Home > Archive > Software Engineering > February 2005 > Software development as an engineering process
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Software development as an engineering process
|
|
|
| How one can compare a software development process with any any other
engineering process?
Is there any formal metrics to compare the SW development process with other
processes?
| |
|
| Guiera wrote:
> How one can compare a software development process with any any other
> engineering process?
> Is there any formal metrics to compare the SW development process with
other
> processes?
You cannot compare production of lines of software code to the assembly of
widgets in a factory. Our product uses only electrons, and they copy more
easily than protons.
The closest hardware analogy to software design is "lean manufacturing".
That's where you design your widgets, and their assembly line, on the fly.
One very good metric for this system is the "total inventory costs". The
more parts you have in inventory, the slower you can change to market
situations.
Dell Computer's entire work system revolves around defeating inventory. A
memory chip that sits on a shelf for a w is obsolete. Dell tries to buy
components only when they have orders to fill. This pushes risk out of their
shops. The risk goes upstream to vendors and downstream to clients.
The software equivalent is a very simple metric: The time between making a
decision about requirements and delivering code based on that decision to
users.
At one extreme end of that metric, many programming shops gather
requirements into huge batches, and then spend a long time simultaneously
converting all these requirements to code. These shops have a very low
"Software in Process" metric. Many studies have shown that this technique
creates incredible risk. Users must wait a long time, then must discover all
the irritations caused by mistakes in the requirements.
At the other extreme end of the metric, many programming shops gather
requirements in batches of one w. They collect the requirements with the
highest business value, code only these for a w, and then deliver them.
Users can begin to profit from the new features immediately. Then the
programming team uses realtime feedback from these users to identify the
next batch of high value features. They repeat this process until the
customers are satisfied.
Working with a Software in Process metric as low as 1 w permits a
software development process to remain flexible.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
|
| > At one extreme end of that metric, many programming shops gather
> requirements into huge batches, and then spend a long time simultaneously
> converting all these requirements to code. These shops have a very low
> "Software in Process" metric. Many studies have shown that this technique
> creates incredible risk. Users must wait a long time, then must discover
> all
> the irritations caused by mistakes in the requirements.
> At the other extreme end of the metric, many programming shops gather
> requirements in batches of one w. They collect the requirements with
> the
> highest business value, code only these for a w, and then deliver them.
> Users can begin to profit from the new features immediately. Then the
> programming team uses realtime feedback from these users to identify the
> next batch of high value features. They repeat this process until the
> customers are satisfied.
>
> Working with a Software in Process metric as low as 1 w permits a
> software development process to remain flexible.
>
> --
> Phlip
> http://industrialxp.org/community/b...tUserInterfaces
>
Imagine a R&D organization which has to build in-house, application specific
SW to control a complex system (a power plant, or a space craft etc) that
they are developing.
How they can select a SW development process model?
How they can verify that their SW development process is a good one for the
job and working toward a successfull completion of the task in its time
constraints?
| |
| William 2005-02-06, 3:58 pm |
| "Phlip" <phlip_cpp@yahoo.com> wrote in message
news:9xqNd.26699$by5.2532@newssvr19.news.prodigy.com...
[...]
>
> Dell Computer's entire work system revolves around defeating inventory. A
> memory chip that sits on a shelf for a w is obsolete. Dell tries to buy
> components only when they have orders to fill. This pushes risk out of
their
> shops. The risk goes upstream to vendors and downstream to clients.
This is off-topic, but Sears pioneered that over a century ago. One story
has it that Sears walked into a clothing manufacturer's office and offered
to buy 10,000 pairs of pants. When asked if he wouldn't rather try a
few hundred to see how they'd sell, he replied that he'd already sold the
10,000...
> The software equivalent is a very simple metric: The time between making a
> decision about requirements and delivering code based on that decision to
> users.
You could argue that the inventory cost of software is the difference
between
what you've spent developing and the amount you've been paid for it so far,
averaged over some time period. For custom work, the gap is smaller and
shorter lived than it is for something sold by the unit. -Wm
| |
|
| Guiera wrote:
> Imagine a R&D organization which has to build in-house, application
specific
> SW to control a complex system (a power plant, or a space craft etc) that
> they are developing.
> How they can select a SW development process model?
They need to pick one that instructs them to deliver new functionality every
w. (If the target is life-critical or, even worse, money-critical, of
course they won't put each delivery online every w.)
This means every w they rate both their software and their process. If
the process is not working, they will know very soon.
However, frequent iterations provide very high odds of working.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| shelley@osel.netkonect.co.uk 2005-02-08, 3:59 pm |
| Guiera wrote:
> Imagine a R&D organization which has to build in-house, application
specific
> SW to control a complex system (a power plant, or a space craft etc)
that
> they are developing.
> How they can select a SW development process model?
> How they can verify that their SW development process is a good one
for the
> job and working toward a successfull completion of the task in its
time
> constraints?
Still very difficult. This was something that the SEI's CMM was
supposed to address. Their approach was to assess existing capability
as a confidence builder, but it is very culture specific. There is a
huge amount of know how available - SWEBOK attempted to scope this -
but precious little guidance on how to design and select appropriate
tools and techniques for a particular needs with a high degree of
confidence. It's still an art, dependent on judgement and experience.
(For what it's worth I like to treat the setting up of software dev.
capability as a systems problem - investigate and state the reqs,
design (architecture, low level), implement... ...refine, and so on,
but that's because I think that way. I've known project managers, who
often get this problem dumped on them, treat it a project management
problem - don't know who's right.)
The new level 5 type organizations may have some interesting knowledge
on rapid s/w process implementation but I wouldn't expect much in terms
of predictable process effectiveness, efficiency or s/w quality. The
agile community have important and interesting ideas which should be
looked at carefully by the engineering community, but this too is still
not well understood.
So far as software engineering is concerned building the right software
process capability is a problem, certainly nothing equivalent to the
production engineer's 'flat pack' approach exists, yet.
(The argument that s/w is different to other engineering is not
convincing. I haven't come across a software dev. problem that hasn't
got a design or production engineering analog. There's still lots to
learn from engineering design and production processes, as well as the
new s/w specific ideas, but some sort of filters that enable selection
of tools for say, safety critical, or organization infrastructure, or
embedded gizmo etc... are sorely needed. Maybe a software process
taxonomy, some decision trees, something like that to mitigate the 'one
size fits all' approaches - does this stuff exist anywhere?)
| |
| burrise@umkc.edu 2005-02-10, 3:59 am |
| Software engineering is not the same as traditional engineering
principally because software development isn't based on physical laws.
An electrical engineer can use Ohm's Law to make decisions about
circuit design but the "formulas" and scientific knowledge underlying
software development are much less precise:
cost * time = features * quality
(COCOMO Cost model) Effort = 3.0(KDSI)^1.12
I would contend that when calibrated with local data, organizations can
develope formulas for software development that approach the accuracy
of those in electrical engineering.
Design and other non-deterministic activities in software development
make it more difficult to call software development engineering, but
the gradual increase in codified knowledge in the form of design
patterns, refactorings, etc is minimizing this distinction.
Software engineering must also contend with the fact that software
development is principally a human activity, so humanistic issues will
always play a big part in software development. (The Psychology of
Computer programming; Peopleware, etc.)
Eddie
| |
|
| Eddie,
I liked your message, thank you for the well summarized information.
By the way what is the meaning of KDSI in your equation? Can you give as
some reference how that equation is created?
> Software engineering is not the same as traditional engineering
> principally because software development isn't based on physical laws.
> An electrical engineer can use Ohm's Law to make decisions about
> circuit design but the "formulas" and scientific knowledge underlying
> software development are much less precise:
>
> cost * time = features * quality
> (COCOMO Cost model) Effort = 3.0(KDSI)^1.12
>
> I would contend that when calibrated with local data, organizations can
> develope formulas for software development that approach the accuracy
> of those in electrical engineering.
>
> Design and other non-deterministic activities in software development
> make it more difficult to call software development engineering, but
> the gradual increase in codified knowledge in the form of design
> patterns, refactorings, etc is minimizing this distinction.
>
> Software engineering must also contend with the fact that software
> development is principally a human activity, so humanistic issues will
> always play a big part in software development. (The Psychology of
> Computer programming; Peopleware, etc.)
>
> Eddie
>
| |
| xpyttl 2005-02-10, 3:58 pm |
| <burrise@umkc.edu> wrote in message
news:1108018611.853188.50460@z14g2000cwz.googlegroups.com...
> Design and other non-deterministic activities in software development
> make it more difficult to call software development engineering, but
Every engineering discipline has some design component, and design is never
simply mechanical. There is always some non-deterministic component.
The chief difference between software engineering and other sorts of
engineering is that software engineers tend to be primmadonnas who refuse to
believe that anyone who went before could possibly be as smart as they are.
That is beginning to change with the acceptance of patterns, but even before
OO became the fad there was plenty of knowledge that was largely ignored by
practitioners.
That is not the case with traditional engineering, where practitioners
always review the "case law" before embarking on a design activity. But
designing a bridge or a chemical plant is as much of a creative activity as
designing a program.
...
| |
| Jonathan Allan 2005-02-10, 3:58 pm |
| xpyttl wrote:
...
> The chief difference between software engineering and other sorts of
> engineering is that software engineers tend to be primmadonnas who refuse to
> believe that anyone who went before could possibly be as smart as they are.
> That is beginning to change with the acceptance of patterns, but even before
> OO became the fad there was plenty of knowledge that was largely ignored by
> practitioners.
>
> That is not the case with traditional engineering, where practitioners
> always review the "case law" before embarking on a design activity. But
> designing a bridge or a chemical plant is as much of a creative activity as
> designing a program.
Never ascribe to malice what can be explained by stupidity. Though
in this case, it's not stupidity as much as a lack of ability to sue
the software practitioner for ignoring history (stupidity). After
we, as an industry, have gotten sued out of our shorts and someone
is doing real prison time for ignoring history, then we'll start to
see much more rigor and "software engineering" will become a reality.
Employers of "SWEs" will be far more interested in good "discipline"
when there are significant economic consequences.
Until then,
we are on the same curve as the early <pick your discipline> engineers.
Jonathan
--
Jonathan Allan, IEEE CSDP & ASQ CSQE
Neither Mayo Clinic nor I speak for each other unless we explicitly
say so. You should assume I am speaking only for myself.
Please remove the antispam ".6809" to reply direct to me. Thanks!
| |
| Mike Bandor 2005-02-11, 3:59 am |
|
<hu-axiang> wrote in message
news:420b0b1a$0$5725$afc38c87@news.optusnet.com.au...
> Eddie,
>
> I liked your message, thank you for the well summarized information.
> By the way what is the meaning of KDSI in your equation? Can you give as
> some reference how that equation is created?
>
>
>
>
Here is the link to the COCOMO II website:
http://sunset.usc.edu/research/COCO...como_main.html. BTW, the
annotation "KDSI" represents "thousand delivered source instructions".
Mike
| |
|
|
|
|
"Mike Bandor" <mbandor@satx.rr.com> wrote in
message
news:6RVOd.39799$uA.35141@fe1.texas.rr.com...[color=darkred]
local data, organizations can[color=darkred]
that approach the accuracy[color=darkred]
There are several problems with this, but you are
on the right track. So far,
most of the replies have dealt with process, not
design.
One of the most serious problems is that no single
programming language
provides the facilities required to design at the
level of rigor we typically
use for physical engineering. The closest
development model I know
of that allows this is the SPARK Examiner from
Praxis. SPARK sits
on top of a subset of Ada, and allows the designer
to set some pretty
rigorous tolerances for the underlying code and
final software product.
None of the C family qualifies as engineering
language. There are too
many holes in them, too many places where things
can go dreadfully
wrong. Eiffel is a good model, and probably a
good starting point
for extension into a more rigorous design
language.
I posted, in a separate thread, an inquiry about
whether anyone was
engaged in research relative to software
engineering design metrics. By
this I do not mean process metrics. I also do
not mean evaluation
metrics. Most of what passes for metrics in the
world of software
falls under the category of what I call evaluation
metrics.
With present design tools, modeling tools,
programming languages, etc.,
we are far from being able to rise to the level of
discipline enjoyed by
engineers in the physical world.
Richard Riehle
|
|
|
|
|