oblivion软件开发方法外文文献

Software Development Methodologies

Introduction

Software methodologies are concerned with the process of creating software - not so much the

technical side but the organizational aspects. In this, the first of two articles, I will introduce the

different types of methodologies. I will describe them from an historical perspective, as one way

to understand where we are and where we are going is to know where we have been.

There

will

also

be

a

subsequent

companion

article

looking

at

the

current

state

of

the

art

and

what I believe the future holds. This second article is given the rather controversial title of

Creating

Software

is

not

Engineering

which

I

will,

of

course,

explain.

In

the

2nd

article

I

will

discuss

several

popular

agile

methodologies

particularly

their

most

important

aspects

(such

as

unit testing), which are generally neglected or glossed over.

Before beginning I should warn the reader of my penchant for analogy. Actually this whole article

is one big analogy stretched almost to breaking point. I like them because many of the concepts

in software development are abstract and hard to grasp, but using a familiar real-world situation,

like taking a taxi to the pub, can clarify the ideas. Of course, there is always the caveat that no

analogy is perfect. Be careful to understand the similarities and the differences.

Ad-hoc

Historically, the first methodology was basically no methodology at all. This is generally called the

We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have

no idea where that is but you jump in a cab and tell the taxi driver where you want to go. A few

minutes later you arrive at your destination safely and without wasting any drinking time!

In this analogy you are the

ideal case where the customer knows where they want to go and the developer knows how to

get there. Unfortunately the real world is never this simple. Consider these variations.

Problems

1.

You

tell

the

driver

where

to

go

but

you

end

up

at

the

train

station

not

the

Station

Hotel.

Obviously he misheard you and after all many of his passengers go there.

You

clarify

the

situation

but

the

taxi

driver

is

uncommunicative

and

you

end

up

at

the

wrong

hotel. Eventually, you work out that the driver does not speak English well.

At some point you give up. If you are really persistent you might get to your destination but by

then Jim has already left.

2. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is

one?

went to. You try them all but can't find Jim.

The driver suggests it might be the

you started.

3. The taxi driver kindly informs you that your destination is quite distant and you do not have

enough money. He suggests that you take the bus.

Of course, the bus is slow and does not go directly past the pub. You get there eventually.

4. The taxi takes you straight to the hotel but it's closed for business.

5. You are half way there when you realise you need to post a letter. Then Jim calls your mobile

and says that he has gone to a different hotel. Then you get stuck in traffic and also need to use

the bathroom. The whole trip is much longer and more expensive than expected.

6.

The

taxi

driver

seems

to know

where

to

go

but

is

inexperienced

and

after

quite

a

while

he

realises that he is going completely the wrong direction. Several times he has to backtrack but

eventually finds the destination though the trip takes much longer than expected.

I'm sure you can think of many more things that can go wrong.

Summary

The ad-hoc methodology can work provided you have a simple problem. If the customer knows

exactly what they want and the developer knows how to give it to them and has the right tools to

do so (a reliable vehicle and a street directory if necessary) then there is a good chance of success.

However, most of the time you get there late or not at all.

The above scenarios represent several common problems seen in software development, namely

miscommunication (1), a customer who doesn't know exactly what they want (2) or thinks they

do until they try it (4), changing requirements (5) and inexperienced developers (6). I leave it the

reader to work out what scenario 3 means.

Waterfall

OK, you want to avoid all the above problems, but what do you do? Conventional wisdom is to

ask an expert for help and there are many willing helpers ready to provide their services, for a fee,

of course. You find that you need an

The

analyst

works

out

by

deduction

and/or

educated

guesswork

exactly

which

Hotel

you want. Perhaps they even manage to contact Jim to confirm the location. They also find out

the exact address and the opening hours.

Now

you

know

exactly

where

you

want

to

go

but

how

to

get

there?

The

designer

provides

a

- eg proceed 2 miles to the roundabout,

take the 3rd exit, etc. To ensure that the driver understands the instructions the essential parts

are

even

translated

into

his

native

language.

A

good

designer

might

also

try

to

anticipate

problems and have contingency plans - eg, if the freeway has heavy traffic to take an alternative

route.

The

essential

point

of

the

specification

is

to

have

the

trip

completely

and

thoroughly

planned

before

starting

out.

Everybody

involved reads

the

specification

and

agrees

that

this

should

get

the customer to the pub on time. Can you see a problem with this approach?

While the analyst/designer is busy at work you (the customer) are getting a bit nervous. It's been

some time and you still haven't gone anywhere. You also want feedback that once you start the

trip everything will stay on track, since your experience of taxi journeys is that they can be very

unpredictable and the driver never gives any indication of whether he is lost or on course.

You need a

amiss it will be immediately apparent. The plan will also require the driver to regularly report his

position so you know if he is going to be late or not get there at all. For a large project you will

need a

Problems

