часть 2

И. Н. Скопин

3. Требования к программному изделию
и жизненный цикл

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

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

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

3.1. Проблемы определения и анализа требований

В наиболее общем виде понятие требований сводится к следующим двум аспектам, фиксируемым для выполнения конструкторских работ:

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

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

Основные проблемы управления требованиями, с которыми приходится сталкиваться при их анализе, сводятся к следующему.

• Требования имеют много источников.

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

• Требования не всегда очевидны.

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

• Требования не всегда легко выразить словами.

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

• Существует множество различных типов требований и различных уровней их детализации.

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

• Требования чаще всего взаимосвязаны и взаимозависимы, иногда противоречивы.

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

• Требования всегда уникальны.

  При формулировке требований как регламента разработки всегда должны быть найдены свойства или значения свойств, по которым они различаются: не существует двух равнозначимых требований. Это не так, если рассматривать исходный материал для требований. Тем не менее, не следует сразу отбрасывать некоторое новое требование только по причине того, что оно кажется похожим на ранее рассмотренные. Необходимо проанализировать, какие дополнительные стороны оно характеризует, и выявить аргументированный ответ на вопрос, действительно ли данное требование является новым. По существу, утверждение об уникальности требований означает то, как они должны быть представлены в проекте в результате анализа (требование к требованиям);

• Набор требований чаще всего является компромиссом.

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

• Требования изменяются.

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

• Требования зависят от времени.

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

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

3.2. Трассировка требований

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

Любое предложение по развитию конструируемой системы может быть классифицировано как требование одного их трех видов:

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

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

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

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

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

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

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

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

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

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

Рис. 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 выделены пунктиром). Постулируется, что все они обрабатываются в четыре этапа:

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

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

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

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

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

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

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

Большинство требований на уровне анализа выражается в виде сценариев, которые надо реализовывать на данной итерации. Это в полной мере относится и к первой итерации. Но здесь исходный комплект сценариев играет две дополнительные роли:

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

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

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

Суть метода состоит в том, что разработка первой итерации проводится мини-циклами реализации выбираемых сценариев. Используется два критерия отбора сценариев для мини-циклов:

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

Полнота базового набора требований в методе «Сначала в глубину» достигается за счет анализа последовательно выполняемых мини-циклов для выделенных сценариев. Если в какой-то момент обнаруживается, что для полноты необходимо расширение исходного комплекта сценариев, то комплект пополняется.

На рис. 16 представлена еще одна модификация гантеровской модели жизненного цикла, отражающая развитие работ на первой итерации методом «Сначала в глубину». Модель модифицирована в следующих отношениях.

• По сравнению со стационарным периодом время, отводимое для анализа и конструирования, существенно увеличивается за счет этапа программирования (конкретные временные соотношения зависят от особенностей выполняемого проекта и от условий его выполнения).
• На общей части этапов анализа и конструирования (контрольные точки 2, 3) выделяется явно работа по определению и утверждению базового набора требований и сценариев для реализации (группа сценариев обозначена овалом с внутренними незакрашенными кружками). Таким образом, появляется контрольная точка 2'6
• Этапы анализа и конструирования для выбранных сценариев выпол-няются совместно (жирная стрелка между овалами). В результате строятся модели сценариев (контрольная точка 3?, модели обозначены закрашенными кружками), которые рассматриваются в качестве исходных данных для спецификации реализуемых компонентов (контрольная точка 5).

Рис. 16. Фазовое измерение модели жизненного цикла при
объектно-ориентированном развитии проекта
методом «Сначала в глубину»

• Для каждого из сценариев образуется мини-цикл его разработки. Разработка мини-циклов включает в себя перекрывающиеся этапы автономной работы и интеграции сценариев (контрольные точки 3?, 5?? и 5?, 7).
• Фиксируется событие готовности результатов всех мини-цик­лов (контрольная точка 5??), которое означает завершение формирования базового набора требований.
• Интеграция сценариев предполагает ревизию (возможно и переписывание кода, и даже перепроектирование реализации каких-либо из сценариев). Она должна быть закончена к началу этапа пополнения базового окружения проекта в рамках оценки (контрольная точка 7).
• Вместо подготовки к распространению системы для прикладного использования проводятся демонстрационные испытания, после завершения которых (контрольная точка 9) осуществляется переход к следующей итерации.
• Прерывания процесса выполнения первой итерации для обработки дополнительных требований не допускаются. По существу это означает, что остается единственный вариант работы с такими требованиями: откладывание их анализа и реализации до последующих итераций .

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

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

3.5. Фаза завершения

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

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

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

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

Рис. 17. Модель обработки требований в период эксплуатации системы

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

