EuroSPI 2000 
Practical and innovation based software process improvement to prepare for the new millenium.
European Software Process Improvement
SPI and Personal Processes
Category Index
Rated Newspaper Supported by EU Project 

 
 
 
 
 
A Tool to Support the Capture of Individual Process Data
 

Rory O’Connor, Howard Duncan
Dublin City University, Ireland

Gerry Coleman
Dundalk Institute of Technology, Ireland

Marisa Escalante, Cliona McGowan
European Software Institute, Spain

David Escala, Maurizio Morisio
Politecnico di Torino, Italy

Christophe Mercier
AFTI, France

Yingxu Wang
IVF, Sweden


 

Introduction

Software developers and managers have faced the problem of producing quality software since the beginning of the software age. Many people have studied the software quality problem and have proposed solutions, including better testing, better project planning, better practices, better programming environments and many other factors that potentially affect the development of software. We can categorize these different solutions into two groups: Firstly, solutions that focus on software development as a group effort and secondly, solutions that focus on the individual software developer. Some of the many suggestions that involve groups of software developers include: the Capability Maturity Model, clean room development, software quality assurance groups and formal technical review groups. These organisational level methods help improve the quality of the software, however they may not be enough.

Many user needs in SPI are not fully catered for through existing software process models. In particular, there is an absence of support for process improvement at the individual level, although according to a recent survey of European software organisations 83% of companies believe that SPI is essential for future success and 87% of companies believe that SPI can significantly improve software quality [1]. However time, cost and lack of knowledge are seen as the main barriers to SPI usage. In Europe to date, SPI has focused at the organisational level. As a result a number of issues have been identified in the European software industry at this level [2]:

At the personal level, the support available to the individual software engineers in performing their software engineering activities a matter of concern. This is often referred to as the Personal Software Process (PSP), a term coined by Watts Humphrey [3]. The main purpose of providing process resources at this level is [4]: The PSP has been successfully used within organisations already using SPI methods, where the culture of quality and process discipline is strong. However, it has not been so successful in smaller or less disciplined organisations. Some of the issues associated with the PSP are:
 

PIPSI Approach

The IPSSI (Improving Professional Software Skills in Europe) project [5] is an ESSI funded project which aims to provide a process improvement framework for use by individual software engineers working in European SMEs. The focus of the project is on improving individual software engineering skills thus generating bottom-up improvement. Companies can experiment with SPI by sending individuals on IPSSI training courses and then monitoring its implementation. By training individuals in this way, costs are reduced. At the heart of the IPSSI initiative is the PIPSI (Process for Improving Programming Skills in Industry) approach, whose aim is to present the techniques in a way that makes them more attractive and more easily used in small and medium-sized organisations and development teams.

PIPSI focuses on two areas of concern to the software engineer – Personal Project Management and Personal Quality Management. Both of these are supported by an estimating process and the use of appropriate metrics for measuring past success in estimating and providing a basis for future planning. Each program worked on is treated as a 'project' by the software engineer, who starts with a planning and estimating phase before starting work on the program. As the work progresses detailed metrics are kept, which are used both to monitor progress and to build up a history. These metrics are personal to the programmer at all times, and are not available to management for productivity assessment or similar purposes. The entire personal process is cyclical, success in one personal project building on success in previous projects. As software engineers become comfortable with the concepts, new and more sophisticated techniques can be introduced to improve both Project Management and Quality Management.

PIPSI is built around the following key concepts:

The focus of PIPSI is on bottom-up process improvement. Figure 1 illustrates the three elements of personal software engineering - defining a personal process, personal project management and personal quality management.

Fig.1 : PIPSI Structure

The entire model is buttressed and controlled through the use of measurement. By collecting data on their own performance, software engineers learn about how they develop software. The measures help them understand the fundamental relationship between size and effort and, through this understanding, enable them to improve their estimating abilities. Furthermore, by gathering data on their defect rates they witness how using practices such as personal code reviews and the use of checklists will allow them to produce higher-quality software products. The measures provide information on performance, information can then lead to process improvement and process improvement can lead to the production of better quality software on time. Finally collecting performance data continuously moves developers from defining their own development process, through managing it to optimising it.

