ФГБОУ ВПО «АКАДЕМИЯ ГРАЖДАНСКОЙ ЗАЩИТЫ МЧС РОССИИ»

Инженерный факультет

Кафедра информационных систем и технологий

 

 

УТВЕРЖДАЮ

Заведующий кафедрой №31

к.т.н., доцент С.В. Самойлов

Методические рекомендации

по проведению лекции

по учебной дисциплине

«Системная инженерия»

Тема № 2. Модели и процессы управления проектами программных средств. Системное проектирование программных средств

Лекция 2.1. Модели и процессы управления проектами программных средств

 

Время: 2 часа

Учебные группы: …..

Обсуждено на заседании кафедры

(предметно-методической комиссии)

Протокол № …“… ”____ 2012 г.

Химки 2012

 

II. Учебные и воспитательные цели:

Учебные цели: изучить модели и процессы управления проектами программных средств.

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

 

II. Учебно-материальное обеспечение:

6. Методическая разработка на проведение занятия.

7. Слайд-фильм лекции для ПК.

8. Проекционная аппаратура к ПК.

 

Время4часа

III. Расчет учебного времени:

Содержание занятия	Время, мин.
Вступительная часть Проверить подготовленность обучаемых к занятию. Объявить тему, цели занятия, учебные вопросы, порядок их отработки. Назвать учебную литературу.
Учебные вопросы (основная часть)
1. Управление проектами программных средств в системе CMMI. 2. Стандарты менеджмента (административного управле-ния) качеством систем. 3. Стандарты открытых систем, регламентирующие струк-туру и интерфейсы программных средств.
Заключительная часть Напомнить обучаемым вопросы, изученные на занятии, подчеркнуть важность отработанной тематики. Дать задание на самостоятельную подготовку, ответить на возможные вопросы обучаемых.

IV.Литература для самостоятельной работы обучаемых:

а) основная литература:

1. Липаев В.В. Программная инженерия. Методологические основы: Учеб. / В. В. Липаев. Гос. ун-т – Высшая школа экономики. – М.: ТЕИС, 2009. – 608с.

2. Саяпин О.В. Проектирование АСОИУ. Часть 1: Теоретические основы проектирования автоматизированных систем // О.В. Саяпин, С.В. Самойлов, С.В. Чискидов. – Химки: АГЗ МЧС России, 2013. – 168с.

3. Молчанов А.Ю. Системное программное обеспечение / А.Ю. Молчанов. – СПб.: Питер, 2010. – 400 с.

4. Пышкин Е.В. Основные концепции и механизмы объектно-ориентированного программирования : учеб. пособие для студентов вузов / Е.В. Пышкин. – СПб.: БХВ – Петербург, 2005. – 628 с.

5. Соммервилл И. Инженерия программного обеспечения / И. Соммервилл. – М.: Вильямс, 2009. – 624

б) дополнительная литература:

8. Брауде Эрик Дж. Технология разработки программного обеспечения. – СПб, ПИТЕР, 2009. – 655 с.

9. Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб, ПИТЕР, 2004. – 592 с.

10. Якобсон А., Буч Г., Рамбо Д. Унифицированный процесс разработки программного обеспечения. – СПб, ПИТЕР, 2008. – 496 с.

11. Макконнелл С. Совершенный код. – СПб: «Питер», 2009. – 896 с.

12. Канер С., Фолк Д., Нгуен Е.. Тестирование программного обеспечения: – К., Диасофт, 2010. – 544 с.

13. Штерн В. Основы С++. Методы программной инженерии. – Москва: ЛОРИ, 2009 г. – 860 с.

14. Бек К.. Экстремальное программирование. – СПб: ПИТЕР, 2002. – 224 с.

 

в) программное обеспечение современных информационно-коммуникационных технологий:

Персональные компьютеры с доступом в сеть Интернет.

 

 

в) программное обеспечение современных информационно-коммуникационных технологий:

Персональные компьютеры с доступом в сеть Интернет.

 

V. Организационно-методические указания:

 

1. За 2-3 дня до начала занятия преподаватель обязан уточнить:

- состав обучаемых;

