3. Реализация

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

4. Тестирование продукта и его внедрение

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

Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.

Внедрения системы обычно предусматривает следующие шаги:

- установка системы,

- обучение пользователей,

- эксплуатация.

5. Сопровождение

Сопровождение продукта подразумевает его поддержку в рабочем состоянии до конца жизненного цикла ПО.

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

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



2.2 Предложение общего подхода к выявлению требований

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

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

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

В описании данного этапа при разработке ПО Карл Вигерс советует: «Задокументируйте этапы выявления, анализа, определения и проверки требований. Наличие инструкций по выполнению ключевых операций поможет аналитикам качественно и согласованно выполнить их работу. Кроме того, вам будет проще поставить задачи по созданию требований и графики, а также продумать необходимые ресурсы» [2]. Таким образом, важной частью этапа анализа является определение процесса выявления и формулирования требований. В соответствие с этим, определим общий подход к выявлению требований.

Стадию выявления и представления требований условно можно разделить на 4 этапа:

1. Выявление требований сбор информации.

2. Первичный анализ требований.

3. Документация требований.

4. Проверка требований.

Для фиксирования точных и верных требований прохождения одного описанного цикла недостаточно. Как правило, необходимо пройти несколько циклов уточнения требований и их формирования из разных источников для формирования базы знаний с необходимой полной информацией. Работать над выявлением требований означает задавать вопросы, выслушивать ответы и наблюдать за действиями пользователей, изучать имеющуюся документацию и т.д. Затем полученную информацию следует обработать, классифицировать по различным категориям и зафиксировать ее в документированном виде. Затем соотнести имеющиеся данные с полученными ранее, и в случае нахождения несоответствий, вернутся к дальнейшему сбору требований. Этапы будут выполняться, чередуясь и периодически повторяясь. Этот итерационный процесс и есть процедура выявления требований.

Рисунок 7 - Процесс выявления требований

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

2.3 Основные источники требований

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

Перечислим важнейшие для анализа виды информации.

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

2. Данные о существующих аналогах. Часто неуспех проекта бывает вызван некачественным сбором информации о продуктах-конкурентах. Грамотный анализ достоинств и недостатков конкурирующих (или предшествующих) продуктов экономит аналитику массу времени и сил. Это тот случай, когда день исследований одного человека может сэкономить многие месяцы работы всего коллектива. Рекламные материалы с сайтов, презентации, демонстраций - важные источники данных для анализа. Бесценными являются отзывы реальных пользователей продуктов. При этом данные о недостатках продуктов-аналогов не менее ценны, чем данные об их достоинствах.

3. Данные о специфике предприятия-заказчика. Для разных видов создаваемых систем важны разные аспекты работы предприятия-заказчика. Чаще всего самой важной является следующая информация:

- специфика бизнес-процессов организации;

- данные об уже используемом в организации ПО, так называемом унаследованном

- ПО (legacy software);

- используемое аппаратное обеспечение;

- политика безопасности организации;

- уровень квалификации персонала [19].

На основе перечисленных видов информации определим основные источники требований:

1. Заинтересованные лица - как правило, являются первым и основным источником требований.

2. Документация - все документы, присутствующие в компании или относящиеся к правовой системе страны\бизнеса, являются источником требований, который чаще всего определяет те или иные ограничения проекта.

3. Сегмент рынка\бизнеса - конкурентные системы будущего продукта являются незаменимым источником требований. Благодаря изучению систем-аналогов можно существенно уменьшить время на выявление требований. Также незаменимым источником являются различные маркетинговые материалы.

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

В индустрии разработки программного обеспечения принято использовать все источники информации, которые существуют на проекте. Несмотря на это, главным источником информации как правило являются заинтересованные лица, которые определяют потребности и зачастую устанавливают границы проекта.

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

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

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



ГЛАВА 3. МЕТОДЫ И СРЕДСТВА ВЫЯВЛЕНИЯ И ПРЕДСТАВЛЕНИЯ ТРЕБОВАНИЙ

