К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Планування конфігурації залежить від типу проекту, організаційних заходів, обмежень і загальних рекомендацій з керівництва конфігурацією. До видів цього планування належать: ідентифікація, визначення статусу й аудиту конфігурації, зміни конфігурації. Розділ 10 304 До засобів планування належать: – система керування кодами компонент, їхнім перекладом й об'єднанням у конфігурацію системи; – базові бібліотеки й ресурси; – спеціальні групи контролю системи і її конфігурацій; – СКБД для ведення проекту й зберігання змін у системі. Основними завданнями цього планування є: – фіксація різних завдань на зміни й вибір інструментарію для їхнього виконання; – визначення людино-годин й інструментальних ресурсів, стандартів, витрат для внесення змін та ін.; – встановлення зв'язків із замовником з проведення контролю системи і її конфігурації, а також оцінки системи; – визначення послідовності робіт керування конфігурацією. Результати планування відображають в плані керування конфігурацією проекту, а також у документі внесення змін у версію, конфігурацію або в саму систему. Ідентифікація елементів конфігурації. Її Виконують методами структуризації, класифікації й іменування елементів системи і її версій. С ідентифікацією зв’язано: визначення стратегії ідентифікації для отримання врахованої версії системи; іменування елементів системи і всієї її конфігурації; встановлення співвідношення між кількістю виконуваних завдань і кількістю пунктів конфігурації; ведення версії системи (або її частин) і документування; вибір елементів базису конфігурації і його формальне позначення. До засобів підтримки ідентифікації відносять бібліотеку елементів, версій і змін системи. Основу ідентифікації становить конфігураційний базис – набір формально розглянутої й затвердженої конфігураційної документації, як основи для подальшого розвитку або розроблення системи. Виділення в продукті контрольованих одиниць конфігурації є складним завданням. Воно, як правило, належить до процесу високого рівня або архітектурного проектування й виконується системними архітекторами. Побудова адекватної схеми класифікації й ідентифікації об'єктів конфігураційного керування виконується одночасно зі структуризацією продукту й полягає у визначенні правил унікальної ідентифікації (кодування, маркірування): конфігурації продукту і її версій; контрольованих одиниць конфігурації і їхніх версій; всіх складових конфігураційного базису і їхніх редакцій. Результатом створення і застосування схеми ідентифікації є можливість швидко й гарантовано відрізняти: різні продукти один від одного, версії одного продукту між собою, одиниці конфігурації продукту і їхньої версії. 10.4.1. Формування версій й контроль конфігурації Версія системи містить у собі елементи конфігурації й варіант версії системи для передачі замовнику [8, 13]. Керування версіями полягає у виконанні дій: Розділ 10 305 інтеграція або композиція коректної й остаточної версії системи з елементів конфігурації, які реалізовані на процесах ЖЦ. Функціонування коду системи залежить від апаратних засобів й інструментів, за допомогою яких будувалася система; вибору інструментарію побудови версії, оцінки можливостей середовища й засобів автоматизації процесу побудови окремих версій з коректною конфігурацією ПС і даних; керування варіантами версій із сукупності готових ідентифікованих елементів системи, що задовольняють заданим вимогам замовника. При формуванні версій системи враховуються обмеження на розробку системи під час виконання процесів ЖЦ, які, як правило, породжують ряд відхилень від вимог на розробку елементів конфігурації системи. Наприклад, приймається рішення про зміну конфігурації і вони не погоджені із замовником. Коли нову версію системи отримано, замовнику передають остаточну версію, /конфігураціюю, документацію й інструменти керування версіями для самостійного супроводу системи і внесення змін у її елементи. Яскравим прикладом формування 21 версії на ОС 360 (1965–1980р.) є фірма IBM. В ОС постійно й поетапно додавалися нові функціональні можливості й вносилися зміни до попередньої версії при її експлуатації [9]. Над розвитком додаткових можливостей даної ОС і внесення змін у попередню версію постійно працював колектив фірми. Трудомісткість розробки чергової версії ОС вважалася пропорційною інтервалу часу між реєстраціями чергових версій і приймалася за одиницю виміру складності створення нової версії [8]. Як міру трудомісткості супроводу й створення чергової версії було використано число модулів (обмежених розмірів зі стандартизованим описом), що піддаються змінам і доповненням. Крім того, оцінювалася інтенсивність робіт над створенням версії, що вимірялася числом змінених модулів в одиницю часу. Після 12 років постійних змін в ОС 21 версія працювала стабільніше, до неї майже не вносилося змін, оскільки претензій з боку користувачів в основному не надходило. Метричний аналіз процесу розвитку ОС 360 дозволив встановити, що обсяг середнього приросту системи на кожну версію відповідав приблизно 200 модулям. При цьому загальний обсяг збільшився від 1 тис. модулів у перших версіях до 5 тис. модулів в останніх версіях. Коли рівень приросту складності був великим, для усунення помилок або додаткових коректувань іноді створювалися проміжні версії з меншим числом змін. Як результат з'явилося поняття «критичної маси» або критичної складності системи, що модифікується. Якщо при модернізації й випуску чергової версії системи обсяг доробок перевищує «критичний», то зростає ймовірність погіршення характеристик або необхідність введення проміжної версії із внесенням деяких змін. «Критичний» обсяг доробок ОС–360 близько 200 модулів залишався постійним, незважаючи на підвищення кваліфікації колективу, удосконалення технічних і програмних засобів тощо. У перших версіях обсяг доробок становив 20% модулів, а в останніх версіях знизився до 5%. Контроль конфігурації – це перевірка її правильності і випробування розгортки конфігурації в процесі експлуатації системи. Він містить у собі безперервні коректування, які стосуються вже погодженого й/або затвердженого конфігураційного базису. Це обумовлює такі об’єкти контролю: Розділ 10 306 – зміни в затвердженому базисі і пов'язані з ними коректування елементів конфігурації; – дефекти й відхилення в конфігурації продукту з затвердженого базису. Для їхнього опису використовують формальні процедури ініціалізації, аналізу, прийняття й контролю виконання управлінських рішень з приводу запропонованих змін, виявлених дефектів і відхилень у конфігурації й/або елементів конфігурації продукту. Формальна обробка запитів на зміну базису. Після досягнення взаєморозуміння з приводу вимог, архітектури та інших технічних рішень, відповідні проектні документи вважаються затвердженими й не можуть довільно модифікуватися. Тобто будь-яка потреба в зміні, що виходить від будь-якого учасника проекту, повинна пройти формальну процедуру з таких кроків: 1. Реєстрація пропозиції /запиту на зміну. 2. Аналіз впливу запропонованої зміни на наявний заділ, обсяг, трудомісткість, графік і вартість робіт з проекту. 3. Прийняття рішення з виконання цього запиту (наприклад, задовольнити, відмовити або відкласти). 4. Реалізація затвердженої зміни і її верифікація. Керування дефектами й відхиленнями від затвердженого базису. Другою важливою складовою контролю конфігурації є керування невідповідностями між конфігурацією або елементами конфігурації продукту й конфігураційним базисом. З погляду керування всі невідповідності поділяються на дефекти й відхилення. До дефектів відносять ті невідповідності, які безпосереднє стосуються цільового використання продукту за його призначенням. Усе інше належить до відхилень. Якщо дефекти програмного продукту є негативними, то вони підлягають усуненню за такою схемою: реєстрація інформації про отриманий дефект /відхилення; аналіз та діагностика місця й причини дефекту /відхилення, оцінка обсягу, трудомісткості, строків і вартості переробок; прийняття рішення з усунення дефекту/відхилення, реалізація й верифікація цих недоліків. Такого роду рішення є керованими, їх приймають керівники відповідного рівня або їхні повноважні представники. Як правило, рівень прийняття рішення про зміну програмного продукту повинен бути прийнятий на рівні узгодження або затвердження документів відповідного конфігураційного базису. Найзручнішою формою реалізації такого рішення є рада керівників з контролю конфігурації CCB (Configuration Control Board), як родоначальника теорії й практики керування конфігурацією. 10.4.2. Облік статусу й аудит конфігурації Зміст цього обліку полягає в реєстрації й наданні інформації з ефективного контролю конфігурації. Предметом обліку є інформація про поточний статус ідентифікованих об'єктів конфігурації, запропоновані і виконанні зміни, а також виявлені дефекти й відхилення від затвердженого конфігураційного базису. Звітність про статус конфігурації є ключовим чинником прийняття проектних рішень до системи або проекту. Більше того, дані обліку статусу конфігурації, що оперативно реєструються та регулярно оновлюються, є вихідним матеріалом для Розділ 10 307 формування кількісних оцінок, а саме, метрик продуктивності і якості робіт на проекті. Застосування цих метрик дозволяє приймати не тільки правильні, а й ефективні проектні рішення з створення програмного проекту. У системі обліку статусу конфігурації накопичують зведені звіти про кількість виявлених і виправлених дефектів, що надійшли, й реалізованих запитів на зміни, динаміку внесення змін у конфігурацію в часі та ін. Цю звітність використають практично всі учасники проекту: замовники, аналітики, розробники, тестувальники, служби впровадження та якості й керівництво проекту. На її основі проводять кількісну оцінка продуктивності і якості проекту. Аудит конфігурації – це ревізія або перевірка випуску чергової версії ПС або перездачі системи замовнику. В обох випадках аудиторська робота здебільшого пов'язана з розглядом й оцінкою документації, даних, звітів і результатів іспитовій версії системи. Аудит конфігурації проводять безпосередньо перед виходом нової версії продукту, його частини, тобто практично завжди виходять із відповідальності моменту з тих або інших зобов'язань перед замовником. Конфігураційний аудит – це: – функціональний аудит конфігурації для підтвердження відповідності фактичних характеристик конфігурації/одиниць програмного продукту висунутим вимогам до системи; – фізичний аудит конфігурації, як підтвердження взаємної відповідності документації з фактично створеної конфігурації готового продукту системи. Функціональний аудит – не є верифікацію або валідацією програмного продукту, а є перевірка того, що тестування проведено у встановленому обсязі, результати документовані й підтверджують відповідність характеристик продукту висунутим до нього вимогам. При цьому всі зміни реалізовано, критичні дефекти усунуто, а про всі виявлені відхилення від конфігураційного базису прийнято адекватні проектне рішення. Цей аудит полягає у звіренні готового продукту з документами конфігураційного базису, а також перевірки того, що цю конфігурацію побудовано відповідно до встановлених процедур і з коректних версій відповідних компонентів. Конфігураційний аудит проводять незалежними експертами, наприклад, представниками служби якості. Висновки. У даному розділі подані всі питання менеджменту програмними проектами, а саме, методи СРМ і PERT, завдяки яким формуються план графік роботами, строками і виконавцями. Розглянуті різні види планів і шляхи їх застосування ][ в керуванні проектом, оцінки вартості і витрат на кожну роботу. Jбґрунтовані задачі виявлення ризиків, що виникають при розробленні елементів проекту, як з точки зору браку ресурсів, так і стану виконавців (хвороби, звільнення тощо). Виготовлений програмний проект отримує протестовану версію ПС, її різні варіанти конфігурації залежно від операційного середовища, що є у замовника і користувачів. Висвітлені процедури контролю і аудиту варіантів конфігурації та якості отриманого продукту проекту. Контрольні запитання і завдання 1. Як вирішуються завдання менеджменту програмного проекту? 2. Визначте процес планування менеджменту проекту. 3. Визначте поняття керування ризиком. Розділ 10 308 4. Поясніть стратегію оцінки вартості продукту за Боємом. 5. Як вирішуються завдання менеджменту програмного проекту? 6. Визначте процес планування менеджменту проекту. 7. Визначте поняття керування ризиком. 8. Поясніть стратегію оцінки вартості продукту за Боємом. 9. Що розуміється під процесом керування конфігурацією ПО? 10. Наведіть основні завдання керування конфігурацією. 11 .Які дії виконуються в процесі керування версіями ПО? 12. Сформулюйте основні завдання обліку й аудиту. Список літератури до розділу 10 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. Первое знакомство с Microsoft Office Рroject Professional 2003. – Microsoft, 2003. – 34 c. 7. Андон Ф.И., Коваль Г.И., Коротун Т.M., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем. – К.: Академпериодика, 2002. – 502 с. 8. Бабенко Л.П., Лаврищева Е.М. Основи програмної інженерії. Посібник. – К.: Знання, 2001. – 269 с. 9. Брукс Ф.П. Мифический человеко-месяц или как создаются программные системы. Пер.с англ. – СПб.: Символ–Плюс, 2005. – 304 с. 10. Боэм Б.У. Инженерное проектирование программного обеспечения. – М.: Радио и связь, 1985. – 511 с. 11. Лаврищева Е.М. Методы программирования. Теория, инженерия, практика.– К.: Наук. думка, 2006. – 451 с. 12. Круковський М.Ю., Цурін О.П., Петренко А.І. (24 червня 2007). Керування проектами засобами MS Project [WWW документ]. URL http://www.itcomp.edu-ua.net/datas/upload/643646190.ppt (9 липня 2007). 13. R.H. Thayer, ed., Software Engineering Project Managment, 2nd.ed., IEEE CS Press, Los Alamitos, Calif. 1997.–391p. 309 ПІСЛЯМОВА Підручник призначений для навчання предмету „Програмна інженерія» в вищих навчальних закладах України. Його мета – навчити теорії, інженерії і практиці розроблення комп’ютерних програм в сучасних інструментальних середовищах. За поглядом автора, у майбутньому програмна інженерія отримає розвиток нових дисциплін, орієнтованих на індустріальне виробництво ПП, пов’язаних з керуванням колективною розробкою складних програмних об’єктів (доменів, сімейств систем, проектів тощо) та оцінюванням економічних і вартісних працевтрат, а також їх продуктивності і якості Запропоновані дисципліни ПІ, опис яких у загальному вигляді подані у розділі 1, на думку автора, отримають розвиток. Є надія, що вони будуть розглянуті робочим комітетом Curricula–2010 і деякі з них увійдуть у робочу програму цього комітету, як дисципліни навчання на факультетах інформатики, кому’ютених наук, АСУ тощо. Викладання цих дисциплін надасть студентам знання про різні функціональні, економічні та технологічні види діяльності, що необхідні при участі у індустріальному виробництві програмних продуктів. На даний час цей підручник відображає робочу міжнародну програму Computing Curricula–2004 для навчання студентів, починаючі с першого курсу з спеціальності «Програмна інженерія» і закінчуючи загальним курсом навчання цього предмета на факультетах інформатики. У даному підручнику матеріал навчання програмної інженерії відповідає програмі SE201 Curricula–2004, яку рекомендовано як типовий факультативний тематичний план навчання, що містить у собі наступні теми: 1. Проектування ПС. 2. Інтерфейси застосувань. 3. Програмні засоби й оточення. 4. Процеси розроблення ПС 5. Вимоги до ПС. 6. Перевірка відповідності ПС. 7. Методи еволюції ПС. 8. Керування програмними проектами. 9. Компонентно-орієнтована розробка. 10. Формальні методи. 11. Надійність і якість ПС. 12. Підходи до розробки спеціалізованих систем (не обов'язкова). Усі наведені теми навчання, окрім останній, наведено в даному підручнику, і вони можуть використовуватися також викладачами як зразок при практичній підготовці курсу лекцій студентам вищих навчальних закладів, які навчаються за напрямами «Комп’ютерні науки», «Комп’ютерна інженерія», «Прикладна математика» у галузі знань «Інформатика та обчислювальна техніка». Як наука, програмна інженерія набуває подальшого розвитку у багатьох з наведених дисциплін та розділах ядра знань SWEBOK, найперспективнішими у наступному десятиріччі будуть такі напрями: – 15 річний міжнародний проект (з 2006р.) – теорія і практика верифікації усіх видів продуктів та їхнє накопичення у Інтернет-бібліотеках; Список позначень і скорочень 312 – розвиток і вдосконалення сформульованих дисциплін програмної інженерії, обґрунтоване подання їхнього змісту з обговоренням у широкому загалі фахівців з програмної інженерії та подання напрацьованих знань з цих дисциплін у відповідних посібниках або підручниках для навчання студентів за відповідними спеціальностями на факультетах інформатики і комп’ютерних наук; – узагальнення технологічних та інструментальних засобів розроблення програмних проектів силами фахівців передових міжнародних фірм з програмної інженерії у напряму підвищення теоретичного і автоматизованого рівнів індустрії виробництва різних видів програмних продуктів, орієнтованих на користувачів, фахівців прикладних доменів та ринок; – розвиток теоретичного і прикладного підгрунтую майбутнього предметно, мовно-орієнтованого програмування забезпечуючого формальний опис специфіки доменів і членів сімейства систем, а також інструментальну підтримку усіх сторін їхнього виробництва; – комп’ютеризація математичних, логіко-алгебраїчних та обчислювальних знань тощо. |