Like Moliere's Monsieur Jourdain, who spoke prose all his life without knowing it, Hugos may be surprised to discover that four of his five diagram types are either valid UML diagrams or can be mapped directly to corresponding UML diagrams, with one important difference: UML diagrams are composed of elements that have a standard semantics associated with them."Five Diagrams Beat a Victorian Novel" is a catchy title and we can all relate to a good diagram being easier to absorb than thousands of words. We should encourage meaningful illustratons but there are many parts of our templates that are not amenable to the simple diagram. We need to talk about objectives, risks, non-functional requirements, costs etc. – these are easier to express in words.
Hugos is advocating a warterfall development methodology and not advocating anything new with his 5 diagrams.
The first diagram is a data flow diagram which was developed by Edward Yourdon and then improved by Gane & Sarson in the 1980s. Gane & Sarson added sources and sinks which evolved to be the actors in use-case diagrams and swim-lanes in swim-lane diagrams. The swim-lane diagram is a special case of the UML Activity Diagram. I prefer to see the swim-lane diagrams to the old Yourdon data flow diagram. The old DFDs certainly still have value but I believe the new diagrams are more expressive and better accepted.
The logical data model is good sense and developers have been using these for years. I would hope that any serious business analysis involved a logical data model and that this was based on an enterprise information model.
Hugos writes about a "System Technical Architecture" which is similar to a UML Deployment Diagram. This is not usually the role of the BA and sometimes not even the role of the software developer. The systems architect will often be responsible for what part of the application runs on what hardware and therefore this deployment diagram.
Hugos write about an Object Model which is the equivalent of a UML Class Diagram. It is the role of the programmer or systems analyst to develop these. Again I have no problem with this diagram being included in a solution design.
Storyboarding is a technique that has been around for a while and has been adopted by the XP (extreme programming) agile programming technique. Use cases attempt to portray the same information.
The use of screen mock-ups helps show the user some tangible picture of what the application might look like and is an alternative to prototyping the user interface. There is a good IBM article on this.
There is little question that use cases have a bigger impact on software engineering than storyboards. Use cases are the origin and basis for a well-defined object model that not only manages the functionality and business rules of a system, but also serves more than one HCI [Human Computer Interface]The Business Analyst(BA) develops requirements for two audiences. It is the BA's call whether to do screen mock-ups or storyboards. If the BA wants to develop these to convey to the user what the solution might look like then this should be commended. However, a BA still needs to develop the use cases for the developers to understand the logic behind the user interface.
I got a difficult email this week. It went something like "I have just found something new. Apparently five diagrams can replace our long business requirement documents. Please investigate and see if we can get rid of RUP". This is what prompted me to prepare this posting. In general I believe diagrams are goodness but we need words to be precise. Hugos would like to regress to a simpler time. UML is a standard and we use well-accepted standards to make our life simpler. We should not be slaves to our methodologies. Develop screen-shots or storyboards or prototypes if they will help the users understand their requirements. We need to remember that the developer will benefit by seeing a use-case in a format that he or she is comfortable with and expresses what happens behind the user interface.
References:
Two responses to the Hugos article:
Letter: UML Shifts Specs to User's Point of View
Bob Jones, October 15, 2007 (Computerworld)
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=304960
Opinion: Five Diagrams Redux
Bran Selic, an IBM distinguished engineer at IBM Canada, is co-chairman of the UML 2 task force in the OMG
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9043002&source=rss_topic73
The IBM article on Storyboarding
Form feeds function: The role of storyboards in requirements elicitation
http://www.ibm.com/developerworks/rational/library/dec05/krebs/index.html
4 comments:
Dear Antony,
Thank you for recognizing that none of my five diagrams is new; they have all evolved in our profession over the last 30+ years and were invented by far wiser people than me. It is sad to see critics claim that I am "re-inventing the wheel" or that I am merely using "home-grown" techniques when I talk about the five system design documents. Like yourself, I've devoted my career to the study and practice of developing software systems.
I have no quarrel with UML; it's just that UML specs are very hard for users to understand. The power of the five documents is that they communicate so well with non-technical users and those are the people we work for and develop systems for. When these five documents are used by development teams who are skilled in what I call the six core techniques (JAD facilitation, process mapping, data modeling, system prototyping, object oriented design and programming, and system testing) organizations are able to deliver application systems very quickly and very cost effectively. Here's a link to an earlier Computerworld column I wrote titled "The Value of IT Agility": http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=112307
Two global corporations are working with me this year and we are showing their IT development teams how to apply these documents and the six core techniques in an iterative system development approach I call the "30-Day Blitz". We've use the 30-Day Blitzes to create and iteratively enhance three systems for these companies - a supply chain visibility systems, a real-time quality control system, and a global workflow coordination system. Here's a post I wrote for my CIO magazine blog, "The 30-Day Blitz, IT Agility in Action": http://advice.cio.com/michael_hugos/the_30_day_blitz_it_agility_in_action
I don't claim these diagrams or this iterative development approach is best for all situations. I do not propose to replace UML. As you point out, these documents are similar to and can be produced in addition to UML documents. Because things move so fast these days, the seasoned IT professional needs to be able to use a technique like the 30-Day Blitz when needed. Doing so earns you a lot of credibility with users because they like the responsiveness to their urgent needs. Here's a link to a post I wrote that describes how business executives are reacting to the blitzes, "Agility Makes IT Fun Again": http://advice.cio.com/michael_hugos/agility_makes_it_fun_again
Quick action by development teams using the six core techniques and the five documents in an iterative process like the 30-Day Blitz both enhance the credibility of IT in an organization and also relieves pressure from users so you have time to take a more studied and measured approach to other IT needs. Pick an appropriate project; try a blitz and see for yourself.
Best regards,
Michael Hugos
CIO at Large
Center for Systems Innovation
Direct: +1 312-771-1354
Website: www.MichaelHugos.com
Michael
Thank you for your comments on this post.
It is good to bring these issues up. In the end we are trying to get developers and users on the same wavelength. Some representations are better for users and others are better for developers. The business analyst is stuck in the middle. A huge amount of software engineering best practice has been built around UML and this is suited to enterprise projects.
I have seen many systems developed in 30 days and then seen the IT department burdened by years of maintenance, enhancement and integration labour based around these "cheap" system. Spreadsheets and Access Databases can serve specific workgroup needs and the ability to develop solutions quickly makes everyone happy initially. However, the responsibility of a central IT department is to build enterprise applications that serve the organisation with the ability to scale, to integrate and to be maintained well into the future.
Analysing requirements for an enterprise application will involve stakeholders with uncertain and conflicting needs from different parts of the organisation. It takes time just to get consensus on requirements. SOA provides the promise to develop systems that are built with integration in mind. Many of our software engineering practices are aimed at providing applications that stay simple and maintainable as they age. These things do not score you quick accolades from the organisation but they stop your responsiveness degrading with the years.
In the end there is need for balance. You do need your quick wins and you do need your solid enterprise platform. Iterative development techniques under the guidance of enterprise architecture are one way to achieve this balance.
If you are ever at large in South Australia, look me up. I would be happy to show you through my IT department.
Antony
Antony,
I agree that iterative development techniques under the guidance of enterprise architecture is the way to achieve balance between need for quick wins and the need for a solid enterprise platform. I can introduce you to a fellow senior enterprise architect at a global electronics and software firm who has done this.
It is from the foundation of a well thought out enterprise architecture that the quick wins are possible. SOA techniques combined with components selected from your enterprise architecture make it possible to get quick wins yet still create stable and scalable systems; they are built with trusted architecture components and small chunks of custom code. In this way application systems evolve quickly as needed yet don't become a hopeless mess of unmaintainable code.
You are also right about the Business Analyst being stuck in the middle. Good BAs do the translation between user oriented specs and developer oriented specs. The BA role is pivotal in project success. A good BA is skilled in JAD facilitation, process mapping, logical data modeling, prototyping of screen designs, and training and testing.
Michael
Excellent discussion.
Thanks for sharing.
Post a Comment