SlideShare une entreprise Scribd logo
LE GÉNIE LOGICIEL
Niveau : DSI 2
Lycée Technique
Brevet de technicien supérieure
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
DÉFINITION
Ensemble de moyens (techniques, méthodes)
mis en œuvre pour la construction de
logiciels ou système informatique.
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.
Maitrise
d’ouvrage
(MOA)
Maitrise
d’oeuvre
(MOE)
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
• …
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.
Fiabilité de
maintenance
Cout de
production
Fiabilité
Efficacité
Ponctuation
Relation Secondaire
Relation Essentielle
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)
Atelier Genie Logiciel  Developement.pptx
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
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.
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é.
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.
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.
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.
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.
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 :
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
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.
LA GESTION DE LA
CONFIGURATION
• Elle permet de contrôler les évolutions du code produit et les différentes
versions du produit.
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
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 …
LE MODÈLE EN CASCADE
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 . . .
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.
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
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.
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.
LE MODÈLE EN
SPIRALE
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
LE MODÈLE EN SPIRALE
• Inconvénients :
• Mise en œuvre couteuse
LE MODÈLE ITÉRATIF
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é.
LE SCHÉMA DIRECTEUR
• Pourquoi un Schéma Directeur ?
• Diagnostique >> Remède
• Prospectives >> Plan de Progrès
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.
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.
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).
LES
FONCTIONS
DU SDI
• Sur Trois niveaux :
• DG : Direction générale.
• DSI
• Utilisateur.
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.
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 ?
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.
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
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.
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…
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
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
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.
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
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 ?
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
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
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.
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)
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.
CRITÈRES
DE
QUALITÉ
D'UN
SCHÉMA
DIRECTEUR
LES STRUCTURES DE
TRAVAIL
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.
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
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
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
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.
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.
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.
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.
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.
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
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.
CONCLUSION
(RIAD)
• Méthode Nolan Norton
• La méthode Nolan Norton
• (GPA)
• La démarche de la méthode
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
ATELIER 1 (SUITE)
• Partie 2
• I. Outils et langages utilisés
• Langages
• Conception
• Conception de site E-commerce
• Identification des acteurs :
• Identification des messages :
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
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
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
08/12/14
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
LES OBJECTIFS DU GL
LES PRINCIPES DU GL
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é.
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.
L’ENCAPSULATION
(AVANTAGES)
• Une meilleur sécurité.
• Un e Meilleur lisibilité
• Simplicité apparente pour
l’utilisateur
• Une meilleur portabilité.
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.
LA LOCALISATION
• C’est la proximité physique se rapportant à une même
abstraction.
L’UNIFORMITÉ
• Adopter le même style pour toute l’application en fonction
du projet et l’organisation
LA VALIDABILITÉ
• C’est la décomposition en modules pour faciliter les tests.
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.
APPLICATION DE CES
PRINCIPES
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
SCHÉMA GÉNÉRALE DE LA
RÉALISATION D’UN LOGICIEL
(VERSION SIMPLIFIÉE)
SCHÉMA GÉNÉRALE DE LA
RÉALISATION D’UN LOGICIEL
(VERSION SIMPLIFIÉE)
AVANT PROJET
• Pourquoi développer ce logiciel ?
• Comment faire pour réaliser le développement ?
• Quels moyens faut-il mettre en Œuvre ?
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.
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.
AVANT PROJET
• Le résultat de cette phase est :
Le Cahier de Charges
LE DÉVELOPPEMENT
• Planification du projet + Pilotage et suivie du projet +
Gestion de qualité :
• Emanent des principes de gestion de projet:
• WBS
• Gantt
• Pert …
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.
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.
EXPLOITATION ET
MAINTENANCE
• Effectuer des dépannages pour des corrections mineurs.
• Distribuer les mises à jours.
• Fournir l’assistance technique et un support de consultation
LE RETRAIT
• Avertir les utilisateurs.
• Effectuer une exploitation en parallèle du logiciel à retirer et
de son successeur.
• Arrêter le support du logiciel.
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.
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.
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.
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.
UN AGL (AVANTAGES)
• Documentation et mise à jour tout au long de la conception.
• Maintenance du logiciel.
• Collaboration entre ingénieurs.
UN AGL (EXEMPLES)
• Windev
• Eclipse
• PowerAMC
• Rational Rose
• …
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)
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)
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
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
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
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
LA VALIDATION ET
VÉRIFICATION
PROCESSUS EN CASCADE
15/12/14
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.
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.
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)
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.
UML ORIENTÉ OBJET ?
• Il introduit les principes de l’Orienté Objet :
• Les Classes et Objets
• L’héritage
• Le polymorphisme
• L’encapsulation
• …
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
UML (LA VUE DYNAMIQUE)
• le diagramme de séquence
• le diagramme d'états-transitions
• le diagramme d'activités
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 :
USE CASE (EXEMPLE)
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.
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 /)
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
LE DIAGRAMME DE CLASSES
(NOTATION COMPLÈTE D’UNE
CLASSE)
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
LE DIAGRAMME DE
CLASSES (ASSOCIATION)
LE DIAGRAMME DE
CLASSES
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..*
LE DIAGRAMME DE
CLASSES (EXEMPLE)
Diagramme de Classe
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.
EXEMPLE
EXEMPLE 2
UML CONCLUSION
AGL À UTILISER POUR LA
CONCEPTION UML
• Rational ROSE
• POWER AMC
• Star UML
• …
22-12-14
SWOT / ARIS
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.
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.
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)
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.
LES TESTS
• Les trois grands objectifs des testes sont :
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 ’’
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.
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.
LES TESTS
• Cette phase répond aux questions suivantes :
LES TESTS
• La réponse à ces question servira à :
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.
LES TESTS
• Les tests doivent concerner les éléments suivants :
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
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.
LES TESTS
• Il existe deux grandes catégorie de tests :
• Les tests en Boite Noir.
• Les tests en Boite Blanche.
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.
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é.
LES TESTS
• Il y a plusieurs types de tests :
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.
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.
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.
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.
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.
LES TESTS
• Les tests d’acceptation :
• Boite noire.
• Des tests formalisé par le client et exigés au testeurs pour
pouvoir valider le produit.
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.
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.
LES TESTS
• Comparaison entre les types de tests :
LES TESTS
• La priorisation des défaillances :
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
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
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é.
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.
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…).
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)
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)
LE DÉPLOIEMENT
• 3. La désinstallation consiste à effectuer les opérations
inverses de l'installation, en vue de retirer le logiciel.

Contenu connexe

Similaire à Atelier Genie Logiciel Developement.pptx

Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
LatifaBen6
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
Mohamed Diallo
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
jkebbab
 
partie3-cahier-des-charges fonctionnel intro
partie3-cahier-des-charges fonctionnel intropartie3-cahier-des-charges fonctionnel intro
partie3-cahier-des-charges fonctionnel intro
formationsalger
 
2 relation-acteurs-projet
2 relation-acteurs-projet2 relation-acteurs-projet
2 relation-acteurs-projet
briann_guillaud
 
Accéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.NetAccéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.Net
Frédéric Vandenbriele
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Agile Montréal
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
Nouhaila ALAMI
 
introduction génie logiciel-1.ppt
introduction génie logiciel-1.pptintroduction génie logiciel-1.ppt
introduction génie logiciel-1.ppt
SafaeElhouicha
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
Jean Michel
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
informatiquehageryah
 
1.pdf
1.pdf1.pdf
1.pdf
DabiYonko
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
Mohammed Amine Mostefai
 
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesEnrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Romain Couturier
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
Lilia Sfaxi
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
Sany_M
 
Drupal un projet comme les autres ? Drupalcamp Paris 2013
Drupal un projet comme les autres ? Drupalcamp Paris 2013Drupal un projet comme les autres ? Drupalcamp Paris 2013
Drupal un projet comme les autres ? Drupalcamp Paris 2013
Artusamak
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
Laurent PY
 

Similaire à Atelier Genie Logiciel Developement.pptx (20)

Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
 
partie3-cahier-des-charges fonctionnel intro
partie3-cahier-des-charges fonctionnel intropartie3-cahier-des-charges fonctionnel intro
partie3-cahier-des-charges fonctionnel intro
 
2 relation-acteurs-projet
2 relation-acteurs-projet2 relation-acteurs-projet
2 relation-acteurs-projet
 
Accéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.NetAccéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.Net
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
introduction génie logiciel-1.ppt
introduction génie logiciel-1.pptintroduction génie logiciel-1.ppt
introduction génie logiciel-1.ppt
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
 
1.pdf
1.pdf1.pdf
1.pdf
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesEnrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
 
Les usines à logiciels
Les usines à logicielsLes usines à logiciels
Les usines à logiciels
 
Drupal un projet comme les autres ? Drupalcamp Paris 2013
Drupal un projet comme les autres ? Drupalcamp Paris 2013Drupal un projet comme les autres ? Drupalcamp Paris 2013
Drupal un projet comme les autres ? Drupalcamp Paris 2013
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
 

Plus de ssusercb2b311

1. Task Sheet-diagramme-de-gantt-des.pdf
1. Task Sheet-diagramme-de-gantt-des.pdf1. Task Sheet-diagramme-de-gantt-des.pdf
1. Task Sheet-diagramme-de-gantt-des.pdf
ssusercb2b311
 
