Глава 17

Методи специфікації

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

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

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

" Потреби і труднощі.

" Підходи до специфікації.

" Специфікації в стилі мінімалізму.

" Види специфікації- концептуальна, высокоуровневая, деталізована; реалізація.

" Схема специфікації.

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

" Продовження обговорення проекту: специфікація.

Розробка специфікацій для Пи-ориентированных додатків (мал. 17.1) - важка справа, особливо для проектів з коротким життєвим циклом.

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

Потреби і труднощі

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

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

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

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

" Визначення полючи.

" Мітка для полючи в звичайному чи книжковому стилі.

" Пунктуація для мітки (підкреслення, виділення і т.д.).

" Внутрішнє ім'я елемента керування для мітки.

" Внутрішнє ім'я елемента керування для полючи.

" клавіша, Що Прискорює, для полючи.

" Розташування мітки і полючи на екрані.

" Інтервал між міткою і полем.

" Інтервал між міткою, полем і іншими елементами керування на екрані.

" Вирівнювання базової лінії тексту мітки і полючи.

" Необхідний індикатор полючи, якщо такий доречний.

" Тип, формат, діапазон даних і значення даних, використовуване за замовчуванням.

" Ширина полючи.

" Маски введення, якщо такі маються.

" Вирівнювання даних усередині полючи.

" Порядок роботи клавіші табуляції.

" Специфічне поводження пристрою введення у відношенні полючи (наприклад, чи клавіатура миша).

" Зовнішній вигляд (шрифт, стиль, розмір, колір, ефекти, графіка).

Поводження (розблокування і блокування, тільки чи перегляд редагування, використання звуку і т.п.).

" Правила верифікації для самого полючи і для полючи у взаємодії з іншими даними, представленими на екрані (безліч функцій, що забезпечують перевірку даних (dіalog data verіfіcatіon), одержуваних від діалогових эле-ментов керування. - Прим. ред.)

" Бізнесу-правила, керуючі обробкою даних.

" Умови виконання верифікації.

" Інформація з повідомлень, полю, підтримці ефективності, довідкова і навчальна інформація для полючи.

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

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

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

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

Підходи до специфікації

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

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

Специфікації в стилі мінімалізму

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

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

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

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

" Стислість.

" Відповідність задачі.

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

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

Відповідність задачі. Задача, підтримувана специфікацією, - це проектування, реалізація і тестування ПІ. Специфікація звертається до наступного питанням.

" Динамічний і використовуваний за замовчуванням зовнішній вигляд.

" Незалежне поводження.

" Вимоги до взаємодії користувача із системою.

" Взаємодія з іншими системами і програмними можливостями.

" Результуючий ПІ.

У специфікації також представляються системні результати.

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

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

Корисне правило.

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

" Фіксуйте найбільш часті помилки, чинені вашою бригадою.

" Для нестатків опису екранів повинне бути досить від двох до трьох сторінок тексту (включаючи віконну графіку).

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

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

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

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

Корисне правило. Специфицируйте те, що потрібно проектній бригаді - не більше і не менше.

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

" Колір тла, розміри і властивості вікна повідомлення.

" Розміри використовуваних графічних об'єктів.

" Відстань між елементами графіки.

" Початкові, проміжні і кінцеві позиції "літаючої" піктограми.

" Використовувані проміжні піктограми.

" Проміжок часу від старту до фінішу "літаючої" піктограми.

" Повторення циклів - при необхідності.

" Поводження по завершенні дії.

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

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

" прототипи, Що Виконуються, чи приклади.

" Приклади проектних чи рішень фрагментів вихідного коду, що створюють бажаний ефект.

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

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

Види специфікації - концептуальна, высокоуровневая, деталізована; реалізація

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

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

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

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

" У розпорядженні бригади системних тестировщиков мається досить деталізована інформація для того, щоб написати, виконати й оцінити тестові прецеденти.

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

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

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

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

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

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

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

