🚀 go-pugleaf

As I have already stated, I believe the purpose of the (highest) specification
should be to describe the requirements of the system as clearly and succintly
as possible. For the most part this aim is well served by concentrating
on what must be done rather than how is should be done. The
details of algorithms are usually complex and more difficult to
understand than a simple statement of the aim of the algorithm. Moreover
the less said at first about how, the greater the freedom of choice is
at subsequent stages of development. However it should always be
remembered that the primary aim is clarity and that a theological
pursuit of abstractness will often run contrary to this aim. Thus it is
often productive to use off-the-shelf data structures such as queues and
stacks in the initial specification. Even if they must later be
eliminated from the design they will improve understandability.

I feel I must question Cybulski's advocacy of early emphasis of
procedural aspects. This faces the danger of obscuring the purpose of
the system under construction. Further he attempts to support his case
by claiming that greater flexibility may be gained by early
considerations of procedural aspects. I find this proposition extremely
doubtful. It is fairly clear the later introduction of procedural
concerns aids flexibility rather than the contrary. In particular it may
allow a cheaper non-computerised solution to be found.

jacob@latcs1.oz.au (Jacob L. Cybulski) writes:

>Let me give you a nice texbook example, ref. Barbee Teasley Mynatt "Software
>Engineering with Student Project Guidance," Prentice-Hall Int. The book
>introduces the problem of estimating and projecting ticket sales revenues
>from art performances. The author adopts Yourdon and DeMarco methodology,
>and introduces a series of neat developments steps leading from REQUIREMENT,
>and SPECIFICATION through DESIGN to the IMPLEMENTATION and TESTING.
>Somewhere between the design and implementation there is a SELECTION of the
>programming language, i.e. Pascal. An interesting thing about this
>particular example is that if a decision were made to implement the program
>in a spreadsheet, then about 90% of the development effort could have been
>avoided, i.e. detailed specs, flows, data dictionaries, then algorithm
>elaborations, etc. To make it worse the technical requirements for the
>project would allow the spreadsheet-based system to provide the correct
>time-space efficiency. I do not deny the value of the text but I think that
>this strong separation of WHATs and HOWs at the early stage of software
>development was actually to the detriment of entire project.

I think you should ponder this example more. First the criteria Cybulski
uses to determine that a spreadsheet would offer a better solution are
themselves non-procedural. He seems to feel that the early emphasis on
on what has lead inexorably to the use of a low level language, Pascal.
In fact it is more likely the decision to use a standard procedural
language was made much earlier than the particular selection of Pascal.
Possibly this decision was made too early, thus leading to all the
wasted work on data dictionaries etc. It seems very likely the entire
methodology is predicated on the decision that languages such as Pascal
would be used in the coding phase.

Of course it may be the case that a simple ledger, a pen and a calculator
would provide the best price to performance ratio :-).

--
Brendan Mahony                   | brendan@batserver.cs.uq.oz       
Department of Computer Science   | heretic: someone who disgrees with you
University of Queensland         | about something neither of you knows
Australia                        | anything about.