книги / Надежность программного обеспечения систем обработки данных

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

Событиями называются результаты произведенных работ. Событие конкретизирует процесс планирования, исключает возможность различного толкования итогов выполненных работ. Результаты перечисленных выше ра­ бот, т е события, можно записать так: «разработка мо­ дуля М завершена», «комплексное рабочее тестирование подсистемы завершено».

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

последующим

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

завершающим.

Любая последовательность работ в сетевом графике,

видов путей а) от исходного события до завершающего события —

полный путь, или просто путь; б) от исходного события до некоторого события —

путь, предшествующий этому событию; в) от данного события до завершающего — путь,

последующий за данным событием; г) между двумя какими-либо событиями, из которых

ни одно не является исходным нлн завершающим,— путь между событиями i и./;

221

6

Изобразив в виде сетевого графика последователь­ ность отображенных на рис 11 2 работ, можно получить значительно лучшее представление о проекте, о взаимо­ связи составляющих его работ Этот сетевой график по­ казан на рис 11.3. Ребра графика помечены названиями соответствующих работ, рядом с названием проставлена продолжительность выполнения работы Под графиком расположена ось времени, дающая представление о сро­ ках начала и завершения любой из работ (проекции вершин графика на временную ось)

Анализ данного сетевого графика позволяет, иапрнмер, установить, что работа <44 дблжна быть завершена прежде, чем начата работа <43-1, чего нельзя было понять

из лентЬчного графика (рис 11.2) Наличие фиктивной работы Р указывает на то, Что началу работы <45 должно

предшествовать завершение определенных работ Анализ продолжительности выполнения всех работ показывает, что одни из путей (<42, <46-1, <46-2) по продолжительно­ сти самый длинный Это критический путь, величина ко­ торого определяет сроки выполнения всего планируемо­ го комплекса работ Он характеризуется еще и тем, что не располагает резервами времени

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

Рассчитаем ранние н позднне сроки начала и оконча­

222

А4

11 4 Сетевой график выполнения работ с учетом резерва времени

А4

Прн расчете параметров сетевого графика предпола­ гается, что работа над проектом начинается в момент времени, равный нулю Это и есть ранний срок начала работ Ранний срок окончания каждой из первоначальных работ равен продолжительности их выполнения. Ранни* сроки начала н окончания работ рассчитываются, начи­ ная от исходного события и заканчивая завершающим событием Ранний срок окончания работы равен продол­ жительности этой работы плюс ранний срок ее начала. Для события, которому предшествуют несколько путей (на рнс. U 5 — события 5, 6, 7, в), раиинй срок начала юследующей работы выбирается равным максимальному из ранннх сроков окончания предшествующих работ На критическом пути ранний срок окончания работы, предшествующей завершающему событию, соответствует минимальной продолжительности работ над проектом и равен позднему сроку окончания этой работы.

Расчет поздннх сроков начала и окончания работ производится в обратном порядке, т. е, от завершающего события к исходному. Для работ критического пути позд­ ние н ранние сроки соответственно начала н окончания

223

11 6 Представление сетевого графика в виде ленточного

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

Сетевые графики можно сделать более наглядными и простыми двумя способами Во-первых, работы сетевого графика могут быть представлены ленточным графиком с указанием плановых сроков, а также раннего срока начала ц позднего срока окончания каждой из работ, как это показано на рис. 11.6. Во-вторых, чтобы проиллю­ стрировать зависимости между работами, можно вос­ пользоваться вертикальными стрелками, соединяющими работы, зависящие друг от друга (рис. 11.7).

117 Представление сетевого графика в виде аенточпого с отображением зависимостей между работами*

=работы критического пути — другие работы

-резерв времени «— зависимость между работами

294

Исследованные в данной главе аспекты прогнозиро­ вания ресурсов разработки, а также методы планиро­ вания работ могут быть положены в основу реализации системы управления качеством программных средств. Естественно, что при планировании ресурсов должны быть учтены и требования по обеспечению надежности разрабатываемого продукта.

