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

Иллюстративные и инструментальные модели жизненного цикла

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

Какими качествами должна обладать инструментальная модель? Прежде всего, она должна давать менеджеру полную картину процесса разработки и развития проекта. В этой картине выделяются уровни, предназначенные для организации планирования процесса, в частности для определения графика работ, для выделения и отслеживания их ресурсной обеспеченности. Как следствие должна быть по крайней мере принципиальная возможность перехода от модели жизненного цикла к работам каждого из этапов, доступа к истории развития проекта. Хорошая модель должна позволять видеть текущее состояние проекта и варианты его продвижения вперед. Наконец, если говорить о реальной поддержке деятельности менеджера на основе модели жизненного цикла, то нужно предоставить ему средства декомпозиции процесса разработки, т.е. согласованного с моделью разбиения общих этапов на вложенные этапы и работы. Эти средства следует рассматривать в качестве основного инструмента планирования развития проекта.

Однако реализация столь значительных требований к моделированию жизненного цикла может приводить к потере наглядности модели. Это противоречие в принципе преодолимо в CASE-системах, если бы они строились с ориентацией на определенные типы моделей жизненного цикла. Но чаще всего их разработчики пытаются представлять системы для пользователей как универсальные, на все случаи жизни. А фиксированный тип жизненного цикла препятствует универсальности. В результате обычно в CASE-системах модели жизненного цикла остаются иллюстративными. Так, наиболее популярная сегодня методология RUP [30] (по данным статьи Р. Харитта, 51% программных систем разрабатываются в рамках использования этой методологии [35]) ориентируется исключительно на иллюстративную модель, которая никак не связана с использованием системы моделей UML. Подобное положение занимает и модель жизненного цикла MSF — шаблона проектирования, претендующего на универсальность. Мы еще будем иметь возможность в этом убедиться.

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

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

1. Атрибутивность — с элементами модели связаны определенные атрибуты, необходимые для управления проектом. Эти атрибуты можно задавать или извлекать, т.е. размещать информацию о проекте в некотором хранилище или получать ее из хранилища.
2. Расширяемость — элементы модели допускают пополнение, в результате чего модель становится более детализированной, точнее отражающей реальный процесс. Для модели жизненного цикла расширяемость означает возможность ее достраивания элементами, указывающими на составляющие процесса разработки, т.е. на добавляемые этапы и на продолжения поэтапного дробления процесса на задачи, работы и др.
3. Масштабируемость — возможность увидеть модель с разной степенью детализации, от охвата всего процесса и до конкретной работы.
4. Интегрированность с другими инструментами поддержки. Это качество не самой модели, а CASE-средств, совместно с которыми она используется.

Мера, в которой модели обладают этими свойствами, может служить основой для сравнения их инструментальных возможностей.

Обсудим инструментальность ранее рассмотренных моделей (см. лекции 7–9). За исключением модифицированной модели фазы—функции все они имеют отношение лишь к последовательному развитию проектов, а потому, в принципе, могут применяться в итеративных методологиях лишь фрагментарно, т.е. на уровне отдельной итерации. Схемы, которые мы обсуждали до каскадной модели, претендовали лишь на иллюстративную роль. Поэтому заслуживают внимания лишь строгая каскадная модель и матрица фазы—функции. Обе они могут удовлетворить качеству расширяемости: блоки каскадной модели и линия жизненного цикла вполне пригодны для того, чтобы определять дополнительные самостоятельные и дополнительные вложенные этапы (этому вопросу мы еще уделим внимание). При этом, как было показано в лекции 8 и при построении модифицированной модели Гантера в лекции 9, линия жизненного цикла может расщепляться, создавая основу для отражения технологического параллелизма (см. предыдущий раздел). Атрибутивность матрицы фазы—функции выше каскадной атрибутивности за счет явного выделения функционального измерения. К тому же в каскадной модели не очень наглядно было бы показывать дополнительные атрибуты. Эта модель ориентирована на связи и контроль. Масштабируемость обеих моделей примерно одинакова, однако за счет того, что для каскадной модели существует достаточно много инструментов поддержки в рамках CASE-систем, пусть даже слабо интегрирующих ее с другим инструментарием, можно говорить о ее фактически более развитых средствах масштабирования.