SDLC — Обзор

Жизненный цикл разработки программного обеспечения (SDLC) — это процесс, используемый индустрией программного обеспечения для проектирования, разработки и тестирования высококачественного программного обеспечения. SDLC нацелен на производство высококачественного программного обеспечения, которое соответствует ожиданиям клиентов или превосходит их, в кратчайшие сроки завершает работу и оценивает затраты.

• SDLC является аббревиатурой жизненного цикла разработки программного обеспечения.

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

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

• ISO / IEC 12207 является международным стандартом для процессов жизненного цикла программного обеспечения. Он призван стать стандартом, определяющим все задачи, необходимые для разработки и обслуживания программного обеспечения.

SDLC является аббревиатурой жизненного цикла разработки программного обеспечения.

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

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

ISO / IEC 12207 является международным стандартом для процессов жизненного цикла программного обеспечения. Он призван стать стандартом, определяющим все задачи, необходимые для разработки и обслуживания программного обеспечения.

Что такое SDLC?

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

На следующем рисунке представлено графическое представление различных этапов типичного SDLC.

Типичный жизненный цикл разработки программного обеспечения состоит из следующих этапов:

Этап 1: планирование и анализ потребностей

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

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

Этап 2: определение требований

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

Этап 3: проектирование архитектуры продукта

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

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

Подход к проектированию четко определяет все архитектурные модули продукта, а также его связь и представление потока данных с внешними и сторонними модулями (если таковые имеются). Внутренний дизайн всех модулей предлагаемой архитектуры должен быть четко определен с мельчайшими деталями в DDS.

Этап 4: Создание или разработка продукта

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

Разработчики должны следовать руководящим принципам кодирования, определенным их организацией, и для генерации кода используются такие инструменты программирования, как компиляторы, интерпретаторы, отладчики и т. Д. Для кодирования используются различные языки программирования высокого уровня, такие как C, C ++, Pascal, Java и PHP. Язык программирования выбирается в зависимости от типа разрабатываемого программного обеспечения.

Этап 5: Тестирование продукта

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

Этап 6: развертывание на рынке и сопровождение

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

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

Модели SDLC

Существуют различные модели жизненного цикла разработки программного обеспечения, определенные и спроектированные, которые следуют в процессе разработки программного обеспечения. Эти модели также называются «Модели процессов разработки программного обеспечения». Каждая модель процесса следует серии шагов, уникальных для своего типа, чтобы обеспечить успех в процессе разработки программного обеспечения.

Ниже приведены наиболее важные и популярные модели SDLC, используемые в отрасли.

• Модель водопада
• Итерационная модель
• Спиральная модель
• V-модель
• Модель большого взрыва

Другими связанными методологиями являются Agile Model, RAD Model, Rapid Application Development и моделирование прототипов.

SDLC — модель водопада

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

Модель Waterfall — самый ранний подход SDLC, который использовался для разработки программного обеспечения.

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

Модель водопада — Дизайн

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

Следующая иллюстрация представляет различные фазы модели водопада.

Последовательные фазы в модели Waterfall:

• Сбор и анализ требований — Все возможные требования к разрабатываемой системе фиксируются на этом этапе и документируются в документе спецификации требований.

• Проектирование системы. На этом этапе изучаются требования к требованиям первого этапа и готовится проектирование системы. Такая конструкция системы помогает определить требования к оборудованию и системе и помогает определить общую архитектуру системы.

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

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

• Развертывание системы — после завершения функционального и нефункционального тестирования; продукт развернут в среде клиента или выпущен на рынок.

• Обслуживание — Есть некоторые проблемы, которые возникают в клиентской среде. Чтобы исправить эти проблемы, исправления выпущены. Также для улучшения продукта выпущены лучшие версии. Техническое обслуживание проводится для предоставления этих изменений в среде клиента.

Сбор и анализ требований — Все возможные требования к разрабатываемой системе фиксируются на этом этапе и документируются в документе спецификации требований.

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

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

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

Развертывание системы — после завершения функционального и нефункционального тестирования; продукт развернут в среде клиента или выпущен на рынок.

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

