Глава 18

Низкоуровневое проектування

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

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

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

У цій главі розглядаються наступні питання.

" Деталі! Деталі!! Деталі!!!

" Пророблення деталей.

" Важко передбачувані фактори.

" Низкоуровневое проектування.

Деталі! Деталі!! Деталі!!!

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

Деталізовані функції, зовнішній ВИГЛЯД, поводження. Высоко-уровневый проект концентрується на широких проектних рішеннях на рівні екранів, логіки викликів і взаємодій. Завжди залишається великий обсяг деталей, що вимагають пророблення, особливо коли мова йде про реалізацію. Напружені календарні графіки вимагають знання всіх деталей з абсолютною визначеністю.

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

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

Звичайно проектні елементи переглядаються для всіх можливостей, обеспе-чиваемых продуктом.

От зразковий перелік цих елементів.

" Використання ПІ і стандартів платформи.

" Передбачувана користувальницька модель.

" Особливості об'єктів, властивостей і операцій.

" Структура і логіка викликів чи вікон екранів.

" Основні вікна, екрани, представлення і діалоги.

" Стандартні і додаткові представлення.

" Спеціальні можливості ПІ.

" Графіка, компонування, звук і візуальний стиль.

" Стиль і команди меню.

" Інсталяція, операції перетаскування об'єктів, буфер обміну, печатка і поводження робочого столу.

" Використання можливостей дисплея, клавіатури і покажчика.

" Використання методів організації зворотного зв'язку для підтвердження дій користувача при індикації ходу процесу і помилках.

Нижче приведені приклади робіт, що виконуються, переглядаються і за-вершаются, але не фігурують як частина высокоуровневого проекту.

" Відображення елементів даних, що визуализированы в ПІ, на структуру бази даних.

" Проектування інтерактивних і функціональних алгоритмів для підтримки контролю бізнес - процесів і реалізації бізнес - правил.

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

" Одержання необхідного схвалення з боку керівництва, а також обличчя й організацій, зацікавлених у проекті.

" Перенесення проекту в середовище керування змінами.

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

Корисне правило. Варто документувати нестандартне поводження, коли воно виявляється чи випадково відповідно до проекту.

Обновлена графіка. Первісні графічні можливості і во-просы візуалізації розробляються на початкових етапах проектування, тому в ході деталізованого проектування буде потрібно уточнення цих графічних можливостей (іноді використання графіки виходить за межі первісних проектних представлень). Крім того, на даному етапі потрібно остаточне детальне компонування екранів і повідомлень.

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

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

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

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

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

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

Корисне правило. Оцінки практичності варто проводити по можливо більшому наборі сценаріїв.

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

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

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

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

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

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

Корисне правило. Не слід перевантажувати специфікацію під час выполне-ния деталізованого проекту.

Проект реалізації і реалізація. Дотепер проект ПІ концентрувався на питаннях із ключовим словом "що" (тобто що система може робити, що бачить користувач, що повинний робити користувач і т.д.). Проект реалізації зосереджений на питаннях, що починаються зі слова "як". Наприклад, проект ПІ формує екрани з відповідним поводженням, а проект реалізації формує алгоритми, логіку викликів і структури даних для підтримки результуючого ПІ.

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

Пророблення деталей - розміри, фокус, розташування курсору, затінення і багато чого іншого

Заповнення деталей виглядає як процес уточнення. Низкоуровневое проекти-рование - це ще один етап уточнення, що проектна бригада виконує при участі користувачів. Часто використовувані і добре відомі можливості спро-ектированы, уточнені і відшліфовані. Менш досліджені чи раніше не опреде-ленные можливості розглядаються більш глибоко.

Проектування рідке використовуваних можливостей. На етапі высокоуровневого проектування проробляються часто використовувані задачі, можливості і ПІ. Однак частина функцій, що залишилася, системи і ПІ (до 80% загального обсягу) тепер вимагає такого ж рівня уваги й уточнення, який одержують інші системні можливості. Неясні, рідко використовувані і складні задачі, можливості і компоненти ПІ вимагають пророблення питань практичності.

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

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

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

Компонування. Уточнюються вміст екранів, групування, порядок і компонування інформації. Вирівнювання міток і полів, прив'язка інформації до координат макета, а також відповідність стандартам ПІ знову піддаються перу-огляду.

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

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

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

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

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

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

