In a recent article at the CACM, Dobing and Parsons report on the analysis of a UML usage survey (182 respondents) . 171 responses came from UML users and 11 came from partial UML users.
Of the several findings of the article, I would like to stress the following ones:
1) Respondents, on average, have been involved in 27 projects, of which only 6.2 used UML.
2) Class Diagram (73%) is the most frequently used technical description, followed by Use Case Diagram and Sequence Diagram.
3) Use Cases Narratives (87%), Activity Diagrams (77%) and Use Case Diagrams (74%) are the preferred means with regard to client involvement.
4) Class Diagram (93%), Sequence Diagram (91%) and Statechart Diagram (82%) are the preferred means with regard to clarify technical understanding.
7) In asking the question, “reasons for not using some UML components”, some findings are intriguing:
a. 50% said that Class Diagrams were not well understood by analysts, 48% said that Activity Diagrams were not well understood by analysts.
b. 42% said that Statechart Diagrams were not useful for most projects.
c. 42% said that Use Case Diagrams have insufficient value to justify cost and that were not useful with programmers.
d. 49% said that Collaboration Diagrams would capture redundant information.
8) “The median “typical” UML project had a budget of around $1, 000,000 and 6.5 person-years and required 50,000 lines of code”
Some observations:
1) Although being the most used UML component, Class Diagram is also the top misunderstood component! If the data collection and treatment is trustful, then this looks like to be a major contradiction. How a team would claim to use UML, and as such be object-oriented, if their team members do not understand the Class Diagram?
2) Of respondents´previous projects, 27 (average), only 6, 2 (23%) used UML!
3) Use Case Narratives were preferred over Use Case Diagrams as a way to communicate with clients. This is a surprise, since common belief is that Use Case Diagrams, given its iconic character, is the most used medium by OO developers when dealing with clients.
4) The data collected by Dobing and Parsons shows a productivity of 7,692 lines of code per year. Above to the industry averages of 2001, according to Gartner ( as cited in the Msdn Blog by EldarM), which is of 6,200. This brings the productivity at the rate of 32 LOC per day per person (240 working days). Of course, it is widely known that LOC is not the best productivity measure, since different context yields different numbers.
5 comments:
Cool article, thanks for the link. So... given these results, we can assume other modeling languages are used even less. What does that imply for research into software or requirements modeling? Do we need to change our research focus to adoptable tools?
Very good post, Julio. Just a couple of points to your observations:
The class diagrams got 50% of analyst misunderstanding *from the 8 people that are not using them* --that is, four persons said that their analysts don't understand class diagrams. It's a very shaky statistic.
The 23% of UML use is spread over an average of a 15-year career; presumably people learnt to use UML relatively recently and then continued using it. However, participants were contacted through the OMG, so these are the people that are really, really involved with UML. I was expecting a higher usage rate among them.
Jorge,
Thanks for the comments. Yes, it is a surprise that those that came from the OMG referral had a low involvement with UML in the past.
jcl
Neil,
Thanks for the comments.
Well, I would put this way: modeling languages are not widely used.
However, there are other modeling languages that are being used, but I have not seen data from their use. For instance, IDEF0 or SADT is very much used in the DOD environment, but I do not known of numbers regarding their use. It is also true that ER diagrams are also very much used in the Data Base community.
If there is an impact with respect to research I believe it has to do with "easy of use" and "clarity" of the languages.
jcl
Fred Brooks covered this in The Mythical Man-Month. You don't need to use large diagrams for software projects and you really cannot because there are so many dimensions that you have to worry about.
Post a Comment