Софтуерни технологии



страница6/18
Дата16.11.2017
Размер3.19 Mb.
Размер3.19 Mb.
1   2   3   4   5   6   7   8   9   ...   18

6. КАЧЕСТВО НА СОФТУЕРА

че това едва ли е стъпка към по-голяма яснота и конструктивност. Причината е


в значителната размитост на понятието потребител и още по-голямата неопре-
деленост на неговите нужди.

Така даденото определение може да се приложи и към качеството на соф-

, туера и да послужи за добра основа при изграждането на ясен и конкретен
възглед преди всичко с оглед на прагматичната задача за измерването му. Мето-
дологично погледнато, естествената стъпка, водеща до тази цел, е създаването

! на модел на качеството на софтуера.



6.2. Модели на качеството на софтуера

6.2.1. Модел на Боем


6.1. Общи понятия

Интуитивно е ясно, че всеки потребител желае да придобива и използва


качествен софтуер. От това следва, че и стремежът на всеки разработчик е да]
създава софтуер с високо качество. Стимулът за това е не само чисто етичен, но
има очевидни икономически причини. Възможността даден програмен продукт
да бъде продаден, и то на по-висока цена, зависи силно от неговото качество.
Теоретиците на софтуерните технологии и производство са разбирали важността
на качеството на софтуера и в повечето определения на предмета на дисципли-
ната, явно или не толкова явно, са включвали тази характеристика.

В контекста на този учебник и в съответствие с крайните цели на дисципли-


ната разглеждането на всяко понятие, в дадения случай качеството на софтуера,
трябва да води по възможност до конструктивни решения. Щом принципният
стремеж на производителите на софтуер е да създават софтуер с високо качество,
естествена цел е да се изгради някаква система или поне съвкупност от взаимооб-
вързани мерки за осигуряване на качеството. За да стане обаче това, необхо-
димо е преди това да се намерят достатъчно точни, обективни и ефективни метода
за измерване на качеството на програмните продукти. Последното пък изиск-
ва най-напред да се изясни какво е това качество на софтуера.

Напоследък повечето автори са склонни да дават по-обща дефиниция на


понятието качество, водени вероятно от убеждението, че всеки опит за по-под-
робно определение рано или късно ще доведе до намирането на контраприме-
ри и следователно до опровергаване. Причините за това се крият в прекалената
универсалност на понятието качество (дори ако се абстрахираме от философс-
кия му аспект), изключително широката му приложимост и уязвимост от прак-
тиката. Така че напоследък като че ли най-добре и от най-широк кръг се възпри
ема определението, дадено в International Standard Quality Vocabulary (ISO 8402-
1986), още повече че то има в известен смисъл статут на стандарт:

Качеството е съвкупността от средства и характеристики на да
ден продукт или услуга, носители на способността му да отговори на яв-
но или неявно указани нужди.

Понякога изразът „указани нужди" се заменя с привидно по-конкретното


„нужди на потребителя", но дори един не особено задълбочен анализ показва

70
Смята се, че първи сериозни изследвания по въпроса е направил Боем [1]
през 1973 година, а по-късно, през 1978 година, ги е задълбочил с помощта на
други автори [2]. Моделът на качеството на софтуера на Боем има йерархичен
характер, но е сравнително слабо структуриран със своите реални две нива.
Качеството на софтуера Боем свързва преди всичко с неговата полезност и
възможност за лесно съпровождане. Първият аспект се определя от няколко
характеристики надеждност, ефективност и използваемост от гледна
точка на потребителя човек. Вторият аспект зависи от други характеристики —
тестируемост, разбираемост и модифицируемост. Освен това има още ед-
на, несвързана с двата аспекта характеристика, наречена портабелност (мо-
билност).
Характеристиките от своя страна зависят от свойства на по-долно
ниво. Тази зависимост вече не е чиста йерархия, защото не само че дадена ха-
рактеристика се определя от две или повече свойства от по-долното ниво, но
има свойства, които определят повече от една характеристика. Например на-
деждността се определя от три свойства — пълнота, точност и непротиворечи-
вост, но от своя страна непротиворечивостта определя и характеристиката раз-
бираемост. По-нататък идеята е да се оцени всяко свойство за конкретния прог-
рамен продукт чрез някаква обективна мярка (не непременно число, а по-скоро
една от малък брой възможни степени в рамките на скала). Тази мярка се нари-
ча метрика. Още тогава Боем е осъзнал, че по някакъв начин трябва да се
отразява важността на метриката. Защото е ясно, че дадено свойство или харак-
теристика е много важно за даден тип програмни продукти и не толкова — за
други. Типичен пример е надеждността — за софтуер, управляващ полети на
самолети или ракети, надеждността е една от най-важните характеристики, до-
:ато за един текстов редактор това едва ли е така. Още един жалон в работата на
Боем е разбирането за необходимостта от автоматизирано оценяване на свойс-
твата и характеристиките.

Естествено, като всяка пионерска работа и тази има своите недостатъци —


не съвсем ясната структурираност, недостатъчната пълнота на множеството от
характеристики, съсредоточаване почти изключително върху качеството на прог-
рамния код, а не върху цялостния програмен продукт, сравнително тясната ек-
спериментална база (програми на Фортран). Независимо от това следващите,
по-съвършени модели несъмнено са били силно повлияни от идеите на Боем.
Най-малкото развита е идеята за йерархичност, а и повечето от характеристи-

71

ките, предложени от Боем, отново са включени, макар и понякога на различни
нива. i

6.2.2. Типичен йерархичен модел \

Един завършен йерархичен модел на качеството на софтуера е предложен


в [3]. Този модел е създаден с активното участие на самолетостроителната ком-
пания „Боинг". Интересът на „Боинг" към такъв тип разработки е леснообяс-
ним. Проектът, чийто резултат е моделът, е имал три основни задачи:

— развиване и утвърждаване на резултатите от предходни проекти на по

добна тематика;


  • разширяване на рамката на разглеждане на програмния продукт като
    такъв;

  • разработване на методология за определяне и специфициране на изиск
    вания към факторите, определящи качеството на софтуера.

Като основа на нашите разглеждания ще ни послужи друг йерархичен модел
[4]. Той наподобява модела на „Боинг", почива на същите принципи, но има и
специфики, които идват само да покажат, че в една такава сложна и динамична
област, каквато е създаването на софтуер, трудно се достига единствена гледна
точка. Определящата причина да изберем [4] е участието на български специа-
листи в разработката на този модел и по-голямата му популярност в България.

Структура



Качеството се разглежда като йерархична структура. То се намира н
най-високото ниво — 0.

На следващото ниво — 1 — се намират факторите. Факторът се опре


деля като потребителски ориентирано свойство, представящо даден ас
пект на качеството на софтуера от гледище на потребителя.

В зависимост от конкретния модел факторите могат да бъдат от 6 до 16. В


разглеждания от нас те са 6 и са следните:

  • гъвкавост,

  • коректност,

  • надеждност,

  • съпровождаемост,

  • удобство на използване,

  • ефективноcт.

Ето как се дефинират горните фактори на качеството на програмния npо-
дукт. ;

Гъвкавост: Лекота на адаптиране към нови функционални условия, вклю-
чително при изменение на областта на приложение или други условия на функ-
циониране.

Коректност: Степен на съответствие на специфицираните алгоритми
други изисквания спрямо обработката на данни, както и спрямо потребителска
та документация.

Надеждност: Способност на програмния продукт да изпълнява зададе
ните функции, предвидени в програмната документация, при отклонения, във

72

никващи в средата на функциониране (апаратни и програмни отклонения и


грешки).

Съпровождаемост: Възможност за отстраняване на отклонения и грешки
в процеса на експлоатация на програмния продукт и за поддържането му в ак-
туално състояние.

Удобство на използване: Възможност за усвояване и експлоатация на прог-
рамния продукт с минимални усилия.

Ефективност: Пълнота и скорост на изпълнение на специфицираните
функции в зададената изчислителна среда.

На ниво 2 са критериите. Критериите са софтуерно ориентирани


свойства, представящи характеристики на програмния продукт. Всеки
фактор се определя от няколко критерия. Така например факторът съпровож-
даемост се определя от следните критерии:

  • структурност: степен на сложност на построяването на частите на
    програмата в единно цяло в съответствие с принципите на структурното проек-
    тиране и програмиране (впрочем тук следва да припомним, че разглежданият
    модел е разработван в средата на 80-те години, когато обектната ориентира-
    ност беше далече от сегашната си популярност и престиж);

  • простота: простота на построяването на програмите;

  • нагледност: нагледност на представянето на текстовете на програмите,
    възможност за визуално или звуково изобразяване на хода на изпълнението.

