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

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

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

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

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

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

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

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

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

• адаптивное сопровождение (адаптация продукта к новой программно-аппаратной среде).

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

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