• 
• 
  • Our Mission
  • History
  • Who's involved
  • SEI Partner
• 
  • What is CMMI?
  • Why CMMI?
  • CMMI Pilot in SA
  • Preparing for Export
• 
• 
  • The Partner Programme
  • Current partners
  • The Benefits of Partnership
  • Menu of Activities
  • Application
• 
• 
  • Agile Forum
  • Software Architecture Forum
  • Online forum
  • SPIN Forum
• 
  • Programme Overview
  • Scholar Programme
  • Intern Programme
  • CoachLab@JCSE 2010
  • Pre-Incubator
• 
• 
• 
  • Event Registrations
  • Course Applications
  • CPD Application
  • Partner Application
  • Pre-incubator Application
• 
  • Contact details
  • General Queries
  • Newsletter Signup

Putting an end to IT project disasters

5 May 2010

Article published in Engineer IT

by Prof. Barry Dwolatzky, JCSE, Wits University

Oh no - not another information technology disaster! As lawyers on both sides sharpen their pencils, the future of another major South African IT project hangs in the balance.

The Department of Home Affairs has informed Gijima AST that it is terminating a R4,4-billion contract to implement a new state-of-the-art identity verification system called "Who am I online". Home Affairs director general, Mkuseli Apleni, cited "failure to perform" as one of the reasons for this drastic step. While the details of this specific project remain to be discovered, the apparent failure of another large and complex software project should not be too surprising to those of us working in the IT sector.

More than forty years ago organisations involved in the procurement of large software development projects noticed that many were delivered late, over-budget and with large numbers of "bugs". Some projects were not completed at all. The search to find a solution to what has been called the "Software Crisis" started in 1968 when a conference sponsored by NATO in Garmisch, Germany, coined the phrase "software engineering". In the years that followed substantial progress has been made, but the situation still remains rather depressing. The Standish Group's "Chaos Report" and other studies provide evidence that a large software project is likely to:

• Be delivered between 27 and 112% late
• End up costing between 17 and 85% more than the original budget
• Be delivered with between 1 and 7 defects per 1000 lines of source code.

Furthermore about 25% of projects are abandoned before they are completed at an annual cost of tens of billions of dollars.

Imagine a world where... large software systems are delivered without any defects at all (i.e. "bug"-free), on time and within budget. Finding a way to achieve this seemingly straight-forward objective gave rise to the discipline of "software engineering" in the late 1960s and remains the holy grail for anyone involved in either the procurement or delivery of software today.

Back row: Prof. Barry Dwolatzky (JCSE)], Jim Over (SEI, USA),
Prof. Johnson Kinyua (Central University of Technology, Bloemfontein) Rafael Salazar (Tec de Monterrey, Mexico), Watts Humphrey (SEI, USA). Front row: Francina Botha [Nedbank), Fernando Jaimes (Tec de Monterrey, Mexico).  

 Process maturity as the solution to the software crisis

Some believe that the solution to the software crisis is to be found in the adoption of processes that support the acquisition, development, delivery and operation of software. Concepts of "process" and "process maturity" lie at the heart of the very successful and well-established quality movement in manufacturing, construction and many branches of engineering. In the late 1980s Watts Humphrey, who had recently retired as IBM's V-P Software, joined the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh and set about developing a process maturity model for software. The "Software Capability Maturity Model" (CMM-SW) and then the "Capability Maturity Model Integration" (CMMI) grew out of Humphrey's work at the SEI.

Using CMMI many software development organisations have significantly reduced the risks associated with software development. For example, Tata Consultancy Services (TCS), one of India's major IT companies, is rated at the highest CMMI level (maturity level 5). TCS has been able to deliver 96% of its large IT projects on time, and within 3,2% of allocated budget. Their quality is also very good - around 1 defect per 1000 lines of code. Process improvement based on CMMI certainly benefits organisations that have been disciplined enough to adopt this framework.

There is, however, an important dimension of process improvement that is not covered by capability maturity models. This was identified in the late 1990s by Watts Humphrey after several years of working with organisations that were implementing CMM-SW. Humphrey noted that while there was a huge difference between "low maturity" and "high maturity" organisations, the way that individual software developers worked was very similar. He decided to develop a methodology that would allow an individual programmer to work in a "high maturity" way. He called this methodology the "Personal Software Process" or PSP.

While CMMI is a framework that supports process improvement within and organisation from the top-down, PSP drives improvement from the bottom-up. Humphrey found that there was also a need to define a "process framework" at the organisational level between individuals using PSP and the organisation as a whole. He defined the "Team Software Process", or TSP, to occupy this "middle layer".

