CC BY
185
териале. Проведенные экспериментальные исследования для определения скорости распространения акустической волны в древесине. На основе полученных результатов предложена методика выявления дефектов в древесине акустическим методом.
Ключевые слова: акустические измерения, древесина, неразрушающий контроль, звуковая карта, программное обеспечение.
Storozhuk O.L., \Turash R.I\ Kens I.R., Sokolowskyy Ya.I. Using of information 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 define transit time of a test sonic signal in a stuff by direct measurement. The experimental research 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 Викл. В.В. Яцишин - Терноптьський НТУ iM. 1вана Пулюя;
доц. О.Г. Харченко, канд. техн. наук - Нащональний АУ, м. Кит
CASE-технолопя розроблення вимог до програмного забезпечення та оц1нювання
його якост1
Наведено результати дослщження сучасних CASE-технолоriй, як використову-ють для тдтримання процеав проектування на рiзних етапах життевого циклу прог-рамного забезпечення (ПЗ). Внаслщок аналiзу виявлено низку недолшв цих технологий та запропоновано власний CASE-зааб, який е web-орiентованим i спрямований на тдтримку технологи, базовано'1 на моделi якосп стандарту ISO 9126. Показано, що використання ще! модел^ вщповщно! технологи та засобу дае змогу адекватно вщобразити потреби замовника та користувачiв ПЗ на специфшаци вимог, а також визначити мiру ix задоволення. Пропонований CASE-зааб дае змогу автоматизувати процес розроблення вимог i керування ними, що значно тдвищуе якють процесу проектування i скорочуе часовi меж виконання проекту.
Вступ. Сучасний стан розвитку шформацшних систем (1С) характеризуемся постшним зростанням 1хньо! складность Це потребуе залучення знач-них ресурЫв для забезпечення ефективност ix функцюнування. Хоч на цей час розроблено цшу низку метод1в та методологш проектування 1С, як корпо-ративних, так i загального використання, але за ix застосування часто виника-ють проблеми, пов'язаш з недостатньою формал1защею процеЫв проектування. А це своею чергою перешкоджае впровадженню засоб1в автоматизацп цих процеЫв.
Тому розроблення формал1зованих процедур реал1зац11 процеЫв проектування ПЗ е актуальною задачею шженерп програмного забезпечення.
Постановка задачь Технолопя створення ПЗ базуеться на процесах ЖЦ [1], як за своею природою е досить складними, трудомюткими i творчи-ми. У зв'язку з цим виникае потреба створення CASE-технологш, як б давали змогу автоматизувати операцп та стадп як основних, так i допомiжниx процесiв ЖЦ. Розроблення таких технологш е актуальною задачею, оскшьки
ix застосування шдвищуе ефективнiсть процесу розроблення програмних продукпв приблизно у 6 разiв [2].
Аналiз процесiв ЖЦ розроблення ПЗ показав, що найменш формалiзо-ваними i тому найбшьш трудомiсткими е процеси на етат аналiзу вимог та оцiнювання якост [3, 4]. Це пояснюеться складшстю використання формаль-них методiв для вщображення потреб замовника на специфжаци системних вимог, що породжуеться вщсутшстю единого унiфiкованого ix подання [5]. Чинний стандарт IEEE830 дае достатньо довшьш трактування структури та форми представлення вимог, що вщображаеться у неоднозначност та неузго-дженостi у сформульованих вимогах. Звщси випливае, що для створення ефективних CASE-засобiв автоматизацн процесiв розроблення специфiкацiй вимог, ix контролю та управлiння необxiдно розробити стандартизованi уш-фiкованi моделi ix представлення i процедури ix побудови. Оскiльки моделi вимог якостi, як базуються на унiфiкованиx компонентах i мiстять критери оцiнювання, е основою для процедур ощнювання якостi, то вони також мо-жуть бути базою для створення CASE-засобiв ощнювання якост ПЗ.
Огляд iснуючих ведомостей. Виконаемо аналiз теxнологiй розроблення ПЗ та CASE-засобiв, якi ix тдтримують на етапах ЖЦ. При цьому ос-новну увагу зосередимо на етат розроблення вимог та ощнювання якость На практицi використовують низку теxнологiй розроблення ПЗ. Найширше ви-користовуваними е такi:
• Microsoft Solutions Framework (MSF).
• Custom Development Method Oracle (CDMO).
• Rational Unified Process (RUP).
Щ технологи базуються на двох основних тдходах: структурному та об,ектно-орiентованому. Теxнологiя MSF е платформно-незалежною, яка орь ентована на розроблення ПЗ i розвиток iнформацiйноi iнфраструктури [6]. За-соби цiеi технологи тдтримують розподшет обчислення та застосування технологи "кшент-серевер".
Пiд час проектування вимог до ПС MSF використовуе метод шаблотв та UML дiаграм. Засобами графiчного моделювання та документування вимог ПЗ е Microsoft Visio та пакет Microsoft Office. Microsoft Visio шдтримуе генеращю UML-дiаграм, зокрема Use case дiаграм. Для управлшня проектом та контролю загального процесу створення ПЗ використовують зашб Microsoft Project.
Теxнологiя RUP базуеться на принципах об,ектно-орiентованого тд-ходу створення ПС та мови графiчного моделювання UML. Пiдтримку цiеi технологи забезпечують засоби фiрми IBM групи Rational. Для розроблення вимог за об,ектно-орiентованим тдходом використовують дiаграми клашв та Use case дiаграми, що вщображають функцiональнiсть майбутньоi ПС.
Засобом, що шдтримуе моделювання дiаграм цього типу е Rational Rose. 1нший зашб керування вимогами та ix документування - середовище Rational Requsite Pro. Основне призначення цього засобу полягае у наданш можливост вщслщковування та зручного внесення змiн у вимоги. При цьому вимоги представляють у текстовому виглядi з вщображенням дiаграм, змо-дельованих в Rational Rose.
Об,ектно-орiентовний шдхщ розроблення вимог втiлений також в ав-томатизованому засобi DOORS компашею Telelogic. Принцип проектування вимог вщображае структуру шаблону, що рекомендований у стандарт [3]. В основi технологiïCDMO, згiдно з [6], лежить метод ORACLE CASE* METHOD, який базуеться на визначенш об'ек^в (сутностей) та зв'язюв мiж ними, що фактично е структурним пiдходом. Технолопя CDM пiдтримуеться ш-струментальними засобами компани Oracle i використовуеться шд час ство-рення автоматизованих шформацшних систем на основi реляцiйних баз да-них. Для розроблення та керування вимогами використовуеться зашб автома-тизацiï Oracle Designer. Цей заЫб дае змогу моделювати дiаграми "сутшсть-зв'язок". З його допомогою можна лише визначати основш сутностi всереди-нi системи та зв'язки мiж ними, але неможливо описати систему загалом та процеси, якi в нш вiдбуваються. В Oracle Designer вщсутня можливiсть пред-ставлення вимог якост та обмежень, що ютотно звужуе область його застосу-вання. Засобами автоматизации якi пiдтримують принципи структурного тд-ходу щодо проектування ПС, е також програмш продукти ARIS Toolset, ERwin Datamodeler, Process Modeler (BPwin).
Виходячи з результатiв проведеного аналiзу можна стверджувати, що тшьки технологiï MSF та DOORS мають засоби формалiзованого представ-лення вимог якостi, якi використовують метод шаблонiв. Однак структура i класифжащя рубрик шаблонiв не утфшоваш, тому у разi ïx використання можуть виникати неоднозначносп трактувань, що ютотно звужуе область за-стосування цих CASE-технологш.
Для перевiрки вщповщносл готового програмного продукту заявле-ним у специфжаци вимогам фiрми-розробники використовують автоматизо-ванi засоби тестування. Засоби, як б здiйснювали автоматизацiю технолопч-них операцiй в процесi ощнювання якостi ПЗ вiдсутнi.
У роботах [5,7] мютяться основнi положення та обгрунтування техно-логiï побудови специфжацш вимог та оцiнювання якостi ПЗ, яка базуеться на використанш концепци моделi якостi ISO 9126 [4]. Ця технолопя забезпечуе формалiзацiю процешв вiдображення потреб замовника на специфжаци вимог в унiфiкованому, стандартизованому виглядi i використання побудова-них специфшацш при оцiнюваннi якостi. У цш роботi розроблено CASE-за-Ыб, який автоматизуе процеси цiеï технологи.
Основна частина. Стандартом [8] визначено три типи вимог щодо яко-cri ПЗ, а саме вимоги у використанш, внутрiшньоï та зовшшньоь Процес почи-наеться з побудови вимог щодо якост у використанш. Для цього фшсуються потреби користувача бiзнеc-cиcтеми, для яко1' замовляеться WEB-продукт.
П = {P, CiK}, i = Щ K = \Mi, (1)
де: Pi - i-та потреба користувача; CiK - обмеження на i-ту потребу; N - кшь-кicть потреб замовника; K - кшьюсть обмежень на потреби.
Виходячи з бiзнеc-вимог та вимог предметно1' облаcтi, для кожно1' потреби Pi задаеться множина атрибу^в {AiK}, K = 1, St, якi вiдображають сту-пiнь задоволення i-тоï потреби. В результат отримуемо cукупнicть
{Р, Ак, Ск}, I = Т N К = Т$, (2)
де: Р - /-та потреба користувача; Ак - /-ий атрибут, що вщображае /-ту потребу замовника та К -те обмеження на потребу; СК - обмеження на атрибут; Сукупшсть {Р, АК, СК}, I = 1, N К = 1,$ представляе вимоги до WEB-
продукту користувача бiзнес-системи.
Для запису цих вимог в стандартизованому виглядi вщобразимо (2) на елементи структури моделi якостi у використаннi [9].
{ни, ми}, / =ТА ]=ТЯ (3)
де: ни - /-та характеристика моделi якостi; М% - метрика /-о! характеристики; Я - кшьюсть метрик.
У пiдсумку отримуемо модель вимог щодо якостi користувача бiзнес-системи, сформульованi у стандартизованих термшах.
У^е = {ни, Аи, а, м?к}, / 6 Ыки, К = , (4)
де: Уше - вимоги у виглядi моделi якостi у використaннi; ни - /-та характеристика моделi якост^ А/к - 1-й атрибут, що вщображае /-ту потребу замовника та К -те обмеження на потребу; Скк - обмеження на атрибут; Мкк - метрика моделi якостц
Наступним етапом тд час проектування е розроблення специфшацш системних вимог до програмного комплексу. Для цього вщобразимо елементи сукупност (4) на елементи структури зовшшньо! якость
{н*, П*, М*}, / = ТА ] = 1К/, (5)
де: нх - характеристики; П* - шдхарактеристики зовшшньо1 якостi; М* -вщповщш метрики; К - кшьюсть шдхарактеристик ьо1 характеристики.
У шдсумку отримаемо специфжацп вимог якост в стандартизованих термiнaх.
Уош = {н х, ПК, АК, с К, М К}, /6 Мх, К = ТЯ (6)
де: Уоиг - вимоги щодо зовшшньо! якостi; н* - характеристики зовшшньо! моделi якостi; ПК - шдхарактеристики характеристик зовшшньо! моделi якостi; АК - атрибути шдхарактеристик зовшшньо! якостi; С/К - обмеження на атрибути; М К - метрики атрибу^в зовшшньо! моделi якостi; Ых - юль-кiсть характеристик зовшшньо! моделi якостi; К - кшьюсть атрибу^в; Я* -кiлькiсть метрик зовшшньо! моделi якостi.
Для формування специфшацш вимог Уп до модулiв програмного комплексу WEB-зaстосувaння виконуеться вщображення вимог (6) на елементи структури моделi внутршньо1 якостi. Це вщображення виконуеться для кожного модуля з врахуванням його функщональность
Для побудови вщображень (4), (6) використовуеться процедура класи-фжацп, в яюй використано алгоритм пошуку асощацш на iерaрхiчнiй струк-
тур^ якою видаеться модель якоcтi [10]. При цьому, для кожного структурного елемента множини вхщних вимог здшснюеться пошук найбiльш залежних структурних елеменпв виxiдниx вимог. Процедура (7) ггерацшна, реаль зуеться скануванням за структурою "згори-вниз", а потiм "знизу-вгору ". За-лежноcтi визначаються експертом в режимi дiалогу.
H ={Яl, H 2.. .H n}
I I
П1 ={ П11, П12,..., П1к} Пп ={ Пп1, Пп2,..., Ппк}
II II
A = { A11, A12,..., A1k} An = { An1, An2,..., Ans} (7)
{M11, M12,..., M1k } ............. {Mn1, Mn2,..., Mns}
Вершиною iерарxiï е H1,...,Hn - стандартизован характеристики, на нижчому рiвнi показано {Пij} - множини шдхарактеристик, {Aim} - множина
атрибу^в пiдxарактериcтик, якi вибранi з урахуванням специфжи предметно1' облаcтi, {Mim} - вiдповiднi метрики, якi можуть вибиратися iз стандартизова-ного перелжу. Для реалiзацiï цiеï процедури створено репозитори метрик, ат-рибутiв, характеристик i пiдxарактериcтик.
Проаналiзувавши принципи побудови моделей якост i данi, як бу-дуть зберiгатиcь в репозитори, розроблено функцюнальну схему CASE-засо-бу, яку наведено на рис. 1.
Вхщними даними для розробки вимог до ПЗ, зпдно з рис. 1, е потреби замовника, як представляють у деякому формалiзованому текстовому вигля-да. ïx можна визначати на оcновi Use case дiаграм, згенерованих i формально cпецифiкованиx за допомогою шших автоматизованих систем. Записавши потреби замовника, виконуемо ïx аналiз та класифжащю за стандартизовани-ми характеристиками H1,...,Hn, шдхарактеристиками {niJ} моделi якоcтi [9].
К^м того, у CASE-заcобi забезпечено вибiр метрик Mjm з вщповщного репо-зиторiю (БД стандартизованих метрик). Шсля цього формуються вiдповiднi записи множини вимог Vuse, Vout, Vin у репозиторiй проекту (БД вимог у виг-лядi моделi якоcтi ISO 9126). Керування та змша потреб i вимог вщслщко-вуеться через модуль керування вимогами. Для зручносп заповнення репози-торiïв спроектовано вiдповiднi системи керування, зокрема для заповнення бази даних стандартизованих метрик. Шсля того як вимоги до ПЗ узгодженш зi вЫма защкавленими в проектi сторонами, формуються специфжаци вимог, якi використовують на наступних cтадiяx життевого циклу.
Оцшювання якоcтi готового програмного продукту вщбуваеться шляхом використання тих же репозиторив, але з урахуванням особливостей цього процесу. Зокрема, для кшьюсного вщображення мiри якосп програмного продукту потрiбно обчислити штегральний показник якоcтi. У роботi [11] наведено методи обчислень локальних, частинних та глобального показниюв якосп ПЗ. Враховуючи аспекти теxнологiï оцшювання якосп, у CASE-заcобi
розроблено вщповщну пiдсистему для визначення мiри задоволення вимог, функщональну схему яко! наведено на рис. 2.
Рис. 1. Функщональна схема СА8Е-засобу розроблення вимог
Рис. 2. Функщональна схема мдсистеми ощнювання СА8Е-засобу
1з схеми, наведено! на рис. 2, видно, що процес оцшювання якостi ПЗ починаеться iз звернення до репозиторш вимог, якi сформульовано у виглядi характеристик, пiдхарактеристик, атрибутiв та метрик моделей якость Для кожного атрибута якост ставимо у вiдповiднiсть пряму або непряму метрику i задаемо елементарну функцiю для його оцшювання. Для визначення ваги i впливу кожного атрибута запропоновано використати матрищ попарних по-рiвнянь, якi дае змогу генерувати САББ-заЫб. Побудованi шаблони матриць попарних порiвнянь оцiнюють експерти. Вщношення впливу мiж атрибутами опрацьовують методами статистичного оброблення. В результат отримаемо ваговi коефiцiенти кожного атрибута. Аналопчно до атрибутiв будують матрищ попарних порiвнянь для шдхарактеристик та характеристик, що дае змогу визначити кшьюсш частковi показники якост за вiдповiдними характеристиками та шдхарактеристиками моделей якостi. Ус ваговi множники, визна-ченi експертами, записують у репозиторiй вагових множниюв, а результати оцiнювання всiх рiвнiв моделi якостi - у репозиторш кшьюсного оцiнювання якостi. На основi даних, якi вiдображають кiлькiсну мiру якостi, формують специфiкацiю процесу оцшювання та розробляють рекомендаци щодо покра-щення якостi програмного продукту.
Розроблений САББ-заЫб е web-орiентованим i його можна використо-вувати як web-сервiс для пiдтримки процесiв розробки вимог i оцiнювання якостi ПС. У ньому забезпечено можливють вiддаленого формування потреб замовника, специфжаци вимог до ПЗ i визначення ступеня задоволення та вщповщносп вимог i потреб.
Структурно САББ-заЫб складаеться з двох частин: кшентсько! i сер-верно!. Клiентська частина надае замовнику можливють задання потреб у ви-глядi шаблону моделей якостi. Шаблон становить набiр стандартизованих характеристик, шдхарактеристик, атрибу^в та метрик. Замовник мае змогу ви-бирати властивостi, як необхiдно реалiзувати, базуючись на цьому шаблош (рис. 3).
I Incredatble specification builder - Mozilla Firefo* в KM
Файл Правка Вигляд Журнал Закладки 1нструменти Дов1дка
HfcJW ' О* yb'V | 1 httpi//specbuilder.crowdin.net/createspec "Ci ' | * Google M
1 j&i Нзйбшьш BiflBiflyBaHi ^^ Початкова CTopiHKa Останн1 sari яловки J My Opera Community |_j Amazon.com W Wikipedia Gmail: Електронне no...
Ф Наука и 06... 1ПММС - Пу... [3 Журнал "Bi. . | Gmaili Елек... | Словники У... Store Mana... инженерия ... * U52009019. Я постелю ... I§J? IBProvider -... Q rules []) Incred...Q
Incredatble specification builder Hello, Vasyl Yatcyshyn Logout
My Specifications « Dashboard Project 1 Submit custom requiremei 1 Create New Speciflcat x
¿. Create ' ©Remove Функщональтн ъ » Фухкшокальна повнота » Haiiraui« та перегляд шформаип » Головне меню
Керування¡нформацшним наповненням 0 Головне меню
Точн1сгь ► Нав1гац1я та перегляд ¡нформацм ПЗ Контексне меню
Захищежсть » Пошук та отримання ¡нформацн ►
П В|дпоещн1сть стандартам
< 1
(У Save As.
D • к f с I t d M t ~ Ct M
P <J У
Головне меню
Selected category hasn't metrics to change
Рис. 3. Шаблон формування потреб замовника
У CASE-засобi реашзовано також можливють формування потреб замовника у формальному текстовому виглядь Процедура адаптаци потреб, за-
даних таким чином, виконуеться на серверi шляхом 1х класифжаци за вщпо-вщними атрибутами, пiдхарактеристиками i характеристиками.
Серверна частина реалiзуе функци менеджера роботи з репозитор1ями ви-мог, потреб, вагових множниюв. На рис. 4 зображено iнтерфейс серверно! частини.
Рис. 4. Серверна частина CASE-засобу
На рис. 4 показано наповнення репозиторда стандартизованих метрик для ощнювання якост ПЗ. KpiM того, адмiнiстратор CASE-засобу мае можли-вiсть контролю, керування та наповнення уЫх репозиторив вщповщними да-ними. У сервернiй частит забезпечено можливють розподiлу прав доступу, налаштування зовнiшнього iнтерфейсу, спроектовано систему допомоги з ко-ристування CASE-засобом.
Пiд час розроблення засобу автоматизации орiентованого на пiдтримку етапу аналiзу вимог та оцiнювання якостi використано вщкрит компоненти та засоби розробки. Зокрема, кшентську частину реалiзовано за допомогою ком-понентiв JavaScript (Ext JS). Серверну частину розроблено за допомогою PHP 5.1 (Zend Framework) та MySQL 4.4 (InnoDB). Web-сервю можна використову-вати за адресою в мережi Internet http://specbuilder.crowdin.net/createspec
Висновки. Внаслщок застосування запропонованого CASE-засобу ре-алiзовано автоматизацiю процесу розроблення та аналiзу вимог, а також ощнювання якост ПЗ. Цей зашб е спецiалiзованим i втiлюе основш принципи технологiï, базовано1 на рекомендащях стандарту ISO 9126 1-4. Система дае змогу автоматизувати процес аналiзу вимог, шляхом побудови розробленого в робот шаблону для формування потреб. Наявшсть такого шаблону дае змогу однозначно та повною мiрою враховувати побажання кшцевих користува-чiв, цiлi замовника бiзнес-системи i вщповщшсть стандартам. На етапi розроблення вимог до ПЗ автоматизовано процеси: розроблення потреб замовника i формування вiдповiдноï специфжаци, перетворення потреб у вимоги до ПЗ, генерування специфшаци вимог. На етат ощнювання якост ПЗ автоматизовано функци роботи з репозиторiями характеристик, шдхарактеристик i метрик, процес визначення вагових множниюв i обчислення iнтегрального показника якость
Лггература
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 Specifications (ANSI).
4. Брауде Е Технология разработки программного обеспечения / Е. Брауде. - СПб. : Изд-во "Питер", 2004. - 655 с.
5. Харченко О. Розроблення та керування вимогами до програмного забезпечення на основi моделi якосп / О. Харченко, В. Яцишин // Вюник ТДТУ. - 2009. - Том 14, № 1. - С. 201-207.
6. Авраменко Е.А. Метод и средства редокументирования наследуемого программного обеспечения : дис... канд. техн. наук: спец. 01.05.03 / Национальный авиационный ун-т. - К., 2008. - 144 с.
7. Райчев 1.Е. Принципи побудови моделi якосп у використант програмних систем / I.E. Райчев, О.Г. Харченко // Збiрник наукових праць шституту проблем моделювання в енер-гегищ. - 2007. - Вип. 39. - С. 31-38.
8. ISO/IEC 25030 Software engineering-Software product Quality Requirement and Evaluation (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. Яцишин В.В. Анашз технологий розробки та управлшня вимогами до програмного забезпечення / В.В. Яцишин // Iнженерiя програмного забезпечення 2007 : матер. Всеукраш-сько'1 конф. астр. i студенпв. - К. : Изд-во НАУ. - С. 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 opportunity to show adequately the needs of the supplier and of the users of software on the requirements 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 design faster.
