Файл: Технология раработки програмного обеспечения УП.pdf

246 

 
Проверка

изделий

Уровень

испытаний

Класс

испытаний

Категория

испытаний

А

В

С

Надежностные

испытания

/

Проверка

устойчивости

/

Возвратная

проверка

/

Пусковые

испытания

P

И

О

Конфигурационные

испытания

P

И

О

Режимы

испытаний

I

—

Проводится

группой

испытаний

II

—

Контролируется

группой

испытаний

III

—

Группа

испытаний

не

участвует

Подразделения,

проводящие

испытания

P

—

группа

разработки

О

—

группа

обслуживания

И

—

группа

испытаний

/

—

испытания

исключены

(X)

(

)

(

)

8.6.2 Организационная структура группы испытаний 

Общее

правило

организации

деятельности

по

обеспече-

нию

качества

программного

изделия

заключается

в

установле-

нии

подотчетности

соответствующих

процедур

как

можно

бо-

лее

высокому

уровню

руководства

фирмы

и

отделении

их

от

функции

разработки.

Группа

испытаний

в

этом

смысле

должна

быть

органом

контроля

деятельности

других

функциональных

групп,

особенно

групп

разработки

и

выпуска

документации,

и

потому

следует

принять

меры,

предотвращающие

причины

раз-

ногласий

между

ними.

Наиболее

рациональная

схема

взаимо-

действия

представлена

на

рис.

8.9,

где

группа

испытаний

вхо-

дит

в

состав

сектора

компоновки

и

выпуска.

Организуя

испытания

программного

изделия,

необходимо

иметь

четкий

ответ

на

вопрос:

«где

кончается

процесс

оценки

и

начинается

процесс

отладки

программного

изделия»?

Прежде

всего,

следует

ограничить

деятельность

испытателей,

возложив

на

них

только

обязанность

фиксировать

факт

наличия

ошибки.

Им

нельзя

разрешать

диагностировать

причины

ошибок,

и,

бо-

Окончание табл. 8.7 

247 

лее

того,

указывать

точное

место

их

возникновения.

Если

не

проводить

в

жизнь

такое

распределение

труда,

то

никогда

не

удастся

отделить

задачи

от

обязанностей

испытателей

и

разра-

ботчики

будут

уповать

на

то,

что

группа

испытаний

сама

за-

вершит

отладку

программ.

Рис.

8.9

—

Организация

взаимосвязи

при

проведении

испытаний

Необходимо

продумать

вопрос,

на

кого

следует

возло-

жить

ответственность

за

компоновку

программ

в

систему,

осо-

бенно

в

условиях,

когда

в

проекте

участвует

несколько

фирм-

подрядчиков.

Объединение

функций

компоновки

и

испытаний

уменьшает

число

подразделений-участников

проекта

и

не

при-

водит

к

утрате

объективности

оценок.

При

этом

должно

четко

выполняться

требование

—

на

группе

разработки

лежит

полная

ответственность

за

устранение

обнаруживаемых

ошибок.

Типичный

путь

эволюции

испытаний

можно

представить

следующим

образом:

•

Испытания

не

проводятся,

разработчики

сами

отлажи-

вают

программные

средства

и

выпускают

их

для

рас-

пространения.

•

Пользователи

присылают

много

замечаний,

указы-

вающих

на

обилие

ошибок,

в

организации

выделяется

−

Выпуск документации; 

−

Обеспечение  целостно-
сти проекта; 

−

Анализ  эксплуатацион-
ных характеристик; 

−

Испытание изделия; 

−

Проверка документации; 

−

Разработка  стандартных 
процедур; 

Вице-президент отдела 

исследований и разработок 

Программирование 

изделия 

Компоновка и 

выпуск 

Проектирование 

системы 

Аппаратные 

средства 

Периферийное 

оборудование 

248 

автономная

группа

испытаний,

которая

не

оказывает

влияние

на

проектирование.

•

Деятельность

группы

испытаний

становится

столь

ак-

тивной,

что

руководитель

группы

разработки

протес-

тует,

заявляя:

«Как

я

могу

уложиться

в

плановые

сро-

ки,

если

группа

испытаний

придирается

к

любой

мело-

чи

и

не

соглашается

рекомендовать

изделие

к

выпус-

ку»?

Тогда

группа

испытаний

становится

частью

груп-

пы

разработки,

и

их

совместная

деятельность

продол-

жается

успешнее,

т.к.

испытатели

утвердили

«незави-

симый»

стиль

работы

и

не

склонны

допускать

наруше-

ния

этой

традиции.

•

Руководители

проекта

и

руководство

фирмы

осознают,

что

проблема

испытаний

требует

профессионального

подхода

и

что

сотрудники

группы

испытаний

могут

играть

важную

роль

в

процессах

планирования

и

про-

ектирования

изделий.

Эта

группа

начинает

постоянно

участвовать

в

составлении

планов

и

спецификаций.

В

результате

вновь

возникают

трения,

т.к.

руководитель

группы

разработки

часто

нейтрализует

предложения

испытателей.

«Если

мы

все

будем

делать

так,

как

тре-

буют

испытатели,

мы

не

выполним

календарный

план,

и

нам

не

хватит

отпущенных

ресурсов».

Поэтому

группа

испытаний

выделяется

из

группы

разработки

и

становится

самостоятельной

организационной

едини-

цей.

Независимо

от

места,

которое

занимает

группа

испытаний

в

