Index of /GestionProjetInfo/Génie Logiciel

Icon  Name                    Description
[PARENTDIR] Parent Directory        
[DIR] Cycle en V/             
[DIR] Historique/             
[DIR] Mythes et Règles d Or/ 
[DIR] Quelques cours/         
<style>
#contenu h1 { padding: 2px 10px;}
#contenu h1>* { background-color: rgba(255, 238, 221, 0.8);margin: 0 10px;padding: 0 10px;border: 2px solid #114499;} 
</style>
<h1><span>Génie Logiciel</span></h1>

<style>
#contenu dl dt { padding-top:6px;padding-bottom:2px;text-decoration:underline;color: #114499;} 
#contenu dl:after, #contenu dt:before {clear:both; content:' ';display:block; text-decoration:none; }
</style>

<dl>

<dt>Qu'est-ce que le <b>génie logiciel</b> ?</dt>
<dd>C'est l'<em>l'ingénierie du logiciel</em>, 
c'est-à-dire l'organisation professionnelle de la conception et du développement informatique. 
</dd>

<dt>Qu'apporte le <b>génie logiciel</b> ?</dt>
<dd>Une assurance de qualité, de pérennité, d'adéquation entre le besoin du client et le logiciel produit, 
le respect des délai et des coûts... 
Voir le <a href="http://manu40k.free.fr/CoursGenieLogiciel.pdf">
support de cours de l'ESISAR de E. Chenu</a>, pour qui 
un bon logiciel bien fait est un logiciel
<ul><li> correct,
</li><li> robuste,
</li><li> extensible,
</li><li> compatible avec d’autres logiciels,
</li><li> efficace,
</li><li> portable,
</li><li> facile à utiliser,
</li><li> ponctuel et
</li><li> avec un code réutilisable.
</li></ul>
</dd>

<dt>En quoi ça consiste ?</dt>
<dd>Il s'agit 
<ul><li> d'appliquer des techniques (outils et formalismes, dits de Génie logiciel)
</li><li> et d'organiser le développement de logiciels dans un <b>processus</b> 
(« <em>Ensemble d’activités coordonnées et régulées, en partie ordonnées, 
dont le but est de créer un produit. </em>»)
</li></ul>
L’ordre et la manière d’enchaîner les étapes d’un développement 
est le <b>processus de développement</b> ou, autrement dit, son <b>cycle de vie</b>.
<br /> Analogie: « Diviser pour régner. » : 
un processus définit un enchainement d’activités 
pendant lesquelles on traite des problèmes différents.
</dd>

<dt>Pourquoi parle-t-on de cycle de vie du logiciel ? </dt>
<dd>
La notion de cycle de vie (datant de 1970) résulte de la prise de conscience 
du fait que le développement de logiciel n'est pas simplement l’écriture de programmes 
sur une durée variant de quelques heures à quelques jours. 
C'est un processus beaucoup plus complexe auquel on applique le vieil adage diviser pour régner, 
qui permet de le maîtriser en le divisant en sous- tâches.
</dd>
<dd>
Le cycle de vie du logiciel débute à l'analyse du problème, 
comprend le processus complet du développement (création) et dure 
tant que le logiciel est maintenu en exploitation. 
Pendant l'étape de maintenance, le logiciel peut être amené à évoluer selon les besoins, 
auquel cas on recommence un petit processus de développement pour réaliser les modifications. 
Une refonte majeure met fin au cycle de vie courant et en redémarre un nouveau.
</dd>
<dd>
Un cycle de vie se décompose en deux grandes phases: la <b>construction</b> et la <b>maintenance</b>. 
Celle-ci permet une utilisation optimale du logiciel 
et donne lieu à des phases de construction de peu d'importance: 
constructives ou évolutives. 
En pratique, c'est la phase qui coûte le plus cher, non parce que c'est la plus longue, 
mais parce que les phases précédentes n'aboutissent pas toujours complètement 
à ce qu'elles devraient. 
La cause de ces inadéquations est la faiblesse des méthodologies disponibles pour ces phases.
</dd>


