Разработка программного обеспечения средств измерений

Содержание

Слайд 2

План Введение Понятие разработки ПО Подходы к разработке ПО Планирование Определение

План

Введение
Понятие разработки ПО
Подходы к разработке ПО
Планирование
Определение конфигурации проекта
Разработка требований
Детальное планирование
Разработка архитектуры
Разработка

кода и юнит тестирование
Тестирование
Средства разработки ПО
Системы контроля версий
Системы отслеживания изменений
Системы построения сборок
IAR Workbench
Microsoft Visual Studio 2010
Clear Case, Clear Quest
Team Foundation Server 2010
Дополнительная информация
Слайд 3

Введение Специфика работы в отделе ПО Инженерного Центра Разработка ПО для

Введение

Специфика работы в отделе ПО Инженерного Центра
Разработка ПО для датчиков давления

и температуры
HART, FieldBus, CAN, Modbus протоколами
Графические и сегментные индикаторы
RTOS, C++
Разработка ПО для тестирования и настройки датчиков
С#, WPF, Framework 4.0, Silverlight, Entity Framework, SQL
Разработка ПО для производства датчиков давления
С#, SQL, ASP.NET
Слайд 4

Введение Метран-150

Введение

Метран-150

Слайд 5

Введение Electronic Remote Seal (ERS)

Введение

Electronic Remote Seal (ERS)

Слайд 6

Введение

Введение

Слайд 7

Введение (Глобальные продукты) Metran-150 http://www.youtube.com/watch?v=tGJRLaOqeJA Rosemount 3051S-ERS system http://www2.emersonprocess.com/en-us/brands/rosemount/pressure/dp-level-products/3051s-ers/Pages/index.aspx Rosemount 751

Введение (Глобальные продукты)

Metran-150
http://www.youtube.com/watch?v=tGJRLaOqeJA
Rosemount 3051S-ERS system
http://www2.emersonprocess.com/en-us/brands/rosemount/pressure/dp-level-products/3051s-ers/Pages/index.aspx
Rosemount 751
http://www2.emersonprocess.com/en-US/brands/rosemount/Accessories/751/Pages/index.aspx
Rosemount 752
http://www2.emersonprocess.com/en-US/brands/rosemount/Fieldbus/documents/productoverview_752indicator.html
Easy Upgrade Utility
http://www.documentation.emersonprocess.com/groups/public_assetoptprodlit/documents/video/475_allvoe_easyupgrade.swf

Слайд 8

Введение ПО для производства Датчиков Давления

Введение

ПО для производства Датчиков Давления

Слайд 9

Введение Эмулятор производственного оборудования

Введение

Эмулятор производственного оборудования

Слайд 10

Введение ПО для тестирования датчиков

Введение

ПО для тестирования датчиков

Слайд 11

Введение ПО для тестирования ПО ☺

Введение

ПО для тестирования ПО ☺

Слайд 12

Введение

Введение

Слайд 13

Понятие разработки ПО Что такое разработка ПО? Какие этапы и что входит в понятие разработка ПО?

Понятие разработки ПО

Что такое разработка ПО?
Какие этапы и что входит в

понятие разработка ПО?
Слайд 14

Понятие разработки ПО

Понятие разработки ПО

Слайд 15

Понятие разработки ПО

Понятие разработки ПО

Слайд 16

Подходы к разработке ПО

Подходы к разработке ПО

Слайд 17

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

Подходы к разработке ПО

Модель кодирования и устранения ошибок
Самая простая из моделей

очень часто применяемая студентами в учебном процессе. Алгоритм этой модели состоит из следующих шагов:
Шаг 1: постановка задачи
Шаг 2: создание программы
Шаг 3: тестирование
Шаг 4: анализ результата тестирования и возможный переход к шагу 1
Эта модель совсем не актуальна при профессиональной разработке программного обеспечения. По таким алгоритмам работали программисты 50-60 лет назад.
Слайд 18

Подходы к разработке ПО "Водопад" или каскадная модель жизненного цикла программного

Подходы к разработке ПО

"Водопад" или каскадная модель жизненного цикла программного обеспечения
Это

модель жизненного цикла программного обеспечения устарела
Слайд 19

Подходы к разработке ПО SCRUM: Гибкая разработка

Подходы к разработке ПО

SCRUM: Гибкая разработка

Слайд 20

