Last modified: Mar 11, 2014
Software Process Models
A software development process is a structured series of activities that comprise the way in which an organization develops software projects.
The Waterfall Model
Some of the names of the phases in this process model are the same as the names of some of our workflows.
You need to rely on context to know whether “Design” is referring to a workflow or to a phase of the development process.
This phase establishes what the customer requires from a software system. The primary product of this phase is a requirements document.
What is a requirement?
May range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification
This is inevitable as requirements may serve a dual function
May be the basis for a bid for a contract - therefore must be open to interpretation
May be the basis for the contract itself - therefore must be defined in detail
Both these statements may be called requirements
Sample Reqts Specification
1.1 The user should be provided with facilities to define the type of external files
1.2 Each external file type may have an associated tool which may be applied to the file.
1.3 Each external file type may be represented as a specification from the user’s display.
1.4 Facilities should be provided for the icon representing an external file type to be defined by the user.
1.5 When the user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon.
The requirements document
The requirements document is the official statement of what is required of the system developers
Specify external system behaviour
Specify implementation constraints
Serve as reference tool for maintenance
It is not a design document. As far as possible, it should indicate WHAT the system should do rather than HOW it should do it
This phase seeks to derive a solution which satisfies the software requirements. The primary product of this phase is design documentation.
Phases of design
architectural design, the collection of decisions that need to be common to all components.
Examples of architectural design decisions would be
Will the system run on a single machine or be distributed over multiple CPUs?
Will outputs be stored in a file or in a database?
How will run-time errors be handled?
high-level design, dividing the system into components, and
low-level design (choosing the data structures and algorithms for a single component).
Writing the code – probably the most familiar activity.
The primary product of this phase is code – both application and test code.
Verification & Validation: assuring that a software system meets the users’ needs. The primary product of this phase is a test report.
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.
V & V
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.
As requirements evolve and bug reports come in from the field, someone must
prioritize changes
make the changes
validate the changes
new test cases
validate that change does not break previously working code
regression testing
A variety of related approaches (e.g., Extreme Programming)
a counter-reaction to what many believe to be an overly rigid waterfall model
emphasize quick cycles of development, usually with earlier and more user-oriented validation
Specification (analysis) and development are interleaved.
Each version adds a small amount of additional functionality.
Iterative Development
Advantages:
conducive to exploration of alternatives
e.g., throw-away prototyping
can lead to insight into poorly understood requirements (e.g., GUIs)
Disadvantages:
poor process visibility (e.g., are we on schedule?),
continual small drifts from the key architecture leading to poorly structured systems.
General OO Analysis & Design
OOAD is largely viewed as a model-building activity. The primary models that we find are
domain model
analysis model
design model
and OOAD emphasizes a smooth evolution from one to the other.
The domain model describes the world in terms of objects interacting with one another via messages.
Not every project needs a domain model (e.g., If the team has done several projects already in this application domain)
An analysis model is a model of how the world will interact with the software system that we envision. As such, it is our statement of just what the system will do when it is working.
Or if you prefer,…
It’s Magic!
Not wrong, per se, but it’s certainly not helpful.
Such an approach is fundamentally at odds with the OO philosophy
We should look to the real world to suggest how to decompose our system.
Evolving the Analysis Model
What we really hope for is an evolution from our domain model to our analysis model. The OO philosophy tells us that the classes and interactions of our domain model …
retain these classes
add more detail to our understanding of them, and …
The Boundary
be automated
remain external
be a mixture of the two
The system, then, remains a collection of interacting objects rather than an unstructured black box.
Design is concerned with how we can get the system to do the things the analysis model says it should do.
Designs are expressed via a design model,
hopefully, evolved from the analysis model
Design Model: Agents
Design Model: Agents (2)
Design Model: Interfaces
What do we call an interaction between an external entity and an internal automated entity?
Design Model: Interfaces
MVC
A common organizing principle for such interfaces is to distinguish between
viewers that portray the contents of automated classes and
controllers that accept external signals (e.g., mouse clicks, keyboard data) and interpret those signals as instructions to automated classes and to viewers.
Such viewers and controllers should be implemented as separate classes from the model classes that were derived from the analysis model.
MVC Example
Model-View-Controller
The MVC pattern establishes specific requirements so that GUI changes have minmal impact on the rest of the system.
The model classes must not depend on (make use of the interface of) the view and controlelr classes.
The view classes must not depend on the controller classes
For larger projects, we may want something a bit more formal than the general OOA&D process.
The Unified Process was developed by Jacobsen, Booch, and Rumbaugh, who were already some of the biggest names in OOA&D before they decided to collaborate on a unified version of their previously distinctive approaches.
Unified Model Phases
Inception: initial concept
Elaboration: exploring requirements
Construction: building the software
Transition: final packaging
Pitching the project concept
Usually informal, low details.
“Perhaps we should build a … ”
Adding detail to our understanding of what the system should do.
Produces
Domain model
Analysis model
Requirements document
Release plan
Among these products, only the release plan is new.
In point of fact, each of the process phases may be divided into increments:
Such increments are most common in the elaboration and construction phases.
Each increment produces a release - some kind of product whose existence and/or acceptance by management shows that we are ready to move on.
A release represents the implementation of some part of the required functionality.
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
Perhaps the most familiar of the phases. This merges the waterfall activities of Design and Implementation.
Each construction increment adds new functionality
Documentation is constructed in addition to source code
Each increment must be separately tested
Each increment must be integrated and tested
Activities that can’t be done incrementally during construction, e.g.,
performance tuning
user training
It should be noted again that the software development process model provides overall strategic guidance. The day-to-day “tactical” activity is still described by our four workflows.