3.2. Каскадная стратегия

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

Рис.3.1. Каскадная стратегия

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

Достоинства модели:

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

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

Недостатки модели:

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

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

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

3.3. Инкрементная стратегия

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

Рис.3.2. Инкрементная стратегия

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

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

Отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

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

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

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

3.4. Спиральная стратегия

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

Рис. 3.3. Спиральная стратегия

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

Достоинства модели:

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

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

Обеспечивает большую гибкость в управлении проектом;

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

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

Уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

Увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

3.5. Сравнительный анализ моделей

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

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

Таблица 3.1. Сравнение моделей жизненного цикла

Характеристика проекта	Модель (стратегия)
Новизна разработки и обеспеченность ресурсами	Типовой. Хорошо проработаны технология и методы решения задачи		Нетиповой (новаторский). Нетрадиционный для разработчика
	Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки	Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта	Малые и средние проекты	Средние и крупные проекты	Любые проекты
Сроки выполнения проекта	До года	До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии	Заключается один договор. Версия и есть итоговый результат проекта	На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта	Да	Да	Нет
Изменение требований по мере развития проекта	Нет	Незначительное	Да
Разработка итерациями (версиями)	Нет	Да	Да
Распространение промежуточного ПО	Нет	Может быть	Да

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

При разработке системы под итоговым продуктом и промежуточным программным обеспечением согласно следует понимать:

- ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

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

- версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

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

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

3.6. Методологии, поддерживающие спиральную модель

В настоящее время имеется несколько методологий 1 разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999).

3. Дайте краткую характеристику методологий и .

Лекция 2.

Понятие жизненного цикла и модели жизненного цикла. Каскадная модель ЖЦ. Поэтапная модель с промежуточным контролем. Спиральная модель ЖЦ . Процессы ЖЦ ПО . Rapid Application Development(RAD). Extreme Programming (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Custom Development Method (методика Oracle).

2.1. Понятие жизненного цикла и модели жизненного цикла

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

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

Модель ЖЦ ПО включает в себя (слайд 3) :стадии, результаты выполнения работ на каждой стадии, ключевые события - точки завершения работ и принятия решений.

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

Крайним случаем модели ЖЦ можно считать так называемую модель «черного ящика» (black box) или «code and fix» (кодиро­вание и исправление), что фактически означает отсутствие ка­кой-либо модели. В этом случае выделить какие-либо рациональные стадии в процессе разработки ПО не представля­ется возможным, поскольку отсутствует планирование и органи­зации работ.

В настоящее время известны и используются следующие модели жизненного цикла:

Каскадная модель (характерна для периода 1970-1980 гг.);

Поэтапная модель с промежуточным контролем (характерна для периода 1980-1985 гг.);

Спиральная модель (характерна для периода после 1986 г.)

2.2. Каскадная модель жц

В1970 г. эксперт в области ПО Уинстон Ройс опубликовал по­лучившую широкую известность статью, в которой он излагал свое мнение о методике, которая позднее получила название «модель водопада» (waterfall model), или «каскадная модель» (слайд 4) .

Впосле­дствии эта модель была регламентирована множеством норма­тивных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34.

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

Принципиальными свойствами так называемой «чистой» каскадной модели являются следующие:

Фиксация требований к системе до ее сдачи заказчику;

Последовательное выполнение этапов.

Переход на очередную стадию проекта только после того, как будет полностью завершена работа на текущей стадии, без возвратов на пройденные стадии.

Отсутствие временного перекрытия этапов

Отсутствие возврата к предыдущим этапам

Наличие результата только в конце разработки.

Преимущества применения каскадной модели заключаются в следующем:

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

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

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

Другими недостатками каскадного подхода являются:

позднее обнаружение проблем. Выявление и устранение ошибок производится только на стадии тестирования, которая может растянуться во времени или вообще никогда не завершиться.

выход из календарного графика, запаздывание с получени­ем результатов;

избыточное количество документации;

невозможность разбить систему на части (весь продукт раз­рабатывается за один раз);

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

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

В общем случае программная система помимо собственно программ содержит еще и аппаратное обеспечение, а также обычно рассматривается в окружении других программно-аппаратных систем.

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

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

Этапы жизненного цикла ПО

Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: -1- возникновение и исследование идеи; -2- анализ требований и проектирование; -3- программирование; -4- тестирование и отладка; -5- ввод программы в действие; -6- эксплуатация и сопровождение; -7- завершение эксплуатации.

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

Примеры описания жизненного цикла

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

В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:

разработка технического задания (этапы 1 и 2);

технический проект (третий этап до 3.2.1 включительно);

рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);

