@article {28159,
	title = {Benefits management in software development: A systematic review of empirical studies},
	journal = {IET Software},
	volume = {15},
	year = {2021},
	pages = {1-24},
	publisher = {IET},
	abstract = {Considerable resources are wasted on software projects delivering less than the planned benefits. Herein, the objective is to synthesize empirical evidence of the adoption and impact of benefits management (BM) in software development, and to suggest directions for future research. A systematic review of the literature is performed and identified 4836 scientific papers of which the authors found 47 to include relevant research. While most organizations identify and structure benefits at the outset of a project, fewer organizations report implementing BM as a continuous process throughout the project lifecycle. Empirical evidence gives support for positive impact on project outcome from the following BM practices: identifying and structuring benefits, planning benefits realization, BM during project execution, benefits evaluation and the practice of having people responsible for benefits realization. The authors suggest four research directions to understand (1) why BM practices sometimes not are adopted, (2) BM in relation to other management practices, (3) BM in agile software development and (4) BM in the context of organizations{\textquoteright} value creation logics.},
	author = {Holgeid, Kjetil and J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup and Krogstie, John}
}
@article {Simula.simula.2758,
	title = {Incorrect Results in Software Engineering Experiments: How to Improve Research Practices},
	journal = {Journal of Systems and Software},
	volume = {117},
	year = {2016},
	pages = {274-281},
	publisher = {Elsevier},
	abstract = {Context: The trustworthiness of research results is a growing concern in many empirical disciplines. Aim: The goals of this paper are to assess how much the trustworthiness of results reported in software engineering experiments is affected by researcher and publication bias and to suggest improved research practices. Method: First, we conducted a small-scale survey to document the presence of researcher and publication biases in software engineering experiments. Then, we built a model that estimates the proportion of correct results for different levels of researcher and publication bias. A review of 150 randomly selected software engineering experiments published in the period 2002-2012 was conducted to provide input to the model. Results: The survey indicates that researcher and publication bias is quite common. This finding is supported by the observation that the actual proportion of statistically significant results reported in the reviewed papers was about twice as high as the one expected assuming no researcher and publication bias. Our models suggest a high proportion of incorrect results even with quite conservative assumptions. Conclusion: Research practices must improve to increase the trustworthiness of software engineering experiments. A key to this improvement is to avoid conducting studies with unsatisfactory low statistical power.},
	author = {J{\o}rgensen, Magne and Dyb{\r a}, Tore and Liest{\o}l, Knut and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Simula.simula.2934,
	title = {Construction and Validation of an Instrument for Measuring Programming Skill},
	journal = {IEEE Transactions on Software Engineering},
	year = {2014},
	publisher = {IEEE Transactions on Software},
	abstract = {Skilled workers are crucial to the success of software development. The current practice in research and industry for assessing programming skills is mostly to use proxy variables of skill, such as education, experience, and multiple-choice knowledge tests. There is as yet no valid and efficient way to measure programming skill. The aim of this research is to develop a valid instrument that measures programming skill by inferring skill directly from the performance on programming tasks. Over two days, 65 professional developers from eight countries solved 19 Java programming tasks. Based on the developers{\textquoteright} performance, the Rasch measurement model was used to construct the instrument. The instrument was found to have satisfactory (internal) psychometric properties and correlated with external variables in compliance with theoretical expectations. Such an instrument has many implications for practice, for example, in job recruitment and project allocation.},
	author = {Gunnar Rye {Bergersen} and Sj{\o}berg, Dag Ingar Kondrup and Dyb{\r a}, Tore}
}
@article {Simula.simula.1460,
	title = {Quantifying the Effect of Code Smells on Maintenance Effort},
	journal = {IEEE Transactions on Software Engineering},
	volume = {39},
	number = {8},
	year = {2012},
	pages = {1144-1156},
	abstract = {Context: Code smells are assumed to indicate bad design that leads to less maintainable code. However, this assumption has not been investigated in controlled studies with professional software developers. Aim: Our aim was to investigate the relationship between code smells and maintenance effort. Method: Six developers were hired to perform three maintenance tasks each on four functionally equivalent Java systems originally implemented by different companies. Each developer spent three to four weeks. In total, they modified 298 Java files in the four systems. An Eclipse IDE plug-in measured the exact amount of time a developer spent maintaining each file. A regression was used to explain the effort using file properties, including the number of smells. Results: None of the 12 investigated smells was significantly associated with increased effort after we adjusted for file size and the number of changes; Refused Bequest was significantly associated with decreased effort. File size and the number of changes explained most of the variation in effort. Conclusion: The effects of code smells on maintenance effort are limited. In general, to reduce maintenance effort, focusing on code size and the work practices that limit the number of changes may be more beneficial than refactoring code smells.},
	doi = {10.1109/TSE.2012.89},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Yamashita, Aiko and Anda, Bente Cecilie Dahlum and Mockus, Audris and Dyb{\r a}, Tore}
}
@inproceedings {Simula.prepare.14,
	title = {Inferring Skill From Tests of Programming Performance: Combining Time and Quality},
	journal = {Proc. 5th Int{\textquoteright}l Symp.Empirical Software Engineering and Measurement (ESEM)},
	year = {2011},
	pages = {305-314},
	publisher = {IEEE Computer Society},
	type = {Conference},
	abstract = {The skills of software developers are crucial to the success of software projects. Also, controlling for individual differences is important when studying the general effect of a method or a tool. However, the way skill is determined in industry and research settings is often ad hoc or based on unvalidated methods. According to established test theory, validated tests of skill should infer skill levels from welldefined performance measures on multiple small, representative tasks. We show how time and quality can be meaningfully combined as task performance, and subsequently aggregated into an approximate measure of programming skill. Our results show significant and positive correlations between our proposed measures of skill and variables such as seniority, lines of code written, and self-evaluated expertise. The method for combining time and quality are a promising first step to measuring programming skill in industry and research settings.},
	isbn = {978-1-4577-2203-5},
	author = {Gunnar Rye {Bergersen} and Jo Erskine {Hannay} and Sj{\o}berg, Dag Ingar Kondrup and Dyb{\r a}, Tore and Karahasanovic, Amela}
}
@article {Karahasanovic.2006.5,
	title = {Comparing of Feedback Collection and Think-Aloud Methods in Program Comprehension Studies},
	journal = {Behaviour \& Information Technology},
	volume = {28},
	number = {2},
	year = {2009},
	month = {March-April},
	pages = {139-164},
	publisher = {The University of Western Australia},
	abstract = {This paper reports an explorative experimental comparison of (i) an experience-sampling method called feedback collection and (ii) the think-aloud methods with respect to their usefulness in studies on program comprehension. Think-aloud methods are widely used in studies of cognitive processes, including program comprehension. Alternatively, as in the feedback-collection method (FCM), cognitive processes can be traced by collecting written feedback from the subjects at regular intervals. We compare FCM with concurrent think-aloud (CTA) and retrospective think-aloud (RTA) regarding type and usefulness of the collected information, costs related to analysis of the collected information, and effects of the data collection methods on the subjects\&$\#$39; performance. FCM allowed us to identify a greater number of comprehension problems that prevented progress or caused significant delay (FCM: 30 problems; CTA: 5; RTA: 15). It was less precise in identifying strategies for comprehension than CTA (92\% correctness for FCM; 100\% for CTA). FCM was less expensive in analysis (transcription and coding) than the other two methods (FCM: 0,7 hours of analysis per protocol; CTA: 31 hours; RTA: 7,9 hours). The results indicate that all three methods of data collection were intrusive and affected the performance of the subjects with respect to time and correctness (small to medium effect size). This research confirms that FCM can be used beneficially in studies that trace the cognitive processes involved in, and identify problems related to, the comprehension of software applications. Based on our experience, we recommend that FCM be used in studies that have a large number of subjects and as a complement to other methods for tracing cognitive processes, such as user log files. We recommend a design with two groups (verbalization and silent control) and a pretest task to be used in studies with FCM or CTA that focus on performances.},
	author = {Karahasanovic, Amela and Unni Nyhamar {Hinkel} and Sj{\o}berg, Dag Ingar Kondrup and Thomas, Richard}
}
@article {Simula.SE.435,
	title = {Confronting the Myth of Rapid Obsolescence in Computing Research},
	journal = {Communications of the ACM},
	volume = {53},
	number = {9},
	year = {2009},
	pages = {62-67},
	publisher = {ACM},
	abstract = {By 1999, Microsoft had already become the world\&$\#$39;s largest company measured by stock-market value. Now, the Internet is offering us new services every day. Computing technologies have moved on and are rapidly changing our social, political, economic, and cultural worlds [13]. Accompanying this observation is the common belief that research in computing makes progress more rapidly, and just as rapidly becomes more obsolete, than research in other disciplines. One indicator of how fast research becomes obsolete is how quickly reports of it cease to be cited in the literature. Common measures of this phenomenon are cited half-life, citing half-life, and the Price Index. Interestingly, and contrary to popular belief, these measures indicate that research in computing does not cease to be cited any more quickly than research in other disciplines. Therefore, research in computing does not become obsolete any more quickly than research in other disciplines. The extent to which this is the case is important for a number of reasons: 1) Although there have been tremendous achievements in the history of computing, there is an exponentially increasing demand for complex, reliable, robust, and usable hardware and software systems in society. The advances in computing technology that need to be made to meet this demand depend on the long-term funding of fundamental research [11]. However, it seems very difficult to convince funding bodies to support long-term fundamental research programmes and projects in computing. One reason may be the already rapid development in computing applications. This may be taken to indicate that research in computing is less difficult than in other disciplines and that as a result, progress can be made with less funding that other disciplines receive. Hence, as has been reported in the context of NSF, when fighting for research money, we computer scientists must argue on the one hand for the practical conclusion that society has a strong need for the results of our research, while on the other, for the identity of computer science as a basic research discipline to maintain respect within the scientific community [18]. In particular, in a university setting, when competing for funding with researchers from other sciences, we must counter the argument that basic research funding in computing will not be prioritized because everything that is useful is being done both faster and better by the IT industry anyway. 2) Literature that is still relevant may be considered obsolete, and thereby ignored, merely on the grounds that it is old. As a researcher and journal editor, I have found that reviewers comment on \&ldquo;old references\&rdquo; fairly frequently, and as a supervisor, I have found that PhD students often are reluctant to read older literature.},
	doi = {10.1145/1810891.1810911},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@misc {Simula.SE.413,
	title = {Control Versus Realism in Software Engineering Studies: Experiences From Simula Research Laboratory},
	howpublished = {Keynote address},
	year = {2009},
	month = {January},
	abstract = {Keynote address, Software Engineering Observatory Workshop, Sheffield, UK. \&nbsp; Control versus Realism in Software Engineering Studies: Experiences from Simula Research Laboratory \&nbsp; http://observatory.group.shef.ac.uk/workshop2009},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Simula.SE.309,
	title = {The Effectiveness of Pair-Programming: a Meta-Analysis},
	journal = {Information and Software Technology},
	volume = {55},
	number = {7},
	year = {2009},
	month = {June},
	pages = {1110-1122},
	abstract = {Several experiments on the effects of pair versus solo programming have been reported in the literature. We present a metaanalysis of these studies. The analysis shows a small significant positive overall effect of pair programming on quality, a medium significant positive overall effect on duration, and a medium significant negative overall effect on effort. However, between-study variance is significant, and there are signs of publication bias among published studies on pair programming. A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high. The higher quality for complex tasks comes at a price of considerably greater effort, while the reduced completion time for the simpler tasks comes at a price of noticeably lower quality. We conclude that greater attention should be given to moderating factors on the effects of pair programming.},
	author = {Jo Erskine {Hannay} and Dyb{\r a}, Tore and Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Simula.SE.305,
	title = {Effects of Personality on Pair Programming},
	journal = {IEEE Transactions on Software Engineering},
	volume = {36},
	number = {1},
	year = {2009},
	pages = {61-80},
	abstract = {Personality tests in various guises are commonly used in recruitment and career counseling industries. Such tests have also been considered as instruments for predicting programming and team performance in software engineering. However, research suggests that other human-related factors, such as motivation, general mental ability, expertise and task complexity also affect performance in general. This paper reports on a study of the impact of Big-Five personality traits on the performance of pair programmers together with the impact of expertise and task complexity. The study involved 196 software professionals from three countries forming 98 pairs. The analysis consisted of a confirmatory part and an exploratory part, and the results show that (1) our data does not confirm a meta-analysis-based model of the impact of certain personality traits on performance, and (2) personality traits in general have modest predictive value on pair programming performance compared with expertise, task complexity, and even country. Rather than focusing on direct effects of personality on pair programming performance, we conclude that (a) effort should be spent on elaborating on personality{\textquoteright}s (and other factors{\textquoteright}) indirect effects on performancemediated by formalized scales of collaboration, and (b) more effort should be spent on investigating other performance-related predictors such as programming skill, learning, motivation, expertise, and task complexity.},
	author = {Jo Erskine {Hannay} and Arisholm, Erik and Engvik, Harald and Sj{\o}berg, Dag Ingar Kondrup}
}
@misc {Simula.SE.411,
	title = {Experiences From Empirical Studies at Simula Research Laboratory},
	howpublished = {Invited lecture},
	year = {2009},
	month = {January},
	abstract = {Experiences from Empirical Studies at Simula Research Laboratory. Invited Lecture, University of Castilla-La Mancha, Ciudad Real, Spain},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@inbook {Simula.SE.447,
	title = {The Industry Is Our Lab - Organization and Conducting of Empirical Studies in Software Engineering at Simula},
	booktitle = {Simula Research Laboratory - by thinking constantly about it},
	year = {2009},
	pages = {443-458},
	publisher = {Springer},
	organization = {Springer},
	chapter = {29},
	address = {Heidelberg},
	abstract = {The society is completely dependent on reliable and efficient software. Development of such software requires the use of appropriate processes, method and tools. To evaluate their appropriateness in various industrial settings, empirical studies are needed. At present, most studies in software engineering are run with students in artificial settings. The strategy of Simula Research Laboratory to invest in experiment infrastructures and hire professionals as subjects has contributed to a significant improvement of state of the art regarding the realism and scale of experiments and control in real-life case studies. During its first eight years, Simula has conducted studies that have included about 6000 professional software developers and managers from 273 companies in 25 countries. However, increasing the realism of tasks and systems in experiments and control in case studies is still a challenge for Simula and the rest of the research community.},
	isbn = {978-3-642-01155-9},
	author = {Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Tveito, Aslak and Are Magnus {Bruaset} and Lysne, Olav}
}
@inbook {Simula.SE.637,
	title = {Software Engineering: Why - How - What - What{\textquoteright}s Next},
	booktitle = {Simula Research Laboratory - by thinking constantly about it},
	year = {2009},
	pages = {363-368},
	publisher = {Springer},
	organization = {Springer},
	chapter = {24},
	isbn = {ISBN: 978-3642011559},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Grimstad, Stein},
	editor = {Tveito, Aslak and Are Magnus {Bruaset} and Lysne, Olav}
}
@article {Simula.SE.124,
	title = {A Systematic Review of Quasi-Experiments in Software Engineering},
	journal = {Information and Software Technology},
	volume = {51},
	number = {1},
	year = {2009},
	month = {January},
	pages = {71-82},
	author = {Vigdis By {Kampenes} and Dyb{\r a}, Tore and Jo Erskine {Hannay} and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {Simula.SE.617,
	title = {Using Concept Mapping for Maintainability Assessments},
	journal = {3rd IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)},
	year = {2009},
	month = {October 2009},
	publisher = {IEEE},
	type = {Conference},
	abstract = {Many important phenomena within software engineering are difficult to define and measure. A good example is software maintainability, which has been the subject of considerable research and is believed to be a critical determinant of total software costs. Yet, there is no common agreement on how to describe and measure software maintainability in a concrete setting. We propose using concept mapping, a well-grounded method used in social research, to operationalize this concept according to a given goal and perspective. We apply this method to describe four systems that were developed as part of an industrial multiple-case study. The outcome is a conceptual map that displays an arrangement of maintainability constructs, their interrelations and corresponding measures. Our experience is that concept mapping (1) provides a structured way of combining static code analysis and expert judgment; (2) helps tailoring the choice of measures to a particular system context; and (3) supports the mapping between software measures and aspects of software maintainability. As such, it represents a strong addition to existing frameworks for evaluating quality such as ISO/IEC 9126 and GQM, and tools for static measurement of software code. Overall, we find that concept mapping provides a systematic, structured and repeatable method for developing constructs and measures of the phenomenon of interest, and we deem it useful for defining constructs and measures of other aspects of software engineering, in addition to maintainability.},
	isbn = {10.1109/ESEM.2009.5316044},
	author = {Yamashita, Aiko and Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup and Hans Christian {Benestad} and Per Einar {Arnstad} and Moonen, Leon},
	editor = {Miller, James and Selby, Rick}
}
@article {Simula.SE.195,
	title = {Variability and Reproducibility in Software Engineering: a Study of Four Companies That Developed the Same System},
	journal = {IEEE Transactions on Software Engineering},
	volume = {35},
	number = {3},
	year = {2009},
	pages = {407-429},
	publisher = {IEEE},
	abstract = {The scientific study of a phenomenon requires it to be reproducible. Mature engineering industries are recognized by projects and products that are, to some extent, reproducible. However, reproducibility in software engineering (SE) has not been thoroughly investigated, although generalizing the results of SE studies depend on SE phenomena being reproducible. We report a longitudinal multiple-case study of variations and reproducibility in software development, from bidding to deployment, on the basis of the same requirements specification. In a call for tender to 81 consultancy companies, 35 responded. Four of them developed the system independently. The firm price, planned schedule, and planned development process, had, respectively, \&ldquo;low\&rdquo;, \&ldquo;low\&rdquo;, and \&ldquo;medium\&rdquo; reproducibility. The contractor\&$\#$39;s internal costs, actual lead time, and schedule overrun of the projects had, respectively, \&ldquo;medium\&rdquo;, \&ldquo;high\&rdquo;, and \&ldquo;low\&rdquo; reproducibility. The quality dimensions of the delivered products, reliability, usability, and maintainability had, respectively, \&ldquo;low\&rdquo;, \&ldquo;high\&rdquo;, and \&ldquo;low\&rdquo; reproducibility. We proposed a coarse-grained model that uses software process inputs to predict key project outcomes. The comparisons of the model\&$\#$39;s predictions with the actual outcomes indicate some reproducibility. This initial work may contribute to developing more accurate models, but making SE more reproducible remains a great challenge for SE research, education, and industry.},
	doi = {10.1109/TSE.2008.89 },
	author = {Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup and Mockus, Audris}
}
@book {Shull.2007.1,
	title = {Advanced Topics in Empirical Software Engineering},
	year = {2008},
	publisher = {Springer},
	abstract = {Empirical studies have become an integral element of software engineering research and practice. This unique text/reference includes chapters from some of the top international empirical software engineering researchers and focuses on the practical knowledge necessary for conducting, reporting and using empirical methods in software engineering.},
	isbn = {13:978-1-84800-043-8},
	author = {Shull, Forrest and Singer, Janice and Sj{\o}berg, Dag Ingar Kondrup}
}
@inbook {Sjoberg.2007.1,
	title = {Building Theories in Software Engineering},
	booktitle = {Advanced Topics in Empirical Software Engineering},
	year = {2008},
	pages = {312-336},
	publisher = {Springer},
	organization = {Springer},
	chapter = {12},
	abstract = {Empirical studies have become an integral element of software engineering research and practice. This unique text/reference includes chapters from some of the top international empirical software engineering researchers and focuses on the practical knowledge necessary for conducting, reporting and using empirical methods in software engineering.},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Dyb{\r a}, Tore and Anda, Bente Cecilie Dahlum and Jo Erskine {Hannay}},
	editor = {Shull, Forrest and Singer, Janice and Sj{\o}berg, Dag Ingar Kondrup}
}
@inbook {Simula.SE.211,
	title = {Reporting Experiments in Software Engineering},
	booktitle = {Guide to Advanced Empirical Software Engineering},
	year = {2008},
	pages = {201-228},
	publisher = {Springer},
	organization = {Springer},
	chapter = {8},
	author = {Jedlitschka, Andreas and Ciolkowski, Marcus and Pfahl, Dietmar},
	editor = {Shull, Forrest and Singer, Janice and Sj{\o}berg, Dag Ingar Kondrup}
}
@inbook {Simula.SE.210,
	title = {Simulation Methods},
	booktitle = {Guide to Advanced Empirical Software Engineering},
	year = {2008},
	pages = {117-152},
	publisher = {Springer},
	organization = {Springer},
	chapter = {5},
	author = {Mueller, Mark and Pfahl, Dietmar},
	editor = {Shull, Forrest and Singer, Janice and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Simula.SE.197,
	title = {Usability Inspection: a Comparative Study of the Evaluator Performance of Work-Domain Experts Vs. Usability Experts},
	journal = {journal},
	year = {2008},
	abstract = {When applications that are tailored to work domains of which usability experts have little knowledge are evaluated, the usefulness of usability inspection methods is challenged. To counter this challenge, usability inspections with work-domain experts have been explored, but no empirical research has been reported on such experts{\textquoteright} performance as evaluators. The present study compares the performance of work-domain experts and usability experts, with respect to the validity and thoroughness of their evaluations. Fifteen work-domain experts and 12 usability experts participated. The applied inspection method was group-based expert walkthrough. The basis for comparison was user test results. The work-domain experts produced equally valid but less thorough evaluation results than the usability experts. On average, two work-domain experts produced results of similar quality to those of one usability expert, which implies that work-domain experts may substitute for usability experts if the number of evaluators is increased. These results should be taken into account when developing future usability inspection methods with work-domain experts as evaluators.},
	author = {F{\o}lstad, Asbj{\o}rn and Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Simula.SE.162,
	title = {Are Two Heads Better Than One? on the Effectiveness of Pair Programming},
	journal = {IEEE Software},
	volume = {24},
	number = {6},
	year = {2007},
	month = {November/December},
	pages = {12-15},
	author = {Dyb{\r a}, Tore and Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup and Jo Erskine {Hannay} and Shull, Forrest}
}
@inbook {Simula.SE.10,
	title = {Documenting Theories},
	booktitle = {Empirical Software Engineering Issues: Critical Assessment and Future Directions},
	series = {LNCS 4336},
	year = {2007},
	pages = {111-114},
	publisher = {Springer},
	organization = {Springer},
	address = {Berlin Heidelberg},
	author = {Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Basili, V.R. and Rombach, D. and Schneider, K. and Kitchenham, Barbara and Pfahl, D. and Selby, R.}
}
@article {Arisholm.2006.2,
	title = {Evaluating Pair Programming With Respect to System Complexity and Programmer Expertise},
	journal = {IEEE Transactions on Software Engineering},
	volume = {33},
	number = {2},
	year = {2007},
	month = {February},
	pages = {65-86},
	abstract = {A total of 295 junior, intermediate and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions, but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors.},
	author = {Arisholm, Erik and Hans Enger {Gallis} and Dyb{\r a}, Tore and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {Simula.SE.13,
	title = {The Future of Empirical Methods in Software Engineering Research},
	journal = {Future of Software Engineering (FOSE {\textquoteright}07)},
	year = {2007},
	month = {May},
	pages = {358-378},
	publisher = {IEEE-CS Press},
	type = {Conference},
	abstract = {We present the vision that for all fields of software engineering (SE), empirical research methods should enable the development of scientific knowledge about how useful different SE technologies are for different kinds of actors, performing different kinds of activities, on different kinds of systems. It is part of the vision that such scientific knowledge will guide the development of new SE technology and is a major input to important SE decisions in industry. Major challenges to the pursuit of this vision are: more SE research should be based on the use of empirical methods; the quality, including relevance, of the studies using such methods should be increased; there should be more and better synthesis of empirical evidence; and more theories should be built and tested. Means to meet these challenges include (1) increased competence regarding how to apply and combine alternative empirical methods, (2) tighter links between academia and industry, (3) the development of common research agendas with a focus on empirical methods, and (4) more resources for empirical research.},
	isbn = {432663526},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Dyb{\r a}, Tore and J{\o}rgensen, Magne},
	editor = {Briand, Leon and Wolf, A.}
}
@inbook {Simula.SE.11,
	title = {Knowledge Acquisition in Software Engineering Requires Sharing of Data and Artifacts},
	booktitle = {Empirical Software Engineering Issues: Critical Assessment and Future Directions},
	series = {LNCS 4336},
	year = {2007},
	pages = {77-82},
	publisher = {Springer},
	organization = {Springer},
	address = {Berlin Heidelberg},
	author = {Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Basili, V.R. and Rombach, D. and Schneider, K. and Kitchenham, Barbara and Pfahl, D. and Selby, R.}
}
@article {Basili.2006.1,
	title = {Protocols in the Use of Empirical Software Engineering Artifacts},
	journal = {Empirical Software Engineering},
	volume = {12},
	number = {1},
	year = {2007},
	month = {February},
	pages = {107-119},
	abstract = {If empirical software engineering is to grow as a valid scientific endeavor, the ability to acquire, use, share, and compare data collected from a variety of sources must be encouraged. This is necessary to validate the formal models being developed within computer science. However, within the empirical software engineering community this has not been easily accomplished. This paper analyses experiences from a number of projects, and defines the issues, which include the following: (1) How should data, testbeds, and artifacts be shared? (2) What limits should be placed on who can use them and how? How does one limit potential misuse? (3) What is the appropriate way to credit the organization and individual that spent the effort collecting the data, developing the testbed, and building the artifact? (4) Once shared, who owns the evolved asset? As a solution to these issues, the paper proposes a framework for an empirical software engineering artifact agreement. Such an agreement is intended to address the needs for both creator and user of such artifacts and should foster a market in making available and using such artifacts. If this framework for sharing software engineering artifacts is commonly accepted, it should encourage artifact owners to make the artifacts accessible to others (gaining credit is more likely and misuse is less likely). It may be easier for other researchers to request artifacts since there will be a well-defined protocol for how to deal with relevant matters.}, and defines the issues, which include the following = {(1) How should data, testbeds, and},
	author = {Basili, Victor and Zelkowitz, Marvin and Sj{\o}berg, Dag Ingar Kondrup and Johnson, Philip and Cowling, Tony}
}
@article {Kampenes.2006.1,
	title = {A Systematic Review of Effect Size in Software Engineering Experiments},
	journal = {Information and Software Technology},
	volume = {49},
	number = {11-12},
	year = {2007},
	pages = {1073-1086},
	author = {Vigdis By {Kampenes} and Dyb{\r a}, Tore and Jo Erskine {Hannay} and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Hannay.2006.1,
	title = {A Systematic Review of Theory Use in Software Engineering Experiments},
	journal = {IEEE Transactions on Software Engineering},
	volume = {33},
	number = {2},
	year = {2007},
	month = {February},
	pages = {87-107},
	abstract = {Empirically-based theories are generally perceived as foundational to science. However, in many disciplines, the nature, role and even the necessity of theories remain matters for debate, particularly in young or practical disciplines such as software engineering. This article reports a systematic review of the explicit use of theory in a comprehensive set of 103 articles reporting controlled experiments, from of a total of 5,453 articles published in major software engineering journals and conferences in the decade 1993-2002. Of the 103 articles, 24 use a total of 39 theories in various ways to explain the cause-effect relationship(s) under investigation. The majority of these use theory in the experimental design to justify research questions and hypotheses; some use theory to provide \emph{post-hoc} explanations of their results; while a few test or modify theory. A third of the theories are proposed by authors of the reviewed articles. The interdisciplinary nature of the theories used is greater than that of research in software engineering in general. We found that theory use and awareness of theoretical issues are present, but that theory-driven research is, as yet, not a major issue in empirical software engineering. Several articles comment explicitly on the lack of relevant theory. We call for an increased awareness of the potential benefits of involving theory, when feasible. To support software engineering researchers who wish to use theory, we give an overview that shows which of the reviewed articles on which topics use which theories for what purposes, as well as details of the theories{\textquoteright} characteristics.},
	author = {Jo Erskine {Hannay} and Sj{\o}berg, Dag Ingar Kondrup and Dyb{\r a}, Tore}
}
@inbook {Arisholm.2006.1,
	title = {Evaluating the Effect of a Delegated Versus Centralized Control Style on the Maintainability of Object-Oriented Software},
	booktitle = {Software Process Improvement: Results and Experience from the Field},
	year = {2006},
	pages = {379-406},
	publisher = {Springer},
	organization = {Springer},
	chapter = {20},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Conradi, Reidar and Dyb{\r a}, Tore and Sj{\o}berg, Dag Ingar Kondrup and Ulsund, Tor}
}
@inbook {Anda.2006.2,
	title = {Experiences From Introducing UML-Based Development in a Large Safety-Critical Project},
	booktitle = {Software Process Improvement. Results and Experiences from the Field},
	year = {2006},
	pages = {329-359},
	publisher = {Springer},
	organization = {Springer},
	chapter = {18},
	isbn = {3-540-32178-0},
	author = {Anda, Bente Cecilie Dahlum and Hansen, Kai and Gullesen, Ingolf and Hanne Kristin {Thorsen}},
	editor = {Conradi, Reidar and Dyb{\r a}, Tore and Sj{\o}berg, Dag Ingar Kondrup and Ulsund, Tor}
}
@inbook {Jorgensen.2006.9,
	title = {Expert Estimation of Software Development Work},
	booktitle = {Software Evolution and Feedback: Theory and Practice},
	year = {2006},
	pages = {489-503},
	publisher = {Wiley},
	organization = {Wiley},
	chapter = {25},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Nazim H. {Madhavji} and Fernandez-Ramli, Juan and Perry, Dewayne}
}
@article {Krogstie.2006.1,
	title = {A Longitudinal Study of General and Functional Maintenance in Norway},
	journal = {Information and Software Technology},
	volume = {48},
	number = {11},
	year = {2006},
	month = {November},
	pages = {993-1005},
	author = {Krogstie, John and Jahr, Arthur and Sj{\o}berg, Dag Ingar Kondrup}
}
@inbook {Karahasanovic.2006.2,
	title = {Revealing Object-Oriented Comprehension by Feedback Collection},
	booktitle = {Comprehensive Object-Oriented Learning. The Learner{\textquoteright}s Perspective},
	year = {2006},
	pages = {111-130},
	publisher = {Informing Science Press},
	organization = {Informing Science Press},
	chapter = {7},
	address = {California, USA},
	isbn = {83-922337-4-3},
	author = {Karahasanovic, Amela and Fjuk, A. and Sj{\o}berg, Dag Ingar Kondrup and Thomas, R.},
	editor = {Fjuk, A. and Kaasb{\o}ll, J.}
}
@misc {Sjoberg.2006.1,
	title = {The Simula Approach to Experimentation in Software Engineering},
	howpublished = {Keynote address at EASE{\textquoteright}2006},
	year = {2006},
	month = {April},
	abstract = {The ultimate goal of software engineering research is to support the private and public software industry in developing higher quality systems with improved timeliness in a more cost-effective and predictable way. One contribution of the empirical software engineering community to this overall goal is the conducting of experiments to evaluate and compare technologies (processes, methods, techniques, languages and tools) for planning, building and maintaining software. However, the applicability of the experimental results to industrial practice is, in most cases, hampered by the experiments{\textquoteright} lack of realism and scale regarding subjects, tasks, systems and environments. In this talk, I will discuss Simula Research Laboratory{\textquoteright}s strategy for addressing this challenge: (1) About 25\% of our budget is used for hiring software consultants as experimental subjects, mainly at the expense of employing a larger number of researchers. In the last five years, about 800 professionals from 60 companies in several countries have participated in 25 experiments (some of them very large, in order to identify the variances between sub-populations) in which the professionals worked under various controlled circumstances, such as the complexity of tasks and systems, the tools used, whether they worked in pairs, and so on. (2) A large investment in infrastructures and apparatus has been made to support the logistics of running large experiments and surveys, and to collect and organise data with minimal overhead. (3) A senior project manager has been employed to organise the experiments and the resulting data. To increase flexibility and save administrative overhead, Simula hires people on a short-term basis for assistance with, for example, particularly large or complex experiments. They could be students for clerical work or consultants who are particularly qualified for certain tasks, for example, a statistician. (4) Active collaboration with industry (in addition to hiring consultants), such as taking part in industry-managed research projects on software process improvement, and giving seminars and courses, has been considered important. The focus on publicising our research in the media and disseminating it through teaching has also resulted in Simula becoming well known in the Norwegian software industry. (5) Software engineering is typically performed by humans in organisations. Hence, we have established research collaborations with other disciplines, such as psychology, sociology and management.},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@book {Conradi.2006.3,
	title = {Software Process Improvement: Results and Experience From the Field},
	year = {2006},
	month = {March},
	publisher = {Springer},
	abstract = {For over a decade, software process improvement (SPI) has been promoted as an approach to improve systematically the way software is developed and managed. Mostly this research and the relevant experience reports have been focussed on large software companies. Conradi and his co-authors have collected the main results from four Norwegian industrial research and development projects on SPI carried out between 1996 and 2005, which, in contrast to other treatments, concentrated on small- and medium-sized companies, typically characterized by fast-changing environments and processes. The presentation is organized in five sections: general principles and methods of SPI, knowledge management for SPI, process modelling and electronic process guides, estimation methods, and object-oriented and component-based systems. A spectrum of empirical methods has been used, e.g. case studies, large-scale experiments, surveys and interviews, and action research. The book mainly targets researchers and graduate students in (empirical) software engineering, and software professionals working in development or quality assurance},
	isbn = {3-540-32178-0},
	author = {Conradi, Reidar and Dyb{\r a}, Tore and Sj{\o}berg, Dag Ingar Kondrup and Ulsund, Tor}
}
@article {Dyba.2006.1,
	title = {A Systematic Review of Statistical Power in Software Engineering Experiments},
	journal = {Information and Software Technology},
	volume = {48},
	number = {8},
	year = {2006},
	month = {August},
	pages = {745-755},
	abstract = {Statistical power is an inherent part of empirical studies that employ significance testing and is essential for the planning of studies, for the interpretation of study results, and for the validity of study conclusions. This paper reports a quantitative assessment of the statistical power of empirical software engineering research based on the 103 papers on controlled experiments (of a total of 5453 papers) published in nine major software engineering journals and three conference proceedings in the decade 1993-2002. The results show that the statistical power of software engineering experiments falls substantially below accepted norms as well as the levels found in the related discipline of information systems research. Given this study{\textquoteright}s findings, additional attention must be directed to the adequacy of sample sizes and research designs to ensure acceptable levels of statistical power. Furthermore, the current reporting of significance tests should be enhanced by also reporting effect sizes and confidence intervals.},
	author = {Dyb{\r a}, Tore and Vigdis By {Kampenes} and Sj{\o}berg, Dag Ingar Kondrup}
}
@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 {Benestad.2005.1,
	title = {How to Recruit Professionals As Subjects in Software Engineering Experiments},
	journal = {IRIS (Information Systems Research in Scandinavia), August 6-9, Kristiansand Norway},
	year = {2005},
	month = {August},
	publisher = {Department of Information Systems, Agder University College},
	type = {Conference},
	abstract = {Controlled experiments are the classical scientific method for identifying cause-effect relationships, and are complementary to case studies and surveys as a means to empirically evaluate information systems development methods and practices. Most controlled experiments that evaluate software development methods and practices use students as subjects. Using students as subjects is convenient. However, a common criticism of controlled experiments in which students are used as subjects is that it is difficult to generalize the results to industrial settings. Consequently, Simula Research Laboratory has included professionals as subjects in software engineering experiments. At present, more than 750 professional software developers from 46 software development organizations have participated in our experiments. From this experience we have identified three important principles for research groups that want to include professional software developers as subjects in controlled experiments. First, practical constraints must be considered when defining the target population of software developers. Second, the participating organizations must be offered flexibility and value using a planned communication strategy, in order to ensure adequately sized representative samples of organizations and individuals. Third, to ensure long-term, relationships with the organizations, high professional and ethical standards must be employed.},
	author = {Hans Christian {Benestad} and Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {E., Hustad and B.E., Munkvold and K., Rolland and L.S., Flak}
}
@article {Anda.2005.2,
	title = {Investigating the Role of Use Cases in the Construction of Class Diagrams},
	journal = {Empirical Software Engineering},
	volume = {10},
	number = {3},
	year = {2005},
	month = {July},
	pages = {285-309},
	abstract = {Several approaches have been proposed for the transition from functional requirements to object-oriented design. In a use case-driven development process, the use cases are important input to the identification of classes and their methods. There is, however, no established, empirically validated technique for the transition from use cases to class diagrams. One recommended technique is to derive classes by analyzing the use cases. It has, nevertheless, been reported that this technique leads to problems, such as the developers missing requirements and mistaking requirements for design. An alternative technique is to identify classes from a textual requirements specification and subsequently apply the use case model to validate the resulting class diagram. This paper describes two controlled experiments conducted to investigate these two approaches to applying a use case model in an object-oriented design process. The first experiment was conducted with 53 students as subjects. Half of the subjects used a professional modelling tool; the other half used pen and paper. The second experiment was conducted with 22 professional software developers as subjects, all of whom used one of several modelling tools. The first experiment showed that applying use cases to validate class diagrams constructed from textual requirements led to more complete class diagrams than did the derivation of classes from a use case model. In the second experiment, however, we found no such difference between the two techniques. In both experiments, deriving class diagrams from the use cases led to a better structure of the class diagrams. The results of the experiments therefore show that the technique chosen for the transition from use cases to class diagrams affect the quality of the class diagrams, but also that the effects of the techniques depend on the categories of developer applying it and on the tool with which the technique is applied.},
	author = {Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Sjoberg.2005.1,
	title = {A Survey of Controlled Experiments in Software Engineering},
	journal = {IEEE Transactions on Software Engineering},
	volume = {31},
	number = {9},
	year = {2005},
	month = {September},
	pages = {733-753},
	abstract = {The classical method for identifying cause-effect relationships is to conduct controlled experiments. This paper reports upon the present state of how controlled experiments in software engineering are conducted and the extent to which relevant information is reported. Among the 5,453 scientific articles published in 12 leading software engineering journals and conferences in the decade from 1993 to 2002, 103 articles (1.9 percent) reported controlled experiments in which individuals or teams performed one or more software engineering tasks. This survey quantitatively characterizes the topics of the experiments and their subjects (number of subjects, students versus professionals, recruitment, and rewards for participation), tasks (type of task, duration, and type and size of application) and environments (location, development tools). Furthermore, the survey reports on how internal and external validity is addressed and the extent to which experiments are replicated. The gathered data reflects the relevance of software engineering experiments to industrial practice and the scientific maturity of software engineering research.},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Jo Erskine {Hannay} and Hansen, Ove and Vigdis By {Kampenes} and Karahasanovic, Amela and Liborg, Nils-Kristian and Anette C. {Rekdal}}
}
@misc {Sjoberg.2005.2,
	title = {Use of Professionals in Experiments},
	howpublished = {Letter to Editor, IEEE Software, Sep/Oct, pp. 9-10},
	year = {2005},
	month = {Sep/Oct},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@article {Vokac.2004.2,
	title = {A Controlled Experiment Comparing the Maintainability of Programs Designed With and Without Design Patterns - a Replication in a Real Programming Environment},
	journal = {Empirical Software Engineering},
	volume = {9},
	number = {3},
	year = {2004},
	pages = {149-195},
	abstract = {Software "Design Patterns" seek to package proven solutions to design prob- lems in a form that makes it possible to find, adapt and reuse them. To support the industrial use of Design Patterns, this research investigates when, and how, using patterns is beneficial, and whether some patterns are more di\pmcult to use than others. This paper describes a replication of an earlier controlled experiment on Design Patterns in maintenance, with major extensions. Experimental realism was increased by using a real programming environment instead of pen and paper, and paid professionals from multiple major consultancy companies as subjects. Measurements of elapsed time and correctness were analyzed using regression models and an estimation method that took into account the correlations present in the raw data. Together with on-line logging of the subjects{\textquoteright} work, this made possible a better qualitative understanding of the results. The results indicate quite strongly that some patterns are much easier to understand and use than others. In particular, the Visitor pattern caused much confusion. Conversely, the patterns Observer and, to a certain extent, Decorator were grasped and used intuitively, even by subjects with little or no knowledge of patterns. The implication is that Design Patterns are not universally good or bad, but must be used in a way that matches the problem and the people. When approaching a program with documented Design Patterns, even basic training can improve both the speed and quality of maintenance activities},
	author = {Vok{\'a}c, Marek and Tichy, W. and Sj{\o}berg, Dag Ingar Kondrup and Arisholm, Erik and Aldrin, M.}
}
@techreport {Karahasanovic.2004.1,
	title = {A Controlled Experiment to Evaluate Feedback-Collection Tool in Software Engineering Research, Technical Report 2004-8, Simula Research Laboratory},
	number = {2004-8},
	year = {2004},
	note = {Technical Report 2004-8, Simula Research Laboratory},
	publisher = {Simula Research Laboratory},
	abstract = {Objective: To compare the feedback-collection method with think-aloud methods regarding effects on subjects{\textquoteright} performance and type of collected information in software engineering experiments. Rationale: Think-aloud methods provide a rich set of data about experiments but are time-consuming in data collection. Alternatively, subjects can be interrupted during experiments and asked for written feedback. However, there has been no systematic comparison of these methods. Design of study: We conducted a controlled experiment to evaluate three methods for qualitative data collection: feedback-collection, concurrent think-aloud and retrospective think-aloud. Results: There is no significant difference in subjects{\textquoteright} performance for the three data collection methods. The types of information gathered by these three methods differed; in particular, the feedback collection method provided more explanations about the problem-solving process and more information about subjects{\textquoteright} perceptions of the experiment. Conclusions: This research confirms that the feedback-collection method is an appropriate data collection method in software engineering experiments.},
	author = {Karahasanovic, Amela and Unni Nyhamar {Hinkel} and Sj{\o}berg, Dag Ingar Kondrup and Annette Kristin {Levine} and Thomas, Richard}
}
@inproceedings {SE.5.Karahasanovic.2004,
	title = {A Controlled Experiment to Evaluate the Reactivity and Usefulness of the Think-Aloud Tool},
	journal = {Information Resources Management Association International Conference (IRMA{\textquoteright}04), Human Computer Interaction Track},
	year = {2004},
	month = {May 23-26},
	pages = {1033-1034},
	publisher = {Idea Group Publishing},
	type = {1},
	address = {New Orleans, Louisiana, USA},
	abstract = {This paper presents ongoing work on the evaluation of a tool for collecting feedback in large-scale software engineering and program comprehension experiments. Two most important questions one can ask about a new verbal procedure are whether it is useful and whether it is reactive. We have developed a tool, called the think-aloud tool, to support the think-aloud method in a variety of experiments. This tool instructs the subjects at regular intervals to write down their thoughts on a web based screen, as opposed to the oral expression of thoughts in conventional think-aloud method. The tool collects the subjects\&$\#$39; feedback together with timestamps. This paper describes an experiment designed to investigate whether the think-aloud tool affects performance of the subjects and whether it collects information beyond that collected in traditional think-aloud and retrospective reports. Furthermore, we will conduct a qualitative comparison of mouse and keying rates with think-aloud and retrospective reports. In addition, the experiment aims to check for any effect from using the think-aloud tool on the subject\&$\#$39;s task-related understanding and problem solving.},
	author = {Karahasanovic, Amela and Fjuk, A. and Sj{\o}berg, Dag Ingar Kondrup and Thomas, R.}
}
@article {SE.4.Arisholm.2004.b,
	title = {Evaluating the Effect of a Delegated Versus Centralized Control Style on the Maintainability of Object-Oriented Software},
	journal = {IEEE Transactions on Software Engineering},
	volume = {30},
	number = {8},
	year = {2004},
	month = {August},
	pages = {521-534},
	abstract = {A fundamental question in object-oriented design is how to design maintainable software. According to expert opinion, a delegated control style, typically a result of responsibility-driven design, represents object-oriented design at its best, whereas a centralized control style is reminiscent of a procedural solution, or a {\textquotedblleft}bad{\textquotedblright} object-oriented design. This paper presents a controlled experiment that investigates these claims empirically. A total of 99 junior, intermediate and senior professional consultants from several international consultancy companies were hired for one day to participate in the experiment. To compare differences between (categories of) professionals and students, 59 students also participated. The subjects used professional Java tools to perform several change tasks on two alternative Java designs that had a centralized and delegated control style, respectively. The results show that the most skilled developers, in particular the senior consultants, require less time to maintain software with a delegated control style than with a centralized control style. However, more novice developers, in particular the undergraduate students and junior consultants, have serious problems understanding a delegated control style, and perform far better with a centralized control style. Thus, the maintainability of object-oriented software depends, to a large extent, on the skill of the developers who are going to maintain it. These results may have serious implications for object-oriented development in an industrial context: having senior consultants design object-oriented systems may eventually pose difficulties unless they make an effort to keep the designs simple, as the cognitive complexity of {\textquotedblleft}expert{\textquotedblright} designs might be unmanageable for less skilled maintainers.},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Joergensen.2004.c,
	title = {Generalization and Theory-Building in Software Engineering Research},
	journal = {Empirical Assessment in Software Engineering (EASE2004)},
	year = {2004},
	pages = {29-36},
	publisher = {IEE Proceedings},
	type = {1},
	abstract = {The main purpose of this paper is to generate discussions which may improve how we conduct empirical software engineering studies. Our position is that statistical hypothesis testing plays a too large role in empirical software engineering studies. The problems of applying statistical hypothesis testing in empirical software engineering studies is illustrated by the finding: Only 3 out of the 47 studies in Journal of Empirical Software Engineering which applied statistical hypothesis testing, were able to base their statistical testing on well-defined populations and random samples from those populations. The frequent use of statistical hypothesis testing may also have had unwanted consequences on the study designs, e.g., it may have contributed to a too low focus on theory building. We outline several steps we believe are useful for a change in focus from \&ldquo;generalizing from a random sample to a larger population\&rdquo; to \&ldquo;generalizing across populations through theory-building\&rdquo;},
	isbn = {0 86341 435 4},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Joergensen.2004.b,
	title = {The Impact of Customer Expectation on Software Development Effort Estimates},
	journal = {International Journal of Project Management},
	volume = {22},
	number = {4},
	year = {2004},
	month = {May},
	pages = {317-325},
	abstract = {The results from the study described in this paper suggest that customer expectations of a project{\textquoteright}s total cost can have a very large impact on human judgment-based estimates (expert estimates) of the most likely use of software development effort. The information that the customer expectations are not valid estimation information did not remove the impact. Surprisingly, the estimators did not notice this impact or assessed it to be low. An implication of the results is that the provision of realistic project estimate of most likely use of effort may require that the estimators do not know the customer{\textquoteright}s expectations of the total cost of the project.},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Anda.2003,
	title = {Applying Use Cases to Design Versus Validate Class Diagrams - a Controlled Experiment Using a Professional Modelling Tool},
	journal = {ISESE{\textquoteright}2003 (Second International Symposium on Empirical Software Engineering)},
	year = {2003},
	month = {September 30 - October 1},
	pages = {50-60},
	publisher = {IEEE Computer Society},
	type = {Conference},
	address = {Rome, Italy},
	abstract = {Several processes have been proposed for the transition from functional requirements to an object-oriented design, but these processes have been subject to little empirical validation. A use case driven development process is often recommended when applying UML. Nevertheless, it has been reported that this process leads to problems, such as the developers missing some requirements and mistaking requirements for design. This paper describes a controlled experiment, with 53 students as subjects, conducted to investigate two alternative processes for applying a use case model in an object-oriented design process. One process was use case driven, while the other was a responsibility-driven process in which the use case model was applied as a means of validating the resulting class diagram. Half of the subjects used the modelling tool Tau UML Suite from Telelogic; the other half used pen and paper. The results show that the validation process led to class diagrams implementing more of the requirements. The use case driven process did, however, result in class diagrams with a better structure. The results also show that those who used the modelling tool spent more time on constructing class diagrams than did those who used pen and paper. We experienced that it requires much more effort to organize an experiment with a professional modelling tool than with only pen and paper.},
	isbn = {not found},
	author = {Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {found, not}
}
@inbook {Sjoberg.2003.1,
	title = {Challenges and Recommendations When Increasing the Realism of Controlled Software Engineering Experiments},
	booktitle = {Empirical Methods and Studies in Software Engineering: Experiences from ESERNET},
	series = {Lecture Notes in Computer Science, Volume 2765},
	year = {2003},
	pages = {24-38},
	publisher = {Springer},
	organization = {Springer},
	chapter = {Part II: Method Chapters},
	address = {Berlin / Heidelberg},
	abstract = {An important goal of most empirical software engineering experiments is the transfer of the research results to industrial applications. To convince industry about the validity and applicability of the results of controlled software engineering experiments, the tasks, subjects and the environments should be as realistic as practically possible. Such experiments are, however, more demanding and expensive than experiments involving students, small tasks and pen-and-paper environments. This chapter describes challenges of increasing the realism of controlled experiments and lessons learned from the experiments that have been conducted at Simula Research Laboratory.},
	isbn = {978-3-540-40672-3},
	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 Vok{\'a}c, Marek},
	editor = {Conradi, Reidar and Alf Inge {Wang}}
}
@techreport {SE.7.Arisholm.2003.b,
	title = {A Controlled Experiment With Professionals to Evaluate the Effect of a Delegated Versus Centralized Control Style on the Maintainability of Object-Oriented Software},
	number = {2003-6},
	year = {2003},
	publisher = {Simula Research Laboratory},
	abstract = {One fundamental question in object-oriented design is how to design maintainable software. According to expert opinion, a delegated control style, typically a result of responsibility-driven design, represents object-oriented design at its best, whereas a centralized control style is reminiscent of a procedural solution, or a {\textquotedblleft}bad{\textquotedblright} object-oriented design. This paper presents a controlled experiment that investigates these claims empirically. A total of 99 junior, intermediate and senior professional consultants from several international consultancy companies were hired for one day to take part in the experiment. To compare differences between (categories of) professionals and students, 59 students also participated. The subjects used professional Java tools to perform several change tasks on two alternative Java designs having a centralized and delegated control style, respectively. The results show that the most skilled developers, in particular the senior consultants, require less time to maintain software with a delegated control style than with a centralized control style. However, more novice developers, in particular the undergraduate students and junior consultants, have serious problems understanding a delegated control style, and perform far better with a centralized control style. Thus, the maintainability of object-oriented software depends to a large extent on the skill of the developers who are going to maintain it. The results may have serious implications for object-oriented development in an industrial context: having senior consultants design object-oriented systems that eventually will be maintained by juniors may be unwise, since the cognitive complexity of such {\textquotedblleft}expert{\textquotedblright} designs might be unmanageable for less skilled maintainers.},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Joergensen.2003.b,
	title = {An Effort Prediction Interval Approach Based on the Empirical Distribution of Previous Estimation Accuracy},
	journal = {Information and Software Technology},
	volume = {45},
	number = {3},
	year = {2003},
	month = {March},
	pages = {123-136},
	abstract = {When estimating software development effort, it may be useful to describe the uncertainty of the estimate through an effort prediction interval (PI). An effort PI consists of a minimum and a maximum effort value and a confidence level. We introduce and evaluate a software development effort PI approach that is based on the assumption that the estimation accuracy of earlier software projects predicts the effort PIs of new projects. First, we demonstrate the applicability and different variants of the approach on a data set of 145 software development tasks. Then, we experimentally compare the performance of one variant of the approach with human (software professionals{\textquoteright}) judgment and regression analysis-based effort PIs on a data set of 15 development tasks. Finally, based on the experiment and analytical considerations, we discuss when to base effort PIs on human judgment, regression analysis, or our approach.},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Syversen.2003,
	title = {An Evaluation of Applying Use Cases to Construct Design Versus Validate Design},
	journal = {Hawaii International Conference on System Sciences (HICSS-36)},
	year = {2003},
	month = {January 6-9},
	publisher = {-},
	type = {1},
	address = {Big Island, Hawaii},
	abstract = {Use case models capture and describe the functional requirements of a software system. A use case driven development process, where a use case model is the principal basis for constructing an object-oriented design, is recommended when applying UML. There are, however, some problems with use case driven development processes and alternative ways of applying a use case model have been proposed. One alternative is to apply the use case model in a responsibility-driven process as a means to validate the design model. We wish to study how a use case model best can be applied in an object-oriented development process and have conducted a pilot experiment with 26 students as subjects to compare a use case driven process against a responsibility-driven process in which a use case model is applied to validate the design model. Each subject was given detailed guidelines on one of the two processes, and used those to construct design models consisting of class and sequence diagrams. The resulting class diagrams were evaluated with regards to realism, that is, how well they satisfied the requirements, size and number of errors. The results show that the validation process produced more realistic class diagrams, but with a larger variation in the number of classes. This indicates that the use case driven process gave more, but not always more appropriate, guidance on how to construct a class diagram The experiences from this pilot experiment were also used to improve the experimental design, and the design of a follow-up experiment is presented.},
	isbn = {0-7695-1874-5},
	author = {Syversen, E. and Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Dennis, Eileen}
}
@inproceedings {SE.5.Conradi.2003.b,
	title = {Lessons Learned and Recommendations From Two Large Norwegian SPI Programmes},
	journal = {9th European Workshop on Software Process Technology (EWSPT 2003)},
	year = {2003},
	month = {1-2 September},
	pages = {32-45},
	publisher = {Springer-Verlag},
	type = {1},
	address = {Helsinki, Finland},
	isbn = {978-3-540-40764-5},
	author = {Conradi, R. and Dyb{\r a}, Tore and Sj{\o}berg, Dag Ingar Kondrup and Ulsund, T.},
	editor = {Oquendo, }
}
@misc {Gallis.2003.3,
	title = {Pair Programming Versus Individual Programming on Maintenance Tasks With Professional Subjects: a Controlled Experiment},
	howpublished = {Scientific presentation to ISERN, October 4th},
	year = {2003},
	month = {October},
	author = {Hans Enger {Gallis} and Arisholm, Erik and Dyb{\r a}, Tore and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Joergensen.2003.a,
	title = {Software Effort Estimation by Analogy and Regression Toward the Mean},
	journal = {Journal of Systems and Software},
	volume = {68},
	number = {3},
	year = {2003},
	pages = {253-262},
	abstract = {Estimation by analogy is, simplified, the process of finding one or more projects that are similar to the one to be estimated and then derive the estimate from the values of these projects. If the selected projects have an unusual high or low productivity, then we should adjust the estimates toward productivity values of more average projects. The size of the adjustments depends on the expected accuracy of the estimation model. This paper evaluates one adjustment approach, based on the findings made by Sir Francis Galton in the late 1800s regarding the statistical phenomenon {\textquotedblleft}regression toward the mean{\textquotedblright} (RTM). We evaluate this approach on several data sets and find indications that it improves the estimation accuracy. Surprisingly, current analogy based effort estimation models do not, as far as we know, include adjustments related to extreme analogues and inaccurate estimation models. An analysis of several industrial software development and maintenance projects indicates that the effort estimates provided by software professionals, i.e., expert estimates, to some extent are RTM-adjusted. A student experiment confirms this finding, but also indicates a rather large variance in how well the need for RTM-adjustments is understood among software developers.},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup and Ulf G. {Indahl}}
}
@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}
}
@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}
}
@article {SE.4.Joergensen.2002.a,
	title = {Impact of Experience on Maintenance Skills},
	journal = {Journal of Software Maintenance and Evolution: Research and Practice},
	volume = {14},
	number = {2},
	year = {2002},
	month = {March},
	pages = {123-146},
	abstract = {This study reports results from an empirical study of 54 software maintainers in the software maintenance department of a Norwegian company. The study addresses the relationship between amount of experience and maintenance skills. The findings were, amongst others: (1) While there may have been a reduction in the frequency of major unexpected problems from tasks solved by very inexperienced to medium experienced maintainers, additional years of general software maintenance experience did not lead to further reduction. More application specific experience, however, further reduced the frequency of major unexpected problems. (2) The most experienced maintainers did not predict maintenance problems better than maintainers with little or medium experience. (3) A simple one-variable model outperformed the maintainers{\textquoteright} predictions of maintenance problems, i.e., the average prediction performance of the maintainers seems poor. An important reason for the weak correlation between length of experience and ability to predict maintenance problems may be the lack of meaningful feedback on the predictions.},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@misc {Sjoberg.2002.1,
	title = {Nekrolog - Kristen Nygaard, Aftenposten Og Uniforum 13.8.2002},
	howpublished = {Misc},
	year = {2002},
	author = {Sj{\o}berg, Dag Ingar Kondrup and S{\o}r{\r a}sen, Oddvar and Holden, Lars}
}
@misc {Sjoberg.2002.2,
	title = {Obituary - Kristen Nygaard},
	year = {2002},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Arisholm.2002.c,
	title = {SESE - an Experiment Support Environment for Evaluating Software Engineering Technologies},
	journal = {NWPER{\textquoteright}2002 (Tenth Nordic Workshop on Programming and Software Development Tools and Techniques)},
	year = {2002},
	month = {18-20 August},
	pages = {81-98},
	type = {1},
	address = {Copenhagen, Denmark},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup and G. J. {Carelius} and Lindsj{\o}rn, Y.}
}
@inproceedings {SE.5.Joergensen.2002.d,
	title = {A Simple Effort Prediction Interval Approach},
	journal = {Proceedings of the Conference on Achieving Quality in Information Systems},
	year = {2002},
	month = {13.-15. March},
	pages = {19-30},
	type = {1},
	address = {Venezia},
	isbn = {0000-0000},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Anda.2002.b,
	title = {Towards an Inspection Technique for Use Case Models},
	journal = {Fourteenth IEEE Conference on Software Engineering and Knowledge Engineering (SEKE{\textquoteright}02)},
	year = {2002},
	pages = {127-134},
	publisher = {-},
	type = {Conference},
	abstract = {A use case model describes the functional requirements of a software system and is used as input to several activities in a software development project. The quality of the use case model therefore has an important impact on the quality of the resulting software product. Software inspection is regarded as one of the most efficient methods for verifying software documents. There are inspection techniques for most documents produced in a software development project, but no comprehensive inspection technique exists for use case models. This paper gives an overview of typical defects in use case models and proposes a checklist-based inspection technique for detecting such defects. This inspection technique was evaluated in two studies with undergraduate students as subjects. The results indicate that inspections are useful for detecting defects in use case models. However, more work is needed to establish appropriate inspection techniques.},
	isbn = {1-58113-556-4},
	author = {Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Anda, Bente Cecilie Dahlum}
}
@inproceedings {SE.5.Karahasanovic.2002,
	title = {Visualising Impacts of Change in Evolving Object-Oriented Systems: an Explorative Study},
	journal = {Proceedings of the International Workshop on Graph-Based Tools GraBaTs{\textquoteright}02},
	year = {2002},
	month = {October 7-8},
	pages = {22-31},
	publisher = {Technische Universitat Berlin},
	type = {1},
	address = {Barcelona, Spain},
	author = {Karahasanovic, Amela and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Arisholm.2002,
	title = {A Web-Based Support Environment for Software Engineering Experiments},
	journal = {Nordic Journal of Computing},
	volume = {9},
	number = {4},
	year = {2002},
	pages = {231-247},
	abstract = {The software engineering communities frequently propose new software engineering technologies, such as new development techniques, programming languages and tools, without rigorous scientific evaluation. One way to evaluate software engineering technologies is through controlled experiments where the effects of the technology can be isolated from confounding factors, i.e., establishing cause-effect relationships. For practical and financial reasons, however, such experiments are often quite unrealistic, typically involving students in a class-room environment solving small pen-and-paper tasks. A common criticism of the results of the experiments is their lack of external validity, i.e., that the results are not valid outside the experimental conditions. To increase the external validity of the experimental results, the experiments need to be more realistic. The realism can be increased using professional developers as subjects who conduct larger experimental tasks in their normal work environment. However, the logistics involved in running such experiments are tremendous. More specifically, the experimental materials (e.g., questionnaires, task descriptions, code and tools) must be distributed to each programmer, the progress of the experiment needs to be controlled and monitored, and the results of the experiment need to be collected and analyzed. To support this logistics for large-scale, controlled experiments, we have developed a web-based experiment support environment called SESE. This paper describes SESE, its development and the experiences from using it to conduct a large controlled experiment in industry.},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup and G. J. {Carelius} and Lindsj{\o}rn, Y.}
}
@book {SE.2.Kirby.2001,
	title = {9th International Workshop, POS-9},
	number = {2135},
	year = {2001},
	month = {September 6-8},
	publisher = {Springer},
	address = {Lillehammer, Norway},
	isbn = {3-540-42735-X},
	author = {Kirby, NC and Dearle, A. and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Joergensen.2001.a,
	title = {Anchoring Effects: an Important Cause of Too Optimistic Effort Estimates in Software Development Projects},
	journal = {24nd IRIS Conference (Information Systems Research Seminar In Scandinavia)},
	year = {2001},
	month = {August},
	type = {Conference},
	address = {Ulvik, Norway},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Arisholm.2001,
	title = {Assessing the Changeability of Two Object-Oriented Design Alternatives - a Controlled Experiment},
	journal = {Empirical Software Engineering},
	volume = {6},
	number = {3},
	year = {2001},
	pages = {231-277},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup and J{\o}rgensen, Magne}
}
@inproceedings {SE.5.Sjoeberg.2001,
	title = {Conducting Experiments on Software Evolution},
	journal = {4th International Workshop on Principles of Software Evolution (IWPSE 2001)},
	year = {2001},
	month = {September},
	pages = {142-145},
	publisher = {-},
	type = {Workshop},
	address = {Vienna, Austria},
	isbn = {1-58113-508-4},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Arisholm, Erik and J{\o}rgensen, Magne},
	editor = {Tamai, Tetsuo and Aoyama, Mikio and Bennet, Keith}
}
@inproceedings {SE.5.Karahasanovic.2001.c,
	title = {Data Collection in Software Engineering Experiments},
	journal = {Managing Information Technology in a Global Economy, Information Resources Management Association International Conference IRMA 2001, Software Engineering Track},
	year = {2001},
	month = {May 20 - 23},
	pages = {1027-1028},
	publisher = {Idea Group Publishing},
	type = {Conference},
	address = {Toronto, Ontario Canada},
	abstract = {This paper presents ongoing work on developing a mechanism for automatic data collection during software engineering experiments. The importance of experiments in software engineering can hardly be overemphasised. Conducting such experiments raises the challenge of efficient and reliable data collection and analysis. During the experiment subjects (students, experienced programmers, etc.) perform tasks on the software engineering artefacts (e.g., design documents and code) using the technology under study in the given context (e.g. operating system). We are typically interested in data concerning subjects, their interaction with the technology and context, and changes of the software engineering artefacts. To conduct a series of experiments on software engineering technology (methods and tools), we envisage an experimental environment for data collection and analysis. As a first step, we have developed a logging mechanism that collects data about subjects of the experiment and their usage of the technology under study. We believe that our logging mechanism will alleviate data collection and increase the validity of experiments.},
	author = {Karahasanovic, Amela and Sj{\o}berg, Dag Ingar Kondrup and J{\o}rgensen, Magne}
}
@inproceedings {SE.5.Anda.2001.a,
	title = {Estimating Software Development Effort Based on Use Cases - Experiences From Industry},
	journal = {4th International Conference on the Unified Modeling Language (UML2001)},
	year = {2001},
	month = {October},
	pages = {487-502},
	publisher = {Springer-Verlag},
	type = {1},
	address = {Toronto, Canada},
	abstract = {Use case models are used in object-oriented analysis for capturing and describing the functional requirements of a system. Several methods for estimating software development effort are based on attributes of a use case model. This paper reports the results of three industrial case studies on the application of a method for effort estimation based on use case points. The aim of this paper is to provide guidance for other organizations that want to improve their estimation process applying use cases. Our results support existing claims that use cases can be used successfully in estimating software development effort. The results indicate that the guidance provided by the use case points method can support expert knowledge in the estimation process. Our experience is also that the design of the use case models has a strong impact on the estimates.},
	isbn = {3-540-42667-1},
	author = {Anda, Bente Cecilie Dahlum and Dreiem, Hege and Sj{\o}berg, Dag Ingar Kondrup and J{\o}rgensen, Magne},
	editor = {Gogolla, M. and Kobryn, C.}
}
@article {SE.4.Joergensen.2001.a,
	title = {Impact of Effort Estimates on Software Project Work},
	journal = {Information and Software Technology},
	volume = {43},
	number = {15},
	year = {2001},
	pages = {939-948},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Anda.2001.b,
	title = {Quality and Understandability of Use Case Models},
	journal = {ECOOP 2001 - Object-Oriented Programming, 15th European Conference},
	year = {2001},
	month = {June 18-22},
	pages = {402-428},
	publisher = {Springer-Verlag},
	type = {1},
	address = {Budapest, Hungary},
	abstract = {Use case models are used in object-oriented analysis for capturing and describing the functional requirements of a system. Use case models are also used in communication between stakeholders in development projects. It is therefore important that the use case models are constructed in such a way that they support the development process and promote a good understanding of the requirements among the stakeholders. Despite this, there are few guidelines on how to construct use case models. This paper describes an explorative study where three different sets of guidelines were used for constructing and documenting use case models. An experiment with 139 undergraduate students divided into 31 groups was conducted. Each group used one out of the three sets of guidelines when constructing a use case model from an informal requirements specification. After completing the use case model, each student answered a questionnaire. The results of the experiment indicate that guidelines based on templates support the construction of use case models that are easier to understand for the readers, than guidelines without specific details on how to document each use case. The guidelines based on templates were also considered as the most useful when constructing use cases. In addition to better understandability, our experiment indicates that the guidelines based on templates result in better use case models regarding also other quality attributes. Our results further indicate that it may be beneficial to combine the template guidelines with another set of guidelines that focus on the documentation of the flow of events of each use case. Keywords. Object-oriented analysis, Requirements specification, Use Cases, UML, Understandability, Experiment},
	isbn = {3-540-42206-4},
	author = {Anda, Bente Cecilie Dahlum and Sj{\o}berg, Dag Ingar Kondrup and J{\o}rgensen, Magne},
	editor = {Knudsen, Lindskov}
}
@inproceedings {SE.5.Joergensen.2001.b,
	title = {Software Effort Estimation by Analogy and Regression Toward the Mean},
	journal = {The Thirteenth International Conference on Software Engineering \& Knowledge Engineering (SEKE01)},
	year = {2001},
	month = {June 13-15},
	pages = {253 - 262},
	publisher = {Elsevier Science Inc},
	type = {Conference},
	address = {Buenos Aires, Argentina},
	abstract = {Estimation by analogy is, simplified, the process of finding one or more projects that are similar to the one to be estimated and then derive the estimate from the values of these projects. If the selected projects have an unusual high or low productivity, then we should adjust the estimates toward productivity values of more average projects. The size of the adjustments depends on the expected accuracy of the estimation model. This paper evaluates one adjustment approach, based on the findings made by Sir Francis Galton in the late 1800s regarding the statistical phenomenon \&ldquo;regression toward the mean\&rdquo; (RTM). We evaluate this approach on several data sets and find indications that it improves the estimation accuracy. Surprisingly, current analogy based effort estimation models do not, as far as we know, include adjustments related to extreme analogues and inaccurate estimation models. An analysis of several industrial software development and maintenance projects indicates that the effort estimates provided by software professionals, i.e., expert estimates, to some extent are RTM-adjusted. A student experiment confirms this finding, but also indicates a rather large variance in how well the need for RTM-adjustments is understood among software developers.},
	author = {J{\o}rgensen, Magne and Ulf G. {Indahl} and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Joergensen.2001.b,
	title = {Software Process Improvement and Human Judgement Heuristics},
	journal = {Scandinavian Journal of Information Systems},
	volume = {13},
	number = {1},
	year = {2001},
	pages = {99-122},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Karahasanovic.2001.a,
	title = {Visualizing Impacts of Database Schema Changes - a Controlled Experiment},
	journal = {2001 IEEE Symposium on Visual/Multimedia Approaches to Programming and Software Engineering},
	year = {2001},
	month = {September},
	pages = {358-365},
	publisher = {IEEE Computer Society},
	type = {Conference},
	address = {Stresa, Italy},
	abstract = {Research in schema evolution has been driven by the need for more effective software development and maintenance. Finding impacts of schema changes on the applications and presenting them in an appropriate way are particularly challenging. We have developed a tool that finds impacts of schema changes on applications in object-oriented systems. This tool displays components (packages, classes, interfaces, methods and fields) of a database application system as a graph. Components potentially affected by a change are indicated by changing the shape of the boxes representing those components. Two versions of the tool are available. One version identifies affected parts of applications at the granularity of packages, classes, and interfaces, whereas the other version identifies affected parts at the finer granularity of fields and methods. This paper presents the design and results of a controlled student experiment testing these two granularity levels with respect to productivity and user satisfaction. There are indications that identifying impacts at the finer granularity can reduce the time needed to conduct schema changes and reduce the number of errors. Our results also show that the subjects of the experiment appreciated the idea of visualizing the impacts of schema changes.},
	isbn = {0-7695-0474-4},
	author = {Karahasanovic, Amela and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Joergensen.2000.c,
	title = {Empirical Studies on Effort Estimation in Software Development Projects},
	journal = {IRMA 2000},
	year = {2000},
	month = {May},
	pages = {778-779},
	publisher = {IGI Publishing},
	type = {Conference},
	address = {Alaska,},
	isbn = {1-878-28984-5},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Joergensen.2000.b,
	title = {Human Judgement in Effort Estimation of Software Projects},
	journal = {Beg, Borrow, or Steal Workshop, International Conference on Software Engineering},
	year = {2000},
	month = {June},
	pages = {45-51},
	type = {Workshop},
	address = {Limerick, Ireland},
	author = {J{\o}rgensen, Magne and Kirkeb{\o}en, Geir and Sj{\o}berg, Dag Ingar Kondrup and Anda, Bente Cecilie Dahlum and Bratthall, Lars}
}
@inproceedings {SE.5.Joergensen.2000.a,
	title = {The Importance of NOT Learning From Experience},
	journal = {EuroSPI{\textquoteright}2000 -European Software Process Improvement},
	year = {2000},
	month = {November 7-9,},
	pages = {2.2-2.8},
	type = {Workshop},
	address = {Copenhagen, Denmark},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inbook {SE.5.Sjoeberg.2000,
	title = {The Persistent Workshop - a Programming Environment for Napier88},
	booktitle = {Fully Integrated Data Environment},
	year = {2000},
	pages = {523-527},
	publisher = {Springer},
	organization = {Springer},
	abstract = {The Persistent Workshop is a programming environment to support the construction of application systems in Napier88, a persistent programming language. In addition to supporting programming activities, the Workshop provides a demonstration of the persistence technology together with an environment in which various experiments can be conducted. The paper gives a brief description of the underlying principles of persistence which are exploited by the Workshop. The basic structure of the Workshop is described, together with a brief summary of the tools provided within the programming environment, followed by an outline of the internal structure of the Workshop and the use of persistent data structures. =46inally, the current status of the Workshop is described together with some comments on future work.},
	author = {Sj{\o}berg, Dag Ingar Kondrup and M. P. {Atkinson} and Philbrow, P. and Waite, C.},
	editor = {M. P. {Atkinson} and Welland, Ray}
}
@inproceedings {SE.5.Joergensen.2000.d,
	title = {The Prediction Ability of Experienced Software Maintainers},
	journal = {4th Europan Conference on Software Maintenance and Reengineering},
	year = {2000},
	pages = {93-100},
	publisher = {IEEE Computer Society},
	type = {Conference},
	address = {Zurich, Switzerland},
	abstract = {Reports an empirical study of 109 randomly selected maintenance tasks in a large Norwegian software organization. When the maintainers had understood the maintenance task specifications, we asked whether they knew how to solve the task. A high confidence in knowing how to solve the task meant that the maintainers did not expect any major difficulties. Then, immediately after the task was completed, we asked whether there had been any major unexpected difficulties. A comparison of the answers gave the seemingly surprising result that one could not, except for corrective, small and simple maintenance tasks, have more confidence in the predictions of an experienced maintainer than the predictions of an inexperienced maintainer. We believe that better quality of the feedback on previous predictions and more training in probabilistic thinking are important means to improve the prediction abilities of maintainers. Decision aids, such as maintenance effort estimation models, should enable the analysis of previous predictions and stimulate probabilistic thinking},
	isbn = {0-7695-0546-5},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup and Kirkeb{\o}en, Geir},
	editor = {Ebert, Jurgen and Verhoef, Chris}
}
@misc {SE.7.Mughal.2000,
	title = {Proceedings of NWPER{\textquoteright}2000 - the Ninth Nordic Workshop on Programming and Software Development Environment Research},
	howpublished = {Lillehammer, Norway 28-30 May, 2000, Research Report 283, Department of Informatics, University of Oslo, ISBN 82-7368-231-5, ISSN 0806-3036},
	year = {2000},
	author = {K. A. {Mughal} and A. L. {Opdahl} and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Opdahl.2000,
	title = {Programming and Software Development Environment Research in the Nordic Countries},
	journal = {Nordic Journal of Computing},
	volume = {7},
	number = {2},
	year = {2000},
	pages = {65-66,},
	author = {A. L. {Opdahl} and Sj{\o}berg, Dag Ingar Kondrup}
}
@techreport {SE.7.Dybaa.2000,
	title = {SPIQ Metodeh{\r a}ndbok},
	number = {282},
	year = {2000},
	note = {ISBN 82-7368-230-7, ISSN 0806-3036},
	publisher = {Department of Informatics, University of Oslo},
	author = {Dyb{\r a}, Tore and K. J. {Wedde} and St{\r a}lhane, T. and N. B. {Moe} and Conradi, R. and Dings{\o}yr, T. and Sj{\o}berg, Dag Ingar Kondrup and J{\o}rgensen, Magne}
}
@article {SE.4.Holgeid.2000,
	title = {A Study of Development and Maintenance in Norway: Assessing the Efficiency of Information Systems Support Using Functional Maintenance},
	journal = {Information and Software Technology},
	volume = {42},
	number = {10},
	year = {2000},
	pages = {687-700,},
	author = {K. K. {Holgeid} and Krogstie, John and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Arisholm.2000,
	title = {Towards a Framework for Empirical Assessment of Changeability Decay},
	journal = {Journal of Systems and Software},
	volume = {53},
	number = {1},
	year = {2000},
	pages = {3-14},
	abstract = {Evolutionary development allows early and frequent adaptations to new or changed requirements. However, such unanticipated changes may invalidate design documentation and cause structural degradations of the software, which in turn may accelerate changeability decay. Our definition of changeability decay focuses on the increased effort required to implement changes. We have identified three approaches to the assessment of changeability decay: (1) Structure measurement, (2) change complexity measurement and (3) benchmarking. Our research aims to evaluate and compare these approaches in order to develop an empirical assessment framework. In this paper we propose a set of change complexity measures (2) and compare them with structural attribute measures (1) using detailed process and product data collected from a commercial object-oriented development project. The preliminary results indicate that the change complexity measures capture some dimensions of changeability decay not accounted for with structural attribute measures. However, the current findings also suggest that many aspects of changeability decay cannot be accounted for by the indirect measures utilized in approach (1) and (2). As an alternative approach, we therefore propose using benchmarks (3) where change effort can be measured more directly. A research methodology for the development of benchmarks and benchmarking procedures are described.},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Arisholm.1999.b,
	title = {Empirical Assessment of Changeability Decay in Object-Oriented Software},
	journal = {ICSE{\textquoteright}99 Workshop on Empirical Studies of Software Development and Evolution},
	year = {1999},
	month = {May},
	pages = {62-69},
	publisher = {Springer Netherlands},
	type = {Workshop},
	address = {Los Angeles, CA},
	abstract = {Abstract Genera AS is a vendor of a CASE tool called Genova. The work described in this paper aims to define and evaluate an evolutionary development process (the Genova process) to complement and support the use of the Genova tool. As a starting point, we used a lightweight version of the Rational Unified Process in a development project for one of our customers. This process was instrumented to enable process improvement activities. An essential question is what to improve the defined or the actual process? Based on quantitative and qualitative data, we identified improvements related to the distribution of test effort throughout the life cycle. Furthermore, we gained useful experience on the management of evolutionary development projects. Our case study also provided insight for instrumentation of the process for collecting data related to the cost of changes.},
	author = {Arisholm, Erik and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Bennet.1999,
	title = {Empirical Studies of Evolving Systems},
	journal = {Empirical Software Engineering},
	volume = {4},
	number = {4},
	year = {1999},
	month = {December},
	pages = {370-380,},
	abstract = {This paper describes the results of the working group investigating the issues of empirical studies for evolving systems. The groups found that there were many issues that were central to successful evolution and this concluded that this is a very important area within software engineering. Finally nine main areas were selected for consideration. For each of these areas the central issues were identified as well as success factors. In some cases success stories were also described and the critical factors accounting for the success analysed. In some cases it was later found that a number of areas were so tightly coupled that it was important to discuss them together.},
	author = {Bennet, K. and Burd, F. and Kemerer, C. and M. M. {Lehman} and Lee, M. and Madachy, Ray and Mair, Carolyn and Sj{\o}berg, Dag Ingar Kondrup and Slaughter, S.}
}
@inproceedings {SE.5.Arisholm.1999.c,
	title = {Guidelines on Conducting Software Process Improvement Studies in Industry},
	journal = {22nd IRIS Conference (Information Systems Research Seminar In Scandinavia)},
	year = {1999},
	month = {August 7-10,},
	pages = {87-102},
	type = {Conference},
	address = {Keuruu, Finland},
	author = {Arisholm, Erik and Anda, Bente Cecilie Dahlum and J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Arisholm.1999.a,
	title = {Improving an Evolutionary Development Process - a Case Study},
	journal = {EuroSPI99},
	year = {1999},
	month = {25-27 October,},
	pages = {9.40-9.50},
	type = {1},
	address = {Pori, Finland},
	author = {Arisholm, Erik and Skandsen, J. and Sagli, K. and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Holgeid.1999,
	title = {A Longitudinal Study of Software Maintenance in Norway},
	journal = {International Conference on Software Maintenance (ICSM{\textquoteright}99)},
	year = {1999},
	note = {Poster session},
	month = {09/1999},
	type = {Workshop},
	address = {Oxford, England},
	author = {K. K. {Holgeid} and Krogstie, John and Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Joergensen.1999.a,
	title = {Reuse of Software Development Experience - a Case Study},
	journal = {Telektronikk},
	volume = {95},
	number = {1},
	year = {1999},
	pages = {48-54,},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup and Conradi, R.}
}
@inproceedings {SE.5.Karahasanovic.1999,
	title = {Supporting Database Schema Evolution by Impact Analysis},
	journal = {Proceedings of Norwegian Conference in Informatics NIK{\textquoteright}99},
	year = {1999},
	month = {November 16-17,},
	pages = {303-314},
	publisher = {TAPIR},
	type = {Conference},
	address = {Trondheim, Norway},
	author = {Karahasanovic, Amela and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Arneberg.1998,
	title = {Configuration Management in Component-Based Development Projects},
	journal = {Workshop on Component-Based Information Systems Engineering (CBISE{\textquoteright}98)},
	year = {1998},
	month = {June 8-9,},
	pages = {94-100},
	publisher = {-},
	type = {Workshop},
	address = {Pisa, Italy},
	author = {Arneberg, G. and Sagli, K. and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Grundy, John}
}
@inproceedings {SE.5.Grimstad.1998,
	title = {Evaluating Usability Aspects of PJama Based on Source Code Measurements},
	journal = {Third International Workshop on Persistence and Java (POS8/PJW3)},
	year = {1998},
	month = {September 1-3,},
	pages = {307-321},
	publisher = {Morgan Kaufmann Publishers Inc},
	type = {1},
	address = {Tiburon, California},
	isbn = {1-55860-585-1},
	author = {Grimstad, Stein and Sj{\o}berg, Dag Ingar Kondrup and M. P. {Atkinson}},
	editor = {Morrison, Ron and Jordan, Mick and Atkinson, Malcolm}
}
@inproceedings {SE.5.Joergensen.1998,
	title = {Reuse of Software Development Experience at Telenor Telecom Software},
	journal = {European Software Process Improvement Conference (EuroSPI{\textquoteright}98)},
	year = {1998},
	month = {November 16-18,},
	pages = {10.19-10.31},
	type = {Conference},
	address = {Gothenburg, Sweden},
	author = {J{\o}rgensen, Magne and Sj{\o}berg, Dag Ingar Kondrup and Conradi, R.}
}
@inproceedings {SE.5.Sjoeberg.1998,
	title = {Software Constraints in Integrated Data Environments},
	journal = {Fifth Integrated Data Environments Australia Workshop (IDEA5)},
	year = {1998},
	month = {February 7-10,},
	pages = {65-68},
	type = {Workshop},
	address = {Fremantle, Australia},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@misc {SE.8.Sjoeberg.1997.b,
	title = {Driftsrevolusjonen},
	howpublished = {Kronikk, Computerworld, 9.5.97},
	year = {1997},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Per Einar {Arnstad}}
}
@inproceedings {SE.5.Welland.1997,
	title = {Empirical Analysis Based on Automatic Tool Logging},
	journal = {Empirical Assessment \& Evaluation in Software Engineering (EASE97)},
	year = {1997},
	month = {March},
	type = {Conference},
	address = {Keele, UK},
	author = {Welland, Ray and Sj{\o}berg, Dag Ingar Kondrup and M. P. {Atkinson}}
}
@article {SE.4.Sjoeberg.1997.a,
	title = {Exploiting Persistence in Build Management},
	journal = {Software: Practice and Experience},
	volume = {27},
	number = {4},
	year = {1997},
	pages = {447-480,},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Welland, Ray and M. P. {Atkinson} and Philbrow, P. and Waite, C.}
}
@misc {SE.8.Sjoeberg.1997.a,
	title = {Komponenter - Basis for Utvikling Etter Ferdighusprinsippter},
	howpublished = {Computerworld, 19.9.97},
	year = {1997},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Per Einar {Arnstad}}
}
@article {SE.4.Sjoeberg.1997.c,
	title = {The Persistent Workshop - a Programming Environment for Napier88},
	journal = {Nordic Journal of Computing},
	volume = {4},
	number = {1},
	year = {1997},
	pages = {123-149,},
	abstract = {The Persistent Workshop is a programming environment to support the construction of application systems in Napier88, a persistent programming language. In addition to supporting programming activities, the Workshop provides a demonstration of the persistence technology together with an environment in which various experiments can be conducted. The paper gives a brief description of the underlying principles of persistence, which are exploited by the Workshop. The basic structure of the Workshop is described, together with a brief summary of the tools provided within the programming environment, followed by an outline of the internal structure of the Workshop and the use of persistent data structures. Some initial measurements on the usage of the Workshop are briefly presented, and we discuss related work. Finally, the current status of the Workshop is described together with some comments on future work.},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Welland, Ray and M. P. {Atkinson} and Philbrow, P. and Waite, C. and Macneill, -.}
}
@article {SE.4.Sjoeberg.1997.b,
	title = {Software Constraints for Large Application Systems},
	journal = {Computer Journal},
	volume = {40},
	number = {10},
	year = {1997},
	pages = {598-616,},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Welland, Ray and M. P. {Atkinson}}
}
@misc {SE.8.Sjoeberg.1996,
	title = {Den Menneskefiendtlige Informasjonsteknologien \- Og Andre Myter},
	howpublished = {Artikkel i Schola},
	year = {1996},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Cristophersen, N.}
}
@inproceedings {SE.5.Sjoeberg.1996.a,
	title = {Evaluating Software Maintenance Technology},
	journal = {Norwegian Conference in Informatics},
	year = {1996},
	month = {November 18-20,},
	pages = {49-61},
	publisher = {TAPIR},
	type = {Conference},
	address = {Alta, Norway},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Welland, Ray and M. P. {Atkinson} and J{\o}rgensen, Magne and John Petter {Martinussen} and Maus, Arne}
}
@inproceedings {SE.5.Sjoeberg.1996.b,
	title = {The Persistent Workshop - a Programming Environment for Napier88},
	journal = {7th Nordic Workshop on Programming Environment Research (NWPER{\textquoteright}96)},
	year = {1996},
	month = {May},
	pages = {37-52},
	type = {Workshop},
	address = {Aalborg, Denmark},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Welland, Ray and Malcom P. {Atkinson} and Philbrow, Paul and Waite, Cathy and Macneill, Stewart}
}
@inproceedings {SE.5.Sjoeberg.1995.b,
	title = {Analysing Persistent Language Applications},
	journal = {Sixth International Workshop on Persistent Object Systems (Tarascon)},
	year = {1995},
	month = {{\textquoteright}5th\xc2\xad-9th of September{\textquoteright}},
	pages = {235-255},
	publisher = {Springer-Verlag and British Computer Society},
	type = {Workshop},
	address = {Provence, France},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Cutts, -. and Welland, Ray and M. P. {Atkinson}},
	editor = {M. P. {Atkinson} and Benzaken, V. and Maier, D.}
}
@misc {SE.8.Sjoeberg.1995,
	title = {B{\o}r PC-Markedsf{\o}rere Spises Til Aftens?},
	howpublished = {Kronikk, Dagbladet 19.12.95},
	year = {1995},
	author = {Sj{\o}berg, Dag Ingar Kondrup and Cristophersen, N.}
}
@misc {ND.8.Lysne.1995,
	title = {Internett - Ikke Livsn{\o}dvendig},
	howpublished = {Kronikk i Aftenposten, 13. Desember},
	year = {1995},
	author = {Lysne, Olav and Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Sjoeberg.1995.c,
	title = {Thesaurus-Based Software Environments},
	journal = {Workshop on the Intersection Between Databases and Software Engineering (WIBDSE{\textquoteright}94)},
	year = {1995},
	month = {16th-17th of May},
	pages = {41-46},
	publisher = {IEEE Computer Society Press},
	type = {Workshop},
	address = {Sorrento, Italy},
	author = {Sj{\o}berg, Dag Ingar Kondrup and M. P. {Atkinson} and Welland, Ray}
}
@inproceedings {SE.5.Sjoeberg.1995.a,
	title = {Towards a Methodology for Evaluating Software Maintenance Technology},
	journal = {18th Information systems Research seminar In Scandinavia (IRIS18)},
	year = {1995},
	note = {Gothenburg Studies in Informatics, Report 7, June},
	month = {11th-13th of August},
	pages = {653-663},
	publisher = {-},
	type = {Conference},
	address = {Gjern, Denmark},
	author = {Sj{\o}berg, Dag Ingar Kondrup},
	editor = {et al {Dahlbom}}
}
@inproceedings {SE.5.Sjoeberg.1994.b,
	title = {Building an Integrated Persistent Application},
	journal = {Proceedings of the Fourth International Workshop on Database Programming Languages},
	year = {1994},
	month = {09/1994},
	pages = {359-375},
	publisher = {Springer-Verlag and British Computer Society},
	type = {Workshop},
	address = {Manhattan, New York City, USA},
	isbn = {3-540-19853-9},
	author = {Sj{\o}berg, Dag Ingar Kondrup and M. P. {Atkinson} and Lopes, Joao and Trinder, Phil}
}
@inproceedings {SE.5.Sjoeberg.1994.a,
	title = {Managing Change in Information Systems: Technological Challenges},
	journal = {17th Information systems Research seminar In Scandinavia (IRIS17)},
	year = {1994},
	month = {6th-9th of August,},
	pages = {838-851},
	publisher = {University of Oulu},
	type = {Conference},
	address = {Sy{\"o}te, Finland},
	author = {Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Kerola, P. and Juustila, A. and J{\~a}rvinen, J.}
}
@inproceedings {SE.5.Sjoeberg.1994.c,
	title = {Software Constraint Models - a Means to Improve Maintainability and Consistency},
	journal = {Norwegian Conference in Informatics},
	year = {1994},
	month = {11/1994},
	pages = {93-103},
	publisher = {TAPIR forlag},
	type = {Conference},
	address = {Molde, Norway},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@inproceedings {SE.5.Atkinson.1993,
	title = {Managing Change in Persistent Object Systems},
	journal = {Proceedings of the First JSSST International Symposium on Object Technologies for Advanced Software},
	year = {1993},
	month = {4th-6th of November},
	pages = {315-338},
	publisher = {Springer-Verlag},
	type = {Conference},
	address = {Kanazawa, Japan},
	isbn = {3-540-57342-9},
	author = {M. P. {Atkinson} and Sj{\o}berg, Dag Ingar Kondrup and Morrison, Ron},
	editor = {Nishio, S. and Yonezawa, A.}
}
@article {SE.4.Sjoeberg.1993,
	title = {Quantifying Schema Evolution},
	journal = {Information and Software Technology},
	volume = {35},
	number = {1},
	year = {1993},
	month = {January,},
	pages = {35-44},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@phdthesis {SE.3.Sjoeberg.1993,
	title = {Thesaurus-Based Methodologies and Tools for Maintaining Persistent Application Systems},
	year = {1993},
	month = {July,},
	school = {University of Glasgow},
	type = {phd},
	author = {Sj{\o}berg, Dag Ingar Kondrup}
}
@article {SE.4.Bendvold.1989,
	title = {Marital Break-Up Among Couples Raising Families by Artificial Insemination by Donor},
	journal = {Fertility and Sterility},
	volume = {51},
	number = {6},
	year = {1989},
	pages = {980-983,},
	abstract = {{The separation rate for Norwegian women who had given birth to children after artificial insemination by donor (AID},
	author = {Bendvold, E. and Kravdal, {\O} and Moe, N. and Sj{\o}berg, Dag Ingar Kondrup and Skjaeraasen, J.}
}
@inproceedings {SE.5.Lindsjoern.1988,
	title = {Database Concepts Described in an Object-Oriented Perspective},
	journal = {Proceedings of the European Conference on Object-Oriented Programming Oslo},
	year = {1988},
	month = {15th-17th August},
	pages = {300-318},
	publisher = {Springer-Verlag},
	type = {Conference},
	address = {-},
	author = {Lindsj{\o}rn, Y. and Sj{\o}berg, Dag Ingar Kondrup},
	editor = {Gjessing, Stein and Nygaard, Kristen}
}
@article {SE.4.Lindegaard.1987,
	title = {Variations in Middle Cerebral Artery Blood Flow Investigated With Noninvasive Transcranial Blood Velocity Measurements},
	journal = {Stroke},
	volume = {18},
	number = {6},
	year = {1987},
	pages = {1025-1030,},
	abstract = {Observations on blood velocity in the middle cerebral artery using transcranial Doppler ultrasound and on the ipsilateral internal carotid artery flow volume were obtained during periods of transient, rapid blood flow variations in 7 patients. Five patients were investigated after carotid endarterectomy. A further 2 patients having staged carotid endarterectomy and open heart surgery were investigated during nonpulsatile cardiopulmonary bypass. The patient selection permitted the assumption that middle cerebral artery flow remained proportional to internal carotid artery flow. The integrated time-mean values from consecutive 5-second periods were computed. The arithmetic mean internal carotid artery flow varied from 167 to 399 ml/min in individual patients, with individual ranges between \pm15\% and \pm35\% of the mean flow. The mean middle cerebral artery blood velocity varied from 32 to 78 cm/sec. The relation between flow volume and blood velocity was nearly linear under these conditions. Normalization of the data as percent of the individual arithmetic means permitted a composite analysis of data from all patients. Linear regression of normalized blood velocity (V) on normalized flow volume (Q{\textquoteright}) showed V = 1.05 Q{\textquoteright} - 5.08 (r2 = 0.898). (Stroke 1987;18:1025-1030)},
	author = {K. F. {Lindegaard} and Lundar, T. and Wiberg, J. and Sj{\o}berg, Dag Ingar Kondrup and Aaslid, R. and Nornes, H.}
}
