@article {25405,
	title = {Agile Uncertainty Assessment for Benefit Points and Story Points},
	journal = {IEEE Software},
	volume = {36},
	year = {2019},
	month = {10/2018 },
	pages = {50--62},
	publisher = {IEEE Computer Society},
	abstract = {Estimates are inherently uncertain, and it{\textquoteright}s fair to expect that business value estimates are even more so. By making this uncertainty explicit, you can manage and monitor your agile project according to upper and lower margins of uncertainty. The trick is to instantiate benefit points and story points with values reflecting various scenarios.},
	author = {Jo Erskine {Hannay} and Hans Christian {Benestad} and Strand, Kjetil}
}
@article {25406,
	title = {Benefit and Cost Periodized {\textendash} Stretching Your Points},
	journal = {IEEE Software},
	year = {2017},
	publisher = {IEEE Computer Society},
	abstract = {When you estimate lifecycle cost and benefit of your software product, your stakeholders should be assured not only that you{\textquoteright}lldeliver value but should also be informed when that value is expected to manifest itself. To do this you{\textquoteright}ll need tools to layout your estimates in time, so that you can plan and monitor your project{\textquoteright}s investments and returns. After reading this, you{\textquoteright}ll beable to take your points-based estimates for both cost and benefit (story points and benefit points) and distribute them out in timeaccording to the best of your project{\textquoteright}s knowledge. You{\textquoteright}ll also be able to project cost and return according to most likely, bad caseand good case uncertainty assessments.},
	author = {Jo Erskine {Hannay} and Hans Christian {Benestad} and Strand, Kjetil}
}
@article {24652,
	title = {Benefit Points {\textendash} The Best Part of the Story},
	journal = {IEEE Software},
	volume = {34},
	year = {2017},
	pages = { 73 - 85},
	publisher = {IEEE Computer Society},
	abstract = {\&quot;Value for customer\&quot; is the mantra in agile management and development. The product owner is involved along the way, and backlogs are prioritized, with the best of intents to maximize business value early and to eliminate waste. Yet, in many IT development projects bewilderment remains as to how exactly value for customer should be expressed in process decisions and in the delivered system. And projects continue to implement functionality which turns out to be off the mark or is never used. The reason, we say, is that there isn\&rsquo;t sufficient methodological support to determine and to monitor value for customer. Nor is there sufficient methodological support to link business value decisions to the mechanics of the development project.},
	author = {Jo Erskine {Hannay} and Hans Christian {Benestad} and Strand, Kjetil}
}
@article {24653,
	title = {Earned Business Value Management {\textendash} See that You Deliver Value to Your Customer {\textendash}},
	journal = {IEEE Software},
	volume = {34},
	year = {2017},
	pages = {58 - 70},
	publisher = {IEEE Computer Society},
	abstract = {The order in which you send your backlog items into construction determines when stakeholders will be able to reap benefit from\&nbsp;what functionality. This can have substantial impact on market timing, enterprise earnings and project manager survivor rate.\&nbsp;There are several ways to order a backlog, and sophisticated methods and tools exist to do so\&mdash;for example, in release planning.\&nbsp;But the important point we\&rsquo;ll make here, is that no matter what scheme for backlog ordering you choose to use, you ought to be\&nbsp;explicit on the order in which you realize potential business value. To this end, we\&rsquo;ll present methods to express business value\&nbsp;relative to cost in your backlog and methods to monitor how much potential business value you\&rsquo;re realizing along the way\&mdash;in\&nbsp;addition to cost expended.},
	author = {Jo Erskine {Hannay} and Hans Christian {Benestad} and Strand, Kjetil}
}
@inproceedings {Simula.simula.1224,
	title = {Does the Prioritization Technique Affect Stakeholders{\textquoteright} Selection of Essential Software Product Features?},
	journal = {Proceedings of IEEE International Conference on Empirical Software Engineering and Measurement (ESEM 2012)},
	year = {2012},
	pages = {261-270},
	publisher = {ACM},
	type = {Conference},
	address = {New York, NY, USA},
	abstract = {Context: To select the essential, non-negotiable product features is a key skill for stakeholders in software projects. Such selection relies on human judgment, possibly supported by structured prioritization techniques and tools. Goal: Our goal was to investigate whether certain attributes of prioritization techniques affect stakeholders\&$\#$39; threshold for judging product features as essential. The four investigated techniques represent four combinations of granularity (low, high) and cognitive support (low, high). Method: To control for robustness and masking effects when investigating in the field, we conducted both an artificial experiment and a field experiment using the same prioritization techniques. In the artificial experiment, 94 subjects in four treatment groups indicated the features (from a list of 16) essential when buying a new cell phone. In the field experiment, 44 domain experts indicated the software product features that were essential for the fulfillment of the project\&$\#$39;s vision. The effects of granularity and cognitive support on the number of essential ratings were analyzed and compared between the experiments. Result: With lower granularity, significantly more features were rated as essential. The effect was large in the general experiment and extreme in the field experiment. Added cognitive support had medium effect, but worked in opposite directions in the two experiments, and was not statistically significant in the field experiment. Implications: Software projects should avoid taking stakeholders\&$\#$39; judgments of essentiality at face value. Practices and tools should be designed to counteract biases and to support the conscious knowledge-based elements of prioritizing.},
	doi = {10.1145/2372251.2372300},
	author = {Hans Christian {Benestad} and Jo Erskine {Hannay}}
}
@inproceedings {Simula.simula.28,
	title = {A Comparison of Model-Based and Judgment-Based Release Planning in Incremental Software Projects},
	journal = {ACM/IEEE International Conference on Software Engineering},
	year = {2011},
	pages = {766-775},
	publisher = {ACM New York, NY, USA},
	type = {Conference},
	abstract = {Numerous factors are involved when deciding when to implement which features in incremental software development. To facilitate a rational and efficient planning process, release planning models make such factors explicit and compute release plan alternatives according to optimization principles. However, experience indicates that industrial use of such models is limited. To investigate the feasibility of model and tool support, we compared input factors assumed by release planning models with factors considered by expert planners. The former factors were cataloged by systematically surveying release planning models, while the latter were elicited through repertory grid interviews in three software organizations. The findings indicate a substantial overlap between the two approaches. However, a detailed analysis reveals that models focus on only select parts of a possibly larger space of relevant planning factors. Three concrete areas of mismatch were identified: (1) continuously evolving requirements and specifications, (2) continuously changing prioritization criteria, and (3) authority-based decision processes. With these results in mind, models, tools and guidelines can be adjusted to better address real-life development processes.},
	isbn = {978-1-4503-0445-0},
	author = {Hans Christian {Benestad} and Jo Erskine {Hannay}}
}
@inproceedings {Simula.simula.520,
	title = {Does the Prioritization Technique Affect Stakeholders{\textquoteright} Selection of Essential Software Product Features?},
	journal = {5th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement},
	year = {2011},
	pages = {261{\textendash}270},
	publisher = {ACM},
	type = {Conference},
	abstract = {Context: Being able to select the essential, nonnegotiable product features is a key skill for stakeholders of software projects. Such selection relies on human judgment, sometimes supported by structured prioritization techniques and associated tools. Goal: Our goal was to investigate whether certain attributes of prioritization techniques affect stakeholders\&$\#$39; threshold for judging product features as essential. The four investigated techniques reflect four combinations of granularity (low, high) and cognitive support (low, high). Method: In one experiment, 94 subjects in four treatment groups indicated the features (from a list of 16) that would be essential in their decision to buy a new cell phone. With a similar setup in a controlled field experiment, 44 domain experts indicated the software product features that were essential for the fulfillment of the project\&$\#$39;s vision. The effects of granularity and cognitive support on the number of essential ratings were analyzed and compared between the experiments. Result: With lower granularity, significantly more features were rated as essential. The effect was large in the first experiment and extreme (Cohen\&$\#$39;s d=2.40) in the second. Added cognitive support had medium effect (Cohen\&$\#$39;s d=0.43 and 0.50), but worked in opposite directions in the two experiments, and was not statistically significant in the second. Implications: The results of the study imply that software projects should avoid taking stakeholders\&$\#$39; judgments of essentiality at face value. Practices and tools should be designed to counteract potentially harmful biases; however, more empirical work is needed to obtain more insight into the causes of these biases.},
	doi = {10.1145/2372251.2372300},
	author = {Hans Christian {Benestad} and Jo Erskine {Hannay}}
}
@inproceedings {Simula.simula.386,
	title = {A Literature Review of Agile Practices and Their Effects in Scientific Software Development},
	journal = {Proceedings of SE-CSE11},
	year = {2011},
	pages = {1-9},
	type = {Workshop},
	abstract = {The nature of scientific research and the development of scientific software have similarities with processes that follow the agile manifesto: responsiveness to change and collaboration are of the utmost importance. But how well do current scientific software development processes match the practices found in agile development methods, and what are the effects of using agile practices in such processes? In order to investigate this, we conduct a literature review, focusing on evaluating the agility present in a selection of scientific software projects. Both projects with intentionally agile practices and projects with a certain degree of agile elements are taken into consideration. In the agility assessment, we define and utilize an agile mapping chart. The elements of the mapping chart are based on Scrum and XP, thus covering two of the most prominent agile reference models. We compared the findings of the literature review to results of a previously conducted survey. The comparison indicates that scientific software development projects adopting agile practices perceive their testing to be better than average. No difference to average projects was perceived regarding requirements-related activities. Future work includes an in-depth case study to further investigate the existence and impact of agility in three large scientific software projects, ultimately aiming at a better understanding of the particularities involved in developing scientific software.},
	author = {Magnus Thorstein {Sletholt} and Jo Erskine {Hannay} and Pfahl, Dietmar and Hans Christian {Benestad} and Hans Petter {Langtangen}},
	editor = {Carver, J.}
}
@misc {Simula.prepare.24,
	title = {Forskning P{\r a} PERFORM Hva Har Vi Funnet Ut?},
	howpublished = {Talk given at Agile fagdag Statens Pensjonskasse August 27},
	year = {2010},
	author = {Petersen, J{\o}rgen and Jo Erskine {Hannay} and Hans Christian {Benestad}}
}
@inbook {Simula.SE.643,
	title = {A Method to Measure Productivity Trends During Software Evolution},
	booktitle = {CCIS - Evaluation of Novel Approaches to Software Engineering},
	series = {Communications in Computer and Information Science},
	volume = {69},
	year = {2010},
	pages = {147-162},
	publisher = {Springer},
	organization = {Springer},
	chapter = {2},
	abstract = {Better measures of productivity are needed to support software process improvements. We propose and evaluate indicators of productivity trends that are based on the premise that productivity is closely related to the effort required to complete change tasks. Three indicators use change management data, while a fourth compares effort estimates of benchmarking tasks. We evaluated the indicators using data from 18 months of evolution in two commercial software projects. The productivity trend in the two projects had opposite directions according to the indicators. The evaluation showed that productivity trends can be quantified with little measurement overhead. We expect the methodology to be a step towards making quantitative self-assessment practices feasible even in low ceremony projects.},
	isbn = {978-3-642-14819-4},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik},
	editor = {Leszek A. {Maciaszek} and Gonz{\textasciiacute}lez-P{\'e}rez, C{\'e}sar and Jablonski, Stefan}
}
@inproceedings {Simula.se.759,
	title = {Perceived Productivity Threats in Large Agile Development Projects},
	journal = {International Symposium on Empirical Software Engineering and Measurement (ESEM 2010)},
	year = {2010},
	publisher = {ACM},
	type = {Conference},
	abstract = {Applying agile methodology in large software development projects introduces many challenges. For example, one may expect that the combination of autonomous teams and the necessity for an overall organizational control structure may lead to conflicts, and one may expect that Agile{\textquoteright}s informal means of knowledge sharing breaks down as the number of project participants increases. Issues such as these may in turn compromise the project{\textquoteright}s productivity. In order to better understand potential threats to productivity in large agile development projects, we conducted repertory grid interviews with 13 project members on their perceptions of threats to productivity. The project was a large software development project consisting of 11 Scrum teams from three different subcontractors. The repertory grid sessions produced 100 issues, which were content analyzed into 10 main problem areas: (1) Restraints on collaboration due to contracts, ownership, and culture, (2) Architectural and technical qualities are given low priority, (3) Conflicts between organizational control and flexibility, (4) Volatile and late requirements from external parties, (5) Lack of a shared vision for the end product, (6) Limited dissemination of functional knowledge, (7) Excessive dependencies within the system, (8) Overloading of key personnel, (9) Difficulties in maintaining well-functioning technical environments, (10) Difficulties in coordinating test and deployment with external parties. Using critical-case reasoning, we claim that projects deploying agile practices in projects with less favorable conditions than those enjoyed in the current project, and that are larger and more complex, are likely to face similar challenges.},
	isbn = {978-1-4503-0039-01},
	author = {Jo Erskine {Hannay} and Hans Christian {Benestad}},
	editor = {Morisio G. {Succi} and Nagappan, N.}
}
@article {Simula.SE.301,
	title = {Understanding the Cost of Software Change: a Quantitative and Qualitative Investigation of Change Effort During Evolution of Two Software Systems},
	journal = {Empirical Software Engineering},
	volume = {15},
	number = {2},
	year = {2010},
	month = {April},
	pages = {166-203},
	abstract = {Making changes to software systems can prove costly and it remains a challenge to understand the factors that affect the costs of software evolution. This study sought to identify such factors by investigating the effort expended by developers to perform 336 change tasks in two different software organizations. We quantitatively analyzed data from version control systems and change trackers to identify factors that correlated with change effort. In-depth interviews with the developers about a subset of the change tasks further refined the analysis. Two central quantitative results found that volatility of requirements and dispersion of changed code consistently correlated with change effort. The analysis of the qualitative interviews pointed to two important, underlying cost drivers: Difficulties in anticipating side effects of changes and difficulties in comprehending dispersed code. This study demonstrates a novel method for combining qualitative and quantitative analysis to assess cost drivers of software evolution. Given our findings, we propose improvements to design practices and development tools to reduce the costs.},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik}
}
@inproceedings {Simula.SE.323,
	title = {Are We More Productive Now? Analyzing Change Tasks to Assess Productivity Trends During Software Evolution},
	journal = {Evaluation of Novel Approaches to Software Engineering (ENASE)},
	year = {2009},
	publisher = {Elsevier},
	type = {Conference},
	abstract = {Organizations that maintain and evolve software would benefit from measuring productivity in an easy and reliable way. This could allow them to determine if new or improved practices are needed, and to evaluate improvement efforts. We propose and evaluate indicators of productivity trends that are based on the premise that productivity during software evolution is closely related to the effort required to complete change tasks. Three indicators use data about change tasks from change management systems, while a fourth compares effort estimates of benchmarking tasks. We evaluated the indicators using data from 18 months of evolution in two commercial software projects. The productivity trend in the two projects had opposite directions according to the indicators. Possible explanations were that one system became easier to maintain due to a large refactoring effort, while developers in the other project experienced less time pressure due to reduced use of fixed-price contracts. The evaluation of the indicators showed that productivity trends can be quantified with little measurement overhead. The methodology is a step towards making quantitative self-assessment practices feasible even in low ceremony projects.},
	isbn = {978-989811198-2},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik},
	editor = {Jablonski, Stefan and Leszek A. {Maciaszek}}
}
@misc {Simula.SE.653,
	title = {Defense Presentation: Empirical Assessment of Cost Factors and Productivity},
	year = {2009},
	month = {June},
	author = {Hans Christian {Benestad}}
}
@phdthesis {Simula.SE.649,
	title = {Empirical Assessment of Cost Factors and Productivity During Software Evolution Through the Analysis of Software Change Effort},
	year = {2009},
	month = {June},
	school = {University of Oslo},
	type = {phd},
	isbn = {1501-7710},
	author = {Hans Christian {Benestad}}
}
@misc {Simula.SE.647,
	title = {Green Software Engineering: Substance Or Fad},
	year = {2009},
	month = {June},
	author = {Hans Christian {Benestad}}
}
@article {Simula.SE.196,
	title = {Understanding Software Maintenance and Evolution by Analyzing Individual Changes: a Literature Review},
	journal = {Journal of Software Maintenance and Evolution: Research and Practice},
	volume = {21},
	number = {6},
	year = {2009},
	pages = {349-378},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik}
}
@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}
}
@techreport {Simula.SE.327,
	title = {Assessing the Reliability of Developers{\textquoteright} Classification of Change Tasks: a Field Experiment},
	year = {2008},
	publisher = {Simula Research Laboratory},
	abstract = {Many software projects routinely record information about change type as part of their change management process. Such information can be used to make priorities, to clarify responsibilities, and to monitor and act on trends during software evolution. The objective of this field experiment was to empirically assess the reliability of developers{\textquoteright} classifications according to two alternative classification schemes, in the context of a commercial software project. The project members perform classifications of already completed changes according to the dimensions of maintenance by Swanson and according to quality factors included in the ISO9126 standard. The results show that in this project, the inter-rater agreement was low by normal standards, for both the investigated schemes. The conclusion is that projects should take explicit actions to improve and evaluate the reliability of such classification before they are used as input to management decisions.},
	author = {Hans Christian {Benestad}}
}
@techreport {Simula.SE.317,
	title = {An Investigation of Change Effort in Two Evolving Software Systems},
	year = {2008},
	publisher = {Simula Research Laboratory},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik}
}
@techreport {Simula.SE.297,
	title = {A Systematic Review of Empirical Software Engineering Studies That Analyze Individual Changes},
	number = {2008-05},
	year = {2008},
	month = {September},
	publisher = {Simula Research Laboratory},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik}
}
@article {Simula.SE.150,
	title = {Using Planning Poker for Combining Expert Estimates in Software Projects},
	journal = {Journal of Systems and Software},
	volume = {81},
	number = {12},
	year = {2008},
	pages = {2106-2117},
	abstract = {Combination of expert opinion is frequently used to produce estimates in software projects. However, whether, when, and how to combine expert estimates is poorly understood. In order to study the effects of a combination technique called planning poker, the technique was introduced in a software project for half of the tasks. The tasks estimated with planning poker provided: 1) group consensus estimates that were less optimistic than the statistical combination (mean) of individual estimates for the same tasks, and 2) group consensus estimates that were more accurate than the statistical combination of individual estimates for the same tasks. The set of control tasks in the same project, estimated by individual experts, achieved similar estimation accuracy as the planning poker tasks. Moreover, for both planning poker and the control group, measures of the median estimation bias indicated that both groups had unbiased estimates, because the typical estimated task was perfectly on target. A code analysis revealed that for tasks estimated with planning poker, more effort was expended due to the complexity of the changes to be made, possibly triggered by the group discussions.},
	author = {Kjetil Johan {Mol{\o}kken-{\O}stvold} and Nils Christian {Haugen} and Hans Christian {Benestad}}
}
@inproceedings {Benestad.2006.1,
	title = {Assessing Software Product Maintainability Based on Class-Level Structural Measures},
	journal = {7th International Conference on Product-focused Software Process Improvement (PROFES)},
	year = {2006},
	pages = {94-111},
	publisher = {Springer-Verlag},
	type = {Conference},
	abstract = {A number of structural measures have been suggested to support the assessment and prediction of software quality attributes. The aim of our study is to investigate how class-level measures of structural properties can be used to assess the maintainability of a software product as a whole. We survey, structure and discuss current practices on this topic, and apply alternative strategies on four functionally equivalent systems that were constructed as part of a multi-case study. In the absence of historical data needed to build statistically based prediction models, we apply elements of judgment in the assessment. We show how triangulation of alternative strategies as well as sensitivity analysis may increase the confidence in assessments that contain elements of judgment. This paper contributes to more systematic practices in the application of structural measures. Further research is needed to evaluate and improve the accuracy and precision of judgment-based strategies.},
	isbn = {0302-9743},
	author = {Hans Christian {Benestad} and Anda, Bente Cecilie Dahlum and Arisholm, Erik},
	editor = {M{\"u}nch, J{\"u}rgen}
}
@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}
}
@inproceedings {Anda.2005.6,
	title = {A Multiple-Case Study of Effort Estimation Based on Use Case Points},
	journal = {ISESE{\textquoteright}2005 (Fourth International Symposium on Empirical Software Engineering)},
	year = {2005},
	pages = {407-416},
	publisher = {IEEE Computer Society, Noosa, Australia, November 17-18},
	type = {1},
	abstract = {There is much interest in industry for the estimation of software development effort based on use cases, but little scientific evaluation of applying use cases in estimation has been reported. We investigated one particular method, the use case points method, in a multiple-case study. The Software Engineering Department at Simula issued a tender for a system, and 35 companies responded, with estimates ranging from 78 to 654 hours. We chose four companies to develop the system. They all implemented the same functionality, but their development processes varied, ranging from a light, mainly code-and-fix process, to a heavy process with much emphasis on analysis and design. The use case points method estimated this project to 430 hours. This was equal to the actual effort spent on implementing the system by the company with the lightest development process. In our opinion, the results from this study may represent a basis for measuring size of the use cases and choosing productivity factor (hours per use case point) when estimating based on use cases. The three other companies spent 587, 829 and 943 hours respectively, showing that a heavier development process and more emphasis on non-functional requirements may increase effort by more than 100\%.},
	author = {Anda, Bente Cecilie Dahlum and Hans Christian {Benestad} and Siw Elisabeth {Hove}}
}
@inproceedings {SE.5.Arisholm.1998,
	title = {Incorporating Rapid User Interface Prototyping in Object-Oriented Analysis and Design With Genova},
	journal = {Proceedings of NWPER{\textquoteright}98 Nordic Workshop on Programming Environment Research},
	year = {1998},
	month = {June 14-16,},
	pages = {155-161},
	publisher = {-},
	type = {1},
	address = {Bergen},
	author = {Arisholm, Erik and Hans Christian {Benestad} and Fredhall, H. and Skandsen, J.}
}
