М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Графічна побудова розпочинається з визначення кореляційного поля. Приклади кореляційних полів показано на рис. 5.9.
Рис. 5.9. Кореляційні поля: а - вписується в коло; б- вписується в еліпс (спадного вигляду); в - вписується в еліпс (вихідного вигляду); г- складної конфігурації
Якщо кореляційне поле мас форму еліпса, робиться висновок про лінійний регресійний зв'язок. Далі проводиться побудова лінійної peгрeciї і її оцінювання. Якщо побудовані точки кореляційного поля потрапляють у коло, то робиться висновок про відсутність залежності. Якщо ж кореляційне поле не вписується в коло чи еліпс, а має інший вигляд, то робиться висновок про нелінійну залежність у лінії регресії. Потім будуються і аналізуються найімовірніші наближені лінії регресії. Серед них вибирається найточніша шляхом обчислення відхилення значень залежної Змінної Висновок про найточніше припущення робиться для функції, у якої відхилення найменше. Для нелінійної залежності проводиться лінеаризація коефіцієнтів, тобто зведення функції до лінійного вигляду.
Завершальним етапом є довірче оцінювання ліній регресій [8]. Довірче оцінювання регресії відбувається в декілька етапів. Першим етаном є визначення коефіцієнта детермінації, який показує ступінь залежності між величинами. Далі проводиться оцінювання відхилення окремих значень залежної величини від емпіричної регресії шляхом порівняння практичних та теоретичних значень залежної змінної. Останнім кроком є побудова довірчого інтервалу лінії регресії.
Якщо пара пройшла всі етапи і не була відсіяною, робиться висновок, що одна метрика залежить певним чином від іншої з силою, що показує коефіцієнт детермінації, а вигляд залежності визначає лінія регресії.
5.3.2. Засоби емпіричної інженерії програмного забезпеченийДля реалізації емпіричних методів в інженерії програмного забезпечення створюються спеціальні середовища - 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 - планується така фаза: застосування Інформації, що належить до фази розробки продукту на наступному рівні, до планування на наступному кроці фази проекту.
Таким чином, у відповідному квадраті відбуваються такі дії: планування, прототипування, конструювання, оцінювання замовником і планування наступних дій.
Вертикальна вісь показує накопичувану вартість, а горизонтальна - прогрес у розробці продукту.