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

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

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

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

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

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

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

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

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

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

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

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

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

Модели са необходими не само в областта на софтуерните технологии. Целта на конструктивните дисциплини е да се отговори на три основни въпроса:

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

как го правим - с какви операции си служим, какви са техните характеристики;

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

Всеки модел се характеризира с три особености:

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

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

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

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

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

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

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

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

Възможни са най-различни класификации. Тази, която следва, се опитва да обхване почти всички по-известни модели на ЖЦ на ПП, като се стреми да отрази определящия ги признак. Към типовете ЖЦ в скоби са дадени по един или повече примера за съответния тип. Изрично трябва да се отбележи, че посочените като примери ЖЦ са на най-различно равнище на разработеност.

КЛАСИФИКАЦИИ

1.Пълни

1.1.Едномерни

1.1.1. Хронологични

Стандартни (Боем, Метцгер, Фрийман)

Модифицирани (каскаден, прототипен)

Разклонени (Фокс)

1.1.2. Функционален (Хамилтън-Зелдин)

1.2. Многомерни

Двумерни (Гънтър)

Тримерни (Питърс-Трип)

Еволюционни

Спирални

2. Частични - за повторно използване (Епълтън)

3. Тук ще разгледаме най-общо типовете модели на ЖЦ. като следваме дадената по-горе класифи-кация. Редът на класифи-кацията на тези модели, които представляват пове-че теоретичен интерес - било поради това, че са твърде абстрактни, било поради това, че вече са твърде остарели и са интересни най-вече от гледна точка на просле-дяване развитието на идеите за моделиране на ЖЦ на ПП. Модела на Гънтър е най-интересен, от една страна е твърде подробно разработен, а от друга - твърде всестранно пред-ставя ЖЦ на ПП. Основният му недостатък е, че някои от конкретните числови стойности в него вече не обхващат увеличилото се разнообра-зие от типове софтуер.

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

Най-характарният пример за функционален модел е разработеният от Хамилтън и Целдинл, най-същественият признак, по който следва да се декомпозира ЖЦ на ПП, е типът извършвани дейности. Такава група от приличащи си дейности по този модел се нарича ф-ция. Дефинирането на проблема би следвало да дойде от взаимодействи-ето на потреб с разра-ботчика. Анализът пред-ставлява изясняване на проблема и избиране на р-ние в най-общия му вид. Тук се вкл планирането и разпределението на вся-какви ресурси, необходими за изпълнението на разработката - човешки, хардуерни, софтуерни, документационни и пр.

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

Този модел се е използвал реално - на негова основа е бил разработено инструментално програмно средство (ПП) под името USEIT.

Разклонен модел на Фокс е също особен модел. Той отразява гледната точка на един известен специалист с огромен практически опит от разработването на много големи софтуерни системи. В този модел се отделя особено внимание на дейностите по съпровождането. В този смисъл Фокс като че ли изпреварва своето време. Самият Фокс твърди, че терминът съпровождане" не е подходящ и използва поддържане". Като важен принос на Фокс следва въведената от него успоредност на две от фазите. Безпроблемното използване зависи силно от вложените усилия при разработването. Съпровождането според Фокс може да отнеме при големи ПП толкова усилия, колкото и разработването.

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

Тримерен модел на Питърс-Трип представлява само теоретически инте-рес. Той е опит да се обхванат заедно различни страни на процеса на разработване на софтуер, но като че ли третото въведено измерение, свър-зано с използваните фор-мални апарати, няма прак-тическо значение. Време, това е вече срещаната хронологическа компонен-та и тя отразява разви-тието във времето на ПП. Вероятно поради това, че чрез останалите две компоненти се допринася за по-пълното описание на ЖЦ на ПП, тук се отличават само 4 фази - анализ на системата (ПП), проектиране, реализация и експлоатация.

Логиката, в това измерение се категоризира като дейностите, които се извършват през отделните фази. Формализъм, в това измерение вкл необходи-мите за разработването формални модели на ПП.

Частични модели - частични" се използва, за да се покаже, че в този тип модели по правило липс-ват съществени части от естествения ЖЦ на ПП. Тези модели се опитват да отразят т.н. reuse техника, чийто смисъл е малко или повече използване на вече създадени компоненти от други ПП-програмни моду-ли, проектантски решения, документация.Това е модел от групата на хронологичните и модифи-цирани. Модификацията се състои в това, че отдел-ните фази се припокриват частично във времето. Това е една стъпка на подобрение на адекват-ността на модела на ЖЦ на ПП по отношение на стандартните модели.

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

