1 Waterfall Model, RUP, Agile Methodologies & Extreme Programming Qutaibah MalluhiSoftware EngineeringQatar UniversityBased on slides by Bernd Bruegge & Allen H. Dutoit
2 Agenda Waterfall Lifecycle Model RUP Lifecycle Model Agile Software Development MethodologiesExtreme Programming
3 Software Lifecycle Models Waterfall ModelRational Unified ProcessOthersV-modelSpiral model
4 Waterfall Model Activity-centered view of the software lifecycle Define detailed upfront requirementsCome up with the design that will support the required behavior.Implement the required system.Integrate and test the components.Activities are performed in sequenceDescribed in 1970 by Royce.
5 Waterfall Model Illustrated RequirementsProcessSystemAllocationConceptExplorationDesignImplementationInstallationOperation &Support ProcessVerification& Validation
6 About Waterfall Lifecycle Managers love waterfall models:Nice milestonesNo need to look back (linear system), one activity at a timeEasy to check progress : 90% coded, 20% testedDevelopers hate the waterfall modelRequirements are a moving targetThey have to come up with estimates based on no data.
7 Problems with the Waterfall (I) Complete up-front specifications with sign-offResearch showed that 45% of features created from early specifications were never used—with an additional 19% rarely used [Johnson02].Over-engineering, a study of 400 projects spanning 15 years showed that less than 5% of the code was actually useful or used [CLW01].
8 Problems with the Waterfall (II) Late Integration and TestThe waterfall pushes this high-risk and difficult issues toward the end of the project. Waterfall is called fail-late lifecycle.Reliable Up-front Estimates and SchedulesCan not be done when the full requirements and risks are not reliably known at the start, and high rates of change are the norm.“Plan the work, work the plan” valuesLimited value for high change, novel, innovative domains such as software development.
9 Iterative and Incremental Lifecycle Models 1960’s: ad-hoc code-and-fix1970’s: Waterfall was thought to be the ideal approach to software developmentIn practice, waterfall is only applicable to the most straightforward projects.1980’s: Iterative and incremental lifecycle modelsThe lifecycle is composed of a sequence of iterations.Each iteration is a mini-project composed of activities such as requirements analysis, design, programming and testing.An iteration ends with an iteration release, a stable, integrated and tested partially complete system.1990’s: Rational Unified ProcessPopular example of Iterative and incremental lifecycleA product and a process based on object orientation and UML
10 RUP: Rational Unified Process Derived from the work on the UML at RationalBooch, Jacobson, and Rumbaugh (1999)4 Phases:InceptionElaborationConstructionTransitionSeveral Iterations in each phaseFor each iteration, several parallel activities (workflows)
11 RUP DimensionsFirst Dimension: A dynamic perspective that shows phases and iterations over timeSecond Dimension: static perspective that shows process activities (workflows)
12 RUP Dynamic Perspective Phases can beenacted incrementallyEach phase is enactedIn an iterative way
13 RUP Phases Inception Elaboration Construction Transition Establish the business case for the systemIdentify actors and initial use casesInitial planning, estimation and scheduleElaborationUnderstand problem domainRequirements model (use case model)Overall system architectureConstructionSystem design, object design, programming and testingDevelop a working software system ready to deliver to usersTransitionDeploy the system in its operating environment.
16 RUP Good Practice Develop software iteratively Manage requirements Plan increments based on customer prioritiesManage requirementsExplicitly document requirements and track requirement changesAnalyze impact of changes before accepting themUse component-based architecturesVisually model software (UML)Control changes to softwareManage changes to software using a change management system and configuration management procedures and tools
18 What is a Software Development Methodology? Collection of techniques and tools that provide guidance, general principles, and strategies for developing and managing a software system unified by a philosophical approachExamples of methodology issuesHow much planning should be done in advance?How much of the design should result from reusing past solutions?How much of the system should be modeled before it is coded?In how much detail should the software development process be defined?How often should the work be controlled and monitored?When should the project goals be redefined?
19 Agile MethodsIn the 1908os and early 1990s there was a widespread view that the best way to achieve better software was throughcareful project planningformalised quality assurancethe use of analysis and deign methods supported by CASE toolscontrolled and rigorous software development
20 Agile Methods (Cont.)This view came from software engineers who were developing large, long-lived software systemsTeams in different companies and geographically distributedWhen heavy weight, plan-based development approaches were applied to small and medium size systemsThe overhead sometimes dominated the software development processConsider the cost of changing requirements
21 Agile Methods (Cont.)More time was spent on how the system should be developed than on program development and testingIn the 1990s new agile methods were formulated whichrelied on an iterative & incremental approachallowed for changing requirementsRapid software delivery to customers
22 General Principles of Agile Methodologies Customer close involvementIncremental deliveryA focus on people, not the processTeam members develop their own ways of workingEmbrace requirements and changeMaintain simplicity
23 Examples of Agile Methodologies Extreme programming (covered here)CrystalAdaptive Software DevelopmentScrumDSDMBest suited for small and medium sized systems
25 Light-weight Methodologies Heavy-weight methodologies: (based on waterfall or RUP)Up-front analysis & design documentationStrict phasesLarge teams, long iteration cycles, long release timesFeature intensiveLight-weight (Agile) methodologies: (E.g., XP)No up-front analysis & design documentationTest-first codingSmall teams, short iteration cycles, short release timesChange intensive
26 Software Development Processes WaterfallIterativeExtreme Programming (XP)AnalysisDesignCodeDesign
27 XP HighlightsProbably the best known and most widely used agile methodFounded on four values: communication, simplicity, feedback, and courage (courage in changing requirements and code).Programmers work in pairsDevelop tests for each task before writing codeNew versions of the software may be created several times a dayIncrements are delivered to customers roughly every two weeks
28 XP Highlights (Cont.)All scenarios and requirements are represented as user storiesCustomer is involved in specifying and prioritising requirementsThe customer is part of the development teamThe software is continually refactored
29 User Stories Written by customer Used instead of large requirements documentsSimilar to scenarios but not limited to features visible to the outside world.Used for release planningUsed for the creation of acceptance testTypically much less detailed than scenarios and use casesTypically takes 1-3 weeks to implement
30 XP Release Cycle Select user stories for this release Breakdown stories into tasksPlan releaseDevelop/integrate/ test softwareRelease softwareEvaluate System
32 Pair ProgrammingAll code to be included in a production release is created by two people working together at a single computer.One person types and codes, the other one observes and constantly monitors the code.The observer is doing real-time code review, and perhaps thinking more strategically than the person typing.Pairs dynamically swap rollsActive communication, sharing expertise
33 On-Site CustomerProgrammers and customers work together in the same team (same room).Immediate check, feedback, and clarification by customer through face-to-face communication.Customer performs acceptance test of features as they are completed.Customer satisfaction: early and frequent delivery of software features.
34 Test-First Development Develop automated tests before implementationTest-then-code instead of code-then-testTest-driven coding: constant validation and verificationConstant testing: unit, integration, acceptance (by onsite customer)Automated testing (JUnit framework)Open source framework for implementing unit tests in JavaComes with Eclipse
35 Iterative Development Customers choose the story cards for next iteration (next features to be implemented) depending on their business priorities.Short iterations, release frequency, customer prioritized short cyclesIteration plan, release plan from planning gamesSmall complete and continuous releasesFrequent delivery of working software progressively acquiring new features
36 Refactoring Improves code quality Extreme re-factoring for continued improvement of designConstantly simplifies codeChanging existing program to make adding new features simpleRe-factoring after adding a new feature to clean up and organize the effect of the changeRe-factor as often as needed
37 Simple Design Design for now, not for the future Extreme simplicity in design: avoid shortcuts, smart hard-to-understand codeNo duplicate logic (no parallel class hierarchies)Fewest possible classes and methodsOnly features in the current iterationGood design (re-factored) and technical excellence
38 Planning Game (I)The goal is to choose the stories for next iteration (1-3 weeks)discovering what the customer wants and estimating how long this will take to do.Outline: Customers divide up the work to be done into a set of stories, each of which can be written on a 3 by 5 card (CRC cards) in a few sentences. The developers then estimate how much effort is required to build each story. The customer then chooses which stories she wants built in the next cycle, based on the time available and the estimates from the developers.
39 Planning Game (II) By customer By Developer Desirable features (business-wise) for next iterationOrder (priority of one feature over another)Release planning by business: features, datesBy DeveloperPossible technical featuresEstimating development time for iteration tasksDevelopment-process planning and organization of work and development team membersConsequences of business decision communicated to customerFace-to-face communication in planning game
40 Coding Standards Naming conventions Same coding notations Make team communication by code easier
41 Continuous Integration Integration and integration testing of tasks frequently (every few hours, at least once a day)Integration on a machine dedicated for integrationIntegration testing before completing current integration sessionContinuous code review: integration testing and code review of completed code
42 Metaphor Use of best practices: design patterns, naming, defining Easy to use system of names: consistent naming of classes and methods
43 40-Hour RuleBest individual effort without overwork and undue pressureUniform individual velocity: sustainable development paceFresh and eager team when starting in the morningSatisfied and not tired when finishing the day in the evening40 hr may vary ( )Discourage overtime. No two successive days of over-time.Vacation and weekend work discouraged for best developer contributionHighly motivated and fully fit developing members
44 Collective Code Ownership Any pair programmers may re-factor any part of the codeFaster development by eliminating the bottleneck associated with change requests in an individual code ownership modelPair programming, adherence to the code standard, and continuous integration lower the danger of this free model of modifying the code.No individual (or pair) responsibility or blame after integration
45 XP Achieves Timing: Delivery On Time Releasing: Frequent Releases (with Business Prioritized Features)Quality: Simple Code--easy to test and modifyReliability: Constantly Tested, Pair-programmed & Integrated FeaturesFlexibility: Rapid Response to Feedback, Change, Re-schedulingLow Initial Cost: Flattened Change Cost Curve, No Future-safe CostCommunication: Face-to-face, On-site Customer, Pair-programmingTeam-work: Constant Team Integration, Team Spirit & EsteemIterating: Micro-iterations, Small Analyze/Test/Design/Code EpisodesPeople-Centered: Stand-up Meetings, Planning Games, Individual Velocities
46 Question to Think About Is XP suitable for students’ projects?Why or why not?