- учебные вопросы занятия и их содержание;

- разработать и утвердить план проведения занятия.

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

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

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

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

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

 

Ход занятия

Проверка подготовленности обучаемых к занятию - 5 минут.

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

 

VI. Текст лекции

 

Введение

 

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

 

1 вопрос: Управление проектами программных средств в системе – CMMI

Назначение методологии CMM/CMMI – системы и модели оценки зрелости – состоит в предоставлении необходимых общих рекомендаций и инструкций предприятиям, производящим ПС, по выбору стратегии совершенствования качества процессов и продуктов, путем анализа степени их производственной зрелости и оценивания факторов, в наибольшей степени влияющих на качество ЖЦ ПС, а также посредством выделения процессов, требующих модернизации.

Для достижения устойчивых результатов программной инженерии в процессе развития технологии и организации управления жизненным циклом ПС в стандарте ISO 15504:1-9рекомендуется использовать эволюционный путь, который позволяет совершенствовать и постепенно повышать качество процессов и продуктов, вскрывать преимущества и недостатки предприятия.

В методологии СММ выделены пять уровней зрелости, раскрываемые в этом стандарте де-факто (рис. 3.1).

 

 

Рис. 3.1

 

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

Описание процессов ЖЦ ПС в СММ сфокусировано на поэтапном определении реально достигаемых результатов и на оценивании качества их выполнения. Качество процессов зависит от технологической среды, в которой они выполняются. Зрелость процессов – это степень их управляемости, возможность поэтапной количественной оценки качества, контролируемости и эффективности результатов (см. рис. 3.1). Модель зрелости предприятия представляет собой методический нормативный материал, определяющий правила создания и функционирования системы управления жизненным циклом ПС, методы и стандарты систематического повышения культуры и качества производства. Рост зрелости обеспечивает потенциальную возможность возрастания эффективности и согласованности использования процессов создания, сопровождения и оценивания качества компонентов и ПС в целом. Реальное использование регламентированных процессов предполагает поэтапный контроль и документирование их характеристик качества. На предприятиях, достигших высокого уровня зрелости, формализованные процессы ЖЦ ПС должны принимать статус стандарта, фиксироваться в организационных структурах и определять производственную тактику и стратегию корпоративной культуры производства и системы обеспечения качества ПС.

Уровень 1 – Начальный.Массовые разработки проектов ПС характеризуются относительно небольшими размерами программ в несколько тысяч строк, создаваемых несколькими специалистами. Они применяют простейшие неформализованные технологии с использованием типовых инструментальных компонентов операционных систем. Основные процессы ЖЦ ПС на этом уровне не регламентированы, выполняются не совсем упорядоченно и зависят от некоординированных индивидуальных усилий и свойств отдельных специалистов. Успех проекта, как правило, зависит от энергичности, таланта и опыта нескольких руководителей и исполнителей. Процессы на первом уровне характеризуются своей непредсказуемостью по трудоемкости и срокам в связи с тем, что их состав, назначение и последовательность выполнения могут меняться случайным образом в зависимости от текущей ситуации.

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

Уровень 3 – Определенный – стандартизация процессов. При высоких требованиях заказчика и пользователей к конкретным характеристикам качества сложного ПС и к выполнению ограничений по использованию ресурсов необходимо дальнейшее совершенствование и повышение уровня зрелости процессов ЖЦ ПС. Процессы ЖЦ ПС на этом уровне должны быть стандартизированы и представлять собой целостную технологическую систему, обязательную для всех подразделений. На основе единой технологии поддержки и обеспечения качества ЖЦ ПС для каждого проекта могут разрабатываться дополнительные процессы последовательного оценивания качества продуктов с учетом их особенностей. Описание каждого процесса должно включать условия его выполнения, входные данные, рекомендации стандартов и процедуры выполнения, механизмы проверки качества результатов, выходные данные, условия и документы завершения процессов. В описания процессов включаются сведения об инструментальных средствах, необходимых для их выполнения, роль, ответственность и квалификация специалистов.

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

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

