Методологія CCM (Capability Maturity Model for Software) - модель розвитку здатності організації розробляти і супроводжувати програмні продукти) у сфері управління якістю проектів




Дата конвертації19.12.2018
Розмір41 Kb.
Типреферат

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ПІВДЕННО-Уральського державного університету

ФАКУЛЬТЕТ ЕКОНОМІКИ І ПІДПРИЄМНИЦТВА

КАФЕДРА ЕКОНОМІКИ ТА ЕКОНОМІЧНОЇ БЕЗПЕКИ

КОНТРОЛЬНА РОБОТА

По курсу «управління якістю реалізації проектів»

Тема: «Методологія CCM (CapabilityMaturityModelforSoftware) - модель розвитку здатності організації розробляти і супроводжувати програмні продукти) у сфері управління якістю проектів»

керівник

професор Пятков Г.Н.

«» Вересня 2003 р

Автор роботи

Студент 638 групи

Гребенщиков І.А.

15 вересня 2003 р

Челябінськ

2003 р

зміст:

1. Введення 2

2. Причини необхідності впровадження менеджменту якості при розробці та забезпеченні програмних продуктів 3

3. Розгляд даної проблеми на прикладі фірми «Платон»

м Пенза 3

3.1 Структура СММ (еволюційна модель розвитку здатності організації розробляти і супроводжувати програмні продукти). Зіставлення СММ і МС ІСО 9001: 2000 4

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 - BusinessProcessesImprovement);

II. Саме в області інформаційних технологій (ІТ) найбільш явно проявляється такий принцип МС ІСО 9000: 2000, як «Лідерство». Лідер докладає зусиль для реалізації нові підходи і методи, спрямовані на ефективне використання обчислювальної техніки (ОТ) і виявлення майбутніх потреб користувача. Лідери закладають в інформаційній системі (ІС) підприємства можливості, які в поточний момент ще не повністю використовуються, але в майбутньому дадуть підприємству широкий маневр для розвитку бізнесу.

III. Розвиток засобів телекомунікацій (E-mail, Інтернет, ICQ і т. П.) Готує революцію в області організації виробництва, яку можна порівняти з революцією кінця XIX в., Викликаної розвитком залізниць і використанням розкладів. Область програмування і супроводу ІС - авангардна в новій промислової революції. Відбувається перерозподіл центрів виробництва ПО. Засоби телекомунікацій роблять рівнозначними робочі місця, розташовані в сусідніх кімнатах і віддалені на десятки тисяч кілометрів один від одного. Вже зараз провідні західні фірми за рахунок субпідрядників з Індії або Росії можуть здешевити роботи в 30 разів і досягти цілодобового супроводу ПЗ, тим самим, підвищуючи якість супроводу на порядок. Але для провідних фірм США, Європи використання субпідрядників з Росії пов'язане з ризиком отримати неякісну та несвоєчасно виконану роботу. Для Росії існує загроза залишитися на узбіччі глобального перерозподілу центрів розробки ПЗ. Так, Індія в 1999 р заробила 2 млрд дол., Отримуючи субпідрядні роботи на розробку ПЗ і передачу результатів замовнику через Інтернет, Росія - тільки 70 млн дол.

Неякісна робота російських інформаційних служб, крім того, є стримуючим фактором розвитку всього промислового сектора в Росії. Для вирішення завдання організації робіт з розвитку ПЗ з початку 90-х років в США (потім і в усьому світі) використовується методологія СММ (Capabili ­ ty Maturity Model for Software) - Еволюційна модель розвитку здатності компанії розробляти і супроводжувати ПО, яку підтримує SEI (SoftwareEngineeringInstitute) - Інститут розробки ПО. Цей інститут входить до складу американського університету Карнегі-Мелона. Використання СММ дозволить російським підприємствам поставити розробку ПЗ на промислову основу, підвищити виробничу культуру, гарантувати якісну роботу і виконання проектів точно в строк.

Далі елементи СММ співвідносяться з під-елементами МС ІСО 9001: 2000, назви яких укладені в дужки.

СММ розглядається через призму практичного досвіду її впровадження Центром інформаційних технологій «Платон» (м Пенза) в Управлінні Інформатизації (далі УІ) - служба одного з найбільших підприємств регіону, і в Інформаційній організації «CIT» (далі CIT).

