Модель зрелости процессов разработки программного обеспечения - Марк Паулк

Управление конфигурацией ПО

Цель 1. Управление конфигурацией ПО происходит на плановой основе.

Цель 2. Выбранные промежуточные программные продукты определены, управляемы и доступны.

Цель 3. Изменения в определенных промежуточных программных продуктах происходят управляемым образом.

Цель 4. Распространение информации между группами и сотрудниками, задействованными в проекте, о состоянии и содержании базовых линий конфигурации.

2. Группы ключевых процессов для уровня 3: определенный уровень

Координация производственного процесса организации

Цель 1. Координация мероприятий по разработке и усовершенствованию производственного процесса в рамках всей организации.

Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.

Цель 3. Планирование мероприятий, проводимых на уровне организации в целях разработки и усовершенствования производственного процесса.

Определение производственного процесса организации

Цель 1. Разработка и сопровождение стандартного производственного процесса организации.

Цель 2. Сбор, изучение и распространение информации, связанной с использованием СППО в проектах разработки ПО.

Программа обучения

Цель 1. Мероприятия по обучению проводятся на плановой основе.

Цель 2. Обеспечение обучения навыкам и знаниям, необходимым для выполнения руководящих и технических ролей в процессе разработки ПО.

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

Интегрированное управление разработкой ПО

Цель 1. Получение производственного процесса проекта в виде адаптированной версии СППО.

Цель 2. Планирование проекта и управление им в соответствии с его производственным процессом.

Инженерия разработки программного продукта

Цель 1. Определение, интеграция и последовательное выполнение задач разработки ПО.

Цель 2. Поддержка взаимной согласованности промежуточных программных продуктов.

Межгрупповая координация

Цель 1. Согласование требований заказчика со всеми группами, задействованными в проекте.

Цель 2. Взаимное согласование обязательств между задействованными инженерными группами.

Цель 3. Выявление, отслеживание и разрешение инженерными группами проблем межгруппового взаимодействия.

Экспертные оценки

Цель 1. Планирование работ по проведению экспертных оценок.

Цель 2. Выявление и устранение дефектов в промежуточных программных продуктах.

3. Группы ключевых процессов для уровня 4: управляемый уровень

Количественное управление процессом

Цель 1. Планирование работ по количественному управлению процессом.

Цель 2. Установление количественного контроля над выполнением производственного процесса проекта.

Цель 3. Количественное выражение продуктивности стандартного производственного процесса организации.

Управление качеством ПО

Цель 1. Планирование работ по управлению качеством ПО.

Цель 2. Определение желаемых количественных показателей качества программного продукта и их приоритетов.

Цель 3. Фактический процесс достижения желаемых показателей качества программных продуктов должен быть количественно определен и управляем.

4. Группы ключевых процессов для уровня 5: оптимизирующий уровень

Предотвращение дефектов

Цель 1. Планирование работ по предотвращению дефектов.

Цель 2. Поиск и выявление общих причин возникновения дефектов.

Цель 3. Определение приоритетов для общих причин возникновения дефектов и их систематическое устранение.

Управление технологическими изменениями

Цель 1. Планирование внедрения технологических изменений.

Цель 2. Оценка новых технологий с целью определения их влияния на качество продукта и продуктивность производственного процесса.

Цель 3. Внедрение подходящих новых технологий в производственный процесс организации.

Управление изменениями процесса

Цель 1. Планирование непрерывного усовершенствования процесса.

Цель 2. Участие в работах по усовершенствованию производственного процесса организации должно носить общекорпоративный характер.

Цель 3. Непрерывное усовершенствование СППО и производственных процессов отдельных проектов.

ССЫЛКИ НА ИСПОЛЬЗУЕМУЮ ЛИТЕРАТУРУ

Brooks 87 F.P. Brooks, «No Silver Bullet: Essence and Accidents of Software Engineering», IEEE Computer, Vol. 20, No. 4, April 1987, pp. 10–19.

