The Hindu Business Line : To resolve a failure first find the fault

THE most important quality characteristics that software users look for are reliability/availability, rapid delivery, and low cost, but what's most crucial for developers is "how to resolve conflicting demands that customers place on them," writes John D. Musa in Software Reliability Engineering, from Tata McGraw-Hill (www.tatamcgrawhill.com) .

To help developers manage the conflict, researchers have focussed thus far on the mechanics of software development and built many tools for the purpose; in the process, not much attention has been given to `engineering', says Musa.

`Engineering' software reliability means, "developing a product in such a way that the product reaches the `market' at the right time, at an acceptable cost, and with satisfactory reliability."

I'm sure the accountant near you is curious to know if SRE (software reliability engineering) would add to cost.

Cost is low, assures Musa. "There is an investment cost in training and planning of no more than three equivalent staff days per person in an organisation," he explains.

The operating cost in SRE is `the cost of developing the operational profiles', and on an average the effort is "one to two staff months for systems in the range of hundreds of thousands of source instructions."

The formula for computing the operating cost of SRE over the project life cycle as a per cent of project software development cost is P=10S - {+0}{+.}{+7}{+4}, "where P is the per cent and S is the project size in staff years". For small projects, the total effort is usually no more than one staff month, Musa points out.

Before you `engineer', you must know the meaning of `reliability' and the related `availability'. Musa defines reliability as "the probability that a system or a capability of a system will continue to function without failure for a specified period in a specified environment".

While `safety' is a specialised sub-category of reliability, "portability, modifiability, and understandability of documentation" aren't part of reliability, please note.

One of the exercises at the end of the chapter is on the reliability theme: "An expert system (software) assists open heart surgeons by continuously analysing patient's echocardiogram and electrocardiogram, alerting surgeon to potential problems (e.g. 40 per cent chance of fibrillation), and recommending responses. How reliable should this software be?"

Why should you have a reliability objective? Shouldn't you strive for zero defects (faults)? Musa answers these questions and also scores of more queries included in helpful FAQs throughout the book.

Here's a glimpse of a few more posers: "Where can SRE make its greatest contribution in improving the software development process? How will the move to network computing affect SRE? How does SRE relate to the Capability Maturity Model? How does FMEA (Failure Modes and Effects Analysis) relate to SRE?"

Failure and fault are often used interchangeably but Musa explains the difference between the two. A failure is a `user-oriented concept'; it is "a departure of system behaviour in execution from user needs."

A fault, on the other hand, is a `developer-oriented concept'; it is the defect that causes or can potentially cause the failure when executed.

Thus, "a fault doesn't necessarily result in a failure, but a failure can only occur if a fault exists. To resolve a failure you must find the fault."

It would be a big fault not to get your developers read Musa!

Missing piece in the J2EE jigsaw

ROD Johnson and his team have written Professional Java Development with the Spring Framework, from Wiley Dreamtech (www.wileydreamtech.com) .

Spring is an application framework, explains the book, right at the start. "Unlike single-tier frameworks such as Struts or Hibernate, Spring aims to help structure whole applications in a consistent, productive manner, pulling together best-of-breed single-tier frameworks to create a coherent architecture."

But first, shouldn't we know why a framework is needed? Because there is a missing piece in the J2EE jigsaw, the application developer's view, say the authors.

Therefore, using J2EE (short for Java 2 Platform, Enterprise Edition) `out of the box' is not an attractive option.

"J2EE does a great job of standardising low-level infrastructure, solving such problems as how can Java code access transaction management without dealing with the details of XA transactions. But J2EE does not provide an easily usable view for application code."

So, here comes the `agile' Spring relief by enabling you to enjoy the key benefits of J2EE, while at the same time "minimising the complexity encountered by application code".

Spring has `values' such as being non-invasive, consistent, promoting code reuse, facilitating object-oriented design, promoting pluggability, and not reinventing the wheel.

Spring technology is "the Dependency Injection flavour of Inversion of Control" and the latter, i.e. IoC, is best understood through the `Hollywood Principle', meaning "Don't call me, I'll call you." Dependency Injection is a form of `push configuration', based on Java language constructs, rather than the use of framework-specific interfaces, explain the authors.

"Instead of application code using framework APIs (i.e. application programming interfaces) to resolve dependencies such as configuration parameters and collaborating objects, application classes expose their dependencies through methods or constructors that the framework can call with the appropriate values at runtime, based on configuration".

Know that POJOs or Plain Old Java Objects are going to get enterprise services from Spring, which is a triangle with IoC, AOP (or aspect oriented programming) and CSA (consistent service abstraction).

"In OOP we model real-world objects or concepts, such as bank accounts, as objects, and organise these objects in hierarchies," as you perhaps know already.

AOP works differently; it enables you to think about "concerns or aspects" of the system. "Typical concerns are transaction management, logging, or failure monitoring," say the authors and point out that AOP enables us to capture "the cross-cutting code in modules such as interceptors that can be applied declaratively wherever the concern they express applies - without imposing tradeoffs on the objects benefiting from the services."

That may be quite abstract for many, and so I'd leave out the other abstraction, viz. CSA, with the hope that eager beavers would unravel the Spring mystery, to gain some spring in their `developing' steps!

Tailpiece

"I don't understand what the developing team talks!"

"Try running a compiler."

"You mean, a road-roller?"

Books2Byte@TheHindu.co.in

Article E-Mail :: Comment :: Syndication :: Printer Friendly Page

Stories in this Section
The verdict: Go digital

Free to move

All about telecom and tax

The inside story

Score for the team

Preventing Trojan horse intrusions

Booting hitch

Giving shape to technology

The world's within reach

To resolve a failure first find the fault