- Структура нормативних документів
3.2 План управління конфігураціями
Управління документацією програмного проекту вимагає значних організаційних навичок, оскільки документація великого проекту являє собою сложноорганизованную систему документів з безліччю перехресних зв'язків, яка схильна до безперервним змін в ході виконання проекту. Управління документацією передбачає підтримку її повноти, узгодженості та включає в себе управління конфігураціями. Повнота документації обумовлюється переліком стандартів, використаних при розробці проекту. Узгодженість документації означає, що набір документів не містить внутрішніх протиріч. Забезпечення несуперечності досягається за рахунок створення цілісної документації, тобто такої документації, в якій кожна специфікація розташовується тільки в одному місці. Рішення проблеми неузгодженості можливо за рахунок використання гіпертекстових документів з підтримкою перехресних посилань. Підтримка конфігурації - це координація різних версій і частин документації та програмного коду. Для відстеження частин проекту необхідно визначити їх межі, тобто ввести елементи конфігурації, під якими, як правило, розуміють класи, значимі набори даних, рідко - окремі функції. Існують спеціальні програмні засоби для управління конфігурацією (наприклад, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion та ін.) [3] .разработал стандарт з планування управління конфігураціями - IEEE 828-1990. Результатом його застосування є план управління конфігураціями (SCMP - Software Configuration Management Plan).
3.3 План управління проектом
Управління проектом полягає в управлінні виробництвом продукту в рамках відведених коштів і часу. Іншими словами, управління проектом - це досягнення балансу між вартістю, можливостями, якістю та термінами [4].
Важливу роль в управлінні програмним проектом має визначення ризиків, які можуть відбутися в ході розробки. Для даного проекту були виділені 3 ризику.
Управління ризиком складається з наступних дій:
- Ідентифікація ризику полягає у фіксації всіх факторів неспокою і здивованості, пов'язаних з проектом, а потім у обмірковуванні інших можливих побоювань.
- Планування усунення.
- Вибір пріоритетів.
- Попередження ризиків - це процес, в ході якого ступінь ризиків знижується або ризики повністю усуваються. Є два способи попередження ризиків. Перший полягає у внесення змін у вимоги проекту, завдяки чому усувається причина виникнення ризику (уникнути ризику). Інший спосіб - розробка деяких технологій та архітектури, що вирішують проблему (усунення ризику).
Ризик №1 - відсутність навичок програмування мовою Java. Приймаючи цей факт, слід визнати, що даний фактор серйозно загальмує проект, але оскільки не всі у проекті присвячено програмуванню, збиток оцінюється числом 7. Вартість усунення ризику висока, оскільки потрібно затратити багато часу на навчання з відволіканням від роботи.
Ризик №2 - відсутність стабільності у проведенні зборів із замовником. Щотижневі збори є основою якісної роботи співробітників. Своєчасні зустрічі дозволяють на ранніх стадіях виявити недоліки і повністю сформулювати всі вимоги до системи, що дозволить скоротити втрати, як часу, так і ресурсів.
Ризик №3 - відсутність базових знань роботи Java і концепцію роботи веб-додатки в цілому. Приймаючи цей факт, слід визнати, що даний фактор серйозно загальмує проект, так як для правильної роботи АС необхідні знання у вище описаних областях. Для усунення цього ризику доведеться вдатися до допомоги фахівців у цих галузях.
3.4 План контролю якості
На додаток до відповідальності індивідуальних розробників і перевіркам робіт їхніх колег, організації визначили процес роздільної систематичної і повної перевірки - контроль якості. У функції контролю якості входять перевірки, інспектування та тестування. Контроль якості повинен починатися з запуску кожного проекту. Найкраще залучати контроль якості і для перевірки правильності використовуваного процесу та актуальності документації [3].
4. Формування вимог
4.1 З-Вимоги
У результаті проведеного аналізу були висунуті вимоги замовника, які представлені у вигляді діаграми use-case UML в додатку Г, а також описані нижче.
. Авторизація в системі
. Реєстрація користувачів
. Введення даних про клієнта
. Заявка на виконання/відмова від послу...
