Codes of calibre

Rukmini Priyadarshini

EVEN as the quality of Indian software has a strong brand recall value in the international market, quality consciousness and process improvement are taking centre-stage in the country's tech companies.

eWorld caught up with the prima donnas of quality - at Bangalore recently for the hottest IT event of the year, IT.COM 2001 - to get a line on the state of the practice in software engineering and the trends taking shape.

Trend I: Software manufacturing

And, the first of these is, surprise, surprise, a move away from software engineering to software manufacturing. Identifying this, Stephen E. Cross, Director and Chief Executive Officer of Software Engineering Institute, Carnegie Mellon University, says the focus now is on a software-product-line approach. ''The business strategy is organised on the basis of the argument that there is greater return on investment if a product line shares the software architecture and while the core assets include software,'' Cross says.

''The trend is a move from software engineering to software manufacturing, a move away from the component-based approach of the 1990s,'' according to Cross. An example of the product-line focus is Motorola's Flexworks project which achieved 4x cycle-time improvements or HP's printer systems which achieved 2-7x cycle-time improvements, Cross says.

The product-line approach helps get new devices and new products quickly onto the marketplace. It adds functionality to software and gets the product out more quickly, with more functions and features. The product-line approach also addresses the top management dilemma of aligning business needs and strategies with quality concerns. ''Top management face the pressure of reducing time to market,'' Cross says. The conflicting emotions of CEOs when instituting quality procedures, their mistaken perception that these procedures affect schedules are quite unnecessary, he says. This approach is fast finding favour in the telecom market as well, say experts.

Those organisations adopting the product-line practice have started with a commitment to process improvement. Level 5 organisations are in a good position to get a headstart on this, it appears.

Trend II: Branding Indian software quality

Increasingly, industry opinion has it that Indian software quality must be branded and its value realised in Western and other markets.

At the same time, and perhaps because of branding hopes, there is widespread concern about a quality backslide in India. ''This neglect of quality issues could be because of the need for speedy application development and time pressures,'' says Girish V. Sheshagiri, co-founder of the Watts Humphrey Software Quality Institute, Chennai, and CEO, Advanced Information Services Inc.

The need to spread the quality culture among organisations and individuals has been recognised. The Software Process Improvement Network, part of a worldwide software quality movement, has a good base in India.

With 11 such chapters in the country and Bangalore being the largest among the 95 such chapters across the world, India has a good background.

''There is much scope for the spread of such organisations as well as for increased depth,'' says Cross.

Of the 132 high-maturity organisations worldwide, 69 are in India. The process-improvement movement is only gathering strength and this should be leveraged well by organisations and the Indian software industry, it is argued.

There is, of course, a cautionary note against an overemphasis on maturity level as a means of acquiring contracts without a continued focus on process improvement. ''Several Level 5 organisations have individual engineers working at varying levels of maturity,'' says Sheshagiri.

Not everybody agrees. Says Sreeshaila, Director, Software Quality, Bell Labs, Bangalore, that such a situation could happen only in a shallow implementation of the quality initiatives. ''When an organisation is implementing the process-improvement programme, you do not treat it like an exam to be passed. CMM is about bringing in discipline within the process,'' he says. ''When top management is trying to get engineers and project managers to buy into the quality programme, it is not the marketability but the quality issues that are emphasised.''

Trend III: 'Level 5 is just the beginning'

Capability maturity is a necessary but not sufficient condition for software quality excellence, says Cross. Level 5 maturity brings about an awareness of the need for continuous improvement, he says. ''The message for Level 4 and Level 5 organisations is that they have just started, There is no need or way that they can consider the achievement of the maturity level as the conclusion.''

Click here for Table

For CEOs, the lowering of costs and the marketability of the maturity level are important and continued investment in process improvement may seem superfluous. In fact, an organisation can continue at Level 5 maturity only if there is top management commitment, says Sarala Ravishankar, Motorola India Electronics Ltd (MIEL). Fifteen years into the industry, she heads the wireless subscriber business at Motorola's flagship centre for its global software division and she has been associated with MIEL and its quality commitment since its inception in 1991.

Click here for Table

''We have had a high maturity process implemented from the beginning,'' she says. In 1993, MIEL was the first commercial software entity in the world to reach SEI CMM Level 5. ''Since then, it has been a case of institutionalising organisational excellence,'' she says.

'What after Level 5?' is a question that puzzles most organisations. Sarala Ravishankar says MIEL did not rest once it achieved its Level 5 maturity. ''The quality of our projects enabled us to get larger, more complex projects and we moved up the value chain.''

However, the most important benefit from the quality effort has been alignment, according to Sarala Ravishankar. ''Everybody speaks the same language. The discipline that process-improvement programmes require of us is crucial to software development,'' she says.

''Since we work in large teams, distributed globally, the discipline enables us to make the right commitments and to keep them.'' However, the discipline is not beneficial to MNCs alone. Small organisations need it more than ever to achieve professionalism.

Any management system, to work, needs to be based on data, not intuition alone, she says. The metrics that gets into the blood of the quality-conscious is a vital force in any management endeavour, she insists.

Trend IV: CMMI

The plethora of quality standards makes it difficult for organisations to know how to go about them.

There are the SPICE, Bootstrap, Ticket models, to name a few. Of these, the European standard is increasingly being preferred, especially as it is to be integrated with the ISO standards. And also as most software companies now look to the European markets.

The Software Engineering Institute, though, reassures concerns on the plethora of standards and expects the CMMI (CMM Integration) to be an umbrella standard. ''CMM members are also on the board of the SPICE-ISO standards committee and we encourage the adoption of the CMMI,'' says Cross. The SEI will support software CMM for a couple of more years at the end of which time there is expected to be large-scale adoption of the CMMI standard, according to him.

''Although assessment methods or CMMI are still being developed, there are 33 lead appraisers for CMMI,'' Cross says. Apart from that, the SEI has licensed several organisations to provide the training required for implementing the CMMI framework.

''CMMI integrates the common elements and best features of the CMM, providing common terminology, common training and an integrated appraisal method,'' says Cross. This has come about in recognition of the tremendous need for an integrated approach for the plethora of quality standards. ''The models are exploding and becoming difficult to understand and implement.''

Trend V: Tools to instill quality culture

Though it is recognised that CMM is good for building organisational capability, lowering costs and scheduling time, and builds individual skill and discipline, it has become necessary but not sufficient.

One study, by Watts Humphrey, even found that as companies moved up the maturity curve, individual engineers worked index pendent of the organisation's maturity level. Startling though that may sound, it is not so uncommon as one could wish it to be, says Sheshagiri. ''Until individual software engineers are convinced and make a behavioural change, there is no good to be got out of the process improvement programme,'' according to Sheshagiri. ''After all, the whole point of all business activity is to make money. Until there is return on investment, there is no sense in pursuing a goal.''

For the CEO, certainly, cost savings or increased productivity will get interested listeners. ''Good managerial and engineering processes instituted in companies have brought about a productivity improvement of 39-69 per cent per developer per year,'' says Cross. ''The process improvement activities have compelling evidence.''

Agrees Sreeshaila: ''Any quality effort will succeed only if all the participants buy in, or are convinced about the imperative for process improvement.''

For individual engineers to sustain the quality effort, there is a need to build capabilities at the individual and team levels. That is where Personal Software Process (PSP) and Team Software Process (TSP) come in.

Though over six years old, these concepts have not really taken off because they are not directly related to organisational benefits, say quality experts. That is changing now as evidence comes in from their implementation in several organisations.

PSP shows engineers that process improvement can help them at an individual level as well, says Sheshagiri.

A 135-hour course, PSP is designed for individuals and based on the software capability maturity model and provides the experience of operating at Level 5.

''With PSP, engineers maintain and monitor their data themselves,'' says Cross. Whereas before the programme, engineers would have spent most of their time on writing code and testing, post-PSP, the individual's efforts are dramatically different, he says: ''Most of the time is spent on design and coding and testing takes up very little of the engineer's time. This is as it should be,'' says Cross. ''There is a need for PSP training at the university level.''

At the organisational level, process-improvement efforts are not translated into individual discipline whereas the PSP directly addresses the need for engineering methods.

Of course, one issue is convincing top management to invest in PSP training, says Sheshagiri. ''But there is convincing evidence that PSP training pays off - at both the organisational and individual level.''

Team software process (TSP) is an instance of Level 5 process for a team and is usually scheduled (as a four-day workshop) at the beginning of a project, says Cross. ''TSP is a process-framework for building and guiding engineering teams that develop software.''

The team is recognised as the single-most powerful tool for large-scale work. TSP harnesses this power by providing the benefits of disciplined teamwork; creates motivated teams that make their own plans, manage their own work and are committed to producing quality products, according to Sheshagiri.

''TSP also provides the framework for managers to guide, support and motivate disciplined teamwork.''

Watts Humphrey provides evidence that teams in companies that had not achieved any maturity level at all outperformed Level 5 teams simply because of PSP/TSP, says Sheshagiri.

Ultimately, it is the individual who will make the difference to quality. Bringing in the quality culture seems to be the challenge before the industry today.

(priya@thehindu.co.in)

(Please e-mail us at eworld@thehindu.co.in if you have queries on computer usage or if you find an interesting way of using the computer. )