tgoop.com »
United States »
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. » Telegram Web
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Первая часть обзора книги "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
🔵 Как будто больше маркетинга, чем рациональных доводов
🔵 В доводах указываются вещи, которые я бы не связал напрямую с OAuth
🔵 Не хватило секции “почему не что-то другое”
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Илиюный неокрепший ум… Не знаю, в общем.
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
1️⃣ Identity & Access Management — Authorization Server
2️⃣ API Management — API Gateway
3️⃣ Entitlement Management — Policy Engine
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
В первой главе авторы пробуют ответить на вопрос: “А зачем нам вообще OAuth?”.
И уже с первой страницы главы авторы делают мне приятно и используют понятие “аутентификация запросов”, ставим лайк. А вот сама аргументация “за” использование OAuth здесь не сильно впечатлила:
Ну то есть я, будучи сам сторонником использования OAuth, читая, вижу натянутость приведенных аргументов. Но я-то для себя об этом думал, и у меня есть другие! А вот если читать будет скептически настроенный критик… Или
Тут же авторы приводят пояснение, что они понимают под Cloud Native:
Cloud native is a technology approach for operating services and infrastructure in a vendor-neutral way.
Как говорится, а мужики-то не знают! Интересное определение, да? В общем, приведенное описание Cloud Native здесь не понял, как будто “в общих словах” все.
После вводной главы об основах OAuth и OIDC, в третьей, авторы переходят к понятию API security architecture. Тут мне откликнулась мысль о выделении ключевой триады функций и соответствующих им ключевых компонентов:
Я очень солидарен с тем, что в современных системах, говоря о вопросах IAM, мало думать только про “аутентификацию и авторизацию”, как говорили раньше. В том числе в более расширенном смысле на это смотрит и концепция Identity Fabrics, про которую писал ранее (пост 1, пост 2).
Модные названия у такой расширенной области могут быть разными, как разными могут быть и ее границы. Вот такой краткий вариант с выделением трех базовых и понятных функций-компонентов тоже хорош, поскольку позволяет для их рассмотрения абстрагироваться от прочих деталей.
Дальше начинаются действительно интересные главы. В главе четыре предлагается взглянуть на некоторые функции и дизайн данных самого компонента authorization server. Во-первых, хочется сказать, что про это вообще мало пишут, а во-вторых, напомню, что у Curity как раз есть свое IAM-решение, поэтому можно надеяться, что ребята в целом должны знать, о чем говорят.
Авторы обращают внимание на существование различных категорий данных у authorization server. Приведенная конкретно здесь классификация показалась чуть странной, но в целом сама мысль верная. Подумав в эту сторону, мы можем увидеть, что данные различаются своими характеристиками, жизненными циклами, характерами нагрузки и пр. И, например, понять, что для разных данных нам (внезапно) могут понадобиться различные хранилища (СУБД). Для примера можно посмотреть, как аналогичный подход применяют RooX в своем UIDM, используя несколько СУБД, в том числе Tarantool для хранения токенов и сессий.
Говорится о подходах к определению пользовательских данных, которые уместно хранить на стороне authorization server. Рассматривают различные подходы к работе с атрибутами пользователя, в том числе и такой, где сам authorization server может сходить в другой сервис за данными пользователя, которые хранятся там. Я уже писал о кейсе, когда это может быть применимо, разбирая Rich Authorization Requests (RAR).
Также авторы упоминают и про довольно важные вещи вроде управления конфигурациями, мультитенантности и мультирегиональности.
Кстати, пользовательская миграция через SCIM показывается на примере любопытной задачки: вот есть такие-то собранные в кучу данные (AS IS), давайте приведем их к желаемому виду, разделив на identity-данные и бизнес-данные (TO BE). Мне подумалось, что такой кейс может быть здорово рассмотреть в процессе собеседования, чтобы посмотреть, как кандидат смотрит на подобные вопросы. Выглядит пока незаезженно 😈
#book #iam_general #oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
❤1👍1🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[2/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
🔵 валидация входящих временных учетных данных
🔵 трансляция их в JWT access token для конечных сервисов.
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
🔵 Здесь получаете не отдельный токен доступа в виде JWT, а обернутый в JWT тот же ответ от introspection endpoint
🔵 Таким образом два представления токена доступа полноценно не “развязать”: полученный JWT не ограничить отдельно по времени жизни или области действия
🔵 Сами авторы RFC пишут, что возвращаемый здесь JWT “is not an alternative representation of the introspected access token and is not intended to be used as an access token”
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
🔵 Flexibility (API работают только с предоставленным результатом, саму логику контроля доступа можно изменять, не ломая их)
🔵 Auditability (имеем события аудита как для применения политик, так и их для изменения)
🔵 Security agility (отделение ЖЦ политик доступа от ЖЦ конечных сервисов)
🔵 Quality assurance via policy as code (если политики прописываются отдельно, сами сервисы могут не тестировать их внутреннюю логику, а покрывать только возможные исходы)
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
While secure flows are essential, they should be complemented by a keen focus on access tokens.
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
We have seen that your overall API security is distributed between the API gateway APIs, and possibly additional components such as service meshes.
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной entitlement management system (EMS):
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1🔥1
Forwarded from Архитектура ИТ-решений
Когда речь заходит о записях архитектурных решений (architecture decision records, ADR) часто возникает вопрос: где посмотреть реальный пример? Вот чтоб в проекте более-менее долго фиксировались решения, уточнялись, пересматривались и т.п.
... и тут все обычно начинают мяться, вспоминают про NDA
Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
... и тут все обычно начинают мяться, вспоминают про NDA
Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
GitHub
GitHub - nats-io/nats-architecture-and-design: Architecture and Design Docs
Architecture and Design Docs . Contribute to nats-io/nats-architecture-and-design development by creating an account on GitHub.
❤7👍2🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное…
Немного модифицировал JIRA to TaskJuggler convertor ( https://github.com/emacsway/jira-juggler ), чтобы он сохранял иерархию Epic -> UserStory -> Task. Удобно для извлечения и планирования эпика целиком.
GitHub
GitHub - emacsway/jira-juggler: JIRA to TaskJuggler convertor
JIRA to TaskJuggler convertor. Contribute to emacsway/jira-juggler development by creating an account on GitHub.
👍1🔥1🙏1
Forwarded from Системный сдвиг
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
👍8🤔3❤1
Forwarded from SWE notes
Putting the “You” in CPU
Отличный материал для погружения в работу ПК на примере Linux.
Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи
#sysprog #linux #os
Отличный материал для погружения в работу ПК на примере Linux.
Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи
#sysprog #linux #os
Putting the "You" in CPU
Curious exactly what happens when you run a program on your computer? Learn how multiprocessing works, what system calls really are, how computers manage memory with hardware interrupts, and how Linux loads executables.
👍5🔥2
Catalog of legacy modernization patterns by Nick Tune:
https://legacy-modernization.io/patterns/
https://legacy-modernization.io/patterns/
Legacy-Modernization.io
Patterns
Common patterns for modernizing legacy systems.
🔥10❤1
Forwarded from Russian Association of Software Architects (Ivan)
"On Orchestrators: You Are All Right, But You Are All Wrong Too"
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
Dlthub
On Orchestrators: You Are All Right, But You Are All Wrong Too
👍2
Forwarded from Russian Association of Software Architects (Сергей Баранов)
www.latent.space
The 2025 AI Engineering Reading List
We picked 50 paper/models/blogs across 10 fields in AI Eng: LLMs, Benchmarks, Prompting, RAG, Agents, CodeGen, Vision, Voice, Diffusion, Finetuning. If you're starting from scratch, start here.
👍4
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
С какими трудностями я обычно сталкивался в своей практике при реализации Specification Pattern? 1. Расслоение, если мы хотим применять его как для фильтрации объектов в оперативной памяти, так и в БД. Обычно эта проблема решается через Expression Tree, но…
Очень похоже на готовый Specification Pattern из коробки, причем, судя по исходникам, работает и с БД, и с объектами в оперативной памяти.
https://github.com/EvgSkv/logica
https://github.com/EvgSkv/logica
GitHub
GitHub - EvgSkv/logica: Logica is a logic programming language that compiles to SQL. It runs on DuckDB, Google BigQuery, PostgreSQL…
Logica is a logic programming language that compiles to SQL. It runs on DuckDB, Google BigQuery, PostgreSQL and SQLite. - EvgSkv/logica
👍3🔥2🙏1
Forwarded from Сергей Баранов
„Если ты хочешь построить корабль, не надо созывать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю. Тогда они сами построят корабль…“ — Антуан де Сент-Экзюпери
🔥14👍6👎3
Очень часто слышу "бизнес-логика" от слова "бизнес" - зарабатывать деньги.
Бизнес переводится с английского "дело".
"It's not your business!" - "Не твое дело!"
Бизнес логика - это то, что будет "делать" система или сервис. Это причина его возникновения.
В большинстве случаев "бизнес-логика" тождественна "доменной модели", когда система призвана автоматизировать какой-то процесс предметной области.
[UPDATE]:
-- Ward Cunningham
http://wiki.c2.com/?CategoryBusiness
Бизнес переводится с английского "дело".
"It's not your business!" - "Не твое дело!"
Бизнес логика - это то, что будет "делать" система или сервис. Это причина его возникновения.
В большинстве случаев "бизнес-логика" тождественна "доменной модели", когда система призвана автоматизировать какой-то процесс предметной области.
[UPDATE]:
Business - Software intersects with the Real World. Imagine that.
-- Ward Cunningham
http://wiki.c2.com/?CategoryBusiness
👍19🔥3❤1
Stay ahead, lead the future of AI in project management
Artificial intelligence (AI) is here to stay. Join us in leading the AI transformation where the future of project management blends AI and human ingenuity, fueled and guided by our global community.
https://www.pmi.org/learning/ai-in-project-management
Artificial intelligence (AI) is here to stay. Join us in leading the AI transformation where the future of project management blends AI and human ingenuity, fueled and guided by our global community.
https://www.pmi.org/learning/ai-in-project-management
www.pmi.org
Artificial Intelligence in Project Management | PMI
AI is impacting the future of project management and changing how professionals approach projects. Learn how to leverage AI in project management today.
Leading AI Transformation: Organizational Strategies for Project Professionals
Project Management Institute
Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
https://www.pmi.org/standards/leading-ai-transformation-organizational-strategies-for-project-professionals
Project Management Institute
Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
https://www.pmi.org/standards/leading-ai-transformation-organizational-strategies-for-project-professionals
www.pmi.org
Leading AI Transformation: Organizational Strategies for Project Professionals
Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
AI Essentials for Project Professionals
A companion guide to incorporating AI in day-to-day project management.
https://www.pmi.org/standards/ai-essentials-for-project-professionals
A companion guide to incorporating AI in day-to-day project management.
https://www.pmi.org/standards/ai-essentials-for-project-professionals
www.pmi.org
AI Essentials for Project Professionals
🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Из г...глины и палок? Чтобы работало? Легко! В руках мастера, как говорится...
Даже не знаю, что меня смущает больше — деревянный мотоцикл или глиняный шлем.
Даже не знаю, что меня смущает больше — деревянный мотоцикл или глиняный шлем.
🔥5😁5👍3🤩1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное…
Добавил в TaskJuggler поддержку подсчета Standard Deviation:
https://github.com/emacsway/TaskJuggler/tree/standard_deviation
Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.
Как это работает у меня сейчас. Мой коллега разработал для Jira плагин, который позволяет вводить трехточечную оценку по методу PERT. Это очень важный плагин, который решает целый ряд проблем, начиная от психологических (разработчики склонны оптимизировать оценки, а бизнес склонен воспринимать планирование как обязательство и понукать сроками) и заканчивая математическими (вероятностную распределенность невозможно выразить одним значением).
Из трех значений плагин выводит вероятностную оценку и среднеквадратичное отклонение. Если хотите посчитать вручную, то это можно сделать с помощью PERT-калькулятора. Далее эти оценки по специальным правилам суммируются, но в контекста TaskJuggler функции и возможности плагина нам уже не интересны.
Интеграционный скрипт при экспорте задач из Jira в TaskJuggler извлекает эти оценки и высчитывает вероятностную оценку (effort) и среднеквадратичное отклонение (stdev).
Для контейнерного типа задач TaskJuggler суммирует stdev как корень квадратный суммы квадратов. Значение получается в человеко-днях уже с учетом фокус-фактора.
Для нахождения пессимистического срока эпика используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).
Список литературы по планированию см. здесь.
#Estimation #Scheduling #TaskJuggler #PERT
https://github.com/emacsway/TaskJuggler/tree/standard_deviation
Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.
Как это работает у меня сейчас. Мой коллега разработал для Jira плагин, который позволяет вводить трехточечную оценку по методу PERT. Это очень важный плагин, который решает целый ряд проблем, начиная от психологических (разработчики склонны оптимизировать оценки, а бизнес склонен воспринимать планирование как обязательство и понукать сроками) и заканчивая математическими (вероятностную распределенность невозможно выразить одним значением).
Из трех значений плагин выводит вероятностную оценку и среднеквадратичное отклонение. Если хотите посчитать вручную, то это можно сделать с помощью PERT-калькулятора. Далее эти оценки по специальным правилам суммируются, но в контекста TaskJuggler функции и возможности плагина нам уже не интересны.
Интеграционный скрипт при экспорте задач из Jira в TaskJuggler извлекает эти оценки и высчитывает вероятностную оценку (effort) и среднеквадратичное отклонение (stdev).
Для контейнерного типа задач TaskJuggler суммирует stdev как корень квадратный суммы квадратов. Значение получается в человеко-днях уже с учетом фокус-фактора.
Для нахождения пессимистического срока эпика используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).
Список литературы по планированию см. здесь.
#Estimation #Scheduling #TaskJuggler #PERT
GitHub
GitHub - emacsway/TaskJuggler at standard_deviation
TaskJuggler - Project Management beyond Gantt chart drawing - GitHub - emacsway/TaskJuggler at standard_deviation
🔥11❤1👍1🙏1