Стандарт 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) процессы разработки.
Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков.
Адаптивные процессы делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки.
Они избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте и не требуют разработки дополнительных промежуточных документов.
Дата добавления: 2018-05-13; просмотров: 958; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!