Софтуерни технологии
Табл. 6.2. Примерна обучаваща таблица
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- Неприво- дим
- 1.2. Xapakmepucmuku на софтуера
- Литература 7. СОФТУЕРНИ МЕТРИКИ
- 7.1.Въведение
- 7.2. Измерването в софтуерното производство
- ОБЕКТИ ВЪТРЕШНИ ХАРАКТЕРИСТИКИ ВЪНШНИ ХАРАКТЕРИСТИКИ
- 7.4. Примери за софтуерни метрики
|
Табл. 6.2. Примерна обучаваща таблица Вижда се, че например стълбовете 7 и 9 образуват тест. Комбинацията (0,1) се среща само в първия клас, (0,0) — само в третия, а останалите две комбинации — (1,0) и (1,1) — само във втория. Представителен набор за даден клас по някакво подмножество от стъл- бове е такава част от описание, която в подтаблицата, образувана от този стъл- бове, се среща в дадения клас, но не се среща в останалите класове. Неприво- дим се нарича представителен набор, никоя част от който не е представителен набор. Ще го означаваме с НПН. Ако в горната таблица разгледаме стълбовете 1, 3 и 5, ще забележим, че описанието (0,0,0) е характерно само за третия клас (то се среща в Е7 и E8 и в никой друг клас). Забележете, че тестовете са общи за цялата таблица и различават всич- ки класове едновременно, докато представителните набори отличават само даден клас от всички останали. Представителните набори са толкова по-доб- ри, колкото кратността им е по-голяма (брой на появяванията им за дадения клас). Двете понятия — НТ и НПН — се характеризират с дължина — броя на признаците, които участват в тях. Алгоритми Създадени са няколко алгоритъма, които по различен начин, използвайки било НТ, било НПН, се опитват да класифицират даден обект (продукт) към някой от класовете на таблицата. Казваме „опитват", защото има случаи, когато алгоритъмът не е в състояние да завърши успешно класифицирането. Това е една от причините да се използват няколко алгоритъма едновременно. Когато се получи резултатът от всеки от тях, се прилага някаква обобщаваща процеду- ра, която дава окончателния резултат. Най-просто е да се извърши гласуване 80
Резултатът у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 признака:
Описанията образуват дадената вече като пример таблица. При експеримен- тите последователно всеки от продуктите е изваждан от таблицата и разпознаван чрез разработените 8 класификационни алгоритъма. Резултатите са твърде оку- ражителни. Подобни експерименти са правени и със значителен брой други ти- пове програмни продукти — авторски системи, текстови редактори и др. 81
те средствата за глобална комуникация стават потенциално достъпни за всеки, това променя значително изброените характеристики на програмите за ком- пютри, доколкото кръгът от потребители рязко нараства и става изключително разнообразен по образование, квалификация, възраст, интереси и пр. 1.1.2.Проблеми От така скицираното развитие на програмите за компютри за последните около 50 години лесно могат да се видят няколко най-общи техни характерис- тики:
От тези характеристики непосредствено следва, че програмата трябва да може да бъде записвана на някакъв технически носител и да бъде придружава- на от определени документи, които я описват в различни аспекти. 1.1.3. Определения След тези подготвителни бележки сме готови да дадем определение за прог- рама и за програмен продукт. Програмата е последователност от инструкции, които, когато бъ- дат декодирани от компютър (или от компютър и транслираща прог- рама), водят до решаването от страна на компютъра на дадена задача. Програмният продукт е програма или съвкупност от взаимодейс- тващи програми, записани върху технически носител и придружени от съответна документация. Веднага възниква въпросът за все по-често използваната дума софтуер. Ще смятаме термините софтуерен продукт и програмен продукт за еквива- лентни по смисъл. Думата софтуер според [1] се употребява за обозначаване на съвкупност от взаимодействащи програми и в този смисъл се доближава донякъде до поня- тието програмен продукт. 10 Друго определение, което по общо виждане се доближава още повече до понятието програмен продукт, е формулирано през 1983 r. от голямата профе- сионална американска асоциация на електронните инженери lEEE и гласи, че софтуерът — това са компютърни програми, процедури, правила и евентуал- но придружаваща документация, както и данни, отнасящи се до функционира- нето на компютърната система. Днес най-голяма гражданственост е придобило разбирането за софтуера като общо понятие за програмни и/или програмни продукти. 1.2. Xapakmepucmuku на софтуера За да достигнем до предмета на софтуерните технологии, ще разгледаме няколко най-общи характерни особености на софтуера. Редът на разглеждане- то им не е свързан с тяхната значимост. 1.2.1. Необходими ресурси Софтуерните продукти в сравнение с много друга се отличават невероят- но много по отношение на влаганите в тях ресурси, откъдето следва и цената им. Знае се, че един нов автомобил може да струва примерно от 5 000 до 200 хил. щатски долара, а ако се разгледат 95% от продаваните автомобили, този интер- вал ще се свие значително. За сравнение ще посочим софтуерни продукти око- ло двата края на скалата.
1.2.2. Абстрактностна софтуера Софтуерният продукт не може да бъде почувстван с нито едно от петте човешки сетива. С компютъра това не е така — той може най-малкото да бъде видян или пипнат. Разбира се, написаните команди на първичния текст на една 11
Литература 7. СОФТУЕРНИ МЕТРИКИ  l.BoehmB. W. Software and its Impact: A Quantitative Assessment. Datamation, Vol.19, No.5,
Mayl973,p.4£—59.
7.1.Въведение В тази глава ще обясним същността на софтуерните метрики и ще предло- жим класификация по няколко критерия. Ще опишем шест ,"kласически" метри- ки, измерващи характеристики на различни типове обекти — продукти, проце- си и ресурси. Накрая ще разгледаме някои методологични проблеми на изграж- дане на система от метрики в конкретна софтуерна организация. 82 7.2. Измерването в софтуерното производство Първата публикация, свързана със софтуерни метрики, излиза през 1968 г. и поставя проблема за количествено измерване качеството на програми. Инте- ресът към този проблем е неотслабващ, за което свидетелстват ежегодните меж- дународни конференции на тази тема, големият брой книги и публикации в спе- циализираните издания. Основната идея на прилагането на софтуерни метрики е да се измерват характеристики на обекти в софтуерното производство (спе- цификации, проекти, програми, документация и др.). Така може да се получава информация за качеството на тези обекти и по възможност да се прогнозират някои тенденции в процеса на разработване на софтуера, за които се смята, че зависят от изследваните характеристики и могат да бъдат управлявани. Ще въведем някои основни понятия, необходими за по-нататъшното изло- жение, придържайки се основно към възприетата в [1] терминология. Измерването е процес, при който в съответствие с определени правила на характеристики на изследвания обект се съпоставят стойности. Ако тези стойности са числови, измерването се нарича количествено. Мярка е числото, съпоставено при количествено измерване. Мярката представя различните състояния на характеристиката, която се измерва. Понятието метрика има две значения в областта на софтуерните техноло- гии и производство: а) Друго име за мярката; б) Процедура за намиране и използване на мярката. 83
 Измерването и получаваните мерки трябва да притежават следните свойс-
