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



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

Табл. 6.2. Примерна обучаваща таблица

Вижда се, че например стълбовете 7 и 9 образуват тест. Комбинацията


(0,1) се среща само в първия клас, (0,0) — само в третия, а останалите две
комбинации — (1,0) и (1,1) — само във втория.

Представителен набор за даден клас по някакво подмножество от стъл-
бове е такава част от описание, която в подтаблицата, образувана от този стъл-
бове, се среща в дадения клас, но не се среща в останалите класове. Неприво-
дим се нарича представителен набор, никоя част от който не е представителен
набор. Ще го означаваме с НПН. Ако в горната таблица разгледаме стълбовете
1, 3 и 5, ще забележим, че описанието (0,0,0) е характерно само за третия клас
(то се среща в Е7 и E8 и в никой друг клас).

Забележете, че тестовете са общи за цялата таблица и различават всич-


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

Алгоритми

Създадени са няколко алгоритъма, които по различен начин, използвайки


било НТ, било НПН, се опитват да класифицират даден обект (продукт) към
някой от класовете на таблицата. Казваме „опитват", защото има случаи, когато
алгоритъмът не е в състояние да завърши успешно класифицирането. Това е
една от причините да се използват няколко алгоритъма едновременно. Когато
се получи резултатът от всеки от тях, се прилага някаква обобщаваща процеду-
ра, която дава окончателния резултат. Най-просто е да се извърши гласуване

80
Тук Т е множеството на всички HT,j1 j2... , jk образуват НТ


Резултатът у1, (Е) всъщност показва броя гласове, които в рамките на този

алгоритъм идват от класа 1. Ако се върнем към горната таблица пример и решим

да класифицираме продукта

Е = (1,0,0,0,1,1,0,1,1,0,-,0,0),

ще видим, че се получава следният резултат:

у,(Е)=1/2(2(7,9)+...) = 3


у2(Е)=1/3(0(7,9)+...) = 0
у3(Е)=1/3(0(7;9)+...) = 0

Поясняваме, че в изчислението за първия клас от други НТ идват още 4


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

Пример

Един от първите реални примери, чрез които е проверяван и валидиран


разглежданият класификационен метод, оценява програмни продукти за труд и
работна заплата. Избрани са 9 такива продукта, разпределени в 3 класа — мно-
го добри, добри,слаби. Това разпределение е направено от експерти. Опреде-
лени са и 22 характеристики и всеки от продуктите е описан като вектор по тези
характеристики. По-нататък се оказва, че 9 от признаците не са информативни,
защото имат еднакви стойности за всичките 9 продукта. Така остават следните
13 признака:

  1. Минимални входни данни

  2. Просто кодиране на входните данни

  3. Степен на автоматичност

  4. Приложимост при изменящи се условия

  5. Оптималност на организацията на данните

  6. Рационалност на интерфейса

  7. Бързина на изпълнение

  8. Независимост от операционната система

  9. Лекота на експлоатация




  1. Структурираност

  2. Възможности за интерфейс с други продукти

  3. Рационалност на потребителския език

  4. Защита на данните

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

81

Когато през 80-те години се появяват персоналните компютри, а през 90-


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

1.1.2.Проблеми

От така скицираното развитие на програмите за компютри за последните


около 50 години лесно могат да се видят няколко най-общи техни характерис-
тики:

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

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

  • последното обаче веднага води до необходимостта от преносимост на
    програмата от един компютър на друг;

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

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

1.1.3. Определения

След тези подготвителни бележки сме готови да дадем определение за прог-


рама и за програмен продукт.

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


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

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


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

Думата софтуер според [1] се употребява за обозначаване на съвкупност


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

10

Друго определение, което по общо виждане се доближава още повече до


понятието програмен продукт, е формулирано през 1983 r. от голямата профе-
сионална американска асоциация на електронните инженери lEEE и гласи, че
софтуерът — това са компютърни програми, процедури, правила и евентуал-
но придружаваща документация, както и данни, отнасящи се до функционира-
нето на компютърната система.

Днес най-голяма гражданственост е придобило разбирането за софтуера


като общо понятие за програмни и/или програмни продукти.

1.2. Xapakmepucmuku на софтуера

За да достигнем до предмета на софтуерните технологии, ще разгледаме


няколко най-общи характерни особености на софтуера. Редът на разглеждане-
то им не е свързан с тяхната значимост.

1.2.1. Необходими ресурси

Софтуерните продукти в сравнение с много друга се отличават невероят-


