
- •Содержание
- •1.13. Задания для самопроверки 59
- •1.17. Задания для самопроверки 88
- •1.19. Задания для самопроверки 108
- •1.23. Задания для самопроверки 116
- •1.27. Задания для самопроверки 125
- •1.37. Задания для самопроверки 144
- •1.48. Задания для самопроверки 159
- •Перечень рисунков
- •Перечень таблиц
- •Введение
- •Принятые сокращения
- •1.Жизненный цикл разработки по
- •Программные проект и его атрибуты
- •Ролевые модели в программном проекте
- •Размер и сложность программного проекта
- •Характеристики программного проекта
- •Качество программного продукта
- •Экран проекта и сводка о подходе
- •Критерий smart для формулирования целей
- •Критерии успешности программного проекта
- •Модели жизненного цикла
- •Водопадная модель
- •Модель быстрой разработки приложения
- •Пошаговая модель
- •Спиральная модель Боэма
- •Прототипная модель
- •Выбор модели жизненного цикла
- •Задания для самопроверки
- •2.Типовой каркас для разработки по
- •Программная разработка
- •Планирование проекта
- •Модель cocomo для оценки трудозатрат в проекте
- •Модель slim для оценки трудозатрат в проекте
- •Разработка спецификации требований
- •Отслеживание и контроль
- •Верификация и валидация
- •Обеспечение качества
- •Конфигурационное управление
- •Метрики
- •Повышение квалификации
- •Задания для самопроверки
- •3. Модели зрелости способностей cmm/cmmi
- •Ключевые области процесса в модели cmm
- •Характеристика уровней зрелости в модели cmm
- •Интегрированная модель зрелости способностей cmmi
- •История возникновения
- •Уровни зрелости и области процесса
- •Уровни способностей процесса в модели cmmi
- •Специальные и общие цели и практики процессных областей
- •Характеристики уровней зрелости в модели cmmi
- •Задания для самопроверки
- •4.Управление рисками в программном проекте
- •Модели esi и pmi управления рисками
- •Выявление рисков
- •Анализ рисков
- •Расстановка приоритетов для рисков
- •Планирование рисков
- •Исполнение ответных стратегий
- •Оценивание результатов исполнение ответных стратегий
- •Документирование действий по рискам
- •Заключительное оценивание рисков
- •Задания для самопроверки
- •5.Стандарты качества iso в применении к по
- •Структура и принципы семейства стандартов iso 9000
- •Модели iso 9000 на базе процессов
- •Самооценивание по ключевым элементам iso 9000
- •Задания для самопроверки
- •6.Формальные методы в разработке по
- •Инструменты формализации и верификации
- •Взаимодействие функциональностей
- •Интегрированная технология анализа и верификации
- •Задания для самопроверки
- •7.Некоторые общие технологические приемы
- •Инспекции по Фейгану
- •Диаграммы Исикавы («рыбий скелет»)
- •Инструменты
- •Swot-анализ
- •Сбалансированный экран результативности
- •Технологическая дорожная карта
- •Метод Дельфи
- •Деревья решений
- •Сравнительное ранжирование
- •Методология подвижного программирования
- •Принципы подвижного программирования
- •Рабочий цикл и роли участников
- •Рабочие документы и обстановка
- •Задания для самопроверки
- •8.Сертификация программного обеспечения в авиации
- •История создания серии документов do-178 и ed-12
- •Уровни программного обеспечения
- •Процессы жизненного цикла по авиационных систем
- •Цели процессных деятельностей
- •Рабочие документы и категории их контроля
- •Процесс планирования по
- •Процессы разработки по
- •Определение требований
- •Проектирование
- •Кодирование
- •Верификация
- •Конфигурационное управление
- •Обеспечение качества
- •Контакт с органом сертификации
- •Выводы и рекомендации
- •Задания для самопроверки
- •9.Задания для самостоятельной работы
- •Темы, связанные с единым каркасом для разработки по
- •Перечень тем
- •Краткое описание каждой темы
- •Тема 2. Программная архитектура базового инструмента для распределенного управления программными проектами
- •Тема 3. Профили типовых рабочих компонентов для разработки приложений
- •Тема 1. Прототип метрической базы данных для управления разработкой приложений
- •Тема 5. Репозиторий повторно используемых компонентов
- •Тема 6. Сквозной пример для единого каркаса разработки приложений
- •Темы, связанные применением формальных методов перечень тем
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи краткое описание каждой темы
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи
- •10.Литература
- •11.Приложения
- •Шаблон для одностраничного экрана проекта
- •Примерная структура положения о работе и тз
- •Примерная форма еженедельного отчета
- •Примерная форма презентации на ежемесячном операционном обзоре
- •12.Указатель
Уровни зрелости и области процесса
Ключевые области процесса модели CMM превратились в области процесса модели CMMI; и их число увеличилось с 18 до 22, при этом некоторые области исчезли или слились с другими, добавились новые и названия многих областей изменились, более точно отражая существо деятельностей в данной области:
CAR – Causal Analysis and Resolution – анализ и разрешение причин
CM – Configuration Management – управление конфигурацией
DAR – Decision Analysis and Resolution – анализ и принятие решений
IPM – Integrated Project Management – интегрированное управление проектом
MA – Measurement and Analysis – измерение и анализ
OPD – Organizational Process Definition – определение процесса организации
OPF – Organizational Process Focus – нацеленность процесса организации
OPM – Organizational Process Management – управление процессом организации
OPP – Organizational Process Performance – исполнение процесса организации
OT – Organizational Training – обучение в организации (повышение квалификации)
PI – Product Integration – интеграция продукта
PMC – Project Monitoring and Control – наблюдение за процессом и контроль над ним
PP – Project Planning – планирование проекта
PPQA – Process and Product Quality Assurance – обеспечение качества в процессе и продукте
QPM – Quantitative Project Management – количественное управление проектом
RD – Requirements Development – разработка требований
REQM – Requirements Management – управление требованиями
RSKM – Risk Management – управление рисками
SAM – Supplier Agreement Management – управление договорами с поставщиками
TS – Technical Solution – техническое решение
VAL – Validation – валидация (проверка применимости)
VER – Verification – верификация (проверка корректности реализации)
Рис. 25. Мета-модель целей и практик в модели CMMI
В модели CMMI изменилась структура (Рис. 25), по сравнению с моделью CMM. Теперь ее компонентами теперь являются области процесса (PA – Process Areas), три общие цели (GG – Generic Goals), одни и те же для всех областей процесса, и от 1 до 3 специфических целей (SG – Specific Goals), формулируемых отдельно для каждой из них. Для достижения общих целей предлагается использовать 16 общих практик (GP – Generic Practices), а для достижения специфических целей процесса – от 4 до 14 специфических практик (SP – Specific Practices), характерных для каждой отдельной процессной области. Общее число целей (специальных целей областей процесса) – 49, а общее число деятельностей (специальных практик) – 162. Для каждой из 22 процессных областей в модели определены еще и компоненты «для сведения», которыми являются:
заявление о назначении (Purpose Statement) – описывает назначение данной процессной области;
вводные замечания (Introductory Notes) – описывают главные концепции и обосновывают необходимость данной процессной области;
смежные процессные области (Related Process Areas) – перечисление процессных областей, логически связанных с данной; и
примеры рабочих продуктов (Example Work Products) – взятые из опыта примеры продуктов, создаваемых в конкретных специфических практиках для данной области.
Перечень уровней – тот же, что и в модели CMM.
Уровень 1 (начальный – initial) сохранил свое прежнее название и остался тем же. Процесс разработки на этом уровне непредсказуем, плохо контролируем, является реактивным по своей природе.
Уровень 2 (управляемый – managed) сменил прежнее название «повторяемый» на «управляемый». Процесс уже характеризует проекты, часто является реактивным. Он сохранил все 6 ключевых областей того же 2-го уровня модели CMM под теми же или близкими названиями, превратив их в области процесса и добавив только одну новую область.
Уровень 3 (определенный – defined) подвергся наиболее значительным изменениям, хотя и сохранил свое прежнее название. Процесс на этом уровне характеризует уже организацию-разработчика и часто является проактивным. В модели CMMI на этом уровне 11 областей процесса вместо прежних 7 ключевых областей модели CMM. Области (8)-(10) сохранились под теми же или слегка измененными названиями, что и в модели CMM, область (11) объединила в себе 2 прежние ключевые области, и к ним добавились еще 7 новых областей, вобравших в себя прежние 3 ключевые области модели CMM.
Уровень 4 (количественно управляемый – quantitatively managed) сменил прежнее название «управляемый», чтобы подчеркнуть особую роль метрик в процессе этого уровня. Процесс этого уровня измеряем и контролируем. Прежние две области объединились в одну, и добавилась одна новая.
Уровень 5 (оптимизирующий – optimizing) сохранил свое название и сфокусирован на постоянное улучшение самого себя. Он состоит теперь из двух областей процесса вместо прежних трех ключевых областей.
Области процесса разделены на 4 категории: управление процессом, управление проектом, инженерная и поддержка (Рис. 26).
Рис. 26. Группировка процессных областей в модели CMMI
Каждая область появляется на определенном уровне зрелости и должна присутствовать на всех последующих уровнях. Распределение процессных областей по уровням зрелости показано на Рис. 27.
Такое четкое разграничение процессных областей на собственно инженерную деятельность, управление проектом, управление процессом и поддержку, помогает лучше фокусироваться соответствующим исполнителям на своих прямых обязанностях, и способствует более оперативному и профессиональному решению соответствующих производственных вопросов.
Рис. 27. Восхождение по уровням зрелости