У УІ до серпневої кризи 1998 р працювала сильна команда, яка створила і супроводжуюча ІС підприємства. Після нього дане підприємство застосувало «даунсайзіш» (зниження витрат за рахунок масового скорочення кадрів), в результаті сталася втрата лідерів. Вся діяльність УІ базувалася на особистостях, а не на процедурах. Бізнес даного підприємства сильно залежав від ІС, тому крах останньої означав крах самого підприємства. У цих умовах почалося впровадження СММ. Перед УІ були поставлені наступні цілі:

задача мінімум - стабілізувати ситуацію експлуатації і супроводу ІС (якість ІС не повинно впасти в порівнянні з «докризових» періодом);

середньострокова завдання - темпи розвитку ІС підприємства не повинні знижуватися в умовах обмеження ресурсів (зберегти якість процесів при зниженні вартості);

задача максимум - домогтися високого рівня розвитку і супроводу ІС, незалежно від зовнішнього і внутрішнього середовища (домогтися постійного рівня якості ІС).

Досягнення цих цілей на практиці означало рішення задачі BPI в УІ і вихід на другий рівень СММ з направленням на третій рівень. Була виконана тільки завдання мінімум.

Порівняємо результати, отримані УІ і CIT.

Структура СММ. Зіставлення СММ і МС ІСО 9001: 2000

За ступенем занурення в СММ інформаційна служба може бути атестована по одному з п'яти рівнів зрілості, представлених на схемі 1 (дані рівні співвідносяться з рівнями BPI).

I. Хаос (початковий рівень) - Initial - «самоорганізується хаос». Якість ПЗ та процесів його розробки на даному рівні є випадковою вели-

схема 1

чиною і безпосередньо залежить від здібностей окремих співробітників. Вартість розробки ПО висока, результат непередбачуваний. Для нашого прикладу (впровадження СММ в УІ) на даному рівні вирішується завдання мінімум.

П. Контроль (повторюваність) - Repeatable - здійснення планування, налагодження обліку і контролю діяльності, і, як наслідок, балансування основних цілей. При виході на другий рівень діяльність підприємства стає прозорою, можливе повторення раніше досягнутих успіхів. Якість ПЗ все ще залежить від здібностей окремих особистостей. Основна увага на даному рівні приділяється керуючим процесам. Результат стає передбачуваним. Для нашого прикладу на даному рівні вирішується середньострокова завдання.

III. Початок оптимізації (визначеність) - Difmed - керуючі і прикладні дії по роботі над ПО задокументовані, стандартизовані і об'єднані в загальний для всіх проектів процес створення ПЗ. Даний рівень характеризується точної тимчасової оцінкою діяльності і розрахунком собівартості продукту. Метою (і критерієм виходу на даний рівень) є створення «інкубатора лідерів». Якість ПЗ не залежить від здібностей окремих особистостей. Основна увага приділяється прикладним процесам і організаційної підтримки. На даному рівні вирішується завдання максимум.

IV. Управління- Managed - зібрані докладні дані про процеси роботи над ПЗ та компонентах продукції. Всі процеси і компоненти продукції кількісно оцінюються і контролюються. Основна увага на даному рівні приділяється якості продукції і процесів роботи.

V. Висока оптимізація - Optimizing - забезпечується BPI за допомогою кількісних оцінок і впровадження інноваційних ідей і технологій.

Кожен рівень СММ характеризується областю ключових процесів (ОКП). ОКП - сукупність взаємопов'язаних процесів, які при спільному виконанні призводять до досягнення певного набору цілей. Досягнення всіх цілей в рамках ОКП для певного рівня СММ визначає відповідність організації даного рівня. Якщо хоча б одна мета хоч однієї ОКП рівня СММ не досягнуто, то організація не може відповідати даному рівню СММ. ОКП може бути розбитий на три категорії: керівники (Management), організаційні (Organiza ­ tion) і забезпечують (Engineering) (табл.1).

СММ не визначає всі процеси, що мають відношення до розробки програмного забезпечення; виділяються тільки ті, які необхідні для досягнення рівня СММ, вони і включаються в ОКП. Кожна ОКП розбивається на п'ять загальних властивостей (CommonFeatures): зобов'язання виконати (Commenttoperform); здатність виконати (AbilitytoPerform); виконувані дії (ActivitiesPerformed); вимір і аналіз (MeasurementandAnalysis); перевірка реалізації (VerifyingImplementation).

