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