Почему интерактивные визуальные эффекты являются следующей большой вещью в сотрудничестве программного обеспечения
16 июня 2025 г.Таблица ссылок
Аннотация и I. Введение
II Подход
А. Архитектурный дизайн
B. Доказательство реализации концепции
Iii. Представленные сценарии использования
IV Дизайн эксперимента и демография
А. Участники
B. Целевая система и задача
C. Процедура
V. Результаты и обсуждение
VI Связанная работа
VII. Выводы и будущая работа, признание и ссылки
Iii. Представленные сценарии использования
Помимо использования Advanced (Web) технологий, наш подход может быть отличается от связанной работы с использованием динамического анализа и совместных функций SV. Поэтому мы теперь представляем предполагаемые сценарии использования, которые могут следовать нашему подходу и связанных с ними будущих работах.
Сценарий 1 (SC1): облегчить процесс адаптации
В разработке профессионального программного обеспечения компании используют различные методы для процесса адаптации новых разработчиков. Поддержка сверстников, обзор продукта и простые задачи воспринимаются как полезные в этом контексте [22], одновременно обнаруживая документацию и технические проблемы, например, создание среды разработки, препятствует процессу адаптации, особенно для удаленной работы [23]. Мы представляем сценарий, в котором облачные редакторы кодов со встроенными SV готовы направлять новых разработчиков шаг за шагом через поведение программной системы. Пользователи нажимают на использование анализируемой (распределенной) целевой системы и понимают ее разворачивание через SV. Кроме того, все более крупные части исходного кода (например, в зависимости от опыта) непосредственно связаны с сущностями SV. Это позволяет разработчикам понять, какая часть исходного кода действия, в которых варианты использования. Затем подход может использоваться для встроенной в соответствии с задачей, где разработчики также сталкиваются с небольшими задачами для понимания программного обеспечения [22], [24]. В любое время пользователи могут приглашать других разработчиков для совместного понимания или их наставника и попросить о помощи. Рядом с голосовой коммуникацией участники используют совместные функции, такие как синхронизированный выбор текста и всплывающие окна общей информации для взаимодействия и обмена [16].
Сценарий 2 (SC2): Выделите изменения во время обзоров кода
Запросы на функции и полученные обзоры кодов на основе изменений обычно используются в разработке профессионального программного обеспечения [25]. Тем не менее, рецензенты, как правило, дают необычную обратную связь и, как правило, сообщают об ограничениях инструментов обзора при использовании в сложных сценариях [26]. В этом контексте мы видим еще один потенциальный сценарий использования для нашего подхода, который мы обрисовываем в следующем. Предполагается, что член команды рассмотрит изменения исходного кода коллеги. Для этого он или она может нажать на ссылку внутри запроса о привлечении, который открывает подготовленный, облачный редактор кода со встроенным SV нового поведения программы (из-за изменения исходного кода). Изменения исходного кода в IDE кодируется. Для понимания поведения программы можно переключиться между старым и новым поведением программы в SV, нажав кнопку. Коллега, который выпустил запрос на привлечение, может быть приглашен на сессию, чтобы изменения также можно обсудить вместе.
Сценарий 3 (SC3): интегрируйте информацию времени выполнения в деятельность по разработке
Постановка среды используются для тестирования программных систем в производственной среде. Мы представляем редакторы кода, информирующие выбранных разработчиков о проблемах производительности установленной программной системы (например, в зоне постановки). Разработчик может нажать на это уведомление, чтобы открыть встроенный SV. Визуализация изображает поведение времени выполнения, которое включает проблему производительности. Он также подчеркивает сущность, которая вводит проблему, например, метод вызова, который занял слишком много времени, чтобы закончить. Основываясь на этом, разработчики получают информацию о среде выполнения, отображаемая в их редакторе кода и могут анализировать затронутые строки кода.
IV Дизайн эксперимента и демография
Эффективность является одним из наиболее распространенных свойств, используемых для оценки подходов SV. В этом контексте Merino et al. [27] представляют систематический обзор литературы по оценке SV. В их работе анализируется литература полных работ, которые были опубликованы на конференциях Softvis/Vissoft, что привело к изучению 181 статей. Авторы сосредоточены на оценках, которые подтверждают эффективность их представленного подхода. Указывается, что в нескольких оценках пропускают другие переменные, которые могут способствовать или, как правило, влиять на эффективность [28], такие как воспоминания и эмоции. Мы разделяем это мнение и утверждаем, что мы должны сначала оценить свойства, такие как воспринимаемая полезность, воспринимаемая удобство использования или запросы на функции, чтобы потенциально уточнить новый, исследовательский подход. Только после этого мы должны оценить эффективность и эффективность с помощью достаточно большого числа участников в контролируемых экспериментах [29]. В результате мы решили сначала провести исследовательское изучение пользователя. Мы спроектировали эксперимент, в котором участники используют и оценивают наш подход в процессе встроенной задачи, то есть в сценарии, аналогичного SC1 (см. Раздел III). В будущем мы также оценим наш подход в других сценариях, используя аналогичный эксперимент. В этой статье, однако, мы разработали эксперимент с акцентом на SC1 из -за реализации прототипа подхода, исследовательского характера исследования и продолжительности одного экспериментального прогона. В результате наши вопросы исследования (RQ) не обеспокоены эффективностью или эффективностью. Вместо этого мы сосредоточены на нескольких аспектах, чтобы собрать качественную обратную связь и количественные результаты, такие как время, проведенное во встроенное SV, чтобы получить первое представление о использовании нашего подхода:
• RQ1: Как субъекты используют встроенный редактор SV и кода во время решения задач?
• RQ2: Редактор кода воспринимается более полезным, чем встроенный SV?
• RQ3: Узнают ли субъекты полезность совместных функций SV для конкретных задач?
• RQ4: Каково общее восприятие полезности и удобства использования подхода?
• RQ5: Подход воспринимается как полезный в предполагаемых сценариях использования?
Мы снова подчеркиваем, что результаты этого вклада следует рассматривать как первые понимания и показатели для уточнения, а не статистически обоснованные результаты. Однако, отвечая на вопрос исследования, мы можем получить следующий основной вклад нашей оценки:
• Дальнейшее понимание относительно воспринимаемой полезности городов программного обеспечения для понимания поведения времени выполнения.
• Первые количественные и качественные результаты, касающиеся воспринимаемой полезности, воспринимаемой удобства и времени использования для совместных, проксимальных программных городов.
• Дополнительный пакет, содержащий необработанные результаты оценки, записи экранов всех участников и подробные инструкции, а также программные пакеты для воспроизведения [30].
Далее мы теперь представляем демографию участников и процедуру нашего эксперимента.
Авторы:
(1) Александр Краузе-Глау, Группа по разработке программного обеспечения, Университет Киля, Киль, Германия (akr@informatik.uni-kiel.de);
(2) Вильгельм Хассельбринг, Группа по разработке программного обеспечения, Университет Киля, Киль, Германия (wha@informatik.uni-kiel.de).
Эта статья есть
Оригинал