Software Engineering For Students: A Programming Approach Part 6 pptx

28 Chapter 2 ■ The tasks of software development
2.1 Discussion question on validation and verification: What do the following mean, what is
the difference between them, and which is better?
■ a program that works (but doesn’t meet the specification)
■ a program that meets the specification (but doesn’t work).
2.2 Discussion question on validation and verification: What do the following terms mean
and how do they relate to one another (if at all):
■ correctness
■ working properly
Summary
We have identified a list of tasks that are part of software development. All of them
must be carried out somehow during development.
A process model is a strategic plan for the complete process. Different process mod-
els offer alternative suggestions as to exactly how and when tasks are carried out. As
we shall see, in some process models all of the stages are visible, while in other
process models some of the stages vanish or become part of some other stage.
A methodology is a complete (often proprietary) package of methods, tools and
notations.
Hacking is an approach to development that is highly skilled but ill-disciplined.
Exercises
•
There is one notorious approach to software development, called hacking. There are
actually two types of hacker:
■ the malicious hacker who breaks into computer systems, often using the internet, to
commit fraud, to cause damage or simply for fun
■ the programmer hacker, who uses supreme skills, but no obvious method, to develop
software.
It is the second of these meanings that we will use in this book. Hacking is often dis-
paraged in software development circles because it appears to be out of control.
However, the display of skill also earns hackers praise. Hackers also obviously enjoy
what they do and relish their skills. We will return to the subject of hacking in the chap-

ter on open source development.
2.5
●
Hacking
BELL_C02.QXD 1/30/05 4:14 PM Page 28
Answer to self-test question 29
■ error free
■ fault
■ tested
■ reliable
■ meet the requirements.
Answer to self-test question
2.1 Architectural design, unit testing, project management, configuration man-
agement and version control.
BELL_C02.QXD 1/30/05 4:14 PM Page 29
Every software project begins with a judgment as to whether the project is worthwhile
or not. This is called a feasibility study. Sometimes this assessment is carried out in a
detailed and systematic fashion; and sometimes it is carried out in a hurried and ad hoc
fashion; and sometimes it is not carried out at all. In this chapter we outline a frame-
work for assessing whether a software system is worthwhile.
There are two types of computer system:
■ a system that replaces an existing computer-based system
■ a brand new system that replaces or enhances work that is not currently computer-
assisted.
Another categorization is:
■ a general purpose system, such as a word processor or a game. This is written and
then sold in the market place
■ a tailor-made one-off system for a specific application.
Remember also that there is often the choice between writing the software and buy-
ing it off the shelf.

3.1
●
Introduction
CHAPTER
3
The feasibility study
This chapter:
■ explains the role of a feasibility study
■ suggests how to go about conducting a feasibility study.
BELL_C03.QXD 1/30/05 4:14 PM Page 30
3.3 Cost-benefit analysis 31
Before beginning a project, there is a crucial decision that must be made: Is the pro-
posal technically feasible? That is, will the technology actually work? We know, for
example, that a system to predict lottery results cannot work. But a system to recognize
voice commands is borderline. A system to download and play DVD-quality movies
into people’s homes is also borderline.
In engineering, there has long been a tradition of assessing available technology, for
example, the use of reinforced concrete in building. Similarly in computer-based infor-
mation systems, a number of techniques have been used in advance of building a system
in order to determine whether the system will be worthwhile.
Money provides the ready-made metric for measuring value. This kind of investiga-
tion is called investment appraisal or a cost-benefit analysis. The organization expects a
return on investment. In this approach two quantities are calculated:
1. the cost of providing the system
2. the money saved or created by using the system – the benefit.
If the benefit is greater than the cost, the system is worthwhile; otherwise it is not.
If there is some other way of accomplishing the same task, which may be manually,
then it is necessary to compare the two costs. Whichever technique gives the smaller
cost is the one to select, provided that the benefit is greater than the cost.
Costs and benefits are usually estimated over a five year period. This means that the

initial start-up costs are spread over the expected useful life of the system. Five years is
the typical lifetime of a computer-based system. Beyond this time, changes in technol-
ogy as well as changes in requirements make predictions uncertain.
Many evaluation criteria are common to all computer systems – and indeed to all
products designed for some useful purpose. Thus motor cars, buildings and televisions
need to be reliable, robust, easy to maintain, easy to upgrade. The obvious, central con-
sideration is the construction cost. With each of these criteria we can associate a cost,
though for some it is less easy:
■ cost to buy equipment, principally the hardware
■ cost to develop the software
■ cost of training
■ cost of lost work during switchover
3.3
●
Cost-benefit analysis
3.2
●
Technical feasibility
BELL_C03.QXD 1/30/05 4:14 PM Page 31
32 Chapter 3 ■ The feasibility study
■ cost to maintain the system
■ cost to repair the equipment in the event of failure
■ cost of lost work in the event of failure
■ cost to upgrade, in the event of changed requirements.
The upgrade cost is part of the cost of some future system and not strictly part of
the current costing, but is worth bearing in mind at the evaluation stage.
While all of these costs should be estimated in advance of developing a system, it is
in practice very difficult to estimate the cost of construction and of maintenance.
It is easy to be drawn into judging everything on the basis of costs, but there are other
approaches.

