project methodologies n.
Skip this Video
Loading SlideShow in 5 Seconds..
Project Methodologies PowerPoint Presentation
Download Presentation
Project Methodologies

Loading in 2 Seconds...

play fullscreen
1 / 42

Project Methodologies - PowerPoint PPT Presentation

  • Uploaded on

Project Methodologies. AD643 From a lecture by Qutaibah Malluhi , Qatar University. Agenda. Waterfall Lifecycle Model RUP Lifecycle Model Agile Software Development Methodologies Extreme Programming. Waterfall Model. Activity-centered view of the software lifecycle

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Project Methodologies

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
project methodologies

Project Methodologies

AD643From a lecture by QutaibahMalluhi, Qatar University

  • Waterfall Lifecycle Model
  • RUP Lifecycle Model
  • Agile Software Development Methodologies
  • Extreme Programming
waterfall model
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.
waterfall model illustrated














& Validation




Operation &

Support Process

Waterfall Model Illustrated
about waterfall lifecycle
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.
problems with the waterfall i
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].
problems with the waterfall ii
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.
iterative and incremental lifecycle models
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
rup rational unified process
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)

Over time…

(this Figure is from

rup dimensions
RUP Dimensions
  • First Dimension: A dynamic perspective that shows phases and iterations over time
  • Second Dimension: static perspective that shows process activities (workflows)
rup dynamic perspective
RUP Dynamic Perspective

Phases can be

enacted incrementally

Each phase is enacted

In an iterative way

rup phases
RUP Phases
  • Inception
    • 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.
rup illustrated
RUP Illustrated



rup good practice
RUP Good Practice
  • Develop software iteratively
    • 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
what is a software development methodology
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 approach
  • Examples of methodology issues
    • How 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?
agile methods
Agile Methods
  • In the 1980s 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
agile methods cont
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
agile methods cont1
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
general principles of agile methodologies
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
examples of agile methodologies
Examples of Agile Methodologies
  • Extreme programming (covered here)
  • Crystal
  • Adaptive Software Development
  • Scrum
  • DSDM

Best suited for small and medium sized systems

light weight methodologies
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
software development processes
Software Development Processes



Extreme Programming (XP)





xp highlights
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
xp highlights cont
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
user stories
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
xp release cycle

Select user stories for this release

Breakdown stories into tasks

Plan release

Evaluate System

Release software

Develop/integrate/ test software

XP Release Cycle
12 xp practices
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
pair programming
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
on site customer
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.
test first development
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
iterative development
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
  • 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
simple design
Simple Design
  • Design fornow, 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
planning game i
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.
planning game ii
Planning Game (II)
  • By customer
    • Desirable features (business-wise) for next iteration
    • Order (priority of one feature over another)
    • Release planning by business: features, dates
  • By Developer
    • Possible technical features
    • Estimating development time for iteration tasks
    • Development-process planning and organization of work and development team members
    • Consequences of business decision communicated to customer
  • Face-to-face communication in planning game
continuous integration
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
  • Use of best practices: design patterns, naming, defining
  • Easy to use system of names: consistent naming of classes and methods
40 hour rule
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 (35 - 45)
  • 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
collective code ownership
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 blameafter integration
xp achieves
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