Software companies are constantly fighting against the perils of software .... A>10. 0
4 A MODEST BUT PRACTICAL SOFTWARE PROCESS MODELING TECHNIQUE FOR SOFTWARE PROCESS IMPROVEMENT
Ahonen, J. , Forsell, M. , Taskinen, S-K. , “A Modest but Practical Software Process Modeling Technique for Software Process Improvement”. This paper has been submitted for publication to Software Process: Improvement and Practice. Copyright may be transferred without further notice and the accepted version may be posted by the publisher. Information Technology Research Institute, University of Jyv¨askyl¨a, Finland. Chydenius Institute, University of Jyv¨askyl¨a, Finland.
Abstract One of the main problems with software engineering is due to the difficulties in evaluating and improving our software processes, especially in the light of the fact that reuse depends on a process which supports it. Generally used approaches to the evaluation and improvement of software processes are based on CMM, for example. In this paper we present a technique to improve software processes through modeling and evaluation. The presented technique is fairly easy to use, provides reasonably good results and requires only a fraction of resources required by CMM appraisals. Keywords: technique
4.1
process modeling, software process improvement, modeling
Introduction
Software companies are constantly fighting against the perils of software projects. Timetables do not hold, talented personnel is not available when re-
82 quired, budgets are overrun and software quality is not adequate. Those problems are severe and it is obvious that there are no “silver bullets” for those problems (Brooks, 1987). The problems that software engineering organizations face are not, however, completely incurable. It is a common opinion that it is possible to improve the situation through gradual improvement (see e.g. Humphrey, 1989). One approach is to improve the software development process. The main ways to improve a process are 1. to omit unnecessary phases from the process; 2. to introduce new phases to the process; and 3. to improve the existing phases of the process. The necessary steps to be taken in order to implement any of the above ways of process improvement require good knowledge of the actual software process to be improved. In this paper the terms software, and software process, and software process modeling are considered in the light of (Pressman, 2000, Boehm, 1976, and Gibson, 1999, and Curtis et al. 1992), respectively. The software process is described (or prescribed) in extensive models like CMM (Paulk et al. 1993, Paulk et al. 1995), SPICE (SPICE, 2001) and ISO9001 (Kehoe & Jarvis, 1996). Those models do not include any way to model the actual process and for that purpose it is possible to use techniques like SADT, IDEF0 and Petri Nets (see e.g. (Curtis et al. 1992) for an evaluation). There are very few techniques which include processes, modeling and documentation in a single package (Curtis et al. 1992). In this paper such a technique is presented. The technique has been developed in an industry cooperation project called PISKO. The aim of the project was to improve the software process — and especially software reuse — of the participating companies. The interest was especially in software reuse and the organization of reuse, in which the actual characteristics of the software process is especially important. This is expressed by Lim (Lim, 1997) when he stresses the importance of considering reuse in every phase of the software process, i.e. the actual characteristics of the process. In the very first steps of the research it was decided that CMM is not probably useful considering the aim of the project and the lack of explicit notion of software reuse in CMM. The view was backed up by the companies which were already familiar with CMM. One of the problems expressed by the companies already familiar with CMM were the overall feeling of CMM appraisals. The representatives of those companies thought those appraisals too serious, almost like inspections in the army1 , and an approach with a more positive feeling was sought after. 1
Something like: “All you programmers, arrange yourself in straight lines according to the quality manual. Now we will have a look at your code and your ways to program it. No speaking in the line.”
83 In order to improve software reuse in participating companies a technique to model software processes was required. There were a few requirements for the technique. Those requirements were based on the fact that all participating companies were in constant need of talented personnel and their current employees were generally overstressed. Therefore any technique had to fulfill the following restrictions: 1. the technique should be easy to use for people who have no prior knowledge of it; 2. the technique should require as minimal resources as possible from the target organization; and 3. the technique should be able to point out real problems in the software process and hence provide input for process improvement. In this paper a technique which satisfies the requirements in a reasonable way is presented. The situation in which the technique has been applied is outlined and the results are analyzed and their usability discussed.
4.2
PISKO Process Modeling Technique
The practical requirements lined out above restricted the complexity of the techniques that we could use. Process modeling is based on observation and reporting (Verlage, 1997). Therefore the most important part of any attempt to model the actual software process should emphasize the opinion and experience of the experts of the target organization. In our case the object of description and analysis is the software process actually used in the organization — not a process found from quality handbooks. Our organization have earlier used the wall-chart technique (SaarenSepp¨al¨a, 1997)2 and experiences have been positive. The wall-chart technique is an excellent technique when a group of specialists are required to communicate and achieve a consensus regarding the current situation in a tight timetable (Karjalainen et al. 2000). It is the backbone of our modeling technique. The PISKO Modeling Technique includes six phases, which are shown in the figure 4.1. We acquire the current process from expert knowledge by using the wall-chart technique in sessions which are organized in the target organization. During these sessions problems and points of improvement are recorded. After this the process models are transformed into a digital form which is inspected by the target organization. Next the process and problems are analyzed and evaluated, and naturally these results are inspected. In the following sections the phases are briefly discussed.
2
The wall-chart technique has been fairly popular in Finland since 1970’s, especially in information system design.
84
Existing process descriptions. Development method
Modeling the process with wall-chart technique
Wall-chart. Textual descriptions
Definfing the problems and points of improvement
Enhanced wall-chart Enhanced textual descriptions
Creating an electronic version of the process description No
Digital document
Inspection of the electronic version
Approve? Yes
Approved digital document
Analysis of the process description
Approved description of software process
No Enhanced digital document
Inspection of the results
FIGURE 4.1 The process description of the PISKO technique.
Yes
Approve?
85 4.2.1 The Wall-Chart Sessions During the Wall-Chart Sessions the model of the current process is constructed and problems with it are identified. The session lasts normally from three to five hours and it is done in a room where the session can be held without disturbance. In most cases there are seven people participating in the session: five experts from the target organization and two consultants. The experts should be chosen from those who know the actual software engineering process very well and have relatively long experience from the process. Two consultants are required to fill the roles of the chairman of the sessions and the secretary, whose responsibility is to make sure that every important piece of information revealed in the session will be written down. The chairman and the secretary have prepared for the session by studying the existing material of the target organization’s processes. That knowledge should, however, be used for gentle guidance, not for auditing. That is because the aim of the session is to let the experts describe the real process as is, which very often differs from the official process.3 In the beginning of the session the technique is briefly explained to the experts. After the introduction the chairman lets the experts identify the main phases of the software process. Every expert is allowed, practically required, to express his/her opinion. When the experts have achieved a common opinion of a phase and its name, the secretary writes it down on a piece of paper. The chairman attaches the paper to the wall-chart into a place which represents the position of the phase in the software process. The flows of information are identified and represented in the same way (e.g. a document produced by a phase and required by another phase is represented by an elongated piece of paper which is marked by the name of the document). The wall-chart notation is shown in the figure 4.2, a simple process description is shown in the figure 4.3, and a wallchart under construction is shown in the figure 4.4. Often the process model needs greater accuracy. These may be pointed out by the experts participating the session, or the chairman may hint on the possible phases or flows that need to be handled with greater precision. Normally the experts can be trusted to make such decisions. In these cases the phases and flows of information may be divided into subphases and subflows if necessary. In some cases the subphases and subflows may require separate wall-charts and they need to be modeled in separate sessions. The session may be recorded, but in many cases recording makes the situation a bit awkward. Therefore we have decided to have the secretary to make accurate notes of the discussion and especially on the reasons why particular decisions have been made and consensus achieved. The secretary uses a predefined report template as much as possible during the note-taking. The outline of the template is shown in the figure 4.5.
3
This is somewhat in contrast to the attitude of CMM appraisals.
86 Conditional connections Connection may be conditional. In this case it is good to mark the condition to the connection line Conditional situation may be emphasized with a violet piece of paper which is shaped as a diamond.
By marking conditions to the connection lines, one can describe rather complicated logical constructs.
Data 1
A
