What is Software Engineering
Sanjiv Gossain
and friends from different backgrounds (MIS, real-time, hackers....)
and cam up with an interesting problem. We all had different view on
what we thought software engineering to be. Some of the view points were:
- nothing more than a fancy term coined by academics who don't practice
the thing anyway
- a _formal_, verifiable appraoch to software development (whatever
that is!)
- doesn't exist....people like to code (i.e. read hack!) too much
- a rigorous, complete engineering discipline that provides rules
on constructing software.
Now I'm for the last one, but what does that really mean in practice?
I mean how many people of you out there actually practice all this stuff?
Do you use a method? If so which(SA/SD, OOA/D, Hatley-Pirbhai, Ward-Mellor..)?
Do you believe software can be engineered?
I would be interested to hear your comments and what you do in the REAL WORLD.
-Sanjiv
--
----------------
Sanjiv Gossain sgos...@projtech.com
Project Technology Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA (510) 845 1484
Motamarri Saradhi
Date: Wed, 5 Aug 92 13:05:11 +0800
From: Motamari Saradhi <sar...@frigg.iti.gov.sg>
Return-Path: <sar...@frigg.iti.gov.sg>
To: san...@projtech.com (Sanjiv Gossain)
Subject: Re: What is Software Engineering
In article <1992Aug3.2...@projtech.com>, you write:
> I have been discussing the term software engineering recently with colleagues
> and friends from different backgrounds (MIS, real-time, hackers....)
> and cam up with an interesting problem. We all had different view on
> what we thought software engineering to be. Some of the view points were:
>
> - nothing more than a fancy term coined by academics who don't practice
> the thing anyway
> - a _formal_, verifiable appraoch to software development (whatever
> that is!)
> - doesn't exist....people like to code (i.e. read hack!) too much
> - a rigorous, complete engineering discipline that provides rules
> on constructing software.
>
> Now I'm for the last one, but what does that really mean in practice?
> I mean how many people of you out there actually practice all this stuff?
> Do you use a method? If so which(SA/SD, OOA/D, Hatley-Pirbhai, Ward-Mellor..)?
> Do you believe software can be engineered?
>
> I would be interested to hear your comments and what you do in the REAL WORLD.
Dear friends,
In my recent papers I have attempted to address some of the points raised
by Mr Sanjiv mostly as an engineer and as a practitioner of systems engi-
neering.
In a paper 'Software Engineering from a Practical Perspective', to appear
in ACM-Software Engg Notes Vol 17 No 3, July 1992, I have presented the real
world complexities of software or systems development. The theme of the paper:
"The development of software is a marathon feat. Software Quality Assurance is
a much more difficult and challenging task. Further, putting the software for
live use, is a still more complex affair. These matters are not trivial for
successful and appropriate exploitation of computers and information technology,
rather they are the central issues one must answer first. Motivated by the
ongoing discussions on a plenty of issues related to software, (software
technology!) including standards and quality assurance, I am translating my
experiences as the mentioned issues are duly represented in my systems develop-
ment projects. Perhaps, this is an attempt to bring to light the prominent but
less addressed points, especially that are lying at the interface of the several
disciplines related to software creation. I present a generic structure of
'Systems Development Process' (SDP) from a practical view point. An outline on
the framework of SDP, and the environment in which it takes is presented to
illustrate the line-of-thinking that has influenced in the creation of successful
application systems developed in several domains."
Coming to the question of notions of Software Engineering, I would like to say
that even engineering itself is more of an art than science. But still engineering
has strong methodological foundation. If we desire to make software development
also as an engineering discipline we must first understand what's engineering
problem strategy? May be perhaps, one must first understand what's engineering?
For an interesting reader who would like to know the impact of engineering
visualization on software development and would like to know the engineering
strategy to SDP, I reques him to refer to my latest paper:
"Systems Modelling and Description", appeared in ACM-Software Engg Notes of
Vol 17 No 2 of April, 1992 issue.
As a practitioner I am proud to share that I was greatly benefited by Jackson's
strategy not only in program design but also in a variety of situations and
contexts.
Finally, I fear that they are some fundamental issues which have not been well
discussed and well tested that has a profound influence on the problems of
software creation. I made a very fundamental analysis on such issues in my forth
coming article:
" A Diagnostic View on Information Technology", to appear in the same ACM-SEN of
Vol 17 No 4 of Oct, 1992 issue. For an interested reader, the abstract of the
work runs as:
"Why does this magnificient applied science which saves work and makes life
easier bring us so little happiness? The simple answer runs : Beacuse we have
not yet learned to make sensible use of it."
-- Albert Einstein
"Computers, computerization, Systems Analysis, Systems Design etc., have become
the catchwords of the day. In majority of the cases analysis is interpreted in
the narrow sense as the 'study of the existing system' in view of computerizing
its operations. The thrust for computerization is emphaized without any relevance
to the context of application. The real power, its limitations, and level of
applicability are not properly thought of. Computerization at most, is one facet
of Information Technology, is surprisingly overlooked. The aaim of this article
is drive home the point that a much rational thought and approach are mandatory
to get fruitful benefits out of IT."
Hope these points will gain some follow-up and help in laying the engineering
foundations for software development.
Regards.... Motamarri Saradhi
*** disclaimer: opinions are exclusively personal ***
+-------------------------------------------------------------------------+
| Motamarri Saradhi, Life Mem ISCA;Mem ACM |Office : (65)772 0931 |
| Knowledge Systems Lab |Res : (65)774 3805 |
| ITI, National Computer Board |Fax : (65)777 3043 |
| 71 Science Park Drive |Bitnet : Sar...@itivax.bitnet|
| Singapore - 0511. |Int'net: Sar...@iti.gov.sg |
| ------------------------------------------------------------------------|
| "Man is guided by his stomach. He walks. His stomach goes first. |
| Then his head. Have you not seen that? It will take ages to make |
| the head go first." - Swami Vivekananda |
+-------------------------------------------------------------------------+
--
+-------------------------------------------------------------------------+
| Motamarri Saradhi, Life Mem ISCA;Mem ACM |Office : (65)772 0931 |
| Knowledge Systems Lab |Res : (65)774 3805 |
| ITI, National Computer Board |Fax : (65)777 3043 |
Brandon
engineering discipline that provides rules, guidelines, etc based on
proven techniques and sound theories. I also feel that Software Engineering
NEEDS to be recognized as a true engineering field or else the cost of
business as usual (always the bottom line) will continue to damage the software
field. However, I see some hurdles to overcome:
1) A majority of persons developing software are still using ad-hoc
techniques and I think this reduces the entire software community. In Electrical
Engineering it is unlikely that someone without extensive training could go out and
begin designing and building chips (especially ones that people base their life
and livelyhood on). In software this situation is far too common.
2) If Software Engineering is recognized as a true engineering than the
responsibility of those claiming to be SE's will be enforcable. For example, it
will be much easy to prove gross negligence on someone claiming to be an SE if they
failed to follow accepted standards (such as IEEE testing guidelines) when a mishap
occurs.
3) There will be a lot of bitterness between those who become Software
Engineers and those who will remain programmers. I do not believe that everyone
developing Software has the drive or the means to achieve the level of training
necessary to become a Software Engineer.
The solutions to these problems (training, managerial support and enforcement,
etc) are easy to say (lip service) but a LOT harder for large organizations to
actually change.
Brandon Goldfedder
--
Brandon - Consistancy is often important.
bra...@evb.com
A. Jeff Offutt
I recently had an interesting conversation with a close friend who is a
practicing mechanical engineer. He is licensed by a professional
society (a PE), which carries with it certain responsibilities as well
as a certain amount of respect. My friend builds power plants
(hydroelectric). He is typically a chief engineer on these kinds of
projects, which means he has the ultimate responsibility of making the
power plant work.
I recently asked him to list the 3 factors that drive his production
process -- I guess 3 was the wrong number, because he gave me 4:
1. Safety
2. Quality
3. Cost
4. Delivery date
Upon questioning, he listed reliability, efficiency of power
generation, ease of maintenance, and lifetime as important components
of quality (certainly this is not too different from what we think of
as quality in software).
Take a moment to think about this list. If you develop software for a
living, what are the factors that you and/or your company considers to
be most important? If you are a student or an educator/researcher (as
I am), what do you perceive to be the important factors in the software
industry? What do you think software engineerings _should_ focus on?
I also asked my friend if he ever compromises on these factors. He
said he will trade off cost for delivery date if the customer wants
(slower and cheaper or faster and more expensive). He said that
although he never has, he has seen his fellow engineers sacrifice
quality for a lower cost of quicker delivery time, but only with a
_WRITTEN_, _SIGNED_ document from the customer that attests to the fact
that the compromise was the _customer's_ decision.
My friend said he would _never_, under any circumstances, sacrifice
safety. He would _resign_ if pressured to do so. In fact, he said he
would resign if pressured to sacrifice quality without an appropriate
reason (e.g., the plant is only to be used 5 years). Luckily for him,
most of his colleagues would also resign under similar conditions, and
his professional organization would back him up!
Can you imagine IEEE or ACM coming to our rescue if a software engineer
refused to rush a product to market simply because the sales VP said
that the best time for sales is January? Can you imagine a software
engineer _resigning_ before sacrificing quality for a delivery time?
Here is my perception of what the above list is for the software industry:
MECHANICAL ENGINEERING SOFTWARE ENGINEERING
______________________ ____________________
1. Safety 1. Delivery date
2. Quality 2. Cost
3. Cost 3. Use latest "whiz-bang" technique (OO)
4. Delivery date ...
n. Quality
Most practicing software engineers wouldn't know how to build quality
software systems if their jobs were threatened. Certainly most of our
students can't ... and most of the CS faculty in the world don't know
how to teach the skills needed to build quality systems.
Can we claim to be SOFTWARE ENGINEERS?
Not until we put SAFETY and QUALITY first!
___________
Jeff Offutt
Department of CS, Clemson University, Clemson SC (803) 656-5882
email: of...@cs.clemson.edu
soon to be:
Information Systems and Systems Engineering Department
George Mason University, Fairfax VA
email: of...@gmuvax2.gmu.edu
--
Jeff Offutt
Department of CS, Clemson University, Clemson SC (803) 656-5882
email: of...@cs.clemson.edu
Richard Bielak
"To Engineer is Human" by Henry Petrowski, Vintage Books
After reading this book , I think the term "engineering" can be safely
applied to software.
As for the term "software engineer", it always reminds me of the
phrase "sanitation engineer". Are we not secure enough to be called
"programmers" ?
...richie
--
* Richie Bielak (212)-815-3072 | "Your brain is a liquid-cooled parallel *
* Internet: ric...@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan." *
* - Strictly my opinions - | - David Chudnovsky - *
Allen Adams
In order to see something significant in the other engineering areas
(electrical, mechanical, etc.), much time and effort is needed,
supplies need to be purchased, etc. For the most part, when
constructing software, if one already has a computer, the individual
can 'crank out' a solution within a reasonable amount of time, and
with the speed of today's computers, a resonably engineered solution
really is not necessary. Now if I was going to build a computer, road,
robot, etc., the failure to engineer it properly would be noticed, both
inside and out. When one runs a computer program, unless it 'bombs',
runs ridiculously slow, etc., the engineering 'beauty' cannot really be
appreciated. The down side of not engineering software properly comes
in the 'maintenace' phase. Either hacks need to be made to hacks, some
unfortunate person has to try and figure out what is going on, etc., in
order to 'upgrade' the software. One could argue that someone could do
this and make things run anew. However the time involved, in theory,
should be much greater if one does not engineer it properly.
So as a general conclusion, it is hard to convince both novices and
engineers in areas other than software that engineering software is to
their benefit. As one electrical engineer told me, "My job as an engineer
is to make things work, no matter what." Therefore, my conclusion is
that 'hacking' is and should be the job of an engineer. To 'engineer'
software, as the latest software engineering principle's tell us, really
is not engineering. Maybe we should call ourselves 'software artists'.
Allen Adams
Sanjiv Gossain
> [book recommendation deleted]
>
>As for the term "software engineer", it always reminds me of the
>phrase "sanitation engineer". Are we not secure enough to be called
>"programmers" ?
>
>
Excuse me if I misunderstood, but I would say that software
engineering is _much_ more than writing programs. A program
may be the final end result but there is a lot more than
just writing code to producing ths stuff.
- Sanjiv
--
-------------------------------------
Dr. Sanjiv Gossain, sgos...@projtech.com
Project Technology Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA Tel: (510) 845 1484
Dan Drake
> ...
>
> As for the term "software engineer", it always reminds me of the
> phrase "sanitation engineer". Are we not secure enough to be called
> "programmers" ?
>
seniority to use the simple old-fashioned unexalted term.
There are, however, some other possibilities for those willing to go
just halfway to being programmers:
Enhanced Programmer
Super Programmer
Ultra Programmer
Virtual Programmer
Senior Programmer
Elder Programmer
Doddering Programmer
Intergalactic Exalted Cosmic Hyper Programmer
(List reprinted without permission from The Autodesk File by John
Walker, New Riders Publishing, 1989.)
Myself, I'm considering getting my new business cards with the title
Senile Programmer.
--
Dan Drake
dr...@Autodesk.com
Mark Kanko
[Sorry, I can't keep myself out of this!]
> [text deleted]
> appreciated. The down side of not engineering software properly comes
> in the 'maintenace' phase. Either hacks need to be made to hacks, some
^^^^^^^^^^^^^^^^^^^^^^^^^
Bingo! Now the relevant question is: "What percentage of a S/W dev
organization's software budget will be spent on maintenance of
existing S/W?" According to Pressman, those numbers look like:
Decade % of S/W Budget
------------------------------
1970 35-40%
1980s 40-60%
1990s 70-80%
Further, Pressman goes on to say, "One intangible cost of software maint
is a development opportunity that is postponed or lost because available
resources must be channeled to maint tasks." There are other intangibles.
> [other text deleted]
> As one electrical engineer told me, "My job as an engineer
> is to make things work, no matter what." Therefore, my conclusion is
This EE does dis-service to his profession. Every job has constrints.
Does '...no matter what...' include 'working' for only 5 minutes before
burning out the power supply? Of course not! Virtually every H/W effort
has reliability and maintainability (R&M) constraints somewhere in the
spec. Same should hold true for software. (Hoo-boy. I can see the
defect density and MTBF discussions coming already... ;-) )
> is to make things work, no matter what." Therefore, my conclusion is
> that 'hacking' is and should be the job of an engineer. To 'engineer'
> software, as the latest software engineering principle's tell us, really
> is not engineering. Maybe we should call ourselves 'software artists'.
Sorry, your conclusion(s) is (are) based on a faulty assumption.
[Or was your whole post a tongue-in-cheek?]
[standard disclaimer: my views are my own.]
--
/*** Mark Kanko Arizona State University ka...@asuvax.eas.asu.edu ***/
John Lehman -- GDP
>> > phrase "sanitation engineer". Are we not secure enough to be called
>> > "programmers" ?
>> >
>> Very few of us are. It seems that it takes someone with some real
>> seniority to use the simple old-fashioned unexalted term.
>>
>> There are, however, some other possibilities for those willing to go
>> just halfway to being programmers:
>>
>> Enhanced Programmer
>> Super Programmer
How about:
"Software Staff Person" or "Software Staff"
which would cover an occupation including
writing purchase requests for software license
renewals, occasional debugging or consulting,
technical writing, occasional (or rare)
programming (in C, Fortran, sed, shell, make,
etc.), going to administrative meetings,
occasionally installing, reviewing, or
testing software; occasionally engineering
part of a software system; or, doing computer
system administration tasks; etc. The term
"programmer" doesn't really fit such an
occupation, particularly as the person
may not have much time to program or may
not receive any programming assignments.
As for what "software engineering" is:
"Software Engineering" could mean:
writing requirements and supervising programmers,
testers, and procurement; (this person is partly
a "supervisor" of people, and/or partly a "project
manager" using project management skills which,
in the main, aren't particular to software);
or it could mean a somewhat more technical and
somewhat narrower occupation: for example:
designing a software system:
for example:
researching and discussing the methods,
selecting the tools, learning how to use
the tools (e.g., imake, make, and RCS),
and putting them together to maintain yet
another, already-existing, software package,
is a kind of software engineering. (But,
this particular example is only for _part_ of
the total software system. A more "real"
software engineer would be one who designed
the whole original software package (the
one for which the above person is designing
the maintenance system), that is, determined
what functions were needed and what subroutines
or libraries should be used and how they would
link together, and then writes down the
requirements for all the parts, before any
programming was done.) In either case, the
software technical engineer is a kind of
"designer".
(More below, on what a "software engineer"
really is.)
Can anyone suggest what to call the
software staff person? Also, is there a
meaningful title for each of those
tasks s/he does?
Also, a dozen years ago some people didn't
know what "software" was. Is the term
"software" too exalted (perhaps in the
same way that "engineer" is)? Is "program"
the simplest term for what software is?
Is an "engineer" always a designer?
--------
Maybe instead of saying "I am a software engineer"
one could say "I design computer programs" and
then everyone (inside the field and also in the
world at large) would know what s/he was talking
about. (Also, would be more easily able to verify
whether the statement is true.)
When a person talks, s/he may or may not want
another person to know exactly what s/he is
talking about. If the purpose is to persuade
someone (who has limited knowledge and has only
limited time or inclination to ponder and pursue
meanings, and who may be impressed by vaguely
unfamiliar poly-syllables or words connoting big
money) to hire oneself, then "I am a software
engineer" may be the most efficacious utterance.
On the other hand, if one really wants to clarify
and have the truth be understood, then either
"I design computer programs" or "I do miscellaneous
work relating to computer software" would accomplish
that purpose better, and would let the listener
know which of these two (or many) job descriptions
really fits.
In summary:
The phrase "Software Engineering" is generally used to mean either:
{
A:
(1) working in the software field,
and
(2) already having experience working in the software field,
and
(3) (as needed) managing software projects;
where either (1) or (2) but not both may be left unsatisfied,
when determining whether a given person is or is not a
"software engineer";
(i.e., (1),(2),&(3), (1)&(3), and (2)&(3) are all sufficient
to make a person a "software engineer" in the way the term is
now generally used).
}
or:
{
B:
the study of software and the study of the production of software
}
The phrase "Software Engineering" should more properly be
used to mean:
designing computer programs;
and even more properly, should not be used at all (instead
just say "designing computer programs" or whatever else
it is that you are really talking about (for example, I
would relegate the study of "software metrics" to be called
just that (or "measurement of computer programs"), and not
call it "software engineering").
After all the above, I must now admit, in the general
interest of truth, that I myself could barely be called
either a designer of computer programs or (as the term
is generally used at "A" above) a "software engineer",
as I only do those things part of the time, very seldom
have managed multi-person projects, and am less experienced
than several others who write to this newsgroup. So, although
it may seem (to a few people) that I have written with
authority, that authority is from the heart but not from
the job. If some of the more experienced people who call
themselves "software engineers" will hereby be persuaded
to use simpler vocabulary, then this message will have served
a worthwhile purpose.
Finally, having said that the most proper use of the phrase
"software engineering" is to not use it at all, what am
I doing reading and posting to this newsgroup which is
called comp.software-eng? In the beginning, I got here
because I couldn't find any other group discussing RCS
(Revision Control System) and this group did mention
RCS; and in fact I _still_ haven't found an RCS discussion
group; and this group is as entertaining as others such
as gnu.misc.discuss.
Stephen Schmid
As a carpenter is to an architect,
so is a programmer to a software engineer.
------------------------------------------------------------
Steve Schmid Interactive Development Environments
------------------------------------------------------------
Brian Marick
>As a carpenter is to an architect,
>so is a programmer to a software engineer.
A dangerous analogy to make to the son of a carpenter, who spent much
of his childhood listening to his father fume about unlivable,
unimplementable designs. Some of the things he had to talk people out
of were so stupid even I saw it, but some were rather subtle.
Never thought about it, but I bet that's why I insist that I can't
preach about testing unless I spend a lot of time *doing* it. Too
many "implementation details" have too large an impact.
Brian Marick, mar...@cs.uiuc.edu, uiucdcs!marick, mar...@testing.com (pending)
Testing Foundations: Consulting, Training, Tools.
Freeware test coverage tool: see cs.uiuc.edu:pub/testing/GCT.README
Geoff Miller
>In article <adams.7...@fanaraaken.Stanford.EDU>, ad...@fanaraaken.Stanford.EDU (Allen Adams) writes:
>> [text deleted]
>> appreciated. The down side of not engineering software properly comes
>> in the 'maintenace' phase. Either hacks need to be made to hacks, some
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> Bingo! Now the relevant question is: "What percentage of a S/W dev
> organization's software budget will be spent on maintenance of
> existing S/W?" According to Pressman, those numbers look like:
> Decade % of S/W Budget
> ------------------------------
> 1970 35-40%
> 1980s 40-60%
> 1990s 70-80%
> Further, Pressman goes on to say, "One intangible cost of software maint
> is a development opportunity that is postponed or lost because available
> resources must be channeled to maint tasks." There are other intangibles.
I don't dispute the figures as such, but I wonder if there's some double
counting going on. We're looking at a project at the moment for which
we estimate the development time of a working core system to be 6 months,
with at least a further 12 months for refinement and further development.
Now, is that "maintenance"? By some definitions it is (since it involves
fixing problems with existing code), so if you analyse our time on that
basis it will look as though we're spending a lot of time on maintenance.
However, is that a problem? I don't think so, because I don't see
maintenance and development as necessarily distinct. In fact, most of
our software "maintenance" involves additional functionality or altered
functionality in response to changing user requirements.
Geoff Miller (g-mi...@adfa.oz.au) | Don't steal. The government
Computer Centre | hates competition.
Australian Defence Force Academy | (via Jeff Cooper)
m...@mole-end.matawan.nj.us
> >> Do you believe software can be engineered?
> I recently had an interesting conversation with a close friend who is a
> practicing mechanical engineer. He is licensed by a professional
> society (a PE), which carries with it certain responsibilities as well
Actually, he is licensed by the state in which he practices, with the
advice of nationwide prefessional societies upon the licensing procedure.
> ... My friend builds power plants
> (hydroelectric). He is typically a chief engineer on these kinds of
> projects, which means he has the ultimate responsibility of making the
> power plant work.
He has more than that. He has ultimate responsibility for the safety
of the plant, and if his work does not measure up to generally accepted
standards he can be held legally responsible for malpractice. (Not that
it happens often, and thank goodness.)
> ...
> Most practicing software engineers wouldn't know how to build quality
> software systems if their jobs were threatened. Certainly most of our
> students can't ... and most of the CS faculty in the world don't know
> how to teach the skills needed to build quality systems.
>
> Can we claim to be SOFTWARE ENGINEERS?
> Not until we put SAFETY and QUALITY first!
We have to show that there is enough science to our work, and then
show that we can take the kind of project responsibility that a PE
takes. I'd really like to see the PE societies take an interest here.
--
(This man's opinions are his own.)
From mole-end Mark Terribile
m...@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
m...@mole-end.matawan.nj.us
> In article <1992Aug10.0...@bony1.bony.com> ric...@bony1.bony.com (Richard Bielak) writes:
> > [book recommendation deleted]
> >As for the term "software engineer", it always reminds me of the
> >phrase "sanitation engineer". Are we not secure enough to be called
> >"programmers" ?
> Excuse me if I misunderstood, but I would say that software
> engineering is _much_ more than writing programs. A program
> may be the final end result but there is a lot more than
> just writing code to producing ths stuff.
True.
But an engineer should not be ashamed to be both an engineer and a circuit
designer, an engineer and a aerodynamicist, an engineer and a hydrologist.
If we can establish engineering principles in software, we ought not be
ashamed to be engineers and programmers, engineers and performance
analysts, engineers and algorithmetists.
Bonus, Iniquus, Celer - Delegitus Duo
> In article <1992Aug9.1...@hubcap.clemson.edu>, of...@hubcap.clemson.edu (A. Jeff Offutt) writes:
>> >> Do you believe software can be engineered?
>> Can we claim to be SOFTWARE ENGINEERS?
>> Not until we put SAFETY and QUALITY first!
>
> We have to show that there is enough science to our work, and then
> show that we can take the kind of project responsibility that a PE
> takes. I'd really like to see the PE societies take an interest here.
Don't worry about the PE societies. The lawyers will find you, totally
independent of the amount of science and responsibility in our work. (No
smiley.)
George Kambic
standard disclaimer
Lewis Kirby
|> phrase "sanitation engineer". Are we not secure enough to be called
|> "programmers" ?
Not quite in the thread, but very often I hear people using terms like "platform",
"machine", "workstation", and so on, but they seem very reluctant to use "computer".
Lewis G Kirby Telephone +44 473 645807
--------------------------------------------------------------------
Hindsight is the only exact science
--------------------------------------------------------------------
sig pretentious quote number 167
Dennis Peters
> . . .
> one could say "I design computer programs" and
> then everyone (inside the field and also in the
> world at large) would know what s/he was talking
> about. (Also, would be more easily able to verify
> whether the statement is true.)
>
By a similar logic should we ask that a Civil Engineer, when asked what s/he
does for a living reply: "I design roads/bridges/sewer systems"? I think that
the term 'Software Engineer' is no more improper than 'Civil Engineer'.
[ order altered to support my point ]
> . . .
>
> "Software Staff Person" or "Software Staff"
>
> which would cover an occupation including
> writing purchase requests for software license
> renewals, occasional debugging or consulting,
> technical writing, occasional (or rare)
> programming (in C, Fortran, sed, shell, make,
> etc.), going to administrative meetings,
> occasionally installing, reviewing, or
> testing software; occasionally engineering
> part of a software system; or, doing computer
> system administration tasks; etc. The term
> "programmer" doesn't really fit such an
> occupation, particularly as the person
> may not have much time to program or may
> not receive any programming assignments.
>
>
> As for what "software engineering" is:
>
> "Software Engineering" could mean:
>
> writing requirements and supervising programmers,
> testers, and procurement; (this person is partly
> a "supervisor" of people, and/or partly a "project
> manager" using project management skills which,
> in the main, aren't particular to software);
>
Ask any practicing engineer (that is a _real_ engineer: Civil, Mechanical, Electrical
etc. ) what percentage of his/her time s/he spends actually designing whatever it is
that they design. I think that you'll find that typically it amounts to far less
than 50%. So the expresion 'I design X' is not a complete description of the job.
The job of engineering involves a lot of administration, evaluation, documentation
etc.
As for the programming part: It is acceptable (_real_) engineering practice to
construct, or have constructed, a prototype of whatever it is that the engineer is
designing. The reason that (in SE) the designer typically actually builds the
prototype is that we have not yet found a concise method to communicate our design
to programmers (where _real_ engineers can draw plans and pass them out to 'the
shop' for construction).
Unfortunately, in the case of software the step from prototype to
production is trivial so we don't _have_ to go back and update our design and we
often just pass off our re-worked prototype as _the_ product.
> . . .
>
>
> After all the above, I must now admit, in the general
> interest of truth, that I myself could barely be called
> either a designer of computer programs or (as the term
> is generally used at "A" above) a "software engineer",
> as I only do those things part of the time, very seldom
> have managed multi-person projects, and am less experienced
> than several others who write to this newsgroup.
As I've said, engineering, as a profession, involves a great deal more than
designing. Also, there is no requirement to be the _most_ experienced in a field
to call yourself an engineer.
> . . .
>
> leh...@ames.arc.nasa.gov
---
Dennis Peters | den...@newbridge.com |
Newbridge Networks Corporation | Phone: (613) 591-3600 |
Kanata, Ontario, Canada. | FAX: (613) 591-3680 |
Mark Kanko
>
> I don't dispute the figures as such, but I wonder if there's some double
> counting going on. We're looking at a project at the moment for which
> we estimate the development time of a working core system to be 6 months,
> with at least a further 12 months for refinement and further development.
> Now, is that "maintenance"? By some definitions it is (since it involves
> fixing problems with existing code), so if you analyse our time on that
> basis it will look as though we're spending a lot of time on maintenance.
> However, is that a problem? I don't think so, because I don't see
> maintenance and development as necessarily distinct. In fact, most of
> our software "maintenance" involves additional functionality or altered
> functionality in response to changing user requirements.
I agree with your comments and that is exactly the point: The issue
is not whether we call a certain effort "development" or "maintenance"
but rather the fact that we don't (usually) build a software system one
time and then never have to touch it again! That is why it is so important
to design/implement with future maintenance in mind. One of Lehman's 'Laws of
S/W Evolution' says that any (I'd say most) existing software system
must either evolve (i.e., be modified for whatever reason) or eventually
become obsolete.
I wouldn't call the quoted numbers "double-counted". Then DO include
the kind of refinement you're talking about. This is called perfective
maintenance (again, see Pressman book). Three other kinds are corrective
(to fix bugs or defects), adaptive (to meet changing H/W or data envi-
ronment requirements), and preventive (to enhance future maintainability).
Just to put this all in a different light-- Many of the USAF's fighter
aircraft have been extremely effective in combat. But when it comes
to maintenance, some of them have been real "bears". Entire subassemblies
not related to the maintenance task had to be removed in order to get
to the actual maintenance task (e.g., having to remove the entire ejection
seat so that a battery for the system clock can be replaced). Well, we
don't build airplanes like that anymore. Complete Reliability and
Maintainability assessments are done (and redone) on the entire design
before any sheetmetal is bent. Why? Because when it comes combat time,
we can't afford a 3-hour turn-around between sorties for a routine
maintenance task. Are there compromises? Sure! But the compromises
are a matter of planned (engineered?) choice, not chance.
I've really appreciated seeing all the viewpoints on this subject.
[I didn't say I agreed with them all! ;-) ]
Allen Adams
The EE example was intended to show why some engineers think it is 'silly'
to practice the principle's espoused by 'software engineers'. This
was said during an effort that I was leading where we were converting
software I had written from Pascal to Ada. The two other main player's
backgrounds in this situation, besides myself, were EE and CS. The CS
person had done several things in Ada and was trying to approach the
conversion in, for lack of better words, an object-oriented manner (this
was before OOP was the latest buzzword). The EE (as an aside here, I am
not trying to portray this EE as an example of ALL EEs, just using him
as a reference point) wanted no part of this. Ada was just another
language like FORTRAN and he felt that to try and 'software engineer'
the solution just got in the way of getting his job done on time.
Since I was interested in other things at the time, I let each person
go on the paths they felt more comfortable with. The exercise, in my
mind, proved that you could develop packages in Ada that can and will
be re-used, as well as a person has the ability to treat Ada like
FORTRAN and generate code, that might be messy, but 'works' just
like the 'software engineered' code.
So this leads me to two points. The first is that the 'ilities'
associated with software engineering are meant to help people
cope with the problems they have had/still do have/will continue to have
with modifying code when some 'baseline' is reached. This applies
to code sizes small, medium, and large. Now there are things in
software engineering, like object-oriented design, data flow analysis,
etc., that help people reach the initial baseline they are striving for.
If done properly, not only will this 'software engineering' help them
make changes to this baseline, it should also help them, or some poor
lost soul who has the misfortune of picking up this baseline from
someone else, figure out what they were doing when they reached this
baseline. In my example above, the EE ran into problems several times
because of his design/lack thereof. Was this due to inexperience??
Maybe, but as time went on, I think he wished he had done some of
the 'software engineering techniques' that he knew about, but ignored.
My second point deals with my reference to 'software artists', rather
than 'software engineer'. If you apply the 'software engineering
techniques', one will find the strengths and weaknesses in doing so.
But the knowledge base that one will obtain will allow them to
tackle the next software assignment with more 'colors on their palette.'
If one only knows about red, green, and blue (do loops, if-then-else,
assignment statements) a picture can indeed be painted, and 'beauty
will be in the eye of the beholder.' If one has more colors, a different
picture can be painted. But I will bet you the person that had the
red, green, and blue will try and logically explain why there 'picture'
is better, as will an argument come from the painter with more colors.
Neither side will listen to the other, and each artist will be
resistent to the other side. So to conclude, I like 'software
engineering techniques' because I like trying new ways to solve
problems, and every time I apply them, I learn something new.
It is very hard to argue with someone who has painted their picture
with red, green, and blue, maybe painfully mixed some of the colors to
get green, yellow, magenta, cyan, black, and white, and they are
'proud' of their picture. To tell them otherwise is 'insulting to
them.'
Allen Adams
Small Systems Solutions
sch...@ide.com (Stephen Schmid) writes:
>The analogy I like best is:
>
>As a carpenter is to an architect,
>so is a programmer to a software engineer.
Perhaps a carpenter is to an architectural engineer as a programmer
is to a software engineer.
Of course, to stretch the analogy, a software project is like a building
project without an architect, a good set of blueprints, or an agreed-upon
method for erecting the house. The subsystems will function great by
themselves, but for some reason the lights flicker when the toilets are
flushed...
--
Small Systems Solutions 1563 Solano Avenue, Suite 123
s...@netcom.com Berkeley, CA 94707-2116
The above-expressed opinions aren't necessarily
Dain Samples
Indeed not. The State of Ohio passed a law last month the forbids
anyone from using the term `engineer' in their title or description
unless:
(1) They are licensed by a state recognized licensing board.
(2) They graduated from an ABET accredited department of
engineering.
Note that ABET is the accreditation organization for *engineering*
departments; CSAB (I think is the acronym) is the accrediation
organization for Computer Science departments. For those of you
planning to live in the state of Ohio and getting your degree from a
Computer Science department, you will have legal problems if you call
yourself a `software engineer' and do not become a licensed engineer.
--
========================================================================
A. Dain Samples, Dain.S...@uc.edu, wk:(513)556-4783, hm:(513)771-5492
------------------------------------------------------------------------
It is so difficult to find the beginning. Or, better, it is difficult
to begin at the beginning. And not try to go further back.
-Wittgentstein (from "On Certainty")
May the background be with you.
-Heidegger (from "Being and Time", paraphrased)
John Lehman -- GDP
> ... should we ask that a Civil Engineer, when asked what s/he
>does for a living reply: "I design roads/bridges/sewer systems"? I think
>that the term 'Software Engineer' is no more improper than 'Civil Engineer'.
I wondered what civil engineers do. So it isn't the above ...
>> . . .
>>
>> "Software Staff Person" or "Software Staff"
>>
>> which would cover an occupation including
>> writing purchase requests for software license
>> renewals, occasional debugging or consulting,
...
>
>... the expresion 'I design X' is not a complete description of the job.
>The job of engineering involves a lot of administration, evaluation,
>documentation etc.
>
>As I've said, engineering, as a profession, involves a great deal more than
>designing.
I take, as your point, that there is no simple definition
of "engineer".
We all know approximately what a software engineer is, and
maybe we should let it go at that. However I'm not satisfied
with such a term which covers so many activities. That's
why I keep trying to simplify the definition.
Is it feasible for a practicing software engineer to write
down what s/he does so that a group of people who are not software
engineers could learn to fill in when the software engineer
takes a year-long sabbatical leave (or goes away forever)?
Can anyone offer a system of categories describing what
software engineers do, in simple terms?
How should a person, who is not a sw eng., but is considering
hiring one, determine whether the person calling him/herself
a sw eng. really is one? The hirer would probably resort to
consulting a list of what activities are really needed for the
job at hand; and the phrase "software engineer" (to my way of
thinking) would not be useful terminology; on the other hand,
one sees "software engineering" listings in the want ads,
and unfortunately we don't (yet) have any phrase that brief
which describes the position.
I was about to say, if a person calls him/herself a software
engineer, it is so hard to disprove them, that the title always
stands. But that's not quite true; it just takes a software
engineer to know one. I don't yet see any consensus on a
better terminology.
There was (/is) a somewhat similar situation with the phrase
"system programmer". A long time ago I worked with some people
who called themselves that; but there was such a great difference
in what they could do that they certainly should not all be called
by the same title. It takes one to know one; except I found out
who was real and who wasn't by hearing them talk (over a long
period of time, after all of them were already hired).
Peter Chubb,x114,6982322,3982735
who works at more than one level: not only does such a person
design/implement/manage/maintain/etc software, s/he studies the
*process* by which software is produced, implemented, maintained,
etc., with the aim of improving it next time around. Thus a software
engineer is a meta-designer of software: the person who designs the
methodologies for the programmers to follow.
(This matches my previuous experience as an electrical engineer: the
engineers decided what to do to build the power station, and told the
draughtsmen, who translated that into drawings the contractors could
understand... along with written instructions as to how to build or
operate the powerstation. We chose which methodologies to use,
modified them, then told the contractors to use them, and inspected
the plant as it was being built to ensure they got it right. Often
they didn't, and we'd have to invent appropriate remedial methods)
Regards,
- Peter Chubb
Softway Pty Ltd, P.O. Box 305, Strawberry Hills, NSW 2012, AUSTRALIA
Phone: +61 2 698 2322; Fax: +61 2 699 9174; Telex: AA27987
Internet: pet...@softway.oz.au UUCP: ...!uunet!softway.oz!peterc
Johnny Schmittou EXUTEEG x7887 Dallas Texas USA
I always liked the term "computer scientist" over the term "software
engineer". If people get computer science degrees (what I received),
why not call those people computer scientists? Perhaps when colleges
have software engineering degrees (and probably some colleges already
have this) a person who earns this degree may be rightfully called
a software engineer.
In the 3 companies for which I've worked, my titles thus far have been:
1) Software Design Engineer
2) Software Engineer/Member of Technical Staff (I always thought MTS was
a nice term)
3) Senior Engineer
My two cents...
___________________________________________________________________________
Internet....: exu...@exu.ericsson.se | "Everything I say is the absolute
Real life...: Johnny Schmittou | Gospel... Nah, just kidding."
Virtual life: Q-man ---<<<I'd rather be drumming.>>>--- Dallas, Texas USA
Jerry Heyman
In article <1992Aug12....@m.cs.uiuc.edu>, mar...@m.cs.uiuc.edu (Brian Marick) writes:
> sch...@ide.com (Stephen Schmid) writes:
>
> >As a carpenter is to an architect,
> >so is a programmer to a software engineer.
>
> A dangerous analogy to make to the son of a carpenter, who spent much
> of his childhood listening to his father fume about unlivable,
> unimplementable designs. Some of the things he had to talk people out
> of were so stupid even I saw it, but some were rather subtle.
In several of the places that I've worked, there was a clear delineation
between those doing software 'architecting/designing' (engineering?) and
those doing the actual implementation (programmers). On many occassions
there were large holes in the architecture (big enough to drive a truck
through). In other cases, even when implemented as designed, the function
failed for very subtle reasons (following a code path not anticipated).
With these kind of problems, I would suggest that the analogy from Stephen
Schmid is more correct than not.
>
> Brian Marick, mar...@cs.uiuc.edu, uiucdcs!marick, mar...@testing.com (pending)
jerry
--
Jerry Heyman e-mail : je...@austin.ibm.com
IBM AWD AIX Dev Env Tools MS 9631 "Software is the difference between
Austin, TX 78758 hardware and reality"
*** All opinions expressed are exactly that - my opinions and NOT IBM's
Charles R. Martin
Here's a quick quiz (with, perhaps, an embedded clue):
what is the difference between a chemist and a chemical engineer?
--
Charles R. Martin/(Charlie)/mar...@cs.unc.edu/(ne c...@cs.duke.edu)
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
----------------------------------------------------------------------
"I am he who walks the States with a barb'd tongue, questioning every
one I meet,/Who are you that wanted only to be told what you knew
before?/ Who are you that wanted only a book to join you in your
nonsense?" _Leaves of Grass_ xxiii.4.
Jeff Musa
>
>I don't dispute the figures as such, but I wonder if there's some double
>counting going on. We're looking at a project at the moment for which
>we estimate the development time of a working core system to be 6 months,
>with at least a further 12 months for refinement and further development.
>Now, is that "maintenance"? By some definitions it is (since it involves
>fixing problems with existing code), so if you analyse our time on that
>basis it will look as though we're spending a lot of time on maintenance.
>However, is that a problem? I don't think so, because I don't see
>maintenance and development as necessarily distinct. In fact, most of
>our software "maintenance" involves additional functionality or altered
>functionality in response to changing user requirements.
>
spent enhancing a product to meet the needs of customers and fixing bugs in
an already released product. These included data corruption, run-time errors
implementing new controls, etc... Development (the development that the
figures are based on) is the act of creating a new product to then be put
into the maintenance phase. Classic software engineering stipulates a life
cycle of software that reflects a development phase, maintenance, and
demise.
Those that create hack programs, force maintenance programmers
to write hack fixes and these (one on top of another) cause more time to
be spent figuring out and rewritting code just to fix or enhance. An
engineered approach is more likely to be delivered on time, meet the
customers needs, be more easily maintainable/enhanceable, and very probably
more robust due to the extensive write-ups and prototyping required before
starting a truly engineered software project.
One possible difference in semantics should be pointed out, if you are
developing shrink wrapped software versus software systems, "development"
probably would encompass enhancements to this existing product.
---
Jeff Musa (mu...@cmptrc.lonestar.org) | "These opinions are my own
CompuTrac Inc. (214) 235 - 7161 #3810 | and do not necessarily
222 Municiple Drive | reflect those of my employer"
Richardson, TX 75080
Chris Prael
>
> I always liked the term "computer scientist" over the term "software
> engineer". If people get computer science degrees (what I received),
> why not call those people computer scientists? Perhaps when colleges
> have software engineering degrees (and probably some colleges already
> have this) a person who earns this degree may be rightfully called
> a software engineer.
I went through college before there were "computer science" degrees.
The only fields that felt they needed to tell the rest of the world that
tey had scientific pretensions were "political science", "social
science", and "military science" (better known as ROTC).
The next thing that I have observed is that poeple who prefer to be
called "computer scientist" tend (though not invariably) to perform more
like technicians than like engineers or scientists. The real problem
here is in the experience they have (or have not) gained in college.
Perhaps there is too much memorization of minor techniques and not
enough learning of principles.
In the rest of the technical world, scientists try to figure out why the
latest thing the engineers built works, engineers build products, and
technicians handle the scut work.
The label programmer covers all three quite well.
Just another two cents
Chris Prael
Travis Marlatte
the definition of "software engineering" or just get a better feel
for what it is we are supposed to be doing?
It seems that if someone were able to prove that a software engineer
is a person who spent 15% of his day on the beach, everyone in this
discusion with "Software Engineer" on their business card would get
their bathing suit out.
I think that part of the problem is that the duties assigned to a
software person tend to cover the entire life-cycle so it is hard to
create a more specific title.
Let's get back to discussing how we get the job down, not what we call
it.
Travis,
Software Engineer, Reuse Specialist, Project Coordinator, Product Planner,
Scheduler, Resource Manager, Staff Phsycologist, Writer, System Designer,
Software Designer, Documentation Specialist, Programmer, System Tester,
User Alpha, Software Maintenance Administrator, Field Consultant,
Trouble Shooter, Friend
--
Travis
allen Adams
>What's the point of this discussion? Are we really trying to nail down
>the definition of "software engineering" or just get a better feel
>for what it is we are supposed to be doing?
I think the answer to the second question is 'Yes and Yes'. When
people get together to discuss 'what it is they do', describing
what a 'software engineer' does can be both hard to define and defend
as a worthwhile thing to do.
>It seems that if someone were able to prove that a software engineer
>is a person who spent 15% of his day on the beach, everyone in this
>discusion with "Software Engineer" on their business card would get
>their bathing suit out.
I personally go for walks after work along The Strand here in
Manhattan and Hermosa beaches, so maybe I qualify :) .
>I think that part of the problem is that the duties assigned to a
>software person tend to cover the entire life-cycle so it is hard to
>create a more specific title.
Very good point. I think that is the root of the problem in coming
up with definitions.
>Let's get back to discussing how we get the job down, not what we call
>it.
I would encourage just the opposite. It is good every once in a while
to stop and look around to see what is going on, what is influencing software
engineers, etc. I would discourage personal attacks about people's beliefs
about software engineering, but to discuss the whats, whys, and wheres of
the positive/negative beliefs that software engineers have run into, helps
put things into perspective now and then.
Geoff Miller
>Maintenace and development are very distinct. Maintenance is the effort
>spent enhancing a product to meet the needs of customers and fixing bugs in
>an already released product. These included data corruption, run-time errors
>implementing new controls, etc... Development (the development that the
>figures are based on) is the act of creating a new product to then be put
>into the maintenance phase. Classic software engineering stipulates a life
>cycle of software that reflects a development phase, maintenance, and
>demise.
And classical geography taught that the Earth was flat.
I would argue with your definitions - to me, maintenance involves
current functionality, development involves new functionality. Often a
given piece of work will involve both. Certainly, if you consider what
I call "development" as "perfective maintenance" (I've forgotten who
posted that, but thanks) then yes, it's "maintenance", but it's a
different sort of maintenance from the "bug-fix" type.
>Those that create hack programs, force maintenance programmers
>to write hack fixes and these (one on top of another) cause more time to
>be spent figuring out and rewritting code just to fix or enhance.
In my environment those who create the systems can expect to maintain
and develop them, usually working directly with the users. Self-interest
is a powerful incentive to do it right.
>An engineered approach is more likely to be delivered on time, meet the
>customers needs, be more easily maintainable/enhanceable, and very probably
>more robust due to the extensive write-ups and prototyping required before
>starting a truly engineered software project.
And some projects are so well and thoroughly "engineered" that they are
obsolete before they are delivered; perhaps the best example here in
Australia was the Public Service's "Mandata" system. I'm talking
about custom information systems here, not off-the-shelf products or
even large transaction-oriented systems, both of which present different
problems. In my experience the most important part of prototyping is
to get the users working with the system, hence the need to deliver a
core system which in turn provides them with some benefit. As they use
it, they provide the feedback to drive the development, and (again, in
my experience) this often opens up lines of development that were not
originally foreseen.
This, to my mind, brings up the major difference between software
engineering and the sort of engineering that results in bridges, cars
or TVs - that we are designing a product which will be developed
while it is in use, whereas in other forms of engineering it is the
replacement product which is being developed.
Geoff Miller (g-mi...@adfa.oz.au)
Computer Centre, Australian Defence Force Academy
John Goodsen
>>Maintenace and development are very distinct. Maintenance is the effort
>>spent enhancing a product to meet the needs of customers and fixing bugs in
>>an already released product. These included data corruption, run-time errors
>>implementing new controls, etc... Development (the development that the
>>figures are based on) is the act of creating a new product to then be put
>>into the maintenance phase. Classic software engineering stipulates a life
>>cycle of software that reflects a development phase, maintenance, and
>>demise.
>
>And classical geography taught that the Earth was flat.
>
>I would argue with your definitions - to me, maintenance involves
>current functionality, development involves new functionality. Often a
>given piece of work will involve both. Certainly, if you consider what
>I call "development" as "perfective maintenance" (I've forgotten who
>posted that, but thanks) then yes, it's "maintenance", but it's a
>different sort of maintenance from the "bug-fix" type.
>
The above discussion is premised upon a more classical (outdated)
software development lifecycle based upon or similar to the waterfall
model, which has been shown over and over again to be a totally
innappropriate model of software development reality.
Choosing a more modern process model like the evolotionary spiral
process (ESP) model, which is a much better model of reality, one
considers maintenance no differently than development. It's just
another cycle of development. The term maintenance might only be used
to help get more money from your customer but you would still model it
in the exact same manner as any other development cycle.
>>Those that create hack programs, force maintenance programmers
>>to write hack fixes and these (one on top of another) cause more time to
>>be spent figuring out and rewritting code just to fix or enhance.
>
>In my environment those who create the systems can expect to maintain
>and develop them, usually working directly with the users. Self-interest
>is a powerful incentive to do it right.
>>>An engineered approach is more likely to be delivered on time, meet the
>>customers needs, be more easily maintainable/enhanceable, and very probably
>>more robust due to the extensive write-ups and prototyping required before
>>starting a truly engineered software project.
>
>And some projects are so well and thoroughly "engineered" that they are
>obsolete before they are delivered; perhaps the best example here in
>Australia was the Public Service's "Mandata" system. I'm talking
>about custom information systems here, not off-the-shelf products or
>even large transaction-oriented systems, both of which present different
>problems. In my experience the most important part of prototyping is
>to get the users working with the system, hence the need to deliver a
>core system which in turn provides them with some benefit. As they use
>it, they provide the feedback to drive the development, and (again, in
>my experience) this often opens up lines of development that were not
>originally foreseen.
>
Once again, I would point you to the ESP process model and note that
prototyping is simply the early development cycles (of the REAL
PRODUCT in most cases). It's all development and it all needs to me
modeled and managed in the same manner.
John Goodsen
EVB Software Engineering
good...@ajpo.sei.cmu.edu
j...@evb.com
--
John Goodsen (619) 530-0881
The Dalmatian Group U.S. PCIS Expert Review Team
User Interface Specialists Ada Joint Program Office
j...@dalmatian.com good...@ajpo.sei.cmu.edu
Bonus, Iniquus, Celer - Delegitus Duo
[...]
>
> The above discussion is premised upon a more classical (outdated)
> software development lifecycle based upon or similar to the waterfall
> model, which has been shown over and over again to be a totally
> innappropriate model of software development reality.
I recommend that everyone read Royce's paper on the waterfall model. The
common misunderstanding, and what he recommended in the paper are totally
different. The reference: Managing the Development of Large Software Systems,
Winston Royce, IEEE WESCON, 1970, pages 1-9.
I believe that I have stated this before but will do so again. At some scale,
every software development process looks like a waterfall. The "classical"
waterfall looks like the ETVX model (Entry, Task, Validate, eXit). Even
assembling a prototype takes some planning, even though it may be minutes
rather than months.
Less focus on the model_of_the_month club and more focus on the similarities
between them and the contained tasks would help us get our jobs done.
I personally prefer the Monty Python "Confuse-a-cat" model for planning
purposes. You never get any questions about where you are at.
George X. Kambic
standard evolutionary revolutionary chaotic sprial waterfall disclaimer
John Lehman -- GDP
>> What's the point of this discussion? Are we really trying to nail down
>> the definition of "software engineering" or just get a better feel
>> for what it is we are supposed to be doing?
>>
>> It seems that if someone were able to prove that a software engineer
>> is a person who spent 15% of his day on the beach, everyone in this
>> discusion with "Software Engineer" on their business card would get
>> their bathing suit out.
>>
>> I think that part of the problem is that the duties assigned to a
>> software person tend to cover the entire life-cycle so it is hard to
>> create a more specific title.
>>
>> Let's get back to discussing how we get the job down, not what we call
>> it.
>>
Well said; if you don't take titles seriously. Some of
us just don't like to wear ill-fitting labels that invoke
wrong perceptions by others. For example I'd prefer that
no-one call me a "professional" unless I've already done
something to justify such a lofty word. Not that I'd deny
that particular label myself; but something plainer and
provable would feel more comfortable.
Regarding discussing "how to get the job [done]" -- are
there any spin-off groups, from comp.software-eng, that
discuss specific groups of tools, such as variants of
"make" or "software configuration management tools"?
The FAQ's of comp.software-eng help some, but not enough.
leh...@ames.arc.nasa.gov,
Software technician; and sometimes a writer, technical
writer, debugger, programmer, or engineer; and, often
a Student.
Johnny Schmittou EXU-T-EEG x7887 Dallas Texas USA
I personally prefer the Monty Python "Confuse-a-cat" model for planning
purposes. You never get any questions about where you are at.
===
OK, I gotta know. What's the "confuse-a-cat" model? It's gotta be good
if it's from Monty Python. Maybe I can use it on my next project...
Rob Bradlee
>
>Here is my perception of what the above list is for the software industry:
>
>MECHANICAL ENGINEERING SOFTWARE ENGINEERING
>______________________ ____________________
> 1. Safety 1. Delivery date
> 2. Quality 2. Cost
> 3. Cost 3. Use latest "whiz-bang" technique (OO)
> 4. Delivery date ...
> n. Quality
>
Here at my company the list is this:
SOFTWARE ENGINEERING
--------------------
1. Delivery Date
2. Delivery Date
3. Delivery Date
4. Cost
And cost really means "do it with the available bodies unless you can make it
look like a crisis and then we'll pull some people off one of the other crises
so that you can meet your first three priorities." The obvious reply is
"Well your company doesn't do Software Engineering". I agree.
--
Rob Bradlee w:(508)-658-5600 X5153
Agfa Corporation. ...!{decvax}!cg-atla!bradlee
200 Ballardvale St. bra...@cg-atla.agfa.com
Wilmington, Mass. 01887
allen Adams
>In article <1992Aug9.1...@hubcap.clemson.edu> of...@hubcap.clemson.edu (A. Jeff Offutt) writes:
>>
>>Here is my perception of what the above list is for the software industry:
>>
>>MECHANICAL ENGINEERING SOFTWARE ENGINEERING
>>______________________ ____________________
>> 1. Safety 1. Delivery date
>> 2. Quality 2. Cost
>> 3. Cost 3. Use latest "whiz-bang" technique (OO)
>> 4. Delivery date ...
>> n. Quality
>>
>Here at my company the list is this:
>SOFTWARE ENGINEERING
>--------------------
>1. Delivery Date
>2. Delivery Date
>3. Delivery Date
>4. Cost
>And cost really means "do it with the available bodies unless you can make it
>look like a crisis and then we'll pull some people off one of the other crises
>so that you can meet your first three priorities." The obvious reply is
>"Well your company doesn't do Software Engineering". I agree.
Well if your company is like mine and considers every electronic message
you work on as company property, they will be unhappy with the above
statement (good luck on you job search :) ).
As an aside, last week I went on a job interview at SEI Information
Technology, which provides consulting in the 'commercial' arena. Since my
work background involves the defense area, one of the two consultants who
was interviewing me wanted to know what I could provide to commercial
businesses. When I proposed that I could not only develop software and the
same time as engineer it, he was surprised. He indicated that most
commercial companies consider software engineering an unnecessary expense and
that for me to do that might offend the companies I would consult. I
certainly would like to get out of the defense industry, but at what cost!!
I guess if I get layed off, maybe my tune would change.
Allen Adams
Please do not be confused - The above opinions are certainly not those of
TRW Inc. or any one associated with them.
Andrew J C Blyth
>
> I agree with your 4th definition (that Software Engineering is a complete
> engineering discipline that provides rules, guidelines, etc based on
> proven techniques and sound theories. I also feel that Software Engineering
> NEEDS to be recognized as a true engineering field or else the cost of
> business as usual (always the bottom line) will continue to damage the software
> field. However, I see some hurdles to overcome:
There have been disgussions before on this news group about what is
software emgineering and these discussions generally as a rule come
down to what is ment by the term engineer.
Now I have no problems with people calling them selves software engineers.
And yes I agree that there are certain engineering pronciples that
software engineers can use when attempting to solve problems in software.
However you have to be carful about how the term engineer in applied.
As has been stated before on this newsgroup engineering disaplines such
as civil engineering draw upon the physical sciences to give the mean.
For example we can talk about the physical properties of a bridge, the
question as to where or not we can talk about the physical properties
of a piece of software remain unansered. It is because of this unanswered
question that I do not that that you can say that Software Engineering is
a complete engineering discipline.
In 1987 Kalle Lyytinen published a paper called "Different Perspectives on
Information Systems: Problems and Solutions". This paper appeared in ACM
computing surveys Vol.19 No.1 March. In this paper he outlines three types
of process models that a software engineer could use to solve a problem.
The first type is the engineering model, this model works best on technical
system. The second model is the learning model and this works best on
soical system. Finally, the final process model is the dialogue process
model, again this works best on a soical systems.
By stateing that software engineering is a total engineering disapline
you are forceing engineering priciples and practices to be applied to
soical problem. The evidence of where people have failed to deliver
software solutions to soical problems would seem to surgest that using
and pure (hard) engineering option to understand and solve what are
in essence soical problems does not work.
> 1) A majority of persons developing software are still using ad-hoc
> techniques and I think this reduces the entire software community. In Electrical
> Engineering it is unlikely that someone without extensive training could go out and
> begin designing and building chips (especially ones that people base their life
> and livelyhood on). In software this situation is far too common.
This situation is changeing as sofware engineers are being held accountable by
law for the software that they write. In addition companies are impossing
firm rules about who pays for what if the software does not work. The day is
comeing when Software Engineers will have to carry insurance and have professional
status similar to the Doctors in the US today.
> 2) If Software Engineering is recognized as a true engineering than the
> responsibility of those claiming to be SE's will be enforcable. For example, it
> will be much easy to prove gross negligence on someone claiming to be an SE if they
> failed to follow accepted standards (such as IEEE testing guidelines) when a mishap
> occurs.
I do not think that by using your approach you will solve the software crisis, the
problems that gave rise to it will still be there unsolved.
> The solutions to these problems (training, managerial support and enforcement,
> etc) are easy to say (lip service) but a LOT harder for large organizations to
> actually change.
On the above point I totally agree with you. Large organizations have to want to
change and inorder for them to do so they will require clear payback after a
specific time.
Andrew.
Steven King, Software Archaeologist
>mu...@cmptrc.lonestar.org (Jeff Musa) writes:
>>Those that create hack programs, force maintenance programmers
>>to write hack fixes and these (one on top of another) cause more time to
>>be spent figuring out and rewritting code just to fix or enhance.
>
>In my environment those who create the systems can expect to maintain
>and develop them, usually working directly with the users. Self-interest
>is a powerful incentive to do it right.
Not necessarily. *IF* the developers believe that doing it right will
save them hassle in the long run, then you're right. But I've worked
with enough people who have an "Oh, let's just make it work" attitude.
This is regardless of the fact that they'll have to fix or add on to it
a year or two later, after they've forgotten what they've done.
Another dis-incentive to do it right is schedules and management
buy-in. I'm currently embattled to convince the managers of a project
to let us do it right to avoid headaches down the road. The managers
want to "just make it work" and don't agree that neat code is
significantly easier to maintain in the long run. Mind you, most of
the managers come from a hardware rather than a software background.
I agree totally with Jeff Musa. Hack development forces hack
maintenance, REGARDLESS of who is developing and who is maintaining, or
of the fact that the same person may be doing both.
--
-------------------------------------------------------+-----------------------
The amount of work that actually got done during the | Steven King
week is inversely proportional to the number of | Motorola Cellular
entries in 'timetool'. | ki...@rtsg.mot.com
m...@mole-end.matawan.nj.us
> This situation is changeing as sofware engineers are being held accountable by
> law for the software that they write. In addition companies are impossing
> firm rules about who pays for what if the software does not work. The day is
> comeing when Software Engineers will have to carry insurance and have
> professional status similar to the Doctors in the US today.
I'd prefer a status equivalent to other Professional Engineers. There
exists a PE licensure system in every state of the US, and I assume that
other developed nations have them as well. Medical doctors in the US
operate under a Truly Horrible and Litigatious malpractice system; so
far engineers have only had a small taste of this.
This probably implies that Software Engineers will have to master the
basic physical sciences and their analytic techniques. It also implies
that other engineers will have to learn the basics of `software theory.'
I suspect this should include E/R modelling, recursive structures and
control, possibly DFDs, basic O(N) analysis, and basic testing and
software management techniques. It should NOT include the FORTRAN codes
that were on the EIT (Engineer-In-Training) exam that I took in 1980.
Advanced subjects on that exam for SE's _should_ include data
normalization, scheduling, imperative languages, functional languages,
OO, and alternates among such areas as game theory, concurrency, etc.
(What about the social aspects of project requirements analysis?)
Should the material science/thermodynamics sections have an alternate
for software engineers? Queueing theory, perhaps?
--
(This man's opinions are his own.)
From mole-end Mark Terribile
m...@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Joseph Brothers
>>MECHANICAL ENGINEERING SOFTWARE ENGINEERING
>>______________________ ____________________
>> 1. Safety 1. Delivery date
>> 2. Quality 2. Cost
>> 3. Cost 3. Use latest "whiz-bang" technique (OO)
>> 4. Delivery date ...
>> n. Quality
>>
>Here at my company the list is this:
>
>SOFTWARE ENGINEERING
>--------------------
>1. Delivery Date
>2. Delivery Date
>3. Delivery Date
>4. Cost
It took me a while to notice that the one item missing from all these lists is
Effectiveness.
My dictionary defines engineering as "applying scientific knowledge to practical ends".
It's embarassing to me how often I get caught up in irrelevancies while trying
to put what I know to work. Hmmm, like posting this when I should be reading old
grotty code 8-).
--
Joseph L. Brothers
brot...@mdd.comm.mot.com uunet!mdisea!brothers
"I am speaking solely for my self, not my employer."
Hor Shoon Chan (Mr)
: Various netpersons wrote:
: >>MECHANICAL ENGINEERING SOFTWARE ENGINEERING
: >>______________________ ____________________
: >> 1. Safety 1. Delivery date
: >> 2. Quality 2. Cost
: >> 3. Cost 3. Use latest "whiz-bang" technique (OO)
: >> 4. Delivery date ...
: >> n. Quality
: >>
: >Here at my company the list is this:
: >
: >SOFTWARE ENGINEERING
: >--------------------
: >1. Delivery Date
: >2. Delivery Date
: >3. Delivery Date
: >4. Cost
:
: It took me a while to notice that the one item missing from all these lists is
:
: Effectiveness.
:
: My dictionary defines engineering as "applying scientific knowledge to practical ends".
: --
: brot...@mdd.comm.mot.com uunet!mdisea!brothers
: "I am speaking solely for my self, not my employer."
Another big element missing from the list, which could be classified as
a component of Quality, is USABILITY. Generally, software development
is about designing, developing,and implementing systems or tools for
people to use. So what if it is the latest technology and so what if you
deliver the system on time. If a tool or product is not usable or
difficult to learn and use then we have failed as software engineers.
SC Hor -- Standard Disclaimer
"You will never know until you test it"
Geoff Miller
>g...@ccadfa.cc.adfa.oz.au (Geoff Miller) publicly declared:
>>mu...@cmptrc.lonestar.org (Jeff Musa) writes:
>>>Those that create hack programs, force maintenance programmers
>>>to write hack fixes and these (one on top of another) cause more time to
>>>be spent figuring out and rewritting code just to fix or enhance.
>>
>>In my environment those who create the systems can expect to maintain
>>and develop them, usually working directly with the users. Self-interest
>>is a powerful incentive to do it right.
>Not necessarily. *IF* the developers believe that doing it right will
>save them hassle in the long run, then you're right. But I've worked
>with enough people who have an "Oh, let's just make it work" attitude.
>This is regardless of the fact that they'll have to fix or add on to it
>a year or two later, after they've forgotten what they've done.
It will save them hassles from me. One of my responsibilities is
management of applications development. However, I still consider my
point to be largely valid. A programmer who is working on a day-to-day
basis with the users of a system certainly has a powerful incentive to
get things done quickly, which does lead to a temptation to cut corners,
but equally there is a powerful incentive to do things in a way that
does not cause problems later, because the programmer is seen as
personally responsible.
As far as "hack" programs are concerned, let me state two of my own
policies:
1. Every non-trivial program must be properly structured and documented.
2. There is no such thing as a non-trivial program.
>Another dis-incentive to do it right is schedules and management
>buy-in. I'm currently embattled to convince the managers of a project
>to let us do it right to avoid headaches down the road. The managers
>want to "just make it work" and don't agree that neat code is
>significantly easier to maintain in the long run. Mind you, most of
>the managers come from a hardware rather than a software background.
My background is in software - in fact, I got into this business as
a user who got more interested in the techniques of computing than
what I was supposed to be using the computing for. I take your point,
but the battle for "doing it right" is one that I fight with the
users. BTW, I 'm not clear who you see as being the "managers" of
a project - the implication in what you write is that the managers
are computer-people rather than user-people, whereas in my environment
the "managers" of projects are mostly on the user side. We are developing
applications to support them, but they drive the overall project.
>I agree totally with Jeff Musa. Hack development forces hack
>maintenance, REGARDLESS of who is developing and who is maintaining, or
>of the fact that the same person may be doing both.
True, but until Jeff introduced the term we weren't talking about
hack development. If you, and he, are suggesting that rapid prototyping
and evolutionary development are necessarily "hack development" then
I respectfully disagree.
Geoff Miller (g-mi...@adfa.oz.au)
Deputy Manager Computing Services
Australian Defence Force Academy
Canberra ACT 2601
Andrew J C Blyth
> This probably implies that Software Engineers will have to master the
> basic physical sciences and their analytic techniques. It also implies
> that other engineers will have to learn the basics of `software theory.'
Here in the UK, courses are certified by the BCS (British Computer Society).
So if you apply to become a certified engineer from the BSC and if your
degree came from an acredited school then you are exempt from certain
examines. This forces poeple and universities to teach certain subject.
Andrew
Stephen Schmid
>In my opionion (for what it's worth) a software engineer is someone
>who works at more than one level: not only does such a person
>design/implement/manage/maintain/etc software, s/he studies the
>*process* by which software is produced, implemented, maintained,
>etc., with the aim of improving it next time around. Thus a software
>engineer is a meta-designer of software: the person who designs the
>methodologies for the programmers to follow.
>
I like that definition very much. Along those lines, perhaps a better
term for what many of us do most of the time would be "software developer".
I was never comfortable with the term "computer programmer", because there
is much more to software development than just programming. Likewise,
"software designer" is too restrictive. And "software engineer" is often
too broad. "Developer" seems about right.