Собираемые метрики, используемые методы, стандарты и шаблоны

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

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

Используемые инструменты: система подготовки документов (например, MS Word); электронные таблицы (например, Excel); система автоматизации планирования (например, Project).

Используемые методы и стандарты: процесс организации; мет­рическая программа организации.

Используемые шаблоны: плана проекта; отчета по обзору; от­чета о статусе проекта.

Контрольные вопросы

1. Каково назначение этапа планирования в жизненном цикле разра­ботки программного продукта?

2. Что представляет собой цикл планирования?

3. Объясните цель и назначение структурирования работ.

4. В чем и как измеряются объем и сложность программного продукта?

5. Как выполняется оценка необходимых ресурсов для выполнения, работ?

6. Какие виды рисков вы знаете и как они оцениваются?

7. Объясните назначение временного графика выполнения работ.

8. Какие метрики собирают на этапе планирования?

9. Какие инструменты, методы, стандарты и шаблоны используют! при выполнении этапа планирования?

УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ПРОДУКТУ

Общие сведения об управлении требованиями

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

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

Управление требованиями (requirements management) представ­ляет собой:

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

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

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

достижение соглашения с заказчиком и пользователями о том, что ПП должен делать;

улучшение понимания требований к ПП со стороны разработ­чиков;

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

определение базиса для планирования.

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

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

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

Требование — это условие или характеристика, которой дол­жен удовлетворять ПП. Существуют функциональные и нефунк­циональные требования.

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

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

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

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

требования к реализации — предписывают использование оп­ределенных стандартов, языков программирования, операцион­ной среды и т.д.;

требования к надежности — обусловливают допустимые часто­ту и воздействие сбоев на работу ПП, а также возможности вос­становления ПП после сбоев;

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

Цикл формирования требований

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

Рис. 7.1. Цикл составления требований к программному продукту

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

Анализ и структурирование первичных требований заказчика

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

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

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

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

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

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

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

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

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

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

Описание рекомендуется составлять с использованием приня­той в технической литературе терминологии.