Розкадровування

Компромісним рішенням між електронним і паперовим варіантами прототипів UI класу, являються презентації, виготовлені за допомогою засобів електронного офісу (наприклад, комбінації Microsoft Visio і Microsoft PowerPoint). У цьому випадку користувач позбавлений свободи вибору, що надається йому поведінковим прототипом. Але ідею покрокової зміни екранів у процесі реалізації сценарію варіанту використання цілком можна реалізувати. Цей вид рішення визначається у [3], як пасивне розкадровування. Активне розкадровування є подальшим розвитком поняття пасивного розкадровування, із застосуванням засобів анімації і т.п. Третій вид розкадровування – інтерактивне, є електронним одноразовим горизонтальним прототипом.

Ілюстровані сценарії прецедентів (ІСП) разом із прототипами дозволяють досягти кращого розуміння між замовником і розробником [4]. Але, якщо прототипи адресовані швидше замовникові, ніж розробникові, то з ІСП ситуація протилежна: вони містять додаткові відомості, що допомагають розробнику краще зрозуміти специфіку проблемної області і, тим самим, краще відбити її у інтерфейсі користувача.

Основна ідея ІСП – розширити текст опису сценарію варіанту використання аспектами застосовності.

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

Розрізняють 3 різновиди аспектів застосовності : орієнтири, середні значення атрибутів і обсяги об'єктів, середня інтенсивність використання [4].

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

Приклад. Опис потоку подій ІСП для прецеденту «Оформити замовлення», розширеного орієнтирами (текст у квадратних дужках).

У процесі виконання прецеденту менеджер з прийому замовлень вибирає замовника з клієнтської бази, визначає товарні позиції з довідника і вказує їх кількість. Система відображає на моніторі найменування позицій, ціну, суму і кількість на складі. Менеджер призначає знижку і визначає порядок оплати. Система розраховує підсумкову суму. [Менеджер повинен мати можливість бачити поточне сальдо розрахунків з клієнтом і дані по останніх десяти угодах із статистикою дотримання договірних зобов'язань].

Середні значення атрибутів і обсяги об'єктів

Ця інформація дозволяє оптимальніше побудувати призначений для користувача інтерфейс і оцінити на ранніх стадіях проекту «вузькі місця» в обробці даних, які можуть вплинути на продуктивність системи.

Так, при виборі з 2 можливостей краще підійде елемент управління checkbox, при виборі, обмеженому 2-3 десятками позицій, перелік, що випадає, при різноманітті у тисячі варіантів, знадобляться додаткові засоби фільтрації і пошуку.

Приклад: Опис потоку подій ІСП для прецеденту «Оформити замовлення», розширеного обсягами і середніми значеннями об'єктів (текст у фігурних дужках).

У ході виконання прецеденту менеджер з прийому замовлень вибирає замовника з клієнтської бази {до 10000 клієнтів}, визначає товарні позиції з довідника {товари розбиті на 10 категорій, кількість позицій у категорії не перевищує 500} і вказує їх кількість {до 100 позицій, середнє замовлення – 8 позицій}. Система відображає на моніторі найменування позицій, ціну, суму і кількість на складі. Менеджер призначає знижку і визначає порядок оплати {на даний момент існують 3 варіанти оплати}. Система розраховує підсумкову суму.

Середня інтенсивність використання

Середня інтенсивність використання дозволяє виділити сценарії «масового» використання, в яких усе повинно бути ідеально (швидкодія, зручність користування, мінімум дій на виконання операцій). Наприклад, інтерфейс касира у супермаркеті. Іна противагу сценаріям, що виконуються від випадку до випадку, не щодня і що не вимагають особливої оперативності (наприклад, розрахунок заробітної плати за місяць). Ці дані дозволяють структурувати подання інформації, прибрати з «головних» інтерфейсів рідко використовувані опції тощо.

Приклад. Фрагмент опису потоку подій ІСП для прецеденту «Оформити замовлення для нового клієнта», розширеного середніми значеннями об'єктів (текст в круглих дужках).

У процесі виконання прецеденту менеджер по прийому замовлень вибирає замовника з клієнтської бази (у 95% випадків), або викликається інтерфейс реєстрації нового клієнта (у 5% випадків).

Література теми:

1. Вигерс К. Разработка требований к программному обеспечению. Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2004. -576с.

2. Брауде Э. Технологии разработки программного обеспечения – СПб: Питер, 2004. - 655 с.

3. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению–М.: ИД "Вильямс", 2002

4. Новиков Л. Введение в Rational Unified Process http://www.interface.ru/rational/interface/151199/rup/main.htm

5. Маглинец Ю. Анализ требований к автоматизированным информационным системам БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий – Intuit.ru, 2008.