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

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

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

Программные продукты можно классифицировать по разным основаниям. Один из видов классификации – масштаб использования: это и личное использование, и некоммерческое, и коммерческое как коробочный продукт для широкого класса организаций и предприятий. Другой способ классификации – цель использования. Это может быть специализированное ПО, нацеленное на решение достаточно узкой задачи, например расчетное ПО для решения астрономических задач, лазерной дальнометрии, или ПО более общего назначения, такое как операционная система, офисные продукты и т. п. Еще один вид классификации – степень открытости. При этом можно говорить о компонентной ориентированности, скажем, API, библиотеки, такие как, например, библиотека классов Enterprise Libraries, которая используется для надстройки над. NET для построения Microsoft-продуктов корпоративного типа, библиотека классов для построения офисных приложений и т. д. или готовые продукты.

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

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

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

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