CSC 2920 Software Development

1
CSC 2920Software Development Professional
Practices

• Fall 2009
• Dr. Chuck Lillie

2
Chapter 5
New and Emerging Process Methodologies
3
Objectives

• Understand
• Limitations of traditional process methodologies
• Applicability of agile processes
• Basic tenets of agile processes
• Gain familiarity with some agile processes

4
What are agile processes

• Family of software development methodologies
• Short releases and iterations
• Divide into small pieces
• Release to customer as often as possible
• Incremental design
• Dont try to complete design up front
• Delay design decisions as long as possible
• User involvement
• Get user feedback as often as possible
• Minimal documentation
• Only necessary amount of documentation
• Informal communications
• People communicate better informally
• Change
• Things will change, plan for that

5
The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
That is, while there is value in the items on
the right, we value the items on the left more.
1. Individuals and interactions - - over
processes and tools 2. Working software
- - over comprehensive documentation
3. Customer collaboration - - over
contract negotiation 4. Responding to change
- - over following a plan
http//agilemanifesto.org
6
Problems with traditional processes

• Lengthy development time
• Inability to cope with changes in requirements
• Assumes requirements are understood at beginning
  of project
• Relies on heroic development effort
• Complex methodology
• Waste/duplication of effort

7
Some Agile Methodologies

• No process will work for all projects
• Choose process best matched to project
• Four of many agile methodologies
• Extreme Programming (XP)
• Crystal Clear/Orange
• Rational Unified Process (RUP)
• Framework
• Microsoft Solutions Framework

8
Extreme Programming (XP) Core Values

• Communication (between team and with customers)
• Simplicity (in design and code)
• Feedback (at many levels)
• Courage (to make and implement difficult decision)

9
XP Fundamental Principles

• Rapid feedback
• Use pair programming, unit testing, integration,
  and short interations and releases
• Simplicity
• Try the simplest approach possible
• Incremental change
• Try small changes that add up
• Use code refactoring small modifications to
  improve code
• Embrace change
• Preserve options for the future
• Delay decisions that commit one to a path for as
  long as possible
• Quality work
• Create the best product possible

10
XP Other Principles

• Ongoing learning
• Small initial investment
• Playing to win
• Concrete experiments
• Open, honest communications
• Working with peoples instincts
• Accepting responsibility
• Local adaptation
• Traveling light
• Honest measurement

11
XP 12 practices

• Planning
• Determine features to be included in next release
• Business priorities and technical estimates
• Short releases
• Get a working system quickly
• Release new versions in short cycles (2 to 4
  weeks)
• Base new detail plans on customer feedback
• Metaphor
• Use a metaphor instead of an architecture
• Simple design
• Eliminate unnecessary complexity as soon as
  possible
• Design can be changed in later versions
• Test-driven development
• Continuous and automated
• Write tests before writing code
• Design improvement (Refactoring)
• Remove duplication, improve communication, and
  simplify or add needed flexibility

12
XP 12 practices

• Pair programming
• Two programmers working at same machine
• Collective ownership
• Anyone can change any code at any time
• Continuous integration
• Integrate and test every time a task is completed
  (many times a day)
• Sustainable pace
• 40 hours a week reasonable
• Never overtime two consecutive weeks
• On-site customer
• Include real customer on the team
• Coding standards
• Everyone needs to use the same rules

13
XP Planning

• Plan only the immediate next iteration in detail
• Four variables to adjust in a project
• Scope
• What needs to be done for system to be useful
• Cost
• Quality
• Time
• Scope is easier to change (drop features)
• Uses stories (represents a task, similar to use
  cases)

14
XP Planning (2)

• Who makes the decisions?

• Technical side decides
• Estimates how long will each feature take
• Consequences best technology and programming
  language
• Process how are work activities performed team
  organization

• Client decides
• Scope needed for useful system
• Priorities identify and prioritize
  characteristics
• Release scope what is included in each release
• Release dates

15
XP Planning game

• Goal Maximize value of software produced
• Strategy Invest as little as possible to get
  most functionality as quickly as possible
• Three phases
• Exploration delimit possible scope
• Commitment choose release scope, date
• Business sorts stories (features) into three
  categories essential, important, and nice to
  have
• Development sorts stories by risk can precisely
  estimate, can estimate reasonably well, those
  that cannot be estimated
• Business chooses the scope, those story cards
  that can meet the schedule, or the schedule is
  readjusted to meet scope
• Steering adjust plan
• Add, remove, or adjust stories

16
XP Planning Game - Exploration

• Goal Find out/decide what the system can do
• Moves
• Write a story (client)
• Estimate a story (developer)
• Split or combine stories

17
XP Planning game - commitment

• Business chooses scope and date of next release
• Development commits to it
• Moves
• Sort stories (essential, important, nice)
• Sort by risk (precise estimate, guess, no clue)
• Development sets velocity (ideal vs calendar
  time)
• Business chooses scope (which stories/tasks)

18
XP Planning game - Steering

• Update and adjust plan
• Moves
• Client can choose stories for iteration
• Recovery
• Developer asks client to reprioritize
• Add/Replace story
• Re-estimate

19
Crystal

• One methodology cannot fit all projects
• What/how to adapt to project
• Classify projects by
• Size (number of developers)
• Criticality Loss that a malfunction would cause
• Life
• Essential money
• Discretionary money
• Customer comfort
• Priority (time pressure)

