Brief Introduction to Software Engineering

Gerson SunyéUniversity of Nantes

gerson.sunye@univ-nantes.frhttp://sunye.free.fr

1

Agenda1. Software Engineering Definition

2. Modern Software Complexity

3. The Software Industry Today

4. Software Modeling

5. Software Development Process

6. Conclusion2

Acknowledgements• Jean-Marc Jézéquel, Benoît Combemale, Olivier Barais.

• Université de Rennes 1

• Yves Le Traon

• Université du Luxembourg

• Jean-Marie Mottu, Gilles Ardourel

• Université de Nantes3

Goals

• To understand the complexity of modern software systems.

• To have a preview of the recommended solution:

• Separation of concerns.

• Technical continuity: from models to programs.

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

4

Definition

5

A 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 an detailed algorithm for computing Bernoulli’s numbers with the analytical engine.

6

7

First Computer Programmer

• Ada translated well known formulae into an implementable algorithm.

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

8

Software Engineering Definition

«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]

9

Software Engineering Approach

AD Software Engineering Approach

Software Engineering Approach

SoftwareRequirement

UML Activity: systematic, disciplined, and quantifiable approach

10

Software Engineering Activities [Meyer]

• Describe: requirements, design, specification, documentation...

• Implement: modeling, programming

• Assess: testing and other V&V techniques

• Manage: plans, schedules, communication, reviews

• Operate: deployment, installation...

11

Requirement Software

Describe Assess

Operate

Software Engineering Approach

ManageImplement

A Systematic Approach

An approach that follows a method, with rigor and precision

12

A Disciplined Approach

An approach that shows a controlled form of behavior

13

A Quantifiable Approach

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

14

Modern Software Complexity

15

Modern Software Complexity

16

Critical, Real-Time, Embedded

17

Reusable, Durable

18

Elasticity

FarmVille 1 million users in 2 months!

Quicken took 10 years to reach this amount !

19

Scalability

20

Long Term Availability

• 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.

• From the OPEES ITEA2 project (2009-12).

21

Distributed Data Processing

http://googletesting.blogspot.com/search/label/Copeland Source:

• Google.com: 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

22

Large-Scale Development

• Google.com: 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

23

Ubiquity

• Autonomic Computing• Cloud Computing• SaaS, IoS, IoT

24

The Software Industry Today

25

The Software Industry Today

• New actors

• Separation of concerns

• Modeling

26

Actor Evolution

Scientist

Programmer

User

Software Engineers

Users

Time27

Actors at Present Time

end userscomponent developers

architects

assemblers

standardization organization

tool vendors

application testers

site administrators

component testers

middleware providers

28

Several Actors, Different Concerns

• Different:

• Concerns.

• Jobs and tasks.

• Competences.

• Tools.

• Software artifacts.29

Residents

Plumbers

Electricians

Architects

LandscapeArchitects

Cadastre

Insurers

Firefighters

Notaries

PropertyDevelopers

System

Separation of Concerns

30

OwnerPlumber

Electrician

BricklayerArchitect

Cadastre

System

Separation of Concerns

31

In Short

• Issues:

• Growing software complexity.

• Separation of concerns

• New software actors

• Requirement diversity

• Heterogeneous platforms

• Permanent evolution

• Etc.

• Question: Is using code to represent complex systems the correct solution?

32

Software Modeling

33

Different Models of a System• Models for :

• Firefighters• Property developers• Residents• Plumbers• Electricians• Landscape architects• Architects• Notaries• Insurers• Cadastre

System

34

Different Models of a System

Design Model

Code Model

Deployment

Fault tolerance

Security

Functional behaviorUse case model

PlatformModel

«subsystem»ATM

Withdraw

Deposit

Print Receipt

Check Balance

Login

Client

0..1

1

1

1

0..1

0..1

35

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).

The world

Modeling space

Is re

pres

ente

d by

36

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.37

Why 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.

Jeff Rothenberg, «The Nature of Modeling», 1989.38

Why Modeling?• To think:

• Abstract representation, Separation of concerns.

• To communicate:

• Graphical representation, document generation.

• To automate the development:

• Code generation, Quality evaluation, Migration

• To validate

• Model validation and verification: simulation, model-checking, model-based testing.

39

