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

«Как движется работа над той подсистемой, Джеки», — спросил Дейв.

«Довольно отлично, Дейв. Готово около 90%».

Дейв был озадачен: «А разве пару недель вспять ты не сделала приблизительно 90%?»

Джеки ответила: «Я задумывалась, что да, но сейчас эти 90% вправду готовы».

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

Ловушка Существует древняя шуточка, что на первую половину проекта по разработке тратится 90% ресурсов, а на остальную половину — оставшиеся 90% ресурсов. Очень оптимистичная оценка и попустительское Контроль статуса требований отношение к контролю статуса верный путь к перерасходам в проекте.

В таблице 18-1 перечислено несколько вероятных состояний требований. (Другая схема показана в Caputo, 1998.) Некие спецы добавляют состояние Designed (Создано) (если элементы проектирования, в каких отражены многофункциональные требования, сделаны и испытаны) и Delivered (Выпущено) (ПО отдано в руки юзеров, как Контроль статуса требований для бета-тестирования).Полезно выслеживать требования, от которых вы отказались,и предпосылки этого, так как отвергнутые требования имеют обыкновение «всплывать» в процессе разработки. Статус Rejected (Отклонено)позволяет бросить предложенное требование легкодоступным для грядущего использования, не создавая кавардака в наборе утвержденных требований для определенного выпуска.

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

Таблица 18-1. Рекомендуемые состояния требования

Состояние Определение
Proposed (Предложено) Требование запрошено авторизированным источником
Approved (Одобрено) Требование проанализировано, его воздействие на проект просчитано, и оно было расположено в базисной версии определенной версии. Главные заинтригованные в проекте лица согласились с этим требованием, а разработчики ПО обязались воплотить его
Implemented (Реализовано Контроль статуса требований) Код, реализующий требование, разработан, написан и протестирован. Требование отслежено до соответственных частей дизайна и кода
Verified (Испытано) Корректное функционирование реализованного требования доказано в соответственном продукте. Требование отслежено до соответственных вариантов тестирования. Сейчас требование считается завершенным
Deleted (Удалено) Утвержденное требование удалено из базисной версии. Опишите предпосылки удаления и назовите того, кто Контроль статуса требований принял это решение
Rejected (Отклонено) Требование предложено, но не запланировано для реализации ни в какой будущих версий. Опишите предпосылки отличия требования и назовите того, кто принял это решение

На рис. 18-2 показано, как держать под контролем состояние требования в гипотетичном 10-месячном проекте: на графике показано, сколько процентов Контроль статуса требований требований к системе в каждом состоянии имеется в кон не каждого месяца. Направьте внимание, что при всем этом не устанавливается, меняется ли с течением времени количество требований в базисной версии. Кривые иллюстрируют, как достигается такая цель проекта, как полная проверка всех утвержденных требований. Основная часть работы считается выполненной, когда Контроль статуса требований всем требованиям назначено состояние Verified (Испытано) (реализуется, как запланировано) либо Deleted (Удалено) (удалено из базисной версии).

Рис. 18-2. Контроль состояния требований для цикла разработки проекта


kontrolnaya-po-logike-v-zadachah-referat.html
kontrolnaya-po-teletrafiku-referat.html
kontrolnaya-posle-fizkulturi-referat.html