Если говорить про аналитику бизнес-данных, то это действительно задача бизнес-аналитика. Особенно, если данные обрабатываются и собираются в доступные представления. Но если говорить про написание выборки данных и работу с исходными таблицами в базе, то это такие задачи практически всегда решают системные аналитики.
Безусловно, можно данную задачу решать иначе, СА подготовит выгрузки для представлений, доступных бизнесу, а уже бизнес на своей стороне будет анализировать данные. Но если говорить про выборки данных по исходным таблицам, то это задача системного аналитика, а также разработчика в некоторых случаях.
Спасибо за замечания. Я согласна, что есть кейсы, когда указанные вами моменты действительно стоит учесть и скорректировать процесс. Я строила диаграмму на основе той системы, с которой работаю, и в нашем случае данных проблем нет. Перелив данных в целевую систему не редкость и имеет свои плюсы. Мне было важно описать построение диаграммы. Действительно нужно отметить, что сам процесс не стоит брать за основу, так как это всё зависит от имеющейся архитектуры, целей и задач.
Спасибо за комментарий, к сожалению, я не знакома с MBSE, изучу подробно данную методологию.
В тезисе я имела в виду кейс, когда диаграммы не дополняются описанием. Немногие виды требований можно формализовать диаграммой. Особенно, если речь идет об использовании UML. Это может привести к проблемам, упомянутым в статье.
Я не сказала, что данные атрибуты нельзя добавить. В комментарии я указала, что атрибуты не являются обязательными.
Я имела в виду, что диаграммы на PlantUML имеют некоторые различия, и могут показаться некорректными на первый взгляд, если ранее не было опыта работы с данным инструментом. Возможно это и произошло у предыдущего комментатора)
Диаграммы в статье построены на PlantUML, внешний вид может отличаться от использования иных инструментов. Если смотреть официальную документацию по PlantUML, то диаграммы ей соответствуют.
Есть некоторые отличия построения диаграмм с использованием PlantUML. Но стрелки в примере не отличаются. Синхронность/асинхронность различается окончанием стрелки, здесь явно использован закрашенный вариант, что означает синхронность.
Активации на линии жизни и наименования диаграмм не являются обязательными атрибутами.
Так как управление требованиями включает в себя документирование, анализ, отслеживание, то матрица - инструмент управления. Я не называю матрицу процессом, она является средством, которое используется в нём.
Ключевой посыл любого требования - это нахера. Нахера оно надо заказчику? а продукту? А команде?
Не соглашусь. Требования, грубо говоря, описывают ожидаемые конечный результат. Формат пользовательских историй, например, содержит обоснование необходимости. Эту информацию можно включить в требования. Но требования не являются обоснованием необходимости, это не главная их задача. Ответы на перечисленные вопросы скорее содержатся в бизнес-цели, бизнес-задаче, описании доработки или назначении.
И как следствие, у вас спутана роль - эта штука про QA и тестирование требований, а не про анализ. От анализа здесь ничего нет, это другой контекст, к сожалению.
Я описала в статье кейсы, где матрица используется не только для анализа взаимосвязей тестов и требований. Матрицу также можно использовать для отслеживания связей различных видов требования и не только. Инструмент действительно в основном используется для задач QA, но его также можно использовать и в других задачах.
По определению управление требованиями подразумевает несколько иное значение, чем управление станцией метро:
Управление требованиями к программному обеспечению (англ. software requirements management) – процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритизацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц
Управление в данном контексте включает в себя документирование, анализ и отслеживание. Матрица трассировки требований используется для решение данных задач, что делает её инструментом, который используется в управлении требованиями.
Соглашусь, что матрица является способом визуализации связей. Но все же это контекст управления требованиями.
Да, это действительно отличная возможность, которую я не упомянула. Только нужно учитывать, что диаграмма в PlantUML (её исходник) получается достаточно непростой, нежели в Structurizr
Спасибо вам за подробную обратную связь! Вы правы, что интеллект карты подходят не для всех требований, это безусловно нужно учитывать в работе, ваш пример это также иллюстрирует.
В XMind, как и в других инструментах, действительно много возможностей. Я рассмотрела только базовое построение карты, но если необходимо, в каждом инструменте также можно применить дополнительные настройки.
Системный подход это отлично. Думаю, что формально, прямые обязанности сотрудника всегда определены. Вопрос в том, можно ли найти зону роста, не выходя за них.
Если изучить теорию, то поставка целей именно у системного аналитика, сравнивая даже с другими ролями в команде, имеет явные отличия и специфику. Конечно, если сказать, что цель аналитика – написание требований, что на самом деле не является корректной целью вовсе, то и правда все будет казаться очевидным. Если что-то из базовых понятий кажется элементарным и даже ненужным, то скорее всего отсутствует владение данными понятиями.
Подскажите, на какую профессию может заменить системного аналитика в данном контексте?
Если говорить, например, про смежные роли в команде, то безусловно данные пункты будут актуальны для всех начинающих специалистов в разных ролях.
Но для разработчика, например, я бы начала не с этого, а с основ по навыкам. Для бизнес-аналитика также данный список нужно сформировать и приоритизировать иначе. Именно для системного аналитика наиболее важно понимать изначально сам процесс разработки и задачи смежных ролей.
Скажу на своем опыте, теорию очень полезно изучать. Кроме того, что она может понадобиться в собеседованиях, она способствует корректному подходу к решению задач. Знание основ, понимание того, как «правильно» решать задачи поможет избежать ошибок и найти новые (более эффективные) подходы к решению. Кроме этого, это поможет вам вырасти как специалисту, глубоко погруженному в профильную предметную область.
Если говорить про аналитику бизнес-данных, то это действительно задача бизнес-аналитика. Особенно, если данные обрабатываются и собираются в доступные представления. Но если говорить про написание выборки данных и работу с исходными таблицами в базе, то это такие задачи практически всегда решают системные аналитики.
Безусловно, можно данную задачу решать иначе, СА подготовит выгрузки для представлений, доступных бизнесу, а уже бизнес на своей стороне будет анализировать данные. Но если говорить про выборки данных по исходным таблицам, то это задача системного аналитика, а также разработчика в некоторых случаях.
Спасибо за замечания. Я согласна, что есть кейсы, когда указанные вами моменты действительно стоит учесть и скорректировать процесс. Я строила диаграмму на основе той системы, с которой работаю, и в нашем случае данных проблем нет. Перелив данных в целевую систему не редкость и имеет свои плюсы. Мне было важно описать построение диаграммы. Действительно нужно отметить, что сам процесс не стоит брать за основу, так как это всё зависит от имеющейся архитектуры, целей и задач.
Согласно документации, рекомендуется использовать
-->для синхронного возврата в PlantUML, так как это соответствует стандартной нотацииСпасибо за комментарий, к сожалению, я не знакома с MBSE, изучу подробно данную методологию.
В тезисе я имела в виду кейс, когда диаграммы не дополняются описанием. Немногие виды требований можно формализовать диаграммой. Особенно, если речь идет об использовании UML. Это может привести к проблемам, упомянутым в статье.
Я не сказала, что данные атрибуты нельзя добавить. В комментарии я указала, что атрибуты не являются обязательными.
Я имела в виду, что диаграммы на PlantUML имеют некоторые различия, и могут показаться некорректными на первый взгляд, если ранее не было опыта работы с данным инструментом. Возможно это и произошло у предыдущего комментатора)
Диаграммы в статье построены на PlantUML, внешний вид может отличаться от использования иных инструментов. Если смотреть официальную документацию по PlantUML, то диаграммы ей соответствуют.
Есть некоторые отличия построения диаграмм с использованием PlantUML. Но стрелки в примере не отличаются. Синхронность/асинхронность различается окончанием стрелки, здесь явно использован закрашенный вариант, что означает синхронность.
Активации на линии жизни и наименования диаграмм не являются обязательными атрибутами.
Спасибо большое!
Спасибо, буду иметь в виду!
Да, в статье Модель C4 в Structurizr: шаблоны для системного аналитика подробно разобрала построение диаграмм Context, Containers и Components
Так как управление требованиями включает в себя документирование, анализ, отслеживание, то матрица - инструмент управления. Я не называю матрицу процессом, она является средством, которое используется в нём.
Не соглашусь. Требования, грубо говоря, описывают ожидаемые конечный результат. Формат пользовательских историй, например, содержит обоснование необходимости. Эту информацию можно включить в требования. Но требования не являются обоснованием необходимости, это не главная их задача. Ответы на перечисленные вопросы скорее содержатся в бизнес-цели, бизнес-задаче, описании доработки или назначении.
Я описала в статье кейсы, где матрица используется не только для анализа взаимосвязей тестов и требований. Матрицу также можно использовать для отслеживания связей различных видов требования и не только. Инструмент действительно в основном используется для задач QA, но его также можно использовать и в других задачах.
По определению управление требованиями подразумевает несколько иное значение, чем управление станцией метро:
Управление в данном контексте включает в себя документирование, анализ и отслеживание. Матрица трассировки требований используется для решение данных задач, что делает её инструментом, который используется в управлении требованиями.
Соглашусь, что матрица является способом визуализации связей. Но все же это контекст управления требованиями.
Спасибо вам за подробное объяснение, не знала таких подробностей, очень интересно!
Да, это действительно отличная возможность, которую я не упомянула. Только нужно учитывать, что диаграмма в PlantUML (её исходник) получается достаточно непростой, нежели в Structurizr
Спасибо вам за подробную обратную связь! Вы правы, что интеллект карты подходят не для всех требований, это безусловно нужно учитывать в работе, ваш пример это также иллюстрирует.
В XMind, как и в других инструментах, действительно много возможностей. Я рассмотрела только базовое построение карты, но если необходимо, в каждом инструменте также можно применить дополнительные настройки.
Спасибо за отличную рекомендацию!
Системный подход это отлично. Думаю, что формально, прямые обязанности сотрудника всегда определены. Вопрос в том, можно ли найти зону роста, не выходя за них.
Думаю, что про p-shaped я даже не слышала. Терминология растет быстрее, чем ее практическое применение)
Если изучить теорию, то поставка целей именно у системного аналитика, сравнивая даже с другими ролями в команде, имеет явные отличия и специфику. Конечно, если сказать, что цель аналитика – написание требований, что на самом деле не является корректной целью вовсе, то и правда все будет казаться очевидным. Если что-то из базовых понятий кажется элементарным и даже ненужным, то скорее всего отсутствует владение данными понятиями.
Подскажите, на какую профессию может заменить системного аналитика в данном контексте?
Если говорить, например, про смежные роли в команде, то безусловно данные пункты будут актуальны для всех начинающих специалистов в разных ролях.
Но для разработчика, например, я бы начала не с этого, а с основ по навыкам. Для бизнес-аналитика также данный список нужно сформировать и приоритизировать иначе. Именно для системного аналитика наиболее важно понимать изначально сам процесс разработки и задачи смежных ролей.
Скажу на своем опыте, теорию очень полезно изучать. Кроме того, что она может понадобиться в собеседованиях, она способствует корректному подходу к решению задач. Знание основ, понимание того, как «правильно» решать задачи поможет избежать ошибок и найти новые (более эффективные) подходы к решению. Кроме этого, это поможет вам вырасти как специалисту, глубоко погруженному в профильную предметную область.