Software Development Process Models
Steven J Zeil
Last modified: Dec 27, 2023
1 Software Development Process Models
A software development process model (SDPM), a.k.a., a software life-cycle model, is the process by which an organization develops software.
- Projects typically broken into phases
- There are varying criteria for entering or exiting each phase
1.1 Common Activities
- Recognition of problem / need / opportunity
- Feasibility study
- Analysis of requirements
- Design of system
- Implementation
- Testing
- Deployment
- Maintenance
Different SDPMs will divide these activities among phases in different ways.
1.1.1 Analysis of Requirements
1.1.1 Analysis of Requirements
1.1.1 Analysis of Requirements
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
- Enumerate precisely what the new system will do
Common Documents from Requirements Analysis
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
- Enumerate precisely what the new system will do
Common Documents from Requirements Analysis
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
- Enumerate precisely what the new system will do
Common Documents from Requirements Analysis
- Feasibility report
- Software Requirements Specification (SRS)
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
- Enumerate precisely what the new system will do
Common Documents from Requirements Analysis
- Feasibility report
- Software Requirements Specification (SRS)
- Detailed statement of problem
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
- Enumerate precisely what the new system will do
Common Documents from Requirements Analysis
- Feasibility report
- Software Requirements Specification (SRS)
- Detailed statement of problem
- Functional requirements
1.1.1 Analysis of Requirements
-
Examine existing system.
- How does it work?
- What are its shortcomings?
-
Propose a new system
- Enumerate precisely what the new system will do
Common Documents from Requirements Analysis
- Feasibility report
- Software Requirements Specification (SRS)
- Detailed statement of problem
- Functional requirements
- Constraints on the system
We’ll look at requirements in more detail in a later section.
1.1.2 Design
Derive
a solution which satisfies the software requirements.
Commonly recognized subproblems include
-
architectural design,
- the collection of decisions that need to be common to all components.
-
high-level design,
- dividing the system into components, and
-
low-level design
- choosing the data structures and algorithms for a single component.
A possible breakdown of design activities
1.1.3 Maintenance
Maintenance can have a number of forms:
1.1.3 Maintenance
Maintenance can have a number of forms:
1.1.3 Maintenance
Maintenance can have a number of forms:
1.1.3 Maintenance
Maintenance can have a number of forms:
1.1.3 Maintenance
Maintenance can have a number of forms:
1.1.3 Maintenance
Maintenance can have a number of forms:
- Corrective
- Adaptive
- Perfective
1.1.3 Maintenance
Maintenance can have a number of forms:
- Corrective
- Adaptive
- Perfective
1.1.3 Maintenance
Maintenance can have a number of forms:
- Corrective
- Adaptive
- Perfective
- adding features
- improving performance
1.1.3 Maintenance
Maintenance can have a number of forms:
- Corrective
- Adaptive
- Perfective
- adding features
- improving performance
- Preventative
1.1.3 Maintenance
Maintenance can have a number of forms:
- Corrective
- Adaptive
- Perfective
- adding features
- improving performance
- Preventative
- refactoring to improve maintainability
1.1.3 Maintenance
Maintenance can have a number of forms:
- Corrective
- Adaptive
- Perfective
- adding features
- improving performance
- Preventative
- refactoring to improve maintainability
- Refactoring is a change made that preserves the current behavior of the system.
2 The Waterfall Model
-
The best known process model
- dates from 1970’s
- though widely derided, it remains widely used
- and its terminology forms the basis for almost all discussions of other SDPMs
-
Defining characteristic: movement from phase to phase is always forward (downhill), irreversible
- Milestones are set at each phase transition
- schedule deadlines
- required reports
- required approval to move on
2.1 Verification & Validation
Verification & Validation: assuring that a software system meets the users’ needs.
The principle objectives are:
- The discovery of defects in a system
- The assessment of whether or not the system is usable in an operational situation.
2.1.1 What’s the Difference?
2.1.1 What’s the Difference?
2.1.1 What’s the Difference?
-
Verification:
- “Are we building the product right” (Boehm)
2.1.1 What’s the Difference?
-
Verification:
- “Are we building the product right” (Boehm)
- The software should conform to its (most recent) specification
2.1.1 What’s the Difference?
-
Verification:
- “Are we building the product right” (Boehm)
- The software should conform to its (most recent) specification
-
Validation:
2.1.1 What’s the Difference?
-
Verification:
- “Are we building the product right” (Boehm)
- The software should conform to its (most recent) specification
-
Validation:
- “Are we building the right product”
2.1.1 What’s the Difference?
-
Verification:
- “Are we building the product right” (Boehm)
- The software should conform to its (most recent) specification
-
Validation:
- “Are we building the right product”
- The software should do what the user really requires
Testing
- Testing is the act of executing a program with selected data to uncover bugs.
- As opposed to debugging, which is the process of finding the faulty code responsible for failed tests.
- Testing is the most common, but not the only form of V&V
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
- System Test: Test of the entire system,
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
- System Test: Test of the entire system,
- supervised by team leaders or by V&V specialists.
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
- System Test: Test of the entire system,
- supervised by team leaders or by V&V specialists.
- Many companies have independent teams for this purpose.
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
- System Test: Test of the entire system,
- supervised by team leaders or by V&V specialists.
- Many companies have independent teams for this purpose.
- Regression Test: Unit/Integration/System tests that are repeated after a change has been made to the code.
2.2 Testing throughout the Waterfall
2.2.1 Testing stages
- Unit Test: Tests of individual subroutines and modules,
- Integration Test: Tests of “subtrees” of the total project hierarchy chart (groups of subroutines calling each other).
- generally a team responsibility.
- System Test: Test of the entire system,
- supervised by team leaders or by V&V specialists.
- Many companies have independent teams for this purpose.
- Regression Test: Unit/Integration/System tests that are repeated after a change has been made to the code.
- Acceptance Test: A test conducted by the customers or their representatives to decide whether to purchase/accept a developed system.
2.2.2 Not just in one phase
Although the waterfall model shows V&V as a separate phase near the end, we know that some forms of V&V occur much earlier.
- Requirements are validated in consultation with the customers.
- Unit testing occurs during Implementation, etc.
So this phase of the waterfall model really describes system and acceptance testing.
A Still-broader View
Even the “V&V V” does not capture the full context of V&V:
- Requirements must be validated
- Designs may be validated & verified
- Maintenance changes are tested
2.3 Advantages of Waterfall
- Linear structure is easy to understand
- Development progress is easily estimated and explicitly documented
- Widely known
- Scales well
2.4 Disadvantages of Waterfall
- Inflexible: corrections limited to current phase
- In some projects, requirements are not known or understood early in the life-cycle
- Working version of system is only available near the end
- Often becomes a documentation mill
3 Iterative/Incremental Development
- A variety of related approaches
- a counter-reaction to what many believe to be an overly rigid, management-focused, waterfall model
- emphasize quick cycles of development, usually with earlier and more user-oriented validation
- Requirements specification, design and implementation are interleaved.
- Each version adds a small amount of additional functionality.
Iterative versus Incremental Models
Iterative versus Incremental Models
-
Iterative – we do some set of process steps repeatedly.
To use a programming analogy, this is iterative:
while (!done) {
⋮
}
Iterative versus Incremental Models
-
Iterative – we do some set of process steps repeatedly.
To use a programming analogy, this is iterative:
while (!done) {
⋮
}
-
Incremental – we accumulate value in small steps.
To use a programming analogy, this is incremental:
total += x;
Incremental development is almost always iterative, but you can be iterative without being incremental.
Variations
-
Some projects employ throw-away prototyping, versions whose code is only used to demonstrate and evaluate possibilities.
- This can lead to insight into poorly understood requirements.
-
Evolutionary prototyping keeps the prototypes, gradually evolving them into the final deliverable
-
Some waterfall projects may employ incremental schemes for parts of large systems (e.g., the user interface).
3.1 Advantages
- Ability to explore poorly understood requirements
- Flexibility
- Working implementation is available early.
3.2 Disadvantages
-
Poor process visibility (e.g., are we on schedule?),
-
Continual small drifts from the main architecture leading to poorly structured systems.
-
Dead-ends (the local optimization problem)
4 The Spiral Model
1986, Boehm
An iterative approach with a focus on risk management
4 The Spiral Model
1986, Boehm
An iterative approach with a focus on risk management
4 The Spiral Model
1986, Boehm
An iterative approach with a focus on risk management
4 The Spiral Model
1986, Boehm
An iterative approach with a focus on risk management
4 The Spiral Model
1986, Boehm
An iterative approach with a focus on risk management
4 The Spiral Model
1986, Boehm
An iterative approach with a focus on risk management
Spiral Phases
- Determine objectives, alternatives and constraints:
- Define requirements
- Alternatives (including, e.g., 3rd-party code) identified
- Constraints defined
- Identify and resolve risks, evaluate alternatives:
- Evaluate identified alternatives
- Identify risks
- Resolve risks
- Produce prototype
- Develop and test
- Analyze performance of prototype
- Create & review design, code, test
- Plan next iteration
- Often includes customer evaluation of prototype or current project iteration
4.1 Advantages of Spiral Model
- Flexible – emphasis on alleviating risks as they are identified
- Considerable opportunity for validation
- Scales well
- Good process visibility
- Working releases/prototypes produced early
4.2 Disadvantages of Spiral Model
- Can be costly (slow?)
- Risk analysis is a specialized skill, but critical to project success
5 Rational Unified Process
- 1997, Jacobsen, Booch, and Rumbaugh,
5.2 Unified Model Phases Continued
Releases
One task during Elaboration is to plan releases:
-
Major phases are divided into increments, each of which ends with a release.
-
A release is some kind of product that implements some part of the required functionality
- Its existence and/or acceptance by management shows that we are ready to move on.
-
The release plan records decisions about
- How many releases there will be
- What functionality will be added with each release
- When the releases will be made
- Which releases are internal (i.e., only the development team sees them) and which are external
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
- Although waterfall and other SDPMs treat analysis, design, etc., as one-time phases
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
- Although waterfall and other SDPMs treat analysis, design, etc., as one-time phases
- Careful study shows that developers do analysis, design, etc., activities continuously.
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
- Although waterfall and other SDPMs treat analysis, design, etc., as one-time phases
- Careful study shows that developers do analysis, design, etc., activities continuously.
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
- Although waterfall and other SDPMs treat analysis, design, etc., as one-time phases
- Careful study shows that developers do analysis, design, etc., activities continuously.
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
- Although waterfall and other SDPMs treat analysis, design, etc., as one-time phases
- Careful study shows that developers do analysis, design, etc., activities continuously.
5.3 Key Concepts of the RUP
5.3.1 Common Workflows
- Although waterfall and other SDPMs treat analysis, design, etc., as one-time phases
- Careful study shows that developers do analysis, design, etc., activities continuously.
ADIV
In the RUP, all progress is made as continual ADIV cycles
- ADIV: Analysis, Design, Implementation, Validation
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
- Ensures that the development team understands the world that the system will work in.
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
- Ensures that the development team understands the world that the system will work in.
-
Analysis Model
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
- Ensures that the development team understands the world that the system will work in.
-
Analysis Model
- A model of how the world will interact with the software system that we envision.
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
- Ensures that the development team understands the world that the system will work in.
-
Analysis Model
- A model of how the world will interact with the software system that we envision.
- Expresses what the system will do when it is working.
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
- Ensures that the development team understands the world that the system will work in.
-
Analysis Model
- A model of how the world will interact with the software system that we envision.
- Expresses what the system will do when it is working.
-
Design Model
5.3.2 An Evolution of Models
RUP supports development via a series of models.
The most important of these are
-
Domain Model
- A model of the application domain as it currently exists, before we began our new development project.
- Ensures that the development team understands the world that the system will work in.
-
Analysis Model
- A model of how the world will interact with the software system that we envision.
- Expresses what the system will do when it is working.
-
Design Model
- Describes how we can get the system to do the things the analysis model says it should do.
Models Evolved
RUP embraces the
Object-Oriented philosophy
Models Evolved
RUP embraces the
Object-Oriented philosophy
- Every program is a simulation
Models Evolved
RUP embraces the
Object-Oriented philosophy
- Every program is a simulation
- The quality of a program’s design is proportional to how faithfully the objects and interactions in the program reflect those in the real world
Models Evolved
RUP embraces the
Object-Oriented philosophy
- Every program is a simulation
- The quality of a program’s design is proportional to how faithfully the objects and interactions in the program reflect those in the real world
Models Evolved
RUP embraces the
Object-Oriented philosophy
- Every program is a simulation
- The quality of a program’s design is proportional to how faithfully the objects and interactions in the program reflect those in the real world
-
Domain, analysis, and design models all focus on how classes of objects interact with one another
-
Most of the classes in the design are presumed to have already been described as part of the analysis model,
Models Evolved
RUP embraces the
Object-Oriented philosophy
- Every program is a simulation
- The quality of a program’s design is proportional to how faithfully the objects and interactions in the program reflect those in the real world
-
Domain, analysis, and design models all focus on how classes of objects interact with one another
-
Most of the classes in the design are presumed to have already been described as part of the analysis model,
- Most of the classes in the analysis model are presumed to have already been described as part of the domain model,
5.4 Advantages of RUP
- Process details are expressed in general terms, allowing local customization
- Heavy emphasis on documentation (UML)
- Can embrace incremental releases
- Evolutionary approach can lead to clean implementations
5.5 Disadvantages of RUP
- Process details are expressed in general terms, providing minimal guidance and requiring local customization
- Complex
- Heavy documentation can be expensive
6 Agile Methods
A modern variant of incremental development.
Agile development is
- A reaction against heavily-managed, documentation-heavy processes
- A social movement within the software development profession
Emphasis Areas
Emphasis is on
- Iterative & incremental development
- Frequent communication with customer representatives
- Work is organized via “user stories”
- Short “time-boxed” development cycles
- Focus on quality as a matter of professional pride
- Adoption of professional best-practices
We’ll look at Agile in more detail later in the semester, after we have learned more about these “best practices” that lie at the heart of the process.
© 2015-2024, Old Dominion Univ.