Особый стиль наращивания возможностей системы и ее развития.

Распределение реализуемых требований по итерациям.

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

Представление системы как набора связанных различными отноше­ниями классов — основа декомпозиции проекта при объектно-ориенти­рованном подходе. Каждая новая итерация расширяет этот набор путем добавления новых классов, вступающих в определенные отношения с ра­нее построенной системой классов. Выполнить такое расширение кор­ректно без абстрагирования от деталей реализации существующего, а ес­ли учитывать перспективу, то и без такого же абстрактного представления добавляемых классов практически невозможно. Иными словами, требу­ется построение моделей уровня конструирования, которые задают реали­зационное представление проектируемой системы.

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

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

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

Следует отметить еще одну модификацию схемы Гантера, отражен­ную на рисунке. В рамках этапа оценки выделен специальный вложен­ный этап — пополнение базового окружения проекта. Смысл его сводится к планированию и реализации пере использования программного обеспе­чения. Любой объектно-ориентированный проект развивается исходя из некоторой уже существующей среды классов и других компонентов. Это базовое окружение проекта интенсивно используется и, в свою очередь, пополняется средствами, возникающими в результате итеративного нара­щивания. Полезность сохранения таких средств для текущего проекта и для последующих разработок очевидна. В связи с этим целесообразно в рамках выполнения этапа оценки производить дополнительную работу, направленную на сохранение полезного в депозитарии проектов.

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

0. Необходимость разработки признана.

Эта точка означает начало работ над проектом, которые еще не ут­верждены как официальный проект. Официальным он становится, когда доказана его осуществимость, задачи проекта в целом обозначены, в том числе определены те задачи, которые предстоит решать в первую очередь (контрольная точка 2). В этот период можно говорить лишь о предпроектной деятельности менеджера. Если схема развития проекта допускает рас­пределение менеджерских обязанностей в команде исполнителей и есть команда, которая принимает решение о целесообразности работ над про­ектом, предпроектная деятельность менеджера становится сферой ответ­ственности команды целиком. Но и при таких схемах эта деятельность может быть персонифицирована, когда предполагаемый менеджер готов взять на себя обязательства, имея в виду свои планы по использованию некоторого сложившегося коллектива, по формированию команды и др. Собственно говоря, один из главных менеджерских вопросов, который нуждается в решении в обсуждаемой контрольной точке, — стратегия и тактика формирования проектной команды.

1. Ресурсы распределены.

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

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

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

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

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

• общие требования— что требуется от проекта в целом в данный мо­мент;

• общий план— как предполагается достигать поставленных целей;

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

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

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

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

3. Системная значимость.Этот критерий отражает внутренние для
проекта предпочтения. В первую очередь целесообразно реализовывать функциональность, которая полезна для развития: заго­товки широкого применения, базовые и инструментальные ком­поненты для других предоставляемых средств системы. С точки
зрения развития проекта решение ближайшей задачи должно
обеспечить осуществимость последующего итеративного наращивания возможностей системы (об этом разговор еще предстоит).
Данный критерий конкурирует с актуальностью для пользователя.
Он является более значимым для начальных итераций проекта.

4. Демонстрационная значимость.С точки зрения этого критерия пер­воочередными считаются те средства, которые в состоянии проде­монстрировать работоспособность и лучшие, выгодные для пока­
за качества системы. Наибольший удельный вес данный критерий
имеет для начального периода развития проекта, причем не толь­
ко для заказчика, но и для разработчиков, которые при соответст­вующей трактовке демонстрационное™ будут в состоянии убе­диться в правильности выбранной стратегии и методов. Критерий
может противоречить и пользовательской актуальности, и функциональной полноте, и системной значимости.

5. Скорость реализации. Поэтому критерию выделяются те виды ра­бот, которые можно реализовать за самое короткое время. Если же
время итерации фиксировано, то для выполнения отбирается пул
работ, которые в состоянии завершить команда в заданные сроки.

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

Критерий полноты следует прокомментировать особо. Различают три аспекта полноты, которые отражают три составляющие качества про­граммной системы [21]:

• функциональная полнота— соответствие предлагаемых средств на­
бору пользовательских функций, которые могут быть активизированы в рамках автоматизируемой деятельности;

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

• интерфейсная полнота— задание языка управления поведением си­стемы, адекватного восприятию системы пользователем.

В обсуждаемом критерии речь идет о функциональной полноте. Функциональная замкнутость означает, что автоматизация деятельности, осуществляемая релизом данной итерации, достигается таким путем, ко­торый не требует от пользователя ничего, что выходит за рамки средств, предлагаемых релизом системы. Эти качества обеспечиваются реализа­ционной полнотой, а на уровне управления поведением системы — ин­терфейсной полнотой. Таким образом, дополнительные критерии не тре­буются: и реализационная, и интерфейсная полнота определяются как производные от функциональной полноты.

Иногда говорят о минимальности того, что должно быть реализовано на итерации для достижения полноты и функциональной замкнутости. Это подчеркивается, например, в подходе экстремального программирования [3].Однако реализационная минимальностьесть качество, которое характе­ризует конкретную методологическую стратегию ведения проекта, а потому на уровень общих для любых методологий критериев ее выносить не стоит.

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

Для ближайшей задачи должны быть определены:

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

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

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

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

В контрольной точке 2 определяется фронт работ проектировщиков подсистем.