10 лекция

Лекция 10. Технологические аспекты

развития программных систем

в моделях жизненного цикла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Масштабируемость — возможность увидеть модель с разной степе­нью детализации, от охвата всего процесса и до конкретной работы.

4. Интегрированное™ с другими инструментами поддержки. Это ка­чество не самой модели, а CASE-средств, совместно с которыми она используется. Мера, в которой модели обладают этими свойствами, может служить основой для сравнения их инструментальных возможностей.

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

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

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

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

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

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

Распределение времени и контроль над ним — назначение столбцов 2 и 3. В них указываются календарные даты планируемого (столбец 2) и фактического (столбец 3) сроков выполнения работы, задачи или зада­ния. Планируемое начало работы — это самая ранняя дата, после которой можно приступать к выполнению; конец — это предельный срок отчета исполнителей перед менеджером. Иногда графа планируемых сроков до­полняется критическими и целесообразными сроками начала/конца ра­боты. Это позволяет менеджеру более внимательно следить за распреде­лением временных ресурсов.

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

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

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

Календарный план удобен в трех отношениях. Во-первых, его верх­ний уровень рубрикации почти в точности совпадает (должен совпадать) с тем, что составляет предмет рассмотрения технического задания на про­ектирование (в СССР государственные стандарты требовали обязатель­ного включения календарного плана в документы, сопровождающие про­цедуру заключения договора на проведение любых работ [12]). Во-вто­рых, дополнение календарного плана новыми рубриками (строками таб­лицы), в том числе в процессе выполнения проекта, не вызывает трудностей. В-третьих, он достаточно нагляден.

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

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

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

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

Спираль развития

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

Теперь мы покажем, как этот недостаток можно исправить, причем почти без потери инструментальных качеств модели. Новая модель (см. рис. 10.3) исходит из ставшей классической спирали развития Буча, пред­ставленной еще в первом издании его книги в качестве иллюстративной модели [8]. Мы добавляем к ней систему координат «время—предостав­ляемые возможности», в которой размещаем итерации в виде горизон­тальных отрезков и переходы к следующим итерациям в виде вертикаль­но начинающихся линий итеративного зацикливания, которые ведут к началу очередной итерации. Линии, параллельные временной оси, ото­бражают уровни пользовательских возможностей, реализуемых на итера­циях (римскими цифрами обозначены номера итераций). У каждой ите­рации в новой модели указаны стандартные этапы, для обозначения ко­торых используются сокращения, принятые на рис. 10.1.

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

Спираль охвата предметной области

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

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

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

Модель расширения охвата прикладной области совсем не претен­дует на инструментальность. Поэтому обсуждать эти свойства для данной

модели мы не будем.

Инструментальная спиралевидная модель

Спираль, раскручивающаяся от центра, послужила основой для многочисленных вариаций на тему отражения в модели жизненного цик­ла итеративного развития проекта. По-видимому, первым предложил ее Боэм в [33]. В этой и в ряде последующих публикаций Боэм настоятельно рекомендует применять итеративное наращивание и использование прототипирования в качестве базовых методов развития программных про­ектов. По его мнению, эти методы успешно противостоят многим рискам при реализации программных проектов. Риски, итеративное наращива­ние и прототипирование — основа спиральной модели Боэма, один из ва­риантов которой мы приводим на рис. 10.5.