Software Engineering - Software engineering successes?

Author

Software engineering successes?

Edd Stewart

2004-05-04, 2:35 pm

Friends,

I am due to give a lecture to some students at my local college on the
subject of ethics in computing. Much of it will focus on the inquiry into
the London Ambulance Service's CAD system (which was an infamous failure due
to poor management and engineering practices). I would like to finish the
piece with a section on lessons learnt from such failures illustrated by a
number of successful projects; however I can find little information. Can
anyone with knowledge on appropriate projects please post in reply. Any
information would help greatly.

Kind Regards, Edd Stewart

Peter Amey

2004-05-04, 2:35 pm

Edd Stewart wrote:
> Friends,
>
> I am due to give a lecture to some students at my local college on the
> subject of ethics in computing. Much of it will focus on the inquiry into
> the London Ambulance Service's CAD system (which was an infamous failure due
> to poor management and engineering practices). I would like to finish the
> piece with a section on lessons learnt from such failures illustrated by a
> number of successful projects; however I can find little information. Can
> anyone with knowledge on appropriate projects please post in reply. Any
> information would help greatly.
>
> Kind Regards, Edd Stewart
>
>

There are some good successes on www.sparkada.com. Have a look at
"Correctness by Construction: Developing a Commercial Secure System"
under "Publications" for one example.

Peter

Phlip

2004-05-04, 2:35 pm

Edd Stewart wrote:
> Friends,
>
> I am due to give a lecture to some students at my local college on the
> subject of ethics in computing. Much of it will focus on the inquiry into
> the London Ambulance Service's CAD system (which was an infamous failure
due
> to poor management and engineering practices). I would like to finish the
> piece with a section on lessons learnt from such failures illustrated by a
> number of successful projects; however I can find little information. Can
> anyone with knowledge on appropriate projects please post in reply. Any
> information would help greatly.

The problem here is that really big projects tend to administrate themselves
into certain failure. But the successful projects out there are all small,
humble, and don't look like "big successes" on paper.

This is a pity, because modern software administration practices are
learning that keeping projects small is a good way to ensure success. But
that's hard to explain to those who want to toast more and more money on the
big ones.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Bradley K. Sherman

2004-05-04, 2:35 pm

In article <c781c8$2fu6$1@godfrey.mcc.ac.uk>,
Edd Stewart <eddstew@hotmail.com> wrote:
> Friends,
>
> I am due to give a lecture to some students at my local college on the
>subject of ethics in computing. Much of it will focus on the inquiry into
>the London Ambulance Service's CAD system (which was an infamous failure due
>to poor management and engineering practices). I would like to finish the
>piece with a section on lessons learnt from such failures illustrated by a
>number of successful projects; however I can find little information. Can
>anyone with knowledge on appropriate projects please post in reply. Any
>information would help greatly.

I asked this same question of Peter Neumann (comp.risks moderator)
some years ago. His response was the Space Shuttle software
systems.

I would add the integration of TCP/IP into Berkeley Unix which
started Internet participation on an exponential growth curve.

--bks

Alan Gauld

2004-05-04, 7:06 pm

On Tue, 4 May 2004 13:12:56 +0100, "Edd Stewart"
<eddstew@hotmail.com> wrote:
> the London Ambulance Service's CAD system (which was an infamous failure due
> to poor management and engineering practices). I would like to finish the
> piece with a section on lessons learnt from such failures illustrated by a
> number of successful projects;

There are dozens of large successful software projects out there
but they don't make headlines and so don't get written about. In
fact it seems that some folks have gotten to the point of
thinking that all big projects fail or even that most do which is
nonsense, its just that the successful ones tend not to be hugely
visible.

In the past 15 years or so I've been involved in around a dozen
big projects (how big is big? They lasted over 1 year each and
had over 20 people working on them...totally arbitrary I know -
the biggest lasted 5 years and had several hundred people on it
at peak). All but 2 were successful in that they delivered on the
agreed date and pretty much did what was expected. Sure there
were bugs and change requests galore but that happens on projects
big and small, but the systems were sufficiently usable that the
users were happy.

So how des that help you? I don't know because none of these
projects has been written up so far as I know. Why would they be?
They were just run of the mill software engineering. Some used
waterfalls some used DSDM some used other iterative techniques
but they all had solid project management, sensible customers,
and sufficient budget to complete the job!

The BCS web site might help, since they have a software
competition each year which looks at successful projects...

HTH,

Alan G.

Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

xpyttl

2004-05-12, 9:06 pm

"Alan Gauld" <alan.gauld@btinternet.com> wrote in message
news:n8ki90l8cge64ekd8egdn8885cgf5fkho8@
4ax.com...

> The one area you will notice that I haven't declared successful
> is cost. Estimation is as bad for big projects as for small and
> all of the above projects were probably 50-100% over budget.

I would disagree with that. Many organizations have gotten the cost
estimation thing down, especially shops at higher CMM levels. I had the
experience of being in a shop as they made the transition from CMM level 1
to 3. When we were at level 1, the 50-100% thing was probably pretty
close -- if we came within 50% of the cost it was considered a success. At
level 3, indications that there might be a 10% overrun in a large project
would bring all sorts of attention from directors and vice presidents. One
big difference is that the possibility that the project was in trouble would
be identified much earlier. With reasonable project controls, projects
simply don't go well over budget or schedule.

