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

16

лишь

36 %

на

этапе

кодирования.

Однако

эти

ошибки

могут

быть

очень

дорогостоящими

(DO

4

I=1,5

и

DO

4

I=1.5

).

В

общем

случае

кодирование

освоено

лучше,

чем

другие

этапы

создания

программ,

и

очень

четко

формализовано.

2.5 

Тестирование

Этап

тестирования

обычно

в

финансовых

затратах

со-

ставляет

половину

расходов

на

создание

системы.

Плохо

спла-

нированное

тестирование

приводит

к

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

увеличе-

нию

сроков

разработки

системы

и

является

основной

причиной

срывов

графиков

разработки.

В

процессе

тестирования

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

данные,

харак-

терные

для

системы

в

рабочем

состоянии,

т.е.

данные

для

тес-

тирования

выбираются

случайным

образом.

План

проведения

испытаний

должен

быть

составлен

заранее,

обычно

на

этапе

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

Тестирование

подразумевает

три

стадии:

−

автономное;

−

комплексное

и

−

системное.

При

автономном

тестировании

модуль

проверяется

с

по-

мощью

данных,

подготовленных

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

При

этом

программная

среда

модуля

имитируется

с

помощью

программ

управления

тестированием,

содержащих

фиктивные

программы

вместо

реальных

подпрограмм,

с

которыми

имеется

обращение

из

данного

модуля

(заглушки).

Подобную

процедуру

называют

про-

граммным

тестированием,

а

программу

тестирования

—

UUT 

(тестирующей

программой).

Модуль,

прошедший

автономное

тес-

тирование,

подвергается

комплексному

тестированию.

В

процессе

комплексного

тестирования

проводится

совме-

стная

проверка

групп

программных

компонент.

В

результате

имеем

полностью

проверенную

систему.

На

данном

этапе

тес-

тирование

обнаруживает

ошибки,

пропущенные

на

стадии

ав-

тономного

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

Исправление

этих

ошибок

может

со-

ставлять до ¼ от общих

затрат.

Системное

(или

оценочное)

тестирование

—

это

завер-

шающая

стадия

проверки

системы,

т.е.

проверка

системы

в

це-

17

лом

с

помощью

независимых

тестов.

Независимость

тестов

яв-

ляется

главным

требованием.

Обычно

Заказчик

на

стадии

при-

емки

работ

настаивает

на

проведении

собственного

системного

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

Для

случая,

когда

сравниваются

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

нескольких

систем

(имеется

альтернативная

разработка),

такая

процедура

известна

как

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

тестирование.

В

процессе

тестирования,

для

определения

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

выполнения

программы

вводится

ряд

критериев:

1)

каждый

оператор

должен

быть

выполнен,

по

крайней

мере,

один

раз

для

заданного

набора

тестов,

и

про-

грамма

должна

выдать

правильный

результат;

2)

каждая

ветвь

программы

должна

быть

опробована,

и

программа

при

этом

должна

выдать

правильный

ре-

зультат;

3)

каждый

путь

в

программе

должен

быть

испытан

хотя

бы

один

раз

с

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

набора

тестовых

данных,

и

программа

должна

выдать

правильный

результат;

4)

для

каждой

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

программы

необходимо

располагать

набором

тестовых

данных,

позволяющих

установить,

что

программа

правильно

реализует

дан-

ную

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

Хотя

критерии

1)

и

2)

кажутся

схожими,

в

действительно-

сти

они

сильно

разнятся.

Например,

арифметический

оператор 

IF

в

Fortran:

IF

 (

Выражение) N1, N2, N3. 

Критерий

1)

подразумевает,

что

IF

должен

быть

выпол-

нен,

в

то

время

как

2)

подразумевает

различные

наборы

данных,

для

того

чтобы

выполнились

условия

N1

,

N2

,

N3

(т.е.

передачу

на

эти

метки).

В

общем

случае

не

существует

единого

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

критерия,

определяющего

«хорошо

проверенную»

программу.

Тесно

связаны

с

тестированием

понятия

«верификация»

и

«испытание».

Испытание

системы

осуществляется

посредством

тести-

рования.

Цель

такой

проверки

—

показать,

что

система

функ-

18

ционирует

в

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

с

разработанными

на

нее

специфика-

циями.

Верификация

заключается

в

выполнении

доказательств,

что

программа

удовлетворяет

своим

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

Современный

процесс

разработки

программ

не

позволяет

реализовать

обе

указанные

концепции.

Для

ситуаций,

не

кон-

тролируемых

тестовыми

данными,

система,

прошедшая

испы-

тания,

может

дать

неверные

результаты.

После

проведения

ве-

рификации

система

работает

правильно

лишь

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

первоначальных

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

и

допущений

о

поведении