Many people develop software purely for fun. Open source programmers are a prime
example. Their motivations include providing useful tools, enjoying the act of pro-
gramming and collaborating with others.
Large military projects are sometimes funded because they are considered necessary
(militarily or politically), whatever the cost.
Some people, perhaps seduced by technology, take the view that a computer system
is obviously better than a manual system.
Some systems are, arguably, socially useful and, perhaps, outside the scope of a costing-
based approach. How can we meaningfully assess the value of a system that allows a patient
to book a medical appointment, or a system that provides information on bus arrival times
at bus stops?
3.4
●
Other criteria
SELF-TEST QUESTION
3.1 Suggest another system for which cost-benefit analysis is probably not
appropriate.
We will examine carrying out a feasibility study of the software for an ATM, outlined
in Appendix A. An ATM is part hardware, part software, so we could either carry out
a feasibility study for the complete system or limit ourselves to the software component.
However, if we are assessing the viability on the basis of cost, we must look at the com-
plete system.
We first look at costs of construction. We expect that the ATM is not just a one-off
but that a number of them will be built and deployed. Let us assume that 200 machines
will be needed.
3.5
●
Case study
BELL_C03.QXD 1/30/05 4:14 PM Page 32
3.5 Case study 33

The hardware cost includes the processor, the card reader, the display, the screen,
the key pad, the printer, a cash dispenser and a modem. We presume that these can be
bought off the shelf rather than specially designed and made. We could estimate the
cost of the hardware for each ATM at $10,000. In addition there is the cost of
installing the machines in a secure fashion. There will probably be a need for extra serv-
er capacity at the bank in order to handle the requests from ATMs. An estimate for the
total hardware costs is $20,000 per ATM.
Running costs include the telephone line charge, replacing printer paper, stocking
the ATM with cash.
Now we attempt to estimate the software cost. The software is relatively complex
because it uses a number of special devices. There is software in each ATM, plus the
software at the bank to handle requests from ATMs. The ATM software must be robust
and reliable because it is used by members of the public. We could adopt such tech-
niques as those explained in Chapter 30 to predict the software cost, but these tech-
niques are poor, and anyway, as we shall see, we only need a ball park figure. Suppose
we guess two person years for the software. Suppose that this equates to $100,000. But
this cost must be shared across the 200 machines, which is $500 per machine. This is
about 2–5% of the cost of each ATM – an insignificant component. This is typical of
software costs in embedded systems, where the software is simply one component
among many others.
What about the benefits of providing ATMs? No doubt ATMs are convenient,
available 24/7 hours in stations, stores and public buildings. But most banks are not
philanthropists – their mission is not to serve the public, but to make a profit. The
provision of ATMs might attract customers to the bank and this benefit could be
costed. This would probably be only a temporary advantage, until other banks
caught up. However, most banks in the industrialized world have reduced jobs by
computerization and this is probably the significant cost benefit. We might estimate
that a single 24-hour ATM would replace two full-time cashiers. This is a saving of,
say, $40,000 each per year. (This is not simply salaries, but includes other costs, such
as office space.)

So, in summary, over a five-year period for each ATM:
Costs Benefits
cost of hardware $20,000 staff costs $400,000
cost of software $500
cost of maintenance $4,500
total $25,000 total $400,000
Should the ATMs be developed? The conclusion speaks for itself.
Now, all these figures are indicative, but the point is to see how to go about cost-
benefit analysis. We can see that assessing the costs and the benefits of a system is com-
plicated and time-consuming. It is not an exact science and some guesses usually have
to be made.
BELL_C03.QXD 1/30/05 4:14 PM Page 33
34 Chapter 3 ■ The feasibility study
It is notoriously difficult to predict the cost of a system and therefore it is very difficult
to carry out a feasibility study. This may explain why it is common to ignore it. There is,
however, another common reason for avoiding a feasibility study: once an idea for a sys-
tem has been suggested, the project generates its own momentum, people become
committed to it and it cannot be stopped. Instead people talk about a business case for the
system, which tends to emphasize the positive aspects while minimizing the negative.
Bear in mind that sometimes the feasibility study plays a large part in deciding that
the project should be abandoned.
3.6
●
Discussion
SELF-TEST QUESTION
3.2 If the software cost were doubled, would the decision be the same?
Summary
A feasibility study is an investigation to check that a development is worthwhile. It
is carried out at the start of a project. It assesses technical feasibility and costs.
Cost-benefit analysis compares the cost of developing the system with the money