Еволюционният модел се опитва да интегрира специфициране, проекти-ране и реализация. Ета-пите в един еволюционен процес са: Формулиране първи вариант на изисква-нията към ПП; Разра-ботване на ПП възможно най-бързо на основата на така формулираните изисквания; Оценяване на ПП съвместно с потреб или възложителя и внасяне на изменения с оглед предявените пови изисквания от него. Това означава изменение па първоначалната функционалност на ПП и добавяне на нова, ако е необходимо. Този подход обикновено се поддържа от т.н. езици от четвърто поколение. Разработеният ПП може да се използва като база за строго специфициране на крайния ПП или да еволюира до ПП, който ще се достави на потребителя.

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

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

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

Изследване на Модела на Гънтър-Начало, това е началото на ЖЦ на ПП и е моментът на възникване на идеята за създаване на ПП. Същност, през тази фаза се уточнява предназначението, основните ф-ции и изисква-ния към разработвания ПП. Обикновено тази фаза вкл маркетингово проучване на съществуващите в момента на софт пазар аналогични ПП. Резултат от анализи-рането на фазата трябва да бъдат формулирани всички основни изисквания към ПП. Като всеки подобен резул-тат се оформя в писмен док. В случая той се нарича Съглашение за изисквания-та (СИ). Продължителноста. 4-10 седмици.

Анализ на осъществи-мостта-Начало, моментът на назначаване на ръково-дител на проекта. Същност, през фазата Изследване се установява какъв ПП трябва да бъде разработван. Въп-росът е може ли това да се осъществи. Предназначе-нието на тази фаза е да се установи може ли да се създаде ПП. Това става ч/з анализ на: а) техническа осъществимост: анализ на достъпния хардуер, както за осъществяване на разра-ботката, така и за изпол-зване на готовия ПП. Освен вида на хардуера, трябва да се анализират и необходи-мите заразработ-ката други технически средства; б) икономическа осъществи-мост: анализират се и се оценяват в рамките на възможното цената на разработване, цена на която би се продавал ПП и цената за експлоатация на ПП. Ана-лизът на цената на разработване трябва да завър-шва с пълна яснота как ще бъдат осигурявани необхо-димите средства, т.е. иконо-мическата осъществимост показва и откъде ще се осигурят необходимите средства; в) експлоатацион-на осъществимост: анали-зират се преимуществата и недостатъците на замисле-ния ПП от гледна точка на потреб му, например: изис-ква ли се специална квали-фикация, какви техноло-гични операции трябва да се извършват и дали са по силите на средния потребител, ще се реализират ли разумни стойност по отно--шение на бързината на обработките и т.н.; г) пазар-на осъществимост: на осно-вата на маркетингово проучване се прави опит да се прогнозира дали новият ПП ще се търси, може ли да бъде конкурентноспособен и какви ще са силните му страни в сравнение с аналогичните ПП. Този анализ е важен за изгражда-нето на маркетинговата стратегия на фирмата по отношение на този ПП. Анализът на всички видове осъщест-вимост се извър-шва от група специалисти със съответната квалифика-ция. Резултат. След евен-туални промени се утвърж-дават формулираните в СИ изисквания. Продължител-ност-Срок: 1-10 седмици след края на предишната фаза.

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

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

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

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

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

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

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

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

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

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

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

Съпровождане-Обхваща всички дейности по внасяне на промени в готовия ПП, адаптиране на ПП към нова операционна или хардуерна среда. Извършва се от разработчиците. Изисква най-високата възможна квалификация, защото, както е известно, в повечето случаи внасянето на коректни изменения в съществуваща програма е по-трудно, отколкото създаването на нова програма. Съпровождането може да се извършва на различни равнища: гаранционно съпровождане - обикновено то включва задължения за безусловно и безвъзмездно отстраняване на грешки по искане на потреб, като обичайният срок е 12 месеца; развитие на ПП и отстраняваш: на грешки; отстраняване на грешки; регистриране па съобщенията за грешки и на заявките за подобряване с оглед вземането им под внимание при евентуално разработване на нов подобен ПП.

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

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

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

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

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

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