Through PIPSI training, developers complete programming tasks on which they collect increasing quantities of data. Early exercises capture effort measures. Subsequent exercises gather size data whilst the concluding exercises capture defect and quality measures. This is hugely empowering for both the programmer and the organisation as a whole. Programmers are now in a position where they can provide the project manager with achievable deadlines and the project manager can develop more accurate and predictable delivery schedules. The final element of PIPSI is that of personal quality management. As developers complete PIPSI program using exercises, they collect data on the defects injected into those programs. This process illustrates in which development phases they inject and remove defects. Furthermore, the defects are categorised by type thus allowing a causal analysis to be performed which can then lead to defect prevention. PIPSI focuses on proven quality control mechanisms such as design and code reviews which enable developers to remove defects earlier in the development process. This achieves the twin objectives of removing defects at the front end of the development cycle where they are cheaper and easier to fix and, as a corollary, means testing time is more focused as fewer defects are escaping into test.

This process information highlights the developers strengths and weaknesses and empowers them to make the necessary process improvement adjustments. We believe the provision of such a tool will ensure the ‘buy-in’ of training participants and subsequent continued usage of the PIPSI disciplines.
 
 

PIPSI Support Tool

Empirically based process improvement frameworks such as PSP and PIPSI focus on the individual software engineer and require them to record data about time spent programming, the defects they find in their software and size of the software, etc. The PSP as described by Humphrey is a manual process. The engineer records, transfers and analyses he data all on paper forms. After many projects, the engineer accumulates a large paper database of their historical data.

Feedback from PSP training programmes in Ireland [6] has suggested that the absence of a support tool, to simplify the recording and analysis of the data produced is one of the major barriers to continued usage of the methods. Developers tire of recording data on paper forms and eventually usage of the disciplines peters out. There is also corroborating evidence from the USA. For example, [7] and [8] report on experiences of a two year PSP study which questioned the quality of the data recorded. They found that there was significant data quality issues with manual PSP, for example, not all defects were recorded because the overhead in recording was too expensive.

These experiences and observations from the PSP, lead the IPSSI project consortium to consider designing an automated, empirically based personal process improvement tool to support the data collection and analysis requirements of the PIPSI approach to process improvement. Therefore as part of the IPSSI project, a tool set, which consists of data gathering and data analysis tools for use in a web-based environment, has been developed. The main requirements of this tool were that it enables measures to be collected as a simple complement to the development process and provides for analyses of the data collected to provide the developer with important process feedback.

The PIPSI tool was developed in order to support the individual developer using the PIPSI approach and is designed to support two main functions (as illustrated in figure 2): Data Capture - simple and easy recording of data such as time, size and defects, and Data Analysis - automatic analysis of collected data to generate aggregate project data in textual and graphical form. In addition, there were also a number of constraints placed on the development of the tool:

Fig.2 : PIPSI Tool Usage

The PIPSI model follows the three elements of personal software engineering; defining a personal process, personal project management and personal quality management. These are represented in the tool by three main levels:


 

Tool Design and Implementation

The tool was designed with a view to having three possible configurations in terms of which component(s) may be installed on which host machine. The three typical configurations which are envisaged are: The architecture of the tool is shown in figure 3. The user interface, which operates within a standard web browser and provides facilities for data gathering, analysis and submission to a local database. Upon completion of a project, the user may choose to anonymously submit their data to a central database where aggregate data can be further collected and analysed.

Fig.3 : PIPSI Tool Architecture

The PIPSI support tool was implemented using Active Server Pages which interact with a database system. This provides for a light weight implementation which facilitated the three configurations described above and also provided a flexible approach to system implementation.

The web pages of the system are a code mix of VBScript and standard HTML. The VBScript of the requested web active server page is interpreted by the web server, which generates HTML code which in turn is sent to the clients browser and is displayed like a pure HTML page. The underlying PIPSI data is held in a standard Microsoft Access 2000 database , which is accessed by the Active Server Pages via ODBC connection to the database.

In addition to the design considerations previously described, was the issue of localization of the user interface in terms of the language which is presented on the web browser (user interface). This issues was approached by allowing the user (software developer) to choose at tool startup which language they wished to work in. The text of the user interface is held in a series of files from which the Active Server Pages extract the text to be displayed. Currently the system supports the following languages: English, French, Spanish, Dutch, German, Italian, Swedish, Danish, Finnish, Greek and Portuguese.
 
 

