Жизненный цикл разработки ПО (SDLC)

В сфере разработки программного обеспечения эффективность имеет первостепенное значение. SDLC расшифровывается как Software Development Life Cycle (“жизненный цикл разработки программного обеспечения”) и подразумевает под собой структурированный подход, направленный на быстрое и экономичное создание высококачественного ПО. Понимание и эффективное внедрение SDLC может значительно улучшить результаты программных проектов, удовлетворить требования клиентов и даже превзойти их ожидания. Давайте разберемся в тонкостях SDLC, чтобы использовать весь его потенциал.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Компоненты и этапы SDLC

Жизненный цикл разработки ПО можно разделить на две составляющие: жизненный цикл непосредственно разработки (LCD, Life Cycle Development) и жизненный цикл тестирования (LCT, Life Cycle Testing).

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

Сбор информации

Сбор информации это не что иное, как сбор требований от клиента. Собирает их бизнес-аналитик. Он же готовит спецификацию бизнес-требований (Business requirement specification, BRS) для технической команды (разработчиков и тестировщиков).

Анализ

На этом этапе также задействованы бизнес-аналитики. В процессе анализа создаются SRS (спецификация требований к ПО) и SRS (подробная функциональная документация).

BRS содержит требования в целом. Например, в приложении должна быть страница регистрации и домашняя страница.

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

SRS состоит из следующих компонентов:

1. Функциональная блок-схема
2. Функциональные требования
3. Юзкейсы
4. Снапшоты

1. Функциональная блок-схема

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

2. Функциональные требования

Функциональные требования – это требования к тому, как должны работать те или иные функции приложения. В качестве примера можно привести требования к полям формы:

• FirstName и LastName должны принимать только буквенные символы, могут быть ограничены по длине.
• DOB – дата рождения – должна быть в формате DD-MM-YYYY, поле должно принимать только цифры.
• PhoneNo – номер телефона – допускаются только цифры.

3. Юзкейсы (Use Cases)

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

Use case служит следующим целям:

• Помогает установить требования к проекту
• Изображает различные способы взаимодействия пользователя с системой
• Визуализирует архитектуру системы
• Помогает оценить потенциальные риски и системные зависимости
• Позволяет легко донести сложные технические требования до соответствующих заинтересованных сторон (стейкхолдеров)

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

Подробнее можно почитать в статье “Тестирование на основе use case”.

4. Моментальные снимки (Snapshot )

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

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

Проектирует ПО в целом системный архитектор. Процесс проектирования состоит из двух этапов:

1. High Level Design (HLD) – высокоуровневый дизайн
2. Low Level Design (LLD ) – низкоуровневый дизайн

Кодинг

Это не что иное, как программирование. Одна строка – это код, несколько строк кода – это программа.

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

Кодинг подразумевает использование языков программирования, например, C, C++, Java, Python, PHP и т.д., баз данных, таких как SQL, ORACLE и т.д., и различных инструментов программирования, таких как компилятор, интерпретатор, отладчик.

Разработчики обычно специализируются во фронтенде или бэкенде.

Фронтенд-разработчик занимается пользовательским интерфейсом (расположение элементов, анимация, навигация) и использует в работе JavaScript, HTML, CSS. Бэкенд-разработчик фокусируется на безопасности, отладке, работе с базами данных и других серверных функциях, которые не видны пользователю. Он пишет код на различных языках программирования, типа Java, Python, PHP и т.д.

Разработчик, сочетающий в своей работе оба направления, называется фулстек-разработчиком.

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

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

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

Тестирование белого ящика

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

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

Программист не может отправить код тестировщику без проведения тестирования белого ящика.

Тестирование черного ящика

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

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

Тестирование серого ящика

Тестирование серого ящика – это сочетание тестирования белого и черного ящиков. Проводят его тестировщики.

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

Поддержка ПО

Поддержка ПО означает предоставление услуг после поставки продукта. Она включает в себя как техническую, так и нетехническую поддержку. Нетехническая поддержка называется аутсорсинг бизнес-процессов (Business Process Outsourcing, BPO). Техническая поддержка называется аутсорсинг управления знаниями (Knowledge Process Outsourcing, KPO).

Перевод статьи «Software Development Life Cycle (SDLC)».