Александр Юркин

Директор по развитию бизнеса, глава спец. проектов: аутстафф/аутсорс
✉️: ay@leantech.ai
06.12.2022

Как методологии разработки программного обеспечения влияют на запуск IT-проекта?

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

В этой статье рассмотрим методологии разработки программного обеспечения и под какие задачи бизнеса они подходят.

Начнем с того, что именно представляет собой ПО.

Что такое программное обеспечение?

Программное обеспечение - то, что позволяет нам (обычным пользователям) выполнять любые действия с компьютером. Взаимодействие любого пользователя с компьютером без ПО невозможно.

Например, без интернет-браузера (Google Chrome, Yandex и т.д.) никто не смог бы пользоваться интернетом. А без операционной системы (Windows, Android, macOS и др.) невозможна работа интернет-браузера.

Здесь два примера программного обеспечения: интернет-браузер и операционная система. Интернет-браузер также - программа, а ОС при этом - нет. Таким образом, все программы - это ПО, но не все ПО - программы.

Когда есть цель - разработать проект программного обеспечения, как это сделать? Как происходит процесс?

Этапы разработки и жизненного цикла ПО

Каждое ПО проходит определенный порядок этапов с момента создания до окончания внедрения. Стандартный цикл: подготовительный этап, проектирование, разработка (создание) и поддержка.
Этапы и методологии разработки программного обеспечения><meta itemprop=
Этапы разработки проекта программного обеспечения
Теперь рассмотрим эти процессы на примере создания приложения для онлайн покупок и доставки продуктов для сети продуктовых магазинов.

Подготовка.

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

Проектирование.

Руководители выбрали компанию-подрядчика для создания программного обеспечения и обсудили архитектуру и дизайн будущего IT-продукта с ее специалистами.

Создание.

Руководители сети магазинов заключили договор с разработчиками. Специалисты запустили кодирование, начали отрисовывать дизайн и составлять необходимую документацию.

Поддержка.

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

Так выглядит стандартный процесс разработки проекта программного обеспечения.

Кроме того, есть еще два понятия: модель и методология разработки ПО. Что это такое и в чем разница?

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

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

Далее - расскажем подробнее о популярных моделях разработки ПО, их плюсах и минусах.

Модели разработки ПО

Существует достаточно широкий ряд моделей разработки ПО:
  • модель кодирования и устранения ошибок (Code and fix),
  • каскадная модель или "водопад" (Waterfall),
  • V-образная модель - разработка через тестирование (V-model),
  • инкрементная модель (Incremental Model),
  • итеративная или итерационная модель (Iterative Model),
  • спиральная модель (Spiral Model),
  • прототипная модель (Prototype Model) и др..

Из этого ряда наиболее популярные:
✔️ каскадная,
✔️ V-образная,
✔️ инкрементная,
✔️ итерационная
✔️ и спиральная.

На них остановимся, рассмотрим более подробно.
Популярные модели и методологии разработки программного обеспечения
Виды популярных моделей разработки ПО по данным ScienceSoft

"Водопад" - каскадная модель (Waterfall)
При выборе этой модели создание программного обеспечения происходит поэтапно, т.е. каждая стадия начинается по завершению предыдущей. Появилась давно - в 1970-х годах. Зачастую наиболее быстрая и простая в применении.

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

✔️ Простой контроль. Заказчик всегда в курсе, что именно выполняют разработчики в конкретный момент, и имеет возможность управлять стоимостью и сроками разработки.

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

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

Недостатки

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

Возможность посмотреть готовый IT-продукт заказчику только в конце разработки. Это нередко влечет несоответствие ожиданиям и, соответственно, неудовлетворенность заказчика.

Увеличенные сроки из-за большого количества технической документации. Чем больше масштаб проекта и объем необходимой документации, тем больше корректировок необходимо вносить, тем дольше происходит их согласование.

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

V-образная модель - через тестирование (V-model)
Данная модель - усовершенствованная версия каскадной. Здесь заказчик с командой разработчиков составляют ряд требований к системе одновременно, описывают, как будет происходить тестирование на каждом этапе. Появилась данная модель разработки в начале 1980-х гг.

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

✔️ Сведение к минимуму количества ошибок в архитектуре ПО.

Недостаток

Высокая стоимость исправления допущенной ошибки при разработке архитектуры (как и в каскадной модели).

V-образная модель подходит разработке тех продуктов, для которых важна надежность - например, системы видеонаблюдения в сфере медицины и здравоохранения.

