8/2/2019 10.1.1.75.7307

1/8

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 managersand developers. Although software process improvement results in many benefits inthe 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 betweencompanies 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 isinspired by the open source model and in the paper we compare our model for tailoringsoftware 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 ICELANDHjardarhaga 2-6, IS-107 Reykjavik, Iceland

tel.: +354-525-4702, fax.:+354-525-4937, email: ebba@kerfi.hi.is

Helgi Thorbergsson, Dr., UNIVERSITY OF ICELANDHjardarhaga 2-6, IS-107 Reykjavik, Iceland

tel.: +354-525-4945, fax.:+354-552-8801, email: hetho@hi.is

1. Introduction

Increasingly we are using the Internet to communicate and search for knowledge and information. Wereview each others work more extensively, creating repositories of experiences and form variousknowledge 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 formalsoftware 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, ISOstandards are relatively new. Among landmark standards that have been published are the ISO/IEC 12207

Software Life Cycle Processes and ISO/IEC 15504 Technical Report for Software Process Assessment, orSPICE. 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 3software companies in Iceland have adopted ISO 9001. 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 certificationwas 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. Theremaining 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 softwareprocess improvement but only 3 of them are adhering to international standards. The other 13 companies

are using in house methods.

8/2/2019 10.1.1.75.7307

2/8

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 adoptstandard 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 wepresent the open process as an analogy to the open source software, it can be used for all types of softwaredevelopment, 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 thissubject. In the spirit of the open model, readers are welcome to send e-mail 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 DevelopmentBefore presenting an anology between open source software and our proposed open process for softwaredevelopment, 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 studythe impact of open source software on quality of the software, e.g. bugs, functionality, usability andsecurity.

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 processmay 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 projectmanager or an editor. The other users, that is the slaves, send in comments, bug fixes etc. The product israther 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].

8/2/2019 10.1.1.75.7307

3/8

Developer

(Master)

Developer/User

Developer/User

Developer/User

Source

Bug-fixesAddedfunctionality

Sourc

e

Source

Figure 1 shows how open source software development works. The actors are either developers or users.

The actors communicate on the Internet via e-mail, web, and co-operating systems. Their subject ofcommunication 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-functionalityrequirements, or comments on design.

We shall next look at the development model for the open process. If it follows the cathedral-model there isone person, company or institution that starts tailoring the process carefully according to his own needs. Heor 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 hisown 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 tostart 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.

Figure 1 Master model

8/2/2019 10.1.1.75.7307

4/8

Baseline

version

Start

another

project

to fit different

needs

Peers

Following the bazaar model, the software process should be used very early and then incrementallyenhanced 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 softwareprocess 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, andsuggestions 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 tailoredinstances. 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 peopleask 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 softwaredevelopment 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 improvementexperiments.

There are several ways to encourage people to improve the maturity of their software processes. Among themotivations that are usually presented are increased satisfaction of employees, faster development, lowermaintenance 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 hasto 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 SoftwareInitiative (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

Figure 2 Peer model

8/2/2019 10.1.1.75.7307

5/8

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 carriesout 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 fromsoftware 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 12207 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 concepthas 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 usuallystarted 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 thatcan 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 tailoredprocess. The motivation for a company to start an open process would be that it needed help and saw theadvantage 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 fromcompanies 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

8/2/2019 10.1.1.75.7307

6/8

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 tailoringthe process for their own use. They can not verify the process in a software development house or adepartment. 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 aweb that was structured around methodologies or issues such as formal methods, object-orienteddevelopment 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 onmetrics 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 mayhowever 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 RationalUnified 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 acompany 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 involvingstudents in software process improvement project. It is common that they work in the software industryduring the latter part of their study and can be a good link between the university and the industry.

4.6 Funded initiatives

The 5th

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 ProcessImprovement 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.

8/2/2019 10.1.1.75.7307

7/8

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 experiencegained 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 othercompanies 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 thatneed improving.

When companies start to co-operate on the tailoring, they need to be careful to adhere to the ISO 12207

standard. Tailoring of the standard to the companys 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 thequality 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 newprocesses 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 toimplement 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 processmight 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 thanwriting 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 aflexible 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 madeeasier, 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 tailoredprocess 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 theirjob-focus matures.

Finally, we wonder who will benefit the most from the open model of tailoring processes. Is it the leastmature 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/2/2019 10.1.1.75.7307

8/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 withcompanies 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 ontools 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. Thereare 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 co-operates with each other on the tailoring the software processes.

References

1. Yourdon, Edward, Millennial megatrends, Software in Focus, Issue 9, December 1999

2. Lund, Anita Bjork and Hvannberg, Ebba Thora, Survey of software best practice experience for smallcompanies, 1999

3. Free Software / Open Source: Information Society Opportunities for Europe?,

Working group on Libre Software, April 2000, Version 1.2 (work in progress),

http://eu.conecta.it/4. Raymond, Eric S., Cathedral and the Bazaar, 1999, ISBN: 1-56592-724-9

5. Dutta, S., Van Wassenhove, L.N., Kulandaiswamy, S., Benchmarking European Software ManagementPractices, Communications of the ACM, June 1998/Vol. 41, No. 6

6. O'Day, Dan, This old house, IEEE Software, March/April 1998

7. Grady, Practical Software Metrics for Project Management and Process Improvement. Hewlett-

Packard Professional Books, Prentice-Hall, 1992, ISBN 0-13-720384-58. Humphrey, Watts S., Managing the Software Process, Addison-Wesley, 1989, ISBN 0-201-18095-2

9. Zahran, Sami, Software Process Improvement, Addison-Wesley, 1997, ISBN 0-201-17782-X10. Sanders, Marty, editor, The SPIRE handbook, 1998 The European Community, ISBN 1-874303-02-9

11. Sanders, Joc and Curran, Eugene, Software Quality: A Framework for Success in SoftwareDevelopment and Support. Addison-Wesley, 1994, ISBN: 0201631989