3.1 Анализ существующих методов и средств выявления требований

Существует множество практик и подходов, позволяющих добиться стройной и однозначной системы требований, отвечающих реальным потребностям заказчиков и их приоритетам. Ниже описаны основные из них:

1. Опрос - подразумевает опрос существующих и потенциальных пользователей продукта (например, интервью, анкеты);

2. Наблюдение - подразумевается наблюдение за работой пользователей;

3. Изучение правил работы пользователей по существующим регламентам/законодательству, а также изучение существующих документов, описывающих бизнес клиента или существующего продукта;

4. Анализ истории использования продукта по его техническим журналам;

5. Изучение существующих продуктов конкурентов на рынке;

6. Обсуждения и мозговые штурмы с пользователями и экспертами;

7. Маркетинговые исследования;

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

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



3.1.1 Интервьюирование заинтересованных лиц

Использование интервью представляет собой основной метод выявления фактов и сбора информации. Большинство интервью проводятся с заказчиками. Интервью с заказчиками позволяют выявить по большей части “прецедентные” требования, т.е. требования вытекающие из “прецедентов”. Если бизнес аналитик не обладает достаточным опытом в проблемной области, можно также проинтервьюировать соответствующих экспертов.

Интервью с экспертами в прикладной области зачастую представляет собой просто процесс передачи знаний -- занятие по обучению бизнес аналитика. Интервью с заказчиками отличает большая сложность [20].

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

Существуют два основных типа интервью: структурированное (формальное) и не структурированное (неформальное). Структурированное интервью готовится заранее, отличается ясностью постановки вопросов, а многие вопросы могут быть заданы заранее.

Заранее сформулированные вопросы можно разделить на две категории: вопросы c открытым множеством ответов(open ended question) (ответы на эту категорию вопросов заранее не готовятся) и вопросы c замкнутым множеством ответов (closed ended question) (ответы на эту категорию вопросов можно выбрать из списка подготовленных ответов).

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

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

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

- Небеспристрастные вопросы, в которых интервьюер выражает (прямо или косвенно) свое мнение по вопросу (“Должны ли мы работать так, как мы работаем?”).

- Предвзятые вопросы, аналогичные небеспристрастным, но отличаются от последних тем, что мнение интервьюера является, очевидно, тенденциозным (“Вы ведь не станете этого делать, не так ли?”).

- Наводящие вопросы, которые предполагают ответ в самом вопросе (“Вы ведь сделаете именно так, не правда ли?”).

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

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

Чтобы не упустить из виду потребности отдельных пользователей необходимо:

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

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

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

1. Стейкхолдеры уже не могут придумать новые варианты использования.

2. Стейкхолдеры предлагают новые варианты использования, однако вы уже вывели соответствующие функциональные требования из других вариантов использования.

3. Стейкхолдеры описывают проблемы, которые уже обсуждались;

4. Стейкхолдеры новые функции выходят за рамки проекта;

5. Стейкхолдеры предлагают возможности, которые имеет смысл реализовать когда-то позже.

3.1.2 Анкетирование заинтересованных лиц

Использование анкет или анкетирование (questionnaires) -- эффективный способ сбора информации от многих заказчиков. Обычно анкеты используются в дополнение к интервью, а не вместо них. Исключение могут составлять проекты с низким риском, цели которых ясно очерчены. Для таких проектов обычно достаточно использовать анкеты с вопросами, которые носят пассивный характер и не отличаются большой глубиной.

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

Анкетирование пассивно -- это можно расценивать и как достоинство, и как недостаток. Это достоинство, поскольку у респондента есть время подумать над ответом, а анкета может остаться анонимной. Это недостаток, поскольку респонденту нелегко прояснить для себя вопросы.

