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

Рис. 3.1.Модель Build-and-fx жизненного цикла ПО

Каскадная (водопадная) модель, представленная на рис. 3.2, является в полной мере применимой для корпоративных информационных систем, но имеет ряд ограничений. В частности, как и многие модели, которые применимы для КИС, она требует дисциплины и организованности, хорошего знания CASE-средств, так как нужно быстро и организованно создавать диаграммы, проводить сетевые совещания, конференции, достаточно быстро вести тестирование различными методами. Кроме того, нужно производить документацию в соответствии со стандартами, которые приняты по договоренности с заказчиком внутри компании как руководство к действию, как шаблоны для реализации документации, которая тоже является важной частью продукта. Продукт – это не только код, но и огромное количество документации, необходимое, чтобы обеспечить его грамотное и стабильное сопровождение. Документация тем более полезна для чтения чужого кода, поскольку персонал сопровождения как раз и работает с чужим кодом, ища в нем ошибки. Это будет рассмотрено более подробно далее, когда речь пойдет о стадии сопровождения. Пока следует отметить, что документация критически важна для каскадной модели, потому что, проверяя ее на адекватность и сопоставляя с ТЗ или другим вариантом требований к продукту, которые согласованы с заказчиком и утверждены как юридический документ, разработчики отчитываются по продукту и закрывают каждую стадию жизненного цикла.

Рис. 3.2.Каскадная модель жизненного цикла ПО

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

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

Рис. 3.3.V-модель жизненного цикла ПО на базе каскадной модели

Рис. 3.4.Быстрое прототипирование – модель жизненного цикла ПО

Рис. 3.5.«Зубья акула» – модель жизненного цикла ПО на базе модели быстрого прототипирования

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