проектной

организации,

следует

не

упускать

из

виду

необхо-

димость

стимулирования

работы

ее

сотрудников.

Ошибочно

желание

укомплектовать

группу

испытаний

стажерами

или

людьми,

не

проявившими

себя

как

разработчики.

Испытания,

проведенные

этими

людьми,

несут

больше

вреда,

чем

просто

отсутствие

испытаний.

Будет

затрачена

масса

времени

и

сил

на

отладку

самих

тестов,

общение

между

испытателями

и

разра-

ботчиками

будет

происходить

на

крайне

низком

уровне

взаимо-

действия,

и

программный

продукт

получит

крайне

плохую

ре-

путацию

среди

потребителей.

Только

из

хороших

проектиров-

249 

щиков

и

программистов

получаются

хорошие

испытатели.

Осо-

бенно

удачно

использование

системных

программистов

и

спе-

циалистов

по

системному

прикладному

анализу.

Должны

быть

предусмотрены

пути

самостоятельного

служебного

роста

для

таких

людей.

8.6.3 Организация испытаний в фазах исследований 

и анализа осуществимости 

В

фазе

исследований

деятельность

группы

испытаний

должна

предусматривать

интенсивное

общение

с

другими

груп-

пами

для

решения

вопросов

о

том,

какие

режимы

испытаний

следует

установить,

когда

начнутся

испытания

класса

B,

какие

новые

методики

или

средства

должны

быть

привлечены

для

этих

испытаний.

Необходимо

провести

анализ,

какие

ресурсы

потребуются

на

каждой

стадии

испытаний,

и

дать

оценку

сро-

кам

выполнения

и

предполагаемым

затратам.

На

этой

стадии

составляется

предварительный

бюджет,

обычно

этот

документ

составляет

кто-либо

из

сотрудников

группы

разработки

на

основании

данных,

поступивших

от

ос-

тальных

групп.

Роль

группы

испытаний

на

этом

этапе

—

наи-

более

объективно

оценить

свои

предполагаемые

затраты

(бюд-

жет).

Основной

алгоритм,

лежащий

в

этой

оценке,

—

стоимость

испытаний

пропорциональна

стоимости

разработки.

В

стадии

анализа

осуществимости

группа

обработки

го-

товит

соглашение

о

требованиях.

В

этот

период

группа

испыта-

ний

имеет

первую

возможность

повлиять

на

качество

изделия,

предъявляя

свои

материалы

для

выработки

соглашения

о

требо-

ваниях.

В

процессе

поиска

компромиссных

решений,

пересмот-

ра

и

утверждения

этого

документа

утверждаются

и

необходи-

мые

уровни

испытаний.

Группа

испытаний

здесь

играет

актив-

ную

роль,

побуждая

разработчиков

к

введению

количественных

характеристик

в

требования

и

цели.

Соглашения

о

требованиях

являются

одновременно

и

планом

разработки,

они

содержат

довольно

много

сведений

о

путях

реализации

проекта.

В

этих

соглашениях

предусматрива-

ется

специальный

раздел,

в

котором

группа

испытаний

описы-

вает

свой

план

проверок.

250 

В

этой

фазе

группа

испытаний

особое

внимание

уделяет

тем

разделам

соглашения

о

требованиях,

где

речь

идет

о

внеш-

них

условиях,

в

которых

должно

работать

программное

изде-

лие,

об

эргономических

характеристиках

и

действующих

огра-

ничениях.

На

протяжении

всей

фазы

анализа

осуществимости

груп-

па

испытаний

изучает

соглашение

о

требованиях

и

на

основе

этого

анализа

составляет

собственные

планы

(план

разработки

спецификаций

испытаний,

установление

начальных

дат

испы-

таний

класса

B

и

каждого

цикла

и

др.).

8.6.4 Организация испытаний в фазах 

конструирования и программирования 

Составление

плана

испытаний

является

основной

рабо-

той,

которую

выполняет

группа

испытаний

в

этой

фазе.

Обяза-

тельным

условием

завершения

этой

работы

является

утвержде-

ние

соглашения

о

требованиях,

и

поэтому

ее

окончание

намеча-

ется

на

период

фазового

обзора.

При

составлении

плана

испытаний

используется

принцип

декомпозиции

планов.

План

испытаний

является

детализацией

соглашения

о

требованиях

и

содержит

подробную

информацию,

достаточную

для

того,

чтобы

рецензенты

смогли

уловить

сте-

пень

соответствия

программы

испытаний

класса

B

этому

испы-

танию.

Создавая

план

испытаний,

группа

испытаний

принимает

все

меры

к

тому,

чтобы

спланировать

все

виды

работ

—

обору-

дование,

программное

обеспечение,

расходные

материалы

и

др.

Фаза

программирования

начинается

с

момента

появления

внешней

спецификации.

Сразу

после

получения

этого

докумен-

та

группа

испытаний

начинает

анализировать

его

на

соответст-

вие

соглашению

о

требованиях,

сообщая

группе

разработки

свои

замечания.

После

завершения

работ

над

внешней

спецификацией

группа

испытаний

начинает

готовить

спецификацию

испыта-

ний.

Спецификация

испытаний

представляет

собой

декомпози-

цию

плана

испытаний

и

подробно

описывает

все

тесты,

кото-

рые

предстоит

выполнить,

включая

описание

ожидаемых

ре-

зультатов.

Поскольку

спецификация

испытаний

в

значительной