SD Textbook 2008syllabus

International Diploma in
Computer Studies
(
IDCS
)
2008
Systems Development
This workbook addresses the main topics
and issues associated with the
computer-based system development
process used within a typical business
organisation. The intention is to provide
the student with the requisite skills
and understanding to enable them to
become involved with systems development
projects in a meaningful way, with both
technical specialists and business managers.
The areas covered by the workbook include:
Organisational aspects of systems
development and the need for
a collaborative approach to this
Application of simple mathematical
techniques to solve problems in the design
and implementation of computer systems
Basic principles, activities and deliverables
associated with popular life cycle models
Key elements of leading analysis and
design methods
Requirements for documentation and
coding standards
Role of testing in software development
A case study is used throughout the
workbook to illustrate the practical aspects
of systems development.
For any other enquiries please contact one of our regional offices:
UK & Europe - Tel +44 (0) 161 438 6200 | Africa and the Caribbean - Tel +27 (0) 21 913 8928
East Asia - Tel +86 (0) 10 6518 9327 | Middle East and South Asia - Tel +971 (0) 4 391 2727
South East Asia - Tel +60 (0) 3 7710 5755
ISBN 0954307108

Systems
Development

ii NCC Education. All rights reserved. Unauthorised duplication is prohibited.
Published by:
NCC Education Limited
The Towers, Towers Business Park
Wilmslow Road, Didsbury
Manchester M20 2EZ
UK

Tel: +44 (0) 161 438 6200
Fax: +44 (0) 161 438 6240

e-mail: info@nccedu.com
http://www.nccedu.com

NCC Education Limited, 2007
Version 2.0

The copyright in this document is vested in NCC Education Limited. The document must not be
reproduced by any means, in whole or in part, or used for manufacturing purposes, except with the
prior written permission of NCC Education Limited and then only on condition that this notice is
included in any such reproduction.

Information contained in this document is believed to be accurate at the time of publication, but no
liability whatsoever can be accepted by NCC Education Limited arising out of any use made of this
information.

First published 2001

Trademarks: NCC Education acknowledge that the trademarks and registered trademarks of
products mentioned in this material are held by the companies producing them. Use of a term in
this material should not be regarded as affecting the validity of any trademark or service mark.

Copyright of any screen captures in this material are the property of the softwares manufacturer.

This material may contain some clipart which is copyright to the Corel Corporation.

The mention of any product in this workbook does not constitute an endorsement by
NCC Education Limited.

V2.0 iii

NCC Education
About NCC Education
NCC Education is a global provider and an awarding body of quality British education
programmes in Business, IT and Sales and Marketing, ranging from Foundation to Masters level.

Originally part of the National Computing Centre, we began offering IT qualifications in 1976 and
from 1997 developed our portfolio to include IT qualifications for school children and Foundation
and Business programmes.

Today, NCC Education has Accredited Partners in over 45 countries, five international offices
and academic managers worldwide employing the latest technologies for learning, assessment and
support. NCC Education is also partnered with the British Council Education UK programme and
quality assured by the QCA.

Our programmes are developed to provide the required skills and knowledge to help students
excel in their chosen career. NCC Education is recognised by universities, professional bodies
and employers around the world. Our students can upgrade their skills on our professional
development modular programmes, or complete a university degree in their home country or in
the UK via the NCC Education International Degree Pathway.

NCC Education provides students with the opportunity to gain internationally recognised UK
qualifications by studying at one of our global network of Accredited Partners either in the
classroom or online.

NCC Education values its students and offers continuous support and guidance throughout their
learning experience.

Thats why students worldwide choose NCC Education as their route to a quality British
education.

NCC Education Mission
To be a global leader in the assessment and certification of quality British education programmes
in the major transnational education markets.

In line with our Mission Statement, we will provide:

Innovative career-orientated programmes in business and IT.
The highest level of customer service in the industry.
A complete solution for our partners and students.

iv NCC Education. All rights reserved. Unauthorised duplication is prohibited.
NCC Education Quality British
Education
Our aim is to ensure all our students are equipped and competent in using and developing their
IT and business skills in todays transnational markets. As such, quality assurance is a rigorous
requirement of all NCC Education products and partners.

In support of this, NCC Education operates a Quality Management System that provides a
framework of standards and procedures within which it manages and controls all its project,
product and service activities.
Specifically NCC Educations quality objectives are:
To ensure that NCC Education Accredited Partners provide NCC Education
programmes which meet the requirements specified in our syllabus and
regulations.
To specify and maintain syllabi and regulations that meet the career development
needs of students specialising in the IT and business sectors.
To ensure where appropriate that syllabi and assessments meet international
academic standards.
To provide the highest quality administration and support to the international
qualifications allied certification schemes.

V2.0 v
How to Use Your Workbook
The author has been careful to structure this workbook with your assessment in mind. Each
chapter therefore covers an essential part of the Systems Development Syllabus.
This is a workbook, not a textbook and is aimed at providing an activity-based learning approach
and is therefore extremely interactive. This workbook has a practical approach and is carefully
structured to support and encourage you to discover and learn by doing.
Your lecturer will allow you time during lectures to perform the various exercises contained in
the workbook.
Generally, after each exercise carried out during class time, 5 or 10 minutes will be spent as
lecturer led group feedback time.
This workbook is the required textbook for the Systems Development module. Throughout the
workbook you will be given pointers as to where you can find additional information if you
should need it. This workbook is organised into six subject-based chapters, each of which
contain:
Indicative Content
This appears at the very beginning of each chapter and specifies the topics and level of detail of
the subject matter that you will be covering.
Introduction
Each chapter will always contain an introduction to the subject matter.
Text
Substantial text will follow regarding the subject matter, which will be interspersed with:
Exercises these are class exercises which reinforce the course material. We
have generally provided answers to exercises at the end of each chapter you
should note that in some cases there are many correct answers.
In order to gain the maximum benefit from each question we suggest that you
attempt it to the best of your ability before you refer to the suggested answer.
Some exercises may be in the form of actions to be carried out and have been
provided to reinforce learning, confirm understanding and stimulate thought;
there are no suggested answers.
Definition Statements these statements define precisely the meaning of certain
terms and the context in which they are used within the module.

vi NCC Education. All rights reserved. Unauthorised duplication is prohibited.
Study Note these are an aide-memoire and will help you to distinguish between
text that is background knowledge and that which you should understand and be
able to write about or carry out. You should pay close attention to these. They
are there to ensure you are fully aware of any important points raised within the
text.
Self Study Exercises these are provided at the end of most chapters. This
section contains directed self study actions to enhance the learning experience
and allow students to explore topics to a greater depth.
Further Reading You should try to extend your reading well beyond this
workbook if you want to fully understand the subject matter. Pointers are
provided to appropriate books and websites.
Summary
Finally, each chapter ends with a summary detailing what you should understand and be able to
write about, or actions which you should be able to carry out. If you reach this stage and do not
understand and/or cannot describe and explain the topics detailed in the summary, then we
suggest you re-read the chapter, re-do any exercises/activities suggested and perhaps consider
some further reading.
Feedback
Your feedback will help us improve our workbook. Should you have any questions regarding the
content of this workbook, or have any suggestions on how it could be improved, then please
contact us, as detailed on the feedback sheet contained at the end of this workbook.

V2.0 vii
Contents

(Note: A detailed Contents appears at the front of each chapter)
Page
Chapter 1 Businesses, Systems and Teams................................................ 1-1
Chapter 2 Mathematics for Computing......................................................... 2-1
Chapter 3 System Development Life Cycles ................................................ 3-1
Chapter 4 Software Analysis and Design Methods ..................................... 4-1
Chapter 5 Documentation and Standards .................................................... 5-1
Chapter 6 Testing ........................................................................................ 6-1
Glossary

viii NCC Education. All rights reserved. Unauthorised duplication is prohibited.

V2.0 1-1
Chapter 1
Businesses, Systems and Teams
1 Indicative Content........................................................................................1-2
2 Introduction..................................................................................................1-2
3 Computers in the Modern World..................................................................1-3
3.1 Communicating Design......................................................................1-4
4 Information Systems ....................................................................................1-5
5 Velotec Ltd...................................................................................................1-6
5.1 The Business .....................................................................................1-6
5.2 Organisation Structure.......................................................................1-7
5.3 Major Systems ...................................................................................1-8
6 The Information Systems Department.........................................................1-9
6.1 IS Manager.......................................................................................1-10
6.2 Operations Management .................................................................1-11
6.3 User Support....................................................................................1-11
6.4 Systems Support..............................................................................1-11
6.5 Telecommunications or Network Management...............................1-11
6.6 Development Manager.....................................................................1-12
6.7 Development Project Team.............................................................1-13
Project Manager...............................................................................1-13
Systems Analyst...............................................................................1-13
Database Administrator (DBA).........................................................1-13
Programmer.....................................................................................1-14
7 Velotec Information Systems.....................................................................1-14
7.1 Velotec IS Department.....................................................................1-15
8 Relationships with Business Managers.....................................................1-17
8.1 History of the IS Department............................................................1-17
8.2 Understanding Requirements..........................................................1-19
9 The System Development Life Cycle.........................................................1-20
9.1 System Maintenance .......................................................................1-22
9.2 Velotec System Maintenance..........................................................1-23
9.3 Minimising Maintenance ..................................................................1-23
9.4 Velotec Documentation and Standards ...........................................1-24
10 Summary....................................................................................................1-24
11 Self Study...................................................................................................1-25
11.1 Exercise ...........................................................................................1-25
11.2 Townsfield Case Study....................................................................1-25
12 Answers .....................................................................................................1-30

Chapter 1 Businesses, Systems and Teams Systems Development

1-2 NCC Education. All rights reserved. Unauthorised duplication is prohibited.
1 Indicative Content
Brief overview of:
Computers in business.
User communication.
Business organisations.
Information Systems (IS) and the systems development process.
Roles and functions in a typical system development project.
Relationships and user requirements.
Tasks and contributions of the members of a systems project team.
The systems life cycle and maintenance.
2 Introduction
This module will cover a number of issues and topics which need to be
understood in order to pass the module assessment and to gain work in
the computing profession. In addition, this module will assist you to
understand and put into context material covered in other modules and
also prepare you for further study.
This workbook covers the main topics and issues concerned with the
computer based system development process within a typical business
organisation. What we mean by a system is explained in section 4. The
emphasis of the systems development process is firstly on business,
secondly on management and lastly on the technical details of system
development. Many in the profession of computing appear to believe that
the technology is most important, when actually it is simply a tool to be
used to help a business to be more effective and to be more efficient.
Not only will this workbook be helpful to you as you study to pass the
module, but it will also provide you with the basic knowledge and
understanding required of junior members within a systems development
team. You will learn some of the mathematical basics that underpin the
design of computer systems. At the end of this workbook, you will be able
to become involved with system development projects in a meaningful
way, with both technical specialists and business managers.
This first chapter takes a close look at the organisational aspects of
system development and in particular, why such development is always a
collaborative process. Managing systems development is a challenge
which involves bringing together all the people, with the appropriate skills,
who are needed to develop a system. The process of systems
development is difficult to describe, and even harder to understand, in an
abstract fashion. Due to this, we will use a case study approach all the
way through this workbook. Student exercises are contained within the
Systems Development Chapter 1 Businesses, Systems and Teams

V2.0 1-3
workbook. The business case study will be typical in some respects, but
subject to problems that you will be asked to solve or to discuss in groups.
3 Computers in the Modern World
The use of computers within business organisations is increasing each
day, due mainly to the reduction in their price and the substantial increase
in power. In addition, as the cost of human resources continues to
increase (weekly wages) many work roles have been, and will continue to
be, transferred from humans to computers and also to computer
controlled machines.
In the developed world it is difficult to find a part of daily life that is not
affected by a computer. Most of us today know about computers through
our use of, and the widely available, PC.
In 1981, the first IBM PC ran on a 4.77 MHz microprocessor. The PC
came equipped with 16 kilobytes of memory, expandable to 256k and with
one or two 160k floppy disk drives and a very heavy monitor, not even in
colour. The price tag would be over US$4,000 today.
The PC only became widely used when the hardware and software
became standardised and key applications became available around
1990.
It was only in 1987 that the Internet became commercially available and at
that time, only around 28,000 host computers were connected to it. Now
we have around 500 million.
We are thus still in the early days of development!
Discussion point 1: 15 minutes
As a group exercise, discuss how computers affect the lives of group
members.
What would change if all computers failed to work for say one week?
What effect would this scenario have on you, on your family; on anyone
you know who has a job?
Hopefully your group will soon reach the conclusion that much of the
world would not be able to continue as we know it today.


Discuss some of the good and bad uses of the Internet.
What will computers be used for in your lifetime? As a computing
student, you will be part of this development.
Motivation is important to ensure you learn well and after passing this
module successfully, any development work in which you are engaged
should be accurate, well designed, fully tested and accurately
documented.
3.1 Communicating Design
One of the problems we face in the development and design of computer
systems is showing those for whom we develop the system, what it will
look like and how it will work.
In many forms of design, for example building construction or engineering,
scale models are produced to show the customer. Scale models of new
hotels, shopping malls and golf courses for example, are all produced so
that customers can easily visualise the development and comment
accordingly. Many people are unable to visualise from a two dimensional
drawing, however detailed and colourful. Even with sophisticated 3D
(three dimensional) models produced on computers, many people are
unable to appreciate what is still a flat image.
In the computing profession we also try to produce models which will
show the way in which the data will be collected and the form of the
output of the system, which often includes screen layouts. However, many
computer systems are large and complex and fail to meet user
requirements, because the analyst has not understood exactly what the
user wanted or the user forgot to mention some vital part of the system.
Users have a habit of changing their requirements, or the system may
need to be changed after specification, due to changes in the business or
an external change such as new laws. We will cover some of these
difficulties later in the workbook.
However working within the world of computing is varied, exciting, always
moving forward and rewarding.
Most computer systems used in a business organisation are called
Information Systems (IS). An Information System is a computer system
and the process of collecting the data, the procedures and people
involved, all combine together in a structured way. This will be covered in
the next section.


V2.0 1-5
4 Information Systems
Those people not directly involved with computers assume that the
computer is the only or most important part of an information system. As a
student of computing, you need to fully understand that the computer is
similar, for example, to the engine of a train. There are many other
components involved in a railway system which include; train, driver,
track, stations, signals and control, timetable, station staff, ticket office,
finance and accounting procedures and staff, training for staff,
passengers, goods, and no doubt you will think of other components too.
As such, all these components combine to form the railway system.
Within the railway system there are sub systems, such as the accounting
system and the signal and control systems. Each subsystem is made up
of detailed components and procedures. The purpose, or desired result of
the whole railway system, is to transport goods and people from one
place to another in a safe and timely manner.

The above definition is a direct quote, which means it uses words which
have been taken directly from anothers work, and they are not our own
words. When quoting anothers work, it is important to use quotation
marks () to avoid plagiarism or cheating. The source of the words also
needs to be clearly stated, as we have here in the footer, but this is
usually stated in a reference section at the end of the document.
People often talk of computer systems, but this does not cover all the
components. We should use the term Information Systems (IS) which is, a
structured set of processes, people and equipment for converting data
into information.
In our case the equipment is all the IT hardware and software (computer
programs) involved in the collection, transmission, storage, processing
(calculation, analysis and manipulation) of the data in order to produce
information. We will introduce some case studies which will help you to
understand the components of an IS and the various job roles within IS,
the interaction with business users and in some cases, the customer.

1
M E C Hull, K J ackson, A J J Dick. (2004) Requirements Engineering, Springer ISBN 1-85233-577-7
Definition.
A system is a:
collection of components - machine, software and humans, which all
cooperate in an organised way to achieve some desired result.
M E C Hull (2004)
1
.

In groups, identify a typical Information System that you have seen or
even used in your daily life.
5 Velotec Ltd
Understanding the content of this workbook will be much easier (and
much more interesting) if we use a fictitious company within which we will
role-play certain scenarios. We will use Velotec Automotive Components
Ltd (Velotec) as our case study business, and you will be expected to take
a series of decisions about how systems development is undertaken at
Velotec, and then to follow your decisions through to see the
consequences.
Velotec Automotive Components Ltd is a fictitious company. Any
similarity to a real company is purely coincidental.
5.1 The Business
Velotec is a medium-sized manufacturing and retail services company,
established twenty five years ago. It has three main lines of business:
Producing car accessories and tuning equipment for the enthusiast.
These are sold through a large number of retail stores and directly
through a website.
Fitting new brakes and exhausts to cars through a chain of ten drive-
in workshops that are owned by the company. These workshops are
all based in and around the capital city.
Producing high technology components and assemblies for the
automotive industry, especially for motorcar racing.
The first and second of these lines of business are wholly consumer
based, known as business-to-customer, and the third is strictly business-
to-business. The company does not produce many of the car accessories
or consumable items, preferring to subcontract production wherever good
quality can be obtained at a good price. All of the high technology
products are produced by Velotec in their own factory, often referred to as
in-house production. The accessories sell through the brand name, as
customers are aware of the products used in motor racing and the
enthusiasts like to buy accessories with the same brand name. The
same is true of the exhaust and brake fittings; the company trades on the
image of rapid fit.
Velotec employs about 2,500 people; most of whom (about 1,500) are
based in one location, the rest are based in the local workshops.

V2.0 1-7
5.2 Organisation Structure
The Velotec organisation structure looks like this:

This is not a complete organisation chart; it shows only the directors and
the subordinate managers for the Finance Director and the Manufacturing
Director.
We will discuss the structure of Velotec Information Systems Department
a little later in this chapter.
Exercise 1.1 20 minutes
Notice that Velotec has no direct board level representation for
Information Systems. The IS Manager reports through the Finance
Director. What advantages and disadvantages do you think this
reporting relationship offers?
You will be expected to review your thoughts after the introduction of
the Townsfield case study.

I S M a n a g e r
C h i e f A c c o u n t a n t
F i n a n c e D i r e c t o r
D i r e c t o r R e t a i l O p e r a t i o n s
D i r e c t o r W o r k s h o p O p e r a t i o n s
D i r e c t o r H u m a n R e s o u r c e s
D i r e c t o r M a r k e t i n g
M a n a g e r H i g h P e r f o r m a n c e P r o d u c t s
M a n a g e r C o n s u m e r P r o d u c t s E n g i n e e r i n g
D i r e c t o r M a n u f a c t u r i n g
M a n a g i n g D i r e c t o r
C o m p a n y S e c r e t a r y
C h a i r m a n
Figure 1. 1 Organisation Structure

5.3 Major Systems

Velotec uses a mixture of package software and in-house systems.
Packaged software is used wherever possible, but some important
applications are developed and maintained in-house, by Velotecs own IS
teams, because they deliver a significant commercial advantage.
Examples are:
The website and the associated back-end systems, including order
processing and tracking, and links into the stock control system.
A large stock control system that helps to manage the level of
consumer stock and workshop stock held in the warehouse. This is
critically important, because each of the workshops has to be able to
fit any exhaust to any popular car within one day.
A customer loyalty scheme based on a budget card, issued to all
customers at the workshops and usable against purchases of
accessories at the retail stores. This card entitles the user to
discounts on future purchases. The card is swiped through a reader
whenever the owner makes a purchase. Note these loyalty card
schemes enable the company to gather data on the purchasing habits
of their customers. The collection of this type of personal data has
both advantages and disadvantages for the customer.
A variety of special purpose engineering analysis programs used by
the high performance products department. These supplement the
bought-in packages used for the same purpose.
A special purpose accounts system used only by the high
performance products department. This focuses on projects, hours of
work and other costs, so that the costs of special projects can be
obtained and their profitability monitored.
Definition
Software Package a group of pre-written, fully tested and
documented functional programs that can be purchased ready to use
on a computer to carry out application tasks, e.g. word processing,
general payroll.
Definition
Application Software a specialised program or a series of programs
that is a software package, with associated documentation, and which
performs a particular function, a specific task or job to meet a specific
user need, e.g. company payroll, stock control system, sales analysis
reports.

V2.0 1-9
Further details about Velotec will be added as you work through this
workbook, but now we must look not at the detail of Velotec, but at
businesses in general and how they organise their Information Systems
departments.
Exercise 1.2 3 hours
There is clearly a choice between using packaged software and
developing a system in-house. There are however, other ways in
which Velotec could obtain for example, the website services that it
uses. Carry out some research using IT and business journals and
magazines to find at least two other ways in which Velotec could obtain
these services. Comment on why you think Velotec has not yet made
use of these possibilities.
6 The Information Systems Department
Most Information Systems departments are made up of smaller teams
consisting of people with specialised skills. We will first consider a list of
the skills not directly associated with systems development and then
review those skills most closely aligned with systems development. We
will then see how the Velotec Information Systems department is
constituted.

Definition
Information Systems a structured set of processes, people and
equipment for converting data into information. Note this definition uses
slightly different words than those used previously but conveys the
same meaning.
Definition
Information Technology as mentioned earlier, we will take IT to
mean all the computer hardware and software (computer
programs) which are used to collect, store, and process data and
to distribute information.

6.1 IS Manager
An Information Systems Manager or Director takes responsibility for the
delivery of all information services to the business. The person with this
role will take the lead in defining an Information Systems strategy for the
business so that it can gain a competitive advantage from using the most
appropriate information systems. From this, the manager will establish
the definition of an Information Technology strategy that will determine the
computer platforms and technology necessary to enable the Information
Systems strategy to be delivered. The IS manager will be a member of
the Information Systems Steering Committee, which is a cross-
departmental group of people set up to discuss and agree all strategic
IS/IT matters. The manager has full budgetary and line management
responsibility for the department.
What problems do you think can be avoided by this more modern view
of responsibilities?
Study Note
Notice that we are talking about an Information Systems department,
not an Information Technology (IT) department. There are a number of
different and confusing views as to what IT means. IT is increasingly
used as ICT (Information and Communications Technology), as most
systems now include telecommunications.
Both IS and IT terminologies are in common use, as is Management
Information Systems (MIS). To some extent the terminology follows
fashion, but there is a more profound reason why many IT departments
have their name changed from IT to IS. We will explore this later in the
chapter.
Study Note
There is an important distinction between being responsible for the IS
department and owning Information Systems.
Most modern businesses correctly regard the owners of Information
Systems to be the Business Managers for whose departments the
systems were implemented.
This is a major change from previous generations where all aspects of
IT were believed to be solely the responsibility of IT specialists. You
should be prepared to discuss this issue and the Townsfield case study
will be provided later to assist the discussion.

V2.0 1-11
6.2 Operations Management
Operations management is concerned with managing the use of
hardware, software, and personnel resources in the data centre of an
organisation. Operational activities that may be involved include data
entry, equipment operation, and support. This is a role that can be seen
in some very large organisations in which IS remains as a data centre and
usually mainframe or large online server configurations are centred. In an
increasing number of business organisations, data is collected
automatically or entered by the user, rather than in one centralised data
entry location.
In traditional mainframe data centres, a team of operators may be used to
handle the day-to-day activities needed to run the systems hosted by the
mainframe (or multi server) system. These people would form part of the
operations team, as would data preparation and data management
specialists. These roles are much less common in the medium sized
organisation, although some of the same functions may remain. In these
companies, system support personnel will usually carry out the residual
operations functions.
6.3 User Support
User support or IT support is concerned with ensuring that systems
continue to deliver effective functionality for user departments. The User
Support Manager will usually be responsible for a Help Desk, which is a
focal point for the reporting of all user-oriented problems. User support is
increasingly decentralised, where support is provided from within user
departments rather than from a central IT team. In such cases, the more
detailed technical support required is provided by an external company or
manufacturer of the equipment.
6.4 Systems Support
This group is responsible for maintaining the hardware and systems
software used by the business. They install new hardware, both locally
and at any branch offices. They install and maintain systems software
such as Operating Systems, Database Management Systems and
software tools. They also install and maintain a standard set of desktop
software used throughout the business.
6.5 Telecommunications or Network Management
The rapid growth of telecommunications networks in companies using
computers has made telecommunications a major information services
function. A telecommunications manager is concerned with the following:

Wide Area Networks (WANs), for applications such as online
transaction processing, inquiry and response, and electronic mail
(email).
Local Area Networks (LANs), for work group and end user computing.

This function may also be called Network Management, particularly in
small and medium sized organisations. The manager of this function may
report through the Operations Manager or directly to the IS manager,
depending on the type of technology used by the IS department.
Telecommunications Managers are usually responsible for evaluating and
recommending the acquisition of communications media, voice and data
communications carriers, and communications hardware and software for
end user, work group, and corporate telecommunications networks.
Telephone (voice) communication is a very important part of this role.
We will now focus on the development function.
6.6 Development Manager
In many medium sized and larger companies a group of specialists will
undertake all the internal systems development work. In some countries,
this group will be heavily supplemented by contractors who are hired to
carry out specific tasks. This allows the business to undertake big
projects without the need to have a large team of permanent employees.
The development function will usually be headed up by a Development
Manager who is responsible for the deployment of all resources required
during project development. Project teams are formed from the available
staff who have the necessary skills and knowledge required to complete
Definition
Wide Area Network a communications network covering long
distances and frequently employing some of the facilities of the public
network. Wide Area Networks (WANs) operate nationally and
internationally, using telephone lines, fibre optic cabling, microwaves,
satellites and radio transmissions, e.g. the Internet. One network can
be linked to another using a gateway or bridge connections.
Definition
Local Area Network a system that links computers, usually PCs, so
that they are able to communicate with each other to form a local
communications network that shares hardware, including printers,
storage and software facilities. LANs frequently also provide gateway
access to external networks.

V2.0 1-13
the project. Thus people will move from their team when their role has
been completed, to another project development team.
6.7 Development Project Team
Project Manager
A Project Manager takes full responsibility for the system to be delivered
on time, on budget and to an agreed quality standard. This is a
necessary and demanding role, usually filled by a senior and experienced
person drawn from the permanent employees of the IS department.
Systems Analyst
A Systems Analyst is responsible for defining what a system is required to
do in order to meet the needs of the business. This role requires the
analyst to work with the potential users of the new system, and their
business managers to clearly identify and record the business user
requirements in the form of a specification which the rest of the team can
work with in order to produce the desired system.

The above description of a systems analyst, although accurate, is
somewhat outmoded and could have been written twenty years ago. The
description given assumes a particular type of systems development life
cycle, where all the work on defining the specification is done at the
beginning, and when it is complete and signed off by the business
manager, the rest of the development process starts. This is increasingly
not the way in which projects are undertaken in many companies, as we
shall see when we discuss the development life cycle in more detail later.
In these cases, the role of the systems analyst changes, sometimes quite
radically.
Database Administrator (DBA)
Large proportions of the internal development projects undertaken by
businesses utilise a Database Management System (DBMS). The use of
such tools greatly reduces the time required to implement a large-scale
system. Usually a business will select a preferred DBMS and use this for
the majority of its systems, including those that are bought in as
packages. The Database Administrator (DBA) is responsible for designing
the database so that it is able to meet performance, security and
Definition
Systems Analysis the processes of investigation and analysis into
the feasibility of potential computer applications and the design,
implementation and subsequent review of computer-based systems.

integration requirements. The DBA often continues to provide support
after the development project is completed.

Programmer
A traditional view of the development process sees programming as a
purely mechanical process which is undertaken after the specification has
been agreed and frozen. This means it is signed off by the user
department manager and will not be changed, and that a complete
system design has been completed by a system designer. This can be
true for some projects undertaken in large organisations, but there are
more appropriate development models for smaller projects in smaller
organisations. We will explore these in this workbook.
Programmers use their knowledge of a programming language to
implement the system defined by the system specification. There are
varieties of such languages but a common choice for many projects is one
of the languages provided by a DBMS. These are sometimes described
as Fourth Generation Languages (4GL), although this terminology is less
frequently used by system vendors.
Large projects often use contract programmers who are hired for their
very detailed knowledge and skill of the particular programming language
and specific development tools.

7 Velotec Information Systems
Velotec is similar to many other companies in its use of IT. The use of IT
started twenty years ago with a combination of an external bureau service
and a small mainframe that was used for accounting and stock control.
This was later replaced by a UNIX based system and some 20 people in
the HQ building used this system through simple terminals wired directly
to the processor. As PCs became less expensive and performed more
local functions, they were installed initially for simple word processing and
spreadsheet work. The next development was the introduction of a Local
Area Network to allow file and print sharing between authorised users.
New applications were then located on the network servers and Windows
NT was adopted for these servers. The old UNIX system was replaced by
Definition
Database Management System a computer software package used
for the organisation, storage, manipulation, retrieval and updating of
data and information in a database. The system also manages and
controls the security and integrity of the database.

V2.0 1-15
more modern UNIX servers and incorporated into the network. All the
terminals have been replaced with PCs and client/server became the
standard approach. As the power of PCs increase and more sophisticated
applications become available, the Unix system is being phased out and
eCommerce is being considered.

The Velotec Managing Director is resistant to the idea of making the IS
Manager a director. If you were the manager, what arguments would
you use to change the directors opinion?
7.1 Velotec IS Department
Given the overview of typical roles and functions, we will look at the
structure of the IS department at Velotec.
Definition
Computer Bureau a business, which specialises in selling services
and time on its computer(s) to other business organisations.
Definition
Client/Server two categories of computers exist on a network.
These are known as clients and servers. A client requests services
and information from a server. A server supplies and delivers services
and information to a client.


The first thing you will notice is that the IS department is quite small, with
a total of only 19 full-time staff. A team like this is quite capable of
managing the IS needs of a medium sized organisation.
For business organisations which rely on information systems to assist in
running their business, the support of users of computing equipment is
vital. In the case of Velotec, this has been recognised and there is in
place a small user support team headed by an IT support manager.
The development team is not quite as definitively structured as might
appear. The project manager and systems analyst change roles
depending on the development project. Essentially, the project manager
is a systems analyst who takes on the project manager role for some
projects. There are two programmers employed full time, however the X
reflects the fact that contract programmers are used to supplement the
team, when required, to complete a project.
The IT support technicians share many skills, but one of them
concentrates mostly on PC desktops and NT servers, whilst the other has
strong UNIX skills. This person will need some training on the other
platforms in use, as the UNIX system is being phased out.
The various business departments represented in the full organisation
structure also have a member of staff who is nominated as an IS liaison
person. His/her role is to help users within the business unit to solve
Figure 1. 2 Velotec IS Department Organisation Structure
IS Manager
Secretary
Network manager IT support manager Development manager
Network
Technician (2)
Help desk
staff (2)
Support
technician (5)
Database
administrator
Project
manager
Systems
analyst
Programmer
(2+X)

V2.0 1-17
problems and to feed back support requirements to the IS department.
This represents (to some extent) a distribution of the IS support role.
The Manufacturing Director of Velotec holds a strong view that it would
be better to disperse all the IS functions into the departments and
abolish the IS department. Put yourself in the position of the Velotec IS
Manager and think of the arguments you might use to counter this idea.
Write down the points that you would make.

8 Relationships with Business Managers
The relationship the IS department has with the other functional
departments in the business is important. Often this relationship is based
on the maturity and history of the business and, to some extent, the
people involved. To understand the issues we need a quick overview of
how the IS department has been viewed over time.
8.1 History of the IS Department
IS departments have had many titles over the last 20 years. At first, these
reflected a purely technical view, so the title Computer Department was
common. This tended to suggest that managing such a department was
all about looking after hardware (which was true in the early days of batch
processing mainframe computers). As the technology matured, managers
of such departments felt, quite reasonably, that their role was rather wider
than this and had a lot to do with collecting and processing the critical
data that the organisation needed. This led to the Data Processing (DP)
department and the DP Manager.
The original application area for computer systems was heavily
concentrated around the financial activities of the business. This often
resulted in the DP Manager reporting to the Finance Director (FD). After
many years, some businesses began to realise that this was
inappropriate, and it was necessary to view data processing as providing
the delivery mechanism for Management Information to the whole
business. This resulted in a gradual change of title to Management
Information Systems or Information Systems department. In the most
Further Reading
Although an old text, this is still a good introductory text on organisation
structures; Mintzberg, Structure in Fives, Designing Effective
Organisations, Prentice Hall, ISBN 0138541914.


