ECOLE PEPI IDL - 5 au 9/12/2011 -...

ECOLE PEPI IDL - 5 au 9/12/2011 -La-Londes-Les-Maures ∗

Philippe Breucker †

09/12/2011

Résumé

Retranscriptons des cours et certains échanges tennus lors de l’écoleinformatique du PEPI IDL, qui a eu lieu du 5 au 9 décembre 2011 à La-Londes-Les-Maures (Var)

∗Document sous licence Creative Commons (http ://creativecommons.org/licenses/by-nc-sa/2.0/fr/)

†INRA UR Sciences en Société, Marne-La-Vallée (www.inra-ifris.org). Ingénieur d’études à laplateforme CorTexT (www.cortext.fr) du GIS IFRIS (www.ifris.org). Contact : [email protected]

1

Table des matières

Table des matières 2

I UML 7

1 Rappel Objet 91.1 Héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Ecapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 101.5 Polymorqhisme . . . . . . . . . . . . . . . . . . . . . . . . 101.6 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 UML 112.1 Méthode UML . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . 122.2.2 Diagramme de classe . . . . . . . . . . . . . . . 122.2.3 Outils UML . . . . . . . . . . . . . . . . . . . . . 12

2.3 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Diagramme états-transitions . . . . . . . . . . . . 13

II Agile 15

3 Méthodes 173.1 XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Test driven . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Team driven . . . . . . . . . . . . . . . . . . . . 183.3.3 Itératif . . . . . . . . . . . . . . . . . . . . . . . . 193.3.4 Feedback . . . . . . . . . . . . . . . . . . . . . . 193.3.5 Design émergeant . . . . . . . . . . . . . . . . . 193.3.6 Management . . . . . . . . . . . . . . . . . . . . 19

3.4 Gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Q/R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 Retour d’expérience . . . . . . . . . . . . . . . . . . . . . 21

2

TABLE DES MATIÈRES 3

3.6.1 URGI . . . . . . . . . . . . . . . . . . . . . . . . . 213.6.2 IJPB - petite équipe . . . . . . . . . . . . . . . . . 22

III Test logiciel 23

4 Introduction 254.1 Motivations du test . . . . . . . . . . . . . . . . . . . . . . 254.2 Validation et vérification . . . . . . . . . . . . . . . . . . . 254.3 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4.1 Test statique . . . . . . . . . . . . . . . . . . . . . 264.4.2 Test dynamique . . . . . . . . . . . . . . . . . . . 26

4.4.2.1 Test dynamique structurel “white box” . 274.4.2.2 Test dynamique fonctionnel “black box” 274.4.2.3 Niveaux de test . . . . . . . . . . . . . 274.4.2.4 Type du test . . . . . . . . . . . . . . . 274.4.2.5 Stratégie . . . . . . . . . . . . . . . . . 28

5 Test structurel 295.1 Bases du test structurel . . . . . . . . . . . . . . . . . . . 29

5.1.1 Graphe de contrôle . . . . . . . . . . . . . . . . . 295.1.1.1 Constitution des jeux de test . . . . . . 29

5.1.2 Flot de données . . . . . . . . . . . . . . . . . . . 305.1.3 Test mutationnel . . . . . . . . . . . . . . . . . . . 30

6 Test fonctionnel 316.1 Analyse partitionnelles des domaines de données . . . . 316.2 Test combinatoire . . . . . . . . . . . . . . . . . . . . . . 316.3 Test aléatoire . . . . . . . . . . . . . . . . . . . . . . . . . 316.4 Test à partir de modèle . . . . . . . . . . . . . . . . . . . 32

7 Contexte Agile 337.0.1 Tests et méthodes agile . . . . . . . . . . . . . . 337.0.2 Rôle du test structurel . . . . . . . . . . . . . . . 337.0.3 Rôle du test fonctionnel . . . . . . . . . . . . . . . 33

8 Synthèse 35

9 TP Test driven developpement 36

IV Evolution, maintenance, réutilisation 37

10 Intro 3810.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 3810.2 Software vs. Hardware . . . . . . . . . . . . . . . . . . . 38

10.2.1 Problèmes . . . . . . . . . . . . . . . . . . . . . 3810.2.2 Eléments . . . . . . . . . . . . . . . . . . . . . . 39


11 Conception 4011.1 Design patern . . . . . . . . . . . . . . . . . . . . . . . . 40

11.1.1 POO . . . . . . . . . . . . . . . . . . . . . . . . . 4011.1.2 Patern et principes : les dérives . . . . . . . . . . 41

11.2 Choix du langage . . . . . . . . . . . . . . . . . . . . . . 4111.2.1 Limites . . . . . . . . . . . . . . . . . . . . . . . . 4111.2.2 Seconde tendance . . . . . . . . . . . . . . . . . 4111.2.3 Début de Solution . . . . . . . . . . . . . . . . . . 41

11.3 Cycles de développement . . . . . . . . . . . . . . . . . . 4211.3.1 Histoire du logiciel . . . . . . . . . . . . . . . . . 4211.3.2 Cycle en V . . . . . . . . . . . . . . . . . . . . . . 4211.3.3 Itération . . . . . . . . . . . . . . . . . . . . . . . 4211.3.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . 42

V Bonnes pratiques de dev 44

12 Intro 4612.1 Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4612.2 Causes principales des problèmes . . . . . . . . . . . . . 4612.3 Points clés . . . . . . . . . . . . . . . . . . . . . . . . . . 46

13 Gestion de projet 4813.1 Projet informatique . . . . . . . . . . . . . . . . . . . . . . 4813.2 Méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4813.3 Développer de façon itérative . . . . . . . . . . . . . . . . 4813.4 Gérer les exigences . . . . . . . . . . . . . . . . . . . . . 4813.5 Réutilisation de code (composants) . . . . . . . . . . . . 4813.6 Modéliser . . . . . . . . . . . . . . . . . . . . . . . . . . . 4913.7 Vérifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4913.8 Versionner . . . . . . . . . . . . . . . . . . . . . . . . . . 4913.9 Gains attendus . . . . . . . . . . . . . . . . . . . . . . . 49

14 Qualité 50

15 Sécurité 51

16 Bonnes pratiques 5216.1 Règles de nommage . . . . . . . . . . . . . . . . . . . . . 5216.2 Règle de programmation . . . . . . . . . . . . . . . . . . 5216.3 Commentaires . . . . . . . . . . . . . . . . . . . . . . . . 5216.4 Mise en forme . . . . . . . . . . . . . . . . . . . . . . . . 53

17 Standards et normes 54

18 Analyse de code 55

19 Métriques 56

20 Couverture du code 57


VI Diffusion des développements informatiques 58

21 Démarche 6021.1 Déterminer les propriétaires . . . . . . . . . . . . . . . . . 6021.2 Traces de construction du code . . . . . . . . . . . . . . . 6121.3 Choix de la licence . . . . . . . . . . . . . . . . . . . . . . 6121.4 Preuve d’antériorité . . . . . . . . . . . . . . . . . . . . . 61

VII Débogage de code 63

22 Debogage 6522.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6522.2 Apports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6522.3 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

22.3.1 Traceur d’appel système . . . . . . . . . . . . . . 6522.3.1.1 Strace et valgrind . . . . . . . . . . . . 66

22.4 Debogueur . . . . . . . . . . . . . . . . . . . . . . . . . . 6622.4.1 Fonctionnement de base . . . . . . . . . . . . . . 67

22.5 Problèmes . . . . . . . . . . . . . . . . . . . . . . . . . . 68

VIIIAteliers 69

IX Documentation logicielle 71

23 Intro 7323.1 Pourquoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . 7323.2 Pour quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . 7323.3 Quelles doc ? . . . . . . . . . . . . . . . . . . . . . . . . . 73

24 Besoins 7424.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7424.2 Expression des besoins . . . . . . . . . . . . . . . . . . . 7424.3 Architechture / conception . . . . . . . . . . . . . . . . . . 7524.4 Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 7524.5 Utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 7524.6 Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

25 Mise en oeuvre 76

X Forge 77

26 Forge ? 7826.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 7826.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . 7826.3 Forges utilisée dans l’ESR . . . . . . . . . . . . . . . . . 79


XI CDSI : Pepi /Cati - Bilan 8026.4 Bilan PEPI . . . . . . . . . . . . . . . . . . . . . . . . . . 8126.5 CATI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8126.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8126.7 Point à améliorer . . . . . . . . . . . . . . . . . . . . . . . 8226.8 Futur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Première partie

UML

7


LAURENT PÉROCHON, INRA

Chapitre 1

Rappel Objet

IntroUML <=> POOTechniques de modélisation de systèmes.Composé d’objet en intéraction (ex. compagnie aérienne, ...)Ex. amphi : objets = chaises, instances = élève sur chaisePropriétés, méhtodes, héritage... diff. POO / PFonctionnelleClasse : méthodes et attributs communes à plusieurs instances (ie. le

moule). Une classe est un modèle, une abstraction.1 instance <=> 1 ClasseObjet : instance de classe (donc méthodes associées), et valeurs partic-

ulières pour les attributs.existe Associations entre objets (héritage par ex.)

1.1 Héritage

Héritage== Généralisation/Spécialisation. => Regroupe des méthodes/attributscommunes aux classes (factorisation ). Exemple : on factorise les objets “per-sonnes” qui regroupent “Homme” et “Bébé”. => Partage du code mais atten-tion au découpage excessif.

1.2 Agrégation

Relation entre objets ( ?)

1.3 Association

Relation entre objets (type prof demande rapport à étudiant)

9

CHAPITRE 1. RAPPEL OBJET 10

1.4 Ecapsulation

=> Séparation méthodes et attributs publique et privées. Sécurisation ducode.

1.5 Polymorqhisme

auto-adaptation d’un objet à l’instanciation.

1.6 Classes

Création de classes : se poser la question : “qu’est-ce qui agit, pense,fourni un service.. ?”

Sans objectifs, les réprésentations peuvent être multiples, du très simpleau très complexe. L’objectif permet d’arrêter le niveau de difficulté.

D’où : création d’un modèle. Attention à créer de bonnes associations en-tre classes afin de regrouper les fonctions de chaque classes (ex. les élèvesenvoient leurs rapport, le prof le demande). Attention à ne pas factoriser àoutrance : faire une classe juste pour stocker un nom par ex n’est pas bon.

Chapitre 2

UML

logiciel se représente : ss forme symbolique ou exécutable.l’UML modélise :un domaine, une architechture matérielle, un mode de communication en-

tre développeursVue d’ensemble : vient de l’OMG (Object Management Group), qui produit

UML v1 en 1997 et UML v2 2005 (arrivée de l’automatisation des modèles,MDA).

UML Manipule des entités et des relations.- Entités : Classe, Acteur, Cas d’utilisation, Etats/ Activité, Paquetage- Associations : dépendances, association, agrégation, généralisation/spécialisation- Diagrammes : regroupent entités et associations sur 13 diagrammes dif-

férents. Plusieurs représentations graphiques d’un logiciel.UML est un formalisme, pas une méthode.Symbole : bonhome

2.1 Méthode UML

1- Définir Type d’acteursOn modélise les types d’utilisateurs par les acteurs.2- Faire la liste des fonctionalitésListe des fonctions devant être remplies par chaque acteurs. En UML :

fonctionnalité = cas d’utilisation. Symbole : cas d’utilisation.=> Diagramme des cas d’utilisation et des acteurs. On peut faire des as-

sociations entre cas d’utilisation. On détail ensuite les cas, avec les fonctionsdemandées par les acteurs et exécutées par le logiciel. On prend en compteles aspects métiers et/ou les aspects techniques.

3 - Réaliser les fonctionnalitésOn se pose les question :- Quelles sont les parties qui interviennent pour réaliser les cas d’utilisation

(structure du système) ?- Comment font les différentes parties pour réaliser le cas (dynamique) ?

11

CHAPITRE 2. UML 12

4 - Créer la structure- Faire des sous-systèmes, regroupés en paquetages : associations entre

sous-systèmes- Ces sous-systèmes sont ensuite modélisé en objets puis regroupés en

classes (une classe = un rectangle, sous deux formes, avec ou sans méthodeset attributs)

- Création des associations (type lapin mange salade) et de leur cardinal-ité (0..n, 1..n, ...). Ensuite Génératlisations/spécialisation (schéma d’héritage),agréation (et décomposition).

Bien garder dans ces diagrammes la distinction métier/technique : dif-férents diagrammes sont nécessaires : on ne discute pas de la même façonavec un développeur ou avec un "client".

Rq. : UML est une méthodea utiliser si on veut et quand on veut. Ce n’estpas toujours utile, voire compliqué dans certain cas.

2.2 Introduction

2.2.1 Diagramme de cas d’utilisation

-> aujourd’hui : utilisé pour rescencer besoins/ but du logicielCrise du logiciel : dynamique créée autour des fonctionnalité et des ac-

teurs. On invente les cas d’utilisations. Ils peuvent servir à analyser un codeexistant en fonction des besoins réels.

On s’aperçoit alors que plusieurs pan entiers du logiciel ne servent à rien.On jette donc ces parties et on se reconcentre sur les parties désirées =>Gros changement de pratiques.

2.2.2 Diagramme de classe

Lorsqu’on parle avec le client, on a un vocabluaire correspondant à la réal-ité d’un système, non pas informatique. Le diagramme de classe du domainescientifique peut alors aider à avoir un langage et un vocabulaire commun.

Il y a de bonne chance que les classes immaginées comme ça soientutilisées plus tard.

Mais domaine scientifique évolue beaucoup plus lentement que les tech-nologies : conflit des rythmes d’évolution. Les évolutions peuvent être très dif-ficiles si la séparation technologique / scientifique n’est pas clairement définiedans le code. Donc bien séparer les aspects (donc les classes) techniquesdes classes scientifiques .

2.2.3 Outils UML

Plusieurs types d’outil existent 1. On peut soit utiliser un outil graphiquesimple (comme powerpoint), soit des outils spécifiques UML avec des kit

1. les outils sont discutés sur le site du PEPI IDL

CHAPITRE 2. UML 13

graphiques, ou encore des outils qui gèrent un projet en tant que tel avec toutles aspects 2. Voir aussi TopCase . Papyrus vient de la communauté CEA.Dev en commun depuis plusieurs années. Plus simple : papyrus. Ces outilssont libres.

Il existe des outils payants : Rose (par les créateurs d’UML), Together (deBorland, qui n’est plus actif)

Autre aspect important : travail en communauté, échange de diagrammes.Si format images, non manipulables => un format commun d’échange XMLexiste. Pour cela, il existe une extension : “XMI”. Plusieurs versions existent,avec des compatiblités moyennes entre logiciels. Les logiciels n’implémententpas tout XMI. XMI ne permet pas d’exporter les graphiqes ou les disposi-tions spatial : d’où : utilisation du “DI” (diagram interchange), mais qui n’estpas forcément compatible non plus avec tous les logiciels. Pour éclipse, laversion “MDT” est la meilleure pour l’utilisation de papyrus . Autres outils in-téressants : argoUML , yEd, Bouml. A voir : “uml gourou” : blog intéressant surUML, agile...

2.3 Modélisation

La dynamique peut d’un système peut-être inter-objet ou intra-objet.

2.3.1 Diagramme états-transitions

Le diag e-t. : cycle de vie d’un objet. L’objet possède plusieurs états 3 aucours du temps. Certains objets ne bougent pas (invariants).

Ex : Feu rouge : attribut = couleur, valeurs = [vert, orange, rouge]Rq. trouver les états d’un sytème peut être extrèmement complexe, de

même que nommer les états. Les états sont des aspects disjoint d’un objet :un objet ne peut être dans deux états.

Le passage d’un état à un autre est nommé transition .D’où le diagramme états-transitions qui symbolises les différents états

(rectangles arrondi) et des transitions (flêches). La transition se produit lorsqu’unévénement se produit. L’événement peut avoir une condition d’occurrence.Rq. un évènement peut être externe à l’objet ou au système.

Notion d’état initial , d’état final .Il existe des activités liées à un état / transition qui se produisent lorque

l’objet change d’état, ou lorsque l’évenement se produit.- une activité est une série d’action- une action est une unité de traitement, la plus petiteEx. : activités une fois à l’entrée, en boucle pendant un état, lors d’un

évènement, une fois à la sortieNotation : sur la flèche :Evenement [ ondition℄ / a tivité

2. cf dans la virtual box le plugin eclipse papyrus3. ensemble de valeurs particulières des attributs de l’objet

CHAPITRE 2. UML 14

l’évenement se déclanche sur la condition, puis réalise l’activité.- Il existe des “macro-états ” qui comprennent des sous-états. Rq. : les

transition vers l’état final ne sont pas nécessaires si le macro état transitedirectement vers l’état final du système ; en revanche les sous-état ont besoind’un etat initial.

Ex. : course Hippique

Activités Symbole : rectangle arrondi.- Conditions : les activités peuvent avoir des conditions de réalisation (OU)Notion de barre de synchronisation 4 : activité 1 et 2 doivent être finies

pour que l’activité 3 commence.A l’inverse, on peut lancer deux activités à partir de la fin d’un première

(ET)Ex. : activités du ruminant au pâturage.ex. Schémas d’activité inter-objet et de séquence : on peut presque aller

jusqu’au code objet à partir d’un diagramme de classe+activité+séquence

4. (Attention, erreur : switcher type fourche et synchro sur la pres.)

Deuxième partie

Agile

15

CHAPITRE 2. UML 16

Intervenant : Resp. dev dans le privé.Origine : XP, (2002) puis Agile depuis 2003.A l’orgine de la méthode :- en 1994, 53% des projets échouent (arrétés, ou arrivent trop tard), contre

24% en 2010. De même, 44% projets dépassent le budget en 2010 contre3&% en 1994.

- Standardisation du métier, spécialisation des tâches, montée en puis-sance des SSII, délocalisation, taylorisation,...=> Métier de conception devientmétier de production.

Un groupe d’américains crée l”’Agile manifesto ” en 2001 (17 consultantsen informatique 5). Ce manifeste met en avant des valeurs :

- Individus et intéractions plus importantes que processus et outils.- Logiciels opérationnels plus qu’une documentation exhaustive- Collaboration avec le client plus que la négociation contractuelle- Adaptation au changement plus que le suivi d’un planCertains principes sont édictés :- Satisfaire le client- Mettre en avant des itérations, etc

5. R.C. Martin, M. Fowler, W. Cunningham, Jeffries,...

Chapitre 3

Méthodes

Plusieurs méthodes agiles :- XP, SCRUM, Crystal, XUP, DSDM, Lean software development

3.1 XP

Valeurs- Simplicité- Communication- Feedback- Respect (de ses pairs)- Courage (prendre des risques, refuser le cycle “en cascade”)Pratiques- Client sur site- Jeu du planning (plusieurs itérations, plannifiée à l’avance)- Intégration continue (automatiser la construction de livrables - type maven,make)- Livraison fréquentes (si possible, livrer à chaque itération)- Rythme soutenable (pression constante sur les équipes)- Test de recettes/fonctionnels (livraison en production automatisée)- Tests unitaires (automatisation, objectif de design)- Conception simple (combatre l’architecture qui ne sert à rien)- Utilisation de métaphores (langage commun client, dev, test)- Remaniement permanent (ie refactoring.avoir le courage de refaire des

parties de code plutôt que d’entasser des correctifs. Diminue le coût de main-tenance)

- Appropriation collective du code (pas de spécialiste indispensable)- Standards de code (écriture du code)- Programmation en binôme

3.2 SCRUM

Rôles :

17

CHAPITRE 3. MÉTHODES 18

- Product Owner : décide ce que devient l’application, priorise les fonction-nalités mais ne fait pas de l’architecture

- ScrumMaster : coach, responsable du processus, du cylcle agile- Equipe : ensemble des personnes réalisant le logicielQuatre rituels- Sprint planning : itération régulière- Daily scrum : communication, feedback, tous les jours, pour mettre au

courant les autres de ce qu’il se passe- Sprint reviews : fin d’itération, bilan, démo : finir les fonctionnalités et les

montrer. Eviter l’effet tunel : tester régulièrement pour avoir une véritable vuesur l’avancement.

- Sprint retrospectives : amélioration continue, retour sur les mauvaisesexpériences

Trois objets- Product backlog- Sprint backlog- Burndown chart

3.3 Pratiques

3.3.1 Test driven

Les tests sont au coeur du développement - ils doivent être automatiséspour éviter la régression lors de la sortie d’une version

- Test unitaires automatisé (xUnit)- Test Driven Developpement (TDD) : Ecrire les tests unitaires avant le

code : permet de faire du design avant de coder et de rester proche des at-tentes clients. Vérifient que le code fonctionne.

- Test fonctionnels automatisés : vérifie que le code sert à une fonctionnal-ité

- Behaviour Driven Developement : Ecrire les tests fonctionnel avant lecode. Servent de documentation de code

Il existe des framework de test (type concordion) qui génèrent des tests etmaintiennent la doc à jour avec les résultats des tests.

3.3.2 Team driven

“Le développement logiciel est un problème de relations sociales”. (J. Roth-man)

- Equipe élargie : Client, testeur dans l’équipe- Rôles- Présence d’un coach ou d’un ScrumMaster (XP, Scrum)- Propriété collective du code- Binôme


3.3.3 Itératif

3.3.4 Feedback

- Intégration continue- Feedback à tous les niveaux : plan, test, negociation, ...- Démo- Dashboard- Amélioration continue : afficher les difficultés et les résoudre- Métriques (couverture de code, complexité)

3.3.5 Design émergeant

- Incrémentale- Refactoring- Simple design- Just-In-time- Design-Patterns, Solid- Design émergeant nécessite parfois des cliquets. (focalisation sur un de-

sign particulier)- Real option

3.3.6 Management

Management différents que les entreprises classiques. Le manager estlà pour supprimer les problèmes, pas pour distribuer les tâches (plus de bâ-ton/carrote)

- Servant leadership- Pensée systéme- Gestion du risque (Black swan theory : minimiser l’improbable)- Conduire la vision- ...

3.4 Gains

- Augmentation de la qualité des appli- Diminution du nombre de ligne de code- Réduction du coût total de possession (TCO)- Réduction du Time to Market- Augmentation de la vie des appli- Augmentation de la motivation des équipes : les personnes sont contents

du travailL’agilité est-elle un acquis ?Oui mais encore difficilement accepté car elle donne de l’autonomie au

gens, diminue le nombre de personnes sur un projet et les coût.


3.5 Q/R

- les product owner actuellement sont difficile à trouver/ à former, mais onpeut y arriver

- question de la motivation du chercheur dans un projet, notamment sur lelong terme. Le chercheur a pour objectif la publi, pas le logiciel.

- produire quelque chose qui a de la valeur vs. produire le résultat d’uneitération : attention à ne pas se perdre dans la méthode en perdant de vue lesobjectifs du client/chercheur. Déveloper de l’ingénierie incrémentale : démon-trer que la sortie d’un incrément donné a de valeur.

- Pb d’intéraction avec le scientifique qui est “inssaisissable”.- Peut-on faire de l’agile tout seul : non. Mais on peut en utiliser cer-

tains principes et bonnes pratiques (test unitaires par ex.). Produire moinsde bug plutôt que du code facile à debuger. Rq : il y a une équipe avec leclient/chercheur.

- XP : contraignant ? regroupement géographique ? -> Il y a eu une adap-tation, avec des réunions inter-équipe par ex. XP à distance est possible (ex-périence sur du pair prog à distance)

- Q. : caractéristiques d’agile : niveau hierarchique faible, informaticiensgénéralistes : il y a une sincérité. Ce gnere de méthodes ne peuvent-ellespas ralentir l’évolution de carrière : on ne devient pas spécialiste donc on apas de promotion. R. : oui, surtout en France. US : paie très bien, sur lescompétences, non pas sur les spécialisation. Mais sur le long terme, les in-formaticiens deviennent meilleurs et donc mieux payés (en tout cas dans leprivé). R. : lorsqu’on est formé à Agile, on peut évoluer en changeant de rôledans la méthode (coach). A l’INRA, on est pas promu comme ça quoiqu’il ensoit.

- Q. Expé d’agile dans un projet externalisé. Dans un premier temps leschangements de besoin étaient bien perçu, jusqu’à un certain point où lepresta ne les acceptait plus. Question : doit-on spécifier plus ? R. : Le prob-lème est de faire de l’agile “au forfait” donc si le client change, le presta setrouve à faire les spec plus les changements demandés.

- Q. Le livrable n’est pas toujours disponible et donc les changements sontdifficilement gérables. R. la Moe et Moa doivent toujours être investis : lesclients comme les développeurs doivent prendre des responsabilités. Le clientdoit dire ce qu’il veut et le développeur ce qu’il a fait. Ce travail reste trèsdifficile à mettre en oeuvre.

- Q. Projet d’un logiciel pour des chercheurs, qui enrichit les recherhes.Système d’itération mise en place puisque l’amélioration du modèle. Pb. : oucommencer pour appliquer la méthode. R. Commencer par mettre en placeles tests, puis le processus d’itération en impliquant plus le chercheur.

- Q. Problème sur la programmation en binôme : surtout à l’INRA.


3.6 Retour d’expérience

3.6.1 URGI

Plateforme URGI. : plateforme développement d’outils pour la biologieProjets ANR, financement orienté sur la question scientifique et pas l’outil

avec peu de ressources.Evolution des besoins en cours de projet est importante (changement des

techno, questions originales changent, nouvelles questions apparaissent)Contraintes- utilisateurs non-informaticients, souvent externe à l’unité- développeurs en interne, code robuste, besoin de maintenance et évolu-

tionDifficultés- Domaine en cte évolution, adaptation aux besoins permanente- Besoins de connaissances multiples (bio, bioinfo, info)- Turn over importante (essentiellement CDD 1an à 3 ans). Maintenance

des outils développés pour les suivants.D’où besoin d’une méthode répondant à ces contraintes : Agile. Partic-

ulièrement pour les itération courtes et le binômage.Constitution de l’équipeMasse critique de développeur à obtenir.D’où : création une équipe de développement. Rotation de binôme sur les

développements. Mise en place d’un budget de projet.3 équipes : systèmes d’information, pipelines, data.Premier problème : gestion du temps.Une personne = deux équipe “agile” maximum, pas plus de 80% du temps,

pas moins de 20%Les agents donnent leurs dispo. On donne 1 j par semaine pour autre

chose + 2h/j pour réponse aux e-mailsLa notion de “feature”Spécification légère d’une “user-story “ : Ecrite (mais pas toujours) par

l’équipeArbitrage à chaque itération (1 mois)Une feature : un coût et une durée maximale d’un moisFeature leaderPratiquesFeatures dans jira, binomes, gest de version,...Réunions : stand-up tous les jours, réunion d’itération (présentation, dé-

mos) tous les moisBudget : % de temps de chaque développeur apporté à chaque projetProjet common : feature transversales, maintenance applicative, 20% du

tempsBurn down : conso des ressources sur 3 mois (3 itération)Possibilité de faire des avances de temps, mise à 0 au bout de 3 mois.Bilan


4 ans de mise en place(+)Développeurs satisfaits, meilleurs suivi, réorientation rapidePlus de visibilité sur les difficultésMeilleurs résultats(-)les personnes en dehors se sentent exclusrythme imposé accruvisibilité plus courtepas le temps de s’approprier le projetpeu de temps pour les démos ou les discussionsModifications de la méthodeD’où :- création d’une roadmap- abitrage des features pour 3 mois avec le budget- co-contruction des features entre chef de projet et devRecommandations- pas de dogme établis- principes plus important que les pratiques- mettre en place progressivement- contruire la confiance : autonomie des équipes, auto-organisation- déléguer les responsabilités- jamais remettre en cause les chiffrages- ne pas remettre en cause

3.6.2 IJPB - petite équipe

Contexte : 5 unités INRA -> TGU : “IJPB”Equipe informatiques constituée à l’intérieur de la TGU (360 personnes,

25 équipes)Mise en place avec Olivier Inizan, formation à l’URGI, école ENVOL, ...Mise en place des pratiques basées sur SCRUM (backlog, itérations 15

jours)Première expérience satisfaisante sur un projet pilote, à 2Deuxième expérience : ajout des binômes, augmentation des intéractions.BilanStand-up : suivi inégal, dérives et digressionsDiversité des projets complique la mise en placeFacilité de communications bio / informaticiens...DifficultésPlus d’analyse que devProjets sans docMultiple projets

Troisième partie

Test logiciel

23


Fabien Peureux, maître de conf à l’univ de franche-comté, ancien consul-tant dans le privé.

Chapitre 4

Introduction

4.1 Motivations du test

Pourquoi des tests ? A cause des bugs . Bug vient d’erreurs, commisesà différents niveaux, spec, analyse et conception, développement, qui con-duisent à une anomalie de fonctionnement .

Un bug côute cher : 60 MM §/ an, 22 pourraient être évités si des procé-dures de test de logiciels étaient améliorées.

On ne teste pas car le cylce en cascade (analyse-dev-test) met le test à lafin donc le retard met le test vers le client.

4.2 Validation et vérification

Validation : logiciel offre les services attendusVérification : modèles utilisé sont correctsMéthodes- Tests statiques (revue de code, spec, docu)- Test dynamiques (executer le code)- Vérification symbolique- Modèle checking

4.3 Définition

- Exécution ou évaluation d’un système dans l’intention d’y trouver desdéfauts de fonctionnement

Rq. c’est bien l’intention qui compte : il ne faut pas faire de test pour qu’ilspassent mais pour trouver les bugs.

- Le test ne prouve pas qu’il n’y a pas d’erreur dans le code, jutes que lesfonctions développées ne sont pas bugées.

25

CHAPITRE 4. INTRODUCTION 26

4.4 Pratique

Test appartient à l’activité de validation du logiciel.2 types d’erreurs :-> erreur de type structurelles-> erreur touchant au service rendu par le logicielLe test est impopulaire en entreprise : le testeur “sappe” le travail du

développeur s’ils sont séparés. Les deux sont souvent antagonistes alorsqu’ils devraient travailler ensemble. Réputation en france : le testeur est lemauvais codeur. Aux US c’est l’inverse : un validateur est plus important (sortede dev sénior) car une étape qualité donc plus importante.

Le test et le code doivent être produit ensembles et sont indissociables.Actuellement le test dynamique est le plus diffusé. Il représente 60% du

dev (plus de test que de dev).Méthodes :- Test statiqueTraite le code du logiciel sans l’éxécuter- Test dynamiqueRepose sur l’éxécution du code effective pour un sous ensemble bien

choisi de données de test

4.4.1 Test statique

- Exemple : lectures croisée / inspections. Vérif collégialle d’un doc (pro-gramme ou spec du logiciel)

- Analyse d’anomalie : corriger de manière statique les erreurs (typageimpropres, code mort)

- Avantage : peu coûteuse, permet de régler 60% des problèmes- Inconvénient : ne permet pas de valider le code en fonctionnementDonc nécessaire, mais pas suffisant, et donc pas souvent fait. Bénéfique

pour l’équipe mais investissement a un retour à long terme.

4.4.2 Test dynamique

Test d’exécution du programme, sur4 niveaux :- Test des composants (unitaire) [dev]- Test d’intégration des composants [dev/moe]- Test du système global [moe]- Test d’acceptation (recette) [moe/moa]2 techniques- Test stucturel “boite de verre” : analyse du code source, jeu de test parti-

culier pour l’analyse- Test fonctionnel : analyse “boite noire” : jeu de tests créé par les spec.

Test de la bonne fourniture du service demandéEn résumé :


- Exécuter le programme sur un nombre fini d’entrées- Valider les fonctionnalités attenduesExemple : test de G. Myers (1979) : programme fournissant le type d’un

triangle. Demande des test à faire sur ce logiciel. 14 cas de jeux de test àfournir trouvés.

4 Activités- Séléction d’un jeu de test- Soumission du jeu test- Dépouillement des résultats (Pass/Fail/Inconclusive)- Evaluation de la qualité et de la pertinence des tests effectués (Pass ne

veut pas forcément dire qu’on a tout testé)Cylcle de vieDesign -> Prepare -> Run ->Validate

4.4.2.1 Test dynamique structurel “white box”

Données du test sont produites à partir d’une analyse de code : on cherchetous (ou presque) les chemins possibles par exemple, ou exécuter toute lesinstruction.

4.4.2.2 Test dynamique fonctionnel “black box”

On teste directement si le programme fait ce qu’il doit.***La complémentarité des deux est essentielle. Les tests structurels dé-

tectent les erreurs commises, les fonctionnels les erreurs par rapport aux spé-cifications.

Rq. un test fonctionnel exhaustive est en réalité impossible : la combina-toire est trop importante.

4.4.2.3 Niveaux de test

Test unitaire : procédures, modules, composants (50% du coût total)Test d’intégration : bon comportement : coût 10xbug unitaireTest fonctionnel : 100x

4.4.2.4 Type du test

Test fonctionnelsTest non-fonctionnels (valide la manière dont les services sont rendus)Test de performance (load testing, stress testing)Test de non-régression (pas d’anomalie introduite par de nouvelles ver-

sions)Test de confirmation (valide la correction d’un défaut)


4.4.2.5 Stratégie

Le plan de test et de validation doit être fait à l’avance : Plannifier les tests.

Chapitre 5

Test structurel

5.1 Bases du test structurel

Différents outils permettant les tests structurels, par ex les graphes de con-trôle :

5.1.1 Graphe de contrôle

Permet de représenter n’importe quelle algoNoeud = blocs d’instructionArcs = posibilité de transfert d’un noeud à l’autreUne seule entrée A au programme (noeud de base) et une seule sortie F.

Permet de déterminer toutes les possibilités de chemin A à F.Structures de graphe :séquentielle : abdé ision : a (b+ ) ditérative : ab ( b)* d

5.1.1.1 Constitution des jeux de test

On produit de jeux de test donnés à partir des chemins du graphe decontrôle. Le test doit couvrir tous les noeuds et tous les liens, ie couvrir toutesles instructions et tous les enchaînements .

Notion de taux de couverture : nb noeud couvert par le test/nb total, idempour les liens : on peut avoir un taux de couverture de 100% pour les noeudsalors qu’il reste des liens (donc des erreurs) non-couverts.

Couverture de tous les noeuds = critère TER1 , tous les liens TER2 (TestEfficiency Ratio)

Rq. : TER2=>TER1Un jeu de test doit aussi détecter des cas extrêmes si on ne passe pas

dans une boucle (les variables ne sont pas changées et du coup peuvent créerdes erreurs). D’où : critères spécifiques pour les boucles : “chemin limite” :non-itération de la boucle, et chemin intérieur (exécution au moins une fois).

29

CHAPITRE 5. TEST STRUCTUREL 30

On couvre de 0 à i fois la boucle (“i-chemin”). Cela garantie TER1 et TER2,et le critère de couverture des chemins limites et intérieurs. En posant i=navec n le nb max d’itération possible, appelé critère tous les chemins . Dansla pratique c’est peu ou pas utilisé (trop de tests). Donc le problème est dechoisir des jeux de tests les plus intéressants en fonciton du composant testé(critique ou pas, gros risques ou pas,...).

IL existe une hierarchie des critères de test.

5.1.2 Flot de données

Deuxième mode de représentation : on anote le graphe de controle parcertaines infos sur les manipulation de variables par le programme

- Définition de variables : lorsque la valeur de la variable est modifiée- Utilisation : accès à la valeur de la variable : p-utilisation dans une condi-

tion, c-utilisation lors de l’accès simpleCritère de couvertures :“toutes-les-utilisations”-> “tous les DU-chemin” (toutes les paires définition-

utilisation d’un graphe)-> “tous les chemins”

5.1.3 Test mutationnel

Idée : considérer les variantes d’un programme comme des mutants quine diffèrent que par une instruction. En modifiant des parties des instructions,(par ex. X devient Y) on crée un ensemble d’erreurs pouvant s’introduire lorsdu modifications du programme. Un jeu de test permettant de vérifier toutesles possibilté des mutants est ensuite créer. Cette méthode perme d’évaluerla pertinence des données test en vérifiant un jeu de test sur tous les mutantsqu’on aura générer, et voir si les erreurs ressortent toutes.

Pour repérer les mutants les plus probables (type fautes de frappe) il existedes modèles de faute. Mais cette méthode est coûteuse évidemment.

Chapitre 6

Test fonctionnel

Le test fonctionnel vise à examiner le comportement d’un programme etsa conformité avec la spécification. On doit sélectionner avec précision desdonnées test.

Les méthodes utilisées :

6.1 Analyse partitionnelles des domaines de données

Notion de classe d’équivalence : correspond à un ensemble de donnée quitestent le même comportement (activer le même défaut).

On caclul les classes, on choisi un représentant de la classe, et on com-pose par produit cartésien les jeux de test. On suit pour ça des règles departitionnement (type si valeur appartient à intervalle, on construit une classepour les val. inf, une pour les val. sup, et n classes valides). Les erreurs sor-tent souvent aux valeurs limites des classes.On forme les classes en prenantles valeurs aux limites des classes d’équivalence. Diffculté de caractériser lacouverture du texte.

6.2 Test combinatoire

On ne peut pas tester toutes les combinaisons, mais il existe des méthodespour trouver les combinaisons les plus intéressantes, comme Pair-Wise (oncouvre chaque combinaison de pair de valeur). Ca détecte la majorité desfautes. Problème : le choix des combinaison ne détecte pas forcément le bug,et le résultat doit être fourni à la main, depuis le cahier des charges.

6.3 Test aléatoire

Ppe : utilisation d’une fonction aléatoire dans le domaine de la donnéed’entrée, ou d’une fonction statistique

Exemple : échantillonnage de 5 en 5 pour une donnée d’entrée représen-tant une distance. Le test aléatoire a une courbe de couverture plus rapide

31

CHAPITRE 6. TEST FONCTIONNEL 32

6.4 Test à partir de modèle

On génère les cas de tests à partir du modèle formel type UML. La produc-tion des données de test est alors automatisée, en fonction des attentes ducahier des charges. Les scripts de tests sont aussi générés car il découllentdu modèle directement. Donc on a le schéma

Modèle Formel + Directives = jeu de test + résultats attendus.

Chapitre 7

Contexte Agile

Plusieurs principes Agile appliqués aux tests :– Versionning : les developpeurs commit tous vers un serveur de version– Serveur d’intégration continue : intègre automatiqment les modifs et

passe les tests.– Si les tests passent, le déploiement est automatique et passe sur le

serveur de prod– Sinon, il n’y a pas de déploiement et tous les développeurs s’arrêtent

pour voir ce qui ne va pas

7.0.1 Tests et méthodes agile

– Xunit, concordion

7.0.2 Rôle du test structurel

Pratique– dev les test en premier– dev le code corrspondant– refactoriser

Gains– Détecter au plus tôt les erreurs– Assurer la non-regression– Améliorer la testabilité– Simplifier l’architechture– Simplifier le code source

Processus Refactor->Vert->déploiement, jusqu’à plus de test.

7.0.3 Rôle du test fonctionnel

Pratique

33

CHAPITRE 7. CONTEXTE AGILE 34

– test client automatisé– objectif fonctionnels du développement

Gains– Spécification exécutable– Capturer des besoins réels– Garantir la conformité vis-à-vis du cahier des charges

Chapitre 8

Synthèse

Le test est incontournable :

- Validation par le test

- Complémentarité des approches

- Plusieurs techniques dédiées

Dans le contexte agile :- Expansion du rôle de test : spécifier les besoins, guider le développe-

ment, simplifier et minimiser le code développé

35

Chapitre 9

TP Test driven developpement

(cf pdf tp)Le test driven = méthode de dev par le testOn développe les tests sur les spec, et en premier, on fait passer ces tests,

et ensuite on refactore le code pour éviter les dupplications dues aux tests.Pour l’implémentation, plusieurs stratégies :

1. implé bidon : return true

2. triangulation : généralisation du code lorsqu’il sera au minimum en deuxexemplaires

3. implé correcte : taper direcement l’implé réelle

la stratégie à adopter dépend de la difficulté, du métier et du temps qu’on veutaccorder au test.

- on teste l’interface d’une classe (soit les méthodes publiques seulement) :l’interface est l’ensemble des services fournis par une classe au client test.

- le code test devient la doc de la classe

Refactoring Refactoring 1 = éliminer la duplication. Duplication de donnée(le 5x2 du TP) ou de code. Repérer le code “bad smell”.

Design Le test c’est de la conception, du design. Ce type de design estémergent : une vision globale suffit, mais le détail émerge des tests.

couplage faible Le code développé dans cette méthode doit avoir une faibledépendance : c’est garanti par le principe des interfaces : elle permettent dedécoupler l’implémentation du service rendu par la classe.

1. Voir “Refactoring : Improving the Design of Existing Code”, Martin Fowler, Addison-WesleyEd.

36

Quatrième partie

Evolution, maintenance,réutilisation

37

Chapitre 10

Intro

Objectifs session : identifier les élements qui permettent d’assurer l’EMR 1

d’un logiciel.L’ensemble des choix faits lors du codage à une uinfluence sur la réutilis-

abilité du code. Objectif = avoir éléments clé pour faire ces choix.

10.1 Définition

- Evolution : augmenter le comportement d’un système donné : le systèmepropose un contrat auquel on ajoute des “clauses”

- Maintenance : contrat non respecté par le logiciel, qu’il faut donc corriger- Réutilisation : d’un syst à un autre, il faut pouvoir reprendre quelque choseL’EMR n’est pas la chasse gardée de l’ingénierie logicielle. Idée = voir

ces thèmes sur d’autres secteur de l’ingénierie, tels que l’automobile ou lesponts. L’évolution est dans cette perspective la création d’un nouveau produit,et on réutilise des plans, pièces existantes. On répare également les objetsdéfectueux (=>maintenance).

10.2 Software vs. Hardware

Est-ce que l’industrie du software présente des similarités ?- soft : modfiable sur une base matérielle- discipline relativement jeune (informatique carte perforées = 35ans)

10.2.1 Problèmes

- En théorie, il est plus facile de faire évoluer un système informatique etde le faire évoluer que d’autres produits.

- Discipline jeune = historique faible, moins de capitalisation- D’où : deux rythme : rapide : modifier le software facilement et de façon

souple, et de l’autre lent : la capitalisation prend du temps.

1. Evolution-Maintenance-Réutilisation

38

CHAPITRE 10. INTRO 39

10.2.2 Eléments

A partir de ce problème, il faut identifier les élément de l’EMR dans l’ingénierielogicielle.

Plusieurs aspects :- En quoi la conception influe sur l’EMR- Est-ce que le choix d’un langage idem ?- Cycle du logiciel ?- Positionnement de la production de code par rapport à ces aspects ?

Chapitre 11

Conception

- “Ce qui se conçoit bien s’ennonce clairement” : plus un pb est clair danssa conception, plus il sera facile à mettre en oeuvre.

- Un logiciel bien conçu est maintenable et réutilisable : il s’agit surtout departie de logiciel pensées lors du codage pour être réutilisable

- Qu’est-ce que de la bonne conception pour des logiciels qui ne sontfinalement que du traitement binaire ?

Réponse par les approches- De l’approche procédurale à l’approche objet- Pierre-Alain Muller : “Modélisation Objet avec UML”

Exercice : Modéliser le même programme en objet et en procédural. L’objetest plus proche de la réalité, et on sort du paradigme binaire.

L’approche objet est-elle suffisante ?- Approche objet est-elle suffisante pour produire un logiciel plus adapté

aux EMR ?- Les pilliers de la conception objet : héritage, encapsulation, polymor-

phisme- Aller plus en avant avec les design patern.

11.1 Design patern

- Histoire : “Gang of four” : plusieurs personnes ayant l’idée de formaliserdes solutions génériques à des problèmes récurrents : invention des designpatern

- Ex. : Plusieurs cas où une classe est utilisée une seule fois dans l’appli :invetion du pattern singleton

- Ex. : Un objet se comporte comme une valeur, un patern : value-object

11.1.1 POO

Récoltés et formalisées par RC Martin, “Uncle Bob”Deux exemples

40

CHAPITRE 11. CONCEPTION 41

- Ouverture-fermeture (open-close ) : code ouvert aux évolution mais ferméaux modifications (tout ajout doit au minimum casser l’existant.

- Substition de Liskov : on va du moins spécialisé au plus spécialisé dansl’ordre de l’héritage.

- Les paterns sont une abstraction, répondent à des principes

11.1.2 Patern et principes : les dérives

- “Ticket d’entrée” toujours élévé : temps d’apprentissage long- Il pemettent de l’esthétique dans le code- Première tendance : abuser : “la paternite”- Seconde tendance : “Software craftmanship” : le coding devient de l’art- Rq. connaître les design patern peut être nécessaire pour maintenir cor-

rectement un code.

11.2 Choix du langage

Est-ce que le choix du langage influe sur l’EMR ?Oui : plus facile de maintenir du python que du C++Courbe d’apprentissage plus longue, connaissance du langage influe forte-

ment sur la facilité de maintenance et d’évolution.Pourquoi un langage interprété : compilé vs interprété : syntaxe / ticket

d’entrée / connaissance du langageTendance : aller vers l’interprété

11.2.1 Limites

- Performances : l’interprété est beaucoup moins rapide- Le python n’a pas de notion d’encapsulation, pas de notion de pub-

lic/privé : peut être un problème

11.2.2 Seconde tendance

- Appréhender le cycle de vie d’un code : il y a du code constant et variable.Dans des logiques type TDD on a souvent du code à remanier. La factorisationse fait après, lorsqu’on refactore le code pour le mutualiser : là il devient con-stant. Dynamique du cycle intervient donc dans la maintenance : d’un codevariable vers un code stable.

- La performance arrive souvent en second : faire marcher d’abord, fairevite après

11.2.3 Début de Solution

- Codage stable (design éprouvé + performance) : langage à typage propre- code variable (design incomplet) peut-être écrit avec un langage à typage

faible.


11.3 Cycles de développement

11.3.1 Histoire du logiciel

- 1970 : crise du logiciel, de plus en plus de bugs, de la nécessité deformaliser un cycle

- Premier pas : le cycle en V, cycle en cascade- Cycle courts, notion d’itérations : Rapid Application Development- 2000 : Kent Beck : “Embrace change” (méthode XP), Agile Manifesto- Scrum

11.3.2 Cycle en V

Phase de décision -> phase de phase de réalisation -> phase de livraisonEffet tunel : arrêt de la spec pour coder : mais le code n’a rien à voir avec

les spec orginales.D’où la pensée en itération.

11.3.3 Itération

- Découper le dev en pleins de petits cycles en V- Adaptation au changement :1 - pas de limite des décisions dans le temps2 - Feedback et démo permettent de corriger le capMais : prix à payer :- Avec des spec qui changent tout le temps, on passe son temps à spé-

cifier : le cahier des charges est limitant donc utiliesr plutôt des “user stories”ou des “features”

- Implication forte du “client” : “product owner “- Ingénierie incrémentale : tout le système n’est pas imaginé au début. On

a le nez sur l’itération sans vue d’ensemble.- Etre en mesure à chaque itéréation de produire un logiciel opérationnel

(mode dégradé). Le client doit pouvoir utiliser le logiciel à chaque itération :production de valeurs.

- Construire une archtecture qui s’adapte au changemen =>changementde la gestion technique

11.3.4 Tests

TestsProduction de code- Différentes façon, à partir du modèleNon régression- Assurer que le contrat est remplli suite à une modification du code- Une ratique pour assurer la non-regression : le test fonctionnel (TF)- TF : à chaque item décrit dans les spécification correspond un test


- Une pratique un peu extrème : les spécifications et les tests ne font plusqu’un : l’écriture du TF crée les spec

- Systématiser l’écriture d’un TFLa non regression est assurée.Limites du TF- Le TF est un “gros grain” : risque de diagnostique difficile : le Test Driven

Dev est souvent la solution

Cinquième partie

Bonnes pratiques de dev

44


Véronique Baudin, CNRS-> Logiciel conforme à l’attente du demandeur-> Facile à relire, à modifier

Chapitre 12

Intro

12.1 Projet

Def. : Ensemble d’activités et d’actions, dont l’obj est de répondre à unbesoin défini.

Se décline en 5 aspects :- Fonctionnel (besoins)- Technique( spec)- Organisationnel (contexte organisateur)- Délais (échéances, planning)- Coûts

12.2 Causes principales des problèmes

Plusieurs causes de problèmes lors du dev :- Mauvaises interprétation des demandes des utilisateurs- Surspécifications- Incapacité à tenir compte des modifs du cahier des charges- Construction algo non fiable- Membres isolés -> pas de moyen de savoir ce qui a changé- Procédures de tests coûteuses ou inefficaces- Découverte tardive de problèmes- Fable qualité du logiciel

12.3 Points clés

Pour y remédier : qq point clés- Bien comprendre les demandes utilisateur- tenir compte des modifications du cahier des charges- Eviter de découvrir les défauts trop tard- Traiter au plus tôt tous les points critiques du projet- Définir uen architechture robuste et adaptée

46

CHAPITRE 12. INTRO 47

- Bien maîtriser la complexité du système- Bien communiquer avec l’utilisateur final- Favoriser la réutilisation du code- Faciliter le travail en équipe- Concevoir en tenant compte des contrainte d’exploitation (ITIL)

Chapitre 13

Gestion de projet

13.1 Projet informatique

Schéma global des acteurs d’un projet (chef, Moe, Moa, utilisateur, équipe,...)Etapes de vie : étude, lancement,étude générale et détaillée, recherche et

détermination des solutions, réalisations et contrôle, ...

13.2 Méthodes

Objectif = guider les développeurs de la phase d’analyse à la phase demaintenance. Un grand nombre de méthodes existent de façon théorique,connues et pratiquées dans le monde du logiciel.

6 bonnes pratiques en ressortent :

13.3 Développer de façon itérative

planinifaction->besoins->conception->implémentation->déploiement(ou démo)->tests->évaluation->ré-évaluation->re-planification.

13.4 Gérer les exigences

-> Conditions que doit remplir un système ou tâche qu’il doit accomplir.Pour un syst info, exigences dynamiquesGestion des éxigences : mettre en évidence, évaluer, ...

13.5 Réutilisation de code (composants)

Imortance de développer du code réutilisable, développement à base decomposants.

48

CHAPITRE 13. GESTION DE PROJET 49

13.6 Modéliser

Ex diagrammes UML

13.7 Vérifier

Qualité = fonctionnalités, fiabilité, performances => tests

13.8 Versionner

-> suivi des changements du logiciel et de la doc, travail à plusieurs, de-mandes client suivies par le système.

13.9 Gains attendus

– mettre en évidence les incompréhensions, clarifier le CC– avoir un modèle standard– spécifier correctement le comportement attendu– focus sur les problèmes critiques– éval objective de l’avancement– incohérence entre CC et modèle– charge de travail réparte– évaluation du système– détection d’anomalies– amélioration process de production– preuves réelles pour le client

Chapitre 14

Qualité

Aspects de la qualité :- Point de vue du client : Correction, intégrité, convivialité, efficacité, com-

patibilité, extensibilité, robustesse, correction.- Point de vue du développeur : réutilisabilité, portabilité, lisibilité, modular-

ité, vérifiabilité, modularitéDéfinir avec le demandeurs les critères les plus importants, et avoir les

siens également.Existe des normes permetant de mesurer la qualité (ISO/CEI 9126, et

2500)

50

Chapitre 15

Sécurité

Sécurité = 1 aspect de la sûreté de fonctionnementSûreté =aptitude d’une entité à satisfaire à une ou plusieurs fonctions req-

uises dans des conditions donnéesConception- Anticiper de mauvaises utilisation d’un logiciel -> prévoir les défauts et

les failles de sécurité avant/pendant le développement- Quelques points à vérifier lors de l’implémentation :

1. Vérification de la validité des valeurs d’entrées externes

2. Vérifier valeurs des paramètres des fonctions publique

Outils :- utiliser les assertions (java) : contrôle d’un programme par lui-même pen-

dant l’éxécution- gestion des erreurs- gestion des exeptions : alerter, capturer, corriger.- limiter les dégâts (convertir les types de variables attendus nottamment)

51

Chapitre 16

Bonnes pratiques

Bon code/mauvais code :- Lecture par qq d’autre- Maintenance- Evolution- Partage et réutilisation- Faire une chose et une seule, mais bien- Peu de dépendances

16.1 Règles de nommage

- Nom clair et évident, prononcable, dans un langage explicite, en anglais- Règles uniforme de nommage

16.2 Règle de programmation

- Limiter le nombre de lignes- Faire une seule chose à la fois- Nommer correctement les fonctions- Mettre les grosses boucles dans des fonctions

16.3 Commentaires

- sont un mal nécessaire, pallient notre incapacité à expliciter le code di-rectement

- rester court- être cohérent enre commentaire et code- ne pas compenser le mauvais code par du commentaire- priviligier la ré-écriture du code (ex créer une fonction) plutôt que d’expli-

quer

52

CHAPITRE 16. BONNES PRATIQUES 53

16.4 Mise en forme

- Fichiers courts sont plus facile à comprendre- Aérer le code- une instruction par ligne- nb de colonnes limité- indentation correcte- espacement uniforme (parenthèses, virgules, signes opération...)Alignement horizontal des variables.

Spécificités des langages (langage C, C++, Fortran, Python)

Chapitre 17

Standards et normes

Standards inventés pour éviter la prolifération des compilateurs. Ex. CANSI.

Normes importantes pour la réutilisation du code (cf prés. et web).

54

Chapitre 18

Analyse de code

Analyse statique : rechercher erreurs dans le code, et dynamique :ex. : RATS pour php, python, c, c++

55

Chapitre 19

Métriques

Plusieurs métriques :Taille- nb lignes physiques- nb lignes code- nb lignes de commentaires- nb lignes videsStructure- Nb cyclomatique de Mc Cabe (complexité du logiciel)- Nb d’HalsteadOutils existent (cf pres).

56

Chapitre 20

Couverture du code

- Identifier les partie de code non-utlisées (idem, cf pres.)

57

Sixième partie

Diffusion des développementsinformatiques

58

CHAPITRE 20. COUVERTURE DU CODE 59

Nathalie Gandon, INRA

Chapitre 21

Démarche

Beaucoup de confusions autour des concepts de licence, protection et dif-fusion, libre/gratuit,...

-> Démarche :

1. Déterminer les propriétaires

2. Déterminer la façon dont le code a été construit

3. Choisir la licence

4. Vérifier la preuve d’antériorité (dépôt APP / Forge)

Tout ça doit être une démarche de conception, en amont du projet, d’un pointde vue stratégique.

21.1 Déterminer les propriétaires

Droits d’auteurs - Protection automatique par la loi du code. Mais il vautmieux i-déposer son code, ii-faire apparaître le copyright.

- Protection du type droit d’auteurs : longue (70ans)- Données pas protégée (seule lignes de code)

Auteurs, propriétaire, éditeur Auteur : codeur (personne phys.)Propriétaire : employeur si auteur salarié (pas stagiaires) : attention aux

auteurs non-salariésEditeur : diffuse ou met en vente (propriétaire ou non)Il faut pouvoir tracer le nom et le statut des personnes travaillant sur

le projet . Pour les non-salariés, faire signer une session de droits à l’issue dustage par ex.

Collaborations Liste des auteurs et de leur employeur à faireCadres contractuels ?Quels financements ?Quelles collaborations informelles ? Dans quel cadre ?

60

CHAPITRE 21. DÉMARCHE 61

On comptabilise les % de chacun : si des personnes n’ont rien écrit, ellen’ont pas de poids, si certaines écrivent trop de lignes, elles auront plus depoids...

Bases de données Protection différentes entre le contenu (loi sui generis)et la base elle-même (loi n°98-536 du 1/7/98 et suivant du cod e de la PI).

- Seul le contenu est protégé !- Producteur de la base est titulaire des droits

21.2 Traces de construction du code

Si on veut le choix de la licence finale, il est important de se poser desquestion au début

- Le code a-t-il des dépendances ? Libre ou pas ? Sous quelles licences ?

21.3 Choix de la licence

Pour déterminer la licence à appliquer à un logiciel, plusieurs paramètressont à prendre en compte :

- Définir avec l’unité, le département, ... les licences sous lesquelles leslogicels sont développés.

- Deux types : libre, propriétaires- On peut changer en cours de route- Est-ce que tous les partenaires sont d’accord sur le type de licence ?Rq. : il ne suffit pas de mettre le logiciel sur internet pour qu’il soit libre et

utilisé de façon licite : si une mauvaise utilisation du logiciel est prouvée, uneplainte peut se retourner contre l’auteur. De même, le code peut-être repris etvendu.

Déf.- Contrat qui donne, entre autre, le droit à une personne d’utiliser le logiciel,

autrement dit de l’installer sur son matériel et de l’éxécuter- Contrat conclu entre propriétaire et utilisateurLicences libres- deux classes : gauche d’auteur (copyleft) : GPL et permissives (non-

copyleft) : modif non-obligatoirement redistribuéePropriétairesA prendre si valo éco, pas d’accès voulu au code sourceSi changement en cours de code : accord écrit sur le choix des licences

21.4 Preuve d’antériorité

- Sert principalement en cas de litige- Plusieurs possibiltés dont l’utilisation- A l’INRA, dépôt à l’APPMentionner :


- nom du logiciel, n°de version- copyright INRA- nom(s) des labos- dépôt APP : n°IDDN- nom de licences- nom des auteursPour alle plus loinCf. page du CATI CIAM, vademcum INRA et PLUMEStar-up INRIA “Antelink” propose une analyse ’automatisée’ du noms des

auteurs et de leur poids dans le dev.Méthodes en cours de dev à l’INRA : projet pilote en cours au dept MIA.Logiciels libres d’analyse des licences embarqués : FOSSOlogy, OSLC

Septième partie

Débogage de code

63


Romaric DAVID (informaticien pas pas dev, resp. centre calcul, universitéde strasbourg)

Chapitre 22

Debogage

22.1 Définitions

Pôle HPC = méso-centre de l’Université de strasboug (hpc.unistra.fr)Débogage : consiste en l’analyse d’un programme présentant un com-

portement incorrect.- Plantage du programme- Prog qui boucle de façon infinie ou qui est bloqué- Prog qui calcule faux (ex. valeurs numériques éronnées)Analyse d’un programme :- Soit Après le plantage “post-mortem” : fichier “core” 1 et éxécutable ->

débogueur- Soit pendant l’éxécution (pré-plantage “in vivo”) en prenant le pas sur le

progamme y compris à distance (système de debogage client-serveur par ex.)

22.2 Apports

Pourquoi un debogueur ?- Identifier la ligne de code fautive plus vite autrement que par des printf- Contrôler le déroulement du programme en mode pas à pas (pratique

pour arrêter le programme avant qu’il ne plante)- Se concentrer sur les variables, en les explorant intéractivement

22.3 Outils

22.3.1 Traceur d’appel système

Bcp de prg se plantent dés le début.Deux causes principales :- ouvertures de fichiers, input- allocation de mémoire

1. état de la mémoire et du proc au moment du plantage

65

CHAPITRE 22. DEBOGAGE 66

Permettent de comprendre l’état du système au moment du plantage.

22.3.1.1 Strace et valgrind

strace : premet de tracer tous les appels systèmes (vraiment tout !) : pro-duit une sortie énorme.

Ex. sur l’instruction open : ouvre un fichier et renvoie un code de retournégative si problème. On regarde donc le résultat. On peut aussi comparerdeux cas (marche/marche pas).

Exemple : on essaye de trouver tout les appel négatifs à open, puis onretrouve l’argument.

EmulateurPermet de repérer les erreur d’accès mémoire (segfault) : on accède à une

zone interdite, ou à une zone du programme mais pas la bonne.Débogueur vous dira le n° de la ligne du segfault. -> code sour ce corre-

spondant.Outils :- insertion de code automatique pour vérifier les bornes du tableau (gcc le

fait pour java et Fortran). Possibiliter de coder des assert 2 en C directement.- bibliothèques au-dessus de malloc (mais limité à qq langages).- mais : on ne détecte pas les erreurs pointeurL’outil Valgrind permet d’éxécuter du code en surveillant tous les appels

mémoires et les défauts de cache, les mauvais appel à malloc,... Il exécutele code sur un proc virtuel instrumenté, puis le code instrumenté sur le CPU(ralentis l’éxécution) et on regarde la sortie. Il utiliser principalement mem-check, qui vérifient les lectures/écritures mémoires, emet des avertissementssur différentes choses (variables ou pointeurs non initialiées par ex.). Il repère,à l’octet prêt, les erreurs d’affectation. Il détecte également les doubles libéra-tion de mémoire et les fuites de mémoires. Memcheck dispose de sa propreversion de malloc.

Le programme sera ralenti de 5 à 100 fois. Attention aux tableaux sta-tiques : ne détecte pas le débordement dès le premier octet.

Remarques :- à l’install de valgrind dépend de libc6-dbg, qui contient les symbôles de

débugages

22.4 Debogueur

Ecrire un débogueur, c’est facile :)Le pas à pas est réalisé grâce à la fonction ptrace disponible sur linux.

Commande qui est à la base de tous les débugueurs du marché.Le programme lancé par le débogueur est un fork du débogueur (process

fils).

2. tester une condition en début de programme /fonction et sortir en cas d’erreur en affichantle message


Les différentes commandes que recevera le programmes sont :- avancer jusqu’à la prochaine instruction du compteur de programme (sin-

glestep) : dans la réalité, c’est la ligne de code- continuer jusqu’à la prochaine action du débogueur- lire / écrire une valeur (octet, mot) en mémoire dans les espaces d’in-

struction ou de données du processus.Le débogueur permet de faire le lien entre le code binaire, assemblé, et

le code source, en terme de variables et de présentation de structures dedonnées définie par le programmeur. Pour ça, il lui faut des symbôles dedébugages et avoir compilé avec les bonnes opions. Ils contiennent des de-scripteurs de variables, la position dans le code source,...

Ex. de symbôles : stabs, COFF, XCOFF, DWARF 2 (dwarfstd.org)Rq. Tous les débugueurs ne marchent pas forcément avec tous les com-

pilateurs. Certains langages sont plus ou moins bien pris en charge par ledébogueur.

22.4.1 Fonctionnement de base

Premier usage = où en est le programme.- Vérifier qu’un programme avance- Liste des appels empilé- Si c’est toujours la même pile d’appel, on sait que c’est toujours la même

fonctionRq. On doit bien filtrer la pile d’appel qui contient beaucoup de choses ne

concernant pas le programme

breakpoint On peut mettre en place des break-point (arrêt programme avantun emplacement indiqué). Ils peuvent être mis devant une ligne source ou as-sembleur. Ex. gdb : break ligne/nom fonction.

Servent à comprendre le contexte d’appel d’une ligne particulière. Rq. :L’arrêt à un breakpoint est systématique, mais on peut demander l’arrêt aprèsun nombre de franchissement du point d’arrêt.

Il existe des breakpoint conditionnels (arrêt seulement si variable remplitcondition : break 7 if i=10)

Il faut savoir où chercher dans le code.Donc on veut suivre l’évolution d’une variable : watchpoint rend le contrôle

du programme à chaque modif d’une variable (watch foo)

visualisation des données - A partir des symboles de débogagesle débogueur associe une adresse mémoire et un nom/type de variableles affiches à la demandeil faut parfois l’aider (cas des tableaux)=>exploration intéractive pour voir ou se situe le problèmeListe d’outils

gdb : gnu.org, pour C, C++, Fortran, python (septembre 2010)


dbx : oracle.com, pour C, C++, Fortran, Pascal

commerciaux : Intel, PGI, Pathscale

spécialisés : Totalview, DDT

Interfaces graphiques Manip en ligne fastidieuse : existe des outils graphiques.– eclipse CDT– kdbg (KDE)– ddd (data display debugger)

Facilite l’affichage des données complexe - tableau, structures, instances declasses.

ddd : intéractif, moins rébarbatif, possiblité de visualisation des données,manipulation des breakpoints. Mais les commandes sont quand même néces-saires, et la communauté n’est pas active.

22.5 Problèmes

- Support de certains langages pas forcément bien assuré (ex gdb pourFortan)

( solution la plus satisfaisante : ddd+dbx)Conclusion sur les différents outils.

Huitième partie

Ateliers

69


Objectif = partager retour d’expérience, identifier besoin formations. Idée= faire marcher le groupe PEPI, en mode réseau, pas client-service.

Neuvième partie

Documentation logicielle

71


Véronique Baudin

Chapitre 23

Intro

23.1 Pourquoi ?

- Accès rapide et fiable à l’info- Partage- Cohérence info- Réutilisation- Archive

23.2 Pour quoi ?

- Doc du logiciel ->spec, code source, doc utilisateur- Doc du projet

23.3 Quelles doc ?

Expression des besoins : définition de l’attendu, périmètre du projet, prior-isation des fonctionnalités

Archtecture / Conception : vue d’ensemble, relation avec l’environnementDocumentation technique ou détaillé : doc du codeManuels : différents en fonction de la cibleValorisation

73

Chapitre 24

Besoins

24.1 Objectifs

- Exprimer le contour du projet, le contexte général- Définir les acteurs du projets (humain ou non)- Définir les fonctionnalités attendues- Le contexte technique (machines, infrastructure)- Entrées / sorties de chaque fonctionnalité- Interface homme-machine- Cahier des charges fonctionnel et technique afin de réaliser et valider le

logiciel final

24.2 Expression des besoins

Atteindre ses objectifs passe essentiellement par le dialogue entre les ac-teurs du projet. La question est : comment obtenir les informations ?

Plusieurs méthodes existent telles que APTE 1, diagramme de PERT.Ex. logiciel de gestion des supports vidéos (cf. pres.)

Méthode APTE sorte de brainstorming organisé. Deux façons :’bête à cornes’ : par des questions simple, déterminer :- à qui le logiciel va servir- avec quelles données- pour quels besoinsou’pieuvre’Représenter toutes les composantes de l’environnement d’un logiciel. Pren-

dre en compte à la fois les utilisateurs et les règles devant être appliquées,telle que des textes de lois par exemple. On prend aussi en compte les as-pects matériels. Faire ensuite des liens entre les différents composants.

1. Application aux Techniques d’Entreprises

74

CHAPITRE 24. BESOINS 75

Le schéma généré constitue un outil de discussion avec le client.Mise en oeuvre :- Langage naturel- Pseudo code de type PDL- Diagramme de flot de donnée- UML- ...Des normes et standards existent pour l’expression des besoins.

24.3 Architechture / conception

- Obectif : fournir une vue d’ensemble du logiciel (cf pres.)

24.4 Technique

Définir les interfaces de programmation, les structuresOutils pour extraire les commentaires, comme javadoc ou doxygen

24.5 Utilisateur

pour utilisateur final (mode d’emploi, limites du logiciel)pour l’administrateur (procédure d’installation, pré-requis)pour le support : manuel ’utilisateur final’ + tests

24.6 Marketing

Posters de présentation, articlesFiche sur le web (PLUME, ESR)LicenceSite web du logiciel : téléchargement, contact, doc, équipe de dev, infor-

mation licence, mailing list,...

Chapitre 25

Mise en oeuvre

La mise en oeuvre doit être simple et informative. Aucun doc n’est figétans que le projet n’est pas clos (type FAQ). Les informations ne doivent pasêtre dupliquées ou mélangées. Donner des titres clairs et informatifs. Don-ner, pour chaque document, certaines info comme le titre, l’auteur, la datede création/modif, les numéros de version, la licence du document. Le con-tenu doit être facile à identifier, clair et concis pour le lecteur, illustré (typeUML). Identifier correctement les acteurs de la doc (commanditaire, analyste,développeur,...)

Créer les scénarios d’utilisation du document : faire un diagramme use-case par ex. ecrire les différents scénarios de mise en oeuvre. (cf pres.)

Il faut que le doc puisse permettre la compréhension du fonctionnementdu logiciel.

Les documents à produire sont essentiellement la doc technique et lemanuel utilisateur.

Déterminer la taille de l’équipe qui doit réaliser la doc (cf table de décisiondans pres.)

76

Dixième partie

Forge

77

Chapitre 26

Forge ?

Plusieurs sources existent, telles que sourceForge (4,3 Millions de projets),Chiliproject, fusionForge, launchpad (ubuntu entre autre), sourcesup (héberge-ment pour la communauté ESR mais pas signé par INRA, quoiqu’on puisses’identifier par LDAP INRA).

26.1 Définition

-> Outil collaboratif pour les développeurs pour construire un logiciel.-> Communauté des utilisateurs peuvent accéder aux sources et à la doc-> Met en oeuvre un outil web-> Mais : ce n’est pas un outil de gestion de projet (pas GANTT ou autre)

quoique de plus en plus de forge mettent certains indicateurs en place

26.2 Fonctionnalités

- Fonctionnalités projet : description, fonctionnalités, utilisateurs, ...On peut administrer le projet sous différents angles, telles que la visi-

bilité, le mode de partage, l’organisatoin par catégories ou des groupes dedéveloppeurs (rôles). On fait également des choix d’outils tel que le gestion-naire de version. On peut voir les activités du projet.

Défauts : souvent trop de fonctionnalités.

Fonctionnalité projet - Visualisation du code source et les changements àchaque commit.

- “bug tracker” afin de prendre en compte les problèmes.- gérer les tâches (même principe que le bug tracker).- doc est également en place, qu’on peut éventuellement versionner.- Outils de com sont à disposition, tels que sondages, admin, différents

forums, mailing-list, wiki.- gestion des releases- gestion des packages

78

CHAPITRE 26. FORGE ? 79

Fonctionnalités utilisateur - connexion ssh- annuaire compétences- user rating, activité des équipes- surveillance des tâches (suivi précis d’une tâche)

26.3 Forges utilisée dans l’ESR

SourceForge, INRIA, SourceSup, forges CNRS, à l’INRA : MulcyberPlus récemment : redmine (gérée par CATI GA)

Mulcyber 2005 : outil mise en place :gForge , 2007 mutualistaion sur MIA,groupe élargi. 2008 : gestion du service par le CIAM, 2009 : migration versFusionForge.

caractéristiques : gestionnaire de code, doc, fichiersbug tracker, activités, sondage, annonces120 projets actuellement, l’outil est stable et robuste. Héberge le projet

RECORD.

Action PEPI roadmap de l’évolution des outils à faire, spec ergonomiques,mise en place des supports et documentations. Idée : compagnonnage dansles unité.

Onzième partie

CDSI : Pepi /Cati - Bilan

80


ISABELLE BLANC (CDSI INRA)Rappel :- Les PEPI sont nés des souhaits des CATI, et sont construits par les infor-

maticiens. Il y a 70 personnes dans les bureaux PEPI sur 550 informaticiens.- Sur CATI/PEPI : les CATI ne sont pas spécialisés sur un métier, contraire-

ment aux PEPI. Ils sont transverses. L’idée est de capitaliser la connaissancede chacun.

- Il faut repérer les acteurs pour pouvoir échanger correctement- Le CDSI est promoteur de l’action, et souhaiterait un annuaire de com-

pétence nationnal, par PEPI- Le PEPI n’est pas qu’une formation

26.4 Bilan PEPI

Il y 7 PEPI créés. Ce n’est pas un modèle hierarchique, on peut adhérer àplusieurs PEPI. On doit se positionner dans plusieurs PEPI. Les PEPI 2IC etAdmin sys vont fusionner. Voir si on ne peut pas fusionner IDL avec Gestionde projet.

Dans le support : information complémentaires.Le meilleur fonctionnement est celui de 2IC (mais démaré plus tôt).

26.5 CATI

- Décret 1971 - prime info = CATI => création en 2008 pour préserver cetteprime.

Pour 2012, la prime informatique n’est plus le sujet pour le renouvellement.Dorénavant, l’attribution de la prime se fait par un examen spécifique (2 foispar an).

Mise en place du CDSI à l’INRA : conseil qui produit un certains nombrede travaux dont les CATI et l’évaluation de l’informatique de l’institut.

L’évaluation des Cati à été faite (disponible sur le site de la présidence).Les responsables ont produits un bilan, il y a eu un échange entre le groupeet les CD pour produire ce rapport.

26.6 Bilan

- isolement des informaticiens, non-reconnus.- problème de valorisation : publier - pas forcément dans une revue scien-

tifique - ses productions, surtout logicielles- Amorce d’outils transversaux inter-unité- Les responsables CATI commes experts- Contribution à l’émmergence des PEPI


26.7 Point à améliorer

Tension forte entre projets Cati et projet Unité : quelle contribution dansquelles mesures. Mais le pilotage n’a pas été suffisant sur les projets doncpeu ont émergé.

Difficulté dans l’affection de temps aux Cati.Qui est le dept pilote ?Peu d’échanges entre CatisEparpillement des PRI dans les Cati - laissé pour comptePeu de productions CATI : c’est la sommes des production des unités

26.8 Futur

Les CATI modalité de la production informatique : mais plus près des pro-jets des unités.

Cati regroupent l’ensemble des métiers informatiques utiles à sa produc-tion. Il doit y avoir plusieurs métiers de l’informatique au sein des Cati.

Les CATI 2e génération seront décidés par les CD.Les CATI sont “centré objet” : finalité explicite, service défini.Ils doivent garder la connexion et mutualisation des productions.Modalité d’application spécifiques aux projets.GouvernanceEngagement à l’amont des départements : dialogue entre CD et DU sur

les sujets pour éviter les tensions.Notion d’objet-centré : centraliser l’affectation des moyens.DémarcheProduction actuelle du groupe mission :- un contour objet des futur CATI (ex. outils pour gestion des cheptels)- proposition de gouvernanceCalendrierMars : lancement des candidaturesHomologation fin juin 2012

ECOLE PEPI IDL - 5 au 9/12/2011 -...

Documents

Transcript of ECOLE PEPI IDL - 5 au 9/12/2011 -...