Process

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Goal

  • Meet requirements/needs of users
  • On budget
  • On-time
  • Others?

Software Process

Set and sequence of activities that leads to the production of a software product

  • Process Model - Abstraction of the software development process
  • Why study process?

Place of Process

Goals

Process

Methods

Tools

Traditional Software Process Paradigms

  • Waterfall Model
  • Prototype/Spiral Model
  • Component-based

Fundamental Activities

  • Specification
  • Design & Implementation
  • Validation
  • Evolution

Waterfall Model

Waterfall Model

Waterfall Model

Waterfall Model

  • Paradigm from around the time of the NATO conference to deal with the "Software Crisis"
  • Each phase is completed and verified before another phase is started
  • Requirements are gathered first, design is made to support requirements, and the design is used throughout the development process
  • Once delivered, any further problems are considered maintenance
  • Predominant model taught in SE for many years
  • Predominant process model for other engineering disciplines
  • Handles maintenance very differently than initial development

Process & Resources

  • Resources - money, time, expertise, workers, etc.
  • Process requires resources of different types at different times
  • Expertise: Breadth and Depth

Prototype/Spiral Model

Prototype/Spiral Model

Initial Implementation Produces a Prototype

Prototype/Spiral Model

  • The spiral model starts with the creation of a minimalistic prototype that contains only the most essential features
  • This prototype serves as a working model that is shown to the end-users and other stakeholders
  • Based on the feedback received, this prototype is iteratively refined. New features can be added, existing features can be modified, and unnecessary features can be removed
  • Each iteration brings the software closer to the final version that meets all requirements. It also becomes the baseline for the next spiral

Validation/Verification of Requirements

Prototype/Spiral Model

  • One of the benefits of the spiral model is that it permits validation (are we building the right product?) and verification (are we building the product right?) at an early stage
  • Users can interact with the prototype and give immediate feedback, making it easier to capture more accurate requirements
  • This iterative validation/verification process helps in finalizing the product scope and minimizes the likelihood of end-product failure

Risk Assessment

Prototype/Spiral Model

  • Before each iteration (spiral), a risk assessment is conducted. This involves identifying, analyzing, and finding mitigation strategies for risks
  • Risks could range from technical challenges and budget constraints to external factors like market competition
  • Early identification of risk helps in avoiding significant problems later in the project lifecycle
  • The team can decide whether it's feasible to move to the next spiral based on the risk assessment

Maintenance as Extended Development

Prototype/Spiral Model

  • Maintenance, which often follows the software release, can also be considered an extension of the spiral model
  • Any additional features, bug fixes, or performance improvements can be handled as new spirals
  • This allows the software to evolve according to changing user requirements or external factors, making the model particularly adaptable

Downsides

Prototype/Spiral Model

  • The spiral model often involves higher costs because of its iterative nature, repeated prototyping, and the need for thorough risk assessments
  • Each iteration requires workforce, tools, and other resources, making the model expensive for small projects
  • The model is complex and requires a team with a deep understanding of not just the technology stack but also risk assessment methodologies, requirement elicitation, and more
  • Poorly conducted spirals could lead to budget overflows and scope creep, requiring a high level of expertise for effective management

Traditional Software Process

  • May combine paradigms or even with ad-hoc approaches
  • May be used at different levels of development
  • May be transitionary