Основы проектирования корпоративных систем

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

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

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

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

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

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

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

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