Le document traite du génie logiciel, qui est une discipline scientifique axée sur les meilleures pratiques et méthodes pour développer des logiciels de qualité. Il aborde son historique, les processus de développement incluant l'analyse des besoins, la conception, la construction, les tests et la maintenance, ainsi que les modèles de génie logiciel tels que le modèle en cascade et le modèle en spirale. Enfin, il présente le schéma directeur informatique comme un outil de planification stratégique pour l'évolution des systèmes d'information d'une entreprise.

1. LE GÉNIE LOGICIEL
Niveau : DSI 2
Lycée Technique
Brevet de technicien supérieure

2. DÉFINITION
Le génie Logiciel (anglais software engineering) :
est une science qui étudie les méthodes de travail et
les bonnes pratiques des ingénieurs qui
développent des logiciels. Le génie logiciel
s'intéresse en particulier aux procédures
systématiques qui permettent d'arriver à ce que des
logiciels de grande taille correspondent aux
attentes du client, soient fiables, aient un coût
d'entretien réduit et de bonnes performances tout
en respectant les délais et les coûts de construction

3. DÉFINITION
Ensemble de moyens (techniques, méthodes)
mis en œuvre pour la construction de
logiciels ou système informatique.

4. HISTORIQUE
La notion de génie logiciel a été mentionnée
pour la première fois à une conférence concernant
la crise du logiciel en 1968. La crise du logiciel est
une baisse significative de la qualité des logiciels.

5. Maitrise
d’ouvrage
(MOA)
Maitrise
d’oeuvre
(MOE)

6. PROBLÈMES
RENCONTRÉS
• l'augmentation de la puissance de calcul des
ordinateurs qui a permis de réaliser des logiciels
beaucoup plus complexes qu'auparavant.
• Temps d’exécution
• Coûts élevés
• Fiabilité
• Respect des besoins fonctionnels
• …

7. BUTS ET AVANTAGES DU
GÉNIE LOGICIEL
Buts :
• Adéquation et correspondance aux besoins de l’utilisateur.
• Fiabilité : fonctionnement sans pannes.
• Coût : raisonnable et défini.
• Modification : ni complexe ni couteuse.(gain de temps)
• Ponctuation Livraison dans les bons délais.
• Portabilité.
• Efficacité: bonne utilisation des ressources.

8. Fiabilité de
maintenance
Cout de
production
Fiabilité
Efficacité
Ponctuation
Relation Secondaire
Relation Essentielle

9. BUTS ET AVANTAGES DU
GÉNIE LOGICIEL
Avantages:
• Aide a réaliser des application aux utilisateurs
• Diminuer les coûts
• Éviter les retards
• Gérer les risques
• Rendre l’activité de conception d’un logiciel comme un travail
d'ingénierie
• Permettre à l’équipe d’avoir un vocabulaire Standard (Normes
IEEE1074 et ISO 9126)

11. CYCLE DE VIE D’UN
LOGICIEL
Analyse des
besoins
Conception
Construction
Tests
Maintenance
Gestion des
projets
Outils et
méthodes
Gestion de
qualité
Gestion de
configuration

12. ANALYSE
DES
BESOINS
• Elle Consiste à récolter des informations détaillées
concernant l'éventail de fonctions que devra offrir le
logiciel, ainsi que les résultats qu'il devra donner. Des
connaissances du domaine d'activité du
logiciel (exemple: banque, industrie, administration)
facilitent le travail de l'ingénieur.

13. LA CONCEPTION
• Consiste à déterminer et schématiser les grandes lignes des
mécanismes qui devront être programmés en vue d'obtenir chacune
des fonctions que devra offrir le logiciel.Des plans conceptuels du
logiciel selon les formalismes de modélisation (UML par exemple)
seront alors réalisé. C'est également à cette étape que l'utilisation de
Patrons de conception logiciel sont appliqués afin de résoudre
certains problèmes de conceptions communs. Le recours
à l’architecture logiielle pourra également être effectué.

14. LA
CONSTRUCTION
Elle Consiste à la rédaction du Code source, des
instructions de programme qui offriront les
fonctions attendues, et qui sont le corps du
logiciel. La programmation est alors effectuée en
suivant les plans initialement établis lors de la
conception. Selon la méthodologie choisie (ex:
itératif), les ingénieurs pourront retourner sur les
planches a dessin afin d'ajuster la conception avec
la réalité de la construction.

15. LES TESTS
• C’est Une suite de vérifications faites par les ingénieurs qui
servent à déceler un maximum de bugs, des défauts de
programmation qui provoquent des pannes ou des résultats
incorrects. La validation est un examen réalisé par le client
durant lequel il vérifie que les fonctions offertes par le logiciel
correspondent à ses attentes et à ses besoins.

16. LA MAINTENANCE
Ce sont des opérations d'analyse, de
programmation et de test réalisés après coup, une fois
que le logiciel a été mis à disposition des utilisateurs et
durant lesquelles le logiciel subit des transformations,
des corrections ou des améliorations. La facilité de cette
maintenance dépendra de l'importance qui lui a été
accordé durant la phase de conception.

17. LA GESTION DE PROJETS
C’est une activité réalisée tout au long des travaux sur le
logiciel, qui consiste à organiser une équipe d'ingénieurs,
répartir les tâches et veiller à l'avancée des travaux en vue de
finir dans les délais prévus. C'est une activité
de management également exercée dans d'autres domaines
d’ingenieurs.

18. LES OUTILS ET MÉTHODES
• Sont Les thématiques du génie logiciel recouvrent notamment
les outils et méthodes de spécification de fonctionnalités d'un logiciel, les
méthodes formelles (Méthode B par exemple), les outils et les méthodes
de conception de logiciel, les outils de conception, atelier logiciel,
Ingénierie des modèles kermeta par exemple, l'automatisation de
l'optimisation du code.
• D'autres domaines sont connexes au génie logiciel dans la mesure où ils
partagent des outils communs : description formelle du
code, grammaire des langages manipulés. Ces domaines sont par
exemple :

