DOCSLIB.ORG

Software Development Risk Management Model- a Goal-Driven Approach

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Development Risk Management Model- a Goal-Driven Approach Software Development Risk Management Model- a goal-driven approach Shareeful Islam Lehrstuhl fur¨ Software & Systems Engineering Institut fur¨ Informatik Technische Universitat¨ Munchen¨ Technische Universitat¨ M ¨unchen Institut f ¨urInformatik Lehrstuhl fur¨ Software & Systems Engineering Software Development Risk Management Model- a goal-driven approach Shareeful Islam Vollstandiger¨ Abdruck der von der Fakultat¨ fur¨ Informatik der Technischen Uni- versitat¨ Munchen¨ zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Hans Michael Gerndt Prfer der Dissertation: 1. Univ.-Prof. Dr. Dr. h.c. Manfred Broy 2. Univ.-Prof. Dr. Martin Bichler Die Dissertation wurde am 11.11.2010 bei der Technischen Universitat¨ Munchen¨ eingereicht und durch die Fakultat¨ fur¨ Informatik am 25.03.2011 angenommen. Abstract Every software project by its inherent nature is unique and contains significant numbers of uncertainties from various perspectives such as time-to-market, bud- get and schedule estimation, product deployment or maintenance. If failing to control these uncertainties, it imposes potential risks not only during the devel- opment phases but also throughout the life cycle of the product. Software risk management is an effective tool to control these risks and contributes to increase the likelihood of project success. Risk management needs to be integrated as early as possible from a holistic perspective into the development. However a compre- hensive risk management practice is not always possible due to resource problems, more emphasize on budget and schedule constraints and difficulties to concretely estimate the benefit of risk management. This thesis proposes a Goal-driven Software Development Risk Management Model (GSRM) that explicitly integrates into the requirements engineering phase. The in- tegration provides an early warning of potential problems so that both preventive and corrective actions can be undertaken to avoid the causes of project failure. The framework is comprised of four layers, i.e., goal, obstacle, assessment and treat- ment, that support the identification, assessment, treatment and documentation of risks in relation to project-specific goals. GSRM is implemented in active on-going software development projects to empirically evaluate its usefulness, particular advantages and limitations in an industrial context. The results show that goal- driven approach is suitable for risk management and risk management is well in- tegrated into requirements engineering phase. It is not always necessary to rank budget and schedule related goals and risk factors at the highest priority for risk management. At the early stage of the project risk factors related to estimation, project management, project scope, requirements, change management and hu- man (i.e. customer/user and practitioner) and at the later stage risk factors related to user satisfaction and product usage are more frequent and severely affect meet- ing the project goals. If project risk factors are beyond the control of a project manager and project development environment, it is difficult to control the risks. The results conclude that early risk management practice is necessary and GSRM contributes to this direction for a successful project outcome. Zusammenfassung Jedes Software-Entwicklungsprojekt ist einzigartig und gepragt¨ von schwer plan- baren Einflussfaktoren, wie time-to-market oder Budget, aber auch von Einflussen¨ resultierend aus der Integration und der Wartung. Die Beherrschung dieser Ein- flussgroßen¨ ist unabdingbar fur¨ die Minimierung der Risiken wahrend¨ der En- twicklung als auch wahrend¨ des gesamtem Software-Lebenszyklus. Software Risikomanagement stellt ein effektives Mittel zur Risikobeherrschung dar. Haufig¨ ist ein umfassendes Risikomanagement jedoch aufgrund fehlender Ressourcen oder fehlendem Domanenwissen¨ nicht realisierbar. Idealerweise muss Risikoman- agement aber in den gesamten Entwicklungsprozess integriert sein, insbesondere auch in die ersten Phasen der Enwicklung. Der Beitrag der Dissertation ist ein Modellierungsframework zum Risikomanage- ment. Wir schlagen einen zielbasierten Ansatz vor (Engl: Goal-driven Software Development Risk Management Model (GSRM)) und integrieren diesen in die er- ste Phase des Entwicklungprozess, in das Requirements Engineering. Diese In- tegration tragt¨ dazu bei, fruhzeitig¨ potentielle Probleme zu erkennen und diese in Form von korrigierenden Maßnahmen zu umgehen. Das Framework gliedert sich in vier Abstraktionsebenen, i.e., goal,obstacle, assessment and treatment, die eine methodische Handlungsrichtlinie zur Identifikation, Dokumentation und Be- handlung von Risiken in Zusammenhang mit Zielen unterstutzt.¨ Die Integration der Ziele fuhrt¨ insbesondere zu nachvollziehbaren und reproduzierbaren Spezi- fikationsdokumenten. Die Tragfahigkeit¨ des Ansatzes wird in Fallstudien unter Einbeziehung laufender Software-Entwicklungsprojekte hinsichtlich Anwendbarkeit und seiner Vor- und Nachteile evaluiert. Die Ergebnisse werden sowohl die Integrationsfahigkeit¨ des Ansatzes in das Requirements Engineering, als auch seine Anwendbarkeit aufzeigen. Wir werden Beobachtungen darlegen, dass das Risikomanagement unmittelbar durch die fehlende Einbindung des Projektmanagers in Projektinhalte erschwert wird, und dass der Projektkontext, wie auch die Projektkomplexitat¨ die Risiken gleichermaßen beeinflussen, unabhangig¨ von der ursprunglichen¨ Risikoeinschatzung¨ des Projektes. Wir schließen die Arbeit mit einer Zusammenfassung der Ergebnisse, stellen die Relevanz eines fruhzeitigen¨ Risikomanagements dar und belegen, wie wir mit dem Beitrag dieser Dissertation dieses Risikomanagement unterstutzen.¨ Acknowledgments It is very difficult to manage a funded PhD research from Bangladesh specifically in the field of software engineering. I am very grateful to the scholarship agency DAAD(German Academic Exchange Service) for giving me an opportunity to pur- sue my PhD study in a country like Germany. I would like to thank Prof. Manfred Broy for giving me the opportunity to work in a challenging and competitive re- search environment and support me in all aspects during the course of the disser- tation. His support and critical comments made this work much better. I also want to thank Prof. Dr. Martin Bichler for co-supervising this thesis and providing me time to discuss the updated status of the thesis. I would like to thank Siv Hilde Houmb, Telenor GBD& R, & SecureNOK Ltd., Norway for her continuous support throughout the work on my dissertation. She helped me all the way to complete this dissertation from her long experienced as a risk expert in the industry. I would also like to thank Axel van Lamsweerde and Robert Darimont for their valuable suggestion to work with KAOS goal modeling language for risk manage- ment and permit me to use KAOS goal modeling tools Objectiver version 2. During my research work, I had collaborations with Jan Jurjens¨ from Technis- che Universitat¨ Dortmund & Fraunhofer-Institute for Software- and Systems- Engineering (ISST) , Haris Mouratidis from University of East London, Kurt Schneider and Eric Knauss from Leibniz Universitat¨ Hannover and Stefan Wag- ner and Daniel Mendez-Fernandez from Technische Universitat¨ Munchen.¨ And with whom I published several research papers in the direction of this disserta- tion. Jan Jurjens¨ also gave me useful insights about how to do research and how to write papers. I would like to thank all of them. There are several persons that read (parts of) my dissertation and provided me very useful comments: Alarico Campetelli, Dmitriy Golubitskiy, Daniel Ratiu Maximilian Irlbeck , Philipp Neubeck from TUM Germany, Siv Hilde Houmb from SecureNOK Ltd. Norway. Thanks all of you. My stay at the chair was made much easier by: Silke Muller,¨ Eleni Nikolaou-Weiss, Marina Franke, Philipp Neubeck who solved my problems all the time when I appeared in front of them. Thanks all of you. Above all, I want to thank my parents, brother, especially my wife and our little son Maheer to support me while I was struggling to do my research and for giving me the greatest joy of my life. At the end, I would also like to thank all the faculty members and stuff of Institute of Information Technology(IIT), University of Dhaka, Bangladesh for a wonderful time and every support before starting my PhD work. Contents 1 Introduction1 1.1 Background and Motivation........................1 1.2 Problem Domain..............................2 1.2.1 Overall Goals of the Thesis....................3 1.2.2 Research Question.........................3 1.3 Research Contribution...........................4 1.4 The Approach................................5 1.5 Empirical Evaluation............................6 1.6 Structure of the Thesis...........................7 2 Fundamentals and Related Work 11 2.1 Basic Concepts................................ 11 2.1.1 Software Risk............................ 12 2.1.2 Risk Event and Likelihood..................... 12 2.2 Risk Management in Software Project.................. 13 2.2.1 Principals of Software Risk Management............ 14 2.2.2 Risk Management Frameworks.................. 15 2.2.3 Risk Management Standards................... 17 2.2.4 Current Practice of Risk Assessment............... 18 2.3 Study results on software risk management............... 19 2.3.1 Risk Factors............................. 19 2.3.2 Risk Factors in Global Software Development........
Load more

Recommended publications
  • ASSESSING the MAINTAINABILITY of C++ SOURCE CODE by MARIUS SUNDBAKKEN a Thesis Submitted in Partial Fulfillment of the Requireme
    ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE By MARIUS SUNDBAKKEN A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science WASHINGTON STATE UNIVERSITY School of Electrical Engineering and Computer Science DECEMBER 2001 To the Faculty of Washington State University: The members of the Committee appointed to examine the thesis of MARIUS SUNDBAKKEN find it satisfactory and recommend that it be accepted. Chair ii ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE Abstract by Marius Sundbakken, M.S. Washington State University December 2001 Chair: David Bakken Maintenance refers to the modifications made to software systems after their first release. It is not possible to develop a significant software system that does not need maintenance because change, and hence maintenance, is an inherent characteristic of software systems. It has been estimated that it costs 80% more to maintain software than to develop it. Clearly, maintenance is the major expense in the lifetime of a software product. Predicting the maintenance effort is therefore vital for cost-effective design and development. Automated techniques that can quantify the maintainability of object- oriented designs would be very useful. Models based on metrics for object-oriented source code are necessary to assess software quality and predict engineering effort. This thesis will look at C++, one of the most widely used object-oriented programming languages in academia and industry today. Metrics based models that assess the maintainability of the source code using object-oriented software metrics are developed. iii Table of Contents 1. Introduction .................................................................................................................1 1.1. Maintenance and Maintainability.......................................................................
    [Show full text]
  • Software Maintenance Maintenance Is Inevitable Types of Maintenance
    SoftWindows 8/18/2003 Software Maintenance • Managing the processes of system change Reverse Engineering (Software Maintenance & Reengineering) © SERG Maintenance is Inevitable • The system requirements are likely to change while the system is being developed because the environment is changing. • When a system is installed in an environment it changes that environment and therefore changes the system requirements. Reverse Engineering (Software Maintenance & Reengineering) © SERG Types of Maintenance • Perfective maintenance – Changing a system to make it meet its requirements more effectively. • Adaptive maintenance – Changing a system to meet new requirements. • Corrective maintenance – Changing a system to correct deficiencies in the way meets its requirements. Reverse Engineering (Software Maintenance & Reengineering) © SERG Distributed Objects 1 SoftWindows 8/18/2003 Distribution of Maintenance Effort Corrective maintenance (17%) Adaptive maintenance Perfective (18%) maintenance (65%) Reverse Engineering (Software Maintenance & Reengineering) © SERG Evolving Systems • It is usually more expensive to add functionality after a system has been developed rather than design this into the system: – Maintenance staff are often inexperienced and unfamiliar with the application domain. – Programs may be poorly structured and hard to understand. – Changes may introduce new faults as the complexity of the system makes impact assessment difficult. – The structure may be degraded due to continual change. – There may be no documentation available to describe the program. Reverse Engineering (Software Maintenance & Reengineering) © SERG The Maintenance Process • Maintenance is triggered by change requests from customers or marketing requirements. • Changes are normally batched and implemented in a new release of the system. • Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step.
    [Show full text]
  • System Software Maintenance and Support 24X7
    SYSTEM SOFTWARE MAINTENANCE AND SUPPORT SERVICES - PREMIUM These Premium System Software Maintenance and Support Service terms and conditions (“Terms and Conditions”) apply to any quote, order, order acknowledgment, and invoice, and any sale or provision of Premium System Software Maintenance and Support Services as defined herein provided to Customer by Viavi Solutions Inc. (“Viavi”), in addition to Viavi’s General Terms (“General Terms”) and/or Software License Terms, which are incorporated by reference herein and are either attached hereto, available at www.viavisolutions.com/terms or available upon request. k) Severity Level means classification of a problem determined by Viavi personnel 1. PURPOSE AND SCOPE based upon the Customer’s assessment of business impact. The three (3) Severity Levels that apply to the Services are as follows: These Terms and Conditions describe the Services that Viavi will provide to, and perform for, Customer. These Terms and Conditions apply to Services for standard Software, as 1) Problem Report – Critical means conditions that severely affect the defined herein, and are limited to the System configuration specified in a Statement of primary functionality of the System and because of the business impact to the Work (“SOW”) or other ordering document (i.e., a quote, order, order acknowledgment customer requires non-stop immediate corrective action, regardless of time of day or invoice) which contains a description of the System. All Services and Documentation or day of the week as viewed by a customer
    [Show full text]
  • Innovations in Natural Language Document Processing for Requirements Engineering
    Calhoun: The NPS Institutional Archive Faculty and Researcher Publications Faculty and Researcher Publications 2008 Innovations in Natural Language Document Processing for Requirements Engineering Berzins, Valdis þÿB. Paech and C. Martell (Eds.): Monterey Workshop 2007, LNCS 5320, pp. 125 146, 2008. http://hdl.handle.net/10945/46073 Innovations in Natural Language Document Processing for Requirements Engineering Valdis Berzins, Craig Martell, Luqi, and Paige Adams Naval Postgraduate School, 1411 Cunningham Road, Monterey, California 93943 {berzins,cmartell,luqi,phadams}@nps.edu Abstract. This paper evaluates the potential contributions of natural language processing to requirements engineering. We present a selective history of the relationship between requirements engineering (RE) and natural-language processing (NLP), and briefly summarize relevant re- cent trends in NLP. The paper outlines basic issues in RE and how they relate to interactions between a NLP front end and system-development processes. We suggest some improvements to NLP that may be possible in the context of RE and conclude with an assessment of what should be done to improve likelihood of practical impact in this direction. Keywords: Requirements, Natural Language, Ambiguity, Gaps, Domain- Specific Methods. 1 Introduction A major challenge in requirements engineering is dealing with changes, especially in the context of systems of systems with correspondingly complex stakeholder communities and critical systems with stringent dependability requirements. Documentation driven development (DDD) is a recently developed approach for addressing these issues that seeks to simultaneously improve agility and de- pendability via computer assistance centered on a variety of documents [1,2]. The approach is based on a new view of documents as computationally active knowledge bases that support computer aid for many software engineering tasks from requirements engineering to system evolution, which is quite different from the traditional view of documents as passive pieces of paper.
    [Show full text]
  • Managing Requirements Engineering Risks: an Analysis and Synthesis of the Literature
    Lars Mathiassen – Timo Saarinen – Tuure Tuunanen – Matti Rossi MANAGING REQUIREMENTS ENGINEERING RISKS: AN ANALYSIS AND SYNTHESIS OF THE LITERATURE W-379 HELSINKI SCHOOL OF ECONOMICS ISSN 1795-1828 WORKING PAPERS ISBN 951-791-895-X (Electronic working paper) W-379 2004 Lars Mathiassen* – Timo Saarinen** – Tuure Tuunanen** – Matti Rossi** MANAGING REQUIREMENTS ENGINEERING RISKS: AN ANALYSIS AND SYNTHESIS OF THE LITERATURE *Center for Process Innovation, Georgia State University **Helsinki School Economics, Department of Management, Information Systems Science November 2004 HELSINGIN KAUPPAKORKEAKOULU HELSINKI SCHOOL OF ECONOMICS WORKING PAPERS W-379 HELSINGIN KAUPPAKORKEAKOULU HELSINKI SCHOOL OF ECONOMICS PL 1210 FIN-00101 HELSINKI FINLAND © Lars Mathiassen, Timo Saarinen, Tuure Tuunanen, Matti Rossi and Helsinki School of Economics ISSN 1795-1828 ISBN 951-791-895-X (Electronic working paper) Helsinki School of Economics - HeSE print 2004 Managing Requirements Engineering Risks: An Analysis and Synthesis of the Literature Lars Mathiassen ([email protected]) Center for Process Innovation, Georgia State University P. O. Box 4015, Atlanta, GA 30303-4015, USA Phone: +1-404-651-0933, Fax: +1-404-463-9292 Timo Saarinen ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P. O. Box 1210, FIN-00101 Helsinki, Finland Phone: +358-9-431-38272, Fax: Fax: +358-9-431-38700 Tuure Tuunanen ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P. O. Box 1210, FIN-00101 Helsinki, Finland Phone: +358-40-544-5591, Fax: +358-9-431-38700 http://www.tuunanen.fi Matti Rossi ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P.
    [Show full text]
  • Software Engineering Software Maintenance
    SOFTWARE ENGINEERING SOFTWARE MAINTENANCE Software maintenance is the process of modification or making changes in the system after delivery to overcome errors and faults in the system that were not uncovered during the early stages of the development cycle. LEARNING OBJECTIVES • To study on why maintenance is an issue. • To study on reverse engineering and limitations. • To organize data. • To check what the system does. SOFTWARE MAINTENANCE The IEEE Standard for Software Maintenance (IEEE 1219) gave the definition for software maintenance as “The process of modifying a software system or component after delivery to correct faults, improves performance or other attributes, or adapt to a changed environment.” Maintenance Principles 100 Hardware Development 60 Software 20 Maintenance Percent of total cost total of Percent 1995 2000 2010 The IEEE/EIA 12207 Standard defines maintenance as modification to code and associated documentation due to a problem or the need for improvement. Nature of Maintenance Modification requests are logged and tracked, the impact of proposed changes are determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. Maintainers can learn from the developer´s knowledge of the software. Need for Maintenance Maintenance must be performed in order to: • Correct faults. • Improve the design. • Implement enhancements. • Interface with other systems. • Adapt programs so that different hardware, software, system features, and telecommunications facilities can be used. • Migrate legacy software. • Retire software Tasks of a maintainer The maintainer does the following functions: • Maintain control over the software´s day-to-day functions. • Maintain control over software modification.
    [Show full text]
  • Requirements Management Applied in an Agile Project Management Environment
    Requirements Management applied in an agile Project Management environment Franco (Frank) Curtolo CEng, Principal Consultant, Program Planning Professionals Ltd, [email protected] Categorisation • Accessibility: PRACTITIONER • Application: GOOD PRACTICE • Topics: Agile Systems Engineering; Project Management Abstract This paper looks at how the Requirements Management process of Systems Engineering may benefit from some of the aspects derived from developing systems within an agile Project Management environment, using as example, the Scaled Agile Framework® of © Scaled Agile, Inc. The aim is to see if some of these agile techniques can enhance the Systems Engineering approach. Systems Engineering (SE) is well suited to develop large, complex products in a project environment where the requirements can be defined and fixed upfront. In fact, SE relies on an initial, well-defined End User’s need specified in for example, a User Requirements Specification (URS), to establish an initial requirements baseline which is used to drive the rest of the development process. However not all development projects happen that way. Sometimes the End User’s need is not clear, or cannot be well defined upfront, thus not allowing it to be captured in a fixed requirements baseline. Furthermore, the project environment may need to accommodate rapid change, both in the End Users’ need and in the technologies available to satisfy this need. In such a project environment, an agile development approach, as described in the Scaled Agile Framework® (SAFe®), may be more suitable since it allows for incremental delivery of the product and change to requirements. This can accommodate undefined End User needs, rapid change in requirements and allow for the introduction of innovation during the development and implementation stages.
    [Show full text]
  • Read Ms. Shaw's First Amended Complaint
    Janet L. Goldstein Peter W. Chatfield THE MARTYN FIRM, PLLC PHILLIPS & COHEN LLP 1054 31st Street, NW 2000 Massachusetts Ave., NW Washington, D.C. 20007 Washington, D.C. 20036 Tel: (202) 965-3060 Tel: (202) 833-4567 Fax: (202) 965-3063 Fax: (202) 833-1815 Jonathan A. Willens (JW-9180) JONATHAN A. WILLENS LLC 217 Broadway, Suite 707 New York, New York 10007 Tel: (212) 619-3749 Fax: (800) 879-7938 Attorneys for qui tam plaintiff Ann-Marie Shaw UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF NEW YORK UNITED STATES OF AMERICA ) 06 CV 3552 (DLI) (SMG) ex rel. ANN-MARIE SHAW ) and ) AMENDED COMPLAINT ) FOR VIOLATIONS OF STATE OF CALIFORNIA ex rel.ANN-MARIE SHAW ) FEDERAL AND STATE DISTRICT OF COLUMBIA ex rel.ANN-MARIE SHAW ) FALSE CLAIMS ACTS STATE OF FLORIDA ex rel.ANN-MARIE SHAW ) STATE OF HAWAII ex rel.ANN-MARIE SHAW ) STATE OF ILLINOIS ex rel.ANN-MARIE SHAW ) COMMONWEALTH OF MASSACHUSETTS ) ex rel.ANN-MARIE SHAW ) STATE OF NEVADA ex rel.ANN-MARIE SHAW ) COMMONWEALTH OF VIRGINA ) ex rel.ANN-MARIE SHAW ) STATE & CITY OF NEW YORK ) ex rel.ANN-MARIE SHAW, ) ) JURY TRIAL DEMANDED Plaintiffs, ) ) FILED UNDER SEAL v. ) ) CA, INC., ) ) Defendant. ) _______________________________________________ ) Through her attorneys, plaintiff and qui tam relator Ann-Marie Shaw, for her Amended Complaint against Defendant CA, Inc. (“CA”), formerly known as Computer Associates International, Inc. or “Computer Associates,” alleges as follows: FACTS COMMON TO ALL COUNTS A. Introduction 1. This is a civil action to recover damages and civil penalties arising from false and/or fraudulent statements, records, and claims made and caused to be made by the Defendant CA and/or its agents and employees in violation of the Federal Civil False Claims Act, 31 U.S.C.
    [Show full text]
  • Requirements Engineering Objectives
    Requirements Engineering Chapter 2 Requirements Engineering Processes Learning Objective ...to give a general introduction to the requirements engineering process. Different approaches to modeling requirements engineering processes are suggested and why human, social and organizational factors are important influences on those processes. Other concepts that are evaluated include process maturity, tools and process improvement. Frederick T Sheldon Assistant Professor of Computer Science University of Colorado at Colorado Springs CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 1 Objectives ⊗ To introduce the notion of processes and process models for requirements engineering ⊗ To explain the critical role of people in requirements engineering processes ⊗ To explain why process improvements is important and to suggest a process improvement model for requirements engineering CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 2 Processes ⊗ A process is an organized set of activities which transforms inputs to outputs ⊗ Process descriptions encapsulate knowledge and allow it to be reused ⊗ Examples of process descriptions • Instruction manual for a dishwasher • Cookery book • Procedures manual for a bank • Quality manual for software development CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 3 Design processes ⊗ Processes which involve creativity, interactions between a wide range of different people, engineering judgement and background knowledge and experience ⊗ Examples of design processes • Writing a book • Organizing a conference • Designing a processor chip • Requirements engineering CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G.
    [Show full text]
  • Techniques for Software Maintenance 57 02 58
    01 Techniques for Software Maintenance 57 02 58 03 59 04 60 Kostas Kontogiannis 05 61 Department of Electrical and Computer Engineering, National Technical University of Athens, 06 62 Athens, Greece 07 63 08 64 09 65 10 66 Abstract 11 Software maintenance constitutes a major phase of the software life cycle. Studies indicate that software 67 12 maintenance is responsible for a significant percentage of a system’s overall cost and effort. The software 68 13 engineering community has identified four major types of software maintenance, namely, corrective, 69 14 perfective, adaptive, and preventive maintenance. Software maintenance can be seen from two major points 70 15 of view. First, the classic view where software maintenance provides the necessary theories, techniques, 71 16 methodologies, and tools for keeping software systems operational once they have been deployed to their 72 17 operational environment. Most legacy systems subscribe to this view of software maintenance. The second 73 18 view is a more modern emerging view, where maintenance is an integral part of the software development 74 19 process and it should be applied from the early stages in the software life cycle. Regardless of the view by 75 which we consider software maintenance, the fact is that it is the driving force behind software evolution, a 20 76 very important aspect of a software system. This entry provides an in-depth discussion of software 21 77 Q1 maintenance techniques, methodologies, tools, and emerging trends. 22 78 23 79 24 80 25 INTRODUCTION type of software maintenance is referred to as Adaptive 81 26 82 Software Maintenance and refers to activities that aim to 27 83 Software maintenance is an integral part of the software modify models and artifacts of existing systems so that 28 84 life cycle and has been identified as an activity that affects these systems can be integrated with new systems or 29 85 in a major way the overall system cost and effort.
    [Show full text]
  • Elicitation of Quality Agile User Stories Using QFD
    Elicitation of Quality Agile User Stories Using QFD NDIA 20th Annual Systems Engineering Conference “Agile in Systems Engineering“ 10:15 – 10:40 AM October 25, 2017 Sabrina J. Ussery, Shahryar Sarkani, Thomas Holzer Dissertation Topic Department of Engineering Management and Systems Engineering School of Engineering and Applied Science The George Washington University 1176 G Street NW Washington, DC 20052 1 Agile Requirements Engineering (RE) The lack of standard Requirements Engineering (RE) practices in Agile negatively impacts system quality, contributing to 24% of the causes for challenged or failed projects. • The 2015 CHAOS Standish Group report indicates Agile projects are 3x more likely to succeed than Waterfall projects due to increased customer collaboration and customer satisfaction. [2] • The Agile community claims that they do not really tackle requirements in a structured way, which may bring problems to the software organization responsible for software built following an Agile method. [1] • Though more successful in some respects, the Image source: [2] lack of stand RE practices in Agile contributes to 24% of the reasons for challenged or failed projects due to poor requirements quality (i.e., unclear or volatile). [2] 2 What is Agile? 3 Agile RE: As Is Requirements Requirements engineering (RE) refers to the process of defining, documenting and maintainingEngineering requirements. [5] Requirements Requirements Development Management Elicitation Priorities Specification Traceability Analysis Specifications Validation Configuration
    [Show full text]
  • Integrated Requirements Engineering: a Tutorial
    focusrequirements engineering1 Integrated Requirements Engineering: A Tutorial Ian Sommerville, Lancaster University efore developing any system, you must understand what the sys- tem is supposed to do and how its use can support the goals of the individuals or business that will pay for that system. This in- B volves understanding the application domain (telecommunica- tions, railways, retail banking, games, and so on); the system’s operational constraints; the specific functionality required by the stakeholders (the peo- ple who directly or indirectly use the system or the information it provides); and essential system characteristics such as The fundamental process performance, security, and dependability. Re- The RE process varies immensely depend- quirements engineering is the name given to a ing on the type of application being devel- structured set of activities that help develop oped, the size and culture of the companies in- this understanding and that document the sys- volved, and the software acquisition processes tem specification for the stakeholders and en- used. For large military and aerospace sys- gineers involved in the system development. tems, there is normally a formal RE stage in This short tutorial introduces the funda- the systems engineering processes and an ex- mental activities of RE and discusses how it tensively documented set of system and soft- has evolved as part of the software engineering ware requirements. For small companies de- process. However, rather than focus on estab- veloping innovative software products, the RE lished RE techniques, I discuss how the chang- process might consist of brainstorming ses- ing nature of software engineering has led to sions, and the product “requirements” might new challenges for RE.
    [Show full text]