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

Discussion in 'Java' started by tenxian, Apr 26, 2008.

  1. tenxian

    tenxian Guest

    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?
     
    tenxian, Apr 26, 2008
    #1
    1. Advertising

  2. tenxian

    Arne Vajhøj Guest

    Re: How to design proper classes when the requirements are quitecomplex?

    tenxian wrote:
    > 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
     
    Arne Vajhøj, Apr 26, 2008
    #2
    1. Advertising

  3. tenxian

    Mark Space Guest

    Re: How to design proper classes when the requirements are quitecomplex?

    tenxian wrote:
    > 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>
     
    Mark Space, Apr 26, 2008
    #3
  4. Re: How to design proper classes when the requirements are quitecomplex?

    Lew wrote:
    > Mark Space wrote:
    >> Two years is not that long for a new software project.

    >
    > 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
     
    Arne Vajhøj, Apr 27, 2008
    #4
  5. Re: How to design proper classes when the requirements are quitecomplex?

    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.
     
    Chase Preuninger, Apr 27, 2008
    #5
  6. tenxian

    Mark Space Guest

    Re: How to design proper classes when the requirements are quitecomplex?

    Lew wrote:
    > Arne Vajhøj wrote:
    >> Lew wrote:
    >>> Mark Space wrote:
    >>>> Two years is not that long for a new software project.
    >>>
    >>> 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.

    >
    > 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.
     
    Mark Space, Apr 27, 2008
    #6
  7. Re: How to design proper classes when the requirements are quitecomplex?

    Lew wrote:
    > Arne Vajhøj wrote:
    >> Lew wrote:
    >>> Mark Space wrote:
    >>>> Two years is not that long for a new software project.
    >>>
    >>> 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.

    >
    > 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
     
    Arne Vajhøj, Apr 27, 2008
    #7
  8. tenxian

    Mark Space Guest

    Re: How to design proper classes when the requirements are quitecomplex?

    Lew wrote:

    > 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.)
     
    Mark Space, Apr 28, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. news.amnet.net.au
    Replies:
    1
    Views:
    579
    =?UTF-8?b?TMSByrtpZSBUZWNoaWU=?=
    Apr 13, 2004
  2. Stanimir Stamenkov
    Replies:
    2
    Views:
    748
    Stanimir Stamenkov
    Oct 25, 2005
  3. Kevin Goodsell

    Requirements for exception classes

    Kevin Goodsell, Sep 22, 2003, in forum: C++
    Replies:
    9
    Views:
    416
    Gianni Mariani
    Sep 23, 2003
  4. Robert Mark Bram
    Replies:
    0
    Views:
    685
    Robert Mark Bram
    Feb 4, 2007
  5. Kottiyath

    How complex is complex?

    Kottiyath, Mar 18, 2009, in forum: Python
    Replies:
    22
    Views:
    766
Loading...

Share This Page