Създадените Специфика-ции на изискванията към софтуера са основа за изграждане на първия формален модел на целе-вата с-ма - т.н. аналитичен модел. Той е резултат от проведения стр-рен анализ и предназначението му е да улесни следващите дейности по проектиране. Основните съставящи на аналитичния модел са: модел на данните, функ-ционален модел, поведен-чески модел. Моделът на данните представя основ-ните обекти, атрибутите, които ги описват и връз-ките на обектите помежду им. Обект може да бъде всяко нещо, което създава или използва информация в софтуерната с-ма. Опи-санието на обекта включва описание на същността и на атрибутите му, които представят основните х-стики и с-ства на този обект. Обектите са свър-зани помежду си по раз-личен начин. Разглеждани-те отношения са ориенти-рани, т.е. имат посока, която трябва да се отчита при анализирането и изо-бразяването им. За всяко отношение могат да се определят стойностите на две основни х-стики: кардиналност и модалност, Кардиналността е х-стика, която определя колко екземпляра от единия обект могат да са в отношение с екземпляри от другия обект. Кардиналността се описва с един" и много" и може да бъде един-към-един", един-към-много" и много-към-много".

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

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

Предназначението на този модел е да представи основните функции на софтуерната система чрез проследяване на преобразуването на информацията в нея. Диаграмата на потока на данните е графично представяне, описващо трансформациите на данните така, че от входните данни в системата да се получат исканите изходи. Използваните графични елементи са правоъгълник за означаване на външни обекти, предаващи или приемащи информация от системата; кръг - за означаване на функция, променяща данните по някакъв начин и надписани стрелки, представящи съответните вх и изх данни. Широкото практическо използване на ДПД се обуславя от тяхната изключителна простота и нагледност. Те могат да се съставят с различна степен на детайлизираност. По-нататъшното анализиране изяснява основните функции, докато се достигне до описание, което може да бъде основа за проектирането. Графичното представяне на функциите може да се съпътства с допълнително описание на всеки елемент в ДПД. Това описание се нарича спецификация на процеса. Освен входа, изхода и същността на извършваната трансформация, могат да се задават и допълнителни изисквания към всяка от описваните функции.

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

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

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

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

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

Обектите в класа наследяват неговите атрибути и операции. Суперклас е съвкупност от класове, а подклас е екземпляр на клас. Съществува йерархия на класовете, като подкласовете наследяват атрибутите и операциите на суперкласа, но могат да имат и специфични за тях атрибути и операции. Взаимодействието между обекти се осъществява чрез съоб.Съоб предизвиква р-ция и промяна в поведението на обекта-получател. Той изпълнява посочената в съоб операция и връща управлението на обекта-подател. Чрез съобта се описва поведението на обектите и на 00 с-ма като цяло. Три основни х-стики са присъщи на 00 подход. Те са: а) капсулиране" в класа на данните и операциите върху тях. Това има следните преимущества:

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

б) наследяване. Същността на наследяването е че всеки подклас придобива автоматично всички атрибути и операции на съответния суперклас. Така се осигурява повторно използване на проектираните и реализирани вече стр-ри данни и алгоритми. Улеснено е внасянето на изменения, защото те се правят само в съответното ниво в йерархията от класове и чрез наследяването се разпространяват. При необходимост от нов клас, той може да се конструира изцяло или да се вмъкне" в съществуващата йерархия от класове, като се допишат само специфичните за него елементи. Допуска се и множествено наследяване" от няколко различни суперкласа. То е полезно заради по-големия брой наследявани с-ва, но затруднява проследяването на връзките в йерархията. в) полиморфизъм- Това с-во дава възможност различни операции да имат едно и също име. Така се осигурява настроеваемост и гъвкавост, защото с унифицирано извикване могат да се реализират специфични обработки. Обектно-ориентиран анализ и проектиране. Целта на обектно-ориентирания анализ (ООА) е създаването на модел, представящ, статичните и динамични характеристики на класовете и взаимоотношенията между тях. Създадени са различни методи за ООА, използващи различни съвкупности от диаграми и означения, но преминаващи през едни и същи стъпки, обобщени както следва: Изясняване на потреб изисквания за с-мата; Идентифициране на потреб сценарии; Избор на класовете и обектите въз основа на формулираните изисквания; Идентифициране па атрибутите а операциите за всеки обект; -Дефиниране на стр-рите и йерархиите на класовете; -Построяване на модел, описваш обектите и връзките между тях; -Построяване на поведенчески модел; -Проверка на 00 аналитични модели за съответствие с потреб сценарии.

