Мы с коллегами-добровольцами подготовили для вас
Базу ссылок на полезные материалы по системной интеграции
для аналитиков и проектировщиков.

В базе собраны ссылки на русскоязычные и англоязычные статьи, видео, книги, сервисы и курсы.

Что в неё сейчас вошло:

Основы интеграции информационных систем
- Постановка задачи и общий обзор
- Способы классификации интеграций

Форматы представления данных
- Форматы JSON и YAML
- Форматы XML и XSD

Сетевые протоколы и транспорт
- Протоколы HTTP, HTTPS
- Протокол WebSocket

Сценарии взаимодействия, Sequence, Plant UML

Web Serviсes / RPC
- Проектирование API
- REST-like сервисы. Стиль REST
- Протокол SOAP и форматы XML, XSD, WSDL
- Технология GraphQL
- Технология gRPC

Обмен сообщениями
- Паттерны обмена сообщениями
- Apache Kafka
- Брокер Rabbit MQ

Файловый обмен

Интеграция через общую БД

Архитектурные паттерны интеграции систем
- Интеграционные шины, Enterprise Service Bus (ESB)
- API Gateway, Backend For Frontend
- Оркестрация и хореография
- Circuit breaker

Дальше готовим другие подборки по темам:

- Базы данных и анализ данных
- Бизнес-анализ и моделирование
- Архитектура программного обеспечения и Systems Design

На курсе по микросервисной архитектуре встретил чеканную формулировку: микросервисная архитектура нужна для снижения lead time в крупных системах. Lead time — время прохождения через цепочку производства отдельной новой функции. Можно сказать, снижение Time-to-market отдельной фичи. И если после перехода на микросервисы — а на микросервисы почему-то всегда переходят, никто не начинает с микросервисов :)) — эта метрика должна упасть. Если растет, в не падает — значит, вы делаете что-то не так. Это очень простое объяснение, ценное для бизнеса.

Agile, кстати, обещает то же самое. Джефф Сазерленд вообще так и назвал свою книгу: как делать вдвое больше работы за половину времени. То есть, пообещал ускорение аж в 4 раза. Это название даже на русский испугались перевести. И всё, у всех теперь SCRUM :) Ну ещё бы, кто же не захочет ускорить работу программистов в 4 раза.

И я задумался: есть ли такое же объяснение для практики системного анализа? Какую одну главную метрику, очевидно ценную для бизнеса, улучшает системный анализ? TTM он как раз скорее снижает — ведь в процесс добавляются дополнительные действия. А вот что улучшает? Как системный анализ продать бизнесу?

К вопросу про ускорение или замедление работ. Часто ТЗ по ГОСТу воспринимают, как waste — потери, что-то излишне формальное и то, что делать совсем не нужно, а нужно только для формального закрытия контракта. Как говорил один мой знакомый — это чтобы нам деньги доехали, к работе это не имеет отношения. Я очень не люблю такие фанерные декорации, хотя на определенном уровне и особенно в госконтрактах это почти повсеместная практика, к сожалению. По сравнению с другими схемами эта ещё выглядит совсем невинно.
Но мне-то ГОСТ 34 нравится (после того, как я в нём разобрался :) практически, как я перестал бояться и полюбил ГОСТы :) )) Мне комфортно с ГОСТом, я могу засунуть туда практически всё, что мне нужно в проекте. А однажды один из пунктов ТЗ по ГОСТу спас меня от очень больших расходов — тот пункт, который обычно относят к "воде": про гарантию работоспособности на конкретных версиях операционных систем.
В общем, я всегда стараюсь приспособить ГОСТ к реальной работе, и не делать дважды в разных видах одно и то же. А на завтра у нас в школе запланирован бесплатный вебинар, на котором как раз про ГОСТ и его осмысленное применение расскажет эксперт, который разделяет со мной это отношение!

‍26 января в 18:00 пройдет бесплатный открытый вебинар, который развеет мифы о ГОСТ 34 и поможет взглянуть на него по-новому. Спикер — Василий Баракин, применяет ГОСТ 34 более 15 лет и в роли архитектора ПО участвовал в проектах Enterprise уровня.

