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

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

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

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

---

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

В связи с тем что ЖЦ продукта проходит ряд стадий, очевидна необходимость проводить вывод из эксплуатации и переходить к новой версии.

Достаточно интересным является взгляд на вклад различных фаз ЖЦ программных проектов в сроки и стоимость. Анализ произведен на основе целого ряда проектов (порядка 1000), которые велись компанией HP и др. Очевидно, что сопровождение составляет львиную долю стоимости и сроков проекта. При этом такие стадии, как кодирование, даже вместе с тестированием, и анализ требований, даже вместе с изготовлением спецификаций, занимают относительно небольшую долю стоимости. Можно сделать ряд интересных выводов на основе анализа этой динамики. Основные затраты выделяются на сопровождение. Особенно это важно для корпоративных проектов, которые являются долгосрочными и включают большое количество компонентов, которые нужно объединять, интегрировать и поддерживать совместно, что вызывает дополнительные сложности. Кроме того, программные средства, которые увеличивают расширяемость применения ПО, более эффективны, чем все попытки рефакторинга улучшения кода. Еще один интересный вывод состоит в том, что фазы перед кодированием и после него составляют порядка 30 % затрат, а собственно кодирование при этом составляет всего 5 %. То есть то, что называется программированием, для больших проектов отнюдь не является затратной частью. Обрамляющие стадии (тестирование и коррекция спецификаций) обеспечивают существенное улучшение качества ПО и его соответствие требованиям. Нужно сказать, что правильная постановка обрамляющих стадий очень важна и ускоряет кодирование.

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

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

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

Какие общие черты можно выделить в перечисленных моделях ЖЦ? Как правило, они включают все его стадии, за исключением модели Build-and-fix. Кроме того, предполагается несколько итераций по разработке продукта, за исключением каскадной модели. Как правило, стадии ЖЦ четко различимы, кроме объектно-ориентированной модели, где они могут объединяться. Некоторые отдельные модели, связанные с некоторыми методологиями проектирования, такие как модель синхронизации и стабилизации, связаны с методологией MSF. RUP поддерживает каскадные и спиральные сценарии жизненного цикла и т. д.

Грамотное применение модели ЖЦ требует высокой организационной зрелости команды и серьезной дисциплины проекта с точки зрения стандартов документирования, кодирования, использования специализированных CASE-средств и т. д. Если такие знания недостаточны, то объектно-ориентированная модель может выродиться в такую модель, как Build-and-fix, т. е. можно потерять все преимущества модели и увеличить затраты.

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

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

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