Все эти фазы каскадно связаны друг с другом, в которых прогресс рассматривается как непрерывно нисходящий (как водопад) через фазы. Следующий этап начинается только после того, как определенный набор целей достигнут для предыдущего этапа, и он подписан, поэтому называется «Модель водопада». В этой модели фазы не перекрываются.

Модель водопада — Применение

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

• Требования очень хорошо задокументированы, понятны и зафиксированы.

• Определение продукта является стабильным.

• Технология понятна и не динамична.

• Здесь нет двусмысленных требований.

• Достаточные ресурсы с необходимым опытом доступны для поддержки продукта.

• Проект короткий.

Требования очень хорошо задокументированы, понятны и зафиксированы.

Определение продукта является стабильным.

Технология понятна и не динамична.

Здесь нет двусмысленных требований.

Достаточные ресурсы с необходимым опытом доступны для поддержки продукта.

Проект короткий.

Модель водопада — преимущества

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

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

Некоторые из основных преимуществ модели водопада следующие:

• Просто и легко понять и использовать

• Простота в управлении благодаря жесткости модели. Каждый этап имеет конкретные результаты и процесс обзора.

• Фазы обрабатываются и завершаются по одному.

• Хорошо работает для небольших проектов, где требования очень хорошо поняты.

• Четко определенные этапы.

• Хорошо понятные вехи.

• Легко организовать задачи.

• Процесс и результаты хорошо документированы.

Просто и легко понять и использовать

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

Фазы обрабатываются и завершаются по одному.

Хорошо работает для небольших проектов, где требования очень хорошо поняты.

Четко определенные этапы.

Хорошо понятные вехи.

Легко организовать задачи.

Процесс и результаты хорошо документированы.

Модель водопада — недостатки

Недостатком развития водопада является то, что он не позволяет много размышлений или пересмотра. Когда приложение находится на стадии тестирования, очень трудно вернуться назад и изменить что-то, что не было хорошо документировано или продумано на стадии разработки.

Основные недостатки модели водопада следующие:

• Никакое рабочее программное обеспечение не производится до конца жизненного цикла.

• Большое количество риска и неопределенности.

• Не очень хорошая модель для сложных и объектно-ориентированных проектов.

• Плохая модель для длительных и текущих проектов.

• Не подходит для проектов, где требования изменяются от умеренного до высокого риска. Таким образом, риск и неопределенность высоки с этой моделью процесса.

• Трудно измерить прогресс в несколько этапов.

• Невозможно учесть меняющиеся требования

• Регулировка объема в течение жизненного цикла может завершить проект.

• Интеграция осуществляется как «большой взрыв» в самом конце, что не позволяет выявить какие-либо технологические или бизнес-узкие места или проблемы на ранних этапах.

Никакое рабочее программное обеспечение не производится до конца жизненного цикла.

Большое количество риска и неопределенности.

Не очень хорошая модель для сложных и объектно-ориентированных проектов.

Плохая модель для длительных и текущих проектов.

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

Трудно измерить прогресс в несколько этапов.

Невозможно учесть меняющиеся требования

Регулировка объема в течение жизненного цикла может завершить проект.

Интеграция осуществляется как «большой взрыв» в самом конце, что не позволяет выявить какие-либо технологические или бизнес-узкие места или проблемы на ранних этапах.

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

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

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

Итерационная модель — Дизайн

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

Следующая иллюстрация — представление Итеративной и Инкрементальной модели —

Итеративная и инкрементная разработка — это сочетание итеративного проектирования или итеративного метода и модели инкрементной сборки для разработки. «Во время разработки программного обеспечения одновременно может выполняться более одной итерации цикла разработки программного обеспечения». Этот процесс может быть описан как подход «эволюционного приобретения» или «инкрементной сборки».

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

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

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

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

• Требования к полной системе четко определены и понятны.

• Основные требования должны быть определены; однако некоторые функции или запрошенные улучшения могут со временем развиваться.

• Есть время для ограничения рынка.

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

• Ресурсы с необходимыми наборами навыков недоступны и планируется использовать на контрактной основе для конкретных итераций.

• Есть некоторые особенности и цели высокого риска, которые могут измениться в будущем.

Требования к полной системе четко определены и понятны.

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

