Сергей Зыков - Основы проектирования корпоративных систем

Рис. 3.6.Инкрементальная модель жизненного цикла ПО

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

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

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

Рис. 3.7.Эволюционная модель жизненного цикла ПО

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

1) определить цели – продукт, деловые цели, понять ограничения, предложить альтернативы;

2) оценить альтернативы – анализ риска, прототипирование;

3) разработать продукт – детальный проект, код, unit test, интеграция;

4) спланировать следующий цикл – оценка клиентом, планирование проектирования, поставка клиенту, внедрение.

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

Рис. 3.8.Спиральная модель жизненного цикла ПО

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

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