Download - реалізація проекту
![Page 1: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/1.jpg)
![Page 2: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/2.jpg)
План
1. Робоче планування.2. Принципи кількісного управління.3. Завершення проекту.
![Page 3: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/3.jpg)
Управління - це "розчленування”, аналіз, визначення послідовності дій, конкретна реалізація.
1.Робоче планування
![Page 4: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/4.jpg)
Елементарна робота, як правило, являє собою окрему функціональну вимогу до програмного продукту чи запит на зміну, над яким послідовно працюють:
–бізнес-аналітик; –проектувальник; –розробник; –тестувальник; –документаліст;
Трудомісткість елементарної роботи кожного з виконавців повинна бути від 4 до 20 люд. * рік.
![Page 5: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/5.jpg)
Для робочого планування доцільно використовувати систему управління завданнями або «баг трекінга» (“bugtracking” – система відслідковування помилок), оскільки вона дозволяє задавати послідовність переходів завдання від виконавця до виконавця, керувати пріоритетами робіт і адекватно відстежувати їх статус: –аналіз; –проектування; –кодування; –тестування;
–документування.
![Page 6: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/6.jpg)
В залежності від рівня професіоналізму і зрілості команди проекту розподіл робіт може здійснюватися або директивно з жорсткою постановкою терміну і контролем виконання кожного завдання, або ці повноваження делегуються виконавцям.
![Page 7: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/7.jpg)
У цьому випадку вони самі вибирають задачі послідовно у відповідність з пріоритетами, а їх виконання аналізується періодично на статус мітингу. Можна рекомендувати щотижневі збори за статусом проекту всієї команди або, якщо проект досить великий, то ключових його приватників: керівників підпроектів і лідерів команд. Гарний час для цього ранок понеділка.
![Page 8: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/8.jpg)
Обговорюються, як правило, лише три запитання:• Загрози і проблеми ;• Аналіз результатів за тиждень;• Уточнення пріоритетів завдань на новий тиждень.
![Page 9: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/9.jpg)
На етапі тестування може бути виявлена помилка проектування і вся робота почнеться заново. Рекомендація - використовувати правило «50/100». Якщо робота по завданню розпочата, то слід враховувати її, як виконану на 50%. А 100% повчає тільки протестована і документована робота.
![Page 10: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/10.jpg)
2.Принципи кількісного управління
Для кожного планового значення повинні бути визначені три області критичності відхилень:
• Допустимі відхилення. Передбачається, що ніяких керуючих впливів не потрібно.
• Критичні відхилення. Потрібен ретельний аналіз причин відхилення і при необхідності застосування коригувальних дій.
• Неприпустимі відхилення. Потрібно терміновий аналіз причин відхилення та обов’язкове застосування коригувальних дій.
![Page 11: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/11.jpg)
Вимірювання необхідно проводити регулярно. Мета – виявити причини наступаючих або можливих критичних і неприпустимих відхилень.
![Page 12: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/12.jpg)
Оскільки головне завдання менеджера утримати проект в межах «залізного» трикутника, то, в першу чергу, необхідно аналізувати відхилення проекту по термінах і витратам.
![Page 13: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/13.jpg)
Суть методу оцінки проекту по освоєному обсягом полягає в наступному. Спочатку оцінюється відхилення від графіка SV (Shedule Variance) в грошових одиницях:
SV = EV – PV, де EV (Earned Value) – освоєний обсяг. PV (Planned Value) – плановий обсяг.
![Page 14: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/14.jpg)
Якщо ми випереджаємо графік, то це не обов’язково означає що проект йде успішно. Добре це чи погано залежить від значення іншого показника методу освоєного обсягу: CV (Cost Variance) – відхилення за витратами, яке оцінюється за формулою:
CV = EV – AC, деEV (Earned Value) – освоєний обсяг.AC(Actual Cost) – фактичні витрати.
![Page 15: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/15.jpg)
Від’ємне значення відхилення за витратами означає, що ми перевищили бюджет, що, в загальному випадку, не дуже добре. Але якщо термін завершення проекту для нас має вищий пріоритет, і наші прогнозовані витрати по завершенню проекту не перевищують планових з урахуванням управлінського резерву (рисунок 1), то в цьому випадку можна вважати, що проект виконується успішно.
![Page 16: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/16.jpg)
Рисунок 1 – Оцінка і прогноз показників за методом освоєного обсягу
![Page 17: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/17.jpg)
Відхилення від бюджету і за термінами в абсолютних грошових одиницях недостатньо для характеристики проектів різних масштабів. Наочніші відносні показники: індекс виконання термінів SPI (Schedule Performance Index)
SPI = EV / PVі індекс виконання вартості CPI (Cost Performance Index)
CPI = EV / AC,які характеризують проект незалежно від його розміру. Якщо значення обох індексів більше 1, то це свідчить про благополучний стан в проекті.
![Page 18: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/18.jpg)
В управлінні програмним проектом доцільно застосовувати ще такі вимірні показники:
• показник прогресу проекту • стабільність проекту • середня продуктивність
![Page 19: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/19.jpg)
Ще одна група кількісних показників, які слід спостерігати в ході реалізації проекту, характеризує якість програмного продукту:
- Дефектність продукту – кількість виявлених дефектів на одиницю об’єму продукту (наприклад, KSLOC).
- Частка не усунених дефектів – відношення кількості незакритих максимально критичних і критичних дефектів до кількості виявлених невідповідностей.
- Середні витрати на супровід – середні трудовитрати на виправлення одного дефекту. Високе значення цього показника може свідчити про неякісну архітектуру програмного продукту.
- Документованість коду – визначає відсоток рядків вихідного коду з коментару по відношенню до загальної кількості рядків.
![Page 20: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/20.jpg)
Головна мета цієї фази - перевірити і передати замовникові результат проекту. Для цього необхідно виконати приймально-здавальні роботи у відповідності з процедурою приймання, яка має бути визначена заздалегідь на самій ранній стадії проекту.
Результати проекту повинні бути передані у впровадження або супроводження, або належним чином законсервовані для подальшого використання. Не повинно залишатися «завислих» робіт за проектом.
3.Фаза завершення проекту
![Page 21: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/21.jpg)
Всі проекти і особливо провальні проекти повинні завершуватися підсумковим звітом, якщо компанія не хоче «наступати на одні й ті ж граблі». Пам'ятаємо про те, що «вчорашні проблеми, це сьогоднішні ризики».
![Page 22: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/22.jpg)
Підсумковий звіт повинен містити таку інформацію:
Підсумки проекту:- Досягнення цілей проекту- Додаткові корисні результати- Фактичні терміни- Фактичні витрати- Обгрунтування відхилення від цілей- Відхилення результатів від вимог
![Page 23: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/23.jpg)
Уроки проекту:- Проблеми проекту та способи їх вирішення- Матеріали програмні компоненти для подальшого використання- Пропозиції щодо зміни технологій або стандартів компаніїНа фазі завершення бажано реалізувати і
план мотивації учасників проектної команди.
![Page 24: реалізація проекту](https://reader035.vdocuments.site/reader035/viewer/2022062220/5589b8a8d8b42a223e8b4573/html5/thumbnails/24.jpg)
Кінець