Этот вебинар для вас, если вы:
• аналитик
• руководитель проекта
• технический писатель
• ведущий разработчик
• представитель заказчика
• сотрудник ИТ-компании, работающей с госзаказчиками

Даже если вы не работали по ГОСТ-ам, наверняка вы слышали о них. Стоит ли приходить просто для расширения кругозора? Однозначно, да!

Наш гость:

— Развеет заблуждения о ГОСТ 34 и поможет взглянуть на ГОСТ по-новому
— Покажет ТЗ во взаимосвязи с документами других стадий создания АС
— Раскроет важность пунктов ТЗ, которые либо упускают, либо копируют из Интернета

О спикере:

Василий Баракин:

• Архитектор проектов по информационной безопасности
• Опыт применения ГОСТ серии 34 более 15 лет
• Участвовал в создании автоматизированных систем федерального уровня

У всех слушателей будет возможность задать вопросы в режиме реального времени.

Регистрируйтесь по ссылке, участие бесплатное!

В ходе обсуждения метрики для работы аналитика возникла вот такая мысль: аналитик снижает риск переделки системы. Многие так или иначе про это говорят. И вот что интересно: риск — это вероятность*ущерб. Это чисто математическое определение. Использование практики системного анализа, очевидно, работает на снижение вероятности в этой формуле. То есть, это попытка заранее проработать нужды и потребности заказчика и пользователей, ничего не забыть, не сделать лишнего или ненужного, а сделать сразу только востребованное и полезное. Чтобы не пришлось переделывать или неожиданно расширять объем работ, когда сроки и бюджет уже согласован, а вот о содержании проекта у заказчика и исполнителя оказалось разное мнение.

Риски же тут огромны: Chaos Report дает оценку около 17-20% вероятности полного провала проекта, и 40-50% вероятности значимого выхода проекта за границы сроков или бюджета. Конечно, любому менеджеру хочется снизить такие огромные вероятности. Что интересно, эти вероятности практически не зависят от квалификации команды (если только вы не набрали совсем неподходящих людей — тогда вероятность примерно на 10% выше. Что интересно — связь с высокой квалификацией менеджмента вообще отрицательная — менеджеры с высокой квалификацией с большей вероятностью ведут проект к провалу).

Так вот практики agile или микросервисов подходят к этой задаче с другой стороны — они снижают ущерб. Работа короткими итерациями с частыми поставками (а значит — с частым получением обратной связи) разделяет большую систему на маленькие инкременты, потеря или переделка каждого из которых не несет большого ущерба. Даже если вероятность накосячить очень высока. Кроме того, в процессе этого путешествия команда постепенно узнает предметную область и задачу всё лучше и лучше, а значит — может предложить лучшее решение (см. Paul Ralph, Is Requirements Engineering Inherently Counterproductive?), то есть и вероятность тоже со временем снижается.

Микросервисный подход разделяет ущерб не по времени, а пространственно, структурно — если сломается один микросервис, то большого ущерба это не должно нанести — на то и разделение ответственности и выделение изолированных контекстов.При этом, в общем случае, кажется, эффективность снижения риска оказывается кратно выше, чем в случае применения системного анализа: работу обычно разбивают на очень много коротких итераций, даже в небольшом проекте их обычно больше 20. Микросервисы тоже тяготеют к большому количеству, даже в небольшом проекте из может быть десяток, в крупных системах — сотни.

Навскидку, применение системного анализа вряд ли способно снизить риски в десятки раз. Значит, гораздо выгоднее снижать ущерб — там, при хорошем раскладе, можно добиться кратного снижения рисков. Нельзя сказать, что работа системных аналитиков совсем бесполезна — так как это независимые переменные, вы можете снижать и ущерб, и вероятность, будет только лучше. Главное, чтобы аналитики не тормозили вас в получении обратной связи от пользователей или рынка.

А вы знали, что, если попросить ChatGPT вывести результаты в таблицу, эту таблицу потом можно скопировать и вставить в Miro как отдельные карточки? И потом уже на доске располагать их, как угодно? Например, так можно вытаскивать на доску User Story, идеи для мозговых штурмов, события для Event Storming (шучу, их должны предметные эксперты генерировать) или, например, модули и их API. #chatGPT

