While доки проект не завершиться або не буде зупинений loop

Лекція № 4

Тема: Керування проектами розробки програмного забезпечення. Планування проекту, графік робіт, керування ризиками.

Мета: Після вивчення лекції студенті повинні:

· розуміти відмінності між управлінням програмними проектами і управлінням інженерними проектами інших типів;

· знати основні завдання, що стоять перед керівником програмного проекту;

· розуміти значущість і роль етапу планування проекту серед усіх етапів процесу створення ПО;

· знати графічні способи представлення графіків робіт;

· мати уявлення про типи ризиків, що виникають при реалізації програмних проектів, і процеси управління цими ризиками.

Управління проектами.

Проблеми управління програмними проектами уперше проявилися в 60-х - початку 70-х років, коли провалилися багато великих проектів по розробці програмних продуктів. Були зафіксовані затримки в створенні ПО, воно було ненадійним, витрати на розробку у декілька разів перевершували первинні оцінки, створені програмні системи часто мали низькі показники продуктивності [60]. Провали цих проектів обумовлювалися не лише некомпетентністю керівників і програмістів. Навпаки, в цих великих пошукових проектах брали участь люди, рівень кваліфікації яких був явно вище за середнє. Причини провалів коренилися в тих підходах, які використовувалися в управлінні проектами. Вживана методика була заснована на досвіді управління технічними проектами і виявилася неефективною при розробці програмного забезпечення.

Тут важливо зрозуміти різницю між професійною розробкою ПО і любительським програмуванням. Необхідність управління програмними проектами витікає з того "прикрого" факту, що процес створення професійного ПО завжди є суб'єктом бюджетної політики організації, де воно розробляється, і має тимчасові обмеження. Робота керівника програмного проекту за великим рахунком полягає в тому, щоб гарантувати виконання цих бюджетних і тимчасових обмежень з урахуванням бизнес-целей організації відносно ПО, що розробляється.

Ключовою категорією, що бере участь в процесі управління проектами, є обмеження. Відомий закон Лермана свідчить: "Будь-яку технічну проблему можна здолати, маючи досить часу і грошей", а наслідок Лермана уточнює: "Вам ніколи не буде вистачати або часу, або грошей". Якщо попросити менеджера описати, як він розуміє своє основне завдання у виконанні проекту, то він дасть відповідь: "Забезпечити виконання робіт в зазначений термін, у рамках виділених коштів, відповідно до технічного завдання". Саме ці три моменти: час, бюджет і якість робіт знаходяться під постійною увагою керівника проекту. Їх також можна назвати основними обмеженнями, що накладаються на проект.

Ці три основні обмеження (терміни, витрати і якість результату) взаємозв'язані. Для ілюстрації взаємозв'язки використовують трикутник обмежень, в якому якість, час і гроші інтерпретуються площами внутрішніх трикутників.

У цьому трикутнику центр і верхня вершини фіксовані, а нижні вершини можуть переміщатися. Трикутник ілюструє, що будь-яке скорочення фінансів або часу веде до скорочення якості, а збільшення якості може бути досягнуте за рахунок збільшення фінансування або термінів.

Менеджери проектів покликані спланувати усі етапи розробки програмного продукту. Вони також повинні контролювати хід виконання робіт і дотримання усіх необхідних стандартів. Постійний контроль за ходом виконання робіт потрібний для того, щоб процес розробки не виходив за обмеження терміну розробки і бюджетні обмеження. Хороше управління не гарантує успішного завершення проекту, але погане управління обов'язково приведе до його провалу. Це може виразитися в затримці термінів здачі готового ПО, в перевищенні кошторисної вартості проекту і в невідповідності готового ПО специфікації вимог.

Керівники програмних проектів виконують таку ж роботу, що і керівники технічних проектів. В той же час процес розробки ПО істотно відрізняється від процесів реалізації технічних проектів, що породжує певні складнощі в управлінні програмними проектами. Приведемо невеликий список цих відмінностей.

1. Програмний продукт нематеріальний. Менеджер суднобудівельного проекту або проекту спорудження будівлі бачить результати виконання свого проекту. Якщо реалізація проекту відстає від графіку, це також видно своїми очима, оскільки частина конструкції не завершена. В протилежність цьому програмне забезпечення нематеріальне. Його не можна побачити або поторкати. Менеджер програмного проекту не бачить процес "зростання" ПО, що розробляється. Він може покладатися тільки на документацію, яка фіксує процес розробки програмного продукту.

