Ім'я файлу: case-tehnologiya-rozroblennya-vimog-do-programnogo-zabezpechenny
Розширення: pdf
Розмір: 923кб.
Дата: 13.05.2022
скачати
Пов'язані файли:
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ.docx
Конфуцианство.doc
ZMIST2.docx
1111 Методологія та методи наукового дослідження.ppt
Кримінально- процесуальне право.docx
Історичне есе на тему Соціально-економічне та політичний розвито
Історична довідка про Тараса Шевченка.docx
службова Никифорову.docx
Zubchaste_koleso.docx

ДОДАТОКЕМіС2.docx
ФБ_КП_ЦарікС.О._(fixed) (1).doc
21.pdf
Хоменко Поради батькам при запинках в мовленні у дітей.docx
Реферат на тему_Українські та міжнародні організації зі стандарт
Реферат на тему_Українські та міжнародні організації зі стандарт
1 ENDOCRINE SYSTEM.docx
Задачи похідна.docx
цуацаца.rtf
gosudarstvennoe_i_municipalnoe_upravlenie-shpargal.pdf
текст доклада ъ.docx
Bedyukh_Yuliya_Oleksandrivna_Mm-21.docx.pdf
Типи календарів.docx
курсова психологія.doc
Реферат 2629.docx
пояснююча записка111.doc
Зміст практики.doc
Основи автоматики. Лекція 2.docx
Особливості організації інклюзивного навчання.docx
Практичне завдання_1.docx
Контрольні запитання ЛР № 8.docx
2 питання.rtf
Документ Microsoft Office Word.docx
kazedu_179257.docx
Рожков_Ниссенбаум_ТЧМК_лекции.doc
Курсова_робота_Пасевич_Аліна,_ЮД_046,_1_курс.docx
1 (1).docx
конспект заняття.docx
d71d73ee90c56_1797715607_1707122403.doc

Науковий вісник НЛТУ України. – 2010. − Вип. 20.2
5. Інформаційні технології галузі
277
териале. Проведенные экспериментальные исследования для определения скорости распространения акустической волны в древесине. На основе полученных результа- тов предложена методика выявления дефектов в древесине акустическим методом.
Ключевые слова: акустические измерения, древесина, неразрушающий кон- троль, звуковая карта, программное обеспечение.
Storozhuk O.L., Turash R.I., Kens I.R., Sokolowskyy Ya.I. Using of in-
formation technologies for wood defects detection by the acoustic method
The software is developed here for improvement and practical implementation of an acoustic method for detection of imperfections in timber. This will make it possible to defi- ne transit time of a test sonic signal in a stuff by direct measurement. The experimental re- search to define the velocity of sonic wave propagation in wood was conducted. Obtained results made it possible to propose the technique of wood defects detection by the acoustic method.
Keywords: acoustic measurement, wood, nondestructive control, a sound card, the software.
УДК 004.4
Викл. В.В. Яцишин – Тернопільський НТУ ім. Івана Пулюя;
доц. О.Г. Харченко, канд. техн. наук – Національний АУ, м. Київ
CASE-ТЕХНОЛОГІЯ РОЗРОБЛЕННЯ ВИМОГ ДО
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ТА ОЦІНЮВАННЯ
ЙОГО ЯКОСТІ
Наведено результати дослідження сучасних CASE-технологій, які використову- ють для підтримання процесів проектування на різних етапах життєвого циклу прог- рамного забезпечення (ПЗ). Внаслідок аналізу виявлено низку недоліків цих техно- логій та запропоновано власний CASE-засіб, який є web-орієнтованим і спрямований на підтримку технології, базованої на моделі якості стандарту ISO 9126. Показано, що використання цієї моделі, відповідної технології та засобу дає змогу адекватно відобразити потреби замовника та користувачів ПЗ на специфікації вимог, а також визначити міру їх задоволення. Пропонований CASE-засіб дає змогу автоматизувати процес розроблення вимог і керування ними, що значно підвищує якість процесу проектування і скорочує часові межі виконання проекту.
Вступ. Сучасний стан розвитку інформаційних систем (ІС) характери- зується постійним зростанням їхньої складності. Це потребує залучення знач- них ресурсів для забезпечення ефективності їх функціонування. Хоч на цей час розроблено цілу низку методів та методологій проектування ІС, як корпо- ративних, так і загального використання, але за їх застосування часто виника- ють проблеми, пов'язані з недостатньою формалізацією процесів проектуван- ня. А це своєю чергою перешкоджає впровадженню засобів автоматизації цих процесів.
Тому розроблення формалізованих процедур реалізації процесів про- ектування ПЗ є актуальною задачею інженерії програмного забезпечення.
Постановка задачі. Технологія створення ПЗ базується на процесах
ЖЦ [1], які за своєю природою є досить складними, трудомісткими і творчи- ми. У зв'язку з цим виникає потреба створення CASE-технологій, які б дава- ли змогу автоматизувати операції та стадії як основних, так і допоміжних процесів ЖЦ. Розроблення таких технологій є актуальною задачею, оскільки

