Обоснованные отклонения от элементарного бизнес-процесса

Несмотря на то, что основные прецеденты приложения должны сответствовать элементарным бизнес-процессам, зачастую полезно прецеденты более низкого уровня, представляющие подзадачи или последовательности действий в рамках основного прецедента. То есть могут сущестовать преценденты, не соотвествующие EBP.

Прецеденты и задачи

Исполнители имеют свои задачи (или потребности), для решения которых они используют систему. Поэтому прецеденты уровня EBP еще называют преце­дентами уровня задач пользователя (user goal). Это делается для того, чтобы об­ратить внимание на реализацию потребностей пользователей системы или основ­ного исполнителя,

Отсюда следует алгоритм выделения прецедентов.

1. Выделить задачи (цели) пользователей.

2. Определить для каждой из них отдельный прецедент.

При таком подходе несколько смещаются акценты аналитиков. Вместо во­проса "Каковы прецеденты для данной системы?" возникает вопрос "Каковы за­дачи исполнителей?". Чтобы отобразить эту взаимосвязь, имя прецедента долж­но соответствовать названию задачи. Например, задаче электронного оформле­ния продажи должен соответствовать прецедент Оформление продажи.

Заметим, что такая симметрия позволяет оценить адекватность уровня вы­деления прецедентов и задач пользователя в соответствии с правилом выделения элементарных бизнес-процессов.

Совет. Ключевая идея состоит в том, чтобы для выделения преце­дентов исследовать задачи исполнителей.

Допустим, мы собрались на семинаре для формулировки требований. На этом семинаре основной вопрос можно формулировать двумя способами.

• Что делает система?

• Каковы задачи исполнителей?

Ответы на первый вопрос, скорее, отражают текущие решения и процедуры, а также сложность этих процедур.

Ответы на второй вопрос, особенно в сочетании с исследованием целей более высокого уровня ("в чем задача этой задачи?"), открывают видение новых и более эффективных решений, акцентируют внимание на получении ощутимого результата и позволяют глубже понять основные потребности заинтересован­ных лиц в контексте обсуждаемой системы.

Пример: использование рекомендаций в соответствии с EBP

Допустим, вы являетесь системным аналитиком и отвечаете за формулировку требований к системе Алтын. Для этого вам нужно исследовать задачи пользовате­лей. На семинаре по формулировке требований может состояться такой диалог.

Системный аналитик: "Каковы ваши задачи в контексте использования POS-системы”

Кассир: "Во-первых, быстро зарегистрироваться. Во-вторых, оформлять продажи."

Системный аналитик: "Какая задача более высокого уровня приводит, на ваш взгляд, к необходимости выделения отдельной задачи регистрации?"

Кассир: "Мне необходимо "представиться" системе, а она должна прове­рить, имею ли я право ею пользоваться."

---

Системный аналитик: "Какова еще более глобальная задача?"

Кассир: "Предотвратить утечку или повреждение данных."

Обратите внимание на стратегию аналитика выстроить иерархию целей и выявить таким образом нужный уровень для элементарного бизнес-процесса. Это позволяет лучше понять мотивацию действий исполнителей и их задачи.

Предотвращение утечки данных — это цель более высокого уровня, чем за­дача пользователя.

Цель следующего уровня иерархии ("представиться" системе и выполнить аутентификацию) несколько ближе к задачам пользователя. Но относится ли она к уровню элементарных бизнес-процессов? Ее решение не добавляет ощутимого результата или измеримого бизнес-значения. Если на вопрос о том, чем кассир занимался сегодня на работе, прозвучит ответ: "Я 20 раз зарегистрировался!", то вряд ли такой ответ устроит начальника. Значит, это второстепенная задача, Ко­торая служит достижению важной цели, но не относится к уровню ЕВР. Уровню ЕВР точнее всего соответствует задача оформления продажи.

В качестве другого примера можно рассмотреть процесс регистрации вы­ручки, когда кассир задвигает ящик с наличностью и закрывает его в системе, регистрируется и вводит в систему сумму выручки. Регистрация выручки — это прецедент уровня ЕВР (или уровня задач пользователя), а регистрация в сис­теме — это один из его шагов, выполняющий вспомогательную задачу, а не от­дельный прецедент.

Вспомогательные задачи и прецеденты

Несмотря на то, что задача "представиться" системе и выполнить аутенти­фикацию (или задача регистрации) не была отнесена к уровню задач пользовате­ля, она все же является целью, но на более низком уровне. Такие задачи назы­вают вспомогательными (subfunctional goal), поскольку они призваны обеспечи­вать выполнение задач пользователя. Для вспомогательных задач отдельные прецеденты создаются очень редко, хотя специалисты по написанию прецедентов зачастую рекомендуют улучшать (обычно упрощать) набор прецедентов.