Загальна властивість «Що Їх дії» описує дії, які необхідно виконати для досягнення цілей ОКП, інші чотири загальних властивості описують формальні чинники, які роблять процес частиною корпоративної культури (проходження курсу безперервного поліпшення). Повне виконання всіх ключових прийомів (key practice) з усіх загальних властивостей забезпечує досягнення цілей ОКП. Ключові прийоми описують, яким повинен стати робочий процес (або елемент процесу, або частина інфраструктури), але не визначають спосіб досягнення (конкретні технології або методики), хоча для деяких ключових прийомів даються загальні рекомендації. Для різних умов один і той же результат може досягатися різними способами. Ключові прийоми - це швидше загальні принципи роботи, ніж конкретні дії. Послідовне виконання загальних властивостей фактично реалізує цикл BPI (схема 2), т. Е. Безперервне поліпшення бізнес-процесів.

Таблиця 1 - Кожен рівень СММ характеризується областю ключових процесів (ОКП).

рівні зрілості категорії процесів
керуючі організаційні забезпечують
V. Висока оптимізація Управління процесами через кількісні оцінки Управління якістю ПО
IV. управління Управління зміною технології управління зміною процесів запобігання дефектів
III. початок оптимізації Загальне керівництво ПО Координація спільної роботи груп Організація робіт всередині груп Створення функціональних моделей організаційних процесів Програма навчання персоналу

проектування ПО

Виявлення дефектів на ранніх стадіях

II. контроль Управління вимогами Управління СУБКОНТРАКТИ Контроль за виконанням проектів Планування проектів із забезпечення якості ПЗ Управління конфігурацією
I.Хаос випадкові процеси

Схема 2 - цикл BPI (безперервне поліпшення бізнес-процесів)

Цикл 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Уровень зрілості,%

Мал. 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%

Рівень зрілості,%

формування завдань, а також обліку виконаних в рамках даних завдань робіт (ВО «Prose», далі Prose), рівень зрілості даної ОКП в «CIT» оцінюється на 40% (рис. 2).

7.3.1. Управління діяльністю - контроль над ходом проекту

В рамках даної ОКП проводиться детальний облік за видами робіт кожного конкретного виконавця, тим самим накопичуються статистичні дані для формування метрик (кількісних характеристик діючих процесів підприємства). Для накопичення статистики та контролю над ходом проекту переважно використовувати колективні системи ведення проекту на базі професійних СУБД. У процесі обліку проводиться автоматичне накопичення даних для їх подальшого аналізу і перетворення в нормативи.

Дана ОКП базується на наступних принципах організації робіт:

Залучення персоналу. Диспетчеризація здійснюється індивідуально кожним працівником.

Розбиття робіт на стадії ', організація роботи - виконання роботи - просування роботи. Увага направлено на допомогу в організації робіт (коли виконавець сам планує терміни і пріоритети виконання завдань), а також в просуванні роботи (демонстрація рівня і якості роботи). Діємо за принципом: Робота врахована - вона є.

Робота не врахована - її немає.

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

Дана ОКП ставить наступні цілі:

1.Результати і характеристики виконуваного проекту повинні постійно порівнюватися з плановими.

2. Коригувальні дії повинні виконуватися тоді, коли дійсні результати значно відхилилися від планових.

3. Зміна обов'язків має узгоджуватися з задіяними групами і конкретними працівниками.

Спочатку УІ знаходилося на першому рівні оцінки зрілості даної ОКП (20%). У 1999 р в УІ була частково впроваджена диспетчеризація робіт персоналу, але це не стало постійною практикою, і УІ залишилося на колишньому рівні. Спостерігається тенденція до зниження рівня ОКП до 15% (табл. 5).

CIT в 1999 р

Рівень зрілості,%

Мал. 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%.

Рівень зрілості,%

Мал. 4. 1 - УІ; 2 - CIT

CIT в 1999 р перебувала на рівні 20% зрілості ОКП. З введенням в повседневнуюпрактіку формування заявок до субпідрядників, а також

обліку виконаних робіт на базі E-mail, рівень зрілості даної ОКП оцінюється в 30% (рис. 4).

7.5.3. Ідентифікація та простежуваність - забезпечення якості

Рекомендується використовувати дану ОКП поряд з методологією PSP (PersonalSoftwareProcess - програмне забезпечення ПК) [7], де левова частка робіт з контролю якості ПО покладається на розробника. За даними SEI [8] розробник знаходить помилки в 10 разів швидше і в десять разів більше, ніж тестувальник. Якщо виконуються дії по визначенню вимог до ПО і за оцінкою критеріїв якості ПО, то роботи по автономному тестування (тобто тестування окремих шматків ПЗ) вважаються економічно невигідними. Тестировщики здійснюють тестування системи за принципом «чорного ящика», т. Е. Здійснюють загальносистемне тестування.

Дана ОКП визначає наступні цілі:

1) діяльність із забезпечення якості ПЗ повинна плануватися;

2) повинен забезпечуватися об'єктивний контроль за суворим відповідністю ПО і процесів прийнятим стандартам, процедурам і вимогам;

3) задіяні групи і конкретні працівники повинні інформуватися про дії щодо забезпечення якості та про їх результати;

4) питання невідповідності вимогам, які неможливо вирішити в рамках проекту, повинні вирішуватися на вищому рівні компанії.

УІ на початку впровадження СММ знаходилося вище нульового рівня оцінки зрілості даної ОКП (10%). У 1999 р в УІ спробували запровадити облік дефектів з призначенням відповідальних за дефект. У реальній роботі облік дефектів не використовувався. Зараз рівень забезпечення якості ПЗ знизився до 5%.

CIT в 1999 р перебувала на рівні 10% зрілості з даної ОКП. З введенням в повсякденну практику

Рівень зрілості,

Мал. 5. 1 "УІ; 2 - CIT

обліку дефектів за допомогою Prose рівень оцінюється в 30%. Спостерігається тенденція до його підвищення (рис. 5, табл. 7).

Таблиця 7 - Якісна характеристика рівня зрілості контролю якості

Якісна характеристика рівня зрілості %
0. Контролю якості забезпечення немає, є повсякденна практика - «кращим контролером ПЗ є користувач» 0
1. Існує практика «поліцейського контролю», з визначенням винного і його «матеріальним покаранням» 20
2. Існує практика тотального обліку дефектів в розрізі виконаних робіт і виконавців; за виявлений дефект виконавець не карається, йде стимулювання раннього виявлення дефектів 40
3. Існує практика регулярного вимірювання рівня якості ПЗ і планування підвищення якості 60
4. Накопичуються формалізовані знання (метрики) з причин, що викликають дефекти, що дозволяє виконавцям самостійно і своєчасно виявляти і виправляти дефекти 80
5. СУЗ дозволяє планувати запобіжні дії по виключенню дефектів. 100

7.5.5. Консервація продукції - управління конфігурацією

Дана ОКП спрямована на виключення з практики розробки ПЗ ситуацій, коли в момент здачі проекту замовнику (або виправлень при супроводі) ніхто з працівників організації не може з упевненістю сказати, які версії програмних модулів, документації, системних бібліотек є остаточними.

При використанні субпідрядників (коли розробка ПО здійснюється на різних майданчиках) для управління конфігураціями використовується середовище розробки, що сприяє синхронізації роботи. Модулі, які розробляються на одному майданчику, після закриття в масштабі реального часу стають доступними для використання на всіх інших майданчиках, незалежно від ступеня видалення. Це завдання вирішується за рахунок перехресних оновлень конфігурацій ПО між майданчиками, провідними паралельну розробку.

В ОКП «Управління конфігурацією» входять процеси, пов'язані з підготовкою і відсиланням версій кінцевим користувачам. Якщо останніх розглядати як партнерів, що беруть участь в розробці ПЗ і вносять свої зауваження, то оновлення версій можуть бути досить частими. В даному випадку система «Управління конфігураціями» повинна стояти у кінцевого користувача і бути пов'язана з системою обліку вимог (схема 3).

Розширення системи управління конфігураціями на користувача зменшує тривалість циклу виконання заявок, підвищує гнучкість і однозначність розуміння, чого хоче замовник. Дана «зв'язка» ставить вищі вимоги до процесів з управління якістю ПЗ.

Схема 3 - система «Управління конфігураціями»

Рівень зрілості,%

Дана ОКП ставить наступні цілі:

1) діяльність з управління конфігураціями повинна плануватися;

2) знаходяться в роботі ПО повинні бути ідентифіковані, керовані і доступні;

3) зміни в ПО, що знаходяться в роботі, повинні контролюватися;

4) задіяні групи і конкретні працівники повинні інформуватися про статус і зміст основних напрямків розробки ПО.

Рівні оцінки зрілості ОКП «Управління конфігурацією» дано в табл. 8.

УІ знаходилося на рівні 10%. На початку 1999 р в УІ було впроваджено підтримку еталонної версії, в кінці 1999 р - середовище колективної розробки «Roundtable». Але дана система не охоплювала всіх автономних завдань, тобто частина виконавців в УІ знаходиться на рівні зрілості ОКП, що дорівнює 60%, а інша - 0%. Інтегральний показник рівня зрілості ОКП - 30%.

CIT в 1999 р перебувала на рівні 20%. З введенням в повсякденну практику середовища колективної розробки «Roundtable» і інтеграції її з Prose рівень зрілості оцінюється в 70% (рис. 6).

Таблиця 8 - Рівні оцінки зрілості ОКП «Управління конфігурацією»

Якісна характеристика рівня зрілості %
0. Ні практики ведення конфігурацій, кожен виконавець на своєму комп'ютері має версії вихідних файлів, і він же оновлює їх у кінцевих користувачів 0
1. Існує практика еталонної версії, з відповідальним за складання вихідних файлів від усіх виконавців 20
2. Існує технологія ведення сховища ПЗ, куди розробники поміщають останні версії вихідних файлів 40
3. Існує практика використання технологій колективної середовища розробки, де автоматично готуються версії конфігурацій ПЗ 60
4.Накопичуються формалізовані знання (метрики) по стилю і методів розробки, формуються шаблони і сценарії тестування, проводиться регресивний тестування 80
5. СУЗ автоматично оцінює програмний модуль і формує шаблони і сценарії тестування, автоматично синхронізує версії на різних майданчиках розробки 100

Мал. 6. 1-УІ; 2 CIT

Основні висновки

Зрілість процесів роботи над ПЗ в УІ відповідає першому (початковому) рівню СММ. Є викиди в сторону другого рівня СММ тільки по двом ОКП: «Управління робіт з субпідрядниками» та «Управління конфігураціями». Практика нестійка, і УІ може в найближчі півроку «відкотитися» назад. Видно явний провал в ОКП «Забезпечення якості ПЗ». Той стан, в якому знаходиться зараз УІ, означає, що впровадження СММ не відбулися (хоча завдання мінімум в УІ була вирішена). Виділяються три основні причини цього.

I. Керівництво підприємства декларативно підтримувало впровадження СММ в УІ; в своїй повсякденній практиці не використовувало методи СММ. Спрацювало правило: Реальна реорганізація може проводитися тільки зверху.

II. При впровадженні СММ в УІ була обрана сертифікаційна схема, т. Е. Така послідовність: «розробка комплекту документації» -> «нормування» -> «впровадження інформаційних технологій» - »« початок роботи персоналу по СММ ». Комплект документації був прийнятий в УІ як стандарт «де-юре», «де-факто» - робота велася по-старому. Таким чином, проявився принцип «подвійних стандартів». Результатом стало те, що в процесі всіх аудиторських перевірок (яких було дуже багато в рамках вирішення проблеми 2000), керівництво УІ показувало перевіряючим дані документи, - інформаційний аудит проходив «на ура». З практичної точки зору, дані документи коштують менше, ніж папір, на якому вони надруковані.

III. Так як середній вік персоналу УІ був більше 40 років, навчання співробітників йшло повільно. При впровадженні моделі СММ застосовувалися жорсткі методи мотивації персоналу. Поки вище керівництво підтримувало впровадження, темпи були прийнятні, але потім стався відкат. Причому за деякими ОКП відкотилися навіть нижче рівня, з якого починалося впровадження СММ.