экспериментальное внедрение (4.2 и 4.3);

сдача в промышленную эксплуатацию (этап 5);

промышленная эксплуатация (этап 6).

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

Рис. 1.1 Пример жизненного цикла программных систем

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

Анализ целевых требований (2.1). Определяются, без учета средств реализации, общие характеристики системы, которым она должна удовлетворять. Устанавливается, что и как должна делать система.

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

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

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

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

Кодирование и тестирование программного обеспечения (4.1.1 и 4.1.2). Создание, тестирование отдельных модулей, документирование и приемка программных компонентов, которые составляют программную систему.

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

Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.

Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.

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

Завершение проекта (7). Формирование посториорной модели проектных действий с анализом достоинств, недостатков и т.д., и использование их в качестве основания для улучшения процесса разработки.

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

этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);

этап разработки, на котором создается программная система:

постановку задачи (этап 2),

проектирование (3),

кодирование (4.1.1),

получение исполняемого кода (4.1.1, 4.3);

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

Рис. 1.2 Вариант упрощенного жизненного цикла программной системы.

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

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

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

Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения

Для компонента W из множества системных требований к единому продукту формируется подмножество требований, относящихся к данному компоненту, используются эти требования при формировании проекта программного компонента, реализовывают этот проект в исходном коде и тогда интегрирует компонент с аппаратурой. Компонент X показывает использование ранее разработанного программного обеспечения. Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к программному обеспечению. Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта.

Практически все этапы жизненного цикла объединяются с верификацией.

Понятие жизненного цикла программного обеспечения

Понятие жизненного цикла программного обеспечения (ЖЦ ПО) является одним из базовых в программной инженерии. Жизненный цикл определяют как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ разделены на три группы (рис. 2.1).

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

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4.Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

В настоящее время наибольшее распространение получили следующие основные модели ЖЦ ПО:

a) каскадная и

b) спиральная (эволюционная).

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

Преимущества применения каскадной модели заключаются в следующем:

На каждой стадии формируется законченный набор проектной документации;

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

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

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

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

Каскадную (эволюционную) модель можно представить в виде диаграммы, которая приведена на рисунке 2.5.

Одним из результатов применения спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений , или RAD (Rapid Application Development). Жизненный цикл ПО в соответствии с этим способом включает в себя четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) внедрение.

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

1) Стратегия;

2) Анализ;

3) Проектирование;

4) Реализация;

5) Тестирование;

6) Внедрение;

7) Эксплуатация и техническая поддержка.

Стратегия

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

Итогом этапа определения стратегии становится документ, в котором четко сформулировано следующее:

Что именно причитается заказчику, если он согласится финансировать проект;

Когда он сможет получить готовый продукт (график выполнения работ);

Во сколько это ему обойдется (график финансирования этапов работ для крупных проектов).

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

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

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

a) функции - информация о событиях и процессах, которые происходят в бизнесе;

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

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

Проектирование

На этапе проектирования формируется модель данных. Проектировщики обрабатывают данные анализа. Конечным продуктом этапа проектирования являются схема базы данных (если таковая существует в проекте) или схема хранилища данных (ER-модель) и набор спецификаций модулей системы (модель функций).

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

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

Задачами проектирования являются:

