2.1. КЕРУВАННЯ ПРОЦЕСАМИ ЯК ОБЄКТ АВТОМАТИЗАЦІЇ

Керування процесами життєвого циклу ІС включає керування шаблонами процесів (створення моделей процесів) та керування їх практичною реалізацією (оперативне керування). Згідно з IEEE «Guide to the Software Engineering Body of Knowledge» (SWEBOK) мета керування процесами полягає в реалізації нових і кращих процесів у реальній практиці конкретних фахівців, проектів чи організації (як окремих груп підрозділів, так і організації загалом).

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

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

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

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

Спіральна модель, розроблена Баррі Боемом, ґрунтована на класичному циклі Демінга PDCA (plandocheckact, плануйробиперевіряйдій), — ІС створюється за кілька ітерацій (витків спіралі) методом прототипування. Кожна ітерація відповідає створенню фрагмента або версії ІС, на яких уточнюються цілі й характеристики проекту, оцінюється якість отриманих результатів плануються роботи наступної ітерації в разі прийняття рішення стосовно продовження проекту. Прикладом реалізації спіральної моделі є RAD (Rapid Application Development, метод швидкої розробки додатків).

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

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

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

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

— IEEE/ISO 12207 «Information Technology

— Software Lifecycle Processes»

— Інформаційна технологія

— процеси життєвого циклу програмного забезпечення;

— IEEE 1219 «Standard for Software Maintenance»

— Стандарт супроводу програмного забезпечення;

— ISO 14764 «Standard for Software EngineeringSoftware Maintenance»

— Стандарт програмної інженерії

— супровід програмного забезпечення;

— IEEE 1540 «Standard for Software Risk Management»

— Стандарт керування ризиками програмного забезпечення;

— IEEE 1517 «Standard for Software Reuse Processes»

— Стандарт процесів повторного використання програмного забезпечення ;

— ISO/IEC 15939 «Standard for Software Measurement Process»

— Стандарт процесів вимірювання програмного забезпечення.

Часто процеси життєвого циклу визначаються в контексті організаційних процесів керування якістю. Стандарт ISO 9001 формулює вимоги до процесів керування якістю, а ISO 9003 інтерпретує їх стосовно організацій, що розробляють ІС (ISO/IEC 90003:2004, Software and Systems Engineering — Guidelines for the Application of ISO9001:2000 to Computer Software).

Існують також численні технології й методи, що містять конкретні рекомендації стосовно процесів життєвого циклу. Зокрема, слід відзначити сучасні варіанти ітераційної моделі — RUP, MSF, XP, а також методології визначення процесів SixSigma, CMMI, ITIL та CoBIT.

Rational Unified Process (RUP) — методологія розробки ІС, створена компанією Rational Software (див. докладніше п. 2.2).

Microsoft Solutions Framеwork (MSF) — це комплекс засобів і методів процесу розробки проекту, що містить скоординований набір елементів (програмнотехнічних засобів, документації, методик навчання і супроводу) для побудови виробничої архітектури (див. докладніше п. 2.3).

Екстремальне програмування (Extreme Programming, XP) є одним із найвідоміших прикладів практичної реалізації підходу швидкої розробки. На відміну від класичних методологій («монолітних», «важких», «монументальних»), «полегшені», «швидкі» («agile») підходи позбавлені збиткового формалізму, ставлять за мету чутливе реагування на потреби замовника, якого залучають до розробки, і розглядають зміни як невід’ємну складову процесу. Відмінною особливістю цих методів є гнучкість щодо планування, коли план проекту коригується мірою наближення проекту до мети. Метод екстремального програмування призначений для невеликих компактних команд, спрямованих на досягнення якомога вищого рівня якості й продуктивності завдяки інтенсивним неформальним комунікаціям, особистим умінням і навичкам учасників проекту, їхній дисципліні та розумінню, а також мінімуму всіх проміжних робочих продуктів. Для великих компаній з промислової розробки ІС, що готові на тривалі інвестиції в кардинальну перебудову організаційної структури, більше підходять важкі методології, що дають найбільший ефект.

Безпосередньо розробку процесів життєвого циклу регламентує стандарт IEEE 1074 «Standard for Developing Software Life Cycle Processes» («Стандарт розробки процесів життєвого циклу програмного забезпечення»). Він містить список процесів і дій з розробки та супроводу систем , а також список дій з підтримки самого життєвого циклу, який можна відобразити на процеси й організувати аналогічно будьякій моделі життєвого циклу. Крім того, цей стандарт ідентифікує і пов’язує інші стандарти IEEE із діями з підтримки процесів життєвого циклу.

За допомогою методики SixSigma (Шість сигма ), розробленої компанією «Motorola«, спеціальна група фахівців здійснює визначення, усунення дефектів і невідповідностей у бізнеспроцесах і на виробництві із застосуванням набору методів керування якістю, включно зі статистичними методами. Суть поняття «процес шість сігма» полягає в тому, що процес вважається бездефектним, якщо проміжок між математичним очікуванням процесу та межею його поля допуску дорівнюватиме шести середньоквадратичним відхиленням.

CMMI (Capability Maturity Model Integration, комплексна/інтегрована модель продуктивності і зрілості) — набір моделей (методологій) удосконалення процесів в організаціях різних розмірів і видів діяльності. CMMI визначає 22 процесні ділянки (process areas), для кожної з яких визначено цілі (goals), що їх слід досягти за впровадження CMMI. Цілі досягаються шляхом виконання практик. Як цілі, так і практики поділяють на загальні (generic), що стосуються кількох процесних ділянок, та спеціальні (унікальні, specific). При впровадженні CMMI на безперервних (continuous) засадах порядок удосконалення процесних ділянок не фіксується. Якість процесів у кожній процесній ділянці можна оцінити на один з шести (0—5) рівнів продуктивності (capability level). За східчастою (staged) подання визначається п’ять (1—5) рівнів зрілості (maturity level) організації. Для досягнення кожного наступного рівня зрілості слід виконати вимоги щодо провадження певних процесних ділянок і досягнення відповідних цілей.

Набір моделей CMMI містить три моделі: CMMI for Development (CMMIDEV, для розробки), CMMI for Services (CMMISVC, для послуг) і CMMI for Acquisition (CMMIACQ, для придбання).

ITIL (IT Infrastructure Library, бібліотека інфраструктури інформаційних технологій) — бібліотека найкращих способів організації роботи підрозділів або компаній у сфері інформаційних технологій, розроблена на замовлення британського уряду. Бібліотека містить описи всього набору процесів, необхідних для забезпечення високої якості ІТсервісів і задоволення вимог замовника. Використаний у бібліотеці процесний підхід цілком відповідає стандартам серії ISO 9000, зосереджуючи увагу на досягненні поставлених цілей і витрачених при цьому ресурсах. Нині на підставі ITIL розроблено британський стандарт BSI 15 000, який практично без змін перейшов до категорії міжнародних під назвою ISO 20 000.

CoBIT (Control OBjectives for Information Technology, цілі керування в інформаційних технологіях) — це набір стандартів і рекомендацій для аудиту й управління інформаційними технологіями. Методологію розроблено Міжнародною асоціацією аудиту і контролю за інформаційними системами (ISACA). Основний принцип CobIT — інвестування та керування ІТресурсами (додатками, інформацією, інфраструктурою, людьми) через структурований комплекс процесів, які забезпечують сервіси для надання інформації. Стандарт поділяє всю діяльність з ІТ на 4 домени (групи, або сфери діяльності ), що містять 34 процеси, кожен із яких прив’язаний до ІТцілі, а кожна ІТціль — до бізнесцілі. Для кожного процесу визначено ключові індикатори досягнення цілі (KGI, метрики, що відображають рівень досягнення цілей бізнесу за допомогою ІТпроцесу), ключові показники ефективності (KPI, метрики, що відображають якість роботи ІТпроцесу), рівень зрілості процесу за шкалою від 0 до 5 (5 — відповідність процесу рівню передової практики).