- •Лекція 0.Уведення в управління проектами
- •0.1.Введення до проектного менеджменту
- •0.2.Особливості програмного забезпечення як предметної сфери управління проектами інформатизації
- •0.3.«Залізний трикутник» у менеджменті програмних проектів
- •0.4.Еволюція підходів до управління проектами інформатизації
- •0.5.Основні специфічні особливості проектів з розробки програмного забезпечення
- •Лекція 1.Класифікація і оточення проектів
- •1.1.Класифікація проектів
- •1.3.Ресурси і обмежуючі фактори проектів інформатизації
- •1.4.Ролі учасників проектів інформатизації
- •1.5.Вплив зовнішніх факторів на виконання проектів інформатизації
- •1.2.Основні складові зовнішнього та внутрішнього середовища проектів інформатизації
- •Лекція 2.Життєвий цикл проекту
- •2.1.Поняття життєвого циклу програмного проекту
- •2.2.Зв’язок моделі життєвого циклу програмного проекту і підходів до управління та показників програмних проектів
- •2.3.Неструктурований життєвий цикл програмних проектів
- •2.4.Каскадна модель життєвого циклу програмних проектів
- •2.6.Модель життєвого циклу на основі розробки прототипів
- •2.7.Інкрементна модель життєвого циклу програмного проекту
- •2.8.Спіральна модель проектування
- •2.9. Ітеративна модель життєвого циклу програмного проекту
- •Лекція 3.Використання стандартів життєвих циклів інформаційних систем
- •3.1.Поняття стандартів якості і їх використання у сфері проектів інформатизації
- •3.2.Найважливіші стандарти якості і моделі процесу управління програмними проектами
- •3.3.Загальна характеристика групи стандартів sei cmm/cmmi
- •3.4.Стандарт sei sw-cmm. Стандарт sei cmmi
- •4.1.Фундаментальні принципи і проблеми оцінки економічних параметрів програмних проектів
- •4.2.Найпростіша формула розрахунку вартості проекту
- •4.3.Розрахунок трудовитрат на основі хронологічних даних
- •4.4.Одиниці оцінки розміру програмного забезпечення
- •4.5.Кількість рядків коду при оцінці розміру програмного забезпечення
- •4.6.Функціональні точки для оцінки розміру програмного забезпечення
- •4.7.Метод точок властивостей при оцінці розміру програмного забезпечення
- •4.8.Метод об’єктних точок при оцінці розміру програмного забезпечення
- •4.9.Метод побудови бліц-моделі при оцінці обсягу проекту
- •4.10.Методика Wideband Delphi при оцінці розміру програмного проекту
- •4.11.Модель cocomo для оцінки економічних параметрів програмних проектів
- •4.12.Модель cocomo II для оцінки економічних параметрів програмних проектів
- •4.13.Модель slim для оцінки економічних параметрів програмних проектів
- •Лекція 5.Сучасні методології управління програмними проектами
- •5.1.Введення до методологій управління програмними проектами
- •5.2.Загальна характеристика методології msf в управлінні програмними проектами
- •5.3.Моделі, які складають методологію msf
- •5.4.Модель проектної групи msf
- •5.5.Модель процесу msf
- •5.6.Планування з урахуванням ризиків у msf
- •5.7.Орієнтація на випуск версій продукту у msf
- •5.8.Орієнтація на продукт у msf
- •5.9.Загальна характеристика методології rup в управління програмними проектами
- •5.10.Виміри процесу розробки у методології rup
- •5.11.Статичний зміст процесу у rup
- •5.12.Життєвий цикл програмного проекту згідно з методологією rup
- •5.13.Методології швидкої розробки при управлінні програмними проектами
- •Лекція 6.Автоматизація функцій управління проектами
- •6.1.Загальна характеристика програмного інструментарію, який використовується для автоматизації управління проектами інформатизації
- •6.2.Сучасні інструменти, які використовуються учасниками програмних проектів
- •6.3.Інструментарій для планування і контролю за ходом виконання проекту
- •6.4.Засоби для оцінки економічних параметрів і ризиків програмних проектів
- •6.5.Інструментарій для контролю версій та управління змінами при виконанні програмних проектів
- •6.6.Інструментарій для управління вимогами при реалізації програмних проектів
- •6.7.Засоби забезпечення взаємодії учасників при виконанні програмних проектів
- •Лекція 7.Управління вимогами при реалізації програмних проектів
- •7.1.Основі положення управління вимогами при реалізації програмних проектів
- •7.2.Забезпечення взаємодії із замовником при реалізації програмних проектів
- •7.3.Планування, визначення пріоритетів, оцінка ризику та контроль виконання вимог
- •7.4.Управління вимогами на основі підходу до ітеративного створення версій при реалізації програмних проектів
- •7.5.Інтеграція управління вимогами у загальний процес управління програмними проектами
- •Лекція 8.Менеджмент конфігурації програмного забезпечення
- •8.1.Основні положення менеджменту конфігурації при реалізації програмних проектів
- •8.2.Контроль змін як одна із складових менеджменту конфігурацій
- •8.3.Контроль версій як одна із складових менеджменту конфігурацій
- •8.4.Контроль випусків як одна із складових менеджменту конфігурацій
- •8.5.Поняття кортежу програми, кортежу проекту та паспорту проекту при виконанні програмних проектів
- •8.6.Інструментальні засоби менеджменту конфігурацій програмного забезпечення
- •8.7.Стандартизація внутрішніх процесів при виконанні програмних проектів
- •Лекція 9.Управління персоналом при реалізації програмних проектів
- •9.1.Основні положення менеджменту персоналу при реалізації програмних проектів
- •9.2.Основні принципи розподілення ролей учасників програмного проекту
- •9.3.Забезпечення взаємодії учасників програмного проекту
- •9.4.Мотивація виконавців програмних проектів
- •9.5.Корпоративна культура при реалізації програмних проектів
- •9.6.Управління віддаленими учасниками програмних проектів
- •Лекція 10.Аутсорсинг програмних проектів
- •10.1.Основі положення аутсорсингу програмних проектів
- •10.2.Пошук замовників аутсорсингового проекту
- •10.3.Управління взаємодією із замовниками аутсорсингового проекту
- •10.4.Пошук виконавців аутсорсингового проекту
- •10.5.Управління виконавцями аутсорсингового проекту
- •Лекція 11.Безперервне поліпшення процесів виконання програмних проектів
- •11.1.Основні положення інноваційного менеджменту при виконанні програмних проектів
- •11.2.Інновації у сфері програмного забезпечення і їх вплив на параметри «залізного трикутника»
- •11.3.Безперервне поліпшення виконання програмних проектів як основна ціль проектного менеджменту
- •11.4.Забезпечення конкурентноздатності середовища розробки
- •11.5.Управління сторонніми компонентами при реалізації програмних проектів
- •Список літератури
2.4.Каскадна модель життєвого циклу програмних проектів
Як було зазначено раніше, першою загальновизнаною моделлю життєвого циклу програмного проекту вважається модель SLC. Однак незворотній характер етапів моделі не відображав прийняту у практиці більшості компаній-розробників ПЗ можливість повернення на попередні етапи.
Рис. 3.2. Каскадна модель життєвого циклу розробки ПЗ SLC
Як уже зазначалося, в даний час модель SLC вважається застарілою і у «чистому» вигляді майже не застосовується, однак вона стала основою практично всіх сучасних моделей вивчення життєвого циклу розробки ПЗ, термінологія та послідовність етапів SLC були запозичені більш досконалими моделями, тому їх сутність та значення для характеристики діяльності з розробки ПЗ не втратили своєї актуальності в наш час.
2.5.V-подібна модель життєвого циклу
На заміну каскадній моделі була запропонована V-подібна (шарнірна) модель, яка покликана усунути зазначені недоліки, зокрема поєднати етапи постановки завдання та перевірки його відповідності специфікаціям (рис. 3.4).
Однак «інженерний» підхід до розробки ПЗ, реалізований у моделі SLC та V-подібній моделі, виявився неконкурентноздатним, особливо для крупних проектів – тривала поетапна розробка проекту призводила до того, що процес розробки часто виходив за рамки встановленого бюджету та часових обмежень, а кінцевий продукт часто виявлявся таким, що запізнювався з виходом на ринок.
Рис. 3.3. V-подібна модель управління процесом розробки ПЗ
З погляду управління інноваціями, слід зазначити, що моделі SLC та V-подібна модель не пристосовані до можливості впровадження ефективного інноваційного менеджменту. Реалізація проекту може тривати декілька років, однак, відповідно до даних моделей, розроблені на його початку вимоги та план реалізації не враховують науково-технічний прогрес, вони орієнтовані на використання тих технологій, які були актуальними на початок робіт над проектом, що в результаті призводить до створення продукту який є морально застарілим та неконкурентноздатним ще до свого виходу на ринок.
2.6.Модель життєвого циклу на основі розробки прототипів
Модель ЖЦ на основі розробки прототипів передбачає створення повністю або частково робочих моделей готової системи. Такий підхід схожий до використання зменшених моделей будівель у архітектурі.
Основний недолік моделі – наслідок конфлікту інтересів – можливість бути втягненим у нескінченний цикл вдосконалення продукту ще до його виходу у світ.
2.7.Інкрементна модель життєвого циклу програмного проекту
Інкрементна модель ЖЦ передбачає розробку і поставку продукту частинами.
Перевага моделі – вона дозволяє рухатися вперед, зберігаючи інтереси обох сторін.
Недолік – зростання складності проекту та вартості і тривалості його розробки.
2.8.Спіральна модель проектування
Вирішити основні недоліки моделі SLC покликана спіральна модель, яка відповідно до Б. Боема являє собою рухомий ризиком генератор процесної моделі, тобто являє собою модель процесу, в якій ризик виступає у якості фактору, що примушує її до розвитку.
Дана модель використовується для управління проектами з розробки програмного забезпечення, в яких бере участь значна кількість розробників. Вона має дві головні особливості: перша полягає в тому, що використовується циклічний підхід до поступового нарощування рівня визначеності та реалізації системи в умовах зниження її рівня ризику; друга являє собою набір певних віх (чи контрольних точок), котрі необхідні для того, щоб була можливість відслідковувати реальність впровадження та двостороннє узгодження рішень.
Ризик у даному випадку являє собою ситуації чи можливі випадки, що можуть стати на заваді проекту при досягненні ним певної мети (рис. 3.4).
Рис. 3.4. Діаграма спірального розвитку
Відповідно до рис. 3.4 можна відзначити, що рух до кінцевої точки, який відбувається у напрямку руху годинникової стрілки на даній діаграмі, проходить значну кількість стадій, на кожній з яких, по-перше, відбувається уточнення функціональності кінцевого продукту, а, по-друге, спостерігається постійне зростання кумулятивних затрат на проект, які можна визначити у кожен конкретний момент часу роботи над проектом як абсолютну величину відстані між кожною точкою на спіралі та точкою перетину осей на діаграмі.
На відміну від попередніх розглянутих моделей, спіральна модель значно краще підходить до ефективного управління інноваціями. Окремі витки спіралі розпочинаються з етапів оцінки ризику та планування, які можуть включати також і підбір та оцінку можливих інновацій у діяльності підприємства. Таким чином, кожен виток спіралі може передбачати інноваційну діяльність і розробка може бути спланована з урахуванням переваг, які будуть отримані в результаті впровадження інновацій у роботі підприємства-розробника.
Щоб підтвердити переваги спіральної моделі саме з погляду можливостей впровадження інновацій, Б. Боем наводить наступний приклад, згідно з яким на початку 1980-х рр. одна урядова установа стала замовником потужної інформаційної системи, що повинна була забезпечувати роботу понад однієї тисячі користувачів, розміщувалася у великому будівельному комплексі, мала потужні аналітичні та запитові можливості до великої динамічної бази даних. У контракті на розробку даної інформаційної системи була зафіксована вимога, згідно з якою час реакції системи на дії користувача не повинен перевищувати однієї секунди.
Використовуючи класичний підхід (каскадну модель) до проектування ПЗ і розробивши близько двох тисяч сторінок документів з вимогами, архітектори з програмного забезпечення визначили, що поставлене завдання можна реалізувати, побудувавши систему за Архітектурою А, приблизна вартість якої склала близько 100 млн. дол. США. Однак зазначена сума перевищувала рамки встановленого бюджету і реалізація проекту за таких умов була неможливою.
Лише завдяки створенню прототипу інтерфейсу користувача дослідним шляхом було встановлено, що вимога щодо часу реакції системи на дії користувача, який не повинен перевищувати однієї секунди, є завищеною, і достатньо затримки до чотирьох секунд. В результаті переробки вимог та вибору принципово іншої архітектури системи оціночна вартість системи була знижена до 30 млн. дол. США (рис. 3.5).
Рис. 3.5. Дві архітектури системи: затрати у порівнянні з часом реакції
На рис. 3.5 зображено дві можливі архітектури побудови системи. Кожна з них має свою сферу застосування: архітектура А здатна забезпечити більш високу швидкість реакції системи, проте архітектура B за умов невисоких вимог до швидкості реакції має значно нижчу вартість реалізації.
У тому випадку, коли при проектуванні використовується каскадна модель, можливі варіанти, коли після проектування за умов зміни вимог до системи рівень економії виявиться не достатньо високим, оскільки не розглядаються інші, можливо інноваційні, підходи (у даному випадку, коли використовується архітектура А і рух йде по верхній кривій на рис. 3.5 зліва направо).
Якщо ж за основу використовується спіральна модель, то прототип системи співвідноситься з ризиками. У даному випадку на початку кожного нового витку проектування системи визначається проблема й відшукуються її найбільш оптимальні шляхи вирішення: архітектура B буде обрана як найбільш оптимальний варіант на одній з ітерацій проектування за умов ідентифікації ризику завищених вимог (часу реакції системи менше однієї секунди) та їх зміщення до 4 сек (рис. 3.5).
Таким чином, початок кожного нового витка спіралі може бути здійснений з переоцінки ризиків та визначення рішень і технологій, які доцільно застосувати у проекті. Саме з цієї точки зору спіральна модель значним чином відповідає основним положенням ефективного інноваційного менеджменту: початок кожного нового витка може бути здійснено з визначення нововведень, впровадження яких у процес розробки принесе найбільший економіко-технічний ефект.
