@article {Arisholm.2006.3,
	title = {The Impact of UML Documentation on Software Maintenance: an Experimental Evaluation},
	journal = {IEEE Transactions on Software Engineering},
	volume = {32},
	number = {6},
	year = {2006},
	month = {June},
	pages = {365-381},
	abstract = {The Unified Modeling Language (UML) is becoming the de-facto standard for software analysis and design modeling. However, there is still a significant resistance to model-driven development in many software organizations as it is perceived to be expensive and not necessarily cost-effective. It is therefore important to investigate the benefits obtained through modeling. As a first step in this direction, this paper reports on controlled experiments, spanning across two locations, which investigate the impact of UML documentation on software maintenance. Results show that, for complex tasks and past a certain learning curve, the availability of UML documentation may result in significant improvements of the functional correctness of changes as well as their design quality. On the other hand, there does not seem to be any resulting time saving. For simpler tasks, the time needed to update the UML documentation may be substantial compared with the potential benefits, thus motivating the need for UML tools with better support for software maintenance.},
	author = {Arisholm, Erik and Briand, Lionel and Siw Elisabeth {Hove} and Labiche, Yvan}
}
@article {Karahasanovic.2005.2,
	title = {Collecting Feedback During Software Engineering Experiments},
	journal = {Empirical Software Engineering},
	volume = {10},
	number = {2},
	year = {2005},
	pages = {113-147},
	abstract = {Objective: To improve the qualitative data obtained from software engineering experiments by gathering feedback during experiments. Rationale: Existing techniques for collecting quantitative and qualitative data from software engineering experiments do not provide sufficient information to validate or explain all our results. Therefore, we would like a cost-effective and unobtrusive method of collecting feedback from subjects during an experiment to augment other sources of data. Design of study: We formulated a set of qualitative questions that might be answered by collecting feedback during software engineering experiments. We then developed a tool to collect such feedback from experimental subjects. This feedback-collection tool was used in four different experiments and we evaluated the usefulness of the feedback obtained in the context of each experiment. The feedback data was triangulated with other sources of quantitative and qualitative data collected for the experiments. Results: We have demonstrated that the collection of feedback during experiments provides useful additional data to: validate the data obtained from other sources about solution times and quality of solutions; check process conformance; understand problem solving processes; identify problems with experiments; and understand subjects{\textquoteright} perception of experiments. Conclusions: Feedback collection has proved useful in four experiments and we intend to use the feedback-collection tool in a range of other experiments to further explore the cost-effectiveness and limitations of this technique. It is also necessary to carry out a systematic study to more fully understand the impact of the feedback-collecting tool on subjects{\textquoteright} performance in experiments.},
	author = {Karahasanovic, Amela and Anda, Bente Cecilie Dahlum and Arisholm, Erik and Siw Elisabeth {Hove} and J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup and Welland, Ray}
}
@inproceedings {Hove.2005.1,
	title = {Experiences From Conducting Semi-Structured Interviews in Empirical Software Engineering Research},
	journal = {11th IEEE International Software Metrics Symposium (METRICS 2005), 19-22 September, Como, Italy},
	year = {2005},
	month = {September, 2005},
	pages = {23(1-10)},
	publisher = {IEEE},
	type = {Conference},
	abstract = {Many phenomena related to software development are qualitative in nature. Relevant measures of such phenomena are often collected using semi-structured interviews. Such interviews involve high costs, and the quality of the collected data is related to how the interviews are conducted. Careful planning and conducting of the interviews are therefore necessary, and experiences from interview studies in software engineering should consequently be collected and analyzed to provide advice to other researchers. We have brought together experiences from 12 software engineering studies, in which a total of 280 interviews were conducted. Four areas were particularly challenging when planning and conducting these interviews; estimating the necessary effort, ensuring that the interviewer had the needed skills, ensuring good interaction between interviewer and interviewees, and using the appropriate tools and project artifacts. The paper gives advice on how to handle these areas and suggests what information about the interviews should be included when reporting studies where interviews have been used in data collection. Knowledge from other disciplines is included. By sharing experience, knowledge about the accomplishments of software engineering interviews is increased and hence, measures of high quality can be achieved.},
	isbn = {0-7695-2371-4},
	author = {Siw Elisabeth {Hove} and Anda, Bente Cecilie Dahlum},
	editor = {Hove, Anda}
}
@techreport {Arisholm.2005.2,
	title = {The Impact of UML Documentation on Software Maintenance: an Experimental Evaluation},
	number = {2005-14},
	year = {2005},
	month = {August},
	publisher = {Simula Research Laboratory},
	abstract = {The Unified Modeling Language (UML) is becoming the de-facto standard for software analysis and design modeling. However, there is still a significant resistance to model-driven development in many software organizations as it is perceived to be expensive and not necessarily cost-effective. It is therefore important to investigate the benefits obtained through modeling. As a first step in this direction, this paper reports on controlled experiments, spanning across two locations, which investigate the impact of UML documentation on software maintenance. Results show that, for complex tasks and passed a certain learning curve, the availability UML documentation may result into significant improvements of the functional correctness of changes as well as their design quality. On the other hand, there does not seem to be any resulting time saving. For simpler tasks, the time needed to update the UML documentation may be substantial compared with the potential benefits, thus motivating the need for UML tools with better support for performing model changes.},
	author = {Arisholm, Erik and Briand, Lionel and Siw Elisabeth {Hove} and Labiche, Yvan}
}
@inproceedings {Anda.2005.6,
	title = {A Multiple-Case Study of Effort Estimation Based on Use Case Points},
	journal = {ISESE{\textquoteright}2005 (Fourth International Symposium on Empirical Software Engineering)},
	year = {2005},
	pages = {407-416},
	publisher = {IEEE Computer Society, Noosa, Australia, November 17-18},
	type = {1},
	abstract = {There is much interest in industry for the estimation of software development effort based on use cases, but little scientific evaluation of applying use cases in estimation has been reported. We investigated one particular method, the use case points method, in a multiple-case study. The Software Engineering Department at Simula issued a tender for a system, and 35 companies responded, with estimates ranging from 78 to 654 hours. We chose four companies to develop the system. They all implemented the same functionality, but their development processes varied, ranging from a light, mainly code-and-fix process, to a heavy process with much emphasis on analysis and design. The use case points method estimated this project to 430 hours. This was equal to the actual effort spent on implementing the system by the company with the lightest development process. In our opinion, the results from this study may represent a basis for measuring size of the use cases and choosing productivity factor (hours per use case point) when estimating based on use cases. The three other companies spent 587, 829 and 943 hours respectively, showing that a heavier development process and more emphasis on non-functional requirements may increase effort by more than 100\%.},
	author = {Anda, Bente Cecilie Dahlum and Hans Christian {Benestad} and Siw Elisabeth {Hove}}
}
@techreport {Karahasanovic.2003.3,
	title = {A Think-Aloud Support Tool for Collecting Feedback in Large-Scale Software Engineering Experiments},
	number = {2003-7},
	year = {2003},
	publisher = {Simula Research Laboratory},
	abstract = {The think-aloud method has proven useful for studying how a technology is used. However, it is labour-intensive and makes demands on resources for studies with many subjects. This paper describes a tool, called the think-aloud tool, that we have developed to support the collection of feedback from subjects in large-scale software engineering experiments. This tool instructs the subjects, at regular intervals, to write down their thoughts on a web-based screen and collects their feedback. An empirical evaluation of this tool is reported. The results from four controlled experiments suggest that the think-aloud tool is a valuable means for increasing the quality of large-scale software engineering experiments. The results also indicate that the participants were mostly positive to the tool and had no significant problems in verbalising their thoughts. The tool we proposed adds to an available set of tools for data collection in software engineering experiments. Whereas we have experience with the think-aloud tool in software engineering experiments, there is also potential for using such a tool in other areas in which the think-aloud method is used in studies involving a computer system.},
	author = {Karahasanovic, Amela and Anda, Bente Cecilie Dahlum and Arisholm, Erik and Siw Elisabeth {Hove} and J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
