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

ЗМІСТ

Перелік позначень та скорочень

     БД  – база даннях;

     МЖЦ – модель життєвого циклу;

     ПЗ  – програмне забезпечення;

     ПрО – предметна область;

     ПС  – програмна система;

     СКБД – Система керування базами даних;

     IT – Informational Technologies;

     UML – Unified Modeling Language;

     WWW – World Wide Web.

Вступ

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

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

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

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

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

     1.1 Основні проблеми розробки сучасних програмних систем

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

1. Необхідність  розробки програмного  забезпечення

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

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

1.1.2 Огляд основних моделей життєвого циклу програмного забезпечення

     Модель  життєвого циклу ПЗ – структура, яка визначає послідовність виконання та взаємозв’язку процесів, дій та задач протягом життєвого циклу.

     Існує три основних моделі життєвого циклу  ПЗ:

• каскадна модель;
• спіральна модель;
• ітераційна модель.

     Каскадна модель – це модель послідовної розробки програмного забезпечення.

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

     Суть  ітераційної моделі полягає у виконанні робіт паралельно з безперервним аналізом отриманих результатів і коригуванням попередніх етапів роботи. При такому підході в кожній фазі проходить повторюваний цикл: Планування – Реалізація – Перевірка – Оцінка. Основними перевагами такого підходу є зниження ризиків і організація ефективного зворотного зв'язку зі споживачем.

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

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

3. Огляд основних методологій розробки програмного забезпечення

     Гнучка  розробка програмного забезпечення (Agile software development) – це клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та рішення еволюціонують через співпрацю між самоорганізованими багатофункціональними командами.

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

     Scrum – методологія управління проектами для гнучкої розробки програмного забезпечення. Scrum робить акцент на якісному контролі процесу розробки. Ця методологія включає набір методів і попередньо визначених ролей [3].  

     

Рисунок 1.1- Методологія Scrum 

     Весь  проект ділиться на ітерації (спринти) тривалістю 15 - 30 днів кожний. Вибирається список функцій системи, які планується реалізувати протягом наступного спринту. Найважливіші умови – незмінність певних функцій під час виконання однієї ітерації і суворе дотримання термінів випуску чергового релізу, навіть якщо до його випуску не вдасться реалізувати весь запланований функціонал. Керівник розробки проводить щоденні 20 хвилинний наради, які так і називають – Scrum, результатом яких є визначення стану роботи, труднощів та плану на наступний день. Такі наради дозволяють постійно відстежувати хід проекту, швидко виявляти проблеми, що виникли і оперативно на них реагувати. 

     Екстремальне  програмування (Extreme Programming, XP) – найбільш відома з гнучких методологій. Складається з 12 основних принципів: гра в планування, переробки коду (refactoring), короткі релізи, метафори, простий дизайн, колективне володіння кодом, програмування парами, 40-годинний робочий тиждень, постійна присутність замовника і стандарти коду. При використанні XP ретельне планування розробки ПЗ замінюється на постійну присутність замовника. Низька формалізація розробки зазвичай не йде далі хорошого коментування коду, що дозволяє скоротити велику кількість часу розробки, а отже, знизити загальну вартість розробки. При цьому істотну увагу приділяється тестуванню [4]. Найчастіше для кожного модуля системи спочатку пишеться тест, який продовжує виконуватися протягом всієї розробки після будь-якої зміни коду.

     Rational Unified Process (RUP) – методологія розробки програмного забезпечення створена компанією Rational Software. RUP використовує ітеративну модель розробки. Ітеративна розробка дозволяє швидко реагувати на мінливі вимоги, виявляти і усувати ризики на ранніх стадіях проекту, а також ефективно контролювати якість створюваного продукту.

     RUP визначає життєвий цикл проекту,  що складається з чотирьох фаз:

1. Початкова фаза.
2. Фаза уточнення.
3. Фаза конструювання.
4. Фаза впровадження.

 

Рисунок 1.2- Життєвий цикл розробки в RUP

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

     Microsoft Solutions Framework (MSF) – методологія розробки програмного забезпечення, запропонована корпорацією Microsoft. MSF являє собою узгоджений набір концепцій, моделей та правил.

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

4. Чинники вибору методології розробки програмного забезпечення

     Не  існує якоїсь однієї, єдино правильної методології, оптимальної для будь-якого проекту. У кожному конкретному випадку правильний вибір методології розробки залежить від ряду факторів:

• масштабу проекту;
• критичність проекту;
• кількості і розподілу повноважень учасників проекту;
• ступені новизни проекту;
• очікуваної тривалості проекту;
• вимог замовника.

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

     1.2 Докладний опис області управління проектами

     1.2.1 Мотивований вибір методології розробки програмного забезпечення

     На  основі проведеного аналізу основних методологій розробки ПО, представленого в додатку А, мною було обрано методологію Scrum як основу для проектування програмної системи управління проектами.

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

     Також важливою особливістю даної методології є те, що Scrum Команди є самоорганізованими і крос функціональними [3]. Самоорганізовані Команди самі обирають, як їм найкращим чином виконати роботу, та не чекають вказівок від людей, що не входять до їх складу. Кросфункціональним Командам властиві всі необхідні навички, щоб виконати роботу і не залежати від людей, що не входять до їх складу. Командна модель Скраму створена для оптимізації гнучкості, креативності та продуктивності.

     1.2.2 Опис бізнес-процесів області управління проектами

     Бізнес-процес – це сукупність взаємопов'язаних заходів або завдань, спрямованих на створення певного продукту або послуги для споживачів [7].

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

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

     Команда розробників:

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

     Scrum майстер:

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