Анкета (или вопросник) должна быть разработана таким образом, чтобы, по возможности, облегчить ответы на вопросы. В частности, следует избегать вопросов с неопределенным множеством ответов -- большинство вопросов должны относиться к вопросам с замкнутым списком ответов. Подобные вопросы могут принимать три формы [20].

- Многоальтернативные вопросы (multiple choice questions). При ответе на эти вопросы респондент должен указать один или более ответов, выбрав их из прилагаемого списка. Кроме того, иногда допускаются дополнительные комментарии к вопросам со стороны респондентов.

- Рейтинговые вопросы (rating questions). При ответе на этот тип вопросов респондент должен выразить свое мнение в отношении высказанного утверждения. Для этого могут использоваться такие рейтинговые значения, как “абсолютно согласен”, “согласен”, “отношусь нейтрально”, “не согласен”, “абсолютно не согласен” и “не знаю”.

- Вопросы с ранжированием (ranking questions). Этот тип вопросов предусматривает ранжирование ответов с помощью присваивания им последовательных номеров, процентных значений и использования других средств упорядочения.

Тщательно продуманная, облегчающая ответы анкета поощряет респондента к тому, чтобы сразу вернуть заполненный документ. Однако, при оценке результатов анкетирования бизнес-аналитик должен предусмотреть возможность искажения информации из-за того, что те люди, которые не отвечали на вопросы, могли бы ответить на них иначе, чет принимавшие участие в опросе [20].

3.1.3 Наблюдение за бизнесом заказчика

Бизнес -- анализ представляет собой действенное средство реализации принципов социальной ответственности бизнеса и обеспечения условий устойчивого развития как отдельных компаний, так и общества в целом [21]. В некоторых ситуациях бизнес-аналитик находит трудным получить полную информацию с использованием интервью и анкет. У заказчика по тем или иным причинам может отсутствовать возможность (или умение) предоставить необходимую информацию, либо он может не иметь полного представления о бизнес-процессе в целом. В подобных случаях в качестве эффективного метода выявления фактов может выступать наблюдение (observation).

Наблюдение может выступать в двух формах.

- Пассивное наблюдение (passive observation), в ходе которого бизнес-аналитик наблюдает за различными видами деловой деятельности без вмешательства или прямого участия в них. В некоторых случаях для того, чтобы наблюдение было как можно менее навязчивым, можно даже использовать видеокамеры.

- Активное наблюдение (active observation), в ходе которого бизнес-аналитик участвует в деятельности и становится фактически частью команды.

Чтобы результаты наблюдений были представительными, наблюдения необходимо проводить в течение продолжительного периода времени, в разные временные интервалы и при разной рабочей нагрузке (выборочные периоды). Основная трудность, связанная с наблюдением, состоит в том, что люди, за которыми наблюдают, склонны вести себя иначе, чем в обычной обстановке. В частности, они стремятся работать в соответствии с формальными правилами и процедурами. Это приводит к искажению реального положения дел за счет утаивания “рациональных” приемов работы -- как положительных, так и отрицательных. Следует помнить, что “работа по правилам” -- это одна из эффективных форм забастовочного движения.

3.1.4 Изучение документов и программных систем

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

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

К организационным документам, подлежащим изучению, относятся: формы деловых документов (по возможности -- заполненные), описания рабочих процедур, должностные обязанности, методические руководства, бизнес-планы, схемы организационных структур, внутриофисная корреспонденция, протоколы совещаний, учетные записи, внешняя корреспонденция, жалобы клиентов и т.д.

Системные формы и отчеты, подлежащие изучению, включают: копии экранов, отчеты вместе с соответствующей документацией -- системные руководства по эксплуатации, пользовательская документация, техническая документация, системные модели анализа и проектирования и т.д.

Требования, основанные на знании проблемной области, выясняются посредством изучения журналов и учебников, которые относятся к данной сфере. Изучение патентованных программных пакетов наподобие ERP систем (Enterprise Resource Planning Systems -- системы планирования ресурсов предприятия) также может стать богатым источником знаний о проблемной области. Следовательно, посещения библиотек и поставщиков ПО являются частью процесса выявления требований (конечно, Internet позволяет осуществить многие такие “визиты”, не покидая офиса).

