рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Конспект лекций по дисциплине Надежность систем В данной лекции систематически изложены следующие взаимосвязанные аспекты инженерии ПО

Конспект лекций по дисциплине Надежность систем В данной лекции систематически изложены следующие взаимосвязанные аспекты инженерии ПО - Лекция, раздел Философия, Конспект Лекций По Дисциплине «Надежность Систем» Тема 1. В...

Конспект лекций по дисциплине «Надежность систем»

Тема 1.

В данной лекции систематически изложены следующие взаимосвязанные аспекты инженерии ПО:

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

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

Анализ и характеристика областей знаний SWEBOK

Для наглядного представления понятийного аппарата областей знаний SWEBOK проведем условное разбиение областей на основные (пять для проектирования… увеличить изображение Рис. 1.1.Основные области знаний SWEBOK

Требования к ПО (Software Requirements)

Требования отражают потребности людей (заказчиков, пользователей, разработчиков), заинтересованных в создании ПО. Заказчик и разработчик совместно… Область знаний "Требования к ПО (Software Requirements)" состоит из… · инженерия требований (Requirement Engineering),

Проектирование ПО (Software design)

· базовые концепции проектирования ПО (Software Design Basic Concepts), · ключевые вопросы проектирования ПО (Key Issue in Software Design), · структура и архитектура ПО (Software Structure and Architecture),

Конструирование ПО (Software Construction)

Область знаний "Конструирование ПО (Software Construction)" включает следующие разделы: · снижение сложности (Reduction in Complexity), · предупреждение отклонений от стиля (Anticipation of Diversity),

Тестирование ПО (Software Testing)

Существует две формы проверки кода - модульное и интеграционное. При этом используются стандарты (IEEE 829-1996 и IEEE 1008-1987) проверки и… Область знаний "Тестирование ПО (Software Testing)" включает… · основные концепции и определение тестирования (Testing Basic Concepts and definitions),

Сопровождение ПО (Software maintenance)

Область знаний "Сопровождение ПО (Software maintenance)" состоит из следующих разделов: · основные концепции (Basic Concepts), · процесс сопровождения (Process Maintenance),

Управление конфигурацией ПО

Конфигурация системы - состав функций, программного и технического обеспечения системы, возможные их комбинации в зависимости от наличия… Конфигурация ПО включает набор функциональных и технических характеристик ПО,… Область знаний "Управление конфигурацией ПО" состоит из следующих разделов:

Управление инженерией ПО

Как любое управление, менеджмент ПО базируется на планировании, координации, измерении, контроле и учете процесса управления проектом. Координацию… Область знаний "Управление инженерией ПО (Software Engineering… · организационное управление (Organizational Management),

Процесс инженерии ПО (Software Engineering Process)

Для оценивания и совершенствования процессов программной инженерии используется модель зрелости (Capability Maturity Models - CMM), эту концепцию… Концепция зрелости процесса ПО основывается на интеграции концепции процесса… Зрелость процесса - это степень его четкости определения, управления, измерения, контроля.

Методы и инструменты инженерии ПО

Область знаний "Методы и инструменты инженерии ПО (Software Engineering Tools and Methods)" состоит из разделов: · инструменты инженерии ПО (Software Engineering Tools), · методы инженерии ПО (Software Engineering Methods).

Качество ПО (Software Quality)

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

Жизненный цикл ПС, связь с ядром знаний SWEBOK

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

Контрольные вопросы и задания

1. Назовите цели и задачи программной инженерии.

2. Назовите области знаний SWEBOK инженерии разработки ПО.

3. Приведите базовые понятия области знаний "Тестирование ПО".

4. Определите цели и задачи области знаний "Управление проектом".

5. Определите цели и задачи области знаний "Инженерия качества ПО".

6. Дайте определение ЖЦ разработки ПО.

7. Назовите три основные группы процессов жизненного цикла и перечислите процессы каждой из групп.

8. Назовите организационные процессы ЖЦ и перечислите их.

9. Дайте характеристику процесса управления качеством ЖЦ.

10. Какой международный стандарт определяет перечень и содержание процессов ЖЦ ПО?

11. Все ли процессы, указанные в стандарте, должны быть выполнены при каждой разработке ПО?

 

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

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

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

Исторически в эту схему работ включают:

· разработку требований или технического задания;

· разработку системы или технического проекта;

· программирование или рабочее проектирование;

· пробную эксплуатацию;

· сопровождение и улучшение;

· снятие с эксплуатации.

Основное назначение моделей ЖЦ состоит в следующем:

· планирование и распределение работ между разработчиками и ресурсов, а также управление программным проектом;

· обеспечение взаимодействия между разработчиками проекта и заказчиком;

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

· согласование промежуточных результатов с заказчиком;

· проверка правильности конечного продукта путем его тестирования на запланированных и согласованных с заказчиком наборах тестов;

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

· обсуждение используемых процессов ЖЦ в плане оценки их возможностей и недостатков, проявившихся при их применении, а также определение направлений усовершенствования или модернизации ЖЦ и др.

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

2.1. Процессы ЖЦ стандарта ISO/IEC 12207

При выборе схемы модели ЖЦ для конкретной предметной области, решаются вопросы включения важных для создаваемого продукта видов работ или не включения несущественных работ. На сегодня основой формирования новой модели ЖЦ для конкретной прикладной системы является стандарт ISO/IEC 12207, который задает полный набор процессов (более 40), охватывающий все возможные виды работ и задач, связанных с построением ПС, начиная с анализа предметной области и кончая изготовлением соответствующего продукта. Данный стандарт содержит основные и вспомогательные процессы (рис. 2.1 и рис. 2.2).


увеличить изображение
Рис. 2.1.Схема основных процессов ЖЦ ПС

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

Стандарт ISO/IEC 12207 предоставляет структуру процессов ЖЦ, но не обязывает использовать все процессы в модели ЖЦ ПО или в конкретной методологии разработки ПО.


увеличить изображение
Рис. 2.2.Схема вспомогательных процессов ЖЦ ПС

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

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

Кроме этого, стандарт ISO/IEC 12207 предоставляет основу для принятия ряда других связанных с ним стандартов, таких как

стандарты по управлению ПО, обеспечению качества, верификации и валидации, управлению конфигурацией, метриками ПО и т.д.

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

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

· если процесс вызывается процессом и только процессом , то принадлежит ;

· если функция вызывается более чем одним процессом, то она становится отдельным процессом;

· проверка любой функции в ЖЦ является обязательной.

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

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

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

Важную роль при формировании модели ЖЦ имеют организационные аспекты:

· планирование последовательности работ и сроков их исполнения;

· подбор и подготовка ресурсов (людских, программных и технических) для выполнения работ;

· оценка возможностей реализации проекта в заданные сроки, стоимость и ресурсы.

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

Пример. ЖЦ разработки ПС с задачами и действиями для процесса тестирования. Основное назначение процесса тестирования ЖЦ - выполнение задач процесса на основе входов (входные данные для выполнения задач процесса) и выходов при завершении задач, а также ролей и действий исполнителей этих задач.

В соответствии со стандартом ISO/IEC 12207 были выявлены задачи тестирования и распределены по процессам ЖЦ ПС. В результате был получен единый непрерывный процесс тестирования разных ПС, задачами которого являются подготовка,проведение и оценивание результатов тестирования, которые распределились по 20 действиям (шагам) процесса разработки [2.7,2.9]. Данный подход к тщательному тестированию ПС целесообразно применять, например, для систем реального времени.

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

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

Каждый шаг процесса разработки состоит из набора решаемых задач, распределение по процессам и подроцессам ЖЦ (рис. 2.3).

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


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

Описание семантики задач и шагов процесса тестирования представлено в табл. 2.1.

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

Таблица 2.1. Состав задач процесса тестирования
Шаг процесса Задачи процесса тестирования
1. Создание группы тестирования 1.1. Определение участников процесса тестирования
1.2. Распределение обязанностей в группе и формирование плана тестирования
2. Анализ риска 2.1. Идентификация рисков
2.2. Упорядочение рисков
2.3. Распределение ресурсов
3. Определения целей тестирования 3.1. Идентификация целей тестирования
3.2. Определения критериев прохождения тестов
3.3. Приведения в порядок целей тестирования по оценкам риска
4. Разработка планов тестирования 4.1. Разработка плана тестирования ПС
4.2. Разработка плана интеграционного тестирования
4.3. Разработка плана автономного тестирования
4.4. Разработка плана комплексного тестирования
5. Разработка тестов 5.1. Проектирование и разработка тестов
5.2. Подготовка тестовых данных
5.3. Проверка тестовых документов
6. Автономное и интеграционное тестирование 6.1. Автономное тестирование модулей и анализ результатов
6.2. Интеграционное тестирование
6.3. Повторное тестирование после устранения дефектов
6.4. Анализ результатов интеграционного тестирования
7. Тестирования ПС 7.1. Утверждение среды и ресурсов тестирования
7.2. Тестирование ПС
7.3. Повторное тестирование ПС после устранения дефектов
7.4. Анализ результатов завершения тестирования ПС
7.5. Тестирование инсталляции ПС
8. Составление документа по тестированию ПС и подготовка отчета 8.1. Сбор и анализ данных о результатах тестирования
8.2. Подготовка решений и рекомендаций по использованию ПС
8.3. Подготовка итогового документа о результатах тестирования
8.4. Проверка решений и подготовка документа отчета

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

Типы моделей ЖЦ

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

Каскадная модель ЖЦ

увеличить изображение Рис. 2.4.Каскадная модель ЖЦ программных систем Т.е. делается предположение, что каждая работа будет выполнена настолько тщательно, что после ее завершения и перехода…

Инкрементная модель ЖЦ

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

Спиральная модель

увеличить изображение Рис. 2.6.Спиральная модель ЖЦ разработки программных систем Исходя из возможности внесения изменений, как в процесс, так и в создаваемый… Данная модель ЖЦ допускает анализ продукта на витке разработки, его проверку, оценку правильности и принятия решения…

Эволюционная модель ЖЦ

Использование эволюционной модели предполагает проведение исследования предметной области для изучения потребностей заказчика проекта и анализа… Развитием этой модели является модель эволюционного прототипирования в рамках…

Стандартизация модели ЖЦ

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

Характеристика областей знаний SWEBOK

1. Разработка требований; 2. Проектирование; 3. Конструирование;

Контрольные вопросы и задания

1. Охарактеризуйте понятие модели ЖЦ и назовите основные виды моделей ЖЦ.

2. Опишите каскадную и спиральную модели ЖЦ?

3. Дайте характеристику эволюционной модели ЖЦ.

4. Назовите другие виды моделей ЖЦ.

5. Какие общие черты имеют инкрементная и эволюционная модели?

6. Перечислите основные процессы ЖЦ стандарта.

7. Как построить новую модель ЖЦ на основе стандарта?

8. Перечислите процессы категории организационных процессов ЖЦ стандарта.

9. Назовите задачи и методы тестирования ПС.

10. Назовите основные задачи управления качеством и проектом.

11. Проведите сравнительный анализ модели процессов ЖЦ стандарта 12207 и областей ядра знаний SWEBOK.

12. Определите основные цели областей SWEBOK и процессов ЖЦ.

 

Тема 3. Методы проверки и тестирования программ и систем

 

В фундаментальную концепцию проектирования ПС входят базовые положения, стратегии, методы, которые применяются на процессах ЖЦ и обеспечивают тестирование (верификацию) на множестве тестовых наборов данных. К методам проектирования ПС относятся структурные, объектно-ориентированные и др. Их основу составляют теоретические, инструментальные и прикладные средства, которые влияют на процесс тестирования.

Теоретические средства определяют процесс программирования и тестирования программного продукта. К ним относятся методы верификации и доказательства правильности спецификации программ (см. лекцию 6), метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) в качестве отдельных характеристик как формализованных элементов теории определения правильности и гарантии свойств конечного ПО. Например, концепция " чистая комната " базируется на формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования как процесса, то это проверка правильности работы программы по заданным описаниям тестов и покрытия данными соответствующих критериев программы [7.1-7.5].

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

При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 [7.7] жизненного цикла ПО. В некоторой зарубежной литературе процессы верификации и тестирования отождествляются. С теоретической точки зрения верификация была рассмотрена в лекции 6, здесь же будут определены задачи и действия, соответствующих процессов ЖЦ.

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

Процессы ЖЦ верификация и валидация программ

Для этих процессов определены цели, задачи и действия по проверке правильности создаваемого продукта (рабочие, промежуточные продукты) на этапах ЖЦ.… Процесс верификации.Цель процесса - убедиться, что каждый программный продукт… · на стратегии и критериях верификации применительно ко всем рабочим программным продуктам;

Тестирование программ

Тесты подбираются так, чтобы они охватывали как можно больше типов ситуаций алгоритма программы. Менее жесткое требование - выполнение хотя бы один… Исторически первым видом тестирования была отладка. Отладка - это проверка описания программного объекта на ЯП с целью обнаружения в нем ошибок и последующее их…

Статические методы тестирования

Инспекция ПО - это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов… При инспекции программ рассматриваются документы рабочего проектирования на… Эффективность такой проверки заключается в том, что привлекаемые эксперты пытаются взглянуть на проблему "со…

Динамические методы тестирования

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

Функциональное тестирование

Функциональные тесты создаются по внешним спецификациям функций, проектной информации и по тексту на ЯП, относятся к функциональным его… В задачи функционального тестирования входят: · идентификация множества функциональных требований;

