stringtranslate.com

V-модель (разработка программного обеспечения)

V-модель процесса системной инженерии [1]

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

Фазы определения проекта

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

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

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

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

Проектирование системы

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

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

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

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

Модульная конструкция

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

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

Фазы проверки

В V-модели каждому этапу фазы проверки соответствует этап фазы валидации. [4] Ниже приведены типичные этапы валидации в V-модели, хотя они могут быть известны под другими названиями.

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

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

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

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

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

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

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

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

Критика

V-модель подверглась критике со стороны сторонников Agile и других как неадекватная модель разработки программного обеспечения по многим причинам. [5] [6] [7] Критика включает в себя:

  1. Она слишком проста, чтобы точно отражать процесс разработки ПО, и может привести менеджеров к ложному чувству безопасности. V-модель отражает взгляд на разработку ПО с точки зрения управления проектами и соответствует потребностям менеджеров проектов, бухгалтеров и юристов, а не разработчиков ПО или пользователей.
  2. Хотя новички легко это понимают, это раннее понимание полезно только в том случае, если новичок продолжает приобретать более глубокое понимание процесса разработки и того, как V-модель должна быть адаптирована и расширена на практике. Если практикующие упорствуют в своем наивном взгляде на V-модель, им будет очень трудно успешно применять ее.
  3. Он негибкий, поощряет жесткий и линейный взгляд на разработку программного обеспечения и не обладает изначальной способностью реагировать на изменения.
  4. Она представляет собой лишь незначительный вариант каскадной модели и поэтому подвергается той же критике, что и эта модель. Она уделяет больше внимания тестированию и, в частности, важности раннего планирования тестирования. Однако распространенная практическая критика V-модели заключается в том, что она приводит к тому, что тестирование втискивается в узкие окна в конце разработки, когда предыдущие этапы уже вышли за рамки, но дата реализации остается фиксированной.
  5. Он соответствует неэффективным и недейственным подходам к тестированию и, следовательно, неявно поощряет их. Он неявно поощряет написание тестовых сценариев заранее, а не исследовательское тестирование; он поощряет тестировщиков искать то, что они ожидают найти, а не открывать то, что есть на самом деле. Он также поощряет жесткую связь между эквивалентными уровнями любой ноги (например, планы тестирования приемки пользователем, полученные из документов с требованиями пользователя), а не поощряет тестировщиков выбирать наиболее эффективный и действенный способ планирования и выполнения тестирования.
  6. Ей не хватает связности и точности. Существует широко распространенная путаница относительно того, что именно представляет собой V-модель. Если свести ее к тем элементам, с которыми согласится большинство людей, она станет банальным и бесполезным представлением разработки программного обеспечения. Разногласия относительно достоинств V-модели часто отражают отсутствие общего понимания ее определения.

Текущее состояние

Сторонники V-модели утверждают, что она развивалась и поддерживает гибкость и проворство на протяжении всего процесса разработки. [8] Они утверждают, что в дополнение к тому, что это очень дисциплинированный подход, он способствует тщательному проектированию, разработке и документированию, необходимым для создания стабильных программных продуктов. В последнее время ее принимает индустрия медицинских приборов. [9] [10]

Смотрите также

Ссылки

  1. ^ Clarus Concept of Operations. Архивировано 2009-07-05 в Wayback Machine Publication No. FHWA-JPO-05-072, Федеральное управление шоссейных дорог (FHWA), 2005
  2. ↑ Кевин Форсберг и Гарольд Муз , «Связь системной инженерии с проектным циклом», в трудах Первого ежегодного симпозиума Национального совета по системной инженерии, октябрь 1991 г.: 57–65.
  3. ^ Что такое модель V — преимущества, недостатки и когда ее использовать
  4. ^ ДеСпаутц, Джозеф; Кеннет С. Ковач; Герхард Верлинг (11 марта 2008 г.). «Стандарты GAMP для валидации автоматизированных систем». Фармацевтическая обработка. Архивировано из оригинала 8 мая 2012 г. . Получено 28 февраля 2012 г. .
  5. ^ «V Model In Software Development», дата обращения 14 октября 2024 г. (обновлено)
  6. ^ "Опасная и соблазнительная модель V", архивная версия от 15 сентября 2019 г.
  7. ^ "Новые модели для разработки тестов", доступ 6 января 2013 г.
  8. ^ «На пути к гибким процессам системной инженерии», дата обращения 9 августа 2022 г.
  9. ^ Макхью, Мартин; Маккаффери, Фергал; Кейси, Валентайн (2012). «Барьеры для внедрения гибких методов при разработке программного обеспечения для медицинских устройств». Улучшение процесса разработки программного обеспечения и определение возможностей . Коммуникации в области компьютерных и информационных наук. Том 290. С. 141–147. doi :10.1007/978-3-642-30439-2_13. ISBN 978-3-642-30438-5.
  10. ^ «Структура разработки, оценки и улучшения процесса разработки программного обеспечения для индустрии медицинских приборов»

Дальнейшее чтение


На Викискладе есть медиафайлы по теме V-модели .