Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 1.ОСНОВНИ ПОНЯТИЯ 1.1. Програми и програмни продукти
- 5.2. Съпровождане
- 5.3. Документиране
58  Тестването се осъществява в три основни стъпки: планиране, реализация и
отчитане. При планирането на тестването се определя целта на тестването, какво да се тества, кога, с какви данни, как и кой да го извършва. Реализацията на тестването се описва чрез сценарии за тестване. Отчитането се извършва чрез анализ на документираните резултати и прилагане на критериите за изчерпателността и обхвата на тестване. Има два основни подхода за тестване: структурен и функционален. Целта на структурното тестване е да се изберат такива тестови данни,
При функционалното тестване се проверява правилността на реализи- раните основни функции. В зависимост от избраните тестови данни и очаквани резултати тестването се дели на:
В зависимост от начина на осъществяване тестването може да е низходя- що (top down), възходящо (bottom up) и смесено — започва от някакво меж- динно ниво и се провежда в двете посоки. Тестването би трябвало да започне в най-различни етапи на създаване на програмите, като още тогава да се формулират критериите за установяване на желаното ниво на тестване. В зависимост от целта тестването може да бъде:
В зависимост от това, кой извършва тестването, то може да бъде: — вътрешно тестване — от самите разработчици. Всеки програмист проверява правилността на създадените от него програми. Преимущество на този подход е, че не е необходимо разучаване на програмите. Недостатък е, че програмистите имат склонност към надценяване на възможностите си и увере- ността, че не допускат грешки, а това пречи на системното тестване. Форма на вътрешно тестване е т. нар. peer review — проверка, при която програмистите са разделени на двойки и всеки проверява програмите на партньора си. 60
Един от най-сложните проблеми е да се определи докога да се тества. Обик- новено тестването завършва при изтичане на предвидения срок или изчерпване на ресурсите. Специалистите по тестване твърдят, че „недостатъчното тестване е престъпление, а прекомерното — грях". 5.1.3. Автоматизиране на дейностите настройване и тестване Създадени са множество инструментални средства, които подпомагат дей-
Инструменталните средства, подпомагащи настройването, се наричат прог- рами — дебъгери. Основните възможности на дебъгерите са следните: а) разглеждане на текста на програмата на различни нива на декомпо-
б) трасиране на изпълнението — показване на операторите в реда на изпълнението им при конкретните тестови данни; в) възможност за дефиниране на контролни точки и определяне на дейс- твията при достигане на съответната контролна точка. Тези действия могат да бъдат:
В зависимост от предназначението си програмните средства за тестване могат да бъдат анализатори на програми, генератори на тестови данни, помощ- ни средства и среди за тестване. а) Анализатори на програми — предназначението им е да реализират из- бран метод на тестване чрез опериране върху тестващата програма по съответ- стващ на метода начин. Статичният анализ е изследване на текста на програмите и извличане на определена информация от него. Статичният анализ може да бъде елемен- тарен или потоков (статичен анализ на потока на данните и потока на управ- лението). При елементарния статичен анализ текстът на програмата се просле- 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| разрешено;
Обикновено потоковият анализ се извършва на две нива:
Съобщенията за грешки и документиращата информация съответстват на| тези две нива. Потоковият анализ има два недостатъка:
Основни тенденции при статичните анализатори са разработването им 3i програми, написани на различни езици за програмиране, и включването на ста- тичните анализатори в интегрирани системи за тестване. При динамичния анализ програмата се изпълнява по управляем и систе- матичен начин и се изследва нейното поведение, за да се потвърди функционал- ната й коректност или некоректност. При планирането на динамичния анализ се избира стратегия, подготвят с съответстващи на стратегията тестови данни и се определя начинът на тълкува не на получаваните резултати. ! Исторически първият реализиран метод за динамичен анализ е бил тъй на реченият подход на черната кутия, при който изследваната програмна час се разглежда като елемент с неизвестно съдържание. Към нея се подават входни данни и след изпълнението се получават определени резултати. За съжалени при този подход има възможност за установяване на несъответствията, без да се изясняват причините за тях. Така се достига до идеята за реализиране в „бяла кутия" — програмата се инструментира по такъв начин, че да се нат- рупва информация за поведението й по време на изпълнение. При метода на пробите за всеки изпълним оператор се дава броят на изпълненията му при конкретни входни данни. Тази справка показва не сам 62 каква част от програмата е тествана, но и кои са най-често използваните прог- рамни части. Те могат да бъдат обект на по-нататъшна оптимизация. Развитие на този метод е програмата да се инструментира така, че след изпълнението й да се създаде анотиран листинг, в който за всеки изпълним оператор освен броя на изпълненията му се дава и допълнителна информация (например за операто- ра на присвояване — каква е минималната и максималната присвоявана стой- ност, колко пъти се е променила стойността и т. н.). Друг подход е вграждане в програмата на твърдения, които първона- чално са като коментари, но могат да се активизират за целите на динамичните анализатори. Тези твърдения описват някакви условия и какви да бъдат дейст- вията при нарушаването им. Формално-функционалните анализатори реализират „символично из- пълнение на програмата". Програмата се разглежда като изчислима функция, която може да се декомпозира на частични функции, изчислявани върху логи- ческите пътища в програмата с подмножество на входните данни. Сложността на тези анализатори е близка до сложността на системите за доказване правилността на програми и затова практическото им използване за- сега е ограничено. Мутационните анализатори генерират мутанти на изследваните прог- рами чрез внасяне на различни по вид и сложност грешки. След това се изслед- ва приложимостта на избрана съвкупност от тестови данни и чувствителността на избран метод към типа на внесените грешки. б) Генератори на тестови данни Тези програмни средства подпомагат или реализират съставянето на тесто-
Например при структурните стратегии на тестване проблемът е да се избе- рат тестови данни, които ще предизвикат изпълнението на неизпълнявана досе- га програмна част. Ясно е, че автоматичното генериране на тестове в този слу- чай изисква сложен анализ с цел да се определи дали има осъществим път от началото на програмата до тази програмна част; от стойностите на кои промен- ливи зависи изпълнението й и т. н. в) Помощни програмни средства Те подпомагат определени стъпки от процеса на тестване — планиране,
г) Интегрирани системи за тестване Интегрираните системи (понякога наричани среди за тестване) могат да
Натрупаният практически опит показва, че резултатите от тестването уста- новяват наличие на грешки и дефекти твърде късно — тогава, когато програм- ният продукт е почти завършен. Доказано е, че усилията за отстраняване на 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
Анализират се възможните начини за осъществяване на измененията и се определя кои програмни части ще бъдат модифицирани. Етап 3. Програмиране и тестване През този етап съответните програми се изменят и се тестват локално. Етап 4. Интегриране на програмната система и системно тестване Извършва се регресионно тестване и пълни приемни изпитания, след ус- пешното приключване на които версията се пуска за разпространение. През този етап потребителите се запознават с бюлетина за изменение и ако е необхо- димо, се провежда обучение за работа с новата версия. Етап 5. Разпространение на новата версия Всеки от потребителите на ПП може да получи новата версия и съответна- та документация. Конкретните финансови условия на разпространение зависят от съдържанието на новата версия и от регламентираните отношения между собственика на ПП и потребителите. 5.2.5. Разходи и цена на съпровождането Изследвани са факторите, влияещи на разходите за съпровождането: при- ложна област, продължителност на използване на програмната система, степен на зависимост от външната среда. Някои от идентифицираните разходи са след- ствие от методите и средствата, използвани при разработването — език и стил на програмиране, тестване и валидиране на програмите, качество на програм- ната документация и др. Белади и Леман [5] предлагат модел на процеса на съпровождане. Съгласно този модел, ако една програмна система се променя непрекъснато, то нейните обем и сложност нарастват. Причините за това са няколко. Първо, поправянето на едни грешки може да доведе до внасяне на нови. Второ, след всяко изменение системата се отклонява от първоначалния проект, който е обмислян и оценяван внимателно. Трето, съпровождането се извършва от специалисти с различна квалификация, ко- ито невинаги могат да разберат системата така, че да я променят оптимално. Предложена е следната оценка за разходите на съпровождане: с е мярка на сложността, предизвикана от липсата на структурно проекти- ране и документиране. Тази сложност се редуцира с d — степента, до която групата по съпровождане е запозната със софтуера. Константата К е емпирична, като стойността й зависи от средата. Тя се определя чрез регресионен анализ на разходите за съпровождане на реални проекти. Ако системата е разработена без прилагане на основните принципи на соф- туерните технологии, стойността на параметъра с ще бъде висока. Ако освен това се съпровожда без пълно разбиране на системата, стойността на d ще бъде ниска. В резултат разходите за съпровождане ще нарастват експоненциално. Следователно намаляването им Може да се постигне чрез осигуряване на харак- теристиката на качеството съпровождаемост в процеса на разработване и чрез предоставяне на достатъчно време за разучаване на системата, която ще се мо- дифицира. 5.2.6. Автоматизирани средства, подпомагащи съпровождането Някои от съществуващите софтуерни средства могат да се използват и при съпровождане. В зависимост от предназначението си те могат да се класифици- рат в следните групи: а) средства, улесняващи разучаването на програмите. Те реализират пре- форматиране в стандартен вид, създаване на справки за срещаните имена, ста- тичен анализ на потока на данните и потока на управление и др. б) средства, улесняващи анализа и проектирането на внасяните изменения, например чрез прилагане на метрики върху оригиналната и променената програ- ма; в) средства за управляемо внасяне на промените, като се следи за правата на достъп, автоматично се документират промените, управлява се последова- телността на осъществяване, регистрирането и оптималното извършване на мо- дифицирането; в) средства за провеждане и анализ на резултатите от регресионното тест- ване; г) средства за документиране на промените. Съществуват и среди за съпровождане, интегриращи няколко средства и
където:
М са общите разходи за съпровождане на програмната система. Стойността на р представя продуктивните усилия: анализ, проектиране, програмиране и тестване. 66
Разработването и използването на всяка софтуерна система е свързано със
67
 структура и съдържание [6]. Най-общо тези документи могат да бъдат класифи-
