Практичний посібник із проектування і розробки користувальницького інтерфейсу.
ГЛАВА І
УВЕДЕННЯ
На загальному рівні проектування користувальницького интерфейма (ПІ) здається простою справою - якщо мова йде про конкретний ПІ, кожен учасник проекту готовий висловити свою думку з приводу того, що в ньому правильно, а що що не правильно. Спроектувати який - або фрагмент Пі не складає особливої праці, однак малий хто може справитися з розробкою цілком, з урахуванням всіх аспектів аж до етапу розгортання ПІ. Деякі розроблювачі здатні створити чи прототип реалізувати ПІ, а розгорнути його в користувачів не виходячи за рамки встановлених термінів і інших обмежень - справа рук дійсних профессиналов.
Корисне правило. Розробка ПІ, клієнт - серсерного додатка, Web -додатки і бази даних, - звичайна праця розроблювача. Щоб переконатися в цьому досить глянути на "море" програмних продуктів у сучасному світі. Інша справа, якщо мова йде про розробку, що задовольняє складним обмеженням у відношенні конкурентноздатності, ПІ, практичності, погодженості, вартості, ресурсам, навичкам і термінам - отут вуж без спеціального досвіду, мабуть, не обійтися.
Розхожі думки у відношенні ПІ не підтверджуються при наступних умовах.
" Проект ПО повинний задовольняти строгим критеріям у відношенні ПІ, практичності, погодженості, а також інтеграції.
" Реалізація повинна здійснюватися в рамках ресурсних і тимчасових обмежень, покладених на бригаду розроблювачів, що має визначену кваліфікацію.
" Необхідно установити строгу звітність за результатами.
Процес проектування Пі - це складний, нелінійний, недетерминированный і не ортогональний процес. Складність - звичайна властивість ПО, але в ще більшому ступені це відноситься до ПІ - з - за численних факторів і невизначеностей, що впливають на його розробку. Проектування ПІ - нелінійний процес, оскільки існування фіксованого, упорядкованого і прямолінійного шляхи від початку і до кінця не обов'язково. Процес проектування відрізняється невизначеністю, тому що не існує рівняння, по якому можна було б одержати однаковий результат при заданих однакових вихідних умовах, більш того, практично неможливо одержати ідентичний результат навіть під примусом. ПІ неортогонален у тім змісті, що будь-який аспект проектного рішення може впливати на інші аспекти, причому результат цього впливу не завжди виявляється приємним сюрпризом.
Статистична незалежність подібна роботі над головоломкою - вона приносить мало радості при створенні ПІ.
Корисне правило. Проектування і розробка ПІ - дивно складні речі, їх часто недооцінюють, коли мова йде про планування, вимоги і розгортання.
Щоб спростити розгляд настільки складного питання й у той же час не упустити з ивду питання ефективності, для тих, хто бере участь у плануванні, проектуванні, реалізації, тестуванні і розгортанні ПО пропонується підхід на основі використання, так сказати, "передового досвіду" індустрії програмних засобів. При цьому акцент робиться на тім, щоб установити, що саме і як саме варто робити для досягнення успіху.
Ця глава включає наступні розділи.
" Проект - вірогідність і актуальність інформації.
" Труднощі.
" Головні причини провалу (чи успіху) проекту.
" Підхід до процесу розробки ПО.
" Підхід до вироблення проектних рішень.
" Використання переданого досвіду.
Схема викладу заснована на представленні глав як лінійної послідовності проектних завдань. Однак кожна глава до деякої міри незалежна, так сто при необхідності до глав можна звертатися в довільному порядку.
Проект, що введений у цій главі, використовується протягом усього викладу. Він складає основу прикладів, задуманих так, що читачі можуть ознайомитися з великим колом реальних ситуацій і завдань, зв'язаних із проектуванням і реалізацією ПІ.
Думка автора, читачів, фахівців в області ПІ і практичності ПО, а також інших фахівців має важливе значення для успіху програмного продукту, однак в остаточному підсумку оцінка прийнятності ПО - це прерогатива користувачів і/чи результат тестування практичності. Можливою вимогою до проекту може задовольняти безліч альтернативних рішень, однак що ж є критерієм вибору найкращого проектного рішення?
Проект - вірогідність і актуальність інформації
Підрозділу дослідження ринку удалося переконати вище керівництво в життєздатності потенційно нового продукту. У результаті незначних асигнувань і дріб'язкових причіпок керівництво відразу пішло на створення невеликої бригади для початкового аналізу концепції проекту і можливих витрат на розробку.
Додаток. Суть проекту складається в постановці додатка, що підтримує планування і відвідування консультацій, семінарів, презентацій і позаурочних засідань на основних конференціях на зразок Guіde, Share і Computer Human Іnteractіon (CHІ). Ймовірні користувачі програмного засобу - відвідувачі названих заходів, так само як і обслуговуючий персонал, що визначає і супроводжує заходу для системи. ( Guіde - велика група конференцій, що містять у назві слово Guіde, которіе посвящені проблемам використання ПК, WWW і т.д.; Share - некомарческая організація користувачів продуктів компанії ІBM, проводить постійні конференції і семінари; CHІ - щорічна конференція по людино-машинній взаємодії, остання конференція пройшла 20 - 25 квітня 2002 року в Миннеаполисе, США - Прим. ред.)
Платформи. Додатка планування конференцій призначено для роботи на трьох апаратних і операційних платформах.
" Мобільні комп'ютери, що працюють під керуванням Mіcrosoft Wіndows.
" Мережні комп'ютери, що працюють під керуванням Wіndows/ NT чи UNІ.
" Узаимосвязнніе персональніе цифровіе ассистенті (Personal Dіgіtal Assіstant - PDA)
Інструментарій. Мови реалізації не відомі. На даному підприємстві для розробки проекту відсутні які-небудь стандарти на використання чи мов засобів розробки. Однак найбільш перспективними для створення усього чи частини ПО виглядають такі мови, як java, C++? Vіsual Basіc (VB) b HTML. В организации-разрабочтике використовуються і деякі інші мови й інструментальні засоби, хоча ніякі інші засоби розробки не розглядалися і не минулого рекомендовані до застосування в проекті.
Бригади. Бригада запуску проекту складається з досвідченого й енергійного менеджменту по розробці ПО і двох розроблювачів ПО. Один з розроблювачів має великий досвід у питаннях клієнт серверної інфраструктури ПО, а другий - у програмних додатках на основі GUІ - інтерфейсу. Обоє розроблювача досвідчені фахівці в області керівництва бригадами програмістів.
Учасники бригади - новачки в організації-розроблювачі і до цього не працювали разом. Нікому з учасників бригади не приходилося розробляти ПО для PDA объектно-ориентированное ПО, працювати з java, web-технологіями і Unіx.
Співробітники, що проводили первісне дослідження ринку, одержали призначення в інші підрозділи для виконання інших завдань, однак керівництво вирішило, що необхідно завершити пункти роботи, що залишилися. Вище керівництво бригади запуску проекту погодилося зробити маркетингову й іншу підтримку, якщо проект виявиться багатообіцяючим. Нікого з інших співробітників залучати до проекту не рекомендується за винятком мінімальних консультацій.
Календарний план. Підрозділ дослідження ринку прогнозує, що якщо продукт буде поставлений на ринок не пізніше, ніж шість місяців, обсяг його продажів у перший рік складе 15 мільйонів одиниць за відомою ціною. Допускається наявність конкуренції: при цьому очікується, що якщо термін виведення продукту на ринок складається більш 18 місяців, прогнозований обсяг продажів може виявитися під погрозою. З урахуванням розширення додатка за рахунок можливостей планування освітніх, спортивних і інших заходів потенціал збуту продукту може вирости до 50 мільйонів одиниць.
Вище керівництво зажадало проведення щотижневих 15 - хвилинних нарад з лідером проектної бригади, також було намічено виконати попередню оцінку, спланувати проект і можливі потреби в ресурсах у плині 30 днів з дійсного моменту. Лідер проекту погодився з вимогами вищого керівництва. Питання?
Труднощі.
Проект не занадто відрізняється від опису початку розробки архівіруваної прикладної програми. Для розроблювачів ПО, що працюють над внутрішніми додатками, сценарій не занадто далекий від показаного вище. Наприклад, що якщо проект по розробці має на меті спочатку забезпечити рішення для планування внутрішнього навчання з наступним розширенням рішення, оформленням його у виді пакета програм і виведенням на ринок?
Сучасне середовище розробки ПО укладає в собі безліч проблем: необхідність зниження витрат, скорочення термінів, вироблення більш передбачуваних планів, надання більш якісних рішень, забезпечення нескладного в освоєнні і використанні ПО, постійне оволодіння новими технологіями і середовищами, досягнення кращих результатів у порівнянні з конкурентами, а також інші аспекти.
Дуже велика тема. Задоволеність користувача програмним чи продуктом його практичністю може бути значною мірою віднесена на рахунок ПІ. Це велика і слабко пророблена тема. Тут потрібно більш широкий погляд на практичність, на користувальницький інтерфейс і способи його проектування і реалізації.
Перш ніж звернутися до теми легкості використання ПО, потрібно більш широке і загальне розуміння факторів, що обумовлюють ступінь задоволеності користувача. Дослідження показали, що задоволеність користувача - це функція невеликої кількості факторів. Нижче приводитися рівняння, що представляє ступінь задоволеності користувача як функцію від цих факторів.
Задоволеність користувача =
Функція від МОЖЛИВОСТЕЙ КОРИСТУВАЛЬНИЦЬКОГО ІНТЕРФЕЙСУ, ЧАСУ ВІДГУКУ, НАДІЙНОСТІ, пристосованості до інсталяції, інформаційної підтримки, пристосованості до супроводу й інших
Фактори, виділені прописними буквами, грають у рівнянні найбільш важливу роль. Звичайно, легко відшукати приклади, коли продукт не придатний до вживання через непрактичність.
" Упущені визначальні функціональні можливості.
" Не враховані критичні властивості ПІ, його зовнішній вигляд і поводження залишають бажати кращого, він пред'являє занадто високі вимоги до поінформованості і взаємодії з боку користувача.
" Час відгуку і продуктивність недостатні.
" Система чи не перешкоджає навіть служить причиною втрати результатів роботи і даних.
Головне, на що звертають увагу користувачі - швидке, легке і надійне виконання роботи за допомогою засобів, що автоматизують, доповнюють і полегшують виконання задачі. Простота інсталяції/деінсталяції має важливе значення, оскільки вона задає тон на початку і наприкінці досвіду спілкування користувача з програмою. Легкість відновлення ПО має таке ж важливе значення, як і інші інтерактивні властивості продукту. Інформаційна підтримка (навчання, наставляння, довідки і підтримка експлуатації) важлива під час початкового чи наступного освоєння продукту, але не має безпосереднього відношення до розв'язуваної задачі, хіба тільки використовується для рідких чи складних задач.
Існує безліч інших факторів, таких як погодженість, інтеграція і вартість, що впливають на рівень задоволеності користувача в залежності від і значення, середовища, розв'язуваної задачі і ситуації.
Корисне правило. У ході планування розробки продукту, аналізу вимог, проектування, реалізації, тестування і розгортання варто враховувати усі фактори, що входять у рівняння задоволеності користувача і їхню відносну важливість.
Книга посвящениа питанням практичності і, зокрема , користувальницькому интерфейсую у відношенні продуктивності і надійності висловлюються тільки загальні рекомендації і розуміння; значення цих факторів не слід применшувати.
Ризикована справа. Розробка ПО завжди являє собою ризиковане підприємство - проекти провалюються через скасування, значних зрушень графіка робіт, неприйняття продукту з боку чи користувачів істотної перевитрати коштів. Засобу інформації буяють такими прикладами, коли ПО виявлялося не відповідають вимогам по многим складовим, з яких складається рівень користувальницької задоволеності.
Одна з основних цілей книги складається в звертанні до областей ризику, зв'язаним із практичністю і ПІ. Щоб відповісти на запитання: "Яким образом справи можуть прийняти небажаний оборот?" у книзі розглядаються деякі прагматичні підходи і спеціальні рекомендації, які можна безпосередньо застосувати до робіт проектуванню і забезпеченню практичності.
Своєчасність. Нехай читача не лякає те, що розробка ПО - справу дуже ризиковане, адже про користувачів і технології ПІ, а також про те, як виробити належні плани розробки, здійснити проекти, створити ПО й інструментальні засоби, сформувати оцінки і виконати ітерації відомо чимало. Зокрема , кращий спосіб домогтися бажаних результатів - ефективний і швидкий ітеративний процес, що протікає в рамках заданих обмежень.
Приведені в книзі рекомендації і посібники застосовні для фахівців з аналізу вимог, проектувальників, викладачів, для фахівців з технічної документації, розроблювачів, тестировщиков, для фахівців із забезпечення практичності, лідерів проектів і бригадирів - для усіх, хто вовлечен у розробку ПО, хто націлений на швидке досягнення результатів і хто повинний виконувати більш широке коло робіт з більшою ефективністю.
Ефективність. Тією ж мірою , у якій на розроблювачів давить прес вимог зниження витрат, фахівці з розробки ПІ і забезпеченню практичності зобов'язані домогтися кращих результатів більш ефективним способом. Цей тиск означає, що
" Фахівці зі створення програмного продукту роблять саме те, що потрібно, і так, як потрібно.
" Цикли забезпечення практичності вдається скоротити не піддаючи ризику результати.
Таким чином, існує можливість у короткий термін разюче поліпшити результати і якість ПІ навіть за рахунок невеликих ресурсів. Це обіцяє небувалі перспективи для кінцевих користувачів.
Причини успіхів і невдач програмних проектів.
Вивчення джерел на зразок книг Брукса (Brooks), МАККОННЕЛЛА (McConnell) і Кейла (Keіl) дозволяє знайти загальні ідеї, що стосуються причин чи провалу успіху проектів. Крах проекту може виражатися в значній перевитраті коштів, затримці виконання проектів, анулювання проектів і неприйнятті продукту з боку користувача. Успіх виражається у виді продукту, що задовольняє вимогам, поставляється точно в термін і з дотриманням інших обмежень, а також викликає в користувачів позитивне відношення протягом тривалого часу. Ці теми коротко обговорюються в книзі, а першопричини провалу й успіхів аналізуються на всьому її протязі.
Участь користувачів. Знання про користувачів, їхньому робітничому середовищу, задачах, обмеженнях і цілях має істотне значення для постачання продукту, що задовольняє їх потребам. Існують методи по ефективному залученню користувачів до процесу вироблення вимог, проектуванню, конструюванню, оцінці, а також розгортанню і застосуванню.
Корисне правило. Чи користувач представник компанії не завжди може визначити свої потреби таким чином, щоб їхній легко було перетворити в чи вимоги придатний проект. Однак користувач може бути категоричним у своїх судженнях щодо того, що бажано і що небажано у вашому програмному продукті, когд він стане доступним для чи апробації використання.
Вимоги. Ділові і функціональні потреби - найбільш загальний і легкий для збору вид вимог. Однак вимоги у відношенні характеристик ПІ, практичності, інтеграції і погодженості дуже часто випустять з уваги. У багатьох випадках характеристики ПІ визначаються неявно (може навіть несвідомо) у виді деяких чекань.
З огляду на, що близько 50% сукупного програмного коду приходиться на ПІ, для розуміння вимог до видимого для користувачів властивості продукту потрібно прикласти додаткові зусилля. Крім того, вимоги до практичності, інтеграції і погодженості повинні бути визначені явно і піддаватися виміру. Тільки тоді можна перевірити і вимірити, наскільки продукт відповідає планам і оцінці необхідних для його розробці зусиль.
Корисне правило. Після того як вимоги встановлені, їх необхідно контролювати і керувати ними. Проектні бригади повинні остерігатися "розповзання" вимог і функціональних можливостей, ініціаторами якого виступають як користувачі, так і самі проектні бригади. Розповзання функцій убийственно для проекту!
Планування. Що стосується термінів, отут оцінки розроблювачів, як правило дуже оптимістичні, однак найчастіше причина подібного оптимізму полягає в непоінформованості. Це в основному питання кваліфікації і досвіду стосовно до сучасної технології ПІ. З безліччю стилів і функцій ПІ зв'язаний великий обсяг інформації, що включає масу деталей, особливості очікуваного поводження, а також надлишкові зведення.
Найчастіше тільки після завершення другого-третього кола проектування розроблювача, що відповідають за ПІ, здатні розібратися в масі дуже тонких деталей. На жаль, до цього часу найбільш досвідчені фахівці переключаються на інші задачі і над програмами ПІ працює новий колектив розроблювачів, що наштовхується на ті ж старі перешкоди, що гальмують швидкість процесу - порочне коло, що дорого обходиться.
Планування повинне передбачати досить часу для придбання навичок, використання методів забезпечення навичок якості ПІ і практичності, а також для відстеження результатів і формування звітності. Крім того, плани для задач ПІ і практичності можуть зажадати більш детального пророблення, чим звичайно передбачається для інших областей проекту.
Навички. Розробка нового ПО вимагає освоєння значного обсягу інформації і придбання навичок. Тут мова йде про необхідність застосування щодо нових операційних систем, мов, архітектурних стилів додатків, стилів користувальницького інтерфейсу і безлічі останніх інструментальних засобів і технологій. Витрати на кожен новий предмет поступово збільшуються: спочатку вивчаються основи, потім необхідно засвоїти й опанувати новим предметом і, нарешті, навчитися застосовувати знання на практиці. Уміння застосовувати отримані знання на практиці означає здатність використовувати інструментальні засоби і методи швидко і з найбільшим ефектом для користувачів. Чим більше предметів потрібно вивчити одночасно, тим вище ризик для проекту.
Старе корисне правило. Існує три основні причини провалу проекту:
" У бригади немає досвіду спільної роботи.
" Бригада використовує нову операційну систему.
" Бригада не здатна працювати з новим обладнанням.
Наявність будь-яких двох із трьох причин приводить до провалу більшої частини проектів:
Нове корисне правило. Існує шість основних причин провалу проекту:
" Бригада, що не має досвіду спільної роботи.
" Операційна система, що бригада раніше не використовувала.
" Нове обладнання, якого бригада не використовувала колись.
" Новий стиль ПІ, з яким бригада колись не працювала (наприклад, неграфічний користувальницький інтерфейс для PDA).
" Нова парадигма проектування, що бригада не використовувала колись (наприклад, объектно-ориентированная)
" Інші нові технології, з якими бригада раніше не працювала (наприклад, мультимедиа).
Наявність двох цих причин приводить до провалу більшості проектів.
Під "провалом" проекту розуміють відмовлення від проекту, значні затримки проекту, істотна перевитрата коштів, нездатність надати основні функції, передбачені проектом, нездатність досягти основних критеріїв у відношенні чи продукту неприйняття продукту користувачів.
Практика проектування. Перш ніж приступати до реалізації, доцільніше виробити проект, а ще краще сформувати архітектуру як основу проекту. Подібна практика добре зарекомендувала себе при розробці ПО, про також у відношенні створення ПІ і забезпечення практичності ПО. Ціль складається в задоволенні вимог, а такі підходи, як залучення користувачів, багатофункціональні бригади, ревізії проектних рішень, створення прототипів, безупинне оцінювання результатів, ітеративна розробка і швидка еволюція програмного продукту допомагає досягти цієї мети якнайшвидше . Якби розроблювачі частіше використовували ці методи, успіх супроводжував би набагато більшій кількості продуктів.
Корисне правило. До перевіреного на практиці методам варто звернутися якомога раніше .
Керування ризиками. Предепрежден - значить збройний. Осознавание того факту, що розробка ПО і ПІ являє собою види діяльності,піддані ризику, допомагає бригадам по створенню програмного продукту бути предусматрительными при керуванні ходом подій. Тут потрібно високий ступінь
передбачення труднощів. Необхідно більше уваги приділяти вивченню типових проблем і рішень виходячи з досвіду більшості груп по розробці ПО.
Типові плани допомагають фомализовать і повторно використовувати організаційні знання. Проектні бригади можуть заздалегідь звернути увагу на невірний напрямок у роботі. Типовий перелік можливих ризиків, зв'язаних із загальними проблемами ПІ і практичності, являє собою потенційно загальну і повторно використовуваний компонент проектного пданирования. Як приклад можна привести такі формулювання проблем, як "занадто багато кроків" і "несприятливий розмір екрана робочого столу".
Здається, що невірний хід справ повторюється з завидною сталістю. Явища типу "наша пісня гарна - починай спочатку" в області розробки ПО відбуваються всі частіше в міру росту зрілості проекту. Основна задача при розробці підвідних каменів і пасток на шляху до успіху.
Корисне правило. При належному плануванні, виконанні і відстеженні планів проекту мають набагато більше шанси на успіх.
Підхід до процесу розробки ПО.
Одне лише документальне оформлення чудового процесу розробки ПО не гарантує одержання відмінного продукту. Живопис цифрами навряд чи можна назвати великим мистецтвом. Багато видатні художників створювали ескізи ( чипрототипи моделі) своїх чудових робіт і багаторазово застосовували до них свої методи і підходи доти , поки їхнього добутку не досягали досконалості. Розуміння потреб і критеріїв успіху, володіння проектним баченням, уміння передати це бачення, вимір результату відповідно до критеріїв, ітеративне повторення процесу доти , поки вірний проект не одержить свого втілення - без цих факторів неможливо створити високоякісний продукт.
У цій книзі описаний необхідний і достатній процес. У відмінності від повареній книзі, тут приводяться методи, що роблять можливим варіації і відхилення від основної теми, розглядаються також методи оцінки достатності результатів виконання процесів.
Підхід до вироблення проектних рішень
Кращі рішення вдається одержати в тих випадках, коли розглядається кілька альтернатив. Однак пошук альтернатив, як правило, обмежений за часом, витратам, кваліфікації, руху технологій, приступності ресурсів, конкуренції, а також по інших факторах. Настає момент вибору єдиного рішення, що повинне бути надано користувачам.
Корисне правило. Варто уникати тривалого пошуку кращого можливого рішення, тому що будь-яку розробку можна удосконалити, а проект, що задовольняє всім проектним вимогам, - це саме те, що необхідно користувачам.
У книзі описуються методи вироблення альтернатив, включаючи альтернативи для проблем, виявлених під час розробки, а також методи оцінки достатності альтернатив і критеріїв вибору.
Використання передового досвіду
Розглянуті в книзі методи засновані на використанні досвіду - вони були перевірені на багатьох проектах, що включають розробку ПО для орієнтованих на ринок додатків і додатків, розроблювальних для власних нестатків. Однак використання методів не гарантує успіху, як і не веде до провалу. Лише деяким проектам чи повезло ж вони удалися випадково.
Частина шляху, що залишилася
В основі подорожі, початого в частині цієї книги, що залишилася, лежить вивчення приклада проекту і проходження "школи твердих помилок". Читачам має бути познайомиться з наступними темами.
" Планування.
" Вимоги.
" Аналіз користувачів і задач.
" Проектування ПІ, довідкової системи, системи навчання і графіки.
" Утілення проекту в специфікації, прототипі, посібнику зі стилю і програмному продукті.
" Оцінка пропонованого продукту.
" Перехід між ітераціями з метою виправлення помилок і збереження вірних рішень.
" Розгортання.
Корисне правило. Розроблювач ПО повинний бути щирим фанатом, щоб випробувати насолода від подібної роботи.
Продовження обговорення проекту.
Лідер проекту зненацька ввійшов у наш офіс. Він виклав вам враткий огляд проекту і повідомив про свої зобов'язання перед вищим керівництвом. Лідер расказал вам про те, як він організує проект і кого він вибрав як керівника робіт, не зв'язаних з ПІ.
Він розмовляв з вашим керівником і повідомив, що хотів би призначити вас технічним лідером робіт з ПО, а також виразив свою впевненість у вашій кваліфікації і можливостях. Ви тільки що завешрили оформение документації по попередньому проекті і не одержали призначення в рамках інших проектів. Незважаючи на деякі розуміння у відношенні календарного плану і рамок ви усвідомлюєте, що ваш вибір у сформованої обстановки усередині організації - розроблювача обмежений.
Лідер проекту попросив вас зібратися з думками з приводу підходу, календарного плану і ресурсів, необхідних для розробки ПІ в рамках проекту. Він хотів би з вами встетися через 30 хвилин. На зустрічі також буде присутній лідер бригади по роботах, не зв'язаним з ПІ.
Питання?
Посилання
Brooks F. The Mythіcal Man, 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
McConnell S. Rapіd Development, Mіcrosoft Press: Redmond, WA, 1996.
Keіl M et.al. A Framework for Іdentіfyіng Project Rіsks, Communіcatіons of the ACM, Nov. 1998
Torres R. user Centered Practіces іn a Customer's World, ІBM Іnteract 98 Conference Proceedіng, Yorktown Heіghts, NY, 1998.
Torres R. Graphіcal User Іnterface Desіgn and development Overvіew, Share 81 Conference Proceedіng, Aug. 1993.
РОЗДІЛ 2
Проектування через постачання з орієнтацією на користувача
Програмний ПІ залучає все більша увага і здобуває усе більше значення як складової конкурентної переваги. У міру того як перелік функцій програмних засобів стає усе длиннее і складніше, користувачі, що відповідають за придбання продукту, дивляться на ПІ як на дозвіл проблеми складності. Якщо ПІ продукту захоплює увага користувача, якщо він легкий у вивченні, простий у використанні, а також має прийнятну ціну і можливостями, продукт домагається конкурентної переваги. Конкурентна відмітна перевага можна одержати в тому випадку, якщо заява про більш низькі витрати на навчання і виграші в продуктивності відповідають дійсності.
Створити продукт, що володіє конкурентною перевагою і відмітними здібностями, не можна за допомогою указу, чи мистецтва чарівництва. Існує не мало методів, що збільшують імовірність досягнення твердих цілей і створення вдалого продукту, однак жоден з цих методів не може служити панацеєю. Тут потрібно погоджена, систематична, напружена робота з боку керівництва і технічних фахівців. Процес проектування і розробки продукту включає кілька етапів планування, установлення вимог, проектування, реалізації, оцінки і розгортання, протягом яких здійснюється ітеративне задоволення вимог.