<dt>Quels sont les problèmes à résoudre ?</dt>
<dd>
<table><tr>
<th>Quoi ?</th>
<td>
Qu’est-ce que le logiciel doit faire ?
Comment s’assurer qu’il fait bien ce qu’il doit faire ?
Le logiciel fait-il ce qu’il doit faire ?
Comment s’assurer qu’on développe le bon logiciel? A-t-on développé le bon logiciel ?
</td>
</tr><tr>
<th>Comment ?</th>
<td>
Comment organiser et construire le logiciel pour qu’il fasse ce qu’il doit faire ?
Comment s’assurer que le logiciel est organisé et construit de manière à faire ce qu’il doit faire ?
Le logiciel est-il organisé et construit de manière à faire ce qu’il doit faire ?
Comment traduit-on cette organisation en code source? Le code source est-il bien écrit ?
</td>
</tr></table>
</dd>


<dt>Que doit décrire une activité ?</dt>
<dd>Les activités d’un processus sont souvent décrites en termes de:
<img src="Génie Logiciel/_images/GL-activite.png" style="width:320px;float:right" />
<ul><li> <b>Entrées</b> de l’activité (<i>matière première</i>)
</li><li> <b>Sorties</b> de l’activité (<i>résultat</i>)
</li><li> <b>Intervenants</b> et <b>rôles</b> (<i>qui</i>)
</li><li> <b>Description</b> de l’activité (<i>quoi</i> – quel est le problème à traiter?) 
</li><li> <b>Standards</b>, guides, meilleures pratiques (« best practices ») à appliquer (<i>comment</i>)
</li></ul>
</dd>

<dt>Quelles sont les activités les plus courantes et les problèmes traités ?</dt>
<dd>
<img src="Génie Logiciel/_images/phases-cycleDeVie.png" style="width:420px;float:right" />
<table ><tr>
<td>
<b>Spécifier</b>
<br /> Qu’est-ce que le logiciel doit faire?
<br /> Comment s’assurer qu’il le fait?
<br /> Comment s’assurer qu’on développe le bon logiciel?
</td><td>
<b>Valider</b>
<br /> Le logiciel fait-il ce qu’il doit faire? 
<br /> Développe-t-on le "bon" logiciel?
</td>
</tr><tr>
<td>
<b>Concevoir</b>
<br /> Comment organiser le logiciel pour qu’il fasse ce qu’il doit faire?
<br /> Quelles choix techniques faut-il faire pour que le logiciel fasse ce qu’il doit faire?
<br /> Le logiciel est-il organisé et construit de manière à faire ce qu’il doit faire?
</td><td>
<b>Intégrer</b>
<br /> Comment s’assurer que le logiciel est organisé et construit de manière à faire ce qu’il doit faire?
</td>
</tr><tr>
<td>
<b>Coder</b>
<br /> Comment traduit-on cette organisation en code source?
</td><td>
<b>Tester unitairement</b>
Le code source est-il bien écrit?
</td>
</tr></table>
</dd>

<dt>Quels facteurs influent sur la réussite d'un projet ? </dt>
<dd>
L'aspect fonctionnel du développement du logiciel n’est pas le seul facteur de réussite d’un projet.
D'autres facteurs tels que l’animation d'une équipe, 
la confiance que la direction de l’entreprise accorde au chef de projet, 
ont aussi une grande importance. En effet, une équipe est organisée hiérarchiquement 
et chaque membre doit assumer un certain nombre de tâches spécifiques. 
L'équipe doit comporter un responsable chargé de diviser 
et répartir les tâches entre les groupes, de vérifier leur avancement et de les coordonner. 
Elle doit comporter aussi un rapporteur (librarian) 
qui assure la documentation de l'ensemble des décisions prises et des travaux accomplis.
</dd>

<dt>Existe-t-il des formes-type de processus de développement ?</dt>
<div style="text-align:center;">
<img src="Génie Logiciel/_images/cycleV-dessin.png" style="width:486px" />
<img src="Génie Logiciel/_images/cycleV-schema.png" style="width:400px" />
</div>
<dd>
A ce jour, le <b>cycle en V</b> reste le cycle de vie le plus utilisé.
Il est organisé en phases de développement, associées à des activités.
<br /> C’est un cycle de vie orienté test:
<ul><li> A chaque activité créative (spécification, conception et codage) correspond une activité de vérification (validation, intégration, tests unitaires).
</li><li> La vérification est prise en compte au moment même de la création.
</li></ul>
</dd>
<div style="text-align:center;">
<img src="Génie Logiciel/_images/cycleV-dessin.png" style="width:486px" />
<img src="Génie Logiciel/_images/cycleV-schema.png" style="width:400px" />
</div>

<dt>Par exemple, comment décrire l'activité <i>Spécifier</i> ? </dt>
<dd>
<div style="text-align:center;float:right;">
<img src="Génie Logiciel/_images/decompositionSpecifLog.png" style="width:286px" />
</div>
<table><tr>
<th>Activité</th><th> Spécifier</th>
</tr><tr>
<th>Description</th>
<td> 
Décrire ce que doit faire le logiciel (comportement en boite-noire). 
Décrire comment vérifier en boite-noire que le logiciel fait bien ce qui est exigé.
</td>
</tr><tr>
<th>Entrées</th>
<td> 
Client qui a une idée de ce qu’il veut.
</td>
</tr><tr>
<th>Sorties</th>
<td> 
Une spécification (description des besoins du client).
Des procédures de validation.
</td></tr></table>
Une spécification peut suivre de nombreux formalismes: cas d’utilisation, modèles UML, user-stories, exigences ...
Les procédures de validation peuvent être des procédures manuelles ou des tests.
</dd>


<dt>Le cycle en V est-il parfaitement efficace ?</dt>
<dd>
Le cycle en V est-il adapté pour : 
<table><tr>
<td><i><b>Bien construire</b> le logiciel</i> ?  </td>
<td>
Les choix techniques (spec, conception, codage) sont validés très (trop) tard par test.
<ul><li> Beaucoup de choix techniques sont pris sans disposer d’information concrète (prise de risques).
</li><li> Il faut attendre longtemps pour savoir si on a bien construit le logiciel.
Le logiciel est utilisé très (trop) tard.
</li><li> 
</li></ul>
</td>
</tr><tr>
<td><i>Construire le <b>bon logiciel</b></i> ? </td>
<td>
Il faut attendre longtemps pour savoir si on a construit le bon logiciel.
<br /> Difficile d’impliquer les utilisateurs 
lorsque qu’un logiciel utilisable n’est disponible qu’à la dernière phase ...
</td>
</tr></table>
<div style="text-align:center;">
<img src="Génie Logiciel/_images/cascadeV-inconvenients.png" style="width:500px" />
</div>

</dd>

<dt>Y a-t-il des alternatives au cycle en V ?</dt>
<dd>
Le cycle itératif et incrémental est né en
réaction aux faiblesses du cycle en V.
<br /> Analogie: « Un tiens vaut mieux que deux tu l’auras. » : 
Développez de petits incréments fonctionnels livrés en courtes itérations.
<br />Les phases sont remplacées par des activités associées à un <b>incrément fonctionnel</b>.
<br />Un incrément fonctionnel est un besoin du client
</dd>
<div style="text-align:center;">
<img src="Génie Logiciel/_images/cycleVvsIterInc-dessin.png" style="width:620px" />
<img src="Génie Logiciel/_images/cycleVvsIterInc-postits.png" style="width:620px" />
<img src="Génie Logiciel/_images/cycleVvsIterInc-missils.png" style="width:620px" />
</div>

