Software Development Practitioners Research Articles

Application of Privacy Engineering Techniques in Software Development for the National Privacy Commission

The study investigated the implementation of privacy engineering in software development at the National Privacy Commission (NPC) with a specific focus on the Data Breach Notification Management System (DBNMS). Objectives include identifying the factors that contribute to the success or failure of privacy engineering in the NPC's software development context, to provide valuable insights into the integration of privacy measures. This includes the development of actionable guidance for the effective integration of privacy and security in software engineering at the NPC, tailored specifically for NPC engineers and encompassing methodologies for incorporating privacy engineering throughout the software development life cycle. This is to empower NPC software engineers with practical tools and strategies to create a secure and privacy-respecting environment. Qualitative methodology and thematic analysis approach were utilized to assess the effectiveness of privacy engineering techniques. To gather insights, semi structured interviews were conducted with both internal and external stakeholders composed of software developers, data protection officers, and other internal and external users of the DBNMS. Evaluation yielded positive remarks both from internal and external participants. Factors that contributed to the success and failure of privacy engineering techniques in software development include rapid evolution of technology, lack of funds, and stakeholder engagement, among others. Overall, the findings are expected to contribute to the broader discourse on privacy engineering and have implications for policymakers, software development practitioners, and organizations looking to enhance their privacy practices in the digital age.

Metaheuristic-based cost-effective predictive modeling for DevOps project success

Over the decade, DevOps practices have gained popularity within software development organizations for managing the dynamic behavior of system development. Implementing DevOps introduces risks and challenges that increase the difficulties in software development activities, which consequently leads to project failures. This study presents a probability-based predictive model to estimate the success or failure of DevOps projects based on the 13 most significant features identified from literature and data gathered from the DevOps practitioners using a survey questionnaire. The Naïve Bayes Classifier and Logistic Regression (LR) models allied with Grey Wolf Optimization (GWO) have been used to measure the efficiency with the cost of implementing DevOps practices. The results of the study highlighted that NBC with GWO increased the success probability from 0.4954 to 0.9971, with the cost rising from 0.2577 to 0.5000. Similarly, LR with GWO also presented an increase in success probability from 0.2880 to 0.9839, along with an increase in cost from 0.2423 to 0.3558. In conclusion, the developed prediction model based on identified features could help DevOps software development practitioners to implement DevOps projects cost-effectively and successfully.

Why don’t we trace? A study on the barriers to software traceability in practice

Researchers have proposed numerous tools, methods, and techniques for establishing and maintaining software traceability. Despite its acknowledged importance, researchers argue that traceability is still “a sought-after, yet often elusive quality in software-intensive systems”. We have little evidence regarding how creating, managing, and using traceability links vary depending on factors such as organizational contexts, software development practices, and project types. We conduct an empirical study where software development practitioners express their perception regarding the value of software traceability. Via an online survey, 55 participants provided information related to their current traceability practices and needs. Furthermore, we interviewed 14 practitioners to gain a more in-depth understanding. Our study investigates the effect of two independent variables: the software development paradigm and the type of developed software system. Among the several identified findings, our analysis reveals that, although the traceability costs are an inhibitor for adopting more mature traceability practices, the respondents believe that the expected benefits still outweigh envisioned costs. Traceability is mainly performed manually: not only are automated trace retrieval tools scarce, but their offered automation is not expected to replace human involvement.

Agile software development and software practitioners’ productivity amidst the COVID-19 pandemic: a narrative review

