Модель водоспаду із зворотнім зв'язком

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

 

 

Малюнок 2.3.1. Модель водоспаду із зворотнім зв'язком.

Документоване виконання

Модель була спочатку введена армією США. Ця організація завжди вкладала великі суми у виробництво ПЗ. У сімдесятих роках минулого століття призначення грошових коштів було пов'язане із завданням на Зоряні Воєни. Було оцінено, що програмне забезпечення, потрібне для завдання, буде довжиною в мільйони рядків програмного коду.

Програми були написані на мові Ada.

Армія США весь час доводила, що здатна працювати на дуже складних проектах. Ця організація була причетна до процесу розвитку ПЗ і нових технологій. Деякими з результатів були стандарти DOD STD 2167 і DOD STD 2167a, які описують необхідні методи розробки ПЗ для армії.

Життєвий цикл програм, описаний в документах, називається документованим виконанням. Це каскадна модель, що складається з декількох послідовних етапів. Ці документи будуть потрібні для подальшої розробки. Клієнт забезпечується документами, і лише після схвалення цих документів можлива розробка наступного етапу.

Переваги і недоліки моделі

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

Недоліки моделі такі ж, як у каскадної моделі. Ще одним недоліком є: потрібно вкладати більше інвестицій в роботу з підготовки документів (наприклад ті, що відповідають стандарту DOD STD 2167, складають більше 50% всього робочого навантаження); потрібні паузи в розробці ПЗ для перевірки документів клієнтом. Деякі організації, наприклад IEEE, пропонують свої власні стандарти для документованого виконання програмних проектів.

Прототипування

Всі описані вище методи розробки проектів мають суттєвий недоліки – висока вага помилок, зроблених на етапі формулювання вимог. Тому рекомендується спочатку створити модель перед розробкою систем, для якої формулювання є дуже просте, а потім її модифікувати.Що протягом розробки є дороге або зовсім неможливе (наприклад, для космічних програм).

Типовим прикладом систем, які можуть прототипуватися, - інформаційні системи, які обробляють дані роботи організації за нескладними алгоритмами, тобто здійснюють зберіганням даних, їх пошук на виконання простих операцій. Такі системи виконують функції, які раніше виконувалися без комп'ютера.

Проте, інформаційні системи дають змогу вводити нові функції, неможливі без комп'ютерів: дуже складні аналізи, виробнича оптимізація, підтримка ухвалення рішення і автоматизоване управління виробництвом. Точне визначення вимог до нових функцій може бути дуже важким.

Прототипування – це модель, яка прагне мінімізувати ризик помилок у формулюванні вимог.

Ця модель включає:

· загальне формулювання вимог

· розробку прототипу

· перевірку прототипу клієнтом

· повне формулювання вимог

· реалізацію повної системи з використанням каскадної моделі

Головна мета розробки прототипу - краще формулювання вимог, тобто:

· знаходження відмінностей між побажаннями клієнта і розробника

· виявлення відсутніх функцій

· виявленняя найбільш складних операцій

· формулювання вимог по деталізації

Переваги і недоліки моделі

Перевагами розробки прототипу є:

· можливість дуже швидкої демонстрації робочого варіанту системи

· можливість тестування і часткового використання системи до її повної розродки

Головний недолік - додаткове робоче навантаження на розробку прототипу. Крім того, може виникнути помилкове уявлення про низьку вартість продукту, викликане низькою ціною прототипу.

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

Методи створення прототипу:

· Часткова реалізація (тільки частина вимог виконана. Прототипуються лише найважчі вимоги).

· Мови високого рівня (Smalltalk, LISP, Prolog, мови подальших поколінь, мови формальної функціональної специфікації)

· Використання готових компонентів.

· Генератори інтерфейсу користувача (реалізація прототипу часто обмежується розробкою інтерфейсу користувача).

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

· Робота на папері (це швидкий і зручний метод розробки інтерфейсу користувача, який замовники, зазвичай, високо цінують).

Покрокова розробка

Покрокова розробка починається з формулювання вимог і розробки базового проекту всієї системи. На наступному кроці вибираються деякі функції. Вони реалізуються каскадною моделлю і відбувається опис їх реалізації. Протестувавши реалізовану частину її відправляють замовнику.

 

 

Малюнок 2.6.1. Покрокова розробка.

Переваги і недоліки моделі

Переваги:

· менші часові розриви у взаємодії із замовником

· можливість більш швидкого використання частин системи

· гнучкість при затримках в роботі

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

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

6. Збірка готових елементів

Модель збірки готових елементів акцентує увагу на можливості зменшити капітал, що витрачається на розробку шляхом максимізації схожості створеного ПЗ із вже існуючим.

Вже існуючі елементи можуть використовуватися на різних стадіях розробки. Зазвичай це етап реалізації.

Приклади використовуваних елементів:

· бібліотеки

· мови четвертого покоління, в яких інструкції обробляються як посилання на вбудовані бібліотеки

· повні програми, наприклад браузер допомоги в MS Windows

Останнім часом підвищився інтерес до використання готових елементів на етапах аналізу і дизайну. CASE -Інструменти полегшують використання елементів, створених в інших проектах. Деякі компанії стверджують, що вони можуть використовувати до 90% готових продуктів. Очевидно, що можливість повторного використання залежить від схожості системних компонентів. Деякі компанії пропонують так званий інструментарій дизайну. Це вже готові методи для банків, страхових компаній і інших підприємств. Моделі реалізовуються у вигляді CASE -інструментарію.

Є два методи збірки готових компонентів:

· придбання у зовнішніх постачальників

· розробка біжучого проекту з розрахунком на його багатократне використання в наступних проектах

Переваги і недоліки моделі

Переваги використання готових компонентів:

· висока надійність, - готові компоненти добре перевірені на практиці

· зменшення ризику

· ефективне використання експертів

· стандартні вимоги. Готові компоненти реалізовувалися відповідно до деяких стандартів, які повинні бути задоволені в поточному проекті.

· можливість зменшення ціни. Вартість нових компонентів зазвичай менша, ніж вартість розробки "з нуля".

Недоліками моделі є:

· додаткова вартість створення компонентів для подальшого використання (компоненти системи повинні бути розроблені для користування. Вартість інвестицій може не відшкодуватися в майбутньому).

· Залежність від одного постачальника (постачальник може перестати розробляти бібліотеку або не модифікувати її під нові вимоги ПЗ чи нову апаратуру).

· Недолік інструментів, що підтримують роботу (у разі CAD/CAM, які, як було згадано вище, служать в інших дисциплінах тієї ж мети, що і CASE, мають можливість використання бібліотек готових компонентів. Інструменти CASE підтримували в обмеженому об'ємі цей вид роботи до останнього часу. Сучасні інструменти кращі, але розробка нових все ще необхідна).

Модель спіралі

Модель спіралі запропонував Boem в 1998.

Модель містить в собі чотири первинні циклічні етапи:

· аналіз

· розробка

· оцінювання

· планування

Малюнок 2.8.1 Модель спіралі.

 

На першому етапі формулюються основні складові елементи нової системи. Вони аналізуються, з врахуванням ризику. Проблеми аналізу складових елементів обговорюються на наступному кроці стратегічного етапу проекту. Етап також може передбачати прототипування.

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

На етапі планування формулюються головні цілі виробництва.

Детальніше модель спіралі можна розглянути на мал. 2.8.2.

Мал.2.8.2.