Модели жизненного цикла. Принципы и методологии разработки ПО

Разработка программного обеспечения — это стандартизированный комплексный процесс, который проходит множество этапов в течение порой длительного времени. Одним из важнейших этапов жизненного цикла ПО являются первые шаги, а именно — подбор методологии разработки и правильное планирование приоритетов на старте. По сути, именно от этого выбора во многом зависит дальнейший успех проекта. Эта статья поможет подобрать оптимальный вариант в большинстве ситуаций.

Содержание:
1. Этапы жизненного цикла ПО
2. Основные модели разработки ПО
3. Что такое Agile и Lean: принципы разработки ПО

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

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

Более того, даже после первоначального выпуска продукта в свет работа над ним не заканчивается. К примеру, всем известное веб-приложение Instagram сначала существовало только в головах создателей как идея объединения любителей мобильной фотографии в единую социальную сеть, лишенную прочих атрибутов сообщения, музыка и так далее. Однако даже после выхода приложения в 2010 году работа над проектом не прекращалась, и Instagram сегодня — это уже совершенно другое приложение с сообщениями, историями, видео и другими вещами.

Жизненный цикл разработки программного обеспечения от английского Software Development Life Cycle, SDLC — это условная схема, которая содержит в себе все этапы, через которые ПО проходит от формирования в виде идеи до последних дней своей работы, что еще раз подтверждает вышесказанное: разработка приложения не прекращается даже после его релиза.

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

Основные модели разработки ПО

1. Идея, сбор и анализ требований для ее осуществления.
2. Дизайн и проектирование.
3. Реализация и программирование.
4. Тестирование и отладка.
5. Внедрение и эксплуатация.
6. Сопровождение и поддержка.

Остановимся на каждом из них подробнее.

Идея, сбор и анализ требований для ее осуществления

Один из самых важных этапов разработки ПО, на котором принимаются главные решения. Когда у человека есть идея, ее нужно правильно сформировать и донести до других: тех, кто будет выделять на нее деньги, тех, кто будет ее реализовывать, и тех, кто будет пользоваться готовым продуктом.

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

Дизайн и проектирование

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

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

Реализация и программирование

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

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

Тестирование и отладка

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

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

Внедрение и эксплуатация

Когда ПО прошло тестирование и готово к использованию, его выпускают на рынок. Этот этап также может проходить плавно. К примеру, приложение можно выпустить на ограниченном рынке только в одной стране, чтобы пройти дополнительную проверку гипотезы ведь пользователи могут столкнуться со сценариями, которые не учитывали разработчики, что даст время доработать и улучшить продукт. Так или иначе, на этом этапе с ПО начинает взаимодействовать конечный потребитель — люди.

Сопровождение и поддержка

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

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

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

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

2. Основные модели разработки ПО

Методология разработки ПО — это система, которая определяет порядок и сроки выполнения задач внутри этапов жизненного цикла, методы оценки и контроля. Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга.

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

Waterfall (каскадная модель или «водопад»)

Одна из самых первых методологий для разработки ПО. Как может быть понятно из названия, эта модель предполагает постепенное перемещение по этапам жизненного цикла. Сначала проводится анализ и составление задачи, затем проектирование, затем программирование и так далее. Каждый следующий этап стартует только тогда, когда закончен предыдущий. В этом кроется главное преимущество «водопада» и главный недостаток.

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

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

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

Преимущества каскадной модели

1. Простое управление разработкой при наличии четко сформулированной документации.
2. Стоимость и сроки известны на начальном этапе.
3. Низкая вероятность ошибок в небольших проектах.
4. Тестирование могут проводить люди с более низкой квалификацией из-за наличия подробной документации.

Недостатки каскадной модели

1. Тестирование происходит на последних этапах.
2. Чем масштабнее проект, тем большая вероятность критических ошибок, исправление которых потребует значительного увеличения бюджета.
3. Заказчик видит готовый продукт лишь в конце разработки.
4. Написание и согласование подробной документации также может вызвать множество задержек.

V-образная модель (разработка через тестирование)

V-образная модель является модифицированной версией «водопада». V стоит в названии от двух главных принципов данной методологии — validation и verificationутверждение и подтверждение. По сути, здесь процессы происходят друг за другом, однако на каждом этапе присутствует элемент тестирования. Продукт подвергается тщательным проверкам уже на начальных этапах разработки. Тестирование является основополагающим элементом всего процесса.

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

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

Преимущества V-образной модели

1. Тестирование проходит на всех этапах разработки.
2. Вероятность ошибок сводится к минимуму.

Недостатки V-образной модели

1. Требуется высокий уровень квалификации тестировщиков и/или их высокая занятость.
2. Если ошибка все же была допущена, то вернуться к предыдущему этапу будет даже дороже, чем при каскадной модели.

Incremental Model (инкрементная модель)

Инкрементная модель в целом следует той же структуре, что и каскадная, однако, как можно понять из названия, все этапы проходят несколько раз в течение жизненного цикла ПО. Получается своеобразный «мультиводопад».

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

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

