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

1. Разработка программного обеспечения средств измерений Сергей Колодий руководитель отдела Разработки Программного Обеспечения

Инженерного Центра
ЗАО ПГ Метран

2. План

Введение
Понятие разработки ПО
Подходы к разработке ПО
– Планирование
– Определение конфигурации проекта
– Разработка требований
– Детальное планирование
– Разработка архитектуры
– Разработка кода и юнит тестирование
– Тестирование
Средства разработки ПО
– Системы контроля версий
– Системы отслеживания изменений
– Системы построения сборок
– IAR Workbench
– Microsoft Visual Studio 2010
– Clear Case, Clear Quest
– Team Foundation Server 2010
Дополнительная информация
Emerson Confidential
Slide No. 2

3. Введение

Специфика работы в отделе ПО Инженерного Центра
Sergey Kolody
SW Manager
PC based SW group
Test group
Valery Yakovenko supervisor
8 Sw engineers
7 sw engineers
Embedded SW group
Mikhail Chashchin supervisor
8 sw engineers
Разработка ПО для датчиков давления и температуры
– HART, FieldBus, CAN, Modbus протоколами
– Графические и сегментные индикаторы
– RTOS, C++
Разработка ПО для тестирования и настройки датчиков
– С#, WPF, Framework 4.0, Silverlight, Entity Framework, SQL
Разработка ПО для производства датчиков давления
– С#, SQL, ASP.NET
Emerson Confidential
Slide No. 3

4. Введение

Метран-150
Emerson Confidential
Slide No. 4

5. Введение

Electronic Remote Seal (ERS)
Emerson Confidential
Slide No. 5

6. Введение

Emerson Confidential
Slide No. 6

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

Metran-150
– http://www.youtube.com/watch?v=tGJRLaOqeJA
Rosemount 3051S-ERS system
– http://www2.emersonprocess.com/en-us/brands/rosemount/pressur
e/dp-level-products/3051s-ers/Pages/index.aspx
Rosemount 751
– http://www2.emersonprocess.com/en-US/brands/rosemount/Access
ories/751/Pages/index.aspx
Rosemount 752
– http://www2.emersonprocess.com/en-US/brands/rosemount/Fieldbu
s/documents/productoverview_752indicator.html
Easy Upgrade Utility
– http://www.documentation.emersonprocess.com/groups/public_ass
Emerson Confidential
Slide No.etoptprodlit/documents/video/475_allvoe_easyupgrade.swf
7

8. Введение

ПО для производства Датчиков Давления
Emerson Confidential
Slide No. 8

9. Введение

Эмулятор производственного оборудования
Emerson Confidential
Slide No. 9

10. Введение

ПО для тестирования датчиков
Emerson Confidential
Slide No. 10

11. Введение

ПО для тестирования ПО
Emerson Confidential
Slide No. 11

12. Введение

Emerson Confidential
Slide No. 12

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

Что такое разработка ПО?
Какие этапы и что входит в понятие
разработка ПО?
Emerson Confidential
Slide No. 13

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

Относительная длительность этапа работ
1. Анализ требований к
программам и
планирование
20,00%
22,00%
2. Архитектурное
проектирование
программного средства
3. Детальное
проектирование
программного средства
18,00%
22,00%
18,00%
4. Кодирование и
тестирование
программных
компонентов
5. Интеграция,
квалификационное
тестирование и испытания
программного средства
Emerson Confidential
Slide No. 14

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

Относительная длительность этапа работ
Относительное число специалистов на этапе
1. Анализ требований
к программам и
планирование
1. Анализ требований к
программам и
планирование
20,00%
18,00%
18,00%
22,00%
2. Архитектурное
проектирование
программного средства
3. Детальное
проектирование
программного средства
22,00%
4. Кодирование и
тестирование
программных
компонентов
5. Интеграция,
квалификационное
тестирование и
испытания
программного средства
Emerson Confidential
Slide No. 15
2. Архитектурное
проектирование
программного
средства
23,73%
8,47%
13,56%
20,34%
33,90%
3. Детальное
проектирование
программного
средства
4. Кодирование и
тестирование
программных
компонентов
5. Интеграция,
квалификационное
тестирование и
испытания
программного
средства

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

Emerson Confidential
Slide No. 16

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

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

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

