Глава 15
Ітеративна розробка
Підхід, заснований на ітеративній розробці ПО, продемонстрував можливість удосконалювання ПІ, практичності, погодженості, інтеграції і підвищення рівня задоволеності користувачів практично для будь-якого продукту. Ітераційний цикл стосується процесу уточнення проектних рішень на основі користувальницьких оцінок макетів, моделей, прототипів і реального продукту. Виходячи з результатів оцінки визначаються потенційні чи проблеми удосконалення, удосконалення перетворяться в проектні рішення, оцінюються щодо компромісів між вигодою, вартістю і термінами, а потім реалізуються і знову піддаються оцінці. Цикл ітерацій повторюється доти , поки не будуть задоволені задані чи критерії продукт не буде реалізований і поставлений замовникам для серйозного іспиту.
Головна мета ітераційного циклу полягає в задоволенні вимог до реального продукту, корекції реальних проблем і реалізації необхідних усо-вершенствований (мал. 15.1). При цьому передбачається, що в розпорядженні разра-ботчиков мається надійна вхідна оцінна інформація, отримана в результаті чи тестування реального використання замовниками продукту. В умовах усе більш наполегливих вимог по скороченню часу розробки здається привабливої ідея найбільш швидкої реалізації проекту з виконанням наступних ітерацій для продукту в ході його експлуатації. Однак якщо розробка подібного продукту завершується успішно, можна вважати, що бригаді розроблювачів дуже повезло.
У даній главі розглядаються наступні теми.
" Передумови.
" Визначення головної ланки.
" Дефекти, "фіксатори" і компроміси - методи і діагностика.
" Короткострокові і довгострокові наслідки.
" Наступний аналіз.
" Швидкий цикл розробки й оптимізація.
" Організаційні і технічні аспекти.
" Продовження обговорення проекту.
Мотивація. Якщо копію комерційного програмного продукту здобуває мільйон користувачів, це, звичайно, велика удача. Однак якщо 5% з мільйона покупців виявляються незадоволеними, у підсумку це складає 50 000 пользо-вателей! Це величезна кількість розстроєних людей, багато хто з них виражають невдоволення і вимагають особливого підходу. Для Web-вузла Іnternet (серед мільйонів подібних вузлів) незадоволеність може вилитися в ігнорування користувачами цього Web-вузла. Проектна бригада прагне уникнути подібної ситуації.
Ітеративний метод застосовується до розробки продукту для того, щоб обнару-жить і розв'язати основних проблемы, а також внести в продукт важливі усовершен-ствования на ранніх етапах життєвого циклу продукту. Звичайно, основна мета ітеративного підходу полягає в тому, щоб уникнути неприйняття продукту і переробки, що стоїть-дорого-коштує, при усуненні проблем чи замовників при реалізації основних удосконалень. Крім того, що практика ітеративного (покрокового) підходу добре зарекомендувала себе в індустрії програмних засобів, як нарощування можливостей продукту, цей метод розробки можна уподібнити свого роду техніці безпеки, спрямованої на запобігання користувальницької не-задоволеності.
Затримка з виведенням продукту на ринок означає підвищення вартості разра-ботки, збільшення покупної ціни і потенційно більш високий рівень конкуренції. Коли мова йде про створення серйозного продукту, ітеративна розробка просто заради ітеративної розробки неприйнятна. Безупинно наступні одна за іншої ітерації автоматично не гарантують значного удосконалення продукту.
Ітеративне нарощування можливостей стає труднодостижимым у міру того, як більш прості аспекти зміни продукту реалізуються в рамках більш ранніх ітерацій. Потенційна вигода від додаткових ітерацій процесу розробки повинна переважувати додаткові витрати, яких вони вимагають як від розроблювачів, так і від замовників.
Корисне правило. Протягом ітерації помнете про всіх попередніх методахах розробку (методи спільної розробки, евристичний аналіз і т.д.). Ці методи корисні при класифікації рішень проблем і потенційних удосконалень.
Пристосованість до змін. На щастя, продукти, як правило, проектуються і реалізуються в передбаченні майбутніх ітерацій. Якщо продукт не пристосований до швидких і частих змін, ітеративна розробка продукту може бути неефективної і безплідн.
Корисне правило. При проектуванні продукту подбайте про те, щоб він легко піддавався змінам.
Повнота. Не забувайте про складовий користувальницькій задоволеності. Оцінка загального рівня задоволеності і практичності повинна враховувати эффек-тивность роботи користувачів і їхнє відношення до наступного основним факторам.
" Можливості (предметна область і користувальницький інтерфейс).
" ПІ (зовнішній вигляд, поводження, користувальницька взаємодія).
" Продуктивність (час відгуку).
" Надійність (загальна якість).
" Інсталяція.
" Допомога користувачам (підтримка експлуатації, довідкова система, обуче-ние і друкована документація).
Вхідна інформація, одержувана в результаті проведення іспитів практич-ности чи безпосередньо від користувачів, дає усвідомлену чи неусвідомлену оцінку всіх цих параметрів. Правильна оцінка системи залежить від правильної оцінки основних факторів.
Корисне правило. Основна мета ітеративної розробки полягає в наступному.
" Забезпечення ретельного причинного аналізу реально існуючих і потенційних проблем.
" Рішення реальних чи потенційних ключових проблем.
" Визначення інших областей потенційно значимих удосконалень.
" Збереження задовільних можливостей у незмінному виді.
Готовність вислухати. Важливу роль у процесі розробки грає готов-ность вислухати персонал і користувачів, що беруть участь в оцінці практичності, про-' судити і пояснити виниклі проблеми й отримані результати. Іноді разра-ботчикам важко прийняти критику у відношенні вже спроектованого і реализо-ванного продукту по прошествии тривалого періоду часу. Однак готовність внести зміни в продукт, щоб зробити його більш корисним для замовників, необ-ходима для досягнення значного результату в процесі ітеративної розробки.
Компроміси. Варто знати, які компроміси і конкуруючі між собою фактори впливають на внесення змін у продукт. На мал. 15.2 показані кін-курируючі фактори і компроміси, що впливають на чи сприйняття продуктивність роботи користувача. Наприклад, фактори деталізованого проектування, що впливають на легкість вивчення, можуть вступати в протиріччя з легкістю дол-говременного застосування продукту досвідченим користувачем. Інші фактори накла-дывают обмеження на досяжність тих чи інших результатів, як, наприклад, стислі строки чи розробки недостатній досвід у відношенні засобів розробки.
Якщо проаналізувати зміни в ПІ продукту, багато елементів виявляться взаємозалежними. Найчастіше ітеративний процес розробки продукту подібний грі, де зміна одного з властивостей продукту приводить до передбачуваних і несподіваних результатів в інших областях. Проектна бригада повинна зважувати компромісні рішення і протиріччя з погляду загального виграшу користувача.
Відшукати головна ланка
Досвідченому проектувальнику необхідно проникнути в сутність процесу оцінки результатів іспитів практичності й в інші форми оцінки продукту кінцевими користувачами. За першим циклом аналізу випливає друга спроба, що показує, що практичність пройшла ретельну оцінку з погляду короткострокової і довгострокової перспективи.
Припущення. Уведемо наступні припущення.
" Оцінка практичності осмислена проектною бригадою.
" Користувачі, що приймали участь в оцінці, є типовими предста-вителями передбачуваного кола користувачів.
" Використані сценарії - типові для даного продукту, вони адекватно підтримуються об'єктом тестування в термінах основних факторів, що визначають рівень задоволеності користувачів.
Чи виправляти не виправляти?! Проектна бригада повинна безупинно, разом з аналізом кількісної і якісної інформації, з'ясовувати, які виправлення і зміни повинні бути внесені в продукт. При цьому основне питання, на який необхідно відповісти, полягає в тім, які зміни імовірніше всего дозволять поліпшити наступні показники.
" Рівень задоволеності користувачів.
" Продуктивність роботи користувачів.
" Невдоволення користувачів (мається на увазі зниження рівня удовлетво-ренности).
" Конкурентноздатність.
" Задоволення інших критеріїв і цілей.
Виходячи із сукупності результатів тестування проектна бригада визначає, що виправляти, а що залишити без змін. Іспиту мають тенденцію концен-трировать увага розроблювачів на виявленні проблем.
Дефекти, "фіксатори" і компроміси -
методи і діагностика
На ранній стадії чи розробки в процесі дуже цілеспрямованої оцінки можна одержати досить деталізовану діагностичну інформацію на ви-соком рівні деталізації. Високий рівень деталізації, якого сутужніше досягти на етапі высокоуровневого чи деталізованого проектування, включає оцінку практичності на рівні екранів на етапі концептуального проектування. Корисно засвоїти основне практичне правило, що говорить, що для задоволення критеріїв і потреб користувачів змінювати випливає тільки те, що необхідно змінити.
На перший погляд. Деякі корисні правила діагностики включені в перелік, приведений у табл. 15.1. Проектна бригада відшукує чи стереотипи схеми в результатах, ґрунтуючись на інформації, отриманої від багатьох користувачів. Однак навіть інформація від одного користувача корисна для підтвердження інтуїтивних висновків бригади, що стосується області потенційних чи проблем по-тенциальных удосконалень. Варто подбати про те, щоб не діяти передчасно в рішенні чи проблем удосконаленні можливостей продукту на основі аналізу єдиного джерела даних.
,,Якщо воно справно... Позитивні зауваження і високі об'єктивні чи суб'єктивні оцінки вказують на області, де продукт варто залишити в неиз-менном виді. Очевидно, що негативні коментарі, піддані помилкам і потребуючі частій допомозі області, а також низької суб'єктивної оцінки вказують на проектні рішення, які потрібно змінити. Області, де чи конкурент продукт-попередник виявляються краще, указують на необхідність усо-вершенствований. Ясно, що якщо чіткий критерій для практичності не задовольняється, у продукт потрібно внести зміни.
Корисне правило.
1. Помнете, що практичність- це функція можливостей, ПІ, производи-тельности, документації й інших факторів.
2. Прагнете зрозуміти реальну причину проблеми, перш ніж виправляти що-небудь, що може бути не коштує "ламати". Ви можете виправити симптом, внести нові проблеми і знову виявитися перед проблемою, що вимагає дозволу.
Варто класифікувати підлягаючі виправленню елементи (низький рейтинг, привласнений кінцевими користувачами, порушення чи критеріїв низька конку-рентоспособность). Крім того, варто також класифікувати елементи, що поводяться належним чином і повинні бути залишені незмінними.
З іншого боку, якщо конкретний підхід коштує на шляху до досягнення кращих результатів, його цілком можна відкинути і звернутися до більш сильного підходу.
Серйозність і частота проблем. Якщо спочатку звичайно не бракує в проблемах, над якими приходиться працювати, пізніше, цілком імовірно, буде відчуватися надлишок проблем. Існує настійна потреба в оцінці ризику, зв'язаного з індивідуальними і колективними проблемами.
Варто оцінити ймовірну частоту появи проблем, а також їхній можливий вплив на користувачів, що фінансує організацію і замовників, яким, зрозуміло, виявляється підтримка. У деяких випадках необхідно звернутися до здорового глузду. От придатний приклад.
" Проблема, що передбачає суворе покарання користувача, але яка зустрічається досить рідко, може бути оцінена як потребуючої корекції.
" Малозначна проблема, що, однак, доставляє великі незручності і зустрічається досить часто, повинна бути внесена в перелік проблем, що підлягають корекції.
Думки користувачів. Замовник не завжди може бути прав, але варто пам'ятати про тім, хто платить по рахунку! Прислухайтеся до думки користувачів, осо-бенно якщо продукт не відповідає основним задачам, необхідним користувачу. Проектна бригада взаємодіє з користувачами з метою з'ясування наступних питань.
" Які системні і прикладні навички застосовні (новачок, випадковий o користувач, експерт).
" Чого хоче домогтися користувач у реальному світі за допомогою продукту.
" Яким образом користувач прагне виконати роботу з використанням ПО.
Це забезпечує більш глибокий контекст для причин, по яких користувачі зробили ті чи інші зауваження, а також для рішення про тім, чи прийняти ці зауваження.
Короткострокові і довгострокові
наслідки
Перед проектною бригадою коштує питання: чи є потенційні чи реаль-ные проблеми наслідком короткострокового навчання і використання, чи ж вони відносяться до проблем довгострокового застосування, що виходять за межі на-чального навчання, чи ж і до тих і до інших. Оцінка практичності, зокрема , призначена для встановлення характеру деяких з цих важких проблем.
Суть питання. У контексті короткострокового і довгострокового використання часті звертання за допомогою і великий час виконання задачі не обов'язково вказують на проблеми. Оцінка продуктивності роботи типового користувача з новою чи системою додатком показує різні результати стосовно до короткострокової і довгострокової перспективи. Що стосується належним чином спроектованого ПО, те достатній рівень навчання виявляється досить швидко в процесі виконання декількох перших задач, швидкість роботи і точність підвищуються, а знання згодом розширюються. У загальному випадку, час на задачу і кількість звертань за допомогою поступово скорочується.
Розділите задачу на подзадачи, у рамках яких користувач взаємодіє з одним чи екраном діалогом. Наступний стереотип роботи користувача свидетель-ствует про наявність проблеми.
" Користувач витрачає занадто багато часу, намагаючись звернутися до конк-ретному чи екрана елементу керування.
" У роботі користувача зустрічаються чи помилки він постійно вимагає допомоги касательно конкретного чи екрана елемента керування.
Якщо в даному випадку користувач випробує утруднення, це свідчить про наявність проблеми як з ПІ продукту, так і з підтримуючою його інформацією. Доцільно провести наступний аналіз оцінок і зауважень користувача.
Початкове навчання і використання. Необхідно класифікувати проблеми як короткострокові і довгострокові. У багатьох випадках проблемами початкового навчання зневажають. Наприклад, проектна бригада не може, навчити користувача працювати з координатно-вказівним пристроєм. Аналогічно, про-ектная бригада не може надати істотну допомогу користувачу-новачку знайти
упевненість при роботі з основними елементами GUІ-, WUІ- і HUі-стиля. Однак що стосується додатки, проектна бригада здатна контролювати процес придбання користувачем навичок роботи з умістом додатка.
Інший приклад початкового навчання - знайти місце розташування елементів вибору меню. При цьому новачки у використанні GUі-интерфейса повинні досліджувати розташування всіх елементів меню, а більш досвідченим користувачам досить вивчити місце розташування тільки специфічних для даного додатка (нестандартних) елементів меню.
Запам'ятовування комбінацій клавіш, кнопок миші і розширених функцій миша - клавіатури присуще початковому навчанню і не обов'язково є реальною проблемою. Проблему початкового вивчення цього типу інформації не можна дозволити традиційними засобами.
Довгострокове використання. Пи-ориентированное додаток використовуються протягом тривалого періоду часу, якщо тільки кінцевий користувач відразу не відмовляється від нього. Якщо повезе, термін служби ПО продовжується на багато років і охоплює використання багатьох версій. У цьому випадку саме виявляються і стають помітними проблеми довгострокового використання.
Серйозні, довгострокові проблеми повинні бути виправлені, якщо ціль продукту - домогтися визнання. При довгостроковому використанні можуть проявитися фактори - перешкоди які самі по собі не зникають (наприклад, сумно відома, але дуже розповсюджена проблема "занадто багато вікон і занадто багато дій ) Непогодженість стосовно широко використовуваних і стандартних властивостей ПІ, наприклад, некоректні комбінації чи клавіш некоректне розташування елементів меню Edіt (Виправлення), таких як Cut (Вирізувати), Сміттю (Копіювати), Paste (Уставити), являє собою довгострокову проблему.
Існують операції, виконання яких згодом не легшає (наприклад, послідовність необхідних дій, що, якщо її не виконати в точності, приведе до втрати користувальницької чи інформації результатів усієї роботи). У додатках можуть бути області, де користувачі постійно випробують утруднення.
FUPRіD-факторы. Рівень задоволеності і практичності є функцією можливостей системи (Feature), продуктивності (Performance), надійності (Relіabіlіty), легкості інсталяції (Іnstallabіlіty) і документації, включаючи усі форми допомоги користувачам і підтримки якості функціонування (Documentatіon). Складаючи перші букви назв цих факторів, одержуємо абревіатуру FUPRІ. Крім розмежування на короткострокові і довгострокові, проблеми також розділяються на категорії відповідно до FUPRіD-факторами.
Вивчення FUPRіD-факторов указує на те, що можливості, ПІ і продуктивність відіграють найбільшу роль у забезпеченні загального рівня задоволеності і практичності для додатка. Однак якщо базова надійність, пристосованість до інсталяції й інформаційна підтримка не забезпечені належним образом, це може викликати невдоволення користувачів. Тестові анкети задумані таким чином, щоб ОДЕРЖАТИ ВІДГУКИ користувачів по основних факторах, що вносить внесок у практичність і загальну задоволеність користувачів. При створенні продукту важливо вважатися з користувальницькими оцінками і зауваженнями у відношенні цих і інших факторів.
Функціональні можливості стосуються достатності виконуваних функцій - як прикладних, так і интерфейсных - для того, щоб задовольнити потреби задач. Достатність функції не обов'язково означає, що продукт споконвічно має всі елементи, що звичайно включаються в перелік комплекту постачання для великої області додатка. Однак існує рівень деякої необхідної критичної маси функціональних можливостей, нижче якого додаток стає непридатним.
Грань між ПІ і функціями легко розмивається, так що необхідно ретельно відокремлювати те, що повиннео робитися, від того, як це повиннео робитися. Користувальницький інтерфейс стосується достатності елементів наочності (враження), поводження і користувальницької взаємодії (відчуття) для користувальницьких задач.
Ясно, що практичність ПІ надзвичайно важлива, але це не єдиний фактор, якому варто брати до уваги. Основа стилю ПІ системи визначає тільки частину загальної оцінки продукту, однак елементи Пи-ориентированного додатка впливають на значимі аспекти користувальницької задоволеності. Функції і ПІ потрібно акуратно відокремлювати друг від друга. І те й інше повинно бути легенею у вивченні і використанні.
Продуктивність легше всего зв'язати згодом відгуку додатка в інтерактивному режимі (наприклад, від початку до кінця операції). У деяких випадках продуктивність включає оцінку пропускної здатності системи при виконанні задачі в пакетному чи фоновому режимі. Якщо інтерактивний час відгуку більше деякої межі, користувачі виражають своє невдоволення.
Надійність інтерпретується як базова якість продукту в термінах безвідмовного поводження. Ця властивість фіксує загальний рівень довіри користувачів до цілісності і безпечного поводження системи. Чи можуть дані бути зруйновані системою? Чи можна втратити результати роботи при навігації? Це питання довіри до системи.
Пристосованість до інсталяції стосується легкості установки й інсталяції, що приводить до початкового використання продукту. Документація фіксує рівень задоволеності інформацією, що підтримує використання продукту, або у формі друкованої чи документації оперативно-доступної допомоги.
Наступний аналіз
Після завершення оцінки результатів тестування непогано продовжити функ-ционирование програмного продукту. У цьому випадку основне питання звучить образом, що сле-дует: "Внесення яких змін у продукт дозволить поліпшити отримані результати?"
Очікувані результати. Крім рішення основних проблем, ціль ітеративного циклу складається в досягненні вимірних поліпшень по ключових параметрах практичності.
" Знизити час на задачу.
" Підвищити користувальницьку задоволеність.
" Знизити кількість звертань за допомогою.
" Зменшити кількість звітів із проблем.
" Знизити рівень серйозності проблем.
" Збільшити кількість позитивних зауважень.
" Зменшити кількість негативних зауважень.
" Підвищити рівень переваги стосовно конкуруючого продуктам.
Приклад очікуваного результату для часу на задачу показаний на мал. 15.3 (витрати часу на задачу зменшилися між ітераціями 1 і 2). Інші результати можна зобразити аналогічним способом.
Порівняння з конкурентами/попередниками. Корисним методом оцінки ефективності проектних рішень є порівняння з конкуруючими чи попередніми системами, особливо з тими, котрі представляють сучасний технічний рівень. Тут дуже корисне застосування кількісних методів (наприклад, кількість завантажень інформації, підрахунок кількості кроків роботи, час на задачу, користувальницькі помилки і відношення користувачів до тим самим , чи порівнянним користувальницьким задачам).
Даний підхід концентрує увага розроблювачів на тих областях проекту, де можливі удосконалення. Очевидно, ціль полягає в тому, щоб перевершити систему, що обрана для порівняння. Це особливо корисно, якщо оцінна інформація носить діагностичний характер (фіксація витраченого користувачем часу на кожен екран, використовуваний при виконанні призначеної задачі).
"Попрацювати в шкірі користувача". Аналогічно функціональним проблемам, дефекти практичності повинні бути відновлені проектною бригадою. Для того щоб довідатися, де кінцеві користувачі випробують труднощів із продуктом або з інформаційними вікнами і процедурами, застосовуються тестові сценарії.
Що спочатку? Звичайно, насамперед необхідно подбати про тих измене-ниях, що приведуть до реального нарощування можливостей системи. Подібні зміни вимагають більше всього часу і ресурсів для проектування і реалізації, щоб домогтися необхідних удосконалень.
Корисне правило. Концентруйтеся, насамперед , на довгострокових про-блемах. Якщо короткострокову проблему навчання легко перебороти за допомогою из-менений, внесіть необхідні виправлення.
Це також відноситься до полегшення вивчення і розуміння продукту.
SAFCO-фактори. Розглядаючи FUPRіD-факторы, думкою повернетеся до переліку проблем, використовуючи принципи проектування SAPCO. Прийшов час задавати питання, що стосуються рішень.
Як можна зробити продукт більш простим?
" Що користувачу необхідно знати і необхідно робити, щоб застосовувати продукт ефективно?
" Як можна зробити ПІ інтуїтивно більш зрозумілим і саме документируемым?
" Як зробити боле ясними відгуки, що стосуються положення справ?
" Як полегшити виконання часте використовуваних задач на основі застосування продукту?
" Як можна зробити продукт більш простим для вивчення, не караючи користувача за невірні дії?
Як можна зробити продукт більш естетичним?
" Як зробити діалогову графіку, компонування і звуковий супровід більш ясними і приємними для ока і вуха?
" Як можна ефективно використовувати вирівнювання, інтервали, колір і шрифти?
" Як можна визуализировать інформацію до вигоди користувача?
Як зробити продукт більш продуктивним?
" Яким образом використання продукту співвідноситься з попередніми методами?
" чи Існують які-небудь екрани і робочі операції, які можна чи об'єднати виключити?
" Як можна використовувати методи введення параметрів, установлюваних за замовчуванням, і запам'ятовування попередньої інформації, уведеної пользова-телем?
" У чи достатньому обсязі реалізовані функціональні можливості для прикладної області і ПІ?
" чи Відрізняється продукт достатнім рівнем швидкодії і надійності?
Як можна зробити продукт більш приспособляемым?
" Як може продукт підтримувати потреби новачків і досвідчених користувачів?
" чи Досить убудованої в продукт гнучкості для його пристосування до різних користувальницьких переваг у відношенні стилів компонування і взаємодії?
" Яким образом можна удосконалити поводження, зв'язане з розмірами вікон, для нестатків кінцевих користувачів?
Яким образом продукт міг би задовольнити чекання користувачів у відношенні інших можливостей Пи-ориентированного додатка?
" чи Досить додаток терпимий до помилок користувачів?
" Як можна застосувати до продукту методи безпосереднього маніпулювання і безпосереднього введення?
" чи Досить точна і зрозуміла підтримуюча документація?
Проблеми, зв'язані з компонентами ПІ. Найчастіше зустрічаються проблеми, властивим компонентам використовуваного стилю ПІ і проблеми, зв'язані з характером застосування цих компонентів додатком. Проектна бригада повинна вирішити для себе питання: " чиВикористовуються в даному місці додатка належні компоненти для задоволення потреб користувача?" Дане питання можна перефразувати: " чиКоректно використовуються належні компоненти?"
Приклад подібного проблематичного компонента - кнопка лічильника. Дослідження показали, що біля половини користувачів-новачків клацають на символі "стрільця нагору" для збільшення відображуваного значення, а інша половина використовує символ "стрільця вниз" для виконання тієї ж операції. Імовірно, користувачі поводяться подібним чином, тому що така їхня користувальницька модель, що описує по-ведення кнопки в контексті інтегрованого використання з іншими компонентами ПІ (наприклад, смугами прокручування полів і вікон). Деякі користувачі думають, що копка "стрілка нагору" повинна збільшувати значення, у той час як інші користувачі упевнені, що це повиннао робити копка "стрілка вниз". Виходячи з подібної тенденції користувальницького поводження, проектна бригада повинна розглянути питання про тім, наскільки доречно інтенсивне використання даного компонента в додатку, і в яких ситуаціях.
Проблеми, зв'язані з прикладними компонентами. Левина частка проблем, які можна віднести на рахунок ПІ продукту, криється в компонентах Пи-ориентированного додатка. Тому перше, що варто установити у відношенні інтерфейсу, - належне використання стилю ПІ, щоб усунути проблеми типу "занадто багато екранів і занадто багато операцій". Логіка взаємодії допомагає визначити типові маршрути, що проходить користувач при виконанні задачі. Звернетеся до результатів іспитів, щоб з'ясувати, чи відносяться проблеми на рахунок способу використання стилю ПІ. Після цього розгляду підлягають наступні аспекти.
" Передбачувана користувальницька модель.
" Термінологія, піктограми і бітові образи.
" Об'єкти і дії.
" Діалоги і кроки взаємодії.
" Використання пристроїв.
Копії екранів допомагають визначити ясність і погодженість окремих экра-нов, діалогів, піктограм і бітових образів, зворотного зв'язку і повідомлень. Логіка робочих операцій сприяє точному встановленню подальших дій пользо-вателя для досягнення заданого результату стосовно до даного чи екрана діалогу.
Корисне правило. Якщо елементи SAPCO вас не задовольняють, черга може бути за виправленнями.
Визначення і зважування альтернатив. Після того як головні проблеми визначені, звернетеся до проектних альтернатив. Як правило, існує кілька варіантів внесення виправлень у продукт, а відсутність альтернатив може привести до необґрунтованих рішень. Кожна альтернатива оцінюється на предмет того, наскільки добре він інтегрується в існуючу схему продукту. Варіанти зважуються у відношенні до елементів життєвого циклу продукту (наприклад, планам, вимогам, концептуальному проекту, проекту (інтерфейсу й інших компонентів)), реалізації і тестуванню.
А тепер, зробіть це! Альтернативи, що володіють найкращої спільн сба-лансированностью, вибираються і застосовуються до продукту. Цикл повторюється доти , поки вимоги не будуть задоволені.
Швидкий цикл розробки й оптимізація
Реалізація ( чипрототипу продукту) - дуже дорога діяльність, ко-торая є лише засобом досягнення мети, але не самою метою. Нижче приведені деякі підходи і методи, спрямовані на підвищення ефективності реалізації.
Чергове тестування. Один з підходів до оцінки продукту можна назвати відносно пасивним. Сутність цього підходу полягає в тому, що він як би "перекидає" продукт через стіну фахівцям, що проводять тестування прак-тичности. Це підхід "очікує", поки до нього повернуться результати тестування, перш ніж визначити, яким образом удосконалювати продукт. У залежності від характеру виконання тестування між двома "кидками" може пройти два календарних місяці. Звичайно результати наступної ітерації невиразні.
Тут більш доречний активний підхід. Замість напруженого проходження плану-графіку персонал, що бере участь у створенні продукту, активно утягує в оцінку продукту. Члени бригади можуть проводити і відслідковувати тести на практичність. Боротьба знаходяться на "чергуванні" користувачів із продуктом іноді приводить до вироблення кращих альтернатив. Час виявлення проблеми і вироблення рішення зменшується, так що повний цикл займає один день.
Корисне правило. Не турбуйтеся про те, щоб виявити необ'єктивність при аналізі результатів тестування. Важко затверджувати, коли ви доможетеся кількісного і якісного поліпшення продукту.
Запитати дозволу? Навіть будучи прихильниками користувальницької задоволеності, менеджери і лідери розробки не люблять чути про ітеративну розробку продукту. Тому не згадуйте при них про невеликі і легко кон-тролируемых поліпшеннях. Правду говорять, що просити прощення легше, ніж просити дозволу.
Коли зміни, зв'язані з великими витратами, впливають на роботу інших чи фахівців впливають на загальний план-графік, доцільно виробити відповідні проектні плани й установити необхідний контроль. Наприклад, якщо серйозна зміна критерію займає місяць для проектування, реалізації і повторного тестування потенційного рішення, - і безумовно затримає роботу іншої частини проектної бригади - повинне бути отримана згода керівництва і спонсорів щодо планованої роботи. В інших обставинах важлива при-верженность результату і досягнення швидкого циклу розробки.
Критерії оптимізації. Для розробки ПІ проектній бригаді необхідні вимірні цілі і критерії. Крім того, установлення критеріїв необхідно, коли мають місце зміни як рішення проектних чи проблем виявляється можливість оптимізації проектних рішень. Зміни, що приносять незначний кількісний чи якісний ефект, відкладаються, у той час як зміни, що приносять істотні вигоди користувачам, оцінюються більш серйозно.
Загальні критерії для сходження на "вершину" розробки складних продуктів повинні бути чітко визначені і зрозумілі. Осмисливши їхню сутність, керівництво і раз-работчики повинні прийняти критерії. Згода виходить за рамки зовнішнього прийняття критеріїв і означає щиру особисту прихильність розробці всієї проектної бригади.
По одежинці протягай ніжки. Деякі проблеми не піддаються корекції. Прикладом може бути ситуація, коли в користувачів маються чекання з приводу того, як програма повинна працювати - що насправді є нелогічним, нереальним чи нездійсненної.
Корисне правило. Питання, зв'язані з чеканнями, краще розкривати якомога раніше .
Методи спільної розробки. Підтримувати високий рівень участі й активності користувачів у процесі добору результатів і потенційних рішень як і раніше залишається корисною практикою стосовно до ітеративної розробки.
Важливо знати, коли починати (переробка). Проектування часте заходить у тупик. Якщо локально оптимизированный проект не дає бажаних резуль-татов, він відкидається. У противному випадку, невдалий проект уточнюється і шліфується - затрачаються зусилля, що свідомо не приведуть до бездоганної розробки. Кожен проектний компонент оцінюється стосовно критерію достатнього "досконалості", щоб визначити, чи зберегти її в проекті. Якщо існуючий підхід не приводить до бездоганного проекту, відкиньте його. У море проектних альтернатив досить інших риб.
Небезпеки локальної оптимізації. Коли ціль- скорення вершини, не витрачайте занадто багато зусиль на скорення передгір'я! Неоптимальний підхід використовується тоді, коли піднімаються на передгір'я проекту продукту (наприклад, ітеративна розробка функцій продукту, що відіграють незначну роль для продукту в цілому). Важлива частина сходження- зрозуміти розходження між передгір'ям і горою, а потім прикласти максимальні й ефективні зусилля для сходження на вершину.
Важливо знати, коли зупинитися. Перш ніж почати, варто зрозуміти, коли зупинитися. Ітеративний підхід- засіб досягнення мети, і важко пророчити, скільки і якої тривалості ітерацій буде потрібно для досягнення мети. Рейтинг користувальницької задоволеності більшості продуктів показує оцінку десь ледве вище нейтрального значення. Скорення вершини досягається за рахунок організованої, цілеспрямованої і самовідданої роботи керівництва і технічного персоналу. Оскільки більшість конкурентів проводять ітеративне проектування на основі створення прототипів, кількість необхідних ітерацій продовжує рости.
Організаційні і технічні аспекти
Необхідно домагатися реальної прихильності ітеративному підходу як ме-тодологии. Що ще більш важливо, повинна існувати реальна прихильність досягненню результатів стосовно цілям створення продукту.
Прихильність керівництва і технічного персоналу. Керівництво і технічний персонал розробки продукту повинні усвідомлювати, що розробляється і чому. Повинна існувати реальна прихильність виконанню ітерацій для проекту ПО доти , поки вимоги замовника (функції, ПІ, не интерфейсные компоненти, продуктивність і т.д.) не будуть задоволені. Як метод розробки ітеративний підхід буде продовжувати використовуватися на етапі реалізації продукту.
Персонал, що розробляє продукт і прототипи. Якщо бригада по розробці прототипів і бригада реалізації - різні команди, персонал розробки продукту повинний бути цілком інтегрований і брати участь у виконанні ітеративних кроків проекту. У противному випадку, бригада розроблювачів буде выну-ждена застосувати методи реконструкції необхідного проекту інтерфейсу і не интерфейсных компонент для наступної реалізації продукту. Цей метод працює не дуже добре. Альтернатива полягає в тім, щоб зв'язати бригаду прототипирования зобов'язанням у процесі розробки аж до постачання продукту, щоб уникнути втрати знань і підтримати підзвітність.
Підтримка інфраструктури. Багато конкурентів затверджують, що вы-полняют тисячі ітеративних циклів стосовно до функціонального прототипу ПО. Прототип утілює ПІ і проект не интерфейсного ПО. Функціональний прототип зв'язаний з наступними діями.
" Щоденне поширення серед широкого кола учасників проекту.
" Щоденна критика.
" Щоденні виправлення.
" Перехід від однієї ітерації до іншої в міру перетворення прототипу в продукт.
" Неможливість постачання без задоволення усіх вимог.
Після початку робіт зі створення прототипів повинна бути введена соответствую-щая інфраструктура.
Думати наперед. Помнете, що прототип- усього лише інша форма про-граммного забезпечення, що, однак, також піддано змінам. Не завжди обов'язково випливати формальному процесу розробки, але безсистемне хакерство також неприйнятно. Особливо виділите елементи, що беруть участь у процесі ітеративної розробки як прототипу, так і продукту.
Проектування і розробка з думкою про ітеративний підхід. У процесі проектування і розробки майте через ітеративний підхід, думайте про те, як зробити внесення змін у проектні рішення і програмний код більш легким і ефективної. Загальний підхід складається в поділі (сегментуванні) інтерфейсу від проектних рішень і програмного коду для компонентів, відмінних від інтерфейсу.
Проектування і розробка з думкою про альтернативи. Оцінка багатьох проектних альтернатив - це найбільш перспективний варіант розробки. Прагнете полегшити процес додавання проектних альтернатив. Один із придатних методів - уведення перемикачів функцій, доступ до яких легко забезпечити за допомогою користувальницького інтерфейсу.
Еволюційна і нарощувана розробка (проти "великого ривка"). Починати розробку випливає з малого і поступово нарощувати ПО, реалізуючи в першу чергу найбільш важливі і найбільш уразливі функції. Оскільки вкладення засобів у реалізацію на ранній стадії розробки невеликі, роботи з нарощування змін ефективніше, ніж підходи по розробці усіх функцій відразу. Еволюційні зміни, спрямовані на удосконалення проекту, також повинні постійно контролюватися за допомогою вимірних і об'єктивних оцінок з боку кінцевих користувачів.
Питання. Як би ви стали проектувати і розробляти ПО:
" якби вам сказали, що на це буде потрібно більш 100 ітеративних циклів проектування і програмування?
" якщо ви упевнені, що для ПІ і не интерфейсных функцій буде потрібно розглянути більш 25 основних альтернативних варіантів?
Ефективність ітеративної розробки залежить від розроблювачів. Ітерації можуть працювати!
" Для один виведеного на ринок продукту первісні лабораторні іспити практичності показали дуже посередні результати, тобто порядку 4,5 балів по сімох бальній шкалі. Після декількох незначних ітерацій оцінка практичності підвищилася з 5,2 до 6 балів.
" Оцінка одного продукту, що не був випущений, підвищилася за одну ітерацію з 5,5 до 6,3 бали.
Урок полягає в тім, що рівень практичності і задоволеності пользо-вателей можна істотно підвищити за рахунок старанної і цілеспрямованої роботи, прихильності результатам і за рахунок внесення змін, що дозволяють наростити можливості продукту. Якщо раціональні зміни вносяться на ранній стадії розробки продукту, можна домогтися значних результатів, що стосуються прак-тичности і задоволеності.
Продовження обговорення проекту
У вашому розпорядженні відгуки користувачів після початкової оцінки практич-ности, що стосуються концептуальних рішень для проекту. Було організовано і про-ведено незалежне тестування, і у вас маються результати процедур евристичного аналізу і наскрізного контролю. Менеджер проекту має намір переглянути результати
одночасно з вами. Він помітив, що вище керівництво бажало б провести брифінг післязавтра. У вашому розпорядженні біля чотирьох годин для аналізу результатів, оцінки їхньої відповідності вимогам і критеріям, а також для виявлення проблем і потенційних рішень.
Крім того, ви повинні взяти на замітку наступні питання.
" Зміни, який необхідно внести в продукт, щоб задовольнити вимоги і розв'язати всіх проблемы.
" Зміни до проекту, що могли б істотно поліпшити продукт у порівнянні з конкуруючими продуктами.
" Аспекти ПІ, які варто залишити без змін, і аспекти, що підлягають корекції й удосконаленню.
" Наслідку прийнятих рішень для календарного плану проекту, якщо такі маються.
Обґрунтуйте ваші відповіді.
Продовжуйте дослідження через Іnternet.
Питання?
Посилання
Shneіderman В. Desіgnіng the User Іnterface, Addіson-Wesley: Readіng, MA, 1987.
Melkus L.A., and Torres RJ. Guіdelіnes for User of a Prototype іn User Іnterface Desіgn, Human
Factors Socіety Symposіum, 1988.
Torres RJ. Graphіcal User Іnterfaces: Іteratіon, Share 85, Feb. 1995.
Частина 3
Серйозно приймаємося
за справу
Після завершення концептуального проектування перейдемо до наступних эта-пам проектування і розробки ПІ і забезпечення практичності. В міру продовження проекту обсяг роботи, її складність і рівень деталізації зростають. Питань, зв'язаних з людськими й організаційними факторами, також стає усе більше. На даному етапі керівництво вводить у проект основні ресурси, кошти і кращі фахівці.
У третій частині розглядаються наступні теми.
Глава 16. Высокоуровневое проектування (семантика і структура).
Глава 17. Методи специфікації.
Глава 18. Низкоуровневое проектування.
Глава 19. Конструювання, тестування і розгортання продукту.