Эту же модель можно применять для того, чтобы «забросить удочку» и посмотреть, понравится ли пользователям новая идея. К примеру, социальная сеть выпускается с возможностью общаться только в текстовом формате. Если она набирает популярность, инкрементируется следующая возможность — отправлять голосовые сообщения и так далее.

Преимущества инкрементной модели

1. Есть возможность раннего выхода на рынок, чтобы посмотреть реакцию пользователей.
2. Базовая версия ПО стоит дешевле. Модули можно доделывать по мере появления денег, либо не делать вовсе за ненадобностью. Самые рискованные идеи можно отложить на потом.
3. Исправление ошибок обходится дешевле.

Недостатки инкрементной модели

1. Требования к проекту на каждом этапе должны быть четко определены и понятны. Необходим хороший менеджмент.
2. Приложение может выйти слишком «сырым» и не дожить до появления всех функций.

RAD (быстрая разработка)

RAD Model (Rapid Application Development model) — это модель быстрой разработки приложений. Это своего рода ответвление инкрементной модели, так как процесс создания ПО происходит таким же образом с единственным исключением — над проектом работает сразу несколько команд. То есть в один момент времени параллельно существует несколько мини-проектов в одном большом проекте, которые интегрируются в рабочий прототип по мере готовности.

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

Iterative Model (итеративная модель)

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

К примеру, хочется создать масштабную социальную сеть, но какие функции в ней будут, еще не определено. То есть изначальная задача ясна — создать базовый вариант, где люди могут создавать профиль, обмениваться сообщениями и фото. А следующие версии могут включать либо обмен видео, либо появление «стены» записей, либо вообще разворот в сторону социальной сети для поиска пары.

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

Преимущества итеративной модели

1. Есть возможность раннего выхода на рынок, чтобы посмотреть реакцию пользователей.
2. Возможность запустить проект, когда конечная цель до конца не определена.
3. Добавлять новые функции и менять направление проекта можно с каждой новой итерацией в зависимости от бюджета.

Недостатки итеративной модели

1. Добавление заранее не оговоренных функций может привести к необходимости полного переделывания целых кусков проекта.
2. Отсутствие фиксированного бюджета и сроков реализации.
3. Приложение может выйти слишком «сырым» и не дожить до того, как станет функционально соответствовать задумке.

Spiral Model (спиральная модель)

Эта модель — также «родственница» инкрементной и итеративной моделей, но с большим упором на анализ рисков и оценку выгоды проекта. Разработка идет по такому же принципу: реализация части проекта и вывод продукта на рынок поэтапно. Единственное отличие — разработка каждой новой версии продукта начинается только в том случае, если заказчик уверен в ее необходимости, востребованности и потенциальной выгоде.

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

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

3. Что такое Agile и Lean: принципы разработки ПО

На основе семейства итеративных моделей также был придуман сверхпопулярный ныне гибкий подход к разработке ПО — Agile. И это, скорее, действительно подход, а не отдельная методология, потому что внутри проекта, который ведется по Agile, на разных этапах могут применяться и каскадные, и итерационные модели.

В основе подхода стоит разбиение разработки на множество отдельных задач, которые разные специалисты могут выполнять практически независимо друг от друга. Ежедневно проходят встречи команды (Scrum), где обсуждается текущий прогресс. Разработка при этом делится на этапы — так называемые спринты (Sprint), в ходе которых команда должна достигнуть определенного результата полностью закончить дизайн, показать базовую версию продукта и так далее.

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

Преимущества гибкой модели

1. Возможность начать разработку ПО без четкого плана, имея лишь набор идей.
2. Возможность для заказчика видеть даже минимальный результат работы и вносить изменения на ходу, что уменьшает вероятность необходимости правок на поздних этапах.
3. Более дешевая поэтапная разработка, а также возможность постоянной адаптации к изменяющимся условиям рынка из-за наличия коротких спринтов.

Недостатки гибкой модели

1. Часто из-за отсутствия конкретных формулировок результатов сложно оценить бюджет и время, требуемые на разработку готового продукта типична ситуация, что «эстимейты» носят очень примерный или даже совершенно произвольный характер.
2. На начальных этапах высока вероятность неудачи неверная архитектура, ненужные функции или их недостаток и так далее, что также требует гибкости бюджета.

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

• Scrum — где люди постоянно общаются и взаимодействуют между собой на собраниях и обсуждениях.
• Kanban — где есть виртуальная доска с задачами, которые можно выполнять в любом порядке.
• RUP — где есть четкие фазы планирования, уточнения и построения новых итерация ПО.
• Extreme Programming — где применяется высокая частота обновления версии продукта ориентация на постоянные изменения требований и поиск самых быстрых решений.

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

Среди гибких методологий отдельно можно выделить «бережливую» разработку ПО Lean. Она нацелена на повышение эффективности разработки продукта и улучшение рабочих процессов — чтобы сделать проект в три раза быстрее, в три раза дешевле и в три раза чище, чем можно было бы. Здесь упор идет на построение сильной команды, ее обучение и сплоченность, на устранение потерь посредством принятия только тщательно обдуманных решений, качественную и быструю работу по обсуждению рабочих вопросов с заказчиком.

---

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

В заключение, чтобы еще больше углубиться в эту большую тему, можно посмотреть это подробное видео: