APIS - A Web-based System for PSP/TSP

Chenyi Zhuang, Jingyi Li, Guoping Rong and Dong Shao

Software Institute of Nanjing University, Nanjing, China

Abstract. A useful supporting tool is very important to the success of PSP/TSP

adoption. Based upon our experience, we summarize the requirements of a

useful PSP/TSP supporting tool as follows: 1) support all phases of the

PSP/TSP completely; 2) record and use historical data easily; 3) support

teamwork effectively; and 4) provide team data in real time, enabling the

PSP/TSP coach to see the process data at any time. In this paper, we propose a

web-based PSP/TSP supporting tool, APIS (Advanced Process Improvement

Solution). This tool meets all of the requirements stated above. APIS was

deployed in SaaS (Software as a Service) manner, and users can rent software

through the Internet. APIS has been used in more than thirty projects, and we

have received a lot of positive feedback.

1 Introduction

Tools are playing an important role in PSP/TSP [1], [2], especially for process

improvement. The successful application of tools in Mexico is a good example. In

their report [3], there is a table which shows the quality comparison between

CMU/SEI projects, Typical Projects and Mexican Phase I Projects. The quality of

these projects has been improved.

In the last three years, the Software Institute of Nanjing University experimented

with a new education approach to improve software development process. This

initiative applies a well-defined and measurable process called the PSP/TSP [4, 5],

which has been practiced by many top software development organizations. The

objectives of our approach are listed below:

 Provide developers with process material which will help them to understand and

learn a disciplined approach in the development of software easily;

 Engage developers in teams in which they can communicate and co-operate

effectively;

 Provide PSP/TSP coach with process data to supervise a software development

team.

To achieve these objectives, we listed a number of tasks in this approach. Among

them, the major tasks are collecting, managing, and analyzing the process data.

Another task is to support teamwork effectively. We need a process supporting tool to

coordinate these tasks.

The remainder of this paper is organized as follows. Section 2 explains why we

develop APIS. Section 3 describes how the APIS can support PSP/TSP. Section 4

Zhuang C., Li J., Rong G. and Shao D..

APIS - A Web-based System for PSP/TSP.

DOI: 10.5220/0003579700680074

In Proceeding of the 1st International Workshop on Evidential Assessment of Software Technologies (EAST-2011), pages 68-74

ISBN: 978-989-8425-58-4

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

provides an overview of possible future enhancements of APIS. Section 5 is the

conclusion.

2 Goals for APIS

Since the PSP/TSP has been recognized by the software development industry as an

effective way in teaching software engineers a disciplined engineering method [6], we

have experimented with integrating TSP/PSP into our new education approach.

The results of a survey conducted at the end of each semester have shown that the

process support tool, SEI PSP Workbook, has several weaknesses: 1) it can’t save

historical data; 2) it is a stand-alone version which can’t support teamwork

effectively; 3) coach can’t see the real-time process data. Based on our 4 criteria

(Table 1), we also evaluated three popular PSP/TSP supporting tools and the findings

are provided below.

Table 1. Comparison between different PSP/TSP tools.

Tools→

Team Dashboard [7] Point [8] TSPi Workbook

Our Criteria↓

Support all phases

completely

Partially Partially

Yes (cover all forms

provided by SEI)

Record and use

historical data easily

Yes (need expertise in

PSP/TSP)

Nominal (convert an Excel

file to web based tool using

relational database)

Minimal (a programmed

Excel file)

Support teamwork

effectively

Yes

Minimal (support multi

projects)

Provide team data in

real time

Minimal Yes No

Although these tools have their own features, they can’t fully meet our 4

requirements. Therefore, we proposed to develop our own PSP/TSP supporting tool.

3 A Practical Tool for Process Management

3.1 Support All Phases

Developers should make many plans (schedule plan, risk plan, quality plan and so on)

in the TSP launch phase. APIS can guide developers to make each plan mentioned

above. For example, when a team wants to make a schedule plan, all that developers

need input are each developer’s weekly working time and each task’s total hours

which can be estimated by using PROBE method. According to the hierarchy in

project’s tasks, Developers can customize a schedule plan using APIS (Figure 1).

Fig. 1. A Schedule Plan.

In a TSP team, everyone plays a different role and has his own responsibility.

Take plan manager as an example, he should develop complete team plans and

individual plans. At the end of each week, he will report the progress of the project. In

general, there are six roles in a TSP team [1, 2]: Project Manager, Plan Manager,

Development Manager, Quality Manager, Process Manager and Support Manager. AS

a TSP supporting tool, APIS has authority management and make every member

focus on his own responsibility.

In order to ensure the quality of software and improve the development process in

the next project, APIS also integrate almost all of the templates, scripts and quality

indicators in PSP. It is especially useful for new users, because they can just follow

these scripts to record data in templates and needn’t worry about missing any data.

At last, APIS has three different ways to track a project during the development

time. They are Weekly Report [2], PV&EV [2] and Milestone. Milestone uses goal-

driven method based on a hypothesis that: if all the goals are finished [9], the project

is completed.

3.2 Data Reuse

How to use historical process data is a general problem. APIS tried to improve the

accuracy of making plan at the beginning of a project. APIS records previous

projects’ risks and strategies as a repository. When developers meet a same problem

in a new project, they can refer to this repository and find corresponding answers

easily. APIS also has statistical module, and based on more history data, we can make

a more accurate estimate for new projects. We expect to utilize previous projects’

experience to offer a better service for the next project.

3.3 Support Teamwork Effectively

The goal of the development of APIS is to provide a shared tool for PSP/TSP data

repository and analysis used by both the academic and industrial communities. Now,

World-Wide Web (WWW) has been the most popular Internet access mechanism

used by people around the world. Web-browser is all that is required to access the

Web server. Therefore, the users’ burden with incompatible software can be reduced.

APIS uses a relational database to manage multi projects and team data centrally.

Figure 2 shows the directory hierarchy of our TSP database server. It was divided into

4 subdirectories (Projects, Resource, Repository, and Logs). In the Projects Directory,

there are the each project’s process data and staffs’ information; Resource Directory

records many templates and scripts to guide new users; Repository Directory records

projects’ strategies and risks; And the last Logs Directory records system log.

Through the Internet, users can receive timely information about each team. The TSP

database server was implemented by SaaS multi-tenant model. To secure the process

data, we choose the strategy of independent database. In other words, one tenant

corresponds to one database. It simplifies the extension of the design of data model

and can meet different tenants’ unique demands.

Fig. 2. Directory Hierarchy of TSP Database Server.

3.4 Timeliness

A Web-based tool provides developers real-time team data. Once a developer submits

his process data, another team member can see the update on his own computer. In

APIS’s authority management, there is a role called “coach”. Coach has a super

permission which can refer to all the process data (Figure 3) about a development

team, and supervise his team. The red curve stands for the cumulative PV (Plan

Value), while the blue one stands for the cumulative EV (Earn Value). If the blue line

is above the red one, it indicates that the project schedule is ahead. Inversely, if the

blue line is under the red line, we should implement several measures to catch up the

schedule.

Fig. 3. PV&EV of a Task.

4 Discussion

Figure 4 shows the quality improvement of 11 teaching projects counted by APIS,

from which we can find that APIS has actually improved the quality of software

development.

Fig. 4. Build and Integration Defect Density.

4.1 A Survey

For some commercial reasons, we did a survey between students and teachers among

whom some of them were familiar with PSP/TSP and the others were not before using

this tool. There are about 100 people from more than 20 different projects who have

participated in this survey. According to previous users’ feedback, we enumerate

some of the most popular topics:

a) Need expertise in PSP&TSP before using APIS

b) Under pressure by using the allocation of responsibilities

c) Not used to record data when I was developing

d) Can’t adapt to the style of APIS’s interface

Participants only need to select the topics they concerned according to their

experience of using APIS. Figure 5 shows a statistical result. Topic A is the most

common problem followed by C, D, and B.

According to the feedback from students and teachers, some deficiencies of the

tool were also pointed out. Therefore, in the future, we will make some enhancements

to APIS. For topic B, it is a promoted efficient way to organize a team in TSP, so we

will not have any changes on it temporarily. However, for the other three topics, there

are now three ongoing TSP related activities conducted by our maintenance team.

They are briefly described as follow:

 Manually input or automatically record process data. Up to now, developers

should manually input individual process data. If we set a clock cycle or triggers to

achieve process data automatically, developer would be under the pressure of the

passage of time. To collect real time data, they even can’t take a break while

developing software. If there is a switch to close the clock, there are no differences

between these two ways. We should investigate more process supporting tools and

discuss whether it is a good advice.

 Continue to reduce the burden of studying PSP/TSP. According to Nielsen’s

usability heuristics [10], we will try to reduce users’ burden of memory and provide

more help information. Any such information should be easy to search, be focused on

the user’s task, list concrete steps to be carried out, and not be too large.

 With more and more projects are using APIS, we should extend the web server’s

response ability. At the same time, database server will record much more data.

In the future, we want to add functions about process simulation and modeling [11].

APIS have collected more than 30 projects. In others words, we now have collected

many process data. How to fully utilize these resources to help the next project is a

good question. Up to now, APIS has not integrated any mathematical models to help

process simulation and modeling. Therefore, it will be a good trial.

Fig. 5. The Statistics Result.

5 Conclusions

Based on the experience in teaching TSP/PSP and using supporting tools, we

summarized 4 important requirements for a useful TSP/PSP supporting tool. After an

investigation into the available supporting tools, however, we find out that those tools

can’t fully meet our 4 requirements. Therefore, we develop our own supporting tool—

APIS, which is a web-based tool and can fully meet our 4 requirements.

Until now, APIS has been used in more than 30 projects, among which some

projects are from the industry and others are from academia. We have received a lot

of positive feedback as well as useful suggestions. In the future, we will make some

enhancements to the tool, so as to better support TSP/PSP.

References

1. Watts S. Humphrey, 1999. Introduction to the Team Software Process. Addison-Wesley

Longman Ltd., Essex, UK, UK.

2. Watts S. Humphrey. TSP: Coaching Development Teams, Addison-Wesley, ISBN

0201731134, 2000.

3. Nichols, W., & Salazar, R. (2009). Deploying TSP on a National Scale: An Experience

Report from Pilot Projects in Mexico, (March). Retrieved from

http://192.58.107.83/reports/09tr011.pdf.

4. Casallas, R., Osorio, L. A., Lozano, A.,” The challenge of teaching a software engineering

first course”, Proceedings of the fifth international workshop on Active Learning in

Engineering, Delft-Amsterdam, The Netherlands 2005.

5. Dieter Rombach, Jurgen Munch, Alexis Ocampo, Watts S. Humphrey, Dan Burton;

“Teaching disciplined software development”, The Journal of Systems and Software, Issue:

81 (2008), pp 747–763.

6. S. Macke, etc. An Industry/Academic Partnership that Worked: An In progress Report.

Proceedings of the Ninth Conference on Software Engineering Education, pages 234-245,

1996.

7. http://www.processdash.com/

8. http://dogbert.mse.cs.cmu.edu/mse2004korea/projects/point/index.html.

9. 2002. Project Management Institute-Practice Standard for Work Breakdown Structures.

Project Management Institute.

10. Nielsen, J. (1994). Enhancing the explanatory power of usability heuristics. Conference

companion on Human factors in computing systems - CHI ’94, 210. New York, New York,

USA: ACM Press. doi: 10.1145/259963.260333.

11. He Zhang, Kitchenham, B., Pfahl, D., "Software Process Simulation Modeling: Facts,

Trends and Directions, "Software Engineering Conference, 2008. APSEC '08. 15th Asia-

Pacific, vol., no., pp.59-66, 3-5 Dec. 2008 doi: 10.1109/APSEC.2008.50.