Для вспомогательных задач писать прецеденты не запрещается, однако это не всегда нужно, поскольку при этом усложняется модель прецедентов. Количе­ство вспомогательных задач для системы может исчисляться сотнями, но стоит ли создавать так много прецедентов?

Важно понимать, что с увеличением числа прецедентов возрастает слож­ность задачи формулировки и управления требованиями, а значит, увеличивает­ся также время решения этой задачи,

Основным мотивом написания прецедента для вспомогательной должна служить повторяемость этой задачи или ее важное значение как преду­словия для множества других прецедентов. Этому принципу удовлетворяет зада­ча авторизации, которая обеспечивает предусловие для большинства, если не всех остальных прецедентов уровня задач пользователя.

Таким образом, вполне логично создать прецедент Аутентификация пользователя.

---

Составные задачи и прецеденты

Задачи могут принадлежать к различным уровням сложности и являться составными, начиная от уровня предприятия ("быть прибыльным"), до задач среднего уровня ("регистрация торговых операций") и вспомогательных задач в рамках приложения ("проверка правильности ввода").

Аналогично, и прецеденты могут относиться к различным уровням сложно­сти и состоять из прецедентов более низкого уровня.

Наличие нескольких уровней сложности задач и прецедентов может ввести в заблуждение при определении соответствующего уровня для основных преце­дентов. Для отсеивания слишком детальной информации следует использовать принцип нахождения элементарных бизнес-процессов.

Определение основных исполнителей, задач и прецедентов

Прецеденты предназначены для удовлетворения потребностей основных исполните­лей. Поэтому для выделения прецедентов используется следующая процедура.

1. Определите рамки системы: является ли она программным приложением, аппаратно-программным комплексом, включает ли в себя своих пользо­вателей или всю организацию?

2. Идентифицируйте основных исполнителей, потребности (цели) которых удовлетворяются с помощью системы.

3. Для каждого исполнителя определите его задачи. Составьте иерархию в соответствии с рекомендациями по выделению ЕВР.

4. Определите прецеденты, удовлетворяющие потребности каждого испол­нителя, и присвойте им имена в соответствии с задачами. Обычно основ­ные прецеденты соответствуют задачам пользователей, за одним исклю­чением, о котором речь пойдет ниже.

Шаг 1. Определение рамок системы

Для данного прецедента разрабатываемой системой является сама POS-система. Все, что находится за ее пределами, включая кассира, службу автори­зации платежей и т.д., в эти рамки не включается.

Для определения рамок системы следует, в первую очередь, указать, что к ней не относится, т.е. определить внешних основных и вспомогательных испол­нителей. После идентификации внешних исполнителей рамки системы очерчи­ваются более четко. Например, возлагается ли на систему полная ответствен­ность за авторизацию платежей? Нет, эту задачу выполняет внешний исполни­тель — служба авторизации платежей.

Шаги 2 и 3. Определение основных исполнителей и задач

Нельзя однозначно указать последовательность определения исполнителей и задач. Обычно на семинаре по определению требований методом мозгового штурма идентифицируются и те и другие артефакты. Иногда исполнители опре­деляются после формулировки задач, а иногда наоборот.

В процессе мозгового штурма основное внимание следует уделить определению основных исполнителей, поскольку это расширит возможности для дальней­шего исследования.

Вопросы, задаваемые при определении исполнителей и задач

При определении основных исполнителей и задач пользователей следует от­ветить на следующие вопросы, чтобы не упустить из виду некоторые неочевид­ные моменты.

---

• Кто запускает и выключает систему?

• Кто является системным администратором?

• Кто осуществляет управление пользователями и безопасностью?

• Относится ли время к числу исполнителей, другими словами, должна ли система выполнять какие-либо действия в ответ на события времени?

• Существует ли процесс мониторинга, благодаря которому система пере­запускается в случае сбоя?

• Кто контролирует деятельность и производительность системы?

• Как выполняется обновление программного обеспечения?

• Кто анализирует журналы регистрации? Можно ли обеспечить удален­ный доступ к ним?

Основные и вспомогательные исполнители

Напомним, что основные исполнители — это те, чьи потребности удовле­творяются с помощью системы. Для решения своих задач они используют сис­тему. В отличие от них, вспомогательные исполнители (supporting actor) зани­маются обслуживанием системы. Пока сосредоточимся на идентификации основ­ных исполнителей.

Напомним также, что основными исполнителями, среди прочего, могут быть другие компьютерные системы.

Совет. Отсутствие внешних компьютерных систем среди основных исполнителей должно насторожить разработчиков.

Перечень исполнителей и их задач

Составьте список основных исполнителей и их задач. В терминах артефактов унифицированного процесса этот список должен быть разделом артефакта «Видение». Рассмотрим следующую таблицу.

