SDLC

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

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 или итерационной, являются лишь упрощенной схемой, которая не учитывает всех нюансов конкретного продукта.

(рейтинг: 5, голосов: 2)
Добавить комментарий