Всякие-разные истории из мира анализа и проектирования ИТ систем для автоматизации и цифровизации бизнес-процессов. Мысли всякие для обсуждения, которые приходят в голову. Цель - разобраться "что же происходит на самом деле при автоматизации/цифровизации и прочем улучшении бизнес-процессов". Ведущий канала - Женя Скориков. ...Обсуждения в группе приветствуются.

Вот вопрос. С одной стороны в системной инженерии утверждается, что все модели соответствуют/создаются некоторым точкам зрения (view point) некоторых ролей. С другой стороны мы прорабатываем usecase или структуру данных и понимаем, что это делать нужно в случае если это неочевидно. Нужно кому - нам? Тогда это какая-то тавтологическое утверждение "мы проектируем те модели, которые нам интересны". Разработчику ? Но почему модели строятся по одинаковым правилам ? Есть какая-то обьективная потребность(точки зрения), приводящая к тому почему мы строим usecase / структуры данных / модели интерфейсов. Как назвать точку зрения, при взгляде с которой на систему, получается модель usecase (для схем данных, кстати, точку зрения можно назвать взаимосвязью между обьектами)

Новый слоган. "Некогда пилу точить, пилить надо" преобразуется в "Некогда пилу точить, нужно быстро-быстро латать дыры в том, что криво распилили"

Прочитал https://habr.com/ru/post/680376/ Смешанно все. Из плюсов - дан обзор разных стилей реализации API. Из минусов - многие утверждения спорны, как ребята в комментах отписали.

А вот еще статья - https://stackoverflow.blog/2022/07/21/event-driven-topic-design-using-kafka/ . Букв много. Из полезного - обзор разных типов топиков в kafka, и да - kafka не простой брокер очередей "получил-передал". В ней есть некоторая логика организации передачи данных (выдача последнего состояния обьекта с данным ключом и гарантированное сохранение порядка выдачи).

А вот ещё размышление. Кто нибудь видел требования безопасности, сформулированное как свойство системы? Устойчивость к sql инъекциям - это требуемое свойство? Похоже что нет. Sql инъекция это модель атаки. То есть модель взаимодействия. "Требование" устойчивости к иньекциям описывается в виде стандарта/правила, которое должно соблюдаться при программирования. Почему я не считаю стандарт/правило требованием ? Модель взаимодействия и ожидаемый результат от поведения - это потребность. Стандарт/правило описывает как должна быть сделана программа, чтобы этот результат был получен. А где же описание свойства системы ? Его нет. Нужно ли оно? Вероятно нет

Наткнулся на довольно полезное решение от МТС (MTС mobile ID) - упрощение идентификации/сверки перс данных в мобильном телефоне (сайт, приложение), если интернет работает через моб сеть. с помощью операторов связи.

Логика работы:

1. клиент открывает форму идентификации (авторизация, регистрация). Вводит номер телефона. Сайт/приложение отправляет запрос с идентификатором в сервис
2. если связь происходит через моб интернет, то сервис сопоставляет введенный номер и номер телефона, по которому происходит мобильная связь и
2.1. если совпадает, высылает факт подтверждения. Ничего делать не надо
2.2 . если не совпадает - то через SMS, по старому

Основные сценарии использования

1. авторизация/регистрация. Стоимость этого сервиса несколько ниже чем SMS. А клиенту юзабильнее. Поэтому меньше действий.
2. сверка / заполнение данных (фио, дата рождения, пол, адрес, паспортные данные). Тут отдельная тарификация (см тарифы)
Факт отправки считается фактом идентификации для суда, поэтому можно делать подписку на рекламу этого телефона, если человек поставил галочку (не нужен факт ввода sms для доказательства в суде)

Набрел на книжку ITIL v3 2015 по-русски (кому надо - пишите в личку). Полистал. Написано хорошо. Обозначены все моменты ЧТО нужно не забыть. Как всегда очень мало сказано про КАК (как говориться, хотите знать как - идите на трейнинг).

Кстати, я подчерпнул несколько полезных книг в первом из каналов, пользуйтесь

Вот склад Магнит. Какие функциональные элементы вы на нем видите, как устроена работа склада судя по этой фото, как вы считаете? Пишите в комментах ответы

Полтора года без публикаций - это слишком. Начал публиковать накопленные в черновиках материалы. И начал с простого - как давать определения / как определять концепты и вообще понимать о чем идет речь (и да, эта простая методика важна, я слишком часто сталкиваюсь с тем, что аналитики/РП/и пр общаются с заказчиком, но понимают по своему что он говорит, потому что не умеют за терминами увидеть концепты). https://habr.com/ru/post/691604/

Должен ли ИТ-аналитик-проектировщик уметь программировать? Вопрос вызвал жаркие дискуссии в группах аналитиков, количество комментариев перевалило за тысячу. А давайте взглянем на эту задачу системно, от цели ИТ-аналитик-проектировщика - https://habr.com/ru/post/692524/

Благодаря заметкам Максима Цепкова (большое ему спасибо), я наткнулся на записи отличного доклада Ивана Пашкова "Паттерны коммуникации с англоязычными заказчиками". Рекомендую - https://youtu.be/HYFBfW7N8b0?list=PL_XScYmjXxkdmrJPe5uD6woMVSTSY-Iu1

Если вы слышите "Аналитик разрабатывает требования" не верьте своим ушам. Надо говорить "Аналитик-проектировщик проектирует модели решения". Пруф с юморком - https://habr.com/ru/post/696562/

Осознал, что первый вопрос на собеседовании нужно спрашивать такой : "Вы зануда?". Если нет, то скорее всего соискатель не подходит )) а вы как считаете?