Software Development Process (Higher)

The Software Development Process

Higher Computing - Soft Dev – Software Development Process Infosheet 1

Produced by S Lambert, R Simpson and HSDU for The City of Edinburgh Council, 2004

Most computerised systems that we use in every day life we take for granted, but how did they come into

existence? Where did the "hole in the wall" banking, batch sent bills, store cards, software such as word

processors etc. actually come from? How were they developed? Who was responsible for developing

them? What was their role in the creation of these systems?

First Steps

Most creations start with an idea in someone's head. For example, questions like: "Wouldn't it be great

if...", "Is it possible to improve what we are doing by...?"

Sometimes groups of people are involved in brainstorming these ideas. Ideas, however, are not precise

specifications of what the imagined system should do, nor of how it should be built. They are merely the

first steps in the creation of a system.

Need

Computerised systems are developed, as are most creations and inventions, from

perceived needs and a reckoning that certain advantages will arise. Consider the

banking systems of today. What can we see as the benefits that computers have

brought to these businesses? What advantages were foreseen by the managers

and directors who commissioned the construction of these systems, investing

millions of pounds in the process? Perhaps they were thinking along the lines of:

• improving the efficiency of dispensing and depositing cash

• a more flexible service for customers which provided 24 hour access to their accounts

• giving more accurate and up to the minute reporting of transactions

• expanding their customer base and the management of larger databases of information

• reducing their staffing levels

Solution

Often people who generate such ideas have no expertise in building the final product. We don't really

expect managers and directors of companies to be expert programmers. So how do these ideas become

reality? There has to be a method of transforming these ideas into a form that can map onto a computer

system. There has to be a way of translating a verbal or textual description of an idea into a programming

language and its hardware environment. So what are these steps and who is responsible for taking them?

Management Personnel

The clients are the persons who require the new system. They are the ones who need the new software

developed. The project manager is the leader of the software house. This person is responsible for the

whole project and must supervise all steps and stages required.

Initially the clients would meet with the project manager to ensure that the system that needs to be

developed is economically, technically and feasibly possible. If the system is possible only then will it be

taken on by the software house.

The Software Development Process can be divided into seven stages

Analysis, Design, Implementation, Testing, Documentation, Evaluation and

Maintenance.

Each of these steps must be implemented correctly if the final product is to

meet the needs of the client. The process is carried out in this order but it is

possible to go back and correct any errors that may occur.

Analysis


Produced by S Lambert, R Simpson and HSDU The City of Edinburgh Council, 2004

When a project is given the go ahead, obviously it cannot be programmed straight

away. A number of questions and an exploration of the idea must be carried out first.

Systems Analyst

A systems analyst is the person with whom the company will deal initially. It is this person's job to carry

out an analysis of the situation. In other words the need for exploring the original idea more closely.

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.

Skills and Techniques Of A Systems Analyst

Systems analysts need to have a very sound technical background. It is likely that they were once

themselves programmers, highly skilled in coding, testing and debugging software. They will be

knowledgeable in a variety of hardware platforms and operating systems. As analysts they will also have

to acquire new and quite different skills, the most important of which is the ability to communicate well

with their clients. It is fundamentally important that a system is developed which meets the needs of the

client. Anything less is simply useless. The client will be dissatisfied, with money and time misspent.

If we bear in mind that the clients are not usually technically skilled, then we can see that the analyst must

develop ways of extracting their needs, documenting these needs in some formalised way and finally

communicating then to the team of designers and programmers who will build the system. We can

consider the analyst as a "go between" the client and the development team.

Extracting The Client's Needs

This can be a long task, because, at the start, the client may not be fully aware of the possibilities of a

computerised system, and the systems analyst will probably not be fully familiar with the client's business

operations. The analyst will:

• interview the client's management personnel

• take observation notes of the client's business

• make an inspection of the information sources

When the analyst has completed this task, functional reports will have to be drafted. One of these will be

the software specification. This is the most important report as this document is the basis for everything

the design team uses. It is also a legal binding document that provides a contract between the client and

the software house. It clearly states what the client wants and what the system is supposed to do.

Prepared For Change

Obviously the client may have a change of mind or communication between the client and analyst may

not be clear. Hence an iterative process is carried out where the client and the analyst may meet on

several occasions until both sides are in complete agreement.

There may also be technical and/or financial limitations which will require changes to the original idea.

Sometimes ideas are too costly or there just isn't the technical capability to carry out the idea. Sometimes

the analyst may want to produce a solution more advanced than the client's needs. Therefore it is

necessary to limit the scope and boundaries of the development.

