Формування прикладних моделей життєвого циклу

 

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

Модель життєвого циклу - це схема виконання робіт і задач у рамках проце­сів, що забезпечують розробку, експлуатацію і супровід програмного продукту. Ця схема відображає еволюцію ПС, починаючи від формулювання вимог і закінчуючи припиненням користування нею [1- 6].

Історично така схема робіт містить у собі:

- розробку вимог або технічного завдання;

- розробку ескізного або технічного проекту;

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

- пробну експлуатацію;

- супровід і поліпшення;

- зняття з експлуатації.

Основне призначення моделей ЖЦ є таким:

- планування і розподіл робіт і ресурсів між розробниками, а також керуван­ня програмним проектом;

- забезпечення взаємодії між розробниками проекту і замовником;

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

- узгодження проміжних результатів із замовником;

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

- оцінка відповідності характеристик якості отриманого продукту заданим вимогам;

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

Отже, для побудови конкретної моделі ЖЦ ПС, що задовольняє концептуа­льній ідеї проектованої системи з урахуванням її складності і масштабу робіт, необхідно зробити правильний вибір процесів, їх завдань і дій відповідно до стандарту. На сьогодні основою формування нової моделі ЖЦ для конкретної прикладної системи є стандарт ISO/IEC 12207, що задає повний набір процесів (більш 40), охоплює всі можливі види робіт і завдань, пов'язаних з побудовою ПС, починаючи з аналізу предметної області і закінчуючи виготовленням відповідного продукту. Стандарт ISO/IEC 12207 надає загальний опис процесів на найвищому рівні, проте він не покликаний деталізувати виконання дій або задач, з яких скла­даються процеси. Він також не ставить вимоги до формату і змісту документів, що випускаються на різних процесах.

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

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

Зі стандарту ІSО/ІЕС 12207 можна вибирати тільки ті процеси, що найбільше підходять для реалізації конкретної ПС. Обов'язковими є основні процеси, що є у всіх відомих моделях ЖЦ. Залежно від цілей і задач предметної області вони можуть бути поповнені процесами з категорії організаційних процесів даного стандарту. Розробник приймає рішення щодо необхідності вміщення в нову модель ЖЦ засобів забезпечення якості компонентів, системи керування проектом або визначення набору процедур перевірки для забезпечення правильності продукту і відповідності його заданим вимогам.

Процеси, що включені в модель ЖЦ, призначені для реалізації стандартних задач процесів ЖЦ, вони можуть залучати інші процеси, що пов'язані із забезпеченням захисту даних. Інтерфейси (входи і виходи) будь-яких двох процесів ЖЦ повинні бути мінімальними і кожний з них повинен відповідати таким правилам:

- якщо процес А викликається процесом В і тільки процесом В, то А нале­жить В;

- якщо функція викликається більше ніж одним процесом, то вона стає окре­мим процесом;

- перевірка будь-якої функції в ЖЦ є обов'язковою.

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

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

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

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

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

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

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

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

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

Приклад. ЖЦ розробки ПС із задачами і діями процесу тестування.

Головне призначення процесу тестування ЖЦ - виконання задач процесу на основі входів (вхідні дані для виконання задач процесу) і виходів при завершенні задач, а також ролей і дій виконавців цих задач.

Відповідно до стандарту ІSО/ІЕС 12207 задачі тестування розглянуті і розпо­ділені за процесами ЖЦ ПС. Як результат, отримано єдиний безперервний процес тестування різних продуктів ПС, задачами якого є підготовка, проведення й оціню­вання результатів тестування. Ці задачі розподілилися між 20 діями (кроками) про­цесу розроблення 17, 8]. Даний підхід до поглибленого тестування ПС доцільно застосовувати, наприклад, для систем реального часу.

На кроці підготовки здійснюється аналіз робочих продуктів процесу розроб­лення ПС (вхідних для даного кроку процесу тестування) для визначення цілей, об'єктів, сценаріїв і ресурсів тестування, адекватних кроку тестування. Результат виконання кроків підготовки тестування повинні фіксуватися в планах тестування (рис. 2.3).

 

Контрольні питання і завдання

1. Назвіть три основні групи процесів життєвого циклу.

2. Назвіть організаційні процеси ЖЦ і перерахуйте їх.

3. Охарактеризуйте процес керування якістю ЖЦ.

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

5. Чи всі процеси стандарту повинні бузи застосовані в розробці ПЗ ІЗ?

6. Охарактеризуйте суть моделі ЖЦ і основні види моделей.

7. Опишіть каскадну і спіральну моделі ЖЦ.

8. Охарактеризуйте еволюційну модель ЖЦ.

9. Назвіть інші види моделей ЖЦ.

 

 

4. Вимоги до програмних систем.

 

Кожна програмна система - це перетворювач, функцією якого є визначене перетворення даних і вивід результатів цього перетворення. З метою побудови програмної системи до неї, насамперед, формулюються вимоги до умов виконання функції і обробки даних. Ці вимоги є предметом практичного контракту між замовником і розробником системи [1].

У загальному випадку під вимогами до ПС розуміють властивості, які пови­нна мати система для виконання запропонованих замовником функцій. Прикладами таких функцій можуть бути бізнес-функції, документообіг, керування даними і структурою інформації, що необхідна для прийняття системних рішень, та ін. У ядрі знань SWЕВОК викладено основні концепції й особливості інженерії вимог, які подано на рис. 4.1.

 

Рис. 4.1. Основні розділи розробки вимог

 

Найпоширеніший інструмент інженерії вимог - це UML, у якому вимоги визначаються й уточнюються через подання можливих варіантів використання ПС(use case), що трансформуються у проектні рішення і архітектуру системи.