Проектирането па 00 с-ма изисква определянето на многопластова софтуерна архитектура, специфициране на подсистеми, които изпълняват исканите ф-ции, описание на обектите ,които са изграждащите блокове на с-мата и описание на механизмите на комуникация, реализиращи потока на данните между слоевете, подсистемите и обектите. 00 проектиране се извършва на две нива, съответстващи па външното и детайлното проектиране при конвенционалния подход проектиране на с-мата и проектиране на обектите. При проектирането на с-мата се определя архитектура на 00 приложение. Създаденият аналитичен модел се декомпозира на подсистеми- като се описва предназначението на всяка подс-ма и връзките между тях. Проектират се още потребителският интерфейс и логическата организации на данните . При проектирането на обектите за всеки обект се съставя интерфейсно описание и описание на реализацията. Интерфейсното описание определя всички съоб, получавани от обекта и съответните операции, които обектът извършва при получаване на съобта. Описанието на реализацията специфицира свързаните с обекта стр-ри данни и алгоритмите за всяка операция. За стандартизирано описание на моделите в ОО разработване на софтуер е създаден т.н. UML. Основните части са: а) представяния- Моделирането на сложните реални системи изисква описването на различни техни аспекти. Така с-мата има няколко представяния от различна гледна точка, като всяко представяне е проекция на цялостното описание на с-мата в съответствие с избран аспект . Поддържаните от езика UML представяния са потребителско,логическо,компонентно,конкурентно и обвързващо.

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

15. Качеството на програмните продукти е абстрактно понятие. Твърди се, че то трудно се дефинира, но е лесно да се разпознае при реалното използуване на съответния програмен продукт. Една от трудностите при дефинирането е относителният х-ктер на качеството. Могат да се избират различни дефиниции в зависимост от интересуващия ни аспект на качеството, от това кой го оценява и кои са обектите, чието качество се изследва. В по-нататъшното изложение ще се придържаме към следната дефиниция: Качествен е този програмен продукт, който удовлетворява формулираните към него изисквания. Всяко отклонение от изискванията ще наричаме дефект.Дефектите обикновено се дължат на една или няколко грешки. Под грешки ще разбираме неправилност, отклонение или неволно преиначаване на обект или процес.В зависимост от това, в какъв софтуерен продукт се откриват, грешките могат да бъдат грешки в проекта, в програмата, в документацията, в тестовите данни и т.н. По-нататък ще разгледаме само грешките в програмите, дейностите за откриването и отстраняването им и средствата, подпомагащи тези дейности. Според Майерс в програмата има грешки, ако тя не изпълнява това, което потребителят разумно очаква от нея. Грешките могат да бъдат: първични - неправилности в текста на програмите, подлежащи на непосредствено коригиране; вторични - изкривявания на получените резултати съгласно други класификации грешките могат да бъдат-технологични грешки ,алгоритмични грешки,програмни грешки ,системни грешки .

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

В зависимост от целта, тестването може да бъде: за доказване на експлоатационната годност проверява се дали програмният продукт е работоспособен; за атестация - т.н. пускови изпитания, след успешното завършване на които програмният продукт може да се разпространява; за пълна функционална проверка - дали реализираните функции съответстват на формулираните изисквания; за проверка на специални програмни свойства, например надежност или преносимост; за проверка на нови свойства или функции - реализира се след внасяне на изменения в създадения програмен продукт и се нарича регресионно тестване; за проверка на работоспособността на системата в реални потребителски условия - изследва се времето за отговор на системата, продължителността на входно-изходните операции, изчислителните ресурси; качеството на потребителския интерфейс и други. В зависимост от това кой извършва тестването, то може да бъде: вътрешно тестване - от самите разработчици. Всеки програмист проверява правилността на създадените от него програми. Преимущество на този подход е. че не е необходимо допълнитлно разучаване на програмите. Недостатък е, че програмистите имат склонност към над-ценяване на възможностите си и увереността, че не допускат грешки, пречи на систематичното тестване. Форма на вътрешно тестване е т.н. peer review - проверка, при която програмистите са разделени на двойки и всеки проверява програмите на партньора си. независимо тестване - от експерти, които не са участвали в разработването на програмите. Обикновено това са членове на групата по тестване, действаща в софтуерната фирма. сертифициране - проверка и издаване на сертификат, удостоверяващ наличието на определени свойства на ПП. Сертифицирането може да се извършва само от фирми, притежаващи съответния лиценз.

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

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

