Програмісти, що працюють на рівні бітів і байтів



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

Програмісти, що працюють на рівні бітів і байтів



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

 

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

 

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

 

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

 

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

 

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

 

Аналіз вимог замовника

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

 

Може існувати велика кількість способів почати і проводити аналіз вимог, але всі вони повинні приводити до одного і тому ж результату - складання документа, що описує всі вимоги і побажання користувача.

 

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

 

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

 



Последнее изменение этой страницы: 2016-12-12; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.234.221.162 (0.004 с.)