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

Software Product Lines


Software product lines refers to engineering techniques for creating a portfolio of similar software systems from a shared set of software assets using a common means of production. Producing a set of related products as a product line has allowed organizations to achieve increased quality and significant reductions in cost and time to market. But adopting a product line approach to software is both a technical and a business decision that involves many challenges.


Mass production – the ability to efficiently create many copies of the same product – represented a big advance in the manufacturing world, though creating many copies of a software product is trivial. On the other hand, mass customization – the ability to efficiently create many variations of a product – is a big advance in both manufacturing and software engineering.
Some example organizational benefits according to the SEI:

  • Improved productivity by as much as 10x
  • Increased quality by as much as 10x
  • Decreased cost by as much as 60%
  • Decreased labor needs by as much as 87%
  • Decreased time to market (to field, to launch) by as much as 98%
  • Ability to move into new markets in months, not years

Obstacles and Economics of Product Lines

But along with the gains come risks. Using a product line approach constitutes a new technical strategy for the organization. Organizational and management issues constitute obstacles that are critical to overcome and often add more risk, because they are less obvious. Building a software product line and bringing it to market requires a blend of skillful engineering as well as both technical and organizational management. Acquiring a software product line also requires this same blend of skills to position the supplier organizations, so they can effectively exploit the commonality of the incoming products, as well as lend sound technical oversight and monitoring to the development effort. These skills are necessary to overcome the pitfalls that may bring failure to an unsophisticated organization.

A number of other considerations must be considered in order to implement a software product line, and an overhead is created. This will be reflected as an initial cost, which will discourage the implementation of the software product line for small projects. Consequently, a number of products (payoff point), along with a minimum complexity would be necessary before taking into consideration product lines.

Economics Of Product Lines

Key concepts

Software product lines can be described in terms of four simple concepts, as illustrated in the figure below:


Key Software Product Line Concepts

Key Software Product Line Concepts

  • Software asset inputs: a collection of software assets – such as requirements, source code components, test cases, architecture, and documentation – that can be configured and composed in different ways to create all of the products in a product line. Each of the assets has a well defined role within a common architecture for the product line. To accommodate variation among the products, some of the assets may be optional and some of the assets may have internalvariation points that can be configured in different ways to provide different behavior.
  • Decision model and product decisions: The decision model describes optional and variable features for the products in the product line. Each product in the product line is uniquely defined by its product decisions – choices for each of the optional and variable features in the decision model.
  • Production mechanism and process: the means for composing and configuring products from the software asset inputs. Product decisions are used during production to determine which software asset inputs to use and how to configure the variation points within those assets.
  • Software product outputs: the collection of all products that can be produced for the product line. The scope of the product line is determined by the set of software product outputs that can be produced from the software assets and decision model.

Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture. Building a new product (system) becomes more a matter of assembly or generation than one of creation; the predominant activity is integration rather than programming. For each software product line there is a predefined guide or plan that specifies the exact product-building approach.

What Software Product Lines Are Not

  • Clone and own: single-system development with reuse: only modifying code as necessary for the single system
  • Fortuitous small-grained reuse: reuse libraries containing algorithms, modules, objects, or component
  • Just component-based or service-based development: selecting components or services from an in-house library, the marketplace, or the Web with no architecture focus
  • Just versions of a single product: rather, simultaneous release and support of multiple products
  • Just a configurable architecture: a good start, but only part of the reuse potential
  • Just a set of technical standards: constraining choices without an architecture-based reuse strategy
Software Engineering Institute: Software Product Lines
Clements, P. and Northrop, L. Software Product Lines: Practices and Patterns. 2001. Addison-Wesley

Software Architecture Fundamentals

Although software architecture is a key factor in determining the success or failure of a software system, software professionals throughout the industry continue to struggle with questions like:

–   What exactly is a software architecture?
–   Why is software architecture important?
–   What factors influence the design of a software architecture?
–   Which requirements are most important during software architecture design?

The SEI defines Software Architecture as

the structure or structures of the system, which comprise the software elements, the externally visible properties of those elements, and the relationships among them

The importance of Software Architecture can be outlined in three high-level aspects:
  1. Firstly, it is a vehicle for communication, so the development team and stakeholders are able to inter-exchange ideas based on the same “language” and principles.
  2. Secondly, it is a manifestation of earliest design decisions that defines implementation constraints, among others.
  3. Finally, it is a transferable, reusable abstraction.

Now, which requirements are most important to architectural design? The following figure depicts Software Arquitecture as a product of the architectural design process, which depends on functional requirements, design constraints and quality attribute requirements.

Requirements and Architecture Design

Requirements and Architecture Design

The requirements are above and beyond functionality, and they require us to structure an architecture. They include design constraints and quality attributes.

Some issues in eliciting quality attribute requirements:
Non-Operational requirements
  • “The system must be easy to use.”
  • “The system must have high performance.”
  • “The system must be portable.”
Debating the quality attribute to which a system behavior belongs
  • “The system must process 10,000 messages per second.”
Vocabulary variations
  • Everyone knows what “high performance” means, right?

On the other hand, Software Architecture is influenced by the technical, business, and social environment.

Other influences on the Software Architecture

The understanding of this cycle helps us to plan for and manage change throughout the lifetime of a system.

Some influences on the Software architecture:

– Stakeholders

  • customers, users, managers, marketing, developers, maintainers, etc.

– Development organization

  • immediate and long term business goals
  • organizational structure

– Technical environment

  • object oriented, WWW, intelligent agents, EJB, service oriented, J2EE, thin client, .NET, etc.

Background and experience

  • architect and organizational experience
  • education and training

Furthermore, Software Architecture can influence on some aspects of the project and organisation. Lets take a look to some examples:

– Development organization

  • structure, goals, artifacts, etc.

– Stakeholder requirements

  • demand for similar features, existing components and system

Technical environment

  • relational databases, WWW, service oriented architectures, etc.

Background and experience

  • promote approaches that have been successful
  • reject approaches that have failed

Source: Software Architecture Fundamentals: Technical, Business, and Social Influences (Webinar):

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.