1. Project Methodologies
AD642

2. Agenda Waterfall Lifecycle Model RUP Lifecycle Model
Agile Software Development Methodologies
Extreme Programming

3. Waterfall Model Activity-centered view of the software lifecycle
Define detailed upfront requirements
Come up with the design that will support the required behavior.
Implement the required system.
Integrate and test the components.
Activities are performed in sequence
Described in 1970 by Royce.

4. Waterfall Model Illustrated
Requirements
Process
System
Allocation
Concept
Exploration
Design
Implementation
Installation
Operation &
Support Process
Verification
& Validation

5. About Waterfall Lifecycle
Managers love waterfall models:
Nice milestones
No need to look back (linear system), one activity at a time
Easy to check progress : 90% coded, 20% tested
Developers hate the waterfall model
Requirements are a moving target
They have to come up with estimates based on no data.

6. Problems with the Waterfall (I)
Complete up-front specifications with sign-off
Research 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].

7. Problems with the Waterfall (II)
Late Integration and Test
The 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 Schedules
Can 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” values
Limited value for high change, novel, innovative domains such as software development.

8. Iterative and Incremental Lifecycle Models
1960’s: ad-hoc code-and-fix
1970’s: Waterfall was thought to be the ideal approach to software development
In practice, waterfall is only applicable to the most straightforward projects.
1980’s: Iterative and incremental lifecycle models
The 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 Process
Popular example of Iterative and incremental lifecycle
A product and a process based on object orientation and UML

9. RUP: Rational Unified Process
Derived from the work on the UML at Rational
Booch, Jacobson, and Rumbaugh (1999)
4 Phases:
Inception
Elaboration
Construction
Transition
Several Iterations in each phase
For each iteration, several parallel activities (workflows)

10. (source: www.rational.com)

11. RUP Dimensions
First Dimension: A dynamic perspective that shows phases and iterations over time
Second Dimension: static perspective that shows process activities (workflows)

12. RUP Dynamic Perspective
Phases can be
enacted incrementally
Each phase is enacted
In an iterative way

13. RUP Phases Inception Elaboration Construction Transition
Establish the business case for the system
Identify actors and initial use cases
Initial planning, estimation and schedule
Elaboration
Understand problem domain
Requirements model (use case model)
Overall system architecture
Construction
System design, object design, programming and testing
Develop a working software system ready to deliver to users
Transition
Deploy the system in its operating environment.

14. Static workflows

15. RUP Illustrated
Time
Workflows

16. RUP Good Practice Develop software iteratively Manage requirements
Plan increments based on customer priorities
Manage requirements
Explicitly document requirements and track requirement changes
Analyze impact of changes before accepting them
Use component-based architectures
Visually model software (UML)
Control changes to software
Manage changes to software using a change management system and configuration management procedures and tools

17. Agile Methods
In the 1908os and early 1990s there was a widespread view that the best way to achieve better software was through
careful project planning
formalised quality assurance
the use of analysis and deign methods supported by CASE tools
controlled and rigorous software development

18. Agile Methods (Cont.)
This view came from software engineers who were developing large, long-lived software systems
Teams in different companies and geographically distributed
When heavy weight, plan-based development approaches were applied to small and medium size systems
The overhead sometimes dominated the software development process
Consider the cost of changing requirements

19. Agile Methods (Cont.)
More time was spent on how the system should be developed than on program development and testing
In the 1990s new agile methods were formulated which
relied on an iterative & incremental approach
allowed for changing requirements
Rapid software delivery to customers

20. General Principles of Agile Methodologies
Customer close involvement
Incremental delivery
A focus on people, not the process
Team members develop their own ways of working
Embrace requirements and change
Maintain simplicity

21. Examples of Agile Methodologies
Extreme programming (covered here)
Crystal
Adaptive Software Development
Scrum
DSDM
Best suited for small and medium sized projects

22. Light-weight Methodologies
Heavy-weight methodologies: (based on waterfall or RUP)
Up-front analysis & design documentation
Strict phases
Large teams, long iteration cycles, long release times
Feature intensive
Light-weight (Agile) methodologies: (E.g., XP)
No up-front analysis & design documentation
Test-first coding
Small teams, short iteration cycles, short release times
Change intensive

