Esence-software-development

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

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

Модель життєвого циклу - це формалізована, абстрактна конструкція, яка відображає взаємозв'язок і послідовність виконання процесів ЖЦ і їх основних складових.

На початковому етапі розвитку обчислювальної техніки ПЗ розроблялися за принципом «кодування - усунення помилок»

На сучасности етапі широко використовуються три базові методології розробки ПО:

• каскадна;
• інкрементна;
• еволюційна.

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

Каскадна методологія це одноразовий прохід всіх етапів розробки.

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

Використання даної методології найбільш ефективно в наступних випадках:

1. при розробці проектів з чіткими, незмінними протягом ЖЦ вимогами і зрозумілою реалізацією;
2. при розробці проектів невисокої складності;.
3. при виконанні великих проектів в якості складової частини моделей ЖЦ, що реалізують інші методології розробки.
   

Інкрементна методологія це багаторазовий прохід етапів розробки із запланованим поліпшенням результату. Дана методологія базується на повному визначенні всіх вимог до програмного засобу (системи) на початку процесу розробки. Однак повний набір вимог реалізується поступово відповідно до плану в послідовних циклах розробки. Результат кожного циклу називається інкрементом.

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

Використання даної стратегії найбільш ефективно в наступних випадках

1. при розробці проектів, в яких більшість вимог можна сформулювати заздалегідь, але частина з них можуть бути уточнені через визначений період часу;
2. при розробці складних проектів з заздалегідь сформульованими вимогами; для них розробка системи або програмного засобу за один цикл пов'язана з великими труднощами;
3. при необхідності швидко поставити на ринок продукт, що має базові функціональні властивості;
4. при розробці проектів з низькою або середнім ступенем ризиків;
5. при виконанні проекту з застосуванням нових технологій.

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

• при розробці проектів, для яких вимоги занадто складні, невідомі заздалегідь, непостійні або вимагають уточнення;
• при розробці складних проектів, в тому числі:

1. великих довгострокових проектів;
2. проектів зі створення нових, які не мають аналогів ПЗ або систем;
3. проектів зі середнім і високим ступенем ризиків;
4. проектів, для яких потрібна перевірка концепції, демонстрація технічної здійсненності або проміжних продуктів;

• при розробці проектів, що використовують нові технології.

Методології створення ПЗ

Каскадна модель (waterflow model) [1] 26 ст. Водоспадна модель (каскадна схема) запропонована в 1970 році Вінстоном Ройсом. і використовувалася в розробці програмного забезпечення (рис. 2.2), яке передбачало, що перехід на наступну стадію здійснюється після того, як повністю будуть завершені проектні операції попередньої стадії і отримані всі вихідні дані для наступної стадії. Коротка характеристика каскадної схеми розробки програмного забезпечення:

• фіксований набір стадій;
• кожна стадія закінчується документованим результатом;
• наступна стадія починається тільки після закінчення попередньої.

Недоліки:

• негнучкість;
• фаза повинна бути завершена до переходу до наступної;
• набір фаз фіксований;
• важко реагувати на зміни вимог.

Ітеративна модель (Iterative and incremental development) – модель з проміжним контролем [2] 30 ст. Каскадна модель життєвого циклу не є ідеальною, оскільки лише дуже прості завдання проходять всі етапи без будь-яких ітерацій (повернень на попередні кроки процесу). Наприклад, при програмуванні може виявитися, що реалізація деякої функції неефективна і вступає в протиріччя з вимогами до продуктивності системи. У цьому випадку потрібні зміни проекту, а можливо, і переробка специфікацій.

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

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

Мета кожної ітерації в розробці ПЗ – отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерацій. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементно (нарощує функціональність). З точки зору структури життєвого циклу і процесу розробки така модель є ітеративною (iterative), а з точки зору розвитку продукту – інкрементною (incremental). Досвід індустрії розробки ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано. Тому цю модель часто називають моделлю ітеративної і інкрементної розробки (Iterative and incremental development, IID).

Спіральна модель [3] 31 ст. Для подолання перелічених проблем в середині 80-х років XX ст. була запропонована спіральна схема (рис. 2.4). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування призвело до того, що процес модифікації програмного забезпечення перестав сприйматися, як «необхідне зло», а став сприйматися як окремий важливий процес. Прототипом називають діючий програмний продукт, який реалізує окремі функції і зовнішні інтерфейси розроблюваного програмного забезпечення. На першій ітерації, як правило, специфікують, проектують, реалізують і тестують інтерфейс користувача. На другий - додають деякий обмежений набір функцій. На наступних етапах цей набір розширюють, нарощуючи можливості даного продукту. Основною перевагою даної схеми є те, що, починаючи з деякої ітерації, на якій забезпечена певна функціональна повнота, продукт можна надавати користувачеві, що дозволяє:

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

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

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