Software Development Process Models
Steven J Zeil
Last modified: Sep 21, 2016
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
-
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
Maintenence 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 Major Software Development Models
- The Waterfall Model
- Iterative and Incremental Models
- The Spiral Model
- The Rational Unified Process
- Agile Models
3 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
3.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.
3.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
3.2 Testing throughout the Waterfall
3.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.
3.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
- Maintenence changes are tested
3.3 Advantages of Waterfall
- Linear structure is easy to understand
- Development progress is easily estimated and explicitly documented
- Widely known
- Scales well
3.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
4 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 – 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).
4.1 Advantages
- Ability to explore poorly understood requirements
- Flexibility
- Working implementation is available early.
4.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)
5 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
5.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
5.2 Disadvantages of Spiral Model
- Can be costly (slow?)
- Risk analysis is a specialized skill, but critical to project success
6 Rational Unified Process
-
1997, Jacobsen, Booch, and Rumbaugh,
-
Best Practices
- Develop iteratively
- Manage requirements
- Use components
- Model visually
- Verify quality
- Control changes
6.1 Unified Model Phases
6.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
6.3 Key Concepts of the RUP
6.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
6.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
- 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,
6.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
6.5 Disadvantages of RUP
- Process details are expressed in general terms, providing minimal guidance and requiring local customization
- Complex
- Heavy documentation can be expensive
7 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-2016, Old Dominion Univ.