soft-eng@MITRE.MITRE.ORG (Alok Nigam) (06/18/89)
Software Engineering Digest Sunday, 18 Jun 1989
Volume 6 : Issue 23
Today's Topics:
Importance of domain knowledge
Two Questions about Ready Systems' CARDtools (U)
need help choosing between INGRESS and PROGRESS (U)
Re: software engineers (U)
Re: What exactly is a software engineer ? (U)
Re: software engineers (U) 2
US Federal Software Projects - request for reference (U)
Component Specification (Was Re: software engineers) (U)
Re: US Federal Software Projects - request for reference (U)
Re: need help choosing between INGRESS and PROGRESS (U) (2)
Re: What exactly is a software engineer ? (U)
------------------------------------------------------------
Date: Wed, 10 May 1989 22:57:25 EDT
From: "James H. Coombs" <JAZBO@BROWNVM.BITNET>
Subject: Importance of domain knowledge
>I've heard it said that the best predictor of eventual success in building a
>large system is domain knowledge on the part of the designer, i.e. tax
>preparation software is best designed by someone who knows tax preapration
>well rather than someone who knows, say, human-interface design well.
Domain knowledge is stressed in only one of the four "archetypal perspectives
on the use of computers" discussed by John Kammersgaard in "Four Different
Perspectives on Human-Computer Interaction", International Journal of Man
Machine Studies, 28 (1988), 343-62.
Kammersgaard discusses the systems perspective, the dialogue partner
perspective, the tool perspective, and the media pespective. The article is
not as clear as I would like in some of its attempts at characterizing and
distinguishing the perspectives, and the reader must do some significant work
to put it all together. I read the article less than an hour ago, and I am
impressed by it enough to commit the perspectives to memory (or my
understanding of them at least) and to attempt to apply them in my work.
K's conclusion? Dialogue partner perspective (typical of AI and natural
lang.; argued against by Winograd and Flores) is not very promising.
Otherwise, the "message is not that one perspective is the right one; not even
that a single one of them is best suited to understand the use of a given
application. The point is rather that, by shifting between some or all of the
described perspectives, it becomes possible to gain a better understanding
when designing and using a particular computer application."
Oh, yes, domain knowledge is stressed in the tools perspective, which is
closely associated with analogic metaphors, such as the desktop of Xerox Star
and successor Macintosh.
------------------------------
Date: 9 May 89 17:46:16 GMT
From: Rick Low <mitel!melair!low@uunet.uu.net>
Organization: MEL Defence Systems Ltd., Ottawa, Canada
Subject: Two Questions about Ready Systems' CARDtools (U)
It seems that Ready Systems' CARDtools has become the de facto
standard CASE tool for real-time embedded system and software design
at my company. I have two questions for anyone who has used this package:
1. What design method does it support?
Possible answers I've come up with are
a) Hatley, sort of
b) Ward-Mellor, sort of
c) Ready Systems' own
d) anyone/everyone's (it's just a tool box)
TFM doesn't say what method is supported; neither does is have
any references listed that would give it away. When I read TFMs
I get the feeling that the answer is d), but this is never stated.
When I ask people here what method they use with CARDtools they say,
"Well, just CARDtools, right?" A recent article in Computer Design
magazine just said CARDtools supports Ward-Mellor, without really
saying how.
2. (really a general CASE question) Is there any size of project for
which use of tools like CARDtools is uneconomical?
Followups to comp.realtime please.
------------------------------
Date: 9 May 89 14:11:04 GMT
From: Bryan Beck <mstar!resource!bryan@ohio-state.arpa>
Organization: Resource Systems
Subject: need help choosing between INGRESS and PROGRESS (U)
I am in the process of making a DBMS selection, and I have narrowed my
choice down to INGRESS and PROGRESS.
I have found that both are quality packages and capable of handleing the
job. The only negative comment I have received is concerning INGRESS's
query/report generation capabilities.
Does any one have experience with both packages or qualified to compare
and contrast the two. Also I haven't heard anything negative about progress,
has any one had any complaints??
Any revelant comments that could help me make my decision would be
greatly appreciated.
------------------------------
Date: 10 May 89 04:05:06 GMT
From: Stanley Chow <jarvis.csri.toronto.edu!utgpu!bnr-vpa!bnr-fos!leibniz!schow@rutgers.edu>
Organization: Bell-Northern Research, Ottawa, Canada
Subject: Re: software engineers (U)
>Comparing numbers of people or pounds of documentation is not necessarily
>valid. My personal impression from working alongside assorted engineers
>is that individuals tend to be more specialized in the traditional engineering
>disciplines. [...]
Perhaps this is why engineer build bridges that work better than most
programs! There may be a lession for budding software engineers.
> [...] So for instance you might have somebody on a project that is
>concerned only with bolts, or electrical connectors, or maybe even with only
>a single oddly-shaped part made by a subcontractor. Many (most?) software
>people are in the opposite situation - they have to be concerned about all
>aspects of a 50K line program, and they rarely have the leisure to really
>understand the code proper, the design, the limitations, the consequences
>for other parts of a system, and so forth. [...]
I would consider 50K lines to be a (very) small part of a big software systen
or project. (No smiley). If one person cannot totally comprehand a small program
like that, either the person or the method ought to be examined carefully.
As I understand "software engineering", a good part of the effort is devoted to
making systems modular and understandable. One may disagree with the specific
approach - Ada, Modula-2, C++, etc., but the aim is valid.
In big systems, even in small 50KLOC programs, it is important to partition the
program into understandable chunks. S/W people call this module interface. The
civil/mechanical engineers call this "specification". It would be nice if the
mechanical engineer understood how stainless steel is made and what interesting
reactions corode different steel, but it is not necessary to build a bridge.
There are standards that gurantee N years of corodesion resistance as long as
the exposure to corosive chemicals are within certain specific limits.
The S/W analogy is like the mathmatics libraries. If you call this matrix
inversion routine, you will get back a good inverse as long as the input matrix
is not singular, etc.
May be the answer is a mandotary course in "standard writing" for all
software enginees.
As someone said, "Software will be a science when programmers stand on each
other's shoulders instead of each other's toes." [I would be grateful if
someone can point to the originator of this]
> [...] Just imagine how different things
>would be if you only had to be responsible for, say, 1,000 lines of code and
>could spend a year working on it. You spend time analyzing it in depth, you
>could polish the documentation, you could tune it for optimum performance.
>Unfortunately such a situation is rarely possible in today's environment...
>
Aside from a quibble with your scale, I agree with your goal. However, I like
to think that some, if not most, software projects are run better than you
make it out to be. If the situation is indeed as bleak as you say, then I
would worry about the future of S/W, especially in the USA or North America.
>Getting back to comparing bridges and programs, a more valid method might be
>to compare the information content of a program to that of a bridge (more
>accurately, to the size of its description). This would factor out sheer
>volume; 10,000 identical bolts aren't much more interesting than one bolt,
>ditto for code that is replicated in different parts of a program. Seems
>like at least one theorist would have looked at this in the past...
This is a subject that has interested me over the years. Let's say I make
a copy of a matrix addition routine, change it to do subtraction, how much
information have I added? What metrics can we use? Is it possible to determine
which programs are copies of each other?
------------------------------
Date: 9 May 89 22:53:55 GMT
From: Franklin A Davis <fad@think.com>
Organization: Thinking Machines Corporation
Subject: Re: What exactly is a software engineer ? (U)
> I am a student... I read that soft-
>ware engineering as a sub-discipline under computer science; but
>I also read in an another news group that software engineers
>were considered actual engineers (like AE,EE,ME ....).
>What are the actual degree requirements of software engineers and also
>what are their job definitions ?
I'll quote a definition by Richard Fairley from "Software Engineering
Concepts:"
Software engineering is the technological and managerial
discipline concerned with systematic production and maintenance of
software products that are developed and modified on time and within
cost estimates.
Dr. Fairley was a professor of mine and chairman of the faculty at the
late Wang Institute of Graduate Studies when I studied for my Masters
of Software Engineering. He's now head of the MSE program at George
Mason University.
Having studied (and argued about) the details of SE for a year in
school, and then working for nearly two, I feel I am just beginning to
become a good engineer. In my five years of work before my graduate
studies I think I was more a programmer than a true engineer.
Almost everyone who programs computers for a living is now referred to
as a "software engineer." I applaud the goal of having all programmers
practice real engineering, but I'm afraid the use of "software
engineer" as a job title is often inflated. Since there are only a
few schools in the world so far that grant degrees in software
engineering it would be impractical to have specific SE degree
requirements for jobs. Fortunately the real world is often a good
teacher, so people with CS degrees (or no degree at all) become
proficient engineers with experience.
My own working definition is that a software engineer is knowledgable
and disciplined about all the tasks involved in creating a *finished
product*, including specification, planning, design, writing test
plans, coding, debugging, testing, documenting, and maintaining. The
actual effort in writing code that just "works" is a small fraction of
the total.
Few CS departments devote more than a semester (if that!) to software
engineering. I'm not sure the undergraduate level is a good time to
concentrate on it -- the Wang Institute required at least 2 years'
experience, and I think that was beneficial. But, as you'll probably
hear over and over if you continue reading this group, anyone entering
the field should be required to have some basic knowledge of the
engineering aspects of software product development. Sadly, as I
interview recent grads from excellent schools, I find this is rarely
the case.
- --Franklin
Some references:
The Mythical Man-Month, F. Brooks, Addison-Wesley 1975. (READ THIS
FIRST! It's fun.)
Software Engineering Concepts, R. Fairley, McGraw Hill 1985.
Software Engineering: A Practitioner's Approach, R. Pressman, McGraw
Hill 1987. (He says, "A set of techniques, collectively called
'software engineering,' has evolved...[to] deal with software as an
engineered product that requires planning, analysis, design,
implementation, testing, and maintenance.")
------------------------------
Date: 10 May 89 17:39:53 GMT
From: Stanley Todd Shebs <apple!shebs@bloom-beacon.mit.edu>
Organization: Apple Computer Inc, Cupertino, CA
Subject: Re: software engineers (U)
>I would consider 50K lines to be a (very) small part of a big software systen
>or project. (No smiley). If one person cannot totally comprehand a small program
>like that, either the person or the method ought to be examined carefully.
50K lines *per person* is an approximation I picked based on observations
in several different industries over the past few years. I'm assuming
relatively sparse commentary, as seems to be the norm (sigh) - heavily
commented code might be 2-3 times longer. Note also, "total comprehension"
is pretty extreme. It means for instance that somebody could pick any single
line and you would be able to justify its existence, explain why alternatives
were not used, mention how it relates to the specification, and comment on
the consequences of changing it in various ways. Total comprehension is
actually somewhat rare, since it is possible to write and even debug software
without understanding it completely.
Incidentally, the "50K lines == small" statement is a familiar one, but I've
not seen any reliable and up-to-date statistics on program sizes. Is there
a believable chart anywhere of sizes, numbers, and the numbers of people
involved?
>In big systems, even in small 50KLOC programs, it is important to partition the
>program into understandable chunks. S/W people call this module interface. The
>civil/mechanical engineers call this "specification".
Only amateur programmers and researchers work without specifications these
days. The issues revolve around how formal the specifications can be.
Informal specifications seem to cause as much difficulty as they resolve,
while formal specifications are fantastically hard to get right.
>May be the answer is a mandotary course in "standard writing" for all
>software enginees.
Undergraduate software engineering classes feature the writing of interface
specs, but the environment is too artificial to get students to feel a
realistic level of pain at having to conform to a bad specification.
Classes can't always substitute for experience...
>[...] I like
>to think that some, if not most, software projects are run better than you
>make it out to be. If the situation is indeed as bleak as you say, then I
>would worry about the future of S/W, especially in the USA or North America.
I always have an eye out for the well-run software project, but a little
digging generally reveals that much of the proper methodology is window
dressing, concealing the programmers-who-despise-software-engineers who are
cranking out miles of code. I've been observing this ever since my first
software job, which involved writing documentation for an entirely
comment-free Fortran program, to make it appear as if it had been constructed
according to the DoD's standards for delivered software...
stan shebs
shebs@apple.com
(What about Apple? Well, I'll have to dig around and get back to y'all on
Apple's software engineering standards)
------------------------------
Date: 10 May 89 15:10:29 GMT
From: Piet van Oostrum <mcvax!hp4nl!ruuinf!piet@uunet.uu.net>
Organization: Dept of Computer Science, University of Utrecht, Holland
Subject: Re: software engineers (U)
>> >Have you ever seen a civil engineer debugging a bridge after it has been built?
>>
>
>Sure. the brand new bridge in St. Paul MN over the Mississippi just
>buckled. The temporary solution was to put a bunch of concrete barriers on
>the bridge to push the buckled part back in line. Permanent solution is
>now being worked on.
Some time ago there was a CACM article about the design of bridges (CACM
April 1986). It mentioned a few cases of bridges that collapsed during or
shortly after the construction.
------------------------------
Date: 9 May 89 19:19:12 GMT
From: Tony Voss <mcvax!ukc!stl!stc!praxis!hilbert!tv@uunet.uu.net>
Organization: Praxis Systems plc, Bath, UK
Subject: US Federal Software Projects - request for reference (U)
There are some figures in popular circulation in the UK reportedly
originating from the US GAO concerning a survey of 'some US Federal
Software Projects'. These figures (at least the version I have) claim
to show that, of the projects surveyed:
47% $3.2M delivered but were never used
29% $2.0M were paid for but never delivered
19% $1.3M had to be abandoned or reworked
3% $0.2M were used after change
<2% $0.1M were used as delivered
This is startling stuff, and excellent to drive home the need to
improve things. But no one I know has been able to attribute the
figures to a source I would trust. Everyone got them from somewhere
else.
Please can anyone give me a source?
------------------------------
Date: 11 May 89 04:19:54 GMT
From: Stanley Chow <mailrus!jarvis.csri.toronto.edu!utgpu!bnr-vpa!bnr-fos!leibniz!schow@purdue.edu>
Organization: Bell-Northern Research, Ottawa, Canada
Subject: Component Specification (Was Re: software engineers) (U)
Since we are starting to talk about components, I have added comp.sw.components.
>>In big systems, even in small 50KLOC programs, it is important to partition the
>>program into understandable chunks. S/W people call this module interface. The
>>civil/mechanical engineers call this "specification".
>
>Only amateur programmers and researchers work without specifications these
>days. The issues revolve around how formal the specifications can be.
>Informal specifications seem to cause as much difficulty as they resolve,
>while formal specifications are fantastically hard to get right.
>
>>May be the answer is a mandotary course in "standard writing" for all
>>software enginees.
>
>Undergraduate software engineering classes feature the writing of interface
>specs, but the environment is too artificial to get students to feel a
>realistic level of pain at having to conform to a bad specification.
>Classes can't always substitute for experience...
>
What I had in mind is the amount of details in the specification.
Most standards written by traditional engineers, be it mechanical, electrical
or whatever, tend to be a good deal more detailed than software specs. May be
the Mil. Spec. methods of software development are better but I doubt it. The
only really complete documentation I have seen are IBM manuals. They are long
and boring, but they are *complete*.
Modularity and software reuse requires a very high level of documentation. An
example is the simple IC. A couple of articles in comp.sw.components recently
talked about "software IC". Consider the simplest of IC's, say a 5400 -- quad
nand-gate. The documentation goes for several pages:
- logic function table,
- the standard logic symbol,
- the boolean equation,
- pinout information for each possible package,
- the equivalent schematics,
- the absolute maximum ratings (complete with ambient conditions),
- the recommanded operating conditions (with min, max & nominal)
- complete characterization (with conditions, min, max, ..)
Note that the concept of a "nand gate" is captured and encapsulated. It just
requires a lot of details to describe the encapsulated module! With this level
of information, I can design an IC into a circuit and know what it is doing,
what is the operating envelope, and complain to the manufacturer if the IC
does not meet spec.
Most (if not all) hardware type know just about all of this information since
a lot of it is standard across parts in the same family and across families.
The information is repeated anyway becuase it is part of the specification.
How many times have you seen *any* software documentation that comes close to
this level of information?
Some people may say, but the hardware guys are selling IC into a commodity
market so they *have* to characterize their parts. This is true to a certain
extent. But the companies that sell, say, compilers, would seems to fit
that description as well, but have you seen a compiler (or even "make")
described in detail?
Other people may say, but software is more complex. Firstly, there are some
really complicated hardware, take a look at some of the monster chips. Even
very complicated hardware is documented in detail. Secondly, there are some
very simple software. Even very simple software is not well documented.
It appears to me to be a matter of expectation. Hardware types won't even
think about using a part unless the specs are there. Software types don't care.
This may have something to do with specialization: there are IC vs PCB
designers, analog vs digital designers, micro-wave vs RF designers, etc.
Many software people seem to think they can do it all (this probably applies
to me as well, but in my case, i *can* do everything! :-).
Another aspect is knowledge. Hardware people have been burnt enough times
that they put the knowledge into specifications. Software people are still
arguing about what are problems, what is good and what is bad.
Hmm, this is getting pretty long. I better stop rambling before everyone
thinks I am bashing software or s/w engineering.
------------------------------
Date: 11 May 89 12:24:21 GMT
From: Scott Duncan <dduck!duncan@bellcore.bellcore.com>
Subject: Re: US Federal Software Projects - request for reference (U)
[Asking about a source for the following figures about government projects
surveyed by the GAO.]
>47% $3.2M delivered but were never used
>29% $2.0M were paid for but never delivered
>19% $1.3M had to be abandoned or reworked
>3% $0.2M were used after change
><2% $0.1M were used as delivered
The source I was given -- recently at the Emprirical Studies of Programmers
Workshop in Austin just prior to SIGCHI -- was ACM's SIGSOFT Notes (Oct. '85).
But it was pointed out that these projects were ones already considered to be
in trouble (for what reasons I do not know). I have not yet read the article
to know what detail it provides, however.
------------------------------
Date: 11 May 89 11:49:52 GMT
From: Rick Butland <haven!vrdxhq!daitc!viusys!rwb@purdue.edu>
Organization: Unisys D.A. MINIS Branch, McLean, VA
Subject: Re: need help choosing between INGRESS and PROGRESS (U)
[ I tried to mail this, but my mailer puked on your address ]
I really don't have any experience with development using either package.
>From what I've seen, I like both packages' development tools.
I just wanted to relate to you some problems I encountered with Progress
while benchmarking it. I think that Progress has some real problems
dealing with a multi-user environment. Performance, particularly on a
multi-processor machine, was poor. The primary limitations I found were:
(Disclaimer: These observations are based on an older release of Progress,
(3?), and may no longer apply.)
o Single-server architecture. In a multi-user environment, a database
server is started to service requests to access the database. This, to me,
is a Bad Thing. As the number of users began to rise, the server quickly
became overwhelmed, due to the fact that it takes on the responsibility for
everything, from writing the before-image file, reading/writing the database,
parsing messages, servicing the message queues, managing data buffers, etc.
As evidence of this, the benchmark I ran took a single user 8 seconds to
complete. At 64 copies of the same program, with simultaneous starts,
the end-to-end time was around 1 hour 5 minutes. This was a multi-processor
machine, (a three CPU Arix), however, after a period of time, the only
process eligible to run was the server, leaving the other two CPU's nearly
unused.
o The handling of data buffers, (which are located in the dataspace of the
server), was poor. Buffer lookup was obviously linear, rather than hashed,
thus contributing to the degradation problems. Caveat: Version 4 of
Progress was to fix this.
o Before-image handling - The problem here was that everytime you accessed
the database, a copy of the accessed page was written to the before-image file.
Unfortunately, it was always appended to the end of the file, and would not
reclaim unused space. The file just continued to grow and grow, and at one
point, with a 100k database, I had a 11 MB before-image file. The problems
of file system indirection really took a toll. Caveat: in version 4, the
developers told me that they were going to build in a mechanism that would
rewind this file, when there was no activity on the database, whereas the
version I saw required a shutdown before this would occur.
o No support for raw devices - They claim some form of raw i/o (on a
filesystem??), but all that I saw were synchronous writes.
They claim short development times with their 4GL, and I'd believe them,
it really does look pretty good, kinda Dbase-like. Perhaps FoxBase might
be something to look into?
Anyway, I think it's probably an ok product, and the 4GL is really nice, but
be sure, if you're on a Unix system, with multiple users of the same
database, that your application will perform adequately.
I've only seen Ingres demo'd, so I can't speak to that product.
Rick Butland
(rwb@viusys)
Disclaimer: My dog won't let me speak for him, much less my employer.
------------------------------
Date: 11 May 89 16:20:36 GMT
From: Steve Goldfield <steve@violet.berkeley.edu>
Organization: University of California, Berkeley
Subject: Re: need help choosing between INGRESS and PROGRESS (U)
I haven't used PROGRESS, but I can confirm the weakness
of Ingres' report writer.
First of all, it is limited to a single retrieve, so if
you need to report information from more than one table
(as you do in any well-designed relational database), you
have to first do a retrieve outside the report into a table
just for the report. (Example: You have names in one
table, addresses in a second, and phone numbers in a third.
You have to combine these into a single table prior to
running a report on that table.)
Second, there are no flags or, more generally, user-controlled
variables to control flow in the report. (Example: you want
something to happen only on page one, like suppressing a
page number in the footer.) The only thing like a variable
is information read in at run time from a terminal.
Third, you can count or compute other aggregations, but you can
only count everything inside a report. You can't count on a where
condition. (Example: I wanted to report all employees of a
company in our database and count the number of those who
were alumni of this institution. I couldn't do it in the
report. I had to do it in quel.)
These are just the most annoying weaknesses that leap immediately
to mind. Naturally, you could overcome all of them by writing
a report in C. What really gets me going is that all of the above
facilities and more were available in dBASE II on my Kaypro 2.
------------------------------
Date: 11 May 89 15:15:08 GMT
From: Kathy Iberle <hp-pcd!hpmcaa!kathyi@hplabs.hp.com>
Organization: HP McMinville Division
Subject: Re: What exactly is a software engineer ? (U)
Being new to this string, I'm a bit puzzled. In my (possibly outdated)
experience, "programmer" usually refers to someone who has 2 years
education (an associate's degree) and whose job is defined as
implementing the detailed design done by a systems analyst. I believed
this to be true in the DP world. In the engineering or technical
programming world, it seemed that either you had junior engineers/
senior engineers (any of whom might or might not have an engineering
degree in any engineering discipline), or you had jack-of-all-trades
who do design, implementation, and testing. The jack-of-all-trades
requires at least a BS (but not necessarily in CS) and often is called
"software engineer" to distinguish him/her from the "programmer".
Of course, this view was formed before most software engineering programs
were in existence. I still have not met anyone who has actually graduated
from one, though I have certainly learned much of the subject matter out
of necessity.
So, am I outdated? Would you refer to yourself as a "programmer" on a
resume?
------------------------------
End of Software Engineering Digest
**********************************soft-eng@MITRE.MITRE.ORG (Alok Nigam) (07/22/89)
Software Engineering Digest Sunday, 18 Jun 1989
Volume 6 : Issue 23
Today's Topics:
Importance of domain knowledge
Two Questions about Ready Systems' CARDtools (U)
need help choosing between INGRESS and PROGRESS (U)
Re: software engineers (U)
Re: What exactly is a software engineer ? (U)
Re: software engineers (U) 2
US Federal Software Projects - request for reference (U)
Component Specification (Was Re: software engineers) (U)
Re: US Federal Software Projects - request for reference (U)
Re: need help choosing between INGRESS and PROGRESS (U) (2)
Re: What exactly is a software engineer ? (U)
------------------------------------------------------------
Date: Wed, 10 May 1989 22:57:25 EDT
From: "James H. Coombs" <JAZBO@BROWNVM.BITNET>
Subject: Importance of domain knowledge
>I've heard it said that the best predictor of eventual success in building a
>large system is domain knowledge on the part of the designer, i.e. tax
>preparation software is best designed by someone who knows tax preapration
>well rather than someone who knows, say, human-interface design well.
Domain knowledge is stressed in only one of the four "archetypal perspectives
on the use of computers" discussed by John Kammersgaard in "Four Different
Perspectives on Human-Computer Interaction", International Journal of Man
Machine Studies, 28 (1988), 343-62.
Kammersgaard discusses the systems perspective, the dialogue partner
perspective, the tool perspective, and the media pespective. The article is
not as clear as I would like in some of its attempts at characterizing and
distinguishing the perspectives, and the reader must do some significant work
to put it all together. I read the article less than an hour ago, and I am
impressed by it enough to commit the perspectives to memory (or my
understanding of them at least) and to attempt to apply them in my work.
K's conclusion? Dialogue partner perspective (typical of AI and natural
lang.; argued against by Winograd and Flores) is not very promising.
Otherwise, the "message is not that one perspective is the right one; not even
that a single one of them is best suited to understand the use of a given
application. The point is rather that, by shifting between some or all of the
described perspectives, it becomes possible to gain a better understanding
when designing and using a particular computer application."
Oh, yes, domain knowledge is stressed in the tools perspective, which is
closely associated with analogic metaphors, such as the desktop of Xerox Star
and successor Macintosh.
------------------------------
Date: 22 Jul 89 17:46:16 GMT
From: Rick Low <mitel!melair!low@uunet.uu.net>
Organization: MEL Defence Systems Ltd., Ottawa, Canada
Subject: Two Questions about Ready Systems' CARDtools (U)
It seems that Ready Systems' CARDtools has become the de facto
standard CASE tool for real-time embedded system and software design
at my company. I have two questions for anyone who has used this package:
1. What design method does it support?
Possible answers I've come up with are
a) Hatley, sort of
b) Ward-Mellor, sort of
c) Ready Systems' own
d) anyone/everyone's (it's just a tool box)
TFM doesn't say what method is supported; neither does is have
any references listed that would give it away. When I read TFMs
I get the feeling that the answer is d), but this is never stated.
When I ask people here what method they use with CARDtools they say,
"Well, just CARDtools, right?" A recent article in Computer Design
magazine just said CARDtools supports Ward-Mellor, without really
saying how.
2. (really a general CASE question) Is there any size of project for
which use of tools like CARDtools is uneconomical?
Followups to comp.realtime please.
------------------------------
Date: 22 Jul 89 14:11:04 GMT
From: Bryan Beck <mstar!resource!bryan@ohio-state.arpa>
Organization: Resource Systems
Subject: need help choosing between INGRESS and PROGRESS (U)
I am in the process of making a DBMS selection, and I have narrowed my
choice down to INGRESS and PROGRESS.
I have found that both are quality packages and capable of handleing the
job. The only negative comment I have received is concerning INGRESS's
query/report generation capabilities.
Does any one have experience with both packages or qualified to compare
and contrast the two. Also I haven't heard anything negative about progress,
has any one had any complaints??
Any revelant comments that could help me make my decision would be
greatly appreciated.
------------------------------
Date: 22 Jul 89 04:05:06 GMT
From: Stanley Chow <jarvis.csri.toronto.edu!utgpu!bnr-vpa!bnr-fos!leibniz!schow@rutgers.edu>
Organization: Bell-Northern Research, Ottawa, Canada
Subject: Re: software engineers (U)
>Comparing numbers of people or pounds of documentation is not necessarily
>valid. My personal impression from working alongside assorted engineers
>is that individuals tend to be more specialized in the traditional engineering
>disciplines. [...]
Perhaps this is why engineer build bridges that work better than most
programs! There may be a lession for budding software engineers.
> [...] So for instance you might have somebody on a project that is
>concerned only with bolts, or electrical connectors, or maybe even with only
>a single oddly-shaped part made by a subcontractor. Many (most?) software
>people are in the opposite situation - they have to be concerned about all
>aspects of a 50K line program, and they rarely have the leisure to really
>understand the code proper, the design, the limitations, the consequences
>for other parts of a system, and so forth. [...]
I would consider 50K lines to be a (very) small part of a big software systen
or project. (No smiley). If one person cannot totally comprehand a small program
like that, either the person or the method ought to be examined carefully.
As I understand "software engineering", a good part of the effort is devoted to
making systems modular and understandable. One may disagree with the specific
approach - Ada, Modula-2, C++, etc., but the aim is valid.
In big systems, even in small 50KLOC programs, it is important to partition the
program into understandable chunks. S/W people call this module interface. The
civil/mechanical engineers call this "specification". It would be nice if the
mechanical engineer understood how stainless steel is made and what interesting
reactions corode different steel, but it is not necessary to build a bridge.
There are standards that gurantee N years of corodesion resistance as long as
the exposure to corosive chemicals are within certain specific limits.
The S/W analogy is like the mathmatics libraries. If you call this matrix
inversion routine, you will get back a good inverse as long as the input matrix
is not singular, etc.
May be the answer is a mandotary course in "standard writing" for all
software enginees.
As someone said, "Software will be a science when programmers stand on each
other's shoulders instead of each other's toes." [I would be grateful if
someone can point to the originator of this]
> [...] Just imagine how different things
>would be if you only had to be responsible for, say, 1,000 lines of code and
>could spend a year working on it. You spend time analyzing it in depth, you
>could polish the documentation, you could tune it for optimum performance.
>Unfortunately such a situation is rarely possible in today's environment...
>
Aside from a quibble with your scale, I agree with your goal. However, I like
to think that some, if not most, software projects are run better than you
make it out to be. If the situation is indeed as bleak as you say, then I
would worry about the future of S/W, especially in the USA or North America.
>Getting back to comparing bridges and programs, a more valid method might be
>to compare the information content of a program to that of a bridge (more
>accurately, to the size of its description). This would factor out sheer
>volume; 10,000 identical bolts aren't much more interesting than one bolt,
>ditto for code that is replicated in different parts of a program. Seems
>like at least one theorist would have looked at this in the past...
This is a subject that has interested me over the years. Let's say I make
a copy of a matrix addition routine, change it to do subtraction, how much
information have I added? What metrics can we use? Is it possible to determine
which programs are copies of each other?
------------------------------
Date: 22 Jul 89 22:53:55 GMT
From: Franklin A Davis <fad@think.com>
Organization: Thinking Machines Corporation
Subject: Re: What exactly is a software engineer ? (U)
> I am a student... I read that soft-
>ware engineering as a sub-discipline under computer science; but
>I also read in an another news group that software engineers
>were considered actual engineers (like AE,EE,ME ....).
>What are the actual degree requirements of software engineers and also
>what are their job definitions ?
I'll quote a definition by Richard Fairley from "Software Engineering
Concepts:"
Software engineering is the technological and managerial
discipline concerned with systematic production and maintenance of
software products that are developed and modified on time and within
cost estimates.
Dr. Fairley was a professor of mine and chairman of the faculty at the
late Wang Institute of Graduate Studies when I studied for my Masters
of Software Engineering. He's now head of the MSE program at George
Mason University.
Having studied (and argued about) the details of SE for a year in
school, and then working for nearly two, I feel I am just beginning to
become a good engineer. In my five years of work before my graduate
studies I think I was more a programmer than a true engineer.
Almost everyone who programs computers for a living is now referred to
as a "software engineer." I applaud the goal of having all programmers
practice real engineering, but I'm afraid the use of "software
engineer" as a job title is often inflated. Since there are only a
few schools in the world so far that grant degrees in software
engineering it would be impractical to have specific SE degree
requirements for jobs. Fortunately the real world is often a good
teacher, so people with CS degrees (or no degree at all) become
proficient engineers with experience.
My own working definition is that a software engineer is knowledgable
and disciplined about all the tasks involved in creating a *finished
product*, including specification, planning, design, writing test
plans, coding, debugging, testing, documenting, and maintaining. The
actual effort in writing code that just "works" is a small fraction of
the total.
Few CS departments devote more than a semester (if that!) to software
engineering. I'm not sure the undergraduate level is a good time to
concentrate on it -- the Wang Institute required at least 2 years'
experience, and I think that was beneficial. But, as you'll probably
hear over and over if you continue reading this group, anyone entering
the field should be required to have some basic knowledge of the
engineering aspects of software product development. Sadly, as I
interview recent grads from excellent schools, I find this is rarely
the case.
- --Franklin
Some references:
The Mythical Man-Month, F. Brooks, Addison-Wesley 1975. (READ THIS
FIRST! It's fun.)
Software Engineering Concepts, R. Fairley, McGraw Hill 1985.
Software Engineering: A Practitioner's Approach, R. Pressman, McGraw
Hill 1987. (He says, "A set of techniques, collectively called
'software engineering,' has evolved...[to] deal with software as an
engineered product that requires planning, analysis, design,
implementation, testing, and maintenance.")
------------------------------
Date: 22 Jul 89 17:39:53 GMT
From: Stanley Todd Shebs <apple!shebs@bloom-beacon.mit.edu>
Organization: Apple Computer Inc, Cupertino, CA
Subject: Re: software engineers (U)
>I would consider 50K lines to be a (very) small part of a big software systen
>or project. (No smiley). If one person cannot totally comprehand a small program
>like that, either the person or the method ought to be examined carefully.
50K lines *per person* is an approximation I picked based on observations
in several different industries over the past few years. I'm assuming
relatively sparse commentary, as seems to be the norm (sigh) - heavily
commented code might be 2-3 times longer. Note also, "total comprehension"
is pretty extreme. It means for instance that somebody could pick any single
line and you would be able to justify its existence, explain why alternatives
were not used, mention how it relates to the specification, and comment on
the consequences of changing it in various ways. Total comprehension is
actually somewhat rare, since it is possible to write and even debug software
without understanding it completely.
Incidentally, the "50K lines == small" statement is a familiar one, but I've
not seen any reliable and up-to-date statistics on program sizes. Is there
a believable chart anywhere of sizes, numbers, and the numbers of people
involved?
>In big systems, even in small 50KLOC programs, it is important to partition the
>program into understandable chunks. S/W people call this module interface. The
>civil/mechanical engineers call this "specification".
Only amateur programmers and researchers work without specifications these
days. The issues revolve around how formal the specifications can be.
Informal specifications seem to cause as much difficulty as they resolve,
while formal specifications are fantastically hard to get right.
>May be the answer is a mandotary course in "standard writing" for all
>software enginees.
Undergraduate software engineering classes feature the writing of interface
specs, but the environment is too artificial to get students to feel a
realistic level of pain at having to conform to a bad specification.
Classes can't always substitute for experience...
>[...] I like
>to think that some, if not most, software projects are run better than you
>make it out to be. If the situation is indeed as bleak as you say, then I
>would worry about the future of S/W, especially in the USA or North America.
I always have an eye out for the well-run software project, but a little
digging generally reveals that much of the proper methodology is window
dressing, concealing the programmers-who-despise-software-engineers who are
cranking out miles of code. I've been observing this ever since my first
software job, which involved writing documentation for an entirely
comment-free Fortran program, to make it appear as if it had been constructed
according to the DoD's standards for delivered software...
stan shebs
shebs@apple.com
(What about Apple? Well, I'll have to dig around and get back to y'all on
Apple's software engineering standards)
------------------------------
Date: 22 Jul 89 15:10:29 GMT
From: Piet van Oostrum <mcvax!hp4nl!ruuinf!piet@uunet.uu.net>
Organization: Dept of Computer Science, University of Utrecht, Holland
Subject: Re: software engineers (U)
>> >Have you ever seen a civil engineer debugging a bridge after it has been built?
>>
>
>Sure. the brand new bridge in St. Paul MN over the Mississippi just
>buckled. The temporary solution was to put a bunch of concrete barriers on
>the bridge to push the buckled part back in line. Permanent solution is
>now being worked on.
Some time ago there was a CACM article about the design of bridges (CACM
April 1986). It mentioned a few cases of bridges that collapsed during or
shortly after the construction.
------------------------------
Date: 22 Jul 89 19:19:12 GMT
From: Tony Voss <mcvax!ukc!stl!stc!praxis!hilbert!tv@uunet.uu.net>
Organization: Praxis Systems plc, Bath, UK
Subject: US Federal Software Projects - request for reference (U)
There are some figures in popular circulation in the UK reportedly
originating from the US GAO concerning a survey of 'some US Federal
Software Projects'. These figures (at least the version I have) claim
to show that, of the projects surveyed:
47% $3.2M delivered but were never used
29% $2.0M were paid for but never delivered
19% $1.3M had to be abandoned or reworked
3% $0.2M were used after change
<2% $0.1M were used as delivered
This is startling stuff, and excellent to drive home the need to
improve things. But no one I know has been able to attribute the
figures to a source I would trust. Everyone got them from somewhere
else.
Please can anyone give me a source?
------------------------------
Date: 22 Jul 89 04:19:54 GMT
From: Stanley Chow <mailrus!jarvis.csri.toronto.edu!utgpu!bnr-vpa!bnr-fos!leibniz!schow@purdue.edu>
Organization: Bell-Northern Research, Ottawa, Canada
Subject: Component Specification (Was Re: software engineers) (U)
Since we are starting to talk about components, I have added comp.sw.components.
>>In big systems, even in small 50KLOC programs, it is important to partition the
>>program into understandable chunks. S/W people call this module interface. The
>>civil/mechanical engineers call this "specification".
>
>Only amateur programmers and researchers work without specifications these
>days. The issues revolve around how formal the specifications can be.
>Informal specifications seem to cause as much difficulty as they resolve,
>while formal specifications are fantastically hard to get right.
>
>>May be the answer is a mandotary course in "standard writing" for all
>>software enginees.
>
>Undergraduate software engineering classes feature the writing of interface
>specs, but the environment is too artificial to get students to feel a
>realistic level of pain at having to conform to a bad specification.
>Classes can't always substitute for experience...
>
What I had in mind is the amount of details in the specification.
Most standards written by traditional engineers, be it mechanical, electrical
or whatever, tend to be a good deal more detailed than software specs. May be
the Mil. Spec. methods of software development are better but I doubt it. The
only really complete documentation I have seen are IBM manuals. They are long
and boring, but they are *complete*.
Modularity and software reuse requires a very high level of documentation. An
example is the simple IC. A couple of articles in comp.sw.components recently
talked about "software IC". Consider the simplest of IC's, say a 5400 -- quad
nand-gate. The documentation goes for several pages:
- logic function table,
- the standard logic symbol,
- the boolean equation,
- pinout information for each possible package,
- the equivalent schematics,
- the absolute maximum ratings (complete with ambient conditions),
- the recommanded operating conditions (with min, max & nominal)
- complete characterization (with conditions, min, max, ..)
Note that the concept of a "nand gate" is captured and encapsulated. It just
requires a lot of details to describe the encapsulated module! With this level
of information, I can design an IC into a circuit and know what it is doing,
what is the operating envelope, and complain to the manufacturer if the IC
does not meet spec.
Most (if not all) hardware type know just about all of this information since
a lot of it is standard across parts in the same family and across families.
The information is repeated anyway becuase it is part of the specification.
How many times have you seen *any* software documentation that comes close to
this level of information?
Some people may say, but the hardware guys are selling IC into a commodity
market so they *have* to characterize their parts. This is true to a certain
extent. But the companies that sell, say, compilers, would seems to fit
that description as well, but have you seen a compiler (or even "make")
described in detail?
Other people may say, but software is more complex. Firstly, there are some
really complicated hardware, take a look at some of the monster chips. Even
very complicated hardware is documented in detail. Secondly, there are some
very simple software. Even very simple software is not well documented.
It appears to me to be a matter of expectation. Hardware types won't even
think about using a part unless the specs are there. Software types don't care.
This may have something to do with specialization: there are IC vs PCB
designers, analog vs digital designers, micro-wave vs RF designers, etc.
Many software people seem to think they can do it all (this probably applies
to me as well, but in my case, i *can* do everything! :-).
Another aspect is knowledge. Hardware people have been burnt enough times
that they put the knowledge into specifications. Software people are still
arguing about what are problems, what is good and what is bad.
Hmm, this is getting pretty long. I better stop rambling before everyone
thinks I am bashing software or s/w engineering.
------------------------------
Date: 22 Jul 89 12:24:21 GMT
From: Scott Duncan <dduck!duncan@bellcore.bellcore.com>
Subject: Re: US Federal Software Projects - request for reference (U)
[Asking about a source for the following figures about government projects
surveyed by the GAO.]
>47% $3.2M delivered but were never used
>29% $2.0M were paid for but never delivered
>19% $1.3M had to be abandoned or reworked
>3% $0.2M were used after change
><2% $0.1M were used as delivered
The source I was given -- recently at the Emprirical Studies of Programmers
Workshop in Austin just prior to SIGCHI -- was ACM's SIGSOFT Notes (Oct. '85).
But it was pointed out that these projects were ones already considered to be
in trouble (for what reasons I do not know). I have not yet read the article
to know what detail it provides, however.
------------------------------
Date: 22 Jul 89 11:49:52 GMT
From: Rick Butland <haven!vrdxhq!daitc!viusys!rwb@purdue.edu>
Organization: Unisys D.A. MINIS Branch, McLean, VA
Subject: Re: need help choosing between INGRESS and PROGRESS (U)
[ I tried to mail this, but my mailer puked on your address ]
I really don't have any experience with development using either package.
>From what I've seen, I like both packages' development tools.
I just wanted to relate to you some problems I encountered with Progress
while benchmarking it. I think that Progress has some real problems
dealing with a multi-user environment. Performance, particularly on a
multi-processor machine, was poor. The primary limitations I found were:
(Disclaimer: These observations are based on an older release of Progress,
(3?), and may no longer apply.)
o Single-server architecture. In a multi-user environment, a database
server is started to service requests to access the database. This, to me,
is a Bad Thing. As the number of users began to rise, the server quickly
became overwhelmed, due to the fact that it takes on the responsibility for
everything, from writing the before-image file, reading/writing the database,
parsing messages, servicing the message queues, managing data buffers, etc.
As evidence of this, the benchmark I ran took a single user 8 seconds to
complete. At 64 copies of the same program, with simultaneous starts,
the end-to-end time was around 1 hour 5 minutes. This was a multi-processor
machine, (a three CPU Arix), however, after a period of time, the only
process eligible to run was the server, leaving the other two CPU's nearly
unused.
o The handling of data buffers, (which are located in the dataspace of the
server), was poor. Buffer lookup was obviously linear, rather than hashed,
thus contributing to the degradation problems. Caveat: Version 4 of
Progress was to fix this.
o Before-image handling - The problem here was that everytime you accessed
the database, a copy of the accessed page was written to the before-image file.
Unfortunately, it was always appended to the end of the file, and would not
reclaim unused space. The file just continued to grow and grow, and at one
point, with a 100k database, I had a 11 MB before-image file. The problems
of file system indirection really took a toll. Caveat: in version 4, the
developers told me that they were going to build in a mechanism that would
rewind this file, when there was no activity on the database, whereas the
version I saw required a shutdown before this would occur.
o No support for raw devices - They claim some form of raw i/o (on a
filesystem??), but all that I saw were synchronous writes.
They claim short development times with their 4GL, and I'd believe them,
it really does look pretty good, kinda Dbase-like. Perhaps FoxBase might
be something to look into?
Anyway, I think it's probably an ok product, and the 4GL is really nice, but
be sure, if you're on a Unix system, with multiple users of the same
database, that your application will perform adequately.
I've only seen Ingres demo'd, so I can't speak to that product.
Rick Butland
(rwb@viusys)
Disclaimer: My dog won't let me speak for him, much less my employer.
------------------------------
Date: 22 Jul 89 16:20:36 GMT
From: Steve Goldfield <steve@violet.berkeley.edu>
Organization: University of California, Berkeley
Subject: Re: need help choosing between INGRESS and PROGRESS (U)
I haven't used PROGRESS, but I can confirm the weakness
of Ingres' report writer.
First of all, it is limited to a single retrieve, so if
you need to report information from more than one table
(as you do in any well-designed relational database), you
have to first do a retrieve outside the report into a table
just for the report. (Example: You have names in one
table, addresses in a second, and phone numbers in a third.
You have to combine these into a single table prior to
running a report on that table.)
Second, there are no flags or, more generally, user-controlled
variables to control flow in the report. (Example: you want
something to happen only on page one, like suppressing a
page number in the footer.) The only thing like a variable
is information read in at run time from a terminal.
Third, you can count or compute other aggregations, but you can
only count everything inside a report. You can't count on a where
condition. (Example: I wanted to report all employees of a
company in our database and count the number of those who
were alumni of this institution. I couldn't do it in the
report. I had to do it in quel.)
These are just the most annoying weaknesses that leap immediately
to mind. Naturally, you could overcome all of them by writing
a report in C. What really gets me going is that all of the above
facilities and more were available in dBASE II on my Kaypro 2.
------------------------------
Date: 22 Jul 89 15:15:08 GMT
From: Kathy Iberle <hp-pcd!hpmcaa!kathyi@hplabs.hp.com>
Organization: HP McMinville Division
Subject: Re: What exactly is a software engineer ? (U)
Being new to this string, I'm a bit puzzled. In my (possibly outdated)
experience, "programmer" usually refers to someone who has 2 years
education (an associate's degree) and whose job is defined as
implementing the detailed design done by a systems analyst. I believed
this to be true in the DP world. In the engineering or technical
programming world, it seemed that either you had junior engineers/
senior engineers (any of whom might or might not have an engineering
degree in any engineering discipline), or you had jack-of-all-trades
who do design, implementation, and testing. The jack-of-all-trades
requires at least a BS (but not necessarily in CS) and often is called
"software engineer" to distinguish him/her from the "programmer".
Of course, this view was formed before most software engineering programs
were in existence. I still have not met anyone who has actually graduated
from one, though I have certainly learned much of the subject matter out
of necessity.
So, am I outdated? Would you refer to yourself as a "programmer" on a
resume?
------------------------------
End of Software Engineering Digest
***********************