Agile Software Process Models

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Process Model Characteristics (review)

  • Heavyweight vs. Lightweight
  • Planning vs. Doing
  • Efficiency (skillset, personnel, time to market)
  • Single vs. Multiple passes
  • Role of Maintenance
  • View of Evolution

Agile Methods

  • Lightweight, doing (vs. planning), multiple passes, evolutionary approach
  • Strongly iterative and evolutionary
  • "World is fundamentally chaotic", "Change is inevitable", "Deliver value to the customer".

Agile Manifesto

  • Individuals and interactions are more important than processes and tools
  • Working software is more important than comprehensive documentation
  • Customer collaboration is more important than contract negotiation
  • Responding to change is more important than following a plan

eXtreme Programming (XP)

  • Pure agile approach
  • Given as a set of best practices
  • Pushes good practices to their extreme
  • Design is kept as simple as possible
  • Strongly involves refactoring, test-driven development, etc.

XP: Requirements and Design

  • Metaphor - Simple metaphor (story) to use for the entire system
  • On-site customer - A real user should be a full-time member of the team
  • The planning game - The scope of the next release is quickly determined with the plan updated as necessary
  • Small releases - Simple version released as soon as possible. Short cycles for subsequent releases
  • Simple design - the design is as simple as possible for the current requirements
  • Testing - Developers continuously write unit tests, and customers write acceptance tests

XP: Implementation

  • Refactoring - System is changed to improve design but not affect behavior
  • Pair programming - All code is written together by a pair of programmers using one machine
  • Collective ownership - Any developer can change the code at any time
  • Coding standards - Coding standards to support comprehension and to collective ownership
  • Continuous integration - Code integrated and built continuously
  • 40-hour week - Working overtime is the exception

Rational Unified Process (RUP)

  • Developed by Rational Software (IBM)
  • Much tool support: Rational Method Composer (RMC)
  • Between document-driven and agile approaches
  • Most formal: specific practices, strong tool support

Overall RUP Process

RUP: Phases

  • inception - determine objectives, costs, schedule, and risks
  • elaboration - analysis to determine architecture
  • construction - implementation
  • transition - release, integration into existing systems

RUP Practices

  • Iterative development - carefully planned with measured progress
  • Requirements management - systematic approach, including changes
  • Architecture - Decided early with strong use of components
  • Modeling & UML - Development of models, use of UML
  • Quality of process and product - The responsibility of everyone, with an explicit testing workflow
  • Configuration and change management - Sound procedures and appropriate tool support
  • Use-case-driven development - UML Use Cases describe behavior
  • Process configuration - modified for specific circumstances
  • Tool support - strong, especially for modeling and configuration management

RUP: Main Workflows

  • Business Modeling - context of the delivered software
  • Requirements - detailed idea of what the system needs to do
  • Analysis & Design - overall architecture and blueprint for code
  • Implementation - coding and integration into a complete software system
  • Test - all types of testing
  • Deployment - external release and integration into the customer system

RUP: Supporting Workflows

  • Configuration and change management - configuration, change requests, and measurement
  • Project Management - coarse-grained (overall project) and fine-grained (individual iteration)
  • Environment - tailoring process to project needs

Adoption Reality (for the most part)

  • Companies are already following an agile (e.g., iterative) process
  • Companies think they are following an agile (e.g., iterative) process
  • Companies want to be following an agile (e.g., iterative) process