Управління конфігурацією в стандартах CMM та ISO 12207

Процес КК в стандарті ДСТУ ISO/IEC 12207

Чому при виборі стандарту, що визначає процес керування конфігурацією, для докладного розгляду ми зупинилися на стандарті ДСТУ ISO/IEC 12207 «Інформаційні технології. Процеси життєвого циклу програмних засобів »? Для цього є декілька важливих причин:

Стандарт ДСТУ ISO/IEC 12207 є російським стандартом, офіційно введеним в дію на території Російської Федерації.

Розглянутий стандарт є перекладом одного з найбільш популярних міжнародних стандартів у сфері інформаційних технологій - ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes.

Популярні методології розробки ПС (такі як Rational Unified Process) грунтуються на ISO/IEC 12207:1995 (ISO/IEC12207) Standard for Information Technology - Software Lifecycle Processes.

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

Російський стандарт ДСТУ ISO/IEC 12207 розглядає процеси життєвого циклу (ЖЦ) програмних засобів (ПС) і поділяє їх на три групи:

Основні.

Допоміжні.

Організаційні.

Процес конфігураційного управління визначається як допоміжний процес (див. рис. 1).

Рис. 1. Процеси життєвого циклу ПС за ДСТУ ISO/IEC 12207.

Стандарт ДСТУ ISO/IEC 12207 встановлює загальну структуру процесів життєвого циклу (ЖЦ) програмних засобів (ПС), визначає процеси, роботи і завдання, виконувані в ході ЖЦ ПС. Даний процес складається з наступних робіт:

підготовка процесу;

визначення конфігурації;

контроль конфігурації;

облік станів конфігурації;

оцінка конфігурації;

управління випуском і постачання.

Підготовка процесу Повинен бути розроблений план управління конфігурацією. План повинен визначати:

роботи з управління конфігурацією;

процедури і графік виконання даних робіт;

організації (та), відповідальну (і) за виконання даних робіт;

зв'язок даній організації (й) з іншими організаціями, наприклад, з розробки та супроводження програмних засобів.

План повинен бути документально оформлений і виконаний. Примітка: Даний план може бути частиною плану управління конфігурацією системи.

Визначення конфігурації

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

Контроль конфігурації

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

Облік станів конфігурації

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

Оцінка конфігурації

Повинні бути визначені і забезпечені: функціональна завершеність програмних об'єктів з точки зору реалізації встановлених до них вимог; фізична завершеність програмних об'єктів з точки зору реалізації у проекті та програмах всіх внесених змін.

Управління випуском і постачання

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

Управління конфігурацією з точки зору Capability Maturity Model CMM (Capability Maturity Model) - модель зрілості процесів створення ПЗ, або еволюційна модель розвитку здатності компанії розробляти якісне програмне забезпечення.

Спочатку CMM розроблялася і розвивалася як методика, що дозволяє великим урядовим організаціям США вибирати найкращих постачальників ПЗ. Для цього передбачалося створити вичерпний опис способів оцінки процесів розробки ПЗ та методики їх подальшого удосконалення. У підсумку авторам вдалося досягти такого ступеня подробиці і деталізації, що стандарт виявився придатним і для звичайних компаній-розробників, що прагнуть якісно поліпшити існуючі процеси розробки, привести їх до певних стандартам.

Співпадіння поняттям стандарту є зрілість організації. Незрілої вважається організація, в якій процес розробки програмного забезпечення залежить тільки від конкретних виконавців та менеджерів, а рішення найчастіше просто імпровізують «на ходу» - те, що сучасною мовою називається творчим підходом, або мистецтвом. У цьому випадку велика ймовірність перевищення бюджету або виходу за рамки термінів здачі проекту, тому менеджери і розробники змушені займатися тільки роздільною здатністю актуальних проблем, стаючи тим самим заручниками власного програмного продукту. На жаль, на даному етапі розвитку знаходиться більшість компаній (по градації CMM цей рівень позначається числом 1).

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

CMM визначає п'ять рівнів зрілості організацій. У результаті атестації компанії присвоюється певний рівень, який надалі може підвищуватися або знижуватися. Слід зазначити, що кожен наступний рівень містить у собі всі ключові характеристики попередніх.

(1) Початковий рівень (initial level) - це основний стандарт. До даного рівня, як правило, відноситься будь-яка компанія, якій вдалося отримати замовлення, розробити і передати замовнику програмний продукт. Підприємства першим рівня не відрізняються стабільністю розробок. Як правило, успіх одного проекту не гарантує успішність наступного. Для компаній даного рівня властиві нерівномірність процесу розробки - наявність авралів в роботі. До цієї категорії можна віднести будь-яку компанію, яка хоч якось виконує взяті на себе зобов'язання.

(2) Повторюваний рівень (repeatable level). Даного рівня відповідають підприємства, що володіють певними технологіями управління проектами. Планування та управління в більшості випадків грунтується на наявному досвіді. Як правило, в компанії даного рівня вже вироблені внутрішні стандарти і організовані спеціальні групи перевірки якості.