Есть время для ограничения рынка.

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

Ресурсы с необходимыми наборами навыков недоступны и планируется использовать на контрактной основе для конкретных итераций.

Есть некоторые особенности и цели высокого риска, которые могут измениться в будущем.

Итерационная модель — за и против

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

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

Преимущества Итеративной и Инкрементальной модели SDLC заключаются в следующем:

• Некоторая рабочая функциональность может быть разработана быстро и в начале жизненного цикла.

• Результаты получены рано и периодически.

• Параллельное развитие может быть запланировано.

• Прогресс можно измерить.

• Менее затратно изменить сферу / требования.

• Тестирование и отладка во время небольшой итерации очень просты.

• Риски выявляются и устраняются в ходе итерации; и каждая итерация является легко управляемой вехой.

• Проще управлять риском — сначала выполняется часть с высоким риском.

• С каждым шагом, оперативный продукт поставляется.

• Проблемы, проблемы и риски, определенные для каждого приращения, могут быть использованы / применены к следующему приращению.

• Анализ рисков лучше.

• Он поддерживает меняющиеся требования.

• Начальное время работы меньше.

• Лучше подходит для крупных и критически важных проектов.

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

Некоторая рабочая функциональность может быть разработана быстро и в начале жизненного цикла.

Результаты получены рано и периодически.

Параллельное развитие может быть запланировано.

Прогресс можно измерить.

Менее затратно изменить сферу / требования.

Тестирование и отладка во время небольшой итерации очень просты.

Риски выявляются и устраняются в ходе итерации; и каждая итерация является легко управляемой вехой.

Проще управлять риском — сначала выполняется часть с высоким риском.

С каждым шагом, оперативный продукт поставляется.

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

Анализ рисков лучше.

Он поддерживает меняющиеся требования.

Начальное время работы меньше.

Лучше подходит для крупных и критически важных проектов.

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

Недостатки Итеративной и Инкрементальной модели SDLC заключаются в следующем:

• Может потребоваться больше ресурсов.

• Хотя стоимость изменений меньше, но она не очень подходит для изменения требований.

• Требуется больше внимания руководства.

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

• Определение приращений может потребовать определения всей системы.

• Не подходит для небольших проектов.

• Сложность управления больше.

• Конец проекта может быть неизвестен, что является риском.

• Для анализа рисков требуются высококвалифицированные ресурсы.

• Ход реализации проектов в значительной степени зависит от этапа анализа рисков.

Может потребоваться больше ресурсов.

Хотя стоимость изменений меньше, но она не очень подходит для изменения требований.

Требуется больше внимания руководства.

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

Определение приращений может потребовать определения всей системы.

Не подходит для небольших проектов.

Сложность управления больше.

Конец проекта может быть неизвестен, что является риском.

Для анализа рисков требуются высококвалифицированные ресурсы.

Ход реализации проектов в значительной степени зависит от этапа анализа рисков.

SDLC — спиральная модель

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

Спиральная модель — Дизайн

Спиральная модель имеет четыре фазы. Программный проект неоднократно проходит через эти фазы в итерациях, называемых спиралями.

Удостоверение личности

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

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

дизайн

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

Построить или построить

Фаза Construct относится к производству фактического программного продукта на каждой спирали. В базовой линии, когда продукт только продуман и дизайн разрабатывается, на этом этапе разрабатывается POC (Proof of Concept), чтобы получить обратную связь с клиентом.

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

Оценка и анализ рисков

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

Следующая иллюстрация — представление спиральной модели, в которой перечислены действия на каждом этапе.

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

Применение спиральной модели

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

Следующие указатели объясняют типичное использование спиральной модели —

• При наличии бюджетных ограничений важна оценка рисков.

• Для проектов со средней и высокой степенью риска.

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

• Клиент не уверен в своих требованиях, как правило, так.

• Требования сложны и нуждаются в оценке, чтобы получить ясность.

• Новая линейка продуктов, которая должна выпускаться поэтапно, чтобы получить достаточное количество отзывов клиентов.

• Значительные изменения ожидаются в продукте в течение цикла разработки.

При наличии бюджетных ограничений важна оценка рисков.