Схема специфікації: уведення, огляд ПІ,

специфічні компоненти

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

Уведення

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

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

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

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

Огляд ПІ

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

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

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

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

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

Специфічні для додатка компонента ПІ

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

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

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

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

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

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

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

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

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

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

Панелі інструментів. У специфікації відбиваються піктограми і пове-дение панелей інструментів. Описуються можливості, що представляються кожною кнопкою панелі інструментів.

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

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

Клавіші, що прискорюють, меню. Специфицируются символи клавіш, що прискорюють, для елементів вибору меню, що випадають меню і спливають меню.

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

Області стану. Якщо в екранах передбачається використовувати області стану, їх варто описати. Корисно привести приклади інформації, що міститься в цих областях стану.

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

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

про взаємодії легше всего використовувати таблицю. Тут також необхідно дотримувати стандартів платформи.

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

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

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

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

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

Формати печатки. Приводяться описи форматированного висновку на печатку для програмного об'єкта. Це здійснюється відразу після того, як стають відомі макети відображення.

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

Допомога. Специфікація забезпечує структуру інтерактивної допомоги користувачу.

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

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

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

Іноді потрібно використовувати повідомлення підтвердження, щоб дати пользова-телю знати, що операція завершилася успішно. Ці повідомлення підлягають опису.

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

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

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

Питання

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

ПОСИЛАННЯ. Специфікація містить перелік усіх документів, що мають до неї відношення. До основних документів відноситься документація по вимогах, прототипам, іншим специфікаціям, реалізації, тестовим планам, звітам і т.д.

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

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

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

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

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

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

Корисне правило. Якщо обсяг необхідних знань занадто велика, потрібно доробка.

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

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

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

Погоджуйте специфікацію з реалізацією. Після складання

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

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

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

Корисне правило. Дотримуйте стандартів для платформи.

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

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

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

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

специфікація

Менеджер проекту попросив вас підготувати оглядовий документ (тези для брифінгу з керівниками і клієнтами). Крім того, він бажав би бачити начерк змісту специфікації, а також приклад специфікації для одного екрана. Завтра після полудня повинний відбутися великий брифінг із виконавчим керівництвом компанії. Лідеру проекту потрібно огляд по продукті до 8 годинник ранку для перегляду. Для цієї роботи у вашому розпорядженні друга година.

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

" Звичайно, як приклад екрана варто вибрати такий екран, що є присутнім на всіх платформах і повинний бути описаний для кожної з них.

" Схема специфікації повинна бути звернена до всіх стилів взаємодії і визначати момент завершення конкретного елемента (наприклад, на етапі высокоуровневого чи деталізованого проектування).

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

Як вправу спробуйте оцінити, який може бути повний обсяг раз-рабатываемой специфікації. Також постарайтеся визначити, скільки часу займе створення документа і його перегляд за участю відповідних співробітників і організацій. Чи дозволена така робота з погляду план-графіка і ресурсів проекту?

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

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

Продовжуйте ваше дослідження за допомогою Іnternet.

Питання?

Посилання

Etlіnger H.A. Teachіng Programmіng: the Mіnіmalіst Vіew, ІEEE Software, Mar., 1991.

Gong R. and Elkerton. Desіgnіng Mіnіmal Documentatіon Usіng a GOMS Model,

ACM/SІGCHІ '90 Proceedіngs, Aprіl, 1990.

Myers У A State of the Art іn User Іnterface Software Tools, CMU-CS-92-114.

Rettіg M. Nobody Reads Documentatіon, Communіcatіons of the ACM, July 1991.

Torres R. Graphіcal User Іnterface Desіgn and Development Overvіew, Share 81 Conference

Proceedіngs, August 1993.

Torres R. et al. Proofreadіng GUІ-based Applіcatіons, Common Ground, UPA Newsletter,

Summer 1999.

Torres R. et al. The Rule Book: A Guіded Expert System, ІBM Technіcal Report TR 71.0039, 1995.