Группа стандартов CMM, разработанных SEI

Группа стандартов ISO

· ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes (процессы жизненного цикла ПО, есть его российский аналог ГОСТ Р-1999).

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

ISO/IEC 15504 (SPICE) Standard for Information Technology — Software Process Assessment (оценка процессовразработки иподдержкиПО).

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

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

Группа стандартов IEEE

· IEEE 1074-1997 — IEEE Standard for Developing Software Life Cycle Processes [8] (стандартнасоздание процессовжизненногоцикла ПО).

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

IEEE/EIA 12207-1997 — IEEE/EIA Standard: IndustryImplementationofInternationalStandard ISO/IEC 12207:1995 SoftwareLifeCycleProcesses [9,10,11] (промышленное использование стандарта ISO/IEC 12207 на процессы жизненного цикла ПО).

Аналог ISO/IEC 12207, сменил ранее использовавшиеся стандарты J-Std-016-1995 EIA /IEEE InterimStandardforInformationTechnology — SoftwareLifeCycle Processes — SoftwareDevelopment Acquirer - Supplier Agreement (промежуточный стандарт на процессы жизненного цикла ПО и соглашения между поставщиком и заказчиком ПО) и стандарт министерства обороны США MIL-STD -498.

Группа стандартов CMM, разработанных SEI

· Модель зрелости возможностей CMM (CapabilityMaturityModel) [12,13] предлагает унифицированный подход к оценке возможностей организации выполнять задачи различного уровня. Для этого определяются 3 уровня элементов: уровни зрелости организации (maturitylevels), ключевые области процесса (keyprocessareas) и ключевые практики (keypractices). Чаще всего под моделью CMM имеют в виду модель уровней зрелости.

 

9. Тяжелые" и "легкие" процессы разработки

В этой лекции мы рассмотрим детально два процесса разработки — унифицированный процесс Rational (RationalUnifiedProcess, RUP) и экстремальное программирование (ExtremeProgramming, XP). Оба они являются примерами итеративных процессов, но построены на основе различных предположений о природе разработки программного обеспечения и, соответственно, достаточно сильно отличаются.

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

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