Problem Understanding the IEEE definition of Software Engineering

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!

“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.}

Software engineering and the definitions are as pliable and ambiguous as you want or need them to be.

While people end up throwing away a design and just fixing things that is more a function of deadlines and realistic deliverable schedules.

There is no such thing as the mythical man month, and there isn’t any hard and fast canon on what software engineering is.

I’ve coded since the 1980’s, but only a few times with a design at the outset. That’s why Cline is offering the non-explanation. It’s cynicism we all get under.

Now, I find the comments that software isn’t as disciplined as mechanical beam design or electrical circuit design rather gobsmacking. They don’t seem to realize just how much is deterministic inside firmware, hardware, and software in all the ways like every science in they are repeatable, observable, predictable, deterministic, falsifiable, ontological, and so on.

True, when you build a steel I-beam and you specify the flange dimensions and the tensile strength there’s not too much else to know about designing around them.

Rather, it is true that there is FAR MORE to be deterministic and knowledgeable about inside the software process – You could demand a transistor by transistor or functional explanation of circuitry and firmware registers for every processor, controller, and SOC chip. We don’t because we don’t take the time nor demand that kind of granularity. But that doesn’t mean we couldn’t.

Bill Gates was famous for knowing the Intel 8086 instruction and register sets for software but in no way was he a software engineer. He got his degrees by donating $100M+ to university wings. That’s when I threw away my IEEE membership, there’s no point in following a professional standards body that rolls over to whore itself for money showing what it really values.

I would argue that like all definitions of broad and perhaps countless the things that might be classifiable inside it that you think of software engineering not just as a definition but also a tension.

Tensions are good for quantifying somewhere between concepts.

Is there software engineering in software operation? Yes.

Is there software maintenance inside software engineering. If one planned a project with post commission maintenance, then yes.

Do all things that qualify as software operation qualify as software engineering? No.

Do all things that qualify as software maintenance qualify as software engineering? No.

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.

Filed under: softwareengineering - @ 23:53

Thẻ: definition, engineering, software

Thiết kế website giá rẻ

Danh mục

Problem Understanding the IEEE definition of Software Engineering