UML, RUP, MSF and the others versus reality

Mood: Monday was not as horrible as expected
Link: I am not the fan of the serie, but the sounds keep pinging my mind ;)

"We need simply to use UML and it will fix all the problems" - I was quite surprised to see the idea in MY mind and luckily not in my mouth yet ;) I am quite sure you know also the people, who believes that particular approach like Prince2 or RUP will be the remedy for any diseas. The problem is that effectiveness of these solutions always depend on particular situation. That is always the most important to diagnose the problem first and then to find the medicine in various books ;) Sounds like the cliché, but there is still so many werewolf hunters fully equipped with silver bullets. I have made conscience-searching and here we are...

General
· None of these specify necessity of designing GUI, but usually when you start drawing how particular screens will look like you may gain a lot of information (unless you plan the prototype first or strictly agile, iterative approach)
· None of these (but Prince2 books mention it unofficially) specify necessity of hard-numbered profit versus cost estimation. Business analysis should include some predictions of key indicators like Net Present Value or Internal Rate of Return
· QA is different topic, which you need to have in back of your head regardless from everything else (RUP and Prince2 mention it just)

· No one below will remind you about the law issues and regulations (legal acts, being compliant with standards, corporate regulations)

UML
· UML diagrams are really cool, but THAT IS NOT THE METHODOLOGY – that is simply some set of boxes, which you may use in drawings. Nothing more, nothing less.
· Very many companies uses UML to attach some images to documentation (good), but unfortunately not too many generates even the classes skeleton from it; even less keep synchronization between the physical and logical model. Surprisingly I have never heard or read about any CMMI-like model, which would suggest it or score it!
· When we speak about Use Case diagram remember about drawing the border of the system and if necessary about the version of the system (quite often technical spec says about the subset of functionalities enlisted in business spec)
· Use Cases are also about identifying the type of users

· Apply packages to simplify Use Cases

· Always look for reuse of diagrams and avoid copy&pasting (eg. <>, <> in use cases)

· Think about Deployment Diagram and general plan on early stage; it is also a good moment to think which OSes and browsers might be used by final users (it is often forgotten and it blows out when the deployment truely starts)

· Sometimes it is quicker to scetch, scan and paste even sligthly against the rules, that draw the diagram with 100k EUR worth software beign strict; pretty-good is usually enough ;)

· UML is one of the best for desiging software, but it is not the only one - have a look here.

RUP
· That is quite cool approach, which nicely show 4 important stages of the project – preparation, analysis, realization and deployment, but there is no point where all the analysis is finished. It means that even when you start the 3rd Construction phase you do not have all use cases finished (just 80% is required)!

· Against RUP I prefer rather to start coding when I have complete set of uses cases and the range of first release fully established - I found too often one, nasty case, which caused total redesign

· Surprisingly RUP does not go deep within technical aspects - it mentions mostly use cases, business aspects and risk management.

· Martin Fowler in his book The New methodology says something like: “My experiences with RUP are, that you can customize it without the boundaries and it causes problems. I have met couple of RUP usages, starting from the cascade model with analytical iterations, finishing at the full Agile process. I was surprised that this promoting RUP as one process caused that people may do everything and call it RUP – it makes RUP the word without meaning” - I guess this happens because IBM strategy is to allow in the same time the marriage of it with SCRUM and Prince2
· You can quicker find interesting documentation about RUP outside IBM (like Wikipedia) than inside, where you must go through tons of commercial crap to get kilo of knowledge. The kilo is probably somwhere within 270 pages long red book.

· Some sample documents templates

· RUP defines couples of disciplines - among others Business Modelling, Requirements, Analysis & design. In situation, when you need to make the interview with clients (in order to specify the contract), it means that each specialty must be represented at each meeting.

MSF
· Unfortunately since the new version (at least the document is ONLY 47 pages long ;) ), the split between logical and physical design is not bolded so strongly. You need to spend significant time to find the sentence like “There are three levels in the design process: conceptual design, logical design, and physical design”. I guess that is caused by the necessity of generalization caused by MSF for Agile.
· Good trade-off mechanism, which finally learned how to be agile, when customer wants something more :D
· User experience role, which you will not find in RUP.
· Practical bottom-up approach for estimation and no word about it in RUP

I was thinking for a sec to weight both RUP and MSF and put the score, but the truth is that the covarage which both companies for their development environment (IBM with Eclipse and Microsoft with VS.Net). There is couple of interesting places, where you can find deeper comparsion of both like even some Master Tesis prefering slightly RUP. At the end of the road, it does not matter what label you wear, but how you feel with it. Is it flexible? Can you show in the suite on the business meeting? Can you run to catch the cab? Do you buy clothes in regular market or you can afford the tailor? Do not you think you need to have couple of clothes? :D