Методология CCM (Capability Maturity Model for Software) – модель развития способности организации разрабатывать и сопровождать программные продукты) в менеджменте качества проектов
Категория реферата: Рефераты по менеджменту
Теги реферата: рассказы, quality assurance design patterns системный анализ
Добавил(а) на сайт: Дунаев.
Предыдущая страница реферата | 1 2 3 | Следующая страница реферата
3.2 Уровни оценки зрелости ОКП (областью ключевых процессов)
«управление требованиями» 7
3.3 Уровни оценки зрелости ОКП «планирование проекта» 8
3.4 Уровни оценки зрелости ОКП «управление деятельностью — контроль над ходом проекта» 9
3.5 Уровни оценки зрелости ОКП «процессы, связанные с оценкой, выбором и организацией работ с поставщиками» 11
3.6 Уровни оценки зрелости ОКП «контроля качества» 12
3.7 Уровни оценки зрелости ОКП «Управление конфигурацией»
14
4. Основные выводы
15
5. Литература
17
Введение
В настоящее время, в условиях конкуренции, перед организациями ставится
очевидная задача - завоевать СВОЕГО клиента. А также удержать его. Для
этого необходимо вовремя установить потребности клиентов и предложить тот
самый продукт, который полностью удовлетворит эту потребность.
С появлением в России частных организаций, занимающихся хозяйственной
деятельностью, и появлением новых технологий в области программного
обеспечения, у организаций возникла потребность в автоматизации учета этой
самой деятельности.
Удовлетворить такую потребность взялись несколько организаций, среди
которых московская фирма «1:С». Но одна она просто физически не
справлялась с такой задачей. Вследствие чего был создан такой институт как
«1:С-Франчайзинг». Таким образом, у фирмы появились партнеры –
внедренческие организации, занимающиеся удовлетворением потребностей в
автоматизации учета непосредственно на местах.
Но любая потребность после её удовлетворения, порождает другую потребность, и тот, кто вовремя её выявит и предложит варианты ее удовлетворения
оказывается в выигрыше.
Основной деятельностью внедренческой фирмы- франчайзи является оказание
услуг по внедрению в организации автоматизированного учета; то есть
непосредственно «на местах» выявляют эти самые потребности и ищут варианты
их удовлетворения.
Для внедрения требований МС ИСО серии 9000:2000 необходимо определить
наиболее острые проблемы управления предприятиями. В работе
охарактеризованы «болезни российского менеджмента», некоторые из них
рассматриваются авторами на примере информационных служб, чья деятельность
связана с разработкой и сопровождением программного обеспечения (ПО). Такой
выбор обусловлен следующими причинами.
I. Использование информационных технологий (ERP-систем, средств
телекоммуникаций и т. п.) является залогом эффективного внедрения
современных методов управления предприятием. Внутренние иформационные
службы и внешние консалтинговые организации внедряют и сопровождают
данные технологии на предприятии. От качества их работы во многом зависит
успех непрерывного улучшения бизнес-процессов предприятия (BPI - Business
Processes Improvement);
II. Именно в области информационных технологий (ИТ) наиболее явно
проявляется такой принцип МС ИСО 9000:2000, как «Лидерство». Лидер
стремится применять новые подходы и методы, направленные на эффективное
использование вычислительной техники (ВТ) и выявление будущих потребностей
пользователя. Лидеры закладывают в информационной системе (ИС) предприятия
возможности, которые в текущий момент еще не полностью используются, но в
будущем дадут предприятию широкий маневр для развития бизнеса.
III. Развитие средств телекоммуникаций (E-mail, Интернет, ICQ и т. п.)
готовит революцию в области организации производства, которую можно
сравнить с революцией конца XIX в., вызванной развитием железных дорог и
использованием расписаний. Область программирования и сопровождения ИС -
авангардная в новой промышленной революции . Происходит перераспределение
центров производства ПО. Средства телекоммуникаций делают равнозначными
рабочие места, расположенные в соседних комнатах и удаленные на десятки
тысяч километров друг от друга. Уже сейчас ведущие западные фирмы за счет
субподрядчиков из Индии или России могут удешевить работы в 30 раз и
добиться круглосуточного сопровождения ПО, тем самым, повышая качество
сопровождения на порядок. Но для ведущих фирм США, Европы использование
субподрядчиков из России связано с риском получить некачественную и
несвоевременно исполненную работу. Для России существует угроза остаться на
обочине глобального перераспределения центров разработки ПО. Так, Индия в
1999 г. заработала 2 млрд долл., получая субподрядные работы на разработку
ПО и передачу результатов заказчику через Интернет, Россия - только 70 млн
долл.
Некачественная работа российских информационных служб, кроме того, является
сдерживающим фактором развития всего промышленного сектора в России. Для
решения задачи организации работ по развитию ПО с начала 90-х годов в США
(затем и во всем мире) используется методология СММ (Capability Maturity
Model for Software) — Эволюционная модель развития способности компании
разрабатывать и сопровождать ПО, которую поддерживает SEI (Software
Engineering Institute) — Институт разработки ПО. Этот институт входит в
состав американского университета Карнеги-Мелона. Использование СММ
позволит российским предприятиям поставить разработку ПО на промышленную
основу, повысить производственную культуру, гарантировать качественную
работу и исполнение проектов точно в срок.
Далее элементы СММ соотносятся с под-элементами МС ИСО 9001:2000, названия
которых заключены в скобки.
СММ рассматривается через призму практического опыта ее внедрения Центром
информационных технологий «Платон» (г. Пенза) в Управлении Информатизации
(далее УИ) — служба одного из крупнейших предприятий региона, и в
Информационной организации «CIT» (далее CIT).
В УИ до августовского кризиса 1998 г. работала сильная команда, создавшая и
сопровождающая ИС предприятия. После него данное предприятие применило
«даунсайзиш» (снижение затрат за счет массового сокращения кадров), в
результате произошла потеря лидеров. Вся деятельность УИ базировалась на
личностях, а не на процедурах. Бизнес данного предприятия сильно зависел от
ИС, поэтому крах последней означал крах самого предприятия. В этих условиях
началось внедрение СММ. Перед УИ были поставлены следующие цели:
задача минимум - стабилизировать ситуацию эксплуатации и сопровождения ИС
(качество ИС не должно упасть по сравнению с «докризисным» периодом);
среднесрочная задача — темпы развития ИС предприятия не должны снижаться в
условиях ограничения ресурсов (сохранить качество процессов при снижении
стоимости);
задача максимум — добиться высокого уровня развития и сопровождения ИС, независимо от внешней и внутренней среды (добиться постоянного уровня
качества ИС).
Достижение данных целей на практике означало решение задачи BPI в УИ и
выход на второй уровень СММ с направлением на третий уровень. Была
выполнена только задача минимум.
Сравним результаты, полученные УИ и CIT.
Структура СММ. Сопоставление СММ и МС ИСО 9001:2000
По степени погружения в СММ информационная служба может быть аттестована по
одному из пяти уровней зрелости, представленных на схеме 1 (данные уровни
соотносятся с уровнями BPI ).
I. Хаос (начальный уровень) — Initial — «самоорганизующийся хаос». Качество
ПО и процессов его разработки на данном уровне является случайной вели-
Схема 1
[pic]чиной и напрямую зависит от способностей отдельных сотрудников.
Стоимость разработки ПО высока, результат непредсказуем. Для нашего примера
(внедрение СММ в УИ) на данном уровне решается задача минимум.
П. Контроль (повторяемость) — Repeatable — осуществление планирования, налаживание учета и контроля деятельности, и, как следствие, балансировка
основных целей. При выходе на второй уровень деятельность предприятия
становится прозрачной, возможно повторение ранее достигнутых успехов.
Качество ПО все еще зависит от способностей отдельных личностей. Основное
внимание на данном уровне уделяется управляющим процессам. Результат
становится предсказуемым. Для нашего примера на данном уровне решается
среднесрочная задача.
III. Начало оптимизации (определенность) — Difmed — управляющие и
прикладные действия по работе над ПО задокументированы, стандартизованы и
объединены в общий для всех проектов процесс создания ПО. Данный уровень
характеризуется точной временной оценкой деятельности и расчетом
себестоимости продукта. Целью (и критерием выхода на данный уровень)
является создание «инкубатора лидеров». Качество ПО не зависит от
способностей отдельных личностей. Основное внимание уделяется
прикладным процессам и организационной поддержке. На данном уровне
решается задача максимум.
IV. Управление - Managed - собраны подробные данные о процессах работы над
ПО и компонентах продукции. Все процессы и компоненты продукции
количественно оцениваются и контролируются. Основное внимание на данном
уровне уделяется качеству продукции и процессов работы.
V. Высокая оптимизация - Optimizing — обеспечивается BPI при помощи
количественных оценок и внедрения инновационных идей и технологий.
Каждый уровень СММ характеризуется областью ключевых процессов (ОКП). ОКП -
совокупность взаимосвязанных процессов, которые при совместном выполнении
приводят к достижению определенного набора целей. Достижение всех целей в
рамках ОКП для определенного уровня СММ определяет соответствие организации
данному уровню. Если хотя бы одна цель хоть одной ОКП уровня СММ не
достигнута, то организация не может соответствовать данному уровню СММ. ОКП
можно разбить на три категории: управляющие (Management), организационные
(Organization) и обеспечивающие (Engineering) (табл. 1).
СММ не определяет все процессы, имеющие отношение к разработке программного
обеспечения; выделяются только те, которые необходимы для достижения уровня
СММ, они и включаются в ОКП. Каждая ОКП разбивается на пять общих свойств
(Common Features): обязательство выполнить (Comment to perform);
способность выполнить (Ability to Perform); выполняемые действия
(Activities Performed); измерение и анализ (Measurement and Analysis);
проверка реализации (Verifying Implementation).
Общее свойство «Выполняемые действия» описывает действия, которые
необходимо выполнить для достижения целей ОКП, остальные четыре общих
свойства описывают формальные факторы, делающие процесс частью
корпоративной культуры (следование курсу непрерывного улучшения). Полное
выполнение всех ключевых приемов (key practice) из всех общих свойств
обеспечивает достижение целей ОКП. Ключевые приемы описывают, каким должен
стать рабочий процесс (или элемент процесса, или часть инфраструктуры), но
не определяют способ достижения (конкретные технологии или методики), хотя
для некоторых ключевых приемов даются общие рекомендации. Для различных
условий один и тот же результат может достигаться разными способами.
Ключевые приемы — это скорее общие принципы работы, чем конкретные
действия. Последовательное выполнение общих свойств фактически реализует
цикл BPI (схема 2), т. е. непрерывное улучшение бизнес-процессов.
Таблица 1 - Каждый уровень СММ характеризуется областью ключевых
процессов (ОКП).
|Уровни |Категории процессов |
|зрелост| |
|и | |
| |управляющие |организационные |обеспечивающие |
|V. |Управление процессами | |Управление качеством|
|Высокая|через количественные | |ПО |
|оптимиз|оценки | | |
|ация | | | |
|IV. | |Управление |Предотвращение |
|Управле| |изменением |дефектов |
|ние | |технологии | |
| | |Управление | |
| | |изменением процессов| |
|III. |Общее управление ПО |Организация работ |Проектирование ПО |
|Начало |Координация совместной |внутри групп |Выявление дефектов |
|оптимиз|работы групп |Создание |на ранних стадиях |
|ации | |функциональных | |
| | |моделей | |
| | |организационных | |
| | |процессов Программа | |
| | |обучения персонала | |
|II. |Управление требованиями | | |
|Контрол|Управление | | |
|ь |субконтрактами Контроль | | |
| |за выполнением проектов | | |
| |Планирование проектов | | |
| |Обеспечение качества ПО | | |
| |Управление конфигурацией| | |
|I. Хаос|Случайные процессы | | |
Схема 2 - цикл BPI (непрерывное улучшение бизнес-процессов)
[pic]
Цикл BPI действует на каждом уровне СММ. В табл. 2 проведены параллели
между общими свойствами СММ и элементами стандарта ИСО 9001:2000.
Таблица 2 - параллели между общими свойствами СММ и элементами стандарта
ИСО 9001:2000.
|Общие свойства СММ |МС ИСО 9001:2000 |
|1. Обязательство |5. Ответственность руководства |
|выполнить | |
|2. Способность |6. Управление ресурсами |
|выполнить | |
|3. Выполняемые |7. Реализация продукции (частично): 7.2. Процессы, |
|действия |связанные с потребителем; 7.3. Проектирование и |
| |разработка; 7.4. Закупки; 7.5. Деятельность по |
| |производству и обслуживанию продукции |
|4. Измерение и |8. Измерение, анализ и улучшение (I часть): 8.1. |
|анализ |Планирование; 8.2. Измерение и мониторинг; 8.3. |
| |Управление несоответствиями; 8.4. Анализ данных для |
| |улучшения |
|5. Проверка |8. Измерение, анализ и улучшение (11 часть): 8.5. |
|реализации |Улучшение |
Далее детализируется соответствие общего свойства «Выполняемые действия»
ОКП второго уровня СММ с элементом «7. Реализация продукции» МС ИСО
9001:2000.
7.2. Процессы, связанные с потребителем — управление требованиями
В этой ОКП описывается порядок действий, обеспечивающий появление понятных
и заказчику, и исполнителю требований к конечному продукту. Данная ОКП
определяет следующие цели:
1. Системные требования, предъявляемые к ПО, должны быть контролируемыми
и являться основой для проектирования ПО и диспетчеризация хода выполнения
проекта.
2. Планы разработки ПО, продукция и действия сохраняют непротиворечивость с предъявляемыми системными требованиями.
Достижение этих целей подразумевает наличие:
системы разработки технических заданий (ТЗ) на ПО (как начало управления
требованиями);
системы заявок и уточнений на протяжении всего жизненного цикла ПО;
технологии согласования требований на протяжении всего жизненного цикла ПО
(электронная почта, системы электронных сообщений, система управления
документооборотом и т. п.).
Уровни оценки зрелости ОКП «Управление требованиями» даны в табл. 3.
Таблица 3 - Уровни оценки зрелости ОКП «Управление требованиями»
|Качественная характеристика уровня зрелости |% |
|0. Требования заказчика формулируются и принимаются в устной форме и |0 |
|затем нигде не фиксируются | |
|1 . Требования заказчика фиксируются в разрозненных документах; |20 |
|прослеживаемости исполнения нет | |
|2. Ведется диспетчирование заявок заказчика, стадии их исполнения, |40 |
|уровень удовлетворенности заказчика | |
|3. Тесная координация работы с Заказчиком, заказчик интегрируется в |60 |
|процесс разработки ПО | |
|4. Накапливаются формализованные знания (метрики) по удовлетворенности|80 |
|заказчика (для планирования приоритетов) | |
|5. Система управления знаниями (СУЗ) в повседневной работе помогает |100|
|заказчику конфигурировать заявки на ПО с учетом будущих потребностей | |
Для повышения качества процесса управления требованиями необходимо, чтобы
культурой обмена электронными заявками (письмами, требованиями и т. п.)
обладал не только разработчик, но и заказчик.
УИ в начале внедрения СММ находилось на уровне 15% зрелости данной ОКП. В
начале 1999 г. в УИ внедрялась система учета заявок от подразделений
предприятия (на базе BPI-компоненты — ПО, направленного на преобразование
заявок в конкретные задания для персонала). Попытка не удалась, и уровень
управления требованиями остался прежним.
CIT в 1999 г. находилась на уровне 15%. С вводом в практику приема
заявок заказчиков по E-mail, автоматического формирования
заданий в Prose Уровень зрелости, %
[pic]
Рис. 1. 1 -УИ; 2- CIT оценивается на 40% .
(связанных с данными заявками), учета удовлетворенности и пожеланий
заказчиков, уровень зрелости данной ОКП здесь
7.3. Планирование проектирования и разработки — планирование проекта
ОКП «Планирование проекта» осуществляется в рамках трехуровнего
внутрифирменного планирования. Внутрифирменное планирование включает:
I. «Стратегическое и годовое тактическое планирование», определяющее задачи
и финансовые результаты, которых организация хочет достичь в заданный
плановый период;
II. «Объемно-календарное планирование» (или «Планирование
проекта»), определяющее этапы исполнения проекта, календарный график начала
и завершения этапов, результат этапов;
III. «Задание на выполнение работ», подразумевающее детализацию
выполнения проекта до индивидуальных заданий исполнителям с определением
нормативной трудоемкости, квалификационных требований и используемого
инструментария,
Таблица 4 - Уровни оценки зрелости ОКП «Планирование проекта»
|Качественная характеристика уровня зрелости |% |
|0. Планирования нет, есть авральное реагирование на внешние события |0 |
|1. В наличии первый уровень планирования (на базе бюджетирования) |20 |
|2. Наряду с первым уровнем вводится третий уровень планирования, |40 |
|второй уровень планирования — формальный | |
|3. Работают все уровни планирования, центральное место занимает |60 |
|второй уровень (оценка альтернативных решений) | |
|4. Накапливаются формализованные знания (метрики) по элементам |80 |
|планирования (качество, время, ресурсы, взаимодействие, риски, | |
|реагирование, условия заказчика), что позволяет получать качественные| |
|планы второго уровня | |
|5. СУЗ автоматически отслеживает критические моменты, помогая в |100|
|перепланировании | |
Уровни оценки зрелости ОКП «Планирование проекта» показаны в табл. 4.
Первый уровень планирования реализуется с помощью финансового плана с
детализацией по отдельным бюджетам организации. Второй уровень является
одним из элементов ТЗ или договора с заказчиком. Как и ТЗ, «Планирование
проекта» не является жестким требованием, а, скорее, прогнозом реализации
проекта. Обязательство исполнения точно в срок связано не со вторым, а с
третьим уровнями планирования — «Задание на выполнение работ». Данная ОКП
ставит следующие цели:
1. Нормативы на разработку ПО (временные и стоимостные оценки)
должны быть задокументированы для использования при планировании и
отслеживании проектов.
2. Действия и обязательства по проектам должны планироваться и
документироваться.
3. Задействованные группы и личности должны выполнять обязанности, связанные с проектом.
УИ в начале внедрения СММ находилось на первом уровне оценки зрелости
данной ОКП (20%). В 1999 г. в УИ внедрялся третий уровень планирования (на
базе той же BPI-компоненты). Попытка не удалась. В УИ уровень управления
проектами остался прежним.
CIT в 1999 г. находилась на уровне 20%. С вводом в повседневную практику
Рис. 2 - уровень зрелости данной ОКП в «CIT» оценивается на 40%
Уровень зрелости, %
[pic]
формирования заданий, а также учета выполненных в рамках данных заданий
работ (ПО «Prose», далее Prose), уровень зрелости данной ОКП в «CIT»
оценивается на 40% (рис. 2).
7.3.1. Управление деятельностью — контроль над ходом проекта
В рамках данной ОКП производится детальный учет по видам работ каждого
конкретного исполнителя, тем самым накапливаются статистические данные для
формирования метрик (количественных характеристик действующих процессов
предприятия). Для накопления статистики и контроля над ходом проекта
предпочтительно использовать коллективные системы ведения проекта на базе
профессиональных СУБД. В процессе учета производится автоматическое
накопление данных для их дальнейшего анализа и преобразования в нормативы.
Данная ОКП базируется на следующих принципах организации работ:
Вовлечение персонала. Диспетчеризация осуществляется индивидуально каждым
работником.
Разбиение работ на стадии', организация работы — выполнение работы —
продвижение работы . Внимание направлено на помощь в организации работ
(когда исполнитель сам планирует сроки и приоритеты выполнения заданий), а
также в продвижении работы (демонстрация уровня и качества работы).
Действуем по принципу: Работа учтена — она есть.
Работа не учтена — ее нет.
При наличии третьего уровня планирования контроль над выполнением проекта
необходимо производить в рамках спланированных заданий, обеспечивая
реальный учет работ, диспетчирование проекта и контроль узких мест в
реальном режиме времени.
Данная ОКП ставит следующие цели:
1. Результаты и характеристики выполняемого проекта должны
постоянно сравниваться с плановыми.
2. Корректирующие действия должны выполняться тогда, когда действительные
результаты значительно отклонились от плановых.
3. Изменение обязанностей должно согласовываться с задействованными
группами и конкретными работниками.
Вначале УИ находилось на первом уровне оценки зрелости данной ОКП (20%). В
1999 г. в УИ была частично внедрена диспетчеризация работ персонала, но это
не стало постоянной практикой, и УИ осталось на прежнем уровне. Наблюдается
тенденция к снижению уровня ОКП до 15% (табл. 5).
CIT в 1999 г.
Уровень зрелости, %
[pic]
Рис. 3. 1 - УИ; 2 - CIT
находилась на уровне 20%. С вводом в повседневную практику формирования
заданий, а также учета с помощью Prose выполненных
Таблица 5 - Управление деятельностью — контроль над ходом проекта -
Качественная характеристика уровня зрелости - тенденция к снижению уровня
ОКП
|Качественная характеристика уровня зрелости |% |
|0. Контроля нет, есть кризисное управление внеурочными работами |0 |
|1. Существует практика ежедневного обхода рабочих мест |20 |
|2. Существует практика ведения электронного журнала выполненных работ |40 |
|по персональным заданиям | |
|3. Существует практика регулярной оценки выполнения проекта для |60 |
|выявления отклонений от плана | |
|4. Накапливаются формализованные знания (метрики) по трудовым |80 |
|процессам, что позволяет персонально оценивать свою деятельность и | |
|самостоятельно реагировать на отклонения | |
|5. СУЗ автоматически осуществляет контроль исполнения, напоминая |100|
|исполнителям об отклонениях в деятельности | |
в рамках задания работ (индивидуальное диспетчирование), уровень зрелости
данной ОКП оценивается в 40% (рис. 3).
7.4. Закупки — управление работами с субподрядчиками
Данная ОКП (табл. 6) определяет процессы, связанные с оценкой, выбором и
организацией работ с поставщиками (в том числе и поставщиками решений).
Здесь подразумеваются следующие принципы работы.
Таблица 6 - Данная ОКП определяет процессы, связанные с оценкой, выбором и
организацией работ с поставщиками - Качественная характеристика уровня
зрелости
|Качественная характеристика уровня зрелости |% |
|0. Практики передачи работ субподрядчику нет |0 |
|1 . Существует разовая практика работы с субподрядчиками на договорной|20 |
|основе, партнерских отношений нет | |
|2. Имеется практика фиксирования выполненных работ субподрядчиком, |40 |
|дающая возможность оценивания | |
|3. Существует систематическая практика оценки (выгодно «сделать самим |60 |
|или заказать субподрядчикам»), идет формирование партнерских отношений| |
|с поставщиками | |
|4. Накапливаются формализованные знания (метрики) по качеству и срокам|80 |
|выполнения работ поставщиками; субподрядчики полностью интегрированы в| |
|процесс создания ПО | |
|5. СУЗ автоматически осуществляет контроль выполнения субподрядчиками |100|
|работ, напоминая им об отклонениях в их деятельности; знания | |
|становятся доступными и субподрядчикам | |
Субподрядчик рассматривается как партнер, с которым ведутся работы на
долгосрочной основе. Если субподрядчик тебя подвел, не выполнив взятые на
себя обязательства, виноват не он, а ты, так как выбрал его в качестве
партнера, не просчитав все риски.
Данная ОКП определяет следующие цели:
1. Генеральный подрядчик должен выбирать только качественных
субподрядчиков.
2. Генеральный подрядчик и субподрядчик должны согласовать друг с другом
свои обязательства.
3. Генеральный подрядчик и субподрядчик должны поддерживать постоянную
связь.
4. Генеральный подрядчик должен постоянно отслеживать реальные результаты
деятельности субподрядчика и сравнивать их с его обязательствами.
УИ в начале внедрения СММ находилось на первом уровне оценки зрелости
данной ОКП (20%). В 1999 г. в УИ была внедрена система ведения заявок
субподрядчикам (сначала на базе E-mail, затем на базе Интернет). Это
позволило организовать коллективную работу в системе управления заявками и
оценивать исполнительскую дисциплину субподрядчиков. В УИ уровень
управления работами с субподрядчиками поднялся до 40%.
Уровень зрелости, %
[pic]
Рис. 4. 1 - УИ; 2 - CIT
CIT в 1999 г. находилась на уровне 20% зрелости ОКП. С вводом в
повседневную практику формирования заявок к субподрядчикам, а также
учета выполненных работ на базе E-mail, уровень зрелости данной ОКП
оценивается в 30% (рис. 4).
7.5.3. Идентификация и прослеживаемость — обеспечение качества
Рекомендуется использовать данную ОКП наряду с методологией PSP (Personal
Software Process — программное обеспечение ПК) [7], где львиная доля работ
по контролю качества ПО возлагается на разработчика. По данным SEI [8]
разработчик находит ошибки в 10 раз быстрее и в десять раз больше, чем
тестировщик. Если выполняются действия по определению требований к ПО и по
оценке критериев качества ПО, то работы по автономному тестированию (т.е.
тестированию отдельных кусков ПО) считаются экономически невыгодными.
Тестировщики осуществляют тестирование системы по принципу «черного ящика», т. е. осуществляют общесистемное тестирование.
Данная ОКП определяет следующие цели:
1) деятельность по обеспечению качества ПО должна планироваться;
2) должен обеспечиваться объективный контроль за строгим соответствием ПО
и процессов принятым стандартам, процедурам и требованиям;
3) задействованные группы и конкретные работники должны информироваться о
действиях по обеспечению качества и об их результатах;
4) вопросы несоответствия требованиям, которые невозможно разрешить в
рамках проекта, должны решаться на высшем уровне компании.
УИ в начале внедрения СММ находилось выше нулевого уровня оценки зрелости
данной ОКП (10%). В 1999 г. в УИ попытались внедрить учет дефектов с
назначением ответственных за дефект. В реальной работе учет дефектов не
использовался. Сейчас уровень обеспечения качества ПО снизился до 5%.
CIT в 1999 г. находилась на уровне 10% зрелости по данной ОКП. С вводом в
повседневную практику
Уровень зрелости,
[pic]
Рис. 5. 1" УИ; 2 - CIT
учета дефектов с помощью Prose уровень оценивается в 30%. Наблюдается
тенденция к его повышению (рис. 5, табл. 7).
Таблица 7 - Качественная характеристика уровня зрелости контроля качества
|Качественная характеристика уровня зрелости |% |
|0. Контроля качества ПО нет, есть повседневная практика — «лучшим |0 |
|контролером ПО является пользователь» | |
|1. Существует практика «полицейского контроля», с определением |20 |
|виновного и его «материальным наказанием» | |
|2. Существует практика тотального учета дефектов в разрезе выполненных|40 |
|работ и исполнителей; за выявленный дефект исполнитель не | |
|наказывается, идет стимулирование раннего обнаружения дефектов | |
|3. Существует практика регулярного измерения уровня качества ПО и |60 |
|планирование повышения качества | |
|4. Накапливаются формализованные знания (метрики) по причинам, |80 |
|вызывающим дефекты, что позволяет исполнителям самостоятельно и | |
|своевременно выявлять и исправлять дефекты | |
|5. СУЗ позволяет планировать предупреждающие действия по исключению |100|
|дефектов. | |
Рекомендуем скачать другие рефераты по теме: решебник 10 класс, бесплатно ответы.
Предыдущая страница реферата | 1 2 3 | Следующая страница реферата