Глава 13
Макети, моделі і прототипи
У багатьох галузях при розробці продуктів поширена практика як можна більш раннього додання їм наочного виду- те, що в індустрії програмних засобів називається візуалізацією. Подібна практика відіграє велику роль також при проектуванні і розробці ПІ. Користувачі, ділові спонсори, проектна бригада й інші учасники команди по розробці продукту можуть на ранній стадії його створення кинути погляд на те, що ж реально виходить на шляху до постачання. Цей перший погляд дає можливість зацікавленим сторонам внести проміжні корективи. Для проектної бригади це ще один метод розробки і можливість перевірити правильність прийнятих рішень, перш ніж вносити зміни буде занадто чи пізно занадто дорого.
Створення чи прототипу прототипирование - термін, яким часто зловживають, що часто вживають неправильно і який часто спантеличує . Незалежно від використовуваної чи назви технічних особливостей ціль проектної бригади складається у візуалізації проектних рішень, що приймає одну чи кілька форм. Ці методи включають начерки, зроблені олівцем на папері, авторські засоби (Авторські чи засоби авторська система- це система для творчої діяльності, спеціалізований програмне забезпечення, що дозволяє розробляти інтерактивні мультимедийные додатка. - Прим. ред.), графічні програми, імітаційне моделювання, раскадировку і програмні прототипи. Підхід на основі прототипирования можна охарактеризувати з помо-щью таких визначень, як швидкість, точність, можливість повторного використання і скрупульозність.
Найчастіше буває важко пояснити і зрозуміти, що доступно і що недоступно, коли Користувачі, чи розроблювачі менеджери аналізують інтерактивний програмний "прототип". Незалежно від використовуваного підходу в матеріалізації проектних рішень є свої переваги. Це дозволяє, щонайменше , виявити обмеження, а також вивчити і розв'язати питання про цінність тієї чи іншої технічної альтернативи.
Ця глава присвячена огляду методів прототипирования користувальницького інтерфейсу. У ній представлені підходи і методи, застосування яких у сполученні з
іншими методами орієнтованого на користувача проектування збільшує можливість створити відмінний "рецепт" для ПІ. Тема, що торкається, безумовно, широкий, тому огляд основних елементів містить посилання, необхідні для подальшого вивчення (мал. 13.1).
У главі розглядаються наступні питання.
" Визначення.
" Мети.
" Методи матеріалізації проектних рішень.
" Організаційні аспекти.
" Відкидання прототипів.
" Непорозуміння.
" Продовження обговорення проекту.
Приклад. Простий сценарій показує, у чому можуть бути корисними матеріалізація і візуалізація проектних рішень ПІ у високошвидкісних середовищах. У даному прикладі першочергова задача полягає в постачанні продукту у високошвидкісне середовище за відносно короткий час. Другорядні аспекти включають задоволення вимог у відношенні витрат, функцій, ПІ, практичності і продуктивності. Однак терміни постачання є домінуючим чинником слідом за високошвидкісним середовищем.
Web-орієнтовані проекти вважаються швидкоплинними по природі, з їхньою допомогою можна дуже швидко пройти через різні види прототипирования.
" Намальовані від руки накидання використовуються для того, щоб зафіксувати задачу, порядок екранів, дані і вимоги до ПІ під час спільних нарад з користувачами. Начерки носять концептуальний характер і представляють функції, дані, поводження і користувальницькі взаємодії. Як правило, начерки грубо і неточно відображають остаточний зовнішній вигляд і поводження інтерфейсу Web-броузера.
" Начерки екранів і порядку їхня зміни швидко перетворяться в спрощений і інтерактивний HTML-прототип. Сторінки будуються з використанням графіки, міток, полів і засобів межстраничной навігації. У прототип можуть бути включені деякі можливості користувальницької взаємодії, однак функції збереження даних відсутні, а багато властивостей ПІ носять статичний характер і імітуються.
" Після того як HTML-сторінки проаналізовані і схвалені користувачами, починається стадія більш серйозної розробки з додаванням можливостей динамічного поводження і поводження реального часу, а також збереження даних. Ці сторінки можуть залишатися сторінками, написаними чистою мовою HTML, вони можуть бути доповнені сценаріями, що написані на убудованих мовах на зразок JavaScrіpt, чи перетворитися в апплеты, ASP-сторінки (Actіve Server Pages - сторінки активного сервера) чи JSP-сторінки (Java Server Pages - сторінки Java-сервера) або мати інші види підтримки.
Процес планування, вироблення вимог, проектування і розробки від початку до кінця може займати зовсім небагато часу - від двох днів до пари тижнів у залежності від обсягу сторінки, її функціонального і интерфейсного наповнення і складності, а також можливості спілкуватися з користувачами. На подібний швидкий цикл розробки впливають наступні фактори.
" Навички по виявленню вимог.
" Навички в проектуванні, необхідні для представлення вимог в однозначної, але проте задовільній формі.
" Навички розробки, обов'язкові для матеріалізації проектних рішень у виді імітаційної чи моделі прототипу ПІ.
" Навички розробки, необхідні для перетворення прототипу ПІ в ПО, що відповідає галузевим стандартам, і необхідні для нього артефакти.
" Навички керування проектами, необхідні для того, щоб підтримувати відповідний рівень концентрації розроблювачів на постачанні і здійсненні ефективних ітерацій.
Цікаво, що подібний процес застосуємо і до інших проектів, де швидкість не обов'язково є домінуючим проектним фактором, але де присутні інші фактори, такі як витрати, функціональні можливості, практичність, продуктивність і надійність.
Визначення
Тепер, щоб уникнути неоднозначності в тлумаченні понять, звернемося до визначень. Візуалізація проектних рішень відрізняється розмаїтістю. Так, одні види візуальних представлень є статичними, інші - динамічними, а деякі допускають взаємодію з користувачем. Якщо звернутися до інших галузей, можна виробити менш заплутану термінологію. Кожний з перерахованих нижче методів може принести користь на будь-якому етапі циклу розробки продукту в міру виникнення проектних питань, таким чином, використання в процесі розробки всіх цих методів цілком ймовірно.
Макети і розкадрування. Матеріалізований у виді набору статичних зображень проект називається макетом. Поведінкові і динамічні стани представляються статичними зображеннями. Сукупність статичних зображень, що демонструє поводження системи під час прогону сценарію користувальницької взаємодії, називається розкадруванням.
Макети і розкадрування можуть бути реалізовані у виді олівцевих начерків на папері, графічних зображень, презентаційної графіки, як копії екранів імітаційних моделей і прототипів. Так само як у випадку імітації і прототипів, деякі макети можуть бути дуже трудомісткими.
Моделі. Модель (імітаційна модель, імітація) являє собою матеріалізацію проекту, вона будується з використанням засобів реалізації, відмінних від тих, котрі передбачається використовувати для розробки продукту. Реалізації не мають перспектив повторного використання, а також засобів розробки, відмінних від тих, котрі плануються для розробки чи продукту використання в продукті. Приклади засобів, застосовуваних для створення імітаційних моделей, включають графічне, авторське, а також імітаційне ПО.
Приклад. Проект Web-орієнтованого ПІ імітується з використанням пакета графічного ПО. Для імітації Web-сторінок і їхнього порядку застосовуються екранні зображення. Реалізовані сторінки повторно не використовуються. Проектна бригада повинна переконатися в тім, що методи створення й елементи керування ПІ, демонстрируемые в моделі, існують у передбачуваному середовищі розробки продукту.
Корисне правило. Варто уникати проектних рішень, побудованих з використанням засобів, відмінних від передбачуваних засобів розробки.
Приклад. Проект Web-орієнтованого ПІ імітується з використанням GUі-ориентированного мови й інструментальних засобів. Програмний код не підлягає повторному використанню. Проектна бригада повинна переконатися в тім, що методи створення й елементи керування ПІ, демонстрируемые в моделі, існують у передбачуваному середовищі розробки продукту.
Корисне правило. Варто уникати проектних рішень, що повинні переноситися між середовищами розробки.
Імітація буває корисної в рамках визначеного контексту для візуалізації вимог, початкового аналізу макетів і порядку проходження сторінок. Деякі моделі надзвичайно реалістичні, інші носять концептуальний характер. Проект ПІ, матеріалізований у виді моделі, може повторно використовуватися, але в багатьох середовищах це дуже сумнівне допущення. Звичайне перетворення моделі в реалізацію для чи прототипу продукту здійснюється в кілька основних етапів. Крім того, побудова моделі являє собою задачу, відмінну від побудови чи прототипу продукту.
Корисне правило. Якщо проект не відрізняється надлишком часу і здатних людей, не відволікайте розроблювачів від роботи над продуктом, щоб сконструювати імітаційну модель. Варто одержати у своє розпорядження фахівців, що володіють відповідними навичками.
Прототипи. Прототип являє собою матеріалізацію проекту, що побудована з використанням передбачуваних засобів розробки для продукту. Засобу розробки включають апаратні засоби, операційну систему і мови програмування. Компоненти реалізації прототипу потенційно можуть повторно використовуватися в продукті, хоча це не обов'язково відноситься до всіх компонентів.
Прототип ПІ зосереджений на ПІ і практичності. Інший тип прототипу, що концентрується на властивостях ПІ і властивостях компонентів ПО, відмінних від ПІ, називається Uі-NUі-прототипом (UІ- User Іnterface; NUІ- non-Uі). Ще один тип прототипу спрямований тільки на властивості компонентів ПО, відмінних від ПІ, і такий прототип як альтернативу називається технічним прототипом.
Приклад. Візуалізація проекту Web-орієнтованого ПІ здійснюється з використанням засобів, призначених для розробки проекту (наприклад, HTML і JavaScrіpt). При цьому реалізуються не функції збереження даних, а Web-сторінки, елементи керування і навігаційні зв'язки. Інформація таблиць баз даних імітується. Макети сторінок і засобу навігації використовуються повторно, однак усі функції завантаження даних і збереження варто реалізувати в продукті.
Приклад. Візуалізація проекту Web-орієнтованого ПІ здійснюється з використанням засобів, призначених для розробки проекту, - мов HTML (HyperText Markup Language - мова гіпертекстової розмітки документів) і JavaScrіpt. При цьому реалізуються Web-сторінки, елементи керування і навігаційні зв'язки, дані зберігаються, а інформаційні таблиці витягаються з модельної бази даних. Макети сторінок, засобу навігації і деякі методи роботи з даними використовуються повторно, але остаточний програмний код, повідомлення про помилки й обробка виняткових ситуацій повинні бути реалізовані.
Прототипи корисні в рамках визначеного контексту для візуалізації вимог, початкового аналізу ПІ і реалізації проектних підходів. Одні прототипи реалістичні, інші носять концептуальний характер.
Деякі сторони проекту ПІ, матеріалізовані як прототип, можуть використовуватися повторно, однак це стає предметом аналізу в міру разви-тия реалізації проектних рішень і методів у ході проекту. Звичайне перетворення прототипу в реалізацію для продукту здійснюється в кілька етапів. Побудова прототипу- задача більш близька побудові продукту, але ці задачі як і раніше розрізняються.
Корисне правило. Переходити від моделі до прототипу необхідно якнайшвидше . Для реалізації всіх аспектів, зв'язаних з користувальницьким досвідом у відношенні продукту, варто застосовувати справжні засоби реалізації.
Наближена реалізація проектних рішень. Макети і раса-кадрування - це синоніми наближених прототипів, однак при використанні термінів слід дотримуватися обережності. Навіть деякі моделі і прототипи можуть розглядатися як наближена реалізація. Ці види реалізації проектних рішень відносно недорогі і корисні під час спільних нарад і деяких видів користувальницьких іспитів для демонстрації системи і дій користувачів при неприступності системи.
Корисне правило. Термін "прототип" варто вживати дуже обережно для того, щоб більш точно виразити тип інструментальних засобів, використовуваних для матеріалізації проектних рішень, і перспективи його повторного застосування.
Спрощений Прототип. Розробка інтерактивних прототипів не вимагає великих витрат, їхній можна створити досить швидко. Існує поняття спрощеного чи полегшеного прототипу, що являє собою конструкцію, що включає концептуальну логіку ПО, його основні і типові екрани, навігацію між екранами і прості, але типові взаємодії. Функціональна глибина і глибина взаємодії обмежені й у прототип включені не всі можливості.
Екрани спрощеного прототипу представляють передбачуваний зовнішній вигляд, эс-тетические особливості, функції, дані і механізми роботи ПІ з великий точ-ностью, що дозволяє користувачам більш реально оцінити майбутній продукт. Уп-рощенный прототип достатній для користувальницької взаємодії і введення даних відповідно до декількох ключових сценаріїв. І знову, для оцінки проектних рішень у тім виді, у якому вони відбиті в прототипі, використовуються евристичні методи і методи спільної розробки.
Корисне правило. Ви повинні уміти використовувати усі види візуалізації проектних рішень протягом всіх етапів проекту.
Мети
Тепер проведемо огляд цілей візуалізації проекту і застосування методів візуалізації до розробки продукту.
Візуалізація продукту. Візуалізація продукту являє собою цикл поступового уточнення і нарощування проектних рішень у відповідь на питання, що виникають у ході розробки. На ранніх етапах розробки вимоги, проект-ные концепції й альтернативи досліджуються за допомогою підходів, що не вимагають великих витрат і дающих швидку віддачу. Низкоуровневые деталі проекту, як правило, не піддаються глибокому аналізу. На даних етапах не обов'язково використовуються передбачувані засоби розробки, однак це не сприяє проясненню того, як буде виглядати і працювати проект стосовно до передбачуваного середовища його використання. Використання планованих інструментальних засобів допомагає оцінити потреби в навчанні і час, необхідне на розробку.
Створювані на папері макети, спрощені інтерактивні чи моделі прототипи базових стилів ПІ, схем прикладного ПІ і користувальницької взаємодії являють собою спосіб як можна більш раннього входження в життєвий цикл продукту. Спочатку намальовані від руки концептуальні версії екранів використовуються для швидкої матеріалізації й оцінки вимог стосовно в рамках безлічі проектних альтернатив. Тут головний зміст полягає в слові швидко.
Корисне правило. Постійно тримаєте в центрі уваги істотні і типові елементи продукту, ПІ і практичності.
Оцінка проекту і реалізації. Для оцінки спрощених і обмежених представлень складних проектних рішень використовуються евристичні методи і методи спільної розробки. Від членів проектної бригади і користувачів потрібно перебороти концептуальні обмеження, що накладаються існуючими на папері макетами, раскадировкой, моделями, а також очікувані проектні проблеми й обмеження, зв'язані з використанням цих засобів.
У міру того як відбувається становлення вимог і скорочення проектних альтернатив, у гру вступають графічні засоби, що дозволяють збільшити ступінь відповідності візуалізації передбачуваному зовнішньому вигляду ПІ, эстетическим особливостям і логіці. Існуючі на чи папері електронні раскадировки починають додавати зміст користувальницькій взаємодії і логіці роботи системи. І знову, головний зміст полягає в слові швидко.
На етапах, що відносяться до середини проекту, при створенні прототипів ПІ і/чи функціональних прототипів використовуються передбачувані засоби розробки для візуалізації можливої реалізації. Тут же проектна бригада звертається до питань широти і глибини проектних рішень, проектних ризиків, а також сферам проекту, що викликає сумніву. Высокоуровневые компоненти проекту представляються з великим ступенем деталізації. На даних етапах низкоуровневые проектні деталі не обов'язково піддавати глибокому аналізу.
Корисне правило. Бажано якнайшвидше створити спрощений прототип ПІ, використовуючи передбачувані засоби розробки і компоненти. Це допомагає гранично прояснити проблеми користувальницької взаємодії, зв'язані з логікою, кроками роботи й обмеженнями інструментарію.
Загальна ідея полягає в тім, щоб домогтися надзвичайно реалістичного втілення проектних рішень, яке можна пред'явити користувачам для одержання відгуків бригади і реальних користувачів.
На більш пізніх acэтапах проекту стають доступні усі види візуалізації, що дозволяє оцінити такі проблеми, як спізніле внесення змін у вимоги, дозвіл проблемних питань практичності, упущених на більш ранніх етапах, а також аналіз альтернатив істотного поліпшення продукту до початку його розгортання.
Методи прискорення розробки. Темп розробки відіграє істотну роль незалежно від того, чи застосовуються макети, розкадрування, імітація і прототипи, чи ні. От деякі методи прискорення розробки ПО.
" Складання прискореного плану-графіка. Варто планувати щонайменше одну щотижневу зборку, а також аналіз нових екранів і методу 'із залученням проектної бригади і користувачів, що беруть участь у проекті. Часті критичні огляди продукту зі спонсорами й іншими зацікавленими сторонами плануються в міру необхідності таким чином, щоб гарантувати виконання контракту.
" Швидкий перехід до прототипированию. Не грузніть у паперових справах. Поставте мету перейти до використання засобів розробки протягом двох тижнів концептуального проектування.
" Внесення виправлень безпосередньо по ходу проекту. Іноді проект добре виглядає на папері, але в дійсності, у міру вступу в гру прототипів, виявляється зовсім неприйнятним з погляду ПІ, практичності і реалізації. Подібний ефект - наслідок природної ітерації над проектом під час прототипирования. Реалізацію і виправлення варто здійснювати прямо по ходу проекту.
" Допустимість твердого програмування. На ранній стадії візуалізації не потрібно витрачати занадто багато часу на розробку реальних структур даних, алгоритмів і питання зборки. Варто постійно піклуватися про реализуемости проектних рішень, але при цьому задачі візуалізації і функціонального прототипирования планувати по окремості.
" Не потоніть у несуттєвих деталях, концентруйтеся на головних задачах і методах. Уникайте небезпеки згорнути на шлях рішення другорядних, тривіальних проблем і загрузнути в розборі помилок. Ухиляйтеся від прототипирования методів ПІ, що не важливі з погляду користувальницької взаємодії.
Труднощі. При використанні методів візуалізації варто направити ос-новные зусилля на досягнення наступних цілей.
" Візуалізація основних складових, котрі визначають рівень задоволеності користувачів (наприклад, можливостей продукту, ПІ, продуктивності, надійності й інформаційної підтримки).
" Увага до дріб'язків, що можуть стати основними перешкодами на шляху до досягнення задоволеності користувачів (наприклад, зовнішній вигляд, зворотний зв'язок і комбінації клавіш).
" Оцінка значимості розглянутих питань з погляду проекту.
Щоб звернутися до основним цілям, представлення проектних рішень, отримані з використанням візуалізації (мал. 13.2), повинні мати достатню якість відтворення (точністю) і повнотою (широтою, глибиною). Проектна бригада повинна приводити у відповідність репрезентативну силу різних методів із проектними компонентами, на які звернена візуалізація. Наприклад, Для рішення деяких питань досить макета, у той час як в інших випадках потрібно створення прототипу, що охоплює ПІ і функціональні можливості продукту. Аналогічно іншим сферам проектування, тут необхідні компроміси між інструментальними засобами, навичками і термінами розробки.
Основна проблема проектної бригади складається в необхідності прийняти рішення про те, які аспекти проекту підлягають матеріалізації з метою їхньої завчасної оцінки разом з користувачами і які методи для цього застосовувати. Що стосується великих продуктів, а також аспектів можливостей і практичності, зв'язаних з функціями і ПІ, вони вимагають розгляди багатьох питань. Для вибору відповідних рівнів і видів застосовуваної візуалізації необхідно знайти оптимальний баланс між такими аспектами, як базовий стиль ПІ і стиль прикладного ПІ, критичні питання проектування й обмеження.
Про що варто подумати. Незалежно від середовища перед проектною бригадою коштує багато проблем, що вимагають рішення. Будь-яка5матеріалізація проектних рішень вимагає розгляду наступних технічних основ.
" Часто використовувані, хитливі, проблематичні задачі і сценарії, під лежачі представленню.
" Часто використовувані і хитливі функції, методи і дані.
" Загальне використання платформного стилю ПІ.
" Специфіка прикладного стилю ПІ, екранів і логіки.
" Проблематичні елементи керування ПІ.
" Необхідний рівень користувальницької взаємодії.
" Необхідний обсяг точності відтворення середовища.
" Глибина фактичної матеріалізації в порівнянні з потребами візуалізації.
" Швидкість представлення.
" Мети у відношенні повторного використання стосовно до кожного виду візуалізації.
Корисне правило. Помнете, що імітація і прототипи- це просто ПО, тут проектна бригада має справу з питаннями цілей, рядків коду, якості, продуктивності, навичок проектування, навичок розробки і календарного планування.
Його звичайно варто уникати. Існують аспекти програмного обес-печения ПІ, що не підлягають матеріалізації до їхньої реалізації.
" Рідко використовувані галузі функціональних можливостей.
" Рідко використовувані властивості ПІ.
" Інформація про продукт (допомога, посібники, підтримка експлуатації).
" Виняткові умови.
" Повідомлення.
" Обробка помилок.
" Аспекти ефективності.
Корисне правило. Помнете про наступний.
" Зосередьте свою увагу на головних напрямках, використовуючи правило "80/20".
" Потрібно швидкий і покроковий підхід до нарощування/удосконаленню продукту.
" Візуалізація - засіб досягнення мети (а не ціль сама по собі).
Вибір методу візуалізації. Хоча з приводу відносної переваги одного методу над Іншим ведуться численні дебати, вибір методу візуалізації для оцінки проектних рішень залежить від багатьох факторів (табл. 13.1). Серед інших аспектів (терміни розробки, доступні людські ресурси необхідної кваліфікації й інші потребуючі розгляди питання) основним фактором, що підлягає обліку при виборі методу візуалізації, виступає наявний у розпорядженні розроблювачів ресурс часу.
Одні методи не підходять для рішення деяких питань, а інші занадто могутні. Застосування тих чи інших методів супроводжується неминучими компромісами. Наприклад, використання функционально-интерфейсного прототипу може не підходити для оцінки користувачами тексту простого повідомлення, як і застосування олівця і папера не завжди допоможе користувачам оцінити складне поводження і дуже деталізована користувальницька взаємодія із системою.
Організаційні аспекти
Звичайно роботи з візуалізації торкаються деякі питання организацион-ного характеру.
" Керівництво повинне підтримувати витрати, зв'язані з залученням коштовних і дорогих ресурсів для робіт з візуалізації, а також будь-які очікувані чи фактичні затримки в розгортанні продукту.
" У великих організаціях, що відрізняються наявністю конкуруючих і конфліктуючих цілей і груп, набирає сили фактор організаційного поводження.
" Люди зі схованими планами перешкоджають досягненню успіху.
" Якщо проектна бригада існує відділено від організації-розроблювача, потрібно прихильність роботам по візуалізації в технічному аспекті.
Бригада по візуалізації і реалізації. Якщо бригади по візуалізації і реалізації - дві різні команди, між групами, що беруть участь у розробці продукту, повинне бути налагоджена відмінна взаємодія. У противному випадку, можна прийти до необхідності застосування реинжиниринга чи зштовхнутися з партизанською війною.
Корисне правило. Для проектування, візуалізації і реалізації краще використовувати тих самих фахівців, щоб мінімізувати передачу знань, а також для посилення відповідальності і поліпшення звітності за отримані результати.
Підтримуюча інфраструктура. Візуалізація надзвичайно по-лезна для оцінки користувачами проектних рішень, для того, щоб донести до зацікавлених кіл, як обстоять справи з продуктом, а також для інфраструктури, щоб підтримати доступ до результатів візуалізації з боку користувачів, проектної бригади й інших зацікавлених кіл.
Рамки візуалізації. Проектна бригада повинна подбати про те, щоб представити свої потреби, зв'язані з візуалізацією. Варто забезпечити підтримку керівництва, узяти до уваги організаційні фактори і налагодити спілкування з всіма учасниками проекту.
Корисне правило. Людські й організаційні аспекти представляють великі труднощі, чим технічні питання. Поясните, що таке візуалізація, а що виходить за її рамки, а також перелічите, що потрібно для досягнення статусу рівня продукту.
Відкидання прототипів
Іноді для складних проектів необхідна розширена оцінка, яку не можна здійснити недорогими методами. Таким чином, немає нічого незвичайного у виборі імітації і прототипирования, що вимагають розробки тисяч рядків коду, щоб оцінити складні програмні пакети з погляду питань, що стосуються численних екранів, алгоритмів, інтеграції і погодженості. У результаті керівники бажають бути упевненими в тім, що після моделювання відкидається мінімальний обсяг готового програмного коду.
У подібних випадках починати випливає з повторного використання як мети. Виходячи з навичок персоналу, що підтримує інфраструктури і календарного плану необхідно ідентифікувати найбільш ймовірні компоненти, придатні для повторного використання. Якщо ж керівництво вимагає більшого, для цього будуть потрібні відповідні навички й інфраструктура.
Іноді доречно відкинути деякі плоди тяжкої праці. Якщо обраний напрямок проектування привело продукт до результату, що не задовольняє вимогам, тоді залишається тільки повернутися до креслярської дошки! Через таку якість практичність і чудові користувальницькі інтерфейси не мають права на існування. Тут потрібно цілеспрямована і важка праця, гарний старт проекту, оцінка і виконання ітерацій.
Ніхто не бажає відкидати що-небудь корисне, але якщо це просто сміття, що не приносить користі в досягненні проектних цілей, чіплятися за нього недоцільно. "Поставити на прикіл" неефективні проектні рішення і програми - краще рішення.
Непорозуміння
З візуалізацією зв'язана безліч непорозумінь. От деякі найбільш розповсюджені і недоречні висловлення учасників проектів, що представляють собою "останнє слово" у проектуванні.
" Прототипирование можна починати при відсутності проекту.
" Прототип краще імітації.
" Не існує коду, що відкидається.
" Завжди є, що виставити напоказ.
" Перейти від прототипу до продукту легко.
" Успішні ітерації стають коротше.
" Прототипирование допомагає раніш заморозити проект.
" Прототип - це специфікація.
" Прототип дає відповідь на всі питання.
" Продукт буде краще прототипу.
" У підтримці і захисті керівництва немає необхідності.
А тепер вникніть і прислухайтеся до приводи нижче й інших висловлень, що дійсно є останнім словом в області візуалізації.
" Візуалізація іноді обходиться дорого.
" Цей засіб досягнення мети, а не сама мета.
" Протягом життєвого циклу більшої частини складних продуктів, як правило, потрібно використання одного чи декількох методів візуалізації.
Продовження обговорення проекту:
принципи й інструкції
До цього моменту ви, імовірно, використовували методи візуалізації для попереднього вироблення задуму проекту і з метою "показу і розповіді" про досягнуті результати. Тепер прийшов час застосувати візуалізацію більш формально.
До прибуття менеджера проекту виконаєте наступне.
" Продумайте, яким образом ви могли б застосувати методи візуалізації на етапах вироблення вимог і концептуального проектування. Що необхідно продемонструвати вищому керівництву, потенційним покупцям продукту і для оцінки - кінцевим користувачам?
" Для проекту, що знаходиться на стадії вироблення рішень концептуального рівня, розробіть щонайменше три види візуалізації для представлення зовнішнього вигляду і логіки навігації. Наприклад, надайте в розпорядження зацікавлених кіл головну сторінку і наступну сторінку з використанням макета, імітації і прототип для середовища персональних комп'ютерів.
" Для кожного із середовищ, у яких передбачається розгортання продукту, розробіть один вид візуалізації, що, як ви очікуєте, мог.би демонструватися протягом усього життєвого циклу проекту. Наприклад, надайте в розпорядження зацікавлених кіл головну сторінку і логіку навігації для кожної із систем на етапах вироблення вимог, концептуального проектування, высокоуровневого проектування, низкоуровневого проектування і реалізації.
" Поверніться до проектного плану, щоб переконатися, що для цілей візуалізації виділено досить ресурсів і часу.
Лідер проекту прийшов до вас, щоб обговорити майбутній брифінг із вищим керівництвом. Команда керівників стурбована календарним планом, витратами і впливом використання візуалізації на терміни розробки. Існує висока імовірність ще одного скорочення, і всі задачі, що сприймаються як несуттєві, зв'язуються з утратою ресурсів. Якщо кого-небудь зі співробітників сприймають як людини, що не вносить безпосередній внесок у побудову продукту, його можуть перевести на виконання інших чи задач тимчасово звільнити. Лідер проекту хотів би виявити велику турботу у відношенні усіх, хто працює над макетами і розкадруванням.
Вище керівництво також бажало б обновити свої представлення про те, як виглядає ПІ стосовно до різних середовищ розгортання, особливо у відношенні практичності і погодженості для різних додатків і платформ. Керівництво також зацікавлене в тім, щоб побачити, як аналогічні додатки підходять у деяким задачам, розв'язуваним за допомогою довідника конференцій.
Подбайте про те, щоб продовжити ваше дослідження через Іnternet.
Наступне нарада з командою керівників заплановане на завтра на 7 ч 30 хв ранки, і у вашому розпорядженні біля двох годин для роботи над 20-хвилинною презентацією. Після презентації намічена інформаційна нарада з великою групою потенційних покупців і ви відповідаєте за 15-хвилинний "показ з розповіддю" про візуалізацію ПІ. Після презентації для клієнтів намічений технічний аналіз напрямку розвитку ПІ з розроблювачами, що приєднаються до бригади.
Питання?
Посилання
Brooks F. The Mythіcal Man Monf/м, Addіson-Wesley: New York, 1995.
Іsensee S. et al. The Art of Rapіd Prototypіng, Іnternatіonal Thomson Computer Press: Boston, MA, 1995.
McConnell S. Rapіd Development, Mіcrosoft Press: Redmond, WA, 1996.
Nіelsen J. Usabіlіty Engіneerіng, Academіc Press: New York, 1993.
Torres R., Melkus L. Guіdelіnes for Use of a Prototype іn User Іnterface Desіgn, Human Factors Socіety Conference Proceedіngs, Oct. 1988.