Use Cases and object oriented analysis and design

[ConvertFromOldNGs]

by Eric Peachey >> Mon, 7 May 2001 6:45:16 GMT

[ConvertFromOldNGs]

by Hugh McColl >> Mon, 7 May 2001 10:59:06 GMT

Eric,

I have to admit that I don't entirely agree with certain details in Meyer's critique of 'Use Cases'; however, my own observation is that too much up-front time tends to be invested in 'Use Case' analysis at the expense of other more critical aspects of (resource constrained i.e real-world) software development. On the subject of Use Cases and OOAD in general, I would like to recommend certain articles that can be found on the net (bias intentional ).

Last year I benefited from attending an interesting and provocative keynote address at an OO conference by Jim Highsmith on the subect of "Adaptive Software Development". Since then, I found an online article by Highsmith covering the same subject matter that I would like to recommend as *essential* reading to all software developers, including project managers and decision makers.

The paper, titled "Using Adaptive Software Development to meet the challenges of a high-speed, high-change environment" can be found at: http://www.adaptivesd.com/Articles/Reti ... osaurs.pdf

The following are also on my recommended reading list:

"Use Cases: Challenges in Their Use": http://www.cbd-hq.com/articles/1999/991 ... lysis2.asp

Chapter 5 "Understanding Requirements" from a draft version of
"Applying UML and Patterns - An Introduction to Object-oriented Analysis and Design": http://www.craiglarman.com/book_applyin ... 20reqs.pdf provides some useful insites.

Craig Larman's home page is also worth a look: http://www.craiglarman.com/

Kent Beck and others have factored the essense of a 'Use Case' and come up with the concept of a 'User Story' (a lightweight Use Case) as the basis for requirements analysis in eXtreme Programming:
http://ootips.org/xp.html

If the idea of a lightweight Use Case catches your fancy I would recommend taking a closer look at any of a multitude of links on XP (eXtreme Programming).
Rob Barr suggested the following URLs in a recent thread on a JADE ng: http://www.cutter.com/ead/ead0002.html http://www.martinfowler.com/articles/designDead.html

Finally, if you have read this far and somehow you managed to remain awake the principles proposed by the "Agile Software Development" team capture the essentials of greate (as opposed to mediochre) 'Software Development', in my view.

"Agile Software Development":
http://agilealliance.org/
"Principles of Agile Software":
http://agilealliance.org/principles.html


Regards
Hugh McColl (JDC)

[ConvertFromOldNGs]

by Warwick Hunt >> Mon, 7 May 2001 21:17:40 GMT

Of the principles listed in Hugh's reference, my favourite is "Business people and developers must work together daily throughout the project".

Unfortunately it's also the hardest to achieve and the one which, when broken, will most likely cause your project to thrash.

Take, for example, a project to develop an enterprise-wide application for a highly bureaucratic organisation - let's say a Tertiary Education Institution. If the outfit doesn't have the money or the inclination to provide dedicated staff to the project, or if the staff are not empowered to make decisions without ratification from their bureaucratic masters, then all the use-cases, methodologies, life-cycles and manifestos in the world won't save you.

Much more important is to educate your customer on what he/she is buying when he/she signs a software development contract. If I had my druthers, I'd walk away from contracts where the customer clearly doesn't get it.

Warwick

[ConvertFromOldNGs]

by Eric Peachey >> Mon, 7 May 2001 21:39:09 GMT

<slash>

If the outfit doesn't have the money or the inclination to
provide dedicated staff to the project, or if the staff are not empowered to make decisions without ratification from their bureaucratic masters, then all the use-cases, methodologies, life-cycles and manifestos in the world won't save you.

Much more important is to educate your customer on what he/she is buying when he/she signs a software development contract. If I had my druthers, I'd walk away from contracts where the customer clearly doesn't get it.

Hit the nail on the head there Warwick.

E in D

[ConvertFromOldNGs]

by Hugh McColl >> Tue, 8 May 2001 13:50:06 GMT

Of the principles listed in Hugh's reference, my favourite is "Business people and developers must work together daily throughout the project".

Yes, this can definitely be a significant contributer to the success of a project. However, before we look too closely at what might be expected from the customer, what about the way we, as software developers go about developing and delivering software? Topmost on the list of principles of 'Agile Software Development" are:

1. "OUR HIGHEST PRIORITY is to satisfy the customer through early and continuous delivery of valuable software."
2. "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

Note the clear customer focus in these principles. Traditional (process centric) approaches to software development seldom deliver on either of those principles for complex projects.

Unfortunately it's also the hardest to achieve and the one which, when broken, will most likely cause your project to thrash.

I am not convinced that it is the hardest to achieve. Refer to Highsmiths' article on 'Retiring Lifecycle Dinosaurs' on the need to re-examine (process centric) software development practices and management in order to meet the challenges of the "high-speed, high-change environments of today". There are some difficult challenges there for any software development gorup or organisation with an 'optimising culture' to use Highsmith's terms.

