Метрики в софтуерното инжинерство

1. Какво включват разходите за софтуерното инженерство?
2. Измерване в софтуерното производство
3. Какво е софтуерна метрика?
4. Класификация на софтуерните метрики
5. Примери за софтуерни метрики
6. Проблеми на използването на софтуерните метрики

Какво включват разходите за софтуерното инженерство?

Около 60% от разходите са за разработка, а 40% са разходи за тестване. За поръчков (специализиран) софтуер разходите за развитие често надвишават разходите за разработка.
Разходите варират в зависимост от типа на разработваната система и изискванията за системните параметри, такива като производителност и надеждност.
Разпределението на разходите зависи от производствения модел, който се използва.

Една от основните дейности при процеса на управление на софтуерния проект е планирането.

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

• необходимите човешки ресурси (обикновено в човекомесеци);
• хронологичното протичане на проекта (в календарно време);
• цената.

В много случаи оценките се правят на базата на минал опит.
Какво да се прави, ако проектът е от нова област и няма с какво да се сравни?
Разработени са набор техники за оценяване на софтуер.
Общи атрибути на техниките:

• Предварително установяване обхватът на проекта;
• Като основа да се използва предишен опит;
• Разбиване на проекта на части, които се оценяват поотделно.
• За индикация на качеството на продукта;
• За оценка на продуктивността на производителите на продукта;
• За оценка на ползата от използването на новите софтуерни методи и инструменти;
• За формиране на база за сравнение на други проекти;
• За подпомагане доказването на необходимостта от влагане на средства за закупуване на нови инструменти или допълнително обучение на хора.

Измерването е процес, при който в съответствие с определени правила на характеристики на изследвания обект се съпоставят стойности.
Количествено измерване – стойностите са числови.
Мярка е числото, съпоставено при количествено измерване.
Метрика в областта на СТ означава:
А) Друго име за мярката;
Б) Процедура за намиране и използване на мярката.

Основни свойства на измерването и мерките

Обективност – получаваните мерки да не зависят от субекта, извършващ измерването;
Надеждност – мярката да притежава необходимата различаваща способност и при повтаряне на измерванията при едни и същи условия да се получават еднакви резултати;
Валидност  – получаваните мерки да отразяват реално свойствата на измервания обект.
Можем точно да измерим някакво свойство на обект в софтуерното производство;
Съществува връзка между това, което можем да измерим, и това, което бихме искали да знаем за съответното свойство;
Тази връзка е доказана теоретично и експериментално и може да бъде изразена чрез формула или в термините на съответен модел.
Проблеми при създаване на софтуерни метрики
Да се идентифицират съществени за изследване характеристики на софтуерни обекти;
Да се дефинират тези характеристики в изчислими термини;
Да се определят:
типът на използваната скала;
допустимите операции върху метриките;
статистическият смисъл на оценяването;
ограничаването на грешките при измерване.

В зависимост от предназначението

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

• Оценяване на разходите и усилията за разработване на софтуер;
• Измерване производителността на разработчиците;
• Моделиране на качеството на софтуера и оценяването му;
• Измерване и прогнозиране на надежността на създаваните софтуерни системи;
• Изследване на някои програмни свойства.

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

Софтуерните метрики могат да бъдат:

• За характеризиране (to characterize) – да се разбере изследвания обект и да се създаде база за сравнение при следващи оценки;
• За оценяване (to assess) – регистриране на текущото състояние на изследвания обект;
• За прогнозиране (to predict) – предварителна оценка за бъдещо състояние на изследвания обект;
• За подобряване (to improve) – натрупване на количествена информация за определяне на факторите, от които зависи качеството на продукта и ефективността на процеса.

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

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

1. Процеси – дейности, свързани със създаването и използването на софтуер;
2. Продукти – резултати от процесите;

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

Всичко, което може да се измерва, е характеристика на обект от горните типове. Измерваните характеристики на обект могат да бъдат вътрешни, дефинирани в термините на самия обект, или външни, дефинирани в зависимост от отношението на обекта към средата му.
Класификация в зависимост от типа на обектa
В зависимост от начина на получаване на информацията
Регистрационен метод – получаване на информацията по време на разработване или използване на софтуера чрез регистриране на отделни събития;
Измерителен метод – информацията се получава посредством специално разработени за целта инструментални средства;
Възприятиен (органолептичен) метод – информация, получена след анализ на зрителни или слухови възприятия;
Изчислителен метод – използване на теоретични или емпирични зависимости, получени въз основа на статистическите данни, натрупани през различни фази на жизнения цикъл.
Класифиакция за метриките, изследващи програми.
В зависимост от начина на изследване – статични и динамични. Статичните метрики анализират само текста на програмата, докато динамичните изследват и изпълнението й.
В зависимост от изследваната програмна характаристика – сложност, модулност, тестируемост, независимост от средата, модифицируемост и др.
В зависимост от нивото на декомпозиране – изследване на отделна програмна част или на програмна система като цяло.

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

Метрика за размера на програма
Описание – Метриката е статична и може да се прилага както за отделен програмен модул, така и за програмна система.

