ЗАМЕТКИ

Бизнес-аналитик в IT. Команды и процессы.

Жизненный цикл разработки ПО

Исходные модели:

  • Waterfall Model каскадная модель, или «Водопад»
  • V-model V-образная модель, разработки через тестирование
  • Incremental Model инкрементная модель
  • Iterative Model итеративная (или итерационная) модель
  • Spiral Model спиральная модель
  • Chaos model модель хаоса
  • Prototype Model прототипная модель

Публикация на habr.com — Ещё раз про семь основных методологий разработки ссылка или архив в pdf ссылка

Rational Unified Process (RUP)

Недостатки каскадной модели — чем больше Проект, трудоемкость и сроки реализации, тем больше допущений закладывается в проект, которые могут оказаться как верными так и не верными. Самые критичные — это допущения связанные с бизнес-целями Проекта, если они оказываются не верными то все вложенные в проект ресурсы, деньги и время обесцениваются.

Методология RUP была целенаправленно разработана для разработки больших программных систем.


Rational Unified Process (RUP)

Разработка бизнес-сценария использования (Business Modeling), где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются сценарии использования (Use Cases), описывающие функции системы (Requirements), которые будут поддерживать выполнение бизнес-сценария. На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии (Analysis & Design). Каждый бизнес-сценарий разворачивается в системные сценарии использования. Каждый системный сценарий — в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа…). На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы).

habr.com — Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов ссылка

Принципы RUP

  • Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков
  • Концентрация на выполнении требований заказчиков к исполняемой программе
  • Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки
  • Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта
  • Постоянное обеспечение качества на всех этапах разработки проекта (продукта)
  • Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам

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

Сравнение SCRUM, KANBAN и WATERFALL

# SCRUM CANBAN WATERFALL
Темп Повторяемые спринты фиксированной продолжительности Не прерывный процесс Этап с ожидаемыми сроками
Выпуск релиза В конце каждого спринта после одобрения проектным менеджером (владельцем продукта) Поток продолжается без перерывов или на усмотрение команды По результатам этапа разработки
Роли Владелец продукта, Scrum-мастер, Dev-team и необходимые эксперты Команда под руководством проджекта Проектная команда
Показатели Скорость команды Ведущее время Сроки и требования
Приемлемость изменений В ходе спринта изменения не желательны, так как могут привесети к неверной оценке задачи Изменения могут случиться в любой момент времени Только в следующем цикле

Техники декомпозиции требований

  • Горизонтальная декомпозиция, задачи разбиваются по типу работы (функции), которую необходимо выполнить, по компонентам, которые задействованы в работе. В этом случае при разбиении общей большой задачи разработчику будет выделена одна часть, тестировщику другая, техническому писателю третья и так далее. Фактически каждая из частей не приводит к конечному результату сама по себе, чтобы выпустить готовый функционал, необходима реализация всей совокупности связанных задач всеми участниками процесса.
  • Вертикальная декомпозиция напротив предполагает выделение более мелких задач, фич, функций таким, образом, что каждая такая пользовательская история может быть реализована и выпущена отдельно от остальных задач. При этом в разработку могут быть вовлечены различные роли, могут быть задействованы несколько модулей и систем.

Метод 1: По этапам\фазам бизнес процесса. В данном процессе необходимо выделить последовательную цепочку шагов , которые могут быть реализованы и выполнены независимо друг от друга. Большой бизнес процесс разбивается на составляющие его этапы. При этом этапы могут быть критичными и обязательными или опциональными.

Метод 2: По позитивным и негативным сценариям. Ожидаемые сценарий использования функционала и неправильные, но возможные и вероятные сценарии.

Метод 3: По правилам\условиям бизнес процесса. Декомпозиция процесса на логические ветки, возможные варианты отработки функционала. Определяется набор сценариев, по которым может выполняться процесс при выполнении тех или иных правил\условий.

Метод 4: По видам операций. Выделение операций позволит расставить для них приоритеты.

Метод 5: По типам платформы\ОС. Декомпозиция требований на составные части реализации одного и того же функционала для разных платформ, устройств, операционных систем.

Метод 6: По типам данных и параметрам. Декомпозиция требований\фич на ряд мелких пользовательских историй (User story), в рамках каждой из которых нужно реализовать работу только с каким-то одним типом данных.

Метод 7: По ролям\правам доступа. Каждая группа пользователей с определенной ролью и правами доступа, может выполнять только определенную часть функций из общего процесса.

Метод 8: По сценариям тестирования\тест-кейсам. Набор сценариев которые необходимо проверить и какие тесты выполнить, чтобы узнать, работает та или иная функция системы. Набор тест-кейсов, каждый из которых представляет собой отдельную задачу. Каждая задача должна быть реализована так, чтобы тестовый сценарий был успешно пройден.