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
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
Initial Implementation Produces a Prototype
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
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
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
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
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