Xp Schedule Faq

From XpFaq

How much faster will a UML Phase make us?

pandith@my-deja.com wrote:

 > I have the requirements for a project and have to design the system.
 >
 > Once we got the requirements, we did the use cases and use case
 > diagrams. What is the logical and easiest way to arrive at the low
 > level design?
 >
 > Should we do activity diagram or Component diagram and Sequence diagram
 > to end up with the Class Diagram?

Easy. Take the most important feature, and type in a snip of code that will test the feature exists. (TestDrivenDesign.)

Then type in the feature. Forget, at this point, any concept of Design, or of drawing pictures of your design. Forget every feature you know the program eventually must support except the one single feature you are typing in. Sounds easy, huh? (YouArentGonnaNeedIt.)

When you go to the next feature, add a test for it, then add the feature. Repeat. (ContinuousIntegration.)

As you do this, the code will get ... ugly. Detect ugliness by looking for places where the code violates the "OnceAndOnlyOnce" rule. This means you don't have the right kinds of abstractions. At this point, change the code so it fixes the OAOO problem. As you do this you'l probably put in some structure (AdapterPattern, etc.).

Chart your program's structure, as it emerges from the feature list, using the UML you are learning. This means your UML is now proofed and known to work. Easy, huh? (Reversed WaterFall.)

As you refactor code, the test you wrote (before _each_ feature) will protect that feature. Without this simple safety net, you will eventually generate code that can't be changed at all, and your project will die. (KentBeck.)

If you "train" your team, code and UnifiedModelingLanguage diagrams to always incrementally make the code better over time, it can live for ever. Easy.

> BTW the project has a tight schedule.

The system I listed preserves each feature as you add it. Therefore you know the general rate at which the team adds features. This lets you know when the project will end. (PlanningGame.)

You are trying to do all the UML up front, in a batch. _Nobody_ does it like that, but the UML books often overlook this point. Big batches like this will damage your schedule by obscuring the actual rate at which real features can be added. Lots of UnitTests to lock down functionality are more important, and easier. They will eventually support good design, which then deserves to be drawn up in UML diagrams.

--PhlIp