19. LES OUTILS ET METHODES
• la compilation ;
• L’interprétation de code ;
• la traduction de code d'un langage de programmation vers un autre.
• un éditeur dédié au langage de programmation
• les bibliothèques de composants
• les outils de planification
• un outil de gestion des exigences pour développer et gérer les exigences
relatives au code produit
• un outil de gestion des configurations pour contrôler les évolutions du code
produit
• des moyens de tester pour vérifier la conformité du code produit
• des outils de génération de métriques pour caractériser la conformité du code
produit

20. LA GESTION DE LA QUALITÉ
• Bien que l'on passe du génie de la production à celui
de la décision, ces domaines ont un impact tellement
important sur l'activité de génie logiciel qu'ils doivent
être mentionnés:
• La Gestion de la Qualité permet de contrôler
l'organisation de la production du code.
• La qualité repose sur des méthodes.
• Le management est un modèle et un moyen humain
qui a pour but d'améliorer la production.

21. LA GESTION DE LA
CONFIGURATION
• Elle permet de contrôler les évolutions du code produit et les différentes
versions du produit.

22. LES MODÈLES DE GÉNIE
LOGICIELS
• Il existe plusieurs modèles :
• Le modèle en cascade
• Le Modèle Evolutif
• Le modèle en V
• Le modèle tridimensionnel
• Le modèle incrémentale
• Le modèle en spirale

23. LES MODÈLES DE GENIE
LOGICIELS
• Le choix se fait selon plusieurs critères :
• La taille du projet
• La durée du projet
• La maitrise des technologie utilisées
• L’expertise de l’équipe
• La connaissance du domaine …

24. LE MODÈLE EN CASCADE

25. LE MODÈLE EN CASCADE
• Mis au point en 1966
• Formalisé en 1970
• Chaque phase doit se terminer pour commencer la suivante
• Caractéristiques :
• La production de documents entre chaque phase améliore le suivi du
projet.
• Lorsqu’une erreur a été commise dans une phase et qu’elle est détectée
dans une phase suivante, il faut faire remonter cette information dans
la phase incriminée et recommencer le processus à partir de celle-ci.
On doit alors reproduire de nouveaux documents . . .

26. LE MODÈLE
EN CASCADE
• Ce modèle de processus impose donc une
importante réflexion sur les choix faits en amont
car le coût de la correction d’une erreur est
important.
Critiques :
• Le modèle en cascade rend coûteux le
développement itératif puisque la rédaction des
documents de validation de chaque phase
demande beaucoup de travail.
• Ce modèle est inadapté au développement de
systèmes dont la spécification est difficile à
formuler a priori.

27. LE MODÈLE EN V
Définition des
besoins
Conception du
Système
Teste du Système
Conception des
composants
Codage des
composants
Testes des
composants
Validation

28. LE MODÈLE EN V
C’est l’un des modèles les plus connus il permet le teste des
composants et du système pour valider comme il peut être
utilisé dans les application complexes.

29. LE MODÈLE EN V
• Critiques:
• Demande beaucoup de temps pour arriver a la phase
de validation.
• Très couteux en cas d’inadaptation avec les besoins
initiaux.

30. LE MODÈLE EN
SPIRALE

31. LE MODÈLE EN SPIRALE
• Proposé par Bhrem en 1988
• Se base sur plusieurs cycles se déroulant en 4 phase.
• Avantages :
• Validation sure par l’utilisateur.
• Découverte des anomalie plus tôt.
• Réduction du temps d’attente des utilisateur et
maintient de leur motivation

32. LE MODÈLE EN SPIRALE
• Inconvénients :
• Mise en œuvre couteuse

33. LE MODÈLE ITÉRATIF

34. LE MODÈLE ITÉRATIF
• Il est basé sur l’itération et le feed back
systématique.
• Il permet :
• d’ajuster les besoins.
• Apprentissage appliqué progressivement
• Contrôle de compléxité.

35. LE SCHÉMA DIRECTEUR
• Pourquoi un Schéma Directeur ?
• Diagnostique >> Remède
• Prospectives >> Plan de Progrès

36. LE SCHÉMA DIRECTEUR
DOCUMENT . RÉALISÉ PAR LA
DIRECTION
INFORMATIQUE.
VALIDÉ PAR LA
DIRECTION GÉNÉRALE.
REPOSE SUR
L’IDENTIFICATION D’UN
EXISTANT ET DE
BESOINS FUTURS.

37. LE SCHÉMA DIRECTEUR
Le SDI est aussi un outil de planification et
d’arbitrage qui, par différents moyens, permet de
préparer les investissements informatiques sur la
période concernée mais également pouvoir de
réagir face à l’imprévu.

38. LE SCHÉMA
DIRECTEUR
Un Schéma Directeur
Informatique est un document
conçu pour préparer l’évolution et
l’adaptation de l’environnement
informatique d’une entreprise (ou
d’une administration) pendant
une période donnée
(généralement de 2 à 5 ans).

39. LES
FONCTIONS
DU SDI
• Sur Trois niveaux :
• DG : Direction générale.
• DSI
• Utilisateur.

40. LES FONCTIONS DU SDI
(DG)
• Le SDI est le moyen de consigner les choix stratégiques
informatiques de l’entreprise et de les confronter à l’existant,
aux moyens disponibles, à des échéances.

41. LES FONCTIONS DU SDI (DG)
• L’élaboration d’un SDI est le moment idéal pour mener, au niveau de la
direction, une réflexion approfondie sur l’informatique au sein de
l’entreprise : quelles sont les directions à donner ? quels sont les
résultats à attendre ? quels sont les moyens à investir ?

42. LES FONCTIONS DU SDI (DSI)
• Le SDI permet de spécifier les missions et moyens confiés à la DSI et
DSI d’effectuer, en fonction de cela, une planification globale des projets
et investissements.
• Il est ainsi possible de réaliser une planification des chantiers prévus sur
la période, de déterminer des méthodes d’arbitrage de nouveaux projets
arrivant en cours de période, de définir des systèmes cibles.

43. LES FONCTIONS DU SDI (DSI)
• Le SDI doit permettre à la DSI de pouvoir à la fois anticiper les aspects
stratégiques, opérationnels, technologiques des projets, mais également
les aspects budgétaires.
• Enfin, sur l’angle « organisation », le SDI permet une planification de la
charge de travail de la DSI et la préparation des ressources requises pour
la réalisation des projets

44. LES FONCTIONS DU SDI
(UTILISATEUR)
• l’occasion d’exprimer leurs attentes.
• A l’issue de l’élaboration du SDI, celui-ci présentera une
classification des besoins identifiés auprès des utilisateurs et
des solutions envisagées.
• permettre aux utilisateurs de constater qu’ils sont traités en
parfaite équité vis-à-vis des moyens informatiques qui leur
sont consacrés.

45. CONTENUE
D’UN SDI
• Il n’y a pas de SDI type.
• Il y a de nombreux paramètres :
• le type d’entreprise concernée
• l’environnement de l’entreprise
• Les métiers concernées
• la place réservée à l’informatique
• l’organisation Direction-DSI-utilisateurs…

46. CONTENUE D’UN SDI
• Éléments communs à tous les SDI:
• Présenter un existant, un point de départ.
• consigner les missions et les moyens accordés à la DSI
• intégrer des objectifs stratégiques et opérationnels
• présenter les méthodes de travail
• présenter un ensemble de projets
• offrir un cadre de référence intelligent et adaptable

47. CONTENUE D’UN SDI
 Présenter un existant, un point de départ.
 l’étude des besoins et la définition de systèmes cibles devront être
faites après un état des lieux.
 Le SDI doit intégrer une présentation de l’existant (architecture
technique, fonctionnelle, organisationnelle), des précédents axes
stratégiques (période précédente), de l’organisation interne.
 les forces et faiblesses de l’entreprise (sur le plan informatique)doivent
être évoquées

48. CONTENUE D’UN SDI
 consigner les missions et les moyens accordés à la DSI
• Il joue le rôle de « contrat de mission » entre la direction
générale et la DSI.
• Ainsi, la direction a une vision précise des investissements
réalisés mais également de missions à attendre (en proportion
des moyens accordés) de la DSI.

49. CONTENUE D’UN SDI
 intégrer des objectifs stratégiques et opérationnels
 Il est nécessaire de solliciter les différentes entités de l’entreprise pour
estimer les besoins et mener une réflexion stratégique à ce sujet.
 Sur le plan opérationnel, le SDI doit présenter en quoi les moyens
affectés et les échéances prévues sont en accord avec des objectifs
fixés et répondent réellement aux besoins identifiés

50. CONTENUE D’UN SDI
 présenter les méthodes de travail
 comment les utilisateurs sont-ils sollicités lors de lancement de
nouveaux projets ?
 quelles méthodes la DSI met-elle en œuvre pour piloter les projets
informatiques ?
 quels sont les méthodes et outil de reporting de la DSI auprès de la
direction pour suivre l’atteinte des objectifs ?
 quels sont les comités de pilotage informatique et groupes de travail
identifiés ?

51. CONTENUE D’UN SDI
 présenter un ensemble de projets
 Les besoins doivent être classés selon des priorités, les investissements
justifiés, et des systèmes cibles définis.
 Ce portefeuille de projets permet de les comparer les uns aux autres
et de les classer selon différentes vues (échéancier, risques, charge
interne, coûts, besoins en conduite du changement, etc.)
 Il doit être possible de rattacher les projets aux besoins et aux
différentes entités de l’entreprise

52. CONTENUE D’UN SDI
 offrir un cadre de référence intelligent et adaptable (1)
• dans la pratique, la planification de projets informatiques sur
une longue période est un exercice très difficile.
• Les budgets ne sont pas nécessairement prévisibles sur une
période pluriannuelle
• les projets prévus peuvent faire l’objet du retard ; des priorités
non prévues peuvent survenir ; des technologies pressenties
peuvent se révéler obsolètes ou inadaptées lors de leur mise
en oeuvre

53. CONTENUE D’UN SDI
 offrir un cadre de référence intelligent et adaptable (2)
 Le SDI doit permettre de réagir l’imprévisible en toute intelligence :
« Comment réagir si… »
 Idéalement, le SDI doit intégrer les
procédures à mettre en œuvre (réunions à
organiser, comités à solliciter) selon différents
scénarios.

54. CONTENU D’UN SDI
(CONCLUSION)
• L’élaboration du SDI est notamment l’occasion de:
• de mener une réflexion sur l’intégration de nouveaux outils de
travail ou de nouvelles technologies dans l’entreprise
• « repenser » l’organisation informatique et les méthodes
utilisées
• préparer la mise en œuvre de chantier échelonnés dans le
temps ou d’actions qui nécessitent une forte conduite du
changement (ex : mise en œuvre d’une politique de sécurité
du système d’information, ou refonte des applications métier)

55. CONTENU D’UN SDI
(CONCLUSION)
• mener des actions de formation et d’information du personnel
à tous le niveaux de l’entreprise
• communiquer sur la thématique informatique, d’organiser des
ateliers de réflexion permettant des échanges directs entre
personnes qui se rencontrent peu : l’élaboration du SDI
favorise l’échange de l’information au sein de l’entreprise et la
communication des idées.

56. CRITÈRES
DE
QUALITÉ
D'UN
SCHÉMA
DIRECTEUR

57. LES STRUCTURES DE
TRAVAIL

58. ELABORER UN SCHÉMA
DIRECTEUR
1. Comprendre et maîtriser la stratégie business
• Le SD décline les objectifs opérationnels, définis dans la
stratégie business.
• Connaitre les grands projets fonctionnels, participer au
comité de direction.

59. ELABORER UN SCHÉMA
DIRECTEUR
2. Analyser le contexte interne de l’organisation
• Cartographier les processus et infrastructures métier (ARIS).
• Définir les forces et faibles de l’organisation (SWOT)
• Maîtriser les compétences et ressources disponibles dans le
département informatique

60. ELABORER UN SCHÉMA
DIRECTEUR
3. Analyser les ressources du système d’information
• Identifier les pistes d’amélioration et les contributions
possibles à la stratégie business
• Les processus informatiques (ISO15504, TIPA)
• Les infrastructures
• Les applications (Application portfolio management)
• L’architecture fonctionnelle (flux et interactions)
• Les matériels

61. ELABORER UN SCHÉMA
DIRECTEUR
4. Identifier les opportunités et risques externes
• Tendances technologiques et méthodologiques susceptibles
d’avoir un impact sur l’organisation (Gartner ; CIO insight…)
• Compliance (ITIL)
• Les pratiques des concurrents
• les partenaires potentiels lien vers réseaux IT

62. ELABORER UN SCHÉMA
DIRECTEUR
5.Définir les orientations du SI
• Les grandes orientations du SI, axes stratégiques, ou encore lignes
directrices comprennent:
• son architecture fonctionnelle (flux, interactions…)
• son infrastructure
• ses applications
• Elles peuvent donner lieu à plusieurs scénarios.
• Les risques liés à ces orientations sont identifiés et caractérisés, de
même que les aspects réglementaires (Compliance).
Des étapes intermédiaires peuvent être envisagées pour faciliter le
pilotage du SD.

63. ELABORER UN SCHÉMA
DIRECTEUR
6. Eléments de mise en œuvre
• le SD comprend également des éléments de mise en oeuvre
des orientations, notamment :
• Liste des projets les plus critiques:
• Un facteur de criticité, outre le montant d’investissement prévu,
est l’alignement business de ces projets : la création de valeur
attendue sur le business est exprimée en termes quantitatifs et
qualitatifs.

64. ELABORER UN SCHÉMA
DIRECTEUR
6. Eléments de mise en œuvre
• Gestion du changement
• Dans un SD, le CIO est un change manager. Le SD comprend donc
les changements organisationnels et individuels induits par la
stratégie informatique sont présentés, ainsi que leur
accompagnement : besoin en nouvelles compétences techniques
et business, formations, nouveaux modus operandi…
Pour ces éléments, la coopération avec les business units est
cruciale.

65. ELABORER UN SCHÉMA
DIRECTEUR
7. Budgétiser
• Les SD et les différents projets le composant sont évalués
budgétairement. Souvent le CIO s’entoure des compétences
financières et administratives d’un économiste ou d’un
financier pour ce volet.

66. ELABORER UN SCHÉMA
DIRECTEUR
8. Faire adopter le SD
• Le CIO sensibilise la direction générale pour obtenir son
adhésion, lors d’une réunion du comité de direction. Faire
participer les business units à la conception du schéma
directeur - favorise leur adhésion et facilite son adoption au
comité de direction. La communication est un facteur clef de
succès. Il est important que le CIO « déjargonifie » son
discours pour que son message porte.
• Comme dans toute démarche de changement ; le soutien de
la direction (leadership) est un facteur clef de succès pour
réussir le schéma directeur.

67. ELABORER UN SCHÉMA
DIRECTEUR
9. Mettre en oeuvre le SD
• Piloter la mise en oeuvre des projets
• Veiller à la mise en oeuvre des processus et organes de
gouvernance
• Identifier les nouveaux projets en veillant à leur alignement
avec les grandes orientations du SI (Lien vers business case des
projets)
• Manager la qualité du service et la satisfaction des utilisateurs

68. ELABORER UN SCHÉMA
DIRECTEUR
9. Mettre en oeuvre le SD (suite)
• Piloter le département IT
• Veiller au développement des compétences nécessaires,
• Motiver les collaborateurs
• Remonter les indicateurs à la Direction:
• Réviser le SD si nécessaire :
• il doit être semi-flexible pour, d’une part, donner des grandes
lignes directrices, mais, d’autre part, permettre une certaine
souplesse et adaptabilité dans leur mise en oeuvre.

69. CONCLUSION

70. (RIAD)
• Méthode Nolan Norton
• La méthode Nolan Norton
• (GPA)
• La démarche de la méthode

71. ATELIER 1
• Contenu
• Introduction
• Partie 1
• Généralité
• Description des charges :
• Espace client :
• Espace visiteur :
• L’intérêt de projet
• Objectifs du client
• les clients ou utilisateurs potentiels
• Les principales caractéristiques attendues
• Les objectifs visés, les principales contraintes à respecter
• Opportunité du projet

72. ATELIER 1 (SUITE)
• Partie 2
• I. Outils et langages utilisés
• Langages
• Conception
• Conception de site E-commerce
• Identification des acteurs :
• Identification des messages :

73. ATELIER 1 (SUITE)
• Diagramme des classes
• Gestion des articles
• Gestion des offres & Gestion des promotions :
• Gestion des comptes & Gestion des requetes :
• Inscription & Identification :
• Gestion du caddie & Achat :
• Page d’acceuil

