Processus Dev Elgharbi

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 )

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)

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

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.

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é).

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.

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 ?

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.

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.

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é)

GENIE LOGICIEL

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 »

Génie Logiciel

la Crise financière Mondialla Crise financière Mondial

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

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.

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

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;

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é;

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);

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;

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é

Le document produit au cours de cette phase est: Document 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.

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

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.

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.

……….

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 ?

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 .

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.

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 !

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..

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.

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.

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.

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!

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!

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.

Outils

Base de données des exigences.Base de données des exigences.

Rational Requisite Pro.Rational Requisite Pro.

Outils

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é

Assurance qualité logicielle(AQL)

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)

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

Objectifs de la qualité

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é

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.

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.

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)

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.

Ces différentes qualités ne sont pas toujours compatibles ni même réalisables, et il est nécessaire de trouver des compromis ...

Facteurs clés la qualité logicielleFacteurs clés la qualité logicielle

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é ?

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.

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.

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

Pourquoi coder en standard ?

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.

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.

ORGANISATION

Minimal

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

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

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

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 NOMMAGE

PACKAGE

CLASSES ET INTERFACES

METHODE

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

Constantes

COMMENTAIRES

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 ;

Les types tableaux doivent être spécifiés sur le type et non sur la variable.

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

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";

Si plusieurs classes partagent un ensemble de constantes il est souvent préférable de les rassembler par groupe fonctionnel dans des interfaces ;

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 ;

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

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

Maintenance

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…

Points forts Distingue clairement les phases projet

Points faibles Non itératif Ne propose pas de modèles de documents

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)

Développement itératif etincrémental

Impliquer le client au maximum dans le projet

Moyens:

client sur site développement chez le client prototypes …

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 Ensemble de « Bests Practices » de développement (travail en équipes, transfert

de compétences…) Cible des projets de moins de 10 personnes

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.

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

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 ?

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

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.

Gestion des besoins

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

Planification

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.

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é

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

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.

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.

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, …

Sprint Burndown Chart

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

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

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

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

Chaque itération a pour finalité une version exécutable.

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

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

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

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

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

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

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

Model de maturité CMM

EL GHARBI Youssef, 2008 274274

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

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).).

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

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.

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

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

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)

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 ».

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.

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

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

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.

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

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

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

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

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 :

Processus par catégorie

Processus par niveau de maturité

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…).

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 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

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.

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

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.

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()

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. )

La dépendance de ce test par rapport à d'autres exécutions de tests ou groupes de tests.

Attributs dependsOnMethods et dependsOnGroups.

L'activation d'un 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 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.

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.

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

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 (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

Processus Dev Elgharbi

Documents

012011 Dev is Types

Rapport Pi Dev

Dev ag 2011

Modèle de maturité CMMi-DEV

JOANNE BRUNET - DEV

compositions DEV époques III IV

Faq Win Dev

Dev opsday case study

Dev 40 ans mix it

RAPPORT ANNUEL 2020 - DEV

Human Dev Lec 10

Fsd ateliers dev international

Lec Staff Dev

Eco Dev Durable Thème 2

Dev durable

Web dev open door

Expériences Dev Local Maroc (1)

Languedoc-Roussillon DEV LR

Geosci. Model Dev. Discuss.,

Dev Mag 200706