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

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

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

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

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

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