В 2003 году американский Институт программной инженерии (SEI)опубликовал новую комплексную модель CMMI,уточняющую и совершенствующую предшествовавшие модели СММ,а также частично учитывающую основные требования существующих международных стандартов в области менеджмента программных средств. Внедрение этой модели акцентировано на улучшении процессов управления проектами ПС, обеспечении их высокого качества и конкурентоспособности, с основной целью – сделать процессы проектов управляемыми, а результаты – предсказуемыми. Значительное внимание в CMMIуделяется процессам разработки и учету итераций при изменении требований заказчиков, их прослеживанию к функциям, компонентам, тестам и документам проекта. Концепцию, определяющую функциональную пригодность и качество продукта, рекомендуется сопровождать проверками возможных сценариев событий при его применении.

В последнее время появилась информация о модернизации американским Институтом программной инженерии SEI версии CMMI-SE/SW/ IPPD, VI.1 на основе накопленного опыта и отзывов предприятий. Предполагается выпустить в 2006 году новую, существенно модернизированную, версию модели CMMI-VI.2, после чего постепенно должно прекратиться применение версии 1.1. До конца 2007 года должен проводиться переход пользователей на версию CMMI-VI.2, а в дальнейшем она станет обязательной для формализованной оценки качества (сертификации) технологии предприятий в области программной инженерии. При этом срок действия сертификата будет ограничен тремя годами. К этим изменениям следует готовиться после официальной публикации Институтом SEI версии 1.2.

Два варианта модели CMMI – 1.1 созданы для обеспечения непрерывного оценивания комплекса процессов в определенной области создания программных средств или для поэтапного оценивания и совершенствования зрелости предприятия, а также для организации ЖЦ комплексов программ в целом. Модели CMMI представляют помощь специалистам при организации технологии и совершенствовании их продуктов, а также для упорядочения и обслуживания процессов разработки и сопровождения ПС. Концепция этих моделей покрывает управление и оценивание зрелости сложных систем, инженерии программных средств, а также процессов создания интегрированных программных продуктов и совершенствования их разработки. Компоненты непрерывной и поэтапной моделей в значительной степени подобны, могут выбираться и применяться в разном составе и последовательности использования в зависимости от свойств и характеристик конкретных проектов.

Варианты описания моделей построены по единой схеме, которая содержит общие разделы:

предисловие;

1)введение;

2)модель компонентов;

3)терминология;

4) содержание уровней и главные компоненты каждого варианта модели (разработка целей и процедур);

5 раздел – структура взаимодействия процессов. Аннотированы четыре категории процессов раздела 7, их общий обзор и схемы взаимодействия CMMIпроцессов:

менеджмент процессов;

менеджмент – управление проектом;

инжиниринг (технология);

поддержка;

6 раздел – использование модели CMMI –краткие рекомендации для пользователей по применению модели и обучению; отмечается совместимость и соответствие процессов модели с регламентированными процессами предыдущей модели СММв части 2 и 3 стандарта ISO 15504.

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

Первый вариант (непрерывной) модели отражает документ: Capability Maturity Model Integration (CMMI) for Systems Engineering / Software Engineering / Integrated Product and Process Development, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, VI.1, Continuous) – Интегрированная модель оценивания зрелости инженерии систем / программной инженерии / интегрированных продуктов и процессов разработки – непрерывное представление. Вэтой модели седьмой раздел составляют процессы:

- менеджмент процессов.

содержание организационных процессов;

определение организационных процессов;

организация обучения;

организация преобразования (изменений) процессов;

организация инноваций и расширений;

- управление проектом.

планирование проекта;

мониторинг и контроль процессов проекта;

управление соглашениями с поставщиками;

интегрированное управление процессами и продуктами проекта;

управление рисками;

интеграция команды разработчиков;

интегрированное управление поставщиками;

количественное управление проектом;

- инженерия (технология):

управление требованиями;

разработка требований;

технические решения;

интеграция продукта;

верификация;

валидация (аттестация, утверждение);

- поддержка:

управление конфигурацией;

обеспечение качества процессов и продуктов;

измерение и анализ процессов и продуктов;

анализ и принятие решений на изменения;

организация окружения для интеграции;

