0.3.«Залізний трикутник» у менеджменті програмних проектів
В практиці управління проектами з розробки ПЗ використовується поняття «залізного трикутника», який визначає обмеження на найважливіші параметри програмного проекту: обсяг робіт, час та ресурси (рис. 1.1).
Рис. 1.1. «Залізний трикутник» – обмеження програмного проекту
Відповідно до правила «залізного трикутника» для забезпечення успіху програмного проекту необхідно, щоб фіксованими залишалися не більш, ніж дві його вершини, інакше проект буде перевантажений обмеженнями.
А. Коуберн пропонує додати до правила «залізного трикутника» нову вершину – процес і представити його таким чином, як зображено на рис. 1.2.
Рис. 1.2. Модифікований «залізний трикутник»
Необхідність введення додаткової вершини пояснюється наявністю на практиці проектів, у яких фіксованими є всі три вершини традиційного трикутнику, однак ці проекти залишаються успішними.
Діяльність з розробки, впровадження і супроводу ПЗ – це інтелектуальна діяльність, яка, як правило, здійснюється колективно, включає в себе окремі складові (етапи моделі SLC), що передбачають поділ праці та інтенсивний обмін інформацією між учасниками, характеризується інноваційною природою, складністю, високою здатністю до змін, відносно великою долею витрат на оплату праці у загальній структурі витрат. Дана діяльність передбачає не лише розробку і поставку програмного продукту, а й супровідної документації до нього, надання послуг з впровадження, що передбачають встановлення програмного продукту у замовника, його інтеграцію з існуючою апаратно-програмною інфраструктурою, проведення навчання персоналу, а також послуги супроводу, які передбачають модифікацію продукту після його поставки, усунення помилок у самому продукті та супровідній документації до нього, здійсненні будь-яких інших операцій по підтримці продукту, передбачених домовленостями між розробником і клієнтом.
0.4.Еволюція підходів до управління проектами інформатизації
Основна проблема невдач більшості проектів інформатизації полягає, насамперед, у неврахуванні специфіки ПЗ як особливого виду інтелектуальної діяльності, насамперед, колективної діяльності.
Спочатку діяльність з розробки ПЗ розглядалася як наукова діяльність (50-ті рр. XX ст.), оскільки ПЗ у той час використовувалося для наукових розрахунків, пізніше – як математична чи інженерна.
Діяльність з розробки ПЗ почала розглядатися як будь-яка інша самостійна діяльність з розробки ринкового продукту в зв’язку зі створенням концепції життєвого циклу ПЗ (SLC, Software Life Cycle), що стала наслідком проведеної у жовтні 1968 р. в німецькому м. Гармиш конференції підкомітету НАТО з науки і техніки. Модель SLC отримала назву «каскадної» чи «водоспадної», її графічне представлення SLC зображено на рис. 1.1.
Рис. 1.1. Каскадна модель життєвого циклу розробки ПЗ SLC
В даний час модель SLC вважається застарілою і у «чистому» вигляді майже не застосовується, однак вона стала основою практично всіх сучасних моделей вивчення життєвого циклу розробки ПЗ, термінологія та послідовність етапів SLC були запозичені більш досконалими моделями, тому їх сутність та значення для характеристики діяльності з розробки ПЗ не втратили своєї актуальності в наш час.
Відповідно до рис. 1.1 діяльність з розробки ПЗ фактично включає 9 послідовних етапів. Узагальнено прийнято виділяти чотири етапи: проектування, розробка, впровадження та супровід. Проектування включає перші три етапи SLC (дослідження концепції, дослідження системи, вимоги), розробка включає четвертий етап SLC (розробка проекту), впровадження включає п’ятий та шостий етапи (впровадження та встановлення), супровід – останні три етапи (встановлення, експлуатація та підтримка, виведення із експлуатації). Для цілей даного дослідження етап «проектування» буде спрощено розглядатися як складова етапу «розробка», оскільки з економічного погляду результатом послідовного виконання цих двох етапів буде ПЗ як товар, який виступатиме об’єктом економічних відносин між розробником і клієнтом у наступних етапах впровадження та супроводу.
Іноді як окремий етап каскадної моделі виділяється тестування, однак цей етап доцільно виділяти лише для тих моделей, які передбачають ітераційне виконання чи повернення на попередній етап, у оригінальній каскадній моделі тестування є складовою частиною етапу розробки проекту і звичайно окремо не виділяється.