3.1.5 Современные методы выявления требований

К современным методам выявления требований относится использование программных прототипов, а также такие методы, как JAD (Joint Application Development -- совместная разработка приложений)и RAD (Rapid Application Development -- быстрая разработка приложений). Эти подходы предлагают более глубокое проникновение в суть требований, но за счет большей цены и усилий. Однако, долговременные вложения в эти методы могут окупиться с лихвой.

Применение современных методов обычно связано с высоким проектным риском.

Существует множество факторов, обусловливающих высокий риск проекта. К таким факторам относятся неясные цели, недокументированные процедуры, нестабильные требования, слабое знание дела пользователями, неопытные разработчики, недостаточная приверженность пользователей разработке и т.д.

Прототипирование (prototyping)-- это наиболее часто используемый современный метод выявления требований. Программные прототипы конструируются для визуализации системы или ее части для заказчиков с целью получения их отзывов.

Прототип представляет собой демонстрационную систему -- “наскоро и грубо” сделанную рабочую модель решения, которая представляет пользовательский GUI интерфейс и моделирует поведение системы при инициировании пользователем различных событий. Информационное наполнение экранов чаще жестко запрограммировано в программе прототипа, чем получается автоматически из базы данных.

Сложность (и растущие “аппетиты” заказчиков) современных GUI интерфейсов делают прототипирование обязательным элементом разработки ПО. Прототипы позволяют довольно неплохо оценить реализуемость и полезность системы до начала ее реализации.

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

Существуют две основные разновидности прототипов [20].

- “Одноразовый” прототип(“throwaway” prototype), который после того, как выявление требований завершено, просто отбрасывается. Разработка “одноразового” прототипа нацелена только на этап установления требований ЖЦ ПО. Как правило, этот прототип концентрируется на наименее понятных требованиях.

- Эволюционный прототип (evolutionary prototype), который сохраняется после выявления требований и используется для создания конечного программного продукта. Эволюционный прототип нацелен на ускорение поставки продукта. Как правило, он концентрируется на ясно изложенных требованиях, так что первую версию продукта можно предоставить заказчику довольно быстро (хотя ее функциональные возможности, как правило, неполны).

Дополнительным доводом в пользу использования именно “одноразового” прототипа может служить стремление избежать риска “консервации” скорых и грубых и, как следствие, неэффективных решений в конечном продукте. Однако мощь и гибкость современных средств создания ПО ослабляют этот довод. Если управление проектом осуществляется надлежащим образом, то причины, по которой нельзя было бы избавиться от неэффективных предложенных для прототипа решений, не существует.

JAD метод полностью соответствует своему названию -- это совместная разработка приложений (Joint Application Development), осуществляемая в ходе одного или нескольких совещаний с привлечением всех участников проекта (заказчиков и разработчиков). Хотя мы относим JAD подход к современным методам выявления требований, этот метод был впервые введен в конце 1970 х годов компанией IBM.

Существует много разновидностей JAD метода и много фирм, предлагающих услуги по организации и проведению JAD совещаний. Проведение JAD совещаний может занимать несколько часов, несколько дней или даже пару недель. Количество участников не должно превышать 25-30 человек. В совещании принимает участие следующий круг лиц.

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

Секретарь-- человек, который фиксирует ход JAD сессии с использованием компьютера. Этот человек должен уметь быстро вводить текст в компьютер и хорошо владеть вопросами разработки ПО. Для документальной фиксации хода сессии и разработки первоначальных моделей решений секретарь может использовать CASE средства.

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

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

