Help With Program Design! 2

[sparky777]

Hi, this is a fairly dim question, but i am starting to work on my program design.

Program spec is complete with the relevant information including, layouts of windows to be used, input, output etc.

My program design covers the following:

The resources needed (hardware and software)

Modularity (its a fairly large program so will be broken down into smaller manageable pieces).

Processing (i have included objects and their properties at this stage in a table form for each form that is to be used)

The question that i need answering is do i have to set constants and variables at this stage, or will that stage be in the program development)

and program loops etc..

please if you can help.

thanks

pete.

 

[robinmiller]

For a technical design document you should clearly specify all variables modules etc at design stage.
If not specified already you will fall into the trap of adding bits and pieces as you program. Which in turn means you have not clearly though out your design specification.

If you used a design tool for OO such as Rational Rose, you specify these as you create and define the UML documentation.

 

[MichaelRed]

pete,

most development in todays world follows the "RAD" approach and probably has far less design information than you indicate you have developed. In the RAD approach, deffinition of constants and variables is generally done "on the fly" (e.g. during the programming, and even then, only when the need is 'discovered'.

In the FORMAL approach to development, all constants and variables are defined prior to and 'codeing' and the discovery of additional needs is considered a design flaw. Again, in the FORMAL approach, requirements for additional variable or canstants by programmers/coders is refered back to a DESIGN group/individual.

I expect you will get MANY more opinions on the merits of hte approaches than any other topic you could possibly select to post ion a public forum, so I'm sure that my 'humble opinion' will surely be lost in the malestrom which will follow, but - for waht it is worth:

Absoloutly define the convention for the use of both constants and variables. Set down the decision process for making a GLOBAL / MODULE / PROCEDURE level variable. Assign as many as you can before programming. Use some of these as the examples for those who will follow (doing programming/codeing/maintenance). Make rules for the naming convention of constants and variables. Include sufficient 'rules' to be able to tell from the name wheather you are looking at a LOCAL / Module / GLOBAL object, wheather it is a constant, variable, procedure, form, report ... or other object. Set up more rules so that everyone working on the project can know what level (local, module, global) of object they have the 'right' to create. Hope that you can get cooperation on the above. Hire a "COP" to review the project on a regular (continuious) basis to see that the 'rules' are being followed. Hope for the best. Expect something less. Accept something between expectation and hope.



MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over

 

[chiph]

sparky777 -

What MichaelRed has to say is very true. You need to set down some coding rules. And you need to have code reviews to enforce them. Politically, it might be better to hire an outsider (consultant) to do this (give them a copy of the standards ahead of time, plus the material to be reviewed). That way no one from your company has to play the bad guy.

Most of the decisions about where to keep constants, etc. is just housekeeping. You don't want to have one .bas module with everything lumped into it -- It gets too hard to read, plus there's too much contention when two people need to check it out of your source-code control system at the same time.

I'd have a couple of .bas modules which are used project-wide, and then each module within the project (each .dll, really) can have it's own shared .bas module or two. You want to watch your naming standards on this, too. You don't want two projects that have .bas modules of the same name - it gets confusing.

Other than that, organization is the key.

Chip H.