SDLC

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

Концепция SDLC начала формироваться в 60-х годах прошлого века в среде крупных бизнес-конгломератов, чья деятельность была основана на обработке больших данных и выполнении множества рутинных операций. Сегодня она объединяет в себе несколько гибких, итерационных и последовательных методологий, приспособленных для выполнения проектов различного масштаба и сложности.

Фазы жизненного цикла программного обеспечения

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

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

Проектирование архитектуры. SRS — это «дорожная карта» для разработчиков, с помощью которой они предлагают оптимальную архитектуру для будущего продукта. На базе требований из этого документа, как правило, определяется несколько подходов к разработке, которые фиксируются в DDS, документе проектирования. Он предлагается на рассмотрение всем участвующим в проекте сторонам, которые совместно оценивают такие критерии, как риски, прогнозируемая надежность продукта, модульность внутреннего дизайна, ограничения финансов и времени, и выбирают подходящий подход к проектированию. Он, в свою очередь, содержит четко определенные архитектурные блоки продукта, его связь и представление потока данных с внешними модулями (при их наличии).

Разработка. На этой стадии жизненного цикла осуществляется непосредственная работа по созданию и сборке продукта в соответствии с DDS. При наличии детализированного и организованного дизайна написание кода обычно не вызывает серьезных затруднений. В разработке применяются такие средства программирования, как компиляторы, интерпретаторы, отладчики и т.д. Код пишется на различных языках программирования высокого уровня — например C,  C++, Pascal, Java и PHP. Его выбор зависит от типа разрабатываемого ПО.

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

Развертывание и сопровождение. После проверки продукта на ошибки и их устранения он готов к релизу. Развертывание может быть единовременным или поэтапным — в зависимости от того, какую бизнес-стратегию выбрали заказчик и разработчик. Часто первый релиз выпускается в ограниченном сегменте рынка для проведения пользовательского тестирования (UAT) в реальной бизнес-среде. Получив отзывы от представителей целевой аудитории, разработчик далее публикует полноценный релиз без изменений или после соответствующей доработки. Обслуживание уже выпущенного на рынок продукта осуществляется в расчете на существующую клиентскую базу.

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

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

Условно модели разделяются на три основных категории:

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

Рассмотрим наиболее распространенные модели жизненного цикла ПО из каждой категории.

Модель кодирования и устранения ошибок

Она принадлежит к числу последовательных, была популярна в 1960–1970-е годы и на данный момент считается уже устаревшей. Тем не менее она все еще распространена в обучении программистов, например в вузах. Условно она подразделяется на несколько этапов:

• постановка задачи;
• выполнение задачи;
• проверка результатов.

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

Каскадная модель (водопад)

Она также относится к числу последовательных, применяется с 1970-х годов, но уже включает все нужные фазы жизненного цикла. Свое название она получила из-за того, что каждый новый этап начинается тогда, когда заканчивается предыдущий, — схематично это выглядит как каскадный водопад.

Преимущества:

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

Недостатки:

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

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

У «водопада» есть более совершенная версия — «водоворот». Его отличие заключается в том, что на каждом этапе присутствует обратная связь по продукту от заказчика. С одной стороны, это сокращает накопление ошибок, с другой — значительно увеличивает стоимость разработки.

Инкрементная модель

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

Преимущества:

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

Недостатки:

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

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

Итеративная модель

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

Преимущества:

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

Недостатки:

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

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

Agile

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

• SCRUM — команда разработчиков ежедневно собирается на небольшие (не более 15 минут) встречи, а в конце отчетного периода (обычно 1–2 недель) на большом собрании отчитывается о проделанной работе;
• Kanban — рабочий процесс визуализируется с помощью виртуальной доски, на которой отражены этапы разработки, прошедшие, текущие и запланированные задачи, которые можно свободно двигать в зависимости от изменяющихся требований.

Преимущества:

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

Недостатки:

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

На практике используется большее число различных моделей разработки информационных систем. Часто они комбинируются друг с другом, чтобы сократить издержки от их слабых сторон и увеличить эффективность от преимуществ каждой методологии. Также не следует абсолютно идеализировать каждую модель — ведь даже самые современные из них, вроде Agile или итерационной, являются лишь упрощенной схемой, которая не учитывает всех нюансов конкретного продукта.