Подходы к разработке программного обеспечения определяют успех проекта, ведь без правильно подобранной методологии сложно достичь стабильности в работе продукта, безопасности и устойчивости функциональных особенностей. Руководители проекта стараются найти оптимальный вариант из множества. Рассказываем вам о них.
Методология разработки ПО – это система, определяющая порядок выполнения задач, методы оценки и контроля. Модели разработки ПО выбирают, исходя из направления проекта, его бюджета, сроков реализации конечного продукта, а также внимание стоит обратить и на характер и темперамент руководителя проекта и его команды. Подходы разработки ПО отличаются друг от друга тем, как этапы жизненного цикла программного обеспечения взаимосвязаны между собой внутри цикла разработки.
Разработка программного обеспечения состоит из следующих этапов:
• определение стратегии: выяснение требований, оценка реализации этих требований, подсчитывание бюджета и определение возможности выполнения работ для клиента на взаимных условиях. Этот этап может происходить в цикле лишь один раз.
• анализ: исследование функций, которые определились на этапе стратегии, атрибутов и связей. Данный этап обычно происходит сразу после определения стратегии и может повторяться в цикле.
• проектирование – сбор модели данных.
• реализация: разработка продукта по требованиям, взаимодействие всей команды для достижения конечной цели, один из самых насыщенных этапов цикла разработки.
• тестирование. Этот этап может идти параллельно с фазой реализации. Происходит тестирование всего, что делают разработчики, работы продукта.
• внедрение. Зачастую продукт внедряется итерациями, чтобы сделать это более качественно, постепенно справляясь с багами и трудностями. На этапе внедрения вашим главным тестировщиком будет ваш клиент. Вся система выходит на полную мощность и начинает работать для своих пользователей.
• использование и техническая поддержка. Поддержание проекта на плаву, взаимодействие с клиентом, пользователями и так далее. Все зависит от условий работы над проектом.
Чередование этих этапов, взаимодействие между ними может меняться, исходя из выбранной вашим руководителем или вами модели процесса разработки ПО.
Давайте рассмотрим популярные подходы или образцы жизненного цикла программного обеспечения.
«Waterfall Model»
(также известна как каскадная модель или «водопад»)
Как известно, эту модель ПО относят к классике, так как она одна из самых первых моделей разработки ПО. Ее суть заключается в последовательном выполнении этапов жизненного цикла: анализ, дизайн, разработка, тестирование, релиз и поддержка. Каждая стадия должна быть завершена до начала новой. Преимуществом данной модели является то, что оценку качества можно выполнять после каждого этапа. Но сложно представить проект, который можно было бы реально выполнить строго последовательно. Поэтому модель часто считают устаревшей. Как к плюсам, так и к минусам можно отнести то, что при использовании данного подхода бюджет проекта и сроки его реализации точно определены. Также Водопад не дает делать шагов назад, что затрудняет тестирование, которое чаще всего осуществляется в конце разработки продукта. Получается, что последующие изменения будут значительно увеличивать бюджет и затягивать релиз проекта. Такую модель советуем использовать только на маленьких проектах, где точно не возникнет противоречий с требованиями. Каскадная модель не совсем совместима с разработкой ПО.
«Agile Model»
(или гибкая модель разработки ПО)
В такой модели все этапы жизненного цикла бывают выполнены в течение одной итерации и готовы к внесению любых изменений. То есть ваш проект делится на спринты – отрезки времени, за которые должен быть получен результат, обычно от одной до четырех недель. В каждом спринте есть свой список задач, который должен быть выполнен к концу итерации, каждая из задач имеет свой уровень оценки. Отличается подход ежедневными встречами – «Scrum», на которых команда обсуждает, кто что сделал, что собирается сделать и какие есть проблемы. Помимо этого, в начале спринта проводится встреча по планированию задач на итерацию, а в конце – ретроспективная встреча для обсуждения результатов.
Методологию стоит применять, когда ваш проект постоянно адаптируется к условиям рынка, имеет большой объем и длинный жизненный цикл. Если вы творческий руководитель с миллионом новых идей, которые постоянно тестируете, то этот подход разработки точно для вас.
Agile Model имеет два отдельных гибких подхода:
1. «Scrum»
(итерационная модель разработки ПО или «водоворот»)
Поскольку данная модель выделилась из Agile, она состоит из того же, что и Agile model. В таком подходе в команде часто появляется Scrum-мастер, который обеспечивает непрерывную работу все команды, создавая для нее все условия: поддерживая мотивацию, организовывая процедуры, фасилитирует митинги. Также на проекте появляется роль Product Owner – человек, который руководит разработкой, следит за продуктом, как BA, выступает главным звеном между миссией клиента и результатом команды.
Такая система подойдет проектам до десяти человек. Но мы бы не назвали подход эффективным, потому как требования обычно неизвестны на 50%, все постоянно меняется, так как изменения можно вносить на любом этапе разработки: весьма трудно понять затраты на разработку.
2. «Kanban»
(с японского переводится, как «карточка»)
Данный подтип разработки отличается своей визуализацией жизненного цикла. Команда ориентируется на выполнение задач, которые сдаются индивидуально: задача должна пройти через все колонки – To do, In progress, Code review, In testing, Done (колонки могут быть изменены в индивидуальном порядке). Цель каждого участника команды – уменьшать количество задач в первой колонке. Данный наглядный подход позволяет понять, где возникла проблема – бутылочное горлышко, а также просто видеть организацию всего проекта.
«V-Model»
(«шаг за шагом» или validation and verification)
Модель разработки ПО ориентирована на то, чтобы детально проверять и тестировать продукт на первых стадиях разработки. Уже в момент написания кода разработчиками тестировщики пишут модульные тесты, то есть начинают тестирование параллельно с разработкой. Рекомендуется придерживаться данного подхода, если вам крайне важно бесперебойное функционирование продукта, а также известны четкие требования. V-Model относят к практикам экстремального программирования.
RAD
(известная как rapid application development, быстрая разработка приложений, инкрементальная модель)
Такая модель подразделяется на несколько циклов, которые составляют жизненный цикл ПО – «мульти-водопад». В каждом цикле есть свои модули, которые проходят через этапы: сначала определения требований, затем проектирования, после кодирования, тестирования и внедрения. Получается, что данная модель подразумевает, что на первом этапе будут выпущены основные функции, а последующие циклы позволят добавлять новые дополнения. Процесс закончится только после полной имплементации системы. Использовать инкрементальную модель стоит только тогда, когда требования кристально ясны, одновременно возможно внедрение дополнительных фич. Лучшим подходом будет именно этот в случае, если вы обладаете рисковыми нововведениями, и продукт нужно максимально быстро вывести на маркет. Отметим и то, что благодаря постепенной интеграции функций, ваш проект будет дешевле, чем мог бы быть при другой модели, и с меньшими рисками.
Spiral
(спиральная модель)
Данная модель направлена на анализ оценки рисков. И отлично подойдет там, где нет права на ошибку. Также ее удобно использовать для введения новых линеек продукта и проведения исследований. Выглядит эта модель, как спираль, так как начинает оценивать риски сначала на локальных программах, пытаясь предотвратить риски, далее переходит на новый виток спирали, перенаправляясь к работе с более комплексными тасками. Чаще всего мы проходим такие этапы, как: планирование, анализ рисков, конструирование, оценку результата – так, если он удовлетворяет, мы переходим на новый виток.
Подход разумнее использовать на больших и дорогих проектах.
Extreme Programming
(экстремальное программирование, XP)
Extreme Programming считается неформальным подходом разработки ПО, где каждый разработчик – профессионал своего дела. Если же отношение меняется, то внедрять методологию бесполезно. Разработка продукта ведется короткими итерациями. Экстремальность подхода в том, что применяется первое простое решение, что создает большой риск. В методологии практикуется парное программирование и групповая разработка. Целью такой методологии является создать с заказчиком максимально доверительные отношения и значительно сократить срок разработки продукта.
Главное в экстремальном программировании не утратить контроль над происходящим, чтобы разработка не превратилась в хаос.
Lean
(бережливая разработка ПО)
Это не совсем методология разработки программного обеспечения. Скорее, собранные в подход принципы, нацеленные на повышение эффективности разработки продукта и улучшения рабочих процессов. Главная задача этого подхода в том, чтобы сделать проект в три раза быстрее, в три раза дешевле и в три раза чище, чем можно было бы.
В Lean есть семь принципов, которые помогают достичь цели:
• Eliminate waste;
• Amplify learning;
• Decide as late as possible;
• Deliver as fast as possible;
• Enpower the team;
• Build integrity in;
• See the whole.
Мы познакомили вас с основными моделями разработки программного обеспечения. Нельзя сказать, какая из них подойдет больше вашему проекту. Вы должны выбрать оптимальную сами. Многие из них пересекаются между собой, возможно, вам придется попробовать несколько, прежде чем, вы найдете ту, которая приведет ваш проект к успеху и сделает работу продуктивнее.
