Софтуерни технологии
Компоненти на програмата за осигуряване на качеството
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| 8.2. Компоненти на програмата за осигуряване на качеството
8.2.1. фактори Няколко фактора оказват важно влияние върху ПОКС [7]. Без да се впус- каме в подробности, ще ги изброим: изисквания към графика; разполагаемия бюджет; технологичната сложност на продукта; предполагаемия размер на продукта; относителния опит на разработчиците; хардуерните и софтуерните ресурси, предвидени за процеса на разра- ботване; изискванията на договора за възлагане. В момента на създаването на ПОКС трябва да се анализира и установи доколко всеки от горните фактори (а евентуално и някои други) ще й окаже влияние. 8.2.2. Прегледи Под преглед (review) ce разбира дисциплинирана групова дейност, на- сочена към изследване на продукт или процес. Ефективното изпълнение на прегледа изисква умело съставяне на групата с оглед комбиниране различните необходими квалификации. Отличават се 3 вида прегледи: A. Пробег (walkthrough). Това е неформален преглед на софтуерния про- дукт. Обикновено не се подчинява на строги правила. Прилага се най-често върху първичния код на междинните продукти. Б. Инспекция (Inspection). Това е дисциплиниран формален преглед на всякакъв тип продукти. B. Проверка на конфигурацията (Configuration Audit). Много често край- ното приемане на софтуерния продукт се основава на редица проверки на кон- фигурацията. Целта им е да установят доколко крайният продукт удовлетворя- ва изискванията, формулирани първоначално. Тези проверки се делят на 2 кате- гории: B.1. Функционални. Основната цел на функционалните проверки е да пре- одолеят ефекта от многобройните тествания и съответни корекции. Напълно е възможно при установяване на дадена грешка в процеса на разработване и пос- ледващото нейно отстраняване да е била внесена друга грешка. Колкото по- дълго се разработва даден продукт, толкова повече опасността от такива "вто- рични", неотстранени грешки нараства. Крайната функционална проверка це- ли да покаже пълната липса на такива остатъчни грешки. 94 B.2. Физически. Тази категория проверки се съсредоточава върху съот- ветствието на продукта с изискванията на договора по отношение на докумен- тацията и сроковете. Те се правят след функционалните. 8.2.3. Оценяване Оценка се прави обикновено от един специалист. Целта й е да се установи съответствие на всички характеристики на всеки продукт с формулираните изис- квания. По същество това е функция по контрол на качеството на продукта. Тя обаче осигурява информация и*за процеса на разработване. Поради тези при- чини всички дейности по оценяване трябва да се планират подробно и резулта- тите им да се използват възможно най-пълноценно. За отделните фази следва да се предвидят следните примерни дейности по оценяване. 1. Изисквания към продукта. Дори и в използвания модел на жизнения цикъл да няма точно такава фаза, не може на един първоначален етап да не се формулират тези изисквания, така че те да отразяват на едно първо, но доста- тъчно точно приближение възгледите на потребителя за продукта. При плани- рането следва да се предвиди преглед и оценка на: плана за разработване на продукта; софтуерните стандарти; плана за управление на софтуерната конфигурация; плана за осигуряване на качеството; спецификацията на изискванията към продукта; спецификацията на изискванията към интерфейса. 2. Общо проектиране. Както известно, на този етап изискванията се кон- кретизират и уточняват, а така също потребителският възглед започва да се тре- тира от гледна точка на реализацията. Съответни на това са и оценките на: всички ревизирани производствени планове; плана за тестването на софтуера; ръководството за оператора; ръководството за потребителя; ръководството за диагностика, като последните 3 визират всъщност плановете за тези документи, които оче- видно в този ранен стадий не могат да бъдат направени по същество. 3. Подробно проектиране. Резултатите от този етап са подробни специ- фикации, на основата на които може да бъде извършено програмирането (коди- рането) на продукта. Тук се предвижда оценяване на: текущо ревизираните планове — отново; документа — изход от подробното проектиране; документа — проект на интерфейса; документа — проект на базата данни; тестовите примери за проверка на отделните модули; тестовите примери за проверка на интегрираните модули; описанието на процедурите по тестване; ръководството за програмиста; останалите ръководства в новото им състояние. 4. Програмиране и тестване на отделните модули. Както е известно, 95 на този етап наред с програмирането самите изпълнители тестват своите реали- зации. През цялото време се извършват оценки на: плановете, доколкото търпят промени — както на всеки етап; написания първичен код; резултатите от тестването на отделните модули; всички ръководства. 5. Интегриране и тестване. Написаните и проверени отделни модули започват да се интегрират, което изисква оценяване на: текущо ревизираните планове; резултатите от тестването на интегрирането; актуализирания първичен код; описанието на приемните тестове; всички ръководства. 6. Тестване на крайния продукт. Тук се оценяват: текущо ревизираните планове; всички ръководства; актуализираният първичен код; документът за описание и управление на версиите; докладът за тестване на крайния продукт (системата). Изтегляне 2.27 Mb. Сподели с приятели:
|