Current Status

The PIPSI training programme has been developed in a highly iterative manner by a consortium of both academic and commercial organisations. Initially a set of PIPSI programme trials have been conducted using both academic and industrial participants. The objectives of the initial PIPSI trials [9] using undergraduate students were twofold. Firstly, to teach them the benefits of having a defined and measurable software process and secondly to get some preliminary feedback on the PIPSI training programme. All of the graduates commented favorably on the approaches taken. Comments ranged from "It's something I'd never thought of before", to "Prior to this I had no knowledge of where I was spending my time" to "Up to now I have been a 'hacker' who started coding as early as possible. I have now started to concentrate more of my effort in design and I can already see the benefits". Whilst the results from the study may not readily show this, the study group are now adopting a much more professional approach to developing software and have been convinced of the benefits of following a defined process. These trials also provided the necessary feedback on the PIPSI training material which was used in the evolution of the training programme. A second set of trials were conducted using a small group of industrial participants. The primary objective of these trials was to validate both the structure and content of the PIPSI training programme prior to a commercial launch of PIPSI.

Currently the IPSSI consortium is in the process of running a series of PIPSI training courses in several European locations. These courses are a full commercial version of the PIPISI course and are being attended by industrial participants from an number of European SMEs. To date these courses have taken place in Dublin (Ireland), Bilbao (Spain) and Turin and Milan (Italy), with a number of other PIPSI courses currently planned. The PIPSI support tool has been used during these courses and has gathered a set of PIPSI data which is currently being analysed by the IPSSI project consortium.

However, there are two factors which will permit a more complete and effective evaluation of PIPSI. Firstly, if PIPSI is to succeed, it must be applied in an industrial context. The training and the disciplines are designed to allow individuals and companies achieve meaningful software process improvement. The ultimate benefits should accrue when the skills acquired in training are applied by the practitioners in their workplace and it is this which will truly test the value of PIPSI. Secondly, when the initial set of commercial courses are completed, a larger amount of data will be available for study. As these courses are aimed at industrial practitioners, it is expected that motivation and completion rates will be significantly higher than the voluntary trials which have taken place to date.

Improving the quality of software products is a very important goal for both companies and developers. Ultimately, it is through applying PIPSI disciplines in their own daily work that developers can become convinced of its benefits.
 
 

Acknowledgments

This research was supported by the European Commission as ESSI project 27453.

The authors gratefully acknowledge the value gained from discussions regarding this work with their colleagues and research partners: AFTI (France), Dublin City University (Ireland), European Software Institute (Spain), Politecnico di Torino (Italy) and IVF (Sweden). More information about the IPSSI project is available from: http://www.compapp.dcu.ie/ipssi/ipssi.html
 
 

References

[1] "The SPIRE Handbook", Centre for Software Engineering, Ireland, 1998.

[2] Y.Wang, H.Duncan, M.Kartinnen, H.Sjostrom and P.Kokeritz, „IPSSI - A European Methodology on PSP“, Proceedings EuroSPI-99, Finland, 1999.

[3] W.Humphrey, „Introduction to the Personal Software Process“. Addison Wesley, 1997.

[4] S.Zahran, „Software Process Improvement - Practical Guidelines for Business Success“, Addison Wesley, 1998.

[5] http://www.compapp.dcu.ie/ipssi/ipssi.html

[6] P.O'Beirne and J.Sanders, „Personal Software Process: Does the PSP Deliver its promise?“, Proceedings of Inspire ‘97, Gothenburg, Sweden, 1997.

[7] A.Disney and P.Johnson, „Investigating data quality problems in the PSP“, Proceedings of the ACM SIGSOFT Sixth International Symposium on the Foundations of Software Engineering, Florida, USA, 1998.

[8] C.Moore, „Personal Process Improvement for the Differently Disciplined“, Proceedings of the International Conference on Software Engineering, Los Angeles, USA, 1999.

[9] G.Coleman and R.O'Connor, „Power to the Programmer“, In Proceedings of 11th European Software Control and Metrics conference, Germany, 2000.
 



 
Partners in EuroSPI

Editors
ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and Coordination Office, Florence House, 1 Florence Villas, Bray, Ireland, office@iscn.at, office@iscn.com, office@iscn.ie, Editing Done: 19.7.2002