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

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

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

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

---

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

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

Чем хороша спиральная модель? Прежде всего, если ПО производится на основе этой модели, то за счет прототипирования, если оно применяется, за счет анализа и оценки рисков возможно повторное использование продукта. То есть сам подход к жизненному циклу обеспечивает плавное движение продукта по этому жизненному циклу, плавный переход к его сдаче заказчику. Таким образом обеспечивается возможность повторного использования продукта, даже в условиях изначально высоких проектных рисков. Поскольку анализ рисков происходит изначально, можно ограничиться в ряде случаев упрощенной схемой тестирования. С другой стороны, можно достаточно корректно обосновать, в каких случаях и в какой мере это тестирование проводить, когда завершится тестирование и продукт перейдет к заказчику – исходя из применяемой технологии анализа рисков. На основе анализа рисков получается еще целый ряд метрик, которые дают возможность оценить продукт с точки зрения его качества, надежности, полноты документации, чтобы его можно было передать заказчику. Кроме того, можно относительно гладко перейти к сопровождению продукта за счет того, что продукт последовательно приближается к «боевому» решению в ходе достаточно большого количества витков спирали, каждый из которых подтверждается и уточняется очередной итерацией оценки рисков. То есть имеет место цикличность. В этой связи, несмотря на большие затраты из-за оценки рисков, обеспечивается относительно недорогое сопровождение, а оно является наиболее затратной частью жизненного цикла, принимая на себя около 2/3 всех затрат. Таким образом, на полном жизненном цикле – с учетом сопровождения – может быть получена экономия. По сути, все недостатки, присущие этой модели, вытекают из того, что требуются большие затраты на оценку риска. Во-первых, она применима преимущественно для внутренних проектов – таких, которые ведутся в пределах одного подразделения, разными структурами одной корпорации или структурами, которые имеют давнюю историю партнерских отношений и тесные взаимосвязи. Это происходит потому, что требуется предварительная оценка рисков и представителям разработчика часто необходима полная информация о производственных процессах заказчика, которые могут эти риски повлечь. Эта информация часто относится к категории коммерческой тайны и далеко не всегда может быть в достаточной мере передана разработчику. Поэтому если проект внутренний, эта проблема снимается. Конечно, спиральная модель может быть принципиально применима и для относительно небольших проектов, но, учитывая существенную затратность оценки рисков, она в первую очередь используется для больших корпоративных проектов. Что еще очень важно: она требует опыта оценки рисков. То есть либо в команде разработчика должны быть опытные специалисты по оценке рисков (с умением приоретизировать сложную структуру рисков по целому ряду критериев, особенно в корпоративных системах), либо этих специалистов следует привлекать извне.

Еще одна модель – наиболее интересная и динамичная – это объектно-ориентированная модель. Речь пойдет о той ее разновидности, которую называют фонтанной. Это название будет понятно, если посмотреть на схему взаимодействия фаз этой модели.

В чем ее особенности? Если все предыдущие модели содержат изолированные, четко отделенные стадии жизненного цикла (анализ требований, спецификация требований, предварительное и первичное проектирование, детальное и окончательное проектирование, реализация и тестирование, сборка и интеграционное тестирование, тестирование продукта, приемочное тестирование и передача заказчику, сопровождение, вывод из эксплуатации), особенно четко это представлено в водопадной модели (пока нет подписи на документе, что предыдущая стадия завершена в соответствии с принятыми стандартами качества, следующая стадия не может быть начата), то в объектно-ориентированной модели принято достаточно интенсивное взаимодействие между различными фазами жизненного цикла. Более того, имеет место перекрытие фаз: перекрываются объектно-ориентированный анализ и спецификация требований, иногда – объектно-ориентированный анализ и проектирование (вместе это называется «object-oriented analysis and design», что, вообще говоря, в других моделях является разными фазами). В отличие от других моделей она не разделяет данные и действия: внутри класса атрибуты и методы равноправно взаимодействуют внутри класса. Во многом именно поэтому взаимодействие фаз и является важной особенностью объектно-ориентированного подхода.

Еще важной особенностью выступает итеративная смена фаз. Изготовление продукта – процесс циклический, который может требовать и в ряде случаев требует возврата на предыдущие фазы. То есть фазы объектно-ориентированного проектирования часто включают в себя фазы объектно-ориентированного анализа. Скажем, анализ сценариев использования связан с объектным моделированием и производится на основе диаграмм прецедентов, которые являются продуктом проектирования.

На рис. 3.9 достаточно хорошо видно, что снизу вверх происходит проектирование, анализ и спецификация требований (они тесно связаны), последующие два этапа – проектирование и реализация (они тоже достаточно тесно связаны), возможен возврат к предыдущим фазам.