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
BDD. The Outer Limits. Iosif Itkin at Youcon (in Russian)
TMPA-2015: Standards and Standartization in Program Engineering. Why Would You Care?
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 г.
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 г.
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.
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 г.