ОснАлгор_Посібн_Яровенко

для будь-яких моделей ЖЦПЗ, методів і технологій створення програмного продукту.

В стандарті ISO/IEC 12207-95 (ДСТУ 3918-99) процеси, дії та задачі із створення ПС наведені в найбільш загальній природній послідовності. Але це не означає, що в такій самій послідовності вони повинні бути застосовані в конкретній моделі ЖЦ ПС. Залежно від проекту процеси, дії і задачі стандарту вибираються, упорядковуються і включаються в нову модель ЖЦ. При застосуванні вони можуть перекривати, переривати один одного, виконуватися ітераційно або рекурсивно. Це визначає «динамічний» характер стандарту і дозволяє реалізувати з його допомогою довільну модель ЖЦ ПС.

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

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

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

структура колективу розробників і зв’язків між ними;

планування послідовності робіт і термінів їх виконання;

підбір і підготовка ресурсів (людських, програмних і технічних) для виконання робіт;

оцінка можливостей реалізації проекту в заданий термін, вартість і ресурси. Впровадження моделі ЖЦ у практичну діяльність зі створення

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

Найбільш відомими моделями ЖЦ є: модель водопаду, ітеративна та інкрементальна, спіральна, V- та Y-подібні, прототипування, швидка розробка. Кожна з цих моделей, маючи переваги і недоліки, широко застосовуються на практиці.

Модель водопаду (Waterfall model) була запропонована в 1970 році Вінстоном Ройсом (Winston W. Royce) і відома також під назвою «каскадна модель. Відзначимо, що ця модель застосовується як для опису процесів ЖЦПЗ, так і для опису циклу розробки ПЗ (рис.2).

11

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

System

Requirements

Software

Requirements

Analysis

Program

Design

Coding

Testing

Operations

Рис.2. Оригінальна каскадна модель ЖЦПЗ В.Ройса.

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

Незважаючи на відмінності в різних модифікаціях основними і

визначальними ознаками каскадної моделі є:

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

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

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

4.Чітке визначення меж між етапами, при якому перехід до наступного етапу означає повне завершення робіт на попередньому етапі.

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

Етапи (стадії) ЖЦПП у відповідності з каскадною моделлю:

1.Формування системних вимог;

2.Формування вимог до програми;

3.Аналіз вимог;

4.Проектування програми;

5.Реалізація (кодування);

12

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

6.Тестування і відлагодження;

7.Експлуатація і супровід.

Достоїнства (переваги) каскадної моделі:

повна и узгоджена документація на кожному етапі;

легке визначення термінів і затрат на проект.

Разом з тим модель водопаду має суттєві недоліки:

процес створення ПП не завжди вкладається в таку жорстку форму і послідовність етапів;

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

значний розрив між часом внесення помилки (наприклад, на етапі проектування) і часом її виявлення (при супроводі), що призводить до суттєвої переробки ПП.

На думку сучасних спеціалістів, «основна помилка авторів моделі водопаду полягає в припущенні, що проект проходить через весь процес один раз, а всі помилки зосереджуються на стадії реалізації і легко ліквідовуються під час тестування компонентів і системи» [Фредерік П. Брукс, 1975].

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

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

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

Приведена вище послідовність дій процесу «Розробка» (Development) ЖЦПЗ стосується розробки складних програмних систем. Очевидно, що структура процесу розробки автономних програмних продуктів (ПП) для розв’язання навчальних задач є значно простішою. Для моделювання процесу розробки таких ПП цілком придатною є модифікована схема каскадної моделі ЖЦПЗ (рис.3).

13

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

степінь повноти і точності розуміння вимог до системи;

доцільність припинення проекту.

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

Рис.6. Спіральна модель ЖЦ ПЗ В силу своєї ітеративної природи спіральна модель допускає корегування

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

Рис.7. Спіральна модель ЖЦ ПЗ

16

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

Еволюційна модель в літературі часто називається моделлю швидкої розробки програм RAD (Rapid Application Development).

Рис.8. Модель еволюційного прототипування

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

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

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

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

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

При цьому враховуються такі чинники ризику:

реалізація всіх функцій системи одночасно може призвести до громіздкості;

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

швидка реалізація деяких функціональних можливостей системи і їх апробація;

використання проміжного продукту в наступному прототипі;

17

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

виділення окремих функціональних частин для реалізації їх у вигляді прототипу;

можливість збільшення фінансування системи;

зворотний зв'язок із замовником для уточнення функціональних вимог;

спрощення внесення змін у зв'язку із заміною окремих функції.

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

1.4. РЕКОМЕНДОВАНА СТРУКТУРА МОДЕЛІ ПРОЦЕСУ РОЗРОБКИ ПРОГРАМ, СТВОРЮВАНИХ В РАМКАХ ПРАКТИКУМУ.

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

Враховуючи навчальні цілі лабораторного практикуму, розглядатимемо основні етапи (дії) розробки автономних ПП з більшим рівнем деталізації, ніж прийнято в науковій літературі. Тому каскадна модель процесу (циклу) розробки навчальних програм в рамках даного практикуму матиме наступний вид (рис.10):

1 Визначення та аналіз вимог до ПП

2 Синтез інформаційної та математичної моделі об’єкту

3 Вибір та обґрунтування методу розв’язання задачі

4 Формалізований запис розв’язку задачі

1

18

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

1

5Синтез інформаційної моделі задачі

6Обґрунтування структури алгоритму

7Проектування алгоритму

(блок-схема)

8Обґрунтування структури програми

9Специфікація змінних

10Специфікація процедур та функцій

11Проектування інтерфейсу користувача

12Кодування програми

13Компіляція та відлагодження програми

14Верифікація і валідація програми

15Тестування програми та аналіз достовірності результатів обчислень

Рис. 10. Модифікована каскадна модель процесу розробки програм.

19

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

КОНТРОЛЬНІ ЗАПИТАННЯ.

1.Який стандарт визначає перелік і зміст процесів ЖЦПЗ?

2.За якими принципами здійснюється декомпозиція ЖЦПЗ на групи процесів?

3.Охарактеризуйте (коротко) групи процесів ЖЦПЗ.

4.В чому полягає суть ієрархії складових елементів ЖЦПЗ?

5.Чи всі процеси ЖЦПЗ, визначені стандартом, повинні бути застосовані в розробці конкретного ПП? Відповідь аргументуйте.

6.Охарактеризуйте суть поняття «модель ЖЦПЗ».

7.Які з основних призначень моделі ЖЦПЗ будуть реалізовані Вами при створенні програмних продуктів в рамках лабораторного практикуму?

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

9.В чому полягає істотна різниця між каскадною, ітеративною та спіральною моделями ЖЦПЗ?

10.На яких етапах розробки ПП передбачається участь замовника-користувача каскадною, ітеративною та спіральною моделями ЖЦПЗ?

20

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)