Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 6.2. Модели на качеството на софтуера 6.2.1. Модел на Боем 6.1. Общи понятия
- Съпровождаемост
- Ефективност
- Определяне стойностите на оценъчните елементи
- Стойностите
- Процедура по оценяване
- F = C 1 * W| +C 2 *w 2 +... + C n *w n
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 и са следните:
Ето как се дефинират горните фактори на качеството на програмния npо- дукт. ; Гъвкавост: Лекота на адаптиране към нови функционални условия, вклю- чително при изменение на областта на приложение или други условия на функ- циониране. Коректност: Степен на съответствие на специфицираните алгоритми други изисквания спрямо обработката на данни, както и спрямо потребителска та документация. Надеждност: Способност на програмния продукт да изпълнява зададе ните функции, предвидени в програмната документация, при отклонения, във 72 никващи в средата на функциониране (апаратни и програмни отклонения и грешки). Съпровождаемост: Възможност за отстраняване на отклонения и грешки в процеса на експлоатация на програмния продукт и за поддържането му в ак- туално състояние. Удобство на използване: Възможност за усвояване и експлоатация на прог- рамния продукт с минимални усилия. Ефективност: Пълнота и скорост на изпълнение на специфицираните функции в зададената изчислителна среда. 
На ниво 2 са критериите. Критериите са софтуерно ориентирани свойства, представящи характеристики на програмния продукт. Всеки фактор се определя от няколко критерия. Така например факторът съпровож- даемост се определя от следните критерии:
На ниво 3 се позиционират метриките. В йерархичните модели метри- ките са софтуерно ориентирани детайли на даден критерий. Ще отбеле- жим, че в някои от другите йерархични модели това ниво отсъства. Където ги има, метриките се определят от оценъчните елементи. Ако продължим илюстрирането на йерархичната структура, можем да вземем например поддървото на критерия нагледност, определен от следните метрики:
Последното ниво — 4 — е това на оценъчните елементи. Оценъчният 73
жи на количествено оценяване. От метриките, определящи критерия наглед- ност, за пример нека вземем коментари към логиката на програмата. Тя се определя от следните оценъчни елементи:
Определяне стойностите на оценъчните елементи В рамките на йерархичните модели в процедурата за намиране на количес- твена оценка на качеството, разгледана по-нататък, директно се оценяват само оценъчните елементи. Методите, по които става това, могат да се класифицират по два признака: А. По начина на получаване на информацията за програмния продукт:
Б. По източника на получаване на информацията:
Ще проследим последователно дадените класификации. Измерителният метод се състои в използването на програмни инстру- ментални средства за определяне обема на програмата (например броя на редо- вете първичен код, броя на редовете коментари, броя на операторите и на опе- рандите, броя на изпълнимите оператори, броя на разклоненията в програмата, броя на входните и на изходните точки и др.), на времето на изпълнението на цялата програма или определени нейни клонове, на времето на реакция на прог- рамата на определени входове, както и на други показатели. 74 Регистрационният метод се основава на информация, получена по време на изпитания или функциониране на програмния продукт, когато се регистри- рат определени събития, например време и брой на грешки, време на начало и край на работата. Органолептичният метод е основан на използването на информация, по- лучавана от човека в резултат на анализ на възприятията му чрез сетивните органи (зрение, слух) и се прилага при определяне на такива показатели, като удобство на използване, коректност и други подобни. Изчислителният метод използва теоретични и емпирични зависимости (обикновено на ранни стадии на разработването), статистически данни, нат- рупвани при изпитанията, експлоатацията и съпровождането на програмния про- дукт. С помощта на изчислителния метод се определя точността на пресмятани- ята, времето на реакция, необходимите ресурси и др. В определени случаи може да се използва и комбинация от няколко метода. Що се отнася до видовете източници на получаване на информацията, те се
Стойностите на оценъчните елементи могат да попадат в следните видо- ве скали:
Процедура по оценяване Целта на модела е конструктивна — чрез използване на вече де- финираната структура и като се следва точно определена процеду- ра, да се определи за всеки даден програмен продукт (принадлежащ на определен тип софтуер) число (обикновено дефинирано в интервала [0,l]), което да характеризира качеството. Основната идея на процедурата за оценяване на конкретен програмен про- 75
обаче не нарушава принципите на оценяването): 1. Приема се, че всяка характеристика на всяко ниво може да приема стой- ности в интервала [0,1]. Стойностите на всички оценъчни елементи се опреде- лят от експерти по един от изброените по-rope методи. При това експертите ползват някои най-общи указания, изготвени предварително. Когато се отнася за определяне на стойност чрез измерителен, регистрационен или изчисли- телен метод, се посочва точният начин за получаване на стойността (например чрез формула) и как така получената стойност, ако не е в интервала [0,1], да се трансформира подходящо. В останалите случаи се дават по-общи указания, нап- ример от следния вид: коментарите към входно-изходните точки (един от оце- нъчните елементи) се оценяват с:
— 1, ако са отлични (ясни, налични към всяка точка, с голяма обяснителна сила) Стойностите на всички характеристики от по-горни нива се изчисляват ка- то претеглени суми от стойностите на определящите ги характеристики от по- долното ниво. 2. Приема се също така, че на всяка характеристика на всяко ниво съответ- ства тегло в интервала [0,1]. При това, както е обичайно, сумата от теглата на характеристиките, отнасящи се до една характеристика от по-горно ниво, е 1 Например, можем да предположим, че за разгледаното по-горе конкретно под- дърво са определени такива тегла на ниво оценъчни елементи, отнасящи се до метриката коментари към логиката на програмата:
Всички теглови стойности, да ги наречем базови, се определят предвари- телно от експерти и се отнасят до точно определен тип софтуерни продукти Причината е, че дадена характеристика може да е изключително важна за даден тип софтуер и тогава тя трябва да получи високо тегло; същата характеристика може да не е особено съществена за качеството на друг тип софтуерни продук- ти и тогава базовите експерти ще й дадат относително по-ниско тегло. Впрочем по-горе дадохме такъв пример, отнасящ се до надеждността на различни типове софтуер. 3. Следователно при започване на оценката на качеството на конкретен програмен продукт от даден тип експертите разполагат с вече готовите:
76 М = е1 * w1 + е2 * w2 +... + en * wn 6. Например, ако разгледаме вече познатото поддърво и за него експертите
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 = F1*w1 + F2*w2+... + Fn,*wn където Fi са факторите, които определят качеството Q. Ще отбележим, че педантичната нотация би изисквала три индекса за точ- ното експлициране принадлежността на една метрика (коя е поред в рамките на множеството, определящо критерия, кой поред е критерият и кой — факторът). Спестяваме ги за по-голяма прегледност и по-лесно четене. Несъмнено всеки би могъл да разбере какво означава обозначението Мijk. По този начин получаваме числото Q. То остава в интервала [0,1]. Причи- ната за това е, че всички стойности на тегла и на оценъчни елементи са в интер- вала [0,1]. Ясно е, че програмен продукт с Q = 1 е с максимално високо качес- тво. В реалността стойност 1 не би трябвало да се достига, защото тя има сми- съла на идеал за високо качество. Благодарение на нормализацията става въз- можно сравняването на получените стойности за Q на различни програмни про- дукти, както и получаването на самостоятелна представа за качеството на отде- лен програмен продукт. Оценка на модела и метода Така описаният модел на качеството и свързаната с него процедура за оценка
77 4. Крайният резултат е едно-единствено число в зададен интервал и това допринася за избягване на двусмислия и неясноти относно качеството на оце- няване на програмен продукт. Естествено, разглежданият йерархичен модел има и недостатъци: 1 Процедурата за оценяване съдържа твърде много елементи на субек- тивност:
Естествено, съществуват методи, които позволяват от няколко субективни експертни оценки да се получи една — много по-малко субективна. Това не премахва изцяло проблема, но във всички случаи, ако се прилага, оскъпява цялостната процедура.
6.2.3. Класификационен модел Каталог: 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. Сподели с приятели:
|