"Водопад" или каскадная модель жизненного
цикла программного обеспечения
– Это модель жизненного цикла программного
обеспечения устарела
Emerson Confidential
Slide No. 18

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

SCRUM: Гибкая разработка
Emerson Confidential
Slide No. 19

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

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

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

Emerson Confidential
Slide No. 21

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

Rosemount Development Process – итерационная
разработка основанная на RUP
Emerson Confidential
Slide No. 22

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

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

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
Emerson Confidential
Slide No. 24

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

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

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

Прежде нужно определится с
методологий разработки ПО
В компании Метран, мы следуем
итерационному процессу, поэтому
для планирования необходимо:
– В план включаются все этапы
разработки, соответствующие нашей
методологии DOP415
– Оценивается людские затраты
каждый этап
– Кодирование и детальное
проектирование разбивается на
итерации
Emerson Confidential
Slide No. 26

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

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

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

Выполнение работ до Gate4
Область
Трудозатраты чел./нед.
Выполняемые работы оптимистичная наиболее
пессимистическая Комментарии
оценка
правдоподобная оценка
оцека
Project Management
Final Design Review
Final Peer Safety Review
2
2
3
Engineering & Design
Software Unit Test
Plan / Results
1
1
2
48
4
96
6
150
8
Software Source Code
Release Documentation
for Software
Troubleshooting Guide
PCS Product
Requirements
SW DVT Testing
Final Specification
Control Drawing (SCD)
Emerson Confidential
Slide No. 28
These requirements define
what options the customer can
order and what parts need to
be driven in production.
48
96
150

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

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

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

Что такое конфигурация проекта?
Для чего нужна конфигурация проекта?
Emerson Confidential
Slide No. 30

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

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

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

На этом этапе необходимо:
– Определить компоненты ПО
– Определить правила компиляции
– Определить правила для анализатора кода
– Определить политику чекинов
– Определить права пользователей ресурсов проекта
– Определить структуру каталогов проекта
– Определить правила и последовательность создания билдов и
релизов
– Определить правила создания бейслайнов
– Определить правила сливания
– Описать роли
– Описать процедуру изменения документов
Emerson Confidential
Slide No. 32

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

Конфигурационное управление
Emerson Confidential
Slide No. 33

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

Что такое требования?
Для чего нужны требования?
Emerson Confidential
Slide No. 34

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

Emerson Confidential
Slide No. 35

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

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

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

Emerson Confidential
Slide No. 37

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

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

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

Требования_к_программному_обеспечению
Emerson Confidential
Slide No. 39

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

Что такое детальное планирование
Для чего нужно детальное планирование?
Emerson Confidential
Slide No. 40

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

Делается после этапа разработки требований
В основном используется в итерационном
подходе
Все требования разбиваются на фичи .
– Например, (индикатор, меню, HART, расчет
давления и так далее)
Фичи ранжируются, и выбираются, какие будут
делаться раньше, какие позже
Составляется план итераций, какие фичи на
каких итерациях будут реализовываться
Emerson Confidential
Slide No. 41

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

Все фичи развиваются на мелкие задачи
– Задачи могут занимать от 4 часов до 4 дней
– За каждой задачей закрепляется ответственный
Emerson Confidential
Slide No. 42

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

Отслеживание выполнения задач и прогресса
разработки
Emerson Confidential
Slide No. 43

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

Что такое архитектура ПО?
Для чего нужна архитектура?
Как отображать архитектуру?
Emerson Confidential
Slide No. 44

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

Общая архитектура
– Обобщенная структура приложения
– Большие пакеты, основные идеи, уровни
Детальная архитектура
– Детальное описание классов
– Описание взаимодействий между объектами
– Детальное описание работы
Язык UML
Emerson Confidential
Slide No. 45

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

На этапе общей архитектуры должны быть определены:
– Окружение ПО
– Все прецеденты пользователя
– Все основные потоки приложения
– Установлены приоритеты потоков приложения
– Основные пакеты и библиотеки приложения
– Основные интерфейсы приложения как внутренние, так и
внешние
– Основные классы приложения и их взаимодействие
– Если есть базы данных Структура базы данных (Таблицы и
связи между ними)
– Отработаны механизмы и методы, которые используются
впервые и используются в архитектуре, как ключевые.
Emerson Confidential
Slide No. 46

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

