Жизненный цикл разработки ПО. Модели жизненного цикла

1.

ОСНОВЫ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ
Лекция №2: Жизненный цикл.
Модели жизненного цикла
Кафедра: Цифровые системы и модели
Лектор: к.т.н., доцент Зарипова Р.С.

2.

Повторение предыдущего материала
ЧТО ТАКОЕ ПРОЕКТ?
Это временная деятельность, направленная на создание
уникального результата (продукта, услуги, мероприятия и
др.) в ограниченные сроки с использованием ограниченных
ресурсов
(время,
капитал,
люди,
материалы
и
инструменты).
Проект — совокупность мероприятий для разработки
нового продукта или улучшения существующего
продукта / услуги.
IТ-проект — это деятельность по
уникального продукта, сервиса или среды.
созданию

3.

КРИТЕРИИ ПРОЕКТА
новизна;
наличие четкой цели;
начало и окончание проекта четко определены во
времени;
комплексность поставленной цели, когда проект
включает в себя связанные между собой и
зависимые друг от друга задачи и подзадачи
разного уровня;
участие нескольких специалистов для достижения
цели.

4.

ПРИЗНАКИ «НЕ ПРОЕКТА»
Цель однозначно не определена, неконкретна или
недостижима;
Сроки не определены, нереальны для достижения
цели;
Результат неуникален.

5.

Виды деятельности
Чтобы понять, что такое управление проектами, в чём его цель и суть,
нужно сначала разобраться с видами деятельности — это то, как специалисты
и команды работают.
Глобально можно выделить два вида деятельности: процессную
и проектную.
Процессная деятельность — это многократное повторение одного
и того же действия. Например, лепка пельменей в цехе.
Проектная деятельность — это реализация уникальной идеи.
Например, разработка нового рецепта тех же пельменей. Проектная
деятельность сложнее процессной, потому что проектную работу невозможно
выстроить раз и навсегда и поставить «на конвейер» — в ней каждый раз
возникают уникальные сложности и задачи.
Давайте сравним:

6.

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

7.

Все проекты, включая IТ, проходят через 5 этапов. Каждый этап
содержит процессы, которые двигают проект от идеи
до реализации:

8.

ЖИЗНЕННЫЙ ЦИКЛ
Существует
целый
ряд
стандартов,
которые
регламентируют жизненный цикл ПО, а в некоторых
случаях и процессы разработки.
Жизненный цикл программного обеспечения
(ЖЦ ПО) – это период времени, который
начинается с момента принятия решения о
создании программного продукта и заканчивается
в момент его полного изъятия из эксплуатации.

9.

Основные этапы жизненного цикла разработки ПО
1) Сбор и анализ требований,
2) Проектирование,
3) Разработка (программирование),
4) Тестирование и отладка,
5) Эксплуатация и сопровождение.

10.

1. Сбор и анализ требований
Документируются все требования к ПО. Обсуждаются детали
проекта с заинтересованными
сторонами. Учитываются
технические ограничения, которые могут возникнуть в процессе
реализации. Создаётся подробная спецификация, отвечающая
всем требованиям заказчика. Устанавливаются сроки и бюджет.
Все поступающие данные анализируются и систематизируются. Чем
больше информации о проекте собирается, тем меньше времени потом
тратиться на исправление ошибок, доработку проекта, пересмотры
бюджета, обсуждения и решение других вопросов. Важной задачей является
создание подробного документа видения (или образа) проекта, который
включает краткое описание проекта, бизнес-цели, критерии успеха проекта,
факторы бизнес-рисков и описание конечного пользователя продукта. Этот
готовый документ передается на утверждение заказчику, чтобы убедиться в
том, что все поставленные требования были учтены, а также чтобы
проинформировать заказчика о любых рисках, которые могут возникнуть
после релиза проекта.

11.

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

12.

3. Разработка ПО
Это
процесс
превращения
спроектированной
архитектуры и дизайна в функциональный продукт.
Написание кода в соответствии с архитектурными и
проектными решениями. Реализация функционала ПО,
создание модулей и компонентов, создание БД.

13.

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

14.

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

15.

16.

17.

