Intermediate 2 Computing – Software Development Process – Key by byt34827


									Intermediate 2 Computing – Software Development Process – Key Facts Sheet

Software Development Process –

Stages and iterative nature of programming – Iteration means to repeat certain
steps. The steps are followed in order and then repeated. (Repeat Until)

Stages in the SDP – analysis – design – implementation – testing – documentation –
evaluation – maintenance. Stages in the SDP are repeated when we debug a program
or adapt it to suit a new situation. An example of this is with new software eg
Version 1.00 and other titles may say Version 3.12 – the ‘3’ indicates the second
major revision of the software – the ‘1’ is a smaller alteration and the ‘2’ smaller still.
A wide range of skills are needed to write a program to solve a problem.

Analysis – Writing out clearly what the solution to a problem must do eg type of
computer and software needed, specialist input, output devices & backing storage.

Problem specification – programmer may only have a rough outline of the problem –
a clear and precise description is required – this is the problem specification. What is
involved must be agreed between programmer and client before design begins.
Software needs to be right first time be robust and easy to use.

Implications of errors in the problem specification – these should be detected early in
the development cycle as they are costly to correct a later stage. If it is not done poor
testing and incorrect documentation will follow.

Algorithm – a set of instructions that describes how a particular type of problem may
be solved. If correctly implemented it will always produce the correct result. The
problem is only fully specified when it is stated clearly, & we define inputs & outputs
& any assumptions we are making eg an algorithm for the counter & validation.

Design – when the problem is clearly specified there are techniques the programmer
can use to produce the program. Once the algorithm is decided, a method of
representing the design is selected. A number of methods are available – but they all
express a large problem as a set of smaller problems. This method is known as Top
Down Design, and the process of breaking the problem down into smaller problems is
stepwise refinement, which continues until the subproblems are manageable enough to
be coded.

Graphical representation of the program design – structured diagrams – these
represent top down design by ‘layering’. Top layer is the initial problem, second top
layer shows it broken down into smaller problems and so on. Some structures are –
loop – WHILE loop – FOR counter 1 TO 10 etc.

Graphical representation of the program design – flowcharts - program design can
also be shown in flowcharts, which you may have seen before in maths, chemistry,
physics biology etc.
Graphical representation of the program design – pseudocode – is writing the
program design in English statements using key words. Stepwise refinement can be
shown by the numbering of the statements, and indentation helps to represent the
design structure, and make the program more readable.

Choice of design technique – programmers generally use only one or possibly two

Implementation – selecting a programming language eg COMAL, VISUAL BASIC,
C++, PASCAL, FORTRAN etc. When the design of the program is complete and
thoroughly tested we need a High Level Language to code it.

How to choose a programming language – consider how complex the problem is –
can it be solved using a software application – which language is most effective –
hardware needed – what language do you know – can all characters, video, sound &
graphics be included – can procedures (modules) be used – are there a library file of
procedures – can structured programming (eg repetition & selection) be supported –
can data be entered and results given out.

High Level Language means the instructions written in the source code are all English
like words which are more meaningful. Once you have coded the design of your
program in a HLL you run the program on a computer which has a translator program
for the code. All programs developed in HLLs have to be translated into machine
code – the only language a computer ‘understands’ – interpreters or compilers.

Pascal coding – text editing package – file is the source code – processed by the
compiler – checked for syntax errors (have you broken any language rules). Program
construction is checked. Good programming style is – user friendly – short at the top
level – clear internal documentation – meaningful variable names – routines to check
all inputs are acceptable – clear structured layout. If the source code is free from
errors then the compiler will translate it into machine code. This Low Level language
file of code is called the object file. When you want to run your program this object
file is loaded into the computer’s memory and executed. Variables need to be
identified as integer, character, real, string etc.

High Level Language features – Reserved words – these have a special meaning in
HLL programming and can’t be used as names for variables – eg COMAL – CLS –

Assignment statements – we use these to give a name to a variable eg counter:=10

Operations – we want to perform operations on numbers like we do in arithmetic. We
represent these with the use of symbols eg + - * / to carry out arithmetic operations.

Structured Programming – high level languages help you to develop your program by
offering this. The three main techniques are – sequence, repetition and selection.

