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

РефератДопомога в написанніДізнатися вартістьмоєї роботи

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

МІНІСТЕРСТВО ОСВІТИ РОСІЙСЬКОЇ ФЕДЕРАЦИИ.

ПІВДЕННО-УРАЛЬСЬКИЙ ДЕРЖАВНИЙ УНИВЕРСИТЕТ.

ФАКУЛЬТЕТ ЕКОНОМІКИ Й ПРЕДПРИНИМАТЕЛЬСТВА.

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

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

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

Тема: «Методологія CCM (Capability Maturity Model for Software) — модель розвитку здібності організації розробляти і супроводжувати програмні продукти) в менеджменті якості проектов».

Руководитель.

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

" «вересня 2003 г.

Автор работы.

Студент 638 группы.

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

15 вересня 2003 г.

Челябинск.

2003 г.

Введение

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

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

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

Зіставлення СММ і МС ИСО 9001:2000.

3.2 Рівні оцінки зрілості ОКП (областю ключових процессов).

«управління вимогами» 7.

3.3 Рівні оцінки зрілості ОКП «планування проекту» 8.

3.4 Рівні оцінки зрілості ОКП «управління діяльністю — контроль над ходом проекту» 9.

3.5 Рівні оцінки зрілості ОКП «процеси, пов’язані з оцінкою, вибором, і організацією робіт з постачальниками» 11.

3.6 Рівні оцінки зрілості ОКП «контролю за якістю» 12.

3.7 Рівні оцінки зрілості ОКП «Управління конфигурацией».

4. Основні выводы.

Литература

Введение

В час, за умов конкуренції, перед організаціями ставиться очевидна завдання — завоювати СВОГО клієнта. До того ж втримати його вже. Для цього потрібні вчасно встановити потреби клієнтів — і запропонувати той самий продукт, що цілком задовольнить цю потребу. З появою у Росії приватних організацій, котрі займаються господарської діяльністю, і появою нових технологій у галузі програмного забезпечення, у організацій виникла потреба у автоматизації обліку цієї самої діяльності. Задовольнити таку потреба взялися кілька організацій, серед яких московська фірма «1:С». Але одне він фізично не справлялася з такою завданням. Унаслідок чого створили така інституція як «1:С-Франчайзинг». Отже, фірма з’явилися партнери — впроваджувальні організації, займаються задоволенням потреб у автоматизації обліку безпосередньо на місцях. Однак усяка потреба її задоволення, породжує іншу потреба, і той, хто вчасно її виявить і запропонує варіанти її задоволення перебувають у виграші. Основний діяльністю впроводницької фірмифранчайзі є надання послуг за впровадження у організації автоматизованого обліку; тобто безпосередньо «на місцях» виявляють ті ж потреби і посилено шукають варіанти задоволення. Для впровадження вимог МС ИСО серії 9000:2000 необхідно визначити найгостріші проблеми управління тими підприємствами. Діяльність охарактеризовані «хвороби російського менеджменту», окремі розглядаються авторами з прикладу інформаційних служб, чия діяльність пов’язані з із розробкою та супроводом програмного забезпечення (ПО). Такий вибір обумовлений такими причинами. I. Використання інформаційних технологій (ERP-систем, коштів телекомунікацій, і т. п.) є запорукою ефективного впровадження сучасних методів управління підприємством. Внутрішні иформационные служби й зовнішні консалтингові організації впроваджують і супроводжують дані технології для підприємства. Від якості його роботи великою мірою залежить успіх безперервного поліпшення бізнес-процесів підприємства (BPI — Business Processes Improvement); II. Саме галузі інформаційних технологій (ІТ) найбільш явно проявляється такий принцип МС ИСО 9000:2000, як «Лідерство». Лідер прагне застосовувати нові підходи та художні засоби, створені задля ефективне використання обчислювальної техніки (ЗТ) і виявлення майбутніх потреб користувача. Лідери закладають у інформаційній системі (ІВ) підприємства можливості, які у цей час ще повністю використовуються, але у майбутньому дадуть підприємству широкий маневр розвитку бізнесу. III. Розвиток коштів телекомунікацій (Е-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), т. е. безупинне поліпшення бизнес-процессов.

Далі деталізується відповідність загального властивості «Що Їх дії» ОКП другого рівня СММ з елементом «7. Реалізація продукції» МС ИСО 9001:2000. 7.2. Процеси, пов’язані з споживачем — управління вимогами У цьому ОКП описується порядок дій, який би поява зрозумілих і замовнику, і виконавцю вимог до кінцевого продукту. Ця ОКП визначає такі цілі: 1. Системні вимоги, які пред’являються ПО, би мало бути контрольованими і бути підвалинами проектування ПЗ проведено та диспетчеризація ходу виконання проекту. 2. Плани розробки ПО, продукція і дії зберігають несуперечність з що висуваються системними вимогами. Досягнення цього передбачає наявність: системи розробки технічних завдань (ТЗ) на ПО (як початок управління вимогами); системи заявок і уточнень протягом усього життєвого циклу ПО; технології узгодження вимог протягом усього життєвого циклу ПО (електронна пошта, системи електронних повідомлень, систему управління документообігом тощо. п.). Рівні оцінки зрілості ОКП «Управління вимогами» дано у табл. 3.

На підвищення якості процесу управління вимогами необхідно, щоб культурою обміну електронними заявками (листами, вимогами тощо. п.) мав як розробник, а й замовник. УВ на початку впровадження СММ перебувало лише на рівні 15% зрілості даної ОКП. У початку 1999 р. в УВ впроваджувалася система обліку заявок від підрозділів підприємства (з урахуванням BPI-компоненты — ПО, спрямованих перетворення до конкретні завдання персоналу). Спроба виявилася цілком невдалою, і культурний рівень управління вимогами залишився незмінним. CIT 1999 р. перебувала лише на рівні 15%. З її введенням в практику прийому заявок замовників по Е-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) визначає процеси, пов’язані з оцінкою, вибором, і організацією робіт з постачальниками (зокрема і постачальниками рішень). Тут маються на увазі такі принципи работы.

Субпідрядник сприймається як партнер, з яким працюють на довгостроковій основі. Якщо субпідрядник тебе підвів, не виконавши взяті на себе зобов’язання, винен не він, а ти, оскільки вибрав його як партнера, не прорахувавши всі ризики. Ця ОКП визначає такі цілі: 1. Генеральний підрядник повинен вибирати тільки якісних субпідрядників. 2. Генеральний підрядчик і субпідрядник повинні узгодити друг з одним свої зобов’язання. 3. Генеральний підрядчик і субпідрядник повинні підтримувати постійну зв’язок. 4. Генеральний підрядчик повинен постійно відстежувати реальні результати діяльності субпідрядника і порівнювати його з його зобов’язаннями. УВ на початку впровадження СММ перебувало першою рівні оцінки зрілості даної ОКП (20%). У 1999;му р. в УВ було впроваджено систему ведення заявок субпідрядникам (спочатку з урахуванням Е-mail, потім з урахуванням Інтернет). Це дозволило організувати колективну роботу у системи управління заявками і оцінювати виконавчу дисципліну субпідрядників. У УВ рівень управління роботами з субпідрядниками піднявся до 40%. Рівень зрілості, % [pic] Рис. 4. 1 — УВ; 2 — CIT CIT 1999 р. перебувала лише на рівні 20% зрілості ОКП. Із здачею в повсякденну практику формування заявок до субпідрядникам, і навіть обліку виконаних робіт з урахуванням Е-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| |дефектів. | |.

