Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

Capability Maturity Model



План:


Введення

Capability Maturity Model - модель зрілості можливостей створення ПО : еволюційна модель розвитку здатності компанії розробляти програмне забезпечення.


1. Історія

У листопаді 1986 року американський інститут Software Engineering Institute (SEI) спільно з Mitre Corporation почали розробку огляду зрілості процесів розробки програмного забезпечення, який був призначений для допомоги в поліпшенні їх внутрішніх процесів.

Розробка такого огляду була викликана запитом американського федерального уряду на надання методу оцінки субпідрядників для розробки ПЗ. Реальна ж проблема полягала в нездатності управляти великими проектами. У багатьох компаніях проекти виконувалися зі значним запізненням і з перевищенням запланованого бюджету. Необхідно було знайти рішення даної проблеми.

У вересні 1987 року SEI випустив короткий огляд процесів розробки ПЗ з описом їх рівнів зрілості, а також опитувальник, що призначався для виявлення областей в компанії, в яких були необхідні поліпшення. Однак, більшість компаній розглядало даний опитувальник в якості готової моделі, внаслідок чого через 4 роки запитальник був перетворений в реальну модель, Capability Maturity Model for Software (CMM). Перша версія СММ (Version 1.0), що вийшла в 1991 році, в 1992 році була переглянута учасниками робочої зустрічі, в якій брали участь близько 200 фахівців в області ПО, і членами суспільства розробників. [1]


2. Рівні

  1. Початковий. Найпримітивніший статус організації. Організація здатна розробляти ПЗ. Організація не має явно усвідомленого процесу, і якість продукту цілком визначається індивідуальними здібностями розробників. Один проявляє ініціативу і команда слід його вказівкам. Успіх одного проекту не гарантує успіх іншого. При завершенні проекту не фіксуються дані про трудовитратах, розкладі і якості.
  2. Повторюваний. В деякій мірі відстежується процес. Робляться записи про трудовитратах і планах. Функціональність кожного проекту описана в письмовій формі. У середині 99 лише 20% організацій мали 2-й рівень або вище.
  3. Встановлений. Мають певний, документований і встановлений процес роботи, не залежний від окремих особистостей. Тобто Вводяться узгоджені проф. Стандарти, а розробники їх виконують. Такі організації в змозі досить надійно передбачати витрати на проекти, аналогічні виконаним раніше.
  4. Керований. Можуть точно передбачити терміни і вартість робіт. Є база даних накопичених вимірів. Але немає змін при появи нових технологій і парадигм.
  5. Оптимізований. Є постійно діюча процедура пошуку і освоєння нових і поліпшених методів та інструментів.

3. Розвиток

Використання моделі на практиці виявило неоднозначність у підходах до досягнення більш високих рівнів організації процесів розробки ПЗ. Тому до 2002 року розробляються рекомендації щодо поліпшення процесу розробки, які виходять назву CMMI (Capability Maturity Model Integration). На поточний момент остання версія CMMi - 1.3 (опублікована в листопаді 2010) [2].


Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
V-Model
New Model Army
Ford Model T
Component Object Model
Dual Vee Model
Document Object Model
Model Driven Architecture
Windows Driver Model
Windows Display Driver Model
© Усі права захищені
написати до нас