Стандарт ISO/IEC 15504 (SPICE)

Ориентирован на оценку процессов и возможностей их улучшения (Software Process Improvement and Capability); определяет правила такого оценивания.

В основу этого стандарта положена концепция аттестации (assessment) процессов, в отличие от типового для других стандартов ISO понятия "аудит".

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

Определяются 5 категорий, включающих 35 процессов и 201 вид деятельности.

Например, приобретение ПО включает такие виды деятельности, как:

-определение потребности в ПО,

-определение требований,

-подготовку стратегии покупки,

-подготовку запроса предложений,

-выбор поставщика.

Стандарт ISO/IEC 15504 опирается на стандарт SEI Модель зрелости возможностей CMM (Capability Maturity Model)

Этот стандарт предлагает унифицированный подход к оценке возможностей организации выполнять задачи различного уровня

CMM описывает различные степени зрелости процессов в организациях, определяя 5 уровней организаций.

Уровень 1, начальный (initial)(организации, разрабатывающие ПО, но не имеющие осознанного процесса разработки, не производящие планирования и оценок своих возможностей);

Уровень 2, повторяемый (repeatable)(в таких организациях ведется учет затрат ресурсов и отслеживается ход проектов, установлены правила управления проектами, основанные на имеющемся опыте);

Уровень 3, определенный (defined)(в таких организациях имеется принятый, полностью документированный, соответствующий реальному положению дел и доступный персоналу процесс разработки и сопровождения ПО. Этот процесс должен включать как управленческие, так и технические подпроцессы, а также обучение сотрудников работе с ним);

Уровень 4, управляемый (manageable)(в этих организациях, помимо установленного и описанного процесса, используются измеримые показатели качества продуктов и результативности процессов, которые позволяют достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством);

Уровень 5, совершенствующийся (optimizing)(в таких организациях, помимо процессов и методов их оценки, имеются методы определения слабых мест, определены процедуры поиска и оценки новых методов и техник разработки, обучения персонала работе с ними и их включения в общий процесс организации в случае повышения эффективности производства);

Каскадная модель

Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла. Впервые четко сформулирована в 1970 году Уильямом Ройсом (W.W.Royce) и затем закреплена в стандартах Министерства обороны США. Каскадная модель: предполагает строго последовательное поэтапное выполнение различных видов деятельности с четким определением границ между этапами.

Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа.

Характеристика модели

Достоинства модели:

-упорядоченность процесса разработки

-возможность его строгого планирования во времени.

Недостатки модели:

-необходимость точной и полной формулировки требований к ПС перед началом разработки

-невозможность изменения решений, принятых на предыдущих этапах

-результаты проекта становятся доступны заказчику только по завершении работ.

Инкрементная модель

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

Результатом выполнения каждого из инкрементов является очередная работающая версия ПО.

Характеристика модели

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

-Ее основной недостаток заключается в наличии риска увеличения срока разработки из-за подготовки большого числа версий

RAD-модель

Модель быстрой разработки приложений (Rapid Application Development) появилась в 80-х годах прошлого века и является еще одним примером реализации инкрементной стратегии.

Предполагает выделение в системе нескольких основных бизнес-функций и разработку каждой из них отдельной группой разработчиков с последующей интеграцией в целую систему.

Условия применения модели:

Применение данной модели оправдано в проектах, не требующих выполнения сложных алгоритмов, но при жестких ограничениях по сроками выполнения.

Как правило RAD-модель используется при работе с мощными инструментальными средствами разработки – визуальными средами проектирования и программирования.

Характеристика модели

Основным достоинствоммодели является уменьшение сроков разработки.

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

Спиральная модель

Предложена в 1988 г. Барри Боэмом (Barry W. Boehm) и является классическим примером реализации эволюционной стратегии.

Модель определяет четыре действия:

-планирование(заключается в определении целей очередной итерации процесса разработки, выборе вариантов решения и оценки ограничений)

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

-конструирование(это основное действие, заключающееся в создании следующей версии ПО)

-оценивание(оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований)

Характеристика модели

Достоинства модели:

-данная модель отображает процесс разработки ПО в наиболее реальном виде;

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

Недостатки модели:

-повышенные требования к заказчику;

-трудности контроля и управления временем разработки.

Прогнозирующие процессы

Все рассмотренные выше модели соответствуют так называемым прогнозирующим ( тяжеловесным ) процессам разработки ПС.

Они предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации.

Основная цель таких процессов –отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять.

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

Адаптивные процессы

В настоящее время все большее распространение получают адаптивные или облегченные, «живые» (agile) процессы разработки.

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

Адаптивные процессы делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки.

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