Searcharxiv⌕ Search

arXiv subjects

Rashina Hoda

Publications and source records attributed to Rashina Hoda.

At least 55 records · Page 3Linked to original sources

The Impact of Personality on Requirements Engineering Activities: A Mixed-Methods Study

Context: Requirements engineering (RE) is an important part of Software Engineering (SE), consisting of various human-centric activities that require the frequent collaboration of a variety of roles. Prior research has shown that personality is one such human aspect that has a huge impact on the success of a software project. However, a limited number of empirical studies exist focusing on the impact of personality on RE activities. Objective: The objective of this study is to explore and identify the impact of personality on RE activities, provide a better understanding of these impacts, and provide guidance on how to better handle these impacts in RE. Method: We used a mixed-methods approach, including a personality test-based survey (50 participants) and an in-depth interview study (15 participants) with software practitioners from around the world involved in RE activities. Results: Through personality test analysis, we found a majority of the practitioners have a high score on agreeableness and conscientiousness traits and an average score on extraversion and neuroticism traits. Through analysis of the interviews, we found a range of impacts related to the personality traits of software practitioners, their team members, and external stakeholders. These impacts can be positive or negative, depending on the RE activities, the overall software development process, and the people involved in these activities. Moreover, we found a set of strategies that can be applied to mitigate the negative impact of personality on RE activities. Conclusion: Our identified impacts of personality on RE activities and mitigation strategies serve to provide guidance to software practitioners on handling such possible personality impacts on RE activities and for researchers to investigate these impacts in greater depth in future.

cs.SE↗

Ethics in the Age of AI: An Analysis of AI Practitioners' Awareness and Challenges

Ethics in AI has become a debated topic of public and expert discourse in recent years. But what do people who build AI - AI practitioners - have to say about their understanding of AI ethics and the challenges associated with incorporating it in the AI-based systems they develop? Understanding AI practitioners' views on AI ethics is important as they are the ones closest to the AI systems and can bring about changes and improvements. We conducted a survey aimed at understanding AI practitioners' awareness of AI ethics and their challenges in incorporating ethics. Based on 100 AI practitioners' responses, our findings indicate that majority of AI practitioners had a reasonable familiarity with the concept of AI ethics, primarily due to workplace rules and policies. Privacy protection and security was the ethical principle that majority of them were aware of. Formal education/training was considered somewhat helpful in preparing practitioners to incorporate AI ethics. The challenges that AI practitioners faced in the development of ethical AI-based systems included (i) general challenges, (ii) technology-related challenges and (iii) human-related challenges. We also identified areas needing further investigation and provided recommendations to assist AI practitioners and companies in incorporating ethics into AI development.

cs.CY↗

Empathy Models and Software Engineering -- A Preliminary Analysis and Taxonomy

Empathy is widely used in many disciplines such as philosophy, sociology, psychology, health care. Ability to empathise with software end-users seems to be a vital skill software developers should possess. This is because engineering successful software systems involves not only interacting effectively with users but also understanding their true needs. Empathy has the potential to address this situation. Empathy is a predominant human aspect that can be used to comprehend decisions, feelings, emotions and actions of users. However, to date empathy has been under-researched in software engineering (SE) context. In this position paper, we present our exploration of key empathy models from different disciplines and our analysis of their adequacy for application in SE. While there is no evidence for empathy models that are readily applicable to SE, we believe these models can be adapted and applied in SE context with the aim of assisting software engineers to increase their empathy for diverse end-user needs. We present a preliminary taxonomy of empathy by carefully considering the most popular empathy models from different disciplines. We encourage future research on empathy in SE as we believe it is an important human aspect that can significantly influence the relationship between developers and end-users.

cs.SE↗

Dealing with Data Challenges when Delivering Data-Intensive Software Solutions

