Топ-10 вопросов по Системному анализу / Собеседование с разбором ответов и материалами

• Ирина рассказывает о своем опыте работы в компании Диасофт, где она была тестировщиком и занималась проверкой отчетов.  

• Затем она перешла в местную компанию-интегратора, где выполняла задачи проджекта, тестировщика, бизнес-аналитика и системного аналитика.  

• В этой компании она проработала три с половиной года, но решила уйти из-за того, что достигла потолка в развитии и хотела повысить свой уровень заработной платы.  

• Ирина работает в компании Магнит на позиции ведущего системного аналитика.  

• Она рассказывает о проекте, связанном с маркировкой рекламы и зерна, где она автоматизирует работу сотрудников и сокращает их время на обработку документов.  

• В команде семь человек, из них два аналитика, один тестировщик и остальные разработчики.  

• Ирина рассказывает о том, как она собирает и анализирует требования, проектирует систему и пишет функциональные и нефункциональные требования.  

• Она также упоминает о том, что использует шаблоны для документации и декомпозирует задачи с помощью инструмента Жире.  

• Ирина также рассказывает о формате документации, таком как юзер стори и юс кейсы, и приводит пример из текущего проекта.  

• В работе используются юс кейсы для описания процессов и взаимодействия пользователей и элементов системы.  

• В юс кейсах описываются предусловия, действующие лица, альтернативные сценарии и возможные ошибки.  

• Шаблон апи описывает, как бэк должен обрабатывать запросы фронта и возвращать ответы.  

• В шаблоне описываются ресурсы, методы, энд-пойнты, параметры, ограничения и маппинг с базой данных.  

• Бизнес-требования описывают цели и задачи на уровне бизнеса.  

• Пользовательские требования описывают цели и задачи пользователей.  

• Функциональные требования описывают функционал системы.  

• Нефункциональные требования описывают свойства системы, такие как безопасность, масштабируемость и удобство использования.  

• Интервьюирование, анкетирование, опросники, фокус-группы, индивидуальные интервью, тестирование интерфейсов, об-тесты, интерактивные игры, запросы в соцсетях и мессенджерах, об-тесты на выборке людей.  

• Верификация проверяет соответствие требованиям шаблону.  

• Валидация проверяет соответствие бизнес-концепту.  

• Бипмн нотация используется для моделирования бизнес-процессов.  

• Элементы нотации включают пулы, дорожки, события, таски, линии, шлюзы и операторы.  

• Диаграмма юмель: показывает взаимодействие между несколькими объектами последовательно по времени.  

• Диаграмма классов: показывает объекты и их связи.  

• Диаграмма активности: похожа на диаграмму юмель, но с другими элементами и возможностью показать время.  

• Монолит: один большое приложение, развертывается как единое приложение, использует одну базу данных.  

• Микросервисы: приложение делится на маленькие микросервисы, которые изолированы друг от друга и слабо связаны.  

• Сервис-ориентированная архитектура: сервисы крупнее, чем микросервисы, и ориентированы на повторное использование.  

• Декомпозиция микросервисов: выделение микросервисов на основе бизнес-контекста.  

• Паттерн управления данными: секьюрс, сага, опи-композиция и венсорсинг.  

• Паттерн коммуникации с внешними сервисами: опигейт вэй и бфф.  

• Рест - архитектурный шаблон проектирования взаимодействия между системами, основанный на определенных правилах.  

• Обязательные правила: клиент-серверная архитектура, отсутствие хранения состояния клиента на сервере, слоистая архитектура, кэширование, единообразие интерфейсов, возможность запуска кода, возвращенного сервером.  

• Методы: гет, пост, пут, пат, лейт, хэт.  

• Импотентные методы: гет, пут, хэт.  

• Коды ответов: сотые информационные, двухсотые успешные, трехсотые коды перенаправления, четырехсотые клиентские ошибки, пятисотые серверные ошибки.  

• Версионирование нужно для обеспечения совместимости с разными версиями сервиса.  

• SAP - стандартизированный протокол для обмена сообщениями между сервисами.  

• Асинхронное взаимодействие возможно с помощью брокеров сообщений, реста, джерписи, веб-сокетов и графа куэль.  

• Веб-сокеты и джерписи используются для реализации асинхронного взаимодействия в режиме реального времени.  

• Брокеры используются для передачи данных между микросервисами, когда объем данных большой и нужно быстро их передать.  

• Брокеры могут быть пул и пуш, например, Kafka и Redis соответственно.  

• Сервисные шины данных (USB) используются для передачи данных между сервисами, где первый сервис передает данные брокеру, а USB преобразует данные в нужный формат для второго сервиса.  

• Идентификация - определение пользователя в системе.  

• Аутентификация - проверка данных пользователя, например, логина и пароля.  

• Авторизация - проверка права пользователя на доступ к ресурсу.  

• Методы аутентификации: логин-пароль, Single Sign-On (SSO) через соцсети, двухфакторная аутентификация через SMS или приложение.  

• Сертификаты используются для аутентификации при интеграции с сервисами, например, с зерном.  

• Скель-базы данных хранят данные в виде таблиц, имеют транзакционность и согласованность данных.  

• Ну и скульные базы данных могут хранить данные в любом формате, делятся на несколько видов: ключ-значение, документы, графы, колонночные.  

• Нормализация баз данных - процесс декомпозиции таблиц для избежания избыточности хранения данных.  

• Три нормальные формы: первая - все данные должны быть атомарными, вторая - не должно быть частичной зависимости от части первичного ключа, третья - не должно быть транзитивной зависимости от первичного ключа.  

• Реляционные базы данных имеют проблемы с масштабированием, поэтому для больших данных чаще используются базы, которые лучше масштабируются.  

• Репликация, позиционирование и шардирование - методы масштабирования баз данных.  

• Индексы - основной способ оптимизации запросов в базах данных.  

• Вьюхи - виртуальные объекты, созданные из реальных таблиц для оптимизации запросов.  

• Задача: вывести информацию о поставщиках и категориях по продуктам, у которых цена выше средней.  

• Решение: использование функций агрегации, джойнов и условий для вывода нужной информации.  

• Продукт: финтех, выдача займов.  

• Пользователи: все группы населения, желающие взять деньги.  

• Стадия реализации: готовый продукт, в запуске.  

• Команды: мобилки, фронтенд, бэк, аналитики, дизайнеры.  

• Артефакты: документация в гите, описание спецификации, опишка, диаграмма последовательности, план юмс.  

• Работа с базами данных: постоянно на бэке, но не обязательно для аналитика.  

• Аналитик на время испытательного срока выполняет задачи, поставленные тимлитом.  

• Метрики работы аналитика: скорость решения задач и количество задач, которые возвращаются на доработку.  

• Успешное прохождение испытательного срока зависит от выполнения поставленных задач и отсутствия большого количества задач на доработку.  

• В среднем в команде два-три аналитика, два-три кьюэра, пять-шесть разработчиков и тимлит.  

• Встречи с тимлитом проводятся ежедневно, а ретро и дема - каждые две недели.  

• Возможен график работы с девяти до шести или с восьми до пяти, с плавающим началом рабочего дня.  

• Внутри компании есть комьюнити аналитиков, где они делятся опытом и знаниями.  

• Вопросы по графику лучше задавать рекрутеру в начале общения, чтобы избежать сюрпризов.  

• Вопросы о процессе работы, перфоманс-ревью, интервью и софт-скилах также актуальны.