- •Лекція 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.Управління сторонніми компонентами при реалізації програмних проектів
- •Список літератури
0.2.Особливості програмного забезпечення як предметної сфери управління проектами інформатизації
Застарілий підхід, зокрема той, що зустрічається в радянській літературі, визначає програмне забезпечення як набір алгоритмів, викладених алгоритмічною мовою програмування чи у машинних кодах, і призначений для розв’язання певних задач з застосуванням ЕОМ. Зокрема, замість терміну «програмне забезпечення» дуже часто використовувався термін «математичне забезпечення».
Подібне досить вузьке визначення ПЗ є наслідком основної сфери застосування ПЗ у СРСР, якою була, насамперед, сфера наукових розрахунків, відповідно, цікавість для замовника розрахунків становив їх кінцевий результат, а не засіб у вигляді ПЗ, за допомогою якого він досягався. Відповідно ПЗ не розглядалося як самостійний ринковий продукт, підхід до створення якого має бути таким же, як до будь-якого товару чи послуги на ринку. Слід зазначити, що і в СРСР були окремі наукові дослідження з метою уточнення визначення ПЗ, наприклад, дослідженнями у цьому напрямку займався А. Бабій [4], проте, подібні публікації не стали основою більш серйозних наукових досліджень і практичних розробок.
Сучасний підхід розглядає ПЗ, насамперед, як товар, у якому зацікавлений кінцевий споживач.
Сучасні підходи до визначення діяльності з розробки ПЗ розглядають її як таку, що містить три складові: процеси, продукти та ресурси [3]. Власне ПЗ слід розглядати невідривно від вказаних складових, оскільки взаємодія покупця і продавця не обмежується лише здійсненням операції купівлі-продажу, звичайно вона починається з детального аналізу вимог клієнта (чи ринку, коли мається на увазі масове ПЗ), включає взаємодію на етапі розробки і впровадження та продовжується на етапі супроводження продукту.
Даючи визначення сутності ПЗ, Ф. Брукс зазначає, що «сутністю програмного об’єкту є конструкція, що складається із поєднаних разом концепцій: наборів даних, взаємозв’язків між елементами даних, алгоритмів та викликів функцій».
Характеризуючи природу процесу розробки ПЗ, Ф. Брукс виділив дві групи труднощів, з якими зустрічаються розробники: труднощі, що витікають із сутності ПЗ, тобто такі, які внутрішньо властиві природі ПЗ, та труднощі, які супроводять розробку ПЗ на певному етапі розвитку науки і техніки, однак не є такими, що властиві його природі. Труднощами, що витікають із сутності ПЗ були названі такі як складність, узгодженість, здатність до змін, незримість.
Складність ПЗ є характерною особливістю даного продукту цивілізації і проявляється у значно більш високій мірі, ніж у будь-якій іншій галузі людської діяльності. Ф. Брукс підкреслює, що складність є сутністю програмних об’єктів і нелінійно прискорюючими темпами зростає разом зі зростанням їх обсягів. На відміну від продуктів інших галузей людської діяльності, програмні об’єкти не складаються із повторювальних елементів, оскільки такі елементи в процесі розробки мають вилучатися і оформлюватися у вигляді допоміжних модулів. Складність ПЗ визначається великою кількістю можливих його станів, великим обсягом інформації, який містять вихідні коди ПЗ, що в результаті призводить до не лише до технічних, а й до адміністративних проблем.
Головний імператив процесу розробки ПЗ за С. МакКонеллом – боротьба зі складністю.
Г. Буч виділяє чотири головні причини, що викликають складність ПЗ:
складність предметної області розробки ПЗ;
складність управління процесом розробки ПЗ;
необхідність забезпечення достатньої гнучкості ПЗ;
незадовільні способи опису великих дискретних систем [9].
Узгодженість передбачає відсутність інформаційної асиметрії між усіма учасниками процесу розробки ПЗ. Неефективність комунікацій, різне сприйняття системи та припускання неперевірених допущень її розробниками призводять до того, що окремі складові єдиного програмного комплексу, а також взаємозв’язок ПЗ із зовнішніми вимогами стає неузгодженим, що вимагає суттєвих витрат ресурсів на усунення даної проблеми.
Здатність до змін. Характеризуючи здатність ПЗ до змін у порівнянні з іншими результатами людської праці, Ф. Брукс зазначає: «…програмне забезпечення легше змінювати: це чиста думка, нескінченно податлива». Видима в теорії легкість змін ПЗ на практиці виливається у істотні витрати ресурсів, зростання складності та порушення концептуальної цілісності продукту. Об’єктивними факторами, що вимагають змін у ПЗ є необхідність усунення помилок, розширення функціональності та забезпечення сумісності із змінами середовища експлуатації.
Незримість. На відміну від карт, схем, рисунків та інших засобів візуального абстрагування, які можуть бути використані для представлення більшості об’єктів матеріального і нематеріального світу, програмні об’єкти дуже слабко піддаються наглядній візуалізації. Прийняті на практиці нотації блок-схем, моделей даних [15], мови графічного моделювання, такі як, наприклад, UML [43, 10], не здатні достатньо ефективно вирішити проблему наглядного представлення структури ПЗ і принципів його функціонування. Незримість властива природі ПЗ і призводить до складнощів під час його розуміння і осмислення, а також ускладнює процеси обміну інформацією між учасниками проекту.
Таким чином, природі ПЗ властиві об’єктивні складнощі, які, відповідно, відображаються на процес розробки ПЗ.
Слід відзначити, що характерна особливість діяльності з розробки ПЗ – велика доля витрат на робочу силу у загальній суми витрат на розробку. При розробці ПЗ доля витрат на оплату робочої сили за певних умов може досягати майже 100%, в той час коли інженерні компанії з інших сфер діяльності автоматично відносять проекти до проектів з високим ризиком, коли доля витрат на оплату робочої сили перевищує 50% .
Виробничі витрати, тобто витрати власне на відтворення копій розробленого ПЗ, можуть бути надзвичайно низькими у порівнянні з витратами на розробку. Це дозволяє використовувати такі форми розповсюдження програмних продуктів і побудови економічної моделі взаємовідносин з замовниками, які не прийнятні в інших сферах підприємницької діяльності, наприклад, безкоштовне розповсюдження програмного продукту і надання платних послуг впровадження і супроводу.
Що стосується раніше наведеного поділу інновацій на продуктові та процесні, то слід зазначити, що специфіка діяльності з розробки ПЗ передбачає створення нового продукту чи надання нових якостей існуючому продукту у кожному програмному проекті. Таким чином, створення продуктових інновацій є звичайною практикою діяльності компаній-розробників ПЗ, а саму діяльність, на наш погляд, можна охарактеризувати як інноваційну за своєю природою.
