Жизненный цикл ПО (Software development life cycle)
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для Вас с целью персонализации сервисов и предложений. Вы можете прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом без изменения настроек, вы даёте согласие на использование ваших cookie-файлов.
speech bubble

Жизненный цикл ПО (Software development life cycle)

Жизненный цикл ПО (Software development life cycle)

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

Жизненный цикл ПО (Software development life cycle) — этапы событий, происходящие с системой/компонентом/модулем в ходе анализа, создания, разработки и последующей эксплуатации и поддержки.

Рассматривать будем концептуальную модель SDLC на примере этапов каскадной модели:

 

 

1. Идея(Idea). Каждый продукт начинается с идеи. Появляется человек, группа людей, называемые хозяином продукта (Product owner) со своим видением проблем, либо уникального проекта и они обращаются в компанию для её реализации.

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

2. Анализ идеи(Analysis). Этап в жизненном цикле необходим из-за ряда причин: сырой идеи, технической неграмотности заказчика в определенных сферах, обсуждения рисков и рентабельности воплощения, помощи в улучшении проекта. Для решения вопросов вступают бизнес и системные аналитики для выяснения максимальных сведений об идее product owner с пониманием конечной реализации продукта. Результатом этапа является system requirements specification (Техническое направление SRS) и/или business requirements documentation (Описывается в виде user case BRD) – набор требований к разрабатываемому продукту.

3. Архитектура и дизайн (Architecture and design). Основываясь на знаниях предыдущего шага SDLC, этап обуславливается проектированием и архитектурой продукта: языки программирования, базы данных, технологии, потребность в ресурсах, взаимосвязь и взаимодействие различных подсистем, проблемы с безопасностью и так далее.

4. Разработка (Development). Разработчики знакомятся с требованиями, архитектурой и начинают писать продукт. Первая разработка проходит до тех пор, пока не появится на выходе запускаемое ПО (build), которое приблизительно похоже на заявленный проект и готовое к тестированию.

5. Тестирование (Testing). Тестирование продукта/модуля/компонента с последующим предоставлением информации о результатах в виде репортов(report), баг-репортов(bug-report), метрики (metrics).

6. Исправление найденных дефектов (Bug fixing). Разработчики исправляют найденные дефекты, предоставляют результаты.

7. Верификация(Verification). Этап в SDLC служит для проверки тестировщиками пофиксенных багов с этапа 6. Шаг обусловлен появлением цикла между 6 и 7 пунктами в случае, если исправленный баг разработчиками не был устранен. В конечном итоге получается RCS build (Release candidate build), в котором реализована весь/большая часть функционала по заявленным требованиям, незначительные дефекты согласованы. Не все дефекты могут быть устранены из-за сложности продукта, их незначительности или сроков.

8. Приемочное тестирование (Accepting testing). Шаг, служащий для определения качества разрабатываемого продукта/модуля/компонента на основании приемочных критериев, прописанных на этапе проектирования проекта в тест-плане, например, количество найденных дефектов, пропускаемых в релиз с оговорками их исправления.

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

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

9. Релиз (Release). Предоставление готового продукта пользователям.

10. Поддержка (Support). Опциональный шаг в цикле. В некоторых случаях, реализиванное ПО не поддерживается в дальнейшем.

11. Окончание (End). Окончание поддержки программы и её использования юзерами.

Для комментирования необходимо авторизоваться