Подходы к разработке ПО Rational Unified Process (RUP) — методология разработки

Подходы к разработке ПО

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная

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

Подходы к разработке ПО

Подходы к разработке ПО

Слайд 22

Подходы к разработке ПО Rosemount Development Process – итерационная разработка основанная на RUP

Подходы к разработке ПО

Rosemount Development Process – итерационная разработка основанная на

RUP
Слайд 23

Подходы к разработке ПО Основные этапы совпадают Основными состоянии проекта, показанными

Подходы к разработке ПО

Основные этапы совпадают Основными состоянии проекта, показанными на

рисуноке. Все основные этапы разработки сопровождаются дополнительными процедурами:
Экспертный обзор/Пиир Ревью – каждый документ, созданный или изменный в проекте, должен проходить через процедуру экспертного обзора
Проект должен иметь в составе Инженера по качеству, который периодически инспектирует проект на соответствие его процедуре DOP-415 и качество. 
Проект должен иметь как минимум два крупных обзора Предварительный Обзор Архитектуры (PDR), и Финальный обзор Архитектуры(FDR).
Проект должен иметь в составе Менеджера конфигурации проекта (Руководитель проекта может совмещать эту роль) для надлежащего управления конфигурацией проекта и содержания папок и структуры проекта в виде, соответствующему плану управления конфигурацией проекта, а также для инициирования изменений в документах и поддержания их в актуальном виде.
Слайд 24

Подходы к разработке ПО модели-разработки-по http://msdn.microsoft.com/ru-ru/library/ee909663.aspx http://www.shmakov.ru/news/text136.html http://ru.wikipedia.org/wiki/Rational_Unified_Process

Подходы к разработке ПО

модели-разработки-по
http://msdn.microsoft.com/ru-ru/library/ee909663.aspx
http://www.shmakov.ru/news/text136.html
http://ru.wikipedia.org/wiki/Rational_Unified_Process

Слайд 25

Планирование В 1958 году в США приступили к строительству Веррацано-Нарроуского моста.

Планирование

В 1958 году в США приступили к строительству Веррацано-Нарроуского моста. По

расчетам инженеров затраты на строительство определялись в размере 325 млн $,а работы планировалось завершить в 1965 году. Это самый большой подвесной мост в мире. Работы по нему завершились в ноябре 1964 года в соответствии с проектной сметой.
Приблизительно в это же самое время производилась разработка операционной системы OS фирмы IBM. По планам разработчиков длительность разработки составляла 5000 человеко-лет. Но несмотря на все возможные принятые фирмой меры, завершилась на 4 года позже планируемого срока.
http://habrahabr.ru/post/75903/
Слайд 26

Планирование Прежде нужно определится с методологий разработки ПО В компании Метран,

Планирование

Прежде нужно определится с методологий разработки ПО
В компании Метран, мы следуем

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

Планирование: Оценка людских затрат Существует множество методов оценки, в компании Метран

Планирование: Оценка людских затрат

Существует множество методов оценки, в компании Метран

используется метод экспертной оценки
Суть метода заключается в том, что несколько экспертов обсуждают поставленную задачу, вникают в суть, разбивают её на подзадачи и каждый дает затем свою оценку сколько времени потребуется на разработку.
За оценку берется средневзвешенное значение.
Делаются оптимистические (нет рисков) и пессимистические оценки (все риски сработали)
Слайд 28

Планирование: Оценка людских затрат

Планирование: Оценка людских затрат

Слайд 29

Планирование Оценка_затрат_на_разработку_программного_обеспечения http://agilerussia.ru/practices/planning-ms-project/

Планирование

Оценка_затрат_на_разработку_программного_обеспечения
http://agilerussia.ru/practices/planning-ms-project/

Слайд 30

Определение конфигурации проекта Что такое конфигурация проекта? Для чего нужна конфигурация проекта?

Определение конфигурации проекта

Что такое конфигурация проекта?
Для чего нужна конфигурация проекта?

Слайд 31

Определение конфигурации проекта Правила хранения и доступа к документам Правила изменения

Определение конфигурации проекта

Правила хранения и доступа к документам
Правила изменения документов, исходного

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

Определение конфигурации проекта На этом этапе необходимо: Определить компоненты ПО Определить

Определение конфигурации проекта

На этом этапе необходимо:
Определить компоненты ПО
Определить правила компиляции
Определить правила