74. ATELIER 1 (SUITE)
• Planification & Estimation :
·Le coût
• Les taches en réalisation
• La liste des taches à réaliser
• Package achat :
• Package Produit & marketing:
• Package Client
• le diagramme de Gantt

75. ATELIER 1 (SUITE)
• Déclinaison en engagements qualité :
• Mesure de la qualité (propriétés et métriques) :
• Suivi de projet :
• Journal de bord :
• Conclusion

76. 08/12/14

77. MERISE
• Définition
• Les 3 niveaux d’abstraction
• Conceptuel (MCD MCT) Quoi?
• Logique (MLD MLT) Qui Quand Ou ?
• Physique (MPD MPT) Comment Avec Quoi ?
• Cycle d’abstraction de conception des SI
• MCD
• Clé primaire ? Cardinalités ? Oo ?
• MCT cmnt créer ?
• Courbe de soleil

78. LES OBJECTIFS DU GL

79. LES PRINCIPES DU GL

80. L’ABSTRACTION
• C’est le fait de mettre en coté certaines caractéristiques pour
n’en garder que celle qui sot Essentielles.
• Ces caractéristiques forment une vue globale que l’on a du
phénomène concérné.

81. L’ENCAPSULATION
• Masquage de l’information.
• C’est minimiser les interdependance entre les modules du
projeten dissimulant le contenu incorporé dans l’interface
externe donnée par l’abtraction.
• L’abstraction et l’encapsulation sont alors complémentaires.

82. L’ENCAPSULATION
(AVANTAGES)
• Une meilleur sécurité.
• Un e Meilleur lisibilité
• Simplicité apparente pour
l’utilisateur
• Une meilleur portabilité.

83. LA MODULARITÉ
• C’est le fait de diviser un élément en plus petits.
• Elle vise à partitionner un logiciel en unités que l’on peut
manipuler séparément mais qui peuvent être dépendantes.
• Pour avoir une bonne maintenabilité, il faut que les modules
soient faiblement couplés entre eux.

84. LA LOCALISATION
• C’est la proximité physique se rapportant à une même
abstraction.

85. L’UNIFORMITÉ
• Adopter le même style pour toute l’application en fonction
du projet et l’organisation

86. LA VALIDABILITÉ
• C’est la décomposition en modules pour faciliter les tests.

87. APPLICATION DE CES
PRINCIPES
• Un module logiciel se présente comme étant composé de
deux parties :
• Le point de vue de l’utilisateur du module.
• L’implémentation qui retient le point de vue du développeur.

88. APPLICATION DE CES
PRINCIPES

89. SCHÉMA GÉNÉRALE DE LA RÉALISATION D’UN
LOGICIEL
Etude
Préalable
Retrait
Maintenance
et assistance
Evaluation
Planification
Pilotage et suivie
Gestion de Qualité
Vérification et Validation
Gestion de la
Configuration
Développement de la
Documentation
Formation
A
C
I T
I
Initiation
du Projet
Gestion
de
Projet
Activités
Techniques
A.P Développement
Exploitation
et Maintenace Retrait
Cycle de Développement du Logiciel
Cycle de Vie du Logiciel

90. SCHÉMA GÉNÉRALE DE LA
RÉALISATION D’UN LOGICIEL
(VERSION SIMPLIFIÉE)

91. SCHÉMA GÉNÉRALE DE LA
RÉALISATION D’UN LOGICIEL
(VERSION SIMPLIFIÉE)

92. AVANT PROJET
• Pourquoi développer ce logiciel ?
• Comment faire pour réaliser le développement ?
• Quels moyens faut-il mettre en Œuvre ?

93. AVANT PROJET
• Initiation du projet :
• Représenter les activités à entreprendre dans un modèle.
• Prévoir les ressources nécessaires au projet.
• Mettre en place les environnement de développement et de
support.
• Identifier les procédures et normes spécifiques au projet.
• Planifier la gestion de projet.

94. AVANT PROJET
• L’étude préalable:
• Dresser un état de l’existant et faire une analyse de forces et
faiblesses.
• Identifier les besoin des utilisateurs.
• Formuler des solution potentielles.
• Faire des études de faisabilité.
• Planifier la transition entre l’ancien logiciel et le nouveau.
• Finaliser l’enoncé des besoins d’utilisateurs.

95. AVANT PROJET
• Le résultat de cette phase est :
Le Cahier de Charges

96. LE DÉVELOPPEMENT
• Planification du projet + Pilotage et suivie du projet +
Gestion de qualité :
• Emanent des principes de gestion de projet:
• WBS
• Gantt
• Pert …

97. LE DÉVELOPPEMENT
• Le choix d’un modèle a suivre selon les critère
précités (Taille du projet, Compétences … )
• Cette phase se termine par l’installation.

98. LE DÉVELOPPEMENT
• L’installation :
• Planifier l’installation.
• Distribuer le logiciel.
• Installer le logiciel et son environnement.
• Vérifier le logiciel dans son environnement opérationnel.
• Mettre hors service tout logiciel censé avoir été remplacé par
le nouveau.
• Mettre en place les mises ajours.

99. EXPLOITATION ET
MAINTENANCE
• Effectuer des dépannages pour des corrections mineurs.
• Distribuer les mises à jours.
• Fournir l’assistance technique et un support de consultation

100. LE RETRAIT
• Avertir les utilisateurs.
• Effectuer une exploitation en parallèle du logiciel à retirer et
de son successeur.
• Arrêter le support du logiciel.

101. LE PROTOTYPAGE
• la création d’un modèle d’essai du logiciel.
• Utilisé pour tester les différents concepts et exigences des
utilisateurs.
• Il spécifie les IHM.
• Objectif : satisfaire au mieux les besoins du client.

