"CRUD"ing in Use Cases

[thomaskilian]

Indeed
But just to turn the sense of my previous post inside out. What if you model the business of some IT management? They care about CRUD and how it is performed. So it certainly also depends on the level/boundary you're in.

Another 0.02€

[sargasso]

20c AUD!  

Occassionally, I have found that it is helpful to add constraints (postconditions) to use cases that annotate the CRUD effects of the use case.  For example, UC "Join Frequent Traveller Club", in our current system does not Create a member record - that record is automatically created when they make their first booking. This use case Updates the record.

Caveat!  The model has been created for test design purposes, not for system design!!  So these facts are pre-ordained by the system not by any design logic.

bruce

[jeshaw2]

Indeed
But just to turn the sense of my previous post inside out. What if you model the business of some IT management? They care about CRUD and how it is performed. So it certainly also depends on the level/boundary you're in.

Another 0.02€

I believe I made provision for that in my first post in this thread.  

[thomaskilian]

I believe I made provision for that in my first post in this thread.  

I may have forgotten that meanwhile. I'll take back my 0.02€

[mhdhallak]

Great post Jim!!

Every developer turned architect should print this out and paste it to their wall.  This simple example really highlights one of the biggest problems we have in systems design today.  Failure to focus on the true business requirements and benefits of a system is the #1 cause of product failure.

This is a bit off topic, but how can I speed up this transformation of mindset. That is, technically-inclined developer to business-focused architect.

Any books, websites, articles etc you recommend to help in this process? What I'm concenrned with here is the best practices for doing things in software analysis and architecture world. I mean, I already grasped most of the theory behind tools such as UML, but what remains are the best practices which usually come through life-time work experience.

AL

[thomaskilian]

I know you will get a quite number of recommendations. Mine is for Bittner's Writing Use Cases (which I choosed from a recommendation here earlier). It opens your mind on what should be the focus. And it is written from a daily practice.

However, nothing will beat your own practice  

[Paolo F Cantoni]

However, nothing will beat your own practice  

Right on Thomas,

This reminds me of the aphorism:

An amateur practices until they get it right.

A professional practices until they can't get it wrong...  

Paolo

[mhdhallak]

Sumbled upon this site

http://www.pols.co.uk/use-case-zone/use-case-papers.html

Got some great papers on use cases.

[«Midnight»]

Or, perhaps to take you back to the original question...

Take a look at Use Cases: Patterns and Blueprints, but Overgaard and Palmkvist. This goes into CRUD models, and uses non-trivial examples.

[jeshaw2]

This is a bit off topic, but how can I speed up this transformation of mindset. That is, technically-inclined developer to business-focused architect.

Harrumph!  An architect is still on the development side and still needs a technical mind set to function well.  Architects are use case readers, not use case writers.  An architect's strength still lies with deep technical knowledge of an even broader range of technologies.  A business analyst has a management mind set and credentials to earn the respect of other managers.  In my experience, a business-focused architect is an oxymoron.  If I found one, I suspect it would be someone trying to live in both worlds and not doing well in either.  There are, however, some exceptions to be found in this forum  

The best practice for developing a management mind-set is to "walk the walk" not just "talk the talk", nor "read the book".  To become a Business Analyst, become a manager with profit making responsibilities.  Give up that security blanket of deep technical IT knowledge and commit to learning deeply what a manager desperately needs in order to be successful.  It only takes a few weeks, of being in fear of losing one's job because you can't get the past-due shipments out the door, to make the mind-set switch.

Management skills are completely different from IT developer skills.  Read management books written by leading managers, not ones written by leading technical gurus.  Read

• Porter on Strategy
• Mintzberg on Organizational Structure
• Eli Rat's The Goal
• Books and Reviews from the Haavad Business School
• Textbooks used in your local college's MBA degree program
• just to name a few...
  

Ask your management for a three month transfer to a line management position as part of your training to become an business analyst;  they'll think that a smart thing to do if they support your career goals.  In its heyday, the Pennsylvania Rail Road required its software developers to be railroaders first and developers second, not the other way around.  If you are in a large corporation, check out their managent trainee program; see if you can get into it.

Well anyhow, that's how I did it.  I now yield my soap-box to other pontificators.  

[Paolo F Cantoni]

Don't forget Peter F. Drucker...

Paolo

[«Midnight»]

I'm from Canada; we can never forget Drucker...

[thomaskilian]

As we are in it: Brooks Mythical Man-Month and of course almost all of Tom DeMarco's books (esp. Peopleware).

[mhdhallak]

Thanks jeshaw2. That was pretty helpful.

[Kevin Brennan]

Must...resist...urge...to...self-promote...

In terms of books I would recommend David Aaker's Developing Business Strategies over Porter..it's less dense and covers the same ground.

The British Computer Society has a book on Business Analysis that looks to have pretty good coverage of topics (warnign: I haven't read it yet, so can't endorse it).