Re: Software Design Process
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.
---------------------------------
Welcome to System Development 101.
---------------------------------
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
-------------------------------------------------------------------
1. User Click in Address Bar Cursor moves to Address Bar
2. User Type in URL The URL is displayed in AddrBar
3. User Press the [Enter] key. The 'world' icon starts moving
4. System Locates the web page The web page is displayed.
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
together". Write down, usually with plenty of diagrams, the conceptual
components of your system. Especially note what information the components
need from each other. Mark in any 'external' components too. The reason for
doing this is two-fold. One is to test out your concepts about what the
system is trying to achieve and how you can get to happen. And the second
is to have a sort of blueprint that you can continually comeback to to see
if you are on track.
Generally speaking, you should be developing N-Tiers applications. By this
I mean that your database and/or file-access components should be
independant from your 'business' logic, which should be independant from
your User Presentation code. Theoretically, you should be able to replace
any of these tiers (layers) without having to change a single line of code
in any of the other layers. For example, you may write your system using
the EDB, but later you replace this with MySQL. If you do this, you really
shouldn't have to change the code that displays stuff to the user, or the
code that processes the data. To achieve this level of N-Tier-ness you have
to give considerable thought about how to separate the functions of your
code and how to pass data between them. There is no one answer to that - it
all depends on your architecture and other constraints.
Next, make some design notes. Write down HOW you are going to meet the
requirements. This is a form of technical specification. This stuff is
invaluable when it comes to maintenance time. It doesn't take long before a
developer comes back to their own code and wonders "what the **** is this
section of code trying to do?" A good place to put this documentation is in
the code itself, especially if you can use some tool to extract it into a
transportable format.
Finally, you get to write some code. By now, you know the system inside out
and code-writing is the easy part - almost tedious. If so, that's a good
sign. It means that most of the mistakes have already been made and
corrected.
For each of the 'deliverables' of your system - the requirements,
architecture, design, and code - it ALWAYS pays to have somebody else
inspect them before getting too deeply into the next stage. Finding
mistakes as early as possible, is a good rule.
I know I've made this sound like it takes a lot of paperwork and time
before you can see anything for your efforts, but no-one says you have to
do each stage in its entirety before progressing to the next stage. If you
like, you can take 'baby steps'. For example, create a requirements spec
that only has a broad target, then go through the stages to implement that.
This might all be done in a single day. Then go back and expand on the
requirements, and repeat in this incremental way. Some people find that
doing development like this is fun because you get to have a lot of variety
and get results often. It is also easy to change direction because you can
detect possible direction changes faster and have smaller amounts to
rework.
Of course, overall you really should prepare a plan - one with specific
tasks and timelines in them. You can use this to keep spurring yourself to
action. They can also (and should also) be updated daily based on what you
have learned during the previous day. Add tasks, revise expectation, or
whatever so that the plan always reflects your best guess as to what is
happening with your project. An important thing to remember with project
plans is that they are trends and not destiny.
I guess that's enough for now 
--
cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
