1 / 97

Software Engineering: Overview of Selby/Boehm book

Software Engineering: Overview of Selby/Boehm book. Barry Boehm, USC CS 510 Fall 2011 boehm@usc.edu http://csse.usc.edu. Outline. What have we learned? (chapter 8) Some book highlights People and values (chapters 7, 9) Economics (chapters 2, 3) Processes (chapters 4, 6)

tahmores
Télécharger la présentation

Software Engineering: Overview of Selby/Boehm book

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering:Overview of Selby/Boehm book Barry Boehm, USC CS 510 Fall 2011 boehm@usc.edu http://csse.usc.edu

  2. Outline • What have we learned? (chapter 8) • Some book highlights • People and values (chapters 7, 9) • Economics (chapters 2, 3) • Processes (chapters 4, 6) • Risk Management (chapter 5) • Top-10 lists (chapter 1) • Where are we going? (chapter 10) ©USC-CSSE

  3. A Hegelian View of Software Engineering Evolution ©USC-CSSE

  4. 1950’s Thesis: Engineer Software Like Hardware • Hardware-oriented: • Software applications: airplanes, bridges, circuits • Economics: Boehm supervisor, 1955 • “We’re paying $600/hour for that computer, and $2/hour for you, and I want you to act accordingly.” • Professional Societies: Association for Computing Machinery, IEEE Computer Society • Software Processes: SAGE (Semi-Automated Ground Environment) • 1 MLOC air defense system, real-time, user-intensive • Successful development of highly unprecedented system • Hardware-oriented waterfall-type process ©USC-CSSE

  5. The SAGE Software Development Process - (Benington, 1956)“We were successful because we were all engineers”. ©USC-CSSE

  6. 1960’s Antithesis: Software Is Not Like Hardware- Four Brooks factors plus two • Invisibility: like the Emperor’s Magic Cloth • Complexity: Royce, “for a $5M procurement, need a 30-page spec for hardware, and a 1500-page spec for software” • Conformity: executed by computers, not people • Changeability: up to a point, then becomes difficult • Doesn’t wear out: different reliability, maintenance phenomena • Unconstrained: can program antigravity, time travel, interpenetration, … ©USC-CSSE

  7. 1960’s Antithesis: Software Crafting • Flexible materials, frequent changes as above • SW demand exceeded supply of engineers • Music, history, art majors • Counter culture: question authority • Cowboy programmers as heroes • Code-and-fix process • Hacker culture (Levy, 1984) • Collective code ownership • Free software, data, computing access • Judge programmers by the elegance of their code ©USC-CSSE

  8. 1960’s Progress and Problems • Better infrastructure: OS, compilers, utilities • Computer Science Departments • Product Families: OS-360, CAD/CAM, math/statistics libraries • Some large successes: Apollo, ESS, BofA check processing • Problems: 1968, 1969 NATO Reports • Failure of most large systems • Unmaintainable spaghetti code • Unreliable, undiagnosable systems ©USC-CSSE

  9. 1970’s Antithesis: Formal and Waterfall Approaches • Structured Methods • Structured programming (Bohm-Jacopini: GO TO unnecessary) • Formal programming calculus: Dijkstra, Hoare, Floyd • Formalized Top-Down SP: Mills, Baker • Waterfall Methods • Code and fix too expensive (100:1 for large systems) • Precede code by design (De Marco SD, Jackson JSD/JSP) • Precede design by requirements (PSL/PSA, SA, SREM) ©USC-CSSE

  10. The Royce Waterfall Model (1970)- Explicit feedback- “Do it twice” ©USC-CSSE

  11. • • • • Increase in Software Cost-to-fix vs. Phase (1976) 1000 1000 Larger Software Projects 500 500 IBM-SSD GTE 200 200 • 100 100 Relative cost to fix defect Relative cost to fix defect 80% • • • • Median (TRW Survey) 50 50 20% SAFEGUARD • • 20 20 • • Smaller Software Projects 10 10 • • 5 5 • • 2 2 1 1 Requirements Design Code Development Requirements Design Code Development Acceptance Operation Acceptance Operation test test test test Phase in Which defect was fixed Phase in Which defect was fixed ©USC-CSSE

  12. 1970’s: Problems with Formal Methods • Successful for small, critical programs • Largest proven programs around 10 KSLOC • Proofs show presence of defects, not absence • Defects in specification, proofs happen • Scalability of programmer community • Techniques require math expertise, $500/SLOC • Average coder in 1975 survey: • 2 years of college, SW experience • Familiar with 2 languages, applications • Sloppy, inflexible, in over his head, and undermanaged ©USC-CSSE

  13. A Hegelian View of Software Engineering Evolution ©USC-CSSE

  14. Reuse and Object Orientation • 1950’s: Math routines, utilities • 1960’s: McIlroy component marketplace, Simula – 67 • 1970’s: Abstract data types, Parnas program families • 1980’s: Smalltalk, Eiffel, C++, OO methods, reuse libraries • 1990’s: Domain engineering, product lines, UML, pub-sub architectures • 2000’s: Model driven development, service oriented architectures ©USC-CSSE

  15. HP Product Line Reuse Investment and Payoff ©USC-CSSE

  16. People: The Most Important Factor- SW engineering is of the people, by the people, and for the people • 1970’s: Weinberg Psychology of Computer Programming • 1980’s: COCOMO factor-of-10, Scandinavian Participatory Design, DeMarco-Lister Peopleware • 1990’s – 2000’s: Importance emphasized in both Agile and CMM cultures • Individuals and interactions over process and tools • People CMM, Personal Software Process • Overall migration from Reductionism toward Postmodernism (Toulmin) • Universal towards Local • General towards Particular • Timeless towards Timely • Written towards Oral ©USC-CSSE

  17. Dual 1990’s – Early 2000’s Antithesis:- Maturity Models and Agile Methods • Predictability and Control: Maturity Models • Reliance on explicit documented knowledge • Heavyweight but verifiable, scalable • Time to Market and Rapid Change: Agile Methods • Reliance on interpersonal tacit knowledge • Lightweight, adaptable, not very scalable ©USC-CSSE

  18. Agile and Plan-Driven Home Grounds: Five Critical Decision Factors • Size, Criticality, Dynamism, Personnel, Culture Personnel (% Level 1B) (% Level 2&3) 40 15 20 30 20 25 Dynamism(% Requirements – change/month) Criticality (Loss due to impact of defects) 10 30 a: Many Livesb: Single Lifec: Essential Fundsd: Discretionary Fundse: Comfort a b 0 35 0.3 c 1.0 d e 3.0 10 30 3 Agile 90 10 70 30 Plan-driven 50 100 30 300 10 Size(# of personnel) Culture(% thriving on chaos vs. order) ©USC-CSSE

  19. COTS: The Future Is Here • Escalate COTS priorities for research, staffing, education • Software is not “all about programming” anymore • New processes required * • CBA: COTS-Based Application • * Standish Group CHAOS 2000 (54%) ©USC-CSSE

  20. Persistence of Legacy Systems 1939’s Science Fiction World of 2000 Actual World of 2000 • Before establishing new-system increments • Determine how to undo legacy system ©USC-CSSE

  21. Outline • What have we learned? (chapter 8) • Some book highlights • People and values (chapters 7, 9) • Economics (chapters 2, 3) • Processes (chapters 4, 6) • Risk Management (chapter 5) • Top-10 lists (chapter 1) • Where are we going? (chapter 10) ©USC-CSSE

  22. People and Values:Software Engineering Is Of, By, and For the People • Of the people • People invest in software with an expectation of a valuable return • By the people • Software is developed by people • For the people • People use the software to generate value • All are success-critical stakeholders • As are system administrators, interoperators, and often the general public ©USC-CSSE

  23. Theory W: Enterprise Success Theorem– And informal proof Theorem: Your enterprise will succeed if and only if it makes winners of your success-critical stakeholders • Proof of “if”: Everyone that counts is a winner. Nobody significant is left to complain. • Proof of “only if”: Nobody wants to lose.Prospective losers will refuse to participate, or will counterattack.The usual result is lose-lose. ©USC-CSSE

  24. Theory W: WinWin Achievement Theorem Making winners of your success-critical stakeholders requires: • Identifying all of the success-critical stakeholders (SCSs). • Understanding how the SCSs want to win. • Having the SCSs negotiate a win-win set of product and process plans. • Controlling progress toward SCS win-win realization, including adaptation to change. ©USC-CSSE

  25. Initial VBSE Theory: 4+1- with Apurva Jain • Engine: Theory W (stakeholder win-win): What values are important? • Enterprise Success Theorem • Theory of Justice • Win-Win Equilibrium and Negotiation • Four Supporting Theories • Utility Theory: How important are the values? • Multi-attribute utility; Maslow need hierarchy • Decision Theory: How do values determine decisions? • Investment theory; game theory; statistical decision theory • Dependency Theory: How do dependencies affect value realization? • Results chains; value chains; cost/schedule/performance tradeoffs • Control Theory: How to monitor and control value realization • Feedback control; adaptive control; spiral risk control ©USC-CSSE

  26. Initial VBSE Theory: 4+1 Process– With a great deal of concurrency and backtracking ©USC-CSSE

  27. The Model-Clash Spider Web: Master Net - Stakeholder value propositions (win conditions) ©USC-CSSE

  28. EasyWinWin OnLine Negotiation Steps ©USC-CSSE

  29. Red cells indicate lack of consensus. Oral discussion of cell graph reveals unshared information, unnoticed assumptions, hidden issues, constraints, etc. ©USC-CSSE

  30. $100M Required Architecture: Custom; many cache processors $50M Original Architecture: Modified Client-Server Original Cost Original Spec After Prototyping 5 3 1 2 4 Response Time (sec) Expectations Management:Unaffordable Response Time ©USC-CSSE

  31. Economics (Chapters 2, 3) • COCOMO II and importance of people factors • Composite factor-of-10 influence • Economics of software productivity and reuse • Product line return on investment model (COPLIMO) • Realized growth of software productivity • Systems engineering return on investment • How much architecting is enough? ©USC-CSSE

  32. COCOMO II. 2000 Productivity Ranges Scale Factor Ranges: 10, 100, 1000 KSLOC e.g., for RESL: 1.18, 1.38, 1.63 Development Flexibility (FLEX) Team Cohesion (TEAM) Develop for Reuse (RUSE) Precedentedness (PREC) Architecture and Risk Resolution (RESL) Platform Experience (PEXP) Data Base Size (DATA) Required Development Schedule (SCED) Language and Tools Experience (LTEX) Process Maturity (PMAT) Storage Constraint (STOR) Use of Software Tools (TOOL) Platform Volatility (PVOL) Applications Experience (AEXP) Multi-Site Development (SITE) Documentation Match to Life Cycle Needs (DOCU) Required Software Reliability (RELY) Personnel Continuity (PCON) Time Constraint (TIME) Programmer Capability (PCAP) Analyst Capability (ACAP) Product Complexity (CPLX) 1 1.2 1.4 1.6 1.8 2 2.2 2.4 Productivity Range ©USC-CSSE

  33. The COPLIMO Model • Constructive Product Line Investment Model • Based on COCOMO II software cost model • Statistically calibrated to 161 projects, representing 18 diverse organizations • Based on standard software reuse economic terms • RCR: Relative cost of reuse • RCWR: Relative cost of writing for reuse • Avoids overestimation • Avoids RCWR for non-reused components • Adds life cycle cost savings • Provides experience-based default parameter values • Simple Excel spreadsheet model • Easy to modify, extend, interoperate ©USC-CSSE

  34. ©USC-CSSE

  35. Usual Hardware-Software Trend Comparison • Different counting rules • Try counting software as Lines of Code in Service (LOCS) =  (#platforms) * (#object LOCS/platform) Log N New transistors in service/year HW SW New Source Lines of Code/year Time ©USC-CSSE

  36. Lines of Code in Service: U.S. Dept. of Defense ©USC-CSSE

  37. Software Productivity Trends - Bernstein ©USC-CSSE

  38. ROI of Systems Engineering • Strong evidence of systems engineering ROI for software projects • Using architecture and risk resolution as proxy • No comparable evidence for hardware-software projects • Useful in determining how much architecting is enough • Less Big Design Up Front for small agile projects • Considerably more for very large projects • Analysis used to reschedule > 10,000 KSLOC projects • How much may vary with other factors • More for high assurance; less for rapid change ©USC-CSSE

  39. RESL Ratings for 161 Projects in the COCOMO Database ©USC-CSSE

  40. COCOMO II RESL Calibration • Regression analysis: 23 factors, 161 data points • Size range: 2.6 – 1,300 KSLOC; 5 above 1,000 KSLOC • Overall Pred(.30) = 75% • 80% with local calibration • Effect of RESL: range of .0707 in exponent increase • Statistically significant: t-value = 2.08 • Independent of other 22 factors ©USC-CSSE

  41. Effect of Scale on ROI ©USC-CSSE

  42. 10000 KSLOC Sweet Spot 100 KSLOC Sweet Spot Drivers: Rapid Change: leftward High Assurance: rightward 10 KSLOC How Much Architecting is Enough? Percent of Project Schedule Devoted to Initial Architecture and Risk Resolution Added Schedule Devoted to Rework (COCOMO II RESL factor) Total % Added Schedule ©USC-CSSE

  43. Processes (Chapters 4, 6) • Waterfall, V-model problems • 1-second response time case study above • Overdone separation of concerns • Spiral model problems • Getting started: Win-Win Spiral Model • Intermediate milestones • Too easy to misinterpret • Incremental Commitment Model • Based on underlying process principles • Principles can strengthen waterfall, V, RUP, spiral models ©USC-CSSE

  44. The “Separation of Concerns” Legacy “The notion of ‘user’ cannot be precisely defined, and therefore has no place in CS or SE.” • Edsger Dijkstra, ICSE 4, 1979 “Analysis and allocation of the system requirements is not the responsibility of the SE group but is a prerequisite for their work.” • Mark Paulk at al., SEI Software CMM* v.1.1, 1993 * Capability Maturity Model ©USC-CSSE

  45. I wonder when they'll give us our requirements? SOFTWARE AERO. ELEC. G & C MGMT. MFG. COMM PAYLOAD Resulting Project Social Structure

  46. From the Spiral Model to the ICM • Need for intermediate milestones • Anchor Point Milestones (1996) • Avoid stakeholder success model clashes • WinWin Spiral Model (1998) • Avoid model misinterpretations • Essentials and variants (2000-2005) • Clarify usage in DoDI 5000.2 • Initial phased version (2005) • Explain SoS spiral usage to GAO • Underlying spiral principles (2006) • Provide framework for human-systems integration • National Research Council report (2007) ©USC-CSSE

  47. Life Cycle Anchor Points • Common System/Software stakeholder commitment points • Defined in concert with Government, industry affiliates • Coordinated with Rational’s Unified Software Development Process • Life Cycle Objectives (LCO) • Stakeholders’ commitment to support system architecting • Like getting engaged • Life Cycle Architecture (LCA) • Stakeholders’ commitment to support full life cycle • Like getting married • Incremental Operational Capabilities (OCs) • Stakeholders’ commitment to support operations • Like having children ©USC-CSSE

  48. (Risk-driven level of detail for each element) Milestone Element Life Cycle Objectives (LCO) Life Cycle Architecture (LCA) • Top-level system objectives and scope • - System boundary • - Environment parameters and assumptions • - Evolution parameters • Operational concept • - Operations and maintenance scenarios and parameters • - Organizational life-cycle responsibilities (stakeholders) • Elaboration of system objectives and scope of increment • Elaboration of operational concept by increment Definition of Operational Concept • Exercise key usage scenarios • Resolve critical risks • Exercise range of usage scenarios • Resolve major outstanding risks System Prototype(s) • Top-level functions, interfaces, quality attribute levels, • including: • - Growth vectors and priorities • - Prototypes • Stakeholders’ concurrence on essentials • Elaboration of functions, interfaces, quality attributes, • and prototypes by increment • - Identification of TBD’s( (to-be-determined items) • Stakeholders’ concurrence on their priority concerns Definition of System Requirements • Choice of architecture and elaboration by increment • - Physical and logical components, connectors, • configurations, constraints • - COTS, reuse choices • - Domain-architecture and architectural style choices • Architecture evolution parameters • Top-level definition of at least one feasible architecture • - Physical and logical elements and relationships • - Choices of COTS and reusable software elements • Identification of infeasible architecture options Definition of System and Software Architecture • Elaboration of WWWWWHH* for Initial Operational • Capability (IOC) • - Partial elaboration, identification of key TBD’s for later • increments • Identification of life-cycle stakeholders • - Users, customers, developers, maintainers, interoperators, • general public, others • Identification of life-cycle process model • - Top-level stages, increments • Top-level WWWWWHH* by stage Definition of Life- Cycle Plan • Assurance of consistency among elements above • - via analysis, measurement, prototyping, simulation, etc. • - Business case analysis for requirements, feasible architectures Feasibility Rationale • Assurance of consistency among elements above • All major risks resolved or covered by risk management • plan *WWWWWHH: Why, What, When, Who, Where, How, How Much Spiral 2005 Anchor Points ©USC-CSSE

  49. Pass/Fail Feasibility Rationales • Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will • Satisfy the requirements: capability, interfaces, level of service, and evolution • Support the operational concept • Be buildable within the budgets and schedules in the plan • Generate a viable return on investment • Generate satisfactory outcomes for all of the success-critical stakeholders • All major risks resolved or covered by risk management plans • Serves as basis for stakeholders’ commitment to proceed ©USC-CSSE

  50. Spiral Anchor Points Enable Concurrent Engineering ©USC-CSSE

More Related