JAD метод зиждется на групповой динамике. Групповые усилия более перспективны с точки зрения получения лучших решений проблем. Группы способствуют повышению продуктивности, быстрее обучаются, склонны к более квалифицированным заключениям, позволяют исключить многие ошибки, принимают рискованные решения (иногда это может носить негативный характер!), концентрируют внимание участников на наиболее важных вопросах, объединяют людей и т.д.

Если JAD сессия проводится в соответствии с правилами, можно добиться удивительно хороших результатов.

Метод быстрой разработки приложений (Rapid Application Development-- RAD) -- это нечто большее, чем метод выявления требований -- это целостный подход к разработке ПО. Как ясно из названия метода, он предполагает быструю поставку системных решений. Техническое превосходство отступает на второе место в сравнении со скоростью поставки.

Согласно Вуду (Wood) и Сильверу (Silver)[95] технология RAD сочетает в себе пять методов, перечисленных ниже.

- Эволюционное прототипирование.

- CASE средства с возможностями генерации программ и циклической разработкой с переходом от проектных моделей к программе и обратно.

- Специалисты, владеющие развитыми инструментальными средствами (Specialists with Advanced Tools-- SWAT) -- RAD бригада разработчиков. Лучшие аналитики, проектировщики и программисты, которых только может привлечь организация.

Бригада работает в рамках строгого временного режима и размещается вместе с пользователями.

Интерактивный JAD метод-- JAD сессия, во время которой секретарь заменяется бригадой SWAT, оснащенной CASE средствами.

- Жесткие временные рамки (timeboxing) -- метод управления проектом, который отводит бригаде SWAT фиксированный период времени (timebox) для завершения проекта. Этот метод препятствует “расползанию рамок проекта”; если проект затягивается, то рамки решения сужаются, чтобы дать возможность завершить проект своевременно.

Использование RAD подхода может оказаться привлекательным вариантом для многих проектов, в особенности, для небольших проектов, которые не затрагивают сферу ключевых бизне процессов организации, и которые, таким образом, не задают план решения для других проектов по разработке ПО. Маловероятно, чтобы быстрые решения были оптимальными или долговременными для ключевых сфер деятельности организации. С использованием RAD метода связан ряд проблем; некоторые из них перечислены ниже.

1. Несовместимый проект GUI интерфейса.

2. Вместо общих решений, способствующих многократному использованию ПО, специализированные решения.

3. Неполная документация.

4. Трудное для поддержки и масштабирования ПО и т.д.

3.2 Согласование и проверка обоснованности требований

Использование принципов бизнес -- анализа предполагает использование наряду с финансовыми критериями и показателей сбалансированного удовлетворения требований ключевых заинтересованных сторон [22]. Требования, полученные от пользователей, могут дублироваться или противоречить друг другу. Некоторые требования могут быть неясными или нереальными. Другие требования могут остаться невыясненными. По этой причине прежде, чем требования попадут в документ описания требований, их необходимо согласовать.

В действительности согласование и проверка обоснованности требований осуществляется параллельно с выявлением требований. После того как требования выявлены, они подвергаются определенному уровню проверки. Для всех современных методов выявления требований, которые связаны с так называемой “групповой динамикой”, это вполне естественно. Как бы там ни было, после того как выявленные требования собраны вместе, они в любом случае должны быть подвергнуты тщательному обсуждению и проверке.

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

Для проверки обоснованности требований (requirements validation) необходима версия документа, в котором все требования четко идентифицированы и классифицированы. Участники проекта изучают документ и проводят совещания по их формальному пересмотру. Пересмотры (reviews) часто структурированы в виде так называемых процедур сквозного контроля (walkthroughs) или инспекций (inspections). Пересмотры являются разновидностью тестирования (testing).

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

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

3.3 Достоинства и недостатки основных существующих методов выявления и представления требований

Выбор того или иного метода выявления требований зависит от категории продукта (домашняя веб-страничка, программа для домашнего пользователя, программная система автоматизирующую работу атомной станции), и, следовательно, связанных с ней допустимых сроков разработки, стоимости и качества (безопасности, надёжности, производительности, удобства).