23. Software Development Processes
Waterfall
Iterative
Extreme Programming (XP)
Analysis
Design
Code
Design

24. XP Highlights
Probably the best known and most widely used agile method
Founded on four values: communication, simplicity, feedback, and courage (courage in changing requirements and code).
Programmers work in pairs
Develop tests for each task before writing code
New versions of the software may be created several times a day
Increments are delivered to customers roughly every two weeks

25. XP Highlights (Cont.)
All scenarios and requirements are represented as user stories
Customer is involved in specifying and prioritising requirements
The customer is part of the development team
The software is continually refactored

26. User Stories Written by customer
Used instead of large requirements documents
Similar to scenarios but not limited to features visible to the outside world.
Used for release planning
Used for the creation of acceptance test
Typically much less detailed than scenarios and use cases
Typically takes 1-3 weeks to implement

27. XP Release Cycle Select user stories for this release
Breakdown stories into tasks
Plan release
Develop/integrate/ test software
Release software
Evaluate System

28. 12 XP Practices Pair-programming On-site Customer Test-first
Iterative Development
Refactoring
Simple Design
Planning Game
Coding Standards
Continuous Integration
Metaphor
40-Hour Rule
Collective Code Ownership

29. Pair Programming
All 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 rolls
Active communication, sharing expertise

30. On-Site Customer
Programmers 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.

31. Test-First Development
Develop automated tests before implementation
Test-then-code instead of code-then-test
Test-driven coding: constant validation and verification
Constant testing: unit, integration, acceptance (by onsite customer)
Automated testing (JUnit framework)
Open source framework for implementing unit tests in Java
Comes with Eclipse

32. 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 cycles
Iteration plan, release plan from planning games
Small complete and continuous releases
Frequent delivery of working software progressively acquiring new features

33. Refactoring Improves code quality
Extreme re-factoring for continued improvement of design
Constantly simplifies code
Changing existing program to make adding new features simple
Re-factoring after adding a new feature to clean up and organize the effect of the change
Re-factor as often as needed

34. Simple Design Design for now, not for the future
Extreme simplicity in design: avoid shortcuts, smart hard-to-understand code
No duplicate logic (no parallel class hierarchies)
Fewest possible classes and methods
Only features in the current iteration
Good design (re-factored) and technical excellence

35. Continuous Integration
Integration and integration testing of tasks frequently (every few hours, at least once a day)
Integration on a machine dedicated for integration
Integration testing before completing current integration session
Continuous code review: integration testing and code review of completed code

36. Metaphor Use of best practices: design patterns, naming, defining
Easy to use system of names: consistent naming of classes and methods

37. 40-Hour Rule
Best individual effort without overwork and undue pressure
Uniform individual velocity: sustainable development pace
Fresh and eager team when starting in the morning
Satisfied and not tired when finishing the day in the evening
40 hr may vary ( )
Discourage overtime. No two successive days of over-time.
Vacation and weekend work discouraged for best developer contribution
Highly motivated and fully fit developing members

38. Collective Code Ownership
Any pair programmers may re-factor any part of the code
Faster development by eliminating the bottleneck associated with change requests in an individual code ownership model
Pair 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

39. XP Achieves Timing: Delivery On Time
Releasing: Frequent Releases (with Business Prioritized Features)
Quality: Simple Code--easy to test and modify
Reliability: Constantly Tested, Pair-programmed & Integrated Features
Flexibility: Rapid Response to Feedback, Change, Re-scheduling
Low Initial Cost: Flattened Change Cost Curve, No Future-safe Cost
Communication: Face-to-face, On-site Customer, Pair-programming
Team-work: Constant Team Integration, Team Spirit & Esteem
Iterating: Micro-iterations, Small Analyze/Test/Design/Code Episodes
People-Centered: Stand-up Meetings, Planning Games, Individual Velocities

40. Which Methodology to Use?
Each has advantages and disadvantages
Small projects tend to fit well into iterative processes
Large projects often need more up-front planning and a waterfall approach
Outsourcing, market constraints, corporate culture all come into play