Problem Understanding the IEEE definition of Software Engineering

Question

Background

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

My instructor, when explaining this definition has told me that the terms "systematic", "disciplined" and "quantifiable" imply "one after another, structured", "repeatable", and "measurable" among various other possible interpretations. However, it's the second part of the definition that confuses me. When talking about what "operation" implies, he described it this way: "it's the process of maintaining the software, like updating or patching pieces of it. Earlier we used to remove the whole software and change the source, recompile it and install it back. This part of definition is more or less of historical significance - the way engineering was thought of in other disciplines like Mechanical Engineering."

Question

I am really confused about what the definition implies about SE.

• If "operation" was just the process of maintaining the software, why include it in the definition independently?
• If not, What do the terms "Operation" and "Maintenance" imply in the definition?
• Don't maintenance and Operation and everything come under development? Let's say we are developing an automatic updater component of a software for maintenance, doesn't that mean we are "developing" the "maintenance" part too? Why include the other two in definition then?

Please explain me what SE really means. Thank You!

Answer 1

"Operation" has to do with deploying, configuring, starting/stopping, and monitoring the software. For example, at my shop, development builds a tarball of the application and stages it to a specific location on the production server. Another group takes the tarball, expands it into the target directory, sets up Kerberos credentials, adds entries to several databases, etc. We have several utilities that monitor the applications; one gathers statistics, one issues an alert if an application has gone down, one bounces the app if a connection's been dropped or we need to get a new Kerberos ticket, one archives and rotates log files, one looks for and identifies core files, etc. There's also a configuration file that can be updated if an IP address or port number changes, or if some application-specific configuration parameter needs to be enabled/disabled, etc.

None of these things involve touching the source code, so it's a separate activity from maintenance and development. All of these activities have well-defined processes and procedures¹ associated with them.

Software Engineering isn't about writing code. Software Engineering is about developing processes and procedures that make the act of writing and running code more reliable and repeatable.

Edit

Maintenance (at least in my head) encompasses all the non-coding activities involved with managing an application over its lifetime. This includes (but is not limited to) managing defect and incident reports, deciding which defects are fixed in the next patch, scheduling and staging patches, etc. Some other examples from my shop are migrating applications from one server to another, migrating a customer from one backend application to another, doing performance and traffic analysis and spawning additional instances to handle increased traffic or minimize response times, etc.

Development (again, in my head, "official" definitions may vary) is anything that touches code, whether it's writing new code from scratch or patching existing code.

---

^{1 - Process == what you do, procedure == how you do it.}

Answer 2

SE is mostly BS, because software is not a physical artifact.

Real engineering disciplines (electrical, civil, mechanical, chemical) are applied science. They accumulate knowledge about the limitations of materials and use that to build systems that are safe and effective. We estimate the time and cost of physical construction projects after the design is complete. For novel projects estimation is still inaccurate.

Software development is ALL design, and every project is new. (Otherwise we would just reuse existing code). The limitations are not physical but psychological, and they are highly variable. There is no standard "programmer-hour". Some programmers can solve problems in hours that others will never solve. There is little or no difference between the work needed to produce an estimate and the work needed to produce a solution.

We have learned some techniques for organizing code that seem to help. However poor programmers not only don't follow those techniques, they don't understand them. In this way "software engineering" resembles "education science" -- there's no magic formula for programming or teaching.