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

Размещено на http://allbest.ru

Харківський державний технічний університет радіоелектроніки

Автореферат

дисертації на здобуття наукового ступеня кандидата технічних наук

Спеціальність 01.05.04 - системний аналіз і теорія оптимальних рішень

БАГАТОРІВНЕВА ІНТЕЛЕКТУАЛЬНА СКРІЗНА МОДЕЛЬ СТВОРЕННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Виконала Вільчінська Ольга Сергіївна

Харків - 2001



АНОТАЦІЯ

Вільчінська О.С. Багаторівнева інтелектуальна скрізна модель створення програмного забезпечення. - Рукопис.

Дисертація на здобуття наукового ступеня кандидата технічних наук за спеціальністю 01.05.04 - системний аналіз і теорія оптимальних рішень. - Харківський державний технічний університет радіоелектроніки, Харків, 2001.

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

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



1. ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ

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

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

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

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

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

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

Зв'язок роботи з науковими програмами, планами, темами. Дослідження виконувались згідно з планом науково-дослідної роботи Харківського державного технічного університету радіоелектроніки в рамках держбюджетних тем: №526-4 «Обґрунтування і розробка нового методичного та інтелектуального програмного забезпечення для комп'ютерно-орієнтованих дидактичних систем» (№ДР 0197U014156) і №360 «Розробка концепцій та математичного апарату інтелектуальної обробки мультиекспертних знань в глобальних інформаційних системах» (№ДР 0197U008894). Автор узяв участь у даних роботах як виконавець.

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

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

розробити методологію створення програмного забезпечення, орієнтовану на інтелектуальну підтримку CASE-засобів та засновану на уніфікованому життєвому циклі програмного забезпечення;

розробити структуру та принципи функціонування та взаємодії з іншими CASE-засобами інтелектуального інструментального засобу;

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

програмно реалізувати алгоритм оцінки складності об'єктно-орієнтованих програм в складі підсистеми аналізу поточного стану проекту.

Об'єкт дослідження - процес створення програмного забезпечення.

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

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

Наукова новизна одержаних результатів. Внаслідок проведеного дослідження отримані такі результати:

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

вперше запропоновано методологію MIXER, яка забезпечує аналіз проекту на всіх етапах життєвого циклу програмного забезпечення і орієнтована на інтелектуальну підтримку CASE-засобу, що в підсумку підвищить ефективність процесу розробки програмного забезпечення;

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

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

Отримані під час роботи над дисертацією результати були використані при розробці програмного забезпечення до системи «Банкомат» та підсистем великих програмних продуктів, які входять у програмний комплекс АТС (автоматизованих телефонних станцій) у Харківському державному приладобудівному заводі ім. Т.Г. Шевченка (акт впровадження від 10.08.2000р.). Підсистема оцінки складності класів і системи в загалом дозволила значно підвищити якість розробленого програмного забезпечення і зменшити технічні вимоги при використанні.

Також результати досліджень і розробок використовувались в учбовому процесі при підготовці курсів «Основи проектування систем із штучним інтелектом» та «Методологія розробки програмних продуктів та великих систем» на кафедрі Штучного Інтелекту ХТУРЕ (акт впровадження від 2.10.2000 р.).

Особистий внесок здобувача. У співпраці [5] здобувачу належить модель відкритої архітектури системи медичної діагностики. У роботі [6] здобувачу належить оцінка загальної складності використаних статистичних алгоритмів та застосування CASE-засобів для створення системи діагностики. У співпраці [7] здобувачу належить модель уніфікованого життєвого циклу розробки програмного забезпечення. Усі результати, що винесені на захист, отримані автором особисто.

Апробація результатів дисертації. Результати досліджень доповідались і обговорювались на конференціях та семінарах: Першому міжнародному форумі «Электроника и молодежь в XXI веке», Міжнародній науково-технічній конференції «International Meeting on Information Technology» (MicroCAD'97); Міжнародній науково-технічній конференції «International Meeting on Information Technology» (MicroCAD'98); Українській конференції з автоматичного управління «Автоматика-99».

2. ОСНОВНИЙ ЗМІСТ РОБОТИ

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

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

