NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2
Целостный процесс системной инженерии для сложных технических систем: от ожиданий заинтересованных сторон и требований до интеграции, проверки, эксплуатации и вывода из использования.
Требование NASA — документировать программную архитектуру, преобразующую требования к программному обеспечению; руководство SWEHB поясняет её связь с системной архитектурой, подсистемами, зависимостями и контролем соответствия реализации.
Связывает обеспечение качества и программной безопасности с полным жизненным циклом и системными опасностями, а требуемые свидетельства — с критичностью программного обеспечения.
Устанавливает понятийный каркас описания архитектуры: заинтересованные стороны, их интересы, точки зрения, представления, модели и соответствия между ними.
Метод помогает выбрать архитектурные представления по задачам читателей и описать элементы, отношения, контекст, интерфейсы и связи между представлениями.
sei-atamМетод с 1998 года; актуальная карточка SEI
Встраивает безопасность в системную инженерию: от защитных потребностей и недопустимых потерь до архитектуры, анализа компромиссов и проверяемых свидетельств доверия.
Организует проектирование системы так, чтобы она могла предвидеть атаки, выдерживать их, восстанавливаться и адаптироваться при сохранении критических функций.
Организует результаты управления киберриском через функции Управлять, Выявлять, Защищать, Обнаруживать, Реагировать и Восстанавливать и связывает целевое состояние с профилем организации.
Отказывается считать сетевое положение источником доверия: доступ к отдельному ресурсу выдаётся после проверки субъекта, устройства и контекста и затем переоценивается.
Связывает архитектуру Web с глобальной идентификацией URI, семантикой протоколов, представлениями ресурсов, метаданными, ортогональностью и расширяемостью.
Описывает публикацию повторно используемых данных с метаданными, происхождением, лицензиями, версиями, устойчивыми идентификаторами и программным доступом.
Организует проверку рабочей нагрузки по эксплуатационному совершенству, безопасности и приватности, надёжности, стоимости, производительности и устойчивому использованию ресурсов.
Связывает надёжность с пользовательскими показателями и целями обслуживания, использует бюджет ошибок для баланса стабильности и изменений и устраняет повторяемый ручной труд автоматизацией.
Встраивает обучение, требования безопасности, моделирование угроз, контроль сторонних компонентов, автоматизированные проверки и реагирование на уязвимости в жизненный цикл разработки.
AWS Builders’ Library — Static stability using Availability Zones
В статически устойчивом проекте система продолжает уже выполняемую полезную работу при отказе зависимости или контура управления, не требуя для восстановления новых успешных действий от повреждённых компонентов.
Описывает программно создаваемые и воспроизводимые системы из слабо связанных совместимых компонентов, которые защищены, устойчивы, управляемы, наблюдаемы и допускают частые предсказуемые изменения.
Внутренняя платформа объединяет возможности в самообслуживаемый продукт, снижает когнитивную нагрузку и развивается по обратной связи пользователей, предлагая интерфейсы, шаблоны и золотые пути.
Переносит основную ответственность за безопасность с пользователя на производителя: руководство отвечает за результат, безопасные функции доступны по умолчанию, а классы дефектов устраняются в источнике.
Организует защищённое проектирование вокруг контекста системы, затруднения компрометации и нарушения работы, облегчения обнаружения и уменьшения последствий.
Требует понимать пользователей и всю проблему, создавать связную доступную услугу многопрофильной командой, итеративно улучшать её, измерять результат и надёжно эксплуатировать.
Разделяет совместимость на правовую, организационную, семантическую и техническую и связывает её с ориентацией на пользователя, открытостью, безопасностью, повторным использованием и технологической нейтральностью.