PurposeAs the novel coronavirus 2019 (COVID-19) impacts the world, software practitioners are collaboratively working remotely from home. The pandemic has disrupted software practitioners’ productivity forcing changes to agile methodology adopted by software practitioners in software organizations. Therefore, this study aims to provide implication on the issues and recommendations for improving software practitioners’ productivity and also examine the impact of the COVID-19 pandemic on agile software development.Design/methodology/approachThis paper adopts a narrative literature review to provide early assessment based on secondary data from the literature and available document reports from studies published from 2019 to 2022 to explore software practitioners’ productivity and agile software development during the working from home directive amidst the COVID-19 pandemic. A total of 60 sources which met the inclusion criteria were used to provide preliminary evidence grounded on secondary data from the literature. Descriptive analysis was used to provide qualitative findings from the literature.FindingsFindings from this study present the significance of working from home directive on agile software development and software practitioners’ productivity. More importantly, findings from the secondary data shed light on software practitioners’ productivity adopting agile software development amidst the COVID-19 pandemic. Additionally, the findings present virtual collaborative platforms used by software practitioners, technical and social barriers of agile software development during the pandemic and recommendations for remote agile software development.Originality/valueThis study explores the significance of working from home directive on software practitioners’ productivity during COVID-19 pandemic and further investigates how are software practitioners’ productivity adopting agile software development practices amidst the COVID-19 pandemic. Besides, this study discusses the challenges software practitioners currently face and offers some strategies to bridge the gaps in agile software development to help software practitioners, system developers, software managers and software organizations adapt to the changes caused by the pandemic.

Understanding the perceived relevance of capability measures: A survey of Agile Software Development practitioners

Context:In the light of the swift and iterative nature of Agile Software Development (ASD) practices, establishing deeper insights into capability measurement within the context of team formation is crucial, as the capability of individuals and teams can affect team performance and productivity Although a former Systematic Literature Review (SLR) synthesized the state of the art in relation to capability measurement in ASD – with a focus on selecting individuals to agile teams, and capabilities related to team performance, productivity and success determining to what degree the SLR’s results apply to practice can provide progressive insights to both research and practice. Objective:Our study investigates how agile practitioners perceive the relevance of individual and team level measures for characterizing the capability of an agile team and its members. Here, the emphasis was also on selecting individuals to agile teams, and capabilities associated with effective teams in terms of their performance, productivity and success. Furthermore, to scrutinize variations in practitioners’ perceptions, our study further analyzes perceptions across stratified demographic groups. Method:We undertook a Web-based survey using a questionnaire built based on the capability measures identified from a previously conducted SLR. Results:Our survey responses (60) indicate that 127 individual and 28 team capability measures were considered as relevant by the majority of practitioners. We also identified seven individual and one team capability measure that have not been previously characterized by our SLR. The surveyed practitioners suggested that an agile team member’s responsibility and questioning skills significantly represent the member’s capability. Conclusion:Results from our survey align with our SLR’s findings. Measures associated with social aspects were observed to be dominant compared to technical and innovative aspects. Our results can support agile practitioners in their team composition decisions.

The Four Pillars of Research Software Engineering

Building software that can support the huge growth in data and computation required by modern research needs individuals with increasingly specialist skill sets that take time to develop and maintain. The Research Software Engineering movement, which started in the UK and has been built up over recent years, aims to recognise and support these individuals. Why does research software matter to professional software development practitioners outside the research community? Research software can have great impact on the wider world and recent progress means the area can now be considered as a more realistic option for a professional software development career. In this article we present a structure, along with supporting evidence of real-world activities, that defines four elements that we believe are key to providing comprehensive and sustainable support for Research Software Engineering. We also highlight ways that the wider developer community can learn from, and engage with, these activities.

How Usability Defects Defer from Non-Usability Defects? : A Case Study on Open Source Projects