forward thinking companies, the role of MIS was seen as so significant
that it warranted a board level position.
The move from a technical role to one that recognised the value of
information to the business, has been reflected in a change in attitudes to
the development of Information Systems.
If we look back to the early days, computer systems were so poorly
understood by the business as a whole that business managers did not
become involved in a development project, except for the discussion of
requirements with the systems analyst. The completed system would be
implemented by the DP department, the users trained by the DP
department and finally, the system would be put into use. Neither the
business manager nor his staff had any real ownership of the project.
This led to a major problem of alienation (separation) between the
business function and the development team. This often had the following
consequences:
The users would often feel that another department was imposing the
new system on them.
The business manager would take no responsibility for the success of
the new system, because it was a DP department system, and not
his.
A more modern approach recognises that a business manager should
own business systems and that ownership should extend to the
development process. Instead of a system being imposed on a
department, the department commissions the new system using its own
budget and actively controls its development and implementation. This
idea is often extended to support, so that the department has some first-
line system expertise able to handle the simple user problems.
This model radically changed the relationship between users and the
development team. To illustrate this, we can trace through the early
decision making processes leading up to a development project.
The business manager recognises that an opportunity exists to improve
the way his/her department operates, or that a new requirement exists
that requires an Information System to support it.
The business manager produces a business justification for a new or
modified system (perhaps with some systems analyst assistance) and
presents it to the Information Systems Steering Committee for approval
and for prioritisation as part of the IS department workload.
The IS department forms a project team which carries out an initial
investigation with the business manager. This will quantify the size and
business case of the project, and may result in no further action, an
internal development project, or in some cases, the purchase of an
existing system from a software supplier.

V2.0 1-19
If an internal development project is undertaken, the business manager
will own the project, take full responsibility for the implementation of the
system and be held to account for the achievement of the expected
business improvement.
This type of approach is user or business-led. The IS department provides
a service to the business managers.
Think of two other functional areas of Velotec that could be considered
to provide a service to the business.
Do you think that the business views those services in the same way
as IS? If not, why not?
8.2 Understanding Requirements
We will explore a variety of different approaches to managing the
development process in a later chapter, but by far the most difficult
problem to be solved in any development methodology is the
understanding and definition of requirements. This is the realm of the
systems analyst, so we need to consider the relationship between the
systems analyst and the users of the new system; and the relationship
between the systems analyst and the programmers.

Why is this area so problematic? There are several reasons:
Business managers usually do not understand their requirements in a
sufficiently clear and coherent form to allow programmers to produce
a system. Systems analysts need to understand exactly what the
business user requires.
The systems analyst may have no previous experience in the field of
business. In theory, this should not be an issue, because any
business problem can be analysed from a systems viewpoint. In
practice, it is a major advantage if the analyst does have some
understanding because it allows him/her to communicate more easily
with the business manager. Without this prior experience, the analyst
has to spend much more time learning about business. For this
reason, in larger organisations, the systems analysts are called
Definition
Methodology a structured or logical set of methods used in carrying
out some complex activity.

business analysts and are increasingly attached to a user department,
rather than being located in the IS department.
The way in which we describe a project specification is usually difficult
for the business manager to understand. We can use different forms
of communication (diagrams, text, charts etc), but lack of
understanding is still common. The more analytical the language
used, the less ambiguous it is, but the more difficult it is for the typical
business manager to understand.
The act of studying the business managers requirements usually
changes the requirements. This is often simply a result of the
business manager being directed (forced!) to think more deeply about
what is needed as a result of the work of the systems analyst.
Remember, it is the systems analysts job to ensure the user has not
forgotten to mention anything which is likely to affect the design.
Over the years, the lessons learnt during the development of projects
have led to a variety of systems development models, and the life of a
project from its inception (birth), through development and use and
eventual replacement (death), has been called the system
development life cycle. Some system development life cycle models
require the full requirement specification to be completed before work
starts on system design and implementation. The specification may
take a very long time to produce (sometimes a year or more!).
Unfortunately, the business does not and cannot remain static during
this time, so the specification may well be out of date by the time it is
completed. Therefore, the process may need to start all over again.
We expect systems to be user friendly, but this quality is extremely
difficult to define and to specify. Frequently, users are only able to
say whether a system is friendly, that is easy to understand and use,
after a long period of use, but if changes are needed at that stage, the
cost of change is enormous.

9 The System Development Life Cycle
We have already introduced the idea that there is more than one way of
developing a computer system. In fact there are major differences of
opinion about the best way of developing any particular system. To some
extent these differences are based on individual experience and
preferences, but there is also a growing body of knowledge about
methods that work well and those that do not. There are differences in
size and complexity of projects. A method that works well for projects that
require three development staff for three months will be quite different to a
method suitable for major projects taking two years and using many
hundreds of staff.
The pace of change within modern business organisations requires the
development and modification to information systems to be rapid.

V2.0 1-21
We will discuss life cycle models in greater depth in another chapter, but a
simple explanation is helpful at this stage. A systems development life
cycle divides a development project into phases, and shows how each of
these phases relates to the others. Each of these phases may require
different skills, so the development life cycle can also show us where
programmers or systems analysts (or people with other skills) will be
needed. Lastly, a development life cycle provides a convenient template
for a project plan, something that is of value to the project manager.
Early development life cycles were strictly linear, as in Figure 1.3. One
stage follows another, with the output of one becoming the input of the
next.

This type of model makes a number of assumptions, which are unlikely to
be realistic in a modern environment. We will develop some much more
appropriate life cycles in the chapter devoted to system development life
cycles.
You may think that the idea of a life cycle is strictly an IT concept. In
fact it is useful in many other areas also. Think of two other complex
products where a life cycle model from concept through to
decommissioning would be useful. Define the major stages in the life
cycles that you have selected.

Figure 1. 3 Linear Life Cycle Model
Do this
with
Skill A
Then this
with
Skill B
Then this
with
Skill C
Then this
with
Skill D
Pass all results to the next phase
S
t
a
r
t
F
i
n
i
s
h

9.1 System Maintenance
One assumption is worth challenging immediately because it helps us to
understand the roles of the system development team and the user
community more clearly. Some linear life cycle models assume that the
final output is the developed system ready to implement. It says nothing
about what will happen after that point. In practice, the largest part of the
complete life cycle of a system is after the system has been implemented.
This is usually called the maintenance phase. Figure 1.4 summarises
this.
The figure actually compresses the maintenance phase considerably. We
would typically expect that an internally developed system would have a
useful life of at least three years or at least six times the length of time
taken to develop it. It is hard to achieve pay back of the investment
required unless this is possible.
During the maintenance period, resources are needed to keep the system
usable. We can categorise this maintenance work as:
Corrective - putting right any errors that remain in the system.
Errors always exist in any large-scale software system. Most of these
are usually encountered soon after implementation, which is the
reason why the cost curve shown in Figure 1.4 does not descend
vertically after implementation.
Perfective - improving the system so that it better meets the needs
of the business. A typical example is a modification that makes the
system respond more quickly, increasing the performance of a key
part.
Adaptive - changes that are needed because the organisation or
perhaps legislation has changed. This is inevitable in a real business
system, because no business is static; it must always respond to the
needs of the marketplace.

Figure 1. 4 Systems Maintenance
Develop
Maintain
Phase
out
R
e
s
o
u
r
c
e
s
Time

V2.0 1-23
Eventually, the accumulated effect of these maintenance activities often
makes the system progressively more difficult to maintain, and the level of
errors starts to rise. Eventually, a point is reached where the cost of
maintaining the system exceeds the cost of replacing it, if the costs are
spread over a number of years. At this point the system is phased out and
replaced. This is the reason for the rise in resources towards the end of
the life cycle, shown in Figure 1.4.
The need for maintenance has a profound effect on the structure of most
IS departments. In some businesses, the resources devoted to
maintenance exceed by a large margin the resources devoted to all other
activities. This is a serious problem because under these conditions, it is
very difficult for the IS Department to respond to new requirements or to
replace the systems that are causing the high maintenance demands.
Most maintenance work is not substantial enough to need a full project
team. Typically, errors (corrective maintenance) are fixed by a single
programmer, and more far reaching changes (perceptive and adaptive)
may require some systems analysis input. A major problem exists here.
All corrections or modifications need to be correctly documented;
otherwise any new programmer will not have access to the correct
documentation and may well make a simple change to some code which
causes major failures.
9.2 Velotec System Maintenance
Now let us see how Velotec manages maintenance. You will have seen
from the chart (figure 1.2), that there is no separate maintenance function
within the IS department. All maintenance work is undertaken by full-time
programmers and possibly contractors. Corrective maintenance is
prioritised based on the seriousness of the problem. If the error prevents
a critical business function from operating, then fixing it will be given the
highest priority, immediately taking resources away from all other tasks. If
less significant corrective maintenance is required, perceptive or adaptive
maintenance, these tasks are given a low priority and undertaken only
when other work permits. A schedule of work (project plan) is produced
and updated as project priorities are agreed.
9.3 Minimising Maintenance
Given the significance of the maintenance load in most IS departments,
any measure that can reduce it is worth adopting. The key to this is the
quality of the developed system. A maintainable system should;
have a well defined development methodology;
be fully documented;
conform to good programming standards;

have been tested effectively using an agreed test plan.
We will describe all of these in detail in later chapters, but standards and
documentation are both key issues and therefore need to be introduced in
this chapter.
Standards are important because they help to ensure that errors are
avoided, both in the development process and in the later maintenance
phase. Standards define how a programmer should construct code so that
other programmers can understand it and so that it is easy to make
changes without creating other errors at the same time.
Documentation is required for all the stages of the development phase.
We saw earlier how communication between the systems analyst and the
business manager is critically important. This communication is
dependent on good documentation. Programmers need to document
their programs. This is so that they and especially another programmer,
can quickly understand program code and locate errors or make other
changes. Unfortunately, this is rarely done as well as it should be.
There is an old saying amongst maintenance programmers never
trust the system documentation. Why do you think this is so?
If you have no programming experience, put yourself in the position of
a programmer under pressure to finish a project and try to visualise
what might happen.
9.4 Velotec Documentation and Standards
Velotec uses a systems analysis approach that specifies how the
requirement specification should be produced. This gives a good base for
programmers to work from, and for subsequent maintenance. The
programming team has programming and documentation standards and
this is included in the inspection which is part of the development process.
We will explore these Velotec standards in later chapters.
10 Summary
The development of large business systems is always a collaborative
effort. We need a combination of skills and experience that no one
individual could possess and we need a sufficiently large resource to be
able to complete a project in a reasonable period. These two factors
(breadth of experience and level of resource) inevitably mean that an
organisation structure is required.

V2.0 1-25
We have reviewed the main skills and functions which typically form part
of this project development organisation structure. We have emphasised
that successful projects are those which are owned by the business
function that commissions the project. The need for collaboration between
the IS specialists and users is a key requirement for success.
We have placed particular emphasis on understanding that the
development process is not necessarily the most costly part of the life
cycle of a system. We must develop systems so that costs in the
maintenance phase are controlled and minimised.
11 Self Study
11.1 Exercise
This exercise should take approximately 3 hours to complete.
Obtain company reports for some medium and large sized businesses
in your area. The reports you need are the glossy publications
containing the results and descriptions of achievements over the last
year. These usually contain a list of directors and their functions. You
may find these on the company web sites.
Look for any IS representation at board level.
Also look for any significant IT or eCommerce activities.
Try to decide if there is a connection between the organisational
structure and the responsiveness to IT opportunities.
Do you think that you could make recommendations on buying/selling
shares based on this analysis?
11.2 Townsfield Case Study
The use of a fictitious business organisation within the workbook, as
explained in the introduction, is to help students understand many of the
topics within this module. The difficulty for any lecturer is finding a case
study which students can recognise and relate to their own experience
and therefore more easily understand. The case study is based on
consultancy work undertaken by the author of the workbook, who was
called into the company after they had a poor experience of using a large
management consultancy organisation.
This additional case study should be used within your self-study time to
consider any additional points which arise by applying the Townsfield
experience to the exercises in the workbook. You will find it helpful to set

up discussion groups with other students to share ideas. As you consider
and discuss the issues you will note there are some common features and
some differences between Velotec and this case study.
Townsfield Soft Drinks is relatively small in the market for producing non-
alcoholic drinks. For each product they manufacture, they have to order
and take delivery of raw materials and also pay for water used in the
drinks and in the processing and cleaning of some raw materials.
They deliver their own products and other bought in products to
wholesale customers, retail customers (social and sports clubs) and sales
outlets which the company own. They need to ensure they keep
customers supplied and often orders are based on external factors, some
of which may be uncontrolled.
The organisation has an annual turnover of 130M UK pounds and
employs some 600 full-time staff and around 3500 part-time staff who
work in various sales outlets. Of these sales outlets the business
organisation owns 500, but manages only 200 directly, as the other 300
are rented out to managers.
They also supply some 1300 wholesale outlets and other individual
supermarkets all of which could, if Townsfield were not economical,
purchase their requirements from Townsfields competitors.
The Townsfield organisation has used IT for some years and continues to
seek new applications to provide it with an advantage over its larger
competitors.
Their directly managed 200 outlets all use EPOS terminals, which are
linked to the head office computer system, however data is only uploaded
after close of business each day.

Study Note:
If you do not know what EPOS means, then it is a useful exercise in
basic research, to find out.
The data collected via the terminal includes the number of units sold for
each product, and the money taken.
This data is analysed to identify:
stock sold, and which therefore needs replacing;
performance of each outlet against expected sales;
trends in sales of products;
income, against predictions and business efficiency.

V2.0 1-27
Reports are produced for all directors on a daily basis, which enables
them to quickly identify any potential problems within their division
(functional area).
Townsfield Exercise 1: 30 minutes
Bearing in mind the type of business, would it be useful to collect the
date and time of each sale? Could this extra data be used to provide
useful information to local and senior management? Is there any
advantage to be gained by transmitting the data directly to HQ as it is
collected at the terminal?
Typically, in its earlier use of IT, the brewery used a small mainframe
computer to carry out the normal administration functions, including
payroll, order processing, invoices etc. This was all carried out at Head
Office with no direct data input from the sales outlets. Weekly reports
were printed and delivered to each manager.
A total business review was initiated ten years ago and the outcome was
a reorganisation in order to focus the business on its core functional
areas. A board of directors normally runs business organisations. In
smaller business organisations members of the board usually have
management responsibility for one or more functional areas (departments
or units) within the business.
Following reorganisation, a main board director was appointed to run
each functional area (e.g. production, purchasing, finance, retail,
wholesale, HR).
The company objective was placed firmly on PROFIT and an analysis
took place to identify where the profit came from, identified by customer
and by product.
In order to meet the business need, four key databases were identified
and set up.
Financial; to contain all the financial information required by the
business and to meet government regulations.
Retail; to contain details of all retail customers, including order history.
Wholesale; to contain all the details of wholesale customers and their
order history.
Employees; to contain all details of current and previous staff, both full
and part-time.
Having reorganised the business, the board then looked at how IT could
support their new focus and the implementation plans. They realised they
needed to link IT with their business strategy. However they felt they did
not have the expertise within the company and a firm of IT management
consultants was appointed. Unfortunately the directors did not understand
the consultants report, as it was too technical and too full of jargon.

Study Note:
An important lesson: when you are producing a report make sure you
write it for the reader and not for yourself. Use language the reader will
understand, explain any jargon (technical words) to be used.
The board did however take the advice of a new consultant, which was
TO PLACE CONTROL OF IT with USERS and not with IT staff and to
appreciate it was an IS, not an IT issue.
It is important to realise that the purpose of IT in an organisation is to
support the staff of the organisation and in order for the organisation to
derive maximum benefit, they, not the IT staff, need control.
On the basis of the consultants advice, and mindful of the high costs
which were associated with IT, the board decided to control all IS projects
at board level.
Accordingly, if the IT department decided there was a requirement for
some additional or updated hardware, or new or modified software, then
they had to obtain the approval of the potential users. Normally this would
be the head of the relevant department.
Thus all projects needed to be sponsored by a user department, to have a
project steering committee and to be developed via a project team which
had to include user representatives.
Projects requiring use of IT solutions to resolve IS issues included:
new applications to meet changing business requirements;
problems faced by a business unit;
administration problems;
obtaining internal and/or external data to provide business
information.
All projects are then submitted to the COMPANY STEERING
COMMITTEE. (CSC). The CSC consists of the six main board directors
which includes the IS director, who in this business was the FINANCE
director.
The CSC always considers each proposed project from a business
perspective and not simply those justified by financial savings; they
consider such issues as:
What advantage will be gained by the business?
What will the business lose if it does not implement the proposed
project?
What information do we need this project to provide?

V2.0 1-29
Will it be cost effective?
The CSC then identifies the most favourable projects to be taken forward
during the next 12 months and which are achievable within the existing IT
resource base.
The CSC meets every two months to review progress and to consider any
new projects that have been identified. A new project may well receive a
higher priority than one that was previously approved.
In all business organisations, changes can occur in the way the business
needs to operate which could require modifications to any part of an
existing information system. The CSC also controls such changes.
Anyone in the organisation can request a modification to an existing
system. The IT department is authorised to spend one half-day to review
the request, and with the user, to identify the benefit to the business, and
then to produce an estimate for implementing the required resource. Any
board director can sign the request and authorise the IT department to
proceed with the modification. Some 30% of requests are not approved.
In groups, students should discuss the internal and external changes
which are likely to affect a business. Students should select a business
they use themselves and hence know about.
As mentioned previously, the progress of all projects is reviewed at each
meeting of the CSC, and the reasons for delay in any which are not on
schedule, are discussed in detail. There may have been too many
modification requests approved which have caused a delay in one or
more projects. This leads to the directors of the business organisation (the
members of the CSC) demanding any director who has signed a change
request to justify his/her action. Clearly with this level of control, only
those changes which are vital to the business should have been
approved. No projects motivated by self-interest should be approved.
Townsfield also buys in some data that they incorporate into their
information system in order to analyse their business and predict future
trends. For example:
Demographics; population changes due to births, deaths, plans for
new house building, developments in workplaces, (expansion or
reduction).
Weather, history and predictions.
Major sporting and other large events.
These all have an effect on sales of the products sold by Townsfield.
Often new business decisions have major effects on existing IT systems.
For example, the directors decided that in order to improve their business,
they needed to improve their stock control and respond more quickly to

customers requirements for delivery. Often customers would increase
their normal orders when the weather forecast predicted a week of sun
and no rain. This usually means greater sales of drink products and
therefore customers are likely to require more deliveries.
Setting up a new warehouse to enable these changes meant that a new
stock control and ordering system were required. In-house IT staff were
unable to complete a new system in the time required and so an off-the-
shelf product was purchased and the modifications required to meet
Townsfield specific business needs were developed by software
consultants.
In groups, students should discuss how vital the use of IT is to this
business, and if it could manage without IT, what the impact would be.
Could Townsfield use IT in other areas?
12 Answers
The answers given below are an indication of some of the points which
may be considered. There will be other valid points and indeed some
points will depend entirely on the type of business, its size and maturity in
the use and development of IS.
Discussion points
1. There is no correct answer, the purpose of the discussion is to raise
the groups awareness of the impact computers have on our daily
lives. On the basis of the above, you can then determine how your life
would change if all computers failed to work for one week.
Most shops which use computerised checkout machines would shut,
banks would have to close, no-one could withdraw money from their
account. Traffic lights and cell phones would cease to work, aircraft
could not land or in some cases, fly safely. Hospital life support
machines would stop and patients would die.
2. Identifying the good and bad uses of the Internet will enable your
group to appreciate that inventions of man are not always used for
peaceful or ethical purposes. Some people use technology to commit
crime and to create unsuitable content for websites. You will be aware
of hacking, but that is a very mild form of bad use compared to some
illegal uses of the Internet. You may wish to debate how this can be
stopped or controlled.
You should also consider what computers might be used for in your
lifetime, for as a computing student, you will be part of this
development.

V2.0 1-31
3. The purpose of asking groups of students to identify a typical
Information System is to ensure they can understand an IS. Does the
selected IS satisfy all the components in the definition? Does it
collect, store, process data and provide a variety of information to
managers, customers?

Exercises
Answer 1.1
This is a typical reporting line for this size of business.
The advantages that this reporting line offers are:
Keeping the board to a reasonable size. Other service functions could
also argue for board level recognition. A board of eight to nine members
is already large for effective decision-making. Reporting through the
Finance Director (FD) should make it easier for the IS Manager to obtain
authorisation for expenditure, since the FD will have to account for and
justify any expenditure to the board.
The disadvantages of this reporting line are:
The IS department is seen as just another service department. This
makes it difficult for the IS Manager to act proactively and champion
strategic business issues. With this reporting line, it is likely that
information is not valued as a corporate resource. This makes is more
difficult for the IS department to manage Information Systems effectively.
This lack of understanding of the value of company data is often reflected
in poor levels of data and information security.

Answer 1.2
There are more than two possible answers to the first part of this
question.
Velotec could outsource this part of its operations. Outsourcing means
that another organisation assumes the responsibility for providing this
service on behalf of Velotec. The outsourcing company may use the
existing Velotec resources (equipment and people) or replace these with
their own. Velotec would pay a recurring fee for this service.
Velotec could pay an Internet Service Provider for website services so
that it would no longer need to maintain its own servers. This would result
in great savings.
Velotec could move to an Application Service Provider (ASP), an
organisation which rents applications to customers. This would be of
limited value for the website area, but potentially very useful for other
Velotec applications.

These are all options that would appeal to an organisation that has taken
a radical view of its IT provisions, and where all (or nearly all) of its
applications are standard. This is not true for Velotec however.

Answer 1.3
The main problem that can be avoided by this view is the alienation of the
business managers. Alienation means to become distant or unfriendly. A
business manager who sees the IS Manager as the manager of a
department that owns all business data and information, and therefore all
computerised business systems, could quite reasonably feel that the IS
Manager is interfering in his sphere of responsibility. The business
manager is unlikely to accept any responsibility for the systems that
he/she is required to use.

Answer 1.4
Some possible arguments include:
Velotec is not making best use of information. This is because there is
no IS specialist on the board. There is no-one with up-to-date and
expert knowledge of the rapid developments occurring in the
technology and its use in business.
Some of the difficulties of co-ordinating systems requirement between
functional areas would be made easier if there was board level
representation. The IS view would no longer be seen as a Finance
Department view.
Velotec desperately needs a more modern IS/IT strategy, which
needs to be driven from board level. An IS Director is the obvious
focus for such a strategy review.
Velotec is moving into the eCommerce era and this will change the
retail and wholesale areas beyond recognition. For example, it might
be considered desirable for customers to order and book
appointments via the web. The company will miss opportunities
unless there is board level IS recognition.

Answer 1.5
Several arguments are possible:
There would be a duplication of resources. Some of the IS functions
use specialists. If each department were to have a full complement of
these specialists they would be an under-used (and expensive)
resource, representing a significant additional cost.
The IS department tries to ensure coherence of IS provision for the
whole business. If each department has its own IS team, that
coherence would be lost.

V2.0 1-33
There are some IT resources that are shared by everyone. Examples
are the network infrastructure and the UNIX and NT servers. These
should obviously continue to be managed as a central resource. Each
department does not have its own finance team or HR team so why
have its own IS team?
The organisational structure of Velotec is quite likely to change. IS
provision should be independent of such changes.
Information is a shared resource and needs to be managed as such,
in the same way as the company finances.

Answer 1.6
Two other areas are Human Resources and Finance. It is most unlikely
that the business views these in the same way, largely because they have
had this role for many generations and they have become a central part of
the structure of nearly every business. IS has not had this history, and
there is still little awareness of the importance of information to the
business.

Answer 1.7
There is an enormous range of possible answers to this question. The
two described here may help you to think of your own answers, perhaps
using your hobby.
Example 1
A house may start with an outline requirement defined by the potential
owners. An architect would take that requirement and produce a set of
conceptual designs for approval. When these are accepted, a detailed
design would be produced and a builder hired to carry out the
construction. The construction phase may last several months. The next
phase is the occupation and maintenance phase, during which work may
be needed in order to correct any problems resulting from the design and
construction (corrective maintenance), and to ensure that the structure
remains intact. Occasionally more radical changes will occur, such as the
addition of an extension (adaptive maintenance). The end of the house
life cycle occurs after many years when it no longer can fulfil its role as a
house, perhaps because the land is needed for something else. The end
of the life cycle is marked by a short demolition phase.
Example 2
Cooking a meal has a rather shorter life cycle. It starts with a planning
phase during which the necessary ingredients are determined. This is
followed by an acquisition stage during which the ingredients are gathered
together from various sources. This is followed by the preparation phase
in which some of the ingredients are given special treatment (cleaning,
cutting, grinding). The next phase is a hybrid activity during which certain

processes and mixing activities are undertaken. Next is the cooking
phase, in which the ingredients are cooked in the correct order. This
process may have many parts depending on the complexity of the desired
product. The final part of the life cycle is consumption.

Answer 1.8
Documentation is often the last task undertaken by a programmer on a
project. It is often (usually) done badly because:
Projects almost always run out of time, thus programmers are forced
onto the next project.
Programmers often have difficulty producing written communication in
a form which non-specialists can understand.
As programmers can understand the code they have just written, they
fail to see the necessity of explaining it to someone else.
It is not kept up-to-date.
It is unfortunate that even the best programmers often have difficulty
understanding their own code after only a few weeks away from a project.
The documentation is often not very good at the outset, and as the
system is maintained, the documentation often is not.
Townsfield Exercise 1:
Bearing in mind the type of business, would it be useful to collect the date
and time of each sale? Could this extra data be used to provide useful
information to local and senior management? Is there any advantage to
be gained by transmitting the data directly to HQ as it is collected at the
EPOS terminal?
Some useful information would include:
Collecting this data would enable an analysis to identify busy and slack
periods in order to facilitate more accurate scheduling of staff, and assist
in establishing the loss of income if the opening times of the outlet were
changed. (Identify operating costs per hour against income per hour).
Transmitting the data directly it is collected would provide an instant
analysis and ensure data is not lost if for any reason the terminal fails, is
damaged or destroyed in a fire. However, there would be a cost
associated with having communication lines permanently connected
between HQ and each of the 200 outlets.
In groups, students should discuss the internal and external changes
which are likely to affect a business. Students should select a business
they use and know about.

V2.0 1-35
Your lecturer could facilitate the discussion and add his/her own ideas,
many of which will depend on the type of business selected, but may
include; new chief executive with different ideas for the companys future,
takeover by a rival company, price changes and delivery issues with raw
materials, effect of competitors entering or leaving the market,
government tax or other business legislation changes, population change,
staff changes, loss of particular expertise.
In groups, students should discuss whether the use of IT is vital to this
business, and if the business could manage without IT, briefly explain
what the effects would be.
Could Townsfield use IT in other areas?
The main purpose of this exercise is to establish how well students
understand the use of IT within a business and appreciate that having
implemented IT systems it is, for most business organisations, impossible
to return to manual systems.
Clearly, having implemented a system linking outlets to HQ and with a
computerised stock control, it would be impossible to manage the
business without IT.
As Townsfield have their own outlets linked to the head office system for
stock replenishment, they could have all customers linked directly to the
head office system. Are there delivery vans linked to a GPS (Global
Satellite System) so that they can be tracked and diverted by HQ if
necessary? Do the delivery vans carry web-enabled portable devices so
that all deliveries they make can be instantly uploaded to the HQ system?


V2.0 2-1
Chapter 2
Mathematics for Computing
1 Indicative content .........................................................................................2-2
2 Introduction ..................................................................................................2-2
3 Number Systems..........................................................................................2-2
3.1 Decimal ..............................................................................................2-4
3.2 Binary .................................................................................................2-5
3.3 Octal ...................................................................................................2-6
3.4 Hexadecimal ......................................................................................2-6
4 Introduction to Number Base Conversions................................................2-10
4.1 Decimal to Binary.............................................................................2-10
4.2 Decimal to Octal...............................................................................2-11
4.3 Decimal to Hexadecimal ..................................................................2-11
4.4 Decimal Conversions.......................................................................2-14
5 Non-Decimal Conversions .........................................................................2-14
5.1 Binary to Octal..................................................................................2-14
5.2 Octal to Binary..................................................................................2-15
5.3 Binary to Hexadecimal .....................................................................2-15
5.4 Hexadecimal to Binary.....................................................................2-16
6 Arithmetic Calculations ..............................................................................2-17
6.1 Basic Arithmetic Functions...............................................................2-18
6.2 Sum and Difference of Hexadecimal Numbers ...............................2-19
7 Data Structures ..........................................................................................2-21
7.1 Arrays...............................................................................................2-22
7.2 Stacks...............................................................................................2-24
7.3 Queues.............................................................................................2-26
8 Check Digits...............................................................................................2-27
9 Statistics.....................................................................................................2-29
9.1 Averages..........................................................................................2-29
9.2 The Mean.........................................................................................2-30
9.3 The Median ......................................................................................2-31
9.4 The Mode.........................................................................................2-32
9.5 Frequency Distributions ...................................................................2-34
9.6 Cumulative Frequency Distribution..................................................2-34
9.7 Relative Frequency Histograms.......................................................2-36
10 Measures of Spread or Dispersion ............................................................2-37
10.1 The Range .......................................................................................2-38
10.2 Standard Deviation ..........................................................................2-39
11 Elementary Probability...............................................................................2-41
11.1 Relationship - Relative Frequency and Probability..........................2-43
12 Summary....................................................................................................2-45
13 Answers .....................................................................................................2-46
Chapter 2 Mathematics for Computing Systems Development


Characteristics of different number systems, benefits and drawbacks.
Convert and operations on binary, octal and hexadecimal whole
numbers.
Basic arithmetic operations on integers and real numbers, including
base conversion of real numbers.
Numerical and logical data types and data structures.
Check digits.
Represent data diagrammatically.
Cumulative frequency curves for absolute and relative frequencies.
Statistics; range, mean, mode, median, variance and standard
deviation.
Elementary probability, modelling and evaluation of practical
situations.
2 Introduction
Systems analysts, programmers and project managers need to be
numerate. In order to be effective in their role they often need to be able
to apply a range of simple mathematical techniques to solve problems.
Even though you may have covered these topics at school, the purpose of
this chapter is to ensure that you have the required level of mathematical
knowledge.
We will cover a range of different topics, exploring each one to just
sufficient depth to be useful, but no further. If you feel that you are
already familiar with a topic, skim through the text but carry out the
exercise at the end of each section. If you have no problem with the
exercise you should continue with the rest of the chapter. If the exercise
proves difficult, go back and read the section more carefully.
3 Number Systems
Counting things is fundamental to our lives. Everywhere in the world
people are used to counting and to representing numbers in what is called
the decimal (base of ten) number system. This system is based upon our
own physical characteristic of having ten fingers and the fact that fingers
are a natural (and highly portable) aid for counting.
The early designers of computers found that reliable operation could only
be obtained by using switches of various kinds. A switch can be either on
Systems Development Chapter 2 Mathematics for Computing

V2.0 2-3
or off and there is no ambiguity about its state. If we regard off as 0 and
on as 1, we have only two fingers to count with. This might seem to be a
serious problem, but in fact a binary (based on two) number system is
perfectly usable, even if it is not natural for humans. In order to make the
explanation of number systems easier, we will use whole numbers, which
are called integers.

