Изделие (версия) снято с производства.

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

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

Одним из существенных моментов адаптивных методологий, который учитывается и при обычном объектно-ориентированном проектиро­вании, является отказ от традиционного постулата о том, что все требова­ния к системе сформулированы заранее. Как указывает М. Фаулер [24], предсказать направление целесообразного развития программного про­екта чаще всего невозможно, а потому следует строить адаптивные про­цессы разработки, что применительно к моделированию жизненного ци­кла вообще и его фазы завершения в частности означает необходимость учета обработки потока внешних требований на всех этапах. Этому воп­росу еще будет уделено внимание, а пока можно считать (как чаще всего и бывает), что требования, поступающие на фазе завершения итерации, рассматриваются как относящиеся к следующим итерациям, т.е. к следующимверсиям системы. В таком случае завершение итерации означает сопровождение программного изделия, а затем — окончание работы с данной версией. Пожелания к развитию проекта в этот период учитыва­ются как требования к последующим (возможно, еще не начатым) итерациям. Окончание проекта рассматривается как отказ от сопровождения всех версий системы. Поучительно сопоставить это положение с тради­ционными подходами к проектированию, когда учет пожеланий к систе­ме в процессе ее эксплуатации чаще всего означает одно: организацию нового проекта (быть может, специального), цель которого — учет новых требований.

Несколько слов о функциональном измерении в модифицирован­ной для объектно-ориентированного подхода матрице фазы—функции. Как было показано выше, целесообразно список технологических функ­ций расширить за счет моделирования. Соответственно, следует опреде­лить в матрице Гантера строку интенсивностей для этой функции. В пред­положении о сохранении распределения интенсивностей других функ­ций (см. рис. 8.2) распределение интенсивности для модифицированной модели жизненного цикла можно задать так, как это сделано на рис. 9.2. На рисунке показан новый вид модели целиком (указаны номера конт­рольных точек жизненного цикла без пояснений).

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

Вариант 1

Объектно-ориентированное проектирование отличается от традиционных подходов тем, что:

□ используется итеративность развития, и функциональность
наращивается в соответствии со сценариями

□ используются традиционные этапы, которые повторяются при
переходе от итерации к итерации

□ в этих подходах предусматриваются различные виды сценариев

□ используются сценарии как основа распределения требований
по итерациям

□ используются модели разных уровней

Что означает критерий системной значимости?

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

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

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

□ оценка сценария с точки зрения необходимости реализации
для него количества поддерживающих системных средств

□ оценка сценария с точки зрения его эффективности для удов­летворения пользовательских потребностей

Главные менеджерские обязанности в проекте в контроль­ной точке "Спецификации реализуемых сценариев соста­влены» — это:

□ распределение работ в коллективе для реализации выбранных
сценариев

□ распределение финансов с целью выделения их для реализа­ции каждого из выбранных сценариев

□ инвентаризация ресурсов и выяснение, хватает ли ресурсов
для реализации выбранных сценариев

□ оформление подготовленных к реализации сценариев для их
утверждения

□ подбор кадров для выполнения реализации выбранных сценариев

Вариант 2

1. Критерии отбора сценариев для реализации — это:

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

□ способ упорядочить предварительно отобранные для реализа­ции сценарии по степени их важности с той или иной точки

зрения

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

□ предпочтение одного сценария другим с той или иной точки
зрения

□ показатели предпочтения разработчиков и заказчиков, по ко­торым оцениваются предварительно отобранные для реализа­ции сценарии

2. Что означает критерий демонстрационной значимости?

□ оценка сценария с позиций возможности показать различные
выигрышные качества проекта и деятельности разработчиков
по его реализации

□ оценка интерфейсных возможностей сценария

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

□ оценка сценария как демонстрирующего надежность выполне­ния проекта в данных условиях

□ то же, что критерий актуальности для пользователя

3. Пополнение базового окружения проекта — это:

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

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

□ процесс создания компонента программного обеспечения, для
которого планируется переиспользование

□ организация процесса включения программного компонента в
депозитарий проекта

Вариант 3

1. Ближайшая задача проекта — это:

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

□ задача текущей итерации

□ набор функций, реализуемых в текущей итерации, и ограниче­ния, которым реализация должна удовлетворять

□ подготовка и выполнение очередной итерации

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

2. Различия между критерием и ограничением с точки зре­ния задачи отбора сценариев для реализации состоят в
том, что:

□ критерии служат для упорядочения сценариев по степени
предпочтения для выбора, тогда как ограничения задают условия, нарушение которых запрещает выбор

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

□ это, по сути, одно и то же

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

3. Расщепление линии жизненного цикла при итеративном
наращивании приводит:

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

□ к приостановке выполнения текущей итерации и организации
работ над новой итерацией с целью реализации дополнитель­ной функциональности версии системы

□ к приостановке выполнения текущей итерации и организации
работ над новой итерацией с целью исправления обнаружен­ных ошибок в версии системы

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