«Как движется работа над той подсистемой, Джеки», — спросил Дейв.
«Довольно хорошо, Дейв. Готово около 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. Контроль состояния требований для цикла разработки проекта