2. Не існує стандартних процесів розробки ПО. На сьогодні не існує чіткої залежності між процесом створення ПО і типом створюваного програмного продукту. Інші технічні дисципліни мають тривалу історію, процеси розробки технічних виробів багаторазово випробувані і перевірені. Процеси створення більшості технічних систем добре вивчені. Вивченням же процесів створення ПО фахівці займаються тільки декілька останніх років. Тому доки не можна точно передбачити, на якому етапі процесу розробки ПО можуть виникнути проблеми, загрозливі усьому програмному проекту.

3. Великі програмні проекти - це часто "одноразові" проекти. Великі програмні проекти, як правило, значно відрізняються від проектів, реалізованих раніше. Тому, щоб зменшити невизначеність в плануванні проекту, керівники проектів повинні мати дуже великий практичний досвід. Але постійні технологічні зміни в комп'ютерній техніці і комунікаційному устаткуванні знецінюють попередній досвід. Знання і навички, накопичені досвідом, можуть не затребуватися в новому проекті.

 

Перераховане вище може привести до того, що реалізація проекту вийде з часового графіку або перевищить бюджетні асигнування. Програмні системи частенько виявляються новинками як в "ідеологічному", так і в технічному плані. Технічні проекти, які є інноваційними (наприклад, нова транспортна система), також часто порушують тимчасові графіки робіт. Тому, передбачаючи можливі проблеми в реалізації програмного проекту, слід завжди пам'ятати, що багатьом з них властиво виходити за рамки тимчасових і бюджетних обмежень.

Управління програмними проектами - тема дуже велика. Тому в справжній лекції дається тільки введення в цю тему і розглядається три основні процеси, виконуваних у рамках управління проектами, а саме: планування проекту, складання графіку робіт і управління рисками. Процеси управління

Неможливо описати і стандартизувати усі роботи, що виконуються менеджером проекту по створенню ПО. Ці роботи дуже істотно залежать від організації, де виконується розробка ПО, і від типу створюваного програмного продукту. Але у будь-якому випадку більшість менеджерів відповідальна за виконання усіх або деяких з приведених нижче процесів управління.

· - Написання пропозицій по створенню ПО.

· - Планування і складання графіку робіт із створення ПО.

· - Оцінювання вартості проекту.

· - Контроль за ходом виконання робіт.

· - Підбір персоналу.

· - Написання звітів і представлень.

Перша стадія програмного проекту може складатися з написання пропозицій по реалізації цього проекту. Пропозиції повинні містити опис цілей проектів і способів їх досягнення. Вони також зазвичай включають оцінки фінансових і часових витрат на виконання проекту. При необхідності тут можуть приводитися обгрунтування для передачі проекту на виконання сторонньої організації або команді розробників.

Написання пропозицій - дуже відповідальна робота, оскільки для багатьох організацій питання про те, чи буде проект виконуватися самою організацією або розроблятися за контрактом сторонньою компанією, є критичним. Неможливо дати яких-небудь рекомендацій по написанню пропозицій, багато що тут залежить від досвіду менеджера.

На етапі планування проекту визначаються процеси, етапи і отримані на кожному з них результати, які повинні привести до виконання проекту. Реалізація цього плану приведе до досягнення цілей проекту. Визначення вартості проекту безпосередньо пов'язане з його плануванням, оскільки тут оцінюються ресурси, що вимагаються для виконання плану.

Контроль за ходом виконання робіт (моніторинг проекту) - це безперервний процес, що триває протягом усього терміну реалізації проекту. Менеджер повинен постійно відстежувати хід реалізації проекту і порівнювати фактичні і планові показники виконання робіт з їх вартістю. Хоча багато організацій мають механізми формального моніторингу робіт, досвідчений менеджер може скласти ясну картину про стадію розвитку проекту просто шляхом неформального спілкування з розробниками.

Неформальний моніторинг часто допомагає виявити потенційні проблеми, які в явному виді можуть виявитися пізніше. Наприклад, щоденне обговорення ходу виконання робіт може виявити окремі недоробки в створюваному програмному продукті. Замість очікування звітів, в яких буде відбитий факт тієї, що "пробуксувала" графіку робіт, менеджер може обговорити з фахівцями проблеми програмістів, що намічаються, і не допустити зриву графіку робіт.

Протягом реалізації проекту зазвичай відбувається декілька формальних контрольних перевірок ходу виконання робіт із створення ПО. Такі перевірки повинні дати загальну картину ходу реалізації проекту в цілому і показати, наскільки вже розроблена частина ПО відповідає цілям проекту.

