How to design proper classes when the requirements are quite complex?

[tenxian]

Sometimes I feel it is difficult to deal with complex requirements
with an object-oriented approach.Can any experienced Java programmer
give me any advice?

 

[Arne Vajhøj]

Sometimes I feel it is difficult to deal with complex requirements
with an object-oriented approach.Can any experienced Java programmer
give me any advice?

Experience !

Arne

 

[Mark Space]

Sometimes I feel it is difficult to deal with complex requirements
with an object-oriented approach.Can any experienced Java programmer
give me any advice?

Yes, hire an experienced designer.

You can look on the internet for "Best Practice" for ideas how to proceed.

<http://en.wikipedia.org/wiki/Best_practice>

Looking myself, I'm reminded that you probably don't want object
oriented design, what you want is project management. Hire a manager
with experience in software.

Here's a couple of thoughts if you're totally stuck:

"Build one to throw away." If you don't understand your requirements,
on thing you can do is build a prototype. This will help you understand
what the requirements really are. Once this is accomplished, you'll
have a better idea what the real requirements will be.

<http://en.wikipedia.org/wiki/Project_management>

Make sure you have plenty of time, and plenty of money. Don't spend
money too fast. Software is very labor intensive, don't try to force
short deadlines. Better to cut features. Two years is not that long
for a new software project. Make sure you can fund it the whole time.

Finally, read this:

<http://en.wikipedia.org/wiki/The_Mythical_Man-Month>

 

[Arne Vajhøj]

But it is way, way, waaaaaaay too long to wait for such a project to
produce any useful product.

If you are managing a software project, set it up so that first useful
product results start happening in about a week. A month is not too
soon to have a prototype of important basic features.

When the actual development start something should be delivered
frequently. Every 2 month or every 2 weeks or whatever (every week
sound as XXP though).

But the project start long time before that. It is not unusual
to spend 6 months on requirements.

Arne

 

[Chase Preuninger]

Sometimes it makes sense to use a number of classes instead of just
one. Also just think of what data the class needs to hold and what it
needs to do with that data.

 

[Mark Space]

Even requirements should work with prototypes iteratively.

Don't wait six months to put something on the screen. You might find
that it doesn't look or work the same on a computer as it did on paper.

For this to work, management must tolerate wholesale tossing out of
prototypes and complete rewrites in the coding phase, at least sometimes
and at least at first.

I was thinking the same as Arne. 6 months requirements + startup, 18
month development cycle.

Considering your line of work, your advocacy of prototyping and
iterative development is interesting. (You're a consultant, correct?) I
would consider such things wasteful on a large project (or even a small
one) but I suppose it might be needed to keep a client, sponsors (money
folks) and management happy.

"Two weeks" is a known fallacy for time estimates in project management,
but laymen might not understand that. It might be good to play to that
two week event horizon.

 

[Arne Vajhøj]

Even requirements should work with prototypes iteratively.

Don't wait six months to put something on the screen. You might find
that it doesn't look or work the same on a computer as it did on paper.

Prototyping brings you into the "how" instead of entirely focusing
on the "what".

For this to work, management must tolerate wholesale tossing out of
prototypes and complete rewrites in the coding phase, at least sometimes
and at least at first.

If the project process is sufficient flexible then many things are
possible.

But if requirements are signed by vendor and customer and getting
it changed is like negotiating peace in the middle east, then you
do not want some quick prototyping stuff to be carved in stone
in the signed requirements.

Arne

 

[Mark Space]

At all times, we had a document person keep the user manual up to date
with screenshots, and proposed functional requirements for the interface
and its underlying logic. Over three months the changes from one
...
day. The finished product was done in about six months, and was
virtually bug free. The major consulting firm to whom I was contracted
got much praise for the result from their large-scale client.

Very interesting... I'm curious. Was that 6 months total, or 3 months +
6 months.

Here's why I'm curious. I'm re-reading Brooks after advising tenxian he
should do so. Fred Brooks writes:

"For some years I have been successfully using the following rule of
thumb for scheduling a software task:

" 1/3 planning
" 1/6 coding
" 1/4 component test and [...]
" 1/4 system test..."

So if your projects was 3+6 months, you nailed Fred Brooks' rule of
thumb. If not, I'm wondering where automatic code generation improved
things and which phases.

(Probably at least half the coding and half the unit test ("component
test") was done during the design as part of automatic code generation,
would be my guess.)