Model and Reality in Software

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

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

• Software Models: from contemplative to productive

[Magritte]

40

Modeling in Software Engineering• From software design to requirement specification.

• business modeling, testing, runtime adaptation, maintenance, quality assessment, code generation, etc.

• And also documentation, transformation, evolution, migration.

• Any other suggestion?41

42

design, documentation

analysis ... detailed design

requirement management,

systems engineering ...

V&V, (code, test) generation.

... DSML, transformation/composition ... maintenance ...

runtime.

State of the practice in Industry

AnalysisDesignDevelopmentTestDeployment

RuntimeMaintenance

?

The UML

• The Unified Modeling Language

• Several diagrams (concerns), one model.

• Several actors and processes, one syntax.

43

UML: one model, 4 main dimensions, multiple views

Device

start()stop()

Operator<<Actor>>

0..*1

controls

Static

: Operator

: Device

start( )

stop( )

Dynamic

Usage

: Operator

ControllingSite RemoteSite

TCP/IP : Device

Deployment

: Operator

44

The X diagrams of UML• Modeling along 4 main viewpoints:

• Static Aspect (Who?)

• Describes objects and their relationships (Class & Object Diagrams)

• Structuring with packages

• User view (What?)

• Use cases Diagram

• Dynamic Aspects (When?)

• Sequence Diagram

• Collaboration Diagram

• State Diagram

• Activity Diagram

• Deployment Aspects (Where?)

• Component Diagram & deployment diagram

45

Example: Modeling a simplified GPS device

• Gets position, heading and speed by receiving signals from a set of satellites

• Notion of Estimated Position Error (EPE): receives from more satellites to reduce EPE.

• User may choose a trade-off between EPE & saving power

• Best effort mode

• Best route (adapt to speed/variations in heading)

• Power Saving

(Case Study borrowed from N. Plouzeau, K. Macedo, and JP. Thibault)46

Use Case Diagram

47

Class diagramknows

readsFrom

route

48

Sequence Diagram: Configuring Decoders

49

Sequence Diagram: Interrupt Driven Architecture

Many more sequence diagrams needed…50

Modeling a (simplified) GPS device

• Targeting multiple products with the same (business) model

• Hand held autonomous device

• Plug-in device for Smart Phone

• Plug-in device for laptop (PCMCIA/USB)

• May need to change part of the software after deployment

• We choose a component based delivery of the software51

Component Diagram

«component»Decoder

DecoderI

DataIDataI

ReceiverI

52

Component DiagramInstance Level

53

Software Development Processes

54

Software Engineering Activities

• Domain/Business analysis: understanding the user environment.

• Requirement specification: specifying the user needs.

• Software design: describing the foreseen solution.

• Implementation: solution coding, realization.

• Validation/Verification: evaluation of the solution.

• Deployment: distribution, delivery.

• Maintenance: resolving errors and evolving the solution according to new needs.

55

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

• Different processes, all involving (at least):

1. Specification: what the system should do.

2. Design: how the system should be organized.

3. Implementation: realization of the system as a program.

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

5. Evolution: changes according to user new needs.

56

Software Process Models• Abstract representation of a process.

• Examples:

1. Waterfall model.

2. Spiral model.

3. Iterative and incremental model.57

The Waterfall ModelI

|

I '

I I

:i] .

~ '

l l

e ~$

~ ~

i

n |~

~ u

