Разработка ПО: методологии. Часть 2 OTUS
2026-03-10 23:13 Diff
https://otus.ru/journal/razrabotka-po-metodologii-chast-2/4-1-16/

Продолжаем разговор о методологиях разработки ПО. Начало здесь.

Итеративный подход

Это – самый подходящий вариант для тех, у кого есть общее представление об идее. Клиент не обязан понимать, какой конкретно контент он хочет получить на выходе. И предоставлять подробное техническое задание тоже нет никакой необходимости.

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

  1. Клиент поставил перед собой цель – запустить новый мессенджер. Разработчики составили приложение, в котором есть возможность добавления друзей и запуска чата на двоих.
  2. Проект выложили в магазин приложений для предоставления доступа клиентам. Целевая аудитория начала скачивать и активно пользоваться предложением.
  3. Заказчик понял, что программа пользуется спросом. Он решил ее доработать.
  4. Разработчики добавили дополнительный функционал: просмотр видео, загрузку изображений, аудиосообщения. Они постепенно улучшают мессенджер и адаптируют его к требованиям и инновациям рынка.

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

Преимущества

Среди условий, которые относятся к сильным сторонам модели, можно отнести:

  • скорость запуска проекта;
  • возможность проведения проверки на качество и популярность («выстрелит» он или нет);
  • постоянное тестирование пользователями, за счет которого удается оперативно обнаруживать и исправлять ошибки.

Если велик шанс провала проекта, можно оперативно получить фидбэк, а затем доработать ПО перед окончательным релизом.

Недостатки

Среди минусов такого приема выделяют следующие моменты:

  • экстремальная нагрузка при использовании во время коддинга на сервера;
  • применение на первых порах баз данных, требующих немалого времени на обработку;
  • отсутствие строго определенных сроков реализации;
  • нет фиксированного бюджета.

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

Спиральная модель

Начало ее положено в 1988 году. Во время реализации разработчики и заказчик проводят доскональный и серьезный анализ рисков ПО. Далее – осуществляют итерации. Следующая стадия базируется на предыдущей, а в конце каждого «витка» (итерационного цикла) будет приниматься решение относительно продолжения выпуска софта.

Выше – схема, которая объяснит принцип создания ПО «спиральным» подход. А чтобы лучше понять ее, стоит рассмотреть наглядный пример. В качестве него будет выступать система «Умный дом»:

  1. Человек задумался над созданием соответствующего продукта. Он заказал у программистов реализацию управления чайником посредством смартфонов.
  2. Программеры стали использовать модель «водопад»: послушали идею, проанализировали предложения на рынке, обговорили архитектуру, решили вопросы, связанные с реализацией оной. После – написали код, проверили его и продемонстрировали конечный результат.
  3. Заказчик оценил используемое ПО и риски: нужна ли клиентам другая версия, более совершенная. Пример – с управлением ТВ или компьютером.
  4. Заказчик провел расчет сроков и бюджета, после – заказал разработку.
  5. Программеры воспользовались «каскадом» и показали более сложный контент, в основе которого заложен первый созданный софт.
  6. Заказчик решил создать еще и функционал для управления холодильником со смартфона. Но оценка рисков показала, что это неоправданный ход. Вероятность неудачи превышает ожидаемый успех. За счет этого заказчик прекратил разработку и начал совершенствовать имеющийся функционал «Умного дома.

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

Преимущества

Сильных сторон у такой концепции не слишком много. Она подойдет тем, кто готов посвятить анализу немало времени и сил. На выходе получится ПО с минимальными рисками и предельным уровнем успеха.

Недостатки

Минусов у подхода больше, чем плюсов. Среди них выделяют:

  • вероятность на первых порах бесконечно дорабатывать первый релиз;
  • трудности при переходе к новым версиям ПО;
  • стоимость разработки;
  • сроки реализации.

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

Об Agile

При программировании можно воспользоваться всеми перечисленными способами. Но есть еще и Agile («эджайл») метод. В переводе с английского это – «гибкий».

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

Сюда относят:

  • экстремальное программирование (XP);
  • фреймворки для управления проектами Scrum;
  • бережную разработку ПО;
  • разработку путем тестинга;
  • методологии «чистой комнаты»;
  • создание ПО, управляемое функциональностью;
  • итеративно-инкрементальный подход (OpenUP);
  • методологию MSF;
  • метод создания систем динамического характера;
  • управление разработкой Kanban.

Не все перечисленные элементы – это гибкие методологии разработки. Пример – Scrum. Это фреймворк. Здесь прописаны все роли и процессы.

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

Scrum

Основа успеха – короткие ежедневные встречи, а также регулярные собрания. Они носят название Sprint (спринт). Каждый день команда обсуждает следующие вопросы:

  • составление отчета о проделанной работе с момента последнего Scrum;
  • задачи, которые необходимо выполнить каждому из участников группы до следующей «стычки»;
  • проблемы, возникающие в процессе разработки.

Идеальна для ПО с длительным жизненным циклом, адаптированным под рыночные требования.

Kanban

Это – часть Agile метода. Самая популярная из существующих методологий. Команде предстоит проводиться работу через виртуальную доску. Она разбита на этапы проекта. Каждый участник сможет увидеть, какие задачи находятся в работе, а какие «застопорились» на определенном этапе. Также удастся лицезреть то, какие шаги требуют особого внимания при дальнейшем релизе.

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

Лучше понимать рассмотренную тему помогут специализированные дистанционные компьютерные курсы. С их помощью пользователь, независимо от своего опыта в IT, сможет быстро освоить одно или несколько инновационных направлений, включая программирование мобильных и компьютерных игр. Программы рассчитаны на срок до года. В конце обучения будет выдан сертификат, подтверждающий знания и навыки в выбранном направлении.

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!