За мярка на размера на програма се приема броят програмни редове в изходния текст на програмата (LOC – lines of code; KLOC=1000LOC).
L=L1 + L2
където
L – общ брой редове;
L1 – коментари и празни редове;
L2 – същински програмни редове.
Приложимост
Броят на грешките, усилията за разбиране, поддържане и съпровождане са право пропорционални на размера на програмите.
В зависимост от размера на ниво програмна единица и на размера и броя модули в програмната система, програмите могат да се класифицират като прости, средно сложни, сложни и свръхсложни и за всяка категория да се формулират мерките за осигуряване на качеството, да се оценят обхватът и сложността на тестването, съпровождането и др. Граничните стойности могат да се определят експериментално или задават за всеки софтуерен проект.
L е най-проста мярка за извършената от програмиста работа.
Метрика на Маккейб за структурна (цикломатична) сложност
Описание – Метриката на Маккейб е статична и измерва сложността на потока на управление в програмата. Тя е една от най-често циитраните в литературата. За прилагането й е необходимо да се построи управляващият граф на програмата (Flow Graph), в който върховете са отделните оператори (или линейни участъци), а два върха са свързани с ребро, ако има предаване на управление между съответните им оператори.
V(G) = E-N+2*P,
където
V(G) – цикломатичната сложност, която определя максималния брой линейно-независими пътя в програмата;
E – брой ребра в графа;
N – брой върхове в графа;
P – брой свързани компоненти в графа (брой области).
Приложимост
Метриката предлага мярка за вътрешномодулна сложност, която определя лекотата на разбиране и усвояване на програмите и точността на внасяне на изменения в тях.
Препоръчва се да се проектират модули с V(G)<10 като се смята, че модулите със сложност:
до 10 са прости;
до 20 – средно сложни;
от 30 до 50 – сложни;
над 50 – свръхсложни и трябва да се обмисли преструктурирането им.
Метрика на Холстед за текстуална сложност
Описание – Метриката е статична, за програма, написана на произволен програмен език. Датира от 1976 г. Програмата се разглежда като състояща се от активни елементи (оператори) и пасивни елементи (операнди). Операндите са константи или променливи, използвани при реализацията на алгоритъма в конкретна програма. Операторите са елементи, влияещи върху стойностите или наредбата на операндите.

За да се приложи тази метрика, трябва да бъдат определени:
n1 – брой различни оператори;
n2 – брой различни операнди;
N1 – общ брой оператори;
N2 – общ брой операнди.
Чрез тези оценъчни елементи се изчисляват:
Речник:     n = n1 + n2
Дължина на програмата:            N = N1  + N2
Изчислена дължина на програмата:    N = n1 * log2 (n1) + n2* log2 (n2)
Oбем на програмата:            V = (N1  + N2) * log2 (n1 + n2)
Трудност на програмата:            D = (n1/2) * (N2/n2)
Ниво на програмата:            L = 1/D
Усилия за създаване на програмата:    E = V * D    (Effort)
Приложимост
Могат да се оценяват усилията за създаването на програмата. Предлага се за оптимална сложност на програмата стойността
Eop = 60 800  и за максимална Emax = 129 600. Сравняването на E за конкретна програма с тези две стойности дава възможност да се класифицират усилията за разработването й като малки, средни или големи.
Може да се оцени времето за програмиране чрез използване на индекса на Страуд за интензивност на интелектуалните занимания, който за програмирането има стойност S = 18.
Така T = E/S = E/18
Доказано е, че усилията за създаване на нова програма са сравними с усилията за разбиране на съществуваща програма. Използва се за предварителна оценка на усилията за съпровождане в случаите, когато то не се осъществява от разработчиците.
Предлагат се следните формули за предварително оценяване броя на откриваните грешки:
B1 = V/3000        - брой грешки, откривани при тестването;
B2 = 4 * B1 = V/750    - общ брой грешки, открити през жизнения цикъл на програмата.
Обоснована е възможността усилията за тестване да се оценяват чрез произведението NX * E, където NX е индекс за ниво на влагане (индикатор за необходимия брой тестове), а E е мярката на Холстед за усилията за разработване

Метрика на Рехенберг за технологична сложност

Описание – Метриката Рехенберг е опит за преодоляване на едностранчивостта на съществуващите метрики за сложност. Тя е статична комплексна метрика, която може да се прилага за програми или програмни системи, написани на произволен език за програмиране, от високо ниво.
Рехенберг предлага следната формула:
CC = SC + EC + DC,
където:
CC е комплексната сложност;
SC е операторната сложност;
EC е сложност на използваните изрази;
DC е сложност на данните.
Въведени са и относителни мерки за сложност. Ако NS е броят на операторите в програмата, то съответните относителни мерки са:
RCC = CC/NS
RSC = SC/NS
REC = EC/NS
RDC = DC/NS
Относителните мерки дават възможност да се сравняват програми с различна дължина.
Операторната сложност SC на програмата е сума от операторните сложности на съставящите я оператори. За всеки тип оператор е въведена мярка за сложността му. Например:
операторът за присвояване има сложност 1;
операторите за цикъл имат сложност 3;
операторът goto има сложност 5,…
Влагането на операторите се отчита чрез коригиращ коефициент к=1.5, с който се умножава мярката за сложност на всеки вложен оператор.