It is very important that changes in the requirements are identified early, so that the changes in the design

can be made without additional work, and the project can be kept within its planned timescale and budget.

Design

Higher Computing - Soft Dev – Software Development Process Infosheet 3.1


Once the needs of the user are clearly understood and documented, software development can move onto

the next stage. This involves designing the system.

So instead of asking what needs to be done it is now necessary to ask how it is going to be done. It is

necessary to use a structured and methodical approach to the planning of the solution.

Design of the User Interface Design of a good user interface is one of the most important indicators of a high quality piece of software,

and should be given much consideration. It is, after all, the link between those intricate sections of code

that have been worked on for months and the end user.

It doesn't matter how clever the programmer and designers have been in optimising the speed of the code,

or minimising the memory overheads of the program, the code is not acceptable if it is too complex, or

unintelligible in its interaction with the final user.

Looking at the design of conventional WIMP operating systems, and their success in the world market, it

is easy to appreciate that the most influential selling point is how the system appears to the user, and how

easily such a wide audience of people are able to interact with it, and get it to do things for them.

There are many different ways of having a dialogue with the user, including:

Command driven interfaces which allow users to type in commands to activate various tasks.

These normally benefit expert or power users as they can achieve tasks faster without

navigating through various menus or windows.

Screen menus, where the user selects from a choice of options. The selection device can be a

mouse, or a light pen, or indeed their finger, if a touch sensitive screen is being used.

A WIMP style interface, where icons are used to symbolise objects, such as the wastebasket,

or the hard drive, or files and folders on backing storage. Pointing devices such as the mouse,

or light pens can be used to select commands from menus and issue commands to the system.

Choosing the Interface

A set of guidelines are used when setting up a dialogue that suits the client’s needs. It

does not matter what form of interface that is selected to be presented to the user, or

the devices that are opted to use for interaction, these guidelines should be met in

order to provide the best solution for the client.

Design Methodologies

Design methodologies include modular design, Jackson Structured Development and object-orientated

design.

Modular Design is a method of constructing a computer program using self-contained parts called

modules. These are constructed to be designed, coded and maintained independently. Top down design

and Bottom-up design are forms of modular design.

Top down design involves looking at the whole problem and breaking it down into smaller sub-problems.

Each sub-problem may then be further sub-divided. This is called stepwise refinement. When stepwise

refinement is complete you have created an algorithmn.

Bottom-up design involves writing modules first and then joining them together. A bit like a jigsaw.

Design



Design Notation There are two methods of representing a design. The first is the representation of the structure of the

software using a graphical design notation. This could either be a structure diagram or a flowchart.

The second is the representation of the logic of the software using pseudocode. Some developers use

only pseudocode, to document the various stages of their refinement and outline the structure of the

software; some use only structure charts; others may use yet another design method or a combination of

methods.

The important point is that there must be some documented evidence of this stage of the design. It is far

easier to correct logical mistakes, or to upgrade a piece of software, by using structure charts or

pseudocode listings, than by referring to the actual program code, because the structure charts or

pseudocode listings make it easier to understand how the software was built in the first place.

Pseudocode

Pseudocode is a cross between a programming

language and English. It is sufficiently like

English to allow concentration initially on

program design without worrying about the

complexities of the programming language.

However it contains enough programming

language features that allow coding of the

finished design quickly in the chosen program

language. Although the description can be

easily converted into high-level language code,

it is NOT simply a set of language statements.

Structure Diagram

A structure diagram shows the different sections

of the program. It is a treelike diagram,

representing component modules and their

interrelationships.

Flowcharts

A flowchart is often used to illustrate an algorithm

(set of instructions) to solve a problem. A

flowchart is a diagram that uses different shapes

and arrows to show the steps in a problem

solution. Particular box shapes are used to

represent different aspects of coding.

1. ask user for number of hours

2. ask user for rate of pay

3. calculate wages

4. display wages

refine step 1

1.1 ask user for number of hours worked

1.2 store response in hours

refine step 2

2.1 ask user for rate of pay

2.2 store response in rate

refine step 3

3.1 if hours greater than 40

3.2 calculate overtime

3.3 calculate wages

3.4 else

3.5 calculate wages using (hours x rate)

3.6 end if

You have Failed

PROBLEM

Grade Tests

Get Test Mark

Is Mark > 49

Is Mark > 59You have an A pass

You have a C pass

You have a B pass

Is Mark > 69

Yes No

NoYes

NoYes

Implementation


Produced by S Lambert, R Simpson and HSDU for Queensferry High School Computing Department 2004

This is the third stage of the software development process and involves the

translation of the design that has been constructed, through screen layouts,

structured charts and pseudocode, into a form that the computer can understand,

i.e. a program code. Programmers are responsible for constructing the code.

The aim of the implementation stage is to create a program that is :

• CORRECT meets the software specification.

• EASILY MAINTAINED subsequent changes can be effected easily and quickly.

• RELIABLE is free of design and coding bugs, correct for all specified

output. It should work correctly every time it is run.

• READABLE has design and code that can be easily understood by

other programmers.

• PORTABLE may be adapted to run on computers other than that on

which it was designed.

• EFFICIENT should not require processor time or storage resources

disproportional to the scale of the program.

ROBUST should not fail no matter what input is entered by the user.

The program code as part of the Documentation

Often this program or source code may need to be tested, updated and maintained by developers who did

not take part in the original programming exercise. A common technique in trying to test 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. The following points are needed in good

code:

1 The code should be modular (split up into manageable parts) - procedures and functions should be

used.

2 Use should be made of library modules. The programmer who needs a particular routine is saved

the trouble of having to design and write one if it is available in the library. The modules should

already be tested and be free from errors.

3 Meaningful variable names and procedure names should be used.

4 There should be internal commentary explaining what each section of the code does.

5 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.

6 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.

Implementation


Produced by S Lambert, R Simpson and HSDU for Queensferry High School Computing Department 2004

User Interface

A correct program is unsatisfactory if the user finds it difficult to understand or confusing to use. Three

important aspects for implementing the user interface are:

1 The suitability of the start up procedures.

These should be clear and simple, e.g. an autoexec batch file or boot file which automatically

loads any requisite files, then displays the program logo and user instructions.

2 The standard of the general presentation. Factors to consider here include:

• consistent operating instructions,

i.e. always using the same “Press <SPACE> to continue” prompt rather than intermingling

other types of proceed prompt.

• clear uncluttered screen layout.

i.e. headings should be centred on screen ; text scrolling should be

avoided ; text should be upper and lower case ; highlights, graphics,

colours or sounds should be used meaningfully.

• menus/help screens.

i.e. the choice, meaning, and consequence of available actions

should be clear.

• clear prompts

i.e. for inputs, indicating type and source of response required.

If alternative output devices are to be used, prompts must be

given to the user before output commences.

3 Software must be robust. Factors to consider here include:

• echo-printing

i.e. input should be „echoed‟ to the screen so that the user can proof read her/his own data

entry, and make amendments if necessary.

• validation

i.e. All input data must be validated. If an illegal entry is attempted,

the user should be informed where and what the error is (error

messages should be helpful rather than cryptic!) The user should be

warned about an invalid entry.

• reliability

i.e. reliable results must be given for ALL valid entries.

• defensive programming

i.e. potential errors should be anticipated and trapped, to prevent run-time errors (such as

„divide by zero‟).

Testing



In software engineering studies, a report suggests that

analysis and design accounts for 40% of development

costs, implementation 20% and testing around 40%.

These proportions are illustrated on the pie-chart

opposite.

It is therefore too late, and too costly, to discover that

errors in the analytical or design phase have been made

when you finally come to test the final code. By this

stage 60% of the total project resources will have been

used!

Although design errors introduced in the analysis phase are more costly than programming errors (usually

developed late in the software development cycle, easier to detect and costing less to remedy), they do

occur. Half of all errors encountered are due to misunderstanding the problem specification, and not in

fact due to programming!

So why do all these problems occur and what can be done once they have happened? Obviously the best

solution is not to allow errors to happen in the first place, but unforeseen circumstances can obviously

cause unforeseen problems.

So what can be done to sort out errors which have been realised after the analysis, design and

implementation stages and what sort of errors can happen?

Common Errors

The following is a brief classification of the most common design errors and the project phase at which

they more readily occur.

Errors during the detailed design stage.

Incomplete logic Neglect of special cases

Poor error handling Neglect of time consideration

Incorrect interpretation of the problem specification

Errors during coding stage.

Syntax errors Initialisation errors

Confusion of parameters Errors in loop counters

Incorrect handling of results of a decision Multiple or non-definition of variables

Errors in writing variable names Incorrect declaration of type and dimensions

Errors during translation

Compiler errors External symbols wrongly resolved

Confusion of names of library procedures

We should therefore build monitoring and review into every stage of the software development process,

and not merely leave it to the end to find out that we have made mistakes.

Sof tware dev elopment Costs

Implementation

Analy sis

Testing

Testing



Test Data

In earlier courses, you should have come across the idea of creating sets of test data to feed to your