Usability is one of the software qualities attributes that is subjective and often considered as a less critical defect to be fixed. One of the reasons was due to the vague defect descriptions that could not convince developers about the validity of usability issues. Producing a comprehensive usability defect description can be a challenging task, especially in reporting relevant and important information. Prior research in improving defect report comprehension has often focused on defects in general or studied various aspects of software quality improvement such as triaging defect reports, metrics and predictions, automatic defect detection and fixing. In this paper, we studied 2241 usability and non-usability defects from three open-source projects - Mozilla Thunderbird, Firefox for Android, and Eclipse Platform. We examined the presence of eight defect attributes - steps to reproduce, impact, software context, expected output, actual output, assume cause, solution proposal, and supplementary information, and used various statistical tests to answer the research questions. In general, we found that usability defects are resolved slower than non-usability defects, even for non-usability defect reports that have less information. In terms of defect report content, usability defects often contain output details and software context while non-usability defects are preferably explained using supplementary information, such as stack traces and error logs. Our research findings extend the body of knowledge of software defect reporting, especially in understanding the characteristics of usability defects. The promising results also may be valuable to improve software development practitioners' practice.

Knowledge management in the software industry:how Scrum activities support a knowledge management cycle

Knowledge is the primary asset of the software industry which increases the complexity of the software development activities. Knowledge Management (KM) is an important practice that offers processes namely KM cycles and addressed to knowledge capture, creation, storage, dissemination, sharing, and use. Thereby, understanding different means to consolidate individual’s knowledge within the software industry is relevant to software development practitioners and researchers. Therefore, this article discusses how Scrum activities support KM cycle to convert the individual’s knowledge into common knowledge within software development teams. Our analysis points out that KM cycle combined with Scrum practices is a potential tool to disseminate individual knowledge across software development team members.

Perceived importance of agile requirements engineering practices – A survey

Context:Requirements Engineering (RE) is one of the key processes in software development. Since Agile software development advocates continuous improvement, the question arises which Agile RE practices are the most essential and shall be adopted/improved at first? Objective:Investigate and rank the Agile RE practices based on how practitioners perceive their importance for a software project.Method:We conducted a survey asking 136 Agile software development practitioners how they perceive the importance of the 31 Agile RE practices that we had identified in a literature study. We used a ranking method based on the PROMETHEE family methods to create the ranking of relative importance of the practices.Results:The opinions of respondents from a wide range of countries around the globe allowed us to determine the perceived importance of the Agile RE practices and create a seven-tier ranking of the practices. Moreover, the analysis concerning demographic data let us identify some relationships between the experience of the respondents and their view on the importance of the Agile RE practices.Conclusions:Our findings suggest the most critical Agile RE practices are those supporting iterative development with emergent requirements and short feedback loop. Moreover, in many cases, the perceived importance of practices seems to depend on the context of the project (e.g., methodology, domain). We also learned that the popularity of the practices is highly correlated with their perceived importance.

An Early Phase Software Project Risk Assessment Support Method for Emergent Software Organizations

Risk identification and assessment are amongst critical activities in software project management. However, identifying and assessing risks and uncertainties is a challenging process especially for emergent software organizations that lack resources. The research aims to introduce a method and a prototype tool to assist software development practitioners and teams with risk assessment processes. We have identified and put forward software project related risks from the literature. Then by conducting a survey to software practitioners of small organizations, we collected probability and impact of each risk factor opinions of 86 practitioners based on past projects. We developed a risk assessment method and a prototype tool initially based on data that accumulates further data as the tool. Along with a risk prioritisation and risk matrix, the method utilises fuzzy logic to provide the practitioners with predicted scores for potential failure types and aggregated risk score for the project. In order to validate the usability of the method and the tool, we have conducted a case study for the project risk assessment in a small software organization. The introduced method is partially successful at prediction of risks and estimating the probability of predefined failure modes.

Developing a Practical Reactive Synthesis Tool: Experience and Lessons Learned

We summarise our experience developing and using Termite, the first reactive synthesis tool intended for use by software development practitioners. We identify the main barriers to making reactive synthesis accessible to software developers and describe the key features of Termite designed to overcome these barriers, including an imperative C-like specification language, an interactive source-level debugger, and a user-guided code generator. Based on our experience applying Termite to synthesising real-world reactive software, we identify several caveats of the practical use of the reactive synthesis technology. We hope that these findings will help define the agenda for future research on practical reactive synthesis.

