Методологии разработки.

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

Определение стратегии.
Анализ.
Проектирование.
Реализация.
Тестирование.
Внедрение.
Использование и техническая поддержка.

Waterfall Model (также известна как каскадная модель или «водопад»).

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

Как к плюсам, так и к минусам можно отнести то, что при использовании данного подхода бюджет проекта и сроки его реализации точно определены. Также Водопад не дает делать шагов назад, что затрудняет тестирование, которое чаще всего осуществляется в конце разработки продукта.

Model («шаг за шагом» или validation and verification).

Модель разработки ПО ориентирована на то, чтобы детально проверять и тестировать продукт на первых стадиях разработки. Уже в момент написания кода разработчиками тестировщики пишут модульные тесты, то есть начинают тестирование параллельно с разработкой. Рекомендуется придерживаться данного подхода, если крайне важно бесперебойное функционирование продукта, а также известны четкие требования. V-Model относят к практикам экстремального программирования.

RAD (rapid application development, быстрая разработка приложений, инкрементальная модель).

Такая модель подразделяется на несколько циклов, которые составляют жизненный цикл ПО — «мульти-водопад». В каждом цикле есть свои модули, которые проходят через этапы: сначала определения требований, затем проектирования, после кодирования, тестирования и внедрения. Получается, что данная модель подразумевает, что на первом этапе будут выпущены основные функции, а последующие циклы позволяют добавлять новые дополнения. Процесс закончится только после полной имплементации системы. Использовать инкрементальную модель стоит только тогда, когда требования кристально ясны, одновременно возможно внедрение дополнительных фич.

Лучшим подходом будет именно этот в случае, если тестировщик обладает рисковыми нововведениями, и продукт нужно максимально быстро вывести на маркет. Отметим и то, что благодаря постепенной интеграции функций, проект будет дешевле, чем мог бы быть при другой модели, и с меньшими рисками.

Spiral (спиральная модель).

Данная модель направлена на анализ оценки рисков. И отлично подойдет там, где нет права на ошибку. Также ее удобно использовать для введения новых линеек продукта и проведения исследований. Выглядит эта модель, как спираль, так как начинает оценивать риски сначала на локальных программах, пытаясь предотвратить риски, далее переходит на новый виток спирали, перенаправляясь к работе с более комплексными тасками.

Этапы:

Планирование.
Анализ рисков.
Конструирование.
Оценка результата (так, если он удовлетворяет, идет переход на новый виток. Подход разумнее использовать на больших и дорогих проектах).

Extreme Programming (экстремальное программирование, XP).

Считается неформальным подходом разработки ПО, где каждый разработчик — профессионал своего дела. Если же отношение меняется, то внедрять методологию бесполезно. Разработка продукта ведется короткими итерациями. Экстремальность подхода в том, что применяется первое простое решение, что создает большой риск. В методологии практикуется парное программирование и групповая разработка. Целью такой методологии является создать с заказчиком максимально доверительные отношения и значительно сократить срок разработки продукта. Главное в экстремальном программировании не утратить контроль над происходящим, чтобы разработка не превратилась в хаос.

Agile (гибкая модель разработки ПО).

В такой модели все этапы жизненного цикла бывают выполнены в течение одной итерации и готовы к внесению любых изменений. То есть проект делится на спринты — отрезки времени, за которые должен быть получен результат, обычно от одной до четырех недель. В каждом спринте есть свой список задач, который должен быть выполнен к концу итерации, каждая из задач имеет свой уровень оценки. Отличается подход ежедневными встречами — «Scrum», на которых команда обсуждает, кто что сделал, что собирается сделать и какие есть проблемы. Помимо этого, в начале спринта проводится встреча по планированию задач на итерацию, а в конце — ретроспективная встреча для обсуждения результатов.

Методологию стоит применять, когда проект постоянно адаптируется к условиям рынка, имеет большой объем и длинный жизненный цикл.

Scrum (итерационная модель разработки ПО или «водоворот»).

Поскольку данная модель выделилась из Agile, она состоит из того же, что и Agile model. В таком подходе в команде часто появляется Scrum-мастер, который обеспечивает непрерывную работу все команды, создавая для нее все условия: поддерживая мотивацию, организовывая процедуры, фасилитирует митинги. Также на проекте появляется роль Product Owner — человек, который руководит разработкой, следит за продуктом, выступает главным звеном между миссией клиента и результатом команды.

Такая система подойдет проектам до десяти человек. Подход не считается эффективным, потому как требования обычно неизвестны на 50%, все постоянно меняется, так как изменения можно вносить на любом этапе разработки: весьма трудно понять затраты на разработку.

Kanban (с японского переводится, как «карточка»).

Данный подтип разработки отличается своей визуализацией жизненного цикла. Команда ориентируется на выполнение задач, которые сдаются индивидуально: задача должна пройти через все колонки — To do, In progress, Code review, In testing, Done (колонки могут быть изменены в индивидуальном порядке). Цель каждого участника команды — уменьшать количество задач в первой колонке. Данный наглядный подход позволяет понять, где возникла проблема — бутылочное горлышко, а также просто видеть организацию всего проекта.

Lean (бережливая разработка ПО).

Это не совсем методология разработки программного обеспечения. Скорее, собранные в подход принципы, нацеленные на повышение эффективности разработки продукта и улучшения рабочих процессов. Главная задача этого подхода в том, чтобы сделать проект в три раза быстрее, в три раза дешевле и в три раза чище, чем можно было бы.

Подходы к разработке / тестированию (… — driven development / testing).

Тут и там можно встретить упоминания различных подходов к разработке и тестированию на основе чего-то, здесь краткое описание самых часто встречающихся вариантов:

TDD — Test Driven Development: разработка на основе тестов основывается на повторении коротких циклов разработки: изначально пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволит пройти написанный тест. Затем проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов. Есть два уровня TDD:

Acceptance TDD (ATDD): написан один приемочный тест. Этот тест удовлетворяет требованиям спецификации или удовлетворяет поведению системы. После этого пишете достаточно производственного / функционального кода, чтобы выполнить этот приемочный тест. Приемочный тест фокусируется на общем поведении системы. ATDD также известен как BDD — Behavior Driven Development.

Developer TDD: тестировщик пишет один тест разработчика, то есть модульный тест, а затем просто достаточно производственного кода для выполнения этого теста. Модульное тестирование фокусируется на каждой небольшой функциональности системы. Это называется просто TDD. Основная цель ATDD и TDD — определить подробные, выполнимые требования для решения точно в срок (JIT). JIT означает принятие во внимание только тех требований, которые необходимы в системе, что повышает эффективность.

BDD — Behaviour Driven Development: это разработка, основанная на описании поведения. Определенный человек (или люди) пишет описания вида «я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке» (там есть специально выделенные ключевые слова). Программисты давно написали специальные тулы, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). А дальше классическая разработка с тестами (TDD).
TDD — Type Driven Development: при разработке на основе типов данных и сигнатуры типов являются спецификацией программы. Типы также служат формой документации, которая гарантированно обновляется. Типы представляют из себя небольшие контрольные точки, благодаря которым, получается множество мини-тестов по всему нашему приложению.
DDD — Domain Driven Design: Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Это набор принципов и схем, направленных на создание оптимальных систем объектов. Процесс разработки сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.
FDD — Features Driven Development: представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в установленные сроки.
MDD — Model Driven Development: разработка, управляемая моделями — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты.
PDD — Panic Driven Development: это своеобразный антипаттерн разработки. По сути это то, что получается, когда процессы плохо налажены и команда импровизирует в условиях горящих сроков (новые задачи приоритетнее старых, код решает конкретные срочные задачи, но копится технический долг, тестирование в конце и т.д.).
ADD — API Driven Development: разработка на основе API — это практика сначала проектирования и создания API, а затем создания на их основе остальной части приложения.
BDT — Behavior Driven Testing: в тестировании на основе поведения, тесты основаны на user stories, которые описывают некоторые конкретные ожидаемые действия приложения. Вместо проверки деталей реализации фактически проверяется то, что важно больше всего: правильно ли приложение выполняет user stories. Еще одним преимуществом является понятность тестов для менеджеров, аналитиков и т.п.
MDT — Model Driven Testing: Тестирование на основе моделей — это метод тестирования черного ящика, при котором поведение тестируемого программного обеспечения во время выполнения проверяется на основе прогнозов, сделанных моделями. Модель — это описание поведения системы. Поведение может быть описано в виде наглядной схемы, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines или mind map. Простой аналогией модели в тестировании является электрическая схема при разработке электроприбора. Этот подход к тестированию требуется, когда высока цена ошибки в большом продукте и нужно как можно раньше попытаться ее предотвратить.
DDT — Data Driven Testing (table-driven testing or parameterized testing): в тестировании на основе данных тестовые данные хранятся в виде таблицы. Оно позволяет одним скриптом выполнять тесты для всех тестовых данных из таблицы и ожидать результатов теста в той же таблице.
VDT — Value Driven Testing: тестирование на основе ценности — это подход, в основе которого лежит анализ ценности и экономической целесообразности тестирования.