Макетування

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

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

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

Модель може приймати одну з трьох форм:

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

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

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

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

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

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

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

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

Швидке проектування призводить до побудови макета.

Макет оцінюється замовником і використовується для уточнення вимог до ПЗ.

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

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

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

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

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

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

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

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

Стратегії конструювання пз

Існують 3 стратегії конструювання ПЗ:

• одноразовий прохід (Водопадна стратегія) - лінійна послідовність етапів конструювання;

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

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

Характеристики стратегій конструювання ПЗ відповідно до вимог стандарту IEEE / EIA 12207.2 наведені в табл. 1.1.

Таблиця 1.1. Характеристики стратегій конструювання

Стратегия конструирования	В начале процесса определены все требования?	Множество циклов конструирования?	Промежуточное ПЗ распространяется?
Однократный проход Инкрементная (запланированное улучшение продукта) Эволюционная	Да Да Нет	Нет Да Да	Нет Может быть Да