Open Access Open Access  Restricted Access Subscription Access

TSP (Team Software Process)


 

As quoted by the CIO journal December 2003 issue, “By the numbers available, the software quality stinks.”  The Standish Group reported in 1999 that 74% of all projects were not successful.

According to a survey by Standish Group in 2002, only 34 % of the software development is successful. Around 38 billion US dollars are lost every annum due to software failure  and one of the major reasons for this high failure rate is poor software quality. Typical software projects are often late, over budget, of poor quality, and difficult to track. Engineers often have unrealistic schedules dictated to them and are kept in the dark as to the business objectives and customer needs. They are required to use imposed processes, tools, and standards, and often take shortcuts to meet schedule pressures. Very few teams can consistently be successful in this environment. As software systems get larger and more complex, these problems only get worse. The best projects are an artful balance of conflicting forces. To balance these conflicting forces, teams must understand the complete context for their projects.


User
Notifications
Font Size

Abstract Views: 114

PDF Views: 2




  • TSP (Team Software Process)

Abstract Views: 114  |  PDF Views: 2

Authors

Abstract


As quoted by the CIO journal December 2003 issue, “By the numbers available, the software quality stinks.”  The Standish Group reported in 1999 that 74% of all projects were not successful.

According to a survey by Standish Group in 2002, only 34 % of the software development is successful. Around 38 billion US dollars are lost every annum due to software failure  and one of the major reasons for this high failure rate is poor software quality. Typical software projects are often late, over budget, of poor quality, and difficult to track. Engineers often have unrealistic schedules dictated to them and are kept in the dark as to the business objectives and customer needs. They are required to use imposed processes, tools, and standards, and often take shortcuts to meet schedule pressures. Very few teams can consistently be successful in this environment. As software systems get larger and more complex, these problems only get worse. The best projects are an artful balance of conflicting forces. To balance these conflicting forces, teams must understand the complete context for their projects.