Yonote после оплаты сервиса не смогли импортировать 1гб архива из notion и на моё письмо с просьбой вернуть 5тр, тк они не представляют обещанных функций, ничего не ответили.
В наше время каждой команде из 5 человек уже проше свой софт с Ai написать, чем доверять челябинским школьникам, не знакомым с понятием «деловая репутация«.
> какая угодно модель (модель данных, модель процессов, модель описывающая требования к ПО, организационная структура и т. д.
ещё раз. 1. есть модели в виде текста — например, журналистской статьи 2. есть математические модели в виде формул y = x^2 (это НЕ просто текстовые модели, это опять излишнее необоснованное обобщение) 3. есть математические модели в виде графика (НЕ векторного) 4. есть модели в виде натурных макетов (папье маше, 1:43 и т.д.) 5. есть модели в виде 3D-4D-баз данных и т.д.
перестаньте пожалуйста заниматься детским максимализмом «наш рынок — весь мир», «мы моделируем что угодно», «agile походит везде, и в атомной промышленности», найдите зону применимости инструмента
Я не специалист по сусликам, не знаю на сколько точная модель.
Из структурно-графовых моделей как минимум тут скорее бы пригодилась модель состояний, тк она именно показывает смену отношений.
Но я скорее о том, что вот у вас колония из 120 сусликов, между ними есть какие-то отношения и они как-то меняются во времени. Эти отношения можно описать триадами Суслик1, Суслик2, Характер отношения А, [Интервал действия]. Это я предложил фактически текстово-табличную модель, которой можно описать все 120 сусликов и все их отношения. Как тут помогут ваши графовые схемы, пока плохо понятно.
Но очень сложно в двух словах описать что в этом инструменте можно моделировать, да, что угодно — архитектуру ПО, деятельность предприятия, генеалогическое древо, рецепты приготовления пирожков
Работа аналитиков, архитекторов, а тем более онтологов и методологов, на которых вы замахиваетесь, как раз и состоит в выборе адекватных моделей. Именование категории моделей — это тоже модель и моделирование.
Через системное проектирование, вестимо. Как минимум поделить юскейсы по пакетам. Пакеты рассмотреть как кандидаты в подсистемы или сервисы. Принять решение про разбиение системы на части. В целом это описано у Лармана, только долго и нудно.
Непонятно, на какое понимание БТ вы опираетесь. Вигерс и BABOK считают бизнес-требованиями цели организации в конкретной инициативе оргразвмтия.
На ISO 29148? Но там вроде БТ понимаются как бизнес-процессы и бизнес-функции уровнем выше юскейсов.
А ваши юскейсы даже не про бизнес-уровень, а про человеко-машинное взаимодействие, которое по стандартам системной инженерии находится между 2-м и 3-м уровнем:
На мой взгляд, нет противоречия между code first и model first. Модель — это упрощенно граф
А вот и причина. Текст — это тоже модель. И таблица модель. Вы зачем-то подменяете понятие модели именно графической моделью, причём именно структурной схемой (а не графиком и не макетом интерфейса).
Те вы в своей онтологии промахнулись на 2 системных уровня.
Проблема не в том, что эта статья написана с помощью ИИ.
Проблема в том, что эта статья написана с помощью старой плохой версии ИИ (например, 4o вместо о1) и промт-инженером, которому не хватает квалификации в вопросе управления организациями, чтобы почелленджить ИИ чтобы он вместо воды давал мясо.
в тесте «System Analyst Middle» все вопросы про и для бизнес-аналитика, те основые темы 3 — бизнес-процессы, требования, процессы разработки, и ожидаемо нет ничего про БД, интеграции, архитектуру.
почему у БА такое внимание процессам разработки-взаимодействия уделяется — непонятно, он же не процессный инженер.
непонятна разница между тестами «System Analyst» и «System Analyst Middle».
Yonote после оплаты сервиса не смогли импортировать 1гб архива из notion и на моё письмо с просьбой вернуть 5тр, тк они не представляют обещанных функций, ничего не ответили.
В наше время каждой команде из 5 человек уже проше свой софт с Ai написать, чем доверять челябинским школьникам, не знакомым с понятием «деловая репутация«.
Как всегда с 1С — какие-то идиотские истории из 90-х. Вы ещё про обновление баз с дискетки расскажите или про Win3.1 на 50 дискетах
итого, это видимо именно структурные модели
> какая угодно модель (модель данных, модель процессов, модель описывающая требования к ПО, организационная структура и т. д.
ещё раз.
1. есть модели в виде текста — например, журналистской статьи
2. есть математические модели в виде формул y = x^2 (это НЕ просто текстовые модели, это опять излишнее необоснованное обобщение)
3. есть математические модели в виде графика (НЕ векторного)
4. есть модели в виде натурных макетов (папье маше, 1:43 и т.д.)
5. есть модели в виде 3D-4D-баз данных
и т.д.
перестаньте пожалуйста заниматься детским максимализмом «наш рынок — весь мир», «мы моделируем что угодно», «agile походит везде, и в атомной промышленности», найдите зону применимости инструмента
Из структурно-графовых моделей как минимум тут скорее бы пригодилась модель состояний, тк она именно показывает смену отношений.
Но я скорее о том, что вот у вас колония из 120 сусликов, между ними есть какие-то отношения и они как-то меняются во времени. Эти отношения можно описать триадами Суслик1, Суслик2, Характер отношения А, [Интервал действия]. Это я предложил фактически текстово-табличную модель, которой можно описать все 120 сусликов и все их отношения. Как тут помогут ваши графовые схемы, пока плохо понятно.
Работа аналитиков, архитекторов, а тем более онтологов и методологов, на которых вы замахиваетесь, как раз и состоит в выборе адекватных моделей. Именование категории моделей — это тоже модель и моделирование.
Вы видимо говорите о графовых схемах.
Через системное проектирование, вестимо. Как минимум поделить юскейсы по пакетам. Пакеты рассмотреть как кандидаты в подсистемы или сервисы. Принять решение про разбиение системы на части. В целом это описано у Лармана, только долго и нудно.
Если вам удобно — просите нейросеть переводить его в UML и не парьте мозги людям. Разрабатывать и поддерживать удобнее в тексте.
Бред сивой кобылы пошёл :(
И опять ошибка думать, что use case — это диаграмма
Непонятно, на какое понимание БТ вы опираетесь. Вигерс и BABOK считают бизнес-требованиями цели организации в конкретной инициативе оргразвмтия.
На ISO 29148? Но там вроде БТ понимаются как бизнес-процессы и бизнес-функции уровнем выше юскейсов.
А ваши юскейсы даже не про бизнес-уровень, а про человеко-машинное взаимодействие, которое по стандартам системной инженерии находится между 2-м и 3-м уровнем:
Business Requirements
Stakeholder Requirements
System Requirements
Software Requirements
А вот и причина. Текст — это тоже модель. И таблица модель. Вы зачем-то подменяете понятие модели именно графической моделью, причём именно структурной схемой (а не графиком и не макетом интерфейса).
Те вы в своей онтологии промахнулись на 2 системных уровня.
Моделирования чего? Изменения давления в трубах при фазовых переходах? Развития межличностных отношений у сусликов?
Удивительно, что энтузиасты моделирования не умеют точно называть предмет обсуждения
Проблема не в том, что эта статья написана с помощью ИИ.
Проблема в том, что эта статья написана с помощью старой плохой версии ИИ (например, 4o вместо о1) и промт-инженером, которому не хватает квалификации в вопросе управления организациями, чтобы почелленджить ИИ чтобы он вместо воды давал мясо.
«Audi не прокомментировала новость с вирусным роликом, но прокомментировали члены коломенского клуба-форума владельцев Audi»
Примерно такого уровня значимость новости
Там про продукты, а не проекты
если кто-то понял и поверил, что нужно учить, чтобы стать лучшим — напишите, интересно понять, что вы поняли и во что поверили
Опять в заголовке не хватает указания о каких аналитиках речь.
Явно речь про аналитиков данных и BI, а не любых.
NB: в 2002-м году я работал в компании CBOSS и делал те самые кубы и отчёты, по крайней мере для МТС
в тесте «System Analyst Middle» все вопросы про и для бизнес-аналитика, те основые темы 3 — бизнес-процессы, требования, процессы разработки, и ожидаемо нет ничего про БД, интеграции, архитектуру.
почему у БА такое внимание процессам разработки-взаимодействия уделяется — непонятно, он же не процессный инженер.
непонятна разница между тестами «System Analyst» и «System Analyst Middle».
сам тест очень спорный и конъюнктурный
также «Институт» и «Хабр.Карьера» пропустили слово «выберЕте»
по УТ там 2 вопроса из 20+, так что можно не указывать
сочетание «ребята из института» абсурдное стилистически. ребята бывают со двора.