Если программа делается для конкретных людей, которых мы знаем и к которым имеем доступ (заказная разработка), то удобно использовать наблюдение, интервью, мозговой штурм, анализ регламентов.

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

При автоматизации большого предприятия может понадобиться большая трудоёмкая и довольно дорогостоящая предварительная работа по описанию его бизнес-процессов и выделению тех участков, которые нуждаются в автоматизации.

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

Эффективность традиционных методов выявления и представления требований обратно пропорциональна риску проекта. Высокий риск означает, что систему трудно реализовать -- не вполне ясны даже обобщенные требования. Для таких проектов традиционных методов вряд ли будет достаточно [20]. В таком случае могут использоваться современные методы выявления требований, однако, как описано в предыдущих разделах, и они имеют ряд недостатков.

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

3.4 Комбинированный подход выявления и представления требований. Структуризация требований в базе знаний на основе расширенной классификации

Как было описано в главе 2.2, стадию выявления и представления требований условно можно разделить на 4 этапа:

1. Выявление требований, сбор информации.

2. Первичный анализ требований.

3. Документация требований.

4. Проверка требований.

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

Рисунок 8 - Процесс выявления требований по новому методу



После первичного сбора требований мы имеем структурированную базу знаний об основных бизнес-процессах компании и необходимых средств их автоматизации. База знаний представляет собой список требований, которые классифицируются в зависимости от их источника, принадлежности к функциональности и контексте выявления.

Информация представляется в виде списка требований, классифицируя ее по большему количеству параметров, как показано на рисунке 4.

Рисунок 9 - Пример базы знаний с приведенной классификацией

Рассмотрим более подробно Шаг 4. После определения первичной версии базы знаний необходимо приступить к ее более подробному уточнению на предмет пропуска требований, их противоречивости или неполному определению. Практика показывает, что первичный анализ на предмет явных противоречий следует провести еще на этапе их сбора и формирования.

Чаще всего времени на выявление противоречий у нас довольно мало (обычно, данный этап ограничивается несколькими днями, однако это зависит от методологии разработки), поэтому лучше всего принять самый быстрый подход. Поскольку для устранения «разрастания» требований, их двусмысленности, информацию нужно согласовывать со многими участниками проекта, данные нужно представить в виде, при котором на ее согласование тратилось бы минимальное количество времени. А учитывая то, что при наглядном представлении изучаемый материал становится более доходчивым и понятным, мы приходим к необходимости в сжатые сроки представить уже имеющиеся требования в графическом виде, и, как следствие, в одном из подходящих методов моделирования.

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

Таким образом, требования должны быть представлены в одной из модели для их последующего согласования. Тип модели в представлении зависит от типов требований, которые планируется выявлять и уточнять на следующем шаге. Подробно об использовании различных моделей для их проверки и последующего согласования описано в следующих главах диссертации, где раскрывается, какой «срез» классификации требований базы знаний следует использовать для того или иного типа моделирования.

Далее аналитик возвращается к Шагу 1 (выявлению требований) с целью согласования требований с основными участниками проекта на основе уже имеющейся модели. При этом рекомендуется использовать метод Интервьюирования в контексте обсуждения имеющейся модели данных, однако можно использовать и другие методы выявления требований с учетом последующей корректировки модели в качестве методики проверки и внесения данных в базу знаний. После согласования требований с ключевыми заинтересованными лицами в виде обсуждения, анкетирования или опроса, где предметом обсуждения является контекстная диаграмма как метод моделирования, мы вносим необходимые изменения в базу знаний требований дополняя и корректируя их. Количество шагов согласования требований на основе обсуждения контекстной модели с ключевыми заинтересованными лицами с последующим внесением корректировок в базу знаний зависит от сложности проекта и количества выделенного времени на фазу анализа.

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



3.4.1 Моделирование целей и стратегий бизнеса