Сложността на изразите EC се пресмята чрез мерки за сложността на използваните в израза операции. Например,
+, -, >, =, < имат мярка за сложност 1;
* и / имат мярка за сложност 2;
логическите операции и/или имат мярка за сложност 3, …

Сложността на данни измерва разстоянието между декларирането и използването на данните. Мярката за сложност DC за програмата е сума от мерките за сложност на използваните променливи (локални и глобални).
Приложимост
-Тази мярка може да се използва за прогнозиране на усилията за тестване и съпровождане чрез сравняване на мерките на новоразработване софтуерна система със съществуваща, за която тези усилия са документирани.
-По съществуващите в литературата примерни таблици за операторната сложност, сложността на изразите и сложността на данните метриката лесно може да се настрои така, че да може да се използва за програми, написани на език от високо ниво, като се отразят и конкретните потребителски виждания за всяка от разглежданите мерки.
Метрика за четимост
Описание – Метриката изследва различните видове документи – ръководства за потребителя, материали за обучение, спецификации, договори или оферти и спецификации при уеб дизайн или изработка на сайт, документация за web платформи, обучение и др.
Предлаганата мярка е:    F = 0.4 * (lm + plw),
където
lm – средна дължина на изречение, т.е. брой думи/брой изречения;
plw – относителният дял на дългите думи, т.е.
plw = 100 * (брой дълги думи/общ брой думи)
В българския език е прието дълги да са думите, които имат над 3 срички.
Приложимост
Мярката за четимост F отразява трудността на текста. Боем предлага мярката F да е между :
10 и 12 (10<F<12) за обикновените делови документи;
12 и 16 (12<F<16) за спецификациите, документацията и научните отчети.

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

Все още прилагането на метриките в реални софтуерни проекти е ограничено. Някои от основните причини за това са:
Участниците в софтуерните разработки нямат достатъчно добра теоретическа подготовка, за да оценят полезността на софтуерните метрики. Някои метрики (особено тези за процеси) изискват създаването на сложни модели и съответна организационна структура, осъзнаването и реализацията на които може да продължи с години.

Немислимо е използването на метрики в реалните сложни софтуерни проекти, без да са налице инструментални средства, автоматизиращи процедурите на измерване.
Метриките, измерващи програми, зависят и от програмния език, на който са написани програмите, което прави невъзможно създаването на универсални средства.
От прагматична гледна точка интерес представлява следният въпрос: Как една софтуерна организация, осъзнала, полезността на софтуерните метрики, може да изгради и внедри подходяща за нея система от метрики?

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

1. Формулирайте целта, която искате да постигнете с въвеждането на система от метрики.
2. Изберете свързаните с тази цел софтуерни обекти и съответните им характеристики.
3. Проучете какви софтуерни метрики съществуват за избраните характеристики.
4. Съставете съвкупност от тези метрики, за които може да се осигурят инструментални средства, автоматизиращи процедурите за измерване.
5. Регламентирайте и осъществете система за натрупване и анализ на данните от прилагане на метриките и определете контролен срок за експеримента.
6. След изтичане на срока въз основа на експертна оценка на резултатите от прилагане на метриките преустановете експеримента или съставете нова съвкупност от метрики чрез отпадане на някои, добавяне на нови или модифициране на съществуващи. Във втория случай се върнете към стъпка 4.

Подобни статии

• Управление на информационни ресурси
  Планирането, организирането, внедряването, функционирането и управлението на инфрастуктурите, както и на портфейла софтуерни приложения на организацията трябва да се осъществяват умело спрямо бизнес целите на организацията. Видове ресурси и тяхното управление. Основни категории...
• Система за банкови разплащания SWIFTNET – развитие, цели, използвани технологии. Функционални възможности на системата
  Използвана за първи път през 1977 г.  Използвани са телекомуникационни средства за обем на информация, отнасящи се предимно до междубанкови разплащания. Най- важна част от системата е бил т.н. „Модел FIN”. Този модел строго описва начините за обмена на съобщения. Основен принцип ...
• Софтуерни системи за управление на бизнеса, Business Process Management. Управление на бизнес процесите
  В началото на XXI век основният стремеж на всяка огранизация е да направи повече с по-малко ресурси. Постигането на тази цел изисква процесите и работните потоци да бъдат проектирани, така че да се осигурява максимална оперативна ефективност, а това е същността на концепцията упр...
• Автоматични информационни системи – рискове и заплахи към софтуера
  Риска за информационните системи е вероятността от настъпване на събитие оказващо негативно влияние върху АИС и мрежи.Риска може да бъде измерен чрез количествени показатели и може да бъде управляван във времето. За постигане на максимална сигурност е необходимо да се извършва пе...
• Хибридни програмни среди
  Програмните среди, основаващи се на няколко модела, позволяват на напредналите програмисти да експериментират с различни нови архитектури за решаване на задачи, като избират различни софтуерни модули. Поради липсата на универсален език за представяне на знания, който да е подходя...