Вопросы к главе II

I Цель и задами планирования ресурсов разработки

2. Сформулируйте ограничения на планирование ресурсов разработки 3 Сопоставьте методы прототипов и оценочные методы с точки зрения

качества планирования 4 Сформулируйте ограничения методов параметрических уравнений

5Преимущества косвенных методов планирования ресурсов

6Охарактеризуйте возможности применения графических методов

планирования ресурсов

Г л а в а 12

МОДЕЛИРОВАНИЕ И ОЦЕНКА НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Под моделью процесса разработки ПО понимаете!» математическая модель, описывающая взаимосвязь меж­ ду параметрами разрабатываемого программного средст­ ва, оказывающими непосредственное влияние на потреб­ ные ресурсы разработки, с целью оценки ресурсов ^ •овможности предсказания надежностных характеристик Программ, потребных ресурсов их эксплуатации или па­ раметров, их определяющих.

Оценка надежности ПО базируется в определенной мере на теории надежности аппаратуры, где разработа­ ны определенные математические методь!, позволяющие не только оценивать, но и прогнозировать Надежность создаваемого продукта.

225

12.1 СИСТЕМА п о к а з а т е л е й ОЦЕНКИ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Одной из предпосылок использования математичес­ кой статистики в проведении анализа надежности ПО является наличие данных. Существует достаточно много путей получения данных о надежности, но вопрос состоит

втом, как определить необходимое множество данных.

Врезультате того, что первоначальные капитальные затраты на технику и ПО, а также затраты на разработку последующего программного обеспечения достаточно вы­ соки, с самого начала развития технологии обработки

информации с использованием ЭВМ имел место постоян­ ный интерес к проектированию ПО.

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

Одной из первых программ оценки качества конструи­ рования явилась программа, обеспечивающая сбор дан­ ных об исполнении отдельных элементов (модулей, про­ цедур, команд) проблемной программы, работающей под управлением операционной системы. На основе получен­ ных данных можно было сделать заключение о наиболее нагруженных участках проблемной программы, выявить участки, вызывающие задержку исполнения, получить причины задержки и выдать рекомендации к дополнитель­ ным усилиям по «расшивке» узких мест.

Наряду с началом) подобных экспериментов имели место попытки применить некоторые статистические мето­ ды к оценке качества ГГО. Основные усилия были на­ правлены на создание критериев качества ПО и установ­ ление требований к пакетам разрабатываемых программ. Некоторые из типичных подходов и будут рассмотрев в последующем изложении.

Для изложения последующего материала напомним некоторые понятия математической статистики и теории надежности.

В качестве показателей надежности выступают функ­ ция надежности R(t) и среднее время между ошибками программного обеспечения /ср Оба показателя позволя­ ют оценить ресурсы, затрачиваемые на разработку ПО,

2 2 6

■такие, как время, отражающее трудовые затраты на создание ПО, время на отладку на ЭВМ и т. д.

Стандартными функциями вероятности здесь высту­ пают:

W )= P (t'> 0: F(t)= l-R(t)-,

dF _ — dR[t)

№ш ------- щ —

где С — случайное племенное время сбоя,

—частное значение случайной переменной;

т— функция надежности, порождающая вероятность отсут­ ствия сбоев в интервале времени от 0 до t,

т— кумулятивная функция распределения, порождающая

вероятность сбоя в интервале времени от 0 до /;

— вероятность того, что время прохождения сбоя лежит Вне рассматриваемого интервала.

В области надежности ПО удобно определять другую функцию условной вероятности, называемую количеством (скоростью, темпом) ошибок, или функцию риска Z(/). Эту функцию можно определить в терминах вероятности того, что ошибка произойдет в интервале от / до /-+-Д{, т. е, вероятность появления ошибки:

P (t< t'< t+ b t)= f(t)\t.

Вероятность ошибки в интервале от t до f+Af при условии, что ошибка не произошла до t:

P (i< t'< t + M /t'> t)=Z(t)bt.

Из этих определений следует, что

Решая это дифференциальное уравнение относительно R(t) при начальных условиях /?(0)=1, получим:

-уШх

Среднее время проявления ошибки задается следую­ щей зависимостью:

Для простого случал, когда Z(t) принимается постоян­ ной на всем интервале исследования, уравнения (12.1), (12.2) и (12.3) принимают вид:

227

Одним из способов оценки (Ср является наблюдение за поведением программы в определенный временнбй период и на участке между двумя последующими ошиб­ ками. Время между обнаружением двух последователь­ ных ошибок имеет тенденцию к возрастанию по мере обнаружения и корректировки ошибок. Экстраполируя этот ряд величин в будущее, можно с определенной вероятностью предсказать общее количество ощибок в разработанной системе. Гораздо лучшим приемом, тре­ бующим меньшее количество точек данных для той же точности прогноза, является постулирование модели для удаления ошибок и использования тестовых данных для оценки каждой модели.

Модель ошибок может основываться на предвари­ тельной работе, связывающей R(t) н /ср с данными от­ ладки. Число ошибок, остающихся в программе, модели­ руется статистически в терминах числа исправленных ошибок, размера программы и начального числа ошибок. Делается дополнительное допущение, что темп сбоев ПО пропорционален числу остающихся ошибок. Это позволя­ ет записать выражение для надежности ПО и среднего времени для проявления ошибок.

Для оценки этих Двух констант в модели необходимо собрать тестовые данные ранее описанного типа как ми­ нимум в двух отдельных точках на этапе тестирования и интеграции. Если данные собраны в более чем двух точках, то могут использоваться дополнительные наборы данных для исследования состоятельности параметров и для проверки или внесения изменений в основную модель. Если модель проверяется н парные оценки параметров являются состоятельными, то данные в нескольких тесто­ вых точках могут использоваться для формирования совокупной оценки.

Многие из руководителей, осуществляющих контроль за разработкой ПО, фиксируют ошибки, обнаруженные в процессе тестирования, и строят графики числа обна­ руженных ошибок по календарному времени (недели,

228

X fr)

12 1 Динамика отладки во времени (идеальный случай)

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

Схематически излагаемый подход представлен на рис. ,12.1. На рисунке через 2 (т) обозначены нормализо­ ванные накопленные и отлаженные ошибки; а — остав­ шиеся невыделенные ошибки; Ь — исправленные накоп­ ленные ошибки и т — Накопленное время отладки в меся­ цах. Здесь показан случай, когда имеет место прибли­ жение к равновесию без генерации новых ошибок за счет исправления. Когда кажется, что наклон кривой накоп­ ленных выявленных ошибок приближается к некоторой константе (по крайней мере почти не возрастает во време­ ни), то качество системы достигает условия равновесия. До тех пор дока не будет предпринято крупных измене­ ний в подходе или в затрачиваемых .усилиях на тести­ рование, можно ожидать лишь незначительных измене­ ний в повышении надежности ПО. Схематическое изобра­ жение этой ситуации представлено на рис. 12.2.

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

229

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

В литературе и практике разработки ПО используется широкий спектр моделей, которые могут быть объединены

Большая часть рассматриваемых моделей является количественными и может быть использована при изме­ рении, управлении и предсказании уровня завершенно­ сти ПО на стадиях разработки и тестирования.

12.2 МОДЕЛИ, БАЗИРУЮЩИЕСЯ НА ТЕОРИИ НАДЕЖНОСТИ ТЕХНИЧЕСКИХ СИСТЕМ

Количественными мерами для использования в модели описаиия качества ПО являются функции надежности Х12.4), функция рнска (12.5) и среднее время между ошибками (12.6).

230