для анализатора кода
Определить политику чекинов
Определить права пользователей ресурсов проекта
Определить структуру каталогов проекта
Определить правила и последовательность создания билдов и релизов
Определить правила создания бейслайнов
Определить правила сливания
Описать роли
Описать процедуру изменения документов
Слайд 33

Определение конфигурации проекта Конфигурационное управление

Определение конфигурации проекта

Конфигурационное управление

Слайд 34

Разработка требований Что такое требования? Для чего нужны требования?

Разработка требований

Что такое требования?
Для чего нужны требования?

Слайд 35

Разработка требований

Разработка требований

Слайд 36

Разработка требований Требования заказчика (CRD) Анализ требований от заказчика -> требования

Разработка требований

Требования заказчика (CRD)
Анализ требований от заказчика -> требования к системе

(SRD)
Анализ требований к системе -> требования к ПО (SRS)
Множество дополнительных документов, также являющихся требованиями к ПО
Например, файлы, описывающие типы данных и их значений
Файл с описанием протокола взаимодействия
Спецификации на микросхемы и их настройки
Разработка требований занимает от 1/5 до почти 1/2 времени всей разработки
Слайд 37

Разработка требований

Разработка требований

Слайд 38

Разработка требований Формат представления может быть разным Просто текстовый документ с

Разработка требований

Формат представления может быть разным
Просто текстовый документ с детальным описанием

что необходимо делать (Так сделано в Метране)
Рукописные документы, отсканированные
User Story (Описывают то, что хочет сделать пользователь, например, Ввести пароль и логин, Откалибровать верхний предел датчика)
Use Cases (Более детальное описание действий пользователя, системы и т.д. (Актеров))
Требования могу быть:
Функциональные (описывающие действия и функции и т.д.)
Не функциональные (ограничения, допущения, предположения, например – требования к ресурсам микроконтроллера, к использованию операционной системы, частоты кварца, быстродействия и так далее)
Требования должны быть написаны в такой форме, чтобы каждое требование могло быть проверено тестером (тестируемо)
Главное – записывайте требования!!!
Слайд 39

Разработка требований Требования_к_программному_обеспечению

Разработка требований

Требования_к_программному_обеспечению

Слайд 40

Детальное планирование Что такое детальное планирование Для чего нужно детальное планирование?

Детальное планирование

Что такое детальное планирование
Для чего нужно детальное планирование?

Слайд 41

Детальное планирование Делается после этапа разработки требований В основном используется в

Детальное планирование

Делается после этапа разработки требований
В основном используется в итерационном подходе
Все

требования разбиваются на фичи ☺.
Например, (индикатор, меню, HART, расчет давления и так далее)
Фичи ранжируются, и выбираются, какие будут делаться раньше, какие позже
Составляется план итераций, какие фичи на каких итерациях будут реализовываться
Слайд 42

Детальное планирование Все фичи развиваются на мелкие задачи Задачи могут занимать

Детальное планирование

Все фичи развиваются на мелкие задачи
Задачи могут занимать от 4

часов до 4 дней
За каждой задачей закрепляется ответственный
Слайд 43

Детальное планирование Отслеживание выполнения задач и прогресса разработки

Детальное планирование

Отслеживание выполнения задач и прогресса разработки

Слайд 44

Разработка архитектуры Что такое архитектура ПО? Для чего нужна архитектура? Как отображать архитектуру?

Разработка архитектуры

Что такое архитектура ПО?
Для чего нужна архитектура?
Как отображать архитектуру?

Слайд 45

Разработка архитектуры Общая архитектура Обобщенная структура приложения Большие пакеты, основные идеи,

Разработка архитектуры

Общая архитектура
Обобщенная структура приложения
Большие пакеты, основные идеи, уровни
Детальная архитектура
Детальное описание

классов
Описание взаимодействий между объектами
Детальное описание работы
Язык UML
Слайд 46

Разработка архитектуры На этапе общей архитектуры должны быть определены: Окружение ПО

Разработка архитектуры

На этапе общей архитектуры должны быть определены:
Окружение ПО
Все прецеденты пользователя
Все

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

Разработка архитектуры

Разработка архитектуры

Слайд 48

Разработка архитектуры На каждой итерации для каждой фичи необходимо уточнять архитектуру.

Разработка архитектуры

На каждой итерации для каждой фичи необходимо уточнять архитектуру. Это

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

Разработка архитектуры

Разработка архитектуры

Слайд 50

Разработка архитектуры

Разработка архитектуры

Слайд 51

Разработка архитектуры Язык UML, позволяет вам описывать архитектуру так, что она

Разработка архитектуры

Язык UML, позволяет вам описывать архитектуру так, что она не

будет зависеть от языка на котором вы её будете реализовывать
Вы можете прямо из архитектуры сгенерить заготовку класса, или даже код методов
Так же архитектуру можно проверить на соотвествие стандарту дизайна, например, что классы нижних уровней не вызывают методы классов верхних уровней, или что классы уровня, используют только классы следующего нижестоящего уровня и не “прыгают” через уровень
Слайд 52

Разработка архитектуры Шаблоны проектирования – используются для решения того, чтобы “не

Разработка архитектуры

Шаблоны проектирования – используются для решения того, чтобы “не изобретать

велосипед” ☺ и использовать стандартные решения в частых задач при проектировании. Об этом более детально в разделе кодирование.
Слайд 53

Разработка архитектуры http://ru.wikipedia.org/wiki/UML http://www.omg.org/spec/UML/2.4.1/

Разработка архитектуры

http://ru.wikipedia.org/wiki/UML
http://www.omg.org/spec/UML/2.4.1/

Слайд 54

Примеры требований ПО Должно работать на ПК имеющего 4 Гб оперативной

Примеры требований

ПО Должно работать на ПК имеющего 4 Гб оперативной памяти

и 500 Мб свободного дискового пространства
ПО должно иметь возможность ввода логина и пароля
ПО должно иметь удобный пользовательский интерфейс
ПО должно быть написано на языке программирования С++
ПО должно использовать Framework 4.6
ПО должно позволять пользователю настраивать датчик с HART протоколом
ПО должно иметь возможность расширения
ПО должно иметь возможность подключения внешних модулей (Plug-In) по интерфейсу, описанного в “SDK”
ПО должно иметь меню
ПО должно иметь структуру меню, описанную в документе UI
Слайд 55

Пример кода 1 1. Переменные не приведены к типа в таблице

Пример кода 1

1. Переменные не приведены к типа в таблице 1

- не соответствие стандарту кодирования
2. Значение I не определено, и вообще не понятно, что она возвратит – нарушение стандарта языка
3. Переменная I имеет тип char, А переменная inValue – int, при присвоении мы потеряем старшие байты
4. Плохое название для переменной i
Слайд 56

Пример кода 2 1. Переменные не приведены к типа в таблице

Пример кода 2

1. Переменные не приведены к типа в таблице 1

- не соответствие стандарту кодирования
2. Значение I не определено, и вообще не понятно, что она возвратит – нарушение стандарта языка
3. Переменная I имеет тип char, не проверяется значение inValue, в случае если оно будет 255, может быть переполнение при увеличении на 1.
4. Плохое название для переменной i
Слайд 57

Пример кода 3 1. Return в двух местах - нарушение стандарта

Пример кода 3

1. Return в двух местах - нарушение стандарта кодирования,

да и вообще плохой стиль
2. Ошибка в if вместо “=” должно быть ==
3. Magic Number
4. Комментарий не верный, в Returns должно быть добавлено, что если входное значение равно 255, то возвратится 255.
5. Плохое название для переменной i
6. Сделано не рационально, можно было сделать проверку на неравно
Слайд 58

Пример код 4 1. Return в двух местах - нарушение стандарта

Пример код 4

1. Return в двух местах - нарушение стандарта кодирования,

да и вообще плохой стиль
2. Magic Number
3. Комментарий не верный, в Returns должно быть добавлено, что если входное значение равно 255, то возвратится 255.
4. Плохое название для переменной i
5. Сделано не рационально, можно было сделать проверку на не равно.
Слайд 59

Пример кода 5 1. Magic Number 2. Комментарий не верный, в

Пример кода 5

1. Magic Number
2. Комментарий не верный, в Returns должно

быть добавлено, что если входное значение равно 255, то возвратится 255.
3. Плохое название для переменной i
Слайд 60

Пример кода 6 1. Magic Number 2. Комментарий не верный, в

Пример кода 6

1. Magic Number
2. Комментарий не верный, в Returns должно

быть добавлено, что если входное значение равно 255, то возвратится 255.
3. Плохое название для переменной i
Слайд 61

Пример кода 7 1. Magic Number 2. Два ретурна, должен быть

Пример кода 7

1. Magic Number
2. Два ретурна, должен быть только 1.
3.

Не проверяется я указатель
4. Не понятен размер массива, поэтому 5 – может быть уже выход на пределы массива
Слайд 62

Пример кода 8 1. Ошибка в ифе 2. Char вместо tU8 3. ArraySize с большой буквы

Пример кода 8

1. Ошибка в ифе
2. Char вместо tU8
3. ArraySize с

большой буквы
Слайд 63

Разработка кода/юнит тестирование Что такое юнит тесты и для чего они нужны?

Разработка кода/юнит тестирование

Что такое юнит тесты и для чего они нужны?

Слайд 64

Разработка кода/юнит тестирование Кодирование – написание кода, по существующей архитектуре, спецификации

Разработка кода/юнит тестирование

Кодирование – написание кода, по существующей архитектуре, спецификации методов,

интерфейсов и так далее
Метран использует только объектно-ориентированные языки,
С++ для встроенного ПО
С# для ПО высокого уровня
Для того, чтобы все члены команды понимали друг друга, используется стандарт кодирования:
Общий стиль написания кода (отступы, скобки, фигурные скобки, названия переменных и так далее)
Правила и договоренности по приемам программирования (всегда инициализировать переменную, всегда проверять указатели, всегда делать проверку значения с переменной, а не наоборот “if (VALUE == myVar)“ и так далее)
Слайд 65

