Софтуерни технологии



страница5/18
Дата16.11.2017
Размер3.19 Mb.
Размер3.19 Mb.
1   2   3   4   5   6   7   8   9   ...   18

58

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

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


се тества, кога, с какви данни, как и кой да го извършва.

Реализацията на тестването се описва чрез сценарии за тестване.

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

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

Целта на структурното тестване е да се изберат такива тестови данни,
че да се осигури преминаване през всички програмни части на системата.

При функционалното тестване се проверява правилността на реализи-


раните основни функции.

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


се дели на:

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

  • стохастично тестване — тестваните данни са случайни величини с оп-
    ределено разпределение и се знае разпределението на получаваните резултати.

В зависимост от начина на осъществяване тестването може да е низходя-
що (top down), възходящо (bottom up) и смесено — започва от някакво меж-
динно ниво и се провежда в двете посоки.

Тестването би трябвало да започне в най-различни етапи на създаване на


програмите, като още тогава да се формулират критериите за установяване на
желаното ниво на тестване.

В зависимост от целта тестването може да бъде:



  • за доказване на експлоатационната годност — проверява се дали
    програмният продукт е работоспособен;

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

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

  • за проверка на специални програмни свойства, например надежност
    или преносимост;

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

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

В зависимост от това, кой извършва тестването, то може да бъде:

вътрешно тестване — от самите разработчици. Всеки програмист


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

60


  • независимо тестване — от експерти, които не са участвали в разра-
    ботването на програмите. Обикновено това са членове на групата по тестване,
    действащи в софтуерната фирма.

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

Един от най-сложните проблеми е да се определи докога да се тества. Обик-
новено тестването завършва при изтичане на предвидения срок или изчерпване
на ресурсите. Специалистите по тестване твърдят, че „недостатъчното тестване
е престъпление, а прекомерното — грях".

5.1.3. Автоматизиране на дейностите настройване и тестване

Създадени са множество инструментални средства, които подпомагат дей-
ностите по откриване и отстраняване на грешки [1]. Чрез автоматизация на нас-
тройването и тестването се постига:


  • систематичност;

  • подобряване организацията на тестване;

  • повишаване надежността на програмната система;

  • документиране на извършваните дейности;

  • автоматично измерване обхвата на тестването.

Инструменталните средства, подпомагащи настройването, се наричат прог-
рами — дебъгери.

Основните възможности на дебъгерите са следните:

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

б) трасиране на изпълнението — показване на операторите в реда на


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

в) възможност за дефиниране на контролни точки и определяне на дейс-


твията при достигане на съответната контролна точка. Тези действия могат да
бъдат:

  • преустановяване изпълнението на програмата;

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

  • продължаване изпълнението на програмата от указан оператор.

В зависимост от предназначението си програмните средства за тестване
могат да бъдат анализатори на програми, генератори на тестови данни, помощ-
ни средства и среди за тестване.

а) Анализатори на програми — предназначението им е да реализират из-


бран метод на тестване чрез опериране върху тестващата програма по съответ-
стващ на метода начин.

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

61

др.) обучението по софтуерни технологии продължава две години в рамките на

6 8 задължителни и още толкова избираеми курса, практикум и 2—3 курсови

проекта. Съответна на тази констатация е и целта на авторите — макар да е


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

Главите на тази книга са разработени както следва:

Аврам Ескенази: 1, 2, 6, 8, 10, 11, 15

Нели Манева: 3, 4, 5, 7, 9, 12, 13, 14



1.ОСНОВНИ ПОНЯТИЯ

1.1. Програми и програмни продукти

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

Естественият път за навлизане в тематиката и преди всичко в проблема


програми—програмни продукти (прилики и разлики) е хронологичният. Заед-
но с построяването на първите компютри от средата на 40-те години се появя-
ват и първите програми за тях. Както е известно, предназначението им е било за
военни цели. Доколкото в разработката и на хардуера, и на софтуера са участ-
вали учени, естествено е било да се направят опити за използване на компютри-
те за подпомагане на научните изследвания, преди всичко за изчисления.

Много скоро, още преди края на 50-те години, ръководителите на банките


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

Постепенно компютрите навлизат в търговската дейност, в медицината, в


дейността на авиолиниите и в много други области. Всяка от тях налага създа-
ването на съответните програми. Компютрите обаче си остават „големи" (main
frame) или се произвеждат с известни вариации нагоре (свръхкомпютри) или
надолу (мини). Във всички случаи обаче потребителите остават или професио-
налисти, или добре обучени специалисти в конкретната област на приложение.
Характеристиките на софтуера (интерфейс, надеждност, лекота на усвояване и
др.) са следствие от тези особености на потребителите

В края на 60-те години е извършена и една решаваща за по-нататъшното


