Software Processes and Process Models

Software Processes and Process Models
An Introduction

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Background

A Definition:
- A process (a.k.a. activity) is a collection of related tasks (a.k.a. actions) that transforms a set of inputs into a set of outputs
Processes and Algorithms:
- The set of algorithms is a subset of the set of processes (which, includes, for example heuristics)
Describing Processes:
- Specify the inputs to and outputs from the process
- Specify the tasks
- Specify the inputs to and outputs from each task (a.k.a. data flows)
- Specify the order of tasks and the conditions under which they occur (a.k.a. control flows)

Overview

Definition of a Software Process:
- A set of actions/tasks (and corresponding inputs and outputs) that results in the specification, development, validation, and/or evolution of a software product
An Observation:
- Software processes are very complex and, hence, our discussion of them will necessarily involve abstraction (i.e., we will really be discussing process models)

Common Actions/Tasks in Software Processes

Project Planning:
- Financial/economic analysis
- Scheduling
- Resource allocation
- Cost estimation
- Risk management
Product Design:
- Identification of needs and desires
- Specification of requirements
- Prototyping

Common Actions/Tasks in Software Processes (cont.)

Engineering Design:
- Creation of static models
- Creation of dynamic models
- Consideration of architectural styles and design patterns
Implementation:
- Development
- Code/documentation management
- Debugging
- Verification and validation
Deployment
Support and Maintenance

Problem Solving/Design Actions/Tasks in Software Processes

An Observation:
- Many of the actions/tasks in software processes are said to involve "problem solving" and/or "design"
For Our Purposes:
- Problem solving and design involve the same (or at least the same kind of) steps

Generic Problem Solving/Design Actions

The Tasks:
- Identification of goals, objectives and constraints
- Generation of alternatives
- Evaluation of alternatives
- Selection of an alternative
Categorizing the Actions:
- Analysis (to understand the problem)
- Resolution (to solve the problem)

Models of Software Processes

As Always:
- Since they are models they are simplifications (and some are very abstract)
Types of Models of Software Processes:
- Descriptive (a.k.a positive)- what actually happens
- Prescriptive (a.k.a. normative) - what should (i.e., is supposed to) happen

The Waterfall Model

The Traditional Presentation:
Problems with the Textbook:
- Confusing action names
- Incorrect arrows for flows

The Waterfall Model (cont.)

Questions:
- Is it supposed to be positive/descriptive or normative/prescriptive?
- How idealized/abstract is it?
Modifications:
- Recognize overlap
- Include feedback
- Include iteration

The Spiral Model

Boehm (1988)

The Spiral Model (cont.)

Contributions:
- Explicit incorporation of increases in detail (i.e., decrease in abstraction)
- Explicit incorporation of risk
- One of the early iterative processes
Risk:
- In software engineering, a risk is an occurrence with negative consequences
Iterative Process:
- A process that contains one or more repeated tasks

Incremental Processes

Definition:
- An incremental process is one that produces its output in phases and the output of each phase is a working version of the software product
Example:
- When a customer orders the breakfast special, the chef can first cook and deliver some of the eggs, then cook and deliver the rest of the eggs and the bacon (an incremental process) or cook all of the eggs and bacon and deliver them at the same time (not an incremental process)

Iterative vs. Incremental Software Processes

Iterative Processes:
- Any software process can be made iterative and most are naturally iterative
Incremental Processes:
- Software processes are sharply distinguished by whether they are incremental (e.g., the waterfall process is not -- the intermediate outputs are not versions of the product)

The Rational Unified Process (RUP)

An Incremental Process - Jacobson, Booch, Rumbaugh (1999)

RUP Stages

Inception:
- Develop use cases
- Estimate the schedule and resource requirements
- Estimate risks
- Create a business case
Elaboration:
- Understand the problem domain
- Create baseline design
- Create test plan
- Decide upon metrics
- Organize resources

RUP Stages (cont.)

Construction:
- Complete the implementation
- Release code to \(\alpha\) testers
- Identify remaining activities
Transition:
- Complete the final release
- Confirm user readiness and acceptance
- Confirm support readiness

The Rational Unified Process (cont.)

