1.3. Обзор модели зрелости процессов разработки
1.3. Обзор модели зрелости процессов разработки
Хотя зачастую инженеры-разработчики и менеджеры хорошо осведомлены о своих проблемах, их взгляды на то, какие усовершенствования являются наиболее важными, могут быть различными. Без организованной стратегии усовершенствования трудно достичь согласия между профессионалами-разработчиками и руководством по вопросу, какие именно работы по усовершенствованию следует выполнять первыми. Для того чтобы усилия по усовершенствованию процессов принесли долговременные результаты, необходимо разработать эволюционный путь развития, поэтапно увеличивающий зрелость производственного процесса организации. Концептуальная структура зрелости производственного процесса [Humphrey 87a] упорядочивает эти стадии таким образом, что усовершенствования на каждой предшествующей стадии являются фундаментом усовершенствований последующей стадии. Таким образом, стратегия усовершенствования, предлагаемая концептуальной структурой зрелости производственного процесса, обеспечивает наиболее прямой путь постоянного улучшения производственного процесса. Эта стратегия призвана руководить усовершенствованиями и выявлять недостатки организации; она не предназначена для быстрого «латания дыр» неудачного проекта.
Модель зрелости процессов разработки ПО предоставляет организации-разработчику руководящие принципы управления своими процессами разработки и сопровождения ПО, а также развития культуры управления и программной инженерии. CMM предназначена помогать организациям в выборе стратегий усовершенствования процессов путем определения текущего уровня зрелости производственного процесса и выявления некоторых вопросов, наиболее значимых для повышения качества создаваемого ПО и усовершенствования процессов. Концентрируя свое внимание на конкретном перечне работ и активно добиваясь их выполнения, организация может планомерно совершенствовать свой производственный процесс, обеспечивая устойчивый и постоянный рост его продуктивности.
Многоуровневая структура CMM основывается на принципах обеспечения качества продукта, выработанных за последние шестьдесят лет. В начале тридцатых Валтер Шеварт (Walter Shewart) опубликовал работу, в которой изложил принципы статистического контроля качества. Его идеи были развиты, а их успешное применение было продемонстрировано в работах В. Эдвардса Деминга (W. Edwards Deming) [Deming 86] и Джозефа Джурана [Juran 88, Juran 89]. Эти принципы были развиты институтом SEI в виде концептуальной структуры зрелости процессов, формирующей управленческий и инженерный фундамент для количественного контроля над производственным процессом, что является основой для его непрерывного усовершенствования.
Структура зрелости процессов, в которую вошли эти принципы качества, была впервые намечена Филиппом Кросби в его книге «Quality is Free» [Crosby 79]. Сетка зрелости управления качеством, приведенная Кросби, описывает пять эволюционных фаз во внедрении системы управления качеством. Эта структура зрелости была адаптирована для производственного процесса Роном Радиком (Ron Radice) и его коллегами, работающими под руководством Уотса Хэмфри (Watts Humphrey) из компании IBM [Radice 85]. Хэмфри предложил свою структуру зрелости SEI в 1986 г., добавив концепции уровней зрелости и разработав основу для их текущего использования в программной отрасли.
Ранние версии структуры зрелости процессов разработки, предложенные Хэмфри, описаны в технических отчетах SEI [Humphrey 87a, Humphrey 87b], статьях [Humphrey 88] и в его книге «Managing the Software Process» [Humphrey 89]. Предварительный опросный лист для выявления уровня зрелости [Humphrey 87b] был выпущен в 1987 г. в качестве инструмента, позволяющего организациям определить уровень зрелости их производственных процессов. Для получения характеристик зрелости программного процесса в 1987 г. были разработаны методы внутренней и внешней оценки производственного процесса. Начиная с 1990 г., институт SEI с помощью многих энтузиастов из правительственных и отраслевых структур еще более развил и усовершенствовал эту модель, основываясь на опыте нескольких лет совершенствования производственных процессов.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Обзор: четыре модели использования событий
Обзор: четыре модели использования событий Комбинирование автоматически сбрасываемых и сбрасываемых вручную событий с функциями SetEvent и PulseEvent приводит к четырем различным способам использования событий. Каждая из четырех комбинаций уникальна и каждая из них
1 Скрытые госдотации несвободной модели разработки
1 Скрытые госдотации несвободной модели разработки Российское законодательство об исключительных правах (включая авторские права на программы) формировалось в условиях отсутствия свободно-программного бизнеса. Формально оставаясь нейтральным, законодательство, тем
ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ ЗРЕЛОСТИ ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ
ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ ЗРЕЛОСТИ ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ Спустя два десятилетия, проведенных в ожидании роста производительности и качества ПО вследствие применения новых технологий и методик разработки, промышленные и правительственные организации начали
1.2. Фундаментальные концепции, лежащие в основе понятия зрелости производственных процессов
1.2. Фундаментальные концепции, лежащие в основе понятия зрелости производственных процессов Согласно словарю Вебстера, процесс является «системой операций для производства чего-либо… последовательностью действий, изменений или функций, предназначенных для
ГЛАВА 3. РАБОЧЕЕ ОПРЕДЕЛЕНИЕ МОДЕЛИ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПО
ГЛАВА 3. РАБОЧЕЕ ОПРЕДЕЛЕНИЕ МОДЕЛИ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПО Модель СММ является структурой, представляющей последовательность усовершенствований, которые рекомендуются для организаций-разработчиков, желающих повысить продуктивность своего
ГЛАВА 1 Обзор средств взаимодействия процессов Unix
ГЛАВА 1 Обзор средств взаимодействия процессов Unix 1.1. Введение Аббревиатура IPC расшифровывается как interprocess communication, то есть взаимодействие процессов. Обычно под этим понимается передача сообщений различных видов между процессами в какой-либо операционной системе. При
1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3)
1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3) 1.4.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD
Глава 3 . Связывание модели процессов и модели данных
Глава 3. Связывание модели процессов и модели данных 3.1. Модель данных и ее соответствие модели процессов Функциональная модель BPwin является основой для построения модели данных. Действительно, не имея информации о том, как работает предприятие, бессмысленно строить
3.1. Модель данных и ее соответствие модели процессов
3.1. Модель данных и ее соответствие модели процессов Функциональная модель BPwin является основой для построения модели данных. Действительно, не имея информации о том, как работает предприятие, бессмысленно строить модель данных. Для построения модели данных удобно
4.14. Упражнение 14. Создание модели ТО-ВЕ (реинжиниринг бизнес-процессов)
4.14. Упражнение 14. Создание модели ТО-ВЕ (реинжиниринг бизнес-процессов) Модель ТО-ВЕ создается на основе анализа модели AS-IS. Анализ может проводиться как по формальным признакам (отсутствие выходов или управлений у работ, отсутствие обратных связей и т. д.), так и по
Пример разработки модели одноэтажного коттеджа
Пример разработки модели одноэтажного коттеджа Начать работу необходимо с создания нового проекта. Выполните команду File ? New (Файл ? Новый) или воспользуйтесь комбинацией клавиш Ctrl+N.Переведите систему в метрическую систему измерений (команда меню Design ? Unit of Measure
1. Создание модели процессов в BPwin
1. Создание модели процессов в BPwin 1.1. Инструментальная среда BPwin BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях. Ниже будет описан интерфейс версии 2.5. Рис. 1.1.
1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3)
1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3) 1.5.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как
Паулк Марк
Просмотр ограничен
Смотрите доступные для ознакомления главы 👉