Sunday, January 28, 2007

why UP is important and why use cases are not

[Update from my later perspective: I guess this is the point that I begin to take pieces of “process” and reduce it as (trivial) engineering item. Eventually, I believe “processes” can be reduced as software architecture (engineering), economy, or, politics; I also believe this is the spirit of “lean” process: pay attention to “things themselves”]

Vikas has a very good post here:

It prompts me to put some comments there and put more comments here:

1. Why UP is important.

I see the contrasting directions Vikas and I are emphasizing in the past and present. It seems that Vikas is now emphasizing more on TDD, while I am emphasizing more on UP.

I believe Vikas’s order (UP first; then, XP) is a better approach. Somehow my steps (XP first and then UP) are not “logical”. However, there is a good thing out of it: as a result, I explicitly noticed something that it is worth it to document here.

The reason of emphasizing UP is that I have gradually realized that a lot of people, both mangers and developers, treat software process as a management common sense, instead of an engineering domain. They have no clue (sorry for the bluntness), yet they can talk like they know, because of the apparent similarities of basics. I want to de-emphasize the “common sense” aspect. I understand there is a “common sense” aspect, and there is a “top-down” (i.e. business oriented) approach for the “process”. However, now I want to emphasize the fact that if a person does not know object oriented programming (English talking does not count; and VB6 programming does not count), then, he/she is not qualified to talk about modern software process. They need first to study and learn, and UP offers an excellent tone and context for that kind of learning. Modern software processes depend on serious OO experiences.

2. Why use cases are not

One thing I especially want to augment the points in “Pragmatic programmer”.

It starts with the “requirement pit”: “Don't Gather Requirements—Dig for Them” -- it is very true. Developers, working with users and business analysts, need to help to define the new business workflows. They do not just “gathering”! In order to do it, you have to “Work with a User to Think Like a User”.

I agree with all those totally and I have nothing to add there. However, the book did not do a thorough work on “how to document requirements”. It mentions “use cases”. To me, it is scratching itch through shoes. It also mentions “Sometimes the Interface is the System”. It is so close. However, it is still not there, yet.

In my previous posts, I put together a “user manual with glossary—spec—test script—user manual with glossary again” approach (By the way, the book also indicates the importance of a “glossary”). It is basically the “storyboard” method used in the industry; however, it add things in the perspective of a “user manual” (so, you must think like a user) and a “test script” (so, you can have some “example data” in the document).

To make it clearer: please discard the famous “use case”, for two reasons.

On the one hand, it does not have screen mockups -- it does not help to get users involved. For most business applications, without mockups, it means absolutely nothing to users. Without mockups, it is inevitable that there will be a lot of ambiguities and there will be huge misunderstanding. “Glossary” will help; but it cannot help without mockups. Without mockups, you are inviting disasters to happen!

On the other hand, those “preconditions”, “failure end conditions”, “success end conditions”, “extensions”, “variations”, they can be covered by the “behaviors” (or “logic”) of the buttons in the mockups. Every programmer knows them – they are big words for the trivial things: ordered steps; if-else; loop – give me a break! Who does not know them?!; every power user also intuitively knows them (again, they are just trivial logic 101). Itemizing them into sections makes things so unnatural that they block the discovery and defining the inherent logic.

As a result, it is not just adding “mockups”, we need to remove those “use case” signature items. Of course, we can use “user cases” as a general concept, to refer to the “flow” aspect (the other complementary aspect is the “entity” aspect, which starts with “glossary”).


Post a Comment

Subscribe to Post Comments [Atom]

<< Home