< Попередня  Змiст  Наступна >

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


Стандарт ISO 12207 «Процеси життєвого циклу програмних засобів» визначає процес як набір взаємопов’язаних робіт, які перетворюють початкові дані на вихідні результати. Значення процесів полягає в можливості визначення, запису і розуміння того, що слід зробити і яким чином це має бути зроблено. Для забезпечення якості кінцевих результатів процеси повинні мати відповідні характеристики (табл. 2.1).

 

Таблиця 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 — відповідність процесу рівню передової практики).

 

Визначення процесів відбувається із використанням певних нотацій, головна відмінність між якими полягає у типах інформації, що визначається, контролюється і використовується. Зокрема, можна назвати діаграми потоків даних (data flow diagrams), діаграми переходів і станів (statechart), діаграми дій (activity diagrams) UML (Unified Modeling Language, Уніфікована мова моделювання), діаграми IDEF0. Слід також відзначити перспективність відносно нотації BPMN (Business Process Management Notation, нотація керування бізнеспроцесами), що передбачає побудову діаграм бізнеспроцесів (Business Process Diagram, BPD). Застосування названих нотацій стає першим кроком у вирішенні проблем керування процесами (табл. 2.2).

 

Таблиця 2.2

ПРОБЛЕМИ КЕРУВАННЯ ПРОЦЕСАМИ

Проблема

Опис

 

У проекті задіяно 1—2 особи,

які володіють процесом (кож

на — своєю частиною)

 

Критична для проекту інформація не має

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

слід описати й опублікувати, подати в прос

тому і зрозумілому вигляді

 

 

 

 

 

У разі прийняття нових спів

робітників для введення їх у

курс справ потрібно багато

часу і ресурси досвідчених

фахівців

Ресурс обізнаного фахівця («людина, яка

все знає») стає дедалі критичнішим. Його

час слід максимально використовувати на

основних завданнях проекту — реалізації

продукту, а не для забезпечення проекту

 

 

 

 

 

За великої швидкості оновлен

ня кадрів істотно знижується

ефективність праці експертів

Кваліфіковані фахівці передають свій досвід

новачкам, а не працюють над продуктом

 

 

 

 

Методи вирішення проблем  

Визначити (задокументувати) процеси 

Описати ясною, зрозумілою мовою процеси розробки й експлуатації

Розробити методики та інструкції з роботи в проекті з автоматизованими засобами підтримки проектів

 

 

У цьому контексті можна виокремити проблеми, вирішення яких має на меті автоматизація:

 

— учасники проекту повинні мати серйозну підготовку з методів, що відповідають виконуваним окремими особами ролям. Розробники навчаються аналізу і проектуванню, тестувальники — перевірці результатів реалізації початковим вимогам, менеджери — керуванню проектом тощо. Можна вважати, що кожен учасник знає свої обов’язки та як їх виконувати без документування методів, але багато організацій воліють запровадити загальну регульовану практику з метою вдосконалення методів та увідповіднення вимогам стандартів. Нових учасників розробки слід ознайомити із застосовуваними практиками;

— команда проекту має визначити шляхи застосування цих методів упродовж життєвого циклу ІС, що, своєю чергою, передбачає визначення процесів розробки. Наприклад, методи керування вимогами порізному застосовують на різних стадіях життєвого циклу — на ранніх стадіях проекту вони зосереджуються на визначенні вимог зацікавлених осіб, а на пізніх — на керуванні змінами вимог та аналізі впливу цих змін. Також потрібне чітке розуміння зв’язку між виконуваними завданнями, наприклад, як керування змінами впливає на керування вимогами або на регресійне тестування. Навіть організація, що покладається на самоорганізацію, має виробити процес з мінімумом настанов щодо розробки, досягнення та перевірки віх тощо;

— група розробників потребує простого централізованого доступу до інформації — бази практик і процесів. Зазвичай процеси не документовані повністю або подані в різних місцях і форматах. Складною є інтеграція в процес розробки інших практик і процесів у пропрієтарних форматах (книги, статті).

 

Автоматизовані засоби підтримують власне визначення процесів, зокрема опис процесів із використанням тих чи інших діаграм і нотацій, та/або містять відповідні настанови з визначення процесів (RUP, MSF). У разі проведення аналізу процесів деякі інструментальні засоби забезпечують різні форми симуляції.

 

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

 

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

Налаштовані методології та технології разом із CASEзасобами, які вони їх підтримують, стають центральною частиною середовища автоматизованої розробки ІС.


< Попередня  Змiст  Наступна >
Iншi роздiли:
2.2.2. IBM Rational Method Composer
2.3. АВТОМАТИЗОВАНА ПІДТРИМКА МЕТОДОЛОГІЇ MICROSOFT SOLUTIONS FRAMEWORK
2.4. АВТОМАТИЗОВАНА ПІДТРИМКА МЕТОДОЛОГІЇ DATARUN
Терміни та поняття
Тема 3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ВИМОГАМИ
Дисциплiни

МаркетингАнглійська моваПравоЕтика та естетикаІсторіяБухгалтерський облікЕкономікаІнформатикаМенеджментПолітологіяСтатистикаФінанси

Бібліотека підручників та статтей Posibniki