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)