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

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

Требуется выяснить:

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

Этим задачам посвящена данная лекция.

Схемы итеративного развития программных систем в большей степени, чем классические схемы, отражают фактический ход многих реальных проектов. Поэтому вполне закономерно, что именно итеративные жизненные циклы привлекают внимание специалистов. С помощью моделей, отражающих итеративность, описываются полезные свойства процессов разработки программных систем. Мы продемонстрировали это при обсуждении контрольных точек и производственных функций модифицированной модели Гантера (см. лекцию 9). Далее будет показано, как при моделировании отражается возможность параллельного выполнения итераций и какое место эта возможность занимает в арсенале средств менеджера программных проектов. Затем мы обратимся к вопросу о том, в какой мере модели жизненного цикла могут способствовать реальному управлению, и с этой точки зрения рассмотрим ряд общеупотребительных моделей.

Параллельное выполнение итераций

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

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

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

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

Одновременность выполнения разных итераций можно представить в виде схем, показанных на рис. 10.1.

увеличить изображение
Рис. 10.1. Пределы совмещений итераций в проекте. а) Этапы жизненного цикла итерации (привязка к контрольным точкам общей модели указана числами в скобках) б) Три итерации проекта I, II, III, развиваемые одновременно в) Пределы совмещений итераций в проекте

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

Рис. 10.1б демонстрирует три одновременно выполняемые итерации: вторая начинается после завершения программирования первой итерации с таким расчетом, чтобы ее этап программирования начался после окончания тестирования первой итерации. Планирование третьей итерации начинается одновременно с этапом программирования второй итерации.

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

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