Оценка длительности проекта

     1.2.3 Системні вимоги

     Функціональні вимоги – функції програмної системи або її компонентів, які описують поведінку системи в тих чи інших ситуаціях. Вони визначають основний напрямок роботи розробника та встановлюють цілі, завдання та сервіси, що надаються системою замовнику [8].

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

     Іншими словами, ці вимоги представляють собою атрибути якості (quality attributes), які повинні бути досягнуті в системі. Стандартом SWEBOK на даний час визначені такі атрибути якості:

• продуктивність (performance);
• надійність (reliability);
• безпека (safety);
• зручність використання (usability);
• переносимість (portability);
• супроводжуванність (maintainability).

     Для розроблюваного ПЗ виділяють наступні типи акторів: Scrum майстер, розробник, власник продукту.

     Всі користувачі повинні мати наступні можливості:

1. авторизації;
2. перегляду журналу продукту;
3. перегляду завдань по розробці, та їх модифікація.

     Власник продукту повинен мати можливість:

1. створення та редагування журналу продукту;
2. перегляду процесу виконання спринту та перегляду діаграм прогресу.

     Scrum майстер повинен мати можливість:

1. управління користувачами: додавання до системи або видалення з неї;
2. створення спринту та його цілей;
3. створення завдань для розробників з розподілом обов’язків;
4. оцінки тривалості проекту.

     В роботі було виділено наступні нефункціональні вимоги до розроблюваної системи:

• продуктивність: користувач повинен отримати відповідь від системи  не більш ніж через 2 сек.;
• безпека: безпеку інформації в системі необхідно забезпечити шляхом розмежування прав користувачів;
• зручність використання: інтерфейс користувача повинен бути зручним та зрозумілим. Також користувачам необхідно надати можливість вибору візуального оформлення його сторінки;
• переносимість: серверна та клієнтська частини системи повинні працювати на UNIX-платформах та операційних системах Windows XP/Vista/7.

     1.3 Огляд існуючих  систем управління  проектами

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

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

     1.4 Постановка задачі автоматизації управління проектами

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

     Для досягнення поставленої мети необхідно  вирішити наступні задачі:

• виконати огляд існуючих методологій розробки ПЗ;
• виконати огляд існуючих інформаційних систем управління проектами;
• провести аналіз проблеми оцінки тривалості проекту;
• розробити математичну модель оцінки тривалості проекту;
• обрати цільову архітектуру ПЗ;
• розробити логічну схему даних;
• розробити опис спроектованого програмного забезпечення у вигляді UML діаграм;

     обрати  програмні засоби для реалізації програмного забезпечення.

2 Розробка математичної моделі для автоматизації процесу управління проектами

     2.1 Теоретичні основи оцінки тривалості проекту

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

       (2.1)

     де:

• х – невідома величина, в даному випадку час;
• α – параметр форми ;
• β – параметр масштабу;
• γ – параметр положення.

 

Рисунок 2.1- Функція розподілу Вейбулла-Гніденко

     2.2 Розробка моделі оцінки тривалості проекту

     Параметр  α моделює додаткову роботу, ініційовану змінами в технічному завданні [9]. Можна визначити загальну кількість вимог в технічному завданні змінною TREQ, а кількість запитів на зміну функціональності, що надійшли за поточну ітерацію, змінною CR. Оскільки на підсумкове час виконання проекту впливають тільки ті підзадачі, які знаходяться на критичному шляху, то при розрахунку TREQ і CR необхідно враховувати тільки ту функціональність, яка відноситься до критичного шляху проекту. Ставлення TREQ і CR буде визначати ступінь мінливості вимог до розроблюваної системи.

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

     Можна представити α, як степінь мінливості системи: 

        (2.3)

     де:

• α – моделювання додаткової роботи;
• CR – кількість запитів на зміну функціональності за поточну ітерацію;
• TREQ – загальна кількість вимог в технічному завданні.

     Параметр  β моделює ефективність роботи персоналу проекту. при побудові метрики оцінки ефективності персоналу автором використовуються фактори витрат масштабу.

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

         (2.4)

     де CON – кількість зв’язків, а NW –  кількість співробітників. 

Таблиця 2.1- Опис факторів масштабу

Фактор	Позначення	Опис
Передбачуваність	PREC	Відображає  наявність в організації досвіду такого типу. Низький рівень означає, що досвід відсутній. Дуже високий – дана область являється знайомою для організації.
Згуртованість команди	TEAM	Відображає рівень взаємодії між учасниками команди розробників.
Зрілість  процесу	РМАТ	Відображає  зрілість процесів в організації  згідно моделі CMM. Розраховується цей фактор по збірнику запитань CMM з розрахунку зваженого середнього значення.

 

     Ефективність персоналу можна виразити через кількість реалізованих завдань IFQ (для поточної ітерації), кількості запланованих завдань PFQ (для поточної ітерації) і факторів витрат масштабу: 

    (2.5) 

     де:

• β – ефективність команди розробників;
• IFQ – кількість реалізованих завдань для поточної ітерації;
• PFQ – кількість запланованих завдань;
• F_PREC – передбачуваність;
• F_TEAM – зв’язність команди;
• F_MAT – зрілість процесів.

       В умовах, коли програмний код  ще не доступний, оцінку складності  має сенс проводити на основі  специфікацій. Можна ввести метрику СРХ, яка виражає складність системи у вигляді добутку кількості сценаріїв використання системи (UC) на кількість класів (в сенсі об'єктно-орієнтованого програмування), на яке була декомпозирована система С, що виражається формулою 2.6: 

CPX = UC×C      (2.6) 

     де:

• CPX – складність системи;
• UC – кількість сценаріїв використання системи;
• C – кількість класів.

     Параметр  γ моделює складність системи, відому на етапі оцінки, і тому може бути виражений через метрику СРХ, яка встановлює відповідність між розміром системи і "классом" проекту, з одного боку, і трудомісткістю розробки системи, з іншого боку. Розроблювана модель враховує такі класи проекту:

• природний: відносно малі і розробляються командами, знайомими з прикладної областю;
• напівінтегрований: системи середнього розміру та складності розробляються групами розробників з різним досвідом;
• "вбудовані системи": виконуються при значних апаратних, програмних і організаційних обмеженнях.

     Складність проекту можливо виразити наступними формулами: 

   (2.7) 

      (2.8) 

     де  :

• γ – складність системи;
• EM_i – фактори вартості системи (необхідна надійність програмного забезпечення, розмір БД, необхідне повторне використання коду, текучість персоналу, використання програмних утиліт);
• SF – фактори, які складають об’єднуючий фактор витрат масштабу (передбачуваність, гнучкість середовища розробки, ризик архітектури, зв'язність команди, зрілість процесу).

     Таким чином було побудовано розподіл випадкової величини тривалості проекту,  який виражається формулами (2.1), (2.3), (2.5-2.8). Всі параметри, що використовуються при розрахунках, є об'єктивними параметрами процесу, що дозволяє автоматизувати оцінку ризику незавершення проекту в строк.

3 Розробка програмного забезпечення

     3.1 Розробка загальної архітектури системи

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

     На  основі проведеного огляду існуючих систем управління проектами, представленого в додатку Б, було обрано архітектуру клієнт-серверну архітектуру з "тонким клієнтом", представлену на рисунку 3.1. 

Рисунок 3.1- Цільова архітектура системи

     3.2 Розробка діаграми  варіантів використання

     У розроблюваній системі є три режими роботи: власника продукту, члена команди розробників та Scrum майстра. Дані режими відрізняються функціональними можливостями. Також слід зазначити, що Scrum майстер має всі функціональні можливості члена команди розробки, включаючи свої власні можливості. За допомогою уніфікованої мови UML на підставі аналізу системних вимог, приведеному вище, було спроектовано  діаграму варіантів використання, представлену на наступному рисунку. 
 

Рисунок 3.2- Діаграма варіантів використання

     3.2 Розробка концептуальної моделі даних

     Методологія IDEF1X (IDEF1 Extended) – це методологія побудови реляційних структур (баз даних), яка відноситься до типу методологій "Сутність-взаємозв'язок" (Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних [11].

     Концептуальну модель даних було побудовано, базуючись на глосарій предметної області, приведеному в додатку В, та за допомогою CASE – засобу Computer Associates Erwin 7.1 та представлено на рисунку 3.3. 
 
 

Рисунок 3.3- Концептуальна модель даних 

     Таблиця Backlog містить інформацію про журнал продукту, яка вноситься та  модифікується власником продукту. Поле таблиці estimated_time включає розраховану тривалість проекту, яка заноситься в таблицю Scrum майстром. Таблиця Artifact включає усі артефакти розроблюваних програмних продуктів, що дозволить накопичувати досвід розробки та використовувати його в майбутніх проектах. Таблиця Task містить опис завдання на  розробку, заповнює її Scrum майстер. Таблиця Sprint включає в себе інформацію про основні стратегічні завдання протягом даного спринту та їх цілі. Таблиця Time_report включає в себе звіти членів команди розробників про виконану роботу, а також коментарі власника продукту. Таблиця User містить інформацію про користувачів системи та їх роль в системі. Об'єднує всі таблиці Task_artifact, котра визначає зв'язок між користувачем завданням, звітом, артефактом та журналом продукту.