SDLC (Software Development Life Cycle — жизненный цикл разработки программного обеспечения) — набор этапов, через которые проходит разработка ПО, чтобы создать работающее приложение. Еще его можно назвать «Уставом» разработчиков, который определяет все этапы разработки программного обеспечения, от планирования до тестирования и внедрения. Так же как и настоящие армейские уставы он соблюдается далеко не всегда и во всех случаях. И, так же как и с уставом, на него опираются для организации работы больших команд.
Стоит сразу отметить, что даже в случае индивидуальных проектов любая работа будет гораздо эффективнее при предварительном планировании. Вам наверняка не понадобится формальный проект, если вы разрабатываете приложение с друзьями. Но если нужно подключить специалистов, будет необходимо получить финансирование инвесторов и организовать работу профессиональной команды, то без записанных и утвержденных правил совместной работы не обойтись.
Вы бросили учебу. Часть 2: как довести начатое до конца
В первой статье мы расскажем про SDLC и о том, как эти знания помогут лучше понять мир разработки. Во второй статье мы поделимся информацией о том, какие роли выполняют специалисты на каждом этапе SDLC.
Что такое SDLC
Преимущества и недостатки SDLC
По уставу или по-человечески?
Что такое SDLC
Методология SDLC появилась в 1970-е годы — у нее множество “отцов” и одним из них является инженер Уинстон Ройс. Его целями, среди прочего, были сокращение рисков при разработке дорогостоящего программного обеспечения, снижение хаоса, соответствие софта требованиям заказчиков и устранение необоснованных расходов. Этих благородных целей проектные менеджеры пытаются добиться и сейчас, спустя более чем 40 лет.
Знаковый для сферы IT труд Уинстона Ройса под названием “Управление разработкой крупных программных систем” вышел в 1970 году. Он предлагал, чтобы команды вели разработку софта в определенном порядке. Первым делом собирались системные требования (требования к “железу”. Затем требования к программному обеспечению. После этого следовали:
- Анализ: Проводился анализ требований для понимания, как должна работать система.
- Проектирование программы: Создавалась архитектура и структура будущего программного обеспечения.
- Кодирование: Писался программный код, воплощающий идеи и архитектуру в работающую программу.
- Тестирование: Проверялась работоспособность системы и исправлялись выявленные ошибки.
- Эксплуатация: Программа внедрялась и начинала работать в реальных условиях.
Из иллюстрации можно понять, почему методологию назвали “Водопадом”. Ее, с некоторыми изменениями, использовала NASA, из-за критического характера их программ, где малейшая ошибка или оплошность могут привести к катастрофическим последствиям.
Методология Waterfall по-прежнему используется для разработки, где критически важна предсказуемость и строгий контроль над процессами. Она особенно востребована в проектах с фиксированными требованиями и сроками, таких как проекты в оборонной промышленности или государственные системы, где каждая стадия должна быть завершена перед началом следующей. Примеры подобных проектов включают разработку медицинского оборудования или программного обеспечения для государственных структур, где строгие нормативные требования диктуют необходимость каскадного подхода.
Scrum плюс Agile: что такое гибкая методология разработки?
Преимущества и недостатки SDLC
Одним из преимуществ Waterfall является четкое планирование на каждом этапе, что позволяет избегать неопределенности и обеспечивает прозрачность процесса разработки. Однако, строгая последовательность стадий и невозможность внесения изменений на поздних этапах делает Waterfall менее подходящей для проектов, которые требуют гибкости и быстрой адаптации. Именно поэтому многие современные команды выбирают гибкие подходы, такие как Agile, особенно в условиях быстро меняющихся требований заказчика.
Но даже если вы не будете работать в команде, придерживающейся каскадного метода, понимание SDLC поможет лучше понять процессы разработки, разобраться в командных ролях и эффективно взаимодействовать с коллегами. Это знание станет основой, на которой можно строить понимание различных гибких методологий (Scrum, Extreme Programming) и адаптироваться к любым условиям.
По уставу или по-человечески?
Даже сам Уильям Ройс предупреждал своих будущих последователей, что слишком строгое следование модели “обречено на провал”. В те годы изменения на стадии разработки обходились организациям в большие суммы. Но и сейчас достаточно сложно что-то поменять в продукте, если нет договоренностей с командой разработчиков “на берегу”. Допускать таких ситуация не хочет никто, поэтому было создано достаточно много гибких подходов к организации работы разработчиков, объединенных под названием Agile (гибкие).
Что такое жизненный цикл продукта
Различия между методологиями объясняет бизнес-аналитик Ануар Адильжан.
“Waterfall — это четкий, неизменяемый процесс. Например, мы не примем задачу в работу, пока нет сформулированных требований. Двигаемся строго по процессу. Если заказчик за день до выката просит что-то поменять, мы откажем — уже все. Новую задачу делаем “с нуля”.
Agile позволяет быть более гибкими. Если не хватает функций, добавляются новые требования, можно сделать круг и вернуться к задаче позже. Scrum (гибкая методология) предусматривает работу по спринтам (двухнедельные циклы). В эти две недели ничего не меняется, но раз в две недели можно вносить изменения. Если прям просят поменять за день до выката, говорим “Без проблем”, двигаем выкат на три дня вперед, вносим изменения.
Есть еще и “Канбан” (Kanban — с японского переводится как “Можешь ли ты это видеть?”). Все задачи размещаем списком на доску (может быть обычной доской или виртуальной, как в Trello, Jira или Darlean.kz), оттуда их берут в работу по приоритету. Это настоящий хаос, потому что приоритеты меняются и ты не можешь сосредоточиться на задаче. На моем опыте: “Выполняешь одну задачу, сверху “прилетает” еще три”, — делится он.
