Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Диплом'
certify that was admitted in to and in completed the full course of specialized in By the Resolution of the State Examination Commission of he/she is ...полностью>>
'Документ'
В каком году — рассчитывай, В какой земле — угадывай, На столбовой дороженьке Сошлись семь мужиков: Семь временнообязанных, Подтянутой губернии, Уезда...полностью>>
'Решение'
В соответствии со статьёй 37 Федерального закона от 6 октября 2003 г. №131-ФЗ «Об общих принципах организации местного самоуправления в Российской Фе...полностью>>
'Решение'
В соответствии со статьей 28 Федерального закона от 6 октября 2003 года № 131-ФЗ «Об общих принципах организации местного самоуправления в Российской...полностью>>

Предисловие книга (1)

Главная > Книга #
Сохрани ссылку в одной из сетей:

SW-CMM. CAPABILITY MATURITY MODEL FOR SOFTWARE

МОДЕЛЬ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

v1.10, 25 Сентябрь, 2003

О КНИГЕ

Данный текст является переводом на русский язык описания одного из самых популярных стандартов постановки процесса разработки программного обеспечения (ПО).

О ДАННОЙ ПУБЛИКАЦИИ

Я публикую книгу на своем сайте в открытом доступе для того, чтобы все интересующиеся данным вопросом могли прочитать ее и получить необходимую информацию совершенно свободно и бесплатно. Причина в том, что те методики, которые описаны в данном стандарте, как я считаю, просто обязаны взять на вооружение те разработчики ПО, которые этим занимаются серьёзно. По крайней мере, это касается 2-го и 3-го уровней CMM, так как применение этих практик дает существенное повышение в производительности и устойчивости процесса разработки ПО.

ПРЕДИСЛОВИЕ

Книга, которую вы держите в руках, издается на русском языке впервые. Поводом к ее выпуску послужил стремительно растущий в последнее время интерес в нашей стране к информационным технологиям, а также постоянный спрос среди специалистов на современные методы разработки программного обеспечения, в большой мере обусловленный стремлением российских ИТ компаний выйти на мировой рынок.

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

Однако в последние годы наблюдается взросление экономики страны, а вслед за ней и технологий производства. Возросшая конкуренция на внутреннем рынке и попытки выхода на мировой резко повысили интерес к повышению производительности труда в экономике России, рост которой сейчас напрямую связывают с информатизацией. Возросла ценность программного обеспечения и, таким образом, интерес к постановке индустриального процесса разработки ПО заметно усилился. Отрасль производства программного обеспечения растет и переходит от кустарных разработок к промышленным методам, так как первые просто становятся невыгодны экономически. Кроме того, активно развивается отрасль “оффшорного” программирования, при которой непосредственно производство программ передается в страну, имеющую квалифицированных недорогих специалистов. Таким образом, конкуренция и работа с западными заказчиками стали подталкивать отечественных программистов к совершенствованию своих методов работы.

На сегодняшний день существует множество разнообразных методологий построения процесса разработки ПО, и у каждой из них есть свои плюсы и минусы, области применения, в которых определенные из них наиболее эффективны. Все эти методологии преследуют своей первой целью улучшение производственного процесса, который позволил бы наиболее эффективно и качественно производить программные продукты. Кроме того, некоторые из них предоставляют методику оценки уже существующего технологического процесса, для того чтобы объективно сравнивать разные компании-разработчики по их уровню и производительности. Такие методики оценки используются компаниями-заказчиками для определения уровня исполнителей для своих проектов при принятии решения о заключении контракта.

Одной из наиболее популярных, востребованных и весомых методик на сегодняшний день является модель построения зрелых процессов разработки программного обеспечения SW-CMM (Capability Maturity Model for Software). До сих пор эта модель, разработанная Институтом программной инженерии при Университете Карнеги-Меллон (США), была почти неизвестна в России. Основной причиной этого было отсутствие материалов по этому стандарту на русском языке.

Данный перевод текстов стандарта SW-CMM призван устранить этот пробел и предназначается для всех ИТ специалистов: топ-менеджеров компаний, руководителей проектов, а также рядовых разработчиков. Мы надеемся, что изложенный в книге материал о модели SW-CMM и изложенный в ней опыт успешных и развитых компаний помогут отечественным специалистам повысить эффективность своей работы, выстроить процессы разработки ПО в соответствии с современными требованиями рынка, лучше взаимодействовать с заказчиками и отвечать их запросам.

