Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TMPA-2015: Standards and Standartization in Program Engineering. Why Would You Care?

2,282 views

Published on

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

Published in: Science
  • Be the first to comment

  • Be the first to like this

TMPA-2015: Standards and Standartization in Program Engineering. Why Would You Care?

  1. 1. Стандарты и стандартизация в Software Engineering. Какое дело до этого Вам? Николай Пакулин npak@ispras.ru Институт системного программирования РАН, Москва
  2. 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. 3. Зачем стандарты? What is your name? 这是什么? Не совместимы: не могут понимать речь друг друга Kio estas via nomo? Mia nomo estas Xiao Совместимость! Стандарты обеспечивают общий язык для взаимодействия 3 TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  4. 4. Зачем стандарты? Основная цель: если две реализации соответствуют стандарту, они могут взаимодействовать Реализация 1 Реализация 2Совместимость 4 TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  5. 5. Зачем стандарты?  Стандарты открывают дорогу к стекам технологий  Технологии в стеках могут быть реализованы независимыми производителями  Стандарты обеспечивают совместимость между слоями различных производителей  Стандарты - модульность HTML HTTP POSIX API TCP/IP WiFi, etc. 5 TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  6. 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. Соответствие стандарту?7 TMPA-2015, Санкт-Петербург
  8. 8. Зачем стандарты? Как установить соответствие стандарту? Реализация 1 Реализация 2Совместимость 8 TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  9. 9. Ответ для большинства случаев TMPA-2015, Санкт-Петербург, 13 ноября 2015 г. 9  Тестирование соответствия  Conformance testing  Такое же тестирование, как и всегда,  Но есть нюансы! Тест Реализация Вердикт
  10. 10. 10 Особенности тестирования соответствия ISO 9646  Тестовый набор состоит из формально заданных тестов, не привязанных к реализации.  Цели тестирования (test purposes) описывают ситуации, подлежащие проверке. Цель тестирования реализуется в одном или нескольких тестах.  Реализация считается соответствующей спецификации, если все цели тестирования успешно проверены. Тестовый набор Тесты TP TP TP TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  11. 11. Особенности тестирования соответствия - прослеживаемость  Тесты проверяют поведение, как оно описано в стандарте 11 TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  12. 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. 13. Что тестировать?  Тестируется интерфейс, а не внутренности  Тест не зависит от того, какой алгоритм реализован  Структуры данных и интерфейсы должны быть описаны!  Не тестируются нефункциональные ограничения (если их нет в стандарте)  Производительность, память, и т.д.  Тесты на некорректные входные данные  Только если об этом сказано в стандарте?  Дополнительный вопрос – тестирование поведения, зависящего от реализации Sort Unsorted list Sorted list Comparator 13 TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  14. 14. Утверждения о соответствии  В современных стандартах Вводятся отдельные секции: Conformance  Даётся определение что считать «реализацией соответствующей стандарту»  Но во многих случаях сводится к тривиальному: «Должна удовлетворять всем требованиям» Стандарт 14 Введение Нормативная часть Conformance TMPA 2015, Санкт-Петербург, 13 ноября 2015 г.
  15. 15. Стандарты и жизненный цикл15
  16. 16. Жизнь и смерть программ 16 - "Работает?" - "Да". - "Каждый день работает?" - "Да". - "Тогда сынок, ради бога, ничего не трогай!». TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  17. 17. Жизненный цикл 17  Стандарты ЖЦ вводят требования к организации процессов  Цели, задачи  Работы, роли  Артефакты Требования Проектирование РазработкаТестирование Эксплуатация
  18. 18. Зачем стандарты на жизненный цикл? TMPA-2015, Санкт-Петербург , 13 ноября 2015 г. 18  Все и так всё знают:  Придумал, написал, потестил, отдал заказчику Тест Код Баги  В сложных/критических системах это не работает  Измерять качество продукта по тестам слишком поздно
  19. 19. Проблемы разработки сложного ПО TMPA-2015, Санкт-Петербург , 13 ноября 2015 г. 19  Время: сдаются с опозданием графика  Деньги: сдаются с превышением бюджета  Функциональность: сдаются с неполной функциональностью и/или не той функциональностью  Успех: не завершаются!
  20. 20. Зачем стандарты жизненного цикла?20  Главный посыл: Качество результата разработки определяется качеством процесса разработки  Состав работ  Управление процессом  Верификация Требования Проектирование РазработкаТестирование Эксплуатация TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  21. 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. 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. 23. Модель жизненного цикла ISO 1220723
  24. 24. Модель жизненного цикла ISO 1220724  Поставка и приобретение ( 2)  Управление ЖЦ, инфраструктурой, портфелями проектов, людьми, качеством  Управление проектом, оценки рисков, мониторинг, управление конфигурациями (и ещё 3)  технические процессы: требования (2), реализация, тестирование, эксплуатация, сопровождение (и ещё 5)  подпроцессы реализации— 7  подпроцессы поддержки — 8  подпроцессы повторного применения (3)  23 Процесса, 95 работ, 325 задач, 224 артефакта TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  25. 25. Стандарты ЖЦ: кому? 25  Стандарты регламентируют активности жизненного цикла  Документирование или Бюрократия  Дополнительные подпроцессы или Дополнительные кадры  Требования, проектирование или Долгий путь к коду  Что тут думать, трясти надо!  Тщательная верификация или Дополнительные расходы TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  26. 26. Стандарты ЖЦ для критических систем26  Ошибка ошибке не ровня!  Катастрофа – отказ может привести к смертям людей, крупным материальным потерям  Авария – отказ приводит к существенным негативным эффектам функциональности или травмам людей  Критический - отказ приводит к существенному снижению эксплуатационных характеристик  Малозначимый - отказ создает неудобство, но дальнейшая эксплуатация возможна  Пренебрежимый – отказ не влияет на эксплуатационные характеристики TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  27. 27. Оценка качества для критических систем27 Программы (ЖЦ ПО ) Оборудование (ЖЦ апп.) Системная разработка Оценка безопасности надежности • Архитектура • Критичность Требования Требования Тесты Тесты TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  28. 28. Уровни доверия 28  Процессы создания ПО для малозначимых функций - relaxed  ПО для критических функций должно разрабатываться по всей строгости!  Все процессы  Дополнительные требования к верификации  Строгий дизайн  Формальные модели  Исчерпывающее тестирование  Safety integrity level (машиностроение), Design Assurance Level (авиация) TMPA-2015, Санкт-Петербург , 13 ноября 2015 г.
  29. 29. Good Luck With

×