Seven Phases of a Software Life Cycle |
The purpose of the requirements phase
is to establish the client’s needs.
Steps:
1. Interview
Client
Formal interviews
are conducted to find out what the client
wants and then a preliminary requirements
document is created. The document contains
the main features of the software and
diagrams of the interface the client has
in mind.
2.
Requirements Analysis
All items in the preliminary requirements document are given to the client to get
their priorities. The client ranks each preliminary requirement using categories
such as essential, highly desirable, desirable and so on.
This information is important for the cost benefit analysis to be performed later.
3.
Rapid Prototyping
A hastily built software that exhibits
the key functionality of the target product.
A rapid prototype is then developed to
enable the client and the developers to
agree as soon as possible on what the
product is to do. The customer and the
intended users use the rapid prototype
while the development team watches and
takes notes. The rapid prototype is then
changed until the client is satisfied.
The purpose of the Specification Phase
is to develop a Specification document
that precisely describes what the product
must do. There should be no ambiguities
in the document as the document is also
the contract between the client and Xyon.
The specification document should describe
what the product must do, it must never
say how the product is to do it. Don’t
forget, questions here are “What?” not
“How?”
The Specification document
The Specification document must be informal
enough for the client, formal enough for
developers and free of omissions, contradictions
and ambiguities. Constraints to be discussed
are
- Cost i.e. budget
- Time i.e. deadline
- Parallel running
- Portability
- Reliability
- Rapid response time and others.
Acceptance criteria
These are the criteria that determine
whether the product is complete or not.
It is vital to spell out a series of
tests. If the product passes the tests,
it is deemed to have satisfied its specifications.
Some acceptance criteria are restatements
of constraints but must be mentioned
again.
Informal methods such as natural language
are not a good way to specify a product,
as they are full of ambiguities. Formal
methods such as finite state machines
and Petri nets are also troublesome
as they are too complicated for the
client to understand. We shall use a
semiformal method that is a good balance
between the two called the Gane and
Sarsen method.
Gane and Sarsen method
The method of Gane and Sarsen/De Marco/Yourdon has resulted in major improvements
in the software industry. This is a Nine-step method.
1. Data flow diagram (DFD)
2. Decide What Parts to Computerize
3. Refine Data Flows
4. Refine Logic of Processes
5. Refine Data Stores
6. Define Physical Resources
7. Determine Input/Output Specs
8. Perform Sizing
9. Hardware Requirements
Here is an example to describe these steps. “Sally’s Software Shop buys software
from various suppliers and sells it to the public. Popular software packages are
kept in stock, but the rest must be ordered as required. Institutions and corporations
are given credit facilities, as are some members of the public. Sally’s Software
Shop is doing well, with a monthly turnover of 300 packages at an average retail
cost of $250 each.”
Data flow diagram (DFD)
Data flow diagram (DFD) shows the logical
data flow, “what happens, not how it
happens.”
Notation:
Step 1. Draw the DFD
First refinement.
Infinite number of
possible interpretations.
Second
refinement
PENDING ORDER is scanned daily
Portion of third refinement
Step 2. Decide What Parts to
Computerize
Depends on how much the client is prepared
to spend. Perform a cost/benefit
analysis with the client.
Step 3. Refine Data Flows
Data items for each data flow
Refine each flow stepwise
Refine further
Need a data dictionary
A sample data dictionary is shown below.
Step 4. Refine Logic of Processes
Have process give educational discount
Sally must explain discount for educational
institutions
10% on up to 4 packages, 15% on 5 or
more
Translate into decision tree
Advantage of a decision tree is that
missing items are quickly apparent.
Step 5. Refine Data Stores
Step
6. Define Physical Resources
For
each file, specify
File name
Organization (sequential, indexed, etc.)
Storage
medium
Blocking factor
Records (to field level)
Step 7. Determine Input/Output Specs
Specify input forms, input screens,
and printed output. It is necessary
to draw out each different Input/Output
screen here.
Step 8.Perform Sizing
Numerical data for step 9 to determine
hardware requirements
Volume of input (daily or hourly)
Size, frequency, deadline of each printed
report
Size, number of records passing between
CPU and mass storage
Size of each file
Step 9 to determine hardware requirements
Volume of input (daily or hourly) Size,
frequency, deadline of each printed
report Size, number of records passing
between CPU and mass storage Size of
each file
Step
9.Hardware Requirements
Mass
storage for back-up
Input needs
Output devices
Is existing hardware adequate?
If not, recommend buy/lease.
The
purpose of the Object-Oriented Analysis
Phase is to use all the features of
object oriented programming (OOP) to
create efficient classes. This increases
readability, reusability and manageability
of the code.
Object consists of data (attributes,
state variables, instance variables,
fields, data members), and actions (methods,
member functions).
The
Three Steps of OOA
1.
Use-case modeling
Determine how the various results are
computed by the product without sequencing,
largely action-oriented.
2.
Class modeling (“object modeling”)
Determine the classes and their attributes.
Purely data-oriented.
3.
Dynamic modeling
Determine the actions performed by or
to each class. Purely action-oriented.
The end result should look something
like the following example
The aim of the design phase is to
design the product in terms of the classes
extracted during the OOA phase.
Object-Oriented Design (OOD) consists
of four steps:
1. Construct interaction diagrams for
each scenario
2. Construct the detailed class diagram
3. Design the product in terms of clients
of objects
4. Proceed to the detailed design
Step
1.
Construct
interaction
diagrams
for
each
scenario
Sequence diagrams
Collaboration diagrams
Both show the same thing
Objects and messages passed between
them but in a different way
Step 2.
Construct the detailed class
diagram
Do we assign an action to a class or
to a client of that class?
Criteria
Information hiding
Reducing number of copies of each action
Responsibility-driven design
Examples
“close doors” is assigned to Elevator
Doors
“move one floor down”
is assigned to Elevator
Step
3.
Design
the
product
in
terms
of
clients
of
objects
Draw an arrow from an object to a client
of that object
Objects that are not clients of any
object have to be initiated, probably
by the main method
Additional methods may be needed
Step
4.
Perform
the
detailed
design
Create detailed design of method elevator
controller loop
Testing
during the Design Phase
The design must correctly reflect the
specifications
The design itself must be correct
Transaction-driven inspections
Challenges
of the Design Phase
The design team should not
do too much i.e.
the design shouldn’t become code.
The design
team should not do too little, it is essential
for the design team to produce a complete
detailed design.
Using all the information gathered
during the previous phases, the software
is now coded and tested.
A major challenge of the implementation
phase has to be met in the phases that
precede the implementation phase.
A language should be chosen using the
following criteria.
Cost-benefit analysis
Compute costs, benefits of all relevant
languages
Once a language has been chosen coding
can begin. It is very important to follow
all the coding standards so that the code
can be easily understood by the maintenance
engineers. Xyon’s coding standards are
explained in detail in the document titled
“Coding Rules”.
During the implementation phase, testing
is constantly done and the code is more
or less error free. Once the developer
has finished coding, the software is handed
over to the SQA team for another cycle
of through testing. The procedure for
testing is explained in the document title
“Software Testing”.
Complete
documentation for the software is also
put together here.
Challenges of the Implementation Phase
Module reuse
needs to be built into the product from
the very beginning
Reuse must be a client requirement
The software project management plan must
incorporate reuse.
The final acceptance test is conducted
and once passed the software is delivered
and installed for the client.
Strategy for Final Product Testing
The SQA team must try to approximate
the acceptance test
Black box test cases for the product
as a whole
Robustness of product as a whole
Stress testing (under peak load)
Volume testing (e.g., can it handle
large input files?)
Check all constraints
Timing constraints
Storage constraints
Security constraints
Compatibility
Review all documentation to be handed
over to the client
Verify the documentation against the
product
The product (code plus documentation)
is now handed over to the client organization
for acceptance testing
Acceptance Testing
The client determines whether the product
satisfies its specifications.
Performed
by
The client organization, or
The SQA team in the presence of client
representatives, or
An independent SQA team hired by the
client
Four major components of acceptance
testing
Correctness
Robustness
Performance
Documentation
(Precisely what was done by developer
during product testing)
Challenges of the Implementation
and Integration Phase
Management issues are paramount here
Test case planning
Communicating changes to all personnel
Deciding when to stop testing
Types of maintenance
Corrective maintenance
To correct residual faults
Specification, design, implementation,
documentation, or any other types of faults
On average, 17.5% of maintenance
Perfective maintenance
Client requests changes to improve product
effectiveness
Add additional functionality
Make product run faster
Improve maintainability
On average, 60.5% of maintenance
Adaptive
maintenance
Responses to changes in the environment
in which the product operates
The product is ported to a new compiler,
operating system, and/or hardware
A change to the tax code
9-digit ZIP codes
On average, 18% of maintenance
Difficulty of Maintenance
About 67% of the total cost of a product
accrues during the maintenance phase
Maintenance is a major income source
Nevertheless, even today many organizations
assign maintenance to
Unsupervised beginners,
and
Less competent programmers
A maintenance programmer must have superb
debugging skills
The fault could lie anywhere within the
product
The original cause of the fault might
lie in the by now non-existent specifications
or design documents
Reverse Engineering
When the only documentation is the code
itself
Start with the code
Recreate the design
Recreate the specifications (extremely
hard)
CASE tools help (flow charters, other
visual aids)
Definitions
Reengineering
Reverse engineering, followed by forward
engineering
Lower to higher to lower levels of abstraction
Restructuring
Improving product without changing functionality
Pretty printing, structuring code, improving
maintainability
What if we have only the executable
code?
Treat as black box
Challenges of the Maintenance Phase
The development-then-maintenance model
is unrealistic today
The client’s requirements frequently
change before the product is delivered
Faults often have to be fixed before
the product is delivered
Development from scratch is almost unknown
today.
Instead, products are built from reused
components.
Products are modified before delivery.
|