Основні поняття життєвого циклу та процесу менеджменту проекту

- Аудит конфігурації (Configuration Audit).

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

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

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

Структура служби залежить від складності системи, кількості виконавців та підтримуючих процесів розвитку проекту системи за вимогами замовника.

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

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

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

Результатом внесення змін є нова версія системи, опис документу про проведення на ній випробувань і інструкцій для користувача.

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

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

Після внесення змін проводять контроль поточної версії системи з використанням вихідних кодів систем, що у репозиторію, інструментів контролю які є у фірмах Rational's ClearCase й SourceSafe of Microsoft, а також формується версія системи. Після завершення змін і випробування системи проводять тиражування версії системи з її конфігурацією та документації для передачі замовникові.

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

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

До засобів планування належать:

- система керування кодами компонент, їхнім перекладом й об'єднанням у конфігурацію системи;

- базові бібліотеки й ресурси;

- спеціальні групи контролю системи і її конфігурацій;

- СКБД для ведення проекту й зберігання змін у системі.

Основними завданнями цього планування є:

- фіксація різних завдань на зміни й вибір інструментарію для їхнього виконання;

- визначення людино-годин й інструментальних ресурсів, стандартів, витрат для внесення змін та ін.;

- встановлення зв'язків із замовником з проведення контролю системи і її конфігурації, а також оцінки системи;

- визначення послідовності робіт керування конфігурацією.

Результати планування відображають в плані керування конфігурацією проекту, а також у документі внесення змін у версію, конфігурацію або в саму систему.

Ідентифікація елементів конфігурації. її Виконують методами структуризації, класифікації й іменування елементів системи і її версій. З ідентифікацією зв'язано:

- визначення стратегії ідентифікації для отримання врахованої версії системи;

- іменування елементів системи і всієї її конфігурації;

- встановлення співвідношення між кількістю виконуваних завдань і кількістю пунктів конфігурації;

- ведення версії системи (або її частин) і документування;

- вибір елементів базису конфігурації і його формальне позначення.

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

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

- конфігурації продукту і її версій;

- контрольованих одиниць конфігурації і їхніх версій;

- всіх складових конфігураційного базису і їхніх редакцій.

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

4.1 Формування версій й контроль конфігурації

Версія системи містить у собі елементи конфігурації й варіант версії системи для передачі замовнику. Керування версіями полягає у виконанні дій:

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

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

- керування варіантами версій із сукупності готових ідентифікованих елементів системи, що задовольняють заданим вимогам замовника.

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

Яскравим прикладом формування 21 версії на ОС 360 (1965-1980 р.) є фірма ІВМ. В ОС постійно й поетапно додавалися нові функціональні можливості й вносилися зміни до попередньої версії при її експлуатації. Над розвитком додаткових можливостей даної ОС і внесення змін у попередню версію постійно працював колектив фірми. Трудомісткість розробки чергової версії ОС вважалася пропорційною інтервалу часу між реєстраціями чергових версій і приймалася за одиницю виміру складності створення нової версії.

Як міру трудомісткості супроводу й створення чергової версії було використано число модулів (обмежених розмірів зі стандартизованим описом), що піддаються змінам і доповненням. Крім того, оцінювалася інтенсивність робіт над створенням версії, що вимірялася числом змінених модулів в одиницю часу. Після 12 років постійних змін в ОС 21 версія працювала стабільніше, до неї майже не вносилося змін, оскільки претензій з боку користувачів в основному не надходило.

Метричний аналіз процесу розвитку ОС 360 дозволив встановити, що обсяг середнього приросту системи на кожну версію відповідав приблизно 200 модулям. При цьому загальний обсяг збільшився від 1 тис. модулів у перших версіях до 5 тис. модулів в останніх версіях. Коли рівень приросту складності був великим, для усунення помилок або додаткових коректувань іноді створювалися проміжні версії з меншим числом змін.

Як результат з'явилося поняття «критичної маси» або критичної складності системи, що модифікується. Якщо при модернізації й випуску чергової версії системи обсяг доробок перевищує «критичний», то зростає ймовірність погіршення характеристик або необхідність введення проміжної версії із внесенням деяких змін. «Критичний» обсяг доробок ОС-360 близько 200 модулів залишався постійним, незважаючи на підвищення кваліфікації колективу, удосконалення технічних і програмних засобів тощо. У перших версіях обсяг доробок становив 20% модулів, а в останніх версіях знизився до 5%.