Emerson Confidential
Slide No. 47

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

На каждой итерации для каждой фичи необходимо уточнять
архитектуру. Это делается для того, чтобы более детально описать
как вы собираетесь реализовывать ту или иную функциональную
особенность ПО. Детальная архитектура включает в себя:
– Детальное описание класса, с пояснением какую роль этот класс играет и
зачем он нужен
– Детальное описание атрибутов классов
– Детальное описание и спецификация методов классов
– Детальное описание взаимодействия классов между собой
– Диаграмма последовательности
– Диаграммы состояний
– Другие диаграммы по необходимости.
– Если есть базы данных, то детальное описание полей таблиц базы данных,
связи таблиц
– Дополнительные документы в текстовом или ином виде, для того, чтобы
было понятно назначение и структура классов и компонентов
Emerson Confidential
Slide No. 48

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

Emerson Confidential
Slide No. 49

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

Emerson Confidential
Slide No. 50

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

Язык UML, позволяет вам
описывать архитектуру так,
что она не будет зависеть от
языка на котором вы её будете
реализовывать
Вы можете прямо из
архитектуры сгенерить
заготовку класса, или даже
код методов
Так же архитектуру можно
проверить на соотвествие
стандарту дизайна, например,
что классы нижних уровней не
вызывают методы классов
верхних уровней, или что
классы уровня, используют
только классы следующего
нижестоящего уровня и не
“прыгают” через уровень
Emerson Confidential
Slide No. 51

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

Шаблоны проектирования – используются для
решения того, чтобы “не изобретать
велосипед” и использовать стандартные
решения в частых задач при проектировании.
Об этом более детально в разделе
кодирование.
Emerson Confidential
Slide No. 52

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

http://ru.wikipedia.org/wiki/UML
http://www.omg.org/spec/UML/2.4.1/
Emerson Confidential
Slide No. 53

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

ПО Должно работать на ПК имеющего 4 Гб оперативной
памяти и 500 Мб свободного дискового пространства
ПО должно иметь возможность ввода логина и пароля
ПО должно иметь удобный пользовательский интерфейс
ПО должно быть написано на языке программирования С++
ПО должно использовать Framework 4.6
ПО должно позволять пользователю настраивать датчик с
HART протоколом
ПО должно иметь возможность расширения
ПО должно иметь возможность подключения внешних
модулей (Plug-In) по интерфейсу, описанного в “SDK”
ПО должно иметь меню
ПО должно иметь структуру меню, описанную в документе UI
Emerson Confidential
Slide No. 54

55. Пример кода 1

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

56. Пример кода 2

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

57. Пример кода 3

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

58. Пример код 4

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

59. Пример кода 5

1. Magic Number
2. Комментарий не верный, в Returns должно быть
добавлено, что если входное значение равно 255, то
возвратится 255.
3. Плохое название для переменной i
Emerson Confidential
Slide No. 59

60. Пример кода 6

1. Magic Number
2. Комментарий не верный, в Returns должно быть
добавлено, что если входное значение равно 255, то
возвратится 255.
3. Плохое название для переменной i
Emerson Confidential
Slide No. 60

61. Пример кода 7

1. Magic Number
2. Два ретурна, должен быть только 1.
3. Не проверяется я указатель
4. Не понятен размер массива, поэтому 5 – может быть уже
выход на пределы массива
Emerson Confidential
Slide No. 61

62. Пример кода 8

1. Ошибка в ифе
2. Char вместо tU8
3. ArraySize с большой буквы
Emerson Confidential
Slide No. 62

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

Что такое юнит тесты и для чего они нужны?
Emerson Confidential
Slide No. 63

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

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

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

Использование шаблонов проектирования
(хотя это больше относится к разработке
архитектуры)
– Стандартные подходы к решению частых задач
проблем при разработке ПО
– Пример, обработка событий от кнопки, происходит
по шаблону Observer
– Для создания объектов используется шаблон
Factory
– Для того, чтобы сделать приложение, которое
может работать только в единственном экземпляре
достаточно использовать шаблон Singleton
Emerson Confidential
Slide No. 65

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