software to find out how it behaves under different conditions. The test data need to cover different cases

(conditions) Here are some of the important points about making up such sets:

The expected results from a test data set must be known in advance, so that they can be checked

against the actual results.

Normal - tOne set should test 'normal' operation of the software, to make sure that there are no

unexpected results in ordinary work.

Extreme - One set should test the operation limits of the software, to make sure that the boundary

conditions identified in the design stage are being handled properly.

Exceptional - One set should test 'exceptions' to the normal operating conditions. This set will

show whether or not the software can react to unexpected inputs in an effective way, without

crashing. This set of test data provides useful evidence about the robustness of the software.

Logic Testing

At this stage of the software development process we are concerned with proving that the logic of the

software is correct, and that it meets the requirements of the original specification.

Testing can never prove conclusively that a program is correct. No matter how exhaustive the testing, it

will always be possible for the system to contain errors which have not been detected.

Testing - Who Does It?

Developing a piece of software is a creative task. Being a creative activity, the programmer will naturally

take some pride in his/her creation, and will not necessarily wish to show that it doesn't in actual fact

work properly! The programmer's approach of demonstrating through selective test cases that his/her

software works, is unsatisfactory, and this approach to testing is unhelpful.

Systematically destroying a piece of software using this approach must be handled delicately and tactfully

by the design team. Criticism can be difficult to handle for some people. On the one hand thorough

testing must be carried out, and this must be destructive, aiming to identify faults so that they can be

removed, improving the reliability of the system. On the other hand the programmer must still remain

motivated and continue to work on the development. What is the best way of achieving this?

One approach is to involve outsiders from other areas of the development

team. In some development environments these are known as Independent

Test Groups, (ITGs). These groups work with the programmer to ensure that

thorough testing is carried out. Any errors uncovered are recorded and the

software is returned to the programmer for correction.

Testing - When Should It Be Done?

Software systems can be very complex, consisting of large subsystems which themselves consist of

modules consisting of procedures. Look back at the hierarchical diagram to appreciate this structure. A

system designed by the author of this text to control the distribution of electricity for London Electricity

Board, was implemented in over 250,000 lines of code. This was merely a component of a much larger

system! It would be madness to delay the start of testing for software of this magnitude until the entire

system has been coded.

Documentation



When a new piece of software a is being used for the first time, the first place to look in order to gain an

understanding of how it operates, what commands to use and how to solve any problems encountered,

will be in the documentation which usually accompanies it.

Software companies vary in the nature and quality of documentation that

they provide. However, two essential pieces of documentation which

need to be developed are the User Guide and a Technical Guide.

The quality of this documentation is also normally a good indicator of the

quality of the software. Good documentation should be concise,

comprehensive and above all complete. All of which can only arise from

a well-structured systems analysis and design approach. For instance, any

alterations to the system, through upgrades or corrective maintenance

should also be reflected in the necessary document i.e. documentation

should also be maintained up-to-date.

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. Nowadays it is becoming more common for

developers to provide this documentation in electronic form, as an on-line reference system, with

interactive help and tutorial displays. This saves in the cost of producing paper-based documents, and

also allows upgrades to be reflected in the help system upon subsequent releases of new software

versions.

The Technical Guide

This document should provide information on how to install the software, its memory

and processor requirements, the version number of the software and any associated

help files or systems extensions that may also need to be installed. The guide should

also contain a reference section on troubleshooting, that will help the user to get

around any system problems that they may encounter.

Other Types Of Guides

Although the User and Technical Guides should be given with the software, most companies give out

other guides to aid the user.

Examples

1 Extra features or functions guide - these are normally given with

packages which have been upgraded so that familiar users can see directly

the new aspects of the package.

2 Printing guides - these are normally given with DTP packages to help the

user think about the most appropriate output for their publication.

3 Shortcut guides - these are normally pieces of card with shortcuts for

users to use to enable them to access features quickly.

4 Tutorial guides - these can be given in either manual or video format.

The user can go through step-by-step tuition in order to learn how the package works.

Evaluation



To evaluate a completed application, the developers are mainly concerned with answering the question:

Does this software meet the user requirements?

To answer this, you need to return to the original aims of the software development,

and judge this against a set of criteria.

What are the criteria that you should use?

Robustness - the ability of the software to cope with errors during processing.

Reliability - how well the software operates without stopping due to design faults. It should

give correct and predictable results.

Portability - the software should run on a system other than the one it was designed for.

Efficiency - the amount of processing power and RAM should be within reason as to the task

of the program.

Maintainability - the ease to which a program can be altered. This is helped by the readability of

