Жизненный цикл разработки программного обеспечения, для краткости SDLC, представляет собой четко определенную, структурированную последовательность этапов разработки программного обеспечения для разработки предполагаемого программного продукта.
Деятельность SDLC
SDLC предлагает ряд шагов, которые необходимо выполнить для эффективной разработки и разработки программного продукта. Каркас SDLC включает в себя следующие этапы:
связь
Это первый шаг, когда пользователь инициирует запрос на желаемый программный продукт. Он связывается с поставщиком услуг и пытается договориться об условиях. Он подает свой запрос в организацию, предоставляющую услуги, в письменном виде.
Сбор требований
Этот шаг вперед команда разработчиков программного обеспечения работает над продолжением проекта. Команда проводит дискуссии с различными заинтересованными сторонами из проблемной области и старается предоставить как можно больше информации об их требованиях. Требования рассматриваются и разделяются на пользовательские требования, системные требования и функциональные требования. Требования собраны с использованием ряда методов, как указано —
- изучение существующей или устаревшей системы и программного обеспечения,
- проведение опросов пользователей и разработчиков,
- ссылаясь на базу данных или
- Сбор ответов из анкет.
Технико-экономическое обоснование
После сбора требований команда разрабатывает примерный план процесса разработки программного обеспечения. На этом этапе команда анализирует, можно ли создать программное обеспечение для удовлетворения всех требований пользователя и существует ли вероятность того, что программное обеспечение больше не будет полезным. Выясняется, является ли проект финансово, практически и технологически осуществимым для организации. Существует множество доступных алгоритмов, которые помогают разработчикам сделать вывод о целесообразности программного проекта.
Системный анализ
На этом этапе разработчики решают план своего плана и стараются найти лучшую модель программного обеспечения, подходящую для проекта. Системный анализ включает в себя понимание ограничений программного продукта, проблем, связанных с системой обучения, или изменений, которые необходимо сделать в существующих системах, заранее, выявление и учет воздействия проекта на организацию и персонал и т. Д. Команда проекта анализирует масштаб проекта и планирует график и ресурсы соответственно.
Разработка программного обеспечения
Следующим шагом является полное знание требований и анализа на столе и разработка программного продукта. Входные данные от пользователей и информация, собранная на этапе сбора требований, являются входными данными этого этапа. Результат этого шага представлен в виде двух проектов; логический дизайн и физический дизайн. Инженеры производят метаданные и словари данных, логические диаграммы, диаграммы потоков данных и в некоторых случаях псевдокоды.
кодирование
Этот шаг также известен как этап программирования. Реализация разработки программного обеспечения начинается с написания программного кода на подходящем языке программирования и эффективной разработки безошибочных исполняемых программ.
тестирование
По оценкам, 50% всего процесса разработки программного обеспечения должно быть проверено. Ошибки могут испортить программное обеспечение с критического уровня до его удаления. Тестирование программного обеспечения выполняется разработчиками во время кодирования, а тщательное тестирование проводится экспертами на разных уровнях кода, таких как тестирование модулей, тестирование программ, тестирование продукта, внутреннее тестирование и тестирование продукта на стороне пользователя. Раннее обнаружение ошибок и их устранение — ключ к надежному программному обеспечению.
интеграция
Может потребоваться интеграция программного обеспечения с библиотеками, базами данных и другими программами. Этот этап SDLC связан с интеграцией программного обеспечения с объектами внешнего мира.
Реализация
Это означает установку программного обеспечения на компьютерах пользователей. Иногда программное обеспечение нуждается в настройках после установки на стороне пользователя. Программное обеспечение тестируется на мобильность и адаптивность, а проблемы, связанные с интеграцией, решаются в ходе реализации.
Эксплуатация и техническое обслуживание
Этот этап подтверждает работу программного обеспечения с точки зрения большей эффективности и меньшего количества ошибок. При необходимости пользователи проходят обучение или получают помощь по документации о том, как работать с программным обеспечением и как его поддерживать. Программное обеспечение поддерживается своевременно путем обновления кода в соответствии с изменениями, происходящими в пользовательской среде или технологии. Эта фаза может столкнуться с проблемами из-за скрытых ошибок и реальных неопознанных проблем.
диспозиция
С течением времени программное обеспечение может ухудшиться в плане производительности. Это может полностью устареть или может потребовать интенсивного обновления. Следовательно возникает насущная необходимость устранить основную часть системы. Этот этап включает в себя архивирование данных и необходимых программных компонентов, закрытие системы, планирование действий по утилизации и завершение работы системы в соответствующее время окончания системы.
Парадигма разработки программного обеспечения
Парадигма разработки программного обеспечения помогает разработчику выбрать стратегию разработки программного обеспечения. Парадигма разработки программного обеспечения имеет свой собственный набор инструментов, методов и процедур, которые четко выражены и определяют жизненный цикл разработки программного обеспечения. Несколько парадигм разработки программного обеспечения или моделей процессов определены следующим образом:
Модель водопада
Модель «Водопад» — самая простая модель парадигмы разработки программного обеспечения. В нем говорится, что все фазы SDLC будут функционировать один за другим линейно. То есть, когда первая фаза закончена, тогда только вторая фаза начнется и так далее.
Эта модель предполагает, что все выполнено и выполнено идеально, как и планировалось на предыдущем этапе, и нет необходимости думать о прошлых проблемах, которые могут возникнуть на следующем этапе. Эта модель не работает гладко, если на предыдущем шаге остались некоторые проблемы. Последовательный характер модели не позволяет нам вернуться назад и отменить или повторить наши действия.
Эта модель лучше всего подходит, когда разработчики уже проектировали и разрабатывали подобное программное обеспечение в прошлом и знают все его области.
Итерационная модель
Эта модель ведет процесс разработки программного обеспечения в итерациях. Он проектирует процесс разработки циклически, повторяя каждый шаг после каждого цикла процесса SDLC.
Программное обеспечение сначала разрабатывается в очень небольших масштабах, и выполняются все этапы, которые принимаются во внимание. Затем на каждой следующей итерации все больше функций и модулей разрабатываются, кодируются, тестируются и добавляются в программное обеспечение. Каждый цикл производит программное обеспечение, которое само по себе полно и имеет больше возможностей и возможностей, чем в предыдущем.
После каждой итерации управленческая команда может выполнить работу по управлению рисками и подготовиться к следующей итерации. Поскольку цикл включает в себя небольшую часть всего процесса разработки программного обеспечения, легче управлять процессом разработки, но он потребляет больше ресурсов.
Спиральная модель
Спиральная модель представляет собой комбинацию итерационной модели и модели SDLC. Это может выглядеть так, как будто вы выбираете одну модель SDLC и комбинируете ее с циклическим процессом (итерационная модель).
Эта модель учитывает риск, который часто остается незамеченным большинством других моделей. Модель начинается с определения целей и ограничений программного обеспечения в начале одной итерации. Следующим этапом является создание прототипа программного обеспечения. Это включает в себя анализ рисков. Затем для построения программного обеспечения используется одна стандартная модель SDLC. На четвертом этапе готовится план следующей итерации.
V — модель
Основным недостатком модели водопада является то, что мы переходим к следующему этапу только тогда, когда предыдущий завершен, и не было возможности вернуться назад, если что-то будет найдено неправильно на более поздних этапах. V-модель предоставляет средства тестирования программного обеспечения на каждом этапе в обратном порядке.
На каждом этапе создаются планы тестирования и тестовые наборы для проверки и валидации продукта в соответствии с требованиями этого этапа. Например, на этапе сбора требований группа тестирования подготавливает все контрольные примеры в соответствии с требованиями. Позже, когда продукт будет разработан и готов к тестированию, контрольные примеры этого этапа проверяют программное обеспечение на соответствие требованиям на данном этапе.
Это позволяет и проверке, и проверке идти параллельно. Эта модель также известна как модель верификации и валидации.
Модель большого взрыва
Эта модель является самой простой моделью по форме. Это требует мало планирования, много программирования и много средств. Эта модель концептуализирована вокруг большого взрыва вселенной. Как говорят ученые, после большого взрыва множество галактик, планет и звезд эволюционировали как событие. Аналогично, если мы соберем много программ и средств, вы сможете получить лучший программный продукт.
Для этой модели требуется очень небольшое количество планирования. Это не следует ни за каким процессом, или время от времени клиент не уверен в требованиях и будущих потребностях. Таким образом, входные требования являются произвольными.
Эта модель не подходит для больших программных проектов, но хороша для обучения и экспериментов.
Для подробного изучения SDLC и его различных моделей, нажмите здесь.