Iteration:
- Can occur within a phase
- Can occur between phases
Core Process Workflows:
- Business modeling
- Requirements
- Analysis and design
- Implementation
- Testing
- Deployment
- Configuration and change management
- Project management

Extreme Programming - XP (Beck; 2004)

Basic Principles:
- Ensure rapid feedback
- Embrace change
- Collective ownership
Practices:
- Small releases (every release should be as small as possible containing the most valuable business requirements)
- Have a metaphor for the project (that replaces the architecture)
- Unit tests for every production module and functional tests for features
- Make a small initial investment (i.e., the simplest solution that works is the best) and refactor (i.e., improve) later
- Pair programming (all production code is written with two people working at one computer; one person thinks about the simplest implementation the other things strategically)
- Continuous integration (code is integrated and tested every few hours)
- Strict coding standards

Extreme Programming (cont.)

Participants in the Planning Process:
- Business
- Development
Planning Tools:
- Story cards describe the necessary functionality (in the form of a task description) and an estimate of how long the functionality will take to implement
The Planning Process:
- Exploration - found out what new things the system could do
- Commitment - Decide what subset of all possible requirements to pursue next (Business sorts by value; Development sorts by risk
- Steer - Guide the development (involves iteration, recovery, new story construction, and re-estimation

Scrum (Sutherland and Schwaber; 1995)

Sprints:
- Fixed duration development cycles (usually 1-4 weeks) that end on a specific date (whether the work has been completed or not)
Scrum Roles:
- Product Owner (responsible for achieving maximum business value)
- Team (multi-functional; 5-10 people)
- ScrumMaster (helps the Team be successful; protects the Team)
Process:
- Start of the Sprint: There is a Sprint Planning Meeting at which the Team selects items from a prioritized list of requirements/features and commits to completing them
- Each Day: Members of the Team report (at a standup meeting of 15 minutes or less) on progress
- End of the Sprint: Members of the Team demonstrates what has been built (in a Sprint Review) and get feedback for the next Sprint (in a Sprint Retrospective)

Scrum (cont.)

Terminology:
- The prioritized list of requirements/features is called the Product Backlog
- The tasks being completed are called the Sprint Backlog
- The daily meeting is called the Daily Scrum
- Members of the Team are sometimes called "Pigs" (because they are truly committed to making bacon and eggs) and everyone else is called a "Chicken" (because they are only involved in making bacon and eggs)
Some Details about the Product Backlog:
- The Product Backlog includes a rough estimate of the "size"
- The Product Backlog also contains developer "to dos", exploratory work, and known bugs
- The Product Backlog is updated by the Product Owner

Scrum (cont.)

Scrum - Sprint Planning Meetings

Team members report on their availability
The top item in the product backlog is broken down into tasks that are recorded in the Sprint Backlog
Team members volunteer for the tasks (i.e., take ownership of them) and provide time estimates
The process continues until all available hours are accounted for (Note: Since commitments are being made these meetings can take hours)

Scrum - Sprints

The team should strive to have a working product at the end of every sprint
The Sprint Backlog contains, at a minimum, the tasks, the name of the task owner, the initial estimate, and the hours of work remaining
Teams often post a Sprint Burndown Chart that graphically illustrates the numbers of hours remaining
It is very important that the team have a definition of "Done" that can be used to assess when work is complete on the current increment

Nerd Humor - From Product Backlog to Sprint Backlog

Tasks

(Courtesy of xkcd)

Feature Driven Development - FDD (De Luca; 1977)

The Process:
- Develop an overall model
- Build a feature list
- Plan by feature
- Design by feature
- Build by feature
Practices:
- Individual ownership of classes
- Extensive use of code inspections
- Regular builds

"Heavyweight" vs. "Agile"/"Lean" Methods

A Common Categorization:
- Heavyweight: Waterfall, Spiral
- Agile/Lean: RUP, XP, Scrum, FDD
The Agile Manifesto:
- Value individuals and interactions over processes and tools
- Value working software over comprehensive documentation
- Value customer collaboration over contract negotiation
- Value responding to change over following a plan
Another View:
- The different process involve the same actions/tasks but vary dramatically in the cycle times

Agile Processes

A Generic Model