Функции программного продукта.

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

4. Пользовательские характеристики.

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

5. Общие ограничения.

Содержит общее описание элементов, ограничивающих действия разработчиков:

• аппаратные ограничения;

• интерфейсы с другими приложениями;

• функции контроля;

• требования к языку и т.д.

Стандарт IEEE 830-1998 предполагает несколько способов структурирования функциональных требований. Требования могут быть организованы при помощи следующих классификаций.

1. По основным свойствам. Предоставляемые программой сервисы определяются с помощью пар «стимул – реакция».

2. По режиму работы, например, демонстрационный, нормальный или аварийный режимы;

3. По вариантам использования, или сценариям. Особенность такой организации требований в том, что наиболее подробные требования являются частью варианта использования;

4. По классам. В этом объектно-ориентированном способе требования классифицируются по классам.

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

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

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

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

В настоящее время наиболее востребован объектно-ориентированный стиль проектирования. В этом случае обычно используется организация требований по классам.

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

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

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

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

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

Рис. 5.2

В литературе [1, 4, 6, 9, 10] приведено большое число шаблонов спецификации требований. Например [10], шаблон, в котором интерфейсные требования привязаны к отдельным функциональным требованиям или шаблон, где все требования определены в связи с отдельными функциональными требованиями.

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

5.5.Вопросы для самоконтроля

1. Какая информация вносится в спецификацию требований?

2. Кто основные читатели спецификации?

3. Какие рекомендации по документированию требований должны быть выполнены?

4. Зачем разрабатываются шаблоны спецификации?

5. От чего зависит тип применяемого шаблона?

6. На основе каких стандартов разрабатываются шаблоны?

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

8. В чем особенности организации требований по классам?

6.Анализ спецификации требований

6.1.Оценка качества спецификации требований

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

6.1.1.Характеристики качества спецификации

Рассмотрим характеристики качества, предъявляемые к документу спецификация требований:

• полнота, согласованность,

• способность к модификации

• трассируемость.

Полнота и согласованность

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

Способность к модификации

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

Трассируемость

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

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

6.1.2.Аттестация требований

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

• экспертиза спецификации,

• прототипирование,

• автоматизированный анализ.

6.2.Экспертиза спецификации

Экспертиза спецификации [4, 7] требований позволяет эффективно выявить неполные и некорректные требования, требования неясные или неподдающиеся проверке, несогласованные и не тестируемые требования.

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

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

Рис. 6.1

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

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

Рис. 6.2

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

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

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

Для организации помощи экспертам в проведении экспертизы спецификации требований разрабатываются контрольные списки дефектов [4]. На рис. 6.2. приведен список дефектов для варианта использования. Список содержит вопросы, на которые должен ответить эксперт при проведении анализа. Списки могут изменяться, сообразуясь с требованиями проекта. Если список велик, то его можно разбить на подсписки, которые эксперты будут использовать при подготовке.

Проблемы при просмотре требований

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

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

6.3.Прототипирование

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

6.4.Автоматизированный анализ

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

6.5.Тестирование требований

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

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

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

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

Рис. 6.3

Пунктирными линиями здесь соединены этапы, которые нужно рассматривать параллельно [10]. Остановимся на первых двух связях.

Требования к проекту и планирование

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

Требования к продукту и анализ спецификации

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

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

6.6.Вопросы для самоконтроля

1. Какие характеристики определяют качество спецификации?

2. Как определяется полнота и согласованность требований?

3. Почему важны способность к модификации спецификации и трассируемость требований?

4. Что такое экспертиза спецификации? Почему этот процесс должен быть документирован?

5. Каковы основные роли участников экспертизы?

6. Чем тестирование требований отличается от аттестации?

7. Что определяет критерий приемлемости?

8. Кто должен разрабатывать тесты приемочных испытаний?

7.Управление требованиями

7.1.Причины изменений требований

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

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

