Moderating Effects of Requirements Uncertainty on Flexible Software Development Techniques

Partially due to increasing requirements uncertainty, flexibility has been in the focus of many software development activities for many years. Only few studies have analyzed the indirect effect that different levels of requirements uncertainty have on the effects of established flexible development techniques. This study analyzes how requirements uncertainty moderates the well studied effects of (1) sequential development, (2) investment in architectural design, and (3) intensity of early feedback on the performance of contract development projects. It finds that requirements uncertainty negatively moderates the effects of sequential development. It also points out that requirements uncertainty negatively moderates the effect of investment in architectural design. For agile development approaches, the value of investment in architectural design falls with increasing uncertainty. However, for plan-driven approaches, investment in architectural design is positive at any level of requirements uncertainty. Finally, the paper finds that early feedback throughout the development process is helpful at any level of requirements uncertainty

Developing a Situational Model of Information System Project Success

Scholars have not found a common understanding of information system (IS) project success nor does a common measurement approach exist in empirical research. A plausible cause for the lack of such an agreed on definition is that a generally accepted definition of IS project success practically cannot be derived due to stakeholders’ different perceptions of success. Therefore, we develop a situational model for the group of IS projects’ contractors. We gathered data from 52 IS projects managers and apply PLS path modeling to determine the relevant success dimensions from their subjective perspectives. Our results show customer satisfaction, process efficiency, and functional requirements as the three most important dimensions for contractors. Scholars and practitioners should shift from measuring IS project success in terms of adherence to planning to an approach adapted to the specific terms of the project under consideration and the stakeholder group addressed

Coping with Requirements Uncertainty: An Interpretive Case Study

Information systems development projects (ISDPs) often face requirements uncertainty. Thus, coping with this issue is an important project management task in ISDPs. In order to gain insights into which different requirements uncertainty situations exist and how to cope with them, we conducted a longitudinal interpretive case study. We investigated the requirements analysis of an ISDP in an international insurance company for 17 months. Thereby, we identified eight distinct requirements uncertainty situation types, observed ten requirements engineering (RE) techniques applied in practice and their impact on requirements uncertainty situation types, and finally derived recommendations for applying RE techniques in requirements uncertainty situations based on our observations. We combine these findings and contribute to RE literature by making a first step towards a framework for coping with requirements uncertainty in ISDPs. We believe that RE researchers as well as practitioners in ISDPs can make use of this article’s insights

Factors Influencing the Effort of EAI Projects – A Repertory Grid Investigation

Today’s enterprises often face heterogeneous application landscapes. Many of those companies struggle with effective and efficient accomplishment of enterprise application integration (EAI), which results in significant time and budget overruns. As regards EAI project management, a major reason for failure is considered to be underestimation of effort. The underestimation has been found to be an aftermath of applying estimation methods that do not account for all relevant factors influencing EAI project effort. We therefore explore factors affecting the effort of such projects in this study. Applying Repertory Grid, we conduct 22 semi-structured expert interviews. 91 factors influencing the effort of EAI projects in nine categories emerge from these interviews. We provide an extensive overview of effort-influencing factors and their classification, which can be used as a checklist in EAI projects. Future research can additionally use our findings as basis for development of more accurate effort estimation models

Software Factory - ein Statusbericht

Die Fabrik scheint nicht mehr das Vorbild der Softwareproduktion zu sein. Dennoch zeigt sich bei genauerer Betrachtung, daß sowohl das Ziel, Softwareprozesse wie Fabrikprozesse zu beherrschen, als auch die Fabrikanalogie, Softwareprozesse wie Fabrikprozesse zu betrachten, im wesentlichen weiterhin bestehen. Weil Erwartung und Erfolg so weit auseinanderklafften, hat die zunehmend auf technische Aspekte eingeengte und auf Automatisierung zielende Interpretation die Software Factory in Mißkredit gebracht. Daß die Praxis aus den technischen Lösungsansätzen in der Forschung und Softwarewerkzeugentwicklung nicht den Nutzen ziehen konnte, den man erwartet hat, muß nicht gegen die Lösungsansätze oder die Werkzeuge sprechen. Es ist aber deutlich geworden und dies wird auch durch eine Studie unseres Lehrstuhls bestätigt, daß die Umsetzungsprobleme in der Praxis außer auf technische Probleme wesentlich auf einem Mangel an Verständnis und Beherrschung der organisatorischen und methodischen Aspekte zurückzuführen sind. Es ist also die Bedeutung der im ursprünglichen Konzept der Software Factory wesentlichen organisatorischen und methodischen Aspekte wiederentdeckt worden. Allerdings wird die Verbesserung der organisatorischen und methodischen Rahmenbedingungen der Softwareentwicklung nicht mehr unter dem inzwischen als kontaminiert geltenden Begriff Software Factory belrieben, sondern unter den Begriffen: Prozeßorientierung, Total Quality Management etc. Aber es gibt inzwischen neben der Kritik einer zu eingeschränkten Problemsicht auch substantielle Kritik an der Fabrikanalogie selbst. Das verbesserte Verständnis der Softwareprozesse hat die Grenzen der Analogie zu den Fabrikprozessen deutlich gemacht

A Systematic Analysis of the Effect of Task Clarity on Software Development Design

Two different types of development tasks are distinguished: Clear and unclear development tasks. Based on hypotheses from organizational theory two different designs of software development are derived. The transformational design is appropriate if the development task is clear. In case of an unclear development task software development should employ the adaptive design. The transformational design conforms to the explicit recommendations and implicit assumptions of process oriented software quality management, a software management style considered by many authors to be the universally valid paradigm of software development. Because of the fundamental differences between the two designs we conclude, that process oriented software quality management is not universally valid and should not be applied to unclear software development tasks

Produkt und Prozeß prüfen : ISO 9000 stellt nur Minimalforderungen

Qualitätsmanagement ist eine notwendige Voraussetzung für die Verbesserung der Produkte und Abläufe und damit für den Erhalt der Wettbewerbsfähigkeit. Dies gilt auch für die Entwicklung und die Wartung der Softwaresysteme