Главная страница  Анализ эмпирических данных 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [ 26 ] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

) В Этот процент входят интерфейсы программа/программа, программа/системные программные средства, сопряжения с ленточными устройствами, с базой данных и с пользователем.

включавшими дополнения и изменения программ практически всех типов и значительные изменения интерфейсов, что привело к изменению частоты ошибок по большому числу категорий. Среди прочих результатов анализа данных, представленных в табл. 3.1, наиболее интересными представляются следующие.

- Для всех базовых проектов характерно малое количество документированных ошибок в операционных системах и вспомогательных программных средствах. Это объясняется использованием в основном лишь выверенных возможностей системного программного обеспечения. Исключение составляет модификация MODIBR Проекта 2, в которой нашли применение довольно редко используемые служебные функции операционной системы (ОС), что позволило выявить целый ряд ошибок указанного класса. Однако во всех базовых проектах операционные системы можно считать свободными от ошибок.

- Несмотря на то что относительное распределение ошибок в различных интерфейсах менялось от проекта к проекту, общий их процент) оказался практически постоянным для всех трех проектов: 11,6- 15,7% от суммарного количества ошибок. (Этот факт пока еще не нашел должного объяснения.)

- В тех случаях, когда в результате подавляющего влияния требований устранения ошибок нарушались принципы управления конфигурацией программных средств (Проект 2 и Проект 3), отмечался почти постоянный уровень ошибок компоновки (0,6- 1,9%). В этой связи заметим, что в Проекте 4, где условия технического обслуживания действующей системы не вызывали нарушения указанных принципов, ошибки компоновки вообще отсутствовали. (Более подробный анализ данных табл. 3.1 проводится в последующих разделах этой главы.)

Характеристики ошибок в прикладных программах Проекта 5. Распределение по основным категориям ошибок в прикладных системах реального вре-



мени и имитационных программах Проекта 5 показано на рис. 3.2 и 3.3; гистограммы приводятся для каждой из обобщенных категорий ошибок и содержат четыре уровня аргумента в соответствии с четырьмя основными этапами нисходящей разработки программ. Эти уровни обозначены цифрами от О до 3, причем нулевому уровню отвечает система, состоящая из макетов программ, или заглушек , а все последующие уровни служат для пошаговой детализации функций системы и замены макетов реальными программами. Аналогичные данные для операционной системы реального времени и средств проверки работоспособности программных изделий не приводятся, так как онн не могут считаться полными.

Основной целью проведенного распределения данных об ошибках по этапам является определение характерных изменений комбинаций ошибок, возникающих на различных этапах нисходящей разработки программ. Подобные изменения показаны на рис. 3.2, где приводится распределение общего числа ошибок в прикладных программах. Поскольку нулевой этап разработки, который может быть назван процессором заглушек , практически не содержит программ вычислительного характера, а выходные данные предназначались в основном для целей отладки, неудивительно, что на этом этапе отсутствуют ошибки вычислений и вывода данных. Что касается ошибок ввода данных, то, согласно гистрограммам, они явно присутствуют на нулевом этапе. По-видимому, это вполне закономерно, поскольку программы ввода на нулевом этапе разработки составляют значительную долю.

Некоторые из представленных на рис. 3.2 категорий ошибок обнаруживают тенденцию к убыванию, другие -к возрастанию. Так, например, основная доля ошибок вычислительного характера была зафиксирована на этапах 1 и 2 разработки прикладных программ. Большинство ошибок манипулирования данными также относится к начальным этапам разработки. Однако доля ошибок указанных двух категорий убывает на заключительных этапах разработки. Очевидно, это связано с тем, что процесс тестирования позволяет устранять ошибки начальных этапов,




: giZ3 0123 01Z3 опз виз впз 01Z3 опз виз дт впз ощоц

1 lifr


Рис. 3.2. Результаты системных испытаний прикладных программ системы реального времени.

го -15

Зтст! нисходящего


Зтст 0

Этап /

Зтст 2

ЗтпЗ

10 S

гопз опз опз тз апз апз апз виз апзDJP опз от от

Ь il illh It il У illll il S ill it - 15 ilSe-l a*

Рис. 3.3. Результаты системных исиыхавш! программного обеспечения имитатора системы реального времени.



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [ 26 ] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

© 2000 - 2018 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.