saved by using it. The costs include development, additional hardware, maintenance
and training.
Exercises
•
3.1 Suggest how a feasibility study would be conducted for each of the systems outlined
in Appendix A.
3.2 Discuss the validity of using cost-benefit analysis, especially in socially useful appli-
cations.
BELL_C03.QXD 1/30/05 4:14 PM Page 34
Further reading 35
Further reading
•
A collection of papers that looks at the topic from a variety of perspectives is the fol-
lowing title. Some non-computer case studies are presented. Richard Layard and
Stephen Glaister (eds), Cost-Benefit Analysis, Cambridge University Press, 1994.
Answers to self-test questions
3.1 There are a number of possible systems. For example, aids for disabled
people.
3.2 Yes. The software cost is only a small part of the cost. The benefits over-
whelm the costs.
BELL_C03.QXD 1/30/05 4:14 PM Page 35
Logically the first stage of software development is to establish precisely what the users
of the system want. The dominant part of this stage is communication between the
users and the software developer or engineer. When the engineers are dealing with
requirements, they are normally referred to as systems analysts or, simply, “analysts”.
This is the term we shall use. As far as the users are concerned, they are sometimes
known as clients or customers. We will use the term “user”.
The story begins when a user has an idea for a new (or enhanced) system. He or she
summons the analyst and thereafter they collaborate on drawing up the requirements
specification. The user’s initial idea may be very vague and ill-defined, but sometimes

clear and well-defined.
Arguably, establishing the requirements is the single most important activity in soft-
ware development. It typically consumes 33% of the project development effort. If we
cannot accurately specify what is needed, it is futile to implement it. Conversely, we
could implement the most beautiful software in the world, but if it is not what is need-
ed, we have failed. In the real world of software development there are strong indica-
tions that many systems do not meet their users’ needs precisely because the needs were
not accurately specified in the first place.
4.1
●
Introduction
CHAPTER
4
Requirements
engineering
This chapter:
■ explains what happens during requirements engineering
■ explains the nature of a requirements specification
■ explains how to employ use cases in specifying requirements
■ explains how to draw use case diagrams
■ suggests guidelines and checklists for writing good specifications.
BELL_C04.QXD 1/30/05 4:15 PM Page 36
4.2 The concept of a requirement 37
Establishing the requirements for a software system is the first step in trying to
ensure that a system does what its prospective users want. This endeavor continues
throughout the software development and is called validation.
The requirements specification has a second vital role. It is the yardstick for assess-
ing whether the software works correctly – that it is free from bugs. The job of striving
to ensure that software is free from errors is a time-consuming and difficult process that
takes place throughout development. It is called verification.

Errors in specification can contribute hugely to testing and maintenance costs.
The cost of fixing an error during testing can be 200 times the cost of fixing it dur-
ing specification. It is estimated that something like 50% of bugs arise from poor
specification. The remedy of course is to detect (or prevent) bugs early, that is, dur-
ing specification.
It is easy to write poor requirements specifications for software; it is difficult to write
good specifications. In this chapter we will examine guidelines for writing specifications.
Remember that specifications are not usually written once and then frozen. More
typically, requirements change during the software development as the users’ require-
ments are clarified and modified.
The task of analyzing and defining the requirements for a system is not new or peculiar to
software. For generations, engineers have been carrying out these activities. For example,
the following is part of the requirements specification for a railway locomotive:
On a dry track, the locomotive must be able to start a train of up to 100 tonnes on an
incline of up to 30% with an acceleration of at least 30 km/h/h.
This statement serves to emphasize that a requirement tells us what the user (in this case
the railway company) wants. It says nothing about how the locomotive should be built.
Thus, it does not state whether the locomotive is diesel, coal or nuclear powered. It says
nothing about the shape or the wheel arrangements.
One of the great controversies in computing is whether it is desirable (or even possible)
to specify what a system should do without considering how the system will do it. This is
the relationship between specification and implementation. We will now look at both sides
of this argument.
On the one hand, there are several reasons why the requirements specification
should avoid implementation issues. The prime reason is that the user cannot reason-
ably be expected to understand the technical issues of implementation and cannot
therefore be expected to agree such elements of the specification. To emphasize the
point, how many users of a word processor really understand how software works? A
second reason for minimizing implementation considerations is to avoid unduly con-
straining the implementation. It is best if the developer has a free reign to use whatever

tools and techniques he or she chooses – so long as the requirements are met.
4.2
●
The concept of a requirement
BELL_C04.QXD 1/30/05 4:15 PM Page 37