2Agenda Waterfall Lifecycle Model RUP Lifecycle Model Agile Software Development MethodologiesExtreme Programming
3Waterfall 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.
4Waterfall Model Illustrated RequirementsProcessSystemAllocationConceptExplorationDesignImplementationInstallationOperation &Support ProcessVerification& Validation
5About 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.
6Problems 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].
7Problems 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.
8Iterative 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
9RUP: 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)
11RUP DimensionsFirst Dimension: A dynamic perspective that shows phases and iterations over timeSecond Dimension: static perspective that shows process activities (workflows)
12RUP Dynamic Perspective Phases can beenacted incrementallyEach phase is enactedIn an iterative way
13RUP 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.
16RUP 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
17Agile 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
18Agile 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
19Agile 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
20General 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
21Examples of Agile Methodologies Extreme programming (covered here)CrystalAdaptive Software DevelopmentScrumDSDMBest suited for small and medium sized projects
22Light-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
23Software Development Processes WaterfallIterativeExtreme Programming (XP)AnalysisDesignCodeDesign
24XP 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
25XP 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
26User 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
27XP Release Cycle Select user stories for this release Breakdown stories into tasksPlan releaseDevelop/integrate/ test softwareRelease softwareEvaluate System
29Pair 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
30On-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.
31Test-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
32Iterative 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
33Refactoring 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
34Simple 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
35Continuous 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
36Metaphor Use of best practices: design patterns, naming, defining Easy to use system of names: consistent naming of classes and methods
3740-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
38Collective 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
39XP 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
40Which Methodology to Use? Each has advantages and disadvantagesSmall projects tend to fit well into iterative processesLarge projects often need more up-front planning and a waterfall approachOutsourcing, market constraints, corporate culture all come into play