​​Алоха! Если вы работаете в области аналитики или только хотите начать, то вы знаете, как важно тщательно анализировать и понимать требования к разрабатываемому продукту.

Поэтому предлагаю краткую методику/подход по сбору и анализу требований к программному продукту с последующим проектированием системы на их основе:

✅Шаг 1. Определение заказчика и заинтересованных сторон.
Определите, кто является заказчиком разработки ПО и кто из заинтересованных сторон может повлиять на требования и функциональность ПО.

✅Шаг 2. Определение целей и задач проекта.
Необходимо определить, что именно заказчик ожидает от вашего проекта, а также выяснить задачи, которые необходимо выполнить, чтобы достичь этих целей.

По завершению этих шагов производится вывод о том, будет ли разрабатываться этот продукт или нет.

✅Шаг 3. Сбор требований заказчика.
Начните с сбора основных требований, которые должны быть реализованы в ПО. Это могут быть данные о функциональности, интерфейсе пользователя, возможных ограничениях и т.д.

На данном шаге необходимо определить функции продукта и способы его интеграции в существующие процессы.

✅Шаг 4. Анализ требований.
Проходит структуризация уже собранных раннее требований. Т.е. необходимо предоставить четкий список не дублируемых требований к системе

✅Шаг 5. Описание функциональных и нефункциональных требований к проекту.
Вы можете использовать различные методы формализации требований и нотации, чтобы описать необходимые пункты.

✅Шаг 6. Обеспечьте связь между требованиями и спецификациями системы.
Разработайте тестовые сценарии (Use case) и функциональные требования к отдельным компонентам, чтобы убедиться, что они хорошо интегрируются в систему.

✅Шаг 7. Установление приоритетности требований.
Оцените важность каждого требования в разработке ПО и установите их порядок приоритетности.

✅Шаг 8. Определение ограничений и требований безопасности.
При разработке любой программы необходимо учитывать требования безопасности для защиты от взломов и утечки данных.

✅Шаг 9. Оценка финансовых возможностей проекта.
Проанализируйте затраты на разработку, внедрение и поддержание проекта на протяжении его жизненного цикла (в основном это делает ПМ или РП)

✅Шаг 10. Определение технологий и инструментов (сопоставление полученных результатов с возможностями технической инфраструктуры проекта и ресурсами разработчиков).
Выберите технологии и инструменты, которые используются для создания ПО, и проверьте, соответствует ли их уровень требованиям (в основном это делает ПМ или РП).

✅Шаг 11. Определение пользователей ПО.
Определите ключевых пользователей ПО и их потребности. Это поможет анализировать опыт и поведение пользователей для улучшения функциональности приложения.

✅Шаг 12. Разработка документации.
Разработайте документацию на основе всех результатов, полученных в ходе сбора требований и опишите бизнес-процессы. Это позволит описать структуру ПО и параметры, а также необходимые инструкции и рекомендации для пользователей.

✅Шаг 13. Согласование и обновление требований.
Возможно, после общения с клиентом и заинтересованными сторонами выяснятся дополнительные нужды и требования. Обновите требования и внесите соответствующие изменения в документацию и согласуйте ее с заказчиком и заинтересованными лицами.

✅Шаг 14. Оценка результатов аналитической работы, проведенной на начальных этапах проекта.
Выделите направления для дальнейшей работы, учитывая предыдущие результаты и опыт.

Источник: @ba_and_sa

​​Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему жизненного цикла разработки ПО:

#вопросыссобеседования

Часть 9:

📍Вопрос 1: Что такое жизненный цикл разработки ПО?

✅Краткий ответ:
Жизненный цикл программного обеспечения (ЖЦ ПО) описывает процесс разработки программного обемпечеия, включая все этапы от начала до конца.

Этапы разработки:
1. Определние потребностей заказчика (идея)
2. Сбор и анализ требований
3. Проектирование (документирование требований и дизайн)
4. Разработка ПО
5. Тестирование
6. Внедрение и поддержка продукта

Бизнес-аналитик участвует на каждом этапе ЖЦ ПО

📎Материалы по теме:
- ​​Жизненный цикл программного обеспечения и какое место занимает Бизнес-аналитик в нем
- Что такое ЖЦ Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
- Жизненный цикл проекта и его фазы от инициации до завершения

📍Вопрос 2: Какие бывают модели/методологии жизненного цикла разработки ПО?

✅ Краткий ответ:
1️⃣ Водопадная/Каскадная модель - модель, в которой процесс разработки выглядит как поток, переходящий от одной стадии к другой в строгом порядке, без возможности пропуска стадии или возврата назад.
➕ Преимущесвта:
- Хорошо подходит проектам, где требования жестко фиксированы и не меняются
- стабильность требований в течение всего жизненного цикла ПО
- прозрачные и прогнозируемые сроки прохождения каждой фазы
- простой алгоритм реализации модели
➖ Недостатки:
- невозможность изменять и дополнять список требований на последующих этапах жизненного цикла
- дополнительные затраты на корректировку уже завершенных этапов
- отсутствие промежуточных результатов – продукт можно объективно оценить лишь после официального запуска

2️⃣ Итеративная модель - осуществление разработки с использованием одного цикла разработки, который последовательно повторяется до полного завершения проекта.
➕ Преимущесвта:
- организация эффективной обратной связи проектной команды с заказчиком
- более быстрое решение возникших проблем и ошибок, что ведет к минимизации затрат на устранение рисков
- быстрый выпуск MVP
➖ Недостатки:
- нет фиксированного бюджета и сроков, а также нужна сильная вовлеченность Заказчика в процесс
- при итерациях приходится отбрасывать часть сделанной ранее работы

3️⃣ Спиральная модель - повторяющаяся последовательность циклов разработки с непрерывным контролем рисков
➕ Преимущесвта:
- реализация связи с пользователем с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества
- хорошо подходит для проектов с высокой степенью риска
- минимизация рисков через многократные итерации
➖ Недостатки:
- высокая стоимость проектирования
- необходимость в высокопрофессиональных знаниях для оценки рисков
- необходимость в четком распределении работ между разработчиками

4️⃣ Гибкая модель
В данном подходе работа над проектом осуществляется через короткие итерации, называемые спринтами, в течение которых разработчики фокусируются на реализации наиболее значимых в данное время элементов проекта. На каждом этапе работы заказчик оценивает текущие результаты и может внести изменения в требования к продукту
➕ Преимущесвта:
- высокая скорость разработки продукта, что позволяет быстро адаптироваться к меняющимся условиям рынка;
- привлечение заказчика к разработке, что повышает прозрачность и контролируемость проекта;
- улучшение коммуникации в команде, что ускоряет процесс разработки и повышает качество продукта.
➖ Недостатки:
- не дает гарантий на долгосрочные планы
- нет жесткой структуры и даже методов для всех проектов
- отсутствие четкого плана, очень “поверхностное” описание требований к системе
- необходимо иметь большой уровень знаний и опыта команды

Есть и другие модели ЖЦ ПО

📎Материалы по теме:
- Модели жизненного цикла проекта
- Agile, Waterfall. Модели и методологии разработки ПО
- Самые распрастранненые модели разработки ПО

Источник: @ba_and_sa

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования