Why can’t engineering good software be like building a house? Steve Cross cross@gatech. edu November 17, 2004
What I’d like to share with you • Background – History, state of practice • Analogy – SWE should be more like designing and building a house • 3 key ideas – Process – do the work right the first time – Architecture – design and engineering analysis before coding – Reuse – leverage investment engineered assets + experience • Summary
A Brief History of Software Engineering 1968, the term “software engineering” first used 1990’s 1980’s 1970’s 1960’s 1950’s High Order Languages Tools Emphasis on cycle time Emphasis on quality Emphasis on productivity 2000’s?
State of practice Right Product Built Badly needs Wrong Product Built Well (i. e. , most projects so classified) Requirements (and on cost, on schedule, etc. ) Wrong Product Built Badly Implementation Right Product Built Well (e. g. , buffer overflows are the most common vulnerability exploited in internet attacks) Code (e. g. , the ‘require-delay-surprise’ phenomena) Design analysis
A serious implication of shoddy designs and coding practices • • Viruses Worms Identity theft etc, etc
Leading Culprit - Buffer Overflows http: //www. cert. org/homeusers/buffer_overflow. html
Critical Need for Better Software Vulnerabilities Reported to CERT/CC
Data from 1, 500 Software Projects canceled before completion 53% Projects completed on time and on budget Projects late and over budget 23% 28% 49% 31% • Average cost growth exceeds 89% • The average final product contains 61% of the originally specified features Ref: Standish Group, CHAOS Study, Summer 2001.
Lots of bad products built badly The public is beginning to understand that poor quality software is the cause of many problems. Reference: Cover of 12/6/1999 business week, www. businessweek. com
Reasons Why Projects Fail • • • Project objectives not understood Bad planning and estimating Technology new to the organization Inadequate/no project management Methodology Insufficient senior staff on the team Ref: Robert Glass, Software Runaways, Prentice Hall, Inc. , ISBN 0 -13 -673443, 1998.
Would you design and build a house the way you do software? Before what is needed
What we hope we will get
… and what we get
Analogies between houses and software engineering Feature House Software Architecture Blueprints Architecture Description Languages (e. g. , UML) Standards Building Codes “Technical View” (e. g. , J 2 EE) Construction Method Assembly of prefabricated components Assembly of objects and other reusable software modules Process Skilled craftspeople following a production plan Experienced team (e. g. , architect, designer, coders, testers) following defined Physics N/A (e. g. , use of iterative (e. g. , structural analysis) approaches to gain experience) A housing subdivision A product line First Principles Leveraged investment ways of work (e. g. , cell phones, printers)
Key Idea #1: Process (compiled individual and team experience) A software process is a set of activities, methods, and practices that people employ to develop and maintain software and associated products (e. g. , project plans, design documents, test cases, documentation) A process model (e. g. , the Capability Maturity Model ® or CMMI ® ) is a collection of process descriptions and an embedded approach for assessment and continuous improvement ® Capability Maturity Model, CMM, and CMMI are registered in the U. S. Patent and Trademark Office by Carnegie Mellon University
Many process modeling approaches • • CMM®, CMMISM PSP, TSP Agile approaches Other process models Key point capture, use, and improve experience ® CMM is registered in the U. S. Patent and Trademark Office by Carnegie Mellon University. SMCMMI SMPSP is a service mark of Carnegie Mellon University. and TSP are service marks of Carnegie Mellon University
Capability Maturity Models (models of engineering organizations)
Process models came form manufacturing – e. g. , Crosby’s Quality Management Maturity Grid Manageme nt Categories Cost of quality as % of sales Stage 1: Uncertaint y Reported: unknown Actual: Summatio 20% don’t “We n of know why company we have quality posture problems. ” Stage 2: Stage 3: Awakening Enlightenme nt Reported: 5% 8% Actual: 12% 18% we “We are “Must always have quality problems? ” identifying and resolving our quality problems. ” Stage 4: Wisdom Stage 5: Certainty Reported : 6. 5% Actual: 8% “We Reported: 2. 5% Actual: 2. 5%know “We routinely prevent defects from occurring. ” why we don’t have quality problems. ” Ref: Crosby, P. Quality is Free: The Art of Making Quality Certain. New York: Mc. Graw-Hill, 1979.
Improvement Focus at Each Maturity Level
Average Number of Defects/Kloc Post-Release Defects 15 10 5 0 Level 1 Level 2 level 3 Time (Based on 120 projects in Ref: Griffin, Scott (Boeing CIO). “Software Process Improvement Journey: Boeing Information Systems) From Level 1 to Level 5. ” SEPG Conference, Seattle WA (USA), March 2000.
Cycle Time Average Number of Hours 100 80 60 36% Faster 40 20 0 Level 1 Level 2 level 3 Time (Based on 120 projects in Ref: Griffin, Scott (Boeing CIO). “Software Process Improvement Journey: Boeing Information Systems) From Level 1 to Level 5. ” SEPG Conference, Seattle WA (USA), March 2000.
Percent of Staff Support per System Productivity 100 - 12% 75 Increased Productivity - 26% - 38% 50 - 62% 25 Reduced Staff Support per System = Increased Productivity 0 1992 Level 1 1993 1994 Level 2 1995 1996 Level 3 Ref: Griffin, Scott (Boeing CIO). “Software Process Improvement Journey: From Level 1 to Level 5. ” SEPG Conference, Seattle WA (USA), March 2000.
In contrast, how fast can one (design and) build a good house? Start at t 0 Building t 0 + 2 hrs 45 min Industry Association, San Diego, CA, 1997.
Key Idea #2: Architecture Definition: A software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, the relationships among them, and the documentation to describe it all. Explicit modeling of the architecture permits analysis of a design before coding and test Ref: Bass, Clements, Kazman. Software Architecture in Practice (2 nd edition), Addison-Wesley, 2003.
Systems, models, and views • Model – Abstraction describing a system or subsystem • View – Selected aspects of a model • Notation – Set of rules for representing views
Systems, models, and views Blueprint s Electronic Drawings (plumbing) Blueprint s (room layout) View 1 Model 2 View 3 Blueprint s (wiring) Scale Model House System
Move towards notation that allows exploration of static and dynamic behaviors System Model described by View depicted by House: system Model 1: electronic drawings Model 2: scale model View 1: room layout View 2: wiring diagram View 3: plumbing
Constrains Operational View identifies what needs to be accomplished and who does it Technical View Some key points about architecture (1) centered design Note: others use different terminology to describe “views” – see Krutchen’s “ 4+1 views” paper (2) prescribes standards and conventions Attribute Analysis Generated from OV and TV Systems View relates systems and characteristics to operational needs Repository (components, modules) • From component library • Newly prototyped components build/integrate, test References: Actual System (1) “Do. D Architecture Framework Working Group, Do. D Architecture Framework, Version 1. 0, Volume I: Definitions and Guidelines, ” February 2004 (2) Krutchen, P. “Architectural Blueprints – the “ 4+1” Model of Software Architecture, IEEE Software, Nov. 1995, p. 42 -50, also at www 3. software. ibm. com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk 4 p 1. pdf
Structured English to XML mappings Narrative Form Use Cases Constrains What ifs by end-users Operational View identifies what needs to be accomplished and who does it Technical View Qualitative assessments Quantitative measurements prescribes standards and conventions Attribute Analysis Generated from OA and TA Systems View relates systems and characteristics to operational needs Simulation Environment Executable Architecture Rapid Composability Repository (components, modules) build/integrate, test Actual System • Role played by humans or agents • From component library • Newly prototyped components
Analogies between houses and software engineering Feature House Software Architecture Blueprints Architecture Description Languages (e. g. , UML) Standards Building Codes “Technical View” (e. g. , J 2 EE) Construction Method Assembly of prefabricated components Assembly of objects and other reusable software modules Process Skilled craftspeople following a production plan Experienced team (e. g. , architect, designer, coders, testers) following defined Physics N/A (e. g. , use of iterative (e. g. , structural analysis) approaches to gain experience) A housing subdivision A product line First Principles Leveraged investment ways of work (e. g. , cell phones, printers)
Myth: it is easy to build a system from components - just assemble it
Components everywhere but no help in how to assemble them into a system
OK, now what do I do? “How To” Book Duct Tape Goof Off
Idea #3: Reuse Everything Use of a common asset base Architecture in production Plan of a related set of products Scope Definition Business Case
Putting it all together Domain Understanding • Understanding Relevant Domains feeds Requirements drive Architecture Definition Architecture Evaluation Architecture specifies components Make/Buy/Mine/Commission Analysis Make Buy Mine Commission Component Development COTS Utilization Mining Existing Assets [Developing an Acquisition Strategy] Software System Integration Components Testing
In summary - Design in Quality! Software state of practice (“test in” quality) 60 - 80 % of effort and cost* Development Integration and System Test World-class developers “design in” quality Predictable and improved cost, schedule, and quality Ref: Standish Group, CHAOS Report, 2001.
Parting thought • Software engineering is hard work • The expectation of outputs from our profession should be at least as high as the building trades
Some other references • Clements, P. , Bachmann, F. , Bass, L. , Garlan, D. , Ivers, J. , Little, R. , Nord, R. , and Stafford, J. (2002). Documenting Software Architectures: Views and Beyond, Reading (MA): Addison-Wesley. • Clements, P. , Kazman, R. , and Klein, M. (2001). Evaluating Software Architectures: Methods and Case Studies. Reading (MA): Addison-Wesley. • Clements, P. and Northrop, L. (2001). Software Product Lines: Practices and Patterns, Reading (MA): Addison -Wesley. • Cross, S. (2002). “Reflections on the Process Revolution, ” IEEE Tutorial on Software Management, 6 th Edition, Reifer, D (Ed). • Haeckel, S. (1999). Adaptive Enterprise: Creating and Leading Sense-and-Respond Organizations, Boston: Harvard Business School Press • Kotter, J. and Cohen, D. (2002). The Heart of Change, Boston: Harvard Business School Press. • Mac. Millan, P. (2001). The Performance Factor: Unlocking the Secrets of Teamwork, Nashville: Broadman & Holman Publishers. • Royce, W. (1998). Software Project Management: A Unified Framework, Reading (MA): Addison-Wesley. • Smith, H. and Fingar, P. (2003). Business Process Management: The Third Wave. Tampa: Meghan-Kiffer Press. • Web sites • • • IEEE Software Magazine Object Management Group Software Engineering Institute UML, papers on Workflow Management Coalition www. computer. org/software www. omg. org www. sei. cmu. edu www. rspa. com/reflib/UMLRelated. Materials. html www. wfmc. org
Скачать презентацию Why can t engineering good software be like building
9919e9faeeb756f7f8c356c7686b3bb9.ppt