Maia Daneva

A requirements engineering framework for cross-organizational ERP systems

The development of cross-organizational enterprise resource planning (ERP) solutions is becoming increasingly critical to the business strategy of many networked companies. The major function of cross-organizational ERP solutions is to coordinate work in two or more organizations. However, how to align ERP application components and business requirements for coordination and cooperation is hardly known. This paper reports on the outcomes of applying a coordination theory perspective to an analysis of the ERP misalignment problem. We present a conceptual framework for analyzing coordination and cooperation requirements in inter-organizational ERP projects. The framework makes explicit the undocumented built-in assumptions for coordination and cooperation that may have significant implications for the ERP adopters and incorporates a library of existing coordination mechanisms supported by modern ERP systems. We use it to develop a proposal for how to achieve a better alignment between ERP implementations and supported business coordination processes in inter-organizational settings. We report on some early assessments of the implications of our framework for practicing requirements engineers. Both our framework and library rest on a literature survey and the first author’s experience with ERP implementation. In future empirical research, we will further validate and refine our framework.

Six strategies for generalizing software engineering theories

General theories of software engineering must balance between providing full understanding of a single case and providing partial understanding of many cases. In this paper we argue that for theories to be useful in practice, they should give sufficient understanding of a sufficiently large class of cases, without having to be universal or complete. We provide six strategies for developing such theories of the middle range. n nIn lab-to-lab strategies, theories of laboratory phenomena are developed and generalized to other laboratory phenomena. This is a characteristic strategy for basic science. In lab-to-field strategies, theories are developed of artifacts that first operate under idealized laboratory conditions, which are then scaled up until they can operate under uncontrolled field conditions. This is the characteristic strategy for the engineering sciences. n nIn case-based strategies, we generalize about components of real-world cases, that are supposed to exhibit less variation than the cases as a whole. In sample-based strategies, we generalize about the aggregate behavior of samples of cases, which can exhibit patterns not visible at the case level. We discuss three examples of sample-based strategies. n nThroughout the paper, we use examples of theories and generalization strategies from software engineering to illustrate our analysis. The paper concludes with a discussion of related work and implications for empirical software engineering research.

Cross-organizational ERP management: how to create a successful business case?

This paper deals with the development and use of business cases in support of cross-organizational enterprise resource planning (ERP)-enabled e-business integration initiatives. In order to ensure that such a project starts successfully, we will focus on pre-implementation activities. We propose a set of business case guidelines that emphasize the importance of benefits management during ERP implementations.

Validating Adequacy and Suitability of Business-IT Alignment Criteria in an Inter-Enterprise Maturity Model 202

Aligning requirements of a business with its information technology is currently a major issue in enterprise computing. Existing literature indicates important criteria to judge the level of alignment between business and IT within a single enterprise. However, identifying such criteria in an inter-enterprise setting - or re-thinking the existing ones - is hardly addressed at all. Business-IT alignment in such settings poses new challenges, as in inter-enterprise collaborations, alignment is driven by economic processes instead of centralized decision-making processes. In our research, we develop a maturity model for business-IT alignment in inter-enterprise settings that takes this difference into account. In this paper, we report on a multi-method approach we devised to confront the validation of the business-IT alignment criteria that we included in the maturity model. As independent feedback is critical for our validation, we used a focus group session and a case study as instruments to take the first step in validating the business-IT alignment criteria. We present how we applied our approach, what we learnt, and what the implications were for our model.

Approaching the ERP Project Cost Estimation Problem: an Experiment

This poster reports on a solution to ERP project cost estimation and on results from its first experimental application.Although models have been proven to be helpful in a number of software engineering activities there is still significant resistance to model-driven development. This paper investigates one specific aspect of this larger problem. It addresses the impact of using statecharts for testing class clusters that exhibit a state-dependent behavior. More precisely, it reports on a controlled experiment that investigates their impact on testing fault-detection effectiveness. Code-based, structural testing is compared to statechart-based testing and their combination is investigated to determine whether they are complementary. Results show that there is no significant difference between the fault detection effectiveness of the two test strategies but that they are significantly more effective when combined. This implies that a cost-effective strategy would specify statechart-based test cases early on, execute them once the source code is available, and then complete them with test cases based on code coverage analysis.

