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

План инкрементной поставки — это формальная взаимосвязь между частями трех других артефактов проекта:

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

• иерархическая структура работ (ИСР): сеть задач, которые должны быть выполнены, и их взаимозависимости

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

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

(Здесь мы выдумали абстрактный черновик вместо того, чтобы отдать предпочтение какому-то определенному представлению плана).

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

Процесс, вкратце, таков:

• Версия идентифицируется по рабочему плану.

• Задачи, связанные с этой версией, — это те задачи, завершение которых демонстрируется приемкой версии.

• Приемное испытание для каждой версии — это набор критериев, которым должен удовлетворять продукт, чтобы объявить, что версия завершена.

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

• номер версии

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

• указатель на приемное испытание

• ожидаемая дата приемного испытания завершенной версии

• реальная дата приемного испытания завершенной версии (для заполнения позже)

• список всех работ в ИСР, которые считаются выполненными при завершении версии

• ООФ данной версии (будет рассмотрена в следующем разделе)

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

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

<< | >>
Источник: Том ДеМарко. Вальсируя с Медведями Управление рисками в проектах по разработке программного обеспечения. 2005

Еще по теме План инкрементной поставки:

  1. План Третий шаг: план.
  2. План –
  3. Параграф 3. Поставка
  4. § 3. Договор поставки
  5. 37. План внешнего управления
  6. Статья 712. Договор поставки
  7. § 1. Договор поставки товаров
  8. План:
  9. 3. Заключение договора поставки
  10. 1.3. Договор поставки товаров
  11. Тема: Договір поставки
  12. План
  13. 2. Понятие договора поставки
  14. СОСТАВЬТЕ СЕБЕ ПЯТИЛЕТНИЙ ПЛАН РАЗВИТИЯ
  15. Внутренний план против внешнего плана
  16. Индивидуальный план обучения
  17. 2. Заключение договора поставки.
  18. §2. ДОГОВОР ПОСТАВКИ