Forming theories of practices for software engineering | IEEE Conference Publication | IEEE Xplore

Forming theories of practices for software engineering


Abstract:

The paper outlines a model for theorizing about development practices, especially taking into account the intended rationale for, actual realization of, and resulting imp...Show More

Abstract:

The paper outlines a model for theorizing about development practices, especially taking into account the intended rationale for, actual realization of, and resulting impacts from using particular practices in varying contexts. This includes discussing of two different modes of thinking through which we can approach software development practices: technical rationality vs. reflection-in-action. By framing development practices taking place in software organizations as “organizational practices”, the paper also sketches previous practice research in organizations, which has profoundly informed this work. Finally, the paper compares the SEMAT approach to the outlined model, and suggests a few points of critique and complementary elements to the SEMAT initiative, especially in its capabilities towards theorizing.
Date of Conference: 26-26 May 2013
Date Added to IEEE Xplore: 30 September 2013
Electronic ISBN:978-1-4673-6273-3
Conference Location: San Francisco, CA, USA

I. Introduction

In IEEE Software, Johnson, Eksted and Jacobson [1] have recently argued for “the General Theory for Software Engineering”. Especially, they call for theories which should provide predictive and prescriptive support for software engineering, instead of running costly design processes that are plainly based on trial and error. They mention the issue of choosing software development methods in development projects and organizations as an example of significant questions, which should be tackled by such theory. Especially, Johnson et al. state that “many proposed […] methods, programming languages and requirements specification languages exist, but very few explicit theories explain why or predict that one method or language would be preferable to another under given conditions.” (p. 94).

Contact IEEE to Subscribe

References

References is not available for this document.