the code, the modularity of the code and the amount of internal commentary.

The most important aspect of the evaluation is "Fitness for purpose". Does the software solve the original

problem.

If you are at the analysis stage, then you are measuring how well you have

understood the client's problem. Some say that the proof of this lies in the

final development. However, as we have pointed out, this is far too late a

stage at which to judge success. By interacting with the client, taking notes

of all meetings, agreeing on what has been said - in other words, using the

recommended tools and techniques of analysis you will have increased the

likely success of this stage. You will also have generated a list of user

requirements that can be used as a checklist to help you validate your product as you proceed through the

design, implementation and testing stages.

At the design stage, there are criteria that have been introduced in order to

help you to measure the quality of the HCI. This, together with a

structured and methodical approach to developing screen layouts,

structured charts and algorithms, can all be used to measure the success of

your design. They also help to validate that you are building the correct

product. Guidelines given on how to select a programming language, and

the attributes that good source code should contain, can all be used as

criteria in evaluating the modularity and portability of the software. It is

structure, readability, and the test, used to validate it, that will provide a measure of its reliability,

maintainability and finally its robustness.

Maintenance



Maintenance comes into effect as soon as the system is delivered to the client and it enters productive use.

....it is impossible to produce systems of any size which do not need to

be maintained. Over the lifetime of a system, its original requirements

will be modified to reflect changing needs, the system's environment

will change, and obscure errors, undiscovered during system

validation, will emerge.

Sommerville, Systems Analysis and Design, 1985

Maintenance Activities

Research has identified the following three maintenance activities, and the associated percentage of time

spent on each. These figures are typical of a development company's maintenance procedures:

1. Corrective maintenance (17%)

During the use of the system, errors emerge which were undetected during system

testing. These should be reported to the developer and corrective action taken to

remove them from the original code.

2. Adaptive Maintenance (18%)

The software environment of the system, such as the operating

system or the hardware environment of the system, such as

peripheral devices, processor etc., have altered since the code was

originally developed and these have caused the original code either

to fail, or to operate less effectively. The system must be altered

in order to adapt to these new surroundings

3. Perfective Maintenance (65%)

This is a response to a user's request to change the existing system by adding new or

altering existing functions, or catering for general enhancements to the system.

Categories 2 and 3 are also likely to force the developers to revisit the early stages in the design process -

another iteration of the design. This particular iteration is likely to take place after some years of use of

the software. It may be that the original developers are no longer available to take part in this phase. It is

only likely to be effective if the original design documentation is of high quality, so that it can be

followed and amended easily.

Maintenance Costs

It may come as quite a surprise to learn that during the 1970s maintenance accounted for between 35%

and 40% of the software budget for a typical information system project. This number jumped to 60%

during the 1980s, and if it continues at this rate then we might expect that by the year 2030 there could be

100% of development time spent on the maintenance of existing software. A contradiction in terms!

This could prove very costly for software developers, with most of their time and effort tied up in

maintaining existing software. Very little revenue is received by way of maintenance contracts, compared

with new developments. Maintenance is therefore very expensive.

Maintenance



Factors Affecting Maintainability

Among some of the classic problems associated with software maintenance are the following:

• The application being supported

If the application being supported is new then it is likely that users will request changes to

the initial requirements as they gain experience with the new system. There will therefore

be a high level of perfective maintenance.

• Staff mobility

The original programmer is often not around to explain the original source code. It is

always easier to change something that you have written yourself than alter something

that someone else has done. Unless the code is crystal clear and well documented then

you may require the input of the original developer. The nature of the programming

profession is such that individuals change jobs regularly and it is fairly unusual for one

person to develop and maintain a program throughout its useful life.

• Too many versions

It is often difficult to trace the evolution of the software through many versions or

releases. Changes throughout the new releases may not have been adequately

documented and this can make understanding the code very difficult.

• Not enough documentation

Documentation of the software design does not exist, or is not worth the effort of reading

because it has not been kept up-to-date with code changes.

•Dependence on external environment

For example a program may depend on the information

generated by an external source. If this source alters,

then the program may need to alter.

•Hardware and software stability

Software which depends on a particular hardware platform

or operating system may require modification if either

of these is upgraded.

Design Factors Affecting Maintainability

There are also program design factors which can affect a system's maintainability.

Module independence

In tightly coupled systems, where procedures communicate

using many parameters, and the same parameter may be used by

many procedures, a change in data type of this parameter will

require modification to many parts of the system.

Programming language & programming style

Some programming languages, by nature of their development

environment, their syntax and semantics, provide simpler

maintenance environments than others.