PSP and TSP

The two key elements of PSP are "process" and "measurement". Each PSP developer carries out his or her work using a process - a sequence of steps carried out to achieve the task of writing a program. As the name implies this process is "personal" - the programmer defines - and then continuously improves - his/her own way of developing a program. Measurement is coupled with this personal process. The programmer collects base data associated with his/her process including time, defects, and the size of programs and program parts. Other measures - such as productivity - can be derived from these base measures.

TSP is used when a team of PSP programmers work together on a project. TSP requires a "coach" - a person trained to assist team members in sticking to and improving both their PSP and TSP processes. Data is collected at the project level and is used to monitor progress and estimate size and effort.

As TSP and PSP adoption has spread around the world data are being collected and shared that tell a very exciting story. TSP teams are reporting that projects are being delivered within 10% of schedule and 5% of budget. While this level of improved performance matches what has been achieved by companies reaching high maturity levels using CMMI, the improvements associated with TSP are achieved within a few months of initial adoption rather than several years as is the case with CMMI.

There is also another aspect of TSP adoption that has provided truly remarkable results. This is in relation to quality. Defect rates between zero and 0,2 defects per 1000 lines of code are being regularly achieved - this is more that ten times better than the best industry benchmark figures!

Towards TSP adoption in South Africa

In 2008 the Joburg Centre for Software Engineering (JCSE) at Wits University led a study tour to Mexico and the USA to meet with some of the companies developing software using TSP. These companies included Intuit (developers of the QuickBooks accounting software), Adobe and Softech (Mexico's largest software company). The delegation also met with Watts Humphrey and his team of TSP experts from the SEI. Information collected on this study tour convinced us that it would be valuable to promote the adoption of TSP in South Africa.

In July 2009 a TSP Adoption pilot programme was launched in South Africa by the JCSE. Participants in the pilot are the JCSE, Nedbank's Group Technology division, Dariel Solutions (a medium-sized software development company), the Central University of Technology (in Bloemfontein) and the SEI. The Department of Trade and Industry provided funding to cover the training of local TSP and PSP experts.

The TSP Pilot programme is nearing its conclusion. The results have been extremely encouraging. The following is a summarised list of what has been achieved and learnt in the pilot:

• Four teams of software developers have been trained to use PSP and TSP. Three of the teams are from Nedbank and one from Dariel Solutions. The size of the teams is between five and twelve developers. Each team has completed - or will soon be completing - their first development project using PSP and TSP.
• Results achieved in terms of quality, budget and schedule are encouraging in each case. One of the teams has achieved a significant reduction in the number of defects, reporting that zero defects were found during system testing. In all cases team members and their management are enthusiastic about PSP and TSP and are eager to continue using these methodologies.
• Using the pilot as a training ground the SEI has now trained a number of local PSP instructors and TSP coaches. The JCSE has entered into a partnership with the SEI that will allow the JCSE to begin delivering official PSP and TSP training and coaching in South Africa via these local experts. The SEI will continue working with the JCSE to support TSP adoption and to train additional experts.
• Like any pilot programme the TSP adoption pilot has not proceeded completely smoothly. There have been a number of lessons learnt in relation to the types of projects and individuals that lend themselves well to successful TSP adoption. These lessons are being analysed by the JCSE and will be used to ensure smoother adoption in the future.

Future plans

The JCSE is currently planning to carry out further TSP pilot projects. The development teams already trained will run additional projects using TSP. The intention is also to find two additional pilot companies - one in each of KwaZulu-Natal and the Western Cape. Two teams will be trained at each of these companies and additional instructors and coaches will be trained with support from the SEI. Funding is being sought to cover some of the costs of this - the second phase of the TSP adoption pilot.

While there is still a need to run further projects and collect more data, there are already strong indications that TSP adoption in South Africa will lead to the same benefits achieved elsewhere in the world. We at the JCSE believe strongly that the combination of TSP and CMMI will make a dramatic improvement in the ability of software developers in South Africa to deliver development projects on time, within budget and with low numbers of defects. Hopefully future attempts to deliver ambitious projects like "Who am I online" will not end up in the courts because of a failure to perform.

Contact Prof. Barry Dwolatzky, JCSE, University of the Witwatersrand,
Tel  011 717-6390 , barry.dwolatzky@wits.ac.za
Posted date: Wednesday, May 05, 2010 - 08:41 AM