Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Жизненный цикл разработки программного обеспечения (SDLC) — это эффективный процесс проектирования и разработки высококачественного ПО. Цель SDLC — минимизировать риски за счёт предварительного планирования, вследствие чего программное обеспечение будет соответствовать ожиданиям заказчика как во время производства, так и на других этапах.
SDLC включает в себя ряд этапов, представляющих последовательность шагов, необходимых для перехода от концепции к конечному результату. Ниже они будут рассмотрены подробнее.
Путём опроса заказчика собирается вся необходимая для разработки информация. На основании собранных требований формируется базовое представление о будущем продукте. Результатом данного этапа является спецификация требований к программному обеспечению — документ, устанавливающий ожидания и определяющий общие цели, которые помогают в планировании проекта.
На данном этапе формируется первичное представление о разрабатываемом продукте, и принимается решение о целесообразности его реализации без углубления в технические детали. Для этого выполняются:
После этого этапа может быть принято решение о прекращении работы над продуктом. В этом случае все дальнейшие этапы не выполняются.
Информация, полученная на предыдущих этапах, используется для определения архитектуры программного обеспечения. На этом этапе важно продумать все компоненты разрабатываемого ПО, т.к. их создание без наличия плана может привести с дорогостоящим исправлениям.
Результатом данного этапа являются два документа: высокоуровневый дизайн и низкоуровневый дизайн.
Высокоуровневый дизайн. Данный документ содержит:
Низкоуровневый дизайн. Данный документ содержит:
На этом этапе реализуются, отлаживаются и собираются в единое приложение все компоненты программного обеспечения в соответствии с HLD и LLD. На этапе отладки нередко используется статический анализ кода — процесс выявления значительной части ошибок и опечаток в коде с помощью такого специального программного инструмента, как статический анализатор кода.
На этом этапе разработанное программное обеспечение тщательно тестируется, а также проверяется на соответствие требованиям заказчика, изложенным в SRS-документе. Все обнаруженные дефекты передаются разработчикам для их исправления. Это повторяется до тех пор, пока все дефекты, которые удастся обнаружить, не будут исправлены, а ПО не будет соответствовать ожиданиям заказчика.
Развёртывание может быть единовременным или поэтапным в зависимости от того, какую бизнес-стратегию выбрали заказчик и разработчик. Часто первый релиз выпускается в ограниченном сегменте рынка для проведения пользовательского тестирования в реальной бизнес-среде. Получив отзывы от представителей целевой аудитории, разработчики при необходимости вносят дополнительные изменения в продукт, после чего публикуется полноценный релиз.
Заключительный этап охватывает все время существования ПО, начиная с его релиза. Теперь основное внимание уделяется обеспечению стабильной работы программного обеспечения, а также поддержанию его востребованности среди пользователей. Для этого осуществляется поддержка пользователей при решении проблем с продуктом, исправляются ошибки, регулярно выпускаются обновления с улучшениями, а также выполняются продвижение и популяризация продукта.
В стандартный SDLC тестирование безопасности не входит и выполняется отдельным процессом. Негативным следствием этого является то, что уязвимости обнаруживаются только после развёртывания программного обеспечения. Для устранения этого недостатка была разработана дополненная версия SDLC — SSDLC (Secure Software Development Lifecycle).
Этапы, описанные выше, не обязательно представляют собой строгую линейную последовательность. Они могут перекрываться, меняться местами, повторяться в зависимости от выбранной методологии SDLC. Ниже будут рассмотрены наиболее популярные модели SDLC.
Разработка программного обеспечения начинается с небольшого подмножества требований. На каждой последующей итерации добавляются новые требования, и создаётся новая версия программного обеспечения. И так до тех пор, пока не будет получена версия, готовая к производству. Визуальное представление итеративной модели вы наблюдали в самом начале страницы.
Каскадная модель — жёсткий линейный подход, при котором каждый этап SDLC проходится только раз в определённом порядке. Например, чтобы перейти на этап тестирования, нужно обязательно завершить этап разработки. А перед тем, как перейти к разработке, проект должен быть полностью спроектирован в рамках предыдущего этапа и т.д. Этот подход предполагает, что вся информация о проекте может быть известна заранее, что нереально в мире, где во время разработки возникают неожиданности, и требования постоянно меняются. Однако каскадный подход имеет своё место в критически важных проектах, где нет места компромиссам в отношении требований или качества конечного продукта.
При данной модели этап разработки делится на несколько итераций. На каждой из них выполняется анализ потенциальных проблем, которые могут возникнуть на следующей итерации разработки. На первой итерации реализуется минимально жизнеспособный прототип продукта. На каждой последующей используются наработки с предыдущей итерации для разработки более функционального прототипа. Это продолжается до тех пор, пока не будет получена версия ПО, приемлемого качества. После этого выполняется переход на следующий этап SDLC.
Гибкая разработка учитывает динамичную природу процесса разработки программного обеспечения, благодаря чему проблемы, связанные с изменением требований к ПО, сводятся к минимуму, даже если они возникли в середине разработки.
При использовании гибкой модели разработка проекта делится на несколько циклов (спринтов). За каждый цикл реализуется отдельная самодостаточная часть проекта, а не весь продукт целиком.
Благодаря такому подходу некоторые этапы SDLC могут выполняться параллельно. Так, например, реализованный компонент ПО может проходить этап тестирования, в то время как разработчики уже работают над следующим.
В конце каждой итерации выполняется согласование реализованного компонента с заказчиком. В результате этого принимается одно из следующих решений:
0
0
0
131
0
0