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



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

M1. Метрика за размера на програма

I. Описание

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

За мярка на размера на програма се избира броят програмни редове в из-


ходния текст на програмата.

L = L1 + L2


където

L — общ брой редове;

L1 — коментарни и празни редове;

L2 — същински програмни редове.

Метриката е адитивна.

II. Приложимост



  1. Броят на грешките, усилията за разбиране, поддържане и съпровождане
    са правопропорционални на размера на програмите [3, 4].

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

Примерна класификация е дадена в [3, 4]. Граничните стойности могат да
се определят експериментално или да се задават за всеки софтуерен проект.

3. L е най-проста мярка за извършената от програмиста работа.

87

M2. Метрика на Маккейб за структурна (цикломатична) сложност

I. Описание

Метриката на Маккейб [5] е за програми (обекти от тип „продукт"). Тя е
статична и измерва сложността на потока на управление в програмата. Тази
метрика е една от най-често цитираните в литературата.

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


мата, в който върховете са отделните оператори (или линейни участъци) и два върха
са свързани с ребро, ако има предаване на управление между съответните оператори.

Тогава


  • (G) = е — n + 2 * р,
    където:

  • (G) е цикломатичната сложност, представляваща максималния брой ли-
    нейно-независими пътища в програмата;

е — брой ребра в управляващия граф;

n — брой върхове в управляващия граф;

р — брой на свързаните компоненти в графа.

Разработени са инструментални средства за автоматично изчисляване на


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

Недостатъци на метриката са, че не отчита дължината на линейните участь-


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

Разширение на тази метрика е метриката на Гонг—Шмид [6], която пред-


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

С (G) = V (G) + Е,

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

II. Приложимост

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

Препоръчва се да се проектират модули с цикломатична сложност V < 10


като се смята, че модулите със сложност до 10 са прости, до 20 — средно слож-
ни, от 30 до 50 — сложни, а при сложност над 50 трябва да се обмисли прест-
руктуриране (разделяне на няколко модула).

M3. Метрика на Холстед за текстуална сложност

I. Описание

Статична метрика за програма, написана на произволен език за програми-
ране. Предложена е от Холстед през 1976 г. [7] и е метриката, за която има най-
много публикации.

Програмата се разглежда като състояща се от активни елементи (операто-


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

За прилагане на метриката се определят:

88

— брой различни оператори;



— брой различни операнди;
N1 — общ брой оператори;

N2 — общ брой операнди.

Чрез тези оценъчни елементи се изчисляват:

Речник: n = n1 + n2

Дължина на програмата: N = N1 + N2

Изчислена дължина на програмата:

N = n1* log2 * n1 + n2 log2 n2

Обем на програмата: V = (N1 + N2) * log2 (n1+ n2)

Трудност на програмата: D.= (n1 / 2) * (N2 /n2)

Ниво на програмата: L = 1 / D

Усилия за създаване на програмата: Е = V * D

Преброяването на n1, n2, N1 и N2, както и изчисляването на метриките за


гореописаните свойства, може да се извършва от инструментално средство (спе-
циализиран лексически анализатор).

II. Приложимост

1. Могат да се оценяват усилията за създаване на програмата. В [8] се
предлага за оптимална сложност на програма стойността Еоp = 60 800 и за мак-
симална Emax = 129 600.

Сравняването на Е за конкретна програма с тези две стойности дава въз-


можност да се класифицират усилията за разработването й като малки, средни
или големи.

2. Може да се оцени времето за програмиране чрез използване на индекса


на Страуд за интензивност на интелектуалните занимания, който за програми-
рането има стойност S = 18. Така

T = E/S = E/18



  1. Гордън доказва [9], че усилията за създаване на нова програма са срав-
    ними с усилията за разбиране на съществуваща. Този факт често се използва за
    предварителна оценка на усилията за съпровождане в случаите, когато то не се
    осъществява от разработчиците.

  2. В [8] се предлагат формули за предварително оценяване на броя на отк-
    риваните грешки:

В, = V / 3000 — брой грешки, откривани при изпитанията;
В2 = 4 * B1 = V / 750 — общ брой грешки, открити през жизнения цикъл на
програмата.

5. В [10] се обосновава възможността усилията за тестване да се оценяват чрез


произведението NX * Е, където NX e индекс за ниво на влагане (индикатор за
необходимия брой тестове), а Е е мярката на Холстед за усилията на разработване.

Някои от предлаганите мерки не са очевидни и за разбирането им е необ-


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

89

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



I. Описание

Метриката на Рехенберг [11] е опит за преодоляване на едностранчивостта |

на съществуващите метрики за сложност. Тя е статична, комплексна метрика,

която може да се прилага за програми или програмни системи, написани на |

произволен език за програмиране от високо ниво. |

Рехенберг предлага следната формула:

СС = SC + EC + DC,
където:

СС е комплексната сложност;

SC — операторна сложност;

ЕС — сложност на използваните изрази;

DC — сложност на данните.

Въведени са и относителни мерки за сложност. Ако NS е броят на операто-


рите в програмата, то съответните относителни мерки са:

RCC = CC/NS


RSC = SC/NS
REC = EC / NS
RDC = DC / NS

Относителните мерки дават възможност да се сравняват програми с раз-


лична дължина.

Операторната сложност SC на програмата е сума от операторните слож-


ности на съставящите я оператори. За всеки тип оператор е въведена мярка за
сложността му. Например операторът за присвояване има сложност 1, операто-
рите за цикъл — 3, операторът goto — 5 и т. н. Влагането на операторите се
отчита чрез коригиращия коефициент к = 1.5, с който се умножава мярката за
сложност на всеки вложен оператор.

Сложността на изразите ЕС се пресмята чрез мерки за сложността на из-


ползваните в израза операции. Например операциите „+" и „—" и операциите
за сравнение „>", „=", „<" имат мярка за сложност 1. Операциите „*" и ,/" имат
мярка за сложност 2, логическите операции и/или имат стойност 3 и т. н.

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


зването на данните. Мярката за сложност DC за програмата е сума от мерките
за сложност на използваните променливи (локални и глобални).

II. Приложимост

По описаните в [11] примерни таблици за операторната сложност, слож-
ността на изразите и сложността на данните лесно може да се настрои метрика-
та така, че да може да се използва за програми, написани на език от високо
ниво, като се отразят и конкретните потребителски виждания за всяка от разг-
лежданите мерки.

Мярката на Рехенберг може да се използва за прогнозиране на усилията за


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

90

M5. Метрика за четимост

I. Описание

Обект на изследване са различни видове документи — ръководства за пот-
ребителя, материали за обучение, спецификации и др. [12].

Предлаганата мярка е

F = 0.4 * (lm + plw ),
където

lm е средна дължина на изречение, т. е. брой думи/брой изречения;

plw — относителен дял на дългите думи, т. е.

брой дълги думи


plw = * 100

общ брой думи


В българския език е прието дълги да се наричат думите с над 3 срички.

II. Приложимост

Мярката на четимост F отразява трудността на текста.

Боем [13] предлага мярката F да е

10 < F <12
за обикновените делови документи и

12за спецификации, документация и научни отчети.

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

Съществуват много софтуерни метрики (библиографията в [1] е почти из-


черпателна) и затова интерес представлява изследването на връзките между тях.
Изключително важен е резултатът от сравняване на някои метрики за програми.
Оказва се, че могат да прилагат три основни метрики — за размер, метриката на
Рехенберг за относителна сложност и метриката на Маккейб за структурна слож-
ност, а много други мерки могат да се изведат от резултатите, получени само от
тези метрики. Засега това е хипотеза след статистически експерименти, която
си струва да бъде изследвана и с формални методи.

7.5. Методологични проблеми на използването на
софтуерните метрики

Конструирането на нови метрики, доказване на валидността на съществу-


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

Някои от основните причини за това са:

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

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


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

91

Метриките, измерващи програми, зависят силно и от езика, на който са написа-


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

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



  1. Формулирайте целта, която искате да постигнете с въвеждането на сис-
    тема от метрики (вж. част 3. от класификация А).

  2. Изберете свързваните с тази цел софтуерни обекти и съответните им
    характеристики.

  3. Проучете (или възложете проучването на специалист) какви софтуерни
    метрики съществуват за избраните характеристики.

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

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

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

Литература

  1. Fenton N. Software Metrics — A Rigorous Approach. Chapman & Hall, London, 1991

  2. Kitcheman B. Software metrics in Software Reliability Handbook (ed. by P.Rook), London,
    Elsevier, 1990.

  3. Йенсен, P., Ч.Тониз. Технология на програмирането. Техника, София, 1987.

  4. Липаев В. Качество программного обеспечения. M., Финанси и статистика, 1983.

  5. McCabe Т. A complexity measure. IEEE Transactions on Software Engineering, SE-2,1976,
    pp. 308—320.

  6. Gong, H., M.Schmidt. A complexity Measure Based on Selection and Nesting. ACM SIG-
    METRICS,Nov.l983.

  7. Halstead M.H. Elements of Software Science. New York, Elsevier, 1977.

  8. Hocker, H. et al. Comparative Descriptions of Software Quality Measures. GMD-Studien
    Nr.81,1984.

  9. Gordon R.D. Measuring Inprovements in Program Clarity. IEEE Trans, on SE, SE-5(2) 1979
    pp. 79—90.




  1. Budde et al. Untersuchungen ueber Massnahmen zur Verbesserrung der Software Production,
    Teil 1, Bericht Nr. 130 der Gesellschaft fuer Mathematik und Datenverarbeitung. Munchen-
    Wien, Oldenbourg Verlag, 1980.

  2. Rechenberg P. Ein neues Massfuer die softwaretechnische Komplexitaet von Programmen.
    Informatik Forsch. Entw. Nr. 1,1986, pp. 26— 37.

  3. Gunning R. Technique ofClear Writing. New York, Mc Graw Hill, 1968.

  4. Boehm et al. Characteristics ofSoftware Quality. TRW Series ofSoftware Technology, vol. 1,
    North Holland, 1978.

92

8.УПРАВЛЕНИЕ НА КАЧЕСТВОТО

8.1. Проблемът за управление на качеството

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


дукт. Производството на софтуер, както видяхме в глава 2. и специално в 2.3.8.,
е резултат на процес. Този процес има свои характеристики, които могат да
имат различна степен на съвършенство. Следователно може да се говори за
качество и на софтуерния процес. Близко до ума е, че при по-добро качество
на софтуерния процес по принцип трябва да се очаква и по-добро качество на
софтуерния продукт. Например, ако процесът на планиране и създаване на тес-
товите данни за определен програмен продукт се извърши грижливо и компе-
тентно, т. е. с високо качество, може да се очаква, че продуктът ще има по-
висока стойност на фактора надеждност.

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


же да не се свърже с планирането и прилагането на подходящи мерки през целия
производствен цикъл. Това е изразено много точно в [1] по следния начин:

"Качеството е едновременно философия и съвкупност от ръководни прин-


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

фундаментални техники за управление,

постоянни усилия за усъвършенстване,

технически средства,


всичко това в рамките на един дисциплиниран и целенасочен метод."

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


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

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


с всяка негова фаза. Планирането му следва да се извърши още в началните
фази и да обхваща всички следващи фази. Всеки междинен продукт, резултат от
дадена фаза, заедно със своите характеристики следва да бъде точно дефини-
ран. На тази основа следва да се предвидят начини за обективно установяване

93

доколко удовлетворително е реализиран този междинен продукт (за крайния


продукт казаното се подразбира). За да се осъществи тази дейност по един сис-
тематичен и ефективен начин, теорията препоръчва да се изработи програма за
осигуряване на качеството на софтуера (ПОКС).

8.2. Компоненти на програмата за осигуряване на качеството

8.2.1. фактори

Няколко фактора оказват важно влияние върху ПОКС [7]. Без да се впус-


каме в подробности, ще ги изброим:

  • изисквания към графика;

  • разполагаемия бюджет;

  • технологичната сложност на продукта;

  • предполагаемия размер на продукта;

  • относителния опит на разработчиците;

  • хардуерните и софтуерните ресурси, предвидени за процеса на разра-
    ботване;

  • изискванията на договора за възлагане.

В момента на създаването на ПОКС трябва да се анализира и установи
доколко всеки от горните фактори (а евентуално и някои други) ще й окаже
влияние.

8.2.2. Прегледи

Под преглед (review) ce разбира дисциплинирана групова дейност, на-
сочена към изследване на продукт или процес. Ефективното изпълнение на
прегледа изисква умело съставяне на групата с оглед комбиниране различните
необходими квалификации. Отличават се 3 вида прегледи:

A. Пробег (walkthrough). Това е неформален преглед на софтуерния про-


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

Б. Инспекция (Inspection). Това е дисциплиниран формален преглед на

всякакъв тип продукти.

B. Проверка на конфигурацията (Configuration Audit). Много често край-


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

B.1. Функционални. Основната цел на функционалните проверки е да пре-


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

94

B.2. Физически. Тази категория проверки се съсредоточава върху съот-


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

8.2.3. Оценяване

Оценка се прави обикновено от един специалист. Целта й е да се установи


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

1. Изисквания към продукта. Дори и в използвания модел на жизнения


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

  • плана за разработване на продукта;

  • софтуерните стандарти;

  • плана за управление на софтуерната конфигурация;

  • плана за осигуряване на качеството;

  • спецификацията на изискванията към продукта;

  • спецификацията на изискванията към интерфейса.

2. Общо проектиране. Както известно, на този етап изискванията се кон-
кретизират и уточняват, а така също потребителският възглед започва да се тре-
тира от гледна точка на реализацията. Съответни на това са и оценките на:

  • всички ревизирани производствени планове;

  • плана за тестването на софтуера;

  • ръководството за оператора;

  • ръководството за потребителя;

  • ръководството за диагностика,

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

3. Подробно проектиране. Резултатите от този етап са подробни специ-


фикации, на основата на които може да бъде извършено програмирането (коди-
рането) на продукта. Тук се предвижда оценяване на:

  • текущо ревизираните планове — отново;

  • документа — изход от подробното проектиране;

  • документа — проект на интерфейса;

  • документа — проект на базата данни;

  • тестовите примери за проверка на отделните модули;

  • тестовите примери за проверка на интегрираните модули;

  • описанието на процедурите по тестване;

  • ръководството за програмиста;

  • останалите ръководства в новото им състояние.

4. Програмиране и тестване на отделните модули. Както е известно,

95

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


зации. През цялото време се извършват оценки на:

  • плановете, доколкото търпят промени — както на всеки етап;

  • написания първичен код;

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

  • всички ръководства.

5. Интегриране и тестване. Написаните и проверени отделни модули
започват да се интегрират, което изисква оценяване на:

  • текущо ревизираните планове;

  • резултатите от тестването на интегрирането;

  • актуализирания първичен код;

  • описанието на приемните тестове;

  • всички ръководства.

6. Тестване на крайния продукт. Тук се оценяват:

  • текущо ревизираните планове;

  • всички ръководства;

  • актуализираният първичен код;

  • документът за описание и управление на версиите;

  • докладът за тестване на крайния продукт (системата).

8.2.4. Типове оценки

Добре е известно, че софтуерът за военни цели изисква особена надежд-


ност и други високи качества. Поради тези причини при създаването на такъв
софтуер се полагат особено сериозни мерки за осигуряване на качеството, ка-
то специално се набляга на оценяването. Във връзка с това Министерството на
отбраната на САЩ има приет стандарт — DOD-STD-2168 Software Quality
Program. B него се фиксират типовете оценки, които следва да се правят при
производството на всеки програмен продукт. По-важните от тях следват:

  • съблюдаване на изисквания формат и стандарти за документацията;

  • съответствие с изискванията на договора за разработка;

  • вътрешна непротиворечивост;

  • добра разбираемост;

  • система за лесно намиране на пътя до всеки документ;

  • съответствие на продукта с придружаващите го документи;

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

  • правилно разпределение на ресурсите — по време и памет;

  • адекватно проведено тестване за съответствие на продукта с изисквани-
    ята;

  • адекватно съставени тестови примери;

  • пълнота на тестването;

— пълнота на регресивното тестване (този проблем беше разгледан по­ горе в 8.2.2., т. B1 — тук се им предвид, че едни и същи тестове, проведени в
начални стадии и довели до отстраняване на грешки, следва да се провеждат
отново на по-късни етапи с цел избягване на грешки, резултат от корекции);

96

— съответствие и непротиворечивост между дефинициите на данните и


тяхното използване.

8.2.5. Управление на конфигурацията

Управлението на софтуерната конфигурация обхваща методи и техноло-


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

Общо взето, при по-малки проекти, реализирани от малки фирми, не се


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

  • поддържане целостността на продукта;

  • напълно контролирано управление на промените;

  • управление и контрол на версиите;

  • планиране на управлението на конфигурацията.

8.2.6. Отчитане на грешките

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


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

Поради тази причина подържането на ефективна система за регистриране


на грешките с оглед последващото им отстраняване е абсолютна необходимост.
Такава система трябва да е действена в следните насоки:

1. Идентификация на грешките. Всяка идентифицирана грешка трябва


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

97


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

  2. Корекция на грешките. Коригирането, освен че се извършва по същес-
    тво, следва и да се документира. Описанието на корекцията трябва да съдържа:




  • разказвателно описание на корекцията;

  • списък на засегнатите модули от продукта;

  • пълна идентификация според създадената система на засегнатите доку-
    менти;

  • евентуални промени в тестовите процедури в резултат на корекцията.




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

  2. Регресивно тестване. Вече беше казано, че всяка корекция крие потен-
    циална опасност от създаване на нови грешки. Изследвания показват, че тази
    опасност е около 20%. Най-разумната възможност за отстраняването им е в
    момента на откриването им те да бъдат третирани като стандартни грешки и да
    бъдат отстранявани по вече описаната схема. Във всички случаи обаче описа-
    нието на регресивния тест трябва да включва:




  • списъка на отново тестваните компоненти;

  • върху коя версия/модификация е направено тестването;

  • индикация, дали тестването е било успешно или неуспешно.

6. Категоризация на грешките. Анализът на грешките би се улеснил, ако
те се систематизират с оглед бъдещи анализи. Близко до ума е, че категоризира-
нето ще е най-успешно, ако се направи в момента на отстраняването на всяка
грешка. Възможни признаци за категоризация са:

  • тип на грешката — от изискванията, от проектирането, от програмира-
    нето, от тестването;

  • приоритет на грешката — критична, некритична, козметична;

  • честота на грешката — повтаряща се, неповтаряща се.

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

  1. Честота на грешките. Честотата на грешките следва да се свързва с
    конкретна единица — тестова процедура, програмен модул, дял от специфика-
    ция. Също след статистически обработки могат да се правят изводи за латентни
    грешки в тези единици.

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

  3. Честота на компилациите. Въпреки че на пръв поглед тази характе-
    ристика изглежда тривиална, Де Марко е показал, че програмни модули, които
    са били компилирани често при създаването им, след това се компилират често
    и при интеграцията и системното тестване. Така че би било оправдано за прог-
    рамна единица, за която е установено, че при кодирането е била компилирана
    много често, да се определи задължително процедура по оценяване.

8.2.8. Проследимост

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


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

8.2.9. Планиране на ПОКС

Както всяка друга дейност при производството на софтуер програмата за


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


8.2.7. Анализ на тенденциите

Това е пасивна и по-второстепенна дейност, но тя може да насочи към


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

1. Количество на грешките. Възможно е да се събират данни за количес-


твото грешки както за целия период на разработването, така и за отделни крат-

98

8.2.10. Социални фактори

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

99


!.Точност. Абсолютната точност на представянето на данните от всяка
оценка или друга дейност по осигуряването на качеството е задължителна. Прак-
тиката показва, че най-ефективната защита на контролираните срещу искания
на контролиращите, например за извършване на промени, е позоваване на не-
точност на данните. При това обикновено се цитират прецеденти и доколкото
почти винаги времето за подробно разглеждане и доказване на представените
данни не е достатъчно, такова позоваване се оказва достатъчно. Единственият
начин за противопоставяне е просто да не се създава нито един прецедент за
неточност.

  1. Авторитет. Обикновено отговорниците по осигуряване на качеството
    получават значителни пълномощия от ръководството на фирмата. Както и в други
    дейности обаче, знае се, че истинският авторитет е много no-малко резултат на
    административни мерки, отколкото на доказвана непрестанно лична компетен-
    тност.

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

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

  4. Постоянство. He e възможно да се запази доверието, ако концепциите
    и произлизащите от тях решения се променят често. В такива случаи скоро идва
    момент, от който нататък нарежданията просто не се изпълняват в очакване на
    последваща промяна.

6. Отмьстителност. Лице, отговарящо за осигуряване на качеството,
нерядко ще се сблъсква с волни или неволни нарушения. Те биха му дали въз-
можност при следващи случаи да се изкуши да се възползва от създалото се
предимство пред нарушителя. Ясно е, че такава злонамереност е вредна за об-
щата атмосфера и за ефективността на работата във фирмата.

8.3. Оценяване на софтуерните процеси

8.3.1. Методологията SEIСММ

Изграждането на такава организация на процесите, която да осигурява


ефективното и навременно създаване на качествен софтуер се нуждае и от неп-
рекъснато обективно оценяване на достигнатото равнище. В края на 80-те го-
дини [2], [3] в Института по софтуерни технологии в Питсбърг (САЩ) (Software

100


Engineering Institute (SEI), Carnegie Melon University, Pittsburgh) се обявяват
конструктивни изследвания в тази насока, които по-късно се развиват, прила-
гат в практиката и оказват силно влияние върху теоретиците и практиците в цял
свят. Основният продукт на тези изследвания е моделът за оценяване на зре-
лостта — Capability maturity model СММ [4]. Този модел е предназначен за:

  • подобряване на софтуерните процеси;

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

  • оценяване от подготвени експерти на способността на потенциални из-
    пълнители на даден софтуерен*проект.

Оценяването се извършва по точно определена схема на основата на 150
въпроса,
отговорите на които са „да" или „не". Пример за такъв въпрос е:„Има
ли във вашата фирма формално организирана система за осигуряване на качес-
твото?"

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

СММ е получил широко разпространение, защото:



  • основан е на реалната практика;

  • отразява най-добрите постижения на тази практика;

  • съобразява се с нуждите на участниците в софтуерния процес и него-
    вото оценяване и подобряване;

  • документиран е добре;

достъпен е за широката публика.
Структура

СММ се състои от 5 нива на зрелост (maturity levels). Нивото на зрелост


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

Всяко ниво на зрелост се състои от ключови области на обработка (key


process areas), c изключение на ниво 1. Всяка ключова област съдържа група
свързани дейности, които, изпълнени съвместно, водят до постигане на целите,
смятани за съществени за това ниво на зрелост. Например една от ключовите
области на обработка на ниво 2 е „Планиране на софтуерния проект".

Всяка ключова област се състои от 5 секции общи характеристики


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

На следващото ниво са т. н. ключови практики (key practices), чрез които


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

Схематично това е показано на фиг. 8.1.



Нива на зрелост

101


програма могат да бъдат видени, но логическата същност на програмата, особе-
но ако е по-голяма, няма как да бъде „видяна", още по-малко — цялостната
структура на комплекс от програми. Това е смисълът на твърдението, че софту-
ерът е на много високо ниво на абстрактност.

лемите на общуването в рамките на колектива, разработващ програмен про-


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


1.2.3. Уникалност на софтуерното производство

Много често хората са склонни да мислят себе си или нещата, с които се


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

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

  • ако има грешка в даден програмен продукт (а безгрешен софтуер, както
    е известно, няма), то тя се отнася до всички негови копия; при автомобилите
    този случай е твърде рядък или поне не е типичен — там дефектите могат да
    бъде разнообразни, но, общо взето, са индивидуални — за всеки конкретен
    автомобил;

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

1.2.4. Мултидисциплинарност на разработването на софтуер

Отделните програмни продукти са изключително разнообразни по пред-


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

12

1.2.5. Специфични проблеми на надеждността

Вече беше споменат известният на всички програмисти факт, че абсолют-
но безпогрешен софтуер няма. Разбира се, малка програма с линеен характер и
еднообразни входни данни вероятно би могла да бъде проверена докрай. Ти-
пичният програмен продукт обаче никога не може да бъде абсолютно гаранти-
ран срещу грешки. Причината за това е известна — прекалено много са въз-
можните пътища през програмата, допустимите (и недопустими) съвкупности
от данни, да не говорим за действията от страна на потребителя, които наистина
не могат да бъдат изцяло предвидени. Следователно, дори да разполага с много
време, пари и други ресурси, разработчикът едва ли би бил в състояние да дока-
же абсолютна липса на грешки в предлагания програмен продукт. Естествено,
съществуват чисто теоретически методи, гарантиращи пълна безпогрешност на
програмата, но те са засега приложими само към прекалено тривиални програ-
ми. Има разработени и технологии за тестване и отстраняване на грешки, които
обаче поне от теоретическа гледна точка не могат да гарантират пълна липса на
грешки. Да не говорим за иначе много добрата в други отношения обектно-
ориентирана технология, при която за съжаление все още няма и теоретически
възможности за доказване на безпогрешност на програмите.

Няма да се спираме на отдавна станалите анекдотични примери за програ-


мата, която работила безпогрешно х години и изведнъж сгрешила (което е на-
пълно възможно), или за онази 0 вместо 1 в програмата, управляваща космичес-
ка ракета, довела до преждевременно прекратяване на полета. Ежедневно сме
свидетели на програмни продукти, разработени и продавани в стотици хиляди и
милиони екземпляри от световни фирми, в които изскача по някоя грешка.

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


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

1.2.6. Рискове

Производството на софтуер в много повече случаи, отколкото това става в


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


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


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

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