А вы читали "Алмазный век, или Букварь для благородных девиц" Нила Стивенсона? Это такая фантастика, одним из центральных элементов в сюжете которой служит "Алмазный букварь" — такой интерактивный, или даже иммерсивный учебник, подстраивающийся под ученика. В принципе, с #chatGPT мы уже очень близки к этому. Вот, например, сказочка про системного аналитика (упоминание Алмазного букваря явно сбило с толку ИИ, потому что в книге Букварь был для маленькой девочки, поэтому и сказка):

"Давным-давно, в мире, где технологии правили всем, жил-был молодой человек по имени Макс, который мечтал стать системным аналитиком. Макс был очарован тем, как работают технологии, и хотел стать частью команды, благодаря которой все это произошло.

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

Макс охотно принял предложение Сэма, и вскоре он узнал обо всех аспектах работы. Он узнал о разработке программного обеспечения, сетевой архитектуре, управлении базами данных и многом другом. Макс был полон решимости стать лучшим системным аналитиком, каким только мог быть, поэтому он усердно работал каждый день, изучая и практикуя свои навыки.

Когда Макс стал более уверенным в своих силах, Сэм предложил ему ряд проектов. Первый проект заключался в разработке системы управления запасами компании. Макс неустанно работал над этим проектом, используя свои знания в области управления базами данных для создания эффективной и удобной для пользователя системы.

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

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

С того дня Макс работал системным аналитиком, используя свои навыки, чтобы помогать компаниям решать их технологические проблемы. Он стал известен как один из лучших в своем деле и гордился тем, что является частью мира технологий, который он так любил.

Конец.

Упражнения и проекты для учащихся:

1. Создайте систему для управления ассортиментом небольшого магазина
2. Спроектировать сетевую архитектуру для школы
3. Создать программу для автоматизации системы выставления оценок ученикам.
4. Напишите отчет о преимуществах и недостатках облачных вычислений для бизнеса.
5. Создайте систему управления базой данных для местной библиотеки."

Довольно часто в запросах и обсуждениях всплывает тема ТРИЗ в системном анализе. Кто-то помнит ещё! Действительно, эта технология мышления — одна из признанных в мире чисто российских/советских разработок. И польза в ней, определенно, есть. Хотя некоторые концепции выглядят просто как здравый смысл :) Впрочем, это не мешает проектировщикам систем сплошь и рядом это здравый смысл не использовать.

Вот, например, техника "9 экранов". Очень мощная, если вдуматься. Обычно же как — аналитик фокусируется на центральном экране — система как есть. (В Systems.Education учат этому на курсе Разработка требований. Это для начала. Хороший аналитик смотрит на надсистему (окружение, использующую систему) и на внутреннюю архитектуру. Появляются интеграции, и это большая тема. Про это тоже есть целый курс. Иногда кто-то задумывается о развитии продукта. Вот тут мы про это рассуждаем — что делать сначала, а что потом. Иногда — про внедрение: например, перенос данных из замещаемых систем. Извините, курса на эту тему пока нет.
А вот удержать полную картину очень сложно: целых 9 точек зрения! И это, вообще, считайте, ТРИЗ ещё не начался — только самая первая техника.

А если аккуратно и вдумчиво задать вопросы про каждый квадрат, выясняется сразу много интересного. У нас же в каждый момент времени есть: взаимодействующие системы, входные данные, идентификаторы и справочники, данные и формы документов на выходе, пользователи и технические средства, сценарии работы. И вот есть прошлое, когда системы ещё нет, настоящее (считаем, что это момент, когда система заработала и подтверждено, что она решает задачу, для которой создана) и будущее (когда система будет решать другие задачи, а потом, в конце концов, будет выведена из эксплуатации). И вместе с системой меняется и её окружение, и её внутреннее устройство.

А значит — данные должны быть подготовлены и загружены в системы (а может, у нас несколько шагов внедрения — например, с параллельной эксплуатацией и постепенным замещением), справочники сконвертированы, смежные системы подключены, пользователи обучены, технические средства выделены и настроены, мониторинг, бэкапы и балансировщики подключены. Всё очень сложно? Так это именно та сложность, о которой писал Фредерик Брукс в "Мифическом человеко-месяце": переход от простой программы к программному продукту или программному комплексу стоит x3, а от программы к системному программному продукту (комплекс+продукт) — x9.

А всего-то чек-лист из 9 экранов #ТРИЗ :)

"9 экранов" ТРИЗ

Я продолжаю исследовать возможности #chatGPT с разных сторон. Вот попросил его накидать основных концепций и технологий в какой-нибудь области. Специально выбрал такую, в которой я поверхностно разбираюсь. Дорогие читатели, а кто-нибудь из вас понимает в блокчейне? Эта диаграмма похожа на правду, хотя бы отдаленно? Или совсем пургу ИИ гонит? Не забыл ли он чего-то важного, не написал ли лишнего? Что бы ещё стоило добавить на диаграмму для понимания этой предметной области? (Тут он, кроме самих концепций, пишет, чем в этой области можно заняться. Например, research и education. Ну и, если что, на каждую связь у него есть объяснение — почему эти концепции связаны. Просто эти объяснения на диаграмму не влезли)

Ты пьян, ChatGPT, иди домой.
Извините, я понимаю, что уже задолбал вас этой ИИ-погремушкой, но не смог удержаться. Кажется, я нашел аналог проблемы с пальцами (знаете же, что генераторы картинок не умеют рисовать пальцы?) для ChatGPT :)))

