Аналіз вимог замовника до програмного продукуту

Аналіз вимог замовника до програмного продукуту

 

 

Мета роботи.

a. Визначення існуючих поблем та обмежень в програмному продукті (ПП)

b. Розробка варіантів використання ПП

c. Формування вимог замовника на робробку (модернізацію) ПП

 

 

Стадії життєвого циклу розробки програм

ЖЦРП може сильно відрізнятися від проекту до проекту і від керівника проекту до керівника проекту. Проте, зазвичай він складається з наступних стадій:

1. Побудова життєвого циклу
2. Попередній аналіз
3. Аналіз побажань і вимог замовника
4. Уточнення функціональних характеристик
5. Створення технічного проекту (технічного завдання)
6. Реалізація технічного завдання
7. Системне тестування
8. Постpеалізаційна модифікація (доведення)
9. Супровід

Попередній аналіз

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

Що система повинна робити?

ü Чи була чітко сформульована мета створення системи?

ü Чи знає кінцевий користувач, що система дійсно повинна робити?

 

Дуже важливо знайти дійсну мету ПЗ, щоб мати можливість визначити межі проекту. Це необхідно зробити настільки швидко, наскільки це можливо.

 

Моделі даних і словники

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

 

Вихідні форми

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

 

Безпека і управління

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

 

Платформа і оточення

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

1. Мережеві апаратні і програмні ресурси;
2. Типи наявних комп'ютерів;
3. Існуючі операційній системи;
4. Типи принтерів, моніторів, дисководів;
5. Інші периферійні пристрої.

 

Варіанти використання

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

1. Швидкості
2. Безпеки
3. Зовнішньої привабливості
4. Простоти використання
5. Розміру даних і способу їх організації

 

Хто використовуватиме дану систему?

Часто поняття "хто" значно важливіше за поняття "що". Хороше розуміння категорій кінцевих користувачів може дати важливу стартову інформацію для початку створення проекту. Потрібно постійно вивчати, що хочуть кінцеві користувачі ПЗ. Різні типи користувачів можуть мати різні вимоги. Ці вимоги повинні бути описані і враховані при проектуванні програмного забезпечення.

 

Резюме

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

 

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

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

Порядок виконання роботи

1 Отримати індивідуальне завдання у викладача.

2 Згідно методичних вказівок інструкції повести попередній аналіз проблем і обмежень.

3 Розробити схеми для основних варіантів використання ПЗ.

4 Сформувати власний варіант документу «Вимоги до програмного засобу».

5 Оформити і захистити лабораторну роботу.

 

Контрольні питання

1 Назвіть стадії життєвого циклу програмного засобу.

2 З яких етапів складається аналіз вимог замовника?

3 Що таке варіанти використання програмного засобу?

4...

 

Аналіз вимог замовника до програмного продукуту

 

 

Мета роботи.

a. Визначення існуючих поблем та обмежень в програмному продукті (ПП)

b. Розробка варіантів використання ПП

c. Формування вимог замовника на робробку (модернізацію) ПП