Лекція №9. Принципи, інструкції та керівництва за стилем. Макети, моделі та прототипи інтерфейсів користувача



Скачати 96.21 Kb.
Дата конвертації30.12.2016
Розмір96.21 Kb.
Лекція №9.

Принципи, інструкції та керівництва за стилем.

Макети, моделі та прототипи інтерфейсів користувача.


  1. Варті уваги принципи, стандарти, інструкції та керівництва за стилем.

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

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

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



Мета керівництва за стилем полягає якраз в тому, щоб допомогти розробникам бути послідовними.

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

Потрібно обрати не більше 10 важливих принципів, а потім виробляти інструкції, які містять вимірювані оцінки для цих принципів, щоб вони стали діючими та практичними.

Інструкція (або керівна вказівка) - це правило проектування, корисне при реалізації та легко піддається вимірюванню в термінах відповідності. Виконання інструкцій легко піддається безпосередньому вимірюванню, вони об'єктивні і конкретні. В багатьох керівництвах за стилем інструкції приводяться як правила, а останні вказівки як рекомендації.

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

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

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



Наявність принципів, стандартів, інструкцій та керівництв за стилем необхідна, але недостатня умова поставки високоякісного ПЗ КІ. В загальному випадку, кращий підхід полягає в тому, щоб підтвердити обгрунтованість використання яких-небудь керівництв застосовно до конкретного продукту, спираючись на думку проектного колективу та кінцевих користувачів.

Традиційні керівництва за стилем КІ носять описовий характер, тобто дається загальна вказівка без конкретизації підсказаної директиви. Інструкції описового типу рекомендують розробнику КІ використовувати вікна з різними цілями. Однак керівнпицтво описового типу слабо конкретизує інструкції або директиви по відношенню до того, як саме відображати об'єкт або дію всередині вікна або бажану поведінку при взаємодії. Розробник повинен виділити конкретні деталі, повністю прочитавши керівництво за стилем, сформувати бажаний стиль, а потім визначити конкретні деталі додатків, які виходять за рамки базисних властивостей КІ.


Модель сторінки Схема списків/таблиць

на сторінці

Використання Використання

стандартних ЕУ таблиці, що розширяється

Стандартний ЕУ Вигляд та сприйняття

таблиці, що розширяється


Рис.1. Компоненти та рівні керівництва за стилем


  1. Приписуючі керівництва за стилем.

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

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

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


  1. Розробка приписуючого керівництва за стилем.

Розробка керівництва за стилем КІ для додатку вимагає істотних витрат незалежно від використовуваного підходу. Як правило, до розробки залучається декілька людей на тривалий період часу, протягом якого звичайно ведуться переговори та дебати в спробах досягти згоди у відношенні питань стилю.

Основні особливості, властиві розробці приписуючого керівництва за стилем:



  • цілеспрямованість - приписуюче керівництво за стилем спрямоване на досягнення ясно сформульованих конкретних результатів;

  • підтримка керівництва ;

  • ранній початок та неперервне продовження;

  • ефективність;

  • орієнтація на користувачів;

  • орієнтація на розробників;

  • спрощення реалізації;

  • реалізованість;

  • тестопридатність;

  • конкретність;

  • доцільність;

  • доречність;

  • гнучкість;

  • повнота;

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

  • практичність;

  • наочність;

  • відображення на продукт;

  • відповідальність/підзвітність.




  1. Корисні методи розробки приписуючого керівництва за стилем.

Існують деякі методи, які дозволяють знизити ризик в процесі розробки приписуючого керівництва за стилем:

  • орієнтоване на користувачів проектування;

  • "портрет" сімейства продуктів "До" - екранні зображення продуку, які показують, в чому полягає проблема;

  • неузгодженості - складання переліку відмінностей між продуктами;

  • "портрет" сімейства продуктів "Після" - екранні зображення, які усувають проблеми;

  • що це коштує - складання переліку змін, які призводять до бажаного результату;

  • покази і розповді;

  • приписання;

  • періодичні оцінки/звіти.




  1. Макети, моделі і прототипи.