Sequence – the program does one thing after another
Repetition – an action is repeated until a condition is met
Selection – allows a program to choose a course of action
Most structured programming languages allow you to develop the solution to a
problem in a modular way – ie they will let you use procedures. A module is the
same as a procedure. Module designs can be saved in a library file.

Structured programming languages allow you to use control structures for selection,
unconditional, simple conditional and sequence statements. Different types of data
objects can be represented. They allow for arithmetic operations and provide
structured listings. Indentations in the lines of programs make the program easier to
read, and help you see where the beginning and end words in structures match up.

Testing – any software solution developed for a program should produce correct
results. This can only be checked if we run a program and test it with a variety of
inputs and see if the results produced are what you would expect. A program cannot
usually be tested for every possible input – careful selection of test data as well as
structured listings will help you develop correct, reliable and robust software. It is
important to choose test data which will be valid, and to test it at extremes and also to
test for unacceptable inputs.

Error reporting – help to increase the rate of production of reliable and robust code
because the programmer is alerted to any errors immediately. Thorough testing and
debugging are essential, and the process of debugging a program involves looking for
syntax errors. These arise when rules of the language are broken. Run-time errors
arise during execution when the program attempts for example to divide by zero.
Logical errors are found when the syntax is correct and the code runs without error.
However the program does not give the correct result eg square root of 81 is –9!

Once a module is tested and any bugs removed it may be entered into a module
library, and could be used in other programs – it is portable and always available.

Documentation – is needed so as users of a program know how to use it. The user-
guide should make clear to the user all they need to know eg start-up & facilities. The
technical guide should be provided and give instructions on how to install the
software and detail hardware and memory requirements. It is essential for other users
of the program and is necessary at the following stages –

Analysis – problem specification & program description – IPO, Assumptions.
Design - flowcharts/structured diagrams/pseudocode. Implementation – internal
commentary – program and output listings – test history and sample outputs.

Evaluation – to do this we need to go back through each stage of the development of
the software and check whether the solution meets the requirements. Have we
correctly interpreted it have we considered user interaction – helpful screens –
internal documentation – modularity. Is the program reliable, robust, can it be easily
maintained, does it give correct results, is it the best solution, has the user guide been
included, is there a technical guide and have potential changes been suggested.

Maintenance – programs may have to be altered for a variety of reasons. Working
practices of the customer may change, more files may need to be handled due to
business expansion, rivals may have produced a better version, errors may show up.
Developments in operating systems and processors mean that the way the program
interacts with the computer will have to be changed. How quickly the changes can be
made depends on whether meaningful names for variables have been used, is there
helpful internal documentation, is there a user-guide, is there a technical guide. Good
programming style will be user friendly, as short as possible at the top level, have
validation testing routines and show a clear structured layout.

Characteristics of software – Fitness for purpose – a program should produce the
correct output for all valid inputs and should be reliable – test data should include
acceptable, unacceptable and extreme data, and a dry run may be carried out. It also
needs to be efficient, and run at a speed that is appropriate to the task it has to perform
eg a bank auto-teller should not take 4 hours to perform a transaction!

Design of the user interface – the screen presentation should be clear and the user
should receive consistent instructions on how to proceed through a program. Inputs
should be validated and helpful messages given to the user. Ability to amend entries
is vital, and prompts and menus should be easy to follow. Meaningful variable,
procedure and function names and internal commentary will help to make the
program easier to read and debug.

Documentation – the program should include comment lines that describe what
different parts of the program do. The user guide describes how to use the program,
nowadays an electronic tutorial is usually present. The technical guide gives
instructions on how to install the software eg memory, processor needed and the
version number of the software.

Maintainability – modular design makes a program more maintainable – any
segment which needs corrected, updated or changed can be quickly identified and
altered. Programs are more readable if internal documentation has been included, and
meaningful variable names help too. The programming language used determines the
portability, and a suitable translator has to be available for the platform on which it
will run eg Windows XP. Can the program be adapted to run on other computers?

Additional notes –

Modularity – large problems are broken down into smaller problems which are called
modules or procedures. This is the Top Down Design method, and ideally is short.

Control –

Selection – a computer will run through a program from beginning to end following
one instruction after another. Computers choose by using a control structure eg if-
then-else – an example could be password identification for autoteller machines.

Repetition – a for next loop where an assigned variable stores the number of the count.

Data storage – for example how we represent numbers in the computers memory, and
other data objects such as alphanumeric or string, eg name$:=large bear

To top