Отличие системного аналитика от бизнес-аналитика
В двух словах: БА - больше шарит в бизнесе и бизнес-требованиях, СА - больше в технологиях и системных требованиях
1. Бизнес-аналитик - связующее звено между бизнесом и разработчиками. Погружается в предметную область, выясняет, чего хочет бизнес, передаёт эти требования разработчикам и добивается результата. Нужны коммуникативные способности и аналитический ум. БА настроен на коммуникацию с бизнесом, его задача — определить боль, найти и предложить решение проблемы с помощью ИТ.
2. Системный аналитик - погружён в ИТ, техническую часть. Ему требуется больше практических технических навыков, он ближе к группе технических специалистов и должен лучше понимать их язык.
Сложившаяся ситуация требует от ИТ аналитиков (1) глубокого знания предметной области, особенностей внутренних процессов, внешней среды и трендов, (2) не менее глубоких знаний технологий, практического использования.
В профессии БА действительно вникать в тонкости архитектуры и разработки не надо. БА должен подробно выявить все сценарии работы с системой. А вот СА как раз эти сценарии подробно детализирует и опишет все нюансы на техническом уровне. Получается «сильный СА» может написать настолько подробные требования (после груминга с командой), что разработчику их нужно будет только реализовать.
Хороший БА кропотливо выявляет все сценарии и подробности использования системы, а хороший СА может писать сильно детализированные требования разработчикам. И там и там нужна кропотливость и детально вникать в работу в зоне своей ответственности.
В двух словах: БА - больше шарит в бизнесе и бизнес-требованиях, СА - больше в технологиях и системных требованиях
1. Бизнес-аналитик - связующее звено между бизнесом и разработчиками. Погружается в предметную область, выясняет, чего хочет бизнес, передаёт эти требования разработчикам и добивается результата. Нужны коммуникативные способности и аналитический ум. БА настроен на коммуникацию с бизнесом, его задача — определить боль, найти и предложить решение проблемы с помощью ИТ.
2. Системный аналитик - погружён в ИТ, техническую часть. Ему требуется больше практических технических навыков, он ближе к группе технических специалистов и должен лучше понимать их язык.
Сложившаяся ситуация требует от ИТ аналитиков (1) глубокого знания предметной области, особенностей внутренних процессов, внешней среды и трендов, (2) не менее глубоких знаний технологий, практического использования.
В профессии БА действительно вникать в тонкости архитектуры и разработки не надо. БА должен подробно выявить все сценарии работы с системой. А вот СА как раз эти сценарии подробно детализирует и опишет все нюансы на техническом уровне. Получается «сильный СА» может написать настолько подробные требования (после груминга с командой), что разработчику их нужно будет только реализовать.
Хороший БА кропотливо выявляет все сценарии и подробности использования системы, а хороший СА может писать сильно детализированные требования разработчикам. И там и там нужна кропотливость и детально вникать в работу в зоне своей ответственности.
👍16❤5🔥1🤔1
Абстрактный пример:
Иван — БА компании «Исполнитель».
Ева — системный аналитик компании «Исполнитель».
Компании «Заказчик» нужна крупная доработка имеющейся системы.
В этой ситуации задачи Ивана (БА): выявить функциональные и нефункциональные требования Заказчика и Исполнителя, устранить противоречия между заинтересованными лицами для определения приемлемого решения, создать прототипы, взаимодействовать с заказчиком процессе разработки, осуществить демо-показ и приемку работы. Делать все это сообща с Евой.
Задачи Евы (СА): спроектировать доработку оптимальным образом, описать ее влияние на систему, ограничения и возможные улучшения, создать спецификацию, декомпозировать и передать в разработку задачи, проконтролировать их своевременное выполнение в соответствии с требованиями. Делать все это сообща с Иваном.
Иван — БА компании «Исполнитель».
Ева — системный аналитик компании «Исполнитель».
Компании «Заказчик» нужна крупная доработка имеющейся системы.
В этой ситуации задачи Ивана (БА): выявить функциональные и нефункциональные требования Заказчика и Исполнителя, устранить противоречия между заинтересованными лицами для определения приемлемого решения, создать прототипы, взаимодействовать с заказчиком процессе разработки, осуществить демо-показ и приемку работы. Делать все это сообща с Евой.
Задачи Евы (СА): спроектировать доработку оптимальным образом, описать ее влияние на систему, ограничения и возможные улучшения, создать спецификацию, декомпозировать и передать в разработку задачи, проконтролировать их своевременное выполнение в соответствии с требованиями. Делать все это сообща с Иваном.
👍9❤1
Литература аналитика
1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности.
Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер
Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
5. «Как писать хорошо» Уильям Зинсер
Автор рассказывает, как писать просто, понятно, чисто и интересно. Автор объясняет, как обращаться к читателю, как выбирать тему, как сформировать канву повествования. В книге даются плохие и хорошие примеры, как избавляться от словесного мусора. Автор объясняет, почему простота текста важна.
6. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
В оригинале название книги звучит как "User Story Mapping". Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
Stay tuned.
1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности.
Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер
Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
5. «Как писать хорошо» Уильям Зинсер
Автор рассказывает, как писать просто, понятно, чисто и интересно. Автор объясняет, как обращаться к читателю, как выбирать тему, как сформировать канву повествования. В книге даются плохие и хорошие примеры, как избавляться от словесного мусора. Автор объясняет, почему простота текста важна.
6. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
В оригинале название книги звучит как "User Story Mapping". Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
Stay tuned.
❤10🤔1
Порядок сбора требований:
1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.
1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.
👍6❤2🤔1
🔥 Подборка материалов от телеграм-канала Системный Аналитик
Ссылки отображаются только при переходе в Telegram
📚 20 лучших книг для развития аналитика — можно скачать бесплатно
📨 Брокеры сообщений: Kafka и RabbitMQ
🏭 PlantUML с нуля
📌 Подброка бесплатных материалов базам данных и SQL
▶️ Подборка бесплатных вебинаров по основам интеграции систем
📎 Подборка материалов по изучению REST
🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
🌐 HTTP. Что нужно знать аналитику
⚙️ Интеграция через API. Кратко
🤓 Задачник для системных аналитиков от Тинькофф
🧿 Виртуализация, контейнеризация и оркестрация
💪 Карта навыков системного аналитика
🧮 Про нефункциональные требования
🆚 REST vs SOAP. Сравнение по пунктам
Ссылки отображаются только при переходе в Telegram
📚 20 лучших книг для развития аналитика — можно скачать бесплатно
📨 Брокеры сообщений: Kafka и RabbitMQ
🏭 PlantUML с нуля
📌 Подброка бесплатных материалов базам данных и SQL
▶️ Подборка бесплатных вебинаров по основам интеграции систем
📎 Подборка материалов по изучению REST
🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
🌐 HTTP. Что нужно знать аналитику
⚙️ Интеграция через API. Кратко
🤓 Задачник для системных аналитиков от Тинькофф
🧿 Виртуализация, контейнеризация и оркестрация
💪 Карта навыков системного аналитика
🧮 Про нефункциональные требования
🆚 REST vs SOAP. Сравнение по пунктам
❤5👍1🤔1
Брокеры сообщений
Брокер сообщений (очередь сообщений) – это отдельный сервис, который отвечает за хранение и доставку данных от сервисов-отправителей к сервисам-получателям с помощью модели Pub/Sub.
Эта модель предполагает, что асинхронное взаимодействие осуществляется согласно следующей логике двух ролей:
1. Publishers публикуют новую информацию в виде сгруппированных по некоторому атрибуту сообщений;
2. Subscribers подписываются на потоки сообщений с определенными атрибутами и обрабатывают их.
Большинство брокеров предоставляют гарантии “at least once” и “at most once”.
At most once исключает повторную обработку сообщений, однако допускает их потерю. В этом случае брокер будет доставлять сообщения получателям по принципу “отправил и забыл”. Если получатель не смог по какой-то причине обработать сообщение с первой попытки, брокер не будет осуществлять переотправку.
At least once, напротив, гарантирует получение сообщения получателем, однако при этом есть вероятность повторной обработки одних и тех же сообщений.
Зачастую эта гарантия достигается с помощью механизма Ack/Nack (acknowledgement/negative acknowledgement), который предписывает совершать переотправку сообщения, если получатель по какой-то причине не смог его обработать.
Таким образом, для каждого отправленного брокером (но еще не обработанного) сообщения существует три итоговых состояния — получатель вернул Ack (успешная обработка), вернул Nack (неуспешная обработка) или разорвал соединение. Последние два сценария приводят в переотправке сообщения и повторной обработке.
Однако брокер может произвести повторную отправку и при успешной обработке сообщения получателем. Например, если получатель обработал сообщение, но завершил свою работу, не отправив сигнал Ack брокеру.
В этом случае брокер снова положит сообщение в очередь, после чего оно будет обработано повторно, что может привести к ошибкам и порче данных, если разработчик не предусмотрел механизм устранения дублей на стороне получателя.
#архитектура
Брокер сообщений (очередь сообщений) – это отдельный сервис, который отвечает за хранение и доставку данных от сервисов-отправителей к сервисам-получателям с помощью модели Pub/Sub.
Эта модель предполагает, что асинхронное взаимодействие осуществляется согласно следующей логике двух ролей:
1. Publishers публикуют новую информацию в виде сгруппированных по некоторому атрибуту сообщений;
2. Subscribers подписываются на потоки сообщений с определенными атрибутами и обрабатывают их.
Большинство брокеров предоставляют гарантии “at least once” и “at most once”.
At most once исключает повторную обработку сообщений, однако допускает их потерю. В этом случае брокер будет доставлять сообщения получателям по принципу “отправил и забыл”. Если получатель не смог по какой-то причине обработать сообщение с первой попытки, брокер не будет осуществлять переотправку.
At least once, напротив, гарантирует получение сообщения получателем, однако при этом есть вероятность повторной обработки одних и тех же сообщений.
Зачастую эта гарантия достигается с помощью механизма Ack/Nack (acknowledgement/negative acknowledgement), который предписывает совершать переотправку сообщения, если получатель по какой-то причине не смог его обработать.
Таким образом, для каждого отправленного брокером (но еще не обработанного) сообщения существует три итоговых состояния — получатель вернул Ack (успешная обработка), вернул Nack (неуспешная обработка) или разорвал соединение. Последние два сценария приводят в переотправке сообщения и повторной обработке.
Однако брокер может произвести повторную отправку и при успешной обработке сообщения получателем. Например, если получатель обработал сообщение, но завершил свою работу, не отправив сигнал Ack брокеру.
В этом случае брокер снова положит сообщение в очередь, после чего оно будет обработано повторно, что может привести к ошибкам и порче данных, если разработчик не предусмотрел механизм устранения дублей на стороне получателя.
#архитектура
🤔2👍1🔥1
Партиция - последовательность сообщений, раздел топика, а топик - это очередь.
В Кафке процесса доставки как такового нет: каждый читатель сам ответственен за вытягивание (pull) сообщений из партиций, которые он читает.
Каждый получатель закреплен за определенной партицией (или за несколькими партициями) в интересующем его топике, и при появлении нового сообщения получает сигнал на вычитывание следующего элемента в commit log, при этом отмечая, какое последнее сообщение он прочитал. Таким образом при переподключении он будет знать, какое сообщение ему вычитать следующим.
Базовое правило масштабирования Кафки — количество конкурентных читателей (то бишь группа сервисов, реализующих одинаковую логику обработки (реплик)) топика не должно превышать количество партиций в этом топике, иначе какая-то пара читателей будут обрабатывать одинаковый набор данных.
В Кафке процесса доставки как такового нет: каждый читатель сам ответственен за вытягивание (pull) сообщений из партиций, которые он читает.
Каждый получатель закреплен за определенной партицией (или за несколькими партициями) в интересующем его топике, и при появлении нового сообщения получает сигнал на вычитывание следующего элемента в commit log, при этом отмечая, какое последнее сообщение он прочитал. Таким образом при переподключении он будет знать, какое сообщение ему вычитать следующим.
Базовое правило масштабирования Кафки — количество конкурентных читателей (то бишь группа сервисов, реализующих одинаковую логику обработки (реплик)) топика не должно превышать количество партиций в этом топике, иначе какая-то пара читателей будут обрабатывать одинаковый набор данных.
👍2🤔2