The dimensions of software engineering success

Software engineering research and practice are hampered by the lack of a well-understood, top-level dependent variable. Recent initiatives on General Theory of Software Engineering suggest a multifaceted variable – Software Engineering Success. However, its exact dimensions are unknown. This paper investigates the dimensions (not causes) of software engineering success. An interdisciplinary sample of 191 design professionals (68 in the software industry) were interviewed concerning their perceptions of success. Non-software designers (e.g. architects) were included to increase the breadth of ideas and facilitate comparative analysis. Transcripts were subjected to supervised, semi-automated semantic content analysis, including a software developer vs. other professionals comparison. Findings suggest that participants view their work as time-constrained projects with explicit clients and other stakeholders. Success depends on stakeholder impacts – financial, social, physical and emotional – and is understood through feedback. Concern with meeting explicit requirements is peculiar to software engineering and design is not equated with aesthetics in many other fields. Software engineering success is a complex multifaceted variable, which cannot sufficiently be explained by traditional dimensions including user satisfaction, profitability or meeting requirements, budgets and schedules. A proto-theory of success is proposed, which models success as the net impact on a particular stakeholder at a particular time. Stakeholder impacts are driven by project efficiency, artifact quality and market performance. Success is not additive, e.g., ‘low’ success for clients does not average with ‘high’ success for developers to make ‘moderate’ success overall; rather, a project may be simultaneously successful and unsuccessful from different perspectives

Towards a design theoretic characterisation of software development process models

Effective assessment, comparison, selection and adaptation of software development processes remain an acute problem in Software Engineering practice. The quest for a unified theory which might serve this purpose is ongoing. Objective: To take a first step towards such a theory, with focus on characterising and comparing features of software development process models. Method: We consider a theory of design as problem solving and investigate how it can be applied to characterise and explicate specific process features in well known process models from the literature. The intention is to characterise emerging trade-offs between resource expenditure and risk mitigation, which result from the interplay between process efforts into problem and solution exploration vs. stakeholder validation. The analysis, at this point performed, is purely qualitative, and the treatment of resource expenditure and risk quite abstract. Results: We provide an initial characterisation and comparison of features found in a wide range of process models from the literature, within a design theoretic framework using a single building block -- the Problem Oriented Engineering (POE) Process Pattern -- that allows the characterisation of information flow, the relationship between actors, resource usage and developmental risk. Conclusions: The initial characterisation identifies repeated structure in diverse processes, which allows basic process comparison across models. The interpretations are modular, allowing the possibility of relationships between different process models to be explored. As such, the theory allows for a unified means to characterise and compare systematically key features of different process models. In being of an exploratory nature, the work has a number of limitations, which should be addressed by further research

How software engineering research aligns with design science: A review

Background: Assessing and communicating software engineering research can be challenging. Design science is recognized as an appropriate research paradigm for applied research but is seldom referred to in software engineering. Applying the design science lens to software engineering research may improve the assessment and communication of research contributions. Aim: The aim of this study is 1) to understand whether the design science lens helps summarize and assess software engineering research contributions, and 2) to characterize different types of design science contributions in the software engineering literature. Method: In previous research, we developed a visual abstract template, summarizing the core constructs of the design science paradigm. In this study, we use this template in a review of a set of 38 top software engineering publications to extract and analyze their design science contributions. Results: We identified five clusters of papers, classifying them according to their alignment with the design science paradigm. Conclusions: The design science lens helps emphasize the theoretical contribution of research output---in terms of technological rules---and reflect on the practical relevance, novelty, and rigor of the rules proposed by the research.Comment: 32 pages, 10 figure

Querying histories of organisation simulations

Industrial Dynamics involves system modelling, simulation and evaluation leading to policy making. Traditional approaches to industrial dynamics use expert knowledge to build top-down models that have been criticised as not taking into account the adaptability and sociotechnical features of modern organisations. Furthermore, such models require a-priori knowledge of policy-making theorems. This paper advances recent research on bottom-up agent-based organisational modelling for Industrial Dynamics by presenting a framework where simulations produce histories that can be used to establish a range of policy-based theorems. The framework is presented and evaluated using a case study that has been implemented using a toolset called ES

The impact of situational context on software process: a case study of a very small-sized company in the online advertising domain

A primary concern of software development is selecting a suitable methodology to implement a software project. However, this selection is affected by many factors, with evidence suggesting that a specific set of factors defines a specific situational context for a project. This situational context leads to a project-specific software process. In this paper, we report on our analysis of a very small-sized company’s current software process based on a reference framework that identifies the factors of a situational context. The outcome of our case study confirms the earlier findings that a software process is highly dependent on situational factors. The company has a suitable situational context (such as very small-sized, experienced, skilled, cohesive team with low turnover) to apply agile practices and its software process is more close to an agile rather than plan-driven approach. Moreover, the company is continuously adopting its software process to the situational factors changing from project to project and over time