Software Engineering

A Brief Introduction

Gerson Sunyé


  1. Software Engineering

  2. Modern Software Complexity

  3. Software Modeling

  4. Software Development Process

  5. Conclusion


  • Understand the complexity of modern software systems.

  • Preview of the recommended solution:

    • Separation of concerns.

    • Technical continuity: from models to programs.

    • Activity continuity: from requirements to delivery and then to evolution.

Part I: Software Engineering

The Little History

  • In 1843, Ada Lovelace translates Frederico Luigi de Menabrea’s paper “Sketch of the Analytical Engine Invented by Charles Babbage”, adding several notes.

  • Note G describes a detailed algorithm for computing Bernoulli’s numbers with the analytical engine.

440px Ada Lovelace portrait
Figure 1. Ada Lovelace
Figure 2. Lovelace’s diagram from "note G", the first published computer algorithm

The First Computer Programmer

  • Ada translated well known formulae into an implementable algorithm.

  • This activity is the core of the software engineering process.

Definition of Software Engineering

Software engineering (SE) 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 [SWEBOK]
— Software Engineering Body of Knowledge

A Systematic Approach

An approach that follows a method, with rigor and precision

A Disciplined Approach

An approach that shows a controlled form of behavior

A Quantifiable Approach

An approach that can be measured: from the input until the output

Software Engineering Approach

software engineering approach
Figure 3. UML Activity Diagram

Software Engineering Activities

  • Describe: requirements, design, specification, documentation…​

  • Implement: modeling, programming

  • Assess: testing and other V&V techniques

  • Manage: plans, schedules, communication, reviews

  • Operate: deployment, installation, operation.

software engineering activities

Software Engineering Components

Figure 4. SE Components, [Ghezzi]
  • Principles: Foundations of software engineering: decomposition, abstraction, generality, reuse, etc.

  • Techniques: Best practices, reuse techniques.

  • Methods: Guidelines and rules for activity organization.

  • Tools: Support the automatization of techniques and methods.

Part II: Modern Software Complexity

Modern Software

  • Emerging computing paradigms: Internet of Things (IoT), Cloud, Fog, Edge, etc.

  • New platforms: iOS, Android, RIOT-O, TinyOS, etc.

  • New requirements: OpenData, Smart Manufacturing, Smart Health, Deep Learning, etc.

The Increasing complexity of Software has an impacts on their quality attributes.

Mastering Complexity


Impact on Quality Attributes

  • Size

  • Critical, Real-Time, Embedded

  • Elasticity

  • Scalability

  • Reusable, Durable

  • Long Term Availability

  • Distributed Data Processing

  • Large-Scale Development

  • Ubiquity


historic loc

Reliability, Availability, Maintainability and Safety (RAMS)

  • Safety-Critical Systems

tesla model s tech 2
Figure 5. Tesla model S, more than 200 million lines of code


Figure 6. Samsung’s 2014 product lineup




skype usage
Figure 7. Skype Usage

Distributability, Process Capability, Responsiveness

  • Distributed data processing

  • 300,000 servers, distributed on more than twenty data centers, responding to more than 1 billion queries per day, each one interrogating 8 billions web pages in less than a fifth of a second

  • Google Data Center FAQ

Long-term support (LTS): Reliability, Maintainability, Serviceability

Airbus A300 Lifecycle:

  • Program started in 1972, production ended in 2007 (35 years).

  • Support will last until 2050 (78 years!).

  • On board software development for very long lifecycle products.

Airbus A300B2 1C%2C Air France AN0598358

Large-Scale Development


  • 6,000 developer / 1,500+ projects

  • Each product has custom release cycles few days to few weeks

  • 1(!!) code repository, no binary releases, everything builds from HEAD,

  • 20+ code changes per minute, 50% of the code changes every month


smart home

Part III: Model-Based Software Engineering

How to Master the Complexity of Modern Software?

  • Main Principles: Abstraction, Reuse (among others)

  • Techniques: Modeling, Separation of Concerns

Modeling in Science & Engineering

  • A Model is a simplified representation of an aspect of the World for a specific purpose.

  • Specificity of Engineering: Model something inexistent (in order to build it).

modeling world

Why Model?

  • To think: Understand, Clarify, Describe

  • To communicate: Graphical representation, document generation.

  • To automate the development: Code generation, Quality evaluation, Migration

  • To validate: Validation and verification: simulation, model-checking, testing.

why model

Models rather than Code

  • A model is a simplification (abstraction) of the reality.

  • We build models to better understand a system behavior.

  • We need to model complex systems because we are unable to understand them globally.

  • The code does not simplify the reality.

Models and the Reality

  • Sun Tse: Do not take the map for the reality

  • William James: The concept 'dog' does not bite

Figure 8. La Trahison des Images, René Magritte, 1929
  • Jorge Luis Borges imagines an empire where the science of cartography becomes so exact that only a map on the same scale as the empire itself will suffice.

Figure 9. On Exactitude in Science, Jorge Luis Borges, 1929

Modeling to Master Complexity

Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. (…​)
A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality [Rothenberg].
«The Nature of Modeling»
— Jeff Rothenberg

Separation of Concerns

  • Separation of concerns is a principle for separating a system into distinct sections, where each section addresses a separate concern.

Separation of Concerns in Software Engineering

Software systems have different actors, each one with different concerns:
  • Software Designers

  • Data engineers

  • Security Manager

  • Application Architect

  • Network Security Administrator

  • etc.


Different actors have different:
  • Concerns.

  • Jobs and tasks.

  • Competences.

  • Tools.

  • Software artifacts.

Separation of Concerns in Civil Engineering

system concerns
house concerns
Figure 10. Separation of Concerns in Less Complex Systems

Different Models of a System

Models for:
  • Firefighters

  • Property developers

  • Residents

  • Plumbers

  • Electricians

  • Landscape architects

  • Architects

  • Notaries

  • Insurers

  • Cadastre

electrical plan
civil plan

Different Models of a Software System

system models

Part IV: Software Development Processes

Software Processes

software process
  • A sequence of activities required to produce a software system.

  • Different processes, all involving (at least):

    • Specification: what the system should do.

    • Design: how the system should be organized.

    • Implementation: realization of the system as a program.

    • Validation: check that the system does what it is supposed to do.

    • Evolution: changes according to user new needs.

Software Process Model

  • Abstract representation of a process.

  • Examples:

    1. Waterfall model.

    2. Spiral model.

    3. Agile model.

    4. Iterative and incremental model.

The Waterfall Model

royce summary
Figure 11. Managing the Development of Large Software Systems [Royce] [1970]

Myths about the Waterfall Model

Myth 1:
  • The process is iterative.

  • The idea of a “non-iterative process” is false.

Myth 2:
  • Royce never named the model «Waterfall», this was done later.


  • Industrial organization inherited from the 19th century: reassuring for managers, but inefficient.

  • Antinomy: Coplien’s organizational pattern “Architects also Implement”.

  • Implicit linearity:

    • Document approval time may have a buffering effect.

    • Final document modification cost.

  • Unrealistic for risky, innovative projects.

The Spiral Development Model

bohem summary
Figure 12. Spiral Development: Experience, Principles, and Refinements [Boehm] [1988,2000]


  • Well-adapted for innovative projects:

    • Tangible progress: delivery of running software, not only tons of papers.

    • Can be stopped at any time (for instance, before creating a money pit).

  • Difficult to manage and to control. Improvements become code hacking.

  • Increments obey to 2 among 3 rules:

    • Period (e.g. weekly).

    • Functionalities (e.g. Use Cases).

    • Quality level (Software testing, quality factors, etc.)

The Agile Development Model

scrum process


  • Scalability: difficult to scale to large, complex projects.

  • Glorification of emergency: provides a lot of value in the short-term, but become toxic and demoralizing in the long run.

Iterative and Incremental Model (RUP)

rup iterations
  • Horizontal axis: the dynamic structure (phases in time).

  • Vertical axis: the static structure (disciplines).


  1. Inception: The idea for the project is stated. The development team determines if the project is worth pursuing and what resources will be needed.

  2. Elaboration: The project’s architecture and required resources are further evaluated. Developers consider possible applications of the software and costs associated with the development.

  3. Construction: The project is developed and completed. The software is designed, written, and tested.

  4. Transition: The software is released to the public. Final adjustments or updates are made based on feedback from end users.


