Programação em duplas: estado da arte

Resumo: Programação em Duplas (Pair Programming – PP) é uma prática colaborativa de desenvolvimento de software em que dois programadores trabalham ao mesmo tempo em um único computador e na mesma tarefa de programação. Foi relatado na literatura que o conhecimento sobre PP encontra-se disperso e desorganizado. Com o intuito de colocar um pouco de ordem a esse caos, o presente estudo realizou uma busca exaustiva de trabalhos sobre PP em algumas das bibliotecas digitais mais importantes do mundo em Ciência da Computação (Sociedade Brasileira de Computação, ACM, IEEE Explore, Springer, CiteSeer e ScienceDirect, entre outras) e no Google/Scholar. A partir da completa leitura dos trabalhos encontrados, procurou-se definir temas chave dentro da área descrevendo todos os estudos que se relacionam com cada tema. Os achados são interessantes e extensos – eles podem ser encontrados durante toda a leitura do presente artigo

Software Engineering Taxonomy of Team Processes: A Completeness and Usefulness Validation

RÉSUMÉ Objectif: Délibérer les études sur le travail d'équipe en génie logiciel (GL) et trouver un moyen de mieux comprendre la dynamique des équipes dans le domaine. Contexte: Plusieurs cadres et modèles théoriques ont été présentés dans la littérature sur le travail en équipe: des cadres généraux, des cadres spécifiques de travail et des modèles pour des fonctions spécifiques. Stratégie: Étude sur les équipes et l'équipe de travail dans la littérature du génie logiciel. Étude sur la programmation en paire (PP) comme un échantillon du travail en équipe en GL. Développement d'un processus itératif revu systématique de la littérature (iSR), utilisé comme un outil de recherche pour la collecte et la synthèse des données de la littérature. Méthodologie: Une revue systématique de la littérature sur le travail en équipe en GL et sur la programmation en paires est effectuée. Les résultats de l'examen de la littérature sont utilisés pour une validation d'une taxonomie de GL des processus d'équipe. Résultats: La taxonomie de GL des processus d'équipe est un outil approprié pour la présentation des observations des pratiques d'équipe dans le domaine du GL. Conclusion: Selon la méthodologie et les articles soumis, la taxonomie de GL des processus d'équipe a été validée. Les variables contextuelles des pratiques de PP ont également été identifiées et Le processus ISR a été jugée utile pour les novices. Application: La taxonomie de GL est un outil qui peut être utilisé par les chercheurs ainsi que les gestionnaires de projets logiciels pour identifier et signaler tout type d'interactions observées dans les équipes et pour améliorer les performances de la gestion des équipes.----------ABSTRACT Objective: To deliberate the studies on teamwork in Software Engineering (SE) and to find a way to better understand team dynamics in the SE domain. Background: Several theoretical frameworks and models have been presented in the teamwork literature: general frameworks, task specific frameworks and function-specific models. Strategy: Study on teams and team working in the software engineering literature. Study on pair programming as a sample practice of teamwork. Development of an iterative systematic literature review (iSR) process used as a research tool for gathering and synthesizing data from the literature. Methodology: A systematic literature review on team working in SE and on pair programming is performed. The literature review results are used for an evaluation of current team working practices (namely PP practices) and for the validation of the SE taxonomy of team processes. Results: The SE taxonomy of team processes is an appropriate tool for the report of observations in teamwork practices in the SE domain. Conclusion: According to the employed methodology and submitted articles, the software engineering taxonomy of team processes was validated. The contextual variables of PP practice were also identified. The iSR process was found to be useful for novices. Application: The SE taxonomy is a tool which can be used by researchers as well as software project managers for identifying and reporting any kind of observed teamwork interactions. Report and analysis of team activities could improve team management performance

Automatic Difficulty Detection

Previous work has suggested that the productivity of developers increases when they help each other and as distance increases, help is offered less. One way to make the amount of help independent of distance is to develop a system that automatically determines and communicates developers' difficulty. It is our thesis that automatic difficulty detection is possible and useful. To provide evidence to support this thesis, we developed six novel components: * programming-activity difficulty-detection * multimodal difficulty-detection * integrated workspace-difficulty awareness * difficulty-level detection * barrier detection * reusable difficulty-detection framework Programming-activity difficulty-detection mines developers' interactions. It is based on the insight that when developers are having difficulty their edit ratio decreases while other ratios such as the debug and navigation ratios increase. This component has a low false positive rate but a high false negative rate. The high false negative rate limitation is addressed by multimodal difficulty-detection. This component mines both programmers' interactions and Kinect camera data. It is based on the insight that when developers are having difficulty, both edit ratios and postures often change. Integrated workspace-difficulty awareness combines continuous knowledge of remote users' workspace with continuous knowledge of when developers are having difficulty. Two variations of this component are possible based on whether potential helpers can replay developers' screen recordings. One limitation of this component is that sometimes, potential helpers spend a large amount of time trying to determine if they can offer help. Difficulty-level and barrier detection address this limitation. The former is based on the insight that when developers are having surmountable difficulties they tend to perform a cycle of editing and debugging their code; and when they are having insurmountable difficulties they tend to spend a large amount of time a) between actions and b) outside of the programming environment. Barrier detection infers two kinds of difficulties: incorrect output and design. This component is based the insight that when developers have incorrect output, their debug ratios increase; and when they have difficulty designing algorithms, they spend a large amount of time outside of the programming environment. The reusable difficulty-detection framework uses standard design patterns to enable programming-activity difficulty-detection to be used in two programming environments, Eclipse and Visual Studio. These components have been validated using lab and/or field studies.Doctor of Philosoph