Левицата на масата Абстракт и I. Въведение II. Подходът А. Архитектурно проектиране Б. Доказателство за реализация на концепцията III. Предвидени сценарии за използване IV. Експериментален дизайн и демография А. Участници Б. Целева система и задача В. Процедура V. Резултати и дискусии VI. Свързани дейности VII. Заключения и бъдеща работа, признания и препратки III. Предвидени сценарии за използване В допълнение към използването на усъвършенствани (веб) технологии, нашият подход може да бъде диференциран от свързаната работа чрез използването на динамичен анализ и съвместни SV функции. Сценарий 1 (SC1): Улесняване на процеса на набиране на борда В професионалното разработване на софтуер компаниите използват различни техники за процеса на вграждане на нови разработчици. Поддръжката на партньори, преглед на продуктите и прости задачи се възприемат като полезни в този контекст [22], докато намирането на документация и технически проблеми, напр. създаване на среда за разработване, възпрепятства процеса на вграждане, особено за отдалечена работа [23]. Освен това предвиждаме сценарий, при който все по-големи части от изходния код (например в зависимост от опита) са подготвени да ръководят новите разработчици стъпка по стъпка през поведението на софтуерната система. Потребителите кликват върху случай на използване на анализираната (разпределена) целева система и разбират нейното разгръщане чрез SV Сценарий 2 (SC2): Подчертаване на промените по време на прегледа на кода Въпреки това, рецензентите са склонни да дават празни отзиви и обикновено докладват за ограниченията на инструментите за преглед, когато се използват в сложни сценарии [26]. В този контекст виждаме друг потенциален сценарий за използване на нашия подход, който описваме по-долу. Предполага се, че член на екипа преглежда промените в кода на колега. За да направите това, той или тя може да кликне върху връзка в рамките на искането за изтегляне, която отваря подготвен, базиран на облак редактор на код с вграден SV на поведението на новата програма (поради промяната на кода на източника). Промените в кода на източника се кодират по цвят в IDE. За да се разбере поведението на програмата, е възможно да Сценарий 3 (SC3): Интегриране на информацията за изпълнението в дейностите по разработване Използва се за тестване на софтуерни системи в среда, подобна на производството. Предполагаме, че редакторите на кодове информират избраните разработчици за проблеми с производителността на инсталирана софтуерна система (например в зоната за поставяне на сцената). Разработчикът може да кликне върху това известие, за да отвори вградения SV. Визуализацията изобразява поведението по време на изпълнение, което включва проблема с производителността. Също така подчертава субекта, който въвежда проблема, например метод, който отнема твърде дълго време, за да завърши. IV. Експериментален дизайн и демография В този контекст, Merino et al. [27] представят систематичен преглед на литературата на оценката на SV. Тяхната работа изследва литературното тяло на пълни статии, които са публикувани в конференциите SOFTVIS/VISSOFT, което води до изследване на 181 статии. Авторите се фокусират върху оценките, които валидират ефективността на представения им подход. Той споменава, че многобройните оценки изоставят други променливи, които могат да допринесат за или като цяло да повлияят на ефективността [28], като например напомняне и емоции. Ние споделяме това мнение и твърдим, че първо трябва да оценяваме свойства като възприеманата полезност, възприеманата използваемост или искания за потенциално преработване на нов, експериментален подход • : Как субектите използват вградения SV и редактор на код по време на решаването на задачи? РК1 • : Смятате ли, че редакторът на код е по-полезен от вградения SV? РК2 • : Разпознават ли субектите полезността на съвместните SV функции за конкретни задачи? РК3 • Какво е общото възприятие за полезността и използваемостта на подхода? РК4 • : Възприема ли се подходът като полезен в предвидените сценарии за използване? РК5 Отново подчертаваме, че резултатите от този принос трябва да се разглеждат като първи прозрения и показатели за усъвършенствания, а не като статистически обосновани резултати. • По-нататъшни прозрения относно възприеманата полезност на софтуерните градове за разбиране на поведението по време на изпълнение. • Първи количествени и качествени резултати по отношение на възприеманата полезност, възприеманата използваемост и времето за използване за съвместни, близки до кода софтуерни градове. • Допълнителен пакет, съдържащ сурови резултати от оценката, екранни записи на всички участници и подробни инструкции, както и софтуерни пакети за възпроизвеждане [30]. По-долу представяме демографията на участниците и процедурата на нашия експеримент. 
 
 
 
 на авторите: (1) Alexander Krause-Glau, Software Engineering Group, Kiel University, Kiel, Германия (akr@informatik.uni-kiel.de); (2) Wilhelm Hasselbring, Software Engineering Group, Kiel University, Kiel, Германия (wha@informatik.uni-kiel.de). Authors: (1) Alexander Krause-Glau, Software Engineering Group, Kiel University, Kiel, Германия (akr@informatik.uni-kiel.de); (2) Wilhelm Hasselbring, Software Engineering Group, Kiel University, Kiel, Германия (wha@informatik.uni-kiel.de). 
 
 Тази статия е достъпна под лиценза CC BY 4.0 DEED. Тази статия е достъпна под лиценза CC BY 4.0 DEED. Достъпно за архивиране

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Pair Programming AI Agent 

undefined's blog

Това аудио е създадено на оригиналния език на историята!

Защо интерактивните визуализации са следващото голямо нещо в софтуерното сътрудничество

About Author

КОМЕНТАРИ

ЗАКАЧВАЙТЕ ЕТИКЕТИ

ТАЗИ СТАТИЯ Е ПРЕДСТАВЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps