Макетування

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

Основна мета макетування - зняти невизначеності у вимогах замовника.

Макетування (прототипування) - це процес створення моделі необхідного програмного продукту. Модель може приймати одну з трьох форм:

1) паперовий макет або макет на основі ПК (зображує чи малює людино-машинний діалог);

2) працюючий макет (виконує деяку частину необхідних функцій);

3) існуюча програма (характеристики якої потім повинні бути поліпшені).

Як показано на рис. 2.2, макетування ґрунтується на багаторазовому повторенні ітерацій, в яких беруть участь замовник та розробник.

Рис. 2.2. Макетування

Послідовність дій при макетуванні представлена ​​на рис. 2.3. Макетування починається зі збору й уточнення вимог до створюваного ПЗ Розробник і замовник зустрічаються і визначають всі цілі ПЗ, встановлюють, які вимоги відомі, а які належить довизначити.

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

Перевага макетування: забезпечує визначення повних вимог до ПЗ.

Недоліки макетування:

 замовник може прийняти макет за продукт;

 розробник може прийняти макет за продукт.

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

Рис. 2.3. Послідовність дій при макетуванні

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

Дата добавления: 2014-01-07