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

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

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

Анализ требований [ править ]

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

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

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

Проектирование системы [ править ]

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

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

Архитектурный дизайн [ править ]

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

Дизайн модуля [ править ]

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

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

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

Этапы проверки [ править ]

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

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

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

Интеграционное тестирование [ править ]

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

Тестирование системы [ править ]

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

Приемочное тестирование пользователей [ править ]

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

Критика [ править ]

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

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

Текущее состояние [ править ]

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

См. также [ править ]

Ссылки [ править ]

^ Концепция операций Clarus. Архивировано 5 июля 2009 г. в публикации Wayback Machine № FHWA-JPO-05-072, Федеральное управление шоссейных дорог (FHWA), 2005 г.
^ Кевин Форсберг и Гарольд Муз , «Взаимосвязь системной инженерии с проектным циклом», в материалах первого ежегодного симпозиума Национального совета по системной инженерии, октябрь 1991 г.: 57–65.
^ Что такое модель V - преимущества, недостатки и когда ее использовать
^ ДеСпауц, Джозеф; Кеннет С. Ковач; Герхард Верлинг (11 марта 2008 г.). «Стандарты GAMP для валидации автоматизированных систем» . Фармацевтическая обработка. Архивировано из оригинала 8 мая 2012 года . Проверено 28 февраля 2012 г.
^ «Смерть V-модели» , по состоянию на 6 января 2013 г.
^ «Опасная и соблазнительная модель V» , архивная версия от 15 сентября 2019 г.
^ «Новые модели для разработки тестов» , по состоянию на 6 января 2013 г.
^ «На пути к гибким процессам системного проектирования» , по состоянию на 9 августа 2022 г.
^ «Барьеры на пути внедрения гибких практик при разработке программного обеспечения для медицинского оборудования»
^ «Структура разработки, оценки и улучшения программного обеспечения для индустрии медицинского оборудования»

Дальнейшее чтение [ править ]

Роджер С. Прессман: Программная инженерия: практический подход , The McGraw-Hill Companies, ISBN 0-07-301933-X
Марк Хоффман и Тед Бомонт: Разработка приложений: управление жизненным циклом проекта , Mc Press, ISBN 1-883884-45-4
Борис Бейзер: Методы тестирования программного обеспечения. Второе издание, International Thomson Computer Press, 1990 г., ISBN 1-85032-880-3

[FHWA_05-1] Концепция операций Clarus. Архивировано 5 июля 2009 г. в публикации Wayback Machine № FHWA-JPO-05-072, Федеральное управление шоссейных дорог (FHWA), 2005 г.

[2] Кевин Форсберг и Гарольд Муз , «Взаимосвязь системной инженерии с проектным циклом», в материалах первого ежегодного симпозиума Национального совета по системной инженерии, октябрь 1991 г.: 57–65.

[3] Что такое модель V - преимущества, недостатки и когда ее использовать

[4] ДеСпауц, Джозеф; Кеннет С. Ковач; Герхард Верлинг (11 марта 2008 г.). «Стандарты GAMP для валидации автоматизированных систем» . Фармацевтическая обработка. Архивировано из оригинала 8 мая 2012 года . Проверено 28 февраля 2012 г.

[5] «Смерть V-модели» , по состоянию на 6 января 2013 г.

[6] «Опасная и соблазнительная модель V» , архивная версия от 15 сентября 2019 г.

[7] «Новые модели для разработки тестов» , по состоянию на 6 января 2013 г.

[8] «На пути к гибким процессам системного проектирования» , по состоянию на 9 августа 2022 г.

[9] «Барьеры на пути внедрения гибких практик при разработке программного обеспечения для медицинского оборудования»

[10] «Структура разработки, оценки и улучшения программного обеспечения для индустрии медицинского оборудования»

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

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