Licence Mention Informatique – S4 13

Programmation Object& Genie Logiciel

Burkhart WolffDépartement Informatique

2012-13 L2-GL - Intro 2

Bibliographie et Weberies

UML 2.0, Martin Fowler, Campus Press, 2004

Developing Applications with Java and UML, Paul R. Reed Jr., Addison Wesley, 2002

UML 2 et les Design Patterns, G. Larman, Campus Press, 2005 UML 2 en action, P. Roques, F. Vallée, Eyrolles 2004

Paul R. Reed Jr., Addison Wesley, 2002

The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson, Addison-Wesley, 2005

Précis de Génie Logiciel, M.-C. Gaudel, B. Marre, F. Schlienger et G. Bernot, Masson, 1996

The Science of Programming, D. Gries, Springer Verlag, 1981

http://www.omg.org/gettingstarted/what_is_uml.htm http://www.eecs.ucf.edu/~leavens/JML/http://www.junit.org/

Part II.1 :

Introduction to Software Engineering

If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.

Robert X. Cringely

2012-13 L2-GL - Intro 4

Why Software Engineering ?

Why does ad-hoc software development not scale: Software becomes more and more complex and large Constraints to trustworthyness, safety, security, Growing mix of hardware and software (complexity!), Informatics is omnipresent et « diffuse »

Presence of clients, with imprecise and changing requirements, with whom we must communicate

Development in (very) large, longstanding teams nec. Software can have a long life-cycle, implying maintenance

reference documents Bad image of a company, loss of market credibility

obstacle for development

Legal constraints (Common Criteria Certification, Antri-Trust-Laws, ...)

techno logicalaspect s

society aspect s

2012-13 L2-GL - Intro 5

Software becomes more dangerous ...

Trust, safety and security of software : Transportation: railway, aircrafts, space, Control of industrial processes, nuclear, military, … Tele-surgery, medical imaging and instruments … Communication infrastructure, e-commerce, ...

Economics: costs and delay of development of reliable software, reflecting customer needs, accepted by stakeholders and the public…

Techniques and tools evolve :in 20 years: factor 100 (?) higher la density components

… local errors accumulate, so more large and complex systems require more quality in local components !

Technological aspects, methodologies, management, as in other industrial activities ...

2012-13 L2-GL - Intro 6

Software becomes BIG ...

Windows 7: Team of 1200 programmers only 5 Bln € development costs (estimation) Revenues : 20 Bln € (estimation) ! Legal Bindings: 15 -20 years ! Problems:

Legal Battle about Windows Server 98;led to a settlement with the EU costing 700 mio € !

Technological aspects, methodologies, management, as in other industrial activities ...

That is what Software Engineering is talking about !

2012-13 L2-GL - Intro 7

Famous Software Desasters

Mariner 1 (Venus, 1962) : wrong transcription of a formula erratic corrections of the trajectory (crash during flight)

1981 : Delay of first start of spaceship « voyager »(problème de synchronisation des résultats de calculateurs redondants)

1985 - 1987 : Overdosis in a radiotherapy system (Therac-25, 5 dead). Item 2007 1992 : Crash of planning and tracking system of london ambulance calls 1996 : Crash of flight 501 of Ariane 5 (« validation » problem of the systeme) Juillet 1997 : Blocking of names of the domaine .com Septembre 1999 : Loss of Mars Climate Orbiter after 9 months of flight.

Costs : 120 M$ (confusion of unities between two different components) 2004 : defect of reservation system for SNCF tickets, 2004 : denial of access for the Bouygues Télécom and France Telecom networks 2008 : Toll-Collect Desaster (Allemagne) 2010 : NPfIT desaster in Great Britan (Loss: 12 Billion British Pound)

2012-13 L2-GL - Intro 8

Call-backs ? (interrogations)

Example of a call-back: Speed Control Renault Laguna (2005)

Is it an informatics-bug or not ?Is it a problem of interaction hardware/software/environment ?

Even if no « bug », no-one is completely convinced !

need to justify/control the « proces of construction» (Common Criteria) need to guarantee quality of tests of final product

Ubiquity of software !

Peugeot 607 = 2 Mb of embedded software, 40 processors, 20 % total cost

«Needs» (ABS, ESP, electronic pedals, sensors, …) Interaction of services difficult to control. Trafic/Interferences on busses … Validation of the systeme with all combinations of variants/options ?

Future automatisation of métro lines (RATP – ligne 1: 2010) What validation process ? Responsabilities: RATP or industrial partners (SIEMENS) Who authorizes finally the service ? With what prospected reliability ?

2012-13 L2-GL - Intro 9

Some figures

Size of software systems ? Windows « 90 » : 10 M. LOC source, Win2000: 30 M. LOC Core RedHat 7.1 (2002) : ~2.4 M. LOC, XWindow ~1.8 M.,