20
Three defined methodologies

• Darker color, heavier the methodology
• Crystal clear
• Non critical projects
• Teams of six to eight
• Crystal orange
• Critical but not life critical
• Teams up to 40 people
• Crystal orange web
• Need more that these three
• Life-critical
• Large-scale projects
• Etc.

21
Adjusting methodologies

• Larger methodologies for larger teams
• Heavier methodologies for more critical projects
• Preference to lighter methodologies since weight
  is costly
• Give preference to interactive communication over
  formal documentation
• Understand that people vary. High-discipline
  processes are harder to adopt
• Assume people want to be good citizens

22
Crystal - Properties

• Frequent delivery
• At least every few months
• Types of delivery all users, limited users, only
  demo
• Reflective improvement
• Always thinking what can be improved
• Close communication
• Team members in close proximity
• Personal safety
• No reprisals for speaking up
• Focus
• Minimize disruptions
• Easy access to expert users
• Get expert advise when needed
• Good technical environment
• Automated tests, configuration management, and
  frequent integration

23
Clear Non-Critical Orange Not Life Critical
Teams One team, same room Different teams for system planning, project monitoring, architecture, technology, functions, infrastructure and external testing
Roles/ Separate people At least 4 people, playing the roles of Sponsor, Senior designer, programmer, user. Other roles may be filled by the same people, including Project manager, Business expert, Requirements gatherer 14 different roles, played by different people, including (besides those of Crystal Clear), Project Manager, Sponsor, Business Expert, Architect, Design Mentor, Tester and UI designer.
Work products 9 items, including schedule, use cases, design sketches, test cases and user manuals. 13 items, including those in Crystal Clear plus requirements documents, status reports, UI design documents and Inter-team specs. Work products are developed until they are understandable, precise and stable enough for peer review.
Maximum Release length 2 months 2-4 months, two user viewings per release
Figure 5.2 Comparison of Crystal Clear and
Crystal Orange
24
Crystal Common features across all crystal
methodologies

• Progress tracked by deliveries, not by documents
• Automated regression testing
• Direct user involvement
• Two user viewings per release
• Methodology tuning workshops
• Mandatory policy standards
• Coding style etc. left to local standards
• Techniques for individual roles are left to
  individual

These are similar to XP
25
Unified Process as Agile

• UP is a framework
• Does not specify particular techniques for all
  phases
• UP usually considered heavy
• All requirements at inception
• Architecture, design upfront
• RUP mandates many documents/artifacts
• But
• Iterative and incremental
• UP doesnt really require all products, RUP does
• Restrict products, eliminate roles, add
  iterations

26
Microsoft Solutions Framework

• Framework, not methodology (one level up)
• Can be done as agile
• Components
• Foundational principles
• Models
• Disciplines
• Key concepts
• Proven practices
• Recommendations

27
MSF Foundational Principles

• Foster open communications
• Work toward a shared vision
• Empower team members
• Establish clear accountability and shared
  responsibility
• Focus on business value
• Stay agile, expect change
• Invest in quality
• Learn from all experiences

28
MSF Team model
Role Key quality goal
Program management Delivery within project constraints
Development Delivery to product specifications
Test Ensuring each release addresses all issues
Release Management Smooth deployment and ongoing management
User Experience Enhanced user performance
Product Management Satisfied customers
29
MSF Process Model
Phase Milestone (deliverable) Mindset
Envisioning Approved vision/scope Exploratory
Planning Approved project plans Investigatory
Developing Scope complete (all features implemented) Creative (design)
Stabilizing Approved Release Readiness (debugged functionality complete) Single-Minded (find and correct bugs)
Deploying Deployment complete (for this release) Disciplined
30
MSF Management disciplines

• Project Management
• Risk Management
• Readiness Management

31
Open Source Development

• Make source open, allow users to modify
• Many developers give code back, improve program
• Success stories Linux, Apache, MySQL
• Not really agile

32
Open Source vs. Agile

• Similarities
• Small releases
• Informal communications
• Customer availability
• Continuous integration
• Shared Vision

• Differences
• Larger teams
• Distributed teams
• Scaling

33
Agile vs Traditional
Agile Traditional / Heavy
Requirements Assumes change Informal requirements Constant user interaction Assumes no change Complete, detailed, formal requirements document
Design Informal Iterative Formal Upfront
User involvement Crucial Frequent Beginning (Requirements) End (Acceptance testing)
Documentation Minimal, only as needed Source code. heavy, formal documents
Communication Informally Throughout the project. Documents Formal memos and meetings
Complexity Low High.
Overhead Low High
34
Process vs. Project
Agile (XP) Traditional (RUP)
Scope/size Small. One team, 3-10 people. Large projects. Can be scaled down
Criticality Relatively low. Not for life-critical systems Higher
People Team players 'good citizens Good developers Almost anybody Different roles
Company Culture Small co-located companies Relaxed cultures. Larger companies Geographically remote sites Formal cultures.
Stability Not needed Copes with changes in requirements or environment. Assumes stable environment and requirements Less suited to cope with changes.
35
Agile vs. Traditional

• Advantages
• Simpler
• Low cost, overhead
• Deals with changes
• Fast results
• Usable systems

• Risks, Disadvantages
• Not scalable
• Relies on teamwork
• Relies on access to customer
• Cultural clash