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

Waterfall Model (review)

  • Heavyweight, single-pass, strong planning-based approach
  • “Big Bang” approach described in Head First book exhibits similar characteristics
  • Extreme amounts of time spent on planning compared to implementation
  • Each phase is completed and verified before another phase is started
  • Personnel become experts in individual phases
  • Formal artifacts required for each step
  • Feedback to previous step

Prototyping (review)

  • Idea: Difficult to determine requirements without some sort of running system, so build a prototype to get requirements
  • “Build one to throw away”
  • Develop first version cheaply: Very high-level languages, less features (particularly non-functional requirements of speed, robustness, quality)
  • Heavyweight, two-pass, approach with more feedback
  • Good idea, but not good enough. Still necessary to gather all requirements during the prototype
  • Another issue: perception of prototype as completed system

Agile Methods

  • Lightweight, doing (vs planning), multiple pass, 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 then 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 - 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 next 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 are used for comprehension and to support collective ownership
  • Continuous integration - Code is 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 a strong use of components
  • Modeling & UML - Development of models, use of UML
  • Quality of process and product - responsibility of everyone, 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 complete software system
  • Test - all types of testing
  • Deployment - external release and integration into 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

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