Національний лісотехнічний університет України
Збірник науково-технічних праць
278
їх застосування підвищує ефективність процесу розроблення програмних продуктів приблизно у 6 разів [2].
Аналіз процесів ЖЦ розроблення ПЗ показав, що найменш формалізо- ваними і тому найбільш трудомісткими є процеси на етапі аналізу вимог та оцінювання якості [3, 4]. Це пояснюється складністю використання формаль- них методів для відображення потреб замовника на специфікації системних вимог, що породжується відсутністю єдиного уніфікованого їх подання [5].
Чинний стандарт IEEE830 дає достатньо довільні трактування структури та форми представлення вимог, що відображається у неоднозначності та неузго- дженості у сформульованих вимогах. Звідси випливає, що для створення ефективних CASE-засобів автоматизації процесів розроблення специфікацій вимог, їх контролю та управління необхідно розробити стандартизовані уні- фіковані моделі їх представлення і процедури їх побудови. Оскільки моделі вимог якості, які базуються на уніфікованих компонентах і містять критерії оцінювання, є основою для процедур оцінювання якості, то вони також мо- жуть бути базою для створення CASE-засобів оцінювання якості ПЗ.
Огляд існуючих відомостей. Виконаємо аналіз технологій розроб- лення ПЗ та CASE-засобів, які їх підтримують на етапах ЖЦ. При цьому ос- новну увагу зосередимо на етапі розроблення вимог та оцінювання якості. На практиці використовують низку технологій розроблення ПЗ. Найширше ви- користовуваними є такі:
● Microsoft Solutions Framework (MSF).
● Custom Development Method Oracle (CDMO).
● Rational Unified Process (RUP).
Ці технології базуються на двох основних підходах: структурному та об'єктно-орієнтованому. Технологія MSF є платформно-незалежною, яка орі-
єнтована на розроблення ПЗ і розвиток інформаційної інфраструктури [6]. За- соби цієї технології підтримують розподілені обчислення та застосування технології "клієнт-серевер".
Під час проектування вимог до ПС MSF використовує метод шаблонів та UML діаграм. Засобами графічного моделювання та документування ви- мог ПЗ є Microsoft Visio та пакет Microsoft Office. Microsoft Visio підтримує генерацію UML-діаграм, зокрема Use case діаграм. Для управління проектом та контролю загального процесу створення ПЗ використовують засіб Micro- soft Project.
Технологія RUP базується на принципах об'єктно-орієнтованого під- ходу створення ПС та мови графічного моделювання UML. Підтримку цієї технології забезпечують засоби фірми IBM групи Rational. Для розроблення вимог за об'єктно-орієнтованим підходом використовують діаграми класів та
Use case діаграми, що відображають функціональність майбутньої ПС.
Засобом, що підтримує моделювання діаграм цього типу є Rational
Rose. Інший засіб керування вимогами та їх документування – середовище
Rational Requsite Pro. Основне призначення цього засобу полягає у наданні можливості відслідковування та зручного внесення змін у вимоги. При цьому вимоги представляють у текстовому вигляді з відображенням діаграм, змо- дельованих в Rational Rose.

