From time to time, I dip into (and out of) a podcast series called Software Engineering Radio, which is produced by the IEEE. It’s a really useful resource, and one that I’ve previously mentioned in the blog post Software engineering podcasts.
This is the first of a series of blog posts that shares some notes I’ve made from a number of episodes that I have found especially interesting and useful. In some ways, these posts can be through of a mini course on software engineering, curated using the voices of respected experts.
Towards the end of each blog, I share some informal thoughts and reflections. I also share some links both earlier posts and other relevant resources.
I hope this series is useful for students who are studying TM354 Software Engineering, or any other OU module that touches on the topic of software engineering or software development.
Software engineering as a discipline
When doing some background reading (or listening) for TM113, I found my way to SE Radio 149: Difference between Software Engineering and Computer Science with Chuck Connell.
In this episode, there are a couple of sections that I bookmarked. The first is 10:20 through to 12:20, where there is a discussion about differences between the two subjects. Another section runs between 24:10 and 25:25, where there is an interesting question: is software engineering a science, an art, or a craft? The speaker in the podcast shares an opinion which is worth taking a moment to listen to.
According to the software engineering body of knowledge (SWEBOK), engineering is defined as “the application of a systematic, disciplined, quantifiable approach to structures, machines, products, systems or processes” (SWEBOK v4.0, 18-1). Put in my own words, engineering is all about building things that solve a problem, in a systematic and repeatable way that enables you to evaluate the success of your actions and the success of what you have created.
An early point in chapter 18 of SWEBOK is the need to: “understand the real problem” which is expanded to the point that “engineering begins when a need is recognized and no existing solution meets that need” (18-1). Software, it is argued, solves real world problems. This takes us to a related question, which is: how do we define what we are building? This takes us to the next post, which is all about requirements.
Before having a look at requirements, it is useful to break down ‘software engineering’ a little further. The SWEBOK is divided into chapters. The chapters that begin with the word ‘software’ are: requirements, architecture, design, construction, testing, maintenance, configuration management, engineering management, engineering process, models and methods, quality, security, professional practice, economics.
There are three others which speaks to some of the foundations (and have the word ‘foundation’) in their title. They are: computing, mathematical, and engineering.
Reflections
Software is invisible. It is something that barely exists.
The only way to get a grasp on this ‘imaginary mind stuff’ of software is to measure it in some way. The following bits of the SWEBOK is helpful: “Knowing what to measure, how to measure it, what can be done with measurements and even why to measure is critical in engineering endeavors. Everyone involved in an engineering project must understand the measurement methods, the measurement results and how those results can and should be used.” (SWEBOK v4, 18-10). The second sentence is particularly interesting since it links to the other really important element in software engineering: people. Specifically, everyone must be able to understand the same thing.
The following bit from the SWEBOK is also helpful: “Measurements can be physical, environmental, economic, operational or another sort of measurement that is meaningful to the project”.
Next up is software requirements. By writing down our requirements, we can begin to count them. In turn, we can begin to understand and to control what we are building, or working with.