• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Відповідно до стандарту ISO/IEC 12207 задачі тестування розглянуті і розподілені за процесами ЖЦ ПС. В результаті отримано єдиний безперервний процес тестування різних продуктів ПС, задачами якого є підготовка, проведення й оцінювання результатів тестування. Ці задачі розподілилися між 20 діями (кроками) процесу розробки [7, 8]. Даний підхід до поглибленого тестування ПС доцільно застосовувати, наприклад, для систем реального часу.

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

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

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

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

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

Таблиця 3.2. Зміст задач процесу тестування

Для підключення задач тестування до всіх процесів ЖЦ проводиться:

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

– визначення стандартів на подання остаточних документів, метрик процесу, критеріїв початку і завершення задач і переходу до наступного кроку процесу;

– підбір методів тестування для вибраного класу ПС і перевірки правильності виконання задач тестування;

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

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

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

3.4.3. Підходи до моделювання ПрО мовними засобами DSL

Останні роки сформувался предметно–орієнтований підхід до опису проблематики деякої предметної області за допомогою мови DSL, проблемно–орієнтованого проектування DDD (Domain–Driven Design) та збирання ПС з готових КПВ, тощо. Підходу DDD відповідає систематичний підхід до розробки ПС для складних ПрО, що дозволяє створити базовану на моделі ПрО спільну мову (ubiquitous language) [2] для розробників СПС, як мова спілкування різних категорій розробників, так і мовою документування усіх етапів ЖЦ, метою якого є проведення вдосконалення (рефакторінгу) системи не на рівні коду, а на рівні базованих на ПрО моделей вимог, проектування, архітектури. При цьому модельним класам присвоюються наймення та повноваження реальних класів понять реального світу, які мають бути достатніми для організації їхньої взаємодії задля вирішення покладених на них задач. Спільна мова визначає ключові моменти:

– визначення ядра складної ПрО та визначення її ключових відмінностей;

– визначення неявних понять ПрО та перетворення їх на явні;

– визначення ЖЦ об`єктів моделювання вподовж розробки як бази трасування вимог на об`єкти кодування;

– застосування патернів для аналізу ПрО [3];

– співвіднесення патернів аналізу із патернами проектування.

Вирішення наведених проблем дозволить задати єдину мову аналізу, документування та обміну думками між членами команди розробників протягом ЖЦ розробки моделі ПрО.

Модель ПрО це архітектура у вигляді пошарової структури, де шар більш високого рівня використовує служби, що їх надає безпосередньо нижчий шар, останній не зобов`язаний знати про вищі шари, які користуються його послугами, а кожний проміжний шар “ізолює” нижчий шар від вищого. Ця модель завдається з трьох шарів, а саме:

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

– домен – відповідає за бізнес–логіку прикладного застосування;

– джерело даних – відповідає за звернення до баз даних, обмін повідомленнями, управління транзакціями.

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

Модель ПрО тестується як бізнес–правила у формі дотримання вимог. Таким чином підхід DDD поєднається з підходом керованого тестами проектування TDT (Test Driven Design).

Процес розроблення ПС або домену включає багаторівневий аналіз ПрО для встановлення єдиної термінології, вживаної розробниками сімейства і його членів (рис.3) та визначення компонентів, як готових ресурсів [12, 29, 30].

Готові програми зберігаються в багаточисельних бібліотеках (Matlab, IP, Demral і тому подібне), в репозітаріях e-science, Інтернеті, в названих системах загального призначення і (Rational Rose .NET, Sun IBM, Microsofts і ін.), а також у фірмах і організаціях розробників [3–7].

Із загальної точки зору, такі програми – ці готові ресурси (компоненти, сервіси, агенти, сервіси і ін.) для інтеграції їх в системи або сімейства систем, а також для організації обчислення завдань (фізичних, математичних, біологічних і тому подібне) у сучасних середовищах з використанням прикладних, проблемних і наукових бібліотек .Проте при організації обчислень на нових комп'ютерах, майнфреймах і кластерах виникають проблеми несумісності ЯП, старих і нових програмних ресурсів по організації в них фундаментальних структур і типів даних [8–13].

Вона набуває особливої актуальності ще по наступних причинах [3, 14, 15]:

Рис.3. Рівні аналізу домену

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

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

3. Широке поширення Інтернет технологій привів до створення нових мов опису даних і документів (XML, RDF, OWL і ін.) вимагає глибокого осмислення завдань передачі, перенесення і обробки даних в нових мережевих умовах типа Grid.

.На більш високому рівні аналізу доменів визначаються спільні архітектурні рішення для сімейства систем домену, ще вище – множина компонентів повторного використання (КПВ) для частини або всіх систем у сімействі. І, нарешті, він має забезпечувати часткову або повну підготовку КПВ для автоматизованої зборки компонентів із застосуванням генераторів і/або конфігураторів, включаючи для цього не програмні артефакти (тести, настанови тощо). На найвищому рівні процесу проектування ПС створюється опис моделі домену мовою DSL, яка повинна автоматизовано генеруватися відповідними інструментальними засобами [12. 21].

Читайте також:

1. АДАПТОВАНА ДО РИНКУ СИСТЕМА ФОРМУВАННЯ (НАБОРУ) ОКРЕМИХ КАТЕГОРІЙ ПЕРСОНАЛУ. ВІДБІР ТА НАЙМАННЯ НА РОБОТУ ПРАЦІВНИКІВ ФІРМИ
2. Алгоритм реалізації моделей
3. Алгоритм формування комплексу маркетингових комунікацій
4. Алгоритм формування потенціалу Ф2
5. Алгоритм формування статутного фонду банку
6. Альтернативні джерела формування підприємницького капіталу
7. Аналіз ефективності формування та використання банківських ресурсів
8. Аналіз капітальних інвестицій у формування основного стада
9. АНАЛІЗ ЛІНІЙНИХ МОДЕЛЕЙ ЕКОНОМІЧНИХ ЗАДАЧ
10. АНАЛІЗ ОБОРОТНИХ АКТИВІВ ЗА ДЖЕРЕЛАМИ ЇХ ФОРМУВАННЯ
11. Аналіз процесу формування маркетингових комунікацій
12. Аналіз руху та ефективності формування грошових потоків

Переглядів: 1892