Рассмотрение результатов анализа и проверка их полноты;

Семинары с заказчиком;

Определение критических участков проекта и оценка его ограничений;

Определение архитектуры системы;

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

Проектирование хранилища данных: модель базы данных;

Проектирование процессов и кода: окончательный выбор средств разработки, определение интерфейсов программ, отображение функций системы на ее модули и определение спецификаций модулей;

Определение требований к процессу тестирования;

Определение требований к безопасности системы.

Реализация

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

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

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

Этап разработки сопряжен с этапом тестирования, и оба процесса идут параллельно. Синхронизирует действия тестеров и разработчиков система bug tracking.

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

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

Тестирование

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking, которая обеспечивает следующие функции:

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

Система уведомления о появлении новых ошибок, об изменении статуса известных в системе ошибок (уведомления по электронной почте);

Отчеты об актуальных ошибках по компонентам системы;

Информация об ошибке и ее история;

Правила доступа к ошибкам тех или иных категорий;

Интерфейс ограниченного доступа к системе bug tracking для конечного пользователя.

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

Собственно тесты систем принято подразделять на несколько категорий:

a) автономные тесты модулей; они используются уже на этапе разработки компонентов системы и позволяют отслеживать ошибки отдельных компонентов;

b) тесты связей компонентов системы; эти тесты также используются и на этапе разработки, они позволяют отслеживать правильность взаимодействия и обмена информацией компонентов системы;

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

d) приемосдаточный тест ; основное его назначение - сдать систему заказчику;

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

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

Отдельного компонента информационной системы;

Группы компонентов системы;

Основных модулей системы;

Операционной системы;

Жесткий сбой (отказ питания, жестких дисков).

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

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

Внедрение

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

Ввод в эксплуатацию проходит как минимум три стадии:

2) накопление информации;

3) выход на проектную мощность (то есть собственно переход к этапу эксплуатации).

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

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

Выход системы на проектную мощность в хорошем варианте - это доводка мелких ошибок и редкие серьезные ошибки.

Эксплуатация и техническая поддержка

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

И. Н. Скопин

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

Введение

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

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

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

Рис. 1. Разработка, использование и сопровождение программного обеспечения

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

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

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

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

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

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

1. Модели традиционного представления
о жизненном цикле

1.1. Общепринятая модель

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

• разработка,
• сопровождение.

Фазы разбиваются на ряд этапов (рис. 2).

Рис. 2. Общепринятая модель жизненного цикла программного обеспечения

Разработка начинается с идентификации потребности в новом приложении, а заканчивается передачей продукта разработки в эксплуатацию.

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

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

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

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

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

В рассматриваемой модели фаза разработки заканчивается этапом тестирования (автономного и комплексного) и передачей системы в эксплуатацию .

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

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

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

1.2. Классическая итерационная модель

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

Таковы мотивы классической итерационной модели жизненного цикла (рис. 3).

Рис. 3. Классическая итерационная модель

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

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

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

1.3. Каскадная модель

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

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

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

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

Рис. 4. Каскадная модель

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

Результат проектирования верифицируется , т.е. проверяется, что принятая структура системы и реализационные механизмы обеспечивают выполнимость специфицированных функций.

Реализация контролируется путем тестирования компонент, а после интеграции компонент в систему и комплексной отладки проводится аттестация , т.е. проверка-фиксация фактически реализованных функций системы, описание ограничений реализации и т.п.

В ходе эксплуатации и сопровождения изделия устанавливается, насколько хорошо система соответствует пользовательским запросам, т.е. осуществляется переаттестация .

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

Рис. 5. Строгая каскадная модель

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

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

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

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

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

1.4. Модель фазы-функции

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

Наиболее последовательно такое дополнение классической схемы реализовано в модели Гантера в виде матрицы «фазы-функции». Уже из упоминания о матрице следует, что модель Гантера имеет два измерения:

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

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

Рис. 6. Фазовое измерение модели фазы-функции

