
- •Марк Паулк, Билл Куртис, Мэри Бет Хриссис, Чарльз в. Вебер, Сьюзен м. Гарсия, Мерилин Буш cmmi Product Team модель зрелости процессов разработки программного обеспечения предисловие
- •Глава 1. Основные понятия зрелости производственных процессов
- •1.1. Зрелые и незрелые организации-разработчики по
- •1.2. Фундаментальные концепции, лежащие в основе понятия зрелости производственных процессов
- •1.3. Обзор модели зрелости процессов разработки
- •Глава 2. Пять уровней зрелости производственного процесса
- •2.1. Поведенческие характеристики уровней зрелости
- •2.1.1. Уровень 1 — начальный уровень
- •2.1.2. Уровень 2 — повторяемый уровень
- •2.1.3. Уровень 3 — определенный уровень
- •2.1.4. Уровень 4 — управляемый уровень
- •2.1.5. Уровень 5 — оптимизирующий уровень
- •2.2. Понимание концепций уровней зрелости
- •2.2.1. Понимание концепции начального уровня
- •2.2.2. Понимание повторяемого и определенного уровней
- •2.2.3. Понимание управляющего и оптимизированного уровней
- •2.3. Представление о производственном процессе
- •2.4. Продуктивность процесса и прогнозирование производительности
- •2.5. Пропуск этапов развития организации
- •Глава 3. Рабочее определение модели зрелости процессов разработки по
- •3.1. Внутренняя структура описания уровней зрелости
- •3.2. Уровни зрелости
- •3.3. Группы ключевых процессов
- •3.5. Ключевые практики
- •Глава 4. Использование смм
- •4.1. Методы внутренней и внешней оценки производственного процесса
- •4.2. Различия между внутренними и внешними оценками производственного процесса
- •4.3. Другие способы использования cmm при усовершенствовании производственного процесса
- •Глава 5. Будущие направления развития смм
- •5.1. Что находится вне области рассмотрения cmm
- •5.2. Ближайшие задачи
- •5.3. Долговременные задачи
- •5.4. Заключение
- •Глава 6. Использование страниц описания ключевых практик
- •7.2. Интерпретация разделов
- •7.2.1. Обязательства по выполнению Положения политики
- •Лидерство
- •7.2.2. Необходимые предпосылки Ресурсы и финансирование
- •Обучение
- •Ориентация
- •Начальные условия
- •7.2.3. Выполняемые операции
- •Типы планов
- •Формальные планы
- •Неформальные планы
- •В соответствии с документированной процедурой
- •Отнесенные к по системные требования
- •Отношения типа «поставщик — заказчик»
- •Отслеживание процесса разработки по с принятием корректирующих мер в сравнении с управлением ходом работ
- •Контроль в сравнении с экспертной оценкой
- •Помещение в систему управления конфигурацией в сравнении с управлением и контролем
- •7.2.4. Измерения и анализ
- •7.2.5. Проверка внедрения
- •Регулярный надзор со стороны высшего руководства
- •Регулярный и событийный надзор со стороны руководства проекта
- •Действия по обеспечению качества по
- •7.3. Интерпретация определения производственного процесса
- •7.3.1. Концепции определения процесса
- •7.3.2. Концепции, касающиеся основных средств производственного процесса организации Основные средства производственного процесса организации (ппо)
- •Стандартный производственный процесс организации (сппо)
- •Архитектура производственного процесса
- •Элемент производственного процесса
- •Утвержденное описание жизненных циклов по
- •Инструкции и критерии адаптации
- •База данных производственного процесса организации
- •Библиотека документации по производственному процессу
- •7.3.3. Концепции, связанные с производственным процессом проекта Описание производственного процесса проекта
- •Операции
- •Промежуточные программные продукты (результаты проекта)
- •Программные продукты
- •7.3.4. Взаимосвязь между производственным процессом проекта и планом разработки по
- •7.3.5. Жизненные циклы и cmm
- •7.3.6. Технология и cmm
- •7.3.7. Документация и cmm
- •7.3.8. Сбор и анализ данных процесса
- •7.4. Организационная структура и роли
- •7.4.1. Организационные роли
- •Менеджер
- •Руководитель высшего звена
- •Менеджер проекта
- •Производственный менеджер проекта
- •Линейный менеджер
- •Ведущий специалист
- •Персонал, разработчики, сотрудники
- •7.5. Применение профессиональной оценки
- •Глава 8. Уровень 2: повторяемый уровень
- •8.1. Управление требованиями
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •8.2. Планирование проекта
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •8.3. Отслеживание хода проекта и контроль над ним
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •8.4. Управление производственным субподрядом
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •8.5. Обеспечение качества по
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •8.6. Управление конфигурацией по
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •Глава 9. Уровень 3: определенный уровень
- •9.1. Координация производственного процесса организации
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •9.2. Определение производственного процесса организации
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •9.3. Программа обучения
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •9.4. Интегрированное управление разработкой по
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •9.5. Инженерия разработки программного продукта
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •9.6. Межгрупповая координация
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •9.7. Экспертные оценки
- •Обязательства по выполнению
- •Необходимые предпосылки
- •Выполняемые операции
- •Измерения и анализ
- •Проверка внедрения
- •Обеспечение качества по
- •Управление конфигурацией по
- •Оглавление
Неформальные планы
Обычно для описания неформального плана достаточно одной ключевой практики. Подпрактики включают сведения о содержании плана, а также описывают процедуру его создания и переработки.
В соответствии с документированной процедурой
Документированная процедура обычно нужна для автоматизации повторяющихся задач и действий. Кроме того, использование такой процедуры позволяет сотрудникам с общими представлениями о той или иной группе ключевых процессов быстро научиться аналогичному способу выполнения задачи/операции. Это один из аспектов установления процесса.
Формальность и уровень детализации документированной процедуры может варьировать в значительных пределах (от записанной от руки индивидуальной процедуры до формальной стандартизированной последовательности действий, выполняемых на уровне организации в целом). Формальность и уровень детализации зависят от лица, выполняющего соответствующую задачу или действие (отдельный сотрудник или их группа), частоты выполнения, важности и предполагаемого использования результатов, а также предполагаемых лиц, которым эти результаты будут направлены.
Отнесенные к по системные требования
Установленные для ПО системные требования обычно называются в СММ «установленными требованиями». Они представляют собой подгруппу системных требований, которые необходимо реализовать в программных компонентах системы. Установленные требования являются исходными данными для плана разработки ПО. Анализ требований к ПО позволяет уточнить и документировать установленные требования.
Требования заказчика относятся ко всей системе, а не только к ПО. В рамках СММ центральным пунктом обсуждения требований заказчика являются те требования, которые должны быть реализованы в создаваемом ПО. Отнесение системных требований к ПО, аппаратным средствам и т. д., являясь стадией общего проектирования системы, обычно выполняется группой системного проектирования. Установленные требования включают в себя как технические (функциональные возможности, производительность и т. д.), так и прочие требования (сроки поставки, затраты и т. д.).
Отношения типа «поставщик — заказчик»
Заказчик может располагаться как внутри организации, так и вне ее (внутренний и внешний). Примером внутреннего заказчика является группа маркетинга, а примером внешнего, скажем, Министерство обороны. Пользователь может отличаться от заказчика, как это обычно и бывает в случае заключения контрактов с военными ведомствами. Модель СММ выражается в терминах внешнего поставщика, обеспечивающего систему критически важным программным компонентом.
При необходимости границы между группами должны быть истолкованы должным образом, как это указано в СММ. Например, если по контракту требуется поставить только ПО, между разработчиками программы и заказчиком может быть прямая связь (без участия группы системного проектирования). В этом случае требования заказчика, системные и установленные требования могут являться синонимами. При этом сфера ответственности группы системного проектирования делится между заказчиком и группой разработчиков ПО.
Отслеживание процесса разработки по с принятием корректирующих мер в сравнении с управлением ходом работ
В разделе «Отслеживание хода проекта и контроль над ним» на втором уровне многие ключевые практики содержат следующие выражения: «…процесс отслеживается…принимаются корректирующие меры». В разделе «Интегрированное управление разработкой ПО» на третьем уровне, напротив, в большинстве аналогичных практик употребляется слово «управление». Различие между этими терминами отражает отсутствие в проекте законченного производственного процесса на втором уровне. В подобных случаях обычно требуются действия управленческого характера. В то же время на третьем уровне проекта производственный процесс уже полностью определен, четко обозначены отношения между различными программными продуктами, задачами и действиями. Управленческий подход больше подходит для прогнозирования проблем и их профилактики. При необходимости вмешательства его последствия учитываются на уровне всего производственного процесса, что позволяет более эффективно выбирать и вносить изменения.