Разработка кода/юнит тестирование Использование шаблонов проектирования (хотя это больше относится к

Разработка кода/юнит тестирование

Использование шаблонов проектирования (хотя это больше относится к разработке

архитектуры)
Стандартные подходы к решению частых задач проблем при разработке ПО
Пример, обработка событий от кнопки, происходит по шаблону Observer
Для создания объектов используется шаблон Factory
Для того, чтобы сделать приложение, которое может работать только в единственном экземпляре достаточно использовать шаблон Singleton
Слайд 66

Разработка кода/юнит тестирование Статическая проверка кода Lint Для проверки соответствия С++

Разработка кода/юнит тестирование

Статическая проверка кода
Lint
Для проверки соответствия С++ стандартам и

общепринятым правилам кодирования
Code Analysis
Для проверки соответствия С++ стандартам и общепринятым правилам кодирования
Слайд 67

Разработка кода/юнит тестирование Что такое юнит тестирование (модульное тестирование)? Для чего нужно юнит тестирование?

Разработка кода/юнит тестирование

Что такое юнит тестирование (модульное тестирование)?
Для чего нужно юнит

тестирование?
Слайд 68

Разработка кода/юнит тестирование Юнит тестирование Тестирование и проверка, что методы и

Разработка кода/юнит тестирование

Юнит тестирование
Тестирование и проверка, что методы и функции соответствуют

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

Разработка кода/юнит тестирование Очень часто необходимо сделать юнит тест метода, который

Разработка кода/юнит тестирование

Очень часто необходимо сделать юнит тест метода, который обращается

к какому-то железу, но понятно, что оно не доступно во время компиляции.
В этом случае создают Mock объекты – это практически копии классов, работающих с реальным железом, но они просто подменяют запросы к железу своими данными.
Например проверка, метод RecieveDataFromComPort() работает корректно. Для этого делается Mock объект, который подменяет класс COM порта, и возвращает что-то методу RecieveDataFromComPort()
Слайд 70

Разработка кода/юнит тестирование Ни успешное прохождение проверки архитектуры, ни статическая проверка

Разработка кода/юнит тестирование

Ни успешное прохождение проверки архитектуры, ни статическая проверка кода,

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

Разработка кода/юнит тестирование http://habrahabr.ru/post/136766/ http://ru.wikipedia.org/wiki/Шаблон_проектирования http://citforum.ru/SE/project/pattern/ http://design-pattern.ru/ http://ru.wikipedia.org/wiki/Модульное_тестирование http://habrahabr.ru/post/134836/

Разработка кода/юнит тестирование

http://habrahabr.ru/post/136766/
http://ru.wikipedia.org/wiki/Шаблон_проектирования
http://citforum.ru/SE/project/pattern/
http://design-pattern.ru/
http://ru.wikipedia.org/wiki/Модульное_тестирование
http://habrahabr.ru/post/134836/

Слайд 72

Тестирование ПО В 1945 г. был обнаружен самый первый в истории

Тестирование ПО

В 1945 г. был обнаружен самый первый в истории компьютерный баг,

когда в корпусе компьютера инженеры нашли мотылька. Мотылек этот вызывал закорачивание контактов, вследствие чего компьютер давал сбои. В журнале событий инженерами была сделана запись «обнаружен баг», т.е. насекомое. С этого момента и принято называть компьютерные сбои багами.
Сбой в работе комплекса Patriot
Patriot – состоящая на вооружении армии США мобильная система противоракетной обороны, оснащаемая ракетами класса «земля-воздух» и предназначенная для защиты от самолетов, крылатых ракет и баллистических ракет ближнего радиуса действия. 25 февраля 1991 года сбой в системе Patriot помешал отследить и перехватить иракскую ракету Scud, выпущенную по военной базе Дахран в Саудовской Аравии. Ракета достигла цели, в результате чего погибли 28 американских солдат и еще около 100 человек получили ранения (см. www.fas.org/spp/starwars/gao/im92026.htm). 
Причиной сбоя стала ошибка округления, приводящая к неточности в работе часов, которая усугубилась увеличенным временем работы между перезагрузками системы. При разработке первоначальной архитектуры предполагалось, что система Patriot будет действовать в мобильных условиях и, как следствие, часто перемещаться. В силу чего предполагалось, что ее операционный цикл составит 14 часов. Система в Дахране работала значительно дольше – примерно 100 часов, в результате чего расфазировка синхронизирующих импульсов составила 0,34 с. Несмотря на то что в процентном отношении такая ошибка может показаться небольшой, именно она привела к некорректному расчету местонахождения приближающейся ракеты. Система Patriot определяет, является ли приближающийся объект целью для перехвата, вычисляя «зону попадания» на основе данных первого радарного контакта этого объекта, известной скорости цели и таймера. Радарный контакт в прогнозируемой «зоне попадания» подтверждает факт обнаружения цели, но рассинхронизация часов привела к тому, что система неправильно вычислила границы зоны поражения цели, поэтому не зарегистрировала второй радарный контакт с целью.
Osprey авиакатастрофа
В 2000 году, Корпус морской пехоты США Osprey, - гибрид самолета и вертолета при выходе из строя гидравлической системы, одной из стандартных действий было переход самолета в вертолетный режим для посадки. Из-за неправильной  работы программного обеспечение, управляющий полетом компьютер остановил вращение двигателя при обнаружении отказа гидравлической системы.
Слайд 73

Тестирование ПО Передозировки при лучевой терапии Печально известная ошибка в линейном

Тестирование ПО

Передозировки при лучевой терапии
Печально известная ошибка в линейном ускорителе Therac-25

стала причиной гибели нескольких больных, получивших смертельные дозы радиации во время лечения, проводимого с июня 1985-го по январь 1987 года в нескольких онкологических клиниках в США и Канаде. Эти дозы, как было оценено позже, более чем в 100 раз превышали те, что обычно применяются при лечении. В Therac-25 использовалось меньше аппаратных компонентов, чем в предыдущих модификациях, и применялось новое программное обеспечение для микросхемы предохранительной блокировки, которая гарантирует правильное позиционирование защитных поверхностей и препятствует превышению заданного максимума мощности электронного луча вне зависимости от данных, вводимых оператором. Программная ошибка проявлялась, когда оператор слишком быстро вводил определенную последовательность команд на управляющем терминале. Информация, отображающаяся на экране оператора, не соответствовала реальной работе устройства и не позволяла оператору понять, что возникла ошибка. Та же самая ошибка была и в программном обеспечении предыдущей модели Therac-20, но там была более «глупая», непрограммируемая аппаратная предохранительная блокировка, оказавшаяся в результате более надежной [2].
Один из последних случаев смертельной передозировки при лучевой терапии произошел в Национальном онкологическом институте в Панама-Сити в 2001 году. Разработанное компанией Multidata Systems International программное обеспечение планирования лечения в определенной ситуации некорректно вычисляло дозы радиации. Двадцать восемь пациентов подверглись чрезмерному облучению, что стало причиной смерти нескольких больных. Эта программная ошибка проявлялась, когда операторы пытались преодолеть системные ограничения на количество и конфигурацию защитных поверхностей, используемых для изоляции зоны облучения. Они обнаружили, что, если изображать область с отверстием внутри, то таким образом можно заставить систему направлять нужную дозу радиации в правильное место. Однако им было неизвестно, что при изображении такой поверхности в одном направлении вычисления будут корректными, но, если рисовать поверхность по-другому, то возникнет передозировка. Мы не можем винить в этих инцидентах одно только программное обеспечение – предполагалось, что операторы выполняют вычисления вручную для того, чтобы гарантировать, что доза, определенная программой, является приемлемой. Они игнорировали эту важную проверку из-за отсутствия в этом медицинском институте строгих административных процедур (www.fda.gov/cdrh/ocd/panamaradexp.html или www.fda.gov/bbs/topics/NEWS/2003/NEW00903.html).
Слайд 74

Тестирование ПО 28 июля 1962 г. Американский космический зонд Mariner I

Тестирование ПО

28 июля 1962 г. Американский космический зонд Mariner I
Ошибка в

ПО для запуска ракеты, которая выводила зонд на орбиту, привела к отклонению аппарата от намеченной траектории. Пришлось разрушить ракету над Атлантическим океаном. Расследование инцидента показало, что при составлении программы формула, написанная карандашом на бумаге, была неправильно переведена в компьютерный код. Неверно написанная программа рассчитала ошибочную траекторию ракеты.
1982 год. Газопровод в СССР
Баг в канадской компьютерной системе, купленной СССР для управления Транссибирским газопроводом, привел к одному из самых крупных неядерных взрывов.
15 января 1990 г. Выход из строя сети компании AT&T
Баг в новой программе управления коммутатором междугородних звонков #4ESS компании AT&T привел к тому, что эти сложнейшие устройства выходили из строя, когда от своего партнера по сети получали сигнал о том, что у него произошел сбой и теперь он восстанавливается.
Однажды коммутатор AT&T в Нью-Йорке вышел из строя по какой-то причине и перегружался, чтобы возобновить нормальную работу. При этом все коммутаторы сети, соединенные с ним, получили сигнал, который привел к перебоям в их работе. Вскоре все 114 междугородных коммутаторов сети стали перегружаться каждые шесть секунд, а 60 тыс. абонентов не имели возможности позвонить в другой город в течение девяти часов. Пришлось техникам в срочном порядке загружать хоть и старую, но проверенную версию программы.
4 июня 1996 г. Полет ракеты "Ариан-5"
В компьютерах ракеты "Ариан-5" использовались те же программы, что и у ракеты "Ариан-4". Можно сказать, что более мощные двигатели "Ариан-5" привели к возникновению бага. Ошибка крылась в подпрограмме, которая превращала 64-битные числа с плавающей запятой в 16-битные целые числа. В "Ариан-5" эти 64-битные числа были гораздо больше, чем в "Ариан 4" (из-за большей мощности двигателей), что приводило к переполнению регистров и, в конце концов, к сбою компьютера.
В полете "Ариан-5" компьютер, управляющий двигателями, вышел из строя, а через 0,05 секунды стал неправильно работать и центральный компьютер, ракета начала разгоняться и была взорвана через 40 секунд после старта.
Сбои в системах банках
http://www.youtube.com/watch?v=JjfR05wsuJo
Слайд 75

Тестирование ПО

Тестирование ПО

Слайд 76

Тестирование ПО Юнит тесты Функциональное тестирование Нефункциональное тестирование Регрессионное тестирование Стресс

Тестирование ПО

Юнит тесты
Функциональное тестирование
Нефункциональное тестирование
Регрессионное тестирование
Стресс тесты, нагрузочные тесты, тесты стабильности
Смок

тесты
Слайд 77

Тестирование ПО Plan / Replan Создать план тестирования и провести экспертный

Тестирование ПО

Plan / Replan
Создать план тестирования и провести экспертный обзор
Test Analysis
Определить

что необходимо тестировать и связь тестов с требованиями
Провести экспертный обзор
Test Design
Создать детальные спецификации тестов и шагов тестирования
Выполнить экспертный обзор спецификации тестов
Test Implementation (Automatic tests)
Создать (закодировать) тесты на основе, тест спецификаций
Test Execution (Regression)
Запустить тесты и проанализировать результаты тестирования
Занести найденные несоответствия
Evaluate Test Coverage
Проверить, что все требования покрываются тестами
Слайд 78

Тестирование ПО Тестирование любого ПО в Метране производится в основном автоматически

Тестирование ПО

Тестирование любого ПО в Метране производится в основном автоматически
Язык написания

тестовых скриптов – С#, свой собственный скриптовый язык
Оборудование работает по протоколам GPIB, RS232, RS485, USB (в освном виртуальные RS232 и GPIB)
Каждый раз запускаются все тесты. Количество тестов зависит от проекта, от 500 до 1500, и тесты могут идти до 50 часов.
Слайд 79

Тестирование ПО Компоненты датчика Плата ЦАП Модуль сенсора Индикатор с кнопками

Тестирование ПО

Компоненты датчика
Плата ЦАП
Модуль сенсора
Индикатор с кнопками
Оборудования
Управляемый источник питания
Вольтметр
Мультиплексор сигналов
Переключение компонентов

датчика
Эмуляция нажатия кнопок
Создание ошибок платы ЦАП
Анализатор I2C шины Beagle I2C
Перехват сообщений индикатору и их анализ
Источник давления
Слайд 80

Тестирование ПО http://www.olimpic.tusur.ru/books/GOS/Metodichki/TRPO.pdf http://www.osp.ru/os/2009/03/8158133/ http://habrahabr.ru/post/75903/ http://habrahabr.ru/post/149903/ http://www.protesting.ru/testing/testtypes.html

Тестирование ПО

http://www.olimpic.tusur.ru/books/GOS/Metodichki/TRPO.pdf
http://www.osp.ru/os/2009/03/8158133/
http://habrahabr.ru/post/75903/
http://habrahabr.ru/post/149903/
http://www.protesting.ru/testing/testtypes.html

Слайд 81

Средства разработки: Системы контроля версий Что такое системы контроля версий? Для чего нужны?

Средства разработки: Системы контроля версий

Что такое системы контроля версий?
Для чего нужны?

Слайд 82

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

Средства разработки: Системы контроля версий

Используется для ведения и отслеживания версий документов,

файлов, папок.
Не заменима при командной разработке.
Основный операции
Add to source control - Добавление под систему контроля версий
Check Out - взять файл на изменение
Check in - вернуть измененный файл в систему контроля версий
Merge – объединить изменения
Branch – создать ветвь разработчика
Слайд 83

Средства разработки: Системы контроля версий Clear Case – система контроля версий от IBM Ration Rose

Средства разработки: Системы контроля версий

Clear Case – система контроля версий от

IBM Ration Rose
Слайд 84

Средства разработки: Системы контроля версий

Средства разработки: Системы контроля версий

Слайд 85

Средства разработки: Системы контроля версий

Средства разработки: Системы контроля версий

Слайд 86

Средства разработки: TFS Team Foundation Server - Интегрированная система разработки, включающая

Средства разработки: TFS

Team Foundation Server - Интегрированная система разработки, включающая

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

Средства разработки: TFS Система контроля версий

Средства разработки: TFS

Система контроля версий

Слайд 88

Средства разработки: Системы контроля версий Wikipedia: Система Контроля Версий

Средства разработки: Системы контроля версий

Wikipedia: Система Контроля Версий

Слайд 89

Team Foundation Server Team Foundation Server

Team Foundation Server

Team Foundation Server

Слайд 90

Team Foundation Server Возможности отчетов TFS на Share Point Статус итерации

Team Foundation Server

Возможности отчетов TFS на Share Point

Статус итерации
Статус требований
Статус задач
Статус запросов

на изменение
Оставшаяся трудоемкость
Количество задач

Пример диаграммы отслеживания статуса итерации

Слайд 91

Team Foundation Server Возможности отчетов TFS в Excel Метрика кода Метрика

Team Foundation Server

Возможности отчетов TFS в Excel

Метрика кода
Метрика качества билдов
Метрика задач
Метрика по

тестам
Слайд 92

Team Foundation Server As Basis For Effective Project Management -- RTC/METRAN

Team Foundation Server As Basis For Effective Project Management -- RTC/METRAN

Using

TFS allows Project Manager to get:
All necessary information in any time and quickly take corrective actions if necessary.
Automatic reports without mistakes using Reports/Analysis Services.
Minimum indirect efforts for reports creation.
Estimate efforts for coding
Real efforts and compare them with estimations.
Information about non-covered code by any person (for example QA) and take corrective activity