Другий розділ дисертаційної роботи присвячений розробці скрізної моделі уніфікованого життєвого циклу програмного забезпечення. З появою об'єктно-орієнтованої методології дійсно використані життєві цикли почали відрізнятися від тих, що описані в міжнародних стандартах. Особлива увага приділяється конкретизації робіт з технологічної підтримки і графічної візуалізації процесу проектування, деталізації процесів життєвого циклу, забезпечуючи високу якість програмного забезпечення, що створюється, і можливості його ефективного ітераційного розвитку. Формальною моделлю проекту є двійка:

PR=<NM, R>, (1)

де NM - множина проекту, що складається з підмножин, які ідентифікують програмне забезпечення: назва проекту ID; предметна галузь проекту PО.

Згідно з уніфікованим життєвим циклом та моделлю (1) модель життєвого циклу в термінах теорії прийняття рішення матиме такий вигляд: виділення множини максимальних елементів (ядра) на множині альтернативних множин проекту X з бінарного відношення порівняльної ефективності R:

(2)



де X - кінцева множина альтернативних варіантів проекту.

Бінарне відношення R визначається на основі знання про детальні технічні характеристики варіантів проектів, починаючи з агрегованих описів проектів і часткових відносин R_k, де k= - рівні агрегування. Поступово доступні знання про детальні характеристики розширюються під час проектування.

Описи проектів за рівнями агрегування пов'язані таким чином:

x_k+1=F_k+1(x_k),

X_k+1=F_k+1(X_k),

де x_kX_k; F_nk - відображення;

n_k - розмірність опису;

n_k+1<n_k, k = ;

n₀ = n,

x₀ = x,

X₀ = X;

m - кількість рівнів агрегування.

Тому замість моделі прямого вибору використовуватимемо модифікацію задачі у формі агрегування-декомпозиції з послідовним аналізом і відбракуванням варіантів:

,

де - початкова умова. Тут R₀ = R, а F^-1_k+1(X'_k+1) - повний прообраз множини X'_k+1 при відображенні

F_k+1:X_kX_k+1.



Розв'язанням задачі проектування є множина X'₀. При цьому на кожному рівні:

X_kX'_k= X_k/Q_k,

де Q_k - відбраковані варіанти. Етапна декомпозиція проектної розробки призводить до сукупності рішень, які приймаються послідовно в міру виконання необхідних попередніх кроків. Тому для моделювання етапності визначена динамічна постановка задачі вибору з параметризацією моделі за часом.

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

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

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

Багаторівнева організація проектування відповідає таким властивостям:

1. У проектуванні виділяються три рівні: специфікація, концептуальне (логічний і структурно-параметричний синтез) і параметричне проектування.

2. Багаторівневий процес проектування розвивається згори вниз, тобто від синтезу загальних проектних вимог на першому рівні до проектних рішень необхідної міри деталізації на наступних рівнях. При цьому рішення, прийняті на (k-1) рівні проектування (R_ij^k-1), є додаткові початкові дані для k-рівня: (R_ij^k).

3. На всіх рівнях критерії вибору NM_i ефективних варіантів і їх значення послідовно уточнюються: NM_k-1, NM_k.

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

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

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

Методології M=<Mt, P>, що описують методи Mt і правила P кожного з етапів життєвого циклу програмного забезпечення, назвемо методологіями першого рівня. Методології MM=<M,Rules>, що визначають правила (Rules) використання інших методологій M_i, назвемо багаторівневими методологіями або метаметодологіями.

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

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

Відповідно до MIXER-методології першого типу розрізняють такі основні етапи розробки:

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

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

- застосування до внутрішніх процесів розробки кожного з етапів вибраної методології, її методів і правил, забезпечуючи вимогу повноти інформації в репозиторії;

- здійснення переходів між етапами і підетапами тільки після аналізу поточного стану проекту з обов'язковим урахуванням «думки» системи про відповідність поточного положення цілям і задачам проекту.

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

Ситуація перша - всі критерії складності ранжируванні (багатокритеріальна задача вибору). Вибір будь-якої альтернативи призводить до однозначно відомих наслідків у вигляді чисельно заданого критерію q(x), а найкращою альтернативою x* є та, яка володіє найбільшим значенням критерію:

(3)

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

Задача (3) описуватиме вибір класу з найбільшим показником складності класу. У ролі функції векторного аргументу q(x) виступатиме функція СС, що залежить від адитивних часткових показників складності для i-го класу СС_i.

Якщо в системі метрик складності часткові показники можуть бути визначені у вигляді залежності, то узагальнений показник, що враховує нелінійний характер залежності часткових показників, матиме такий вигляд:

(4)



де M - загальна кількість метрик складності;

a_j - вагові коефіцієнти, що визначають значущість критерію складності, 0a_j1 і .

Коефіцієнти можуть бути визначені за допомогою експертних оцінок. Також вони можуть бути визначені в процесі оцінки системи менеджером проекту (за замовчанням всі критерії складності рівнозначні: a_j = 1/M); f(c_ij) - функція для i-го класу, що визначає залежність узагальненого показника від часткових показників складності с.

У цьому випадку для побудови залежності f(c_ij) доцільно використати одиничні функції:

(5)

де c_ij - значення j-го показника складності для i-го класу (системи метрик); - порогове значення j-го показника складності для i-го класу, що є обмеженням. При подібній структурі узагальненого показника (5) невиконання i-ої вимоги призводить до нульового внеску відповідного показника. Вибір щільно пов'язаний з вибором вагових коефіцієнтів a_j. Якщо необхідно виділити такі випадки, коли оцінка якого-небудь фактора є малозначущою і не являє собою значущості при загальній оцінці програмного забезпечення, то слід використовувати більш складну структуру узагальненого показника, який поєднує мультиплікативні та адитивні властивості:

(6)



де функція значущості оцінок визначена як:

(7)

де {k} - перелік виключених оцінок з послідовностей.

Модифікацією системи (6) можна називати показник складності, формування структури якого засновано на принципі порівняння з еталоном. Нехай є ідеальна система-прототип, для якої є основні показники CC_i (або бажані області їх змін). Тоді узагальнений показник складності реальної системи визначається як відстань між M-мірними точками, що визначаються відповідно множинами C={c_j}, для реальної системи та C₀={} для ідеальної системи:

(8)

де a₁…a_M - такі вагові коефіцієнти, що .

Параметрична чутливість узагальненого показника складності CC_i(c, c₀) до зміни будь-якого часткового показника c_iM може бути оцінена таким чином:

(9)

Якщо задано якесь значення S₀, то вибирається набір більш суттєвих часткових показників з умови для всіх c_iM.

Для порівняльної оцінки поточної, попередньої і «кращої» складностей програми вирішуємо пропорцію: CC_k-X_k%:CC₀-100%, де CC_k - значення узагальненого показника складності проекту, отриманого на k-ої ітерації; X_k% - значення узагальненого показника складності проекту, отриманого на k-ої ітерації, в процентах, причому значення X_k% повинно прагнути до 0; CC₀ - значення «найкращого» показника складності проекту (оцінка складності при першій ітерації приймається за 100% і вважається найкращою). Якщо CC_k<CC_0, то CC₀=CC_k, а менеджеру пропонується повернутися до попередньої ітерації.

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

(10)

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

Експериментально доведена ефективність алгоритму і точність оцінки складності об'єктно-орієнтованих класів та програмного забезпечення в загалом в порівнянні з існуючими методами оцінювання. Робота алгоритму була перевірена на системі «Банкомат», яка була розроблена за допомогою системи MIXER, при цьому проект порівнювався з існуючою системою, що розроблена Л. Розенбергом. Розроблена система показала найбільш комплексну і якісну оцінку проекту ніж методи, які були використані Л. Розенбергом для оцінки подібного проекту.

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

Архітектура MIXER-засобу заснована на архітектурі клієнт-сервер. Основними її частинами є: репозиторій проекту, інтелектуальне ядро і набір CASE-засобів. Репозиторій проекту розташовується на сервері даних, програмне забезпечення інтелектуального ядра - на сервері додатків, а CASE-засоби являють собою клієнтську частину. CASE-засоби звертаються за даними до репозиторію і поводяться відповідно до правил, визначених інтелектуальним ядром, отримуючи від нього постійну інтелектуальну підтримку.

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

Основні функції Менеджеру проекту:

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

- підлаштування характеристик і можливостей системи на основі даних від Системи Підтримки Прийняття Рішень (СППР);

- обміну даними з репозиторієм при використанні Інтерфейсу репозиторію (набір драйверів, форматів даних) і Імпорт/експорт інтерфейсу. Імпорт/експорт інтерфейс приймає і обробляє запити на введення/висновки інформації про будь-який проект в стандартних форматах даних і метафайлів;

- вирішення, наскільки здатна операція, що зажадалася, як вона вплине на подальший процес розвитку проекту;

- аналіз вхідних/вихідних даних і визначення додаткових змін стану проекту і станів CASE-засобів.

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

У додатках наведений комплекс екранних форм, що супроводжує процес функціонування системи MIXER, фрагмент проекту системи «Банкомат», а також акти про впровадження результатів дисертаційної роботи.



ВИСНОВКИ

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

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

Розроблено модель (2), що описує наскрізний уніфікований життєвий цикл, та модель проекту у теоретико-множинному вигляді (1), що описує частини проекту. Вони дозволяють представити задачу створення програмного забезпечення у формі агрегування-декомпозиції з послідовним аналізом і відбракуванням варіантів, що дозволяє якісно оцінити кожний варіант проекту за визначеними показниками.

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

Розроблено узагальнений показник складності проекту, що являє собою комплексну оцінку за кількома критеріями складності. Він дозволяє кількісно оцінити загальну складність як окремого класу (6), (10) та системи в загалом. Розглянуто дві ситуації: критерії, за якими проводиться оцінювання, мають ранг; відсутність додаткової інформації про критерії.

Розроблено алгоритм оцінки складності проекту, заснований на узагальненому показнику (6). У складі системи розроблена підсистема оцінки складності проекту. Алгоритм дозволяє оцінити складність кожного класу та системи загалом в порівнянні зі складністю системи на попередній ітерації. На основі експериментальних досліджень доведено доцільність використання розробленого алгоритму для оцінювання об'єктно-орієнтованих класів та системи в загалом.

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



СПИСОК ОПУБЛІКОВАНИХ АВТОРОМ ПРАЦЬ ЗА ТЕМОЮ ДИСЕРТАЦІЇ

Пономаренко О.С. Интеллектуальные CASE-средства нового поколения // Проблемы бионики. - Харьков: ХТУРЭ. - 1999. - №51.-С.141-145.

Пономаренко О.С. Интеллектуальная сквозная модель создания ПО // Новые решения в современных технологиях. - Харьков: ХГПУ. - 1999. - №44. - С.24-26.

Пономаренко О.С. Интеллектуальная сквозная модель создания ПО // Системный анализ, управление и информационные технологии: Вестник Харьковского государственного политехнического университета. Сб. науч. тр. - Харьков: ХГПУ. - 2000. - №97. - С.75-79.

Пономаренко О.С. Управление по сложности процессом создания программного обеспечения // Новые решения в современных технологиях. - Харьков: ХГПУ, Вып. 81. - 2000. - С.19-21.

Пономаренко О.С., Цымбал А.В. Система автоматизированной диагностики объектов различной природы на основе интеграции статистических методов // Тез. докл. конф. «Электроника и молодежь в 21 веке». - Харьков: ХТУРЭ. - 1997. - С.253.

Вязеленко С.В., Пономаренко О.С., Скрыпник И.В., Цымбал А.В. Информационная система медицинской диагностики, основанная на интеграции статистических методов // Информационные технологии: наука, техника, технология, образование, здоровье. - Харьков: ХГПУ. - 1997. - № 4. - С.322 -325.

Гребенюк В.А., Пономаренко О.С. Модель управления потоками информации на основе мультиагентных систем // Информационные технологии: наука, техника, технология, образование, здоровье. - Харьков: ХГПУ. - 1998. - №4. - С.419 - 422.

Размещено на Allbest.ru

...