An open model for tailoring software processes

Transcription

1 An open model for tailoring software processes Ebba Thora Hvannberg, Helgi Thorbergsson, University of Iceland, Iceland Summary: While supporting companies in defining or improving software processes we have observed that co-operation between companies is very valuable to quality managers and developers. Although software process improvement results in many benefits in the long term to a company, it also requires an investment in time and resources. With frequent migration of personnel between companies, there is both increased need for defining software processes but also more implicit sharing of knowledge between companies because technical people move knowledge with them from one company to another. In this paper we present an open model for tailoring software processes. It is inspired by the open source model and in the paper we compare our model for tailoring software processes to the open source model. Furthermore, we present ways in which the open model could be implemented and describe possible gains and pitfalls. Ebba Thora Hvannberg, Dr.,UNIVERSITY OF ICELAND Hjardarhaga 2-6, IS-107 Reykjavik, Iceland tel.: , fax.: , ebba@kerfi.hi.is Helgi Thorbergsson, Dr., UNIVERSITY OF ICELAND Hjardarhaga 2-6, IS-107 Reykjavik, Iceland tel.: , fax.: , hetho@hi.is 1. Introduction Increasingly we are using the Internet to communicate and search for knowledge and information. We review each others work more extensively, creating repositories of experiences and form various knowledge networks. For the past few years, open source software development has attracted people's attention. Open source software development has been successful in giving us many good products, including compilers, editors and operating systems. Software engineering practitioners and researchers have been trying to develop and incorporate formal software life cycle practices for several decades now, and the results are in some ways a bit disappointing. Although software life cycle standards from other bodies have been used, notably ANSI/IEEE, ISO standards are relatively new. Among landmark standards that have been published are the ISO/IEC Software Life Cycle Processes and ISO/IEC Technical Report for Software Process Assessment, or SPICE. A 1997 survey showed that only 10-15% of US companies has adopted ISO 9001 and equivalent standards [1]. A benchmark of European Software Management Practices has been published [5]. Only 3 software companies in Iceland have adopted ISO In a 1995 survey of nineteen Icelandic companies [2], 20% of the companies had ISO 9001 in planning, it was under consideration by 45% and certification was not considered relevant by 30%. Of the companies surveyed, 25% claimed to be implementing software process improvement (SPI), 45% were considering it and 18% had SPI actions in planning. The remaining 12% considered SPI actions not relevant for their quality control. In 1999 another survey revealed that of 21 Icelandic companies, 16 said they were implementing software process improvement but only 3 of them are adhering to international standards. The other 13 companies are using in house methods.

2 In this paper we present an idea that is based on similar principles as open source software development. We call it open process for software development. Its objective is to encourage companies to adopt standard software processes by suggesting that companies share their experiences with tailoring their processes. It is based on three principles: People share their experiences by reviewing each other's software processes documentation. People share software metrics that result from using tailored processes. Communication occurs mostly over the Internet but also in person if possible. In this paper we define the open process, relate it to open source software, present an implementation plan for it and finally suggest pitfalls and gains that we may encounter. It should be noted that although we present the open process as an analogy to the open source software, it can be used for all types of software development, both open and proprietary. Tailoring of the software process has direct links to the software lifecycle standards, assessment standards and quality standards. Our goal of writing this paper is to encourage discussion of this topic. We hope that the reader will actively participate and comment on this subject. In the spirit of the open model, readers are welcome to send to the authors to agree or disagree on the statements made in the paper as well as adding new opinions. 2. Relationship with Open Source Software Development Before presenting an anology between open source software and our proposed open process for software development, it is necessary to list the main characteristics of open source software development. In [3] free or open source software is characterised as giving the users the freedom to: Use the software as they wish, for whatever they wish. Have the software at their disposal to fit it to their needs. This includes improving it by fixing bugs, adding functionality and reviewing it. Redistribute the software to other users free or at a charge. Users of a piece of software must have access to its source code. In the examination of the open source software movement, several issues have been studied: software development models, economical models, legal rights, and motivation for its existence. One can also study the impact of open source software on quality of the software, e.g. bugs, functionality, usability and security. In the following, we further characterise the development models that have been used for open source software. We dwell less on legal matter although we recognise that the ownership of the defined process may be an important issue. The development model of open source software is always a group model, i.e. it is a social activity. Sometimes there is a master that controls the development and acts as a project manager or an editor. The other users, that is the slaves, send in comments, bug fixes etc. The product is rather carefully designed bottom-down. This model has been called the cathedral-model [4]. The other model is more of a peer-to-peer model and there is no master. Changes are not screened and there is less control. If you want to add something you are free to do so. This model has been called the bazaar-model [4].

