Сегодня в рамках обучения начинающих аналитиков разберем типовые этапы и стандарты жизненного цикла программного обеспечения. Читайте далее про SDLC и модели разработки ПО, реализующие движение по его этапам, чем они отличаются от методологий и при чем здесь Agile, а также где место системного и бизнес-аналитиков в Software Development Life Cycle.
Что такое SDLC и где в нем место аналитику
Как следует из названия, Software Development Life Cycle (SDLC) – это жизненный цикл программного обеспечения из набора типовых этапов, переход между которыми определяется моделью процессов разработки ПО. Подробно цель, выходы, действия и задачи каждого из этих процессов описан в международном стандарте ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes». Российским аналогом этого документа является ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», принятый Федеральным агентством по техническому регулированию и метрологии РФ в 2012 году взамен ГОСТ Р ИСО/МЭК 12207-99. Эти стандарты подробно описывают более 40 процессов ЖЦ ПО, от организационного обеспечения проекта до повторного применения программных средств, сгруппированные в 7 категорий. Эти регламенты очень детальны и универсальны, т.е. подходят для любого прикладного кейса. Обратной стороной этих достоинств является большой объем документов. Поэтому начинающим аналитикам легче понять основные процессы ЖЦ ПО на примере этапов SDLC:
- Планирование – где владелец продукта отвечает на вопрос «Что нужно сделать?», а руководитель проекта – на вопрос «Как это сделать». Здесь также может принимать участие и бизнес-аналитик, чтобы понять потребности и перевести их в бизнес-требования.
- Анализ – определение и документирование требований в виде ТЗ на разработку ПО и/или спецификации, что является основной рабочей обязанностью бизнес-аналитика;
- Проектирование – определение дизайна и архитектуры ПО, а также другие особенности реализации, например, UI/UX-дизайн. Помимо ИТ-архитектора и дизайнеров, здесь работает системный аналитик, уточняя и дополняя требования от бизнес-аналитика. На практике обязанности системного и бизнес-аналитика может выполнять один человек.
- Разработка – непосредственная реализация всех запланированных требований, что делают программисты/разработчики ПО.
- Тестирование и развертывание – после того, как тестировщики проверят представленный разработчиками результат на соответствие требованиям и отсутствие ошибок, к делу приступают DevOps-инженеры и администраторы, которые разворачивают продукт в реальной среде эксплуатации (production).
- Поддержка и сопровождение – работающий продукт сопровождают администраторы и специалисты технической поддержки. Также здесь и на предыдущем этапе технические писатели создают руководства пользователя и администратора, а также прочую программную документацию, предусмотренную контрактом на этапе планирования.
При том, что набор перечисленных этапов SDLC отражает жизненный цикл ПО, переход между этапами не всегда выполняется строго последовательно. За особенности движения по этапам SDLC отвечают модели разработки ПО, которые мы рассмотрим далее.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Agile-подход, методологии и модели разработки ПО
Наиболее известными моделями разработки ПО, по-разному реализующими движение по этапам Software Development Life Cycle являются следующие:
- Водопадная (каскадная) – каждый следующий этап SDLC начинается только по завершении предыдущего. Например, разработка начинается только по утвержденному проектному решению, где полностью описаны все требования к системе. А тестирование стартует после разработки, поэтому стоимость ошибки, допущенной на ранних этапах, таких как отсутствие требования или его некорректное описание, многократно возрастает. Эта модель подходит для проектов с четко и подробно проработанной документальной базой по всем возможным сценариям, в медицине или военно-космической промышленности.
- V-образная – реализует последовательное движение по этапам SDLC с принципом разработки через тестирование (TDD, Test Driven Development). По сути, это усовершенствованная каскадная модель, где одновременно с выполнением каждого этапа SDLC разрабатываются тесты, описывающие проверку его корректного выполнения. V-модель подходит для проектов, где важна надёжность и цена ошибки очень высока. Например, разработка систем обеспечения безопасности в транспорте или мониторинга за жизненно важными параметрами человеческого организма в реанимации.
- Итерационная – когда на этапе планирования и анализа описываются не все требования к продукту, а только базовые, которые составляют его «ядро», реализующее основную суть. Такой минимально жизнеспособный продукт (MVP, Minimal Viable Product) можно быстро выпустить на рынок, протестировать на реальных пользователях и собрать от них обратную связь, чтобы далее исправить не найденные штатными тестировщиками ошибки и добавить новые полезные функции. Итерационная модель подходит для больших проектов с неопределёнными требованиями и инновационных задач.
- Инкрементная – эта модель похожа на итерационную, т.к. здесь разработка тоже выполняется частями. Однако, в случае итеративной модели полный список требований на старте отсутствует и прорабатывается по мере выпусков MVP, а в инкрементной модели он имеется сразу и воплощается частями – релизами, каждый из которых полностью проходит все этапы SDLC. Так, подобно тому как из кусочков пазла складывается целая картинка, инкрементная разработка по мере выпуска каждого релиза приближает продукт к полной готовности. Инкрементная модель подходит для проектов с полным набором требований к результату и быстрым выводом продукта на рынок.
- Спиральная – проект тоже реализуется итерациями. Движение по этапам SDLC подобно спирали, где каждая последующая стадия основывается на предыдущей, а в конце витка (цикла итераций) принимается решение о дальнейшей разработке. Спиральная модель похожа на инкрементную, но гораздо больше внимания уделяет оценке рисков: с каждым новым витком спирали процессы разработки ПО усложняются и расширяются. Эта модель подходит для исследований и проектов с высокими рисками.
Все эти модели (кроме водопадной) поддерживают различные методологии разработки (Scrum, Kanban, RUP, DSDM, FDD, XP, Crystal Clear), совокупность которых называют гибким подходом (Agile), главные принципы которого описаны в Agile Manifesto и направлены на быстрый выпуск продукта на рынок (сокращение TTM, Time-to-Market) за счет эффективного взаимодействия самоорганизованной команды. Говоря в терминах ООП, что мы разбирали в предыдущей статье, гибкие методологии являются классами, реализующими интерфейс Agile. А классы различных моделей разработки ПО реализуют интерфейс SDLC и связаны с методологиями через ассоциации. При этом отдельные методологии и модели разработки ПО можно считать объектами этих классов. Подробнее про UML и основы ООП читайте здесь. А в этой статье вы узнаете, чем Scrum отличается от Kanban, и что между ними общего,
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Более подробно о принципах и практиках Agile вы узнаете на курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика», а освоить тонкости разработки требований к ПО с учетом различных моделей SDLC вам помогут другие курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
