Види прототипування.

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

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

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

Рис. 1 - Еволюційне та експериментальне прототипування

Еволюційне прототипування

Еволюційне прототипування (див. рис. 2) починається з побудови простої системи, яка реалізує найбільш важливі вимоги користувача. У міру виявлення нових вимог прототип змінюється і доповнюється. В остаточному підсумку він стає тією системою, яка вимагається. У цьому процесі не використовується детальна системна специфікація, у багатьох випадках немає навіть формального документа з системними вимогами. В даний час еволюційне прототипування є звичайною технологією розробки програмних систем, яка широко використовується при розробці Web-вузлів і додатків електронної комерції.

Рис. 2 – Розробка ПЗ з використанням еволюційного прототипування

Експериментальне прототипування

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

Рис. 3 - Розробка ПЗ з використанням експериментального прототипування

Існує три основні проблеми еволюційного прототипування, які необхідно враховувати, особливо при розробці великих систем з тривалим терміном життєвого циклу.

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

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

3. Проблеми укладання контрактів. Зазвичай контракт на розробку систем між замовником і розробниками ПЗ ґрунтується на системній специфікації. При відсутності такої важко скласти контракт на розробку системи. Для замовника може бути невигідний контракт, за яким доводиться просто платити розробникам за час, витрачений на розробку проекту; також малоймовірно , що розробники погодяться на контракт з фіксованою ціною, оскільки вони не можуть передбачити всі прототипи, які потрібно створити в процесі розробки системи.

З цих проблем випливає, що замовники повинні розуміти , наскільки ефективне еволюційне прототипування в якості методу розробки ПЗ.

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

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

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

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

Рис . 4 - Покроковий процес розробки ПЗ

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

Відмінності між цілями еволюційного та експериментального прототипування

Існує відмінність між цілями еволюційного та експериментального прототипування.

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

• Метою експериментального прототипування є перевірка і формування системних вимог. Тут спочатку створюється прототип, який реалізує ті вимоги, які сформульовані нечітко і з якими необхідно "розібратися". Вимоги, які сформульовані чітко і зрозуміло, не потребують прототипування.

Інша важлива відмінність між цими підходами стосується управління якістю системи, що розробляється. Експериментальні прототипи мають дуже короткий термін життя. Вони швидко змінюються і для них висока експлуатаційна надійність не потрібна. Для експериментального прототипу допускається понижена ефективність і безвідмовність, оскільки прототип повинен виконати тільки свою основну функцію – допомогти в розумінні вимог.

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