<dt>Quels sont les avantages du cycle incrémental et itératif ?</dt>
<dd>
<ul><li>Les choix techniques (spécification, conception, codage) sont validés très tôt par test.
<br /><i>L’enchainement des itérations permet de régulièrement vérifier 
que l’on construit bien le logiciel.</i>
</li><li>Le logiciel est utilisé très tôt.
<br /><i>L’enchainement des itérations permet aux utilisateurs de vérifier régulièrement 
que l’on construit le bon logiciel.</i>
</li></ul>
</dd>

<dt>Quelles incidences sur la mise en œuvre du processus ?</dt>
<img src="Génie Logiciel/_images/GL-iterFonctionnelle.png" style="width:380px;float:right" />
<dd>
Pour chaque version à développer après la 1ère
version livrée, il faut arbitrer entre:
<ul><li> les demandes de correction,
</li><li> les demandes de modification et
</li><li> les nouvelles fonctionnalités à développer.
</li></ul>
Comment arbitrer?
<ul><li> Il est malsain de vivre avec des défauts identifiés (ou pas ...)
</li><li> Ajouter des fonctionnalités sur un code que l’utilisateur souhaite modifier entrainera des changements en cascade.
</li><li> Laissez le client choisir ...
</li></ul>
</dd>

<dt>Que met-on dans un incrément?</dt>
<dd> 
Il s'agit de Piloter le développement par les <b>besoins du client</b> : 
<ul><li> Chaque <i>Fonctionnalité du produit</i> correspond à un Besoin du client.
</li><li>Les besoins peuvent être exprimés par des <b>exigences</b>, 
des cas d’utilisation, des scénario, etc ...
</li><li>Il s'agit de laissez le client piloter.
</li></ul>
</dd>
<div style="text-align:center;">
<img src="Génie Logiciel/_images/cycleIterInc-iteration.png" style="width:620px" />
</div>

