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

I. Описание

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

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

L = L₁ + L₂

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

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

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

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

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

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

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

87

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

I. Описание

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

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

Тогава

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

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

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

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

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

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

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

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

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

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

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

I. Описание

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

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

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

88

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

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

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

Речник: n = n₁ + n₂

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

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

N = n₁* log₂ * n₁ + n₂ log₂ n₂

Обем на програмата: V = (N₁ + N₂) * log₂ (n₁+ n₂)

Трудност на програмата: D.= (n₁ / 2) * (N₂ /n₂)

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

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

Преброяването на n₁, n₂, N₁ и N₂, както и изчисляването на метриките за

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

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

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

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

T = E/S = E/18

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

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

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

89

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

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

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

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

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

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

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

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

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

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

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

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

RCC = CC/NS

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

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

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

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

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

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

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

I. Описание

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

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

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

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

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

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

общ брой думи

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

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

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

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

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

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

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

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

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

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

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

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.
   

10. 
    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.
    
11. 
    Rechenberg P. Ein neues Massfuer die softwaretechnische Komplexitaet von Programmen.
    Informatik Forsch. Entw. Nr. 1,1986, pp. 26— 37.
    
12. 
    Gunning R. Technique ofClear Writing. New York, Mc Graw Hill, 1968.
    
13. 
    Boehm et al. Characteristics ofSoftware Quality. TRW Series ofSoftware Technology, vol. 1,
    North Holland, 1978.
    

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

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

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

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

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

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

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

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

93

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

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

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

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

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

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

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

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

94

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

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

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

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

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

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

• 
  текущо ревизираните планове — отново;
  
• 
  документа — изход от подробното проектиране;
  
• 
  документа — проект на интерфейса;
  
• 
  документа — проект на базата данни;
  
• 
  тестовите примери за проверка на отделните модули;
  
• 
  тестовите примери за проверка на интегрираните модули;
  
• 
  описанието на процедурите по тестване;
  
• 
  ръководството за програмиста;
  
• 
  останалите ръководства в новото им състояние.
  

95

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

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

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

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

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

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

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

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

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

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

96

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

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

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

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

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

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

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

97

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

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

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

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

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

2. 
   Честота на грешките. Честотата на грешките следва да се свързва с
   конкретна единица — тестова процедура, програмен модул, дял от специфика-
   ция. Също след статистически обработки могат да се правят изводи за латентни
   грешки в тези единици.
   
3. 
   Сложност на програмните модули. Известни са немалко метрики, ко-
   ито позволяват обективно измерване на сложността на програмните единици.
   При установяване на по-голяма от някаква критична стойност, може да се прис-
   тъпи към опит за намаляване на сложността на тази единица.
   
4. 
   Честота на компилациите. Въпреки че на пръв поглед тази характе-
   ристика изглежда тривиална, Де Марко е показал, че програмни модули, които
   са били компилирани често при създаването им, след това се компилират често
   и при интеграцията и системното тестване. Така че би било оправдано за прог-
   рамна единица, за която е установено, че при кодирането е била компилирана
   много често, да се определи задължително процедура по оценяване.
   

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

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

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

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

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

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

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

98

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

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

99

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

2. 
   Авторитет. Обикновено отговорниците по осигуряване на качеството
   получават значителни пълномощия от ръководството на фирмата. Както и в други
   дейности обаче, знае се, че истинският авторитет е много no-малко резултат на
   административни мерки, отколкото на доказвана непрестанно лична компетен-
   тност.
   
3. 
   Полза. По принцип ефективната работа по осигуряване на качеството
   води до обща полза за всички участници в процеса на разработване. От друга
   страна обаче, в краткосрочен и индивидуален план много често това не е така,
   защото на даден програмист например му се налага да прави корекции, които
   смята за ненужни и които му отнемат допълнително време и усилия. Още по-
   характерен и направо типичен пример са исканията към отделните изпълните-
   ли, свързани с изготвяне на документация и спазване на стандарти. В този сми-
   съл ръководителят и другите експерти по осигуряване на качеството имат за
   задача да мотивират засегнатите от мерките изпълнители, като ги убеждават в
   общата полезност на такива мерки.
   
4. 
   Комуникации. Както вече се каза, осигуряването на качеството в голяма
   степен като схема е натрупване и разпространяване на информация. Формите
   за това са обикновено речеви и писмени в различни модификации. Откъдето
   следва, че отговорните за осигуряване на качеството трябва да са комуникатив-
   ни личности, умеещи добре да се изразяват говоримо и писмено.
   
5. 
   Постоянство. 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. Рискове

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

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