Глава 11
Концептуальне проектування
й архітектура
Усі задачі, зв'язані з проектуванням і розробкою ПІ, а також забезпеченням практичності продукту, надзвичайно важливі. Перша конкретна проектна задача- концептуальна і припускає вибір вірних основних положень для прийняття проектних рішень. У багатьох відносинах концептуальний проект ПІ - це, по суті, його архітектура. Послідовні рівні проектних рішень дозволяють нарощувати визначення і ступінь деталізації зовнішнього вигляду, поводження, інформаційної підтримки і користувальницької взаємодії на більш пізніх етапах проектування.
Усі кроки проектування в однаковій мірі важливі. Концептуальне проектування, що стосується концептуальних моделей, стилю ПІ і навігаційних структур, не зупиняється на деталях зовнішнього вигляду, поводження, взаємодії і на функціональних можливостях продукту. Перший вірний крок важливий для збільшення шансів на найкоротший і найменш хворобливий шлях до досягнення цілей проекту у відношенні ПІ, практичності, погодженості, інформаційної підтримки, часу відгуку, надійності й інших проектних факторів.
З одного боку, альтернативні концептуальні рішення формулюються, оцінюються і піддаються ітеративному перегляду, а також дуже швидкому нарощуванню при невеликих витратах - на концептуальному рівні. Тут надзвичайно важливу роль грають методи генерації альтернатив, так само як у випадку швидкого прототипирования, оцінки, ітеративного перегляду і нарощування. Найбільш багатообіцяючі проектні шляхи піддаються тестуванню, добору й уточнюються пізніх етапах розробки продукту. Прийняття вірних рішень- чи раніш пізніше - має істотне значення для успіху проекту.
З іншого боку, помилка в концептуальних проектних рішеннях, непомічена на ранніх проектних етапах розробки, передається на наступний етап і потенційно впливає на безліч екранів, взаємодій, підтримку користувачів, програмний код, навчання, тестування, графік^-графік-план-графік і вартість розробки. Так само, як у випадку інших програмних дефектів, вартість виправлення тим вище, ніж довше помилка залишається невиявленої.
У даній главі розглядаються наступні питання.
" Формування ведення.
" Розподіл компонентів роботи.
" Передбачувана користувальницька модель.
" Архітектура ПІ - самий высокоуровневый проект.
" Продовження обговорення проекту: концептуальне проектування.
"
Посібник зі стилю як компонент постачання етапу концептуального проектування розглядається в наступній главі книги.
Концептуальний проект (мал. 11.1) являє собою попередній ескіз показывающий основні функції, ПІ, візуальні, інформаційні й інші характеристики проекту продукту. Це перспективний погляд на призначення продукту - представлення надій ділових спонсорів і бригади розроблювачів продуета.
Відповідно до класичного формулювання архітектура ідентифікує компоненти системи, розподіляє можливості системи по різних компонентах і позначає інтерфейси між компонентами системи. З погляду користувача, що знаходиться у взаємодії із системою, архітектура ПІ - це буквальний розподіл роботи між системою і користувачем, а також користувальницький інтерфейс між ними.
Корисне правило. На підставі аналізу характеристик користувачів, вимог, задач і ділових потреб можна представити в явній і нахабний формі основну ідею проекту у відношенні візуалізації і взаємодії, організаційні принципи і структуру, а також типової поведінкової моделі ПО.
Концептуальний проект включає наступні компоненти.
" Загальний стиль ПІ.
" Прикладний стиль ПІ.
" Сутності й артефакти кінцевих користувачів.
" Передбачувана користувальницька модель.
" Організація, структура, потоки і відносини між сутностями коні користувачів.
" Ключові принципи функціонування.
Перелік компонентів постачання концептуального проекту не обмежений тільки ПІ. Члени бригади розроблювачів продукту також відповідають за постачання концептуальних проектних рішень.
" Член бригади, відповідальний за навчання, надає концептуальні проектні рішення і прототип підготовчих матеріалів (засобу, навчання, підтримки ефективності і засобу робочої допомоги), а також засобу допомоги при експлуатації, тренувальний^-учбово-тренувальні засоби, використовувані за принципом "точно в термін", і засобу робочої допомоги.
" Член бригади, відповідальний за оцінку практичності, надає евристики, а також орієнтовані на користувачів оцінки концептуальних проектних рішень стосовно вимог.
" Член бригади, відповідальний за маркетингову інформацію, надає концептуальні проектні рішення і матеріали по прототипі.
Усі компоненти, що поставляються кінцевим користувачам, проходять таке ж проектування, прототипирование, оцінку й ітерації, що і компоненти ПІ. Істотну роль грають практичність і ефективність усіх компонентів продукту, що поставляються.
Рис.11.1 Концептуальне проектування
Формування бачення
Найбільш важливий аспект концептуального проекту- його потенціал з погляду формування ведення. Концептуальний проект установлює те, що називається "враженням і відчуттям" від програмного продукту, а також дозволяє виявити, що зі спроектованого і сконструйованих під "обкладинкою" проекту служить для підтримки ведення. Ведення задає загальне відчуття того, наскільки продукт логічно погоджений і працює в підтримку користувальницьких задач.
" Альтернативи, закладені в концептуальний проект, одержують наочність у специфікації і прототипі.
" Для одержання вихідної інформації від користувачів застосовуються методи залучення користувачів до участі в проекті.
" Для прогнозування перспективних шляхів розвитку проекту застосовуються методи оцінки практичності.
Найбільш багатообіцяючі шляхи розвитку проекту відбираються й оформляються документально у виді специфікації концептуального проекту. Також описується передбачуваний стиль ПІ.
Попередній аналіз. Проектна бригада вивчає й аналізує вимоги, профілі, задачі, робітничі середовища користувачів. Існуючі користувальницькі засоби навчання, артефакти, засоби допомоги в роботі, документація в успадковане ПО також піддаються аналізу.
Методи спільної розробки. Методи залучення користувачів до участі в проекті надзвичайно корисні для розуміння суті розробки. Користувачів варто втягувати в процес концептуалізації існуючих задач, аналіз способів удосконалення задач, а також у процес візуалізації і вироблення альтернативних рішень.
Корисне правило. Починайте формулювати концептуальний проект якнайшвидше (після того як у вашому розпорядженні виявиться критична маса інформації).
Проектна ітерація 1 (І1). Концептуальне проектування являємо собою першу з безлічі проектних ітерацій. Хоча він позначається як І1, проектна бригада на даному етапі проектування швидко виконує численні ітерації. Ітерації в рамках концептуального проектування позначаються І11, І12, і т.д.
Є багато способів "обдерти липку", точно так само існують і численні способи "обдерти" ПІ. Однак настає момент, коли бригада розроблювачів продукту приймає рішення, по якому шляху розвитку проекту випливати, спираючи на користувачів. І1 - це інтервал часу, виділений для ухвалення рішення.
Початкова ітерація виражається в наступних діях.
" Формулювання безлічі проектних альтернатив.
" Опис кожної проектної альтернативи.
" Оцінка кожної альтернативи стосовно вимог, середовищам і користувачам.
" Вибір найбільш багатообіцяючих альтернатив і відкидання тих, котрі розцінюються як небажані.
" Повторення, при необхідності, перерахованих дій доти , поки вимоги не будуть задоволені.
Головна мета першої ітерації полягає в доборі найбільш придатних міцних альтернатив для подальшого розгляду й уточнення (мал. 11.2). Краща ситуація для ітерації І, - виявлення єдиної проектної альтернативи для просування і більш детального вивчення. Як правило, протягом наступних фаз аналізу звичайно бракує часу і ресурсів для вивчення безлічі проектних альтернатив, що вимагають більш скрупульозної
роботи по проектуванню, створенню прототипів, оцінці і виконанню ітерацій.
Неприйнятні рішення Хід проекту
Рис. 11.2. Звуження кола припустимих альтернатив у процесі проектування
Існують і інші перспективні проектні альтернативи. Їх тримають як додаткові напрямки розвитку чи проекту функцій, що набудовуються, на випадок, якщо в міру уточнення і розширення проекту основний напрямок виявиться проблематичним. Звичайно інші альтернативи виявляються пізніше у виді сприятливої можливості, що доцільно використовувати в сформованих обставинах.
Корисне правило. У процесі концептуального проектування необхідно піддати оцінці сукупність альтернатив, але вибрати випливає одну, найбільш багатообіцяючу з погляду цілей і задоволення користувальницьких нестатків, для переходу до высокоуровневому проектування.
Альтернативи використання базових властивостей ПІ
Проектна бригада також аналізує альтернативне використання основних стилів ПІ, що повинні застосовуватися і представляти зовнішній вигляд ПІ і поведінкові моделі користувальницької взаємодії із системою. Приклади альтернативних форм використання базових властивостей GUі-интерфейса включають вибір наданих у розпорядження користувачів можливостей, а також можливостей, доступних за замовчуванням (наприклад, рядок меню (стан "включений"), панель інструментів (стан "включений і відображається під рядком меню") і піктограми панелі інструментів (стан "великі (Large) з текстом")). GUІ -, WUІ- і HUІ - інтерфейси надають незліченні можливості й альтернативи.
Альтернативи використання прикладних стилів ПІ
Бригада розроблювачів формує і додає наочний вид проектної моделі користувальницького інтерфейсу прикладного ПО, що підтримує від п'яти до семи задач, що роблять найбільший вплив на роботу системи. Ці задачі можуть представляти до 20% обсягу проекту, на которые приходиться до 80% обсягу використання, впливи і значимості продукту. Приклади альтернативних прикладних стилів ПІ включають представлення програмних артефактів користувачів щонайменше в трьох формах.
o Електронної.
o Фізичної.
o Візуальної (наочної).
Електронний СТИЛЬ. Електронний стиль концептуально подібний електронній чи таблиці документу. Цей тип додатка показує користувачу комп'ютерні чи сутності елементи предметної області без фізичних границь. Прикладом може служити компьютеризованный перелік файлів каталогу без сторінок (на противагу адресній книзі).
Фізичний СТИЛЬ. Фізичний стиль представляє комп'ютерні сутності з використанням понять, виведених на основі їхнього представлення в реальному світі, але в рамках обмежень артефактів ПІ на зразок вікна. Прикладом може служити адресна книга, постачена покажчиком, зі сторінками, відображуваними в GUі-окне.
Візуальний СТИЛЬ. Візуальний стиль аналогічний фізичному стилю, просунутому на один крок уперед - оформлення вікна отсутствует. Кінцевий користувач може взаємодіяти з фізичною сутністю, однак властивості вікна йому недоступні. Візуальна сутність виглядає так само, як у реальному світі, хоча вона підтримує віконні функції (закриття і меню для доступу до команд).
Інші СТИЛІ. До інших стилів ПІ можна віднести ігровий підхід, що власне кажучи, перевертає проблему з ніг на голову і займається пошуком шляхів перетворення комп'ютерних артефактів у гру. Наприклад, гра Fіnd Francіne може служити ігровою моделлю для адресної книги.
Архітектурний стиль для організації функцій і інформації стосовно до ПІ являє собою об'єктний (чи объектно-ориентированный) стиль. Можливості [ продукту представляються як об'єкти, класи об'єктів, ієрархії класів, дії і відповідні властивості. Цей стиль не занадто відрізняється від фізичного стилю за винятком того, що в ньому може брати участь базовий объектно - орієнтована мова програмування. Приклади об'єктів включають адресну книгу і каталог, а прикладами дій є операції Add (Додати) і Person (Суб'єкт).
Інший тип архітектурного стилю- процедурний стиль. Можливості продукту представляються як задачі. Користувач може вибрати необхідні йому задачі і вказати інформацію для подальшої роботи. Прикладом подібного стилю є програма "майстер" (wіzard). (Програма-розроблювач, чи програма-генератор, що створює програмні елементи з заданими властивостями, проводить користувача через кожен крок багатокрокової операції, по шляху постачає його корисною інформацією і, як правило, жадає від користувача завдання деякої вхідної інформації, при цьому коментує кожну опцію. - Прим. ред.)
Зауваження. У багатьох відносинах ці стилі взаємодоповнюючі і часто інтегруються цікавими способами (наприклад, процедурний електронний потік задач). Кожний зі стилів забезпечує основу для вибору базового стилю для ПІ додатка. Існують і інші підходи, що доречні для застосування їхній до проектних проблем у стилі генерації чи ідей інтерпретації безлічі варіантів.
Об'єднання перестановок і сполучень стильових варіацій.
Проектна бригада повинна об'єднати в стилі його численні варіації. Підходи до генерації проектних альтернатив варіюються від мозкового штурму до індивідуального виробітку проектних рішень з наступної груповою інтеграцією ідей. Незалежно від підходу істотну роль грає генерація ідей. Проектна бригада домовляється, яким образом займатися цією роботою, а потім випливає обраному підходу.
Корисне правило. Варто виробити, як мінімум, три проектних альтернативи, використовуючи варіанти стилю ПІ і прикладного стилю ПІ: традиційне проектування; нетрадиційне проектування, що розсовує границі можливого; і в деякому роді проміжний варіант проектування (мал. 11.3).
Традиційне проектування представляє існуюче положення справ в області інженерії програмних засобів, що знайшло відображення в сучасних відомих програмних продуктах. Аналогічно інженерним задачам, традиційне проектування - предмет добре відомий з погляду застосовуваних у ньому технологій, методів і схвалення його користувачами.
Нетрадиційне проектування характеризується можливостями, що іноді здаються нереальними, революційними чи просто благими побажаннями.
Нетрадиційні можливості можна чи кількісно якісно удосконалювати, чи наростити автоматизувати окремі аспекти рішення користувальницьких чи задач поліпшити їхнє сприйняття. Реалізувати нетрадиційне проектування дуже важке і дорого. Діапазон можливостей подібного підходу до проектування допомагає визначити границі проектних рішень і проблеми реалізації, що випливають з них.
Рис.11.3. Вимір концептуального проекту
Проектування проміжного рівня принципово не представляє нічого нового з погляду проектування і реалізації й у той же час це - кількісний і/чи якісний крок уперед. Якщо проект носить еволюційний характер, проектування проміжного рівня може бути саме тим підходом, що потрібно. Нетрадиційне проектування використовується як стратегічний орієнтир, якщо результати, одержувані у відношенні практичності, підтверджують правильність обраного напрямку.
Розподіл компонентів роботи
Основна задача, зв'язана з концептуальним проектуванням, полягає в тім, щоб установити, які функції покладаються на користувача, а які - на систему. Результат рішення цієї задачі визначається наступними аспектами.
" Задачі, що підлягають виконанню.
" Користувачі, що виконують задачі.
" Сильні сторони й обмеження можливостей користувачів.
" Сильні сторони й обмеження апаратного забезпечення, системи, засобів ПІ, додатка і стилів взаємодії, що відносяться до задачі.
" Перспективні характеристики ПО, що поліпшують, чи нарощують автоматизують окремі аспекти рішення користувальницьких задач.
" Перспективний шлях найменшого опору, що веде до досягнення заданих тимчасових і вартісних обмежень.
" Перспективи виконання вимог у відношенні ПІ і практичності.
У загальному випадку бригада розроблювачів продукту розподіляє відповідні компоненти задач по системі і користувачам. На систему приходиться вся робота,
що не можуть виконати користувачі, а на користувачів покладаються задачі, рішення яких проблематично для комп'ютерного ПО. Результуюче розподіл робіт визначається співвідношенням, який удається домогтися бригаді розроблювачів.
Передбачувана користувальницька модель
Сприйняття роботи системи користувачем називається користувальницькою моделлю (мал. 11.4). Це погляд користувача на те, як виглядають події, що відбуваються в системі; така модель представляє ефективний спосіб вивчення і прогнозування поводження ПО. Важливий аспект задач концептуального проектування складається в посиленні цієї особливості навчання і поводження користувача для свідомого формування ПІ, щоб стимулювати поява користувальницької моделі, що відповідає намірам проектувальника.
Передбачувана користувальницька модель, що іноді називають моделлю проектувальника, являє собою версію концептуального знання, що повинний одержати користувач, щоб успішно освоїти і використовувати систему. Цю версію формулює проектна бригада. Ціль бригади полягає в тім, щоб явно і свідомо спроектувати і реалізувати передбачувану користувальницьку модель яка виводить відповідну користувальницьку модель з ведення кінцевого користувача. Передбачувана користувальницька модель служить вираженням того, що підтримується, і що не підтримується продуктом, а також способу взаємодії користувача із системою. Ступінь відповідності моделі впливає на навчання і легкість використання.
" Поняття. Загальне чи представлення ідея, чи конструкції питання, що відображають проектні рішення.
" Можливості. Можливості, забезпечувані набором функцій і ПІ продукту. Приклади функціональних можливостей- команди Add (Додати) Person (Особа) адресної книги. Прикладом можливостей ПІ, інтегрованих з функціональними можливостями, є операція перетаскування (Drag) об'єкта Person з адресної книги в календар подій (точніше, з вікна додатка "Адресна книга" у вікно додатка "Календар заходів". - Прим. ред.).
" Аналогії і метафори. Подоба між подібними чи можливостями поняттями, не зв'язаними буквально.
" Системні і користувальницькі об'єкти. Представлення комп'ютерних користувальницьких об'єктів для користувача. Наприклад, системний об'єкт включає таку сутність, як робітник стіл, у той час як користувальницький об'єкт містить такий елемент, як документ.
" Зовнішній вигляд. Візуальне чи графічне представлення чи об'єкта дійств вия на екрані дисплея привносить концептуальну інформацію про природу сутності.
" Поводження, порядок відображення і відносини. Явне поводження сутності процесі взаємодії користувача із системою є важливим концептуальним компонентом. Відносини між сутностями і приступність дія для схожих об'єктів також значно підсилює концептуальне представлення.
" Взаємодії. З кожною сутністю зв'язаний протокол, якому повинний випливати користувач для взаємодії з нею.
Критерії успіху. Ціль проектної бригади полягає у формувань моделі, що задовольняє декільком критеріям.
" Орієнтація на користувача. Передбачувана користувальницька модель описується в користувальницьких термінах і зорових образах. Варто уникати вживання комп'ютерних термінів і чи понять виражати їх в орієнтованому на користувача стилі.
" Природність. Передбачувана користувальницька модель являє собою абстракцію і відображення користувальницького середовища. Об'єкти, дії і стилі взаємодії знайомі і зручні кінцевому користувачу.
" Узагальнений погляд. Передбачувана користувальницька модель дає высокоуровневый погляд на систему. Критичні объектно-ориентированные властивості і можливості ПІ системи описуються за допомогою передбачуваної користувальницької моделі.
" Інтеграція. Моделі компонентів (об'єктів, дій, елементів керування вікном і т.д.) працюють належним чином тільки спільно. Класи об'єктів і дій разом з ієрархією класів і структурами спадкування формують інтегральне і завершене ціле.
" Погодженість. Компоненти передбачуваної користувальницької моделі погоджені з передбачуваною моделлю системного рівня й один з одним. Аналогічно, системні компоненти погоджені з користувальницьким середовищем і потребами.
" Простота. Хоча передбачувана користувальницька модель досить усеосяжна для опису кола знань, необхідних користувачу для належної взаємодії із системою, вона відрізняється простотою і лаконічністю. Складних взаємодій і відносин між системними сутностями не існує або вони не складніше, ніж їхні аналоги з реального світу.
" Продуктивність. Реалізація проекту, заснована на передбачуваній користувальницькій моделі, відображає, що саме бажають робити користувачі. У роботу не повинні вводитися штучні чи додаткові кроки, при цьому автоматизація і нарощування користувальницьких задач украй необхідні.
" Інтуїтивна наочність. Користувачі в стані зрозуміти, яким образом виконувати невідомі чи рідко зустрічаються задачі. У гіршому випадку, користувач повинний одержати інструкції про те, як виконувати задачу, тільки один раз.
Види передбачуваних користувальницьких моделей. Як відправну крапку для побудови передбачуваної користувальницької моделі може виступати кілька можливих підходів. Деякі з найбільше що часто зустрічаються в ПІ програмного забезпечення моделей були розглянуті раніше (електронна, фізична, візуальна й ігрова). Дві інші можливості - пошукова і гібридна моделі- являють собою комбінації різних стилів. На мал. 11.5 показані три моделі для звертання до інформації: пошукова модель, каталог адресної книги і модель, що відноситься скоріше до фізичного типу, що дозволяє здійснювати безпосереднє введення інформації на всіх рівнях.
Принципи проектування для передбачуваної користувальницької моделі. Формування передбачуваної користувальницької моделі підкоряється декільком принципам і правилам.
" Варто передбачати єдину модель системного рівня. Одна базисна
передбачувана користувальницька модель для системи відбиває ключові
поняття й аналогії, що повинні- з погляду бригади розроблювачів- сприйматися користувачами для системи в цілому. Модель системного рівня забезпечує інтегровану концептуальну схему для компонентів моделі в рамках системи.
" Необхідно моделювати користувальницьке середовище. Варто будувати передбачувану користувальницьку модель, природну й очевидну для цільової аудиторії системи. Передбачувана користувальницька модель повинна відповідати фізичному середовищу і досвіду користувачів. Користувачі переносять знання із середовища в систему, застосовуючи те, чому вони навчилися.
" Необхідно представити розроблювальну систему. Передбачувана користувальницька модель повинна відповідати реальності встановлюваної системи. Вона відкриває доступ до розуміння системи і представляє систему з погляду її рамок: що входить у поняття системи, а що виходить за її межі. Передбачувана користувальницька модель сприяє початковому навчанню користувачів, а також доповнює функціональні і стосовні до ПІ розширення, що виходять за межі всіх метафор, сформульованих проектною бригадою. При належному проектуванні передбачувана користувальницька модель сприяє навчанню користувачів і експлуатації системи понад первісне і випадкове використання, а також захищає погляд користувачів на систему від концептуальних шор.
" Варто забезпечити діалоги, що погодяться із середовищем, і представлення. Передбачувана користувальницька модель включає спосіб взаємодії користувача з об'єктами системи (наприклад, застосовувані стилі взаємодії і методи відображення). Стилі, що погодяться із середовищем, представлення включають візуальні і графічні аналоги об'єктів і взаємодій. Проектна бригада прагне забезпечити методи, що дозволяють легко здійснювати відображення, зв'язане з взаємодіями і зовнішнім виглядом об'єктів у користувальницькому середовищі. Концептуальна точність відтворення фізичних об'єктів комп'ютерними об'єктами є дуже важливим фактором.
" Модель повинна бути гнучкої. Передбачувана користувальницька модель повинна бути досить гнучкої для того, щоб допускати нарощування і розширення системи. Усі можливості, забезпечувані системою, повинні бути ретельно продумані, а модель повинна вибиратися відповідно для кожного проектованого основного компонента системи. Крім моделей для об'єктів визначаються також моделі для дій. Істотним функціям системи придается візуальна форма, що відбиває досягнутий рівень розуміння користувальницьких можливостей, діалогів і парадигм взаємодії. Уточнення може зажадати розробки моделей для елементарних об'єктів, операцій і взаємодії.
" Варто зробити над моделлю кілька ітерацій. Як правило, перший проект- не обов'язково кращий варіант для просування вперед. Передбачувану модель варто обговорити з користувачами, щоб переконатися в її придатності. Аналогічно іншим проектним компонентам, існує безліч альтернатив. Варто ідентифікувати кілька альтернативних варіантів, що задовольняють проектним обмеженням, і, ґрунтуючись на відгуках користувачів, вибрати для більш детального вивчення щонайменше три альтернативи. Основна проблема проектної бригади- сформувати модель, що влаштовує передбачуваних користувачів.
" Варто дотримувати обраної моделі. Після того як передбачувана користувальницька модель обрана, варто строго дотримувати її у всіх аспектах проектування і конструювання. Ознайомте з передбачуваною користувальницькою моделлю усіх фахівців, що беруть участь у розробці продукту. Прийняті концепції установлюють фундаментальні принципи, що впливають на всі аспекти системи, а також проектування об'єктів і реалізацію. Колективно використовувана модель сприяє прийняттю рішень більш численною бригадою. Навчальні стратегії по вивченню обще-доступной моделі впроваджуються в соціальне середовище кінцевих користувачів.
Корисне правило. Коли ви описуєте системну сутність, уподібнюючи її чому-небудь іншому, ви працюєте над передбачуваною користувальницькою моделлю.
Архітектура ПІ - самий
высокоуровневый проект
Уся концептуальна інформація, що стосується ПІ, підлягає інтеграції з метою вироблення концептуального проекту, що включає высокоуровневую специфікацію, початкову візуалізацію матеріалів по продукті й оцінні матеріали.
Концептуальна логіка відображення екранів. Організаційна ієрархія вікон/сторінок/екранів для програмного додатка зображується в наочному виді. Це высокоуровневая структура програмного забезпечення ПІ (тобто спосіб його організації з погляду користувача). Концептуальний порядок відображення- це буквальне дерево екранів, прохідне при виконанні задачі. Користувач повинний одержати доступ до одному чи декільком екранам у дереві для введення даних, здійснення вибору й аналізу результатів запиту до ПО. Потенційно можливі кілька стилів порядку відображення.
Корисне правило. Доцільно зобразити ієрархію екранів ПІ, що включає доступ за допомогою робочого столу і всіх командних діалогів.
Концептуальні екрани. Деякі екрани унікальні для додатка, а інші є загальними і представляють проектні чи стереотипи повторно використовувані компоненти. Прикладом екрана загального виду служить список об'єктів, а прикладом специфічного екрана - макет для бізнесу-об'єкта.
Корисне правило. Ідентифікуйте загальні і специфічні екрани, а також унікальні типи елементів керування, що вимагають розробки.
Концептуальна візуалізація. Базові екрани і поводження втілюються у виді концептуального прототипу. У ньому знаходять висвітлення графіка, концепції, стилі ПІ, графічні стилі і взаємодії. Загальна ідея полягає в тому, щоб одержати деяке наближення реалізації, що представляється користувачам для формування практичного зворотного зв'язку.
Корисне правило. Варто уникати демонстрації зайво красивої чи надто вигадливої візуалізації, а також занадто пригладжених взаємодій - вони можуть виявитися дуже далекі від реальності. Це стосується засобів реалізації, а також користувальницьких елементів керування, наявність яких очікується в рамках обмежень на продукт. Наприклад, початкові прототипи візуалізації можуть включати дійсно витончені методи, які можна быстр©-воплотить у стилі властивим прототипам обмежень за допомогою фахівців з високим рівнем мотивації. Іноді ці методи дорогостоящи і віднімають багато часу для погодженої реалізації стосовно до великих продуктів.
Принципи функціонування. Включають опис базових і фундаментальних правил функціонування ПО. Неявне поводження і чекання виражаються в явній формі. Деякі типові чекання у відношенні ПО перераховані далі.
" Безпосереднє введення для всіх екранів. Прикладом може служити відновлення запису в адресній книзі без необхідності виконання спеціального запиту на редагування, чекання відображення екрана, забезпечення введення в екран редагування, вибір кнопки ОК і чекання повернення керування з чи можливістю без можливості спостерігати автоматичне відображення змін.
" Бездоганне збереження. Наприклад, запам'ятовування введених користувачів даних без необхідності звертання до спеціальної команди для чи збереження діалогу, що просить підтвердження збереження Would you lіke to save? ( чиБажаєте ви виконати збереження?).
" Віконна пам'ять. Наприклад, запам'ятовування останнього розміру, позиції і виду вікна, що були набудовані користувачем.
Оцінка Проекту. Для оцінки проектних рішень непогано використовувати евристичні перегляди, демонстрації, наскрізний контроль, тести на практичність і часті перегляди з використанням методів залучення користувачів, а також так називану "перевірку за столом", тобто перевірку додатка без запуску на машині. Непогано працюють методи оцінки проекту з залученням користувачів, задач, вимог, конкурентних і еталонних продуктів. Для перевірки реалізації застосовуються методи інспектування розробки з залученням усієї бригади.
Проектні ітерації. Коли вимоги чи не задоволені календарний план дозволяє, варто виконати чергову ітерацію для проектних рішень з наступною візуалізацією й оцінкою.
Ухвалення рішення. На підставі результатів оцінки проекту і ступеня задоволення вимог проектна бригада вибирає напрямок проектирова-ния. У багатьох випадках буває важко вибрати один із двох останніх конкуруючих варіантів проекту. Тільки один варіант проекту підлягає заглибленій розробці і реалізації. У процесі виконання розробки серйозних продуктів необхідно виявляти твердість для задоволення вимог у рамках заданих обмежень.
Корисне правило. Приймаючи рішення, виявляйте рішучість, але план от-ступления і запасний варіант проекту завжди повинні бути під рукою.
Документація. У процесі проектування важливу роль грають два види документації. Неформальна документація являє собою записи в проектних робочих зошитах. Формальна документація призначена для фіксації проектних рішень, що є основою для наступних дій, і являє собою специфікацію концептуального проекту.
Проектні робочі зошити включають запис ідей, альтернативних варіантів, питань і рішень, прийнятих проектною бригадою під час нарад брига-ды. Це буквально сукупність проектних заміток, підсумків бригадних нарад, розглянутих альтернатив, проектних начерків і ідей, а також питань і отве-тов, що стосується проектування. Проектний робочий зошит - це хронологічний запис проектних рішень, що ведуть до вибору напрямку в розвитку проекту. Вона містить проектну інформацію з конкурентному чи успадкований ПО.
Корисне правило. Проектний робочий зошит варто складати як "книгу ідей", що включає кращі проектні "рухи" продукту щодо деяких критеріїв чи оцінок еталонів для порівняння.
Проектна бригада документально фіксує передбачуваний проект у виді специфікації концептуального проекту, що являє собою проектний документ дуже високого рівня- мінімізований за своїм характером і дающий коротким змістом передбачуваного проекту. Специфікація концептуального проекту аналогічна загальному огляду проекту- документу, що містить 10-12 сторінок. Короткий зміст включає підмножина специфікації ПІ, а також наступні проектні питання.
o Мети проекту, принципи проектування, передбачуваних користувачів
задачі користувачів.
o Основні властивості продукту - функції, ПІ, інформацію.
o Огляд ПІ, що включає
o передбачувану користувальницьку модель;
o властивості і поводження робочого столу;
o загальний стиль ПІ і прикладні стилі ПІ;
o графічні і візуальні стилі;
o порядок відображення ПІ й основні екрани;
o експлуатаційну підтримку, навчання і допомогу;
o унікальні елементи керування;
o можливості настроювання.
o Судження з приводу погодженості й інтеграції.
o Висловлення з приводу часу відгуку.
o Оцінка практичності і спільні оцінки щодо вимог.
o Робітники питання і ситуації, що звичайно мають місце на наступної
етапі проектування.
Корисне правило. Документ-специфікація концептуального проекту повинний у явному виді фіксувати ключові моменти проекту. У противному випадку виникає необхідність у реконструкції і виведенні передбачуваних проектним рішень з неповного концептуального прототипу. Як би там ні було, інформація буде загублена чи невірна.
Перегляд і контроль проекту. Специфікація концептуального проекту поширюється серед великого кола зацікавлених осіб, включаючи членів бригади розроблювачів продукту, відповідальних за забезпечення інфраструктури підтримку компонент, відмінних від ПІ, і елементи керування. Специфікація концептуального проекту піддається звичайному контролю з боку керівництва проектом (наприклад, перегляд проектних рішень, відновлення і твердження).
По завершенні концептуальний проект передається під контроль системи керування змінами для роботи з модифікаціями концептуального напрямок проекту, причому немає необхідності довільно змінювати напрямок проектування. Щоб переконатися в тім, що план-графік і ресурсні обмеження не порушуються, проектний і календарний плани проекту переглядаються.
Корисне правило. Саме по собі застосування керування змінами не означає затримку в просто ці перетворення стануть більш організованими.
Відновлення плану. Існує безліч ще невивчених подробиць, що стосуються проекту. Однак багато деталей уже відомі, а у відношенні інших можна висунути припущення. Початкові вимоги, екрани і порядок відображення ПІ дозволяють проектній бригаді висунути розуміння у відношенні необхідного обсягу робіт. Наприклад, у її розпорядженні мається оцінка кількості об'єктів, команд, методів і екранів. Складність компонентів також можна оцінити.
Корисне правило. Звернетеся до існуючого додаткам, що доповнюють, щоб переконатися в тім, що в концептуальному проекті й архітектурі відбиті ключові можливості.
Закриття концептуального проекту. Концептуальний проект закривається при наявності наступних результатів.
" Специфікація і візуалізація концептуального проекту.
" Документовані відгуки користувачів, що беруть участь у проекті, і результати іспитів практичності.
" Порівняльний аналіз порядку відображення екранів успадкованих, пропонованих і конкурентних задач.
" Обновлений проектний план.
" Вироблений загальний підхід, що відрізняється порівняльною строгістю і включає засобу покрокового виміру досягнутих результатів, а також структуру підзвітності в рамках проекту.
Продовження обговорення проекту:
концептуальне проектування
Пішов четвертий тиждень проекту. Прийшов час формулювати концептуальний проект ПІ для того, щоб можна було вибрати напрямок проектування. Концептуальний проект повинний бути відбитий у таких документах, як огляд проекту ПІ й опис стилю. Можливо, незабаром будуть отримані оцінки практичності разом з відгуками користувачів, що беруть участь у проекті, і підтвердженням реализуемости проекту.
Завершення даного етапу заплановано через три тижні. За цей час варто розробити альтернативні проектні рішення, створити для них прототипи й оцінити їх. Критичний аналіз проектних рішень, що буде проводитися разом із групою користувачів, запланований через двох тижнів, а іспиту на практичність - тижнем пізніше. Проектна бригада повинна почати швидко й ефективно працювати. Через тиждень у вас призначена зустріч з лідером проекту, і вашим колегою, що відповідає за проектування інфраструктури. Будуть обговорюватися проектні альтернативи і їхній потенційний вплив на підтримуючу інфраструктуру.
Вам належить разом з вашою бригадою і з користувачами сформулювати стільки альтернативних варіантів для концептуального проекту, скільки удасться за один день. При цьому необхідно проробити і визуализировать щонайменше три альтернативних варіанти концептуального проекту. Подбайте про те, щоб включити в концептуальний проект загальні стилі ПІ, прикладні ПІ, распределе-ние функцій між користувачами і системою, передбачувану користувальницьку модель, рішення по графіці, підтримці експлуатації, навчанню і засобам допомоги користувачам. Зафіксуйте документально проектні компроміси між досліджуваними альтернативами.
Поряд з розробкою передбачуваної користувальницької моделі для довідника по конференціях виконаєте наступні роботи.
" Надайте для оцінки передбачувану користувальницьку модель одного об'єкта компонентного рівня й однієї дії.
" Виявите всі можливі нові елементи керування, на проектування і розробку яких потрібно значний час. Надайте для оцінки передбачувану користувальницьку модель для якого-небудь нового елемента керування.
" При наявності яких-небудь проектних стереотипів надайте для оцінки відповідну передбачувану користувальницьку модель.
" Проведіть критичний аналіз проектних рішень за участю щонайменше трьох потенційних користувачів.
" Проведіть аналіз осуществимости проекту при участі щонайменше одного потенційного розроблювача.
" Відкладете евристичний аналіз проектних альтернатив до розгляду ме-тодов оцінки практичності.
" Висловіть рекомендації з приводу вибору проектної альтернативи, що буде ще пророблятися в процесі наступної проектної діяльності.
" Почніть вести робочий зошит проекту.
" Складіть короткий зміст для документації концептуального проекту і почніть його заповнювати.
Підготуйте презентацію для лідера проекту і вищого керівництва, що со-стоится на наступній тижні. Не забудьте повернутися до проектного плану і питання про фахівців, що володіють необхідними навичками.
Продовжуйте ваше дослідження через Іnternet.
Для роботи над проектним планом і його візуалізацією у вашому розпорядженні близько 20 годин.
Питання?
Посилання
Brooks F. The Mythіcal Man Month, Addіson-Wesley: New York, 1995.
Hіx D., and Hartson H.R. Developіng User Іnterfaces, Wіley and Sons: New York, 1993.
Sіbert.L., and Foley.D. User Computer Іnterface Desіgn, CHІ '91 Tutorіal, Conference on
Human Factors іn Computіng Systems, Apr. 1991.
Torres R.J., and Karat J. Desіgnіng to Іnfluence a User's Model: Some Practіcal Guіdelіnes,
ІBM Technіcal Report TR 71.0004, Sep. 1991.