DOCSLIB.ORG

Developing Safety Critical Embedded Software Under DO-178C

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Developing Safety Critical Embedded Software Under DO-178C Developing Safety Critical Embedded Software under DO-178C A Thesis submitted to the Graduate School Of The University of Cincinnati In partial fulfillment of the requirements for the degree of Master of Science in the Department of Electrical and Computer Engineering of the College of Engineering and Applied Sciences November 2015 by Yanyun WANG Committee Chair: Dr. Carla Purdy i ABSTRACT Software installed on avionic equipment requires higher safety standards than any other environment. DO-178C, Software Consideration in Airborne Systems and Equipment Certification, proposed by Radio Technical Commission for Aeronautics (RTCA) and European Organization of Civil Aviation Equipment (EUROCAE), deals with the safety of software used in airborne systems. DO-178C was completed and approved by the RTCA in 2011 and replaces DO-178B as the primary document for Transport Canada, EASA and FAA. DO-178C defines the objectives and focuses on the procedures to produce software at a certain security / safety level. The inclusion of object-oriented concept and formal methods in DO-178C allows great flexibility of implementation. Most of the qualified software tools that can pass the certification process outlined in DO-178C are from big companies such as Matlab, AdaCore and IBM. The prohibitive price to enter the market makes it unaffordable for small business. The purpose of this research is to identify suitable open source software that can fulfill the same mission with minimal effort and cost while complying with the strict DO-178C standards. ii iii Table of Contents 1. INTRODUCTION...................................................................................................- 1 - 2. AVIONIC SYSTEM DEVELOPMENT REGULATIONS ..........................................- 5 - 2.1 ARP4761 ................................................................................................................- 5 - 2.2 ARP4754 ................................................................................................................- 6 - 2.3 DO-254...................................................................................................................- 6 - 2.4 History of DO-178 Family ........................................................................................- 8 - 2.5 DO-178B ................................................................................................................- 9 - 2.6 DO-178C .............................................................................................................. - 12 - 3. SOFTWARE DEVELOPMENT FOR DO-178C COMPLIANCE ............................. - 17 - 3.1 Software Planning ................................................................................................. - 19 - 3.2 Software Requirements ......................................................................................... - 22 - 3.3 Software Design .................................................................................................... - 23 - 3.4 Software Implementation and Integration............................................................... - 23 - 3.5 Software Validation............................................................................................... - 24 - 3.6 Software Verification............................................................................................. - 24 - 3.7 Delivery................................................................................................................ - 24 - 4. TOOLS ................................................................................................................ - 26 - 4.1 Tool Qualification ................................................................................................. - 26 - 4.1.1 Development tool qualification ............................................................................... - 27 - 4.1.2 Verification tool qualification ................................................................................. - 28 - 4.2 Potential Open Source Tool Chains ........................................................................ - 29 - 4.2.1 Life-cycle management .......................................................................................... - 30 - 4.2.2 Requirements management.................................................................................... - 32 - 4.2.3 Software design and implementation ...................................................................... - 37 - 4.2.4 Software testing .................................................................................................... - 38 - 4.2.5 Traceability management ...................................................................................... - 39 - 4.2.6 Team management ................................................................................................ - 41 - 4.2.7 User management ................................................................................................. - 42 - 4.2.8 Version control ..................................................................................................... - 43 - 4.2.9 Release management ............................................................................................. - 44 - 4.2.10 OSEE for DO-178C compliance ............................................................................. - 45 - iv 4.2.11 TOPCASED ......................................................................................................... - 46 - 4.2.12 CPPCheck ............................................................................................................ - 51 - 5. CASE STUDY: BLACKBOX DECODER PROJECT .............................................. - 52 - 6. CONCLUSIONS AND FUTURE WORK ............................................................... - 73 - References .......................................................................................................................... - 75 - Appendix A. TUTORIAL ................................................................................................ - 80 - v LIST OF FIGURES Figure 1 Avionic System Development Regulations ......................................................................- 5 - Figure 2 DO-178C Document Structure [34] .............................................................................. - 18 - Figure 3 Action Tracking System [70] for OSEE........................................................................... - 31 - Figure 4 Surgical Assistance Workstation (SAW) Architecture [71]................................................ - 32 - Figure 5 OSEE - Product Decomposition for SAW Project [71] ...................................................... - 33 - Figure 6 OSEE - Artifacts [72] .................................................................................................. - 34 - Figure 7 OSEE - Requirements [71] .......................................................................................... - 35 - Figure 8 OSEE - Robot API Requirements in Word Format [71]..................................................... - 36 - Figure 9 OSEE - TOPCASED Info Tracker [71] ............................................................................. - 37 - Figure 10 OSEE – Test Management [71] .................................................................................. - 38 - Figure 11 OSEE – Traceability [72] ........................................................................................... - 39 - Figure 12 OSEE – Skywalker [71] ............................................................................................. - 40 - Figure 13 OSEE - Team Management [71] ................................................................................. - 41 - Figure 14 OSEE - User Management [71] .................................................................................. - 42 - Figure 15 OSEE - Version Control [71] ...................................................................................... - 43 - Figure 16 OSEE - Release Management [71] .............................................................................. - 44 - Figure 17 Example Component Diagram [73] ............................................................................ - 47 - Figure 18 Example UML File [73] ............................................................................................. - 48 - Figure 19 UML Model Validation [73]....................................................................................... - 49 - Figure 20 Generating Code from UML Model [73]...................................................................... - 50 - Figure 21 CPPcheck Features [45]............................................................................................ - 51 - Figure 22 Shift Negative Value Warning ................................................................................... - 51 - Figure 23 Cleanflight Github Projects Overview [77]................................................................... - 52 - Figure 24 BlackBox Decoder Internal Flow ................................................................................ - 53 - Figure 25 Typical Header for Blackbox Log ................................................................................ - 55 - Figure 26 BlackBox Decoder Data ............................................................................................ - 56 - Figure 27 Case Study Diagram................................................................................................
Load more

Recommended publications
  • Test Driven .NET Development with Fitnesse
    Test Driven .NET Development with FitNesse second edition Gojko Adzic Test Driven .NET Development with FitNesse: second edition Gojko Adzic Copy-editor: Marjory Bisset Cover picture: Brian Samodra Published 2009 Copyright © 2008-2009 Neuri Limited Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where these designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author has taken care in the preparation of this book, but makes no expressed or implied warranty of any kind and assumes no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Neuri Limited 25 Southampton Buildings London WC2A 1AL United Kingdom You can also contact us by e-mail: [email protected] Register your book online Visit http://gojko.net/fitnesse and register your book online to get free PDF updates and notifications about corrections or future editions of this book. ISBN: 978-0-9556836-2-6 REVISION:2009-12-08 Preface to the second edition ........................................................... vii What's new in this version? ..................................................... vii Training and consultancy ................................................................ ix Acknowledgements ........................................................................
    [Show full text]
  • 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.
    [Show full text]
  • 2019 Stateof the Software Supply Chain
    2019 State of the Software Supply Chain The 5th annual report on global open source software development presented by in partnership with supported by Table of Contents Introduction................................................................................. 3 CHAPTER 4: Exemplary Dev Teams .................................26 4.1 The Enterprise Continues to Accelerate ...........................27 Infographic .................................................................................. 4 4.2 Analysis of 12,000 Large Enterprises ................................27 CHAPTER 1: Global Supply of Open Source .................5 4.3 Component Releases Make Up 85% of a Modern Application......................................... 28 1.1 Supply of Open Source is Massive ...........................................6 4.4 Characteristics of Exemplary 1.2 Supply of Open Source is Expanding Rapidly ..................7 Development Teams ................................................................... 29 1.3 Suppliers, Components and Releases ..................................7 4.5 Rewards for Exemplary Development Teams ..............34 CHAPTER 2: Global Demand for Open Source ..........8 CHAPTER 5: The Changing Landscape .......................35 2.1 Accelerating Demand for 5.1 Deming Emphasizes Building Quality In ...........................36 Open Source Libraries .....................................................................9 5.2 Tracing Vulnerable Component Release 2.2 Automated Pipelines and Downloads Across Software Supply Chains
    [Show full text]
  • Acceptance Testing Tools - a Different Perspective on Managing Requirements
    Acceptance Testing Tools - A different perspective on managing requirements Wolfgang Emmerich Professor of Distributed Computing University College London http://sse.cs.ucl.ac.uk Learning Objectives • Introduce the V-Model of quality assurance • Stress the importance of testing in terms of software engineering economics • Understand that acceptance tests are requirements specifications • Introduce acceptance and integration testing tools for Test Driven Development • Appreciate that automated acceptance tests are executable requirements specifications 2 V-Model in Distributed System Development Requirements Acceptance Test Software Integration Architecture Test Detailed System Design Test See: B. Boehm Guidelines for Verifying and Validating Software Unit Requirements and Design Code Specifications. Euro IFIP, P. A. Test Samet (editor), North-Holland Publishing Company, IFIP, 1979. 3 1 Traditional Software Development Requirements Acceptance Test Software Integration Architecture Test Detailed System Design Test Unit Code Test 4 Test Driven Development of Distributed Systems Use Cases/ User Stories Acceptance QoS Requirements Test Software Integration & Architecture System Test Detailed Unit Design Test These tests Code should be automated 5 Advantages of Test Driven Development • Early definition of acceptance tests reveals incomplete requirements • Early formalization of requirements into automated acceptance tests unearths ambiguities • Flaws in distributed software architectures (there often are many!) are discovered early • Unit tests become precise specifications • Early resolution improves productivity (see next slide) 6 2 Software Engineering Economics See: B. Boehm: Software Engineering Economics. Prentice Hall. 1981 7 An Example Consider an on-line car dealership User Story: • I first select a locale to determine the language shown at the user interface. I then select the SUV I want to buy.
    [Show full text]
  • Model-Based Fuzzing Using Symbolic Transition Systems
    Model-Based Fuzzing Using Symbolic Transition Systems Wouter Bohlken [email protected] January 31, 2021, 48 pages Academic supervisor: Dr. Ana-Maria Oprescu, [email protected] Daily supervisor: Dr. Machiel van der Bijl, [email protected] Host organisation: Axini, https://www.axini.com Universiteit van Amsterdam Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering http://www.software-engineering-amsterdam.nl Abstract As software is getting more complex, the need for thorough testing increases at the same rate. Model- Based Testing (MBT) is a technique for thorough functional testing. Model-Based Testing uses a formal definition of a program and automatically extracts test cases. While MBT is useful for functional testing, non-functional security testing is not covered in this approach. Software vulnerabilities, when exploited, can lead to serious damage in industry. Finding flaws in software is a complicated, laborious, and ex- pensive task, therefore, automated security testing is of high relevance. Fuzzing is one of the most popular and effective techniques for automatically detecting vulnerabilities in software. Many differ- ent fuzzing approaches have been developed in recent years. Research has shown that there is no single fuzzer that works best on all types of software, and different fuzzers should be used for different purposes. In this research, we conducted a systematic review of state-of-the-art fuzzers and composed a list of candidate fuzzers that can be combined with MBT. We present two approaches on how to combine these two techniques: offline and online. An offline approach fully utilizes an existing fuzzer and automatically extracts relevant information from a model, which is then used for fuzzing.
    [Show full text]
  • An Analysis of Current Guidance in the Certification of Airborne Software
    An Analysis of Current Guidance in the Certification of Airborne Software by Ryan Erwin Berk B.S., Mathematics I Massachusetts Institute of Technology, 2002 B.S., Management Science I Massachusetts Institute of Technology, 2002 Submitted to the System Design and Management Program In Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management at the ARCHIVES MASSACHUSETrS INS E. MASSACHUSETTS INSTITUTE OF TECHNOLOGY OF TECHNOLOGY June 2009 SEP 2 3 2009 © 2009 Ryan Erwin Berk LIBRARIES All Rights Reserved The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created. Signature of Author Ryan Erwin Berk / System Design & Management Program May 8, 2009 Certified by _ Nancy Leveson Thesis Supervisor Professor of Aeronautics and Astronautics pm-m A 11A Professor of Engineering Systems Accepted by _ Patrick Hale Director System Design and Management Program This page is intentionally left blank. An Analysis of Current Guidance in the Certification of Airborne Software by Ryan Erwin Berk Submitted to the System Design and Management Program on May 8, 2009 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering and Management ABSTRACT The use of software in commercial aviation has expanded over the last two decades, moving from commercial passenger transport down into single-engine piston aircraft. The most comprehensive and recent official guidance on software certification guidelines was approved in 1992 as DO-178B, before the widespread use of object-oriented design and complex aircraft systems integration in general aviation (GA).
    [Show full text]
  • Before You Continue
    NASA/CR–2015-218982 Application of SAE ARP4754A to Flight Critical Systems Eric M. Peterson Electron International II, Inc., Phoenix, Arizona November 2015 NASA STI Program . in Profile Since its founding, NASA has been dedicated to the CONFERENCE PUBLICATION. advancement of aeronautics and space science. The Collected papers from scientific and technical NASA scientific and technical information (STI) conferences, symposia, seminars, or other program plays a key part in helping NASA maintain meetings sponsored or this important role. co-sponsored by NASA. The NASA STI program operates under the auspices SPECIAL PUBLICATION. Scientific, of the Agency Chief Information Officer. It collects, technical, or historical information from NASA organizes, provides for archiving, and disseminates programs, projects, and missions, often NASA’s STI. The NASA STI program provides access concerned with subjects having substantial to the NTRS Registered and its public interface, the public interest. NASA Technical Reports Server, thus providing one of the largest collections of aeronautical and space TECHNICAL TRANSLATION. science STI in the world. Results are published in both English-language translations of foreign non-NASA channels and by NASA in the NASA STI scientific and technical material pertinent to Report Series, which includes the following report NASA’s mission. types: Specialized services also include organizing TECHNICAL PUBLICATION. Reports of and publishing research results, distributing completed research or a major significant phase of specialized research announcements and feeds, research that present the results of NASA providing information desk and personal search Programs and include extensive data or theoretical support, and enabling data exchange services. analysis. Includes compilations of significant scientific and technical data and information For more information about the NASA STI program, deemed to be of continuing reference value.
    [Show full text]
  • Quality Assurance, Process Engineer
    THOMMEN AIRCRAFT EQUIPMENT Renowned Swiss manufacturer of high precision Aviation Instruments, Air Data Computers, Digital Chronometers and Mission Equipment Established in 1853 under Revue Thommen AG, Thommen Aircraft Equipment Ltd is a renowned Swiss manufacturer of high precision aviation instruments, avionics and mission equipment. The company has celebrated its 100 years anniversary of supplying aviation products to its customers. Thommen Aircraft Equipment AG is currently in the phase of introducing several innovative and exciting products to the market and will gradually increase the general product offering in the course of 2018/2019. To sustain the new company plans, product development, we are looking to hire a skilled and experienced Quality Assurance / Process Engineer – Avionics 100% (m/f) The person will be responsible for leading activities involving Product Lifecycle Management processes. Focused on improving processes and tools, the position is ideal for a candidate seeking a broad technical and business process career. The position offers the opportunity to work as part of a global team which will require flexibility to support activities across multiple time zones for following process development activities. Our culture is to hire only the finest talent and to uphold our values of teamwork, accountability, humor, efficiency, candor and continual improvement. Responsibilities & Tasks • Develop DO-178C and DO-254 process compliance and quality plan, (QAP, SQAP HQAP) • Responsible for reporting assessment and evaluation
    [Show full text]
  • Acceptance Testing How Cslim and Fitnesse Can Help You Test Your Embedded System
    Acceptance Testing How CSlim and FitNesse Can Help You Test Your Embedded System Doug Bradbury Software Craftsman, 8th Light Tutorial Environment git clone git://github.com/dougbradbury/c_learning.git cd c_learning ./bootstrap.sh or with a live CD: cp -R cslim_agile_package c_clearning cd c_learning git pull ./bootstrap.sh Overview Talk w/ exercises: Acceptance Tests Tutorial: Writing Acceptance tests Tutorial: Fitnesse Tutorial: CSlim Talk: Embedded Systems Integration Bonus Topics Introductions Who are you? Where do you work? What experience do you have with ... embedded systems? acceptance testing? FitNesse and Slim? Objectives As a result of this course you will be able to: Understand the purposes of acceptance testing; Use acceptance tests to define and negotiate scope on embedded systems projects; Integrate a CSlim Server into your embedded systems; Objectives (cont) As a result of this course you will be able to: Add CSlim fixtures to your embedded system; Write Fitnesse tests to drive the execution of CSlim fixtures; Write and maintain suites of tests in a responsible manner. Points on a star How many points does this star have? Star Point Specification Points on a star are counted by the number of exterior points. Points on a star How many points does this star have? By Example 3 5 9 Points on a star Now, how many points does this star have? Robo-draw Pick a partner ... Acceptance Testing Collaboratively producing examples of what a piece of software is supposed to do Unit Tests help you build the code right. Acceptance Tests
    [Show full text]
  • 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.
    [Show full text]
  • Order No. 31310019F0149 Under Contract No. GS35F192BA
    2 of 27 19. 20. 21. 22. 23. 24. ITEM NO. SCHEDULE OF SUPPLIES/SERVICES QUANTITY UNIT UNIT PRICE AMOUNT Funded: $702,432.93 Accounting Info: Funded: $40,981.86 Accounting Info: Funded: $347,917.46 10001 Option Period 1 Ceiling Price 0.00 See Attachment 1 for Authorized Labor Categories and Fixed Hourly Rates Amount: $1,059,977.13(Option Line Item) Anticipated Exercise Date09/30/2020 Period of Performance: 10/01/2020 to 09/30/2021 20001 Option Period 2 Ceiling Price 0.00 See Attachment 1 for Authorized Labor Categories and Fixed Hourly Rates Amount: $847,176.84(Option Line Item) Anticipated Exercise Date09/30/2021 Period of Performance: 10/01/2021 to 09/30/2022 The obligated amount of award: $1,091,332.25. The total for this award is shown in box 26. 32a. QUANTITY IN COLUMN 21 HAS BEEN RECEIVED INSPECTED ACCEPTED, AND CONFORMS TO THE CONTRACT, EXCEPT AS NOTED: 32b. SIGNATURE OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32c. DATE 32d. PRINTED NAME AND TITLE OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32e. MA LING ADDRESS OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32f. TELEPHONE NUMBER OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32g. E-MA L OF AUTHORIZED GOVERNMENT REPRESENTATIVE 33. SHIP NUMBER 34. VOUCHER NUMBER 35. AMOUNT VERIFIED 36. PAYMENT 37. CHECK NUMBER CORRECT FOR COMPLETE PARTIAL FINAL PARTIAL FINAL 38. S/R ACCOUNT NUMBER 39. S/R VOUCHER NUMBER 40. PAID BY 41a. I CERTIFY THIS ACCOUNT IS CORRECT AND PROPER FOR PAYMENT 42a. RECEIVED BY (Print) 41b. SIGNATURE AND TITLE OF CERTIFY NG OFFICER 41c. DATE 42b. RECEIVED AT (Location) 42c.
    [Show full text]
  • Software Development Lifecycle (Sdlc) Models & Agile Methods
    sdlc% how did that happen? software development lifecycle (sdlc) models & agile methods • by analogy with civil engineering, where you design first, then do construction • in software, there is no “construction” it’s all design • used to be called coding sdlc%(2)% sdlc%(3)% • what is a software development process? • what is the lifecycle of a software project? • will talk about “agile” later. first, we’ll talk about “disciplined” or is it “traditional?” or is it “sturdy?” or is it “planned?” or is it… sdlc%(4)% example%feature%workflow% • tend to talk about sdlc in terms of a dichotomy – !“agile”!vs.!well…um…“not!agile”! – or,!“planned”!vs.!“con8nuous”! – others!tend!to!(incorrectly)!think!that!the! deployment!method!implies!the!process! • saas!==!agile! • installed!==!tradi8onal! • think more in terms applying the process on an individual feature, or an aggregate goal%of%sdlc% waterfall% Requirements! Design! Construc8on! • what’s the goal of a good sdlc? Integra8on! – passes!all!the!tests!(external!quality!aAriButes)! Debugging! – good!design/architecture!(internal)! Installa8on! Maintenance! – good!user!experience!(quality!in!use)! • move from one phase to the next only when its preceding phase is – process!quality!(can!process!help!ensure! completed and perfected. product!quality)! • first mentioned by Royce in 1970 as an example of a flawed, non- working model for software development. • US department of defence projects attempted to entrench this model by requiring their contractors to produce the waterfall deliverables and then to formally accept them to a certain schedule (US military standard DoD-2167) – there!was!a!unwieldy!process!for!going!Back!and!amending!previous! deliverables! waterfall%(2)% waterfall%(3)% more problems problems • static view of requirements – ignores volatility • lack of user involvement once specification is written • unrealistic separation of specification from design • often tracked with Gantt charts! • doesn’t easily accommodate prototyping, – printed!and!taped!up!on!the!wall! reuse, etc.
    [Show full text]