но много по отношение на влаганите в тях ресурси, откъдето следва и цената
им. Знае се, че един нов автомобил може да струва примерно от 5 000 до 200 хил.
щатски долара, а ако се разгледат 95% от продаваните автомобили, този интер-
вал ще се свие значително. За сравнение ще посочим софтуерни продукти око-
ло двата края на скалата.

  • По отношение на използвания ресурс и от време, и хора (а оттам и цена)
    на горния край се намират софтуерните проекти, свързани с американската кос-
    мическа програма — „Аполо", „Скайлаб", „Совалката"; те са изисквали труда на
    700 души в продължение на 7 години; подобен по мащаб е проектът за управле-
    ние на въздушния трафик на САЩ, който е бил разработван в продължение на 5
    години от 500 души. Без да разполагаме с точни данни за цената на тези продук-
    ти, веднага може да се оцени, че и в двата случая тя е към милиард долара.

  • По отношение на мащаба и сложността може да споменем (отново в
    горния край на скалата) една от резервационните системи в САЩ, която преди
    повече от десет години при създаването си вече е била обслужвана от 13 500
    свързани терминала и е обработвала средно по 10 600 000 транзакции на ден.

  • За сравнение можем да посочим проста (но вършеща работа) информа-
    ционна система за персонален компютър, която би могла да се разработи от един
    опитен програмист за един ден и следователно да струва примерно 100 долара.

  • Що се отнася до пример по отношение на сложност, на долния край на
    скалата би могла да се посочи програма за пресмятане на данък или пък прост
    калкулатор.

1.2.2. Абстрактностна софтуера

Софтуерният продукт не може да бъде почувстван с нито едно от петте


човешки сетива. С компютъра това не е така — той може най-малкото да бъде
видян или пипнат. Разбира се, написаните команди на първичния текст на една

11


Литература

7. СОФТУЕРНИ МЕТРИКИ


l.BoehmB. W. Software and its Impact: A Quantitative Assessment. Datamation, Vol.19, No.5,
Mayl973,p.4£—59.

  1. Boehm B.W. etal. Characteristics of Software Quality. North Holland. 1987.

  2. Bowen T.P., G.B.Wigle, J.T.Tsai. Specification of Software Quality Attributes — Software
    Quality Evaluation Guidebook, RADC-TR-85-37, Vol.III, 1985.

  3. Общая методика оценки качества программньгх средств. Межправительственная комми-
    сия no сотрудничеству социалистических стран в области вичислительной техники. Бюлле-
    тень, вьшуск 1(37), Москва, 1988.

  4. Eskenazi A. The Problem ofObjectivity in Software Quality Evaluation. Proceedings ofthe
    19 Intl.Conf. with Summer School „Information Technologies and Programming", Sofia, 1994,
    p.6—14.

  5. Eskenasi A. Evaluation ofSoftware Quality by Means ofClassification Methods. J. ofSystems
    and Software, vol.10, No 3, October 1989, p. 213—216.

  6. Ангелова, В. Оценка на качеството на програмни продукти чрез класификационни мето-
    ди. Кандидатскадисертация. София, 1987.

7.1.Въведение

В тази глава ще обясним същността на софтуерните метрики и ще предло-


жим класификация по няколко критерия. Ще опишем шест ,"kласически" метри-
ки, измерващи характеристики на различни типове обекти — продукти, проце-
си и ресурси. Накрая ще разгледаме някои методологични проблеми на изграж-
дане на система от метрики в конкретна софтуерна организация.


82

7.2. Измерването в софтуерното производство

Първата публикация, свързана със софтуерни метрики, излиза през 1968 г.


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

Ще въведем някои основни понятия, необходими за по-нататъшното изло-


жение, придържайки се основно към възприетата в [1] терминология.

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

Ако тези стойности са числови, измерването се нарича количествено.



Мярка е числото, съпоставено при количествено измерване.

Мярката представя различните състояния на характеристиката, която се


измерва.

Понятието метрика има две значения в областта на софтуерните техноло-


гии и производство:

а) Друго име за мярката;

б) Процедура за намиране и използване на мярката.

83


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

Обективност — получаваните мерки да не зависят от субекта, извърш-
ващ измерването.

Надежност — мярката да има необходимата различаваща способност и
при повтаряне на измерванията при еднакви условия да се получават еднакви
резултати.

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

В [2] са формулирани следните три предпоставки за прилагането на дадена


софтуерна метрика:

а) можем точно да измерваме някакво свойство на обект в софтуерното


производство;