Инкрементная модель (Incremental model)
Основная суть этой модели - разработка по частям. Появилась она в 1930-е годы. Разберем ее принцип на практическом примере - разработке мессенджера. ❕
1
Некто (заказчик) принял решение, что желает создать и запустить собственный мессенджер, и написал техническое задание. Команда разработчиков предложили реализацию базовых функций: страницу профиля пользователя и чат непосредственно для общения, а потом - протестировать, чтобы понять "зайдет или нет".
2
Разработчики демонстрируют продукт заказчику и делают релиз (выпуск на рынок). В случае удовлетворенности заказчика и пришедших пользователей дальнейшая работа продолжается по частям.
3
IT-шники занимаются одновременным созданием согласованной с заказчиком функциональности: загрузка фото, обмен файлами и т.д. Они пошагово совершенствуют мессенджер, тем самым приближаясь к обозначенному в техническом задании продукту.
Преимущества

✔️ Экономный старт. В самом начале заказчик платит только за разработку базовых функций, и сразу имеет возможность получить продукт и протестировать его запуск на рынке.

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

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

Недостаток

❌ Возможные расхождения в разработке функциональности разными специалистами (различия в интерфейсе). Здесь важно в самом начале обсудить и обозначить, каким именно он будет, для достижения единого понимания и представления.

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

Итеративная или итерационная модель (Iterative Model)
При использовании данной модели, заказчику необязательно понимать, что именно он хочет получить в конечном результате. Соответственно, нет необходимости писать детальное техническое задание для разработчиков.

Вернемся к примеру разработки мессенджера. Процесс его создания по итеративной модели выглядит следующим образом. ⬇️
1
Заказчик принял решение о создании продукта в виде мессенджера, обратился к компании-подрядчику. Специалисты компании разработали приложение с возможностью для пользователей добавлять друг друга и запускать чат на двух человек.
2
Приложение запустили на рынок - в магазин приложений для тестирования. Пользователи (целевая аудитория) начали скачивать и использовать, т.е. продукт начал пользоваться популярностью, поэтому заказчик принял решение о его доработке.
3
Разработчики добавили функции просмотра видео, загрузки фото, записи аудиосообщений. Функциональность приложения улучшается и адаптируется к требованиям аудитории и рынка постепенно.
Преимущества

✔️ Быстрый запуск MVP (минимального продукта) позволяет в сжатые сроки получать фидбэк от заказчика и пользователей, следовательно, концентрироваться только на самых важных функциях ПО, корректировать и улучшать их в соответствии с требованиями рынка этой сферы и пожеланиями заказчика.

✔️ Непрерывное тестирование аудиторией делает возможным оперативно обнаруживать и устранять допущенные ошибки.

Недостатки

Использование на старте баз данных усложняют возможность дальнейшего масштабирования.

Использование серверов (вместо баз данных) не позволяют выдерживать высокую нагрузку.

Эти два момента способствуют риску переписывания большей части приложения.

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

Для разработки масштабных проектов с неопределенными требованиями или для проектов с инновационным подходом (когда у заказчика нет уверенности в конечном результате) хорошо подходит итеративная модель.

Спиральная модель (Spiral Model)
При выборе данной модели команда разработчиков проводит тщательный анализ рисков проектов, а создание программного обеспечения производится пошагово. Каждый последующий этап основывается на предыдущем. В конце каждого "витка" (цикла шагов) принимается решение о том, целесообразно ли продолжать работу над IT-проектом. Данная модель появилась в конце 1980-х гг.

Схема разработки по данной модели представлена ниже.
Модели и методологии разработки программного обеспечения. Спиральная модель.
Спиральная модель разработки ПО
На примере создания системы для автоматизации бизнес-процессов внутри компании рассмотрим принцип функционирования данной модели. Подробнее о том, что такое ERP-система, уже рассказали в статье здесь.
1
Заказчик принял решение о создании системы для управления своим бизнесом, но не понимал, работу каких именно отделов желает оптимизировать, оформил заказ у компании-подрядчика. Команда специалистов начала работать по каскадной модели, разработали базовое ПО для оптимизации процессов одного из отделов (например, отдел кадров).
2
Проведена оценка результата и рисков заказчиком. Рассчитаны сроки, бюджет и заказана новая разработка для автоматизации процессов в отделе бухгалтерии. Разработчики создали новый продукт на базе первого. Заказчик провел анализ, принял решение скорректировать поставленные изначально задачи и оптимизировать процессы в максимально возможном количестве отделов компании (отдел продаж, отдел производства).
3
Команда разработчиков создала систему, оптимизирующую бизнес-процессы остальных отделов, на базе предыдущих. Заказчик протестировал, провел анализ. Разработка завершена.
Спиральная модель схожа с инкрементной, т.к. вся работа проводится пошагово, но здесь намного больше времени тратится на анализ рисков. С каждым витком процесс усложняется.

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

