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

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

*) Один день уходит на описание проблемы с помощью Уведомления о проблеме и один день на передачу материалов по исправлению ошибок.

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

Стремление к полному закрытию проблем было гтаким же, что и во время приемочных испытаний. Однако в силу территориальной разобщенности на передачу материалов из группы исправления дефектов в группу испытаний требовался один день. Именно этим обстоятельством можно объяснить тот факт, что для высоко- и низкоприоритетных проблем длительность приемочных и системных испытаний была различной [(разница составляла два дня)). Малое значение величины At для среднеприоритетных проблем необъяснимо. Системные испытания проводились в подразделении, территориально удаленном от того места, где осуществлялось устранение дефектов в программных изделиях.

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

4.5.4. Связь между проблемами проектирования и программного обеспечения

Изучение связи между проблемами проектирования и программирования позволяет выяснить, может ли число Уведомлений о проблемах проектирования (УПП), возникающих в ходе разработки Проекта 3, служить показателем ожидаемого числа Уведомлений о проблемах программного обеспечения (УППО), возникающих в последующих фазах формальных испытаний.



Па(лвн=0,2* □ Sbiipoc

/ .

° /

0 у

□ /о /о

Г* /

О 200 ш 600 S00 то

Число уВедошешй а проблемах проетироЗания

Рис. 4.7. Связь проблем программного обеспечения с проблемами проектирования в случае Проекта 3.

Результаты исследований (рис. 4.7) свидетельствуют о существовании довольно тесной корреляции на уровне выделенных ранее подсистем {г = 0,97)) При этом обнаружилась тенденция, состоящая в том, что подсистемы, которые подвергались критике в ходе анализа проектных решений, оказывались также и объектами Уведомлений о проблемах программного обеспечения. Интерес представляет одна точка выброса , которой соответствует сравнительно небольшое число Уведомлений о проблемах проектирования. Дальнейшее исследование показало, что отвечающей данной точке подсистеме не уделялось достаточного внимания, так как она аналогична программным средствам, созданным ранее в рамках других проектов, и поэтому не рассматривалась как новая.

*) На уровне программ зависимость существенно отличалась от линейной.



4.5.5. Зависимость между загрузкой ЭВМ

и числом Уведомлений о проблемах программного обеспечения

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

Основой для таких исследований послужили данные, полученные на этапах испытаний Проекта 3. Исследователи имели все основания предполагать, что распределение Уведомлений о проблемах во времени может оказаться разделимым . Поэтому данные, касающиеся машинного времени и Уведомлений о проблемах программного обеспечения, были разделены на две категории: данные испытаний н данные разработки. Испытания состояли в различного рода проверках, выполняемых персоналом независимой группы испытаний с помощью специальных тестовых процедур. В процессе разработки проекта машинное время требовалось для верификации программ, разрешения проблем и контроля правильности принятых решений.

Диаграмма, иллюстрирующая еженедельное использование машинного времени испытателями и разработчиками, приведена на рис. 4.8. Можно видеть два явно выраженных семейства Уведомлений о проблемах, имеющих существенно разные средние значения, принадлежащие разным совокупностям данных. Это можно легко объяснить, исходя из характера рассматриваемых видов деятельности по использованию машинного времени: группа испытаний работает по расписанию, а формируемые Уведомления о проблемах возникают стохастически, в ходе выполнения запла-нированных испытаний. Все разработчики одновременно используют машинное время лишь по мере необходимости, в частности для выявления проблем, исправления дефектов и повторного тестирования программ и формируют Уведомления о проблемах



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.
Копирование материалов разрешено исключительно при условии цититирования.