Методы и средства выявления и представления требований к разработке ПО

Министерство образования Республики Беларусь

Учреждение образования

«Белорусский государственный университет информатики и радиоэлектроники»

Диссертация

на соискание степени магистра экономических наук

-25 80 08 Математические и инструментальные методы экономики

Методы и средства выявления и представления требований к разработке ПО

Пищикова Екатерина Сергеевна

Научный руководитель

Комличенко Виталий Николаевич,

кандидат технических наук, доцент

Минск, 2015

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

Две наиболее распространенные проблемы, о которых сообщается в большом Европейском обзоре индустрии ПО - определение и управление требованиями заказчика.

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

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

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

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

Задачи исследования.

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

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

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

Объект исследования. Процесс разработки ПО.

Предмет исследования. Методы и средства формирования требований.

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

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

Основные положения диссертации, выносимые на защиту. На защиту выносятся следующие основные результаты:

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

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

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

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

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

1) Публикация автором в сборнике международной молодежной научной конференции «Молодежь в науке: новые аргументы» статьи «Методы выявления и представления требований к разработке ПО».

) Публикация автором в сборнике XXVI международной научно-практической конференции «Естественные и математические науки в современном мире» статьи «Техники выявления требований к разработке ПО»

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

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

 

ВВЕДЕНИЕ

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

Вопросам разработки требований к программному обеспечению (ПО) уделяется большое внимание в стандартах по программной инженерии, а рекомендации по лучшим практикам публикуются в разработках типа «Свод знаний по программной инженерии» (SWEBOK - Software Engineering Body of Knowledge) [1]. В SWEBOK разработка программных требований (Software requirements) представлена как одна из десяти важнейших областей знаний создания ПО. На практике же часто применяются подходы, используемые в различных методологиях разработки ПО и базирующиеся на определении групп требований к продукту. Следует также отметить, что выявление и извлечение, формализация и документирование требований к ПО составляют основу спецификации на разработку проекта. Кроме того, в случае сложных программных систем, существует целый комплекс спецификаций, документов, которые являются результатом сбора и анализа требований, их моделирования и архитектурного проектирования. Эти документы представляют базовый контекст создания программных систем.

Требования анализируются, в них вносятся изменения, они пересматриваются и утверждаются.

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

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

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

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

Основными задачами данной работы являются:

1) Анализ сущности, понятия и классификации требований, определение основных атрибутов требований для их документирования.

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

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

заказчик требование программный обеспечение

ГЛАВА 1. ТРЕБОВАНИЕ КАК СВОЙСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1 Требование. Определение и извлечение требований

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

Рисунок 1 - Справочники и стандарты требований

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

В соответствии со стандартом разработки требований ISO/IEC 29148, требование - это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества) [4].

По другому определению требования - это возможности или условия, которым должна соответствовать система или проект [5].

IEEE Standard Glossary of Software Engineering Terminology определяет требования как:

1.      Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

.        Документированное представление условий или возможностей для п. 1 и 2. [6]

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

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

1. Единичность - требование описывает одну и только одну вещь.

2. Завершенность - требование полностью определено в одном месте и вся необходимая информация присутствует.

. Последовательность - требование не противоречит другим требованиям и полностью соответствует документации.

. Атомарность - требование нельзя разделить на более мелкие.

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

. Актуальность - требование не стало устаревшим с течением времени.

. Выполнимость - требование может быть реализовано в рамках проекта.

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

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

.        Проверяемость - реализованность требования может быть проверена.

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

. Насколько оно должно быть надежно. Примеры:) Работать 7 дней в неделю и 24 часа в сутки;) Допускается неработоспособность в течение не более 3 часов в год.

. Насколько им должно быть удобно пользоваться. Примеры:) Покупатель должен легко находить нужный ему товар;) Инженер по специальности «строительство мостов» должен легко понимать, как пользоваться системой.

. Насколько оно должно быть эффективно. Примеры:) Поддерживать обслуживание до 10000 запросов в секунду;) Время отклика на запрос при максимальной загрузке не должно превышать 3 с;) Время реакции на изменение параметров процесса производства не должно превышать 0.1 с;) На обработку одного запроса не должно тратиться более 10 MB оперативной памяти.

. Насколько удобно должно быть его сопровождение. Примеры:) Добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;) Добавление поддержки нового процесса производства не должно занимать более 24 человеко-месяцев.

. Насколько оно должно быть переносимо и заменяемо. Примеры:) ПО должно работать на операционных системах Linux, Windows XP и Mc OS X;) ПО должно работать с документами в форматах MS Word;) ПО должно сопрягаться с существующей системой записи данных о заказах.

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

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

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

1.2 Анализ существующих уровней и классификаций требований. Предложение расширенной классификации с дополнительными атрибутами

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

Рисунок 2 - Классификация требований по К. Вигерсу

Обычно выделяют три уровня требований:

. На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.

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

. Третий уровень - функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

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

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

