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

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

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

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

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

  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!