Adapting the PSP to an SME context
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Adapting the PSP to an SME context
Massimo Capra
FIDIA s.p.a.
Corso Lombardia 11, I - 10099 San Mauro Torinese, Italy
David Escala
Facultat d’Informàtica de Barcelona
Universitat Politècnica de Catalunya UPC
C/ Jordi Girona, 1-3, 08034 Barcelona, Spain
Maurizio Morisio
Dipartimento di Automatica e Informatica
Politecnico di Torino
Corso Duca degli Abruzzi, 24, 10129 Torino, Italy
Abstract
This paper describes how the PSP (Personal Software Process) defined by Watts Humphrey, and specifically the PSP0, has
been adapted to be applied in the same way by all members of a software development team in a SME (Small Medium
Enterprise).
The adaptation allows each member to collect the same measures and use the same process. Therefore measures can be
aggregated at the team level, on an anonymous basis.
While final results regarding variations in quality and productivity due to the PSP are not yet available, the experiment
demonstrates that the PSP is a superior tool to rationalize the process in SMEs or small teams, gaining active
participation of the staff.
Keywords: PSP, Personal Software Process, Software process measurement.
1 Motivation and context
The work we describe is part of a Software Process Improvement effort being performed in, FIDIA s.p.a., an
SME that produces numerical controls (NC) competing in the world NC market with large corporations. To
succeed in this competition Fidia offers to its customers products which have to be technically very advanced.
Moreover Fidia has to offer the flexibility not provided by large corporations. This means capability of offering
new functionalities or adapting existing ones to fit the need of the customer, in short time and with a similar
reliability.
Software is a strategic factor in NC production:
• a machine tool costs approximately ten times its NC and the software is only a part of the NC cost, but can
be a non easily debuggable source of problems
• flexibility in reacting to the requests of customers means high modifiability of software
• the lifecycle of a NC is in the order of years, making maintenance the dominant cost factor for software.
Maintenance has two aspects: evolutive, made constantly in-house; corrective, often made on the customer’s
site. Being FIDIA’s customers distributed all over the world, corrective maintenance has very high costs, either
for travelling or for long telephone conversations. Moreover it can take a significant percentage of working
time from new developments and evolutive maintenance. That means fewer resources dedicated to new
functionalities and to the development of new products, consequently a longer time to market.
Since NCs depend more and more on software, and software is a critical factor (probably the most critical
factor) in reaching the above objectives, FIDIA is involved in a software process improvement program. This
program has brought to the introduction of ISO 9000 procedures in the company and to the participation in
1other ESSI projects. The overall goal of the software process improvement plan is to increase the reliability of
the software developed, to increase productivity and to lower time to market.
The analysis of the previous improvement efforts, such as the introduction of analysis methods and code
reviews, reveals that the pivotal point in the adoption of the two technologies was the acceptance of the
technology by people, and not the technology itself. In other words people with a positive attitude towards the
new technology used it effectively, people with a negative attitude used it not effectively, or did not use it at all.
For instance in experimenting code inspections we observed that only those software reviewers who expressed
interest for the method were really able to discover errors, while the others, who appeared less interested or
more skeptic, systematically obtained worse results. It was very difficult to evaluate if the method in itself was
good or not because it appeared mainly depending on the degree of acceptance by the reviewers.
We conclude that significant improvement in software quality will be only possible if each software engineer
really wants to achieve it.
Therefore the main goals of the company as regards SPI are:
• to motivate software engineers to improve software quality
• to provide them with means for continuous, individual assessments (instead of company level, exceptional
assessments)
• to put each software engineer in a kind of competition with himself and his previous results
• to give to each software engineer a disciplined personal process, partially defined by himself and fitting his
needs.
The above objectives are perfectly fit by Watt Humphrey’s PSP, so the company decided to try experimenting
the PSP in one of his groups. Six software development groups do software development for NC systems, each
one having from four to six software engineers. The languages used are C, C++, Assembler, the platforms are
Windows NT, Windows95, Motorola and Intel based boards.
2 Why adapting the PSP
It is well known that the PSP is a set of techniques plus a training program to learn these techniques and the
habit of applying them (Humphrey 1995, Humphrey 1997). Papers in literature report mostly about the effects
of using the PSP during the training period, either in University settings (Humphrey 1995, Humphrey 1996), or
in industrial context (El Emam et al. 1996). Extremely positive effects of using the PSP in industrial practice
are reported in (Ferguson et al. 1997). Uses of the PSP in industrial context usually consist of: 1) teaching the
PSP to the staff, with hands-on application on the exercises coming with the book; 2) using the PSP as is, in
daily work. In our context it was necessary to adapt the PSP and the approach to adopt it. A similar approach
was used by (Jahnke et al. 1997). The rationales are explained below.
• The PSP in the context of a team. In Fidia the need of applying the PSP in a coordinated way for all the
members of the team was clear from the beginning. First, senior managers agreed only in using a PSP
adapted to the company needs, and did not agree to adapt the company to the PSP. Second, a PSP adapted
and coordinated for a team allows aggregating measures on a team level. This gives useful information
about the team process, and not only about the individual process. On the other hand it allows the team to
share a common process and a common process vocabulary, therefore easing communication, avoiding
misunderstandings and promoting collaboration. Also, if the PSP is not integrated in the company/team
process, some activities (such as collection of failure reports) are duplicated, with obvious negative effect
on the willingness of the staff to use the PSP. This very same issue is called by Watts Humphrey TSP
(Team Software Process) and is one of the topics of his current research.
• Privacy of data. The PSP is based on the collection of very detailed and personal measures. The access to
these measures from managers frightens the engineers, and in some countries breaks specific trade union
regulations. On the other hand personal data, aggregated at a team level, are essential to monitor the
performance of the project. A solution to this problem has to be found, to guarantee personal data privacy
while providing team level data availability.
• Maintenance process. The original PSP uses a number of exercises, or small projects, assuming a process
dedicated to new developments. In the case of Fidia the team deals with corrective and evolutivemaintenance on a product. The process and some measures have to be adapted accordingly.
• Training. In the SEI approach the training for the PSP consists of a 10 days course. This course uses
academic exercises to teach the techniques and build the initial baseline of measures. While the rationale of
this approach is clear, teach not only techniques but also a programming habit in a protected environment,
it has serious drawbacks for companies, and especially for SMEs. A small team responsible of a
commercial product cannot loose all its members for such a long, continuous period. On the other hand, if
one person follows the training at a time, the training delay becomes unacceptable. Moreover, the simple
academic exercises of the PSP training do not motivate experienced engineers.
• Granularity of the effort time scale. The PSP proposes to record effort with a minute grained time scale,
recording all interruptions. This is very demanding for engineers. In some cases the task of recording
interruptions generates new interruptions that disturb the engineer. A solution to this problem could be
obtained using a program for automatic time tracking.
• Automation of data collection and analysis. The collection of data (effort and defects) and the
computation of measures for the PSP are repetitive and cumbersome. A tool is needed to support it. There
are tools that support the data recollection of the “pure PSP” but, in this case, a new tool is needed. Now
the PSP is implemented in the context of a team: there are many important aspects of the process that
should also be measured (and are not measured in the PSP) and the team nature of the data implies a
redesign of the database structure.
3 Adapting the PSP
We describe below the main issues in adapting the PSP to the context of Fidia.
3.1 Training
The training consists of 3 sessions, one per PSP level. The schedule of the sessions is one every 2 or 3 months.
The PSP0 is introduced while the team works on its usual project and not using the academic exercises. Then,
the data obtained using the PSP0 are used as the baseline and the effects of introducing the next levels of the
PSP (that is PSP1 and PSP2) are verified against that baseline.
3.2 The Team PSP
Adaptation method
An essential appeal of the PSP is the fact that it is personal. On the other hand a team cannot allow completely
independent processes at the individual level. To solve this contradiction the following method was used to
define a PSP common for all the members of a team, but also actively accepted by them:
1. Model the current personal process for each member of the staff.
2. Propose a common process, based on personal processes and the PSP.
3. Gain agreement from all staff members on the common process.
Performing the first two steps could seem to be very costly, but in fact we discovered that personal processes
tended to be quite uniform. On the contrary step 3 was the most difficult as it requires that the staff accepts the
techniques introduced by the PSP.
As regards the detailed definition of the team software process, we used the following method, adapted from
(Morisio 1995, Morisio 1999) :
1. Define the process model (PM)
2. Define measurement goals and the related measures as scripts on the PM
3. Design and validate the data collection logs
4. Design the measures database
35. Apply the process and collect measures. The steps above are repeated to improve the process. Points 3 and 4 are strictly related with the implementation of a tool to support data collection and analysis. In the following we describe in more detail the steps above and their results. The Process Model The process model is described using the Object Model of the Object Modeling Technique (OMT) (Rumbaugh et al. 1991). The PM is defined with the goal of measuring the process attributes and is a snapshot of the team’s current process. We have tried to make it general enough to be used by other teams in the enterprise. The idea is to have a common, general PM used in all the teams. We will only need to specialise it to meet the teams’ particular needs. This PM is useful to model the development process and also the maintenance process. The next paragraphs are a short description of our Process Model, which is shown in the Figures 1, 2 and 3. The defects: failures and faults We have decided to differentiate between a fault and a failure, which are different types of defect, as defined by (Fenton and Pfleeger 1996) and shown in Figure 4. A human error leads to a fault in the document, and then, if the fault has persisted until the software is executable, it may manifest itself in a failure during execution. The documents A document is any material generated during the development of a software product, including the product itself (source code, manuals). There are several classes of documents: requirements, planning (defines the planned activities associated to the development), analysis, design (algorithm design, which specifies and/or designs the most important algorithms that the product will need, and module definition), module (the source code is organised in modules), test case document, executable and manual. The actions An action is the fundamental unit of work. It is performed by a single person and has a duration. Actions correspond to phases (basically plan, design, code, compile, test, post-mortem) in the original PSP. Figure 2 shows the inheritance tree of the action classes. Both software specific (failure search, integration, reviews) and non software specific (training, exhibition, marketing, data acquisition, data analysis, support to other teams, system management, demonstration, installation, customer assistance, project tracking) actions have been added to the original PSP phases, with the goal of monitoring how the time of engineers is consumed. The engineer is the subject who performs the action: • Using a mean (examples: a concrete development tool, E-mail, etc.) • At a place (examples: office X, customer Y or at the machine test room) • In the context of an activity (or project), if the action was planned • Upon a product, if it is a product related action • On a document of the product, if it is a development action
The associations between actions and defects
The original PSP collects, for each defect, the phase that injected and the phase that removed it. This allows to
monitor the most effective phases to remove defects, and the phases that inject more defects. We have modified
this model as follows (see Figure 2).
1. An action finds a defect. Performing the action you discover that there is a new failure or fault. While
defects can be found by chance by any action, some of them are explicitly dedicated at finding them (review,
test, failure search) and are classified as quality assurance. The action failure search is explicitly dedicated to
find the cause of failures signalled by users.
2. An action is performed to correct a fault. In the original PSP finding and removing a defect are
synonymous. Here removal of a fault can be performed later, and by a different person, than finding a defect.
After the fault cause of a failure is found, a number of actions can be performed to correct it. These actions are
classified as corrective maintenance, if the product is released.
3. A fault is in a product. This relation substitues ‘phase injects defect’ in the PSP. For instance if a fault is in
the analysis document, we derive that analysis injected the fault.
office organization has customer
is a set of
resource mean
type
works on
is used in
manager developer
action
duration
date
is scheduled
is made at
place
functionality
avtivity product
schedules
time period version
identifier release date document
Figure 1. Actions in the organisation
action
duration data acquisition data analysis
failure is the cause of date
severity is found by
identifier
date training exhibition marketing measure
is in
is the subject of product related action support to other teams system management
product
document has
is made upon
demonstration installation customer assistance project tracking development
finds
quality assurance production
fault
cause
removes injected
cross review review failure search insformal test formal test integration compile write identifier
date
is performed to correct
Figure 2. Action inheritance tree
5product has requests requests resource
customer
version
release date
writes
is the cause of
change request
document functionality has aspect
failure is reported by failure report enhancement request adaptment request
has
severity
identifier
date
fault is caused by corrective change enhancement adaptive change
cause
injected
identifier
date is fixed by
writes change report
resource aspect
Figure 3. Management of product changes
defect
human error fault failure
during the in a document during the
software of the product software use
failure fault process
is caused by
Figure 4. Faults and failures
Author:
Date: see list P, R, A, D, M, product name, D_identifier or
E or file name version F_identifier
Start Stop Action Document Product Description Activity Cause Finds
type id.
Figure 5. Action Recording Log heading
Product:
P, R, A, D, M, E or file name CM, CN, CL or SV
D-Identifier Document Cause Description Author Date Close
Figure 6. Fault Recording Log heading
Product:
Injury Functionality
Major Usability
Minor Efficiency
Negligible
Version F-Identifier Author Function Severity Aspect Origin Description Finds Date
Close
Figure 7. Failure Recording Log headingProduct & version:
Major Functionality
Minor Usability
Negligible
Efficiency
E-Identifier Author Function Priority Aspect Origin Description
Figure 8. Enhancement Recording Log heading
The sheets for data recording
We have performed a mapping of the PM in a few simple logs. In some cases duplication of fields has been
necessary to make it easier to work with the logs. In all the logs a description field for free form text is added.
In an initial validation phase these logs take the form of paper sheets. Then they are automated. Figures 5, 6, 7
and 8 show the headers for the paper sheet version of the logs: the Action Recording Log, the Fault Recording
Log, the Failure Recording Log and the Enhancement Recording Log.
Measures
At the personal level the measures collected are the same as in the PSP. There are some measures that have
been adapted to handle the team level of the process. For example:
effort spent on development, maintenance and other activities,
in development: effort spent on production and quality assurance activities,
in maintenance: effort spent on production and quality assurance activities,
incoming failures: open failures and fixed failures per month,
faults found and fixed per month.
In the PSP, compiling the source code is the milestone event after which no defect should be left in the code.
The process yield measure expresses this concept.
In our modified PSP, there are three events that allow the definition of similar concepts:
1. Compilation of a module, the same PSP event
2. The integration of the product components in a product
3. The release of the product to customers
According to this view, the Process yield and A/FR measures have been modified (see Table 1). The measure
script is a formal description of the measure that uses a query language defined over the Object Model of the
PM. Refer to the Measure column for an informal definition. A “quality assurance action” is any action
subclass of the Quality Assurance Action class.
7Measure name Definition Measure script
Process yield 1 100* (#faults removed before count(fault.find_action.type∈precompile) /
compile)/(total # faults removed) count(fault)
(Compile event)
Defect finding Defects (that is : faults or failures) ∀T∈ActionTypes,
efficiency found per hour per action type count(defect.find_action.type=T) /
sum(defect.find_action[.type=T].duration)
Appraisal to failure Effort(quality assurance actions before Sum(action[.type∈qaaBc].duration) /
ratio 1 compile) / effort(quality assurance sum(action[.type∈qaaAc].duration)
actions after compile)
AF/R 1 (Compile
event)
Appraisal to failure Effort(quality assurance actions before Sum(action[.type∈QA &&
ratio 2 release) / effort(quality assurance .date=ReleaseDate].duration)
Table 1. The modified Process Yield and AF/R measures
3.3 The tool and privacy issues
A tool has been developed to support data acquisition and computation of measures, and to enforce privacy of
data. It is based on a client server architecture, and provides an interface to introduce and to modify the data of
the four logs presented (action, defect, failure and enhancement recording log). It eliminates the need of
duplicated information and hand-maintained pointers. It also computes and displays indirect measures.
It is also a convenient interface to update the classifications used (add and delete action types, add and delete
document types…) and the environment of the process (products and releases, documents of a product,
customers…).
There is a public database, located in the server, which uses cryptography and a password to control access to
the data. The client is also protected using a personal password for each user. In this context, a control of access
to personal-and team information is implemented. The database is divided in team data and personal data, and
the queries perform team measures and personal measures.
Personal information. The data defined as personal is only accessible to his owner. An example of personal
data are the actions performed by an engineer (this information could be used to control the individual’s
productivity).
Team information. The data defined as team data is public to all the team members. Examples of team data
are the failures detected, the enhancements requested and the faults found in a product. The team measures
(if calculated from private data) are aggregated and it is impossible to identify the personal contributions to
the final set. For example: the distribution of action types per team is a public measure, but the distribution
of the action types of an engineer is a personal measure and is only available to her.
3.4 Granularity of effort collection
The PSP requires to collect effort very precisely, with a unit scale in the order of minutes. This level of
precision is not accepted by every engineer, and can be disturbing for short actions (for instance, recording a
two minutes action can require one minute).
We have dealt with this problem trying to use flexibility and automatic support.
An engineer can perform the collection of the actions using various granularity levels. For example, in the first
days one of the components of the team wrote (in the action recording log) about 25 actions per day, a week
after about 10 per day. This granularity can range from writing every defined action separately (an action can
be very short, 2 minutes, for example, to correct a defect found compiling) to writing the actions at a more
abstract level (aggregating short actions so that they have duration in the order of hours). Both ways of working
are accepted in our modified PSP, and supported by the tool.The tool tries to make it easier the introduction of the actions and the related information. The engineer logs an
action with a few mouse clicks, and finishes it with another mouse click. If interrupted, he pauses the action
with one click, resumes it with another one, and so on. Of course, all durations are computed automatically.
4 Conclusion
We have described how the PSP, defined by Watts Humphrey, has been adapted to be applied in a small team of
developers.
Adaptations concern the action recording log (many action types have been added to the original PSP) and the
defect log (both failures and faults are recorded, at the product level instead than at the personal level).
Measures have been adapted accordingly.
We believe that these adaptations maintain the philosophy of the PSP for the personal level, while allowing to
use it effectively as the foundation for a team process.
The goal of this experiment is to verify if, using the PSP in an industrial context on real projects, quality and
productivity improve. While it is now too early to verify if these goals are met, we can state that the PSP is a
superior tool to rationalise the software process in small teams, using a bottom up approach.
• The material in the book provides an excellent source of state of the practice techniques that should be the
background of each software engineer. This material is therefore perfectly suitable as the starting point for a
personal process. Then this process can be quite easily adapted to fit in a team process.
• The PSP movement (in the sense of papers, discussion groups, conferences and so on) provides a convincing
authority to change or to start changing. In this sense the PSP could act as a catalyzer for change in the
software industry as the ISO9000 or the CMM.
5 Acknowledgements
This work was partially supported by the European Commission, DGIII/A, under contract Esprit/ESSI PSP-NC
n. 24060.
6 References
Emam, K.E., B. Shostak and N.H. Madhavji, 1996. Implementing Concepts from the Personal Software Process in an
Industrial Setting, Proceedings of Software Process, Brighton, UK.
Fenton, N.and Pfleeger S.L., 1996. Software Metrics – A Rigorous and Practical Approach, ITP.
Ferguson, P., W.S. Humphrey, S. Khajenoori, S. Macke, and A. Matvya, 1997. Results of Applying the Personal Software
Process, IEEE Computer, May.
Humphrey, W.S., 1995. A discipline for Software Engineering, Addison-Wesley.
Humphrey, W.S., 1996. Using a Defined and Measured Personal Software Process. IEEE Software, pages 77-88, May.
Humphrey, W.S., 1997. Introduction to the Personal Software Process, Addison-Wesley.
Jahnke J., W. Schaefer and A. Zuendorf, 1997. An experiment in building a light-weight process-centered environment
supporting team software processes, technical report TR-RI-97-181, Universitaet Gesamthochschule Paderborn.
Morisio, M., 1995. A Methodology to Measure the Software Process, Proceedings of the Annual Oregon Workshop on
Software Metrics, Portland, OR, 5-7 June.
Morisio, M., 1999. Measurement Processes are Software too. Journal of Systems and Software, to appear. Also available at
www.cim.polito.it/Articles/mproc.zip .
Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, 1991. Object oriented modelling and design, Addison
Wesley.
9You can also read
