Поняття жц ПЗ. Основні процеси життєвого циклу ПЗ. Допоміжні процеси життєвого циклу ПЗ. Організаційні процеси життєвого циклу ПЗ.

Поняття ЖЦ ПЗ. Основні процеси життєвого циклу ПЗ. Допоміжні процеси життєвого циклу ПЗ. Організаційні процеси життєвого циклу ПЗ.

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

Момент закінчення експлуатації програми визначає, як правило, моральне старіння програми чи технічних засобів.

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

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

Визначними ознаками фази виступають:

- ступінь готовності програми;

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

- можливість контролю стану готовності програми;

- можливість контролю за якістю програмного продукту та управління процесом виготовлення програми.
Традиційно розрізняють такі основні фази ЖЦП:

- аналіз вимог до системи (програми);

- визначення специфікацій програми;

- проектування програми;

- кодування програми на мовах програмування;

- тестування програм;

- використання (експлуатація) програм;

- супроводження програм.

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

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

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

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

Тестування програми. Процес перевірки правильності роботи програми, вірніше, відповідність програми специфікаціям. Виконується в два етапи:

1) спочатку тестуються окремі модулі програми;

2) потім налагоджується програма в цілому.

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

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

Супроводження програми. Означає всі технічні операції, які необхідні для використання розробленої програми в робочому режимі. Включає: 1) усунення виявлених помилок в програмі у процесі її експлуатації; 2) адаптацію програми до нових вимог її застосування; 3) навчання користувачів способам використання програми; 4) консультації користувачів програми.

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

Класична модель водоспаду. Спіральна модель. Переваги та недоліки побудови моделей.

Етапи формулювання вимог до ПЗ. Функціональні та нефункціональні вимоги

Першим кроком аналізу має бути класифікація вимог. Множину зібраних вимог можна розподілити між двома головними категоріями:

- ті, що відображають можливості, які повинна забезпечити система, назвали функціональними вимогами (functional requirement);

- ті, що відображають обмеження, пов’язані з функціонуванням системи, назвали нефункціональними вимогами (notfunctional requirement).

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

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

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

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

- відмовостійкість;

- число клієнтів, котрі одночасно мають доступ до системи;

- вимоги безпеки;

- час чекання відповіді на звернення до системи;

- виконавські якості системи (обмеження щодо ресурсів пам’яті, швидкість реакції на звернення до системи тощо).

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

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

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

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

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

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

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

 

Архітектурні функції.

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

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

 

Інформаційна закритість

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

Інформаційна закритість означає наступне:

1. Всі модулі незалежні, обмінюються лише інформацією, яка необхідна для роботи;

2. Доступ до операцій і структур даних модуля обмежений.

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

Ідеальний модуль відіграє роль „чорного ящика”, вміст якого невидимий клієнтам. Він простий у використанні – кількість „ручок і органів управління” ним невелика. Його легко розвивати і коректувати в процесі супроводу ПЗ. Для забезпечення таких можливостей система внутрішніх і зовнішніх зв’язків модуля повинна відповідати особливим вимогам.

Зв’язність модуля

Зв’язність модуля – це міра залежності його частин, внутрішня характеристика модуля. Чим вища зв’язність модуля, тим кращий результат проектування, тобто тим „чорніший” його ящик, тим менше „ручок управління” на ньому знаходиться і тим простіші ці „ручки”.

Для вимірювання зв’язності використовують поняття сили зв’язності. Існує 7 типів зв’язності:

1. Функціональна зв’язність (10). Частини модуля разом реалізують одну функцію. Функціонально зв’язаний модуль містить елементи, які беруть участь у виконанні однієї і тільки однієї проблемної задачі. Коли клієнт викликає модуль, виконується тільки одна робота, без залучення зовнішніх обробників. Деякі з функціонально зв’язних модулів дуже прості, інші складні. Не дивлячись на складність модуля і на те, що його обов’язки виконують декілька функцій, якщо його дії можна представити як єдину проблемну функцію (з точки зору клієнта), тоді вважають, що модуль функціонально зв’язний. Програми, побудовані з функціонально зв’язних модулів, легше супроводжувати. Помилково вважати, що будь-який модуль можна розглядати як однофункціональний – існує багато різновидностей модулів, які виконують для клієнтів перелік різних робіт, і цей перелік не можна розглядати як єдину проблемну функцію. Критерій при визначенні рівня зв’язності цих нефункціональних модулів – як зв’язані один з одним різні дії, які вони виконують.

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