• Поступление сообщения (контрольная точка (a)).
• первичный анализ , в ходе которого из сообщения извлекаются требования. Этот период должен быть максимально кратким, ибо пользователю необходимо знать о реакции разработчиков на его сообщение. Результатом первичного анализа является принятие решения о требовании (контрольная точка ( b ), в которой происходит расщепление линии жизненного цикла). Возможны следующие не взаимоисключающие друг друга варианты такого решения:
  • немедленная реакция — действия, направленные на быстрое устранение замечания, если это возможно, либо указание пользова-телю сроков, когда и как будут учтены поступившие претензии, либо указание пути преодоления трудностей (возможно, времен-ные). Немедленная реакция выполняется всегда, в том числе со-вместно с другими решениями;
  • требование отклоняется — действия, указывающие пользователю причины отклонения требований и пути преодоления трудностей;
  • реализация требования в текущей версии — если претензии обоснованы, а устранение замечаний, ошибок и т.п. возможно в рамках обслуживаемой версии, то организуется мини-цикл обработки требований в итерации;
  • реализация требования в одной из следующих версий — если устранение замечаний в рамках обслуживаемой версии невозможно или нецелесообразно, то требование передается для исполнения на одной из следующих итераций проекта;
  • реализация требования в другом проекте — если выясняется, что в данном проекте требование реализовать невозможно или нецелесообразно, то, быть может, оно станет одним из аргументов в пользу организации нового проекта.
• Мини-цикл обработки требования начинается с анализа, цели которого обычны для объектно-ориентированного развития проектов. В част-ности, определяется осуществимость реализации на данной итерации или целесообразность переноса ее на другую итерацию, образуется группа требований, которые должны быть реализованы совместно. Выработка этих решений о стратегии реализации требований приуро-чивается к контрольной точке (c). Особенностью анализа в данном случае является то, что он проводится, как возобновленный процесс, так как основные работы итерации уже выполнены.
• р еализация отобранных требований на данной итерации осуществляется по обычной схеме, включающей конструирование и программирование и оценку. В качестве специфики следует указать на особую роль проверочных работ — дополнительный этап проверки реализации , который вкладывается в этап оценки. Эти работы обязательно должны включать повторение проверки того, что было отлажено ранее. Таким образом, пополнение базового окружения проекта приобретает дополнительное содержание: накопление тестовой базы проекта.
• р аспространение изменений (контрольная точка 10) — деятельность, направленная на то, чтобы сделанные исправления стали доступны для всех пользователей обслуживаемой версии. При массовом использовании программного изделия эта работа может потребовать значительных ресурсов.

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

Заключение

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

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

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

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

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

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

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

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

Но, несмотря на это и другие влияния, стадия комплексной автоматизации технологий программирования стала возможной только при соответствующем уровне развития техники, который позволил эффективно применять выразительные графические возможности при выполнении технологических процедур конструирования программного обеспечения. Немаловажным обстоятельством, позволившим перейти к комплексной автоматизации, стало осознание того, что нельзя говорить реально о промышленном программировании без поддержки технологических функций на всех этапах жизни программ. Примерно в начале девяностых годов появился термин — CASE -тех­нология ( Computer Added Software Engineering — компьютерная поддержка разработки программ), которым стали обозначать использование систем, обладающих комплексными автоматизированными средствами поддержки разработки и сопровождения программ.

Замечено, что, впрочем, вполне объяснимо, что наиболее удачным оказалось использование CASE -систем в тех специальных областях, в которых уже были успехи и опыт технологичной практической работы, пусть даже лишь на организационном уровне, а также в тех случаях, когда специальная область уже была обеспечена надежной теоретической базой. В первую очередь здесь следует упомянуть о CASE -системах разработки баз данных в развитых реляционных СУБД (к примеру, Oracle Designer 2000 в системе Oracle ). Успехи CASE -систем общего назначения скромнее, скорее всего по причине отсутствия универсальных методов, пригодных для развития любых проектов. Поскольку представление о модели жизненного цикла всегда является основой технологии, это еще раз подтверждает правомерность построения разнообразных моделей.

Сегодня универсальные CASE -системы строятся из расчета не всеобщего назначения, а в рамках применения развитых, но все-таки специальных методологий. Несомненный прогресс в данной сфере достигнут для проектирования, ориентированного на моделирование на этапах анализа и конструирования. В рамках объектно-ориентирован­ного подхода разработан специальный унифицированный язык моделирования UML ( Unified Modeling Language ), который рассматривается как основа проектирования в методологии итеративного наращивания возможностей объектно-ориентированных программных систем. На базе этого языка построен ряд CASE -систем общего назначения с весьма развитыми средствами. Наиболее заметной из них является Ration Rose фирмы Ration Software , предложившей на рынок не только инструментарий для использования UML , но и комплексную методологию производства систем — Ration Unified Processing ( RUP ). Данная методология претендует на охват всех аспектов технологий современного программирования. Не вдаваясь в детали того, насколько эти претензии обоснованы, уместно отметить, что в качестве CASE -сис­те­мы Ration Rose обладает множеством средств, очень полезных для поддержки связи первых этапов проектирования с этапом составления программ (кодирования), а также с этапом оценки. В частности, проверяется, что моделирование на разных этапах согласовано, что модельные соглашения, определения классов, других элементов моделей и их взаимосвязи непротиворечивы. Уровень автоматического анализа высок настолько, что позволяет строить по моделям так называемые реализации по умолчанию. Это заготовки программного кода, включающие в себя описания классов и их методов в том виде, который можно извлечь из моделей. Программист дополняет заготовки фрагментами, детализирующими конкретную реализацию.

