Online Collaborative Editor

“Online collaborative editor” is a node.js based browser application that provides real time collaborative editing of files and improves pair programming. Current real time editors fail to provide simultaneous viewing and editing of files within the server and results in a complex version controlling system. Such systems are also vulnerable to deadlocks and race conditions. This project provides a platform for real time collaborative editors, which can support simultaneous editing and viewing of files and handle concurrency problems by using locking mechanism. The experiment results showed that node.js platform provides good performance for collaborative editing

Identifying Coordination Problems in Software Development:Finding Mismatches between Software and Project Team Structures

Today's dynamic and iterative development environment brings significant challenges for software project management. In distributed project settings, "management by walking around" is no longer an option and project managers may miss out on key project insights. The TESNA (TEchnical Social Network Analysis) method and tool aims to provide project managers both a method and a tool for gaining insights and taking corrective action. TESNA achieves this by analysing a project's evolving social and technical network structures using data from multiple sources, including CVS, email and chat repositories. Using pattern theory, TESNA helps to identify areas where the current state of the project's social and technical networks conflicts with what patterns suggest. We refer to such a conflict as a Socio-Technical Structure Clash (STSC). In this paper we report on our experience of using TESNA to identify STSCs in a corporate environment through the mining of software repositories. We find multiple instances of three STSCs (Conway's Law, Code Ownership and Project Coordination) in many of the on-going development projects, thereby validating the method and tool that we have developed

Engaging developers in open source software projects: harnessing social and technical data mining to improve software development

As software development has evolved, an increasing amount of collaboration and management is done online. Open source software, in particular, has benefited greatly from communication and collaboration on the Internet. As software projects increase in size, the codebase complexity and required communication between developers increases. The barriers of entry for development participation are not only technical in nature but involve understanding the changing dynamics of the community. Social Technical Congruence (STC) attempts to understand and model the synergies between technical development and communication. Motivated by this theory, three algorithms were developed that leverage data from version control history and email mailing list communication to help developers better understand the community. The “code impact” algorithm identifies commits that are impactful to the overall technical structure of the source code. The “developer knowledge” algorithm calculates the knowledge that a developer or developers have for a particular section of code. Lastly, the “communication suggestions” algorithm provides suggestions about who a developer could be increasing communication with on the mailing list based on shared technical dependencies and recent communication. These algorithms were implemented in an online website called “Jamii”. Through an interactive front-end, the website provides relevant development-centric information to the community. The website was evaluated with Mozilla and KDE, two large open source communities. Quantitative and qualitative analysis provide details about the socialization process before the website was developed through an initial survey as well as afterwards. The results from the initial survey paint a primarily positive picture of socialization and inclusion for KDE and a more complex process of socialization and inclusion for Mozilla because of the large size of its community and codebase. In many cases for both communities, the ratings on a number of factors regarding the socialization process and effective coordination were actually higher for the beginner participants as compared to the veterans. This suggests that new participants may have an overly-inflated positive view than veteran members. This work provides fundamental contributions to the field of STC and may generalize to other distributed online collaboration efforts

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

Semi-Synchronous Conflict Detection and Resolution in Asynchronous Software Development

Abstract. Previous work has found that (a) when software is developed collaboratively, concurrent accesses to related pieces of code are made, and (b) when these accesses are coordinated asynchronously through a version control system, they result in increased defects because of conflicting concurrent changes. Previous findings also show that distance collaboration aggravates software-development problems and radical colocation reduces them. These results motivate a semi-synchronous distributed computersupported model that allows programmers creating code asynchronously to synchronously collaborate with each other to detect and resolve potentially conflicting tasks before they have completed the tasks. We describe, illustrate, and evaluate a new model designed to meet these requirements. Our results show that the model can catch conflicts at editing time that would be expensive to manage at later times

Ansatz einer entwicklungsprojektweiten Abhängigkeits-Konsistenz des Quellcodemodells zur Qualitätsverbesserung von Software-Entwicklungsprojekten

Heutige Softwareentwicklungsprojekte müssen oft eine Vielzahl von Anforderungen mit hoher Komplexität in kurzen Release-Zyklen umsetzen. Daraus ergeben sich besondere Herausforderungen an Arbeitsteilung, Dokumentation, Prozesssicherheit und Qualität. Entwicklungsarbeiten müssen parallelisiert werden und Softwareentwickler müssen sich immer wieder in den Quellcode einarbeiten. Die Entwickler brauchen schnelle und präzise Rückmeldung über die Qualität ihrer durchgeführten Änderungen am Quellcode. Über feingranulare Traceability Links in den Quellcode werden eine verbesserte Dokumentation und größere Prozesssicherheit ermöglicht. Dazu wird ein Metamodell für den Quellcode definiert und in ein Metamodell mit Anforderungsmanagement, Änderungsmanagement, Testdatenmanagement und Dokumentation eingebunden. Das gesamte Modell wird in einem Software Configuration Management (SCM) Repository abgespeichert, um die Versionierung aller Artefakte und Links zu ermöglichen. In einem Quellcode Editor können die Traceability Links erstellt und genutzt werden. Die Historie einzelner Quellcode Artefakte kann einschließlich der Traceability Links im Editor zur Anzeige gebracht werden. Durch das Vorliegen des Quellcodes als Modell wird auch ein feingranulares pessimistisches Sperren einzelner Modell Artefakte ermöglicht. Damit ist das parallele Bearbeiten einer Klasse oder einer Methode möglich, ohne dass der Quellcode verschmolzen werden muss. Es werden durch die Sperren auch Syntaxfehler im SCM Repository verhindert. Im Quellcode Editor werden die Sperren anderer Entwickler angezeigt. Continuous Integration wird dahingehend erweitert, dass durch Abspeichern von Class-Dateien im Repository ein schneller Produkt-Build und damit auch schnelleres Feedback für den Entwickler ermöglicht wird. Durch Testauswahlstrategien werden nur für den geänderten Quellcode relevante Tests ausgeführt. Eine Testauswahlstrategie verwendet dabei die Traceability Informationen zwischen geänderten Quellcode, Anforderung, Testspezifikation und dem Test-Quellcode. In großen Projekten entstehen auf Grund des Quellcodes sehr große Modelle, die eine Herausforderung bezüglich Speicherbedarfes und Performance darstellen. Es wurden Untersuchungen an Hand eines Projekts mit 6,5 Millionen Quellcode-Zeilen durchgeführt. Für diese Konzepte wurde ein Prototyp auf Basis der Eclipse Entwicklungsumgebung und für Java entwickelt