What’s the Problem?

by Tim Meehan, Norm Carr

33 Reader Comments

Back to the Article
  1. Now, I have to admit that this article totally shines a new light on most of what my company does… Thanks!

    Copy & paste the code below to embed this comment.
  2. Good introduction to get people started on UML, I am just curious what program was used to create the articles UML diagrams, or what suggestions do people have for UML diagrams, also does anyone have any good articles/links/examples of UML with regards to web development?

    Copy & paste the code below to embed this comment.
  3. Michael,

    As for the application to make uml diagrams:
    give argouml ( http://argouml.tigris.org/ ) a try. It’s open source and basicly platform independent (Java).

    Copy & paste the code below to embed this comment.
  4. “If we simply consider the roles played by the actors and their goals, the use-case model can very rapidly emerge.”

    Consideration is good, and important. However, observation is better, and is nothing more than simply discovering actual use cases. Go directly to the source!

    Copy & paste the code below to embed this comment.
  5. To answer Mike Dance’s question – the Guibot website shows how Use Cases generate the menu for the web site. Also, the Guibot tools will generate the Use Case diagrams and the Use Case specification. Argo UML is an open source tool, Borland has a community edition designer and IBM Rational carries the more expensive sophisticated UML tools.

    Copy & paste the code below to embed this comment.
  6. Besides Cockburn’s excellent book, may I recommend, by the same publisher, “Building Web Applications with UML”, Jim Conallen. Addison-Wesley, 2003. ISBN 0-201-73038-3. The author, from Rational Software, has developed a UML extension for modeling web applications.

    Copy & paste the code below to embed this comment.
  7. peter wrote:

    >>>i call bullshit<<<

    I smell trollshit.

    >>>software engineers don’t know much about design<<<

    Design is a fundamental part of software engineering. Without it, you would have a lot of people saying “OK, this is what the software needs to do” and then start coding without thinking about how it should be done. A software engineer knows a good deal about design by definition, or he/she isn’t a software engineer.

    Unless, of course, by “design” you mean “graphic design” or “web design”.

    And unless, of course, by “software engineer” you mean “programmer”.

    (Which is not to say programmers don’t know anything about design. But they don’t necessarily need to.)

    >>>look at how bad most software is. and the best part is that most software development happens outside the “established” software engineering theory<<<

    See, this is the part that tells me this message was just intended to provoke. The ‘“established”’ theory that “adds nothing to the process” isn’t used for “most software”… and “most software” is bad? Can you miss the connection?

    Copy & paste the code below to embed this comment.
  8. Since everyone involved in the project—client, developer, coder and visitor—are ‘Actors’, this is an excellent metaphor. It removes the site development them vs us thinking.

    Developing a good scope of work plan [SWP] for a project—in the form of a proposal—is an important first step. Design & development is a cooperative process between the client, developer, coder and often test-users. Effective scope of work plans leave room for the ‘Actors’ to have input into schedule and sequence of things to be done PRIOR to signing a contract. Everyone has ownership.

    A well thoughtout scope of work plan—revealing the often misunderstood complexity and many steps of an assignment—often serves to give the client a better understanding of why development fees should be at an adequate level.

    We often spend a day developing a scope of work plan for an average project. Spend more time developing a thorough scope of work plan and you’ll have a clear blueprint for completing your assignment, invoicing, and client/vendor interaction, resulting in a project with less miscommunication and more satisfaction.

    Copy & paste the code below to embed this comment.
  9. Just wanted to point out an interesting collaboration tool relevant to the audience here. http://www.taskportal.com

    Copy & paste the code below to embed this comment.
  10. You wrote that “everyone involved in the project—client, developer, coder and visitor—are ‘Actors’,” but this is a misunderstanding of the terminology. (In fairness to you, it’s easy to see how this misunderstanding arises from the article.)

    An actor, in the context of a use case, is generally the human being actually interacting with the application, device, or site – a user – although actors can also be institutions or systems. In this context, developers, coders, and clients are precisely not actors.

    Misunderstandings like this are part of the reason why I believe UML is best used for what it was originally intended for, mapping application architecture, and not discovery-phase business- or user-needs analysis. It’s just not the right tool for the task.

    Copy & paste the code below to embed this comment.
  11. Learned about User Stories (or use cases) through a book called Extreme Programming, which has the unfortunate acronym of XP.


    In any event, the books on XP helped tons in my role as UI designer and liason between customer (User) and developer. And shaped how I communicate with any new client, no matter how small the site or job at hand.

    Copy & paste the code below to embed this comment.
  12. Joshua Porter makes a crucial point when he says that observation is better than consideration. This is a distinction I make between weak and strong user-centered design. In weak UCD, we think about, or read articles about, users and then design stuff for them. In strong UCD, we observe them, preferably in the field, not just in the lab, and iterate with them during the design process (an approach at least somewhat compatible with agile methods).

    Use cases can become simply another way of foisting our pre/misconceptions on unsuspecting users if we do not ground them in a rich understanding of users’ motivations, tasks, environment, and characteristics. The risk of this happening increases as the people for whom we are designing/building are less like us.

    While either use cases or scenarios can help interaction designers and software engineers communicate, I prefer Contextual Design, with its emphasis on involving the entire cross-functional team in UCD. I’ve seen it transform an entire organization’s approach to developing software.


    Copy & paste the code below to embed this comment.
  13. This article’s Russian translation is avalable at:

    Copy & paste the code below to embed this comment.