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

ЗМІСТ

• Вступ
• Розділ 1. Ініціалізація проекту
• 1.1 Дослідження проблеми створення
• 1.2 Розробка альтернатив вирішення проблеми створення
• 1.3 Вибір моделі життєвого циклу розробки програмного забезпечення
• 1.4 Опис продукту проекту та його функціонування
• Розділ 2. Планування проекту
• 2.1 Планування змісту проекту
• 2.2 Складання розкладів
• 2.3 Планування проектних витрат
• 2.4 Планування ризиків проекту
• 2.5 Додатковий план проекту
• Розділ 3. Реалізація проекту
• 3.1 Моніторинг та прогнозування виконання проекту
• 3.2 Оцінка прогресу проекту для ключових зацікавлених осіб
• 3.3 Охорона праці та безпека в надзвичайних ситуаціях при виконанні проекту
• Висновки
• Список використаної літератури

ВСТУП

Актуальність дослідження. Метод освоєного обсягу (англ. Earned Value Technique, Earned Value Management) — ряд методів, об'єднаних під загальною назвою, що використовуються для вимірювання та контролю ефективності виконання проектів. Метод заснований на використанні ряду числових показників, що розраховуються по ходу проекту. За набором цих показників можна стежити за проектом і вживати заходів по усуненню недоліків своєчасно. Але візуальне представлення інформації дозволяє краще представити багатовимірну інформацію про проект, ніж текст або таблиця. Прикладом візуального представлення є графік. Графіки використовуються для демонстрації трендів у даних з течією часу.

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

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

Мету роботи — розробити проект розробки програмного засобу моніторингу реалізації проектів на основі аналізу освоєного обсягу.

Об'єкт дослідження — процеси управління проектами з розробки програмного забезпечення.

Предмет дослідження — процеси управління проектами для управління проектами.

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

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

Розділ 1. Ініціалізація ПРОЕКТУ

1.1 Дослідження проблеми створення

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

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

Найбільш поширеними проблемами, що виникають в процесі розробки програмних засобів (ПЗ), вважають:

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

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

Недолік контролю. Без точної оцінки процесу розробки зриваються графіки виконання робіт і перевищуються встановлені бюджети. Складно оцінити обсяг виконаної і залишилася роботи.

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

Недолік трасування.

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

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

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

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

Недостатня надійність. Найскладніший процес — пошук і виправлення помилок у програмах на ЕОМ. Оскільки число помилок в програмах заздалегідь невідомо, то заздалегідь невідома і тривалість налагодження програм і відсутність гарантій відсутності помилок в програмах. Слід зазначити, що залучення доказового підходу до проектування ПЗ дозволяє виявити помилки в програмі до її виконання. У цьому напрямку багато працювали Кнут, Дейкстра і Вірт. Професор Вірт при розробці Паскаля і Оберона за рахунок суворості їх синтаксису домігся математичної доказовою завершаємості і правильності програм, написаної на цих мовах.

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

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

Дана проблема не є проблемою, що відноситься виключно до розробки ПЗ. Гарантія якості - це проблема вибору постачальника товару (не продукту).

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

кінцевий результат проекту з розробки програмного забезпечення нематеріальний;

недостатність накопиченого в цій галузі досвіду;

швидка зміна використовуваних в проекті технологій;

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

1.2 Розробка альтернатив вирішення проблеми створення

Альтернативами вирішення існуючої проблеми буде наступне:

— програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу;

— програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу з будуванням графіків;

— програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу з будуванням графіків та завданням відхилень.

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

Перша альтернатива дає нам лише переваги традиційного аналізу освоєного обсягу. Друга надасть більш широкий профіль моніторингу. Третя дасть більш широку картину ніж перша і друга, так як за допомогою відхилень ми будимо бачити прийнятні нам межі. Для того щоб вибрати оптимальну альтернативу скористаємося методом багатокритеріальних шкал. Для 3 варіантів вирішення проблеми розставимо бали від 1−10 в залежності від ступеня задоволення заданим критеріям. Найбільш важливими з них є наступні чотири:

— інноваційність;

— сприйняття інформації;

— якість інформації;

— ефективність.

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

Таблиця 1.1 Оцінка проектних альтернатив

1.3 Вибір моделі життєвого циклу розробки програмного забезпечення

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

1. Проаналізуємо наступні відмітні категорії проекту, поміщені в таблицях: Вимоги. Категорія вимог (таблиця 1.2) складається з питань щодо вимог, які пред’являє користувач до проекту. У термінології їх іноді називають властивостями системи, яка буде підтримуватися даним проектом.

Таблиця 1.2 Вибір моделі життєвого циклу на основі характеристик вимог

Команда розробників. По можливості, до складу команди розробників найкраще відібрати персонал ще до того, як буде обрано модель життєвого циклу. Характеристики такої команди (таблиця 1.3) відіграють важливу роль в процесі вибору, оскільки вона несе відповідальність за вдале виконання циклу і може надати допомогу в процесі вибору.

Таблиця 1.3 Вибір моделі життєвого циклу на основі характеристик учасників команди розробників

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

Таблиця 1.4 Вибір моделі життєвого циклу на основі характеристик колективу користувачів

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

Таблиця 1.5 Вибір моделі життєвого циклу на основі характеристик типу проектів і ризиків

2. Відповівши на всі питання, наведені для кожної категорії, мною була обрана модель швидкої розробки додатків RAD (Rapid Application Development) [6], яка найбільш задовольняє проект.

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

Це забезпечується наявністю засобів розробки графічного інтерфейсу користувача і кодогенераторів. Такі інструментальні засоби, як Oracle Designer/2000, JavaJbuilder 3, Linux, Visual C, Visual Basic 6, SAS, й інші можна використовувати в якості засобів для швидкої розробки додатків. У нашому випадку вибір припав на C # («Сі шарп»).

Характерною рисою RAD є короткий час переходу від визначення вимог до створення повної системи. Метод ґрунтується на послідовності ітерацій еволюційної системи або прототипів, критичний аналіз яких обговорюється з замовником. У процесі такого аналізу формуються вимоги до продукту. Розробка кожного інтегрованого продукту обмежується чітко визначеним періодом часу, який, як правило, становить 60 днів і називається тимчасовим блоком. Фактори, що дозволяють створити систему за 60 днів, причому без шкоди якості, включають в себе використання потужних інструментальних засобів розробки, високий рівень фактора повторного використання, а також осмислені та виділені ресурси.

Переваги моделі RAD. При використанні моделі RAD щодо проекту, для якого вона в достатній мірі прийнятна, проявляються такі переваги:

— час циклу розробки скорочується завдяки використанню потужних інструментальних засобів;

— потрібна менша кількість фахівців (оскільки розробка системи виконується зусиллями команди, обізнаною в предметної області);

— існує можливість зробити швидкий початковий перегляд продукту;

— зменшуються витрати (завдяки скороченим часу циклу і удосконаленої технології, а також меншій кількості задіяних в процесі розробка);

— завдяки принципу тимчасового блоку зменшуються витрати і ризик, пов’язаний з дотриманням графіка;

— забезпечується ефективне використання наявних засобів і структур;

— постійна присутність замовника зводить до мінімуму ризик незадоволення продуктом і гарантує відповідність системи комерційним потребам і надійність програмного продукту в експлуатації;

— до складу кожного часового блоку входить аналіз, проектування та впровадження (фази відділені від дій);

— інтеграції констант запобігають виникненню проблем і сприяють створенню зворотного зв’язку зі споживачем;

— основна увага переноситься з документації на код, причому при цьому справедливий принцип «отримуєте те, що бачите» (What you see is what you get, WYSIWYG);

