Проектування інтерфейсу як частина розробки ТЗ

Владислав Головач, Олександр Белишкін

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

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

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

Пропонований підхід дозволяє вирішити наступні проблеми:

Усунути відмінності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх з працею утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа -- замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі -- всі однаково незрозуміло. Наївно припускати, що замовник, легко який підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, що замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати. процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій ». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягти» наверх, якісь можна «засунути»), як, в Врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... от вони всі в наявності - як правило, не спрацьовують, оскільки при відомої спритності в контексті користувача інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.

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

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

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

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

Технічна проблема пов'язана з труднощами прототипирування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипирування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.

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

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.getinfo.ru/