View
53
Download
0
Category
Tags:
Preview:
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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
Recommended