- Forward


Software Processes and Process Models
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Background
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • The Traditional Presentation:
    • waterfall-process
  • Problems with the Textbook:
    • Confusing action names
    • Incorrect arrows for flows
The Waterfall Model (cont.)
Back SMYC Forward
  • 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
Back SMYC Forward

Boehm (1988)

spiral-process
The Spiral Model (cont.)
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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)
Back SMYC Forward

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

rup-process
RUP Stages
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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)
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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)
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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.)
Back SMYC Forward
scrum-process
Scrum - Sprint Planning Meetings
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
    SprintBacklog
  • 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
Back SMYC Forward
Tasks
/imgs
(Courtesy of xkcd)
Feature Driven Development - FDD (De Luca; 1977)
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward

A Generic Model

agile-process
There's Always More to Learn
Back -