16. Създадени са множество инструментални средства, които подпомагат дейностите по откриване и отстраняване на грешки . Чрез автоматизация на настройването и тестването се постига:систематичност,подобряване на организацията на тестване,повишаване на надежността на програмната система, документиране на извършваните дейности, автоматично измерване на обхвата на тестването. Инструменталните средства, подпомагащи настройването, се наричат програми- дебъгери. Основните възможности на дебъгерите са следните: а) разглеждане па текста на програмата на различни нива на декомпозиране. Съвременните дебъгери реализират многопрозоречно визуализиране на интересуващите ни програмни части. б) трасиране на изпълнението - показване на операторите в реда на изпълнението им при конкретните тестови данни. в) възможност за дефиниране на контролни точки и определяне на действията при достигане на съответната контролна точка. Тези действия могат да бъдат преустановяване на изпълнението на програмата,разпечатване съдържанието на определени области от паметта или на указани променливи,продължаване на изпълнението па програмата от указан оператор. В зависимост от предназначението си, програмните средства за тестване могат да бъдат анализатори на програми, генератори на тестови данни, помощни средства и среди за тестване. а) анализатори на програми: Предназначението им е да реализират избран метод на тестване чрез опериране върху тестващата програма по съответстващ на метода начин.Статичният анализ е изследване на текста на програмите и извличане на определена информация от него. Статичният анализ може да бъде елементарен или потоков. При елементарния статичен анализ текстът на програмата се проследява, като се създава таблица на използуваните имена и срещанията им . Създава се и тъй нареченият статичен прoфили на програмата, показващ кои оператори са използувани и колко пъти.При потоковия анализ се построява управляващ граф на програмата и граф на обръщенията, отразяващ връзките между отделните програмни части. Потоковият анализ дава възможност да се открият няколко вида грешки: структурни - недостижими програмни части, недопустими пресичания в телата на цикли, рекурсивни обръщания към подпрограми, когато това не е разрешено. в дефинирането - използуване на променлива преди да е получила начална стойност, дефиниране на променливи, които по-нататък не се използуват, установяване на случаи при цикли, управлявани от логически израз, в които никоя от променливите, участващи в израза, не променя стойността си в тялото на цикъла-несъответствия и грешки при предаване на параметри между различни програмни части и използването на тези програмни части и параметри. Обикновено потоковият анализ се извършва на две нива : локално - за всяка програмна единица; глобално - за програмната система като цяло. Съобщенията за грешки и документиращата информация съответстват на тези две нива. Потоковият анализ има два недостатъка: дълбочината на анализа се постига с цената на големи изчислителни ресурси, които са пропорцонални на размера на изследваните програми.

поради наличието на условни или изчислителни преходи, откриваните аномалии се делят на установени и на предполагаеми. Основни тенденции при статичните анализатори са разработването им за програми, написани на различни езици за програмиране и включване на статичните анализатори в интегрирани системи за тестване. При динамичния анализ програмата се изпълнява по управляем и систематичен начин и се изследва нейното поведение, за да се потвърди функционалната й коректност или некоректност. При планирането на динамичния анализ се избира стратегия, подготвят се съответстващи на стратегията тестови дании и се определя начинът на тълкуване на получаваните рзултати. Исторически първият реализиран метод за динамичен анализ е бил тъй нареченият подход на черната кутия, при който изследваната програмна част се разглежда като елемент с неизвестно съдържание. Към нея се подават входни данни и след изпълнението се получават определени резултати. При този подход има възможност за установяване на несъответствията, без да се изясняват причините за тях. Така се достига до идеята за реализиране на бяла кутия" - програмата се инструментира по такъв начин, че да се натрупва информация за поведението й по време на изпълнение. При метода на пробите за всеки изпълним оператор се дава броят на изпълненията му при конкретни входни данни. Тази справка показва не само каква част от програмата е тествана, но и кои са най-често използваните програмни части. Те могат да бъдат обект на по-нататъшна оптимизирация. Развитие на този метод е програмата да се инструментира така, че след изпълнението й да се създаде анотиран листинг, в който за всеки изпълним оператор, освен броя на изпълненията му се дава и допълнителна информация .Друг подход е вграждане в програмата на твърдения, които първоначално са като коментари, но могат да се активизират за целите на динамичния анализ. Тези твърдения описват някакви условия и какви да бъдат действията при нарушаването им. Формално-функционалните анализатори реализират символично'" изпълнение на програмата. Програмата се разглежда като изчислима функция, която може да се декомпозира на частични функции, изчислявани върху логическите пътища в програмата с подмножество на входните данни. Сложността на тези анализатори е близка до сложността на системите за доказване правилността на програми и затова практическото им използуване засега е ограничено. Мутационните анализатори генерират мутанти на изследваните програми чрез внасяне на различни но вид и сложност грешки. След това се изследва приложимостта на избрана съвкупност от тестови данни и чувствителността на избран метод към типа на внесените грешки.

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

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

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