развитие на софтуерното производство стъпка. Известната фирма IBM, по това
време най-големият производител на хардуер и софтуер в света, въвежда т. нар.
политика на unbundling. Това означава, че софтуерът, който дотогава се е давал
като безплатна (поне така е било обявявано) добавка към хардуера, започва
постепенно да се продава. В началото това се е отнасяло само до част от доста-
вяния софтуер, постепенно обаче кръгът му се разширява. Какви са били стра-
тегическите помисли на IBM c този техен ход, е предмет на обсъждане дълго
време, но едно е ясно — той всъщност дава тласък за развитие на софтуерната
промишленост.

дява, като се създава таблица на използваните имена и срещанията им (cross-


reference). Създава се и тъй нареченият статичен профил на програмата, по-
казващ кои оператори са използвани и колко пъти.

При потоковия анализ се построява управляващ граф на програмата и


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

— структурни — недостижими програмни части, недопустими пресичания |


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

разрешено;



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

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

Обикновено потоковият анализ се извършва на две нива:

  • локално — за всяка програмна единица;

  • глобално — за програмната система като цяло.

Съобщенията за грешки и документиращата информация съответстват на|
тези две нива.

Потоковият анализ има два недостатъка:



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

  • поради наличието на условни или изчислителни преходи откриваните
    аномалии се делят на установени и на предполагаеми, т. е. на такива, които
    непременно ще се случат, и такива, които биха могли да се случат. Пример
    конструиран може би изкуствено, показва, че след статичен анализ на програма
    от 760 оператори са обявени 20 установени и 1700 предполагаеми аномалии.

Основни тенденции при статичните анализатори са разработването им 3i
програми, написани на различни езици за програмиране, и включването на ста-
тичните анализатори в интегрирани системи за тестване.

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


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

При планирането на динамичния анализ се избира стратегия, подготвят с


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

Исторически първият реализиран метод за динамичен анализ е бил тъй на


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

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


изпълненията му при конкретни входни данни. Тази справка показва не сам

62

каква част от програмата е тествана, но и кои са най-често използваните прог-


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

Друг подход е вграждане в програмата на твърдения, които първона-


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

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

Сложността на тези анализатори е близка до сложността на системите за


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

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

б) Генератори на тестови данни

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

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


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

в) Помощни програмни средства

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

г) Интегрирани системи за тестване

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

5.1.4. Осъществяване на тестването

Натрупаният практически опит показва, че резултатите от тестването уста-


новяват наличие на грешки и дефекти твърде късно — тогава, когато програм-
ният продукт е почти завършен. Доказано е, че усилията за отстраняване на

63

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


тервал t, определен от момента на допускане на грешката t1, до момента на отк-
риването на грешката.:

Затова се разработват специални методи и техники, позволяващи ранното:


откриване и отстраняване на грешки.

5.2. Съпровождане

5.2.1. Същност на съпровождането

Под съпровождане (maintenance) ce разбира съвкупността от дейности,


свързани с внасяне на промени във внедрен софтуер.

В зависимост от целите на модифицирането съпровождането може да бъде:



  • коригиращо — за поправяне на установени грешки;

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

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

Статистическите данни показват, че 25% от усилията за съпровождане са
за коригиращо, 50% за адаптивно и 25% за усъвършенстващо съпровождане
Това разпределение зависи от много фактори (тип и сложност на софтуера,
приложна област и др.), но като цяло разходите за съпровождане са големи
между 65% и 75% от всички разходи. Много софтуерни организации са прину-
дени да ограничават разработването на нови продукти поради голямата трудо-
емкост на съпровождането на съществуващите [3].

5.2.2. Осъществяване на съпровождането

Съпровождането може да се реализира от разработчиците или от други


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

Основните обобщени етапи на съпровождането са:



  • разучаване на съществуващия софтуер;

  • модифициране на съществуващия софтуер;

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

64

5.2.3. Управление на софтуерните конфигурации

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


менти, необходими за функционирането на даден ПП.

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


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

За съпровождането на всеки ПП трябва да се състави описание на софту-


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

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


ние, контрол на версиите и управление на внасянето на измененията.

Обикновено се поддържа стандартен формуляр — заявка за изменение, в


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

а) подреждане на измененията по технически или процедурни причини;

б) подреждане по неотложност на извършване на промените;

в) оценяване на необходимите ресурси за реализиране на измененията;

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

д) сходните промени да се групират в една версия.

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

Трябва да се осигури и пълно съответствие между ПП и документацията му.


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

5.2.4. Управление на внасянето на изменения

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


ните пет етапа:

Eman 1. Идентифициране на проблема и възлагане

Попълва се формуляр, в който се описват одобрените измененията с прис-

65

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

Етап 2. Проектиране на измененията

Анализират се възможните начини за осъществяване на измененията и се


определя кои програмни части ще бъдат модифицирани.