Инфраструктура процесса тестирования ПС

· выделение объектов тестирования; · проведение классификации ошибок для рассматриваемого класса тестируемых… · подготовка тестов, их выполнение и поиск разного рода ошибок и отказов в компонентах и в системе в целом;

Методы поиска ошибок в программах

Ошибка (error) - состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы… Дефект (fault) в программе - следствие ошибок разработчика на любом из этапов… Отказ (failure) - это отклонение программы от функционирования или невозможность программы выполнять функции,…

Классификация ошибок и тестов

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

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

Известно много различных подходов к классификации ошибок, рассмотрим некоторые из них.

Фирма IВМ разработала подход к классификации ошибок, называемый ортогональной классификацией дефектов [7.4]. Подход предусматривает разбиение ошибок по категориям с соответствующей ответственностью разработчиков за них.

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

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

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

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

Фирма Hewlett-Packard использовала классификацию Буча, установив процентное соотношение ошибок, обнаруживаемых в ПО на разных стадиях разработки (рис. 7.2) [7.12].

Это соотношение - типичное для многих фирм, производящих ПО, имеет некоторые отклонения.

Исследования фирм IBM показали, чем позже обнаруживается ошибка в программе, тем дороже обходится ее исправление, эта зависимость близка к экспоненциальной. Так военновоздушные силы США оценили стоимость разработки одной инструкции в 75 долларов, а ее стоимость сопровождения составляет около 4000 долларов.


