IT Unconsciousness

In the July edition of CACM, there is an article with a glowing title: “Managerial IT Unconsciousness”. It is a report on “software failure”, but with a distinct flavor; it is presented from an “IT” perspective. Although, it is still another report on how the lack of software engineering practices does hurt business, it does not mention the term software engineering at all.

The article presents three cases: a) Sydney Water a public company that lost around 61 million dollars, b) RMIT a educational institution who budget 12, 6 million for an academic management system spent 47, 3 and had to re-launch the project and c) One.Tel a company that went bankrupt with problems with its billing system. The amounts are in Australian dollars.

Out of the article I selected three statements from the stakeholders of these systems: a) from RMIT: “The project reports that came through to me and then went on to the council showed that the project was on time, on budget, and meeting its milestones. We all thought that this project was actually OK”, b) from Sydney Water: “There was a belief in Sydney Waters that IT projects of this nature and complexity would inevitably go over budget and be delayed”, and c) from One.Tel “Why bother with petty concerns like faulty billing systems – when you can be thinking about global communications”. Citations pointers are available in the references of the CACM article.

Avison, Gregor and Wilson believe that three common themes/causes emerge from the study: a) “Complexity of application system software”, b) “Poor IT governance”, and c) “Relatively inexperienced and/or powerless IT staff lacking clout among corporate decision makers”. The article concludes stating:

“Management may be seduced by the abstract nature
of software,the ubiquity of PCs on every desktop,
and the availability of genericapplications into
thinking that IT doesn’t matter. ...
Software is flexible,
and IS specialists can develop systems to support
almost any business application. By they are complex
and need rigorous design, carefulconstruction, and
exhaustive testing to ensure they actually do what
they are intended to do. Management must
understand, track, review,and control their progress,
particularly their impact on the rest of the organization.”

In the article there is no mention to the field of software engineering nor to requirements engineering. CMM is mentioned in the comparison table in the article as IT maturity, and as: “CMM Level 1-2” or “CMM Level 1”. I did not know about the 1,5 grade in the CMM scale! Anyhow, this is not the central point. The central point is that in 2006 we still see reports of the type of the failures that have long been reported.

In a previous note, we recall of the LAS case and the lessons learned and published to the community. The last two sentences of the quotation above show that the authors believe that software must implement their requirements and that one has to manage software using a requirements baseline (requirements management is a pre-condition to CMM level 2).

Yes, technology transfer is hard (read about it here and here)!

We need to keep pushing, but sometimes it is a little bit frustrating.

After all, what have we learned?

The Never Ending Story

Recently, Claudia Capelli called my attention to an IEEE Software Article with the title "Nurturing Requirements". The article was written by Dave Thomas and Andy Hunt who call themselves "T h e P r a g m a t i c P r o g r a m m e r s". The short article can be found here.

Claudia, who is working towards her Ph. D., liked the way the article points out to the fact that requirements are in constant change. The article is straight to the point.

Foster, bring up, nourish requirements. Is that the right way? I believe it is. Remember: requirements are a never ending story.

Is it ok to conclude the article with the sentence: "So, while you’re reading the rest of this issue about requirements and process, remember one thing. Requirements aren’t engineered; they’re nurtured."?

It is not! Despite the fact that requirements will evolve as " a complex, multi loop
multilevel feedback system" (using M. Lehman words), requirements elicitation, modeling and analyis must be done the proper way.

Which is this proper way? Answer: use a requirements engineering process. What is the catch? The catch is on using a proper process, which must be tuned to the case at hand.

Requirements evolution, or better software evolution has been a research topic dear to me for almost 10 years. We have introduced the concept of a requirements baseline which is in constant change, but is also the base for the required software.

By the way: if the title reminds you of something, probably it is the movie, or its originator´s book.

An Example of Transparency

Recently I became a flickr fan. Wonderful place to share views of the world.
There, I found out that, once you take a digital photo, your camera records, together with the picture, a series of information.
If your camera has been set with date information, you will be able to see this information as well as other related to the camera used and the characteristics of the given picture.

Want to see it?
a. go to explore flickr
b. go to the month of august
c. choose the picture of august, 5th
d. under "additional information" click on more properties (Oooopsss... The settings were changed, so it is not transparent anymore. See this one instead) (10-14-06).