Контроль конфігурації - це перевірка її правильності і випробування розгортки конфігурації в процесі експлуатації системи. Він містить у собі безперервні коректування, які стосуються вже погодженого й/або затвердженого конфігураційного базису. Це обумовлює такі об'єкти контролю:

- зміни в затвердженому базисі і пов'язані з ними коректування елементів конфігурації;

- дефекти й відхилення в конфігурації продукту з затвердженого базису.

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

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

- Реєстрація пропозиції /запиту на зміну.

- Аналіз впливу запропонованої зміни на наявний заділ, обсяг, трудомісткість, графік і вартість робіт з проекту.

- Прийняття рішення з виконання цього запиту (наприклад, задовольнити, відмовити або відкласти).

- Реалізація затвердженої зміни і її верифікація.

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

- реєстрація інформації про отриманий дефект /відхилення;

- аналіз та діагностика місця й причини дефекту /відхилення, оцінка обсягу, трудомісткості, строків і вартості переробок;

- прийняття рішення з усунення дефекту/відхилення, реалізація й верифікація цих недоліків.

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

Найзручнішою формою реалізації такого рішення є рада керівників з контролю конфігурації CCB (Configuration Control Board), як родоначальника теорії й практики керування конфігурацією.

4.2 Облік статусу й аудит конфігурації

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

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

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

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

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

Конфігураційний аудит - це:

- функціональний аудит конфігурації для підтвердження відповідності фактичних характеристик конфігурації/одиниць програмного продукту висунутим вимогам до системи;

- фізичний аудит конфігурації, як підтвердження взаємної відповідності документації з фактично створеної конфігурації готового продукту системи.

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

Висновки

У курсовій роботі подані всі питання менеджменту програмними проектами, а саме, методи СРМ і PERT, завдяки яким формуються план графік роботами, строками і виконавцями. Розглянуті різні види планів і шляхи їх застосування в керуванні проектом, оцінки вартості і витрат на кожну роботу. Обґрунтовані задачі виявлення ризиків, що виникають при розробленні елементів проекту, як з точки зору браку ресурсів, так і стану виконавців (хвороби, звільнення тощо). Виготовлений програмний проект отримує протестовану версію ПС, її різні варіанти конфігурації залежно від операційного середовища, що є у замовника і користувачів. Висвітлені процедури контролю і аудиту варіантів конфігурації та якості отриманого продукту проекту.

Перелік посилань на використані джерела

1. Англо-український тлумачний словник з обчислювальної техніки, Інтернету, програмування. - К.: СофтПрес, 2006. - 8237 с.

2. Первое знакомство с Microsoft Office project Professional 2003. - Microsoft, 2003. - 34 c.

3. Черников A. Теория и практика управления проектами // Компьютерное обозрение. - 2003. - №10 - С. 24-39.

4. Гультяев А.К. MS PROJECT 2003. Управление проектами. Русская версия; Практическое пособие. - СПб.: КОРОНА, 2003. - 592 с.

5. Джалота П. Управление программными проектами на практике. - Лори, 2005. - 265 с.

6. Андон Ф.И., Коваль Г.И., Коротун Т.Ы., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем. - К.: Академпериодика, 2002. - 502 с.

7. Бабенко Л.П., Лаврищева Е.М. Основи програмної інженерії. Посібник. - К.: Знання, 2001. - 269 с.

8. Брукс Ф.П. Мифический человеко-месяц или как создаются программные системы. Пер.с англ. - СПб.: Символ-Плюс, 2005. - 304 с.

9. Боэм Б.У. Инженерное проектирование программного обеспечения. - М.: Радио и связь, 1985. - 511 с.

10. Лаврищева Е.М. Методы программирования. Теория, инженерия, практика. - К.: Наук. думка, 2006. - 451 с.

11. Круковський М.Ю., Цурін О.П., Петренко А.І. (24 червня 2007). Керування проектами засобами MS Project [WWW документ]. URL http://www.itcomp.edu-ua.net/datas/upload/643646190.ppt (9 липня 2007).

12. R.H. Thayer, ed., Software Engineering Project Managment, 2nd.ed., IEEE CS Press, Los Alamitos, Calif. 1997.-391p.

Размещено на Allbest.ru