Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Стандарт СММ

 

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

Разработка такого обзора была вызвана запросом американского федерального правительства на предоставление метода оценки субподрядчиков для разработки ПО. Реальная же проблема состояла в неработоспособности управлять большими проектами. Во многих компаниях проекты выполнялись со значитель­ным опозданием и с превышением запланированного бюджета. Необходимо было найти решение данной проблемы.

В сентябре 1987 г. SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также оп­росник, предназначавшийся для выявления областей в компа­нии, в которых были необходимы улучшения. Однако большин­ство компаний рассматривало данный опросник в качестве гото­вой модели, вследствие этого через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия CMM (Version 1.0), вышедшая в 1991 г., в 1992 г. была пересмотрена участниками рабочей встре­чи, в которой принимали участие около 200 специалистов в об­ласти ПО, и членами общества разработчиков.

В результате был выпущен стандарт CMM, Version 1.1, который до настоящего времени активно используется во всем мире.

Причины такого интереса к СММ понятны. Несмотря на то что и сами разработчики ПО, и их руководство зачастую очень хорошо знают свои постоянные проблемы, они не могут прийти к единому мнению о том, какие изменения необходимы компа­нии в первую очередь. Без выработки единой стратегии проведе­ния улучшений руководство не может найти взаимопонимания со своими сотрудниками относительно наиболее приоритетных задач по улучшению. Для достижения максимального результата от усилий, потраченных на улучшение процессов, необходимо иметь поэтапную стратегию развития, которая позволит улуч­шать зрелость процессов разработки постепенно, эволюцион­ным путем.

Постоянное улучшение процессов базируется на постепенном взращивании культуры компании, а не на проведении революци­онных инноваций. В СММ представлена схема такого постепен­ного улучшения, разделенная по пяти уровням зрелости процес­сов. Эти пять уровней представляют собой шкалу (рис. 1.) для оценки уровня зрелости процессов разработки ПО в компании и для измерения их параметров.

Приведем основные характеристики каждого уровня:

1. Начальный уровень. Процесс разработки носит хаотиче­ский характер. Определены лишь немногие из процессов, и ус­пех проектов зависит от конкретных исполнителей.

2. Повторяемость. Установлены основные процессы управле­ния проектами: отслеживание затрат, графика работ и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах (проектах с аналогичными приложениями).

3. Разработка. Процессы разработки ПО и управления про­ектами описаны и внедрены в единую систему процессов компа­нии. Во всех проектах используется стандартный для организа­ции процесс разработки и поддержки ПО, адаптированный под конкретный проект.

4. Контроль. Собираются детальные количественные дан­ные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных.

5. Улучшение качества. Постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

 

<== предыдущая лекция | следующая лекция ==>
Серия стандартов ISO 9000 | Процесс сертификации программ на базе информации об их использовании
Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 1221; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.012 сек.