I think small projects tend not to be as good. One reason is that they
don't get as much attention. The other is that on a small project, some
little misstep can result in a large percentage overrun. In a larger
project, a little hiccup isn't such a big deal, and you learn from it so you
don't repeat. If you do repeat, all that attention means that you get the
right resources so you don't keep doing it wrong.

...

Richard Riehle

2004-05-12, 9:06 pm

"Bradley K. Sherman" <bks@panix.com> wrote in message
news:c7bhbi$chv$1@panix3.panix.com...
> In article <vk1g909fth41sgchapgi4krbqu71q5at4n@4ax.com>,
> Alan Gauld <alan.gauld@btinternet.com> wrote:
failure due[color=darkred]
the[color=darkred]
by a[color=darkred]
>
> Well, how about naming three? Or one even.

Hellfire missile.
F-177A
B-2
B-1
AWACS
Intelsat VII
You local ATM machine
The software that drives your digital camera

The list could go on and on and on. But this should suffice for now.

Richard Riehle

Alan Gauld

2004-05-12, 9:06 pm

On Thu, 6 May 2004 08:06:33 -0400, "xpyttl"
<xpyttl_NOSPAM@earthling.net> wrote:

>
> I would disagree with that. Many organizations have gotten the cost
> estimation thing down, especially shops at higher CMM levels. I had the
> experience of being in a shop as they made the transition from CMM level 1
> to 3. When we were at level 1, the 50-100% thing was probably pretty
> close -- if we came within 50% of the cost it was considered a success. At
> level 3, indications that there might be a 10% overrun in a large project
> would bring all sorts of attention from directors and vice presidents.

We are a CMM Level 3 org and average about 30%-50% success in
estimation. But if we get the chance to estimate after
requirements have been gathered(which is rare) the accuracy
improves to 5-10%. From what you say I wonder whether you do
estimates after you know the requirements? That's usually rare in
the software industry in my experience.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Paul Dietz

2004-05-12, 9:06 pm

[color=darkred]
> On Thu, 6 May 2004 08:06:33 -0400, "xpyttl"
> <xpyttl_NOSPAM@earthling.net> wrote:
> At

If overruns brings much unwanted attention, there will
be incentive to pad the estimates. If underruns bring
attention, there will be incentive to pad the actual work.
Both effects could be occuring in the same project.

I doubt this is what was intended, but I would not
be surprised if this were the actual reason some organizations
have accurate (if large) estimates.

Paul

xpyttl

2004-05-12, 9:06 pm

"Alan Gauld" <alan.gauld@btinternet.com> wrote in message
news:ul0l90pb8o80afk44datp0nhrv5eglom2s@
4ax.com...

> From what you say I wonder whether you do estimates
> after you know the requirements? That's usually rare in
> the software industry in my experience.

I'm guessing from the provider that you are in the U.K. Here in the U.S.,
there are tax reasons to keep the requirements effort separate from the
detailed design, build, test and implement efforts. I don't claim to
understand these tax implications, but I know the efforts need to be
accounted differently.

The requirements phase, which includes a conceptual design, is done
basically on a time and materials basis, although there is an initial
expectation of project cost. Part of the requirements phase includes an
experienced architect's assessment as to whether the initial expectations
are realistic.

Using the information extracted from the requirements, an estimate is
developed based on a history of projects. There is a fairly involved
estimating model, which is updated quarterly from project results.

But it gets better ... the estimate is not complete until all the teams
required have bought in to the estimates. Obviously, there is pressure on
the team leads to "bid" close to the estimates, but in the spirit of CMM,
the teams have the option of saying no, and the team leads will get beat up
if they go over, so they will not buy into lowball estimates. On the other
hand, they are also responsible for productivity metrics, so it is really
not in their best interest to pad the estimates, either. If the project
sponsors cannot live with the team leads' bids, they can look to different
teams (which in practice tends to imply different technologies), or they can
walk away from the project. Similarly, if a team believes that the
expectations are unreasonable, the team is empowered to refuse the work.

...

Andrew Gabb

2004-05-12, 9:06 pm

Edd Stewart wrote:
> I am due to give a lecture to some students at my local college on the
> subject of ethics in computing. Much of it will focus on the inquiry into
> the London Ambulance Service's CAD system (which was an infamous failure due
> to poor management and engineering practices). I would like to finish the
> piece with a section on lessons learnt from such failures illustrated by a
> number of successful projects; however I can find little information. Can
> anyone with knowledge on appropriate projects please post in reply. Any
> information would help greatly.

One of the problems you face is that it will be exploited by
different folks differently. I've seen articles on various projects
that promote the same project as both a success and a failure,
depending on your viewpoint (and commercial and political
allegiance, quite obviously). It appears that almost any project
that results in the system being used for a couple of years can be
presented as a success regardless of cost, schedule and performance
shortfalls.

As an example of different viewpoints, I've often seen the London
Ambulance project promoted as a case study for safety critical
software, including the advocacy of using formal methods to avoid
the problems experienced. A less biased reading of the evidence (as
I remember it) points the finger at much less sophisticated causes -
basically incompetence, poor management and lack of testing. It
would have failed regardless of the purpose to which it was put.

One anecdote you might be interested in comes from the text Quality
Software Management by Gerald Weinberg. He tells the story of his
students studying failed projects and concluding that they all had
something in common - bad luck, ie something beyond the control of
the project manager, like fires, plaugues, floods, etc. So he got
them to check out some successful projects. They concluded that the
successful projects had bad luck too. Moral? Successful projects
survive bad luck.

Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----

Sponsored Links