Information Systems and e-Business Management, Vol. 11, S. 377-401.
Since the effort required to develop a system depends on its requirements, it is important to consider the resulting effort when deciding on the requirements. Miscalculating the effort may lead to requirements that cannot be implemented within given budget constraints. In order to support requirements engineers in calculating the effort resulting from the requirements they elaborate correctly, we develop a mapping model for assessing project effort from requirements (MMAPER) in this paper. MMAPER incorporates effort estimation into requirements engineering and thereby enables engineers to proactively assess project effort without demanding that they spend significant additional time on this task. MMAPER measures system size using function point analysis and assesses the resulting effort using the Constructive Cost Model 2. The theoretical underpinning of the methods stems from theoretical perspectives from which we derive theories of how requirements determine the resulting project effort. We also take into consideration that it is important to distinguish requirements of different size but also implemented in different contexts for estimating the resulting effort. We empirically evaluate the model using data from five case studies which we conducted with a financial services organization. The developed model provides very accurate effort estimations, across both controlled experiments and field applications.
IEEE Transactions on Software Engineering, Vol. 38, Nr. 5, S. 1027-1039.
Determining how to cope with existing systems is an important issue for information systems development (ISD). In this paper, we investigate how well different ISD patterns are suited for coping with existing systems. Empirical results, gathered from three software development projects undertaken by a financial institution, suggest propositions regarding how ISD patterns and existing systems affect the characteristics of objective ISD complexity, which in turn determine overall experienced complexity. Existing systems increase complexity due to conflicting interdependencies, but ISD patterns that reduce this complexity, such as those that employ bottom-up or concurrent consideration patterns, are best suited for coping with existing systems. In contrast, top-down and iterative focusing patterns, as classically used in new development, increase the complexity associated with conflicting interdependency, which makes them particularly unsuited for coping with existing systems in ISD.
Proceedings of the 10th International Conference on Wirtschaftsinformatik, Zürich, Schweiz.
In this paper, we analyze two theoretical perspectives and investigate their explanatory power on information systems development (ISD) projects. Building upon a case study, we illustrate that the perspectives of ISD as an economic transformation process and ISD as complex problem solving address different but complementary ISD phenomena. By integrating both theoretical perspectives, we are able to analyze and predict more ISD phenomena than each of the theories individually. Therefore, the contribution of this paper is twofold. Firstly, it supports researchers in their selection of a theory when addressing ISD phenomena. Secondly, it serves as an example of how researchers can develop a new theoretical perspective to address a phenomenon of interest not covered appropriately by existing theories.
Business & Information Systems Engineering, Vol. 2, Nr. 3, S. 165-173.
Project effort is critical for the success of software development projects. It has a major impact on whether constraints in time and budget can be complied with. But although requirements affect project effort, requirements engineering (RE) methods are not capable of assessing project effort. In this paper, we present our mapping model for assessing project effort (MMAPE). MMAPE incorporates into RE the assessment of project effort resulting from requirements for software development projects. It maps semantics of the RE method KAOS onto structures that are counted in function point analyses. We applied MMAPE in a case study on a software development project within a large financial institution. The validity of MMAPE is supported, since we found throughout consistent statements between information provided by MMAPE and data gathered from the case.
DESRIST 2010, LNCS 6105, 2010, S. 490-505
Gewinner des Herbert Simon Awards for the Best Paper
In this paper we report on our design research in progress, where we have developed an artifact that assesses project effort resulting from requirements. Based on models used in the goal-oriented requirements engineering method KAOS, the artifact measures system size via function point analysis and analyzes system complexity via structural analysis. In addition, we provide theoretical explanations and empirically validate how size and structural complexity affect project effort. Overall effort depends on counted functions that must be transformed, since software development can be regarded as a transformation process where size matters. Structural complexity matters as well, since software development is also a complex problem, where effort spent depends on the structure of the problem. Insights from empirical evaluation in three software development projects are encouraging, wherefore we believe that the artifact appropriately assesses project effort. Furthermore, our artifact increases the utility of KAOS by providing additional information on project effort.
Proceedings of the 16th American Conference on Information Systems (AMCIS), Lima, Peru.
Software engineering is a complex task. But although there is no silver bullet that guarantees accomplishing this task, appropriate methods can support the engineer by addressing the characteristics that make it complex. The objective of this paper is to evaluate whether and how the goal-oriented requirements engineering method KAOS addresses these characteristics of complex tasks and thereby, whether it effectively supports software engineering. For serving this purpose, we conduct a literature analysis, which discloses core concepts underlying to the KAOS method, and we apply KAOS in two software development projects, which provide insights into KAOS in use. Our results show that KAOS, despite of some shortcomings, addresses all characteristics, but that applying it can be work intensive. Consequently, while KAOS supports software engineering, provided support must be weigh up against invested work.