В данной модели жизненный цикл распадается на следующие перекрывающие друг друга фазы (этапы):
• исследования - этап начинается, когда необходимость разработки признана руководством проекта (контрольная точка 0), и заключается в том, что для проекта обосновываются требуемые ресурсы (контрольная точка 1) и формулируются требования к разрабатываемому изделию (контрольная точка 2);
• анализ осуществимости - начинается на фазе исследования, когда определены исполнители проекта (контрольная точка 1), и завершается утверждением требований (контрольная точка 3). Цель этапа - определить возможность конструирования изделия с технической точки зрения (достаточно ли ресурсов, квалификации и т.п.), будет ли изделие удобно для практического использования, ответить на вопросы экономической и коммерческой эффективности;
• конструирование - этап начинается обычно на фазе анализа осуществимости, как только документально зафиксированы предварительные цели проекта (контрольная точка 2), и заканчивается утверждением проектных решений в виде официальной спецификации на разработку (контрольная точка 5);
• программирование - начинается на фазе конструирования, когда становятся доступными основные спецификации на отдельные компоненты изделия (контрольная точка 4), но не ранее утверждения соглашения о требованиях (контрольная точка 3). Совмещение данной фазы с заключительным этапом конструирования обеспечивает оперативную проверку проектных решений и некоторых ключевых вопросов разработки. Цель этапа - реализация программ компонентов с последующей сборкой изделия. Он завершается, когда разработчики заканчивают документирование, отладку и компоновку и передают изделие службе, выполняющей независимую оценку результатов работы (независимые испытания начались - контрольная точка 7);
• оценка - фаза является буферной зоной между началом испытаний и практическим использованием изделия. Она начинается, как только проведены внутренние (силами разработчиков) испытания изделия (контрольная точка 6) и заканчивается, когда подтверждается готовность изделия к эксплуатации (контрольная точка 9);
• использование - начинается в ходе передачи изделия на распространение и продолжается, пока изделие находится в действии и интенсивно эксплуатируется. Этап связан с внедрением, обучением, настройкой и сопровождением, возможно, с модернизацией изделия. Он заканчивается, когда разработчики прекращают систематическую деятельность по сопровождению и поддержке данного программного изделия (контрольная точка 10).

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

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

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

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

Рис. 7. Матрица фазы-функции модели Гантера

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

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

Рис. 8. Учет итеративности в модели фазы-функции (фазовое измерение, показаны лишь некоторые возвраты)

2. Объектно-ориентированные модели
жизненного цикла

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

2.1. Принципы объектно-ориентированного проектирования

Принципиальные моменты, в которых объектно-ориентированный подход к развитию проектов стоит сопоставить с традиционными последовательными методологиями, сводятся к следующему:

• Итеративность развития.

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

• Наращивание функциональности в соответствии со сценариями.

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

• Ничто не делается однократно.

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

• Оперирование на размножающихся фазах подобно.

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

При объектно-ориентированном проектировании в ходе итеративного наращивания обыкновенно выполняются вполне традиционные этапы:

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

2.2. Модификация модели фазы-функции

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

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

• Распределение реализуемых требований по итерациям.

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

• Особый стиль наращивания возможностей системы и ее развития.

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

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

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

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

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

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

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

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

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

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

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

• выделение общих (т.е. непривязанных к проекту) переиспользуемых компонентов (обычно эти работы связываются с событием передачи системы на распространение - контрольная точка 10).

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

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

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

Рис. 10. Модель фазы-функции, модифицирования для объектно-ориентированного развития проекта

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

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

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

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

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

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

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

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

Рис. 11. Распараллеливание выполнения итераций проекта

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

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

2.4. Моделирование итеративного наращивания
возможностей системы

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

Рис. 12. Спираль развития объектно-ориентированного проекта

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

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

Рис. 13. Модель расширения охвата прикладной области объектно-ориентированной системой

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

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

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

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