High Perceived-Value Requirements Engineering Practices for Outsourced Software Projects

This paper identifies high perceived-value requirements engineering (RE) practices specifically for outsourced software development projects. This is part of a study that aims to develop a framework for critical requirements engineering (RE) practices for outsourced software development projects. We used a survey questionnaire as the primary approach to collect data from 193 software development practitioners from 62 companies in Malaysia. The practitioners were asked to identify which RE practices, out of the 66 practices of Sommerville’s framework, are considered critical for outsourced projects. Specifically, the practitioners were asked to assess and categorize the practices into four categories: high, medium, low and zero value. Only two RE practices were assigned a ‘high value’ by the practitioners and another 26 practices were assigned a ‘medium’ value. The findings show that there is an increased awareness of the importance of RE practices among Malaysian practitioners because only a very low percentage of the respondents selected most of the practices as zeroor low-value practices. Secondly, all the 28 practices ranked as ‘high’ and ‘medium’ value practices are critical and should be given high emphasis in the outsourced projects. Moreover, due to the many more specific characteristics of outsourced projects, the study also implies that there is an urgent need to identify other RE practices or other related software engineering practices that are critical for outsourced projects but that have not been captured within Sommerville’s framework.

A comparison analysis of environmental factors affecting software reliability

Fifteen years ago, Zhang and Pham launched a survey to investigate the impact of software development environmental factors (EFs) on software reliability assessment. Software development has gone through substantial changes during the past fifteen years. How different the environmental factors have become? This paper aims to revisit the 32 environmental factors and analyze their impact on software development and reliability based on a current survey to software development practitioners. The participants of this study come from 20 various organizations and they hold different positions and work on different application areas. Statistical analysis method, such as principle component analysis, relative weighted method, Tukey method, backward elimination, and correlation analysis are applied to analyze these factors. We compare the findings in the two studies and list the most significant factors based on the general ranking and the principle components. The environmental factors in each development phase are also studied. Recommendations such as time allocation during software development process are also made.

Why Don't Farmers Use Cell Phones to Access Market Prices? Technology Affordances and Barriers to Market Information Services Adoption in Rural Kenya

Providing smallholder farmers with agricultural information could improve economic development, by helping them to grow more crops, which they could then sell for more money. Widespread mobile phone ownership in Africa means that, for the first time, there is a realistic opportunity to deliver pertinent information to remote farmers throughout the continent. Efforts to harness the potential of mobile phones include the development of agricultural market information services (MIS) – applications that send farmers crop pricing information via short message service or SMS. These services promote economic development among some farmers in the developing world, but not yet in rural Kenya. To understand what factors impede the adoption of these services, we qualitatively studied Kenyan farmers’ mobile phone usage patterns and their interactions with MFarm, a commercially available MIS. Using affordance theory to guide our analysis, we discovered a mismatch between the design of MIS and smallholder farmers’ perceptions of their mobile phones’ communication capabilities. We use these findings to motivate a design agenda that encourages software developers and development practitioners to adopt an ecological perspective when creating mobile applications for sub-Saharan Africa's rural farmers. Strategies for implementing this approach include reconsidering the design of mobile phones, and developing innovative educational interventions.

New approaches to usability evaluation in software development: Barefoot and crowdsourcing

Usability evaluations provide software development teams with insights on the degree to which software applications enable users to achieve their goals, how fast these goals can be achieved, how easy an application is to learn and how satisfactory it is in use. Although such evaluations are crucial in the process of developing software systems with a high level of usability, their use is still limited in small and medium-sized software development companies. Many of these companies are e.g. unable to allocate the resources that are needed to conduct a full-fledged usability evaluation in accordance with a conventional approach.This paper presents and assesses two new approaches to overcome usability evaluation obstacles: a barefoot approach where software development practitioners are trained to drive usability evaluations; and a crowdsourcing approach where end users are given minimalist training to enable them to drive usability evaluations. We have evaluated how these approaches can reduce obstacles related to limited understanding, resistance and resource constraints. We found that these methods are complementary and highly relevant for software companies experiencing these obstacles. The barefoot approach is particularly suitable for reducing obstacles related to limited understanding and resistance while the crowdsourcing approach is cost-effective.