Для проектов со средней и высокой степенью риска.

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

Клиент не уверен в своих требованиях, как правило, так.

Требования сложны и нуждаются в оценке, чтобы получить ясность.

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

Значительные изменения ожидаются в продукте в течение цикла разработки.

Спиральная модель — за и против

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

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

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

Преимущества модели Spiral SDLC следующие:

• Изменение требований могут быть учтены.

• Позволяет широко использовать прототипы.

• Требования могут быть зафиксированы более точно.

• Пользователи видят систему рано.

• Разработка может быть разделена на более мелкие части, а более рискованные части могут быть разработаны ранее, что помогает улучшить управление рисками.

Изменение требований могут быть учтены.

Позволяет широко использовать прототипы.

Требования могут быть зафиксированы более точно.

Пользователи видят систему рано.

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

Недостатки спиральной модели SDLC заключаются в следующем —

• Управление более сложное.

• Конец проекта может быть неизвестен рано.

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

• Процесс сложный

• Спираль может продолжаться бесконечно.

• Большое количество промежуточных этапов требует излишней документации.

Управление более сложное.

Конец проекта может быть неизвестен рано.

Не подходит для небольших проектов или проектов с низким уровнем риска и может быть дорогостоящим для небольших проектов.

Процесс сложный

Спираль может продолжаться бесконечно.

Большое количество промежуточных этапов требует излишней документации.

SDLC — V-модель

V-модель — это модель SDLC, в которой выполнение процессов происходит последовательно в форме буквы V. Он также известен как модель верификации и валидации .

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

V-модель — Дизайн

В рамках V-модели соответствующая фаза тестирования фазы разработки планируется параллельно. Итак, есть фазы проверки на одной стороне «V» и фазы проверки на другой стороне. Фаза кодирования объединяет две стороны V-модели.

На следующем рисунке показаны различные фазы V-модели SDLC.

V-модель — Этапы верификации

В V-модели есть несколько этапов верификации, каждый из которых подробно описан ниже.

Анализ бизнес-требований

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

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

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

Архитектурный дизайн

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

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

Модуль Дизайн

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

Фаза кодирования

Фактическое кодирование системных модулей, разработанных на этапе проектирования, рассматривается на этапе кодирования. Выбор наиболее подходящего языка программирования определяется на основе системных и архитектурных требований.

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

Этапы валидации

Различные этапы валидации в V-модели подробно описаны ниже.

Модульное тестирование

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

Интеграционное тестирование

Интеграционное тестирование связано с этапом архитектурного проектирования. Интеграционные тесты выполняются для проверки сосуществования и связи внутренних модулей в системе.

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

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

Приемочное тестирование

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

V- Модель ─ Применение

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

Следующие указатели являются одними из наиболее подходящих сценариев для использования приложения V-Model.

• Требования четко определены, четко задокументированы и зафиксированы.

• Определение продукта является стабильным.

• Технология не динамична и хорошо понимается командой проекта.

• Здесь нет двусмысленных или неопределенных требований.

• Проект короткий.

Требования четко определены, четко задокументированы и зафиксированы.

Определение продукта является стабильным.

Технология не динамична и хорошо понимается командой проекта.

Здесь нет двусмысленных или неопределенных требований.

Проект короткий.

V-модель — плюсы и минусы

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

Преимущества метода V-модели заключаются в следующем —

• Это очень дисциплинированная модель, и Фазы завершаются по одному.

• Хорошо работает для небольших проектов, где требования очень хорошо поняты.

• Просто и легко понять и использовать.

• Простота в управлении благодаря жесткости модели. Каждый этап имеет конкретные результаты и процесс обзора.

Это очень дисциплинированная модель, и Фазы завершаются по одному.

Хорошо работает для небольших проектов, где требования очень хорошо поняты.

Просто и легко понять и использовать.

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

Недостатки метода V-модели заключаются в следующем —

• Высокий риск и неопределенность.

• Не очень хорошая модель для сложных и объектно-ориентированных проектов.

• Плохая модель для длительных и текущих проектов.

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

• Как только приложение находится в стадии тестирования, трудно вернуться назад и изменить функциональность.