UPD: Мне тут говорят, что это он сразу рисует, как на самом деле процесс будет работать после внедрения :D

Интересную тут практику я обнаружил на рынке: разработка классических требований по agile-процессу(!). То есть, люди говорят про scrum, работу итерациями и всякое такое, но при этом выясняется, что они либо "по скраму" разрабатывают большое ТЗ на систему (спринтами-итерациями, ага. То есть, такой очень растянутый нулевой спринт, который сам разбит на спринты, и на выходе у которого большой документ), либо у них "опережающие" аналитические спринты: то есть, команда аналитиков идёт на 1-2 спринта впереди разработки, прорабатывая тему и формулируя "ЧТЗ на спринт" для них. В более-менее классическом виде, не какой-нибудь там бэклог из User story или JTBD.

Иногда это не "аналитический" спринт, а опережающий "UX" или "дизайн"-спринт, если аналитиков не, но есть UX-проектировщики (это больше в продуктах или сайтах).

Удивительное дело. Чего только люди не придумают. С другой стороны, работает — не трогай! :)

В продолжение предыдущего поста, заметка-наблюдение: все говорят про Continuous Integration / Continuous Delivery, встречается также термин Continuous Testing. Но я ни разу не слышал про Continuous Analysis... 🤷‍♂️ Только про Analysis Paralysis.

Доброе утро! 😉

Спросил тут у аналитиков — какой была их первая сложность на работе?

Получился вот такой топ ответов:
1. Как добраться до стейкхолдеров (потому что к ним свои же PMы не пускают!)
2. Непонятно, что вообще нужно делать, чего ожидают-то?
3. Нет образца или шаблона, или он есть, но нет понимания, как его заполнять. Нет онбординга, как такового, никто ничего не объясняет.
4. Существующая документация не соответствует реальности, всё не так.
5. Ничего не понятно в предметной области ("почитал документы. понял только предлоги")

А вы с какой первой проблемой столкнулись, когда только начинали работать?

Люди не понимают смысл пользовательских историй. Даже многие авторы книг не понимают. К сожалению, для проекта это зачастую критично: история перестает приносить пользу, не дает новых знаний и не позволяет сделать систему удобной для пользователя. Например, в одной книге я встретил такой пример истории: "Как пассажир, я хочу зарегистрироваться на рейс, чтобы улететь в место назначения". С первого взгляда история выглядит неплохо, но на самом деле в ней есть концептуальный изъян: перекладывание с больной головы на здоровую.

