 |
Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | |
Класс категория
|
|
Для реализации этого пункта рекомендации целесообразно воспользоваться классификацией, которая построена по принципу “сверху вниз” с необходимым описанием контекста, в котором обнаружена ошибка.
На первом уровне классификационной схемы выделены 5 признаков ошибки:
1) где произошла ошибка;
2) на что похожа ошибка;
3) как была сделана ошибка;
4) когда произошла ошибка;
5) почему произошла ошибка.
Каждый признак представлен в виде набора категорий, разделов и подразделов.
Проблема создания надежных ПИ имеет 2 стороны:
- разработка средств и методов, применение которых в процессе создания ПИ позволит обеспечить ему высокие показатели надежности;
- развитие самой теории надежности: создание стройной системы показателей надежности; планирование уровня надежности на начальных этапах разработки ПИ; возможность оценить показатели надежности по результатам испытаний программ; контроль уровня надежности в процессе эксплуатации ПИ и т.д.
Известно, что ПИ создаются коллективами разработчиков на протяжении определенного времени. После этого они могут поставляться пользователям для эксплуатации по назначению. При этом возникает ряд задач организационного, методологического, структурного и технологического характера, требующих разрешения. Используемые технологии обычно охватывают какой-нибудь один или несколько этапов ЖЦ ПИ и ориентированы на определенный тип разрабатываемого ПИ. Например, ПИ обработки экономической информации. Наибольшую известность получили такие методы, как нисходящее проектирование, восходящее проектирование и метод расширения ядра. В основу последнего положен модульный принцип построения программ.
Нисходящее проектирования (проектирование сверху вниз) основано на пошаговом уточнении и анализе потоков данных.
Первоначально “идея” записывается на языке высокого уровня, возможно, с использованием математической символики, экономических и инженерных расчетов. В последующем осуществляется переход на более низкие иерархические уровни детализации проекта и языки низших уровней (схемы, диаграммы, псевдокоды) вплоть до алгоритмических.
В процессе эксплуатации ПИ могут подвергаться незначительным изменениям и корректировке. Процесс эксплуатации ПИ продолжается до полного морального износа вследствие изменений внешней среды функционирования.
Вопросами о том, как организовать и выполнять действия на любом из этапов ЖЦ для того, чтобы повысить надежность конечного продукта, какие средства и методы избрать (а во многих случаях и разработать) для достижения поставленной цели – получения надежных ПИ, занимается технология программирования (ТП).
ТП – это совокупность знаний о способах выполнения работ по всем этапам создания ПИ, которая позволяет при оптимальных затратах ресурсов получить ПИ с заданными потребительскими и эксплуатационными свойствами. Под ресурсами в данном случае понимаются время на создание ПИ (Т 
), стоимость (К ), машинное время (Т 
) и т.д.
Анализ потока данных базируется на исследовании процессов передачи и преобразования входных элементов. Первоначальный поток данных разбивается на вход, преобразование и выход, интерпретируемые в программы управления вводом, выводом, непосредственно обработки информации.
Рекурсивно используемый на отдельных ветвях древовидной структуры программы метод разбиения на вход, преобразование, выход позволяет получить модули низшего уровня.
В методах расширения ядра и восходящего проектирования (проектирование снизу-вверх) больше внимания уделяется не определению функций всей программы в целом, а тем частным функциям, которые потребуются проектируемой программе.
В методе расширения ядра осуществляется локализация основных частей программы, базирующихся на типичных для данного класса задач процессах обработки информации. Это – контроль входных данных, сортировка, редактирование файлов, записей и др. В дальнейшем осуществляется их детализация с первоначальными определениями и последующими изменениями управляющих связей. Перестройка связей между модулями определяется необходимостью функционального объединения процедур обработки.
В методе восходящего проектирования определяются функции самого низкого уровня, обеспечивающие такие элементарные операции, как управление внешней памятью, выбор библиотечных процедур и т.д. Далее разработанные модули, реализующие эти функции, используются для определения функций и создания модулей более высокого уровня. Это – такие как обновление файлов, корректировка информации и другие, которые, в свою очередь, включаются в части программы на более высоком уровне. Процесс продолжается до тех пор, пока разработка программы не будет завершена.
Обе последние стратегии проектирования ориентированы на разработку небольших по объему вспомогательных систем ПИ с имеющимися аналогами реализации. Они также могут использоваться при модификации программ.
Специфика и реальные условия разработки различных ПИ вызвали необходимость создания технологий проектирования, облегчающих процесс разработки, обеспечивающих последовательное и детальное описание этапов проектирования, взаимодействия разработчиков и пользователей на этапе создания и поддержания ПИ. В конечном итоге они способствуют повышению качества создаваемого ПИ.
К таким ТП можно отнести HIPO-технологию и следующие технологии:
▪ PSL/PSA (Problem Statement Language/ Problem Statement Analyzer), включающая язык и анализатор постановки задач;
▪ SREM (Software Requirement Engineering Methodology) – методология разработки требований к ПО, ориентированная на разработку систем реального времени;
▪ PDM (Process Design Methodology) – методология проектирования процессов, предназначенная и для проектирования, и для тестирования ПС;
▪ SADT (Structured Analysis and Design Technique) – методология структурного анализа и проектирования, состоящая из графического языка ссылок и языка синхронизации. Она используется при разработке систем самых широких классов и т.д.
С целью управления надежностью ПС возникает необходимость определения количественных показателей надежности на различных этапах его разработки. Это обосновывается следующей необходимостью:
1. Надежность ПС, оставаясь ценным качеством, достигается в действительности за счет 2-х основных моментов: Во-1-х, за счет другой характеристики ПС, например объема программ, времени их выполнения, объема внешней памяти и т.д. Во-2-х, за счет характеристик процесса создания ПС, таких, как стоимость разработки (К или Ц ), материальные ресурсы, выделенные на создание ПС, график выполнения работ и т.д. Желательно, чтобы при выборе характеристик ПС и организации процесса его разработки можно было принимать компромиссные решения.
2. Количественные показатели надежности могут использоваться для оценки достигнутого уровня ТП, для выбора метода проектирования будущего ПС. Применение на практике любой новой идеи по технологии программирования связано с дополнительными затратами. Количественный показатель надежности позволяет установить критерии, по которым можно оценивать новые методы и вырабатывать рекомендации по их применению.
3. На этапе тестовых испытаний ПС показатели надежности могут служить критериями завершенности тестирования, т.к. выявлена высокая степень корреляции показателей надежности (например, средней наработки на отказ) с количеством проверок. Это позволяет связать надежность с плановыми сроками выполнения программного проекта.
4. При эксплуатации ПС часто возникает необходимость проведения работ по сопровождению. Известно, что внесение изменений, модификация ПС ухудшают надежность. Поэтому по количественному показателю надежности можно судить об эффективности и целесообразности внесения того или иного изменения.
Основным средством определения количественных показателей надежности являются модели надежности. Под ними понимают математическую модель, построенную для оценки зависимости надежности от заранее известных или оцененных в ходе создания ПС параметров. В связи с этим определение показателей надежности принято рассматривать в единстве 3-х процессов – предсказание, измерение, оценивание.
Предсказание – это определение количественных показателей надежности исходя из характеристик будущего ПС (например, из объема, из сложности и т.д.). Обычно выполняется после проектирования, когда известна структура разрабатываемого ПС.
Измерение – это определение количественных показателей надежности, основанное на данных об интервалах между отказами, полученных при выполнении программ в условиях тестовых испытаний.
Оценивание – это определение количественных показателей надежности, основанное на данных об интервалах между отказами, полученными при испытании ПС в реальных условиях функционирования.
Все модели надежности можно классифицировать по тому, какой из перечисленных процессов они поддерживают (предсказывающие, прогнозные, измеряющие, оценивающие). Причем модели надежности, которые в качестве исходной информации используют данные об интервалах между отказами, можно отнести и к измеряющим, и к оценивающим в равной степени. Некоторые модели, основанные на информации, полученной в ходе тестирования ПС, дают возможность делать прогнозы поведения ПС в процессе эксплуатации.
Рассмотрим классификацию моделей надежности ПС (МНПС), приведенную на Рис.1. МНПС подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности. Они основываются на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели). Эмпирические модели базируются на анализе структурных особенностей программ. Они рассматривают зависимость показателей надежности от числа межмодульных связей, от количества циклов в модулях, от отношения количества прямолинейных участков программы к количеству точек ветвления и т.д. Часто эмпирические модели не дают конечных результатов показателей надежности. Однако они включены в классификационную схему, т.к. развитие этих моделей позволяет выявлять взаимосвязь между сложностью ПС и его надежностью. Эти модели можно использовать на этапе проектирования ПС, когда осуществлена разбивка на модули и известна его структура.
Аналитические модели представлены двумя группами: динамические модели и статические. В динамических МНПС поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем. Здесь учитывают только зависимость количества ошибок от числа тестовых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных.
Для использования динамических моделей необходимо иметь данные о появлении отказов во времени. Если фиксируются интервалы каждого отказа, то получается непрерывная картина появления отказов во времени. Это – группа динамических моделей с непрерывным временем. С другой стороны, может фиксироваться только число отказов за произвольный интервал времени. В этом случае поведение ПС может быть представлено только в дискретных точках. Это – группа динамических моделей с дискретным временем. Рассмотрим основные предпосылки, ограничения и математический аппарат моделей, представляющих каждую группу, выделенную на схеме.
7 .3.1. Аналитические модели надежности
Аналитическое моделирование НПС включает четыре шага:
1) определение предположений, связанных с процедурой тестирования ПС;
Рис. 7.1. Классификационная схема МНПС
2) разработка или выбор аналитической модели, базирующейся на предположениях о процедуре тестирования;
3) выбор параметров моделей с использованием полученных данных;
4) применение модели – расчет количественных показателей надежности по модели.