Етап 3. Програмиране и тестване

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



Етап 4. Интегриране на програмната система и системно тестване

Извършва се регресионно тестване и пълни приемни изпитания, след ус-


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

Етап 5. Разпространение на новата версия

Всеки от потребителите на ПП може да получи новата версия и съответна-


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

5.2.5. Разходи и цена на съпровождането

Изследвани са факторите, влияещи на разходите за съпровождането: при-


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

Белади и Леман [5] предлагат модел на процеса на съпровождане. Съгласно


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

Предложена е следната оценка за разходите на съпровождане:



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

Константата К е емпирична, като стойността й зависи от средата. Тя се


определя чрез регресионен анализ на разходите за съпровождане на реални
проекти.

Ако системата е разработена без прилагане на основните принципи на соф-


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

5.2.6. Автоматизирани средства, подпомагащи съпровождането

Някои от съществуващите софтуерни средства могат да се използват и при


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

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


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

б) средства, улесняващи анализа и проектирането на внасяните изменения,


например чрез прилагане на метрики върху оригиналната и променената програ-
ма;

в) средства за управляемо внасяне на промените, като се следи за правата


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

в) средства за провеждане и анализ на резултатите от регресионното тест-


ване;

г) средства за документиране на промените.

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


където:


М са общите разходи за съпровождане на програмната система.

Стойността на р представя продуктивните усилия: анализ, проектиране,


програмиране и тестване.

66

5.3. Документиране

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

67


структура и съдържание [6]. Най-общо тези документи могат да бъдат класифи-
цирани в две групи:

а) документи, свързани с процеса на създаване на софтуер — планове, гра-


фици, отчети, стандарти, протоколи от заседания, разменяни съобщения и др.

Тази документация зависи от стила на управление на проектите и се регла-


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

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

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

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


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

  • описание на функционалните и нефункционални изисквания към ПП;

  • описание на архитектурата на софтуерната система — от какви основ-
    ни компоненти се състои и какви са връзките между тях;

  • за всяка компонента — описание на спецификациите и на детайлния

проект;

  • първичен текст на програмата. В някои организации има стандарт за
    т. нар. вътрешно документиране на програмите чрез коментари.

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

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

Документацията за администратора се състои от:



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

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

От изключително значение е и документацията за крайния потребител. Съ-
ществуват различни стандарти за съдържанието на потребителската документа
ция — например стандарт ANSI/IEEE Std 1063-1987. Потребителската доку
ментация може да се състои от две части — обучаваща и справочна. Обучава
щата част е предназначена за начинаещи потребители, а справочната — за пот
ребители с по-голям опит, които се нуждаят от информация за възможностите
на системата. Справочната част обикновено представя основните функции, под
редени по определен начин за бързо търсене — например по азбучен ред.

Стилът на изложение зависи от някои характеристики на потенциалните


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

68

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


документация:

а) Правилност. Трябва да има пълно съответствие между функционира-


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

б) Пълнота и структурираност. Да има подробно съдържание и дори


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

в) Стилът на изложение да е ясен, недвусмислен и съобразен с термино-
логията в съответната област на приложение. Да се избягват тривиалните обяс-
нения и примери.

г) Ръководството за потребителя да бъде относително затворена систе-


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

Всяка организация трябва да определи свои вътрешни стандарти за начина


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

В България съществуват стандарти от серията БДС ЕСПО. Те имат номера


БДС 19.ХХХ-УУ, където XXX е номерът на стандарта, а УУ — годината на
създаването му. Тези стандарти са от периода 1978—1980 година и са морално
остарели.

Съществуват автоматизирани средства, подпомагащи съставянето, офор-


мянето и отпечатването на различните видове документи. Освен намаляване на
времето и усилията за документиране преимущество на използването на такива
средства е възможността за поддържане на пълно съответствие между послед-
ното състояние на софтуерната система и всички описващи я документи.

Литература

  1. Манева, Н. Основни тенденции при разработването на средства за тестване на програми.
    АИТ и АС, №3,1987, с. 77—84.

  2. Sneed, H., К. Kirchoff. PRUFFSTAND — A Testbed for Systematic Software Components.
    Proc. INFOTECH State of the Art Conf. on Software Testing, 1978, London.

  3. Thomas, P., Practical Software Maintenance. NY Wiley, 1997.

  4. James, M., Software maintenance. NY Prentice Hall, 1983.

  5. Belady, L., M. Lehman. An Introduction to Growth Dynamics, m W. Freinberger (ed.) Statistical
    Computer Performance Evaluation, Academic Press, 1972.

  6. Guidelines for the documentation of software in industrial computer systems (publ. by IEEE)
    1987.

69


Сподели с приятели:
1   2   3   4   5   6   7   8   9   ...   18


©zdrasti.info 2017
отнасят до администрацията

    Начална страница