The Software Development
Process
► Systems
analysis
► Systems design
► Implementation
► Testing
► Documentation
► Evaluation
► Maintenance
1
Systems Analysis
What is a systems analyst?
 A systems analyst observes, clarifies and
models an existing system to assess its
suitability for computerisation.
 They may once have been programmers.
2
Skills and techniques of the
Systems Analyst
The systems analyst must
 extract the clients needs
 document these needs in a formal way
 communicate these to the designers
3
Extracting the Clients Needs
Extracting the clients needs is known as
requirements elicitation.
This is done by:
 interviewing the client.
 make observation of the client’s business
 Inspect information sources used by the
client to keep track of their business.
4
The Requirements Specification
► is
the end result of the requirements
elicitation
► is a written statement of what the design
team must go on to make
It is extremely important to get this
document right. Mistakes made later
can be very costly.
5
Documentation
The systems analyst must document the
clients needs by drafting formal reports:
 requirements specification
 system specification
6
Design Representations
Examples include:
 structure diagrams
 pseudocode
7
Structure Diagram
A commonly used syntax for structure
diagrams is as follows:
A procedure
A decision
A loop
A single
task
8
An example:
A structure diagram :
Tax payment
IF earns >
30000
Get details
NO
Low rate
payable
Display amount
to be paid
YES
High rate
payable
9
Pseudocode
Pseudocode is another example of a method
of describing a program.
Simple English words are used to describe
the steps of the algorithm and any
refinements made.
10
Pseudocode - Example
1.
2.
3.
4.
Notice the
numbering
system
Display information
Get details
Do calculation
Display answer
Refine
2.1
2.2
2.3
2.4
2.5
2.6
step 2
display prompt
get value
while value out of range
display error message
get value
loop
Top level
design
11
An Iterative process
It is important to realise that the software
development process is iterative in nature.
This means that the problem will be revisited
a number of times getting closer and closer to
the required solution on each time round.
12
CASE Tools
CASE stands for “Computer Aided Software
Engineering”.
A CASE TOOL KIT is a set tools that have
been designed to automate the entire
software life cycle, including analysis, design,
coding and testing.
13
Fact Finding
Analysis is a fact-finding process, and there
are five key questions that need to be asked,
often repeatedly.
These key questions are:





WHO?
WHAT?
WHERE?
WHEN?
WHY?
14
Designing the Solution
Once the needs of the user are clearly
understood and documented
Design of the User Interface
Design of the structure of the software
►Design of the detailed logic of the software
15
Implementation
The next stage involves
turning the carefully
structured design into a
working solution.
16
Choosing an Environment
Before we can implement a solution we must
decide on the programming environment
which is most suitable.
Languages are generally designed for a
specific purpose.
17
Programming Languages
Language
Algol
Cobol
Comal
BASIC
Fortran
Java
Pascal
Prolog
Purpose
Science
Business
Education
Education
Science and Maths
multimedia
Education
Artificial Intelligence
18
Things to Remember...



The code should be modular,
Meaningful variable names should be used.
There should be internal commentary,
explaining what each section of the code
does.
19
Debugging the Solution
A common technique in trying
to debug a piece of software is
to conduct a structured
walkthrough (step through
each line of logic in the code)
using a structured listing,
which is simply a formatted display or printout of
the code. It is important that the code is written
in such a way that helps the above activities.
20
Dry Runs
To complete a dry run the programmer
works through a section of program
code by hand. This is very useful for
locating errors in both syntax and
semantics.
A trace table will normally be used in
this activity.
21
Trace Tables
A trace table is
constructed with a
column to identify the
instruction executed and
a column for each
variable.
Line no
1
2
3
4
Length
5
Breadth
Area
4
20
20
The programmer works through each line of the
listing changing the appropriate variables.
22
Test Data
1. Normal operation of the software, to make sure that
there are no unexpected results in ordinary work.
2. Boundary - the operational limits of the software
3. Exceptions - This set will show whether or not the
software can react to unexpected inputs in an
effective way, without crashing.
23
Documentation The User Guide
► This
document should describe how to use
the software.
► There should be a tutorial which allows the
user to become familiar with the
commands, and the various sections of the
software.
24
Documentation The Technical Guide
This document should provide information on
► how to install the software
► hardware requirements (memory, processor
speed)
► software requirements (Operating system
version)
25
Evaluation
► Does
the solution meet the user
requirements?
 Judge this against a set of criteria
►fitness
for purpose
►maintainability
►robustness
►reliability
►portability
26
Some Definitions
► Correctness
 A program is correct if it matches the users
requirements
► Maintainability
 This will include
►internal
commentary
►meaningful variable and procedure names
►parameter passing
27
Some Definitions (2)
 Reliability - A program is reliable if it is free
from bugs,
 Readability - A program is readable if it is easily
understandable by people other than the
original programmer, ie good internal
documentation, use of white space, etc.
28
Some Definitions (3)
► Portability
 A program is said to be portable if it can be
transferred from one system to another with
minimal adaptation
► Efficiency
 It should not use up more system resources
(memory & processor time) than are necessary.
29
Some Definitions (4)
► Robustness
 A program is said to be robust if it does not
crash when invalid data is input or unexpected
results are generated.
► Fitness
for Purpose
 Does the program meet the requirements?
30
Maintenance
► Activities
identified as part of
maintenance:
 corrective (17%)
 adaptive (18%)
 Perfective (65%)
70
65
60
50
40
30
20
17
18
10
0
%
31