Binary
A two bit binary number is for example:
00 which is zero, 01 which is one, 10 which is two and 11 which is three.
You will realise that three is the highest we can have with a two bit binary
number. Thus our range using two bits is 0 - 3.
Normally, binary numbers tend to be very long. For example, the decimal
number 3571 is 110111110011 in binary. There are two other number
systems used with computers which are related to the binary system, but
are more economical with the length of numbers.
Octal
Octal is based on the numbers 0,1,2,3,4,5,6,7. This is equivalent to 2
3
.
The decimal number 3571 is 6763 in octal.
Hexadecimal
Hexadecimal is based on the numbers 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F.
Hexadecimal implies 16, so we run out of ordinary numbers after 9 and
have to use other symbols. A-F were selected many years ago as the
most convenient for our purposes. The decimal number 3571 is DF3 in
hexadecimal.
Each number system has what is called a base, which indicates the
number of different symbols used in that system. In the case of the
decimal system, this base is 10 since there are ten different symbols used
to show quantities in that system (0,1,2, etc, up to 9).

Definition
Integer a whole number, 1, 5 etc, as opposed to a real number, 1.2,
4.75 etc

The chart below summarises this.
Number system Decimal Binary Octal Hexadecimal
Base 10 2 8 16
Digits available
0 0 0 0
1 1 1 1
2 2 2
3 3 3
4 4 4
5 5 5
6 6 6
7 7 7
8 8
9 9
A
B
C
D
E
F

3.1 Decimal
If we consider the number 258 in the decimal system, the 8 represents the
number of units, and since the digit 5 occupies a position one place to the
left of the units column, it represents the number of tens.
With 10 as the base of the decimal system, each position further to the left
represents a value ten times greater at each move left; hence the 2
represents the number of ten times ten or hundreds; thus 258 has a
value given by 2 hundreds plus 5 tens plus 8 units. Another way of
thinking about this is as powers of 10, so hundreds are 10 to the power 2,
tens are ten to the power 1 and units are ten to the power 0. If you are
unfamiliar with this notation, just remember that any number raised to the
power 0 is always equal to 1. Any number raised to the power 1 is just
that number, so 86234
1
is simply 86234.

The chart below illustrates this
idea.
Hundreds Tens Units
10
2
10
1
10
0

2 5 8

It follows that the value of the position (place value) occupied by a number
in the decimal system is (moving from the right to the left of a whole
number) units, tens, hundreds, thousands, tens of thousands and so on.

V2.0 2-5
Place value depends upon the base used, so the second position from the
right represents tens only because ten is the base; and the third position
from the right represents hundreds only because the base times the
base is a hundred.
3.2 Binary
The base of the binary system is 2, so starting from the right, the units
column (the least significant position) and working to the left, each place
value will be two times greater than its predecessor. Thus the positional
values are 1, 2, 4, 8, 16, 32, 64, etc, increasing far more slowly than with
decimal values which reach the order of millions when the seventh
position is reached. See the chart below, which shows the meaning of the
binary value 110101 (decimal 53).
Powers of 2 2
5
2
4
2
3
2
2
2
1
2
0

Positional value 32 16 8 4 2 1
Binary value 1 1 0 1 0 1

So by multiplying positional values by the binary values, from right to left,
and adding them up:
1 x 32 = 32
1 x 16 = 16
0 x 8 = 0
1 x 4 = 4
0 x 2 = 0
1 x 1 = 1
Adding up we get 53, and thus if the number 53 was stored in a numeric
form internally in a computer, it would be stored as 110101. Both are
alternative forms of representing the same quantity, one being in a
manner suited to humans and the other in a form required by a computer.
Using the same approach, convert the binary value of 101010 to
decimal. Try some more of your own until you feel totally confident.

3.3 Octal
The octal number system uses 8 as its base and so the place values
move left from the least significant position 1, 8, 64, 512, 4096, etc.
These values increase far more rapidly than the binary system. The
example below shows that the value of the octal quantity 3056 is decimal
1582 and, again, these two are simply alternative forms of representing
the same quantity.
Example:
So an octal value of 3056 would be represented as shown in the table.
Powers of 8 8
4
8
3
8
2
8
1
8
0

Positional value 409
6
512 64 8 1
Octal 3 0 5 6

Multiplying values and adding them up:
3 x 512 = 1536
0 x 64 = 0
5 x 8 = 40
6 x 1 = 6
Total 1582
Using the same approach, convert the octal value of 47023 to decimal.
3.4 Hexadecimal
In principle, there is really no difference in the technique necessary for
dealing with hexadecimal numbers, but the use of the digits A to F as well
as the more common 0 to 9, makes them look more complicated. In the
example below, the hexadecimal quantity 2 FA6 is converted to decimal,
yielding a value of 12198.
Example:
Powers of 16 16
3
16
2
16
1
16
0

Positional value 4096 25
6
16 1
Hex value 2 F A 6


V2.0 2-7
2 x 4096 = 8192
F (15) x 256 = 3840
A (10) x 16 = 160
6 x 1 = 6
Total 12198
Using the same approach, convert the hexadecimal value of ABC to
decimal.
It should now be clear that unless the context makes it absolutely certain
which number base is being used, the base should be stated when
referring to the value of a quantity.
So far we have dealt with integers, but what do we do when we want to
work with a value that is not a whole number? Mathematicians refer to
numbers that can vary smoothly and are expressed as decimals (i.e. they
can have a value to the right of the decimal point), as real numbers.
In the case of decimal numbers, place values after the decimal point refer
to units of 0.1, then 0.01, 0.001, etc moving to the right of the decimal
point, and decreasing by a factor equal to the base of the number system
with each step. We can more also represent 0.1 and 0.01 by negative
powers of 10, so 10
-1
is 0.1.
See the table below for an example of 36.528.
Powers of 10 10
3
10
2
10
1
10
0
. 10
-1
10
-2
10
-3

Positional value 100
0
100 10 1 0.1 0.01 0.00
1
3 6 5 2 8

3 x 10 = 30
6 x 1 = 6
5 x 0.1 = 0.5
2 x 0.01 = 0.02
8 x 0.001 = 0.008
Total 36.528

In the same manner, the binary fraction place values decrease by a factor
of two with each step to the right of the decimal point and are 0.5, 0.25,
0.125, etc. See the table below:


Powers of 2 2
3
2
2
2
1
2
0
. 2
-1
2
-2
2
-3

Positional value 8 4 2 1 0.5 0.25 0.12
5
1 0 1 0 1 1

1 x 4 = 4
0 x 2 = 0
1 x 1 = 1
0 x 0.5 = 0
1 x 0.25 = 0.25
1 x 0.125 = 0.125
Total = 5.375

With fractions in octal, place values go down by a factor of eight, giving
0.125, 0.015625, etc, so the octal quantity 31.27 has a value given by
3 x 8 plus 1 x 1 plus 2 x 0.125 plus 7 x 0.015625 which is 25.359375 in
decimal.
Finally, hexadecimal fractions involve place values decreasing by a factor
of 16, yielding 0.0625, 0.00390625, etc, so hexadecimal 0.CF has a value
of 12 (C) x 0.0625 plus 15 (F) x 0.00390625, which is 0.75 + 0.05859375
or 0.80859375 decimal.
The preceding sections have established the positional values
associated with the most commonly used number bases in computing
and, in so doing, have laid down the methods for converting from these
bases into decimal values. The following set of exercises provides the
opportunity to use these methods, to make sure you understand the
principles.
i) Convert each of the following binary quantities into decimal:
110
1001
11101
1101
10011
110010

V2.0 2-9
11010
1110011
11001101
10010110
ii) Convert each of the following octal quantities to decimal:
17
25
43
156
204
362
407
713
1536
2715
iii) Convert each of the following hexadecimal quantities into
decimal:
14
23
1B
3C
7D
A2
AB3
B05
FAD
F23E


iv) Convert each of the following to decimal
1.01 binary
110.101 binary
0.0011 binary
2.23 octal
5.07 octal
10.35 octal
3.B hexadecimal
19.25 hexadecimal

4 Introduction to Number Base Conversions
So far we have concentrated on conversions from binary, octal and
hexadecimal into decimal. Those conversions are quite simple, but we
also need to convert from any number base into any other number base,
so we need a general approach to conversions. In this section we will look
at the techniques that you can use to carry out these conversions.
4.1 Decimal to Binary
In the conversion from decimal to any other number base, the secret is
simply to divide the base into the decimal number, note the remainder,
then divide the base into the quotient and keep repeating this process
until there is a zero quotient, which must always occur sooner or later.
Reading off the remainders in the reverse order of them being written
down will always produce the required answer.
Let us look at how this works with the decimal 117 being converted into
binary in a step-by-step procedure.
1. Since the base of binary numbers is 2, we divide 117 by 2 to get 58
and a remainder of 1.
2. Write down the remainder.
3. Repeat stages 1 and 2 until the result is zero.
4. The required binary number is the remainder, reading from the last
remainder to the first.
This procedure looks suspiciously as if you could write a program to
automate it. If this is what you thought, you are correct. A procedure like

V2.0 2-11
this, clearly defined and with a definite ending, is sometimes called an
algorithm. Computer programs implement algorithms.
Looking at this in a chart:
Quotient Divide by Result Remainder
117 2 58 1
58 2 29 0
29 2 14 1
14 2 7 0
7 2 3 1
3 2 1 1
1 2 0 1

Reading the remainder column from the bottom upwards, we see that
117 Decimal =1110101 Binary.
4.2 Decimal to Octal
Let us try the same thing with decimal to octal. We will convert 236
decimal to octal. The procedure is exactly the same, but of course we
divide by 8.
236 8 29 4
29 8 3 5
3 8 0 3
The result is 354, reading the remainder column bottom upwards.
Note that the process can only produce remainders of 0 to 7 inclusive, so
the digits 8 and 9 will never appear in the octal quantity. This is obviously
what you would expect.
4.3 Decimal to Hexadecimal
Hexadecimal is just as easy, but do not forget that you need to write the
remainders in hexadecimal numbers (remember 0 to F), so for example,
if you get a remainder of 11, just write it as B.


This example converts decimal 473 to hexadecimal:
473 16 29 9
29 16 1 D
1 16 0 1

The result is 1D9, reading the remainder column bottom upwards.
Now try these conversions yourself.
i) Convert each of the following decimal values into binary:
1.13
2. 25
3. 29
4. 64
5. 73
6. 127
7. 103
8. 175
9. 236
10.199
11. 274
12. 493
ii) Convert each of the following decimal values into octal:
1. 9
2. 17
3. 23
4. 39

V2.0 2-13
5. 47
6. 83
7. 96
8. 100
9. 127
10. 301
11. 532
12. 798
iii) Convert each of the following decimal values into hexadecimal:
1. 23
2. 29
3. 35
4. 42
5. 59
6. 79
7. 140
8. 140
9. 254
10. 260
11. 509
12. 537
13. 1295
14. 1998
15. 12047


4.4 Decimal Conversions
Earlier, we described the positional values associated with binary, octal
and hexadecimal fractions and we did some conversions from these into
decimal fractions. An exact conversion was possible in every case.
However, experience shows that it is not always possible to represent
some fractions exactly as decimal fractions. For example, is exactly
0.25 but
1
/
3
is 0.3333 recurring and so has no exact decimal fraction
equivalent.
Exactly the same thing happens when we work with a different number
base. There are some fractions that cannot be exactly represented in
binary fractions. More interesting is the fact that fractions that cannot be
represented exactly in one number base may be exactly represented in a
different number base.
A simple example is
1
/
10
, which is exactly 0.1 in decimal terms but can
only occur as a recurring binary fraction. This is a major factor in errors
produced by a computer when calculating with fractional values, in that it
can only represent some of these in an approximate manner, leading to
small, but accumulating errors when doing calculations with them. Some
decimal fractions can be converted exactly and, where this is not possible,
the accuracy to which the conversions are calculated can be controlled.
5 Non-Decimal Conversions
Up to this point we have concentrated on conversions between decimal
and another base. How do we convert between two non-decimal bases
such as binary and octal? In principle, we could use the same approach
that we have already presented, but there are some short cuts that we
can take if we are only concerned with conversions from and to binary,
octal and hexadecimal. This is actually not a major limitation when we are
dealing with computer systems and computer programming.
5.1 Binary to Octal
Start off with a table of the first 8 binary numbers and their octal
equivalents.
Binary 00
0
00
1
01
0
01
1
10
0
10
1
11
0
11
1
Octal 0 1 2 3 4 5 6 7

Now we can use this table to do rapid conversions from binary to octal.

V2.0 2-15
Split the binary number up into groups of three, working from the right to
the left. Then the octal values are simply read off to replace each group
of three, hence 010 is replaced by 2, 101 by 5, and so on. In cases where
a full group of three does not occur naturally in the leftmost group, add
zeros on the left to make this group up to three digits.
Example 1:
Convert binary 101010110001 to octal:
Split the number up into groups of three:
Binary 101 010 110 001
Now write down the equivalent octal from the table:
Octal 5 2 6 1

Example 2:
Convert binary 1011100101111 to octal:
Binary 001 011 100 101 111
Octal 1 3 4 5 7
Notice that in this case we had to add two zeros to the left hand group.
5.2 Octal to Binary
This conversion can be done easily by reversing the process we have just
described. Each octal digit is replaced by the appropriate triple of binary
digits. Any unnecessary zeros can be removed afterwards.
Example 1:
Octal 2 7 4 3
Binary 010 111 100 011
The left hand zero is not needed, so we are left with 10111100011.
Example 2:
Octal 7 6 3
Binary 111 110 011
5.3 Binary to Hexadecimal
Just as with octal, we can take a short cut by using a simple table.


Binary Hexadecimal Binary Hexadecimal
0000 0 1000 8
0001 1 1001 9
0010 2 1010 A
0011 3 1011 B
0100 4 1100 C
0101 5 1101 D
0110 6 1110 E
0111 7 1111 F

This time we split binary numbers into groups of four digits (2
4
= 16 which
is the hexadecimal base). Just as before, zeros may be added if
necessary.
Binary 0110 1011 1011
Hexadecimal 6 B B
Notice that the leftmost group was padded on the left with an extra zero.
5.4 Hexadecimal to Binary
As you would expect, this reverses the previous process, just as we saw
with octal to binary conversions.
Example 1:
Hexadecimal 9 A C
Binary 1001 1010 1100
Exercise 2.6 1 hour 20 minutes
Now try these conversions.
i) Convert each of the following binary quantities into octal:
101101110
110001100
11011001
101101
110101
ii) Convert each of the following octal quantities into binary:
725

V2.0 2-17
536
234
10653
iii) Convert each of the following binary quantities into hexadecimal:
1. 11010011
2. 100101
3. 10111
4. 101010
iv) Convert each of the following hexadecimal quantities into binary:
1. 2B
2. FC7
3. 8C
4. 3DE2

6 Arithmetic Calculations
The computer can only handle binary numbers, although there are a
variety of different ways in which binary numbers can be used to code
other types of number format. This means that we should be aware of
simple binary arithmetic. There are, in fact, no important differences in
principle, between the ways in which decimal calculations are handled
and those involving binary. We just need to keep in mind the different
number bases.
The fact that computers can only deal with binary data does not mean that
all the binary data that the computer manipulates represent binary
numbers. Binary encodings are used for everything, including program
instructions, character strings, and data, all of which are converted to
binary, so that there is no superficial way of telling which of them is
represented by 01101101. Even if it is known to be an item of numeric
data, it still might be an integer (of several different types), or floating point
(again of several different types).


Hence caution must be exercised so that calculations on data which is
really, for example, representing character strings, are not carried out.
Although it is possible to perform the arithmetic operations, the results will
be of no use.
Different types of computer may use different formats for representing
numbers in binary code. They also use different methods of carrying out
the calculations, particularly for floating point arithmetic. We will consider
only the simplest methods, so bear in mind that although the computer is
carrying out logically the same operation, we will be using methods
suitable for hand calculation.
6.1 Basic Arithmetic Functions
To understand simple binary addition it is useful to remember this simple
table of binary numbers:

Decimal Binary
0 0
1 1
2 10
3 11
4 100
5 101
6 110
7 111

Definition
Real Number the numbers that allow a numerical quantity to be
assigned to every point on an infinite line or continuum. Real numbers
are thus used to measure and calculate exactly the sizes of any
continuous line segments or quantities.
Definition
Floating Point a representation of real numbers that enables both
very small and very large numbers to be conveniently expressed.

V2.0 2-19
6.2 Sum and Difference of Hexadecimal Numbers

Hexadecimal numbers are often used for memory addresses. It is useful
to be able to add and subtract these hexadecimal addresses. Finding the
difference between two such addresses tells us how far apart the memory
locations are. You already know enough to be able to carry out these
operations, by conversion to decimal, then conversion back to
hexadecimal after the arithmetic, but you can also carry out the operations
directly. We will start with finding the sum of two, four-digit hexadecimal
numbers. For this a table is useful:
0 1 2 3 4 5 6 7 8 9 A B C D E F
1 2 3 4 5 6 7 8 9 A B C D E F 0
c1
2 3 4 5 6 7 8 9 A B C D E F 0
c1
1
c1
3 4 5 6 7 8 9 A B C D E F 0
c1
1
c1
2
c1
4 5 6 7 8 9 A B C D E F 0
c1
1
c1
2
c1
3
c1
5 6 7 8 9 A B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
6 7 8 9 A B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
7 8 9 A B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
8 9 A B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
9 A B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
A B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
9
c1
B C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
9
c1
A
c1
C D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
9
c1
A
c1
B
c1
D E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
9
c1
A
c1
B
c1
C
c1
E F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
9
c1
A
c1
B
c1
C
c1
D
c1
F 0
c1
1
c1
2
c1
3
c1
4
c1
5
c1
6
c1
7
c1
8
c1
9
c1
A
c1
B
c1
C
c1
D
c1
E
c1

Notice that the table does not include the addition of 0 to a number,
because that is trivial.
To use this table, find the appropriate row and column for the two
hexadecimal digits being added, then read off the result at the
intersection. The notation c1 means carry one. We can use another table
to illustrate the actual mechanics of the process.

5 2 A C
+ F 1 0 4
result 1 4 3 B 0
carry 1 1


Do not forget to add the carries when required. Use the table if you need
it for this, but adding 1 to a hexadecimal number is easy to do mentally.
We can use a different table to help with finding the difference between
two hexadecimal numbers.

0 1 2 3 4 5 6 7 8 9 A B C D E F
0 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
6
b1
5
b1
4
b1
3
b1
2
b1
1
b1
1 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
6
b1
5
b1
4
b1
3
b1
2
b1
2 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
6
b1
5
b1
4
b1
3
b1
3 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
6
b1
5
b1
4
b1
4 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
6
b1
5
b1
5 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
6
b1
6 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
7
b1
7 7 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
8
b1
8 8 7 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
9
b1
9 9 8 7 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
A
b1
A A 9 8 7 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
B
b1
B B A 9 8 7 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
C
b1
C C B A 9 8 7 6 5 4 3 2 1 0 F
b1
E
b1
D
b1
D D C B A 9 8 7 6 5 4 3 2 1 0 F
b1
E
b1
E E D C B A 9 8 7 6 5 4 3 2 1 0 F
b1
F F E D C B A 9 8 7 6 5 4 3 2 1 0

To use this table, find the first hexadecimal number in the first column,
then go across the table to find the number subtracted from it. Read off
the result at the intersection. The notation b1 means borrow one. We can
again use another table to illustrate the actual mechanics of the process.
F 1 0 4
- 5 2 A C
result 9 E 5 8
borrow 1 1 1

Just as before, you must remember to add the borrowed ones where
necessary, but this is easy to handle mentally.
Notice the pattern that the binary numbers follow. The least significant
digit alternates 0s and 1s, the next significant digit alternates in pairs, and
so on.

V2.0 2-21
In order to perform addition in binary, we need to be familiar with the
following rules of binary addition:
0 plus 0 produces 0
0 plus 1 produces 1
1 plus 1 produces 0 with a carry of 1 into the next most significant
place
1 plus 1 plus 1 produces 1 with a carry of 1 into the next most
significant place
An example will show how we can use these rules in a real addition.
0 1 1 1 0 0 1
+ 1 1 0 0 0 1 1
result 1 0 0 1 1 1 0 0
carry 1 1 1 1

Starting in the rightmost column, we have 1+1, so the result is 0 and a
carry of 1, which we see in the carry row of the next column. Moving to
the next column we have 0 +1 +1 carry. The result is 0 with a carry of 1.
The process continues until all the columns have been added.
Notice that we are adding binary numbers without any concern for their
sign. In any real computer system, we need to be able to work with signed
and unsigned integers. Most CPUs use a simple convention for
representing signed negative values, called twos complement. This allows
the CPU to handle addition of both positive and negative integers, but
more importantly, it also facilitates subtraction of signed integers in a
simple way. Subtraction can, of course, be performed by changing the
sign of a number and then adding to the other number. We will not
describe the twos complement method here, since this is not the way you
would do binary arithmetic by hand.
7 Data Structures
Programmers use a variety of ways of structuring data to make it possible,
or at least more convenient, to implement a system. Certain algorithms
are very closely linked to a specific type of data structure and it is useful
to discuss both the algorithm and the data structure together.
Most of the data structures we will describe in this section are intended for
use within the primary storage (RAM) of a computer. They may be
capable of use within secondary storage, but we will not specifically
describe that area of application.

All these in-memory data structures are based on a single, underlying
model of memory organisation.

We have a large number of individually accessible memory locations.
Each of these has a unique address, which is shown as the numbers 1 to
C in Figure 2.1. Each of these memory locations can hold a fixed number
of binary digits. In the figure, each memory location contains 8 bits or 1
byte. This is the scheme used in most microprocessors.
All the data models we will consider are based on this simple structure.

In a computer program, using a typical programming language, named
variables are used to hold items of data. Variables can be of various
types, such as numbers, text strings etc. These can then be manipulated
using the appropriate operations for the variable type. Number variables
can be operated on with arithmetic, string variables can be joined together
or split apart. A number variable will typically require several adjacent
memory locations to store the value. For example, an integer may require
2, 4, or 8 consecutive bytes to hold it. The compiler (or interpreter) keeps
track of the starting address of the variable and its type.
7.1 Arrays
An array is a series of individually numbered elements. An element is a
single unit of data, such as an integer or a character, but it could be more
complex than this. All the elements in an array are of the same type, so
we can have an array of integers or an array of characters, but we cannot
have an array that consists of some integer elements and some character

Definition
Variable a data item whose value can change during the execution
of a program.
Figure 2. 1 Memory Organisation
13
2
AF
1
00
3
19
4
D4
5
00
6
00
7
11
8
C6
9
00
A
89
B
12
C
AF
1
Address
Content

V2.0 2-23
elements. Arrays are extremely useful in programming, because they
provide the programmer with a way of structuring data in such a way that
every element, or just some elements, can be selected for processing by
means of another variable that holds the address of the elements.
For example, if an array contains 100 elements, the programmer can write
code using an index variable that counts from 0 (or1), the start of the
array, up to 99 (or 100), the end of the array, processing all the elements
by using the calculated value to address each array element in turn.

An array is given a name, just like any other variable, and the programmer
can refer to a particular element of that array by giving the array name
and the index of the element within the array. The index is normally
contained in some form of brackets.
Example:
Customer account [2516] would refer to the 2517
th
customer account if we
were using a programming language which starts array elements at zero.
The purpose of using an array is worthwhile; firstly it reduces the number
of different variables needed with any one problem, since customer
account in the example caters for all the customer account numbers, with
no need to have thousands of different names. The second advantage is
far more significant; it allows a set of interrelated data values to be
grouped together and subsequently to be manipulated.
The simple array we have described is a single dimensional array. This
means that the elements are arranged as a simple list with a single index.
We can extend this simple model to two-dimensional arrays.
Figure 2.2 shows how a two-dimensional array is formed.
Study Note
We said that the element at the start of the array could be numbered
either 0 or 1. This depends on the programming language being used.
C for example, uses 0 as the first element. This can be important
because getting array indexes wrong by 1 is a common source of
errors.


To identify a specific element in the array, we refer to both its row and its
column address as well as to the name given to the table. The table
above is called T; it consists of 4 rows and 5 columns, thus enabling it to
hold 20 elements. Element T (3,4) is the item (2.3) in row number 3,
column number 4 of table T.
Mathematicians call an array that contains numbers, or some other
mathematical function, a matrix.
Two-dimensional arrays are very useful to programmers since they
provide a way of referring to data in a simple, but well organised fashion.
7.2 Stacks
A stack is a data structure found quite commonly in some types of
computer programs. A good way of visualising a stack is to think about
the pop-up plate stacks often found in cafeterias. Plates are put onto the
stack which is spring loaded so that the top plate is always roughly in the
same place. Customers always take the top plate from the stack and the
kitchen always replaces clean plates on the top of the stack. A shorthand
way of describing this is to say that the plate stack is a Last-In-First-Out
(LIFO) organisation.

Study Note
There is no conceptual reason why the idea of an array cannot be
extended to three, four or as many dimensions as we need.
Arrays of four or more dimensions are hard to visualise, and are rarely
necessary. If you think you need this type of data structure, you
probably have some design problems and should take a good look at
the problem you are trying to solve.
Arrays with many dimensions consume a lot of disc space and are
wasteful of storage unless you are sure that all the elements will be
used most of the time.
Figure 2. 2 Two-dimensional Array
3,4 3,3 3,2 3,1 3,0
2,4 2,3 2,2 2,1 2,0
1,4 1,3 1,2 1,1 1,0
0,4 0,3 0,2 0,1 0,0

V2.0 2-25
It turns out that a stack data structure is very useful for some types of
system. This is not to suggest that application programmers frequently
use stacks, but they are a natural way of handling the design of some
kinds of systems software, such as an Operating System.
In order to understand a stack and some other types of data structure we
need a new type of variable. We have described variables that can store
numbers of various types and variables that can store text. We can
extend this idea to variables that can hold memory addresses. The
technical name for such a variable is a pointer (because it points to a
memory address). We can do some operations on pointers. We can:
Compare pointers to see if they point to the same address.
Find the difference between two pointers to see how far apart
they are in memory.
Add and subtract values from pointers so that they point at a
different address.
Increment or decrement pointers so that they point at the next or
previous memory location.
Note: The last of these is really just a more convenient form of the third
point.
Pointer operations such as these are usually scaled so that the pointers
always point to the start of the memory address used for any particular
data type. So for example, if we had a pointer to an integer and the
integer required four memory locations to store it, adding one to the
pointer actually means increasing its value by four memory addresses, so
that it points to the start of the next integer.
The simplest way to represent a stack is as a (conceptually) one-
dimensional array used in conjunction with two pointer variables, the first
to point to the base of the stack and the second, called the stack pointer,
defining the top of the stack.
Figure 2. 3 Stack

Stac
A8
57
F2
17
12
Empty
Bottom of stack
Top of stack
(Stack pointer)
Grows upwards


When a stack is represented in this way, the base-of-the-stack pointer will
be fixed so as to point to the first element in the list, whilst the stack
pointer will be free to move up or down (imagining the stack to be fixed
vertically) as items are added to the top of the stack for use.
There are two fundamental operations that we can perform with a stack:
Push (value) this increments the value of the stack pointer by one
so that it points to the next available space (marked as empty in
Figure 2.3), then sets the element at this position to the value. This is
equivalent to putting one plate on the top of our cafeteria stack.
Pop this removes the value at the top of the stack (the one pointed
to by the stack pointer) and makes it available within the program.
The stack pointer is then decremented so that it points to the next
lowest element. This is equivalent to a customer taking a plate off the
cafeteria stack.

Show how a program could tell if the stack was empty.
Suggest how the stack could be limited to a maximum size.
You do not need programming knowledge to answer these questions.
There is an important distinction to be made between an array and a
stack. Generally speaking, the size of an array is fixed. The program can
allocate the amount of space needed for the rows and columns, and the
array stays within those bounds. It is a static data structure.
A stack is a dynamic data structure; its size changes all the time.
7.3 Queues
A queue is another dynamic data structure, but rather than having the
LIFO characteristic of a stack, it uses FIFO (First-In-First-Out). A good
Study Note
We have not presented an example of the program code to show how
a stack would be implemented, because this module does not assume
any familiarity with any programming language. You should be aware
however, that a real program that uses a stack has to take care of
some potential problems. For example, what should happen when an
attempt is made to POP an item off the top of a stack that is empty?
What should happen if the stack grows and grows until it consumes too
much memory?

V2.0 2-27
example of a queue is a typical shop queue. Customers join the queue at
its tail, and the shop assistant serves the customer at the front or head of
the queue, so the first to join the queue is also the first to leave it.
Queues are (like stacks) frequently used in systems programming.
As in the case of a stack, it is possible to represent a queue by means of
a one-dimensional array. Two pointers are required, the first to point to
the front of the queue (the head pointer) and the second to indicate the
last entry at the tail end of the queue (the tail pointer). As items enter and
leave the queue, the queue slithers towards the end of the array. The
problem with this arrangement is that the queue continually moves
through memory and will leave the bounds of the array eventually, even if
a lot of space is allocated for it. A simple approach that removes this
problem is to make the queue circular so that the tail appears to be
chasing the head. The queue constantly circulates around the loop,
growing and shrinking as necessary.

Note that at least one open space must always exist between the tail of
the queue and the front so that we can clearly identify a queue which is
empty and one which is full.
Show how a program could tell if the queue was empty or full. You do
not need programming knowledge to answer this question.
8 Check Digits
Computer systems should be designed so that they detect when data
entry errors are made. For example, if a user needs to enter an account
number, it is important that the program checks for obvious mistakes,
such as transposed numbers. For example, entering 3578 instead of
3758. One commonly used approach is to use a check digit.

Figure 2. 3 Queue
Queue
Head (remove)
Tail (add)

A check digit is a number appended to the end of the number to be input.
When the user enters the actual number, a calculation is carried out on its
digits. This calculation results in a check digit being created, which is
compared to the final entered digit. If they match, the number has
probably been entered correctly. If not, the user can be prompted to
correct the data entry.
The art of using a check digit is all in the choice of the calculation. To
illustrate this point, assume that the account number we wanted to
validate was 1567823. We could form the check digit by adding up all the
digits in the account number, so the check digit would be 32
(1+5+6+7+8+2+3). The full number entered would therefore be
156782332. The problem with this is that there are a lot of numbers that
will produce the same checksum, so 516782332 273861532 and
328765132 would all be accepted (because they all add up to 37). The
first of these is a single digit transposition, precisely the type of error that
we could reasonably expect a user to make. From this we can see that a
better form of calculation is needed, one that recognises the order of the
digits in the number.
One of the most popular methods for calculating check digits is the
Modulus 11 Check Digit System. This uses a simple calculation to
generate numbers with valid check digits.
The method is as follows:
Choose a random number weight the same length as the number to
be checked.
Multiply the matching digits in the random number and the entered
number. For example, multiply the first digit of the random number by
the first digit of the entered number, and then multiply the second digit
of the random number by the second digit of the entered number.
Add up all the numbers resulting from the multiplications.
Divide the sum by 11, recording the remainder, if any.
Subtract the remainder from 11; this is the check digit, so append it to
the end of the number.
Example:
Account number is 55875
Random number is 64238:
Account
number
5 5 8 7 5
Random
number
weight
6 4 2 3 8 Sum /11
remainder
11minus the
remainder
Product 30 20 16 21 40 127 6 5

V2.0 2-29
Therefore, the number complete with check digit is 558755.
Theoretically, any number could be used as a modulus, but in practice it
has been found that prime numbers give the greatest degree of
protection.
The use of this technique has another major advantage, in that it is
slightly more difficult for a fraudster to guess what would be a valid
account to enter.
Using a table similar to the one shown, calculate the required check
digit and the complete entered number for the account number 47162,
using a weight of 65432, and modulus 11.