Рис. 7.2.Процентное соотношение ошибок при разработке ПО

Согласно данным [7.6, 7.11] стоимость анализа и формирования требований, внесения в них изменений составляет примерно 10%, аналогично оценивается стоимость спецификации продукта. Стоимость кодирования оценивается более чем 20%, а стоимость тестирования продукта составляет более 45% от его общей стоимости. Значительную часть стоимости составляет сопровождение готового продукта и исправление обнаруженных в нем ошибок.

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

Тестовые данные служат для проверки работы системы и составляются разными способами: генератором тестовых данных, проектной группой на основе внемашинных документов или имеющихся файлов, пользователем по спецификациям требований и др. Очень часто разрабатываются специальные формы входных документов, в которых отображается процесс выполнения программы с помощью тестовых данных [7.11].

Создаются тесты, проверяющие:

· полноту функций;

· согласованность интерфейсов;

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

· защиту от сбоев аппаратуры и не выявленных ошибок и др.

Тестовые данные готовятся как для проверки отдельных программных элементов, так и для групп программ или комплексов на разных стадиях процесса разработки. На рис. 7.3. приведена классификация тестов проверки по объектам тестирования на основных этапах разработки.


увеличить изображение
Рис. 7.3.Классификация тестов проверки

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

В зависимости от задач, которые ставятся перед тестированием программ, составляются тесты проверки промежуточных результатов проектирования элементов на этапах ЖЦ, а также создаются тесты испытаний окончательного кода системы.

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


