Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования и науки Республики Казахстан

Карагандинский Государственный Технический Университет

Кафедра ИС

Реферат

По дисциплине: Управление качеством

На тему: Моделирование и обеспечение надежности в процессе создания программных средств

Выполнил: Аманбаева А.Н.

ст.гр. ИС-08-2

Проверил: Зайцева С.В.

Караганда, 2011

Содержание

Введение

1. Основные понятия и показатели надежности программных средств

1.1 Основные понятия надежности систем

1.2 Показатели качества и надежности программных средств

2. Обеспечение качества и надежности в процессе разработки сложных программных средств

2.1 Требования к технологии и средствам автоматизации разработки сложных программных средств

2.2 Планирование и управление обеспечением качества и надежности программ

2.3 Ресурсы, необходимые для обеспечения надежности функционирования программных средств

2.4 Финансовая информация в сети Internet

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

3.1 Требования к средствам обеспечения тестирования

3.2 Виды тестирования сложных программных средств

3.3 Оценка методов тестирования по показателю "эффективность /стоимость"

Заключение

Список использованной литературы

Введение

v

Опыт создания и применения сложных информационных систем (ИС) в последние десятилетия выявил множество ситуаций, при которых сбои и отказы их функционирования были обусловлены дефектами комплексов программ и отражались большим ущербом. Вследствие ошибок в программах автоматического управления погибло несколько отечественных, американских и французских спутников, происходили отказы и катастрофы в сложных административных, банковских и технологических информационных системах. Было показано на примере разработки программ противоракетной обороны США (СОИ), что при существующем уровне развития методов, технологии и средств автоматизации проектирования есть предельные масштабы и объемы комплексов программ, при которых невозможно обеспечить при допустимых затратах необходимую надежность их функционирования и безопасности применения. Очень высокие требования к качеству программ для подобных систем принципиально не могут быть выполнены, вследствие реальных ограничений всех видов ресурсов: бюджета, длительности разработки, характеристик вычислительных систем и квалификации специалистов. Применение таких систем при недостаточной их надежности и безопасности теряет смысл и может становиться не только бесполезным, но и опасным.

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

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

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

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

1. Основные понятия и показатели надежности программных средств

1.1 Основные понятия надежности систем

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

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

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

В основе теории надежности лежат понятия о двух возможных состояниях объекта или системы: работоспособном и неработоспособном.

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

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

- контроль исправности системы и полного соответствия ее состояния и функций технической документации;

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

- поиск, выявление и локализацию источников и результатов сбоев, отказов и неисправностей в системе.

1.2 Показатели качества и надежности программных средств

Формализации показателей качества программных средств посвящена группа нормативных документов. В международном стандарте ISO 9126:1991. при отборе минимума стандартизируемых показателей выдвигались и учитывались следующие принципы: ясность и измеряемость значений, отсутствие перекрытия между используемыми показателями, соответствие установившимся понятиям и терминологии, возможность последующего уточнения и детализации. Выделены характеристики, которые позволяют оценивать ПС с позиции пользователя, разработчика и управляющего проектом. Рекомендуется 6 основных характеристик качества ПС, каждая из которых детализируется несколькими (всего 21) субхарактеристиками (рис.1):

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

Надежность рекомендуется характеризовать: уровнем завершенности (отсутствия ошибок), устойчивостью к ошибкам и перезапускаемостью;

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

Эффективность рекомендуется характеризовать ресурсной и временной экономичностью;

Сопровождаемость - удобством для анализа, изменяемостью, стабильностью и тестируемостью;

Переносимость предлагается отражать: адаптируемостью, структурированностью, замещаемостью и внедряемостью.

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

Близким к описанному стандарту по идеологии, структуре и содержанию является стандарт ГОСТ 28195-89. На верхнем, первом уровне выделено 6 показателей - факторов качества: надежность, корректность, удобство применения, эффективность, универсальность и Сопровождаемость. Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240. Каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав используемых факторов, критериев и метрик предлагается выбирать в зависимости от назначения, функций и этапов жизненного цикла ПС.

Рис. 1. Характеристики качества программных средств

В стандарте ГОСТ 28806-90 формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в стандарте 28195-89.

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

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

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

2. Обеспечение качества и надежности в процессе разработки сложных программных средств

2.1 Требования к технологии и средствам автоматизации разработки сложных программных средств

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

- к объекту разработки на данном этапе - к его программным и информационным компонентам, а также к интерфейсу между ними и с внешней средой;

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

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

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

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

Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE 1209-1992. Стандарт содержит рекомендации по оценке и выбору инструментальных средств, поддерживающих процессы жизненного цикла программных средств, включая процессы управления проектами, процессы разработки и процессы, следующие за разработкой, а также интегральные процессы жизненного цикла ПС. Для оценки и выбора инструментальной среды и CASE-средств стандартом (раздел 7) рекомендуется использовать, приведенные ниже, наборы правил и критериев. Группы критериев в стандарте выделены и сформированы с учетом общих требований стандарта ISO 9126:1991 по оценке качества программных продуктов (см.п. 1.1).

Требования стандарта к средствам управления проектом сложного ПС включают:

- способность CASE-средства оценивать стоимость, формировать планы и другие показатели проекта по данным, вводимым пользователем;

