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

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

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

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

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

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

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

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

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

Теперь рассмотрим эти процессы на примере создания приложения для онлайн покупок и доставки продуктов для сети продуктовых магазинов.

Подготовка.

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

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

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

Создание.

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

Поддержка.

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

Недостаток

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

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

Основная суть этой модели - разработка по частям. Появилась она в 1930-е годы. Разберем ее принцип на практическом примере - разработке мессенджера. ❕

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

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

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

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

Недостаток

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

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

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

Вернемся к примеру разработки мессенджера. Процесс его создания по итеративной модели выглядит следующим образом. ⬇️

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

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

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

Недостатки

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

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

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

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

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

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

Схема разработки по данной модели представлена ниже.

На примере создания системы для автоматизации бизнес-процессов внутри компании рассмотрим принцип функционирования данной модели. Подробнее о том, что такое ERP-система, уже рассказали в статье здесь.

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

Если желаете задать какие-то вопросы о нашей услуге DevOps, то нажмите кнопку ниже.

На основе уже упомянутой итеративной модели появилось понятие Agile.

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

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

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

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

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

Scrum

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

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

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

Kanban

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

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

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

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

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

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

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

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

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

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