Статическая проверка кода
Lint
– Для проверки соответствия С++ стандартам и
общепринятым правилам кодирования
Code Analysis
– Для проверки соответствия С++ стандартам и
общепринятым правилам кодирования
Emerson Confidential
Slide No. 66

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

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

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

Юнит тестирование
– Тестирование и
проверка, что методы и
функции соответствуют
спецификации
– Поиск потенциальных
ошибок в коде
– Защита кода от
изменения другими
разработчиками
Emerson Confidential
Slide No. 68

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

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

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

Ни успешное прохождение проверки архитектуры, ни
статическая проверка кода, ни юните тесты не
гарантируют отсутствие потенциальных ошибок в коде
Поэтому для выявления таких ошибок используются
гениальная процедура экспертного обзора (не только
кода, но архитектуры, требований и др. документов)
– Поиск потенциальных ошибок более опытными инженерами
– Обучение инженеры учатся друг у друга писать код и
проектировать
– Взаимодействие в команде
– Следование одному стилю
Emerson Confidential
Slide No. 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/
Emerson Confidential
Slide No. 71

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

В 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, - гибрид самолета и вертолета при выходе из строя
гидравлической системы, одной из стандартных действий было переход самолета в вертолетный режим для
посадки. Из-за неправильной работы программного обеспечение, управляющий полетом компьютер
Emerson
Confidential вращение двигателя при обнаружении отказа гидравлической системы.
остановил
Slide No. 72

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).
Emerson Confidential
Slide No. 73

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

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
Emerson Confidential
Slide No. 74

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

Emerson Confidential
Slide No. 75

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

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

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

Plan / Replan
Создать план тестирования и провести
экспертный обзор
Test Analysis
Определить что необходимо тестировать и
связь тестов с требованиями
Провести экспертный обзор
Test Design
Создать детальные спецификации тестов и
шагов тестирования
Выполнить экспертный обзор спецификации
тестов
Test Implementation (Automatic tests)
Создать (закодировать) тесты на основе, тест
спецификаций
Test Execution (Regression)
Запустить тесты и проанализировать
результаты тестирования
Занести найденные несоответствия
Evaluate Test Coverage
Проверить, что все требования покрываются
тестами
Emerson Confidential
Slide No. 77

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

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

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

Компоненты датчика
Плата ЦАП
Модуль сенсора
Индикатор с кнопками
Оборудования
Управляемый источник питания
Вольтметр
Мультиплексор сигналов
–
Переключение компонентов датчика
–
Эмуляция нажатия кнопок
–
Создание ошибок платы ЦАП
Анализатор I2C шины Beagle I2C
–
Emerson Confidential
Slide No. 79
Перехват сообщений индикатору и их
анализ
Источник давления

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

http://www.olimpic.tusur.ru/books/GOS/Metodich
ki/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
Emerson Confidential
Slide No. 80

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

Что такое системы контроля версий?
Для чего нужны?
Emerson Confidential
Slide No. 81

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

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

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

Clear Case – система контроля версий от IBM
Ration Rose
Emerson Confidential
Slide No. 83

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

Emerson Confidential
Slide No. 84

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

Emerson Confidential
Slide No. 85

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

Team Foundation Server - Интегрированная система разработки, включающая в
себя контроль версий, раздачу задач, планирование, отслеживание багов, юнит
тестирование, отслеживание состояния проекта и т.д.
Emerson Confidential
Slide No. 86

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

Система контроля версий
Emerson Confidential
Slide No. 87

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

Wikipedia: Система Контроля Версий
Emerson Confidential
Slide No. 88

89. Team Foundation Server

Team Foundation Server
Emerson Confidential
Slide No. 89

90. Team Foundation Server

Возможности отчетов TFS на Share Point
Статус итерации
Статус требований
Статус задач
Статус запросов на
изменение
Оставшаяся
трудоемкость
Количество задач
Emerson Confidential
Slide No. 90
Пример диаграммы отслеживания статуса итерации

91. Team Foundation Server

Возможности отчетов TFS в Excel
Метрика кода
Метрика качества
билдов
Метрика задач
Метрика по
тестам
Emerson Confidential
Slide No. 91

92. 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
Emerson Confidential
Slide No. 92

93. Разработка ПО

Вопросы?
Emerson Confidential
Slide No. 93