Using Project-Based-Learning in a mobile application development course—An experience report

In this paper, we report the experience gained in a Mobile Application Development course. We involved students in Computer Science at the University of Salerno, who in teams had to conduct a project. The goal of this project was to design and develop applications (or simply app) for Android-based devices. The adopted teaching approach was based on Project-Based-Learning and enhanced collaboration and competition. Collaboration took place among members of the same team (intra-team), while competition among different teams of students (extra-team). To allow intra-team collaboration, students used GitHub as Computer-Supported-Collaborative-Learning tool. It provided support for implicit and explicit communication among members in each team and for distributed revision control and management of software artifacts (e.g., source code and requirements models). Developed apps underwent a final public competition prized by IT managers of national and international software companies. This is how we implemented extra-team competition. IT managers expressed a positive judgment on both students׳ competition and developed apps. Also, students provided very good feedback on used teaching approach and support GitHub provided.     

RESRES: The story behind the paper “Research in software engineering: An analysis of the literature”

This article is a background report describing a comprehensive study of research in the three computing disciplines Computer Science, Software Engineering, and Information Systems. Findings relate to research topics, approaches, methods, reference disciplines, and levels of analysis. The article informally describes the process used and the research products produced.     

Investigating Knowledge Management practices in software development organisations – An Australian experience

This study, using both quantitative and qualitative methods, investigates current practice of Knowledge Management (KM) in Software Engineering (SE) processes in two Australian companies on the basis that they both claimed to apply KM practices in their software development work. It also describes the KM activities and KM process used in SE practice, and examines the enablers of KM process for SE in terms of leadership, technology, culture, process and measurement.One of the main findings showed that software developers believe in the usefulness of knowledge sharing; however, their ability to utilise some of the KM systems was limited. The most commonly used systems included personal networks, informal networks, groupware and third-party knowledge. There is a need to formalise knowledge sharing of practices, while also supporting informal and ad-hoc knowledge sharing. While KM was considered to be important, the tools, techniques and methodologies currently employed for software development were inadequate to address effective management of knowledge in these organisations. In both organisations, a uniform model of the KM process did not exist. Among the four KM enablers, leadership was considered to be the most significant as top-down KM strategies were seemingly being pursued by management. Technology was also considered to be an obvious mechanism for KM, despite some of their current KM systems either being unsuitable or inaccessible. In addition, the crucial role that personal networks played in accessing tacit and implicit knowledge was seen as a key reason to foster a culture that encourages participants to share their knowledge with others.     

Communities of practice in a large distributed agile software development organization – Case Ericsson

ContextCommunities of practice—groups of experts who share a common interest or topic and collectively want to deepen their knowledge—can be an important part of a successful lean and agile adoption in particular in large organizations.ObjectiveIn this paper, we present a study on how a large organization within Ericsson with 400 persons in 40 Scrum teams at three sites adopted the use of Communities of Practice (CoP) as part of their transformation from a traditional plan-driven organization to lean and agile.MethodsWe collected data by 52 semi-structured interviews on two sites, and longitudinal non-participant observation of the transformation during over 20 site visits over a period of two years.ResultsThe organization had over 20 CoPs, gathering weekly, bi-weekly or on a need basis. CoPs had several purposes including knowledge sharing and learning, coordination, technical work, and organizational development. Examples of CoPs include Feature Coordination CoPs to coordinate between teams working on the same feature, a Coaching CoP to discuss agile implementation challenges and successes and to help lead the organizational continuous improvement, an end-to-end CoP to remove bottlenecks from the flow, and Developers CoPs to share good development practices. Success factors of well-functioning CoPs include having a good topic, passionate leader, proper agenda, decision making authority, open community, supporting tools, suitable rhythm, and cross-site participation when needed. Organizational support include creating a supportive atmosphere and providing a suitable infrastructure for CoPs.ConclusionsIn the case organization, CoPs were initially used to support the agile transformation, and as part of the distributed Scrum implementation. As the transformation progressed, the CoPs also took on the role of supporting continuous organizational improvements. CoPs became a central mechanism behind the success of the large-scale agile implementation in the case organization that helped mitigate some of the most pressing problems of the agile transformation.     

An analysis of the most cited articles in software engineering journals – 2002