Я, как пассажир, хочу зарегистрироваться на рейс? Серьезно? Вот прям так хочу, что в авиакомпанию напишу: сделайте, пожалуйста, функцию "регистрация на рейс"? По-моему, нет. Я хочу улететь, это да. Я для этого купил билет. И я понимаю, что для этого нужно вовремя приехать в аэропорт. А вот зачем регистрироваться, я не понимаю. Это какой-то бессмысленный шаг, с моей точки зрения. Когда я еду на поезде, мне же не нужно регистрироваться. А почему в самолете нужно? Это для меня лишний шаг. Он для меня не имеет ценности. Если бы его не было, мне было бы только лучше. То есть, история пассажира звучит скорее как "Как пассажир, я хочу, чтобы я как-нибудь автоматически или незаметно регистрировался на рейс, чтобы не тратить время в аэропорту". Отсюда растут все системы онлайн-регистрации, тут сходятся интересы и пассажира, и авиакомпании. Пассажир не хочет терять время, а авиакомпания не хочет держать своих людей на стойках.

Тогда чья это история? Кто хочет, чтобы пассажир зарегистрировался? В чем вообще смысл этого шага? Оказывается, регистрация нужна для того, чтобы разместить багаж и рассадить людей по салону так, чтобы соблюдалась центровка. А для этого нужно знать массу багажа и число пассажиров на момент приезда в аэропорт (то есть, не получится выделить место во время покупки билета). Вероятно, это история капитана или кого-то, кто отвечает за размещение багажа и за безопасность полета. И это хороший пример истории, которая нужна тому, кто и системой-то сам не пользуется. Причем это в случае самолетов уже понятная история, а в какой-нибудь другой предметной области может оказаться не так очевидно, и мы могли бы вполне забыть какую-то важную роль и её потребности.

Вот так. Настоящая история для пассажира получилась противоположной! И если мы хотим сделать лучше пассажиру, мы не должны придумывать — как ему лучше зарегистрироваться. Мы должны придумать, как бы его вообще избавить от этой функции. Тут можно придумать разные варианты — например, автоматически регистрировать на рейс пассажиров без багажа (за дополнительные деньги ;) ). Целую новую услугу можно придумать, если правильно сформулировать пользовательскую историю.

Как оценить качество технического задания? Ну или иного метода работы с требованиями. На что смотреть? Что выбрать?
Что лучше -- use cases или user stories? User stories или job stories? Когда и как применять UML? А BDD-сценарии?

Есть такая штука: Когнитивные измерения. Cognitive dimensions. Не в смысле "померять", а в смысле - задающие пространство. Эти измерения, или шкалы применяются для оценки графических нотаций, языков программирования и пользовательских интерфейсов.
Нотации и языки близки к более-менее формализованным способам записи требований в техническом задании (или любой другой форме описания свойств системы). Так что эти шкалы можно применить и к форме спецификации требований.

На удивление, про когнитивные измерения даже есть статья на русском в Википедии (обычно такие статьи удаляют, как не несущие ценности).

Базируется подход к когнитивным измерениям на 6 базовых действиях с артефактом:
приращение (добавление ещё одного кусочка - строки кода, элемента, ещё одного требования),
транскрипция (можно сказать -- распаковка или превращение, для требований это будет -- воплощение требования в коде),
модификация (тут понятно),
эксплораторное проектирование (когда конечный результат неясен, и вырисовывается только в ходе его обдумывания при помощи нотации / языка),
поиск (тоже понятно -- как найти что-то в спецификации)
и эксплораторное понимание (как из последовательного знакомства с документом понять, о чем вообще речь).

Эти действия очень похожи на то, что мы обычно производим со спецификацией.

Из них авторы выводят 14 "измерений" -- характеристик нотации, языка или интерфейса. Измерения такие:

1. Вязкость. То есть, сопротивление изменениям. Измерить можно как число усилий, требующихся для изменения. Вязкость может быть кумулятивная -- то есть, изменения в одном месте нарушают целостность и влекут каскад изменений в других местах, возможно и на других уровнях абстракции; итеративная -- изменение требует множества мелких действий по внесению исправлений в других местах; вязкость масштабирования -- изменение размера входных данных приводит к изменениях в структуре.

