Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Московский государственный технологический университет "Станкин"

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

220700_62_Nadezhnost_itestirovanie_Sukhanova_Pr_2014_1.docx

Скачиваний:

Добавлен:

01.07.2025

Размер:

219.39 Кб

Скачать

☆

<<< < Предыдущая 1 23 / 63 4 5 6 > Следующая >>>

Раздел 2. Математические модели надежности программного обеспечения

Тема 1. Математические модели надежности программного обеспечения

Практические занятия 5-6. Математические модели надежности программного обеспечения

План занятия:

Повторение изученных теоретических разделов
Решение типовых задач у доски
Самостоятельное решение задач
Обсуждение решения и анализ основных ошибок
Доклады студентов по теме практического занятия

Теоретические сведения

Модель надежности по Джелински, Моранда и Шумана

Известна модель надежности ПО, разработанная Джелински, Морандой и Шуманом.

Она опирается на теорию надежности аппаратуры

Пусть известны:

R (t) — функция надежности, т. е. вероятность того, что ни одна ошибка не проявится на интервале от 0 до t;

F (t) — функция отказов: вероятность того, что ошибка проявится на интервале от 0 до t;

Z(t)- условная вероятность того, что ошибка проявится на интервале от t до t+dt, при условии что до момента t ошибок не было.

Т — время появления ошибки,

то тогда эти величины связаны соотношением:

(5.1)

Для экспоненциального закона распределения вероятности безотказной работы:

(5.2)

Модель использует результаты наблюдения за поведением программы в течение длительного периода времени.

Задачи для самостоятельного решения студентами

Задача 1.

ПО состоит из 2 однотипных модулей, соединенных последовательно. Интенсивность отказов каждого модуля равна 0,1*10 ^-61/час. Определить интенсивность отказов системы.

Задача 2.

ПО состоит из 2 однотипных модулей, соединенных параллельно. Интенсивность отказов каждого модуля равна 0,1*10 ^-61/час. Определить интенсивность отказов системы.

Задача 3.

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

Задача 4.

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

Задача 5.

ПО состоит из 2 модулей, соединенных последовательно. Средняя наработка на отказ первого модуля равна 10 000час, второго модуля -20000 час. Определить вероятность отказов системы.

Задача 6.

ПО состоит из 2 модулей, соединенных параллельно. Средняя наработка на отказ первого модуля равна 10 000час, второго модуля -20000 час Определить вероятность отказов системы.

Тема 2. Язык моделирования uml

Практическое занятие 7. Организация разработки требований к сложным программным средствам.

План занятия:

Повторение изученных теоретических разделов
Решение типовых задач у доски
Самостоятельное решение задач
Обсуждение решения и анализ основных ошибок
Доклады студентов по теме практического занятия

Теоретические сведения

Метод анализа, выявления и освоения проблемы и интересов заказчика включает следующие действия:

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

Чтобы помочь команде решить эти проблемы, лучше понять потребности пользователей и других заинтересованных лиц, целесообразно использовать методы:

интервьюирования и анкетирования, проведение интервью с 5—15 пользователями и/или заинтересованными лицами; подведение итогов совокупности интервью, формулирование 10—15 требований заказчика и пользователей;
совещания, посвященные анализу и синтезу требований — формулирование и определение целей программного продукта; ознакомление с ними всех участников проекта и установление, что они с ними согласны; если это не так, следует остановиться и уточнениями добиться согласия; обязательно убедиться в согласии заказчиков;
мозговой штурм и отбор идей, чтобы выявить и/или уточнить функции проекта; отсечь нецелесообразные идеи; провести классификацию функций, чтобы определить приоритеты, риски, трудоемкости реализации функций;
анализ прецедентов;
создание моделей ПО на основе первичных требований,
создание прототипов на основе первичных требований.

Состав концепции основных требований к программному средству:

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

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

Задачи для самостоятельного решения студентами

Задача 1.