Citations and related work are crucial in any research to position the work and to build on the work of others. A high citation count is an indication of the influence of specific articles. The importance of citations means that it is interesting to analyze which articles are cited the most. Such an analysis has been conducted using the ISI Web of Science to identify the most cited software engineering journal articles published in 2002. The objective of the analysis is to identify and list the articles that have influenced others the most as measured by citation count. An understanding of which research is viewed by the research community as most valuable to build upon may provide valuable insights into what research to focus on now and in the future. Based on the analysis, a list of the 20 most cited articles is presented here. The intention of the analysis is twofold. First, to identify the most cited articles, and second, to invite the authors of the most cited articles in 2002 to contribute to a special section of Information and Software Technology. Six authors have accepted the invitation and their articles appear in this special section.     

Empowering the users? A critical textual analysis of the role of users in open source software development

This paper outlines a critical, textual approach for the analysis of the relationship between different actors in information technology (IT) production, and further concretizes the approach in the analysis of the role of users in the open source software (OSS) development literature. Central concepts of the approach are outlined. The role of users is conceptualized as reader involvement aiming to contribute to the configuration of the reader (to how users and the parameters for their work practices are defined in OSS texts). Afterwards, OSS literature addressing reader involvement is critically reviewed. In OSS context, the OSS writers as readers configure the reader and other readers are assumed to be capable of and interested in commenting the texts. A lack of OSS research on non-technical reader involvement is identified. Furthermore, not only are the OSS readers configured, but so are OSS writers. In OSS context while writers may be empowered, this clearly does not apply to the non-technical OSS readers. Implication for research and practice are discussed.

---

Processes versus people: How should agile software development maturity be defined?

Maturity in software development is currently defined by models such as CMMI-DEV and ISO/IEC 15504, which emphasize the need to manage, establish, measure and optimize processes. Teams that develop software using these models are guided by defined, detailed processes. However, an increasing number of teams have been implementing agile software development methods that focus on people rather than processes. What, then, is maturity for these agile teams that focus less on detailed, defined processes? This is the question we sought to answer in this study. To this end, we asked agile practitioners about their perception of the maturity level of a number of practices and how they defined maturity in agile software development. We used cluster analysis to analyze quantitative data and triangulated the results with content analysis of the qualitative data. We then proposed a new definition for agile software development maturity. The findings show that practitioners do not see maturity in agile software development as process definition or quantitative management capabilities. Rather, agile maturity means fostering more subjective capabilities, such as collaboration, communication, commitment, care, sharing and self-organization.     

Pair programming in software development teams – An empirical study of its benefits

We present the results of an extensive and substantial case study on pair programming, which was carried out in courses for software development at the University of Dortmund, Germany. Thirteen software development teams with about 100 students took part in the experiments. The groups were divided into two sets with different working conditions. In one set, the group members worked on their projects in pairs. Even though the paired teams could only use half of the workstations the teams of individual workers could use, the paired teams produced nearly as much code as the teams of individual workers at the same time. In addition, the code produced by the paired teams was easier to read and to understand. This facilitates finding errors and maintenance.     

An empirical study of the Cobb–Douglas production function properties of software development effort

In this paper we study whether software development effort exhibits Cobb–Douglas functional form with respect to team size and software size. We empirically test this relationship using real-world software engineering data set containing over 500 software projects. The results of our experiments indicate that the hypothesized Cobb–Douglas function form for software development effort with respect to team size and software size is true. We also find increasing returns to scale relationship between software size and team size with software development effort.     

Self-correcting mechanisms and echo-effects in social media: An analysis of the “gunman in the newsroom” crisis

The positive and negative effects of social media in crises are currently receiving an increased amount of scholarly attention. This study focuses on Twitter users in the context of a crisis in the Netherlands on January 29, 2015. After having made a bomb threat, an armed man managed to get access to the national news broadcasting station around 8 pm, where he demanded airplay to share “an important message” with Dutch citizens. Three weeks after the terrorist attack on Charlie Hebdo in Paris, approximately 1.5 million viewers were anxious that a similar attack was taking place in the television studio. The crisis, also followed by social media users, reached a climax when armed policemen arrested the man, which was later shown on national TV. We analyzed 58,931 tweets, posted in the six hours after the incident. By examining shared facts and rumors during the gunman crisis, we identified an “echo-effect”: the dissemination of older tweets continued after the posting of new facts by the same source. Moreover, we found that two rumors were based on misinterpreted humor in Twitter messages. The study adds insight into the self-correcting mechanism of social media communities when verifying and dispelling online rumors during crises.     