Моделирование целей и стратегий позволит наиболее явно представить цели бизнеса, сформулировать требования на основе бизнес-возможностей компании и ее стратегической деятельности. Для данного моделирования используется «срез» требований в соответствии с классификацией «Бизнес требование» и «Ограничение» (см. рис. 5). Однако следует учесть, что для такого типа моделирования можно использовать и полную таблицу требований как единую систему знаний и информации о компании.

Как примеры моделирования рассмотрим Стратегическую карту, Диаграмму связей и, как ее частный случай, Диаграмму Ишикавы.

Стратегическая карта (англ. Strategy Maps) - это диаграмма или рисунок, представляющий стратегию в виде набора стратегических целей и причинно-следственных связей между ними. Стратегическая карта представляет схему для логичного и четкого изложения и разъяснения стратегии, превращая ее в план действия.

Стратегическая карта помогает команде понять стратегии и то, как взаимосвязаны между собой различные стратегические цели. Очень важно, что стратегические карты точно объясняют каждому участнику то, как его индивидуальные цели, проекты и достижения содействуют реализации общей стратегии, ее целей и в конечном счете общему успеху. Важно также, что четкие причинно-следственные соотношения, отраженные на стратегической карте, позволяют сбалансировано и эффективно обеспечивать поддержку выполнения стратегии. Пример стратегической карты представлен на рисунке 5. Возможные инструменты для моделирования: «График студия», Xmind.



Рисунок 10 - Пример стратегической карты компании

Диаграмма связей, известная также как интеллект-карта или ассоциативная карта, (англ. Mind map) - способ изображения процесса общего системного мышления с помощью схем. Также может рассматриваться как удобная техника альтернативной записи.

Диаграмма связей реализуется в виде древовидной схемы, на которой изображены слова, идеи, задачи или другие понятия, связанные ветвями, отходящими от центрального понятия или идеи. В основе этой техники лежит принцип «радиантного мышления», относящийся к ассоциативным мыслительным процессам, отправной точкой или точкой приложения которых является центральный объект.

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

Пример диаграммы связей представлен на рисунке 6. Возможные инструменты для моделирования: Mind Jet, Free Mind, XMind.



Рисунок 11 - Пример диаграммы связей

Диаграмма Ишикавы (cause-effect diagram, fishbone diagram) - частный случай диаграммы связей. Это графический инструмент, позволяющий наглядно и систематизировано анализировать взаимосвязи следствий (effects) и причин (causes), которые порождают эти следствия или влияют на них. Еще эти диаграммы называют «диаграммами рыбного скелета» (fishbone diagram) за их внешнее сходство со скелетом рыб. Но какое бы имя не использовалось, необходимо помнить, что ценность этого метода состоит в способствовании категоризации и структуризации множества потенциальных причин, а так же, идентификации наиболее вероятной корневой причины изучаемого следствия.

Метод применим при выполнении анализа как одним специалистом, так и группой специалистов.

Пример диаграммы связей представлен на рисунке 7. Возможные инструменты для моделирования: TIBCO, Visio, Xmind.



Рисунок 12 - Пример диаграммы Ишикавы

3.4.2 Моделирование бизнес-процессов компании

Моделирование бизнес-процессов компании позволит наиболее явно представить бизнес-процессы компании в наглядном виде, поможет лучше понять особенности бизнеса и возможные ограничения и предпочтения в автоматизации процессов. Для данного моделирования мы будем также использовать разрез требований в соответствии с классификацией «Бизнес требование» и «Ограничение», однако, в отличие от моделирования целей и стратегий, не оглядываясь на другие типы требований для уменьшения «шума» и «загруженности» данных.

Как примеры моделирования рассмотрим Idef0, Idef3 (PFDD, OSTN), BPMN, EPC, а также, такие привычные способы моделирования, как Процесс и Процедура.

Idef0 - Function Modeling - методология функционального моделирования. С помощью наглядного графического языка Idef0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах Idef0). Как правило, моделирование средствами Idef0 является первым этапом изучения любой системы.