An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release.

Examples of Phases and Iterations

InceptionElabo-rationConstructionTransitionProject LengthIteration Length






3-4 months

2-3 weeks






9-12 months

5-7 weeks

Software Process Engineering

  • Supports the creation of flexible process models.

  • OMG related standard: Software & Systems Process Engineering Meta-Model Specification (SPEM).

  • Main elements: Roles, Activities, Work Product.



Models rather than Code

  • A model is a simplification (abstraction) of the reality.

  • We build models to better understand a system behavior.

  • We need to model complex systems because we are unable to understand them globally.

  • The code does not simplify the reality.

Best Practices

  • Develop software iteratively

  • Manage requirements

  • Use component-based architectures

  • Visually model software

  • Verify software quality

  • Control changes to software

Develop Software Iteratively

Given today’s sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations. The Rational Unified Process supports an iterative approach to development that addresses the highest risk items at every stage in the lifecycle, significantly reducing a project’s risk profile. This iterative approach helps you attack risk through demonstrable progress frequent, executable releases that enable continuous end user involvement and feedback. Because each iteration ends with an executable release, the development team stays focused on producing results, and frequent status checks help ensure that the project stays on schedule. An iterative approach also makes it easier to accommodate tactical changes in requirements, features or schedule.

Manage Requirements

The Rational Unified Process describes how to elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate business requirements. The notions of use case and scenarios proscribed in the process has proven to be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software, making it more likely that the final system fulfills the end user needs. They provide coherent and traceable threads through both the development and the delivered system.

Use Component-based Architectures

The process focuses on early development and baselining of a robust executable architecture, prior to committing resources for full-scale development. It describes how to design a resilient architecture that is flexible, accommodates change, is intuitively understandable, and promotes more effective software reuse. The Rational Unified Process supports component-based software development. Components are non-trivial modules, subsystems that fulfill a clear function. The Rational Unified Process provides a systematic approach to defining an architecture using new and existing components. These are assembled in a well-defined architecture, either ad hoc, or in a component infrastructure such as the Internet, CORBA, and COM, for which an industry of reusable components is emerging.

Visually Model Software

The process shows you how to visually model software to capture the structure and behavior of architectures and components. This allows you to hide the details and write code using “graphical building blocks.” Visual abstractions help you communicate different aspects of your software; see how the elements of the system fit together; make sure that the building blocks are consistent with your code; maintain consistency between a design and its implementation; and promote unambiguous communication. The industry- standard Unified Modeling Language (UML), created by Rational Software, is the foundation for successful visual modeling.

Verify Software Quality

Poor application performance and poor reliability are common factors which dramatically inhibit the acceptability of today’s software applications. Hence, quality should be reviewed with respect to the requirements based on reliability, functionality, application performance and system performance. The Rational Unified Process assists you in the planning, design, implementation, execution, and evaluation of these test types. Quality assessment is built into the process, in all activities, involving all participants, using objective measurements and criteria, and not treated as an afterthought or a separate activity performed by a separate group.

Control Changes to Software

The ability to manage change is making certain that each change is acceptable, and being able to track changes is essential in an environment in which change is inevitable. The process describes how to control, track and monitor changes to enable successful iterative development. It also guides you in how to establish secure workspaces for each developer by providing isolation from changes made in other workspaces and by controlling changes of all software artifacts (e.g., models, code, documents, etc.). And it brings a team together to work as a single unit by describing how to automate integration and build management.


  • Software engineering is the application of engineering principles to software development.

  • Software Systems are becoming bigger and more complex: real-time, distributed, large, critical, embedded, pervasive, dynamic, adaptive, scalable, elastic, etc.

  • Model-based software engineering uses models and concerns to allow abstraction and master the complexity of modern software.


  • [] P. Bourque and R.E. Fairley, eds., Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014;

  • [] Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of Software Engineering, 2nd edition. 2002.

  • [] Jeff Rothenberg, The Nature of Modeling, 1989.

  • [] Winston W. Royce, Managing the Development of Large Software Systems, 1970.

  • [] Barry Boehm, Spiral Development: Experience, Principles, and Refinements. Edited by Wilfred J. Hansen. Spiral Development Workshop February 9, 2000. Carnegie Mellon University.