3 Developer (Master) Source Developer/User Source Added functionality Source Bug-fixes Developer/User Developer/User Figure 1 Master model Figure 1 shows how open source software development works. The actors are either developers or users. The actors communicate on the Internet via , web, and co-operating systems. Their subject of communication comes from all phases of software development. The primary subject is often the source code. The actors can send reports on errors, requests for added functionality or non-functionality requirements, or comments on design. We shall next look at the development model for the open process. If it follows the cathedral-model there is one person, company or institution that starts tailoring the process carefully according to his own needs. He or she may then release it and subsequently he or others can test the process. In the meantime, the master gets responses, war stories and experience reports. In addition, if a slave has other requirements he may ask the master to add them. If the master doesn't agree on the revision, the slave may go off and fork off his own version and continue with the project, thus becoming his own master and try to gather other slaves around. Perhaps the characteristics of his company's needs are so different from others that he his forced to start on his own. If the company is mature enough, the process is tested and metrics on its usefulness are produced and released. Figure 2 shows a peer model where one of the developers has forked off his own open project.

4 Peers Baseline version Start another project to fit different needs Figure 2 Peer model Following the bazaar model, the software process should be used very early and then incrementally enhanced as we get comments on its usage. This follows the rule that is often used in open source development: "release early, release often". In the open process model, the actors are software developers, quality managers or members of a software process engineering group (SPEG) from different companies. As with the open source software development, they communicate over the Internet. Their primary subject of communication is the tailored process. Other subjects of communication are process defects reported while using the process, methodologies and technologies related to the process, metrics that result from using the process, and suggestions for additions or changes to the process. Little by little we may have several tailored instances of standard software life cycle processes and we can characterise them by maturity of companies, size, domain etc. Thus we create a repository of tailored instances. All the while we need to be careful that the tailored processes are without a guarantee regarding their capability level. 3. Premises of the open process Our experience of giving courses and workshops on software process improvement has been that people ask for concrete examples. The start-up time of incorporating defined processes may take quite some time and the companies are not always willing to invest in development of the definition of a software development model. We find that it can take a long time to convince companies to get started, that is from the time we introduce the subject until people start process definitions or process improvement experiments. There are several ways to encourage people to improve the maturity of their software processes. Among the motivations that are usually presented are increased satisfaction of employees, faster development, lower maintenance cost, less re-work, fewer defects and better agreement on requirements. What deters people from incorporating software processes is the need for added investment. Adopting software processes has to be planned, and you need resources and training. It is not something that occurs overnight. One of the reasons for this is that each company has to tailor the software development process to their needs. Process Improvement Experiments (PIE), that have been supported by European Systems and Software Initiative (ESSI) [5], take a practical and focused road to software process improvement. In the experiments companies do not renovate the house all at once, they take it room by room[6]. A general framework has