Час виконання великих програмних проектів може займати декілька років. Протягом цього часу мети і наміру організації, що замовила програмний проект, можуть істотно змінитися. Може виявитися, що програмний продукт, що розробляється, став вже непотрібним або початкові вимоги до створюваного ПО просто застаріли і їх необхідно кардинально міняти. У такій ситуації керівництво організації-розробника може прийняти рішення про припинення розробки ПО або про зміну проекту в цілому з тим, щоб врахувати цілі, що змінилися, і наміри організації-замовника.

Керівники - менеджери проектів зазвичай зобов'язані самі підбирати виконавців для своїх проектів. У ідеальному випадку професійний рівень виконавців повинен відповідати тій роботі, яку вони виконуватимуть в ході реалізації проекту. Проте у багатьох випадках менеджери повинні покладатися на команду розробників, яка далека від ідеальної. Така ситуація може бути викликана наступними причинами.

1. Бюджет проекту не дозволяє притягнути висококваліфікований персонал. У такому разі за меншу плату притягуються менш кваліфіковані фахівці.

2. Бувають ситуації, коли неможливо знайти фахівців необхідної кваліфікації як в самій організації-розробнику, так і поза нею. Наприклад, в організації "кращі люди" можуть бути вже зайняті в інших проектах.

3. Організація хоче підвищити професійний рівень своїх працівників. В цьому випадку вона може притягнути до участі в проекті недосвідчених або недостатньо кваліфікованих працівників, щоб вони набули необхідного досвіду і повчилися у досвідченіших фахівців.

Таким чином, майже завжди підбір фахівців для виконання проекту має певні обмеження і не є вільним. В той же час необхідно, щоб хоч би декілька членів групи розробників мали кваліфікацію і досвід, достатні для роботи над цим проектом. Інакше неможливо уникнути помилок в розробці ПО.

Менеджер проекту зазвичай зобов'язаний посилати звіти про хід його виконання як замовникові, так і підрядним організаціям. Це мають бути короткі документи, засновані на інформації, витягуваній з детальних звітів про проект. У цих звітах має бути та інформація, яка дозволяє чітко оцінити міру готовності створюваного програмного продукту.

Планування проекту

Ефективне управління програмним проектом безпосередньо залежить від правильного планування робіт, необхідних для його виконання. План допомагає менеджерові передбачати проблеми, які можуть виникнути на яких-небудь етапах створення ПО, і розробити превентивні заходи для їх попередження або рішення. План, розроблений на початковому етапі проекту, розглядається усіма його учасниками як керівний документ, виконання якого повинне привести до успішного завершення проекту. Цей первинний план повинен максимально детально описувати усі етапи реалізації проекту. Тут відмітимо, що, окрім розробки плану проекту, на менеджера лягає обов'язок розробки інших видів планів. Ці види планів коротко описані в таблиці.

Таблиця. Види планів

План	Опис
План якості	Описує стандарти і заходи по підтримці якості ПО, що розробляється
План атестації	Описує способи, ресурси і перелік робіт, необхідних для атестації програмної системи
План управління конфігурацією	Описує структуру і процеси управління конфігурацією
План супроводу ПО	Пропонує план заходів, що вимагаються для супроводу ПО в процесі його експлуатації, а також розрахунок вартості супроводу і необхідні для цього ресурси
План по управлінню персоналом	Описує заходи, спрямовані на підвищення кваліфікації членів команди розробників

У лістингу показаний процес планування створення ПО у вигляді псевдокоду. Тут зроблений акцент на тому, що планування - це ітераційний процес. Оскільки в процесі виконання проекту постійно поступає нова інформація, план повинен регулярно переглядатися. Важливими чинниками, які повинні враховуватися при розробці плану, є фінансові і ділові зобов'язання організації. Якщо вони змінюються, ці зміни також повинні знайти віддзеркалення в плані робіт.

Лістинг. Процес планування проекту

Визначення проектних обмежень

Первинна оцінка параметрів проекту

Визначення етапів виконання проекту і контрольних відміток

while доки проект не завершиться або не буде зупинений loop

Складання графіку робіт

Початок виконання робіт

Очікування закінчення чергового етапу робіт

Відстежування ходу виконання робіт

Перегляд оцінок параметрів проекту

Зміна графіку робіт

Перегляд проектних обмежень