• понимание пользователями возможностей системы, решаемых ею задач, может измениться;

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

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

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

С точки зрения разработки требования можно разделить на два класса:

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

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

Рис. 7.1

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

• увеличиваются затраты на разработку за счет, например, привлечения дополнительных специалистов или сверхурочной работы;

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

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

7.2.Принципы управления требованиями

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

К действиям по управлению требованиями относятся:

1. Определение основной (базовой) версии спецификации требований для конкретной версии продукта;

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

3. Включение одобренных изменений при помощи определенной процедуры;

4. Согласование плана проекта с требованиями;

5. Отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

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

Базовая версия требований

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

Процесс управления требованиями

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

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

• процесс разработки, согласования, экспертизы и утверждения базовой версии;

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

• процесс передачи новых требований и изменений существующих требований заинтересованным лицам;

• методы анализа влияния и стоимости внесения изменения.

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

Контроль версий

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

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

Идентификация отдельных требований

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

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

Статус требования

В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Статус требований позволяет оценить степень готовности проекта. В [4] рекомендуют использовать состояния требования, приведенные в табл. 7.1.

Таблица 7.1.

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

7.3.Управление изменениями

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

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

1. Все изменения должны вноситься в соответствии с документированным и утвержденным процессом. Неофициальные запросы на изменение не рассматриваются. Запрос на изменение не гарантирует его выполнение. Текст запроса не должен изменяться или удаляться.

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

3. Реализовывать неутвержденные изменения запрещено.

Диаграмма переходов состояний для типового процесса внесения изменений в спецификацию требований приведена на рис. 7.2.

Рис. 7.2

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

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

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

Описание процесса контроля изменений должно содержать:

1. Границы применения процесса. Должны быть перечислены те продукты или изменения, которые не принадлежат процессу.

2. Роли и ответственность. Должны быть определены члены проекта (роли), участвующие в контроле изменений и их ответственность.

3. Описание процедуры прохождения запроса на изменение.

4. Описание процедур анализа и оценки запроса на осуществимость, влияния и стоимости изменения, принятия решения и изменения состояния запроса.

Стоимость внесения изменения в требования сильно зависит от фазы жизненного цикла, на котором находится система и может быть очень велика [1, 4, 10], поэтому принятие решения об изменении – достаточно сложная и ответственная проблема. Лучшее практическое решение этой проблемы – совет по управлению изменениями [4]. Совет по управлению изменениями – это небольшая группа людей, принимающая решение о том, какие предлагаемые изменения требований, новые функции, интерфейс будут включены в продукт. Для эффективной работы совет должен иметь утвержденные структуру, полномочия и рабочие процедуры (устав).

7.4.Управление версиями

Следующая функция, направленная на поддержание целостности, точности и актуальности спецификации требования – это управление версиями спецификации.

Управление версиями требует выполнения следующих видов деятельности:

1. Определение конфигурации требований: именование отдельных требований и версий спецификации.

2. Определение состава версии спецификации.

3. Управление процессом внесения изменений.

4. Хранение истории каждой версии спецификации, содержащей сведения о внесенных изменениях.

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

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

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

7.5.Управление связями требований

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

Трассируемость требований позволяет решить следующие задачи.

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

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

3. Упростить внесение изменения на поздних фазах проектирования, а также фазе эксплуатации и сопровождения продукта.

4. Зафиксировать опыт проектирования, упростить повторное проектирование и повторное использование.

5. Упростить поиск, локализацию и исправление ошибок при тестировании.

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

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

Матрица трассируемости требований

Трассирование требований – это определение связей между требованием и другими артефактами проекта. Такая информация обычно представляется в виде матрицы [1, 4]. На рис. 7.3 приведен один из возможных форматов такой матрицы.

Рис. 7.3

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

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

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

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

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

7.6.Риски, связанные с требованиями

