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

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

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

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

PRINCE2 (PRojects IN Controlled Environments)

Cтруктурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании. Как указывают сами авторы методологии, PRINCE2 создан на основе опыта, полученного из тысяч проектов, в центре внимания методологии – управленческие стороны проекта.


7 принципов в PRINCE2

1 Постоянная оценка целесообразности (Continued business justification)
Спонсор проекта (в русских договорных отношениях это чаще всего Заказчик, даже если он внутренний) должен быть постоянно уверен в необходимости реализации проекта, если такая необходимость отпала, то проект следует прекратить. Ожидаемые выгоды должны быть больше затрат и рисков.

2 Учет предыдущего опыта (Learn from experience)
Принцип призывает руководителей проектов постоянно анализировать и использовать извлеченные уроки других проектов, а также фиксировать собственный опыт в ходе своего проекта.

3 Определенные роли и обязанности (Defined roles and responsibilities)
В каждом проекте должна быть сформирована матрица ответственности в рамках проекта и его организационной структуре. Авторы PRINCE2 выделяют три заинтересованные стороны проекта: бизнес (определяет цели проекта и инвестирует его), пользователи (используют продукт проекта) и поставщики (предоставляют ресурсы).

4 Управления по стадиям (Manage by stages)
Проект должен планироваться, отслеживаться и контролироваться по стадиям, в конце каждой стадии должен обновляться план следующей стадии с учетом результатов завершающейся текущей стадии. Между каждой стадией должны присутствовать точки принятия основных решений.

5 Управление по исключениям (Manage by exception)
Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Такой способ управления позволяет экономить как время высшего руководства, спонсоров проекта, так и самого менеджера проекта. Допустимые отклонения должны быть определены для каждого уровня плана проекта.

6 Фокус на продукте (Focus on product)
Акцент в проекте должен быть на конечном продукте и его качестве. Процедура управления изменениями снижает увеличение скоупа проекта. Акцент на качестве и утвержденном описании продукта снижает неудовлетворенность пользователей (потребителей) конченного продукта проекта.

7 Адаптация к внешним условиям (Tailor to suit the project environment)
Проектная команда должна осознавать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта.

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

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

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

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

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

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

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

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

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

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

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

Базовые принципы техник оценки в Agile
1 Высокая скорость оценки
2 Командная работа
3 Относительные единицы измерения
Методы оценки ссылка