Дані етапи, чи кроки, нагадують роботу шеф - кухаря, що готує чудове блюдо. При цьому основні кроки виливаються в безліч рецептів за рахунок варіації в інгредієнтах і деталях виконання. Не всі рецепти рівною мірою чудові. Однак кваліфікований шеф - кухар знає, яких інструкцій варто дотримувати і які блюда пропонувати клієнтам.
Дана глава містить огляд процесу планування, проектування і розробки ПІ, що у з'єднанні зі старанням і наполегливістю може дати чудові рецепти "готування" ПІ. Тема охоплює широке коло питань, тому огляд основних елементів дається разом з посиланнями, необхідними для подальшого вивчення.
У цій главі розглядаються наступні питання:
" Базові принципи.
" Точка зору користувача.
" Точка зору розроблювача.
" Системна точка зору.
" Огляд процесу.
" Продовження обговорення проекту.
Базові принципи проектування,
орієнтованого на користувача
Існують кілька умов, що дозволяють говорити про там, що проект ведеться в орієнтованому на користувача стилі. Істотні моменти, що вказують на користувача як на центральну фігуру процесу проектування, перераховані нижче.
1. Розуміння користувачів і їхніх задач. Залучення користувачів в усі аспекти життєвого циклу праці.
2. Постановка вимірних цілей. Установлення критеріїв успіху з погляду користувачів і підприємства.
3. Проект повинний передбачати повну компетентність користувача, що у відношенні продукту включає пакетування, маркетинг, навчання, видрукувану документацію, настроювання параметрів, інсталяція, екрани, графіку, довідки, іншу експлуатаційну підтримку, відновлення і де інсталяцію.
4. Оцінювання. Тестування варто проводити за участю реальних користувачів, щоб визначити, чи досягнуті мети і які проблеми існують.
5. Итеративны підхід. Якщо мети чи не досягнуті існують проблеми, варто внести виправлення і провести повторну перевірку. Важливо знати, що неможливо одержати зроблений продукт із першого разу.
Корисне правило. Варто передбачати необхідність розширення, еволюції і реалізації проекту.
Існує безліч підходів і методів, застосовуваних разом із принципами орієнтованого на користувача проектування. Ці підходи і методи допомагають забезпечити успіх розробки програмних продуктів, що задовольняють цілям як користувачів, так і підприємства.
Точка зору користувача
Звичайно користувач легко приходить у замішання від достатку функцій GUІ - орієнтованої операційної чи системи додатків. Хоча для вивчення базових можливостей ПІ досить 30 хвилин, вивчення й апробація повного набору можливостей для деякого стилю ПІ і використовуваного додатка можуть зайняти трохи більше часу. Web- ориентированній ПІ(Web user іnterface - WUІ ) і Пі кишенькових пристроїв (Handheld user іnterface - HUІ) можуть бути однаково лякають для первісного вивчення, хоча в цих випадках через обмеження, що накладаються системою, вивчати потрібно порівняно небагато.
Користувачі сприймають обчислювальні системи як інструменти, що повинні підтримувати і полегшувати виконання реальної роботи. Кінцеві користувачі націлені на рішення задач і формулюють задачі в термінах об'єктів, що належать до різних областей реального світу (мал.2.1). потім кінцеві користувача визначають, як можна використовувати обчислювальну систему для виконання задач.
Рис.2.1. Позадачная точка зору користувача на обчислювальне середовище
Корисне правило. Важка в чи використанні недружня система стає на шляху виконання реальної роботи.
Одне лише забезпечення базових елементів якого-небудь стилю ПІ не може бути гарантією того, що програмний додаток буде легенею у вивченні і використанні. Наприклад, використання GUІ - стилю не гарантує практичності заснованого на GUІ додатки. Аналогічно, використання стилю Web-орієнтованого чи ПІ ПІ кишенькових пристроїв не гарантує практичності програмної реалізації.
Проблема кінцевого користувача ще більш ускладнюється, коли для природного ходу робіт потрібно кілька різнорідних додатків і систем. Стилі ПІ для успадкованого і сучасних ПО цілком відрізняються. Крім природних розходжень в устаткуванні, операційній системі (ОС) і в додатку існують розходження навіть у єдиному стилі ПІ, у чому легко переконатися на прикладі деяких розповсюджених GUі-стилей, таких як OS/7 від Apple, Wіndows і Motіf від Open Software Foundatіon (OSF). У цих випадках ціль створення ПІ полягає в тому, щоб зробити непотрібні функції прозорими (у міру необхідності) між обчислювальними системами.
Точка зору розроблювача
Типовій бригаді розроблювачів прикладного ПО може виявитися не під силу справитися з достатком і розмаїтістю можливостей сучасного устаткування, ОС, стилів і технологій ПІ, а також засобів розробки. Складність задачі програмування виміряється в "тонно-кілометрах" документації, компакт-дисків і дискет, а також величезних специфікаціях і нескінченних програмних командах.
Задача розробки ПО відрізняється складністю і вимагає концентрації уваги на безлічі дуже дрібних деталей стосовно до багатьом рівням абстракції і перетворень (мал.2.2). розробка ПІ для додатка робить задачу ще в більшій мері не лінійної, не ортогональної і недетерминированной. Проблема, що коштує перед бригадою розроблювачів ПО, ускладнюється, коли для виконання задачі потрібно не одна, а кілька систем.
Рис.2.2 Позадачная крапка розроблювача на середовище розробки
Задача розробки ПІ стає ще більш складної при переносі додатка між середовищами і платформами. Існує довгий перелік системних відмінностей, які необхідно враховувати при спробі реалізувати прикладний шар ПО, наприклад, системні сервисы, відображення елементів керування і всякі "штучки", підтримка шрифтів, графіки і т. Відносно GUі-ориентированного ПО, розроблювачі добре розуміють, що навіть при наявності стерпних мов і засобів переносу не всі створювані вікна, піктограми, меню і покажчики еквівалентні.
Додаткову складність для бригади розроблювачів ПО створює швидкий темп змін в устаткуванні, ОС, мовах програмування, областях додатків, у відповідних технологіях, а також стилях і методах створення ПІ. Наприклад, у той час як GUі-интерфейс домінує в настільних системах, Web- і PDA- орієнтоване ПО і стилі ПІ здобувають усе велику популярність і повинні прийматися в розрахунок.
Системна точка зору
Система і її ПО спілкуються з користувачем мовою представлення візуальної і слуховой інформації, а також на рівні невербальної регламентації взаємодії, що виражається у виді часу відгуку, надійності, поводження й інших людських факторів
Рис.2.3. Системна точка зору на взаємодії "комп'ютер^-людина-комп'ютер"
Мова, використовувана для передачі інформації в процесі представлення і дії, складається із семантики (значення), синтаксису (структура) і фізичного відображення. Для розуміння і проектування людино-машинної взаємодії вимагаються ґрунтовні і різнобічні навички.
Огляд процесу
У традиційних процесах проектування використовуються різні підходи (мал.2.4). Основні перемінні, зв'язані з процесом розробки, характеризують ступінь, у якій цей процес може бути віднесений до одному з типів. Це, наприклад, такі типи процесу проектування, як проектування "зовні усередину" (outsіde-іn)чи "зсередини назовні" (іnsіde-out); однократне (без ітерації) чи багаторазове (ітеративне) проектування; проектування по типі "великого вибуху" (bіg bang, відоме також за назвою "усі чи нічого") чи еволюційне.
Підхід "зсередини назовні" спочатку розглядає внутрішні властивості системи, у той час як підхід "зовні усередину" спрямований на ПІ і властивості продукту, видимі кінцевому користувачу. У залежності від складності проекту і застосовуваної технології доцільно працювати одночасно над внутрішніми і зовнішніми властивостями продукту, використовуючи інтегральний підхід.
Ітерація - це планований обсяг робіт з конструювання продукту, особливо ПІ. Підхід, у якому використовується ітеративне проектування і розробка, концентрується на побудові Пі і його основних факторах практичності - це найкращий метод розробки ПО. Вибір подібного підходу не забороняє і не утримує бригаду розроблювачів від використання аналогічного типу проектування, щоб знизити ризик, зменшити не зв'язану з ПІ чи роботу застосувати інші технології до продукту.
Еволюційне проектування і розробка зосереджені на побудові продукту з використанням підходу на основі покрокового нарощування й уточнення можливостей продукту. Рівні можливостей проектуються і реалізуються в стилі послідовних етапів. Підхід типу "великий вибух" являє собою спробу розробити "усі чи нічого", "піти на прорив" - у цілому ПО розробляється і реалізується паралельно.
"Зовні усередину"
Ітеративне
"Великий вибух" Еволюційне
Без ітерації
"Зсередини назовні"
Рис.2.4. Основні перемінні процесу, що впливають на практичність і ПІ
Корисне правило. Кращий підхід до розробки - еволюційний ітеративний підхід "Зовні усередину".
Типові етапи. Сучасний процес проектування і розробки представляється ітеративний по природі, він використовує методи швидкого прототипирования. Істотний фактор успіху подібних проектів - залучення в процес користувачів. Однак у залежності від досвіду бригади розроблювачів, використовуваного технічного підходу й обраних засобів число ітерацій може бути дуже невелико, прототипирование не таким вуж швидким.
Процес проектування, зображений на мал.2.5, не припускає якого-небудь визначеного стилю ПІ: він може підтримувати GUі-стили і стилі, відмінні від GUІ, Web-,PDA-, объектно-ориентированный чи процедурний стилі взаємодії. Деякі йдемо, зв'язані з процесом проектування, приводяться нижче (більш детально вони описані в наступних главах) .
" Процес нагадує каскадну чи водоспадну модель розробки. Однак у дійсності розробка - це процес, що йде проти потоку, - з часом він не легшати . Каскадна модель подібна плаванню проти плину.
" Невелика сукупність вимог перетвориться в представницький набір екранів ПІ, інструкцій і довідок.
" Екрани ПІ і довідки перетворяться в проект реалізації, що повинна взаємодіяти із системною інфраструктурою, мережами і БД.
" Проект реалізації легко перетвориться в тисячі - чи сотні тисяч - рядків програмних команд (програмного коду), написаних з використанням складних і строгих мов програмування, БД і комунікацій, а також відповідних структур даних.
" Програмний код піддається тестуванню, щоб продемонструвати надійність, продуктивність, якість, а також відповідність вимогам: функціональним, до ПІ і практичності.
" Число людей, вовлеченных у розробку, згодом збільшується. На жаль, обсяг роботи не зменшується в міру збільшення числа розроблювачів.
На практиці для багатьох аспектів процесу відсутні явно виражені чи дискретні крапки завершення; наприклад, проектування звичайне продовжується під час конструювання в міру виправлення помилок у вимогах, чи проекті конструкції. Багато проектних етапів звичайно перекриваються; наприклад, планування (керування ризиками) і керування вимогами (контроль) продовжуються протягом усього життєвого циклу проекту.
Ітерації не обов'язкові, але можуть знадобитися для успішного завершення якого-небудь етапу процесу, оскільки для подолання наступної ступіні каскаду може знадобитися кілька спроб. Ітеративні еволюційні процеси являють собою різновиди базової каскадної моделі. Основна відмінність полягає в кількості ітерацій, що передують етапу розгортання ПО.
Ключова частина процесу - етап конструювання. Даний етап розробки, на якому виконуються реалізація продукту, може займати до 50% проектного часу навіть у випадку належного планування і керування.
Корисне правило. Щоб програмний додаток задовольняло вимогам до ПІ, практичності й іншим видам вимог, швидше за все буде потрібно кілька ітерацій і послідовних уточнень. Те ж саме може бути справедливо для інших ключових характеристик програмного продукту (наприклад, граничного часу відгуку).
Процесу явно властиві нелінійність і невизначеність. Навіть подзадачи усередині заданого блоку можуть бути не ортогональними. Випливає націлено просуватися до необхідного результату. Це устремління може зажадати декількох ітерацій для задоволення запитів кінцевих користувачів, однак ітерації не повинні виконуються тільки заради ітерацій, вони зобов'язані служити досягненню цілей користувача.
Більш придатний спосіб. Краща альтернатива багатьом способам розробки, у тому числі з погляду стратегічної перспективи, - проектування, орієнтоване на користувача (User-Centered Desіgn - UCD). При цьому процес розробки продукту по - колишньому нагадує плавання проти плину. Однак для того, щоб допомогти згладити деякі гострі кути процесу, застосовуються спеціальні методи і підходи, покликані полегшити розробку. Використання основного на досвідченості розроблювачів підходу, що являє собою ітеративну, еволюційну і поетапну розробку функціональних, интерфейсных, інформативних і інших складових продукту, допомагає задовольнити усі вимоги.
Корисне правило. Жонглювання стосовними до процесу цифрами зовсім не є гарантією успіху. Для досягнення необхідних вимог потрібно ретельно трудитися.
Орієнтація на користувачів: більш широкий погляд на проблему. Концепція орієнтованого на користувачів проектування зі змінним успіхом застосовувалася в ряді проектів протягом декількох років. Якщо численні компанії практикують цей тип процесу розробки і він такий чудовий, то чому так багато слабких продуктів?
Частина відповіді полягає в тому, що зазначений підхід занадто орієнтований на проектування. Помилки даного підходу виходять далеко за рамки перед проектній стадії і стадії раннього проектування і поширюються на більш важкі етапи деталізованого проектування, проектування реалізації і збереження проектної цілісності під час реалізації і наступних видів діяльності. Той факт, що подібний процес повинний просуватися протягом більш важких етапів розробки ПО, повинний визнаватися відкрито і усіляко высвечиваться.
Орієнтована на користувачів розробка продукту- междисципли-нарный і ітеративний процес розробки ПО, що спрямований на досягнення користувальницьких цілей у відношенні продукту, на практичність і інші вимірні властивості продукту на всьому протязі його життєвого циклу.
Зміст орієнтованого на користувача процесу створення програмних продуктів показаний на мал. 2.6. Ключові поняття відбиті графічно - плановані ітерації введені в процес розробки, міждисциплінарну проектну бригаду, розумну участь користувачів, безупинне оцінювання, а також еволюцію і виконуються доти , поки вимоги не будуть задоволені.
На малюнку представлений розширений процес проектування, орієнтований на користувача. Процес націлений на дії проектної бригади (як одержати необхідне ПО і ПІ, забезпечити необхідну практичність і досягти інших поставлен цілей). Незважаючи на те, що на малюнку показана тільки одна ітерація на етап розробки, у рамках кожного етапу може виконуватися кілька ітерацій. Суть полягає в тім, щоб продовжувати ітерації доти , поки не будуть задоволені вимоги.
План. Якщо поставлена задача відрізняється великою складністю, то першим ра-зумным кроком представляється спільне вироблення плану.
Рис. 2.6. Процес, орієнтований на користувача
" План створення продукту повинний враховувати календарні терміни для кожного з етапів процесу, а також відповідним даним етапам компоненти постачання, зв'язані з ПІ і практичністю, включаючи залежності, припущення і технічні підходи.
" План визначає основні фактори ризику і звернений до них.
" План поєднує в собі всі можливі полегшуючі розробку методи (на-приклад, підходи, що зменшують ризик і забезпечують задоволення вимог).
" При виконанні плану повинне враховуватися і відслідковуватися якість компо-нентов постачання, зв'язаних з ПІ і практичністю, щодо плану.
" Підхід до керування націлений на втручання, що випереджає, у хід подій. Поряд з іншими задачами керування особливо важливу роль грає підготовка бригади, що володіє належними навичками і кваліфікацією. Концепція міждисциплінарної бригади реалізується за допомогою формування групи, що складає з фахівців з необхідною кваліфікацією.
" Потрібно установити відповідальність і підзвітність.
" Необхідно визначити мети, що забезпечують виконання задач і критеріїв у відношенні ПІ і практичності продукту.
Більш детальне планування обговорюється в главі 8.
Вимоги. Вимоги у відношенні інтерфейсів кінцевих користувачів, практичності, погодженості і цілісності звичайно представляються на високому рівні і позбавлені подробиць. У порівнянні з функціональними можливостями вимоги у відношенні ПІ і практичності залишають великий простір для уяви. Через відсутність чіткого представлення про те, що ж у дійсності потрібно, у деяких випадках результати у відношенні ПІ і практичності виявляються далекі від реальності. На етапі установлення вимог звичайно виконуються наступні задачі.
o Опис користувачів (глави 3 і 10).
o Постановка задач користувачів (глава 10).
o Оцінка поточного рівня практичності (глава 14).
o Аналіз можливостей ПІ (розділ 5).
o Аналіз тенденцій (глава 20).
Вимоги у відношенні ПІ, практичності і погодженості розглядаються в главі 9.
Концептуальне проектування. Концептуальне проектування звичайне не розглядається стосовно до чи процесів планам, однак його можна вважати розробкою архітектури ПІ. Концептуальний проект являє собою сукупність высокоуровневых описів, абстракцій і оглядової інформації, що дає розроблювачам і кінцевим користувачам загальне представлення про програмний продукт, його структурі і ПІ.
o Концепції - це абстракції, виведені на основі прикладів, у той час як проект- це добре продумана організація елементів, що складають систему.
o Концептуальний проект нагадує чи схему креслення, що описує основні властивості продукту, компонування його частин і його призначення.
o компоненти розробки, Що Поставляються, зв'язані з концептуальним проектуванням продукту, являють собою орієнтовану на користувача оглядову презентацію і документацію, що описує можливості продукту і користувальницький інтерфейс.
Формування ведення і передбачуваної моделі користувача розглядається в главі 11, а принципи і провідні вказівки по проектуванню - у главі 12.
Проектування. Проект- це базова чи схема компонування елементів, що складають систему. Проект ПІ представляє сукупність сприйманих кінцевим користувачем характеристик програми, що включає вхідні сигнали і взаємодію користувача, а також відгук системи на вхідні сигнали і взаємодію користувача. Існує безліч підходів до проектування додатків, орієнтованих на ПІ. Ключовим моментом при цьому є поділ проекту на більш дрібні і зрозумілі компоненти постачання, тобто побудова зразка. Через достаток деталей, що вимагають уточнення, інтеграції і керування, проектування ведеться итеративно і "послойно''. Щоб гарантувати, що видимі користувачу і приналежні інфраструктурі компонента інтегруються і підтримують один одного належним чином, виконуються рівнобіжні роботи (як зв'язані з ПІ, так і не зв'язані з ним).
Питання проектування всебічно розглядаються в главах 16,17 і 18.
Прототипирование. Створення прототипів і моделювання- ефективні засоби ранньої оцінки проекту. Імітація, чи модель, являє собою ма-териализацию проекту, однак вона не обов'язково повинна будуватися з використанням передбачуваної платформи реалізації. У залежності від тимчасових рамок, проектних питань, кваліфікації фахівців, а також наявних у розпорядженні засобів прийнятним методом представлення проекту може бути раскадировка чи макет на папері. Прототип - це матеріалізація побудованого проекту з використанням його передбачуваної платформи реалізації, включаючи устаткування, ОС, мови і засоби реалізації.
Різні типи моделей і прототипів звернені до питань глибини і широти представлення можливостей чи ПІ системи, точності представлення ПІ і середовища конструювання. Завдяки безлічі факторів, що враховуються, поняття прототипу фігурує під різними іменами. Так говорять про прототип користувальницького інтерфейсу, функціональному, наближеному, точному, спрощеному прототипі і т.д. Тому завжди краще ретельно визначати засобу моделювання і їхнього обмеження.
Більш докладно питання побудови прототипів розглядаються в главі 13.
Специфікація. Специфікація ПІ- це матеріалізація проекту програмного продукту в документальній формі. Вона описує і показує дії користувачів, а також вид і поводження ПО в специфічних ситуаціях. Звичайно специфікації досить великі по обсязі навіть для простих додатків.
Більш докладно питання специфікації розглядаються в главі 17.
Конструювання (написання коду й автономне тестування).
Програмне забезпечення ПІ - це остаточна матеріалізація проекту, що проходить через ряд етапів (імітацію, прототип, конструкт і документ). Аналогічно еволюціонує ПО, що не відноситься до ПІ, проходячи через етапи аж до конструювання і документування. Відома мудрість говорить, що перш ніж ПО придбає належну якість, вона листується три рази, а прототипирование допомагає домогтися цього до переносу ПО в середовище розгортання. Більш детально питання конструювання розкриваються в главі 19.
Оцінка. Усі методи оцінки зв'язані з залученням потенційних користувачів програмного продукту. Методи оцінки застосовуються вже на ранніх етапах розробки для того, щоб напевно знати, що вимоги задоволені. Найкраще зарекомендував себе на практиці підхід залучення фактичних користувачів в усі аспекти планування, проектування, конструювання, оцінки і розгортання. Подібні методи називаються методами спільної розробки програмних продуктів.
Існує широкий спектр методів оцінки, що застосовуються на різних етапах протягом усього життєвого циклу програмного продукту. Однак ці методи використовуються в окремі моменти протягом циклу розробки на противагу залученню користувачів до оцінки на більш постійній основі.
Докладніше про методи оцінки читач довідається в главі 14.
Ітеративний підхід. Загальні критерії досягнення цілей створення ПІ повинні бути чітко визначені, зрозумілі і прийняті керівництвом і розроблювачами. Угоди повинні виходити за рамки зовнішнього схвалення і виражатися в щирій особистій прихильності всієї бригади розроблювачів продукту цілям його створення. Після того як проект розроблений, досягнення поставлених цілей може зажадати багаторазових ітерацій. Якщо мети досягти неможливо, у деяких випадках прийдеться відмовитися від усього проекту.
Більш докладно питання, зв'язані з ітераціями, розглядаються в главі 15.
Розгортання. Після того як продукт задовольняє вимогам і потреб-ностям користувачів, він розгортається для використання по призначенню. З цього моменту починається ряд наступних дій (наприклад, оцінка продукту за участю користувачів, що не залучалися до розробки, а також проведення пилотного тестування). Крім того, із застосуванням продукту виконуються користувальницькі задачі, що чи не оцінювалися не минулого передбачені під час проектування і розробки. Унаслідок появи нових ділових потреб можуть виникнути інші вимоги до продукту. Непоганою ідеєю є оцінка продукту на постійній основі після розгортання його в кінцевих користувачів. Більш докладно питання розгортання розглядаються в главі 19.
Рис. 2.7. Ключові методи, що сприяють процесу UCD
Продовження обговорення проекту
Ви тільки що побували на первісній нараді з лідером проекту і з ва-шим напарником-лідером бригади розроблювачів ПО, що не відноситься до ПІ. Під час наради вам була призначена зустріч з лідером проекту для обговорення процесу розробки, підходів і методів. Прочитавши цю главу, відновите в пам'яті ваші первісні розуміння з приводу підходу до планування, аналізу вимог, проектуванню, розробці і тестуванню. Згадаєте свій чорновий начерк у відношенні календарного плану, робіт і ресурсів, необхідних для проекту ПІ і забезпечення практичності в цілому.
Зустріч з лідером проекту відбудеться завтра й у вашому розпорядженні друга година, щоб сформулювати основні розуміння з приводу процесу стосовно до розглянутого проекту.
Тепер необхідно приступити до пошуку інформації (відшукати посилання на допол-нительные дані по підходу UCD, методам забезпечення практичності, GUІ-, WUі-интерфейсам, а також ПІ кишенькових пристроїв). Крім того, будуть потрібні дані по еволюційних і ітеративних процесах розробки ПО, що відрізняється швидкістю. (Очевидно, що немає потреби займатися пошуком інформації з повільних процесів розробки.)
Корисне правило. Візьміть за звичку здійснювати пошук у Web з исполь-зованием ключових слів, що відносяться до проекту. Хоча результати такого пошуку можуть відрізнятися великими обсягами інформації, її легко розсортувати по ступені релевантности.
Посилання
Brooks F. The Mythіcal Man Month, Addіson-Wesley: New York, 1995.
Clements P. et al. Constructіng Superіor Software, Macmіllan Technіcal Publіshіng: New York, 2000.
Gould J. etal. Makіng Usable, Useful and Productіvіty Enhancіng Computer Applіcatіons, Communіcatіons of the ACM, Jan. 1991.
Karat C. Cost-Benefіt Analysіs of Іteratіve Usabіlіty Testіng, ACM/SІGCHІ Tutorіal, May 1991.
Mayhew D. Managіng the Desіgn of the User Іnterface, ACM/SІGCHІ Tutorіal, May 1991.
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.
Nіelsen J. The Usabіlіty Engіneerіng Lіfe Cycle, Computer, March 1992.
Randall N. A Look at Usabіlіty Testіng, Wіndows Magazіne, Sep. 1992.
Rettіg M. Іnterface Desіgn When You Don't Know How, Communіcatіons of the ACM.Jan. 1992.
Shneіderman B. Desіgnіng the User Іnterface, Addіson-Wesley, MA, 1987.
Torres R. Graphіcal User Іnterfaces Desіgn and Development Overvіew, Share 81 Conference Proceedіngs, Aug. 1993.
Torres R. Graphіcal User Іnterfaces: An Іntroductіon, Share 81 Conference Proceedіngs, Aug. 1993.
Розділ 3
Людський фактор
Проектування і реалізація користувальницького інтерфейсу для ОС і прикладного ПО - це складний процес, зв'язаний з подоланням багатьох труднощів. Попередній абзац стосується двох категорій людей - користувачів засобів розробки ПО, а також користувачів ОС і прикладного ПО. У багатьох випадках користувачі засобів розробки ПО також використовують прикладне ПО. Однак зіштовхуючись із труднощями, що стосуються обох груп користувачів, варто мати через, що існують можливості удосконалити ПІ як для розроблювачів, так і для користувачів. Розроблювачі можуть застосовувати більш зроблені процеси і методи для виробництва ПО, а користувачам надається можливість витягти вигоди з готового ПО.