Space shuttle (and its environment) : ~50 MLOC Colombus Station (abandoned) : 980 MLOC compiled ??

Development costs ? Proportion of «Coding» : 15 - 20 %

Coding is more and more automated (CASE-tools, MDA) Proportion of Validation and Verification ? ~ 40% Proportion of Specification and Design ? ~ 40%

Estimation of « Necessary Manpower » (Boehm)

Man-Month = 3,5 * C1,2

(«Complexity C» very approximative, but clearly Man-Months grow non-linear! see http://www.compapp.dcu.ie/~renaat/ca421/LWu1.html for an overview on cost estimation methods ...)

2012-13 L2-GL - Intro 10

Des chiffres sur les « défauts logiciels »

60%15%

25%

Algorithms

Code

Specification anddesign

83%

8%9%

Specification and design

Algorithms

Code

Distribution of faults

Distribution of costs of faults

Source: F. Fichot, Cours de Conduite de Projets, IFIPS

2012-13 L2-GL - Intro 11

Particularities of software

Complexity strongly depends on applications : Synchronisation, repartition of processes (concurrency, true parallelism) Nature or volume of data, existence of algorithmic problems, Interdependency of hardware and software, Performance or « real-time réponse » (in reactive systems)

Apparently, software is easy to modify (versatility) but impacts/consequences of modifications are difficult to predict

Difficult prediction on fault-rates and mesurement of « quality»: small changes may have the most dramatic consequences

(in contrast to physics: small changes have usually small impacts) no way to predict the « probability » of impacts/consequences

Weak visibility of development processes for clients, but also management!

Importance of the phases (requirements) analysis, design, validation Need for an «industrial» development process, i.e. s.th. tracable Need for document-orientation of the development (at least in classic S.E.)

2012-13 L2-GL - Intro 12

Different aspects of Software Engineering

MANAGEMENT PROCESSDevelopment Mgt. Risc Management

ConfigurationManagement

« PeopleWare »(Staff, Sub-contractors)

PROCESSUS QUALITE

QUALITYASSURANCE

QUALITYCONTROL

METRICS

FEASIBILITY STUDIES (BEFORE PROJET)

SPECIFICATION & DESIGN

PRODUCTION

INTEGRATION & VALIDATION

EXPLOITATION

TECHNICAL PROCESS

Development

Maintenance & Support

2012-13 L2-GL - Intro 13

Organisational aspects: the conduct of projets

Planning, organisation, problem detection, reaction !

Estimation of costs and delays Planning (e.g. diagrams like PERT or GANTT charts) Follow-ups (Suivi): management of staff, des échéances et

fournitures à remettre au client Risk Management (prevention or corrections) Configuration management (versioning of documents, sources,

and tests as well as keeping track of their links and dependencies) Document management associted to different phases of software

production (part of configuration management!)…

and all that respecting quality norms ... (document types, circuits de validation, règles de nommage)

2012-13 L2-GL - Intro 14

Development Phases vs. Documents

A Sequence of increasingly precise and executable documents, Informal Requirement Specification (Cahier des charges informel) -> model(s) of the analyse (captures / formalizes the requirements) -> model(s) of design (captures interfaces of the implementation) -> code (implementation) -> validation et vérification protocols, documentation

Development in «phases» Each phase of the development process ends by producing (versions of) these

documents verified and validated before transition to next phase.

Each phase contributes to a number of «activities», which are pervasive Production of Documentation (user manuals(manuel utilisateur), reference manuals

(manuel de référence), installation manual (manuel d’installation),…): extended at different phases.

Activity of Validation/Verification

2012-13 L2-GL - Intro 15

Activities and Phases (1)

Phase Requirements Analysis (capture des besoins)Study of the environment and the system application context, analysis of

requirements and constraints (performance, ergonomics, portability,…)Output: requirement specification (cahier des charges)

Phase specification analysis (analyse et spécification)Description of what the system should do (and not how)Output: analysis models

Phase architectural design (conception architecturale) Decomposition of the software into «components» Conception of an integration proceeding and order of the different components

(increments); conception of related tests for integration Phase (detailed) design (conception détaillée)

Choice of algorithms, data structures,definition of interfaces and classes to describe conception of tests which verify or validate the implementation

Output: design documents, possibly code-interfaces, code fragments,pseudo-code, mock-ups, prototypes.

2012-13 L2-GL - Intro 16

Activities and Phases (2)

Phase coding

Phase unit test Controled execution of tests of each procedure/methodif they behave as defined

Phase integration and intégration tests Execution of test scenarios conceived in the analysis(Emphasis on high-level system behaviour)

Phase Acceptance Tests and System test (by the producer) Test global tests under real conditions (platforms, under stress, mesuring performance, ...)

Phase Deployment (Recette; par le client) Tests, inspection of delivered documents, possibly véerification of relevant quality norms

2012-13 L2-GL - Intro 17

Beyond phases …

Importance of documentations :stake-holders: users, admins, mainteners, providers, general public …

Distinction of two complementary activities :Validation: check that the right system is built

(what is needed by the client; «external» coherence)

Verification: check if the system has been built right (what has been specified ? «internal» coherence)

Importance of tracability ! (extremely important in open-source devs!) Document and archive the choices beend done ! (mailings, versions,...) Enforce the coherence between the models and the product

(environments must be «forward/reverse engineered»)

Importance of archiving, version and configuration management (versioning documents, «building» particular configurations) Guarante of document coherence wrt. to different versions Guarante of reconstructibility of particular versions (can you

re-build version 1.6.4.7.4. and observe if bug XXX occurs in it ?)

2012-13 L2-GL - Intro 18

And after deployment ?

Maintenance is painful and expensive ! Correction maintenance: correction of critical bugs Adaptive maintenance: new OS version, new hardware, new

performance problems, Y2K !!! Evolutionary maintenance: integrating new functionality

Even worse: it may be nbecessary to maintain different versions/configurations of systems simultaneously !

Maintenance costs: 2 - 4 times more than development ?

Need for regression tests from one version to another: Requires precise test goal descriptions

(input, expected output and execution context + requirement trancing in tests)

Need for test automation (execution, metrics, archiving) and, therefore, tool-chains

2012-13 L2-GL - Intro 19

Process development models …

Organisation of the phases associated documents

Structuring of the process and improve its visibility,

Development of Tool Support for a concrete process (RUP, V Model, Spiral, Méthodes Agiles, Xtreme programming, ...)

Produce templates for associated documents Minimise risc of „procedural“ errors the software process Support for non-linear development (back-tracks)

(modification of requirements, correction of design errors, modification of technical environment (platform), …) ?

Are there methodologies adapted to the general tendancies ?

Distributed aspects in informatics, Global trends like virtualization, Need for interoperability (SOAP, WebServices, XML, …) Component-based approches (reuse, « COTS », libraries, frameworks) Separation of business logic (logique métier) / technical services

(Norms like spécifications J2EE et .Net, WebServices)

2012-13 L2-GL - Intro 20

The V-Model (Le Modèle en V) …

Historically best known, and pretty pedagogical ! The descending flow produit les guides pour les phases montantes Pédagogique, mais pas toujours adapté…(global, linéaire)

Coding

Requirements Engineering

Specification

Architectural Design

Detailed Design

Installation, Systeme Tests

Acceptance Tests

Integration & Integration Tests

Unit Tests

Principle temporal dependenciesPotential Back-flowPlans and Document Flow

2012-13 L2-GL - Intro 21

The V-Model (Le Modèle en V) …

Codage

Analyse des besoins, Faisabilité

Spécification

Conception Architecturale

Conception Détaillée

Installation, Test Système

Test d’acceptation

Intégration

Tests unitaires

Flux temporel principalRetour en arrière éventuelPlans et Documents

Historically best known, and pretty pedagogical ! The descending flow produit les guides pour les phases montantes Pédagogique, mais pas toujours adapté…(global, linéaire)

2012-13 L2-GL - Intro 22

Other process development models

Iteration Model

Spiral Model (Boehm)

Principes généraux: Diminuer les risques, meilleure visibilité, retours utilisateur rapides,

Intégration et validation progressive des fonctionnalités

Exigences

Spécification

ConceptionImplémentation

Prototype

Version 1Version 2

Révision Analyse de risques

Intégration et deploiement

Spécification

Incrément n

Validation

2012-13 L2-GL - Intro 23

Development process models en vogue

Xtreme Programming (and other méthodes agiles such as SCRUM) http://www.en.wikipedia.org/wiki/Extreme_programming Development driven by tests, « client »-centered Permanent restructuring of code, coding in «teams of two» Permanent presence of the client

Rational Unified Process (RUP): iterative, using UML.http://www.idbconsulting.com/francais/incIBMRationalRUP.cfmhttp://en.wikipedia.org/wiki/Rational_Unified_Process

Architecture MDA (http://www.omg.org/mda/)

Approach based on the transformation of UML models

2012-13 L2-GL - Intro 24

Summary

Programming in the small is not enough!When constructing systems with more than 50000 LOC's,the development process must be structured: into phases establishing a „bureaucratic“ decumentation process tool-chains for code-generation, testing, verification,

documentation generation. the work of 1000 of collaborators must be organized ... and financed

There is no silver-bullet, not ONE particular SE Development Process, rather: every process model can be found in industry, from V-Model (large projects with public/military clients) ...

... to Methodes Agiles and Xtreme Programming (google)

... to MDA (e.g. SAP)