Take, for example, a project to develop an enterprise-wide application for a highly bureaucratic organisation - let's say a Tertiary Education Institution.

Wink, wink, nudge, nudge, say no more.....

If the outfit doesn't have the money or the inclination to provide dedicated staff to the project, or if the staff are not empowered to make decisions without ratification from their bureaucratic masters, then all the use-cases, methodologies, life-cycles and manifestos in the world won't save you.

Save you from what? Failure? Perhaps you are expecting too much? None of these items is a 'silver bullet'

The references in my initial post were selected to favour 'Low Ceremony' (or light methods) where the focus is on people and interaction, results (delivering working software), *minimal methods* and maximum collaboration. Of significance, is that the 'low ceremony' camp deliberately devalues 'process centric' methods and artifacts such as use-cases that don't significantly contribute to the botom line:

delivering working software, on time to satisfy users' *continually changing requirements*

You listed 'manifestos' in your list of things that won't save you from the bogie man. The 'Agile Software' groups manifesto is a collection of values that they believe leads to better ways to develop software. The group values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Much more important is to educate your customer on what he/she is buying when he/she signs a software development contract.

Well yes, the customer clearly needs to understand what they are buying in to. However, if you are willing to 'embrace change' neither you nor the customer will know exaclty what they are going to get at the end of a project (cos' it's all gonna change). How many software projects involving significant new development have you worked on where the customer knows what they want before you've delivered something and where the users' requirements don't change during development? It is of course possible to take a hard-line approach and not allow deviation from intitial requirements as specified in some form of contract, but then the customer is not going to be satisfied.

I would like to finish up with a motto I saw on an XP badge that represents an admirable target in the context of this discussion:

eXtreme Programming - "Developing at the speed of change"

[ConvertFromOldNGs]

by Robert Barr >> Tue, 8 May 2001 22:00:25 GMT

It's a fixed quote world.

The customer wants to know what it's IT spend is up front, and once fixed, is reluctant to change.

To effectively manage resource and cash-flow, the supplier also wants
the value of a contract to be fixed.

The supplier may remember having it's fingers burned by overruns ... these are typically blamed on insufficient scoping (understanding of, or definition of requirements) ... so driving ever more comprehensive documentation.

Does the budget need to be as flexible as the developers?

--- "Invoicing at the speed of change" ---

[ConvertFromOldNGs]

by Craig Shearer >> Wed, 9 May 2001 0:05:51 GMT

Well put Robert... I guess nivana is having the users involved and developers being responsive to change, but that means that the users need to be aware of the costs of each change, then agree to those costs. (Oh, and developers would need to be compensated for the time spent investigating the cost of the change too).

In my experience, if you go down that path, you quickly alienate users as they think you're stinging them with a huge cost for what is perceived (by them) to be a minor change.

Craig.

[ConvertFromOldNGs]

by Robert Barr >> Wed, 9 May 2001 1:24:06 GMT

If a methodology can't fit into the harsh commercial world, then it's merely a coffee break discussion topic.
How do you write an iterative contract?
Would a business person want one?

[ConvertFromOldNGs]

by Gerard O'Brien >> Wed, 9 May 2001 3:35:33 GMT

Robert, Craig; Have you actually read "Retiring Lifecycle Dinosaurs" by Jim Highsmith ?

[ConvertFromOldNGs]

by Robert Barr >> Wed, 9 May 2001 6:37:59 GMT

Jim focusses on software development management but does not explain how his ideas fit with fixed quote contacts. Jim bemoans resistance to changing software development and management practices, but do these changes require corresponding changes to software sales practices? Or to the way that customers 'buy' software, as something that has, as Jim describes his brave new world, 'shades of grey'. Sounds like bugs to me! Some of it is just the same tasks we do now, or the same ideals we
strive for now, but rehashed with different names. Also, some ideas do not scale. Don't get me (too) wrong - Ive got a lot of time for Jim H (amongst the preachery) - in fact some of the principles I particularly like, and I know are succesful that spring to mind (but Jim didn't
invent these) are 1) continuous feedback/visibility, and 2) get working code asap

In fact, it's easy to fit #2 into that harsh commercial world, by splitting work into a scope and build phase - the customer does not know what build will cost until scope is complete. However, the *real*
benefit of the scope is usually the prototype(s) - *get working code asap*. This is where you find what the customer really wants - I'd guess somewhat different from the use-cases that may have been written without the visible software. However, I can't recall a customer that, at this point, was happy proceeding without a price. But the prototype did buy you a risk-free speculation/collaboration/learning cycle.

So then you do your estimating (Jim's phrase is timebox) - and this is
an area where scale can cause big problems, where estimating is split up on a large, complex projects. Designers typically estimate based on output from analysts (perhaps use cases, to get back to Eric's original thread). Unfortunately, by this time, then the customer has already signed their fixed price contract. The use cases are in concrete.
Changes must be negotiated. Did you determine your cycle length and frequency based on Jim's oh so comprehensive rule of thumb? Then who
pays for any unplanned speculation/collaboration/learning cycles?