3. Модели и методологии разработки по.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки по
Code and fix — модель кодирования и устранения ошибок;
Waterfall Model — каскадная модель, или «водопад»;
V-model — V-образная модель, разработка через тестирование;
Incremental Model — инкрементная модель;
Iterative Model — итеративная (или итерационная) модель;
Spiral Model — спиральная модель;
Chaos model — модель хаоса;
Prototype Model — прототипная модель.
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная.
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
экстремальное программирование (Extreme Programming, XP);
бережливую разработку программного обеспечения (Lean);
фреймворк для управления проектами Scrum;
разработку, управляемую функциональностью (Feature-driven development, FDD);
разработку через тестирование (Test-driven development, TDD);
методологию «чистой комнаты» (Cleanroom Software Engineering);
итеративно-инкрементальный метод разработки (OpenUP);
методологию разработки Microsoft Solutions Framework (MSF);
метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
метод управления разработкой Kanban.
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Extreme Programming
(экстремальное программирование, XP)
Extreme Programming считается неформальным подходом разработки ПО, где каждый разработчик – профессионал своего дела. Если же отношение меняется, то внедрять методологию бесполезно. Разработка продукта ведется короткими итерациями. Экстремальность подхода в том, что применяется первое простое решение, что создает большой риск. В методологии практикуется парное программирование и групповая разработка. Целью такой методологии является создать с заказчиком максимально доверительные отношения и значительно сократить срок разработки продукта.
Главное в экстремальном программировании не утратить контроль над происходящим, чтобы разработка не превратилась в хаос.
Lean
(бережливая разработка ПО)
Это не совсем методология разработки программного обеспечения. Скорее, собранные в подход принципы, нацеленные на повышение эффективности разработки продукта и улучшения рабочих процессов. Главная задача этого подхода в том, чтобы сделать проект в три раза быстрее, в три раза дешевле и в три раза чище, чем можно было бы.
SCRUM
«SCRUM — это фреймворк управления, согласно которому одна или несколько кроссфункциональных самоорганизованных команд создают продукт инкрементами, то есть поэтапно. В команде может быть около семи человек».
«В SCRUM есть система ролей, встреч, правил и артефактов. В этой модели за создание и адаптацию рабочих процессов отвечают команды».
«В SCRUM используются итерации фиксированной длины, называемые Спринтами. Они обычно занимают 1-2 недели (до 1 месяца). SCRUM команды стремятся создавать готовый к поставке (качественно протестированный) Инкремент продукта в каждой итерации».
В СКРАМ три роли, которые вместе образуют SCRUM команду:
Владелец Продукта — апологет продукта, который полностью понимает его ценность для бизнеса. Этот человек доносит потребности кастомера/стейкхолдера до Команды разработки, но не отвечает за техническую сторону процесса. Владелец Продукта также отвечает за пользовательские истории и определяет их приоритетность.
Команда разработки выполняет все технические задачи по разработке. Команда кроссфункциональна и отвечает за анализ, дизайн, программирование, тестирование, техническую коммуникацию и т. д. В этом она руководствуется пользовательскими историями и их приоритетностью.
SCRUM-Мастер выступает фасилитатором работы СКРАМ команды. SCRUM-мастер помогает Владельцу Продукта и Команде разработки выполнять работу без препятствий и отвлекающих факторов. Вся коммуникация людей вне команды с Командой разработки проходит через SCRUM-Мастера. (Иногда СКРАМ команды взаимодействуют в формате SCRUMа SCRUMов, то есть собрания со SCRUM-мастерами каждой команды).
Артефакты scrum — это работы, которые надлежит сделать для завершения спринта. Они обеспечивают прозрачность проекта для всех участников.
Aртефакты Спринта и их компоненты включают:
Бэклог Продукта — все необходимые действия, связанные с пользовательской и технической сторонами проекта.
Бэклог Спринта — совокупность всех задач, которые нужно выполнить за итерацию спринта. Их выводят из Бэклога Продукта во время Планирования Спринта.
Инкремент — Инкремент представляет собой сумму всех элементов Бэклога Продукта, выполненных во время спринта, и ценность инкрементов всех предыдущих Спринтов. В конце спринта новый Инкремент должен быть «Готов», что означает его работоспособность и соответствие определению «Критериев Готовности» СКРАМ команды.
Элемент Бэклога Продукта — элемент Бэклога Продукта, который нужно выполнить за итерацию спринта. Обычно разбивается на несколько меньших подзадач.
Цель Спринта — то, что нужно сделать, чтобы выполнить элемент Бэклога Продукта.
Берн-даун чат Спринта — работа, которая остается до полного выполнения задач спринта. Берн-даун чат может быть восходящим или нисходящим в зависимости от того, с чем команда сталкивается при выполнении задачи. Он служит не отчетом о продвижении команды, а методом преодоления трудностей и поддержания активности.
Релиз Продукта/Берн-даун чат Продукта — его в конце каждого спринта обновляет СКРАМ-мастер. Горизонтальная ось соответствует спринтам, вертикальная — показывает, сколько работы (в начале каждого спринта) осталось до завершения проекта.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
TDD
TDD, test-driven development или процесс разработки через тестирование — это методология разработки программного обеспечения, которая основывается на повторении коротких циклов разработки: изначально пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволит пройти написанный тест, а затем проводится рефакторинг написанного кода с постоянной проверкой прохождения всех тестов.
FDD
Feature Driven Development (FDD) - это гибкая методология разработки программного обеспечения, появившаяся в 1980 году, в результате сотрудничества Джеффа Де Люка и Питера Кода, совместившая преимущества других гибких подходов таких как Scrum и eXtreme Programming с методами модели-ориентированных подходов.
В отличие от методологий Scrum и XP, которые ориентированы на небольшие команды разработки, FDD позволяет решать проблемы, возникающие в более крупных проектах.
Согласно FDD, вся работа на проекте разбивается на 5 процессов (см. Рисунок 8). В первую очередь, в рамках нулевой итерации, или как это называется в методологии FDD, первичной проектной деятельности реализуются три процесса: разработка общей модели, составление иерархического списка необходимых функций и оценка каждой функции с точки зрения трудозатрат и ответственных за реализацию.
Open UP
OpenUP — это итеративно-инкрементальный метод разработки ПО.
В основу OpenUP положены следующие основные принципы:
Совместная работа с целью согласования интересов и достижения общего понимания;
Развитие с целью непрерывного обеспечения обратной связи и совершенствования проекта;
Концентрация на архитектурных вопросах на ранних стадиях для минимизации рисков и организации разработки;
Выравнивание конкурентных преимуществ для максимизации потребительской ценности для заинтересованных лиц.
OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.
OpenUP делит проект на итерации: планируемые, ограниченные во времени интервалы, длительность которых обычно измеряется неделями. План итерации определяет, что именно должно быть сдано по окончании итерации, а результатом является работоспособная версия. Коллективы разработчиков OpenUP строятся по принципу самоорганизации, решая вопросы выполнения задач итераций и передачи результатов. Для этого они сначала определяют, а затем решают хорошо детализированные задачи из списка элементов работ.
Базовый процесс OpenUP является независимым от инструментов, малорегламентированным процессом, который может быть расширен для удовлетворения потребностей широкого диапазона типов проектов.