На ниво 3 се позиционират метриките. В йерархичните модели метри-
ките
са софтуерно ориентирани детайли на даден критерий. Ще отбеле-
жим, че в някои от другите йерархични модели това ниво отсъства. Където ги
има, метриките се определят от оценъчните елементи.

Ако продължим илюстрирането на йерархичната структура, можем да вземем


например поддървото на критерия нагледност, определен от следните метрики:

  • коментари към логиката на програмата

  • оформление на текста на програмата

  • възприета система за идентификация

Последното ниво — 4 — е това на оценъчните елементи. Оценъчният

73

елемент е елементарна характеристика на най-ниско ниво, която подле-


жи на количествено оценяване. От метриките, определящи критерия наглед-
ност, за пример нека вземем коментари към логиката на програмата. Тя се
определя от следните оценъчни елементи:

  • коментари към машиннонезависимите фрагменти на програ-
    мата


  • коментари към машиннозависимите фрагменти на програмата

  • коментари към входно-изходните точки



Определяне стойностите на оценъчните елементи

В рамките на йерархичните модели в процедурата за намиране на количес-


твена оценка на качеството, разгледана по-нататък, директно се оценяват само
оценъчните елементи. Методите, по които става това, могат да се класифицират
по два признака:

А. По начина на получаване на информацията за програмния продукт:



  • измерителен

  • регистрационен

  • органолептичен

  • изчислителен

Б. По източника на получаване на информацията:

  • традиционен

  • експертен

  • социологически

Ще проследим последователно дадените класификации.

Измерителният метод се състои в използването на програмни инстру-
ментални средства за определяне обема на програмата (например броя на редо-
вете първичен код, броя на редовете коментари, броя на операторите и на опе-
рандите, броя на изпълнимите оператори, броя на разклоненията в програмата,
броя на входните и на изходните точки и др.), на времето на изпълнението на
цялата програма или определени нейни клонове, на времето на реакция на прог-
рамата на определени входове, както и на други показатели.

74

Регистрационният метод се основава на информация, получена по време
на изпитания или функциониране на програмния продукт, когато се регистри-
рат определени събития, например време и брой на грешки, време на начало и
край на работата.

Органолептичният метод е основан на използването на информация, по-
лучавана от човека в резултат на анализ на възприятията му чрез сетивните
органи (зрение, слух) и се прилага при определяне на такива показатели, като
удобство на използване, коректност и други подобни.

Изчислителният метод използва теоретични и емпирични зависимости
(обикновено на ранни стадии на разработването), статистически данни, нат-
рупвани при изпитанията, експлоатацията и съпровождането на програмния про-
дукт. С помощта на изчислителния метод се определя точността на пресмятани-
ята, времето на реакция, необходимите ресурси и др.

В определени случаи може да се използва и комбинация от няколко метода.

Що се отнася до видовете източници на получаване на информацията, те се
класифицират така:


  • Стойностите на оценъчните елементи по традиционния метод се опре-
    делят в специализирани организации от звена по изпитания и изчисления. Таки-
    ва са лаборатории, полигони, центрове за изпитание на програмни продукти,
    стендове и др., както и отдели по програмиране, изчислителни центрове, служ-
    би за контрол на качеството и т. н.

  • Определянето на стойностите на оценъчните елементи чрез експерт-
    ния метод се осъществява от група експерти, компетентни в решаването на да-
    дения тип задачи, на основа на техния опит и интуиция. Експертният метод се
    използва в случаите, когато оценката не може да бъде извършена чрез друг
    метод или другите методи са значително по-трудоемки. Препоръчва се експер-
    тен метод да се прилага при оценяване на елементи, свързани с нагледността,
    удобството на използване, пригодността на документацията, структурността,
    широтата на обхват на функциите.

  • Социологическият метод се основава на обработката на специално под-
    готвени анкети въпросници, на информация от изложби и конференции и т. н.

Стойностите на оценъчните елементи могат да попадат в следните видо-
ве скали:

  • интервална скала, характеризираща се с относителни или абсолютни
    величини в даден интервал;

  • порядкова скала, позволяваща ранжиране на стойностите на някои оце-
    нъчни елементи чрез сравняването им с определени опорни стойности;

  • номинална скала, показваща само наличието на конкретното разглеж-
    дано свойство в дадения програмен продукт.

