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

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

SDLC деятельности

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

Общение

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

Сбор требований

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

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

Технико-экономическое обоснование

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

Системный анализ

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

Разработка программного обеспечения

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

Кодирование

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

Тестирование

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

Интеграция

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

Реализация

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

Эксплуатация и обслуживание

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

Диспозиция

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

Парадигма разработки программного обеспечения

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

Модель водопада

Модель водопада - самая простая модель парадигмы разработки программного обеспечения. В нем говорится, что все фазы SDLC будут работать одна за другой линейно. То есть, когда первая фаза закончится, тогда начнется только вторая фаза и так далее.

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

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

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

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

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

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

Спиральная модель

Спиральная модель представляет собой комбинацию итеративной модели и одной из моделей SDLC. Это можно рассматривать так, как будто вы выбираете одну модель SDLC и объединяете ее с циклическим процессом (итерационная модель).

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

V - модель

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

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

Благодаря этому и верификация, и валидация идут параллельно. Эта модель также известна как модель проверки и валидации.

Модель Большого Взрыва

Эта модель является самой простой по своей форме. Это требует небольшого планирования, большого количества программирования и большого количества средств. Эта модель построена вокруг Большого взрыва Вселенной. Как говорят ученые, после большого взрыва множество галактик, планет и звезд эволюционировали просто как событие. Точно так же, если мы объединим много программ и средств, вы сможете получить лучший программный продукт.

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

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

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