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

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

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

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

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

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

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

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

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

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

Подготовка.

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

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

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

Создание.

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

Поддержка.

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

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

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

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

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

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

Существует достаточно широкий ряд моделей разработки ПО:

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

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

На них остановимся, рассмотрим более подробно.

При выборе этой модели создание программного обеспечения происходит поэтапно, т.е. каждая стадия начинается по завершению предыдущей. Появилась давно - в 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,
✔️ итеративно-инкрементальный метод разработки.

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

Ценности Agile породили более 50 методологий, часть из них мы обозначили выше. Из большого списка Scrum является самой популярной. Рассмотрим пару наиболее популярных методологий.

Scrum

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

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

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

Kanban

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

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

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

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

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

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

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

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

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

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