8.2.4. Типове оценки Добре е известно, че софтуерът за военни цели изисква особена надежд-
ност и други високи качества. Поради тези причини при създаването на такъв
софтуер се полагат особено сериозни мерки за осигуряване на качеството, ка-
то специално се набляга на оценяването. Във връзка с това Министерството на
отбраната на САЩ има приет стандарт — DOD-STD-2168 Software Quality
Program. B него се фиксират типовете оценки, които следва да се правят при
производството на всеки програмен продукт. По-важните от тях следват:
съответствие с изискванията на договора за разработка;
вътрешна непротиворечивост;
добра разбираемост;
система за лесно намиране на пътя до всеки документ;
съответствие на продукта с придружаващите го документи;
коректно извършен анализ на изискванията, проектиране и програми-
ране (тук следва да се отбележи, че всъщност се прави оценка не на атрибути на
продукта, а на качества на процеса);
правилно разпределение на ресурсите — по време и памет;
адекватно проведено тестване за съответствие на продукта с изисквани-
ята;
адекватно съставени тестови примери;
пълнота на тестването;
— пълнота на регресивното тестване (този проблем беше разгледан по горе в 8.2.2., т. B1 — тук се им предвид, че едни и същи тестове, проведени в
начални стадии и довели до отстраняване на грешки, следва да се провеждат
отново на по-късни етапи с цел избягване на грешки, резултат от корекции);
96
— съответствие и непротиворечивост между дефинициите на данните и
тяхното използване.
8.2.5. Управление на конфигурацията Управлението на софтуерната конфигурация обхваща методи и техноло-
гии за иницииране, оценяване и управление на измененията в софтуерния про-
дукт след пускането му в експлоатация. Необходимите промени се правят не
само в първичния код, но така също в документацията — вътрешна (съпровож-
даща) и потребителска, в отчетите за тестване, в отчетите за откритите грешки.
Следят се и се документират последователно създаваните версии и движението
им сред различните потребители.
Общо взето, при по-малки проекти, реализирани от малки фирми, не се
отделят специални усилия управлението на конфигурацията да се върши по
един системен, добре формализиран и документиран начин. Това впрочем е
лесно обяснимо. Но ако един екип от 3 души е в състояние да помни историята
на развитието на даден продукт наизуст или с малко неформални документи, то
от известно място нататък (по отношение на мащаба на продукта и на колекти-
ва) такъв подход е невъзможен. Ето основните функции по управления на кон-
фигурацията, които са решаващи за запазване качеството на продукта след вли-
зането му в експлоатация:
поддържане целостността на продукта;
напълно контролирано управление на промените;
управление и контрол на версиите;
планиране на управлението на конфигурацията.
8.2.6. Отчитане на грешките Добре известна истина е, че и в най-прецизно тествания софтуер след пус-
кането му в експлоатация се откриват непрекъснато грешки. Все още сме много
далече от възможността да се докаже математически строго липсата на грешки в
дадена програма. За програми, писани на процедурни езици, има поне теорети-
ческа яснота, как това би могло да стане, за обектно ориентираните — дори и
това не е ясно.
Поради тази причина подържането на ефективна система за регистриране
на грешките с оглед последващото им отстраняване е абсолютна необходимост.
Такава система трябва да е действена в следните насоки:
1. Идентификация на грешките. Всяка идентифицирана грешка трябва
да се опише ясно и точно. Може да се опише както поведението на продукта в
дадената ситуация, така и реалният дефект в софтуера. Във всички случаи опи-
санието трябва да бъде разбираемо както за хора, които не са се занимавали с
правенето на продукта, така и с оглед на това, че обикновено е минало вече
време от разработването и дори лица, които са участвали пряко в работата,
постепенно са загубили подробна представа за направеното. Впрочем така под-
готвената информация е необходима не само за конкретното отстраняване на
грешката, но и за по-системни анализи на типовете грешки.
97
Анализ на грешките. Трябва да се документира сериозността на грешката
и трудността на нейното отстраняване. Това ще позволи правилно заделяне на не-
обходимия ресурс, определяне на приоритет и график за корекция. Обикновено
грешките се откриват сравнително лесно, често те просто се набиват на очи, но тъй
като отстраняването им невинаги е лесно, налага се да се вземат управленски реше-
ния, свързани с приоритета им. Впрочем отделянето във времето на анализа от
корекцията обуславя разглеждането им като отделни и независими операции.