— в моделі використовуються наступні принципи та інструментальні засоби моделювання: ділове моделювання (методи передачі інформації, місце генерування інформаційних потоків, ким і куди прямує, яким чином обробляється); моделювання даних (відбувається ідентифікація об'єктів даних і атрибутів, а також взаємозв'язків); моделювання процесу (виконується перетворення об'єктів даних); генерування програми (методи четвертого покоління);

— повторне використання компонент вже існуючих програм.

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

— непостійне участь користувача може негативно позначитися на кінцевому продукті (тобто якщо користувачі не можуть постійно брати участь в процесі розробки протягом усього життєвого циклу, це може негативно позначитися на кінцевому продукті);

— при використанні цієї моделі необхідна достатня кількість висококваліфікованих розробників, (які вміють скористатися вибраними інструментальними засобами розробки для прискорення часу розробки);

— використання моделі може виявитися невдалим у разі відсутності придатних для повторного використання компонент;

— можуть виникати труднощі при використанні моделі спільно з спадковими системами і декількома інтерфейсами;

— виникає потреба в системі, яка може бути змодельована коректним чином;

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

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

— при використанні моделі «наосліп» на витрати і дату завершення роботи над проектом обмеження не накладаються;

— команди, які розробляють комерційні проекти за допомогою моделі RAD, можуть «затягти» розробку програмного продукту до такої міри, що його поставка кінцевому користувачеві буде під великим питанням;

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

Область застосування моделі RAD. Менеджер проекту може бути впевнений в тому, що модель RAD підходить для застосування в конкретній ситуації в разі, якщо є в наявності деякі з наведених нижче умов-причин:

— в системах, які піддаються моделюванню (тих які засновані на використанні компонентних об'єктів), а також в масштабованих системах;

— в системах, вимоги для яких в достатній мірі добре відомі;

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

— коли користувачі хочуть брати активну участь у використанні автоматичних інструментальних засобів;

— при невисокій ступеня технічних ризиків;

— при виконанні проектів, розробка яких повинна бути виконана в скорочені терміни (як правило, не більше, ніж за 60 днів);

— в системах, які можна помістити в тимчасовій блок з метою забезпечення функціональних можливостей на послідовній основі;

— коли придатні до повторного використання частини можна отримати з автоматичних сховищ програмних продуктів;

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

— коли витрати і дотримання графіка не є найважливішим питанням (наприклад при розробці внутрішніх інструментальних засобів);

— в інформаційних системах.

1.4 Опис продукту проекту та його функціонування При зустрічах з замовником були обрані шаблони головного та інших вікон програми. Головне вікно повинне виглядіти так (рис. 1.1):

Для того щоб втілити в реальність цю задачу я вибрав мову програмування C#(вимовляється сі шарп). Так як на ній можна втілити всі надані завдання повною мірою. Працює на платформі Microsoft. NET Framework. Перейнявши багато що від своїх попередників — мов C + +, Java, Delphi, Модула і Smalltalk — С #, спираючись на практику їх використання, виключає деякі моделі, що зарекомендували себе як проблематичні при розробці програмних систем, наприклад, C # не підтримує множинне наслідування класів (на відміну від C++)[12].

Щоб втілити всі вимоги замовника з програмного засобу мені було необхідно вивчити побудову таблиць і графіків у вибраній мові програмування.

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

РОЗДІЛ 2. ПЛАНУВАННЯ ПРОЕКТУ

2.1 Планування змісту проекту

2.1.1 Мета проекту

Мету роботи визначимо за допомогою SMART метода.

Specific (конкретність). Розробити програмне забезпечення, для моніторингу реалізації проектів на основі аналізу освоєного обсягу, яке розраховує показники освоєного обсягу та будує графіки моніторингу та графіки відхилень у проекті.

Measurable (вимірюваність). Автоматизація розрахунку показників значно скоротить час обробки даних і підготовки аналітичних і статистичних звітів.

Точність розрахунку показників дозволить економити кошти.

Представлення інформації у вигляді графіків полегшить прийняття рішень керівника про подальші дії .

Agreed Upon (досяжність). Для створення програмного продукту є всі необхідні вихідні дані, відповідний інструментарій для розробки програмних продуктів і технічний персонал.

Realistic (реалістичність). Автоматизований процес розрахунку показників освоєного обсягу із будуванням графіків дозволить якісно поліпшити контроль діяльності учасників проекту і полегшить прийняття управлінських рішень.

Time-Framed (часова визначеність). Тривалість проекту не повинна перевищувати 2х місяців. Програмне забезпечення, для моніторингу реалізації проектів на основі аналізу освоєного обсягу має бути написане до 1 червня 2012 р.

2.1.2 Трирівнева WBS-структура

WBS (work breakedown structure) — це ієрархічна структура, побудована з метою логічного розподілу усіх робіт з виконання проекту і подана у графічному вигляді. Це сукупність декількох рівнів, кожний з яких формується в результаті розподілу роботи попереднього рівня на її складові. Елементом найнижчого рівня є група робіт, або так званий робочий пакет (work package).

WBS надає ієрархічний формат, який допомагає розробнику в:

— структуризації робіт на основні компоненти і підкомпоненти;

— спрямованості діяльності на досягнення всього комплексу цілей;

— розробці системи відповідальності за виконання робіт проекту;

— розробці системи звітності та узагальнення інформації по проекту.

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

Рис. 2.1. Трирівнева WBS-структура проекту

Так як в програмному засобі Suretrak v1.5 максимальна припустима кількість робіт, які можна використати при побудові календарного графіку дорівнює 25, це обмежує можливість поділити всі пакети робіт на окремі роботи. Тому представимо приклад декомпозиції пакету робіт на роботи на прикладі пакету Р. 3.1 «Створення форми реєстрації проекту» (табл. 2.1).

Таблиця 2.1 Приклад опису пакета робіт

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

WBS дозволяє звести цілі проекту до ієрархії засобів їх досягнення, або, що те ж, отримання результатів, передбачених проектом. WBS є так само інструментом, що дозволяє керівнику проекту отримати опис кінцевого результату (продукту, послуги) проекту і всіх підпроектів, в результаті яких буде досягнуто запланований результат. Далі WBS може розділятися (і результати підрозділятися) на частини для спеціалізації видів і обсягів робіт учасників проекту, координації їхніх дій і закріплення відповідальності за обсягами робіт, аж до рівня, що забезпечує керованість та належне адміністрування проекту. WBS забезпечує виявлення робіт, необхідних для досягнення цілей проекту. При такому підході проект визначається в термінах ієрархічно взаємопов'язаних орієнтованих на результат елементів (пакетів робіт — комплексів робіт, згрупованих за заданим підставах / критеріям). Кожен наступний рівень декомпозиції забезпечує послідовну деталізацію змісту проекту, що дозволяє робити оцінку виконаних обсягів робіт, освоєних грошей і виконання за термінами. На нижніх рівнях пакетам робіт відповідають порівняно менші обсяги робіт. Це спрощує оцінку відсотка виконання і дає можливість більш чітко визначати дії, необхідні для досягнення цілей проекту. Запропонований підхід декомпозиції робіт формує необхідну основу для визначення вимірних показників (трудомісткості, вартості), а також дозволяє з високим ступенем достовірності говорити про те, що цілі, пов’язані з даним пакетом робіт можуть і будуть досягнуті.

Таблиця 2.2 Перелік пакетів робіт проекту

2.1.3 Побудова ОBS-структури проекту Організаційна структура проекту (ОBS) — це структура яка стосується тільки внутрішньої організаційної структури проекту і влаштована таким чином, щоб співвідносити пакети робіт з виконуючими організаційними одиницями. На рис. 2.2 зображено організаційну структуру розроблюваного проекту Рис. 2.2. Організаційна структура проекту розробки програмного забезпечення, для аналізу фінансових і економічних показників проекту

2.2 Складання розкладів

Метод передування (PDM) або «вершина — робота» відображають мережну модель в графічному вигляді як безліч вершин, відповідних робіт, пов’язаних лініями, які представляють взаємозв'язки між роботами. Метод передування оперує такими типами залежностей передування — наслідування: «фініш-старт», «старт-фініш», «старт-старт», «фініш-фініш». На рис. 2.3 зображено PDM-сітку проекту, де вказано назви робіт, їх послідовність та тривалість.

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

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

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

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

Результати розрахунку тривалості проекту методом критичного шляху представлені на рис. 2.4.

Графік Ганта. Діаграма Ганта (англ. Gantt chart, також стрічкова діаграма, графік Ганта) — це популярний тип стовпчастих діаграм (гістограм), який використовується для ілюстрації плану, графіка робіт з якого-небудь проекту. Є одним з методів планування проектів. Використовується в додатках з управління проектами.

Перший формат діаграми був розроблений Генрі Л. Гант в 1910 році.

По суті, діаграма Ганта складається зі смуг, орієнтованих вздовж осі часу. Кожна смуга на діаграмі представляє окрему задачу у складі проекту (вид роботи), її кінці - моменти початку та завершення роботи, її протяжність — тривалість роботи. Вертикальною віссю діаграми служить перелік завдань. Крім того, на діаграмі можуть бути відзначені сукупні завдання, відсотки завершення, покажчики послідовності і залежності робіт, мітки ключових моментів (віхи), мітка поточного моменту часу «Вчора» та інші.

Ключовим поняттям діаграми Ганта є «Віха» — мітка значимого моменту в ході виконання робіт, спільний кордон двох або більше завдань. Віхи дозволяють наочно відобразити необхідність синхронізації, послідовності у виконанні різних робіт. Віхи, як і інші кордону на діаграмі, не є календарними датами. Зрушення віхи призводить до зрушення всього проекту. Тому діаграма Ганта не є, строго кажучи, графіком робіт. І це один з основних її недоліків. Крім того, діаграма Ганта не відображає значущості або ресурсоємності робіт, не відображає сутності робіт (області дії). Для великих проектів діаграма Ганта стає надмірно великовагової і втрачає всяку наочність [15 стор. 105−109].

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

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

При розробці проекту я використовував програмний продукт Suretrack. Цей програмний продукт орієнтований на невеликі проекти, під проекти, роботу конкретних виконавців з фрагментами проектів. SureTrak має ті ж кошти, що й P3 у плані організації проекту по кодах і фільтрації інформації, установки обмежень і розрахунку розкладу, але в той же час існує ряд обмежень і додаткових можливостей. З обмежень слід відзначити відсутність коштів багатопроектного управління та фрагментації проектів, меншу розмірність проектів, більш скромні засоби створення звітів. Проте в SureTrak з’явилися календарі ресурсів і, як наслідок, можливість розрахунку тривалості робіт з урахуванням узгодження календарів виконавців (очікується, що календарі ресурсів з’являться і в наступній версії P3). Крім того, у ресурсів з’явилася додаткова категорія — дохід. SureTrak відрізняється від всіх інших продуктів Primavera тим, що він повністю русифікований і поставляється разом з керівництвом для користувача російською мовою.

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

Для побудови графіка Ганта скористаємося програмою SureTrak 1.5

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

2.3 Планування проектних витрат

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

PPOG — Інженер-програміст Корженко С. А.

ENER — електроенергія

Інженер-програміст у нашому випадку має вартість 0. Вартість електроенергії розрахуємо з наступних суджень:

— вартість 1кВт електроенергії у Луганську (0.55 грн.);

— кількість споживаної в день електроенергії для ноутбука ASUS (20 В, 5A) складе 20 * 5 = 100 ВТ, так як 100 це максимум, а в середньому в 2−3 рази менше, тоді 100/2 і помножимо на кількість робочих годин (8) — 0.4кВт / ч. Виходячи з цього вартість електроенергії дорівнює 0,4 * 0,55 = 0,22 грн. в день. Для проектів будь-якого роду неминучим є серйозне планування витрат і їх оцінка, дотримання яких може розглядатися для менеджменту проектів як запорука успіху [10, с.29−42]. При цьому слід виходити з того, що виробляється надійна і професійна підготовка проекту з ефективним планеруванням витрат. Співвіднесені з проектом дані із стадії концепції і визначення переносяться як заснувавши планерування і оцінку витрат. Надійне планерування витрат і вживання стандартів, що діють планування навіть в екстремальному випадку приводить до надійності самого процесу витрат. Поняття надійності тут, зрозуміло, є відносним, оскільки навіть при детермінантних проектах, наприклад технічних, будівельних проектах і т. п., розмах коливань витрат до ± 15% всюди ще вважається терпимим, навіть якщо для інвестора і виробленого фінансування внаслідок цього можуть виникнути серйозні проблеми. Тим самим, при планеруванні проектних витрат пред’являються серйозні вимоги до компетентності і досвіду фахівців для того, щоб були знайдені реалістичні величини витрат.

Розглянемо ресурсний профіль проекту з вартості всіх ресурсів рис 2.6.

На рисунку 2.6 ми бачимо чіткий графік проекту з вартості всіх ресурсів. Розглянемо ресурсний профіль проекту за кількістю всіх ресурсів на рис 2.7.

На рисунку 2.7 чітко виражений ресурсний профіль проекту за кількістю всіх ресурсів.

2.4 Планування ризиків проекту

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

Основні п’ять ризиків проектів розробки програмного забезпечення:

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

Ризик 2: поява нових вимог. В процесі просування проекту з’являються все нові вимоги, які можуть порушити всі терміни та оцінки.

Ризик 3: декомпозиція специфікації. При старті процесу кодування та інтеграції стає ясно, що специфікація неповна і містить конфліктні вимоги.

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

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

2.5 Додатковий план проекту

Складемо реєстр ризиків проекту (табл. 2.3). Імовірність настання ризику виміряємо в балах від 1 до 5. Вплив ризику на проект виміряємо в балах від 1 до 5. Рівень ризику може бути: високий, середній, низький залежно від імовірності настання і ступеня впливу ризику. Ризики з найбільшою ймовірністю настання і високим ступенем впливу будуть мати високий рівень, ризики ж з найменшою вірогідністю настання і низьким ступенем впливу відповідно низький рівень.

Таблиця 2.3 Реєстр ризиків

розділ 3. РЕАЛІЗАЦІЯ ПРОЕКТУ

3.1 Моніторинг та прогнозування виконання проекту

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

— порівняння поточного ходу виконання проекту з планом управління проектом;

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

— аналіз, відстеження та моніторинг ризиків проекту для своєчасного їх

— виявлення, звіту про їх статус і контролю виконання планів реагування на ризики;

— ведення аж до завершення проекту достовірної та актуальної інформаційної бази, що стосується продуктів проекту, і супутньої документації для цих продуктів;

— надання інформації для складання звітів про поточний стані, оцінки прогресу і прогнозування;

— надання прогнозів для оновлення поточних даних про витрати і

— розкладі проекту;

— моніторинг обробки схвалених змін у міру їх появи.

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

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

Відповідальність за контроль над ходом виконання проекту лежить на керівнику проекту від замовника. Керівник проекту зобов’язаний аналізувати звітність по проекті, відслідковувати й реагувати на відхилення й зміни в проекті.

Контроль над ходом реалізації проекту здійснюється на основі розроблених на стадії планування проекту документів:

— графік робіт із проекту,

— бюджет проекту,

— ресурсний профіль,

— план управління ризиками тощо.

Моніторинг виконання кожного завдання проекту повинен включати:

1. Відстеження: збір і документування фактичних даних; визначення в офіційних і неофіційних звітах ступеня відповідності фактичного виконання запланованим показникам.

2. Аналіз: оцінка поточного стану робіт і порівняння досягнутих результатів із запланованими; визначення причини й шляхів впливу на відхилення від виконання плану.

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

Роботи в проекті, що вимагають поділи на частині:

— настроювання системи відповідно до вимог підприємства;

— доробка системи;

— тестування системи;

— експериментальна експлуатація;

— промислова експлуатація.

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

Розглянемо базовий (цільовий) графік для пакетів робіт проекту на рис 3.1.

Рис. 3.1. Базовий (цільовій) графік для пакетів робіт проекту

На рис. 3.1 ми бачимо Базовий графік пакетів робіт проекту. Також шкалу продуктивності проекту. Для оцінки стану проекту на дату моніторингу користаємось методом освоєного обсягу. Метод освоєного обсягу (Earned Value analysis) — найбільш використовуваний в практиці спосіб управління проектом по вартісним параметрам. Дозволяє керівнику проекту та проектної команді відслідковувати відхилення обсягу і вартості робіт фактично виконаних до даного моменту часу від того обсягу і вартості, які були запланована на даний момент часу. Принципи методу освоєного обсягу можуть бути застосовані до будь-яких проектах і в будь-якій галузі.

Метод оперує такими основними показниками:

PV (Planned value) — запланована вартість робіт за аналізований проміжок часу (плановий обсяг)

EV (Earned value) — запланована вартість фактично виконаних робіт за аналізований проміжок часу (освоєний обсяг)

AC (Actual cost) — фактична вартість робіт На основі перерахованих показників визначаються відхилення:

SV (Schedule variance) — відхилення від календарного графіка по запланованої вартості. Значення SV дорівнює нулю коли проект завершений, тому що всі заплановані обсяги освоєні. SV = EV — PV

CV (Cost variance) — відхилення фактичної вартості виконаних робіт від їх запланованої вартості. Важливий показник, що відображає перевитрату коштів. CV = EV — AC

Показники SV і CV відображають поточний стан проекту (дотримання бюджетів і термінів).

Існують і відносні показники:

SPI (Shedule perfomance index) — індекс виконання календарного плану. Використовується для прогнозу завершення проекту. Значення менше 1.0 показує, що завершено менше робіт ніж заплановано. Значення більше 1.0 показує, що роботи виконуються з випередженням. У першу чергу необхідно аналізувати роботи, що знаходяться на критичному шляху, що б розуміти з випередженням або з запізненням буде завершений проект. SPI = EV / PV

CPI (Cost perfomance index) — індекс вартості виконаних робіт. Визначає ефективність використання бюджету по виконаним роботам. Значення менше 1.0 показує, що рівень витрат випереджає обсяг виконаних робіт. Значення більше 1.0 показує, що рівень витрат менше фактичного обсягу виконаних робіт. CPI = EV / AC. Розглянемо Графік освоєного обсягу проекту станом на дату на рис 3.2.

Рис 3.2. Графік освоєного обсягу проекту станом на 25 травня 2012

На рисунку 3.2 ми бачимо що 25 числа проект затримається. Розглянемо графік показників освоєного обсягу проекту станом на дату.

Рис 3.3. Графік показників освоєного обсягу проекту станом на 25.05.12

На рисунку 3.3 видно що на 25 травня показники освоєного обсягу дорівнює 7, Планові (бюджетні) витрати інвестиційного проекту (BCWS) рівні 6а Cost дорівнює 9.

На рисунку 3.4 ми бачимо віхи виконання за звітний період проекту на основі аналізу освоєного обсягу на 25.05.2012.

Таблиця 3.1 Показники освоєного обсягу проекту

За результатами розрахунків можна зробити висновок про відставання проекту від запланованих строків і незначну перевитрату коштів на дату проведення моніторингу. Перевитрата коштів становить 22% від ризикового резерву проекту, що складає 5% від загального бюджету. Тому не має сенсу переглядати бюджет та резерви коштів проекту.

На дату моніторингу виконано 89% проектних робіт. Проект затримається через відсутність своєчасних зустрічей із замовником. Через зайнятість замовника і не отримання наступного завдання немає можливості рухатися далі. Орієнтовна дата здачі проекту 06.06.2012 р. Тобто проект затримається на 2−3 дня.

3.3 Охорона праці та безпека в надзвичайних ситуаціях при виконанні проекту

Робота фахівця з управління проектами пов’язана із наступною діяльністю:

— координація виконання проекту в інтересах замовника з максимальної ефективністю;

— розроблення схеми організації робіт, здійснення розподілу проекту по пакетах робіт і складання графіку виконання;

— забезпечення розробки документації проекту та контроль документообігу;

— визначення принципів організації взаємодії між зацікавленими сторонами проекту, порядку внесення змін до проекту;

— визначення вимог до якості в проекті;

— забезпечення управління всіма адміністративними та фінансовими аспектами проекту, узгодження змін та координація дій із замовником;

— узагальнення інформації по звітах проекту та складання звітів для замовника;

— підготовка необхідних аналітичних матеріалів для проведення узагальнених нарад між замовником, інвестором та виконавцем проекту;

— організація архівації документів проекту.

Відповідно до реєстру нормативно-правових актів з охорони праці, враховуючи специфіку діяльності управління проектами і програмами в сфері матеріального і нематеріального виробництва, на діяльність керівника з управління проектами поширюється низка актів, а саме: Закон України про охорону праці, закон України «Про обов’язкову державне соціальне страхування від нещасних випадків на виробництві і професійних захворюваннях», закон України «Про страхові тарифи на обов’язкове державне соціальне страхування від нещасних випадків на виробництві і професійних захворюваннях», закон України «Про колективні договори і угоди», закон України «Про господарчий кодекс України», закон України «Про пенсійне забезпечення», закон України «Про об'єкти підвищеної небезпеки», закон України «Про пожежну безпеку». Також враховуючи специфіку діяльності фахівця в сфері управління проектами і програмами потрібно мати в наявності наступні нормативно-правові акти з охорони праці НПАОП 75.0−3.40−80, НПАОП 73.0−1.05−79, НПАОП 73.1−1.06−77, НПАОП 73.1−2.07−85, НПАОП 73.1−1.10−71, НПАОП 93.0−1.01−59, НПАОП 93.0−1.02−97, НПАОП 93.0−1.03−97, НПАОП 93.0−1.06−97, НПАОП 93.0−1.07−97, НПАОП 93.0−1.09−97, НПАОП 93.01−1.04−97, НПАОП 93.03−1.08−00.

Документація з охорони праці яка повинна бути в офісі управління проектами, який функціонує як самостійний підрозділ:

— положення про систему управління охороною праці (СУОТ);

— журнал реєстрації ввідного інструктажу (ГОСТ 12.0.004−90 «Организация обучения безопасности труда»);

— програма вводного інструктажу (ГОСТ 12.0.004−90 «Организация обучения безопасности труда»);

— журнал реєстрації первинних інструктажів (ГОСТ 12.0.004−90 «Организация обучения безопасности труда»);

— перелік основних питань інструктажу на робочому місці (ГОСТ 12.0.004- 90 «Организация обучения безопасности труда»);

— журнал розпоряджень;

— наказ про призначення комісії про перевірку знань з охорони праці (ГОСТ 12. 0. 004- 90 «Организация обучения безопасности труда», «Типовое положение о порядке обучения и проверки знаний по охране труда руководителей и специалистов предприятий, организаций и учреждений»);

— графік перевірки знань з охорони праці;

— перелік діючих інструкцій з охорони праці;

— екзаменаційні білети з охорони праці (ГОСТ 12. 0. 004- 90 «Организация обучения безопасности труда»);

— інструкція з охорони праці («Методические указания по разработке правил и инструкций по охране труда». Постановление Минтруда от 01.07.93 г.);

— журнал реєстрації видачи документації з охорони праці;

— журнал реєстрації вхідної документації;

— заходи з охорони праці;

— планування з охорони праці;

— положення про порядок проведення контролю за станом умов і охорони праці;

— журнал видачі посвідчень з охорони праці (ГОСТ 12. 0. 004- 90 «Организация обучения безопасности труда»);

— журнал реєстрації перевірки знань з охорони праці.

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

Таблиця 3.2 Опис факторів працездатності робочого місця діяльності фахівця з управління проектами