Development Methodologies Development Methodologies A methodology - PowerPoint PPT Presentation

Development Methodologies Development Methodologies A methodology is a system of methods and principles used in a particular “school” of software design. There is a wide variety of published methodologies, and Dr. James A. Bednar an even larger set of informal and/or company-specific jbednar@inf.ed.ac.uk methodologies. The most mature methodologies are often http://homepages.inf.ed.ac.uk/jbednar codified using specialist tools and techniques. Dr. David Robertson All methodologies are controversial, because some people argue that any fixed methodology is an affront to a dr@inf.ed.ac.uk professional, creative, independent designer, while the http://www.inf.ed.ac.uk/ssp/members/dave.htm rest argue about which methodology is best. SAPM Spring 2006: Methodologies 1 SAPM Spring 2006: Methodologies 2 Example Methodologies Types of Methodologies Milestone Milestone Inch−pebble Adaptive SW risk−driven plan−driven ironbound In this course we will focus on three main methodologies: Hackers XP development models models contract • The Waterfall Model Agile methods Software CMM • The Unified Process (UP) CMM • Extreme Programming (XP) “Cowboy hacking” and micromanaging are at the extremes (But we will mention many others, such as Cleanroom, of a continuum (Boehm 2002). DSDM, V-model, Scrum, Crystal, etc.!) We will also discuss open-source design, which is more of a Basic distinction: agile vs. heavyweight philosophical approach than a methodology like the Agile methods are more fashionable to discuss, but it’s others, but which has implications for methodology. hard to tell what people are actually using. SAPM Spring 2006: Methodologies 3 SAPM Spring 2006: Methodologies 4

Plan-Driven Model: Waterfall Waterfall Model of One Release (Royce 1970) Inspired by older engineering disciplines, System feasibility Validation such as civil and mechanical (e.g. how cathedrals are built) Plans and requirements Validation Development of a release is broken into phases, each of Product design Verification which is completed and “signed-off” before moving on. Detailed design Verification Code When problems are found, must backtrack to a previous Unit test phase and start again with the sign-off procedures. Integration Product verification Implementation Much time and effort is spent on getting early phases System test right, because all later phases depend on them. Operation and maintenance Revalidation SAPM Spring 2006: Methodologies 5 SAPM Spring 2006: Methodologies 6 Problems with Waterfall Model The Unified Process In practice it is rarely possible to go straight through from Typical heavyweight approach. Iterative modification of requirements to design to implementation, without waterfall model using modeling to forestall backtracking: backtracking. • Component based There is no feedback on how well the system works, and • Uses UML for all blueprints how well it solves users’ needs, until nearly the very end. • Use-case driven Large danger of catastrophic failure: • Architecture centric • Any error in key user requirements dooms entire process • Iterative and incremental • Big chance that the design is not actually feasible Details in Jacobson et al. (1998). • Big potential for unacceptable performance SAPM Spring 2006: Methodologies 7 SAPM Spring 2006: Methodologies 8

Relatives of The Unified Process Phases of UP Design The IBM Rational Unified Process (RUP) is a commercial Each software release cycle proceeds through a series of product and toolset, superseding: phases, each of which can have multiple modeling iterations: Inception : Produces commitment to go ahead • The Objectory Process (business case feasibility and scope known) • The Booch Method Elaboration : Produces basic architecture; • The Object Modeling Technique plan of construction; significan t risks identified; The Unified Software Development Process (UP) is a major risks addressed published, non-proprietary method based on the RUP , but Construction : Produces beta-release system without specific commercial tools or proprietary methods. Transition : Introduces system to users SAPM Spring 2006: Methodologies 9 SAPM Spring 2006: Methodologies 10 Waterfall Iterations Within Phases UP vs. Waterfall Cycle • Each phase can have PHASES PHASES PHASES Construction Elaboration Construction Construction multiple iterations Inception Transition Elaboration Elaboration Inception Transition Inception Transition • Each iteration can include all workflows, Requirements Requirements Requirements but some are more WORKFLOWS WORKFLOWS WORKFLOWS Analysis heavily weighted in Analysis Analysis Design different phases Design Design Implementation Implementation Implementation • Still hard to change Test Test Test requirements once 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 implementation underway ITERATIONS ITERATIONS ITERATIONS SAPM Spring 2006: Methodologies 11 SAPM Spring 2006: Methodologies 12

