Tag Archives: Basis

Software Engineering vs. Computer Science [vs. the World]

Most of us, at least the ones building non-scientific software applications and systems, are dealing with software engineering issues rather than computer science ones. I see projects where most of the problems that arise are not technical ones that require the insight of a computer scientist to unveil the mystery by creating or applying a combination of theory and models that you would rather see in a CS research paper. Most of the problems are about how to deliver a functionality within a deadline (sometimes with the illusion of freewill), efficiency in communication within teams as well as with stakeholders, and trade-off analysis to select the best possible solution given a pool of resources (i.e. infrastructure, software tools, people, network, etc.) and constraints (functional, business, technical).

The mental exercise I follow to differentiate a software engineering issue from a computer science one is: Does the solution to the issue have impact on how projects are handled? or Does the solution contribute new elements to a body of knowledge that is more associated to how we perceive and work with computer systems?. Furthermore, I would propose the following diagram to assist a rookie or outsider to distinguish between the different kinds of computer-related knowledge.

How to differentiate between Software Engineering, Computer Science and the rest

How to differentiate?

On a similar note, Jeff Offutt, in an article for the IEEE Software magazine [1], tries to raise awareness about differences between Software Engineering and Computer Science from an Educational Framework perspective. He states:

If software engineering isn’t a branch of computer science, then we must ask practicing software engineers what they need to know that they don’t learn as part of CS degrees. Most computer science undergraduate students take one software engineering class, typically with a week or two spent on each phase in the traditional waterfall lifecycle model. A lot of the semester is devoted to process theory.[1]

He goes further by re-affirming a proposal that has not being fully applied in sound curricula: or adapt existing course proposal to equip students with useful tools for real-life work, or create a separate Software Engineering curriculum. He compares Physics to Mechanical Engineering, common base knowledge but different disciplines. But what the students need to learn in this, not a topic but a separate, discipline? The answer is in the work place, where practicality prevails over theory: usability, testing security, design modeling, project management, quality control, standards, architecture, embedded applications, evolution, Web applications, ethics, etc.


1. J. Offutt, “Putting the Engineering into Software Engineering Education,” IEEE Software, vol. 30, no. 1, 2013, pp. 94-96

Hello world!

Welcome to an interesting Blog for Software Engineering and related areas.

The IEEE Computer Society defines software engineering as: “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).”

An important start point is the Software Engineering Body of Knowledge (SWEBOK). The purpose of the Guide to the SWEBOK is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the Body of Knowledge supporting that discipline. The Body of Knowledge is subdivided into ten software engineering Knowledge Areas (KA) plus an additional chapter providing an overview of the KAs of strongly related disciplines.