102. UN AGL (DÉFINITION)
• Un AGL (Atelier de Génie Logiciel) ou EGL(Environnement)
est un ensemble intégré d’outils logiciels qui fournissent une
aide pour réaliser et documenter toutes les activités du
développement logiciel, en accord avec les besoins, la
politique et les normes de qualité d'une organisation.

103. UN AGL
(FONCTIONNALITÉS)
1 - Améliorer la qualité du processus
• Augmenter la productivité des équipes.
• Favoriser la standardisation de la production.
• Accroître la prédictibilité des développements.
• Améliorer la visibilité des projets.
• Augmenter le confort et la créativité desdéveloppeurs.

104. UN AGL
(FONCTIONNALITÉS)
2 - Augmenter la conformité des produits
• Aider à appliquer les plans et les normes d’assurance qualité,
• Permettre de mener à bien des projets complexes et
importants en volume et en taille d’équipe,
• Améliorer le travail coopératif,
• Obtenir et mesurer un niveau de qualité défini.

105. UN AGL (AVANTAGES)
• Documentation et mise à jour tout au long de la conception.
• Maintenance du logiciel.
• Collaboration entre ingénieurs.

106. UN AGL (EXEMPLES)
• Windev
• Eclipse
• PowerAMC
• Rational Rose
• …

107. RAPPELS
• Activités du développement logiciel
• Analyse des besoins
• Spécification
• Conception
• Programmation
• Validation et vérification
• Livraison
• Maintenance
• Pour chaque activité : Utilisation et production de
documents (Livrables)

