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

• Название: Основы проектирования корпоративных систем
• Автор: Сергей Зыков
• Жанр: Управление, подбор персонала
• Год: 2012
• ISBN: 978-5-7598-0862-6

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

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

---

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

Кратко остановимся на преимуществах и недостатках различных моделей ЖЦ.

Модель Build-and-fix хороша для небольших проектов, которые не требуют сопровождения, но абсолютно непригодна для корпоративных или вообще нетривиальных проектов объемом более 1000 строк.

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

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

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

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

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

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

На что влияет выбор модели ЖЦ? На скорость разработки, время выхода проекта на рынок, качество и стоимость продукта, стратегию управления изменениями и рисками, отношения с заказчиком на стадии сопровождения.

Окончательные выводы, которые можно сделать по моделям ЖЦ: выбор модели определяет основные критические параметры проекта – это успех проекта в целом, архитектура проекта, его бюджет, в каких случаях можно сэкономить. Модель должна быть адекватна опыту проектной команды с точки зрения знаний предметной области и знания конкретных технологий, CASE-средств, документирования, подходов к документированию и т. д. Серьезные модели, такие как спиральная или объектно-ориентированная, требуют определенной дисциплины и зрелости. В противном случае они вырождаются в модель проб и ошибок. Универсальной модели не существует. Выбор модели определяется исключительно характером и масштабом проекта. Ряд моделей можно комбинировать. У каждой модели есть свои преимущества и недостатки, которые обнаруживаются и имеют смысл только в контексте проекта, с учетом его особенностей.

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

Одним из важных CASE-средств, которое мы будем рассматривать, является Visual Studio.NET от Microsoft. О нем мы будем говорить в дальнейшем. Существует большое количество других CASE-средств: линейка Rational, которая поддерживает RUP. CASE-средства помогают во всех трех аспектах – и узко при кодировании, и при оптимизации ЖЦ, и при командной работе.

CASE-средства в первом приближении делятся на CASE-средства верхнего уровня (front-end), т. е. соответствуют первичным стадиям ЖЦ, и нижнего уровня (back-end), соответствующие стадиям ЖЦ, начиная с реализации. Важно отметить, что существуют конвейерные средства, такие как линейка Rational, Microsoft Visual Studio.NET, которые представляют собой среды, т. е. наборы определенного инструментария или своего рода конвейеры для выполнения связанных операций компиляции, тестирования, интеграции, редактирования кода, изготовления проектной документации, диаграммирования и т. д.

CASE-технологии дают неоспоримое преимущество при изготовлении больших программных систем. Но при своем применении они требуют определенных условий, таких как организационная зрелость команды, знание стандартов (UML, XML), знание самого средства. Кроме того, CASE-средства применимы для больших проектов корпоративных систем. Для небольших проектов стоимость CASE-средств и обучения им неоправданно высока. В результате успешного применения CASE-средств можно получить существенный рост производительности труда разработчиков и, в результате, если мы говорим о проекте в целом, существенное снижение сроков и стоимости программного проекта.

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

Глава 3 Модели жизненного цикла корпоративных систем

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

В предыдущей главе был рассмотрен ряд моделей, используемых в разработке ПО, в частности модель Build-and-fix (модель неполного жизненного цикла, рис. 3.1), которая в силу своей простоты не пригодна для больших и сложных проектов, имеющих размеры более 1000 программных строк. Также была рассмотрена модель быстрого прототипирования, которая тоже несколько ограниченна, несмотря на то что включает в себя все необходимые стадии жизненного цикла: анализ и спецификацию требований, первичное и детальное проектирование, реализацию, модульное и сборочное тестирование, интеграцию, тестирование продукта, передачу его заказчику, вывод из эксплуатации. Несмотря на это, она несамостоятельна, потому что на самом деле этап тестирования (и индивидуальных модулей, и при сборке) недостаточен, документация неполная, и продукт, получаемый на выходе, лишь моделирует функциональность той «боевой» системы, разработка которой ведется.

Рис. 3.1. Модель Build-and-fx жизненного цикла ПО

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