Разработка программного обеспечения — это стандартизированный комплексный процесс, который проходит множество этапов в течение порой длительного времени. Одним из важнейших этапов жизненного цикла ПО являются первые шаги, а именно — подбор методологии разработки и правильное планирование приоритетов на старте. По сути, именно от этого выбора во многом зависит дальнейший успех проекта. Эта статья поможет подобрать оптимальный вариант в большинстве ситуаций.
Содержание:
1. Этапы жизненного цикла ПО
2. Основные модели разработки ПО
3. Что такое Agile и Lean: принципы разработки ПО
Разработка программного обеспечения — сложный многоступенчатый процесс. Нельзя так просто взять и создать современное приложение. Сначала придумывается идея и концепция, ищутся инвестиции, подбирается команда, составляется список функций, которыми должна обладать конечная программа, подбирается визуальный стиль и так далее. Этот процесс включает в себя множество обязательных этапов, некоторые из которых могут проходить параллельно, в зависимости от сложности и глубины проекта.
Более того, даже после первоначального выпуска продукта в свет работа над ним не заканчивается. К примеру, всем известное веб-приложение Instagram сначала существовало только в головах создателей как идея объединения любителей мобильной фотографии в единую социальную сеть, лишенную прочих атрибутов
Жизненный цикл разработки программного обеспечения
Этапы, описываемые циклом разработки, также являются для начинающих создателей ПО своеобразной шпаргалкой. Ведь именно вдумчивое прохождение каждого шага, без перескакиваний и спешки, позволит на выходе получить качественный и экономически выгодный продукт, чтобы довольными остались и потребители, и заказчики, и разработчики.
Основные модели разработки ПО
Остановимся на каждом из них подробнее.
Один из самых важных этапов разработки ПО, на котором принимаются главные решения. Когда у человека есть идея, ее нужно правильно сформировать и донести до других: тех, кто будет выделять на нее деньги, тех, кто будет ее реализовывать, и тех, кто будет пользоваться готовым продуктом.
Необходимо проанализировать нужно ли людям то, что вы хотите создать, будут ли они этим пользоваться, окупятся ли вложенные в производство время и деньги, учесть риски. Поэтому нужно понимать, на кого программа будет рассчитана, что она должна делать, какие у нее есть конкуренты на рынке и так далее, а также четко в задокументированном виде обозначить конкретные цели и результат работы.
Когда сформировались четкие требование к ПО, которое нужно создать, переходят к этапу его непосредственной разработки. На основе изложенных идей и требований подбирается техническая архитектура продукта. Описываются функции и технические детали продукта, подбирается визуальный стиль
Именно на этом этапе подбираются технологии, которые будут применяться для реализации проекта, подбирается команда, определяется загрузка команды, формируется самый приближенный к конечной цифре бюджет разработки.
Это один из самых легких в описании, но порой один их самых трудных в реализации этапов. Именно в этот момент в дело вступают программисты, которые на основе всех составленных документов, схем и иллюстраций пишут код таким образом, чтобы готовое ПО выглядело именно так, как задумывалось, и делало то, что необходимо.
Именно на этом этапе правки в духе «ой, мы хотим добавить еще одну функцию» могут стать настоящим адом для всей команды разработчиков и кошелька заказчика, ведь для этого может потребоваться изменение архитектуры приложения и возвращение к стадии дизайна, что полностью перечеркнет уже затраченное на программирование время.
Код готов и скомпилирован, приложение создано и существует физически. На этом этапе нужно проверить, все ли работает как задумывалось, нет ли каких-то дефектов, ошибок, системных неисправностей, все ли механики правильно реализуются, все ли функции работают корректно.
Тестированием занимаются специально обученные люди, которые проходятся по всем возможным вариантам взаимодействия с ПО, а затем составляют отчеты о найденных ошибках и багах, чтобы разработчики могли их устранить. Этот этап повторяется до тех пор, пока участники проекта не останутся довольны уровнем качества продукта.
Когда ПО прошло тестирование и готово к использованию, его выпускают на рынок. Этот этап также может проходить плавно. К примеру, приложение можно выпустить на ограниченном рынке
Самый длительный этап жизненного цикла ПО. Здесь разработчики следят за тем, чтобы программа работала исправно и не имела багов. Некоторые ошибки исправляют сразу с помощью хотфиксов, некоторые убираются во время следующего обновления.
В обновлениях также часто внедряют новые функции, фишки, улучшают удобство использования продукта, его производительность и так далее. Если приложение успешно и живет долго, разработчики обновляют используемые технологии и стандарты в соответствии с современными возможностями. Также на данном этапе в работу включается отдел технической поддержки, который обеспечивает обратную связь с пользователями.
Естественно, помимо указанных выше, существуют также и другие этапы и процессы, происходящие во время разработки ПО
В зависимости от сложности и амбиций проекта разные этапы могут занимать разное время. От этого зависит и выбор методологии, от которой идет обратная зависимость к последовательности и длительности разных этапов. Далее мы детально рассмотрим основные модели и практики при разработке ПО.
Методология разработки ПО — это система, которая определяет порядок и сроки выполнения задач внутри этапов жизненного цикла, методы оценки и контроля. Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга.
От выбора методологии будет зависеть то, как разные этапы жизненного цикла будут связаны между собой и в какой последовательности реализованы. Чтобы правильно выбрать модель, нужно понимать плюсы и минусы каждой из них и суть своего проекта.
Одна из самых первых методологий для разработки ПО. Как может быть понятно из названия, эта модель предполагает постепенное перемещение по этапам жизненного цикла. Сначала проводится анализ и составление задачи, затем проектирование, затем программирование и так далее. Каждый следующий этап стартует только тогда, когда закончен предыдущий. В этом кроется главное преимущество «водопада» и главный недостаток.
С одной стороны, проектом легко управлять, есть четкая последовательность действий, сроки выполнения и бюджет известен заранее. С другой — проекты с такой моделью не терпят правок, требующих возвращения к предыдущим этапам, а результат заказчик видит только на завершающих этапах разработки, когда приложение почти готово.
Таким образом, для небольших проектов с относительно малыми сроками реализации при грамотно составленной документации
Однако чем проект больше, тем больше риск ошибиться в какой-то момент и получить на выходе не то, что нужно, что увеличит бюджет в несколько раз из-за необходимости возвращаться к давно пройденным этапам.
Преимущества каскадной модели
Недостатки каскадной модели
V-образная модель является модифицированной версией «водопада». V стоит в названии от двух главных принципов данной методологии — validation и verification
К примеру, тесты удобства интерфейса проходят еще на этапе дизайна, функциональные и нагрузочные тесты — по мере написания кода, интеграционные тесты, которые подтверждают, что несколько компонентов от различных производителей вместе работают стабильно, — по мере добавления элементов
Соответственно, V-образная модель также подходит для небольших и средних по объемам проектов, где вся документация четко прописана и требуется определенный уровень качества (высокий). Это могут быть приложения безопасности, наблюдения за тяжелобольными пациентами, ПО для атомных электростанций и так далее.
Преимущества V-образной модели
Недостатки V-образной модели
Инкрементная модель в целом следует той же структуре, что и каскадная, однако, как можно понять из названия, все этапы проходят несколько раз в течение жизненного цикла ПО. Получается своеобразный «мультиводопад».
Имеется в виду, что процесс создания программы со множеством задуманных функций начинается с воплощения в жизнь базовой версии. Проходят этапы анализа, дизайна, программирования, тестирования и выпуска продукта на рынок.
К примеру, создатели задумывали приложение для обмена фото, музыкой и видео, но чтобы оно быстрее добралось до пользователей, реализовали только фотообмен. Затем начинается разработка модуля для обмена музыкой и весь процесс повторяется. Затем цикл проходит в третий раз, когда создается модуль обмена видео.
Эту же модель можно применять для того, чтобы «забросить удочку» и посмотреть, понравится ли пользователям новая идея. К примеру, социальная сеть выпускается с возможностью общаться только в текстовом формате. Если она набирает популярность, инкрементируется следующая возможность — отправлять голосовые сообщения и так далее.
Преимущества инкрементной модели
Недостатки инкрементной модели
RAD Model (Rapid Application Development model) — это модель быстрой разработки приложений. Это своего рода ответвление инкрементной модели, так как процесс создания ПО происходит таким же образом с единственным исключением — над проектом работает сразу несколько команд. То есть в один момент времени параллельно существует несколько мини-проектов в одном большом проекте, которые интегрируются в рабочий прототип по мере готовности.
Все преимущества и недостатки инкрементной модели справедливы и для RAD, просто процесс идет еще быстрее, но требует еще более качественного и жесткого менеджмента, а также крепкой обратной связи и синергии между всеми командами. Каждый участник должен понимать итоговую цель.
По сути, итеративная модель — это также разновидность инкрементной модели, которая, однако, лучше показывает себя в больших проектах, где конечная цель заранее не определена либо планируется применение каких-либо инновационных подходов.
К примеру, хочется создать масштабную социальную сеть, но какие функции в ней будут, еще не определено. То есть изначальная задача ясна — создать базовый вариант, где люди могут создавать профиль, обмениваться сообщениями и фото. А следующие версии могут включать либо обмен видео, либо появление «стены» записей, либо вообще разворот в сторону социальной сети для поиска пары.
То есть в инкрементной модели реализуется задуманный набор функций готовыми кусками
Преимущества итеративной модели
Недостатки итеративной модели
Эта модель — также «родственница» инкрементной и итеративной моделей, но с большим упором на анализ рисков и оценку выгоды проекта. Разработка идет по такому же принципу: реализация части проекта и вывод продукта на рынок поэтапно. Единственное отличие — разработка каждой новой версии продукта начинается только в том случае, если заказчик уверен в ее необходимости, востребованности и потенциальной выгоде.
Таким образом, эта модель подходит для тех, чей бизнес зависит от финансового успеха продукта
В целом, преимущества и недостатки подобных моделей справедливы и для спиральной. Только здесь анализ рисков идет постоянно и выпустить ненужный продукт практически невозможно, но при этом можно надолго застрять на одном из этапов, бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
На основе семейства итеративных моделей также был придуман сверхпопулярный ныне гибкий подход к разработке ПО — Agile. И это, скорее, действительно подход, а не отдельная методология, потому что внутри проекта, который ведется по Agile, на разных этапах могут применяться и каскадные, и итерационные модели.
В основе подхода стоит разбиение разработки на множество отдельных задач, которые разные специалисты могут выполнять практически независимо друг от друга. Ежедневно проходят встречи команды (Scrum), где обсуждается текущий прогресс. Разработка при этом делится на этапы — так называемые спринты (Sprint), в ходе которых команда должна достигнуть определенного результата
Такой подход хорошо работает, когда у заказчика много идей и он на начальном этапе не уверен, какие из них будут реализованы, а с течением времени
Преимущества гибкой модели
Недостатки гибкой модели
Agile включает в себя множество разных подходов, техник и методологий, которые сводятся к поэтапному созданию конечного продукта. Среди них можно выделить:
Везде применяется философия готовности к изменениям, сотрудничества с заказчиком, а не следования контракту, нацеленности не на описание документации, а на создание рабочего ПО, а также важности самоорганизации людей, занятых в проекте.
Среди гибких методологий отдельно можно выделить «бережливую» разработку ПО Lean. Она нацелена на повышение эффективности разработки продукта и улучшение рабочих процессов — чтобы сделать проект в три раза быстрее, в три раза дешевле и в три раза чище, чем можно было бы. Здесь упор идет на построение сильной команды, ее обучение и сплоченность, на устранение потерь посредством принятия только тщательно обдуманных решений, качественную и быструю работу по обсуждению рабочих вопросов с заказчиком.
Как видно из всего вышесказанного, у каждой методики и модели есть свои яркие преимущества и неизбежные недостатки и каждая из них может работать для достижения определенного круга задач.
В заключение, чтобы еще больше углубиться в эту большую тему, можно посмотреть это подробное видео:
Прокси (proxy), или прокси-сервер — это программа-посредник, которая обеспечивает соединение между пользователем и интернет-ресурсом. Принцип…
Согласитесь, было бы неплохо соединить в одно сайт и приложение для смартфона. Если вы еще…
Повсеместное распространение смартфонов привело к огромному спросу на мобильные игры и приложения. Миллиарды пользователей гаджетов…
В перечне популярных чат-ботов с искусственным интеллектом Google Bard (Gemini) еще не пользуется такой популярностью…
Скрипт (англ. — сценарий), — это небольшая программа, как правило, для веб-интерфейса, выполняющая определенную задачу.…
Дедлайн (от англ. deadline — «крайний срок») — это конечная дата стачи проекта или задачи…
