Re: Software Design Process
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.
>
>To make sure that your requirements are useful, get somebody else to
>inspect them and suggest improvements. In nearly every case, a second pair
>of eyes will find mistakes or improvements that you never would have found
>until too late.
>
>After you have your requirements documented, you really should prepare your
>test cases, but this is best left for an experienced tester. Developers are
>the worst testers of their own product. Its a huge psychological effort to
>actively try to find bad things about your 'baby'. A common statement from
>developers is "Oh come on! No-one would do that in normal usage!". BZZZTT -
>Wrong!
>
>Time to address System Architecture. Otherwise known as "how it all hangs
<snip>
>
>
|
Not Categorized, Please Help
|
|