9 Statistics

There is a close relationship between statistics and Information
Technology. We often think of IT as helping people to obtain information
from data. Statistics has much the same objective.
A good starting point to understanding statistics is the description of data,
often called descriptive statistics.
9.1 Averages
The word average is, to say the least, a very loosely defined term. It
refers, in general, to the taking of a single value or quantity to be
representative of a number of such values or quantities; as such, it is
frequently referred to as a measure of central tendency. The problem is
that there is no single method of obtaining such a value, so that a choice
has to be made from a number available. The choice will be determined
partly by the nature of the values to be represented, be they qualitative or
quantitative etc, and partly by the purpose for which the average is
required.
In elementary mathematics courses the word average is usually
synonymous with what we shall define as the arithmetic mean; however
we shall see that other alternative averages exist, such as the median and
the mode.
Definition
Statistics numerical data relating to sets of individual objects or
phenomena. It is also the science of collecting, summarising and
interpreting such data.

9.2 The Mean
Assume we have eight numbers:
7 21 13 17 23 18 9 20
Add them up (giving 128), then divide the total by the number of items (8),
the value of the mean obtained would be 128 / 8 = 16. This particular
average can only be used with data which is quantitative. In working it out,
every one of the original eight values was taken into account so that each
one will have had an equal influence on the value obtained for the mean.
It is worth mentioning here that the mean may not be equal to any of the
original numbers (as in this case), but may do so on other occasions.
Note however, that the presence of even one value which is
disproportionate to the others in terms of its size may easily distort the
value of the mean obtained. For example, if the original set of values was
the 12 numbers:
3 3 4 4 4 4 5 5 6 6 6 176
then the mean would be the total (226) divided by the number of items
(12) giving 18.83 (to two decimal places). This value would not have been
seen as being in any way typical of the first items in the set, as the twelfth
item, 176, was so much out of keeping with all the others as to distort the
picture. This liability to distort is one of the factors to bear in mind when
attempting to decide which average is to be used.
We need to turn our rather wordy definition of the arithmetic mean into
something a bit more mathematically respectable, such as this:
N
x
x

=

The letter x denotes a value. The notation x (pronounced sigma x)
denotes the result of adding up all the x values i.e. the total of the x
values. N is used to denote the number of x values. Finally,the notation
x refers to the mean of the x values (read as x bar).
The mean has exactly the same units as those of the original data and it
is worth noting that, in order to calculate a mean, the data must first be
quoted in the same units as one another; i.e. do not mix minutes with
seconds or hours.

V2.0 2-31

1. A check was made to find how many exhaust systems for a popular
car had been fitted by Velotec workshops each day for 7 days during
August. Workshops are open every day. The figures were as follows:
12 14 17 16 24 13 7
Calculate the average number of these exhausts fitted per day.
Calculate how long the warehouse stock of 400 exhausts is likely to
last.
2. The Velotec accounts system is receiving some adverse comment.
The claim is that the time taken to enter a transaction is excessive.
The support team decide to investigate this. They time a sample of
transactions at a busy time of the day. The results were measured to
the nearest 0.1 second as follows:
2.3 1.6 2.9 3.6 4.1 2.6 2.7 3.1 3.8 2.7 2.8
Calculate the mean response time.
3. The support team accept that these response rates are a bit too
slow, so they raise the priority of accounts program on the server. To
check if this has solved the problem, they re-measure the response
rate, with the following results:
1.8 2.3 3.1 3.2 3.8 2.8 2.7 3.0 3.5 2.1 2.9
Calculate the new mean response time.
4. Using your results for (2) and (3) calculate the percentage reduction
in response time caused by the changes made to the system software.
Do you feel confident that the support team have solved the problem?
If not, why not?
9.3 The Median
When we calculate the arithmetic mean, it is common to find that the
mean is different to all the values. The median gives us another way of
representing a series of values.
Arrange the values in order of magnitude, lowest to highest, and select as
the average, the one that occurs in the middle of the list, calling it the
median this time.
If there are N items the median will therefore be the (N+1) th value.
Should N be an odd number this will identify one value uniquely, but if N is

even, such as 14, then the median is the 7th value, which is interpreted
as being exactly half way between the 7
th
and 8
th
values. So for
example, if we have 14 values, arranged in order of magnitude:
10900 11600 12500 12700 13400 13800 14100 15700 16200 17200
17700 17800 18700 19000

The 7th and 8
th
values are, respectively, 14100 and 15700, so the median
is (14100 + 15700) = 14900.
The median does posses some particular advantages; it is more easily
found than the mean and it is not so affected by extreme values. For
example: the median of the seven items:
3 4 7 8 12 15 8164
is exactly the same as the median of the seven items:
3 4 7 8 12 15 17
This is a disadvantage however at the same time, since it means that the
value of the median does not at all reflect the values of anything but the
middle term(s) in a data set, whereas the mean is affected by each
value.
The following are the ages in years of the 12 staff in the largest Velotec
exhaust fitting workshop. The management are concerned about staff
retention so need to keep track of the typical ages in each workshop.
26 29 42 28 51 23 32 49 29 35 41 38

Arrange the ages in ascending order of magnitude and hence calculate
the median age.
The run times (in minutes) of an overnight report run on the server
were noted and listed below:
37 21 16 59 18 24 37 41 12 29

Calculate the median run time.
9.4 The Mode
The mode is defined to be that value which appears most commonly in
the list of data items, i.e. the most popular item. As this completely
ignores the values of the data items, it is especially well suited to data
which is qualitative. In the table shown below, the popularity of a number
of different programming languages was investigated.

V2.0 2-33
If two values appear with equal frequencies, both proving to be more
commonly found than any other value, both are classified as the modes
and the distribution is referred to as bimodal.
A survey of languages used by companies in one town.
Language Used Frequency
FORTRAN
C
JAVA
VISUAL BASIC
C++
SQL
24
43
8
16
14
1
The mode is C since it has the highest frequency.
Apart from its ease of determination, the mode may be used for planning
purposes. If (all other factors being equal), a decision had to be made
about which language to select for the purpose of training a group of new
recruits to computing at a training school, then the most popular language
(i.e. C in the previous case) is likely to be the one to be used. If it were
possible and desirable to train them in two languages, then the most
popular, C, and the second most popular, FORTRAN would seem to
provide the best coverage, since the trainees would be capable of working
in 41 of the 80 companies in the survey.
1. Determine the mode of the following set of values:
6 8 5 12 6 8 16 5 9 3 12 4 9 6 5 13 7 9 8 2 5 1
2. All Velotec HQ staff were asked to choose a new colour for the
walls. Only 47 responded and chose as follows:
Beige 12
Blue 3
Lemon 8
Mustard 4
Pink 9
White 11
What was the mode?
Do you think the mode is a good indication of the preference of the
HQ staff?


9.5 Frequency Distributions
A frequency distribution provides a simple way of summarising data. So
for example, an analysis of a sample of the Velotec loyalty card usage
shows that the number of repeat purchases using the card looks like this:
0 28
1 76
2 43
3 33
4 19
5 7
6 3
7 1

We can plot this type of distribution as a histogram, as shown below.
9.6 Cumulative Frequency Distribution
Sometimes, a simple frequency distribution is not sufficient. The total
frequency up to a particular value on the horizontal axis (the value of the
relevant variable) may be needed.
The table below shows an analysis of the number of lines of C++ code in
a small library of routines purchased to improve the productivity of the
Velotec development teams. It shows that 24 programs have between
150 and 174 lines of code; however, we may be interested in knowing
how many have less than 175, this being the sum of the frequencies in
the categories 100-, 125- and 150-, or a cumulative frequency of 3 + 12 +

Figure 2. 5 Frequency Distribution
Frequency Distribution of Repeat
Purchases with a Loyalty Card
0
20
40
60
80
0 1 2 3 4 5 6 7 8

V2.0 2-35
24 = 39. Some organisations have limits on the number of lines of code
for an individual program.

Lines of
code
Number of
programs
100-
125-
150-
175-
200-
225-
250-
275-
300-
325-349
3
12
24
42
51
39
30
21
12
6

To do this, it is essential to first construct what is called a cumulative
frequency distribution table, by counting up the total frequency below
each of the boundary values, including the lower limit of the first category
as well as the upper limit of the last. Hence, the total frequencies for
values less than 100, 125, 150, etc needs to be found. Since there is
nothing less than 100, the cumulative frequency less than 100 must be 0;
for less than 125 it is 3, for less than 150 it must be 3+12 or 15 and so
on, with the final cumulative frequency less than 350 being the total of all
the original frequencies, i.e. 240, a check that the calculation has been
correctly done.
Lines of code
(less than)
Cumulative
frequency
100
125
150
175
200
225
250
275
300
325
350
0
3
15
39
81
132
171
201
222
234
240


The table shows that 15 programs had less than 150 lines of code each,
that 201 had less than 275 lines of code each, etc. To produce the
corresponding cumulative frequency curve, the values obtained from the
cumulative frequency table can be plotted. Such a curve can now be used
to determine how many programs contain less than any given number of
lines of code, by reading off the values.
9.7 Relative Frequency Histograms
Sometimes using absolute frequencies is a severe limitation. This is
particularly true when we want to compare two different cumulative
frequency distributions. If the total number of readings in each distribution
is different (a typical condition), we cannot easily compare the
distributions.
A relative frequency histogram can resolve this problem.
In order to create a relative frequency histogram, the relative frequency
for each category needs to be found; this means that the actual frequency
must be divided by the total of all the frequencies for the whole
distribution. Hence if one category has a frequency of 12 and the total of
all frequencies in the distribution is 200, then that particular category
would have a relative frequency of 12 / 100 = 0.06.
Once this has been calculated for each of the categories, the histogram
may be drawn using the relative, rather than the absolute frequencies.
The total of all the relative frequencies for a given distribution will always
be exactly 1 no matter what the distribution is, how many categories it
may contain, or what the total of the actual frequencies (absolute rather
than relative) may have been.

Figure 2. 6 Relati ve Frequency Distribution
Rel at i v e Fr equ ency Di st r i but i on of PC Ages
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
0.45
1 2 3 4 5 6
Department A
Department B
Age of PC 1 2 3 4 5 6 Total
Department A 16 10 8 4 2 1 41
Relative Frequency 0.39 0.24 0.20 0.10 0.05 0.02 1
Department B 5 3 3 3 2 1 17
Relative Frequency 0.29 0.18 0.18 0.18 0.12 0.06 1

V2.0 2-37
Figure 2.6 shows how the calculation can be laid out in a spreadsheet and
the relative frequency distributions plotted. The spreadsheet shows the
ages of PCs in two different Velotec departments. The histograms plot the
relative frequency distributions of the ages of equipment.
It can be seen at once that there is a far higher proportion of older
equipment in department B. This would have been difficult to state with
certainty using the absolute frequency distribution.
10 Measures of Spread or Dispersion
The term average was introduced as a method of identifying one item to
represent or be typical of a group of items; a measure of location.
However, having an average really tells us little about a set of data. What
we usually want in addition to an average is how the data is spread out or
dispersed. For that we need a measure of spread or dispersion.
Consider the four distributions below in which the mean has been
calculated for each.
Distribution A: 5, 6, 7, 8, 9, 10, 11 Mean is 8
Distribution B: 5, 5, 5, 8, 11, 11, 11 Mean is 8
Distribution C: 1, 2, 3, 8, 13, 14, 15 Mean is 8
Distribution D: 14, 15, 17, 19, 20 Mean is 17

Figure 2.7 shows these four distributions as frequency distribution
histograms.
The distributions A, B and C each have seven values and the same mean
of eight, yet they are different in other ways. A involves an even
distribution of values between the two end-points of 5 and 11 and
although B uses the same end-points, the values are spread in such a

Figure 2. 7 Measures of Spread
easu es o Sp ead
2
4
6
8
10
12
14
16
18
20
A
D 0
0.5
1
1.5
2
2.5
3
Thr e e Fr equency Di st r i but i ons
A
B
C
D

way as to be heavily bunched at the end-points. In C, the end-points are
further apart yet the values are still clustered close by them without
affecting the mean at all. With D, the difference between the end-points
is the same as in cases A and B, yet the mean is quite different.
A second parameter must therefore be introduced to assist in describing
the distribution. This parameter should identify the way in which the
values are spread out or dispersed. It must reflect the fact that the values
in C are far more widely scattered than in the other three cases and it
should also distinguish between the uniformity of distribution seen in A
and the clustering around the end-points of B. Just as in the case of
averages, there is no such single measure of dispersion. This section will
examine a few of the different ways of representing it.
10.1 The Range
The range is the simplest measure of dispersion. It is found, for any
distribution, by subtracting the smallest data value in the distribution from
the largest. So for the four distributions:
Distribution Range
A 6
B 6
C 14
D 6

Immediately we can see that B and C are more readily distinguished from
one another; both have the same mean of 8, but the greater degree of
spread of C leads to a range of 14 rather than to one of 6, as in the case
of B. It is worth noting at the same time that A and D have the same
range, yet different means. However, the range totally fails to distinguish
between A and B, which have equal means and equal ranges but, as
already indicated, the data in B is more clustered around the two end-
points than with A. Thus the range is incapable of coping with what
happens between the end-points. Nevertheless, it provides us with a very
easily obtained measure of dispersion, even if it is not capable of
providing the degree of discrimination required in all cases.
Just as the mean could be distorted by extraneous untypical data items,
so too can the range. In the case of distribution A (earlier), if we replaced
the value 11 by a value of 17 so that the distribution becomes:
5 6 7 8 9 10 17
the mean would change from 8 to 8
6
/
7
and the range would double from 6
to 12. Had the values between 5 and 11 of the original distribution A been
altered, the range would not have changed at all in the process.

V2.0 2-39

i) Find the range of the data values:
29 7 15 23 11 14 36 8 14 17 21
ii) If the value of 36 in question 1 was changed to 39, what effect
would it have on the range?
10.2 Standard Deviation
A measure of dispersion which can overcome the objections listed for
both the range and for other simple measures of spread, is the standard
deviation. At first it may seem that the manner of its calculation is long
and unwieldy, but since it can be calculated almost as a by-product of the
calculation for the mean of a grouped frequency distribution, in most
cases there will be relatively little extra work to be done. Most scientific
calculators have a standard deviation function and its calculation is easy
with a spreadsheet.
The features that we require of a good measure of dispersion are:
That every data value is taken into account.
That data values are weighted according to their frequency.
The standard deviation satisfies these criteria and is calculated according
to the following steps:
Calculate the mean,x of the data items.
Obtain the deviations x
i
x for each of the data items x
i
.
Obtain the squares of these deviations for each value x.
Find the mean of the squared deviations by dividing by the number of
data items -1.
Obtain the square root of this value.
Putting this in mathematical terms :
=
n
i
i
n
x x
1
2
1
) (

Much of this makes sense when you look a bit closer. The x
i
-x is
measuring the spread of a value from the mean. The trouble is that this
could be positive or negative, when we really want just a number. We
overcome that difficulty by squaring the value, getting rid of any negative

values. What we want is the mean dispersion, so we must divide by the
number of items. This leaves us with a value that is squared, so we find
the square root to bring it back to numbers that are directly meaningful in
terms of our data values.
The division by n-1 looks a little mysterious why would we not divide by
n? The answer is that usually we are measuring a series of values of x
that are drawn from a much larger possible population of xs. So the mean
we are dealing with is the mean of the sample of data items, not the
actual mean of the whole population. Under these conditions, it is better
(theoretically) to divide by n-1. In truth this makes very little difference
when we are working with reasonable values of n.
The result is the standard deviation of the original set of data items.
Let us work this through in a spreadsheet so that you can see the
calculation more clearly.
The example below shows the calculation of the standard deviation for a
distribution of 10 data values.
Note in particular the deviations. Some of these values are positive, some
negative, and the squaring which takes place next is a means of
eliminating the signs; it is compensated for by the last stage in which a
square root is taken.

Values 3.00 6.00 7.00 9.00 9.00 11.00 12.00 13.00 14.00 19.00 Mean 10.30
Deviation -7.30 -4.30 -3.30 -1.30 -1.30 0.70 1.70 2.70 3.70 8.70
Squared
deviation 53.29 18.49 10.89 1.69 1.69 0.49 2.89 7.29 13.69 75.69 Total 186.10
Mean 20.68

Std Deviation
4.55

So the standard deviation is 4.55.
Occasionally, reference may be made to the variance; this is simply the
square of the standard deviation. In the previous example, the variance
was calculated as 20.6 so the variance is calculated as a by-product of
the standard deviation.
The standard deviation has exactly the same units as did the original data
values.
The standard deviation, together with the mean, provides us with a
method of comparing two or more distributions in a workable manner.
Together with the concept of probability, these two measures form the
cornerstone of much statistical work, though they are not covered in this
workbook.

V2.0 2-41

The following values are the times, in minutes, taken to run the same
spreadsheet application on eight different microcomputers:
6.1 7.3 5.4 6.9 8.7 5.3 6.4 8.3
Calculate the mean and the standard deviation of these values.
State clearly the units involved in each of the results.
Calculate also the variance of the times, stating clearly the units.
11 Elementary Probability
Probability is the essential foundation for understanding the theory of
statistics. We all have a personal view of what probability means but we
really need to tighten up definitions to be able to make progress with the
theory.

For an example, if we throw a single dice, the sample space is 1, 2, 3, 4, 5
and 6. Throwing a dice is an experiment which mathematicians frequently
use in connection with probability. This reflects the origin of the study of
probability, which was the study of gambling.
Study Note
Although range may not be so widely used as standard deviation, it has
the great advantage that it can be calculated exceptionally quickly and
this has some useful repercussions. All too frequently, carelessness in
calculating standard deviation leads to values being obtained which are
wildly inaccurate.
One very simple device that works in a large number of cases (but not
all), is to check that the calculated standard deviation has a value
which lies approximately between one eighth and one quarter of the
range; if this is true then the standard deviation has at least the correct
order of magnitude, whether or not it is arithmetically correct. This test
may be used solely for the purpose of establishing that the calculated
standard deviation is at least of a size which is appropriate to the data
values being analysed, and so it avoids the putting forward of values
which are totally and obviously wrong.
Avoid embarrassment check your calculations.
Definition
Sample Space the sample space is defined as the set of all possible
outcomes of an experiment.


For example, if a dice is thrown, and a number less than 4 is obtained,
this is an event that contains the sample points 1, 2 and 3.
So if an experiment has N equally likely outcomes and an event is made
up of E of these outcomes, we define the probability of that event to be E
/ N.

A few more examples may make this easier to understand.
First, imagine a shuffled pack of 52 playing cards from which can be
chosen at random any one card which could be any of the four suits,
hearts, clubs, diamonds or spades. The experiment refers simply to
selecting a card from the pack and the outcomes are the different suits
that can be chosen. Given the same experiment, one may be more
selective and choose to pick a particular face value such as an ace, king,
queen, etc, being the outcomes in this instance.
Since there are 52 cards (N = 52) of which 13 are spades (E=13), the
probability of drawing a spade is
13
/
52
or . Similarly, since there are four
kings (E=4) in the pack, the probability of drawing a king is
4
/
52
or
1
/
13
.
Since there is only one king of spades (E=1), the probability of drawing it
is
1
/
52
.
Taking a different situation, in rolling a traditional sixsided dice, there are
six equally likely outcomes. Hence the probability of throwing a 5 is
1
/
6

(since N = 6 and E = 1). If faced with finding the probability of throwing an
even number (E = 3 since there are three such outcomes possible), then
the value of that probability would be
3
/
6
or . Not surprisingly, the
probability of throwing a 7 would be 0 (since E=0), a value representing
total impossibility. Alternatively, finding the probability of throwing a
number between 1 and 6 inclusive (E=6) would be
6
/
6
or 1, a value which
represents absolute certainty.
The introduction of the word success may convey the attainment of some
desired outcome, such as the throwing of an evennumbered face on the
dice; thus probability in the manner defined will imply the probability of
achieving that success. This probability is denoted by the use of the letter
p. Furthermore, we denote by the letter q the probability of failure, i.e. of
failing to achieve success. Since it is absolutely certain that if an event is
Definition
Event each possible outcome of an experiment is a sample point. A
collection of sample points with a common property is an event.
Definition
Probability a mathematical expression of uncertainty that is a
measure of the possibility of occurrence of an uncertain event or
happening.

V2.0 2-43
not a success then it must be a failure, it follows that the respective
probabilities must add up to 1, since success and failure are seen as
complementary events.
Hence:
p + q = 1.
As a clarification of this, if the experiment involved the throwing of the six
sided dice and a success was the throwing of a 3, then (with N = 6 and E
= 1) p =
1
/
6
. A failure must mean failing to throw a 3, i.e. throwing instead
any other number so that (with N = 5 and E = 6) q =
5
/
6
. This may help
to reinforce the point that p + q =1. On the point of notation, the
expression P(E) is often used to stand for the Probability of achieving an
Event, with the particular event often defined in the bracketed expression.
Unless there is any possibility of confusion we shall take P(E) = p. In
those cases where some confusion is possible it is better to use
subscripted values such as p1 or p2 or p3 etc to refer to different
probabilities in the same experiment.
Given that an experiment may be carried out not just once but on a
number of different occasions, each is called a trial.
Hence, if the dice is thrown on 12 occasions (whatever outcomes they
may produce) there have been 12 trials of the same experiment. It may
never be declared in advance (with any certainty) what the outcome of
any given trial will be, but we can, by theory, by practical work or a
mixture of both, identify all the possible outcomes and attach to each one
a probability which indicates which outcomes are more or less likely.
If one declares the probability of getting two heads when two coins are
thrown is , then one can be confident that while the event may not
actually happen once on every four throws, it will tend to happen on a
quarter of all throws as the number of trials increases.
11.1 Relationship - Relative Frequency and Probability
Earlier, we showed how a relative frequency histogram can be
constructed. There is an obvious connection between relative frequency
and probability.
Relative frequency measures the way in which one particular category
occupies the distribution as a whole and in what proportion. We could as
easily ask the question How likely is it that a piece of equipment chosen
at random from workshop W8, will be between 4 and 5 years old? We
could view the result as a measure of the probability that the age of the
equipment lies between those limits.


i)
A Velotec project manager has started to become concerned about the
level of expertise of his programming team. He has kept records of the
success of initial compilations of some C++ code produced as part of
the project.
The results indicate that:
2 compiled correctly on the first run.
7 compiled correctly on the second run.
5 compiled correctly on the third run.
4 compiled correctly on the fourth run.
2 compiled correctly on the fifth run.
On the basis of the foregoing data, calculate the probability that the
next program will compile correctly:
1 on the first run;
2 on the second run;
3 on the third run;
4 before the fifth run;
5 after the third run (but not earlier);
6 at all;
7 but not on the first run.
ii)

The operations manager keeps a log of the downtime records of the 30
PCs in the sales department. These indicate that:
17 PCs have never failed.
8 PCs have each failed on one occasion.
4 PCs have each failed on two occasions.
1 PC has failed on three occasions.

V2.0 2-45

Continued..
On the basis of this data what is the probability that if a PC were
chosen at random from the 30, it would:
1. never fail;
2. fail once;
3. fail twice;
4. certainly fail;
5. fail twice or three times;
6. fail four times.

12 Summary
In this chapter we have covered a range of basic mathematical
techniques, all of which have some application to system design
programming, or system operations.
The ability to use and understand numbers in any of the common bases,
such as decimal, binary, octal and hexadecimal, is frequently needed for
certain types of programming tasks. Any programmer should be able to
carry out conversions and simple arithmetic in these bases.
Visualising functions using a graph is frequently needed to gain a better
understanding of data. You should be able to produce such graphs and
use them to answer simple questions.
There are other mathematical topics, for example sets, logic, and
particularly for graphics, matrix manipulation. These topics are not
required at the level of study of this module.


13 Answers
Answer 2.1
42

Answer 2.2
The decimal value of octal 47023 is 4 x 4096 plus 7 x 512 plus 0 x 64 plus
2 x 8, plus 3 x 1, 16384 + 3584 + 16 + 3 = 19987.

Answer 2.3
The hexadecimal quantity ABC has a decimal value of 10 x 256 plus 11 x
16 plus 12 x 1, or 2560 + 176 + 12 = 2748.

Answer 2.4
i)
1. 6
2. 9
3. 29
4. 13
5. 19
6. 50
7. 26
8. 115
9. 205
10. 150

ii)
1. 15
2. 21
3. 35
4. 110
5. 132

V2.0 2-47
6. 242
7. 263
8. 459
9. 862
10. 1485

iii)
1. 20
2. 35
3. 27
4. 60
5. 125
6. 162
7. 2739
8. 2821
9. 4013
10. 62014

iv)
1. 1.25
2. 6.625
3. 0.1875
4. 2.296875
5. 5.109375
6. 8.453125
7. 3.6875
8. 25.14453125

Answer 2.5
i)
1. 1101
2. 11001
3. 11101
4. 1000000
5. 1001001

6. 1111111
7. 1100111
8. 10101111
9. 11101100
10. 11000111
11. 100010010
12. 111101101

ii)
1. 11
2. 21
3. 27
4. 47
5. 57
6. 123
7. 140
8. 144
9. 177
10. 455
11. 1024
12. 1436

iii)

1. 17
2. 1D
3. 23
4. 2A
5. 36
6. 4F
7. 8C
8. 96
9. FE
10. 104
11. 1FD
12. 219

V2.0 2-49
13. 50F
14. 7CE
15. 2F0F

Answer 2.6
i)
1. 556
2. 614
3. 331
4. 55
5. 65
ii)
1. 111010101
2. 101011110
3. 10011100
4. 1000110101011
iii)
1. D3
2. 25
3. 17
4. 2A
iv)
1. 101011
2. 111111000111
3. 10001100
4. 11110111100010

Answer 2.7
i) If the stack pointer = the base of stack, then the stack must be
empty.
ii) The stack could be limited by using another pointer that points to the
maximum allowed address in the stack. Every time an attempt is made to
push on the stack, the stack pointer could be tested to make sure it does
not exceed the maximum stack pointer.


Answer 2.8
The queue is empty when the tail pointer value equals the head pointer. It
is full when the tail pointer is one less than the head pointer.

Answer 2.9
Account
number
4 7 1 6 2
Random
number weight
6 5 4 3 2 Sum /11
remainder
11-
remainder
Product 24 35 4 18 4 85 8 3
Complete entered number = 471623

Answer 2.10
1. 14.71 exhausts per day, stock would last 27 days to the nearest day.
2. 2.9 sec (to nearest 0.1 sec).
3. 2.8 sec (to the nearest 0.1 sec).
4. 3% reduction in response times. Given the variations in the samples,
you could not be confident, without further analysis, that an
improvement has been made. A more sophisticated statistical test
could give a more definitive answer, but this is beyond the scope of
this chapter.

Answer 2.11
1. 23 26 28 29 29 32 35 38 41 42 49 51; median is 35 years.
2. 12 16 18 21 24 29 37 37 41 59 median is 26.5.

Answer 2.12
1. 5
2. Beige, but this is not a very good indication of preference.

Answer 2.13
1. Range is 29
2. Range would increase to 32


V2.0 2-51
Answer 2.14
Mean
Values 6.1 7.3 5.4 6.9 8.7 5.3 6.4 8.3 6.8
Deviation -0.7 0.5 -1.4 0.1 1.9 -1.5 -0.4 1.5Total
SquaredDeviation 0.490.251.960.013.612.250.162.25 10.98
Mean
1.37
Std Deviation
1.17 minutes
Variance is 1.3725 minutes.

Answer 2.15
i)
1.
1
/
10

2.
7
/
20

3.
4.
9
/
10

5.
3
/
10

6. 1
7.
9
/
10

ii)

1.
17
/
30

2.
4
/
15

3.
2
/
15

4.
13
/
30

5.
1
/
6

6. 0


V2.0 3-1
Chapter 3
System Development Life Cycles
2 Introduction..................................................................................................3-2
3 Software Engineering...................................................................................3-2
3.1 Why is Producing Software So Difficult? ...........................................3-3
3.2 Programme Size................................................................................3-5
3.3 Quality and Productivity.....................................................................3-6
4 Project Stages and Project Control..............................................................3-8
4.1 Strategic Study...................................................................................3-8
4.2 Business Study..................................................................................3-9
4.3 Feasibility Study.................................................................................3-9
4.4 Requirements Analysis ....................................................................3-10
4.5 Requirements Specification.............................................................3-11
4.6 Logical Systems Specifications .......................................................3-11
4.7 Logical Design..................................................................................3-12
4.8 Physical Design................................................................................3-12
4.9 Coding..............................................................................................3-13
4.10 Testing.............................................................................................3-14
4.11 Implementation.................................................................................3-14
4.12 Maintenance.....................................................................................3-15
4.13 Phase Out........................................................................................3-16
5 The Waterfall Life Cycle Model..................................................................3-16
6 The V Model .............................................................................................3-17
6.1 Testing - Why and When.................................................................3-18
7 Velotec Training History System................................................................3-19
8 Prototyping.................................................................................................3-20
9 Velotec Product Data Management System..............................................3-21
10 Rapid Applications Development...............................................................3-22
11 The Spiral Life Cycle Model.......................................................................3-24
12 Summary....................................................................................................3-25
13 Self Study...................................................................................................3-26
14 Answers .....................................................................................................3-27

Chapter 3 System Development Life Cycles Systems Development


Software and project stages
Life cycle models
Prototyping and rapid development methods
2 Introduction
In a previous chapter we introduced some basic ideas about how software
development is organised in a typical business. We introduced the
different types of skills involved in software development and how it is
important that a close collaboration exists between business managers
and the IT specialists. We illustrated some of those ideas by relating them
to our case study organisation, Velotec.
In a previous chapter we saw how the development of a system followed
a life cycle and that the system itself has a life cycle that includes
maintenance activities. In this chapter we will explore some life cycles in
more detail.
3 Software Engineering
Engineers and mathematicians produced the earliest computer systems.
They knew what they had to achieve, they had well-defined and relatively
simple problems to solve. Typically the automation of a complex
calculation, and they understood the architecture of the computer system
they were using in detail. The idea that there was a development process
underlying their work would have seemed very strange to them. They
were simply using a tool to carry out calculations.
As systems became more complex and we started to use computer
systems to solve less well-defined problems, we continued to produce
systems in the same way. Effectively the programmers who wrote code
learned from hard experience and sometimes from each other.
Essentially this was a craft industry; where what mattered was the
creation of a product and the process needed to reach that goal was
unimportant.
This approach to system building started to fall apart in the 1960s. The
improved power of mainframe computers enabled far more complex
problems to be solved by using a computer. Increasingly large projects
were being undertaken and developed in the same informal manner as
had been the case with much smaller and less complex systems. Due to
the informal approach, many of these large systems failed to deliver the
Systems Development Chapter 3 System Development Life Cycles

V2.0 3-3
required system. Such failures resulted in great concern being expressed
within the software industry and the term software crisis was used to bring
the problem into focus.
Research was undertaken both by the software industry and by
academics in the field of software development. The result of all the
research, seminars and discussions was to realise that in order to resolve
the software crisis, we needed to regard software development as an
engineering discipline. Thus the discipline of Software Engineering was
born.

3.1 Why is Producing Software So Difficult?
Building something large is more difficult than building something small.
More precisely, the difficulty of producing something increases with its
complexity. This is true for any kind of artefact (manufactured item).
Some of the most complex products include:
ships
large aircraft
cars
worlds tallest buildings
worlds longest bridges
In each of these cases there is a design stage which takes a long time
and which can require hundreds of people all with different skills. The
production processes will also require large groups of workers, with each
group having different sets of skills. The production processes may need

2
Ian Sommerville (2006) Software Engineering 8
th
Ed, Addison Wesley ISBN- 0321313798
Study Note
The terminology software engineering seems to have originated in
1968 at a conference in Rome and a further conference in Garmisch,
Germany.
Definition
Software Engineering software engineering is an engineering
discipline, using a systematic and organised approach (including
theories, methods and tools) which is concerned with all aspects of
software production from the early stages of systems specification
through to maintaining the system after it has gone into use.
Sommerville (2006)
2


to be entirely newly designed. The design stage in each of these cases
can take several years, and the complete operational (useful) life cycle of
the product from production to scrap, can vary.
If we examine products that are less complex, we find that substantially
fewer people and less time is required to design and produce them.
What we are observing is a non-linear relationship between complexity
and the difficulty of producing a product. The difficulty increases much
faster than the degree of complexity.

Large software systems are very complex products. This means that we
are operating at the far right hand end of this curve, where the difficulty
increases almost vertically, with small increases in complexity. This alone
is sufficient to explain why developing large software systems is
problematic, but there are other contributory factors, such as the fact that
typically, software design is not always given sufficient attention in
comparison to other complex products:
Software is intangible, meaning that we cannot directly perceive the
product either during or after design. Remember, we mentioned in
chapter 1 that we had difficulty showing potential users what the
system would look like and what it would do! This makes it much
more difficult for us to understand and to maintain. Intangibility also
makes it very difficult to assess the status of a system in the same
way that we can physically inspect a car to see how complete it is.
Software is not subject to well-understood physical laws. All other
manufactured products are based on engineering principles that can
ultimately be traced back to the laws of physics. Software is subject
to some fundamental logical principles, but they do not help us gain
an understanding of a system as a whole in the same way that the
principles of mechanics do for a car.
Complex physical products such as cars and aircraft are based on the
reuse of components which have been designed and implemented
D
i
f
f
i
c
u
l
t
y

o
f

p
r
o
d
u
c
t
i
o
n
Complexity of product

Figure 3. 1 System Complexity

V2.0 3-5
previously. The software industry has learnt over the years and the
development of Object Oriented Technology, which we will discuss
later in this workbook, has increased awareness, and reuse is now
considered and used wherever possible.
3.2 Programme Size
Many students (but not all) will have had the opportunity to write very
small programs as part of their normal secondary education. These
programs are often small (say 20 lines of code) and usually perform some
simple calculation or analysis. Whilst the mental effort required to produce
and test the program may seem great at the first attempt, this quickly
reduces with increased familiarity. With practice, most people can write a
simple program within an hour or less and with reasonable accuracy.
Notice that this is the entire process, from thinking about the problem
(systems analysis), deciding how to solve it (system design) writing
program code (programming) and checking that it works (testing). The
documentation phase is usually ignored in this situation.
A medium sized computer system with perhaps 50,000 lines of program
code, should, on the basis of the above, take about one month, assuming
that you used a team of five people this is not an unreasonable team
size since this is obviously a much bigger project!
In practice, a project like this is more likely to require at least one year,
and possibly longer. There is clearly something wrong with our
assumptions about how projects scale up from little programming
exercises.
There are two reasons why this scaling does not work:
The complexity of a computer system does not increase linearly with
size measured in lines of program code. The relationship is more like
the curve we saw in Figure 3.1. This means that the difficulty of
producing a computer system increases extremely quickly with size.
The idea that adding more resources to a project will allow it to be
completed more quickly seems reasonable.
Unfortunately, we learned many years ago that this idea simply does
not work for large software development projects. In fact adding
resources to a project in order to reduce the time needed for
completion usually has exactly the opposite effect it extends the
entire project duration.


This exercise is a class project that will require you and your
colleagues to collect information over the duration of your course.
Collect newspaper articles and web based information about large
computer projects. Concentrate on those undertaken by governments
(or their suppliers) and very large companies. Look especially for
problems related to project size and complexity. Combine all your
information with your colleagues and jointly produce a short report on
your analysis of these projects. Where projects have been successful,
look for the reasons for the success (these are often supplied by the
project sponsor). Where the project has failed, you may need to rely
on the views of reporters and commentators. No formal answer is
provided for this exercise.
3.3 Quality and Productivity
If we accept that size and complexity have a disproportionate impact on
the difficulty of producing software and that we cannot assume that
adding resources can help, does this fully define why software
development is so problematic?
The answer is no; there are other factors we need to take into account.
The first of these is quality.
When we buy a consumer durable (e.g. razor, hair dryer, cell phone, TV,
car etc) from a well-known supplier, we expect that the product will
function well for its entire life span. If any maintenance is required, this will
be well-defined and simply undertaken (think of a car). If any failure
occurs, we expect the shop or the supplier to fix the problem or to give us
another (working) product.
Unfortunately, this is not the normal expectation for software. We know
that it used to be quite common for desktop software applications to fail
(crash), often with the loss of data. Desktop software is now more reliable
due to the many millions of users having found and reported most of the
bugs for the supplier to fix. New releases however still fail. The situation
with bespoke (developed in-house for a specific purpose) software is even
Further Reading
The problem of scalability was first documented by Frederick Brooks
whilst working as a project manager with IBM on the development of a
new mainframe Operating System (a large complex job). He analysed
his experiences and wrote one of the most influential computing books.
Although an old book, his ideas and the way he expresses them are
still as valid as ever.
F. Brooks, The Mythical Man Month: The Essays on Software
Engineering, Addison Wesley (1995), ISBN 0201835959

V2.0 3-7
worse, with major errors being very common in the early part of the life
cycle. It is suggested that the software used in the US moon landing craft
had around 900 known coding errors, but still the system was useable!
Notice that we are only really considering a single type of error here, one
that stops us from using the software. Much more common is an error that
means the software does not correctly implement an aspect of the
specification in the way required. This is analogous to providing car
ashtrays that cannot be opened. The ashtrays are there; but they do not
meet the specification expected of a useful ashtray.
There are more scientific ways of measuring quality than this, but it is
clear that the level of quality we obtain from software products is not the
same as we expect from other products. Clearly we need to know why
this is so. This is one of the major objectives of Software Engineering.
Productivity is another area where there are some surprises and further
problems. We can define productivity very loosely as the amount of useful
output produced per hour. If you measure the productivity of workers in
several manufacturing companies you will find some variations both
between workers and companies, but provided the same tools and
processes are being applied, these are relatively small. Studies of
programmer productivity (people working on the same tasks with the
same tools) showed a variation between programmers of at least 16:1.
That is, some programmers took sixteen times as long to complete the
same set of tasks as another group of programmers. A variation such as
this in other industries would cause great concern and probably result in
the worker (and his manager) being fired.
Some studies have shown that about 13% of programmer time was spent
writing programs. The other classes of activity were:
Reading programs and manuals 16%
J ob communication 32%
Personal 13%
Miscellaneous 15%
Training 6%
Mail 5%
Notice that job communication absorbs by far the largest proportion of
time. Although this study was carried out some years ago, more recent
studies have not shown any radical change. This analysis goes some way
to explaining why the 50,000 line system we referred to earlier takes
proportionately much longer than expected: we did not account for any
communication between programmers or the project manager.

By this stage you should be convinced that software development
represents some unusual challenges and that Software Engineering is a
discipline which requires study time to understand, so that any
involvement you have with the software life cycle is on a professional
level.
We will start that study by expanding on the work we did in chapter one,
when we described in outline the stages of the software development life
cycle. A software development lifecycle gives a framework for planning
and managing a software development project. It shows what should be
done, when and by whom. We will discuss which lifecycle model is best
for a particular situation and demonstrate the flaws in some popular
models, but it is important not to lose sight of the fact that without a
model, we have no framework for discussion and no means of quantifying
improvements. Life cycle models help us to change software development
from an ad-hoc craft into something that resembles an engineering
discipline.
4 Project Stages and Project Control
This section describes 13 different stages in the life cycle of a system.
You should not assume that all of these stages will always be apparent in
the life cycle of every system. We define and describe them in some
detail so that you will be able to share a common language with other
people and so that we can contrast and compare different ways of
combining and managing these stages in a real project. You will note
when you read books on software development that some authors identify
five main activities. We will cover each of the 13 here in order to help you
understand the full range of activities required in software development.
4.1 Strategic Study
Almost all business organisations have a strategic plan for developing and
continuing their business. Increasingly, a business needs to use IT to help
fulfil the strategic plans of the business. A strategy study is used to
determine what Information Systems are needed to support the needs of
the business and what Information Technology would be most appropriate
Study Note
We will use the Structured Systems Analysis and Design Methodology
(SSADM) as the basis for much of our definition of project stages,
although we are taking a wider view of the life cycle than SSADM. You
do not need to learn SSADM, indeed this would be a major
undertaking, but you should be aware that this is one of the best-
defined methodologies for Information Systems. Later in this chapter
we will discuss where you can obtain further information about
SSADM, if you are curious.

V2.0 3-9
to support those Information Systems. A strategy study such as this is
usually company-wide and driven by the corporate business plan. It is
often undertaken as a result of a review of business priorities and
processes. The product of this stage is an IT strategy.
4.2 Business Study
A business study is the first point at which specific business systems are
the focus of work, rather than the business as a whole. There are a
variety of different methods for exploring how business systems relate to
each other, and more importantly, how they could be improved. Most of
these rely on analysing the activities that are, or should be undertaken,
and what the outputs and inputs of each business system should be.
Why might a business study conclude that some current business
activities are not appropriate, and conversely, that some new business
activities are necessary?
If you find this difficult, think of the whole business as a system that has
an objective and contains subsystems that also have objectives.
If you still have problems, discuss the question with your colleagues.
The output from the business study is a definition of the required business
system in a very general sense; defined in terms of what it is intended to
achieve in business terms and how it relates to other systems, again in
very general terms.
The business study is the point at which a formal project plan will be
started. There are many project management methodologies, just as
there are many systems analysis methodologies. An example is PRINCE
(PRojects IN a Controlled Environment). We will discuss different
approaches to project management later, but an important part of
PRINCE is the Project Initiation Document (PID), which is produced at this
stage in the life cycle. Note that it is not usually possible to produce a
totally definitive project plan at this stage; not enough is known about the
project.
4.3 Feasibility Study
A feasibility study is a preliminary investigation of a project, to decide
whether it will be cost-effective, if it will realise the benefits that are
expected, and be technically feasible. A feasibility study is essentially a
mini systems analysis with some additional systems design and
investigation work. Feasibility studies are often criticised as being
unnecessary and delaying the start of the project. This is a mistake, since

we have already seen in chapter one and earlier in this chapter, that our
track record in completing system development projects on target is rather
poor. Often, that is because unexpected difficulties are encountered and
a feasibility study should try to identify all the possible eventualities which
may arise. A risk analysis is part of the study. It allows a better
appreciation of the risks that may be inherent in the project and then we
can plan to reduce those risks accordingly. As part of this process we
gain a better understanding of the time and resources that will be required
in the full project so that a more detailed and accurate project plan can be
produced.
A feasibility study might result in a recommendation not to proceed with
a development project.
Explain why this should be seen as a positive outcome.
If this happened, what options are there if we assume that the
business really does require a new system?
4.4 Requirements Analysis
Requirements Analysis is concerned with discovering what the new
system is required to do. Some outline requirements are already known
from the Business Study and the Feasibility Study, but these are by no
means sufficient to start building a new system.
SSADM, in common with many other structured analysis methodologies,
assumes that we start this stage by examining an existing system. This
provides a lot of information about how that system works and becomes
the basis of the requirements definition for the new system. Note that an
existing system does not necessarily mean a computer system; it could
be a totally manual system.
This is certainly not the only approach that can be used for requirement
analysis, as we shall see when we look at systems analysis much more
closely in the chapter covering this topic.
The output from this stage (if using SSADM) is a series of different
documents with models used to describe the existing system, and to
describe the business options that are available to implement the system.
Remember, in chapter 1 we mentioned the need to use models to
describe a system to the potential user.

V2.0 3-11

What happens if we do not currently use a computer system for the
business process? Does this mean that we have nothing to analyse?
4.5 Requirements Specification
The Requirements Specification stage, under SSADM, is concerned with
converting the output of the Requirements Analysis stage into a
specification that reflects what the new system is required to do. This
involves some further modelling activities which investigate:
The functions the system is required to perform.
The data that underlies the required system.
How data changes over time as a result of events.
Note the importance of data here. To provide information, we first need to
identify, and then collect relevant and accurate data. We also recognise
that the data we require may change over time. The use of models such
as these to define requirements is a key aspect of most structured
systems analysis methods. The intention is to provide a specification that
is as clear and precise as possible and which can be understood by the
business manager. The aim is to ensure no possibility of confusion. Once
delivered, it is pointless if the user says, thats not what I understood the
system would do!
This is critically important, as we saw in chapter 1. The use of different
types of models represents a way of describing systems. The difficulty
with any model is that it needs to be both understandable to the business
manager and at the same time, expressive and definitive enough to be
useful to the IT specialists.
This stage should result in the user signing acceptance of the
requirements for the new system, as identified and recorded by the
analyst.
4.6 Logical Systems Specifications
The fact that the Requirements Specification stage defines what the new
system is required to do does not mean that there is only one way in
which those requirements could be met. There may be several technical
options that could be adopted which would be capable of delivering the
required system. In this stage, the systems analyst first decides and
defines what those technical options are and then, with the help of the
business manager, selects the most appropriate. This interaction is

important; it reflects the idea (discussed in chapter 1) that the business
manager is controlling the development, and it is not controlled by the IT
function.
The typical question answered at this stage is, what type of computer (IT)
architecture (platform) is most suitable for the new system?
There is an obvious interaction between the available technical options
and the work done at the strategic study stage. Explain what this
interaction is and to what extent you believe the earlier study should
constrain the choices presented by the analyst.
4.7 Logical Design
This stage represents a fundamental switch in focus. Instead of
concentrating only on WHAT is required (systems analysis) we now start
the process of deciding HOW the system can be designed. This process
of deciding how can be further broken down into a logical stage and a
physical stage. Logical design (this stage) is concerned with how the
system will work, without too much notice being taken of the choice of
technical architecture. A logical design could, in theory, be implemented
on a different type of computer platform without needing total revision.
SSADM includes aspects such as:
Dialogue design the screen interface with the users of the system.
Update processes processes that change the underlying system
data.
Enquiry processes the extraction of useful information from the
systems data.
Logical design should involve the business manager at each stage. Time
invested now can save time later. Dialogue design in particular, will
influence how the system looks and behaves to its users. This has
become more and more important over time, particularly with the
continual advance in the sophistication of Graphical User Interfaces such
as that offered by Windows.
4.8 Physical Design
Physical design is the stage where all the design decisions which are
dependent on the physical system architecture are made. The primary
users of this work will be the programmers who will implement the design,
so it is important that the physical design stage provides all the
information that they will require.

V2.0 3-13
In many larger projects, physical design performs an important additional
function. It shows how the process of implementation can be broken down
into a number (perhaps many) of logically independent chunks. This is
important from a project management viewpoint because the total elapsed
time for the project can be reduced if the programming team can be
working on many different parts of the system in parallel. This is only
possible if the system design is well-defined.
Physical design is also the first point at which practical steps can be taken
to ensure that the performance requirements of the system will be met.
Performance in this sense usually means how quickly the system can
perform key processes. This is dependent on good physical design more
than on any other factor. You will be aware that the design for the storage
of data held on the Internet is vital to ensure the rapid response we all
expect from search engines (e.g. Google).
The result of the physical design stage depends on the methodology
being followed. A very typical output is a series of minispecs (miniature
specifications) that an individual programmer can work with to produce
appropriate code. SSADM defines a whole series of products for this
stage, which achieve the same result; to provide the programmer with
unambiguous definitions of what they must produce. This is the last stage
defined by SSADM.

With some types of systems, particularly those that require very
innovative design such as engineering, scientific and multimedia, system
design are likely to involve research into appropriate algorithms.

4.9 Coding
The structured approach we have described above leaves very little
creative space for the programmer. The role is simply to convert the
specification into efficient, maintainable program code according to the
Study Note
You might think that performance depends mostly on the speed of the
hardware used. This certainly matters, but a poor physical design can
make even the fastest processors look like ten year old PCs.
Analysing designs so as to achieve a reasonable performance, whilst
not compromising good Software Engineering principles, is a significant
skill. It often requires some deeper mathematical analysis and a full
understanding of the platform selected.
Definition
Algorithm a set of precise instructions or rules for carrying out a task
or working out a mathematical problem in a finite number of steps.

standards that are used by the organisation. In many projects, particularly
for commercial data processing type systems, that will certainly be the
case. Most of the program code will be essentially repetitious, perhaps
focusing on managing screen interaction and some underlying
processing. This is where modern programming languages are helpful,
since they are optimised around being able to code this type of
processing with the minimum of effort.
We pointed out that not all projects are like this; those that require
innovative algorithms will be much more of a challenge to the
programmer, indeed the distinction between system design and
programming is typically blurred in these systems.
Coding is not normally carried out in one enormous, single chunk.
Usually and preferably, program code is written in short pieces that carry
out a single, well-defined function. These program units are then
integrated together. This has consequences for the testing phase, which
we will review next.
4.10 Testing
There are several different forms of testing. The first of these, Unit
Testing, is usually undertaken by the programmer responsible for the
program unit. As the system is assembled, further testing is carried out
on the system again, typically by the programming team. Eventually, the
whole system is ready for testing as a system.
Further testing may be carried out by another test team and/or by the
business function for which the system was developed.
Testing is a large and very important part of the development life cycle.
The whole of a later chapter is devoted to this area, so we will consider it
only as part of the life cycle in this chapter.
4.11 Implementation
Introducing the new system to the working environment.

Study Note
You will see two uses of the word implementation concerning the
systems development life cycle. In many Software Engineering
textbooks, implementation essentially means the same as coding. To
most business managers, implementing a new system means the
stage when it is introduced to the working environment. You need to
bear in mind the other meaning when doing any follow up reading.

V2.0 3-15
The implementation stage consists of many connected activities:
New computer equipment may be needed. If so, this will need
specifying, ordering, installing and testing.
Users need to be trained, often on a special isolated training system,
where no damage to real data can be done.
The new system is installed on the target computer system.
Data may need to be transferred from an old system.
New data may need to entered.
The old system and the new system may need to run in parallel for a
period to ensure the new system is performing correctly.

The implementation phase is typically terminated by a formal acceptance
process, when the business manager declares that she/he is satisfied that
the system meets its objectives and sign off takes place.
A formal acceptance in an external development (i.e. where another
company has developed the system) usually triggers a payment. This
is not usually the case in an internal development project, but a formal
acceptance is still often required. Comment on why you think this is
so.
4.12 Maintenance
The maintenance stage begins once the implementation is complete. We
dealt with some of the issues of the maintenance stage in chapter 1.
Recall that maintenance in Velotec is carried out as a part-time activity by
programmers. This is typical of many medium sized organisations. In
larger companies, a full-time maintenance team may carry out all this
work. Maintenance includes error fixing, updates and modifications which
are necessary because requirements are incorrectly understood or
specified, requirements analysis is not completed in time, and the needs
of the business have changed.
Assignment to a maintenance team is widely seen as a backward
career step by many programmers. Why do you think this view is
held? If you were the IS Manager of an organisation that had such a
maintenance team, what would you do to maintain their motivation?

4.13 Phase Out
Phase out occurs when it is no longer feasible to continue using the
system and it is discontinued in an orderly fashion. There are several
reasons why phase out occurs:
The maintenance costs for the system have risen to the point where
there are more economical alternatives.
The needs of the business or the legislative environment have
changed and it is not possible, or financially justifiable, to modify the
system to meet the new requirements.
The company adopts a new IT strategy that identifies a different
platform (hardware and operating system), on which the application
will not run.
With application packages, the original supplier may cease operating
or withdraw their support. This can make the continued use of the
system untenable. You can reduce the risk by purchasing only from
the largest software suppliers, but even this is not a complete
guarantee. The use of an escrow service can also be helpful in
reducing the impact of this type of problem.
Escrow is a process where an independent provider holds a copy of the
software package, with the supplier's agreement, on behalf of the
customer. This ensures that if the supplier's business fails or they do not
maintain their contractual obligations, the software can be accessed and
legally released to the customer, allowing the customer able to continue
business operations without disruption.
5 The Waterfall Life Cycle Model

The Waterfall life cycle was the first attempt at a definition of a software
development life cycle. The diagram in Figure 3.2 is typical of this type of
life cycle model. Notice that only a few of the stages we previously
Requirements
anal ysis
Requirements
Specification
System Design
Code & test
Maintenance
Implement
Figure 3. 2 Waterfall Life Cycle Model

V2.0 3-17
identified are shown in the model. This does not invalidate the model, we
could easily extend it to include all of the stages. As we saw in chapter 1,
it makes several assumptions about how a software development project
is managed:
It is possible to divide project activities into discrete, isolated stages.
Each stage is completed before the next one is started.
Each stage relies on the information produced by the previous stage,
and only on that stage.
A project plan can be constructed, based on milestones, represented
by the completion of each stage.
The Waterfall model is not a good representation of what actually
happens in most projects, and several of its assumptions actually lead to
poor project management practice:
The Waterfall model assumes that all of the system is developed at
the same time. This may seem reasonable, but it is quite possible to
code and implement parts of the system in series. In effect, we loop
around these stages until the whole system is available. This has
some advantages, as we will see later.
Project activities are usually not as clearly defined and discrete as the
model implies. Very frequently, work in one stage overlaps another
stage, either deliberately or because of problems encountered.
Sometimes it is necessary to repeat or iterate a group of project
stages in order to fully understand or complete an aspect of the
system. This is particularly true of the systems analysis stages.
There is a relationship between stages that are not next to each other
in the waterfall, but this is not apparent from the model.
The involvement and exposure of the system to the owning business
managers is not clear from the model.
The Waterfall model focuses most strongly on the activities that are
performed in each stage. Most modern project management
methodologies emphasise products (what is produced) rather than
stage based activity. This gives a much better basis for the
management of quality.
6 The V Model

The V model rectifies some, but not all, of the problems that we noted with
the Waterfall model. In Figure 3.3 we see that the life cycle still lacks
some of the stages that we defined in Section 4, but it could be extended
to include them all without losing any generality. The immediately
apparent difference is that products are identified at the end of each
stage. This is a significant improvement, but the V model takes this idea

further. It shows how there is a relationship between the products at the
early stages of the life cycle and the later stages. The V model lines up
these products on either side of the V, making the relationships clear.
The placement of coding at the bottom of the V also emphasises the
activities that lead down to this from the initial concept, and the activities
that lead up from this to the deployed system and into the maintenance
stage.
6.1 Testing - Why and When
The V model is particularly strong in the way in which it depicts verification
and validation.

The V model shows how verification and validation activities are built on
work done at a different stage of the life cycle. For example, the tested
system should be based on the requirements specification. The V model
therefore shows us what we should be testing at each stage in the life
cycle and for what reason. We will further develop these ideas in the
chapter on testing.
Tested modules
System design
Requirements
specification
Acceptance test
Maintenance
Tested
system
Integration and test
Code and unit test
Initial concept
Software design
Requirements definition
Detailed design
Tested software
Tested system
Tested software
Tested
modules
Module design

Definition
Verification and Validation these are such important ideas that we
need a formal definition, and the definition we will use was originally
introduced by B Boehm, a very important Software Engineering
pioneer:
Verification: Are we building the product right?
Validation: Are we building the right product?
Figure 3. 3 The V Model

V2.0 3-19
7 Velotec Training History System
Now we need to turn attention from theory to practice, with a small
Velotec case study which will help you pull together some of the ideas we
have discussed.
Velotec offers rapid fitting of brakes and other critical parts. There is
clearly a potential risk in this type of business because an error by one of
the workshop fitters could easily cause a fatal accident. Velotec carries
insurance against this type of risk, but it is still important that the business
trains its fitters correctly, confirms (validates) their qualifications on
appointment and monitors their work. Failure to do this could be
considered negligent. All the training is organised from within the Human
Resources (HR) department and is carried out by specialist training
companies which are not part of Velotec. Workshop fitters join and leave
very frequently, so it is quite difficult to keep training records up- to-date.
The HR Director commissioned a training tracking system to help HR staff
keep track of these courses and qualifications. The development project
was planned and managed using a simple linear Waterfall model. The
system was delivered late, considerably over budget and the users did not
feel that it was useful.
The project manager faced two major issues during the project. At the
end of the requirements analysis stage, the systems analyst recorded the
fact that the users views of the system requirements seemed to be
particularly dynamic, in fact every meeting seemed to introduce new and
radical ideas about what the system should do, and particularly about how
information should be displayed. The analyst was urged by the project
manager to get on with the specification so that the users would have
something concrete to discuss.
At the end of the requirements specification stage, the business manager
was asked to sign-off the specification as representing a definitive
statement of the HR department requirements. The HR Director was
reluctant to do this because, as he said, We keep getting better ideas
about how we will use this system, and in any case my staff are unsure
what these models really mean.
Eventually the project manager persuaded the HR Director (business
manager) to sign-off the specification, on the basis that if this was not
done, the project would come to a stop and delivery would be late.


If you were the project manager, what would you have done to resolve
the problems?
To what extent is the life cycle model a contributory factor in creating
the problem? What other changes do you think would be beneficial?
Complete this exercise before continuing.
8 Prototyping
As you saw in the previous section, a rigid linear life cycle model has
some serious drawbacks in real life. The V model, although better than
the Waterfall model, still has some of the same problems. We will explore
some more radical approaches to the life cycle model later, but first we
need to address one of the other problems encountered in the Velotec
Training History System.
The HR department had problems understanding the requirements
specification, and they were dissatisfied with the attention given to the
application user interface. This is a very common problem, and one
effective solution is the use of prototypes. A prototype is a simplified
subset of the proposed system that simulates the actual processing that
will be carried out by the real system. Typically, it consists of a few screen
designs and reports that provide just sufficient functionality to allow users
to experience how the proposed system might look and feel.
Prototypes are easy to create, particularly with the Windows and modern
GUI tools. There are specialised prototyping tools available.
Prototypes have many benefits:
A prototype can very quickly resolve misunderstandings between
business managers and analysts.
A prototype makes an ideal tool for defining and discussing user
interaction. Some prototyping tools are so fast and flexible that
changes can be made whilst in discussion with a user. This can
become a very powerful way of identifying requirements.
Users can understand a prototype far more easily than most of the
standard ways of communicating requirements in the form of models.

Prototypes also have some drawbacks:

V2.0 3-21
Business managers may not understand the purpose of a prototype,
which in the form we have described is only intended to assist with
defining requirements.
Some prototypes are so realistic that they give the impression that the
project is almost finished whilst still at the systems analysis stage.
This can put severe pressure on the development team.
The effort required to produce a prototype may lead to the
development team using it as a part of the new system. This can lead
to quality problems with the resulting system, unless the prototype is
designed to meet that objective and the life cycle is suitably modified.
We will discuss this possibility later.
9 Velotec Product Data Management System
Now let us see how the idea of prototyping works with another Velotec
case study. This one concerns the High Performance Products Division.
The manager of the division had a major problem with the parts being
produced for motor racing teams. These have to conform to some
extremely complex rules, and every part must be tracked through all its
design and production processes to ensure that it complies both with the
customer specification and the rules.
The customer specification is a mixture of engineering drawings,
submitted in Computer Aided Design format, extensive written material
and spreadsheets containing numerical data. Keeping all this information
in synchronisation was a major problem, absorbing a lot of clerical effort.
What was required was a system that could bring all of this under control
and that could be used to track parts and solve problems whilst talking on
the telephone with the customer.
This project used a V model life cycle, with extensive prototyping at the
requirements specification stage. The High Performance Division
Manager was eventually satisfied with the prototype (although it seemed
to take a long time to get to this point) and signed off the complete
specification.
During system design, it became obvious that the system could be made
very modular, with a complex database design underlying a whole series
of fairly simple front-end GUI based applications. This was the solution
adopted and the development team proceeded to complete all of these
modules.
Six months later the finished system was ready for acceptance testing.
By this point, nearly a year had passed and the business manager
refused to accept the finished system, although it met all the requirements
he had agreed and signed off. The reason was simple; there had been a
fundamental rule change that meant that a lot of new safety related

information was needed. The existing system would be useful only for
about two months and then would require a complete redesign.
If you were the project manager, what would you do to avoid this type
of problem in the future?
There are a few clues in the case study, but you need to think about
the nature of the development life cycle to write a good answer.
Do you think this type of problem is likely to be more or less common in
the future?
Comment on whether the manager of the High Performance Division or
the project manager should accept the blame for this disaster.
Complete this before continuing.

10 Rapid Applications Development
The problems we found in the previous case study point out the need for
a different type of life cycle. It is now unacceptable for development
projects to run for several years without delivering usable products.
Businesses move much too quickly to allow a specification to be frozen
after a long period of systems analysis, only for another long wait for a
usable system and then to have only a short period of effective
deployment before a major revision is needed.

Iterative development is one response to this problem. In this life cycle
we explicitly recognise that the history of a system is not linear. The
maintenance stage leads to a review stage which examines the relevance
of the system and compares this to the IS and IT strategies. This can then
Systems analysis
Requirements analysis
Initial strategy
Feasibility study Review
Maintenance
Implementation
Testing
Development
Design
Specification

Figure 3. 4 Iterati ve Development

V2.0 3-23
lead directly into another development cycle, should it be shown that the
system is still viable, but needs updating.
This is helpful, but it would not solve the problem that we saw in the High
Performance Division life cycle.
Rapid Application Development, or RAD, is a more radical approach
which has gained a lot of strength over the past ten years. It started from
a realisation that development does not need to proceed in the big bang
waterfall style. It is better to produce some of the system as early (as
rapidly) as possible.
Along with this idea of iterating through the design, code and test cycle
many times, is the view that prototyping is essential to obtain valid
systems that will be effective and that will be owned by business users.

Figure 3.5 shows both of these ideas (iteration and prototyping).
RAD has been enthusiastically received by many organisations. Its
impact has moved beyond a simple life cycle model and there are now
many RAD software tools available. These typically concentrate on the
coding and prototyping part of the life cycle, but they are certainly capable
of producing rapid results when used by experts.
The life cycle shown in Figure 3.5 is very general and there have been a
number of attempts to produce a full methodology based on the RAD
ideal. One of the best of these is the Dynamic Systems Design
Methodology.

Figure 3. 5 Rapid Development
Code
Integration
test
Unit test
Design
Prototype
Requirements
analysis & spec.
System&
acceptance test


We will not attempt to describe the DSDM in detail, since this would
require much time and space. The point is to make you aware that there
are other, more complex, models.

11 The Spiral Life Cycle Model
The final life cycle model we will describe is the Spiral life cycle model.
This was originally proposed by Boehm (1988). It extends the ideas of
prototyping and iterative development, but it also recognises that one of
the major problems faced in any development project is an initial lack of
understanding of the scope and technical difficulty of the project. The
Spiral life cycle model explicitly includes a risk analysis stage at each
rotation of the spiral. The risk analysis provides the information needed to
help the business managers decide whether to proceed.

Web Pointer
Not required for this module, but if you are interested, information
about DSDM and access to some case studies is available on:
http://www.dsdm.org
Figure 3. 6 DSDM
Implement
User
approval &
user
guidelines
Train users
Review
design
prototype
Design and Build
Iteration
Create
functional
prototype
Agree schedule
Identify functional
prototype
Agree
schedule
Feasibility
Business study
Review
business
Identify
design
prototypes
Review
prototype
Create
design
prototype
Implementation
Functional
Model
Iteration
.
2
1
3
1
2
3
2

V2.0 3-25
The final loop of the spiral is effectively equivalent to a conventional
Waterfall linear development life cycle. However, by the time this is
reached, the development team (and the business manager) will have a
very good understanding of the problem they are attempting to solve and
the requirements for the new system.
The Spiral life cycle model is particularly suitable when object-oriented
analysis, design and programming techniques are used. A later chapter
will explain the reason for this.
12 Summary
We have examined the software life cycle development model, starting
with the definition of its components and then using them in the simplest
of all life cycles, the Waterfall model.
We saw that this model has numerous problems and does not provide
good project management practice.
We can improve on the Waterfall model in a number of different ways,
and we have discussed several of these.
We used two case studies to both illustrate the problems of the Waterfall
model, and to introduce the ideas of prototyping and iterative
development. These themes are the foundation for the two most modern
life cycles we described, the DSDM RAD approach and the Spiral life
cycle.

Figure 3. 7 Spiral Life Cycle Model

In later chapters we will concentrate on specific parts of the life cycle, but
we will keep coming back to the life cycle as the structure on which all
development projects are based.
13 Self Study
Not compulsory, however for those who are interested, the DSDM
website is useful for reading about RAD. You will find that there is a
range of papers covering the thinking behind the method and success
of its application. This research will help you to understand the material
that we have covered on life cycles and expose you to some thinking
about software development.

V2.0 3-27
14 Answers
Answer 3.1
There are no specific answers to this exercise. However by completing
the exercise you will have learnt how to:
carry out some basic research
summarise your findings
discuss and debate issues with fellow students.
You will of course have identified that there are many large IT projects
which have failed to meet expectations, are late and over budget. This
has given the IT profession a poor name within the population and media.

Answer 3.2
It is common to find that the different parts of a business have objectives
that are in conflict with each other and even in conflict with the overall
objectives of the organisation. It is also common to find that the overall
business objectives implicitly require a particular set of business functions
that currently do not exist.

Answer 3.3
This is what a feasibility study is for! It is much better to abort a project at
this stage than to continue and experience major and costly problems at a
later stage. An obvious option is to commission the project from an
external software supplier rather than carrying it out internally. If you
choose this option, you should think carefully about the reasons that led
you to abandon the internal project and whether they might apply equally
to an external supplier.

Answer 3.4
We are using the word system in the broadest possible way. This means
we can analyse a manual system just as easily (sometimes more easily)
than an existing computer system. If there really is no existing system of
any description then we obviously cannot analyse it, but this does not
prevent us from completing the rest of the systems analysis activities.


Answer 3.5
The IT strategy defines the hardware needed to implement the required
Information Systems. It usually defines a preferred architecture for all the
systems that the business uses. It should be enforced rigorously to
prevent confusion and a division of effort amongst many different
platforms. The technical options suggested by the systems analyst should
therefore be consistent with the IT strategy, unless there are compelling
reasons for them not to.

Answer 3.6
This is to some extent a side-effect of the Waterfall life cycle model,
where by implication, every stage must be completed before the next
stage starts. A good way to close a stage in a project is to request a
signature from an authorised person; this is often referred to as a formal
sign-off. This is sometimes a problem when a truly collaborative approach
is used in an internal development project, quite apart from the problems
that are inherent in the Waterfall model.

Answer 3.7
Maintenance programmers rarely have the chance to do anything new.
They become very familiar with the same applications, but do not get the
opportunity to show how they could write better code and be creative.
Unfortunately, we need maintenance programmers even more than we
need programmers who write code anew, so as the IS Manager, you
might consider rotating maintenance teams or at least giving members of
such teams the opportunity to take part in new projects occasionally.

Answer 3.8
Both the business manager and the project manager were being a little
irresponsible in this situation. No project can afford to be extended
indefinitely while requirements are settled, but the Waterfall life cycle
model just makes this problem infinitely worse. The model essentially
says that the project cannot proceed until the requirements are made
watertight, which is rarely achieved. Another contributory factor was the
lack of understanding of the models produced by the analyst. This
situation would have been helped if the systems analyst had used some
examples of how the system might look and feel (prototypes) rather than
the abstract models. A more flexible and realistic attitude to the project
life cycle would also have helped to avoid some of the problems.

V2.0 3-29
Answer 3.9
Any set of business requirements is sure to change, because every
business has to adapt to its environment. The rate of change is much
higher in some cases than others. In this case, we have an extremely
high rate of change. This should have been recognised at the outset and
an appropriate development methodology adopted. It would have been
better to have at least some of the functionality early in the life of the
project rather than all of it in a big bang at the end, and in this case, too
late to be useful. This type of problem is certain to become more and
more common, simply because the pace of business increases all the
time.
The eCommerce revolution is accelerating this trend.
Allocation of blame is a common, but usually pointless product of any
software development problem. In this case, both the project manager
and the business manager should have recognised the issue of rate of
change much earlier, but they were both constrained by a development
life cycle that was imposed by the organisation and gave them no
opportunity to operate in a different way.


V2.0 4-1
Chapter 4
Software Analysis and Design Methods
2 Introduction..................................................................................................4-2
3 Analysis and Design Methods......................................................................4-2
3.1 What is in a Method? .........................................................................4-3
3.2 Structured...........................................................................................4-3
4 Modelling Techniques..................................................................................4-4
4.1 Data Modelling...................................................................................4-5
4.2 Data Flow Diagrams ..........................................................................4-6
4.3 Entity Life Histories ............................................................................4-9
5 A History of Methods at Velotec .............................................................. 4-11
6 Some Traditional Methods.........................................................................4-12
6.1 Structured Systems Analysis...........................................................4-12
6.2 J ackson Structured Programming...................................................4-13
6.3 SSADM............................................................................................4-14
7 Object Technology.....................................................................................4-15
7.1 Objects.............................................................................................4-15
7.2 Object Oriented Analysis and Design..............................................4-16
8 Program Specification................................................................................4-17
8.1 Pseudocode.....................................................................................4-17
8.2 Structure Diagrams..........................................................................4-18
8.3 Structured Flowcharts......................................................................4-18
8.4 Decision Tables...................................................................................19
9 Summary....................................................................................................4-22
9.1 Self Study.........................................................................................4-22
10 Answers .....................................................................................................4-23

Chapter 4 Software Analysis and Design Systems Development

Analysis and design methods.
Popular structured design methods, including object-oriented design.
Modelling techniques.
The use of software design methods.
Methods for specifying design including pseudocode, structure
diagrams, structured flowcharts and decision tables.
2 Introduction
We have seen how Software Engineering attempts to turn what was a
craft discipline into an engineering discipline. We have seen how a
software development life cycle gives us a framework for considering and
needing to identify a suitable development process. The heart of that
development process is the analysis and design of applications. This
chapter is devoted to that part of the process.
3 Analysis and Design Methods
In a craft discipline, there is no clear, written definition of process. In
order to learn how to produce something, you watch and imitate a master
craftsman, and after a long period of time you are able to produce the
same types of products. We have already seen that this is ineffective for
software development and that we need an engineering approach. This
requires us to define and refine a process that will result in a good quality
project. The way in which we carry out the process is a method. To be
precise; a method is a particular technique or procedure; and a
methodology is a range of such methods brought together into a
formalised and disciplined approach.
Analysis methods are those we use during the requirements analysis and
requirements definition stages.
Design methods are used during the system design stage and are closely
aligned with the coding activity that follows.
Systems Development Chapter 4 Software Analysis and Design

V2.0 4-3

3.1 What is in a Method?
There are hundreds of methods and an increasing number of
methodologies.
How can we distinguish between them and choose the most suitable for
our purposes? It does not take much effort to design a method, and just
because a method is documented does not mean that it is actually useful.
We really need a guide to help to distinguish between methods, but failing
this, some guidelines may help:
Look for a method that is widely used.
Look for a method that is adopted by governments and other
important organisations.
Look for a method that is freely available, not proprietary.
Look for a method that reflects modern thinking about life cycles.
In a work environment, the task of selecting a method and methodology
will usually have been completed and standards adopted which all those
involved in the software process will be required to follow.
3.2 Structured
We have used the word structured without being specific about what we
mean by it. In order to understand the importance of structure in program
design, programming, and of course systems analysis, we need to know a
little about development practices before the software industry became
aware of the need for software engineering.
Some analysis of requirements would be undertaken which resulted in a
large, written specification for a system. This would be in a conventional
written essay style, using whatever language seemed suitable to the
analyst. The extreme length and ambiguity of this specification would
make it almost untestable and unlikely to be meaningful to the business
manager. That usually did not matter much because the business
manager was not expected to understand it.
Usually the programmer(s) would work directly from this document, with
no intervening design stage. The programming language would itself be
unstructured and the programmers would write code usually involving
many pages. The programmers would write their code in whatever style
they preferred, including what we would now consider extremely bad
practice. An example of this is a feature of most programming languages
of the time a program statement that allowed the program logic to jump
to any place in the program (the GOTO statement). Most programmers
felt that this was necessary for them to do their work, but even moderate

use of this technique produced programs that had many paths and
strands, often referred to as being like a bowl of noodles.
The result of this would be a system that would be totally
incomprehensible, even to the programmers who produced it, and virtually
impossible to maintain throughout its remaining life.
In the 1960s, two early software engineers, Bohm and J acopini, wrote a
very influential paper where they showed that every possible system and
every possible program requires only the following three types of
construction:
Sequencing - one procedure follows another in strict sequence.
Selection - if some condition occurs, do one procedure, otherwise do
another.
Iteration - while some condition remains true, repeat some
procedure.
From this idea came a set of rules about how programs should be written
to avoid the noodle problem.
The idea that structure would help avoid complexity and obscurity, led to
the realisation that there are similar types of structures that can be used
universally to represent system design and system specification. These
were obviously preferable to the totally ad-hoc methods used in the earlier
days of systems development. Research undertaken by a variety of
experts led to structured programming, structured design and structured
analysis. All of these techniques employ models of different types that
allow us to define structures in a way that is easier to comprehend and
most importantly, to test.
4 Modelling Techniques
There are a small number of modelling techniques which appear in many
structured methodologies. We need some familiarity with these and the
way in which they are used. We will use the SSADM version of each of
these modelling methods in order to explain them. This does not reduce
their generality; it simply provides a coherent framework for our
description.

V2.0 4-5
4.1 Data Modelling

This modelling technique is used to show the things or entities that are of
importance in a system and how these entities relate to each other. A
relationship shows how one entity relates to another entity and how many
occurrences of one entity relates to another entity. Data models such as
this are the standard way to show the complete picture of the data used
and stored by a system.
This model shows the relationships between books, authors and
borrowers in a library system. Each of the rectangles represents an entity.
The lines between the boxes represent the relationships. A line with a
fork on the end (similar to the foot of a bird and within SSADM known as a
crows foot), represents a one-to-many relationship. For example, the
diagram says that a book is borrowed by many borrowers and an author
writes many books. As you can imagine, this model could easily be
understood by the business manager, in this case, the librarian. Models
can be much more elaborate than this, but the most important idea is the
simple one of entities and relationships. Models like this are used in the
analysis of existing systems, and form part of the specification of the new
system. The model will be used by the programmer and especially the
Database Administrator who is responsible for setting up the database
that underpins the new system.
Definition
Entity any item, such as a data item or statement, which can be
named or denoted in a program. In a practical sense, an entity is
something the business organisation wants to keep. (In a library, an
entity would include book, borrower, loan, reservation).

Figure 4. 1 Data Model
Book
Borrower
Author

4.2 Data Flow Diagrams
Data Flow Diagrams (DFDs) show how data moves in a system and
where it is stored. Data flow diagrams were one of the first types of
models and they are a fundamental building block of many analysis and
design methodologies. There are many variations in the diagramming
rules and conventions, but we will keep to the SSADM variant.

This data flow diagram shows some of the processes which may occur in
a book lending library.
The large rectangular boxes (e.g. reception desk) represent data handling
processes. They accept some input, change it in some way and output it
to somewhere else. The title bar of the box specifies where the process
is done. The number to its left is a process number. The process numbers
do not indicate anything significant in terms of sequence or timing. The
main body of the rectangle defines the process in simple, active terms.
The ovals represent external entities things that are outside the system
but that communicate with it in some way. Each of these has a name.
Notice that member occurs twice in the diagram and has a slash in the
top left hand corner of the oval. The slash confirms that this is the same
entity drawn twice. The duplication is for neatness and simply to avoid
having lines crossing over other lines that would make the diagram look
more complicated.
The thin rectangle is a data store. This is a place where data is held for
use at a future time. There are various types of data store, signified by the
letter in the left hand box:
M represents a manual data store like a card file.
D represents a computer data store, such as a database file.

Figure 4. 2 Data Flow Diagram
Completed
application form
Person Apply for membership
Librarian
Member
Membership card
Reception desk 1
Change member
details
2
Delete member
details
3
Librarian
Detail changes
Member
Member left
M1 Member file
M1 Member file
Application form
Produce
membership card

V2.0 4-7
Data flows are represented by arrows. Each arrow represents a specific
type of data. Each data flow is uni-directional, i.e. travel is in one direction
and it cannot have heads at each end.
Flows from external entities into the system cause a process to be
triggered. We can see this in the case of Apply for Membership and
Detail Changes.
There are some rules we have not described that define which
connections are valid and which are not. These are all really common
sense restrictions and we will not describe them in detail. One very
important feature of a Data Flow Diagram is that it forms part of a
hierarchy of such diagrams. The whole system can be defined by one
single DFD called a Context Diagram, as in figure 4.3.

This is the context diagram for a whole library system. Notice that we
have only one process, book processing, and three external entities. The
process represents the whole system, but it does not tell us much about
how it works (or should work). The strength of DFDs is that we can take a
process such as this and decompose or break it down into sub-processes
or systems.

Study Note
A useful way of thinking about DFDs is as Data Models in Motion.
There is an obvious relationship between the two types of models.

Figure 4. 3 Context Diagram
Supplier
Chief librarian
Member
Book processing
Delivery
New book
orders
Reserves
book
Returns
book
Borrows
book
Joins
library
List of old books


Exercise 4.1 1 hour
The IS Manager of Velotec has been asked to organise a study of the
exhaust fitting workshops. This might lead to a feasibility study for a
new business system. The manager suggests that a good starting point
would be the production of some data flow diagrams so that everyone
can agree on how the exhaust fitting operation works.
As a new member of the IS section, you are asked to produce a
context diagram. You interview the managers of two exhaust fitting
workshops and discover that:
Customers usually just arrive without warning and ask for their
exhaust to be repaired or a new one fitted.
Occasionally customers telephone to check if an exhaust system for
their car is in stock.
The workshop manager telephones the warehouse several times a
day to order new exhausts.
Orders are delivered in batches and also in single parts, depending
on the urgency. When exhausts arrive, they have to be signed in.
Exhaust fitters talk to the customers to find out what they want.
Sometimes two fitters are needed for a big job.
Head Office needs a daily sales return.
Fitters have to be trained, tested and certified frequently. This
requires a lot of paperwork involving the Human Resources
department.
To draw the context diagram, you will need to decide the boundary of
an exhaust fitting workshop. Then decide on what the external entities
are and how they communicate with the system.
Draw the context diagram, and then pair up with one of your
colleagues. Explain your context diagrams to each other and defend
your choices. What did you learn from this exercise?
Definition
Decomposition the analysis of a problem into simpler sub-problems.
Remember, the way to tackle a large job is to break it down into
manageable parts. The old question, how do you eat an elephant? You
cut it into small pieces.

V2.0 4-9

In figure 4.4 we see the context diagram we started with. The process box
becomes an entire DFD that contains further process boxes and so on.
This means we can describe any system in as much detail as we need.
The diagram shows that the lowest level DFD contains enough detail to
allow us to write a minispec which, as we mentioned previously, is the
document that a programmer uses to define his coding activity. A DFD
can be used both as an analysis tool, where it helps us to understand an
existing system, and as a design tool, where it describes the system the
business manager actually needs.
Minispecs are not strictly within the SSADM methodology, but they could
certainly be created in the way described, and often are.
4.3 Entity Life Histories
Entity Life Histories (ELHs) show how entities change over their life. This
is another form of life cycle, but based on an entity rather than a whole
system. Entity Life Histories are actually based on a J ackson Structured
Design technique, which we will review in the next section.

Figure 4. 4 Decomposition of DFD
Further detail
Lowest level DFD
Expands into
is supported by
Context
diagram
Expands into
Mini-spec

The ELH in figure 4.5 shows the life history of a book in a lending library.
There are three main stages in the life cycle of such a book. First it is
acquired, then it spends a long period available for use, and finally it is
disposed of. The life of the book always follows this strict sequence. The
acquisition stage can be accomplished by either buying the book, or by it
being a gift to the library. These are alternative events. The available
stage consists of many loans, which in turn consist of issue and return
events. The issue and return events are another sequence; they must
always occur in that order. Loan is a repetition there can be many
repetitions of a loan. Finally, a book can be removed from the library by
either selling or scrapping it. These are alternatives:
Sequences are represented by boxes; read left to right on the same
level.
Alternatives are marked with a small
o
in the top right hand corner of
the box.
Repetitions are marked with a small
*
in the top right hand corner of
the box.
There are some additional features of ELHs which can add more
expressiveness and remove clutter from complex diagrams, but the
simple ideas we have introduced are sufficient for many models.
Note in this simple example, we have not covered all possibilities in the
diagram. It is possible a book could never be returned by a borrower (lost
or stolen), a book could be stolen from the library and never go through
the loan process. These exceptions or risks should be identified, as
discussed in the previous chapter. One of the reasons a stock check is
carried out by business organisations is to verify their records (computer
or paper based) with the physical stock.

Figure 4. 5 Entity Life History
Library Book
Acquire
Available Remove
Buy Gift Loan
Issue Return
Sell Scrap
o o * o o
Sequences are represented by boxes
read left to right on the same l evel
Alternatives are marked with a small
o

in the top ri ght hand corner of the box
Repeti tions are marked with a small
*

i n the top ri ght hand corner of a box

V2.0 4-11

Exercise 4.2 1 hour
The IS Manager of Velotec was so impressed with your context
diagram that he decides to test your capabilities further. He asks you
prepare an ELH for the entity exhaust component. J ust as before, you
interview the same two workshop managers and discover the following:
Exhaust component is a very vague description. It could be nuts,
bolts and washers, a silencer or a catalytic box worth hundreds of
dollars.
All parts are ordered from the warehouse. They arrive singly or in
batches.
When they arrive, they are inspected. If they look fine, they are
taken into stock and placed in racks or storage bins, depending on
their size.
When a customer needs a part, it is taken from storage and fitted.
If it is anything other than a standard component such as a nut or
bolt, the stock used is recorded.
Sometimes stock becomes obsolete because that model of car
becomes too old and there are too few customers. In that case, the
part is usually just withdrawn from stock and scrapped. Some parts
can be reclaimed and these are sent back to the warehouse.
Draw the ELH, and then pair up with one of your colleagues. Explain
your diagrams to each other and justify your choices. What did you
learn from this exercise?
5 A History of Methods at Velotec
Most system development projects undertaken by Velotec have not used
a recognised methodology, but they have used some of the techniques
we have described, particularly data flow diagrams.
The previous IS Manager took the view that using a methodology such as
SSADM was a waste of time because:
It would mean a large training program both inside the IS team and for
business managers.
Many of the stages and detail involved in SSADM are unnecessary.
What really matters is getting started with coding as soon as possible.


Put yourself in the position of a new project manager wanting to use a
standard methodology. Think of arguments which support the use of a
standard methodology and decide how you would present them to the
IS Manager in order to change his mind.
As a result of the persuasive argument of a courageous project manager,
Velotec adopted a rather more structured approach, although not with the
full rigour of SSADM.
The engineering departments were extremely concerned about this
change. They claimed that structured methods are designed to suit data
processing applications, not their typical requirement for number
crunching systems.
Put yourself in the position of the IS Manager. Think of arguments you
could use to persuade the engineers of the merits of a structured
methodology even for such number crunching applications. Do you
agree with these arguments?
6 Some Traditional Methods
6.1 Structured Systems Analysis
One of the earliest structured methodologies was produced by Chris
Gane and Trish Sarson in 1977.

Gane and Sarson showed how various techniques can be used in a
coherent way. The techniques they describe are:
Data Flow Diagrams - using a slightly different notation than the
examples we have given.
Further Reading
There are many texts on structured systems. One which was written for
computer science students is: Practical Business Systems Using
SSADM
Philip Weaver ; Nicholas C. Lambrou ; Matthew Walkley
PRENTICE-HALL ; ISBN 9780273655756

V2.0 4-13
Data Dictionary - a definition of all the data entities in the system and
their internal structure.
Decision tables and decision trees.
Structured English and pseudocode.
Normalisation of data.

This chapter provides an awareness of the method and does not attempt
to cover all of the techniques.
In summary:
Decision trees are a way of depicting a series of logical cases,
graphically. They cover the same conceptual area as decision tables,
but decision tables are rather more practical for most real-life
situations.
Structured English provides the same type of specification of program
logic as pseudocode (which we will describe later), but with a slightly
different approach to structure.
Normalisation of data is a very important technique which ensures
that data is structured in such a way that we avoid redundancy, we
can process it simply and effectively, and we can obtain information
from it without introducing errors or logical traps.
6.2 Jackson Structured Programming
J ackson Structured Programming (J SP) was developed by Michael
J ackson (not the singer!).This is essentially a system design methodology
that transforms a problem structure into a program structure which can
solve the problem.
The methodology has three stages:
Stage 1 model the problem by defining the input and output data
structures, using the tree-like structure we have seen used in the
ELH. This is no coincidence, ELHs are based on the original work by
J ackson and his notation.
Stage 2 transform the input/output models into a structural model for
the whole system by looking for points of correspondence between
items in the input and output structures.
Stage 3 expand the structural model into a detailed design model
that specifies all the operations needed for the complete system.
J SP uses the hierarchical modelling technique very intensively. The final
part of Stage 3 however, uses a form of pseudocode to define the detailed
program design.

6.3 SSADM
Structured Systems Analysis and Design Methodology (SSADM) has
been used widely in UK and in other parts of the world for many years. It
dates from work carried out in 1980 by the Central Computer and
Telecommunications Agency (CCTA), and was supported for many years
by the NCC with a variety of manuals, training courses and books.
A very comprehensive methodology defines the analysis and design life
cycles in terms of modules and stages. A variety of techniques are used
including:
Entity life histories using a J ackson-like notation.
Data modelling based on an entity relationship approach.
Data flow modelling.
Data normalisation.
In addition, SSADM takes three interrelated views of information:
Logical data models- show the data stored and interrelationships
Data flow models- show how data is passed around the system
Entity Life histories- show how data is changed over its life
SSADM is one of the most highly developed conventional analysis and
design methodologies. It is conventional in the sense that it assumes a
conventional analysis and design life cycle. It is a well-proven
methodology that is freely available and openly documented.
Exercise 4.5 2 hours 30 minutes
The Velotec IS Manager is again considering whether to adopt
SSADM. He asks you to prepare a briefing paper describing how it
could be used at Velotec. You have read only the material above and
that is clearly insufficient.
Use a web browser to find out much more about SSADM (there are
dozens of good sites).
Then produce a five-minute presentation to try to sell the idea to him.
Your lecturer will then select a number of presentations and if selected,
you will present your ideas to your colleagues.
No formal answer is provided for this question.

V2.0 4-15
7 Object Technology
Much research continues into the most appropriate method to use for the
development of information systems. One development has been the
introduction of Objected Oriented Programming (OOP), Object Oriented
Analysis and Design, (OOA and OOD), Object Databases and more.
Clearly that represents a lot of thinking about objects. So what exactly is
an object and why does it matter?
7.1 Objects
In normal life we deal with objects all the time. An object such as a chair
has a name, it has properties that we can use to describe it, such as
number of legs, materials, shape etc. It can do certain (limited) things for
us, such as supporting our weight comfortably when we sit on it. It has a
life cycle which we can define, involving creation and ultimate destruction.
It belongs to a class of similar objects (seating) that have some
similarities, but also differ in some specific ways. For example, a sun
lounger is a seat, just like a chair, but it can do something extra it can
fold up. An office chair is a seat, but it has extra capabilities, including
swivelling, height adjustment, tilting etc.
We can use this idea of an object very effectively with computer systems.
It has the potential to solve some of the problems that have caused
difficulties in more traditional development methods.
Objects provide a common, understandable way for analysts, designers
and programmers to talk about the same things in an unambiguous way.
This is in sharp contrast to the wide range of tools and ideas used in more
conventional analysis, design and programming practice where users,
analysts and programmers all talk in different languages.
We need to tighten up our currently loose definition of an object. The
easiest way to do this is by defining some of the attributes of an object
from the viewpoint of a programmer:
Encapsulation an object packages together data and the access
methods to that data. This means that the data within an object can
only be changed by using these methods. The object effectively hides
the data from the outside world.
Definition
Object a term loosely used to describe an identifiable component of
a software system or design, now more commonly applied to a
component that is in some sense self-contained, having an identifiable
boundary.
In a business HR system, an employee would be an object.

Messages the only way that an object can communicate is by
means of a message. A message can be passed between two objects
and may result in the object carrying out one of its methods.
Inheritance an object belongs to a class of objects that share the
same methods (both access methods and methods that carry out any
other kind of function). A new class can be defined that inherits the
data structure and methods of its parent class. This in itself would be
of some interest, but inheritance goes further.The new class can
override some of the methods of the parent class and add new
methods. Inheritance from a single class can be further elaborated to
inheritance from multiple classes.
Polymorphism polymorphism is a word of Greek origin, meaning
many shapes. In object technology terms, it means that classes that
are different can implement the same message. For example, a series
of classes could be defined for the types of shape that can be drawn
by a graphics system. Each is quite different, but they all know how
to draw themselves; they each have a draw method that responds to
a draw message.
7.2 Object Oriented Analysis and Design
Object Oriented Analysis and Design Methodologies are obviously based
on objects, but does this mean that they represent a total break with the
existing structured analysis and design methodologies? The answer is no,
but their focus is certainly different. Instead of analysing systems from a
number of different viewpoints using different tools such as DFDs and
ELHs, we analyse and define the required behaviour of a series of
classes that will together provide the functionality we require.
The success of the object idea led to the emergence of new notations that
better fitted objects. For a while, object oriented analysis and design
methodologies appeared everywhere until it looked as if there would be
so many, that confusion would result. The situation is now resolved
because several of the leading experts in OO got together and combined
their efforts. The result, the Unified Modelling Language, has gained a lot
of acceptance.

Study Note
UML is based mostly on the unification of three methods:
Grady Boochs methods.
J ames Rumbaughs Object Modelling Technique (OMT).
Ivor J acobsens Object Oriented Software Engineering (OOSE).
Most computer companies support UML. (e.g. Microsoft)

V2.0 4-17
8 Program Specification
Program specifications take a variety of different forms. We have already
described the minispec, and this can be supplemented by various other
types of processing description. We have made clear that you do not
need any experience in programming to complete this workbook, but in
describing some of these techniques, we are very close to real program
code and the thinking that accompanies it. This should not discourage
you; the descriptions are all quite simple to follow, and are independent of
the programming language used.
8.1 Pseudocode
Pseudocode is a reasonably well organised and precise way of producing
a minispec. The point of pseudo code is that a set of logic is presented as
a list, ready for actual coding. It uses indentation of text to indicate logical
blocks of program code, coupled with closure statements to terminate
iterations and selections.
The following pseudocode counts the number of times words occur in a
text file. A table is produced at the end showing how many times each
word occurred.
DO WHILE there are more text records
DO WHILE there are more words in the text record
extract the next text word
search the word table for the extracted word
IF the extracted word is found
increment the words occurrence count
ELSE
insert the extracted word into the table, set words
occurrence count to 1

ENDIF
increment the words-processed count

ENDDO at the end of the text record
read the next text record

ENDDO when all text records have been read
Display the table

Standards for writing pseudocode are available, but many companies
produce their own simple variants. The critical requirement is that the
Web Pointer
Although you are not required to investigate UML further, you may do
so via the Object Management Group (OMG) at http://www.omg.org.

pseudocode is a clear and unambiguous way of communicating a logical
system design with the programmer.
8.2 Structure Diagrams
A structure diagram is essentially the same concept as an ELH and uses
the same type of diagram notation. This is not surprising, given that both
the structure diagram and the ELH are based on J ackson principles. The
difference is that the structure diagram describes the processing needed
for the whole system.
In Figure 4.6 we see the processing for producing an invoice, which may
be for one item that has been ordered, or for many items. Write Title,
Produce Invoice Body and Write Footer are sequential processes.
Calculate Invoice Line is repeated for as many lines as required. This
consists in turn of three sequential processes, Write Item Description,
Calculate Tax and Write Value.
Structure diagrams are a powerful way of representing the designed logic
of a program without becoming involved in the actual program code.
8.3 Structured Flowcharts
One of the most popular early pictorial methods of logic description was
(and in some cases still is) the flowchart. The idea of a flowchart predates
the invention of computers by some time. It grew out of techniques used
to organise manual work, where no automatic data processing was
involved.
Flow charts use a small set of symbols where:
A process is shown as a box.
A decision is shown as a diamond.
The flow of processing is shown as arrows linking the symbols.

Figure 4. 6 Structure Diagram
Produce
invoice
Write title
Produce
invoice
body
Write
footer
Write item
description
Calculate
tax
Write
value
* Calculate
invoice
line

V2.0 4-19
Flow charts like this do represent small simple procedures quite well, but
they quickly become ineffective when the logic becomes more complex.
The most serious criticism of them is that the very generality of the
flowchart leads to unstructured program code. We have already seen that
noodle code is a major problem, and a flowcharting approach that
encourages it is obviously not a good idea.
Structured flowcharts are a development of the original flowchart idea, but
recognising the three constructs of sequence, selection and iteration.
A structured flowchart is better, but it is hard to keep the logical design of
a program and its implementation on program code cleanly separated.
Flowcharts are rarely used and never by professional system designers.
There are better and more readable methods of representing logic,
particularly where this becomes more complex. You should be aware of
the approach, but should think carefully before using a flowchart.
8.4 Decision Tables
A decision table takes the basic constructs of sequence, selection and
iteration and presents them as questions (conditions) and/or things to do
(actions) in the form of a table or several tables. Since it specifies only the
logic rules involved and contains no implications about the procedure to
be executed, a decision table is more problem orientated than a flowchart,
which is solution orientated.
Not surprisingly, given their name, decision tables are useful when a
system design requires very complex logic (many decisions). This type of
system is notorious for producing hidden logical errors that are hard to
find. Decision tables help to ensure that such problems are avoided.

Figure 4. 7 Flowchart
Fine?
Process
fine
No
Yes
Start
Locate library
member
Process
book returned
Another
book?
End
No
Yes
A process is shown as a
box
A decision is shown as a
diamond
The flow of processing is
shown as arrows linking
the symbols

A decision is represented in a flowchart by the diamond symbol, and in
pseudocode by the IF ... ELSE statement. In a decision table the
question is asked first, followed by the answer, which is either Yes or No.
Sequence is represented in a flowchart by rectangles connected together
and in structured English or pseudocode by a list of statements. Similarly,
in a decision table, sequence is a list of statements called actions. For
example:
get out of bed;
get washed;
clean teeth;
get dressed;
make breakfast;
eat breakfast;
go to work.
Sometimes these actions depend on the result of an earlier action.
Iteration is represented in a flowchart by lines and arrows, and in pseudo-
code by the DO ... ENDDO or similar statements. Iteration in a decision
table is achieved by naming the table so that the name can be branched
to.
The four basic elements of a decision table are known as:
the condition stub;
the condition entry;
the action stub;
the action entry.

The condition stub and condition entry describe the conditions to be
tested, while the action stub and action entry describe the actions to be
taken. In a decision table these four elements form quadrants.
The condition entry and action entry together constitute one or more
rules, which run vertically through the two right-hand quadrants.
Each rule indicates the actions to be taken when a particular combination
of conditions applies. In a limited-entry decision table the conditions are
expressed as simple YES/NO questions, and the actions are restricted to
either execute (indicated by the X) or do not execute (indicated by the
).

V2.0 4-21
In Figure 4.8, we see a full decision table used for deciding whether credit
will be offered to a person in a store. It is called a full table because there
are three questions which can each be answered Yes or No, giving a total
of 2
3
=8 possible combination of answers or rules.
When the full decision table has been laid out, it should be inspected to
see whether there are any rules that have identical action entries. If such
instances are found, it may be possible to combine these. In addition, in
this example, if the answer to condition 1 is Y then the first four rules are
the same action, meaning no further conditions need to be tested.
By making simplifications like this, the decision table can be reduced to
the much more concise version shown in Figure 4.9.

Decision tables have many useful features for the systems analyst and
system designer. They are:
Simple - easy for the user to understand.
Complete and unambiguous - the analyst can calculate the exact
theoretical number of rules to be specified. Methods exist for laying

Figure 4. 8 Decision Table
Figure 4. 9 Simplified Decision Table
Y Creditworthy?
Rules
Salaried?
Reject
Accept
2 1
-
-
-
N
3 4

Special person?
Y
Y N N N
Y Y Y
Y Y Y N N N N
N N N N
Y Y Y
- - - - -

5 6 7 8
Creditworthy?
Salaried?
Reject
Accept
N
Special person? N
-
N
ELSE
-
-
-

out these rules systematically so that none is missed or specified
twice.
Statements of policy - they say nothing about how the policy is
carried out.
Working documents: like all good analysis tools, the decision table is
a useful working document. Used as part of the dialogue between
analyst and user, it leads to clear communications and identification of
areas of uncertainty or error in the analysts understanding.
Decision tables can be more than just a good design aid. There have
been some software development packages that essentially use decision
tables directly as an implementation tool. It is possible to build very
complex systems with these tools.
9 Summary
This chapter has introduced some notations, methods and methodologies
for systems analysis and design. We have seen that some notations such
as simple flowcharts are now rarely used, because they do not fit easily
into our desire for a structured approach. Other methods have matured
and been put to use in coherent methodologies such as SSADM. We
also saw that Object Technology is having an increasing influence on
methods and with the introduction of UML, we have a unified Object
Oriented Analysis and Design notation.
All of this tends to suggest that everybody should be using an appropriate
methodology for software development projects. Unfortunately, this is far
from the truth. We have seen that Velotec has encountered some
resistance to the introduction of structured methods and this is very typical
of many businesses.
9.1 Self Study
Given the growing importance of OO you may decide to visit the OMG
group and read the beginner information on UML. Although not
compulsory, if you wish to become more involved with programming, it
will help you to understand OO.
Once you have absorbed this, download the specification for the latest
version of the UML (it is freely available). Versions are available in
both PDF and PostScript formats. If you are not sure how to use
these, ask your lecturer. Do not print out the specification, it is over
one thousand pages long! Skim through the specification so that you
gain an overall view of UML.

V2.0 4-23
10 Answers
Answer 4.1

Answer 4.2

Figure 4. 10 Exhaust Fitting Context Diagram
Warehouse
Head Office
Customer
Operate workshop
Delivery
Order parts
Stock
response
Requests
work
Pays for work
Stock
query
Sales returns
HR Department
Training request
Certified fitters
Figure 4. 11 Exhaust Component ELH
Exhaust Part
Receive Inspect Use
Accept Return
o o
Scrap Return
o o
Fit
o

Answer 4.3
The arguments you could use include:
A standard methodology means that we could recruit people who
understand our development process.
Why re-invent the wheel? A standard methodology has had a lot of
input from experts and users so it probably has fewer problems than a
methodology we could produce ourselves.
If we leave out some of the things that are done in a standard
methodology we should be asking ourselves why they are not
needed.
Adopting a standard methodology will make it much easier to estimate
time, cost, and manage projects because we will all have a clearer
idea about the process we are following.
Standard methodologies are all well documented so we will not need
to produce this ourselves.
There are many other possible answers.

Answer 4.4
You could use all the same arguments as in Question 3.3, but this really
misses the point. Some of the applications that the engineers are thinking
about are very far from typical of those for which most structured methods
were designed. The best answer is probably to say that a number of
criteria should be used to decide if a standard structured methodology is
not an appropriate solution. For example, if the proposed application:
manipulates very little data;
is predominantly calculation based, and these are extremely complex;
needs no user interface, or at most a very simple interface;
will produce just one type of output.
Then most structured analysis and design methodologies would be a poor
fit. If any of these factors do not apply, there will be benefits in using a
structured analysis and design methodology.

Answer 4.5
Preparing a presentation is a useful exercise in learning to communicate
with others, something you will have to do if you become a systems
analyst or designer.
V2.0 5-1
Chapter 5
Documentation and Standards
2 Introduction..................................................................................................5-2
3 Standards.....................................................................................................5-2
3.1 Why Standards?.................................................................................5-2
3.2 Standards and Quality.......................................................................5-3
4 Documentation and Coding Standards........................................................5-3
4.1 Documentation...................................................................................5-3
Accessibility........................................................................................5-4
Readable............................................................................................5-4
Understandable..................................................................................5-5
Correct ...............................................................................................5-5
Controlled...........................................................................................5-5
4.2 Code Standards.................................................................................5-6
4.3 Types of Documentation....................................................................5-8
5 Summary......................................................................................................5-9
6 Self Study...................................................................................................5-10

Chapter 5 Documentation and Standards Systems Development

Standards and quality.
Purpose of documentation and coding standards.
Attributes of good documentation.
Types of documentation.
2 Introduction
Documentation and coding standards are two topics almost guaranteed to
cause a sudden lack of interest. The purpose of this chapter is to show
that there is a lot to be gained from good documentation and compliance
with appropriate standards. We showed in chapter 1 that by far the largest
proportion of the life cycle costs of a system can be absorbed in
maintenance, and that using appropriate standards and documentation is
a good way to minimise these costs. In this chapter we will take these
ideas and apply them more widely, so that we will see how standards and
documentation benefit us all the way through the development life cycle.
3 Standards
Before we consider standards in the context of a system development life
cycle and its documentation, it is perhaps helpful to identify standards in
general.
Standards are present in all areas of our lives and in business.
Throughout the world, a red traffic light means stop and green means
go. This is an international standard. Many countries have food
standards which specify which additives (food colouring is an example)
and how much of each additive is allowed in processed and tinned food.
There are standards for office and factory conditions in some, but not all,
countries. Car manufacturers all use the same layout of foot pedals, with
the accelerator on the left, whether the steering wheel is on the left or
right! Spend a few moments identifying some standards which are
relevant to you.
3.1 Why Standards?
It is no exaggeration to say that the global development of IT depended
on standards being in place or being produced and agreed quickly.
Without standards, we would not be able to physically connect different
types of equipment and programming languages would be different for
each type and model of computer. Every system would be built in an
Systems Development Chapter 5 Documentation and Standards

V2.0 5-3
entirely different way and would be substantially more expensive than
they currently are. Standards give some comfort to the consumer;
standards allow for some degree of certainty, in that the system being
produced can be expected to behave in a predictable fashion. The
adoption of a common operating system by most PC manufacturers is
one example of a standard. We say most but not all, because do not
forget the Apple Macintosh, loved by many in the art world, but which
causes problems for those trying to move applications (including graphics)
between an Apple and a PC.
3.2 Standards and Quality
There is a close relationship between standards and quality. In order to
improve quality, we have first to have a process that is well enough
defined to be repeatable and susceptible to study. A standard provides
the framework for this repeatability. It is not possible to assess or
measure quality unless you have defined what is expected. A
documented procedure for the manufacture of any article will be found in
most organisations. The person responsible for quality assurance will
check a sample after manufacture. If it does not meet the required
standard, he/she will then trace back over the procedure to identify at
which stage the problem occurred. This is one of the reasons why written
procedures form part of all Quality Management Systems.
.
4 Documentation and Coding Standards
We have briefly mentioned how important standards are, but our main
purpose in this chapter is to understand the significance of a particular
group of standards, those that define how we document information
systems. Before we look at the detail of any particular documentation
standard, we should first decide what good documentation is and how we
can recognise good documentation practice.
4.1 Documentation
Good documentation is:
accessible;
readable;
understandable;
correct;
controlled.


These are significant requirements which have management implications.
Accessibility
Documentation is useless unless it is possible to use it to answer
questions. Technical documentation is rarely read from beginning to the
end like a novel. Users need to find the required document and the
appropriate section to solve a specific problem. This means that technical
documents need:
a clear structure;
a table of contents;
a detailed index;
pointers to other relevant documents;
to be catalogued.

The last is particularly important in an IS department, where very large
amounts of documentation will be produced. A catalogue is necessary to
give each document a unique code and very importantly, a searchable
outline. These are requirements that are satisfied by many general
purpose library systems and some specific IS department documentation
systems. The move towards placing all documentation on a computer
helps in this respect. With a good structure and folder names and
location, the document may be found quickly. Using standard routines,
such as the Microsoft Help system, the document can be searched for
specific topics.
Readable
There is no single style which is appropriate to all documentation.
Documentation should be written to suit the knowledge and level of
understanding of the likely users of the document. An impersonal active
style may be appropriate for much system documentation, but user
documentation should be written in a more personal style and should not
assume technical expertise. Technical reports may favour a more passive
style. This is a large topic area, and writers of documentation should be
encouraged to take up training in the skills involved.

V2.0 5-5

Review some of the Help documentation for Microsoft Word.
Define the profile of the reader for whom this is written.
What assumptions are being made about the experience of the reader?
No answer is produced for this exercise.
Understandable
Documentation is intended to convey information to the reader. It can
only do this if the reader is able to understand the text. Understanding is
based partly on style, but also strongly on the assumptions made by the
author about the expertise and experience of the user. The writer should
have a very clear idea about what can be assumed of the reader.
Correct
Documentation should be viewed as just another product of the
development life cycle. This means it should be subject to the full
verification and validation process. We have to decide two things:
Is this the right thing to document?
Is this documentation correct?
Correctness requires testing by means of peer review (colleagues). No
documentation should ever be released without such a review because
even the best document writers make mistakes and it is difficult to find
ones own mistakes.
Controlled
All the products of the software development life cycle are subject to
change, and this includes documentation. Extreme confusion can be
caused by mixing up different and incompatible versions of program code,
documentation, and any other deliverable from the system development
life cycle. For this reason, most large projects use a version control
system. These possess some features that help to keep control over
project products:
A check in and check out facility, so that any product (source code,
documentation, drawings etc) can be checked out to a particular
programmer or team. While it is checked out, no other team can

make alterations. When it is checked back in, the program will update
version information so that changes in the total system can be
tracked.
A baseline and release control capability. A baseline is a known state
of the entire system, containing all the version information for all the
products. This configuration can be recreated at any time using the
system, regardless of what changes may be made in the future. A
release is a configuration that has completed all testing and is ready
to be made available to some or all customers. The release (and its
target customers) can be recorded so that it is always possible to
know which customers have which versions of every product.
The ability to create branches in the line of development. This allows
two or more parallel configurations to be developed independently,
perhaps for different architectures, whilst retaining complete control.
A system that does all this can be very complex, but it is necessary to
maintain control if documentation is to remain useful.
4.2 Code Standards
A good understanding of a programming language is not sufficient to write
good quality code. Programmers need to have a disciplined approach that
will produce code that will be efficient, effective and easy to maintain. To
achieve these goals, most large IS departments design coding standards
which define rules that a programmer must follow.
We have already seen some of those rules in a previous chapter, where
we found that research had proved that any program could be constructed
from sequence, choice and repetition. Other programming constructs
such as a GOTO (a jump directly to another part of the program) are not
required and in fact, are bad practice.
Internal standards usually define other aspects of a programmer's work
such as:
No single program function should be more than about one page of
code. This is to ensure that it is possible to understand and maintain
the code effectively. It also has the effect of reducing the incidence of
errors.
All functions must have a single entry and exit point. This is part of the
structured programming paradigm and is again essential if the code is
to be understandable and maintainable.
Functions should communicate with the rest of the system in a tightly
defined manner. This is connected with the rule above, but
programmers often use variables that are outside the scope of a
function. This effectively sets up some very complex and often
obscure connections between different parts of a system.

V2.0 5-7
Specific types of statement must be used in a particular restricted
way. This is to ensure that the structure of the code is not obscured.
Variables should be named according to a convention. This is again
an aid to understanding and maintenance.
Assumptions about hardware should be limited and well-defined.
Application programmers should ideally avoid writing code that will
only work on one particular hardware/operating system architecture.
All functions should contain internal documentation in the form of
comments. These are divided between a header, that defines and
describes the function in detail, and comments interspersed
throughout the code, where it is necessary to explain a particular bit of
logic. The header usually has a standard format and will define the
relationship of this function to others, together with how it is meant to
be used. It will also define the usage of all important variables.

A function is the smallest amount of code that can be compiled
separately.
Different terminology is used in different languages to describe a function.
This is a very limited selection of the rules that would normally be applied.
Code inspections are often used to ensure that the rules are being
followed and to ensure that the code correctly implements the
specification.
There are very few opportunities available for students to look at the
documentation of real large-scale code. Fortunately, the strong trend
towards open-source systems means that this situation is now
changing.
Obtain the source for SAMBA, a UNIX oriented system that can make
a UNIX system look like a Microsoft NT Server. Take a look at how the
code is documented. http://us1.samba.org/samba/
An alternative is Apache, a very widely used open-source web server.
www.apache.org/
No answer is provided for this exercise.


4.3 Types of Documentation
We will now summarise some of the types of documentation, their uses
and the stage of the life cycle in which you are likely to encounter them.
Type Use Stage
See fig 6.2
Project Initiation
Document
Defines scope of project FS, BS
End of Stage
Report
Defines the status of development at
the end of a project stage
FS - I
Data Flow
Diagram
Defines processes and flows of data FS, RA, RS,
LSS, LD
Entity Life
History
How an entity changes over time FS, RA, RS,
LSS, LD
Logical Data
Model
Relationships between entities FS, RA, RS,
LSS, LD
Flow Chart Shows logic of system RA, PD (if
at all)
Structure
Diagram
Shows the processing done by a
program
LD
Decision Table Defines complex logic LD
Program Listing Documents a program C
Test Report Summarises testing results T
Test Plan Describes how and what will be tested T
Test Case Describes a particular test T
Test Data Defines the data to be used with a
test case
T
Modification
History
Tracks changes to a system M
User Manual Describes how to use a system from
users perspective
I
System Manual Describes the operation of a system
from a technical viewpoint
M
Release Notes Describes what has changed since
the last release and any special
installation requirements
I, M

Figure 5. 1 Types of Documentation

V2.0 5-9
The keys to these stages are:
SS Strategic Study
BS Business Study
FS Feasibility Study
RA Requirements Analysis
RS Requirements Specification
LSS Logical Systems Specification
LD Logical Design
PD Physical Design
C Coding
T Test
I Implementation
M Maintenance
PO Phase Out
Figure 5. 2 Key to Stages
5 Summary
Standards in all their different forms are vital to the development of IT,
and in particular, to uphold the interests of small consumers against the
large corporate entities. We need standards for hardware and software,
and for the internal development of software, because that allows us to
learn from and rely on the experience of others.
Documentation and standards in documentation are needed to ensure
that we communicate effectively with all the people who will be involved in
the development of a system. We have reviewed some of the attributes of
good documentation and emphasised the fact that good documentation is
hard to produce, but particular attention should be made to reflect the
needs of the intended readership.


6 Self Study
This exercise should take approximately 2 hours 30 minutes to
complete.
Write a short user manual for Microsoft Notepad or any other software
you use.
Ask your colleagues to review your efforts against the criteria for good
documentation, as defined earlier in this chapter.
V2.0 6-1
Chapter 6
Testing
2 Introduction..................................................................................................6-2
3 Defining Testing...........................................................................................6-2
3.1 What Testing Is and Is Not.................................................................6-3
3.2 What is a Good Test? ........................................................................6-4
3.3 Types of Error ....................................................................................6-4
3.4 Why Cant We Test Everything?........................................................6-6
4 Types of Testing...........................................................................................6-7
4.1 Black Box Testing..............................................................................6-8
4.2 White Box Testing..............................................................................6-8
4.3 Testing Through the Life Cycle..........................................................6-9
4.4 Test Teams ......................................................................................6-15
5 Designing and Implementing Tests ...........................................................6-15
5.1 Integrated Development Environments ...........................................6-16
5.2 Design Guidelines............................................................................6-16
Inputs................................................................................................6-17
Data Files.........................................................................................6-17
Outputs.............................................................................................6-18
5.3 Test Tools ........................................................................................6-18
5.4 Knowing When to Stop Testing........................................................6-19
6 Planning and Managing Tests ...................................................................6-19
6.1 Standards for Test Management and Documentation....................6-20
6.2 Test Plan..........................................................................................6-20
6.3 Test Design......................................................................................6-22
6.4 Test Case.........................................................................................6-22
6.5 Test Procedure.................................................................................6-23
6.6 Test Log...........................................................................................6-24
6.7 Test Incident Report.........................................................................6-24
7 Velotec Testing..........................................................................................6-25
8 Summary....................................................................................................6-27
9 Answers .....................................................................................................6-28

Chapter 6 Testing Systems Development

Testing and errors.
Types of testing, testing plans, testing tools, test teams.
Designing, planning, managing and documenting tests.
2 Introduction
Everybody knows that testing is important, but very few organisations
actually test software well. This chapter will help you to understand why
and when you should test and what you should expect to achieve as a
result of this effort. We will also dispel some myths about the connections
between testing and quality.
Managing software testing requires an understanding of both economics
and psychology. We will explore why this is so and show you how to plan
what to test and for how long. The latter is important, because as we will
see, no matter how many testers you have and no matter how long you
try, you can never guarantee that a software application has no errors.
This is a challenging chapter and some of the questions that we pose as
exercises require much consideration to obtain a good answer. You will
appreciate the benefits of the knowledge you will gain, when studying
other modules of the course and particularly when you complete
coursework and projects.
3 Defining Testing
Testing a product seems very simple. It involves ensuring the product
works as intended and does not fail. This is what we strive to achieve
when testing program code. If you ask the average person to explain
testing, he/she will probably say something like testing makes products
work and adds quality to them.
When you read text books on testing you will find that verification and
validation is the name given to the checking and analysis processes that
ensure the software conforms to its specification and meets the needs
(requirements) of the customer. The difference between validation and
verification was expressed by Boehm (1979) in Somerville
3
.

3
Software Engineering, Ian Sommerville, Addison Wesley ISBN 0 201 39815
Systems Development Chapter 6 Testing

V2.0 6-3
Why do you think that adding quality by testing is a questionable
concept?
Many would suggest one or more of the following:
Testing is the process of demonstrating that errors are not present.
Testing shows that a program performs its intended functions
correctly.
Testing is the process of establishing confidence that a program does
what it is supposed to do.
These definitions are all flawed in quite a serious way. Sommerville
(reference on previous page) provides a useful section on Validation and
Verification.
3.1 What Testing Is and Is Not

The difference between the average persons definition and the selected
definition is more than just superficial. In some respects, the average
person is describing the opposite of what is intended. When testing a
system, we wish to add to its value by increasing reliability, or suitability
for purpose. The process of testing is costly, and therefore it is desirable
that this cost is recovered by increasing the value of the system. The only
way this can be done is by discovering and rectifying errors. The tester
should start with the assumption that a system contains errors and then
use the most effective techniques possible to find those errors.
The preferred definition implies a destructive approach. The objective is to
find the most cost-effective tests available to uncover the errors in the
system by breaking it. This is an approach that is very difficult for the
team that developed the system to apply; in most cases it has a protective
attitude to the system, being something in which considerable time and
effort has been invested. You may be aware that Formula 1 cars have to
pass a crash test which destroys the car, but demonstrates that in the
event of failure by the driver or a component in the car, the driver should
survive.
Definition
Validation are we building the right product?
Verification are we building the product right?
Definition
Testing any activity that checks by means of actual execution,
whether a system or component behaves in the desired manner.

3.2 What is a Good Test?
In order to test a software system, we actually need a whole series of
tests, many hundreds, or even thousands. Given the effort that this
entails, we need to have a good idea of what constitutes a good test.
A successful test is one that finds an error.
A good test is one that has a high probability of finding a new error.
This is slightly counter intuitive, but follows logically from the definition that
we started with.
There is no point in devising a large set of tests that we are certain the
system will pass. The object is to find errors using a minimal set of low
cost tests. Of course, it is only possible to be certain which tests are good
tests in hindsight, but there are techniques that increase the likelihood of
tests being successful. A mistake made by most trainee programmers is
that they devise tests which they know their code will pass. We need the
users of the eventual system to help devise the tests.
3.3 Types of Error
We have introduced the notion of errors when referring to successful
tests, but what exactly is an error? Intuitively, we think we would be able
to recognise an error if we saw it, but in reality, it is much more difficult.
For example, it is not uncommon for a supplier of bespoke software and
the customer to resort to litigation, arguing about the validity of the tests
and the errors revealed by them. This is because payment is often
dependent on the success of customer testing.
We can get a better idea of what an error is through a two-part definition.

This helps, but not greatly. The definition of error seems to depend
directly on what a system is supposed to do. How do we know what the
system is supposed to do? The answer lies at least partly in the various
types of specification that are generated during the system development
life cycle. This is where the V Model that we reviewed earlier, in the
chapter on systems development life cycles, really helps. It shows quite
clearly how various types of testing are related to the different types of
specification.
Definition
Error an incorrect step, process, or data definition in, for example, a
program.

V2.0 6-5

The Spiral life cycle model below also shows this type of relationship, but
not quite as clearly.

This is an important part of our thinking about testing. We need to define
specifications so that it is possible to design tests to exercise program
code. We could go further than this; a specification which contains
features that cannot be tested is usually a bad specification.

Figure 6. 1 V Model
Figure 6. 2 Spiral Model
Tested modules
Systemdesign
Requirements
specification
Acceptance test
Maintenance
Tested
system
Integration and test
Code and unit test
Initial concept
Software design
Requirements definition
Detailed design
Tested software
Tested system
Tested software
Tested
modules
Module design

3.4 Why Cant We Test Everything?
It is difficult to completely test a computer program which is longer than
about twenty lines of code. That may sound incredible, but it is correct.
Complete testing means trying out every possible combination of inputs
and initial conditions, so that every possible path through the code is
tested with all the possible values. It is easy to show that we would need
a huge number of different tests and the total number would actually be
unmanageable. As an indication of how large this number could be, for a
reasonable program set of perhaps a thousand lines of code, and
assuming that we could carry out one test per second, which would be
very fast, we would require more than the entire remaining expected
lifespan of our sun to complete the test programme!
Testing is expensive. We cannot automate the production of good tests,
(although paradoxically it is easy to automate the production of poor tests)
and we usually need people to interpret and confirm test results.
Testing is never completed. This follows from the fact that we can never
exhaustively test real systems. It is also true that we can never eliminate
errors from real systems, but we can reduce the number of errors to a
point that we may decide is acceptable. Recall how many errors have
been found by users despite extensive testing by Microsoft.

The graph above illustrates an important point. In many surveys of testing
it has been found that there is a relationship between the probability of
residual errors and the number of errors already found in the testing. In
simple terms, this implies that there are probably as many undiscovered
residual errors as have already been found at the end of the test program.
Testing for every eventuality is difficult or even impossible. Take the
example of a real situation.

Figure 6. 3 Probability of Further Errors
Errors already found
P
r
o
b
a
b
i
l
i
t
y

o
f

f
u
r
t
h
e
r

e
r
r
o
r
s

V2.0 6-7
A warship (the mother ship) was sent out to sea in order to test the
software guidance of a new torpedo. A design feature was, that whatever
moves were made by the target, the torpedo would adjust its direction and
always hit the target. The unmanned and remotely controlled ship (the
target) would attempt to manoeuvre, so as to avoid being hit by the
torpedo. In a war situation, the target would also be trying to send its own
torpedo to hit the mother ship, and so once the torpedo had left the
mother ship, it would also be manoeuvring in any direction.
When designing the tests, the team realised that once the torpedo had
been sent from the mother ship, there was no control over either ships
movements. After the torpedo had been fired, it could just be possible for
the target to manoeuvre so that it was behind the mother ship. Thus the
software in the torpedo measured each change in direction and once it
had completed a 180-degree change from the start point (leaving the
mother ship), it would have to self-destruct. This would ensure the torpedo
never tried to go through the mother ship to reach its target.
All tests went to plan until the motor driving a torpedo failed. The
indicators were, that despite being fired, it had not left the mother ship.
The captain ordered his ship to return to port to resolve the problem.
When the ship turned around to go back to port it moved through 180
degrees and the torpedo self-destructed and blew a large hole in the side
of the mother ship. You may wonder who was at fault! The lesson is, we
need to test for exceptional circumstances. Computers do not, like
humans, think for themselves.

4 Types of Testing
There are many different approaches to testing. You need to recognise
the different types and where they are applied in the system development
life cycle.
This chapter contains only an overview of the stages contained in this
important area of software development. Perhaps you should consider the
importance of testing when you fly on an aircraft. Many of the systems are
controlled by software, and as you take off you should perhaps hope that
the software engineer and the testing process found all the errors!
Further Reading
For those of you who wish to understand more about the whole
process of testing, perhaps if you intend to become a software
engineer, we suggest you read the chapter on Software Testing in the
text book - Software Engineering, Ian Sommerville, Addison Wesley
ISBN 0 201 39815.

4.1 Black Box Testing
Black box testing is sometimes called:
Functional.
Data-driven.
Input/output testing.
These alternative titles help to explain the nature of this form of testing.
Black box testing is based solely on the specification of the system. The
testers need not (and should not) have any knowledge of the internal
structure and behaviour of the system, being concerned only with what
goes in and what comes out of the system black box, in other words, the
functional behaviour of the system. The test designer is only interested in
finding circumstances in which the system does not comply with its
specification. These tests are derived from the specification and are only
communicated to the system by its normal input mechanisms.
Black box testing can never be exhaustive, and in most cases it is not
possible to estimate how exhaustive a set of tests has been, since this
would require knowledge of the internal structure of the system.
However, it is often possible to make some assumptions about coverage,
which can be useful in designing a cost effective set of tests.
Why would black box testing be used for the acceptance testing of a
system by a customer?
What consequences do you think this might have?
4.2 White Box Testing
White box testing assumes complete knowledge of the internal structure
of a system. It is sometimes described as:

Figure 6. 4 Black Box Testing
Data-driven
Input/output
Functional
No knowledge of system
internals
Tests use only standard
input interfaces
?

V2.0 6-9
Logic-driven.
Structural.
Glass (can see inside) box testing.

It might be thought that white box testing allows a closer approach to the
limit of exhaustive testing, but in practice, internal knowledge does not
always help. The exercising of all the internal paths within a program
would only be useful if they are the correct paths to satisfy the
specification. In other words, even if it were possible to exercise all the
paths, there could still be an infinite number of hidden errors because
paths are missing or some paths should not be present. It is possible to
have a program that is internally correct in some sense, but is still the
wrong program.
This distinction is important and is another form of the difference between
Verification and Validation which has been stated a number of times
throughout this workbook.
Given the definition of white box testing, who would you expect to carry
out such testing in an internal software development project?
What problems do you think might result from this?
4.3 Testing Through the Life Cycle
We can also classify testing according to the stage of the life cycle in
which it is used. The types of testing we will review in this way are:
Unit.
Package.

Figure 6. 5 White Box Testing
Logic-driven
Structural
Glass box
Complete knowledge of
internals
Tests can use special
interfaces

Integration.
Code Inspection.
System Testing.
Acceptance Testing.
Beta Testing.
Usability Testing.
Conformance Testing.
Unit Testing
Unit, package and integration tests are forms of white box testing. The
other forms are all black box. Unit testing is concerned with testing a
module to ensure it satisfies its specification, typically a minispec. A
module is the smallest unit of code; but what a module is and what a
specification is depends very much on the programming language being
used and on the standards for program specification.
A module might be as small as a subroutine or as large as a 'C' language
file containing several functions. Usually the programming team carries
out unit testing.
Since a unit or a module should be a small chunk of code, if we are
using good structured programming techniques, how do you think it is
possible to test it?
There is no complete system, and the unit may have no conventional
input and output functionality. What are the consequences of this?
Hint; think what else the programmer might have to construct before
starting testing.
Package Testing
Package testing is concerned with the testing of a group of units that work
together to carry out a well-defined set of functionality. An example might
be the set of all transactions for a particular file. This is most meaningful in
large projects where an elaborate functional decomposition has been
performed.
Typically, a package will consist of a number of functions or sub-routines
that have high internal coupling, but low coupling with another package or
module.

V2.0 6-11
Integration Testing
Integration testing is required when systems are developed in an
incremental fashion, typically with a team of programmers. This form of
testing is used when a module or package is completed, and is intended
to uncover errors in the interfaces between this module and all the others.
There are two basic strategies for integration testing, top-down and
bottom-up.
The choice will reflect the underlying development approach. The
advantage of the top down approach is that testing can be carried out
without needing to create any scaffolding code to provide the necessary
transfer of control and input data for the new module.
Integration testing frequently uncovers serious errors in parameter
passing between different packages. These errors are typically a result of
poor definition of minispecs and the confusion inherent in large
development teams.
A recent Velotec project combined programmers from the High
Performance Division with the IS Department to produce a medium
sized, but complicated system that combined some complex
engineering calculations with some database access.
Unit and package testing went well, but many errors were found during
integration testing.
What do you think could have caused this?
As IS Manager, what changes would you make to the development
life cycle to ensure that this does not occur again with similar
projects?
System Testing
System testing is used to discover mismatches between the system
specification and the system actually produced. It is a form of black box
testing because it is not based on any knowledge of the system design. It
is usually carried out by the development team, but in an ideal situation,
an external test team might be used. We will discuss the management of
test teams later.
There are a number of different types of system tests that can be used to
highlight specific types of error:
Functional testing.
Volume testing.

Stress testing.
Usability testing.
Security testing.
Performance testing.
Documentation testing.

Each of these is a reflection of the functional and non-functional
requirements.
For example, if the specification states that certain types of transactions
can be carried out in a maximum length of time, then a performance test
is required to discover any performance problems in this area. In some
cases, system testing is carried out with a similar set of test cases to
those that are expected to be used for system acceptance.
Why do you think it is very important that an independent white box
review is made of programmers code for a system that must exhibit
high security?
Do not move on to the next question until you have answered this.

Exercise 6.7 1 hour
Many Windows office applications contain Easter Eggs. If you do not
know what an Easter Egg is, use your web browser and a search
engine to find out and note down one or two of the official examples.
With the permission of the person who owns the PC you use, try out
one of these. For an example of an easter egg, the 1997 version of
Microsoft Excel contained a hidden flight simulator.
Why do you think that multinational software providers allow
programmers to embed Easter Eggs? Do you think they know about
them? Does this tell you anything about the need for an independent
inspection of code for highly secure systems? What advantage do you
think this gives to open-source software such as LINUX?
Acceptance Testing
Acceptance testing is a form of black box testing and may include the
same type of tests as system testing. The critical difference is that it is
normally carried out by the customer or user of the system, and will
typically form part of the contract between the supplier and the customer.

