Стандарт ISO/IEC 12207-95: работы и задачи процесса разработки. См.9

- Первая редакция ISO/IEC 12207-95 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 "Информационные технологии, подкомитет SC7, проектирование программного обеспечения»

- По определению, ISO/IEC 12207-95— базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, куда ПО входит как часть.

- Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Задачи

· Работа по развертыванию процесса разработки состоит из следующих задач:

- определение модели жизненного цикла,

- документирования и контроля результатов отдельных работ,

- выбора используемых стандартов,

- языков и инструментов и пр.

· Работа по переносу ПО между платформами состоит из:

- разработки плана переноса,

- оповещения пользователей,

- выполнения анализа произведенных действий и пр.

11. Стандарт ISO/IEC 15504 (SPICE): оценка возможностей разработчика. Связь этогостандарта с моделью зрелости предприятия SEI CMM.

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

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

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

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

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

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

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

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

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

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

Процессы ЖЦ по ISO/IEC 15504

Модель CMM

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

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

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

Уровни зрелости

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

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

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

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

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

12. Стандарт ISO 9126: оценочные характеристики качества программного продукта.

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

· Разделяется на 4 части, описывающие следующие вопросы:

- модель качества;

- внешние метрики качества;

- внутренние метрики качества;

- метрики качества в использовании

· Качество определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц

· Различаются понятия:

- внутреннего качества,

- внешнего качества,

- качества ПО при использовании

Три аспекта качества ПО

· Внутреннее качество связано с характеристиками ПО самого по себе, без учета его поведения

· Внешнее качество характеризующего ПО с точки зрения его поведения

· Качества ПО при использовании – это то качество, которое ощущается пользователями при конкретных сценариях работы ПО

13. Каскадная модель процесса разработки, ее характеристика. Инкрементная модель процесса разработки, ее характеристика.

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

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

Каскадная модель(содержание):

Выработка системных требованийàвыработка требованийàанализàпроектированиеàкодированиеàтестированиеàэксплуатация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14. RAD-модель процесса разработки, ее характеристика. Этапы и рабочие потоки процесса разработки.

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

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

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

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

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

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

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

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