Рассмотрим требования с точки зрения их классификации.

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

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

Рисунок 3 - Характеристика описания требований

К функциональным требованиям относят:

.1. Бизнес-требования. Что система должна делать с точки зрения бизнеса. Слово "бизнес" в данном контексте ближе к слову "заказчик". Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.

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

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

.4. В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта - объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС - Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

Почему важно указывать системные требования и утверждать их у заказчика? Если не указать, например, что важно обеспечить просмотр сайта в IE 6, то разработчики вполне могут выбрать такое архитектурное решение, которое не позволит корректно отображать сайт. Системные требования напрямую зависят от целевой аудитории проекта.

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

. Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2] выделяет следующие основные группы нефункциональных требований:

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

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

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

легкость и простота использования (usability)

производительность (performance)

удобство эксплуатации и технического обслуживания (maintainability)

надежность и устойчивость к сбоям (reliability)

взаимодействия системы с внешним миром (interfaces)

расширяемость (scalability)

требования к пользовательским и программным интерфейсам (user and software interface).

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

Относительно состава групп функциональных и нефункциональных требований до сих пор нет согласия [7]. Разные авторы и эксперты могут как добавлять, так и исключать подгруппы требований. Например, часто ограничения объединяют с бизнес-правилами, а бизнес-требования объединяют с ключевыми потребностями. На рисунке 4 представлены соответствия типов требований по Вигерсу и ГОСТ 34.602, 34.601, 7.32-2001.

Если рассматривать стандарт ITILv3, все требования в проекте можно разделить на следующие группы:

1. Функциональные (Functional) - реализуют саму бизнес-функцию.

2. Управленческие (Manageability) - требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.

. Эргономические (Usability) - к удобству работы конечных пользователей.

. Архитектурные (Architectural) - требования к архитектуре системы.

. Взаимодействия (Interface) - к взаимосвязям между существующими приложениями и программным средствами и новым приложением.

. Сервисного уровня (Service Level) - описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком [8].

Рисунок 4. Описание соответствий типов требований по К.Вигерсу и ГОСТ 34.602, ГОСТ 34.601, ГОСТ 7.32-2001

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

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

. Функциональность - функциональное или нефункциональное требование по классической типизации.

. Уровень требования - бизнес-требование, пользовательское требование, функциональное требование

. Модуль системы - модуль, к реализации которого относится требование

. Название требования - атрибут, отражающий саму суть требования.

. Комментарии - комментарии к требованию, дополнительное описание или уточнение.

. Этап реализации - этап реализации системы, в котором будет реализовано требование.

. Приоритет - приоритет реализации данного требования

. Статус реализации - на какой стадии реализации находится требование.

. Источник требования - кто или что было инициатором требования

.        Дата появления - дата появления требования.

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

1.3 Определение основных заинтересованных лиц проекта

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

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

По определению ISO/IEC, Стейкхо́лдер (англ. stákeholder) (заинтересованная сторона, причастная сторона) - это физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям.

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

Те, кто будет пользоваться системой

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

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

Люди или организации, которые против существования системы (заинтересованные лица, находящееся в оппозиции)

Организации, ответственные за системы, которые связаны или взаимодействуют с разрабатываемой системой

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

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

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

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

Приобретающая сторона, или покупатель (англ. acquirer) - организация или физическое лицо, которое приобретает или получает (англ. procures) продукт или услугу от поставщика [11]. Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.[12]

Заказчик, или клиент (англ. customer) - организация или физическое лицо, получающее продукт или услугу [11].

Разработчик (англ. developer) - организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла [11].

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

Производитель (англ. producer) - представитель, ответственный за выполнение работы [14]; лицо, ответственное за выравнивание расписания, бюджета и ограниченность ресурсов, чтобы удовлетворить клиентам [11].

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

Ликвидатор (англ. disposer) - организация или физическое лицо, выполняющее ликвидацию (изъятие и списание) рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб [11].

Аккредитор, или инспектор (англ. accreditor) - организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию [15].

Регулирующий орган (англ. regulatory bodies) - организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации [15]. Остальные - персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

Результатами успешного осуществления процесса определения требований стейкхолдеров является:

требуемые характеристики и условия использования услуг;

формализованные ограничения для системных решений;

возможность прослеживания от требований стейкхолдеров к стейкхолдерам и их потребностям;

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

основа для валидации соответствия услуг;

сформированная основа для ведения переговоров и заключения соглашений о поставке услуги или продукции.

Процесс идентификации стейкхолдеров можно сформулировать как: идентификацию стейкхолдеров или классов стейкхолдеров, имеющих интерес к системе в процессе её жизненного цикла. Если непосредственная коммуникация невозможна, выбираются представители стейкхолдеров [16].

Процесс идентификации требований в контексте их выявления у заинтересованных лиц состоит из решения следующих задач:

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

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

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

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

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

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