This all sounds very thorough and reassuring but there are many problems with this approach.

1. First the taxi driver has to read and understand the whole specification before starting out - for

example,

he

might

have

to

work

out

where

he

can

buy

fuel

if

necessary.

The

specification

is

complex

and

detailed

and

it

can

take

some

time

before

the

driver

understands

it

enough

to

begin.

2.

The

taxi

driver

attempts

to

follow

the

specifications

exactly

but

there

are

a

few

small

ambiguities and he makes a wrong assumption. By the time he realises the mistake he has gone

for miles in the wrong direction and has to backtrack.

3. There are crucial assumptions in the specification that nobody checked. For example, you can

never get a taxi after 8pm on a Friday. The designer had not considered this but his excuse is that

it was outside his purview - the customer should know this since he is the one that catches taxis

and after all he signed off on the specification.

4.

Things

happen

that

were

not

anticipated.

For example,

unexpected

traffic

snarls

cause

slow

progress.

5. There are problems that the designer was not aware of. For example, roadworks that require a

lengthy detour. The taxi driver knew about it but nobody asked him.

6. There are problems that nobody was aware of. For example, the planned route goes the wrong

way down a one-way street, even though it was not marked as such on any map.

7. There are some things that you (the customer) forgot to mention - eg, you need to stop at the

bank to get some cash on the way. It seems like a minor thing to you, but the designer complains

that it completely invalidates most of the specifications (though he exaggerates of course).

8. There are unexpected events that nobody could have anticipated such as a major accident that

causes traffic chaos.

9. The taxi driver becomes annoyed and frustrated with the process.

to go!

10.

The

project

plan

estimates

that

the

journey

will

take

an

hour.

The

passenger

immediately

starts reading a book or falls asleep in the back seat. The taxi driver thinks it will take half that

time, especially as he knows a shortcut. He dawdles for awhile, makes some detours to take care

of

some

personal

business,

and

loses

track

of

the

time.

The

customer

wakes

up

and

wonders

where he is - the driver assures him that all is going to plan.

However by now there is only 15 minutes to go and he's hardly made any progress. He finds the

road for his shortcut has been closed, then gets booked for speeding. In the end he makes a huge

effort and only arrives 20 minutes late. Ironically, he is praised by all for being so dedicated.

11.

The

designer

knows

from

past

experience

that

taxi

drivers

vary

widely

in

ability.

The

specification

is

written

to

the

lowest

common

denominator,

even

though

this

demeans

the

average taxi driver.

12. The designer knows that the taxi driver has a tendency to deviate from his specification. This

can be at the behest of his passenger (see 7 above), or he may take the scenic route to make the

trip more pleasant (and increase the fare), or take a shortcut that may save time but has many

risks involved, or simply take a diversion out of some personal interest.

To counter this, the designer will try to limit the information provided to the driver to only what

they need to know. As an extreme example the designer might cover all the windows of the taxi

and make the driver navigate entirely using the odometer and a compass. Obviously, this a very

dangerous approach as the driver has no feedback at all in order to correct for even the slightest

deviation from the course.

13.

You start the journey but there are a lot of problems and delays. You manage to contact Jim

and arrange to meet him at a nearby hotel which is actually more convenient for both of you.

(Unfortunately this completely invalidates the specification which is discarded.)

Summary

The waterfall model can work if everything goes to plan, but in a complex project things rarely do.

The crux of the problem is the reliance on getting the specification perfect before attempting to

implement it. Unfortunately, even if you get close to getting it right at the start things will change.

For most real-world projects this means this approach is doomed to failure, or at best a late and

over-budget project and a very frustrating experience.

The

above

scenarios

represent

several

common

problems

with

the

waterfall

methodology

namely the difficulty of understanding (1) and following the specifications (2) and getting them

right in the first place (3, 5, 6, 7). The process does not cope with change (4, 8, 13) and does not

make best use of the developers (9, 11, 12).

A major problem is that without hard deliverable milestones most developers will procrastinate

at the start (10). However, to be fair this behaviour is reinforced by the fact that the most projects

have major changes (or are even cancelled) well after development has started. To the developer

there is no point in working hard at the start when in all likelihood the effort will be wasted.

Prototype

The

prototype

methodology

addresses

the

major

problem

of

the

waterfall

methodology's

is difficult or impossible to prove that the specification is correct so we instead create a simple

working example of the product, much like an architect would create a scale model of a proposed

new building.

To continue our taxi analogy the designer, or a delegate, grabs a motorbike to first check that you

can

actually

get

to

the

Station

Hotel

and

even

explore

a

few

alternative

routes.

When

the

motorbike driver has found a good way the actual taxi trip can begin.

Problems

1. A motorbike is not a car. It can bypass traffic snarls or pass through narrow lanes that a car

cannot. In his eagerness to prove the feasibility of the trip the designer may gloss over the fact

that the taxi trip will take a lot longer.