3. Комунікативна зв’язність (7). Частини модуля зв’язані за даним (працюють з однією і тою ж структурою даних). З точки зору клієнта проблема використання комунікативно зв’язного модуля полягає в надлишковості отримуваних результатів. Майже завжди розбиття комунікативно зв’язного модуля на окремі функціонально зв’язні модулі покращує супроводжуваність системи.

4. Процедурна зв’язність (5). Частини модуля зв’язані порядком виконуваних ними дій, які реалізують деякий сценарій поведінки. При досягненні процедурної зв’язності попадають в пограничну ділянку між доброю (для модулів з більш високими рівнями зв’язності) і поганою супроводжуваністю (для модулів з більш низькими рівнями зв’язності). Процедурно зв’язний модуль складається з елементів, які реалізують незалежні дії, для яких задано порядок роботи, тобто порядок передачі управління. Залежності за даними між елементами немає.

5. Часова зв’язність (3). Частини модуля не зв’язані, але необхідні в один і той же період роботи системи. Недолік: сильний взаємний зв’язок з іншими модулями та велика чутливість до внесення змін. При часовій зв’язності елементи-обробники модуля прив’язані до конкретного періоду часу. Класичним прикладом модуля такого типу зв’язності є модуль ініціалізації.

6. Логічна зв’язність (1). Частини модуля об’єднані за принципом функціональної подібності. Наприклад, модуль складається з різних підпрограм обробки помилок. При використанні такого модуля клієнт вибирає тільки одну з підпрограм. Недоліками таких модулів є складність спряження та велика ймовірність внесення помилок при зміні спряження заради однієї з функцій.

7. Зв’язність за співпадінням (0). В модулі відсутні явно виражені внутрішні зв’язки.

Зв’язність за співпадінням, логічна та часова зв’язності – результат неправильного планування архітектури, а процедурна зв’язність – результат поганого планування архітектури ПЗ.

Можливі більш складні випадки, коли з модулем асоціюються декілька рівнів зв’язності. В цих випадках потрібно застосовувати одно з двох правил:

- Правило паралельності. Якщо всі дії модуля мають декілька рівнів зв’язності, то модулю присвоюють самий сильний рівень.

- Правило послідовності. Якщо дії в модулі мають різні рівні зв’язності, то модулю присвоюють самий слабкий рівень.

Зчеплення модулів

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

- Кількість елементів даних, які передаються між ними.

- Кількість управляючих даних, які передаються між модулями.

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

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

Кількісно зчеплення вимірюється мірою зчеплення і виділяють 6 типів.

1. Зчеплення за даними (1). Модуль А викликає модуль В. Усі вхідні й вихідні параметри викликаного модуля – прості елементи даних.

2. Зчеплення за зразком (3). В якості параметрів використовуються структури даних.

3. Зчеплення за управлінням (4). Модуль А явно управляє функціонуванням модуля В (за допомогою прапорців або перемикачів), посилаючи йому управляючі дані.

4. Зчеплення за зовнішніми посиланнями (5). Модулі А і В посилаються на один і той же глобальний елемент даних.

5. Зчеплення за спільною пам’яттю (7). Модулі розділяють одну й ту ж глобальну структуру даних.

6. Зчеплення за вмістом (9). Один модуль прямо посилається на вміст іншого модуля (не через його точку входу). Наприклад, коди їх команд перемішуються один з одним.

Поняття ЖЦ ПЗ. Основні процеси життєвого циклу ПЗ. Допоміжні процеси життєвого циклу ПЗ. Організаційні процеси життєвого циклу ПЗ.

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

Момент закінчення експлуатації програми визначає, як правило, моральне старіння програми чи технічних засобів.

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

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

Визначними ознаками фази виступають:

- ступінь готовності програми;

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

- можливість контролю стану готовності програми;

- можливість контролю за якістю програмного продукту та управління процесом виготовлення програми.
Традиційно розрізняють такі основні фази ЖЦП:

- аналіз вимог до системи (програми);

- визначення специфікацій програми;

- проектування програми;

- кодування програми на мовах програмування;

- тестування програм;

- використання (експлуатація) програм;

- супроводження програм.

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

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

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

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

Тестування програми. Процес перевірки правильності роботи програми, вірніше, відповідність програми специфікаціям. Виконується в два етапи:

1) спочатку тестуються окремі модулі програми;

2) потім налагоджується програма в цілому.

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

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

Супроводження програми. Означає всі технічні операції, які необхідні для використання розробленої програми в робочому режимі. Включає: 1) усунення виявлених помилок в програмі у процесі її експлуатації; 2) адаптацію програми до нових вимог її застосування; 3) навчання користувачів способам використання програми; 4) консультації користувачів програми.