В заключение хотелось бы персонально поблагодарить тех, кто помогал нам делать данный перевод: сотрудникам компании “Аджаст Медиа”, особенно Наталье Сапрыкиной, подготовившей первую версию глоссария в соответствии с принятой в России стандартной терминологией, а также участникам форума на интернет сайте: Игорю Овсянику (EPAM Systems, Минск), Виктору Малькову (Тэлма, Нижний Новгород), Юрию Назаренко (TelesensKSCL Ukraine Itd.), Михаилу Сабурову, Максиму Локтухину, Алексею Пичкурову, Павлу Можаеву (БНТП, Москва), Александру Бузуну (Тэлма, Нижний Новгород), Александру Ефимову, Batbold Dulguun (The World Bank Junior Professional Associate), активно участвовавших в обсуждении и адаптации перевода основных терминов SW-СММ.

Владимир Рябикин,

ОГЛАВЛЕНИЕ

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.4. Разделы

3.5. Ключевые практики

4. ИСПОЛЬЗОВАНИЕ CMM

4.1. Методы внутренней и внешней оценки производственного процесса

4.2. Различия между внутренними и внешними оценками производственного процесса

4.3. Другие способы использования CMM при усовершенствовании производственного процесса

5. БУДУЩИЕ НАПРАВЛЕНИЯ РАЗВИТИЯ CMM

5.1. Что находится вне области рассмотрения CMM

5.2. Ближайшие задачи

5.3. Долговременные задачи

5.4. Заключение

6. ИСПОЛЬЗОВАНИЕ СТРАНИЦ ОПИСАНИЯ КЛЮЧЕВЫХ ПРАКТИК

7. ИНТЕРПРЕТАЦИЯ CMM

7.1. Интерпретация ключевых практик

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.4.2. Организационная структура

7.4.3. Независимость и организационная структура

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. Экспертные оценки

ПРИЛОЖЕНИЯ

ЦЕЛИ КАЖДОЙ ИЗ ГРУПП КЛЮЧЕВЫХ ПРОЦЕССОВ

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

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

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

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

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

ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ ЗРЕЛОСТИ ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ

Спустя два десятилетия, проведенных в ожидании роста производительности и качества ПО вследствие применения новых технологий и методик разработки, промышленные и правительственные организации начали осознавать фундаментальную проблему, с которой они столкнулись: невозможность управления процессом разработки ПО [DoD 87]. Стало очевидным, что преимущества, возникшие вследствие применения наилучших инструментальных средств и методов разработки, сводятся к нулю при работе в рамках неорганизованного, хаотического проекта. Многие организации отмечают, что завершение проектов зачастую слишком запаздывает, а затраченный бюджет вдвое перекрывает запланированный [Siegel 90]. Как правило, подобные неудачи вызваны тем, что организации не предоставляют своим группам разработчиков необходимой инфраструктуры и поддержки.

Тем не менее случается и так, что даже в недисциплинированной организации отдельные проекты дают превосходные результаты. Успешное завершение подобных проектов, как правило, требует героических усилий со стороны энтузиастов-разработчиков, в отличие от итеративного повторения проверенных методов со стороны организации, обладающей зрелыми производственными процессами. В отсутствие единого для всей организации производственного процесса, повторение достигнутых результатов определяется исключительно участием тех же сотрудников, которые были задействованы в предыдущем проекте. Таким образом, подобный успех определяется участием высококвалифицированных энтузиастов, а не наличием у организации фундамента, способного обеспечить устойчивую, долговременную производительность труда и непрерывное улучшение качества разработок. Достижение же последнего может произойти только в результате сфокусированных и непрерывных усилий, направленных на построение инфраструктуры процессов эффективной программной инженерии и управления.

1.1. Зрелые и незрелые организации-разработчики ПО

Постановка осмысленных целей, направленных на улучшение производственных процессов, требует понимания различий между зрелыми и незрелыми организациями-разработчиками ПО. В незрелых организациях-разработчиках производственный процесс, как правило, импровизируется исполнителями и их руководством. Даже при наличии указаний по определенной организации производственного процесса ими не руководствуются. Незрелая организация-разработчик противодействует любым изменениям, а управляющее звено обычно сфокусировано на решении неотложных проблем (деятельность, известная как «пожаротушение»). Графики работ и бюджеты обычно превышаются вследствие того, что они не основаны на реальных оценках. По мере приближения к критическим срокам сдачи проекта приходится идти на компромисс между сроками выполнения, функциональностью и качеством продукта.

В незрелых организациях не существует объективной основы для вынесения решения о качестве продукта или для решения проблем, связанных с процессами и разрабатываемым продуктом. Вследствие этого качество разработанного программного продукта является трудно предсказуемым. Работы, нацеленные на улучшение качества, такие как экспертные оценки и тестирование, зачастую урезаются или вообще отбрасываются по мере того, как проект выходит за пределы своего графика.

