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– 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

RequirementsProcess

SystemAllocation

Process

ConceptExploration

Process

DesignProcess

ImplementationProcess

InstallationProcess

Operation &Support Process

Verification& Validation

Process

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)

• 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)

• 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

• 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

• 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)

(this Figure is from www.rational.com)

Over time…

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

Phase iteration

Inception Elaboration Construction Transition

Phases can be enacted incrementally

Each phase is enacted In an iterative way

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.

Static workflows

Workflow Description

Business modelling The business processes are modelled using business use cases.

Requirements Actors who interact with the system are identified and use cases aredeveloped to model the system requirements.

Analysis and design A design model is created and documented using architecturalmodels, component models, object models and sequence models.

Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.

Test Testing is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.

Deployment A product release is created, distributed to users and installed in theirworkplace.

Configuration andchange management

This supporting workflow managed changes to the system (seeChapter 29).

Project management This supporting workflow manages the system development (seeChapter 5).

Environment This workflow is concerned with making appropriate software toolsavailable to the software development team.

RUP IllustratedTime

Workflows

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?

• 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

• 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.)

• 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 (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

• 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

• Extreme programming (covered here)• Crystal• Adaptive Software Development• Scrum• DSDM

Best suited for small and medium sized systems

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

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Analysis

Design

Code

Design

Waterfall Iterative Extreme Programming (XP)

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.)

• 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

• 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

Develop/integrate/ test

software

Release software

Evaluate System

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

• 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

• 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

• 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

• 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

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

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

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)

• 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

• 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

Metaphor

• Use of best practices: design patterns, naming, defining

• Easy to use system of names: consistent naming of classes and methods

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

• 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

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