Standards and Standartization in Program Engineering. Why Would You Care? Nikolay Pakulin, ISP RAS, Moscow 12 - 14 November 2015 Tools and Methods of Program Analysis in St. Petersburg

1. Стандарты и стандартизация
в Software Engineering.
Какое дело до этого Вам?
Николай Пакулин npak@ispras.ru
Институт системного программирования РАН, Москва

2. Стандарты, они везде!
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
RFC 1738
URL format
RFC 2616
HTTP
ISO 3166
Country
Codes
RFC 1035
Domain
Names
TCP/IP
stack
IEEE 802
(WiFi ,
Ethernet)
W3C
HTML,
CSS3
W3C DOM
ECMA-262
ECMAScript
RFC 2618
HTTP
Secure
FIPS 197
AES
RSA
specification,
ECC
IEEE
1003.1
POSIX
ISO/IEC
15948
(W3C) PNG
Unicode
2

3. Зачем стандарты?
What is
your name?
这是什么?
Не совместимы: не могут
понимать речь друг друга
Kio estas
via nomo?
Mia nomo estas
Xiao
Совместимость!
Стандарты обеспечивают общий язык для взаимодействия
3
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

4. Зачем стандарты?
Основная цель: если две реализации соответствуют
стандарту, они могут взаимодействовать
Реализация 1 Реализация 2Совместимость
4
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

5. Зачем стандарты?
 Стандарты открывают дорогу к
стекам технологий
 Технологии в стеках могут быть
реализованы независимыми
производителями
 Стандарты обеспечивают
совместимость между слоями
различных производителей
 Стандарты - модульность
HTML
HTTP
POSIX API
TCP/IP
WiFi, etc.
5
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

6. Один поставщик
Зачем стандарты?
 Стандарты –
открытый мир
 Совместимость
между
компонентами
от различных
поставщиков
 Vendor lock-in
 Open System
Interconnection
– с 1980х
Browser ServerVendor lock-in
Firefox IIS
Совместимость
Apache
nginx
Tomcat
Explorer
Safari
Chrome
Open Systems
6
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

7. Соответствие стандарту?7
TMPA-2015, Санкт-Петербург

8. Зачем стандарты?
Как установить соответствие стандарту?
Реализация 1 Реализация 2Совместимость
8
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

9. Ответ для большинства случаев
TMPA-2015, Санкт-Петербург, 13 ноября 2015 г.
9
 Тестирование соответствия
 Conformance testing
 Такое же тестирование, как и всегда,
 Но есть нюансы!
Тест
Реализация Вердикт

10. 10
Особенности тестирования соответствия
ISO 9646
 Тестовый набор состоит из
формально заданных тестов, не
привязанных к реализации.
 Цели тестирования (test purposes)
описывают ситуации, подлежащие
проверке. Цель тестирования
реализуется в одном или нескольких
тестах.
 Реализация считается
соответствующей спецификации,
если все цели тестирования успешно
проверены.
Тестовый
набор
Тесты
TP
TP
TP
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

11. Особенности тестирования
соответствия - прослеживаемость
 Тесты проверяют поведение, как оно описано в
стандарте
11
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

12. Особенности тестирования соответствия:
внешне наблюдаемое поведение
12
Стандарт Реализация
… An implementation is not required to have them in the exact
form described here, so long as its external behavior is
consistent with that described in this document. …
RFC 2461

13. Что тестировать?
 Тестируется интерфейс, а не
внутренности
 Тест не зависит от того, какой
алгоритм реализован
 Структуры данных и интерфейсы
должны быть описаны!
 Не тестируются
нефункциональные ограничения
(если их нет в стандарте)
 Производительность, память, и т.д.
 Тесты на некорректные входные
данные
 Только если об этом сказано в
стандарте?
 Дополнительный вопрос –
тестирование поведения,
зависящего от реализации
Sort
Unsorted list
Sorted list
Comparator
13
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

14. Утверждения о соответствии
 В современных
стандартах Вводятся
отдельные секции:
Conformance
 Даётся определение
что считать
«реализацией
соответствующей
стандарту»
 Но во многих случаях