V2.0 6-13
Completion of acceptance testing is usually a trigger for a major stage
payment.
Acceptance testing is often carried out using a previously defined, and
agreed, test plan and test cases. The systems analyst may take a lead
role in defining these test cases, which should be based directly on the
specification for the required system. It is also normal for the development
team to be supplied with this set of test cases and data well in advance of
the test date. Given this, acceptance testing is not strictly testing in the
sense defined at the start of this session, since the development team will
ensure that the system is capable of passing all the tests. The actual
contractual acceptance test is therefore not specifically intended to
discover errors, but instead to demonstrate a level of capability, i.e. that
the software meets the agreed specification.
This distinction is extremely important and acceptance testing is often
more correctly considered to be a form of system demonstration, rather
than a true test. Given this view, we can add to the objectives of system
testing the need to ensure that acceptance testing will not cause severe
embarrassment to the development team.
Beta Testing
This type of testing is often carried out by large suppliers of shrink-
wrapped software before full release of a product. An example of shrink-
wrapped is Microsoft Word, which comes in a box which is sealed in
plastic wrapping. Often the instructions on the box state that by removing
the wrapping, you are accepting some specific conditions of sale. Beta
testing is intended to supplement and follow on from full internal system
testing and is designed to uncover errors in the actual use of the system
by selected users. The supplier releases copies of the system to these
trusted users under a non-disclosure agreement.
These users then use the system and report on any errors they find. Beta
testing is a powerful technique that can sometimes be abused. It should
never be a replacement for thorough system testing.
A smaller scale version of beta testing can be applied to an in-house
development project. The new system may be released to a small
selected group of users before finalising the system for release.
Beta testing requires careful organisation, but does not require the
systems analyst to define test cases or test data. These arise naturally
out of the day-to-day operation of the user.


What advantages does beta testing have for the supplier of a system?
What do you think would be the effect of a reliance on beta testing at
the expense of the other types of testing we have identified?
Usability Testing
A major aspect of testing a new system is investigating how easy it is to
use. Usability testing determines whether the system behaves in an
acceptable way for specific types of user carrying out specific tasks.
Points to be considered are:
Ease of learning - the time and effort required to reach a specified
level of user performance.
Ease of use - the tasks accomplished by experienced users, the
speed of task execution and the errors made.
Flexibility - the extent to which users can adapt a system to new ways
of interaction, as they become more experienced.
Attitude - the positive attitude engendered in users by the system.
Who should carry out usability testing? Who should not?
Give the reasons for your views.
Conformance Testing
Conformance testing is the testing of hardware or software against a well
defined standard such as an international standard, or a de-facto
standard. This type of testing is not usually undertaken by small and
medium sized organisations. It requires a great deal of careful planning
and in-depth knowledge of the relevant standards.
Regression Testing
When a system is in its maintenance phase, and even earlier during its
development, a large number of changes may be made to the program
code in order to correct errors. There is a significant risk that these
changes may re-introduce previously corrected errors. In this case, the
software regresses or goes back to a previously incorrect state. Clearly, it
is important that this does not occur. Regression testing is designed to
detect this type of error re-introduction. It usually takes the form of a
series of tests that are run in succession and are known to be effective in
finding the errors that have already been removed. Regression testing is

V2.0 6-15
usually automated because the effort involved in running hundreds or
even thousands of tests is prohibitive. Such regression test tools are
widely used by maintenance programmers.
4.4 Test Teams
An important issue in the management of software development is the
selection of test teams. The emphasis is usually on teams, because the
amount of work is far more than can be completed by a single person.
It might be thought that the natural choice of testers would be the
programmers responsible for the code. This is acceptable for unit testing,
but is an extremely bad idea for the other types of testing we have
described. The reason is that testing must be a destructive process if it is
to be successful. Remember a successful test is one that discovers an
error, and the people who have written program code usually find it
difficult to discover ways of breaking the system that they have spent so
long producing.
What we really require is a team of people independent of the
development team who have an incentive to find errors. This is a
specialised requirement but there are software testing businesses that
can carry out this type of work. The costs of mounting an exercise like this
are high, so it is usually limited to systems that are safety critical (fly by
wire aircraft) or that carry a very high risk of some other kind.
5 Designing and Implementing Tests
How do we design tests? We know already that our goal is to design tests
that will find errors, so our design methods need to lead to tests that will
be effective. There is not one single type of test, nor a single way of
designing tests. We will discuss some of the test design disciplines in this
section, but you should be aware that this is a very large area and one
that in some cases requires a thorough knowledge of programming
languages, which is beyond the scope of this workbook.
The first form of testing which is required during the software development
process is desk checking and dry running code. In this process, the
programmer checks code by tracing through the path of execution of
his/her code manually, whilst recording the changes to variables. This is
often called desk checking. This technique is rarely given much attention,
but it is a very effective way of finding logical errors in a program. It
requires no special software (no computer at all), but it is capable of
finding errors that would be difficult to locate with other more sophisticated
methods.
A further form of simple testing occurs when a program is compiled. The
compiler will give quite specific indications of where any syntax errors

have occurred. Syntax errors are the most trivial form of error as we have
already seen, being equivalent (roughly) to a simple typing mistake or
spelling mistake when writing normal text.
Some compilers go well beyond this and can look for particular types of
code that probably represent a more significant error. For example, using
a variable before giving it a value may not be a syntax error (that depends
on the language), but it is certainly bad practice.
Compilers can be required to produce very detailed listings of programs,
together with details of any errors. These listing are useful and should be
used as part of the project documentation.
Further errors can be detected at run-time by the Operating System or in
some cases, by setting an option when compiling the program. One useful
run time test is to provide a count of each time a line of code is used.
Obviously the lines that are not used should be investigated; perhaps it is
redundant code or the tests have not tested that particular path of the
program.
None of these detection mechanisms are capable of finding logical errors
(remember the warship story earlier in the chapter?) therefore useful as
they are, there is no substitute for human based testing.
5.1 Integrated Development Environments
The process of editing, compiling, linking, running and recording
debugging results can be carried out much more conveniently with
specialist software tools such as an Integrated Development Environment,
or IDE. This can be used to handle all the files that make up a large
project and typically offers some programmer oriented features such as:
A language aware editor that has an understanding of syntax and can
indicate simple errors whilst code is being entered. This is similar to
the spellcheckers that are common with word processors. This
awareness of syntax often extends to using colour to indicate different
parts of statements. This can improve programmer productivity.
A project build capability that can automate the compile and link
process for a large project using many files. This valuable feature can
remove some common errors.
5.2 Design Guidelines
When we design tests we need to identify any condition that is likely to
cause a system to fail. This is a very large and complex subject, but the
following guidelines will help you to produce effective tests. These
guidelines are especially suitable for system and acceptance testing.
Since these are black box testing scenarios, we must look at systems in
terms of input, output and data storage.

V2.0 6-17
Inputs
Screen layout - ease of use, clarity, handling of incorrect entries.
Forms design - legibility and ease of use for clerical and data
preparation procedures.
Data preparation and controls.
Computer input validation.
Submission of corrections.
The content of test data for testing an input validation program should
include:
Minimum and maximum values of all data items - which should be
acceptable.
Minimum minus one, maximum plus one - which should be rejected.
Item formats, dependencies, combinations, sequence - if relevant.
Batch control total data - valid and invalid.
The system should only accept valid and specified data. All other data
should be reported and rejected, but never ignored. Not only invalid
inputs, but also illegal inputs should be rejected. Simple tests to ensure
users enter correct and valid dates of birth. A typical user mistake is to
enter the correct day and month, but to mistakenly enter the current year,
rather than their birth year.
Data Files
Files of data, or a database, must be checked for validity of format at each
stage in processing. This may mean that software tools will be needed to
inspect the contents. Most modern database software provides assistance
in trapping input errors if, and only if, the database was set up correctly in
the first place.
The content of test data for testing an update program should be:
At least one of each type of transaction - in logical and illogical
combinations.
Tests for no transactions, or no data in the master file.
End of file combinations.
The ability to insert before the first record on file, and after the last.
The ability to delete records from the front and from the end of the file.
Multiple transactions per record - if permitted.
Duplicated insertions.
At least one of every reportable error and exception.
Production of every type of output.

Outputs
Output testing is related to the output of each sub-system within the
system, of which the computer processing is only one. Although not
strictly a test, we should always have ensured that the user approves the
screen layout and colour selection. The design and testing of error
messages to the user should be included. Our tests should include:
Presentation of data on user screens (often through a Windows
client).
Forms design.
Completion and ease of preparation.
Controls and transmission.
Use of special devices.
5.3 Test Tools
As we saw at the beginning of this chapter, we cannot automate the
production of good tests, but we can certainly use automation to help with
the procedure of testing. Test tools can be used to:
Automate regression testing so that the tester can carry out a whole
series of tests in one session, with automatic comparison of test
results to the expected results and with exception reporting of any
errors.
Establish the coverage of testing. Coverage means the extent to
which all the paths in a program have been explored by tests.
Various levels of coverage imply greater or lesser certainty of the
existence of errors. Note that even with these tools, it is not possible
to tests systems exhaustively.
Test documentation tools can be used to automate most of the
documentation effort of a large test programme. As we will see in the
next section, this can be a significant problem in its own right.
Carry out static testing of programmes without actually running the
code. This is why it is called static testing. Such tools are complex
and language dependent. A typical use is for firmware in safety critical
systems.
Generate test data. Whilst we said that tests cannot be automated,
test data preparation can, to some extent. Some tests require large
volumes of data and it is impractical to create this by hand.
Create test load situations. Large systems usually need to support
many users. The specification of the system often defines the
response rate that must be maintained with a specified number of
users and a critical set of transactions. It is obviously expensive to
have hundreds or even thousands of testers sitting in front of PCs

V2.0 6-19
running transactions simultaneously. This type of software simulates
the actions of a many users. Despite experience gained over the
years, many new systems still fail when their websites receive more
hits per second than they envisaged.
5.4 Knowing When to Stop Testing
Starting a test programme is the easy part. Deciding when to stop is much
more difficult. We know that there are always residual errors in any real
large-scale system and that no matter how long we carry on testing, some
of those errors will remain. We will keep on finding errors as we test, so
there is no clear point at which it is possible to say that the process is
complete.
Some organisations continue testing until the rate of new error detection
drops below a predetermined level. In other cases, testing continues until
a specific level of coverage has been achieved. In most cases however,
the duration of a test programme is predetermined in the overall
development project plan and is geared to the need to have a product
ready for a commercial launch. The sad fact is that many such products
are launched with a far higher level of errors than is reasonable, simply
because the company has announced the launch date and cannot delay,
both for financial and market positioning reasons.
Produce a list of three well known software products that you believe
suffered from this problem. Consider the rationale for their launch in an
unsatisfactory condition.
As you might expect, no answers are provided for this question.
6 Planning and Managing Tests
Testing any large system with many individual programs is a substantial
undertaking. You cannot simply start running tests and carry on until you
think the testing is complete. A framework and a test plan for the testing
are needed, and especially for the documentation of testing. In a previous
chapter, we saw that documentation and standards are closely linked and
this is true also for testing. We will describe the testing process and its
documentation together.

6.1 Standards for Test Management and
Documentation
Test plans encompass a number of different activities which should be
documented in a structured fashion.
Test programmes should include the following:
Test plan.
Test design.
Test case.
Test procedure.
Test log.
Test incident report.
All of these can be utilised for either white box or black box tests and at
any stage of the system life cycle, although the importance of
documentation increases in the later stages of testing.
These various activities broadly fall into three different types:
Planning.
Specification.
Reporting.
6.2 Test Plan
The test plan defines:
Scope.
Methods.
Resources required.

Figure 6. 6 Test Organisation
Test plan planning
reporting
Test log
Test incident report
specification
Test design
Test case
Test procedure

V2.0 6-21
Schedule of tests.
In addition, it allows the project manager to define and assess the risks
associated with the test plan.

The test plan will include the following items:
Test plan identifier - each test plan will have a unique identifier.
Resources required, the total time required or allocated for the test,
including computer time, staff time, technician support etc.
Introduction - this will be very brief and give a description of the
system or sub system to be tested.
Test items - this section will normally be a list of the tests that make
up the total plan. The tests themselves are described elsewhere.
Features to be tested - this should be a list of software features and
combinations of features to be tested.
Features not to be tested there may be specific features being
tested, but not all. If so, it is necessary to clearly identify, document
and exclude some features from the test.
Approach - this section will describe the testing methods which will be
used.
Pass/fail criteria - used in the test plan to define a global pass/fail
criterion. For example, if any error is found in any of the series of
tests, the whole series will be regarded as having failed.
Suspension criteria - the project manager/analyst must plan on the
basis of successful tests (tests that find errors). It is possible that
testing will be so successful that a very large number of errors is
found early in the test plan. Under these circumstances, it may be
sensible to suspend the tests until at least some of the errors have
been fixed. This section of the plan describes the conditions that
would cause the test plan to be suspended. Examples of this may
be:
the number of errors or error density;
Study Note
You should recognise that some forms of testing do carry risks.
Testers should seek to break a system with their tests, and therefore
the system they test should not be one that is currently in use for day-
to-day work. When it is necessary to carry out tests on a system that is
in use, it is normal practice to carry out those tests on a separate copy
of the software and data files, in a secure environment, to avoid
destroying valuable data.

the level of error (serious, critical, etc.);
the inability to run subsequent tests due to an error.
Resumption conditions - the definition of each type of suspension
criterion and the conditions under which the tests can be resumed.
Test deliverables - this is a list of all the documents associated with
the test plan.
Environmental needs - a summary of the hardware required to carry
out the test series, the data which is assumed to be already available
(i.e. static data) and any special test tools.
Responsibilities - the people and organisations who will be charged
with undertaking all aspects of the test plan:
staffing and training needs - identify the people carrying out the
tests, and any training needs;
schedules - a project plan for the tests, identifying milestones, test
dates, estimates etc;
risks and contingencies - identify where particularly high risk
assumptions have been made.
Approvals - this is the Quality Approval sign off.
6.3 Test Design
The test design describes how a particular system feature will be tested
and defines a series of test cases which will be used. There can be many
test designs for a test plan.
The typical contents of a test design are:
Test design identifier - a unique identifier for this set of tests.
Features to be tested - the specific feature that this test design is
intended to test. For each feature to be tested, a reference should be
provided to the specification item which supports the feature.
Test identification - lists the test cases which are needed, together
with a brief description.
Feature pass/fail criteria - a lower level pass/fail criterion, overriding
the global criterion.
6.4 Test Case
The purpose of the test case is to define specific tests. A test case may
be used by many test designs.
A test case consists of the following items:

V2.0 6-23
Test case identifier - a unique identifier for the test case.
Test description - a brief description of the test purpose.
Input specification - a definition of the data or input conditions which
are required to carry out the test. The specification should name all
the tables and fields which are to be used.
Output specifications - describes what is expected to happen as a
result of running the test.
Environmental needs - describes any special requirements for
carrying out this test, in addition to those given in the test plan.
Inter-case dependencies - all dependent tests which can only be
performed when this test has been performed, possibly without error;
all the tests which must be performed prior to this one.
6.5 Test Procedure
The test procedure describes how the test should be carried out. This is
important because the people carrying out the test may have little
familiarity with the system, and may have only limited IT experience. A
test procedure consists of the following:
Test procedure identifier.
Purpose - lists the entire test cases which are associated with the
procedure.
Procedure steps - describes what the tester should do. This is very
important when the testers are distinct from the development team.
Acceptance testing is a good example of this condition.

The steps should include:
Log - describes any special requirements for logging the test result.
Start up - describes how to set up the system before testing.
Procedure - special procedures to be followed during the tests.
Measurement - describes how any measurements should be made
(for example timings).
Shut down - describes how to terminate the series of tests.
Restart - describes the conditions under which the series of tests can
be restarted, perhaps after an error.
Wrap up - describes how to bring the entire environment back to a
controlled condition after the series of tests. This is a critically
important stage, since every test should start from known, controlled
conditions.

Contingencies - this section describes what to do if problems occur
during the test. For example, if a test caused the system to crash, the
tester might be unsure of what to do next. A development team
contact point is a possible general contingency action.
6.6 Test Log
The test log gives a chronological record of the test cases and is where
test results are recorded. The execution of each test procedure will result
in the production of a test log record. The test log is typically one line per
test case and consists of the following items:
Test log identifier - each test log will have a unique identifier.
Description - a brief description of any observation which applies to all
the tests, but does not warrant an exception report.
Individual Test Logs contain:
Date.
Time.
Name of person (all in the team) carrying out each test.
Result - actual observed output from the test.
Error flag - if the result is an error, this should be recorded.
Incident report identifier.
6.7 Test Incident Report
An incident is any test result that was not expected in the test case or
procedure. When such an incident happens, an incident report is
recorded.
An error does not require the production of an incident report. This is
consistent with the initial definition of testing objectives; by that definition,
an error is not an unexpected event.

V2.0 6-25
Figure 6.7 summarises the relationships between the different types of
test documentation, using a logical data model.

7 Velotec Testing
Velotec, in common with many other medium sized organisations, used to
rely on a combination of ad-hoc white box testing carried out by
programmers, some black box system testing led by the project manager
and other members of the team, and finally, some very limited acceptance
testing by either the business manager or his/her staff.
This unstructured approach to testing began to cause serious problems
some years ago, when a mission critical warehouse stock control system
was implemented. This system was used to control the receipt and issue
of exhaust systems from the large central warehouse. The system was
used both by logistics managers to make deliveries to the drive-in
workshops, and by the warehouse staff themselves. These people used
the system to inform them of the location in which to store each exhaust
system. This replaced a manual system where physical paper labels
were used for exhaust parts and specific segregated areas were used for
each type.
The system appeared to work reasonably well during system testing.
Some minor errors were located in the screens used by the logistics
teams and the system was implemented. Acceptance testing by the
business manager and system owner was extremely limited, since
typically the project was already late.

Further Reading
There is a large number of books available on software testing. For
example - Software Testing: A Craftsman's Approach; Paul C.
J orgensen
J ohn Wiley & sons; ISBN 0849308097
Figure 6. 7 Test Documentation
Test Plan
Test Case Test Procedure
Test Log Incident Report
Test Design

The system appeared to operate satisfactorily at first. The increase in the
utilisation of the warehouse was immediately noticeable, and the total
stock levels were reduced, improving cash flow. After about three months,
some problems began to appear. Workshops started to complain that the
exhaust parts they received were not the same as the order they had
placed. These orders were returned, leaving the warehouse staff with the
problem of deciding what the parts actually were, which was possible, but
used up a lot of warehouse staff time. This was not productive time and
was thus an overhead cost to the business. The problem gradually grew
worse, and the warehouse manager decided on a quick check of the
actual stock locations against the computer system records. This showed
that about 25% of the parts were not in the locations indicated by the data
records. The warehouse staff was blamed, but this view was quickly
reversed when the warehouse manager carried out sample physical
checks on the next day's work and found that nearly all the store locations
indicated by the new system were wrong.
At this point, an emergency work-around was instituted. All shipments
were manually selected by experienced workers, and deliveries from the
suppliers were halted. The workshops turned away customers for
exhausts, and a large scale, manual reorganisation of the warehouse was
started, to try to return to the old scheme. After three months the
warehouse was still in chaos, the workshops had lost about 30% of their
customers, and the company auditors placed a note in the accounts
stating that, because of the confusion, it was impossible to carry out an
effective stock check. The combination of these problems caused a major
fall in Velotec share prices and a credit squeeze by the exhaust system
suppliers.
Who is to blame for this failure?
What actions would you take to punish the guilty if you were the
Managing Director of Velotec?
Do you think that your actions would prevent a repeat of the problems?
Do not read any further until you have answered this question.

As a result of this experience, Velotec recognised that there were some
key changes that would have to be made to avoid a repeat of this
problem.
These included:
Improved project management techniques, so that risk analysis was
undertaken.

V2.0 6-27
A clarification of the roles and responsibilities of IS and business
managers, with respect to the implementation of new systems.
Improved testing procedures.
Write down the new testing procedures, using the ideas in this chapter
as a guide. Do not confine your answers to simple procedural issues.
Partly due to the experience described above, Velotec policy changed so
that only systems that were highly Velotec specific were developed in-
house. In most cases, ready to use package systems were to be bought
in, even if this meant that Velotec processes had to change to use them.
If you were the IS Manager, what, if any, testing procedures would you
suggest for the acquisition of package systems? J ustify your decisions.
8 Summary
We started this chapter with a particularly important set of definitions that
gave us a slightly counter-intuitive view of the reasons for testing. We
have built on those definitions to see that there are two distinct classes of
testing, those that assume internal knowledge of a system (white box),
and those that do not (black box). We have seen how testing is needed
at several stages in the software development life cycle and that the most
important aspect of this testing is the quality of the test design. We gave
some guidelines for test design, but recognised that this is a difficult
problem which cannot be automated.
The documentation of testing is critically important and we described a
scheme that provides both good documentation and a framework for test
management.
We have shown what a serious impact poor testing can have and the
human and organisational consequences which can arise from a testing
disaster.
Finally, we suggested throughout the chapter, some additional reading
which will help you to understand more about the contents of this chapter,
will help you in producing coursework and projects, and help you to
become a programmer or software engineer.


9 Answers
Answer 6.1
Quality cannot be added to a product like a coat of paint. It has to be
designed into the product and the process. Adding quality by testing is
therefore a very misguided idea.

Answer 6.2
Black box testing is usually the only possible choice for acceptance
testing by a customer. This is because the supplier will not usually release
source code to the customer. Without source code, white box testing is
not possible. Even if source code was released, it is most unlikely that
the customer will have sufficient expertise to be able to carry out white
box testing using it.

Answer 6.3
White box testing is almost always carried out by the programmers in the
development team. In an ideal situation, an external test team can be
hired to carry out some of this work, but this is uncommon in most
projects, because of the significant costs. A more practical compromise is
for programmers in the development team to test each others code.
The disadvantage of a programmer testing his/her own code is that the
programmer has probably invested a lot of time and effort in the code.
This makes it psychologically difficult to find ways to break the code and
find errors. This is not to suggest that the programmer will be consciously
resistant to finding errors (although this is possible), but simply that the
programmer will be unconsciously protective of his/her own creation.

Answer 6.4
It is usually not possible to test a unit without creating some further code
to support it. For example, if a module was a single C function (a very
common situation) the code could be compiled, but not directly executed,
because it is not a complete program. The minimum requirement would
be for a main function that provides the context for the function under
test. This is sometimes called scaffolding code because it supports a unit
during testing. The problem is that the scaffolding code may need to be

V2.0 6-29
quite complex, and the larger it gets, the more likely it is that errors will
exist in the scaffolding code. This can totally mask the errors in the
function under test, so the programmer has to debug the scaffolding code
before testing the actual function. Some automation of scaffolding code is
possible, but usually it needs to be written by hand.

Answer 6.5
The cause is almost certainly down to assumptions that are being made
by the two parts of the development team about how different parts of the
system communicate. This may be as simple as numerical data types that
do not match up properly or, it may be that the minispecs are badly
defined and entirely different approaches have been used. In this case, a
major re-engineering of the system will probably be necessary.
It is sad, but true, that the integration stage of big projects is often when
the first major problems are uncovered. The only way to avoid this is to
focus attention on the earlier part of the development life cycle and ensure
that the system design is properly specified. This is the area that you, as
IS Manager, should change.

Answer 6.6
Without an independent review, it would be very easy for a programmer
(or even a group of programmers) to add mischievous or even fraudulent
functionality into the application. A typical example would be a back door
that allows someone who is not authorised to gain access to critical data,
by using a predefined and hard coded password.

Answer 6.7
In most cases, the parent business is aware of the fact that their
applications contain Easter Eggs. Without deliberately encouraging their
production, they tolerate them provided that they do not compromise
functionality or delivery schedules. They do this because they help the
motivation of the development team, who often include their names as
credits. Programmers usually get no other exposure. The fact that some
Easter Eggs are quite sophisticated, but hidden, points out the need for
independent inspection. These inspections can only be carried out with
the use of the source code, which customers do not have access to.
(Except that is, with open-source systems such as LINUX, where you
could if you wished, inspect every line of the Operating System code to
check whether any security back doors exits).


Answer 6.8
Beta testing allows a supplier to obtain access to an enormous number of
testers, who are usually not paid for their efforts. In addition, beta testers
will use the system in ways that the supplier had not considered, so they
have a good chance of exposing new errors.
Reliance on beta testing at the expense of other types of testing is very
dangerous, because:
Some types of error may not be exposed by this approach;
If there are many errors, the beta testing process can become
extremely complicated and very lengthy. It may be more economical
to test thoroughly first.

Answer 6.9
Usability testing should be carried out by typical users, drawn from the
target population of users. Ideally, usability testing should be carried out
in a laboratory environment where the testers are given typical tasks to
perform and the way they accomplish the tests is observed. This is the
way that some very large software businesses test Windows applications.
Usability testing should never be carried out by the development team.
They are not typical users, and they start with an entirely different
knowledge of the system. The results from tests using them would be
useless for measuring usability.

Answer 6.10
No answer supplied for this exercise.

Answer 6.11
Blame is an unfortunate end product of most system development
disasters. Often this results in legal action. If you believe that firing
people is the appropriate answer, ask yourself how that would improve
the share price or prevent the problem from recurring. Who would you
punish? Is this a failure of the IS team or the business manager, or both?
Should not you as Managing Director, have taken a more direct
responsibility for a project that quite clearly had the potential to close the
business? Does this mean that you should resign?
In reality this project failed because the development process was
inadequate, risks were not properly understood, and the relationships

V2.0 6-31
between the development team and the business managers were unclear.
These things need to change.

Answer 6.12
It is not possible to provide an answer to this question without repeating
most of the second part of the chapter. You should have addressed:
Testing at different life cycle stages.
Roles and responsibilities.
Test tools and techniques.
Test documentation.

Answer 6.13
Package testing must, by definition, be black box based because you as
the customer have no access to the source code. Given this, you have to
ask yourself why you want to carry out the testing and what results you
are looking for.
If you have purchased the package against your own fully defined system
specification, then you could carry out full system testing against the
specification. This is an extremely unlikely scenario, since the entire
rationale for a package is that it is based on the supplier's own internal
specification, not that of a single customer. It is therefore very unlikely that
the supplier will agree to supply a package on the basis of specifically
meeting your specification.
If you have purchased the package as a shrink-wrapped product, testing
against your specification might tell you whether the product is a good fit
with your requirements. If it is not, you will not be able to change the
package, but you may be able to choose another instead.


V2.0
Systems Development - Glossary
American Standard
Code for
Information
Interchange
(ASCII) The commonly used 7 bit character encoding
standard.
Array A simple data structure.
Assembly
Language
A low level programming language.
BASIC A simple programming language.
Binary A number system with a base of 2.
Browser The application used to view HTML.
Business Model A model that shows how a business interacts with
suppliers, customers and others.
Bytecode The code used for compiled J ava.
C A higher level language, very widely used for many
applications.
C++ An Object Oriented language descended from C and
largely compatible with it.
Cartesian
Co-ordinates
A co-ordinate system based on rectangular x and y axes.
Compiled Program A program that has been translated by a compiler.
Context Diagram A top level data flow diagram.
Data Flow Diagram A modelling technique in which data stores, processes
and data flows are displayed graphically.
Data Modelling A modelling technique in which entities and their
relationships are displayed graphically.
Data Models A model that shows entities and their relationships.
Database A collection of related data.
Database
Administrator
The person who is responsible for designing and
maintaining databases so that they meet performance
Glossary Systems Development

NCC Education. All rights reserved. Unauthorised duplication is prohibited.
and security requirements.
Database Design The process of defining the structure of a database.
Decimal A number system with a base of 10.
Decision Table A technique for displaying complex logic in a simple
tabular diagram.
Entity Life History A modelling technique that graphically displays the stages
a data entity passes through.
Event-Driven
System
A system that must be able to respond to any possible
user or system event, regardless of any other processing
taking place.
Feasibility Study An initial investigation that determines whether a system
will be cost-effective and realise the benefits that are
expected.
GOTO A programming construct that is deprecated for structured
programming.
Hexadecimal A number system with a base of 16.
Interpreter A source code translator that translates and executes
code one line at a time.
Java A language designed to be especially useful for web site
automation as well as other application areas.
Java Applet A small J ava application used with a web browser.
Logic Gate A fundamental unit of digital electronics, implementing a
simple logical function.
Machine Code The binary instructions that can be directly executed by
the CPU.
Matrix A data structure with rows and columns containing
numeric or other data.
Non-procedural
language
A language in which the programmer defines what the
program should do, not how it should be achieved.
Object Technology The application of Object Oriented techniques to different
stages in the development life cycle.
Octal A number system with a base of 8.
Procedural
Language
A language in which the programmer defines in detail how
the program should work.
Systems Development Glossary

V2.0
Prototyping A development technique in which a simple, limited model
is built to demonstrate some aspects of system
functionality.
Pseudo Code A technique for program specification in which highly
structured English with indentation and program like
control structures is used to describe the required logic of
a program.
Queue A simple FIFO data structure.
Range A simple measure of the spread of a data set.
Requirements
Analysis
Requirements Analysis is concerned with discovering
what a new system is required to do.
Software
Development Life
Cycle
The definition of the stages in the life of a software
product, and the relationships between those stages.
Software
Engineering
The practical application of scientific knowledge to the
design and construction of computer programs and the
associated documentation required to develop, operate
and maintain them.
Stack A simple LIFO data structure.
Standard Deviation A fundamental measure of the spread of a data set.
Structured
Flowchart
A flowchart in which a disciplined approach is used to
depict program flow using only Sequence, Selection and
Iteration.
Structured Query
Language (SQL)
A language used to query and manipulate data in a
database.
System Design The activity of proceeding from an identified set of
requirements for a system to a design that meets those
requirements.
Systems Analysis The systematic assessment of business functions with the
intent of improving organisational practice.
Systems
Maintenance
Activities that allow an application to continue in effective
use.
Glossary Systems Development

NCC Education. All rights reserved. Unauthorised duplication is prohibited.

Unicode An international standard used to encode all the major
character sets of the world.
Venn Diagram A diagramming technique useful for displaying sets and
their relationships.
Visual Basic (VB) A proprietary Microsoft language frequently used for
simple applications.
Waterfall Life Cycle A traditional and limited software development life cycle
model.

www.nccedu.com

Feedback

NCC Education would be pleased to receive any
comments you may have relating to this workbook.

Email: customer.services@nccedu.com

Or write to us:

Customer Services Department
NCC Education Ltd
The Towers, Towers Business Park
Wilmslow Road, Didsbury
Manchester, M20 2EZ
UK

Fax Number: +44 0161 438 6240.

Please include your name, address, telephone number
and clearly state the workbook title, and page numbers
where appropriate.
NCC Education

International Diploma in
Computer Studies
(
IDCS
)
2008
Systems Development
This workbook addresses the main topics
and issues associated with the
computer-based system development
process used within a typical business
organisation. The intention is to provide
the student with the requisite skills
and understanding to enable them to
become involved with systems development
projects in a meaningful way, with both
technical specialists and business managers.
The areas covered by the workbook include:
Organisational aspects of systems
development and the need for
a collaborative approach to this
Application of simple mathematical
techniques to solve problems in the design
and implementation of computer systems
Basic principles, activities and deliverables
associated with popular life cycle models
Key elements of leading analysis and
design methods
Requirements for documentation and
coding standards
Role of testing in software development
A case study is used throughout the
workbook to illustrate the practical aspects
of systems development.
For any other enquiries please contact one of our regional offices:
UK & Europe - Tel +44 (0) 161 438 6200 | Africa and the Caribbean - Tel +27 (0) 21 913 8928
East Asia - Tel +86 (0) 10 6518 9327 | Middle East and South Asia - Tel +971 (0) 4 391 2727
South East Asia - Tel +60 (0) 3 7710 5755
ISBN 0954307108

SD Textbook 2008syllabus

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SD Textbook 2008syllabus

Uploaded by

Copyright:

Available Formats

International Diploma in

You might also like