Науковий вісник НЛТУ України. – 2010. − Вип. 20.2
5. Інформаційні технології галузі
279
Об'єктно-орієнтовний підхід розроблення вимог втілений також в ав- томатизованому засобі DOORS компанією Telelogic. Принцип проектування вимог відображає структуру шаблону, що рекомендований у стандарті [3]. В основі технологіїCDMO, згідно з [6], лежить метод ORACLE CASE* MET-
HOD, який базується на визначенні об'єктів (сутностей) та зв'язків між ними, що фактично є структурним підходом. Технологія CDM підтримується ін- струментальними засобами компанії Oracle і використовується під час ство- рення автоматизованих інформаційних систем на основі реляційних баз да- них. Для розроблення та керування вимогами використовується засіб автома- тизації Oracle Designer. Цей засіб дає змогу моделювати діаграми "сутність- зв'язок". З його допомогою можна лише визначати основні сутності всереди- ні системи та зв'язки між ними, але неможливо описати систему загалом та процеси, які в ній відбуваються. В Oracle Designer відсутня можливість пред- ставлення вимог якості та обмежень, що істотно звужує область його застосу- вання. Засобами автоматизації, які підтримують принципи структурного під- ходу щодо проектування ПС, є також програмні продукти ARIS Toolset, ER- win Datamodeler, Process Modeler (BPwin).
Виходячи з результатів проведеного аналізу можна стверджувати, що тільки технології MSF та DOORS мають засоби формалізованого представ- лення вимог якості, які використовують метод шаблонів. Однак структура і класифікація рубрик шаблонів не уніфіковані, тому у разі їх використання можуть виникати неоднозначності трактувань, що істотно звужує область за- стосування цих CASE-технологій.
Для перевірки відповідності готового програмного продукту заявле- ним у специфікації вимогам фірми-розробники використовують автоматизо- вані засоби тестування. Засоби, які б здійснювали автоматизацію технологіч- них операцій в процесі оцінювання якості ПЗ відсутні.
У роботах [5,7] містяться основні положення та обґрунтування техно- логії побудови специфікацій вимог та оцінювання якості ПЗ, яка базується на використанні концепції моделі якості ISO 9126 [4]. Ця технологія забезпечує формалізацію процесів відображення потреб замовника на специфікації ви- мог в уніфікованому, стандартизованому вигляді і використання побудова- них специфікацій при оцінюванні якості. У цій роботі розроблено CASE-за- сіб, який автоматизує процеси цієї технології.
Основна частина. Стандартом [8] визначено три типи вимог щодо яко- сті ПЗ, а саме вимоги у використанні, внутрішньої та зовнішньої. Процес почи- нається з побудови вимог щодо якості у використанні. Для цього фіксуються потреби користувача бізнес-системи, для якої замовляється WEB-продукт.
{
}
,
,
1, ,
1,
i
ік
і
П
P С
і
N
K
M
=
=
=
, (1) де:
і
Р
і-та потреба користувача;
ік
С
– обмеження на і-ту потребу;
N
– кіль- кість потреб замовника;
K
– кількість обмежень на потреби.
Виходячи з бізнес-вимог та вимог предметної області, для кожної пот- реби
і
Р
задається множина атрибутів
{ }
iK
A
,
1,
i
K
S
=
, які відображають сту- пінь задоволення і-тої потреби. В результаті отримуємо сукупність

Національний лісотехнічний університет України
Збірник науково-технічних праць
280
{
}
,
,
,
1, ,
1,
i
iK
іK
i
P A
С
і
N K
S
=
=
, (2) де:
і
Р
і-та потреба користувача;
iK
A
і-ий атрибут, що відображає і-ту пот- ребу замовника та
K
-те обмеження на потребу;
iK
C
– обмеження на атрибут;
Сукупність
{
}
,
,
,
1, ,
1,
i
iK
іK
i
P A
С
і
N K
S
=
=
представляє вимоги до WEB- продукту користувача бізнес-системи.
Для запису цих вимог в стандартизованому вигляді відобразимо (2) на елементи структури моделі якості у використанні [9].
{
}
,
,
1,4,
1,
u
u
i
ij
i
H M
i
j
R
=
=
(3) де:
u
i
H
і-та характеристика моделі якості;
u
ij
M
– метрика і-ої характеристи- ки;
i
R
– кількість метрик.
У підсумку отримуємо модель вимог щодо якості користувача бізнес- системи, сформульовані у стандартизованих термінах.
{
}
,
,
,
,
,
1,
u
u
u
u
k
use
i
u
i
ik
ik
ik
V
H A C M
i N K
S
=

=
, (4) де:
use
V
– вимоги у вигляді моделі якості у використанні;
u
i
H
і-та характе- ристика моделі якості,
u
ik
A
і-й атрибут, що відображає і-ту потребу замовни- ка та
K
-те обмеження на потребу;
C
u
ik
– обмеження на атрибут;
u
ik
M
– метри- ка моделі якості;
Наступним етапом під час проектування є розроблення специфікацій системних вимог до програмного комплексу. Для цього відобразимо елемен- ти сукупності (4) на елементи структури зовнішньої якості.
{
}
,
,
,
1,6,
1,
x
x
x
i
ij
ij
i
H П M
i
j
K
=
=
, (5) де:
x
i
H
– характеристики;
x
ij
П
– підхарактеристики зовнішньої якості;
x
ij
M
– відповідні метрики;
i
K
– кількість підхарактеристик і-ої характеристики.
У підсумку отримаємо специфікації вимог якості в стандартизованих термінах.
{
}
,
,
,
,
,
,
1,
x
x
x
x
x
x
out
i
x
i
iK
iK
iK
iK
V
H П
A С
M
i N K
R
=