17. Всеки потреб желае да придобива и използва качествен софт. От това следва, че и стремежът на всеки разработчик е да създава софт с високо качество. Стимулът затова е не само чисто етичен, но има очевидни икономи-чески причини. Възмож-ността даден програмен продукт да бъде продаден, и то на по-висока цена, зависи силно от неговото качество. Щом принципният стремеж на производителите на софт е да създават софт с високо качество, естествена цел е да се изгради някаква с-ма или поне съвкупност от взаимообвързани мерки за осигуряване на качеството. За да стане обаче това, необходимо е преди това да се намерят достатъчно точни, обективни и ефективни методи за измерване на качеството на програмните продукти. Последното пък изисква най-напред да се изясни какво е това качество на софта. Напоследък повечето автори са склонни да дават по-обща дефиниция на понятието качество", водени вероятно от убеждението, че всеки опит за по-подробно определение рано или късно ще доведе до намирането на контра-примери и, следователно, до опровергаване. Причините за това се крият в прекалената универсалност на понятието ,,качество, изключително широката му приложимост и уязвимост от практиката. Така че напоследък като че ли най-добре и от най-широк кръг се възприема определението: Качеството е съвкупността от средства и х-ките на даден продукт или услуга, носители на способността му да отговори на явно или неявно указани нужди. Смята се, че първи сериозни изследвания по въпроса е направил Боем през 1973 година, а по-късно, през 1978 година ги е задълбочил с помощта на други автори . Моделът на качеството на софта на Боем има йерар характер, но е сравнително слабо стр-риран със своите реални две нива. Качеството на софта Боем свързва преди всичко с неговата полезност" и възможност за лесно съпровождане. Първият аспект се определя от няколко х-ристики - надеждност, ефективност и използваемост от гледна точка на потребя-човек. Вторият аспект зависи от други х-ристики - тестируемост, разбираемост и модифицируемост. Освен това има още една, несвързана с двата аспекта х-ристика, наречена портабелност . Х-ристиките от своя страна зависят от с-ва на по-долно ниво. Тази зависимост вече не е чиста йерархия, защото не само че дадена х-ристика се определя от две или повече с-ва от по-долното ниво, но има с-ва, които определят повече от една х-ристика. Един завършен йерар модел на качеството на софта е този на компания Боинг. Той има три основни задачи: развиване и утвърждаване на резултатите от предходни проекти на подобна тематика; разширяване на рамката на разглеждане на програмния продукт като такъв; разработване на методология за определяне и специфициране на изисквания към: факторите, определящи качеството на софта. Качеството се разглежда като йерархична стр-ра. То се намира на най-високото ниво -0.На следващото ниво - 1се намират факторите. Факторът се определя като потребски ориентирано свойство, представящи даден аспект на качеството на софта от гледище на потребя. В зависимост от конкретния модел факторите могат да бъдат от 6 до 16. В разглеждания от нас те са б и са следните: Гъвкавост: лекота на адаптиране към нови функционални условия, включително при изменение на областта на приложение или други условия на функциониране. Коректност: степен на съответствие, на специфицираните алгоритми и други изисквания спрямо обработката на данни, както и спрямо потребската документация,

Надеждност: способност на програмния продукт да изпълнява зададените функции, предвидени в програмната документация, при отклонения, възникващи за средата на функциониране. Съпровождаемост: възможност за отстраняване на отклонения и грешки в процеса на експлоатации на програмния продукт и 1а поддържането му в актуално състояние. Удобство на използване: възможност за усвояване и експлоатация на програмния продукт с минимални усилия.

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

Последното ниво - 4 - е това на оценъчните елеми ният елем е елемарна х-ристика на най-ниско ниво. която подлежи на количествено оценяване. От метриките, определящи кри терия нагледност. за пример нека вземем коментари към логиката наI програмата. Тя се определя от следните оценъчни елеми: коментари към машинно-независимите фрагменти на програмата; коментари към машинно-зависимите фрагменти на програмата

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

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

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

