DOCSLIB.ORG

6.005 Elements of Software Construction Fall 2008

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
6.005 Elements of Software Construction Fall 2008 MIT OpenCourseWare http://ocw.mit.edu 6.005 Elements of Software Construction Fall 2008 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms. 10/6/2008 Today’s Topics why testing is important and hard choosing inputs ¾input space partitioning ¾boundary testing how to know if you’ve done enough Testing and Coverage ¾coverage testing pragmatics Rob Miller ¾stubs, drivers, oracles Fall 2008 ¾test-first development ¾regression testing © Robert Miller 2008 © Robert Miller 2008 Real Programmers Don’t Test!(?) top 5 reasons not to test 5) I want to get this done fast – testing is going to slow me down. 4) I started programming when I was 2. Don’t insult me by testing my perfect code! 3) testing is for incompetent programmers who cannot hack. 2) we’re not Harvard students – our code actually works! 1) “Most of the functions in Graph.java, as implemented, are one or two line functions that rely solely upon functions in HashMap or HashSet. I am assuming that these functions work perfectly, and thus there is really no need to test them.” – an excerpt from a 6.170 student’s e-mail WHY TESTING MATTERS © Robert Miller 2008 © Robert Miller 2008 1 10/6/2008 Who Says Software is Buggy? Another Prominent Software Bug Ariane 5 self-destructed 37 seconds after launch Mars Polar Lander crashed Photographs of the Ariane 5 rocket Diagrams of the Mars Polar Lander removed due to copyright restrictions. removed due to copyright restrictions. reason: a control software bug that went undetected ¾conversion from 64-bit floating point to 16-bit signed integer caused an ¾sensor signal falsely indicated that the craft had touched down when it was exception still 130 feet above the surface. • because the value was larger than 32767 (max 16-bit signed integer) ¾the descent engines shut down prematurely... and it was never heard from ¾but the exception handler had been disabled for efficiency reasons again ¾software crashed ... rocket crashed ... total cost over $1 billion the error was traced to a single bad line of code ¾Prof. Nancy Leveson: these problems "are well known as difficult parts of the software-engineering process”... and yet we still can’t get them right © Robert Miller 2008 © Robert Miller 2008 The Challenge Testing Strategies That Don’t Work we want to exhaustive testing is infeasible ¾know when product is stable enough to launch ¾space is generally too big to cover exhaustively ¾deliver product with known failure rate (preferably low) ¾imagine exhaustively testing a 32-bit floating-point multiply operation, a*b ¾offer warranty? • there are 2^64 test cases! but statistical testing doesn’t work for software ¾it’s very hard to measure or ensure quality in software ¾other engineering disciplines can test small random samples (e.g. 1% of ¾residual defect rate after shipping: hard drives manufactured) and infer defect rate for whole lot • 1 - 10 defects/kloc (typical) ¾many tricks to speed up time (e.g. opening a refrigerator 1000 times in 24 • 0.1 - 1 defects/kloc (high quality: Java libraries?) hours instead of 10 years) • 0. 01 - 0. 1 defects/kloc (very best: Praxis, NASA) ¾gives known failure rates (e.g. mean lifetime of a hard drive) ¾example: 1Mloc with 1 defect/kloc means you missed 1000 bugs! ¾but assumes continuity or uniformity across the space of defects, which is true for physical artifacts ¾this is not true for software • overflow bugs (like Ariane 5) happen abruptly • Pentium division bug affected approximately 1 in 9 billion divisions © Robert Miller 2008 © Robert Miller 2008 2 10/6/2008 Two Problems Aims of Testing often confused, but very different what are we trying to do? (a) problem of finding bugs in defective code ¾find bugs as cheaply and quickly as possible (b) problem of showing absence of bugs in good code reality vs. ideal approaches ¾idea lly, choose one test case that exposes a bug and run iit ¾testing: good for (a), occasionally (b) ¾in practice, have to run many test cases that “fail” (because they don’t ¾reasoning: good for (a), also (b) expose any bugs) theory and practice in practice, conflicting desiderata ¾for both, you need grasp of basic theory ¾increase chance of finding bug ¾good engineering judgment essential too ¾decrease cost of test suite (cost to generate, cost to run) © Robert Miller 2008 © Robert Miller 2008 Practical Strategies Basic Notions design testing strategy carefully what’s being tested? ¾know what it’s good for (finding egregious bugs) and not good for ¾unit testing: individual module (method, class, interface) (security) ¾subsystem testing: entire subsystems ¾complement with other methods: code review, reasoning, static analysis ¾integration, system, acceptance testing: whole system ¾exploit automation (e.g. JUnit) to increase coverage and frequency of how are inputs chosen? testing ¾random: surprisingly effective (in defects found per test case), but not ¾do it early and often much use when most inputs are invalid (e.g. URLs) ¾systematic: partitioning large input space into a few representatives ¾arbitrary: not a good idea, and not the same as random! how are outputs checked? ¾automatic checking is preferable, but sometimes hard (how to check the display of a graphical user interface?) © Robert Miller 2008 © Robert Miller 2008 3 10/6/2008 Basic Notions how good is the test suite? ¾coverage: how much of the specification or code is exercised by tests? when is testing done? ¾test-didriven deve lopment: tests are written first, bfbefore the code ¾regression testing: a new test is added for every discovered bug, and tests are run after every change to the code essential characteristics of tests ¾modularity: no dependence of test driver on internals of unit being tested ¾automation: must be able to run (and check results) without manual effort CHOOSING TESTS © Robert Miller 2008 © Robert Miller 2008 Example: Thermostat How Do We Test the Thermostat? specification arbitrary testing is not convincing ¾user sets the desired temperature Td ¾“just try it and see if it works“ won’t fly ¾thermostat measures the ambient temperature Ta exhaustive testing is not feasible ¾want heating if desired temp is higher than ambient temp ¾would require millions of runs to test all possible (TdT(Td,Ta ) pairs ¾want cooling if desired temp is lower than ambient temp key problem: choosing a test suite systematically ¾small enough to run quickly if Td > Ta, turn on heating ¾large enough to validate the program convincingly if Td < Ta, turn on air-conditioning if Td = Ta, turn everything off © Robert Miller 2008 © Robert Miller 2008 4 10/6/2008 Key Idea: Partition the Input Space More Examples input space is very large, but program is small java.math.BigInteger.multiply(BigInteger val) ¾so behavior must be the “same” for whole sets of inputs ¾has two arguments, this and val, drawn from BigInteger ideal test suite ¾partition BigInteger into: approach 1: ¾ident ify sets of inputs wiihth the same bbhehavi or • BigNeg, SmallNeg, -1, 0, 1, SmallPos, BigPos partition itinputs ¾try one input from each set ¾pick a value from each class separately, • -265, -9 -1, 0, 1, 9, 265 then form all ¾test the 7 × 7 = 49 combinations combinations static int java.Math.max(int a, int b) ¾partition into: approach 2: if Td > Ta, turn on heating • a < b, a = b, a > b partition the whlhole if Td < Ta, turn on air-conditioning ¾pick value from each class input space (useful if Td = Ta, turn everything off • (1, 2), (1, 1), (2, 1) when relationship between inputs matters) © Robert Miller 2008 © Robert Miller 2008 More Examples Boundary Testing Set.intersect(Set that) ¾include classes at boundaries of the input space • zero, min/max values, empty set, empty string, null ¾partition Set into: use both approaches • ∅, singleton, many ¾why? because bugs often occur at boundaries ¾partition whole input space into: • off-by-one errors • this = that, this ⊆ that, this ⊇ that, this ∩ that ≠ ∅, this ∩ that = ∅ • forget to handle empty container • overflow errors in arithmetic ¾pppick values that cover both partitions • {},{} {},{2} {},{2,3,4} • {5},{} {5},{2} {4},{2,3,4} • {2,3},{} {2,3},{2} {1,2},{2,3} © Robert Miller 2008 © Robert Miller 2008 5 10/6/2008 Exercise recall our quiz grammar ¾partition the input space of quizzes ¾devise a set of test quizzes Option ::= Value? Text Value ::= [ digit+ ] Text ::= char* Rule ::= Range Message Range ::= digit+ - digit+ : Message ::= char* COVERAGE ¾what important class of inputs are we leaving out? © Robert Miller 2008 © Robert Miller 2008 Coverage State Diagram for Thermostat how good are my tests? ¾measure extent to which tests ‘cover’ the spec or code if Td > Ta, turn on heating spec coverage for state machines if Td < Ta, turn on air-conditioning if Td = Ta, turn everything off state machine being tested all actions ¾a test case is a trace of (Td,Ta) pairs ¾all actions: (Td<Ta), (Td=Ta), (Td>Ta) all states • e.g., using actual temperatures: (67, 70), (67, 67), (70, 67) kinds of ¾all states: the same trace would cover all states coverage all transitions ¾all transitions: (Td<Ta), (Td=Ta), (Td > Ta), (Td=Ta) • e.g. (67, 70), (67, 67), (70, 67), (70, 70) all paths ¾all-actions, all-states ≤ all-transitions ≤ all-paths © Robert Miller 2008 © Robert Miller 2008 6 10/6/2008 Code Coverage How Far Should You Go? view control flow graph as state machine for spec coverage ¾and then apply state machine coverage notions ¾ all-actions: essential example ¾ all-states, all-transitions: if possible if (x < 10) x++; ¾ all-paths: generally infeasible, even if finite for code coverage ¾ all-statements, all-branches: if possible ¾ all-paths: infeasible industry practice ¾ all-statements is common goal, rarely achieved (due to unreachable code) ¾safe ty critica l in dus try has more arduous criter ia (eg, “MCDC”, modifie d decision/condition coverage) © Robert Miller 2008 © Robert Miller 2008 A Typical Statement Coverage Tool Black Box vs.
Load more

Recommended publications
  • Testing in the Software Development Life Cycle and Its Importance
    International Journal of Engineering and Information Systems (IJEAIS) ISSN: 2643-640X Vol. 3 Issue 9, September – 2019, Pages: 15-20 Testing in the Software Development Life Cycle and its Importance Noortaj Department of Computing and Technology Abasyn University Peshawar, Pakistan Email: [email protected] Abstract : Software development life cycle is a structure followed by the development team within the software organization imposed on the development of software product. The important role of testing in the software development life cycle is to improve the performance, reliability, and quality of the software. I believe testing should be thoroughly planned and conducted throughout the Software development life cycle for best results. Hence, software testing is facing different challenges. In this article, i have explained different phases of the software development life cycle, different testing techniques and its importance. Keywords: Software Development Life Cycle Testing, Testing in the Software Development Process, Software Testing, Importance of testing. 1. INTRODUCTION Testing plays an important role in the software development life-cycle to recognize the defects in the development process and resolve those defects. But before the explanation of the Software development life cycle, I would like to explain the phases of the software development process. Phase 1 Requirement collection and Analysis: For the collection of requirements a discussion is conducted to analyze the requirements and to state how the problem should be solved. The main work of the requirement collection is to determine the anticipated issues and it helps companies to finalize the necessary timeline in order to complete the work of that system in time.
    [Show full text]
  • Definition of Software Construction Artefacts for Software Construction
    Chapter 3: Internet and Applications Definition of Software Construction Artefacts for Software Construction M.Zinn, G.Turetschek and A.D.Phippen Centre for Information Security and Network Research, University of Plymouth, Plymouth United Kingdom e-mail: [email protected]; [email protected], [email protected] Abstract The definition of a service based software construction process, published in 2007 (Zinn, 2007), builds on the use of software construction artefacts (SCA). These artefacts form useable building blocks (units of modelling) for software, which can be implemented in a software product by a service. The building blocks are categorized in four different types (GUI, data, function and structure). The foundation for the use of these artefacts is the method of the software construction process which constructs the software similar to the methods used in computer aided design (CAD). This paper refines and expands on the definition of the artefacts to present the current state of research in software construction procedures. It will show how the artefacts are constructed and how they can be used in software construction. In addition the software construction artefacts will be compared to components, modules and objects. Based on this definition of the application area, further potential scenarios for the use of the artefacts, as well as their properties and points still being worked on, are shown. The purpose is to create a more exact description, definition of the software construction artefacts to obtain a better understanding of the software construction process. Keywords Computer Aided Design (CAD), software construction process (SCP), software engineering, (web) services, software construction artefacts (SCA) and software construction services (SCS), model driven development (MDD) 1.
    [Show full text]
  • A Parallel Program Execution Model Supporting Modular Software Construction
    A Parallel Program Execution Model Supporting Modular Software Construction Jack B. Dennis Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 U.S.A. [email protected] Abstract as a guide for computer system design—follows from basic requirements for supporting modular software construction. A watershed is near in the architecture of computer sys- The fundamental theme of this paper is: tems. There is overwhelming demand for systems that sup- port a universal format for computer programs and software The architecture of computer systems should components so users may benefit from their use on a wide reflect the requirements of the structure of pro- variety of computing platforms. At present this demand is grams. The programming interface provided being met by commodity microprocessors together with stan- should address software engineering issues, in dard operating system interfaces. However, current systems particular, the ability to practice the modular do not offer a standard API (application program interface) construction of software. for parallel programming, and the popular interfaces for parallel computing violate essential principles of modular The positions taken in this presentation are contrary to or component-based software construction. Moreover, mi- much conventional wisdom, so I have included a ques- croprocessor architecture is reaching the limit of what can tion/answer dialog at appropriate places to highlight points be done usefully within the framework of superscalar and of debate. We start with a discussion of the nature and VLIW processor models. The next step is to put several purpose of a program execution model. Our Parallelism processors (or the equivalent) on a single chip.
    [Show full text]
  • Object-Oriented Software Construction Oriented Software Construction Software Construction I Software Construction II
    ObjectObject--orientedoriented software construction Analysis/Requirements: What am I doing? Design: Which classes and methods? Implementation: How do I do it? Testing: Does it work? Maintenance: I just turn it in, right? Software Construction I z Programming is not just coding and debugging! z Analysis Analysis – English description of what system models, Design to meet a requirement or specification Implementation – Usually involves working with non-programmer Testing Maintenance to develop detailed specifications Waterfall model of software development z DiDesign: Mtit!Measure twice, cut once! – divide & conquer: system is composed of smaller subsystems which in turn may be composed of even smaller subsystems z OOP, system is decomposed into a set of cooperating objects – Pseudocode: describe tasks, subtasks, and how they relate – hand-simulation: desk-check pseudocode by stepping through it without using a computer – often use diagrams to better communicate the structure of the system z Often flowcharts in procedural languages and UML diagrams in OOP Wright State University, College of Engineering CS 241 Dr. T. Doom, Computer Science & Engineering Computer Programming II 58 Software Construction II z Implementation – Pick a language Analysis Design – emphasize good problem decomposition, Implementation well structured design, and readable, Testing well-documented programming style Maintenance –mayyg need to backtrack and redesign Waterfall model of software development z Testing – submitting input data or sample user interactions and seeing if program reacts properly – typically done in stages, starting with individual components and working up to subsystems, and eventually the entire program – bugs: errors in code or design – debugging: process of removing program bugs Wright State University, College of Engineering CS 241 Dr.
    [Show full text]
  • 6.005 Elements of Software Construction Fall 2008
    MIT OpenCourseWare http://ocw.mit.edu 6.005 Elements of Software Construction Fall 2008 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms. 10/15/2008 Today’s Topics how to avoid debugging ¾assertions ¾code reviews how to do it when you have to ¾reducing test cases ¾hypothesis-driven debugging ¾binary search Debugging very hard bugs Rob Miller ¾Heisenbugs Fall 2008 © Robert Miller 2008 © Robert Miller 2008 Defensive Programming First Defense: Impossible By Design first defense against bugs is to make them impossible in the language ¾Java makes buffer overflow bugs impossible ¾automatic array bounds checking make buffer overflow bugs impossible second defense against bugs is to not make them ¾static typing eliminates many runtime type errors ¾correctness: get things riihght first time in the protocols/libraries/modules third defense is to make bugs easy to find ¾TCP/IP guarantees that data is not reordered ¾local visibility of errors: if things fail, we'd rather they fail loudly and ¾BigInteger guarantees that there will be no overflow immediately – e.g. with assertions in self-imposed conventions fourth defense is extensive testing ¾immutable objects can be passed around and shared without fear ¾uncover as many bugs as possible ¾caution: you have to keep the discipline last resort is dbidebugging • get the language to hel p you as much as possible , e.g. with pritivate and final ¾needed when effect of bug is distant from cause © Robert Miller 2008 © Robert Miller 2008 1 10/15/2008 Second Defense: Correctness Third Defense: Immediate Visibility get things right the first time if we can't prevent bugs, we can try to localize them to ¾don’t code before you think! Think before you code.
    [Show full text]
  • Integration Testing of Object-Oriented Software
    POLITECNICO DI MILANO DOTTORATO DI RICERCA IN INGEGNERIA INFORMATICA E AUTOMATICA Integration Testing of Object-Oriented Software Ph.D. Thesis of: Alessandro Orso Advisor: Prof. Mauro Pezze` Tutor: Prof. Carlo Ghezzi Supervisor of the Ph.D. Program: Prof. Carlo Ghezzi XI ciclo To my family Acknowledgments Finding the right words and the right way for expressing acknowledgments is a diffi- cult task. I hope the following will not sound as a set of ritual formulas, since I mean every single word. First of all I wish to thank professor Mauro Pezze` , for his guidance, his support, and his patience during my work. I know that “taking care” of me has been a hard work, but he only has himself to blame for my starting a Ph.D. program. A very special thank to Professor Carlo Ghezzi for his teachings, for his willingness to help me, and for allowing me to restlessly “steal” books and journals from his office. Now, I can bring them back (at least the one I remember...) Then, I wish to thank my family. I owe them a lot (and even if I don't show this very often; I know this very well). All my love goes to them. Special thanks are due to all my long time and not-so-long time friends. They are (stricty in alphabetical order): Alessandro “Pari” Parimbelli, Ambrogio “Bobo” Usuelli, Andrea “Maken” Machini, Antonio “the Awesome” Carzaniga, Dario “Pitone” Galbiati, Federico “Fede” Clonfero, Flavio “Spadone” Spada, Gianpaolo “the Red One” Cugola, Giovanni “Negroni” Denaro, Giovanni “Muscle Man” Vigna, Lorenzo “the Diver” Riva, Matteo “Prada” Pradella, Mattia “il Monga” Monga, Niels “l’e´ semper chi” Kierkegaard, Pierluigi “San Peter” Sanpietro, Sergio “Que viva Mex- ico” Silva.
    [Show full text]
  • Effective Methods for Software Testing
    Effective Methods for Software Testing Third Edition Effective Methods for Software Testing Third Edition William E. Perry Effective Methods for Software Testing, Third Edition Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2006 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN-13: 978-0-7645-9837-1 ISBN-10: 0-7645-9837-6 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 3MA/QV/QU/QW/IN No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copy- right Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no repre- sentations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fit- ness for a particular purpose. No warranty may be created or extended by sales or promo- tional materials.
    [Show full text]
  • A Survey of System Development Process Models
    Models for Action: Developing Practical Approaches to Electronic Records Management and Preservation Center for Technology in Government State Archives and Records Administration A Survey of System Development Process Models Introduction This document provides an overview of the more common system development Process Models, used to guide the analysis, design, development, and maintenance of information systems. There are many different methods and techniques used to direct the life cycle of a software development project and most real-world models are customized adaptations of the generic models. While each is designed for a specific purpose or reason, most have similar goals and share many common tasks. This paper will explore the similarities and differences among these various models and will also discuss how different approaches are chosen and combined to address practical situations. Typical Tasks in the Development Process Life Cycle Professional system developers and the customers they serve share a common goal of building information systems that effectively support business process objectives. In order to ensure that cost-effective, quality systems are developed which address an organization’s business needs, developers employ some kind of system development Process Model to direct the project’s life cycle. Typical activities performed include the following:1 · System conceptualization · System requirements and benefits analysis · Project adoption and project scoping · System design · Specification of software requirements · Architectural design · Detailed design · Unit development · Software integration & testing · System integration & testing · Installation at site · Site testing and acceptance · Training and documentation · Implementation · Maintenance 1 Kal Toth, Intellitech Consulting Inc. and Simon Fraser University; list is partially created from lecture notes: Software Engineering Best Practices, 1997.
    [Show full text]
  • Decision Framework for Selecting a Suitable Software Development Process
    DECISION FRAMEWORK FOR SELECTING A SUITABLE SOFTWARE DEVELOPMENT PROCESS Delft University of Technology Faculty of Technology, Policy and Management Systems Engineering, Policy Analysis and Management (SEPAM) August, 2009 By Itamar Sharon 2 DECISION FRAMEWORK FOR SELECTING A SUITABLE SOFTWARE DEVELOPMENT PROCESS SPM 5910 Master Thesis Faculty of Technology, Policy and Management Section: ICT By Itamar Sharon Student Number: 1192922 August, 2009 Graduation committee: M. dos Santos Soares (first supervisor) Dr. J. Barjis (second supervisor) Dr.ir. J. van den Berg (section professor) C. Bergman (Operations and IT Banking ING supervisor) 3 4 PPREFACE This Thesis report has been written in the period of February – August 2009. In this report I describe the research I have conducted during my internship at Operations and IT Banking ING (OIB ING) which is the final facet of my MSc education in Systems Engineering, Policy Analysis and Management at the faculty of Technology, Policy and Management (TPM), Delft University of Technology. Performing this research and writing this Thesis was, at some periods, a struggle and intellectual challenge. However, most of the times, I felt delighted of the work that I did and the contribution it will finally make. For this research, I could not have wished for a better environment to perform in. The department in which I was stationed (Solution Delivery Centre Call Face NL) was very comfortable as a research setting. I experienced its employees as flexible, interested and most of all very helpful. The most difficult aspect of this graduation project was to conduct it individually. In the entire MSc education programme, every project consisted of multiple project members.
    [Show full text]
  • Continual and Long-Term Improvement in Agile Software Development
    MASARYK UNIVERSITY Faculty of informatics Continual and long-term improvement in agile software development DIPLOMA THESIS Brno 2015 Bc. Juraj Šoltés Declaration I declare that the work in this thesis is my own authorial work, which I have worked out on my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Juraj Šoltés Advisor: doc. RNDr. Tomáš Pitner, Ph.D. ii Acknowledgment I would like to express thanks of gratitude to everyone, who supported me throughout the course of this thesis. My special thanks belong to my advisor, who helped me with the overall idea and structure of my diploma thesis. I would also like to thank my family and friends for material and psychological support, Kentico software for the opportunity of doing my diploma thesis under its roof, my colleagues who helped me to become Scrum master and the On-line marketing team for their patience with me. iii Abstract Diploma thesis deals with the improvement in agile teams and ways how it can be measured and tracked. The work puts emphasis on choosing proper metrics and working with them so that it complies with the principles behind agile manifesto. The metrics then serve as a basis for creating the performance indicators for chosen goals. Several representative indicators for the agile process measuring are created, concretely in areas of collaboration and predictability. These are then used for analysis of the data collected during two releases in Kentico software. The results are compared with the outcome of the team’s retrospectives.
    [Show full text]
  • Software Construction
    Software Construction Bertrand Meyer University of Zurich September-December 2017 Lecture 5: Requirements analysis Statements about requirements: Brooks Source*: Brooks 87 The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. *For sources cited, see bibliography 2 2 1 Statements about requirements: Boehm Source*: Boehm 81 Relative cost to correct a defect 70 60 50 40 30 20 10 0 Requirements Design Code Development Acceptance Operation Testing Testing Source: Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981 3 When not done right 80% of interface fault and 20% of implementation faults due to requirements (Perry & Stieg, 1993) 48% to 67% of safety‐related faults in NASA software systems due to misunderstood hardware interface specifications, of which 2/3rds are due to requirements (Lutz, 1993) 85% of defects due to requirements, of which: incorrect assumptions 49%, omitted requirements 29%, inconsistent requirements 13% (Young, 2001). Numerous software bugs due to poor requirements, e.g. Mars Climate Orbiter 4 2 A small case study Source*: Wing 88 Consider a small library database Transactions 1, 2, 4, and 5 are with the following transactions: restricted to staff users, except that 1. Check out a copy of a book. ordinary borrowers can perform Return a copy of a book.
    [Show full text]
  • Lean Thinking in Software Engineering : a Systematic Review
    International Journal of Software Engineering & Applications (IJSEA), Vol.8, No.3, May 2017 LEAN THINKING IN SOFTWARE ENGINEERING : A SYSTEMATIC REVIEW Fernando Sambinelli 1and Marcos Augusto Francisco Borges 2 1Federal Institute of Education, Science and Technology of São Paulo, Hortolândia, Brazil 2School of Technology, University of Campinas, Limeira, Brazil ABSTRACT The field of Software Engineering has suffered considerable transformation in the last decades due to the influence of the philosophy of Lean Thinking. The purpose of this systematic review is to identify practices and approaches proposed by researchers in this area in the last 5 years, who have worked under the influence of this thinking. The search strategy brought together 549 studies, 80 of which were classified as relevant for synthesis in this review. Seventeen tools of Lean Thinking adapted to Software Engineering were catalogued, as well as 35 practices created for the development of software that has been influenced by this philosophy. The study provides a roadmap of results with the current state of the art and the identification of gaps pointing to opportunities for further research. KEYWORDS Lean Thinking, Lean IT, Agile, Software Engineering, Software Development, Systematic Review 1. INTRODUCTION Lean has been studied by researchers for almost half a century [1]. Publications in this field have increased considerably with an increasing number of industries trying to adopt this philosophy of work in its productive processes[2]. The term Lean emerged in the early 1980s when a quality gap was observed between Western and Japanese products, being most clearly noticed in the car manufacturing industry. The most comprehensive research on the differential features of Japanese productive methods was conducted by the International Motor Vehicle Program (IMVP) at the Massachusetts Institute of Technology (MIT) [3].
    [Show full text]