Модели жизненного цикла программного обеспечения (стр. 8 )

Рис. 14. Схема трансформации требований

Иерархия типов требований представлена на рисунке следующим образом. Верхний уровень — это абстрактный тип, свойства которого присущи требованиям всех типов (они сводятся к стандартизованному набору операций объединения, пересечения атрибутов, сравнения значений атрибутов и др.). Можно сказать, что Т абстр задает регламент, которого следует придерживаться при оперировании с требованиями. Следующий уровень содержит четыре обязательных типа: Т экон, Т функ, Т инт и Т эфф, которые объединяют требования экономического характера (пределы стоимости, рентабельность и пр.), функциональные требования, требования к интерфейсу и эффективности. Многоточием обозначены типы, которые, добавляются из-за специфики проекта. Т a ( a 1,…, an a ), Т b ( b 1,…, bn b ), Т c ( c 1,…, cn c ), …, Т z ( z 1,…, zn z ) — это конкретные типы, к которым приписываются элементарные составляющие требований (в скобках указаны их атрибуты).

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

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

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

3.3. Учет трассировки требований в модели жизненного цикла

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

  Требование или группа требований обрабатываются до начала работ над итерацией;

  Требование или группа требований поступают, когда работы итерации начались.

Первый вариант полностью укладывается в схему модифицированной модели фазы — функции (рис. 9, 10). Если требование (группа требований) принимается для данной итерации и используется при разработке сценария, который будет реализовываться (контрольные точки 2, 8), то указанные на схеме трассировки работы включаются в аналитическую и конструкторскую деятельность. В противном случае оно либо откладывается до последующих итераций, либо отклоняется.

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

  требование отклоняется — работа с требованием прекращается;

  требование принимается к реализации на текущей итерации;

  реализация требования откладывается до следующих итераций.

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

Рис. 15. Фазовое измерение модели жизненного цикла при объектно-ориентированном развитии проекта, дополненное обработкой требования в мини-цикле

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

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

3.4. Особенности первой итерации

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

Первую итерацию обычно характеризует следующее.

  Разработчики еще не достигли достаточно глубокого понимания проблем предметной области, ее приоритетов и критериев.

  Круг инициаторов работ, а значит, потенциальных консультантов сформировался далеко не окончательно. Следовательно, есть опасность начать делать не ту систему.

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

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

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

  Часто разработчики в начале проекта не вполне владеют методами, инструментами и т. п., как следствие, работа на первой итерации имеет учебный аспект.

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

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

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