Риск отражает возможные потери при выполнении программного проекта, которые оказывают на него негативное влияние. С каждым из этапов разработки требований связаны свои риски. В [4, 6] рассматриваются вопросы управления рисками их отслеживание и контроль. Приведем основные риски, связанные с требованиями.

7.6.1.Риски этапа выявления требований

7.6.2.Риски этапа анализа и спецификации требований

7.6.3.Риски управления требованиями

7.7.Вопросы для самоконтроля

1. Перечислите несколько причин изменения требований.

2. Чем отличаются постоянные и изменяемые требования?

3. Перечислите основные функции по управлению требованиями.

4. Что такое базовая версия требований?

5. Для чего используются атрибуты требований? Назовите несколько атрибутов и обоснуйте их выбор.

6. Что такое статус и состояние требования?

7. Кто принимает решение о внесении изменений в требования?

8. Какие задачи позволяет решить трассируемость требований?

8.Case-средства для управления требованиями

8.1.Выбор case-средств для управления требованиями

Как было уже замечено документальное хранение требований весьма трудоемко и имеет много недостатков, основные из которых – это трудности:

• во внесении изменений, поддержке непротиворечивости и актуальности документов;

• в хранении атрибутов, управлении статусом требований;

• в управлении версиями и т.д.

Поэтому использование инструментальных средств является необходимым условием успешности выполнения проекта. Средства автоматизации и поддержки, используемые в процессе разработки программных систем, принято называть CASE-средствами (Computer-Aided Software Engineering). Нас интересуют средства, которые можно использовать на этапе разработки и анализа требований к программной системе, т.е. средства, поддерживающие: выявление и документирование требований пользователей, разработку системных требований, анализ требований и управление требованиями.

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

• при определении заинтересованных лиц, пользователей системы;

• при выявлении и сборе требований.

CASE-средства не могут заменить «ручные» методы выявления требований.

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

8.2.Уровень зрелости и используемые инструменты

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

• имеются четко определенные процедуры создания программного продукта и управления программными проектами;

• оценки времени и стоимости выполнения работ основываются на накопленном опыте;

• существуют стандарты на процессы разработки, кодирования, тестирования, внедрения и сопровождения продукта.

Модель зрелости способностей предприятий в области разработки программного обеспечения (Capability Maturity Model for Software – CMM) определяет уровни зрелости, характеризующей способности коллектива к разработке программного продукта.

В модели CMM различают пять уровней зрелости (наивысшим из которых является пятый) и насчитывается 24 ключевые области процесса, которые распределены по уровням зрелости. Ключевые области процесса – это основные компоненты способностей предприятия по разработке программ. Напомним особенности первых трех уровней.

Уровень 1. Начальный (Initial)

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

Уровень 2. Управляемый (Managed)

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

Уровень 3. Определенный (Defined)

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

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

На втором уровне зрелости определены следующие ключевые области:

1. Управление требованиями (Requirements Management) – обеспечение возможности установления единого с заказчиком понимания требований к разрабатываемому продукту.

2. Управление конфигурацией (Configuration Management) – установление и поддержка целостности всех продуктов проекта или процесса за счет обеспечения единой системы идентификации компонентов продукта, контроля над изменениями и управления изменениями компонентов.

Третий уровень характеризуется включением ключевой области:

Разработка требований (Requirements Development)» – разработка и анализ требований заказчика, требований к программному продукту и отдельным его компонентам.

Для обеспечения данных ключевых областей перечислим [6] следующие специфические типы инструментов:

• моделирование требований;

• трассировка требований;

• управление версиями.

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

Таблица 8.1

8.2.1.Моделирование требований

Инструментальные средства управления требованиями можно разделить на две категории: моделирование и трассировку. Инструменты моделирования позволяют, используя графические средства, описать модель требования, а затем по определенным (в инструменте) правилам выполнить его структурное или объектно-ориентированное моделирование. Минимальный набор инструментов моделирования состоит из графического пакета Visio, позволяющего построить различные, например, IDF или UML модели требований, и базы данных Access, хранящей структурную информацию требований.

