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