Declan Chellar

Why do some customers put a proof of concept into production?

In part, I suspect it has to do with wanting to spend as little as possible and still end up with something that earns them revenue.

But I think it is mostly because customers fail to grasp what proof of concept really means. It could also be that a vendor, desperate to get some work, rushes into a POC without fully explaining the limitations.

There is a simple analogy you can use to understand or explain the difference between a proof of concept, a pilot and a production-ready system. Let’s imagine your customer wants  a parachute system capable of being steered and performing acrobatics.

Continue reading Would you jump out of a plane with a POC?

Here is a fabulous animation from RSA Animate, illustrating a talk by author Barbara Ehrenreich on how positive thinking can be delusional and harmful.

She basically says what I said in “Reality check“, but with more eloquence and concrete examples. I dislike her already. Applause to the cartoonist also.

Thanks to my friend Rowan Manahan for pointing out this video.

BP have been subject to scorn and rage over the past few weeks, and rightly so. Of course, inane comments attributed to BP CEO, Tony Hayward, have not helped.

• “The environmental impact of this disaster is likely to be very, very modest.” Unless you live in Louisiana or Florida, that is.
• “I want my life back.” So do the families of the eleven people who died on the Deepwater Horizon rig.
• “The Gulf is a big ocean.” A big ocean with a big coastline that was not designed to have millions of barrels of oil a day pumped into it.

Continue reading Same Deepwater as you

A friend told me the other day that at a company meeting, the directors of the company brought up the subject of work-life balance.

It seems they were getting tired of the scales being tipped strongly in favour of work.

The CEO’s response?

“You should take up Tai Chi, it has done wonders for me.”

Erm, boss, I think you have to have a life in order to be able to take stuff up, especially when it is slow-moving stuff.

This stuff takes time, you know. Even to do it as badly as this!

Yesterday I had an online chat with a friend and the subject quickly turned to work stress and bullying. My friend gave me permission to reproduce the chat on my blog, so here it is, abridged, with some further comments inserted by me afterwards for your benefit.

Such comments appear in green (See what I did there?).

To understand all of this conversation, it would be useful for you to know that I am a qualified martial arts instructor and that my friend was a student of mine some years ago.

Continue reading Take a deep breath…

In Light Use Cases: Part 2, I promised I would talk about documenting business rules and data items relevant to a use case. Here I am, fulfilling that promise.

Imagine a holiday company requires a system that allows it to, among other things, take bookings for holidays. I have modelled a “Take Booking” use case in activity diagram form.

You will notice that I while I have made references to data and business rules, the specifics do not appear within the diagram. Those details are held in a spreadsheet. The reason for this is maintainability and reusability of the rules and data items and to facilitate logical data modelling.

If you look at the diagram and the spreadsheet, you will see that the diagram and the business rules make reference to each other using a combination of use case step numbers and rule ids. You will also see that the spreadsheet can be filtered to see which use cases use which rules and data items.

By documenting the rules and data items in this way, you have a central repository for both. This allows analysts to check for existing rules and data items before adding them to a new use case.

It also allows us to maintain rules and data easily, since the details are held in one place.

The price you pay for this approach is that you cannot understand the full detail of the use case without opening the spreadsheet. Some reviewers will not like that, because it means a little more work for them when reviewing the use case. But I believe that the advantages outweigh this one drawback and so I make it my business to sell the idea to the reviewers.

By the way, the purpose of this post is not to show a perfect “Take Booking” use case, so no suggestions on how to improve the use case itself, please.

Benefits:

• Business rules, data items, notifications, SLAs, etc, are easily maintainable (saves time in the long run).
• Business rules, data items, etc, are easily identified for re-use (saves time and effort in the long run).
• Facilitates logical data modelling, which is essential to good physical data modelling (poor physical data modelling causes worsening system performance over time).
• No voluminous use case specifications

Drawbacks:

• Some extra effort is required in reviewing a use case.

Related posts:

• Light Use Cases: Part 1
• Light Use Cases: Part 2
• Light Use Cases: Part 3

As a follow-on from Light Use Cases: Part 2, here is a short tutorial on modelling use cases as activity diagrams. It is best viewed in full-screen mode.

Kind regards,

Declan Chellar

I am fond of System Use Cases as a tool for documenting functional requirements, but I am not a big fan of use case specifications.

I find the textual specifications result in the kind of weighty documents that everyone hates reviewing and I continue to be amazed that so many analysts start documenting a SUC by writing out a textual specification instead of modelling visually.

Indeed, there are still some analysts who don’t bother to produce a visual model of the SUCs at all!

People relate better to pictures than they do to text, that is why the Rational Unified Process tells us to model visually.

Those who are not familiar with SUCs do need to be taught how to read an Activity Diagram, but take a look at this SUC specification and then at the corresponding Activity Diagram and tell me which you think is easier to follow. Now imagine a much more complex use case.

My approach is to dispose of the textual version altogether (except for the “Characteristic Information” section), since it says nothing that is not said more concisely and more clearly in the diagram. The result is a set of SUCs that are easier and quicker to review.

You will notice that in neither the specification nor the diagram do I provide details of the business rules or data requirements. I will explain why in a later post.

Kind regards,

Declan Chellar

Related Posts

• Light Use Cases: Part 1
• Light Use Cases: Part 3

Recently I was asked to take a look at some System Use Case (SUC) specifications. What I found was actually a description of a screen flow crowbarred into a SUC specification template.

There are two questions you might be asking.

1. What’s wrong with that?
2. How does it come about?

What’s wrong with that?
The purpose of the SUC is to understand the Actor/System interaction at a logical level and to tease out and make clear the primary path and all alternate and exception paths. A well crafted SUC also makes it clear where business rules are needed. SUCs don’t care about button clicks because they distract from the logic of the scenario.

Screen flows are not about the underlying logic, they are about showing all the possible routes through the screens, depending on which buttons you click.

It’s a problem when you focus on the button clicks, because you risk missing out on some of that underlying logic. You risk missing out on alternate and exception flows and you risk overlooking business rules. Iterative development is supposed to mitigate risk, not increase it.

What is more, a screen flow is more easily read if it is visual, so cramming it into a SUC specification template does not make it easy to follow at all. In fact, I encourage people not to write SUC specifications at all, on the basis that they are hard for the customer to read, but that’s for another post.

If you document screen flows and call them SUCs, you may get approval from all parties (except the Software Architect, who, I imagine, would not be happy), but I am pretty certain not all parties will have the same understanding of the requirements. As a result, misunderstandings will not become apparent until User Acceptance Testing.

How does it come about?
Lack of experience. Analysts need to be strong-willed as well as flexible. While it is important to produce analysis artefacts that meet the needs of the intended readers, the analyst cannot simply be at the whim of those readers. If the intended consumers of the SUC are not themselves familiar with how to document a SUC, they will try to influence how it is documented and they will get it wrong. The analyst must be firm, explaining how things should be done, while being sensitive to the needs of the consumer.

Caveat
While screen flows should follow SUCs, don’t spend so much time producing “perfect” SUCs that you leave yourself with no time to produce screen flows.

Takeways:

• SUCs and screen flows are not the same thing
• Do SUCs first, then screen flows
• Model both visually

Every project needs the perspective of Demetri Martin.