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

Для реалізації емпіричних методів в інженерії програмного за­безпечення створюються спеціальні середовища - Computer Aided Empirical Software Engineering (CAESE) (рис. 5.10). Як видно, CAESE забезпечує вивчення проблем, пов'язаних з програмним за­безпеченням на основі емпіричних даних, отриманих шляхом про­ведення експериментів.

Рис. 5.10 Структура САЕSЕ

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

Рис. 5.11. Обіг програмного забезпечення

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

Стандарт ISO / ІЕС 12207:1995 визначає модель життєвого циклу як схему, що відображає процеси, дії і завдання, які залучаються до розробки, експлуатації і супроводу програмного продукту, почи­наючи з визначення вимог і закінчуючи зняттям з експлуатації.

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

Першими моделями життєвого циклу були такі: «кодуй і вип­равляй (code-and-fix ); «крокова» (stage wise ); «водоспад» (waterfall).

Модель «кодуй і виправляй» містила дві фази (рис. 6.1):

— написання коду;

- встановлення помилок у коді.

Недоліки моделі: після безлічі змін код ставав погано структурований; навіть добре спроектоване програмне забезпечення не відповідало вимогам; супровід коду був дорогим, оскільки код по­гано пристосований для тестування і модифікації.

Рис. 6.1. Модель «кодуй і виправляй»

Крокова модель була розроблена на основі моделі «кодуй і вип­равляй» шляхом усунення недоліків, значної деталізації кроків роз­робки програмного продукту.

Модель, що передбачає послідовне виконання наступних кроків, така (рис. 6.2): планування дій, специфікування дій, кодування, тес­тування, асемблювання, shakedown, оцінювання розробленої сис­теми. Основні недоліки моделі полягали в тому, що вказані кроки ви­конувалися у строїти послідовності (був відсутній зворотний зв'язок) і не передбачалося швидке прототипування програм (рис. 6.3). Удоско­наленням крокової моделі була каскадна модель, оскільки вона забез­печувала:

Рис. 6.2. Крокова модель

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

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

- введені фази проектування;

- кожна фаза продукту проходить верифікацію, валідацію або тестування.

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

Рис. 6 . 3 . Каскадна модель

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

Натепер моделі життєвого циклу можна поділити на три групи. Основою моделей усіх груп є каскадна модель.

Першу групу утворюють «послідовні» моделі - модифікації каскад­ної моделі орієнтування на розробку «з нуля». До цієї групи входять:

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

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

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

Класична модель водоспаду - це узагальнення моделі водоспаду Райса, Модель містить п'ять фаз і, зазвичай, використовується в теоретичних побудовах (рис. 6.4).

Рис. 6.4. Класична модель водоспаду

Спіральна модель запропонована Боемом, як уточнення моделі водоспаду в результаті виконання ряду проектів, Процес розробки пред­ставлений у вигляді спіралі. Кожен виток спіралі - фаза (рис. 6.5).

Рис. 6.5. Спіральна модель

Спіраль розташована в чотирьох квадратах. У кожному квадраті виконуються певні дії:

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