Вступ до інженерії програмного забезпечення - Микола Олександрович Сидоров
Для реалізації емпіричних методів в інженерії програмного забезпечення створюються спеціальні середовища - Computer Aided Empirical Software Engineering (CAESE) (рис. 5.10). Як видно, CAESE забезпечує вивчення проблем, пов'язаних з програмним забезпеченням на основі емпіричних даних, отриманих шляхом проведення експериментів.
Рис. 5.10 Структура САЕSЕ
5.4. Взаємозв'язок інженерійВзаємозв'язок прямої і оберненої інженерії у вигляді програмного забезпечення показано на рис. 5.11. Видно, що оберненій інженерії відводиться інформаційна роль, наприклад, для формування депозитарію для інформації про програмне забезпечення.
Рис. 5.11. Обіг програмного забезпечення
На основі взаємодії обох інженерій будується методологія розробки і супроводу програмного забезпечення. Суть її полягає в тому, що з наявного програмного забезпечення застосуванням методів оберненої інженерії будується репозитарій проектних вирішень домена, відтак на основі репозитарію методами прямої інженерії створюються нові застосування.
Розділ 6. ЖИТТЄВИЙ ЦИКЛ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. МОДЕЛЮВАННЯСтандарт ISO/ІЕС 12207:1995 визначає модель життєвого циклу як схему, що відображає процеси, дії і завдання, які залучаються до розробки, експлуатації і супроводу програмного продукту, починаючи з визначення вимог і закінчуючи зняттям з експлуатації.
Головні цілі моделювання життєвого циклу полягають у тому, щоб, абстрагуючись від деталей, визначити склад і порядок виконання фаз, а також критерії переходу від однієї фази до іншої.
Першими моделями життєвого циклу були такі: «кодуй і виправляй (code-and-fix); «крокова» (stage wise); «водоспад» (waterfall).
6.1. Базові моделіМодель «кодуй і виправляй» містила дві фази (рис. 6.1):
— написання коду;
- встановлення помилок у коді.
Недоліки моделі: після безлічі змін код ставав погано структурований; навіть добре спроектоване програмне забезпечення не відповідало вимогам; супровід коду був дорогим, оскільки код погано пристосований для тестування і модифікації.
Рис. 6.1. Модель «кодуй і виправляй»
Крокова модель була розроблена на основі моделі «кодуй і виправляй» шляхом усунення недоліків, значної деталізації кроків розробки програмного продукту.
Модель, що передбачає послідовне виконання наступних кроків, така (рис. 6.2): планування дій, специфікування дій, кодування, тестування, асемблювання, shakedown, оцінювання розробленої системи. Основні недоліки моделі полягали в тому, що вказані кроки виконувалися у строїти послідовності (був відсутній зворотний зв'язок) і не передбачалося швидке прототипування програм (рис. 6.3). Удосконаленням крокової моделі була каскадна модель, оскільки вона забезпечувала:
Рис. 6.2. Крокова модель
- зворотні зв'язки між стадіями (тим самим зменшувалася переробка програмних продуктів окремих стадій);
- прототипування як спосіб розробки програмного забезпечення двічі;
- введені фази проектування;
- кожна фаза продукту проходить верифікацію, валідацію або тестування.
Проте головний недолік каскадної моделі - це обов'язкове завершення фаз специфікації вимог і проектування перш, ніж може бути продовжено виконання інших фаз життєвого циклу. Якщо для окремих класів програмних систем, наприклад, операційних систем цей підхід був ефективний, то для широкого класу інтерактивних застосувань він не працював. Це зумовило необхідність розробляти інші моделі життєвого циклу (рис. 6.3).
Рис. 6.3. Каскадна модель
Каскадна модель не знайшла практичного застосування, проте виявилася важливою теоретичною базою для розробки моделей інших типів, а також стандартів, Наприклад, такі особливості технологій, як інкрементна і паралельна розробка, сімейство програм, еволюційні зміни, формальна розробка і верифікація, ризик-аналіз були вперше введені як розвиток каскадної моделі.
6.2. Типи моделей життєвого циклуНатепер моделі життєвого циклу можна поділити на три групи. Основою моделей усіх груп є каскадна модель.
Першу групу утворюють «послідовні» моделі - модифікації каскадної моделі орієнтування на розробку «з нуля». До цієї групи входять:
класична, водоспад, спіральна, інкрементна, покрокова, модель швидкої розробки, модель прототипування, еволюційна модель.
Розробка нових методів побудови програмного забезпечення, заснованих на багатократному і повторювальному використанні, призвела до появи другої групи моделей, До її складу входять моделі компонентної розробки і моделі, засновані на повторному використанні.
Одним із шляхів підвищення ефективності розробки ПЗ є усунення фаз життєвого циклу шляхом автоматизації відповідних процесів, У зв'язку з цим з'явилася третя група моделей автоматичного синтезу програмного забезпечення.
6.2.1. Моделі, орієнтовані на розробку «з нуля»Класична модель водоспаду - це узагальнення моделі водоспаду Райса, Модель містить п'ять фаз і, зазвичай, використовується в теоретичних побудовах (рис. 6.4).
Рис. 6.4. Класична модель водоспаду
Спіральна модель запропонована Боемом, як уточнення моделі водоспаду в результаті виконання ряду проектів, Процес розробки представлений у вигляді спіралі. Кожен виток спіралі - фаза (рис. 6.5).
Рис. 6.5. Спіральна модель
Спіраль розташована в чотирьох квадратах. У кожному квадраті виконуються певні дії:
- квадрат 1 - визначаються цілі альтернативи і обмеження - визначення вимог і специфікація для критичних частин системи з погляду продуктивності, функціональних властивостей, здібності до акомодації змін, програмного/апаратного інтерфейсу, критичних чинників успіху;
- квадрат 2 - розробляється прототип, ідентифікуються і вирішуються ризики - визначення вимог і специфікацій для найбільш потенційно небезпечних частин уявної системи задля виконання оцінювання і визначення ступеня ризику; розділення на окремі частини відповідно до ступенів ризику;
- квадрат 3 — розробляється продукт;
- квадрат 4 - планується така фаза: застосування Інформації, що належить до фази розробки продукту на наступному рівні, до планування на наступному кроці фази проекту.
Таким чином, у відповідному квадраті відбуваються такі дії: