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

Управление конфігурацією в стандартах CMM і ISO 12 207

Процесс КК у стандарті ГОСТ Р ИСО/МЭК 12 207

Почему під час виборів стандарту, визначального процес управління конфігурацією, для докладного розгляду ми зупинилися на стандарті ГОСТ Р ИСО/МЭК 12 207 «Інформаційні технології. Процеси життєвого циклу програмних засобів»? Для цього кілька важливих причин:

Стандарт ГОСТ Р ИСО/МЭК 12 207 російський стандартом, офіційно запровадженим в дію біля Російської Федерації.

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

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

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

Российский стандарт ГОСТ Р ИСО/МЭК 12 207 розглядає процеси життєвого циклу (ЖЦ) програмних засобів (ПС) і поділяє їх у три группы:

Основные.

Вспомогательные.

Организационные.

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

.

Рис. 1. Процеси життєвого циклу ПС по ГОСТ Р ИСО/МЭК 12 207.

Стандарт ГОСТ Р ИСО/МЭК 12 207 встановлює загальну структуру процесів життєвого циклу (ЖЦ) програмних засобів (ПС), визначає процеси, праці та завдання, що їх під час ЖЦ ПС. Цей процес складається з таких работ:

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

определение конфігурації;

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

учет станів конфігурації;

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

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

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

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

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

организацию (и), ответственную (ые) у виконанні даних робіт;

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

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

Определение конфігурації

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

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

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

Учет станів конфігурації

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

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

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

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

Должны офіційно контролюватися випуск і постачання програмних продуктів разом із відповідної документацією. Оригінали програм, тож документації повинні супроводжуватися в життєвому циклі. Програми і документація, пов’язані з забезпеченням критичних функцій безпеки чи захисту, повинні оброблятися, зберігатися, упаковуватися постачатимуть відповідно до встановленими правилами Управление конфігурацією з погляду 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 і п’яти по більшу частину управлінські та їх досягнення важливо як випустити програмний продукт, а й проаналізувати хід проекту, і навіть побудувати плани майбутній проект, виходячи з поточних шаблонах. Застосування даних підходів має забезпечити планомерно-плавное поліпшення використовуваних процесів.

Пока у Росії знають лише абревіатуру СММ, але з уявляють собі, як можна домогтися якісного стрибка. І це у тому, що є напрям цього стрибка, суть у тому, що після кожної окремо взятому компанії досить важко вибудувати свої процеси під вимоги 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 і трьох рівнів. Хочеться наголосити, що почнеться впровадження СС відповідно до 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 до того що, що є у Вашої компанії! Подивіться. Скільки % вимог у Вас реализовано.

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

Для підготовки даної праці були використані матеріали із сайту internet.