21 Whoa.

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

posted at 06:20 pm on January 26, 2005 by Ryan Brooks

22 Excellent introduction...

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?

posted at 06:33 pm on January 26, 2005 by Michael Dance

23 application to make uml diagrams

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).

posted at 06:12 am on January 27, 2005 by Thomas Maas

24 Observation beats Consideration

[blockquote]“If we simply consider the roles played by the actors and their goals, the use-case model can very rapidly emerge.”[/blockquote]

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

posted at 09:54 am on January 27, 2005 by Joshua Porter

25 Guibot Web Site shows UML for web

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.

posted at 10:30 am on January 27, 2005 by Tim Meehan

26 Jim Conallen's WAE UML extension

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.

posted at 04:52 pm on January 27, 2005 by Padraig Coogan

27 Software engineering and design

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?

posted at 03:16 pm on January 28, 2005 by Peterman

28 Actors and Goals are good metaphors

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.

posted at 09:48 am on January 30, 2005 by Stephen Hall

29 FYI Tool

Just wanted to point out an interesting collaboration tool relevant to the audience here. http://www.taskportal.com

posted at 08:59 am on January 31, 2005 by John

30 Careful, Stephen:

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.

posted at 07:53 pm on January 31, 2005 by adam greenfield