10,782 research outputs found
Identifying Agile Requirements Engineering Patterns in Industry
Agile Software Development (ASD) is gaining in popularity in today´s business world. Industry is adopting agile methodologies both to accelerate value delivery and to enhance the ability to deal with changing requirements. However, ASD has a great impact on how Requirements Engineering (RE) is carried out in agile environments. The integration of Human-Centered Design (HCD) plays an important role due to the focus on user and stakeholder involvement. To this end, we aim to introduce agile RE patterns as main objective of this paper. On the one hand, we will describe our pattern mining process based on empirical research in literature and industry. On the other hand, we will discuss our results and provide two examples of agile RE patterns. In sum, the pattern mining process identifies 41 agile RE patterns. The accumulated knowledge will be shared by means of a web application.Ministerio de Economía y Competitividad TIN2013-46928-C3-3-RMinisterio de Economía y Competitividad TIN2016-76956-C3-2-RMinisterio de Economía y Competitividad TIN2015-71938-RED
Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle
Many practitioners and academics believe in a delayed issue effect (DIE);
i.e. the longer an issue lingers in the system, the more effort it requires to
resolve. This belief is often used to justify major investments in new
development processes that promise to retire more issues sooner.
This paper tests for the delayed issue effect in 171 software projects
conducted around the world in the period from 2006--2014. To the best of our
knowledge, this is the largest study yet published on this effect. We found no
evidence for the delayed issue effect; i.e. the effort to resolve issues in a
later phase was not consistently or substantially greater than when issues were
resolved soon after their introduction.
This paper documents the above study and explores reasons for this mismatch
between this common rule of thumb and empirical data. In summary, DIE is not
some constant across all projects. Rather, DIE might be an historical relic
that occurs intermittently only in certain kinds of projects. This is a
significant result since it predicts that new development processes that
promise to faster retire more issues will not have a guaranteed return on
investment (depending on the context where applied), and that a long-held truth
in software engineering should not be considered a global truism.Comment: 31 pages. Accepted with minor revisions to Journal of Empirical
Software Engineering. Keywords: software economics, phase delay, cost to fi
What influences the speed of prototyping? An empirical investigation of twenty software startups
It is essential for startups to quickly experiment business ideas by building
tangible prototypes and collecting user feedback on them. As prototyping is an
inevitable part of learning for early stage software startups, how fast
startups can learn depends on how fast they can prototype. Despite of the
importance, there is a lack of research about prototyping in software startups.
In this study, we aimed at understanding what are factors influencing different
types of prototyping activities. We conducted a multiple case study on twenty
European software startups. The results are two folds, firstly we propose a
prototype-centric learning model in early stage software startups. Secondly, we
identify factors occur as barriers but also facilitators for prototyping in
early stage software startups. The factors are grouped into (1) artifacts, (2)
team competence, (3) collaboration, (4) customer and (5) process dimensions. To
speed up a startups progress at the early stage, it is important to incorporate
the learning objective into a well-defined collaborative approach of
prototypingComment: This is the author's version of the work. Copyright owner's version
can be accessed at doi.org/10.1007/978-3-319-57633-6_2, XP2017, Cologne,
German
Scrum2Kanban: Integrating Kanban and Scrum in a University Software Engineering Capstone Course
Using university capstone courses to teach agile software development
methodologies has become commonplace, as agile methods have gained support in
professional software development. This usually means students are introduced
to and work with the currently most popular agile methodology: Scrum. However,
as the agile methods employed in the industry change and are adapted to
different contexts, university courses must follow suit. A prime example of
this is the Kanban method, which has recently gathered attention in the
industry. In this paper, we describe a capstone course design, which adds the
hands-on learning of the lean principles advocated by Kanban into a capstone
project run with Scrum. This both ensures that students are aware of recent
process frameworks and ideas as well as gain a more thorough overview of how
agile methods can be employed in practice. We describe the details of the
course and analyze the participating students' perceptions as well as our
observations. We analyze the development artifacts, created by students during
the course in respect to the two different development methodologies. We
further present a summary of the lessons learned as well as recommendations for
future similar courses. The survey conducted at the end of the course revealed
an overwhelmingly positive attitude of students towards the integration of
Kanban into the course
Boundary Objects and their Use in Agile Systems Engineering
Agile methods are increasingly introduced in automotive companies in the
attempt to become more efficient and flexible in the system development. The
adoption of agile practices influences communication between stakeholders, but
also makes companies rethink the management of artifacts and documentation like
requirements, safety compliance documents, and architecture models.
Practitioners aim to reduce irrelevant documentation, but face a lack of
guidance to determine what artifacts are needed and how they should be managed.
This paper presents artifacts, challenges, guidelines, and practices for the
continuous management of systems engineering artifacts in automotive based on a
theoretical and empirical understanding of the topic. In collaboration with 53
practitioners from six automotive companies, we conducted a design-science
study involving interviews, a questionnaire, focus groups, and practical data
analysis of a systems engineering tool. The guidelines suggest the distinction
between artifacts that are shared among different actors in a company (boundary
objects) and those that are used within a team (locally relevant artifacts). We
propose an analysis approach to identify boundary objects and three practices
to manage systems engineering artifacts in industry
An Empirical Study on Decision making for Quality Requirements
[Context] Quality requirements are important for product success yet often
handled poorly. The problems with scope decision lead to delayed handling and
an unbalanced scope. [Objective] This study characterizes the scope decision
process to understand influencing factors and properties affecting the scope
decision of quality requirements. [Method] We studied one company's scope
decision process over a period of five years. We analyzed the decisions
artifacts and interviewed experienced engineers involved in the scope decision
process. [Results] Features addressing quality aspects explicitly are a minor
part (4.41%) of all features handled. The phase of the product line seems to
influence the prevalence and acceptance rate of quality features. Lastly,
relying on external stakeholders and upfront analysis seems to lead to long
lead-times and an insufficient quality requirements scope. [Conclusions] There
is a need to make quality mode explicit in the scope decision process. We
propose a scope decision process at a strategic level and a tactical level. The
former to address long-term planning and the latter to cater for a speedy
process. Furthermore, we believe it is key to balance the stakeholder input
with feedback from usage and market in a more direct way than through a long
plan-driven process
Measuring Software Process: A Systematic Mapping Study
Context: Measurement is essential to reach predictable performance and high capability processes. It provides
support for better understanding, evaluation, management, and control of the development process
and project, as well as the resulting product. It also enables organizations to improve and predict its process’s
performance, which places organizations in better positions to make appropriate decisions. Objective:
This study aims to understand the measurement of the software development process, to identify studies,
create a classification scheme based on the identified studies, and then to map such studies into the scheme
to answer the research questions. Method: Systematic mapping is the selected research methodology for this
study. Results: A total of 462 studies are included and classified into four topics with respect to their focus
and into three groups based on the publishing date. Five abstractions and 64 attributes were identified,
25 methods/models and 17 contexts were distinguished. Conclusion: capability and performance were the
most measured process attributes, while effort and performance were the most measured project attributes.
Goal Question Metric and Capability Maturity Model Integration were the main methods and models used
in the studies, whereas agile/lean development and small/medium-size enterprise were the most frequently
identified research contexts.Ministerio de Economía y Competitividad TIN2013-46928-C3-3-RMinisterio de Economía y Competitividad TIN2016-76956-C3-2- RMinisterio de Economía y Competitividad TIN2015-71938-RED
DevOps and software quality : a systematic mapping
Quality pressure is one of the factors affecting processes for software development in its various stages. DevOps is one of the proposed solutions to such pressure. The primary focus of DevOps is to increase the deployment speed, frequency and quality. DevOps is a mixture of different developments and operations to its multitudinous ramifications in software development industries, DevOps have attracted the interest of many researchers. There are considerable literature surveys on this critical innovation in software development, yet, little attention has been given to DevOps impact on software quality. This research is aimed at analyzing the implications of DevOps features on software quality. DevOps can also be referred to a change in organization cultures aimed at removal of gaps between the development and operations of an organization. The adoption of DevOps in an organization provides many benefits including quality but also brings challenges to an organization. This study presents systematic mapping of the impact of DevOps on software quality. The results of this study provide a better understanding of DevOps on software quality for both professionals and researchers working in this area. The study shows research was mainly focused in automation, culture, continuous delivery, fast feedback of DevOps. There is need of further research in many areas of DevOps (for instance: measurement, development of metrics of different stages to assess its performance, culture, practices toward ensuring quality assurance, and quality factors such as usability, efficiency, software maintainability and portability). Keywords: DevOps, development, operations, software, software quality, automation, measurement, systematic mappingpublishedVersio
- …