- управление действиями и ресурсами путем поддержки ввода пользователем данных для планирования проекта, данных о фактических действиях и анализ этих данных, включая: планы, ресурсы компьютеров, назначение персонала, бюджет проекта, а также возможность определения условий выполнения проекта;

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

- управление качеством разрабатываемого ПС - ввод и обработка данных о качестве, их анализ и генерация отчетов об управлении качеством;

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

2.2 Планирование и управление обеспечением качества и надежности программ

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

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

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

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

2.3 Ресурсы, необходимые для обеспечения надежности функционирования программных средств

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

При анализе целесообразно разделять, также как Планы, ресурсы, необходимые для непосредственного решения основных функциональных задач ПС, и ресурсы, требующиеся для обеспечения надежности и безопасности функционирования ПС. Соотношение между этими видами ресурсов в реальных ПС зависит от сложности и состава решаемых функциональных задач, степени их критичности и требований к надежности и безопасности всей информационной системы. В различных ПС ресурсы на обеспечение надежности могут составлять от 5-20% до 100-300% от ресурсов, используемых на решение функциональных задач, т.е. в особых случаях (критические военные системы) могут превышать последние в 2-4 раза.

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

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

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

3.1 Требования к средствам обеспечения тестирования

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

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

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

В стандарте IEEE 1209-1992 сформулированы общие требования к функциям средств автоматизации тестирования, входящим в CASE-средства, которые должны обеспечивать:

- определение тестов - реализацию процесса тестирования пользователем: ввод тестовых наборов, генерацию тестовых наборов, генерацию тестовых данных, ввод ожидаемых, эталонных результатов, генерацию ожидаемых результатов;

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

- управление тестами и участком программы, для которого CASE-средство может автоматически выполнять тестовые наборы;

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

- анализ тестовых результатов - возможность CASE-средства автоматически анализировать тестовые результаты: сравнение ожидаемых и реальных результатов, сравнение файлов, статистический анализ результатов;

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

- анализ производительности программы, когда она выполняется: загрузку центрального процессора, загрузку памяти, обращения к специфицированным элементам данных и/или сегментам кода, временные характеристики;

- верификацию условий или исключительных ситуаций во время выполнения теста;

- моделирование среды - поддержку процесса тестирования с помощью модели, например, возможность CASE-средства автоматически генерировать входы моделируемых систем на основе полученных системных выходов.

3.2 Виды тестирования сложных программных средств

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

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

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

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

3.3 Оценка методов тестирования по показателю "эффективность /стоимость"

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

- интенсивность (вероятность) обнаружения и устранения ошибок за единицу времени тестирования;

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

При наличии значительного количества ошибок в программе наработка на отказ, используемая как показатель надежности на начальных этапах, чрезвычайно низка (рис.2 - жирная сплошная кривая). Интенсивное устранение ошибок на этих этапах простейшими методами слабо влияет на рост надежности программ. (Тонкие сплошные линии на рис.2 соответствуют изменению надежности при последовательном применении методов тестирования). Однако их применение необходимо, так как на начальных этапах более сложные методы еще менее эффективны. Наработка на отказ начинает заметно возрастать при применении стохастического тестирования и тестирования в реальном времени после того как все предшествующие методы выявления ошибок исчерпали свои возможности. Такая особенность изменения показателя наработки на отказ отражает особое значение тестирования в реальном времени для соответствующего класса ПС. Для других классов ПС также могут быть выявлены методы, позволяющие достигнуть наивысших показателей качества на завершающих этапах отладки, когда основная часть ошибок выявлена более простыми методами.

Приведенный качественный анализ "эффективности/стоимости" методов тестирования показывает пути возможной оптимизации затрат на достижение заданной надежности программ.

Заключение

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

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

Список использованной литературы

1. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. /Под ред. А.А. Красилова. - М.:Радио и связь, 1985.

2. Безопасность информации. Сб. материалов международной конференции. М.: Изд.РИА. 1997.

3. Гантер Р. Методы управления проектированием программного обеспечения: Пер. с англ. /Под ред. Е.К. Масловского. -М.:Мир,1981.

4. Герасименко В.А. Защита информации в автоматизированных системах обработки данных. Книга 1 и 2. М.: Энергоат-омиздат. 1994.

5. Гласе Р. Руководство по надежному программированию: Пер. с англ. М.: Финансы и статистика, 1982.

6. Гласе Р., Нуазо Р. Сопровождение программного обеспечения: Пер. с англ. /Под ред. Ю.А. Чернышева. - М.: Мир, 1983.

7. Евстигнеев В.А. Применение теории графов в программировании. М.:Наука, 1985.

8. Испытательные центры за рубежом.-М.: Изд. стандартов, 1989.

9. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). М.: Изд.ЛОРИ. 1996.

10. Карповский Е.Я., Сагач В.В., ЧернецкийА.А. Надежность алгоритмов управления. К.: Техника, 1983.

11. Костогрызов А.И., Липаев В.В. Сертификация качества функционирования автоматизированных информационных систем. М.: Изд. Вооружение. Политика. Конверсия. 1996.

12. Котляров В.П. CASE-технология и возможности современных CASE-средств в поддержке этапов проектирования программного продукта // Системная информатика. Новосибирск. ВО "Наука". Сибирская издательская фирма. Вып 4.1995.

Размещено на Allbest.ru