<style>.lazy{display:none}</style>Жизненный цикл разработки ПО (SDLC)

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

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

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

Компоненты SDLC

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

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

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

✦ Цель SDLC – создание качественного ПО, которое удовлетворяет требованиям заказчика и соответствует его ожиданиям.

Подтипы SDLC

Два подтипа SDLC: LCD (Life Cycle Development) – непосредственно жизненный цикл разработки и LCT (Life Cycle Testing) – жизненный цикл тестирования.

Процесс SDLC включает шесть этапов:

Процесс SDLC включает шесть этапов

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

✦ Бизнес-аналитик (БА) собирает информацию от клиента

✦ Сбор информации – это не что иное, как сбор требований от клиента

✦ Сбор информации включает в себя спецификацию бизнес-требований (Business requirement specification, BRS)

✦ Бизнес-аналитик готовит документы BRS.

Клиент-БА-Команда разработки

Клиент-БА-Команда разработки.

Анализ

✦ В этом процессе участвует БА

✦ SRS (спецификация требований к ПО) создается в процессе анализа

✦ SRS – подробная функциональная документация

Сравнение BRS и SRS

SRS – спецификация требований к ПО

Документация SRS состоит из следующих 4 компонентов:

Документация SRS состоит из следующих 4 компонентов

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

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

✦ Представляет собой пошаговые этапы работы с приложением

✦ Иллюстрирует связи и зависимости между задачами

✦ Обеспечивает правильную последовательность задач

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

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

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

✦ Это некоторые атрибуты функциональных требований

✦ Эти атрибуты необходимы для выполнения определенной функции.

В примере выше описано, какие входные данные должно принимать каждое поле ввода (Имя, Фамилия, телефон и т.д.)

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

Предположим, у нас есть функция Входа в систему (Login):

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

✦ Тестирование юзкейсов подразумевает проверку комбинаций входных данных + процесса + выходных данных.

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

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

Дизайн

✦ Системный архитектор разрабатывает дизайн

✦ Процесс разработки состоит из двух этапов:

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

Отличия высокоуровневого и низкоуровневого видов дизайна

Кодинг

✦ Кодинг – это не что иное, как программирование

✦ Одна строка – это код; несколько строк кода – это программа

✦ Этот этап проводится разработчиком или программистом

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

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

✦ Подразумевает использование определенных баз данных, таких как SQL, ORACLE и т.д.

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

✦ Существует два типа разработчиков: фронтенд и бэкенд

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

Типы разработчиков: : фронтенд и бэкенд
Фулстек-разработчик

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

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

✦ Существует три вида тестирования:

три вида тестирования: белого, черного и серого ящика

❖ ТЕСТИРОВАНИЕ БЕЛОГО ЯЩИКА (WBT)

✦ В WBT, как правило, участвуют только разработчики

✦ Разработчики выполняют тестирование на уровне кода (юнит-тестирование – тестирование собственного кода после разработки)

✦ При проверке рассматриваются только позитивные сценарии

✦ Необходимо знание внутренней структуры приложения

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

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

❖ ТЕСТИРОВАНИЕ ЧЕРНОГО ЯЩИКА (BBT)

✦ В BBT участвуют только тестировщики

✦ Тестировщик проверяет/оценивает зависимость внутренней функциональности приложения от внешней (фронтенда)

✦ Это техника тестирования на уровне сборки

✦ Его также называют системным и динамическим тестированием

✦ При этом виде тестирования проверяется общая функциональность

✦ Не нужно знать внутреннюю структуру приложения.

Позитивные и негативные сценарии тестирования

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

❖ ТЕСТИРОВАНИЕ СЕРОГО ЯЩИКА (GBT)

✦ В GBT участвуют только тестировщики

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

✦ При тестировании серого ящика тестировщику необходимо знание языков программирования

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

Поддержка ПО

✦ Поддержка ПО означает предоставление услуг после поставки продукта

✦ Поддержка ПО включает в себя как техническую, так и нетехническую поддержку

✦ Нетехническая поддержка называется аутсорсинг бизнес-процессов (Business Process Outsourcing, BPO)

✦ Техническая поддержка называется аутсорсинг управления знаниями (Knowledge Process Outsourcing, KPO).

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

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *