With the further developments of the Chartered Information Technology Professional status, or CITP, BCS, the Chartered Institute for IT, encourages us to reconsider our understanding of our profession.
Our professional community is founded in our deep understanding of the complex technologies in our toolbox and it exists to provide solutions to our stake-holders' needs: fit-for-purpose, validated and appropriate. The challenges we face are defined by our context, by our clients, and by other stakeholders.
As an independent professional community, what we do defines who we are. And software engineering, if not all of what we do, is a critical part of it.
But can we say we know what software engineering is?
The term software engineering was coined for the 1968 NATO Software Engineering Conference, and was meant to provoke thought regarding the perceived "software crisis" at the time. Even if it is in general use nowadays, as a term software engineering is still somewhat obscure, used by many to mean many different things.
The respected IEEE Computer Society's Software Engineering Body of Knowledge (the SWEBOK) defines software engineering as "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches".
It's not a bad definition, overall, and contains many important and useful words: "systematic", "disciplined", "quantifiable", are all important, as is "study"'. There's a less satisfying subsidiary part to the definition, however, in that it continues to say: "... that is, the application of 'engineering' to software".
This part of the definition has always disappointed me: according to SWEBOK, software engineering is, ahem, the application of 'engineering' to software.
It's an ill wind, though, so let's follow SWEBOK's guidance for a moment longer and find a definition of engineering and apply it to software. There is a very precise, appropriate and applicable characterisation of software engineering by Gordon Rogers, writing in 1983 , that describes engineering as: "[...] the practice of organising the design and construction of any artifice which transforms the physical world around us to meet some recognised need."
Part of the utility (and beauty) of this definition is its vast applicability to the engineering disciplines in capturing its essential practical nature. Moreover, it makes completing the SWEBOK definition simple: "Software engineering refers to the practice of organising the design and construction of software to run within a physical computer installation which transforms the physical world around us to meet some recognised need."
Not so shabby, eh? Software engineering is a practical discipline defined by the things done to organise the design and construction of software to run on machines which affect their environment. Even better, critical characteristics follow: the fact that a software system is delivered to and changes its physical context - including, or course, the system's many stakeholders - so that a previously recognised need is met.
Loads of other important stuff comes from this definition: the need for management, measures and metrics, notations, ideas of fitness-for-purpose, and organising principles (such as software architectures), to name but a few.
The ease with which our new definition mixes software with engineering is disarming, and care is needed. It does not, for instance, justify the natural, indeed historically observed, tendency to take engineering tools from other disciplines and to adopt or adapt them to software. On this point there are may counter-indications:
• Software is a formal language, whilst a computer system is a physical product, therefore, logical and physical representations of a programmed computer system will need to co-exist, and be co-designed;
• software, as a digital entity, does not benefit from interpolation between validating experiments using the properties of continuity;
• software is mutable in a way that physical products are not, leading to often unrealistic expectations of a stepped, or evolutionary, approach to any end point;
• software is unique in existing almost exclusively in a designed state.
The same arguments tell us, also, that we should not infer that every needed software engineering tool or technique already exists within other engineering disciplines, only to be adapted for and to software.
Much time consuming (but necessary) adaptation and invention has occurred (and continues to occur) to bring us to our current understanding of software engineering and our profession. Unfortunately, much of the experimentation has been in the gaze of an expectant, initially enthusiastic, latterly critical lay audience that includes politicians, policy makers and business leaders.
Because of this, our Chartered Institute faces very many challenges in fostering our profession. But what better start could we ask than a debate to establish a deeper understanding of it, and hence of IT.
Dr Jon G Hall is a senior lecturer and researcher in the computing department at the Open University.
Previous articles by Dr Jon Hall
Sign-up to Computer Weekly to download reports on software engineering