- •Общая характеристика технологии программных средств.
- •Принципиальная схема разработки программных средств. (Технология, процесс создания).
- •Способы описания алгоритмов.
- •Описание алгоритма с помощью таблиц решения.
- •Технология системного проектирования программных средств. Принципиальная схема разработки.
- •Современные методы и средства разработки прикладных программных средств.
- •Характеристики качества программного обеспечения.
- •Языки программирования.
- •Надёжность программного обеспечения.
- •Показатели надёжности.
- •Факторы, определяющие надёжность по.
- •Стандартизация. Дисциплина и творчество программирования.
- •Виды программ и программных документов.
- •Виды программных документов.
- •Эксплуатационные документы.
- •Классификация документов.
- •Работы, выполняемые на стадии «Эскизный проект».
- •Структурное программирование.
- •Терминология и обозначения.
- •Очевидно, что g и h являются простыми программами, иначе f была бы не простой.
- •Число управляющих линий в блоке h удовлетворяет соотношению:
- •Графическая иерархическая документация (гид).
- •Простейшие пути повышения качества программ.
- •Классификация ошибок.
- •Сквозной структурный контроль.
- •Стиль программирования и качества программ.
- •Case – технологии.
- •Моделирование данных.
- •Что дает применение case-средств?
- •Средства реализации case-технологий.
- •Общая характеристика case-средства
- •Особенности рабочего интерфейса
- •Начало работы с проектом в среде
- •Разработка диаграммы вариантов использования в среде Rational Rose.
- •Разработка диаграммы классов в среде
- •Диаграмма классов
- •Разработка диаграммы состояний в среде Rational Rose.
- •Разработка диаграммы последовательности в среде Rational Rose.
- •Разработка диаграммы кооперации в среде Rational Rose.
- •Разработка диаграммы компонентов в среде Rational Rose.
- •Разработка диаграммы развёртывания в среде Rational Rose.
- •Практические примеры диаграмм.
- •Актеры.
- •Диаграмма классов (основы)
- •Ассоциации
- •Заказ от одного клиента
- •Полезные советы по использованию диаграмм классов
- •Диаграмма взаимодействия
- •Диаграмма кооперации
- •Диаграмма кооперации
- •Диаграмма пакетов
- •Диаграмма состояний
- •Верификация программ.
- •Восходящее тестирование, нисходящее тестирование.
- •Методы тестирования компонентов.
- •Структура коллектива программистов.
- •Общая структура коллектива, работающего над крупным проектом.
- •Трудовые затраты по видам работ (человеко/месяц).
Надёжность программного обеспечения.
В настоящее время существуют две взаимосвязанные проблемы: стоимость и надёжность.
Программная ошибки имеет место тогда, когда программа работает не так как предполагает пользователь. Наличие ошибки в программе – это функция от самой программы и от того, что ждёт от неё пользователь.
Надежность ПО – вероятность того, что программа какой-то период времени будет работать бес сбоев с учетом степени их влияния выходные результаты. Другими словами, надёжность ПО - есть функция от ущерба, наносимого ошибкой пользователя. Надёжность не является свойством присущем программе, а в большей мере относится к тому, как используется программа.
Для технического обеспечения начальный этап характеризуется высокой интенсивностью отказов, которая достаточно быстро снижается по мере выявления и устранения неисправных элементов в процессе отладки.
Второй этап характеризуется неизменной интенсивностью отказов.
Третий этап - износ. Не надёжность ПО целиком определяется ошибками разработки. Чтобы подчеркнуть различие между отказом и ошибкой рассмотрим поведение отказов оборудования и ошибок ПО с точки зрения их зависимости от входных данных и от времени.
Отказ оборудования не зависит от обрабатываемой информации. Программные ошибки зависят от входной информации. Причина появления ошибки в какой-то конкретный момент времени заключается в том, что в этот момент была обработана определённая последовательность входных данных вызвавшая появление ошибки. Отказы оборудования зависят от времени, ошибки ПО являются функцией от текущей входной информации.
Достижения в области повышения надёжности оборудования в настоящее время более ощутимы, чем надёжности ПО – это объясняется рядом причин, среди которых целесообразно выделить следующие:
ПО значительно сложнее оборудования. Входным потоком информации для центрального процессора является поток машинных команд. Для выполнения машинной команды центральный процессор получает информацию о коде операции и нахождении операнда. Входной поток информации для ПО в зависимости от желания пользователя намного сложнее.
Различие заключается в области применения оборудования, в основном не зависит от области применения. Большая часть ПО чувствительна к области применения.
Базируется на природе составных элементов и ПО. Центральный процессор (ЦП) представляет собой объединение стандартных блоков. Разработчик ЦП заинтересован в количестве, размере, скорости и конфигурации стандартных блоков, с помощью которых он создаёт ЦП с заданными параметрами. Блоки, из которых компонуются ПО, боле примитивны с точки зрения конечного результата. К ним относятся операторы систем программирования, участки ранее написанных программ. Это значит, что разработчик ПО для достижения надёжности ПО должен выполнить более сложную работу, чем разработчик оборудования.
Показатели надёжности.
Под показателями надёжности принято понимать величину или совокупность величин, характеризующих качественно и количественно степень приспособленности систем к выполнению поставленной задачи при применении по назначению.
Качественные показатели не могут быть выражены в виде числа и не содержат информации, позволяющей обосновать предпочтение одного или нескольких конкурирующих вариантов системы при их сравнении. Они указывают на то, что рассматриваемая система обладает определёнными свойствами для выполнения поставленной задачи. Качественные показатели дают возможность отличать системы друг от друга, но не позволяют сравнивать их по степени выполнения поставленной задачи.
Порядковые показатели содержат информацию, позволяющую обосновать предпочтение одного из вариантов системы при их сравнении без качественной оценки предпочтения. Они дают возможность расположить в ряд по степени возрастания надежности, исследуемые варианты системы, но не позволяют оценить на какую величину отличается достигнутый уровень надёжности рассматриваемых вариантов.
Количественные показатели содержат информацию, содержащую оценку степени предпочтения одного варианта системы по отношению к другому из применения по назначению. Количественные показатели выражают надёжность в виде числа. При помощи количественных показателей надёжность измеряется или оценивается в принятой шкале оценок в абсолютных или относительных единицах. Количественные показатели определяют путём непосредственных статистических наблюдений на основе обработки результатов применения или испытания систем, а также путём аналитических расчетов или моделирования процесса функционирования систем.
Они являются основными показателями надёжности, обобщающими наиболее ценную информацию о степени приспособленности систем к применению по назначению.
В первых работах по теории надёжности ПО заимствованы основные положения теории аппаратурной надёжности и применена известная экспоненциальная формула функции надёжности, выражающая вероятность безотказной работы за некоторый промежуток времени t.
В ряде исследований показатель надёжности рассматривается как функция времени наработки. Характерно, что ПО не изменяется существенно по мере наработки, а изменяется в результате устранения ошибок.
Вероятность отказа в работе не имеет прямого отношения к времени наработки в зависимости для оценки надёжности ПО могут быть непосредственно получены на основе свойств программы и элементарных понятий статистики (безотказность).
Вероятность безотказной работы ПО определяется по формуле:
n – число возможных входов в ПО.
y = 0, если выходной результат верен определённой комбинации входных данных.
y = 1, в противном случае.
Pi – вероятность выбора для множества n.
Д ля получения вероятности отказа ПО экспериментальным путём существует определённый подход, если испытания ПО относительно различных входов n (100) и для l из них имеют место отказы, то вероятность отказа ПО оценивается как:
.
Таким образом, представляется через определение вероятности отказа в отношении входного множества данных и через наблюдение интенсивности изменения вероятности отказа по мере устранения ошибок.