Файл: Инфрам.pdf

153 1) перечисление (сбор) возможных требований и идей насчет будущей системы;
2) осознание контекста системы (моделирование предметной области или бизнес-моделирование);
3) определение функциональных требований;
4) определение нефункциональных требований.
Первое, что нужно сделать – это собрать всевозможные требования и идеи, которые можно будет использовать при проектировании системы.
Это будет несистематизированный список, в который должно попасть все, что касается системы и приходит в голову разработчикам, аналити- кам и пользователям. Эти идеи будут кандидатами в будущих версиях системы и используются для планирования работ.
Основными методами выявления требований являются: интервью, опросы, анкетирование; мозговой штурм, семинар; наблюдение за производственной деятельностью, «фотографирова- ние» рабочего дня; анализ нормативной документации; анализ моделей деятельности; анализ конкурентных продуктов; анализ статистики использования предыдущих версий системы.
Каждое собранное предложение в списке должно иметь название и краткое описание, в чем оно заключается. Для дальнейшей работы не- обходима дополнительная информация для планирования и последую- щей реализации требований, в которую могут входить: состояние предложения (одобрено, включено в план, утверждено); трудоемкость в человеко-часах или стоимость реализации; приоритет (критический, важный, вспомогательный); уровень риска, связанный с реализацией предложения (критический, значительный, обычный).
Этот список в ходе работ может уменьшаться, когда требования пре- образуются в другие артефакты – например, варианты использования или нефункциональные требования, и увеличиваться, когда выдвигают- ся новые предложения.
Для того чтобы правильно определить требования разработчики ПС должны понимать контекст (часть предметной области), в котором работает система. Существует два подхода к описанию контекста сис- темы: моделирование предметной области и бизнес-моделирование.
Модель предметной области описывает важные понятия предметной области и их связи между собой. Нельзя путать модель предметной области с логической или физической моделями системы. Модель предметной области описывает только объекты предметной области, но не показывает, как система будет работать с ними. Такая модель позво- ляет составить глоссарий системы для лучшего ее понимания разработ- чиками и пользователями.
В отличие от модели предметной области, бизнес-модель описывает процессы (существующие – As Is или будущее – As To Be), которые

154 должна поддерживать система. Кроме бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности и действия, которые они должны выполнять. Для целей моделирования бизнес- процессов могут быть использованы различные специализированные нотации, такие как ARIS, BPML, IDEF0 и др., и, соответственно, инст- рументы, их поддерживающие, а также инструменты, поддерживающие унифицированный язык моделирования UML, предназначенный, преж- де всего, для разработки программных систем. В этом отношении сле- дует отметить широкие возможности продукта IBM Rational Software
Architect, предназначенного для построения моделей разрабатываемых программных систем с использованием унифицированного языка моде- лирования UML 2.0.
4.4.2. Бизнес-моделирование
Прежде чем приступить к разработке программной системы и к формированию требований к ней, необходимо (за редким исключением) выполнить обследование автоматизируемого предприятия и провести анализ результатов обследования с целью получения описания сущест- вующих на предприятии бизнес-процессов и разработки рекомендаций по их улучшению. Рассмотрим порядок действий, подлежащих выпол- нению, цели и задачи, решаемые в ходе проведения предпроектного анализа, а также способы оформления получаемых результатов.
Любое предприятие и любую предметную область можно предста- вить в виде системы, обладающей некоторой структурой и поведением.
Если говорить о предприятии, то оно имеет организационную структу- ру, включающую в себя набор подразделений, связанных определенным образом друг с другом. Что касается предметной области, то она состо- ит из множества объектов и взаимосвязей между ними. Как объекты предметной области, так и подразделения предприятия являются участ- никами или непосредственно исполнителями некоторых процессов.
Объекты могут сами обладать некоторым поведением либо могут изме- няться под воздействием других объектов в ходе того или иного про- цесса.
Применительно к процессу автоматизации деятельности предпри- ятия его подразделения могут осуществлять какие-то бизнес-процессы или действия в рамках процессов, либо могут играть роль вспомога- тельных единиц, предоставляющих необходимые для осуществления рассматриваемого процесса ресурсы, либо они могут являться потреби- телями результатов выполнения процесса. Такие те же роли могут иг- рать и внешние по отношению к данному предприятию субъекты (дру- гие организации или физические лица) и объекты (например, информа- ционные системы). Часть осуществляемых процессов может быть авто- матизирована. В этих случаях можно говорить о том, что данный про- цесс выполняется данным подразделением с использованием некоторой