2. Наглядность или видимость. Насколько легко найти требуемый элемент? Насколько легко понять, где искать?

3. Преждевременная фиксация. Вся ли нужная информация предоставлена и рассмотрена к тому моменту, когда зафиксировано решение? Это "N" в критериях INVEST -- требование можно обсуждать до момента реализации, не надо сразу выдавать какое-то решение, неизвестно на чем основанное. Плохой пример: описание конкретных элементов интерфейса в use case.

4. Скрытые зависимости. Как изменение этого требования повлияет на остальные требования? Видно ли это явно? Для спецификации это обычно решают трассировками (которые обычно, конечно же, забывают/забивают).

5. Выразительность ролей. Вот эта штука, которую мы сейчас описываем, она вообще про что? Она как соотносится с остальными частями спецификации? В идеале, когда мы открываем документ, мы должны сразу понять — ага, тут речь про API, или про модель назначения полномочий.

6. Подверженность ошибкам. Насколько используемая нотация или формат провоцирует ошибки? Или наоборот, не дает эти ошибки совершить? Формат требования "система должна X" вообще никак не избавляет от ошибок в формулировках, а вот [Условие срабатывания][субъект][действие][объект][ограничение] помогает выявить и описать поведение лучше.

7. Абстракция. Где границы по уровням абстракции для этой нотации или формата? Понятны ли они? К чему стремится описание в такой форме (иногда говорят о градиенте абстракции)? Например, те же юскейсы обычно сползают по градиенту к деталям реализации, а описания процессов слишком абстрактны.

8. Вторичные обозначения. Есть ли инструмент, позволяющий дать дополнительный контекст этой нотации? Выйти, так сказать, за пределы формального описания? Примечания там, разметка, теги, выделение цветом.

9. Близость соответствия. Насколько выбранное описание похоже на тот объект или действие, которое мы описываем? Похожи ли user stories на взаимодействие двух программных модулей?

10. Согласованность (конститентность). Грубо говоря, одинаковые вещи описываем одинаково, разные - по-разному. Из формы должно считываться, про что мы сейчас говорим (и достраиваться картина -- а что ещё про эту штуку мы обычно хотим знать). То есть, не должно быть такого, что где-то действия пользователя описываются сторями, а где-то -- юскейсами. И где-то юскейсы с полной выкладкой, а где-то -- одни названия.

11. Размытость — сжатость. Это прямо как Data/Ink Ratio у Эдварда Тафти. Сколько чернил или слов можно стереть, чтобы смысл не потерялся? Насколько размыты ваши формулировки?

12. Трудность мыслительных операций. Насколько трудно понять и разобраться, о чем вообще идёт речь? Нужно ли помнить какие-то соглашения, обозначения и приемы? Характерный признак -- читателю приходится вести отдельные заметки, чтобы не забыть, что тут что.

13. Сопоставляемость. Можно ли легко сопоставить между собой разные варианты решения?

14. Поэтапное оценивание. Насколько легко оценить и получить обратную связь когда решение ещё не полностью готово?


Понятно, что эти "измерения" не ортогональны, между ними есть зависимости, причем где-то отрицательные (например, сжатость может вступать в конфликт с трудностью мыслительных операций, а явность зависимостей -- приводить к итеративной вязкости).

Интересно было бы сопоставить разные способы описания требований к ПО по этим шкалам, но это уже за рамками короткого поста в канале 🤷🏼‍♂️ И так пост разрезало на два.

Зато ясно, какие характеристики есть у типичного "ТЗ по ГОСТу": вязкое, непрозрачное, размытое, зачастую неконсистентное, с большим числом скрытых зависимостей, со скачущим уровнем абстракции, переусложненным языком и наполненное преждевременными решениями ⛔️

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

Так вот есть такой канадский ученый-исследователь Paul Ralph, который давно уже топит за то, что в реальных эмпирических исследованиях никаких "требований" не просматривается, это мисконцепция. Ну, у него куча статей с провокационными названиями типа "Иллюзия требований в разработке ПО", "Является ли инженерия требований по сути контрпродуктивной практикой?" и "Как шаблонные спецификации требований убивают креативность", я как-нибудь соберусь написать обзор его взглядов.

Так вот, он вбрасывает красивый термин "desiderata". Это латынь, значит окончание на -a означает множественное число. В единственном будет desideratum, но лучше множественное: пользовательская дезидерата, бизнес-дезидерата.

На русский наиболее точно переводится как "хотелки".

Презентация с моего доклада про User Story Splitting, про разбивку и детализацию пользовательских историй. Это конференция FlowConf'22 — а вот тут можно посмотреть само выступление, бесплатно после регистрации.

Общая идея в том, что истории в бэклоге продукта обычно слишком высокоуровневые и в один спринт не лезут. Либо вообще непонятно, с какой стороны взяться за них. Или самая худшая ситуация — когда сужение истории происходит неосознанно, то самое "заказчик ожидал вооооот всего сколько, а разработчики сделали только маленькую фитюльку, и совсем не про то" — лучше такую детализацию и сужение скоупа делать осознанно, понимая — что мы выбираем и от чего отказываемся.

Тренажер для аналитика. В разных обсуждениях совершенствования в професии регулярно всплывает тема тренажера для системного или бизнес аналитика. Кто-то говорит, что хорошо было бы потренироваться писать юскейсы. Кому-то нужна тренировка в проектировании REST API. Кто берёт уровень выше вот бы взять кейс, и к нему выявить требования / составить проект системы. Есть запрос на тренажеры по UML и SQL — чтобы на примерах из реальной практики.

А вы сталкивались с тренажерами? Знаете успешные примеры? (Необязательно из области анализа). Сами бы что-нибудь хотели потренировать?

Есть вещи, которые меня раздражают и даже бесят. Наверное, это уже возраст :( Например — информационная безопасность. Сплошная профанация часто получается. Системно посмотреть на ИБ никто и не пытается. Вот так, чтобы по-настоящему, не для галочки. Так-то у всех есть ворох документов по защите перс.данных, целые компании работают, чтобы эти документы составить. По объему они обычно толще самых толстых ТЗ. Куча юристов поработало. Аналитики и инженеры их обычно не касались. Зато как доходит до практики...

Я последние лет 8 занимаюсь EdTech. И вот в одном проекте повадились школьники тесты взламывать, ботов понаписали — ты ему номер теста — он тебе верные ответы. Вода дырочку найдёт. Особенно если на фронт сразу в xml и вопросы, и правильные ответы слать. Ну, отловили, выявили, API переделали, ответы припрятали. Я у техлида спрашиваю — какие варианты атаки есть? Говорит: мы эту дырку прикрыли. Ок, эту прикрыли, а другие? Это какие такие другие? Ну, которые ещё можно придумать. Будут же дальше пытаться. Ну, найдут ещё — прикроем и их.

Нет, говорю, так не пойдёт. Это реактивное действие. У вас модель нарушителя есть? Уязвимости? Векторы атаки? Какая ещё такая, удивляется, модель нарушителя? У нас в БД разные модели,но модели нарушителя нет, не понимаю, о чём вы. Ну как же, говорю. Ведь наверняка для системы есть документы на ИБ, она же аттестована. В общем, долго разбираемся, и тут её переключает: а! говорит. Персональные данные! Есть модель нарушителя, конечно. И риски. Всё там есть. Только какое это отношение к тестам имеет? [и вообще к реальной жизни]

Бесят такие вещи. Есть же методика, страховка от глупостей. Тогда ведь учителя так к электронным тестам и не вернулись, не верят, что их снова не взломают. Продукт в итоге толком не работает. Оттого, что никто идею анализа ИБ не ухватывает. Я когда-то прошел курс по ISO 27001, и это очень потом помогало. Для аналитика это, пожалуй, перебор, да и стоит сейчас наверное под 30 тыс. А вот чтобы вникнуть в тему — у нас в эти выходные (11-12 марта) будет воркшоп, там быстро, на человеческом языке и с практикой можно основные понятия освоить. А ещё у меня 12 день рождения, и я вам поэтому сгенерил немного промо-кодов: YKSI12 (их штук 10, так что разбирайте. На другие курсы тоже действуют).