Have your cake and eat it too? Simultaneously pursuing the knowledge-sharing benefits of agile and traditional development approaches

This research examines how organizations manage knowledge-sharing processes in systems development projects that employ both agile and traditional development techniques. Using a longitudinal case study, we draw on one company’s experience with a system implementation that employed a traditional approach during its first phase and then a hybrid, agile-traditional approach in its second phase. By applying an ambidexterity theory lens, we find that the adoption of a hybrid approach allowed the project to continue to exploit the traditional techniques that were working well, abandon techniques that were underperforming, and explore the use of agile techniques in selected areas.     

Empirical studies on the use of social software in global software development – A systematic mapping study

BackgroundIn Global Software Development (GSD), informal communication and knowledge sharing play an important role. Social Software (SoSo) has the potential to support and foster this key responsibility. Research on the use of SoSo in GSD is still at an early stage: although a number of empirical studies on the usage of SoSo are available in related fields, there exists no comprehensive overview of what has been investigated to date across them.ObjectiveThe aim of this review is to map empirical studies on the usage of SoSo in Software Engineering projects and in distributed teams, and to highlight the findings of research works which could prove to be beneficial for GSD researchers and practitioners.MethodA Systematic Mapping Study is conducted using a broad search string that allows identifying a variety of studies which can be beneficial for GSD. Papers have been retrieved through a combination of automatic search and snowballing, hence a wide quantitative map of the research area is provided. Additionally, text extracts from the studies are qualitatively synthesised to investigate benefits and challenges of the use of SoSo.ResultsSoSo is reported as being chiefly used as a support for collaborative work, fostering awareness, knowledge management and coordination among team members. Contrary to the evident high importance of the social aspects offered by SoSo, socialisation is not the most important usage reported.ConclusionsThis review reports how SoSo is used in GSD and how it is capable of supporting GSD teams. Four emerging themes in global software engineering were identified: the appropriation and development of usage structures; understanding how an ecology of communication channels and tools are used by teams; the role played by SoSo either as a subtext or as an explicit goal; and finally, the surprising low percentage of observational studies.     

Perceived causes of software project failures – An analysis of their relationships

ContextSoftware project failures are common. Even though the reasons for failures have been widely studied, the analysis of their causal relationships is lacking. This creates an illusion that the causes of project failures are unrelated.ObjectiveThe aim of this study is to conduct in-depth analysis of software project failures in four software product companies in order to understand the causes of failures and their relationships. For each failure, we want to understand which causes, so called bridge causes, interconnect different process areas, and which causes were perceived as the most promising targets for process improvement.MethodThe causes of failures were detected by conducting root cause analysis. For each cause, we classified its type, process area, and interconnectedness to other causes. We quantitatively analyzed which type, process area, and interconnectedness categories (bridge, local) were common among the causes selected as the most feasible targets for process improvement activities. Finally, we qualitatively analyzed the bridge causes in order to find common denominators for the causal relationships interconnecting the process areas.ResultsFor each failure, our method identified causal relationships diagrams including 130–185 causes each. All four cases were unique, albeit some similarities occurred. On average, 50% of the causes were bridge causes. Lack of cooperation, weak task backlog, and lack of software testing resources were common bridge causes. Bridge causes, and causes related to tasks, people, and methods were common among the causes perceived as the most feasible targets for process improvement. The causes related to the project environment were frequent, but seldom perceived as feasible targets for process improvement.ConclusionPrevention of a software project failure requires a case-specific analysis and controlling causes outside the process area where the failure surfaces. This calls for collaboration between the individuals and managers responsible for different process areas.     

Optimal stopping of multi-project software testing in the context of software cybernetics

Software cybernetics explores the interplay between control theory/engineering and software theory/engineering. The controlled Markov chains (CMC) approach to software testing follows the idea of software cybernetics and treats software testing as a control problem. The software under test serves as a controlled object and the software testing strategy serves as the corresponding controller. The software under test and the software testing strategy make up a closed-loop feedback control system, and the theory of controlled Markov chains can be used to design and optimize software testing strategies in accordance with testing/reliability goals given a priori. In this paper we apply the CMC approach to the optimal stopping problem of multi-project software testing. The problem under consideration assumes that a single stopping action can stop testing of all the software systems under test simultaneously. The theoretical results presented in this paper describe how to test multiple software systems and whe     