5 been developed for how to do such experiments and participants share results of the experiments. However, you have little or no chance in being a co-participant in the experiment. Furthermore, one company carries out each PIE. With the open process we aim to remedy the following: Lack of tailoring examples of software processes. The incorporation of quality management systems takes too long and is too rigid. Low management commitment because of lack of resources. Usability of standards. The reason we think that the open process will work now is: People change jobs frequently and there is thus more implicit sharing of knowledge between companies. Quality work is often introduced in companies bottom-up. People are more satisfied with working in well defined environments, where you know what to do next. Technical people like to share experiences - people get fulfilment from telling others about their experiences. The open process works on the following premises that are in step with the open model methodology: Individuals from a group of companies are willing to work together on improving each other's software life cycle processes. The tailored processes are free, that is they are not sold for any fee. The tailored processes or quality handbooks are not licensed to individual companies; they have an open licence. The defined processes are not guaranteed, but you can present metrics (analogous to test data from software testing) that shows how well they work. If a tailored process is open, anyone can read it, use it, comment on it, change it, or adapt it to their needs. Adoption of international standards should be encouraged. A tailored software life cycle process is neither guaranteed to conform to ISO nor can it be assessed out of the context of a company environment. 4. Implementation plan In the previous sections, we presented the idea of an open process. It is presented here to encourage discussion, to receive criticism and to further new ideas for modification. Since the open process concept has not been tested or verified in any way, we would like to give a few ideas on how it could be tested. 4.1 Companies Any task under the open model, whether it is software development or tailoring of a process, is usually started in the grass-root. A pioneer company begins the work and after a while publishes it and hopes to find some companies that are interested in sharing the work-load or comment on it. It is not something that can be steered or controlled - someone has to be willing to start. Although open source software development, for instance, is an egalitarian task, it is seldom a true peer model; there is always someone that is the editor. The editor, however, does not own the results. Therefore all the others can use the tailored process. The motivation for a company to start an open process would be that it needed help and saw the advantage of getting comments from others. We have examples of when one company adopts another company's quality handbook. 4.2 Individuals Individual developers could also start or participate in the open process. We separate them here from companies since we assume that they are not working in the name of any company. They could still practice the process in their individual projects or even in their companies. We have seen in the past that

6 open source software projects are often started by individual champions and therefore expect this to happen for open processes. 4.3 Institutions A university, a software industry association, or a professional organisation could encourage companies or individuals to develop an open process. We believe that they can set a framework or provide the environment to encourage it, but they can not be the initiators since they are not the ones that are tailoring the process for their own use. They can not verify the process in a software development house or a department. The above institutions can however start an initiative with the following support actions: Provide a platform: Maintain a CSCW (Computer-Supported Co-operated Work) site where people can discuss the processes and store documents. There could be several such on-going projects with different visibility. For example, there could be three companies working on the Requirements Specification Process and another team of five companies working on the Testing Process. Methodologies, technologies, best practices and tools: Maintain a public information web-site on methodologies, technologies and best practices on the different processes. This is a reference site for the participants. The ESPINODE network created a web that was structured around methodologies or issues such as formal methods, object-oriented development and testing. Because of the emphasis on process definition, it may be appropriate to organise the same resources around the software lifecycle processes. Database of metrics: A database of metrics collected for software processes. We said earlier that in order to convince others to use the tailored process, we needed to provide evidence of success. Grady [7] points out that data on metrics needs to be divided into private and public data. This classification applies especially for small and medium companies that may be reluctant to release data on their own company. They may however be willing to put their data into an aggregated set from three or more companies. Process guidelines: Resources on process guidelines, e.g. [8,9,10] and frameworks for processes such as the Rational Unified Process. The above list is by no means exhaustive but gives an idea of the type of support that may be valuable. 4.4 Consultants Companies sometimes seek advice from consultants or consulting firms on quality management. Consultants could therefore initiate an open process, and participate in it as long as they do not charge for their work. 4.5 Student involvement Several students at the University of Iceland have carried out process improvement experiments within a company as B.S. thesis projects. Since the theses are public, they can be used as a basis for someone else to adopt and start their own open process project. In general, we have successful experiences of involving students in software process improvement project. It is common that they work in the software industry during the latter part of their study and can be a good link between the university and the industry. 4.6 Funded initiatives The 5 th framework programme of the European Commission and national funds has supported software improvement process projects for several years. The projects have often been in forms of Process Improvement Experiments. We suggest that one form of project could be co-operative software quality, where two or more companies decide to tailor the same process together.