• Никакое рабочее программное обеспечение не производится до конца жизненного цикла.

Высокий риск и неопределенность.

Не очень хорошая модель для сложных и объектно-ориентированных проектов.

Плохая модель для длительных и текущих проектов.

Не подходит для проектов, где требования изменяются от умеренного до высокого риска.

Как только приложение находится в стадии тестирования, трудно вернуться назад и изменить функциональность.

Никакое рабочее программное обеспечение не производится до конца жизненного цикла.

SDLC — модель большого взрыва

Модель Большого взрыва — это модель SDLC, в которой мы не следуем никаким конкретным процессам. Разработка только начинается с необходимых денег и усилий в качестве входных данных, а результатом является разработанное программное обеспечение, которое может соответствовать или не соответствовать требованиям заказчика. Эта модель Большого взрыва не соответствует процессу / процедуре, и требуется очень мало планирования. Даже заказчик не уверен, что именно он хочет, и требования выполняются на лету без особого анализа.

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

Модель Большого взрыва ─ Дизайн и применение

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

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

Модель Большого взрыва — за и против

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

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

Преимущества модели Большого взрыва следующие:

• Это очень простая модель

• Мало или не требуется планирование

• Прост в управлении

• Требуется очень мало ресурсов

• Предоставляет разработчикам гибкость

• Это хорошее учебное пособие для новичков или студентов.

Это очень простая модель

Мало или не требуется планирование

Прост в управлении

Требуется очень мало ресурсов

Предоставляет разработчикам гибкость

Это хорошее учебное пособие для новичков или студентов.

Недостатки модели Большого взрыва заключаются в следующем —

• Очень Высокий риск и неопределенность.

• Не очень хорошая модель для сложных и объектно-ориентированных проектов.

• Плохая модель для длительных и текущих проектов.

• Может оказаться очень дорогим, если требования неправильно поняты.

Очень Высокий риск и неопределенность.

Не очень хорошая модель для сложных и объектно-ориентированных проектов.

Плохая модель для длительных и текущих проектов.

Может оказаться очень дорогим, если требования неправильно поняты.

SDLC — гибкая модель

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

• планирование
• Анализ требований
• дизайн
• кодирование
• Модульное тестирование и
• Приемочное тестирование.

В конце итерации рабочий продукт отображается клиенту и важным заинтересованным сторонам.

Что такое Agile?

Agile модель считает, что каждый проект должен обрабатываться по-разному, а существующие методы должны быть адаптированы в соответствии с требованиями проекта. В Agile задачи делятся на временные рамки (небольшие временные рамки) для предоставления определенных функций для выпуска.

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

Вот графическая иллюстрация Agile Model —

Agile мыслительный процесс начался на ранней стадии разработки программного обеспечения и стал популярным со временем благодаря своей гибкости и адаптируемости.

К наиболее популярным методам Agile относятся Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), адаптивная разработка программного обеспечения, функционально-ориентированная разработка и метод разработки динамических систем (DSDM) (1995). Теперь они все вместе называются Agile-методологиями после публикации Agile Manifesto в 2001 году.

Ниже приведены принципы Agile Manifesto —

• Индивидуумы и взаимодействия. В гибкой разработке важны самоорганизация и мотивация, а также такие взаимодействия, как совместное размещение и парное программирование.

• Рабочее программное обеспечение. Демонстрационное рабочее программное обеспечение считается лучшим средством связи с клиентами для понимания их требований, а не просто в зависимости от документации.

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

• Реагирование на изменения — Agile Development ориентирована на быстрое реагирование на изменения и постоянное развитие.

Индивидуумы и взаимодействия. В гибкой разработке важны самоорганизация и мотивация, а также такие взаимодействия, как совместное размещение и парное программирование.

Рабочее программное обеспечение. Демонстрационное рабочее программное обеспечение считается лучшим средством связи с клиентами для понимания их требований, а не просто в зависимости от документации.

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

Реагирование на изменения — Agile Development ориентирована на быстрое реагирование на изменения и постоянное развитие.

Agile Vs против традиционных моделей SDLC

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

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

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

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

Agile Model — за и против