=
(6) де:
out
V
– вимоги щодо зовнішньої якості;
x
i
H
– характеристики зовнішньої моделі якості;
x
iK
П
– підхарактеристики характеристик зовнішньої моделі якості;
x
iK
A
– атрибути підхарактеристик зовнішньої якості;
x
iK
С
обмеження на атрибути;
x
iK
M
– метрики атрибутів зовнішньої моделі якості;
x
N
– кіль- кість характеристик зовнішньої моделі якості;
K
– кількість атрибутів;
x
i
R
– кількість метрик зовнішньої моделі якості.
Для формування специфікацій вимог
in
V
до модулів програмного ком- плексу WEB-застосування виконується відображення вимог (6) на елементи структури моделі внутрішньої якості. Це відображення виконується для кож- ного модуля з врахуванням його функціональності.
Для побудови відображень (4), (6) використовується процедура класи- фікації, в якій використано алгоритм пошуку асоціацій на ієрархічній струк-

Науковий вісник НЛТУ України. – 2010. − Вип. 20.2
5. Інформаційні технології галузі
281
турі, якою видається модель якості [10]. При цьому, для кожного структурно- го елемента множини вхідних вимог здійснюється пошук найбільш залежних структурних елементів вихідних вимог. Процедура (7) ітераційна, реалі- зується скануванням за структурою "згори-вниз", а потім "знизу-вгору". За- лежності визначаються експертом в режимі діалогу.
{
}
1 2
,
n
H
H H H
=


{
}
1 11 12 1
,
,...,
k
П
П П
П
=
{
}
1 2
,
,...,
n
n
n
nk
П
П П
П
=




{
}
1 11 12 1
,
,...,
k
A
A A
A
=
{
}
1 2
,
,...,
n
n
n
ns
A
A A
A
=
(7)






{
}
11 12 1
,
,...,
k
M M
M
………….
{
}
1 2
,
,...,
n
n
ns
M M
M
Вершиною ієрархії є
1
,...,
n
H
H
– стандартизовані характеристики, на нижчому рівні показано
{ }
ij
П
– множини підхарактеристик,
{ }
im
A
– множина атрибутів підхарактеристик, які вибрані з урахуванням специфіки предметної області,
{
}
im
M
– відповідні метрики, які можуть вибиратися із стандартизова- ного переліку. Для реалізації цієї процедури створено репозиторії метрик, ат- рибутів, характеристик і підхарактеристик.
Проаналізувавши принципи побудови моделей якості і дані, які бу- дуть зберігатись в репозиторії, розроблено функціональну схему CASE-засо- бу, яку наведено на рис. 1.
Вхідними даними для розробки вимог до ПЗ, згідно з рис. 1, є потреби замовника, які представляють у деякому формалізованому текстовому вигля- ді. Їх можна визначати на основі Use case діаграм, згенерованих і формально специфікованих за допомогою інших автоматизованих систем. Записавши потреби замовника, виконуємо їх аналіз та класифікацію за стандартизовани- ми характеристиками
1
,...,
n
H
H
, підхарактеристиками
{ }
ij
П
моделі якості [9].
Крім того, у CASE-засобі забезпечено вибір метрик
jm
M
з відповідного репо- зиторію (БД стандартизованих метрик). Після цього формуються відповідні записи множини вимог
use
V
,
out
V
,
in
V
у репозиторій проекту (БД вимог у виг- ляді моделі якості ISO 9126). Керування та зміна потреб і вимог відслідко- вується через модуль керування вимогами. Для зручності заповнення репози- торіїв спроектовано відповідні системи керування, зокрема для заповнення бази даних стандартизованих метрик. Після того як вимоги до ПЗ узгодженні зі всіма зацікавленими в проекті сторонами, формуються специфікації вимог, які використовують на наступних стадіях життєвого циклу.
Оцінювання якості готового програмного продукту відбувається шля- хом використання тих же репозиторіїв, але з урахуванням особливостей цьо- го процесу. Зокрема, для кількісного відображення міри якості програмного продукту потрібно обчислити інтегральний показник якості. У роботі [11] на- ведено методи обчислень локальних, частинних та глобального показників якості ПЗ. Враховуючи аспекти технології оцінювання якості, у CASE-засобі