7 5. Gains and pitfalls This section on gains and pitfalls of our suggested approach will be short since we do not have any basis to support our findings. We try, though, to foresee some of the gains and pitfalls. We hope that experience gained in the future with the open process will provide us with evidence of success or failure. 5.1 Pitfalls We feel that the initial implementation of the open process idea might be difficult for several reasons. Many companies have spent years in developing their quality manual and will not be eager to let other companies or competitors get what they might feel is a free-ride. This is so despite the fact that companies that have developed an initial version of a quality manual are stuck with software processes that need improving. When companies start to co-operate on the tailoring, they need to be careful to adhere to the ISO standard. Tailoring of the standard to the company s needs and workflows is necessary in order for the procedures to be fully usable within the company. Smaller companies will not be eager to share their metrics, deviation-reports etc. in fear that competitors will use these facts against them in the competition. Another reason for a difficult implementation of an open process is that the employees of a company that adopts a framework will not have the feeling that the quality manual is their own work and thus not as willing to adhere to the processes suggested. We feel, though, that this is a minor issue since with rapid movement of personnel in this field, employees are getting more used to adhering to processes that they did not participate in creating from scratch. Furthermore, such movement of personnel is in vein with the open process, employees adhering to new processes will get fulfilment out of giving input to the new process based on their own experience. 5.2 Gains The long term gains of the open process are definitely financial. It is expensive for small companies to implement a quality handbook and most often the most difficult and expensive part is the initial phase, i.e. educating the employees on what a quality handbook is and how it should be organised. An open process might get rid of this initial hurdle. Many companies have already gone through the basic steps of developing a quality handbook and employees are more willing to work on tailoring the framework than writing a handbook from scratch. It is difficult to say beforehand whether the instantiation of a quality handbook will be quicker this way. The tailoring of processes is a time-consuming task and without a flexible framework this part can though be a painstaking one. Experience in Iceland shows that employee satisfaction increases with the adoption of a quality manual and employees prefer to work in such an environment leading to easier employee recruitment. With the open process giving a common framework adaptation of employees to a new work environment will be made easier, increasing both productivity and job satisfaction. We have said that one of the goals of this model was to promote standards. We could view a tailored process as one reference implementation of the software life cycle standard. It may not fit everyone's need, but still gives an example. We feel that start-up companies that are willing to adhere to standards will benefit the most from such an undertaking. Those companies can adopt the open process from the start and tailor it to their needs as their job-focus matures. Finally, we wonder who will benefit the most from the open model of tailoring processes. Is it the least mature companies that have no defined process that need to see examples of tailoring? Alternatively, is it perhaps too difficult for them to be in a team with other companies? Do more mature companies benefit more since they are likely to be working on improvements of their processes? These questions are open for debate and answers to them will only be received when the model is implemented.

8 6. Conclusion In this paper we have presented the idea of an open process which goal is to promote process standards and improvement of software processes. It is intended to shorten the start-up time of process tailoring with companies by asking companies to share each other's quality handbooks and thus make the process definitions open. The open process is not the only way to reach the above goal. We may also start an open source project on tools to use for best practices such as review, configuration control, project management for software development and assessment tools. Already, such tools are available for some best practices. We can also speculate that an open process will encourage an open source software development of such tools. Fortunately, we have many texts [11] to guide software developers in their process definition work. There are many case studies that give testimonies on software process improvement experiments. What is different with the approach suggested in this paper is that the developer or the quality manager actively cooperates with each other on the tailoring the software processes. References 1. Yourdon, Edward, Millennial megatrends, Software in Focus, Issue 9, December Lund, Anita Bjork and Hvannberg, Ebba Thora, Survey of software best practice experience for small companies, Free Software / Open Source: Information Society Opportunities for Europe?, Working group on Libre Software, April 2000, Version 1.2 (work in progress), 4. Raymond, Eric S., Cathedral and the Bazaar, 1999, ISBN: Dutta, S., Van Wassenhove, L.N., Kulandaiswamy, S., Benchmarking European Software Management Practices, Communications of the ACM, June 1998/Vol. 41, No O'Day, Dan, This old house, IEEE Software, March/April Grady, Practical Software Metrics for Project Management and Process Improvement. Hewlett- Packard Professional Books, Prentice-Hall, 1992, ISBN Humphrey, Watts S., Managing the Software Process, Addison-Wesley, 1989, ISBN Zahran, Sami, Software Process Improvement, Addison-Wesley, 1997, ISBN X 10. Sanders, Marty, editor, The SPIRE handbook, 1998 The European Community, ISBN Sanders, Joc and Curran, Eugene, Software Quality: A Framework for Success in Software Development and Support. Addison-Wesley, 1994, ISBN: