Copyright The Mc Graw-Hill Companies Inc Permission

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. Software Development Methodologies Some images taken from Rosenberg

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Background (1) – 1950 s • Assembly code • Small size, specific purpose – 1960 s • COBOL, Fortran, PL/1 • Dijkstra’s “Structured Programming” • Large size (banking, airline reservations, airline control) – 1968 “On verge of a software crisis” (NATO) • Systems not delivered, too expensive, unreliable, not user friendly, inefficient, not maintainable

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Background (2) – 1960 s Development Model: “Build and Fix” • Problems –No specifications –No design • Totally unsatisfactory • Need life-cycle model –“Game plan” –Phases –Milestones

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Background (3) – 1970 s – the “Waterfall Model” • Structured Design and Analysis • Characterized by –Feedback loops –Documentation-driven • Advantages –Documentation of steps –Maintenance easier • Disadvantages – Delayed delivery to clients – Hard to “get right” – Too much backtracking

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Rapid Prototyping – Make fast movements over all phases • Build functional equivalent • Throw away after development – Result • • Not proven Too much time spent on coding Tends to lock in design, interface Peaks customer interest – Perhaps too early – Possible Role • Use for specification only • Use other methods for rest

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Spiral Model – Waterfall plus risk assessment • Only really appropriate for “in-house” development of large systems

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Incremental/Iterative (1) – Series of builds • Each build is only part of requirements • Incremental in planned system growth • Iterative in that new builds can redo old builds

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Incremental/Iterative (2) – Advantages • Gets deliverable to client faster • Eases user integration – Reduces initial capital outlay – Reduces “big bang” effect • Permits rework with more experience – Disadvantages • Can get deliverable to client too fast • Can reduce to build-and-test • Difficult when next build doesn’t match previous builds • Can lead to “tunnel vision” design – not considering all requirements

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Unified Development Model (1) – aka Rational Unified Model (RUP) – An object-oriented, iterative/incremental waterfall model – Development focuses on construction of artifacts (or work products) – Iterations move through series of phases in which different aspects of waterfall receive different levels of attention

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Unified Development Model (2) – Each phase ends with a milestone – Each phase processes all workflows

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Unified Development Model (3) – Phases • Inception – – Establish business case/models Establish vision, high-level requirements Create stakeholder “buy in” Evaluate risks/returns • Elaboration – – – Detailed requirements Architecture and prototype Design • Construction – Coding and testing • Transition – – Putting product in user’s hands Preparing for next release

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Unified Development Model (4) – Salient Features • UML based – Artifacts may be documents, models, code, … • Heavy artifact maintenance – Very formal structure • Use-case driven – A “use case” is a typical user interaction with the system for a user goal • Traceability – All artifacts are co-referenced Overall, was the historical “preferred” method for large-scale software development within large companies

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Unified Development Model (5) – RUP UML Models • • • • Class Diagrams Use Case Diagrams Sequence Diagrams Robustness Diagrams (not really standard UML 2. 0) Collaboration/Communication Diagrams State Diagrams Deployment Diagrams Component Diagrams Package Diagrams Activity Diagrams Composite Structure Diagrams Object Diagrams Timing Diagrams Interaction Diagrams

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (1) – “Agile” techniques are a reaction to the imposing structure and regulation of RUP – Trying to make software development process: • Simpler • Easier to implement • More responsive to customer needs

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (2) • The Manifesto for Agile Software Development* We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools. • Working software over comprehensive documentation. • Customer collaboration over contract negotiation. • Responding to change over following a plan. That is, while we value the items on the right, we value the items on the left more. • * - copyright 2001 by the 17 authors of the concept

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (3) • Agile Methods (from www. agilealliance. org ) – Agile Modeling – Adaptive Software Development – Lean Software Development – Scrum (www. controlchaos. com ) – Test Driven Design / Test Driven Development – Story Driven Development (see http: //cukes. info/ ) – Extreme Programming

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (4) • Extreme Programming, Core Practices (from www. xprogramming. com ) – Whole Team – Planning Game / Small Releases / Customer Tests – Simple Design / Pair Programming / Test-Driven Development / Design Improvement – Continuous Integration / Collective Code Ownership / Coding Standard – Metaphor / Sustainable Pace

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (5) – Characteristics of light projects • Small / medium projects (up to 30 people, maybe) • Requirements gathered over iterations • Collaborative – Short development cycles • Flexible mindset, quick planning and development cycle, and tremendously disciplined testing

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (6) – Customer experience goes from negotiation to collaboration – Must also be followed completely and rigorously, else confusion and anarchy – Project team and the customer work together • Logically • Physically

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (7) – People • Flexible and motivated • Trust them to get the work done • Let them balance work with life (40+ hours) • Let them execute – Barely sufficient structure (not insufficient)

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (8) – Common development path: – Gather user stories (how system is used) – Generate a prioritized list of tasks and estimated times to develop each task – Developers work on subset of tasks for short periods – Use test-first development – Continuous testing as part of development – Users get regular builds of system for feedback – Measure “velocity” (units of work completed/ time)

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Agile Software Development (9) – Possible problem: Agile methods can be used as an excuse for: • No planning • No analysis • No modeling • No design • No structure • No documentation

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • The ICONIX Development Model – RUP • Some companies use this approach • Best for large projects – Agile • Increasing number of companies use this approach • Some evidence: better for relatively smaller projects • More a philosophy and set of approaches than a methodology – ICONIX • A compromise between RUP and Agile • Allows enough structure to be understood • Should allow you to function in most companies

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • ICONIX – Subset of UML – Keep: • Class Diagrams • Use Case Diagrams (with text extensions) • Sequence Diagrams • Robustness Diagrams • Maybe keep: • Collaboration Diagrams (optional) • State Diagrams (optional) • Deployment Diagrams (optional)

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Overview of ICONIX Process

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • ICONIX and the Three Amigos

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • The Agile + ICONIX Approach – Problem – ICONIX can lean more towards RUP • Complex models must be generated if complex domain • Still heavy documentation overhead • Difficult to correlate all models (use cases, design, tests) • This can delay prototyping, client feedback – Agile + ICONIX • Goals – Achieve working results earlier – Remove duplicate documentation

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • The Agile + ICONIX Steps – Basically Same Process Steps as ICONIX – But leave out all optional models – Use Agile Methods to accomplish process (where possible) – Steps 1. 2. 3. 4. 5. 6. 7. Identify your real-world domain objects (domain model) Define the behavior requirements (use cases) Perform robustness analysis to disambiguate the use cases and identify gaps in the domain model Allocate behavior to your object (sequence diagrams) Finish the static model (class diagram) Write/generate the code (source code) Perform system and user-acceptance testing

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Which Development Methodology / Model Should You Use? – Some large companies still use RUP, Iconix or variants – RUP or formal methods often used for large projects with low tolerance for failure – Many companies (large and small) are moving toward Agile methodologies or techniques – – – Sometimes UML models are still used Other Agile techniques are being explored and tested Increasing exploration of formal software development methods (based on pre-conditions and post-conditions)

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Improving Software Development (1) – People have tried improving software development by using the following: • Time sharing • CASE tools • Different methodologies – However, these did NOT solve the intrinsic problems – Some have experienced 5% - 10% annual productivity increase – But, no order-of-magnitude increase has been possible

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Improving Software Development (2) – U. S. Department of Defense initiative – Software Engineering Institute (SEI) – The fundamental problem with software • The software process is badly managed – Software process improvement initiatives • Capability maturity model (CMM) • ISO 9000 -series • ISO/IEC 15504

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Capability Maturity Model Integration – Not a life-cycle model – Set of strategies for improving the software process • • • SW–CMM for software P–CMM for human resources (“people”) SE–CMM for systems engineering IPD–CMM for integrated product development SA–for software acquisition – These strategies have been unified into CMMI (capability maturity model integration) • Current standard finding wider acceptance • http: //www. sei. cmu. edu/cmmi/ • Apply to more than software development

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • SW-CMM (1) – Strategy for improving the software process (pre. CMMI) • Put forward in 1986 by the SEI • Fundamental idea: • Improving the software process leads to – – Improved software quality Delivery on time, within budget • Improved management leads to – Improved techniques – Five levels of “maturity” were defined • Organization advances stepwise from level to level

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • SW-CMM (2) – Level 1 – Initial Level • Ad hoc approach – – Entire process is unpredictable Management consists of responses to crises • Many organizations world-wide are still at level 1 – Level 2 - Repeatable • Basic software management – – Management decisions should be made on the basis of previous experience with similar products Measurements (“metrics”) are made These can be used for making cost and duration predictions in the next project Problems are identified, immediate corrective action is taken

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • SW-CMM (3) – Level 3 – Defined Level • The software process is fully documented – – Managerial and technical aspects are clearly defined Continual efforts are made to improve quality, productivity Reviews are performed to improve software quality CASE tools are applicable now (and not at levels 1 or 2) – Level 4 – Managed Level • Quality and productivity goals are set for each project – – Quality, productivity are continually monitored Statistical quality controls are in place

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • SW-CMM (4) – Level 5 – Optimizing Level • Continuous process improvement – – – Summary Statistical quality and process controls Feedback of knowledge from each project to the next

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Experience – It took: • 3 to 5 years to get from level 1 to level 2 • 1. 5 to 3 years from level 2 to level 3 • SEI questionnaires highlight shortcomings, suggest ways to improve the process – Original idea: Defense contracts would be awarded only to capable firms – Profitability • Hughes Aircraft (Fullerton, CA) spent $500 K (1987– 90) – Savings: $2 M per year, moving from level 2 to level 3 • Raytheon moved from level 1 in 1988 to level 3 in 1993 – – Productivity doubled Return of $7. 70 per dollar invested in process improvement

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • ISO 9000 – Set of five standards for industrial activities • ISO 9001 for quality systems • ISO 9000 -3, guidelines to apply ISO 9001 to software • There is an overlap with CMM/CMMI, but they are not identical • Not process improvement • Stress on documenting the process • Emphasis on measurement and metrics • ISO 9000 is required to do business with the E. U. • Also by many U. S. businesses, for example, GE • More and more U. S. businesses are ISO 9000 certified

Copyright © The Mc. Graw-Hill Companies, Inc. Permission required for reproduction or display. • Process Improvement Data – SEI report on 13 organizations in the original study – They used a variety of process improvement techniques, not just SW–CMM