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

Классификация требований

Существует значительное количество различных методов классификации требований [2.2-2.7], наиболее существенные из которых будут рассмотрены в лекции.

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

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

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

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

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

1. Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure - WBS) с точностью до конкретных исполнителей.
2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонент разрабатываемого продукта и тестирование продукта в целом.
3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

Дата добавления: 2014-11-29