✔️ Тщательная проработка рисков.

Недостатки

Риск остановиться на первом этапе разработки.

Большие временные затраты.

Высокая стоимость.

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

Помимо перечисленных моделей разработки, популярно в настоящее время развертывание DevOps.

Развертывание DevOps как подход в разработке ПО

DevOps означает разработку ПО (Dev - development) и IT-операции (Ops - operations). Основа этого подхода в объединении двух сторон создания IT-продукта - разработки ПО и улучшения процессов в единое целое.

Здесь команда специалистов работает над проектом пошагово, при этом фокусируется на автоматизации процессов, прозрачности процессов и оперативной обратной связи.

Такой подход позволяет оптимизировать ✔️ скорость разработки, сохраняя ✔️ высокое качество, ✔️ согласованность и ✔️ надежность.

На данный момент DevOps активно применяется в сферах финтеха и телекоммуникаций.

Подробнее об услуге DevOps от нашей команды LeanTech рассказано здесь.

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

Agile: модель или методология?

Ввиду того, что в каждой модели после появления обнаружены определенные недостатки (по каждой модели мы их рассмотрели выше), поиски оптимальных решений продолжались. Принципы работы по каждой модели комбинировали, корректировали. Так и появился термин Agile.

Agile не относится ни к моделям, ни к методологиям разработки программного обеспечения. Это скорее подход к разработке.

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

К Agile относятся:
✔️ методология "чистой комнаты",
✔️ методология разработки Microsoft Solutions Framework - MSF,
✔️ экстремальное программирование,
✔️ Scrum - фреймворк для управления проектами,
✔️ разработка через тестирование,
✔️ бережливая разработка ПО,
✔️ FDD - разработка, управляемая функциональностью,
✔️ метод управления разработкой Kanban,
✔️ метод разработки динамических систем - DSDM,
✔️ итеративно-инкрементальный метод разработки.

Особенности Agile
Гибкий подход отличается:
✔️ адаптивностью,
✔️ высокой вовлеченностью заказчика,
✔️ возможностью доработки документации по мере развития проекта,
✔️ легко изменяемыми требованиями,
✔️ стабильным составом опытных специалистов в команде,
✔️ невысокой стоимостью изменения кода при необходимости.
Место Agile среди моделей и методологий разработки программного обеспечения
Agile среди моделей и гибких методологий разработки программного обеспечения
Ценности Agile породили более 50 методологий, часть из них мы обозначили выше. Из большого списка Scrum является самой популярной. Рассмотрим пару наиболее популярных методологий.

Популярные гибкие методологии разработки программного обеспечения

Scrum

Здесь при разработке определяется Scrum-мастер, обеспечивающий непрерывную работу всей команды разработчиков, создавая необходимые условия (мотивация, проведение встреч и т.д.). Также выделяется роль руководителя разработки - он следит за продуктом, выступает главным звеном между заказчиком и командой.

Scrum подходит для проектов, включающих до 10 человек.

Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы четко прописаны. Помимо Scrum, часто используют Kanban.

Kanban

В переводе с японского - карточка. Отличие в визуализации цикла разработки. Специалисты ориентируются на выполнение задач, которые нужно сдавать в индивидуальном порядке. Цель каждого специалиста в команде - минимизировать количество задач в списке "выполнить" (еще не начатых).

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

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

Теперь поясним, как добиться бизнесу (заказчику разработки) наиболее эффективного контроля процесса создания программного обеспечения, т.е. желаемого IT-продукта.

Самое важное ❗️❗️❗️

Методов разработки ПО много, выбор зависит от особенностей (целей, задач и т.д.) конкретного заказчика или бизнеса.

  • Каскадная модель (водопад) подходит в тех случаях, где есть четкие требования и техническое задание, а также уверенность, что они не будут меняться в процессе создания продукта.

  • Для инновационных проектов, где уровень непредсказуемости высок, более удачным станет выбор одного из гибких методов, т.к. они позволяют оперативно реагировать на необходимые изменения и производить их.

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


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

Наша команда специалистов с 2014 года помогает своим заказчикам реализовывать свои идеи и задумки в сфере IT.

Делаем так, чтобы заказчику было максимально комфортно контролировать весь процесс, и все этапы были прозрачными.

Наши кейсы можно посмотреть здесь.