software development process - int 2

Software Development

INT 2 Computing - Software Development Infosheet 5.6.1

Adapted by P W Shadbolt from materials produced by LTS 2006.

What is software?

You should already know that any computer system is made

up of hardware and software.

The term hardware is fairly easy to understand, because you can see it. It is

all the pieces of equipment that make up the system - the processor, monitor,

keyboard, mouse, printer, scanner and so on.

Software is not so obvious. It is all the programs,

instructions and data that allow the hardware to do

something useful and interesting.

Think about all the different items of software that you have used in the last week

or so.

Here is a list of popular programs that you may be familiar with:

• Microsoft Word (the word processing program that I use)

• Microsoft Excel (spreadsheet used to keep charity accounts for which I am the treasurer)

• AppleWorks 6 (integrated package - I mainly use its word processor and simple database sections) .

• Internet Explorer (both PC and Mac versions - for browsing the web)

• two different e-mail clients (Nets cape Communicator and MS Outlook

• iPhoto (for organising my digital photographs)

• iMovie (for editing digital movies)

• Safari (web browser for MacOS X)

• Adobe Photoshop (for editing digital photographs)

• Adobe PageMaker 6.5 (for creating worksheets to be used at school)

• Toast (for burning CDs)

• Adobe Acrobat (for viewing pdf files)

But that’s not all! On each computer that we have used, a program (or group of programs) called the

operating system must have been running. So we must add the following to our list:

• MacOS 9.2 ( iMac at school)

• MacOS X.2 (on a iMac at home)

Thirdly, a full list would include all the actual documents, files, web pages, e-mails and so on, that we

had accessed, as these are also software. That would be too long a list, so I’ll ignore it here.




The development process Before we think about how software is developed, it is worth considering how any product is developed,

because the process is essentially the same.

For example, think about the process of developing a new model of TV.

Stage 1: Analysis

Before a new product is developed, someone within the

company, probably in the marketing department,

analyses what people want. They consider which

products are selling well, look at what rival companies

are producing, and maybe even carry out a survey to find out what people want.

From this they can work out which features are required in their newest model,

including its size, target price range and various technical requirements.

They use this information to produce a specification for the new model of TV. This states clearly all the

features that it must have.

Stage 2: Design

The next stage is to turn the specification into a design. Designers will

get to work, alone or in groups, to design various aspects of the new

TV. What will it look like? How will the controls be laid out?

Sketches will be drawn up and checked against the specification.

Another team of designers will be planning the internal circuitry,

making sure it will allow the TV to do all the things set out in the

specification.

Stage 3: Implementation

Once the design phase is over, engineers will get to work to actually

build a prototype. Some will build the case according to the design,

while others will develop the electronics to go inside. Each part will be

tested on its own, and then the whole thing will be assembled into a

(hopefully), working TV set.

Stage 4: Testing

Before the new model can be put on sale, it will be thoroughly tested. A wide range of tests will be carried

out.

It might be tested under ‘normal’ conditions. It could be put in a room at

normal room temperature, and checked to see that all the controls work

correctly, the display is clear, it is nice and stable, and so on.

If it passes this type of testing, it might be tested under ‘extreme’ conditions.

For example, does it still work if the temperature is below freezing, or very hot and humid, if it is used for

long periods of time, or with the volume or the brightness or contrast set to their maximum values.




Finally, it could be tested under

‘exceptional’ conditions. What happens if

a 2-year old picks up the remote and

presses all the buttons at once? What

happens if there is a power cut, or a power

surge?

If it fails any of these tests, it might be necessary to go back to the implementation (or even design) stage

and do some further work, before re-testing.

If it passes all the tests, then the new TV can go into production.

Stage 5: Documentation

However, the development isn’t yet complete! Some documentation

will be needed to go with the TV - a User Manual containing all the

instructions about how to work the new TV, and probably a

Technical Manual for repair engineers.

Stage 6: Evaluation

Once the model is in production, the company will want to

evaluate it. Does it do what it is supposed to do? Is it easy to

use? And, from the engineer’s point of view, is it easy to

repair?

Stage 7: Maintenance

Stage 6 should be the end of the story, but in the real world, there needs to be

stage 7 - maintenance. There are different kinds of maintenance: fixing faults that

turn up once the product is being used

regularly, improving the design to make

the product even better, or making changes

for other situations the product may face

(like making a version that

will work in another

country) .

These seven stages are an essential part of any production system

and are collectively known as the Development Process.

Software Development Process



A system is much more than an environment of computer hardware and

software, and in some cases will have none of these components. You

only need to look around to see that in the world of work some systems

do not contain or utilize computers.

A small companies payroll system

may have a process set-up to pay

employees but does not use any

computers. The amount of Pay, Tax,

National Insurance, etc is calculated manually and the employees paid

in cash. Books are kept with all the total information regarding the

staff payroll and are kept for

years.

So, when does a system become a computerised system and the

design of a computerised solution become a requirement? What

factors would influence this decision?

The most common factors are:

• the manual system becomes overloaded by increasing workloads

• the system is too dependent on skilled staff who are expensive or difficult to employ

• the nature of the work changes

• frequent expensive errors are made

The manual system will have to undergo a rigorous process of Systems Analysis and Design to transform

it into a computerised system.

Developing Computerised Solutions

Prior to the 1960's computer solutions

were developed with little regard to

what we now recognise as established

methods. Development of a system

was handled by highly trained,

technical personnel within an

organisation. There were many

problems with this approach. Too often user's

needs were met by programmers who did not

take into account the system as a whole.

Managers and directors are not expert programmers, but understandably knew

that these systems were not what they required. They insisted upon better

solutions. The solution lies in a method of clearly translating a verbal or

textual description of an idea into a feasible solution.

Software Development Process



The only way to guarantee that the best solution is

identified at the earliest opportunity is to adopt a

clearly defined system of procedures and practices that

provide guides and checks that all factors have been

taken into account at all stages of the development.

The most popular and widely used system in industry is

referred to as the waterfall model.

Lots of different versions of this development model

exist, each one is usually specific to the type of

problem that is being solved, but each follows basically

the same procedures.

THE WATERFALL MODEL

MAINTENANCE

ANALYSIS

DESIGN

IMPLEMENTATION

TESTING

DOCUMENTATION

EVALUATION

Using the ‘Waterfall Model’ each

stage is created and completed in

turn before moving on to the next

stage. This process continues to the

completion of the task however as

we move from one stage to another

questions or problems may arise that

require that we return to a previous

stage to obtain clarity. This referral

to previous stages to answer

questions and resolve problems is

referred to as an Iterative Process.

ANALYSIS



A systems analyst is the person who is capable of ensuring that all of the

demands of the system are properly analysed, documented and applied. 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.

Skills Of A Systems Analyst Most systems analysts have a background in programming. The first

thing that a systems analyst needs to learn is to communicate effectively with the user / client and

technical systems developers. The analyst is like a buffer between the user / client and the systems

development team. These communication skills can be transferred into many other aspects of the job.

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.

Clients are not usually technically skilled, therefore the analyst

must develop ways of extracting their needs, documenting

these needs in some formalised way and finally

communicating them to the team of designers and

programmers who will build the system.

Analysis of the problem

Systems Analysis relates to the understanding of the problem, clearly identifying what the solution to the

problem must do.

What type of computer and what operating system will be used to run the program?

Will it need special input or output devices?

Will it be using specialist backing storage devices?

Problem Specification

The problem specification is a clear and precise description of the

problem understood by both the programmer and the client. A clear

statement of the problem inputs, outputs and any assumptions are stated.

It is important to get software correct the first time. For example, if new

software was being developed for all of the banks in Scotland the cost

would be very high, therefore it is imperative to get the software right

the first time, to save money and keep good customer relations.

The aim is to produce robust and easy to use software. Program

schedules (the expected time for each stage of development), test plans

(to check that is robust and correct) and user documentation (instructions on how to use the package) arise

from the problem specification.

ANALYSIS



Errors

Any errors regarding the problem specification should be

detected early in the development cycle. If not they can be very

costly to resolve especially at a later stage in the development of

the software. If errors are not detected then poor testing and

incorrect documentation will be produced as a result. It costs

more to correct an error at the maintenance stage of software

development that it does at the analysis stage.

Algorithm

An algorithm is a set of instructions that describe how a particular type of problem may be solved.

When we are going to make

something e.g. a meal we

firstly need all of the

ingredients combined with

the recipe. Every time we go

to make the meal after this

we use the same ingredients

and follow the same recipe.

If we missed something out

then would not end up with

desired result! The input and

the recipe must be clearly

identified and adhered to

obtain the expected output.

An algorithm correctly implemented will always produce a correct result. In computing the correctness of

a program can be ensured if the correct algorithm is chosen.

A problem is fully specified when it is stated clearly and we define the inputs and outputs for the problem.

Only when both the analyst and the client are sure and happy about the

idea and its proposed development, only then will the analysis stage may

be completed. It is a lengthy iterative process (repeatedly checking that

the various stages are correct and do the correct job) , but both parties

must be 100% sure before the next stage in the development can take

place.

DESIGN



Once the needs of the user are clearly understood and documented,

software development can move onto the next stage - the DESIGN of

the system. System Design involves the methodical planning of the

solution to the problem. Systems Design answers the following

questions:

•What the hardware and software environment of the system

will be.

• The programming language to be used.

• HCI - screen designs, menu options, etc.

When the problem for the programmers is clearly specified there

are some techniques which the programmer can use to produce the

program. A number of methods are available, they all express large

problems as a set of smaller problems. This method is called Top

Down Design. Top Down Design is a process of breaking a

problem down into smaller problems, this is known as stepwise

refinement. Stepwise refinements continues until the subproblems

are manageable enough to be coded. It is necessary to use a

structured and methodical approach to planning the solution.

These techniques can be used in any type of design or planning. We can use a Top Down Design

technique to write an essay.

Introduction

Set Scene

Introduce Main Characters

Introduce Plot

Middle

Develop relationship between main characters

Introduce a minor but important character

Develop Plot

Tell strand 1 of plot



Ending

Bring together strands

Conclusion of plot

Happy ending

DESIGN



Two graphical methods of designing the structure of a program which we will look at are structured

diagrams and flow charts.

Structured Diagrams

Structured diagrams represent the top down design of the solution by 'layering'. The top layer of the

diagram is the initial problem. The second top layer shows the breaking down of the initial problem into

smaller problems, and so on. It's a tree-like diagram.

Example

A program has to be written to find the average of a set of numbers.

A typical structure diagram for this problem could be:

Notes about structure diagrams

• The box at the top describes what the whole program

does.

• The boxes below are arranged in logical order from left

to right.

• Each box shows a different section of the program.

• The flow of data may be indicated by an arrow labelled

with the data name.

Flow Charts A flowchart is often used to illustrate an algorithm (set of

instructions) to solve a problem. A flowchart is a diagram which

uses different shapes and arrows to show the steps in a problem

solution. Particular box shapes are used to represent different

aspects of coding.

Example

A program has to be written to find the average of a set of

numbers,

A typical flowchart for this problem could be:

Finding the average of a

set of numbers

Get firstnumber

Repeat until nomore numbers

Calculate averageby dividing total

by count

Print average

Add number to total

Add 1 to count

Initialisevariables

Calculate average

Start

Get first numbers

Any morenumbers?

Print out average

Stop

Yes

No

Add number

to total

Add 1 to count

FLOWCHART

DESIGN



Pseudocode Pseudocode is a cross between a programming language and English. Pseudocode is sufficiently like

English to allow you to concentrate initially on your program design without having to worry about the

complexities of the programming language using key words.

When writing pseudocode it is important to use indentation and keywords to represent the design

structure. Every program should be broken down into modules and then each module should be described

and again broken down fully. This is known as step-wise refinement.

Stepwise refinement can be identified by the numbering of the statements. Indentation of the

statements helps to represent the design structure. This helps to make the program more readable.

Example

A program has to be written to find the average of a set of numbers.

Typical pseudocode for this problem could be:

Program Inputs: data

Program Outputs: average

Algorithm 1 initialise variables

2 work out average

3 print the average of the data set

Refine step 1 1.1 initialise the total and count of data items

Refine step 2 2.1 get the first number

2.2 while there are more numbers do

2.3 add number to total

2.4 increment the count of numbers

2.5 endwhile

2.6 divide the total by the count of numbers

DESIGN



Software Characteristics

At each stage of the design process the programmers must consider

certain characteristics of the program they are developing. Some

relate to the requirements of the customer who is going to use the

software. Some relate to other programmers or computing

specialists who may have to read the program.

Fitness for purpose

A program should be:

correct A program should produce the correct answers (output) for all valid data (inputs).

There is no point in producing a program that doesn't do the task required.

reliable Are there any design or coding bugs? Does the program work for any situation ?

efficient The program should run at a speed that is appropriate to the task it has to perform.

There is no point in a bank auto-teller that takes four hours per transaction.

Likewise a small business payroll program which had to run on a super-computer wi

Gigabytes of RAM would not find many customers.

Design of the User Interface

The screen presentation should be clear. The user should receive consistent instructions on how to

proceed through a program. If at different stages the program stops running until the user presses the

<space> bar then the screen instructions on how to proceed should be positioned at the same place on the

screen. The user will look to that place. Clear prompts should be given.

The software should be robust. The user should see any data entered on the screen so that it can be altered

if necessary. Suppose you wanted to type in '37' but you typed '73' instead. How do you know that you

have made a mistake during data entry if you do not see what you have typed. It should be clear to amend

what you have typed if it is incorrect.

All inputs should be validated (checked to ensure that they are appropriate) and helpful messages given to

the user. This means that any entry at the keyboard should be automatically passed into a module which

will test the validity of the input before accepting it. If your entry is being rejected as invalid - e.g. 31st

February 2000, then you should get an error message on-screen.

If invalid data is allowed into the program it may cause the program to 'hang' - this is when a data item is

entered which is not acceptable input. The program cannot proceed and you will have no option but to

come out of the program.

The program should give correct results for all acceptable inputs. The program should present the user

with prompts that make sense and are easy to follow. Menus should have suitable headings and be well

structured. Option names should be meaningful. Error messages should attract the user's attention with

possible actions indicated.

Implementation



Implementation is the third stage in the software development process.

This stage involves the translation of the design into a form that the

computer can understand - program code. There are many high level

programming languages available, Basic, Comal, Pascal, Visual Basic,

Algol, Primex, C ++ etc.

Choosing a Programming Language

When considering the problem many questions need to be answered

regarding which programming language to use - How complex is the

problem? Which language will be the most effective for the particular

problem? What hardware is needed for the language? Can I develop a

program in modules, that is, with procedures? Does the language let

me do structured programming? Does it support sequence, repetition

and selection? and so on.

In general a good programming style will be user friendly; be

as short as possible at the top level; have clear internal

documentation; use meaningful variable names; have routines

to check that all the inputs are acceptable; and show a clear

structured layout.

Types of Languages

The nature of the problem that you are trying to solve will

decide the programming language that will be used. Some

languages are special purpose and suited to solve one particular type of programming language, such as

Primex (an expert system shell) or Prolog. Others are general purpose and these are designed to produce

programs that solve a wide range of problems, such as Comal, Pascal, Hypertalk, Visual Basic etc.

There are 2 different types of languages. They can either be procedural or declarative.

• In a Procedural Language the programmer identifies all the

instructions that the program must carry out to complete the

task and set them in the correct order.

• Declarative languages allows the programmer to define the

problem being solved in terms of the facts and relationships

contained in the program.

Once you have coded the design of your program in

a High Level Language you will run the program on

a computer which has a translator program for the

code. All programs developed in High Level

Languages have to be translated into

machine code - this is the only language that

the computer understands! The translator

program may be an interpreter or compiler

depending on your choice of High Level

Language.

Implementation



When your coding is finished it is ready to be entered into the computer. The file that you create is

known as the source code. This code is then processed by the compiler and checked for any syntax errors

(language errors) and construction errors. The compiler then translates the source code into machine

code. This Low Level Language file of code is called the object file. When you run the program the

object file is loaded into the computer's memory and executed.

High Level Language Features

User Interface

The user interface is the way that your program looks to the person who is using it. This includes the

screen layouts, the prompts or instructions and the way it checks the input.

Screen Layout

How your program looks on the screen is important. If it is clearly laid out, then the user will find it easy

to use and follow. The problem statement may well include a description of the way the screen may look.

User Prompts

Programs must tell the user what keys to press to operate the program, or what type of input to give.

Input Validation

When a user can choose what they input, the program must check to see if it is the correct type, text or

number. For example, if a number is required then a number is entered. The program checks that the

number is in the correct range. This is called validating the data.

Variables

Variables can take the form of integer, real number, character or string. A variable is a name given to a

box in the computer's memory that is being used in the program. Programs are not very useful if they

cannot be used more than once. Therefore a program will be more useful if variable names as meaningful.

Reserved Words

The language in which you use to program will have reserved words. These are words that have a special

meaning in the High Level Language. These words cannot be used as variable names.

Examples:-

END LET PRINT FOR....NEXT

PROC....END PROC IF.......THEN DO......WHILE INPUT

Structured Programming

Structured Programming helps you to develop your program by organising your code into blocks. It is

based on three main techniques

SEQUENCE the program will do one thing after another.

REPETITION the program repeats an action either a fixed number of times or until a condition is met.

SELECTION allows the program to choose a course of action.

Processed by

Compiler

Object Code

10101101

1010000111011101

1101000010000000

01000101

0100101010010111

0010001000101001

Print"What is the length"

Input lengthPrint"What is the breadth"

Input breadth

Let area=length * breadthPrint "The area is "; area

Source Code

TESTING



TEST DATA

To make sure that the program actually solves

the problem you have to test it to ensure that

there are no errors. To carry out proper tests

you need to create and use multiple sets of

data, this is called test data. Test data must be

carefully chosen to ensure that all stages of the

program are being tested. There are three

different types of test data:

Normal

This is test data that is well within the limits that the program should

be able to deal with. This makes sure that there are no unexpected

results.

Extreme

Extreme test data is data which is at the ends of the range, that is on the

limit. This tests to make sure that the boundary limits are working correctly.

Exceptional

Exceptional data is data that is incorrect. This shows whether or not the software can deal

with unexpected inputs without crashing. This also helps to test the robustness of the

software.

When testing your program we need to create sets of test data. This test data

must include data from the three different types. The idea of this is to cover

different scenarios. When creating our test data, we must consider the

following point:

The expected results must be know in advance, that is we check

the test data manually first so that we can compare our

expected results with our known results when we run the

program.

Example a program has been written to tell you how many dollars your pounds can be exchanged for.

Normal input - 10 expected Output - 16

input - 100 expected output - 160

Extreme input - 0 expected Output - 0

input - 100000 expected Output - 1600000

Exceptional input - -5 expected Output - "your value must be greater than

zero please try again"

input - 0.47 expected Output - "your value must be a whole

number please try again"

input - five expected Output - "your value must be a number

please try again"

TESTING



ERRORS

There are three different types of error:

System Errors (Run -Time Errors)

System Errors are errors that affect either the computer or its peripherals. For example we

may write a program that sends its output to the printer as well as the monitor. If there is no

printer when we run the program then the computer will produce a system error message. A

common run-time error is to ask your program to divide by zero. These errors sometimes

make the computer stop altogether and we have to restart the computer.

To avoid system errors we should write code to check that the printer is connected before the

data is sent to the printer. In this case the computer would warn us in advance again with a

simple message on the screen.

Syntax Errors

Syntax Errors are errors that occur in the programming

language, i.e. EDN instead of END. Syntax errors cause the

program to fail.

Logic Errors

Logic Errors are very difficult to detect because a program

that contains logical errors will run, but it will not work

properly. To avoid logical errors we will have to 'Hand-Test' the program, this means working

through the problem line by line to ensure that the program does what we want it to do on

paper. This form of testing is also known as a 'Dry Run'.

Some programming software environments help to solve errors through interactive debugging. This

entails tracking a variable through a program and noting the values that it takes. Breakpoints can be

inserted to stop the program executing at a certain point. The contents of all variables which have been

assigned values up to the breakpoint will be kept and can be checked by the programmer. Step commands

can also be used. In this instance the program will step through a statement at a time, thus each statement

can be checked for error.

Thorough testing and debugging are essential. The process of

debugging involves looking for syntax errors. These are

usually easy to detect because most software environments tell

the programmer that a syntax error has occurred and will even

try to tell them where. This is called an Error Reporting facility.

System Errors (or Run-Time Errors) arise during execution of the program

and Logical Errors are found when the syntax is correct and the code runs

without any error, but the program does not give the correct result.

The correctness and reliability of the program can

only be determined by very thorough testing and debugging.

Once a module is tested and any

bugs removed it may be entered into

a module library to be used again.

This is advantageous as the

programmer does not have to write

new code every time that module is

used, and the module can be used and

called anywhere in a program any number of times. This is a feature that

saves time in the program development.

Documentation & Evaluation



When we look at a new piece of software the first place we look

at to understand how it works will be in the documentation.

Documentation is needed so that users of the program will know

how to use it. Good documentation should be concise and

complete. Any alterations to the system through upgrades or

corrective maintenance should be included in the documentation,

documentation should be maintained and kept up-to-date.

Two essential pieces of documentation are the User Guide and

the Technical Guide.

User Guide

The user guide should clearly tell the user all that they need to

know; the start-up instructions for the program, the facilities it

offers and how to use them. Ideally there should be tutorials

and examples for the user to become familiar with the

commands and the various sections of the software. This is now

commonly provided as on-line with interactive help and

tutorials. It is very common for developers to provide

documentation in an electronic form, this saves the cost of

producing paper-based documents.

Technical Guide

A technical guide should be provided as this

gives instructions on how to install the software

and details hardware and memory

requirements. The technical guide should also

include a section on troubleshooting, this will

help the user to get around any problems that

they may encounter.

Documentation is essential if any person other

than the programmer is going to use the

program.

At all stages of software development documentation should be evident.

Stage Documentation

Analysis Problem Specification

Program Description

Inputs and Outputs

Assumptions

Design Flowcharts / Structured Diagrams /

Pseudocode

Implementation Internal Commentary

Program and Output Listings

Test History and Sample Outputs

Documentation & Evaluation



Other Guides

Although User and Technical Guides are commonly given with

software, most companies include other guides to help the user.

e.g. Printing Guides

Shortcut Guides

Tutorial Guides

Extra Features or Function Guides

To evaluate our solution we must go back through

each stage of development of the software

development process and check whether the solution meets the requirements. The

evaluation stage is mainly concerned with answering the question:

Does the software meet the user requirements?

To answer this question, we need to return to the original aims

of the software development and judge the program against a set

of criteria. This criteria can be used against the different stages of the software

development process.

• In analysing the problem have we correctly interpreted the user requirements?

• During the design stage have we taken account of user interaction with the

program? This will include helpful screens, internal documentation and modularity.

• Is the program reliable?

• Is the program robust?

• Can the program be easily maintained?

• Is the program giving correct results?

• Is this the best solution?

• Has a user guide been included?

• Is there a technical guide?

• Have potential changes been suggested?

For example, during the analysis stage you are measuring how well you have understood the problem. In

using the recommended tools and techniques of analysis and through interaction with the client you will

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.

The criteria for the design stage helps to measure and develop screen

layouts, structured diagrams and algorithms. The criteria are used to

evaluate the modularity and portability of the software. The reliability,

maintainability and robustness of the software are validated through

its structure, readability and testing.

MAINTENANCE



The maintenance stage of software development comes into effect as soon as the

system is delivered to the client and enters into productive use.

Maintenance Procedures

Research has identified three maintenance activities.

1. Corrective Maintenance

A company will spend 17% of their time on

corrective maintenance. These are errors that

emerge during the use of the system that were undetected during system

testing.

2. Adaptive Maintenance

Here a company will spend 18% of their time on adaptive maintenance.

Adaptive Maintenance concerns the software environment of the system,

such as the operating system or the hardware environment of the system,

such as peripheral devices, processor etc. that have changed since the

program was originally developed and these have caused the program to fail

or operate less effectively. The system has therefore to be altered in order to

adapt to these changes.

3. Perfective Maintenance

65% of a company's time is spent on Perfective Maintenance. Perfective Maintenance involves

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

Maintenance Costs

In the 70's maintenance costs accounted for between 35 and 40% of

the software budget. This figure rose to 60% in the 80's, and if it

continues at this rate by the year 2030 maintenance costs will account

for 100% of development time.

This could prove to be very costly for developers as most of their

time will be tied up in existing software and little time will be left for

new developments.

Maintenace is very expensive.

Minimising maintenance costs will be determined by the answers to the following questions:

• Have meaningful names been used for the variables?

• Is there internal documentation which is helpful?

• Is there a user guide?

• Is there a technical guide?

MAINTENANCE



In general a good programming style will be friendly to the user; be as short as possible at the top level;

have clear internal documentation; use meaningful variable names; have validation testing routines and

show a clear structured layout.

Factors Affecting Maintenance

Many factors affect the maintainablity of a piece of software, some of the

most common problems are as follows:

Application

If the application is new, then it is likely that users will require

changes to the initial software as they gain experience.

Staff

It is fairly unusual for one person to develop and maintain a program

therefore, the code must be very clear and well documented so that the

original developer does not have to explain the original source code.

Versions

When software is evolving there are many versions, changes from one

version to another must be clearly documented.

Documentation

If documentation does not exist or has been kept up-to-date then it is not worth reading.

Documentation must be kept up-to-date with code changes and revisions.

External Environment

If the program depends upon an external source, any changes to the source may alter the

program.

Hardware and Software

Software that is on particular hardware or operating systems may

require modification.

Design

Design factors can also affect a system's maintainability.

software development process - int 2

Documents

software development

different items of software

development process

new tv

new model of tv

new product

list of popular programs

school macos