Аналіз побажань і вимог замовника

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

 

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

 

Hайважливіша мета, яку необхідно досягти на цьому першому етапі, - це знайти і зрозуміти, що ж HАСПРАВДІ ХОЧЕ КОРИСТУВАЧ!

Часто це не так просто зробити, оскільки користувач не завжди уявляє, ЩО він дійсно хоче отримати. Банальним прикладом можуть служити користувачі, що замовляють, наприклад, одночасні декілька великих завдань типу "Облік заробітної плати", "Ведення складського обліку", "Складання табеля" і тому подібне, називаючи все це "Бухгалтерією". Якщо проігнорувати даний етап, то проект може врешті-решт бути засуджений на велику кількість доопрацювань, добудовування коду "на коліні" і неодмінне сидіння програмістів по вихідним, щоб зробити клієнтові дійсно те, що він хоче і що не було обумовлено заздалегідь.

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

 

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

 

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

Три найбільш поширені помилки допускаються на даній стадії:

1. Замовники, які приступають до обговорення проекту, не є тими людьми, які ухвалюватимуть остаточне рішення про вимоги до програмної системи (тобто вони не є людьми, що мають повне уявлення про описуване ними завдання).

2. Учасники обговорення з боку розробників не є людьми, що мають відношення до технічної розробки проекту.

2. Технічні фахівці не розуміють користувачів (або розробники погано розбираються в діловодстві і бізнесі, або останню частину життя вони провели не відходячи від монітора, і можуть розмовляти тільки мовою бітів і байтів).

 

Аналіз типу користувачів ПЗ

У одному випадку, користувачі, що беруть участь в обговоренні проекту, описують всі, із їхньої точки зору, деталі майбутнього завдання і залишаються задоволеними думкою, що вони точно виклали всі вимоги і побажання до завдання. На жаль, якщо користувачі, що брали участь в обговоренні не є кінцевими користувачами даної системи, то після складання кінцевого документа, який в деталях описує вирішувану задачу, у людей, що підписують даний документ, виникають питання і які-небудь нові пропозиції по вдосконаленню окремих деталей або їх зміні. Ця ситуація виникає в більшості подібних випадків. Як ви розумієте, така ситуація відкидає процес розробки ПЗ знову назад, на стадію аналізу майбутнього проекту. Маємо втрату часу і коштів.

 

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

 

Третя проблема полягає в тому, що користувачі, які пред'явили мінімальні вимоги до системи на стадії системного проектування і залишили розробку проекту на розгляд виробника, починають обурюватися, що продукт не задовольняє тим або іншим вимогам, а тому працює некоppектно і вимагає переробки.

 

Щоб уникнути описаних вище ситуацій, необхідно зробити наступне:

1. Переконаєтеся, що люди, що беруть участь в обговоренні проекту, є людьми, що детально розбираються в тонкощах вирішуваного завдання.
2. Переконаєтеся, що люди, що беруть участь в обговоренні проекту, зацікавлені в кінцевому результаті.
3. Дати користувачам можливість обговорити всі питання, які тільки можливо. Навіть якщо їх пояснення незв'язні і неоpганізовані, спробуйте з'ясувати, що для користувачів є важливішим в створюваній програмі, а що менш важливим (що вони хотіли б отримати спочатку, а що потім).
4. Постаратися підключити до обговорення людей, які дійсно використовуватимуть створюваний продукт.

 

Керівник проекту

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

 

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

 

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

 

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

 

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