Transcript The Software Development Process

Shawlands Academy
Higher Computing
Software Development Unit
1
Explain Aspects of the
Software Development Process
2
The Software Development
Process
•
•
•
•
•
•
•
Analysis
Design
Implementation
Testing
Documentation
Evaluation
Maintenance
3
Remember
A Dance In The Dark Every Monday
•Analysis
•Design
•Implementation
•Testing
Monday
•Documentation
•Evaluation
•Maintainance
4
Systems Analysis
What is a systems analyst?
– A systems analyst observes, clarifies
and models an existing system to assess
its suitability for computerisation. In
the process, the analyst could also find
ways of improving the system.
– The systems analyst must have a sound
technical background. They may once
have been programmers.
5
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
6
Extracting the Clients
Needs
Extracting the clients needs is known as
requirements elicitation.
This is done by:
– interviewing the client’s management personnel
– making observation notes of the client’s
business
– The analyst will also inspect information
sources used by the client to keep track of
their business.
7
The Software Specification
• is the end result of the requirements
elicitation
• is a written statement of what the design
team must go on to make
• It forms part of a legally binding contract
between the client and the development
team
It is extremely important to get this
document right. Mistakes made later
can be very costly.
8
Analyst’s Reports
The systems analyst must document
the clients needs by drafting formal
reports:
– requirements specification
– software specification
9
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?
Not HOW?
10
Designing the Solution
Once the needs of the user are clearly
understood and documented, software
development can move onto the next stage,
involving the DESIGN of the system.
Design of the User Interface
Design of the structure of the software
•Design of the detailed logic of the software
11
Design Representations
There are a number of commonly used
forms of design representation in
common use.
Examples include:
– structure diagrams
– pseudocode
12
Structure Diagram
A commonly used syntax for structure
diagrams is as follows:
A procedure
A decision
A loop
A single
task
13
An example:
A structure diagram allows the design of a
program to be drawn out in diagrammatic
form. Here is an example:
Tax payment
IF earns >
30000
Get details
NO
Low rate
payable
Display amount
to be paid
YES
High rate
payable
14
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.
15
Pseudocode - Example
1.
2.
3.
4.
Notice the
numbering
system
Display information
Get details
Do calculation
Display answer
Refine step 2
2.1 display prompt
2.2get value
2.3while value out of range
2.4
display error message
2.5
get value
2.6loop
Top level
design
Simple English
words in a familiar
program form
16
Hierarchy of Software
• A diagram of the hierarchy of
software will
– show the relationship between all the
modules of the software
– identify modules which contain a call to
other sub modules.
17
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.
18
Implementation
The next stage
involves turning the
carefully structured
design into a working
solution.
19
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.
20
Programming Languages
Language
Algol
Cobol
Comal
BASIC
Fortran
Java
Pascal
Prolog
Purpose
Science
Business
Education
Education
Science and Maths
multimedia
Education
Artificial Intelligence
21
Things to Remember...
 The code should be modular, - procedures and
functions should be used. Library modules should
be ‘closed’ so that the variables used in them
cannot disturb the code of the rest of the
program.
 Meaningful variable names should be used.
 There should be internal commentary, explaining
what each section of the code does. Where a
complex algorithm has been implemented, it is
helpful to comment on several lines of the code, in
addition to a general description of what the
module does.
22
Things to Remember (2)
 Where parameters are being used in a module,
they should be described in the commentary of
the module. This is particularly important in
library modules.
• Parameter lists should be small and manageable.
If a procedure or function requires a set of
parameters which is very big, then it is likely that
it is performing more than one program function.
The original design needs to be revisited, and
functionally decomposed.
23
Debugging the Solution Testing
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.
24
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.
25
Trace Tables
A trace table is
Line no Length Breadth
Area
constructed with a
1
5
column to identify
2
4
3
20
the instruction
4
20
executed and a
column for each
variable.
The programmer works through each line
of the listing changing the appropriate
variables.
26
Test Data
The expected results from a test data set must be
known in advance, so that they can be checked
against the actual results. You should include test
data to demonstrate the following:
1. “normal” operation of the software, to make sure
that there are no unexpected results in ordinary
work.
2. the operation limits of the software, to make sure
that the boundary conditions identified in the
design stage are being handled properly.
3. “exceptions” to the normal operating conditions.
This set will show whether or not the software can
react to unexpected inputs in an effective way,
27
without crashing.
Documentation The User Guide
• This document should describe how
to use the software.
• Ideally there should also be tutorial
files which can take the user through
examples of a piece of work, and
allow them to become familiar with
the commands, and the various
sections of the software.
28
Documentation The Technical Guide
This document should provide
information on
• how to install the software
• hardware requirements
• software requirements
29
Evaluation
• Does the solution meet the user
requirements?
– Judge this against a set of criteria
•
•
•
•
•
•
•
•
screen layout
help required
user prompts
fitness for purpose
maintainability
robustness
reliability
portability
30
Some Definitions
• Correctness
– A program is correct if it matches the
users requirements
• Maintainability
– A program will be easily maintained if it
has been written in a way which will make
it easy to change. This will include
• internal commentary
• meaningful variable and procedure names
• parameter passing
31
Some Definitions (2)
• Reliability
– A program is reliable if it is free from
bugs, ie it must meet the requirements
repeatedly under severe testing
• 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.
32
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
– A program is efficient if it uses the most
appropriate structures for the job. It should
run as fast as possible and not use up more
system resources than are necessary.
33
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?
34
Maintenance
• Activities identified as part of
maintenance:
– corrective (17%)
– adaptive (18%)
– Perfective (65%)
70
65
60
50
40
30
20
17
18
10
0
%
35
Maintenance Costs
• Maintenance is very costly. It is vital
that errors are detected at as early a
stage as possible.
100
90
80
70
60
50
40
30
20
10
0
1970s
1980s
2030 ?
% of total development cost
36
Factors Affecting
Maintainability
•
•
•
•
•
•
The application being supported
staff mobility
too many versions
not enough documentation
dependence on external environment
hardware and software stability
37