--::::::::::
--asr202.doc
--::::::::::




 
 





                               ADA SOFTWARE REPOSITORY (ASR) NEWSLETTER
                                                   
                                     ISSUE 202, November 7, 1989





                                              Edited by______ __
                                             Richard Conn
                                   Manager, Ada Software Repository
                                                   
                                             Published by_________ __
                      Management Assistance Corporation of America, Inc. (MACA)
                                    PO Drawer 100 - Building T148
                             White Sands Missile Range, New Mexico  88002
                                             505/678-3288





                                               Sponsor_______
                           The Ada Software Repository and this Newsletter
                                           are sponsored by
                                   The STARS Joint Program Office,
                              Defense Advanced Research Projects Agency
                                                 and
                               The US Army Information Systems Command,
                                      White Sands Missile Range












                                              Disclaimer__________

            Statements  made in this newsletter are the opinions of the individuals making
            them  and  are  not  necessarily  the  opinions or policy statements of the US
            Government or any other organization.


 
 




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                                             1. Articles

                 The  first  seven articles in this section continue a discussion from the
            last  newsletter  on the topics of software quality and the impact of creating
            quality  software within schedule and budget constraints.  These articles were
            extracted  from  the  SW-COMP  electronic mailing list.  The last articles, on
            computer  viruses,  popular files in the ASR, and the SW-COMP and USENET feed,
            are ASR-specific.

            1.1.  Schedule________ and___ budget______ are___ secondary_________


            1.1.1.  From____ Dick____ Dunn____

            Date: 10 Oct 89 23:25:21 GMT
            From: ico!vail!rcd@handies.ucar.edu  (Dick Dunn)
                 billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu  (William  Thomas Wolfe,
            2847 ) writes:
            > >>    ...We're here to engineer products on time, under budget,
            > >>    and with as much quality as we can get within those two constraints.
            > > ...It's particularly
            > > sad to see "quality" a poor third to the other two.
            >    If the product does not meet the minimal standards of acceptability,
            >    then it is not complete.  "On time", etc., refers to the product
            >    being completed in accordance with the relevant quality requirements.
                 "Quality"  software  is  MUCH more than software which meets "the minimal
            standards of acceptability", thank you.
                 A  piece  of  software may be judged to have been "completed" on time and
            within  budget  if  it meets its stated requirements within those constraints.
            The  requirements  are  going  to  be  objective  criteria--such  as tasks the
            software  must  perform,  performance  and  size  limits,  etc.   They MUST be
            objective  criteria  in the (very common) case where the requirements are part
            of the negotiated contract for the software project.
                 It  is  entirely  possible  to  construct  software  which meets all such
            requirements,  but which is poorly conceived or implemented.  Examples abound.
            I  know  of  no  way to specify software requirements such as "must be able to
            survive  the next five years of changes, to meet new needs, hacked in by bored
            second-string  maintenance  programmers..."  But  that's  often  what  quality
            software needs.
                 Sometimes  software doesn't need high quality--sometimes the minimal hack
            that meets the short-term requirements is enough! The "lowest bidder" approach
            is  OK  sometimes,  but  not  universally.   Most  software  far  outlives its
            originally  estimated/intended life.  It is more common to find ourselves with
            software  under-engineered  than  over-engineered.   My personal peeve here is
            that  I  spend  far  too much of my time reworking under-engineered hacks back
            into   decent   code  that  can  survive.   So  I  see  an  extreme  focus  on
            budget/schedule as needlessly increasing the amount of such work I have to do.






 
            1. Articles                                                         Page 202-1




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.2.  From____ Dick____ Dunn____

            Date: 10 Oct 89 23:52:32 GMT
            From: ico!vail!rcd@handies.ucar.edu  (Dick Dunn)
                 itkin@mrspoc.Transact.COM (Steven M.  List) writes:
            >...In reading what Dick said, I can only believe that he's never worked on
            > a project for which someone ELSE was paying.  Or a project for which the
            > market window is critical to the continued survival of the company or the
            > project or the product...
                 You  are  quite  wrong  on  both  counts.  I have worked on both for many
            years; currently most of my work falls into projects paid for by customers.  I
            think it's not that we are in any fundamental disagreement (we'll see) so much
            as that we're driving at different points.

            > Dick's statements strike me as somewhat ivory tower.  While those of us
            > who consider ourselves professionals in the field of "software engineering"
            > presumably ALWAYS strive for quality products, we can't just turn off our
            > systems and refuse if someone comes along and says "we have a deadline".
                 Understood  completely.  I'm NOT trying to put quality at the very top of
            the  list,  to  the  exclusion  of  schedule  and  budget...but  I want to get
            schedule/budget off the top of the list.
                 One  of  the  things we have to consider in bidding a software project is
            that we want to set a reasonable cost which will allow us to produce a product
            of  sufficient  quality  that  the  customer  is not only happy with it in the
            short-term  (meeting  the  immediate needs) but in the long term when it comes
            time to modify it.
                 If  it's our own product, we don't want to do a quick hack that will save
            us 10% on the first release and cost us 50% more in the second release when we
            have to repair the damage we did by hurrying.  Sometimes, market pressures are
            extreme enough that it's the only way to hit close enough to the market window
            that there can BE a second release--but we need to avoid that.

            >     "How much can I get in that meets MY/OUR/OUR CUSTOMER'S standards
            >     of quality within the time and budget constraints set forth?  Can
            >     we modify the constraints?  Are we willing to adjust our standards?"
                 This  is  a good statement.  The software MUST meet its requirements, but
            that's  a  separate issue.  We MUST schedule enough time and money to do that.
            Then we try to schedule enough to produce a product of sufficient quality that
            we won't hate ourselves for it later on.

            > Dick's statement that producing a schedule that meets a lower confidence
            > factor would permit a favorable decision is frightening to me.  This
            > implies that it's okay to plan based on 80% or 70% or lower confidence.
                 Sure--why  not? Wait, let me qualify that...There are circumstances where
            it's OK to work at that confidence level.  Just remember that nothing is black
            and  white  here.  Suppose we're talking about a product aimed at a particular
            market  window.   What's  the  accuracy  of the end date on the market window?
            Probably  50%  at  best!  (That is, the window is at least as likely as not to
            close  AFTER  the  estimated  end  date.)  Also,  the window doesn't just slam
            shut...it means that the longer you delay, the smaller your market share.  You
            have to work with the probabilities involved.  If there's a 70% chance you can
            make  the stated market window, you also need to know something like what your
            90%-confidence  completion  date is, and whether that might come in acceptably
 
            Page 202-2                                                 1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            close to the window that it will still give you a good product--enough to make
            some money even if not as much as you "should" make.
                 There  are literally SCORES of other factors to consider.  The better the
            condition  of  the  company, the more of a gamble you can afford to take.  You
            may  build  the  company's  reputation  in a new technology area; you may gain
            expertise you need as a side-effect of the project.
                 You  have  to  look at the type of contract you're going to work with, if
            it's  contract  work.   You  can  bid base cost plus T&M at a lower confidence
            level    than    fixed-price,    which    in    turn   can   be   lower   than
            fixed-price-with-penalty-for-late,      which      is      different      from
            fixed-price-with-bonus-for-early,  etc.   to  endless  detail.   Sometimes you
            don't even bid because the terms your customer wants don't fit with the amount
            of  risk  (which translates into level of confidence for a plausible schedule)
            for the project.

            > This implies that he is willing to proceed based on the assumption that
            > HE CANNOT SUCCEED in meeting time or budget constraints...
                 No, it implies that I might be willing to proceed even with the knowledge
            that  the  desired (ideal) outcome is less than certain.  But it involves lots
            of  other  considerations, per above, if you're going to go ahead from a lower
            confidence value.

            >...Dick - who's
            > funding you?...
                 Our customers.

            >...What happens when the date for which you had 70%
            > confidence comes and goes?  Who eats it?...
                 If  the project is begun at a low confidence level, there will be aspects
            of  the  contract  which  anticipate  that.   If  an  estimate  carries  a low
            confidence, that's taken into account.

            >...I would rather produce a
            > realistic project plan up front, including specifying the compromises,
            > than to produce a falsely optimistic plan with a qualifier ("this is
            > only 70% certain") and have to scramble to adjust near the end.
                 It  depends on what the curve of confidence level vs schedule looks like.
            All  such  curves have a tail asymptotic to 100%.  With some, the shape of the
            tail heading out past 75% or so is unpleasantly long...that tells you that the
            project  is  riskier than average, and you have to decide whether you can live
            with the risk.

            1.1.3.  From____ William_______ Thomas______ Wolfe_____

            Date: 11 Oct 89 15:22:59 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
                 From rcd@ico.ISC.COM (Dick Dunn):
            >> >>    ...We're here to engineer products on time, under budget,
            >> >>    and with as much quality as we can get within those two constraints.
            >> > ...It's particularly
            >> > sad to see "quality" a poor third to the other two.
            >>    If the product does not meet the minimal standards of acceptability,
 
            1. Articles                                                         Page 202-3




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >>    then it is not complete.  "On time", etc., refers to the product
            >>    being completed in accordance with the relevant quality requirements.
            >
            % It is entirely possible to construct software which meets all such require-
            % ments, but which is poorly conceived or implemented.  Examples abound.  I
            % know of no way to specify software requirements such as "must be able to
            % survive the next five years of changes, to meet new needs, hacked in by
            % bored second-string maintenance programmers..."  But that's often what
            % quality software needs.  [...] My personal peeve here is that I spend
            % far too much of my time reworking under-engineered hacks back into
            % decent code that can survive.  So I see an extreme focus on
            % budget/schedule as needlessly increasing the amount of such work I
            % have to do.
                 This  depends  upon  whether  the product is implemented by hackers or by
            professionals.   A  professional  will  meet  cost and schedule constraints by
            using CASE tools, advanced programming languages, and so on, using overtime as
            the  last  resort.   A  professional  knows  that developing modular, readable
            software  not  only helps make the software maintainable, but also reduces the
            probability  that  the  product  will be delayed due to errors and reduces the
            time  that  will be required to correct errors if they are discovered, thereby
            enhancing the probability of meeting scheduling constraints.
                 Dick's  particular  environment is one in which operating system software
            is  being  developed  in  C,  a  double  whammy  as  far as a well-established
            tradition of hacking is concerned.  In such an environment, great efforts must
            be  taken  on  the  part  of  management  to  ensure the existence of a proper
            software engineering orientation.

            1.1.4.  From____ Jeff____ Hallett_______

            Date: 11 Oct 89 17:06:55 GMT
            From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu
              !mrsvr.UUCP!positron.uucp!hallett@tut.cis.ohio-state.edu
              (Jeff Hallett x5163 )
                 In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >It is entirely possible to construct software which meets all such require-
            >ments, but which is poorly conceived or implemented.  Examples abound.  I
                 Therefore it is time someone addressed the issue of how to quantitatively
            specify  nebulous  terms  like  "user friendly", "maintainable", "extendible",
            etc.   In  a requirements document, these terms have no meaning aside from the
            warm  and  fuzzy  connotations.   To  quote  Star  Trek:  The  Next Generation
            ("Samaritan  Snare"),  the space moron stated : "We look for things: things to
            make us go." Sure, but quantify it.
                 How   does   one   specify  a  requirement  for  "user  friendliness"  or
            "well-written"?









 
            Page 202-4                                                 1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.5.  From____ Richard_______ S_ D'Ippolito__________

            Date: 11 Oct 89 21:46:47 GMT
            From: sei!rsd@pt.cs.cmu.edu  (Richard S D'Ippolito)
                 In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >It is entirely possible to construct software which meets all such require-
            >ments, but which is poorly conceived or implemented.  Examples abound.  I
            >know of no way to specify software requirements such as "must be able to
            >survive the next five years of changes, to meet new needs, hacked in by
            >bored second-string maintenance programmers..."  But that's often what
            >quality software needs.
                 There  are  ways  to  do  it.   One can generally anticipate the areas of
            change, especially in large systems where there is a long history of changes.
                 For  example,  suppose  you require software for a flight trainer used to
            simulate  operation  at  several  airports,  i.e.,  the characteristics of the
            airports  are used to drive the simulated display and the cockpit instruments.
            Can't  it  be  required  that  the  capability  of  changing the airport(s) be
            designed  in?  It  is  possible  for  the contractor to include in his bid the
            effort (read "cost") to do this.
                 Suppose  you  are  building  a  C3I  system  based  on  a large number of
            electronically  received  messages  which  have to be translated and validated
            before  being  stored in a database.  Should you not require the contractor at
            proposal time to tell you the cost of adding or deleting new messages, some of
            which  are  of  the  same  types  and some of which are probable new types (if
            known)?
                 There  are  many  other  examples I could give, as these types of systems
            have  been  around long enough for us to have a good idea of the nature of the
            expected  changes.   It merely requires the program office to request the cost
            of the anticipated changes in the proposals.
                 As  you  can  see,  the contractor (read "software engineer") is going to
            need some concrete idea of what he's going to build in order to be responsive,
            but, hey, isn't that true of other engineers?
                 Watch for it -- happening soon to a contractor near you!

            1.1.6.  From____ Phil____ Meyer_____

            Date: 11 Oct 89 22:10:39 GMT
            From: gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!texbell
              !vector!attctc!phil@tut.cis.ohio-state.edu  (Phil Meyer)
                 In    article   <6742@hubcap.clemson.edu>   billwolf%hazel.cs.clemson.edu
            @hubcap.clemson.edu writes:
            >From rcd@ico.ISC.COM (Dick Dunn):
            >
            >    This depends upon whether the product is implemented by hackers
            >    or by professionals.
                 Haven't we had the hacker vs.  professional wars before? I am reminded of
            the  fortune "A poor workman blames his tools".  It is also a poor workman who
            must  blame  tools  for  other's  inferior  workmanship.   This next statement
            suggests  that  you are not professional if you do not use CASE tools.  Pretty
            silly.  Most developers are still eyeing CASE.

            >    A professional will meet cost and schedule
            >    constraints by using CASE tools, advanced programming languages,
 
            1. Articles                                                         Page 202-5




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >    and so on, using overtime as the last resort.
                 This last line is the killer.  If you don't work your butt off, you don't
            work  for me! If the job needs doing, you stay 'till it's done.  What is this?
            Bankers ethics in the computer center? Forget it!

            >    Dick's particular environment is one in which operating system
            >    software is being developed in C, a double whammy as far as a
            >    well-established tradition of hacking is concerned.  In such an
            >    environment, great efforts must be taken on the part of management
            >    to ensure the existence of a proper software engineering orientation.
                 This  statement  applies  to ANY environment.  It may be true that sloppy
            programmers working in a CASE environment can produce better code than without
            CASE,  but  steps  must  still be taken to insure that guys like you who won't
            stay past quitting time, don't just throw stuff together!
                 This  isn't really a flame, I was just suprised to see stuff like this in
            a  news  group  where I'm certain that most participants dream of the day when
            they can work 'regular' hours.

            1.1.7.  From____ William_______ Thomas______ Wolfe_____

            Date: 12 Oct 89 01:30:55 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
                 From phil@attctc.Dallas.TX.US (Phil Meyer):
            >>    A professional will meet cost and schedule
            >>    constraints by using CASE tools, advanced programming languages,
            >>    and so on, using overtime as the last resort.
            >
            > [...]  I'm certain that most participants dream of the day when
            > they can work 'regular' hours.
                 First,  the  context:  my  work experience so far has been with a company
            which  had  to  actually  pay time-and-a-half for overtime, which is usually a
            VERY expensive way to trade cost for schedule.
                 Also, Phil misinterprets my position.  The idea is to maximize the use of
            productivity  tools  FIRST;  simply  throwing time at the problem makes little
            sense  UNLESS we have already done all the things that can be done to minimize
            the difficulty of solving it.

            1.1.8.  From____ Linda_____ Mundy_____

            Date: 11 Oct 89 22:49:07 GMT
            From: pacbell!rtech!linda@ames.arc.nasa.gov  (Linda Mundy)
                 In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:

            >billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
              (William Thomas Wolfe, 2847 ) writes:
            [...some discussion of "on time, under budget" vs. "quality", deleted...]
            
            >"Quality" software is MUCH more than software which meets "the minimal
            >standards of acceptability", thank you.
            >
            [...more good stuff deleted...]
            >
 
            Page 202-6                                                 1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >It is entirely possible to construct software which meets all such require-
            >ments, but which is poorly conceived or implemented.  Examples abound.  I
            >know of no way to specify software requirements such as "must be able to
            >survive the next five years of changes, to meet new needs, hacked in by
                                                                        ^^^^^^^^^^^^
            >bored second-string maintenance programmers..."  But that's often what
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            >quality software needs.
            >
                 Dick,  I  really  agreed with the main points of your article, making the
            above  remark  come as a surprise.  Not picking you in particular, but this is
            such  a common attitude towards maintenance programmers, I thought it might be
            appropriate as a topic of discussion in its own right.  So I ask you:

             1.   do  you  think  maintenance  work  is easier than development work?
                 always?  sometimes? never? does your answer change for large systems
                 vs.  small systems?

             2.   do  you  think  that  maintenance  programming belongs lower on the
                 "pecking order" than development programming?

             3.   do  you think that such presumptions are likely to help people work
                 together more effectively?

             4.   do  you  think  that  software  engineers  should  do  a  stint  at
                 maintenance,  or do you think that maintenance is a place to put the
                 (perceived to be) less talented?

             5.   do  you  think  maintenance  should be a separate function, or that
                 developers  should be responsible for maintaining their own code (as
                 much as possible)?

             6.  do you think that there are different skill sets for maintenance vs.
                 development? if so, is one skill set "better" than another?

                 You can probably tell, you hit one of my hot buttons.  I personally think
            that  any  new,  just-out-of-school  programmer should do maintenance work for
            awhile  (assuming, of course, that the company already has a product!) It will
            introduce them to the product they will be working on, in a context where they
            can  both  learn and have something to show for it.  It will introduce them to
            the  prevailing coding style.  It will introduce them to the many pitfalls and
            pratfalls  that  lead to bugs, thus hopefully teaching them how to avoid same.
            It may introduce them to the real-world effects of software bugs on customers,
            thus  improving their attitudes towards software quality.  etc., etc.  But the
            most  important  point:  don't  diminish  people  because  of  their  relative
            positions.  It can't do any good -- in fact, it is exactly such attitudes that
            lead  to "bored, second-string" employees -- wherever they happen to be in the
            organizational structure.
                 As I said before, this is not meant as a flame, and judging by your other
            statements,  I doubt that we are in basic disagreement.  Of course, I could be
            wrong! (but only about the previous statement...;-))


 
            1. Articles                                                         Page 202-7




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.9.  From____ Dick____ Dunn____

            Date: 12 Oct 89 03:54:08 GMT
            From: gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!ico!vail
              !rcd@tut.cis.ohio-state.edu  (Dick Dunn)
                 I  was  gritching about quality being given short shrift, and had pointed
            out  that  software can be constructed which meets all objective requirements,
            yet is of poor quality.

            >     This depends upon whether the product is implemented by hackers
            >     or by professionals...
                 Hey,  groovy...we'll  just  get  our  customers  to  add  a clause to the
            contract  to require that "All software shall be implemented by professionals.
            Hackers  shall  not  be  employed..." and nobody will have to worry about poor
            quality software any more, right?
                 Of course good people will produce better software than bad people.  That
            is  true,  but irrelevant to the point I was trying to make--which is that the
            relative  emphasis  on  quality will influence the result.  A good programmer,
            under   extreme   time/budget   pressure,  will  likely  be  able  to  produce
            better-quality  software  than  a  dullard working at leisure who codes with a
            chainsaw  .  But the professional won't do as good a job as if there were more
            external interest in quality and less extreme time/money pressure.

            >...A professional will meet cost and schedule
            >     constraints by using CASE tools, advanced programming languages,
            >     and so on...
                 No.   A  professional  will  use  the tools suitable for the job (perhaps
            creating  them  if  appropriate).   A  professional  will  focus on the job of
            constructing  good  software, and will leave the buzzword-oriented programming
            to the acolytes of strongly-hyped languages.  (apologies to Andrew Koenig)
                 And what's this about advanced programming languages? Wolfe has, in other
            postings,  been  an  outspoken  advocate  of  Ada,  which  is  certainly *not*
            advanced.   In  fact,  the  difficulty  of  making  Ada  catch  up  to current
            technology has been a hot topic over in comp.lang.ada.

            >     Dick's particular environment is one in which operating system
            >     software is being developed in C, a double whammy as far as a
            >     well-established tradition of hacking is concerned...
                 There is operating system software developed in C at Interactive Systems.
            That's  not  what I'm doing, although that is irrelevant.  C is well suited to
            the task.  (Most of the OS work is, for example, better done in C than in C++.
            But  you  have  to  understand  what  "most  of the work" is about, and that's
            another topic.)
                 The  "well-established  tradition  of  hacking"  is  an  empty  insult, a
            manifestation  of  Wolfe's  inability  to  mount any substantive objection.  C
            works.   UNIX  works.  They've lasted well, and survived incredible amounts of
            modification  and  adaptation.   All  the cheap insults you can dream up won't
            change  that.   We'll trade taunts with you for a while; then we'll let you go
            back to *talking* about software while we *produce* software.
                 Don't get me wrong--C is *not* The One True Way.  (That's religion, which
            is  anathema:-)  C  is  *a*  way  to  get  things done, and done both well and
            expeditiously.   There  are  other  languages  and  tools--some  of  them more
            appropriate to their problem domains than C could be.
 
            Page 202-8                                                 1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >        In such an
            >     environment, great efforts must be taken on the part of management
            >     to ensure the existence of a proper software engineering orientation.
                 Not  at  all.   You just get good people who know what they're doing, and
            make  room  for  them  to  do their jobs.  Good management does not direct; it
            assists.
                 The  people  I  work with are not the people who produce the nasty code I
            was  complaining  about  in my earlier posting.  In fact, some of the nastiest
            code  was  produced  as  a  result of blind, dogmatic application of so-called
            software  engineering  principles.   It's  gotten them into binds.  We have to
            help them out, help clean up the messes, and get the software headed back in a
            reasonable  direction.   We  do  it  in  C  (since that's what all of them are
            using),  without  dogma  and  buzzwords.   Sometimes we have to tell them that
            getting  back  to  quality  software is going to cost a little more and take a
            little  longer than the "shortest path" to meeting the immediate requirements.
            When  we  can  make  a  good case for it, they're likely to go for it--because
            they've  seen  how  we  work  and  they appreciate the long-term benefits.  We
            budget and plan for quality work; we don't "lowball" contracts.

            1.1.10.  From____ Steve_____ Shapland________

            Date: 12 Oct 89 16:27:50 GMT
            From: ico!vail!sps@handies.ucar.edu  (Steve Shapland)
                 In article <3807@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes:

            >In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >>I know of no way to specify software requirements such as "must be able to
            >>survive the next five years of changes, to meet new needs, hacked in by
            >                                                            ^^^^^^^^^^^^
            >>bored second-string maintenance programmers..."  ...
            > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            >     .....  I personally think that
            >any new, just-out-of-school programmer should do maintenance work for awhile
            >(assuming, of course, that the company already has a product!)  It will
            >introduce them to the product they will be working on, in a context where they
            >can both learn and have something to show for it.  ...
                 I  agree  with  the policy of assigning rookie programmers to maintenance
            tasks.   The learning experience is wonderful.  Most companies I've worked for
            tend  to  follow  this policy, and I believe that this is what leads to Dick's
            view of maintenance programmers.

             1.   "hacked"  -  Being  rookies,  they  are still learning the product,
                 style,   and   problems   of   real-world  (large  complex  systems)
                 programming.  Their code tends to lack the polish of craftsmanship.

             2.   "bored"  -  Being youthful, they still possess the dream of setting
                 the  world  on fire.  "Enough of this working on last year's code, I
                 want to design the next major system." They are being forced to walk
                 when they want to run.

             3.  "second-string" Of course they're second-string.  They still have to
                 prove  themselves  to management; and until they do, the more senior
                 people of the team continue to carry the ball.
 
            1. Articles                                                         Page 202-9




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 There   is  yet  another  reason  for  assigning  junior  programmers  to
            maintenance  tasks.   Don't  forget that maintence represents ~80% of the life
            cycle  costs of a software product.  By assigning programmers from the low end
            of the pay scale, these costs may be reduced.
                 All of the above sounds brutal, but the benefits, to both the programmers
            and the companies who pay their salaries, are very significant.
                 My  pet peeve regarding quality software is programmers who insist on the
            status quo, without considering improvements in their toolkits and development
            processes.   These  programmers  are  still  producing  code  with last year's
            methods  and  setting poor examples for the junior programmers who have to fix
            that code next year.
                 Quality  development  is  an  continual spiral.  As you introduce quality
            improvements,  the quality of the each succeeding product generation improves.
            The inverse is also true.  If you do not introduce quality improvements in the
            development   process,  the  quality  of  the  future  products  continues  to
            deteriorate.   The  real  problem for management is the intial cost of getting
            into  the  right  spiral.   Once  on  the proper path, quality methods becomes
            second nature.

            1.1.11.  From____ Ted___ Dunning_______

            Date: 12 Oct 89 16:41:43 GMT
            From: opus!ted@lanl.gov  (Ted Dunning)
                 In  article  <3807@rtech.rtech.com>  linda@rtech.rtech.com  (Linda Mundy)
            writes:

               In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            
             ...
               I personally think that any new, just-out-of-school programmer
               should do maintenance work for awhile (assuming, of course,
               that the company already has a product!)
             ...
                 Why  wait until then? one of the most important things that any course in
            software  engineering  should have students do is work on a large system.  for
            that  matter,  so should all but the most basic courses.  if you have compiler
            class,  make them work on a real compiler, in a course on semantics, make them
            work with the semantics of a real language.

             ...
               But the most important point: don't diminish people because of
               their relative positions.  It can't do any good -- in fact, it
               is exactly such attitudes that lead to "bored, second-string"
               employees -- wherever they happen to be in the organizational
               structure.
             ...
                 I  am  not  sure that Dick was trying to diminish people asmuch as he was
            just  observing  that  the  programmers  who  do maintenance and typically are
            bored, typically are second-string.




 
            Page 202-10                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.12.  From____ Dick____ Dunn____

            Date: 12 Oct 89 21:50:44 GMT
            From: ico!vail!rcd@handies.ucar.edu  (Dick Dunn)
                 linda@rtech.rtech.com  (Linda  Mundy)  writes  about  my comment that one
            hard-to-pin-down aspect of new-code quality might be:

            > >..."must be able to
            > >survive the next five years of changes, to meet new needs, hacked in by
            >                                                             ^^^^^^^^^^^^
            > >bored second-string maintenance programmers..."  ...
            >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            
            She says:
            > Dick, I really agreed with the main points of your article, making the above
            > remark come as a surprise.  Not picking you in particular, but this is
            > such a common attitude towards maintenance programmers, I thought it might
            > be appropriate as a topic of discussion in its own right...
                 I  agree with Linda's sentiments.  Now, to be clear about why I said what
            I  did:  It  IS  a  common  attitude  toward maintenance programmers.  It's an
            unfortunate,  stupid,  misdirected attitude.  Not only do I NOT agree with it;
            it  makes  me  angry.   BUT it's there, and has to be reckoned with.  In other
            words,  I pointed out that quality software needs to survive being hacked over
            by  bad  maintenance  programmers  not because maintenance SHOULD be done that
            way,  but  because  it  WILL be done that way, in all likelihood.  You have to
            make  the  software  a  little  hardier  than it should need to be in order to
            survive what it will be put through.
                 Maybe  I  should also have been careful with the wording so that it would
            have  been  clear  that  I meant (second-string) (maintenance programmers), as
            opposed to (second-string maintenance) programmers.

            >        -- do you think maintenance work is easier than development work?
                 Sometimes  it  is  - routine changes may be very easy to make.  Sometimes
            it's  not - the effects of an apparently small change may run across the grain
            and  affect  a  large  part of the code, requiring exceptional perspicacity to
            keep from screwing up the code.

            >                ...does your answer change for large
            >                systems vs. small systems?
                 My  initial  reaction  is  that  it doesn't.  It changes depending on the
            structure of the system.  The more interconnected a system is, the harder some
            changes are.

            >        -- do you think that maintenance programming belongs lower on the
            >                "pecking order" than development programming?
                 As a rule, no.  However, it is usually PLACED lower in the pecking order.
            Sometimes,  maintenance  work  can  be  used effectively for training--in this
            sense,  you  spend  time  learning an existing body of code, understanding how
            things  are  done,  seeing  problems, etc., before you go create new code.  It
            works if it's done carefully.

            >        -- do you think that software engineers should do a stint at
            >                maintenance, or do you think that maintenance is a place to
 
            1. Articles                                                        Page 202-11




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >                put the (perceived to be) less talented?
            >        -- do you think maintenance should be a separate function, or that
            >                developers should be responsible for maintaining their own
            >                code (as much as possible)?
                 All   software   engineers  should  spend  time  on  maintenance.   Since
            maintenance,  in  the  general sense which includes modification, porting, and
            the  like, is MOST of what software folk spend their time doing, having people
            work only on new code puts them a bit out of touch with reality.
                 One approach is to assign people to a software project "cradle to grave."
            That  is,  if  you write it you maintain it.  You get to take on a new project
            when  the  work  load for the old one drops below some threshold.  This has an
            interesting  incentive--if  you  want  to  work  on new stuff, you may be more
            careful  getting  things  right  so  you don't have to do a lot of maintenance
            time.   The  approach also has a handful of flaws, but it's worth exploring it
            in some environments.

            >        -- do you think that there are different skill sets for maintenance
            >                vs. development?  if so, is one skill set "better" than
            >                another?
                 We  need to get development and maintenance to equal prestige.  There are
            people  who LIKE to work on existing code, shaping it to new needs.  There are
            others who are better at cutting from whole cloth; they have trouble reworking
            other  people's  code.   We  should  be  able  to  accommodate these different
            abilities.

            > You can probably tell, you hit one of my hot buttons...
                 Yes,  and  I  did  so  unintentionally;  it  seems  that  we're mostly in
            agreement.   But it's just as well.  It's a topic that needs to be dragged out
            into the open periodically.  It has been realized for perhaps two decades that
            maintenance  tasks  are perceived as "inferior" in many organizations.  It has
            also  been  realized  that  this leads to poor maintenance.  But we perpetuate
            those damaging stereotypes.

            1.1.13.  From____ Travis______ Marlatte________

            Date: 13 Oct 89 14:05:26 GMT
            From: gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!mailrus
              !accuvax.nwu.edu!delta.eecs.nwu.edu!travis@tut.cis.ohio-state.edu
              (Travis Marlatte)
                 I  don't  see  the  reasoning that novice programmers should be given the
            task  of  maintaining  existing  systems.  I also don't see the reasoning that
            thou who creates it will maintain it even unto ball and chain.
                 Simple  analogy:  A  team  of  crack  engineers  build  a  beautiful  and
            structurally  sound  bridge  that  serves  its purpose well.  Five years after
            construction,  it  is learned that the foundation at one end is giving way due
            to  water  damage.   The  company  assigns  its newest employee to the task of
            designing the correction to the problem.
                 Sounds  absurd  to  me!  I would hope it sounds absurd to the rest of you
            too.   Isn't  the  analogy  correct.  Why would I want to assign inexperienced
            staff  to  the  task of shoring up existing systems? Especially, since we know
            that  mainenance  is  often  a  task  of stretching the intent of the original
            design  to  meet  current  expectations.   Further, why would I want my newest
            employee dedicated to mastering 5 year old technology?
 
            Page 202-12                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 Why  does  the idea of an apprentice not spring to mind quickly? Would it
            not  be  better  to  have  a junior programmer (or junior software engineer or
            junior  whatever)  position? This position may very well get stuck with a load
            of  grunt work tasks.  But, the work would ultimately be the responsibility of
            a senior person who guides the work of the junior.
                 The work would then include a mix of maintencance and latest and greatest
            design  -  whatever  the senior staff was working on.  By blending the work of
            the past with the work of the new, the junior member gets an introductory view
            of the whole picture.  Technology transfer through sharing rather than dumping
            - dumping unwanted, undesirable tasks on a new hire.
                 This  type  of  idea  can  be  taylored  to  each  situation.   A company
            developing  coin  machines may have a six month apprentice program.  A company
            developing chemical process control might have a 5 year program.
                 I have a friend working as a actuary.  For advancement, they have to take
            a  series of tests that may take up to ten years to complete.  Their status as
            an actuary depends on the level they have achieved in taking the tests.
                 While  I  don't  think  the  software  business  is  as structured as the
            insurance  business,  my point is that a training program for newcomers should
            not  be  shuned.  It should not be embarassing to be considered a junior staff
            member.   Of  course, there is cause to celebrate when that day comes that you
            are no longer considered a junior.
                 By  the  way,  my first job out of school was as a maintenance programmer
            for  control  systems.  I didn't mind doing it but it certainly was a waste of
            time.   Only  by  becoming  involved  in curent design effort does one come to
            understand the task of doing current design.

            1.1.14.  From____ Phil____ Meyer_____

            Date: 13 Oct 89 19:33:00 GMT
            From: attctc!phil@ames.arc.nasa.gov  (Phil Meyer)
            In  article <1271@accuvax.nwu.edu> travis@delta.eecs.nwu.edu (Travis Marlatte)
            writes:

            >
            >Why does the idea of an apprentice not spring to mind quickly?
                 Travis  has  a  good point here.  The analogy to a wizard's apprentice is
            even  better.  How do you become a wizard? By studying with/for a wizard.  (or
            rather, what is the BEST way)
                 We  must also cultivate a love of the craft.  This is the real difference
            between being bored (in any position) and being happy with the workload.
                 Many  really  good programmers do it because they couldn't think of doing
            anything  else.  "Give me a workstation and a place to sit, and I'm happy." is
            a  common attitude among the wizards I have known.  The specific task, whether
            it  be  maintainance  or  design, is seldom mentioned.  But rather, the usuall
            conversations  amongst  these  people  lean  towards new constructs, difficult
            passages, tools, the latest and greatest hardware, etc.  etc.







 
            1. Articles                                                        Page 202-13




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.15.  From____ Jim___ Barnes______

            Date: 13 Oct 89 12:16:26 GMT
            From: xylogics!barnes@CS.BU.EDU  (Jim Barnes)
            In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:

            >
            >One approach is to assign people to a software project "cradle to grave."
            >That is, if you write it you maintain it.  You get to take on a new project
            >when the work load for the old one drops below some threshold.  This has
            >an interesting incentive--if you want to work on new stuff, you may be more
            >careful getting things right so you don't have to do a lot of maintenance
            >time.  The approach also has a handful of flaws, but it's worth exploring
            >it in some environments.
                 One  disadvantage  to this approach is that it will encourage turnover of
            personnel.   "I'm  tired  of  just  doing  maintenance  and  since I can't get
            assigned  to  some new development, I'll just go somewhere where I CAN work on
            something  new."  Then  you  have  to  hire  new programmers to do maintenance
            anyway.

            >We need to get development and maintenance to equal prestige.  There are
            >people who LIKE to work on existing code, shaping it to new needs.
                 I  agree,  but it seems that it is very hard to find these people.  Maybe
            the truly good maintenance programmers do not change jobs very often.

            1.1.16.  From____ Jim___ Bander______

            Date: 13 Oct 89 23:20:52 GMT
            From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth
              !bander@tut.cis.ohio-state.edu  (Jim Bander)
            In  article  <1189@mrsvr.UUCP> hallett@gemed.ge.com (Jeffrey A.  Hallett (414)
            548-5163) writes:

            >
            >Therefore   it  is  time  someone   addressed  the  issue   of how  to
            >quantitatively    specify    nebulous  terms   like "user   friendly",
            >"maintainable", "extendible", etc.  In  a requirements document, these
            >terms have no meaning aside from the warm and  fuzzy connotations.  To
            >quote Star Trek: The Next   Generation ("Samaritan Snare"), the  space
            >moron stated : "We look for things: things  to make us go."  Sure, but
            >quantify it.
            >
            >How   does  one  specify  a  requirement   for "user  friendliness" or
            >"well-written"?
                 I'm  not  sure  anyone will ever QUANTIFY user-friendliness in a way that
            would  help  me  design  better  systems.   But Paul Heckel (formerly of PARC)
            SPECIFIED  the requirement 30 useful ways in The___ Elements________ of__ Friendly________ Software________
            Design______  (Warner  Books, 1984).  His point is that software designers who think
            like  engineers are doomed to fail, as was Thomas Edison when he tried to make
            movies.   Engineers  develop  the  medium;  writers  and  artists  use  it  to
            communicate effectively!


 
            Page 202-14                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.17.  From____ Dick____ Dunn____

            Date: 13 Oct 89 20:50:08 GMT
            From: usc!ginosko!cs.utexas.edu!ico!vail!rcd@ucsd.edu  (Dick Dunn)
            
            rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
            > ... rcd@ico.ISC.COM (Dick Dunn) writes:
            [about the hard-to-pin-down adaptability needs]
            > >..."must be able to
            > >survive the next five years of changes, to meet new needs,...
            
            > There are ways to do it.  One can generally anticipate the areas of change,
            > especially in large systems where there is a long history of changes.
                 Yes, you can anticipate some of the needs.  But there's a whole continuum
            of  possible changes.  Some future needs are so explicit that you can actually
            put  provisions  in  your  requirements  that  the  code  be  "ready"  for the
            changes--in  effect, what you do is specify and design for a feature; you just
            don't implement it.
                 Next  along the spectrum is the type of change Richard is talking about--
            You may not be able to pin down the exact change you'll need, but you know the
            general area and direction.
                 The type of change I'm interested in is all the way down at the other end
            of the spectrum...the changes which will eventually come about because someone
            comes  up  with a need and says, "Wait a minute! What about the xyzzy program?
            Doesn't  it  do a lot of this stuff? Could we adapt it to do what we need?" It
            may  be  an  adaptation of the program to add a capability, or you might clone
            the program and transmogrify the clone.
                 I   don't  have  many  clues  of  how  to  characterize  or  measure  the
            adaptability  of code to such unanticipated needs.  I'm not even sure it makes
            sense  to  try  to  measure  it.   But  I  do know that it's common to look at
            recycling  code  this  way...and  I  know that "quality code" will allow it to
            happen.
                 It's  hard  to  make analogies with other areas of engineering about this
            sort of change, because software is so much more mutable.

            1.1.18.  From____ Lee___ Sailer______

            Date: 13 Oct 89 14:43:55 GMT
            From: psuvm!uh2@psuvax1.cs.psu.edu  (Lee Sailer)
            
            <16187@vail.ICO.ISC.COM> <1189@mrsvr.UUCP>
            
            In article <1189@mrsvr.UUCP>, hallett@positron.uucp (Jeff Hallett x5163 )
            says:
            >How   does  one  specify  a  requirement   for "user  friendliness" or
            >"well-written"?
            >
                 I  know many will scoff, but you can measure these things.  Just go ask a
            social  scientist, eg psychology, sociology, anthropology.  These guys measure
            such  fuzzy  things  all  the  time.   So, without further ado, here's a brief
            course in Measurement:
                 What is a measure?
                 We have some concept from the world, like 'user friendly'.  The domain is
 
            1. Articles                                                        Page 202-15




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            the set of all programs we are concerned with.  We'd need a function that maps
            from  the  domain  to  something  arithmetical,  say  the  set of reals.  That
            function  is  a  measure if some features of arithmetic on the resulting reals
            behave in a way that reflects the behavior of the objects in the domain.
                 Constructing that function is the art of measurement.
                 Example--User Friendliness
                 Let's  use  a  spreadsheet  as  an  example.  Prepare a test, say 8 or 10
            problems  that  spreadheet users should be able to solve.  To measure the user
            friendliness  of  spreadsheet X, choose 100 typical users at random, give them
            some  fixed  amount  of instruction, say 5 hours, and then give them the test.
            The average score of those 100 users on the test is a number, UF(X).
                 Repeat  for spreadsheet Y with a new group of 100 users.  This produces a
            number UF(Y).
                 In  fact,  for  any  spreadsheet  Z  there is in theory at least a number
            UF(Z),  so  UF:  Spreadsheets  ------>  reals is (within some variability from
            group  to group) a function.  I contend that if UF(X) > UF(Y) then spreadsheet
            X is more user friendly than Y is, which makes UF an "ordinal" measure.
                 Comments
                 That's  pretty  expensive, isn't it? Yes, it is.  Some things are easy to
            measure.   The  physical  scientists snapped those up pretty early, eg length,
            weight,  temperature,  strength.   Some  things  are  hard,  eg  time,  space,
            subatomic thingies, and nearly all the stuff social scientists are studk with.
                 Do  UF(x)-UF(y) or UF(x)/UF(y) mean anything? These arithmetic operations
            may  not be used on our example measure, UF.  However, techniques for creating
            scales where these operations may be used are available, eg Magnitude Scaling.
                 Where  can I learn more? The library, or course, is full of books.  Start
            with Research Methods in , where the blank is any social science.
                 Measuring "well-written"
                 Give the code to the quality control team.  They study the code, and then
            introduce  bugs  on  purpose.   Give  the code to another team that debugs it.
            This  produces  several  numbers: the number of introduced bugs they find, the
            number  of  introduced  bugs  they  correctly fix, the number of new bugs they
            find.   high  scores  for  the  first two indicate well-written code, and high
            numbers  for  the second indicate poorly written code.  That's three measures.
            You might stick them together with something like

                                 WW =  (measure1 + measure1)/measure3
                 Is  this  fuzzy  and squishy? Yes, of course it is.  More money poured on
            the  process  would make the measurement more precise, valid, reliable, and so
            on, but may not be worth it.

            1.1.19.  From____ Richard_______ Sargent_______

            Date: 13 Oct 89 15:30:10 GMT
            From: pantor!richard@uunet.uu.net  (Richard Sargent)
            
            > From: linda@rtech.rtech.com (Linda Mundy)
            > Message-ID: <3807@rtech.rtech.com>
            > Date: 11 Oct 89 22:49:07 GMT
              ...
            > Not picking you in particular, but this is such a common attitude
            > towards maintenance programmers, I thought it might be
            > appropriate as a topic of discussion in its own right.
 
            Page 202-16                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >
                 Most  companies  I  have  encountered  have  the attitude that it takes a
            particularly *skilled* person to be a *successful* maintenance programmer.
                 Think  about  it  for  a  few  moments: when you come along, pick up some
            else's  code,  have  to find and fix a bug in the shortest possible time frame
            (since it is delaying your customers!), and so on.  Good maint.programmers are
            worth  their  weight in gold (well, maybe silver :-) to companies which have a
            significant investment in existing products.
                 In  an  ideal  world,  it  would  be  nice if we developers didn't create
            programs  with  any  bugs,  so  maint.programmers would only have to deal with
            enhancement  requests,  but it just ain't that way now, and won't be for quite
            some time to come.  :-(

            1.1.20.  From____ Richard_______ Sargent_______

            Date: 13 Oct 89 14:46:20 GMT
            From: pantor!richard@uunet.uu.net  (Richard Sargent)
            
            > From: phil@attctc.Dallas.TX.US (Phil Meyer)
            > Message-ID: <9670@attctc.Dallas.TX.US>
            > Date: 11 Oct 89 22:10:39 GMT
            >
            > In article <6742@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
              @hubcap.clemson.edu writes:
            > >From rcd@ico.ISC.COM (Dick Dunn):
               ...
            > >    A professional will meet cost and schedule
            > >    constraints by using CASE tools, advanced programming languages,
            > >    and so on, using overtime as the last resort.
            >
            > This last line is the killer.  If you don't work your butt off, you don't
            > work for me!  If the job needs doing, you stay 'till it's done.  What is
            > this?  Bankers ethics in the computer center?  Forget it!
                 You've  got  to  be  joking!  Sweatshops  went out of fashion in the last
            century! It is true that entrenpreneurial companies and start-ups require long
            hours  of  the staff/owners, but sensible employers plan for their staff to be
            still alive and functional so that they can do the next project.
                 Staff distracted/unhappy/etc.  from divorces/miserable homelives/etc.  or
            burned  out,  etc.   are  poorer producers than those who aren't.  Whether the
            burnout  takes  6  months,  a year, or two isn't germane.  Turn-over is *very*
            expensive for companies
                 If a company can't budget a project to avoid burning out its staff, it is
            in long-term trouble.  There certainly circumstances where the 6 month project
            just  has to be done in 3 months, but if that is company policy, you'll lose a
            lot of people.
                 *I*  work  to  live, not live to work.  I am fortunate to work in a field
            that  I  enjoy.   If  my employer tried to make 16 hour days a policy, I would
            switch  to  working  for  a  bank  faster than you could say "boo".  (They pay
            better and the fringe benefits are nice - low interest and a pension plan, for
            starters.  :-)
                 Enough  said.   I fully realize there as many rebuttals possible as there
            are  circumstances for everyone out there.  This is my opinion: you don't have
            to agree nor even like it.
 
            1. Articles                                                        Page 202-17




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.21.  From____ Linda_____ Mundy_____

            Date: 13 Oct 89 23:19:46 GMT
            From: pacbell!rtech!linda@ames.arc.nasa.gov  (Linda Mundy)
            
            In article  ted@nmsu.edu
            (Ted Dunning) writes:
            >
            >In article <3807@rtech.rtech.com> linda@rtech.rtech.com (Linda Mundy)
            >writes:
            >   In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >        ...
            >   I personally think that any new, just-out-of-school programmer
            >   should do maintenance work for awhile (assuming, of course,
            >   that the company already has a product!)
            >        ...
            >why wait until then?  one of the most important things that any
            >course in software engineering should have students do is work on
            >a large system.  for that matter, so should all but the most
            >basic courses.  if you have compiler class, make them work on a
            >real compiler, in a course on semantics, make them work with the
            >semantics of a real language.
            >
                 I  certainly  agree that could be a very useful approach; however, few if
            any university CS programs operate that way.

            >        ...
            >   But the most important point: don't diminish people because of
            >   their relative positions.  It can't do any good -- in fact, it
            >   is exactly such attitudes that lead to "bored, second-string"
            >   employees -- wherever they happen to be in the organizational
            >   structure.
            >        ...
            >i am not sure that dick was trying to diminish people asmuch as
            >he was just observing that the programmers who do maintenance
            >and typically are bored, typically are second-string.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            >
                 I  don't  think  he  was  *trying*  to  diminish  people, yet that phrase
            "second-string  maintenance  programmers" sure sounds like a stereotype to me.
            And your comments above perpetuate that stereotype.

            1.1.22.  From____ Linda_____ Mundy_____

            Date: 16 Oct 89 19:12:05 GMT
            From: oliveb!amdahl!rtech!linda@apple.com  (Linda Mundy)
                 In  article  <16198@vail.ICO.ISC.COM>  sps@ico.ISC.COM  (Steve  Shapland)
            writes:
            >In article <3807@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes:
            >>In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >>>I know of no way to specify software requirements such as "must be able to
            >>>survive the next five years of changes, to meet new needs, hacked in by
            >>                                                            ^^^^^^^^^^^^
 
            Page 202-18                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            >>>bored second-string maintenance programmers..."  ...
            >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            >>     .....  I personally think that
            >>any new, just-out-of-school programmer should do maintenance work for awhile
            >>(assuming, of course, that the company already has a product!)  It will
            >>introduce them to the product they will be working on, in a context where
            >>they can both learn and have something to show for it.  ...
            >
            >I agree with the policy of assigning rookie programmers to maintenance
            >tasks.  The learning experience is wonderful.  Most companies I've
            >worked for tend to follow this policy, and I believe that this is
            >what leads to Dick's view of maintenance programmers.
            >
                 Well  a  few  people  have  pointed out the apparent contradiction of (a)
            wanting  maintenance  to  be  respected  and  (b)  assigning rookies to do it.
            First,  I  did  not  say nor mean to imply that *only* rookies should be doing
            maintenance, just that *all* rookies should do some.  None of this "this guy's
            too  smart  to  'waste'  his  time doing maintenance".  In my experience, even
            smart  programmers benefit a *lot* by exposure to the problems that occur when
            software gets out there in the real world -- they see first-hand that software
            may be used in ways that are not foreseen; they experience the agony of trying
            to  debug  something  which has bad error handling/lack of tracing facilities/
            etc...  Hopefully, they learn from this how to code defensively.

            1.1.23.  From____ Kurt____ Luoto_____

            Date: 16 Oct 89 19:59:30 GMT
            From: oliveb!amdahl!fai!kurtl@apple.com  (Kurt Luoto)
                 In  article  <7402@xenna.Xylogics.COM>  barnes@Xylogics.COM  (Jim Barnes)
            writes:

            >In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            
            [ Some stuff deleted regarding assignment of personnel
              to maintenance programming ... ]
            
            >>We need to get development and maintenance to equal prestige.  There are
            >>people who LIKE to work on existing code, shaping it to new needs.
            >
            >I agree, but it seems that it is very hard to find these people.  Maybe
            >the truly good maintenance programmers do not change jobs very often.
            >
            >----
            >  Jim Barnes (barnes@Xylogics.COM)
                 I  agree  that  finding  people to stay with a project long-term is often
            difficult.   I certainly don't have any easy solutions.  However, I think that
            we help continue the problem and the mindset that gives rise to it by refering
            to  "development  programming"  and  "maintenance programming" as if they were
            somehow  very  different  things.  In my humble experience, there really is no
            difference.  The cuttoff point for the "maintenance" phase of a product's life
            cycle  is  completely  arbitrary.   I  don't change the way I program based on
            whether  the  product  has  had a first release or not.  Certainly I have some
            different problems when having to use or modify code that another person wrote
 
            1. Articles                                                        Page 202-19




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            as  opposed  to code that I wrote myself, but I have dealt with that situation
            even  in the "development" phase.  Ever had a team member leave the company in
            the  middle  of  development?  I think a company can take a small step towards
            resolution by officially not recognizing such an arbitrary distinction between
            development and maintenance phases of a project.
                 I  know  that  I'm not the first to voice the opinion, but can't find the
            references at the moment.  Cheers.

            1.1.24.  From____ Linda_____ Mundy_____

            Date: 16 Oct 89 19:52:14 GMT
            From: oliveb!amdahl!pacbell!rtech!linda@apple.com  (Linda Mundy)
                 In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:

            >linda@rtech.rtech.com (Linda Mundy) writes about my comment that one hard-
            >to-pin-down aspect of new-code quality might be:
            >> >..."must be able to
            >> >survive the next five years of changes, to meet new needs, hacked in by
            >>                                                             ^^^^^^^^^^^^
            >> >bored second-string maintenance programmers..."  ...
            >>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            >
            >She says:
            >> Dick, I really agreed with the main points of your article, making the
            >> above remark come as a surprise.  Not picking you in particular, but
            >> this is such a common attitude towards maintenance programmers, I thought
            >> it might be appropriate as a topic of discussion in its own right...
            >
            >I agree with Linda's sentiments.  Now, to be clear about why I said what I
            >did:  It IS a common attitude toward maintenance programmers.  It's an
            >unfortunate, stupid, misdirected attitude.  Not only do I NOT agree with
            >it; it makes me angry.  BUT it's there, and has to be reckoned with.  In
            >other words, I pointed out that quality software needs to survive being
            >hacked over by bad maintenance programmers not because maintenance SHOULD
            >be done that way, but because it WILL be done that way, in all likelihood.
            >You have to make the software a little hardier than it should need to be
            >in order to survive what it will be put through.
            >
            >Maybe I should also have been careful with the wording so that it would
            >have been clear that I meant (second-string) (maintenance programmers), as
            >opposed to (second-string maintenance) programmers.
            >
                 Well  your  main point remains valid, i.e.  that one needs to think about
            future maintenance/enhancement when coding something.  The phrase quoted above
            just  jumped  out  at me -- like a red flag in front of a bull -- and demanded
            comment...







 
            Page 202-20                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.25.  From____ Steven______ M._.  List____

            Date: 18 Oct 89 17:05:32 GMT
            From: coherent!mrspoc!itkin@ames.arc.nasa.gov  (Steven M. List)
            
            travis@delta.eecs.nwu.edu (Travis Marlatte) writes:
            
            >I don't see the reasoning that novice programmers should be given the
            >task of maintaining existing systems. I also don't see the reasoning that
            >thou who creates it will maintain it even unto ball and chain.
                 This  seems  awfully absolute.  I didn't hear anyone make either of these
            statements  as  absolutes.   In  fact, as regards the second statement, it was
            specifically  mentioned  as  an  option.   There  are MANY people who find the
            option  to  have  responsibility for and commitment to a project from "womb to
            tomb"  VERY  attractive.   There are others (myself included) who like to do a
            certain  amount  of work on a project and then move on to something else.  The
            threshhold varies, but the desire tends to be one for change and variety.

            >Simple analogy: A team of crack engineers build a beautiful and structurally
            >sound bridge that serves its purpose well. Five years after construction,
            >it is learned that the foundation at one end is giving way due to water
            >damage. The company assigns its newest employee to the task of designing
            >the correction to the problem.
                 I  notice  that  Travis  said "newest employee", not "novice engineer" or
            "recent graduate."

            >Sounds absurd to me! I would hope it sounds absurd to the rest of you too.
            >Isn't the analogy correct. Why would I want to assign inexperienced staff
            >to the task of shoring up existing systems? Especially, since we know that
            >mainenance is often a task of stretching the intent of the original design
            >to meet current expectations. Further, why would I want my newest employee
            >dedicated to mastering 5 year old technology?
                 Sounds  absurd  to  me  too.  No one said that was the idea.  The idea is
            that  through  working on fixing bugs (maybe major, maybe not), a new employee
            (not  necessarily  junior, however!!!!) can learn the systems, the techniques,
            and the standards and approach used by his/her new employer.  While we tend to
            think  of  YOUNGER employees when we think of NEWER employees, this is CLEARLY
            not  the  case.  When you change jobs, do you expect to walk into your new job
            and  immediately  start designing their hottest project? While it does happen,
            it  is  the exception rather than the rule.  New employees have to learn their
            way   around;   socially,   organizationally,   and  professionally.   In  our
            profession, this is frequently accomplished by putting the employee to work on
            low- to medium-priority maintenance tasks.

            > [ lots of interesting stuff about apprenticeship approaches ]
                 I agree that apprenticeship is a terrific way to progress.  Once again, I
            must  point  out  that  NEW  employee does not translate to RECENT GRADUATE or
            YOUNG.  Put the issue in perspective.

            >By the way, my first job out of school was as a maintenance programmer
            >for control systems. I didn't mind doing it but it certainly was a waste
            >of time. Only by becoming involved in curent design effort does one come
            >to understand the task of doing current design.
 
            1. Articles                                                        Page 202-21




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 "A  waste  of  time."  Does  this let everyone know what Travis thinks of
            maintenance  and  programmers  who DO maintenance? Obviously what is important
            and  interesting  to  Travis  is  design and being in on the ground floor of a
            project.   While  that's  true  of many of us, we also learn to appreciate the
            time  we  get  to  work  on maintenance.  It can be a wonderful break from the
            pressure  and pace of being at the front end.  Like doing gardening or cooking
            or  folding  laundry.   Like  doing  manual  labor  after programming all day.
            Change.
                 Nurture   versatility  and  an  appreciation  for  ALL  aspects  of  your
            profession, and you will BE a professional.

            1.1.26.  From____ Jim___ Frost_____

            Date: 18 Oct 89 20:12:25 GMT
            From: xylogics!world!madd@CS.BU.EDU  (jim frost)
            
            In article <3829@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes:
            >In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >>You have to make the software a little hardier than it should need to be
            >>in order to survive what it will be put through.
            [...]
            >Well your main point remains valid, i.e. that one needs to think about
            >future maintenance/enhancement when coding something.
                 Yes;  the technique I've used is to error-check arguments everywhere that
            performance isn't ABSOLUTELY necessary, even in distributed code.
                 This  costs  some performance but improves the initial quality and future
            maintainability.   During  development  it  catches  early programming errors,
            saving  debug  time.   Sometimes  it  saves  a  LOT  of  debug  time.   During
            maintenance  it provides known points of failure which can be used in tracking
            reported  bugs  and drops the likelihood that low-quality programmers will use
            functions incorrectly.

            1.1.27.  From____ J.R._._.  Jarrett_______

            Date: 18 Oct 89 02:34:29 GMT
            From: rochester!rit!ultb!jrj1047@cu-arpa.cs.cornell.edu  (J.R. Jarrett)
                 Titled "Software Maintenance is a Solution, not a Problem" in the Jan '89
            issue of System Development.  He stated that the goal of maintenance should be
            to  maximize  efficiency  rather  than minimize cost, and to do that, the best
            people should be attracted to and placed in maintenance positions.  It doesn't
            always  happen that way.  I work for a software maintenance group, and the new
            hires  are  the  ones that get put in there; the experienced people move on to
            more  "interesting"  ventures.  It's nice to say "Put the best people in", but
            until it happens in industry, it's no more than lip service.









 
            Page 202-22                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.1.28.  From____ Charles_______ Weir____

            Date: 20 Oct 89 16:34:48 GMT
            From: richsun!cweir@uunet.uu.net  (Charles Weir)
            
            In article <1989Oct18.201225.3330@world.std.com> madd@world.UUCP
            (jim frost) writes:
            >>>You have to make the software a little hardier than it should need to be
            >>>in order to survive what it will be put through.
            >[...]
            >>Well your main point remains valid, i.e. that one needs to think about
            >>future maintenance/enhancement when coding something.
            >
            >Yes; the technique I've used is to error-check arguments everywhere
            >that performance isn't ABSOLUTELY necessary, even in distributed code.
            >
            >This costs some performance
                 If performance is important, then make it an option (Compile option in C,
            I don't know in other languages):
            #if defined (CHECK)...
            [check all parameters]
            #endif
                 That  isn't quite as convenient as leaving the checks in permanently, but
            it allows one to use the technique in virtually ALL code.
                 It's funny how little public domain code does this...

            1.2.  Non-Code________ Software________ Components__________


            1.2.1.  From____ Edward______ Berard______

            Date: 12 Oct 89 01:45:43 GMT
            From: sei!ajpo!eberard@pt.cs.cmu.edu  (Edward Berard)
                 I  have  been  involved  in  software  reusability for a number of years.
            During this time I have:

             1.  conducted research in various aspects of software reusability (e.g.,
                 domain   analysis,   reusability   metrics,  and  reusable  software
                 construction)

             2.   conceived  of,  implemented, and sold on a commercial basis a large
                 (>512K lines of source code) library of reusable components

             3.  developed and delivered a number of software applications which made
                 conscious and extensive use reusable components

             4.  developed and delivered a number of courses on software reusability

             5.  provided consulting on software reusability to a number of clients

             6.  authored a number of papers, and chaired a few sessions on the topic

                 I  do  not consider myself an expert on software reusability, but I would
 
            1. Articles                                                        Page 202-23




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            say that I have some experience in the area.
                 One  thing  that continues to amaze me is the lack of understanding as to
            just  what  "software" is.  Before one can discuss reusing something, you must
            know what that something is.  When software reuse is discussed, very often one
            gets the impression that "software" is:

             a. source code
            
             b. object code

            and nothing else.
                 I  submit  that  software encompasses much more than mere source code and
            object code.  For example, I consider all of the following to be software:

             1.  code fragments

             2.  modules (in the subroutine/procedure/function sense)

             3.  packages (in the package/module/class sense)

             4.  large collections (in the library/subsystems sense)

             5.  applications (in the complete, stand-alone sense)

             6.   scaffolding  code (produced during development, but not part of the
                 delivered product)

             7.  test data

             8.  software quality assurance information

             9.  the deliverable products of feasibility studies

             10.  the deliverable products of analysis efforts

             11.  designs

             12.  plans

             13.  standards

             14.  tools

             15.  environments

                 You  will  note  that  not  everything  on  this  list  is code software.
            Non-code  software includes such things as test data, designs, plans, software
            quality  assurance  information,  standards, the products of analysis efforts,
            and the products of feasibility studies.
                 Unfortunately,  most  of the effort in software reusability systems seems
            to be focused on code software.  Ironically, this is the area where the return
            on  investment  seems  to  be the lowest.  For example, if analysis and design
            consume  a  significantly  larger  share  of the software life-cycle than does
 
            Page 202-24                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            coding,  reuse  of  analysis  and design can potentially provide significantly
            greater returns than the mere reuse of code.
                 The  reuse  of  non-code software involves different issues than does the
            reuse  of code software.  For example, non-code software may contain graphical
            information,  as  well  as  textual  information.   Many so-called reusability
            systems  are  not set up to handle graphical representations.  The taxonomies,
            evaluation  criteria,  and  interconnections  of  non-code  software are often
            different from the same items for code software.
                 Reusability technology tells us that:

             1.   The  larger  a component is, the higher will be the payoff from the
                 reuse of that component, however

             2.   The  larger  a component is, the lower will be the probability that
                 component will actually be reused.

                 This  means  that  domain analysts (i.e., those charged with identifying,
            documenting,  and  configuration managing reusable components) must constantly
            balance  the  size  of a component against its potential for reuse.  They must
            find  both  the  granularities of components, and the mix of components, which
            will provide the highest return.
                 Given  that  reuse  of  analysis  and design may potentially provide more
            benefits  than  the  simple  reuse of source code (in fact, may even drive the
            structure and selection of reusable source code), we need to ask:
                      What  should  the  granularity of analysis and design products be to
                 maximize  their  reusability,  and  thus  our  investment  in making them
                 reusable?
                 Of  course,  there  are  many  other  issues,  e.g., taxonomies, software
            engineering  approaches  (e.g.,  object-oriented),  horizontal  vs.   vertical
            reuse, and documentation styles.
                 I  propose  a  thread  of  discussion  focusing  on the reuse of non-code
            software.   Further,  I  propose  that, at least at the start, one of the main
            topics be the reuse of analysis and design, and, more specifically, what types
            of  analysis  and  design  products  provide a suitable granularity (i.e., one
            which has a high potential for a return on investment (ROI)).
                 I  have some ideas on the subject, but I will wait to see if there is any
            interest.

            1.2.2.  From____ William_______ Thomas______ Wolfe_____

            Date: 12 Oct 89 15:31:44 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
                 From eberard@ajpo.sei.cmu.edu (Edward Berard):

            > Non-code software includes such things as test data, designs, plans,
            > software quality assurance information, standards, the products of
            > analysis efforts, and the products of feasibility studies.
                 Wouldn't  this really be "software infrastructure", rather than software?
            Whatever  we call it, though, infrastructure reuse is certainly an interesting
            topic.

            > I have some ideas on the subject, but I will wait to see if there is
 
            1. Articles                                                        Page 202-25




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            > any interest.

            1.2.3.  From____ Scott_____ Henninger_________

            Date: 12 Oct 89 16:47:40 GMT
            From: scotth@boulder.colorado.edu  (Scott Henninger)
            
            |>From: eberard@ajpo.sei.cmu.edu (Edward Berard)
            |
            |I submit that software encompasses much more than mere source code and
            |object code.
                 Absolutely.   I  refer  you to Ted Biggerstaff's article in IEEE Computer
            (July,  1989).   He stresses the use of a wide scope of software work products
            to recover the design issues for source code.  It's not quite to the point you
            make,  but  is  the  only  work  I  know of that explicitly tries to draw from
            sources other than raw code for reuse.

            |Unfortunately, most of the effort in software reusability systems
            |seems to be focused on code software. Ironically, this is the area
            |where the return on investment seems to be the lowest. For example, if
            |analysis and design consume a significantly larger share of the
            |software life-cycle than does coding, reuse of analysis and design can
            |potentially provide significantly greater returns than the mere reuse
            |of code.
            |[...]
            |Given that reuse of analysis and design may potentially provide more
            |benefits than the simple reuse of source code (in fact, may even drive
            |the structure and selection of reusable source code), [...]
                 It  can  go  the  other  way  too.   The  availability  of  reusable code
            components can drive the analysis and design.
                 A  common  mistake in software reusability systems is the assumption that
            the  management  of  software  projects  will  remain  the  same.   If you are
            consciously  striving  to reuse existing software the processes and proportion
            of time spent on these processes will change.
                 For  example,  time  must  now  be  spent  finding and assessing reusable
            components.   This  is  not  accounted  for in traditional software management
            techniques.  If you believe my above statement and also realize that time must
            also be spent on indexing new code for future reusability, I think you can see
            that  SE  techniques  must  adapt to the very different programming techniques
            involved in reusing software.

            1.2.4.  From____ Dick____ Dunn____

            Date: 13 Oct 89 21:07:30 GMT
            From: mailrus!cs.utexas.edu!ico!vail!rcd
              @tut.cis.ohio-state.edu  (Dick Dunn)
            
            eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
            
            > Unfortunately, most of the effort in software reusability systems
            > seems to be focused on code software. Ironically, this is the area
            > where the return on investment seems to be the lowest. For example, if
            > analysis and design consume a significantly larger share of the
 
            Page 202-26                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            > software life-cycle than does coding, reuse of analysis and design can
            > potentially provide significantly greater returns than the mere reuse
            > of code.
                 I'm surprised to see this statement.  Perhaps it's true, but from where I
            sit (in an organization which does a LOT of contract development of software),
            we  re-use bits and pieces all through projects.  We'll start looking at a new
            contract, say at the proposal phase, and realize that it has some major pieces
            which  are  close  to  major  pieces of other contracts we've done.  It's only
            natural  to  find  that,  since  our repeat or referred business is based on a
            reputation established from previous work.
                 It's  important  to  re-use  work  from the front-end phases of projects.
            That's  how  you  improve  your  ability  to  size projects--if you've done it
            before, you *know* how long it will take.

            1.2.5.  From____ Scott_____ Duncan______

            Date: 16 Oct 89 12:32:43 GMT
            From: dduck!duncan@bellcore.com  (Scott Duncan)
            
            In article <16210@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
            >
            >    (in an organization which does a LOT of contract development of soft-
            >ware), we re-use bits and pieces all through projects.  We'll start looking
            >at a new contract, say at the proposal phase, and realize that it has some
            >major pieces which are close to major pieces of other contracts we've done.
            >It's only natural to find that, since our repeat or referred business is
            >based on a reputation established from previous work.
            >
            >Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
            >   ...No DOS.  UNIX.
                 This  brings  up a point that came up when I was talking to people who do
            contracting  for  the US Government.  They felt that, in many instances, reuse
            was  discouraged  for  this very reason.  That is, if a vendor/contractor were
            using  software,  documentation, e.g., anything developed on another contract,
            the  government  agencies  did  NOT  want to have the bid include any cost for
            reuse of such software.  After all, it had been paid for already.
                 Has  your  organization been able to solve this problem in some way or do
            you,  in  fact,  reduce  the  contract  bid  based  on  the  cost saved by not
            redeveloping the software (or whatever other artifacts are reused)?
                 Another  issue  was  reuse  of  software by one contractor which had been
            developed  by  another.   Supposedly  this  could save the government (and the
            contractor  reusing  it) money (and time), but there was no incentive to do so
            because  of  maitenance  issues  and because it actually represented a loss in
            revenue  to  the firm reusing the software since they could NOT charge for its
            redevelopment.
                 It  seems to me that within organizations and between them, the issues of
            who  does  ongoing support for reused software and how reused software will be
            paid for are major, non-technical, stumbling blocks to moving ahead with large
            reuse efforts.
                 What  opinions/experiences do other people have? One contractor suggested
            to  me  that  the  governmment might consider offering a 'reward' for reuse in
            that half the savings would be passed along to the government while half would
            be  divided  equally  between  the developing and reusing organizations.  This
 
            1. Articles                                                        Page 202-27




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            would  provide incentive to both develop reusable software as well as make use
            of it, presumably.

            1.2.6.  From____ Don___ Dwiggins________

            Date: 18 Oct 89 02:26:18 GMT
            From: usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!hacgate!ashtate
              !atsun!dwiggins@ucsd.edu  (Don Dwiggins)
            
            In article <598@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu
            (Edward Berard) writes:
            
               I propose a thread of discussion focusing on the reuse of non-code
               software. Further, I propose that, at least at the start, one of the
               main topics be the reuse of analysis and design, and, more
               specifically, what types of analysis and design products provide a
               suitable granularity (i.e., one which has a high potential for a
               return on investment (ROI)).
                 OK,  I'll  pick  up the thread with a request for setting the parameters.
            It seems to me that the interpretation of the terms "analysis" and "design" is
            less  than  well  settled.  Design, for example, can occur in several settings
            and  at  several  levels;  it  would  be useful to distinguish among them, and
            discuss reusability in the different contexts.
                 With  regard  to  analysis,  I have a question arising from your message.
            Early on, you say that you've

             - conducted research in various aspects of software
               reusability (e.g., domain analysis, ......
                 Later, you say

                   This means that domain analysts (i.e., those charged with identifying,
                   documenting, and configuration managing reusable components) must
                   constantly balance the size of a component against its potential for
                   reuse. They must find both the granularities of components, and the
                   mix of components, which will provide the highest return.
                 I  had  the  impression that "domain analysis" was the sort of thing that
            would  be done for a class of applications intended to run in a common domain,
            to  identify  common  classes  of  data,  algorithms, report types, etc.  Your
            characterization  of the task of a "domain analyst" seems to be more like that
            of a database administrator for a component database.  Where am I confused?

            1.2.7.  From____ Edward______ Berard______

            Date: 18 Oct 89 20:22:01 GMT
            From: sei!ajpo!eberard@pt.cs.cmu.edu  (Edward Berard)
            
            Don Dwiggins (dwiggins@atsun.a-t.com) writes:
            > OK, I'll pick up the thread with a request for setting the parameters.  It
            > seems to me that the interpretation of the terms "analysis" and "design" is
            > less than well settled.  Design, for example, can occur in several settings
            > and at several levels; it would be useful to distinguish among them, and
            > discuss reusability in the different contexts.
            If  you  study  software  engineering  technology,  and  software  engineering
 
            Page 202-28                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            history, several things become apparent:

             1.   The  development  part  of  the  software life-cycle is basically a
                 series of transformations.  Specifically, if a non-technical (in the
                 software  engineering  sense)  user could interact directly with the
                 computer,  without  having to actually develop an application, there
                 would   be   no  need  for  software  engineers  for  many  everyday
                 applications.    However,   users   currently  have  to  go  through
                 intermediaries  (i.e.,  software engineers and their managers).  The
                 job  of  these  intermediaries  is  to  help formulate, clarify, and
                 translate  the  users'  requests  into a form which the computer can
                 understand.    This   formulation,  clarification,  and  translation
                 process  is  what  we  often refer to as the development part of the
                 software life-cycle.
                      Traditionally,  (systems,  requirements,  and/or user) analysis
                 was  the first step in this transformation process.  The idea was to
                 help  both  the  client and the software engineers better understand
                 the  problem  to  be  solved.   One  of  the outputs of the analysis
                 process  was  a description of the system, as it would appear to the
                 client.   Equally traditionally, the process which followed analysis
                 was  referred  to  as  design.  The usual concept was that designers
                 implemented  the  internal  (software)  architecture  of the system.
                 Designers were supposed to discuss things in terms of modules (e.g.,
                 subroutines),  and  other  technical  (from the software engineering
                 perspective)   issues.    Design   was   traditionally  followed  by
                 programming (coding).

             2.   Even  in  the  "good  old  days" people had trouble differentiating
                 between  analysis  and  design.   When  did  analysis stop? When did
                 design  begin?  How  do  I  systematically  take  the  output of the
                 analysis process and use it as the input to the design process? Some
                 people  began  to  realize  that  the  boundaries between life-cycle
                 phases really were fuzzy.

             3.   Some people realized that the development of a software product was
                 more  a  continuous  process than it was a series of discrete steps.
                 Some  even  realized  that  the  distinction  between  the analysis,
                 design,  coding, and testing phases were purely artificial, and were
                 very  often  used  by  management  as  tools  to  control a software
                 development effort.
                      If  you view a software development effort as a huge monolithic
                 entity,  that  means  that  you  may  have  to  invest large sums of
                 resources,  for an extended period of time, with very little idea of
                 what the final results will be.  On the other hand, if you introduce
                 phases into the life-cycle, and specify deliverables for each phase,
                 you  have  much more control over the overall process.  You can make
                 "mid-course  adjustments,"  "go/no  go" decisions at the end of each
                 phase,  spot  trouble earlier, and generally have a much better idea
                 of  actual  progress.  Please note, however, methods, methodologies,
                 deliverables,   well-defined   phases,  and  the  mere  presence  of
                 management do not guarantee success.

             4.   Others  have  observed  that analysis and design, for example, even
 
            1. Articles                                                        Page 202-29




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 take place in the maintenance phase of the software life-cycle.

             5.   There  are  many  different  overall  approaches  to  the  software
                 life-cycle,     e.g.,     waterfall,     spiral,     b-model,    and
                 recursive/parallel.   (In some of my classes, I show people at least
                 six  different approaches.) In object-oriented software engineering,
                 a  very  commonly  used  approach  is  recursive/parallel, sometimes
                 referred  to  as  "analyze  a  little,  design a little, implement a
                 little,  test  a little." Yes, this means that analysis, design, and
                 implementation  may  take  place  at  many  different  points during
                 development.

             6.  Depending on how you view the terms:

             7.   Analysis  and  design  are precursors to coding, and do not involve
                 coding.

             8.   Each  time  a  single  character  of source code is changed you are
                 actually  re-designing.   (Notice  that software maintenance differs
                 from  hardware  maintenance in this respect.  Specifically, hardware
                 maintenance may involve replacing a defective part with an identical
                 part,  whereas  software  maintenance  requires  the introduction of
                 different parts.)

             9.   Analysis  may  involve  analysis of a piece of source code with the
                 intent   of  finding  a  problem,  or  suggesting  optimizations  or
                 extensions.

             10.  Et cetera ...


            > With regard to analysis, I have a question arising from your message.
            > Early on, you say that you've
            >
            >        - conducted research in various aspects of software
            >          reusability (e.g., domain analysis, ......
            >
            > Later, you say
            >
            >    This means that domain analysts (i.e., those charged with identifying,
            >    documenting, and configuration managing reusable components) must
            >    constantly balance the size of a component against its potential for
            >    reuse. They must find both the granularities of components, and the
            >    mix of components, which will provide the highest return.
            >
            > I had the impression that "domain analysis" was the sort of thing that would
            > be done for a class of applications intended to run in a common domain, to
            > identify common classes of data, algorithms, report types, etc.  Your
            > characterization of the task of a "domain analyst" seems to be more like
            > that of a database administrator for a component database.  Where am I
            > confused?
                 I suspect it is in your interpretation of the word "component." I have no
            problem  with  "components"  being "common classes of data, algorithms, report
 
            Page 202-30                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            types, etc." However, I think we can better define what we are after in domain
            analysis.
                 First, we need some definitions:

             1.   "An  investigation  of  a  specific  application area that seeks to
                 identify the operations, objects, and structures that commonly occur
                 in software systems within this area." -- Dan McNicholl

             2.   "Systems  analysis  states what is done for a specific problem in a
                 domain  while  domain analysis states what can be done in a range of
                 problems in a domain.  ...  A domain analysis is only useful if many
                 similar  systems  are  to  be  built  so that the cost of the domain
                 analysis can be amortized of all the systems.
                      "The key to reusable software is captured in domain analysis in
                 that  it stresses the reusability of analysis and design, not code."
                 -- Jim Neighbors

             3.   "A horizontal domain analysis studies a number of different systems
                 across a variety of applications." -- Grady Booch

             4.  "A vertical domain analysis studies a number of systems intended for
                 the same class of applications." -- Grady Booch

                 We can add some more clarifications:

             1.   Domain  analysis  is  not a software life-cycle activity.  It has a
                 beginning,  but, usually, never stops.  It runs in parallel with the
                 life-cycles of many software products.

             2.   Domain  analysts  must identify reusable items in their application
                 domains,  however  they  will  usually be able to classify what they
                 find as:

             3.   reusable, and highly domain-specific, i.e., these items will have a
                 very  low  potential for reuse outside of the defined domain.  These
                 items are usually in the minority of the items encountered.

             4.   reusable, and not specific to the defined domain, i.e., these items
                 will  have  at  least some "horizontal reuse potential." These items
                 are usually in the majority of the items encountered.

             5.   Unfortunately,  many  people  tend to focus on only low-level items
                 (e.g.,  source  code,  object  code, algorithms, data) during domain
                 analysis.   Much larger payoffs are achieved when higher-level items
                 (e.g.,  plans,  standards,  design  products, analysis products) are
                 also considered.

             6.  A domain analyst must not only be familiar with the specific domain,
                 he  or  she  must also be familiar with what they are supposed to be
                 looking  for  (e.g.,  objects  and  classes),  he  or  she must have
                 excellent  abstraction  skills, and he or she must be well-versed in
                 software reusability technology.

 
            1. Articles                                                        Page 202-31




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
             7.   In functional domain analysis, we are looking for things that fit a
                 functional  viewpoint  of  systems  in  our domain.  That is, we are
                 looking  for  reusable  functions,  libraries  of functions, and, in
                 general,  items which will be useful to those software engineers who
                 have  taken  a  functional  decomposition  approach  to the software
                 life-cycle.

             8.   In  object-oriented  domain  analysis,  we are looking for objects,
                 classes,  systems  of  objects, and, in general, items which will be
                 useful  to  software engineers taking an object-oriented approach to
                 the software life-cycle.

                 A  domain  analyst must do much more than simply point to an item and say
            that the item is reusable.  There is much more work to be done.  Without going
            into  a  full-blown  course  on  domain  analysis, some of the things a domain
            analyst can be expected to do are:

             1.  Concisely and precisely define the application domain.

             2.   Identify  a  representative  sample  of applications which span the
                 domain, and use this sample to begin to extract potentially reusable
                 items.

             3.   Accurately  name  and  document each reusable item.  Of course this
                 brings up issues like nomenclature and definitions.

             4.   Clean  up,  parameterize, and otherwise refine potentially resuable
                 items.

             5.   Identify  additional  reusable  items  suggested  by  those already
                 identified.

             6.   Store  and  retrieve  both  the  reusable  items,  and  information
                 associated with the items.

             7.  Develop guidelines for the (re)use of the reusable items.

             8.  Demonstrate reuse using the reusable items and the guidelines.

             9.   Interact  with  all  those  involved  in  the  software engineering
                 process,  e.g.,  requirements  analysts, testers, designers, coders,
                 software  quality  assurance  personnel,  managers,  and maintenance
                 personnel.   The specifics of these interactions are too involved to
                 go into in this short message.

                 There  is  much  more  I  could  say.   (Yes,  I do teach a course on the
            subject.) But this message is already too long.  Thanks for listening.






 
            Page 202-32                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.2.8.  From____ KC__ Burgess_______ Yakemovic_________

            Date: 20 Oct 89 13:51:19 GMT
            From: ncrlnk!ncratl!ncratl2!kcby@uunet.uu.net  (kcby)
                 The   idea   of  reusing  analysis  and  design  components  of  software
            development  efforts  is  very interesting to me.  In fact, as someone who has
            been  involved primarily with the analysis and design "phases" of projects for
            a number of years, it may rank as one of my *major* interests.  :-)
                 Here's  my  problem.   The  information  associated with the analysis and
            design  must somehow be documented, or it can only be reused by the people who
            were  around  when  the  original analysis and design were done.  Typically we
            have  'encoded'  some  of this information in specifications either in English
            (or  other  native language) or by using some diagraming technique.  Actually,
            what  we  have  recorded  is  the  *results*  of the analysis and design.  The
            analysis  and  design  effort took place in meetings, discussions, etc.  which
            may  or may not have been documented through letters, meeting notes, technical
            notes, etc.
                 As  an individual, I have maintained analysis and design information from
            past  projects,  and  have  made  use  of  (some  of) it on new projects.  The
            information  (handwritten  papers, meeting notes, letters, faxs, paper napkins
            with  preliminary  design  diagrams  on  them, etc.) is currently organized in
            chronological  order,  by  project.   As  such,  *I*  can (sometimes) find the
            information  which  I  need  when  it  comes  time  to reuse it, because I was
            responsible for storing it.  However, just having kept the information doesn't
            mean  it  is reusable.  At times I can't find information I know is there, and
            worse,  other  people  (even  when  given  access  to the "paper") haven't the
            foggiest idea where to start, or whether the information is event there.
                 Now a few questions:

             1.   What  would  analysis  and design information look like if I wanted
                 that  information to be reusable by someone other than me? (freeform
                 text?  structured text? defined by a specific methodology? up to the
                 originator?)

             2.  How can it be made accessible? (Linear search through 15+ binders of
                 paper  organized in chronological order and associated with a single
                 project doesn't work!)

             3.   Is  there  enough  reuse possible to justify the (apparently) extra
                 effort  required  to document more than just the results of analysis
                 or design? (That is, how do I convince people who don't even want to
                 write  down the *results* of analysis and design (in specifications)
                 that  they  should  somehow  document  the  information they used to
                 produce the analysis and design specs?)

                 I  hope  the orignal poster will forgive me if this has gotten off of his
            topic somewhat.  But I believe there is at least some relationship involved.






 
            1. Articles                                                        Page 202-33




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.3.  Software________ Quality_______


            1.3.1.  From____ William_______ Thomas______ Wolfe_____

            Date: 12 Oct 89 15:42:31 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
                 From article <16193@vail.ICO.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn):
            > Of course good people will produce better software than bad people. [...]
            > But the professional won't do as good a job as if there were more
            > external interest in quality and less extreme time/money pressure.
                 A  long schedule can provide enough time to get a product almost perfect,
            but   with   very   negative  economic  consequences.   It  is  *management's*
            responsibility to balance quality requirements against other requirements when
            determining the schedule.
                 At  some  point,  the  tradeoff must be made, and the engineers must then
            produce  the  best  possible product within the specified minimum standards of
            quality and the cost and schedule constraints.

            > And what's this about advanced programming languages?  Wolfe has, in other
            > postings, been an outspoken advocate of Ada, which is certainly *not*
            > advanced.
                 Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.

            1.3.2.  From____ Dick____ Dunn____

            Date: 13 Oct 89 20:58:15 GMT
            From: mailrus!cs.utexas.edu!ico!vail!rcd@purdue.edu  (Dick Dunn)
            
            William Thomas Wolfe writes:
            
            >     ...It is
            >     *management's* responsibility to balance quality requirements
            >     against other requirements when determining the schedule.
                 No.   Management  assists  in this.  Management makes the final call, but
            the  engineers  are  a major part of the decision process.  After all, it's an
            engineering exercise to determine how long it takes to do the engineering.
                 Also,  as I've pointed out (ad nauseam for other readers, I suspect), the
            quality  characteristics I've been talking about are not readily quantifiable,
            whereas  the  requirements  I've been talking about are necessarily objective.
            >>In this context<< the phrase "quality requirements" is a contradiction.
                 Note in passing...I had said:

            > > And what's this about advanced programming languages?  Wolfe has, in other
            > > postings, been an outspoken advocate of Ada, which is certainly *not*
            > > advanced.
               ... and Wolfe dodges it:
            >     Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
                 No,  let's  not.  I won't assert that C is advanced.  It's suitable.  Nor
            did  I  assert  that  "advanced programming languages" were essential.  Try to
            answer  the  question, Bill: Are you advocating use of an advanced programming
            language, or are you advocating the use of Ada?
 
            Page 202-34                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.3.3.  From____ Mike____ Lutz____

            Date: 12 Oct 89 21:59:42 GMT
            From: rochester!rit!mjl@louie.udel.edu
            
            In article <6756@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
            @hubcap.clemson.edu writes:
            >From article <16193@vail.ICO.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn):
            >> And what's this about advanced programming languages?  Wolfe has, in other
            >> postings, been an outspoken advocate of Ada, which is certainly *not*
            >> advanced.
            >
            >    Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
                 I'm  into  lingua-snobbery as much as anyone else, but is this really the
            forum  for  it?  And using it to willyhorton someone else's position certainly
            does nothing to give added credibilty to your own.  So let's drop this and get
            back to the interesting quality issues that started this thread.

            1.3.4.  From____ William_______ Thomas______ Wolfe_____

            Date: 14 Oct 89 21:05:41 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
            
            From rcd@ico.ISC.COM (Dick Dunn):
            >>     *management's* responsibility to balance quality requirements
            >>     against other requirements when determining the schedule.
            >
            > No.  Management assists in this.  Management makes the final call, but the
            > engineers are a major part of the decision process.  After all, it's an
            > engineering exercise to determine how long it takes to do the engineering.
                 Engineers  repeatedly  provide  information  as a function of the varying
            constraint parameters which are specified by management.  Management makes the
            decision.  Engineers then comply.
                 Notice: *Engineering* assists.  *Management* DECIDES.

            > note in passing...I had said:
            >> > And what's this about advanced programming languages?  Wolfe has, in
            >> > other postings, been an outspoken advocate of Ada, which is certainly
            >> > *not* advanced.
            >> Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
            >
            > No, let's not.  I won't assert that C is advanced.
                 Glad to hear it.

            > answer the question, Bill:  Are you advocating use of an advanced
            > programming language, or are you advocating the use of Ada?
                 I  advocated  precisely  what  I  said: "advanced programming languages",
            along with CASE tools and so on.  YOU brought up Ada, not I.
                 And I *will* assert that Ada is advanced, within the domain of PRODUCTION
            programming languages; followups to comp.lang.misc if you'd like to pursue it.


 
            1. Articles                                                        Page 202-35




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.3.5.  From____ Dick____ Dunn____

            Date: 19 Oct 89 04:29:03 GMT
            From: ico!vail!rcd@handies.ucar.edu  (Dick Dunn)
            
            Bill Wolfe said, in relation to the ongoing discussion about factoring
            quality into scheduling:
            > >>     *management's* responsibility to balance quality requirements
            > >>     against other requirements when determining the schedule.
                 I  complained  about  the characterizations of engineering and management
            roles:

            > > No.  Management assists in this.  Management makes the final call, but the
            > > engineers are a major part of the decision process.  After all, it's an
            > > engineering exercise to determine how long it takes to do the engineering.
                 There  are some statements about interactions inherent in what I said.  I
            really  mean  that  the  engineers  had  better  *participate* in the decision
            process.   I should have noted that, in addition to the engineering aspects of
            determining  schedule,  you  have  to  keep  the  old responsibility/authority
            equation  in  balance--and  it's the engineers who have the responsibility for
            meeting the schedule.
                 Wolfe counters:

            >     Engineers repeatedly provide information as a function of the varying
            >     constraint parameters which are specified by management.  Management
            >     makes the decision.  Engineers then comply.
                 The  first  part  works,  but  poorly.   The problem is that (in software
            buzzterms)  it  starts  with  a  waterfall model, then wraps a loop around the
            outside.    That   is,  management  provides  constraints,  engineers  provide
            information  in  response--that's  the waterfall pair of steps.  It can take a
            lot of iterations to get a decent answer compared to what happens if you plunk
            engineers  and  managers  down  together  and  let  them  work  on  all of the
            constraints together.
                 As  for the "management decides, engineers comply" - in some sense that's
            what  happens,  but  it's  an  incredibly  poor  choice  of  words.   That is,
            regardless  of  the  actions,  an organization which sees its process in those
            terms is not healthy...it has management problems.

            >     Notice: *Engineering* assists.  *Management* DECIDES.
                 In  a  wider context, this would be very unhealthy.  Engineering does the
            work  in  an  engineering  project,  and  management  assists the engineers in
            getting it done.  (This comes from the observation that the end product is the
            result of engineering effort, not management effort.)
                 But let's not lose sight of the fact that we're talking about setting the
            schedule,  budget,  and  related constraints--this is a different context from
            the  "real work" in the project.  My contention is that even this initial work
            is  substantially an engineering effort.  If engineers are to be involved, you
            don't involve them as "subordinates".
                 A perspective: When someone (even in our company) asks me who I work for,
            I say "Interactive Systems." If I'm then pressed for the name of a *person*, I
            say "Oh, you must mean `Who do I report to?'" and give them my manager's name.
            The  distinction  between  "work  for" and "report to" is important in what it
            says about structure versus control.
 
            Page 202-36                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.3.6.  From____ William_______ Thomas______ Wolfe_____

            Date: 21 Oct 89 20:17:55 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
            
            From rcd@ico.isc.com (Dick Dunn):
            > Bill Wolfe said, in relation to the ongoing discussion about factoring
            > quality into scheduling:
            >> >>     *management's* responsibility to balance quality requirements
            >> >>     against other requirements when determining the schedule.
            >
            > I complained about the characterizations of engineering and management
            > roles:
            >> > No.  Management assists in this.  Management makes the final call, but the
            >> > engineers are a major part of the decision process.  After all, it's an
            >> > engineering exercise to determine how long it takes to do the engineering.
            >
            > There are some statements about interactions inherent in what I said.  I
            > really mean that the engineers had better *participate* in the decision
            > process.  I should have noted that, in addition to the engineering aspects
            > of determining schedule, you have to keep the old responsibility/authority
            > equation in balance--and it's the engineers who have the responsibility for
            > meeting the schedule.
                 This is exactly correct, and here we agree completely.  (See below)

            % Wolfe counters:
            %>     Engineers repeatedly provide information as a function of the varying
            %>     constraint parameters which are specified by management.  Management
            %>     makes the decision.  Engineers then comply.
            %
            % The first part works, but poorly.  The problem is that (in software buzz-
            % terms) it starts with a waterfall model, then wraps a loop around the out-
            % side.  That is, management provides constraints, engineers provide infor-
            % mation in response--that's the waterfall pair of steps.  It can take a lot
            % of iterations to get a decent answer compared to what happens if you plunk
            % engineers and managers down together and let them work on all of the
            % constraints together.
                 But  these  iterations  can occur with everyone in the same room, working
            together.  Management specifies some parameters, engineers provide information
            as to probable cost/schedule requirements, loop until the meeting is over.

            > As for the "management decides, engineers comply" - in some sense that's
            > what happens, but it's an incredibly poor choice of words.  That is,
            > regardless of the actions, an organization which sees its process in those
            > terms is not healthy...it has management problems.
                 No,  it  in  fact  shows that the organization IS healthy.  Engineers are
            not,  and  should  not  be  in  the  business of trying to be, responsible for
            setting  cost and schedule constraints.  They ARE responsible for providing as
            much information as possible to management as it weighs technical and economic
            factors in the process of making the decision.
                 If  engineers were responsible for setting cost and schedule constraints,
            they  would  tend  to  disregard  economic  factors and the organization would
 
            1. Articles                                                        Page 202-37




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            quickly  find  itself  out  of business.  Projects would be technical works of
            genius,  with  complete  formal  specifications  for  each  subprogram or data
            abstraction,  3-D  images illustrating the design, etc., at a cost which would
            result in fatal financial illness for the company.

            >>     Notice: *Engineering* assists.  *Management* DECIDES.
            >
            > In a wider context, this would be very unhealthy.  Engineering does the
            > work in an engineering project, and management assists the engineers in
            > getting it done.  (This comes from the observation that the end product is
            > the result of engineering effort, not management effort.)
                 The  statement  above relates only to the topic at hand, which is "Who is
            responsible  for setting cost/schedule constraints?".  When we move to the new
            and different question, "Who is responsible for delivering the product?", then
            in  THAT context I agree completely, but this has nothing to do with the topic
            at hand.

            > But let's not lose sight of the fact that we're talking about setting the
            > schedule, budget, and related constraints--this is a different context
            > from the "real work" in the project.  My contention is that even this
            > initial work is substantially an engineering effort.  If engineers are to
            > be involved, you don't involve them as "subordinates".
                 Sure  you  do.   Who says superiors and subordinates can't participate in
            the same meeting? Who says superiors and subordinates can't have free and open
            discussions? I don't, and I hope you aren't implying this either.

            1.3.7.  From____ Mike____ Lutz____

            Date: 24 Oct 89 03:22:18 GMT
            From: rochester!rit!mjl@cu-arpa.cs.cornell.edu
            
            In article <6847@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
            @hubcap.clemson.edu writes:
            >From rcd@ico.isc.com (Dick Dunn):
            >> As for the "management decides, engineers comply" - in some sense that's
            >> what happens, but it's an incredibly poor choice of words.  That is,
            >> regardless of the actions, an organization which sees its process in those
            >> terms is not healthy...it has management problems.
            >
            >   No, it in fact shows that the organization IS healthy.  Engineers
            >   are not, and should not be in the business of trying to be, responsible
            >   for setting cost and schedule constraints.  They ARE responsible for
            >   providing as much information as possible to management as it weighs
            >   technical and economic factors in the process of making the decision.
            >
            >   If engineers were responsible for setting cost and schedule constraints,
            >   they would tend to disregard economic factors and the organization would
            >   quickly find itself out of business.  Projects would be technical works
            >   of genius, with complete formal specifications for each subprogram or
            >   data abstraction, 3-D images illustrating the design, etc., at a cost
            >   which would result in fatal financial illness for the company.
                 I  can't  let this one pass, if for no reason than to defend the honor of
            engineers.   I don't think we can (or should) use the Nuremburg defense "I was
 
            Page 202-38                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            only   doing   what  I  was  told."  If  engineers  realize  that  managment's
            requests/requirements/demands  are  impossible to achieve, they have the right
            --  the  obligation  --  to object, if for no other reason than to protect the
            shareholder's interests against the unrealizable plans of management!
                 Like  most  others  who've  been in this business for any time, I've seen
            examples  of  what Bill is talking about.  Still, this was usually due less to
            engineers  violating  budget  and  time  constraints  than  it  was  a lack of
            management direction -- by which I mean setting clear goals for what was to be
            done.   People  fritter their time away when they don't have a clear vision of
            where  they're  going.   But  once goals are established, the engineers should
            have  significant  if not primary control over how to get there.  Most fiascos
            I've  seen  have  resulted  from management inability or unwillingness to face
            facts: what the project would cost and how long it would take.
                 I   have  no  problem  with  management  proposing  budget  and  schedule
            constraints,  but the engineering staff is best qualified to determine whether
            there  is  a  feasible solution within these constraints.  And "feasiblity" in
            this  case  includes adequate time to produce a quality design that has a high
            probability  of successful evolution over the lifetime of the product.  Bill's
            snide  remarks  notwithstanding,  sometimes  this  will mean creating a formal
            spec.   and  a  variety of related models to ensure a well-engineered piece of
            software.
                 In  my  experience,  managers consistently underestimate software product
            lifetime,  possibly  because they base their estimates on hardware development
            models.   When the hardware subsystems are no longer up to snuff, they are are
            often  redesigned  *from  scratch* using the latest technology.  However, most
            organizations work under the implicit assumption that software need *never* be
            redesigned from scratch -- it can always be modified to meet new requirements.
            I  have  in mind several projects I've been involved with over the past couple
            of  years,  where  the  hardware  base evolved in stages from first generation
            mini's  (like PDP8's and Nova 1200's) to 68K's and 80xxx's.  While the current
            processor  boards  and attendant interfaces look nothing like their ancestors,
            the  current  software system architectures still reflect the original designs
            (or lack thereof) from the early 70's.
                 For   those  interested  in  the  issues  surrounding  long-term  product
            evolution,  I  strongly  recommend  Belady & Lehman's book "Program Evolution:
            Processes of Software Change" (Academic Press, 1985, ISBN 0-12-442441-4).  The
            typography  is awful, and I think the proof reading phase was skipped, but the
            ideas and insights are well worth the time it takes to ferret them out.

            1.3.8.  From____ William_______ Thomas______ Wolfe_____

            Date: 29 Oct 89 18:53:08 GMT
            From: hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu
              (William Thomas Wolfe, 2847 )
            
            From mjl@cs.rit.edu:
            >>   [I wrote:] Engineers
            >>   are not, and should not be in the business of trying to be, responsible
            >>   for setting cost and schedule constraints.  They ARE responsible for
            >>   providing as much information as possible to management as it weighs
            >>   technical and economic factors in the process of making the decision.
            >
            > If engineers realize that managment's requests/requirements/demands
 
            1. Articles                                                        Page 202-39




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            > are impossible to achieve, they have the right -- the obligation --
            > to object, if for no other reason than to protect the shareholder's
            > interests against the unrealizable plans of management! [...] Most
            > fiascos I've seen have resulted from management inability or
            > unwillingness to face facts: what the project would cost and
            > how long it would take.
                 Perhaps so, but I think it is a gross misinterpretation of my position to
            imply  that  I  am  suggesting that engineers should not make their objections
            known  to  management.   This  comes  under  the part about "providing as much
            information as possible..."!!
                 Now assume that engineering has made its views known, and that management
            sticks with its decision.  We must consider:

             1.   The  engineers  could  be  wrong.   Management  could  be  taking a
                 calculated  risk  that research efforts taking place in another part
                 of  the  company  will  provide  the tools needed to bridge the gap,
                 management  could be dealing with a group of engineers which largely
                 is  fresh out of college, etc.; we cannot automatically discount the
                 possibility  that  the  management has access to better information.
                 Indeed,  it  is  a  primary function of management to see to it that
                 information  is  considered  on  a  larger  scale  than  simply that
                 information which is visible to a single department.

             2.   What  if  management *is* wrong? Amdahl, I believe, gambled that it
                 would  be  possible to perform wafer-scale integration and lost; but
                 that  does  not  mean  that  such projects should have been met with
                 engineer-level  revolution.   Management  may well have more in mind
                 than simply achieving the direct objectives of the project.

             3.   Engineers are free to resign if they believe the project and/or the
                 company  will  go  down the tubes.  Many good products have resulted
                 from  engineers  deciding  to  form their own company, and I believe
                 that  engineers  should be perfectly free to take this route if they
                 deem  it  appropriate.   Alternatively,  they  can  buy  51%  of the
                 company's  stock  and  then  fire  management.   Or  they can try to
                 convince  upper management or the stockholders that management is in
                 need  of  closer  supervision.   But it is NOT within their realm of
                 options to usurp management's rights and responsibilities.

                 > sometimes [good design] will mean creating a formal spec. and a
                 > variety of related models to ensure a well-engineered piece of software.

                 The  citation did NOT imply that formal specs are not valuable, only that
            a  formal  specification  of  EVERYTHING  is  not presently applicable to many
            situations  due  to  the  great  cost  of specifying things with that level of
            detail.   Clearly,  there are some situations in which the currently extremely
            high costs are justified.






 
            Page 202-40                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.4.  Maintenance___________ and___ Reuse_____


            1.4.1.  From____ Ralph_____ Johnson_______

            Date: 13 Oct 89 13:46:00 GMT
            From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu
              !johnson@iuvax.cs.indiana.edu
                 I'm  a  Smalltalk  programmer.  All Smalltalk programmers are maintenance
            programmers.   That's  because we take reuse seriously.  The average Smalltalk
            programmer  spends  75%  of  the  time  reading  code and only 25% of the time
            writing  code.   Although  this  might  seem like an unproductive use of time,
            Smalltalk  programmers  also  have a reputation of being extremely productive,
            and the two are related.  The fastest way to get good code (as all the readers
            of  this  news  group  probably  know)  is to reuse it.  Reusing code requires
            understanding   it.    Understanding   code  requires  at  least  reading  the
            documentation,  and  sometimes  reading  the  code.   Thus, any system that is
            successful at reuse will make everybody who uses it a maintenance programmer.

            1.4.2.  From____ Satish______ Kumar_____ .C._

            Date: 15 Oct 89 17:26:52 GMT
            From: m2c!umvlsi!chittamu@husc6.harvard.edu  (Satish Kumar .C)
            
            In article <130200014@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
            >
            >Reusing code requires understanding it.  Understanding code
            >requires at least reading the documentation, and sometimes
            >reading the code.
                 I  beg  to differ.  Reusing code requires understanding the *function* of
            the  code  and  not  the  code itself.  If you know precisely what the code is
            supposed to do, then you can reuse it without reading thro' the implementation
            of it.  If reusable code requires us to read thro' its implementation, then in
            my  opinion  it is not truely reusable.  It defeats the very purpose of having
            package  specification  and  module  interfaces.   Reuse is fine.  I am strong
            advocate of it.  But not when I have to read thro' the code.  The only thing I
            would  necessarily need to read is the documentation describing the purpose of
            the code.

            1.4.3.  From____ Ralph_____ Johnson_______

            Date: 20 Oct 89 16:40:30 GMT
            From: swrinde!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive
              !uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
              !p.cs.uiuc.edu!johnson@ucsd.edu
                 chittamu@umvlsi.ecs.umass.edu  begs  to differ with my claim that reusing
            code  requires understanding it, which sometimes requires reading it.  He says
            that we should not have to read code, but only need to understand the function
            of the code.
                 This  is  an  idealist's  position.   Documentation  is almost never good
            enough.  Some people spend most of their time running experiments on libraries
            trying  to  figure  out what they do.  Others junk the libraries.  The systems
            that  are  most  successful  for  reuse usually make source available, because
 
            1. Articles                                                        Page 202-41




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            every  so  often the users need to look at the code.  I know several companies
            that  refuse  to buy libraries of components unless they get source.  It might
            not  be impossible to make libraries that are completely useable only from the
            documentation, but it sure is hard.
                 An  entirely  different  line  of argument is that there is no difference
            between  programs  and program specifications.  Either a program specification
            is  complete  (it specifies everything of interest about the program) or it is
            partial.   If  it  is  complete, then it is a program.  It may be written in a
            language  that  we don't know how to compile efficiently, but that is just the
            inadequacy  of  our compiler technology.  (I *know* about undecideability, and
            it does not change my position.) If it is partial then there will be things we
            need to know about the program that is not in the specification.
                 People  who  must put up with low-level languages can find it hard to see
            that  complete  program  specifications  are  just another way of programming.
            However, I program in Smalltalk at as high a level as possible.  The result is
            that my programs look a lot like the formal program specifications that I have
            read.  Of course, I don't think that Smalltalk is as abstract as it should be,
            but  it is one of the better existing languages for programming at a very high
            level.
                 Smalltalk  has  lots of practical problems that can make it inappropriate
            for  commercial  use.   However,  it  is possibly the best system for software
            reuse.   In  my  opinion,  everybody  who  is seriously interested in reusable
            components should study Smalltalk to see what it did right.  The browser is an
            extremely  important  reason why Smalltalk is good for reuse.  It assumes that
            code  is  readable.   I think this is important, and people who expect to sell
            components  without  providing  source  should  ponder  what  they  must do to
            overcome the fact that their users won't be able to read their code.

            1.4.4.  From____ Joe___ Fitzgerald__________

            Date: Mon, 23 Oct 89 08:14:48 EDT
            From: fitz@ctc.contel.com (Joe Fitzgerald)
            
            m2c!umvlsi!chittamu@husc6.harvard.edu  (Satish Kumar .C) writes:
            
            >In article <130200014@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
            >>
            >>Reusing code requires understanding it.  Understanding code
            >>requires at least reading the documentation, and sometimes
            >>reading the code.
            
            > I beg to differ. Reusing code requires understanding the *function* of
            > the code and not the code itself. If you know precisely what the code is
            > supposed to do, then you can reuse it without reading thro' the
            > implementation of it. If reusable code requires us to read thro' its
            > implementation, then in my opinion it is not truely reusable. It
            > defeats the very purpose of having package specification and module
            > interfaces. Reuse is fine. I am strong advocate of it. But not when I
            > have to read thro' the code.  The only thing I would necessarily need to
            > read is the documentation describing the purpose of the code.
                 I agree that the function of a piece of code is necessary for reuse.  But
            there  are  many  situations  in which the code's function and/or data that is
            being  operated upon are only SIMILAR to your own requirements.  To this point
 
            Page 202-42                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            it  is  open  for debate whether or not one should take the time to understand
            the  code  you have and reuse it, or start from scratch.  I would venture that
            most  (not  all!)  of  today's programmers would opt for the second choice and
            write   their   own   code,   this   being   only  one  manifestation  of  the
            "not-invented-here"   syndrome.    The  point  is,  reuse  sometimes  involves
            adaptation  and  along  with  that  comes  the  responsibility  of reading and
            understanding what you are adapting.

            1.5.  Maintenance___________


            1.5.1.  From____ Travis______ Marlatte________

            Date: 19 Oct 89 01:32:07 GMT
            From: gem.mps.ohio-state.edu!ginosko!shadooby!mailrus
              !accuvax.nwu.edu!delta.eecs.nwu.edu!travis
              @tut.cis.ohio-state.edu  (Travis Marlatte)
                 The  discussion was kind of heading in the direction of using maintenance
            as  a  training vehicle for new engineers.  I think most of us agree that this
            is wrong.  Exposure only to maintenance is probably not the way to bring a new
            programmer up to speed for design.
                 Whoops.   There  I  said  it  again.   The goal is create good designers.
            Somehow, to be a good programmer, I believe one has to become a good designer.
            Even  in  maintenance,  and  we all know I think that job is scum, good design
            techniques  are  paramount to making sound revisions - whether defect fixes or
            enhancements.
                 Contrary  to  my  sarchastic  comment  above, I love maintenance.  I have
            always  been  one to enjoy tearing something apart, figuring out how it works,
            and  how  to make it work better.  I would think that most engineers have this
            same attitude.
                 I  do  think  that  maintenance as a training vehicle is a waste of time.
            The  trainee  learns  nothing  except  how  stupid  past developers were.  The
            company  may  benefit  from  freeing up its more highly prized programmers but
            there certainly is a cost of poorly done maintenance.
                 Actually,  maintenance  is  an  important  part of new design as well.  I
            can't  count  how much time I've saved by striping a piece of code from a past
            product and using it in a new design.  Gosh - reusable software.
                 To reiterate my position - apprenticeships or something similar seem like
            a  pretty  clean way of approaching training.  Note that this does address the
            new  employee  whether novice or experienced.  Some formal program to help the
            experienced  programmer  fit  in  with the company is just as appropriate as a
            formal program to bring the novice up to speed.
                 A few comments on licensing: (are you out there Ms.  Richards?) Licensing
            does  not  prove  competence  or ability.  It merely transfers liability.  And
            that  usually  doesn't work either.  Licensing should mean nothing to a fellow
            programmer  (or  engineer).   It  is  only a stamp of approval from a publicly
            recognized body and it is for the benefit of the public.
                 Licensing  can  only be used as a first defense against blithering idiots
            passing themselves off as professional programmers.  I am quite confident that
            the  programmers  responsible  for  recent widely publicized software failures
            were  nothing  but  professionals and would have gained a license if such were
            required.

 
            1. Articles                                                        Page 202-43




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.5.2.  From____ Robert______ Osborne_______

            Date: 19 Oct 89 21:00:25 GMT
            From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!censor
              !isgtec!robert@tut.cis.ohio-state.edu  (Robert Osborne)
            
            In article <1337@accuvax.nwu.edu> travis@delta.eecs.nwu.edu
            (Travis Marlatte) writes:
            >The discussion was kind of heading in the direction of using maintenance
            >as a training vehicle for new engineers. I think most of us agree that
            >this is wrong. Exposure only to maintenance is probably not the
            >way to bring a new programmer up to speed for design.
                 I  think  a  small  bug  or new piece of functionality is the best way to
            bring  somebody up to speed.  The new engineer MUST be guided by a experienced
            engineer throughout this experience.  However, leaving somebody in maintenence
            for a long time is probably a good way to kill morale and enthusiasm.

            >I do think that maintenance as a training vehicle is a waste of time. The
            >trainee learns nothing except how stupid past developers were.
                 The  key  is  to  make the trainee *SEE* what bad design, habits, styles,
            whatever  do to a maintenance effort, and just what bad design etc.  *IS*.  Of
            course  if  the  trainee  is  modifying  my  stuff  they  get  to  see a great
            implementation of a good design :-).

            >Actually, maintenance is an important part of new design as well. I can't
            >count how much time I've saved by striping a piece of code from a past
            >product and using it in a new design. Gosh - reusable software.
                 Exactly,  get  them to explore the system and see what there is out there
            for them to steel.

            >A few comments on licensing:
            >[...] It merely transfers liability. [...]
            >[...] It is only a stamp of approval from a publicly
            >recognized body and it is for the benefit of the public.
                 It  also  gives you somebody to pin the blame on and to sue :-(.  Like an
            civil  engineer  (at  least  in  Ontario) must stamp building plans, and if it
            falls down they catch it (bad pun intended :-).

            1.5.3.  From____ Lee___ Sailer______

            Date: 20 Oct 89 16:34:15 GMT
            From: psuvm!uh2@psuvax1.cs.psu.edu  (Lee Sailer)
                 One hears the phrase, "Maintenance through redesign." The idea is that to
            modify  a  program,  one goes back to the analysis and design documents, e.g.,
            Data  Flow  Diagrams,  Logical  Data Models, Structure Charts, or whatever and
            makes  the modifications there, moving step by step through the entire process
            til the coding stage is reached.
                 On  the  other  hand, to many practitioners, maintenance means jumping in
            and hacking the code.
                 It  seems to me that the first type of M-- would be very educational, and
            a good way to bring a new hire up to speed on local customs, the nature of the
            system, and so forth.

 
            Page 202-44                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.5.4.  From____ Kevin_____ W._.  Wall____

            Date: 3 Nov 89 03:44:30 GMT
            From: att!cbnews!kww@ucbvax.Berkeley.EDU  (Kevin W. Wall)
            
            In article <1337@accuvax.nwu.edu> travis@delta.eecs.nwu.edu (Travis Marlatte)
            writes:
            
            >I do think that maintenance as a training vehicle is a waste of time. The
            >trainee learns nothing except how stupid past developers were.
                 I disagree; I think it is *valuable* that trainees "learn how stupid past
            developers were".  The reason:
                      We are usually blind to our own mistakes, but not to the mistakes of
                 others.
                 I  find  this  an  excellent  way  to point out bad habits in a trainees'
            programming style.  (Remember the story of not removing the splinter from your
            colleague's eye until I have removed the plank from my own?) I learned as much
            looking at "bad" code, as I did looking at "good" code.
                 Trainees  "fresh  out  of  grad  school"  seldom  (ever?) have to go back
            several years later and make changes to their own code (which are usually only
            simple,  toy  programs  anyway).   Fifty percent or more of the total software
            life-cycle is made up of the maintence phase, yet this is one aspect where our
            CS  departments have failed us miserably.  Approaching an existing 50,000 line
            software  system which you neither designed nor wrote is a WHOLE LOT DIFFERENT
            than  writing  a 5,000 line program from scratch.  Just once I'd like to see a
            homework assignment in some CS course be something like
                 "add  features X and Y to this 60,000 software system (which the students
            have never seen before) and turn it in next week".
                 The  "discovery  process"  (i.e., figuring out how a particular design or
            piece  of  code  (mis)behaves involves a entirely different set of skills than
            does  the  "creation  process".   Yet  no  formal  training  is  given for the
            "discovery process", which is so vital to the maintenance phase of software.

            >Actually, maintenance is an important part of new design as well. I can't
            >count how much time I've saved by striping a piece of code from a past
            >product and using it in a new design. Gosh - reusable software.
                 Exactly!  But  of  course  "code stealing" (or "stealing" of any kind) is
            another  thing which is strongly discouraged in traditional education.  Yet to
            really be successful in the real world, "code stealing", design stealing, etc.
            is ESSENTIAL.  I don't know how many green horns fresh out of grad school I've
            worked  with  who  wasted needless company time writing the own sort function,
            hashing  functions, DBMS, etc.  because 1) they weren't aware that stealing is
            an  encouraged/expected  part  of the culture, or 2) they weren't aware of the
            existence  of  these  packages,  or 3) they thought they could do a better job
            than  what  was  available  from  standard libraries or commercial vendors (of
            course, sometimes they do; but usually not).
                 <<>> Now for the inflamatory remark...  IMHO, I
            think  a  large  part of the blame for the software crisis has to be placed on
            the  shoulders  of  the  formal  education  system.   To  put  it  bluntly, CS
            departments  are  not  teaching  the  necessary  skills  to  be  successful in
            industry.   (They  do  however, teach the necessary skills to be successful in
            academia.)  If  they  ARE  teaching  the necessary skills, perhaps someone can
            comment  on why it is that many of the folks that have had little or no formal
 
            1. Articles                                                        Page 202-45




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            software  education  (1 or 2 yrs undergrad or associate degree at the max) can
            run circles around many of the supposedly brightest M.S.  and Ph.D.  graduates
            in  computer  science? Not only in the area of coding, testing, designing, and
            debugging,  but also in common sense.  I've seen this happen too many times in
            my past 10 yrs here to believe that it is just coincidence.
                 A  colleague  of  mine  who attended a Demming (the quality guru) lecture
            said  that someone in the audience remarked that "Bell Labs only hires the top
            10%  of  all  the  graduates" (implying "how could they have all those quality
            problems?").   Demming replied, "well, the deserve what they get".  Perhaps he
            had a valid point.
                 Now  let me clarify one thing before my E-mail box overflows...  I am NOT
            saying  or even implying that current CS curricula is not valuable.  What I AM
            trying  to  say  is  that I think it could be a LOT more relevant (to the real
            world, vs.  the academic world).
                 Of  course,  my opinions do not necessarily reflect those of my employer.
            (...fortunately for me, since I was 1 of those top 10% of the villagers.  :-)

            1.6.  Seeing______ Component_________ Source______ Code?____?


            1.6.1.  From____ Bruce_____ Weide_____

            Date: 20 Oct 89 21:35:00 GMT
            From: elephant.cis.ohio-state.edu!weide@tut.cis.ohio-state.edu  (Bruce Weide)
                 Occasionally  something  goes  by  on this newsgroup that cries out for a
            response.   Case  in  point:  Recently  Ralph Johnson made an argument that in
            order  to reuse a software component, one must be able to see its source code.
            The  essence  of  his  case  seemed  to  be:  (1)  Writing  formal  behavioral
            specifications for components is hard.  (2) A complete formal specification IS
            a   program.    (3)  Smalltalk  programs  he  has  written  look  a  lot  like
            specifications  he  has  seen.  Therefore, why not just stick with source code
            and   forget   formal  specifications?  Or,  perhaps,  why  not  write  formal
            specifications  but  still  provide source code just in case? (I couldn't tell
            for sure what the conclusion was.  These seemed likely candidates.)
                 (1) Writing formal behavioral specifications for components is hard.
                 Here there is no disagreement.  Fortunately, one of the nice things about
            reusable  components  is  that  relatively few people need to be able to WRITE
            specifications.   Lots  of people need to be able to read them.  This suggests
            that,  while writing specifications is presently difficult, we really ought to
            be  working on specification methods and languages that also emphasize ease of
            understanding.   Of  course  it  will also help to improve the ease with which
            specifications are written.  Both areas call for further work.  But one should
            not  conclude  from  the  fact  that  specs are hard to write NOW that it must
            always  be  so.   Nor  should  one  conclude that they are necessarily hard to
            understand.   In  fact I think we already have the concepts necessary to write
            comprehensible  formal specifications of non-trivial components, and plenty of
            anecdotal  evidence that both CS students and practicing software engineers in
            industry  can  understand them; I have previously commented on such techniques
            in  this  forum.   (By  the  way, I don't think Ralph was really claiming that
            formal  behavioral  specifications  are  INHERENTLY  IMPOSSIBLE  to  write  or
            INHERENTLY  DIFFICULT to read and understand, which seems to be what is needed
            to  support  his argument.  If that is the claim it's going to be difficult to
            defend.)
 
            Page 202-46                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 (2) A complete formal specification IS a program.
                 On  this  point  there  may  be  some  grounds  for disagreement.  Formal
            specifications   for   a   component   will   in   general   be  abstract  and
            implementation-neutral,   i.e.,   they  will  hide  both  representation  data
            structures  and  algorithms used in the component's implementation, explaining
            behavior   in  abstract  terms,  and  admitting  of  multiple  plug-compatible
            implementations.   Specifications say WHAT the component does, not HOW it does
            it.   Now  there's  a hell of a gap between such specifications and the source
            code  for an implementation in an algorithmic language.  To claim that this is
            "only"  a  compiler  technology  issue  -- that a smart compiler can invent an
            acceptable  (in  performance) implementation from such abstract specifications
            -- is a remarkable leap of faith that flies in the face of reality.
                 (3)  Smalltalk  programs Ralph has written look a lot like specifications
            he has seen.
                 Perhaps  Ralph's  real claim in (2) is that one might simply consider the
            specifications  to  BE  the  source  code.   I  can  only  suggest  that  such
            "specifications"    are   inappropriately   named.    If   they   reveal   any
            representational  or  algorithmic  details of HOW the component works they are
            not  specifications by the above definition.  I'm not fluent in Smalltalk, and
            maybe  Ralph's  programs  look  a lot different from Smalltalk code I've seen.
            But those samples don't look much like formal specifications to me.
                 SUMMARY  -  Can we agree on the general definition, the nature/purpose of
            formal  "specifications":  to say WHAT the component does? Can we agree on the
            nature  of  "source  code": to say HOW it does it? Can we agree that these are
            not  the  same thing? If so, I think we ought to be able to agree on something
            about  the  nature  of  reusable components in a (future?) software components
            industry: There is no reason in principle that a client programmer should need
            to  examine  component  source  code in order to understand what the component
            does.
                 If  we  can't  agree  on  the  above  definitions,  we'd  better move the
            discussion back to that issue.

            1.6.2.  From____ Ralph_____ Johnson_______

            Date: 25 Oct 89 00:11:25 GMT
            From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu
              !ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
              !p.cs.uiuc.edu!johnson@tut.cis.ohio-state.edu
                 I  argued that to reuse a software component, one must be able to see its
            source  code,  and  that  it was a mistake to think that formal specifications
            were going to solve the problem.
                 Bruce Weide summarized my argument as

             1.  Writing formal behavioral specifications for components is hard.

             2.  A complete formal specification IS a program.

             3.   Smalltalk  programs  I has written look a lot like specifications I
                 has seen.

                 It  is  always interesting to see how others interpret my words.  I don't
            think  (1)  is a crucial point.  (2) is crucial, and (3) is just there to back
            up  (2).   In  fact,  I  don't  think  that Smalltalk is at all unique in this
 
            1. Articles                                                        Page 202-47




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            regard.   For  example,  the  first  Ada  compiler was written in SETL and was
            really  more  of a specification for Ada, or a design of an Ada compiler, than
            it  was  a "real program".  Although it was executable, it only compiled a few
            lines per minute.
                 My  last  message  elaborated  on (2).  However, I've been thinking about
            (1).  I'd like to say some provocative things.
                 First,  to the best of my knowledge, nobody has written formal behavioral
            specifications  for  a real component library.  There was a group at Tektronix
            that was using Z to specify a few Smalltalk classes, and there is a group here
            at  Illinois  that  is  using  Z  to  specify  a few classes from a library of
            operating  system  classes  written  in  C++,  but neither of these groups are
            dealing  with  more than a few classes.  There is also the Larch group at MIT,
            though  I  haven't  seen  anything  from them dealing with real libraries.  It
            seems to me that the burden of proof is on the side of those who claim that it
            is reasonable to expect to have formal specifications for component libraries.
            I would love to be proved wrong.
                 I  am  not one of those who think that formal specifications are useless.
            Quite  the  contrary,  I  demand  that my students take courses in programming
            language  semantics and program verification, and I studied both when I was in
            graduate  school.   However,  so  far  the  effect of these topics on computer
            science  has  been  indirect.  They have helped us invent better languages and
            learn  to  think  about  programming  better,  but they have had little use in
            commercial  programming.  Perhaps this will change soon, but I see little sign
            of  it.   There  are  too  many  unsolved  problems,  like how to reason about
            pointers.   On  the  other  hand, I am greatly in favor of more research being
            done on the problem and wish that the area was funded a lot better than it is.
            It  is  an  important problem, and one worthy of the attention of many people,
            but  it  is an area that offers many interesting research topics, not one that
            offers ready-made solutions to current practical programming problems.

            1.6.3.  From____ Ralph_____ Johnson_______

            Date: 25 Oct 89 00:11:21 GMT
            From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu
              !ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
              !p.cs.uiuc.edu!johnson@tut.cis.ohio-state.edu
            
             weide@elephant.cis.ohio-state.edu said
            >Occasionally something goes by on this newsgroup that cries out for a
            >response.
                 Naturally, I was trying to get a response! I'm glad I succeeded.
                 There are lots of things I could say in response, such as I disagree with
            the  idea  that it is irrelevant how hard it is to make reuseable code because
            the  cost  will be amortized later.  However, the main point that I was trying
            to  make  was  that in practice there is no real difference between a complete
            specification  of  what behavior a component has and a specification of how it
            is implemented.  In other words, I think that the generally well accepted idea
            that  "Formal  specifications  for a component will in general be abstract and
            implementation-neutral,   i.e.,   they  will  hide  both  representation  data
            structures  and  algorithms used in the component's implementation, explaining
            behavior   in  abstract  terms,  and  admitting  of  multiple  plug-compatible
            implementations"   is  wrong.   It  is  only  correct  for  specifying  tricky
            algorithms,  i.e.   fast, complex algorithms for problems that also have slow,
 
            Page 202-48                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            simple  algorithms.   It is certainly false for most real code, which consists
            of mostly user interface.  Moreover, to the extent that it is true, it is also
            true of programs written in very-high-level languages.
                 There is certainly a wide semantic gulf between formal specifications and
            Pascal  programs.   This  is  irrelevant  to  the  claim  that there is a wide
            semantic  gulf  between  formal  specification  languages  and ALL programming
            languages.   For  example,  there are many formal specification languages that
            are  executable.   Thus,  these  specification  languages are also programming
            languages.   More  to the point I am trying to make, real high-level languages
            (i.e.   not Pascal or C) can look very much like specification languages.  For
            example, compare these specifications of stacks.

            class stack
             sequence elements;
            push(elem) = {elements := elements, elem}
            pop() = {elements := elements(1:(elements.size-1)}
            top() = {return elements.last}
            empty() = {return elements.size = 0}
            
            or
            
            pop(push(elem,S)) = S
            top(push(elem,S)) = elem
            empty(push(elem,S)) = false
            empty(newstack()) = true
                 The second (the "abstract" specification) is shorter, but not much easier
            to  read.  Most importantly, it is not easier to understand.  Thus, I claim it
            is no better as a specification than the first.
                 Stacks  are  about the easiest component for which one can write a formal
            specification.   However,  a  better  example  to show the strengths of formal
            specifications  would  be  sorting, since the specification is that the output
            sequence  is  a permutation of the input sequence and that the output sequence
            is  sorted,  while  most  fast  sorting  algorithms take a lot of more code to
            express.   This  is  an  example of a problem for which there exists both fast
            complex  algorithms and slow simple algorithms.  The specification I described
            corresponds  to  the  sorting algorithm that takes each permutation and checks
            whether  it is sorted.  This simple specification could be represented just as
            well by a program.
                 To  raise  a  last point, we probably disagree on what a component is.  I
            don't  believe  in  the  mythology  that  we  will be able to reuse components
            without  changing  them.   It  is very hard to predict how people will want to
            change  components,  so  it  is  very  hard  to know what information to hide.
            Components  include  abstract  classes  and  frameworks, which are really just
            partial  programs.   This  makes it even harder to make provide specifications
            that are different from the code, significantly simpler, and useful.








 
            1. Articles                                                        Page 202-49




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.6.4.  From____ Bruce_____ Weide_____

            Date: 25 Oct 89 22:08:00 GMT
            From: elephant.cis.ohio-state.edu!weide@tut.cis.ohio-state.edu
              (Bruce Weide)
                 Ralph   Johnson's   recent   comments   about   the  differences  between
            specification and implementation call for a few more comments and questions of
            clarification.
                 (1)  Ralph  gives  an  example  of  a simple implementation of stacks and
            simple  algebraic  specification,  and  concludes: "The second (the "abstract"
            specification)  is shorter, but not much easier to read.  Most importantly, it
            is not easier to understand.  Thus, I claim it is no better as a specification
            than the first."
                 I'm  not  sure  I understand the point of this example, except that it is
            POSSIBLE  for  an  implementation  to  be  about as short and as simple as its
            formal  specification.   No  argument there.  But the claim that the algebraic
            specification  is "THE abstract specification" is too strong.  There are other
            well-known  specification methods that, we would both apparently agree, render
            specifications  easier  to  comprehend  than  the  algebraic  approach.   Such
            specifications  remain  abstract  but  do  not  rely on using equations, as in
            Ralph's  example.   Such  alternative  specification  methods should result in
            easier-to-understand specifications of stacks.
                 Admittedly  these  alternatives  might look on the surface very much like
            Ralph's  source  code  (for  this  example  but not in general).  But they are
            subtly  and  importantly  different  in  meaning  precisely  BECAUSE  they are
            abstract.    One  might,  for  example,  use  a  mathematical  sequence  as  a
            mathematical model of a stack.  But there would be no implication that program
            sequences  are used in the implementation, as apparently Ralph has done in his
            code.   This  is  important for lots of reasons, upon which I can elaborate if
            the discussion continues along this line.
                 (2)  Ralph  continues:  "Stacks are about the easiest component for which
            one  can  write a formal specification.  However, a better example to show the
            strengths  of  formal specifications would be sorting, since the specification
            is  that  the  output sequence is a permutation of the input sequence and that
            the  output  sequence is sorted, while most fast sorting algorithms take a lot
            of  more  code  to  express.   This is an example of a problem for which there
            exists   both  fast  complex  algorithms  and  slow  simple  algorithms.   The
            specification I described corresponds to the sorting algorithm that takes each
            permutation  and checks whether it is sorted.  This simple specification could
            be represented just as well by a program."
                 The  general  claim here seems to be that for a reusable component with a
            compact  formal specification, there is also a simple but possibly inefficient
            ALGORITHM  that is its implementation and that, to some people at least, would
            be  easier  to  understand.   This  seems unlikely at best.  Consider a simple
            example.   Suppose  you  have  a component that keeps track of a function from
            some  domain  type  D to some range type R (both parameters to the component).
            You want to specify a boolean-valued operation that returns "true" given f and
            r  iff  function f maps some value of type D to the specific value r.  This is
            easy  to  specify  in  the abstract using an existential quantifier; something
            like:

                                 there exists d:D such that f(d) = r
                 Presumably the source code to explain this behavior consists of a program
 
            Page 202-50                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            to search through all values of type D for one that f maps to r.  Two problems
            here.   First,  D may not be finite, in which case this is not an algorithm at
            all  because it may not terminate and could never return "false".  Second, how
            do  you write this program (except in pseudocode or something) without knowing
            what type D is?
                 But  Ralph  has  provided  a  good  idea here: to challenge specification
            writers to design and specify a component that permits one to do sorting.  I'm
            happy  to  oblige,  and  will post such specs to this forum if asked to do so.
            But  we should also be able to see the "simple specification" mentioned in the
            last sentence above for comparison purposes relative to ease of understanding.
            A  biased  audience,  readers  of  this  forum,  but  we  might  get some info
            nonetheless.
                 Of  course, comparisons on other grounds (e.g., ease of verification that
            alternative  implementations meet the specs; whether the spec method helps one
            design  a good reusable component in the first place; lots of other questions)
            might be too difficult to carry out in this forum.  But it would be a start at
            seeing whether people might prefer to see source code or formal specifications
            for their reusable components.

            1.6.5.  From____ Bruce_____ Weide_____

            Date: 25 Oct 89 22:23:48 GMT
            From: elephant.cis.ohio-state.edu!weide@tut.cis.ohio-state.edu
              (Bruce Weide)
                 Ralph  Johnson's  second  reply  to  the  question of the place of formal
            specification was very interesting.
                 I'd  like  to  add our group to his list of those who have written formal
            specifications  for  "real" components.  Ralph, I'll send you a few reports if
            you  wish;  just  drop me a note.  I wish I could cite a bunch of papers we've
            had  published  but  few people seem to want to hear what we're trying to say.
            That's  one  of  the reasons we think this newsgroup is so important: at least
            the  people  here  have  not already abandoned the idea that reusable software
            components  might  someday become practical.  Nor are they convinced that they
            already know the one-and-only way to do something.
                 That  leads  to  Ralph's  claim  that one of the deficiencies in relating
            formal  specification,  verification  --  formal methods in general -- to real
            programming  is  the  difficulty of dealing with pointers.  How true!!! Again,
            all  I  can  say  is  that  we  have  done quite a bit of work on this, but it
            generally  falls  on deaf ears.  Many people can't imagine programming without
            pointers  sticking  out  of  everything,  so don't even bother suggesting that
            pointers  spell  trouble.   But  this  is another important reason that formal
            specifications are important and that you don't want to look at source code to
            try  to understand a component's behavior.  By making specifications abstract,
            one  can  shield  a client of a reusable component from all the pointer tricks
            that often need to be played in the implementation in order to implement it at
            all, and certainly to make it efficient.
                 I  guess  the  bottom  line  is  that  Ralph might grant that, if certain
            technical  problems could be solved, there might be some hope for substituting
            formal  specifications  for source code as descriptions of component behavior.
            Ralph, if I've misrepresented your position on this, please advise.



 
            1. Articles                                                        Page 202-51




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.6.6.  From____ John____ Hogg____

            Date: 26 Oct 89 00:29:42 GMT
            From: cs.utexas.edu!mailrus!jarvis.csri.toronto.edu!db.toronto.edu
              !hogg@tut.cis.ohio-state.edu  (John Hogg)
                 Ralph Johnson has claimed that every specification is a program, and this
            statement has been challenged by other posters.  Since I take it as an article
            of faith myself, I'll try to clarify it.
                 No  specification or program by itself does anything, except take up disk
            space.   A  program  (as  we  all  learned  at  a tender age) is a sequence of
            instructions.  These instructions must be executed by (in cases of interest to
            us)  a  computer.   And  the  code  we  see is seldom executed directly; it is
            normally  processed by a compiler and friends.  Therefore, when we speak about
            executing  a program, we implicitly acknowledge the existence of large amounts
            of  hardware,  software  and  cleverness,  which make up our program execution
            engine.
                 Specifications  are  not generally executed, and therefore the market for
            specification language engines is thin.  However, in principle, such an animal
            is  quite  possible.   A  specification  defines  the set of acceptable output
            states  for  a  given  input  state.  (I'll certainly accept other flavours of
            specification,   but   similar  arguments  can  be  made.)  To  implement  the
            specification,  simply  enumerate  the  domain  of  output  states  until  one
            satisfying  the  postcondition  is  found.   Or,  if you prefer, select states
            nondeterministically until satisfaction.  If the specification is satisfiable,
            then the specification engine will terminate, albeit in unbounded time.
                 Bruce  Weide  gave  a  description  of a specification which he claims is
            unimplementable:

            >Suppose you have a component
            >that keeps track of a function from some domain type D to some range
            >type R (both parameters to the component).  You want to specify a
            >boolean-valued operation that returns "true" given f and r iff
            >function f maps some value of type D to the specific value r.  This is
            >easy to specify in the abstract using an existential quantifier;
            >something like:
            >
            >        there exists d:D such that f(d) = r
            >
            >Presumably the source code to explain this behavior consists of a
            >program to search through all values of type D for one that f maps to
            >r.  Two problems here.  First, D may not be finite, in which case this
            >is not an algorithm at all because it may not terminate and could
            >never return "false".  Second, how do you write this program (except
            >in pseudocode or something) without knowing what type D is?
                 This  isn't quite fair, because he's given a specification of a component
            or  function  g  without  specifying  the  function  f  that it uses.  If f is
            specified,  then  we  can  enumerate through the range of g ({true, false}) in
            quite acceptable time.  The specification of f is executed in the same manner.
                 The  only  reason that implementations are somehow more ``concrete'' than
            specifications,  then,  is  that  we've  gone  to  the trouble of building the
            program  execution engines.  Specification engines would actually be easier to
            build in some ways, because we can be totally uninterested in performance.
                 So   both  specifications  and  implementations  are  descriptions  of  a
 
            Page 202-52                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            computation,   which  merely  differ  in  undescribed  side  effects.   Formal
            verification  is  just  the  process  of  showing  that  the  two  are in fact
            equivalent.   The  advantage  of  the  implementation  is its efficiency.  The
            advantage  of the specification *should* be its clarity.  If the specification
            is  no  clearer  than  the  implementation, then it is of academic interest at
            most.
                 My  PhD thesis, by the way (Extremely Real Soon Now) is on the subject of
            specification  and  verification of object languages.  This should make me the
            world's greatest booster of component selection by specification alone.  Well,
            the  work  is  worth  doing so that giants can step on my shoulders.  However,
            we're  a long way from modular, sound, and complete object specifications, let
            alone  ones  that  are  easier  to  read  than the source.  (Those who wish to
            challenge  this  statement  are invited to do so by mail.  Note that the claim
            has four adjectives and a noun that require precise definitions.)
                 Probably  the main advantage of formal specifications is that they can be
            used  to  prove  that  if  sub-components  meet  their  specifications,  their
            component  sum will too.  But that's a property of an associated proof system,
            not the specification language per se.

            1.6.7.  From____ George______ Mitchell________

            Date: 25 Oct 89 12:51:23 GMT
            From: snorkelwacker!spdcc!merk!alliant!linus!community-chest
              !mitchell@tut.cis.ohio-state.edu  (George Mitchell)
                 Until  your  last  posting  you were only getting close, but now you have
            really "pushed my button".

            In article <130200016@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
            >
            >To raise a last point, we probably disagree on what a component is.
            >I don't believe in the mythology that we will be able to reuse
            >components without changing them.  It is very hard to predict how
            >people will want to change components, so it is very hard to know
            >what information to hide.  Components include abstract classes and
            >frameworks, which are really just partial programs.  This makes it
            >even harder to make provide specifications that are different from
            >the code, significantly simpler, and useful.
            >
                 At  OOPSLA  '89  the  statement was made (I wish that I had said it) that
            modifying  [code/component]  was  not  reuse but recycling.  Since the cost of
            producing  code  is  a  small portion of the total lifecycle cost, the goal of
            reusing complete components should not be so quickly abandoned.  The potential
            savings  in  testing  and  maintenance are well worth while.  If this requires
            extensive   domain   analysis,   system   designs   constrained  by  component
            availability, and use of languages supporting inheritance, the benefits should
            usually be well worth the sacrifices.







 
            1. Articles                                                        Page 202-53




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.6.8.  From____ Bruce_____ Weide_____

            Date: 26 Oct 89 15:51:14 GMT
            From: elephant.cis.ohio-state.edu!weide@tut.cis.ohio-state.edu
              (Bruce Weide)
            
            I recently suggested an operation that I claimed could be more easily
            specified abstractly than by giving source code for an implementation:
             ">Suppose you have a component
              >that keeps track of a function from some domain type D to some range
              >type R (both parameters to the component).  You want to specify a
              >boolean-valued operation that returns "true" given f and r iff
              >function f maps some value of type D to the specific value r.  This is
              >easy to specify in the abstract using an existential quantifier;
              >something like:
              >
              >       there exists d:D such that f(d) = r
              >
              >Presumably the source code to explain this behavior consists of a
              >program to search through all values of type D for one that f maps to
              >r.  Two problems here.  First, D may not be finite, in which case this
              >is not an algorithm at all because it may not terminate and could
              >never return "false".  Second, how do you write this program (except
              >in pseudocode or something) without knowing what type D is?"
                 John   Hogg   has   subsequently   suggested  that  I  claimed  that  the
            specification "was unimplementable." Sorry for the confusion; this is not what
            I  meant  to imply.  It is quite implementable.  It's just that the "obvious,"
            and therefore presumably easy-to-understand implementation that would make the
            "source  code  specification"  of  behavior  simple,  is not in fact a correct
            implementation.
                 John  goes  on  to  say:  "This  isn't  quite  fair, because he's given a
            specification  of  a component or function g without specifying the function f
            that it uses.  If f is specified, then we can enumerate through the range of g
            ({true,  false}) in quite acceptable time.  The specification of f is executed
            in the same manner."
                 Perhaps  I wasn't being clear enough, or I don't understand John's point.
            The  reusable  component  I  have  in  mind  provides  a  type  whose ABSTRACT
            MATHEMATICAL  MODEL  is a function from D to R; let's call it type "foo" so we
            don't  confuse  it  with  a  program  function.   The  component also provides
            operations  that  permit  the  client to construct a foo, and also provides an
            operation that asks the question above: for the foo variable f (which has been
            constructed in this way), does any value of its domain map to r? The specified
            doesn't know what mathematical function models f.  All he/she knows about f is
            that  it  has  been constructed by the client using the operations provided by
            the component to operate on variables of type foo.  The fact that the abstract
            specification  of  this  component  may  talk  about  f  as  though  it were a
            mathematical  function is what makes the abstract specifications simple.  That
            source  code  doesn't have this abstract view of f is what, I claim, will make
            writing  "source  code  specifications" more difficult and make them harder to
            understand.  (Not impossible, just clumsier.)
                 Overall  I  agree  with most of John's points, and in particular with his
            view  of  what  verification  is  all about and what properties it should have
            (modularity,  soundness,  etc.).   This  is another reason for having abstract
 
            Page 202-54                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            specifications.   If one wishes to reason about the correctness of programs --
            whether  they  meet  their  specifications  -- one should probably draw on the
            ready  supply  of techniques, notations, and concepts of mathematical logic to
            do  this  reasoning.   Having  abstract specifications, for both the component
            being implemented and the components its implementation uses, seems to support
            this  approach  directly.   Reasoning  about  the relationships among concrete
            implementations  of components would seem, by comparison, to be more likely to
            cause  problems  when  issues  of  soundness, relative completeness, etc., are
            considered.  Again, I'm not claiming that it would be impossible to do it that
            way, just that the abstract approach seems more promising from here because it
            "reuses" what mathematicians have already done.

            1.6.9.  From____ Ralph_____ Johnson_______

            Date: 27 Oct 89 11:05:00 GMT
            From: tank!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
              !p.cs.uiuc.edu!johnson@handies.ucar.edu
                 I  guess I don't really believe that "if certain technical problems could
            be solved, there might be some hope for substituting formal specifications for
            source code as descriptions of component behavior." That might be true, but it
            remains to be seen.
                 It  is  pretty  hard  to  *prove* my opinion.  Even if we haven't started
            using  formal  specifications a hundred years from now, the solution might lie
            right around the corner.
                 So  far,  we  have  been  debating  my claim that there is not that big a
            difference  between  specifications  and  programs.   My  claim  is  that  our
            programming  languages  will  improve  to  the  point  where they let us write
            programs   that   are   just   like  the  specifications.   For  example,  the
            specification

                                  f(x)=y, where y is in D and g(y)=x

            can be written in Smalltalk as

                                      D detect: [:y | y g = x].
                 I  know  the  notation  is a little wierd, but that's not the point.  The
            point  is  that  it  is  POSSIBLE  to  write programs on the same level as the
            specifications.   If D is infinite then the program might not terminate, but I
            write  infinite  objects all the time (i.e.  the stream of all prime numbers).
            Naturally,  I  tend to reimplement these inefficient programs as time goes on,
            though  it  would be possible to argue that what I am really doing is starting
            with  specifications and incrementally implementing them.  In fact, that's how
            I like to think about it.
                 The  second point that I think is important is that most of the code in a
            large  system  is  not  algorithmic,  and  is  not  amenable  to  this kind of
            specification.   The  specification  of user interfaces, for example, tends to
            look  an  aweful  lot like the implemenation unless you go to a lot of work to
            invent higher level concepts.  For example, if you worry about exactly how the
            screen will look then the specification is just a slow implementation.  On the
            other  hand,  if you introduce the idea of "choices" and say that a particular
            "choice"  can  be  made by a "menu" then you can reason about the problem much
            more abstractly.  However, modern user interface management systems are moving
            in this direction---they are making these specifications executable.
 
            1. Articles                                                        Page 202-55




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 The third point is specific to object-oriented programming, which I think
            is  the  best way to achieve code reuse.  One of the several important ways to
            reuse  software  (some people seem to think this is the only one o-o languages
            provide,  which  is  wrong)  is to inherit a class and to override some of the
            procedures  from  it.   This  ability to override procedures is crucial---many
            classes are designed in such a way that they cannot be reused until procedures
            are  overridden.   It  is  possible  to  provide  formal specifications of the
            procedures  that  you  expect  will be overridden, but it turns out that it is
            very  hard  to  predict  exactly  what  will  be  overridden.  A class is most
            reusable  when  it  is  possible  to override anything.  This means that every
            procedure  will  be  formally  specified.   Since the median procedure size in
            Smalltalk  is  3  lines,  this  means  that  few  procedures  will have formal
            specifications  that  are  anything  other  than  their implementation.  Thus,
            providing  formal  specifications  is  really  the same thing as providing the
            implementation.
                 I  would  like to advance a fourth argument, which is one that I have not
            used  before.   That  argument  is that almost all the design effort goes into
            making  the  formal  specification.   That  is  one  of the reason that formal
            specifications  are  so  important.   They  let  you debug a program at a high
            level,  where  it is easy to think about the problem.  Of course, I believe in
            programming  at a high level, but lots of other people seem to be content with
            C, and it certainly is a good idea for them to design their system at a higher
            level  and then translate it into the lower level.  The effort in designing an
            object-oriented system is defining the classes and their interfaces.  Once you
            give  this  away  to  people, it is easy for them to recreate the code.  Thus,
            programs with formal specifications are almost as easy to recreate as programs
            with   source   provided   are   to   understand.   This  argues  that  formal
            specifications  are not going to be solutions to the problem of protecting the
            ownership rights of the authors of the components.
                 Research  in  formal  verification has had many influences on CS.  One of
            the  most  important is that it has taught us what is difficult.  For example,
            it  showed  that goto statements were hard to think about.  It also shows that
            pointers  are  hard  to  think  about.   This is why lots of modern languages,
            especially  the  symbolic  ones,  don't  have explicit pointers.  However, the
            effect  is  for  programming  language designers to borrow good ideas from the
            specification people.  I think that the future will lie in that direction.

            1.6.10.  From____ Steve_____ Cook____

            Date: 30 Oct 89 14:29:16 GMT
            From: mcsun!ukc!icdoc!qmc-cs!steve@uunet.uu.net  (Steve Cook)
            
            In article <130200018@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
            >
            >Research in formal verification has had many influences on CS.  One of
            >the most important is that it has taught us what is difficult.  For
            >example, it showed that goto statements were hard to think about.
            >It also shows that pointers are hard to think about.  This is why
            >lots of modern languages, especially the symbolic ones, don't have
            >explicit pointers.  However, the effect is for programming language
            >designers to borrow good ideas from the specification people.  I
            >think that the future will lie in that direction.
                 I have been interested and rather surprised to read the articles by Ralph
 
            Page 202-56                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            Johnson  which seem to be saying there is no place for formal specification as
            distinct from programming in today's software technology.
                 My  own  experience  with Smalltalk-80 is that much of the time I need to
            ask  the  question "what assumptions, exactly, does this method make about the
            current state of affairs?".
                 In  many  cases  this  question  is hard to answer.  Nevertheless, if for
            example  I  wish to alter a method, in the hope that my modification will be a
            proper  generalization and thus not break any current clients of the method, I
            must  get  the  answer  exactly  right.   Therefore I would greatly value some
            formal  assertions  which  would enable me to know the assumptions exactly.  A
            system of verifying the assumptions statically would be very helpful too.
                 A  first step towards this would be a type-checking scheme, and of course
            Ralph  himself has done a great deal of work in this area.  An obvious further
            step  would  be  a  more  powerful  system  of  static assertions, such as the
            preconditions, postconditions and invariants provided in the Eiffel system.  A
            step  from  there  would  be  automated  support  for  verification  of  these
            assumptions, and a range of more expressive constructs.
                 The  notion  of software contracting surely requires this kind of support
            to  make  sense.   An  effective  contract says exactly what is agreed without
            unnecessary  verbiage: just like a formal specification.  Surely Ralph Johnson
            is  not  saying  that the contract between the supplier and user of a software
            component must be based on the source code?
                 Once  the  need  for  a language, or sub-language, of assertions has been
            acknowledged, the possibility of reusability in this domain itself emerges.
                 In  summary  I claim that formal declarations of program properties (i.e.
            specifications)  do  play  a  very  important  role, as statements of contract
            between  suppliers  and consumers of software components.  Smalltalk itself in
            my experience is not well-suited to this task.

            1.7.  Conceptual__________ Model_____ for___ Software________ Components__________


            1.7.1.  From____ Will____ Tracz_____

            Date: 3 Nov 89 14:15:58 EST
            From: "Tracz, Will" 
                 What  follows  is a portion of the working group summary that I wrote for
            the  Reuse  in  Practice  Workshop sponsored by IDA and SEI that was held this
            summer.   I  have  included  the  section related to the "Conceptual Model for
            Software  Components",  initially proposed by myself and refined with the help
            of  the  members  of  the  working  group  (in particular: Sholom Cohen - SEI,
            Stephen Edwards - IDA, John Goodenough - SEI, and Larry Latour - University of
            Maine).
                 I  would  appreciate  any  feedback  anyone  has.   This  is just a short
            overview.  There is much more written, of course, with references, etc., but I
            believe this gives you the general idea.
                 So -- fire at Will


                              A Conceptual Model for Software Components
                 The conceptual model for reusable software components was an outgrowth of
            the Concept/Context model initially proposed by Tracz in his dissertation work
            at Stanford.  The model, referred to as the 3C model (Concept/Context/Content)
 
            1. Articles                                                        Page 202-57




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            is based on defining three facets of a software component:

             1.   The  "concept"  behind a reusable software component is an abstract
                 canonical  description  of  "what"  a  component does.  Concepts are
                 identified  through  requirement  or  domain  analysis  as providing
                 desired  functionality  for  some  aspect of a system.  A concept is
                 realized  by  an  interface specification and an (optionally formal)
                 description  of  the  semantics  (as  a  minimum, the pre- and post-
                 conditions)   associated   with  each  operation.   An  Ada  package
                 specification  with its behavioral semantics described in Anna is an
                 example of a reusable software concept.

             2.   The "content" of a reusable software component is an implementation
                 of  concept,  or "how" a component does "what" it is supposed to do.
                 The  basic premise it that each reusable software component can have
                 several  implementations  that  obey  the semantics of it's concept.
                 The  collection  of  (28)  stack  packages  found  in  Grady Booch's
                 components is an example of a family of implementations for the same
                 concept (a stack).

             3.   The  "context"  of  a  reusable  software  component  takes  on two
                 dimensions that often overlap:

                  i. the "conceptual context" of a reusable software component and the
                 ii. the "contentual context" of a reusable software component.

                 There  is a direct correlation between context and parameterization.
                 At  first  glance  the conceptual context might be thought of as the
                 data  (or  attributes of the data) being manipulated by the concept.
                 Similarly,  the  contentual  context  might  be  the  implementation
                 details or options that can be selected at compile or run-time.  One
                 should  note  that  while  it is often the case that the concept and
                 content  of  a  component  share the same context, the context of an
                 implementation  often  subsumes  that  of the concept and extends it
                 with  performance  trade-offs,  hardware platform, operating system,
                 algorithmic,  or  language  dependent  contextual  information.   An
                 example  of a conceptual context is the type of element to be stored
                 in a generic stack package (an instantiation parameter).  An example
                 of  a  implementation  context is a conditional compilation variable
                 that selects between UNIX and DOS operating system calls.

                 The  example  used for discussion by the working group was the concept of
            sorting.   The  sorting  concept can not be described without a context (Note:
            All  concepts  and  contents  have  a  context! In fact one of the most common
            problems faced with trying to reuse previously written software is determining
            the  assumptions  made  by  the  original  developer.  These assumptions often
            encompass  the  contextual  information  that  is  buried  in the interface or
            implementation and point out the need to separate the context from the concept
            and  content of a reusable software component!).  The context used to describe
            the  concept  of sorting includes a list of elements that have a partial order
            on them (a characteristic of the elements in the list).  Therefore the context
            associated  with  sorting  concept,  that is the data and data structure being
            sorted.   This data structure must have certain properties associated with it,
 
            Page 202-58                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            that is, it's context can, in turn, be described in terms of properties of its
            elements  --- that a linear order relationship is defined on them.  This is an
            example  of a concept (sorting) whose context (lists) is itself a concept that
            has  a  context  of the linear order relationship on its elements.  Note also,
            the linear order relationships can be satisfied in many ways (e.g., less than,
            greater  than,  is  a  member  of).   These are all examples of the conceptual
            context of the sorting software component.
                 Focusing  now on contentual context, there can be several implementations
            of  lists  (e.g.   linked  list,  arrays,  or files), therefore the content or
            implementation  associated  with the concept can take any of a number of forms
            based   on  different  contexts.   Similarly,  there  exists  several  sorting
            algorithms,  each  perhaps  more  suited  for  different  implementations  and
            attributes  of  the  data  (e.g.,  nearly  sorted data), each having different
            run-time performance and resource characteristics.
                 The  selection  of  an  implementation,  or the content of the concept is
            determined  by trade-offs in context.  Clearly, knowing the characteristics of
            the  type  of  data  structure  being  manipulated will lead to more efficient
            implementations.   This  can  result in the population of a reuse library with
            several  efficient  implementations  of the same (parameterized) concept, each
            tailored to a particular context.  At design time, a programmer could identify
            the  concept  and  define  the  context it is being manipulated under based on
            requirements or operating constraints.  At implementation time, the programmer
            could  instantiate  an  implementation  of  the  concept  with  the conceptual
            contextual  information  plus  any  other  contentual  contextual  information
            necessary.

            1.8.  Computer________ Virus_____ Concerns________


            1.8.1.  From____ Frank_____ Starr_____

            Date: Sunday, 24 September 1989  15:12-MDT
            From: SAC.55SRW-LGS@E.ISI.EDU
            Re:   Virus Commentary

                                                   
            Sabotaged Program Reactions - An Editorial Review
                                            by Frank Starr
                 The continuing threat of virus and Trojan Horse programs - which I prefer
            to  call  sabotaged  programs, has begun to spark some reaction from the upper
            levels  of  the  Department  of Defense.  Concurrent with the discovery of the
            so-called  "Columbus  Day Time Bomb", previously known as the Datacrime Virus,
            has  come  a  series of directives which may serve to eliminate the use of all
            forms of shareware by D.O.D.  personnel on D.O.D.  microcomputers.
                 Air  Force users first received word of the Columbus virus from a message
            published  by  the  USAF Office of Special Investigation, republished and mass
            mailed  through  MILNET/DDN, the D.O.D.  e-mail system.  Two suspected sources
            have  been  listed - a European extremist group in the spiritual sway of Bader
            Meinhoff,   and  a  Norwegian  group  displeased  with  celebrations  honoring
            Columbus,  while  ignoring  Norse  discoveries  preceeding  those  of European
            explorers.
                 Later  communiques identified the virus as the Datacrime variety, capable
            of  trashing  the  FAT  area  of  a hard drive.  From the first message to all
 
            1. Articles                                                        Page 202-59




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            others  received  to  date, a prevailing directive has been to cease using all
            software  downloaded  from  private  bulletin boards.  Various interpretations
            have  gone  so far as to conclude that only vendor supplied software should be
            used,  to  the  absolute  exclusion  of  everything  else,  whether  shareware
            available  for purchase after an initial test period, or freeware for which no
            fee or donation is ever asked.
                 All  of  this confusion promises to cause a lot of D.O.D.  micro users to
            cut themselves off from anything except commercial software, purchased through
            government  contracting  channels.   This in spite of the fact that there have
            even  been  reports  about commercial software occasionally being sabotaged by
            temporary employees (as reported in an issue of Government Computer news about
            a  year  ago.   Sorry, specific issue forgotten).  There are a number of micro
            bulletin  boards  in  D.O.D.,  some  of  which  offer  shareware  software for
            evaluation to potential customers.  Some of the SYSOPs of these systems forsee
            a  call  to  close  down  operations, based on reactions to sabotaged software
            threats,  and  rough  drafts  of  official  regulations to control software on
            D.O.D.  micros (see the September/October C2MUG bulletin, page 5).
                 Although  there  are some advisories for users to back up all software on
            D.O.D.   micros,  more  attention seems to be going towards the elimination of
            all  non-contract  software  on  D.O.D.  micros.  Since sabotaged programs are
            more  often  reported in connection with softwaree downloaded from public RBBS
            systems, this game plan can be understood, if not readily supported.  However,
            with  micro  user  education  still a lower priority object in many areas, and
            software  backup  not  a  widespread  practice, it seems that, especially with
            funding cuts a now and future reality, more attention would better be given to
            how  to  defend  against  sabotaged programs, and perhaps the avoidance of all
            forms of shareware could be reevaluated.

            1.8.2.  From____ Frank_____ J._.  Wancho______

            From: Frank J. Wancho 
            To:   Frank Starr 
            Re:   Virus Commentary
            
            Frank,
                 I  just read and reread your editorial.  I fear that possibly many people
            will  misread  it, overlooking certain key words and phrases, such as "may" in
            "may  serve  to  eliminate,"  "various interpretations," "foresee," "seems" in
            "more attention seems to be," etc.
                 The  actual  point of your editorial, with which I agree, is in your last
            sentence,  which  should  have  been  a paragraph by itself (starting with the
            word, "However," and broken into several sentences:
                 Micro  user education is still a low priority activity in many areas, and
            software backup not a widespread practice.  With funding cuts a now and future
            reality,  more  attention  should  be  given  to  defending  against sabotaged
            programs.   Then,  perhaps,  the  trend toward avoiding all forms of shareware
            could be reevaluated.






 
            Page 202-60                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.8.3.  From____ Rick____ Conn____

            Date: Wed, 27 Sep 89 03:49:52 MDT
            From: Rick Conn 
                 The  role  of  ADA-SW  is  to  support  the  ASR users, who are naturally
            concerned with the proliferation of computer viruses.  My recent posting could
            trigger turning the digest into a broadcast of virus information.  Rather than
            doing  that,  interested  users  should  subscribe to the email list mentioned
            below,  which  is  specifically  geared  to  passing  information  on computer
            viruses.

                                                   
            The VIRUS-L Mailing List
                 To get onto the VIRUS-L mailing list, send a mail message to

            LISTSERV@LEHIIBM1             if you are on the BITNET
            LISTSERV@IBM1.CC.Lehigh.Edu   if you are on the Internet
                 In the body of the message, say nothing more than:

                                        SUB VIRUS-L your name
                 LISTSERV is a program which automates mailing lists such as VIRUS-L.
                 All  submissions  to VIRUS-L are stored in monthly log files which can be
            downloaded  by  any  user on (or off) the mailing list.  There is also a small
            archive  of  some  of  the  public  anti-virus  programs  which  are currently
            available.

            1.9.  20__ Most____ Popular_______ Files_____ in__ the___ ASR___


            [PHOTO:  Recording initiated  Wed 27-Sep-89 6:05AM]
            
            @
               name                                   # refs,     rate/month,     size.
            ABSTRACT.SRC.1             1045              20     224 pgs
            LIST.ADA.2                  939              15       7 pgs
            PAGER.SRC.5                      894              18      34 pgs
            UNPAGE.ADA.1                     891              15       3 pgs
            EXPERT.ADA.1                        882              18      15 pgs
            BENCH.DOC.1                 867              17       3 pgs
            EXPERT.PRO.1                        864              18       2 pgs
            CHAP01.DOC.1                  863              10      12 pgs
            PAGE.ADA.1                       857              15       3 pgs
            GKSUSER.DOC.1                      856              17      99 pgs
            GKS0A.SRC.1                        847              16     452 pgs
            FTP.DOC.5                      847              21      11 pgs
            FTP2.DOC.3                     846              17       8 pgs
            PAGER.DOC.2                      839              17       7 pgs
            KERMIT.DOC.1                   837              14       7 pgs
            FTP1.DOC.1                     835              18       7 pgs
            QSORT.SRC.1                 834              14       3 pgs
            PRET.SRC.1             832              16     131 pgs
            EXPERT.DAT.1                        831              17       1 pgs
            PARSER.PRO.1                825              16       2 pgs
 
            1. Articles                                                        Page 202-61




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            1.10.  SW-COMP_______ <=>___ USENET______ Feed____ is__ Operational___________

            Date: Fri, 13 Oct 89 05:38:10 MDT
            From: Rick Conn 
                 The  comp.sw.components  newsgroup  feed into SW-COMP is now operational.
            Messages from this feed will now appear in SW-COMP digests.
                 To subscribe to SW-COMP, send a request to:

                                SW-COMP-REQUEST@WSMR-SIMTEL20.ARMY.MIL












































 
            Page 202-62                                                1. Articles




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                                          2. Release Notices

            2.1.  ASR___ Master______ Index,_____, September_________ 25,__, 1989____

                 A  new  issue of the ASR Master Index, dated September 25, 1989, has been
            released.  The following describes the ASR Master Index.

            1. Taxonomy:
            ADA BOOKS AND DOCUMENTS
            ADA SOFTWARE REPOSITORY
            MASTER INDEX
            
            2. Abstract:
                 PD2:  contains  a  machine-readable  copy of the Master
            Index,  a  book which documents the items in the Ada Software Repository.  The
            Master  Index provides descriptions of the various items maintained in the ASR
            and  acts  as  a  useful,  effective reference to the users of the ASR.  Three
            types of items are described in the Master Index:

              Text           text and information files
            
              Software       Ada software and its associated documentation
            
              WIS/NOSC       those items submitted by WIS and NOSC
                 WIS/NOSC   items   are   mainly   software,   and  the  WIS/NOSC-specific
            descriptions  are  in  Appendix  A.   All  software  and text items (including
            descriptions  of  those  items  provided  by  WIS/NOSC)  are  described in the
            chapters  of  the  Master  Index.   Chapter  1  of  the  Master Index contains
            instructions  on  how to use the Master Index, how to acquire the files in the
            ASR, and other information of interest to the user of the ASR.
                 The  *.CH  files are ASCII text files which make up the title page, table
            of  contents  and  taxonomy,  chapters and appendices, and index of the Master
            Index.   The *.CH files files are designed to be printed on 8 1/2" x 11" paper
            in  elite  (12  chars/inch) type.  No margins should be preset; a 1" margin is
            already formatted into these files.
                 The order of the *.CH files in PD2: is:

             TITLE.CH        Title Page
             TOC.CH          Table of Contents and Taxonomy
             CH01.CH         Chapter 1
             ...
             CHnn.CH         Chapter nn
             CHA.CH          Appendix A
             CHB.CH          Appendix B
             INDEX.CH        Index
                 Other files in PD2: are data files used in the creation
            of the Master Index and are not of general interest.
                 The  Support  Contractor of the ASR provides hardcopy distribution of the
            Master  Index  for  those who do not wish to print their own copies from these
            files.   This  hardcopy  is  available  without  cost  to  elements  of the US
            Government  and  is  available  to  all  others  for the cost of reproduction.
            Contact the Support Contractor (see PD2:OVASRSUPP.DOC) for prices
            and further details.
 
            2. Release Notices                                                 Page 202-63




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            3. Directory Listing:
            Directory   PD2:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              CH01.CH             74884    2232
              CH02.CH            133472    4092
              CH03.CH              4994     124
              CH04.CH             25058     744
              CH05.CH             15850     496
              CH06.CH             26836     744
              CH07.CH            389728   12152
              CH08.CH             14359     372
              CH09.CH              9330     248
              CH10.CH             13773     372
              CH11.CH             34834     992
              CH12.CH             22912     496
              CH13.CH              9982     248
              CH14.CH             90761    2108
              CH15.CH             42510     992
              CH16.CH             14668     372
              CH17.CH             15276     372
              CHA.CH             281790    7812
              CHB.CH               8215     248
              INDEX.CH            83145    1240
              TITLE.CH             2170     124
              TOC.CH              21615     744
              ===============  ========  ======
               22 Files         1336162   37324

            2.2.  Incremental___________ Upgrade_______ from____ the___ July____ Master______ Index_____

                 For  those  of  you  who  have  a current (July 5) copy of the ASR Master
            Index, it is not necessary for you to obtain all of the files of the September
            25  release  in  order  to update your index.  Only those files marked with an
            asterisk (*) have been changed since the July 5 issue.

               PD2:
                       Bytes(SZ)
            
            *CH01.CH.10       74884(7)
            *CH02.CH.10       133472(7)
             CH03.CH.10       4994(7)
             CH04.CH.10       25058(7)
             CH05.CH.10       15850(7)
             CH06.CH.10       26836(7)
            *CH07.CH.10       389728(7)
             CH08.CH.10       14359(7)
             CH09.CH.10       9330(7)
             CH10.CH.10       13773(7)
             CH11.CH.10       34834(7)
             CH12.CH.10       22912(7)
             CH13.CH.10       9982(7)
            *CH14.CH.10       90761(7)
 
            Page 202-64                                          2. Release Notices




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            *CH15.CH.10       42510(7)
             CH16.CH.10       14668(7)
             CH17.CH.3        15276(7)
             CHA.CH.10        281790(7)
            *CHB.CH.10        8215(7)
            *INDEX.CH.10      83145(7)
            *TITLE.CH.10      2170(7)
            *TOC.CH.10        21615(7)
            
             Total of 532 pages in 22 files

            2.3.  DRAFT_____ CHOICE______ Object-Oriented_______________ Drawing_______ Tool____


            1. Taxonomy:
            PROGRAMMING TOOLS
            CASE
            DRAFT CHOICE
            
            2. Author:
                TRIUS Inc.
                231 Sutton Street, Suite 2D-3
                PO Box 249
                North Andover, MA  01845-1639
                508/794-9377
            
            3. Abstract:
                 From the "DRAFT CHOICE" manual:
                 "DRAFT  CHOICE  is an impressively fast, object based graphics tool which
            uses  floating  point  mathematics  to record the size, shape, and position of
            objects you design.  An object is a basic element like a line, circle, box, or
            more  complex  shapes  like  polygons  (triangles, pentagons, etc.) and Bezier
            curves.   By  choosing  a  mixture  of these elements you can create amazingly
            detailed drawings, impressive graphics, and conceptual schematics.
                 "DRAFT CHOICE contains functions that allow you to quickly correct errors
            or  modify  a  drawing  either  by  acting on a single object or on a group of
            objects  at  a  time.   Modification options include moving, copying, scaling,
            rotating, and many more."
                 DRAFT  CHOICE  also  supports  the  creation  of  reusable  libraries  of
            commonly-used  symbols.   Symbol  libraries are available in the ASR to aid in
            the   creation   of   Booch   and  Buhr  diagrams,  Data  Flow  Diagrams,  and
            Entity-Relationship Diagrams.  DRAFT CHOICE is SHAREWARE.

            4. Directory Listing:
            Directory   PD1:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              DRAFTC.ARC         219739  Binary
              ===============  ========  ======
                1 Files          219739       0



 
            2. Release Notices                                                 Page 202-65




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            2.4.  EasyCASE________ Drawing_______ Tool____


            1. Taxonomy:
            PROGRAMMING TOOLS
            CASE
            EASYCASE
            
            2. Author:
                Evergreen CASE Tools
                11025 164th Avenue, NE
                Redmond, WA  98052
                206/881-5149
            
            3. Abstract:
                 From the Introduction in the "EasyCASE Users Guide":
                 "EasyCASE   is   a   limited   function  CASE  (Computer  Aided  Software
            Engineering)  tool  intended to simplify the generation (with a certain amount
            of  automation)  of  data  flow  diagrams (DFDs), transformation graphs, state
            transition  diagrams,  structure  charts,  and  entity-  relationship diagrams
            (ERDs).    EasyCASE   produces   these   charts   in   accordance   with   the
            Yourdon-DeMarco, Gane & Sarson, Ward-Mellor, Hatley-Pirbhai (also known as the
            Boeing-Hatley  method),  Yourdon-  Constantine  and  Chen  representations and
            methodologies  for  structured  analysis  and  design  as  published  in their
            respective  texts  (see bibliography section).  EasyCASE provides an easier to
            use,   more   automated  method  of  producing  these  diagrams  than  does  a
            presentation  graphics  or drawing program such as Lotus Freelance, Micrografx
            Designer,  Windows  Draw  or  Gem Draw, etc., in that the drawing functions it
            provides  are  only  those  required  to  provide  the  symbols,  connections,
            annotation   and   relationships   required   for  the  specific  chart  types
            implemented.   EasyCASE  is  also easier to use than most of the full-featured
            CASE tools in that is provides only the basic functions (charts) necessary for
            performing and presenting structured systems analysis and design.
                 "EasyCASE  provides  the  capability  to  add  the appropriate chart type
            objects  to  the  chart  and then manipulate them.  EasyCASE maintains certain
            information  about each object and its relationships with other objects on the
            chart.   Objects  can  be  added,  moved,  deleted,  labelled, identified, and
            associated  with  other objects on the chart.  If an object is modified in any
            way,  any  other similarly identified or associated objects are modified also.
            For  example: (i) if a data process symbol on a transformation graph is moved,
            any  attached  data  and/or  control  flows  and  their labels are moved also,
            remaining  connected  to, and associated with, that symbol; (ii) if a function
            symbol  on  a  structure  chart  is  deleted,  any  attached  connections  and
            associated  data or control flow arrows (couples) and their labels are deleted
            also;  (iii)  if  a  previously  defined  object identifier is reused, the new
            object will inherit its attributes (label)."
                 EasyCASE  1.53  is also reviewed in the September 1989 issue of "Computer
            Language" magazine.  EasyCASE is SHAREWARE.

            4. Directory Listing:
            Directory   PD1:
                 File Name      Bytes    Lines
              ---------------  --------  ------
 
            Page 202-66                                          2. Release Notices




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
              EZCASE15.ARC       232695  Binary
              EZCDOC15.ARC        97464  Binary
              ===============  ========  ======
                2 Files          330159       0

            2.5.  Validated_________ Ada___ Compilers_________ List____ -_ October_______ 1989____

                 This is the October 1989 list of validated Ada compilers.  There are over
            280 base and derived compilers.

            1. Taxonomy:
            ADA BOOKS AND DOCUMENTS
            ADA COMPILERS, AVAILABLE
            
            2. Abstract:
             Ada Compilers, Available
            
            FORMAT KEY:
             1st Line - Ada Software Repository File Name
             2nd Line - AdaIC File Name
             Rest     - Description
            
            COMPILERS.INF
            VAL-COMP.HLP
             This file contains a list of currently validated Ada
            compilers.
            
            3. Directory Listing:
            Directory   PD2:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              COMPILERS.INF      151760    2749
              ===============  ========  ======
                1 Files          151760    2749

            2.6.  Booch,_____, Buhr,____, and___ Data____ Flow____ Diagrams________ -_ Symbol______ Libraries_________


            1. Taxonomy:
            PROGRAMMING TOOLS
            CASE
            DRAFT CHOICE
            
            2. Author:
                TRIUS Inc.
                231 Sutton Street, Suite 2D-3
                PO Box 249
                North Andover, MA  01845-1639
                508/794-9377
            
            3. Abstract:
                 From the "DRAFT CHOICE" manual:
                 "DRAFT  CHOICE  is an impressively fast, object based graphics tool which
 
            2. Release Notices                                                 Page 202-67




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            uses  floating  point  mathematics  to record the size, shape, and position of
            objects you design.  An object is a basic element like a line, circle, box, or
            more  complex  shapes  like  polygons  (triangles, pentagons, etc.) and Bezier
            curves.   By  choosing  a  mixture  of these elements you can create amazingly
            detailed drawings, impressive graphics, and conceptual schematics.
                 "DRAFT CHOICE contains functions that allow you to quickly correct errors
            or  modify  a  drawing  either  by  acting on a single object or on a group of
            objects  at  a  time.   Modification options include moving, copying, scaling,
            rotating, and many more."
                 DRAFT  CHOICE  also  supports  the  creation  of  reusable  libraries  of
            commonly-used  symbols.   Symbol  libraries are available in the ASR to aid in
            the   creation   of   Booch   and  Buhr  diagrams,  Data  Flow  Diagrams,  and
            Entity-Relationship  Diagrams.   DRAFT  CHOICE  is  SHAREWARE.   See  the file
            BBDSLIB.ARC for symbol libraries of Booch, Buhr, and Data Flow Diagrams.

            4. Directory Listing:
            Directory   PD1:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              DRAFTC.ARC         219739  Binary
              BBDSLIB.ARC         32304  Binary
              ===============  ========  ======
                2 Files          252043       0

            2.7.  Booch_____ Diagrams________ of__ Top___ Two___ Levels______ of__ PTF___


            1. Taxonomy:
            TEXT MANIPULATION
            WORD PROCESSORS
            PORTABLE TEXT FORMATTER
            
            2. Author:
                Richard Conn
            
            3. Abstract:
                 The  Portable  Text  Formatter  (PTF)  is  a document formatting program,
            written in Ada, which can execute on a variety of hardware platforms.  PTF was
            designed  to  be  as  portable  as  possible, so it should run on any platform
            supported by a validated Ada compiler.
                 PTF  reads  one  or more source text files which contain both commands to
            PTF and text lines, and PTF generates a formatted output file and (optionally)
            a  file  containing  index entries.  Commands to PTF are placed on lines whose
            first  character is a dot (this may be changed if desired), and text lines are
            those  lines  whose first character is not a dot.  Commands to PTF instruct it
            to  perform  certain operations on the formatted output file, such as set left
            margin,  underline  the  following  words,  place  an  entry into the table of
            contents, place an entry into the index, and define a macro.
                 PTF was designed to meet several objectives:
                 1.   Generate  DoD-STD-2167A documents.  PTF was designed specifically to
            support  the  generation  of  DoD-STD-2167A  documents,  as  detailed  in  the
            DoD-STD-2167A  Data  Item  Descriptors  (DIDs).   To  this  end,  PTF supports
            multiple  page  heading  lines,  multiple page footer lines, page numbers in a
 
            Page 202-68                                          2. Release Notices




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            variety  of  formats (including Arabic and Roman numeral), generation of up to
            six  distinct  tables  of  contents  (so  that separate tables for figures and
            diagrams may be created), and generation of an index.
                 2.   Support  Ada  software  development.   PTF  was written to provide a
            mechanism  to  support  other  Ada software development tools, such as Ada PDL
            (Program  Design  Language) processors.  Output from these tools would be text
            files containing PTF commands.  Specifically, support of such tools to process
            PDL as defined in MIL-HDBK-1804 is anticipated.
                 3.   Support  team  development  of  a  document.  PTF also supports team
            development  of  a  document,  where  individuals can be given a common set of
            macros  and  instructions  on  their use, and PTF can assemble a document in a
            common  format  from  many  different  source  files  which were independently
            created.
                 4.   Provide  a  documentation  standard for the Ada Software Repository.
            Many  of the reusable documents in the Ada Software Repository will be revised
            so  they may be processed by PTF, and many new documents will be released in a
            form that may be processed by PTF.
                 5.  Port without modification to computer systems for which validated Ada
            compilers exist.  PTF is written in Ada and has been tested on a VAX, Sun, and
            PC platform in an attempt to insure portability.
                 The PTF System consists of two programs: PTF and PTFIDX.  PTF is the main
            word  processor.   PTFIDX  is  a  companion program to PTF which processes its
            index pages.
                 The  file  PTF.VDD  contains  a  listing  of  the distribution of PTF, an
            installation  manual,  and other instructions which detail how to bring PTF up
            on  a  particular target system.  The file CLI2.SRC in PD2: is
            needed to compile PTF and PTFIDX.
                 Booch  diagrams  of  the top two levels of the PTF system are in the file
            PTFDIAG.ARC.  See the VDD in this file for further details.

            4. Directory Listing:
            Directory   PD2:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              PTF.PRO              5306     100
              PTF.SDD             50640    2109
              PTF.SUM            126215    3473
              PTF.VDD             32680    1241
              PTFBODY.SRC        164630    5951
              PTFDOCS.SRC        134171    4705
              PTFINDEX.SUM         8121     187
              PTFMAIN.SRC         32603    1250
              PTFREAD.ME            182       5
              PTFSPEC.SRC         87912    2861
              PTFTEST.SRC         33684    1422
              ===============  ========  ======
               11 Files          676144   23304
            
            Directory   PD2:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              CLI2.PRO             3345      63
              CLI2.SRC            41974    1144
 
            2. Release Notices                                                 Page 202-69




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
              ===============  ========  ======
                2 Files           45319    1207
            
            Directory   PD1:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              PTF.ARC            391897  Binary
              PTFDIAG.ARC         70195  Binary
              ===============  ========  ======
                2 Files          462092       0

            2.8.  Analyst_______ Tool____ Kit___


            1. Taxonomy:
            PROGRAMMING TOOLS
            CASE
            ANALYST TOOL KIT
            
            2. Author:
                Chinook Software Group
                PO Box 24536
                Denver, CO  80224
            
            3. Abstract:
                 From the Documentation:
                 "This  tool suite enables a user to perform top-down system specification
            using  the Structured Analysis Methodology (Data Flow Diagrams).  Diagrams are
            entered  and  manipulated  graphically,  but  stored  in textual form for easy
            access by other tools.  Support is provided for data dictionary generation and
            analysis, as well for analysis of the DFDs."
                 Also:
                 "The  Structured Analysis methodology allows a user to perform a top-down
            specification  of  a  system  from  a  data viewpoint.  The methodology is not
            limited  to  software  development, but functions well at the requirements and
            system  design  levels  also.   The  resulting  set  of  diagrams and the data
            dictionary  augments  any  documentation effort, and provides a concise, clear
            picture  which  may  be  dynamically  maintained  along  with  the  system  it
            describes.
                 "The  Analyst  Tool  Kit  (ATK)  is  a collection of application software
            designed  to facilitate the development, analysis, and maintenance of a set of
            DFD's  (Data  Flow  Diagrams)  and  their  associated  data  dictionary.   The
            SHAREWARE version consists of the following:
                 "1.  A GRAPHIC EDITOR, called GED, which allows DFD's to be interactively
            entered  and  manipulated on a CRT screen.  Unlike a generic graphics package,
            GED  is  specifically  designed  to  work  with  standard  DFD  symbology  and
            convention.   GED  also  produces an ASCII format file as output, which can be
            read by standard text editors as well as the other tools in the package.
                 "2.  A DATA DICTIONARY builder, called DDBUILD, which can read the output
            of  the  graphic  editor  and  produce the skeleton Data Dictionary.  The data
            dictionary  is an ASCII format file which can be read by standard text editors
            as well as the DFD EVALUATOR.
                 "3.   A  DATA  DICTIONARY  EVALUATOR,  called  DDEVAL,  which  reads  the
 
            Page 202-70                                          2. Release Notices




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            completed  data  dictionary,  parses  it  for  errors,  and  produces  a  data
            dictionary listing.
                 "4.   A  DATA  FLOW  DIAGRAM EVALUATOR, called ANAL, which reads the data
            flow  diagram files and the data dictioanry, and reports on conformance to the
            Structured Analysis methodology guidelines.
                 "5.  A REPORT GENERATOR, called RG, which formats the output of the other
            tools.   It  has  knowledge of certain files produced by the tool set, but may
            also be used as a general-purpose page formatter.
                 "Other tools are also included:
                 "1.   A PostScript GENERATOR, called GEDPS, which converts DFD files into
            PostScript  representations  suitable  for  sending to an Apple LaserWriter or
            other PostScript printer.
                 "2.   A  DFD REUSE HELPER, called ATTACH, which attaches or stores entire
            DFD subtrees for reuse on other designs.
                 "This  version  of Analyst Tool Kit was originally intended for classroom
            use  and  provides  an  environment  in which to study the Structured Analysis
            method.   It  was discovered, however, to be practical for a range of small to
            medium  size  design  efforts, and is being offered as SHAREWARE at a price to
            suit a market neglected by comparable products.
                 "The toolkit features:
                 "- 8 levels of decomposition below the context diagram
                 "- Data Dictionary evaluation limited only be available memory
                 "- flat ASCII data file formats easily accessible to other tools
                 "- PostScript output from DFDs, suitable for printing or incorporation as
            EPS documents in publishing systems like Ventura Publisher
                 "-  full function on vanilla PC hardware configurations, with no mouse or
            expensive graphics cards."
                 This  item  in  the  ASR is SHAREWARE and is presented in executable form
            only, suitable for running on IBM PCs which support at least 192K of memory, a
            standard  IBM  color  graphics  adapter  (or  equivalent),  DOS version 2.0 or
            higher, and a printer capable of doing graphic output.

            4. Directory Listing:
            Directory   PD1:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              ATKBASE.ARC        151765  Binary
              ATKDOC.ARC          24632  Binary
              ATKIBM.ARC          84730  Binary
              ATKREAD.ME           4969      97
              ATKSAMP1.ARC        13647  Binary
              ATKSAMP2.ARC         7093  Binary
              ATKZ100.ARC         46568  Binary
              ===============  ========  ======
                7 Files          333404      97








 
            2. Release Notices                                                 Page 202-71




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
            2.9.  Snapshot________ of__ the___ ASR___ for___ November________ 1989____


            1. Taxonomy:
            ADA BOOKS AND DOCUMENTS
            ASR SNAPSHOTS
            
            2. Abstract:
                 These files contain snapshots of the Ada Software Repository (ASR).
                 The  first  four  snapshots list each directory in the ASR and show their
            sizes.   The  snapshots  provide  an  overview  of the ASR, provide a means to
            quickly find out how much is available in the various subject areas, and allow
            the reader to follow the growth of the ASR during the earlier days of the ASR.
            These snapshot files are named SNAP01.DOC to SNAP04.DOC.
                 The  later  snapshots  show  the  total  number of accesses and the total
            number of files in the ASR along with a count of the total number of bytes and
            lines in these files.  The later snapshots are generated automatically.  These
            snapshot files are named SNAPyymm.DOC for the year and month they were taken.

            3. Directory Listing:
            Directory   PD2:
                 File Name      Bytes    Lines
              ---------------  --------  ------
              SNAP01.DOC           3754      80
              SNAP02.DOC          10523     315
              SNAP03.DOC          12600     330
              SNAP04.DOC          20620     855
              SNAP8810.DOC          250       9
              SNAP8812.DOC          249       9
              SNAP8902.DOC          251       9
              SNAP8903.DOC          246       9
              SNAP8904.DOC          245       9
              SNAP8905.DOC          245       9
              SNAP8906.DOC          246       9
              SNAP8907.DOC          244       9
              SNAP8908.DOC          247       9
              SNAP8909.DOC          252       9
              SNAP8910.DOC          251       9
              SNAP8911.DOC          250       9
              ===============  ========  ======
               16 Files           50473    1688












 
            Page 202-72                                          2. Release Notices




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                          3. Calls for Papers, Press Releases, Announcements

                 This section of the newsletter contains calls for papers, press releases,
            and  other  announcements.   These  articles  are submitted by mailing same to
            MACA.   All  attempts are made to ensure that no modification to their content
            is  made during transcription to the newsletter.  Presentation of the articles
            in this section does not constitute an endorsement in any way.

            3.1.  Ada___ for___ POSIX_____ from____ AETECH______

                 The following is a press release received from AETECH.
                 SOLANA  BEACH,  CA  --  October 19, 1989 -- AETECH successfully completed
            validation testing for it's POSIX Ada Compiler during extensive testing by the
            Department  of  Defense during September 1989.  This makes IntegrAda/POSIX the
            first_____  Ada___  Programming___________  Support_______ Environment___________ for___ the___ POSIX_____ compliant_________ operating_________
            systems._______.
                 POSIX,  an  acronym  for  the  Unix-based,  multi-user,  multi-processing
            "Portable  Operating  System Interface for Computer Environments", is the U.S.
            Government's  new  standard  for operating systems.  POSIX is now required for
            use  by  government agencies such as NASA, the Federal Aviation Administration
            and the military services.  Ada is the DoD's standard computer language, which
            was mandated in 1983 for all military computer systems.
                 Ada  and POSIX are the two cornerstones of the U.S.  Government's plan to
            save  taxpayer  dollars by establishing a single, high-order standard computer
            language  and  multi-tasking  operating system which works on the thousands of
            different  types  of  government  computers.  Ada and POSIX, with standardized
            coding,  documentation,  and  maintenance  features,  are  expected  to reduce
            software costs by standardizing programming skills and tools.
                 "This  validation  is  significant because it means the "IntegrAda/POSIX"
            has satisfied the government's stringent requirements for Ada compatability on
            fully  compliant POSIX operating systems," said James T.  Thomes, president of
            AETECH.   "Unix  has always been very popular throughout the defense industry,
            but  now  that Ada and POSIX have been mandated, IntegrAda/POSIX might well be
            the only Ada programming system which can fully meet government requirements."
                 Thomes  said  the  IntegrAda/POSIX  programming system was validated in a
            highly-productive "Turbo-like" programming environment, which allows up to ten
            concurrent  editing  and  compilations  to  be  simultaneously controlled by a
            single  programmer.   It  was tested on the latest POSIX compliant versions of
            SCO and Interactive Unix operating systems using Zenith, IBM, and Unisys 80386
            based computers.
                 According  to Thomes, Ada compilers for POSIX compliant operating systems
            have  been  specified  this year in government bids by the FAA, the Army Small
            Multi-User Computer, and the DoD's Desktop III micro-computer program which is
            reportedly  worth  $2  billion.   While other companies have Ada compilers for
            Unix,  Thomes  reports  that IntegrAda/POSIX is one of the first validated for
            use on the new POSIX systems.
                 Last  year,  AETECH  introduced  the MS-DOS version of IntegrAda which is
            written  envirely  in Ada, as the first integrated Ada programming environment
            for  the microcomputer.  IntegrAda is used throughout the military and defense
            industry.   IntegrAda/POSIX  is  also  an  integrated  programming environment
            written entirely in Ada.
                 For further information contact:

 
            3. Calls for Papers, Press Releases, Announcements                 Page 202-73




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 
                 Jim Dorman
                 AETECH, Inc.
                 380 Stevens Ave, Suite 212
                 Solana Beach, California  92075
                 (619) 755-1277
















































 
            Page 202-74              3. Calls for Papers, Press Releases, Announcements




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 




















                                    This Page Intentionally Blank
































 
            3. Calls for Papers, Press Releases, Announcements                 Page 202-75




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 




                                          Table of Contents_____ __ ________


            
            1. Articles ............................................................ 202-1
               1.1. Schedule and budget are secondary .............................. 202-1
               1.2. Non-Code Software Components  ................................. 202-23
               1.3. Software Quality  ............................................. 202-33
               1.4. Maintenance and Reuse ......................................... 202-40
               1.5. Maintenance ................................................... 202-43
               1.6. Seeing Component Source Code? ................................. 202-46
               1.7. Conceptual Model for Software Components  ..................... 202-57
               1.8. Computer Virus Concerns ....................................... 202-59
               1.9. 20 Most Popular Files in the ASR  ............................. 202-61
               1.10. SW-COMP <=> USENET Feed is Operational ....................... 202-61
            
            2. Release Notices  ................................................... 202-63
               2.1. ASR Master Index, September 25, 1989  ......................... 202-63
               2.2. Incremental Upgrade from the July Master Index  ............... 202-64
               2.3. DRAFT CHOICE Object-Oriented Drawing Tool ..................... 202-65
               2.4. EasyCASE Drawing Tool ......................................... 202-65
               2.5. Validated Ada Compilers List - October 1989 ................... 202-67
               2.6. Booch, Buhr, and Data Flow Diagrams - Symbol Libraries  ....... 202-67
               2.7. Booch Diagrams of Top Two Levels of PTF ....................... 202-68
               2.8. Analyst Tool Kit  ............................................. 202-70
               2.9. Snapshot of the ASR for November 1989 ......................... 202-71
            
            3. Calls for Papers, Press Releases, Announcements  ................... 202-73
               3.1. Ada for POSIX from AETECH ..................................... 202-73




















 
                                                 ii




                                 Ada Software Repository Newsletter
            Issue 202                                                     November 7, 1989
 




















                                    This Page Intentionally Blank
































 
                                                 iii
--::::::::::
--asr202.ptf
--::::::::::
.comment
.! Template for creating ASR Newsletters
.! by Richard Conn
.!
.! Customize this template for the particular newsletter by
.! following the directions in the square brackets ([]), replacing
.! the text in the square brackets with the text to go into the
.! newsletter.
.!
.! This template provides for the newsletter to be created in
.! a stand-alone fashion.  Page numbering will be local to the
.! particular issue of the newsletter.  An index will be created
.! that can be used to index a collection of newsletters (see
.! instructions below).
.!
.! To use this template to create a particular newsletter, copy
.! this template into a working directory and edit it, placing
.! the material of the newsletter into it.  Then run the Portable
.! Text Formatter:
.!
.!     ptf asrnews.ptf asrnews.doc
.!
.! The file ASRNEWS.DOC will be created.  This is the formatted newsletter.
.! The file PTF.IDX will also be created; this is the index data file.
.! It may be discarded.
.!
.! If it is desired to create an index of one or more newsletters,
.! issue a group command:
.!
.!     ptf news1.ptf news2.ptf ... newsN.ptf group.doc
.! or
.!     ptf _@group.inc group.doc
.!
.! This creates the file GROUP.DOC (which is not needed, since only the
.! index is desired) and the file PTF.IDX.  The next step is to process
.! the file PTF.IDX:
.!
.!     ptfidx
.!
.! This reads PTF.IDX and creates PTFIDX.PTF.  Finally, this file is
.! used to create the index itself:
.!
.!     ptf asrnewsi.ptf index.doc
.!
.! ASRNEWSI.PTF is another template which reads the file PTFIDX.PTF
.! to produce the desired index.  The file INDEX.DOC is the desired
.! index.
.comment

.comment
.! The following variables are to be set at this time.
.! The margins are set for ELITE type (12 chars/inch) and may
.! be changed if desired.
.comment
.vs DATE November 7, 1989
.vs NEWSID 202
.lm 13
.rm 90

.comment
.! Macros
.comment
.nr a 0
.! -------------------------------------------------------
.! .SECT 
.de SECT
.nr a +1
.nr b 0
.cl
.cl 0 @na. @1 @2 @3 @4 @5 @6 @7 @8 @9
.ce on
@na. @1 @2 @3 @4 @5 @6 @7 @8 @9
.ce off
.of /@na. @1 @2 @3 @4 @5 @6 @7 @8 @9//Page #/
.ef /Page #//@na. @1 @2 @3 @4 @5 @6 @7 @8 @9/
.en
.! -------------------------------------------------------
.! .SUBSECT <title>
.de SUBSECT
.nr b +1
.nr c 0
.cl 1 @na.@nb. @1 @2 @3 @4 @5 @6 @7 @8 @9
.sp
.ne 10
@na.@nb.
.ul
@1 @2 @3 @4 @5 @6 @7 @8 @9
.sp
.en
.! -------------------------------------------------------
.! .SUBSUBSECT <title>
.de SUBSUBSECT
.nr c +1
.sp
.ne 10
@na.@nb.@nc.
.ul
@1 @2 @3 @4 @5 @6 @7 @8 @9
.sp
.en
.! -------------------------------------------------------
.! .PP
.de PP
.br
.ti +5
.en
.! -------------------------------------------------------
.! .LIST
.de LIST
.li +5
.ri +5
.nr l 0
.en
.! -------------------------------------------------------
.! .LE <text>
.de LE
.nr l +1
.sp
.ti -4
@nl. @1 @2 @3 @4 @5 @6 @7 @8 @9
.en
.! -------------------------------------------------------
.! .ELIST
.de ELIST
.br
.li -5
.ri -5
.sp
.en
.! -------------------------------------------------------
.! .HEAD <text>
.de HEAD
.sp
.ce
.ul
@1 @2 @3 @4 @5 @6 @7 @8 @9
.br
.en

.comment
.! Title page
.comment
.sp 5
.ce on
ADA SOFTWARE REPOSITORY (ASR) NEWSLETTER

ISSUE @NEWSID, @DATE
.sp 5
.ul
Edited by
Richard Conn
Manager, Ada Software Repository

.ul
Published by
Management Assistance Corporation of America, Inc. (MACA)
PO Drawer 100 - Building T148
White Sands Missile Range, New Mexico  88002
505/678-3288
.sp 5
.ul
Sponsor
The Ada Software Repository and this Newsletter
are sponsored by
The STARS Joint Program Office,
Defense Advanced Research Projects Agency
and
The US Army Information Systems Command,
White Sands Missile Range
.spaceto -6
.ul
Disclaimer
.ce off
.sp
Statements made in this newsletter
are the opinions of the individuals making them
and are not necessarily
the opinions or policy statements
of the US Government or any other organization.

.nlheader 3
.he 1 //Ada Software Repository Newsletter//
.he 2 /Issue @NEWSID//@DATE/
.pn arabic @NEWSID-#
.bp 1
.fo //#//
.SECT Articles
.sp
.PP
The first seven articles
in this section continue a discussion from the last newsletter
on the topics of software quality and the impact of creating quality software
within schedule and budget constraints.  These articles were extracted from
the SW-COMP electronic mailing list.  The last articles, on computer viruses,
popular files in the ASR, and the SW-COMP and USENET feed, are ASR-specific.
.SUBSECT Schedule and budget are secondary
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 10 Oct 89 23:25:21 GMT
From: ico!vail!rcd_@handies.ucar.edu  (Dick Dunn)
.fi
.PP
billwolf%hazel.cs.clemson.edu_@hubcap.clemson.edu
(William Thomas Wolfe, 2847 ) writes:
.index Wolfe, William Thomas
.nf
> >>    ...We're here to engineer products on time, under budget,
> >>    and with as much quality as we can get within those two constraints.
> > ...It's particularly
> > sad to see "quality" a poor third to the other two.
>    If the product does not meet the minimal standards of acceptability,
>    then it is not complete.  "On time", etc., refers to the product
>    being completed in accordance with the relevant quality requirements.
.fi
.PP
"Quality" software is MUCH more than software which meets "the minimal
standards of acceptability", thank you.
.index quality software
.index software, quality
.index acceptability, min stds for
.PP
A piece of software may be judged to have been "completed" on time and
.index completed software (defn)
.index software, completed (defn)
within budget if it meets its stated requirements within those constraints.
The requirements are going to be objective criteria--such as tasks the
software must perform, performance and size limits, etc.  They MUST be
objective criteria in the (very common) case where the requirements are
part of the negotiated contract for the software project.
.PP
It is entirely possible to construct software which meets all such
requirements, but which is poorly conceived or implemented.
Examples abound.  I
know of no way to specify software requirements such as "must be able to
survive the next five years of changes, to meet new needs, hacked in by
bored second-string maintenance programmers..."  But that's often what
quality software needs.
.PP
Sometimes software doesn't need high quality--sometimes the minimal hack
that meets the short-term requirements is enough!  The "lowest bidder"
approach is OK sometimes, but not universally.  Most software far outlives
its originally estimated/intended life.  It is more common to find ourselves
with software under-engineered than over-engineered.  My personal
peeve here is that I spend far too much of my time reworking under-engineered
hacks back into decent code that can survive.  So I see an extreme
focus on budget/schedule as needlessly increasing the amount of such work I
have to do.
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 10 Oct 89 23:52:32 GMT
From: ico!vail!rcd_@handies.ucar.edu  (Dick Dunn)
.fi
.PP
itkin_@mrspoc.Transact.COM (Steven M. List) writes:
.index List, Steven M.
.nf
>...In reading what Dick said, I can only believe that he's never worked on
> a project for which someone ELSE was paying.  Or a project for which the
> market window is critical to the continued survival of the company or the
> project or the product...
.fi
.PP
You are quite wrong on both counts.  I have worked on both for many years;
currently most of my work falls into projects paid for by customers.  I
think it's not that we are in any fundamental disagreement (we'll see) so
much as that we're driving at different points.
.sp
.nf
> Dick's statements strike me as somewhat ivory tower.  While those of us
> who consider ourselves professionals in the field of "software engineering"
> presumably ALWAYS strive for quality products, we can't just turn off our
> systems and refuse if someone comes along and says "we have a deadline".
.fi
.PP
Understood completely.  I'm NOT trying to put quality at the very top of
the list, to the exclusion of schedule and budget...but I want to get
schedule/budget off the top of the list.
.PP
One of the things we have to consider in bidding a software project is that
.index software costing
.index costing, software
we want to set a reasonable cost which will allow us to produce a product
of sufficient quality that the customer is not only happy with it in the
short-term (meeting the immediate needs) but in the long term when it comes
time to modify it.
.PP
If it's our own product, we don't want to do a quick hack that will save us
10% on the first release and cost us 50% more in the second release when we
have to repair the damage we did by hurrying.  Sometimes, market pressures
are extreme enough that it's the only way to hit close enough to the market
window that there can BE a second release--but we need to avoid that.
.sp
.nf
>     "How much can I get in that meets MY/OUR/OUR CUSTOMER'S standards
>     of quality within the time and budget constraints set forth?  Can
>     we modify the constraints?  Are we willing to adjust our standards?"
.fi
.PP
This is a good statement.  The software MUST meet its requirements, but
that's a separate issue.  We MUST schedule enough time and money to do
that.  Then we try to schedule enough to produce a product of sufficient
quality that we won't hate ourselves for it later on.
.sp
.nf
> Dick's statement that producing a schedule that meets a lower confidence
> factor would permit a favorable decision is frightening to me.  This
> implies that it's okay to plan based on 80% or 70% or lower confidence.
.fi
.PP
Sure--why not?  Wait, let me qualify that...There are circumstances where
it's OK to work at that confidence level.  Just remember that nothing is
black and white here.  Suppose we're talking about a product aimed at a
particular market window.  What's the accuracy of the end date on the
market window?  Probably 50% at best!  (That is, the window is at least as
likely as not to close AFTER the estimated end date.)  Also, the window
doesn't just slam shut...it means that the longer you delay, the smaller
your market share.  You have to work with the probabilities involved.  If
there's a 70% chance you can make the stated market window, you also need
to know something like what your 90%-confidence completion date is, and
whether that might come in acceptably close to the window that it will
still give you a good product--enough to make some money even if not as
much as you "should" make.
.PP
There are literally SCORES of other factors to consider.  The better the
condition of the company, the more of a gamble you can afford to take.  You
may build the company's reputation in a new technology area; you may gain
expertise you need as a side-effect of the project.
.PP
You have to look at the type of contract you're going to work with, if
it's contract work.  You can bid base cost plus T&M at a lower confidence
level than fixed-price, which in turn can be lower than
fixed-price-with-penalty-for-late,
which is different from fixed-price-with-bonus-for-early,
etc. to endless detail.  Sometimes you don't even bid because the terms
your customer wants don't fit with the amount of risk (which translates
into level of confidence for a plausible schedule) for the project.
.sp
.nf
> This implies that he is willing to proceed based on the assumption that
> HE CANNOT SUCCEED in meeting time or budget constraints...
.fi
.PP
No, it implies that I might be willing to proceed even with the knowledge
that the desired (ideal) outcome is less than certain.  But it involves
lots of other considerations, per above, if you're going to go ahead from a
lower confidence value.
.sp
.nf
>...Dick - who's
> funding you?...
.fi
.PP
Our customers.
.sp
.nf
>...What happens when the date for which you had 70%
> confidence comes and goes?  Who eats it?...
.fi
.PP
If the project is begun at a low confidence level, there will be aspects of
the contract which anticipate that.  If an estimate carries a low confidence,
that's taken into account.
.sp
.nf
>...I would rather produce a
> realistic project plan up front, including specifying the compromises,
> than to produce a falsely optimistic plan with a qualifier ("this is
> only 70% certain") and have to scramble to adjust near the end.
.fi
.PP
It depends on what the curve of confidence level vs schedule looks like.
All such curves have a tail asymptotic to 100%.  With some, the shape of
the tail heading out past 75% or so is unpleasantly long...that tells you
that the project is riskier than average, and you have to decide whether
you can live with the risk.
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 11 Oct 89 15:22:59 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )
.fi
.PP
From rcd_@ico.ISC.COM (Dick Dunn):
.index Dunn, Dick
.nf
>> >>    ...We're here to engineer products on time, under budget,
>> >>    and with as much quality as we can get within those two constraints.
>> > ...It's particularly
>> > sad to see "quality" a poor third to the other two.
>>    If the product does not meet the minimal standards of acceptability,
>>    then it is not complete.  "On time", etc., refers to the product
>>    being completed in accordance with the relevant quality requirements.
> 
% It is entirely possible to construct software which meets all such require-
% ments, but which is poorly conceived or implemented.  Examples abound.  I
% know of no way to specify software requirements such as "must be able to
% survive the next five years of changes, to meet new needs, hacked in by
% bored second-string maintenance programmers..."  But that's often what
% quality software needs.  [...] My personal peeve here is that I spend 
% far too much of my time reworking under-engineered hacks back into 
% decent code that can survive.  So I see an extreme focus on 
% budget/schedule as needlessly increasing the amount of such work I
% have to do.
.fi
.PP
This depends upon whether the product is implemented by hackers
or by professionals.  A professional will meet cost and schedule
constraints by using CASE tools, advanced programming languages,
and so on, using overtime as the last resort.  A professional
knows that developing modular, readable software not only helps
make the software maintainable, but also reduces the probability
that the product will be delayed due to errors and reduces the time
that will be required to correct errors if they are discovered,
thereby enhancing the probability of meeting scheduling constraints.
.PP
Dick's particular environment is one in which operating system 
software is being developed in C, a double whammy as far as a 
well-established tradition of hacking is concerned.  In such an
environment, great efforts must be taken on the part of management
to ensure the existence of a proper software engineering orientation.
.SUBSUBSECT From Jeff Hallett
.index Hallett, Jeff
.nf
Date: 11 Oct 89 17:06:55 GMT
From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu
  !mrsvr.UUCP!positron.uucp!hallett_@tut.cis.ohio-state.edu
  (Jeff Hallett x5163 )
.fi
.PP
In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
.nf
>It is entirely possible to construct software which meets all such require-
>ments, but which is poorly conceived or implemented.  Examples abound.  I
.fi
.PP
Therefore   it  is  time  someone   addressed  the  issue   of how  to
quantitatively    specify    nebulous  terms   like "user   friendly",
"maintainable", "extendible", etc.  In  a requirements document, these
terms have no meaning aside from the warm and  fuzzy connotations.  To
quote Star Trek: The Next   Generation ("Samaritan Snare"), the  space
moron stated : "We look for things: things  to make us go."  Sure, but
quantify it. 
.index user friendly software
.index software, user friendly
.index well-written software
.index software, well-written
.PP
How   does  one  specify  a  requirement   for "user  friendliness" or
"well-written"? 
.SUBSUBSECT From Richard S D'Ippolito
.index D'Ippolito, Richard S.
.nf
Date: 11 Oct 89 21:46:47 GMT
From: sei!rsd_@pt.cs.cmu.edu  (Richard S D'Ippolito)
.fi
.PP
In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
.nf
>It is entirely possible to construct software which meets all such require-
>ments, but which is poorly conceived or implemented.  Examples abound.  I
>know of no way to specify software requirements such as "must be able to
>survive the next five years of changes, to meet new needs, hacked in by
>bored second-string maintenance programmers..."  But that's often what
>quality software needs.
.fi
.PP
There are ways to do it.  One can generally anticipate the areas of change,
especially in large systems where there is a long history of changes.
.PP
For example, suppose you require software for a flight trainer used to
simulate operation at several airports, i.e., the characteristics of the
airports are used to drive the simulated display and the cockpit
instruments.  Can't it be required that the capability of changing the
airport(s) be designed in?  It is possible for the contractor to include in
his bid the effort (read "cost") to do this.
.PP
Suppose you are building a C3I system based on a large number of
electronically received messages which have to be translated and validated
before being stored in a database.  Should you not require the contractor at
proposal time to tell you the cost of adding or deleting new messages, some
of which are of the same types and some of which are probable new types (if
known)?
.PP
There are many other examples I could give, as these types of systems have
been around long enough for us to have a good idea of the nature of the
expected changes.  It merely requires the program office to request the cost
of the anticipated changes in the proposals.
.PP
As you can see, the contractor (read "software engineer") is going to need
some concrete idea of what he's going to build in order to be responsive,
but, hey, isn't that true of other engineers?
.PP
Watch for it -- happening soon to a contractor near you!
.SUBSUBSECT From Phil Meyer
.index Meyer, Phil
.nf
Date: 11 Oct 89 22:10:39 GMT
From: gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!texbell
  !vector!attctc!phil_@tut.cis.ohio-state.edu  (Phil Meyer)
.fi
.PP
In article <6742_@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
_@hubcap.clemson.edu writes:
.index Wolfe, William Thomas
.index Dunn, Dick
.nf
>From rcd_@ico.ISC.COM (Dick Dunn):
>
>    This depends upon whether the product is implemented by hackers
>    or by professionals.
.fi
.PP
Haven't we had the hacker vs. professional wars before?  I am reminded of the
fortune "A poor workman blames his tools".  It is also a poor workman who
must blame tools for other's inferior workmanship.  This next statement
suggests that you are not professional if you do not use CASE tools.  Pretty
silly.  Most developers are still eyeing CASE.
.sp
.nf
>    A professional will meet cost and schedule
>    constraints by using CASE tools, advanced programming languages,
>    and so on, using overtime as the last resort.
.fi
.PP
This last line is the killer.  If you don't work your butt off, you don't
.index overtime
work for me!  If the job needs doing, you stay 'till it's done.  What is this?
Bankers ethics in the computer center?  Forget it!
.sp
.nf
>    Dick's particular environment is one in which operating system 
>    software is being developed in C, a double whammy as far as a 
>    well-established tradition of hacking is concerned.  In such an
>    environment, great efforts must be taken on the part of management
>    to ensure the existence of a proper software engineering orientation.
.fi
.PP
This statement applies to ANY environment.  It may be true that sloppy
programmers working in a CASE environment can produce better code than
without CASE, but steps must still be taken to insure that guys like you who
won't stay past quitting time, don't just throw stuff together!
.PP
This isn't really a flame, I was just suprised to see stuff like this in
a news group where I'm certain that most participants dream of the day
when they can work 'regular' hours.
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 12 Oct 89 01:30:55 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )
.fi
.PP
From phil_@attctc.Dallas.TX.US (Phil Meyer):
.index Meyer, Phil
.nf
>>    A professional will meet cost and schedule
>>    constraints by using CASE tools, advanced programming languages,
>>    and so on, using overtime as the last resort.
> 
> [...]  I'm certain that most participants dream of the day when 
> they can work 'regular' hours.
.fi
.PP
First, the context: my work experience so far has been with a 
company which had to actually pay time-and-a-half for overtime, 
which is usually a VERY expensive way to trade cost for schedule.  
.index overtime
.PP
Also, Phil misinterprets my position.  The idea is to maximize the 
use of productivity tools FIRST; simply throwing time at the problem
makes little sense UNLESS we have already done all the things that
can be done to minimize the difficulty of solving it.
.SUBSUBSECT From Linda Mundy
.index Mundy, Linda
.nf
Date: 11 Oct 89 22:49:07 GMT
From: pacbell!rtech!linda_@ames.arc.nasa.gov  (Linda Mundy)
.fi
.PP
In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
.sp
.index Wolfe, William Thomas
.nf
>billwolf%hazel.cs.clemson.edu_@hubcap.clemson.edu
  (William Thomas Wolfe, 2847 ) writes:
[...some discussion of "on time, under budget" vs. "quality", deleted...]

>"Quality" software is MUCH more than software which meets "the minimal
>standards of acceptability", thank you.
>
[...more good stuff deleted...]
>
>It is entirely possible to construct software which meets all such require-
>ments, but which is poorly conceived or implemented.  Examples abound.  I
>know of no way to specify software requirements such as "must be able to
>survive the next five years of changes, to meet new needs, hacked in by
                                                            ^^^^^^^^^^^^
>bored second-string maintenance programmers..."  But that's often what
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>quality software needs.
>
.fi
.PP
Dick, I really agreed with the main points of your article, making the above
remark come as a surprise.  Not picking you in particular, but this is
such a common attitude towards maintenance programmers, I thought it might be
appropriate as a topic of discussion in its own right.  So I ask you:
.LIST
.LE
do you think maintenance work is easier than development work?
always?  sometimes? never?  does your answer change for large
systems vs. small systems?
.LE
do you think that maintenance programming belongs lower on the
"pecking order" than development programming?
.LE
do you think that such presumptions are likely to help people work
together more effectively?
.LE
do you think that software engineers should do a stint at
maintenance, or do you think that maintenance is a place to
put the (perceived to be) less talented?
.index maintenance programming
.index programming, maintenance
.LE
do you think maintenance should be a separate function, or that
developers should be responsible for maintaining their own
code (as much as possible)?
.LE
do you think that there are different skill sets for maintenance
vs. development?  if so, is one skill set "better" than
another?
.ELIST
.PP
You can probably tell, you hit one of my hot buttons.  I personally think that
any new, just-out-of-school programmer should do maintenance work for awhile
(assuming, of course, that the company already has a product!)  It will
introduce them to the product they will be working on, in a context where they
can both learn and have something to show for it.  It will introduce them to
the prevailing coding style.  It will introduce them to the many pitfalls
and pratfalls that lead to bugs, thus hopefully teaching them how to avoid
same.  It may introduce them to the real-world effects of software bugs on
customers, thus improving their attitudes towards software quality.  etc., etc.
But the most important point:  don't diminish people because of their relative
positions.  It can't do any good -- in fact, it is exactly such attitudes that
lead to "bored, second-string" employees -- wherever they happen to be in the
organizational structure.
.PP
As I said before, this is not meant as a flame, and judging by your other
statements, I doubt that we are in basic disagreement.  Of course, I could
be wrong!  (but only about the previous statement...;-))
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 12 Oct 89 03:54:08 GMT
From: gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!ico!vail
  !rcd_@tut.cis.ohio-state.edu  (Dick Dunn)
.fi
.PP
I was gritching about quality being given short shrift, and had pointed out
that software can be constructed which meets all objective requirements,
yet is of poor quality.
.sp
.nf
>     This depends upon whether the product is implemented by hackers
>     or by professionals...
.fi
.PP
Hey, groovy...we'll just get our customers to add a clause to the contract
to require that "All software shall be implemented by professionals.
Hackers shall not be employed..." and nobody will have to worry about poor
quality software any more, right?
.PP
Of course good people will produce better software than bad people.  That
is true, but irrelevant to the point I was trying to make--which is that
the relative emphasis on quality will influence the result.  A good
programmer, under extreme time/budget pressure, will likely be able to
produce better-quality software than a dullard working at leisure who
codes with a chainsaw .  But the professional won't do as good a job as if
there were more external interest in quality and less extreme time/money
pressure.
.sp
.nf
>...A professional will meet cost and schedule
>     constraints by using CASE tools, advanced programming languages,
>     and so on...
.fi
.PP
No.  A professional will use the tools suitable for the job (perhaps
creating them if appropriate).  A professional will focus on the job of
constructing good software, and will leave the buzzword-oriented
programming to the acolytes of strongly-hyped languages.  (apologies to
Andrew Koenig)
.PP
And what's this about advanced programming languages?  Wolfe has, in other
postings, been an outspoken advocate of Ada, which is certainly *not*
advanced.  In fact, the difficulty of making Ada catch up to current
technology has been a hot topic over in comp.lang.ada.
.sp
.nf
>     Dick's particular environment is one in which operating system 
>     software is being developed in C, a double whammy as far as a 
>     well-established tradition of hacking is concerned...
.fi
.PP
There is operating system software developed in C at Interactive Systems.
That's not what I'm doing, although that is irrelevant.  C is well suited
to the task.  (Most of the OS work is, for example, better done in C than
in C++.  But you have to understand what "most of the work" is about, and
that's another topic.)
.PP
The "well-established tradition of hacking" is an empty insult, a
manifestation
of Wolfe's inability to mount any substantive objection.  C works. 
UNIX works.  They've lasted well, and survived incredible amounts of
modification
and adaptation.  All the cheap insults you can dream up won't change
that.  We'll trade taunts with you for a while; then we'll let you go back
to *talking* about software while we *produce* software.
.PP
Don't get me wrong--C is *not* The One True Way.  (That's religion, which
.index C
is anathema:-)  C is *a* way to get things done, and done both well and
expeditiously.  There are other languages and tools--some of them more
appropriate to their problem domains than C could be.
.sp
.nf
>	In such an
>     environment, great efforts must be taken on the part of management
>     to ensure the existence of a proper software engineering orientation.
.fi
.PP
Not at all.  You just get good people who know what they're doing, and make
room for them to do their jobs.  Good management does not direct; it
assists.
.PP
The people I work with are not the people who produce the nasty code I was
complaining about in my earlier posting.  In fact, some of the nastiest
code was produced as a result of blind, dogmatic application of so-called
software engineering principles.  It's gotten them into binds.  We have to
help them out, help clean up the messes, and get the software headed back
in a reasonable direction.  We do it in C (since that's what all of them
are using), without dogma and buzzwords.  Sometimes we have to tell them
that getting back to quality software is going to cost a little more and
take a little longer than the "shortest path" to meeting the immediate
requirements.  When we can make a good case for it, they're likely to go
for it--because they've seen how we work and they appreciate the long-term
benefits.  We budget and plan for quality work; we don't "lowball"
contracts.
.SUBSUBSECT From Steve Shapland
.index Shapland, Steve
.nf
Date: 12 Oct 89 16:27:50 GMT
From: ico!vail!sps_@handies.ucar.edu  (Steve Shapland)
.fi
.PP
In article <3807_@rtech.rtech.com> linda_@rtech.UUCP (Linda Mundy) writes:
.index Mundy, Linda
.sp
.index Dunn, Dick
.nf
>In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
>>I know of no way to specify software requirements such as "must be able to
>>survive the next five years of changes, to meet new needs, hacked in by
>                                                            ^^^^^^^^^^^^
>>bored second-string maintenance programmers..."  ...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     .....  I personally think that
>any new, just-out-of-school programmer should do maintenance work for awhile
>(assuming, of course, that the company already has a product!)  It will
>introduce them to the product they will be working on, in a context where they
>can both learn and have something to show for it.  ...
.fi
.PP
I agree with the policy of assigning rookie programmers to maintenance
tasks.  The learning experience is wonderful.  Most companies I've
worked for tend to follow this policy, and I believe that this is
what leads to Dick's view of maintenance programmers.
.LIST
.LE
"hacked" -
Being rookies, they are still learning the product, style,
and problems of real-world (large complex systems) programming.
Their code tends to lack the polish of craftsmanship.
.LE
"bored" -
Being youthful, they still possess the dream of setting the 
world on fire. "Enough of this working on last year's code,
I want to design the next major system."  They are being forced
to walk when they want to run. 
.LE
"second-string"
Of course they're second-string.  They still have to prove
themselves to management; and until they do, the more senior
people of the team continue to carry the ball.
.ELIST
.PP
There is yet another reason for assigning junior programmers to
.index maintenance programmers
.index programmers, maintenance
maintenance tasks.  Don't forget that maintence represents ~80% of
the life cycle costs of a software product.  By assigning programmers
from the low end of the pay scale, these costs may be reduced.
.PP
All of the above sounds brutal, but the benefits, to both the
programmers and the companies who pay their salaries, are very
significant.
.PP
My pet peeve regarding quality software is programmers
who insist on the status quo, without considering improvements in
their toolkits and development processes.  These programmers are
still producing code with last year's methods and setting poor
examples for the junior programmers who have to fix that code next year.
.PP
Quality development is an continual spiral.  As you introduce
quality improvements, the quality of the each succeeding product
generation improves.  The inverse is also true.  If you do not
introduce quality improvements in the development process,
the quality of the future products continues to deteriorate.
The real problem for management is the intial cost of getting into
the right spiral.  Once on the proper path,
quality methods becomes second nature.
.SUBSUBSECT From Ted Dunning
.index Dunning, Ted
.nf
Date: 12 Oct 89 16:41:43 GMT
From: opus!ted_@lanl.gov  (Ted Dunning)
.fi
.PP
In article <3807_@rtech.rtech.com> linda_@rtech.rtech.com
  (Linda Mundy) writes:
.index Mundy, Linda
.sp
.nf
   In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:

	...
   I personally think that any new, just-out-of-school programmer
   should do maintenance work for awhile (assuming, of course,
   that the company already has a product!)
	...
.fi
.PP
Why wait until then?  one of the most important things that any
course in software engineering should have students do is work on
a large system.  for that matter, so should _all_ but the most
basic courses.  if you have compiler class, make them work on a
real compiler, in a course on semantics, make them work with the
semantics of a real language.
.sp
.nf
	...
   But the most important point: don't diminish people because of
   their relative positions.  It can't do any good -- in fact, it
   is exactly such attitudes that lead to "bored, second-string"
   employees -- wherever they happen to be in the organizational
   structure.
	...
.fi
.PP
I am not sure that Dick was trying to diminish people asmuch as
he was just observing that the programmers who do maintenance
and typically _are_ bored, typically _are_ second-string.
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 12 Oct 89 21:50:44 GMT
From: ico!vail!rcd_@handies.ucar.edu  (Dick Dunn)
.fi
.PP
linda_@rtech.rtech.com (Linda Mundy) writes about my comment that one
.index Mundy, Linda
.index survivability, software
.index software survivability
hard-to-pin-down aspect of new-code quality might be:
.sp
.nf
> >..."must be able to
> >survive the next five years of changes, to meet new needs, hacked in by
>                                                             ^^^^^^^^^^^^
> >bored second-string maintenance programmers..."  ...
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

She says:
> Dick, I really agreed with the main points of your article, making the above
> remark come as a surprise.  Not picking you in particular, but this is
> such a common attitude towards maintenance programmers, I thought it might
> be appropriate as a topic of discussion in its own right...
.fi
.PP
I agree with Linda's sentiments.  Now, to be clear about why I said what I
did:  It IS a common attitude toward maintenance programmers.  It's an
unfortunate, stupid, misdirected attitude.  Not only do I NOT agree with
it; it makes me angry.  BUT it's there, and has to be reckoned with.  In
other words, I pointed out that quality software needs to survive being
hacked over by bad maintenance programmers not because maintenance SHOULD
be done that way, but because it WILL be done that way, in all likelihood.
You have to make the software a little hardier than it should need to be
in order to survive what it will be put through.
.PP
Maybe I should also have been careful with the wording so that it would
have been clear that I meant (second-string) (maintenance programmers), as
opposed to (second-string maintenance) programmers.
.sp
.nf
> 	-- do you think maintenance work is easier than development work?
.fi
.PP
Sometimes it is - routine changes may be very easy to make.  Sometimes it's
not - the effects of an apparently small change may run across the grain
and affect a large part of the code, requiring exceptional perspicacity to
keep from screwing up the code.
.sp
.nf
> 		...does your answer change for large
> 		systems vs. small systems?
.fi
.PP
My initial reaction is that it doesn't.  It changes depending on the
structure of the system.  The more interconnected a system is, the harder
some changes are.
.sp
.nf
> 	-- do you think that maintenance programming belongs lower on the
> 		"pecking order" than development programming?
.fi
.PP
As a rule, no.  However, it is usually PLACED lower in the pecking order.
Sometimes, maintenance work can be used effectively for training--in this
sense, you spend time learning an existing body of code, understanding how
things are done, seeing problems, etc., before you go create new code.
It works if it's done carefully.
.sp
.nf
> 	-- do you think that software engineers should do a stint at
> 		maintenance, or do you think that maintenance is a place to
> 		put the (perceived to be) less talented?
> 	-- do you think maintenance should be a separate function, or that
> 		developers should be responsible for maintaining their own
> 		code (as much as possible)?
.fi
.PP
All software engineers should spend time on maintenance.  Since maintenance,
in the general sense which includes modification, porting, and the like, is
MOST of what software folk spend their time doing, having people work only
on new code puts them a bit out of touch with reality.
.PP
One approach is to assign people to a software project "cradle to grave."
That is, if you write it you maintain it.  You get to take on a new project
when the work load for the old one drops below some threshold.  This has
an interesting incentive--if you want to work on new stuff, you may be more
careful getting things right so you don't have to do a lot of maintenance
time.  The approach also has a handful of flaws, but it's worth exploring
it in some environments.
.sp
.nf
> 	-- do you think that there are different skill sets for maintenance
> 		vs. development?  if so, is one skill set "better" than
> 		another?
.fi
.PP
We need to get development and maintenance to equal prestige.  There are
people who LIKE to work on existing code, shaping it to new needs.  There
are others who are better at cutting from whole cloth; they have trouble
reworking other people's code.  We should be able to accommodate these
different abilities.
.sp
.nf
> You can probably tell, you hit one of my hot buttons...
.fi
.PP
Yes, and I did so unintentionally; it seems that we're mostly in agreement.
But it's just as well.  It's a topic that needs to be dragged out into the
open periodically.  It has been realized for perhaps two decades that
maintenance tasks are perceived as "inferior" in many organizations.  It
has also been realized that this leads to poor maintenance.  But we perpetuate
those damaging stereotypes.
.SUBSUBSECT From Travis Marlatte
.index Marlatte, Travis
.nf
Date: 13 Oct 89 14:05:26 GMT
From: gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!mailrus
  !accuvax.nwu.edu!delta.eecs.nwu.edu!travis_@tut.cis.ohio-state.edu
  (Travis Marlatte)
.fi
.PP
I don't see the reasoning that novice programmers should be given the
task of maintaining existing systems. I also don't see the reasoning that
thou who creates it will maintain it even unto ball and chain.
.PP
Simple analogy: A team of crack engineers build a beautiful and structurally
sound bridge that serves its purpose well. Five years after construction,
it is learned that the foundation at one end is giving way due to water
damage. The company assigns its newest employee to the task of designing
the correction to the problem.
.PP
Sounds absurd to me! I would hope it sounds absurd to the rest of you too.
Isn't the analogy correct. Why would I want to assign inexperienced staff
to the task of shoring up existing systems? Especially, since we know that
mainenance is often a task of stretching the intent of the original design
to meet current expectations. Further, why would I want my newest employee
dedicated to mastering 5 year old technology?
.PP
Why does the idea of an apprentice not spring to mind quickly? Would it not
be better to have a junior programmer (or junior software engineer or
junior whatever) position? This position may very well get stuck with a
load of grunt work tasks. But, the work would ultimately be the
responsibility of a senior person who guides the work of the junior.
.PP
The work would then include a mix of maintencance and latest and greatest
design - whatever the senior staff was working on. By blending the work
of the past with the work of the new, the junior member gets an introductory
view of the whole picture. Technology transfer through sharing rather than
dumping - dumping unwanted, undesirable tasks on a new hire.
.PP
This type of idea can be taylored to each situation. A company developing
coin machines may have a six month apprentice program. A company developing
chemical process control might have a 5 year program.
.PP
I have a friend working as a actuary. For advancement, they have to take
a series of tests that may take up to ten years to complete. Their status
as an actuary depends on the level they have achieved in taking the tests.
.PP
While I don't think the software business is as structured as the insurance
business, my point is that a training program for newcomers should not be
shuned. It should not be embarassing to be considered a junior staff member.
Of course, there is cause to celebrate when that day comes that you are
no longer considered a junior.
.PP
By the way, my first job out of school was as a maintenance programmer
for control systems. I didn't mind doing it but it certainly was a waste
of time. Only by becoming involved in curent design effort does one come
to understand the task of doing current design.
.SUBSUBSECT From Phil Meyer
.index Meyer, Phil
.nf
Date: 13 Oct 89 19:33:00 GMT
From: attctc!phil_@ames.arc.nasa.gov  (Phil Meyer)
.fi
In article <1271_@accuvax.nwu.edu> travis_@delta.eecs.nwu.edu
.index Marlatte, Travis
(Travis Marlatte) writes:
.sp
.nf
>
>Why does the idea of an apprentice not spring to mind quickly?
.fi
.PP
Travis has a good point here.  The analogy to a wizard's apprentice is even
better.  How do you become a wizard?  By studying with/for a wizard.
(or rather, what is the BEST way)
.PP
We must also cultivate a love of the craft.  This is the real difference
between being bored (in any position) and being happy with the workload.
.PP
Many really good programmers do it because they couldn't think of doing
anything else.  "Give me a workstation and a place to sit, and I'm happy." is
a common attitude among the wizards I have known.  The specific task, whether
it be maintainance or design, is seldom mentioned.  But rather, the usuall
conversations amongst these people lean towards new constructs, difficult
passages, tools, the latest and greatest hardware, etc. etc.
.SUBSUBSECT From Jim Barnes
.index Barnes, Jim
.nf
Date: 13 Oct 89 12:16:26 GMT
From: xylogics!barnes_@CS.BU.EDU  (Jim Barnes)
.fi
In article <16202_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
.sp
.nf
>
>One approach is to assign people to a software project "cradle to grave."
>That is, if you write it you maintain it.  You get to take on a new project
>when the work load for the old one drops below some threshold.  This has
>an interesting incentive--if you want to work on new stuff, you may be more
>careful getting things right so you don't have to do a lot of maintenance
>time.  The approach also has a handful of flaws, but it's worth exploring
>it in some environments.
.fi
.PP
One disadvantage to this approach is that it will encourage turnover of
personnel.  "I'm tired of just doing maintenance and since I can't get
assigned to some new development, I'll just go somewhere where I CAN work on
something new."  Then you have to hire new programmers to do maintenance
anyway.
.sp
.nf
>We need to get development and maintenance to equal prestige.  There are
>people who LIKE to work on existing code, shaping it to new needs.  
.fi
.PP
I agree, but it seems that it is very hard to find these people.  Maybe
the truly good maintenance programmers do not change jobs very often.
.SUBSUBSECT  From Jim Bander
.index Bander, Jim
.nf
Date: 13 Oct 89 23:20:52 GMT
From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth
  !bander_@tut.cis.ohio-state.edu  (Jim Bander)
.fi
In article <1189_@mrsvr.UUCP> hallett_@gemed.ge.com
(Jeffrey A. Hallett (414) 548-5163) writes:
.index Hallett, Jeffrey A.
.sp
.nf
>
>Therefore   it  is  time  someone   addressed  the  issue   of how  to
>quantitatively    specify    nebulous  terms   like "user   friendly",
>"maintainable", "extendible", etc.  In  a requirements document, these
>terms have no meaning aside from the warm and  fuzzy connotations.  To
>quote Star Trek: The Next   Generation ("Samaritan Snare"), the  space
>moron stated : "We look for things: things  to make us go."  Sure, but
>quantify it. 
>
>How   does  one  specify  a  requirement   for "user  friendliness" or
>"well-written"? 
.fi
.PP
I'm not sure anyone will ever QUANTIFY user-friendliness in a way that would
.index user friendly software
.index software, user friendly
help me design better systems.  But Paul Heckel (formerly of PARC)
.index Heckel, Paul
SPECIFIED the requirement 30 useful ways in
.ul
The Elements of Friendly Software Design
(Warner Books, 1984).  His point is that software 
designers who think like engineers are doomed to fail, as was Thomas Edison
when he tried to make movies.  Engineers develop the medium; writers and 
artists  use it to communicate effectively!
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 13 Oct 89 20:50:08 GMT
From: usc!ginosko!cs.utexas.edu!ico!vail!rcd_@ucsd.edu  (Dick Dunn)

.index D'Ippolito, Richard S.
rsd_@sei.cmu.edu (Richard S D'Ippolito) writes:
> ... rcd_@ico.ISC.COM (Dick Dunn) writes:
[about the hard-to-pin-down adaptability needs]
> >..."must be able to
> >survive the next five years of changes, to meet new needs,...

> There are ways to do it.  One can generally anticipate the areas of change,
> especially in large systems where there is a long history of changes.
.fi
.PP
Yes, you can anticipate some of the needs.  But there's a whole continuum
of possible changes.  Some future needs are so explicit that you can
actually put provisions in your requirements that the code be "ready" for
the changes--in effect, what you do is specify and design for a feature;
you just don't implement it.
.PP
Next along the spectrum is the type of change Richard is talking about--
You may not be able to pin down the exact change you'll need, but you know
the general area and direction.
.PP
The type of change I'm interested in is all the way down at the other end
of the spectrum...the changes which will eventually come about because
someone comes up with a need and says, "Wait a minute!  What about the
xyzzy program?  Doesn't it do a lot of this stuff?  Could we adapt it to do
what we need?"  It may be an adaptation of the program to add a capability,
or you might clone the program and transmogrify the clone.
.PP
I don't have many clues of how to characterize or measure the adaptability
of code to such unanticipated needs.  I'm not even sure it makes sense to
try to measure it.  But I do know that it's common to look at recycling
code this way...and I know that "quality code" will allow it to happen.
.PP
It's hard to make analogies with other areas of engineering about this sort
of change, because software is so much more mutable.
.SUBSUBSECT From Lee Sailer
.index Sailer, Lee
.nf
Date: 13 Oct 89 14:43:55 GMT
From: psuvm!uh2_@psuvax1.cs.psu.edu  (Lee Sailer)

<16187_@vail.ICO.ISC.COM> <1189_@mrsvr.UUCP>

In article <1189_@mrsvr.UUCP>, hallett_@positron.uucp (Jeff Hallett x5163 )
says:
.index Hallett, Jeff
>How   does  one  specify  a  requirement   for "user  friendliness" or
>"well-written"?
>
.fi
.PP
I know many will scoff, but you can measure these things.  Just go ask a
social scientist, eg psychology, sociology, anthropology.  These guys
measure such fuzzy things all the time.  So, without further ado, here's
.index metrics
.index measuring user friendliness
.index measuring quality
.index user friendliness, measuring
.index quality, measuring
a brief course in Measurement:
.PP
What is a measure?
.PP
We have some concept from the world, like 'user friendly'.  The domain is
the set of all programs we are concerned with.  We'd need a function that
maps from the domain to something arithmetical, say the set of reals.
That function is a measure if some features of arithmetic on the
resulting reals behave in a way that reflects the behavior of the objects
in the domain.
.PP
Constructing that function is the art of measurement.
.PP
Example--User Friendliness
.PP
Let's use a spreadsheet as an example.  Prepare a test, say 8 or 10 problems
that spreadheet users should be able to solve.  To measure the user
friendliness
of spreadsheet X, choose 100 typical users at random, give them
some fixed amount of instruction, say 5 hours, and then give them the test.
The average score of those 100 users on the test is a number,  UF(X).
.PP
Repeat for spreadsheet Y with a new group of 100 users.  This produces a
number UF(Y).
.PP
In fact, for any spreadsheet Z there is in theory at least a number UF(Z),
so UF: Spreadsheets ------> reals is (within some variability from group
to group) a function.  I contend that if UF(X) > UF(Y) then spreadsheet
X is more user friendly than Y is, which makes UF an "ordinal" measure.
.PP
Comments
.PP
That's pretty expensive, isn't it?  Yes, it is.  Some things are easy to
measure.  The physical scientists snapped those up pretty early, eg
length, weight, temperature, strength.  Some things are hard, eg
time, space, subatomic thingies, and nearly all the stuff social
scientists are studk with.
.PP
Do UF(x)-UF(y) or UF(x)/UF(y) mean anything?  These arithmetic operations
may not be used on our example measure, UF.  However, techniques for
creating scales where these operations may be used are available, eg
Magnitude Scaling.
.PP
Where can I learn more?  The library, or course, is full of books.
Start with Research Methods in <blank>, where the blank is
any social science.
.PP
Measuring "well-written"
.PP
Give the code to the quality control team.  They study the code, and then
introduce bugs on purpose.  Give the code to another team that debugs it.
This produces several numbers:  the number of introduced bugs they find,
the number of introduced bugs they correctly fix, the number of new
bugs they find.  high scores for the first two indicate well-written
code, and high numbers for the second indicate poorly written code.
That's three measures.  You might stick them together with something
like
.sp
.ce
WW =  (measure1 + measure1)/measure3
.PP
Is this fuzzy and squishy?  Yes, of course it is.  More money poured on
the process would make the measurement more precise, valid, reliable, and
so on, but may not be worth it.
.SUBSUBSECT From Richard Sargent
.index Sargent, Richard
.nf
Date: 13 Oct 89 15:30:10 GMT
From: pantor!richard_@uunet.uu.net  (Richard Sargent)

.index Mundy, Linda
> From: linda_@rtech.rtech.com (Linda Mundy)
> Message-ID: <3807_@rtech.rtech.com>
> Date: 11 Oct 89 22:49:07 GMT
  ...
> Not picking you in particular, but this is such a common attitude
> towards maintenance programmers, I thought it might be
> appropriate as a topic of discussion in its own right.  
> 
.fi
.PP
Most companies I have encountered have the attitude that it takes a
particularly *skilled* person to be a *successful* maintenance programmer.
.PP
Think about it for a few moments: when you come along, pick up some else's
.index software maintenance
.index maintenance, software
code, have to find and fix a bug in the shortest possible time frame (since
it is delaying your customers!), and so on. Good maint.programmers are
worth their weight in gold (well, maybe silver :-) to companies which have
a significant investment in existing products.
.PP
In an ideal world, it would be nice if we developers didn't create
programs with any bugs, so maint.programmers would only have to deal
with enhancement requests, but it just ain't that way now, and won't
be for quite some time to come. :-(
.SUBSUBSECT From Richard Sargent
.index Sargent, Richard
.nf
Date: 13 Oct 89 14:46:20 GMT
From: pantor!richard_@uunet.uu.net  (Richard Sargent)

.index Meyer, Phil
> From: phil_@attctc.Dallas.TX.US (Phil Meyer)
> Message-ID: <9670_@attctc.Dallas.TX.US>
> Date: 11 Oct 89 22:10:39 GMT
> 
> In article <6742_@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
  _@hubcap.clemson.edu writes:
> >From rcd_@ico.ISC.COM (Dick Dunn):
.index Dunn, Dick
   ...
> >    A professional will meet cost and schedule
> >    constraints by using CASE tools, advanced programming languages,
> >    and so on, using overtime as the last resort.
> 
> This last line is the killer.  If you don't work your butt off, you don't
> work for me!  If the job needs doing, you stay 'till it's done.  What is
> this?  Bankers ethics in the computer center?  Forget it!
.fi
.PP
You've got to be joking! Sweatshops went out of fashion in the last century!
It is true that entrenpreneurial companies and start-ups require long hours
of the staff/owners, but sensible employers plan for their staff to be still
alive and functional so that they can do the next project.
.PP
Staff distracted/unhappy/etc. from divorces/miserable homelives/etc. or
burned out, etc. are poorer producers than those who aren't. Whether the
burnout takes 6 months, a year, or two isn't germane. Turn-over is *very*
expensive for companies
.PP
If a company can't budget a project to avoid burning out its staff, it is
in long-term trouble. There certainly circumstances where the 6 month
project just has to be done in 3 months, but if that is company policy,
you'll lose a lot of people.
.PP
*I* work to live, not live to work. I am fortunate to work in a field
that I enjoy. If my employer tried to make 16 hour days a policy, I
would switch to working for a bank faster than you could say "boo".
(They pay better and the fringe benefits are nice - low interest and
a pension plan, for starters. :-)
.PP
Enough said. I fully realize there as many rebuttals possible as there
are circumstances for everyone out there. This is my opinion: you don't
have to agree nor even like it.
.SUBSUBSECT From Linda Mundy
.index Mundy, Linda
.nf
Date: 13 Oct 89 23:19:46 GMT
From: pacbell!rtech!linda_@ames.arc.nasa.gov  (Linda Mundy)

.index Dunning, Ted
In article <TED.89Oct12104143_@kythera.nmsu.edu> ted_@nmsu.edu
(Ted Dunning) writes:
>
>In article <3807_@rtech.rtech.com> linda_@rtech.rtech.com (Linda Mundy)
>writes:
.index Mundy, Linda
.index Dunn, Dick
>   In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
>	...
>   I personally think that any new, just-out-of-school programmer
>   should do maintenance work for awhile (assuming, of course,
>   that the company already has a product!)
>	...
>why wait until then?  one of the most important things that any
>course in software engineering should have students do is work on
>a large system.  for that matter, so should _all_ but the most
>basic courses.  if you have compiler class, make them work on a
>real compiler, in a course on semantics, make them work with the
>semantics of a real language.
>
.fi
.PP
I certainly agree that could be a very useful approach; however, few if any
university CS programs operate that way.
.sp
.nf
>	...
>   But the most important point: don't diminish people because of
>   their relative positions.  It can't do any good -- in fact, it
>   is exactly such attitudes that lead to "bored, second-string"
>   employees -- wherever they happen to be in the organizational
>   structure.
>	...
>i am not sure that dick was trying to diminish people asmuch as
>he was just observing that the programmers who do maintenance
>and typically _are_ bored, typically _are_ second-string.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
.fi
.PP
I don't think he was *trying* to diminish people, yet that phrase
"second-string maintenance programmers" sure sounds like a stereotype
to me.  And your comments above perpetuate that stereotype.
.SUBSUBSECT From Linda Mundy
.index Mundy, Linda
.nf
Date: 16 Oct 89 19:12:05 GMT
From: oliveb!amdahl!rtech!linda_@apple.com  (Linda Mundy)
.fi
.PP
In article <16198_@vail.ICO.ISC.COM> sps_@ico.ISC.COM (Steve Shapland) writes:
.index Shapland, Steve
.nf
>In article <3807_@rtech.rtech.com> linda_@rtech.UUCP (Linda Mundy) writes:
>>In article <16187_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
>>>I know of no way to specify software requirements such as "must be able to
>>>survive the next five years of changes, to meet new needs, hacked in by
>>                                                            ^^^^^^^^^^^^
>>>bored second-string maintenance programmers..."  ...
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>     .....  I personally think that
>>any new, just-out-of-school programmer should do maintenance work for awhile
>>(assuming, of course, that the company already has a product!)  It will
>>introduce them to the product they will be working on, in a context where
>>they can both learn and have something to show for it.  ...
>
>I agree with the policy of assigning rookie programmers to maintenance
>tasks.  The learning experience is wonderful.  Most companies I've
>worked for tend to follow this policy, and I believe that this is
>what leads to Dick's view of maintenance programmers.
>
.fi
.PP
Well a few people have pointed out the apparent contradiction of (a) wanting
maintenance to be respected and (b) assigning rookies to do it.  First, I
did not say nor mean to imply that *only* rookies should be doing maintenance,
just that *all* rookies should do some.  None of this "this guy's too smart to
'waste' his time doing maintenance".  In my experience, even smart programmers
benefit a *lot* by exposure to the problems that occur when software gets out
there in the real world -- they see first-hand that software may be used in
ways that are not foreseen; they experience the agony of trying to debug
something which has bad error handling/lack of tracing facilities/ etc...
Hopefully, they learn from this how to code defensively.  
.SUBSUBSECT From Kurt Luoto
.index Luoto, Kurt
.nf
Date: 16 Oct 89 19:59:30 GMT
From: oliveb!amdahl!fai!kurtl_@apple.com  (Kurt Luoto)
.fi
.PP
In article <7402_@xenna.Xylogics.COM> barnes_@Xylogics.COM (Jim Barnes) writes:
.index Barnes, Jim
.sp
.nf
>In article <16202_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick

[ Some stuff deleted regarding assignment of personnel
  to maintenance programming ... ]

>>We need to get development and maintenance to equal prestige.  There are
>>people who LIKE to work on existing code, shaping it to new needs.  
>
>I agree, but it seems that it is very hard to find these people.  Maybe
>the truly good maintenance programmers do not change jobs very often.
>
>----
>  Jim Barnes (barnes_@Xylogics.COM)
.fi
.PP
I agree that finding people to stay with a project long-term is often
difficult.  I certainly don't have any easy solutions.
However, I think that we help continue the problem and the mindset that
gives rise to it by refering to "development programming" and "maintenance
programming" as if they were somehow very different things.
.index personnel
.index software maintenance
.index maintenance, software
In my humble experience, there really is no difference.
The cuttoff point for the "maintenance" phase of a product's life cycle is
completely arbitrary.  I don't change the way I program based on whether
the product has had a first release or not.  Certainly I have some different
problems when having to use or modify code that another person wrote
as opposed to code that I wrote myself, but I have dealt with that situation
even in the "development" phase.  Ever had a team member leave the company
in the middle of development?  I think a company can take a small step
towards resolution by officially not recognizing such an arbitrary
distinction between development and maintenance phases of a project.
.PP
I know that I'm not the first to voice the opinion,
but can't find the references at the moment.  Cheers.
.SUBSUBSECT From Linda Mundy
.index Mundy, Linda
.nf
Date: 16 Oct 89 19:52:14 GMT
From: oliveb!amdahl!pacbell!rtech!linda_@apple.com  (Linda Mundy)
.fi
.PP
In article <16202_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
.sp
.nf
>linda_@rtech.rtech.com (Linda Mundy) writes about my comment that one hard-
>to-pin-down aspect of new-code quality might be:
>> >..."must be able to
>> >survive the next five years of changes, to meet new needs, hacked in by
>>                                                             ^^^^^^^^^^^^
>> >bored second-string maintenance programmers..."  ...
>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>She says:
>> Dick, I really agreed with the main points of your article, making the
>> above remark come as a surprise.  Not picking you in particular, but
>> this is such a common attitude towards maintenance programmers, I thought
>> it might be appropriate as a topic of discussion in its own right...
>
>I agree with Linda's sentiments.  Now, to be clear about why I said what I
>did:  It IS a common attitude toward maintenance programmers.  It's an
>unfortunate, stupid, misdirected attitude.  Not only do I NOT agree with
>it; it makes me angry.  BUT it's there, and has to be reckoned with.  In
>other words, I pointed out that quality software needs to survive being
>hacked over by bad maintenance programmers not because maintenance SHOULD
>be done that way, but because it WILL be done that way, in all likelihood.
>You have to make the software a little hardier than it should need to be
>in order to survive what it will be put through.
>
>Maybe I should also have been careful with the wording so that it would
>have been clear that I meant (second-string) (maintenance programmers), as
>opposed to (second-string maintenance) programmers.
>
.fi
.PP
Well your main point remains valid, i.e. that one needs to think about 
future maintenance/enhancement when coding something.  The phrase quoted
above just jumped out at me -- like a red flag in front of a bull -- and
demanded comment...
.SUBSUBSECT From Steven M. List
.index List, Steven M.
.nf
Date: 18 Oct 89 17:05:32 GMT
From: coherent!mrspoc!itkin_@ames.arc.nasa.gov  (Steven M. List)

travis_@delta.eecs.nwu.edu (Travis Marlatte) writes:
.index Marlatte, Travis

>I don't see the reasoning that novice programmers should be given the
>task of maintaining existing systems. I also don't see the reasoning that
>thou who creates it will maintain it even unto ball and chain.
.fi
.PP
This seems awfully absolute.  I didn't hear anyone make either of these
statements as absolutes.  In fact, as regards the second statement, it
was specifically mentioned as an option.  There are MANY people who find
the option to have responsibility for and commitment to a project from
"womb to tomb" VERY attractive.  There are others (myself included) who
like to do a certain amount of work on a project and then move on to something
else.  The threshhold varies, but the desire tends to be one for
change and variety.
.sp
.nf
>Simple analogy: A team of crack engineers build a beautiful and structurally
>sound bridge that serves its purpose well. Five years after construction,
>it is learned that the foundation at one end is giving way due to water
>damage. The company assigns its newest employee to the task of designing
>the correction to the problem.
.fi
.PP
I notice that Travis said "newest employee", not "novice engineer" or
"recent graduate."
.sp
.nf
>Sounds absurd to me! I would hope it sounds absurd to the rest of you too.
>Isn't the analogy correct. Why would I want to assign inexperienced staff
>to the task of shoring up existing systems? Especially, since we know that
>mainenance is often a task of stretching the intent of the original design
>to meet current expectations. Further, why would I want my newest employee
>dedicated to mastering 5 year old technology?
.fi
.PP
Sounds absurd to me too.  No one said that was the idea.  The idea is that
through working on fixing bugs (maybe major, maybe not), a new employee
(not necessarily junior, however!!!!) can learn the systems, the techniques,
and the standards and approach used by his/her new employer.  While we
tend to think of YOUNGER employees when we think of NEWER employees, this
is CLEARLY not the case.  When you change jobs, do you expect to walk into
your new job and immediately start designing their hottest project?  While
it does happen, it is the exception rather than the rule.  New employees
have to learn their way around; socially, organizationally, and
professionally.  In our profession, this is frequently accomplished by
putting the employee to work on low- to medium-priority maintenance
tasks.
.sp
.nf
> [ lots of interesting stuff about apprenticeship approaches ]
.fi
.PP
I agree that apprenticeship is a terrific way to progress.  Once again,
I must point out that NEW employee does not translate to RECENT GRADUATE
or YOUNG.  Put the issue in perspective.
.sp
.nf
>By the way, my first job out of school was as a maintenance programmer
>for control systems. I didn't mind doing it but it certainly was a waste
>of time. Only by becoming involved in curent design effort does one come
>to understand the task of doing current design.
.fi
.PP
"A waste of time."  Does this let everyone know what Travis thinks of
maintenance and programmers who DO maintenance?  Obviously what is
important and interesting to Travis is design and being in on the
ground floor of a project.  While that's true of many of us, we also
learn to appreciate the time we get to work on maintenance.  It can
be a wonderful break from the pressure and pace of being at the front
end.  Like doing gardening or cooking or folding laundry.  Like doing
manual labor after programming all day.  Change.
.PP
Nurture versatility and an appreciation for ALL aspects of your
profession, and you will BE a professional.
.SUBSUBSECT From Jim Frost
.index Frost, Jim
.nf
Date: 18 Oct 89 20:12:25 GMT
From: xylogics!world!madd_@CS.BU.EDU  (jim frost)

In article <3829_@rtech.rtech.com> linda_@rtech.UUCP (Linda Mundy) writes:
.index Mundy, Linda
>In article <16202_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
>>You have to make the software a little hardier than it should need to be
>>in order to survive what it will be put through.
[...]
>Well your main point remains valid, i.e. that one needs to think about 
>future maintenance/enhancement when coding something.
.fi
.PP
Yes; the technique I've used is to error-check arguments everywhere
that performance isn't ABSOLUTELY necessary, even in distributed code.
.PP
This costs some performance but improves the initial quality and
future maintainability.  During development it catches early
programming errors, saving debug time.  Sometimes it saves a LOT of
debug time.  During maintenance it provides known points of failure
which can be used in tracking reported bugs and drops the likelihood
that low-quality programmers will use functions incorrectly.
.SUBSUBSECT From J.R. Jarrett
.index Jarrett, J. R.
.nf
Date: 18 Oct 89 02:34:29 GMT
From: rochester!rit!ultb!jrj1047_@cu-arpa.cs.cornell.edu  (J.R. Jarrett)
.fi
.PP
Titled "Software Maintenance is a Solution, not a Problem" in the Jan
'89 issue of System Development.  He stated that the goal of maintenance
.index software maintenance
.index maintenance, software
should be to maximize efficiency rather than minimize cost, and to do
that, the best people should be attracted to and placed in maintenance
positions.  It doesn't always happen that way.  I work for a software
maintenance group, and the new hires are the ones that get put in there;
the experienced people move on to more "interesting" ventures.  It's
nice to say "Put the best people in", but until it happens in industry,
it's no more than lip service.
.SUBSUBSECT From Charles Weir
.index Weir, Charles
.nf
Date: 20 Oct 89 16:34:48 GMT
From: richsun!cweir_@uunet.uu.net  (Charles Weir)

In article <1989Oct18.201225.3330_@world.std.com> madd_@world.UUCP
(jim frost) writes:
.index Frost, Jim
>>>You have to make the software a little hardier than it should need to be
>>>in order to survive what it will be put through.
>[...]
>>Well your main point remains valid, i.e. that one needs to think about 
>>future maintenance/enhancement when coding something.
>
>Yes; the technique I've used is to error-check arguments everywhere
>that performance isn't ABSOLUTELY necessary, even in distributed code.
>
>This costs some performance 
.fi
.PP
If performance is important, then make it an option
(Compile option in C, I don't know in other languages):
.nf
#if defined (CHECK)...
[check all parameters]
#endif
.fi
.PP
That isn't quite as convenient as leaving the checks in
permanently, but it allows
one to use the technique in virtually ALL code.
.PP
It's funny how little public domain code does this...
.SUBSECT Non-Code Software Components
.SUBSUBSECT From Edward Berard
.index Berard, Edward
.nf
Date: 12 Oct 89 01:45:43 GMT
From: sei!ajpo!eberard_@pt.cs.cmu.edu  (Edward Berard)
.fi
.PP
I have been involved in software reusability for a number of years.
During this time I have:
.LIST
.LE
conducted research in various aspects of software
reusability (e.g., domain analysis, reusability metrics, and
reusable software construction)
.LE
conceived of, implemented, and sold on a commercial basis a
large (>512K lines of source code) library of reusable
components
.LE
developed and delivered a number of software applications
which made conscious and extensive use reusable components
.LE
developed and delivered a number of courses on software
reusability 
.LE
provided consulting on software reusability to a number of
clients
.LE
authored a number of papers, and chaired a few sessions on
the topic
.ELIST
.PP
I do not consider myself an expert on software reusability, but I
.index software reuse
.index reuse, software
would say that I have some experience in the area.
.PP
One thing that continues to amaze me is the lack of understanding as
to just what "software" is. Before one can discuss reusing something,
.index software, definition of
.index definition of software
you must know what that something is. When software reuse is
discussed, very often one gets the impression that "software" is:
.sp
.nf
	a. source code

	b. object code
.fi
.sp
and nothing else.
.PP
I submit that software encompasses much more than mere source code and
object code. For example, I consider all of the following to be
software: 
.LIST
.LE
code fragments
.LE
modules (in the subroutine/procedure/function sense)
.LE
packages (in the package/module/class sense)
.LE
large collections (in the library/subsystems sense)
.LE
applications (in the complete, stand-alone sense)
.LE
scaffolding code (produced during development, but not
part of the delivered product)
.LE
test data
.LE
software quality assurance information
.LE
the deliverable products of feasibility studies
.LE
the deliverable products of analysis efforts
.LE
designs
.LE
plans
.LE
standards
.LE
tools
.LE
environments
.ELIST
.PP
You will note that not everything on this list is code software.
.index non-code software
.index software, non-code
Non-code software includes such things as test data, designs, plans,
software quality assurance information, standards, the products of
analysis efforts, and the products of feasibility studies.
.PP
Unfortunately, most of the effort in software reusability systems
seems to be focused on code software. Ironically, this is the area
where the return on investment seems to be the lowest. For example, if
analysis and design consume a significantly larger share of the
software life-cycle than does coding, reuse of analysis and design can
potentially provide significantly greater returns than the mere reuse
of code.
.PP
The reuse of non-code software involves different issues than does the
reuse of code software. For example, non-code software may contain
graphical information, as well as textual information. Many so-called
reusability systems are not set up to handle graphical
representations. The taxonomies, evaluation criteria, and
interconnections of non-code software are often different from the
same items for code software.
.PP
Reusability technology tells us that:
.LIST
.LE
The larger a component is, the higher will be the payoff
from the reuse of that component, however
.LE
The larger a component is, the lower will be the probability
that component will actually be reused.
.ELIST
.PP
This means that domain analysts (i.e., those charged with identifying,
.index domain analyst
.index analyst, domain
documenting, and configuration managing reusable components) must
constantly balance the size of a component against its potential for
reuse. They must find both the granularities of components, and the
mix of components, which will provide the highest return.
.PP
Given that reuse of analysis and design may potentially provide more
benefits than the simple reuse of source code (in fact, may even drive
the structure and selection of reusable source code), we need to ask:
.li +5
.PP
What should the granularity of analysis and design products be
to maximize their reusability, and thus our investment in
making them reusable?
.li -5
.PP
Of course, there are many other issues, e.g., taxonomies, software
engineering approaches (e.g., object-oriented), horizontal vs.
vertical reuse, and documentation styles.
.PP
I propose a thread of discussion focusing on the reuse of non-code
software. Further, I propose that, at least at the start, one of the
main topics be the reuse of analysis and design, and, more
specifically, what types of analysis and design products provide a
suitable granularity (i.e., one which has a high potential for a
return on investment (ROI)).
.PP
I have some ideas on the subject, but I will wait to see if there is
any interest.
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 12 Oct 89 15:31:44 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )
.fi
.PP
From eberard_@ajpo.sei.cmu.edu (Edward Berard):
.index Berard, Edward
.sp
.nf
> Non-code software includes such things as test data, designs, plans,
> software quality assurance information, standards, the products of
> analysis efforts, and the products of feasibility studies.
.fi
.PP
Wouldn't this really be "software infrastructure", rather than
software?  Whatever we call it, though, infrastructure reuse
is certainly an interesting topic.   
.sp
.nf
> I have some ideas on the subject, but I will wait to see if there is
> any interest.
.fi
.SUBSUBSECT From Scott Henninger
.index Henninger, Scott
.nf
Date: 12 Oct 89 16:47:40 GMT
From: scotth_@boulder.colorado.edu  (Scott Henninger)

|>From: eberard_@ajpo.sei.cmu.edu (Edward Berard)
.index Berard, Edward
|
|I submit that software encompasses much more than mere source code and
|object code. 
.fi
.PP
Absolutely.  I refer you to Ted Biggerstaff's article in IEEE Computer
.index Biggerstaff, Ted
(July, 1989).  He stresses the use of a wide scope of software work
products to recover the design issues for source code.  It's not quite
to the point you make, but is the only work I know of that explicitly
tries to draw from sources other than raw code for reuse.
.sp
.nf
|Unfortunately, most of the effort in software reusability systems
|seems to be focused on code software. Ironically, this is the area
|where the return on investment seems to be the lowest. For example, if
|analysis and design consume a significantly larger share of the
|software life-cycle than does coding, reuse of analysis and design can
|potentially provide significantly greater returns than the mere reuse
|of code.
|[...]
|Given that reuse of analysis and design may potentially provide more
|benefits than the simple reuse of source code (in fact, may even drive
|the structure and selection of reusable source code), [...]
.fi
.PP
It can go the other way too.  The availability of reusable code
components can drive the analysis and design.
.PP
A common mistake in software reusability systems is the assumption that
the management of software projects will remain the same.  If you are
consciously striving to reuse existing software the processes and
proportion of time spent on these processes will change.  
.PP
For example, time must now be spent finding and assessing reusable
components.  This is not accounted for in traditional software
management techniques.  If you believe my above statement and also
realize that time must also be spent on indexing new code for future
reusability, I think you can see that SE techniques must adapt to the
very different programming techniques involved in reusing software.
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 13 Oct 89 21:07:30 GMT
From: mailrus!cs.utexas.edu!ico!vail!rcd
  _@tut.cis.ohio-state.edu  (Dick Dunn)

eberard_@ajpo.sei.cmu.edu (Edward Berard) writes:
.index Berard, Edward

> Unfortunately, most of the effort in software reusability systems
> seems to be focused on code software. Ironically, this is the area
> where the return on investment seems to be the lowest. For example, if
> analysis and design consume a significantly larger share of the
> software life-cycle than does coding, reuse of analysis and design can
> potentially provide significantly greater returns than the mere reuse
> of code.
.fi
.PP
I'm surprised to see this statement.  Perhaps it's true, but from where I
sit (in an organization which does a LOT of contract development of software),
we re-use bits and pieces all through projects.  We'll start looking
at a new contract, say at the proposal phase, and realize that it has some
major pieces which are close to major pieces of other contracts we've done.
It's only natural to find that, since our repeat or referred business is
based on a reputation established from previous work.
.PP
It's important to re-use work from the front-end phases of projects.
That's how you improve your ability to size projects--if you've done it
before, you *know* how long it will take.
.SUBSUBSECT From Scott Duncan
.index Duncan, Scott
.nf
Date: 16 Oct 89 12:32:43 GMT
From: dduck!duncan_@bellcore.com  (Scott Duncan)

In article <16210_@vail.ICO.ISC.COM> rcd_@ico.ISC.COM (Dick Dunn) writes:
.index Dunn, Dick
>
>    (in an organization which does a LOT of contract development of soft-
>ware), we re-use bits and pieces all through projects.  We'll start looking
>at a new contract, say at the proposal phase, and realize that it has some
>major pieces which are close to major pieces of other contracts we've done.
>It's only natural to find that, since our repeat or referred business is
>based on a reputation established from previous work.
>
>Dick Dunn     rcd_@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
>   ...No DOS.  UNIX.
.fi
.PP
This brings up a point that came up when I was talking to people who do
contracting for the US Government.  They felt that,
in many instances, reuse was
discouraged for this very reason.  That is, if a vendor/contractor were using
software, documentation, e.g., anything developed on another contract, the
government agencies did NOT want to have the bid include any cost for reuse of
such software.  After all, it had been paid for already.
.PP
Has your organization been able to solve this problem in some way or do you,
in fact, reduce the contract bid based on the cost saved by not redeveloping
the software (or whatever other artifacts are reused)?
.PP
Another issue was reuse of software by one contractor which had been developed
by another.  Supposedly this could save the government (and the contractor
reusing it) money (and time), but there was no incentive to do so because of
maitenance issues and because it actually represented a loss in revenue to the
firm reusing the software since they could NOT charge for its redevelopment.
.PP
It seems to me that within organizations and between them, the issues of who
does ongoing support for reused software and how reused software will be paid
for are major, non-technical, stumbling blocks to moving ahead with large
reuse efforts.
.PP
What opinions/experiences do other people have?  One contractor suggested to me
that the governmment might consider offering a 'reward' for reuse in that half
the savings would be passed along to the government while half would be divided
equally between the developing and reusing organizations.  This would provide
incentive to both develop reusable software as well as make use of it,
presumably.
.SUBSUBSECT From Don Dwiggins
.index Dwiggins, Don
.nf
Date: 18 Oct 89 02:26:18 GMT
From: usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!hacgate!ashtate
  !atsun!dwiggins_@ucsd.edu  (Don Dwiggins)

In article <598_@ajpo.sei.cmu.edu> eberard_@ajpo.sei.cmu.edu
(Edward Berard) writes:
.index Berard, Edward

   I propose a thread of discussion focusing on the reuse of non-code
   software. Further, I propose that, at least at the start, one of the
   main topics be the reuse of analysis and design, and, more
   specifically, what types of analysis and design products provide a
   suitable granularity (i.e., one which has a high potential for a
   return on investment (ROI)).
.fi
.PP
OK, I'll pick up the thread with a request for setting the parameters.  It
seems to me that the interpretation of the terms "analysis" and "design" is
less than well settled.  Design, for example, can occur in several settings
and at several levels; it would be useful to distinguish among them, and
discuss reusability in the different contexts.
.PP
With regard to analysis, I have a question arising from your message.  Early
on, you say that you've
.sp
.nf
	- conducted research in various aspects of software
	  reusability (e.g., domain analysis, ......
.fi
.PP
Later, you say
.sp
.nf
       This means that domain analysts (i.e., those charged with identifying,
       documenting, and configuration managing reusable components) must
       constantly balance the size of a component against its potential for
       reuse. They must find both the granularities of components, and the
       mix of components, which will provide the highest return.
.fi
.PP
I had the impression that "domain analysis" was the sort of thing that would
be done for a class of applications intended to run in a common domain, to
identify common classes of data, algorithms, report types, etc.  Your
characterization of the task of a "domain analyst" seems to be more like
that of a database administrator for a component database.  Where am I
confused?
.SUBSUBSECT From Edward Berard
.index Berard, Edward
.nf
Date: 18 Oct 89 20:22:01 GMT
From: sei!ajpo!eberard_@pt.cs.cmu.edu  (Edward Berard)

Don Dwiggins (dwiggins_@atsun.a-t.com) writes:
.index Dwiggins, Don
> OK, I'll pick up the thread with a request for setting the parameters.  It
> seems to me that the interpretation of the terms "analysis" and "design" is
> less than well settled.  Design, for example, can occur in several settings
> and at several levels; it would be useful to distinguish among them, and
> discuss reusability in the different contexts.
.fi
If you study software engineering technology, and software engineering
history, several things become apparent:
.LIST
.LE
The development part of the software life-cycle is basically
a series of transformations. Specifically, if a
non-technical (in the software engineering sense) user could
interact directly with the computer, without having to
actually develop an application, there would be no need for
software engineers for many everyday applications. However,
users currently have to go through intermediaries (i.e.,
software engineers and their managers). The job of these
intermediaries is to help formulate, clarify, and translate
the users' requests into a form which the computer can
understand. This formulation, clarification, and translation
process is what we often refer to as the development part of
the software life-cycle.
.PP
Traditionally, (systems, requirements, and/or user) analysis
was the first step in this transformation process. The idea
was to help both the client and the software engineers
better understand the problem to be solved. One of the
outputs of the analysis process was a description of the
system, as it would appear to the client.
Equally traditionally, the process which followed analysis
was referred to as design. The usual concept was that
designers implemented the internal (software) architecture
of the system. Designers were supposed to discuss things in
terms of modules (e.g., subroutines), and other technical
(from the software engineering perspective) issues. Design
was traditionally followed by programming (coding).
.LE
Even in the "good old days" people had trouble
differentiating between analysis and design. When did
analysis stop? When did design begin? How do I
systematically take the output of the analysis process and
use it as the input to the design process? Some people began
to realize that the boundaries between life-cycle phases
really were fuzzy.
.LE
Some people realized that the development of a software
product was more a continuous process than it was a series
of discrete steps. Some even realized that the distinction
between the analysis, design, coding, and testing phases
were purely artificial, and were very often used by
management as tools to control a software development
effort.
.PP
If you view a software development effort as a huge
monolithic entity, that means that you may have to invest
large sums of resources, for an extended period of time,
with very little idea of what the final results will be. On
the other hand, if you introduce phases into the life-cycle,
and specify deliverables for each phase, you have much more
control over the overall process. You can make "mid-course
adjustments," "go/no go" decisions at the end of each phase,
spot trouble earlier, and generally have a much better idea
of actual progress. Please note, however, methods,
methodologies, deliverables, well-defined phases, and the
mere presence of management do not guarantee success.
.LE
Others have observed that analysis and design, for example,
even take place in the maintenance phase of the software
life-cycle.
.LE
There are many different overall approaches to the software
life-cycle, e.g., waterfall, spiral, b-model, and
recursive/parallel. (In some of my classes, I show people at
least six different approaches.) In object-oriented software
engineering, a very commonly used approach is
recursive/parallel, sometimes referred to as "analyze a
little, design a little, implement a little, test a little."
Yes, this means that analysis, design, and implementation
may take place at many different points during development.
.LE
Depending on how you view the terms:
.LE
Analysis and design are precursors to coding, and do
not involve coding.
.LE
Each time a single character of source code is
changed you are actually re-designing. (Notice that
software maintenance differs from hardware
maintenance in this respect. Specifically, hardware
maintenance may involve replacing a defective part
with an identical part, whereas software maintenance
requires the introduction of different parts.)
.LE
Analysis may involve analysis of a piece of source
code with the intent of finding a problem, or
suggesting optimizations or extensions.
.LE
Et cetera ...
.ELIST
.sp
.nf 
> With regard to analysis, I have a question arising from your message.
> Early on, you say that you've
> 
> 	- conducted research in various aspects of software
> 	  reusability (e.g., domain analysis, ......
> 
> Later, you say
> 
>    This means that domain analysts (i.e., those charged with identifying,
>    documenting, and configuration managing reusable components) must
>    constantly balance the size of a component against its potential for
>    reuse. They must find both the granularities of components, and the
>    mix of components, which will provide the highest return.
> 
> I had the impression that "domain analysis" was the sort of thing that would
> be done for a class of applications intended to run in a common domain, to
> identify common classes of data, algorithms, report types, etc.  Your
> characterization of the task of a "domain analyst" seems to be more like
> that of a database administrator for a component database.  Where am I
> confused?
.fi
.PP
I suspect it is in your interpretation of the word "component." I have
no problem with "components" being "common classes of data,
algorithms, report types, etc." However, I think we can better define
what we are after in domain analysis.
.PP
First, we need some definitions:
.LIST
.LE
"An investigation of a specific application area that seeks
to identify the operations, objects, and structures that
commonly occur in software systems within this area."
-- Dan McNicholl
.index McNicholl, Dan
.LE
"Systems analysis states what is done for a specific problem
in a domain while domain analysis states what can be done
in a range of problems in a domain. ...  A domain
analysis is only useful if many similar systems are to
be built so that the cost of the domain analysis can be
amortized of all the systems.
.PP
"The key to reusable software is captured in domain analysis
in that it stresses the reusability of analysis and design,
not code."
-- Jim Neighbors
.index Neighbors, Jim
.LE
"A horizontal domain analysis studies a number of different
systems across a variety of applications."
-- Grady Booch
.index Booch, Grady
.LE
"A vertical domain analysis studies a number of systems
intended for the same class of applications."
-- Grady Booch
.ELIST
.PP
We can add some more clarifications:
.LIST
.LE
Domain analysis is not a software life-cycle activity. It
has a beginning, but, usually, never stops. It runs
in parallel with the life-cycles of many software products. 
.LE
Domain analysts must identify reusable items in their
application domains, however they will usually be able to
classify what they find as:
.LE
reusable, and highly domain-specific, i.e., these
items will have a very low potential for reuse
outside of the defined domain. These items are
usually in the minority of the items encountered.
.LE
reusable, and not specific to the defined domain,
i.e., these items will have at least some
"horizontal reuse potential." These items are
usually in the majority of the items encountered.
.LE
Unfortunately, many people tend to focus on only low-level
items (e.g., source code, object code, algorithms, data)
during domain analysis. Much larger payoffs are achieved
when higher-level items (e.g., plans, standards, design
products, analysis products) are also considered.
.LE
A domain analyst must not only be familiar with the specific
.index domain analyst
.index analyst, domain
domain, he or she must also be familiar with what they are
supposed to be looking for (e.g., objects and classes), he
or she must have excellent abstraction skills, and he or she
must be well-versed in software reusability technology.
.LE
In functional domain analysis, we are looking for things
that fit a functional viewpoint of systems in our domain.
That is, we are looking for reusable functions, libraries of
functions, and, in general, items which will be useful to
those software engineers who have taken a functional
decomposition approach to the software life-cycle.
.LE
In object-oriented domain analysis, we are looking for
objects, classes, systems of objects, and, in general, items
which will be useful to software engineers taking an
object-oriented approach to the software life-cycle.
.ELIST
.PP
A domain analyst must do much more than simply point to an item and
say that the item is reusable. There is much more work to be done.
Without going into a full-blown course on domain analysis, some of the
things a domain analyst can be expected to do are:
.LIST
.LE
Concisely and precisely define the application domain.
.LE
Identify a representative sample of applications which span
the domain, and use this sample to begin to extract
potentially reusable items.
.LE
Accurately name and document each reusable item. Of course
this brings up issues like nomenclature and definitions.
.LE
Clean up, parameterize, and otherwise refine potentially
resuable items.
.LE
Identify additional reusable items suggested by those
already identified.
.LE
Store and retrieve both the reusable items, and information
associated with the items.
.LE
Develop guidelines for the (re)use of the reusable items.
.LE
Demonstrate reuse using the reusable items and the
guidelines.
.LE
Interact with all those involved in the software engineering
process, e.g., requirements analysts, testers, designers,
coders, software quality assurance personnel, managers, and
maintenance personnel. The specifics of these interactions
are too involved to go into in this short message.
.ELIST
.PP
There is much more I could say. (Yes, I do teach a course on the
subject.) But this message is already too long. Thanks for listening.
.SUBSUBSECT From KC Burgess Yakemovic
.index Yakemovic, KC Burgess
.nf
Date: 20 Oct 89 13:51:19 GMT
From: ncrlnk!ncratl!ncratl2!kcby_@uunet.uu.net  (kcby)
.fi
.PP
The idea of reusing analysis and design components of software development
efforts is very interesting to me.  In fact, as someone who has been
involved primarily with the analysis and design "phases" of projects for a
number of years, it may rank as one of my *major* interests. :-)
.PP
Here's my problem. The information associated with the analysis and design
must somehow be documented, or it can only be reused by the people who were
around when the original analysis and design were done.  Typically we have
'encoded' some of this information in specifications either in English (or
other native language) or by using some diagraming technique. Actually,
what we have recorded is the *results* of the analysis and design. The
analysis and design effort took place in meetings, discussions, etc. which
may or may not have been documented through letters, meeting notes,
technical notes, etc.
.PP
As an individual, I have maintained analysis and design information from
past projects, and have made use of (some of) it on new projects.  The
information (handwritten papers, meeting notes, letters, faxs, paper
napkins with preliminary design diagrams on them, etc.) is currently
organized in chronological order, by project. As such, *I* can (sometimes)
find the information which I need when it comes time to reuse it, because I
was responsible for storing it. However, just having kept the information
doesn't mean it is reusable.  At times I can't find information I know is
there, and worse, other people (even when given access to the "paper")
haven't the foggiest idea where to start, or whether the information is event
there.
.PP
Now a few questions:
.LIST
.LE
What would analysis and design information look like if I wanted that
information to be reusable by someone other than me? (freeform text?
structured text? defined by a specific methodology? up to the
originator?)
.LE
How can it be made accessible? (Linear search through 15+ binders of
paper organized in chronological order and associated with a single
project doesn't work!)
.LE
Is there enough reuse possible to justify the (apparently) extra effort
required to document more than just the results of analysis or design?
(That is, how do I convince people who don't even want to write down the
*results* of analysis and design (in specifications) that they should
somehow document the information they used to produce the analysis and
design specs?)
.ELIST
.PP
I hope the orignal poster will forgive me if this has gotten off of his
topic somewhat. But I believe there is at least some relationship involved.
.SUBSECT Software Quality
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 12 Oct 89 15:42:31 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )
.fi
.PP
From article <16193_@vail.ICO.ISC.COM>, by rcd_@ico.ISC.COM (Dick Dunn):
.index Dunn, Dick
.nf
> Of course good people will produce better software than bad people. [...] 
> But the professional won't do as good a job as if there were more 
> external interest in quality and less extreme time/money pressure.
.fi
.PP
A long schedule can provide enough time to get a product almost
perfect, but with very negative economic consequences.  It is 
*management's* responsibility to balance quality requirements
against other requirements when determining the schedule.
.PP
At some point, the tradeoff must be made, and the engineers
must then produce the best possible product within the specified
minimum standards of quality and the cost and schedule constraints. 
.sp
.nf
> And what's this about advanced programming languages?  Wolfe has, in other
> postings, been an outspoken advocate of Ada, which is certainly *not*
> advanced.  
.fi
.PP
Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 13 Oct 89 20:58:15 GMT
From: mailrus!cs.utexas.edu!ico!vail!rcd_@purdue.edu  (Dick Dunn)

William Thomas Wolfe writes:
.index Wolfe, William Thomas

>     ...It is 
>     *management's* responsibility to balance quality requirements
>     against other requirements when determining the schedule.
.fi
.PP
No.  Management assists in this.  Management makes the final call, but the
engineers are a major part of the decision process.  After all, it's an
engineering exercise to determine how long it takes to do the engineering.
.PP
Also, as I've pointed out (ad nauseam for other readers, I suspect), the
quality characteristics I've been talking about are not readily quantifiable,
whereas the requirements I've been talking about are necessarily
objective.  >>In this context<< the phrase "quality requirements" is a
contradiction.
.PP
Note in passing...I had said:
.sp
.nf
> > And what's this about advanced programming languages?  Wolfe has, in other
> > postings, been an outspoken advocate of Ada, which is certainly *not*
> > advanced.  
   ... and Wolfe dodges it:
>     Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
.fi
.PP
No, let's not.  I won't assert that C is advanced.  It's suitable.  Nor did
I assert that "advanced programming languages" were essential.  Try to
answer the question, Bill:  Are you advocating use of an advanced programming
language, or are you advocating the use of Ada?
.SUBSUBSECT From Mike Lutz
.index Lutz, Mike
.nf
Date: 12 Oct 89 21:59:42 GMT
From: rochester!rit!mjl_@louie.udel.edu

In article <6756_@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
.index Wolfe, William Thomas
_@hubcap.clemson.edu writes:
>From article <16193_@vail.ICO.ISC.COM>, by rcd_@ico.ISC.COM (Dick Dunn):
>> And what's this about advanced programming languages?  Wolfe has, in other
>> postings, been an outspoken advocate of Ada, which is certainly *not*
>> advanced.  
>
>    Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
.fi
.PP
I'm into lingua-snobbery as much as anyone else, but is this really
the forum for it?  And using it to willyhorton someone else's position
certainly does nothing to give added credibilty to your own.  So
let's drop this and get back to the interesting quality issues that
started this thread.
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 14 Oct 89 21:05:41 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )

From rcd_@ico.ISC.COM (Dick Dunn):
.index Dunn, Dick
>>     *management's* responsibility to balance quality requirements
>>     against other requirements when determining the schedule.
> 
> No.  Management assists in this.  Management makes the final call, but the
> engineers are a major part of the decision process.  After all, it's an
> engineering exercise to determine how long it takes to do the engineering.
.fi
.PP
Engineers repeatedly provide information as a function of the varying
constraint parameters which are specified by management.  Management 
makes the decision.  Engineers then comply.  
.PP
Notice: *Engineering* assists.  *Management* DECIDES. 
.sp
.nf
> note in passing...I had said:
>> > And what's this about advanced programming languages?  Wolfe has, in 
>> > other postings, been an outspoken advocate of Ada, which is certainly
>> > *not* advanced.  
>> Oh, then let's talk about how "advanced" C is, over in comp.lang.misc.
> 
> No, let's not.  I won't assert that C is advanced.  
.fi
.PP
Glad to hear it.
.sp
.nf
> answer the question, Bill:  Are you advocating use of an advanced 
> programming language, or are you advocating the use of Ada?
.fi
.PP
I advocated precisely what I said: "advanced programming languages",
along with CASE tools and so on.  YOU brought up Ada, not I.
.PP
And I *will* assert that Ada is advanced, within the domain of
PRODUCTION programming languages; followups to comp.lang.misc
if you'd like to pursue it.
.SUBSUBSECT From Dick Dunn
.index Dunn, Dick
.nf
Date: 19 Oct 89 04:29:03 GMT
From: ico!vail!rcd_@handies.ucar.edu  (Dick Dunn)

.index Wolfe, William Thomas
Bill Wolfe said, in relation to the ongoing discussion about factoring
quality into scheduling:
> >>     *management's* responsibility to balance quality requirements
> >>     against other requirements when determining the schedule.
.fi
.PP
I complained about the characterizations of engineering and management
roles:
.sp
.nf
> > No.  Management assists in this.  Management makes the final call, but the
> > engineers are a major part of the decision process.  After all, it's an
> > engineering exercise to determine how long it takes to do the engineering.
.fi
.PP
There are some statements about interactions inherent in what I said.  I
really mean that the engineers had better *participate* in the decision
process.  I should have noted that, in addition to the engineering aspects
of determining schedule, you have to keep the old responsibility/authority
equation in balance--and it's the engineers who have the responsibility for
meeting the schedule.
.PP
Wolfe counters:
.sp
.nf
>     Engineers repeatedly provide information as a function of the varying
>     constraint parameters which are specified by management.  Management 
>     makes the decision.  Engineers then comply.  
.fi
.PP
The first part works, but poorly.  The problem is that (in software buzzterms)
it starts with a waterfall model, then wraps a loop around the outside.
That is, management provides constraints, engineers provide information
in response--that's the waterfall pair of steps.  It can take a lot
of iterations to get a decent answer compared to what happens if you plunk
engineers and managers down together and let them work on all of the
constraints together.
.PP
As for the "management decides, engineers comply" - in some sense that's
what happens, but it's an incredibly poor choice of words.  That is,
regardless of the actions, an organization which sees its process in those
terms is not healthy...it has management problems.
.sp
.nf
>     Notice: *Engineering* assists.  *Management* DECIDES. 
.fi
.PP
In a wider context, this would be very unhealthy.  Engineering does the
work in an engineering project, and management assists the engineers in
getting it done.  (This comes from the observation that the end product is
the result of engineering effort, not management effort.)
.PP
But let's not lose sight of the fact that we're talking about setting the
schedule, budget, and related constraints--this is a different context
from the "real work" in the project.  My contention is that even this
initial work is substantially an engineering effort.  If engineers are to
be involved, you don't involve them as "subordinates".
.PP
A perspective:  When someone (even in our company) asks me who I work for,
I say "Interactive Systems."  If I'm then pressed for the name of a
*person*, I say "Oh, you must mean `Who do I report to?'" and give them my
manager's name.  The distinction between "work for" and "report to" is
important in what it says about structure versus control.
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 21 Oct 89 20:17:55 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )
  
From rcd_@ico.isc.com (Dick Dunn):
.index Dunn, Dick
> Bill Wolfe said, in relation to the ongoing discussion about factoring
> quality into scheduling:
>> >>     *management's* responsibility to balance quality requirements
>> >>     against other requirements when determining the schedule.
> 
> I complained about the characterizations of engineering and management
> roles:
>> > No.  Management assists in this.  Management makes the final call, but the
>> > engineers are a major part of the decision process.  After all, it's an
>> > engineering exercise to determine how long it takes to do the engineering.
> 
> There are some statements about interactions inherent in what I said.  I
> really mean that the engineers had better *participate* in the decision
> process.  I should have noted that, in addition to the engineering aspects
> of determining schedule, you have to keep the old responsibility/authority
> equation in balance--and it's the engineers who have the responsibility for
> meeting the schedule.
.fi
.PP
This is exactly correct, and here we agree completely.  (See below)
.sp
.nf 
% Wolfe counters:
%>     Engineers repeatedly provide information as a function of the varying
%>     constraint parameters which are specified by management.  Management 
%>     makes the decision.  Engineers then comply.  
% 
% The first part works, but poorly.  The problem is that (in software buzz-
% terms) it starts with a waterfall model, then wraps a loop around the out-
% side.  That is, management provides constraints, engineers provide infor-
% mation in response--that's the waterfall pair of steps.  It can take a lot
% of iterations to get a decent answer compared to what happens if you plunk
% engineers and managers down together and let them work on all of the
% constraints together.
.fi
.PP
But these iterations can occur with everyone in the same room,
working together.  Management specifies some parameters, engineers
provide information as to probable cost/schedule requirements,
loop until the meeting is over.
.sp
.nf 
> As for the "management decides, engineers comply" - in some sense that's
> what happens, but it's an incredibly poor choice of words.  That is,
> regardless of the actions, an organization which sees its process in those
> terms is not healthy...it has management problems.
.fi
.PP
No, it in fact shows that the organization IS healthy.  Engineers
are not, and should not be in the business of trying to be, responsible
for setting cost and schedule constraints.  They ARE responsible for
providing as much information as possible to management as it weighs
technical and economic factors in the process of making the decision.
.PP
If engineers were responsible for setting cost and schedule constraints,
they would tend to disregard economic factors and the organization would
quickly find itself out of business.  Projects would be technical works
of genius, with complete formal specifications for each subprogram or
data abstraction, 3-D images illustrating the design, etc., at a cost 
which would result in fatal financial illness for the company. 
.sp
.nf  
>>     Notice: *Engineering* assists.  *Management* DECIDES. 
> 
> In a wider context, this would be very unhealthy.  Engineering does the
> work in an engineering project, and management assists the engineers in
> getting it done.  (This comes from the observation that the end product is
> the result of engineering effort, not management effort.)
.fi
.PP  
The statement above relates only to the topic at hand, which is
"Who is responsible for setting cost/schedule constraints?".  When
we move to the new and different question, "Who is responsible for 
delivering the product?", then in THAT context I agree completely,
but this has nothing to do with the topic at hand.
.sp
.nf
> But let's not lose sight of the fact that we're talking about setting the
> schedule, budget, and related constraints--this is a different context
> from the "real work" in the project.  My contention is that even this
> initial work is substantially an engineering effort.  If engineers are to
> be involved, you don't involve them as "subordinates".
.fi
.PP
Sure you do.  Who says superiors and subordinates can't participate
in the same meeting?  Who says superiors and subordinates can't have
free and open discussions?  I don't, and I hope you aren't implying
this either.
.SUBSUBSECT From Mike Lutz
.index Lutz, Mike
.nf
Date: 24 Oct 89 03:22:18 GMT
From: rochester!rit!mjl_@cu-arpa.cs.cornell.edu

.index Wolfe, William Thomas
In article <6847_@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu
_@hubcap.clemson.edu writes:
>From rcd_@ico.isc.com (Dick Dunn):
.index Dunn, Dick
>> As for the "management decides, engineers comply" - in some sense that's
>> what happens, but it's an incredibly poor choice of words.  That is,
>> regardless of the actions, an organization which sees its process in those
>> terms is not healthy...it has management problems.
>
>   No, it in fact shows that the organization IS healthy.  Engineers
>   are not, and should not be in the business of trying to be, responsible
>   for setting cost and schedule constraints.  They ARE responsible for
>   providing as much information as possible to management as it weighs
>   technical and economic factors in the process of making the decision.
>
>   If engineers were responsible for setting cost and schedule constraints,
>   they would tend to disregard economic factors and the organization would
>   quickly find itself out of business.  Projects would be technical works
>   of genius, with complete formal specifications for each subprogram or
>   data abstraction, 3-D images illustrating the design, etc., at a cost 
>   which would result in fatal financial illness for the company. 
.fi
.PP
I can't let this one pass, if for no reason than to defend the honor of
engineers.  I don't think we can (or should) use the Nuremburg defense
"I was only doing what I was told." If engineers realize that
managment's requests/requirements/demands are impossible to achieve,
they have the right -- the obligation -- to object, if for no other
reason than to protect the shareholder's interests against the
unrealizable plans of management!
.PP
Like most others who've been in this business for any time, I've seen
examples of what Bill is talking about.  Still, this was usually due
less to engineers violating budget and time constraints than it was a
lack of management direction -- by which I mean setting clear goals for
what was to be done.  People fritter their time away when they don't
have a clear vision of where they're going.  But once goals are
established, the engineers should have significant if not primary
control over how to get there.  Most fiascos I've seen have resulted
from management inability or unwillingness to face facts: what the
project would cost and how long it would take.
.PP
I have no problem with management proposing budget and schedule
constraints, but the engineering staff is best qualified to determine
whether there is a feasible solution within these constraints.  And
"feasiblity" in this case includes adequate time to produce a quality
design that has a high probability of successful evolution over the
lifetime of the product.  Bill's snide remarks notwithstanding,
sometimes this will mean creating a formal spec. and a variety of
related models to ensure a well-engineered piece of software.
.PP
In my experience, managers consistently underestimate software product
lifetime, possibly because they base their estimates on hardware
development models.  When the hardware subsystems are no longer up to
snuff, they are are often redesigned *from scratch* using the latest
technology.  However, most organizations work under the implicit
assumption that software need *never* be redesigned from scratch --
it can always be modified to meet new requirements.  I have in mind
several projects I've been involved with over the past couple of years,
where the hardware base evolved in stages from first generation mini's
(like PDP8's and Nova 1200's) to 68K's and 80xxx's.  While the current
processor boards and attendant interfaces look nothing like their
ancestors, the current software system architectures still reflect the
original designs (or lack thereof) from the early 70's.
.PP
For those interested in the issues surrounding long-term product
evolution, I strongly recommend Belady & Lehman's book "Program
Evolution: Processes of Software Change" (Academic Press, 1985, ISBN
0-12-442441-4).  The typography is awful, and I think the proof reading
phase was skipped, but the ideas and insights are well worth the time
it takes to ferret them out.
.SUBSUBSECT From William Thomas Wolfe
.index Wolfe, William Thomas
.nf
Date: 29 Oct 89 18:53:08 GMT
From: hubcap!billwolf%hazel.cs.clemson.edu_@gatech.edu
  (William Thomas Wolfe, 2847 )

From mjl_@cs.rit.edu:
>>   [I wrote:] Engineers
>>   are not, and should not be in the business of trying to be, responsible
>>   for setting cost and schedule constraints.  They ARE responsible for
>>   providing as much information as possible to management as it weighs
>>   technical and economic factors in the process of making the decision.
>
> If engineers realize that managment's requests/requirements/demands 
> are impossible to achieve, they have the right -- the obligation -- 
> to object, if for no other reason than to protect the shareholder's 
> interests against the unrealizable plans of management! [...] Most 
> fiascos I've seen have resulted from management inability or 
> unwillingness to face facts: what the project would cost and 
> how long it would take.
.fi
.PP
Perhaps so, but I think it is a gross misinterpretation of my 
position to imply that I am suggesting that engineers should
not make their objections known to management.  This comes under
the part about "providing as much information as possible..."!!
.PP
Now assume that engineering has made its views known, and that
management sticks with its decision.  We must consider:
.LIST
.LE
The engineers could be wrong.  Management could be taking
a calculated risk that research efforts taking place in
another part of the company will provide the tools needed
to bridge the gap, management could be dealing with a group
of engineers which largely is fresh out of college, etc.;
we cannot automatically discount the possibility that the
management has access to better information.  Indeed, it is
a primary function of management to see to it that information
is considered on a larger scale than simply that information
which is visible to a single department.
.LE
What if management *is* wrong?  Amdahl, I believe, gambled that
it would be possible to perform wafer-scale integration and lost;
but that does not mean that such projects should have been met
with engineer-level revolution.  Management may well have more
in mind than simply achieving the direct objectives of the project.
.LE
Engineers are free to resign if they believe the project and/or
the company will go down the tubes.  Many good products have 
resulted from engineers deciding to form their own company, 
and I believe that engineers should be perfectly free to take 
this route if they deem it appropriate.  Alternatively, they 
can buy 51% of the company's stock and then fire management.  
Or they can try to convince upper management or the stockholders
that management is in need of closer supervision.  But it is NOT
within their realm of options to usurp management's rights and
responsibilities.  
.sp
.nf         
> sometimes [good design] will mean creating a formal spec. and a 
> variety of related models to ensure a well-engineered piece of software.
.fi
.ELIST
.PP
The citation did NOT imply that formal specs are not valuable,
only that a formal specification of EVERYTHING is not presently
applicable to many situations due to the great cost of specifying
things with that level of detail.  Clearly, there are some situations
in which the currently extremely high costs are justified.
.SUBSECT Maintenance and Reuse
.SUBSUBSECT From Ralph Johnson
.index Johnson, Ralph
.nf
Date: 13 Oct 89 13:46:00 GMT
From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu
  !johnson_@iuvax.cs.indiana.edu
.fi
.PP
I'm a Smalltalk programmer.  All Smalltalk programmers are
maintenance programmers.  That's because we take reuse seriously.
The average Smalltalk programmer spends 75% of the time reading
code and only 25% of the time writing code.  Although this might
seem like an unproductive use of time, Smalltalk programmers
also have a reputation of being extremely productive, and the
two are related.  The fastest way to get good code (as all the
readers of this news group probably know) is to reuse it.
Reusing code requires understanding it.  Understanding code
requires at least reading the documentation, and sometimes
.index Smalltalk
reading the code.  Thus, any system that is successful at
reuse will make everybody who uses it a maintenance programmer.
.SUBSUBSECT From Satish Kumar .C
.index Kumar .C, Satish
.nf
Date: 15 Oct 89 17:26:52 GMT
From: m2c!umvlsi!chittamu_@husc6.harvard.edu  (Satish Kumar .C)

In article <130200014_@p.cs.uiuc.edu> johnson_@p.cs.uiuc.edu writes:
.index Johnson, Ralph
>
>Reusing code requires understanding it.  Understanding code
>requires at least reading the documentation, and sometimes
>reading the code.
.fi
.PP
I beg to differ. Reusing code requires understanding the *function* of
the code and not the code itself. If you know precisely what the code is
supposed to do, then you can reuse it without reading thro' the
implementation of it. If reusable code requires us to read thro' its
implementation, then in my opinion it is not truely reusable. It
defeats the very purpose of having package specification and module
interfaces. Reuse is fine. I am strong advocate of it. But not when I
have to read thro' the code.  The only thing I would necessarily need to
read is the documentation describing the purpose of the code.
.SUBSUBSECT From Ralph Johnson
.index Johnson, Ralph
.nf
Date: 20 Oct 89 16:40:30 GMT
From: swrinde!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive
  !uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
  !p.cs.uiuc.edu!johnson_@ucsd.edu
.fi
.PP
chittamu_@umvlsi.ecs.umass.edu begs to differ with my claim that
reusing code requires understanding it, which sometimes
requires reading it.  He says that we should not have to read code, 
but only need to understand the function of the code.
.PP
This is an idealist's position.  Documentation is almost never
good enough.  Some people spend most of their time running
experiments on libraries trying to figure out what they do.
Others junk the libraries.  The systems that are most successful
for reuse usually make source available, because every so often
the users need to look at the code.  I know several companies that
refuse to buy libraries of components unless they get source.  It
might not be impossible to make libraries that are completely
useable only from the documentation, but it sure is hard.
.PP
An entirely different line of argument is that there is no difference
between programs and program specifications.  Either a program
specification is complete (it specifies everything of interest
about the program) or it is partial.  If it is complete, then it
is a program.  It may be written in a language that we don't
know how to compile efficiently, but that is just the inadequacy
of our compiler technology.  (I *know* about undecideability, and
it does not change my position.)  If it is partial then there will
be things we need to know about the program that is not in the
specification.
.PP
People who must put up with low-level languages can find it hard
to see that complete program specifications are just another way
of programming.  However, I program in Smalltalk at as high a level
as possible.  The result is that my programs look a lot like the
formal program specifications that I have read.  Of course, I don't
think that Smalltalk is as abstract as it should be, but it is one
of the better existing languages for programming at a very high level.
.PP
Smalltalk has lots of practical problems that can make it inappropriate
for commercial use.  However, it is possibly the best system for
software reuse.  In my opinion, everybody who is seriously interested
in reusable components should study Smalltalk to see what it did right.
The browser is an extremely important reason why Smalltalk is good for
reuse.  It assumes that code is readable.  I think this is important,
and people who expect to sell components without providing source
should ponder what they must do to overcome the fact that their users
won't be able to read their code.
.SUBSUBSECT From Joe Fitzgerald
.index Fitzgerald, Joe
.nf
Date: Mon, 23 Oct 89 08:14:48 EDT
From: fitz_@ctc.contel.com (Joe Fitzgerald)

m2c!umvlsi!chittamu_@husc6.harvard.edu  (Satish Kumar .C) writes:
.index Kumar .C, Satish

>In article <130200014_@p.cs.uiuc.edu> johnson_@p.cs.uiuc.edu writes:
>>
>>Reusing code requires understanding it.  Understanding code
>>requires at least reading the documentation, and sometimes
>>reading the code.

> I beg to differ. Reusing code requires understanding the *function* of
> the code and not the code itself. If you know precisely what the code is
> supposed to do, then you can reuse it without reading thro' the
> implementation of it. If reusable code requires us to read thro' its
> implementation, then in my opinion it is not truely reusable. It
> defeats the very purpose of having package specification and module
> interfaces. Reuse is fine. I am strong advocate of it. But not when I
> have to read thro' the code.  The only thing I would necessarily need to
> read is the documentation describing the purpose of the code.
.fi
.PP
I agree that the function of a piece of code is necessary for reuse.  But there
are many situations in which the code's function and/or data that is being
operated upon are only SIMILAR to your own requirements.  To this point
it is open for debate whether or not one should take the time to understand
the code you have and reuse it, or start from scratch.  I would venture that
most (not all!) of today's programmers would opt for the second choice and 
write their own code, this being only one manifestation of the
"not-invented-here" syndrome.  The point is, reuse sometimes involves
adaptation and along
with that comes the responsibility of reading and understanding what you
are adapting.
.SUBSECT Maintenance
.SUBSUBSECT  From Travis Marlatte
.index Marlatte, Travis
.nf
Date: 19 Oct 89 01:32:07 GMT
From: gem.mps.ohio-state.edu!ginosko!shadooby!mailrus
  !accuvax.nwu.edu!delta.eecs.nwu.edu!travis
  _@tut.cis.ohio-state.edu  (Travis Marlatte)
.fi
.PP
The discussion was kind of heading in the direction of using maintenance
as a training vehicle for new engineers. I think most of us agree that
this is wrong. Exposure only to maintenance is probably not the
way to bring a new programmer up to speed for design.
.PP
Whoops. There I said it again. The goal is create good designers. Somehow,
to be a good programmer, I believe one has to become a good designer. Even
in maintenance, and we all know I think that job is scum, good design
techniques are paramount to making sound revisions - whether defect fixes
or enhancements.
.PP
Contrary to my sarchastic comment above, I love maintenance. I have always
been one to enjoy tearing something apart, figuring out how it works, and
how to make it work better. I would think that most engineers have this
same attitude.
.PP
I do think that maintenance as a training vehicle is a waste of time. The
trainee learns nothing except how stupid past developers were. The company
may benefit from freeing up its more highly prized programmers but there
certainly is a cost of poorly done maintenance.
.PP
Actually, maintenance is an important part of new design as well. I can't
count how much time I've saved by striping a piece of code from a past
product and using it in a new design. Gosh - reusable software.
.PP
To reiterate my position - apprenticeships or something similar seem
like a pretty clean way of approaching training. Note that this does
address the new employee whether novice or experienced. Some formal program
to help the experienced programmer fit in with the company is just as
appropriate as a formal program to bring the novice up to speed.
.PP
A few comments on licensing: (are you out there Ms. Richards?) Licensing
does not prove competence or ability. It merely transfers liability. And
that usually doesn't work either. Licensing should mean nothing to a fellow
programmer (or engineer). It is only a stamp of approval from a publicly
recognized body and it is for the benefit of the public.
.PP
Licensing can only be used as a first defense against blithering idiots
passing themselves off as professional programmers. I am quite confident
that the programmers responsible for recent widely publicized software
failures were nothing but professionals and would have gained a license
if such were required.
.SUBSUBSECT From Robert Osborne
.index Osborne, Robert
.nf
Date: 19 Oct 89 21:00:25 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!censor
  !isgtec!robert_@tut.cis.ohio-state.edu  (Robert Osborne)

In article <1337_@accuvax.nwu.edu> travis_@delta.eecs.nwu.edu
(Travis Marlatte) writes:
.index Marlatte, Travis
>The discussion was kind of heading in the direction of using maintenance
>as a training vehicle for new engineers. I think most of us agree that
>this is wrong. Exposure only to maintenance is probably not the
>way to bring a new programmer up to speed for design.
.fi
.PP
I think a small bug or new piece of functionality is the best way to bring
somebody up to speed.  The new engineer MUST be guided by a
experienced engineer throughout this experience.  However, leaving somebody
in maintenence for a long time is probably a good way to kill morale and
enthusiasm.
.sp
.nf
>I do think that maintenance as a training vehicle is a waste of time. The
>trainee learns nothing except how stupid past developers were.
.fi
.PP
The key is to make the trainee *SEE* what bad design, habits, styles,
whatever do to a maintenance effort, and just what bad design etc. *IS*.
Of course if the trainee is modifying my stuff they get to see a great
implementation of a good design :-).
.sp
.nf
>Actually, maintenance is an important part of new design as well. I can't
>count how much time I've saved by striping a piece of code from a past
>product and using it in a new design. Gosh - reusable software.
.fi
.PP
Exactly, get them to explore the system and see what there is out
there for them to steel.
.sp
.nf
>A few comments on licensing: 
>[...] It merely transfers liability. [...]
>[...] It is only a stamp of approval from a publicly
>recognized body and it is for the benefit of the public.
.fi
.PP
It also gives you somebody to pin the blame on and to sue :-(.
Like an civil engineer (at least in Ontario) must stamp building plans,
and if it falls down they catch it (bad pun intended :-).
.SUBSUBSECT From Lee Sailer
.index Sailer, Lee
.nf
Date: 20 Oct 89 16:34:15 GMT
From: psuvm!uh2_@psuvax1.cs.psu.edu  (Lee Sailer)
.fi
.PP
One hears the phrase, "Maintenance through redesign."  The idea is that to
modify a program, one goes back to the analysis and design documents, e.g.,
Data Flow Diagrams, Logical Data Models, Structure Charts, or whatever and
makes the modifications there, moving step by step through the entire process
til the coding stage is reached.
.PP
On the other hand, to many practitioners, maintenance means jumping in and
hacking the code.
.PP
It seems to me that the first type of M-- would be very educational, and a good
way to bring a new hire up to speed on local customs, the nature of the
system, and so forth.
.SUBSUBSECT From Kevin W. Wall
.index Wall, Kevin W.
.nf
Date: 3 Nov 89 03:44:30 GMT
From: att!cbnews!kww_@ucbvax.Berkeley.EDU  (Kevin W. Wall)

In article <1337_@accuvax.nwu.edu> travis_@delta.eecs.nwu.edu (Travis Marlatte)
writes:
.index Marlatte, Travis

>I do think that maintenance as a training vehicle is a waste of time. The
>trainee learns nothing except how stupid past developers were.
.fi
.PP
I disagree; I think it is *valuable* that trainees "learn how stupid past
developers were".  The reason:
.li +5
.PP
We are usually blind to our own mistakes, but not to the mistakes
of others.
.li -5
.PP
I find this an excellent way to point out bad habits in a trainees'
programming style.  (Remember the story of not removing the splinter from
your colleague's eye until I have removed the plank from my own?)  I learned
as much looking at "bad" code, as I did looking at "good" code.
.PP
Trainees "fresh out of grad school" seldom (ever?) have to go back several
years later and make changes to their own code (which are usually only
simple, toy programs anyway).   Fifty percent or more of the total software
life-cycle is made up of the maintence phase, yet this is one aspect where
our CS departments have failed us miserably.  Approaching an existing 50,000
line software system which you neither designed nor wrote is a WHOLE LOT
DIFFERENT than writing a 5,000 line program from scratch.  Just once I'd
like to see a homework assignment in some CS course be something like
.PP
"add features X and Y to this 60,000 software system (which the
students have never seen before) and turn it in next week".
.PP
The "discovery process" (i.e., figuring out how a particular design or piece
of code (mis)behaves involves a entirely different set of skills than does
the "creation process".  Yet no formal training is given for the
"discovery process", which is so vital to the maintenance phase of software.
.sp
.nf
>Actually, maintenance is an important part of new design as well. I can't
>count how much time I've saved by striping a piece of code from a past
>product and using it in a new design. Gosh - reusable software.
.fi
.PP
Exactly!  But of course "code stealing" (or "stealing" of any kind) is another
thing which is strongly discouraged in traditional education.  Yet to really
be successful in the real world, "code stealing", design stealing, etc. is
ESSENTIAL.  I don't know how many green horns fresh out of grad school I've
worked with who wasted needless company time writing the own sort function,
hashing functions, DBMS, etc. because 1) they weren't aware that stealing
is an encouraged/expected part of the culture, or 2) they weren't aware of
the existence of these packages, or 3) they thought they could do a better
job than what was available from standard libraries or commercial vendors
(of course, sometimes they do; but usually not).
.PP
<<<Put on asbetos underware>>>
Now for the inflamatory remark... IMHO, I think a large part of the blame for
the software crisis has to be placed on the shoulders of the formal education
system.  To put it bluntly, CS departments are not teaching the necessary
skills to be successful in industry.  (They do however, teach the necessary
skills to be successful in academia.)  If they ARE teaching the necessary
skills, perhaps someone can comment on why it is that many of the folks that
have had little or no formal software education (1 or 2 yrs undergrad or
associate degree at the max) can run circles around many of the supposedly
.index reuse, software
.index software reuse
brightest M.S. and Ph.D. graduates in computer science?  Not only in the
area of coding, testing, designing, and debugging, but also in common sense.
I've seen this happen too many times in my past 10 yrs here to believe that
it is just coincidence.
.PP
A colleague of mine who attended a Demming (the quality guru) lecture said that
someone in the audience remarked that "Bell Labs only hires the top 10% of
all the graduates" (implying "how could they have all those quality problems?").
Demming replied, "well, the deserve what they get".  Perhaps he had a valid
point.
.PP
Now let me clarify one thing before my E-mail box overflows... I am NOT
saying or even implying that current CS curricula is not valuable.  What
I AM trying to say is that I think it could be a LOT more relevant
(to the real world, vs. the academic world).
.PP
Of course, my opinions do not necessarily reflect those of my employer.
(...fortunately for me, since I was 1 of those top 10% of the villagers. :-)
.SUBSECT Seeing Component Source Code?
.SUBSUBSECT From Bruce Weide
.index Weide, Bruce
.nf
Date: 20 Oct 89 21:35:00 GMT
From: elephant.cis.ohio-state.edu!weide_@tut.cis.ohio-state.edu  (Bruce Weide)
.fi
.PP
Occasionally something goes by on this newsgroup that cries out for a
response.  Case in point: Recently Ralph Johnson made an argument that
in order to reuse a software component, one must be able to see its
source code.  The essence of his case seemed to be: (1) Writing formal
behavioral specifications for components is hard.  (2) A complete
formal specification IS a program.  (3) Smalltalk programs he has
written look a lot like specifications he has seen.  Therefore, why
not just stick with source code and forget formal specifications?  Or,
perhaps, why not write formal specifications but still provide source
code just in case?  (I couldn't tell for sure what the conclusion was.
These seemed likely candidates.)
.PP
(1) Writing formal behavioral specifications for components is hard.
.PP
Here there is no disagreement.  Fortunately, one of the nice things
about reusable components is that relatively few people need to be
able to WRITE specifications.  Lots of people need to be able to read
them.  This suggests that, while writing specifications is presently
difficult, we really ought to be working on specification methods and
languages that also emphasize ease of understanding.  Of course it
will also help to improve the ease with which specifications are
written.  Both areas call for further work.  But one should not
conclude from the fact that specs are hard to write NOW that it must
always be so.  Nor should one conclude that they are necessarily hard
to understand.  In fact I think we already have the concepts necessary
to write comprehensible formal specifications of non-trivial
components, and plenty of anecdotal evidence that both CS students and
practicing software engineers in industry can understand them; I have
previously commented on such techniques in this forum.  (By the way, I
don't think Ralph was really claiming that formal behavioral
specifications are INHERENTLY IMPOSSIBLE to write or INHERENTLY
DIFFICULT to read and understand, which seems to be what is needed to
support his argument.  If that is the claim it's going to be difficult
to defend.)
.PP
(2) A complete formal specification IS a program.
.PP
On this point there may be some grounds for disagreement.  Formal
specifications for a component will in general be abstract and
implementation-neutral, i.e., they will hide both representation data
structures and algorithms used in the component's implementation,
explaining behavior in abstract terms, and admitting of multiple
plug-compatible implementations.  Specifications say WHAT the
component does, not HOW it does it.  Now there's a hell of a gap
between such specifications and the source code for an implementation
in an algorithmic language.  To claim that this is "only" a compiler
technology issue -- that a smart compiler can invent an acceptable (in
performance) implementation from such abstract specifications -- is a
remarkable leap of faith that flies in the face of reality.
.PP
(3) Smalltalk programs Ralph has written look a lot like
specifications he has seen.
.PP
Perhaps Ralph's real claim in (2) is that one might simply consider
the specifications to BE the source code.  I can only suggest that
such "specifications" are inappropriately named.  If they reveal any
representational or algorithmic details of HOW the component works
they are not specifications by the above definition.  I'm not fluent
in Smalltalk, and maybe Ralph's programs look a lot different from
Smalltalk code I've seen.  But those samples don't look much like
formal specifications to me.
.PP
SUMMARY - Can we agree on the general definition, the nature/purpose
of formal "specifications": to say WHAT the component does?  Can we
agree on the nature of "source code": to say HOW it does it?  Can we
agree that these are not the same thing?  If so, I think we ought to
be able to agree on something about the nature of reusable components
in a (future?) software components industry: There is no reason in
principle that a client programmer should need to examine component
source code in order to understand what the component does.
.PP
If we can't agree on the above definitions, we'd better move the
discussion back to that issue.
.SUBSUBSECT From Ralph Johnson
.index Johnson, Ralph
.nf
Date: 25 Oct 89 00:11:25 GMT
From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu
  !ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
  !p.cs.uiuc.edu!johnson_@tut.cis.ohio-state.edu
.fi
.PP
I argued that to reuse a software component, one must be able to see its
source code, and that it was a mistake to think that formal specifications
were going to solve the problem.
.PP
Bruce Weide summarized my argument as
.index Weide, Bruce
.LIST
.LE
Writing formal behavioral specifications for components is hard.  
.LE
A complete formal specification IS a program.  
.LE
Smalltalk programs I has written look a lot like specifications I
has seen.
.ELIST
.PP
It is always interesting to see how others interpret my words.
I don't think (1) is a crucial point.  (2) is crucial, and (3)
is just there to back up (2).  In fact, I don't think that Smalltalk
is at all unique in this regard.  For example, the first Ada compiler
was written in SETL and was really more of a specification for Ada,
or a design of an Ada compiler, than it was a "real program".  Although
it was executable, it only compiled a few lines per minute.
.PP
My last message elaborated on (2).  However, I've been thinking about
(1).  I'd like to say some provocative things.
.PP
First, to the best of my knowledge, nobody has written formal behavioral
specifications for a real component library.  There was a group at
Tektronix that was using Z to specify a few Smalltalk classes, and there
is a group here at Illinois that is using Z to specify a few classes
from a library of operating system classes written in C++, but neither
of these groups are dealing with more than a few classes.  There is
also the Larch group at MIT, though I haven't seen anything from them
dealing with real libraries.  It seems to me that the burden of proof
is on the side of those who claim that it is reasonable to expect to
have formal specifications for component libraries.  I would love to
be proved wrong.
.PP
I am not one of those who think that formal specifications are useless.
Quite the contrary, I demand that my students take courses in programming
language semantics and program verification, and I studied both when I
was in graduate school.  However, so far the effect of these topics on
computer science has been indirect.  They have helped us invent better
languages and learn to think about programming better, but they have had
little use in commercial programming.  Perhaps this will change soon, but
I see little sign of it.  There are too many unsolved problems, like how
to reason about pointers.  On the other hand, I am greatly in favor of
more research being done on the problem and wish that the area was
funded a lot better than it is.  It is an important problem, and one
worthy of the attention of many people, but it is an area that offers
many interesting research topics, not one that offers ready-made solutions
to current practical programming problems.
.SUBSUBSECT From Ralph Johnson
.index Johnson, Ralph
.nf
Date: 25 Oct 89 00:11:21 GMT
From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu
  !ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
  !p.cs.uiuc.edu!johnson_@tut.cis.ohio-state.edu

 weide_@elephant.cis.ohio-state.edu said
>Occasionally something goes by on this newsgroup that cries out for a
>response.
.fi
.PP
Naturally, I was trying to get a response!  I'm glad I succeeded.
.PP
There are lots of things I could say in response, such as I disagree
with the idea that it is irrelevant how hard it is to make reuseable
code because the cost will be amortized later.  However, the main
point that I was trying to make was that in practice there is no
real difference between a complete specification of what behavior
a component has and a specification of how it is implemented.
In other words, I think that the generally well accepted idea that
"Formal specifications for a component will in general be abstract and
implementation-neutral, i.e., they will hide both representation data
structures and algorithms used in the component's implementation,
explaining behavior in abstract terms, and admitting of multiple
plug-compatible implementations" is wrong.  It is only correct for
specifying tricky algorithms, i.e. fast, complex algorithms for
problems that also have slow, simple algorithms.  It is certainly
false for most real code, which consists of mostly user interface.
Moreover, to the extent that it is true, it is also true of programs
written in very-high-level languages.
.PP
There is certainly a wide semantic gulf between formal specifications
and Pascal programs.  This is irrelevant to the claim that there is a
.index Pascal
wide semantic gulf between formal specification languages and ALL
programming languages.  For example, there are many formal specification
languages that are executable.  Thus, these specification languages
are also programming languages.  More to the point I am trying to
make, real high-level languages (i.e. not Pascal or C) can look
very much like specification languages.  For example, compare these
specifications of stacks.
.sp
.nf
class stack
	sequence elements;
push(elem) = {elements := elements, elem}
pop() = {elements := elements(1:(elements.size-1)}
top() = {return elements.last}
empty() = {return elements.size = 0}

or

pop(push(elem,S)) = S
top(push(elem,S)) = elem
empty(push(elem,S)) = false
empty(newstack()) = true
.fi
.PP
The second (the "abstract" specification) is shorter, but not much
easier to read.  Most importantly, it is not easier to understand.
Thus, I claim it is no better as a specification than the first.
.PP
Stacks are about the easiest component for which one can write a
formal specification.  However, a better example to show the strengths
of formal specifications would be sorting, since the specification is
that the output sequence is a permutation of the input sequence and
that the output sequence is sorted, while most fast sorting algorithms
take a lot of more code to express.  This is an example of a problem
for which there exists both fast complex algorithms and slow simple
algorithms.  The specification I described corresponds to the sorting
algorithm that takes each permutation and checks whether it is sorted.
This simple specification could be represented just as well by a program.
.PP
To raise a last point, we probably disagree on what a component is.
I don't believe in the mythology that we will be able to reuse
components without changing them.  It is very hard to predict how
people will want to change components, so it is very hard to know
what information to hide.  Components include abstract classes and
frameworks, which are really just partial programs.  This makes it
even harder to make provide specifications that are different from
the code, significantly simpler, and useful.
.SUBSUBSECT From Bruce Weide
.index Weide, Bruce
.nf
Date: 25 Oct 89 22:08:00 GMT
From: elephant.cis.ohio-state.edu!weide_@tut.cis.ohio-state.edu
  (Bruce Weide)
.fi
.PP
Ralph Johnson's recent comments about the differences between
.index Johnson, Ralph
specification and implementation call for a few more comments and
questions of clarification.
.PP
(1) Ralph gives an example of a simple implementation of stacks and
simple algebraic specification, and concludes:
"The second (the "abstract" specification) is shorter, but not much
easier to read.  Most importantly, it is not easier to understand.
Thus, I claim it is no better as a specification than the first."
.PP
I'm not sure I understand the point of this example, except that it is
POSSIBLE for an implementation to be about as short and as simple as
its formal specification.  No argument there.  But the claim that the
algebraic specification is "THE abstract specification" is too strong.
There are other well-known specification methods that, we would both
apparently agree, render specifications easier to comprehend than the
algebraic approach.  Such specifications remain abstract but do not
rely on using equations, as in Ralph's example.  Such alternative
specification methods should result in easier-to-understand
specifications of stacks.
.PP
Admittedly these alternatives might look on the surface very much like
Ralph's source code (for this example but not in general).  But they
are subtly and importantly different in meaning precisely BECAUSE they
are abstract.  One might, for example, use a mathematical sequence as
a mathematical model of a stack.  But there would be no implication
that program sequences are used in the implementation, as apparently
Ralph has done in his code.  This is important for lots of reasons,
upon which I can elaborate if the discussion continues along this
line.
.PP
(2) Ralph continues:
"Stacks are about the easiest component for which one can write a
formal specification.  However, a better example to show the strengths
of formal specifications would be sorting, since the specification is
that the output sequence is a permutation of the input sequence and
that the output sequence is sorted, while most fast sorting algorithms
take a lot of more code to express.  This is an example of a problem
for which there exists both fast complex algorithms and slow simple
algorithms.  The specification I described corresponds to the sorting
algorithm that takes each permutation and checks whether it is sorted.
This simple specification could be represented just as well by a
program."
.PP
The general claim here seems to be that for a reusable component with
a compact formal specification, there is also a simple but possibly
inefficient ALGORITHM that is its implementation and that, to some
people at least, would be easier to understand.  This seems unlikely
at best.  Consider a simple example.  Suppose you have a component
that keeps track of a function from some domain type D to some range
type R (both parameters to the component).  You want to specify a
boolean-valued operation that returns "true" given f and r iff
function f maps some value of type D to the specific value r.  This is
easy to specify in the abstract using an existential quantifier;
something like:
.sp
.ce
there exists d:D such that f(d) = r
.PP
Presumably the source code to explain this behavior consists of a
program to search through all values of type D for one that f maps to
r.  Two problems here.  First, D may not be finite, in which case this
is not an algorithm at all because it may not terminate and could
never return "false".  Second, how do you write this program (except
in pseudocode or something) without knowing what type D is?
.PP
But Ralph has provided a good idea here: to challenge specification
writers to design and specify a component that permits one to do
sorting.  I'm happy to oblige, and will post such specs to this forum
if asked to do so.  But we should also be able to see the "simple
specification" mentioned in the last sentence above for comparison
purposes relative to ease of understanding.  A biased audience,
readers of this forum, but we might get some info nonetheless.
.PP
Of course, comparisons on other grounds (e.g., ease of verification
that alternative implementations meet the specs; whether the spec
method helps one design a good reusable component in the first place;
lots of other questions) might be too difficult to carry out in this
forum.  But it would be a start at seeing whether people might prefer
to see source code or formal specifications for their reusable
components.
.SUBSUBSECT From Bruce Weide
.index Weide, Bruce
.nf
Date: 25 Oct 89 22:23:48 GMT
From: elephant.cis.ohio-state.edu!weide_@tut.cis.ohio-state.edu
  (Bruce Weide)
.fi
.PP
Ralph Johnson's second reply to the question of the place of formal
specification was very interesting.
.PP
I'd like to add our group to his list of those who have written formal
specifications for "real" components.  Ralph, I'll send you a few
reports if you wish; just drop me a note.  I wish I could cite a bunch
of papers we've had published but few people seem to want to hear what
we're trying to say.  That's one of the reasons we think this
newsgroup is so important: at least the people here have not already
abandoned the idea that reusable software components might someday
become practical.  Nor are they convinced that they already know the
one-and-only way to do something.
.PP
That leads to Ralph's claim that one of the deficiencies in relating
formal specification, verification -- formal methods in general -- to
real programming is the difficulty of dealing with pointers.  How
true!!!  Again, all I can say is that we have done quite a bit of work
on this, but it generally falls on deaf ears.  Many people can't
imagine programming without pointers sticking out of everything, so
don't even bother suggesting that pointers spell trouble.  But this is
another important reason that formal specifications are important and
that you don't want to look at source code to try to understand a
component's behavior.  By making specifications abstract, one can
shield a client of a reusable component from all the pointer tricks
that often need to be played in the implementation in order to
implement it at all, and certainly to make it efficient.
.PP
I guess the bottom line is that Ralph might grant that, if certain
technical problems could be solved, there might be some hope for
substituting formal specifications for source code as descriptions of
component behavior.  Ralph, if I've misrepresented your position on
this, please advise.
.SUBSUBSECT From John Hogg
.index Hogg, John
.nf
Date: 26 Oct 89 00:29:42 GMT
From: cs.utexas.edu!mailrus!jarvis.csri.toronto.edu!db.toronto.edu
  !hogg_@tut.cis.ohio-state.edu  (John Hogg)
.fi
.PP
Ralph Johnson has claimed that every specification is a program, and this
.index Johnson, Ralph
statement has been challenged by other posters.  Since I take it as an
article of faith myself, I'll try to clarify it.
.PP
No specification or program by itself does anything, except take up disk
space.  A program (as we all learned at a tender age) is a sequence of
instructions.  These instructions must be executed by (in cases of interest
to us) a computer.  And the code we see is seldom executed directly; it is
normally processed by a compiler and friends.  Therefore, when we speak
about executing a program, we implicitly acknowledge the existence of large
amounts of hardware, software and cleverness, which make up our program
execution engine.
.PP
Specifications are not generally executed, and therefore the market for
specification language engines is thin.  However, in principle, such an
animal is quite possible.  A specification defines the set of acceptable
output states for a given input state.  (I'll certainly accept other
flavours of specification, but similar arguments can be made.)  To
implement the specification, simply enumerate the domain of output states
until one satisfying the postcondition is found.  Or, if you prefer, select
states nondeterministically until satisfaction.  If the specification is
satisfiable, then the specification engine will terminate, albeit in
unbounded time.
.PP
Bruce Weide gave a description of a specification which he claims is
.index Weide, Bruce
unimplementable:
.sp
.nf
>Suppose you have a component
>that keeps track of a function from some domain type D to some range
>type R (both parameters to the component).  You want to specify a
>boolean-valued operation that returns "true" given f and r iff
>function f maps some value of type D to the specific value r.  This is
>easy to specify in the abstract using an existential quantifier;
>something like:
>
>	there exists d:D such that f(d) = r
>
>Presumably the source code to explain this behavior consists of a
>program to search through all values of type D for one that f maps to
>r.  Two problems here.  First, D may not be finite, in which case this
>is not an algorithm at all because it may not terminate and could
>never return "false".  Second, how do you write this program (except
>in pseudocode or something) without knowing what type D is?
.fi
.PP
This isn't quite fair, because he's given a specification of a
component or function g without specifying the function f that it
uses.  If f is specified, then we can enumerate through the range
of g ({true, false}) in quite acceptable time.  The specification of f is
executed in the same manner.
.PP
The only reason that implementations are somehow more ``concrete'' than
specifications, then, is that we've gone to the trouble of building the
program execution engines.  Specification engines would actually be
easier to build in some ways, because we can be totally uninterested in
performance.
.PP
So both specifications and implementations are descriptions of a
computation, which merely differ in undescribed side effects.  Formal
verification is just the process of showing that the two are in fact
equivalent.  The advantage of the implementation is its efficiency.
The advantage of the specification *should* be its clarity.  If the
specification is no clearer than the implementation, then it is of
academic interest at most.
.PP
My PhD thesis, by the way (Extremely Real Soon Now) is on the subject of
specification and verification of object languages.  This should make
me the world's greatest booster of component selection by specification
alone.  Well, the work is worth doing so that giants can step on my
shoulders.  However, we're a long way from modular, sound, and complete
object specifications, let alone ones that are easier to read than the
source.  (Those who wish to challenge this statement are invited to do
so by mail.  Note that the claim has four adjectives and a noun that
require precise definitions.)
.PP
Probably the main advantage of formal specifications is that they can be
used to prove that if sub-components meet their specifications, their
component sum will too.  But that's a property of an associated proof
system, not the specification language per se.
.SUBSUBSECT From George Mitchell
.index Mitchell, George
.nf
Date: 25 Oct 89 12:51:23 GMT
From: snorkelwacker!spdcc!merk!alliant!linus!community-chest
  !mitchell_@tut.cis.ohio-state.edu  (George Mitchell)
.fi
.PP
Until your last posting you were only getting close, but now you have
really "pushed my button".
.sp
.nf
In article <130200016_@p.cs.uiuc.edu> johnson_@p.cs.uiuc.edu writes:
.index Johnson, Ralph
>
>To raise a last point, we probably disagree on what a component is.
>I don't believe in the mythology that we will be able to reuse
>components without changing them.  It is very hard to predict how
>people will want to change components, so it is very hard to know
>what information to hide.  Components include abstract classes and
>frameworks, which are really just partial programs.  This makes it
>even harder to make provide specifications that are different from
>the code, significantly simpler, and useful.
>
.fi
.PP
At OOPSLA '89 the statement was made (I wish that I had said it) that
modifying [code/component] was not reuse but recycling.  Since the cost
of producing code is a small portion of the total lifecycle cost, the
.index OOPSLA
goal of reusing complete components should not be so quickly abandoned.
The potential savings in testing and maintenance are well worth while.
If this requires extensive domain analysis, system designs constrained
by component availability, and use of languages supporting inheritance,
the benefits should usually be well worth the sacrifices.
.SUBSUBSECT From Bruce Weide
.index Weide, Bruce
.nf
Date: 26 Oct 89 15:51:14 GMT
From: elephant.cis.ohio-state.edu!weide_@tut.cis.ohio-state.edu
  (Bruce Weide)

I recently suggested an operation that I claimed could be more easily
specified abstractly than by giving source code for an implementation:
 ">Suppose you have a component
  >that keeps track of a function from some domain type D to some range
  >type R (both parameters to the component).  You want to specify a
  >boolean-valued operation that returns "true" given f and r iff
  >function f maps some value of type D to the specific value r.  This is
  >easy to specify in the abstract using an existential quantifier;
  >something like:
  >
  >       there exists d:D such that f(d) = r
  >
  >Presumably the source code to explain this behavior consists of a
  >program to search through all values of type D for one that f maps to
  >r.  Two problems here.  First, D may not be finite, in which case this
  >is not an algorithm at all because it may not terminate and could
  >never return "false".  Second, how do you write this program (except
  >in pseudocode or something) without knowing what type D is?"
.fi
.PP
John Hogg has subsequently suggested that I claimed that the
.index Hogg, John
specification "was unimplementable."  Sorry for the confusion; this is
not what I meant to imply.  It is quite implementable.  It's just that
the "obvious," and therefore presumably easy-to-understand
implementation that would make the "source code specification" of
behavior simple, is not in fact a correct implementation.
.PP
John goes on to say:
"This isn't quite fair, because he's given a specification of a
component or function g without specifying the function f that it
uses.  If f is specified, then we can enumerate through the range
of g ({true, false}) in quite acceptable time.  The specification of f is
executed in the same manner."
.PP
Perhaps I wasn't being clear enough, or I don't understand John's
point.  The reusable component I have in mind provides a type whose
ABSTRACT MATHEMATICAL MODEL is a function from D to R; let's call it
type "foo" so we don't confuse it with a program function.  The
component also provides operations that permit the client to construct
a foo, and also provides an operation that asks the question above:
for the foo variable f (which has been constructed in this way), does
any value of its domain map to r?  The specified doesn't know what
mathematical function models f.  All he/she knows about f is that it
has been constructed by the client using the operations provided by
the component to operate on variables of type foo.  The fact that the
abstract specification of this component may talk about f as though it
were a mathematical function is what makes the abstract specifications
simple.  That source code doesn't have this abstract view of f is
what, I claim, will make writing "source code specifications" more
difficult and make them harder to understand.  (Not impossible, just
clumsier.)
.PP
Overall I agree with most of John's points, and in particular with his
view of what verification is all about and what properties it should
have (modularity, soundness, etc.).  This is another reason for having
abstract specifications.  If one wishes to reason about the
correctness of programs -- whether they meet their specifications --
one should probably draw on the ready supply of techniques, notations,
and concepts of mathematical logic to do this reasoning.  Having
abstract specifications, for both the component being implemented and
the components its implementation uses, seems to support this approach
directly.  Reasoning about the relationships among concrete
implementations of components would seem, by comparison, to be more
likely to cause problems when issues of soundness, relative
completeness, etc., are considered.  Again, I'm not claiming that it
would be impossible to do it that way, just that the abstract approach
seems more promising from here because it "reuses" what mathematicians
have already done.
.SUBSUBSECT From Ralph Johnson
.index Johnson, Ralph
.nf
Date: 27 Oct 89 11:05:00 GMT
From: tank!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu
  !p.cs.uiuc.edu!johnson_@handies.ucar.edu
.fi
.PP
I guess I don't really believe that "if certain
technical problems could be solved, there might be some hope for
substituting formal specifications for source code as descriptions of
component behavior."  That might be true, but it remains to be seen.
.PP
It is pretty hard to *prove* my opinion.  Even if we haven't
started using formal specifications a hundred years from now, the
solution might lie right around the corner.
.PP
So far, we have been debating my claim that there is not that big
a difference between specifications and programs.  My claim is
that our programming languages will improve to the point where
they let us write programs that are just like the specifications.
For example, the specification
.sp
.ce
f(x)=y, where y is in D and g(y)=x
.sp
can be written in Smalltalk as
.sp
.ce
D detect: [:y | y g = x].
.PP
I know the notation is a little wierd, but that's not the point.
The point is that it is POSSIBLE to write programs on the same
level as the specifications.  If D is infinite then the program
might not terminate, but I write infinite objects all the time
(i.e. the stream of all prime numbers).  Naturally, I tend to
reimplement these inefficient programs as time goes on, though
it would be possible to argue that what I am really doing is
starting with specifications and incrementally implementing them.
In fact, that's how I like to think about it.
.PP
The second point that I think is important is that most of the code
in a large system is not algorithmic, and is not amenable to this
kind of specification.  The specification of user interfaces, for
example, tends to look an aweful lot like the implemenation unless
you go to a lot of work to invent higher level concepts.  For example,
if you worry about exactly how the screen will look then the specification
is just a slow implementation.  On the other hand, if you introduce the
idea of "choices" and say that a particular "choice" can be made by a
"menu" then you can reason about the problem much more abstractly.
However, modern user interface management systems are moving in this
direction---they are making these specifications executable.
.PP
The third point is specific to object-oriented programming, which
I think is the best way to achieve code reuse.  One of the several
important ways to reuse software (some people seem to think this is
the only one o-o languages provide, which is wrong) is to inherit
a class and to override some of the procedures from it.  This ability
to override procedures is crucial---many classes are designed in such
a way that they cannot be reused until procedures are overridden.
It is possible to provide formal specifications of the procedures that
you expect will be overridden, but it turns out that it is very hard
to predict exactly what will be overridden.  A class is most reusable
when it is possible to override anything.  This means that every
procedure will be formally specified.  Since the median procedure size
in Smalltalk is 3 lines, this means that few procedures will have
formal specifications that are anything other than their implementation.
Thus, providing formal specifications is really the same thing as
providing the implementation.
.PP
I would like to advance a fourth argument, which is one that I have
not used before.  That argument is that almost all the design effort
goes into making the formal specification.  That is one of the reason
that formal specifications are so important.  They let you debug a
program at a high level, where it is easy to think about the problem.
Of course, I believe in programming at a high level, but lots of other
people seem to be content with C, and it certainly is a good idea for
them to design their system at a higher level and then translate it
into the lower level.  The effort in designing an object-oriented system
is defining the classes and their interfaces.  Once you give this away
to people, it is easy for them to recreate the code.  Thus, programs with
formal specifications are almost as easy to recreate as programs with
source provided are to understand.  This argues that formal specifications
are not going to be solutions to the problem of protecting the ownership
rights of the authors of the components.
.PP
Research in formal verification has had many influences on CS.  One of
the most important is that it has taught us what is difficult.  For
example, it showed that goto statements were hard to think about.
It also shows that pointers are hard to think about.  This is why
lots of modern languages, especially the symbolic ones, don't have
explicit pointers.  However, the effect is for programming language
designers to borrow good ideas from the specification people.  I
think that the future will lie in that direction.
.SUBSUBSECT From Steve Cook
.index Cook, Steve
.nf
Date: 30 Oct 89 14:29:16 GMT
From: mcsun!ukc!icdoc!qmc-cs!steve_@uunet.uu.net  (Steve Cook)

In article <130200018_@p.cs.uiuc.edu> johnson_@p.cs.uiuc.edu writes:
.index Johnson, Ralph
>
>Research in formal verification has had many influences on CS.  One of
>the most important is that it has taught us what is difficult.  For
>example, it showed that goto statements were hard to think about.
>It also shows that pointers are hard to think about.  This is why
>lots of modern languages, especially the symbolic ones, don't have
>explicit pointers.  However, the effect is for programming language
>designers to borrow good ideas from the specification people.  I
>think that the future will lie in that direction.
.fi
.PP
I have been interested and rather surprised to read the articles by
Ralph Johnson which seem to be saying there is no place for formal
specification as distinct from programming in today's software
technology.
.PP
My own experience with Smalltalk-80 is that much of the time
I need to ask the question "what assumptions, exactly, does
this method make about the current state of affairs?".
.PP
In many cases this question is hard to answer. Nevertheless, if
for example I wish to alter a method, in the hope that my modification
will be a proper generalization and thus not break any
current clients of the method, I must get the answer exactly right.
Therefore I would greatly value some formal assertions which
would enable me to know the assumptions exactly.  A system of
verifying the assumptions statically would be very helpful too.
.PP
A first step towards this would be a type-checking scheme, and of
course Ralph himself has done a great deal of work in this area.
An obvious further step would be a more powerful system of static
assertions, such as the preconditions, postconditions and
invariants provided in the Eiffel system.  A step from there
would be automated support for verification of these
assumptions, and a range of more expressive constructs.
.PP
The notion of software contracting surely requires this kind of
support to make sense.  An effective contract says exactly what
is agreed without unnecessary verbiage: just like a formal
specification.  Surely Ralph Johnson is not saying that the
contract between the supplier and user of a software component
must be based on the source code?
.PP
Once the need for a language, or sub-language, of assertions
has been acknowledged, the possibility of reusability in this
domain itself emerges.
.PP
In summary I claim that formal declarations of program
properties (i.e. specifications) do play a very
important role, as statements of contract between suppliers and
consumers of software components.  Smalltalk itself in my
experience is not well-suited to this task.
.SUBSECT Conceptual Model for Software Components
.SUBSUBSECT From Will Tracz
.index Tracz, Will
.nf
Date: 3 Nov 89 14:15:58 EST
From: "Tracz, Will" <OWEGO_@ALMADEN.IBM.COM>
.fi
.PP
What follows is a portion of the working group summary that I wrote
for the Reuse in Practice Workshop sponsored by IDA and SEI that was
held this summer.  I have included the section related to the
"Conceptual Model for Software Components", initially proposed by myself
and refined with the help of the members of the working group (in
particular: Sholom Cohen - SEI, Stephen Edwards - IDA, John Goodenough
- SEI, and Larry Latour - University of Maine).
.PP
I would appreciate any feedback anyone has.  This is just a short
overview.  There is much more written, of course, with references, etc.,
but I believe this gives you the general idea.
.PP
So -- fire at Will
.sp 2
.ce
A Conceptual Model for Software Components
.PP
The conceptual model for reusable software components was an outgrowth
of the Concept/Context model initially proposed by Tracz in his
dissertation work at Stanford.  The model, referred to as the 3C model
(Concept/Context/Content) is based on defining three facets of a
software component:
.LIST
.LE
The "concept" behind a reusable software component is an abstract
canonical description of "what" a component does.  Concepts are
identified through requirement or domain analysis as providing
desired functionality for some aspect of a system.  A concept is
realized by an interface specification and an (optionally formal)
description of the semantics (as a minimum, the pre- and post-
conditions) associated with each operation.  An Ada package
specification with its behavioral semantics described in Anna is
an example of a reusable software concept.
.LE
The "content" of a reusable software component is an implementation
of concept, or "how" a component does "what" it is supposed to do.
The basic premise it that each reusable software component can have
several implementations that obey the semantics of it's concept.
The collection of (28) stack packages found in Grady Booch's
components is an example of a family of implementations for the
same concept (a stack).
.LE
The "context" of a reusable software component takes on two
dimensions that often overlap:
.sp
.nf
 i. the "conceptual context" of a reusable software component and the
ii. the "contentual context" of a reusable software component.
.fi
.sp
There is a direct correlation between context and parameterization.
At first glance the conceptual context might be thought of as the
data (or attributes of the data) being manipulated by the concept.
Similarly, the contentual context might be the implementation details
or options that can be selected at compile or run-time.  One should
note that while it is often the case that the concept and content
of a component share the same context, the context of an
implementation often subsumes that of the concept and extends it
with performance trade-offs, hardware platform, operating system,
algorithmic, or language dependent contextual information. An example
of a conceptual context is the type of element to be stored in a
generic stack package (an instantiation parameter).  An example of a
implementation context is a conditional compilation variable that
selects between UNIX and DOS operating system calls.
.ELIST
.PP
The example used for discussion by the working group was the concept of
sorting.  The sorting concept can not be described without a context (Note:
All concepts and contents have a context! In fact one of the most common
problems faced with trying to reuse previously written software is
determining the assumptions made by the original developer.  These assumptions
often encompass the contextual information that is buried in the interface
or implementation and point out the need to separate the context from the
concept and content of a reusable software component!).   The context used
to describe the concept of sorting includes a list of elements that have
a partial order on them (a characteristic of the elements in the list).
Therefore the context associated with sorting concept, that is the data
and data structure being sorted.  This data structure must have certain
properties associated with it, that is, it's context can, in turn, be
described in terms of properties of its elements --- that a linear order
relationship is defined on them.  This is an example of a concept (sorting)
whose context (lists) is itself a concept that has a context of the linear
order relationship on its elements.  Note also, the linear order
relationships can be satisfied in many ways (e.g., less than, greater
than, is a member of).  These are all examples of the conceptual context
of the sorting software component.
.PP
Focusing now on contentual context, there can be several implementations
of lists (e.g.  linked list, arrays, or files), therefore the content or
implementation associated with the concept can take any of a number of
forms based on different contexts.  Similarly, there exists several sorting
algorithms, each perhaps more suited for different implementations and
attributes of the data (e.g., nearly sorted data), each having different
run-time performance and resource characteristics.
.PP
The selection of an implementation, or the content of the concept is
determined by trade-offs in context.  Clearly, knowing the characteristics
of the type of data structure being manipulated will lead to more efficient
implementations.  This can result in the population of a reuse library with
several efficient implementations of the same (parameterized) concept, each
tailored to a particular context.  At design time, a programmer could
identify the concept and define the context it is being manipulated
under based on requirements or operating constraints.  At implementation
time, the programmer could instantiate an implementation of the concept
with the conceptual contextual information plus any other contentual
contextual information necessary.
.SUBSECT Computer Virus Concerns
.SUBSUBSECT From Frank Starr
.index Starr, Frank
.nf
Date: Sunday, 24 September 1989  15:12-MDT
From: SAC.55SRW-LGS_@E.ISI.EDU
Re:   Virus Commentary
.fi
.HEAD
Sabotaged Program Reactions - An Editorial Review
.ce
by Frank Starr
.PP 
The continuing threat of virus and Trojan Horse programs - which I
prefer to call sabotaged programs, has begun to spark some reaction from
the upper levels of the Department of Defense. Concurrent with the
discovery of the so-called "Columbus Day Time Bomb", previously known as
the Datacrime Virus, has come a series of directives which may serve to
eliminate the use of all forms of shareware by D.O.D. personnel on D.O.D.
microcomputers.
.PP
Air Force users first received word of the Columbus virus from a
message published by the USAF Office of Special Investigation, republished
and mass mailed through MILNET/DDN, the D.O.D. e-mail system. Two suspected
sources have been listed - a European extremist group in the spiritual sway
of Bader Meinhoff, and a Norwegian group displeased with celebrations
honoring Columbus, while ignoring Norse discoveries preceeding those of
European explorers.
.PP
Later communiques identified the virus as the Datacrime variety,
capable of trashing the FAT area of a hard drive. From the first message to
all others received to date, a prevailing directive has been to cease using
all software downloaded from private bulletin boards. Various
interpretations have gone so far as to conclude that only vendor supplied
software should be used, to the absolute exclusion of everything else,
whether shareware available for purchase after an initial test period, or
freeware for which no fee or donation is ever asked.
.PP
All of this confusion promises to cause a lot of D.O.D. micro users to
cut themselves off from anything except commercial software, purchased
.index computer virus
.index virus, computer
through government contracting channels. This in spite of the fact that
there have even been reports about commercial software occasionally being
sabotaged by temporary employees (as reported in an issue of Government
Computer news about a year ago. Sorry, specific issue forgotten). There are
a number of micro bulletin boards in D.O.D., some of which offer shareware
software for evaluation to potential customers. Some of the SYSOPs of these
systems forsee a call to close down operations, based on reactions to
sabotaged software threats, and rough drafts of official regulations to
control software on D.O.D. micros (see the September/October C2MUG
bulletin, page 5).
.PP
Although there are some advisories for users to back up all software
on D.O.D. micros, more attention seems to be going towards the elimination
of all non-contract software on D.O.D. micros. Since sabotaged programs are
more often reported in connection with softwaree downloaded from public RBBS
systems, this game plan can be understood, if not readily supported.
However, with micro user education still a lower priority object in many
areas, and software backup not a widespread practice, it seems that,
especially with funding cuts a now and future reality, more attention would
better be given to how to defend against sabotaged programs, and perhaps
the avoidance of all forms of shareware could be reevaluated.
.SUBSUBSECT From Frank J. Wancho
.index Wancho, Frank J.
.nf
From: Frank J. Wancho <WANCHO2WSMR-SIMTEL20.ARMY.MIL>
To:   Frank Starr <SAC.55SRW-LGS_@E.ISI.EDU>
Re:   Virus Commentary

Frank,
.fi
.PP
I just read and reread your editorial.  I fear that possibly many
people will misread it, overlooking certain key words and phrases,
such as "may" in "may serve to eliminate," "various interpretations,"
"foresee," "seems" in "more attention seems to be," etc.
.PP
The actual point of your editorial, with which I agree, is in your
last sentence, which should have been a paragraph by itself (starting
with the word, "However," and broken into several sentences:
.PP
Micro user education is still a low priority activity in many
areas, and software backup not a widespread practice.  With
funding cuts a now and future reality, more attention should be
given to defending against sabotaged programs.  Then, perhaps, the
trend toward avoiding all forms of shareware could be reevaluated.
.SUBSUBSECT From Rick Conn
.index Conn, Rick
.nf
Date: Wed, 27 Sep 89 03:49:52 MDT
From: Rick Conn <RCONN_@WSMR-SIMTEL20.ARMY.MIL>
.fi
.PP
The role of ADA-SW is to support the ASR users, who are naturally
concerned with the proliferation of computer viruses.  My recent posting
.index VIRUS-L Email List
.index Email List, VIRUS-L
could trigger turning the digest into a broadcast of virus information.
Rather than doing that, interested users should subscribe to the email list
mentioned below, which is specifically geared to passing information on computer
viruses.
.HEAD
The VIRUS-L Mailing List
.PP
To get onto the VIRUS-L mailing list, send a mail message to
.sp
.nf
LISTSERV_@LEHIIBM1             if you are on the BITNET
LISTSERV_@IBM1.CC.Lehigh.Edu   if you are on the Internet
.fi
.PP
In the body of the message, say nothing more than:
.sp
.ce
SUB VIRUS-L your name
.PP
LISTSERV is a program which automates mailing lists such as VIRUS-L.
.PP
All submissions to VIRUS-L are stored in monthly log files which can
be downloaded by any user on (or off) the mailing list.  There is also
a small archive of some of the public anti-virus programs which are
currently available.
.SUBSECT 20 Most Popular Files in the ASR
.sp
.nf
[PHOTO:  Recording initiated  Wed 27-Sep-89 6:05AM]

_@
   name	                                 # refs,     rate/month,     size.
<ADA.COMPONENTS>ABSTRACT.SRC.1             1045              20     224 pgs
<ADA.COMPONENTS>LIST.ADA.2                  939              15       7 pgs
<ADA.PAGER>PAGER.SRC.5                      894              18      34 pgs
<ADA.PAGER>UNPAGE.ADA.1                     891              15       3 pgs
<ADA.AI>EXPERT.ADA.1                        882              18      15 pgs
<ADA.BENCHMARKS>BENCH.DOC.1                 867              17       3 pgs
<ADA.AI>EXPERT.PRO.1                        864              18       2 pgs
<ADA.ANSI-LRM>CHAP01.DOC.1                  863              10      12 pgs
<ADA.PAGER>PAGE.ADA.1                       857              15       3 pgs
<ADA.GKS>GKSUSER.DOC.1                      856              17      99 pgs
<ADA.GKS>GKS0A.SRC.1                        847              16     452 pgs
<ADA.GENERAL>FTP.DOC.5                      847              21      11 pgs
<ADA.GENERAL>FTP2.DOC.3                     846              17       8 pgs
<ADA.PAGER>PAGER.DOC.2                      839              17       7 pgs
<ADA.GENERAL>KERMIT.DOC.1                   837              14       7 pgs
<ADA.GENERAL>FTP1.DOC.1                     835              18       7 pgs
<ADA.COMPONENTS>QSORT.SRC.1                 834              14       3 pgs
<ADA.PRETTY-PRINTERS>PRET.SRC.1             832              16     131 pgs
<ADA.AI>EXPERT.DAT.1                        831              17       1 pgs
<ADA.COMPONENTS>PARSER.PRO.1                825              16       2 pgs
.fi
.SUBSECT SW-COMP <=> USENET Feed is Operational
.nf
Date: Fri, 13 Oct 89 05:38:10 MDT
From: Rick Conn <RCONN_@WSMR-SIMTEL20.ARMY.MIL>
.fi
.PP
The comp.sw.components newsgroup feed into SW-COMP is now operational.
.index SW-COMP Email List
.index Email List, SW-COMP
Messages from this feed will now appear in SW-COMP digests.
.PP
To subscribe to SW-COMP, send a request to:
.sp
.ce
SW-COMP-REQUEST_@WSMR-SIMTEL20.ARMY.MIL
.bp
.SECT Release Notices
.SUBSECT ASR Master Index, September 25, 1989
.PP
A new issue of the ASR Master Index, dated September 25, 1989, has
been released.  The following describes the ASR Master Index.
.sp
.nf
1. Taxonomy:
ADA BOOKS AND DOCUMENTS
ADA SOFTWARE REPOSITORY
MASTER INDEX

2. Abstract:
.fi
.PP
PD2:<ADA.MASTER-INDEX> contains a machine-readable copy of the
.index ASR Master Index
.index Master Index, ASR
Master Index, a book which documents the items in the Ada Software
Repository.  The Master Index provides descriptions of the various
items maintained in the ASR and acts as a useful, effective reference
to the users of the ASR.  Three types of items are described in the
Master Index:
.sp
.nf
  Text		text and information files

  Software	Ada software and its associated documentation

  WIS/NOSC	those items submitted by WIS and NOSC
.fi
.PP
WIS/NOSC items are mainly software, and the WIS/NOSC-specific
descriptions are in Appendix A.  All software and text items
(including descriptions of those items provided by WIS/NOSC) are
described in the chapters of the Master Index.  Chapter 1 of the
Master Index contains instructions on how to use the Master Index, how
to acquire the files in the ASR, and other information of interest to
the user of the ASR.
.PP
The *.CH files are ASCII text files which make up the title
page, table of contents and taxonomy, chapters and appendices, and
index of the Master Index.  The *.CH files files are designed to be
printed on 8 1/2" x 11" paper in elite (12 chars/inch) type.  No
margins should be preset; a 1" margin is already formatted into these
files.
.PP
The order of the *.CH files in PD2:<ADA.MASTER-INDEX> is:
.sp
.nf
	TITLE.CH	Title Page
	TOC.CH  	Table of Contents and Taxonomy
	CH01.CH 	Chapter 1
	...
	CHnn.CH 	Chapter nn
	CHA.CH  	Appendix A
	CHB.CH  	Appendix B
	INDEX.CH	Index
.fi
.PP
Other files in PD2:<ADA.MASTER-INDEX> are data files used in
the creation of the Master Index and are not of general interest.
.PP
The Support Contractor of the ASR provides hardcopy
distribution of the Master Index for those who do not wish to print
their own copies from these files.  This hardcopy is available without
cost to elements of the US Government and is available to all others
for the cost of reproduction.  Contact the Support Contractor (see
PD2:<ADA.GENERAL>OVASRSUPP.DOC) for prices and further details.
.sp
.nf
3. Directory Listing:
Directory   PD2:<ADA.MASTER-INDEX>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  CH01.CH             74884    2232
  CH02.CH            133472    4092
  CH03.CH              4994     124
  CH04.CH             25058     744
  CH05.CH             15850     496
  CH06.CH             26836     744
  CH07.CH            389728   12152
  CH08.CH             14359     372
  CH09.CH              9330     248
  CH10.CH             13773     372
  CH11.CH             34834     992
  CH12.CH             22912     496
  CH13.CH              9982     248
  CH14.CH             90761    2108
  CH15.CH             42510     992
  CH16.CH             14668     372
  CH17.CH             15276     372
  CHA.CH             281790    7812
  CHB.CH               8215     248
  INDEX.CH            83145    1240
  TITLE.CH             2170     124
  TOC.CH              21615     744
  ===============  ========  ======
   22 Files         1336162   37324
.fi
.SUBSECT Incremental Upgrade from the July Master Index
.PP
For those of you who have a current (July 5) copy of the ASR Master
Index, it is not necessary for you to obtain all of the files of
the September 25 release in order to update your index.  Only those
files marked
with an asterisk (*) have been changed since the July 5 issue.
.sp
.nf
   PD2:<ADA.MASTER-INDEX>
		  Bytes(SZ)  

*CH01.CH.10       74884(7)   
*CH02.CH.10       133472(7)  
 CH03.CH.10       4994(7)    
 CH04.CH.10       25058(7)   
 CH05.CH.10       15850(7)   
 CH06.CH.10       26836(7)   
*CH07.CH.10       389728(7)  
 CH08.CH.10       14359(7)   
 CH09.CH.10       9330(7)    
 CH10.CH.10       13773(7)   
 CH11.CH.10       34834(7)   
 CH12.CH.10       22912(7)   
 CH13.CH.10       9982(7)    
*CH14.CH.10       90761(7)   
*CH15.CH.10       42510(7)   
 CH16.CH.10       14668(7)   
 CH17.CH.3        15276(7)   
 CHA.CH.10        281790(7)  
*CHB.CH.10        8215(7)    
*INDEX.CH.10      83145(7)   
*TITLE.CH.10      2170(7)    
*TOC.CH.10        21615(7)   

 Total of 532 pages in 22 files
.fi
.SUBSECT DRAFT CHOICE Object-Oriented Drawing Tool
.sp
.nf
1. Taxonomy:
PROGRAMMING TOOLS
CASE
DRAFT CHOICE

2. Author:
    TRIUS Inc.
.index TRIUS, Inc.
.index DRAFT CHOICE
.index drawing tool, DRAFT CHOICE
    231 Sutton Street, Suite 2D-3
    PO Box 249
    North Andover, MA  01845-1639
    508/794-9377

3. Abstract:
.fi
.PP
From the "DRAFT CHOICE" manual:
.PP
"DRAFT CHOICE is an impressively fast, object based graphics tool
which uses floating point mathematics to record the size, shape, and
position of objects you design.  An object is a basic element like a
line, circle, box, or more complex shapes like polygons (triangles,
pentagons, etc.) and Bezier curves.  By choosing a mixture of these
elements you can create amazingly detailed drawings, impressive
graphics, and conceptual schematics.
.PP
"DRAFT CHOICE contains functions that allow you to quickly correct
errors or modify a drawing either by acting on a single object or on a
group of objects at a time.  Modification options include moving,
copying, scaling, rotating, and many more."
.PP
DRAFT CHOICE also supports the creation of reusable libraries of
commonly-used symbols.  Symbol libraries are available in the ASR to
aid in the creation of Booch and Buhr diagrams, Data Flow Diagrams, and
Entity-Relationship Diagrams.  DRAFT CHOICE is SHAREWARE.
.sp
.nf
4. Directory Listing:
Directory   PD1:<MSDOS.CAD>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  DRAFTC.ARC         219739  Binary
  ===============  ========  ======
    1 Files          219739       0
.fi
.SUBSECT EasyCASE Drawing Tool
.sp
.nf
1. Taxonomy:
PROGRAMMING TOOLS
CASE
EASYCASE

2. Author:
    Evergreen CASE Tools
.index Evergreen CASE Tools
    11025 164th Avenue, NE
    Redmond, WA  98052
    206/881-5149

3. Abstract:
.fi
.PP
From the Introduction in the "EasyCASE Users Guide":
.PP
"EasyCASE is a limited function CASE (Computer Aided Software
.index EasyCASE
.index drawing tool, EasyCASE
Engineering) tool intended to simplify the generation (with a certain
amount of automation) of data flow diagrams (DFDs), transformation
graphs, state transition diagrams, structure charts, and entity-
relationship diagrams (ERDs).  EasyCASE produces these charts in
accordance with the Yourdon-DeMarco, Gane & Sarson, Ward-Mellor,
Hatley-Pirbhai (also known as the Boeing-Hatley method), Yourdon-
Constantine and Chen representations and methodologies for structured
analysis and design as published in their respective texts (see
bibliography section).  EasyCASE provides an easier to use, more
automated method of producing these diagrams than does a presentation
graphics or drawing program such as Lotus Freelance, Micrografx
Designer, Windows Draw or Gem Draw, etc., in that the drawing functions
it provides are only those required to provide the symbols,
connections, annotation and relationships required for the specific
chart types implemented.  EasyCASE is also easier to use than most of
the full-featured CASE tools in that is provides only the basic
functions (charts) necessary for performing and presenting structured
systems analysis and design.
.PP
"EasyCASE provides the capability to add the appropriate chart
type objects to the chart and then manipulate them.  EasyCASE maintains
certain information about each object and its relationships with other
objects on the chart.  Objects can be added, moved, deleted, labelled,
identified, and associated with other objects on the chart.  If an
object is modified in any way, any other similarly identified or
associated objects are modified also.  For example: (i) if a data
process symbol on a transformation graph is moved, any attached data
and/or control flows and their labels are moved also, remaining
connected to, and associated with, that symbol; (ii) if a function
symbol on a structure chart is deleted, any attached connections and
associated data or control flow arrows (couples) and their labels are
deleted also; (iii) if a previously defined object identifier is
reused, the new object will inherit its attributes (label)."
.PP
EasyCASE 1.53 is also reviewed in the September 1989 issue of
"Computer Language" magazine.  EasyCASE is SHAREWARE.
.sp
.nf
4. Directory Listing:
Directory   PD1:<MSDOS.CASE>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  EZCASE15.ARC       232695  Binary
  EZCDOC15.ARC        97464  Binary
  ===============  ========  ======
    2 Files          330159       0
.fi
.SUBSECT Validated Ada Compilers List - October 1989
.PP
This is the October 1989 list of validated Ada compilers.  There
.index AdaIC
.index Ada Information Clearinghouse
.index Ada compilers, validated
.index validated Ada compilers
are over 280 base and derived compilers.
.sp
.nf
1. Taxonomy:
ADA BOOKS AND DOCUMENTS
ADA COMPILERS, AVAILABLE

2. Abstract:
	Ada Compilers, Available

FORMAT KEY:
	1st Line - Ada Software Repository File Name
	2nd Line - AdaIC File Name
	Rest     - Description

COMPILERS.INF
VAL-COMP.HLP
	This file contains a list of currently validated Ada
compilers.

3. Directory Listing:
Directory   PD2:<ADA.POINTERS>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  COMPILERS.INF      151760    2749
  ===============  ========  ======
    1 Files          151760    2749
.fi
.SUBSECT Booch, Buhr, and Data Flow Diagrams - Symbol Libraries
.sp
.nf
1. Taxonomy:
PROGRAMMING TOOLS
CASE
DRAFT CHOICE

2. Author:
    TRIUS Inc.
.index TRIUS, Inc.
    231 Sutton Street, Suite 2D-3
    PO Box 249
    North Andover, MA  01845-1639
    508/794-9377

3. Abstract:
.fi
.PP
From the "DRAFT CHOICE" manual:
.PP
"DRAFT CHOICE is an impressively fast, object based graphics tool
.index DRAFT CHOICE
.index drawing tool, DRAFT CHOICE
which uses floating point mathematics to record the size, shape, and
position of objects you design.  An object is a basic element like a
line, circle, box, or more complex shapes like polygons (triangles,
pentagons, etc.) and Bezier curves.  By choosing a mixture of these
elements you can create amazingly detailed drawings, impressive
graphics, and conceptual schematics.
.PP
"DRAFT CHOICE contains functions that allow you to quickly correct
errors or modify a drawing either by acting on a single object or on a
group of objects at a time.  Modification options include moving,
copying, scaling, rotating, and many more."
.PP
DRAFT CHOICE also supports the creation of reusable libraries of
commonly-used symbols.  Symbol libraries are available in the ASR to
aid in the creation of Booch and Buhr diagrams, Data Flow Diagrams, and
Entity-Relationship Diagrams.  DRAFT CHOICE is SHAREWARE.  See the
file BBDSLIB.ARC for symbol libraries of Booch, Buhr, and Data Flow
Diagrams.
.sp
.nf
4. Directory Listing:
Directory   PD1:<MSDOS.CAD>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  DRAFTC.ARC         219739  Binary
  BBDSLIB.ARC         32304  Binary
  ===============  ========  ======
    2 Files          252043       0
.fi
.SUBSECT Booch Diagrams of Top Two Levels of PTF
.sp
.nf
1. Taxonomy:
TEXT MANIPULATION
WORD PROCESSORS
PORTABLE TEXT FORMATTER

2. Author:
    Richard Conn
.index Conn, Richard

3. Abstract:
.fi
.PP
The Portable Text Formatter (PTF) is a document formatting program,
.index Portable Text Formatter
.index PTF
.index Text Formatter, Portable
.index Formatter, Portable Text
written in Ada, which can execute on a variety of hardware platforms. 
PTF was designed to be as portable as possible, so it should run on any
platform supported by a validated Ada compiler.
.PP
PTF reads one or more source text files which contain both commands
to PTF and text lines, and PTF generates a formatted output file and
(optionally) a file containing index entries. Commands to PTF are
placed on lines whose first character is a dot (this may be changed if
desired), and text lines are those lines whose first character is not a
dot. Commands to PTF instruct it to perform certain operations on the
formatted output file, such as set left margin, underline the following
words, place an entry into the table of contents, place an entry into
the index, and define a macro.
.PP
PTF was designed to meet several objectives:
.PP
1. Generate DoD-STD-2167A documents.  PTF was designed specifically to
support the generation of DoD-STD-2167A documents, as detailed in the
.index DOD-STD-2167A
DoD-STD-2167A Data Item Descriptors (DIDs). To this end, PTF supports
multiple page heading lines, multiple page footer lines, page numbers
in a variety of formats (including Arabic and Roman numeral),
.index DIDs
generation of up to six distinct tables of contents (so that separate
tables for figures and diagrams may be created), and generation of an
index.
.PP
2. Support Ada software development.  PTF was written to provide a
mechanism to support other Ada software development tools, such as Ada
PDL (Program Design Language) processors. Output from these tools would
.index PDL
.index Program Design Language
.index MIL-HDBK-1804
be text files containing PTF commands. Specifically, support of such
tools to process PDL as defined in MIL-HDBK-1804 is anticipated.
.PP
3. Support team development of a document.  PTF also supports team
development of a document, where individuals can be given a common set
of macros and instructions on their use, and PTF can assemble a
document in a common format from many different source files which were
independently created.
.PP
4. Provide a documentation standard for the Ada Software Repository. 
Many of the reusable documents in the Ada Software Repository will be
revised so they may be processed by PTF, and many new documents will be
released in a form that may be processed by PTF.
.PP
5. Port without modification to computer systems for which validated
Ada compilers exist.  PTF is written in Ada and has been tested on a
VAX, Sun, and PC platform in an attempt to insure portability.
.PP
The PTF System consists of two programs: PTF and PTFIDX.  PTF is
the main word processor.  PTFIDX is a companion program to PTF which
processes its index pages.
.PP
The file PTF.VDD contains a listing of the distribution of PTF, an
installation manual, and other instructions which detail how to bring
PTF up on a particular target system.  The file CLI2.SRC in
PD2:<ADA.COMPONENTS> is needed to compile PTF and PTFIDX.
.PP
Booch diagrams of the top two levels of the PTF system are in
the file PTFDIAG.ARC.  See the VDD in this file for further details.
.sp
.nf
4. Directory Listing:
Directory   PD2:<ADA.WORD-PROCESSORS>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  PTF.PRO              5306     100
  PTF.SDD             50640    2109
  PTF.SUM            126215    3473
  PTF.VDD             32680    1241
  PTFBODY.SRC        164630    5951
  PTFDOCS.SRC        134171    4705
  PTFINDEX.SUM         8121     187
  PTFMAIN.SRC         32603    1250
  PTFREAD.ME            182       5
  PTFSPEC.SRC         87912    2861
  PTFTEST.SRC         33684    1422
  ===============  ========  ======
   11 Files          676144   23304

Directory   PD2:<ADA.COMPONENTS>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  CLI2.PRO             3345      63
  CLI2.SRC            41974    1144
  ===============  ========  ======
    2 Files           45319    1207

Directory   PD1:<MSDOS.TXTUTL>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  PTF.ARC            391897  Binary
  PTFDIAG.ARC         70195  Binary
  ===============  ========  ======
    2 Files          462092       0
.fi
.SUBSECT Analyst Tool Kit
.sp
.nf
1. Taxonomy:
PROGRAMMING TOOLS
CASE
ANALYST TOOL KIT

2. Author:
    Chinook Software Group
.index Chinook Software Group
    PO Box 24536
    Denver, CO  80224

3. Abstract:
.fi
.PP
From the Documentation:
.PP
"This tool suite enables a user to perform top-down system
.index Analyst Tool Kit
.index drawing tool, Analyst Tool
.index ATK
.index drawing tool, ATK
specification using the Structured Analysis Methodology (Data Flow
Diagrams).  Diagrams are entered and manipulated graphically, but
stored in textual form for easy access by other tools.  Support is
provided for data dictionary generation and analysis, as well for
analysis of the DFDs."
.PP 
Also:
.PP
"The Structured Analysis methodology allows a user to perform a
top-down specification of a system from a data viewpoint.  The
methodology is not limited to software development, but functions well
at the requirements and system design levels also.  The resulting set
of diagrams and the data dictionary augments any documentation effort,
and provides a concise, clear picture which may be dynamically
maintained along with the system it describes.
.PP
"The Analyst Tool Kit (ATK) is a collection of application software
designed to facilitate the development, analysis, and maintenance of a
set of DFD's (Data Flow Diagrams) and their associated data dictionary.
The SHAREWARE version consists of the following:
.PP
"1. A GRAPHIC EDITOR, called GED, which allows DFD's to be
interactively entered and manipulated on a CRT screen.  Unlike a
generic graphics package, GED is specifically designed to work with
standard DFD symbology and convention.  GED also produces an ASCII
format file as output, which can be read by standard text editors as
well as the other tools in the package.
.PP
"2. A DATA DICTIONARY builder, called DDBUILD, which can read the
output of the graphic editor and produce the skeleton Data Dictionary. 
The data dictionary is an ASCII format file which can be read by
standard text editors as well as the DFD EVALUATOR.
.PP
"3. A DATA DICTIONARY EVALUATOR, called DDEVAL, which reads the
completed data dictionary, parses it for errors, and produces a data
dictionary listing.
.PP
"4. A DATA FLOW DIAGRAM EVALUATOR, called ANAL, which reads the data
flow diagram files and the data dictioanry, and reports on conformance
to the Structured Analysis methodology guidelines.
.PP
"5. A REPORT GENERATOR, called RG, which formats the output of the
other tools.  It has knowledge of certain files produced by the tool
set, but may also be used as a general-purpose page formatter.
.PP
"Other tools are also included:
.PP
"1. A PostScript GENERATOR, called GEDPS, which converts DFD files
into PostScript representations suitable for sending to an Apple
LaserWriter or other PostScript printer.
.PP
"2. A DFD REUSE HELPER, called ATTACH, which attaches or stores
entire DFD subtrees for reuse on other designs.
.PP
"This version of Analyst Tool Kit was originally intended for
classroom use and provides an environment in which to study the
Structured Analysis method.  It was discovered, however, to be
practical for a range of small to medium size design efforts, and is
being offered as SHAREWARE at a price to suit a market neglected by
comparable products.
.PP
"The toolkit features:
.PP
"- 8 levels of decomposition below the context diagram
.PP
"- Data Dictionary evaluation limited only be available memory
.PP
"- flat ASCII data file formats easily accessible to other tools
.PP
"- PostScript output from DFDs, suitable for printing or incorporation
as EPS documents in publishing systems like Ventura Publisher
.PP
"- full function on vanilla PC hardware configurations, with no
mouse or expensive graphics cards."
.PP
This item in the ASR is SHAREWARE and is presented in executable
form only, suitable for running on IBM PCs which support at least 192K
of memory, a standard IBM color graphics adapter (or equivalent), DOS
version 2.0 or higher, and a printer capable of doing graphic output.
.sp
.nf
4. Directory Listing:
Directory   PD1:<MSDOS.FLOWCHART>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  ATKBASE.ARC        151765  Binary
  ATKDOC.ARC          24632  Binary
  ATKIBM.ARC          84730  Binary
  ATKREAD.ME           4969      97
  ATKSAMP1.ARC        13647  Binary
  ATKSAMP2.ARC         7093  Binary
  ATKZ100.ARC         46568  Binary
  ===============  ========  ======
    7 Files          333404      97
.fi
.SUBSECT Snapshot of the ASR for November 1989
.sp
.nf
1. Taxonomy:
ADA BOOKS AND DOCUMENTS
ASR SNAPSHOTS

2. Abstract:
.fi
.PP
These  files  contain snapshots of the Ada Software Repository (ASR).
.PP
The first four snapshots list each directory in the ASR and show  their
sizes.   The snapshots provide an overview of the ASR, provide a means
to quickly find out how much  is  available  in  the  various  subject
.index ASR Snapshot
areas, and allow the reader to follow the growth of the ASR during the
earlier days of the ASR.  These snapshot files are named SNAP01.DOC to
SNAP04.DOC.
.PP
The later snapshots show the total number of accesses and the total
number of files in the ASR along with a count of the total number of bytes
and lines in these files.  The later snapshots are generated automatically.
These snapshot files are named SNAPyymm.DOC for the year and month they
were taken.
.sp
.nf
3. Directory Listing:
Directory   PD2:<ADA.NEWS>
     File Name      Bytes    Lines 
  ---------------  --------  ------
  SNAP01.DOC           3754      80
  SNAP02.DOC          10523     315
  SNAP03.DOC          12600     330
  SNAP04.DOC          20620     855
  SNAP8810.DOC          250       9
  SNAP8812.DOC          249       9
  SNAP8902.DOC          251       9
  SNAP8903.DOC          246       9
  SNAP8904.DOC          245       9
  SNAP8905.DOC          245       9
  SNAP8906.DOC          246       9
  SNAP8907.DOC          244       9
  SNAP8908.DOC          247       9
  SNAP8909.DOC          252       9
  SNAP8910.DOC          251       9
  SNAP8911.DOC          250       9
  ===============  ========  ======
   16 Files           50473    1688
.fi
.bp
.SECT Calls for Papers, Press Releases, Announcements
.sp
.PP
This section of the newsletter contains calls for papers, press releases,
and other announcements.  These articles are submitted by mailing same to MACA.
All attempts are made to ensure that no modification to their
content is made during transcription to the newsletter.  Presentation of the
articles in this section does not constitute an endorsement in any way.
.SUBSECT Ada for POSIX from AETECH
.PP
The following is a press release received from AETECH.
.PP
SOLANA BEACH, CA -- October 19, 1989 -- AETECH successfully
completed validation testing for it's POSIX Ada Compiler during
extensive testing by the Department of Defense during September 1989.
This makes IntegrAda/POSIX the
.ul
first Ada Programming Support Environment for the POSIX compliant operating systems.
.PP
POSIX, an acronym for the Unix-based, multi-user, multi-processing
"Portable Operating System Interface for Computer Environments", is the
U.S. Government's new standard for operating systems.  POSIX is now
required for use by government agencies such as NASA, the Federal
Aviation Administration and the military services.  Ada is the DoD's
standard computer language, which was mandated in 1983 for all military
computer systems.
.PP
Ada and POSIX are the two cornerstones of the U.S. Government's
plan to save taxpayer dollars by establishing a single, high-order
standard computer language and multi-tasking operating system which works
on the thousands of different types of government computers.  Ada and
POSIX, with standardized coding, documentation, and maintenance features,
are expected to reduce software costs by standardizing programming
skills and tools.
.PP
"This validation is significant because it means the "IntegrAda/POSIX"
has satisfied the government's stringent requirements for Ada compatability
on fully compliant POSIX operating systems," said James T. Thomes,
president of AETECH.  "Unix has always been very popular throughout the
defense industry, but now that Ada and POSIX have been mandated,
IntegrAda/POSIX might well be the only Ada programming system which can
fully meet government requirements."
.PP
Thomes said the IntegrAda/POSIX programming system was validated in a
highly-productive "Turbo-like" programming environment, which allows up to
ten concurrent editing and compilations to be simultaneously controlled
by a single programmer.  It was tested on the latest POSIX compliant
versions of SCO and Interactive Unix operating systems using Zenith, IBM,
and Unisys 80386 based computers.
.PP
According to Thomes, Ada compilers for POSIX compliant operating systems
have been specified this year in government bids by the FAA, the
Army Small Multi-User Computer, and the DoD's Desktop III
micro-computer program which is reportedly worth $2 billion.  While other
companies have Ada compilers for Unix, Thomes reports that IntegrAda/POSIX
is one of the first validated for use on the new POSIX systems.
.PP
Last year, AETECH introduced the MS-DOS version of IntegrAda which is
written envirely in Ada, as the first integrated Ada programming
environment for the microcomputer.  IntegrAda is used throughout the
military and defense industry.  IntegrAda/POSIX is also an integrated
programming environment written entirely in Ada.
.PP
For further information contact:
.sp
.li +5
.nf
Jim Dorman
AETECH, Inc.
380 Stevens Ave, Suite 212
Solana Beach, California  92075
(619) 755-1277
.fi
.li -5
.sp
.bp
.sp 20
.ce
This Page Intentionally Blank
.bp 2
.pn lower_roman #
.fo //#//
.sp 4
.ce on
.ul
Table of Contents
.ce off
.sp 2
.pc
.bp
.sp 20
.ce
This Page Intentionally Blank

</PRE>
</BODY>