анализ причин и разрешение проблем (устранение дефектов).

В пяти приложениях приводятся:

А – состав использованных литературных источников и документов, в котором, однако, не упоминаются стандарты ISO;

В – сокращения;

С – глоссарий на основе терминологии ISO,применяемой только в четырех стандартах ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D –описания требований и предложений для формирования компонентов модели по уровням зрелости;

Е – список участников разработки CMMI –проекта.

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

Планирование проекта в этой, так же как и во второй, модели включает:

- оценку возможного размера – масштаба программного продукта;

- оценку сложности функций и характеристик проекта ПС;

- определение модели и этапов жизненного цикла комплекса программ;

- технико-экономическое обоснование проекта – определение стоимости, трудоемкости и длительности ЖЦ ПС;

- разработка поэтапного графика работ и бюджета проекта;

- анализ, идентификация и оценка проектных рисков;

- планирование и управление документированием процессов и продуктов в ЖЦ проекта ПС;

- планирование и распределение технических и людских ресурсов по этапам ЖЦ ПС;

- планирование обеспечения знаний и квалификации коллектива специалистов для реализации проекта;

- обобщение и анализ совокупности планов проекта ПС;

- согласование работ и ресурсов по этапам ЖЦ разработчиком с заказчиком проекта ПС;

- документирование плана работ и утверждение его менеджером разработчиков проекта.

Процессы разработки требований к программному продукту аналогичны процессам в обеих моделях и включают:

- выявление реальных потребностей заказчика и пользователей к функциям и характеристикам программного продукта;

- разработку и согласование между заказчиком и разработчиком исходных, базовых требований к функциям программного продукта;

- определение доступных ресурсов и ограничений проекта комплекса программ;

- декомпозицию базовых исходных требований к функциям ПС в набор требований к компонентам и тестам комплекса программ;

- формализацию требований к интерфейсам между компонентами, с операционной и внешней средой;

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

- разработку требований к обобщенным характеристикам функциональной пригодности и использованию функций программного продукта по назначению. Управление требованиями в обеих моделях включает:

- достижение однозначного понимания требований к проекту ПС заказчиком и разработчиками;

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

- согласованное между заказчиком и разработчиком управление изменениями требований к проекту ПС;

- обеспечение прослеживания корректности изменений от общих требований к проекту ПС до требований к компонентам и частным процессам;

- выявление и идентификация несоответствий между процессами разработки проекта и требованиями заказчика.

Второй вариант CMMIпредставлен документом: Capability Maturity Model Integration for Systems Engineering /Software Engineering /Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, VI.1, Staged) – Интегрированная модель оценивания зрелости инженерии сложных систем / программной инженерии / интегрированных продуктов и процессов разработки – поэтапное представление. Модель базируется на сохранении концепции пяти уровней зрелости СММ.Состав процессов практически повторяет приведенный выше для первого варианта модели, в несколько иной последовательности и с относительно небольшими дополнениями. Первый уровень отличается значительной неопределенностью состава и содержания процессов в различных относительно простых проектах, поэтому он в документе не описан и не комментируется. Поэтому при уточнении и детализации содержания процессов в поэтапном варианте CMMIрекомендуется ограничиваться четырьмя (2-й – 5-й) основными уровнями:

- второй уровень – формализует базовое управление проектами:

управление требованиями;

планирование проекта;

мониторинг и контроль проекта;

управление соглашениями с поставщиками;

измерение и анализ процессов и продуктов;

обеспечение качества процессов и продуктов;

управление конфигурацией;

- третий уровень – содержит стандартизацию основных процессов:

разработка требований;

технические решения;

интеграция продукта;

верификация;

валидация (аттестация);

содержание организационных процессов;

определение организационных процессов;

организация обучения;

интегрированное управление процессами и продуктами проекта;

управление рисками;

интеграция команды разработчиков;

интегрированное управление поставщиками;

анализ и разрешение проблем (устранение дефектов);

организация окружения для интеграции;

- четвертый уровень – определяет количественное управление:

организация представления качества процессов;

количественное управление всем проектом и ресурсами;

- пятый уровень – оптимизационный, непрерывное совершенство
вание:

