On a theory of software engineering a proposal based on transaction cost economics

Abstract

This article leverages the findings of the transaction cost economics field, and proposes a simple theory and associated vocabulary to serve as a foundation for a unified theory of software engineering. It characterizes software engineering as a set of transactions organized under three governance structures. The theory explains the strengths and weaknesses of these governance structures in relation to asset specificity. It takes into account the recursive nature of the notions in software engineering, and applies uniformly to various contexts at different levels of granularity. The theory not only provides an explanatory framework for some of the propositions given in the software engineering literature, but also reveals the boundaries of their applicability.

Extending essence kernel to enact practices at the level of software modules

“…Faced with a high level of uncertainty, requirements may fail to converge, project risks can go higher or it can be hard to monitor and measure progress. In [4], it was concluded from transaction cost economics theory, that projects which have high levels of asset specificity and uncertainty prefer bottom-up governance, whereas projects with low levels of asset specificity and uncertainty favor top-down governance. Different modules of a software development project, however, may have different characteristics in relation to asset specificity and uncertainty.…”

“…The need for heterogeneous methodologies is expressed in a recent study [4] which leveraged transaction cost economics to build foundations for a general theory for software engineering. This study reached to the conclusion that the characteristics of a software development project, in particular, asset specificity and uncertainty, affects the choice of governance structure for that project.…”

“…Reuse with modifications, which is the realistic case of reuse is represented as a compound case, where modification effort is regarded as a separate effort. In [4], asset specificity is defined as a measure of how much the software is specific for a need. It may take different forms in software engineering, such as application, domain, platform, tool, language or interface specificity.…”

“…Likewise, software tools used for design and requirement management also provide a way to create modular work pieces in order to cope with the growing complexity. Furthermore, it is quite plausible that within the same project, development of certain modules may require more discipline, while development of other modules may require more agility [4]. We use the term "heterogeneous methodologies" to refer to this type of development.…”

Using ESSENCE ALPHAs in a CMMI level 5 software development organization

“…The characteristics of a software development project, in particular, asset specificity and uncertainty, affect the choice of governance structure of a project [1]. For that reason, it is important to define a governance structure for monitoring and controlling the project according to its particular context.…”