В основе методологии описания бизнес-процессов по стандарту Idef0 лежат два основных понятия: функциональный блок и интерфейсная дуга.

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

Каждая из четырех сторон функционального блока имеет свое определенное значение (свою роль):

- верхняя сторона имеет значение «Управление» - это регламенты, политики и процедуры, под воздействием или управлением которых осуществляется деятельность;

- левая сторона имеет значение «Вход» - это ресурс, подаваемый на вход, который преобразуется в процессе для получения результата (выхода);

- правая сторона имеет значение «Выход» - это результат деятельности процесса;

- нижняя сторона имеет значение «Механизмы» - инструменты, при помощи или с использованием которых осуществляется деятельность.

Пример диаграммы связей представлен на рисунке 8. Возможные инструменты для моделирования: BPWin, Visio.



Рисунок 13 - Пример диаграммы Idef0

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

Существуют два типа диаграмм в стандарте Idef3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах:

1) Диаграммы Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD). Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

2) Диаграммы Состояния Объекта в его Трансформации (Object State Transition Network, OSTN).

Возможные инструменты для моделирования Idef3: BPWin, Visio.

Диаграмма Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) - предназначена для описания последовательности этапов процесса. Пример диаграммы представлен на рисунке 9.

Рисунок 14 - Пример диаграммы Idef3 PFDD

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.

Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.

Диаграммами Состояния Объекта в его Трансформации (Object State Transition Network, OSTN) - если диаграммы PFDD рассматривает технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта".

Состояния объекта и изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Пример диаграммы OSTN представлен на рисунке 10.

Рисунок 15 Пример диаграммы Idef3 OSTN

Моделирование бизнес-процессов при помощи BPMN (Business Process Modeling Notation) позволяет описывать графическую нотацию для отображения бизнес-процессов в виде диаграмм бизнес процессов. BPMN ориентирована как на технических специалистов, так и на бизнес пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции.

Основная цель BPMN - создание стандартной нотации понятной всем бизнес пользователям. Бизнес пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими. Следовательно, BPMN призвана служить связующим звеном между фазой дизайна бизнес процесса и фазой его реализации.

Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:

- Объекты потока управления: события, действия и логические операторы

- Соединяющие объекты: поток управления, поток сообщений и ассоциации

- Роли: пулы и дорожки

- Артефакты: данные, группы и текстовые аннотации.

Пример диаграммы BPMN представлен на рисунке 11. Возможный инструмент для моделирования: TIBCO.

Рисунок 16 Пример диаграммы BPMN

EPC (Event-Driven Process Chain, событийная цепочка процессов) - нотация отображения хода выполнения процесса, ключевыми элементами которой являются События и Функции.

Диаграмма бизнес-процесса в EPC должна начинаться и заканчиваться Событием. За Функцией всегда должно следовать Событие, т.е. выполнение Функции создает некоторое событие (состояние). Документы, организационные звенья, информационные и материальные потоки, элементы информационной системы (программное обеспечение, базы данных) имеют свое графическое обозначение.

Возможный инструмент для моделирования EPC: Visio.

Пример диаграммы EPC представлен на рисунке 12.

Рисунок 17 Пример диаграммы EPC

Процесс (Basic Flowchart, простая блок-схема) - нотация, представляющая собой простой вариант пошагового выполнения алгоритма. Используется на низшем уровне описания бизнес-модели.

Блок-схема используется в различных областях знаний. Многим она может быть известна по школьным урокам информатики.

Процесс (Basic Flowchart) состоит из прямоугольников (бизнес-процессы), в которые входят и выходя стрелки (потоки информации, документов, ТМЦ). Так же в нотации используются элементы типа «решение», которые позволяют делать ветвления. Для обозначения начала выполнения всего бизнес-процесса и его окончания могут быть использованы фигуры типа «событие» (элементы, похожие на овалы).