Что такое SDLC Жизненный цикл разработки ПО

После того как создана документация по системе, разработка разбивается на модули (юниты), и начинается собственно написание кода. Подбираются инструменты, программные и аппаратные, описывается общая архитектура приложения. Спецификации системного дизайна, подготовленные на этом этапе, служат указаниями для следующего, четвертого, этапа. А на текущем, третьем этапе, при активном участии QA-департамента создается стратегия тестирования, в которой описывается, sdlc это что будет тестироваться, и как. После разработки продукта необходимо тестирование программного обеспечения, чтобы обеспечить его бесперебойную работу. Сегодня хочу рассказать какие этапы жизненного цикла программного обеспечения существуют на примере алгоритма Software Life Cycle Model (SLCM).

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

Модель «большого взрыва» фокусируется на всех типах ресурсов в разработке и кодировании программного обеспечения без какого-либо планирования или с очень незначительным планированием. В этом Тестирование программного обеспечения типе тестирования и разработки модели SDLC этап планируется параллельно. Таким образом, существуют этапы проверки SDLC на одной стороне и этап проверки на другой стороне. На этом этапе разработчик должен следовать определенным заранее определенным рекомендациям по кодированию. Им также необходимо использовать инструменты программирования например, компилятор, интерпретаторы, отладчик для генерации и реализации кода.

Программное прототипирование — приложение

Горизонтальный прототип отображает пользовательский интерфейс для продукта и дает более широкое представление о всей системе, не концентрируясь на внутренних функциях. Вертикальный прототип с другой стороны — это детальная проработка определенной функции или подсистемы в продукте. Prototype — это рабочая модель программного обеспечения https://deveducation.com/ с некоторыми ограниченными функциональными возможностями. Прототип не всегда содержит точную логику, используемую в реальном программном приложении, и требует дополнительных усилий при оценке усилий.

Разнообразие ‌моделей SDLC:​ от классики к инновациям

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

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

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

Концептуально разработка переходит от одной фазы к другой, подобно каскаду. В больших проектах и системах с множеством встраиваемых этапов/сегментов. Также известна как «фаза деплоя», наступает после успешного завершения тестирования.

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

Используя эволюционное прототипирование, хорошо понятные требования включаются в прототип, а требования добавляются по мере их понимания. Клиенту могут потребоваться некоторые изменения после того, как он увидит программное обеспечение. Тем не менее, процесс изменений довольно жесткий, и может быть нецелесообразно включать основные изменения в продукт в традиционном SDLC. Это очень реалистичный подход к разработке программного обеспечения. Теперь они все вместе называются Agile-методологиями после публикации Agile Manifesto в 2001 году. Agile модель считает, что каждый проект должен обрабатываться по-разному, а существующие методы должны быть адаптированы в соответствии с требованиями проекта.

Agile мыслительный процесс начался на ранней стадии разработки программного обеспечения и стал популярным со временем благодаря своей гибкости и адаптируемости. Модель Большого взрыва включает в себя сосредоточение всех возможных ресурсов на разработке и кодировании программного обеспечения, практически без планирования. Любые необходимые изменения могут или не должны обновлять программное обеспечение полностью. Приемочное тестирование связано с фазой анализа бизнес-требований и включает тестирование продукта в пользовательской среде. Приемочные тесты раскрывают проблемы совместимости с другими системами, доступными в пользовательской среде. Он также обнаруживает нефункциональные проблемы, такие как загрузка и дефекты производительности в реальной пользовательской среде.

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

Итак, теперь мы знаем, что разработка программного обеспечения на основе жизненного цикла разработки программного обеспечения (SDLC) является важной основой для более качественной и структурированной разработки ПО. От того как проведен SDLC (Software Development Life Cycle) — жизненный цикл разработки программного обеспечения зависит качество IT проекта. А неправильный подход к разработке программного обеспечения может привезти даже к провалу создаваемого продукта. Модель Большого взрыва — это модель SDLC, в которой мы не следуем никаким конкретным процессам. Эта модель Большого взрыва не соответствует процессу / процедуре, и требуется очень мало планирования. Даже заказчик не уверен, что именно он хочет, и требования выполняются на лету без особого анализа.

По своей сути жизненный цикл разработки программного обеспечения (SDLC) представляет собой методологию, обеспечивающую структурированный и стандартизированный процесс разработки программного обеспечения. Во время данного этапа собирается вся необходимая информация у клиента для разработки продукта соответствующего его ожиданиями. Перед созданием продукта очень важно понимание или знание продукта.Пример,  Клиент желает получить приложение которое включает перевод денег. На данном этапе создаются все компоненты ПО.#4) ТестированиеТестирование начинается как только завершено программирование и модули готовы для тестирования. Тестировщики сверяют Спецификацию и созданный продукт,  чтоб убедиться что ПО соответствует ожиданиям заказчика. Поскольку программное обеспечение развивается через последовательные циклы, тесты должны повторяться и расширяться для проверки каждой версии программного обеспечения.

Разработка прототипа может быть дополнительной нагрузкой в ​​таких проектах и ​​может потребовать много дополнительных усилий. Назначение как горизонтального, так и вертикального прототипа различно. Горизонтальные прототипы используются для получения дополнительной информации об уровне пользовательского интерфейса и бизнес-требованиях. Это может даже быть представлено в демоверсиях продаж, чтобы получить бизнес на рынке. Вертикальные прототипы носят технический характер и используются для получения подробной информации о точном функционировании подсистем. Например, требования к базе данных, взаимодействие и обработка данных загружаются в данную подсистему.

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

Сбор и анализ требований — Все возможные требования к разрабатываемой системе фиксируются на этом этапе и документируются в документе спецификации требований. Модель Waterfall — самый ранний подход SDLC, который использовался для разработки программного обеспечения. Как только продукт протестирован и готов к развертыванию, он официально выпускается на соответствующем рынке. Иногда развертывание продукта происходит поэтапно в соответствии с бизнес-стратегией этой организации.

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

На сегодняшний день используется более 50 признанных моделей SDLC. Но ни одна из них не идеальна, и каждая имеет свои преимущества и недостатки для конкретного проекта разработки программного обеспечения или команды. Данная модель делит разработку программного обеспечения на более мелкие итерации или этапы, и каждый этап включает планирование, проектирование, кодирование, тестирование и тд. Команда обычно быстро завершает каждую итерацию; после завершения они просматривают и оценивают программное обеспечение для уточнения и улучшения программного обеспечения для следующей итерации. Модель водопада — одна из наиболее классических моделей жизненного цикла, также называемая линейно-последовательной моделью жизненного цикла разработки ПО.