Рис. 7.4.Интегрированное тестирование компонент

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

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

Согласно приведенной схеме сначала тестируются компоненты А, В, D независимо друг от друга и каждый с отдельным тестом. После их проверки выполняется проверка интерфейсов для последующей их интеграции, суть которой заключается в анализе выполнения операторов вызова А -> E, B -> C, D -> G, на нижних уровнях графа: компоненты Е, С, G. При этом предполагается, что указанные вызываемые компоненты, так же должны быть отлажены отдельно. Аналогично проверяются все обращения к компоненту F, являющемуся связывающим звеном с вышележащими элементами.

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

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

Служба тестирования ПС

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

Управление процессом тестирования

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

Контрольные вопросы и задания

1. Назовите формальные методы проверки правильности программ.

2. Какие процессы проверки зафиксированы в стандарте?

3. Какие функции у процесса верификации программ?

4. Назовите основные задачи процесса валидации программ.

5. Сравните задачи процессов верификации и валидации программ.

6. В чем отличие верификации и валидации?

7. Определите процесс тестирования.

8. Назовите методы тестирования.

9. Объясните значения терминов "черный ящик", "белый ящик".

10. Назовите объекты тестирования и подходы к их тестированию.

11. Какая существует классификация типов ошибок в программах?

12. Определите основные процессы ЖЦ тестирования ПО.

13. Наведите классификацию тестов для проверки ПО.

14. Какие задачи выполняет группа текстовиков?

15. Какая организация работ в проведении тестирования?

 

Тема 4. Формальные спецификации, доказательство и верификация программ

 

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

В формальных методах нет рутинного написания спецификации на ЯП, а есть анализ текста и описание поведения программы в стиле, близком математической нотации, путем рассуждений и доказательств, принятых в математике. Формальные методы в программировании появились одновременно с самим программированием, на которое повлияли работы по теории алгоритмов А.А. Маркова [6.1], А.А. Ляпунова [6.2], схемы Ю.И.Янова [6.3], формальные нотации языка описания взаимодействующих процессов К.А. Хоара [6.4] и др.

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

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

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

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

Анализ языков формальной спецификации программ

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

VDM-спецификация программ

Этот язык имеет математическую символику, которая легко воспринимается математически подготовленными студентами последних курсов университетов за… · - натуральные числа с нулем; · - натуральные числа без нуля;

Спецификация программ средствами RAISE

В RSL-языке имеются предопределенные абстрактные типы данных и конструкторы сложных типов данных, такие как произведение ( ), множества ( ),… Произведение типов- это упорядоченная конечная последовательность типов …

Спецификации задач концепторным языком

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

Методы доказательства правильности программ

