<span class=Introducing processes – why do we need values?

Using a defined process for software development is not really a new idea - in fact the whole term ‘software engineering’ came into being in 1968, when the first ever international conference on software engineering was held in Garmisch, Germany, from 7-11 Oct. 1968.

In that decade – the sixties – for the first time ever the cost of the software part of projects exceeded that of hardware or any other kind of labor. That was a good reason to try to make software development into an engineering discipline as seemingly predictable as others.

Even before that time iterative and incremental methods had been around – e.g. when developing the software for Project Mercury as Larman and Basili point out – and some of those approaches even had been partially standardized.

Yet software development projects still were prone to failure – or at least to what people deemed to be failure.

Semantic diffusion in “Waterfall”

There are many stories on how Waterfall first came into life. A lot of them start with an article by Dr. Winston W. Royce, presented at the 1970 WESCON.

In this article the classical waterfall approach is outlined in the first few sentences and pictures.

And for many a reader that was enough!

And so they missed that Royce continued by stating that while he believed in the principal idea [of doing analysis and design prior to programming] he considered the [waterfall style of] implementation to be „risky and inviting failure“. He used the remainder of the paper to outline a more iterative approach, which he recommended to his readers. If only they had read thus far…

So the straw-man, that Royce set up just to knock him down, has become the foundation for the waterfall model as we know it, because (some? most?) people didn’t bother reading far enough.

Read the whole article 

">
Introducing Processes - why do we need values
08-10-2015 14:39
Introducing processes – why do we need values?

Using a defined process for software development is not really a new idea - in fact the whole term ‘software engineering’ came into being in 1968, when the first ever international conference on software engineering was held in Garmisch, Germany, from 7-11 Oct. 1968.

In that decade – the sixties – for the first time ever the cost of the software part of projects exceeded that of hardware or any other kind of labor. That was a good reason to try to make software development into an engineering discipline as seemingly predictable as others.

Even before that time iterative and incremental methods had been around – e.g. when developing the software for Project Mercury as Larman and Basili point out – and some of those approaches even had been partially standardized.

Yet software development projects still were prone to failure – or at least to what people deemed to be failure.

Semantic diffusion in “Waterfall”

There are many stories on how Waterfall first came into life. A lot of them start with an article by Dr. Winston W. Royce, presented at the 1970 WESCON.

In this article the classical waterfall approach is outlined in the first few sentences and pictures.

And for many a reader that was enough!

And so they missed that Royce continued by stating that while he believed in the principal idea [of doing analysis and design prior to programming] he considered the [waterfall style of] implementation to be „risky and inviting failure“. He used the remainder of the paper to outline a more iterative approach, which he recommended to his readers. If only they had read thus far…

So the straw-man, that Royce set up just to knock him down, has become the foundation for the waterfall model as we know it, because (some? most?) people didn’t bother reading far enough.

Read the whole article 

Opslaan