Barefoot usability evaluations

Usability evaluations provide software development teams with insights on the degree to which a software application enables a user to achieve his/her goals, how fast these goals can be achieved, how easy it is to learn and how satisfactory it is in use. Although usability evaluations are crucial in the process of developing software systems with a high level of usability, their use is still limited in the context of small software development companies. Several approaches have been proposed to support software development practitioners (SWPs) in conducting usability evaluations and this paper presents two in-depth empirical studies of supporting SWPs by training them to become barefoot usability evaluators. Findings show that the SWPs after 30 hours of training obtained considerable abilities in identifying usability problems and that this approach revealed a high level of downstream utility. Results also show that the SWPs created relaxed conditions for the test users when acting as test monitors but experienced problems with making users think aloud. Considering the quality of problem descriptions, we found that the SWPs were better at providing clear and precise problem descriptions than at describing the impact, cause, user actions and providing data support for observations.

Expectations of Software Development Practitioners for Non-Technical Clients

Expectations of Software Development Practitioners for Non-Technical Clients

When intuition and logic clash: The case of the object-oriented paradigm

This paper presents difficulties illustrated by software development practitioners with regard to the use and understanding of concepts and principles of the object-oriented paradigm. In order to understand these difficulties and the sources from which they stem, a theoretical framework borrowed from cognitive psychology, called the dual-process theory, was used. The empirical findings, collected using tools based on the qualitative research approach and analyzed through the lens of the dual-process theory, suggest that a tension between intuitive and logical thinking modes may lead to simple mistakes software engineers exhibit when practicing object-oriented analysis and design (OOA/D). Examining the understanding of OOA/D from this perspective helps explain some of the previously documented, as well as some newly identified difficulties in learning and practicing OOA/D, as well as guide the design of future quantitative experiments to understand how prevalent these phenomena are.

Overview and Guidance on Agile Development in Large Organizations

A continual debate surrounds the effectiveness of agile software development practices. Some organizations adopt agile practices to become more competitive, improve processes, and reduce costs. Other organizations are skeptical about whether agile development is beneficial. Large organizations face an additional challenge in integrating agile practices with existing standards and business processes. To examine the effects of agile development practices in large organizations, we review and integrate scientific literature and theory on agile software development. We further organize our theory and observations into a framework with guidelines for large organizations considering agile methodologies. Based on this framework, we present recommendations that suggest ways large organizations with established processes can successfully implement agile practices. Our analysis of the literature and theory provides new insight for researchers of agile software development and assists practitioners in determining how to adopt agile development in their organizations

Users' Frustration and HCI in the Software Development Life Cycle

Users’ frustration on the software used will affect the productivity. In addition, the ignorance of users’ involvement in the system development methodology will cause problems to the users later on. In the human-computer interaction (HCI) literature, it has been recommended that user’s involvement and HCI consideration in the software development life cycle (SDLC) as an important mechanism for a successful system implementation. However, it is still unclear to what extend do the users’ involvement and HCI consideration have been adopted by software development practitioners. This paper reports on the results of a survey on the importance of HCI in SDLC from the practitioners’ perspective. The survey involves thirty two (32) software designers. The objectives of the study are to identify the state of users’ involvement in SDLC and to identify the HCI elements that have been addressed. Results show that many of the practitioners have involved the users in SDLC, but majority only during the requirement analysis phase. The findings have also revealed that HCI elements on functionality are well addressed. However, the non-functionality elements such as cultural and affective values have not been emphasized by practitioners. The paper concludes with a recommendation to further investigate the users’ awareness on the importance of users’ involvement in the software development.