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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перехід від «програмування в малому» до «програмування у великому» розширив погляд на розробку програмного забезпечення в двох напрямах: