Модели разработки ПО: минусы и плюсы

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

Давайте рассмотрим основные модели.

  1. Каскадная или водопадная модель.

Суть каскадной модели в том, чтобы все делалось строго пошагово, как показано в примере на схеме:

Программисты начинают свою работу только после формулировки требований, а тестировщики — после того, как работа программистов окончена.

Эта модель довольно проста: ее легко контролировать, планировать бюджет. Однако на разработку уходит много времени, а то, что тестирование происходит в самом конце, может привести к позднему обнаружению ошибок и долгому их исправлению.

  1. V-модель — по сути продвинутая водопадная:

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

V-модель сохранила все плюсы своего предшественника. А еще улучшилось качество, ведь теперь тестирование происходит сразу на каждом этапе, и не нужно ждать завершения проекта. Минусы этой модели такие же, как и у каскадной.

  1. Инкрементная модель.

В этом варианте с каждым релизом в проекте появляются какие-то новые доработки, а тестирование проводится при каждой новой итерации. 

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

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

Из минусов — достичь конечной цели можно будет нескоро. А еще это может быть дорого и сложно спланировать.

  1. Эволюционная модель.

В отличие от инкрементной при такой модели нет технического задания сразу на весь продукт. Функции наращиваются постепенно. 

В примере ниже — создание соцсети Facebook.  Изначально у Марка Цукерберга была компактная идея: общение между студентами. Все остальные функции добавлялись по ходу эволюции продукта:

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

Главные минусы: управлять такой разработкой сложно, а множество идей иногда приводит к хаосу.

На  курсе Аудит и оптимизация QA-процессов мы подробно разбираем модели и методологии разработки ПО, а наши студенты примеряют их на свои проекты. 

Вот вопрос от студентки курса:

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

Отвечает Людмила Лихогляд – сотренер курса и тест-менеджер с 11-летним опытом:

Людмила Лихогляд

— Добрый день! Вы правы в своих выводах. Действительно, не так часто можно встретить абсолютно чистую ту или иную модель. Со временем ПО переходит на новые этапы, и тогда закономерен переход от одной модели к другой.

Более подробно о процессах в QA и  о том, как выявлять зоны риска и причины проблем в вашем проекты, мы говорим на курсе «Аудит и оптимизация QA-процессов».

Полная программа курса – по ссылке. Старт 19 августа!

Отзывы выпускников курса:

Олеся П.: Дельный курс. Легкая подача нелегкого материала. Отличные домашние задания, которые реально использовать на практике для улучшения ситуации на проекте. Рекомендую!

Карина А.: Курс однозначно помог! Мы стали использовать Jira как основной инструмент сбора показателей эффективности и качества реализации задач. Также на данный момент мы находимся в процессе деления на продуктовые команды, после чего собираемся внедрять метрики качества для измерения прогресса.

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Метки
css (1)html (1)ISTQB FL (9)IT (2)Java для тестировщиков (1)Jedi Point (32)JSON (1)kaizen (2)Pairwise Testing (1)QA (25)REST API (1)selenium (1)SOAP UI (1)softskills тестировщика (9)SQA Days-25 (1)SQL в тестировании (7)TestSuites (1)XML (1)xpath (1)Анна Палей (1)Исследовательское тестирование (4)История успеха (21)Курс тестирования для начинающих (47)Мнемоники в тестировании (1)Наталья Руколь (3)Нина Агеева (6)Обучение тестированию (24)ПОИНТ (79)Роман Буданов (5)Сессионное тестирование (1)ТЗ (1)Таблица решений (1)Тест-анализ (5)Тест-дизайн (8)Тест-кейс (2)Тест-стратегия (1)Тест-туры (1)Тестирование usability (8)Тестирование ПО (44)Тестирование игр (5)Тестирование мобильных приложений (18)Тест менеджмент (6)Чек-лист в тестировании по (6)Чит-лист в тестировании (3)автоматизация тестирования (3)автотесты (1)английский для тестировщиков (12)аудит проекта (13)баг (3)багнапродакшене (1)введение в тестирование (2)виды тестирования (4)войти в айти (15)выгорание (2)граничные значения (1)гуманитарии в тестировании (1)декомпозиция (1)инструменты тестирования по (6)интервью с выпускником (25)как надо тестировать (3)как стать тестировщиком (6)клиент-серверная архитектура (1)комбинаторика в тестировании (1)мануальное тестирование (1)метрики тестирования (5)начать карьеру в IT (27)начинающий тестировщик (40)негативное тестирование (2)ограничения (1)оптимизация QA-процессов (4)организация тестирования (1)персонажи (1)планирование тестирования (1)профессия тестировщик (10)работа в QA (2)расписание (6)резюме (1)релокация (3)ручное тестирование (1)сертификация ISTQB FL (7)скринкаст (1)смена работы (28)создание и управление командой тестирования (4)сопроводительное письмо (1)тайм-менеджмент (1)тест-кейс (1)тест-менеджмент (10)тестирование безопасности (1)тестирование без требований (5)тестирование веб (24)тестовая стратегия (1)удаленная работа (5)управление требованиями (6)фреймворк тестирования (1)школа тест-аналитика (2)школа тест-менеджера (10)юзабилити (3)
С 23.08 по 10.11, ОНЛАЙН Зарегистрироваться