(3) Певний рівень (defined level). Рівень характеризується наявністю формального підходу до управління (тобто описані всі типові дії, необхідні для багаторазового повторення: ролі учасників, формати документів, вироблені дії та ін.) Для створення і підтримки подібного стандарту в актуальному стані в організації вже підготовлена спеціальна група. Компанія постійно проводить спеціальні тренінги для підвищення професійного рівня своїх співробітників. Починаючи з цього рівня організація перестає залежати від особистісних якостей конкретних розробників і не має тенденції скочуватися на нижчестоящі рівні. Абстрагування від розробників обумовлено продуманим механізмом постановки завдань та контролю виконання.

(4) Керований рівень (managed level). Рівень, при якому встановлюються кількісні показники якості.

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

З градації рівнів видно, що технологічні вимоги зберігаються тільки до 3-го рівня, далі ж в основному дотримуються вимоги до адміністративного управління. Тобто рівні 4 та 5 здебільшого управлінські і для їх досягнення важливо не тільки випустити програмний продукт, але і проаналізувати хід проекту, а також побудувати плани на майбутній проект, грунтуючись на поточних шаблонах. Застосування даних підходів має забезпечити планомірно-плавне поліпшення використовуваних процесів.

Поки в Росії знають тільки абревіатуру СММ, але не уявляють собі, яким чином можна домогтися якісного стрибка. І справа не тільки в тому, що невідомо напрямок цього стрибка, а в тому, що кожної окремо взятої компанії досить важко вибудувати свої процеси під вимоги CMM самостійно, без зовнішнього втручання. А навіщо винаходити велосипед? Чи не простіше взяти готовий набір рішень оптимізації (наприклад, Rational Unified Process), запровадити його (тут вже можна і своїми силами обійтися), отримавши готовий набір рішень для якісного побудови ПЗ, а вже потім запрошувати фахівців і атестуватися на певний рівень? Як ми вже не раз згадували в цій статті, Rational гарантує отримання 3-го рівня СММ.

На Заході сьогодні вже широко використовують для оптимізації процесу випуску ПО технології компанії Rational Software. Причин цього кілька: по-перше, Rational Software - практично єдина компанія, яка чітко описала весь виробничий цикл з випуску програмного забезпечення (Rational Unified Process), визначила всі можливі види документів, які супроводжують проект, суворо розписала ролі (вхідні/вихідні документи, шаблони документів і пр.) кожного учасника проекту. По-друге, компанія створила спеціальний програмне забезпечення для якісного виконання як кожного етапу в окремо, так і всього проекту в цілому. Важливо і те, що за допомогою Rational RUP пропонує перейти від програмування як мистецтва до програмування як до науки, де все зрозуміло і прозоро завдяки науковому підходу до розробки. За деякими оцінками західних аналітиків, співвідношення повернення капіталу до і після впровадження якісних процесів варіюється від 5:1 до 8:1.

Configuration and Change Management з точки зору CMM і RUP Отже, ми вже торкнулися вимог до якісності процесів, а зараз розглянемо, як RUP регламентує досягнення необхідної якості. Поговоримо про ту частину RUP, яка описує конфігураційне управління.

Основна завдання конфігураційного управління ПЗ - встановлення і підтримання цілісності проектних даних протягом усього життєвого циклу розвитку проекту.

Конфігураційне управління бере участь в ідентифікації конфігурації випускається ПЗ (тобто в виборі програмного продукту і в його описі) в строк. SCM (Source Configuration Management) забезпечує систематизоване управління змінами конфігурації, підтримка їх цілісності та актуальності протягом всього життєвого циклу проекту. Результати розробки, які поставляються клієнта, знаходяться під управлінням конфігураційної системи. Також під її управлінням знаходяться всі документи і результати компіляції (документи вимог, звіти, вихідні дані на будь-якій мові програмування).

Бібліотеки базових ліній повинні бути встановлені і містити працюють версії релізів. Під базовими лініями тут і далі розуміється набір версій вихідних файлів, складових конкретну версію скомпільованій релізу. Зміни базових ліній програмного продукту, побудованих на основі бібліотеки базових ліній, повинні бути керованими за допомогою контролю змін і конфігураційного аудиту функцій у SCM, що повністю забезпечується продуктом Rational ClearCase (версійність управління).

Всі дані з ключових областей процесу (Key Process Area) охоплюють можливі методи виконання функції конфігураційного управління. У СММ всі якісні вимоги представляються саме як KPA. Кожен з цих методів чітко описує певну ділянку з формалізованими вимогами, а RUP здатний привести цю ділянку у відповідність зазначеному вимогу.

Механізми, ідентифікують певні одиниці конфігурації, що містяться в KPA і описують розвиток та супроводження кожної одиниці конфігурації (вихідні тексти, картинки, документація та ін.)

Нижче наведені вимоги CMM до процесу конфігураційного управління. Це вимоги 2 та 3 рівнів. Хочеться відзначити, що впровадження СС відповідно до RUP автоматично дає рівень 3 якості процесу.

Цілі процесу КК: 1. Управління конфігурацією відбувається на плановій основі 2. Всі зміни відбуваються керовано

Зобов'язання з виконання 1. Проект слід документованої організаційної політики 1.1. Є відповідальні за виконання проекту 1.2. КК реалізується протягом усього життєвого циклу (див. РУП) 1.3. КК реалізується для кінцевих продуктів, проміжних, експериментальних і перспективних 1.4. Всі проекти мають власний репозиторій 1.5. На регулярній основі проводиться аудит базових ліній 1.6. На регулярній основі проводиться аудит робіт з управління КК 2. Повинна існувати комісія з управління БЛ 2.1. (завдання 1) Санкціоновані створення БЛ 2.2. (задача 2) Представляти інтереси менеджера проекту і груп 2.3. (задача 3) Ревізія і зміна БЛ 2.4. (задача 4) Створення продуктів з БЛ 3. Необхідна група, що відповідає за координацію та реалізацію КК 3.1. Створення бібліотеки БЛ і управління їй 3.2. Розробка, супровід і поширення планів і стандартів КК 3.3. Ідентифікація набору продукту (під контролем) 3.4. Управління доступом до елементів 3.5. Оновлення БЛ 3.6. Створення продуктів з БЛ 3.7. Запис дій по КК 3.8. Створення звітів 4. Роботи з КК повинні бути забезпечені ресурсами 4.1. Призначення менеджера КК 4.2. Призначення адміністратора КК 4.3. Роботи забезпечені инстр. Засобами і апаратурою 5. Учасники КК повинні пройти навчання цілям, процедур і методів виконання робіт з КК 6. Члени групи розробки ПО повинні пройти навчання з виконання своїх завдань

Операції 1. Для кожного проекту готується план КК 1.1. План розробляється на ранніх стадіях загального планування проекту 1.2. План розглядається задіяними групами і рецензується ними 1.3. План має бути доступний, і керуємо конфігуріруем 2. Документувати і затверджений план КК використовується в якості основи для всіх дій (охоплює наступні питання) 2.1. Роботи, що виконуються за КК 2.2. Графік робіт 2.3. Сфери відповідальності 2.4. Ресурси 2.5. Вимоги та роботи з КК, що виконуються групою розробки ПЗ та суміжними групами 3. Встановлюється бібліотечна система КК, що служить репозиторієм БЛ (завдання) 3.1. Багаторівнева підтримка контролю КК 3.2. Зберігання та вилучення елементів конфігурації 3.3. Спільне використання елементів групами 3.4. Допомога у застосуванні виробничих стандартів КК 3.5. Зберігання та вилучення архівних версій 3.6. Забезпечення коректного створення продуктів 3.7. Зберігання та оновлення записів за КК 3.8. Підтримка створення звітів 3.9. Підтримка структури та вмісту бібліотеки 4. Ідентифікація проміжних програмних продуктів, що знаходяться в системі КК 4.1. Вибір елементів на підставі задокументованих критеріїв 4.2. Елементам репозиторію призначаються унікальні ідентифікатори 4.3. Визначаються характеристики кожного блоку конфігурації 4.4. Визначаються базові лінії 4.5. Для кожного блоку визначена стадія розробки, на якій він міститься в систему КК 4.6. Визначено відповідальний за кожен елемент 5. Запити обслуговуються. Звіти складаються 6. Зміна базових ліній відбувається підконтрольний, відповідно до документованої процедурою 6.1. Виконання перевірок і регресійних тестів 6.2. Внесення до бібліотеки БЛ лише затверджених блоків конфігурації 6.3. Внесення і витяг блоків конфігурації не порушує цілісність проекту 7. Створення продуктів на основі ББЛ і контролювання їх випуску відповідно до документованої процедури 7.1. Комісія контролює створення продуктів на основі ББЛ 7.2. Всі елементи створюються тільки з блоків конфігурації, що містяться в ББЛ 8. Запис статусу елементів конфігурації в відповідно до документованої процедури 8.1. Запис дій по УК проводиться з детальністю, достатньою для того, щоб мати в наявності статус всіх елементів 8.2. Мати можливість відновити колишні версії 8.3. Ведення історії змін 9. Розробка стандартних звітів, документують операції КК 9.1. протоколи нарад 9.2. короткий опис запитів 9.3. короткий опис проблем 9.4. короткий опис базових ліній 9.5. історія змін 9.6. результати аудиту БЛ

Вимірювання і аналіз 1. Виконання вимірювань та використання їх результатів для визначення стану робіт з КК 1.1. кількість запитів за одиницю часу 1.2. виконання етапів робіт по КК в порівнянні з планом 1.3. обсяг виконаних робіт по КК 1.4. ресурси

Перевірка впровадження 1. Регулярна перевірка вищим керівництвом у КК 2. Регулярні і подієві перевірки менеджером проекту робіт по КК 3. Регулярний аудит БЛ (перевірка на відповідності документації)

Висновок

Зверніть увагу на схожість вимог до процесу КК в різних стандартах. Спробуйте застосувати вимоги CMM до того, що є у Вашій компанії! Подивіться. Скільки% вимог у Вас реалізовано.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.cmcons.com/