В багатьох галузях при розробці продуктів поширена практика якомога більш раннього надання їм начоного вигляду - те, що в індустрії програмних засобів називається візуалізацією. Подібна практика відіграє велику роль також при проектуванні та розробці КІ. Корситувачі, ділові спонсориЖ, проектний колектив та інші учасники команди по розробці продукту можуть на ранній стадії його створення поглянути на те, що ж реально виходить на шляху до поставки. Цей перший погляд дає можливість зацікавленим сторонам внести проміжні корективи. Для проектного колективу це ще один метод розробки та можливість перевірити правильність прийнятих рішень, перш ніж вносити зміни буде надто пізно або надто дорого.

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



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

Модель (імітаційна модель, імітація) представляє собою матеріалізацію проекту, вона будується з використанням засобів реалізації, відмінних від тих, які передбачається використовувати для розробки продукту.

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



  1. Цілі візуалізації проекту.

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

Для оцінки спрощених та обмежених представлень складних проектних рішень використовуються еврістичні методи і методи сумісної розробки. Від членів проектного колективу та користувачів вимагається подолати концептуальні обмеження, накладені існуючими на папері макетами, розкадровкою, моделями, а також очікувані проектні проблеми та обмеження, пов'язані з використанням цих засобів. Бажано якомога швидше створити спрощений прототип КІ, використовуючи передбачувані засоби розробки і компоненти. Це допомагає прояснити проблеми користувацької взаємодії, пов'язані з логікою, кроками роботи і обмеженнями інструментарію.



Методи прискорення розробки:

  • складання прискореного план-графіка;

  • швидкий перехід до прототипування;

  • внесення виправлень безпосередньо по ходу проекту;

  • припустимість жорсткого програмування;

  • концентрація на головних задачах і методах, нехтування неістотними деталями.

При використанні методів візуалізації слід спрямувати основні зусилля на досягнення наступних цілей:

  • візуалізація основних складових, які визначають рівень задоволеності користувачів;

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

  • оцінка значущості розглядуваних питань з точки зору проекту.




  1. Методи матеріалізації проектних рішень.

Основна проблема проектного колективу полягає в необхідності прийняти рішення про те, які аспекти проекту підлягають матеріалізації з метою їх завчасної оцінки сумісно з користувачами і які методи для цього застосувати. Що стосується великих продуктів, а також аспектів можливостей і практичності, пов'язаних з функціями і КІ, вони вимагають розгляду багатьох питань.

Будь-яка матеріалізація проектних рішень вимагає розгляду наступних технічних основ:

  • часто використовувані, нестійкі, проблематичні задачі і сценарії, які підлягають представленню;

  • часто використовувані і нестійкі функції, методи і дані;

  • загальне використання платформенного стилю КІ;

  • специфіка прикладного стилю КІ, екранів і логіки;

  • проблематичні елементи управління КІ;

  • потрібний рівень користувацької взаємодії;

  • необхідний обсяг точності відтворення середовища;

  • глибина фактичної матеріалізації в порівнянні з потребами візуалізації;

  • швидкість представлення;

  • цілі по відношенню до повторного використання застосовно до кожного виду візуалізації.

Існують аспекти ПЗ КІ, які не підлягають матеріалізації до їх реалізації:

  • рідко використовувані гілки функційних можливостей;

  • рідко використовувані властивості КІ;

  • інформація про продукт;

  • повідомлення;

  • обробка помилок;

  • аспекти ефективності.

Методи візуалізації:

  • олівець і папір;

  • розкадровка;

  • імітація;

  • спрощений прототип КІ;

  • прототип КІ;

  • функційно-інтерфейсний прототип;

  • реалізація.



  1. Відкидання прототипів.

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

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


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка