SEMAT Blog SEMAT Blog

Back

What is the Scope of Software Engineering?

Looking at the discussions that have been appearing in response to the initial SEMAT-related blog posts, there appears to be little shared understanding of what we in the software world mean by the term “software engineering” or why it was selected ahead of other candidates such as “software development” or “computer science”.

The importance of the wording is also illustrated by the other discussions that touch on topics such as ”what is the relationship between software engineering and the management of software engineering projects?”, and “what is the relationship between software engineering and systems engineering?” There have even been other people publishing blogs on the suitability of the term software engineering as the banner for an initiative of this sort, one of our favourites being http://parijatmishra.wordpress.com/2010/01/08/188/.

Within the SEMAT group, we already have differences of opinion as to what the term “software engineering” should mean.

Some people want to start with the Wikipedia (http://en.wikipedia.org/wiki/Software_engineering) definition, which comes from the Software Engineering Body of Knowledge:

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Alistair Cockburn is on record disagreeing with that definition, noting the difference between that definition and the the American Engineers’ Council for Professional Development (ECPD, the predecessor of ABET[1]) definition of engineering as:

[T]he creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.

Alistair develops his criticism of the term “software engineering” in his article http://alistair.cockburn.us/The+end+of+software+engineering+and+the+start+of+economic-cooperative+gaming). He proposes a model for software engineering (and engineering itself) that is comprised of

  • craft,

  • cooperative gaming,

  • lean processes, and

  • design as knowledge acquisition.

You can see his talk on the subject at http://alistair.cockburn.us/Software+engineering+in+the+21st+century.ppt.

The two of us take working through this disagreement as a part of the SEMAT assignment. We hope that by bringing all of the signatories and supporters together, we can refound software engineering to reflect these and other important perspectives.

This gets us to the question: Should SEMAT address “software engineering” or all of software development?

The term “software development” includes every type of software development, from simple spreadsheet macros to the programming of personal websites, up the scale to drawing packages, game development, massively  parallel scientific calculators, civil-engineering structural simulations, and the running of nuclear submarines. There are so many differences in the optimal working habits across these activities that we think it is too broad of a scope for the SEMAT charter.

“Software engineering” points to a subset of software development where the term “engineering” can be felt as appropriate. That is likely to exclude small efforts where the danger of failure is only loss of comfort. It should include efforts where lives are at stake, from structural simulators for civil engineering projects to medical devices and power control systems. In government and defence projects, there will be many projects – even non-life-critical projects – that need the “engineering” aspects. There will be others that don’t. The two of us recognize those differences.

We choose to stay with the term “software engineering” for SEMAT because we believe that the growth and success in of the targeted category of projects depends on the elaboration and evolution of an engineering perspective with its emphasis on evidence-based practices grounded in sound theory.

It should be obvious that if we SEMAT supporters succeed with our goals, many of the other software development projects may find it useful to adopt parts of our result.

One of the goals of the SEMAT initiative is to establish a baseline theory that can be tested and evolved over time. The SEMAT initiative will clarify what we mean by “software engineering” and define a kernel that embodies that definition.

Ivar Jacobson proposes that that theory, amongst other things, clearly:

  • Identifies the bounds of software engineering.

  • Allows software engineering practices and principles to be defined, studied, and improved.

  • Shows that software engineering is a form of collaborative activity.

  • Enables the measurement and comparison of the effectiveness of different practices and teams.

Alistair’s proposes that when we are done, the term “software engineering” should

  • explain why successful projects succeed and failing projects fail,

  • intrinsically name topics known to be important to project success,

  • lead a person on a live project to derive sensible advice as to how to proceed,

  • provide a sound pedagogical base for teaching newcomers to the field.

Now these are not conflicting goals. The two of us are both working together on SEMAT because we both believe it is possible to refound software engineering in a way that addresses all our concerns. Starting to address the question “What is Software Engineering?” will be a key part of the initial SEMAT meeting in Zurich. But there is no reason to wait to start our discussions, please feel free to support our working definitions or propose others that you prefer and that we all can learn from.  Remember the goal here is but to create an environment where we can learn from each other and build a new, less partisan consensus.

— Ivar Jacobson and Alistair Cockburn

with thanks to Ian Spence and Larry Constantine for their help in pulling this blog entry together.

Comments
No comments yet. Be the first.