б) съществува връзка между това, което можем да измерим, и това, което


бихме искали да знаем за съответното свойство;

в) тази връзка е осъзната, потвърдена (т. е. доказана е теоретично и експе-


риментално ) и може да бъде изразена чрез формула или в термините на съотве-
тен модел.

Следователно основните проблеми при създаване на софтуерни метрики


са два:

  • да се индентифицират съществени за изследване характеристики на соф-
    туерни обекти и те да се дефинират в изчислими термини;

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

7.3. Класификация на софтуерните метрики

Изключително голямото разнообразие на съществуващите софтуерни мет-


рики затруднява реалното им използване. Затова ще предложим класификация
на метриките по няколко критерия.

А. Класификация в зависимост от предназначението

Най-често софтуерните метрики се използват за:

а) оценяване на разходите и усилията за разработване на софтуера;

б) измерване на производителността на разработчиците;

в) моделиране на качеството на софтуера и оценяването му;

г) измерване и прогнозиране на надежността на създаваните софтуерни
системи;

д) изследване на някои програмни свойства.

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

а) за характеризиране (to characterize) — да разберем изследвания обект и


да установим база за сравнение при бъдещи оценки;

б) за оценяване (to assess) — регистриране на текущо състояние на изс-


ледвания обект;

в) за прогнозиране (to predict) — предварителна оценка за бъдещо състоя-


ние на изследвания обект;

84

г) за подобряване (to improve) — натрупване на количествена информация


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

В. Класификация в зависимост от типа на изследвания обект


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

а) процеси — дейности, свързани със създаването и използването на соф-


туера;

б) продукти — резултати от процесите;

в) ресурси — елементи, входни данни за процесите.

Всичко, което можем да измерваме, е характеристика на обект от горните


три класа. Измерваните характеристики могат да бъдат вътрешни (дефинирани
в термините на самия обект) или външни (дефинирани и измервани в зависи-
мост от отношението на обекта към средата му).

Примери за обекти в софтуерното производство и съответните им вътреш-


ни и външни характеристики са описани в таблица 1, структурата и някои дан-
ни на която са взети от [1] .

Г. Класификация в зависимост от начина на получаване на информация-


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

а) регистрационен метод — получаване на информацията по време на раз-


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

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


циално разработени инструментални средства;

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


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

г) изчислителен метод — използване на теоретични или емпирични зависи-


мости, изведени въз основа на статистическите данни, натрупани през различни
фази на жизнения цикъл на ПП.

Първи са се появили метриките, изследващи програми. Обяснението е,


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

а) в зависимост от начина на изследване — статични и динамични.

При статичните метрики се анализира само текстът на програмата, докато
за динамичните метрики е необходимо изпълнението й.

б) в зависимост от изследваната програмна характеристика — сложност


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

в) в зависимост от нивото на декомпозиране — изследване на отделна прог-


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

85


ОБЕКТИ

ВЪТРЕШНИ
ХАРАКТЕРИСТИКИ


ВЪНШНИ
ХАРАКТЕРИСТИКИ


ПРОДУКТИ







Спецификации

Размер
Модулност
Коректност
Функционалност
Възможност
за повторно използване

Изчерпателност
Съпровождаемост
Разбираемост

Проекти

Размер
Модулност
Свързаност

Качество
Сложност
Съпровождаемост

Програми

Размер
Алг. сложност
Тестируемост

Надежност
Приложимост
Съпровождаемост

Тестови данни

Размер
Ниво на тестване

Качество
Изчерпателност

Документация

Обем
Пълнота

Разбираемост
Адекватност

ПРОЦЕСИ







Специфициране

Продължителност
Трудоемкост
Брой изменения
в изискванията

Качество
Разходи
Стабилност

Детайлно проектиране

Продължителност
Трудоемкост
Брой открити грешки
в спецификациите

Разходи

Тестване

Продължителност
Трудоемкост
Брой открити грешки
в спецификациите

Разходи
Изчерпателност
Систематичност

РЕСУРСИ







Кадри

Възраст
Възнаграждение

Производителност
Професионален опит

Екип

Численост
Структура

Продуктивност
Качество

Софтуер

Цена
Размер

Полезност
Надеждност

Хардуер

Цена
Изч. възможности

Надежност
на функциониране

Таблица 1
86

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

7.4. Примери за софтуерни метрики

Ще опишем някои софтуерни метрики, които се смятат за „класически". Те


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

Метриките ще представим по следната схема:

I. Описание

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


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

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


ката резултати.


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


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

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