Software development
Stages in the program development life cycle:
Analyse problem – Define problem, record program specifications and recognize inputs,
process, output & UI
Design program – Develop logic plan, write algorithm in e.g. pseudocode or flowchart and
test solution
Code program – Translate algorithm into high level language with comments/remarks and
produce user interface with executable processes
Test and debug program – Test program using test data, find and correct any errors and
ensure results are correct
Maintain program – Provide education and support to end-user, correct any bugs and
modify if user requests
The program development life cycle:
Waterfall model – A classical model, used to create a system with a linear approach, from
one stage to another
Iterative model – An initial representation starts with a small subset, which becomes more
complex over time until the system is complete
Rapid Application Development (RAD) model – A prototyping model, with no (or less)
specific planning put into it. More emphasis on development and producing a product-
prototype
Program design using structure charts:
Structure chats – A graphical representation of the modular structure of a solution
Parameter – A value passed between modules
Process – Represents a programming module e.g. a calculation
Data couple – Data being passed from module to module that needs to be processed
Flag – Check data sent to start or stop a process. E.g. check if data sent in the correct format
Selection – Condition will be checked and depending on the result, different modules will be
executed
Iteration – Implies that module is executed multiple times
Example:
Converting Pseudocode to Structure Chart
Break the program into main task and sub tasks
Define main module and submodules
Each module will be represented in boxes
Parameters passed by value will go to the left
Parameters passed by reference and return value goes to right
Program design using state-transition diagrams:
Finite state machine (FSM) – A machine that consists of a fixed set pf possible states with a
set of inputs that change the state and a set of possible outputs
State-transition table – A table that gives information about the states of an FSM
State-transition diagram – A diagram that diagram that describes the behaviour of an FSM
Here is an example:
If the FSM is in state S1, an input of a causes no change of state
If the FSM is in state S1, an input of b transforms S1 to S2
If the FSM is in state S2, an input of b causes no change of state
If the FSM is in state S2, an input of a transforms S2 to S1
This is what it would look like with outputs:
If an input causes an output this is shown by a vertical bar. For example, if the current state
is S1, an input of b produces output c and transforms the FSM to state S2.
Types of errors:
Syntax errors – An error in which a program statement does not follow the rules of the
language
Logic error – An error in the logic of the solution that causes it not to behave as intended
Run-time error – An error that causes program execution to crash or freeze
Testing errors:
Stub testing – When you want to test your program before you have implemented all the
facilities you can write a ‘stub’ for each procedure. The procedure body only contains an
output statement to acknowledge that the call was made.
Black-box testing – Comparing expected results with actual results when a program is run
White-box testing – Testing every path through the program code
Dry-run (walk through) – The process of checking the execution of an algorithm or program
by recording variable values in a trace table
Integration testing – Individually tested modules are joined into one program and tested to
ensure the modules interact correctly
Alpha testing – Testing of software in-house by dedicated testers
Acceptance testing – Testing of software by customers before sign-off
Beta testing – Testing of software by a limited number of chosen users before general
release
Test data:
Normal (valid) – Typical data values that should be accepted
Abnormal (erroneous) – Data values that the system should not accept
Boundary (extreme) – Data values that are at a boundary or an extreme end of range of
normal data; test data should include values just within the boundary (that is, valid data)
and just outside the boundary (that is, invalid data)
Maintenance:
Corrective maintenance – Correcting identified errors
Adaptive maintenance – Amending a program to enhance functionality or in response to
specifications changes
Perfective maintenance – Modifying a program to improve performance or maintainability