Под доказательством частичной правильности понимается проверка выполнения свойств данных программы с помощью утверждений, которые описывают то, что… Для доказательства частичной правильности используется метод индуктивных… Теорема 6.1. Если выполнены все действия метода индуктивных утверждений для программы, то она частично правильна…

Характеристика формальных методов доказательства

Метод Флойда основан на определении условий для входных и выходных данных и в выборе контрольных точек в доказываемой программе так, чтобы путь… Каждая точка рассматривается для индуктивного утверждения того, что формула… Формирование таких утверждений - довольно сложная задача, особенно для программ с высокой степенью параллельности и…

Доказательство конкретности с помощью утверждений

Рассмотрим формальное доказательство программы, заданной структурной логической схемой и совокупностью утверждений, задаваемых логическими операторами, комбинациями переменных (true/false), операциями (конъюнкция, дизъюнкция и др.) и кванторами всеобщности и существования (табл. 6.1).

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

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

1. Входное условие алгоритма задается в виде начального утверждения:

Выходное утверждение - это конъюнкция таких условий:

o ,

o ,

o ,

т.е.

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

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

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

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

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

Так, оператор присваивания означает, что для всех ( ) выполняется ( ). Результат выполнения алгоритма в точке с нулем может быть выражен утверждением

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


увеличить изображение
Рис. 6.2.Схема сортировки элементов массива Т

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

В точке с одной звездочкой выполнен оператор который меняет местами элементы.

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

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

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

В этой точке также справедливо утверждение

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

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

Доказано, что выполнение алгоритма программы завершено успешно, что означает ее правильность.

3. Этот алгоритм можно представить в виде серии теорем, которые доказываются. Начиная с первого утверждения и переходя от одного преобразования к другому, определяется индуктивный путь вывода. Если одно утверждение - истинно, то истинно и другое. Иными словами, если дано первое утверждение и первая точка преобразования , то первая теорема -

Если - следующая точка преобразования, то второй теоремой будет .

Таким образом, формулируется общая теорема , где и - смежные точки преобразования. Эта теорема формулируетсятак, что если условие "истинное" в последней точке, то истинно и выходное утверждение .

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

4. Далее специфицируются утверждения типа - .

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

6. Доказательство алгоритма программы завершено.

Валидация сценариев требований

Сценарий после трансформации - это последовательность взаимодействий между одним или несколькими акторами и системой, в которой актор выполняет цели… Валидация требований - это процесс выявления ошибок в представлении сценарных… 1. Формализованное описание требований в виде сценариев;

Методы анализа структур программ

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

Верификация и валидация программ

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

Подходы к верификации моделей

Верификация объектных моделей основывается на спецификации следующих элементов: 1. Базовых (простых) объектов ОМ, атрибутами которых являются данные и… 2. Проверенных объектов с помощью операций (функции), используемых в качестве теорем, а все операции, которые…

Метод верификации композиции правильных компонентов

Модель проверки включает в себя идентификацию правильных компонентов; композицию повторных компонентов по их спецификациям; формирование общей… · спецификация компонентов задается в языке диалекта UML [6.23] и содержит… · reuse-компоненты задают функции, спецификации интерфейса и временные свойства;

Перспективные направления верификации программ

Идея создания этого проекта принадлежит Т.Хоару, она обсуждалась на симпозиуме по верифицированному ПО в феврале 2005 г. в Калифорнии. Затем в… В нем сформулированы следующие основные задачи: · разработка единой теории построения и анализа программ;

Контрольные вопросы и задания

1. Дайте определение формальной спецификации.

2. Назовите категории классификации спецификаций.

3. Определите основные понятия формальной спецификации VDM.

4. Определите основные базовые элементы спецификации RAISE.

5. Сравните математические понятия методов VDM и RAISE.

6. Определите цель и структуру концепторного языка.

7. Назовите формальные методы доказательства и приведите. их короткую аннотацию.

8. Определите понятия пред- и постусловий, аксиом и утверждений.

9. Опишите, как проходит процесс доказательства программы, заданной спецификацией.

10. В чем проблемы проведения доказательства программ с по мощью формальных методов?

11. Приведите отличие техники формального доказательства от символьного выполнения программ?

12. Дайте определение верификации и валидации.

13. В чем суть композиции верифицированных программ?

14. Расскажите о международном проекте по верификации.

 

– Конец работы –

Используемые теги: Конспект, лекций, дисциплине, надежность, систем, данной, Лекции, систематически, изложены, следующие, Взаимосвязанные, аспекты, инженерии, ПО0.173

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Конспект лекций по дисциплине Надежность систем В данной лекции систематически изложены следующие взаимосвязанные аспекты инженерии ПО

Что будем делать с полученным материалом:

Если этот материал оказался полезным для Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Еще рефераты, курсовые, дипломные работы на эту тему:

КУРС ЛЕКЦИЙ ПО ИНФОРМАТИКЕ Тема: Базы данных, Банки Данных, Системы Управления Базами Данных — СУБД
ГОУ ВПО ВОЛОГОДСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Факультет промышленного менеджмента...

Лекция № 1 КОНСПЕКТЫ ЛЕКЦИЙ ПО ДИСЦИПЛИНЕ СОЦИАЛЬНАЯ РЕАБИЛИТАЦИЯ И РЕАДАПТАЦИЯ
Лекция Предмет и задачи дисциплины Социальная реабилитация и реадаптация Предмет... Лекция... Виды реабилитации...

Конспект лекций по дисциплине Системы и сети связи с подвижными объектами Курск 2011 Тема1: Классификация телекоммуникационных систем
Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Юго Западный государственный университет... Факультет информатики и вычислительной техники...

Конспект лекций по дисциплине Экономика недвижимости: конспект лекций
Государственное бюджетное образовательное учреждение... высшего профессионального образования... Уральский государственный экономический университет...

Психиатрия. Конспект лекций. ЛЕКЦИЯ № 1. Общая психопатология Психиатрия: конспект лекций
Психиатрия конспект лекций... Текст предоставлен литагентом http litres ru...

Психодиагностика. Конспект лекций ЛЕКЦИЯ № 1. Истоки психодиагностики Психодиагностика: конспект лекций
Психодиагностика конспект лекций... А С Лучинин...

Лекция 1. Тема: Операционная система. Определение. Уровни операционной системы. Функции операционных систем. 1. Понятие операционной системы
Понятие операционной системы... Причиной появления операционных систем была необходимость создания удобных в... Операционная система ОС это программное обеспечение которое реализует связь между прикладными программами и...

Лекции 1.ОСНОВНЫЕ ПОНЯТИЯ И КАТЕГОРИЯ ИНФОРМАТИКИ. 2 ЛЕКЦИИ 2. МАТЕМАТИЧЕСКИЕ ОСНОВЫ ИНФОРМАТИКИ. СИСТЕМЫ СЧИСЛЕНИЯ. 12 ЛЕКЦИЯ 3. АППАРАТНОЕ ОБЕСПЕЧЕНИЕ ЭВМ. 20 ЛЕКЦИЯ 4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРОВ.. 49 Широко распространён также англоязычный вар
gl ОГЛАВЛЕНИЕ... Лекции ОСНОВНЫЕ ПОНЯТИЯ И КАТЕГОРИЯ ИНФОРМАТИКИ... ЛЕКЦИИ МАТЕМАТИЧЕСКИЕ ОСНОВЫ ИНФОРМАТИКИ СИСТЕМЫ СЧИСЛЕНИЯ...

История мировых религий: конспект лекций История мировых религий. Конспект лекций ЛЕКЦИЯ № 1. Религия как феномен культуры Классификация религий
История мировых религий конспект лекций... С Ф Панкин...

0.038
Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • По категориям
  • По работам