SDLC

Что такое жизненный цикл разработки программного обеспечения?

Тестирование–не изолированный процесс. Это часть модели жизненного цикла программного обеспечения (Software Development Life Cycle, SDLC). Именно поэтому выбор средств и методик тестирования будет напрямую зависеть от выбранной модели разработки. В этом разделе мы рассмотрим наиболее часто применяемые подходы к разработке программного обеспечения, а также популярные сегодня методологии и практики, такие как Agile и Scrum.

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

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

Хотя реализация принципов построения модели жизненного цикла для разных компаний может существенно отличаться, существуют стандарты, такие как ISO/IEC 12207, определяющие принятые практики разработки и сопровождения программного обеспечения.

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

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

• Анализ требований отвечает на вопрос «Какие проблемы требуют решений?»
• Планирование отвечает на вопрос «Что мы хотим сделать?»
• Проектирование и дизайн отвечает на вопрос «Как мы добьемся наших целей?»
• Разработка ПО регулирует процесс создания продукта.
• Тестирование регулирует обеспечение качественной работы продукта.
• Развертывание регулирует использование финального продукта.

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

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

Анализ требований

На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: «Какие проблемы требуют решений?» Быть внимательным и делать заметки будет очень полезно на этом этапе.

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

Планирование

На этом этапе вы ищете ответ на следующий вопрос: «Что вы хотите сделать?» Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.

Хороший пример:

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

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

Проектирование и дизайн

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

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

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

Разработка ПО

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

Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе – и приступайте к делу.

Тестирование

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

Развертывание

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

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

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

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

Плюсы и минусы каскадной модели:

+ Полное документирование каждого этапа;
+ Четкое планирование сроков и затрат;
+ Прозрачность процессов для заказчика;
- Необходимость утверждения полного объема требований к системе еще на первом этапе;
- В случае необходимости внесения изменений требований позднее – возврат к первой стадии и переделка заново всей проделанной работы;
- Увеличение затрат средств и времени в случае необходимости изменения требований.

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

Когда использовать каскадную модель:

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

V - модель

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

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

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

Плюсы и минусы V-модели:

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

Когда использовать V-модель:

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

Полезные ссылки:

SDLC /video tutorial/eng

SDLC /video tutorial/rus

SDLC /article/eng

SDLC /article/rus