Catia.conception_mecanique_des_piecespptx
Catia.conception_mecanique_des_piecespptxCatia.conception_mecanique_des_piecespptx
Catia.conception_mecanique_des_piecespptx
ssusercb2b311
 
magasin de stockage automatise-diagram.pptx
magasin de stockage automatise-diagram.pptxmagasin de stockage automatise-diagram.pptx
magasin de stockage automatise-diagram.pptx
ssusercb2b311
 
presentation_adoption_de_IA_automobile.pptx
presentation_adoption_de_IA_automobile.pptxpresentation_adoption_de_IA_automobile.pptx
presentation_adoption_de_IA_automobile.pptx
ssusercb2b311
 
presentation strategie 11 final animated.pptx
presentation strategie 11 final animated.pptxpresentation strategie 11 final animated.pptx
presentation strategie 11 final animated.pptx
ssusercb2b311
 
presentaion-systeme-d'alerte-andonmsg.ppt
presentaion-systeme-d'alerte-andonmsg.pptpresentaion-systeme-d'alerte-andonmsg.ppt
presentaion-systeme-d'alerte-andonmsg.ppt
ssusercb2b311
 
White and Blue Professional Modern Technology Pitch Deck Presentation.pptx
White and Blue Professional Modern Technology Pitch Deck Presentation.pptxWhite and Blue Professional Modern Technology Pitch Deck Presentation.pptx
White and Blue Professional Modern Technology Pitch Deck Presentation.pptx
ssusercb2b311
 
1680274500731_Interfacehommemachine.pptx
1680274500731_Interfacehommemachine.pptx1680274500731_Interfacehommemachine.pptx
1680274500731_Interfacehommemachine.pptx
ssusercb2b311
 
Présentation-1.pptx
Présentation-1.pptxPrésentation-1.pptx
Présentation-1.pptx
ssusercb2b311
 
disposition des vues 2(ex+corrigé).ppt
disposition des vues 2(ex+corrigé).pptdisposition des vues 2(ex+corrigé).ppt
disposition des vues 2(ex+corrigé).ppt
ssusercb2b311
 

Plus de ssusercb2b311 (10)

1. Task Sheet-diagramme-de-gantt-des.pdf
1. Task Sheet-diagramme-de-gantt-des.pdf1. Task Sheet-diagramme-de-gantt-des.pdf
1. Task Sheet-diagramme-de-gantt-des.pdf
 
Catia.conception_mecanique_des_piecespptx
Catia.conception_mecanique_des_piecespptxCatia.conception_mecanique_des_piecespptx
Catia.conception_mecanique_des_piecespptx
 
magasin de stockage automatise-diagram.pptx
magasin de stockage automatise-diagram.pptxmagasin de stockage automatise-diagram.pptx
magasin de stockage automatise-diagram.pptx
 
presentation_adoption_de_IA_automobile.pptx
presentation_adoption_de_IA_automobile.pptxpresentation_adoption_de_IA_automobile.pptx
presentation_adoption_de_IA_automobile.pptx
 
presentation strategie 11 final animated.pptx
presentation strategie 11 final animated.pptxpresentation strategie 11 final animated.pptx
presentation strategie 11 final animated.pptx
 
presentaion-systeme-d'alerte-andonmsg.ppt
presentaion-systeme-d'alerte-andonmsg.pptpresentaion-systeme-d'alerte-andonmsg.ppt
presentaion-systeme-d'alerte-andonmsg.ppt
 
White and Blue Professional Modern Technology Pitch Deck Presentation.pptx
White and Blue Professional Modern Technology Pitch Deck Presentation.pptxWhite and Blue Professional Modern Technology Pitch Deck Presentation.pptx
White and Blue Professional Modern Technology Pitch Deck Presentation.pptx
 
1680274500731_Interfacehommemachine.pptx
1680274500731_Interfacehommemachine.pptx1680274500731_Interfacehommemachine.pptx
1680274500731_Interfacehommemachine.pptx
 
Présentation-1.pptx
Présentation-1.pptxPrésentation-1.pptx
Présentation-1.pptx
 
disposition des vues 2(ex+corrigé).ppt
disposition des vues 2(ex+corrigé).pptdisposition des vues 2(ex+corrigé).ppt
disposition des vues 2(ex+corrigé).ppt
 

Atelier Genie Logiciel Developement.pptx

  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • 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
  • 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 :
  • 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)
  • 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.
  • 138. AGL À UTILISER POUR LA CONCEPTION UML • Rational ROSE • POWER AMC • Star UML • …
  • 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.