5. Эксплуатация и сопровождение
Это процесс, на котором ПО передаётся конечным
пользователям или в рабочую среду для использования.
Здесь важна стабильность системы и готовность людей с
ней работать.
На этом этапе стоит:
— настроить интеграции с другими системами (кадровыми,
финансовыми, BI-платформами);
— провести обучение ключевых пользователей;
— организовать информационную поддержку внедрения
(инструкции, рассылки, FAQ);
— определить ответственных за сопровождение и за сбор
отзывов и комментариев.

18.

МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПО
Для разработки качественного ПО необходимо хорошо
понимать основные принципы ЖЦ ПО, требования заказчика к
создаваемому ПО, учитывать его финансовые возможности.
Для облегчения проектирования, создания и
качественного ПО существуют разные модели ЖЦ ПО.
выпуска
Выбор определенной модели ЖЦ зависит от содержания и
целей проекта, а также от размера его финансирования.
Модели ЖЦ разработки ПО — это структурированные
схемы, описывающие последовательность процессов,
действий и задач на разных этапах разработки. Эти модели
помогают организовать работу команды и распределить
задачи на каждом шаге — от планирования до внедрения.

19. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПО

• Водопадная модель;
• V-образная модель;
• Инкрементная модель;
• Итеративная модель;
• Спиральная модель;
• Прототипирование.

20.

№1
ВОДОПАДНАЯ (КАСКАДНАЯ) МОДЕЛЬ
Каскадная модель работает по принципу водопада: каждый этап
разработки строго следует за предыдущим без возможности вернуться

21.

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

22.

ПЛЮСЫ КАСКАДНОЙ МОДЕЛИ:
• все стадии проекта выполняются в строгой последовательности;
• строгость этапов позволяет планировать ресурсы и сроки;
• требования остаются неизменными в течение проекта;
• проще отслеживать прогресс и контроль выполнения задач.
МИНУСЫ:
• сложности при формулировке четких требований;
• отсутствие гибкости, невозможность изменения требований;
• разработка ПО может затянуться из-за строгой этапизации;
• тестирование начинается только с середины проекта;
• до завершения разработки клиент не знает о качестве ПО;
• модель плохо подходит для проектов, где нужно быстро
вносить изменения.

23.

№2
V-ОБРАЗНАЯ МОДЕЛЬ (V-MODEL)
Процессы на всех этапах тестируются, чтобы убедиться в возможности перехода на
следующий уровень. Уже на стадии написания требований начинается процесс тестирования.

24.

V-модель — это подход к разработке проекта, где каждый
этап подготовки сразу связывается с этапом тестирования.
Выглядит это как буква V:
• Левая часть — это сбор требований, проработка
архитектуры и проектирование системы.
• Правая часть — это тестирование, где проверяют,
правильно ли всё реализовано и соответствует ли
результат требованиям проекта.
В этап тестирования входят автотесты, интеграционные тесты на проверку,
как компоненты взаимодействуют друг с другом, системные тесты на общую
работу продукта, в приёмочных тестах команда проверяет, соответствует ли
разработка требованиям заказчика. Например, если вы на этапе
проектирования видите, что система не сможет подключиться к CRM, это можно
исправить сразу, а не после того, как всё уже сделано.

25.

Данная модель стала последователем каскадной модели, так как с ее
помощью можно устранить недостатки, которые были в каскадной модели.
ПЛЮСЫ V-ОБРАЗНОЙ МОДЕЛИ:
• строгая этапизация;
• минимизация рисков и устранение ошибок за счет раннего
тестирования;
• усовершенствованный тайм-менеджмент.
МИНУСЫ:
• низкий уровень гибкости;
• длительное время разработки;
• подходит не для всех проектов;
• поздняя демонстрация работающего продукта.

26. ИТЕРАТИВНАЯ МОДЕЛЬ

№3
ИТЕРАТИВНАЯ МОДЕЛЬ

27.

Выполнение работ идет параллельно с непрерывным анализом
полученных результатов и корректировкой предыдущих этапов
работы.
Здесь команда делит проект на короткие этапы — итерации,
которые длятся около 2–4 недель. На каждой стадии разработчики
проходят все этапы цикла: собирают требования, пишут код,
тестируют и показывают результат.
После каждой итерации появляется рабочая часть ПО, которую
можно сразу отдать на пробу пользователям, протестировать или
встроить в текущий процесс.
В
ходе
разработки
всегда
выявляются
или
изменяются
дополнительные требования. Также появляются новые ограничения,
связанные с принятыми техническими решениями. В наиболее полной
мере их удается учесть именно в итерационной разработке, поскольку
именно при таком подходе руководство проекта в полной мере готово к
изменениям.

