Дескриптивні моделі - концептуальні, прескриптивні - формальні. Обидві категорії моделей повинні бути точними і недвозначними. Проте формальні моделі повинні містити додаткові критерії коректності для створюваного програмного продукту. Оскільки мета концептуальної моделі - описувати вимоги, то і якість моделі визначає те, наскільки добре програмні продукти відповідають вимогам прикладного домена. Визначення такої відповідності - процес суб'єктивний і називається валідацією. Якщо формальна модель існує, то основні властивості програмного продукту встановлені і можна встановлювати його коректність відносно до формальної моделі. Процес встановлення коректності називається верифікацією. Таким чином, валідація має справу з проблемою (вимоги), а верифікація з продуктом (реалізація вимог). Очевидно, що для однієї проблеми може бути декілька концептуальних моделей, а для кожної концептуальної - декілька формальних моделей, У цьому сенсі немає кращої реалізації проблеми, а формальні моделі відіграють важливу роль у процесі розробки програмного продукту, оскільки без них не можна визначити коректність проектування і реалізації.
Таким чином, усі методи інженерії програмного забезпечення можна розділити на два типи. Перший тип - проблемно-орієнтовані методи, що забезпечують краще розуміння проблеми і пропонованого рішення. Другий тип - продукто-оріентовані методи, що забезпечують коректну трансформацію формальної специфікації в супроводжувану реалізацію. Очевидно, що можуть бути методи, які забезпечують обидва аспекти процесу розробки. У табл. 4.2 наведено методи інженерії програмного забезпечення.
Таблиця 4.2
| Порядковий номер | Назва методу | Автор | Рік походження |
| 1 | Рівні абстракції | Е. Дейкстра | 1968 |
| 2 | Покрокове уточнення | Н. Вірт | 1971 |
| 3 | Функціональна декомпозиція, модуляризація | - | - |
| 4 | Структурне проектування | У. Стивенс, Г. Мейерс, Л. Константіне | 1991 |
| 5 | З'єднання, скріплення, приховування | Д. Парнас | 1972 |
| 6 | Структурне програмування | Е. Дейкстра | 1972 |
| 7 | Абстрактні типи даних | Б, Лісков С. Зайліс | 1975 |
| 8 | Структурний аналіз | Т. Де Марко | 1978 |
| 9 | PSL/QSA | Д. Тихросв Е. Херши | 1977 |
| 10 | ERM | С.Чен | 1976 |
| 11 | JSP/JSD | К. Джексоні | 1977 |
| 12 | Vienna Development methud | ІБМ | 1970 |
| 13 | Simula 67, об'ектно-оріентоване програмування ля | У. Даал, А. Кей | 1976 |
| 14 | Об'сктно-орієнтованне проектування | Г. Буч | 1980 |
| 15 | Домєнний аналіз | Р. Прието-Діаз | 1991 |
| 16 | Об'єктно-орієнтований аналіз | Е. Йодон, П. Коад | 1978 |
Розглянемо ці методи докладніше.
Рівні абстракції (Е. Дейкстра, 1968). Ґрунтуючись на досвіді системи мультипрограмування Т.Н.Е., Дейкстра запропонував розробляти програмне забезпечення за рівнями. Перший низький рівень забезпечує балові сервіси для реалізації наступних, рівнів і ґрунтується на можливостях тієї машини, що реально існує. Кожен наступний рівень використовує сервіси поперед нього. Процес Створення рівнів продовжується до тих пір, доки по буде реалізований найвищий рівень абстракції. Наводиться приклад з управлінням пам'яті. На базовому рівні (машинна мова) відомі канальні команди для обміну даними між різними типами пам'яті. На першому рівні проектується механізм управління перериваннями - вплив на сигнали переривання, але без деталей маскування, відкриття, закривання, блокування, черговості. На наступному рівні проектується канальний супервізор - зберігається можливість управління каналами без зайвих деталей і, нарешті, на ще вищому рівні адміністратор пам'яті організовує обмін. Метод можна віднести як до методів розробки, так і управління.
