Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA
#вопросыссобеседования
Часть 2:
📍Вопрос 1: Что такое UML-моделирование?
✅Краткий ответ: UML (Unified Modeling Language - унифицированный язык моделирования). Это графический язык, который с помощью диаграмм и схем описывает разнообразные процессы и структуры. Данный язык в основном используется для разработки программного обеспечения. Однако он также используется для описания рабочих ролей, организационных функций и бизнес-процессов.
Типы UML-диаграмм:
Структурные диагараммы:
- Диаграмма развертывания
- Диаграмма пакетов
- Диаграмма профилей
- Диаграмма классов
- Диаграмма объектов
- Диаграмма компонентов
- Диаграмма композитивной структуры
Диаграммы поведения:
- Диаграмма деятелньости
- Диаграмма вариантов использования
- Диаграмма состояний
- Диаграмма взаимодействий
- Диаграмма последовательности
- Диаграмма коммуникации
- Диаграмма обзора взаимодействия
- Диаграмма синхронизации
📎Материалы по теме:
- UML
- UML для бизнес-моделирования: зачем нужны диаграммы процессов
📍Вопрос 2: Что такое BPMN? Назовите основные элементы BPMN?
✅Краткий ответ: BPMN (Business Process Modeling Notation - Нотация моделирования бизнес-процессов) — это метод, используемый для иллюстрации/описания бизнес-процессов, другими словами BPMN - это графическое представление бизнес-процессов. Данный метод наглядно отображает подробную последовательность бизнес-операций и информационных потоков, необходимых для завершения процесса.
Можно сказать, что BPMN является частью двух важнейших составляющих:
- Business Process Management (BPM) — управление бизнес-процессами, или процессное управление. Иными словами, BPM - это концепция управления организацией, представляющая деятельность предприятия как совокупность процессов.
- Business Process Modeling System (BPMS) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Camunda, ELMA и пр.
В нотации BPMN выделяют пять основных категорий элементов:
- элементы потока (события, процессы и шлюзы);
- данные/date (объекты данных и базы данных);
- соединяющие элементы (потоки управления, потоки сообщений и ассоциации);
- зоны ответственности (пулы и дорожки);
- Artefact (артефакты/сноски).
📎Материалы по теме:
- Нотация BPMN
- Краткое описание BPMN с примером
Источник: @ba_and_sa
#собеседование
Часть 1 - https://t.me/ba_and_sa/885
p.s.Делитесь своими мыслями в комментариях
#вопросыссобеседования
Часть 2:
📍Вопрос 1: Что такое UML-моделирование?
✅Краткий ответ: UML (Unified Modeling Language - унифицированный язык моделирования). Это графический язык, который с помощью диаграмм и схем описывает разнообразные процессы и структуры. Данный язык в основном используется для разработки программного обеспечения. Однако он также используется для описания рабочих ролей, организационных функций и бизнес-процессов.
Типы UML-диаграмм:
Структурные диагараммы:
- Диаграмма развертывания
- Диаграмма пакетов
- Диаграмма профилей
- Диаграмма классов
- Диаграмма объектов
- Диаграмма компонентов
- Диаграмма композитивной структуры
Диаграммы поведения:
- Диаграмма деятелньости
- Диаграмма вариантов использования
- Диаграмма состояний
- Диаграмма взаимодействий
- Диаграмма последовательности
- Диаграмма коммуникации
- Диаграмма обзора взаимодействия
- Диаграмма синхронизации
📎Материалы по теме:
- UML
- UML для бизнес-моделирования: зачем нужны диаграммы процессов
📍Вопрос 2: Что такое BPMN? Назовите основные элементы BPMN?
✅Краткий ответ: BPMN (Business Process Modeling Notation - Нотация моделирования бизнес-процессов) — это метод, используемый для иллюстрации/описания бизнес-процессов, другими словами BPMN - это графическое представление бизнес-процессов. Данный метод наглядно отображает подробную последовательность бизнес-операций и информационных потоков, необходимых для завершения процесса.
Можно сказать, что BPMN является частью двух важнейших составляющих:
- Business Process Management (BPM) — управление бизнес-процессами, или процессное управление. Иными словами, BPM - это концепция управления организацией, представляющая деятельность предприятия как совокупность процессов.
- Business Process Modeling System (BPMS) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Camunda, ELMA и пр.
В нотации BPMN выделяют пять основных категорий элементов:
- элементы потока (события, процессы и шлюзы);
- данные/date (объекты данных и базы данных);
- соединяющие элементы (потоки управления, потоки сообщений и ассоциации);
- зоны ответственности (пулы и дорожки);
- Artefact (артефакты/сноски).
📎Материалы по теме:
- Нотация BPMN
- Краткое описание BPMN с примером
Источник: @ba_and_sa
#собеседование
Часть 1 - https://t.me/ba_and_sa/885
p.s.Делитесь своими мыслями в комментариях
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему о требованиях:
#вопросыссобеседования
Часть 3:
📍Вопрос 1: Что такое требование, какие бывают типы требований?
✅Краткий ответ: Требование — описывает, что нужно сделать для достижения определенных бизнес-целей. Это входные данные для различных этапов жизненного цикла программного обеспечения (SDLC). Требования — это основа проекта, которые перед реализацией должны быть утверждены заинтересованными сторонами и бизнес-пользователями
Типы/уровни требований:
- Бизнес-требования (business requirements) - высокоуровневая бизнес-цель организации или заказчиков системы
- Пользовательские требования (user requirements) - описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то.
- Функциональные требования (functional requirements) - это особенности продукта или функции, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи, иными словами это описание требуемого поведения системы в определенных условиях.
Отдельно выделяют Нефункциональные требования (non-functional requirements) - описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
📎Материалы по теме:
- Выявление и сбор требований к ПО
📍Вопрос 2: Какими свойствами обладают хорошие требования?
✅ Краткий ответ: Хорошие требования должны удовлетворять нескольким критериям:
- Завершенность (требование должно быть описано для всех возможных условий)
- Атомарность (требование нельзя разбить на более детальные требования)
- Недвусмысленность (означает, что существует только один вариант интерпретации требования)
- Проверяемость/Тестируемость (означает, что тестеры должны иметь возможность проверить, было ли требование реализовано корректно)
- Полнота (требование должно быть описано подробно и понятно для реализации)
- Корректность (если требование содержит факты, эти факты должны быть достоверны)
- Понятность (требования должны быть грамматически правильные, написаны в соответствующем стиле)
- Независимость (чтобы понять требование, не нужно знать какое-либо другое требование)
- Абстрактность (требования не должны содержать ненужной информации о дизайне и реализации системы)
- Необходимость (требование должно быть необходимым для работы системы, в требовании нет необходимости, если оно не нужно ни одному заинтересованному лицу, и удаление требования не повлияет на работу системы)
- Однозначность (требование должно быть написано понятным языком для всех, т.е. все, кто работает с требованиями, должны интерпретировать их одинаково)
….
📎Материалы по теме:
- Требования к системе: характеристики хороших требований
- характеристики качества требований
📍Вопрос 3: Какие существуют методы сбора требований?
✅ Краткий ответ:
- Интервью
- Анкетирование/опрос
- Фокус-группа
- Семинар
- Мозговой штурм
- Совещание
- Моделирование процессов
- Прототипирование
- Анализ вариантов использования
- Анализ интерфейсов
- Анализ действующей документации
…
📎Материалы по теме:
- Метод сбора требований - Event Storming
- Техники сбора требований к разработке ПО
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
◾️Часть 1 - Что такое приоритизация требований и какие бывают методы расстановки приоритетов? Что такое SRS и какие бывают ключевые элементы? Что такое BRD и в чем разница между SRS?
◾️Часть 2 - Что такое UML моделирование? Что такое BPMN и его основные элементы?
p.s.Делитесь своими мыслями в комментариях
#вопросыссобеседования
Часть 3:
📍Вопрос 1: Что такое требование, какие бывают типы требований?
✅Краткий ответ: Требование — описывает, что нужно сделать для достижения определенных бизнес-целей. Это входные данные для различных этапов жизненного цикла программного обеспечения (SDLC). Требования — это основа проекта, которые перед реализацией должны быть утверждены заинтересованными сторонами и бизнес-пользователями
Типы/уровни требований:
- Бизнес-требования (business requirements) - высокоуровневая бизнес-цель организации или заказчиков системы
- Пользовательские требования (user requirements) - описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то.
- Функциональные требования (functional requirements) - это особенности продукта или функции, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи, иными словами это описание требуемого поведения системы в определенных условиях.
Отдельно выделяют Нефункциональные требования (non-functional requirements) - описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
📎Материалы по теме:
- Выявление и сбор требований к ПО
📍Вопрос 2: Какими свойствами обладают хорошие требования?
✅ Краткий ответ: Хорошие требования должны удовлетворять нескольким критериям:
- Завершенность (требование должно быть описано для всех возможных условий)
- Атомарность (требование нельзя разбить на более детальные требования)
- Недвусмысленность (означает, что существует только один вариант интерпретации требования)
- Проверяемость/Тестируемость (означает, что тестеры должны иметь возможность проверить, было ли требование реализовано корректно)
- Полнота (требование должно быть описано подробно и понятно для реализации)
- Корректность (если требование содержит факты, эти факты должны быть достоверны)
- Понятность (требования должны быть грамматически правильные, написаны в соответствующем стиле)
- Независимость (чтобы понять требование, не нужно знать какое-либо другое требование)
- Абстрактность (требования не должны содержать ненужной информации о дизайне и реализации системы)
- Необходимость (требование должно быть необходимым для работы системы, в требовании нет необходимости, если оно не нужно ни одному заинтересованному лицу, и удаление требования не повлияет на работу системы)
- Однозначность (требование должно быть написано понятным языком для всех, т.е. все, кто работает с требованиями, должны интерпретировать их одинаково)
….
📎Материалы по теме:
- Требования к системе: характеристики хороших требований
- характеристики качества требований
📍Вопрос 3: Какие существуют методы сбора требований?
✅ Краткий ответ:
- Интервью
- Анкетирование/опрос
- Фокус-группа
- Семинар
- Мозговой штурм
- Совещание
- Моделирование процессов
- Прототипирование
- Анализ вариантов использования
- Анализ интерфейсов
- Анализ действующей документации
…
📎Материалы по теме:
- Метод сбора требований - Event Storming
- Техники сбора требований к разработке ПО
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
◾️Часть 1 - Что такое приоритизация требований и какие бывают методы расстановки приоритетов? Что такое SRS и какие бывают ключевые элементы? Что такое BRD и в чем разница между SRS?
◾️Часть 2 - Что такое UML моделирование? Что такое BPMN и его основные элементы?
p.s.Делитесь своими мыслями в комментариях
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему о методологиях управления проектами:
#вопросыссобеседования
Часть 4:
📍Вопрос 1: Что такое методология управления проектами и какие они бывают?
✅Краткий ответ:
Методология управления проектами — это стандарт ведения проектов от старта до завершения, который включает в себя принципы работы (способы оценки сроков, постановки задач и передача их между сотрудниками, сбор требований, способы согласований и тд)
Наиболее распрастраненные методологии управления проектами:
- Waterfall (Водопадная модель)
- Agile (Гибкая модель)
- SCRUM
- Kanban
- Lean и тд.
- Гибридна модель (Waterfall+Agile)
- PRiSM
- PRINCE2
Методы управления проектами:
- Critical part method / Метод критического пути
- Critical chain project management / Метод критической цепи
- и др.
*Этапы управления проектом:
- Инициация
- Планирование
- Выполнение/Разработка
- Мониторинг/Тестирование
- Завершение
📎Материалы по теме:
- Методологии управления проектами: водопад, эджайл
- Методологии управления проектами: 12 популярных подходов
📍Вопрос 2: Что такое Waterfall (водопадная модель)?
✅ Краткий ответ:
Водопадная или каскадная модель разработки программного обеспечения (waterfall, водопад) - это модель процесса разработки ПО, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Водопадная модель подразумевает, что переход от одной фазы создания продукта к другой происходит только после полного завершения предыдущей фазы и что переходов назад и перекрытия фаз не происходит.
📎Материалы по теме:
- Как устроена каскадная модель управления проектами
- WATERFALL МЕТОДОЛОГИЯ РАЗРАБОТКИ
📍Вопрос 3: Что такое Agile (Гибкая модель)?
✅ Краткий ответ:
Методология Agile - это гибкий подход к разработке программного обеспечения, который помогает командам быстрее и с меньшими проблемами поставлять ценность клиентам. Вместо того чтобы выпускать весь продукт целиком, команда, следующая принципам Agile, выполняет работу в рамках небольших, но удобных инкрементов. Требования, планы и результаты оцениваются непрерывно, благодаря чему команды могут быстро реагировать на изменения.
Процесс работы по Agile делится на итерации — короткие циклы по две-три недели. Каждый цикл решает серию задач.
📎Материалы по теме:
- Методология управления проектами - Agile
- Agile от А до Я
Понять в чем разница между Agile и Waterfall поможет статья - Agile vs. Waterfall: суть и отличия методологий разработки
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
- Часть 1
- Часть 2
- Часть 3
p.s.Делитесь своими мыслями в комментариях
#вопросыссобеседования
Часть 4:
📍Вопрос 1: Что такое методология управления проектами и какие они бывают?
✅Краткий ответ:
Методология управления проектами — это стандарт ведения проектов от старта до завершения, который включает в себя принципы работы (способы оценки сроков, постановки задач и передача их между сотрудниками, сбор требований, способы согласований и тд)
Наиболее распрастраненные методологии управления проектами:
- Waterfall (Водопадная модель)
- Agile (Гибкая модель)
- SCRUM
- Kanban
- Lean и тд.
- Гибридна модель (Waterfall+Agile)
- PRiSM
- PRINCE2
Методы управления проектами:
- Critical part method / Метод критического пути
- Critical chain project management / Метод критической цепи
- и др.
*Этапы управления проектом:
- Инициация
- Планирование
- Выполнение/Разработка
- Мониторинг/Тестирование
- Завершение
📎Материалы по теме:
- Методологии управления проектами: водопад, эджайл
- Методологии управления проектами: 12 популярных подходов
📍Вопрос 2: Что такое Waterfall (водопадная модель)?
✅ Краткий ответ:
Водопадная или каскадная модель разработки программного обеспечения (waterfall, водопад) - это модель процесса разработки ПО, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Водопадная модель подразумевает, что переход от одной фазы создания продукта к другой происходит только после полного завершения предыдущей фазы и что переходов назад и перекрытия фаз не происходит.
📎Материалы по теме:
- Как устроена каскадная модель управления проектами
- WATERFALL МЕТОДОЛОГИЯ РАЗРАБОТКИ
📍Вопрос 3: Что такое Agile (Гибкая модель)?
✅ Краткий ответ:
Методология Agile - это гибкий подход к разработке программного обеспечения, который помогает командам быстрее и с меньшими проблемами поставлять ценность клиентам. Вместо того чтобы выпускать весь продукт целиком, команда, следующая принципам Agile, выполняет работу в рамках небольших, но удобных инкрементов. Требования, планы и результаты оцениваются непрерывно, благодаря чему команды могут быстро реагировать на изменения.
Процесс работы по Agile делится на итерации — короткие циклы по две-три недели. Каждый цикл решает серию задач.
📎Материалы по теме:
- Методология управления проектами - Agile
- Agile от А до Я
Понять в чем разница между Agile и Waterfall поможет статья - Agile vs. Waterfall: суть и отличия методологий разработки
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
- Часть 1
- Часть 2
- Часть 3
p.s.Делитесь своими мыслями в комментариях
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему об API:
#вопросыссобеседования
Часть 5:
📍Вопрос 1: Что такое API?
✅Краткий ответ:
API (Application Programming Interface — программный интерфейс приложения, или интерфейс программирования приложений) - это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными
Главная цель использования API – связывание компонентов одного приложения с другим. Т.е. если API перестанет работать, то отключатся и все связанные с ним сервисы, инструменты, программы
Наиболее распрастраненные виды или типы API:
- RPC (Remote Procedure Call ) – удаленный вызов процедур
- SOAP (Simple Object Access Protocol) – простой протокол доступа к объектам
- REST (Representational State Transfer ) – передача состояния представления (архитектурный стиль)
- GraphQL - маршрутизатор API-запросов внутри больших ИС и сложных связок сервисов
📎Материалы по теме:
- Что такое API и как он работает
- Что такое API (простыми словами) с примерами использования
📍Вопрос 2: Что такое SOAP?
✅ Краткий ответ:
SOAP (Simple Object Access Protocol) — простой протокол доступа к объектам. Т.е. способ взаимодействия Вашей информационной системы через web с другими информационными системами.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
📎Материалы по теме:
- SOAP API
- Применение SOAP при интеграции систем
📍Вопрос 3: Что такое REST?
✅ Краткий ответ:
REST (Representational State Transfer) — это архитектурный стиль взаимодействия компонентов распределённого приложения в сети.
Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.
Принципы REST:
- Клиент-серверная архитектура
- Stateless
- Кэширование
- Единообразие интерфейса
- Layered system
- Code on demand
📎Материалы по теме:
- REST API
- REST, что же ты такое?
📍Вопрос 4: В чем разница между SOAP и REST?
✅ Краткий ответ:
Главное различие между REST и SOAP, это то, что REST — это архитектурный стиль. SOAP — это формат обмена сообщениями.
Специфика SOAP - это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий: Envelope (конверт), Header (заголовок), Body (тело), Fault
Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.
📎Материалы по теме:
- REST vs SOAP
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
- Часть 1
- Часть 2
- Часть 3
- Часть 4
p.s.Делитесь своими мыслями в комментариях
#вопросыссобеседования
Часть 5:
📍Вопрос 1: Что такое API?
✅Краткий ответ:
API (Application Programming Interface — программный интерфейс приложения, или интерфейс программирования приложений) - это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными
Главная цель использования API – связывание компонентов одного приложения с другим. Т.е. если API перестанет работать, то отключатся и все связанные с ним сервисы, инструменты, программы
Наиболее распрастраненные виды или типы API:
- RPC (Remote Procedure Call ) – удаленный вызов процедур
- SOAP (Simple Object Access Protocol) – простой протокол доступа к объектам
- REST (Representational State Transfer ) – передача состояния представления (архитектурный стиль)
- GraphQL - маршрутизатор API-запросов внутри больших ИС и сложных связок сервисов
📎Материалы по теме:
- Что такое API и как он работает
- Что такое API (простыми словами) с примерами использования
📍Вопрос 2: Что такое SOAP?
✅ Краткий ответ:
SOAP (Simple Object Access Protocol) — простой протокол доступа к объектам. Т.е. способ взаимодействия Вашей информационной системы через web с другими информационными системами.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
📎Материалы по теме:
- SOAP API
- Применение SOAP при интеграции систем
📍Вопрос 3: Что такое REST?
✅ Краткий ответ:
REST (Representational State Transfer) — это архитектурный стиль взаимодействия компонентов распределённого приложения в сети.
Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.
Принципы REST:
- Клиент-серверная архитектура
- Stateless
- Кэширование
- Единообразие интерфейса
- Layered system
- Code on demand
📎Материалы по теме:
- REST API
- REST, что же ты такое?
📍Вопрос 4: В чем разница между SOAP и REST?
✅ Краткий ответ:
Главное различие между REST и SOAP, это то, что REST — это архитектурный стиль. SOAP — это формат обмена сообщениями.
Специфика SOAP - это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий: Envelope (конверт), Header (заголовок), Body (тело), Fault
Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.
📎Материалы по теме:
- REST vs SOAP
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
- Часть 1
- Часть 2
- Часть 3
- Часть 4
p.s.Делитесь своими мыслями в комментариях
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему про работу с базами данных:
#вопросыссобеседования
Часть 6:
📍Вопрос 1: Что такое БД и какие они бывают?
✅Краткий ответ:
База данных (БД) - это стандартный программный сервис для упорядоченного хранения данных.
Основные типы БД:
- Реляционные - это набор данных с предопределенными связями между ними. Эти данные организованны в виде набора таблиц, состоящих из столбцов и строк.
- Сетевые - В отличие от реляционных баз, в сетевых между таблицами и записями, может быть несколько разных связей, каждая из который отвечает за что-то своё
- Иерархические - это сложная многокомпонентная система, в основе которой лежит древовидная структура. Она состоит из комплекса объектов разных уровней (рангов), расположенных по принципу их подчинения от общего к частному.
Также есть и другие типы БД: Объектные или объектно-ориентированные, функциональные.
📎Материалы по теме:
- Базы данных: что это такое, и какие они бывают
- Виды баз данных
- 11 типов современных баз данных: краткие описания, схемы и примеры БД
📍Вопрос 2: Что такое ER-модель (Entity-relationship model)? Для чего нужно разрабатывать ER-модель?
✅ Краткий ответ:
ER-модель или ER-диаграмма (Entity-relationship model или Entity-relationship diagram) – это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных.
Грубо говоря ER-модель – это представление базы данных в виде наглядных графических диаграмм.
В ER-моделях и моделях данных обычно выделяют до трех уровней детализации:
- Концептуальная модель данных - схема наивысшего уровня с минимальным количеством подробностей
- Логическая модель данных - содержит более подробную информацию, нежели концептуальная модель
- Физическая модель данных - на основе каждой логической модели данных можно составить одну или две физических модели
Отвечая на вопрос для чего вообще разрабатывать ER-модель можно сказать, что с ее помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
📎Материалы по теме:
- Понятие ER-модели. Понятие сущности (entity). Атрибуты. Виды атрибутов
📍Вопрос 3: В чем разница между реляционными (SQL) и нереляционными базами данных (NoSQL)?
✅ Краткий ответ:
Реляционные БД - база, где данные хранятся в формате таблиц, они строго структурированы и связаны друг с другом.
Основные СУБД реляционных БД:
• SQL: MySQL, Oracle, PostgreSQL, Microsoft SQL Server;
Нереляционная база данных (NoSQL) — хранит данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях.
Основные СУБД нереляционных БД
• NoSQL: MongoDB, Redis, RavenDB Cassandra, BigTable, HBase, Neo4j, CouchDB.
Также можно сказать, что в современном мире нет противостояния между реляционными и нереляционными БД, а лучше говорить об их совместном использовании для решения поставленных задач , на которых та или иная технология показывает себя лучше всего, для чего необходима интеграция данных технологий друг в друга.
📎Материалы по теме:
- Сравнение SQL и NoSQL: как выбрать систему хранения данных
- Базы данных SQL и NoSQL: основные различия
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
- Часть 1 - Часть 4
- Часть 2 - Часть 5
- Часть 3
В следующий раз разберем более подробно тему SQL, так как на собеседованиях очень часто гоняют по данной теме))
p.s.Делитесь своими мыслями в комментариях
#вопросыссобеседования
Часть 6:
📍Вопрос 1: Что такое БД и какие они бывают?
✅Краткий ответ:
База данных (БД) - это стандартный программный сервис для упорядоченного хранения данных.
Основные типы БД:
- Реляционные - это набор данных с предопределенными связями между ними. Эти данные организованны в виде набора таблиц, состоящих из столбцов и строк.
- Сетевые - В отличие от реляционных баз, в сетевых между таблицами и записями, может быть несколько разных связей, каждая из который отвечает за что-то своё
- Иерархические - это сложная многокомпонентная система, в основе которой лежит древовидная структура. Она состоит из комплекса объектов разных уровней (рангов), расположенных по принципу их подчинения от общего к частному.
Также есть и другие типы БД: Объектные или объектно-ориентированные, функциональные.
📎Материалы по теме:
- Базы данных: что это такое, и какие они бывают
- Виды баз данных
- 11 типов современных баз данных: краткие описания, схемы и примеры БД
📍Вопрос 2: Что такое ER-модель (Entity-relationship model)? Для чего нужно разрабатывать ER-модель?
✅ Краткий ответ:
ER-модель или ER-диаграмма (Entity-relationship model или Entity-relationship diagram) – это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных.
Грубо говоря ER-модель – это представление базы данных в виде наглядных графических диаграмм.
В ER-моделях и моделях данных обычно выделяют до трех уровней детализации:
- Концептуальная модель данных - схема наивысшего уровня с минимальным количеством подробностей
- Логическая модель данных - содержит более подробную информацию, нежели концептуальная модель
- Физическая модель данных - на основе каждой логической модели данных можно составить одну или две физических модели
Отвечая на вопрос для чего вообще разрабатывать ER-модель можно сказать, что с ее помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
📎Материалы по теме:
- Понятие ER-модели. Понятие сущности (entity). Атрибуты. Виды атрибутов
📍Вопрос 3: В чем разница между реляционными (SQL) и нереляционными базами данных (NoSQL)?
✅ Краткий ответ:
Реляционные БД - база, где данные хранятся в формате таблиц, они строго структурированы и связаны друг с другом.
Основные СУБД реляционных БД:
• SQL: MySQL, Oracle, PostgreSQL, Microsoft SQL Server;
Нереляционная база данных (NoSQL) — хранит данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях.
Основные СУБД нереляционных БД
• NoSQL: MongoDB, Redis, RavenDB Cassandra, BigTable, HBase, Neo4j, CouchDB.
Также можно сказать, что в современном мире нет противостояния между реляционными и нереляционными БД, а лучше говорить об их совместном использовании для решения поставленных задач , на которых та или иная технология показывает себя лучше всего, для чего необходима интеграция данных технологий друг в друга.
📎Материалы по теме:
- Сравнение SQL и NoSQL: как выбрать систему хранения данных
- Базы данных SQL и NoSQL: основные различия
Источник: @ba_and_sa
#собеседование
‼️Раннее рассмотренные вопросы:
- Часть 1 - Часть 4
- Часть 2 - Часть 5
- Часть 3
В следующий раз разберем более подробно тему SQL, так как на собеседованиях очень часто гоняют по данной теме))
p.s.Делитесь своими мыслями в комментариях
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и продолжим тему про работу с базами данных и поговорим именно об SQL:
#вопросыссобеседования
Часть 7:
Данную тему очень часто затрагивают на собеседованиях и спрашивают как теорию, так и просят что-либо показать на практике, поэтому нашла пару статей👇🏼, где уже отмечены вопросы с ответами по теме sql:
📌 27 распространённых вопросов по SQL с собеседований и ответы на них
📌 Топ-30 вопросов по SQL на технических собеседованиях:
- Часть 1
- Часть 2
📌 20 вопросов и задач по SQL на собеседовании с ответами
📌 50 популярных вопросов и ответов на собеседовании по SQL Server
Также исходя из опыта и прочитав разные статьи выделю несколько вопросов, которые практически всегда задают на собеседовании:
📍Вопрос 1: Какие есть операторы SQL
✅Краткий ответ:
DDL (Data Definition Language, язык описания данных) - это группа операторов определения данных, в нее входят такие операторы как:
- CREATE
- ALTER
- DROP
DML (Data Manipulation Language, язык управления данными) - это группа операторов для манипуляции данными, в нее входят такие операторы как:
- SELECT
- INSERT
- UPDATE
- DELETE
DCL (Data Control Language, язык контролирования данных) - группа операторов определения доступа к данным, в нее входят такие операторы как:
- GRANT
- REVOKE
- DENY
TCL (Transaction Control Language, язык управления транзакциями) - группа операторов для управления транзакциями, в которую входят такие операторы как:
- BEGIN TRANSACTION
- COMMIT TRANSACTION
- ROLLBACK TRANSACTION
- SAVE TRANSACTION
📎Материалы по теме:
- Основные команды SQL, которые должен знать каждый программист
📍Вопрос 2: Какие есть типы соединения в SQL
✅ Краткий ответ:
Для соединения двух таблиц используют оператор JOIN. Соединение может быть внутренним (INNER), внешним (OUTER), которое в свою очередь может быть левым (LEFT), правым (RIGHT) и полным (FULL).
Рассмотрим чуть подробней каждое из них:
- INNER JOIN - объединяет записи из двух таблиц по связующему полю, если оно содержит одинаковые значения в обеих таблицах
- FULL OUTER JOIN - возвращает все записи, для которых есть совпадение в любой из таблиц. Следовательно, он возвращает все строки из левой таблицы и все строки из правой таблицы
- LEFT JOIN - используется для возврата всех строк из левой (первой) таблицы и только совпадающих строк из правой (второй) таблицы, для которых выполняется условие соединения
- RIGHT JOIN - используется для возврата всех строк из правой (второй) таблицы и только совпадающих строк из левой (первой) таблицы, для которых выполняется условие соединения
📎Материалы по теме:
- Соединение таблиц – операция JOIN и ее виды
- SQL JOIN - соединение таблиц базы данных
📍Вопрос 3: Что такое SQL-ограничения (Constraints) и какие они бывают?
✅ Краткий ответ:
Ограничения (constraints) используются для указания ограничения на тип данных таблицы. Они могут быть указаны при создании или изменении таблицы
Примеры ограничений:
- NOT NULL - значение не может быть NULL
- CHECK - значения столбца должны соответствовать заданным условиям
- DEFAULT - предоставляет столбцу значения по умолчанию
- UNIQUE - гарантирует уникальность значений в столбце
- INDEX — создаёт индексы в таблице для быстрого поиска/запросов
- PRIMARY KEY - требует, чтобы каждая запись в данном столбце была уникальной и не равнялась NULL
- FOREIGN KEY - требует, чтобы каждая запись в данном столбце уже существовала в определенном столбце из другой таблицы
📎Материалы по теме:
- SQL Создание ограничений
- Основы работы с ограничениями SQL
Источник: @ba_and_sa
#собеседование
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
p.s.Делитесь своими мыслями в комментариях и напишите, какие вопросы были у вас на собесах
#вопросыссобеседования
Часть 7:
Данную тему очень часто затрагивают на собеседованиях и спрашивают как теорию, так и просят что-либо показать на практике, поэтому нашла пару статей👇🏼, где уже отмечены вопросы с ответами по теме sql:
📌 27 распространённых вопросов по SQL с собеседований и ответы на них
📌 Топ-30 вопросов по SQL на технических собеседованиях:
- Часть 1
- Часть 2
📌 20 вопросов и задач по SQL на собеседовании с ответами
📌 50 популярных вопросов и ответов на собеседовании по SQL Server
Также исходя из опыта и прочитав разные статьи выделю несколько вопросов, которые практически всегда задают на собеседовании:
📍Вопрос 1: Какие есть операторы SQL
✅Краткий ответ:
DDL (Data Definition Language, язык описания данных) - это группа операторов определения данных, в нее входят такие операторы как:
- CREATE
- ALTER
- DROP
DML (Data Manipulation Language, язык управления данными) - это группа операторов для манипуляции данными, в нее входят такие операторы как:
- SELECT
- INSERT
- UPDATE
- DELETE
DCL (Data Control Language, язык контролирования данных) - группа операторов определения доступа к данным, в нее входят такие операторы как:
- GRANT
- REVOKE
- DENY
TCL (Transaction Control Language, язык управления транзакциями) - группа операторов для управления транзакциями, в которую входят такие операторы как:
- BEGIN TRANSACTION
- COMMIT TRANSACTION
- ROLLBACK TRANSACTION
- SAVE TRANSACTION
📎Материалы по теме:
- Основные команды SQL, которые должен знать каждый программист
📍Вопрос 2: Какие есть типы соединения в SQL
✅ Краткий ответ:
Для соединения двух таблиц используют оператор JOIN. Соединение может быть внутренним (INNER), внешним (OUTER), которое в свою очередь может быть левым (LEFT), правым (RIGHT) и полным (FULL).
Рассмотрим чуть подробней каждое из них:
- INNER JOIN - объединяет записи из двух таблиц по связующему полю, если оно содержит одинаковые значения в обеих таблицах
- FULL OUTER JOIN - возвращает все записи, для которых есть совпадение в любой из таблиц. Следовательно, он возвращает все строки из левой таблицы и все строки из правой таблицы
- LEFT JOIN - используется для возврата всех строк из левой (первой) таблицы и только совпадающих строк из правой (второй) таблицы, для которых выполняется условие соединения
- RIGHT JOIN - используется для возврата всех строк из правой (второй) таблицы и только совпадающих строк из левой (первой) таблицы, для которых выполняется условие соединения
📎Материалы по теме:
- Соединение таблиц – операция JOIN и ее виды
- SQL JOIN - соединение таблиц базы данных
📍Вопрос 3: Что такое SQL-ограничения (Constraints) и какие они бывают?
✅ Краткий ответ:
Ограничения (constraints) используются для указания ограничения на тип данных таблицы. Они могут быть указаны при создании или изменении таблицы
Примеры ограничений:
- NOT NULL - значение не может быть NULL
- CHECK - значения столбца должны соответствовать заданным условиям
- DEFAULT - предоставляет столбцу значения по умолчанию
- UNIQUE - гарантирует уникальность значений в столбце
- INDEX — создаёт индексы в таблице для быстрого поиска/запросов
- PRIMARY KEY - требует, чтобы каждая запись в данном столбце была уникальной и не равнялась NULL
- FOREIGN KEY - требует, чтобы каждая запись в данном столбце уже существовала в определенном столбце из другой таблицы
📎Материалы по теме:
- SQL Создание ограничений
- Основы работы с ограничениями SQL
Источник: @ba_and_sa
#собеседование
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
p.s.Делитесь своими мыслями в комментариях и напишите, какие вопросы были у вас на собесах
Алоха, друзья! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему архитектуры:
#вопросыссобеседования
Часть 8:
📍Вопрос 1: Что такое архитектура программного обеспечения (ПО)?
✅Краткий ответ:
Архитектура программного обеспечения (ПО) - это структура и организация системы, которая определяет ее компоненты, взаимодействия между ними и их отношения с внешней средой. Также можно сказать, что Архитектура представляет собой основу для дальнейшей разработки ПО, определяет его функциональность, надежность, масштабируемость, производительность и возможности расширения.
Важной частью архитектуры ПО является выбор технологий для ее реализации. Существует множество различных технологий, включая языки программирования, базы данных, фреймворки и библиотеки. Выбор технологий должен основываться на конкретных требованиях приложения, его цели и ограничениях.
Более подробно расскажу в следующий раз))
📎Материалы по теме:
- Разработка архитектуры для чайников. Часть 1 / Часть 2
- Архитектура ПО: разница между архитектурой и проктированием
📍Вопрос 2: Что такое микросервисная, монолитная и клиент-сервисная архитектура? В чем разница между ними?
✅Краткий ответ:
Микросервисная архитектура - это подход, в котором приложение разделено на множество небольших сервисов, каждый из которых отвечает за определенную функцию. Она обеспечивает гибкость, относительную независимость компонентов и масштабируемость. Однако, такая архитектура может потребовать дополнительных усилий в сопровождении и управлении сервисами.
Монолитная архитектура - это крупнопланировочная структура с единым кодом, который включает в себя все компоненты приложения. Она обеспечивает простоту в разработке и тестировании, но часто имеет проблемы масштабирования и зависимости между компонентами.
Клиент-серверная архитектура - это модель, в которой клиенты на своих устройствах используют удаленный сервер для обмена информацией. Она обеспечивает хорошую масштабируемость и безопасность, но может иметь проблемы с производительностью из-за удаленного доступа.
Клиент-серверная и микросервисная архитектуры часто являются лучшим выбором для крупных проектов, которые требуют масштабируемости и гибкости. Монолитная архитектура хорошо подходит для небольших проектов или простых систем.
📎Материалы по теме:
- Сравнение микросервисной и монолитной архитектур
- Микросервисы или монолит. Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса
- Клиент-серверная архитектура в картинках
📍Вопрос 3: Какие вы знаете виды и способы интеграции систем?
✅ Краткий ответ:
Существует несколько видов интеграций систем, в том числе:
1. Интеграция API (Application Programming Interface) - это способ связывания различных программных приложений через их программные интерфейсы.
2. Интеграция через файловые форматы - это способ интеграции, основанный на конвертировании файлов в разные форматы для обмена информацией между ПО.
3. Интеграция баз данных - это способ обмена информацией между различными базами данных на основе протоколов обмена.
4. Интеграция с помощью платформы - это способ связывания различных приложений через одну платформу.
Способ интеграции зависит от требований конкретного проекта, но важно выбрать наиболее подходящий вариант для эффективной работы приложения в целом.
📎Материалы по теме:
- Видео - Способы интеграции систем
Это лишь маленькая часть вопросов данной темы и вопросы для начинающих, которые задают, чтобы понять знает ли кандидат, что такое архитектура ПО, без углубления в тему.
Источник: @ba_and_sa
#собеседование
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
p.s.Делитесь своими мыслями в комментариях и напишите, какие вопросы были у вас на собесах
#вопросыссобеседования
Часть 8:
📍Вопрос 1: Что такое архитектура программного обеспечения (ПО)?
✅Краткий ответ:
Архитектура программного обеспечения (ПО) - это структура и организация системы, которая определяет ее компоненты, взаимодействия между ними и их отношения с внешней средой. Также можно сказать, что Архитектура представляет собой основу для дальнейшей разработки ПО, определяет его функциональность, надежность, масштабируемость, производительность и возможности расширения.
Важной частью архитектуры ПО является выбор технологий для ее реализации. Существует множество различных технологий, включая языки программирования, базы данных, фреймворки и библиотеки. Выбор технологий должен основываться на конкретных требованиях приложения, его цели и ограничениях.
Более подробно расскажу в следующий раз))
📎Материалы по теме:
- Разработка архитектуры для чайников. Часть 1 / Часть 2
- Архитектура ПО: разница между архитектурой и проктированием
📍Вопрос 2: Что такое микросервисная, монолитная и клиент-сервисная архитектура? В чем разница между ними?
✅Краткий ответ:
Микросервисная архитектура - это подход, в котором приложение разделено на множество небольших сервисов, каждый из которых отвечает за определенную функцию. Она обеспечивает гибкость, относительную независимость компонентов и масштабируемость. Однако, такая архитектура может потребовать дополнительных усилий в сопровождении и управлении сервисами.
Монолитная архитектура - это крупнопланировочная структура с единым кодом, который включает в себя все компоненты приложения. Она обеспечивает простоту в разработке и тестировании, но часто имеет проблемы масштабирования и зависимости между компонентами.
Клиент-серверная архитектура - это модель, в которой клиенты на своих устройствах используют удаленный сервер для обмена информацией. Она обеспечивает хорошую масштабируемость и безопасность, но может иметь проблемы с производительностью из-за удаленного доступа.
Клиент-серверная и микросервисная архитектуры часто являются лучшим выбором для крупных проектов, которые требуют масштабируемости и гибкости. Монолитная архитектура хорошо подходит для небольших проектов или простых систем.
📎Материалы по теме:
- Сравнение микросервисной и монолитной архитектур
- Микросервисы или монолит. Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса
- Клиент-серверная архитектура в картинках
📍Вопрос 3: Какие вы знаете виды и способы интеграции систем?
✅ Краткий ответ:
Существует несколько видов интеграций систем, в том числе:
1. Интеграция API (Application Programming Interface) - это способ связывания различных программных приложений через их программные интерфейсы.
2. Интеграция через файловые форматы - это способ интеграции, основанный на конвертировании файлов в разные форматы для обмена информацией между ПО.
3. Интеграция баз данных - это способ обмена информацией между различными базами данных на основе протоколов обмена.
4. Интеграция с помощью платформы - это способ связывания различных приложений через одну платформу.
Способ интеграции зависит от требований конкретного проекта, но важно выбрать наиболее подходящий вариант для эффективной работы приложения в целом.
📎Материалы по теме:
- Видео - Способы интеграции систем
Это лишь маленькая часть вопросов данной темы и вопросы для начинающих, которые задают, чтобы понять знает ли кандидат, что такое архитектура ПО, без углубления в тему.
Источник: @ba_and_sa
#собеседование
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
p.s.Делитесь своими мыслями в комментариях и напишите, какие вопросы были у вас на собесах
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему жизненного цикла разработки ПО:
#вопросыссобеседования
Часть 9:
📍Вопрос 1: Что такое жизненный цикл разработки ПО?
✅Краткий ответ:
Жизненный цикл программного обеспечения (ЖЦ ПО) описывает процесс разработки программного обемпечеия, включая все этапы от начала до конца.
Этапы разработки:
1. Определние потребностей заказчика (идея)
2. Сбор и анализ требований
3. Проектирование (документирование требований и дизайн)
4. Разработка ПО
5. Тестирование
6. Внедрение и поддержка продукта
Бизнес-аналитик участвует на каждом этапе ЖЦ ПО
📎Материалы по теме:
- Жизненный цикл программного обеспечения и какое место занимает Бизнес-аналитик в нем
- Что такое ЖЦ Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
- Жизненный цикл проекта и его фазы от инициации до завершения
📍Вопрос 2: Какие бывают модели/методологии жизненного цикла разработки ПО?
✅ Краткий ответ:
1️⃣ Водопадная/Каскадная модель - модель, в которой процесс разработки выглядит как поток, переходящий от одной стадии к другой в строгом порядке, без возможности пропуска стадии или возврата назад.
➕ Преимущесвта:
- Хорошо подходит проектам, где требования жестко фиксированы и не меняются
- стабильность требований в течение всего жизненного цикла ПО
- прозрачные и прогнозируемые сроки прохождения каждой фазы
- простой алгоритм реализации модели
➖ Недостатки:
- невозможность изменять и дополнять список требований на последующих этапах жизненного цикла
- дополнительные затраты на корректировку уже завершенных этапов
- отсутствие промежуточных результатов – продукт можно объективно оценить лишь после официального запуска
2️⃣ Итеративная модель - осуществление разработки с использованием одного цикла разработки, который последовательно повторяется до полного завершения проекта.
➕ Преимущесвта:
- организация эффективной обратной связи проектной команды с заказчиком
- более быстрое решение возникших проблем и ошибок, что ведет к минимизации затрат на устранение рисков
- быстрый выпуск MVP
➖ Недостатки:
- нет фиксированного бюджета и сроков, а также нужна сильная вовлеченность Заказчика в процесс
- при итерациях приходится отбрасывать часть сделанной ранее работы
3️⃣ Спиральная модель - повторяющаяся последовательность циклов разработки с непрерывным контролем рисков
➕ Преимущесвта:
- реализация связи с пользователем с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества
- хорошо подходит для проектов с высокой степенью риска
- минимизация рисков через многократные итерации
➖ Недостатки:
- высокая стоимость проектирования
- необходимость в высокопрофессиональных знаниях для оценки рисков
- необходимость в четком распределении работ между разработчиками
4️⃣ Гибкая модель
В данном подходе работа над проектом осуществляется через короткие итерации, называемые спринтами, в течение которых разработчики фокусируются на реализации наиболее значимых в данное время элементов проекта. На каждом этапе работы заказчик оценивает текущие результаты и может внести изменения в требования к продукту
➕ Преимущесвта:
- высокая скорость разработки продукта, что позволяет быстро адаптироваться к меняющимся условиям рынка;
- привлечение заказчика к разработке, что повышает прозрачность и контролируемость проекта;
- улучшение коммуникации в команде, что ускоряет процесс разработки и повышает качество продукта.
➖ Недостатки:
- не дает гарантий на долгосрочные планы
- нет жесткой структуры и даже методов для всех проектов
- отсутствие четкого плана, очень “поверхностное” описание требований к системе
- необходимо иметь большой уровень знаний и опыта команды
Есть и другие модели ЖЦ ПО
📎Материалы по теме:
- Модели жизненного цикла проекта
- Agile, Waterfall. Модели и методологии разработки ПО
- Самые распрастранненые модели разработки ПО
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования
Часть 9:
📍Вопрос 1: Что такое жизненный цикл разработки ПО?
✅Краткий ответ:
Жизненный цикл программного обеспечения (ЖЦ ПО) описывает процесс разработки программного обемпечеия, включая все этапы от начала до конца.
Этапы разработки:
1. Определние потребностей заказчика (идея)
2. Сбор и анализ требований
3. Проектирование (документирование требований и дизайн)
4. Разработка ПО
5. Тестирование
6. Внедрение и поддержка продукта
Бизнес-аналитик участвует на каждом этапе ЖЦ ПО
📎Материалы по теме:
- Жизненный цикл программного обеспечения и какое место занимает Бизнес-аналитик в нем
- Что такое ЖЦ Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
- Жизненный цикл проекта и его фазы от инициации до завершения
📍Вопрос 2: Какие бывают модели/методологии жизненного цикла разработки ПО?
✅ Краткий ответ:
- Хорошо подходит проектам, где требования жестко фиксированы и не меняются
- стабильность требований в течение всего жизненного цикла ПО
- прозрачные и прогнозируемые сроки прохождения каждой фазы
- простой алгоритм реализации модели
- невозможность изменять и дополнять список требований на последующих этапах жизненного цикла
- дополнительные затраты на корректировку уже завершенных этапов
- отсутствие промежуточных результатов – продукт можно объективно оценить лишь после официального запуска
- организация эффективной обратной связи проектной команды с заказчиком
- более быстрое решение возникших проблем и ошибок, что ведет к минимизации затрат на устранение рисков
- быстрый выпуск MVP
- нет фиксированного бюджета и сроков, а также нужна сильная вовлеченность Заказчика в процесс
- при итерациях приходится отбрасывать часть сделанной ранее работы
- реализация связи с пользователем с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества
- хорошо подходит для проектов с высокой степенью риска
- минимизация рисков через многократные итерации
- высокая стоимость проектирования
- необходимость в высокопрофессиональных знаниях для оценки рисков
- необходимость в четком распределении работ между разработчиками
В данном подходе работа над проектом осуществляется через короткие итерации, называемые спринтами, в течение которых разработчики фокусируются на реализации наиболее значимых в данное время элементов проекта. На каждом этапе работы заказчик оценивает текущие результаты и может внести изменения в требования к продукту
- высокая скорость разработки продукта, что позволяет быстро адаптироваться к меняющимся условиям рынка;
- привлечение заказчика к разработке, что повышает прозрачность и контролируемость проекта;
- улучшение коммуникации в команде, что ускоряет процесс разработки и повышает качество продукта.
- не дает гарантий на долгосрочные планы
- нет жесткой структуры и даже методов для всех проектов
- отсутствие четкого плана, очень “поверхностное” описание требований к системе
- необходимо иметь большой уровень знаний и опыта команды
Есть и другие модели ЖЦ ПО
📎Материалы по теме:
- Модели жизненного цикла проекта
- Agile, Waterfall. Модели и методологии разработки ПО
- Самые распрастранненые модели разработки ПО
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Please open Telegram to view this post
VIEW IN TELEGRAM
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA:
#вопросыссобеседования
Часть 10:
📍Вопрос 1: Какой подход вы используете в своей работе, чтобы повысить точность определения требований и лучшего их понимания заказчиками и пользователем?
Или
Что такое прототипирование и визуализация и для чего вы используете их в своей работе?
✅Краткий ответ:
Лучшим способом повышения точности определения требований и их понимания является использование прототипирования и визуализации.
➖ Разработка прототипа - это процесс создания кратковременной версии будущего продукта с целью демонстрации его функций заказчикам или пользователям.
Прототипирование позволяет снизить риски внесения изменений и позволяет заказчику визуально понимать, что он получит в итоге.
Результатом прототипирования является прототип – эскизная модель конечного решения, которая будет полезна для:
- выявления неправильно описанных или отсутствующих требований;
- подтверждения или опровержения гипотезы о взаимодействии с пользователями;
- уточнения логики бизнес-процессов и бизнес-правил;
- понимания внешнего вида и поведения продукта, единое со стейкхолдерами на ранних стадиях его проектирования.
➖ Визуализация - это создание картинок, диаграмм и других графических изображений для улучшения понимания и осмысления требований заказчиками и пользователями. Другими словами, это разработка макета.
Визуализация помогает заказчикам и пользователям лучше понимать требования и ускоряет процесс принятия решений.
В идеале, создание проекта начинается с прототипирования, чтобы определить концепцию проекта и его основные функциональные требования. Затем, после утверждения концепции, переходят к визуализации, чтобы улучшить дизайн и взаимодействие пользователя с проектом. Комбинирование этих двух подходов может помочь создать лучший проект в сокращенные сроки.
📎Материалы по теме:
- Прототипирование для бизнес-аналитика: техника BABOK®Guide
- Зачем нужно прототипирование
- Вайрфрейм, макет и прототип сайта: в чем разница?
📍Вопрос 2: Что значит «требование хорошего качества» или как определить качество требований? Опиши критерии оценки требований
✅ Краткий ответ:
Для определения качества требований можно воспользоваться принципами SMART, т.е. требования должны удовлетворять следующим критериям:
1. Specific (Конкретное): Требование должно описывать, что именно должно быть выполнено для достижения конкретной цели. Оно должно быть понятно и конкретно, и задокументировано.
2. Measurable (Измеримое): Требование должно иметь параметры, позволяющие измерить достижение целей. Определение точных параметров позволит убедиться в том, что целевые показатели были достигнуты.
3. Attainable (Достижимое): Выставляйте реалистичные цели. Для того чтобы достичь глобальной цели, нужно убедиться, что заданные цели даются в выполнимом объеме и за установленный срок.
4. Relevant (Релевантное/Значимое): Требование хорошего качества должно соответствовать целям компании/организации, так же качественное требование должно соответствовать бизнес-модели проекта.
5. Timel Based (Временно ограниченное): Необходимо установить конкретный период, в течение которого требование должно быть выполнено. Ограничение во времени поможет вам оценить эффективность решений, принятых в процессе выполнения требований.
Создание требования хорошего качества, основываясь на принципе SMART, поможет бизнес-аналитикам грамотно и эффективно определить достижимые, конкретные и соответствующие целям бизнеса задачи, а также измерить и отслеживать их выполнение. Это позволит гарантировать успех проекта и уменьшить риски, связанные с невыполнением требований.
📎Материалы по теме:
- SMART-цели – полный гайд + 12 универсальных примеров
- Цели по SMART: примеры и антипримеры, чек-лист для постановки
- Что такое цели по СМАРТ: обзор метода и пошаговый гайд с примерами
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования
Часть 10:
📍Вопрос 1: Какой подход вы используете в своей работе, чтобы повысить точность определения требований и лучшего их понимания заказчиками и пользователем?
Или
Что такое прототипирование и визуализация и для чего вы используете их в своей работе?
✅Краткий ответ:
Лучшим способом повышения точности определения требований и их понимания является использование прототипирования и визуализации.
➖ Разработка прототипа - это процесс создания кратковременной версии будущего продукта с целью демонстрации его функций заказчикам или пользователям.
Прототипирование позволяет снизить риски внесения изменений и позволяет заказчику визуально понимать, что он получит в итоге.
Результатом прототипирования является прототип – эскизная модель конечного решения, которая будет полезна для:
- выявления неправильно описанных или отсутствующих требований;
- подтверждения или опровержения гипотезы о взаимодействии с пользователями;
- уточнения логики бизнес-процессов и бизнес-правил;
- понимания внешнего вида и поведения продукта, единое со стейкхолдерами на ранних стадиях его проектирования.
➖ Визуализация - это создание картинок, диаграмм и других графических изображений для улучшения понимания и осмысления требований заказчиками и пользователями. Другими словами, это разработка макета.
Визуализация помогает заказчикам и пользователям лучше понимать требования и ускоряет процесс принятия решений.
В идеале, создание проекта начинается с прототипирования, чтобы определить концепцию проекта и его основные функциональные требования. Затем, после утверждения концепции, переходят к визуализации, чтобы улучшить дизайн и взаимодействие пользователя с проектом. Комбинирование этих двух подходов может помочь создать лучший проект в сокращенные сроки.
📎Материалы по теме:
- Прототипирование для бизнес-аналитика: техника BABOK®Guide
- Зачем нужно прототипирование
- Вайрфрейм, макет и прототип сайта: в чем разница?
📍Вопрос 2: Что значит «требование хорошего качества» или как определить качество требований? Опиши критерии оценки требований
✅ Краткий ответ:
Для определения качества требований можно воспользоваться принципами SMART, т.е. требования должны удовлетворять следующим критериям:
1. Specific (Конкретное): Требование должно описывать, что именно должно быть выполнено для достижения конкретной цели. Оно должно быть понятно и конкретно, и задокументировано.
2. Measurable (Измеримое): Требование должно иметь параметры, позволяющие измерить достижение целей. Определение точных параметров позволит убедиться в том, что целевые показатели были достигнуты.
3. Attainable (Достижимое): Выставляйте реалистичные цели. Для того чтобы достичь глобальной цели, нужно убедиться, что заданные цели даются в выполнимом объеме и за установленный срок.
4. Relevant (Релевантное/Значимое): Требование хорошего качества должно соответствовать целям компании/организации, так же качественное требование должно соответствовать бизнес-модели проекта.
5. Timel Based (Временно ограниченное): Необходимо установить конкретный период, в течение которого требование должно быть выполнено. Ограничение во времени поможет вам оценить эффективность решений, принятых в процессе выполнения требований.
Создание требования хорошего качества, основываясь на принципе SMART, поможет бизнес-аналитикам грамотно и эффективно определить достижимые, конкретные и соответствующие целям бизнеса задачи, а также измерить и отслеживать их выполнение. Это позволит гарантировать успех проекта и уменьшить риски, связанные с невыполнением требований.
📎Материалы по теме:
- SMART-цели – полный гайд + 12 универсальных примеров
- Цели по SMART: примеры и антипримеры, чек-лист для постановки
- Что такое цели по СМАРТ: обзор метода и пошаговый гайд с примерами
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему, связанную со стейкхолдерами:
#вопросыссобеседования
Часть 12:
📍Вопрос 1: Кто такие стейкхолдеры и как с ними работать?
✅Краткий ответ:
Стейкхолдеры (заинтересованные стороны) - это все люди, компании и группы, которые имеют интерес к проекту или продукту. Это могут быть клиенты, партнеры, внутренние сотрудники, акционеры и любые другие лица, которые могут быть затронуты проектом.
Стейкхолдеры могут быть внешними и внутренними:
➖Внутренние стейкхолдеры включают группы, отдельно взятых людей или отделы компании, которые работают на пользу бизнеса и частично или полностью влияют на его успешность. Это могут быть высшее руководство, менеджеры, разработчики, маркетологи, сотрудники служб поддержки, новые участники команды и другие, на которых делается акцент при внутреннем управлении бизнеса.
➖ Внешние стейкхолдеры - это люди или организации, которых можно назвать "вне офиса". Они также заинтересованы в результате и успехе бизнеса и могут влиять на него путем своих решений и действий. Среди них могут быть: клиенты, инвесторы, партнеры по бизнесу, поставщики, конкуренты, регулирующие органы, профсоюзы, средства массовой информации и другие.
Отдельно стоит упомянуть проектных стейкхолдеров, которые участвуют в окончании проекта. К ним относятся пользователи, заказчики, аналитики, менеджеры, консультанты, эксперты и все, кто непосредственно или косвенно участвуют в достижении целей проекта.
Конечная цель управления заинтересованными сторонами - достичь согласия между всеми участниками проекта и убедить их работать на благо общей цели. Распознаете, оцениваете и управляете рисками, создаете среду, которая способствует продуктивному общению, а также применяете средства для увеличения вовлеченности и общего чувства сотрудничества.
📎Материалы по теме:
- Кто такие стейкхолдеры
- Стейкхолдеры
📍Вопрос 2: Какие стратегии вы применяете для управления заинтересованными сторонами?
✅ Краткий ответ:
Для управления заинтересованными сторонами можно использовать несколько стратегий:
1. Анализ заинтересованных сторон: изучение всех заинтересованных сторон, которые могут быть затронуты проектом. Это может включать клиентов, партнеров, владельцев бизнеса, сотрудников, инвесторов и т.д. Далее необходимо провести анализ их потребности, интересы, ожидания и оценку проекта, а также определить, какие у них есть ресурсы и влияние на проект.
2. Коммуникация: необходимо установить эффективную коммуникацию с заинтересованными сторонами, чтобы поддерживать их заинтересованность в проекте. Это может включать проведение регулярных совещаний, обмен информацией и документами, периодическую отчетность о состоянии проекта и т.д.
3. Управление конфликтами: необходимо решить непредвиденные проблемы и конфликты, связанные с заинтересованными сторонами. Можно предпринять шаги для идентификации, анализа и контроля конфликтов, используя стратегии убеждения и компромисса, и помочь достичь взаимоприемлемых решений.
4. Создание плана участия: тут идет разработка плана участия заинтересованных сторон в проекте и определение уровня их взаимодействия с проектом. Это может включать планирование обучения, регулирование процессов управления, определение поставок и т.д. Нужно строить план в соответствии с общей философией и целями проекта.
5. Оценка выполнения: тут идет контроль выполнения задач и результативности заинтересованных сторон в проекте и оценка результатов, чтобы решить, нужно ли вносить изменения в стратегию управления заинтересованными сторонами.
📎Материалы по теме:
- Что такое анализ заинтересованных лиц и почему он важен?
- Кому какое дело: управление заинтересованными сторонами проекта
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования
Часть 12:
📍Вопрос 1: Кто такие стейкхолдеры и как с ними работать?
✅Краткий ответ:
Стейкхолдеры (заинтересованные стороны) - это все люди, компании и группы, которые имеют интерес к проекту или продукту. Это могут быть клиенты, партнеры, внутренние сотрудники, акционеры и любые другие лица, которые могут быть затронуты проектом.
Стейкхолдеры могут быть внешними и внутренними:
➖Внутренние стейкхолдеры включают группы, отдельно взятых людей или отделы компании, которые работают на пользу бизнеса и частично или полностью влияют на его успешность. Это могут быть высшее руководство, менеджеры, разработчики, маркетологи, сотрудники служб поддержки, новые участники команды и другие, на которых делается акцент при внутреннем управлении бизнеса.
➖ Внешние стейкхолдеры - это люди или организации, которых можно назвать "вне офиса". Они также заинтересованы в результате и успехе бизнеса и могут влиять на него путем своих решений и действий. Среди них могут быть: клиенты, инвесторы, партнеры по бизнесу, поставщики, конкуренты, регулирующие органы, профсоюзы, средства массовой информации и другие.
Отдельно стоит упомянуть проектных стейкхолдеров, которые участвуют в окончании проекта. К ним относятся пользователи, заказчики, аналитики, менеджеры, консультанты, эксперты и все, кто непосредственно или косвенно участвуют в достижении целей проекта.
Конечная цель управления заинтересованными сторонами - достичь согласия между всеми участниками проекта и убедить их работать на благо общей цели. Распознаете, оцениваете и управляете рисками, создаете среду, которая способствует продуктивному общению, а также применяете средства для увеличения вовлеченности и общего чувства сотрудничества.
📎Материалы по теме:
- Кто такие стейкхолдеры
- Стейкхолдеры
📍Вопрос 2: Какие стратегии вы применяете для управления заинтересованными сторонами?
✅ Краткий ответ:
Для управления заинтересованными сторонами можно использовать несколько стратегий:
1. Анализ заинтересованных сторон: изучение всех заинтересованных сторон, которые могут быть затронуты проектом. Это может включать клиентов, партнеров, владельцев бизнеса, сотрудников, инвесторов и т.д. Далее необходимо провести анализ их потребности, интересы, ожидания и оценку проекта, а также определить, какие у них есть ресурсы и влияние на проект.
2. Коммуникация: необходимо установить эффективную коммуникацию с заинтересованными сторонами, чтобы поддерживать их заинтересованность в проекте. Это может включать проведение регулярных совещаний, обмен информацией и документами, периодическую отчетность о состоянии проекта и т.д.
3. Управление конфликтами: необходимо решить непредвиденные проблемы и конфликты, связанные с заинтересованными сторонами. Можно предпринять шаги для идентификации, анализа и контроля конфликтов, используя стратегии убеждения и компромисса, и помочь достичь взаимоприемлемых решений.
4. Создание плана участия: тут идет разработка плана участия заинтересованных сторон в проекте и определение уровня их взаимодействия с проектом. Это может включать планирование обучения, регулирование процессов управления, определение поставок и т.д. Нужно строить план в соответствии с общей философией и целями проекта.
5. Оценка выполнения: тут идет контроль выполнения задач и результативности заинтересованных сторон в проекте и оценка результатов, чтобы решить, нужно ли вносить изменения в стратегию управления заинтересованными сторонами.
📎Материалы по теме:
- Что такое анализ заинтересованных лиц и почему он важен?
- Кому какое дело: управление заинтересованными сторонами проекта
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему Use cases:
#вопросыссобеседования | @ba_and_sa
Часть 13:
📍Вопрос 1: Что такое Use Case и какие критерии написания вы знаете?
✅Краткий ответ:
Use case - это текстовое представление взаимодействия между действующими сторонами (actors - пользователями, системами или внешними сущностями) и системой или программным приложением.
Другими словами Use case - это часть требований к ПО. Он помогает разработать качественный продукт, от которого пользователь получит ожидаемый результат.
Use case состоит из:
- Заголовок
- Участники
- Предусловие
- Шаги (описание сценария)
- Результат или гарантии успеха
- Альтернативные сценарии
- Постусловие
Критерии для написания use case:
Вот некоторые из них:
1. Ясность и простота: Use case должен быть написан четко и лаконично, избегая технической терминологии, чтобы его можно было легко понять как техническими, так и не-техническими заинтересованными сторонами.
2. Ориентированность на цель: Каждый use case должен четко определять основную цель или задачу, которую он должен выполнить. Он должен фокусироваться на конкретных действиях пользователя и ответах системы, связанных с этой целью.
3. Модульность: Use case должен быть модульным и независимым друг от друга. Он должен описывать отдельный, самодостаточный сценарий без перекрытий или общих шагов.
4. Обработка исключений: Включите альтернативные и исключительные сценарии для предвидения и описания того, как система должна вести себя при неожиданных действиях пользователя или ошибке системы.
5. Интересы заинтересованных сторон: Учитывайте интересы и требования всех заинтересованных сторон, вовлеченных в проект, включая конечных пользователей, администраторов и техническую поддержку, при написании use case.
В целом, хорошие use cases должны быть ясными, основываться на реалистичных условиях и описывать все важные аспекты взаимодействия пользователя с системой. Эти критерии помогут бизнес-аналитику создавать полезные и эффективные сценарии использования.
📎Материалы по теме:
- Use case. Инструкция по работе со сценариями использования для молодого аналитика
- Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case
📍Вопрос 2: Напишите пример Use Cases
✅ Краткий ответ:
Use Case: Регистрация пользователя
Описание:
Этот use case показывает, как новый пользователь может зарегистрировать аккаунт на интернет-магазине.
Основной actor: Новый пользователь
Предусловия:
- Пользователь открыл страницу регистрации.
- Пользователь находится на странице регистрации.
Шаги:
1. Пользователь открывает форму регистрации.
2. Пользователь вводит свое полное имя, адрес электронной почты и желаемый пароль.
3. Пользователь нажимает кнопку "Зарегистрироваться".
4. Система проверяет введенные данные.
5. Система проверяет, не зарегистрирован ли уже указанный адрес электронной почты.
6. Система отправляет пользователю письмо для подтверждения.
7. Пользователь получает письмо для подтверждения и переходит по указанной ссылке.
8. Система проверяет адрес электронной почты и подтверждает его.
9. Система выводит сообщение о подтверждении и автоматически выполняет вход пользователя в приложение.
Альтернативные сценарии:
- Если адрес электронной почты уже зарегистрирован, система выводит сообщение об ошибке и предлагает пользователю войти непосредственно или сбросить пароль.
- Если пользователь не получает письмо для подтверждения, он может запросить его повторно.
Постусловия:
- Пользователь зарегистрирован и авторизован на интернет-магазине.
📎Материалы по теме:
- Use case - что это + 3 примера
- Use case. Что это такое и зачем они нужны? С примерами
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 13:
📍Вопрос 1: Что такое Use Case и какие критерии написания вы знаете?
✅Краткий ответ:
Use case - это текстовое представление взаимодействия между действующими сторонами (actors - пользователями, системами или внешними сущностями) и системой или программным приложением.
Другими словами Use case - это часть требований к ПО. Он помогает разработать качественный продукт, от которого пользователь получит ожидаемый результат.
Use case состоит из:
- Заголовок
- Участники
- Предусловие
- Шаги (описание сценария)
- Результат или гарантии успеха
- Альтернативные сценарии
- Постусловие
Критерии для написания use case:
Вот некоторые из них:
1. Ясность и простота: Use case должен быть написан четко и лаконично, избегая технической терминологии, чтобы его можно было легко понять как техническими, так и не-техническими заинтересованными сторонами.
2. Ориентированность на цель: Каждый use case должен четко определять основную цель или задачу, которую он должен выполнить. Он должен фокусироваться на конкретных действиях пользователя и ответах системы, связанных с этой целью.
3. Модульность: Use case должен быть модульным и независимым друг от друга. Он должен описывать отдельный, самодостаточный сценарий без перекрытий или общих шагов.
4. Обработка исключений: Включите альтернативные и исключительные сценарии для предвидения и описания того, как система должна вести себя при неожиданных действиях пользователя или ошибке системы.
5. Интересы заинтересованных сторон: Учитывайте интересы и требования всех заинтересованных сторон, вовлеченных в проект, включая конечных пользователей, администраторов и техническую поддержку, при написании use case.
В целом, хорошие use cases должны быть ясными, основываться на реалистичных условиях и описывать все важные аспекты взаимодействия пользователя с системой. Эти критерии помогут бизнес-аналитику создавать полезные и эффективные сценарии использования.
📎Материалы по теме:
- Use case. Инструкция по работе со сценариями использования для молодого аналитика
- Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case
📍Вопрос 2: Напишите пример Use Cases
✅ Краткий ответ:
Use Case: Регистрация пользователя
Описание:
Этот use case показывает, как новый пользователь может зарегистрировать аккаунт на интернет-магазине.
Основной actor: Новый пользователь
Предусловия:
- Пользователь открыл страницу регистрации.
- Пользователь находится на странице регистрации.
Шаги:
1. Пользователь открывает форму регистрации.
2. Пользователь вводит свое полное имя, адрес электронной почты и желаемый пароль.
3. Пользователь нажимает кнопку "Зарегистрироваться".
4. Система проверяет введенные данные.
5. Система проверяет, не зарегистрирован ли уже указанный адрес электронной почты.
6. Система отправляет пользователю письмо для подтверждения.
7. Пользователь получает письмо для подтверждения и переходит по указанной ссылке.
8. Система проверяет адрес электронной почты и подтверждает его.
9. Система выводит сообщение о подтверждении и автоматически выполняет вход пользователя в приложение.
Альтернативные сценарии:
- Если адрес электронной почты уже зарегистрирован, система выводит сообщение об ошибке и предлагает пользователю войти непосредственно или сбросить пароль.
- Если пользователь не получает письмо для подтверждения, он может запросить его повторно.
Постусловия:
- Пользователь зарегистрирован и авторизован на интернет-магазине.
📎Материалы по теме:
- Use case - что это + 3 примера
- Use case. Что это такое и зачем они нужны? С примерами
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему пользовательских историй / user story
#вопросыссобеседования | @ba_and_sa
Часть 14:
📍Вопрос 1: Что такое user story? Какие критерии их написания вы знаете?
✅Краткий ответ:
User story - это краткое и затрагивающее интересы пользователя описание конкретной функциональности или возможности, отражающее потребности и ожидания конечного пользователя. Оно обычно составляется простым и нетехническим языком и имеет определенный формат, обеспечивающий ясность и эффективность коммуникации между заинтересованными сторонами и командами разработки
Критерии написания user story:
1. Ориентированность на пользователя или ценность: User story должна фокусироваться на потребностях, мотивациях и целях конечных пользователей. Она должна ясно формулировать, чего пользователь хочет достичь и почему это важно для него.
2. Независимость и малая размерность: User story должна быть достаточно маленькой, чтобы быть завершенной в рамках одной итерации разработки, обычно 1-2 недели. Она также должна быть независимой от других историй, чтобы обеспечить гибкость в их приоритезации и планировании.
3. Тестуемость: Каждая user story должна быть написана таким образом, чтобы ее критерии приемки могли быть четко определены и протестированы. Это помогает убедиться в том, что команда разработки и заинтересованные стороны имеют общее понимание успешной реализации.
4. Общая гранулярность: Избегайте слишком детализированных или мелких user story. Лучше фокусироваться на высокоуровневой функциональности, оставляя возможность для команды разработки определить детали при реализации.
5. Оцениваемость: Каждая User Story должна быть оцениваемой. Команда должна иметь возможность оценить сложность и объем работы, необходимых для реализации каждой истории. Это помогает команде планировать и управлять процессом разработки.
📎Материалы по теме:
- Пользовательские истории в разработке
- Как писать User Stories и зачем они нужны
- Как разработать критерии приёмки для User Story
📍Вопрос 2: Приведите пример user store
✅ Краткий ответ:
Пример хорошо написанной пользовательской истории:
User story строится исходя из шаблона:
«Как» - «Я хочу» - «Чтобы»
Как зарегистрированный пользователь,
Я хочу иметь возможность сбросить свой пароль,
Чтобы я мог восстановить доступ к своему аккаунту, если я его забуду.
Критерии приемлемости:
- На странице входа должна быть ссылка «Забыли пароль».
- Щелчок по ссылке «Забыли пароль» должен перенаправить пользователя на страницу сброса пароля.
- Страница сброса пароля должна предлагать пользователю ввести свой зарегистрированный адрес электронной почты.
- После отправки адреса электронной почты система должна отправить электронное письмо со ссылкой для сброса пароля.
- Щелчок по ссылке сброса пароля в электронном письме должен перенаправить пользователя на страницу, где он может ввести новый пароль.
- При успешном сбросе пароля пользователь должен получить подтверждение и быть перенаправленным на страницу входа
📎Материалы по теме:
- User Story: пора применять правильно
- Пользовательские истории с примерами и шаблоном
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 14:
📍Вопрос 1: Что такое user story? Какие критерии их написания вы знаете?
✅Краткий ответ:
User story - это краткое и затрагивающее интересы пользователя описание конкретной функциональности или возможности, отражающее потребности и ожидания конечного пользователя. Оно обычно составляется простым и нетехническим языком и имеет определенный формат, обеспечивающий ясность и эффективность коммуникации между заинтересованными сторонами и командами разработки
Критерии написания user story:
1. Ориентированность на пользователя или ценность: User story должна фокусироваться на потребностях, мотивациях и целях конечных пользователей. Она должна ясно формулировать, чего пользователь хочет достичь и почему это важно для него.
2. Независимость и малая размерность: User story должна быть достаточно маленькой, чтобы быть завершенной в рамках одной итерации разработки, обычно 1-2 недели. Она также должна быть независимой от других историй, чтобы обеспечить гибкость в их приоритезации и планировании.
3. Тестуемость: Каждая user story должна быть написана таким образом, чтобы ее критерии приемки могли быть четко определены и протестированы. Это помогает убедиться в том, что команда разработки и заинтересованные стороны имеют общее понимание успешной реализации.
4. Общая гранулярность: Избегайте слишком детализированных или мелких user story. Лучше фокусироваться на высокоуровневой функциональности, оставляя возможность для команды разработки определить детали при реализации.
5. Оцениваемость: Каждая User Story должна быть оцениваемой. Команда должна иметь возможность оценить сложность и объем работы, необходимых для реализации каждой истории. Это помогает команде планировать и управлять процессом разработки.
📎Материалы по теме:
- Пользовательские истории в разработке
- Как писать User Stories и зачем они нужны
- Как разработать критерии приёмки для User Story
📍Вопрос 2: Приведите пример user store
✅ Краткий ответ:
Пример хорошо написанной пользовательской истории:
User story строится исходя из шаблона:
«Как» - «Я хочу» - «Чтобы»
Как зарегистрированный пользователь,
Я хочу иметь возможность сбросить свой пароль,
Чтобы я мог восстановить доступ к своему аккаунту, если я его забуду.
Критерии приемлемости:
- На странице входа должна быть ссылка «Забыли пароль».
- Щелчок по ссылке «Забыли пароль» должен перенаправить пользователя на страницу сброса пароля.
- Страница сброса пароля должна предлагать пользователю ввести свой зарегистрированный адрес электронной почты.
- После отправки адреса электронной почты система должна отправить электронное письмо со ссылкой для сброса пароля.
- Щелчок по ссылке сброса пароля в электронном письме должен перенаправить пользователя на страницу, где он может ввести новый пароль.
- При успешном сбросе пароля пользователь должен получить подтверждение и быть перенаправленным на страницу входа
📎Материалы по теме:
- User Story: пора применять правильно
- Пользовательские истории с примерами и шаблоном
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему интеграции систем:
#вопросыссобеседования | @ba_and_sa
Часть 15:
📍Вопрос 1: Что такое интеграция сисем и зачем она нужна в информационных системах?
✅Краткий ответ:
Интеграция систем (или системная интеграция) – это процесс объединения различных систем и приложений для обмена данными и совместной работы. Она необходима для обеспечения эффективной связи и взаимодействия между различными компонентами системы, обеспечивая передачу данных и позволяя достичь целостности и полноты информации.
📎Материалы по теме:
- Системная интеграция, что это и как с ней работать
- Способы интеграции систем (видео)
- Что такое интеграция и зачем она нужна?
📍Вопрос 2: Какие преимущества и недостатки вы можете выделить при интеграции систем?
✅ Краткий ответ:
➕ Преимущества системной интеграции:
1. Автоматизированный обмен данными - упрощение передачи информации, улучшение точности и актуальность данных, так же экономия времени и снижение вероятности ошибок при ручном копировании данных
2. Сокращение затрат на IT-инфраструктуру и масштабируемость - минимизирование финансов на ресурсы обслуживания и поддержку отдельных систем
3. Улучшенная аналитика и прогнозирование - все в едином поле зрения, более полная картина, что улучшает и упрощает работу с бизнес-процессами и тд.
4. Снижение рисков
➖ Недостатки системной интеграции:
1. Потенциальные проблемы безопасности: Интеграция различных систем может создать уязвимости в безопасности, особенно если не принимаются соответствующие меры для защиты данных и доступа к системам
2. Сложность внедрения: Системная интеграция может быть сложным и трудоемким процессом, особенно если различные системы имеют разные форматы данных и протоколы взаимодействия
3. Риск некорректной интеграции: Неправильная интеграция систем может привести к ошибкам и проблемам в работе системы, что может затруднить бизнес-процессы и привести к сбоям
4. Зависимость от поставщиков решений: Для реализации интеграции могут потребоваться специальные решения и услуги от поставщиков, что создает зависимость и дополнительные расходы.
📍Вопрос 3: Какие методы интеграции могут использоваться при обмене данными между различными системами?
✅ Краткий ответ:
При обмене данными между системами могут быть использованы различные методы системной интеграции, например:
1. Пакетная обработка: Данные передаются в виде пакетов, которые обрабатываются пакетными программами или заданиями. Этот метод позволяет обеспечить обмен данными в определенные моменты времени или по определенному расписанию.
2. Форматы файлов: Данные могут быть обменены с использованием различных форматов файлов, таких как CSV, XML или JSON. Эти форматы позволяют структурировать данные и легко их обрабатывать.
3. Базы данных: Интеграция может происходить через общие базы данных, где системы записывают и читают данные из общих таблиц. Это позволяет обмениваться актуальной информацией между системами.
4. Сетевые протоколы: Для системной интеграции могут быть использованы сетевые протоколы, такие как HTTP, FTP, TCP/IP и т.д. При этом данные могут передаваться через сеть в реальном времени.
5. Сервисно-ориентированная архитектура (SOA): В рамках SOA системы взаимодействуют через сервисы, включающие интерфейсы, выделяющие четко определенные функции или работы для других систем. Используя стандартизированные интерфейсы, системы могут обмениваться данными и функциональностью.
6. API (Application Programming Interface): API позволяет системам обмениваться данными и взаимодействовать друг с другом. Существуют различные типы API, такие как REST (Representational State Transfer), SOAP (Simple Object Access Protocol), GraphQL (Query Language for APIs) и другие структуры и протоколы, которые определяют, как системы могут взаимодействовать между собой.
📎Материалы по теме:
- Методы интеграции информационных систем
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 15:
📍Вопрос 1: Что такое интеграция сисем и зачем она нужна в информационных системах?
✅Краткий ответ:
Интеграция систем (или системная интеграция) – это процесс объединения различных систем и приложений для обмена данными и совместной работы. Она необходима для обеспечения эффективной связи и взаимодействия между различными компонентами системы, обеспечивая передачу данных и позволяя достичь целостности и полноты информации.
📎Материалы по теме:
- Системная интеграция, что это и как с ней работать
- Способы интеграции систем (видео)
- Что такое интеграция и зачем она нужна?
📍Вопрос 2: Какие преимущества и недостатки вы можете выделить при интеграции систем?
✅ Краткий ответ:
1. Автоматизированный обмен данными - упрощение передачи информации, улучшение точности и актуальность данных, так же экономия времени и снижение вероятности ошибок при ручном копировании данных
2. Сокращение затрат на IT-инфраструктуру и масштабируемость - минимизирование финансов на ресурсы обслуживания и поддержку отдельных систем
3. Улучшенная аналитика и прогнозирование - все в едином поле зрения, более полная картина, что улучшает и упрощает работу с бизнес-процессами и тд.
4. Снижение рисков
1. Потенциальные проблемы безопасности: Интеграция различных систем может создать уязвимости в безопасности, особенно если не принимаются соответствующие меры для защиты данных и доступа к системам
2. Сложность внедрения: Системная интеграция может быть сложным и трудоемким процессом, особенно если различные системы имеют разные форматы данных и протоколы взаимодействия
3. Риск некорректной интеграции: Неправильная интеграция систем может привести к ошибкам и проблемам в работе системы, что может затруднить бизнес-процессы и привести к сбоям
4. Зависимость от поставщиков решений: Для реализации интеграции могут потребоваться специальные решения и услуги от поставщиков, что создает зависимость и дополнительные расходы.
📍Вопрос 3: Какие методы интеграции могут использоваться при обмене данными между различными системами?
✅ Краткий ответ:
При обмене данными между системами могут быть использованы различные методы системной интеграции, например:
1. Пакетная обработка: Данные передаются в виде пакетов, которые обрабатываются пакетными программами или заданиями. Этот метод позволяет обеспечить обмен данными в определенные моменты времени или по определенному расписанию.
2. Форматы файлов: Данные могут быть обменены с использованием различных форматов файлов, таких как CSV, XML или JSON. Эти форматы позволяют структурировать данные и легко их обрабатывать.
3. Базы данных: Интеграция может происходить через общие базы данных, где системы записывают и читают данные из общих таблиц. Это позволяет обмениваться актуальной информацией между системами.
4. Сетевые протоколы: Для системной интеграции могут быть использованы сетевые протоколы, такие как HTTP, FTP, TCP/IP и т.д. При этом данные могут передаваться через сеть в реальном времени.
5. Сервисно-ориентированная архитектура (SOA): В рамках SOA системы взаимодействуют через сервисы, включающие интерфейсы, выделяющие четко определенные функции или работы для других систем. Используя стандартизированные интерфейсы, системы могут обмениваться данными и функциональностью.
6. API (Application Programming Interface): API позволяет системам обмениваться данными и взаимодействовать друг с другом. Существуют различные типы API, такие как REST (Representational State Transfer), SOAP (Simple Object Access Protocol), GraphQL (Query Language for APIs) и другие структуры и протоколы, которые определяют, как системы могут взаимодействовать между собой.
📎Материалы по теме:
- Методы интеграции информационных систем
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Please open Telegram to view this post
VIEW IN TELEGRAM
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA
#вопросыссобеседования | @ba_and_sa
Часть 16:
📍Вопрос 1: Что означает аббревиатура INVEST и как с ней работать?
✅Краткий ответ:
INVEST - это аббревиатура, с помощью которой можно создавать качественные User Story / Пользовательские истории.
Каждая буква в слове INVEST представляет собой определенный критерий, который помогает определить ценность для пользователей и бизнеса.
I - Independent (независимость): задачи должны быть независимы друг от друга, чтобы их можно было выполнять в любом порядке.
N - Negotiable (договорная): задачи должны быть достаточно гибкими, чтобы их можно было изменять в процессе разработки.
V - Valuable (ценность): задачи должны иметь ценность для пользователей и бизнеса.
E - Estimable (оцениваемость): задачи должны иметь достаточно информации для того, чтобы их можно было оценить по времени и затратам.
S - Small (маленькие): задачи должны быть достаточно маленькими, чтобы их можно было завершить за короткое время.
T - Testable (тестируемость): задачи должны быть достаточно четко определены, чтобы их можно было протестировать.
📎Материалы по теме:
- INVEST опыт из реальных проектов
- Что такое INVEST-критерии для задач
📍Вопрос 2: Что такое USM - User Story Mapping?
✅ Краткий ответ:
User Story Mapping (USM - Карта пользовательских историй) - это инструмент Agile-разработки, который помогает команде разработки видеть продукт глазами пользователя. User Story Mapping представляет собой структурированную визуализацию функциональных требований, объединенных вокруг пользовательских сценариев. Он помогает команде лучше понять, как пользователи будут взаимодействовать с продуктом и какие функции им нужны для достижения своих целей.
USM включает в себя этапы:
1. Определение перспективы пользователей - определение целевых пользователей продукта и их потребностей.
2. Создание начальной карты пользовательских историй - отображение user story от начальной до конечной точки взаимодействия пользователя с продуктом.
3. Группировка пользовательских историй: объедините пользовательские истории в логические группы, отражающие этапы или процессы, через которые проходят пользователи.
4. Поиск пробелов: выявите пробелы или недостающие элементы в вашей карте пользовательских историй
5. Использование карты пользовательских историй в процессе разработки
📎Материалы по теме:
- User Story Map в проектировании продукта: как приоритизировать бэклог и определиться с MVP
- Что такое User Story Mapping и зачем это нужно
- User Story Mapping как подход к проектированию
📍Вопрос 3: Что такое CJM - Customer Journey Map?
✅ Краткий ответ:
Customer Journey Map (Карта путешествия клиента) - это инструмент, который помогает понять взаимодействие пользователя с продуктом или услугой через весь процесс от начала и до конца. Customer Journey Map фокусируется на выявлении опыта клиента от начала до конца, включая контакты, эмоции, потребности и ожидания пользователя на каждом этапе пути.
Метод customer journey map — это изучение мотивов, потребностей и эмоций клиента, чтобы улучшить его опыт взаимодействия с продуктом или компанией.
Работа с CJM включает в себя следующие этапы:
1. Шкала времени
2. Сценарий или этапы взаимодействия
4. Определение потребностей и эмоций пользователей
5. Поиск возможностей для улучшения
6. Внедрение улучшений
📎Материалы по теме:
- Что такое Customer Journey Map и как правильно составить карту пути пользователя
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 16:
📍Вопрос 1: Что означает аббревиатура INVEST и как с ней работать?
✅Краткий ответ:
INVEST - это аббревиатура, с помощью которой можно создавать качественные User Story / Пользовательские истории.
Каждая буква в слове INVEST представляет собой определенный критерий, который помогает определить ценность для пользователей и бизнеса.
I - Independent (независимость): задачи должны быть независимы друг от друга, чтобы их можно было выполнять в любом порядке.
N - Negotiable (договорная): задачи должны быть достаточно гибкими, чтобы их можно было изменять в процессе разработки.
V - Valuable (ценность): задачи должны иметь ценность для пользователей и бизнеса.
E - Estimable (оцениваемость): задачи должны иметь достаточно информации для того, чтобы их можно было оценить по времени и затратам.
S - Small (маленькие): задачи должны быть достаточно маленькими, чтобы их можно было завершить за короткое время.
T - Testable (тестируемость): задачи должны быть достаточно четко определены, чтобы их можно было протестировать.
📎Материалы по теме:
- INVEST опыт из реальных проектов
- Что такое INVEST-критерии для задач
📍Вопрос 2: Что такое USM - User Story Mapping?
✅ Краткий ответ:
User Story Mapping (USM - Карта пользовательских историй) - это инструмент Agile-разработки, который помогает команде разработки видеть продукт глазами пользователя. User Story Mapping представляет собой структурированную визуализацию функциональных требований, объединенных вокруг пользовательских сценариев. Он помогает команде лучше понять, как пользователи будут взаимодействовать с продуктом и какие функции им нужны для достижения своих целей.
USM включает в себя этапы:
1. Определение перспективы пользователей - определение целевых пользователей продукта и их потребностей.
2. Создание начальной карты пользовательских историй - отображение user story от начальной до конечной точки взаимодействия пользователя с продуктом.
3. Группировка пользовательских историй: объедините пользовательские истории в логические группы, отражающие этапы или процессы, через которые проходят пользователи.
4. Поиск пробелов: выявите пробелы или недостающие элементы в вашей карте пользовательских историй
5. Использование карты пользовательских историй в процессе разработки
📎Материалы по теме:
- User Story Map в проектировании продукта: как приоритизировать бэклог и определиться с MVP
- Что такое User Story Mapping и зачем это нужно
- User Story Mapping как подход к проектированию
📍Вопрос 3: Что такое CJM - Customer Journey Map?
✅ Краткий ответ:
Customer Journey Map (Карта путешествия клиента) - это инструмент, который помогает понять взаимодействие пользователя с продуктом или услугой через весь процесс от начала и до конца. Customer Journey Map фокусируется на выявлении опыта клиента от начала до конца, включая контакты, эмоции, потребности и ожидания пользователя на каждом этапе пути.
Метод customer journey map — это изучение мотивов, потребностей и эмоций клиента, чтобы улучшить его опыт взаимодействия с продуктом или компанией.
Работа с CJM включает в себя следующие этапы:
1. Шкала времени
2. Сценарий или этапы взаимодействия
4. Определение потребностей и эмоций пользователей
5. Поиск возможностей для улучшения
6. Внедрение улучшений
📎Материалы по теме:
- Что такое Customer Journey Map и как правильно составить карту пути пользователя
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и поговорим про требования к системе:
#вопросыссобеседования | @ba_and_sa
Часть 17:
📍Вопрос 1: Что такое документирование требований? Для чего документировать требования?
✅Краткий ответ:
Документирование требований – это процесс формального записывания требований к проекту или продукту. Это включает в себя определение функциональных и нефункциональных требований, а также требований к качеству и ограничений.
Документирование требований необходимо для того, чтобы:
1. Сформулировать и утвердить конкретные требования к продукту или процессу.
2. Определить стандарты, условия и критерии оценки, с которыми должны согласиться все заинтересованные стороны.
3. Установить точные границы и ограничения проекта или продукта.
4. Сведения требований к единым и однозначным формулировкам для всех участников проекта.
5. Улучшить коммуникацию между заказчиком и исполнителем.
6. Предотвратить внесение ошибок или недопониманий в процессе разработки.
7. Обеспечить возможность проверки выполнения задач.
8. Сохранить и передать знания о требованиях к продукту или процессу для текущих и будущих участников проектов….
📎Материалы по теме:
- Документирование требований
- Документирование требований: мелкие ошибки, порождающие крупные проблемы
📍Вопрос 2: Какие вы знаете методы / способы документирования требований?
✅ Краткий ответ:
1. Use Case диаграммы - представляют сценарии использования системы через взаимодействие актеров (пользователей) с системой.
- Каждый сценарий описывает, как система и пользователь взаимодействуют для достижения определенной цели.
- В основном используется для описания функциональных требований системы и их взаимосвязей
2. Entity Relationship диаграммы (ER-диаграммы) - описывают структуру данных в системе и их взаимосвязи.
- Моделируют сущности (объекты) и их атрибуты, а также связи между сущностями.
- Используется для документирования требований к базе данных и хранению информации.
3. UML (Unified Modeling Language) диаграммы - представляют различные аспекты системы, включая структуру, поведение, взаимодействие компонентов и т.д.
- Включают в себя Class диаграммы, Sequence диаграммы, Activity диаграммы, и др.
- Используется для визуализации и анализа требований, моделирования различных аспектов системы.
4. Моделирование Бизнес-процессов - описывают последовательность действий, необходимых для достижения определенной цели в рамках бизнес-процесса.
- Включают в себя процессы, ресурсы, участников и взаимодействие между ними.
- Используется для документирования бизнес-требований и процессов.
5. Технические спецификации - включают в себя подробные описания функциональных и нефункциональных требований, а также технические аспекты реализации системы.
- Описывают методы, алгоритмы, архитектуру, интерфейсы и т.д.
- Используется для передачи требований разработчикам и инженерам.
6. Прототипы и мокапы - представляют собой визуальные модели интерфейсов системы.
- Используются для визуализации и проверки пользовательских требований, а также для обсуждения идей и обратной связи.
Каждый из этих методов имеет свои особенности и может использоваться в зависимости от конкретных потребностей проекта и предпочтений команды.
Что такое требования к системе или какие они бывают, мы рассматривали раннее в 3 части
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 17:
📍Вопрос 1: Что такое документирование требований? Для чего документировать требования?
✅Краткий ответ:
Документирование требований – это процесс формального записывания требований к проекту или продукту. Это включает в себя определение функциональных и нефункциональных требований, а также требований к качеству и ограничений.
Документирование требований необходимо для того, чтобы:
1. Сформулировать и утвердить конкретные требования к продукту или процессу.
2. Определить стандарты, условия и критерии оценки, с которыми должны согласиться все заинтересованные стороны.
3. Установить точные границы и ограничения проекта или продукта.
4. Сведения требований к единым и однозначным формулировкам для всех участников проекта.
5. Улучшить коммуникацию между заказчиком и исполнителем.
6. Предотвратить внесение ошибок или недопониманий в процессе разработки.
7. Обеспечить возможность проверки выполнения задач.
8. Сохранить и передать знания о требованиях к продукту или процессу для текущих и будущих участников проектов….
📎Материалы по теме:
- Документирование требований
- Документирование требований: мелкие ошибки, порождающие крупные проблемы
📍Вопрос 2: Какие вы знаете методы / способы документирования требований?
✅ Краткий ответ:
1. Use Case диаграммы - представляют сценарии использования системы через взаимодействие актеров (пользователей) с системой.
- Каждый сценарий описывает, как система и пользователь взаимодействуют для достижения определенной цели.
- В основном используется для описания функциональных требований системы и их взаимосвязей
2. Entity Relationship диаграммы (ER-диаграммы) - описывают структуру данных в системе и их взаимосвязи.
- Моделируют сущности (объекты) и их атрибуты, а также связи между сущностями.
- Используется для документирования требований к базе данных и хранению информации.
3. UML (Unified Modeling Language) диаграммы - представляют различные аспекты системы, включая структуру, поведение, взаимодействие компонентов и т.д.
- Включают в себя Class диаграммы, Sequence диаграммы, Activity диаграммы, и др.
- Используется для визуализации и анализа требований, моделирования различных аспектов системы.
4. Моделирование Бизнес-процессов - описывают последовательность действий, необходимых для достижения определенной цели в рамках бизнес-процесса.
- Включают в себя процессы, ресурсы, участников и взаимодействие между ними.
- Используется для документирования бизнес-требований и процессов.
5. Технические спецификации - включают в себя подробные описания функциональных и нефункциональных требований, а также технические аспекты реализации системы.
- Описывают методы, алгоритмы, архитектуру, интерфейсы и т.д.
- Используется для передачи требований разработчикам и инженерам.
6. Прототипы и мокапы - представляют собой визуальные модели интерфейсов системы.
- Используются для визуализации и проверки пользовательских требований, а также для обсуждения идей и обратной связи.
Каждый из этих методов имеет свои особенности и может использоваться в зависимости от конкретных потребностей проекта и предпочтений команды.
Что такое требования к системе или какие они бывают, мы рассматривали раннее в 3 части
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA:
#вопросыссобеседования | @ba_and_sa
Часть 18:
📍Вопрос 1: Что такое Code First и для чего и где его используют?
✅Краткий ответ:
Code First - это подход к разработке программного обеспечения, который заключается в создании кода приложения сначала, а затем автоматической генерации базы данных и моделей на основе этого кода.
Этот подход обычно используется в случаях, когда разработчики хотят быстро создать прототип или MVP приложения. Однако, недостатком Code First является то, что API может не соответствовать требованиям клиентов или стандартам безопасности.
Для чего нужен подход Code First? Он позволяет разработчикам сосредоточиться на создании бизнес-логики и функциональности приложения, не тратя время на создание и поддержание схемы базы данных. Кроме того, Code First позволяет более гибко изменять структуру базы данных, так как изменения в коде сразу отражаются в базе данных.
➕ Преимущества подхода Code First:
1. Быстрая разработка - разработчики могут быстро создавать и изменять модели данных, без необходимости написания SQL запросов или изменения схемы базы данных.
2. Гибкость - изменения в структуре базы данных можно легко вносить, не нарушая целостность данных.
3. Простота в поддержке - разработчики могут легко создавать и обновлять миграции базы данных для обновления схемы.
➖ Недостатки подхода Code First:
1. Недостаточный контроль - генерация базы данных автоматически может привести к недостаточному контролю над структурой и индексами.
2. Не всегда оптимальная производительность - автоматически сгенерированные запросы могут быть не всегда оптимальными по производительности.
3. Сложность масштабирования - при большом количестве данных и сложной структуре базы данных, могут возникнуть проблемы с масштабируемостью.
📎Материалы по теме:
- Разработка REST API — что такое Code First подход?
📍Вопрос 2: Что такое Contract First и где его используют?
✅ Краткий ответ:
Contract First - это подход к разработке программного обеспечения, который заключается в определении и создании спецификации интерфейса API (например, формата передачи данных, структуры сообщений) до начала разработки кода приложения. Этот подход обычно используется для обеспечения соответствия API стандартам, требованиям клиентов и улучшения коммуникации между разработчиками и заказчиками.
Для чего нужен подход Contract First? Он помогает более предсказуемо определить структуру API и обеспечить согласованность между разработчиками и клиентами. Кроме того, Contract First упрощает тестирование API, так как спецификация уже определена заранее.
➕ Преимущества подхода Contract First:
1. Повышение качества - задание структуры API заранее помогает избежать недочетов и ошибок в разработке.
2. Совместимость - спецификация API может быть использована для генерации кода на разных языках программирования.
3. Улучшенная коммуникация - заказчики и разработчики имеют общее обозначение структуры и функциональности API.
➖ Недостатки подхода Contract First:
1. Дополнительные трудозатраты - создание спецификации API может потребовать дополнительного времени и ресурсов.
2. Ограничения гибкости - изменения в API могут потребовать корректировки спецификации, что может занять дополнительное время.
📎Материалы по теме:
- Разработка REST API — что такое Contract First?
📍Вопрос 3: В чем разница между Code First и Contract First?
✅ Краткий ответ:
Разница между Code First и Contract First заключается во времени начала создания API. Code First начинается с написания кода приложения, а затем автоматической генерации API на его основе, в то время как Contract First начинается с создания интерфейса API и определения спецификации, затем код приложения создается на основе этой спецификации.
В след раз поговорим о других подходах😉
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 18:
📍Вопрос 1: Что такое Code First и для чего и где его используют?
✅Краткий ответ:
Code First - это подход к разработке программного обеспечения, который заключается в создании кода приложения сначала, а затем автоматической генерации базы данных и моделей на основе этого кода.
Этот подход обычно используется в случаях, когда разработчики хотят быстро создать прототип или MVP приложения. Однако, недостатком Code First является то, что API может не соответствовать требованиям клиентов или стандартам безопасности.
Для чего нужен подход Code First? Он позволяет разработчикам сосредоточиться на создании бизнес-логики и функциональности приложения, не тратя время на создание и поддержание схемы базы данных. Кроме того, Code First позволяет более гибко изменять структуру базы данных, так как изменения в коде сразу отражаются в базе данных.
1. Быстрая разработка - разработчики могут быстро создавать и изменять модели данных, без необходимости написания SQL запросов или изменения схемы базы данных.
2. Гибкость - изменения в структуре базы данных можно легко вносить, не нарушая целостность данных.
3. Простота в поддержке - разработчики могут легко создавать и обновлять миграции базы данных для обновления схемы.
1. Недостаточный контроль - генерация базы данных автоматически может привести к недостаточному контролю над структурой и индексами.
2. Не всегда оптимальная производительность - автоматически сгенерированные запросы могут быть не всегда оптимальными по производительности.
3. Сложность масштабирования - при большом количестве данных и сложной структуре базы данных, могут возникнуть проблемы с масштабируемостью.
📎Материалы по теме:
- Разработка REST API — что такое Code First подход?
📍Вопрос 2: Что такое Contract First и где его используют?
✅ Краткий ответ:
Contract First - это подход к разработке программного обеспечения, который заключается в определении и создании спецификации интерфейса API (например, формата передачи данных, структуры сообщений) до начала разработки кода приложения. Этот подход обычно используется для обеспечения соответствия API стандартам, требованиям клиентов и улучшения коммуникации между разработчиками и заказчиками.
Для чего нужен подход Contract First? Он помогает более предсказуемо определить структуру API и обеспечить согласованность между разработчиками и клиентами. Кроме того, Contract First упрощает тестирование API, так как спецификация уже определена заранее.
1. Повышение качества - задание структуры API заранее помогает избежать недочетов и ошибок в разработке.
2. Совместимость - спецификация API может быть использована для генерации кода на разных языках программирования.
3. Улучшенная коммуникация - заказчики и разработчики имеют общее обозначение структуры и функциональности API.
1. Дополнительные трудозатраты - создание спецификации API может потребовать дополнительного времени и ресурсов.
2. Ограничения гибкости - изменения в API могут потребовать корректировки спецификации, что может занять дополнительное время.
📎Материалы по теме:
- Разработка REST API — что такое Contract First?
📍Вопрос 3: В чем разница между Code First и Contract First?
✅ Краткий ответ:
Разница между Code First и Contract First заключается во времени начала создания API. Code First начинается с написания кода приложения, а затем автоматической генерации API на его основе, в то время как Contract First начинается с создания интерфейса API и определения спецификации, затем код приложения создается на основе этой спецификации.
В след раз поговорим о других подходах
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Please open Telegram to view this post
VIEW IN TELEGRAM
