Задачі супроводження та їх пріоритети

Размещено на http://www.allbest.ru/

[Введите текст]

1. Природа терміну «супроводження програмного забезпечення». Завдання та цілі супроводження

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

Природа супроводу. Супровід підтримує функціонування програмного продукту протягом усього операційного життєвого циклу, тобто періоду його експлуатації. У процесі супроводу фіксуються і відслідковуються запити на модифікацію (запити на зміни), оцінюється вплив запропонованих змін, модифікується код та інші активи (артефакти) продукту, проводиться необхідне тестування і, нарешті, випускається оновлена версія продукту. Крім того, проводиться навчання користувачів і забезпечується їх щоденна підтримка при роботі з поточною версією продукту. Супровід, з точки зору операцій відстеження та контролю, має ширший зміст, ніж розробка (у загальному розумінні). Обсяг і активність операцій з контролю розробки у великій мірі залежить від сформованих практик, внутрішньокорпоративних регламентів і вимог, а також методологій та концепції управління (проектного менеджменту). Так чи інакше, відстеження і контроль -- ключові елементи діяльності з супроводження програмного забезпечення (як і інших ІТ-активів підприємства). Стандарт 12207 визначає поняття "maintainer" -- у відповідному ДУСТ він йменується як "Персонал супроводу", маючи на увазі організацію, що виконує роботи з супроводу. Даний термін використовується також і щодо осіб, які проводять певні роботи по супроводу, на відміну, наприклад, від розробників, що займаються реалізацією системи в програмному коді. Стандарт життєвого циклу 12207 також ідентифікує основні роботи по супроводу:

реалізація процесу супроводу;

аналіз проблем і модифікацій (змін);

реалізацій модифікацій;

огляд (оцінка) і прийняття рішень по супроводу;

міграція (з однієї версії програмного продукту на іншу, з одного продукту на інший);

виведення системи з експлуатації.

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

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

Практика показує, що інженери з технічної підтримки виробника програмного забезпечення повинні не просто мати доступ до всіх ключовим активам проекту (код, документація, специфікації вимог, внутрішні моделі і тощо), але в їх обов'язки входить створення "патчів", виправлень помилок і, в особливих випадках, такі зміни, до випуску нової версії продукту, створюються із залученням безпосередньо розробників продукту (груп і підрозділів R & D -- Research and Development). При цьому, розробники продукту інформуються про знайдені помилки і, в разі знаходження відповідних вирішень проблем фахівцями технічної підтримки, результати їх роботи передаються розробникам для того, щоб ті або включили такі зміни в нову версію програмного продукту, або знайшли більш адекватне рішення в контексті функціональності нової версії продукту. В обов'язки інженерів служби супроводу, загалом випадку, входить:

перевірка користувацького сценарію, що приводить до збою;

ідентифікація причин збою, тобто локалізація помилки та причин її появи;

надання відповідних виправлень або, при неможливості створення таких на даному етапі або в задані терміни -- надання обхідного шляху вирішення проблеми для досягнення необхідних бізнес-завдань ("workaround");

протоколювання всіх робіт і операцій;

занесення опису проблеми й її вирішення в базу знань служби супроводу;

передача всієї інформації розробникам;

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

Супроводження потрібне для того, щоб програмна система продовжувала забезпечувати задоволення потреб користувачів. Супроводження має виконуватись у відповідності до вирішення наступних задач:

- усунення помилок;

- усунення конструкторських недоліків;

- покращення дизайну;

- удосконалення функціональності системи;

- розробка інтерфейсів для взаємодії з іншими системами;

- міграція успадкованих програмних систем;

- виведення програмної системи із експлуатації.

Усунення помилок.

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

Однак деякі помилки викликають необхідність термінового виправлення програм. У цих випадках припустимо деяке відставання коригування документації при більш терміновому і реєструється виправленні самих програм.

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

Міжнародний стандарт ANSI/IEEE-729-83 розділяє всі помилки в розробці програм на такі типи.

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

Дефект (fault) у програмі - наслідок помилок розробника на кожному з процесів проектування, що може утримуватися у вхідних або проектних специфікаціях, текстах кодів програм, експлуатаційній документації тощо. У процесі виконання програми можуть бути виявлені дефект або збій.

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

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

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

проект програми може містити у собі помилки (наприклад, база даних спроектована без засобів захисту від несанкціонованого доступу користувача, а потрібен захист);

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

Усунення конструкторських недоліків.

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

Область знань «Конструювання ПЗ» містить у собі такі розділи:

- зниження складності (Reduction in Complexity),

- попередження відхилень від стилю (Anticipation of Diversity),

- структуризація перевірок (Structuring for Validation),

- використання стандартів (Use of External Standards).

Зниження складності - це мінімізація, зменшення і локалізація складності конструювання.

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

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

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

2. Удосконалення функціональності системи

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

Придатність до застосування (suitability) - здатність ПС надавати належну множину функцій для розв'язання специфікованих задач і досягнення цілей користувача;

Коректність (правильність, точність) (accuracy) - здатність ПС забезпечувати правильні або погоджені результати або впливи з необхідним ступенем точності;

Здатність до взаємодії (в тому числі мережевої) (interoperability) - здатність взаємодіяти з однією чи більше специфікованими системами;

Захищеність (security) -- здатність забезпечувати захист інформації від несанкціонованого доступу осіб або систем і її доступність особам та системам з необхідними правами доступу.

Ключові питання супроводу програмного забезпечення.

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

Спроба знайти дефект в продукті, що містить 500 000 рядків коду, написаних іншими інженерами -- яскравий приклад складнощів, з якими доводиться стикатися інженерам по супроводу. Інший приклад, вже організаційний, постійна боротьба за ресурси з розробниками (найчастіше виявляється в питаннях відволікання розробників від поточної роботи для допомоги у вирішенні проблем супроводу, а також в конкуренції за пріоритети фінансування розробки нової системи або супроводу існуючої). Одночасне планування перспективної версії системи, реалізація наступної версії і підготовка критичних патчів для поточної версії -- ще один класичний приклад проблем, з якими доводиться стикатися в процесі експлуатації програмного забезпечення. Дана секція висвітлює деякі технічні та управлінські питання, пов'язані з супроводом програмних систем. Ці питання і проблеми згруповані в набір тем:

Технічні питання.

Керування супроводом.

Оцінка вартості.

Вимірювання.

Технічні питання супроводу.

Обмежене розуміння (Limited understanding).

Під обмеженим розумінням мають на увазі те, як швидко інженер з супроводу може зрозуміти, де необхідно внести виправлення або зміни в код системи, яку він не розробляв. Дослідження показують, що від 40 до 60 відсотків зусиль по супроводу витрачається на аналіз і розуміння супроводжуваного програмного забезпечення. Формування цілісного погляду має велике значення для інженерів. Цей процес більш складний у випадку аналізу вихідного коду системи, особливо, коли процес еволюції системи від збірки до збірки, від релізу до релізу, в ньому ніяк не зазначений, не документований і коли розробники не можуть пояснити історію і структуру змін, що, на жаль, трапляється досить часто. Практика показує, що для об'єктно-орієнтованих програм якісно спрощує задачу розуміння коду використання UML-інструментарію, здатного на основі коду відновити не тільки модель класів, але і їх взаємодії у формі діаграм класів (class diagram), комунікацій або співробітництва (collaboration в UML 1.x, перейменована в communication в UML 2.0) і, особливо, послідовностей (sequence diagram), що демонструє структуру взаємних викликів в часі. Якщо відповідний інструментарій надає одночасну візуалізацію коду і діаграми і забезпечує взаємну синхронізацію їх з погляду навігації (вибір методу в будь-який з представлених діаграм автоматично позиціонує відповідним чином редактор коду і, навпаки) -- такі засоби автоматизації можуть скоротити час, необхідний для формування уявлення про систему, іноді -- навіть не в рази, а на порядок (звичайно, при достатньому рівні знань інженера з супроводу). Якщо до цього додати документованість архітектури та ключових технологічних рішень з боку розробників системи -- то завдання, звичайно, не стає тривіальним, однак, перетворюється на цілком розв'язну задачу.

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

Тестування (Testing).

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

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

Аналіз впливу (Impact analysis).

Аналіз впливу описує як проводити (зокрема, з точки зору ефективності витрат) повний аналіз можливих наслідків і впливів змін, що вносяться в існуючу систему. Персонал супроводу повинен володіти необхідними знаннями про специфіку системи (в ідеальному випадку, мати повне уявлення про систему на рівні її розробників) -- її зміст і структуру. Інженери використовують ці знання для виконання робіт з аналізу впливу, ідентифікуючи всі системи3 і програмні продукти, на які можуть вплинути зміни, що вносяться в програмну систему. При цьому, повинні бути визначені ризики, пов'язані з внесенням змін. Запити на зміни4 (change requests -- CR), іноді згадуються як запити на модифікацію (modification request -- MR), часто також називаються звітами про проблеми (problem report -- PR), повинні аналізуватися і трансформуватися в терміни програмної системи. Ці кроки виконуються після того, як відповідний запит на зміну починає оброблятися в рамках процесу управління змінами або, як прийнято називати, конфігураційного управління, і фіксується в системі конфігураційного управління (див. область знань Configuration Management). Цілі аналізу впливу можуть бути сформульовані наступним чином:

Визначення змісту змін для визначення робіт з планування та реалізації.

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

Аналіз вартості і вигоди від внесення запитаних змін (зазвичай стосується побажань, запитів на розширення системи)

Обговорення складності питань, пов'язаних із внесенням відповідних змін.

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

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

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

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

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

Як це часто можна почути -- "буде доступно в наступному релізі". Економічно, це часто буває більш ніж виправдано.

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

3. Компоненти реалізації задач супроводження

програмний забезпечення тестування

Збір запитів щодо майбутніх змін.

Проблеми стають зрозумілішими тільки коли система використовується; багато користувачів не можуть пояснити потреби змін у зрозумілому для аналітиків та програмістів вигляді.

Зміни способів програмування.

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

Зміна парадигм.

Багато програм, які використовуються та потребують супроводження, розроблялись без врахування професійних правил розробки, методик, сучасних технік розробки (використання малофункціональних мов програмування; нетипових програмних структур, інтерфейсів, функцій, структур та типів даних). Такі програми мають бути реструктуровані або переписані.

“Мертві” парадигми для “живих” систем.

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

Виявлення та усунення помилок.

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

Пріоритет вартості супроводу.

Роботи з супроводу споживають якщо не більшу, то значну частина фінансових ресурсів життєвого циклу програмного забезпечення. Загальне розуміння супроводу має на увазі лише усунення збоїв. Однак, дослідження та опитування протягом багатьох років показують, що більше 80% зусиль з супроводу пов'язані не стільки усуненням збоїв, скільки з іншими роботами, не пов'язаними з виправленням дефектів. Багато менеджери з супроводу об'єднують у звітності питання розширення функціональності і виправлення помилок у підтримуваних програмних системах. Така суміш якісно різних робіт призводить до неправильного уявленню про реальну вартість супроводу в частині усунення дефектів. Розуміння різних категорій 2 Судячи з усього, SWEBOK в даному випадку має на увазі функції не програмного забезпечення, а процесів супроводу і функції персоналу супроводу, як такі. 38 робіт в рамках діяльності по супроводу допомагає зрозуміти структуру реальних витрат. Крім того, розуміння факторів, що впливають на можливості супроводу системи, допомагають не тільки зберігати необхідний рівень витрат, але і знижувати їх. Існують як технічні, так і інші (наприклад, організаційні), фактори, що впливають на вартість супроводу:

тип програми;

новизна програмного забезпечення;

наявність і кваліфікація персоналу по супроводу;

тривалість використання програмної системи;

характеристики і специфіка апаратної частини (а також телекомунікаційної інфраструктури);

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

Оцінка вартості супроводу.

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

Оцінка вартості (Cost Estimation) ISO / IEC 14764 (Standard for Software Engineering -- Software Maintenance) визначає, що "існує два найбільш популярних методу оцінки вартості супроводу -- параметрична модель і використання досвіду". Найчастіше, обидва цих підходу комбінуються для підвищення точності оцінки.

Параметричні моделі (Parametric models) SWEBOK наводить ряд джерел, детально розглядають питання оцінки вартості супроводу і, зокрема, параметричні моделі. Для використання таких моделей використовуються дані попередніх проектів. Поряд із історичними даними використовується метод функціональних точок (див. стандарт IEEE 14143.1-00).

Досвід (Experience) Серед тих підходів, які дозволяють підвищити точність оцінок, отриманих при використанні параметричних моделей -- застосування досвіду (у формі експертної думки, наприклад, при використанні техніки оцінки "Delphi", назва якої походить від "делфійского оракула"), аналогій, а також структури декомпозиції робіт. Найкращі результати отримуються при поєднанні емпіричних методів з наявним досвідом. Отримані дані використовуються як результат програми вимірювання аспектів супроводу.

Вимірювання у супроводі програмного забезпечення. Форми і дані вимірювань в процесі супроводу можуть об'єднуватися в єдину корпоративну програму кількісних оцінок, які проводяться по відношенню до ПЗ. Багато організацій використовують популярний і практичний підхід для вимірювань, який базується на оцінці кількості проблем та статусу їх рішень (issue-driven measurement). Ідеї цього підходу систематизовані в проекті Practical Software and Systems Measurement (PSM).

Існують загальні (для всього життєвого циклу) метрики і, відповідно, їх категорії, які визначаються Інститутом Програмної Інженерії університету Карнегі-Меллон: розмір, зусилля, розклад і якість. Застосування цих метрик є гарною відправною точкою для оцінки робіт з боку організації, що відповідає за супровід. Більш детальне обговорення питань вимірювань відносно продуктів і процесів проводиться в галузі знань "Процес програмної інженерії (Software Engineering Process). Питання організації програми вимірювань відносяться до галузі знань "Управління програмної інженерії"(Software Engineering Management).

Спеціалізовані метрики (Specific Measures) Існують різні методи внутрішньої оцінки продуктивності (benchmarking) персоналу супроводу для порівняння роботи різних груп супроводу. Організація, що веде супровід, повинна визначити метрики, за якими будуть оцінюватися відповідні роботи. Стандарти IEEE 1219 (Standard for Software Maintenance) і ISO / IEC 9126-01 (Software Engineering -- Product Quality -- Part 1: Quality Model, 2001 г.) пропонують спеціалізовані метрики, орієнтовані саме на питання супроводу і відповідні програми.

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

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

Змінність (Changeability): оцінка зусиль, необхідних для проведення заданих модифікацій.

Стабільність (Stability): оцінка випадків непередбаченого поведінки системи, включаючи ситуації, виявлені в процесі тестування.

Тестованість (Testability): оцінка зусиль персоналу супроводу і користувачів по тестуванню модифікованого програмного забезпечення

Висновки

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

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

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