организация, инновации, количественное управление процессами и обеспечением ресурсами;

анализ причин дефектов, совершенствование качества и управления процессами и продуктами.

Приложения во втором варианте модели подобны по составу приведенным выше приложениям для первой модели. Рекомендуется на каждом более высоком уровне зрелости применять все процессы предыдущих нижних уровней. В обоих вариантах модели каждый, выделенный выше базовый процесс комментируется подробными рекомендациями для его практической реализации, которые содержат унифицированные по структуре описания объемом около 20—30 страниц:

- общие цели процесса, которые должны быть достигнуты;

- вводные замечания и общее описание функций процесса;

- специфические цели процесса;

- менеджмент процесса;

- разработка требований к процессу;

- взаимодействие и интерфейсы с другими процессами;

- практические цели – требуемые результаты действий процесса;

- планирование действий в определенном процессе;

- анализ и валидация (утверждение) результатов реализации процесса;

- мониторинг и контроль выполнения процесса.

Эти рекомендации по объему, содержанию и полноте описаний базовых процессов подобны ряду стандартов профиля ЖЦ ПС. Упорядочение и оценка полноты используемых процессов в соответствии с уровнями зрелости позволяет устанавливать производственный потенциал предприятий – разработчиков программных продуктов по прогнозируемому качеству процессов и результатов их деятельности и готовности к сертификации на соответствие определенному уровню зрелости модели CMMI –1.1.

Особое внимание в моделях CMMIуделяется процессам менеджмента проекта ПС. Эти требования и процессы моделей практически соответствуют регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000, ISO 12207и в основных компонентах профиля стандартов жизненного цикла сложных ПС. Требованиям к процессам в функциональных разделах 4-8 стандартов ISO 9001, ISO 9004, ISO 90003может быть сопоставлен адекватный по содержанию ряд разделов в моделях CMMI –рис. 3.2. Общность процессов и требований состоит в подобии: состава, терминологии, структуры, перечня основных рекомендуемых процессов управления, планирования, учета доступных ресурсов, реализации процессов программной инженерии, оценивания и организации специалистов.

С точки зрения поддержки и регламентирования полного жизненного цикла крупных проектов программных средств к недостаткам моделей CMMIотносительно профиля существующих стандартов ISOможно отнести следующие:

- не все процессы предусмотрены в составе процессов моделей CMMI –1.1, которые развиваются и детально комментируются для их реализации в стандартах ISO 9004:2000и ISO 90003:2004,а также в профиле стандартов ISO;

- не отражены особенности системной инженерии и международные стандарты, регламентирующие процессы жизненного цикла сложных систем ISO 15288:2002и ISO 19760:2003;

 

 

 

Рис. 3.2

 

 

- при анализе процессов обеспечения качества используется ряд
традиционных характеристик систем и программных продуктов, которые
применяются в сложных проектах, однако не описаны и не комментиру
ются базовые международные стандарты, систематизирующие и регла
ментирующие качество программных средств – ISO 9126:1-4, ISO
14598:1-6, ISO 15939;

- отсутствуют описания характеристик и конкретных процессов обес
печения информационной и функциональной безопасности программных
продуктов и ссылки на многочисленные стандарты в этой области;

- не отражены регламентированные интерфейсы Открытых систем на взаимодействие программных компонентов, а также с операционной и внешней средой, в соответствии со стандартами – ISO 9945:1-4;

- документирование процессов и продуктов ЖЦ ПС комментируется только по мере их реализации, и не представлены обобщенные требования к технологической и эксплуатационной документации на программный продукт в соответствии со стандартами – ISO 9294, ISO 15910, ISO 18019.

Для определения представленных выше уровней зрелости процессов обеспечения жизненного цикла ПС разработан и первоначально утвержден в 1998 году обширный технический отчет ISO 15504 –Оценка и аттестация зрелости процессов создания и сопровождения ПС и систем, состоящий из девяти частей и множества приложений. В нем изложены модель зрелости СММ и восемь базовых принципов программной инженерии на основе стандарта ISO 9000:2000(см. лекцию 1). Затем в ISOэтот документ претерпел коренную переработку, сокращение, упрощение структуры и содержания, при полном сохранении целей и концепции, и утвержден как стандарт в составе пяти частей (см. Приложение 1). Стандарт ISO 15504:1-5:2003-2006регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями:

