43585
Проект розробки програмного засобу моніторингу реалізації проектів на основі аналізу освоєного обсягу
Дипломная
Информатика, кибернетика и программирование
Практична цінність дослідження полягає у створенні сприятливих умов для кращого сприйняття наданої інформації керівником проекту, що заощадить витрати по проекту. В свою чергу, це є основою для підвищення успішності управління проектом.
Украинкский
2013-10-26
1.17 MB
11 чел.
Вступ 5
Розділ 1. Ініціалізація проекту 7
1.1 Дослідження проблеми створення 7
1.2 Розробка альтернатив вирішення проблеми створення 9
1.3 Вибір моделі життєвого циклу розробки програмного забезпечення 11
1.4 Опис продукту проекту та його функціонування 21
Розділ 2. Планування проекту 23
2.1 Планування змісту проекту 23
2.2 Складання розкладів 29
2.3 Планування проектних витрат 35
2.4 Планування ризиків проекту 37
2.5 Додатковий план проекту 38
Розділ 3. Реалізація проекту 40
3.1 Моніторинг та прогнозування виконання проекту 40
3.2 Оцінка прогресу проекту для ключових зацікавлених осіб 41
3.3 Охорона праці та безпека в надзвичайних ситуаціях при виконанні проекту 48
Висновки 58
Список використаної літератури 60
Додатки окремим томом
Актуальність дослідження. Метод освоєного обсягу (англ. Earned Value Technique, Earned Value Management) - ряд методів, об'єднаних під загальною назвою, що використовуються для вимірювання та контролю ефективності виконання проектів. Метод заснований на використанні ряду числових показників, що розраховуються по ходу проекту. За набором цих показників можна стежити за проектом і вживати заходів по усуненню недоліків своєчасно. Але візуальне представлення інформації дозволяє краще представити багатовимірну інформацію про проект, ніж текст або таблиця. Прикладом візуального представлення є графік. Графіки використовуються для демонстрації трендів у даних з течією часу.
У зв'язку з цим виникла проблема створення програмного забезпечення для моніторингу проекту за методом освоєного обсягу, в якому будуть будуватися графіки. Користувач з легкістю зможе проводити моніторинг проекту, слідкуючи як за показниками так і за відхиленнями графіків. Що в свою чергу підвищить шанс успіху досліджуваних проектів.
Виходячи з цього тема магістерської роботи «Проект розробки програмного засобу моніторингу реалізації проектів на основі аналізу освоєного обсягу» є актуальною.
Мету роботи розробити проект розробки програмного засобу моніторингу реалізації проектів на основі аналізу освоєного обсягу.
Об'єкт дослідження - процеси управління проектами з розробки програмного забезпечення.
Предмет дослідження - процеси управління проектами для управління проектами.
Новизна результатів дослідження полягає в розробці інноваційного рішення шляхом створення програмного засобу моніторингу проекту, за допомогою аналізу освоєного обсягу використовуючи як показники так і візуальне представлення у вигляді графіків. Це дозволить суттєво скоротити швидкість прийняття своєчасних рішень, через краще сприйняття наданої інформації, що в свою чергу заощадить витрати по проекту.
Практична цінність дослідження полягає у створенні сприятливих умов для кращого сприйняття наданої інформації керівником проекту, що заощадить витрати по проекту. В свою чергу, це є основою для підвищення успішності управління проектом.
Традиційний аналіз за допомогою методу освоєного обсягу дуже корисний при моніторингу проектів на етапі реалізації. Але навіть у такого ефективного методу є свої мінуси. Один з них це подання інформації для керівника. По таблиці розрахованих показників не завжди вдається побачити картину в цілому або на певному етапі. Щоб зрозуміти хід оперативних рішень, які сприяють найкращому завершення проекту.
Для демонстрації трендів у даних із плином часу використовуються графіки. Тому цей метод можна вдосконалити за допомогою побудови графіків. Так само якщо ставити розраховувати проміжні точки шляхом введення коефіцієнтів, то можна отримати більш точний графік. Додавши введення прийнятних відхилень ми отримаємо ефективний програмний засіб для моніторингу реалізації проекту на основі аналізу освоєного обсягу.
Найбільш поширеними проблемами, що виникають в процесі розробки програмних засобів (ПЗ), вважають:
Недолік прозорості. В будь-який момент часу складно сказати, в якому стані перебуває проект і який відсоток його завершення.
Дана проблема виникає при недостатньому плануванні структури (чи архітектури) майбутнього програмного продукту, що частіше за все є наслідком відсутності достатнього фінансування проекту: програма потрібна, скільки часу займе розробка, які етапи, чи можна якісь етапи виключити або заощадити - наслідком цього процесу є те, що етап проектування скорочується.
Недолік контролю. Без точної оцінки процесу розробки зриваються графіки виконання робіт і перевищуються встановлені бюджети. Складно оцінити обсяг виконаної і залишилася роботи.
Дана проблема виникає на етапі, коли проект, завершений більш ніж наполовину, продовжує розроблятися після додаткового фінансування без оцінки ступеня завершеності проекту.
Недолік трасування.
Недолік моніторингу. Неможливість спостерігати хід розвитку проекту не дозволяє контролювати хід розробки в реальному часі. За допомогою інструментальних засобів менеджери проектів приймають рішення на основі даних, що надходять в реальному часі.
Дана проблема виникає в умовах, коли вартість навчання менеджменту володінню інструментальними засобами порівнянна з вартістю розробки самої програми.
Неконтрольовані зміни. У споживачів постійно виникають нові ідеї щодо розроблюваного програмного забезпечення. Вплив змін може бути суттєвим для успіху проекту, тому важливо оцінювати пропоновані зміни і реалізовувати тільки схвалені, контролюючи цей процес за допомогою програмних засобів.
Дана проблема виникає внаслідок небажання кінцевого споживача використовувати ті чи інші програмні середовища. Наприклад, коли при створенні клієнт-серверної системи споживач пред'являє вимоги не тільки до операційної системи на комп'ютерах-клієнтах, а й на комп'ютері-сервері.
Недостатня надійність. Найскладніший процес - пошук і виправлення помилок у програмах на ЕОМ. Оскільки число помилок в програмах заздалегідь невідомо, то заздалегідь невідома і тривалість налагодження програм і відсутність гарантій відсутності помилок в програмах. Слід зазначити, що залучення доказового підходу до проектування ПЗ дозволяє виявити помилки в програмі до її виконання. У цьому напрямку багато працювали Кнут, Дейкстра і Вірт. Професор Вірт при розробці Паскаля і Оберона за рахунок суворості їх синтаксису домігся математичної доказовою завершаємості і правильності програм, написаної на цих мовах.
Дана проблема виникає при неправильному виборі засобів розробки. Наприклад, при спробі створити програму, що вимагає коштів високого рівня, за допомогою засобів низького рівня. Наприклад, при спробі створити засоби автоматизації з СУБД на асемблері. У результаті вихідний код програми виходить дуже складним і погано піддається структуруванню.
Відсутність гарантій якості і надійності програм через відсутність гарантій відсутності помилок в програмах аж до формальної здачі програм замовникам.
Дана проблема не є проблемою, що відноситься виключно до розробки ПЗ. Гарантія якості - це проблема вибору постачальника товару (не продукту).
Основні відмінності управління розробкою програмного забезпечення від інших видів управління проектами:
кінцевий результат проекту з розробки програмного забезпечення нематеріальний;
недостатність накопиченого в цій галузі досвіду;
швидка зміна використовуваних в проекті технологій;
досвід управління проектами з розробки програмного забезпечення часто не може бути застосований до інших проектів.
Альтернативами вирішення існуючої проблеми буде наступне:
Тепер зупинимося більш детально на кожній з них:
Перша альтернатива дає нам лише переваги традиційного аналізу освоєного обсягу.
Друга надасть більш широкий профіль моніторингу.
Третя дасть більш широку картину ніж перша і друга, так як за допомогою відхилень ми будимо бачити прийнятні нам межі.
Для того щоб вибрати оптимальну альтернативу скористаємося методом багатокритеріальних шкал. Для 3 варіантів вирішення проблеми розставимо бали від 1-10 в залежності від ступеня задоволення заданим критеріям. Найбільш важливими з них є наступні чотири:
Виходячи з наведених у таблиці 1.1 ми бачимо, що внаслідок ранжирування найбільшу кількість балів отримала альтернатива програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу з будуванням графіків та завданням відхилень. Виходячи з цього, можна сказати, що даний варіант буде найбільш оптимальним.
Таблиця 1.1
Оцінка проектних альтернатив
Альтернатива |
Критерій |
||||
Ефективність |
Якість інформації |
Сприйняття інформації |
Інноваційність |
Підсумок |
|
програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу |
5 |
5 |
4 |
0 |
14 |
програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу з будуванням графіків |
8 |
9 |
10 |
9 |
36 |
програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу з будуванням графіків та завданням відхилень |
10 |
10 |
10 |
10 |
40 |
Вибір та адаптація життєвого циклу розробки проекту впливає на методики розробки продукту, навички менеджменту проектів та навички менеджменту персоналу. Що стосується методів розробки продукту, менеджер проекту повинен насамперед мати уявлення про стандарти процесу, вміти оцінити їх придатність по відношенню до даного проекту, оцінити альтернативні процеси і при необхідності адаптувати процес життєвого циклу до поточних потреб. На вибір методів і інструментальних засобів також може впливати вибір життєвого циклу.
Вибір прийнятної моделі життєвого циклу розробки ПЗ для проекту може здійснюватися в ході використання наступного процесу:
Вимоги. Категорія вимог (таблиця 1.2) складається з питань щодо вимог, які пред'являє користувач до проекту. У термінології їх іноді називають властивостями системи, яка буде підтримуватися даним проектом.
Таблиця 1.2
Вибір моделі життєвого циклу на основі характеристик вимог
Вимоги |
Каскадна |
V-образна |
Прототипування |
Спіральна |
RAD |
Інкрементна |
Чи є вимоги легко визначених та / або добре відомими? |
Так |
Так |
Ні |
Ні |
Так |
Ні |
Чи можуть вимоги заздалегідь визначатися в циклі? |
Так |
Так |
Ні |
Ні |
Так |
Так |
Чи часто будуть змінюватися вимоги в циклі? |
Ні |
Ні |
Так |
Так |
Ні |
Ні |
Чи потрібно демонструвати вимоги з метою визначення? |
Ні |
Ні |
Так |
Так |
Так |
Ні |
Чи потрібні для демонстрації Продовження таблиці 1.2 можливостей перевірка концепції? |
Ні |
Ні |
Так |
Так |
Так |
Ні |
Чи будуть вимоги відображати складність системи? |
Ні |
Ні |
Так |
Так |
Ні |
Так |
Чи володіє вимога функціональними властивостями на ранньому етапі? |
Ні |
Ні |
Так |
Так |
Так |
Так |
Всього: |
4 |
4 |
3 |
3 |
5 |
3 |
Команда розробників. По можливості, до складу команди розробників найкраще відібрати персонал ще до того, як буде обрано модель життєвого циклу. Характеристики такої команди (таблиця 1.3) відіграють важливу роль в процесі вибору, оскільки вона несе відповідальність за вдале виконання циклу і може надати допомогу в процесі вибору.
Таблиця 1.3
Вибір моделі життєвого циклу на основі характеристик учасників команди розробників
Команда розробників проекту |
Каскадна |
V-образна |
Прототипування |
Спіральна |
RAD |
Інкрементна |
Чи є проблеми предметної області проекту новими для більшості розробників? |
Ні |
Ні |
Так |
Так |
Ні |
Ні |
Чи є технологія предметної області проекту нової для більшості розробників? |
Так |
Так |
Ні |
Так |
Ні |
Так |
Чи є інструменти, використовувані проектом, новими для більшості розробників? |
Так |
Продовження таблиці 1.3 Так |
Ні |
Так |
Ні |
Ні |
Чи змінюються ролі учасників проекту під час життєвого циклу? |
Ні |
Ні |
Так |
Так |
Ні |
Так |
Чи можуть розробники проекту пройти навчання? |
Ні |
Так |
Ні |
Ні |
Так |
Так |
Чи є структура більш значимої для розробників, ніж гнучкість? |
Так |
Так |
Ні |
Ні |
Ні |
Так |
Чи буде менеджер проекту строго відслідковувати прогрес команди? |
Так |
Так |
Ні |
Так |
Ні |
Так |
Чи важлива легкість розподіл ресурсів? |
Так |
Так |
Ні |
Ні |
Так |
Так |
Всього: |
3 |
4 |
4 |
3 |
6 |
2 |
Колектив користувачів. На початкових фазах проекту можна отримати чітке уявлення про колектив користувачів (таблиця 1.4) і його майбутньої взаємозв'язку з командою розробників протягом всього проекту. Таке уявлення допоможе вам при виборі відповідної моделі, оскільки деякі моделі вимагають посиленого участі користувачів у процесі розробки та вивчення проекту.
Таблиця 1.4
Вибір моделі життєвого циклу на основі характеристик колективу користувачів
Колектив користувачів |
Каскадна |
V-образна |
Прототипування |
Спіральна |
RAD |
Інкрементна |
Чи буде присутність користувачів обмежена в життєвому циклі? |
Так |
Так |
Ні |
Так |
Ні |
Так |
Чи будуть користувачі знайомі з визначенням системи? |
Ні |
Ні |
Так |
Так |
Ні |
Так |
Чи буду користувачі ознайомлені з проблемами предметної області? |
Ні |
Ні |
Так |
Ні |
Так |
Так |
Чи будуть користувачі залучені в усі фази життєвого циклу? |
Ні |
Ні |
Так |
Ні |
Так |
Ні |
Чи буде замовник відстежувати хід виконання проекту? |
Ні |
Ні |
Так |
Так |
Ні |
Ні |
Всього: |
1 |
1 |
4 |
1 |
4 |
1 |
Тип проекту та ризики. І, нарешті, уточнимо, що собою представляють тип проекту і ризики (таблиця 1.5), які були розглянуті як елементи, визначення яких здійснюється на фазі планування. У деяких моделях передбачений менеджмент ризиків високого ступеня, в той час як в інших він не передбачений взагалі. Вибір моделі, яка робить можливим менеджмент ризиків, не означає, що вам не потрібно складати план дій, спрямований на мінімізацію виявлених ризиків. Така модель просто забезпечує схему, в рамках якої можна обговорити і виконати даний план дій.
Таблиця 1.5
Вибір моделі життєвого циклу на основі характеристик типу проектів і ризиків
Тип проекту і ризики |
Каскадна |
V-образна |
Прототипування |
Спіральна |
RAD |
Інкрементна |
Чи буде проект ідентифікувати новий напрямок продукту для організації? |
Ні |
Ні |
Так |
Так |
Ні |
Так |
Чи буде проект мати тип системної інтеграції? |
Ні |
Так |
Так |
Так |
Так |
Так |
Чи буде проект бути розширенням існуючої системи? |
Ні |
Так |
Ні |
Ні |
Так |
Так |
Чи очікується тривала експлуатація продукту в організації? |
Так |
Так |
Ні |
Так |
Ні |
Так |
Чи повинна бути висока ступінь надійності? |
Ні |
Так |
Ні |
Так |
Ні |
Так |
Чи буде система змінюватися, можливо, із застосуванням непередбачених методів, на етапі супроводу? |
Ні |
Ні |
Так |
Так |
Ні |
Так |
Чи є графік обмеженим? |
Ні |
Ні |
Так |
Так |
Так |
Ні |
Чи є "прозорими" інтерфейсні модулі? |
Так |
Так |
Ні |
Ні |
Ні |
Так |
Чи доступні повторне Продовження таблиці 1.5 використовувані компоненти? |
Ні |
Ні |
Так |
Так |
Так |
Ні |
Чи є достатніми ресурси (час, гроші, інструменти, персонал)? |
Ні |
Ні |
Так |
Так |
Ні |
Ні |
Всього: |
4 |
5 |
5 |
6 |
8 |
2 |
Тому що завдяки методу RAD користувач задіяний на всіх фазах життєвого циклу розробки проекту - не тільки при визначенні вимог, а й при проектуванні, розробці, тестуванні, а також кінцевої постачання програмного продукту.
Це забезпечується наявністю засобів розробки графічного інтерфейсу користувача і кодогенераторів. Такі інструментальні засоби, як Oracle Designer/2000, JavaJbuilder 3, Linux, Visual C, Visual Basic 6, SAS, й інші можна використовувати в якості засобів для швидкої розробки додатків. У нашому випадку вибір припав на C # («Сі шарп»).
Характерною рисою RAD є короткий час переходу від визначення вимог до створення повної системи. Метод ґрунтується на послідовності ітерацій еволюційної системи або прототипів, критичний аналіз яких обговорюється з замовником. У процесі такого аналізу формуються вимоги до продукту. Розробка кожного інтегрованого продукту обмежується чітко визначеним періодом часу, який, як правило, становить 60 днів і називається тимчасовим блоком. Фактори, що дозволяють створити систему за 60 днів, причому без шкоди якості, включають в себе використання потужних інструментальних засобів розробки, високий рівень фактора повторного використання, а також осмислені та виділені ресурси.
Переваги моделі RAD. При використанні моделі RAD щодо проекту, для якого вона в достатній мірі прийнятна, проявляються такі переваги:
Недоліки моделі RAD. Якщо ця модель застосовується для проекту, для якого вона не підходить в повній мірі, можуть позначатися такі недоліки:
Область застосування моделі RAD. Менеджер проекту може бути впевнений в тому, що модель RAD підходить для застосування в конкретній ситуації в разі, якщо є в наявності деякі з наведених нижче умов-причин:
При зустрічах з замовником були обрані шаблони головного та інших вікон програми. Головне вікно повинне виглядіти так (рис. 1.1):
Рис. 1.1. Шаблон головного вікна програми
a назви кроків
b кнопки етапів
c поле допоміжної інформації
Для того щоб втілити в реальність цю задачу я вибрав мову програмування C#( вимовляється сі шарп). Так як на ній можна втілити всі надані завдання повною мірою. Працює на платформі Microsoft. NET Framework. Перейнявши багато що від своїх попередників - мов C + +, Java, Delphi, Модула і Smalltalk - С #, спираючись на практику їх використання, виключає деякі моделі, що зарекомендували себе як проблематичні при розробці програмних систем, наприклад, C # не підтримує множинне наслідування класів (на відміну від C++)[12].
Щоб втілити всі вимоги замовника з програмного засобу мені було необхідно вивчити побудову таблиць і графіків у вибраній мові програмування.
Так само було необхідно навчитися обмінюватися інформацією між елементами програмного засобу і вміти зберігати всі дані в текстовий файл, щоб можна було заповнювати елементи програмного засобу з нього.
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-структура проекту
Таблиця 2.1
Приклад опису пакета робіт
Пакет робіт |
Роботи |
Р.3.1. Створення форми реєстрації проекту |
Створення графічного інтерфейсу на дизайнері форм |
Створення подій |
|
Написання програмного коду реагування на події |
|
Налаштування зв'язку з іншими вікнами |
|
Компіляція |
|
Тестування |
|
Виправлення помилок у програмному коді |
Робочий пакет складається з робіт, які представляють деяку діяльність, необхідну для досягнення конкретних результатів (кінцевих продуктів нижнього рівня). Таким чином, робота є основним елементом (дискретної, компонентою) діяльності на самому нижньому рівні деталізації, на виконання якого потрібен час, і який може затримати початок виконання інших робіт. У таблиці 2.2 представлено детальний розподіл пакетів робіт на роботи, визначена їх тривалість та шлях.
WBS дозволяє звести цілі проекту до ієрархії засобів їх досягнення, або, що те ж, отримання результатів, передбачених проектом. WBS є так само інструментом, що дозволяє керівнику проекту отримати опис кінцевого результату (продукту, послуги) проекту і всіх підпроектів, в результаті яких буде досягнуто запланований результат. Далі WBS може розділятися (і результати підрозділятися) на частини для спеціалізації видів і обсягів робіт учасників проекту, координації їхніх дій і закріплення відповідальності за обсягами робіт, аж до рівня, що забезпечує керованість та належне адміністрування проекту. WBS забезпечує виявлення робіт, необхідних для досягнення цілей проекту. При такому підході проект визначається в термінах ієрархічно взаємопов'язаних орієнтованих на результат елементів (пакетів робіт - комплексів робіт, згрупованих за заданим підставах / критеріям). Кожен наступний рівень декомпозиції забезпечує послідовну деталізацію змісту проекту, що дозволяє робити оцінку виконаних обсягів робіт, освоєних грошей і виконання за термінами. На нижніх рівнях пакетам робіт відповідають порівняно менші обсяги робіт. Це спрощує оцінку відсотка виконання і дає можливість більш чітко визначати дії, необхідні для досягнення цілей проекту. Запропонований підхід декомпозиції робіт формує необхідну основу для визначення вимірних показників (трудомісткості, вартості), а також дозволяє з високим ступенем достовірності говорити про те, що цілі, пов'язані з даним пакетом робіт можуть і будуть досягнуті.
Таблиця 2.2
Перелік пакетів робіт проекту
Пакети(блоки) робіт WBS-структури |
Код роботи |
Назва роботи |
Тривалість роботи, днів |
Попе-редня робота |
Р.1. Планування |
01 |
Постановка задачі |
1 |
|
02 |
Підготовка технічного завдання |
1 |
01 |
|
Р.2. Набуття навичок роботи в C # |
03 |
Набуття навичок роботи з таблицями |
10 |
02 |
04 |
Набуття навиків малювання графіків |
11 |
02 |
|
05 |
Набуття навиків здобуття інформації з таблиць і графіків |
10 |
02 |
|
06 |
Створення наочного зразка для демонстрації набутих навиків |
3 |
03, 04, 05 |
|
Р.3. Створення програмного забезпечення моніторингу реалізації проекту на основі аналізу освоєного обсягу |
07 |
Створення форми реєстрації проекту |
5 |
06 |
08 |
Створення форм введення проекту |
16 |
07 |
|
09 |
Створення форм побудови графіків |
4 |
08 |
|
10 |
Створення форм моніторингу проекту |
4 |
09 |
|
11 |
Створення форм документації |
2 |
10 |
|
Р.4. Ліцензування програмного забезпечення |
12 |
Підготовка документації для отримання ліцензії |
1 |
11 |
2.1.3. Побудова ОBS-структури проекту
Організаційна структура проекту (ОBS) це структура яка стосується тільки внутрішньої організаційної структури проекту і влаштована таким чином, щоб співвідносити пакети робіт з виконуючими організаційними одиницями. На рис. 2.2 зображено організаційну структуру розроблюваного проекту
Рис. 2.2. Організаційна структура проекту розробки програмного забезпечення, для аналізу фінансових і економічних показників проекту
Метод передування (PDM) або «вершина - робота» відображають мережну модель в графічному вигляді як безліч вершин, відповідних робіт, пов'язаних лініями, які представляють взаємозв'язки між роботами. Метод передування оперує такими типами залежностей передування - наслідування: «фініш-старт», «старт-фініш», «старт-старт», «фініш-фініш». На рис. 2.3 зображено PDM-сітку проекту, де вказано назви робіт, їх послідовність та тривалість.
Рис. 2.3. PDM-сітка проекту розробки програмного засобу моніторингу реалізації проектів на основі аналізу освоєного обсягу
Критичний шлях максимальний за тривалістю повний шлях в мережі; роботи, що лежать на цьому шляху, також називаються критичними. Саме тривалість критичного шляху визначає найменшу загальну тривалість проекту в цілому. Тривалість виконання всього проекту в цілому може бути скорочена за рахунок скорочення тривалості завдань, що лежать на критичному шляху. Відповідно, будь-яка затримка виконання завдань критичного шляху спричинить збільшення тривалості проекту.
Основною перевагою методу критичного шляху є можливість маніпулювання термінами виконання завдань, які не лежать на критичному шляху.
Метод критичного шляху дозволяє розрахувати можливі календарні графіки виконання комплексу робіт на основі описаної логічної структури мережі і оцінок тривалості виконання кожної роботи, визначити критичний шлях проекту.
Тимчасової резерв або запас часу - це різниця між раннім, можливим терміном завершення роботи і найпізнішим допустимим часом її виконання. Управлінський зміст тимчасового резерву полягає в тому, що при необхідності врегулювати технологічні, ресурсні або фінансові обмеження проекту він дозволяє менеджеру затримати роботу на цей час без впливу на загальну тривалість проекту та тривалість безпосередньо пов'язаних з нею завдань. Роботи, що лежать на критичному шляху, мають часовий резерв, рівний нулю.
Результати розрахунку тривалості проекту методом критичного шляху представлені на рис. 2.4.
Рис. 2.4. Розрахунок тривалості проекту методом критичного шляху
Графік Ганта. Діаграма Ганта (англ. Gantt chart, також стрічкова діаграма, графік Ганта) - це популярний тип стовпчастих діаграм (гістограм), який використовується для ілюстрації плану, графіка робіт з якого-небудь проекту. Є одним з методів планування проектів. Використовується в додатках з управління проектами [14].
Перший формат діаграми був розроблений Генрі Л. Гант в 1910 році.
По суті, діаграма Ганта складається зі смуг, орієнтованих вздовж осі часу. Кожна смуга на діаграмі представляє окрему задачу у складі проекту (вид роботи), її кінці - моменти початку та завершення роботи, її протяжність - тривалість роботи. Вертикальною віссю діаграми служить перелік завдань. Крім того, на діаграмі можуть бути відзначені сукупні завдання, відсотки завершення, покажчики послідовності і залежності робіт, мітки ключових моментів (віхи), мітка поточного моменту часу «Вчора» та інші.
Ключовим поняттям діаграми Ганта є «Віха» - мітка значимого моменту в ході виконання робіт, спільний кордон двох або більше завдань. Віхи дозволяють наочно відобразити необхідність синхронізації, послідовності у виконанні різних робіт. Віхи, як і інші кордону на діаграмі, не є календарними датами. Зрушення віхи призводить до зрушення всього проекту. Тому діаграма Ганта не є, строго кажучи, графіком робіт. І це один з основних її недоліків. Крім того, діаграма Ганта не відображає значущості або ресурсоємності робіт, не відображає сутності робіт (області дії). Для великих проектів діаграма Ганта стає надмірно великовагової і втрачає всяку наочність [15 стор. 105-109].
Зазначені вище недоліки і обмеження серйозно обмежують сферу застосування діаграми. Тим не менш, у даний час діаграма Ганта є стандартом де-факто в теорії і практиці управління проектами, принаймні, для відображення Структури переліку робіт по проекту.
Перші програми для управління проектами були розроблені майже сорок років тому. В основі даних систем лежали алгоритми мережевого планування і розрахунку часових параметрів проекту за методом критичного шляху. Перші системи дозволяли представити проект у вигляді мережі, розрахувати ранні та пізні дати початку та закінчення робіт проекту і відобразити роботи на тимчасовій осі у вигляді діаграми Ганта. Пізніше в системи були додані можливості ресурсного і вартісного планування, засоби контролю за ходом виконання робіт.
При розробці проекту я використовував програмний продукт Suretrack. Цей програмний продукт орієнтований на невеликі проекти, під проекти, роботу конкретних виконавців з фрагментами проектів. SureTrak має ті ж кошти, що й P3 у плані організації проекту по кодах і фільтрації інформації, установки обмежень і розрахунку розкладу, але в той же час існує ряд обмежень і додаткових можливостей. З обмежень слід відзначити відсутність коштів багатопроектного управління та фрагментації проектів, меншу розмірність проектів, більш скромні засоби створення звітів. Проте в SureTrak з'явилися календарі ресурсів і, як наслідок, можливість розрахунку тривалості робіт з урахуванням узгодження календарів виконавців (очікується, що календарі ресурсів з'являться і в наступній версії P3). Крім того, у ресурсів з'явилася додаткова категорія - дохід. SureTrak відрізняється від всіх інших продуктів Primavera тим, що він повністю русифікований і поставляється разом з керівництвом для користувача російською мовою.
Для того щоб мати реальне уявлення про тривалість виконання робіт проекту з урахуванням обмежень у використанні ресурсів, а також проекту в цілому з урахуванням вихідних і святкових днів, побудуємо календарний графік. Він так само має назву графіка Ганта і являє собою зображення задач у вигляді відрізків на шкалі часу.
Для побудови графіка Ганта скористаємося програмою SureTrak 1.5 (рис. 2.5).
Рис. 2.5. Графіка Ганта
Ми бачимо що практично всі роботи лежать на критичному шляху і нам нічого не остається крім того, як створити додатковий план, в якому ми будемо реєструвати всі ризики по проекту. Тому що у нас немає резервів часу нам потрібно знизити ризики до мінімуму, щоб виконати проект з найменшою затримкою у часі.
Привласнимо кожному ресурсу проекту унікальний код:
PPOG Інженер-програміст Корженко С. А.
ENER електроенергія
Інженер-програміст у нашому випадку має вартість 0. Вартість електроенергії розрахуємо з наступних суджень:
Виходячи з цього вартість електроенергії дорівнює 0,4 * 0,55 = 0,22 грн. в день.
Для проектів будь-якого роду неминучим є серйозне планування витрат і їх оцінка, дотримання яких може розглядатися для менеджменту проектів як запорука успіху [10, с.29-42]. При цьому слід виходити з того, що виробляється надійна і професійна підготовка проекту з ефективним планеруванням витрат. Співвіднесені з проектом дані із стадії концепції і визначення переносяться як заснувавши планерування і оцінку витрат. Надійне планерування витрат і вживання стандартів, що діють планування навіть в екстремальному випадку приводить до надійності самого процесу витрат. Поняття надійності тут, зрозуміло, є відносним, оскільки навіть при детермінантних проектах, наприклад технічних, будівельних проектах і т. п., розмах коливань витрат до ± 15% всюди ще вважається терпимим, навіть якщо для інвестора і виробленого фінансування внаслідок цього можуть виникнути серйозні проблеми. Тим самим, при планеруванні проектних витрат пред'являються серйозні вимоги до компетентності і досвіду фахівців для того, щоб були знайдені реалістичні величини витрат.
Розглянемо ресурсний профіль проекту з вартості всіх ресурсів рис 2.6.
Рис. 2.6. Підсумок по ресурсах за кількістю
На рисунку 2.6 ми бачимо чіткий графік проекту з вартості всіх ресурсів. Розглянемо ресурсний профіль проекту за кількістю всіх ресурсів на рис 2.7.
Рис. 2.7. Підсумок по ресурсах за вартістю у програмі SureTrak 1.5
Планування управління ризиками [9] - процес прийняття рішень щодо застосування та планування управління ризиками для конкретного проекту. Цей процес може включати в себе рішення по організації, кадрового забезпечення процедур управління ризиками проекту, вибір кращою методології, джерел даних для ідентифікації ризику, тимчасової інтервал для аналізу ситуації. Важливо спланувати управління ризиками, адекватне як рівню і типу ризику, так і важливості проекту для організації.
Основні п'ять ризиків проектів розробки програмного забезпечення:
Ризик 1: помилки, властиві розкладу. Завдяки своєї невідчутної природи й унікальності програмного забезпечення, процес розробки ПО складно оцінити і розписати.
Ризик 2: поява нових вимог. В процесі просування проекту з'являються все нові вимоги, які можуть порушити всі терміни та оцінки.
Ризик 3: декомпозиція специфікації. При старті процесу кодування та інтеграції стає ясно, що специфікація неповна і містить конфліктні вимоги.
Ризик 4: низька продуктивність. Наявність попереду тривалих термінів призводить до того, що на ранніх стадіях часто відсутнє почуття терміновості в роботі, а це в результаті дає на початку проекту втрату часу, який вже не можна повернути.
Ризик 5: відсутність своєчасних зустрічей з замовником. Через зайнятість замовника і не отримання наступного завдання немає можливості рухатися далі, що в свою чергу затримує виконання всього проекту.
Складемо реєстр ризиків проекту (табл. 2.3). Імовірність настання ризику виміряємо в балах від 1 до 5. Вплив ризику на проект виміряємо в балах від 1 до 5. Рівень ризику може бути: високий, середній, низький залежно від імовірності настання і ступеня впливу ризику. Ризики з найбільшою ймовірністю настання і високим ступенем впливу будуть мати високий рівень, ризики ж з найменшою вірогідністю настання і низьким ступенем впливу відповідно низький рівень.
Таблиця 2.3
Реєстр ризиків
№ з/п |
Ризик |
Вірогід-ність наступу (1-5) |
Вплив ризику (1-5) |
Рівень ризику |
Заходи зменшення наслідків ризику |
1 |
помилки, властиві розкладу. Завдяки своїй невідчутною природі й унікальності програмного забезпечення, процес розробки ПО складно оцінити і розписати. |
2 |
4 |
середній |
більше зупиняти вплив в процес планування та оцінки. Отримання відгуків на ранній стадії і обговорення можливих помилок і нестиковок особисто з замовником. |
2 |
поява нових вимог. В процесі просування проекту з'являються все нові вимоги, які можуть порушити всі терміни та оцінки. |
5 |
4 |
високий |
постійне залучення замовника і розробника. |
3 |
декомпозиція специфікації. При старті процесу кодування та інтеграції стає ясно, що специфікація неповна і містить конфліктні вимоги. |
1 |
2 |
низький |
здійснення критичних договорів і рішень. |
4 |
низька продуктивність. Наявність попереду тривалих термінів призводить до того, що на ранніх стадіях часто відсутнє почуття терміновості в роботі, а це в результаті дає на початку проекту втрату часу, який вже не можна повернути. |
2 |
2 |
низький |
короткі ітерації, потрібні люди в команді, лідерство та розвиток команди. |
5 |
відсутність своєчасних зустрічей з замовником. Через зайнятість замовника і не отримання наступного завдання немає можливості рухатися далі, що в свою чергу затримує виконання всього проекту. |
5 |
5 |
високий |
краще розпланувати зустрічі із замовником і налагодити комунікації. |
Моніторинг та управління роботами проекту виконується для спостереження за проектними процесами, пов'язаними з ініціацією, плануванням, виконанням і закриттям проекту. Коригувальні та попереджувальні дії робляться для контролю ефективності проекту. Моніторинг є аспектом управління проектом і проводиться протягом всього проекту. Моніторинг включає в себе збір, вимір і поширення інформації про ефективність і оцінку вимірів і тенденцій для внесення покращень в процеси. Безперервний моніторинг дозволяє команді управління проектом заглянути всередину проекту і виявити місця, яким потрібно приділити особливу увагу. Процес моніторингу та управління роботами проекту відповідають на наступні моменти:
Всі основні елементи проекту повинні контролюватися керівництвом, що повинне визначити процедуру й установити послідовність збору даних через певні інтервали часу, провадити аналіз отриманих даних, аналізувати поточні розбіжності фактичних і планових показників і прогнозувати вплив поточного стану справ на виконання обсягів, що залишилися, робіт.
Відповідальність за контроль над ходом виконання проекту лежить на керівнику проекту від замовника. Керівник проекту зобов'язаний аналізувати звітність по проекті, відслідковувати й реагувати на відхилення й зміни в проекті.
Контроль над ходом реалізації проекту здійснюється на основі розроблених на стадії планування проекту документів:
- графік робіт із проекту,
- бюджет проекту,
- ресурсний профіль,
- план управління ризиками тощо.
Моніторинг виконання кожного завдання проекту повинен включати:
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.
Рис 3.3. Графік показників освоєного обсягу проекту станом на 25.05.12
На рисунку 3.3 видно що на 25 травня показники освоєного обсягу дорівнює 7, Планові (бюджетні) витрати інвестиційного проекту (BCWS) рівні 6а Cost дорівнює 9.
На рисунку 3.4 ми бачимо віхи виконання за звітний період проекту на основі аналізу освоєного обсягу на 25.05.2012.
Рис. 3.4. Віхи виконання за звітний період проекту на основі аналізу освоєного обсягу на 25.05.2012
№ з/п |
Показник |
Сутність показника |
Фактичне значення показника (гр.) коментарі |
1 |
Планова (бюджетна) вартість запланованих робіт (запланований обсяг PV) |
Сума планових бюджетних вартостей робіт, які повинні бути виконані на конкретну розглянуту дату. Розраховується на основі плану проекту |
6 |
2 |
Фактична вартість виконаних робіт (фактичні витрати AC) |
Розраховується як сума реальних витрат за проектом на розглянуту дату на основі бухгалтерських документів |
7 |
3 |
Бюджетна вартість фактично виконаних робіт (освоєний обсяг EV) |
Розраховується як сума бюджетних вартостей всіх робіт, які фактично виконані за проектом на розглянуту дату на основі фактичних звітів про стан виконання проекту |
9 |
4 |
Відхилення від вартості (CV) |
CV=EV-AC Показує в грошовому вираженні, на скільки витрачено ресурсів більше для вже виконаних робіт порівняно з тим, що планувалося. |
2 |
5 |
Відхилення від графіку (SV) |
SV=EV-PV Показує в грошовому вираженні, на скільки в планових цінах виконано робіт менше, ніж планувалося |
3 |
6 |
Індекс виконання вартості CPI |
CPI=EV/AC |
1,29 CPI> 1 показує економію витрат. |
7 |
Індекс виконання графіка SPI |
SPI=EV/PV |
1,5 SPI > 1 показує економію витрат. |
8 |
Індекс відхилення за витратами CDI |
CDI=CV/EV*100% |
22,22% |
Таблиця 3.1
Показники освоєного обсягу проекту
За результатами розрахунків можна зробити висновок про відставання проекту від запланованих строків і незначну перевитрату коштів на дату проведення моніторингу. Перевитрата коштів становить 22 % від ризикового резерву проекту, що складає 5 % від загального бюджету. Тому не має сенсу переглядати бюджет та резерви коштів проекту.
На дату моніторингу виконано 89% проектних робіт. Проект затримається через відсутність своєчасних зустрічей із замовником. Через зайнятість замовника і не отримання наступного завдання немає можливості рухатися далі. Орієнтовна дата здачі проекту 06.06.2012 р. Тобто проект затримається на 2-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.
Документація з охорони праці яка повинна бути в офісі управління проектами, який функціонує як самостійний підрозділ:
Опис факторів працездатності робочого місця фахівця з управління проектами наведено у табл.3.2
Таблиця 3.2
Опис факторів працездатності робочого місця діяльності фахівця з управління проектами
№ |
Основні види робіт |
Робоча зона |
Фактори працездатності |
|||
технічні |
ергономічні |
фізіологічні |
психологічні |
|||
1 |
Планування проекту (розробка змісту, календарного графіку) |
Робочий кабінет у приміщенні |
електричне обладнання (компютер,мережеве обладнання); меблі. |
освітлення; ергономіка робочого місця з компютером; стан повітря; атмосферний тиск. |
монотонність роботи; сидяча поза; навантаження зору; навантаження на пальці та кінцівки рук; випромінювання обладнання. |
стрес з причини перевантаження, постійного переривання та часового обмеження емоційна напруга; керування підлеглими; взаємодія із замовником; монотонний шум від офісного обладнання. |
2 |
Моніторинг проекту (внесення фактичних даних про стан проекту, розрахунок показників прогресу проекту методом освоєного обсягу) |
Робочий кабінет у приміщенні |
електричне обладнання (компютер, мережеве обладнання); меблі. |
освітлення; ергономіка робочого місця з компютером; стан повітря; атмосферний тиск; оточення в приміщенні; оточення на обєктах підрядних організацій. |
монотонність роботи; сидяча поза; навантаження зору; навантаження на пальці та кінцівки рук; випромінювання обладнання; численні переїзди автомобільним транспортом. |
стрес з причини перевантаження, постійного переривання та часового обмеження емоційна напруга; взаємодія із підрядниками, замовником; монотонний шум від офісного обладнання. |
3 |
Коригування базового плану проекту та релевантної документації |
Робочий кабінет у приміщенні |
електричне обладнання (компютер, мережеве обладнання); меблі. |
освітлення; ергономіка робочого місця з компютером; стан повітря; атмосферний тиск; оточення в приміщенні. |
монотонність роботи; сидяча поза; навантаження зору; навантаження на пальці та кінцівки рук; випромінювання обладнання. |
стрес з причини перевантаження, постійного переривання та часового обмеження емоційна напруга; монотонний шум від офісного обладнання. |
Оцінка працездатності робочого місця діяльності фахівця з управління проектами наведена у табл. 3.3.
Таблиця 3.3
Інтегральна оцінка придатності
№ |
Найменування фактору працездатності РМ |
Нормативний показник |
Фактичний показник |
Оцінка (1-10) |
Оцінка (%) |
1 |
компютер (0,5) |
монітор з низьким рівнем випромінювання |
виконано |
10 |
90 |
системний блок з низьким рівнем шуму |
виконано |
8 |
|||
бездротові зєднання |
виконано |
8 |
|||
наявність системного адміністратора |
виконано |
10 |
|||
2 |
ергономіка робочого місця з компютером (0,3) |
площа на 1 місце 6 м? |
виконано |
9 |
85 |
сучасні офісні меблі |
виконано |
8 |
|||
комфортний рівень освітлення |
виконано |
8 |
|||
3 |
сидяча поза (0,2) |
Продовження таблиці 3.3 заплановані перерви |
виконано |
9 |
90 |
Інтегральна оцінка придатності робочих місць офісу до роботи |
66,75 |
Аналіз визначених факторів та оцінка працездатності робочого місця дозволяє запропонувати с заходи щодо поліпшення працездатності робочого місця керівника проекту та менеджерів проекту у табл. 3.4[13 стор. 143-153].
Таблиця 3.4
Заходи щодо поліпшення працездатності робочого місця керівника проекту та менеджерів проекту.
№ |
Найменуван-ня фактору працездат-ності РМ |
Рекомендовані заходи щодо поліпшення умов праці та безпеки |
1 |
компютер |
Конструкція ПЕВМ повинна забезпечувати потужність експозиційної дози рентгенівського випромінювання в будь-якій точці на відстані 0,05 м. від екрану і корпусу при будь-яких положеннях регульованих пристроїв, що не перевищують 0,1 мбэр/час (100 мкР/час.). |
2 |
ергономіка робочого місця з компютером |
Робочі місця з відеомонітором повинні розташовуватися (у напрямі тилу поверхні одного відеомонітора і екрану іншого монітора) на відстані не менше 2,0 м., а між бічними поверхнями - не менше 1,2 м. Екран відеомонітора повинен знаходитися від очей користувача на відстані 600-700 мм. |
2.1 |
освітлення |
Приміщення повинні мати природне і штучне освітлення. Природне освітлення повинне здійснюватися через світлові отвори і забезпечувати коефіцієнт природного освітлення не нижче 1,5%. Освітленість на поверхні столу в зоні розміщення робочого документа має бути 300-500 лк, місцеве освітлення не повинне створювати відблисків на поверхні екрану і збільшувати освітленість екрану більше 300 лк. Слід обмежувати пряму блесткость від джерел освітлення, при цьому яскравість поверхонь (вікна, світильники), що світяться, знаходяться в полі зору має бути не більше 200 кд/кв.м. Як джерела світла при штучному освітленні повинні застосовуватися переважно люмінесцентні лампи типу ЛБ.. |
2.2 |
повітря |
Оптимальні параметри мікроклімату: Продовження Таблиці 3.4 у холодний період року температура повітря 22-24 град. С, швидкість його руху 0,1 м/с, відносна вологість 60-40%;
Рівень шуму на робочому місці при роботі з ПЕВМ не повинен перевищувати 50 дБА. |
3 |
сидяча поза |
При 8-ми годинній робочій зміні регламентовані перерви слідує встановлювати: - для 1 категорії робіт через 2 години від початку робочої зміни і через 2 години після обідньої перерви тривалістю 15 хвилин кожен; - для 2 категорії робіт через 2 години від початку робочої зміни і через 1,5-2 години після обідньої перерви тривалістю 15 хвилин кожен або тривалість 10 хвилин через кожну годину роботи; - для 3 категорії робіт через 1,5-2 години від початку робочої зміни і через 1,5-2 години після обідньої перерви тривалістю 15 хвилин через кожну годину роботи. При 12-ти годинній роботі регламентовані перерви повинні встановлюватися в перших 8 годин роботи аналогічно перервам для 8-ми годинної робочій зміні, а протягом останніх 4 годин роботи, незалежно від категорії і виду робіт, кожну годину тривалістю 15 хвилин. |
Для робочого місця фахівця з УП крім розгляданих вище факторів існують також ризики виникнення надзвичайних ситуацій. До найбільш вагомих належить: електричне замикання, пожежа в приміщенні. Їх оцінки наведені в табл. 3.5.
Таблиця 3.5
Оцінка готовності РМ до НС
№ |
Найменування можливої НС (ступінь небезпеки) |
Нормативний показник готовності |
Фактичний показник готовності |
Оцінка |
Оцінка готовності (%) |
1 |
електричне замикання (0,3) |
розроблено необхідні інструкції |
не виконано |
0 |
0 |
забезпечення захисними засобами |
не виконано |
0 |
|||
2 |
пожежа в приміщенні (0,4) |
розроблено необхідні інструкції |
не виконано |
0 |
16 |
навчання персоналу в ЕТЦ |
виконано |
5 |
|||
забезпечення засобами пожежогасіння |
не виконано |
0 |
|||
3 |
відключення опалення в зимовий період (0,2) |
розроблено необхідні інструкції |
не виконано |
0 |
35 |
наявність резервних засобів опалювання |
виконано |
7 |
|||
4 |
порив системи опалення (0,1) |
розроблено необхідні інструкції |
не виконано |
0 |
0 |
засоби сигналізації на затоплення |
не виконано |
0 |
|||
Інтегральна оцінка готовності офісу до надзвичайних ситуацій |
13,4 |
Враховуючи те, що працездатність робочого місця команди управління проектами має коефіцієнт значимості 0,13, готовність команди управління проектами до надзвичайних ситуацій має коефіцієнт значимості 0,9 оцінюємо готовність готовності команди управління проектами на 10%, тобто офіс готов до роботи за винятком вказаних недоліків.
У роботі розглянуто проект розробки програмного засобу моніторингу реалізації проектів на основі аналізу освоєного обсягу. В основу якого покладена ідея створення програмного засобу моніторингу проекту, за допомогою аналізу освоєного обсягу використовуючи як показники так і візуальне представлення у вигляді графіків. Це дозволило суттєво скоротити швидкість прийняття своєчасних рішень, через краще сприйняття наданої інформації, що в свою чергу заощадило витрати по проекту.
В результаті розгляду різних альтернатив вирішення проблеми, було вибрано найбільш раціональну з позиції гармонізації цінності проекту. Це програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу з будуванням графіків та завданням відхилень. Відповівши на питань щодо вимог була обрана найбільш прийнятна модель життєвого циклу розробки ПЗ. Це модель швидкої розробки додатків RAD (Rapid Application Development).
Ідентифікація класифікаційних ознак проекту, а також результати проектного аналізу показують, що проект був цілком здатний для реалізації.
А подальший його моніторинг показав, що виконання проекту було затримано через зайнятість замовника, але всього лише на кілька днів, тому що цей ризик був врахований в додатковому плані проекту і було вжито заходів щодо зниження впливу ризику на проект.
Що до недоліків проекту - інтеграція. Програмний засіб хоч і вміє зберігати і відкривати свої проекти, але відсутня інтеграція цих проектів в інші програмні засоби для подальшої роботи.
Фактом реалізації проекту є діючий програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу. Який був написаний на об'єктно-орієнтованій мові програмування C#. Це мова розробки додатків для платформи Microsoft. NET Framework.
Платформа .NET є патентованої технологією корпорації Microsoft і офіційно розрахована на роботу під операційними системами сімейства Microsoft Windows, тому користувачам не складе труднощів у використанні програмного засобу.
У закінченні ми маємо продукт проекту, яким є програмний засіб моніторингу реалізації проектів на основі аналізу освоєного обсягу. Функціональні характеристики продукту подані у додатках другому томі дипломної роботи.
А также другие работы, которые могут Вас заинтересовать | |||
30709. | Проблемы антифашистской борьбы в Европе 1920 – 1930 гг | 23.5 KB | |
В 1935 во Франции был создан Народный фронт в состав которого вошли как коммунистические и социалистические партии так и левобуржуазные политические организации. Народный фронт представляет собой политический союз который как правило объединяет левые и центральные силы для осуществления противодействия правым силам представителей власти. Основной целью возникновения народных фронтов стала борьба за защиту экономических интересов рабочего класса и противопоставление войне и фашизму. Самый первый народный фронт был образован во... | |||
30710. | Основные тенденции и итоги развития Европейского Сообщества в 1990-е | 23.5 KB | |
ЕЕА провозгласил создание Европейского Союза на основе существующих Сообществ и углубление компетенции союза ЕС в области координации экономической валютной социальной политики социальноэкономического сплочения исследований и технологического развития защиты окружающей среды а также развитие европейского сотрудничества в области внешней политики. Амстердамский договор 1997 подтвердил основные цели Союза и дополнил раздел общей внешней политики и политики безопасности. При анализе политики Европейского Союза... | |||
30711. | Создание и основные направления деятельности антигитлеровской коалиции | 24 KB | |
Черчилль и США Рузвельт заявили о своем желании оказать помощь Сов. Великобритания и США подписывают Атлантическую Хартию о совместных действиях против Гитлера СССР присоединилась к ней. Нападение Японии на США ускорило формирование Антигитлеровской коалиции. В декабре 1941 США официально вступает во 2у мировую войну. | |||
30712. | Парижская мирная конференция и ее решения. Версальский мирный договор | 24 KB | |
Возглавлял конференцию Климансо присутствовали лидеры ведущих стран ЛлойдДжордж Великобритания Вильсон США и др. Но главные решения принимались в узком кругу сначала пяти государств Франция Великобритания США Италия Япония а затем только трех Франции Великобритании США таким образом сохранялась практика тайной дипломатии т. Американский конгресс не утвердил вступление США в эту организацию. Франция и Италия за военное давление на Сов России; Великобритания и США более осторожны за переговоры. | |||
30713. | США динамика развития в двухполюсном мире | 31 KB | |
Вторая мировая война стимулировала быстрое экономическое развитие США. Изменилась отраслевая структура экономики США успешнее решались проблемы занятости населения. В первые послевоенные годы в США была успешно проведена конверсия военного производства. С конца 40х годов устойчивый и непрерывный экономический рост стал отличительной особенностью функционирования экономической системы США. | |||
30714. | Противоречия Версальско-Вашингтонской системы международных отношений | 26.5 KB | |
Франция требовала вернуть им Эльзас и Лотарингию установить контроль за промышленным Рурским районом претендовали на германские колонии в Африке и Средиземноморье и т. Великобритания хотели сохранить единство Германии установив контроль над её экономикой. | |||
30715. | Факторы социальной и политической нестабильности во Франции в 1950-е годы. Конец 4-ой республики (1958 г.) | 25.5 KB | |
во Франции обострилась проблема инфляции. В этот период во Франции усилились попытки коммунистов дискредитировать американскую помощь или отказаться от нее а партия де Голля Объединение французского народа РПФ желая уберечь страну от коммунизма стремилась к власти и изменению государственного строя. | |||
30716. | Развитие социально-политического кризиса в Европе в начале 1920-х гг | 22 KB | |
: сильный рост промышленного правительства в США Франции в результате 1 мировой войны они обогатились. Основой промышленного подъема был технический прогресс новые технологии новые отрасли автомобили Увеличение концентрации и централизации капитала усиления мощи корпораций смена промышленности и банков рост финансового капитала. Рост благотворительности для поддержания социальной стабильности. | |||
30717. | ФРГ: переход к новой «восточной политике». Договор с СССР от 12 августа 1970 г | 27 KB | |
Брандт с 1969 канцлер ФРГ лидер социалдемократов. Подтверждалось что Западный Берлин не является частью территории ФРГ и устанавливался тройной механизм взаимоотношений между компетентными органами ГДР Западного Берлина и ФРГ по вопросам регулирования транзитных перемещений граждан транспортного телефонного и телеграфного сообщения и пр. Но Западный Берлин имел международные соглашения заключенные ФРГ поэтому ФРГ получила право представлять интересы жителей Западного Берлина в международных организациях по вопросам не... | |||