OpenEuphoria

Re: Software Design Process

• Posted by rml at rubis.trix.net Jun 12, 2003
• 384 views

Derek and "Mr Trick" ;


         This text could be part of the Euphoria manual! :>)

         Things like this make this list very useful.

Good question, excellent answer.

Rubens

At 04:40 12/6/2003, you wrote:
>
>Thank you VERY much. :o)
>
>As for a second pair of eyes, I think I've just found a job for my 
>not-too-technical friend who's been bugging me about finishing this project!
>=====================================================
>.______<-------------------\__
>/ _____<--------------------__|===
>||_    <-------------------/
>\__| Mr Trick
>
>
>>From: Derek Parnell <ddparnell at bigpond.com>
>>Reply-To: EUforum at topica.com
>>To: EUforum <EUforum at topica.com>
>>Subject: Re: Software Design Process
>>Date: Thu, 12 Jun 2003 17:26:37 +1000
>>
>>
>>On Thu, 12 Jun 2003 14:08:42 +1000, <mistertrik at hotmail.com> wrote:
>>
>>>
>>>I have been working on a fairly large software project, with database 
>>>and display components, and the all-important user interface. Now my 
>>>coding method is ad hoc at best, and I haven't used any particular 
>>>system of design or coding.
>>>
>>>I managed to get the display component of this system fairly complete, 
>>>and some of the user interface directly related to the display 
>>>component, but when I started coding database and more advanced user 
>>>interface stuff - in my ad hoc way - it all just ground to a halt.
>>>
>>>Now, I can see how it might benifit having some kind of perfunctory 
>>>overall design and process to follow. Can anyone suggest ideas or 
>>>resources for how I might go about doing this? This is a one-man 
>>>project, so I don't imagine I would need something as complicated as 
>>>ISO/IEC 12207 compliance...
>>>
>>>To the Euphoria heavyweights, how do you guys plan your projects?
>>
>>Firstly, how much I weigh is not for public information.
>>
>>Secondly, "ouch!" - I feel your pain.
>>
>>There is no easy way out - you have to work at it. Unless your system can 
>>be totally specified on a single piece of A4 paper and be understood by a 
>>8th grader, you should stop now, and put things into order.
>>
>>On the assumption you don't want to work on the same system forever 
>>before its released, you need to know when to stop working on it. The 
>>easiest way is to write a list the things that the system MUST be able to 
>>do. Then stop working when the system can do all of them.
>>
>>This is the Requirements List. Most likely, a simple list will not 
>>adequetely express, in an unambiguous manner, the full requirements. So, 
>>for each item in your WRITTEN DOWN list (yes, writing it down is 
>>important) you ought to add enough detail so that, hyperthetically, 
>>somebody else could write your system for you. This is a balancing act, 
>>for sure. It is easy to write too little detail as it is to write too 
>>much. Remember to describe WHAT the system should deliver rather than HOW 
>>it should deliver it.
>>
>>One useful technique for the UI aspect of your system, is to write down 
>>the 'use cases'. That is, how a person will actually use the system to do 
>>each single, very specific, thing. These are usually written as a set of 
>>actor- action-effect statements. For example, if I'm describing how to 
>>use IE to view a web page.
>>
>>  Actor         Action                    Effect
>>
>>Often you will have a pre-requirement specified too. In this example, 
>>that might be that IE has been started running (this might be a link to 
>>another use-case).
>>
>>A use-case will always have the primary process flow. It may also have 
>>many alternate flows that are there to deal with exceptional 
>>circumstances. In the example above, you might also have ...
>>
>>Exception after (4): Error message 'page not found'.
>>5. User         Check the spelling of the URL and correct if needed.
>>
>>
>>When you have use-cases documented, testing the system becomes real easy. 
>>Just follow the use-cases. Any unexpected effects might be bugs or 
>>missing use-case material.
>>
>>
>>Don't build any production quality code until you have the requirements 
>>specified. However, one of the better ways of understanding what the 
>>requirements are is to build prototypes. Demo programs, or sample 
>>programs, that help you play with your ideas until you fully understand 
>>what you (or your clients) want. Never convert a prototype into a 
>>production system. Always start a production system from a clean slate. 
>>The prototype is a learning method where mistakes and dead-ends are 
>>expected. You are allowed to
>>compromise quality in protypes. However, these don't convert well into 
>>production code.
>>
<snip>

>
>