This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I feel all we need is use case diagrams, sequence diagrams, class diagrams and collaboration diagrams to go at a deliverable. We can always go onto delivery related UML diagrams at the end of the cycle. What you experts think?? Kishore.
Originally posted by Kishore Dandu: I feel all we need is use case diagrams, sequence diagrams, class diagrams and collaboration diagrams to go at a deliverable.
If you want to say that you need to produce all these before starting to code, I would say you might need much less.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 10, 2001
What I mean is those are all the diagrams/discussions about main parts of the system to realize a production worthy system. (assuming u have very good coders handy, if not it does not matter which way you go). Kishore.
How about non-functional requirements? like performance, and the illities like maintability .. how about other info like delivery date, and the technologies/methods/standards that must be follwed..where are u gonna put them, so one could "test" your system up against them?
I like to think a lot about packaging, too. And we are forced to diagram deployment - how many servers in how many sites, what kind of state synchronization or data replication, etc. You might enjoy Scott Ambler's Agilemodeling.com. He talks a lot about building only the models you really need, how to know what they are, good reasons for documentation and bad reasons. It all sounds related to your original questions.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 10, 2001
I see not much enthusiasm for deployment related diagrams. What many high profile clients do is, hire a full time/consultant who is good at figuring out merits of partitioning, clustering and network management and go that route than wasting time of so called deployment diagrams. I am not sure if there is a big practise to look into any performance related diagrams. But, I would consider them to be more looked upon when the actual implementation is 80% completed. Kishore.
Joined: Jul 11, 2001
Originally posted by Tonny Tssagovic: How about non-functional requirements? like performance, and the illities like maintability
Those need to be addressed, certainly. But do they need to be formally documented?
.. how about other info like delivery date,
A release plan, regularly updated, is important, I'd think. I very much like the XP approach for this.
the technologies/methods/standards that must be follwed
I don't think those need to be documented, but lived (and adopted) by the team. Your mileage may vary...