Upload
hamza-el-alami
View
300
Download
2
Embed Size (px)
Citation preview
Méthodologies de développement
Qualité et processusQualité et processus
EL GHARBI Youssef, 2008
Introduction
sciences de la méthode (litéralement) est cette systématisation de l'étude, indépendamment du
thème à étudier lui-même. Suite de question a ce poser Désigner une personne pour la collection des
informations Les opérations à suivre en vue de faire des choix.
22EL GHARBI Youssef, 2008
Théorie
IntroductionIntroduction
Crise du logicielCrise du logiciel
Définition du génie logicielDéfinition du génie logiciel Les rôles dans un projet de développementLes rôles dans un projet de développement
Qualité dans le contexte LogicielQualité dans le contexte Logiciel Analyse des exigencesAnalyse des exigences La qualité de codage et les tests.La qualité de codage et les tests.
Model de maturité CMM et qualitéModel de maturité CMM et qualité
Processus de développement logicielProcessus de développement logiciel
RUP (Rational Unified Process )RUP (Rational Unified Process ) XP (eXtreme Programming )XP (eXtreme Programming )
33EL GHARBI Youssef, 2008
Travaux pratiques
Travail en équipe :Travail en équipe :
Gestionnaire de configuration (CVS)Gestionnaire de configuration (CVS) Contrôle qualité par mavenContrôle qualité par maven
Tests :Tests :
Tests unitaires (junit)Tests unitaires (junit) Tests de charge (Open STA)Tests de charge (Open STA)
44EL GHARBI Youssef, 2008
Recherche
Méthodologies Agiles (implication du client)Méthodologies Agiles (implication du client)
Model de maturité CMM/CMMIModel de maturité CMM/CMMI
Autres méthodologies :Autres méthodologies :
Méthodologie 2TUPMéthodologie 2TUP Méthodologie ScrumMéthodologie Scrum
Qualité logiciel automatiséeQualité logiciel automatisée
PDM qualité de codePDM qualité de code TestNGTestNG
TestingTesting Test DrivenTest Driven
55EL GHARBI Youssef, 2008
Objectif du cour
Connaître les notions fondamentales de la génie Connaître les notions fondamentales de la génie logiciel.logiciel.
Acquérir Les bonnes habitude de la génie logiciel.Acquérir Les bonnes habitude de la génie logiciel.
Maîtriser les différents processus standardisés.Maîtriser les différents processus standardisés.
66EL GHARBI Youssef, 2008
77EL GHARBI Youssef, 2008
Crise du logiciel
88EL GHARBI Youssef, 2008
Crise du logiciel
Se traduit par un ratio de plus en élevé d'échecs des Se traduit par un ratio de plus en élevé d'échecs des projets. De tous les projets concernant des systèmes projets. De tous les projets concernant des systèmes logiciels: logiciels:
2% fonctionnent comme voulu à la livraison, 2% fonctionnent comme voulu à la livraison, 3% fonctionnent après des corrections mineures, 3% fonctionnent après des corrections mineures, 20% fonctionnent après des corrections majeures, 20% fonctionnent après des corrections majeures, 45% sont livrés mais jamais utilisés, 45% sont livrés mais jamais utilisés, 30% ne sont jamais livrés (le projet est annulé).30% ne sont jamais livrés (le projet est annulé).
99EL GHARBI Youssef, 2008
Crise du logiciel
Prise de conscience d’une véritable crise lord d’une conférence Prise de conscience d’une véritable crise lord d’une conférence international en 1968 à Garmisch, RFA, conception des logiciels.international en 1968 à Garmisch, RFA, conception des logiciels.
Etude mené par le DOD (Department Of Defense) USAEtude mené par le DOD (Department Of Defense) USA
Evolution du coût logiciel/ matériel.Evolution du coût logiciel/ matériel.
1010EL GHARBI Youssef, 2008
Crise du logiciel
Pourquoi le génie logiciel affiche autant d’échecs Pourquoi le génie logiciel affiche autant d’échecs contrairement aux autres branches de l’ingénierie ?contrairement aux autres branches de l’ingénierie ?
1111EL GHARBI Youssef, 2008
Crise du logiciel
Décalage entre les progrès matériels d'une part et logiciels Décalage entre les progrès matériels d'une part et logiciels d'autre part.d'autre part.
Les logiciels réalisés ne correspondent souvent pas aux Les logiciels réalisés ne correspondent souvent pas aux besoins des utilisateurs; besoins des utilisateurs;
Les logiciels contiennent trop d'erreurs (qualité du logiciel Les logiciels contiennent trop d'erreurs (qualité du logiciel insuffisante); insuffisante);
Une fiabilité aléatoire … ;Une fiabilité aléatoire … ; La maintenance des logiciels est une tâche complexe et La maintenance des logiciels est une tâche complexe et
coûteuse; coûteuse; Les délais de réalisation sont généralement dépassés; Les délais de réalisation sont généralement dépassés; Les logiciels sont rarement portables. Les logiciels sont rarement portables.
1212EL GHARBI Youssef, 2008
Crise du logiciel
Cette crise à débouché sur la définition et Cette crise à débouché sur la définition et l’adoption du génie logiciel sur 2 constations :l’adoption du génie logiciel sur 2 constations :
1.1. d'une part le logiciel n'était pas fiabled'une part le logiciel n'était pas fiable
2.2. d'autre part, il était incroyablement difficile de réaliser d'autre part, il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leur dans des délais prévus des logiciels satisfaisant leur cahier des charges.cahier des charges.
1313EL GHARBI Youssef, 2008
Exemples de défaillances dues au manque de méthodologie de développement
La sonde Mariner vers Vénus s'est perdue dans l'espace à La sonde Mariner vers Vénus s'est perdue dans l'espace à cause d'une erreur de programme FORTRAN.cause d'une erreur de programme FORTRAN.
EDF a récemment renoncé à la mise en service de nouveaux EDF a récemment renoncé à la mise en service de nouveaux systèmes de contrôle-commande de ses centrales 1400 méga-systèmes de contrôle-commande de ses centrales 1400 méga-watts watts
L'explosion d'Ariane 5, le 4 juin 1996, qui a coûté un demi L'explosion d'Ariane 5, le 4 juin 1996, qui a coûté un demi milliard de dollars (non assuré !), est dûe à une faute logicielle milliard de dollars (non assuré !), est dûe à une faute logicielle d'une composante (à cause d'un débordement de capacité)d'une composante (à cause d'un débordement de capacité)
1414EL GHARBI Youssef, 2008
GENIE LOGICIEL
1515EL GHARBI Youssef, 2008
Génie Logiciel
« La nature des hommes fait qu’ils réagissent qu’après la crise »« La nature des hommes fait qu’ils réagissent qu’après la crise »
1616EL GHARBI Youssef, 2008
Génie Logiciel
la Crise financière Mondialla Crise financière Mondial
1717EL GHARBI Youssef, 2008
Génie Logiciel
Mode d'emploi simplifié de la crise financière mondiale en 6 étapesMode d'emploi simplifié de la crise financière mondiale en 6 étapes : Etape 1 : La crise financière part des Etats-Unis en août 2007Etape 1 : La crise financière part des Etats-Unis en août 2007 Etape 2 : Toutes les banques sont touchées à cause de la Etape 2 : Toutes les banques sont touchées à cause de la
titrisationtitrisation Etape 3 : Les banques se méfient et ne se prêtent plus Etape 3 : Les banques se méfient et ne se prêtent plus
d'argentd'argent Etape 4 : Faute de liquidités, certaines banques sont Etape 4 : Faute de liquidités, certaines banques sont
asphyxiées dès 2007asphyxiées dès 2007 Etape 5 : La panique gagne les marchés financiers en 2008Etape 5 : La panique gagne les marchés financiers en 2008 Etape 6 : Tentative de sauvetage à coût de centaines de Etape 6 : Tentative de sauvetage à coût de centaines de
milliardsmilliards
1818EL GHARBI Youssef, 2008
Le gouvernement américain tente de convaincre le congrès de voter un plan de sauvetage de 700 milliards de dollars.
Les banquiers remettent en question leurs formules de financement, et prennent en considération de plus en plus la variation du marché de l’immobilier et d’autre secteur qui touchent le leur.
Génie Logiciel
EL GHARBI Youssef, 2008
Avant 1968: Absence de process; Absence de phase; Absence de rôle (pas de spécialisation); L’unique mission c’est la programmation; Manque démarche ingénierique.
Le génie logiciel en histoire
Après 1968: Naissance d’une discipline de l’ingénieur du logiciel
« génie logiciel » , pour aider le programmeur des systèmes informatiques à réaliser des logiciels fiables, i.e., satisfaisant leur cahier des charges, dans des délais raisonnables.
« génie logiciel » comme génie chimique, génie électrique, génie mécanique…
génie logiciel en histoire
Génie Logiciel
Le terme génie logiciel (en anglais software engineering) Le terme génie logiciel (en anglais software engineering) désigne l'ensemble des méthodes, des techniques et outils désigne l'ensemble des méthodes, des techniques et outils concourant à la production d'un logiciel, au-delà de la seule concourant à la production d'un logiciel, au-delà de la seule activité de programmation (activité de programmation (WikiPediaWikiPedia).).
ensemble des techniques, outils et méthodes visant à optimiser et rationaliser la production du logiciel et son suivi.
Le génie logiciel touche à toutes les phases du cycle de vie du Le génie logiciel touche à toutes les phases du cycle de vie du logiciel.logiciel.
2222EL GHARBI Youssef, 2008
Le génie logiciel
les méthodes et techniques issues du génie logiciel sont imposées par les autorités de certification pour le développement de systèmes critiques (avionique, nucléaire…)en parle de « normes de développement de systèmes (DO178B…) »
Génie Logiciel – Disciplines
Phase de spécifications des besoins; Phase de conception générale; Phase de conception détaillée; Phase de codage et tests unitaires; Phase de test des modules; Phase d'intégration d'ensemble Phase de recette
2424EL GHARBI Youssef, 2008
Génie Logiciel (phase spécification des besoins)
spécifications générales:ensemble d’objectif de contrainte et généralité;
Spécification fonctionnelle: description de fonctionnalité du logiciel aussi détailler que nécessaire;
Spécification d’interface: IHM interface humain machine;
Génie Logiciel (phase spécification des besoins)
Le but de la première phase de développement est de spécifierles besoins du logiciel à partir des besoins existants
Cette phase qui constitue environ 15% du temps total du développement se termine par la revue des spécifications fonctionnelles;
Le but de la première phase de développement est de spécifier les besoins du logiciel à partir des besoins existants (Requirement);
Cette phase peut aussi s'appeler "spécifications externes" ou "analyse des besoins" selon le vocabulaire employé;
Génie Logiciel (phase spécification des besoins)
Les documents produits au cours de cette phase sont: Plan de développement du logiciel :(résume cette phase) Spécifications des besoins du logiciel:SRS Cahier de recette (spécification de teste);
Génie Logiciel (phase spécification des besoins)
Genie Logiciel (Phase de conception générale)
Définition de l’architecture logiciel; Envisager plusieurs solution au problème et d’étudier
leur faisabilité Une présentation générale de la structure du logiciel est
faite. découper le logiciel en modules si l'on utilise un langage
classique ou de définir les objets si l'on utilise un langage orienté objet.
Ex: définir les modules qui géreront les transactions; découper le logiciel en tâches (exécution d’un
code )pouvant s'exécuter en parallèle;
Genie Logiciel (Phase de conception générale)
Cette phase peut dépendre des outils de développement spécifié dans les spécification générales (au cas ou ils sont spécifiés);
Cette phase qui représente environ 10% du temps total consacré au développement se termine par la revue de conception générale.
Cette phase peut aussi s'appeler "conception globale" ou "analyse organique globale" selon le vocabulaire employé
Genie Logiciel (Phase de conception générale)
Le document produit au cours de cette phase est: Document de conception générale
Genie Logiciel (Phase de conception générale)
Genie Logiciel (Phase de conception détaillée)
Dans le cas de l'utilisation d'un langage modulaire, cette phase consiste à définir précisément les interfaces des modules;
Dans le cas de l'utilisation d'un langage orienté objet, cette phase consiste à définir précisément les contenus des objets: attributs et méthodes;
Le document de conception détaillée présente l'architecture détaillée à laquelle on aboutit;
Les tests et jeux d'essais à mettre en oeuvre durant le phase d'intégration du logiciel sont décrits dans le document de spécifications des tests d'intégration du logiciel.
On peut aussi décrire le contenu des procédures grâce à un pseudo-langage (des algorithmes).
Cette phase qui représente environ 25% du temps total consacré au développement se termine par la revue de conception détaillée.
Les deux phases de conception peuvent être regroupées sous le vocable de "spécifications internes" selon les cas.
Genie Logiciel (Phase de conception détaillée)
Les documents produits au cours de cette phase sont: Document de conception détaillée Manuel d'utilisation Spécifications des tests d'intégration
Genie Logiciel (Phase de conception détaillée)
Dans cette phase: Les procédures identifiées lors de la phase précédente
sont codées et testées individuellement; Le produit est le code source et les résultats des tests
unitaires; Dans le cas de l'utilisation d'un langage modulaire, cette
phase consiste à coder les corps des modules en respectant leur interface;
Cette phase qui représente environ 15% du temps total consacré au développement se termine par la revue de codage et tests unitaires.
Genie Logiciel (Phase de codage et tests unitaires)
Les documents produits au cours de cette phase sont: Source Résultats des tests unitaires
Genie Logiciel (Phase de codage et tests unitaires)
Génie Logiciel (Phase de test des modules)
Dans cette phase: Chaque module est testé individuellement; On vérifie que les services spécifiés par l'interface d'un
module sont effectivement rendus par le module; Cette phase qui représente environ 5% du temps total
consacré au développement se termine par la revue de tests des modules;
Cette phase peut éventuellement être fusionnée avec les tests unitaires de la phase précédente.
Les documents produits au cours de cette phase sont: Résultats des tests de modules
Génie Logiciel (Phase de test des modules)
Génie Logiciel (Phase d'intégration d'ensemble)
Dans cette pahse: Les différents modules du logiciel sont progressivement
intégrés par niveaux successifs en respectant les spécifications des tests d'intégration;
Les jeux d'essais, procédures et résultats des tests sont consignés dans le document de résultat des tests d'intégration.
Cette phase qui représente environ 20% du temps total consacré au développement se termine par la revue d'intégration d'ensemble du logiciel.
Les documents produits au cours de cette phase sont: Présentation du logiciel; Résultats des tests d'intégration.
Génie Logiciel (Phase d'intégration d'ensemble)
Génie Logiciel (Phase de recette)
Dans cette phase: On l’appelle aussi phase de réception; On vérifie que le logiciel développé répond aux besoins
exprimés dans la phase de spécifications des besoins; Cette phase qui représente environ 10% du temps total
consacré au développement se termine par la revue finale.
Les documents produits au cours de cette phase sont: Résultats de la recette
Génie Logiciel (Phase de recette)
Génie Logiciel (LA MAINTENANCE)
La maintenance est une activité qui comprend la formation de l'utilisateur et l'assistance technique;
Elle débute à la livraison du logiciel et s'achève à la fin de l'exploitation du système.
L'activité se prépare pendant le développement et s'applique ensuite sur le logiciel opérationnel recetté.
Lorsque les modifications représentent une partie notable du développement, on les considère comme une refonte sortant du cadre de la maintenance, traitée comme un projet logiciel normal.
La maintenance peut être: corrective: non conformité aux spécifications, d'où
détection et correction des erreurs résiduelles. adaptative: modification de l'environnement (matériel,
fournitures logicielles, outil, ...) évolutive: changement des spécifications fonctionnelles
du logiciel.
Génie Logiciel (LA MAINTENANCE)
Les activités de maintenance couvrent les domaines suivants:
qualifications des nouvelles versions, suivis des modifications, archivage, mise à jour de la documentation, exécution des modifications.
Génie Logiciel (LA MAINTENANCE)
……….
Définir les rôles dans projet logiciel
Votre rôle dans un projet de développement
Un projet d’informatisation ou de développement de logiciel est un ensemble d'activités accomplies par une équipe de spécialistes de disciplines différentes concourant, sous la conduite d'un responsable, à la réalisation d'un même objectif à l'intérieur de limites de temps et de coût.
Admettons que vous faites partie de l’équipe en tant qu’ingénieur développeur
fraîchement sorti de High-Tech… et voyons ce qui vous
attend
NetAdmin (Administrateur de
réseau)
Qui peut être avec vous ?
DBA
Analyste/concepteur/
Développeur(s)
Rédacteur
Technique
Ingénieur
Qualité (QA)
Chef de projet
Client
Le chef de projet ?
Il vous assignera les tâches en fonction de votre profil
Parmi ses occupations :STRUCTURER
identifier les fonctions du logicielfaire préciser le besoin si nécessaire
constituer une équipegérer les interfaces ente les acteurs
PILOTERnégocier avec les clients et partenairesanticiper au maximum les situations
maîtriser les coûts, délais et performances
...
...
Le DBA ?
C’est lui qui va : Installer le serveur SGBD (Oracle ou autre …)
et les outils applicatifs, créer les bases de données.
Assurer la maintenance et la disponibilité de la
base de données.
Créer la structure logique de stockage, c'est à dire les tablespaces, les tables, les vues et les
indexes.
Manager la structure physique de stockage, comprenant les fichiers de données, les fichiers
de contrôle et les fichiers de redo log.
Le DBA (suite)
Allouer et prévoir l'espace disque système de stockage nécessaire aux spécifications
de la base de données.
Maintenir, contrôler et monitorer les accès des utilisateurs.
Assurer la sécurité du système.
Monitorer les performances de la base de données.
Créer un plan de sauvegarde et de récupération.
DBA (suite)
Toute modification dans la base de données doit d’abord être discutée dans une réunion avec le chef
de projet et les DBAs. Toute modification, ajout ou suppression dans la
structure de la BD se fait par des script SQL que seul le DBA a le droit d’exécuter.
Le DBA crée pour chaque développeur une BD de test avec des données d’essai.
Le DBA et le problème de performances des applicatifs
SELECT num FROM table wHERE num IN(10, 11, 12, 13, 14)
sur une table de 2 millions de records prend 5
minutes
Le DBA propose : Le DBA propose : SELECT num FROM tableSELECT num FROM table
WHERE num BEETWEEN 10 AND 15WHERE num BEETWEEN 10 AND 15ÇÇa prend 20 secondesa prend 20 secondes
Non CNon C’’est Trop est Trop !!
Appel le Appel le DBADBA
SELECT A.zon1 FROM Table1 A WHERE A.zon1 NOT IN (SELECT B.zon1 FROM
table2 WHERE B.zon2 <> 0)
sur une table de 2 millions de records prend 15 minutes
SELECT A.zon1 FROM Table1 A WHERE NOT SELECT A.zon1 FROM Table1 A WHERE NOT EXISTS(SELECT * FROM Table2 B WHERE EXISTS(SELECT * FROM Table2 B WHERE
A.zon1 = B.zon1 AND B.zon2 = 0)A.zon1 = B.zon1 AND B.zon2 = 0) ÇÇa prend 10 secondesa prend 10 secondes
Trop lente !Trop lente !
Any suggestion Mister DBA ?Any suggestion Mister DBA ?
Indépendance des SGBD un grand avantage
Attention ! L’optimisation des requêtes peut conduire à l’utilisation des SQLs spécifiques et créer la dépendances entre les applicatifs et le SGBD.
La solution ? Les classes d’accès aux données.
ApplicatifApplicatifBDBD
Classes Classes dd’’accaccèès s
aux aux donndonnééeses
Classes Classes dd’’accaccèès s
aux aux donndonnééeses
Le rôle du rédacteur technique ?
C’est lui qui va :
Concevoir la structure de la documentation du logiciel. Le cas échéant, participer à la définition de l'ergonomie de
l'interface. Identifier et choisir les éléments graphiques à utiliser. Rédiger et mettre en forme le texte. Coordonner le travail de correction linguistique. Effectuer les tests qualité nécessaires, surtout conformité
document réalité. A la production du produit final : impression, intégration à un
logiciel auteur, etc.Il vous visitera au moins deux fois :
Au début du projet pour vous fournir les éléments de l’interface
A la fin pour noter ce que fait votre module.
Le NetAdmin
Son rôle consiste à : gérer l'organisation générale du réseau (gestion de l'espace disque du ou
des serveurs, création de comptes, de groupes de travail, gestion des droits d'accès, ...),
installer et configurer les matériels et logiciels utilisés sur le réseau (Routeurs, Serveurs, Modems …)
gérer la sécurité du réseau, assurer la sauvegarde régulière des données présentes sur l'espace disque du serveur,
répondre aux besoins des utilisateurs, organiser leur formation, ...
C’est lui qui préparera votre poste de travail (installe les outils de développement et vous connectera au réseau)
l’ingénieur qualité
Validité : pour vérifier son aptitude à remplir exactement ses fonctions.
Fiabilité (ou robustesse) : pour vérifier son aptitude à fonctionner dans des conditions anormales.
Extensibilité : pour mesurer avec quelle facilité ses fonctions peuvent être modifiées ou enrichies.
Réutilisabilité : mesurer à quel point votre travail peut être réutilisé, en tout ou en partie, dans de nouvelles applications.
Son rôle est de vous prouver que vous êtes un mauvais développeur en faisant subir à votre travail les tests de :
l’ingénieur qualité (suite)
Efficacité : Pour mesurer son utilisation des ressources matérielles.
Portabilité : Afin de juger la facilité avec laquelle un votre logiciel peut être transféré sous différents environnements matériels et logiciels.
Vérifiabilité : pour mesurer la facilité de préparation des procédures de test.
Facilité d'emploi (convivialité) : pour juger de la facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.
……….
Définir les rôles dans projet logiciel
Récréation...
A propos de la réutilisation et du poids du passé…
Question : la distance standard entre 2 rails de chemin de fer aux US est de 4 pieds et 8,5 pouces. C'est un chiffre particulièrement bizarre.Pourquoi cet écartement a-t-il été retenu ?
Parce que les chemins de fer US ont été construit de la même façon qu'en Angleterre, par des ingénieurs anglais expatriés, qui ont pensé que c'était une bonne idée car ça permettait également d'utiliser des locomotives anglaises. Pourquoi les anglais ont construits les leurs comme cela ?
Parce que les premières lignes de chemin de fer furent construites par les mêmes ingénieurs qui construisirent les tramways, et que cet écartement était alors utilisé. Pourquoi ont-ils utilisé cet écartement ?
Récréation...
Parce que les personnes qui construisaient les tramways étaient les mêmes qui construisaient les chariots et qu'ils ont utilisé les mêmes méthodes et les mêmes outils. Pourquoi les chariots utilisent un tel écartement ?
Parce que partout en Europe et en Angleterre les routes avaient déjà des ornières et un espacement différent aurait cause la rupture de l'essieu du chariot. Pourquoi ces routes présentaient elles des ornières ainsi espacées ?
Parce que les premières grandes routes en Europe ont été construites par l'empire romain pour accélérer le déploiement des légions romaines.Pourquoi les romains ont ils retenue cette dimension ?
Parce que les premiers chariots étaient des chariots de guerre romains. Ces chariots étaient tirés par deux chevaux. Ces chevaux galopaient cote à cote et devaient être espacés suffisamment pour ne pas se gêner. Afin d'assurer une meilleure stabilité du chariot, les roues ne devaient pas se trouver dans la continuité des empreintes de sabots laissées par les chevaux, et ne pas se trouver trop espacées pour ne pas causer d'accident lors du croisement de deux chariots.
Récréation...
Réponse à la question : l'espacement des rails US (4 pieds et 8 pouces et demi) s'explique parce que 2000 ans auparavant, sur un autre continent, les chariots romains étaient construits en fonction de la dimension de l'arrière train des chevaux de guerre.
Conséquence : la navette spatiale américaine est flanquée de deux réservoirs additionnels attachés au réservoir principal. La société THIOKOL fabrique ces réservoirs additionnels dans leur usine de l'UTAH. Les ingénieurs qui les ont conçus auraient bien aimé les faire un peu plus larges, mais ces réservoirs devaient être expédiés par train jusqu'au site de lancement. La ligne de chemin de fer entre l'usine et Cap Canaveral emprunte un tunnel sous les montagnes rocheuses. Les réservoirs additionnels devaient pouvoir passer sous ce tunnel. Le tunnel est légèrement plus large que la voie de chemin de fer, et la voie de chemin de fer est à peu près aussi large que les arrières train de deux chevaux.
Conclusion : une contrainte de conception du moyen de transport le plus avancé au monde est la largeur d'un de cheval.
Cahier des charges
Résumer
Le cahier des charges est un préalable à tout projet informatique. Etude de l’existant, analyse des besoins, spécifications des caractéristiques fonctionnelles, cadre juridique : autant d’aspects qu’il faut maîtriser pour un projet réussi.
Pourquoi un cahier des charges
Pour que le projet de site soit le vrai reflet de l'entreprise Pour éviter la confusion Pour réussir le Projet Pour ne pas réinventer la roue Pour trouver des renseignements, références et aides
utiles
Consistance générale d'un cahier des charges
les enjeux du projet les objectifs généraux à atteindre, y compris le livrable
principal ; les modalités éventuelles d'exécution (coûts estimés a
priori, délai, jalons,…) les critères d’évaluation du livrable et des autres
objectifs ; les contraintes principales ; Le Hors Périmètre.
Plan type (AFNOR X50-151)
Utilisation du cahier des charges
En interne: le cahier des charges sert à formaliser les besoins et à les expliquer
aux différents acteurs pour s’assurer que tout le monde est d’accord. Choisir le prestataire ou soumissionnaire considéré comme un référentiel partagé par le prestataire et l’équipe
interne
Utilisation du cahier des charges
En Externe: le cahier des charges est en outre un outil fondamental de communication du
directeur de projet et/ou du chef de projet. Le cahier des charges est un document contractuel entre le client et le
prestataire/vendeur considéré comme un référentiel partagé par le prestataire et l’équipe interne
Cahier des charges(Général/fonctionnel)
La partie « expression du besoin » du cahier des charges est ensuite précisée, si besoin, dans un cahier des charges fonctionnel.
Partie technique d'un cahier des charges
La partie technique d’un Cahier des Charges doit se limiter à énumérer les contraintes techniques avérées: économiques ; Environnementales( le caractère recyclable du produit, etc.) ;
humaines (la population visées); industrielles matérielles (Hardware,serveur d’applications, la plate-forme de
déploiement)
Outil de communication
Le cahier des charges est tout d’abord un outil de communication et d’information entre le professionnel de l’information (« utilisateur ») et le prestataire de service.
Quatre objectifs d’un cahier des charges
Définir les objectifs que doit atteindre la solution. Indiquer les contraintes à respecter impérativement. Etre un outil de dialogue entre les différents acteurs. Diminuer les risques d’erreur lors de la réalisation ou
l’installation.
Structuration
il n’y a pas de plan type pour rédiger un cahier des charges
Structuration
Les quatre éléments clés d’un cahier des charges : Étude de l’existant Analyse des besoins Description de la solution(fonctionnelle et technique) Définition de la procédure (juridique, managériale)
Structuration
L’étude de l’existant:1. La première consiste à recueillir les informations 2. La seconde consiste à analyser, classer et donner une vue
synthétique de l’ensemble des informations collectées par domaine fonctionnel,
3. La troisième consiste à esquisser une modélisation à grosses mailles des données et des traitements.
Structuration
L’analyse des besoins
Trois facteurs sont à prendre en compte dans l’analyse :1. Facteurs liés à l’application informatique elle-même comme la durée de vie de
l’application, le champ de l’application.
2. Facteurs liés à la solution, comme la mise en place d’un portail d’information, la gestion de ressources électroniques.
3. Facteurs liés au projet comme les enjeux, le coût, les crédits.
le besoin c’est la nécessité ou le désir éprouvé par un utilisateur
Structuration
L’analyse des besoins(Suite)Ces facteurs sont à prendre en compte avec l’intégration
de contraintes : 1. Les contraintes organisationnelles, par exemple la gestion d’un fonds
géré sur plusieurs sites.2. Les contraintes techniques comme l’usage d’un système d’exploitation
particulier ou un système de gestion de bases de données (SGBD).3. Les contraintes humaines et administratives (compétences,
organigramme, planning).4. Les contraintes financières (budget).
Structuration
Les caractéristiques fonctionnelles
Dans cette partie le client crée un tableau de fonctionnalité à compléter par le prestataire potentiel, Ces tableaux seront des instruments très utiles à trois niveaux :
1. Pour comparer et sélectionner le prestataire ou la solution.
2. Pour obliger le prestataire à s’engager sur toutes les questions.
3. Pour permettre de réaliser la vérification d’aptitude (recette).
StructurationLes caractéristiques fonctionnelles (suite)
tableaux cadre des caractéristiques fonctionnelles et techniques
Structuration
Le cadre juridique:Tout projet, une fois lancé, possède un caractère contractuel. Ce
contrat engage client et prestataire sur la base du cahier des charges.
L’objet du contrat Les lieux d’exécution et de livraison La durée du contrat/marché Les caractéristiques principales Les critères d’attribution du marché Appel d’offres ouvert Appel d’offres restreint
Cahier des charges
Conclusion
Un bon cahier des charges sera toujours le reflet d’une compréhension et du respect mutuel des métiers. Le professionnel de l’information n’a pas à se substituer à l’informaticien. Le cahier des charges n’est pas destiné à imposer au prestataire comment il doit réaliser le projet mais à lui expliquer les besoins de l’établissement et décrire les fonctionnalités cibles.
Analyse des exigences
EL GHARBI Youssef, 2008 8787
Introduction
40% à 60% des échecs logiciels sont le produit de mauvaise 40% à 60% des échecs logiciels sont le produit de mauvaise gestion des exigences.gestion des exigences.
L’effort est perdu lorsque l’équipe se base sur une mauvaise L’effort est perdu lorsque l’équipe se base sur une mauvaise collecte de besoins.collecte de besoins.
L’analyse des exigences en SI a été standardisé par l’IEEE L’analyse des exigences en SI a été standardisé par l’IEEE ((Institute of Electrical and Electronics EngineersInstitute of Electrical and Electronics Engineers ) sous la ) sous la référence STD 830-1998 .référence STD 830-1998 .
8888EL GHARBI Youssef, 2008
Analyse des exigances (Problèmes des utilisateurs)
les manières selon lesquelles les utilisateurs peuvent ne pas maîtriser l'ensemble des exigences :
Les utilisateurs ne savent pas ce qu'ils veulent ; Les utilisateurs ne veulent pas s'engager à écrire les exigences ; Les utilisateurs insistent sur de nouvelles exigences après que le
coût et le calendrier ont été fixés ; La communication avec les utilisateurs est lente ; Les utilisateurs ne participent le plus souvent pas aux revues ou
sont incapables de le faire ; Les utilisateurs manquent de compétence technique ; Les utilisateurs ne comprennent pas le processus de
développement. Cela peut conduire à une situation où les exigences des utilisateurs
continuent de changer même lorsque le développement du système ou du produit a commencé.
qui est responsable de l’analyse des exigences?
Le gestionnaire du projet (chef de projet).Le gestionnaire du projet (chef de projet).
L’équipe d’ingénierie logiciel.L’équipe d’ingénierie logiciel.
En collaboration avec :En collaboration avec :
Les donneurs d’ordres.Les donneurs d’ordres. Les clients.Les clients. Les utilisateurs finaux.Les utilisateurs finaux.
9090EL GHARBI Youssef, 2008
Contexte
Les utilisateurs ou clients ont des besoins qu’il expriment de Les utilisateurs ou clients ont des besoins qu’il expriment de façon plus au moins détaillée.façon plus au moins détaillée.
Il est de la responsabilité de l’ingénieur du SI de creuser les Il est de la responsabilité de l’ingénieur du SI de creuser les détails et de formaliser les demandes. détails et de formaliser les demandes.
Les Clients expriment leurs besoins en des termes vagues Les Clients expriment leurs besoins en des termes vagues (simple, le meilleur, compatible…) mais ne peuvent pas être (simple, le meilleur, compatible…) mais ne peuvent pas être blâmés !blâmés !
9191EL GHARBI Youssef, 2008
Mission
Exprimer les besoin des client vers des :Exprimer les besoin des client vers des :
Exigences fonctionnelles.Exigences fonctionnelles. Exigences de qualité.Exigences de qualité. Exigences externes.Exigences externes.
Transformer le tout vers des:Transformer le tout vers des:
Software requirements specifications : spécifications Software requirements specifications : spécifications d’exigences logicielles. SRSd’exigences logicielles. SRS
NB: NB: les correspondances entre les exigences et les SRS doivent les correspondances entre les exigences et les SRS doivent être gardésêtre gardés..
9292EL GHARBI Youssef, 2008
Mission
9393EL GHARBI Youssef, 2008
Mission
Avant d’être remis aux équipes de développement les SRS Avant d’être remis aux équipes de développement les SRS doivent être :doivent être :
Prioritairisé !Prioritairisé !
Les priorités nous permettent de filtrer les SRS à :Les priorités nous permettent de filtrer les SRS à :
Implémenter rapidement Implémenter rapidement (règle 20/80)(règle 20/80) Remettre vers des versions ultérieures.Remettre vers des versions ultérieures. Supprimer du périmètre du projet.Supprimer du périmètre du projet.
9494EL GHARBI Youssef, 2008
Exigences fortuites
Tout SRS doit être mappé vers un besoin fonctionnel qui l’as Tout SRS doit être mappé vers un besoin fonctionnel qui l’as généré.généré.
Si le client insiste sur un besoin non fonctionnel:Si le client insiste sur un besoin non fonctionnel:
Estimer la charge.Estimer la charge. L’informer du côut.L’informer du côut.
9595EL GHARBI Youssef, 2008
Changement dans les exigences
Le changement dans les besoins est Le changement dans les besoins est inévitableinévitable..
Tout changement doit être documenté.Tout changement doit être documenté.
L’information doit être généralisée à toute l’équipe.L’information doit être généralisée à toute l’équipe.
Un changement dans une exigence doit impliquer les revue Un changement dans une exigence doit impliquer les revue de tout les SRS correspondants.de tout les SRS correspondants.
9696EL GHARBI Youssef, 2008
Formulation des exigences
Eviter la dissertation !Eviter la dissertation !
Un SRS contient (selon pertinence):Un SRS contient (selon pertinence): Un acteur.Un acteur. Une action.Une action. Un objectif.Un objectif. Un ensemble de contraintes.Un ensemble de contraintes.
Un SRS contient souvent Un SRS contient souvent 3 ponctuation3 ponctuation, la , la répétition des mots est souhaitable. répétition des mots est souhaitable.
Vérifier qu’aucune phrase ne contient deux besoins!Vérifier qu’aucune phrase ne contient deux besoins!
9797EL GHARBI Youssef, 2008
Formulation des exigences
Les mots choisis doivent être concis et compréhensibles par Les mots choisis doivent être concis et compréhensibles par tous (pas de jargon de boite).tous (pas de jargon de boite).
Être prudent dans l’utilisation des conjonctions « et », « ou Être prudent dans l’utilisation des conjonctions « et », « ou », « si »…», « si »…
Vérifier l’exactitude avec le client et la compréhension avec Vérifier l’exactitude avec le client et la compréhension avec les développeurs.les développeurs.
Vérifier que vous n’êtes pas tombé dans des contradictions!Vérifier que vous n’êtes pas tombé dans des contradictions!
9898EL GHARBI Youssef, 2008
What’s Next ?
Vérifier que toutes les exigences sont couvertes Vérifier que toutes les exigences sont couvertes (fonctionnelles, de qualité et externes).(fonctionnelles, de qualité et externes).
Transformer (faire correspondre) les SRS en use Transformer (faire correspondre) les SRS en use cases.cases.
Décrire et diagrammer les use cases.Décrire et diagrammer les use cases.
9999EL GHARBI Youssef, 2008
Outils
Base de données des exigences.Base de données des exigences.
Rational Requisite Pro.Rational Requisite Pro.
100100EL GHARBI Youssef, 2008
Outils
101101EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
Qualité : est ce qui fait qu’une chose est plus ou moins Qualité : est ce qui fait qu’une chose est plus ou moins recommandable, le degrés plus ou moins élevé d’une échelle recommandable, le degrés plus ou moins élevé d’une échelle pratique (pratique (le Robertle Robert))
La Qualité dans un système d’information est fonction de La Qualité dans un système d’information est fonction de plusieurs paramètres. Certains sont liés aux moyens déployés plusieurs paramètres. Certains sont liés aux moyens déployés pour l’instauration et le suivi du SI. Certains autres sont pour l’instauration et le suivi du SI. Certains autres sont l’image de la qualité du logiciel déployé l’image de la qualité du logiciel déployé
102102EL GHARBI Youssef, 2008
Assurance qualité logicielle(AQL)
6
ensemble des activités préétablies et systématiquement mises en œuvre dans du système qualité et démontrées en tant que besoin pour donner la confiance appropriée en ce qu'autre entité satisfera aux exigences pour la qualité. L'assurance de la qualité vise a la fois des objectifs internes et externes:
au sein de l'organisme, elle sert a donner confiance a la direction. dans des conditions contractuelles ou autres elles sert a donner confiance aux clients ou autres.
contrôle qualité logicielle(CQL)
6
Série d’activités désignées pour évaluer la qualité d’un produit Une évaluation indépendante sur la capacité d’un processus logiciel de réaliser un produit logiciel utilisable.
Différence entre AQL et CQL
6
Objectifs de la qualité
6
le seul objectif de la qualité est de prévenir des défaults:
Défauts de conceptionsDéfauts de développementDéfauts de générationDéfauts de déploiementDéfauts d'usage
NB : Le zéro défaut n’existe pas en matière de logiciel
Parties impliquées dans la qualité
6
Qualité dans le contexte logiciel
Les facteurs de qualité logiciel:Les facteurs de qualité logiciel:
Validité Validité (besoin) : (besoin) : aptitude d'un produit logiciel à remplir exactement ses aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications. fonctions, définies par le cahier des charges et les spécifications.
FiabilitéFiabilité (ou robustesse) : (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans aptitude d'un produit logiciel à fonctionner dans des conditions anormales. des conditions anormales.
ExtensibilitéExtensibilité : : facilité avec laquelle un logiciel se prête à une modification ou à facilité avec laquelle un logiciel se prête à une modification ou à une extension des fonctions qui lui sont demandées. une extension des fonctions qui lui sont demandées.
RéutilisabilitéRéutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications. dans de nouvelles applications.
CompatibilitéCompatibilité : : facilité avec laquelle un logiciel peut être combiné avec facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels. d'autres logiciels.
108108EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
EfficacitéEfficacité : : Utilisation optimales des ressources matérielles. Utilisation optimales des ressources matérielles.
PortabilitéPortabilité : : facilité avec laquelle un logiciel peut être transférée sous facilité avec laquelle un logiciel peut être transférée sous différents environnements matériels et logiciels. différents environnements matériels et logiciels.
VérifiabilitéVérifiabilité : : facilité de préparation des procédures de test. facilité de préparation des procédures de test. IntégritéIntégrité : aptitude d'un logiciel à protéger son code et ses données contre des : aptitude d'un logiciel à protéger son code et ses données contre des
accès non autorisés. accès non autorisés.
Facilité d'emploiFacilité d'emploi : : facilité d'apprentissage, d'utilisation, de préparation des facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation. données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.
109109EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
Afin de garantir les caractéristiques de la qualité le Afin de garantir les caractéristiques de la qualité le génie logiciel la traduit en plusieurs facteurs :génie logiciel la traduit en plusieurs facteurs :
Internes à l’application (senties par le développeur)Internes à l’application (senties par le développeur)
Externes à l’application (senties par l’utilisateur final)Externes à l’application (senties par l’utilisateur final)
110110EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
ISO/CEI 9126ISO/CEI 9126 définit un langage commun pour modéliser les définit un langage commun pour modéliser les qualités d'un logiciel qualités d'un logiciel
Utilise des termes tel que Utilise des termes tel que
facteurs qualité;facteurs qualité; Caractéristiques;Caractéristiques; Sous-caractéristiques.Sous-caractéristiques.
111111EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
112112EL GHARBI Youssef, 2008
NB :
Ces différentes qualités ne sont pas toujours compatibles ni même réalisables, et il est nécessaire de trouver des compromis ...
Qualité dans le contexte logiciel
Facteurs clés la qualité logicielleFacteurs clés la qualité logicielle
Qualité dans le contexte logiciel
Pour améliorer l’expérience des utilisateurs il faudrait agir sur Pour améliorer l’expérience des utilisateurs il faudrait agir sur les deux composantes, seulement il est plus facile d’évaluer et les deux composantes, seulement il est plus facile d’évaluer et de budgétiser une mise à niveau du centre de données que de budgétiser une mise à niveau du centre de données que celle de la qualité du logiciel surtout lorsqu’il est déjà en celle de la qualité du logiciel surtout lorsqu’il est déjà en exploitation exploitation
Il importe donc de répondre à la question : Il importe donc de répondre à la question :
Quelles sont les caractéristiques d’un logiciel de haute Quelles sont les caractéristiques d’un logiciel de haute qualité ?qualité ?
115115EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
La qualité peut être :La qualité peut être :
TranscendantalesTranscendantales : difficiles à définir mais sont relatives à un : difficiles à définir mais sont relatives à un sentiment de satisfaction généré par des propriétés intangibles du sentiment de satisfaction généré par des propriétés intangibles du logiciel.logiciel.
Fitness for purpose : Fitness for purpose : accordance avec le besoin, les logiciels qui accordance avec le besoin, les logiciels qui donnent plus qu’on leur demandent imposent une courbe donnent plus qu’on leur demandent imposent une courbe d’apprentissage trop longue.d’apprentissage trop longue.
Industrielles Industrielles : Conformité avec les standards.: Conformité avec les standards.
Produit : Produit : Le point est mis sur les caractéristiques inhérentes du produit Le point est mis sur les caractéristiques inhérentes du produit qui résulteront à améliorer les caractéristiques externes.qui résulteront à améliorer les caractéristiques externes.
Valeur : Valeur : La qualité rime avec la prédisposition des clients à payer pour La qualité rime avec la prédisposition des clients à payer pour utiliser le logiciel.utiliser le logiciel.
116116EL GHARBI Youssef, 2008
Qualité dans le contexte logiciel
Du coté client les attentes sont simple est légitimes. Du coté client les attentes sont simple est légitimes. Dans l’absence de logiciels parfaits l’utilisateur Dans l’absence de logiciels parfaits l’utilisateur demande que :demande que :
Le logiciel doit répondre correctement comme spécifié.Le logiciel doit répondre correctement comme spécifié.
Le logiciel doit être utilisable.Le logiciel doit être utilisable.
117117EL GHARBI Youssef, 2008
A retenir …
La qualité externe d’un produit se mesure sur les critères visibles .
la qualité d’un produit se mesure par la qualité de ses processus
les environnement normatifs et méthodologique de ces deux axes de la qualité logicielle sont différents .
A retenir :
La qualité est omniprésente dans l’ensemble des processus d’ingénierie du logiciel . la qualité logicielle est une des propriété intrinsèques du produit et des processus qui concourent à le produire . La qualité se déploie suivant les axes :
- qualité du produit- qualité des processus métiers ( du logiciel ) - qualité des processus transverses ou
d’entreprise
La qualité de codageLa qualité de codage
Show me code written by ten developers and I'll show you ten different coding styles
La qualité de codageLa qualité de codage
Pourquoi coder en standard ?
La qualité de codageLa qualité de codage
un logiciel est rarement développé par une seule personne;
un logiciel est rarement maintenu par les même développeur;
Pénible tâche d’adaptation avec la productivité et la compréhension du code hétérogène;
La qualité de codage (La qualité de codage (problématiqueproblématique))
Cette homogénéité est assurée par la mise en oeuvre de conventions strictes respectées par tous.
La qualité de codage La qualité de codage SolutionSolution
PRINCIPES GENERAUX DE CONVENTION DE CODAGE
ÉQUILIBRE: équilibrer les performances et les norme de codage;
BRIEVETE: éviter le code inutile ; éviter les dissertations dans les commentaires.
UNIFORMITE: n’importe quel développeur pourra lire le code d’un autre le modifier;
CONSISTANCE:Les recommandations que vous adopterez doivent être appliquées à l’intégralité de votre projet
SYSTEME DE FICHIERS:
EXTENSIONS DES FICHIERS; FICHIERS COMMUNS; ORGANISATION; TAILLE DES SOURCES.
La qualité de codage La qualité de codage
EXTENSIONS DES FICHIERS Les noms des fichiers sources portent l’extension .java; le bytecode généré porte l’extension .class; les fichiers de configuration devraient porter
l’extension .properties.
La qualité de codageLa qualité de codage
FICHIERS COMMUNS:
Les fichiers les plus fréquemment joints au code source: le fichier de directive de compilation; le fichier build.xml (utilitaire Ant) le fichier de description du contenu d’un projet README.
La qualité de codageLa qualité de codage
ORGANISATION
La qualité de codageLa qualité de codage
Minimal
La qualité de codageLa qualité de codage
TAILLE DES SOURCES: Il est recommandé de ne pas excéder 2000 lignes dans
un fichier .java; ne pas dépasser les 80 colonnes;
La qualité de codageLa qualité de codage FORMATAGE/ INDENTATION
TABULATION:Il ne faut pas utilisé le caractère de tabulation car son interprétation varie selon les éditeurs
La qualité de codageLa qualité de codage FORMATAGE/ INDENTATION
TAILLE DES LIGNES:Une ligne ne doit pas excéder 80 colonnes
On revient à la ligne dans les conditions suivantes :
•après une virgule
•avant un opérateur
•de préférence au sein d’une parenthèse de haut niveau, plutôt que de petit niveau
La qualité de codageLa qualité de codage FORMATAGE/ INDENTATION
LIGNES BLANCHES: Les lignes blanches doivent être utilisées pour séparer
les méthodes, et des portions de code distinctes.
ESPACES:Les espaces doivent être utilisés à profusion, mais pas n’importe où !
L’espace est obligatoire dans les conditions suivantes : avant et après tout opérateur, sauf la parenthèse pour
laquelle cela est optionnel après toute virgule après tout mot réservé du langage avant et après toute accoladeL’espace est autorisé : entre le nom d’une méthode et la parenthèse ouvrante
listant ses paramètres
La qualité de codageLa qualité de codage FORMATAGE/ INDENTATION
En revanche, l’espace est proscrit : avant les point-virgules de fin d’instruction avant les crochets des tableaux entre une variable et les opérateurs de pré/post
incrément avant et après un opérateur de transtypage
La qualité de codageLa qualité de codage FORMATAGE/ INDENTATION
La qualité de codageLa qualité de codage FORMATAGE/ INDENTATION
La qualité de codageLa qualité de codage NOMMAGE
PACKAGE
La qualité de codageLa qualité de codage NOMMAGE
CLASSES ET INTERFACES
La qualité de codageLa qualité de codage NOMMAGE
METHODE
La qualité de codageLa qualité de codage NOMMAGE
Les noms des variables doivent respecter les conventions suivantes (d'après SUN):
1ère lettre en minuscule Mélange de minuscule, majuscule avec la première
lettre de chaque mot en majuscule Donner des noms simples et descriptifs Ne pas commencer les noms avec '$' ou '_' bien que ce
soit possible. Variable d'une seule lettre (pour un usage local)
int : i, j, k, m, et n char : c, d, et e boolean : b
La qualité de codageLa qualité de codage NOMMAGE
Constantes
La qualité de codageLa qualité de codage NOMMAGE
COMMENTAIRES
La qualité de codageLa qualité de codage
La qualité de codage La qualité de codage DéclarationDéclaration
Les variables doivent de préférence être déclarées lignes par lignes.
Exemple : int level; int frameWidth;
Sauf dans le cas de variables temporaires itératives pour lesquelles une déclaration globale sur une seule et même ligne est recommandée.
Exemple:int i,j,k ;
La qualité de codage La qualité de codage DéclarationDéclaration
Les types tableaux doivent être spécifiés sur le type et non sur la variable.
La qualité de codage La qualité de codage DéclarationDéclaration
Les variables doivent être déclarées au plus tôt
La qualité de codage La qualité de codage Déclaration/ORDREDéclaration/ORDRE
L’ordre de déclaration des entités du code source doit être le suivant :
1. les attributs de la classe a. en premier les statiques (static) b. en deuxième les publiques (public) c. ensuite les protégés (protected) d. et enfin les privés (private)
2. les méthodes a. en premier les statiques b. en deuxième les publiques c. ensuite les protégées d. et enfin les privées
Règles : Si une variable n’est initialisée qu’une seule fois, il est
préférable de la déclarer final. Si un paramètre de méthode ne doit pas être modifié, il
est préférable de le déclarer final.
La qualité de codageLa qualité de codage Best PraticesBest Pratices
La qualité de codageLa qualité de codage Best PraticesBest Pratices
Règle :
Il ne faut pas avoir directement dans le corps de méthodes des créations d’instances sur des classes non modifiables.
String au lieu de StringBuffer
Il est au contraire préférable de définir un membre static :
public static final String PROP_THE_PROPERTY = "theProperty";
La qualité de codageLa qualité de codage Best PraticesBest Pratices
Si plusieurs classes partagent un ensemble de constantes il est souvent préférable de les rassembler par groupe fonctionnel dans des interfaces ;
La qualité de codageLa qualité de codage Best PraticesBest Pratices
La règle : Dans un test, la partie constante est à la gauche de l’opérateur :
Ne jamais faire comme ça:if(prenom.equals(« youssef »){//instruction}
Faire comme ça:if(« youssef ».equals(prenom){//instruction}
Pour construire vos classes respectez le plus possible les règles de constructions des Java Beans; il suffit de suivre les conventions de nommage:
les attributs sont privés, voire protégés ; un accesseur est nommé d’après le nom de l’attribut,
ou en fonction du type de l’attribut ; un modificateur est nommé d’après le nom de l’attribut ;
utilisez uniquement accesseurs et modificateurs pour manipuler les attributs, même dans la classe ;
La qualité de codageLa qualité de codage Best PraticesBest Pratices
JSP Best Practices Separate HTML from Java Place business logic in JavaBeans Factor general behavior out of custom tag handler classes Favor HTML in Java handler classes over Java in JSPs Use an appropriate inclusion mechanism Use a JSP template mechanism Use stylesheets Use the MVC pattern Use available custom tag libraries Determine the appropriate level of XML compliance Use JSP comments in most cases Follow HTML best practices Utilize the JSP exception mechanism
La qualité de codageLa qualité de codage
Processus en cascade
Processus en cascade
Processus en cascade Propose de dérouler les phases projet de façon séquentielle Cité pour des raisons historiques
Points forts Distingue clairement les phases projet
Points faibles Non itératif Ne propose pas de modèles de documents
Analyse
Conception
Programmation
Test
Maintenance
Processus en cascade
Ce modèle repose sur les hypothèses suivantes : on ne peut pas construire la toiture avant les fondations ; les conséquences d'une modification en amont du cycle ont un impact majeur sur les
coûts en aval; de produire des livrables définis au préalable ; de se terminer à une date précise ; de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape
de validation-vérification
Les décideurs prennent le risque Les concepteurs assument… Les développeurs suivent…
Processus en cascade
Points forts Distingue clairement les phases projet
Points faibles Non itératif Ne propose pas de modèles de documents
Processus en cascade
Les méthodologies Agile
– "Les méthodes de développement de type Agile suivent un mode de développement itératif et incrémental, une planification de projet évolutive et encouragent les release fréquentes au client.
Elles incluent également toute une série d'autres valeurs et pratiques qui encouragent l'agilité et une réponse aux changements."
méthode Agile ?
Pas de planning Pas de cahier des charges Pas de gestion de projet Pas d’attention à la qualité Codage pur et dur
Agile ne signifie pas…
Taux d’échec des projets informatiques reste important
« Non respect des délais, coûts et fonctionnalités initialement prévus »
Pourquoi les méthodes Agileapparaissent-elles ?
Manques de communication.
Migrations d’un système à un autre.
Dépassements des délais.
Abandon du projet.
Principales causes des échecs deprojets
Les méthodes Agile répondent à ces problèmes en mettant l’accent sur deux aspects:
– L’implication du client
– Les développements itératifs et incrémentaux
Solutions proposées par Agile
Développement itératif et incrémental:
– Un développement itératif est une approche utilisée pour développer du logiciel au cours de laquelle l’ensemble du cycle se compose de plusieurs itérations successives.
– Développement Incrémental: logiciel construit progressivement (par sous systèmes successifs)
Solutions proposées par Agile
Développement itératif etincrémental
Impliquer le client au maximum dans le projet
Moyens:
client sur site développement chez le client prototypes …
Solutions proposées par Agile
Exemple de scrum :
La plupart des méthodes Agile mettent l’accent sur:
Intégration du changement Cycles de développement courts et release fréquentes Design le plus simple possible Refactoring Pair programming Test-driven development
Autres concepts fondamentaux Agile
Plusieurs facteurs à prendre en compte dont:
Petite équipe (10-15) Equipe composée d’une majorité de seniors Maîtrise de la gestion de projet Exigences floues et variables Client disponible (sur site = optimal)
Sur quels types de projets utiliser une méthode Agile ?
Il existe plusieurs methodes agiles selon la taille du projet et de l’équipe
Les méthodes agiles
La méthode XP
XP
XP Ensemble de « Bests Practices » de développement (travail en équipes, transfert
de compétences…) Cible des projets de moins de 10 personnes
XP
L'Extreme Programming repose sur 5 valeurs fondamentales : La communication
C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un coach se charge de l'identifier et de remettre ces personnes en contact.
La simplicité La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple
sera plus facile à faire évoluer. Le feedback
Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet. Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.
Le courage Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un projet, jeter du code pour en produire un
meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.
Le respect Cette valeur fut ajoutée dans la deuxième édition de "Extreme Programming Explained" de A. CockBurn.
XP
Points forts Itératif
la revue de code est une bonne pratique, elle sera faite en permanence (par un
binôme) ; Innovant: programmation en duo, kick-off matinal debout … Simple à mettre en œuvre la conception sera faite tout au long du projet Fait une large place aux aspects techniques : prototypes, règles de développement, tests… choisir toujours la solution la plus simple puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour; puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous
adapter au changement. Test Dr
XP
Points faibles Ne couvre pas les phases en amont et en aval au développement : capture des
besoins, support, maintenance, tests d’intégration… Élude la phase d’analyse, si bien qu’on peut dépenser son énergie à faire et défaire Assez flou dans sa mise en œuvre: quels intervenants, quels livrables ?
XP
Principe Planning Game Small releases Tests Refactoring Conception simple Pair programming Collective Code Ownership Intégration continue On-Site Customer Semaine de 40 heures(pas de heures sup) Coding standards
La méthode ScrumDéfinition
Le terme Scrum est emprunté au rugby et signifie mêlée Méthode agile pour la gestion de projets Elle s'articule autour d'une équipe soudée
La méthode ScrumDéfinition
Scrum permet :
d’améliorer la communication et la coopération de maximiser la productivité de détecter et de supprimer tout obstacle
Techniquement parlons, Scrum est un processus léger permettant de gérer et de contrôler le développement de produits logiciels, mettant en oeuvre des pratiques itératives et incrémentales
La méthode Scrumdiagramme Scrum n°1
La méthode Scrumdiagramme Scrum n°2
La méthode ScrumPrincipes
Le manifeste agile utilisé par Scrum résume sa philosophie en quatre concepts :
1. Individus et interactions faire intéragir les gens au maximum
2. Logiciel qui fonctionne seul critère permettant de mesurer l'avancement du projet
3. Collaboration du client le client est au centre du processus de développement
4. Réponse aux changements logiciel développé répondant parfaitement aux véritables besoins
La méthode Scrum Techniques et pratiques
Rôles
La méthode Scrum Techniques et pratiques
Le directeur de produit : prend les décisions quant à l’orientation du projet et définit l’ordre de réalisation des fonctionnalités du produit
L’équipe : groupe soudé de personnes ne comportant pas de rôles prédéfinis, autogéré et les décisions sont prises ensemble
ScrumMaster : veille sur le plein régime, élimine les obstacles, protége l’équipe de l’extérieur et assure l’application des pratiques Scrum
Autres intervenants : personnes souhaitant avoir une vue sur le projet sans s’investir. Scrum conseille de protéger l’équipe de ces personnes.
La méthode Scrum Techniques et pratiques
Gestion des besoins
La méthode Scrum Techniques et pratiques
Backlog de produit : liste des fonctionnalités(items) du produit à réaliser. C’est le directeur du produit qui définit l’ordre de réalisation.
Backlog de sprint : Avant de démarrer un sprint, on choisit quels items du backlog de produit seront réalisés. L’équipe se charge ensuite de décomposer chaque item en liste de tâches élémentaires estimées en heures et ne devant pas durer plus de 2j. On constitue ainsi le backlog de sprint
La méthode Scrum Techniques et pratiques
Planification
La méthode Scrum Techniques et pratiques
Sprint : processus itératif durant en pratique 2 à 4 semaines. Un sprint possède un but et doit réaliser une liste d’items (backlog de sprint)
Release : favorise la lisibilité du projet et permet de mieux identifier les versions.
Quotidien : le Scrum, point sur l’avancement des tâches et sur les difficultés rencontrées.
La méthode Scrum Techniques et pratiques
Réunions :
Réunion de planification :
Ne doit pas durer plus de 4h Durant cette réunion sont choisis les items du
backlog de sprint. Le directeur de produit prend les décisions en
accord avec l’équipe qui possède l’expertise technique pour juger la faisabilité
La méthode Scrum Techniques et pratiques
Réunion au quotidien : Ou Daily Scrum, ne doit pas durer plus de 15min. Chaque membre réponds aux 3 questions
suivantes :Qu'est-ce que j'ai fait hier ?
Qu'est-ce que je compte faire aujourd'hui ?
Quelles difficultés est-ce que je rencontre ?
C'est le niveau quotidien du principe inspect and
adapt de Scrum
La méthode Scrum Techniques et pratiques
Revue de sprint : Ne doit pas durer plus de 4h. L’objectif est de valider le logiciel qui a été produit pendant le sprint et produire le bilan du sprint.L’équipe énonce les items du backlog de sprint qu’elle a réalisée et effectue une démonstration.Le directeur de produit valide chaque
fonctionnalité.Le directeur de produit , en accord avec l’équipe,
peut aménager le backlog de produit et/ou la planification de la release.
La méthode Scrum Techniques et pratiques
Rétrospective du sprint : réunion en interne à l’équipe. Le but est de s’exprimer sur ce qui est bien
et mal passé et définir ainsi des propositions
d’améliorations. Le ScrumMaster peut aussi à ce niveau définir
des améliorations pour le backlog de produit.
La méthode Scrum Environnement de travail
Pas de changements imposés pendant un sprint Toute l'équipe dans une même pièce Un bon outil de suivi de projet Prévenir des interventions extérieures Tout ce qui peut rendre l'équipe plus sereine, productive et efficace. C’est le ScrumMaster qui veille à maintenir la qualité de
l’environnement de travail
La méthode Scrum Documentation
Scrum n'impose aucune documentation particulière Des documents sont implicitement produits (backlogs, Sprint Burndown
Chart, Release Burndown Chart, …). Un document ne doit être produit que si son utilité est réelle et immédiate. Des manuels utilisateurs à chaque sprint et non pas en fin de projet.
Utilisation des vidéos de démonstrations commentées.
La méthode Scrum Documentation
Des diagrammes métiers (processus, objets…) accompagnant le backlog de produit
Des diagrammes de séquence pour les items les plus complexe du backlog de produit
Des diagrammes d’architecture du logiciel, à savoir : composants, classes, …
La méthode Scrum Documentation
Sprint Burndown Chart
La méthode Scrum Documentation
Release Burndown Chart
Contraintes de l’agilité
Une organisation adaptée : il est très difficile de faire admettre aux organes décideurs d'une entreprise de travailler de façon Agile.
Un état d'esprit : être Agile, c'est privilégier l'esprit d'équipe et pas seulement dans la réalisation technique.
Un environnement favorable : éliminer les contraintes dans une entreprise n'est pas toujours évident. Comment limiter les appels téléphoniques trop fréquents, les irruptions dans la pièce de l'équipe, les opérations urgentes demandées aléatoirement par la direction, etc. ?
Outils
Quelques outils OpenSource implémentent les principes et concepts de Scrum :
IceScrum
TheScrum
Eclipse Process Framework, intégre un plugin Scrum
….
Conclusion
Les méthodes agiles constituent des atouts en matière de développement Leurs maîtrises et leurs applications permettront sans aucun doute aux
petites boites d'améliorer la qualité de leur produit. L’approche agile est nouvellement crée et appliquée, par conséquent les
outils restent toujours limitésquant aux services qu'ils offrent
2TUP
Plan :
Définition d’un Processus de développement Logiciel.
Processus Unifié Caractéristiques
Organisation du Processus
Processus 2TUP
Définition d’un Processus de développement Logiciel
Un processus définit une séquence d’étapes, en partie ordonnées, qui concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant. L’objet d’un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles.
Processus Unifié
Un processus unifié (PU ou UP en anglais pour Unified Process) est un processus de développement logiciel construit sur UML. Les processus unifiés sont le résultat de l’unification, non pas des processus, mais plus exactement les meilleures pratiques du développement objet.
Caractéristiques :
Itératif et incrémental :
Le logiciel est itératif dans le sens où il propose de faire des itérations lors de ses différentes phases, ceci garantit que le modèle construit à chaque phase ou étape soit affiné et amélioré. Chaque itération peut servir aussi à ajouter de nouveaux incréments.
Conduit par les cas d’utilisation :Orienter le processus par l’utilisateurpour répondre aux besoins de celui-ci.
Centré sur l’architecture :Définir les modèles tout au long du processus de développement pour contribuer à établir une architecture cohérente et solide.
piloté par les risques:
Les causes majeures d’échec d’un projet logiciel doivent être écartées en priorité.
Les deux principales causes sont: l’incapacité de l’architecture technique à répondre aux
contraintes opérationnelles l’inéquation du développement aux besoins utilisateurs.
Organisation du Processus
Pré étude: évaluer la valeur ajoutée du développement et la capacité technique à le réaliser .
Élaboration : sert à confirmer
l’adéquation du système aux besoins des utilisateurs et à livrer l’architecture de base.
Construction : sert à livrer
progressivement toutes les fonctions du
système. Construire autour de la création et
de la maintenance d’un modèle. Transition : déployer le système sur des sites
opérationnels.
Processus 2TUP
2TUP « 2 Track Unified Process» est un processus de développement logiciel qui:
Implémente le Processus Unifié;Gère la complexité technologique en donnant
part à la technologie dans son processus de développement;
Apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise.
2TUP propose un cycle de développement en Y, qui prend en compte les contraintes de changement continuel imposées aux systèmes d’information des organisations .Ainsi que toute évolution imposée peut se décomposer et se traiter parallèlement suivant un axe fonctionnel et un axe technique.
Caractérisé originale par la méthode de Roques, la distinction d’une branche fonctionnelle et d’une branche technique offre de nombreux avantages : On prend en compte des contraintes et des exigences qui portent d’une part sur le métier
des utilisateurs (branche fonctionnelle) et sur l’environnement (branche technique). Cette distinction permet la réutilisation ultérieure : soit reprendre la même analyse pour un
contexte différent (changement de technologie), soit profiter d’une expertise technique pour l’adapter à des fonctions différentes.
Caractéristiques :
Branche gauche (fonctionnelle) Capture des besoins fonctionnels : focalisation sur le métier et sur les
utilisateurs, qualification du risque de produire un système inadapté aux utilisateurs.
Analyse : étude des spécifications fonctionnelles de manière à obtenir une idée de ce que va réaliser le système en terme de métier.
Branche droite (architecture technique) Capture des besoins techniques : définition du modèle d’analyse
technique l’établissement des couches logicielles en y spécifiant les activités techniques attendues.
Conception générique : définition des composants, génération du modèle de conception technique ou design pattern, délivrance des services techniques et assurance de la réponse aux exigences opérationnelles du système.
Branche du milieu Conception préliminaire : intégration du modèle d’analyse
fonctionnelle dans l’architecture technique, la manière à tracer la cartographie des composants du système à développer.
Conception détaillée : envisagement de la manière à réaliser chaque composant.
Codage et tests : réalisation effective et test au fur et à mesure les unités de code réalisées .
Recette et validation : validation du
fonctionnalité des systèmes à développer
Points forts Points faibles
- Itératif-Fait une large place à la technologie et à la gestion du risque.
- Définit les profils des intervenants, les livrables, les plannings, les prototypes.
-Plutôt superficiel sur les phases situées en amont et en aval du développement :
capture des besoins, support, maintenance, gestion du changement
- Ne propose pas de
documents types.
Rational Unified ProcessRational Unified Process
Rational Unified Process (RUP) : est un processus de conception/développement de logiciel défini par Rational Software.
http://www.rational.com/
Développement itératifDéveloppement itératif
– Les risques sont évalués avant Les risques sont évalués avant
– Les premières itérations permettent Les premières itérations permettent d’avoir des retours utilisateur d’avoir des retours utilisateur
– Le test et l’intégration sont continus Le test et l’intégration sont continus
– Les jalons permettent de fixer les Les jalons permettent de fixer les objectifsobjectifs
– Les avancées sont mesurées au fur Les avancées sont mesurées au fur et à mesure de l’implémentationet à mesure de l’implémentation
– Des maquettes intermédiaires Des maquettes intermédiaires peuvent être déployéespeuvent être déployées
Accroître la productivité Accroître la productivité en en conception/développemeconception/développementntTous les membres partagentTous les membres partagent
• Des bases de connaissanceDes bases de connaissance
• Une même méthode Une même méthode
• Une organisation du travailUne organisation du travail
• Un langageUn langage
Designer /Developer
Analyst Tester
DatabaseAdministrator
PerformanceEngineer
Release Engineer
Project Leader
Guide
Amplifient Utilisent
Oriente
Automatisent
Se focalise
Fédèrent
Instrumentent AccélèrentOutils
Travailleur
Services
Le langage RUP : un modèle Le langage RUP : un modèle visuelvisuel
Activité
Quatre éléments de modélisation dans RUPQuatre éléments de modélisation dans RUP
• Membre est le qui : Chef de projet, Analyste, Testeur, Utilisateur, etc.
• Artéfact est le quoi : Document de l’architecture, Modèle des cas d’utilisation, Fichier exécutable, etc.
• Activité est le comment : Analyse de cas d’utilisation, Conception de cas d’utilisation, etc.
• Enchaînement d’activités est le quand : Modélisation de métier, implémentation, test, etc.
Décrit un rôle dans le
processus
Membre
Use-Case Specifier
NotationsNotations
Activité
Décrit une partie du travail
Décrit une connaissance ou une donnée
Artéfact
Use-Case Package
Use Case
Responsable de
Concepteur Analyse de cas d ’utilisation
Conception de cas d ’utilisation
Réalisation de cas d ’utilisation
est responsable de
Exemple : rôles du concepteurExemple : rôles du concepteur
activité1
ConnaissanceDocument
produit
activité2
Planification des RHPlanification des RH
Re s o u rc e Wo rke r Ac tiv itie s
Paul
Mary
Joe
Sylvia
Stefan
Designer
Use-Case Specifier
Use-Case Designer
Design Reviewer
Architect
Define Operations...
Describe a Use Case...
Distribute Behavior...
Review Use-Case Model...
Define Use-Case ViewDefine Logical Viiew...
Chaque membre est considéré comme un acteur
Exemple d’un WorkflowExemple d’un Workflow
RUP est itératif et incrémentalRUP est itératif et incrémental
Exigences
Planification initiale
PlanificationTests
Déploiement
Implémentation
Analyse & conception
Gestion Environnemen
t
Chaque itération a pour finalité une version exécutable.
RUP
RUP Le RUP est à la fois une méthodologie et un outil prêt à l’emploi
(documents types partagés dans un référentiel Web) Cible des projets de plus de 10 personnes
Analyse des besoins
Élaboration Construction TransitionProcessus projetProcessus organisationnelsSpécificationsAnalyse & ConceptionImplémentationTestsDéploiementSupport du projetConfigurationGestion du projetEnvironnement
Phases
Itérations
ItérationPréliminaire
Iter.#1
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUP
6 enchaînements d'activités
essentielles
• Modélisation du métier
• Gestion des exigences
• Analyse et Conception
• Implémentation
• Test
• Déploiement
3 enchaînements d'activités de soutien
• Gestion de Projet
• Gestion de la configuration et des changements
• Environnement
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPModélisation du métierModélisation du métier
• de décrire la structure et la dynamique de l'organisation (ou de l ’équipe participative)
• de garantir que les clients, les utilisateurs finaux et les développeurs partagent une vision commune de l'organisation
• de réaliser une base d'information qui contiendra le cahier des charges du produit et la planification des tâches de l ’organisation.
Il a pour but
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPGestion des exigencesGestion des exigences
Il a pour but
• de définir une vision du produit,
• de traduire cette vision en un modèle de cas d'utilisation, (ce modèle, accompagné des spécifications externes, constitue le cahier des charges logicielles),
• d’organiser et de gérer les exigences,
• de définir et de construire une maquette de l'interface utilisateur.
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPAnalyse et conceptionAnalyse et conception
• L'objectif de l'analyse est de comprendre le cahier des charges et d ’écrire les spécifications internes. L'analyse permet d'obtenir une vue interne du produit
• La conception a pour but de définir l'architecture du système/produit
• L'analyse se concentre sur le "quoi faire", la conception se concentre sur le "comment le faire".
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPImplémentationImplémentation
• L'objectif est de créer les composants : sources, scripts, puis exécutables...
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPTestTest
• La phase de test a pour objectif d'évaluer le niveau de qualité atteint par le produit et d'en tirer les conclusions. Elle s'appuie sur les cas d'utilisation et définit des cas de test.
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPDéploiementDéploiement
• Le but de l'enchaînement des activités de déploiement est de livrer le produit aux utilisateurs finaux.
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPGestion de projetGestion de projet
• La planification d'un projet itératif
• La gestion des risques
• Le contrôle des progrès.
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPGestion de la configuration et des changementGestion de la configuration et des changement
• Le but de la gestion de la configuration et des changements est de garder la trace de tous les éléments tangibles qui participent au développement, et de suivre leur évolution.
Enchaînement d’activités dans RUPEnchaînement d’activités dans RUPEnvironnementEnvironnement
• un processus de développement adapté au projet
• des outils de travail qui aident à réaliser les activités et les artefacts du processus.
Il a pour but de fournir
Phases dans RUPPhases dans RUP
Inception Conception Construction Transition
Temps
Jalon : objectifs et cycle de vie
Jalon : architecture du système
Jalon :prototype
Jalon : livraison du produit
InceptionInception
• Il s’agit de décrire quelle vision on a du produit final et où on veut aller, de réaliser une étude de rentabilité et de définir le projet.
• La phase Inception se termine par le jalon « objectifs et cycle de vie »
ConceptionConception
• Il s’agit de
¤ planifier les activités et les ressources nécessaires à la réalisation du projet
¤ spécifier les fonctionnalités
¤ concevoir l’architecture
• La phase de conception se termine par le jalon « architecture du système »
ConstructionConstruction
• Il s’agit de construire le système et de faire évoluer la vision, l ’architecture et les plans de développement jusqu’à l ’obtention d’un produit prêt à être testé.
• La phase construction se termine par le jalon « prototype »
TransitionTransition
• Il s’agit de soumettre le produit aux utilisateurs (béta-test),
• La phase transition se termine par le jalon « livraison du produit » ou par une nouvelle itération
Ambition de RUPAmbition de RUP
• Faire face aux changements en cours du projet qui restent les causes principales de l’échec du projet. • Par exemple :
¤ Les utilisateurs changent leurs exigences
¤ L’équipe de développement modifie l’architecture du logiciel
Changement des exigencesChangement des exigences
• Au départ, les utilisateurs ne savent pas quelles sont leurs exigences et comment les spécifier de façon précise.
• Ils changent leurs exigences quand ils voient les livrables
Effet: IKIWISIIKIWISI
I Know It When I See It - Je le saurai quand je l ’aurai vu
Bary Boehm - Université de Californie du Sud
Changements de l’architectureChangements de l’architecture
• Les membres de l’équipe :
¤ n’ont peut-être pas bien compris le système exigé
¤ n’ont peut-être pas partagé une même compréhension du système
RUP est centré sur l’architectureRUP est centré sur l’architecture
Vue logiqueVue pratique
Vue déploiement
Vue d'implémentation
Vue des processus
ProgrammeursGestion du logicielUtilisateur final
Fonctionnalité
Analystes/TesteursComportement
Intégrateurs systèmePerformanceCapacité à grandirDébit d'information
Ingénieurs SystèmeTopologie du systèmeLivraison, installationCommunication
Vue des cas d'utilisation
Briques d’organisationBriques d’organisation
Contrôle des changements
Management
Composants logiciels
Processus itératif
Modèle visuel Qualité
RUP : tracer les changementsRUP : tracer les changements
• RUP définit un enchaînement d’activités de soutien : gestion des configurations et des changements
• RUP est piloté par les cas d ’utilisation
RUP est piloté par les cas d’utilisationRUP est piloté par les cas d’utilisation
Modèle d’implémentationModèle d’implémentation Modèle de test
Modèle de test
Vérifié parVérifié parRéalisé parRéalisé par
Implémenté parImplémenté par
Modèle de conceptionModèle de conception
AvantagesAvantages
• RUP améliore la qualité du produit
• RUP augmente le taux de succès du projet
• RUP est supporté par les outils du Rational Software
RUP améliore la qualité du produitRUP améliore la qualité du produit
• RUP améliore la compréhension du système
¤ RUP est itératif
¤ RUP reste centré sur l’architecture
¤ RUP utilise UML pour modéliser le logiciel
RUP améliore la qualité du produitRUP améliore la qualité du produit
• RUP contrôle et trace le processus de transformation de la compréhension du système en produit
¤ RUP est piloté par les cas d’utilisation
¤ RUP contrôle l’avancement de travail à l ’aide des livrables fournis dans les jalons
RUP augmente le taux de succès du projetRUP augmente le taux de succès du projet
RUP permet d’anticiper et de limiter les risques. On peut mieux les traiter quand ils sont petits...
RUP est intégré par les outils du Rational SoftwareRUP est intégré par les outils du Rational Software
Rose
TeamTest
RequisitePro
SoDA ClearCase
ClearQuest
PurifyQuantify
PureCoverage
Visual StudioApex
Interface
Présentation des rôles
Présentation des scénarios
Diagramme de la collaboration
Présentation des classes (UML)
Diagramme des états de transition
Diagramme des composants
Points faibles de RUPPoints faibles de RUP
• RUP ne supporte pas les multi-projets
• RUP exige des experts
• RUP est propriété de Rational Software
RUP est un cadre de processusRUP est un cadre de processus
• RUP décrit qui, quoi, comment et quand faire à l’aide d’un langage visuel
• RUP apporte des outils et une méthode d’organisation pour l’ingénierie participative
• RUP apporte une vision unifiée sur le processus qui peut être partagée par tous les acteurs
• Cible des projets de plus de 10 personnes
2TUP
2TUP2TUP S’articule autour de l’architectureS’articule autour de l’architecture Propose un cycle de Propose un cycle de
développement en Ydéveloppement en Y Détaillé dans « UML en action »Détaillé dans « UML en action » Cible des projets de toutes taillesCible des projets de toutes tailles
2TUP = Two Tracks Unified Process
268268EL GHARBI Youssef, 2008
269269EL GHARBI Youssef, 2008
2TUP
Points fortsPoints forts
ItératifItératif Fait une large place à la technologie et à la gestion du risqueFait une large place à la technologie et à la gestion du risque Définit les profils des intervenants, les livrables, les plannings, les Définit les profils des intervenants, les livrables, les plannings, les
prototypesprototypes
Points faiblesPoints faibles
Plutôt superficiel sur les phases situées en amont et en aval du Plutôt superficiel sur les phases situées en amont et en aval du développement : capture des besoins, support, maintenance, développement : capture des besoins, support, maintenance, gestion du changement…gestion du changement…
Ne propose pas de documents types Ne propose pas de documents types
270270EL GHARBI Youssef, 2008
Résumé
Méthodologie Personnes Profiles avantages
XP <10 Programmeurs Bonnes pratiques
2TUP 5<n<15 +analystes
+concepteur
+testeurs
+processus
+phases
RUP >10 +intégrateurs
+chef de projets
+ingénieur system
+processus détaillés
+documents livrables
271271
Résumé
Les processus peuvent se compléter plus qu’ils Les processus peuvent se compléter plus qu’ils n’entrent en concurrencen’entrent en concurrence
Analyse des besoins
Élaboration Construction TransitionProcessus projetProcessus organisationnelsSpécificationsAnalyse & ConceptionImplémentationTestsDéploiementSupport du projetConfigurationGestion du projetEnvironnement
Phases
Itérations
ItérationPréliminaire
Iter.#1
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
RUP
2TUP
XP
272272EL GHARBI Youssef, 2008
Conclusion
Ne passez pas des mois Ne passez pas des mois àà d dééfinir votre mfinir votre mééthodologie de thodologie de ddééveloppement !veloppement !
Prenez connaissance des processus les plus utilisPrenez connaissance des processus les plus utiliséés pour en s pour en intintéégrer un ou plusieurs grer un ou plusieurs àà votre m votre mééthodologie de projet.thodologie de projet.
ExempleExemple Les valeurs dLes valeurs d’’XP et quelques rXP et quelques rèègles (communication, simplicitgles (communication, simplicitéé, ,
feedback et feedback et éénergie)nergie) LesLes documentsdocuments types du RUP et leur enchatypes du RUP et leur enchaîînementnement La branche technique du 2TUPLa branche technique du 2TUP
273273EL GHARBI Youssef, 2008
Model de maturité CMM
EL GHARBI Youssef, 2008 274274
Model de maturité CMM
Créé à la Créé à la Software Engineering Institute (SEI), dans l’université (SEI), dans l’université de Pittsburg et utilisé extensivement dans des projets de Pittsburg et utilisé extensivement dans des projets d’envergure dans le monde.d’envergure dans le monde.
Approche étagée, les bonnes pratiques préconisées par des Approche étagée, les bonnes pratiques préconisées par des domaines de processus eux-mêmes regroupés en 5 niveaux domaines de processus eux-mêmes regroupés en 5 niveaux de maturité.de maturité.
Le CMM définit les processus à suivre comme conditions pour Le CMM définit les processus à suivre comme conditions pour passer d’un niveau à un niveau supérieur. passer d’un niveau à un niveau supérieur.
La plupart des administrations américaines (et plusieurs dans La plupart des administrations américaines (et plusieurs dans le monde) requièrent que leur partenaires SSI opèrent au le monde) requièrent que leur partenaires SSI opèrent au moins au niveau 3 du CMM moins au niveau 3 du CMM
275275EL GHARBI Youssef, 2008
Model de maturité CMM
CMM.CMM. N1 : Initial (N1 : Initial (initialinitial),), N2 : Géré, répétable (N2 : Géré, répétable (repeatablerepeatable),), N3 : Défini (N3 : Défini (defineddefined),), N4 : Géré, contrôlé (N4 : Géré, contrôlé (quantitatively managedquantitatively managed),), N5 : En optimisation (N5 : En optimisation (optimizingoptimizing).).
276276EL GHARBI Youssef, 2008
Model de maturité CMM
Comment se déroule une démarche d'amélioration basée sur le modèle CMMI ?
Pour mettre en place une démarche d'amélioration basée sur le Pour mettre en place une démarche d'amélioration basée sur le modèle CMMI, un projet dédié est créé et constitué : modèle CMMI, un projet dédié est créé et constitué :
De membres de l'organisation qui sera évaluée De membres de l'organisation qui sera évaluée De membres de sociétés externes De membres de sociétés externes
278278EL GHARBI Youssef, 2008
Comment se déroule une démarche d'amélioration basée sur le modèle CMMI ?
Le projet doit choisir la société externe, certifiée par le SEI, qui Le projet doit choisir la société externe, certifiée par le SEI, qui conduira l'évaluation.conduira l'évaluation.
279279EL GHARBI Youssef, 2008
Le projet se déroule en plusieurs phases :Le projet se déroule en plusieurs phases :1.1. Initialisation Initialisation 2.2. Définition Définition 3.3. Accompagnement Accompagnement 4.4. Evaluation « à blanc »Evaluation « à blanc »5.5. Evaluation officielle Evaluation officielle
280280EL GHARBI Youssef, 2008
InitialisationInitialisation : Evaluation initiale dans laquelle le niveau de : Evaluation initiale dans laquelle le niveau de maturité de l'organisation est défini, qui débouche sur maturité de l'organisation est défini, qui débouche sur l'établissement d'un plan d'actionsl'établissement d'un plan d'actions
281281EL GHARBI Youssef, 2008
DéfinitionDéfinition : organisation de workshops constitués de membres : organisation de workshops constitués de membres d'équipe projets de l'organisation afin d'implémenter les d'équipe projets de l'organisation afin d'implémenter les pratiques déclinées pour les projets (en tenant compte du pratiques déclinées pour les projets (en tenant compte du contexte et de l'existant)contexte et de l'existant)
282282EL GHARBI Youssef, 2008
AccompagnementAccompagnement : Les pratiques définies dans les workshops : Les pratiques définies dans les workshops sont déployées dans les projets au travers de sessions de sont déployées dans les projets au travers de sessions de formation et de « coaching ».formation et de « coaching ».
283283EL GHARBI Youssef, 2008
EvaluationEvaluation « à blanc » : Ce sont des évaluations non officielles « à blanc » : Ce sont des évaluations non officielles (exemple : mini-check, GO/NOGO) qui permettent de donner (exemple : mini-check, GO/NOGO) qui permettent de donner un état des lieux des pratiques. Elles donnent lieu à un état des lieux des pratiques. Elles donnent lieu à l'établissement d'un plan d'action, et donnent une idée de la l'établissement d'un plan d'action, et donnent une idée de la date d'évaluation officielle.date d'évaluation officielle.
284284EL GHARBI Youssef, 2008
EvaluationEvaluation officielle : officielle : Collecte de preuves par l'équipe d'évaluation au sein des Collecte de preuves par l'équipe d'évaluation au sein des
projets de l'organisation projets de l'organisation « Readiness review » : analyse des preuves collectées afin de « Readiness review » : analyse des preuves collectées afin de
déterminer les points forts et les points faibles de déterminer les points forts et les points faibles de l'organisation l'organisation
Evaluation sur site : il s'agit essentiellement d'interviews Evaluation sur site : il s'agit essentiellement d'interviews Cotation et présentation des résultats, qui sont ensuite Cotation et présentation des résultats, qui sont ensuite
envoyés au SEI envoyés au SEI
285285EL GHARBI Youssef, 2008
Pourquoi CMMI
Pourquoi CMMI
les coûts de production sont optimisés
risques réduits : les résultats sont plus prévisibles, les engagements plus fiables
Le client a une garantie d'utilisation des meilleures pratiques
les meilleures pratiques sont capitalisées
Model de maturité CMM
Niveau initial :Niveau initial :
Les processus s’improvisentLes processus s’improvisent
Faute de stabilité de l’environnement, la réussite des Faute de stabilité de l’environnement, la réussite des projets repose sur les performances individuelles.projets repose sur les performances individuelles.
Le logiciel produit marche mais il dépasse généralement Le logiciel produit marche mais il dépasse généralement les prévisions.les prévisions.
Certains projets sont abandonnés en cas de crise et le Certains projets sont abandonnés en cas de crise et le succès est difficile à reproduire.succès est difficile à reproduire.
288288EL GHARBI Youssef, 2008
Model de maturité CMM
Niveau Géré, répétable :Niveau Géré, répétable :
Certains processus sont répétés.Certains processus sont répétés.
Un ensemble de pratiques de gestion de projets sont Un ensemble de pratiques de gestion de projets sont installés.installés.
Une discipline minimale est installéeUne discipline minimale est installée
Il existe comme même un risque d’excéder les délaisIl existe comme même un risque d’excéder les délais
289289EL GHARBI Youssef, 2008
Model de maturité CMM
Niveau définit :Niveau définit :
Les processus sont bien définis sur le tempsLes processus sont bien définis sur le temps
Les bonne pratiques et standards sont suivisLes bonne pratiques et standards sont suivis
L’organisation établi des objectifs à atteindre dans ses L’organisation établi des objectifs à atteindre dans ses processusprocessus
La différence avec le niveau 2 est surtout dans les objectifs La différence avec le niveau 2 est surtout dans les objectifs et standardset standards
290290EL GHARBI Youssef, 2008
Model de maturité CMM
Niveau géré ,contrôlé (quantitatively managed):Niveau géré ,contrôlé (quantitatively managed):
Des mesures précises sont établis afin d’évaluer l’efficacité.Des mesures précises sont établis afin d’évaluer l’efficacité.
L’organisation définie des mesure qualitatives quantifiées L’organisation définie des mesure qualitatives quantifiées pour les atteindre sur le tempspour les atteindre sur le temps
Ces mesures ajoutent la capacité de prévoir l’issue des Ces mesures ajoutent la capacité de prévoir l’issue des projetsprojets
291291EL GHARBI Youssef, 2008
Model de maturité CMM
Niveau optimisé : Niveau optimisé :
Les processus sont graduellement optimisésLes processus sont graduellement optimisés
Les technologies et innovations sont mises à contribution.Les technologies et innovations sont mises à contribution.
Les objectifs sont revus à la hausseLes objectifs sont revus à la hausse
292292EL GHARBI Youssef, 2008
Model de maturité CMM
Les prescriptions que propose CMM afin de monter Les prescriptions que propose CMM afin de monter de niveau intéressent les domaines suivant :de niveau intéressent les domaines suivant :
293293EL GHARBI Youssef, 2008
Processus par catégorie
294294EL GHARBI Youssef, 2008
Processus par niveau de maturité
295295EL GHARBI Youssef, 2008
Model de maturité CMM
296296EL GHARBI Youssef, 2008
COBIT
L'utilisation des technologies de l'information (TI) est largement répandue dans la plupart des entreprises. Les systèmes d'information, opérationnels et stratégiques, sont porteurs d’avantages substantiels en termes de productivité et d'opportunité d'affaires. En revanche, ces systèmes apparaissent vulnérables, face à un large éventail de menaces souvent imprévisibles. La compréhension de ces risques et leur gestion est donc un problème majeur qui concerne les directions des entreprises, les propriétaires des processus d'affaire et les auditeurs.
COBIT un modèle de référence utilisé pour l'audit et la maîtrise des systèmes d'information.
COBIT se positionne comme un référentiel à la fois d’audit et de gouvernance, aligné sur les métiers et la stratégie de l’entreprise ; (la gouvernance regroupant quant à elle l’ensemble des processus et des procédures organisationnelles de pilotage des TI.)
COBIT participe à la gouvernance des SI en garantissant :
L’alignement du SI sur le métier de l’entreprise ; La maximisation des avantages issus du recours aux TI ; L’optimisation des dépenses informatiques ; La maîtrise et l’évaluation des risques et des bénéfices ; La fourniture de métriques de référence.
CobiT fournit aux gestionnaires, auditeurs et utilisateurs de TI, des indicateurs, des processus et des pratiques pour les aider à maximiser les avantages issus du recours à des technologies de l'information et à l'élaboration de la gouvernance et du contrôle d'une entreprise. Il les aide à comprendre leurs systèmes de TI et à déterminer le niveau de sécurité et de contrôle qui est nécessaire pour protéger leur entreprise.
Le modèle CobiT se focalise sur ce que l’entreprise a besoin de faire et non sur la façon dont elle doit le faire.
CobiT concerne différents types d’utilisateurs : les directions générales : pour que l’investissement informatique
produise de la valeur et pour trouver le bon équilibre entre risques et investissements en contrôles dans un environnement informatique souvent imprévisible,
les directions métiers : pour obtenir des assurances sur la gestion et le contrôle des services informatiques fournis en interne ou par des tiers,
les directions informatiques : pour fournir les services informatiques dont les métiers ont besoin pour répondre à la stratégie de l’entreprise, et pour contrôler et bien gérer ces services,
les auditeurs et consultants : pour justifier leurs opinions et/ou donner des conseils au management sur les contrôles internes et la gouvernance des SI.
Il définit 34 processus regroupés en quatre étapes successives :
Planification et Organisation Acquisition et Installation Livraison et Support Monitoring
dans ce domaine nous cherchons à savoir comment utiliser les technologies afin que l’entreprise atteigne ses objectifs. Définition du plan stratégique informatique Définition de l'architecture des informations Définition de la direction technologique Organisation du service informatique Gestion des investissements Communication des objectifs de la direction Gestion des ressources humaines Respect des exigences légales Évaluation des risques Gestion des projets Gestion de la qualité
ici CobiT cherche à définir, acquérir et mettre en œuvre des technologies en les alignant avec les processus métiers de l’entreprise. Identification des solutions automatiques Acquisition et maintenance des applications informatiques Acquisition et maintenance de l'infrastructure technologique Développement et maintien des procédures Installation et certification des systèmes Gestion des modifications
l’objectif est de garantir l’efficacité et l’efficience des systèmes technologiques en action. Définition des niveaux de service Gestion des services aux tiers Gestion des performances et des capacités Garantie de la poursuite des traitements Garantie de la sécurité des systèmes Identification et attribution des coûts Formation des utilisateurs Assistance des utilisateurs Gestion de la configuration Gestion des incidents Gestion des données et des applications Sécurité physique du système Gestion de l'exploitation
Il convient ici de vérifier si la solution mise en place soit en adéquation avec les besoins de l’entreprise dans une vision stratégique. Surveillance des processus Appréciation du contrôle interne Certification par un organisme indépendant Audit par un organisme indépendant
Le framework COBIT définit 3 critères de haut niveaux applicables sur les informations produites par le processus:
Qualité Sécurité Financier
Ces 3 critères de haut niveau se décomposent en 7 critères détaillés applicables sur les informations produites:
Effectivité (effectiveness) Efficacité (efficiency) Confidentialité (Confidentiality) Intégrité (Integrity) Disponibilité (Availability) Conformité (Compliance) Fiabilité (Reliability)
L'impact du processus sur le critère d'information peut être Primaire, Secondaire, ou vide.
Les processus ont une responsabilité plus ou moins importante dans la gestion des ressources: Personnel Applications Technologies Equipements Données
Le guide de management COBIT permet de: Situer le niveau de maturité des 34 processus par rapport
à un modèle de maturité Définir les facteurs clefs de succès de chaque processus Mesurer l'accomplissement des objectifs Définir des indicateurs de performance
Le modèle de maturité permet d'évaluer le niveau de chaque processus de gestion. Le modèle contient 5 niveaux de maturité:
Le modèle de maturité permet de définir: La situation actuelle de l'organisation La situation des entreprises dans un domaines métier équivalent La stratégie d'amélioration de l'entreprise, là où elle souhaite aller
Les FCS décrivent les choses les plus importantes à faire pour que les processus de gestion des TI atteignent leurs objectifs et qui concernent:
La stratégie, La technique, L'organisation, Les processus et procédures.
COBIT est à la fois un cadre de référence global et une démarche de management structurée pour l'alignement des ressources informatiques avec les objectifs stratégiques de l'entreprise. mais il ne fournit pas d’indications ou de recommandations à caractère technique (choix technologiques, consolidation, gestion de crises…).
ITIL
CMMI
IInformation nformation TTechnology echnology IInfrastructurenfrastructure LLibraryibrary
Introduction Qu’est ce qu’un service IT? IT infrastructure Library Pourquoi ITIL? ITIL le contenu en bref ? Modèle ITIL
Service Support Service Delivery
Exemple de contenu d'un module ITIL
IntroductionIntroduction
Les Entreprises deviennent de plus en plus dépendantes de l’informatique. Cela les conduit à avoir des exigences trop fortes lier à la qualité des services IT .
ITIL est de plus en plus utilisé comme cadre d’organisation des services informatiques car :
Les systèmes informatiques deviennent incontournables. Leur indisponibilité pose des problèmes de discontinuité d’activités de plus en plus aigus
Les systèmes informatiques fonctionnent en réseaux. L’internet a fortement complexifié les problématiques de sécurité de ces systèmes
Evolution rapide et investissements lourds en mesures de sécurité
Qu’est ce qu’un service IT ?Qu’est ce qu’un service IT ?
Ensemble des fonctions fournies par les systèmes IT en support des métiers (gestion du parc PC, gestion des applications au jour le jour, production d’outputs, gestion des accès aux applications, helpdesk, etc...)
Un service est constitué de composants software, hardware et de communication (réseaux) Les services peuvent couvrir de nombreux domaines : depuis l’accès à une application jusqu’à
la mise à disposition d’un service impliquant plusieurs applications, des réseaux, etc... Exemples :
Disponibilité de systèmes critiques Transactions sécurisées sur réseaux ouverts Transfert de données entre applications via un WAN
IT Infrastructure Library IT Infrastructure Library
ITIL (“Information Technology Infrastructure Library”) est un ensemble de recommendations développé par le UK Office of Government Commerce
Ces recommendations sont documentées et décrivent un cadre de gestion des services IT intégré et basé sur les différents processus de fournitures de services
Développé dans les années ’80 pour le gouvernement britannique, l’ ITIL est devenu une référence mondiale en matière de gestion de services IT
Plusieurs centaines de sociétés ont implémentés des processus conformes à ITIL Objectifs du modèle ITIL
Faciliter une gestion de qualité des services IT Améliorer l’efficacité Réduire les risques Fournir un “best practice”
Bibliothèque des meilleures pratiques en matière de service
Description des relations entre les processus informatiques
la base de la qualité des services IT
Favorise le développement de processus efficaces et efficients
Cadre efficace pour développer la maturité des services IT
Indépendant de la structure organisationnelle
Méthodes prescrites Prescrit la structure
organisationnelle impose l'attribution des tâches et
des responsabilités entre les unités fonctionnelles
En lieu et place des pratiques de qualité comme les autres CoBIT, CMM, ISO-9000, ou Six Sigma
ITIL – EST… N’EST PAS…
Pourquoi ITIL ?Pourquoi ITIL ?
Le SI est désormais crucial pour les organisations de tout périmètre et de toute taille.
De plus en plus de Services sont à forte criticité et visibilité : Applications Web (e-banking, e-commerce, e-administration) Télétravail et nomadisme Logistique et communication (supply-chain, visio-conférence) Extranet (centre d’appel, supervision)
L’optimisation de la Gestion des Services est VITALE
ITIL, le contenu en brefITIL, le contenu en bref
QU’ESTCE QUE ITIL?Un ensemble de Meilleurs Pratiques organisé par processus
Modèle ITILModèle ITIL
Hypothèse ITIL : les fonctions suivantes sont essentielles afin de livrer des services IT de qualité
ITIL propose une approche structurée pour définir, implémenter et gérer chacune de ces fonctions au jour le jour
Service Support
Configuration Management
Incident Management
Problem Management
Change Management
Release Management
Service Delivery
Service Continuity
Capacity Management
Financial Management
Service Level Management
Availability Management
Modèle ITILModèle ITIL
Service support :
Assure que l’utilisateur a accès aux services appropriés pour supporter les fonctions métiers :
• Le centre de services (Service Desk)• La gestion des incidents (Incident Management)• La gestion des problèmes (Problem Management)• La gestion des changements (Change Management)• La gestion des mises en production (Release Management)• La gestion des configurations (Configuration Management)
Centre de Services et Gestion des IncidentsCentre de Services et Gestion des Incidents
La fonction Centre de Services Etre l’interface entre les utilisateurs et la Gestion des Services
Informatiques
Le processus de Gestion des Incidents Rétablir le service au Métier au plus vite pour l’utilisateur
Gestion des ProblèmesGestion des Problèmes
Identifier la cause fondamentale des incidents récurrents ou importants afin de les résoudre de manière définitive.
Etre proactif : prévenir les incidents
Gestion des ChangementsGestion des Changements
Minimiser le risque d’incidents induis par les changements
Autoriser ou refuser les demandes de changement
Gestion des Mises en ProductionGestion des Mises en Production
Garantir la qualité des mises en production en considérant les aspects techniques et non techniques
Gérer les différentes versions des éléments de configuration (CI) en production
Gestion des ConfigurationsGestion des Configurations
Organiser l’information relative à tous les éléments de configuration dans un référentiel unique
Gérer toutes les relations (matériel, logiciel, réseau, document)
Service deliveryService delivery
Quels sont les services demandés par les métiers afin de servir correctement les clients de l’entreprise.
• La gestion financière des services des TI (IT Financial Management) • La gestion de la capacité (Capacity Management)• La gestion de la disponibilité (Availability Management)• La gestion de la continuité des services des TI (IT Continuity Management)• La gestion des niveaux de service (Service Level Management)
Gestion Financière des Services InformatiquesGestion Financière des Services Informatiques
Identifier les coûts de Services et les valoriser Budgéter et comptabiliser, ou même refacturer.
Gestion de la CapacitéGestion de la Capacité
Optimiser la Capacité existante et anticiper le besoin futur du Métier.
Gérer et modérer la demande du Métier.
Gestion de la DisponibilitéGestion de la Disponibilité
Assurer que les Services restent disponibles pour répondre aux besoins du Métier (chaîne de service de « bout en bout »).
Sécuriser les points de non fiabilité de l’infrastructure.
Gestion de la Continuité des Services InformatiquesGestion de la Continuité des Services Informatiques
Garantir que les Services critiques puissent être rétablis en adéquation avec les besoins Métier.
Préparer et tester les sites de secours en cas de désastre majeur sur la production.
Gestion des Niveaux de ServiceGestion des Niveaux de Service
Mettre en place et piloter constamment les Accords de Niveau de Services .
Etre l’interface entre le Client (≠Utilisateur) et la Gestion des Services.
Exemple de contenu d'un module ITIL
Incident Management
Problème Management
Change Management
Vue d'ensemble des processus Service Support:
Vue simplifiée du processus Incident Management
CONCLUSIONCONCLUSION
Le meilleur service informatique au meilleur coût . Non propriétaire Non dogmatique: pratiques robustes, mûres et testées
adaptables . Gage de Qualité
Facteurs clés du succès
PMI
PMI en bref
Fondée en 1969, à Philadelphie aux USA, le PMI « Project Management Institue » est une organisation non commerciale qui est de nos jours référence internationale en matière de management de projet. Elle compte plus de 100 000 membres répartis dans plus de 150 pays. Voir le site du PMI pour plus de détail.
Évolution du PMBOK
Le PMI publie le premier volume PMBOK sur papier en 1987 avec la tentative de documenter et standardiser les informations et les pratiques du management de projet. La première édition est publié en 1996 suivit par la seconde édition en 2000. En 2004, la troisième édition est publiée. La quatrième édition est disponible depuis fin décembre 2008.
C’est quoi le PMBOK ?
PMBOK est l’acronyme de Project Management Body Of Knowledge. Traduit en français par « Corpus des Connaissances en Management de Projets ». Ce référentiel, élaboré par le PMI, décrit un ensemble de principes et de Best Practices en MP. Il est un standard américain reconnu par l’ANSI.
Comment est structuré le PMBOK ?
Le référentiel PMBOK décrit le cycle de vie d’un Projet selon à 5 phases ou « groupes de processus » :
Démarrage : définition et autorisation du projet ou d’une phase du projet
Planning : définition et affinement des objectifs, planification des actions requises pour atteindre les objectifs et le périmètre défini pour le projet
Réalisation : intégration des ressources (humaines, matérielles, etc) pour mener à bien le projet
Pilotage et contrôle : surveillance et mensuration régulière de l’avancement projet afin de détecter les écarts par rapport aux plans projets. Dans tel cas, des actions correctives peuvent être prises pour redresser la situation
Clôture : formalisation de l’acceptation d’un produit, service ou résultat. Ceci peut concerner le projet ou une phase du projet
Comment est structuré le PMBOK ?
Chaque groupe de processus est définit par un ensemble de sous processus qui peuvent être liés à l’un des 9 « domaines de connaissances » : intégration, contenu, délais, coûts, qualité, ressources humaines, communication, risque, approvisionnements.
Comment est structuré le PMBOK ?
Comment est structuré le PMBOK ?
Chaque processus est défini par ses : données d’entrées, outils et méthodes et données de sortie.
Les Certifications PMI
Project Management Professional (PMP®) Certified Associate of Project Management (CAPM®) Program Management Professional (PgMP®) PMI Scheduling Professional (PMI-SP®) PMI Risk Management Professional (PMI-RMP®)
Prince2
(PRojects IN Controlled Environments) est une méthode de gestion et de certification de projet structurée qui se focalise sur trois points : l'organisation, la gestion et le contrôle du projet.
Processus
RINCE est divisé en huit processus définis par des clés d'entrée et de sortie, des objectifs à atteindre et des activités à réaliser. Chaque processus est désigné par une abréviation.
(SU) - Elaborer un projet (EP) (IP) - Initialiser un projet (IP) (DP) - Diriger un projet (DP) (CS) - Contrôler une séquence (CS) (MP) - Gérer la livraison des produits (LP) (SB) - Gérer les limites de séquences (LS) (CP) - Clore un projet (CP) (PL) - Planifier (PL)
On peut regrouper ces étapes en quatre phases : Démarrage (SU) Initialisation (IP) Exécution (CS,MP,SB) Clôture (CP)
Processus
Schéma d'ensemble des processus Prince2
MDA
Plan
I-Principes du MDA (Architecture) II-Modèles de MDA III-Transformation de Modèles de MD
IV-Avantages de MDA V- MDA dans la Pratique
Avec MDA les développeurs de logiciels seront capables de créer et de maintenir les logiciels avec moins d’efforts que dans le passé mais avant que cela devienne une réalité
Plusieurs Problèmes ont besoin de solutions :
La définition de méta-modèles dépendants des plates-formes La transformation de modèles
I-Principes du MDA (Architecture)
Dans la première couche, se trouvent le standard UML (Unified Modeling Language), MOF (Meta-Object Facility) et CWM (Common Warehouse Metamodel)
Dans la couche suivante, se trouve aussi un standard XMI (XML Metadata Interchange) qui permet le dialogue entre les middlewares (Java, CORBA, .NET et web services)
La troisième couche contient les services qui permettent de gérer les évènements, la sécurité, les répertoires et les transactions
la dernière couche propose des frameworks adaptables à differents types d’applications à savoir Finance, Télécommunication, Transport, Espace, médecine, commerce électronique et Manufacture,…)
II-Modèles de MDA
Le principe clé de MDA consiste en l’utilisation de modèles aux différentes phases du cycle de développement d’une application.
Modèle :
Le modèle d’un système est la spécification formelle des fonctions, de la structure et/ou du comportement de ce système dans son environnement, dans un certain but.
Un modèle est souvent représenté par des schémas et du texte.
L’objectif majeur de MDA est l’élaboration de modèles pérennes, indépendant des détails techniques des plates-formes d’exécution (J2EE, .Net, PHP ou autre), afin de permettre la génération automatique de la totalité du code des applications et d’obtenir un gain significatif de productivité.
Transformation de Modèles de MDA
CIM (Computation Independent Model) : C’est le modèle métier ou le modèle du domaine d’application
PIM (Platform Independent Model) : Indépendant de toute plate-forme technique
PSM (Platform Specifique Model) : Dépendant de la plate-forme technique
PDM (Plateform Description Model) : contient des informations pour la transformation de modèles vers une plate-forme en particulier
IV-Avantages de MDA
Les trois avantages recherchés par MDA sont les suivants : La pérennité des savoir-faire. Afin de permettre aux entreprises de
capitaliser sur leur métier sans savoir à ce soucié de la technique. Les gains de productivité, afin de permettre aux entreprises de
réduire les couts de mise en œuvre des applications informatiques nécessaires à leur métier.
La prise en comptes des plates formes d’exécution. Afin de permettre aux entreprises de bénéficiers des avantages des plates formes sans souffrir d’effets secondaires.
V-MDA dans la Pratique
Un certain nombre d'étapes et de transformation sont identifiables dans un processus MDA :
- modélisation UML, - transformation intermédiaires, - génération de code.
C'est une étape préalable. Elle se fait en utilisant les outils conceptuels d'UML (Unified Modeling Language). Elle aboutit à un ensemble de modèles de la future application, représentés par des diagrammes de classes.
Chaque domaine fonctionnel de l'application est représenté indépendamment des autres.A partir de ces diagrammes de classes UML, des modèles manipulables sont générés (au format XMI).
1-La Modélisation
2-La Transformation:
A partir de modèles génériques, il s'agit de préciser ce que sera l'application : format de données, réalisation des fonctionnalités. Le(s) modèle(s) de l'application sont donc complétés, affinés.
Typiquement, il s'agit à ce niveau là de transformer un méta-modèle (modèle de modèle, qui indique les contraites que doit respecter l'application), en modèle fonctionnel, dotés de services particuliers.
Il peut également s'agir de transformer un modèle fonctionnel indépendant de l'application (PIM - Platform
Independant Model) en modèle prennant en compte les contraintes de déploiement (PSM - Platform Specific Model).
3-La génération de Code
Lorsque le modèle est complet, le code est généré. L'application peut alors être déployée.
Dans la pratique, le code généré doit être complété : l'implémentation des différentes méthodes, par exemple, n'est pas explicitée dans le modèle.
En cas d'extension ultérieure du modèle, il est indispensable de disposer d'un environnement de développement qui conserve le code ajouté. Si ce n'est pas le cas, le développement incrémental est rendu beaucoup plus laborieux, et la création de grandes applications est compromise.
JUNIT
Le but principal de JUnit est d'offrir au développeur un environnement de développement simple, le plus familier possible, et ne nécessitant qu'un travail minimal pour rédiger de nouveaux tests.
Ecrire Test JUnit
JUnit apporte une solution efficace à ces problèmes. Il nous suffit d'écrire une classe dérivant de junit.framework.TestCase et d'y ajouter nos tests
Exécution des tests
TestCase tc = new VectorTest("testClone");
tc.runTest();
Méthodes d'assertion
Architecture
Outil et résultat
TestNG
Présentation du framework
TestNG est un framework de tests unitaires Java d'une nouvelle génération. il offre la possibilité aux développeurs d'utiliser une des améliorations importantes
de Java 1.5, à savoir les annotations.C'est un framework très simple à mettre en oeuvre et à intégrer dans des projets.
TestNG assure une rétro-compatibilité avec les tests JUnit. Il propose par ailleurs un plugin permettant de l'interfacer dans le l'environnement de
développement Eclipse.
Fonctionnalités
voici un rapide aperçu des différentes fonctionnalités offertes par TestNG : Organisation des tests très puissante Absence de contraintes de nommage Rétro-compatibilité avec les tests JUnit ou transformation des tests JUnit en
tests unitaires TestNG Attente d'Exception sur les tests Création de dépendances entre les différents tests Lancement des tests échoués uniquement Passage de paramètres aux méthodes de tests
Comparaison avec JUnit 3.8
Un point sur JUnit 4.0
Les annotations disponibles dans JUnit 4.0 sont : @Test : permet de spécifier que c'est une méthode de test
Elle permet de spécifier, en attribut, l'attente d'Exception java, et un timeout pour la méthode de test.
@Ignore : permet de spécifier qu'une méthode de test doit être ignorée @BeforeClass : méthode appelée au lancement d'une classe de tests @Before : une méthode annotée ainsi sera l'équivalent de la méthode setUp() pour
JUnit 3.8 @AfterClass : méthode appelée à la fin d'une classe de tests @After : une méthode annotée ainsi sera l'équivalent de la méthode tearDown() pour
JUnit 3.8
Les annotations de base
Les annotations étudiées sont : @Configuration @Test
@Configuration
Méthode appelée au lancement d'une classe de tests
@Configuration
Méthode appelée à la fin d'une classe de tests
@Configuration
Equivalent de la méthode setUp()
@Configuration
Equivalent de la méthode tearDown()
@Test
Cette annotation permet de spécifier qu'une classe ou une méthode correspond à un test (pour une méthode) ou un regroupement de tests (pour une classe).
(les groupes auxquels la méthode de test appartient et sa description. )
@Test
La dépendance de ce test par rapport à d'autres exécutions de tests ou groupes de tests.
Attributs dependsOnMethods et dependsOnGroups.
@Test
L'activation d'un test
@Test
L'obligation de lancer un test=>Attribut alwaysRun mis à "true".
Le nombre de fois que sera exécuté un test=>Attribut invocationCount.
La spécification d'un timeout pour test
=>Attribut timeOut.
PMD
PMD est un framework qui permet d'analyser le code source Java. Il contient un certain nombre de règles qui assure la qualité de code : le code inutile, les imbrications trop complexes... Il permet d'obtenir le résultat par le biais d'un rapport.
Il s'intègre dans Apache Ant, mais aussi dans Maven 1 et Maven 2, ainsi que
dans de nombreux IDE Java( Eclipse, IntelliJ, NetBeans, ...)
La qualité d’une application étant directement liée à la qualité de son code, de nombreux outils sont apparus pour effectuer différents contrôles : vérifications du respect des règles de codage, de nommage des variables et méthodes, etc. parmi ces outils, on trouve PMD.
PMD est un analyseur de code source java. Il détecte et placera en évidence des variables inutilisées, des objets créés inutilement, et bien plus.
Fonctionnement de PMD.
PMD contient une série d'outils :
Détecteur de Copier/Coller.
Analyseur de flux de données
Détecteur de Code mort.
Bugs potentiels (mauvaise utilisation de try/catch)
Sorties récentes
2008-10-12 PMD 4.2.4: correction d’erreur. 2008-08-31 PMD 4.2.3:encore correction d’erreur. 2008-05-20 PMD 4.2.2: encore correction d’erreur.
2008-04-11 PMD 4.2.1: correction d’erreur.
Vérifier l'installation du PMD pour Éclipse
•Sélectionner dans le menu Help -> About Eclipse Platform. Cliquer sur le bouton "Plug-in Details" et rechercher dans la liste des plug-in le "PMD UI plugin" (normalement vers la fin). •Sélectionner dans le menu Help -> Help contents. Vérifier que la documentation pour le plug-in de PMD est présente.
Activer les règles PMD
*Dans Eclipse, ouvrir les préférences pour PMD (Window -> Preferences -> PMD -> Rules configuration)
*Cliquer sur le bouton "Clear all" pour effacer les règles par défaut. *Vérifier que la liste de règles (Rules) est vide. *Cliquer sur le bouton "Import rule set..." et ensuite sur la liste déroulante (▼)
des ensembles de règles ("rule sets").
Comment verifier la qualité du code avec PMD ?
public class bidon // nom de classe commençant avec minuscule{
int i; // nom d'attribut trop court
double Somme; // variable commençant avec une lettre majuscule
public void C() // méthode commençant avec une lettre majuscule{
double y = i + Somme; // nom de variable locale trop court}
}
Résultat:
les variables locales inutilisées;
les blocs catch vides;
les paramètres inutilisés;
les instructions if vides;
les instructions import en double;
les méthodes privées inutilisées;
les noms courts/longs de variables et de méthodes.
La révision de code est l'une des tâches les plus ennuyeuses d'un projet. La vérification de milliers de lignes de code rédigées par un autre développeur pour des éléments tels que les accolades de bloc, les commentaires peut s'avérer une véritable corvée.
PDM vise à automatiser la procédure de révision de code, on laissant la
partie de contrôle de la logique au réviseur humain.
Conclusion.
MAVEN
Apache Maven est un outil logiciel libre pour la gestion et l'automatisation de production des projets logiciels Java en général et Java EE en particulier.
MAVEN
MAVEN
Project Object Model (POM):
Chaque projet ou sous-projet est configuré par un POM qui contient les informations nécessaires à Maven pour traiter le projet (nom du projet, numéro de version, dépendances vers d'autres projets, bibliothèques nécessaires à la compilation, noms des contributeurs etc.)
Ce POM se matérialise par un fichier pom.xml à la racine du projet
PMD
Convention d’arborescence: /src : les sources du projet /src/main : code source et fichiers source principaux /src/main/java : code source /src/main/resources : fichiers de ressources (images, fichiers annexes etc.) /src/test : fichiers de test /src/test/java : code source de test /src/test/resources : fichiers de ressources de test /src/site : informations sur le projet et/ou les rapports générés suite aux
traitements effectués /src/webapp : webapp du projet /target : fichiers résultat, les binaires (du code et des tests), les packages
générés et les résultats des tests
cette liste n’est pas exhaustive dans un projet Maven :
Cycle de vie MAVEN
Les buts (goals en anglais) principaux du cycle de vie d'un projet Maven sont:
compile test package install deploy
--------- en dehors du cycle de vie d’un projet clean assembly:assembly site site-deploy
Plugin Site
Le plugin site est utilisé pour générer le site d’un projet, il inclus tous les plugin report qui ont été défini dans le pom.xml.
La commande est: mvn site
Plugin Site
Plugin Changelog
Le plugin changelog génère un rapport des derniers changement du SCM (source configuration management )du projet.
Le rapport contient tous les activitées SCM,les activités développeur et les activités des fichiers.
Plugin Changelog
Plugin Changelog
Plugin Changelog (Developper Activity)
Plugin Changelog(File Activity)
Plugin Changes
Le plugin changes télécharge les issues depuis jira et génère un rapport contenant la liste des issues affectés à un utilisateur.
Plugin Changes
Plugin CheckStyle
Le plugin checkstyle génère un rapport concernant le style de code utilisé par le développeur.
Le plugin peut être configurer afin de définir des règles de codage.
Plugin CheckStyle
Plugin javadoc
Le plugin javadoc utilise javadoc tools pour génèrer une API JAVADOC du projet
Le plugin peut être configurer afin de définir des règles de codage.
Plugin javadoc
Plugin PMD
Le plugin PMD permet d’exécuter automatiquement pmd code analyseur pour un projet et générer un rapport des bug susceptible d’être rencontrer durant le runtime.
Permet l’exécution de copy/paste detector (CPD tool) et la génération d’un rapport du code dupliqué
Il est possible de personnaliser l’exécution du pmd code analyseur.
Plugin PMD
Plugin JXR
Le plugin JXR permet de facilité au utilisateur l’accès aux classes réalisé avec une numérotation de ligne, il génère un cross-reference du projet .
Plugin Surefire Report
Le plugin Surefire est utilisé durant la phase de test du projet il permet de lancer tous les test unitaire et génère un fichier txt ou xml
Le plugin surefire report utilise Les fichiers xml ou txt pour générer un rapport de test
Plugin Surefire Report
Plugin FindBug
Le plugin FindBug permet de lancer l’analyseur FindBug et generer la liste des bug dans un rapport
Plugin FindBug
Plugin Jdepend
Le plugin changelog génère un rapport des derniers changement du SCM (source configuration management )du projet.
Le rapport contient tous les activitées SCM,les activités développeur et les activités des fichiers.
Plugin Jdepend