The predicted increase in demand for data-intensive solution development is driving the need for software, data, and domain experts to effectively collaborate in multi-disciplinary data-intensive software teams (MDSTs). We conducted a socio-technical grounded theory study through interviews with 24 practitioners in MDSTs to better understand the challenges these teams face when delivering data-intensive software solutions. The interviews provided perspectives across different types of roles including domain, data and software experts, and covered different organisational levels from team members, team managers to executive leaders. We found that the key concern for these teams is dealing with data-related challenges. In this paper, we present the theory of dealing with data challenges that explains the challenges faced by MDSTs including gaining access to data, aligning data, understanding data, and resolving data quality issues; the context in and condition under which these challenges occur, the causes that lead to the challenges, and the related consequences such as having to conduct remediation activities, inability to achieve expected outcomes and lack of trust in the delivered solutions. We also identified contingencies or strategies applied to address the challenges including high-level strategic approaches such as implementing data governance, implementing new tools and techniques such as data quality visualisation and monitoring tools, as well as building stronger teams by focusing on people dynamics, communication skill development and cross-skilling. Our findings have direct implications for practitioners and researchers to better understand the landscape of data challenges and how to deal with them.

cs.SE↗

The Role of Emotional Intelligence in Handling Requirements Changes in Software Engineering

Background: Requirements changes (RCs) are inevitable in Software Engineering. Research shows that emotional intelligence (EI) should be used alongside agility and cognitive intelligence during RC handling. Objective: We wanted to study the role of EI in-depth during RC handling. Method: We conducted a socio-technical grounded theory study with eighteen software practitioners from Australia, New Zealand, Singapore, and Sri Lanka. Findings: We found causal condition (software practitioners handling RCs), intervening condition (mode of work), causes (being aware of own emotions, being aware of others' emotions), direct consequences (regulating own emotions, managing relationships), extended consequences (sustaining productivity, setting and sustaining team goals), and contingencies: strategies (open and regular communication, tracking commitments and issues, and ten other strategies) of using EI during RC handling. We also found the covariances where strategies co-vary with the causes and direct consequences, and ease/ difficulty in executing strategies co-vary with the intervening condition. Conclusion: Open and regular communication is key to EI during RC handling. To the best of our knowledge, the framework we present in this paper is the first theoretical framework on EI in Software Engineering research. We provide recommendations including a problem-solution chart in the form of causes, direct consequences, and mode of work against the contingencies: strategies for software practitioners to consider during RC handling, and future directions of research.

cs.SE↗

The Influence of Human Aspects on Requirements Engineering-related Activities: Software Practitioners Perspective

Requirements Engineering (RE)-related activities require high collaboration between various roles in software engineering (SE), such as requirements engineers, stakeholders, developers, etc. Their demographics, views, understanding of technologies, working styles, communication and collaboration capabilities make RE highly human dependent. Identifying how "human aspects" such as motivation, domain knowledge, communication skills, personality, emotions, culture, etc. might impact RE-related activities would help us improve the RE and SE in general. This study aims to better understand current industry perspectives on the influence of human aspects on RE-related activities, specifically focusing on motivation and personality by targeting software practitioners involved in RE-related activities. Our findings indicate that software practitioners consider motivation, domain knowledge, attitude, communication skills and personality as highly important human aspects when involved in RE-related activities. A set of factors were identified as software practitioners motivational factors when involved in RE-related activities and identified important personality characteristics to have when involved in RE. We also identified factors that made individuals less effective when involved in RE-related activities and obtained an initial idea on measuring individuals performance when involved in RE. The findings from our study suggest various areas needing more investigation, and we summarise a set of key recommendations for further research.

cs.SE↗

Emotion-Centric Requirements Change Handling in Software Engineering

Background: Requirements Changes (RCs) -- the additions/modifications/deletions of functional/non-functional requirements in software products -- are challenging for software practitioners to handle. Handling some changes may significantly impact the emotions of the practitioners. Objective: We wanted to know the key challenges that make RC handling difficult, how these impact the emotions of software practitioners, what influences their RC handling, and how RC handling can be made less emotionally challenging. Method: We followed a mixed-methods approach. We conducted two survey studies, with 40 participants and 201 participants respectively. The presentation of key quantitative data was followed by descriptive statistical analysis, and the qualitative data was analysed using Strauss-Corbinian Grounded Theory, and Socio-Technical Grounded Theory analysis techniques. Findings:We found (1) several key factors that make RC handling an emotional challenge, (2) varying emotions that practitioners feel when it is challenging to handle RCs, (3) how stakeholders, including practitioners themselves, peers, managers and customers, influence the RC handling and how practitioners feel due to the stakeholder influence, and (4) practices that can be used to better handle RCs. Conclusion: Some challenges are technical and some are social which also belong to aspects of agile practice, emotional intelligence, and cognitive intelligence. Therefore, to better handle RCs with positive emotions in socio-technical environments, agility, emotional intelligence, and cognitive intelligence need to cooperate with each other.

cs.SE↗

The Impact of Considering Human Values during Requirements Engineering Activities

Human values, or what people hold important in their life, such as freedom, fairness, and social responsibility, often remain unnoticed and unattended during software development. Ignoring values can lead to values violations in software that can result in financial losses, reputation damage, and widespread social and legal implications. However, embedding human values in software is not only non-trivial but also generally an unclear process. Commencing as early as during the Requirements Engineering (RE) activities promises to ensure fit-for-purpose and quality software products that adhere to human values. But what is the impact of considering human values explicitly during early RE activities? To answer this question, we conducted a scenario-based survey where 56 software practitioners contextualised requirements analysis towards a proposed mobile application for the homeless and suggested values-laden software features accordingly. The suggested features were qualitatively analysed. Results show that explicit considerations of values can help practitioners identify applicable values, associate purpose with the features they develop, think outside-the-box, and build connections between software features and human values. Finally, drawing from the results and experiences of this study, we propose a scenario-based values elicitation process -- a simple four-step takeaway as a practical implication of this study.

cs.SE↗

How Can Human Values Be Addressed in Agile Methods? A Case Study on SAFe

Agile methods are predominantly focused on delivering business values. But can Agile methods be adapted to effectively address and deliver human values such as social justice, privacy, and sustainability in the software they produce? Human values are what an individual or a society considers important in life. Ignoring these human values in software can pose difficulties or risks for all stakeholders (e.g., user dissatisfaction, reputation damage, financial loss). To answer this question, we selected the Scaled Agile Framework (SAFe), one of the most commonly used Agile methods in the industry, and conducted a qualitative case study to identify possible intervention points within SAFe that are the most natural to address and integrate human values in software. We present five high-level empirically-justified sets of interventions in SAFe: artefacts, roles, ceremonies, practices, and culture. We elaborate how some current Agile artefacts (e.g., user story), roles (e.g., product owner), ceremonies (e.g., stand-up meeting), and practices (e.g., business-facing testing) in SAFe can be modified to support the inclusion of human values in software. Further, our study suggests new and exclusive values-based artefacts (e.g., legislative requirement), ceremonies (e.g., values conversation), roles (e.g., values champion), and cultural practices (e.g., induction and hiring) to be introduced in SAFe for this purpose. Guided by our findings, we argue that existing Agile methods can account for human values in software delivery with some evolutionary adaptations.

cs.SE↗

The Role of the Scrum Master in an Industry based University Course

Background: Scrum is the most commonly used agile software development method, and the role of the Scrum Master (SM) in a Scrum environment is vital. Therefore, through an industry based university course for final year undergraduate and masters students, we aimed to give students both theoretical and practical understanding of the role of SM via hands-on experience on playing the role in real-world Scrum contexts. Method: We asked them (92 students) to share their experiences and learnings on the role of SM through reflective surveys and essays. Students participated in reflective surveys (311 survey responses) over 5 weeks in the course, and they submitted essays (92 essays) at the end of the course. We used a mixed-methods approach using Socio-Technical Grounded Theory analysis techniques and trend and regression based statistical analysis to analyse the survey responses and the essays. Findings: We identified the key responsibilities and duties of the SM, common challenges faced by the SM and the team due to the role of the SM, root causes of the challenges, strategies used by the SM and the team to overcome the challenges, and the overall experience of the students. Based on the results, we present recommendations for educators.

cs.SE↗

The Effects of Human Aspects on the Requirements Engineering Process: A Systematic Literature Review

Requirements Engineering (RE) requires the collaboration of various roles in SE, such as requirements engineers, stakeholders and other developers, and it is thus a highly human dependent process in software engineering (SE). Identifying how human aspects such as personality, motivation, emotions, communication, gender, culture and geographic distribution might impact RE would assist us in better supporting successful RE. The main objective of this paper is to systematically review primary studies that have investigated the effects of various human aspects on RE. A systematic literature review (SLR) was conducted and identified 474 initial primary research studies. These were eventually filtered down to 74 relevant, high-quality primary studies. Among the studies, the effects of communication have been considered in many RE studies. Other human aspects such as personality, motivation and gender have mainly been investigated to date related to SE studies including RE as one phase. Findings show that studying more than one human aspect together is beneficial, as this reveals relationships between various human aspects and how they together impact the RE process. However, the majority of these studied combinations of human aspects are unique. From 56.8% of studies that identified the effects of human aspects on RE, 40.5% identified the positive impact, 30.9% negative, 26.2% identified both impacts whereas 2.3% mentioned that there was no impact. This implies that a variety of human aspects positively or negatively affects the RE process and a well-defined theoretical analysis on the effects of different human aspects on RE remains to be defined and practically evaluated. Findings of this SLR help researchers who are investigating the impact of various human aspects on RE by identifying well-studied research areas, and highlight new areas that should be focused on in future research.

cs.SE↗

The Emotional Roller Coaster of Responding to Requirements Changes in Software Engineering

Background: A preliminary study we conducted showed that software practitioners respond to requirements changes(RCs) with different emotions, and that their emotions vary at stages of the RC handling life cycle, such as receiving, developing, and delivering RCs. Objective: We wanted to study more comprehensively how practitioners emotionally respond to RCs. Method: We conducted a world-wide survey with the participation of 201 software practitioners. In our survey, we used the Job-related Affective Well-being Scale (JAWS) and open-ended questions to capture participants emotions when handling RCs in their work and query about the different circumstances when they feel these emotions. We used a combined approach of statistical analysis, JAWS, and Socio-Technical Grounded Theory (STGT) for Data Analysis to analyse our survey data. Findings: We identified (1) emotional responses to RCs, i.e., the most common emotions felt by practitioners when handling RCs; (2) different stimuli -- such as the RC, the practitioner, team, manager, customer -- that trigger these emotions through their own different characteristics; (3)emotion dynamics, i.e., the changes in emotions during the project and RC handling life cycles; (4) distinct events where particular emotions are triggered:project milestones, and RC stages; (5) and time related matters that regulate the emotion dynamics. Conclusion: Practitioners are not pleased with receiving RCs all the time. Last minute RCs introduced closer to a deadline especially violate emotional well-being of practitioners. We present some practical recommendations for practitioners to follow, including a dual-purpose emotion-centric decision guide to help decide when to introduce or accept an RC, and some future key research directions.

cs.SE↗

Socio-Technical Grounded Theory for Software Engineering

Grounded Theory (GT), a sociological research method designed to study social phenomena, is increasingly being used to investigate the human and social aspects of software engineering (SE). However, being written by and for sociologists, GT is often challenging for a majority of SE researchers to understand and apply. Additionally, SE researchers attempting ad hoc adaptations of traditional GT guidelines for modern socio-technical (ST) contexts often struggle in the absence of clear and relevant guidelines to do so, resulting in poor quality studies. To overcome these research community challenges and leverage modern research opportunities, this paper presents Socio-Technical Grounded Theory (STGT) designed to ease application and achieve quality outcomes. It defines what exactly is meant by an ST research context and presents the STGT guidelines that expand GT's philosophical foundations, provide increased clarity and flexibility in its methodological steps and procedures, define possible scope and contexts of application, encourage frequent reporting of a variety of interim, preliminary, and mature outcomes, and introduce nuanced evaluation guidelines for different outcomes. It is hoped that the SE research community and related ST disciplines such as computer science, data science, artificial intelligence, information systems, human computer/robot/AI interaction, human-centered emerging technologies (and increasingly other disciplines being transformed by rapid digitalisation and AI-based augmentation), will benefit from applying STGT to conduct quality research studies and systematically produce rich findings and mature theories with confidence.

cs.SE↗

What Drives and Sustains Self-Assignment in Agile Teams

Self-assignment, where software developers choose their own tasks, is a common practice in agile teams. However, it is not known why developers select certain tasks. It is important for managers to be aware of these reasons to ensure sustainable self-assignment practices. We investigated developers' preferences while they are choosing tasks for themselves. We collected data from 42 participants working in 25 different software companies. We applied Grounded Theory procedures to study and analyse factors for self-assigning tasks, which we grouped into three categories: task-based, developer-based, and opinion-based. We found that developers have individual preferences and not all factors are important to every developer. Managers share some common and varying perspectives around the identified factors. Most managers want developers to give higher priority to certain factors. Developers often need to balance between task priority and their own individual preferences, and managers facilitate this through a variety of strategies. More risk-averse managers encourage expertise-based self-assignment to ensure tasks are completed quickly. Managers who are risk-balancing encourage developers to choose tasks that provide learning opportunities only when there is little risk of delays or reduced quality. Finally, growth-seeking managers regularly encourage team members to pick tasks outside their comfort zone to encourage growth opportunities. Our findings will help managers to understand what developers consider when self-assigning tasks and help them empower their teams to practice self-assignment in a sustainable manner.

cs.SE↗

Emotimonitor: A Trello Power-Up to Capture Emotions of Agile Teams

In recent years, Agile methods have continued to grow into a popular means of modulating team productivity, even garnering a presence in non-software development related industries. The uptake of Agile methods has been driven by their flexibility, making them more suitable for many teams when compared to traditional approaches. However, an inevitable expectation for an Agile workflow is a higher level of change and uncertainty regarding requirements and tasks, which can ultimately have impacts on team member emotional states. The extent of such emotion impacts has motivated our research into the manner in which emotional states evolve in an Agile setting, along with whether such emotions can be accurately measured. To this end, we have developed Emotimonitor, a Trello power-up designed to capture information on emotions of team members as they relate to their technical tasks through a user-friendly interface. Emotimonitor will better enable team members to express their emotional states through emoji reactions on Trello cards, while also providing team leaders with a dashboard summarising these reactions as visualisations and statistical data. It is extensible and potentially provides an outlet for team members operating in Agile environments to better express their emotional states.

cs.SE↗

Real World Scrum A Grounded Theory of Variations in Practice

Scrum, the most popular agile method and project management framework, is widely reported to be used, adapted, misused, and abused in practice. However, not much is known about how Scrum actually works in practice, and critically, where, when, how and why it diverges from Scrum by the book. Through a Grounded Theory study involving semi-structured interviews of 45 participants from 30 companies and observations of five teams, we present our findings on how Scrum works in practice as compared to how it is presented in its formative books. We identify significant variations in these practices such as work breakdown, estimation, prioritization, assignment, the associated roles and artefacts, and discuss the underlying rationales driving the variations. Critically, we claim that not all variations are process misuse/abuse and propose a nuanced classification approach to understanding variations as standard, necessary, contextual, and clear deviations for successful Scrum use and adaptation

cs.SE↗

Empirical Standards for Software Engineering Research

Empirical Standards are natural-language models of a scientific community's expectations for a specific kind of study (e.g. a questionnaire survey). The ACM SIGSOFT Paper and Peer Review Quality Initiative generated empirical standards for research methods commonly used in software engineering. These living documents, which should be continuously revised to reflect evolving consensus around research best practices, will improve research quality and make peer review more effective, reliable, transparent and fair.

cs.SE↗

A Multi-dimensional Study of Requirements Changes in Agile Software Development Projects

Agile processes are now widely practiced by software engineering (SE) teams, and the agile manifesto claims that agile methods support responding to changes well. However, no study appears to have researched whether this is accurate in reality. Requirements changes (RCs) are inevitable in any software development environment, and we wanted to acquire a holistic picture of how RCs occur and are handled in agile SE teams in practice. We also wanted to know whether responding to changes is the only or a main reason for software teams to use agile in their projects. To do this we conducted a mixed-methods research study which comprised of interviews of 10 agile practitioners from New Zealand and Australia, a literature review, and an in-depth survey with the participation of 40 agile practitioners world-wide. Through this study we identified different types of RCs, their origination including reasons for origination, forms, sources, carriers, and events at which they originate, challenging nature, and finally whether agile helps to respond to changes or not. We also found that agile teams seem to be reluctant to accept RCs, and therefore, they use several mitigation strategies. Additionally, as they accept the RCs, they use a variety of techniques to handle them. Furthermore, we found that agile allowing better response to RCs is only a minor reason for practicing agile. Several more important reasons included being able to deliver the product in a shorter period and increasing team productivity. Practitioners stated this improves the agile team environment and thus are the real motivators for teams to practice agile. Finally, we provide a set of practical recommendations that can be used to better handle RCs effectively in agile software development environments.

cs.SE↗