М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

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

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

Процес розглядають в трьох різних аспектах, визначаючи три типи процесів:

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

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

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

Ці три типи процесу перекриваються, коли виконуються паралельно, але у них різні цілі, учасники, метрики, виробничі відносини і часовий масштаб (табл. 4.1),

Таблиця 4.1

Стандарт IEEE 1074 описує процеси і дії. Цим стандартом передбачено 17 підпроцесів і 65 дій, що входять до складу підпроцесів.

Розрізняють процеси «важкі» і «полегшені». Для процесів першого типу характерне таке:

- реалізація фіксованих вимог великою групою розробників;

- повний прогноз робіт, які слід виконати;

- строго усталений порядок виконання. Для процесів другого типу характерне таке:

- реалізація невеликою кількістю розробників за умови частих змін вимог, непередбачуваність;

- адаптивність під час виконання;

- участь замовника;

- відсутність повного порядку і документування.

Як приклад реалізації стандартного процесу можна навести уніфікований процес (Rational United process), а як приклад визначуваних процесів - робочі процеси.

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

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

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

В уніфікованому процесі розрізняють чотири стадії, які групуються відповідно по дві;

- стадія розробки, дії спрямовані на виконання робіт з проектування і синтезу (включає початкову стадію і стадію уточнення — детального проектування);

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

Процес розробки описується в поняттях робочих процесів. Робочим процесом є набір видів діяльності. Термін «робочий процес» використовується для позначення потоку зв'язаних і послідовних дій. Передбачається сім робочих процесів:

- управління проектом - контроль ходу робіт і гарантія умов Досягнення успіху для всіх зацікавлених сторін;

- створення робочого середовища - автоматизація процесу і розвиток середовища супроводу та експлуатації;

- управління вимогами - аналіз проблемної області і вдосконалення робочих продуктів вимог;

- проектування - моделювання рішення і отримання робочих продуктів проектування (архітектура);

- реалізація - програмування компонентів і вдосконалення робочих продуктів;

- оцінка - оцінювання тенденцій і якості продукту;

- впровадження - передача кінцевих продуктів користувачеві.

У термінах UML процес - це стереотип кооперації, в якій беруть участь співробітники і артефакти. Не існує такого процесу розробки програмного забезпечення, який міг би застосовуватися у всіх випадках. Основні чинники, що призводять до відмінностей у процесах, такі:

- організаційні - структура і культура організації, організація управління проектом, наявні здібності і знання, попередній досвід і створені програмні системи;

- наочні області - наочна область програмного забезпечення, бізнес-процес підтримки, співтовариство користувачів і пропозиції конкурентів;

- життєвого циклу - час виходу на ринок (проведення під час розроблення програми експертизи технології та персоналу і планування майбутніх випусків);

- технічні - мови програмування, засоби розробки, бази даних, покладена в основу розробки архітектура.

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

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

Розрізняють три типи контрольних точок:

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

- другорядні - встановлюються в кінці ітерації (у рамках стадії) для детальної перевірки результатів ітерації і для санкціонування подальшої роботи;

- оцінки стану - встановлюються довільно і дають змогу контролювати хід процесів.

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

Критерії точок оцінки стану виробляються залежно від ситуації, що склалася.

Рівень і кількість контрольних точок змінюються залежно від таких параметрів, як: масштаб проекту, кількість зацікавлених сторін, стан бізнесу, технічний ризик і чутливість проекту до змін витрат і термінів. Для більшості процесів потрібно встановити всі основні контрольні точки (відповідно до кількості стадій). Лише у виняткових випадках слід додавати основні контрольні точки або оперувати меншою їх кількістю. У простіших проектах для контролю проміжних результатів може знадобитися менша кількість другорядних контрольних точок або їх не потрібно буде зовсім, а періодичність оцінок стану може бути невеликою (наприклад, щоквартальною).