Software Engineering / Génie Logiciel Samuel KORTAS
Janvier-Février 2003
But du cours ¾
Initier aux méthodes de gestion du logiciel
¾ Théorie (8h de cours) Historique Cycles de Developpement ¾ Tests !!! ¾ règles de codage ¾ UML ¾ methode CRC ¾ Pratique : projet suivi ¾ ¾
¾
Présenter :
¾ l’Assurance Qualité ¾
Apprendre à utiliser
¾ Un outil de Gestion de configuration ¾ Rational Rose Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 2
1
Sensibilisation aux projets logiciels ➀ Les projets logiciels ☞ ☞ ☞ ☞
la réalité en chiffres les cycles de vie les problèmes la qualité logicielle
② Les errements de la pratique ☞ bonnes habitudes ☞ erreurs classiques
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 3
Software Engineering / Génie Logiciel 1 . Pourquoi ?
Janvier-Février 2002
06/02/2003
2
Un peu d’histoire… •
Boulier, Machine de Pascal, Machine de Turing, Etudiants dans un Stade, ENIAC • Pas de logiciels, mais un utilisateur ou un chef d’orchestre • Une opération, pas de mémoire
•
Années 50 et 60 : programmation empirique • Production « artisanale » de logiciels scientifiques • Royaume des « codeurs » et des « gourous »
•
Fin des années 60 : « la crise du logiciel » • Difficulté d’écrire de grands programmes • Difficulté de les utiliser, de les faire évoluer • De nombreux projets échouent…..
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 5
La crise… s’éternise! Etude du gouvernement américain en 1979
Payés mais jamais livrés Livrés mais jamais utilisés Abandonnés ou refaits Utilisés après modifications Utilisés tel quel
Samuel Kortas – Janvier/Février 2003
06/02/2003
$ 3.2 M $ 2.0 M $ 1.3 M $ 0.2 M $ 0.1 M
47% 28% 20% 03% 02%
Software Engineering
Page : 6
3
Mais pourquoi? …. Complexité des Logiciels
Taille : des millions de lignes de code, des milliers de module
Windows NT = 15 millions de ligne C++ Linux 2.4.0 = 3 millions de ligne C/C++/asm --> Dans Excel 97 est caché un simulateur de vol en 3D !!
Durée de vie : 3 mois à 20 ans… à 50 ans
Un serveur web de e-commerce doit etre mis en place au plus tard avant… hier! --> Time to market de + en + cours En 1998, on rappelle les programmeurs COBOL!
Tailles des équipes : 1 à 50… à 1000 ingénieurs logiciels
plusieurs acteurs : Constructeurs, SSII, Utilisateurs finaux et clients
équipes réparties autour de la planète
Coût de développement et de maintenance élevés :
de centaine de milliers de francs à des milliards!
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 7
Niveau (approximatif) de langage Assembleur
1
C
2.5
Fortran 77 Pascal Ada 83
3 3.5 4.5
C++ Visual Basic 3
6.5 10
Perl
15
Tableur Excel
on développe à peu près le même nombre de lignes/mois (la productivité individuelle variant néanmoins de 1 à 10) donc développement plus ou moins rapide mais dépend de l’utilisation
~50
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 8
4
Qu ’est ce qu ’un logiciel? Computer Programs and the associated documentation required to develop, upgrade and maintain them [ Boehm 76]
Logiciel ≠ Code !!!
Et quoi d ’autre?
Binaires, librairies, manuels utilisateurs spécifications, dossier de conception détaillée et général plans de tests, résultats de tests Savoir faire, Stratégie de maintenance, procédures qualités
Savoir programmer : un détail !!!
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 9
Charges Des Différents postes Poste
Cycle de développement
Cycle de vie
Spécifications Etude du Pb Analyse Besoins Définir Actions & Données
20%
8%
Conception/Développement Décomposer le projet Coder Documenter
30%
12%
Tests/Validation Vérifier les fonctions Tester les perf Optimiser
50%
20%
Operation/Maintenance Formation Mise en place Maintenance corrective Evolution/Portage
Samuel Kortas – Janvier/Février 2003
06/02/2003
60%
Software Engineering
Page : 10
5
De Codeur à Ingénieur Logiciel!
1968 : 1ére Conférence de Genie Logiciel/Software Engineering
Génie Logiciel = Ingénierie + Logiciel idée : organiser la production des logiciels Contrôle des coûts, contrôle de la qualité, … meilleure Estimation, prévision et gestion des risques
changement de terminologie :
1950 : codeur 1970 : analyste-programmeur 1980 : ingénieur logiciel
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 11
Définition Ingénierie "Creating cost-effective solutions … ... to practical problems … ... by applying scientific knowledge » [Shaw90]
ressources limitées (e.g. temps, argent, ...) solution utile résolvant un problème concret le problème n'est pas inventé par l'ingénieur rigueur dans la résolution du problème prédictibilité du résultat
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 12
6
En pratique...
résolution de problèmes complexes résolution de problèmes récurrents catalogue de solutions pour un type de problèmes solutions sûres et éprouvées
Et…..
"There are three ways to loose money: women, gambling and engineers. The two former are the more comfortable ones, the latter the most certain » - bankier Rothschild -
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 13
Rotschild avait raison (1/2) Ariane 5: mauvaise couverture de test / OUT OF RANGE = $370 000 000
AT&T, 1992: interruption du service téléphonie pendant 5 heures à l'est des états unis.
Aéroport de Denver, 1994: logiciel de suivi des bagages, coût 3 millards de $, retard de 18 mois.
Oslo, Sept. 1993 : erreur dans le système de comptage des votes du parlement => nouvelles éléctions
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 14
7
Rotschild avait raison (2/2)
Etude récente effectuée aux états unis [Standish Group 1995]
31% des projets non achevés ou abandonnés à la livraison 53% des projets dépassent les ressources allouées 16% des projets se déroulent comme prévu
Faut-il retourner tenter sa chance et sa fortune au jeu et en amour
?
Peut-être pas encore!
Valeur du logiciel aux états unis
1980 : 2% of PNB 1985 : 8% of PNB 1990 : 13% of PNB
Augmentation de 12% par an
Une amélioration de rendement même faible peut avoir des répercutions trés importantes Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 15
Questions ?
? Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 16
8
Software Engineering / Génie Logiciel 2. Comment ?
Janvier-Février 2002
2. Comment ? General Cycle / Actors and Steps
Janvier-Février 2002
06/02/2003
9
Software Cycle : Sample [1/2] End User
Designer
clear definition of needs Proposal/planning GO/NOGO Architecture Architecture Validation Specifications Specifications Validation Development Samuel Kortas – Janvier/Février 2003
Software Engineering
Page : 19
Software Cycle : Sample [2/2] End User
Designer Test Plan Definition
Test Plan Validation Bugs Correction Validation Test Plan Bug Revue Bug Report
Delivery Acceptance Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 20
10
2. Comment ? Different Cycles
Janvier-Février 2002
Différent cycles
Shoot and Try Simple Cascade Modified Cascade
with overlap with sub projects with risk management Spiral
Evolutive Prototyping Step by Step Delivery Evolutive Delivery Conception regarding planning Conception regarding tools
Specification, conception, test steps are always part of the cycle ½ Cycle depends on project!
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 22
11
Time to Market – “Classical” Development Process? Product Lifecycle
Problems: •Time To Market •High Costs •Meeting deadlines •Visibility
Requirements Specification
Design Implementation Test Operation & Maintenance TIME Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 23
V Cycle • Good Quality, but expensive and long • No Results before the end of the cycle Operation & Maintenance
Requirements
Validation & Maintenance
Specification
Architecture Design
Integration Tests
Detailled Design & specification
TIME Samuel Kortas – Janvier/Février 2003
06/02/2003
Unitary Tests
Implementation
Software Engineering
Page : 24
12
Incremental Lifecycle Product Lifecycle Requirements Specification
Design Implementation Test Operation & Maintenance TIME Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 25
« Spiral » Life Cycle Design a Little, Code a Little
Product Lifecycle Requirements Specification
Design Implementation Test Operation & Maintenance TIME Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 26
13
Modèle en spirale
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 27
Comparaison des cycles Capacité du cycle Spécifications mal comprises
-1
-1
+1
+1
Architecture mal comprise
-1
-1
+1
-1/0 0
Fiabilité (taux de défauts)
-1
+1
+1
-1/0
+1
+1
+1
Gestion des risques
-1
-1
+1
0
Respect du planning
-1
0
0
-1
Temps d’utilisation efficace
+1
-1
0
0
Possibilités de modifications
-1/+1
-1
0
+1
Indice d’avancement (client)
0
-1
+1
+1
Indice d’avancement (projet)
-1
0
+1
0
Faible compétence
+1
0
0
-1
Capacité d’extension en taille
Samuel Kortas – Janvier/Février 2003
06/02/2003
Programmer Cascade Spirale Prototypage -corriger évolutif
Software Engineering
Page : 28
14
Sotware LifeCycle 1. Requirements / Analyse des Besoins
For this part...
Slides taken from un cours du DESS Compétence Complémentaire en Informatique
« Analyse des Besoins » du cours de Génie Logiciel de JeanMarie Favre, Maitre de Conférence à l'Universite Joseph Fourier (Université Grenoble 1)
http://www-adele.imag.fr/~jmfavre/
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 30
15
Problématique
Beaucoup de systèmes informatiques ne sont jamais utilisés car ils ne correspondent pas aux besoins du client ! – « Ce n ’est pas ce que je voulais… » – « Ca ne sert à rien... » – « Comment je fais ça ?» – « Ce n’est pas le bon résultat ! » – « Je vous avais dis que je voulais ça ! » – ...
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 31
Causes
Le client ne sait pas ce qu’il veut Le client ne sait pas exprimer ce qu’il veut L’informaticien ne comprend pas client Le client ne comprend pas l’informaticien Ce que le client veut n’est pas ce qu’il voulait
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 32
16
Des difficultés réelles!
Difficultés de communiquer
difficulté d’être précis, cohérent, complet, ... différences de culture : z z
les utilisateurs ne sont pas informaticiens… les informaticiens ne connaissent pas le domaine…
Complexité du problème
problème non formalisé problème complexe
Évolutivité
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 33
Analyse des besoins
L ’une des étapes les plus importantes
étape déterminante pour la suite aspects contractuels
• L ’une des étapes les plus difficiles
différents intervenants :
le client, les utilisateurs, les développeurs…
le problème n’est pas encore formalisé
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 34
17
Différents Roles
Identifier les différents intervenants : – Le(s) client(s) – Les utilisateurs – Le maître d’œuvre – Les développeurs – ...
Identifier le rôle de chacun
Éventuellement associer des priorités
Le client est roi (mais quand même)
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 35
Différentes étapes
Capture des besoins
collecte des informations : interviews, lecture de doc. chercher à comprendre : (1) le domaine (2) le problème
Définition des besoins
restitution dans un langage compréhensible par le client identification, structuration, définition d'un dictionnaire
Spécification des besoins
spécification détaillée des besoins, plus formel utile pour le client, mais aussi pour les développeurs
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 36
18
Capture des besoins - (1) Collecter
Objectifs
comprendre le domaine comprendre le problème
(1) Collecter le maximum d ’informations
Lecture des documents fournis Interviews du client, des utilisateurs, … Réunions de travail Collecter des exemples pour valider Étudier les systèmes existants le cas échéant
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 37
Capture des besoins - (2) Intéragir
(2) Réagir et être actif !
Établir la liste des documents consultés, les classer Élaborer une liste de questions précises z z
les numéroter, les dater, … faire référence aux documents concernés
Écrire un ou plusieurs documents et les diffuser Provoquer les réunions et les mener z z z
établir l’ordre du jour prendre des notes faire systématiquement des comptes rendus écrits
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 38
19
Définition des besoins
Restituer les informations sous forme synthétique
Ce qui n’est pas écrit n’existe pas !
Préciser les besoins, pas la solution
Préciser ce que doit faire le système
et aussi ce qu’il n ’est pas sensé faire. mais surtout pas comment il doit le faire.
Etablir des priorités
Arriver à un consensus avec le client
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 39
Different Types de besoins
Besoins fonctionnels
à quoi sert le système ce que doit faire le système, les fonctions utiles
• Besoins non fonctionnels
performance, sûreté, confidentialité, portabilité, etc. chercher des critères mesurables
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 40
20
Conseils
Les besoins doivent être compris par tous
utiliser la langue naturelle utiliser des schémas si nécessaire
tout schéma doit être commenté
tout schéma doit toujours comporter une légende
Structurer le document
suivre un plan standard si disponible numéroter les sections, références, index, …
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 41
Langue Naturelle... mais technique
Faire des phrases courtes
Eviter le conditionnel, le futur
Eviter les termes ambigus ou subjectifs, ...
Parler en termes de rôles plutôt que de personnes
Numéroter les paragraphes si nécessaire
Utilisation de références précises
Elaborer un dictionnaire
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 42
21
Spéfication des besoins
Interface entre le client et les développeurs
doit être compris par les deux défini dans le détail ce qui doit être réalisé doit être précis car contractuel
Utilisation de techniques semi-formelles
e.g. diagrammes de cas d'utilisation UML e.g. diagrammes de classes UML
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
Software Engineering
Page : 43
Résumé
L'analyse des besoins est une étape essentielle
Origine de toute activité de développement
Problème de communication client / informaticiens
Capture des besoins : collecter l'information
Définition des besoins : restituer les besoins
Spécification des besoins : définir précisément
Des techniques informelles mais utiles !
Besoin également de techniques plus précises…
Jean-Marie (UJF Grenoble) Samuel Kortas –Favre Janvier/Février 2003
06/02/2003
Software Engineering
Page : 44
22
Travaux Dirigés n°1 Software Engineering / Génie Logiciel A vous! Janvier-Février 2003
Sotware LifeCycle 2. Architecture
06/02/2003
23
Architecture Design ¾
The architecture goals are to design a software that is :
¾ Portable : multiple OS, multiple targets ¾ Reusable : modularity ¾
These features are important to design an evolutionary and maintainable software.
¾
Arhitecture Design Process :
¾ List of features supported ¾ Components and objects definition ¾ Portability and reusability constraints
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 47
Architecture Design Portability Tests Cost Performances
List of features
Components Approach
Samuel Kortas – Janvier/Février 2003
06/02/2003
Components Interaction Approach
Implementation
Software Engineering
Page : 48
24
Sotware LifeCycle 3. Specifications
Specifications ¾
The specifications are a base for the software development.
¾
All the elements needed during the development have to be detailled in the specifications.
¾
The specifications have to be reviewed and validated before the beginning of the development phase.
¾
It will be a reference for further modifications of the software
¾ Successive versions of the specifications have to be clearly traced and should appear in the code
¾
Will allow to develop the code in parallel
¾
Important for maintenance
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 50
25
Specifications ¾
Two kinds of Specifications
¾ General for the Portable parts ¾ OS specific for implementation and adaptation parts ¾
The specifications have to include :
¾ A project overview ¾ Scenarios in nominal case and error case ¾ The architecture ¾ For each module : ¾ ¾ ¾
The functional specifications The detailled APIs Data structures
Samuel Kortas – Janvier/Février 2003
Software Engineering
Page : 51
Sotware LifeCycle 4 . Implementation
06/02/2003
26
Configuration Management Tool ¾
Principle :
¾ Only store the delta from a version to another ¾ Provides tagging facilities ¾ Allows multi-site, multi-developers, multi-branches coding ¾
A tool to help you !
¾ Keep track of your work from beginning to end ¾ Save space and version management ¾ Manage easely different version of the code ¾
Famous tools :
¾ SCCS, RCS, CVS ¾ Source Safe ¾ Clear Case (Rational Software)
Software Engineering
Samuel Kortas – Janvier/Février 2003
Page : 53
An Example of Version Management ¾
Tag to help keep track
¾ For each different branch : stable, delivered/maintained, experimental
¾ For each major step of the software cycle : development, validation, delivery
¾ Shall we all track : modules, compiled objects, executable, tests, results of the tests, test proofs? ¾
One base for all developments?
¾ Windows and Linux have problems to stay aside ¾ How to synchronize versions developped on different places? ¾ To which version and when to report modification/fix made in one branch
¾ --> efficient and convenient way of saving the work of everyone
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 54
27
Automatic Code Generation Tool A dramatic help and danger for productivity!
¾
¾ Idea : automatize the repetitive generation work ¾ use a higher level of abstraction than the programming language : better to discuss with people, to stick with specification ¾ Examples : ¾ Rational Rose : UML to C++ ¾ perl2C, a2p, a2ps… ¾
¾ Danger : ¾ ¾ ¾
Not to know how to use the tool Think it ’s magical NEVER change by hand a generated code!!!!!!
Samuel Kortas – Janvier/Février 2003
Software Engineering
Page : 55
Documentation
As a minimum
requirements detailled specification APIs sources : Version, modules, functions AND variables tests (procédures+résults) User manual Bug and trick tracing manual
Blind and systematic rules never replace intelligence
Documentation volume ∝ project volume Do not do too much or too less!
Samuel Kortas – Janvier/Février 2003
06/02/2003
Software Engineering
Page : 56
28
Documentation
Bad excuses :
It ’s not the final version, we are only testing That ’s a toy program anyway I am the only one to use the code, I ’ll remember! That is trivial. That is too complicated : I ’ll explain it later I ’ll complete the comments later : we have to reach our goal as soon as possible Documentation is not in the requirements
Advices :
Do it while coding! Document any tricky part, even fast or in an unclear maner
Samuel Kortas – Janvier/Février 2003
Software Engineering
Page : 57
Coding Rules ¾
Efficient coding is clear coding :
¾ Easy to read ¾ Easy to maintain ¾ Easy to trace ¾ Avoid : for (i++=(j--)