“Failures” to be celebrated: an analysis of major pivots of software startups

In the context of software startups, project failure is embraced actively and considered crucial to obtain validated learning that can lead to pivots. A pivot is the strategic change of a business concept, product or the different elements of a business model. A better understanding is needed on different types of pivots and different factors that lead to failures and trigger pivots, for software entrepreneurial teams to make better decisions under chaotic and unpredictable environment. Due to the nascent nature of the topic, the existing research and knowledge on the pivots of software startups are very limited. In this study, we aimed at identifying the major types of pivots that software startups make during their startup processes, and highlighting the factors that fail software projects and trigger pivots. To achieve this, we conducted a case survey study based on the secondary data of the major pivots happened in 49 software startups. 10 pivot types and 14 triggering factors were identified. The findings show that customer need pivot is the most common among all pivot types. Together with customer segment pivot, they are common market related pivots. The major product related pivots are zoom-in and technology pivots. Several new pivot types were identified, including market zoom-in, complete and side project pivots. Our study also demonstrates that negative customer reaction and flawed business model are the most common factors that trigger pivots in software startups. Our study extends the research knowledge on software startup pivot types and pivot triggering factors. Meanwhile it provides practical knowledge to software startups, which they can utilize to guide their effective decisions on pivoting.     

Strengths and barriers behind the successful agile deployment—insights from the three software intensive companies in Finland

The number of success stories being reported concerning agile software development has led to an increase in interest among industries and research communities. The purpose of this paper is to identify strengths and barriers for ‘successful agile deployment’ in the software companies. This knowledge can benefit software companies planning their current strategy for agile deployment. Analysis of 57 developers, architects, project managers, customers, quality managers, and line and product managers in three case companies identifies 71 strengths and 169 barriers of agile deployment. The analysis revealed the importance of management providing the necessary goals and support for agile development. It also indicated the significance of defining a tailored process model and giving developers the freedom to improve their own agile development process continuously during agile deployment. The identified barriers, strengths and recommendations can be used as a checklist for planning and/or monitoring the effectiveness of agile deployment in software companies. By identifying the barriers and strengths of agile deployment, the paper deepens understanding of this highly relevant but relatively under-researched phenomenon and contributes to the literature on agile deployment and software process improvement.     

SoSyM reflections: the 2018 “State of the Journal” report

Software and Systems Modeling -     

An examination of private intermediaries’ roles in software vulnerabilities disclosure

Software vulnerability disclosure has generated much interest and debate. Recently some private intermediaries have entered this market. This paper examines the effects of such private intermediaries on optimal timing of disclosure policy made by public intermediaries and vendors’ reactions. Our analysis of private intermediaries’ role suggests that public intermediary’s optimal disclosure time does not change with private intermediary’s participation. However, a vendor’s patch time increases when the probability of information leakage is low, if not non-existent. In other words, private intermediaries’ service decreases a vendor’s willingness to deliver quick patches. Empirical evidence with 1493 vulnerability observations from CERT/CC and other 326 different vulnerability observations from iDefense provided support for our analytical results.

“Cloning considered harmful” considered harmful: patterns of cloning in software

Literature on the topic of code cloning often asserts that duplicating code within a software system is a bad practice, that it causes harm to the system’s design and should be avoided. However, in our studies, we have found significant evidence that cloning is often used in a variety of ways as a principled engineering tool. For example, one way to evaluate possible new features for a system is to clone the affected subsystems and introduce the new features there, in a kind of sandbox testbed. As features mature and become stable within the experimental subsystems, they can be migrated incrementally into the stable code base; in this way, the risk of introducing instabilities in the stable version is minimized. This paper describes several patterns of cloning that we have observed in our case studies and discusses the advantages and disadvantages associated with using them. We also examine through a case study the frequencies of these clones in two medium-sized open source software systems, the Apache web server and the Gnumeric spreadsheet application. In this study, we found that as many as 71% of the clones could be considered to have a positive impact on the maintainability of the software system.