<dt>Dans quel ordre faut-il réaliser les itérations ?</dt>
<dd>Il s'agit de Piloter le <b>développement par les priorités</b> : 
d'abord les fonctionnalités les plus importantes pour le client et les plus risquées.
<br /> Conseil pratique : Pensez à la règle des 80/20! Voir
<a href="http://fr.wikipedia.org/wiki/Principe_de_Pareto">http://fr.wikipedia.org/wiki/Principe_de_Pareto</a> 
(80% du résultat est produit par 20% de l'effort)
</dd>

<dt>Comment savoir qu’une itération est terminée ?</dt>
<dd> Il s'agit de Piloter le développement par les <b>tests d’acceptation</b> : 
<ul><li> Ecrivez des tests automatisés d’acceptation.
</li><li>Utilisez ces tests pour mesurer l’avancement du développement.
</li><li>Il n’y a pas de meilleure mesure de l’avancement 
que les fonctionnalités s’exécutant conformément aux besoins du client.
</li><li>Une fonctionnalité s’exécute conformément au besoin du client 
si elle réussit ses tests d’acceptation.
</li><li>Les tests d’acceptation sont ceux qui font le plus avec le moins.
</li></ul>
</dd>

<dt>Comment construire bien et sans régression ?</dt>
<dd>Il s'agit de Pilotez le développement par les tests : 
<ul><li> Développez en cycles très courts: ajoutez un test qui échoue, 
puis faites le réussir.
</li><li> Dès qu’un bug est détecté, commencez par écrire un test qui révèle le défaut.
</li><li> Écrire les tests avant le code est un outil de conception: 
cela conduit à une conception plus pragmatique, plus simple et moins couplée.
</li><li> Assurez vous que l’exécution des tests est automatisée, 
qu’ils vérifient leurs propres résultats et sont jouées par un outil d’intégration continue 
sur toutes les plateformes et pour tous les environnements visés.
</li></ul>
<p>Conseil pratique : Les tests sont destinés à éviter les défauts, pas les trouver!</p>
Il s'ait aussi d 'Intégrer continuellement, et donc le plus tôt possible 
<ul><li>Entretenez tôt et toujours une version du logiciel 
qui soit compilable, testable, livrable, installable 
et comprenant les tous derniers développements.
</li></ul>
<p> Conseil pratique : Évitez les stocks, préférez le flux tendu.</p>
</dd>
<div style="text-align:center;">
<img src="Génie Logiciel/_images/cycleIterInc-IntegContinue-dessin.png" style="width:520px" />
<img src="Génie Logiciel/_images/cycleIterInc-continuousFeedback-dessin.png" style="width:520px" />
<img src="Génie Logiciel/_images/cycleIterInc-stopTheLine.png" style="width:420px" />
</div>

<dt> Et la méthode <b>Agile</b> ?</dt>
<dd>Elle repose sur le <b>Manifeste Agile</b> qui s'appuie sur 4 valeurs : 
<ul><li> Les personnes et les interactions plutôt que les processus et les outils.
</li><li> Un logiciel opérationnel plutôt qu’une documentation exhaustive.
</li><li> La collaboration avec le client plutôt que la négociation du contrat.
</li><li> Réagir au changement plutôt que le suivi d'un plan.
</li></ul>
et 12 principes : 
<ul><li> Notre priorité est de satisfaire le client par des livraisons rapides et continues de logiciel utile.
</li><li> Intégrer les changements aux exigences même s’ils arrivent tard dans le processus de développement. Les méthodes Agiles intègrent rapidement les changements de façon à offrir un avantage compétitif au client.
</li><li> Livrer fréquemment du logiciel opérationnel, soit à toutes les quelques semaines ou quelques mois en visant de courts délais.
</li><li> Les clients et les développeurs doivent travailler main dans la main quotidiennement tout au long du projet.
</li><li> Élaborer des projets autour d’individus motivés. Leur procurer l’environnement et le support nécessaire et leur faire confiance pour réaliser le travail.
</li><li> La façon la plus efficace de transmettre l’information à une équipe et entre les membres est par des conversations en face à face. Le logiciel opérationnel est la principale mesure de progrès
</li><li> Agile favorise le développement à rythme "normal".
</li><li> Les gestionnaires, développeurs et utilisateurs devraient être en mesure de maintenir un rythme constant et ce, indéfiniment.
</li><li> Porter une attention continue à l’excellence technique et à un bon design améliore l’agilité.
</li><li> La simplicité - l’art de maximiser la quantité de travail non fait - est essentielle.
</li><li> Les meilleures architectures, exigences et designs prennent naissance dans des équipes qui se gèrent elles- mêmes.
</li><li> Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et modifie son comportement en conséquence.
</li></ul>
</dd>

<dt> Et l'<b>eXtreme programming</b> (programmation extrème - XP) ?</dt>
<dd>
C'est une démarche technique (Méthode de développement logiciel)
qui prend en compte la gestion de projet. 
<br />
Elle recherche l'efficacité maximale en concentrant l'effort de travail 
sur l'objectif de développer vite et juste.
<br />
La démarche est légère, pragmatique, disciplinée, empirique et adaptative.
Elle repose sur les valeurs: 
<ul><li> Communication 
</li><li> Simplicité
</li><li> Retour d'information 
</li><li> Courage
</li><li> Respect
</li></ul>
</dd>



</dl>

<p class="signature" style="text-align:right;font-size:80%;font-style:italic;"> Ce contenu est largement inspiré 
du <a href="http://manu40k.free.fr/CoursGenieLogiciel.pdf">support de cours de E. Chenu</a>
pour l'ESISAR. 
<br />Quelques copies d'écran viennent du support de cours de
<a href="http://fr.scribd.com/doc/71602951/03-Slides-GL-2010-Site">http://fr.scribd.com/doc/71602951/03-Slides-GL-2010-Site</a>
de Ilhem Boussaid.
<br /> Quelques parties du textes et des images sont extraites 
du livre de <a href="http://cui.unige.ch/Levrat/ch2.pdf">Cours de Génie Logiciel</a>
de B. Levrat.
</p>