Національний лісотехнічний університет України
Збірник науково-технічних праць
282
розроблено відповідну підсистему для визначення міри задоволення вимог, функціональну схему якої наведено на рис. 2.
Рис. 1. Функціональна схема CASE-засобу розроблення вимог
Рис. 2. Функціональна схема підсистеми оцінювання CASE-засобу

Науковий вісник НЛТУ України. – 2010. − Вип. 20.2
5. Інформаційні технології галузі
283
Із схеми, наведеної на рис. 2, видно, що процес оцінювання якості ПЗ починається із звернення до репозиторію вимог, які сформульовано у вигляді характеристик, підхарактеристик, атрибутів та метрик моделей якості. Для кожного атрибута якості ставимо у відповідність пряму або непряму метрику
і задаємо елементарну функцію для його оцінювання. Для визначення ваги і впливу кожного атрибута запропоновано використати матриці попарних по- рівнянь, які дає змогу генерувати CASE-засіб. Побудовані шаблони матриць попарних порівнянь оцінюють експерти. Відношення впливу між атрибутами опрацьовують методами статистичного оброблення. В результаті отримаємо вагові коефіцієнти кожного атрибута. Аналогічно до атрибутів будують мат- риці попарних порівнянь для підхарактеристик та характеристик, що дає змо- гу визначити кількісні часткові показники якості за відповідними характерис- тиками та підхарактеристиками моделей якості. Усі вагові множники, визна- чені експертами, записують у репозиторій вагових множників, а результати оцінювання всіх рівнів моделі якості – у репозиторій кількісного оцінювання якості. На основі даних, які відображають кількісну міру якості, формують специфікацію процесу оцінювання та розробляють рекомендації щодо покра- щення якості програмного продукту.
Розроблений CASE-засіб є web-орієнтованим і його можна використо- вувати як web-сервіс для підтримки процесів розробки вимог і оцінювання якості ПС. У ньому забезпечено можливість віддаленого формування потреб замовника, специфікації вимог до ПЗ і визначення ступеня задоволення та відповідності вимог і потреб.
Структурно CASE-засіб складається з двох частин: клієнтської і сер- верної. Клієнтська частина надає замовнику можливість задання потреб у ви- гляді шаблону моделей якості. Шаблон становить набір стандартизованих ха- рактеристик, підхарактеристик, атрибутів та метрик. Замовник має змогу ви- бирати властивості, які необхідно реалізувати, базуючись на цьому шаблоні
(рис. 3).
Рис. 3. Шаблон формування потреб замовника
У CASE-засобі реалізовано також можливість формування потреб за- мовника у формальному текстовому вигляді. Процедура адаптації потреб, за-

Національний лісотехнічний університет України
Збірник науково-технічних праць
284
даних таким чином, виконується на сервері шляхом їх класифікації за відпо- відними атрибутами, підхарактеристиками і характеристиками.
Серверна частина реалізує функції менеджера роботи з репозиторіями ви- мог, потреб, вагових множників. На рис. 4 зображено інтерфейс серверної частини.
Рис. 4. Серверна частина CASE-засобу
На рис. 4 показано наповнення репозиторію стандартизованих метрик для оцінювання якості ПЗ. Крім того, адміністратор CASE-засобу має можли- вість контролю, керування та наповнення усіх репозиторіїв відповідними да- ними. У серверній частині забезпечено можливість розподілу прав доступу, налаштування зовнішнього інтерфейсу, спроектовано систему допомоги з ко- ристування CASE-засобом.
Під час розроблення засобу автоматизації, орієнтованого на підтримку етапу аналізу вимог та оцінювання якості використано відкриті компоненти та засоби розробки. Зокрема, клієнтську частину реалізовано за допомогою ком- понентів JavaScript (Ext JS). Серверну частину розроблено за допомогою PHP
5.1 (Zend Framework) та MySQL 4.4 (InnoDB). Web-сервіс можна використову- вати за адресою в мережі Internet http://specbuilder.crowdin.net/createspec
Висновки. Внаслідок застосування запропонованого CASE-засобу ре- алізовано автоматизацію процесу розроблення та аналізу вимог, а також оці- нювання якості ПЗ. Цей засіб є спеціалізованим і втілює основні принципи технології, базованої на рекомендаціях стандарту ISO 9126 1-4. Система дає змогу автоматизувати процес аналізу вимог, шляхом побудови розробленого в роботі шаблону для формування потреб. Наявність такого шаблону дає змо- гу однозначно та повною мірою враховувати побажання кінцевих користува- чів, цілі замовника бізнес-системи і відповідність стандартам. На етапі роз- роблення вимог до ПЗ автоматизовано процеси: розроблення потреб замов- ника і формування відповідної специфікації, перетворення потреб у вимоги до ПЗ, генерування специфікації вимог. На етапі оцінювання якості ПЗ авто- матизовано функції роботи з репозиторіями характеристик, підхарактеристик
і метрик, процес визначення вагових множників і обчислення інтегрального показника якості.

