Silvia T. Acuña

How do personality, team processes and task characteristics relate to job satisfaction and software quality?

This article analyses the relationships between personality, team processes, task characteristics, product quality and satisfaction in software development teams. The data analysed here were gathered from a sample of 35 teams of students (105 participants). These teams applied an adaptation of an agile methodology, eXtreme Programming (XP), to develop a software product. We found that the teams with the highest job satisfaction are precisely the ones whose members score highest for the personality factors agreeableness and conscientiousness. The satisfaction levels are also higher when the members can decide how to develop and organize their work. On the other hand, the level of satisfaction and cohesion drops the more conflict there is between the team members. Finally, the teams exhibit a significant positive correlation between the personality factor extraversion and software product quality.

Assigning people to roles in software projects

This paper is based on the premise that peoples behavioural competencies or characteristics of professional conduct influence the effectiveness and efficiency with which they perform a predetermined role in the software process. We propose a capabilities‐oriented process model that includes traditional elements of the software process (activities, products, techniques, people and roles) and the original element of this paper (capabilities). With the aim of adding behavioural competencies to the process model, we define the capability–person and capability–role relationships involved in software development. Additionally, we propose two procedures that are based on each of these relationships: a procedure that can be used to determine the capabilities of the members of a development team; and a procedure that can be used to assign people to perform roles depending on their capabilities and the capabilities demanded by the roles. Finally, the person–capabilities–role relationship has been empirically validated. The results yielded by this experiment confirm the hypothesis that assigning people to roles according to their capabilities and the capabilities demanded by the role improves software development. Copyright

Towards understanding the relationship between team climate and software quality--a quasi-experimental study

This paper describes an empirical study that examined the work climate within software development teams. The question was whether the team climate in software developer teams has any relation to software product quality. We define team climate as the shared perceptions of the team’s work procedures and practices. The team climate factors examined were West and Anderson’s participative safety, support for innovation, team vision and task orientation. These four factors were measured before the project using the Team Selection Inventory (TSI) test to establish subject climate preferences, as well as during and after the project using the Team Climate Inventory (TCI) test, which establishes the subject’s perceptions of the climate. In this quasi-experimental study, data were collected from a sample of 35 three-member developer teams in an academic setting. These teams were formed at random and their members were blind to the quasi-experimental conditions and hypotheses. All teams used an adaptation of extreme programming (XP) to the students’ environment to develop the same software system. We found that high team vision preferences and high participative safety perceptions of the team were significantly related to better software. Additionally, the results show that there is a positive relationship between the categorization of better than preferred, as preferred and worse than preferred climate and software quality for two of the teamwork climate factors: participative safety and team vision. So it seems important to track team climate in an organization and team as one (of many) indicators of the quality of the software to be delivered.

A HCI technique for improving requirements elicitation

Context: To develop usable software we need to understand the users that will interact with the system. Personas is a HCI technique that gathers information about users in order to comprehend their characteristics. This information is used to define fictitious persons on which development should focus. Personas provides an understanding of the user, often overlooked in SE developments. Objective: The goal of our research is to modify Personas to readily build the technique into the requirements stage of regular SE developments. Method: We tried to apply Coopers version of the Personas technique and we found shortcomings in both the definition of the procedure to be enacted and the formalization of the product resulting from the execution of each step of the Personas technique. For each of these limitations (up to a total of 11), we devised an improvement to be built into Personas. We have incorporated these improvements into a SE version of Personas. The improved Personas avoid the weaknesses encountered by an average software developer unfamiliar with HCI techniques applying the original Personas. Results: We aim to improve requirements elicitation through the use of Personas. We have systematized and formalized Personas in the SE tradition in order to build this new version of the technique into the requirements stage. We have applied our proposal in an application example. Conclusion: The integration of Personas into the SE requirements stage might improves the understanding of what the software product should do and how it should behave. We have modified the HCI Personas technique to comply with the levels of systematization required by SE. We have enriched the SE requirements process by incorporating Personas activities into requirements activities. Requirements elicitation and requirements analysis are the RE activities most affected by incorporating Personas.

A PROCESS MODEL APPLICABLE TO SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING

Software engineering (SE) and knowledge engineering (KE) develop software systems using different construction process models. Because of the growing complexity of the problems to be solved by computers, the conventional systems (CS) and knowledge-based systems (KBS) software process is at present passing through a period of integration. In this paper, we propose a software process model applicable to both CS and KBS. The model designed is declarative, that is, it indicates what is done to build a software system. Its goal is to provide software and knowledge engineers with a techno-conceptual tool to develop systems comprising both traditional and knowledge-based software.

Empirical study of how personality, team processes and task characteristics relate to satisfaction and software quality

This paper analyses the relationships between personality, team processes, task characteristics, product quality and satisfaction in software development teams. The data analysed here were gathered from a sample of 35 teams of students (105 participants) from a Spanish university. These teams applied an adaptation of an agile methodology, eXtreme Programming (XP), to develop the same software product. We found that the teams with the highest job satisfaction are precisely the ones whose members score highest for the personality factors agreeableness and conscientiousness. The satisfaction levels are also higher when the members can decide how to develop and organize their work. On the other hand, the level of satisfaction and cohesion drops the more conflict there is between the team members. Finally, the teams exhibit a significant positive correlation between the personality factor extroversion and software product quality.

Are team personality and climate related to satisfaction and software quality? Aggregating results from a twice replicated experiment

Acuna, Silvia T.; Gomez, Marta N.; Hannay, Jo Erskine; Juristo, Natalia; Pfahl, Dietmar. Are team personality and climate related to satisfaction and software quality? Aggregating results from a twice replicated experiment. Information and Software Technology 2015 ;Volum 57. s. 141-156

Software engineering group work: personality, patterns and performance

Software Engineering has been a fundamental part of many computing undergraduate courses for a number of years. Although many of the tools and techniques used to undertake software engineering have changed, the assessment has typically stayed the same. Students are commonly tasked with producing a number of software artefacts, for example designs using the Unified Modelling Language (UML). We recently attempted to extend the software engineering experience for a group of second year students with them participating in groups that attempt to replicate industrial practice. This paper reports our investigation into the correlation between the personality of group members, their approach with respect to using design patterns and their learning achievements.

A systematic mapping study on the open source software development process

Background: There is no globally accepted open source software development process to define how open source software is developed in practice. A process description is important for coordinating all the software development activities involving both people and technology. Aim: The research question that this study sets out to answer is: What activities do open source software process models contain? The activity groups on which it focuses are Concept Exploration, Software Requirements, Design, Maintenance and Evaluation. Method: We conduct a systematic mapping study (SMS). A SMS is a form of systematic literature review that aims to identify and classify available research papers concerning a particular issue. Results: We located a total of 29 primary studies, which we categorized by the open source software project that they examine and by activity types (Concept Exploration, Software Requirements, Design, Maintenance and Evaluation). The activities present in most of the open source software development processes were Execute Tests and Conduct Reviews, which belong to the Evaluation activities group. Maintenance is the only group that has primary studies addressing all the activities that it contains. Conclusions: The primary studies located by the SMS are the starting point for analyzing the open source software development process and proposing a process model for this community. The papers in our paper pool that describe a specific open source software project provide more regarding our research question than the papers that talk about open source software development without referring to a specific open source software project.

Design and programming patterns for implementing usability functionalities in web applications

Usability is a software system quality attribute. There are usability issues that have an impact not only on the user interface but also on the core functionality of applications. In this paper, three web applications were developed to discover patterns for implementing two usability functionalities with an impact on core functionality: Abort Operation and Progress Feedback. We applied an inductive process in order to identify reusable elements to implement the selected functionalities. For communication purposes, these elements are specified as design and programming patterns (PHP, VB.NET and Java). Another two web applications were developed in order to evaluate the patterns. The evaluation explores several issues such as ease of pattern understanding and ease of pattern use, as well as the final result of the applications.We found that it is feasible to reuse the identified solutions specified as patterns. The results also show that usability functionalities have features, like the level of coupling with the application or the complexity of each component of the solution, that simplify or complicate their implementation. In this case, the Abort Operation functionality turned out to be more feasible to implement than the Progress Feedback functionality. It is possible to identify reusable elements to implement usability functionalities.Reusable elements can be specified as design patterns and programming patterns.Abort Operation can be specified as a design and programming pattern.Progress Feedback can be specified as a design and programming pattern.