Transcript Document
The Software Development Cycle
Bill Biddle 2002
Introduction
The the traditional approach used by software
developers to create new applications follows the
“Software Development Cycle”
It consists of 5 end-on stages including;
Defining and Understanding the problem
Planning and Designing of software solutions
Implementation of software solutions
Testing and Evaluation of software solutions
Maintenance of software solutions
The Cycle is used as part of the “Structured
Approach” to software development
It can be represented using the “Waterfall Model”
Bill Biddle 2002
Waterfall Model
The Software Development Cycle
“Waterfall Model”
Defining and
Understanding the
Problem
Planning and
Designing Software
Solutions
Implementation
of Software
Solutions
Testing and
Evaluation of
Software Solutions
Time
Maintenance of
Software
Solutions
Bill Biddle 2002
Stage 1
Defining and Understanding the problem
At the end of this stage the developer should have a
document that spells out the requirements of the
piece of software in terms of the data inputs and
outputs required and the processes required
To achieve this the developer needs to;
collect information from the client (ie the user’s needs)
and validate these needs
determine the scope of the problems to be solved and
define its boundaries clearly
examine feasibility issues
consider Social and Ethical requirements
Systems analysts typically carry out the tasks involved
with this stage
Bill Biddle 2002
Steps Involved in Defining and Understanding
The Software developer will carry out the following steps
in order to complete this stage
1.
2.
3.
4.
5.
6.
7.
8.
Collect information from the users to determine the needs of
the users/client
Determine the objectives
Identify the scope, boundaries and constraints
Determine the feasibility of different approaches
Develop a design specification, documenting data elements
and data types
Represent the system using appropriate system diagrams or
build a throwaway prototype to model the system to the client
and validate the requirements
Generate a requirements report
Provide feedback to the client
Bill Biddle 2002
Determining the Needs
Clients/users need to be surveyed to collect information
for the requirements report. The developer will need
to know;
The hardware specifications, on which the software is to run
The data inputs and outputs
data types and structures needed
the volume of data which needs to be processed and stored
sources of data
data security requirements
sequence of data on screen designs
Processing needs
Ergonomic and Social & Ethical needs
Testing needs
Training needs
User Documentation needs
Maintenance needs
Bill Biddle 2002
Objectives and Scope
The developer must set clear objectives which
clarify what is trying to be achieved
The objectives are usually expressed in terms of what
the user will be able to do eg
1.
2.
“users will be provided with an easy to use interface”
“context sensitive help will be available to users at all
times”
The Scope of the project has to do with identifying
and defining its limits or boundaries. These limits or
boundaries may be;
functional or technical
based around time and cost
based around the level of support given through
documentation and training
Bill Biddle 2002
Feasibility
Before commencing any project it is essential that a
feasibility study is carried out to answer the
questions;
“Is the problem worth solving?” and
“Which approach provides the optimal way of solving
the problem?”
This study should look at all constraints placed on the
system including;
Time Constraints (Scheduling)
Budgetary Constraints (Cost)
Operational Constraints (Functionality / Usability)
Technical Constraints (Hardware limits)
Organizational Constraints (Administrative limits)
Social and Ethical Considerations
Bill Biddle 2002
Design Specifications
During this task the Developer (analyst) should detail the
design requirements for;
The Data including;
The User Interface identifying;
names for data elements (identifiers)
data types for different data elements
data structures for storing data elements
the screen elements required
the screen principles to be applied
The System identifying;
minimum hardware specifications
operating system requirements
Bill Biddle 2002
System Modelling
Software developers use system modelling to try
display their understand of the problem and to
communicate this understanding to their clients
System Modelling is achieved through the use of;
IPO diagrams
Storyboards
Dataflow diagrams
System Flowcharts
Screen designs, and
Limited prototypes
These models may be used and further developed in
Stage 2 as part of the planning
Bill Biddle 2002
IPO Diagrams
Input Process Output diagrams help developers
identify all the Inputs,Processes and Outputs required
by a system.
The simplest to represent these is with an IPO Chart
(Table) eg
Problem: An application is required that will display a
persons age given their name, birth date and current date
Input
Name
Current_Date
Birth_Date
Process
CalculateAge
Output
Age
Bill Biddle 2002
Storyboards
A storyboard is a visual representation of the material to be
delivered in the solution in a narrative format, including
screen designs, audio script, data elements, user
interactions and navigation.
A storyboard sets out the contents of the materials to be
developed and describes the format in which it will appear in
the finished product.
A storyboard should contain:
the name of each screen
the names of data elements that are manipulated on the
screen
a description of the interaction which will take place on each
screen
a description of the graphics specified for each screen
Storyboards allow the developer test their ideas with
potential users, to help them test assumptions and clarify
requirements.
Bill Biddle 2002
Dataflow Diagrams (DFD)
Dataflow diagrams are used to represent the flow of
data through a system
They are mainly used to represent transaction
processing system
Dataflow diagrams allow developers to identify;
External Entities (Sources of Data)
Data Names
Processes
File Stores
DFDs can represent systems at a number of different
levels
Level “0” diagrams are called context diagrams
Bill Biddle 2002
Dataflow Diagrams (diagram)
Representing “the Registration of a New Borrower”
Borrower_Name
Borrower
Reject_Message
Full_Details
Borrower_ID
Check if
Borrower_Details
exist
Valid_Flag
+
Borrower_Name
Generate
Borrower_ID
Borrower_Details
Next_Record_ID
Borrower File
New_Borrower_Details
Bill Biddle 2002
System Flowcharts
System Flowcharts are a valuable tool because they
represent;
Processes and Process sequences
Hardware Tasks
– Screen Display – Keyboard Entry
- Storage Details - etc
User procedures
Documents
Decisions
System Flowcharts are probably easier for clients to
understand than DFDs and are a useful tool used to
help verify the systems requirements
Bill Biddle 2002
System Flowcharts
(diagram)
Begin
Licence Applicant
Form
Primary Proof of Identity
(licence, passport, Identity
Card)
OR
Seconday Proof
Has applicant
completed form
Correctly?
YES
Group 1 Document
Process
Group 2 Document
NO
RTA
Licencing
System.
System
Flowchart.
Verif y Identity of
Applicant and
complete "Proof of
Identity f orm"
Licence Applicant
Form
(Office Use Section)
Reference Section
Licence Applicant
Form
OR
Witness Section of
Applicant Form
Completed
Verif y Address
or ensure that
Witness section
of the f orm is
complete
OR
Proof of Address
Document
Licence Applicant
Form
(Office Use Section)
Bill Biddle 2002
Screen Designs
Screen Designs are probably the most valuable tool
used to verify the requirements of the application with
the users/ clients
Screen designs should;
contain Headings and Labels
contain Prompts, Messages and Help to the user
contain Navigation elements including menus
contain Data Input/Output elements
follow good design principles
not contain unnecessary elements
Elements included on screen designs should be
labelled clearly
Bill Biddle 2002
Limited Prototype
A limited (or throwaway) prototype may be little more
than a model which allows users to do a live walk
through of the solution.
Characteristically these prototype will have
well developed screen designs for the whole system
limited real functionality
limited error checking
These prototypes are used essentially to validate the
requirements with the clients/users.
Several prototypes may be developed before the full
scope and nature of the problem is understood
Bill Biddle 2002
Social and Ethical Considerations
Social and Ethical requirements of an application
should be considered early to minimise problems later
The sort of questions the developer should ask
include things like;
How do I make the application user friendly?
What steps need to be taken to ensure private data is
kept private?
How is a user’s access to data to be controlled?
How is the integrity of data in the system to be
maintained?
How is the application going to be maintained to ensure
its usefulness in the future?
How is the software going to be licensed and protected
from unauthorised use?
Bill Biddle 2002
Documentation
At the end of this stage a variety of documents are
produced for different individuals and groups including;
1.
2.
3.
The Client
Feasibility Report
Questionnaires and Survey Reports
Refined requirements used to form the basis of a contract
Administrators
Risk Analysis Report
Feasibility Reports with costings
Project Details
Project Development Team
Project Schedule detailing the timeframe and approach
Requirements definition report including feedback from
client
System Documentation
Software Requirements Report
Bill Biddle 2002
Stage 2
Planning and designing Software Solutions
Developers take the information presented in Stage 1
of the Software Development Cycle and use it to
design a solution.
Designing a Solution involves;
Documenting the names and data types of all the data
elements used in the form of a Data Dictionary
Using Abstraction and Refinement techniques to
develop Modularised Solutions
Developing Algorithm Solutions using either Flowcharts
or Pseudocode
Using Structure Charts, Data Flow Diagrams, or
System Flowcharts to show the relationship between
Modules or processes
Designing Test Data to Test the Solution
Bill Biddle 2002
Steps involved in designing
Typically the Design process follows the following
steps
1.
2.
3.
4.
5.
6.
A mainline solution is developed
Data structures are developed and a Data Dictionary is
produced
The mainline solution is refined and represented as a
hierarchy of modules in a structure chart.
Solutions for each module are represented as
Algorithms using either Standard Algorithms or Custom
Algorithms
Test Data is developed.
Algorithms are desk checked using test data and
refined if necessary
Bill Biddle 2002
Data Typing
A Name (or Identifier) must be given to each data
element
The data type for each element must be decided.
These data types may be simple data types or
structures data types defined by the user. eg
Simple Data Types
Structured Data Types
- Boolean
- Character
- Integer and Long Integer
- Floating Point (Real Numbers)
- Arrays
Single
Precision &
Double Precision
- Bytes
- Strings
Single
Dimensional
Multi Dimensional
- Records
- Files
Sequential
Random
Access
Bill Biddle 2002
Data Dictionaries
Data Dictionaries are used to keep track of Data
Identifiers and their types.
They are also used to show the data length and range
of acceptable values eg
Identifier
Data Type
Size
Description
SalePrice
CharPosition
CharCode
Name
ProductDetails
ProductCode
Products
String
Real (Single)
Integer
Byte
String
Record
String
Array
256
Range Example
Incomplete
1
25
13
4000
products
Bill Biddle 2002
Global Variables, Local Variable & Parameters
As well a deciding what data types are needed, you need
to decide how they are going to be used.
Global Variable are available across all modules in a
program
Local Variables are defined an used within a specific
module
Parameters allow values to be passed from one module
to another even though the variable may be named
differently.
Modules become reusable if they make use of local
variables and parameters instead of global variables
Bill Biddle 2002
Abstraction and Refinement
Abstraction is the process of starting out with a simple
idea and elaborating on it so you provide more detail
Abstraction is used in designing solutions
Mainline solutions can be refined so that they
gradually display more detail. This process is called
“Top Down Design”
HIPO charts and Structure Charts may help show the
relationship between modules
Bill Biddle 2002
Structure Charts
Structure Charts show;
The hierarchical relationship between modules
The parameters that are passes between modules
Conditional branching and looping between modules
eg.
Repetition
Parameter
passing
Random Numbers
1
2
Input 6, 1 digit v alues
Conditional
branching
3
Generate 100 random
6 digit Numbers containing
only the 1 digit v alues
Output Random Numbers
4
Format 2 columns
Format 4 columns
Bill Biddle 2002
Algorithms
An algorithm consists of a set of explicit and
unambiguous finite steps which, when carried out for
a given set of initial conditions, produce the
corresponding output and terminate in finite time.
How to Solve it by Computer, RG Dromey, Prentice Hall UK, 1982
Algorithms can be represented using;
Pseudocode
Flowcharts
Standard Algorithms are used to describe common
routine involved with
Finding max & min values
String processing
File processing
Linear Searches
Binary Searches
Bubble Sorts
Inserting Sorts
Selection Sorts
Bill Biddle 2002
Pseudocode
Pseudocode means “like code”
Pseudocode uses pairs of “Reserved Words” to
establish control structures
User-defined Identifiers and Processes define the
tasks to be performed
Several techniques can be used to make pseudocode
more readable
Capitalise reserved words
Underline procedure identifiers
Indent the processes between corresponding pairs of
reserved words
Bill Biddle 2002
Pseudocode Sample
BEGIN MAINPROGRAM
StudentRooming = Array[1..4,0..2,1..25]
FOR BlockIndex = 1 to 4
FOR FloorIndex = 0 to 2
FOR RoomIndex = 1 to 25
Output StudentRooming[BlockIndex, FloorIndex, RoomIndex]
CASEWHERE BlockIndex =
1: Output "A"
2: Output "B"
3: Output "C"
4: Output "D"
END CASE
CASEWHERE FloorIndex =
0: Output ""
1: Output "1"
2: Output "2"
ENDCASE
IF RoomIndex <10 and FloorIndex >0 THEN
Output "0",RoomIndex
ELSE
Output RoomIndex
ENDIF
NEXT RoomIndex
NEXT FloorIndex
NEXT BlockIndex
END MAINPROGRAM
Bill Biddle 2002
Flowcharts
Flowcharts use a series of shapes to represent
processes.
Arrows are used to show the sequence
Flowcharts are good a representing small solutions.
Once the solution gets bigger than the page, it is hard
to follow.
When developing flowcharts you must be careful to
form the control structures properly. (It is easy to
create solutions that cannot be coded.)
Bill Biddle 2002
Test Data Design
Test data should be designed to adequately test each
module
Test data should be designed for
Good test data will
all values that are input by the user
all values that are passed into a module using
parameters
test all pathways in the module
test the all boundary conditions
test above and below boundary conditions
Sample outputs should be provided for each piece of
test data
Bill Biddle 2002
Documentation
Most of the documentation developed during stage 2
is intended for use by the programming teams in
stage 3 It should include
Refinements of system documentation
Data Dictionaries
Screen designs
Software Specifications
Algorithms
Test data
Bill Biddle 2002
Stage 3
Implementation of Software Solutions
Implementation of Software Solutions involves converting
paper-based solutions into solutions that work on a
computer system. This involves;
implementing screen designs
coding algorithms using an appropriate language
(Sequential or Event driven)
Translation of the code
(Compliers or Translators)
detecting and correcting errors using appropriate
techniques
(breakpoints, traces, stepping, output debugging
statements)
documenting the solution
(user documentation, technical documentation, project
documentation)
Bill Biddle 2002
Steps Involved in Implementation
If a teams approach is used typically different teams
will be allocated different parts of the solution to
implement. Each team will be responsible for
Building the screens
Coding algorithms for their part using standard libraries
where possible
Detecting and correcting errors (Debugging)
Developing the documentation needed for the solution
Bill Biddle 2002
Building Screen Designs
Most modern programming languages allow screen
designs to be developed by dragging screen elements
onto a form eg.
Bill Biddle 2002
Program Development Techniques
Programmers should follow a strategy when entering
code. The best strategy seems to be based on the
idea that the program should always run even if you
haven’t finished coding. This can be achieved by;
Using Stubs – A separate stub is used for each
procedure. Progressively, each procedure is coded and
debugged.
Limiting the size of Procedures or subroutines to 1
logical task to make it easy to debug
Documenting the code as you go. Intrinsic
documentation and internal remarks should be added to
explain what you have done
Isolating problem areas with brackets and using
output debugging statements and flags to try to
figure out what is going on.
Bill Biddle 2002
Types of Errors
No matter how careful programmers are, errors
always creep into the code
Error types include;
Syntax Errors
Logic Errors
Runtime Errors
Calculation Errors
Errors can be detected by
attempting to compile or interpret the source code
carrying out peer checking and desk checking
using debugging tools
using output debugging statements, flags and isolating
segments of code
Bill Biddle 2002
Syntax Errors
Syntax Errors are errors that are reported during
translation of the code.
Syntax Errors occur when the source code does not
match the Syntax Rules defined for the language eg
a misspelled reserved word will mean that the translator
will not generate a token for the command and the
syntactical analyser will pick up the error
Most Compilers and Interpreters are clever enough to
issue a error message indicating how to fix the error.
eg
BEGIN expected
Type Mismatch Error
‘:=‘ expected
Error in statement
Bill Biddle 2002
Logic Errors
Logic Errors are usually detected during Design Stage
but some might creep through to the Implementation
Stage.
A Logic Error is an error that results from an mistake
made in defining a condition that is used to determine
the path taken in a solution
Logic Errors may occur at
IF conditions
WHILE conditions
UNTIL conditions
CASEWHERE conditions
FOR conditions
Logic errors may also result from performing
processes in the wrong order or leaving out processes
Bill Biddle 2002
Desk Checking
Desk Checking is a manual process which is mainly
used to pick up logic errors and calculation errors
In a desk check every step in the solution is recorded
along with the value of variable input, processed and
output, and the results of conditions tested
Desk checking should be used to check programming
code when you detect a logic error
Bill Biddle 2002
Sample code for Desk check
Desk check the following segment using the following
values for the Array called Marks [15, 15, 12, 18, 8, 9]
Index = 1
WHILE Index < 6
Index = Index+1
Value = Marks[Index]
Pointer = Index
WHILE ( Marks[Pointer-1] > Value )
Marks[Pointer] = Marks[Pointer-1]
Pointer = Pointer-1
Marks[Pointer] = Value
ENDWHILE
ENDWHILE
Bill Biddle 2002
Desk check Solution
Step
Index
Value Pointer Test
Cond1
Test
Cond2
Marks in array
set Index
M
[3]
M
[4]
M M
[5] [6]
15
15
12
18
8
9
Yes
2
Value = Marks[2]
15
Pointer = Index
2
Is Marks [2-1] >
Value
No
Is Index < 6
Index = Index + 1
M
[2]
1
Is Index < 6
Index = Index + 1
M
[1]
Yes
3
Bill Biddle 2002
Runtime Errors
Runtime errors are errors that are reported to the user
once the program has been translated successfully
and is up and running
Runtime errors are usually fairly difficult to locate
Runtime errors may result from events like
recursive calls producing a “Stack Overflow” error
calls to invalid filenames or hardware resources
poor error trapping of user input resulting in errors like
“Divide by Zero” error
calculations that produce values that can’t be stored
such as “Floating Point Overflow” error.
Although runtime errors may show up during this
stage, it is more usual that they will be picked up
during thorough testing in Stage 4
Bill Biddle 2002
Expected Outputs
The programmer using sample test data should
compare the actual outputs against sample outputs
If an application delivers the Expected outputs then
it is ready for Stage 4 (Testing and Evaluation)
If Unexpected outputs occur they are usually a result
of Logic Errors or Calculation Errors and need to
be fixed
These errors are usually picked up once the
application is running
Desk checking and Debugging tools should be used
to fix the problem
Bill Biddle 2002
Debugging Tools and Techniques
Most modern language have inbuilt debugging tools
The contain features such as
Setting breakpoints and stops
resetting variable contents
program traces
step-throughs (similar to an online desk check)
The programmer may also use his/her own
techniques such as
output debugging statements
isolating code segments
flags
Bill Biddle 2002
Forms of Documentation Used
There are 3 main areas in which documentation
needs to be developed
1.
Project documentation involving
2.
User documentation including
3.
the use of process diaries, log books, Gantt Charts and
CASE Tools
user manuals
online help system
installation guides
tutorials
Technical Documentation including
Internal documentation of the Code
Self documentation (Intrinsic Documentation)
Remarks and Comments
Systems Documentation
Documentation for subsequent Maintenance
Bill Biddle 2002
User Documentation
Once a solution has been built the User Documentation can
be produced
User documentation is needed in 2 areas
Online documentation includes
Online Documentation
External Documentation
Help systems accesses via a menu in the application
Context sensitive help such as “Balloon text”
Links to tutorials or multimedia presentations
External documentation includes paper-based
user manuals
installation guides
tutorials
system’s administrator guides
license agreements
Bill Biddle 2002
Technical Documentation
Technical documentation is designed for use by the
developers and maintenance programmers
This documentation includes;
System documentation
Structures Charts
Data Flow diagrams
System Flowcharts
Data Dictionaries
IPO Charts
Story Boards
Screen Designs
Algorithms
Source Code (with appropriate internal documentation)
Bill Biddle 2002
Stage 4
Testing and Evaluation of Software Solutions
Testing is the process of making sure that the
software solution meets all the defined requirements
Evaluation has more to do with Quality Assurance and
examining what people think of the solution measuring its functionality, user-friendliness,
versatility, portability, etc
Testing can take place on a number of different levels
the module level
the program level
the system level
the street level (user level)
Testing techniques may include
Black box testing
White box testing
Bill Biddle 2002
Steps Involved in Testing
Module
Testing
There is a hierarchy in testing.
It is probably best represented
by a typical Waterfall Model
Program
Testing
System
Testing
Live
Acceptance
Testing
Bill Biddle 2002
Module Testing
At the Module level testing 2 types of testing are used
1.
White box testing.
This form of testing may use a minimal data set to
test each pathway through the module
OR
2.
Use test data which tests the boundary value, a value
above the boundary, and a value below the boundary
for each condition in the program
Black box testing
With black box testing only the inputs and checked
against the expected outputs
Black box testing does not check the processes
behind the outputs. If the output is correct, then the
process is assumed to be correct.
Bill Biddle 2002
Program Testing
Many programs are so large that it is impossible to
test every pathway or every possible combination of
user inputs
Program testing instead focuses on testing whether or
not data passes between modules properly and
whether modules are called when they should be.
One approach is called Integration Testing. With
Integration testing modules are progressively added
to the main program and black box testing is
employed
Interface testing is also carried out to examine
whether all the navigation elements work properly
Bill Biddle 2002
System Testing
Programs are usually developed under highly
controlled environments. During System testing the
application is exposed to a variety of different
operating environments including;
different operating systems and
different hardware
System testing is carried out to detect errors involved
with the software / hardware interface
Black box testing is usually used for system testing
Bill Biddle 2002
Live Testing
Live testing involves the use of real data in real
environments
Live testing is used to test
the applications ability to handle real data including
unexpected values
response times
the ability of the application to handle the required
volume of data (Stress testing)
a users interaction with the user interface
Live testing includes
Alpha testing (where the application is released to a
small number of interested clients) and
Beta testing (where the application is release to a
larger cross section of the market place) Errors that are
reported are corrected before the final release.
Bill Biddle 2002
Evaluation
Evaluation has to do with how well a new application
meets the needs and expectations of users / clients
The process of ensuring that the end product meets
user expectation is called “Quality Assurance”
During Quality Assurance the application is evaluated
against a set of criteria including;
usability
flexibility
integrity
accuracy
clarity
maintainability
portability
reliability
reusability
inclusively
scalability
efficiency
economy
quality of documentation
Bill Biddle 2002
Documentation Needed
Reports need to be generated to validate the reliability
of the testing process. The document is called a
“Software Test Report”
CASE Tools are often used to assist with the testing
process. They;
manage the testing process
generating tests automatically and
generating reports automatically
Bill Biddle 2002
Stage 5
Maintenance of Software Solutions
Maintenance is the process of modifying a solution for
an important reason.
Modifications may be undertaken to
remove a bug from the program
improve the efficiency of the code
cater for new user requirements – add new function
improve the user interface
cater for new hardware
Modifications may be achieved through
the use of patches
the addition macros and script files
version updates requiring rewrites
Bill Biddle 2002
Steps involved in Maintenance
Maintenance is usually undertaken by the developer
but in some instances businesses employ their own
maintenance programmers to handle changes
The steps involved with maintenance depend upon
the type of application.
Some applications can be modified through the use of
Macros and Script files. This applies mainly to those
applications developed with RAD Tools.
Other applications can only be maintained by making
changes to the original source code. For these
applications it is necessary to revisit ALL the stages in
the Software Development Cycle, again
CASE Tools can be used to help monitor and
document changes
Bill Biddle 2002
Documentation Required
Ongoing maintenance of a solution means that there
needs to be ongoing changes to the documentation
User manuals need to be updated to describe new
features
Changes to source code, macros and script files need to
be well documented
File version numbers need to be maintained to ensure
the correct files work together
Bill Biddle 2002
The End
Bill Biddle 2002