SDLC – Software Development Life Cycle. Жизненный цикл разработки программного обеспечения

1.

SDLC – Software Development Life Cycle
Жизненный цикл разработки
программного обеспечения

2.

Жизненный цикл разработки
программного обеспечения
Жизненный цикл программного обеспечения
(ПО) — период времени, который начинается с
момента принятия решения о необходимости
создания программного продукта и
заканчивается в момент его полного изъятия из
эксплуатации.
2

3.

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

4.

• Этап 1: Анализ и планирование

5.

• Этап 2: Проектирование и
Дизайн/Определение
требований

6.

• Этап 3: Разработка
архитектуры продукта

7.

• Этап 4: Создание или
разработка продукта

8.

• Этап 5: Тестирование продукта

9.

• Этап 6: Размещение на рынке
и обслуживание

10.

Модели разработки ПО

11.

Водопадная
Waterfall

12.

V–
образнaя
модель
V - model

13.

Итерационная инкрементальная модель
Iterative incremental model

14.

Спиральная модель
Spiral model

15.

Гибкие модели разработки
ПО

16.

Kanban VS Scrum

17.

Канбан
(кан – видимый, бан-доска)
Преимущества
Недостатки
Планируем то, что
необходимо в
текущее время
Внимание ко всему
процессу
Нет частых
переприотизаций
Сроки не важны,
если равномерно
разбить задачи
Вместо скорости
важно время цикла,
т.е. Среднее время
для реализации
задач
Нет таймбоксов
Выпускаем по мере
необходимости
Плохо работает с командами >
5человек
Не предназначен для
долгосрочного планирования
Bottleneck

18.

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

19.

Устали?

20.

Спасибо за внимание!