Больше видео хороших и разных про ИИ!
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
👍10
Как разобраться с JSON?
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
{ "id": 12345,
"name": "Константин",
"surname": "Константинопольский",
"birthdate": "1990-04-14"
}Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
👍20🤯7❤6
Вообще я хотел серьезный пост написать про математику, которая помогает в интеграциях, но потом вспомнил — какое сегодня число и какой день недели, и понял, что никто толком не работает, и умная тема не зайдет.
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
5😁59❤8👍3
Или вот хардкорный пост.
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javanoscript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.💐 🌸 🌷
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javanoscript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥47❤30❤🔥13👍5👎3
Про математику в системном анализе и проектировании.
Я вообще топлю за инженерные методы в разработке, в частности — за расчеты. Вы, наверное, могли заметить. Используются математические методы в анализе и проектировании нечасто. Тем ценнее ситуации, когда их можно применить, причем с очевидной пользой.
Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?
Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.
Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.
Оно задается жутковатой формулой вероятности:
P(k)=λˆk*eˆ-λ/k!
(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),
где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.
В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016
Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!
А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.
Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.
Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.
Применяйте инженерные методы в системном анализе!
Я вообще топлю за инженерные методы в разработке, в частности — за расчеты. Вы, наверное, могли заметить. Используются математические методы в анализе и проектировании нечасто. Тем ценнее ситуации, когда их можно применить, причем с очевидной пользой.
Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?
Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.
Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.
Оно задается жутковатой формулой вероятности:
P(k)=λˆk*eˆ-λ/k!
(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),
где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.
В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016
Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!
А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.
Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.
Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.
Применяйте инженерные методы в системном анализе!
🔥54👍27🤯8😁2👎1
36 лет назад в этот день, а может быть в предыдущий, инженер Европейского центра ядерных исследований Тим Бернерс-Ли, занимавшийся высокоскоростной шиной FASTBUS для сбора информации с датчиков микрочастиц и разработкой технологий RPC для неё, представил своему руководителю Майку Сендаллу "Предложение по управлению информацией".
Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.
Часто это приводило к тому, что две соседние лаборатории работали над дублирующими друг друга проектами, а разобраться в том, кто использует конкретную установку или датчик, и чей эксперимент слетит, если их немного перенастроить — не представлялось возможным. А когда что-то ломалось, требовалось просто детективное расследование причин и технических деталей.
Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?
Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования
а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.
Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться
Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).
По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.
Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.
Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹
Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.
Часто это приводило к тому, что две соседние лаборатории работали над дублирующими друг друга проектами, а разобраться в том, кто использует конкретную установку или датчик, и чей эксперимент слетит, если их немного перенастроить — не представлялось возможным. А когда что-то ломалось, требовалось просто детективное расследование причин и технических деталей.
Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?
Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования
а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.
Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться
Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).
По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.
Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.
Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹
🔥31🎉24👍5❤4
Я иногда просматриваю программы конференций по инженерии требований, чтобы понять, о чем сейчас говорят, какие темы актуальны.
Их две топовых:
RE (собственно, Requirements Engineering) от IEEE и
REFSQ (Requirements Engineering: Foundation for Software Quality), с участием IREB и Springer.
В 2025 обе проходят в Испании: REFSQ вот сейчас в апреле в Барселоне, RE в сентябре в Валенсии.
Это прям научные конференции, проходят в университетах, с профессорами и исследовательскими докладами. Впрочем, обычно есть и индустриальный трек, это больше на наши конференции похоже.
Программы SE пока нет, а в REFSQ, ожидаемо, чуть ли не треть докладов про ИИ и LLM.
Но удивила меня тема конференции. Фокус, так сказать. Пока мы тут, на WAW например, ИИ выносим на флаг, в западном мире людей совсем другое интересует.
Знаете, что?
Социальная ответственность!
(Social REsponsibility)
Это круто, и я про это тоже часто думаю.
То, что мы делаем, то, какие системы создаем, какие функции в них реализуем — как это влияет на жизнь людей?
Осознаем ли мы это влияние и свою ответственность?
Как организаторы пишут:
А, какая формулировка!
Соответственно, вопросы, которые они выносят на обсуждение:
➡️ Как наше сообщество инженеров по требованиям (читай — системных аналитиков) может внести вклад в «общественное благо»?
➡️ Как поддержать «ответственное проектирование» (Responsible Design) посредством разработки требований?
➡️ Как активно вовлекать общество (крупные/разнородные группы заинтересованных сторон) в разработку требований (например, совместное создание/совместное проектирование)?
➡️ Как систематически извлекать, проектировать и оценивать социальные ценности и воздействия?
➡️ Как согласовать социальные потребности и эволюцию «интеллектуальных» систем?
А вам как кажется, актуальные темы для нашего сообщества? Хотели бы вы их обсудить на какой-нибудь конференции?
Их две топовых:
RE (собственно, Requirements Engineering) от IEEE и
REFSQ (Requirements Engineering: Foundation for Software Quality), с участием IREB и Springer.
В 2025 обе проходят в Испании: REFSQ вот сейчас в апреле в Барселоне, RE в сентябре в Валенсии.
Это прям научные конференции, проходят в университетах, с профессорами и исследовательскими докладами. Впрочем, обычно есть и индустриальный трек, это больше на наши конференции похоже.
Программы SE пока нет, а в REFSQ, ожидаемо, чуть ли не треть докладов про ИИ и LLM.
Но удивила меня тема конференции. Фокус, так сказать. Пока мы тут, на WAW например, ИИ выносим на флаг, в западном мире людей совсем другое интересует.
Знаете, что?
(Social REsponsibility)
Это круто, и я про это тоже часто думаю.
То, что мы делаем, то, какие системы создаем, какие функции в них реализуем — как это влияет на жизнь людей?
Осознаем ли мы это влияние и свою ответственность?
Как организаторы пишут:
Инженерия требований — это социально-техническая дисциплина, которая направлена на понимание и анализ потребностей заинтересованных сторон, затронутых внедрением цифровых решений, и на передачу этих потребностей команде разработчиков. Эта роль посредника позволяет нашему сообществу оказывать существенное влияние на цели, возможности, функциональность и качество цифровых решений и, таким образом, брать на себя ОТВЕТСТВЕННОСТЬ за социальное воздействие, которое приносят эти решения.
А, какая формулировка!
Соответственно, вопросы, которые они выносят на обсуждение:
А вам как кажется, актуальные темы для нашего сообщества? Хотели бы вы их обсудить на какой-нибудь конференции?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23❤9🤔7🗿3
О, вот это самое крутое выступление за последние несколько лет, которое я слышал на конференциях! Зал был битком, там видно. И ещё это интерактив!
Сама тема вообще не специфичная для аналитика — это в чистом виде практикум по противодействию манипуляторам на работе. А может быть, как раз для аналитиков будет актуально — у нас вечно не совсем четко определены границы рабочих обязанностей, поэтому навешать лишнего забесплатно — это у нас постоянно.
В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂
Сама тема вообще не специфичная для аналитика — это в чистом виде практикум по противодействию манипуляторам на работе. А может быть, как раз для аналитиков будет актуально — у нас вечно не совсем четко определены границы рабочих обязанностей, поэтому навешать лишнего забесплатно — это у нас постоянно.
В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂
👍8❤2💯2
Forwarded from Flow — конференция про системный и бизнес-анализ
#видеозаписи
Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».
YouTube | VK Видео
Скачать презентацию с сайта Flow
Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».
YouTube | VK Видео
Скачать презентацию с сайта Flow
👍13