Группа стандартов 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) методы разработки, называемые также "легкими" процессами. Они делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте, а также выступают против разработки дополнительных документов, не вносящих непосредственного вклада в получение готовой работающей программы.