DOCSLIB.ORG

Traceability in Agile Software Projects

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Traceability in Agile software projects Master of Science Thesis in Software Engineering & Management VUONG HOANG DUC University of Gothenburg Chalmers University of Technology Department of Computer Science and Engineering Göteborg, Sweden, May 2013 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Traceability in Agile software projects VUONG.HOANG DUC VUONG. HOANG DUC, May 2013. Examiner: CHRISTIAN.BERGER University of Gothenburg Chalmers University of Technology Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 ABSTRACT Context: Software applications have been penetrating every corner of our daily life in the past decades. This condition demands high quality software. Traceability activities have been recognized as important factors supporting various activities during the development process of a software system with the aim of improving software quality. Over the past decades, software traceability has been discussed in literature and there are many approaches proposed to achieve traceability. However, these current literature mainly discussed traceability in traditional software development process and very few studies are discussing traceability issues in Agile software process. Objective: This study aims to investigate the important types of traceability, benefits against challenges when conducting traceability in an Agile software project. This paper also aims to identify what mechanisms are used and how they work and help companies to achieve traceability in Agile software projects. Method: This study is conducted by interviewing 12 Agile software companies and reviewing 20 primary papers related to this research topic. Result: Rationale, Contribute and Refinement are three most important types of traceability. Traditional traceability tools such as: excel, product backlog, communication, etc are used together with automated software tools. Automated tools could be commercial tools made or self-developed by companies. Difficulties related to knowledge, experience, cooperation or commitment within the development team seem to be the most challenging. Doing traceability could help the software company gain the customer focus and guarantee or safety for its software system. Keywords: traceability goals/purposes, agile/lean traceability, type of traceability, Agile principles. ACKNOWLEDGEMENT This master thesis would not have been possible without the sincere help and contribution of several people. I would like to take this opportunity to express my gratitude to them. First of all, I would like to express my sincere gratitude to my supervisor Professor Tony Gorschek for providing me with valuable guidance and advice throughout this thesis. Not only did Professor Tony guide every crucial steps of my thesis, but he also provided, supported and suggested other aspects of this paper. I really appreciate his supervision since he provided very detailed instructions, though he was extremely busy. I would also like to give thanks to my former teacher: Dick Stenmark at IT Göteborg department for helping me with the methodology research methods. Moreover, I would like to thank Professor Giuliano Antoniol and Professor Alexander Egyed at Center of Excellence for Software Traceability for their preliminary comments on this research topic. Last but not least, I am deeply grateful to my family and friends for their support, encouragement and always being with me through the challenges that I faced. Contents 1 Introduction 4 1.1 Aims and Objectives . .5 1.2 Research Questions . .5 1.3 Expected Outcomes . .6 1.4 Terminologies . .6 2 Background 7 2.1 Overview of traceability . .7 2.1.1 Definition of traceability . .7 2.1.2 The importance of traceability . .8 2.1.3 Purposes of traceability . .8 2.1.4 Traceability directions . 10 2.1.5 Traceability Mechanisms . 12 2.1.6 Tracing links/relations . 13 2.1.7 Types of tracing links/relations . 14 2.1.8 The traceability map . 15 2.2 Overview of Agile software development . 21 2.2.1 Practices of Agile . 21 2.2.2 The Agile map . 23 2.3 Problems of traceability in Agile development process . 25 3 Related Work 26 4 Research Methodology 28 4.1 Brief description of research methods . 28 4.1.1 Literature Review . 28 4.1.2 Snowball Sampling . 28 4.1.3 Industry interview . 29 4.2 Mapping of research questions and research methodologies . 29 5 Conducting literature review 32 5.1 Motivation for the method selection . 32 5.2 Searching and Identifying literature . 33 5.2.1 Validating quality literature . 34 5.2.2 Locations for quality literature . 34 5.2.3 Keywords search . 35 5.2.4 Snowball sampling search . 36 5.2.5 When to stop searching . 37 5.3 Processing and synthesizing literature . 37 1 5.3.1 Understanding the literature . 37 5.3.2 Comprehending literature . 38 5.3.3 Applying literature . 38 6 Conducting industry interviews 42 6.1 Motivation for the Interview method . 42 6.2 Interview Preparation Plan . 42 6.2.1 Finding interviewees . 42 6.2.2 Developing the interview guide . 43 6.3 Conducting interviews . 44 6.3.1 Asking and motivational probing . 45 6.4 Processing and Extracting interview data . 45 6.4.1 Processing data . 45 6.4.2 Extracting and Gathering data . 46 7 Results and Analysis of this thesis 48 7.1 General information of companies and primary studies . 48 7.1.1 Characteristics of reviewed literature . 48 7.1.2 Interviewed companies . 50 7.2 Research Questions . 59 7.2.1 RQ1: What types of traceability are important for software development in organiza- tions subscribing to being Agile? . 59 7.2.2 RQ2: What mechanisms are used by Agile companies to achieve traceability? . 68 7.2.3 RQ3: What mechanisms work well in Agile development organizations? . 72 7.2.4 RQ4: What challenges exist for realizing traceability in Agile organizations? . 76 7.2.5 RQ5: What benefits exist in realizing traceability in Agile organizations? . 83 8 Validity Threats 89 8.1 Internal validity . 89 8.1.1 Threats of conducting interviews . 89 8.1.2 Threats of reviewing papers . 90 8.2 External validity . 90 8.2.1 Threats to the industry interview . 90 8.2.2 Threats to the literature review . 90 8.3 Construct validity . 90 8.4 Conclusion validity . 90 8.4.1 Threats to the industry interview . 91 8.4.2 Threats to the literature review . 91 9 Conclusion 92 9.1 Research questions revisited . 92 9.2 Future work . 94 10 Reference 95 11 Appendix 103 11.1 The interview package . 103 11.1.1 The interview guide . 103 11.1.2 Three HANDOUT . 107 11.2 Interviewed data by companies . 114 11.2.1 Company A . 114 11.2.2 Company B . 116 2 11.2.3 Company C . 117 11.2.4 Company D . 119 11.2.5 Company E . 122 11.2.6 Company F . 125 11.2.7 Company G . ..
Recommended publications
  • A System Model for Managing Requirement Traceability Matrices Via Statistical Artifact Change Analysis Benjamin J

    A System Model for Managing Requirement Traceability Matrices Via Statistical Artifact Change Analysis Benjamin J

    A System Model for Managing Requirement Traceability Matrices via Statistical Artifact Change Analysis Benjamin J. Deaver and LiGuo Huang, Southern Methodist University, Dallas Introduction and Motivation Requirement Traceability Matrix – Gantt Open Source Software Project The Value of the Requirements Traceability Matrix The system Requirement Traceability Matrix (RTM) is primarily used for ensuring Our initial dataset for evaluation is taken from the Gantt Open Source PROCEDURE Kannenberg et al identify the underlying necessity of the Requirements Traceability Matrix and the underlying effect on that all requirements are fulfilled by the system artifact deliverables and the Software Project (http://www.ganttproject.biz). The initial trace data 1. Identify the taxonomy of change for a given domain (Systems Engineering, project management, process visibility, verification and validation, as well as project maintainability. Over time, the management of change to deliverables with respect to impact on other systems. In has been provided to us by Dr. Alexander Egyed at the Institute for SoS Engineering, Software Engineering). the systems engineering and system of systems (SoS) engineering landscapes, the Systems Engineering and Automation at Johannes Kepler University. Requirements Traceability Matrix provides significant insight in to the internal workings of the relationships between RTM is a tool that is useful at time of creation, but requires constant maintenance in Additional traces of requirements to code for subsequent Gantt versions 2. Identify and classify changes between static versions of the product. requirements and deliverable artifacts. a frequently changing landscape to maintain the original level of validity. The are being created using similar methods to the original collections 3. Generate Requirements Trace Matrixes for each static version of the product dynamic nature of systems and SoS engineering landscapes requires that a RTM be performed by Dr.
  • Navigating the Next Evolution of Application Development Using Distributed Tracing

    Navigating the Next Evolution of Application Development Using Distributed Tracing

    Navigating the Next Evolution of Application Development Using Distributed Tracing Navigating the Next Evolution of Application Development 1 Table of Contents Introduction ...........................................................................................................................................................................................3 How has software been built? Waterfall vs. DevOps ................................................................................. ............................. 4 The next evolution: Microservices ................................................................................................................................................5 What will you need to do differently to capitalizeon modern application development? ..........................................6 Get started with Epsagon on AWS ...............................................................................................................................................8 Case Study: Bastian Solutions .......................................................................................................................................................9 Learn More ..........................................................................................................................................................................................10 Navigating the Next Evolution of Application Development 2 Introduction Building and maintaining a competitive edge often requires you to evolve with your customers’
  • Traceability Establishment and Visualization of Software Artefacts in Devops Practice: a Survey

    Traceability Establishment and Visualization of Software Artefacts in Devops Practice: a Survey

    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 10, No. 7, 2019 Traceability Establishment and Visualization of Software Artefacts in DevOps Practice: A Survey D. A. Meedeniya1, I. D. Rubasinghe2, I. Perera3 Dept. of Computer Science and Engineering, University of Moratuwa, Sri Lanka Abstract—DevOps based software process has become the artefacts in the SDLC [2][3]. There are different forms of popular with the vision of an effective collaboration between the relationships between the homogeneous and heterogeneous development and operations teams that continuously integrates software artefacts. Some artefacts may be highly coupled, and the frequent changes. Traceability manages the artefact some may depend on other artefacts in different degrees, consistency during a software process. This paper explores the unidirectionally or bidirectionally. Thus, software artefacts trace-link creation and visualization between software artefacts, consistency management helps to fine-tune the software existing tool support, quality aspects and the applicability in a process. The incomplete, outdated software artefacts and their DevOps environment. As the novelty of this study, we identify the inconsistencies mislead both the development and maintenance challenges that limit the traceability considerations in DevOps process. Thus, artefact management is essential such that the and suggest research directions. Our methodology consists of changes are accurately propagated to the impacted artefacts concept identification, state-of-practice exploration and analytical review. Despite the existing related work, there is a without creating inconsistencies. Traceability is the potential to lack of tool support for the traceability management between relate artefacts considering their relationships [4][5]; thus, a heterogeneous artefacts in software development with DevOps solution for artefact management.
  • Requirements Traceability Practices Guide

    Requirements Traceability Practices Guide

    CDC UNIFIED PROCESS PRACTICE GUIDE REQUIREMENTS TRACEABILITY Document Purpose The purpose of this document is to provide guidance on the project management practice of Requirements Traceability and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements. In addition, templates relevant to this practice are provided at the end of this guide. Practice Overview Requirements traceability is an activity that is one part of an overarching requirements management practice and extends from requirements definition through to implementation. Requirements tracing is used to ensure that each step of the product’s development process is correct, conforms to the needs of prior and next steps, and conforms to the defined requirements. Requirements tracing is a technique that helps to ensure that the project delivers what stakeholders expect. If applied correctly requirements tracing is a practice that can greatly increase the quality and reliability of a project’s final product while minimizing costly rework resulting from requirements errors. Requirements tracing defines the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through each step of the entire product’s life cycle. This is done by documenting and tracking traceability relationships between requirements. A traceability relationship is a dependency relationship between project and/or product elements. Similar to the way a dynamic project schedule may react to a change in one task, a change to a requirement element may also have a rippling effect on other elements. A well documented traceability relationship clearly defines requirement dependencies and allows for analysis of how changes in requirements affect other requirements and the project as a whole.
  • Systems Engineering Guided Tour

    Systems Engineering Guided Tour

    Systems Engineering Guided Tour Copyright © 1993–2007 Vitech Corporation. All rights reserved. No part of this document may be reproduced in any form, including, but not limited to, photocopying, translating into another language, or storage in a data retrieval system, without prior written consent of Vitech Corporation. Restricted Rights Legend Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7013. Vitech Corporation 2070 Chain Bridge Road, Suite 100 Vienna, Virginia 22182-2536 703.883.2270 FAX: 703.883.1860 Customer Support: [email protected] www.vitechcorp.com CORE® is a registered trademark of Vitech Corporation. Other product names mentioned herein are used for identification purposes only, and may be trademarks of their respective companies. Revised Date: August 2007 ii Table of Contents Creating External Systems ................................ 32 ................... 1 1 Getting Started with CORE Defining the Context Component ...................... 34 The Benefits of CORE ....................................... 1 Adding Detail to the External Systems .............. 35 Installing CORE................................................. 2 Viewing a Physical Hierarchy ............................ 36 Overview of the CORE Product Family ............. 2 Creating Function Elements .............................. 37 Key Concepts .................................................... 3 Establishing
  • Linuxcon North America 2012

    Linuxcon North America 2012

    LinuxCon North America 2012 LTTng 2.0 : Tracing, Analysis and Views for Performance and Debugging. E-mail: [email protected] Mathieu Desnoyers August 29th, 2012 1 > Presenter ● Mathieu Desnoyers ● EfficiOS Inc. ● http://www.efficios.com ● Author/Maintainer of ● LTTng, LTTng-UST, Babeltrace, Userspace RCU Mathieu Desnoyers August 29th, 2012 2 > Content ● Tracing benefits, ● LTTng 2.0 Linux kernel and user-space tracers, ● LTTng 2.0 usage scenarios & viewers, ● New features ready for LTTng 2.1, ● Conclusion Mathieu Desnoyers August 29th, 2012 3 > Benefits of low-impact tracing in a multi-core world ● Understanding interaction between ● Kernel ● Libraries ● Applications ● Virtual Machines ● Debugging ● Performance tuning ● Monitoring Mathieu Desnoyers August 29th, 2012 4 > Tracing use-cases ● Telecom ● Operator, engineer tracing systems concurrently with different instrumentation sets. ● In development and production phases. ● High-availability, high-throughput servers ● Development and production: ensure high performance, low-latency in production. ● Embedded ● System development and production stages. Mathieu Desnoyers August 29th, 2012 5 > LTTng 2.0 ● Rich ecosystem of projects, ● Key characteristics of LTTng 2.0: – Small impact on the traced system, fast, user- oriented features. ● Interfacing with: Common Trace Format (CTF) Interoperability Between Tracing Tools Tracing Well With Others: Integration with the Common Trace Format (CTF), of GDB Tracepoints Into Trace Tools, Mathieu Desnoyers, EfficiOS, Stan Shebs, Mentor Graphics,
  • Managing Project Requirements

    Managing Project Requirements

    MANAGING PROJECT REQUIREMENTS Course Materials The causes of the majority of failed IT projects can be traced to poor definition and understanding of requirements. Changing requirements causes more delays than any other cause. If you want to improve project performance you must improve the way you define and manage requirements. Requirements must be a clear description in a common language. They are the bridge between the customer who will describe, pay for, and use the solution and the technical community who will specify and provide the solution. Requirements must be unique, normalized, linked, complete, consistent, bounded, modifiable, configurable and granular. Participants will cultivate the skills needed to elicit full business information from the right stakeholders and, learn structured techniques to identify and present business requirements clearly and effectively. Table of Contents Lesson 1: Introduction to Requirements Management ......................................................................... 1 Topic 1: Requirements Definition ....................................................................................................... 2 Exercise 1.1 Evaluating Requirements ............................................................................................... 5 Topic 2: The Project Environment ...................................................................................................... 6 Topic 3: Understanding the Project Charter .....................................................................................
  • System Wide Tracing and Profiling in Linux

    System Wide Tracing and Profiling in Linux

    SYSTEM WIDE TRACING AND PROFILING IN LINUX Nadav Amit Agenda • System counters inspection • Profiling with Linux perf tool • Tracing using ftrace Disclaimer • Introductory level presentation • We are not going to cover many tools • We are not going to get deep into the implementation of the tools • I am not an expert on many of the issues Collect Statistics • First step in analyzing the system behavior • Option 1: Resource statistics tools • iostat, vmstat, netstat, ifstat • dstat Examples: dstat --vm --aio • dstat • dstat --udp --tcp --socket • dstat --vm --aio dstat --udp --tcp --socket Watch system behavior online • Option 2: Sample the counter • top • Use –H switch for thread specific • Use ‘f’ to choose additional fields: page faults, last used processor • Use ‘1’ to turn off cumulative mode • iotop • Remember to run as sudoer top Inspect Raw Counters • Option 3: Go to the raw counters • General • /proc/stat • /proc/meminfo • /proc/interrupts • Process specific • /proc/[pid]/statm – process memory • /proc/[pid]/stat – process execution times • /proc/[pid]/status – human readable • Device specific • /sys/block/[dev]/stat • /proc/dev/net • Hardware • smartctl /proc/interrupts /sys/block/[dev]/stat Name units description ---- ----- ----------- read I/Os requests number of read I/Os processed read merges requests number of read I/Os merged with in-queue I/O read sectors sectors number of sectors read read ticks milliseconds total wait time for read requests write I/Os requests number of write I/Os processed write merges requests number
  • Verification and Validation

    Verification and Validation

    Requirements Verification and Validation In4Mtx 113 February 2010 Agenda Definitions of V&V Why do we care? Verification Methods VCRMs Verification Techniques Success Criteria Early Verification Planning in the RE Process What Makes Requirements Verification Difficult 2 Definitions Verification: The process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase. Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. These definitions are taken from : Verifying and validating software requirements and design specifications. Boehm, B W IEEE Software. Vol. 1, no. 1, pp. 75-88. 1984 3 Basically… Verification: "Am I building the product right?" Validation: "Am I building the right product?" 4 Why do we care? Outputs Data/Models In Requirements Database Directly Drives Verifies 5 Remember this process? Inspection Individual Defect evaluation RD planning reviewing at review meetings consolidation Figure 5.1 – Requirements inspection, review, and consolidation Your testers are key stakeholders 6 Verification Methods Industry accepted methods are: Test Analysis Demonstration Inspection S Any guesses to the “S” in T.A.D.I.S? 7 VCRM Verification Cross Reference Matrix Supplemental to the RD This will be required on any RD you’ll ever produce. Guarantee it: 100% Can be combined with the Requirements Traceability Matrix 8 Sample VCRM Req ID Requirement Verification Allocation Success Criteria Method 1 The train doors shall remain D, T Controller SW Once ground speed >= 1mph, closed during all operational train doors lock and remain activities. closed.
  • EPRI TR 107330, "Requirements Compliance Traceability Matrix,"

    EPRI TR 107330, "Requirements Compliance Traceability Matrix,"

    HF Controls HF CONTROLS CORPORATION HFC-6000 Product Line U--Nuclear Qualification Project ERD 111 EPRI TR 107330 REQUIREMENTS COMPLIANCE TRACEABILITY MATRIX RR901-000-10 Rev C Effective Date: 12/14/2009 Author: Ivan Chow Reviewer: Jonathan Taylor Approval: Allen Hsu Copyright© 2009 HF Controls Corporation 1 of 66 ERD i 11 EPRI TR 107330 Requirement Compliance Traceability Matrix Revision History Date Revision Author Changes 2/3/05 A0 J Taylor Draft 3/1/05 A J Taylor Incorporate review comments 11/19/09 B I. Chow Resolved the inconsistencies about undetectable errors and remedial implementations in RR901-000-01 Rev. B and PP901-000-01 Rev. C SCR 2612, CR 2009-0540 12/9/09 C I. Chow Revised and based on new documented information from the qualification summary report and reconstructed requirement documentations. Table of Contents 1.0 Introduction ...................... ............................................................................... 3 2.0 Traceability M atrix ....................................................................................... 3 3.0 Glossary .................................................................................................... 3 3.1 Traceability M atrix Com pliance ................................................................ 3 3.2 .Abbreviations .............................................................................................. 4 4.0 R eferences .................................................................................................... 5 List of Tables Table 1 - EPRI
  • Software Requirements Specification (SRS) Tailoring Standards

    Software Requirements Specification (SRS) Tailoring Standards

    CS 330 Software Engineering Software Requirements Specification (SRS) Tailoring Standards The following description provides the basic document organization, and required information (see the Document Style Guidelines and Standards for information about format). The main thing to remember is that the SRS must contain a Requirements Traceability Matrix (RTM). Each requirement is uniquely identified (using a number) in the body of the document and must be called out in the RTM. Each requirement will use the verb “shall.” Otherwise the statement shall not be considered a requirement. Each item below should be considered required as a major element or section in the SRS. The standard referred to here is IEEE Std. 830-1993. Title Page Abstract1 Frontmatter 1. Introduction (see section 5.1 of the standard for details) 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations 1.4. References 1.5. Overview 2. Overall description (see section 5.2 of the standard for details) 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 3. Specific Requirements (see section 5.3 and/or appendix A of the standard for details) 4. References Appendixes Definitions, Acronyms and Abbreviations Requirements Traceability Matrix Schedule (with a description of milestones and deliverables) Walk-through Check List Coding Standards Special Purpose Items: Description of the external items pictured in context diagram Other Special Purpose Items (e.g. JAVA / C++ API; Screen Shots of a GUI) Index (optional) 1 Include in the abstract a complete overview of the product (purpose, goals, and design constraints) including your chosen design methodology, any exceptions to the stated requirements.
  • Debugging and Profiling with Arm Tools

    Debugging and Profiling with Arm Tools

    Debugging and Profiling with Arm Tools [email protected] • Ryan Hulguin © 2018 Arm Limited • 4/21/2018 Agenda • Introduction to Arm Tools • Remote Client Setup • Debugging with Arm DDT • Other Debugging Tools • Break • Examples with DDT • Lunch • Profiling with Arm MAP • Examples with MAP • Obtaining Support 2 © 2018 Arm Limited Introduction to Arm HPC Tools © 2018 Arm Limited Arm Forge An interoperable toolkit for debugging and profiling • The de-facto standard for HPC development • Available on the vast majority of the Top500 machines in the world • Fully supported by Arm on x86, IBM Power, Nvidia GPUs and Arm v8-A. Commercially supported by Arm • State-of-the art debugging and profiling capabilities • Powerful and in-depth error detection mechanisms (including memory debugging) • Sampling-based profiler to identify and understand bottlenecks Fully Scalable • Available at any scale (from serial to petaflopic applications) Easy to use by everyone • Unique capabilities to simplify remote interactive sessions • Innovative approach to present quintessential information to users Very user-friendly 4 © 2018 Arm Limited Arm Performance Reports Characterize and understand the performance of HPC application runs Gathers a rich set of data • Analyses metrics around CPU, memory, IO, hardware counters, etc. • Possibility for users to add their own metrics Commercially supported by Arm • Build a culture of application performance & efficiency awareness Accurate and astute • Analyses data and reports the information that matters to users insight • Provides simple guidance to help improve workloads’ efficiency • Adds value to typical users’ workflows • Define application behaviour and performance expectations Relevant advice • Integrate outputs to various systems for validation (e.g.