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

Графічна побудова розпочинається з визначення кореляційного поля. Приклади кореляційних полів показано на рис. 5.9.

Рис. 5.9. Кореляційні поля: а - вписується в коло; б- вписується в еліпс (спадного вигляду); в - вписується в еліпс (вихідного вигляду); г- складної конфігурації

Якщо кореляційне поле мас форму еліпса, робиться висновок про лінійний регресійний зв'язок. Далі проводиться побудова лі­нійної peгрeciї і її оцінювання. Якщо побудовані точки кореляційного поля потрапляють у коло, то робиться висновок про відсут­ність залежності. Якщо ж кореляційне поле не вписується в коло чи еліпс, а має інший вигляд, то робиться висновок про нелінійну за­лежність у лінії регресії. Потім будуються і аналізуються найімовір­ніші наближені лінії регресії. Серед них вибирається найточніша шляхом обчислення відхилення значень залежної Змінної Висно­вок про найточніше припущення робиться для функції, у якої від­хилення найменше. Для нелінійної залежності проводиться лінеа­ризація коефіцієнтів, тобто зведення функції до лінійного вигляду.

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

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

Для реалізації емпіричних методів в інженерії програмного за­безпечення створюються спеціальні середовища - 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 - визначаються цілі альтернативи і обмеження - визна­чення вимог і специфікація для критичних частин системи з погляду продуктивності, функціональних властивостей, здібності до акомодації змін, програмного/апаратного інтерфейсу, критичних чинників успіху;

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

- квадрат 3 — розробляється продукт;

- квадрат 4 - планується така фаза: застосування Інформації, що належить до фази розробки продукту на наступному рівні, до планування на наступному кроці фази проекту.

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

Вертикальна вісь показує накопичувану вартість, а горизон­тальна - прогрес у розробці продукту.