@inproceedings {SE.5.Sjoeberg.2002,
	title = {Conducting Realistic Experiments in Software Engineering},
	journal = {ISESE{\textquoteright}2002 (First International Symposium on Empirical Software Engineering)},
	year = {2002},
	month = {October 3-4},
	pages = {17-26},
	publisher = {IEEE Computer Society},
	type = {1},
	abstract = {An important goal of most empirical software engineering research is the transfer of research results to industrial applications. Two important obstacles for this transfer are the lack of control of variables of case studies, i.e., the lack of explanatory power, and the lack of realism of controlled experiments. While it may be difficult to increase the explanatory power of case studies, there is a large potential for increasing the realism of controlled software engineering experiments. To convince industry about the validity and applicability of the experimental results, the tasks, subjects and the environments of the experiments should be as realistic as practically possible. Such experiments are, however, more expensive than experiments involving students, small tasks and pen-and-paper environments. Consequently, a change towards more realistic experiments requires a change in the amount of resources spent on software engineering experiments. This paper argues that software engineering researchers should apply for resources enabling expensive and realistic software engineering experiments similar to how other researchers apply for resources for expensive software and hardware that are necessary for their research. The paper describes some of the experiences from recent experiments that varied in size from involving one software professional for 5 days to 130 software professionals, from 9 consultancy companies, for one day each.},
	isbn = {0-7695-1796-X},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Anda, Bente Cecilie Dahlum and Arisholm, Erik and Dyb{\r a}, Tore and J{\o}rgensen, Magne and Karahasanovic, Amela and Koren, E. and Vok{\'a}c, Marek},
	editor = {found, not}
}
@inproceedings {SE.5.Westerheim.2002,
	title = {{\textquoteright}Leave the Programmers Alone{\textquoteright} - a Case Study},
	journal = {4th International Conference on Product Focused Software Process Improvement},
	year = {2002},
	month = {December 9-11},
	pages = {291-299},
	publisher = {Springer-Verlag},
	type = {1},
	address = {Rovaniemi, Finland},
	abstract = {There has been much focus on the development process in the Software Process Improvement community. This paper describes software process improvement work done within a product division in a medium-sized Norwegian software company. The division has the main responsibility for the market activities, development, implementation, maintenance and support of their software products. We identified three main problem areas related to the overall process for management of the software product. None of the problem areas were directly concerned with the development process itself. The problem areas were addressed by the division{\textquoteright}s management. Despite the lack of focus on the programmers and the development process, the programmers{\textquoteright} attitude changed into a more positive one. One reason might be that the new overall product handling process "protected" the programmers from the market activities, and also clarified responsibility for the core development and the maintenance development. This paper discusses the findings in the case-study, and concludes that maybe the best software process improvement initiative would be to simply leave the programmers alone.},
	author = {Westerheim, H. and Koren, E.}
}
@inproceedings {SE.5.Koren.2002.b,
	title = {Techniques for Gathering Information About an Organisation and Its Needs for Software Process Improvement},
	journal = {EASE 2002},
	year = {2002},
	month = {April 8-10},
	publisher = {-},
	type = {1},
	address = {Keele, England},
	abstract = {This paper reports on how the authors planned and conducted the work in the initial phase of software process improvement in a Norwegian software house. The work was motivated by the results from the projects SPIQ (Dyb{\r a}, Wedde et al. 2000) and PROFIT (http://www.geomatikk.no/profit), where a pragmatic approach to software process improvement was the main focus. The way the work was conducted was further motivated by the results of Tore Dyb{\r a} (Dyb{\r a} 2001). He claimed that for instance participation of employees and exploitation of existing knowledge has positive influence on the success of software process improvement. This led us to arrange workshops with participants from all relevant parts of the organisation to gather a picture as broad as possible of the situation. The paper is organised as follows: First we describe the motivation behind the choice of method. Then we describe the case study. Then we discuss the results we got from our investigations. The paper ends with a conclusion and a description of further work.},
	author = {Koren, E. and Westerheim, H.}
}
@inproceedings {SE.5.Koren.2002.a,
	title = {Using a Knowledge Survey to Plan Software Process Improvement Activities - a Case Study},
	journal = {EuroSPI 2002},
	year = {2002},
	month = {September 18-20},
	pages = {213-224},
	publisher = {-},
	type = {1},
	address = {N{\"u}rnberg, Germany},
	abstract = {An important success factor for software process improvement is to identify the areas of the software process with the largest improvement potentials, and focus the improvement work on these areas. It is important to involve the employees in the improvement activities. Furthermore, recent research suggests that the exploitation of existing knowledge in an organisation is another important success factor for software process improvement. Consequently, it might be effective to focus improvement efforts on areas that exploit existing knowledge. This paper reports from a case study where we conducted a knowledge survey to identify the process improvement areas with high improvement potentials. A questionnaire was distributed to the developers of the organisation. The developers described their level of knowledge on general software engineering areas such as methods and programming languages. They also described how important they felt those areas would be in the future. Then, the resulting data were analyzed using simple statistical techniques. The results of the case study suggest that, when combined with other qualitative information, the knowledge survey was useful for identifying improvement areas that exploit existing knowledge. Furthermore, conducting a knowledge survey may have a positive impact on the improvement effort since the survey involved the employees.},
	author = {Koren, E. and S. E. {Hove}}
}
