Реферати українською » Остальные рефераты » Проектування інтерфейсу як частину розробки ТЗ


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

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

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

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

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

Запропонований підхід дає змогу вирішити такі:

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

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

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

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

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

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

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

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

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

Схожі реферати:

Навігація