Процедура по оценяване

Целта на модела е конструктивна чрез използване на вече де-
финираната структура и като се следва точно определена процеду-
ра, да се определи за всеки даден програмен продукт (принадлежащ на
определен тип софтуер) число (обикновено дефинирано в интервала
[0,l]), което да характеризира качеството.
Основната идея на процедурата за оценяване на конкретен програмен про-

75

дукт се състои в следното (за нашите цели правим известно опростяване, което


обаче не нарушава принципите на оценяването):

1. Приема се, че всяка характеристика на всяко ниво може да приема стой-


ности в интервала [0,1]. Стойностите на всички оценъчни елементи се опреде-
лят от експерти по един от изброените по-rope методи. При това експертите
ползват някои най-общи указания, изготвени предварително. Когато се отнася
за определяне на стойност чрез измерителен, регистрационен или изчисли-
телен метод, се посочва точният начин за получаване на стойността (например
чрез формула) и как така получената стойност, ако не е в интервала [0,1], да се
трансформира подходящо. В останалите случаи се дават по-общи указания, нап-
ример от следния вид: коментарите към входно-изходните точки (един от оце-
нъчните елементи) се оценяват с:

  • 0, ако изцяло липсват;

  • 0.33, ако ги има, но са твърде кратки и неясни;

  • 0.67, ако ги има и са задоволителни;

— 1, ако са отлични (ясни, налични към всяка точка, с голяма обяснителна сила)
Стойностите на всички характеристики от по-горни нива се изчисляват ка-
то претеглени суми от стойностите на определящите ги характеристики от по-
долното ниво.

2. Приема се също така, че на всяка характеристика на всяко ниво съответ-


ства тегло в интервала [0,1]. При това, както е обичайно, сумата от теглата на
характеристиките, отнасящи се до една характеристика от по-горно ниво, е 1
Например, можем да предположим, че за разгледаното по-горе конкретно под-
дърво са определени такива тегла на ниво оценъчни елементи, отнасящи се до
метриката коментари към логиката на програмата:

  • 0.4 за коментари към машиннонезависимите фрагменти на програмата;

  • 0.3 за коментари към машиннозависимите фрагменти на програмата;

  • 0.3 за коментари към входно-изходните точки.

Всички теглови стойности, да ги наречем базови, се определят предвари-
телно от експерти и се отнасят до точно определен тип софтуерни продукти
Причината е, че дадена характеристика може да е изключително важна за даден
тип софтуер и тогава тя трябва да получи високо тегло; същата характеристика
може да не е особено съществена за качеството на друг тип софтуерни продук-
ти и тогава базовите експерти ще й дадат относително по-ниско тегло. Впрочем
по-горе дадохме такъв пример, отнасящ се до надеждността на различни типове
софтуер.

3. Следователно при започване на оценката на качеството на конкретен


програмен продукт от даден тип експертите разполагат с вече готовите:

  • процедура за оценяване;

  • указания за намиране стойностите на оценъчните елементи;

  • теглата към всички характеристики на всички нива точно за дадения
    тип софтуер.




  1. Експертите определят стойностите на всички оценъчни елементи, като
    използват структурата на модела и указанията и изследват оценявания програ-
    мен продукт.

  2. Нека получените стойности на оценъчните елементи, определящи мет-
    риката М са e,, е2,..., en, a съответните им предварително зададени тегла са
    W1,w2,...,wn. Тогава стойността на метриката М се изчислява по формулата:

76

М = е1 * w1 + е2 * w2 +... + en * wn

6. Например, ако разгледаме вече познатото поддърво и за него експертите
са определили следните оценки:


  • 0.9 за коментари към машиннонезависимите фрагменти на програмата;

  • 0.6 за коментари към машиннозависимите фрагменти на програмата;

  • 0.8 за коментари към входно-изходните точки, то ще се получи:
    М = 0.9 * 0.4 + 0.6 * 0.3 + 0.8 * 0.3 = 0.36 + 0.18 + 0.24 = 0.78
    (теглата са определени по-горе в т. 2).

7. Същата схема на пресмятане се прилага за всяко от следващите нива.

7.1. След като всички стойност на метрики М са ни известни, за всеки кри-


терий С прилагаме формулата: *

С = М1 * w1 + М2 * w2 +... + Mn * wn,


където Mi са метриките, определящи критерия С.

7.2. Аналогично, след като всички стойност на критерии С са ни известни,


за да получим стойността на всеки фактор F прилагаме формулата:

F = C1*W|+C2*w2+... + Cn*wn

Тук Ci са критериите, които определят фактора F.

7.3. И накрая, след като всички стойности на фактори F са ни известни, за
да получим стойността на качеството Q прилагаме формулата:

Q = F1*w1 + F2*w2+... + Fn,*wn

където Fi са факторите, които определят качеството Q.

Ще отбележим, че педантичната нотация би изисквала три индекса за точ-


ното експлициране принадлежността на една метрика (коя е поред в рамките на
множеството, определящо критерия, кой поред е критерият и кой — факторът).
Спестяваме ги за по-голяма прегледност и по-лесно четене. Несъмнено всеки
би могъл да разбере какво означава обозначението Мijk.

По този начин получаваме числото Q. То остава в интервала [0,1]. Причи-


ната за това е, че всички стойности на тегла и на оценъчни елементи са в интер-
вала [0,1]. Ясно е, че програмен продукт с Q = 1 е с максимално високо качес-
тво. В реалността стойност 1 не би трябвало да се достига, защото тя има сми-
съла на идеал за високо качество. Благодарение на нормализацията става въз-
можно сравняването на получените стойности за Q на различни програмни про-
дукти, както и получаването на самостоятелна представа за качеството на отде-
лен програмен продукт.

Оценка на модела и метода

Така описаният модел на качеството и свързаната с него процедура за оценка
има следните предимства:


  1. Простота на модела от структурна гледна точка. Йерархията е лесно
    обозрима структура, с ясно видими еднопосочни връзки. При сегашните разби-
    рания за качеството на софтуера тази структура е адекватно негово отражение.

  2. Структурата на модела съдържа в себе си и директно следващи възмож-
    ности за конструктивност, т. е. за изграждане на процедура за оценяване.
    Видяхме как е направено това.

  3. Твърде елементарно е да се създаде компютърна програма за пресмята-
    не на оценката, доколкото действията са прости и еднообразни. Нещо повече,
    без такава автоматизация оценяването става твърде неефективно.

77

4. Крайният резултат е едно-единствено число в зададен интервал и това


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

Естествено, разглежданият йерархичен модел има и недостатъци:


1 Процедурата за оценяване съдържа твърде много елементи на субек-
тивност:

  • указанията за това, как да се определят стойностите на оценъчните еле-
    менти, както се видя по-горе, се изготвят предварително от експерти;

  • при самото определяне на стойностите на част от оценъчните елементи
    експертите, оценяващи конкретния програмен продукт, също не могат да не
    проявят субективност; оказва се, че твърде малка част от тези оценъчни елемен-
    ти могат да бъдат оценени обективно (чрез измервания и изчисления); повечето
    получават стойности на основата на експертна оценка (ако искаме да сме съв-
    сем точни, ще посочим, че от общо 257 оценъчни елемента в разглеждания мо-
    дел 216, т. е. около 84% се оценяват на чисто експертна основа [5]);

  • теглата на всички нива за всеки тип програмни продукти се определят
    предварително от експерти, следователно — субективно.

Естествено, съществуват методи, които позволяват от няколко субективни
експертни оценки да се получи една — много по-малко субективна. Това не
премахва изцяло проблема, но във всички случаи, ако се прилага, оскъпява
цялостната процедура.

  1. Огромна трудоемкост поради посочената вече необходимост от мно-
    гостранна и разнообразна работа на експертите по предварително определяне
    на тегла, на указания за оценяване, както и на отделен труд по определяне стой-
    ностите на оценъчните елементи за всеки конкретен програмен продукт.

  2. Донякъде недостатък е и това, че макар моделът да е топологично универ-
    сален (т. е. грубо казано; йерархичната структура е винаги една и съща), всеки
    тип програмни продукти изисква свое собствено множество от тегла.

6.2.3. Класификационен модел


Сподели с приятели:
1   2   3   4   5   6   7   8   9   ...   18


©zdrasti.info 2017
отнасят до администрацията

    Начална страница