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