ок-

ружающей

среды;

формальные

доказательства

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

программ

весьма

сложны

и

слабо

разработаны.

Общий

процесс

создания

правильных

программ

с

помо-

щью

процедур

испытания

и

верификации

называется

аттеста-

цией.

Различаются

три

вида

отклонения

от

нормальной

работы

системы.

Сбой

системы

—

это

явление,

связанное

с

нарушением

системой

установленных

на

нее

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

Данные,

при

обработке

которых

правильными

алгорит-

мами

системы

происходит

сбой,

называются

выбросом.

Ис-

правление

выброса

можно

предусмотреть

в

программе,

так

что

не

каждый

выброс

может

приводить

к

сбою.

Ошибка

—

это

алгоритмический

дефект,

который

создает

выброс

(программная

ошибка).

Различают

понятия

«правильная»

и

«надежная»

програм-

ма.

Правильная

программа

—

это

та,

что

удовлетворяет

своим

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

Что

касается

надежной

программы,

то

она

не

обязательно

является

правильной,

но

выдает

приемлемый

ре-

зультат

даже

в

том

случае,

когда

входные

данные

либо

условия

ее

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

не

удовлетворяют

принятым

допущениям.

Естественно

стремление

иметь

«живую»

(robustness)

систему,

т.е.

систему,

способную

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

широкий

спектр

вход

-

ных

данных

при

неблагоприятных

условиях.

Система

является

правильной,

если

в

системе

нет

ошибок,

а

ее

внутренние

данные

не

содержат

выбросов.

Система

назы-

вается

надежной,

если,

несмотря

на

сбои,

она

продолжает

удов-

19

летворительно

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

Это

особо

видно

на

примере

операционной

системы

(ОС),

включающей

систему

обработки

сбоев.

При

обнаружении

выброса

такая

система

прекращает

работу

с

сохранением

текущей

информации

и

возможности

продолжения

работы

после

устранения

выброса.

2.6 

Эксплуатация

и

сопровождение

С

учетом

затрат

на

эксплуатацию

и

сопровождение

вре-

менные

затраты

на

разработку

программной

системы

можно

представить

так

(рис.

2.5):

1)

анализ

требований;

2)

определение

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

3)

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

4)

кодирование;

5)

автономное

тестирование;

6)

комплексное

тестирование;

7)

сопровождение.

Рис.

2.5

—

Временные

затраты

на

реализацию

этапов

жизненного

цикла

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

обеспечения

Анализ

требований

(3%)

Определение

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

(3%)

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

(5%)

Кодирование

(7%)

Автономное

тестирование

(8%)

Комплексное

тес-

тирование

(7%)

Сопровождение

(67%)

20

Ни

одна

из

вычислительных

систем

не

остается

неизмен-

ной

по

мере

ее

эксплуатации.

Это

объясняется

несколькими

причинами,

среди

которых

можно

выделить

следующие:

1.

Заказчик

обычно

не

может

четко

сформулировать

свои

требования,

редко

бывает

удовлетворен

созданной

сис-

темой

и

поэтому

настаивает

на

внесении

изменений

в

готовую

систему.

2.

Могут

быть

обнаружены

ошибки,

пропущенные

при

тестировании.

3.

Могут

потребоваться

специальные

модификации

сис-

темы

для

частных

условий

функционирования,

связан-

ные

с

различными

применениями.

4.

Сопровождение

многочисленных

компонентов

систе-

мы.

Рассмотрим

затраты,

оказывающие

наибольшее

влияние

на

процесс

разработки

системы.

В

первую

очередь

следует

от-

метить,

что

методы

разработки,

стимулирующие

раннее

завер-

шение

проекта,

могут

привести

к

весьма

высоким

затратам

по

сопровождению.

Поэтому

не

следует

ориентироваться

на

воз-

можно

ранний

переход

на

этап

кодирования.

Хотя

написание

кодов

и

создает

иллюзию

благополучия

у

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

проек-

та,

однако

это

чревато

такими

последствиями,

как

многократное

тестирование

и

возникновение

большого

числа

проблем

на

бо-

лее

позднем

этапе

сопровождения. 

Задачу

сопровождения

обычно

трактуют

как

задачу

отра-

ботки

непомерно

возрастающего

числа

версий

системы.

Пусть

некоторая

система

содержит

компоненты

A,

B,

C

и

установлена

у

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

I,

II,

III

(рис.

2.6).

Рис.

2.6

—

Исходные

системы

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

В

процессе

эксплуатации

системы

потребитель

I

обнару-

жил

ошибку

и

сообщил

об

этом

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

Последний

кор-

ректирует

ее

и

направляет

исправленный

модуль

A

’ 

всем

поль-

A

B

C

I

A

B

C

III

A

B

C

II