The Product: A Series of Models Use Cases “A use case specifies a sequence of actions, including Use−Case Analysis specification model variants, that the system can perform and that yields an model realisation observable result of value to a particular actor.” Design distribution model These drive: implementation Deployment • Requirements capture model verification • Analysis and design of how system realizes use cases Implementation • Acceptance/system testing model • Planning of development tasks Test • Traceability of design decisions back to use cases model SAPM Spring 2006: Methodologies 13 SAPM Spring 2006: Methodologies 14 UP Example: 1 UP Example: 2 Initial use-case diagram: Analysis classes for withdrawing money: USE−CASE MODEL ANALYSIS MODEL Customer Withdraw money Withdraw money Withdraw money Deposit money Transfer between Dispenser Cashier Withdrawal Account accounts interface SAPM Spring 2006: Methodologies 15 SAPM Spring 2006: Methodologies 16

UP Example: 3 UP Example: 4 Collaboration diagram for withdrawing money: Design classes introduced for analysis classes: ANALYSIS MODEL Cashier identify interface request Cashier Dispenser Withdrawal Account Customer interface Withdrawal Dispenser Display Withdrawal Account dispense authorise sensor validate and Key pad Client Account Dispenser Dispenser withdraw manager manager feeder Card reader Cash Transaction counter manager Account DESIGN MODEL SAPM Spring 2006: Methodologies 17 SAPM Spring 2006: Methodologies 18 UP Example: 5 UP Example: 6 Class diagram which is part of the realization of the design model: Sequence diagram for part of the realization: Customer Account Account Client Cash Transaction manager Card reader Display Key pad manager counter manager Card reader Customer Insert card Card inserted Display Client Transaction Ask for PIN code manager manager Show request Key pad Specify PIN code PIN code Request for validation Ask amount Withdrawal Dispenser Show request Cash feeder Specify amount counter Amount Request cash available Dispenser Request withdrawal sensor SAPM Spring 2006: Methodologies 19 SAPM Spring 2006: Methodologies 20

Assumptions of UP Problems with UP Heavy training, documentation, and tools requirements — UP and other heavyweight methodologies concentrate on learning and using UML, modeling, process, tools, carefully controlled, up-front, documented thinking. techniques. Based on assumption that cost of making changes rises exponentially through the development stages. UML is not a native language for customers, and so they To minimize backtracking, establishes rigorous control often cannot provide good feedback until system is over each stage. implemented. At each stage a model acts as a proxy for the whole Requirements are very difficu lt to change at later stages, if system, helping to bring out problems as early as possible needed to match changes in business world, address new (before they are set in code). competition, or fix mistakes in requirements capture. SAPM Spring 2006: Methodologies 21 SAPM Spring 2006: Methodologies 22 Extreme Programming (XP) UP Cycle vs. XP Development PHASES PHASES What if it were possible to make the cost of change Development Construction Maintenance Elaboration Inception Transition Inception constant across all stages, so that design and requirements can be changed even at late stages? XP tries to prevent backtracking by keeping the system Requirements Requirements continuously flexible, eliminating the need for determining WORKFLOWS WORKFLOWS Analysis Analysis the final correct requirements and design before Design Design implementation. Implementation Implementation XP started the trend toward “agile” processes (like Scrum Test Test and Crystal), focusing on closely knit, fast moving 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 design/coding teams and practices (Beck 1999). ITERATIONS RELEASES SAPM Spring 2006: Methodologies 23 SAPM Spring 2006: Methodologies 24