Agile методы в настоящее время широко распространены в мире программного обеспечения. Однако этот метод не всегда подходит для всех продуктов. Вот некоторые плюсы и минусы Agile модели.

Преимущества Agile Model следующие:

• Это очень реалистичный подход к разработке программного обеспечения.

• Способствует командной работе и кросс-тренировке.

• Функциональность может быстро развиваться и демонстрироваться.

• Требования к ресурсам минимальны.

• Подходит для фиксированных или меняющихся требований

• Поставляет ранние частичные рабочие решения.

• Хорошая модель для сред, которые постоянно меняются.

• Минимальные правила, документация легко используется.

• Обеспечивает одновременную разработку и доставку в общем запланированном контексте.

• Мало или нет планирования не требуется.

• Прост в управлении.

• Дает гибкость разработчикам.

Это очень реалистичный подход к разработке программного обеспечения.

Способствует командной работе и кросс-тренировке.

Функциональность может быстро развиваться и демонстрироваться.

Требования к ресурсам минимальны.

Подходит для фиксированных или меняющихся требований

Поставляет ранние частичные рабочие решения.

Хорошая модель для сред, которые постоянно меняются.

Минимальные правила, документация легко используется.

Обеспечивает одновременную разработку и доставку в общем запланированном контексте.

Мало или нет планирования не требуется.

Прост в управлении.

Дает гибкость разработчикам.

Недостатки Agile Model следующие:

• Не подходит для обработки сложных зависимостей.

• Больше риска устойчивости, ремонтопригодности и расширяемости.

• Общий план, проворный лидер и проворная практика PM — необходимость, без которой это не будет работать.

• Строгое управление доставкой диктует объем, функциональность, которую необходимо доставить, и корректировки для соблюдения сроков.

• В значительной степени зависит от взаимодействия с клиентами, поэтому, если клиент не ясно, команда может двигаться в неправильном направлении.

• Существует очень высокая индивидуальная зависимость, так как генерируется минимум документации.

• Передача технологии новым членам команды может быть довольно сложной из-за отсутствия документации.

Не подходит для обработки сложных зависимостей.

Больше риска устойчивости, ремонтопригодности и расширяемости.

Общий план, проворный лидер и проворная практика PM — необходимость, без которой это не будет работать.

Строгое управление доставкой диктует объем, функциональность, которую необходимо доставить, и корректировки для соблюдения сроков.

В значительной степени зависит от взаимодействия с клиентами, поэтому, если клиент не ясно, команда может двигаться в неправильном направлении.

Существует очень высокая индивидуальная зависимость, так как генерируется минимум документации.

Передача технологии новым членам команды может быть довольно сложной из-за отсутствия документации.

SDLC — RAD модель

Модель RAD (Rapid Application Development) основана на прототипировании и итеративной разработке без особого планирования. Сам процесс написания программного обеспечения включает планирование, необходимое для разработки продукта.

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

Что такое RAD?

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

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

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

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

RAD Модель Дизайн

Модель RAD распределяет фазы анализа, проектирования, сборки и тестирования на серию коротких итерационных циклов разработки.

Ниже приведены различные этапы модели RAD —

Бизнес моделирование

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

Моделирование данных

Информация, собранная на этапе бизнес-моделирования, анализируется и анализируется для формирования наборов объектов данных, важных для бизнеса. Атрибуты всех наборов данных идентифицированы и определены. Отношения между этими объектами данных устанавливаются и детально определяются в соответствии с бизнес-моделью.

Моделирование процессов

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

Генерация приложений

Фактическая система построена, и кодирование выполняется с использованием инструментов автоматизации для преобразования моделей процессов и данных в реальные прототипы.

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

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

На следующем рисунке подробно описывается модель RAD.

Модель RAD против традиционного SDLC

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

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

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

Модель RAD — Применение

Модель RAD может быть успешно применена к проектам, в которых возможна четкая модульность. Если проект не может быть разбит на модули, RAD может потерпеть неудачу.

Следующие указатели описывают типичные сценарии, в которых может использоваться RAD —

• RAD следует использовать только в том случае, если система может быть модульной, чтобы доставлять ее постепенно.

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

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

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