- для установления состояния собственных технологических процессов и их совершенствования;

- для определения пригодности собственных процессов для выполнения определенных требований или классов требований заказчиков;

- с целью его пригодности для выполнения определенных договоров с заказчиками ПС и систем.

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

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

- для аттестаторов зрелости – основу для проведения и совершенствования процессов аттестации.

Аттестация в стандарте рассматривается в двух аспектах: для усовершенствования процессов ЖЦ ПС и систем конкретного предприятия и для определения соответствия декларированной зрелости процессов обеспечения проекта или предприятия реальным используемым процессам. Это отражено в следующих пяти частях стандарта ISO 15504:1-5:2003-2006.

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

Часть 2 – Выполнение (производство) аттестации – включает детальные требования к проведению процессов аттестации, как основы для совершенствования и определения уровня зрелости технологических процессов обеспечения ЖЦ ПС и систем. Документ определяет процессы выполнения аттестации, модели рекомендуемых процессов аттестации и верификации процессов, с тем чтобы они были объективными, содержательными и репрезентативными.

Часть 3 – Руководство по производству аттестации – содержит обзор технологии выполнения процессов аттестации зрелости и интерпретации реализации требований. В нем отражены: исполнение аттестации; измерительные средства для определения процессов зрелости; выбор и применение средств аттестации; оценка компетентности аттестаторов; верификация соответствия аттестации декларированным требованиям. Средства аттестации могут использоваться предприятиями при планировании, менеджменте, мониторинге, контроле и усовершенствовании программных продуктов и систем, при их приобретении, разработке, применении и сопровождении.

Часть 4 – Руководство пользователей для процессов усовершенствования и определения зрелости процессов по этим двум аспектам. Рекомендуется ряд шагов, которые включают: применение результатов процессов аттестации; постановка целей аттестации зрелости; определение исходных данных для аттестации; оценка возможного снижения результирующих рисков; шаги по усовершенствованию процессов; шаги по определению уровня зрелости; сравнение результатов анализа аттестации с требованиями.

Часть 5 – Образец модели процессов аттестации на соответствие требованиям, представленным в части 2. Обширный документ (162 стр.) содержит примеры практического применения предыдущих частей стандарта для организации, оценивания и совершенствования аттестации зрелости процессов жизненного цикла для различных областей использования, проектов программных средств и предприятий.

При практической реализации проектов и обеспечении жизненного цикла сложных ПС разработчикам и поставщикам может быть трудно определить и выделить для применения преимущества моделей CMMI. В зависимости от традиций предприятия и особенностей крупного проекта ПС зачастую целесообразно использовать как основной полный профиль стандартов ISO, а для оценивания заказчиками уровня зрелости менеджмента, организационного и технологического обеспечения проектов ПС применять конкретные рекомендации CMMI. Эти рекомендации могут эффективно использоваться при сертификации качества процессов на предприятиях, обеспечивающих ЖЦ ПС как альтернатива или наряду с сертификацией по комплексу стандартов менеджмента ISO 9000, в зависимости от особенностей проекта и требований заявителя на сертификацию программного продукта или технологии обеспечения его жизненного цикла.

 

2 вопрос: Стандарты менеджмента (административного управления) качеством систем

Серия стандартов ISO 9000:2000 разработана, чтобы помочь предприятиям всех типов и размеров внедрить и использовать эффективные системы менеджмента (административного управления) качества.

Совместно они образуют комплект согласованных стандартов управления системами качества и могут применяться как основа процессов управления в программной инженерии:

- ISO 9000:2000 –представляет введение в системы управления качеством продукции и услуг и словарь качества;

- ISO 9001:2000 –устанавливает детальные требования для систем управления качеством, достаточные в случае необходимости продемонстрировать способность предприятия, обеспечить соответствие качества продукции и услуг требованиям заказчика;

- ISO 9004:2000 –соде