-Функционални. Основната цел на функционалните проверки е да се преодолее ефектът от многобройните тествания и съответни корекции. Напълно е възможно при установяване на дадена грешка в процеса на разработване и последващото нейно отстраняване да е била внесена друга грешка. Колкото по-дълго се разработва даден продукт, толкова повече опасността от такива ..вторични" неотстранени грешки нараства. Крайната функционална проверка цели да покаже пълната липса на такива остатъчни грешки. Физически. Тази категория проверки се съсредоточава върху съответствието на продукта с изискванията на договора по отношение на документацията и сроковете. Те се правят след функционалните. Оценяване. Оценка се прави обикновено от един специалист. Целта й е да се установи съответствие на всички х-ристики на всеки продукт с формулираните изисквания. По същество това е функция по контрол па качеството на продукта. Тя обаче осигурява инфо и за процеса па разработване. Поради тези причини всички дейности по оценяване трябва да се планират подробно и резултатите им да се използват възможно най-пълноценно. За отделните фази следва да се предвидят следните примерни дейности по оценяване. Изисквания към продукта. Дори и в използвания модел на жизнения цикъл да няма точно такава фаза, не може на един първоначален етап да не се формулират тези изисквания, така че те да отразяват на едно първо, но достатъчно точно приближение, възгледите на потребя за продукта. При планирането следва да се предвиди преглед и оценка на: плана за разработване на продукта; софтните стандарти; плана за управление на софтната конфигурация; плана за осигуряване на качеството; спецификацията на изис-кванията към продукта.

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

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

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

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

4. Програмиране и тестване на отделните модули. Както е известно, на този етап, наред с програмирането, самите изпълнители тестват своите реализации. През цялото време се извършват оценки на: както на всеки етап - плановете, доколкото търпят промени; написания първичен код - резултатите от тестването на отделните модули; всички ръководства.

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

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

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

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

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

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

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

Класификация в зависимост от типа на изследвания обект.

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

Продукти - резултати от процесите; Ресурси - елементи, входни данни за процесите.

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

Примери за обекти в софтуерното производство и съответните им вътрешни и външни характеристики са описани в таблицата на по- горната фигура.

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

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

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

Една метрика се нарича адитивна, ако резултатите от прилагането й за програмна система могат да се получат чрез сумиране на резултатите от прилагането й върху съставящите я програмни части.

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

I. Описание - Метриката е статична и може да се прилага както за отделен програмен модул, така и за програмна с-ма.За мярка на размера на програма се избира броят програмни редове в изходния текст на програмата: L=L1+L2, където L е общият брой редове, L1- броят коментарни и празни редове, а L2 - броят на същинските програмни редове. Метриката е адитивна.

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

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

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

М2. Метрика на Мак Кейб за структурна сложност.

I. Описание - Метриката на Мак Кейб е за програми. Тя е статична и измерва сложността на потока на управление в програмата. Тази метрика е една от най-често използваните. За прилагане на метриката трябва да се построи управляващият граф на програмата, в който върховете са отделните оператори (или линейни участъци) и два върха които са свързани с ребро, ако има предаване на управление между съответните оператори. Тогава V(G)=e-n+2*p, където V(G) е цикломатичната сложност, представляваща максималния брой линейно-независими пътища в програмата, е - броят на ребрата в управляващия граф, n ~ броят на върховете в управляващия граф, а р - броят на силно свързаните компоненти в графа. Тъй като обикновено р = 1, получаваме V(G)=e-n+2.

Очевидно е, че за сложните и дълги програми в реални софт проекти построяването на управляващия граф и пресмятането на цикломатичната сложност е доста ресурсоемко. Мак Кейб доказва, че броят на областите е с 1 повече от броя на разклоненията в програмата. Т.е. ако намерим общия брой d, на операторите IF, на операторите за цикъл и на операторите САSЕ , можем да изчислим дипломатичната сложност чрез формулата V = d+ 1.Недостатък на метриката на Мак Кейб е, че не отчита дължината на линейните участъци и нивото на влагане на управляващите стр-ри. Не се отразяват и м/у модулните връзки, които влияят на стр-рната сложност на програмната с-ма като цяло.Разширение на метриката на Мак Кейб е метриката на Гонг-Шмид, която предлага цикломатичната сложност да се изчислява по формулата С(G) = V(G) + Е, където Е представя обобщената степен па вграждане на управляващите стр-ри една в друга.

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

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

I. Описание - Тази метрика е статична метрика за програма, написана на произволен език за програмиране. Предложена е от Холстед през 197бг. и е метриката, за която има най-много публикации.Програмата се разглежда като състояща се от елем , които се класифицират в две групи: пасивни елем и активни елем. Операндите имат ст-ст и могат да бъдат константи или променливи, използвани при реализацията па алгоритъма в конкретна програма. Операторите са всички останали елем, влияещи върху ст-стите или наредбата на операндите. За прилагане на метриката се определят следните оценъчни елем: n1 - брой различни оператори; n2 - брой различни операнди; N1 - общ брой оператори; N2 - общ брой операнди.

