Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Тема 1.3. Надежность программных продуктов. Факторы надежности




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

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

  1. работоспособное – такое состояние системы, при которой она способна выполнять заданные функции, с параметрами установленными технической документацией
  2. неработоспособное

В процессе функционирования системы возможны переходы от одного состояния к другому. С этими переходами связано событие отказа и восстановления. Существует три вида отказа:

  1. устойчивый
  2. самоустраняющийся
  3. перемежающийся

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

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

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

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

1) пригодность для применения:

­ пригодность для применения

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

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

­ способность к взаимодействию

­ соответствия стандартам и правилам проектирования

2) надежность

­ отсутствие ошибок

­ устойчивость к ошибкам

­ перезапускаемость

3) применяемость

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

­ обучаемость

­ простота использования

4) эффективность

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

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

5) сопровождаемость

­ удобство для анализа

­ изменяемость

­ стабильность

­ тестируемость

6) переносимость

­ адаптируемость

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

­ замещаемость

­ внедряемость

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

Объекты уязвимости   Дестабилизирующие факторы и угрозы надежности   Методы предотвращения угрозы надежности:   Последствия нарушения надежности:
    Вычислит. процесс   Объектный код   Инф-ция для потребителей Внутренние: 1. ошибки проектирования при постановке задачи 2. ошибки алгоритмизации задачи 3. ошибки программирования 4. недостаточное качество средств защиты   Внешние: 1. ошибки персонала при эксплуатации 2. искажение инф-ции в каналах связи 3. сбои и отказы аппаратуры ЭВМ 4. изменение конфигурации системы 1. предотвращение ошибок проектирования в технологии 2. систематическое тестирование 3. обязательная сертификация 1. разрушение выч-ного процесса 2. разрушение инф-ции базы данных 3. разрушение текста программ 4. разрушение инф-ции для потребителя
 
Оперативные методы повышения надежности:
1. временная избыточность 2. инф-ционная избыточность 3. программная избыточность

Объектами уязвимости влияющими на надежность ПС являются:

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

2. информация, накопленная в БД, отражающая объекты внешней среды в процессе ее обработки

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

4. информация подаваемая пользователю и на исполнительные механизмы, являющаяся результатом обработки исходных данных и информации накопленной в БД.

На эти объекты воздействуют различные дестабилизирующие факторы:

Внутренние:

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

2) алгоритмические ошибки разработки при непосредственной спецификации функций ПС, при определении структуры и взаимодействии компонент комплекса программ, а также при использовании БД.

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

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

Внешние:

1) ошибки оперативного и обслуживающего персонала в процессе эксплуатации ПС.

2) искажение в каналах телекоммуникации, информации, поступающей от внешних источников и передаваемой потребителя, а также недопустимые для конкретной информационной системы характеристики потоков внешней информации.

3) сбои и отказы в аппаратуре вычислительных средств.

4) изменение состава и конфигурации комплекса, взаимодействующей аппаратуры инф-ционной системы за пределы проведенные при испытании или сертификации и отлаженной ПС в эксплуатационной документации.

Цели и принципы стандартизации документирования прикладных ПС.

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

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

Предлагается общая структура технологических и эксплутационных документов, объектов и процессов ЖЦ ПС, которая предназначена для использования в индустрии создания ПС. Эта структура содержит номенклатуру документов, которые должны быть использованы во время создания и сопровождения программного средства, для определения, управления и совершенствования сложных комплексов программ. Архитектура и содержание документов на ПС далее не конкретизируется в деталях как их реализовать, а описывается точное содержание, как их документировать.

Документацию на ПС можно разделить на:

1. Технологическая документации процесса разработки, включающую подробное техническое описание и подготавливаемую для специалистов ведущих проектирование, разработку и сопровождение ПС, детального освоения развитии и корректировки программы и данных на всем ЖЦ.

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

Технологическая документация в наименьшей и наибольшей степени должна отражать процессы ЖЦ:

  1. регламентировать структуру и состав этапов, работ и документов ЖЦ ПС,
  2. обеспечивать их адаптацию к характеристикам объекта проектирования внешней и операционной среды,
  3. поддерживать и регламентировать процессы организации и планирования реализации ЖЦ конкретных ПС,
  4. формулировать выполнение и документирование конкретных работ при проектировании, разработки и сопровождении ПС,
  5. регламентировать процессы обеспечения качества конкретных работ при проектировании, разработки и сопровождении ПС, показателей качества ПС.

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

  1. базовые документы определяющие цели и методы применения конкретной версии ЖЦ ПС.
  2. ссылочные документы на руководство по организации подобных разработок, включая общесистемные стандарты и нормативные документы различных уровней.
  3. стандарты и нормативные документы ЖЦ программ, планирование и технологию разработки документации, состав и описание инструментальных средств, автоматизации разработки.
  4. стандарты и нормативные документы непосредственно используемые при разработке, испытаниях, сопровождении программ на различных этапах.

Технологические документы создаваемых и сопровождаемых прикладных ПС должны определять:

  1. структуру и содержание исходных и отчетных документов по этапам разработки, испытаний и сопровождения ПС.
  2. логическую структуру программных и информационных документов и БД проекта ПС,
  3. спецификацию на внутрении межмодульные интерфейсы компонентов прикладных ПС и на интерфейсы с внешней средой,
  4. язык и правила программирования, идентификацию компонентов, комментирование текстов программ и описание данных,
  5. методы тестирования и аттестации программных компонентов и ПС в целом.
  6. оформление формата и обозначения отчетных и результатирующих документов.

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

Эксплуатационная документация ПС включает:

  1. руководство операторов, осуществляющих инсталляцию и непосредственно управление режимами решения функциональных задач регламентированными в информационной системе,
  2. руководство операторов, пользователей, использующих ПС по прямому назначению,
  3. документацию сопровождения ПС, включая руководство по сопровождению и модификации программ и информации БД.
  4. справочные руководства, по применению ПС.
  5. учебное руководство по освоению ПС.



Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 729; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.01 сек.