- здійснення стандартного процесу розробки програмного забезпечення (потребує від організації і проекту визначення процесів, які задовольняють їх власні унікальні потреби);
- процес, використовуваний для реалізації даного проекту (повинен враховувати досвід членів команди, поточний статус продукту, а також доступні інструменти і можливості).
Згідно з стандартом ІЕЕЕ610 процес життєвого циклу програмного забезпечення визначається як послідовність етапів, спрямованих на досягнення конкретної мети, якою може бути створення програмного продукту або програми. Детальніше, процес - це обмежений ряд взаємозв'язаних дій, у процесі здійснення яких використовуються один або більше типів початкових продуктів, які за допомогою однієї або декількох змін перетворюються на вихідний продукт, що становить цінність для замовника.
Процес розглядають в трьох різних аспектах, визначаючи три типи процесів:
- метапроцес - дії, які виконує організація під час проведення підприємницької діяльності, пов'язаної з розробкою програмного забезпечення. Основна увага при виконанні цього типу процесу приділяється економіці організації, довготривалій стратегії і поверненню інвестицій у програмне забезпечення;
- мікропроцес - дії, які виконуються в організації в разі реалізації певного проекту програмного забезпечення. Основна увага приділяється вартості, термінам і якості;
- мікропроцес - дії, які виконуються командою розробників у певній фазі проекту, спрямовані на отримання конкретних результатів. Основна увага приділяється створенню проміжного продукту такої якості, яка адекватна функціональним можливостям і настільки економічно і швидко, наскільки це здійснено на практиці.
Ці три типи процесу перекриваються, коли виконуються паралельно, але у них різні цілі, учасники, метрики, виробничі відносини і часовий масштаб (табл. 4.1),
Таблиця 4.1
Атрибути процесу Метапроцесс Макропроцес Мікропроцес Цілі Стратегія бізнесу Прибутковість стратегії бізнесу Конкурентоспроможність Виконання проекту. Прибутковість проекту. Зменшення ризиків. Виконання бюджету проекту, термінів, якості Виконання процесу. Управління ресурсами. Виконання проміжного бюджету, термінів, якості Учасники Менеджери організації. Замовники Менеджери проекту. Розробники ПЗ Менеджери процесів проекту. Розробники програмного забезпеченим Метрики Передбачуваність проекту Отримання доходу на контрольованому сегменті ринку Виконання бюджету, термінів. Досягнення основних контрольних точок Виконання бюджету і термінів процесу. Досягнення основних контрольних точок процесу Часовий масштаб Постійно Від одного року до декількох років Від одного до декількох місяців
Стандарт IEEE 1074 описує процеси і дії. Цим стандартом передбачено 17 підпроцесів і 65 дій, що входять до складу підпроцесів.
Розрізняють процеси «важкі» і «полегшені». Для процесів першого типу характерне таке:
- реалізація фіксованих вимог великою групою розробників;
- повний прогноз робіт, які слід виконати;
- строго усталений порядок виконання. Для процесів другого типу характерне таке:
- реалізація невеликою кількістю розробників за умови частих змін вимог, непередбачуваність;
- адаптивність під час виконання;
- участь замовника;
- відсутність повного порядку і документування.
Як приклад реалізації стандартного процесу можна навести уніфікований процес (Rational United process), а як приклад визначуваних процесів - робочі процеси.
В уніфікованому процесі термін «процес» належить до концепції, що працює подібно до шаблону, який може бути багато разів використаний для створення екземплярів - процесів конкретного проекту.
Процес розробки програмного забезпечення - це назва для повного набору дій, необхідних для перетворення вимог користувачів в узгоджений набір артефактів, що є програшнім продуктом, а пізніше - для перетворення змін в цих вимогах у новий узгоджений набір артефактів.
Значущий результат процесу - це узгоджений набір артефактів, що представляє одну програмну систему або сім'ю тих систем, що С програмними продуктами. Таким чином, процес покриває не тільки перший цикл розробки (перший випуск), але і більшість подальших випусків. У подальших випусках до екземпляра процесу вносяться послідовні зміни у вимоги. На виході, відповідно, виходять змінені набори артефактів.
В уніфікованому процесі розрізняють чотири стадії, які групуються відповідно по дві;
- стадія розробки, дії спрямовані на виконання робіт з проектування і синтезу (включає початкову стадію і стадію уточнення — детального проектування);
- стадія виготовлення, дії зорієнтовані на створення, тестування і введення в дію програм або програмних продуктів (включає стадію реалізації і стадію введення в дію).
Процес розробки описується в поняттях робочих процесів. Робочим процесом є набір видів діяльності. Термін «робочий процес» використовується для позначення потоку зв'язаних і послідовних дій. Передбачається сім робочих процесів:
- управління проектом - контроль ходу робіт і гарантія умов Досягнення успіху для всіх зацікавлених сторін;
- створення робочого середовища - автоматизація процесу і розвиток середовища супроводу та експлуатації;
- управління вимогами - аналіз проблемної області і вдосконалення робочих продуктів вимог;
- проектування - моделювання рішення і отримання робочих продуктів проектування (архітектура);
- реалізація - програмування компонентів і вдосконалення робочих продуктів;
- оцінка - оцінювання тенденцій і якості продукту;
- впровадження - передача кінцевих продуктів користувачеві.
У термінах UML процес - це стереотип кооперації, в якій беруть участь співробітники і артефакти. Не існує такого процесу розробки програмного забезпечення, який міг би застосовуватися у всіх випадках. Основні чинники, що призводять до відмінностей у процесах, такі:
- організаційні - структура і культура організації, організація управління проектом, наявні здібності і знання, попередній досвід і створені програмні системи;
- наочні області - наочна область програмного забезпечення, бізнес-процес підтримки, співтовариство користувачів і пропозиції конкурентів;
- життєвого циклу - час виходу на ринок (проведення під час розроблення програми експертизи технології та персоналу і планування майбутніх випусків);
- технічні - мови програмування, засоби розробки, бази даних, покладена в основу розробки архітектура.
Процеси змінюються, оскільки вони викопуються в різних контекстах, призначені для розробки різних типів систем і мають різні типи бізнес-обмежень (плани, ціна, якість і надійність). Тому реальний процес розробки програмного забезпечення повинен мати можливість адаптуватися і конфігуруватися під поточні потреби конкретного проекту і/або організації. Розробляючи уніфікований процес, у нього була включена можливість спеціалізації. Будь-яка організація, що використовує уніфікований процес, з часом спеціалізує його, пристосувавши до своїх умов.
4.2.2. Контроль виконання процесуДля контролю виконання процесу використовуються контрольні точки. Контрольна точка - це місце, визначене часом у процесі, коли він зупиняється і здійснюється оцінювання параметрів складових фази життєвого циклу.
Розрізняють три типи контрольних точок:
- основні - встановлюються в кінці кожної стадії розробки на рівні всієї системи. Дають змогу виявити великі проблеми, узгодити точки зору управління та розробки і підтвердити, що цілі даної стадії досягнуті;
- другорядні - встановлюються в кінці ітерації (у рамках стадії) для детальної перевірки результатів ітерації і для санкціонування подальшої роботи;
- оцінки стану - встановлюються довільно і дають змогу контролювати хід процесів.
Для основних контрольних точок в кінці кожної стадії використовуються формальні, схвалені зацікавленими сторонами критерії оцінки і опису версій. Для другорядних контрольних точок застосовуються неформальні критерії, встановлювані командою розробників.
Критерії точок оцінки стану виробляються залежно від ситуації, що склалася.
Рівень і кількість контрольних точок змінюються залежно від таких параметрів, як: масштаб проекту, кількість зацікавлених сторін, стан бізнесу, технічний ризик і чутливість проекту до змін витрат і термінів. Для більшості процесів потрібно встановити всі основні контрольні точки (відповідно до кількості стадій). Лише у виняткових випадках слід додавати основні контрольні точки або оперувати меншою їх кількістю. У простіших проектах для контролю проміжних результатів може знадобитися менша кількість другорядних контрольних точок або їх не потрібно буде зовсім, а періодичність оцінок стану може бути невеликою (наприклад, щоквартальною).