Crosby 79 P.B. Crosby, Quality is Free, McGraw-Hill, New York, NY, 1979. Curtis 90 B. Curtis, «Managing the Real Leverage in Software

Productivity and Quality,» American Programmer, Vol. 3, No. 7, July 1990, pp. 4–14.

Deming 86 W. Edwards Deming, Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986.

DoD 87 Report of the Defense Science Board Task Force on Military Software, Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September 1987.

Fagan 86 M.E. Fagan, «Advances in Software Inspections», IEEE Transactions on Software Engineering, Vol. 12, No. 7, July 1986, pp. 744–751.

Fowler 90 P. Fowler and S. Rifkin, Software Engineering Process Group Guide, Software Engineering Institute, CMU/SEI-90-TR-24, ADA235784, September 1990.

Freedman 90 D.P. Freedman and G.M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews, Third Edition, Dorset House, New York, NY, 1990.

Gabor 90 A. Gabor, The Man Who Discovered Quality, Random House, New York, NY, 1990.

GAO-92-48 Embedded Computer Systems: Significant Software Problems on C-17 Must Be Addressed, GAO/IMTEC-92-48, May 1992.

Humphrey 87a W.S. Humphrey, Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/ SEI-87-TR-11, ADA182895, June 1987.

Humphrey 87b W.S. Humphrey and W.L. Sweet, A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23, ADA187320, September 1987.

Humphrey 88 W.S. Humphrey, «Characterizing the Software Process», IEEE Software, Vol. 5, No. 2, March 1988, pp. 73–79.

Humphrey 89 W.S. Humphrey, Managing the Software Process, AddisonWesley, Reading, MA, 1989.

Humphrey 91a W.S. Humphrey, D.H. Kitson, and J. Gale, «A Comparison of U.S. and Japanese Software Process Maturity», Proceedings of the 13th International Conference on Software Engineering, Austin, TX, 13–17 May 1991, pp. 38–49.

Humphrey 91b W.S. Humphrey, «Process Fitness and Fidelity», Proceedings of the Seventh International Software Process Workshop, 16–18 October 1991.

IEEE-STD-610 ANSI/IEEE Std 610.12-1990, «IEEE Standard Glossary of Software Engineering Terminology», February 1991.

Imai 86 M. Imai, Kaizen: The Key to Japan’s Competitive Success, McGraw-Hill, New York, NY, 1986.

Juran 88 J.M. Juran, Juran on Planning for Quality, Macmillan, New York, NY, 1988.

Juran 89 J.M. Juran, Juran on Leadership for Quality, The Free Press, New York, NY, 1989.

Kitson 92 D.H. Kitson and S. Masters, An Analysis of SEI Software Process Assessment Results: 1987–1991, Software Ingineering Institute, CMU/SEI-92-TR-24, July 1992.

Paulk 91 M.C. Paulk, B. Curtis, M.B. Chrissis, et al, Capability Maturity Model for Software, Software Engineering Institute, CMU/ SEI-91-TR-24, ADA240603, August 1991.

Paulk 93a M.C. Paulk, B. Curtis, M.B. Chrissis, and C.V. Weber, Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-24, February 1993. Paulk 93b M.C. Paulk, C.V. Weber, S. Garcia, M.B. Chrissis, and M. Bush,

Key Practices of the Capability Maturity Model, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-25, February 1993.

Radice 85 R.A. Radice, J.T. Harding, P.E. Munnis, and R.W. Phillips, «A Programming Process Study», IBM Systems Journal, Vol. 24, No.2, 1985.

Siegel 90 J.A.L. Siegel, et al., National Software Capacity: Near-Term Study, Software Engineering Institute, CMU/SEI-90-TR-12, ADA226694, May 1990.

Weber 91 C.V. Weber, M.C. Paulk, C.J. Wise, and J.V. Withey, Key Practices of the Capability Maturity Model, Software Engineering Institute, CMU/SEI-91-TR-25, ADA240604, August 1991.