4

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!

6
  • 2
    Not to disagree with your esteemed professor, but "operation" is most certainly not "maintenance." Jan 15, 2013 at 17:45
  • @RobertHarvey: Well, he actually said that it was more about the "process of maintenance" rather than "maintenance" Jan 16, 2013 at 9:21
  • 3
    "Earlier we used to remove the whole software and change the source, recompile it and install it back." - We still do exactly this even today Your professor's definition of operation is clearly wrong, since maintenance is already listed, it would actually be more "operating" the software your maintaning and developing.
    – Ramhound
    Jan 16, 2013 at 15:45
  • 1
    @ForbiddenOverseer - I do that daily when I maintain software that is being updated because a defect was reported against it.
    – Ramhound
    Jan 17, 2013 at 11:53
  • 1
    @ForbiddenOverseer Any update will remove the software as soon as a newer version is successfully installed.
    – gnasher729
    Jun 16, 2018 at 22:35

2 Answers 2

7

"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 procedures1 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.

5
  • That was nice! What exactly is maintenance in this regard? and What does maintenance have to do with development of software? (I mean does it include developing or not?) Jan 16, 2013 at 9:19
  • @ForbiddenOverseer: see my edit.
    – John Bode
    Jan 16, 2013 at 12:02
  • Let me summarize what I understood: SE is more than just writing code, "operation" is about maintenance activities that have nothing to do with the code of software whereas "maintenance" is about maintenance activities that may have something to do with the code inside our software. The boundaries between these three terms are not that clear, meaning some of the activities we perform may come under more than one of them. Was I right in my understanding? BTW, "Maintenance encompasses all the non-coding activities involved with managing an ..." is confusing because of that "all non-coding". Jan 16, 2013 at 14:56
  • Again, these are definitions I use, not necessarily what you'd find in a SE textbook. "All non-coding tasks" simply mean anything that doesn't involve modifying the source code. Assigning defects to developers is a maintenance task, but not a coding task, it that makes things more clear. Migrating a customer from one server to another is also a maintenance task, but not a coding task.
    – John Bode
    Jan 16, 2013 at 15:14
  • I think I got what ur saying there... Thank you!! :D Jan 17, 2013 at 6:22
-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.

3
  • I disagree that your view applies in every situation. I think software is such a deep and broad field today, that some software can and should be engineered, while some need not be. Jun 17, 2018 at 16:12
  • 1
    Also it sounds like you’re trying to repeat an argument from an older blog post that’s been circulating for years. I’ll see if I can dig up a link. But I think that post’s argument was more nuanced. Jun 17, 2018 at 16:57
  • 1

Not the answer you're looking for? Browse other questions tagged or ask your own question.