Requirements engineering for cross-organizational ERP implementation undocumented assumptions and potential mismatches

A key issue in requirements engineering (RE) for enterprise resource planning (ERP) in a cross-organizational context is how to find a match between the ERP application modules and requirements for business coordination. This paper proposes a conceptual framework for analyzing coordination requirements in inter-organizational ERP projects from a coordination theory perspective. It considers the undocumented assumptions for coordination that may have significant implications for ERP adopting organizations. In addition, we build a library of existing coordination mechanisms supported by modern ERP systems, and use it to make a proposal for how to improve the match between ERP implementations and supported business coordination processes. We discuss the implications of our framework for practicing requirements engineers. Our framework and library are based on a literature survey and the experience with ERP implementation of one of us (Daneva). We further validate and refine our framework.

Cooperation between information system development and operations: a literature review

Software development can profit from improvements in the deployment and maintenance phases. DevOps improves these phases through a collection of principles and practices, centered around close collaboration between Development and Operations personnel. Both sides have paid little attention to issues faced by each other. Yet knowledge sharing is invaluable. Development personnel can for example make software more robust by implementing scalability and performance features desired by operations personnel.

Human factors in software development: On its underlying theories and the value of learning from related disciplines. A guest editorial introduction to the special issue

Human factors play a very important role in Software Development [1]. According to Avison et al. [2] ‘‘Failure to include human factors may explain some of the dissatisfaction with conventional information systems development methodologies; they do not address real organizations’’ (p95 [2]). Software development has nbeen characterized in essence as a human activity [3] where nhuman factors play a critical role [4]. While the area of Human Factors spans a lot of different and diverse concepts and theories, the human factors aspects most often studied in software engineering research include coordination [5,6], collaboration in the development process [7–9], trust [10], expert recommendation [11], program comprehension [12], knowledge management n[13,14] and culture [15]. nThe growing importance of human factors in software development research is clearly evidenced by the fact that the ICSE 2014 conference a track entirely devoted to Human factors, namely, ‘‘Social Aspects of Software Engineering’’. Furthermore, the 2014 ICSE conference keynote by James Herbsleb [16] presented the theory nof socio-technical coordination and represented a call for further development of theories on coordination in Software nEngineering (SE). In this editorial we not only reiterate this call, but also suggest SE researchers to draw on reference disciplines such as the field of Information Systems to borrow well-established theories. nIn the next section we first present empirical evidence on the importance of research involving Human Factors in the field of Software Engineering. We then run a citation analysis exercise to identify the prominent theories related to Human Factors in SD.

Lessons learned from evaluating a checklist for reporting experimental and observational research

This short paper summarizes and discusses the result of an iterative construction and evaluation of a checklist for writing and reading reports about experimental and observational research.

What you ask is what you get: Understanding architecturally significant functional requirements

Software architects are responsible for designing an architectural solution that satisfies the functional and non-functional requirements of the system to the fullest extent possible. However, the details they need to make informed architectural decisions are often missing from the requirements specification. An earlier study we conducted indicated that architects intuitively recognize architecturally significant requirements in a project, and often seek out relevant stakeholders in order to ask Probing Questions (PQs) that help them acquire the information they need. This paper presents results from a qualitative interview study aimed at identifying architecturally significant functional requirements categories from various business domains, exploring relevant PQs for each category, and then grouping PQs by type. Using interview data from 14 software architects in three countries, we identified 15 categories of architecturally significant functional requirements and 6 types of PQs. We found that the domain knowledge of the architect and her experience influence the choice of PQs significantly. A preliminary quantitative evaluation of the results against real-life software requirements specification documents indicated that software specifications in our sample largely do not contain the crucial architectural differentiators that may impact architectural choices and that PQs are a necessary mechanism to unearth them. Further, our findings provide the initial list of PQs which could be used to prompt business analysts to elicit architecturally significant functional requirements that the architects need.