8(

I I

.. I

s""

O0 0@'

0 O° ~ d

p@@@@@@~S.

I w

R

I.L.

338

[Royce, 1970]58

Issues• 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.

59

The Spiral Development Model

2 CMU/SEI-2000-SR-008

applications discussed in [Bernstein 00] and [DeMillo 00] use a complementary best practiceas their anchor point milestones: the AT&T/Lucent/Telcordia Architecture Review Board pro-cess [AT&T 93]. Xerox’s Time-to-Market process uses the anchor point milestones as hard-ware-software synchronization points for its printer business line [Hantos 00].

Several successful large aerospace spiral projects were also discussed. The best documentedof these is the CCPDS-R project discussed in [Royce 98]. Its Ada Process Model was thepredecessor of the Rational Unified Process and USC MBASE approach, which have bothbeen used on a number of successful spiral projects [Jacobson 99, Boehm 98], as has the SPCEvolutionary Spiral Process [SPC 94]. Further successful large aerospace spiral projectswere presented by SAIC and TRW [Kitaoka 00, Bostelaar 00].

RQTS PLANLIFE CYCLE PLAN

CONCEPT OFOPERATION

EMULATIONS MODELS BENCHMARKS

REVIEW

COMMITMENTPARTITION

RISK ANALYSIS

RISKANAL.

RISK ANALYSIS

RISK ANALYSIS

PROTO-TYPE1

PROTOTYPE3

OPERATIONALPROTOTYPE

EVALUATEALTERNATIVESIDENTIFY,RESOLVE RISKS

PROGRESSTHROUGHSTEPS

CUMMULATIVECOST

DETERMINEOBJECTIVES,ALTERNATIVES,CONSTRAINTS

DEVELOP-MENT PLAN

INTEGRATIONAND TEST

PLANDESIGN VALIDATIONAND VERIFICATION

REQUIREMENTSVALIDATION

SOFTWAREPRODUCTDESIGN

DEVELOP, VERIFYNEXT LEVEL PRODUCT

SOFTWARERQTS

IMPLEMEN-TATION

ACCEPT-ANCE TEST

INTEGRA-TION AND

TEST

UNITTEST

CODE

DETAILEDDESIGN

PROTOTYPE2

PLAN NEXTPHASES

Figure 1: Original Diagram of Spiral Development[Bohem 1988, 2000]60

Issues• 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.)

61

Iterative and Incremental Model

62

Phases1. 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.

Inception Elaboration Construction Transition

Time63

Iterations

Preliminary Iteration

Architect. Iteration

Architect. Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

Transition Iteration

Transition Iteration

Inception Elaboration Construction Transition

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

64

Phases and IterationsExamples

(No. of Iterations)

Inception Elaboration Construction Transition Project Length

Iteration Length

e-business 0.2 1 3 1 3-4 months 2-3 weeks

infrastructure 1 3 3 2 9-12 months 5-7 weeks

65

Best Practices• Develop software iteratively

• Manage requirements

• Use component-based architectures

• Visually model software

• Verify software quality

• Control changes to software66

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.

Functional Analyst Interface Designer Technical Designer

DefineRequirements

DesignProcess Model

UserRequirements

User WorkProcesses

Draft UserInterface

Refine UserInterface

User InterfaceDraft

User Interfacerefined

Define Techn.Requierements

BuildApplication

https://code.google.com/p/spem4omnigraffle/67

Software Modeling and the Software Development Process

• The Unified Modeling Language (and other languages) may be applied on different activities.

• One syntax, different semantics:

• Reduces the learning curve, but

• Increases misinterpretation and confusion.68

Requirements Problem Analysis Design Implementation Validation Deployment

Use Case ++ ++

Classes + ++ ++ ++ ++

Components ++ + + +

Iteration + ++ + + ++

States + ++ ++ + +

Activities + ++ ++ ++ +

Deployment + + + ++69

Conclusion

70

Why do projects fail?• Unrealistic or unarticulated project

goals• Inaccurate estimation of needed

resources• Badly defined system requirements• Poor reporting of the project's status• Unmanaged risks• Poor communication among

customers, developers, and users

• Use of immature technology• Inability to handle the project's

complexity• Sloppy development practices• Poor project management• Stakeholder politics• Commercial pressures

71

72

Conclusion• Software Systems are becoming bigger and more complex: real-

time, distributed, critical, embedded, pervasive, dynamic, adaptive, scalable, elastic, etc.

• New actors on software development: tools vendors, middleware providers, testers, etc.

• Software engineering is more than writing code: different activities, languages, processes.

• Modeling allows developers to master complexity.73

References

• “Software Engineering”, Ian Somerville. Addison-Wesley. 9th edition. 2009.

• “Rational Unified Process—Best Practices for Software Development Teams”. Rational Software White Paper.

• “Rational Unified Process—An Introduction”. Philippe Kruchten. Addison-Wesley, 1999.

• Boehm, B. (n.d.). Spiral Development: Experience, Principles, and Refinements. Spiral Development Workshop. Retrieved from http://www.sei.cmu.edu/reports/00sr008.pdf

74