• Должен использоваться, когда требования изменяются во время проекта, а рабочие прототипы должны быть представлены заказчику небольшими итерациями в течение 2-3 месяцев.

RAD следует использовать только в том случае, если система может быть модульной, чтобы доставлять ее постепенно.

Его следует использовать, если существует высокая доступность дизайнеров для моделирования.

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

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

Должен использоваться, когда требования изменяются во время проекта, а рабочие прототипы должны быть представлены заказчику небольшими итерациями в течение 2-3 месяцев.

Модель RAD — за и против

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

Преимущества модели RAD следующие:

• Изменение требований могут быть учтены.

• Прогресс можно измерить.

• Время итерации может быть коротким с использованием мощных инструментов RAD.

• Производительность с меньшим количеством людей за короткое время.

• Сокращение времени разработки.

• Увеличивает возможность повторного использования компонентов.

• Быстрые начальные обзоры происходят.

• Поощряет обратную связь с клиентами.

• Интеграция с самого начала решает множество проблем интеграции.

Изменение требований могут быть учтены.

Прогресс можно измерить.

Время итерации может быть коротким с использованием мощных инструментов RAD.

Производительность с меньшим количеством людей за короткое время.

Сокращение времени разработки.

Увеличивает возможность повторного использования компонентов.

Быстрые начальные обзоры происходят.

Поощряет обратную связь с клиентами.

Интеграция с самого начала решает множество проблем интеграции.

Недостатки модели RAD следующие:

• Зависимость от технически сильных членов команды для определения бизнес-требований.

• Только система, которая может быть модульной, может быть построена с использованием RAD.

• Требуются высококвалифицированные разработчики / дизайнеры.

• Высокая зависимость от навыков моделирования.

• Неприменимо к более дешевым проектам, так как стоимость моделирования и автоматической генерации кода очень высока.

• Сложность управления больше.

• Подходит для систем, основанных на компонентах и ​​масштабируемых.

• Требует участия пользователя на протяжении всего жизненного цикла.

• Подходит для проекта, требующего более коротких сроков разработки.

Зависимость от технически сильных членов команды для определения бизнес-требований.

Только система, которая может быть модульной, может быть построена с использованием RAD.

Требуются высококвалифицированные разработчики / дизайнеры.

Высокая зависимость от навыков моделирования.

Неприменимо к более дешевым проектам, так как стоимость моделирования и автоматической генерации кода очень высока.

Сложность управления больше.

Подходит для систем, основанных на компонентах и ​​масштабируемых.

Требует участия пользователя на протяжении всего жизненного цикла.

Подходит для проекта, требующего более коротких сроков разработки.

SDLC — модель прототипа программного обеспечения

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

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

Что такое прототипирование программного обеспечения?

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

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

Ниже приведен пошаговый подход к разработке прототипа программного обеспечения.

Идентификация основного требования

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

Разработка первоначального прототипа

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

Обзор прототипа

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

Пересмотреть и улучшить прототип

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

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

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

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

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

Throwaway / быстрое прототипирование

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

Эволюционное прототипирование

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

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

Инкрементное прототипирование относится к созданию нескольких функциональных прототипов различных подсистем и последующей интеграции всех доступных прототипов в единую систему.

Экстремальное прототипирование

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

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

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

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

Программное прототипирование — плюсы и минусы

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

Преимущества модели прототипа заключаются в следующем —

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

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

• Сокращает время и затраты, поскольку дефекты могут быть обнаружены намного раньше.

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

• Отсутствующие функциональные возможности могут быть легко идентифицированы.

• Запутанные или сложные функции могут быть определены.

Повышенная вовлеченность пользователей в продукт еще до его внедрения.

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

Сокращает время и затраты, поскольку дефекты могут быть обнаружены намного раньше.

Доступна более быстрая обратная связь с пользователем, что приводит к лучшим решениям.

Отсутствующие функциональные возможности могут быть легко идентифицированы.

Запутанные или сложные функции могут быть определены.

Недостатки прототипа модели заключаются в следующем —

Риск недостаточного анализа требований из-за слишком большой зависимости от прототипа.

Пользователи могут запутаться в прототипах и реальных системах.

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

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

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