Usually I'll detail the various sections that go together in a rough way (say a text editor might have a file access segment, a buffer segment and an interface segment) and list the relations between them (e.g. one file access service and one user interface can service many text buffers) and finally the information transfers between them (e.g. the UI sends a command to the buffer, the buffer sends a text stream and a filename to the file access service for saving, the UI switches between buffers, etc).
I avoid going into absurd detail, I find great use for high level modelling but find low level modelling just slows me down. So I have little use for flowcharts and such other than as very quick sketches. Most of UML falls into this bracket IMHO.
Other than this I tend to use test driven development because it leaves your code with very loose coupling which in turn makes refactoring and even scope changes as simple as it can possible be (it also leaves you with a solid regression testing suite). Also it's nice knowing that at any time during development the maximum time your code didn't work (as defined by your test suite) is 5 minutes. Naturally if your test suite sucks this doesn't mean much.
//edit - the most important thing for any process is to identify what you need, break it down into manageable sections and then set some sort of system to measure progress. Usually the first part (identifying what you need) is impossible to get right first time and it's important that any good design is capable of the inevitable scope changes at low cost.
I'd be careful about any system that puts too much faith in requirements gathering, any system that assumes you can know exactly what you want is absolutely doomed to failure.//
__________________
Code:
glBegin(GL_TRIANGLES);
drawWorld();
glEnd();
Last edited by G_Morgan; 01-07-2008 at 11:34 AM.
|
01-07-2008, 11:29 AM
Linear Mode
Similar Threads