С другой стороны, зрелые организации-разработчики обладают широкими возможностями по управлению процессами разработки и сопровождения ПО. Сферы ответственности внутри производственного процесса точно распределены как среди имеющихся, так и недавно принятых сотрудников, а все работы проводятся в соответствии с запланированным процессом. Установленные процессы пригодны для использования [Humphrey 91b] и соответствуют реально применяемым способам проведения работ. По мере необходимости эти определенные процессы обновляются, а усовершенствования разрабатываются с помощью контролируемого пилотного тестирования и/или анализа затрат и прибылей. Распределение ролей и сфер ответственности в пределах определенного процесса четко определено на протяжении всего проекта и в рамках всей организации.

В зрелой организации, управляющее звено непрерывно следит за качеством программного продукта и за тем, удовлетворен ли заказчик созданным решением. Существует объективная, количественная основа для вынесения решения о качестве продукта, а также анализа проблем, возникающих с продуктом или процессом. План-графики и бюджеты реалистичны и основаны на показателях производительности предыдущих проектов; как правило, достигаются ожидаемые результаты по затратам, срокам разработки, функциональности и качеству продукта. Кратко говоря, соблюдается точное следование упорядоченному процессу, так как все участники проекта понимают важность его соблюдения, а для поддержки процесса разработки существует необходимая инфраструктура.

Реализация этих наблюдений о зрелых и незрелых организациях требует создания структуры, обеспечивающей достижение зрелости производственных процессов. Эта структура предназначена для описания эволюционного пути от специально создаваемых, хаотических процессов к зрелым, упорядоченным производственным процессам. Без этой структуры программы улучшения процессов могут стать неэффективными, вследствие отсутствия необходимых предпосылок для поддержки последовательных усовершенствований. Структура поддержки зрелости производственных процессов представляет собой интеграцию концепций самого производственного процесса, его возможностей, производительности и зрелости. Каждая из этих концепций будет обсуждена далее.

1.2. Фундаментальные концепции, лежащие в основе понятия зрелости производственных процессов

Согласно словарю Вебстера, процесс является «системой операций для производства чего-либо ... последовательностью действий, изменений или функций, предназначенных для достижения окончания или результата». Комитет IEEE определяет процесс как «последовательность шагов, выполняемых для достижения заданной цели» [IEEE-STD-610]. Производственный процесс может быть определен как набор операций, методов, практик и преобразований, используемых разработчиками для создания и сопровождения ПО и связанных с ним продуктов (например, планов проекта, проектных документов, кодов, сценариев тестирования и руководств пользователя). По мере того, как организация становится более зрелой, ее производственный процесс становится все более четко определенным и последовательно применяемым в рамках всей организации.

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

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

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

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

По мере роста зрелости своего производственного процесса, организация-разработчик институционализирует производственные процессы с помощью политик, стандартов и организационных структур. Институционализация подразумевает создание инфраструктуры и корпоративной культуры, которые поддерживают методы, практики и бизнес-процедуры, сохраняя эти достижения после того, как разработавшие их сотрудники покинут организацию.

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 с помощью многих энтузиастов из правительственных и отраслевых структур еще более развил и усовершенствовал эту модель, основываясь на опыте нескольких лет совершенствования производственных процессов.



Скачать документ

Похожие документы:

  1. Предисловие книга (2)

    Книга
    Автор и составитель архива: ЧЕРНОБРОВ Вадим АлександровичПо состоянию на 2.09.2002."ХРОНИКИ ВИЗИТОВ НЛО"ПРЕДИСЛОВИЕКнига, в которой впервые раскрываются советские и российские архивы наблюдений НЛО.
  2. В. Х. Кандинского Л. Л. Рохлин предисловие книга

    Книга
    Книга о жизни и творчестве отечественного психиатра В. X. Кандинского представляет собой самостоятельный раздел русской и мировой истории психиатрии. Она, как и каждое историческое исследование, устанавливает преемственность прошлого с современностью.
  3. А. М. Фитерман теория и практика перевода с английского языка на русский издательство литературы на иностранных языках москва 1963 предисловие книга

    Книга
    Книга «Теория и практика перевода с английского языка на русский» рассчитана на студентов языковых институтов, филоло­гических факультетов и курсов иностранных языков.
  4. Необходимое предисловие книга

    Книга
    Книга, предлагаемая вашему вниманию, по праву считается главным произведением Алистера Кроули - автора, обладающего образцово дурной репутацией в мистических кругах Запада.
  5. А. В. Виннер Как работать над пейзажем масляными красками Профиздат, 1971 год Предисловие Книга

    Книга
    Книга А. В. Виннера посвящена технике живописи пейзажа масляными красками. В ней используется ценнейший опыт лучших русских и советских мастеров-пейзажистов, рассказывается о технике их мастерства.

Другие похожие документы..