Жизненный цикл разработки ПО, фазы, процессы, модели.

Что такое Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC)

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

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

Что вы узнаете:
Процесс жизненного цикла разработки ПО

Циклы разработки ПО

Фазы разработки ПО
1) Сбор и анализ требований
2) Дизайн
3) Программирование и внедрение
4) Тестирование
5) Установка
6) Поддержка
Модели жизненного цикла разработки ПО
1) Водопадная модель
2) V-образная
3) Прототипная модель
4) Спиральная
5) Итеративно -инкрементальная модель
6) Модель большого взрыва
7) Agile модель
Выводы
Рекомендации

Процесс жизненного цикла разработки ПО

Жизненный цикл разработки ПО это процесс который определяет различные этапы включенные в разработку ПО для поставки высококачественного продукта. Этапы SDLC включают все этапы жизненного цикла ПО, т.е. от зарождения до вывода продукта из работы.

Соблюдение рекомендаций SDLC ведет к систематической и дисциплинированной разработке программного обеспечения.

Цель:
Основная цель SDLC поставка высококачественного продукта который соответствует требованиями заказчика.

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

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

Циклы разработки ПО
Этапы SDLC представляют собой процесс разработки ПО.

Внизу представлена диаграмма описывающая основные этапы SDLC

Этапы SDLC
Ниже представлены основные этапы разработки:

• Сбор и анализ требований
• Дизайн
• Программирование
• Тестирование
• Установка
• Поддержка

#1) Сбор и анализ требований

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

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

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

Как только требования ясно представлены и поняты создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. Данный документ должен быть тщательно изучен и правильно понят разработчиками и самим клиентом.

#2) Дизайн
На данном этапе, требования зафиксированные в Спецификации используются как исходные данные для создания архитектуры, которая используется при разработке приложения.

#3) Программирование
Программирование начинается как только разработчик получил документ с архитектурой продукта. Дизайн ПО интерпретируется в код. На данном этапе создаются все компоненты ПО.

#4) Тестирование
Тестирование начинается как только завершено программирование и модули готовы для тестирования. На данном этапе, разработанное ПО тщательно тестируется и все найденные баги передаются команде разработчиков для исправления.

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

#4) Установка

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

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

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

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

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

#1) Водопадная модель

Водопадная модель первая модель из ряда SDLC. Ее также называют линейной последовательной моделью, каскадная моделью.

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

• Первое, сбор и анализ требований завершен. Когда требования утверждены, далее может начинаться создание системного Дизайна или Архитектуры приложения. Здесь создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. То есть Спецификация является итогом сбора требований, и служит основой для создания  системного Дизайна или Архитектуры приложения.
• На этапе системного Дизайна или Архитектуры приложения, создаются документы которые служат основной для следующего этапа  — Программирования.
• На этапе Программирования команда разработки пишет код, создает компоненты приложения. Результат работы команды разработки служит для запуска следующего этапа — Тестирование.
• На этапе тестирования, полученный продукт тщательно тестируется на предмет наличия ошибок. Баги заносятся в системе баг-трекинга (Система отслеживания ошибок) и проходят повторное тестирование после исправления.  Фиксирование багов, повторное тестирование, регрессионное тестирование проводится до тех пор, пока ПО не переходит в рабочее состояние, пока не начинает корректно работать.
• На этапе Установки, разработанное приложение запускается в эксплуатацию после одобрения заказчиком.
• Все проблемы возникающие в процессе эксплуатации решаются командой разработки в рамках Поддержки.

Преимущества Водопадной модели:

• Водопадная модель это простая модель которая может быть легко понята и она одна где все этапы выполняются пошагово.
• Поставка каждого этапа (результаты) хорошо определены и понятны, это делает проект легко управляемым и не сложным.

Недостатки Водопадной модели:

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

#2) V-образная  модель

V-образная также известна как Модель Верификации и Валидации. В данной модели Верификация и Валидация идут вместе т.е. разработка и тестирование идут параллельно. V-образная и Водопадная модель похожи за исключением что планирование тестирования и процесс тестирования начинается на ранних этапах в  V-образной  модели.

Этап Верификации:

1. Сбор и анализ требований
   На данном этапе, собирается вся необходимая информация собирается и анализируется. Верификация заключается в проверке, обзоре требований.

2. Системный дизайн
   Как только определены требования, начинается проектирования дизайна т.е. архитектура приложения, компоненты продукта. Создается документ с описанием дизайна продукта.
   
3. Высокоуровневый дизайн
   Высокоуровневый дизайн определяет архитектуру/дизайн модулей. Он определяет взаимодействие (функциональность) между двумя модулями.
   
4. Низкоуровневый дизайн
   Низкоуровневый дизайн определяет архитектуру/дизайн отдельных компонентов.
   
5. Программирование
   На данном этапе осуществляется программирование.
   
   Этап Валидации:

1)  Юнит — тестирование
Юнит — тестирование (Модульное тестирование) выполняется с использованием сценариев модульного тестирования, которые разработаны и выполняются на этапе низкоуровневого проектирования. Модульное тестирование выполняет сам разработчик. Он выполняется на отдельных компонентах, что приводит к раннему обнаружению дефектов.

2) Интеграционное тестирование
Интеграционное тестирование выполняется используя интеграционные тест кейсы на этапе разработки высокоуровневого дизайна. Интеграционное тестирование — это тестирование интегрированных модулей. Производится тестировщиками.

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

