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

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

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

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

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

Исходя из этих предпосылок перечислим модели. Build-and-fix – модель неполного жизненного цикла, которая содержит краткое описание стадий ЖЦ: первичное проектирование и анализ упрощены, документация присутствует не в полном объеме. Водопадная (каскадная) модель – один проход по всем стадиям жизненного цикла, жесткое документальное согласование каждого этапа с возможностью продолжения или прекращения работы. Модель быстрого прототипирования – несамостоятельная, может применяться как вспомогательная для уточнения технических характеристик. Инкрементальная модель, модель Microsoft (синхростабилизации); объектно-ориентированная модель, где есть взаимодействие и даже перекрытие этапов.

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

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

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