155 информационной системы или программно-инструментального средст- ва.
Считается, что автоматизация того или иного процесса должна по- вышать его эффективность. Пути повышения эффективности могут быть различны в зависимости от конкретной ситуации. Иногда доста- точно передать выполнение части каких-то действий той или иной ин- формационной системе (ИС). В некоторых случаях такая система по- зволит значительно сократить набор выполняемых действий за счет ис- ключения лишних или ненужных. Однако часто необходимо сущест- венным образом модифицировать весь процесс, прежде чем передать все входящие в его состав действия либо необходимую их часть инфор- мационной системе.
Не вдаваясь в детали в способы модификации процессов, остановим- ся на технологии, обеспечивающей выполнение всех необходимых дей- ствий по описанию бизнес-процессов с целью последующей их автома- тизации [16].
Основными компонентами любой технологии, как известно, являют- ся следующие:
1. Процесс, определяющий набор осуществляемых действий и их по- следовательность.
2. Получаемые на выходе результаты.
3. Средства и ресурсы, необходимые для выполнения указанных дейст- вий и получения нужных результатов (в том числе инструменталь- ные средства).
4. Состав исполнителей.
В [16] предлагается такая последовательность действий по описанию и моделированию бизнес-процессов автоматизируемой предметной об- ласти:
1. Составляется описание существующих на предприятии процессов, выполняется построение модели процессов «Как есть (As-Is)».
2. На основе определенных критериев выявляются «проблемные» про- цессы и/или действия или, иначе, «проблемы».
3. Намечаются пути решения выявленных проблем, отдельно выделя- ются те, которые могут быть решены посредством автоматизации.
4. Строятся модели процессов «Как будет (As-To-Be)», отмечаются те процессы, которые должны быть автоматизированы.
Описание существующих бизнес-процессов должно удовлетворять следующим требованиям:
1. Описание выполняется в виде набора действий и входов/выходов.
2. Указываются исполнители (сотрудники конкретных подразделений, программные средства, другие механизмы и т.д.)
3. Определенные в процессе описания действия, составляющие про- цесс, должны быть классифицированы в соответствии с необходи- мыми критериями.
4. Описание желательно выполнять с использованием специализиро- ванного инструментального средства, позволяющего отобразить все необходимые атрибуты бизнес-процесса.

156
Результатами деятельности по описанию бизнес-процессов должны являться модели бизнес-процессов автоматизируемой предметной об- ласти.
Выявление «проблемных» процессов может быть выполнено по- средством использования специализированного инструментального средства, либо проблемы могут быть просто перечислены в отдельном документе. Желательно, чтобы выявленные проблемы были явным об- разом связаны с вызывающими их действиями и/или процессами. Еще лучше, чтобы тут же была продемонстрирована связь от проблем к пу- тям их решения.
Что касается модели процесса «Как будет», то его описание должно удовлетворять тем же самым требованиям, что и описание существую- щих бизнес-процессов. Единственным дополнительным атрибутом яв- ляется четкое разделение всех действий, входящих в состав процесса, на те, которые будут подлежать автоматизации и те, которые разрабаты- ваемой информационной системой не будут автоматизированы.
Можно утверждать, что существует некоторая достаточно общая концептуальная схема, в которую можно «уложить» практически любой бизнес-процесс. Наглядным примером такой схемы является следую- щая: «Инициация (возникновение) – Развитие (становление) – Сущест- вование (стадия «жизни») – Исчезновение (гибель)». Если говорить о процессе управления, то для него общераспространенной является схе- ма «Планировать – Делать – Контролировать (проверять) – Действо- вать», положенная в основу стандарта ГОСТ Р ИСО 9001-2001. Стан- дарт ИСО 9000, как и вся серия ИСО 9000, - международная разработка, которой мы обязаны Международной организации по стандартизации
(ISO). Положения стандарта нашли широкое применение в России, бы- ли официально переведены на русский язык и включены в националь- ный стандарт с названием ГОСТ Р ИСО 9000 [8].
При этом, если мы хотим применить описанную схему процесса управления к тому или иному объекту или процессу, нам необходимо обеспечить выполнение следующего набора действий: сохранение ин- формации о планируемых показателях, учет информации о текущем состоянии объекта, анализ плановой информации и информации о те- кущем состоянии управляемого объекта и регулирование. Нетрудно заметить, что своего рода стандартные процессы или, иначе, так назы- ваемые шаблоны процессов присутствуют в любой предметной области.
Например, если говорить о деятельности любого магазина, то ее можно уложить в следующую схему: «Обеспечение необходимого това- ра в наличии – Продажа товара». Если говорить о строительстве зданий, то схема будет выглядеть приблизительно следующим образом: «Выбор и оформление места строительства – Строительство – Сдача готового объекта». И, наконец, всем нам хорошо известно, что процесс разработ- ки программного обеспечения также укладывается в соответствующую концептуальную схему.
Такая общая схема какого-либо процесса играет роль шаблона или каркаса. При выполнении анализа предметной области понимание такой

157 общей схемы аналитиком (и вообще ее наличие) существенно упрощает стоящую перед ним задачу, которая сводится к необходимости опреде- лить детали конкретной реализации данного схематичного процесса на данном предприятии.
Диаграммы деятельности (Activity Diagram) унифицированного язы- ка моделирования UML как раз и позволяют отобразить не только сам процесс, но и каркас, в который его можно «уложить», позволяя создать так называемые контейнеры для составляющих процесс действий. Кро- ме того, действия, составляющие анализируемый процесс, могут быть классифицированы на диаграмме деятельности в соответствии с други- ми критериями, набор которых может зависеть как от специфики анали- зируемой предметной области, так и целей, преследуемых аналитиком.
К наиболее общим критериям, тем не менее, можно отнести следующие: диапазон себестоимости/затрат на выполнение; частота выполнения/периодичность; диапазон эффективности (низкая, средняя, высокая); исполнители (задействованные подразделения, организации; пользо- ватели, информационная система/системы).
Возможны и многие другие критерии.
В случае необходимости отобразить классификацию выполняемых в ходе анализируемого процесса действий по нескольким критериям, можно изобразить несколько диаграмм деятельности для одного и того же процесса, каждая из которых будет отдельным представлением для анализируемого процесса. Нотация диаграммы деятельности такова, что ее элементы позволяют выполнить полноценное описание бизнес- процессов. Более того, с помощью диаграмм деятельности можно вы- полнить всю необходимую последовательность действий по моделиро- ванию бизнес-процессов предметной области с целью последующей их автоматизации в соответствии с описанной выше технологией (табл.
4.2).
Таблица 4.2