Корисне правило. Не забувайте про операції користувача по керуванню розташуванням вікон і екранів. Щоб забезпечити цей тип запам'ятовування даних параметрів, потрібно додаткова робота.

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

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

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

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

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

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

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

Корисне правило. Проектні рішення по печатці варто обновляти тимчасово з рішеннями по екранах.

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

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

Корисне правило. Усюди, де користувачі мають потребу в зворотному зв'язку, неї варто забезпечити.

Попередження й обробка помилок. У гарячці буденної суєти користувачі іноді роблять помилки, тому вже давно пропагується по-всеместное застосування операції скасування (звичайно відповідна команда виглядає як Скасувати (Undo)). Однак навіть порівняно прості підходи до реалізації операції скасування можуть обходитися дорого і, отже, вони недосяжні в рамках невеликих проектів зі стислими строками. Як альтернативу можна запропонувати пошук підходів захисту від помилок і обробки помилок. Деякі з цих підходів приведені нижче.

" Використання елементів керування (выпадающих списків), заснованих на розпізнаванні помилок для заміни полів уведення.

" Спеціальний зворотний зв'язок при помилці.

" Використання підтверджуючих повідомлень перед виконанням команд, результат1соторых може привести до небажаних наслідків.

Корисне правило. На етапі низкоуровневого проектування рішення по екранах варто піддати перегляду на предмет попередження і запобігання помилок, захисту від помилок і обробки помилок.

Важко передбачувані фактори

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

Корисне правило. Диявол криється в деталях.

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

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

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

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

Корисне правило. Проектуйте дійсно якісний продукт і не йдіть на компроміси по принципових питаннях.

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

Корисне правило. Уникайте помилок, але якщо вони усе-таки відбулися, тща-тельно аналізуйте їх.

Перевірка, що передує завершенню

проектування

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

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

Десять головних позицій, які варто дотримувати

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

1. Простота. ПІ повинний бути простим. Багато задач користувачів відрізняються складністю і заплутаністю бізнес - правил, "покладами" даних, тимчасовими обмеженнями і критичними мірами. Програмний інтерфейс не повинний додавати зайву складність. Додатки повинні полегшувати і підсилювати задачі, виконувані користувачами. Прості задачі повинні залишатися простими, а важкі задачі варто спрощувати. Застосування природних мо-делей роботи й ідей передбачуваних користувачів утворить основу досягнення простоти ПО. Порівняння вражень "до і після" прийняття проектних рішень допомагає переконатися у відносній простоті ПІ (однієї з мір простоти у вивченні використання ПО може служити такий показник, як однократне пояснення користувачу способів роботи з ним).

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

Ефективна організація, компонування і використання шрифтів утворить базис, на якому вибудовуються додаткові графічні символи, колір і додаткові графічні ефекти. Найкраще зарекомендував себе підхід на основі застосування навичок професійних дизайнерів комп'ютерної графіки для формування візуальних представлень (як мінімум). Створення одного графічного зображення з дозволом 32x32 вимагає манипу-лирования до 1024 пикселями, пофарбованими в різні кольори. Для досягнення ефективного результату необхідні спеціальні навички.

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

4. Продуктивність. ПІ повинний забезпечувати короткий шлях до результату і бути зручним у звертанні. Звичайні скарги з боку користувачів на Пи-ориентированный інтерфейс зв'язані з занадто великою кількістю екранів і кроків виконання робочих процедур. Практичний і ефективний продукт забезпечує розумний баланс між функціональними можливостями, ПІ, продуктивністю (часом відгуку) і надійністю. Програмне забезпечення повинне мати належні можливості (функціями, дан-ными, ПІ), що відповідає стилем і деталями ПІ, а також швидким часом відгуку і продуктивністю, він повинно бути стійким і виробляти ефективні результати.'

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

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

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

7. Властивості проблемної області, пізнавані користувачами. Об'єкти й операції повинні бути зв'язані з задачами користувачів. Завдяки цьому навіть за рамками базового стилю ПІ термінологія додатка, графічні символи, дані, компонування даних усередині вікон і макети для печатки виявляються досить знайомими для користувачів. Якщо користувачі взаємодіють із зовнішніми клієнтами, користувальницький погляд збігається з тим, що бачать клієнти.