108. L’ANALYSE
• Objectif : Comprendre les besoins du client
• Objectifs généraux, environnement du futur système,
ressources disponibles, contraintes de performance...
• Entrée : Fournies par le client
• Expert du domaine d'application, futur utilisateur
• Document produit : Cahier des charges (+ manuel
d'utilisation préliminaire)

109. LA SPÉCIFICATION
• Objectifs :
• Établir une description claire de ce que doit faire le
logiciel(fonctionnalités détaillées, exigences de qualité,
interface...)
• Clarifier le cahier des charges (ambiguïtés, contradictions)
• Entrée : Cahier des charges + considérations de faisabilité ?
• Document produit : Cahier des charges fonctionnel

110. LA CONCEPTION
• Objectif : Élaborer une solution concrète réalisant la
spécification
• Description architecturale en composants (avec interface et
fonctionnalités)
• Réalisation des fonctionnalités par les composants
(algorithmes, organisation des données)
• Réalisation des exigences non-fonctionnelles
(performance,sécurité...)
• Entrée : Cahier des charges fonctionnel
• Document produit : Dossier de conception

111. LA PROGRAMMATION
• Objectif : Implantation de la solution conçue
• Choix de l'environnement de développement, du/des
langage(s) de programmation, de normes de développement...
• Entrée : Dossier de conception
• Document produit : Code documenté + manuel d'utilisation

112. LA VALIDATION ET
VÉRIFICATION
• Objectifs :
• Validation : assurer que les besoins du client sont satisfaits (au
niveau de la spécification, du produit fini...)
• Vérification : assurer que le logiciel satisfait sa spécification

113. LA VALIDATION ET
VÉRIFICATION

114. PROCESSUS EN CASCADE

115. 15/12/14

116. LA CONCEPTION
• La conception est une phase principale de l’élaboration de chaque
logiciel.
• C’est une période de réflexion lors de laquelle on réalise une
solution concrète à notre besoin.
• Elle vient après la réalisation du cahier de charges fonctionnelles et
on y constitue un dossier de conception.

117. LA CONCEPTION
• Il y a plusieurs méthodes de conceptions à savoir :
• MERISE
• UML
• …
Chaque méthode est idéale à un type d’applications. On
peut aussi combiner plusieurs méthodes pour avoir la solution.

118. LA CONCEPTION(MERISE-
RAPPEL)
• Il possède 2 Niveaux de conception :
• Données
• Traitement
• Chaque niveau est composé de plusieurs Modèles :
• Données (MCD, MOD , MLD ,MPD)
• Traitemeent (MCT , MOT, MLT, MPT)

119. LA CONCEPTION (UML-
RAPPEL)
Unified Modeling Langage
• Il supporte l’aspect Orienté Objet
• Il est pris sur deux vues :
• La Vue Statique
• La vue Dynamique
• Chaque vue est divisée en plusieurs Diagrammes.

120. UML ORIENTÉ OBJET ?
• Il introduit les principes de l’Orienté Objet :
• Les Classes et Objets
• L’héritage
• Le polymorphisme
• L’encapsulation
• …

121. UML (LA VUE STATIQUE)
• Les Cas D’utilisations (use cases)
• Diagramme de paquetage et de collaboration
• le diagramme de classes
• le diagramme de composants
• le diagramme de déploiement

122. UML (LA VUE DYNAMIQUE)
• le diagramme de séquence
• le diagramme d'états-transitions
• le diagramme d'activités

123. LES USE CASE
• Acteur : entité externe qui agit sur le système (opérateur, composant
interne…).
• Use case : ensemble d’actions réalisées par le système, en réponse à une
action d’un acteur. L’ensemble des uses cases décrit les objectifs (le but) du
système.
• Les relations de base entre cas d’utilisation et acteurs
• « include » : « include »
• « extends » : « extends »
• héritage :

124. USE CASE (EXEMPLE)

125. LE DIAGRAMME DE
CLASSES
• Classe
• Une description d’un ensemble d’objets qui
partage les mêmes attributs, opérations,
méthodes, relations et contraintes
• Objet
• Une entité avec une limite et une identité bien
définies qui encapsule de l'état et du
comportement. L’état est représenté par des
attributs et des relations, le comportement est
représenté par des opérations et des méthodes.
Un objet est une instance d’une classe.

126. LE DIAGRAMME DE
CLASSES
• Attribut = propriété nommée d ’une classe
• Syntaxe
• visibilité nom : type = valeur initiale
• Visibilité
• + public
• # protégé
• - privé
• package
• Attribut de classe
• la portée standard d’un attribut est limité à un objet
• quand cette portée s’applique à la classe elle même, on parle d’attribut de classe
(représenté par le symbole $ ou souligné)
• Attribut dérivé
• attribut qui peut être déduit d’un ou plusieurs autres attributs (représenté par le
symbole /)

127. LE DIAGRAMME DE
CLASSES
• Méthode = service que l ’on peut demander à un objet pour
réaliser un comportement
• Syntaxe
• visibilité nom (paramètres) : type retour
• Mêmes notions que l’attribut
• visibilité
• méthode de classe

128. LE DIAGRAMME DE CLASSES
(NOTATION COMPLÈTE D’UNE
CLASSE)

129. LE DIAGRAMME DE
CLASSES
• Association
• Exprime une connexion sémantique bi-directionnelle entre classes
• Abstraction des liens qui existent entre objets
• Le sens d ’une association peut-être précisé par une flêche
• Association binaire = Association entre 2 classes. Cas particulier
d ’association n-aire
• Rôle = rôle joué par une classe dans une association
• Multiplicité = indique le nombre d’instances d ’une classe qui peut
être mise en relation avec une seul instance de la classe associée
• 1 : obligatoire
• 0..1 : optionnel
• 0..* ou * : quelconque
• 1..* : au moins 1
• 1..5, 10 : entre 1 et 5, ou 10

130. LE DIAGRAMME DE
CLASSES (ASSOCIATION)

131. LE DIAGRAMME DE
CLASSES

132. LE DIAGRAMME DE
CLASSES
• Association n-aire = Une association parmi 3 classes ou plus. Chaque
instance de l’association est un n-tuple de valeurs des classes respectives.
Professeur Elève
Salle
Heure de début
Heure de fin
Cours
lieu
1
1
1..*

133. LE DIAGRAMME DE
CLASSES (EXEMPLE)
Diagramme de Classe

134. LE DIAGRAMME DE
SÉQUENCES
• Il modélise l’échange entre les différents modules de l’application
et ainsi comprendre son comportement
• Il permet de représenter des collaborations entre objets selon un
point de vue temporel, on y met l'accent sur la chronologie des
envois de messages.

135. EXEMPLE

136. EXEMPLE 2

137. UML CONCLUSION

138. AGL À UTILISER POUR LA
CONCEPTION UML
• Rational ROSE
• POWER AMC
• Star UML
• …

139. 22-12-14

140. SWOT / ARIS

141. LE DOSSIERS DE
CONCEPTION
• Il doit Contenir:
• Toutes les règles conclue lors de la phase de conception.
• Tout les diagrammes ou Modèles nécessaires pour débuter la
phase de programmation (pour le code et la base de données)
• Les diagrammes et modèles présentés doivent être clair.

142. LA PROGRAMMATION
• La programmation est la phase qui suit la Conception.
• Dans cette phase on commence à pratiquer le codage de
l’application c’est-à-dire rendre chaque fonctionnalité listé
dans le dossier de conception et le Cahier de charges
fonctionnelles opérationnelle.
• Le livrable de cette phase est l’application en première
version.

143. LES TESTS
• Le test d’un système est un processus d’essai des exécutions
d’un système selon un certain critère. L’observation de
chaque exécution est comparée avec la spécification du
système sous test :
• si conforme : test passé (ACCEPT)
• sinon : test échoué (FAIL)

144. LES TESTS (VÉRIFICATION)
• Cette phase se pratique pendant ou après la phase de
programmation.
• Elle permet de :
• Garantir la fiabilité et la cohérence du Logiciel. C’est-à-dire
qu’il soit conformes aux spécifications.
• Identifier les bugs, erreurs et défaillances du logiciel.
• Valider le logiciel.

145. LES TESTS
• Les trois grands objectifs des testes sont :

146. LES TESTS
• La vérification :
• Consiste à vérifier une spécification par rapport aux attentes
techniques.
• Exemple:
• Spécification : La validation d’une facture
• Attente technique : le champs ’’ Valide’’ = ‘’ True ’’

147. LES TESTS
• La validation :
• Consiste à vérifier une spécification par rapport à une attente
métier.
• Exemple :
• Spécification : La validation d’un facture
• Attente technique : La quantité du produit dans le stock doit
décroitre.

148. LES TESTS
• La défaillance :
• Une variation entre les résultats actuels et les résultats
attendus.
• Elle peut être dans l’expression des besoins ou bien lors de la
conception, l’analyse ou l’implémentation.

149. LES TESTS
• Cette phase répond aux questions suivantes :

150. LES TESTS
• La réponse à ces question servira à :

151. LES TESTS
• Pour commencer les tests il est préférable de :
• Débuter par les cas généraux avant les cas particuliers.
• Débuter par les cas Prioritaires.
• Ps : Une défaillance n’est par toujours causée par un
problème de code.

152. LES TESTS
• Les tests doivent concerner les éléments suivants :

153. LES TESTS
• Il y a une différence entre Programmeur et testeur.
• Les tests sont fait une équipe de testeurs dont la taille change
selon la taille et la complexité du projet.
• Les programmeurs peuvent interagir dans la phase des tests mais
de façon réduite.
• Les qualités d’un testeur :
• Minutieux
• Critique
• Communicatif

154. LES TESTS
• Dans une équipe de testeurs on trouve :
• Le coordinateur de tests : c’est celui qui établis les plans des
tests et les spécifications des tests selon des spécifications
techniques et fonctionnelles.
• Le testeur : exécute les tests et documente les résultats.

155. LES TESTS
• Il existe deux grandes catégorie de tests :
• Les tests en Boite Noir.
• Les tests en Boite Blanche.

156. LES TESTS
• Les tests en boite noire s’exécutent en ignorant les
composant interne du produit.
• Il n’y a pas d’accés au code source du logiciel.
• Exemple : tester un programme en vérifiant que les sorties
obtenues sont bien celles prévues pour des entrées données.

157. LES TESTS
• Les tests en boite blanche s’exécutent en prenant en
considération les composants internes du logiciel.
• Le testeurs dans ce cas utilise le code source du logiciel.
• Exemple : L’utilisation de ce type de tests dans la sécurité
d’un logiciel qui est également appelé test d’intrusion ou de
vulnérabilité.

158. LES TESTS
• Il y a plusieurs types de tests :

159. LES TESTS
• Les tests Unitaires :
• Sont des tests par blocs individuels.
• Sont souvent écrits par les développeurs eux-mêmes pour
valider leurs classes et méthodes.
• Sont exécutés par les machines.

160. LES TESTS
• Les tests d’intégration :
• Sont exécutés en Boite Blanche ou noire.
• Vérifient que certains composants s’intègrent bien avec les
autres composants ou systèmes.
• Il vérifient également la compatibilité du logiciel avec
l’environnement matériel et logiciel.

161. LES TESTS
• Les tests fonctionnels :
• Sont exécuté en boite noire
• Vérifient si le produit assure les fonctionnalités spécifiées dans
les spécifications fonctionnelles.

162. LES TESTS
• Les tests Système (Boite noire):
• S’oriente vers les spécifications non fonctionnelles du
produit.
• Sont composés de plusieurs teste :
• Tests de stress : consiste à tester le produit au delà des attentes
du client.
• Exemple : pour un système de sauvegarde ( 2 fois par jour ), on le
teste pour 3 fois.

163. LES TESTS
• Tests de chargement : Vérifie que le produit fonctionne dans des
condition normales.
• Tests d’utilisabilité : consiste à vérifier les conditions
d’apprentissage d’un utilisateur normale pour l’utilisation du
produit.

164. LES TESTS
• Les tests d’acceptation :
• Boite noire.
• Des tests formalisé par le client et exigés au testeurs pour
pouvoir valider le produit.

165. LES TESTS
• Les tests de régression :
• Ces des sous-ensembles de tests originaux.
• Ils vérifient si une modification n’a pas eu d’impact sur le
produit.

166. LES TESTS
• Les beta tests :
• Consistes à faire des version beta gratuite pour les utilisateurs
qui sont appelés des testeurs Beta.
• Ces utilisateurs vont utiliser le produit et reporter les
disfonctionnements rencontrés.

167. LES TESTS
• Comparaison entre les types de tests :

168. LES TESTS
• La priorisation des défaillances :

169. LA DOCUMENTATION
• Est un processus essentielle pour le suivi de projet et la
communication au sein de l'équipe de projet.
• Elle a pour but la traçabilité du projet.
• Elle a plusieurs bénéfice compte au déroulement du
projet :
• Pour l'équipe :
• Regrouper et structurer les décisions prises
• Faire référence pour les décisions futures
• Garantir la cohérence entre les modèles et le produit
• Pour le client :
• Donner une vision claire de l'état d'avancement du projet
• Base commune de référence :
• Personne quittant le projet : pas de perte d'informations
• Personne rejoignant le projet : intégration rapide

170. LA DOCUMENTATION (LE
MANUEL D’UTILISATEUR)
• Exemple:
• Identification du logiciel
• Introduction
• Environnement du logiciel.
• Installation du logiciel
• Démarrage du logiciel
• Guide de L’utilisateur.
• Manuel de référence
• Commandes et messages
• Données
• Fichiers
• Erreurs
• Dispositions D’aides
• Glossaire
• Index

171. LA DISTRIBUTION
• La phase finale de l’élaboration d’un logiciel est la
distribution.
• Dans cette phase nous avons deux procédures à suivre qui
sont :
• L’empaquetage
• Le déploiement.
• Ces deux procédures Sont des procédures de distribution du
produit finale demandé.

172. L’ EMPAQUETAGE
• L’empaquetage : c’est le fait d’embaler le produit finale
(logiciel) sous une forme qui facilite le transport avant d’être
distribué aux utilisateurs finaux.
• Le logiciel est mis sous forme de Colis ‘’ Package ‘’ .
• Ce Package est conçu pour permettre l’utilisation immédiate
du logiciel sans intervention d’un informaticien.

173. L’EMPAQUETAGE
• Il contient généralement le code objet des programmes, le
nécessaire pour les installer et la documentation.
• Le package est généralement Accompagné d’une licence
d’utilisation (Serial number…).

174. LE DÉPLOIEMENT
• Le déploiement est effectué en plusieurs étapes qui visent à
placer le logiciel dans son environnement cible de manière à
ce qu'il soit prêt à être utilisé.
1. La première étape consiste à emballer
(anglais package) un logiciel en vue de faciliter son envoi vers
l'environnement cible. (L’empaquetage)

175. LE DÉPLOIEMENT
2. L´installation: consiste à effectuer les opérations
nécessaires pour placer le logiciel dans son environnement
cible, ceci peut nécessiter une modification de
la configuration des logiciels déjà en place.
• La procédure d'installation est typiquement automatisée par
des logiciels - qui sont essentiellement des outils de
décompression.
Un logiciel évolue durant toute sa vie, et est typiquement
distribué plusieurs fois, à plusieurs stades de son évolution,
appelés versions ou release (Mises à jours)

176. LE DÉPLOIEMENT
• 3. La désinstallation consiste à effectuer les opérations
inverses de l'installation, en vue de retirer le logiciel.