Корекция на грешките. Коригирането, освен че
се извършва по същес-
тво, следва и да се документира. Описанието на корекцията трябва да съдържа:
разказвателно описание на корекцията;
списък на засегнатите модули от продукта;
пълна идентификация според създадената система на засегнатите доку-
менти;
евентуални промени в тестовите процедури в резултат на корекцията.
Въвеждане на корекцията в експлоатация. На практика не е възмож-
но всяка направена корекция да отива незабавно при потребителя. Затова обик-
новено се прави работен екземпляр, в който постепенно се натрупват направе-
ни корекции. В определен момент, резултат на управленско решение, се създа-
ва нова модификация на продукта, включваща всички направени корекции (а
така също подобрения и нови функционалности, ако е имало такива) и тя се
предлага официално на потребителите. Задължително се регистрира в коя мо-
дификация (или версия) всяка корекция е включена.
Регресивно тестване. Вече беше казано, че всяка корекция крие потен-
циална опасност от създаване на нови грешки. Изследвания показват, че тази
опасност е около 20%. Най-разумната възможност за отстраняването им е в
момента на откриването им те да бъдат третирани като стандартни грешки и да
бъдат отстранявани по вече описаната схема. Във всички случаи обаче описа-
нието на регресивния тест трябва да включва:
списъка на отново тестваните компоненти;
върху коя версия/модификация е направено тестването;
индикация, дали тестването е било успешно или неуспешно.
6.
Категоризация на грешките. Анализът на грешките би се улеснил, ако
те се систематизират с оглед бъдещи анализи. Близко до ума е, че категоризира-
нето ще
е най-успешно, ако се направи в момента на отстраняването на всяка
грешка. Възможни признаци за категоризация са:
тип на грешката — от изискванията, от проектирането, от програмира-
нето, от тестването;
приоритет на грешката — критична, некритична, козметична;
честота на грешката — повтаряща се, неповтаряща се.
ки периоди. При това е препоръчително грешките да се класифицират подходя-
що, например по функционални групи или по отговорни специалисти. При по-
продължително събиране на подобни данни (в рамките на повече проекти) въз-
можно е след статистическа обработка да се фиксират някакви критични грани-
ци, които биха указали например доколко е
смислено да се обучават повече,
или да се оставят на постовете им различните отговорници.
Честота на грешките. Честотата на грешките следва да се свързва с
конкретна единица — тестова процедура, програмен модул, дял от специфика-
ция. Също след статистически обработки могат да се правят изводи за латентни
грешки в тези единици.
Сложност на програмните модули. Известни са немалко метрики, ко-
ито позволяват обективно измерване на сложността на програмните единици.
При установяване на по-голяма от някаква критична стойност, може да се прис-
тъпи към опит за намаляване на сложността на тази единица.
Честота на компилациите. Въпреки че на пръв поглед тази характе-
ристика изглежда тривиална, Де Марко е показал, че програмни модули, които
са били компилирани често при създаването им, след това се компилират често
и при интеграцията и системното тестване. Така че би било оправдано за прог-
рамна единица, за която е установено, че при кодирането е била компилирана
много често, да се определи задължително процедура по оценяване.
8.2.8. Проследимост
Принципът за
проследимостта означава, че за всяка единица, създадена
по време на разработването на софтуера, трябва да може да се проследи от
каква друга единица е получена. Така например за даден алгоритъм, въплътен в
програма, следва да може да се види резултат на какво решение е по време на
проектирането или на създаването на изискванията.
Благодарение на това се
улесняват оценките и преди всичко отстраняването на грешките.
8.2.9. Планиране на ПОКС
Както всяка друга дейност при производството на софтуер програмата за
осигуряване на качеството е също обект на грижливо предварително планира-
не. Практическият съвет в това отношение е да се ползва аналогичен план от
предходна разработка. Най-малкото, с което може да бъде полезен подобен
план, е, че няма да бъдат пропуснати задължителните елементи.
8.2.7. Анализ на тенденциите
Това е пасивна и по-второстепенна дейност, но тя може да насочи към
полезни корективи. Състои се в анализиране на определени страни от софтуер-
ния процес и изготвяне на съответни отчети.
1.
Количество на грешките. Възможно е да се събират данни за количес-
твото грешки както за целия период на разработването,
така и за отделни крат-
98
8.2.10. Социални фактори
Все по-често се обръща внимание на социалните елементи, начина на об-
щуване на ръководителите с подчинените и с клиентите, мотивацията на разра-
ботчиците. Доколкото осигуряването на качеството е особено силно свързано
с общуването между членовете на екипа, често при противопоставящи роли е
необходимо да се обърне внимание и на този елемент от софтуерния процес.
99