8. Дружній зворотний зв'язок. У відповідь на кожну дію користувача необхідно забезпечити зворотний зв'язок. Підтвердження того, що почуте зрозуміло, являє собою важливе вираження ввічливості під час усного спілкування. Підтвердження може приймати різні форми. Для відносно швидких операцій, здійснюваних у процесі обробки, може бути ефективним просте використання піктограми піскових годин замість покажчика. Індикатори ходу процесу можуть бути ефективними під час об-работки тривалих операцій. Також ефективні анимированные діалоги. Якщо для забезпечення зворотного зв'язку використовуються діалоги, не варто змушувати користувача клацати мишею на кнопці для очищення полів діалогу, перш ніж продовжити розмову. Варто пам'ятати, що повідомлення, що виходять від програмного ПІ користувачу, повинні бути дружніми і предсказуе-мыми.

9. Оптимізація роботи з клавіатурою. Варто забезпечити оптимізацію взаємодії користувача з клавіатурою. Багато користувачів усе ще учаться упевненому використанню миші й інших координатно-вказівних пристроїв, але адже навчання ефективному використанню цих пристроїв вимагає часу. Для кожної операції, виконуваної з використанням миші, повинна існувати еквівалентна і гладко протікає операція з клавиа-турой. Утім, іноді клавіатура не дозволяє прямо виконати операції безпосереднього маніпулювання на зразок операції перетаскування-копіювання, однак еквівалентна операція копіювання повинна бути вы-полнима за допомогою клавіатури. У якості ключового проектного фактора варто розглядати можливість забезпечити не більш одного необхідного переходу миша-клавіатура в процесі виконання задачі користувачем. Велике поширення одержало використання мнемонічної навігації по списках.

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

" Випливайте загальним правилам проектування, таким як "Контроль- на стороні користувача", "Інтерфейс повинний бути прозорим", "Будьте послідовні (як внутрішньо, так і зовні)".

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

" По можливості проектуйте ваші рішення на відомі моделі ПІ.

" Утягуйте користувачів у проект на всьому протязі розробки ПО.

" Розроблювачі повинні поважати користувачів. Намагайтеся зрозуміти реальні потреби користувачів, прислухайтеся до користувачів і дійте з урахуванням їх думки.

" Намагайтеся зрозуміти реальні потреби розроблювачів (короткі терміни, обмеження інструментальних засобів, навички і т.д.). Відокремлюйте ці потреби від особистих запитів.

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

" Проектуйте, створюйте прототипы, проводите оцінку і здійснюйте ітерації доти , поки не будуть задоволені вимоги.

Десять позицій, які варто уникати

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

10. Полноэкранные вікна. Проектуйте дружні з погляду робочого столу додатка. Уникайте проектування екранів і вікон, що вимагають усієї площі дисплея. Помнете, що разом з екранами, що ви проектуєте, одночасно відображаються інші додатки. Великі екрани приводять до непотрібних і непродуктивних робочих кроків по керуванню вікнами. Один з корисних методів проектування полягає в тім, щоб свідомо розглядати проектоване ПО як один з багатьох додатків, з якими взаємодіє користувач, і відповідним чином використовувати доступний простір екрана стосовно до будь-якої задачі.