Исполнитель	Задачи	Исполнитель	Задачи
Кассир	Оформляет продажи Оформляет кредиты Выполняет возврат товара Регистрирует выручку	Системный администратор	Добавляет пользователей. Изменяет параметры пользователей. Удаляет пользователей. Управляет безопасностью. Управляет системными таблицами.
Менеджер	Включает систему Выключает систему	Система анализа торговой деятельности	Анализирует информацию о продажах и оценивает производительность

Система анализа торговой деятельности – это yдаленное приложение, которое достаточно часто будет запрашивать данные от ка­ждого узла POS-системы по сети.

"Суровая действительность"

Этот перечень выглядит достаточно просто и понятно. Однако на самом деле создать его довольно сложно. На это уходит масса усилий и требуется несколько интенсивных семинаров, организованных по методу мозгового штурма. Вернемся к приведенному выше примеру, иллюстрирующему применение правила ЕВР к задаче регистрации в системе. На семинаре, посвященном составлению этого списка, кассир может предложить рассматривать регистрацию как одну из задач уровня пользователя. Системный аналитик, углубляясь в проблему, может рас­ширить эту задачу до уровня "идентификации и аутентификации" пользователя. Затем он может осознать, что эта задача не относится к уровню ЕВР и исклю­чить ее из списка задач пользователя. На самом деле, в реальности все будет вы­глядеть несколько иначе, поскольку опытный аналитик, как правило, знает на­бор эвристик, сформулированных на основе его прежнего опыта, одна из кото­рых сводится к следующему: регистрация пользователя редко относится к уровню задач ЕВР. Поэтому он достаточно быстро исключит ее из рассмотрения.

---

Основной исполнитель и задачи системы зависят от ее рамок.

Почему основным исполнителем для прецедента Оформление продажи является кассир, а не покупатель? Почему покупатель не включен в список исполнителей?

Ответ определяется рамками разрабатываемой системы. Если предприятие или торговую организацию рассматривать как агрегатную систему, то для нее основным исполнителем должен являться покупатель, задача которого — приобретение товаров или услуг. Однако с точки зрения самой POS-системы (которая определяет рамки системы для данного прецедента), основным исполнителем является кассир, задача кото­рого — обслуживание продаж.

Определение исполнителей и задач путем анализа событий

Для определения исполнителей, их задач и прецедентов можно также ис­пользовать внешние события. Что это означает? Зачастую к одному и тому же уровню EBP или прецеденту, например, относится целая группа событий.

Внешнее событие	Инициатор	Задача
Ввод информации о наименовании товара	Кассир	Оформить продажу
Ввод информации о платеже	Кассир или покупатель	Оформить продажу
…

Рис. 2. Основные исполнители и их задачи при изменении рамок системы

Шаг 4. Определение прецедентов

Как правило, каждой задаче пользователя соответствует один прецедент уровня ЕВР. Его имя должно соответствовать названию задачи, например, задаче оформле­ния продажи должен соответствовать прецедент Оформление продажи.

Как правило, имя прецедента начинается с существительного, описываю­щего действие.

Типичным исключением из правила соответствия задач и прецедентов явля­ется прецедент, решающий четыре задачи — создание, восстановление, обновле­ние и удаление. Обычно такой прецедент называется Управление <чем-либо>. Например, задачи "изменение информации о пользователях", "удаление пользо­вателей" и т.д. решаются в рамках прецедента Управление пользователями.

Определение прецедентов выполняется в несколько этапов, одни из которых занимают несколько минут (например, присвоение имен прецедентам), а дру­гие — по несколько дней или недель (развернутое описание). В последующих разделах этой главы, посвященных унифицированному процессу, эти этапы бу­дут рассмотрены в контексте итеративной разработки.

Если прецеденты описаны плохо

Для описания прецедентов для POS-системы Алтын в течение нескольких итераций созывались семинары по определению требований, постепенно количе­ство прецедентов увеличивалось, требования уточнялись и дорабатывались с уче­том обратной связи. В процессе описания прецедентов активно участвовали экс­перты предметной области, кассиры и программисты. Между ними не было ни­каких посредников, все общение происходило напрямую.

Хорошо, но не очень. Спецификация требований создает лишь иллюзию корректности. Можно с уверенностью утверждать, что прецеденты и другие тре­бования в этом документе не корректны. В описании не хватает важной инфор­мации и содержатся неверные утверждения. Для решения этой проблемы мы не призываем вас следовать рекомендациям однопроходного процесса разработки и приложить больше усилий к полному описанию требований на начальных этапах разработки, хотя, безусловно, эту работу нужно выполнить максимально добросовестно. Однако этого не достаточно.

---

Смотрите также файлы

• Курсовая работа Управление проектами.docx

• Лабораторная ПРИС управление мероприятиями.docx

• КИС Контрольная работа.doc

• Технические измерения и приборы курсовой.pdf

• Курсовая.doc