Построение реализации по умолчанию — не нововведение Ration Rose . До этой системы оно активно применялось и в рамках систем визуального программирования, и еще раньше в специализированных CASE -системах, используемых, например, в развитых СУБД. Последнее примечательно: именно для СУБД удалось связать реализацию по умолчанию с графическими моделями информационных систем ( ER -диаграммы). В Ration Rose и других UML CASE -системах поддерживается построение реализаций по умолчанию по моделям общего, а не специального назначения.

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

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

Вопросы, которые затрагивались в настоящей работе, освещены в многочисленных публикациях, посвященных технологии программирования. Не все из них выдержали испытание временем. В этой связи в качестве приятного исключения можно указать на работу Ф. Брукса « The Mythical Man - Month . Essay on Software Engineering » (русский перевод первого издания, вышедшего в 1975г., см. в [1], юбилейного издания 1995г. — в [2]). Эта монография по праву считается одной из лучших книг не только по данной тематике, но и по программированию вообще. Сопоставление двух ее изданий явно показывает, что проблемы, которые приходится решать при управлении программными проектами, почти не изменились со времени перфокарт. Меняется только техническая поддержка.

Из ранних работ, не потерявших своей актуальности, прежде всего следует обратить внимание на монографию Гантера [3], содержащую, кроме представленной выше модели, много полезной информации для организации работ над программными проектами. Систематизированные сведения о понятии жизненного цикла и его применении в промышленном программировании можно найти в книге [4], которая, к тому же, дает представление о состоянии дел в этой области в СССР к началу восьмидесятых годов. Весьма обстоятельное исследование задач и методов проектирования и разработки программного обеспечения выполнено Боэмом. Его книга [5] постоянно цитируется и в наши дни.

Современное представление о технологии проектирования программных систем прочно связано с методологией объектно-ориентированно­го программирования. Всестороннее изложение данного подхода, его концепций, а также общих методов разработки проектов в объектно-ориентирован­ном стиле можно найти в книге Буча [6]. UML и методы его использования в практической разработке программных проектов хорошо изложены авторами этого языка в монографии [7]. Понятия, связанные с CASE -технологиями, достаточно четко излагаются в работах [8,   9]. В частности, в последней из упомянутых публикаций достаточно подробно освещаются вопросы CASE -техно­ло­­гий, связанных с проектированием информационных систем.

Следующие ссылки помогут получить сведения об упомянутых выше конкретных разработках. Книга [10] дает наиболее полное представление о СУБД Oracle , в частности, об Oracle Designer 2000 и его месте в системе. I DEF -технология хорошо представлена в документе [11]. Информацию о RUP в целом и Ration Rose в частности можно найти на сайте [12].

Примечания

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

6.Чтобы не нарушалась нумерация контрольных точек, принятая для прежних моделей, дополнительные контрольные точки указаны номерами, помеченными

Литература

1. Брукс Ф.П. Как проектируются и создаются программные комплексы. — М.: Мир, 1979.
2. Брукс Ф.П. Мифический человеко-месяц, или как создаются программные системы. — СПб: Символ-Плюс, 1999.
3. Гантер Р. Методы управления проектированием программного обеспечения. — М.: Мир, 1981.
4. Липаев В.В. и др. Технология проектирования комплексов программ АСУ. — М.: Радио и связь, 1983.
5. Боэм Б.У. Инженерное проектирование программного обеспечения. — М.: Радио и связь, 1985.
6. Буч Г. Объектно-ориентированное проектирование с примерами применения. — М.: Конкорд, 1992.
7. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. — М.: ДМК, 2000.
8. Новоженов Ю.В. и др. Объектно-ориентированные CASE -средства // СУБД. — 1966, № 5-6. С. 119-125
9. Вендров А.М. CASE -технологии. Современные методы и средства проектирования информационных систем. — М.: Финансы и статистика, 1998.
10. Ричардс и др. Oracle ® 7.3. Энциклопедия пользователя. — Киев: «ДиаСофт», 1997.
11. IEEE IDEF0. “Standard Users Manual for the ICAM Function Modeling Method — IDEF0”. — IEEE draft standard P1320.1.1. 1997.
12. Rational Unified Process. — Copyright © 2001 Rational Software Corporation. http://www.rational.com/products/rup/index.jsp

Следующая статья сборника

Из сборника "Новосибирская школа программирования. Перекличка времен". Новосибирск, 2004 г.
Перепечатываются с разрешения редакции.