цирани в две групи: а) документи, свързани с процеса на създаване на софтуер — планове, гра- фици, отчети, стандарти, протоколи от заседания, разменяни съобщения и др. Тази документация зависи от стила на управление на проектите и се регла- ментира от действащи в конкретната софтуерна организация вътрешни правила и стандарти. Те определят каква е структурата на всеки документ, кой и кога го създава, какви са процедурите за утвърждаване, използване и променяне, къде и колко дълго се съхранява. б) документи, описващи създадения програмен продукт В зависимост от предназначението си тази документация може да бъде съп-
Предназначението на съпровождащата документация е да осигури ин- формацията, необходима за разучаване и за внасяне на изменения в програми- те. Тя може да включва:
проект;
Предназначението на експлоатационната документация е да осигури ин- формацията, необходима за използването на софтуерната система от крайни пот- ребители или администратори, което отговарят за функционирането на системата. Документацията за администратора се състои от:
От изключително значение е и документацията за крайния потребител. Съ- ществуват различни стандарти за съдържанието на потребителската документа ция — например стандарт ANSI/IEEE Std 1063-1987. Потребителската доку ментация може да се състои от две части — обучаваща и справочна. Обучава щата част е предназначена за начинаещи потребители, а справочната — за пот ребители с по-голям опит, които се нуждаят от информация за възможностите на системата. Справочната част обикновено представя основните функции, под редени по определен начин за бързо търсене — например по азбучен ред. Стилът на изложение зависи от някои характеристики на потенциалните потребители, като образование, квалификация, ниво на компютърна грамот- ност и др. Ако в изискванията към системата има и описани характеристики на потребителя, то те трябва да се вземат предвид. 68 Могат да бъдат формулирани следните изисквания към потребителската документация: а) Правилност. Трябва да има пълно съответствие между функционира- нето на програмната система и описанието й в документацията. След всяка но- ва версия трябва да се обновява и документацията, като се проверяват и изло- жените примери, така че потребителят да не бъде насочван погрешно. б) Пълнота и структурираност. Да има подробно съдържание и дори каква последователност на четене да се следва от потребителите с различна ква- лификация и опит. в) Стилът на изложение да е ясен, недвусмислен и съобразен с термино- логията в съответната област на приложение. Да се избягват тривиалните обяс- нения и примери. г) Ръководството за потребителя да бъде относително затворена систе- ма, съдържаща необходимата и достатъчна информация. Да се избягват слож- ните препратки дори с цената на повтаряне на информация. Да няма препратки към труднодостъпни източници. Всяка организация трябва да определи свои вътрешни стандарти за начина на създаване на документацията и за самата документация — от кои документи ще се състои и как ще се идентифицират те, каква да е структурата и съдържа- нието на всеки документ, какви правила при оформянето на документите ще се спазват (обща структура на документите, начин на оформление на страниците, номерация, използвани шрифтове, цветове и др.), каква ще е процедурата за внасяне на изменения. В България съществуват стандарти от серията БДС ЕСПО. Те имат номера БДС 19.ХХХ-УУ, където XXX е номерът на стандарта, а УУ — годината на създаването му. Тези стандарти са от периода 1978—1980 година и са морално остарели. Съществуват автоматизирани средства, подпомагащи съставянето, офор- мянето и отпечатването на различните видове документи. Освен намаляване на времето и усилията за документиране преимущество на използването на такива средства е възможността за поддържане на пълно съответствие между послед- ното състояние на софтуерната система и всички описващи я документи. Литература
69 Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
|
