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

Следующая стадия – подготовка проектных спецификаций . Она происходит на основе описания требований, т. е. тех документов, которые получены на предыдущей стадии ЖЦ. Эта и следующие стадии являются в основном прерогативой разработчика. Хотя в ряде методологий проектирования и реализаций программных комплексов, таких гибких, как Agile, X P, Scrum, заказчик участвует на всех этапах ЖЦ ПО. Для больших корпоративных систем, как правило, разработка ведется по методологиям RUP или MSF, и там основным действующим лицом является разработчик. Проектные спецификации содержат описания всей функциональности проекта и всех основных ограничений, желательно выраженных количественно. Здесь уже можно ограничить и программное обеспечение, и технологии, которые будут использованы, и архитектуру (например, сделать выбор между платформами Java или. NET). Необходимо четко ограничить количество одновременных пользователей, количество подключений, транзакций и их интенсивность, пропускную способность канала и ряд других параметров. При этом методологию или модель разработки ПО – каскадную, эволюционную, спиральную или иную – следует выбрать как можно раньше, поскольку выбор методологии или модели ЖЦ определяющим образом сказывается на сроках, стоимости и успехах проекта. Проектные спецификации должны ограничивать сроки и стоимость проекта исходя из договоренностей, которые достигли разработчик и заказчик на предыдущем этапе.

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

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

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

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

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

С точки зрения экономики сопровождение – самый затратный этап ЖЦ (порядка 2/ 3стоимости всего проекта) как по времени, так и по средствам. Нужно понимать, что сопровождение необходимо для любого ПО. Цель при разработке – не просто передача программного продукта заказчику, а продолжение продуктивных отношений с этим заказчиком. Задачами сопровождения программного продукта являются ликвидация ошибок, которые остались в программном продукте, коррекция проектных спецификаций, улучшение производительности и учет особенностей новой программной и аппаратной среды заказчика, если таковые имеются. Сопровождение включает следующие виды:

• корректирующее сопровождение (устранение существующих в продукте ошибок без изменения проектных спецификаций);