К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Моніторинг проекту. Моніторинг (облік та контроль) забезпечує відстеження «факту відповідно плану» шляхом перегляду надбань та результатів у ході виконання проекту, і вироблення належних заходів з коригування. Ці заходи можуть вміщати виправлення плану розроблення ПС, щоб відобразити у ньому фактичний стан справ щодо надбань та результатів, перепланувати залишкову роботу та/або передбачити в плані дії з вдосконалення виконання роботи. Моніторинг проводять для того, щоб фактичні результати було простежено за планами проекту з метою повернення проекту в планові рамки. При моніторингу аналізуються такі дані: – строки (факт/план); – витрати (матеріальні, трудові) (факт/план або % плану); – виконана робота (% запланованої); – об’єм документів (сторінок); – об’єм програм за кількістю функцій кожного компонента (факт/план або % плану); – об’єм тестування компонентів проекту (виконано/заплановано або % плану); – безвідмовність (кількість збійних тестів/проведених або % проведених); – досягнута коректність (кількість ототожнених та виправлених дефектів розробником/кількість помилок, визначена тестувальником). Менеджер проекту використовує дані, отримані під час моніторингу, а також дані з верифікації та тестування для оцінки проекту в цілому. Розділ 10 297 10.2.4. Оцінювання вартості проекту Однією з робіт на проекті є оцінка їх вартості. Загальна вартість проекту визначається виходячи з вартості окремих частин, умов виконання робіт, наявного штату виконавців, застосованих методів і інструментів. У вартість проекту входить все, що створює імідж проекту: комп'ютери, ПС, обладнання, кімнати, меблі, телефони, модеми, канцелярські товари тощо. Іноді необхідно створити додаткові умови (наприклад, безпека). Додаткові витрати – це вартість засобів і інструментів тестування, кодування або інші CASE системи. Основна оцінка в проекті визначає витрати на розроблення проекту, тобто людино-дні робіт виконавців проекту. Вона виконується на початку проекту й складання його плану. Оцінювання здійснюють «знизу» або «вгору». При наявності застарілої системи вартість екстраполюється на нову з деякими корегуваннями або проводиться песимістична, оптимістична і реальна оцінка шляхом опитування всіх членів робочої групи з виведенням найбільш ймовірної. Головними чинниками визначення вартості проекту є тип і кількість ресурсів, а також період часу, необхідний ресурсам для виконання робіт з проекту. Ресурси планових операцій і їхня тривалість використовуються як ключові входи цього процесу, а як ресурси виступають людські ресурси, їхні тарифні ставки. До ресурсів відносять, зокрема, робочу силу, матеріали, обладнання, послуги, приміщення, інформаційні технології, а також особливі статті витрат, наприклад, врахування рівня інфляції або витрати на непередбачені обставини. Вартісна оцінка ресурсів планових операцій може даватися параметрично, наприклад, через кількість рядків у коді програми або годин робочого часу, витрачених на них. Для оцінки вартості проектів широко застосовується програмне забезпечення з управління проектами з такими засобами: крупноформатні електронні таблиці, а також інструментальні засоби з моделювання і обробки статистичної інформації. Це сприяє швидшому розгляду різноманітних альтернативних варіантів. Оцінка вартості операцій – це кількісна оцінка приблизної вартості ресурсів, необхідних для виконання планових операцій. Розроблення бюджету витрат – це об’єднання оцінок вартості окремих планових операцій або пакетів робіт з метою створення загального базового плану з вартості для визначення ефективності виконання проекту з детальним описом бюджетних запитів, необхідних для вартісної оцінки планових операцій. Алгоритмічні методи оцінки. До них належить модель, у якій відображаються зв'язки між витратами в проекті й чинниками, що на них впливають. Модель – це рівняння, у якому витрати – залежна, а чинники – незалежні змінні. Наприклад, вартість проекту визначається за формулою: E = (a+bS c ) m (X), де S — розмір системи, а, в, с — емпіричні константи, Х — вектор чинників вартості розмірністю n, m — регулюючий множник за витратами чинників. У [10] пропонується модель у вигляді співвідношення, отриманого експериментальним шляхом: E = 5.25S 0.91. Ця модель застосовувалася для оцінки проекту, у якому програмні системи мали розмір від 4000 до 467000 рядків коду, 28 різними мовами програмування високого рівня для 66 комп'ютерів, і на які витрачено від 12 до 11758 людино-місяців. Розділ 10 298 Крім того, пропонується техніка моделювання, що використовується в рівнянні витрат організації-розробника: E = 5.5+0.73S 1.16 У більшості моделей оцінка залежить від розміру системи в рядках коду. Модель COCOMO Боєма увібрала в себе три техніки вимірів проекту. У перших моделях застосовувалися показники ціни, враховувався персонал, властивості проекту, продукту й середовища. Модель містить у собі оцінку трьох процесів ведення проекту. На першому будується прототип для завдань підвищеного ризику (інтерфейс користувача, ПС, система взаємодії, реалізації та ін.) і проводиться оцінка витрат (наприклад, число таблиць у БД, екрани й звітні форми тощо). На другому процесі ведуть оцінку витрат з проектування й реалізації робіт у функціональних точках проекту, що наведені у вимогах до проекту. На третьому процесі оцінка належить до завершеного проектування, коли розмір системи визначається у термінах готових рядків програми й інших чинниках. Базовою моделлю оцінки слугує таке рівняння: E=bS c m(X), де первинна оцінка b S c коригується за допомогою вектора вартості m (X). Ця модель розвивається з урахуванням аналізу об'єктів (число старих і нових об'єктів). Параметр с у рівнянні змінюється від 0 до 1.0 для першої стадії й від 1.01 до 1.26 для інших. 10.3. Методи керування ризиками у проекті Причиною виникнення ризиків у проекті є деякі невизначеності в плані обсягу робіт на кожного працюючого та ін. Ризики можуть бути «відомі», які визначені і оцінені, їх планують, а також планують і ризики «невідомі», які можуть з’явитися [3, 4, 11]. Ризик – це небажана подія, що може мати непередбачені негативні наслідки. Якщо в проекті ідентифіковано безліч можливих подій ризику, які можуть викликати негативні наслідки, то такий проект схильний до ризику. Багато компаній приділяють увагу розробці й застосуванню корпоративних методів керування ризиками з урахуванням специфіки проектів і корпоративних методи керування. Американський Інститут PMI менеджменту розробив стандарти з керування проектами й останнім часом переробив розділи, що регламентують процедури з ризиків. У новій версії стандарту PMBOK є шість наступних процедур. 1. Планування робіт з керуванням ризиків шляхом вибору підходів і методів діяльності з їх находження. 2. Ідентифікація ризиків як визначення тих, які здатні вплинуть на реалізацію проекту і його документацію. 3. Якісна оцінка ризиків, як аналіз ризиків і умов їхнього виникнення з метою визначення їхнього впливу на успіх проекту. 4. Кількісна оцінка, як кількісний аналіз імовірності виникнення й впливу наслідків ризиків на проект. 5. Планування реагування ризиків, як визначення процедур і методів зменшення негативних наслідків ризикових подій і використання можливих переваг. 6. Моніторинг і контроль ризиків, як визначення ризиків, що залишаються, виконання плану керування ризиками проекту й оцінка дій з мінімізації ризиків. Розділ 10 299 Всі ці процедури взаємодіють одна з одною, а також з іншими процедурами. Кожна процедура виконується, принаймні, один раз у кожному проекті. Незважаючи на те, що ці процедури розглядаються як дискретні елементи із чітко визначеними характеристиками, на практиці вони можуть частково збігатися й взаємодіяти. Планування керування ризиками – це процес прийняття рішень з застосування й планування керування ризиками для конкретного проекту. Цей процес може містити в собі рішення про організацію, кадрове забезпечення, вибір кращої методології, джерел даних для ідентифікації ризику та аналізу ситуації. Сплановані роботи з керування ризиками є адекватними як рівню й типу ризику, так і важливості проекту для організації. Ідентифікацію ризиків проводять менеджери проекту, замовники, користувачі й незалежні фахівці шляхом опису ризиків, які здатні вплинути на проект. Ця процедура виконується як ітераційний процес і не буде ефективною, якщо проводиться нерегулярно протягом реалізації проекту. Ідентифіковані менеджерами проектів ризики переглядають аналітики проекту. Практично роботу з цими ідентифікованими ризиками виконують розробники проекту. Для формування об'єктивної оцінки стану проекту відносно наявності ризиків чи їх відсутності залучаються незалежні фахівці на завершальному процесі. Якісна оцінка ризиків – це процес проведення якісного аналізу ідентифікації ризиків, з метою швидкого реагування на них. Така оцінка визначає ступінь важливості ризику й вибір способу реагування. Доступність супровідної інформації допомагає легше розставити пріоритети для різних категорій ризиків. Якісна оцінка ризиків – це оцінка умов виникнення ризиків і визначення їхнього впливу на проект за допомогою стандартних методів і засобів. Вони допомагають частково уникнути невизначеностей, які часто зустрічаються в проекті. Постійна переоцінка ризиків відбувається протягом ЖЦ проекту. Кількісна оцінка ризиків – це визначення ймовірності виникнення ризиків і впливів їх наслідків на проект, а прийняття правильних рішень. Ця оцінка визначає наступне: – імовірність досягнення кінцевої мети проекту; – ступінь впливу ризику на проект й обсяги непередбачених витрат і матеріалів, які можуть знадобитися; – ризики, що вимагають якнайшвидшого реагування й більшої уваги, а також впливу їх наслідків на проект; – фактичні витрати й передбачувані строки закінчення робіт в проекті. Кількісна і якісна оцінки ризиків базується на ідентифікації ризиків і проводять їх окремо або разом, залежно від часу й бюджету. Планування і реагування ризиків – це розроблення методів і технологій з зниженню негативного впливу ризиків на проект. Ці методи призначені для ефективного захисту проекту від впливу на нього ризиків. Планування як ідентифікація і розподіл кожного ризику за категоріями потребує їхнього реагування і визначення наслідків впливу ризиків (позитивно або негативно) на проект. Ця стратегія повинна відповідати типам ризиків, рентабельності ресурсів і часових параметрів. Ризики, що обговорюються під час зустрічей, повинні бути адекватними завданням на кожному процесі проекту й погоджені з усіма членами Розділ 10 300 групи виконавців з менеджером проекту. Може бути кілька варіантів стратегій реагування на ризики. Моніторинг і контроль – це процедури спостереження за ідентифікацією ризиків, забезпечення виконання плану ризиків і оцінки його ефективності з урахуванням зниження ризику. Показники ризиків, пов'язані зі здійсненням умов виконання плану, фіксуються. Моніторинг і контроль супроводжує процес впровадження проекту в життя. Якісний контроль виконання проекту надає інформацію для прийняття ефективних рішень для запобігання виникнення ризиків. Для надання повної інформації про ризики у проекту необхідна взаємодія між усіма менеджерами проекту і розробниками. Ціль моніторингу й контролю полягає в з'ясуванні таких ситуацій: – реакцію на ризики впроваджено відповідно до плану й необхідності змін; – зміна ризиків у порівнянні з попередніми значеннями; – визначення впливу ризиків і вживання необхідних заходів; – реакція на ризики відповідно плану. Контроль може викликати вибір альтернативних стратегій, прийняття коректив, перепланування проекту для досягнення базового плану. Між менеджерами проекту й групою ризику повинна бути постійна взаємодія й фіксація всіх змін і явищ. Звіти про виконання проекту й системи ризиків регулярно формуються. Керування ризиками ґрунтується на двох основних типів ризику: загальний ризик і специфічний. До загального типу ризику належить ризик, що виникає, коли наявне недостатнє розуміння вимог, брак професіоналів або недостача часу на тестування. Ризик другого типу виражається недоліками проекту (незавершеність проекту за обіцяний строк та ін.). Для кожного можливого ризику визначається показник ступеню його ймовірності й показник витрат, пов'язаних з ризиком. Під час проведення регресивного тестування здійснюється пошук критичних помилок. Залежно від того, наскільки ця помилка критична й від того, які показники ризику діють, обчислюються збитки ризику. Діяльність керування ризиком пов’язана з виконанням таких завдань: зменшення ризику, планування ризику, резолюцію на виявлений ризик. Зменшення ризику можна досягти, якщо уникати ризику при зміні вимог, перерозподіляти ризик, відслідковувати ризик й керувати ним. Систему керування ризиком можна представити у вигляді відношення: збиток до мінімізації – збиток після мінімізації ціна мінімізації ризику. Мінімізації ризику можна досягти прототипуванням. Боєм [10] ідентифікував 10 найпоширеніших причин ризику в проекті: 1. Скорочення штату або набір некваліфікованих співробітників. 2. Нереалістичні плани й бюджети в проекті. 3. Розроблення функціонально неправильних програмних елементів. 4. Розроблення невдалого інтерфейсу користувача. 5. Невдала постановка вимог. 6. Постійна зміна вимог. Розділ 10 301 7. Недоліки у внутрішній організації робіт. 8. Недоліки взаємозв'язку із замовником. 9. Невміння працювати в реальному часі. 10. Обмежені комп'ютерні ресурси. На кожному проекті з наведених причин можуть бути присутні деякі, а не усі разом ризики. Але їх треба враховувати менеджерам, що розробляють нові проекти, щоб ризиків було як менше. Тоді проект не буде провальним. 10.4. Керування конфігурацією системи Конфігурація системи визначає конкретну версія ПС для різних ОС, комп'ютерів і містить у собі функції, об'єднані між собою процедурами зв'язку (або розгортання) і параметрами, які задають режими функціонування системи в операційному середовищі [3, 4, 11]. Випуск версії різних варіантів системи здійснюється з метою постачання замовникові. Процес отримання конкретної версії системи можна представити схемою (рис.10.7). База даних конфігурацій Компонувальник Система керування версіями Компілятор Редактор зв'язків Тестувальник Елементи зборки Версія вихідного коду Об'єктний код Версія системи Перевірена версія Рис.10.7. Схема формування версії ПС Елементами конфігурації є: – одиниця конфігурації (Configuration Item) – елемент, виділений для цілей керування й обробки на процесорах комп'ютера системи; – базис конфігурації (Configuration Baseline) – набір формально розглянутої й затвердженої основи системи із складу елементів і документації, що встановлює можливість подальшого розвитку системи; – програмні компоненти системи. Конфігурація складається з наведених елементів і спеціалізованих процедур їхнього об'єднання в єдине ціле для функціонування й виконання компонентів у заданій послідовності. Чим більше в системі компонентів, тим більша ймовірність того, що окремі з них можуть змінюватися у зв'язку з виявленими помилками, уточненнями або доповненнями як нових функцій, так і устаткування.В ній Розділ 10 302 іменуються всі елементи, що базуються на структуризації, схемі класифікації й кодування елементів, а також на методах представлення й ведення версій конфігурації з використанням вхідних елементів. Метою керування конфігурацією є забезпечення цілісності системи з спостереженням за змінами, структурою й елементами конфігурації. Керування конфігурацією – дисципліна забезпечення ідентифікації елементів конфігурації системи при її створенні для проведення систематичного контролю, обліку й аудиту внесених змін, а також підтримки цілісності й працездатності системи. До елементів керування конфігурацією також належать фізичні й функціональні характеристики, схема й версія конфігурації. Згідно з діючим стандартом IEEE Std.610–90 керування конфігурацією містить у собі такі основні завдання: 1. Ідентифікація конфігурації (Configuration Identification). 2. Контроль конфігурації (Configuration Control). 3. Облік статусу конфігурації (Configuration Status Accounting). 4. Аудит конфігурації (Configuration Audit). Керування конфігурацією великих систем здійснюють методами і засобами забезпечення ідентифікації її елементів, контроль внесених змін і можливість визначення фактичного стану системи для подання в експлуатацію в будь-який момент часу її готовності. Це керування базується на точній і достовірній інформації про стан системи й плани проведення змін. З формальної точки зору керування конфігурацією полягає в дисциплінованому застосуванні технічних, адміністративних методів спостереження за функціональними і фізичними характеристиками окремих пунктів конфігурації й елементів системи, а також їх змін і підготовці звітів про внесені зміни і перевірки правильності версії системи за висунутими вимогами. Керування конфігурацією, як правило, виконує спеціальна служба, яка визначає можливі обмеження на функціонування системи в заданих умовах операційного середовища, порядок внесення змін, перевірку різних частин системи, збирання даних і облік внесених змін у систему й в документ про конфігурацію. До діяльності цієї служби належить також питання керування проектом, контролю якості й цілісності побудови конфігурації системи, здатної для її супроводу. Структура служби залежить від складності системи, кількості виконавців та підтримуючих процесів розвитку проекту системи за вимогами замовника. Від її діяльності залежить ефективність побудови конфігурації системи (рис. 10.8.). Результатом керування конфігурацією є звіт з проведення змін проміжних версії системи, документації, носія системи та документа передачі версії замовнику і користувачеві. Задачі керування конфігурацією планують й виконують з урахуванням виникаючих обмежень ОС і наявності відповідного устаткування у замовника. Планування виконують менеджери вказаної служби. Вони пропонують пропозиції щодо зміни компонентів системи, проведення аналізу й визначення доцільності їх внесення у версію системи і у конфігурацію, а також оцінювання вартості цих робіт. Все це подають у вигляді переліку змін для їхньої реалізації. Розділ 10 303 Рис. 10.8. Види діяльності керування конфігурацією Цей перелік містить у собі типи змін, строки і організацію їхнього проведення, а також дані про допуск відхилень і відмов з урахуванням вимог до проекту системи. Результатом внесення змін є нова версія системи, опис документу про проведення на ній випробувань і інструкцій для користувача. Замовник оцінює пропозиції з внесення змін і дає дозвіл на проведення найважливіших змін, що впливають на її технічні характеристики або вартість. Аналіз і контроль проведення змін конфігурації системи проводить спеціальна група служби керування. Вона також виконує систематичний облік внесених змін на всіх процесах ЖЦ. План змін конфігурації системи затверджується формальними процедурами, розрахунками оцінок впливу змін на вартість, прийняттям рішень про зміни або відмову від них. Запити на внесення змін виконуються за цими процедурами на процесах розроблення ПП і супроводу системи. Необхідні зміни можуть проводитися одночасно з розробкою, трасуванням і при побудові нових версій системи. Кожна проведена проходить детальний аудит. Після внесення змін проводять контроль поточної версії системи з використанням вихідних кодів систем, що у репозиторію, інструментів контролю які є у фірмах Rational's ClearCase й SourceSafe of Microsoft, а також формується версія системи. Після завершення змін і випробування системи проводять тиражування версії системи з її конфігурацією та документації для передачі замовникові. У конфігурацію системи входять відомості про апаратні ї програмні елементи системи. В них задають обмеження з урахуванням вимог контрактів із замовником на систему, також тих, що пов’язані з аудитом, інформацією з різних джерел (специфікації вимог, описів програм в МП, звітів тощо), інструментальних засобів і рекомендацій державних або міжвідомчих стандартів. |