ль на основі створення прототипів не підходить так як має велику витрату часу і ресурсів для створення великої кількості прототипів які необхідні замовнику.
Інкрементна модель
Інкрементна модель ПО на відміну, наприклад, від мікросхеми можна вводити в експлуатацію по частинах, а значить, розробляти і поставляти його замовнику також можна поступово. Саме на цьому заснована інкрементна модель, що передбачає дроблення продукту на відносно незалежні складові, які розробляються і вводяться в експлуатацію окремо. p align="justify"> Така модель вигідна як для замовника, так і для творця системи, оскільки дозволяє просуватися вперед, дотримуючись інтересів обох сторін. Проте у неї є свої недоліки. Ділення на функціональні блоки в цілому уповільнює процес, так як виникає необхідність забезпечення їх взаємодії. Для багатьох рішень цей метод непридатний, оскільки з них не можна вичленувати окремі складові, які можуть бути поставлені і функціонувати незалежно. Істотно зростає навантаження і на керівний персонал у зв'язку з ускладненням завдань з координування робіт над окремими складовими системи, збільшується вартість внесення змін в готові компоненти, які вже встановлені і працюють у замовника. p align="justify"> Об'єктно-орієнтована модель
Об'єктно-орієнтована модель. Дана методологія передбачає конструювання програмного рішення з готових об'єктів, для яких визначаються правила їх взаємодії, що переводять об'єкти з одного стану в інший. Така модель, що передбачає повну відповідність процесу розробки положень об'єктно-орієнтованої методології (об'єктно-орієнтований аналіз, проектування, програмування), ефективна у великих проектах, а також там, де застосовуються так звані засоби швидкої розробки (RAD, Rapid Application Development), засновані на цих технологіях і містять готові бібліотеки класів.
Однак самі по собі RAD-системи не розташовують до створення об'єктно-орієнтованих рішень. Програмісти, розпещені інструментарієм, що дозволяє в лічені години створювати з готових компонентів продукти, на які раніше йшли дні і місяці роботи, вважають зайвим утрудняти себе детальним вивченням методології та UML, а вже тим більше не прагнуть оформляти свої рішення у вигляді класів, придатних для повторного використання.
Таким чином, об'єктно-орієнтована модель застосовується переважно в дуже великих проектах, де приділяється належна увага етапам аналізу і проектування, а також жорстко контролюється дотримання розробниками встановлених правил.
Спіральна модель
Спіральна модель, запропонована Баррі Боем в 1988 році (рис 2.3), стала істотним проривом у розумінні природи розробки ПЗ. Спіральна модель являє собою процес розробки ПЗ, що поєднує в собі як проектування, так і постадійне прототипування з метою поєднання переваги висхідній і низхідній концепц...