Виходячи з оцінки зрілості ОКП за підсумками впровадження СММ, CIT (схема 4) ближче до другого рівня СММ. Спостерігається відставання тільки по двох ОКП: «Управління роботами з субпідрядниками» (пов'язано з тим, що залучення субпідрядників було епізодичним) і «Забезпечення якості ПЗ»

Таблиця 9 - оцінка «Якості» організації за критеріями

оцінка Середній вік персоналу Тип організаційної структури прихильність стандартам бачення перспектив Цілі в колективі
1 від 50 років авторитарна сім'я потрійний стандарт в минулому особисті
2 від 40 років Ейфелева вежа подвійний стандарт в теперішньому вузькі колективні
3 від 30 років ракета єдиний стандарт в ближ. майбутньому на потенціал організації
4 від 20 років розвинена сім'я непрер. поліпшення в перспективі на розвиток суспільства

(Пов'язано з тим, що технологію «Обліку та контролю дефектів» почали впроваджувати в останню чергу, і результати ще не позначилися). Впровадженню СММ в CIT сприяли наступні фактори:

I. Керівництво CIT на всіх рівнях сприяв впровадженню методів СММ; воно першим починало використовувати методи СММ у своїй повсякденній практиці;

П. З огляду на можливість дії принципу «подвійних стандартів» (рис. 6), вибрали наступну схему: «початок роботи персоналу по СММ» - «введення інформаційних технологій» - «нормування процесів» - «розробка комплекту документації». Таким чином, виробнича культура в CIT вирощувалася, а не нав'язувалася, як у УІ.

Схема 4 - оцінки зрілості ОКП за підсумками впровадження СММ

III. Були виключені всі жорсткі методи; для мотивації персоналу використовувалися тільки «м'які» методи. Середній вік персоналу в CIT відповідав 26 років.

Необхідно відзначити, що використання в УІ такої ж схеми впровадження СММ і методів мотивації не гарантувало б успіху. Проблема глибше - підходи до реалізації принципів «Лідерство» та «Залучення працівників» визначаються типом організаційної структури. Підприємство, в УІ якого здійснювалося впровадження СММ, характеризується організаційною структурою «Ейфелева вежа», де з-за

жорсткої структури процес «вирощування лідерів» неможливий, тому необхідно прийняти на роботу (або вибрати з існуючого персоналу) лідера, визнати його лідером, дати відповідні повноваження. Тільки в цьому випадку на підприємстві буде внутрішній важіль безперервного поліпшення, який зробить можливим використання принципів «Лідерство» та «Залучення працівників». CIT характеризується організаційною структурою, що іменується як «Розвинена сім'я», де можна налагодити «систему інкубаторів», що відтворюють і виховують лідерів, які зможуть залучити весь персонал в безперервне поліпшення, тим самим забезпечуючи дію принципів «Лідерство» та «Залучення працівників». «Якість» організації оцінюється за критеріями, представленим у табл. 9.

УІ є досить консервативну організацію. Будь-які організаційні зміни тут мають тенденцію до загасання. У CIT спостерігаються протилежні тенденції. На чолі кута поставлений принцип «Лідерство», а «Залучення працівників» йде на основі «Виховання лідерів». Таким чином, тут на ділі працює парадигма від «якості підприємства» до «якості людини» (в професійному плані). З порівняльного аналізу УІ і CIT (схема 5) робимо висновок, що для налагодження процесу поліпшення необхідний певний рівень корпоративної культури в організації, інакше все поліпшення тимчасові і швидкоплинні.

Схема 5 - порівняльний аналіз УІ і CIT

Модель СММ по закладеним в ній принципами близька до стандарту ІСО 9001: 2000. Але і СММ, і ІСО 9001: 2000 є всього лише інструментами для безперервного поліпшення діяльності підприємства. Сертифікація за стандартом ISO 9001: 2000 і підтвердження сертифіката повинні сприяти підвищенню якості процесів організації.

література

- журнал «ММК» - 2001, № 7 «Досвід підвищення якості діяльності інформаційних служб» С.А. Волчков, І. В. Балахонова, В. В. Спиридонов

с. 14 - 23.




Головна сторінка
Контакти

    Головна сторінка



Методологія CCM (Capability Maturity Model for Software) - модель розвитку здатності організації розробляти і супроводжувати програмні продукти) у сфері управління якістю проектів