П5. SDLC (1)

1.

Виды, Структуры и Этапы
Создания ПО

2.

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

3.

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

4.

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

5.

Этап 3: Проектирование и Дизайн
Этап проектирования переводит абстрактные требования в конкретный
архитектурный план. Здесь разрабатывается архитектура системы,
определяются компоненты, интерфейсы, структуры данных и схемы
взаимодействия. Также создается дизайн пользовательского интерфейса
(UI/UX).

6.

Этап 4: Разработка
Разработка включает непосредственное написание кода. Команда
разработчиков анализирует требования, разбивая их на более мелкие,
ежедневные задачи.
В современных условиях критически важным является Version Control, что
позволяет поддерживать чистоту кодовой базы и эффективно работать в
команде.

7.

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

8.

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

9.

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

10.

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

11.

Agile, Scrum и прочие методологии
На заре разработки программного обеспечения доминировал традиционный
подход к управлению проектами, который часто называют Моделью
Водопада (Waterfall Model). Этот метод, хотя и структурирован, разбивает
проекты на линейные, последовательные фазы. Работа должна быть
полностью завершена на одном этапе (например, Сбор требований), прежде
чем команда сможет перейти к следующему (Проектирование)

12.

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

13.

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

14.

15.

Четыре основополагающие ценности
1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану

16.

17.

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

18.

А теперь попроще)
Цель:

19.

Scrum
Scrum - это такой способ работы, который помогает не запутаться и
построить именно тот замок, который всем понравится.

20.

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

21.

Разбиваем большую задачу на маленькие кусочки
Вместо того чтобы говорить: "Строим весь
замок!", мы говорим: "Давайте сначала построим
одну башню". Этот маленький, но готовый
кусочек работы в Скраме называется Спринт
(Sprint). Обычно он длится 1 - 4 недели.

22.

тот самый Спринт
Планирование Спринта
Ежедневный Скрам
● Что я сделал вчера, чтобы помочь построить башню?
● Что я сделаю сегодня?
● Что мне мешает?
Это помогает всем быть в курсе дел и быстро решать проблемы.
Обзор Спринта
Ретроспектива Спринта

23.

И потом всё начинается заново))

24.

Архитектурные Структуры
и Типы Программного
Обеспечения

25.

Классификация ПО
● Системное ПО: Обеспечивает работу компьютерного оборудования и
других программ (операционные системы, драйверы, утилиты,
компиляторы).
● Прикладное ПО: Предназначено для решения конкретных задач
конечного пользователя.
● Инструментальное ПО: Используется разработчиками для создания,
отладки и поддержки других программ (среды разработки IDE, системы
управления исходным кодом, инструменты тестирования).

26.

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

27.

Архитектура Микросервисов
Архитектура микросервисов представляет собой подход, при котором
система строится как набор слабо связанных, независимо развертываемых
сервисов.

28.

29.

IT-отдел компании разрабатывает два проекта:
1. Внутренний инструмент для расчета налогов: Требования стабильны,
частота изменений низкая, критична точность и соответствие
законодательству.
2. Мобильное приложение для рекомендаций на основе ИИ: Требования
постоянно меняются, необходима высокая частота обновлений и
возможность независимого масштабирования ИИ-модуля.
Какую архитектуру (Монолит или Микросервисы) следует применить для
каждого из этих продуктов, и как этот выбор повлияет на процесс
разработки?