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

загальна направленість

Лабораторні заняття – 22
Самостійна робота – 46
Всього (годин/кредитів ECTS) – 90/2.5
Домашнє завдання (1) – 8ий семестр
Диференційований залік– 8ий семестр

Література.

пов’язані зі змінами програмного забезпечення після передачі його в експлуатацію, зазвичай відома як Супроводження програмного забезпечення (СПЗ).
Супроводження програмного забезпечення (IEEE 1219, Standard for Software Maintenance) – це модифікація програмного продукту після передачі його в експлуатацію для усунення помилок, підвищення показників продуктивності або інших атрибутів, або адаптації продукту до модифікованого середовища.
Супроводження (ISO/IEC 12207 Standard for Life Cycle Processes, ISO/IEC 14764 The International Standard for Software Maintenance) – процес “модифікації програмного коду та пов'язаної з ним документації , що викликаний появою проблем або потребою в удосконаленні” програмного продукту.
Супроводження програмного забезпечення(SWEBOK) – сукупність заходів, що необхідні для забезпечення витратноефективної підтримки програмних систем (заходи до та після передачі в експлуатацію).
Супроводжувач (maintainer) (ISO/IEC 12207) – організація, яка здійснює заходи супроводження.
Еволюція – це процес безперервних змін від нижчого, простішого, чи гіршого до вищого, більш комплексного, чи кращого рівня. Питання з області знань СПЗ та еволюції систем вперше були озвучені Леманом у 1969 р.

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

залучення у процес розробки та супроводження.
Реалізація модифікацій вимагатиме:
a) “прогресивної” роботи щодо удосконалення
існуючих функцій або впровадження нових;
b) “анти-регресивної” роботи для того, щоб зробити
програми добре структурованими, краще
документованими, більш зрозумілими і здатними до
подальшого розвитку.

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

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

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

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

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

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

California: IEEE Computer Society, 2001. – 219 p.
Grubb Penny. Software Maintenance: Concepts and Practice (2nd Edition) / [Penny Grubb, Takang A. Armstrong]. – Singapore: World Scientific, 2003. – 349 p.
Pigosky M. Thomas. Practical Software Maintenance – Best Practices for Managing Your Software Investment / Thomas M. Pigosky. – Canada: Wiley Computer Publishing, 1997. – 228 p.