|
|
Posted by Jerry Stuckle on 11/16/10 11:30
Jacob Atzen wrote:
> On 2005-10-27, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>>I learned about project management when I was working for IBM back in
>>the 80's. Since then I've been both a programmer and a PM. When I've
>>been a PM, the documentation is complete long before programming starts
>>(and yes, I get the programmers involved in the design). And I've been
>>a programmer on projects where the design is done properly. Every one
>>was completed on time and within budget, given reasonable time and
>>budgetary constraints. And change orders were handled by modifying the
>>design - which showed exactly how it would affect other parts of the
>>project.
>
>
> That sounds impressive and quite contrary to most testimonials I've ever
> read. And quite opposite of the whole agile movement. How are you able
> to design everything up front? What methods do you use? I find it very
> hard to contain a complete design and anticipating all the problems that
> always show up?
>
Practice, Practice, Practice.
Just like you do when you're programming. Start with large blocks.
Break each large block down into smaller blocks. Keep going until you
have real little blocks :-).
Seriously - it is an art, and takes a lot of experience to do it well.
I can't say I'm great at it - there are much better designers out there
than I am. But I get along OK.
But you do take the project and break it up into functional parts.
Figure out what each part has to do (functionality) and what it needs to
do its job (interaction).
You won't go through it once and get everything exactly right. It's a
repetitive effort - you'll miss things the first time around and have to
add them the second time around. Keep going until you're fairly
comfortable with the design.
Even after programming starts you'll find problems in the design you
didn't see before - and/or the customer will change the requirements.
The advantage here is - when this happens, you can determine what you
need to change - and know EXACTLY what that will affect. Additionally,
you can estimate how much it will affect your project schedule - for
instance, a change to code that hasn't been written yet will probably
have a minor affect on the schedule. But if it requires major changes
to large parts of the code (less likely with good a good OO design), you
can estimate how much more time it will add to the project.
I find it easier to do with OO programming; there is less interaction
between objects than in functional programming. The isolation makes
things much easier.
Normally I start with the user interface and work back from there. If
it must interact with an existing database, of course I need to take
that into consideration. Otherwise the database is one of the last
things defined. Other people do it differently.
But it does take practice! And the more you do it, the better you'll be
at it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|