7.5.5. Консервація продукції — управління конфігурацією Ця ОКП спрямовано виключення з практики розробки ПО ситуацій, як у час здачі проекту замовнику (чи виправлень при супроводі) ніхто колектив з працівників організації неспроможна упевнено сказати, які версії програмних модулів, документації, системних бібліотек є остаточними. З використанням субпідрядників (коли розробка ПО складає різних майданчиках) керувати конфігураціями використовується середовище розробки, сприяє синхронізації роботи. Модулі, розроблювані на одному майданчику, після закриття масштабі реального часу стають доступними від використання усім інших майданчиках, незалежно від ступеня видалення. Це завдання вирішується з допомогою перехресних оновлень конфігурацій ПО між майданчиками, провідними паралельну розробку. У ОКП «Управління конфігурацією» входять процеси, пов’язані з підготовкою і відсиланням версій кінцевим користувачам. Якщо останніх розглядати, як партнерів, що у розробці ПЗ проведено та що роблять свої зауваження, то відновлення версій можуть бути досить частими. У разі система «Управління конфігураціями» має стояти у кінцевого користувача і «бути пов’язані з системою урахування вимог (схема 3). Розширення системи управління конфігураціями до користувача зменшує тривалість циклу виконання заявок, підвищує гнучкість і однозначність розуміння, чого хоче замовник. Ця «зв'язка» ставить вищі вимоги до процесів із управління якістю ПО. Схема 3 — система «Управління конфігураціями» [pic] Рівень зрілості, % Ця ОКП ставить такі цілі: 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| |і сценарії тестування, автоматично синхронізує версії різними| | |майданчиках розробки | |.

[pic] Рис. 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 — оцінки зрілості ОКП за підсумками впровадження СММ [pic] III. Були виключені все жорсткі методи; для мотивації персоналу використовувала лише «м'які» методи. Середній вік персоналу в CIT відповідав 26 років. Слід зазначити, що використання у УВ той самий схеми впровадження СММ і методів мотивації не гарантувало б успіху. Проблема глибше — підходи до реалізації принципів «Лідерство» і «Залучення працівників» визначаються типом організаційної структури. Підприємство, в УВ якого здійснювалося впровадження СММ, характеризується організаційної структурою «Ейфелева вежа», десь в результаті жорсткої структури процес «вирощування лідерів» неможливий, тому необхідно ухвалити працювати (чи вибрати з існуючого персоналу) лідера, визнати його лідером, дати належні повноваження. Тільки цьому випадку для підприємства буде внутрішній важіль безперервного поліпшення, який уможливить використання принципів «Лідерство» і «Залучення працівників». CIT характеризується організаційної структурою, що називається як «Розвинена сім'я», де можна налагодити «систему інкубаторів», відтворюють і виховують лідерів, зможуть втягнути весь персонал в безупинне поліпшення, цим забезпечуючи дію засад «Лідерство» і «Залучення працівників». «Якість» організації оцінюється за критеріями, поданих у табл. 9. УВ є досить консервативну організацію. Будь-які організаційні зміни тут мають тенденцію до загасанню. У CIT спостерігаються протилежні тенденції. В основі поставлений принцип «Лідерство», а «Залучення працівників» йде основі «Виховання лідерів». Отже, тут не справі працює парадигма від «якості підприємства» до «якості людини» (у плані). З порівняльного аналізу УВ і CIT (схема 5) бачимо, що з налагодження процесу поліпшення необхідний певний рівень корпоративної культури у організації, інакше все поліпшення тимчасові і швидкоплинні. Схема 5 — з порівняльного аналізу УВ і CIT [pic] Модель СММ по закладених у ній принципам близька до стандарту ИСО 9001:2000. Але й СММ, і ИСО 9001:2000 є лише інструментами для безперервного поліпшення діяльності підприємства. Сертифікація за стандартом ИСО 9001:2000 й підтвердження сертифіката сприятимуть підвищенню якості процесів организации.

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

Показати весь текст

Заповнити форму поточною роботою