тва: Обективност — получаваните мерки да не зависят от субекта, извърш- ващ измерването. Надежност — мярката да има необходимата различаваща способност и при повтаряне на измерванията при еднакви условия да се получават еднакви резултати. Валидност — получаваните мерки да отразяват реално свойствата на из- мервания обект. В [2] са формулирани следните три предпоставки за прилагането на дадена софтуерна метрика: а) можем точно да измерваме някакво свойство на обект в софтуерното производство; б) съществува връзка между това, което можем да измерим, и това, което бихме искали да знаем за съответното свойство; в) тази връзка е осъзната, потвърдена (т. е. доказана е теоретично и експе- риментално ) и може да бъде изразена чрез формула или в термините на съотве- тен модел. Следователно основните проблеми при създаване на софтуерни метрики са два:
7.3. Класификация на софтуерните метрики Изключително голямото разнообразие на съществуващите софтуерни мет- рики затруднява реалното им използване. Затова ще предложим класификация на метриките по няколко критерия. А. Класификация в зависимост от предназначението Най-често софтуерните метрики се използват за: а) оценяване на разходите и усилията за разработване на софтуера; б) измерване на производителността на разработчиците; в) моделиране на качеството на софтуера и оценяването му; г) измерване и прогнозиране на надежността на създаваните софтуерни
д) изследване на някои програмни свойства. Б. Класификация в зависимост от целта на прилагане на метриката
а) за характеризиране (to characterize) — да разберем изследвания обект и да установим база за сравнение при бъдещи оценки; б) за оценяване (to assess) — регистриране на текущо състояние на изс- ледвания обект; в) за прогнозиране (to predict) — предварителна оценка за бъдещо състоя- ние на изследвания обект; 84 г) за подобряване (to improve) — натрупване на количествена информация за определяне на факторите, от които зависи качеството на продукта или ефек- тивността на процеса. В. Класификация в зависимост от типа на изследвания обект В софтуерното производство могат да се разграничат три основни типа обекти: а) процеси — дейности, свързани със създаването и използването на соф- туера; б) продукти — резултати от процесите; в) ресурси — елементи, входни данни за процесите. Всичко, което можем да измерваме, е характеристика на обект от горните три класа. Измерваните характеристики могат да бъдат вътрешни (дефинирани в термините на самия обект) или външни (дефинирани и измервани в зависи- мост от отношението на обекта към средата му). Примери за обекти в софтуерното производство и съответните им вътреш- ни и външни характеристики са описани в таблица 1, структурата и някои дан- ни на която са взети от [1] . Г. Класификация в зависимост от начина на получаване на информация- та, въз основа на която се определят стойностите на измерваните характеристи- ки: а) регистрационен метод — получаване на информацията по време на раз- работване или функциониране на ПП чрез регистриране на отделни събития — продължителност на сеанс, брой аварийни ситуации и описанието им в доку- ментацията и др.; б) измерителен метод — информацията се получава чрез прилагане на спе- циално разработени инструментални средства; в) възприятиен (органолептичен)метод — информация, получена след ана- лиз на зрителни или слухови възприятия — използвани цветове, бързина на смяна на текстове, звукова сигнализация и др. г) изчислителен метод — използване на теоретични или емпирични зависи- мости, изведени въз основа на статистическите данни, натрупани през различни фази на жизнения цикъл на ПП. Първи са се появили метриките, изследващи програми. Обяснението е, че програмите са най-важният продукт, създаван във всеки софтуерен про- ект. Сравнително лесно дори за неспециалист в областта на софтуерните метрики е идентифицирането на програмни свойства, които да бъдат изс- ледвани с определена цел. За този вид метрики е възможна следната класи- фикация: а) в зависимост от начина на изследване — статични и динамични. При статичните метрики се анализира само текстът на програмата, докато
б) в зависимост от изследваната програмна характеристика — сложност (структурна, текстуална или алгоритмична), модулност, тестируемост, незави- симост от средата, модифицируемост и др. в) в зависимост от нивото на декомпозиране — изследване на отделна прог- рамна част или на програмна система като цяло. Метриките от втората група са много по-сложни, защото се изследва потокът на данните и потокът на управле- ние в многокомпонентни системи. 85
Една метрика се нарича адитивна, ако резултатите от прилагането й за програмна система могат да се получат чрез сумиране на резултатите от прила- гането й върху съставящите я програмни части. 7.4. Примери за софтуерни метрики Ще опишем някои софтуерни метрики, които се смятат за „класически". Те се споменават най-често в специализираната литература и са с висока степен на валидираност, т. е. полезността от прилагането им е потвърдена теоретичес- ки и/или експериментално. Описанието е кратко и цели само да се добие пред- става за съответната метрика, а в цитираните източници могат да се намерят останалите подробности. Метриките ще представим по следната схема: I. Описание То включва вида на метриката по някои от критериите за класификация, препратка към литература за допълнителна информация, описание на самата метрика и оценъчните елементи, които използва, възможности за автоматиза- ция на процедурата за измерване и др. П. Приложимост — за какво могат да се използват получаваните от метри- ката резултати. Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
| |||||||||||||||||||||||||||||||||||||||||||||||||||