Науковий вісник НЛТУ України. – 2010. − Вип. 20.2
5. Інформаційні технології галузі
285
Література
1. ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes.
2. Вендров А.М. CASE-технологии: Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Изд-во "Финансы и статистика", 1998. – 176 с.
3. IEEE Std 830-1993, IEEE Recommended Practice for Software Requirements Specifica- tions (ANSI).
4. Брауде Е.Технология разработки программного обеспечения / Е. Брауде. – СПб. :
Изд-во "Питер", 2004. – 655 с.
5. Харченко О. Розроблення та керування вимогами до програмного забезпечення на основі моделі якості / О. Харченко, В. Яцишин // Вісник ТДТУ. – 2009. – Том 14, № 1. – С.
201-207.
6. Авраменко Е.А. Метод и средства редокументирования наследуемого программного обеспечения : дис… канд. техн. наук: спец. 01.05.03 / Национальный авиационный ун-т. – К.,
2008. – 144 с.
7. Райчев І.Е. Принципи побудови моделі якості у використанні програмних систем /
І.Е. Райчев, О.Г. Харченко // Збірник наукових праць інституту проблем моделювання в енер- гетиці. – 2007. – Вип. 39. – С. 31-38.
8. ISO/IEC 25030 Software engineering-Software product Quality Requirement and Evalua- tion (SQuaRE), Quality Requirements, 2007.
9. ISO/IEC 9126 (1-4). Software engineering – Product quality – Part 1: Quality model, Part
2: External metrics, Part 3: Internal metrics, Part 4: Quality in use metrics, 2001–2004.
10. Барсегян А.А. Технологии анализа данных / А.А. Барсегян, М.С. Куприянов,
В.В. Степаненко, И.И. Холод. – СПб. : Изд-во " БХВ-Петербург", 2008. – 384 c.
11. Яцишин В.В. Аналіз технологій розробки та управління вимогами до програмного забезпечення / В.В. Яцишин // Інженерія програмного забезпечення 2007 : матер. Всеукраїн- ської конф. аспір. і студентів. – К. : Изд-во НАУ. – С. 81-85.
Яцишин В.В., Харченко О.Г. CASE-технология разработки требо-
ваний к программному обеспечению и оцениванию его качества
Приведены результаты исследования современных CASE-технологий, которые используют для поддержки процессов проектирование на разных этапах жизненного цикла программного обеспечения (ПО). В результате анализа обнаружен ряд недос- татков этих технологий и предложена собственная CASE-технология, которая явля- ется web-ориентированной и направленной в поддержку технологии, базированной на модели качества стандарта ISO 9126. Показано, что использование этой модели, соответствующей технологии и средства дает возможность адекватно отобразить по- требности заказчика и пользователей ПО на спецификации требований, а также оп- ределить степень их удовлетворения. Предлагаемая CASE-технология дает возмож- ность автоматизировать процесс разработки требований и управления ими, что зна- чительно повышает качество процесса проектирования и сокращает временные рам- ки выполнения проекта.
Yatsyshyn V.V., Harchenko O.G. CASE technology of the requirements
development and quality evaluation of software
The article describes the results of the modern CASE technologies researchments that are used for supporting the process at different stages of the life cyrcle of the software.
Some disadvantages of these technologies were discovered and an own CASE method was proposed, oriented on the technology supportment, based on the usage of the quality model
(standart ISO 9126-1). The article states that the usage of this technology gives us oppor- tunity to show adequately the needs of the supplier and of the users of software on the req- uirements specification and also define the measure of these requirements satisfaction. This
CASE method is web-oriented, it lets us to automates the process of the development and the requirements of quality management, that rises its quality and makes the process of de- sign faster.

скачати

© Усі права захищені
написати до нас