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