AmbySoft.com

Ambysoft Logo

Modeling and Documentation: 2013 Open Research


This open research into modeling and documentation practices in IT was performed during the fourth week of October 2013 and there was 162 respondents. The survey was announced via a link to the survey was posted on my IT Surveys home page at Ambysoft.com/surveys/, announced on my Twitter feed, my mailing list (ambysoft@yahoogroups.com), the IIBA, Considerate Enterprise Architecture, Project/BA World, and Disciplined Agile Delivery (DAD) discussion groups on LinkedIn.

The Survey Results

The survey results are summarized in my DDJ article entitled UML 2.5: Do you even care? The survey had two goals: First, to explore what IT professionals think about common modeling notations such as Unified Modeling Language (UML) and Business Process Model and Notation (BPMN) and second to see how these notations are being used.

Some findings include:

  • See Figure 1 for what people think of UML. It’s interesting to note that every respondent had heard of UML.
  • See Figure 2 for what people think of BPMN. It’s interesting to note that one quarter hadn’t even heard of BPMN, and of the people in modeling-oriented roles that 17% hadn’t heard of it.
  • See Figure 3 for UML/BPMN usage on IT projects. These results reflect that 58 of the 162 respondents didn’t even indicate that they’d looked at or used a single UML/BPMN diagram within the last month. Implication is that although people have heard of UML, and to a lesser extent BPMN, that they’re not using it as much as we may be led to believe.

 

Figure 1. What people think of UML.

 

Figure 2. What people think of BPMN.

 

 

Figure 3. UML/BPMN usage in general.

 

 

 

Downloads

The Survey Questions

Raw Data

Summary Presentation

 

What You May Do With This Information

You may use this data as you see fit, but may not sell it in whole or in part. You may publish summaries of the findings, but if you do so you must reference the survey accordingly (include the name and the URL to this page). Feel free to contact me with questions.Better yet, if you publish, please let me know so I can link to your work.

 

Discussion of the Results

  1. I forgot to ask about use case diagram usage in question #3. I suspect this diagram is used fairly regularly, perhaps at a similar level as class diagrams, but can’t say for sure.
  2. It’s hard to say what the usage rates of a given diagram is based on the paradigm that the team is following for two reasons. First, the usage question was too general (I didn’t ask the person to answer from a specific paradigm in question #3) and the sample size is too small anyway.
  3. People didn’t know the purpose of the survey, so that likely removed some bias. My strategy for the SA+A surveys is to send out a short survey every two months but to not indicate what the topic of the survey actually is (other than an IT topic of course).
  4. I purposely kept this survey short. The longer a survey is the greater the drop out rate. As a result I didn’t ask questions this time around tool usage, nor did I ask anything about the production of deliverable documentation such as user manuals or operations guides.
  5. This survey suffers from the fundamental challenges faced by all surveys.

 

Links to Other Articles/Surveys

  1. My other surveys

 

Why Share This Much Information?

I’m sharing the results, and in particular the source data, of my surveys for several reasons:

  1. Other people can do a much better job of analysis than I can. If they publish online, I am more than happy to include links to their articles/papers.
  2. Once I’ve published my column summarizing the data in DDJ, I really don’t have any reason not to share the information.
  3. Too many traditionalists out there like to use the “where’s the proof” question as an excuse not to adopt agile techniques. By providing some evidence that a wide range of organizations seem to be adopting these techniques maybe we can get them to rethink things a bit.
  4. I think that it’s a good thing to do and I invite others to do the same.