сводится к
тривиальному:
«Должна
удовлетворять всем
требованиям»
Стандарт
14
Введение
Нормативная
часть
Conformance
TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.

15. Стандарты и жизненный цикл15

16. Жизнь и смерть программ
16
- "Работает?" - "Да". - "Каждый день работает?" - "Да". - "Тогда сынок,
ради бога, ничего не трогай!».
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

17. Жизненный цикл
17
 Стандарты
ЖЦ вводят
требования к
организации
процессов
 Цели,
задачи
 Работы,
роли
 Артефакты
Требования
Проектирование
РазработкаТестирование
Эксплуатация

18. Зачем стандарты на жизненный
цикл?
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
18
 Все и так всё знают:
 Придумал, написал, потестил, отдал заказчику
Тест
Код Баги
 В сложных/критических системах это не работает
 Измерять качество продукта по тестам слишком
поздно

19. Проблемы разработки сложного ПО
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
19
 Время: сдаются с опозданием графика
 Деньги: сдаются с превышением бюджета
 Функциональность: сдаются с неполной
функциональностью и/или не той
функциональностью
 Успех: не завершаются!

20. Зачем стандарты жизненного
цикла?20
 Главный посыл:
Качество результата
разработки
определяется
качеством процесса
разработки
 Состав работ
 Управление процессом
 Верификация
Требования
Проектирование
РазработкаТестирование
Эксплуатация
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

21. Эволюция стандартов ЖЦ
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
21
ISO 9000-3
ISO 12207
CMM
ISO 15506
Common
Criteria
Делайте только так!
И будет хорошо
Один процесс
Так – это как?
Процессы и подпроцессы
Слона есть по кусочкам!
Уровни зрелости
Не верю!
Доверие оценке
DO-178
DAL
IEC 61508,
ISO 26262
SIL

22. Стандарты ЖЦ и TMPA
22
Верификация
Требования
проектирова
ние
Разработка
Поставка
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
The subtlest bugs cause the greatest damage and problems.
Bugs will appear in one part of a working program when an 'unrelated' part is modified.
A working program is one that has only unobserved bugs.

23. Модель жизненного цикла
ISO 1220723

24. Модель жизненного цикла
ISO 1220724
 Поставка и приобретение ( 2)
 Управление ЖЦ, инфраструктурой, портфелями
проектов, людьми, качеством
 Управление проектом, оценки рисков, мониторинг,
управление конфигурациями (и ещё 3)
 технические процессы: требования (2), реализация,
тестирование, эксплуатация, сопровождение (и ещё 5)
 подпроцессы реализации— 7
 подпроцессы поддержки — 8
 подпроцессы повторного применения (3)
 23 Процесса, 95 работ, 325 задач, 224 артефакта
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

25. Стандарты ЖЦ: кому?
25
 Стандарты регламентируют активности
жизненного цикла
 Документирование или Бюрократия
 Дополнительные подпроцессы или
Дополнительные кадры
 Требования, проектирование или Долгий путь к
коду
 Что тут думать, трясти надо!
 Тщательная верификация или Дополнительные
расходы
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

26. Стандарты ЖЦ для критических
систем26
 Ошибка ошибке не ровня!
 Катастрофа – отказ может привести к смертям людей,
крупным материальным потерям
 Авария – отказ приводит к существенным негативным
эффектам функциональности или травмам людей
 Критический - отказ приводит к существенному
снижению эксплуатационных характеристик
 Малозначимый - отказ создает неудобство, но
дальнейшая эксплуатация возможна
 Пренебрежимый – отказ не влияет на
эксплуатационные характеристики
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

27. Оценка качества для критических
систем27
Программы
(ЖЦ ПО )
Оборудование
(ЖЦ апп.)
Системная разработка
Оценка
безопасности
надежности
• Архитектура
• Критичность
Требования Требования
Тесты Тесты
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

28. Уровни доверия
28
 Процессы создания ПО для малозначимых
функций - relaxed
 ПО для критических функций должно
разрабатываться по всей строгости!
 Все процессы
 Дополнительные требования к верификации
 Строгий дизайн
 Формальные модели
 Исчерпывающее тестирование
 Safety integrity level (машиностроение),
Design Assurance Level (авиация)
TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.

29. Good Luck With