conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts.
вот у меня другое понимание, что ER-модели прежде всего моделируют мир в автоматизируемой части.
да, с целью последующего создания хранилища этой модели, но моделируют они мир, а не хранилище как таковое, по крайней мере, на концептуальном уровне модели:
Nevertheless, the central goal of IDEF1 and LDDT was the same: to produce a database-neutral model of the persistent information needed by an enterprise by modeling the real-world entities involved.
так может признать, что вам там нужны не аналитики, а специалисты по автоматизации банковских процессов? и проектировщики информационных систем? а анализ окружения (бизнес там, система, не важно) — это просто важная, но не важнейшая часть работы? мы же не называем поваров «нарезчиками» или «варщиками» просто потому, что этой работы у них много
а то наши ребята обчитаются английских словосочетаний типа «Business Systems Analyst» и думают, что это какой-то гибрид БА и СА. а это не гибрид, а специалист по развитию информационных систем определённого класса, а именно — корпоративных информационных систем. т.к. слово Business здесь — прилагательное к Systems
а то ведь как начнёшь залезать в настоящий бизнес-анализ и выясняется, что «БА в ИТ» не только плохо понимает про бизнес этой конкретной компании, так ещё и не может экономически обосновать, зачем нужны те или иные функции в системе. т.е. это исследователи кусков компании и хотелок людей, а не аналитики бизнеса.
Это ко всем стандартам относится, но не считаю, что это плохо.
ну смотрите, за последние несколько лет от СА стали ожидать знаний и умений в темах:
архитектура интеграций
интеграция через REST API
интеграция через брокеры
микросервисная архитектура
Это те вещи, которым нужно обучать и практиковать на работе. Где о них говорить? Явно не в профстандарте. Он тут нам для подготовки конкретных учебных программ и развития компетенций в этих практиках никак не поможет.
современная разработка по Scrum и Kanban вообще не имеет формы проекта, поэтому вся эта риторика про менеджера и проект непонятно как ложится на современную практику
«элементы проекта» тут — это видимо участки работ. а мы в посте видим обсуждение практик проектирования устройства предмета проектирования — информационной системы. поэтому тоже непонятно, что с этим делать. либо тут опять всплыла путаница между design и project
Для разработки ПО, термин профессия можно вообще не использовать (пока), а исходить именно из трудовых функций, проще будет
Вы видимо не понимаете, чем Екатерина и я, например, занимаемся.
Мы развиваем культуру проектирования информационных систем через обучение конкретным практикам.
Мы закрываем запросы рынка в лице компаний и частных лиц.
Людям до сих пор удобнее рассуждать профессиями, компаниям удобнее оперировать должностными позициями, поэтому нам приходится работать в этой лексике и онтологии.
Желание хорошее)) Но вопрос, перечень компетенций для Кого?
Словосочетание «системный аналитик» в России и для большей части вакансий мира сейчас узурпировано профессией «аналитик-проектировщик информационных систем». В мире в официальных источниках чаще встречается фраза «computer systems analyst».
>> Это переводчик текста из бизнес-требований в ТЗ (ПМИ) на автоматизацию.
Минуя проектирование? Понятие ТЗ предполагает, что мы уже знаем, что именно хотим получить. А для этого объект надо спроектировать. Хотя бы концептуально.
в профстандарте в силу его инерционности и общности нет возможности отражать конкретные современные технологии и практики, востребованные рынком
например, первая версия профстандарта создавалась с условиях, когда ещё не было понятно, что СА в КИС вырождаются в проектировщиков интеграций (а сейчас это так) и это надо учитывать и что-то с этим делать
поэтому Екатерина полностью права в своём желании создать актуальный перечень компетенций, который нужен сейчас
считаем исходя из системной холархии. должен исходя из сути деятельности, что для сборки объекта уровня X нужно знать свойства уровня X-1 как минимум. но это только для сборки. для проектирования нужно знать на уровень глубже, т.к. в ходе проектирования может возникать запрос на новую разработку компонентов уже этого уровня
вы какую-то ерунду вычитываете всё время и фантазируете — обидно, ехидно, какие-то судороги, передёргивания, попукивания
я как инженер САПР знаю на 2 уровня ниже САПР - как разрабатывается софт - как работают сети и компьютер
в деталях работы конкретных процессоров и сетевых устройств прям текущего года необходимости разбираться очевидно нет, потому что эти знания просто не нужны (в частности, я специализируюсь скорее на САПР ИС и бизнес-приложений, чем 3D и проч)
также я знаю на 2 уровня ниже, как работает механика, физика и химия, но для работы инженером АС типа САПР это уже не критично
если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
если вам нужен инженер по проектированию высокопроизводительных систем, то ему возможно нужно и в деталях работы процессоров и сетевых устройств текущего года разбираться, зависит от класса системы
просто если не нужны именно инженеры, а достаточно техников по эксплуатации, то нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожидания
Я думаю индустрия сама себя загнала в эти условия, переименовав сисадминов в DevOps-инженеров.
У сисадмина не было обязательности инженерного образования.
Если в 70% случаев от специалиста нужна квалификация ремесленника, техника, как это например обстоит с разработчиками, а не инженера, то это совершенно нормальная ситуация.
Если брать аналогию с традиционной инженерией, то можно считать, что организация конвейера разработки ПО — это частный случай построения АСУТП.
Так вот человек, который строит такой конвейер в большой компании видимо должен иметь квалификацию именно инженера.
А человеку, который такой конвейер поддерживает, сопровождает, достаточно квалификации техника.
conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts.
https://en.wikipedia.org/wiki/Conceptual_model_(computer_science)
вот у меня другое понимание, что ER-модели прежде всего моделируют мир в автоматизируемой части.
да, с целью последующего создания хранилища этой модели, но моделируют они мир, а не хранилище как таковое, по крайней мере, на концептуальном уровне модели:
что такое UX-кейс? юскейс? на слух статью писали? )
на втором шаге в картинке у вас «интеграция» вместо «итерации»
так может признать, что вам там нужны не аналитики, а специалисты по автоматизации банковских процессов? и проектировщики информационных систем? а анализ окружения (бизнес там, система, не важно) — это просто важная, но не важнейшая часть работы? мы же не называем поваров «нарезчиками» или «варщиками» просто потому, что этой работы у них много
а то наши ребята обчитаются английских словосочетаний типа «Business Systems Analyst» и думают, что это какой-то гибрид БА и СА. а это не гибрид, а специалист по развитию информационных систем определённого класса, а именно — корпоративных информационных систем. т.к. слово Business здесь — прилагательное к Systems
а то ведь как начнёшь залезать в настоящий бизнес-анализ и выясняется, что «БА в ИТ» не только плохо понимает про бизнес этой конкретной компании, так ещё и не может экономически обосновать, зачем нужны те или иные функции в системе. т.е. это исследователи кусков компании и хотелок людей, а не аналитики бизнеса.
чушь и бред, смотрите DDD
ну смотрите, за последние несколько лет от СА стали ожидать знаний и умений в темах:
архитектура интеграций
интеграция через REST API
интеграция через брокеры
микросервисная архитектура
Это те вещи, которым нужно обучать и практиковать на работе. Где о них говорить? Явно не в профстандарте. Он тут нам для подготовки конкретных учебных программ и развития компетенций в этих практиках никак не поможет.
современная разработка по Scrum и Kanban вообще не имеет формы проекта, поэтому вся эта риторика про менеджера и проект непонятно как ложится на современную практику
«элементы проекта» тут — это видимо участки работ. а мы в посте видим обсуждение практик проектирования устройства предмета проектирования — информационной системы. поэтому тоже непонятно, что с этим делать. либо тут опять всплыла путаница между design и project
Вы видимо не понимаете, чем Екатерина и я, например, занимаемся.
Мы развиваем культуру проектирования информационных систем через обучение конкретным практикам.
Мы закрываем запросы рынка в лице компаний и частных лиц.
Людям до сих пор удобнее рассуждать профессиями, компаниям удобнее оперировать должностными позициями, поэтому нам приходится работать в этой лексике и онтологии.
Словосочетание «системный аналитик» в России и для большей части вакансий мира сейчас узурпировано профессией «аналитик-проектировщик информационных систем». В мире в официальных источниках чаще встречается фраза «computer systems analyst».
>> Это переводчик текста из бизнес-требований в ТЗ (ПМИ) на автоматизацию.
Минуя проектирование? Понятие ТЗ предполагает, что мы уже знаем, что именно хотим получить. А для этого объект надо спроектировать. Хотя бы концептуально.
Там есть Архитекторы ПО https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=57023
А системные архитекторы звучит как более общая профессия, выходящая за рамки ИТ.
Поэтому видимо Минсвязи решил на неё не покушаться, хотя с аналитиком прокатило)
в профстандарте в силу его инерционности и общности нет возможности отражать конкретные современные технологии и практики, востребованные рынком
например, первая версия профстандарта создавалась с условиях, когда ещё не было понятно, что СА в КИС вырождаются в проектировщиков интеграций (а сейчас это так) и это надо учитывать и что-то с этим делать
поэтому Екатерина полностью права в своём желании создать актуальный перечень компетенций, который нужен сейчас
Тут опять пошла китайская классификация собак имени Владимира Ильича Вигерса.
Бизнес-требования тоже функциональные и нефункциональные.
Просто одни требования к бизнесу, а другие — к системе.
интересно, как ты себе представляешь «Верхнеуровневое проектирование архитектуры»
что именно нужно уметь делать? чем оперировать, какими практиками, знаниями, подходами?
Навык — это умение, доведённое до автоматизма. Система 1 по Канеману, а не 2. У тебя тут в основном умения
мне не обидно, я даже по специальности не работаю
считаем исходя из системной холархии. должен исходя из сути деятельности, что для сборки объекта уровня X нужно знать свойства уровня X-1 как минимум. но это только для сборки. для проектирования нужно знать на уровень глубже, т.к. в ходе проектирования может возникать запрос на новую разработку компонентов уже этого уровня
вы какую-то ерунду вычитываете всё время и фантазируете — обидно, ехидно, какие-то судороги, передёргивания, попукивания
так что и вам
я как инженер САПР знаю на 2 уровня ниже САПР
- как разрабатывается софт
- как работают сети и компьютер
в деталях работы конкретных процессоров и сетевых устройств прям текущего года необходимости разбираться очевидно нет, потому что эти знания просто не нужны (в частности, я специализируюсь скорее на САПР ИС и бизнес-приложений, чем 3D и проч)
также я знаю на 2 уровня ниже, как работает механика, физика и химия, но для работы инженером АС типа САПР это уже не критично
если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
если вам нужен инженер по проектированию высокопроизводительных систем, то ему возможно нужно и в деталях работы процессоров и сетевых устройств текущего года разбираться, зависит от класса системы
просто если не нужны именно инженеры, а достаточно техников по эксплуатации, то нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожидания
только кажется в момент появления абстракций их пользователи перестали быть инженерами
как водитель грузовика не является инженером-механиком или инженером-электриком
Я думаю индустрия сама себя загнала в эти условия, переименовав сисадминов в DevOps-инженеров.
У сисадмина не было обязательности инженерного образования.
Если в 70% случаев от специалиста нужна квалификация ремесленника, техника, как это например обстоит с разработчиками, а не инженера, то это совершенно нормальная ситуация.
Если брать аналогию с традиционной инженерией, то можно считать, что организация конвейера разработки ПО — это частный случай построения АСУТП.
Так вот человек, который строит такой конвейер в большой компании видимо должен иметь квалификацию именно инженера.
А человеку, который такой конвейер поддерживает, сопровождает, достаточно квалификации техника.