4) Приемочное тестирование
Приемочное тестирование связано с этапом Анализом требований и производится в рабочей среде заказчика.

Преимущества V-образной  модели

• Простая и легкая для понимания модель
• Подход V-образная  модели хорошо подходит для небольших проектов где требования определены и зафиксированы на ранних этапах
• Это системная и дисциплинированная модель результатом которой является высококачественный продукт.

Недостатки  V-образной  модели

• V-образная не подходит проектов в разработка (текущих проектов)
• Изменение требований на более позднем этапе приведут к повышению издержек.
  

#3) Прототипная модель разработки ПО

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

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

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

Как только завершили процесс сбора требований, в скором времени создается первая версия прототипа которая предоставляется клиенту для оценки (билд).

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

Преимущества Прототипной  модели

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

Недостатки  Прототипной    модели

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

#4) Спиральная модель

Спиральная модель включает итеративный и прототипный подходы.
Этапы спиральной модели следуют по итерациям. Петли данной модели представляют этапы SDLC (Software Development Life Cycle, Модели жизненного цикла разработки ПО) т.е. ключевой момент — сбор и анализ требований за которым следуют Планирование, Анализ рисков, разработка и оценка качества. Следующая петля это Разработка Дизайна и следующими за ней Разработка и тестирование.

У спиральной модели есть четыре этапа:
Планирование
Анализ рисков
Разработка
Оценка

Планирование:
Этап планирования включает в себя сбор  требований где вся необходимая информация собирается у клиента и документируется. Спецификация требований к программному обеспечению создается на следующем этапе.


Анализ рисков:
На этом этапе выбирается лучшее решение с учетом имеющихся рисков и проводится анализ путем создания прототипа.

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

Разработка:
Как только завершен анализ рисков, следует программирование и тестирование.

Оценка:
Клиент оценивает разработанную систему и планируется следующая итерация.

Преимущества Спиральной  модели

• Широко применяется анализ рисков через использование прототипной модели.
• Добавление новых свойств и изменение функционала могут быть выполнены при следующей итерации.

Недостатки  Спиральной    модели

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

#5) Итеративно инкрементальная модель

Итеративно инкрементальная модель предполагает декомпозицию продукта на небольшие задачи.

Пример: Определен и разработан функционал который будет реализован в рамках итерации. Каждая интеграция проходит этапы Анализ требований, Дизайн, Программирование и Тестирование. Детализированный план не требуется в итерации.

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

Следовательно, продукт увеличивается с точки зрения функций, и после завершения итераций окончательная сборка содержит все функции продукта.

Этапы итеративно инкрементной модели:

• Начальный этап
• Этап разработки
• Этап Создания
• Переходный этап

Начальный этап
Начальный этап включает в себя сбор требований и определение рамок проекта

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

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

Переходный этап
На переходном этапе продукт устанавливается в рабочем окружении клиента.

Преимущества итеративно инкрементной  модели

• Любое изменение требования может быть легко выполнено и не требует затрат, поскольку есть возможность включить новое требование в следующую итерацию.
• В итерациях идентифицируется и анализируется риск
• Баги обнаруживаются на ранних этапах
• Так как продукт декомпозирован на мелкие задачи им легко управлять

Недостатки  итеративно инкрементной    модели

• Полные требования и понимание продукта необходимы для декомпозиции и разработки.

#6) Модель большого взрыва

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

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

Преимущества модели Большого взрыва

• Очень простая модель.
• Не требуется планирования и определенного процесса.
• Команде разработки предоставлена свобода по созданию продукта как -будто для себя.
• Так как продукт декомпозирован на мелкие задачи им легко управлять

Недостатки  модели Большого взрыва

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

#7) Agile модель
Agile модель это комбинация итеративной и инкрементальной модели разработки. Данная модель скорее сосредоточена на гибкости во время создания продукта, чем на требованиях.

В модели  Agile продукт разбивается/декомпозируется на малые инкрементальные сборки (билды). Продукт не разрабатывается как сложная система за один подход. Каждая сборка увеличивается количество функций. Каждая последующая сборка строится на предыдущей функциональности.

В Agile итерации называются спринтами. Каждый спринт длится 2-4 недели. В конце каждого спринта владелец продукта проверяет продукт и после его подтверждения, продукт загружается для клиентов.

Обратная связь клиентов учитывается для улучшения продукта и обрабатывается в следующем спринте. Тестирование проводится в каждом спринте для минимизации риска и отказов.

Преимущества модели Agile

• Это позволяет более гибко адаптироваться к изменениям.
• Новую функцию можно легко добавить.
• Удовлетворенность клиентов, отзывы и предложения принимаются во внимание на каждом этапе.

Недостатки  модели Agile

• Отсутствие документации.
• Для создания продукта нужны опытные и высококвалифицированные ресурсы.
• Если клиент не понимает, каким именно он хочет видеть продукт, проект провалится.

#Выводы.

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

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

Например, в случае неясного требования лучше всего использовать модели Spiral и Agile, поскольку требуемое изменение можно легко внести на любом этапе.

Водопадная модель является базовой моделью, и все остальные модели SDLC основаны только на ней.

Надеюсь, вы получили новые знания о SDLC.