Размещено на http://www.allbest.ru/

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

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

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

информатики и радиоэлектроники»

Диссертация

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

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

МЕТОДЫ И СРЕДСТВА ВЫЯВЛЕНИЯ И ПРЕДСТАВЛЕНИЯ ТРЕБОВАНИЙ К РАЗРАБОТКЕ ПО

ПИЩИКОВА Екатерина Сергеевна

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

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

Минск, 2015



СОДЕРЖАНИЕ

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Что ПО должно делать. Примеры:

a) Позволять клиенту оформить заказы и обеспечить их доставку;

b) Обеспечивать контроль качества строительства и отслеживать проблемные места;

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

2. Насколько оно должно быть надежно. Примеры:

a) Работать 7 дней в неделю и 24 часа в сутки;

b) Допускается неработоспособность в течение не более 3 часов в год.

3. Насколько им должно быть удобно пользоваться. Примеры:

a) Покупатель должен легко находить нужный ему товар;

b) Инженер по специальности «строительство мостов» должен легко понимать, как пользоваться системой.

4. Насколько оно должно быть эффективно. Примеры:

a) Поддерживать обслуживание до 10000 запросов в секунду;

b) Время отклика на запрос при максимальной загрузке не должно превышать 3 с;

c) Время реакции на изменение параметров процесса производства не должно превышать 0.1 с;

d) На обработку одного запроса не должно тратиться более 10 MB оперативной памяти.

5. Насколько удобно должно быть его сопровождение. Примеры:

e) Добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;

f) Добавление поддержки нового процесса производства не должно занимать более 24 человеко-месяцев.

6. Насколько оно должно быть переносимо и заменяемо. Примеры:

g) ПО должно работать на операционных системах Linux, Windows XP и Mc OS X;

h) ПО должно работать с документами в форматах MS Word;

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

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

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

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



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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

- Те, кто получает выгоду от существования системы (политическую, финансовую, социальную и т.д.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Остальные -- персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) Анализ требований с учетом последующего проектирования системы.

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

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

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

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