Чрез тези оценъчни елем се изчисляват мерки на различни х-стики на програмата, които Холстед смята за съществени за текстуалната и сложност: Дължина на програмата: N = N1 + N2. Обем на програмата: Тази мярка се свързва с броя на битовете, необходими за двоичното представяне на изследваната програма. Доколкото за представянето на всеки от n-те различни елема са необходими поне log2 п бита, то за представяне на последователност от N такива елем ще са необходими N*log2 n бита. Потенциален обем: Потенциалният обем е обемът на минималната програма за решаване на разглеждания проблем. В такава програма има само два оператора - името на ф-цията и оператор за групиране , а с n*2 е означен минималният брой операнди. Ниво на реализация: Имайки реалния и потенциалния обем, смислено е да разгледаме отношението им, защото то дава представа колко сме усложнили" програмната реализация, отдалечавайки се от тривиалната. Усилия за създаване на програмата: Тази мярка е за интелектуалните усилия, вложени за написването на програмата, като мерната единица е emd - елементарни умствени импулси. Практическото използване на метриката за текстуална сложност се затруднява от липсата на точно определена алгоритмична процедура, която да се следва,но има прагматично р-ние т.е. да се използва синтактически-базираният подход.

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

2. Може да се оцени времето за програмиране чрез използване на индекса на Страуд за интензивност на интелектуалните занимания, койтоза програмирането има стойност S = 18. Така:Т = E/S = E/8.Гордън доказва , че усилията за създаване на нова програма, са сравними с усилията за разбиране на съществуваща.

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

I. Описание - Метриката на Рехенберг е опит за преодоляване на едностранчивостта на съществуващите метрики за сложност. Тя е статична, комплексна метрика, която може да се прилага за програми или програмни с-ми, написани на произволен език за програмиране от високо ниво. Рехенберг предлага следната формула:СС = SС + ЕС + DС,където: СС е комплексната сложност; SС - операторна сложност; ЕС - сложност на използваните изрази; DС - сложност на данните. Операторката сложност SС на програмата е сума от операторките сложности на съставящите я оператори. Сложността на изразите ЕС се пресмята чрез мерки за сложността на използваните в израза операции. Сложността на данните DС измерва разстоянието м/у декларирането и използването на всяка от данните. Мярката за сложност DС за програмата е сума от мерките за сложност на използваните променливи .

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

М5. Метрика за информационния поток

I. Описание - Статична метрика, която дава мярка за междумодулна сложност на първичния код. Този вид сложност се определя от информационния поток към даден модул, като се отчита броят на предаваните параметри, глобалните променливи и броят на вх/изхе данни. Оценъчните елем са следните: ini - мярка за входящия информационен поток; outi - мярка за изходящия информационен поток; weighti - теглови коефициент, който може да бъде 1 или мярка за размера на модула или друга мярка за сложност. Мярката е адитивна и сложността на програмната система е сума от изчислените сложности на всеки от модулите.

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

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

I. Описание - Обект на изследване са различни видове док - ръководства за потреб, материали за обучение и др. Предлаганата мярка е F=0.4(LM+PLW), където: LM е средна дължина на изречение, т.е. брой думи/брой изречения; PLW- относителен дял на дългите думи .

II. Приложимост - Мярката на четимост F отразява трудността на текста. Съществуват много софт метрики. Изключително важен е резултатът от сравняване на някои метрики за програми. Оказва се, че могат да се прилагат само три основни метрики - за размер, метриката на Рехенберг за относителна сложност и метриката на Мак Кейб за структурна сложност.

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

01. Среден брой методи за клас = Общ брой методи/общ брой класове за обект.

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

02. Средна сложност на метод=Сума от цикломатичната сложност на всички методи/Общ брой на методите в приложението.

Б. Метрики за ОО проектиране

Съкупността МООD включва шест метрики, които са свързани с основните харак-ки на 00 подход като капсулиране , наследяване , полиморфизъм и предаване па съоб. Тези метрики се дефинират по следния начин:

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

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

в} (МIF) - частно на сумата на наследените методи във всички класове на изследваната система и общия брои налични методи за всички класове.

г) (АIF) - частно на сумата на наследените атрибути във всички класове на изследваната система и общия брой налични атрибути за всички класове.

д) (РF) - частно на реалния брой възможни различни полиморфни ситуации за клас Сi и максималния брой на възможните различни полиморфни ситуации за клас Ci.

е) (СF) - частно ла максималния възможен бройна свързвания в системата и реалния брой на свързвания, които не са резултат от наследяване.

В. Класически метрики, адаптирани към ОО разработване.

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