Рисунок 5 Совокупность требований к ПО с учетом требований всех заинтересованных лиц

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

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

примеров или областей решений, определенных стейкхолдерами;

реализации решений, принятых на более высоком уровне системной иерархии;

требований по использованию определенных обеспечивающих систем, ресурсов и штатного персонала [17].

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

Выводы по главе 1

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

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

ГЛАВА 2. ПРОЦЕСС ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ К РАЗРАБОТКЕ ПО ДЛЯ ИХ ПОСЛЕДУЮЩЕГО АНАЛИЗА

2.1 Стадии разработки программного обеспечения. Место этапа выявления требований

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

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

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

. Итеративная разработка (англ. iteration - повторение) - выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование - Реализация - Проверка - Оценка (англ. plan-do-check-act cycle) [18].

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

Итеративный подход сейчас является наиболее распространенным.

Итеративные методы разработки программного обеспечения делятся в основном на две группы:

) Rational Unified Process (RUP) - методология разработки программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие основные принципы:

Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

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

Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

) Гибкая методология разработки (англ. Agile software development).

Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты).

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

Рисунок 6 - Основные этапы жизненного цикла ПО

Ниже кратко описываются основные особенности каждого этапа.

. Анализ требований к проекту.

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

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

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

При анализе требований определяются сроки и стоимость разработки ПО, формируется и подписывается ТЗ на разработку программного обеспечения. Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки [16].

В целом этап анализа разработки ПО состоит из двух фаз:

) Сбор и выявление требований.

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

. Проектирование.

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

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

. Реализация

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПО (legacy software);

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

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

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

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

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

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

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

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

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

 

Выводы по главе 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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), который сохраняется после выявления требований и используется для создания конечного программного продукта. Эволюционный прототип нацелен на ускорение поставки продукта. Как правило, он концентрируется на ясно изложенных требованиях, так что первую версию продукта можно предоставить заказчику довольно быстро (хотя ее функциональные возможности, как правило, неполны).

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

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

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

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

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

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

Если 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 метода связан ряд проблем; некоторые из них перечислены ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с данным циклом, который чаще всего должен быть пройден несколько раз, определим следующие обобщенные шаги действий при выявлении требований, описанные на рисунке 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, а также, такие привычные способы моделирования, как Процесс и Процедура.- Function Modeling - методология функционального моделирования. С помощью наглядного графического языка Idef0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах Idef0). Как правило, моделирование средствами Idef0 является первым этапом изучения любой системы.

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

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

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

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

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

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

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

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

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

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

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

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

) Диаграммы Состояния Объекта в его Трансформации (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

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

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

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

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

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

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

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

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

Каждый бизнес-процесс на нотации может быть декомпозирован (разбит на детальные бизнес-процессы).

Пример блок-схемы представлен на рисунке 13. Возможный инструмент для моделирования: Visio.

Рисунок 18 Пример блок-схемы

Процедура (Cross Functional Flowchart , функциональная блок-схема) - нотация для отображения процесса на нижнем уровне бизнес-модели.

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

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

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

На Процедуре так же могут использоваться решения (условия) для ветвления бизнес-процесса.

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

Рисунок 19 Пример моделирования процедуры

Выводы по главе 3

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Карл И. Вигерс. Разработка требований к программному обеспечению, 2004. : 2-е изд., перераб. и доп. Пер. с англ. - М. : Русская редакция. - 554 c.

. Химонин Ю.И., Сбор и анализ требований к программному продукту, 2009.

. Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML: Пер. с англ. - М.: Вильямс, 2002. - 143 с.

. Бариленко В. И. и др. Основы бизнес - анализа: учебное пособие. / под ред. В. И. Бариленко. - М.: КНОРУС, 2014. - 272 с.

. Бариленко В. И. Бизнес-анализ как важный вид консалтинговых услуг // РИСК: Ресурсы, Информация, Снабжение, Конкуренция. - № 4. - 2012. - С.202-207.

. Конрад Карлберг Бизнес-анализ с использованием Excel. Решение бизнес-задач, 4-е издание = Business Analysis: Microsoft Excel. - М.: «Вильямс», 2013.

. Основы бизнес - анализа: учебное пособие. / под ред. В.И. Бариленко. - М.: КНОРУС, 2013.

. Паклин Н.Б. Орешков В.И. Бизнес-аналитика: от данных к знаниям, 2013.

. Э. Халл, К. Джексон, Д. Дик. Разработка и управление требованиями // Практическое руководство пользователя. - 2-е изд., 2005.

. Г. Буч, Р. Максимчук, М. Энгл, Б. Янг, Д. Коналлен, К.Хьюстон. Объектно-ориентированный анализ и проектирование с примерами приложений,2008. 3-е изд.

. Д. Арлоу, А. Нейштадт. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2008.

ПРИЛОЖЕНИЕ

Графический материал

Рисунок 1 - Отображение графического материала на слайде 1

Рисунок 2 - Отображение графического материала на слайде 2