Page 115 - 4695
P. 115

цьому причина багатьох проблем знаходиться в технічному за-
        вданні. Для вирішення проблем, що виникають при створенні
        ТЗ і які виявляються при впровадженні, розроблено безліч тех-
        нологій і методів. Проте сама їх кількість свідчить, що жоден
        метод не дає бажаного результату. Крім того, багато методів ма-
        ють принциповий недолік – вони збільшують обсяг окремих ча-
        стин роботи і вимагають серйозних інвестицій в навчання спів-
        робітників (характерний приклад – RUP).
            Проте, існує підхід, який не вимагає особливої кваліфікації
        співробітників, значно полегшує впровадження, не збільшуючи
        обсяг робіт по розробці ТЗ. Сенс підходу може бути поданий
        однією тезою — проектування інтерфейсу не є частина про-
        цесу розробки, а є частина процесу створення специфікацій
        на  систему.  Тут  необхідно  зробити  два  важливих  уточнення
        цієї  тези.  По-перше,  інтерфейс  все  одно  буде  розроблений
        (практика показує, що замовники чомусь неохоче оплачу-
        ють функціональність без інтерфейсу). По-друге, від проек-
        тування інтерфейсу нічого особливого не потрібне — на нього
        можуть бути виділені ті ж ресурси, що і в разі звичайної розро-
        бки. Тобто буде інтерфейс ергономічним чи ні все одно впрова-
        дження буде полегшене; зрозуміло, у разі ергономічного інтер-
        фейсу впровадження буде ще простішим, але такий інтерфейс
        дорожче і довше робиться.
            Пропонований  підхід  дозволяє  розв'язати  наступні  про-
        блеми:
            Погодження поглядів на постановку задачі замовника і ви-
        конавця як частина ТЗ. Специфікації на будь-які складні сис-
        теми дуже абстрактні. А тому їх важко утримувати в голові на-
        віть авторам та розуміти ключовій особі — замовнику. Таке не-
        розуміння кінцевого результату і викликає суб’єктивне сприй-
        няття оцінки роботи розробників ІС. Багато хто з замовників
        припускає, що незрозумілі ТЗ призначені для того, щоб спра-
        вити на них враження та підвищити вартість робіт. Як показує
        досвід одним з можливих шляхів розв’язання цієї важливої про-
        блеми є створення та знайомство замовника з прототипом інте-
        рфейсу. Бо. прототипи інтерфейсу є тим єдиним документом,


                                       114
   110   111   112   113   114   115   116   117   118   119   120