28.

ПЛЮСЫ ИТЕРАТИВНОЙ МОДЕЛИ:
• гибкость, возможность вносить изменения по ходу проекта;
• постепенное улучшение продукта.
МИНУСЫ:
• требует слаженной, командной работы;
• трудно оценивать сроки и бюджет.
Итеративная модель подходит для проектов, где требования
заказчика могут меняться, но при этом важно сохранять чёткую
структуру и контролировать этапы работы. К примеру, для
автоматизации бизнес-процессов, где сложно сразу описать все
детали, или для цифровой трансформации устаревших систем.

29. ПРОТОТИПИРОВАНИЕ

№4
ПРОТОТИПИРОВАНИЕ
В этой модели команда сначала разрабатывает
упрощённую версию продукта — прототип или MVP.

30.

Перед запуском сложного ПО команда не начинает с
полноценной бэкенд-разработки, а собирает в Figma
интерактивный макет или создаёт базовую версию на nocode-платформе вроде Tilda или Webflow.
Далее макет показывают фокус-группе: анализируют,
понятно ли пользователю, где и что нажимать, как проходит
сценарий. Тут же вносят правки и уточняют, что
действительно важно реализовывать в продукте, а от чего
можно отказаться.
Подходит проектам, где нужно быстро проверить идеи,
визуализировать продукт и получить отзывы до начала
полной разработки. Например, когда необходимо согласовать
логику и интерфейс с разными участниками проекта.

31.

Плюсы прототипирования:
• Быстрая проверка идей и гипотез. Позволяет на ранней стадии оценить, как
будет работать продукт, и до начала полной разработки предположить, что нужно
пользователям.
• Улучшение коммуникации между участниками проекта. Прототип делает
идею наглядной. Заказчику и конечным пользователям проще понять, что
разрабатывается, а команде — быстрее получить фидбэк.
• Снижение рисков ненужной разработки. Если что-то в прототипе не работает
или вызывает вопросы, то это можно изменить до того, как команда вложит
ресурсы в реализацию.
Минусы:
• Дополнительные затраты времени и ресурсов. Создание прототипа —
отдельный этап, который может увеличить сроки, особенно при высокой
сложности. Пользователи часто принимают его за готовый продукт, недооценивая
объём оставшейся работы.
• Прототип не всегда отражает технические ограничения. То, что выглядит
красиво на прототипе, может быть сложно или дорого в реализации.

32. ИНКРЕМЕНТНАЯ МОДЕЛЬ

№5
ИНКРЕМЕНТНАЯ МОДЕЛЬ
При инкрементной модели (англ. increment – увеличение, приращение) ПО разрабатывается с линейной
последовательностью стадий, но в несколько инкрементов (версий). В начале определяются
основные требования к ПО. Далее выполняется разработка в виде версий. Каждая версия является
законченным и работоспособным ПО. Первая версия реализует часть запланированных возможностей,
следующая версия реализует доп. возможности и т.д. пока не будет получено готовое ПО.

33.

Таким образом, в инкрементной модели улучшение продукта проходит
запланировано всё время пока жизненный цикл разработки ПО не завершится.
Данная модель ЖЦ характерна при разработке сложных и комплексных систем,
для которых имеется четкое видение (как со стороны заказчика, так и со стороны
разработчика) того, что собой должен представлять конечный результат.
Разработка версиями ведётся в силу разного рода причин:
- отсутствия у заказчика возможности сразу профинансировать весь
дорогостоящий проект;
- отсутствия у разработчика необходимых ресурсов для реализации сложного
проекта в сжатые сроки;
- требований поэтапного внедрения и освоения продукта конечными
пользователями. Внедрение всей системы сразу может вызвать у ее пользователей
неприятие и только «затормозит» процесс перехода на новые технологии. Образно
говоря, они могут просто «не переварить большой кусок, поэтому его надо
измельчить и давать по частям».
Подходит проектам, где важно быстро выйти на минимально рабочий
результат и поэтапно развивать функциональность, сохраняя стабильность и
контакт с пользователями. Обычно используется при разработке вебприложений и среди продуктовых компаний.

