Лекция 9: Моделирование объектно-ориентированного жизненного цикла программных проектов

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

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

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

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

1. Актуальность для пользователя. С точки зрения бизнеса важно, чтобы в первую очередь в рабочем продукте предоставлялась функциональность, которая позволила бы устранить узкие места автоматизируемой деятельности. Этот критерий практически всегда рассматривается как наиболее существенный.
2. Полнота и функциональная замкнутость предлагаемых средств. Связан с предыдущим критерием. С его точки зрения, отбирается для реализации такой комплект средств системы, который автоматизирует какой-либо вид пользовательской деятельности в полной мере, не требуя чего-то еще. Важность критерия растет по мере увеличения объемов уже выполненных в проекте работ (обсуждение критерия см. ниже).
3. Системная значимость. Этот критерий отражает внутренние для проекта предпочтения. В первую очередь целесообразно реализовывать функциональность, которая полезна для развития: заготовки широкого применения, базовые и инструментальные компоненты для других предоставляемых средств системы. С точки зрения развития проекта решение ближайшей задачи должно обеспечить осуществимость последующего итеративного наращивания возможностей системы (об этом разговор еще предстоит). Данный критерий конкурирует с актуальностью для пользователя. Он является более значимым для начальных итераций проекта.
4. Демонстрационная значимость. С точки зрения этого критерия первоочередными считаются те средства, которые в состоянии продемонстрировать работоспособность и лучшие, выгодные для показа качества системы. Наибольший удельный вес данный критерий имеет для начального периода развития проекта, причем не только для заказчика, но и для разработчиков, которые при соответствующей трактовке демонстрационности будут в состоянии убедиться в правильности выбранной стратегии и методов. Критерий может противоречить и пользовательской актуальности, и функциональной полноте, и системной значимости.
5. Скорость реализации. По этому критерию выделяются те виды работ, которые можно реализовать за самое короткое время. Если же время итерации фиксировано, то для выполнения отбирается пул работ, которые в состоянии завершить команда в заданные сроки.

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

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

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

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

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

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

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

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

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

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