Початковий (установлюваний по' умовчанню) розмір екрана повинний відповідати задачі, що він підтримує. Наприклад, тип вікна для утиліти, призначеної для підтримки основної задачі, проектується таким чином, щоб використовувати четверту частину можливого простору екрана. З іншого боку, основний об'єкт прикладної області, що являє собою головний засіб виконання задачі, проектується таким чином, щоб використовувати від половини до третини можливого простору екрана. Крім того, у цих вікнах застосовується "золотий перетин" для співвідношення висоти до ширини клієнтської області (наприклад, 1-1 (паперовий блок розміром 5x5 див), 1-1,62 (каталожна картка розміром 3x5 див), 1-1,41 (лист папера розміром 12,6x17,64 див) і т.д.). За рахунок використання цього методу вікна об'єктів виглядають краще, а кількість робочих кроків зменшується.

9. Багато великих і залежних між собою вікон. Погано, коли для одного програмного додатка багато великих екранів, а наявність численних екранів, що залежать один від іншого, - ще гірше.

8. Екрани, розділені на велику кількість областей. Проектуйте прості екрани. Уникайте створення численних областей, для переходу між який потрібно заплутаний порядок застосування клавіші табулювання.

7. Сірі екрани. Уникайте сірого кольору як домінуючий колір тла для екранів. Тут виникає дві проблеми: одна - удобочитаемость, а друга - сумовитий вид. Звернетеся до основної колірної схеми об'єктів платформи, для якої звичайно характерні чорний текст на білому тлі. Варто обмежити використання сірого кольору для діалогів.

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

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

4. Незнайоме оточення. У відношенні розкадрування, компонування і структури екранів випливайте стандартам платформи. Уникайте незрозумілих для користувачів термінів. Імена об'єктів, команд і властивостей повинні бути пізнавані. Дані, значення і діапазони даних, а також формати даних, візуальний ряд і графіка також повинні бути знайомі користувачам.

3. Марна допомога. Допомога користувачам повинна бути осмисленої і корисний. Проектуйте, створюйте прототипы, проводите оцінку і здійснюйте ітерації доти , поки забезпечите корисну допомогу.

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

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

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

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

" Продемонструйте, яким образом задовольняються вимоги.

" Переконаєтеся, що проект включений у контур керування змінами і зміни визначені.

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

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

Корисне правило. Хоча на даному етапі проект у цілому майже довершений, має бути виконати ще багато роботи.

Продовження обговорення проекту

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

Дехто з вищих керівників пішов у чи відставку був переведений на іншу роботу, включаючи одного з основних спонсорів проекту. Був упроваджений ряд методів керування витратами. Ходили самі неймовірні слухи, і люди з бригади дивилися в майбутнє з неприхованим песимізмом.

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

Стан проекту. Высокоуровневый проект успішно пройшов технічні оцінки, оцінки практичності й інші проектні оцінки. Як звичайно, нагромадилася маса проблем, яким не видно кінця. Іспиту на практичність і відгуки замовників указали на деякі пропущені (бажані) можливості, а пари основних екранів занадто заплутані. Однак у загальному проектування ПІ підтримується на належному рівні.

Лідер проекту попросив вас обновити план проекту аж до етапу низкоуровне-вого проектування поряд з деталізованими оцінками у відношенні деяких аспектів роботи. Вам необхідно проробити наступні питання.

" Перелік усіх робіт з реалізації, модульному тестуванню, а також по діях, що веде до розгортання.

" Завдання і календарні плани для проектного персоналу, визначені для частини проекту, що залишилася, аж до розгортання.

" Дати, коли кожен співробітник завершує завдання і може бути переведений на виконання іншого завдання.

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

Низкоуровневый проект. Після відновлення плану-графіка необхідно приступити до роботи над деталізованим проектом.

" Обновите логіку ПІ для програмного забезпечення.

" Розробіть проектні рішення і прототипи для всіх деталей, що стосуються зовнішнього вигляду і поводження для кожного з наступних типів екранів стосовно до кожної із середовищ з метою підтримки трьох загальних задач для додатка Conference Companіon:

" об'єктний екран;

" командний екран;

" екран допомоги;

" екран повідомлення;

" методи організації зворотного зв'язку;

" екран підтримки експлуатації.

" Завершите проектування всіх екранів.

" При необхідності обновите прототип і специфікацію ПІ.

" Перевірте, що методи і засоби реалізації реальні.

" Відіб'єте в документації усе, що потрібно передати розроблювачам і замовникам.

Через двох тижнів повинна відбутися проектна ревізія інформації з низко-уровневым рішень. Через тиждень після проектної ревізії запланована ревізія рішень разом з потенційними замовниками і вищим керівництвом. Будьте готові продемонструвати деталізовані рішення у відношенні поводження продукту в середовищі GUІ-, WUІ- і HUі-интерфейса. По завершенні цих заходів передбачається приступити до проекту реалізації, попередньо буде проведений мінімальний аналіз з боку бригади програмістів.

Припущення ПО задачі. Тривалість конференції - три дні, і щодня паралельно проводяться три сеанси презентації. Щовечора перед-покладаються деякі позаурочні заходи. От перелік загальних задач конфе-ренций.

1. Створіть вашої особистої порядок денний для конференції.

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

3. Простежите за змінами на порядку денному конференції й ознайомтеся з на-правліннями наступної презентації.

Прикладом рідко використовуваної задачі може служити пошук найближчої аптеки, що працює вночі, так що ви зможете купити аспірин.

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

Питання?

Посилання

Rettіg. Nobody Beads Documentatіon, Communіcatіons of the ACM, July 1991.. Soloway E. How the Nіntendo Generatіon Learns, Communіcatіons of the ACM, Sept. 1991. Torres R. Graphіcal User Іnterface: Desіgnіng Object-Orіented Components, Share 83, Aug. 1994.