A controlled experiment on team meeting effectiveness in software architecture evaluation

Abstract

Die Architektur eines Softwareprodukts ist ein sehr kritischer Punkt in der Software Entwicklung, weil die Qualität der Architektur sehr eng mit der Qualität des fertigen Produktes zusammenhängt. Aus diesem Grund ist es sehr wichtig sicherzustellen, dass die Architektur sehr sorgfältig definiert und überprüft wird - und das in frühen Stadien des Software-Entwicklungsprozesses. Der Aufwand und die Kosten steigen, je später Fehler bemerkt werden oder Änderungen auftreten.<br />Architektur-Reviews unterstützen Entwickler dabei die Qualität der Architektur in frühen Entwicklungsphasen sicherzustellen und diese genau zu evaluieren. Szenarien sind bekannte Ansätze um einen guten Überblick zu bekommen, was von einer Software-Architektur verlangt wird und wie diese aussehen sollte, um den verlangten Qualitätsmerkmalen (auch nicht-funktionale Anforderungen genannt) des Produkts zu entsprechen.<br />Solche Merkmale können zukünftige Anforderungen, wie z.B. in den Bereichen der Modifizierbarkeit, Wartbarkeit, etc., aufzeigen. Solche möglichen Änderungen sollten bereits früh in der Software-Entwicklung bedacht werden. Szenarien können durch Brainstorming-Sessions einzelner Personen aber auch in Teams identifiziert werden. Durch Team-Meetings können bessere und wertvollere Szenarios durch Diskussion und Interaktion der Teilnehmer entdeckt werden. Richtlinien können den Teilnehmern dabei helfen sich auf eine spezielle Szenario-Kategorie zu konzentrieren. Es ist sehr wichtig die bestmögliche Methode für das Erstellen solcher Szenarien zu finden, da die Ergebnisse solcher Evaluierungen mit der Qualität des Endprodukts zusammenhängen.<br />Empirische Studien helfen herauszufinden, welche Methoden am besten geeignet sind, indem reale Bedingungen von Architektur-Evaluierungen in einem kontrollierten Experiment nachgestellt werden. In unserer Untersuchung wurden 54 Studenten, mit unterschiedlicher Qualifikation, gebeten Architektur-Szenarien für zwei unterschiedliche Systeme zu finden, welche jeweils unterschiedliche Aufgabengebiete und Funktionen hatten. Durch die Evaluierung zweier Applikationen haben wir einen besseren Überblick bekommen und eine bessere Vorstellung davon welche Anforderungen verlangt werden. Zu Beginn mussten die Studenten Szenarien alleine finden und anschließend daran in einer Gruppe von drei Leuten.<br />Während dieser Gruppenphase gab es zwei Möglichkeiten wie die Studenten miteinander kommunizieren konnten: Die eine Hälfte der Teams kommunizierte und diskutierte die Szenarien von Angesicht zu Angesicht, während die andere Hälfte der Teams über das Internet mit einer textbasierten Chat-Applikation kommunizierte, ohne physisch beieinander zu sitzen. Um zu untersuchen, welche gefundenen Szenarien "die besten" sind, wurde ein Referenz-Profil erstellt, welches auf allen gefundenen Szenarien basierte.<br />In dieser Arbeit wollten wir die beste Möglichkeit identifizieren, wie Szenarien für Architektur-Reviews in Teams gefunden werden können. Aber welche Art von Team-Meeting wäre optimal - physische, reale Meetings oder Meetings mit elektronischen Hilfsmitteln, wie z.B. über das Internet mit einer Chat-Applikation? Das ist eine sehr wichtige Frage, da reale Meetings viel teurer sind, weil alle Teilnehmer physisch am selben Ort zusammenkommen müssen. Wäre die Qualität der Szenarien beider Team-Meeting Möglichkeiten gleich, würde dies reale Meetings obsolet machen.<br />Wir haben herausgefunden, dass Teams, die sich real getroffen haben, mehrere wichtige Szenarien gefunden haben, als Teams die über eine textbasierte Chat-Applikation kommuniziert haben. Wir haben auch herausgefunden, dass real-treffende Teams im Verhältnis mehr wichtige Szenarien in ihren Szenario-Profilen, im Vergleich zu ihrer individuellen Phase, hatten als Teams, die über das Internet kommunizierten. Ein Zusammenhang zwischen der Erfahrung der Teilnehmer und der Anzahl an gefunden, wichtigen Szenarien konnte nicht festgestellt werden.<br />Diese Ergebnisse können Entscheidungsträgern dabei helfen, welche Team-Meeting Methode bei der Evaluierung von Software Architekturen die effizienteste ist, um eine möglichst hohe Qualität des Softwareprodukts zu gewährleisten.<br />

The architecture of a software product is a success critical issue in software development, because the quality of the architecture coheres very strongly with the quality of the final product. Thus, it is very important to ensure that the architecture is set up and reviewed very carefully early in the development life cycle of a software product. Rework effort and cost increases, the later defects are identified or changes occur. Architecture reviews support engineers to ensure the quality of the selected architecture early in the software development process and help engineers in efficiently evaluating the underlying architecture of a software product. Scenarios are well-known approaches to get a well-defined focus on what is needed and how the architecture of a software product should look like to meet the quality (or non-functional) requirements of the product. Quality requirements can address possible upcoming needs, e.g., modifiability and maintainability, during development and maintenance. These changes should be addressed early in the development life-cycle. Scenarios can be developed through individual brainstorming sessions or in architecture evaluation team meetings to identify better and more valuable scenarios due discussion and interaction. Brainstorming guidelines can help reviewers to focus on a defined scenario category.<br />Thus, the results of such brainstorming sessions cohere with the quality of the final product, so it is very important to find the most convincing method of creating these scenarios. Empirical studies help to find those most convincing methods by rebuilding real circumstances of architecture evaluation in a controlled experiment. In our research 54 students, who had different levels of qualification, were asked to identify architecture scenarios for two different software systems - each with different focuses and functions.<br />Evaluating two applications gives us a better and more general view on what requirements are requested. First the students had to find some scenarios individually and then in a group of three people. While in a group there were two different ways, how the students could communicate with each other. One half of the teams was communicating and discussing the scenarios face to face and the other half was communicating over the internet with a text-based chat application. To tell which scenarios are "the best", a reference-scenario profile of all found scenarios was created. In this work we wanted to investigate the most effective way for creating architecture scenarios with the team processes for scenario identification. But what kind of team meeting would be optimal - Face to face or tool-supported communication? This is a very important question - doing face to face meetings is much more expensive than doing tool-supported communication, because all participants have to come together physically - maybe even coming from different continents.<br />Comparable quality levels of architecture scenarios from both meeting styles would make face to face meetings obsolete.<br />We found out that groups, that were communicating face to face, have found more important scenarios than groups communicating with the text-based chat-application. We also saw that face to face teams had more important scenarios in their scenario-profiles compared to the individual phase, than tool-support teams. We also had a look at the relationship between experience and the number of important scenarios found, but we could not see a connection between the meeting style of the teams and their experience as we measured it. These results can help decision makers and stakeholders to choose, which team-meeting method of evaluating software architecture scenarios will be more efficient to ensure a high quality of the software product.<br />Another interesting aspect of analyzing which way of communication is more effective is, that it can also be learned which method might be more effective for evaluation, meetings, etc. in general.<br />