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 на различни програмни про-
дукти, както и получаването на самостоятелна представа за качеството на отде-
лен програмен продукт.
Оценка на модела и метода
Така описаният модел на качеството и свързаната с него процедура за оценка
има следните предимства: Простота на модела от структурна гледна точка. Йерархията е лесно
обозрима структура, с ясно видими еднопосочни връзки. При сегашните разби-
рания за качеството на софтуера тази структура е адекватно негово отражение.
Структурата на модела съдържа в себе си и директно следващи възмож-
ности за конструктивност, т. е. за изграждане на процедура за оценяване.
Видяхме как е направено това.
Твърде елементарно е да се създаде компютърна програма за пресмята-
не на оценката, доколкото действията са прости и еднообразни. Нещо повече,
без такава автоматизация оценяването става твърде неефективно.
77
4. Крайният резултат е едно-единствено число в зададен интервал и това
допринася за избягване на двусмислия и неясноти относно качеството на оце-
няване на програмен продукт.
Естествено, разглежданият йерархичен модел има и недостатъци:
1 Процедурата за оценяване съдържа твърде много елементи на субек-
тивност:
указанията за това, как да се определят стойностите на оценъчните еле-
менти, както се видя по-горе, се изготвят предварително от експерти;
при самото определяне на стойностите на част от оценъчните елементи
експертите, оценяващи конкретния програмен продукт, също не могат да не
проявят субективност; оказва се, че твърде малка част от тези оценъчни елемен-
ти могат да бъдат оценени обективно (чрез измервания и изчисления); повечето
получават стойности на основата на експертна оценка (ако искаме да сме съв-
сем точни, ще посочим, че от общо 257 оценъчни елемента в разглеждания мо-
дел 216, т. е. около 84% се оценяват на чисто експертна основа [5]);
теглата на всички нива за всеки тип програмни продукти се определят
предварително от експерти, следователно — субективно.
Естествено, съществуват методи, които позволяват от няколко субективни
експертни оценки да се получи една — много по-малко субективна. Това не
премахва изцяло проблема, но във всички случаи, ако се прилага, оскъпява
цялостната процедура.
Огромна трудоемкост поради посочената вече необходимост от мно-
гостранна и разнообразна работа на експертите по предварително определяне
на тегла, на указания за оценяване, както и на отделен труд по определяне стой-
ностите на оценъчните елементи за всеки конкретен програмен продукт.
Донякъде недостатък е и това, че макар моделът да е топологично универ-
сален (т. е. грубо казано; йерархичната структура е винаги една и съща), всеки
тип програмни продукти изисква свое собствено множество от тегла.