Життєвий цикл програмного забезпечення
Життє́вий цикл програ́много забезпе́чення — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення[1].
Поняття життєвого циклу програмного забезпечення відносять до дисципліни «Програмна інженерія».
Загальні поняття
В загальному випадку, життєвий цикл визначається моделлю й описується у формі методології (методу). Модель або парадигма життєвого циклу визначає загальну організацію і, як правило, основні його фази та принципи переходу між ними. Методологія (метод) визначає комплекс робіт, їх детальний зміст і рольову відповідальність спеціалістів на всіх етапах вибраної моделі.
Життєвий цикл програмного забезпечення супроводжується розробленням, обігом та використанням програмної документації.
Програмна документація — сукупність документів, що містять відомості, необхідні для розробки, виготовлення, супроводу та експлуатації програм[2]. Програмна документація є одним з видів технічної документації.
Комплекс державних стандартів, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм і програмної документації називається «Єдина система програмної документації» (ЄСПД)[3].
Моделі життєвого циклу програмного забезпечення
Модель життєвого циклу — це структура, що складається із процесів, робіт та задач, які включають в себе розробку, експлуатацію і супровід програмного продукту; охоплює життя системи від визначення вимог до неї до припинення її використання.
На сьогодні найбільшого розповсюдження набули дві моделі:
- каскадна модель;
- спіральна модель.
Каскадна модель
Однією з перших з'явилась каскадна модель, в якій кожен етап роботи виконується лише раз. На кожному етапі робота виконується настільки ретельно, щоб потреби повертатись до попереднього не виникало. Результат виконання кожного етапу, перед передачею в наступний, піддається верифікації.
Спіральна модель
Розробка ітераціями відображає об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головне ж завдання — щонайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення і доповнення вимог.
Виходячи з можливості внесення змін, як в процес, так і в проміжний продукт було створено спіральну модель ЖЦ (рис.3).
Внесення змін орієнтоване на задоволення потреби користувачів одразу, як тільки буде встановлено, що створені артефакти або елементи документації не відповідають дійсному стану розробки.
Дана модель ЖЦ допускає аналіз продукту на витку розробки, його перевірку, оцінку правильності та прийняття рішення про перехід на наступний виток або повернення на попередній виток для доопрацювання на ньому проміжного продукту.
Відмінність цієї моделі від каскадної полягає в можливості багато разів повертатися до процесу формулювання вимог і до повторної розробки версії системи з будь-якого процесу моделі.
-
Рис.3. Спіральна модель ЖЦ розробки програмних систем
Для програмного продукту така модель не дуже підходить з декількох причин. По-перше, висловлення вимог замовником носить суб'єктивний характер, вимоги можуть багаторазово уточнюватися протягом розробки ПС і навіть після завершення та випробовування, і часом може з'ясуватися, що замовник «хотів зовсім інше». По-друге, змінюються обставини та умови використання системи, тому загальновизнаним законом програмної інженерії є закон еволюції, який сформулюємо так: кожна діюча ПС з часом потребує внесення змін або виводиться з експлуатації.
При необхідності внесення змін до системи на кожному витку з метою отримання нової версії системи обов'язково вносяться зміни в заздалегідь зафіксовані вимоги, після чого повертаються на попередній виток спіралі для продовження реалізації нової версії системи з урахуванням усіх змін.
Еволюційна модель
У разі еволюційної моделі система послідовно розробляється з блоків конструкцій. На відміну від інкрементної моделі в еволюційній моделі вимоги встановлюються частково і уточнюються в кожному наступному проміжному блоці структури системи.
Використання еволюційної моделі припускає проведення дослідження предметної області для вивчення потреб її замовника і аналізу можливості застосування цієї моделі для реалізації. Модель використовується для розробки нескладних і некритичних систем, де головною вимогою є реалізація функцій системи. При цьому вимоги не можуть бути визначені відразу і повністю. Тому розробка системи здійснюється ітераційним шляхом її еволюційного розвитку з отриманням деякого варіанта системи–прототипу, на якому перевіряється реалізація вимог. Іншими словами, такий процес за своєю суттю є ітераційним, з етапами розробки, що повторюються, починаючи від змінених вимог і закінчуючи отриманням готового продукту. В деякому розумінні до цього типу моделі можна віднести спіральну модель.
Розвитком цієї моделі є модель еволюційного прототипування в рамках усього ЖЦ розробки ПС (рис.4).
-
Рис.4. Модель еволюційного прототипування
У літературі вона часто називається моделлю швидкої розробки програм RAD (Rapid Application Development).
У даній моделі наведені дії, які пов'язані з аналізом її застосовності для конкретного виду системи, а також обстеженням замовника для визначення потреб користувача при розробці плану створення прототипу.
У моделі є дві головні ітерації розробки функціонального прототипу, проєктування і реалізації системи з метою перевірки, чи задовольняє вона всі функціональні і нефункціональні вимоги. Основною ідеєю цієї моделі є моделювання окремих функцій системи в прототипі і поступове еволюційне його доопрацювання до виконання всіх заданих функціональних вимог.
Ітерацій з отримання проміжних варіантів прототипу може бути декілька, в кожній з яких додається функція і повторно моделюється робота прототипу. І так до тих пір, поки не будуть промодельовані всі функції, задані у вимогах до системи. Після цього виконується ще одна ітерація — остаточне програмування для отримання готової системи.
Ця модель застосовується для систем, в яких найбільш важливими є функціональні можливості, і які необхідно швидко продемонструвати на CASE-засобах.
Оскільки проміжні прототипи системи відповідають реалізації деяких функціональних вимог, їх можна перевіряти і під час супроводу і експлуатації, тобто разом з процесом розробки чергових прототипів системи. При цьому допоміжні і організаційні процеси можуть виконуватися разом з процесом розроблення і накопичувати відомості за даними кількісних і якісних оцінок на процесах розроблення.
При цьому враховуються такі чинники ризику:
– реалізація всіх функцій системи одночасно може призвести до громіздкості;
– обмежені людські ресурси зайняті розробкою протягом тривалого часу.
Переваги застосування даної моделі ЖЦ такі:
– швидка реалізація деяких функціональних можливостей системи і їх апробація;
– використання проміжного продукту в наступному прототипі;
– виділення окремих функціональних частин для реалізації їх у вигляді прототипу;
– можливість збільшення фінансування системи;
– зворотний зв'язок із замовником для уточнення функціональних вимог;
– спрощення внесення змін у зв'язку із заміною окремих функції.
Модель розвивається у напряму додавання нефункціональних вимог до системи, пов'язаних із захистом і безпекою даних, несанкціонованим доступом до них і ін.
Визначення вимог до програмних систем
Актор починає заданий сценарій при звертанні до автоматизованої системи обслуговування бібліотеки. Усі сценарії, що містяться у системі, обведені рамкою, яка визначає межі системи, а актор знаходиться поза рамкою як зовнішній чинник системи.
Відношення між сценаріями. Між сценаріями відношення задаються стрілками з указівкою назви типу відносин.
Характеристика областей знань з інженерії програмного забезпечення — SWEBOK
У підрозділі розглядається теоретичний і інтелектуальний базис проєктування — методи, принципи, засоби і методології, представлені областями в ядрі знань програмної інженерії SWEBOK.
Ядро знань SWEBOK — основний науково-технічний документ, що відображає знання та досвід багатьох іноземних і вітчизняних фахівців з програмної інженерії [1–10] і узгоджується з регламентованими процесами ЖЦ стандарту ISO/IEC 12207.
Документ містить у собі опис 10 областей, кожна з яких представлена відповідно до прийнятої всіма учасниками формування ядра SWEBOK загальної схеми опису, що містить у собі визначення понятійного апарату, методів і засобів, а також інструментів підтримки інженерної діяльності. Стосовно кожної області визначено коло знань, які повинні практично використовуватися при виконанні процесів життєвого циклу.
Для подання понятійного апарату областей знань SWEBOK проведемо умовне розділення областей на головні (п'ять областей для розроблення ПС, рис. 1.7) і допоміжні організаційні області (п'ять областей, що забезпечують інженерію керування розробкою ПС, рис.1.8).
У кожній області наведені ключові поняття, підходи і методи проєктування різних типів ПС. Розподіл областей на основні і допоміжні відповідає структурі розподілу процесів стандарту ISO/IEC 12207 (див. розділ 2), виконання яких визначається методами і засобами, запропонованими в ядрі знань SWEBOK.
Далі подається огляд кожної області цього ядра, визначається її роль у проєктуванні і реалізації програмних продуктів. У деяких підрозділах показаний зв'язок з положеннями відповідних стандартів, що регламентують і регулюють виконання процесів проєктування програмних систем.
Супровід програмного забезпечення
Супровід програмного забезпечення[4] — сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. У зв'язку з вирішенням так званої проблеми 2000 року (пов'язаної з кодуванням дат у новому тисячолітті, зокрема, у двохсимвольному форматі) супровід почав розглядатися, як більш важливий процес, що здійснюють розробники. Після змін система має вирішувати ті самі задачі, а також мати план перенесення інформації в інші БД. Супровід відповідно до стандартів ISO/IEC 12207 і ISO/IEC 14764 проводиться з метою виконання і модифікації програмного продукту в процесі експлуатації за умови збереження його цілісності.
Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів:
– основні концепції (Basic Concepts),
– процес супроводження (Process Maintenance),
– ключові питання супроводу ПЗ (key Issue in Software Maintenance) ,
– техніки супроводу (Techniques for Maintenance).
Супровід розглядається з точки зору задоволення вимог споживача у готовому ПЗ, коректності його виконання, процесів навчання й оперативного обліку його процесу.
Основні концепції — це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. До основних концепцій можна віднести ЖЦ ПЗ (стандарт ISO/IEC 12207) і складання документації. Головне призначення цієї області знань полягає у виконанні готової програмної системи, фіксації помилок, що виникають при виконанні, дослідженні їх причин, аналізі необхідності модифікації системи з метою усунення помилок, оцінці вартості робіт із проведення змін функцій і системи в цілому. Розглядаються проблеми, пов'язані з ускладненістю продукту при великій кількості змін, і методи її подолання.
Процес супроводження містить у собі моделі процесу супроводу і планування діяльності людей, що проводять запуск ПЗ, перевірку правильності його виконання і внесення в нього змін. Цей процес згідно з стандартом ISO/IEC 14764 проводиться шляхом:
– коригування, тобто зміни продукту для усунення виявлених помилок або нереалізованих задач;
– адаптації, тобто настроювання продукту в умовах експлуатації, що змінилися, або в новому середовищі виконання;
– поліпшення, тобто еволюційної зміни продукту для підвищення продуктивності або рівня супроводу;
– перевірки ПЗ, пошуку і виправлення помилок при експлуатації системи.
Ключові питання супроводу ПЗ — це управлінські, вимірювальні і вартісні. Суть управлінських питань — контроль ПЗ при модифікації й удосконалюванні функцій і недопущення зниження продуктивності системи. Питання вимірювання пов'язане з оцінкою характеристик системи після її модифікації, а також повторного тестування для оцінки показників якості. Вартісні питання пов'язані з оцінкою витрат на супровід залежно від його типу, кваліфікації персоналу, платформи й ін.
Техніка супроводу (цей розділ називають також еволюцією ПЗ). Відомий фахівець в області ПЗ Дж. Леман (1970 р.) запропонував розглядати супровід як еволюційну розробку програмних систем, оскільки здана в експлуатацію система не завжди цілком завершена, її треба змінювати протягом терміну експлуатації. Внаслідок змін система стає більш складною і погано керованою. У зв'язку з цим виникає проблема зменшення її складності. До технологій еволюції ПЗ відносять реінженерію, реверсну інженерію і рефакторинг.
Реінженерія — це удосконалення застарілого ПЗ шляхом його реорганізації або реструктуризації, а також перепрограмування окремих елементів або настроювання параметрів на іншу платформу, середовище виконання зі збереженням зручності його супроводу.
Реверсна інженерія полягає у відновленні специфікації (графів викликів, потоків даних і ін.) за отриманим кодом системи для її аналізу на більш високому рівні. Відновлюється ідентифікація компонентів і зв'язків між ними для забезпечення перепрограмування системи на нову платформу. Найчастіше реверсна інженерія застосовується після того, як у код ПЗ було внесено багато змін і воно стало некерованим або змінилася платформа комп'ютера.
Рефакторинг — це реорганізація коду для поліпшення характеристик і показників якості об'єктно-орієнтованих і компонентних програм без зміни їх поведінки. Цей процес реалізується шляхом поступової зміни окремих операцій над текстами, інтерфейсами, середовищем програмування і виконання ПЗ, а також настроювання або внесення змін в інструментальні засоби підтримки ПЗ. Якщо при зміні зберігається формат існуючої системи, то рефакторинг — один з варіантів реверсної інженерії.
Інженерія вимог
Вимоги до ПЗ — сукупність властивостей, які повинно мати ПЗ. Призначені для адекватного визначення функцій, умов і обмежень виконання ПЗ, а також обсягів даних, технічного забезпечення і середовища його виконання.
Вимоги відбивають потреби людей (замовників, користувачів, розробників), зацікавлених у створенні ПЗ. Замовник і розробник спільно виявляють вимоги, аналізують, переглядають, визначають необхідні обмеження і умови, а також описують їх. Розрізняють вимоги до продукту і до процесу, а також функціональні, не функціональні і системні вимоги. Функціональні вимоги визначають призначення і функції системи, а не функціональні — умови стосовно виконання ПЗ, його переносності і доступу до даних. Системні вимоги описують вимоги до програмної системи, яка складається з взаємозалежних програмних і апаратних підсистем і різних застосувань.
Область знань «Вимоги до ПЗ (Software Requirements)» складається з таких розділів:
- інженерія вимог (Requirement Engineering),
- виявлення вимог (Requirement Elicitation),
- аналіз вимог (Requirement Analysis),
- специфікація вимог (Requirement Specification),
- валідація вимог (Requirement validation),
- керування вимогами (Requirement Management).
Інженерія вимог до ПЗ — це дисципліна аналізу і документування вимог до ПЗ, що полягає в перетворенні запропонованих замовником вимог до системи на опис вимог до ПЗ і їх валідації.
Виявлення вимог — це процес витягування інформації з різних джерел (договорів, матеріалів аналітиків з декомпозиції задач і функцій системи й ін.), проведення технічних заходів (співбесід, збирання пропозицій і ін.) для формування окремих вимог до продукту і до процесу розроблення.
Аналіз вимог — процес вивчення потреб і цілей користувачів, класифікація і перетворення їх на вимоги до системи, апаратури і ПЗ, встановлення і вирішення конфліктів між вимогами, визначення пріоритетів, меж системи і принципів взаємодії із середовищем функціонування.
Специфікація вимог до ПЗ — процес формалізованого опису функціональних і нефункціональних вимог, вимог до характеристик якості відповідно до стандарту якості ISO/IEC 9126, які будуть відпрацьовуватися на процесах ЖЦ ПЗ.
Верифікація вимог — це процес перевірки правильності специфікацій вимог щодо їх відповідності потребам, несуперечності, повноти і можливості реалізації, а також узгодженості зі стандартами.
Керування вимогами — це керування процесами формування вимог на всіх процесах ЖЦ, а також змінами й атрибутами вимог, проведення моніторингу — відновлення джерела вимог.
Проєктування програмного забезпечення
Проєктування ПЗ — це процес визначення архітектури, набору компонентів, їх інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту. Область знань «Проєктування ПЗ (Software Design)» складається з таких розділів: — базові концепції проєктування ПЗ (Software Design Basic Concepts), — ключові питання проєктування ПЗ (Key Issue in Software Design), — структура й архітектура ПЗ (Software Structure and Architecture), — аналіз і оцінка якості проєктування ПЗ (Software Design Quality Analysis and Evaluation), — нотації проєктування ПЗ (Software Design Notations), — стратегія і методи проєктування ПЗ (Software Design Strategies and Methods). Базова концепція проєктування ПЗ — це методологія проєктування архітектури за допомогою різних методів (об'єктного, компонентного й ін.), процеси ЖЦ (стандарт ISO/IEC 12207) і техніки — декомпозиція, абстракція, інкапсуляція й ін. На початкових стадіях проєктування предметна область декомпозується на окремі об'єкти (при об'єктно-орієнтованому проєктуванні) або на компоненти (при компонентному проєктуванні). Ключові питання проєктування — це декомпозиція програм на функціональні компоненти для незалежного і одночасного їхнього виконання, розподіл компонентів у середовищі функціонування і їх взаємодія між собою, забезпечення якості і живучості системи й ін. Проєктування архітектури ПЗ проводиться архітектурним стилем, заснованим на визначенні основних елементів структури — підсистем, компонентів, об'єктів і зв'язків між ними. Аналіз і оцінка якості проєктування ПЗ — це заходи щодо аналізу сформульованих у вимогах атрибутів якості, функцій, структури ПЗ, з перевірки якості результатів проєктування за допомогою метрик (функціональних, структурних і ін.) і методів моделювання і прототипування. Нотації проєктування дозволяють представити опис об'єкта (елемента) ПЗ і його структуру, а також поведінку системи за цим об'єктом. Існує два типи нотацій: структурна, поведінкова, та множина їх різних представлень. Стратегія і методи проєктування ПЗ. До стратегій відносять: проєктування вгору, вниз, абстрагування, використання каркасів і ін.
Конструювання програмного забезпечення
Область знань «Конструювання ПЗ (Software Construction)» містить у собі такі розділи: — зниження складності (Reduction in Complexity), — попередження відхилень від стилю (Anticipation of Diversity), — структуризація перевірок (Structuring for Validation), — використання стандартів (Use of External Standards). Зниження складності — це мінімізація, зменшення і локалізація складності конструювання. Попередження відхилень від стилю. Для розв'язання різних задач конструювання застосовуються різні стилі конструювання (лінгвістичний, формальний, візуальний). Структуризація перевірок припускає, що побудова ПС структурована таким чином, що спрощується пошук помилок, дефектів і різних збоїв у процесі перевірок як на стадії незалежного тестування, так і в процесі експлуатації. Використання зовнішніх стандартів. Конструювання ПЗ залежить від застосовних зовнішніх стандартів, пов'язаних з мовами програмування, інструментальними засобами й інтерфейсами. Керування конструюванням — це керування процесом конструювання ПЗ, планування, оцінка виконання плану і розроблення заходів щодо внесення змін.
Тестування програмного забезпечення
Тестування ПЗ — це процес перевірки готової програми в статиці (перегляди, інспекції, налагодження вихідного коду) і в динаміці (прогін на наборі тестових даних) з метою перевірки різних шляхів виконання програми і порівняння отриманих результатів із заздалегідь заданими. Область знань «Тестування ПЗ (Software Testing)» містить у собі такі розділи: — основні концепції і визначення тестування (Testing Basic Concepts and definitions), — рівні тестування (Test Levels), — техніки тестування (Test Techniques), — метрики тестування (Test Related Measures), — керування процесом тестування (Managing the Test Process). Основна концепція тестування — це базові терміни, ключові проблеми і їхній зв'язок з іншими областями знань. Тестування визначається як процес перевірки правильності програми в динаміці її виконання за тестовими даними. Рівні тестування: — тестування окремих елементів — інтеграційне тестування — тестування системи Техніки тестування базуються на певних теоретичних і практичних положеннях щодо проєктування (компонентного, об'єктно-орієнтованого, сервісного і т. ін.). Метрики тестування. Для вимірювання результатів тестування ПЗ й оцінки якості використовуються метрики. Вимір як частина планування і розробки тестів базується на розмірі програм, їх структурі і кількості виявлених помилок і дефектів. Метрики тестування — це вимірювання процесу планування, проєктування і тестування, а також результатів тестування на основі таксономії відмов і дефектів, покриття границь тестування, перевірки потоків даних і ін.
Супровід програмного забезпечення
Супровід ПЗ — сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів: — основні концепції (Basic Concepts), — процес супроводження (Process Maintenance), — ключові питання супроводу ПЗ (key Issue in Software Maintenance) , — техніки супроводу (Techniques for Maintenance). Основні концепції — це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. Ключові питання супроводу ПЗ — це управлінські, вимірювальні і вартісні. Суть управлінських питань — контроль ПЗ при модифікації й удосконалюванні функцій і недопущення зниження продуктивності системи. Техніка супроводу (цей розділ називають також еволюцією ПЗ). Відомий фахівець в області ПЗ Дж. Леман (1970 р.) запропонував розглядати супровід як еволюційну розробку програмних систем, оскільки здана в експлуатацію система не завжди цілком завершена, її треба змінювати протягом терміну експлуатації. Внаслідок змін система стає більш складною і погано керованою.
Методи об'єктного аналізу і моделювання
Огляд об'єктно-орієнтованих методів аналізу і побудови моделей.
На даний час створено понад 50 об'єктно-орієнтованих методів, які застосовуються практично як механізми розроблення об'єктних моделей і побудови на їхній основі програмних систем. Головним поняттям цих методів є об'єкт, а також інші означення елементів предметної області, яка створюється.
Метод об'єктно-орієнтованого моделювання передбачає послідовне виконання двох етапів: об'єктно-орієнтованого аналізу та об'єктно-орієнтованого проєктування.
Об'єктний аналіз — дослідження об'єктів предметної області. Предметна область містить в собі ті об'єкти і взаємозв'язки між ними, які істотно значемі при описі вимог та умов в розв'язанні задач. В процесі об'єктно-орієнтованного проєктування визначають програмні об'єкти та способи їхньої взаємодії і схеми баз даних.
Основні поняття об'єктно-орієнтованих методів аналізу
До основних понять методів об'єктно-орієнтованого аналізу предметної області — ПрО належать наступні .
Об'єкт — це абстрактний елемент, що має поведінку, обумовлену його характеристиками і відношеннями з іншими об'єктами предметної області.
Відповідно до теорії Фреге специфікацію об'єкта можна трактувати як трійку:
<ім’я об’єкта> <денотат> <концепт>,
де <ім’я об’єкта> — ідентифікатор, рядок з літер і чисел;
<денотат> — сутність реальної ПрО, що позначається цим ідентифікатором;
<концепт> — семантика (зміст) денотата ПрО.
Схематично це можна подати за допомогою трикутника Фреге (рис 1). В ньому містяться елементи реального світу, які мають такі властивості і характеристики:
знак — ідентифікатор, який позначає денотат;
денотат — сутність знаку, позначеного цим ідентифікатором;
концепт — семантика денотату.
Вони визначаються на рівнях об'єктного аналізу із залученням математичних формалізмів їхнього опису та уточнення відрізняючих один об'єкт від іншого.
-
(рис 1) Подання об’єктів ПрО за трикутником Фреге
Тобто, об'єкт є іменована частина дійсної реальності з певним рівнем абстракції за наведеними характеристиками відносно вибраної ПрО. Як понятійна структура об'єкт відображає зміст концепту за об'єктним моделюванням предметної області. Одному об'єкту можуть відповідати кілька концептів залежно від вибраного рівня абстракції.
Див. також
Примітки
- ↑ ДСТУ 2844-94 Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.
- ↑ ГОСТ 19.101-77 Единая система программной документации. Виды программ и программных документов.
- ↑ ГОСТ 19.001-77 Единая система программной документации. Общие положения.
- ↑ Лаврищева К. М. «Програмна інженерія» http://www.programsfactory.univ.kiev.ua/content/books/2/28 [Архівовано 26 лютого 2012 у Wayback Machine.]