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

1.

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

2.

Навчальний процес
Лекцій –22
Лабораторні заняття – 22
Самостійна робота – 46
Всього (годин/кредитів ECTS) – 90/2.5
Оцінки
Домашнє завдання (1)
– 8ий семестр
Виконання
домашнього
завдання
Диференційований залік–
Виконання
лабораторних робіт
Національна шкала
Модульна
ий
8 семестр
контрольна робота
6
11-12
13-14
Відмінно
5
9-10
11-12
Добре
4
7-8
9-10
Задовільно
менше 4
менше 7
менше 9
Незадовільно

3.

Питання до розгляду
I.
Супроводження програмного забезпечення. Головні означення.
II. Потреба супроводження.
III. Структура супроводження програмного забезпечення.
IV. Література.

4.

I. Супроводження програмного
забезпечення. Головні означення.

5.

Немає такого поняття як “закінчена” комп’ютерна програма
Леман
Дисципліна , що охоплює питання пов’язані зі змінами програмного забезпечення після передачі
його в експлуатацію, зазвичай відома як Супроводження програмного забезпечення (СПЗ).
Супроводження програмного забезпечення (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 р.

6.

II. Потреба супроводження

7.

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

8.

ISO/IEC 14764 Процес супроводження програмного
забезпечення

9.

III. Структура супроводження програмного
забезпечення

10.

Структура супроводження програмного
забезпечення (1)
Компонент
Опис
1. Потреби користувачів
• Запити на додаткову функціональність, усунення помилок,
покращення супроводжуваності;
• Запити на технічну підтримку, не пов’язану з обробкою
програмного коду.
2. Організаційне середовище
• Зміна державних регуляторних політик;
• Конкуренція на ринку.
3. Операційне середовище
• Апаратні інновації;
• Програмні інновації.
4. Процес супроводження
Збір запитів щодо майбутніх змін;
Креативність та незадокументовані припущення;
Зміни способів програмування;
Зміна парадигм;
“Мертві” парадигми для “живих” систем;
Виявлення та усунення помилок.

11.

Структура супроводження програмного
забезпечення (2)
Компонент
Опис
5. Програмний продукт
• Сформованість та складність програмного
продукту;
• Якість документації;
• Піддатливість програм;
• Складність програмного коду;
• Структура програмного коду;
• Властива якість.
6. Спеціалісти зі супроводження
• Плинність кадрів;
• Знання проблемної області;
• Досвід роботи.

12.

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

13.

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

14.

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

15.

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

16.

Рис.1 Вартість визначення помилок на різних фазах
життєвого циклу програмного забезпечення

17.

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

18.

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

19.

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

20.

IV. Література
1.Guide to the Software Engineering Body of
Knowledge (SWEBOK). – California: IEEE
Computer Society, 2001. – 219 p.
2.Grubb Penny. Software Maintenance: Concepts
and Practice (2nd Edition) / [Penny Grubb, Takang
A. Armstrong]. – Singapore: World Scientific,
2003. – 349 p.
3.Pigosky M. Thomas. Practical Software
Maintenance – Best Practices for Managing Your