К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Розподіл робіт і ролей у проекті. Найчастіше визначення ролей виконавців проекту відповідає моделі ЖЦ. Склад і кількість співробітників, що входять у групи проекту, залежить від масштабу робіт і досвіду співробітників, які повинні бути настільки кваліфікованими, щоб при розробленні виявляти помилки й неточності в проекті, починаючі з ранніх процесів ЖЦ. З організаційної точці зору менеджер проекту оцінює здібності того чи іншого співробітника під час виконання відповідної роботи з проектування або з тестування системи. Розподіл певного обсягу робіт на частини відповідає розподілу ролей і їхній відповідальності в проекті. Менеджер підбирає для вдалої організації ведення проекту підбирає стиль ведення проекту, наприклад, стиль фірми IBM, який склався при розробленні проекту всесвітньо відомої ОС IBM-370. У ньому проектування ОС і розроблення її продукту виконував головний програміст і група програмістів [8–10]. Важлива роль виконував бібліотекар, який зберігав усі проміжні результати роботи команди (документи, тести, модулі, їхні версії тощо) в бібліотеці проекту. Це надавало можливість усім членам команди сконцентруватися на їхній безпосередній роботі створювати необхідні дані для їхнього зберігання у архіві системи. Кожен член групи тестувальників спілкувався безпосередньо зі всією командою для підготовки відповідних тестових даних щодо тестування модулів і системи у цілому, а головний програміст сам переглядав частини основного проекту й програм. Альтернативна структура ведення проекту описана Вейнбергом (Weinberg) [10], так зване знеособлене програмування, коли всі несуть однакову відповідальність за якість продукту. У проекті не концентруються на персоналіях, критиці піддається програмний продукт, а не члени групи. Така структура підходить для маленьких груп програмістів. Сьогодні в екстремальному програмуванні пропонується відповідальність кожного учасника процесу розроблення проекту за виконання своєї роботи. Моделювання робіт у проекті. У військових відомствах розроблено загальну структуру команди для створення інтегрованого продукту (Integrated Розділ 10 289 Product Development Team) [10]. Модель відповідальності команди наведено на рис. 10.2. Розподіл обов’язків Відповідальність за - планування - виконання плану - кінцевий результат Команда Замовник Вплив на проект: - інспекція елементів/збірка - сприяння - керівництво - поповнення Рис. 10.2. Модель відповідальності осіб в проекті В цьому проекті менеджер керував розподілом обов'язків і встановлював строки для виконання трьох однакових за розміром завдань проекту, що пов’язані з моделюванням робіт у процесах проектування, аналізу й тестування. Учасники проекту працювали за матричною організацією, за якої кожен інженер входив до складу певного типу робіт (проектування або тестування) в одному або більше частинах проекту. Суть такої організації робіт – у загальних законах дисципліни і робіт для всіх типів груп. Під час розроблення проекту обов'язки і ролі співробітників постійно змінюються. Це зручно для проекту, у якому часто змінюються плани, для них встановлюються строки в межах тижня або навіть годин. Показником того, якою мірою виконано завдання, є діаграма запланованих і реально виконаних робіт. Часто ця модель обов'язків поєднується з моделлю «з рук у руки» (hand-off). Вона припускає передачу результатів робіт однієї групи для роботи іншій групи. 10.2. Методи керування і планування проектом Відповідно до світової статистики не всі реалізовані програмні проекти завершуються успішно, 33% з них є провальними з таких причин: – вимоги замовника не виконуються, – проект не вклався у вартість, – проект не вклався в заданий термін, – етапи робіт виявилися неузгодженими один з одним, – менеджер не орієнтує розробників на застосування новітніх методів і засобів програмування, планування й дотримання стандартних угод на застосування моделі ЖЦ. Розділ 10 290 Основні положення керування проектом, завдання й методи якого відпрацьовувалися на технічних проектах (наприклад, перший проект розробки лайнера для перевезення пасажирів з Європи в Америку), призвели до того, що Генрі Гант уперше запропонував діаграмну схему обліку часу виконання проекту. Сьогодні ці завдання сформульовано в такий спосіб [8–11]: – планування проекту й складання графіків робіт виконання проекту, – керування проектними роботами і командою виконавців, – керування ризиками, – оцінювання продукту й використовуваних процесів з метою вдосконалення тощо. На практиці процес керування проектом містить у собі: 1) визначення обсягу робіт в рамках задач проекту з урахуванням наявних ресурсів та обмежень; 2) розроблення стратегії реалізації цілей проекту з урахуванням ризиків та сприятливих можливостей; 3) вибір та обґрунтування моделі ЖЦ, адекватної розміру, складності та цілям проекту; 4) визначення обсягів ресурсів та вартості вирішення задач проекту шляхом оцінювання існуючих варіантів досягнення цілей проекту та з огляду на існуючі ризики та умови; 5) розроблення схеми розподілу робіт та стратегію керування ними; 6) підбір інструментальних і людських ресурсів, необхідних для виконання проекту; 7) складання плану-графіка проекту, що ґрунтується на проведеному розподілі робіт, оцінках технічної та організаційної інфраструктури системи; 8) визначення певних осіб та груп для виконання проекту в цілому; 9) введення в дію планів проекту, надання гарантії виконавцям, що вони забезпечені правилами і нормами процесу ЖЦ та відстеження просування робіт відносно до цих планів і строків; 10) аналіз вимог і усунення відхилень від плану їх виконання та запобігання несподіваних проблем, виявлених у проекті. Мережні методи планування і керування. Це методи призначені для керування роботами проекту за планами, орієнтованими на зменшення строків і раціональне використання ресурсів на ньому. Вони базуються на відповідних моделях, які сприяють побудові раціональних і оптимальних за деякими критеріями плану реалізації проекту і забезпечують чітке виконання цього плану з елементами прогнозування і пошуку найкращого рішення до нього. У СРСР такі методи знайшли застосування при будівництві великих споруджень (атомних станцій, заводів тощо), ремонтних роботах, проектно–конструкторських роботах та ін. У загальному випадку мережна модель відображає часткову упорядкованість робіт і може містить у собі такі характеристики, як вартість, час, ресурси тощо, які відносять до окремих робіт і до проекту в цілому проекту. Мережу проекту можливо розглядати як орієнтований скінчений граф без контурів і відображає відношення передування між роботами, які можливо поставить у відповідні дузі або вершині графа. Розділ 10 291 Формою подання мережної моделі є графова, таблична, діаграмна тощо. Головній сутністю усіх моделей – состав робіт і порядок їх виконання у часі. У таких моделях роботи характеризують процеси їх виконання у часі. Їм відповідають вершини, а дугам відношенням між роботами. В якості вершин могуть бути також події, що позначають номерами або іменами. Цим подіям відповідає завершення однієї або декількох робіт, які попереджують (вхідні) до неї події і що створює умови для початку наступних (вихідних) робіт. Подія, що не має вхідних робіт, зветься початковою, а подія, що не має вихідних робіт – кінцевою або завершеною. Перша подія є ціллю проекту і відповідає досягненню окремих підцілей проекту. Різновидом таких моделей є імовірнісна, в якої параметрам робіт відповідає випадкова величина (наприклад аварія, неотримання потрібних ресурсів, фінансовий кризи тощо). Головне призначення мережних моделей – оцінка фактичного і майбутнього стану проекту і вироблення керуючих дій, а також оцінка ефективності від цих дій та вибору кращих з них. Відомими методами керування проектами є метод критичного шляху СРМ (Critical Path Method) та PERT (Program Evaluation and Review Technique). Останній метод відомий у СРСР як ПЕРТ, що був створений у 1958р. групою керування спеціальними проектами. Розглянемо їх. 10.2.1. Метод критичного шляху – СРМ Цей метод було створено при дослідженні можливості ефективного використання обчислювальної машини Univac на фірмі Dupon для планування й складання планів-графіків великих комплексів робіт для модернізації заводів цієї фірми. Як результат було розроблено раціональний і простий метод (Уолкера - Келлі) керування проектом з використанням ЕОМ, що було названо методом критичного шляху CPM. Критичний шлях — послідовність робіт, з’єднаних початковою і кінцевою роботами, відображаючи найдовший повний шлях у мережі. Наприклад, на , критичний путь (рис.10.3) це: Початок робіт, А1, А3, А6, кінець робіт. Роботи, що лежать на цьому шляху, називають критичними. Саме тривалість критичного шляху визначає найменшу загальну тривалість робіт у проекті в цілому. Час виконання всього проекту в цілому може бути скорочено за рахунок скорочення часу виконання задач на критичному шляху. Роботам на критичному шляху приділяють особливу увагу, оскільки будь-яка затримка виконання задач на критичному шляху призводить до збільшення часу виконання проекту і строків закінчення усього комплексу робіт в плані невиконання проекту своєчасно. Тому менеджер проекту повинний забезпечувати концентрацію уваги, саме, на критичних роботах. Розділ 10 292 початок робіт A1 A3 A6 A4 A2 A5 4 тижні 3 тижні 1 тиждень 2 тижні 2 тижні 3 тижні кінець робіт 3 тижні 2 тижні 1 тиждень Рис. 10.3. Граф завдання строків виконання робіт Іншими словами, основною особливістю методу критичного шляху є можливість керування загальними строками проекту за спостереженням тривалістю окремих робіт важливих завдань, які знаходяться на критичному шляху. Цей метод дозволяє розрахувати можливі календарні графіки виконання комплексу робіт на основі поданої логічної структури мережі й необхідності оцінок часу виконання кожної роботи окремо [8, 11]. Метод базується на графічному представленні робіт і видів дій у проекті із зазначенням орієнтовного часу їхнього виконання. При такому представленні у вершинах розташовуються роботи, а час виконання кожної з робіт під вершинами або на дугах графа, як це показано на рис 10.3. Граф доцільно будувати тоді, коли роботи й час їхнього виконання є заданими (визначеними). Критичний шлях у графі вказує максимальну тривалість робіт на графі (від початкової роботи до кінцевої). У ході реалізації проекту вибираються й виконуються роботи за часом, які не впливають на строки виконання інших (незалежних) робіт проекту або на їхню тривалість. Роботи на критичному шляху можуть скорочуватися за рахунок зміни часу виконання. Подання в такому вигляді робіт граф називають ще мережевою діаграмою, яка у наглядному вигляді відображає роботи, їхні взаємозв'язки, послідовності і час виконання. Цей граф є найпоширенішим схематичним представленням мережі на сьогоднішній день. 10.2.2. Метод аналізу й оцінки проекту – PERT Паралельно з розробкою CPM, у військово-морських силах США було створено (фірма «Буз, Аллен & Гамільтон») метод аналізу й оцінки програм PERT для реалізації проекту розробки ракетної системи «Polaris», що поєднує близько 3800 підрядників із числом операцій більш як 60 тис. [11]. Застосування методу PERT дає змогу керівникам даної програми точно знати, що потрібно робити в кожний момент часу і який виконавець це робить, а також визначати ймовірність своєчасного завершення окремих операцій. Керування Розділ 10 293 програмою створення ракетної системи виявилося настільки успішним, що проект було завершено на два роки раніше запланованого строку. Метод PERT представляється мережевими діаграмами з вершинами–подіями, а робота – у вигляді лінії між двома подіями з наступними призначеннями (рис. 10.4): початкова точка – подія або набір подій, які відбулися до початку виконання даного відповідного процесу за набором умов її початку; кінцева точка процесу – контрольна точка, подія, у якій замовник перевіряє якість отриманих результатів процесу; тривалість – інтервал часу, за який успішно повинно завершитися проміжна подія; строк – дата, до якої процес повністю або частково завершує своє виконання. 1.2 1.1 1.3 2.1 2.2 2.3 2.4 3.1 3.2 9 13 12 11 11 10 5 0 0 15 Рис. 10.4. Вид графа робіт і строків (на дугах) для проекту Дузі, що виходить з початкової вершини й входить у кінцеву вершину, відповідає часова позначка 0, а на інших дугах – час виконання. У графі можуть відображатися циклічні шляхи. За графом проводять аналіз шляхів, тобто даних про тривалість кожного з них. Значна частина сучасних засобів відображення таких мережних графів є візуальною, вершини, а також лінії виділяються кольорами, що з’єднують ці вершини між собою. Розбіжності між цими розглянутими двома методами мережевого графового подання методами CPM і PERT незначні. Однак метод PERT, на відміну від CPM, ураховує виникаючі невизначеності в часі виконання кожної операції. Представлення складніших зв'язків між роботами для завдання вузлів графа у вигляді вершина–подія є більш складним, і тому цей метод рідше використовується на практиці. Розділ 10 294 У цьому методі можливий час виконання операцій оцінюється за допомогою трьох оцінок: оптимістичної (ПРО), песимістичної (P), імовірнісної (B). Цей час визначають за формулою: (ПРО+4В+Р)/6 із зазначенням його на мережевому графіку. 10.2.3. Планування і контроль проекту Планування – це процес розподілу й призначення ресурсів (матеріальних і людських) з урахуванням вартості й часу виконання проекту. Неадекватне планування може спричинити зрив проекту або отримання в середовищі проекту неадекватних результатів. Планування й перепланування – най ємнісна в часі частина керування проектом, починаючи з ранніх процесів проекту. У минулому проекти в галузі ПС не мали планів і оцінок їхньої реалізації і виконання. Сучасні методики пропонують засоби для виправлення цієї ситуації, надаючи в розпорядження менеджерів проектів інструменти й методи, які дозволяють планувати реальні роботи і досягати їхнього виконання. Види планів організації проекту. Планування робіт проекту є першим кроком, на якому створюють плани-графіки, проводять їхній облік, контроль та регулювання. Результатом планування є різні види планів, які відповідають усім видам організаційної діяльності в процесі виконання проекту. Взагалі складаються такі плани: – керування проектом за методами критичного шляху СРМ, PERT або іншими; – план-графік робіт з проектування і строків їх виконання за відповідними методами керування і планування; – розподіл робіт між розробниками відповідно плану; – план досягнення якості, а також плани верифікації, валідації й тестування для отримання результатів проектування; – поставки і регулювання технічних, CASE і людських ресурсів на проекті; – супроводження, змінювання деяких вимог і усунення різних недоліків. Керування проектом охоплює всі вказані плани і може мати в своєму складі додаткові плани, пов’язані з деякими особливостями або вказівками замовника проекту. При формуванні планів проекту встановлюють взаємозв’язок наведених планів з різних сторін розроблення та керування проектом. Процес планування починається на початку проекту, під час аналізу предметної області і визначення вимог до неї. Тобто аналіз проекту виконується за методами СРМ, PERT, системного аналізу, аналізу витрат тощо. Цілі проекту розробляються таким чином, щоб оцінки продукту, були документованими задля подальшого їхнього моніторингу, види діяльності були затвердженими, а групи та розробники виконували підписані плани робіт з проекту. Обґрунтування планів базується на реалістичних (якісних експертних) оцінках щодо робіт та їхнього затвердження керівником і замовником проекту. В Розділ 10 295 плані проекту збалансовується сукупність інструментів, джерел даних, методологій, процесів і процедур, які забезпечують відповідні трудовитрати на запланованих роботах. У ньому враховуються зовнішнє середовище – інфраструктура організації, інструменти, людські ресурси, політика щодо до персоналу, ситуації на ринку тощо. План проекту містить у собі календарний план, перелік документів та плану розроблення програмного продукту. Цей план враховує задану вартість, об’єм та план-графік робіт, відстеження ризиків і застосування затверджених методологій і інструментів розроблення проекту. Графік робіт складається за схемою, наведеною на рис. 10.5. Після узгодження плану його з замовником їм користується менеджер. Розроблений план проекту поновлюється протягом ЖЦ для проведення змін за календарним планом і результатами перевірок проекту в контрольних точок. На базі плану розроблення проекту можуть складатися індивідуальні плани робіт кожного члена колективу проекту, які можуть переглядатися і уточнюватися щомісячно за результатами перевірки робіт у проекті. Визначення етапів Зв'язок між етапами Оцінка ресурсів для етапу Розподіл персоналу за етапами Визначення графіка Вимоги до проекту Графік Рис. 10.5. Кроки складання графіка робіт на проекті При плануванні за методом PERT подія або дата в плані є певною віхою здійснення окремих робіт у проекті. Віха слугує відображенню і оцінки стану завершення тих або інших робіт. У проекті менеджери використовують віхи для того, щоб позначити важливі проміжні результати, яких треба буде досягти в процесі реалізації проекту. Послідовність віх, визначених менеджером, часто називається планом за віхами або за подіями. Визначення плану досягнення відповідних віх утворює календарний план. Планування за методом СРМ або діаграми Ганта [11–13], які допомагають: – структуризації робіт на основні компоненти й підкомпоненти; – визначенню напрямів діяльності для досягнення комплексу цілей; – розподілу відповідальних за виконання окремих робіт у проекті; – отриманню звітності й узагальнення інформації про усякі дії проект. План можна представляти етапами, станами і діяльностями (рис.10.6). У плані відображаються зв'язки між процесами, визначається інтервал часу для виконання кожної діяльності, час початку й завершення, а також опис різних видів демонстрацій функцій, надійності, захисту для замовника. До документів плану Розділ 10 296 належать: комплект опису виконання заданого набору робіт і операцій та різних видів комунікації. Рис 10.6. Операційний граф плану проекту Крім того, є діаграма Ганта — цегоризонтальна лінійна діаграма, на якій завдання проекту представляються строками у вигляді відрізків часу і мають дати початку й закінчення, можливо із затримками й іншими часовими параметрами. |