8.2.2.Трассировка требований

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

8.2.3.Управление версиями

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

8.3.Возможности case-средств управления требованиями

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

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

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

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

8.3.1. Средства idf-моделирования

Совокупность методик и моделей концептуального проектирования IDEF (Integrated DEFinition) была разработана в США. В настоящее время имеются методики функционального, информационного и поведенческого моделирования, в которые входит достаточно большое число моделей. Например:

1. IDEF0 – функциональное моделирование. Реализует методику функционального моделирования сложных систем, основой которой является методология SADT (Structured Analysis and Design Technique).

2. IDEF2, IDEF3 – поведенческое моделирование, или моделирование деятельности. В основе лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, конечные автоматы.

Перечисленные методики относятся к структурным методам.

Platinum BPwin

Platinum BPwin – это наиболее распространенный пакет, поддерживающий технологию моделирования IDEF. В него включены три методологии моделирования: функциональное моделирование (IDEF0), описание бизнес-процессов (IDEF3) и диаграммы потоков данных (DFD).

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

BPwin позволяет печатать диаграммы и строить отчеты по моделям. Определено большое число стандартных отчетов, например:

• отчет по диаграммам, который включает информацию об объектах в активной диаграмме;

• отчет о связях в модели;

• отчет об объектах диаграммы, содержащий информацию об объектах, размещенных на диаграмме (функциональных блоках, хранилищах данных и внешних ссылках);

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

Более подробное описание пакета BPwin и его применения для моделирования (требований) можно найти в [5].

8.3.2.Средства uml

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

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

Rational Rose

Пакет Rational Rose – мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Модель Rose [2] поддерживает четыре представления: представление вариантов использования, логическое представление, представление компонентов и представление размещения.

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

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

Together

Программный пакет Together позволяет:

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

2. Строить диаграммы видов деятельности, связанные с требованиями, представленными диаграммами использования или свойствами.

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

В основе Together лежат следующие идеи:

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

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

3. Автоматизация рутинных операций.

4. Постоянный контроль качества. Аудит позволяет проверить соответствие стандартам, используя встроенные правила или формулируя свои правила контроля. Применяя метрики, определенные в Together, можно провести количественный анализ исходного кода.

Достаточно подробное описание Together и его использование в процессе разработки программных систем можно найти в [6].

8.4.Вопросы для самоконтроля

1. Какие недостатки имеет документальное хранение требований?

2. Почему используются CASE-средства управления требованиями?

3. Отчего зависит внедрение автоматизации в процесс управления требованиями?

4. Какие ключевые области процесса, которые определены для разработки требований и на каком уровне зрелости?

5. Какие типы инструментов используются для обеспечения данных ключевых областей?

6. Какие инструменты поддерживают модели концептуального проектирования IDEF ?

7. Что представляет собой пакет Rational Rose?

8. Какие идеи лежат в основе пакета Together?

Список литературы

1. Брауде Э. Технология разработки программного обеспечения. – Спб.: Питер, 2004.

2. Боггс Уэнди. UML и Rational Rose 2002 – М.: Лори-Пресс , 2004

3. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000.

4. Вигерс К. Разработка требований к программному обеспечению /Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2004.

5. Дубейковский В. И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? – М.: ДИАЛОГ-МИФИ, 2004.

6. Кармайкл Э., Хейвуд Д. Быстрая и качественная разработка программного обеспечения : Пер. с англ. – М.: Издательский дом «Вильямс», 2003.

7. Коберн А. Современные методы описания функциональных требований к системам. – М.: Издательство “Лори”, 2002.

8. Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.: Питер, 2004.

9. Соммервилл И. Инженерия программного обеспечения, 6-ое издание. : Пер. с англ. – М.: Издательский дом «Вильямс», 2002.

10. Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. : Пер. с англ. –М.: Издательский дом «Вильямс», 2003

45