Этапы SDLC [объяснено]: как создавать отличное программное обеспечение в 2021 году

Индустрия разработки программного обеспечения переживает бум. Мы продолжаем создавать огромное количество кода каждый год.

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

Итак, давайте отправимся в путешествие по коварной территории разработки программного обеспечения.

Мы посмотрим, что такое SDLC на самом деле, и проследим его эволюцию. Мы увидим, какие основные модели используются в отрасли.

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

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

Понимание процесса SDLC

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

Это зависит от многих переменных, таких как:

• промышленность
• размер организации
• команда и проект
• предполагаемые временные рамки
• и выделенный бюджет.

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

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

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

SDLC часто считается подмножеством более широкого термина «жизненный цикл разработки системы» - старейшей основы для разработки информационных систем.

Он появился в начале 1960-х годов как ответ на потребность в бизнес-системах, способных обрабатывать большие объемы данных. Первая хорошо задокументированная среда SDLC - это парадигма структурированного программирования 1969 года.

В 1990-е годы появилось множество методологий разработки программного обеспечения. Некоторые из них - это объектно-ориентированное программирование, Scrum и Rational Unified Process. Agile Unified Process появился в 2005 году.

Структура процесса разработки программного обеспечения

Разработка программного продукта - это последовательность слаженных этапов. В зависимости от выбранного подхода к разработке количество шагов SDLC может варьироваться.

Мы рассмотрим 5-ступенчатую и 7-ступенчатую разновидности SDLC.

Пятиступенчатая версия

Пятиступенчатая версия процесса разработки программного обеспечения выглядит так:

Требования и анализ

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

• Архитектурный
• Функциональный
• Нефункциональный
• Представление
• И связанные с дизайном

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

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

Дизайн

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

Фаза кодирования

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

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

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

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

Обслуживание

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

7-ступенчатая версия

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

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

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

• Что делать?
• Какие ресурсы нужны?
• Сколько на это потребуется времени?
• Сколько это будет стоить?

Требования и анализ

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

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

Системный дизайн

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

Разработка программного обеспечения

Когда требования ясны, инженеры-программисты могут приступить к работе. Цель на данном этапе - рабочая программа, готовая к тестированию. Это также начало производства в процессе SDLC .

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

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

Автоматическое тестирование - это способ автоматизировать процесс выполнения повторяющихся тестов с использованием внешнего программного обеспечения, такого как Bamboo и Jenkins.

Реализация

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

Техническое обслуживание и эксплуатация

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

Модели SDLC

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

Это неверно, когда мы смотрим на методы разработки . Хотя все они наблюдают за процессом, они делают это по-разному.

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

• сложность проекта
• выбранная технология
• и размер команды.

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

Водопад

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

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

Водопад SDLC очень структурированный подход. Хорошо работает, когда:

• требования и действия четко определены и понятны
• технология надежна
• доступна служба поддержки и вы оцениваете краткосрочный проект

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

Итеративный

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

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

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

Методология не подходит для небольших проектов.

Гибкий

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

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

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

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

Наклонять

Методология Lean-разработки программного обеспечения считается частью метода гибкой разработки программного обеспечения. Процесс SDLC в соответствии с методологией Lean состоит из семи принципов:

• Устранение отходов
• Улучшение обучения
• Решить как можно позже
• Доставим как можно быстрее
• Расширьте возможности команды
• Строить целостность
• Увидеть картину в целом

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

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

DevOps

Модель DevOps частично основана как на Agile, так и на Lean . Это недавно появившийся подход, который связывает тесное сотрудничество между разработчиками программного обеспечения и операционными группами на протяжении всего жизненного цикла разработки.

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

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

Спираль

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

Четыре стадии и повторения называются «спиралями». В SDLC фазы: планирование и сбор требований; дизайн; разработка и тестирование.

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

Заворачивать

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

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