34.

ПЛЮСЫ ИНКРЕМЕНТНОЙ МОДЕЛИ:
• гибкость при изменении требований, разработчики вносят правки
на каждом этапе;
• заказчик может дать свой отзыв по каждой версии ПО;
• параллельная работа над разными модулями. Одни делают
функционал, другие — интерфейс и интеграции;
• привыкание заказчика к новому ПО происходит постепенно.
МИНУСЫ:
• надёжная архитектура нужна с самого начала. Иначе новый
инкремент может ломать логику ПО и мешать масштабированию;
• при постоянных изменениях структура ПО может быть
нарушена;
• нужна хорошо организованная команда, чтобы параллельная
работа шла слаженно, без конфликта между модулями и людьми.

35. СПИРАЛЬНАЯ МОДЕЛЬ

№6
СПИРАЛЬНАЯ МОДЕЛЬ
Здесь ЖЦ разработки ПО изображается
в виде спирали, которая, начавшись на
этапе формирования требований,
раскручивается с прохождением
каждого следующего шага. Таким
образом, на выходе из очередного
витка получаем готовый
протестированный прототип, который
дополняет существующую сборку.
Прототип, удовлетворяющий всем
требованиям, готов к выпуску.
В спиральной модели (1986-88 гг., автор Барри Боэм) разработка ПО идет в
виде последовательности версий, но в начале проекта определены не все
требования. Они уточняются в процессе разработки версий.

36. СПИРАЛЬНАЯ МОДЕЛЬ

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

37.

ПЛЮСЫ СПИРАЛЬНОЙ МОДЕЛИ:
• управление рисками на каждом этапе;
• гибкость в изменении требований, доп. функции можно
добавить на поздних этапах;
• пошаговая проверка: команда регулярно получает
отзывы, тестирует продукт и вносит улучшения .
МИНУСЫ:
• оценка рисков на каждом этапе является затратной;
• постоянные отзывы и реакция заказчика приводят к
новым итерациям, затягивающим разработку ПО;
• высокие требования к квалификации команды,
умеющей адаптироваться в условиях неопределённости.

38.

Сравнение моделей жизненного цикла

39.

РЕКОМЕНДАЦИЯ
Книга двух американских инженеров-программистов Тома
Демарко, Тимоти Листера "Человеческий фактор. Успешные
проекты и команды» – всемирно известный бестселлер об
управлении IT-проектами.
Уникальное озарение этой книги: «Самые сложные
проблемы разработки ПО носят не технический, а социальный
характер. Эти человеческие проблемы решать не просто, но,
решив их, вы увеличите шансы на успех».
Книга показывает патологии лидерства; культуру собраний;
гибридные команды из людей разных, несовместимых
поколений; понимание того, что некоторые наши инструменты
служат якорями, а не двигателями.
Книга для руководителей IT-проектов и программистов,
которые найдут на страницах этой книги множество ценных
советов.

40.

Домашнее задание (краткий конспект)
1. По каким критериям можно классифицировать проекты?
2. Что такое жизненный цикл проекта?
3. Для чего составляется список пользователей программного продукта?
4. Кто такие заинтересованные лица проекта?
5. Какими методами осуществляется выявление потребностей заинтересованных лиц?
6. Всегда ли заказчик проекта имеет представление о реальных потребностях?
7. С какой целью проводится анализ аналогов разрабатываемого программного
продукта.
8. Сколько и какие этапы бывают в ЖЦ проектов?
9. Перечислите модели ЖЦ разработки ПО?
10. Какие модели ЖЦ относятся к гибким (agile) методологиям, а какие к жёстким?
11. Напишите список программ для создания мокапов.
12. Перечислите тестовые среды для тестирования ПО.
13. От чего зависит выбор модели ЖЦ ПО?
14. Запишите плюсы и минусы всех пройденных на лекции моделей ЖЦ ПО (если мы не
успели их записать на лекции. Ответы смотри в лекции).

41.

МОТИВАЦИЯ