Genie-Logiciel_v0

Génie Logiciel(Software Engineering)

Licence InformatiqueDr DIALLO Mohamed

[email protected]

UFRMI 2017.

Curriculum (Licence)Pour

approfondir

Prérequis

Programmation Objet

Théorie des langages

Génie Logiciel

Gestion de projet et applications

Projet de fin d’étude

Curriculum (Master)Génie Logiciel

Projet de Conception

de SI

Modélisation UML

Intégration d’applications

Systèmes Répartis

Conception et

architecture logicielle avancée

Méthodes de test et de

validation du logiciel

Vérification formelle

ContenuVH

CM 18

TD 12

TP 15

• La crise du logiciel et l’évolution de l’ingénierie du logiciel

• Concepts fondamentaux • Qualité du logiciel • Processus de développement• Gestion de projet logiciel

• Gestion de risques

• Spécification• Architecture logicielle

• Modélisation objet• Métriques de qualité • Tests logiciel• Bonnes pratiques de codage• Environnements de

développement• Aspects contractuels et

juridiques du logiciel

La crise du logiciel et l’évolution de l’ingénierie du logiciel

Matériel et logiciel• Matériel est relativement fiable (marché standardisé)• Les problèmes liés à l’informatique sont essentiellement des

problèmes logiciels

Particularité du logiciel• Il est intangible• Il ne s’use pas (pas de

vieillissement)• Il est facilement reproductible:

pas de problème de fabrication en série

• Il est élaboré selon un procédé de développement itératif

• Le procédé de développement se poursuit après la livraison du logiciel, pour la maintenance

• Il est facile à modifier• Il coûte très (trop ?) cher

Typologie des logiciels• Systèmes d’information

• Clients: entreprises, banques, …• SGBD (intégrité des données)

• Systèmes de communication• Clients: Télécoms, spatial…• Développement par couches• Gestion de la répartition• Coût de l’échange de l’information

• Systèmes transactionnels• Clients: compagnie d’aviation, banques,

SNCF• Interactivité, réactivité, rapidité d’accès

aux informations

• Systèmes experts: • Clients: médecine, droit, agriculture..• Problème d’élaboration et de validation des

bases de connaissances• Systèmes scientifiques:

• Clients: métrologie, armée, spatial,..• Grosse consommation en temps CPU• Exploitation de super calculateurs• Exploitation du parallélisme

• Systèmes temps réels• Clients: Industrie, spatial (satellites), armée• Fiabilité, sécurité, robustesse• Techniques employées: tolérances aux fautes,

redondances

Quelques statistiques de logiciel• Windows XP – 45 Millions lignes de

code• Firefox – 20 Millions lignes de code• Linux Kernel – 20 Millions de lignes de

code • Debian – 60 Millions de lignes de code

• Compilateur gcc – 14.5 Millions de ligne de code

• Office 2013 – 40 Millions de ligne de code

• Emacs – 2 Millions de ligne de code• CMS code base

• Drupal – +20 Mille lignes de code• Joomla - +200 000 Mille lignes de code

• MySQL - +10 Millions de lignes de code • Apache Open Office - +20 Millions de

lignes de code • Visual Studio 2012 – 50 Millions de

lignes de code• Google (code base) – 2 Milliards le

lignes de code

Un millions de lignes de code – 18000 pages de texte impriméhttp://www.informationisbeautiful.net/visualizations/million-lines-of-code/

La crise du logiciel• Etude sur 8 380 projets (Standish Group, 1995)

• Succès: 16%• Problématique: 53 % (budget ou délais non respectés, défaut de

fonctionnalités)• Echec: 31% (abandonné)

• Le taux de succès décroît avec la taille des logiciels et la taille des entreprises

Exemple d’échec de projets logiciel• Knight Capital, une firme spécialisée dans l’exécution de transactions

pour des courtiers perdit 440 millions de dollars suite à un bug dans un nouveau logiciel en janvier 2012. (problème algorithmique)

• Dysfonctionnement du système de contrôle de trafic aérien de l’aéroport de Los Angeles entraînant l’interruption de plus de 800 vols dans tout les USA (problème d’implémentation de Timer)

• Délestage dans le nord est des Etats-Unis dû à une erreur de programmation qui engendra des alarmes de panne (mauvaise gestion de la concurrence). Le coût de cette panne est estimée à 7-10 milliards de dollars.

http://www.cse.psu.edu/~gxt29/bug/softwarebug.html

Exemple d’échec de projets logiciel (suite)• Fusée Ariane-5, de l’agence spatiale européenne est lancée le 4 Juin 96. Il

Fonctionne correctement pour 40 secondes ensuite dévie de sa trajectoire et est détruit. Il contenait quatre satellites d’un coût de 500 million de dollars (erreur de conception).

• Perte de satellites dans les années 70 due à une frappe de +I au lieu de +1 dans une instruction d’itération du programme source (FORTRAN).

• Poursuites judiciaires grotesques. Saisie pour dette impayée de 0,01F. Toute la dette avait cependant été payée. • Arrondis mal maîtrisés dans les calculs• Le logiciel n’avait pas de dette-plancher pour déclencher la saisie

• Convocations de centenaires (106 ans+) à l’école. • Codage sur deux caractères

Exemple d’échec de projets logiciel (suite)• Y2K bogue de l’an 2000

• Amende de 91 500 $ au retour d’une cassette vidéo louée, le retard calculé étant de cent ans.

• Cause: la donnée année était codée sur deux caractères, pour gagner un peu de place.

• Inondation de la vallée du Colorado (1983) – Mauvaise modélisation dans le logiciel du temps d’ouverture du barrage

• Certains projets n’aboutissent jamais• Systèmes de réservation de places d’United Air Lines: estimation de 9000 instructions

abandon à 146000. Perte de 56 Millions $.• Advanced Logistics system: 90% transactions en temps réel – abandon en constatant

que 10% le vérifiait. Perte de 217Millions $.

Crise du logiciel (suite)Coût

Logiciel livré mais jamais utilisé avec succès Logiciel utilisé tel que livrélogiciel utilisé après modifications Logiciel utilisé mais refondu ou abandonné plus tardLogiciel payé mais non livré

Neuf grands projets de gestion de l’administration américaine($6,8 millions)

Crise du logiciel: Cause des échecs de ces neufs projets

Causes 1 2 3 4 5 6 7 8 9

Le donneur d’ordre a surestimé son propre savoir faire

X X X X

Mauvaise organisation du donneur d’ordre (tel que contrat inapproprié)

X X X X

Mauvaises spécifications X X X X X X X

Trop de confiance du donneur d’ordre X X

Manque d’organisation pendant le projet. Modifications excessives.

X X X X X

Manque d’inspections et de tests adéquats

X X X X X

Analyse des difficultés• Les symptômes les plus caractéristiques ce cette crise:

• Des logiciels qui ne répondent pas à la demande; ne correspondent souvent pas aux besoins des utilisateurs

• Les logiciels contiennent trop d’erreurs (qualité du logiciel insuffisante)• Les coûts de développement sont rarement prévisibles et sont généralement

prohibitifs• La maintenance des logiciels est une tâche complexe et coûteuse (Elle est

supérieure à 50% du coût d’un logiciel)• Les délais de réalisation sont généralement dépassés• Les logiciels sont rarement portables• Des projets qui n’aboutissent pas

Analyse des difficultés• Contrairement au génie civil (ponts, autoroutes, tunnels)

• Chaque projet informatique est un cas nouveau; développer un logiciel s’apparente plus à une activité de recherche qu’à la routine.

• Les cahier des charges n’est presque jamais complet et figé: il s’élabore et s’adapte à mesure de l’avancement du projet

• Le zéro défaut n’existe pas en matière de logiciel• Personne aujourd’hui ne sait créer de logiciel sans défaut ! La validation de

Windows 2000 avait fait appel à 600000 bêta testeurs, il restait pourtant au lancement de sa commercialisation 63 000 problèmes potentiels dans le code.

Analyse des difficultés

Phase de développement

Coût relatif

Expression des besoins (Spec.)

20%

Conception 15%

Codage 20%

Tests Unitaires 20%

Intégration / Validation 20%

Origine des erreurs0%

10%

20%

30%

40%

50%

60%

Specification Conception Codage

Etape du cycle Coût relatif

Développement 33%

Maintenance 67%

A. Mezrioui, Introduction au Génie Logiciel, 2004

Les remèdes• Maîtrise des coûts et des délais

• Améliorer la précision des devis (coûts, délais)• Contrôler et diminuer le coût du développement (productivité)• Contrôler et diminuer le coût de maintenance

• Maîtrise de la qualité• Assurer les fonctionnalités demandées• Satisfaire les contraintes imposées• Suivre un procédé de production éprouvé• Disposer de méthodes de contrôle de la qualité

• Production industrielle du logiciel• Standardisation de la production (produits sans odeurs)


Les remèdes (suite)• Pour cela il faut:

• Comprendre le logiciel et son développement

• Qualité, facteurs de qualité• Modèles de développement adaptés selon

la nature du problème• Définir des techniques de base

• Méthodes: spécification, conception, validation

• Langages: impératifs, fonctionnels, logiques, L4G, orientés objet

• Construire des outils de développement (Environnements, Ateliers)

• Organiser le développement• Mise en place d’une équipe de

développement• Définition de rôles spécifiques

(spécifieur, concepteur, développeur)

• Reconnaissance de qualifications• Formation complémentaire

• Introduction d’un plan qualité: mise en place de procédures très strictes de contrôles


Le Génie Logiciel• Conférence de l’OTAN à Garmish, Allemagne (1968)• Urgence d’une réflexion sur la qualité et la

productivité du logiciel• Introduction de l’expression Software engineering

• Comment faire des logiciels de qualité ?• Qu’attend-on d’un logiciel ?• Quels sont les critères de qualité pour un logiciel ?

Le Génie Logiciel (Suite)• Discipline informatique dont l’objet

est la construction de logiciels de taille ou de complexité considérable qui sont amenés à évoluer durant leur vie – plusieurs années.

• « Multi-person construction of multi-version software » (D. Parnas)

• « Etablissement et utilisation de bon principes d’ingénierie pour réaliser des logiciels économiques, fiables et efficaces sur des machines réelles » (Fritz Bauer)

Projet Logiciel: Processus permettant de produire un logiciel répondant aux besoins d’un client. Il est caractérisé par:• Date de début • Des objectifs et des contraintes• Des ressources• Des délais et un planning• Des étapes et un plan de

développement• Des responsabilités bien établies • Une recette finale

Evolution de l’Ingénierie du logiciel• Avant 1970s

• Monoprocesseur: mainframes• Deux types de fonctions

• Transformation: conversion d’entrée en sortie• Transaction: entrée détermine quelle fonction doit être réalisée

• Après 1970s• Système répartis et parallèles• Réalisation de fonctions multiples

Pfleeger et Atlee, Software Engineering: Theory and Practice

Evolution de l’Ingénierie du logiciel – 7 facteurs clés de Wasserman• Importance du time to market• Changement dans l’économie de l’informatique• Disponibilité de poste client performants • Importance des communications en réseau locaux et étendus• Disponibilité et adoption de la technologie orientée-objet• Interfaces utilisateur graphiques• Inadéquation du modèle en cascade au développement logiciel


Concepts fondamentaux

Principes utilisés dans le Génie Logiciel• Généralisation: regroupement d’un ensemble de

fonctionnalités semblables en une fonctionnalité paramétrable (Généricité, héritage)

• Structuration: façon de découper un logiciel (bottom-up ou top-down)

• Abstraction: mécanisme qui permet de présenter un contexte en exprimant les éléments pertinents et omettant ceux qui ne le sont pas.

Principes utilisés dans le Génie Logiciel• Modularité: décomposition d'un logiciel en

composants discrets• Documentation: gestion des documents incluant leur

identification, acquisition, production, stockage et distribution

• Vérification: détermination du respect des spécifications établies sur la base des besoins identifiés dans la phase précédente du cycle de vie

Ingénierie du logiciel selon Wasserman• Abstractions• Méthodes et notations d’analyse

et de conception• Prototypage d’interfaces

utilisateurs• Architecture logicielle

• Processus de développement logiciel

• Réutilisation• Métriques et indicateurs• Outils et environnements

intégrés


Méthodes et Notations (Analyse et Conception)•Documenter•Faciliter la communication•Offrir des vues multiples•Unifier différentes vues

Prototypage d’Interface utilisateurs• Prototypage: développer une version minimale d’un

système• Aider les utilisateurs à identifier les exigences clés d’un

système• Démonter la faisabilité

• Développer de bonnes interfaces utilisateurs


Architecture logicielle• Une archi décrit le système en termes d’ensemble

d’unités architecturales et de relations entre ces unités

• Techniques de décomposition architecturale:• Orientée objet• Modulaire• Orientée événement

Processus logiciel• Plusieurs variantes• Différents types de logiciel requièrent différents

processus• Certaines applications nécessitent un processus maîtrisé,

d’autres peuvent être développés de façon plus souple

Réutilisation • Des similarités entre applications doit permettre de réutiliser des

composants de développements antérieurs:• Amélioration de la productivité• Réduction de coûts

• Considérations à prendre en compte• Il est potentiellement plus rapide de développer une petite application que de

rechercher des composants réutilisables• Les composants génériques requièrent plus de temps de développement


Les acteurs du Génie Logiciel• Client: la compagnie, l’organisation ou la personne qui

paie pour le logiciel• Développeur: la compagnie, l’organisation ou la

personne qui développe le logiciel• Utilisateur: la personne ou les individus qui utilisent le

système

Fiche de poste (Ingénieur logiciel Sénior)• Work with our team of security experts to

solve complex problems that haven’t been solved before, accepting that it may take several iterations and / or trial and error to figure out the right approach and solution.

• Given a technical objective, work with a team to determine the best design to meet the requirements in the time frame allowed and at Amazon scale.

• Implement designs you've created using Java, Ruby, JRuby, internal Amazon technologies, and AWS technologies.

• Write unit and integration tests to ensure your solutions are complete and accurate.

• Create monitoring and alarming to ensure your solutions behave correctly in production and alarm in a timely manner when issues arise.

• Participate appropriately in estimation and planning, feeding input to program managers.

• Initiate, perform, and respond to code reviews and design reviews.

• Research and learn new technologies to determine which best solves the problem you are working on

monster Dec. 2016

Fiche de poste (Suite)• Bachelor’s degree in Computer Science or

equivalent work experience• 5+ years of software development experience• Object oriented design and coding experience• Solid software development background

including design patterns, data structures, test driven development

• Full software development life cycle experience

• A track record of shipping software on time

• Excellence in technical communication with peers, partners, and non-technical co-workers

• Ability to handle multiple competing priorities in a fast-paced environment

• Experience developing distributed, multi-process, and multi-threaded client/server architectures

• Excellent judgment, organizational, and problem solving skills

• Interest in network protocols and remote communications

• Interest in security and related issues, solutions and technologies

Ingénieur Développeur Junior (Java/JEE)

Missions• Réalisation des développements dans le respect des

documents d’architecture et des spécifications fonctionnelles

• Développements de tests unitaires• Développement d’interconnexions avec des outils tiers, en

temps réel ou en asynchrone• Vous justifiez d'une première expérience professionnelle

ou d’un stage sur un poste similaire, en environnement Java de préférence.

• Vous êtes sensible aux problématiques e-Commerce et avez idéalement de l'expérience dans les projets J2EE.

• Organisé(e) et précis(e), vous avez le goût du travail en équipe et du partage des connaissances

Environnements techniques

• Apache Tomcat, Hybris, Java 7 & 8• Spring, MVC, JSTL, JSP, • Solr, MySQL• Tests automatisés : JUnit

Monster.fr (Altima – Dec 2016)

Nouvelle tendance dans les recrutements

scorify.me

Qualité du logiciel

Qu’est ce qu’un bon logiciel ?• Une bonne ingénierie du logiciel doit toujours inclure

une stratégie pour produire un logiciel de qualité.• Trois façons de considérer la qualité:

• La qualité du produit• La qualité du processus• La qualité du produit dans le contexte de l’environnement

métier

Utilité• Adéquation entre

• Le besoin effectif de l’utilisateur • Les fonctions offertes par le logiciel

• Solutions:• Emphase sur l’analyse de besoin• Améliorer la communication (langage commun, démarche participative)• Travailler avec rigueur

Utilisabilité• Effectivité, efficacité et satisfaction avec laquelle des

utilisateurs spécifiés accomplissent des objectifs spécifiés dans un environnement particulier.

• Facilite d'apprentissage : comprendre ce que l'on peut faire avec le logiciel, et savoir comment le faire.

• Facilite d'utilisation : importance de l'effort nécessaire pour utiliser le logiciel a des fins données.

• Solutions :• Analyse du mode opératoire des utilisateurs• Adapter l'ergonomie des logiciels aux utilisateurs

Fiabilité • Correction, justesse, conformité: le

logiciel est conforme à ses spécifications, les résultats sont ceux attendus

• Robustesse, sûreté: le logiciel fonctionne raisonnablement en toutes circonstances, rien de catastrophique ne peut survenir même en dehors des conditions d’utilisation prévues

• Mesures:• MTBF – Mean Time Between Failure• Disponibilité (pourcentage du temps

pendant lequel le système est utilisable) et Taux d’erreur (nombre d’erreurs par KLOC)

• Solutions• Utiliser des méthodes formelles, des

langages et des méthodes de programmation de haut niveau

• Vérifications, tests

Interopérabilité• Un logiciel doit pouvoir interagir en synergie avec d'autres logiciels• Solutions :

• Bases de données (découplage données/traitements)• Externaliser certaines fonctions en utilisant des Middleware avec une API

(Application Program Interface) bien définie• Standardisation des formats de fichiers (XML...) et des protocoles de

communication (CORBA...)

Performance• Les logiciels doivent satisfaire aux contraintes de temps

d’exécution• Solutions:

• Logiciels plus simples• Veiller à la complexité des algorithmes• Machines plus performantes• Choix de langage adapté

Performance des langages

https://helloacm.com/a-quick-performance-comparison-on-languages-at-codeforces/

Portabilité• Un même logiciel doit pouvoir fonctionner sur plusieurs

machines• Solutions:

• Rendre le logiciel indépendant de son environnement d’exécution (voir interopérabilité.)

• Machines virtuelles

Réutilisabilité• On peut espérer des gains

considérables car dans la plupart des logiciels:

• 80% du code est du tout venant qu’on retrouve à peu près partout

• 20% du code est spécifique.

• Solutions:• Abstraction, généricité • Construire un logiciel à partir

de composants prêts à l’emploi

• Design patterns

Facilité de maintenance• Un logiciel ne s’use pas• Pourtant, la maintenance absorbe une très grosse partie des efforts

de développement

Facilité de maintenance• Objectifs

• Réduire la quantité de maintenance corrective (zéro défaut)• Rendre moins coûteuse les autres maintenances

• Enjeux • Les coûts de maintenance se jouent très tôt dans le processus d‘élaboration du logiciel• Au fur et a mesure de la dégradation de la structure, la maintenance devient de plus en

plus difficile

• Solutions• Réutilisabilité, modularité• Vérifier, tester• Structures de données complexes et algorithmes simples• Anticiper les changements a venir

La qualité du processus• La qualité du processus de développement et de maintenance est

aussi importante que la qualité du produit• Le processus de développement doit être modélisé pour répondre à

des questions telles que:• Comment trouver efficacement les fautes ?• Comment est réactif au changement ?• Comment gérer les risques ?


Référentiels pour la qualité des processus de développement logiciel - CMMI• Initial – Processus non contrôlé, non défini• Reproductible – Intuitif (organisé, mais pas de processus formel) • Défini – Procédures formelles pour vérifier que le processus est utilisé• Maîtrisé - Quantitatif / Processus de mesures• Optimisé – Améliorations retournées dans le processus• 75% des projets au niveau 1, 25% aux niveaux 2 et 3 selon Curtis• Pour maîtriser le processus de développement logiciel et assurer la qualité du

logiciel, il faut :• Séparer le développement en plusieurs étapes• Organiser ces étapes et modéliser le processus de développement• Contrôler le processus de développement

La qualité dans le contexte métier • La valeur métier qui est aussi importante que la valeur technique doit

être quantifiée• Une approche commune: retour sur investissement (ROI)• ROI est interprété en termes différents:

• Réduction de coûts• Amélioration de la productivité• Amélioration des coûts (efforts et ressources)


Processus de développement

Cycle de vieLa qualité du processus de fabrication est garante de la qualité du

produit.Pour obtenir un logiciel de qualité, il faut en maîtriser le processus

d’élaboration• La vie d’un logiciel est composée de différentes étapes• La succession de ces étapes forment le cycle de vie du logiciel• Il faut contrôler la succession de ces différentes étapes

Composantes du cycle de vie d’un logiciel• Etude de faisabilité• Spécification• Organisation du projet• Conception

• Implémentation• Tests• Livraison• Maintenance

Membres d’une équipe de développement• Analystes: Ils travaillent avec les clients pour identifier et documenter les

exigences• Concepteurs: Ils génèrent une description de ce que le système doit réaliser • Programmeurs: Ecrivent le code implémentant la conception• Testeurs: Identifient les fautes• Formateurs: Montrent aux utilisateurs comment utiliser le système• Equipe de maintenance: Corrige les fautes apparaissant après déploiement• Equipe de gestion de configuration: Maintient la correspondance entre

différents artefacts

Membres d’une équipe de développement

Etude de faisabilité• Déterminer si le développement proposé vaut la

peine d’être mis en œuvre compte tenu des attentes et de la difficulté de développement

• Etude de marché: déterminer s’il existe un marché potentiel pour le produit

Etude de faisabilité• Réponse aux questions suivantes:

• Quoi ? Définition du projet, objectifs internes et externes

• Pourquoi ? Avantages d’une nouvelle solution

• Comment ? Contraintes de réalisation, choix de matériel et de logiciels

• À moins que ? Autres choix possibles (statu quo, réorganisation, acheter louer, sous-traiter,…)

• Résultats:• Décision sur la faisabilité• Première version du cahier des

charges• Plan général du projet • Estimation des coûts et des délais

• Moyens• Plan d’entretiens

Spécification• Déterminer les fonctionnalités que doit posséder le

logiciel• Collecte des exigences: obtenir de l’utilisateur ses

exigences pour le logiciel• Analyse du domaine: déterminer les tâches et les

structures qui se répètent dans le domaine

Spécification (Suite)• Buts:

• Obtenir une description précise et sans ambiguïté du système logiciel

• Préciser la portée et les objectifs du projet

• Produit: performances, traitement, données, entrées et sorties

• Projet: ressources, contraintes, hypothèses

• Résultats• Document de spécification• Plan détaillé du reste du projet• Plan de tests

Organisation du projet• Déterminer comment on va développer le logiciel

• Analyse des coûts: établir une estimation du prix du projet• Planification: établir un calendrier de développement• Assurance qualité du logiciel: déterminer les actions qui

permettront de s’assurer de la qualité du produit fini• Répartition des tâches: hiérarchiser les tâches et sous-tâches

nécessaires au développement du logiciel

Conception• Déterminer la façon dont le logiciel fournit les

différentes fonctionnalités recherchées• Conception générale

• Conception architecturale: déterminer la structure du système• Conception des interfaces: déterminer la façon dont les

différentes parties du système agissent entre elles• Conception détaillée: déterminer les traitements et

structures de données pour les différentes parties du système

Implémentation• Respecter les bonnes pratiques

de codage• Tester et déboguer

• Buts:• Obtenir les programmes• Faire les tests unitaires (modules)

• Résultats• Programmes• Documentation technique• Résultats de tests (unitaires)

• Moyens• Langage de programmation• Outils de test• Analyseurs statiques• Revues de code (inspection)

Tests• Essayer le logiciel sur des données d’exemple pour s’assurer qu’il

fonctionne correctement• Tests unitaires: faire tester les parties du logiciel par leurs développeurs• Tests d’intégration: tester pendant l’intégration• Tests de validation: pour acceptation par l’acheteur• Tests système: tester dans un environnement proche de l’environnement de

production• Tests de régression: enregistrer les résultats des tests et les comparer à ceux

des anciennes versions pour vérifier si la nouvelle n’en a pas dégradé d’autres

Intégration et tests• Buts:

• Vérification des fonctionnalités et des performances du système complet• Vérification du respect des normes de programmation• Vérification de la documentation

• Résultats• Document de validation• Système logiciel intégré

• Moyens• Utilisation de jeux de tests• Outils d’évaluation de performance

Livraison• Fournir au client une solution logicielle qui fonctionne

correctement• Installation: rendre le logiciel opérationnel sur le site du

client• Formation: enseigner aux utilisateurs à se servir du

logiciel• Assistance: répondre aux questions des utilisateurs

Maintenance• Mettre à jour et améliorer le logiciel pour assurer sa

pérennité• Pour limiter le temps et les coûts de maintenance, il

faut porter ses efforts sur les étapes antérieures

Maintenance corrective• Corriger les erreurs: défauts d’utilité, d’utilisabilité, de fiabilité…

• Identifier la défaillance, le fonctionnement• Localiser la partie du code responsable• Corriger et estimer l’impact d’ne modification

• Attention• La plupart des corrections introduisent de nouvelles erreurs• Les coûts de correction augmentent exponentiellement avec le délai de

détection• La maintenance corrective donne lieu à de nouvelles livraisons (release)

Maintenance adaptative• Ajuster le logiciel pour qu’il continue à remplir son rôle compte tenu

de l’évolution• Environnements d’exécution• Fonctions à satisfaire• Conditions d’utilisation

• Ex: changement de SGBD, de machine, de taux de TVA , an 2000, euro…

Maintenance perfective, d’extension• Accroître, améliorer les possibilité du logiciel• Ex: les services offerts, l’interface utilisateur, les performances• Donne lieu à de nouvelles versions

Documents courants• Calendrier du projet• Cahier des charges• Spécifications• Plan de test du logiciel• Plan d’assurance qualité

• Rapports des défauts• Manuel utilisateur• Code source• Rapport des tests

Documents produits dans le cycle de vie

Document Phase de production

Manuel utilisateur final Implémentation

Conception architecturale Conception

Plan d’assurance qualité Planification

Code source Implémentation

Cahier des charges Faisabilité

Plan de test Spécification

Conception détaillée Conception

Estimation des coûts Planification

Calendrier du projet Planification

Rapport des tests Tests

Documentation Implémentation

Modèles de cycle de vie d’un logiciel

• Modèles linéaires• Cascade• Modèle en V

• Modèles non linéaires• Prototypage• Modèles incrémentaux• Modèle en spirale• Méthodes agiles

Le cycle de vie en cascade

Le cycle de vie en cascade (suite)• Adapté pour des projets de petite taille, et dont le domaine est bien

maîtrisé avec peu de changement dans les exigences• Simple et facile à expliquer aux clients• Chaque phase majeur est marquée par des jalons et des livrables• Il n’y a pas d’itérations dans le modèle en cascade – contrairement à

la plupart des développements logiciels.

Le cycle de vie en cascade (suite)• Fournit aucune indication sur la gestion de changements relatifs aux

produits et activité durant les développement (suppose que les exigences peuvent être gelées)

• Modélise le développement logiciel comme un processus industriel plutôt qu’un processus créatif

• L’attente jusqu’au produit final est longue

Le cycle de vie en « V »• Adapté pour des projets dont le domaine est bien maitrisé

Le cycle de vie en « V » (suite)• Une variation du modèle en cascade• Utilise les tests unitaires pour vérifier la conception détaillée• Utilise les tests d’intégration pour vérifier l’architecture • Utilise les tests d’acceptation pour valider les exigences• Si des problèmes sont trouvées durant la vérification et la validation,

la branche gauche du V peut être re-exécutée avant que le test de la branche droite soit activé à nouveau

Le prototypage• Prototype: version d’essai du logiciel

• Pour tester les différents concepts et exigences (design)• Pour montrer aux clients les fonctions que l’on veut mettre en œuvre

(interface)

• Lorsque le client a donné son accord, le développement suit souvent un cycle de vie linéaire

• Avantages: Les efforts consacrés au développement d’un prototype sont le plus souvent compensés par ceux gagner à ne pas développer de fonctions inutiles

Le modèle en spirale • Un modèle mixte• A chaque cycle recommencer:

1. Consultation du client2. Analyse des risques3. Conception4. Implémentation5. Tests6. Planification du prochain cycle

• Avantages: meilleure maîtrise des risques mais nécessite une (très) grande expérience et devrait être limitée aux projets innovants

Développements en phase: Incréments et itérations• Développement incrémental: démarre avec un sous-système

fonctionnel et rajoute des fonctionnalités avec chaque nouvelle version

• Développement itératif: démarre avec un système complet, puis améliore les fonctionnalités de chaque sous-système à chaque nouvelle version

Développement en phase (suite)• Développement en phase est souhaitable pour plusieurs

raisons:• La formation peut commencer tôt, même si certaines fonctions

sont absentes• Les marchés peuvent être créés tôt pour des fonctionnalités qui

n’ont jamais été offertes• Des release fréquentes permettent aux développeurs de corriger

des problèmes non anticipés rapidement

Méthodes agiles• L’accent est mis sur la flexibilité à produire du logiciel fonctionnel

rapidement• Manifeste agile

• Valoriser les individus et les interactions plutôt que les processus et outils• Préférer investir du temps à produire du logiciel fonctionnel plutôt que de

produire une documentation exhaustive• Mettre l’accent sur la collaboration du client plutôt que la négociation de

contrat• Se concentrer sur la réaction au changement plutôt que la réalisation rigide

d’un plan

Exemples de Méthodes agiles• Extreme programming (XP)• Scrum: 30-day iterations; multiple self-organizing

teams, daily scrum coordination

Gestion de projet: Vers les méthodes agiles

Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016

Méthodes Agiles: Ce qu’il faut retenir• Les développeurs auront tendance à s'attarder sur la qualité du code

délivré.• les fonctionnels percevront plus la valeur business d'un projet. • L'intérêt de l'agilité est de permettre à ce beau monde de s'exprimer

de manière optimale pour délivrer un projet qui convienne à tout le monde.


Extreme programming• Accent sur quatre caractéristiques d’agilité

• Communication: Echange continue entre clients et développeurs • Simplicité: sélectionner la conception ou l’implémentation la plus

simple (App. simple évolue facilement et l’anticipation des extensions futures est une perte de temps)

• Courage: Engagement à fournir des fonctionnalités tôt et souvent (Courage aussi pour gérer les changements)

• Feedback: Des boucles de contrôle dans les différentes activités du processus de développement

Méthode agiles: Douze facettes de XP• Le jeu de planification - planning poker (le client

crée des scénarios pour les fonctionnalités qu’il souhaite obtenir. L’équipe évalue le temps nécessaire pour la mise en œuvre. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible)

• Petites releases (cycles de développement rapides pour s’adapter au changement)

• Définir des Métaphores (pour une meilleure compréhension) - (vision commune, noms communs)

• Conception simple (la simplicité permet d’avancer vite)

• Ecrire les tests en premier• Refactoring (Le code doit être toujours clair malgré

les modifications)

• Pair programming (revue de code permanente)

• Propriété collective (chaque développeur peut modifier n’importe quelle partie du code)

• Intégration continue (intégration des modifications de façon quotidienne)

• Rythme soutenable (40 hours/week). Pas d’heures supplémentaires. Un développeur fatigué travaille mal.

• Client sur-site (Un représentant du client disponible pour répondre aux questions)

• Convention de codage

http://www.regismedina.com/articles/fr/extreme-programming

Méthodes Agiles: Scrum• Organisation du projet

• User-stories• Sprint• Mur Scrum

• Trello, Symphonical, papier

• Equipe Scrum• Scrum Master• Le Product Owner• L’équipe (de développeurs)

• Les rituels: visent à faciliter la communication entre le client (porteur du projet) et l’équipe qui réalise le projet (les développeurs)

• Sprint Planning• Backlog Grooming• Daily Scrum Meeting


Scrum: Bilan• Tops

• Meilleur cadre de travail pour un développeur

• Communication optimale avec le client

• Livraison de produits maximisée• Création de liens au sein de

l’équipe.

• Flops• Fatigue de l’équipe• Mise en place progressive• Négligence de la qualité du code

produit


Gestion de projet

Gestion de projets• Problèmes souvent humains

• Planifier la progression• Motiver et coordonner un groupe de professionnels

• Techniques souvent communes à la gestion de projet en général

• Problème particulier de la visibilité• Un projet logiciel apparaîtra souvent à ses développeurs comme

presque achevé alors qu'il ne l'est qu'a 90%

Plan de développement logiciel• Portée du projet • Planning de projet• Organisation de l’équipe de

projet• Description technique du projet• Procédures et standards du

projet• Plan d’assurance qualité• Plan de gestion de configuration

• Plan de documentation• Plan de gestion de ressources• Plan de test• Plan de formation• Plan de sécurité• Plan de gestion de risque• Plan de maintenance

Pfleeger and atlee, Software Engineering: Theory and Practice

Plan de développement logiciel (suite)• Liste des membres de l’équipe de développement• Liste de matériels et logiciels• Méthodes et standards, telles que:

• Algorithmes• Outils• Techniques de revue et d’inspection• Représentations ou langage de conception• Langages de programmation• Techniques de test

Pfleeger and atlee, Software Engineering: Theory and Practice

Pratiques du chef de projet• Opter pour une gestion des risques continue• Estimer les coûts et planifier le projet à partir de données

empiriques• Utiliser des métriques pour la gestion du projet• Suivre l’évolution de la valeur acquise• Rechercher les défauts en fonction des objectifs de qualité• Considérer les employés comme la ressource la plus importante• Utiliser un outil de gestion de configuration

Pratiques du chef de projet• Gérer et suivre l’évolution des besoins• Orienter la conception en fonction du système visé• Définir et contrôler les interfaces• Concevoir plusieurs fois pour ne coder qu’une seule• Identifier les éléments potentiellement réutilisables• Contrôler les spécifications• Organiser les tests comme un processus continu

Planification: Généralités• La planification d’un projet conditionne son bon

déroulement• Le planning a pour but de :

• maîtriser le déroulement du projet dans le temps• constituer un élément de reporting et de dialogue avec les

différents intervenants• mettre en évidence l ’organisation optimale des taches à réaliser

Ph. Legall – Training TAD.

Structurer pour planifier•Les questions:

• Quoi ? Les tâches à effectuer (WBS)• Qui ? Les responsabilités (OBS)• Quand ? Le planning (PERT, GANTT)• Comment ? Les moyens (ressources)• Combien ? Les coûts


Disposer du référentiel coûts / délais au démarrage du Lot• Il est important que le référentiel soit établi au plus tôt (<1 mois après le T0) pour

pouvoir mettre en place les indicateurs de suivi.• Les plannings des tâches sont élaborés, au plus tôt, afin :

• d'identifier les relations et les interdépendances entre les différentes activités du WBS,

• de confirmer par les responsables d’activités (OBS) que les travaux identifiés peuvent être réalisés conformément aux jalons de l'affaire et du contrat de manière logique et dans les délais (engagement des responsables d’activités)

• d'indiquer quand et où les travaux effectifs sont prévus de sorte qu'au cours de l'affaire, l'avancement et les écarts puissent être mesurés, et des modifications apportées au planning.


Planification de projets - WBS• Diviser les tâches principales en tâches plus petites• Nécessite de:

• Pouvoir identifier leurs différentes parties• Trouver des livrables et des jalons qui permettront de mesurer l’avancement

du projet

• WBS (Work Breakdown Structure)• Structure arborescente• Le premier niveau de décomposition correspond souvent au modèle de cycle

de vie adopté

WBS

Planification de projets - PERT• Program Evaluation and Review Technique

• Identifier les tâches et estimer leur durée• Ordonner les tâches• Construire le réseau et l’exploiter

A quoi cela sert • Le PERT est établi, sous forme

graphique, à partir des lots de travaux décrits dans le WBS.

• Il représente• l’enchaînement des travaux, • leurs liens de dépendance, • les contraintes de dates, • les limites d’enclenchement de ces

travaux. Il permet par simulation d’optimiser les délais.

• Ainsi on retrouve pour chaque lot de travaux :• la désignation, la durée,• les dates de début et de fin (dates au plus

tôt et dates au plus tard),• les marges possibles sur ces dates,• les liens de dépendance avec les travaux

précédents et les travaux suivants.• Le PERT fait apparaître les travaux se trouvant

sur le ou les “chemins critiques” • (marges totales les plus faibles ou nulles,

peu ou pas de glissement possible). • Il permet ainsi de détecter les risques de

retard

Construire un réseau PERT• La méthodologie de planification s'appuie

au départ sur la construction d'un réseau. (PERT = (Program Evaluation and Review Technique)

• Un réseau PERT est un graphe orienté où :

• Les nœuds (étapes) correspondent aux jalons

• Les arcs correspondent aux activités, ils sont associés à une durée

• Un réseau potentiel est un graphe orienté où :

• Les nœuds (étapes) correspondent aux activités :

• Durée• Date de début, Date de fin• Ressources

• Les arcs correspondent à des liens chronologiques entre activités, ils peuvent être éventuellement associés à un délai

Evt-1 Evt-2Activité_A

durée

PERT

Activité_A Durée

Activité_BDélai éventuel

Date_Début Date_fin Date_Début Date_fin

POTENTIEL

Historique du réseau PERT• Technique a été mise au point aux USA vers 1950 au sein de l’US Navy

pour la création de la force d’attaque nucléaire pour rattraper le retard vis a vis de l’URSS,

• il fallait rendre l’arme opérationnelle dans un délai fixe à un coût raisonnable • en coordonnant Plus de 250 fournisseurs, Plus de 9000 sous traitants

• L’aboutissement du programme s’est effectué 2 ans avant la date prévue.

Règles de construction d’un PERT• Une activité de durée nulle est un jalon• La réalisation d’un lot de travaux a un jalon de début et un jalon de fin

uniques• Deux activités ne peuvent avoir qu’un type de liens entre elles• Le début d’une activité ne peut commencer que lorsque toutes les

activités sont « quasi » terminées, mais dans la réalité, il y a des recouvrements,

Exemples Dates de début et de fin

désignation

durée AvancementMarge

Méthode de construction1/ Pré-requis : les activités du WBS et leur durée sont identifiées2/ Créer les activités de début et fin3/ Créer les jalons et toutes les activités du WBS ayant une durée4/ Lier les activités entre elles5/ S’assurer que toutes les activités permettent de définir complètement la stratégie de développement (cycle de vie)La date finale de la réalisation et les marges des activités se calculent à partir du PERT et des dates au plus tôt et au plus tard.

Les dates au plus tôt

A

0 4 4

E

4 4 8

B

4 2 6

C

8 2 10

D

10 2 12

0DEBUTPROJET

CALCUL AU PLUS TOT

Début au + TOT

N° ActivitéDurée

Fin au + TOT

• Les dates au plus tôt se calculent du début vers la fin de réalisation du lot.

• Consiste à calculer pour chaque évènement (début ou fin d'activité), une date au plus tôt à partir d'un calendrier donné

Les dates au plus tard

D

10 2 12

E

4 4 8

C

8 2 10

B

4 2 6

A

0 4 4

0DELAIOBJECTIF+ 14

CALCUL AU PLUS TARD

2 2 6 8 4 10 10 2 12 12 2 14

6 2 10

Début au + TARD

Début au + TOT

N° Activité Durée

Fin au + TOT

Fin au + TARD

Marge totale

• Consiste à calculer pour chaque avènement (début ou fin d'activité), une date au plus tard à partir d'un calendrier donné

• Les dates au plus tard se calculent de la fin vers le début de la réalisation du lot, à la suite du calcul de fin au plus tôt

• Le délai objectif correspond à la date attendue par le Client, qui doit être > ou = à la date de fin de réalisation au plus tôt.

La marge libre

• Durée dont on peut déplacer une activité sans incidence sur les autres activités du lot. Elle est individuelle

• La marge libre (2) est due à la mise en parallèle de B et de E.

D

E

C

B

A (4)

(2)

La marge totale• Durée dont une activité

peut être retardée sans affecter le début au plus tard de l'activité suivante, c'est à dire sans affecter la date d'achèvement du projet. Elle est collective.

• La marge totale est liée au chemin A E C D.

D

E

C

B

A

(2)

Le chemin critique • C’est le plus long des chemins, en durée, reliant l’événement début à l’événement fin.

• La durée du chemin critique correspond à la durée de réalisation du lot.

• Les activités du chemin critique sont critiques si une activité du chemin critique dépasse les délais prévus,

• Il peut y avoir plusieurs chemins critiques : il faut découper ces activités critiques pour les paralléliser

D

E

C

B

A

Marge et chemin critique• Chemin critique = marge nulle. En pratique, il s'agit d'une marge faible

par rapport à la durée du développement.• Les marges et chemins critiques sont à analyser à chaque mise à jour

du planning.• La connaissance des marges et des chemins critiques et nécessaire à

la Maitrise des risques• Attention aussi à la fiabilité des estimations des durées prévues.

Les activités "hamac"• Le HAMAC est une activité dont la durée s'ajuste en fonction des

activités qui l'encadrent (Exemple: management, support...)• Il peut permettre de matérialiser des activités de suivi ou de procéder

à des consolidations du planning

FIN-FIN

HAMAC

DEBUT-DEBUT

Les caractéristiques des marges• La marge libre et la marge totale des activités critiques sont nulles.• La marge libre est toujours positive ou nulle• Marge libre <= Marge totale• On peut consommer la marge libre d’une activité sans remettre en cause la

planification des autres activités du lot.• Si la marge totale d’une activité est consommée, la date de fin de réalisation du

lot va glisser, il faut revoir le planning

Critiques• Critique du réseau PERT

• Les activités ne sont pas complètement indépendantes (recouvrement)• Le PERT ne constitue pas une fin en lui même : référence de base pour le

début du travail de planification

• Critique du GANTT• Pas facile de visualiser les dépendances• Incomplet pour visualiser la progression des coûts, nécessité de disposer

d’autres indicateurs• Utile pour l’avancement dans le temps de la progression du projet , mais ne

donne pas un avancement sur la quantité de travail réalisé (nécessité de disposer d’autres indicateurs)

Exemple de GANTT : SP COBRA

Planning de référence

Les jalons (ou milestones)• Activité de durée nulle qui matérialise un

événement du planning• Un jalon représente selon le cas:

• Une date imposée par le Client ou le Donneur d'ordre (exemple qualification officielle, livraison de version...)

• Un interface avec un autre lot de travail (dépendance critique)

• Une étape qui définit l'état d'avancement (exemple revue de fin de phase...)

• Un planning Gantt doit faire figurer obligatoirement les jalons des 2 premiers types :

• Les jalons du premier type sont associés à une date objectif de fin (date au plus tard).

• Les jalons du second type sont associés à une date contrainte de début (date au plus tôt).

• Les autres jalons ou activités du planning ne doivent pas avoir de dates contraintes.

Les ressourcesMOYENSnécessaires à la réalisationdes activités du projet/affaire

INDICATEURSSuivis au niveau de laconduite du projet/affaire

FINALITES

LESRESSOURCES

NATUREMain d'œuvreFrais

CATEGORIEPour la main d'œuvre :Ingénieur, Technicien...

CARACTERISTIQUES

COUT UNITAIRETaux horaire,…

L’affectation des ressources

• Profil de ressource : c'est la courbe de répartition de la ressource sur la durée de l'activité

EXPRIMEES ENQUANTITE RESSOURCEPAR ACTIVITE

OU

100 heures sur activité

10 jours

EXPRIMEES ENUNITE RESSOURCEPAR UNITEDE TEMPS

10 heures par jour

10 jours

D1 D2

DUREE ACTIVITE

La disponibilité des ressources• Les ressources "disponibles" sont les moyens dont on dispose

effectivement

8765

RESSOURCE A

RESSOURCE B

RESSOURCE C

Périodes(calendrier des disponibilités)

Quantité disponiblepar unité de temps

Définitions: Lissage et nivellement• Lissage : les délais de réalisation du lot sont inchangés, on agit sur la

répartition des ressources (avec possibilité de surcharge)• Nivellement : la surcharge des ressources n’est pas tolérée, les délais

de réalisation peuvent être remis en cause• Les outils de planification offrent des techniques mathématiques de

répartition des charges (déterministe, probabiliste) mais sont peu usités, il s’agit de personnes, on ne peut pas faire n’importe quoi dans n’importe quelles conditions.

Application au Gantt• Une fois le Gantt généré à partir du

PERT, il faut répartir les charges et les ressources du lot :

• Affecter les ressources• Lisser les charges en utilisant les

marges• Examiner le plan de charge des

ressources

• Si les ressources sont en surcharge, choix entre

• Nouvelle répartition des ressources• Mettre des priorités sur les

ressources• Ajouter de nouvelles ressources• Surcharge du plan de travail

Indicateurs d'avancement• Suivi de l'avancement détaillé• Objectif :

• Montrer l'avancement d'une activité significative du développement

• Définition :• Dépend de l'activité• L'avancement peut être normalisé en % d'achèvement de l'activité• Mesure basée sur des éléments dimensionnant

Maîtrise des délais• Les réseaux de type “PERT”, représentant l’ordonnancement des lots de

travaux issus du WBS, dont le but est de mettre en évidence les contraintes relatives aux activités déclinées dans le WBS,

• Les plannings de type “GANTT”, représentant chronologiquement la réalisation des différents lots de travaux, dont le but est de suivre leur avancement et de mettre en évidence les dates “clés”.

• Le planning de référence est figé contractuellement, il ne peut pas être modifié sans l’accord du client.

• Le planning courant représente la vie de l’affaire. Il mesure les écarts par rapport au planning de référence et permet de prendre les décisions correctives.

L’indicateur GANTT

% d'avanct

date début référence date fin référence

date de mise à jour

% d'avanct = durée passée / durée totale

Date Début Date Fin

Estimation des coûts• Estimer les coûts des projets est un des aspects cruciaux de

la gestion et planification de projets• L’estimation des coûts doit être faite le plus tôt possible

durant le cycle de vie• Les types de coûts

• Facilités: matériel, espace, mobilier, communication, etc• Logiciels pour concevoir et développer le logiciel• Effort: la composante principale de coût

Estimation de l’effort• L’estimation doit être

répétée de façon continue.• L’incertitude en début de

projet peut affecter la précision des estimations de coût et de taille.

Causes d’imprécision des incertitudes• Demande de changements fréquentes du client.• Le client a du mal à bien formaliser les exigences.• Absence de méthode adéquate pour réaliser les

estimations.• Analyse insuffisante durant les estimations.• Tâches sous-estimées.

Méthodes d’estimation• Jugement des experts

• Analogie: pessimiste (x), optimiste (y), probable (z); Estimation: (x+4y+z)/6

• Techniques de delphi: basée sur la moyenne de jugements confidentiels d’experts

• Algorithmiques: E = (a + bSc) m(X)– COCOMO– Walston and Felix model: E = 5.25 S 0.91

– Bailey and Basili model: E = 5.5 + 0.73 S1.16

Estimation des coûts – COCOMO de base• COnstructive COst Model

• Développé a la firme TRW (organisme du DoD, USA) par B.W. Boehm et son équipe

• Fondé sur une base de données de plus de 60 projets différents

• Modèle d'estimation• du coût de développement d'un logiciel en nombre de mois-hommes (E :

effort)• du temps de développement en mois (TDEV)• en fonction du nombre de lignes de codes en milliers (KLOC)

Estimation des coûts• Mode organique

• Petites équipes• Applications maîtrisées et problèmes bien compris• Pas de besoins non fonctionnels difficiles

• Mode semi-détaché• Expérience variée des membres de l’équipe de projet• Possibilité d’avoir des contraintes non fonctionnelles importantes• Type d’application non maîtrisée par l’organisation

• Mode embarqué• Contraintes serrées• L’équipe de projet a, en général, peu l’expérience de l’application• Problèmes complexes

Calcul de l’effort• Formule générale

• E=• a et b estimés en fonction de données empiriques

a b

Organique 2,4 1,05

Semi-détaché 3,0 1,12

Embarqué 3,6 1,20

Calcul du temps de développement• Formule générale

• TDEV = • a et b estimés en fonctions de données empiriques

a b

Organique 2,5 0,38


Embarqué 2,5 0,32

Modèle COCOMO intermédiaire• Estimation modifiant l’estimation brute fournie par le

modèle COCOMO de base en se servant des attributs• Logiciel• Matériel• Projet• Personnel

Les attributs du logiciel• Besoin en fiabilité• Taille de la base de données• Complexité du produit

Les attributs du matériel• Contraintes sur le temps d’exécution• Contraintes sur la mémoire• Contraintes sur le stockage• Contraintes du temps de passage entre deux processus

(synchronisation)

Les attributs du projet• Techniques de programmation moderne

• Programmation Orientée Objet• Programmation Evénementielle

• Utilisation d’Ateliers de Génie Logiciel (CASE)• Contraintes de développement

• Délais• Budget• …

Les attributs du personnel• Compétence de l’analyste• Compétence du programmeur• Expérience dans l’utilisation du langage de programmation• Expérience dans le domaine de l’application• Expérience dans l’utilisation du matériel

Calcul de l’effort

• Les estimations obtenues par la formule ci-dessus sont multipliées par les 15 facteurs de coût liées aux attributs du logiciel, du matériel, du projet et du personnel

a b

Organique 3,2 1,05


Embarqué 2,8 1,20

Modèle COCOMO expert• Inclue toutes les caractéristiques du modèle intermédiaire• Ajouts:

• L’impact de la conduite des coûts sur chaque étape du cycle de développement

• Le projet est analysé comme une hiérarchie: module, sous-système et système

• COCOMO expert permet une véritable gestion de projet• Utile pour de grands projets• Problème: nécessite une estimation de la taille du projet en KLOC

Analyse en points de fonction• Plutôt que d’estimer le nombre de lignes de code, il peut être

judicieux d’estimer des points de fonction• Les éléments les plus courants à prendre en compte sont les:

• Interrogations: paires requête-réponse• Entrées: les champs individuels ne sont généralement pas comptés

séparément (nom, prénom…comptent pour 1)• Sorties (comme les entrées)• Fichiers internes: fichiers tels que le client les comprend• Interfaces externes: données partagées avec d’autres programmes

Comptage des points de fonction• Des coefficients sont attribués aux éléments, selon leur complexité

Elements Simple Moyens Complexes

Sorties 4 5 7

Interrogations 3 4 6

Entrées 3 4 6

Fichiers 7 10 15

Interfaces 5 7 10

Comptage des points de fonction (suite)• Les coefficients pondèrent une somme du nombre d’éléments

recensés pour obtenir les points de fonction du logiciel• Manque de standard pour compter les PF• Estimation des coefficients à faire en interne• Relation entre points de fonction et coût à estiment en interne

Indicateurs d’avancement•Histogramme de ressources

•Suivi de dépenses

Impact de la communication sur le projet• La progression d’un projet est

affecté par• Le degré de communication• La capacité des individus à

communiquer leurs idées• Des bugs logiciels peuvent

résulter d’une mauvaise communication et d’un manque de compréhension mutuelle

Organisation du projet• Caractéristiques des

projets et la structure organisationnelle adaptée

Highly structured Loosely structured High certainty Uncertainty Repetition New techniques or technology Large projects Small projects

Pfleeger et atlee

Exemple d’organisation structurée

Assurance qualité (Software Quality Assurance)• La qualité est difficile à définir

• ISO 8402 : l’ensemble des caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins exprimés et implicites.

• Un logiciel est de qualité lorsqu’il fonctionne comme il est supposé le faire

• Il est plus facile de mesurer les défauts de qualité• Mécontentement du client• Nombre de rapports d’erreurs

Inspections formelles• Activité formelle et planifiée

• Un concepteur présente des documents sur un projet à un groupe d’autres concepteurs qui en évaluent les aspects techniques avec pour objectif de trouver les erreurs

• Contrôle effectué par des personnes techniquement compétentes• Participation active de l’auteur• Porte sur un produit fini• Inspection périodique au cours du processus de développement

Rôles pour une inspection• Le modérateur

• Il choisit l’équipe• Il dirige l’inspection

• Le lecteur• Il n’est généralement pas l’auteur

du produit• Il guide l’équipe dans la structure

du produit

• Le secrétaire• Il consigne le déroulement de

l’inspection• Il note toutes les erreurs trouvées

• L’auteur• Il est à l’origine du produit

examiné• Il répond aux questions• Il corrige les erreurs et fait un

rapport au modérateur

Etapes de l’inspection• Présentation générale par l’auteur au reste de l’équipe• Préparation

• Les membres de l’équipe étudient le produit dans la limite d’un temps calculé en fonction du nombre de LOC

• Ils peuvent s’aider d’une liste de contrôles

• Réunion pour l’inspection• Organisée par le modérateur• Le lecteur conduit l’inspection• Le secrétaire consigne les problèmes dans un rapport• En cas de désaccord, il est possible de produire des rapports individuels

Etapes de l’inspection (suite)• Intégration des remarques: l’auteur corrige les

erreurs• Suivi

• Le modérateur contrôle le rapport et les corrections• Si les critères sont satisfaits, l’inspection prend fin

Gestion de risque

Le risque• Risque: probabilité qu'un événement indésirable ait lieu. Le risque

implique des idées de• Incertitude: les événements ne se produiront pas de manière certaine• Perte: plus l’événement est indésirable, plus le risque est grand

• Une gestion proactive des risques peut aider a minimiser les effets négatifs d‘événements susceptibles de se produire

• Types de risques:• Les risques de projet concernent le déroulement du projet• Les risques techniques portent sur la qualité du produit• Les risques commerciaux peuvent affecter sa viabilité

Exemples de types de risquesRisque Projet Technique Commercial

Matériel non dispo x

Spécifications incomplètes x

Utilisation de méthodes spécialisées

x

Problèmes pour atteindre la fiabilité désirée

x

Départ d’une personne clé x

Sous-estimation des efforts nécessaires

x

Le seul client potentiel fait faillite

x

Risques courants selon Boehm• Inaptitude du personnel• Planning et budget non réalistes• Développement des mauvaises fonctions ou interface utilisateurs• Flux continus de changements d’exigences• Défaillance des fournitures externes ou des travaux sous-traités• Difficultés à implémenter des exigences de performance• Blocage sur les limites technologiques des plate-formes• Perfectionnisme (Gold-plating)

https://goo.gl/VbHRvS

Calcul des risques• Utilisations de probabilités élémentaires

• Estimer la probabilité du risque • Estimer l’impact, le coût des conséquences• Calculer le risque en multipliant ces deux valeurs

Atténuation des risques• Stratégie proactive pour tenter de diminuer

• L’impact d’un risque• La probabilité d’un risque

• Pas de solution miracle• Identifier très tôt les risques les plus importants• Utiliser un cycle de vie incrémental et fondé sur les risques• Prototyper autant que possible

Exemples de stratégies d’atténuation des risques

Risque Réd. Proba Réd. ImpactMatériel non dispo Accélérer le dév.

du matérielConcevoir un

simulateur

Spécifications incomplètes Approfondir les contrôles des

spécs

Utilisation de méthodes spécialisées

Former les équipes,

engager des experts

Problèmes pour atteindre la fiabilité désirée

Orienter la conception vers

la fiabilité

Départ d’une personne clé Augmenter les salaires

Engager d’autres personnes

Sous-estimation des efforts nécessaires

Diagnostic par un expert externe

Respect des délais,

estimations fréquentes

Le seul client potentiel fait faillite

Trouver d’autres clients potentiels

Spécification

Définition des exigences• Une exigence est une expression de comportement

désiré• Les exigences mettent l’accent sur les besoins des

clients, et non sur la solution ou l’implémentation• Spécifie quel comportement, sans préciser comment le

comportement sera réalisé

De l’importance des exigences• Des facteurs clés à l’origine de

l’échec de projets• Exigences incomplètes• Client pas suffisamment impliqué• Attentes irréalistes• Manque de support des décideurs• Exigences and spécifications

instables• Absence de planification• Système développé obsolète

• Les erreurs dans la phase de spécification peuvent coûter cher si elles ne sont pas détecter tôt

Pfleeger and Atlee, Software Engineering: Theory and Practice

Processus de définition des exigences• Réalisé par

l’analyste d’exigence ou l’analyste système

• Le document final produit est la SRS


Modélisation des exigences Agiles• Lorsque les exigences sont incertaines, les méthodes agiles sont une

approche alternative• Les méthodes agiles collectent et implémentent les exigences de

façon incrémentale.• Avec XP:

• Les exigences sont définies progressivement avec le développement logiciel• Pas de planification ou de conception pour les potentielles futures exigences• Les exigences sont traduites en cas de test que l’implémentation doit passer


Collecte des exigences• Les clients ne comprennent pas toujours leurs besoins et

problèmes• Il est important de discuter les exigences avec tous les

acteurs impliqués dans le système• Trouver un consensus sur les exigences

• Si on ne peut pas s’entendre sur les exigences alors le projet est condamné à l’échec


Collecte des exigences - Intervenants• Clients: paient pour le logiciel à développer• Acheteurs (Customer): Achète le logiciel une fois développé• Utilisateurs• Experts métiers: familiers avec le problème à automatiser• Prospecteurs de marchés: conduisent des enquêtes pour déterminer

les futurs tendances et les clients potentiels• Avocats ou auditeurs: familiers avec les exigences gouvernementales,

de sûreté ou légales• Ingénieurs logiciels

Moyens de collecte d’exigence• Interviews (individuelles ou en

groupe) et Brainstorming avec les utilisateurs potentiels

• Revue de documentation• Observation du système existant• Apprentissage avec les

utilisateurs pour cerner les tâches des utilisateurs avec plus de détails

Modèle de Volere

Types d’exigences• Exigences fonctionnelles: décrit

le comportement désiré en termes d’activités requises

• Exigences de qualité: décrit quelques caractéristiques de qualité que le logiciel doit posséder

• Contraintes conceptuelles: une décision conceptuelle telle qu’un choix de plateforme ou composants d’interface

• Contraintes liées au processus: une restriction sur les techniques ou ressources qui peuvent être utilisées pour concevoir le système

Importance de la testabilité des exigences• Des critères d’acceptation

comme standards objectifs pour juger si une solution proposée satisfait les exigences

• Aisé pour les exigences quantifiables (performance)

• Difficile pour des exigences de qualité subjectives

• Une astuce pour rendre les exigences testables:

• Spécifier une description quantitative pour chaque adverbe et adjectif

Deux types de documents d’exigence• Définition des exigences:

• un listing complet de tout ce que le client souhaite réaliser

• Décrit les entités dans l’environnement dans lequel le système sera installé

• Spécification des exigences:• reformule les exigences

comme une spécification de comment est-ce que le système proposé doit se comporter


Caractéristiques des exigences•Correctes•Cohérentes•Sans ambiguïtés•Complètes

•Faisable•Pertinence•Testable•Traçabilité


Notations de modélisation• Il est important d’avoir des

notations standards pour modélisation, documentation et décision de communication

• La modélisation nous permet de comprendre les exigences complètement

• Des « holes » dans le modèle révèlent des comportements inconnus et ambigüs

• Plusieurs possibilités conflictuelles pour les même inputs révèlent des inconsistances dans les exigences


Notations de modélisation pour la spécification de logiciel• Diagrammes Entité-Association• Diagramme de classes UML• MSC (Diagramme de séquence)• Machines à état (Diagramme

Etat-transition et Réseaux de Pétri)

• DFD (Diagramme de flot de données – Cas d’Utilisation)

• Méthodes formelles• Méthode fonctionnelle

(Tables de décision)• Logique – notations descriptive

• Logique du premier ordre• Logique temporelle• OCL (Object Constraint Language)• Langage Z• Spécifications algébriques (SDL)


Diagrammes Entité-Association• Les diagrammes Entités-

Association sont populaires:• Ils donnent un aperçu du

problème à résoudre.• La vue est relativement stable en

cas d’évolutions de la spécification du problème

Diagramme d’entités du problème du tourniquet

Diagrammes de classe UML• Modélisation métier d’un

problème par des classes et des associations.

• Plusieurs types d’associations:• Agrégation• Composition

Diagramme de séquence de messages• MSC pour une

transaction de prêt bibliothécaire.• Entités – lignes

verticales• Message – flèches• Actions – rectangles

étiquetés• Conditions – Etats

importants dans l’évolution d’une entité représenté comme un hexagone étiqueté.

Machine à états• Description des dialogues entre le

système et son environnement.• Utile pour spécifier aussi bien le

comportement dynamique.

Machine à état – Modèle du problème du tourniquet

Réseaux de Pétri• Outils permettant de modéliser et de

vérifier le comportement dynamiques des systèmes à événement discrets comme les systèmes manufacturiers, de télécommunications et les réseaux de transport.

• Les cercles représentent des activités ou conditions

• Les barres représentent des transitions• Les arcs relient une transitions à ces

activités d’origine et de destination• Les jetons dans les activités, activent les

conditions pour les transitions.

Réseau de Pétri du problème de prêt bancaire

Diagramme de flots de données• Le DFD modélise les

fonctionnalités et le flot de données d’une fonction à une autre

• Processus (Bulles)• Flot de données (Flèches)• Entrepôt de données

(Barres horizontales)• Les acteurs (Rectangles)

• Les diagrammes EA, MSC et machines à états décrivent le système à une granularité plus fine

DFD pour le problème du bibliothécaire

DFD (Suite)

Avantages• Fournit un modèle intuitif des

principales fonctionnalités du système et des dépendances de données entre plusieurs processus

Inconvénients• Peut-être ambigu pour un

développeur qui n’est pas familier au problème modélise.

DFD: Variante (Cas d’utilisation UML)

Méthodes fonctionnelles unlocked s=locked AND e=coin NetState(s,e)= rotating s=unlocked AND e=push locked (s=rotating AND e=rotated) OR (s=locked AND e=slug) buzz s=locked AND e=slug Output(s,e) = <none> Otherwise

• Représentation du problème du tourniquet

• Une fonction pour maintenir l’état

• Une fonction pour déterminer la réponse du tourniquet

Tables de décisions• Table de décision pour

les fonctions de la bibliothèque:

• Borrow• Return• Reserve• Unreserve

Logique• La logique consiste en un langage

pour exprimer des propriétés et des règles d’inférence pour dériver de nouvelles propriétés à partir de prémisses.

• En logique, une propriété de spécification représente uniquement les valeurs des variables de la propriété pour laquelle l’expression de la propriété s’évalue à vrai.

• Il s’agit de la logique de premier ordre, qui inclut:

• Variables typées• Constantes• Fonctions • Prédicats

Logique de premier ordre• Variables du problème du tourniquet

• Les expressions de la logique du premier ordre

num_coins : integer := 0; /* number of coins inserted */ num_entries : integer := 0; /* number of half-rotations of

turnstile */ barrier :{locked, unlocked}:= locked;/* whether barrier is locked */ may_enter : boolean := false; /* event of coin being inserted */ push : boolean := false; /* turnstile is pushed sufficiently hard to rotate it one-half rotation*/

num_coins > num_entries

(num_coins > num_entries (barrier = unlocked)(barrier = locked ) ¬may_enter

Logique temporelle • □f Ξ f est vraie maintenant et pour le reste de l’execution.

• ⋄f Ξ f est vraie maintenant ou à un certain point de l’exécution

• ○f Ξ f est vraie au prochain point d’exécution

• f W g = f est vraie jusqu’à un point où g est vraie, mais g peut ne jamais être vraie.

• Les propriétés du tourniquet exprimées en logique temporelle:□(insert_coin => ○ (may_enter W push))□( n(insert_coin num_coins=n) => ∀ ∧ ○(num_coins=n+1))

• Elle introduit des opérateurs supplémentaires pour contraindre comment les variables évoluent dans le temps.

• Les opérateurs suivants contraint les valeurs futures des variables, pendant une exécution

OCL: Object Constrain Language• Un langage de

contraintes qui est mathématiquement précis et facile à lire, écrire et comprendre pour les non mathématiciens.

• Conçu pour exprimer des contraintes sur les modèles objet.

Notation Z• Notation de spécification utilisé

pour décrire et modéliser les systèmes informatiques.

http://staff.washington.edu/jon/z/z-examples.html

Langages de spécificationsCombinent plusieurs paradigmes de notation

UML• Diagramme de cas d’utilisation (DFD

de haut niveau)• Diagramme de classe (Diagramme EA)• Diagramme de séquence /

Communication (Traces d’événement)• Diagramme d’état transitions

(Machine à état)• Propriétés OCL (logique)

SDL (Standard UIT)• Spécifie le comportement de

processus concurrents, temps-réels et distribués communicant via des files de messages.

• Diagramme système SDL (DFD)• Diagramme de bloc SDL (DFD)• Diagramme de processus SDL (Machine

à état)• Type de données SDL (spécification

algébrique)• MSC

Spécifications algébriques (Données SDL)

• Le comportement des opérations est spécifié par les interactions entre paires d’opérations plutôt que de modéliser individuellement les opérations.

• Il est difficile de trouver un ensemble d’axiomes exhaustifs et cohérent qui réflète le comportement souhaité.

Spécification partielle du problème de la bibliothèque

Prototyper les exigences• Pour clarifier certains aspects du système proposé• Pour obtenir un retour d’utilisateurs potentiels

• Quels aspects du système ils voudraient voir améliorer• Quelles fonctionnalités ne sont pas utiles• Quelles fonctionnalités sont manquantes

• Evaluer si le problème du client a une solution faisable• Exploration d’options pour la mise en œuvre d’exigences de qualité


Approches de prototypage (rapide)• Approche jetable

• Développée pour étudier un problème ou une solution proposée, et qui ne sera pas intégrée au logiciel fournie au client

• Approche évolutionnaire• Développée non seulement pour nous aider à répondre à des

questions mais aussi pour être incorporée au produit final• Le prototype doit exhiber les exigences de qualité du produit

final, et ces qualités ne peuvent être rétrogradéesPfleeger and Atlee, Software Engineering: Theory and Practice

Prototypage vs. Modélisation• Prototypage

• Idéal pour répondre à des questions sur les interfaces utilisateur

• Modélisation• Répond rapidement à des questions relatives aux

événements et aux activités


Documentation des exigences • Donne un aperçu sur l’objectif général et la portée du système,

incluant la motivation• Décrit les caractéristiques essentielles d’une solution acceptable• Décrit l’environnement dans lequel le système va opérer• Esquisse une description de la proposition, si le client a une

proposition pour résoudre le problème• Liste les éventuelles hypothèses faites au sujet du comportement de

l’environnement


Documentation des exigences• Décrit toutes les inputs et outputs en détail, incluant:

• Les sources d’inputs• Les destinations d’outputs• Les plages de valeurs• Les formats des données • Le format des fenêtres et leur organisation• Les contraintes temporelles

• Reformule les fonctionnalités requises en termes d’interfaces d’entrées et de sorties

• Formule critère d’acceptation pour chaque exigence de qualité du client


Documentation des exigences

1. Introduction to the Document1.1 Purpose of the Product

1.2 Scope of the Product

1.3 Acronyms, Abbreviations, Definitions

1.4 References

1.5 Outline of the rest of the SRS2. General Description of Product

2.1 Context of Product

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communications Interfaces

3.2 Functional Requirements

3.2.1 Class 1

3.2.2 Class 2

…

3.3 Performance Requirements

3.4 Design Constraints

3.5 Quality Requirements

3.6 Other Requirements4. Appendices

Standards de l’IEEE pour SRS


Validation et Vérification• Dans la validation des exigences, on vérifie que la définition

des exigences reflète précisément les besoins du client.• Dans la vérification, nous vérifions qu’un document ou

livrable est conforme à un autre• La vérification assure que nous construisons le système

correctement, tandis que la validation assure que nous développons le bon système


Statistique des fautes liées aux exigences• Selon Jone et Thayes

• 35% des fautes liées à la conception pour des projets de 30-35 KLOC• 10% des fautes liées aux exigences et 55% des fautes liées à la conception pour

les projets de 40-80 KLOC• 8-10% de fautes liées aux exigences et 40-55% de fautes liées à la conception

pour les projets de 65-85 KLOC

• Basilis et Perricone• 48% des fautes observées dans un projet logiciel d’envergure moyenne

attribuée à « des exigences incorrectes ou mal interprétées »

• Beizer attribue 8,12% des fautes dans ses échantillons à des problèmes liées aux spécifications fonctionnelles


Vérification automatique• Model Checking est une recherche exhaustive de l’espace

d’exécution d’une spécification, pour déterminer si une propriété logico-temporelle est maintenue durant l’exécution.

• i.e. Spin model checker• Theorem prover concerne le développement de programmes

informatiques qui montre qu’une proposition (la conjecture) est une conséquence logique d’un ensemble de propositions (les axiomes et hypothèses)

• i.e PVS

Mesurer les exigences• Le nombre d’exigences peut donner une indication de

la taille du système à développer• Le nombre de changements dans les spécifications

• Beaucoup de changements indiques une instabilité ou incertitude dans notre compréhension du système

• Les mesures de taille et de changement d’exigence doivent être documentées par type d’exigence


Notation des exigences – Echelle de 1 à 51. Les exigences sont comprises complètement, vous avez développé des systèmes

à partir d’exigences similaires, et vous n’avez aucune difficulté à développer à partir de cette exigence.

2. Certains éléments de l’exigence sont neufs, mais ne sont pas radicalement différents des exigences qui ont été développés avec succès dans le passé.

3. Certains éléments de cette exigence sont très différents d’exigences de projets différents , mais vous comprenez l’exigence et pouvez développer une bonne conception.

4. Certaines parties de l’exigence ne sont pas comprises, et vous n’êtes pas sûrs de développer un bon design.

5. Vous ne comprenez pas du tout l’exigence, and ne pouvez développer un design.


Notation des exigences – Testeurs / Concepteursa) Les exigences sont bien

rédigées• 1 et 2 dominent

b) Les exigences doivent être révisées• 4 et 5 dominent


Choisir une technique de spécification - Critères• Applicabilité• Courbe d’apprentissage• Maturité de la technique• Vérifiabilité / Testabilité• Maturité des outils• Niveau d’abstraction• Modélisation des données

Cas d’utilisation UML• Un cas d’utilisation est:

• Une description de ce qui passe quand les utilisateurs interagissent avec le système

• Une collection de scénarios définissant comment un Acteur utilise le système pour réaliser une certaine fonction

• Deux types de notation• Graphique et textuelle

http://alistair.cockburn.us/


Qu’est ce qu’un acteur ?• Fondamentalement un utilisateur du système• En réalité des groupes ou catégories d’utilisateurs • Les entités externes (individus ou systèmes)

• Qui interagissent avec le système en vue de réaliser un but donné

Exemple


Cas d’utilisations• Consigne les exigences fonctionnelles dans un format facile à lire• Représente le but d’une interaction entre un acteur et le système. Le

but représente un objectif significatif et mesurable pour l’acteur.• Enregistre un ensemble de chemins (scénarios) impliquant un acteur

depuis un événement déclencheur (début du cas d’utilisation) jusqu’à l’objectif visé (scénario de succès)

• Enregistre un ensemble de scénarios qui traverse un acteur depuis un événement déclencheur mais qui n’aboutit pas à l’objectif visé (scénario d’échec)

Cas d’utilisations (suite)

• Sont Multi-niveaux : un cas d’utilisation peut inclure ou étendre la fonctionnalité d’un autre

• Les cas d’utilisations ne spécifie ni l’interface utilisateur, ni les détails d’implémentation

Types d’acteur• Acteur primaire

• L’acteur utilise le système pour réaliser son but• Le cas d’utilisation documente les interactions entre le système et

les acteurs pour réaliser le but de l’acteur primaire• Acteur secondaire

• Acteurs dont le système requiert assistance pour réaliser les intentions des acteurs primaires

Processus de rédaction de cas d’utilisation• Gérer son Energie

• Commencer à un haut niveau et rajouter les détails au fur et à mesure

• Trop de détails trop tôt rend les changement difficiles par la suite• Il s’agit d’un processus itératif et incrémental (cas d’utilisation et

développement logiciel Orienté Objet)



Quatre niveaux de Précision• Acteurs et Buts – liste des Acteurs et de leurs buts• Description du cas – définit le déclencheur (trigger) et le

scénario principal de succès• Conditions d’échec – Tous les scénarios d’échec pouvant se

produire• Gestion d’échec – Décrit comment le système devrait gérer

chaque type d’échec

ExempleRajouter une copie d’un livre

Acteur: Bibliothécaire

But: Rajouter une copie d’un livre à la bibliothèque .

Précondition: Le livre existe dans la librairie.

Bibliothécaire Système

1. Recherche du livre

2. Affichage des informations du livre.

3. Valide la commande d’ajout d’une copie.

4. Demande les informations de la copie

5. Fournit les informations de la copie

5. Valide les informations.

6. Sauvegarde les infos et informe l’utilisateur

Exceptions

1a – le livre n’existe pas (redirection vers ajouter un livre)

3a, 5a – Bibliothécaire annule l’opération

6a – 1 – La copie est un duplicat

6a – 2 – Les informations requises sont manquantes

6a – 3 – Les données ne sont pas conformes au format attendu

Architecture logicielle

La conception• La conception est le processus créatif de définition de

comment implémenter toutes les exigences du client• Les décisions conceptuelles en amont concernent

l’architecture du système• Les décisions conceptuelles tardives concernent

l’implémentation des unités individuelles

Le processus de conception• La conception est une tâche intellectuellement difficile

• Différentes possibilités que le système doit gérer• Objectifs de conception non fonctionnels (facilité d’utilisation, facilité de

maintenance)• Facteurs externes (format de données standard, régulation des

gouvernements)• Il est possible d’améliorer la conception en étudiant des exemples de

bonnes conception • La plupart du temps la conception consiste à résoudre des problèmes

en réutilisant et adaptant des solutions de problèmes similaires

Le processus de conception • Modèle de référence: Architecture

générique qui suggère une approche pour décomposer un système (dépend du problème)

• Styles architecturaux: Solutions génériques pour architectures logicielles

• Patrons de conception (Design Patterns): solutions génériques pour des décisions relatives à la conception détaillée

• Principes de conception (Design Principles): caractéristiques descriptives de bonne conception

Exemple d’architecture logicielle (modèle de référence)

Modèle de référence Pour un compilateur

Processus de conception• La conception logicielle est un processus itératif• Le résultat final est le SAD (Software Architecture Document)

Méthodes populaires de conception• Décomposition fonctionnelle

• Partitionne les fonctions ou exigences en modules• Décomposition orientée objet

• Assigne les objets aux modules• Décomposition orientée événement

• Assigne la responsabilité aux événements à différents modules

Styles architecturaux et stratégies• Modèle en couche• Publish-Subscribe• Filtres et tubes• Client-Serveur• Pair-à-pair• MVC (Modèle Vue Contrôleur)

Filtres et tubes• Le concepteur peut comprendre

l’entièreté de la réponse du système aux entrées comme une composition des filtres.

• Les filtres peuvent être réutilisées sur d’autres systèmes.

• L’évolution du système est simple.

• Permet l’exécution concurrente de filtres.

KEY

pipe


Client/Serveur• Deux types de

composants:• Composant Serveur

offre des services• Clients y accèdent en

utilisant un protocole requête/réponse


Client/Server – Architecture deux tiers

Client/Server – Architecture trois tiers

Client / Server – Architecture N-tiers

Architecture orientée service

Pair-à-pair• Chaque composant se comporte comme un client et comme un

serveur• Chaque composant peut initier une requête à n’importe quel autre

pair composant• Caractéristiques

• Passage à l’échelle• Amélioration de la capacité• Haute tolérance aux pannes

Publish/Subscribe• Les composants interagissent en

diffusant et réagissant aux événements

• Les composants expriment leur intérêt dans un événement en souscrivant.

• Quand un autre composant annonce un événement, les composants abonnés sont notifiés

• Caractéristiques• Couplage lâche facilitant

l ’évolution et la personnalisation• Facilité de réutiliser les

composants dans d’autres systèmes orientés événement

Modèle en couche• Chaque couche fournit des

services à la couche au-dessus et agit comme un client à la couche en-dessous,

• La conception inclut des protocoles (interfaces)

• Explique comment chaque pair de couches vont interagir

• Avantages• Bon niveau d’abstraction• Aisance relative pour ajouter

ou modifier une couche• Inconvénients

• Performances du système peuvent souffrir de l’Overhead induit par la coordination entre les couches

Exemple de Système en coucheModèle OSI

Modèle MVC (Modèle Vue Contrôleur)

• Modèle: Objets encapsulant les informations de la base de données.

• Vue: Présentation (Pages web, HTML, CSS, Javascript)

• Contrôleur: Répond aux actions de l’utilisateur (répond aux événements) et met à jour la vue et le modèle.

Architecture Web MVC (lynda.com)

Modélisation ObjetConception détaillée

Principes de conception (Design Principles)• Les principes de conception sont

des bonnes pratiques pour décomposer les fonctionnalités et comportements requis du système en modules.

• Les principes identifient les critères :

• Pour décomposer un système• Décider quelle information

exposer (ou masquer) dans les modules résultant.

• Six principes dominants• Modularité• Interfaces• Encapsulation d’information• Développement incrémental• Abstraction• Généralité

Méthodologie de conception• Les décisions conceptuelles sont

périodiquement revisitées et révisées (Refactoring) pour simplifier des solutions complexes ou pour optimiser la conception.

• Idéalement, la conception de logiciel serait une progression d’une spécification de haut niveau à une solution, utilisant une séquence de décisions conception (top-down, error-free) résultant en une collection hiérarchique de modules

• En pratique, le travail de conception est rarement systématique de la spécification aux modules (exigences changeantes ou mal comprises, refactoring, erreurs humaines)

Méthodologie de conception: Simuler un processus de conception logique• Nous devons simuler le comportement idéal en rédigeant la

documentation comme si nous avions suivi le processus idéal• Décomposer le logiciel en modules• Définir les interfaces des modules• Décrire les interdépendances entre modules• Documenter la conception interne des modules

Principes de conception: Modularité• La modularité est le principe de séparation des différents aspects non en

relation d’un système, de façon à pouvoir étudier chaque aspect de façon isolée (aussi appelée la separation of concerns)

• Si le principe est bien appliqué, chaque module résultant aura une finalité spécifique et sera relativement indépendante des autres

• Chaque module sera facile à comprendre et développer• Plus facile de localiser les fautes (moins de modules suspects par faute)• Plus facile de modifier le système (un changement dans un module impacte relativement

peu les autres modules)

• Deux concepts sont importants pour mesurer l’indépendance de modules:• Couplage• Cohésion

Couplage• Deux modules sont fortement couplés quand ils dépendent fortement l’un de

l’autre• Deux modules sont lâchement couplés quand ils ont un degré de dépendance,

mais leurs interactions sont faibles• Des modules sont découplés quand ils n’ont pas du tout d’interaction

Tightly coupled -many dependencies

Loosely coupled -some dependencies

Uncoupled -no dependencies

Couplage (suite)• Le couplage mesure

l’interdépendance d’un constituant par rapport à un autre. Il définit le mode de communication inter-composant et précise le type de données qui transitent d’un composant à un autre.

• Un faible niveau de couplage permet de :

• Tester un composant hors de son environnement

• Modifier un composant sans remettre en cause le système

• Comprendre le fonctionnement d’un composant uniquement par lui-même

• Eviter qu’une erreur dans un composant ne se manifeste dans un autre.

Couplage• Il existe différents types de dépendance:

• Les références faites d’un module à un autre• La quantité de données échangées d’un module à un autre• Le degré de contrôle qu’un module a sur un autre

Content coupling

Common coupling

Control coupling

Stamp coupling

Data coupling

Uncoupled

TIGHT COUPLING

LOOSE COUPLING

LOW COUPLING

Couplage par contenu (le pire)• Se produit quand un composant modifie une donnée interne

à un autre composant, ou quand un composant fait un branchement au milieu d’un autre composant

Couplage par données communesModifier les données partagées a un impact sur tous les composants ayant accès à ces données

Couplage de contrôle et autres• Un module transmet à

l’autre une information (flag) destinée à contrôler sa logique interne

• Il est impossible pour le module contrôlé de fonctionner sans direction du module de contrôle

• Couplage de collection• Référence à une structure de

donnée non globale mais complexe échangée entre modules (enregistrement, matrice, etc.)

• Couplage de données (le meilleur):

• Passage de données simples du module appelant au module appelé

Cohésion• La cohésion mesure à la

dépendance entre les éléments internes à un module (e.g. données, fonctions, modules internes)

CoincidentalLogical

TemporalProcedural

CommunicationalFunctional

Informational

HIGH COHESION

Cohésion• Cohésion fonctionnelle (la meilleure): toutes les actions du module contribuent à remplir une seule et même fonction• Cohésion informationnelle: Adaptation de la cohésion fonctionnelle à l’abstraction de données et la conception orientée objet• Cohésion communicationnelle: les actions du module se réfèrent aux mêmes paramètres d’entrée ou de sortie (i.e. elles opèrent sur le même jeu de données)

• Cohésion temporelle: les actions du module ont comme unique relation le temps (les données et fonctions sont utilisées simultanément)• Cohésion logique: les actions du module font partie d’une même logique de programmation mais indépendantes les unes des autres • Cohésion de coïncidence (la pire): les

actions du module n’ont aucune relation fonctionnelle entre elles

Interfaces• Une interface définit les services offert par une unité

logiciel au reste du système, et comment les autres unités peuvent accéder ces services.

• Par exemple, l’interface d’un objet est la collection des opérations publiques de cet objet et les signatures des opérations, qui spécifie pour chaque opération le nom, les paramètres et les potentiels valeurs de retour

Interfaces (Suite)• Une unité logicielle peut exposer différentes interfaces pouvant offrir

notamment différents niveaux de services.

Interfaces (suite)• La spécification de l’interface d’une unité logicielle décrit les

propriétés visibles d’une unité logicielle• Une spécification d’interface communique aux autres développeurs

du système tout ce qu’ils doivent savoir pour utiliser le logiciel correctement

• Fonction• Pré-conditions (hypothèses)• Protocoles• Post-conditions (effets visibles)• Attributs de qualité

Encapsulation• L’encapsulation est un principe

pouvant être utilisé lors de la décomposition d’un système:

• Chaque composant encapsule une décision de conception spécifique qui peut être modifiée dans le futur

• Les interfaces et leurs spécifications sont utilisées pour décrire chaque composant en termes de propriétés exposées

• Avec ce principe, les modules peuvent exhiber différents types de cohésion

• Un module qui masque une représentation de données peut avoir une cohésion informationnelle

• Un module qui masque un algorithme peut avoir une cohésion fonctionnelle

• Un avantage important de l’encapsulation est que les composants logiciels résultants sont lâchement couplés.

Encapsulation dans la modélisation Objet• Dans la conception OO, nous décomposons un système en objets et

leurs types associés• Chaque objet masque sa représentation de données des autres objets• L’accès des autres objets est restreint à un ensemble de fonctions que l’objet

expose dans son interface• L’encapsulation permet de changer facilement le modèle de l’objet sans

perturber le reste du système

Développement incrémental• Etant donnée la conception logicielle de composants logiciels et leurs

interfaces, on peut utiliser les dépendances entre les unités pour concevoir un planning incrémental de développement

• La première étape consiste à construire un graphe d’utilisation

Abstraction• Une abstraction est un

modèle ou représentation qui omet certains détails afin de mettre l’accent sur certains aspects

• Supposons qu’une des fonctions du système est de trier les éléments d’une liste L.

DO WHILE I is between 1 and (length of L)–1:Set LOW to index of smallest value in L(I),..., L(length of L)

Interchange L(I) and L(LOW)

ENDDO

Trier L en ordre croissant

DO WHILE I is between 1 and (length of L)-1Set LOW to current value of IDO WHILE J is between I+1 and

(length of L)IF L(LOW) is greater than

L(J)THEN set LOW to

current value of JENDIF

ENDDOSet TEMP to L(LOW)Set L(LOW) to L(I)Set L(I) to TEMP

ENDDO

Généralisation• La généralisation est le principe qui rend un composant aussi

universel que possible, pour augmenter les chances qu’il soit utile dans un éventuel futur système

• Plusieurs approches:• Paramétrer des informations spécifiques à un contexte• Supprimer les pré-conditions• Simplifier les post-conditions

Généralisation• Les quatre procédures suivantes sont listées en ordre croissant de

généralité:PROCEDURE SUM: INTEGER;POSTCONDITION: returns sum of 3 global variables

PROCEDURE SUM (a, b, c: INTEGER): INTEGER;POSTCONDITION: returns sum of parameters

PROCEDURE SUM (a[]: INTEGER; len: INTEGER): INTEGERPRECONDITION: 0 <= len <= size of array aPOSTCONDITION: returns sum of elements 1..len in array a

PROCEDURE SUM (a[]: INTEGER): INTEGERPOSTCONDITION: returns sum of elements in array a

Modélisation objet• Les méthodologies orientées objet sont les méthodologies les plus

populaires et sophistiquées• Une modélisation objet décompose un système en une collection de

composants appelés objets qui encapsule des données et des fonctionnalités• Les objets sont des entités identifiés de façon unique à l’exécution et qui peuvent être

la cible d’un message ou d’une requête• Les objets peuvent être composés, i.e. les attributs encapsulés par un objet peuvent

être des objets• L’implémentation d’un objet peut être réutilisée et étendue par héritage, pour définir

l’implémentation d’autres objets• Le code OO peut être polymorphique: écrit en code générique qui fonctionne avec

des objets de types différents mais liés

Modélisation objet (Terminologie)• Une classe est un module (composant) logiciel qui implémente un

type de données abstraits• Un objet est une instance d’une classe. Les données encapsulées par

les objets sont appelés attributs, et ces opérations sont appelées méthodes

• Si une classe ne définit pas de méthodes pour une de ces méthodes, on dit qu’elle est abstraite

• La définition d’une classe inclut des constructeurs pour créer des instances

Modélisation Objet (Terminologie)

addItem(Item)removeItem(product No.)computeSubtotal()computeTax()computeTotal()voidSale()

Sale

subtotal : Moneytax : Moneytotal : Money

Date

day: 1..31month : 1..12year : integer

Item

product No.namedescriptionprice : Money

sale date

1*

*

Modélisation Objet (Terminologie)• Les variables peuvent faire référence à des objets de différentes

classes durant l’exécution d’un programme (dynamic binding)• Construire de nouvelles classes en combinant des classes

composantes est appelée composition.• Quatre principaux concepts

Modélisation objet (Terminologie)

• Exemple d’héritage

Modélisation objet (Terminologie)• Le polymorphisme se produit quand le code est écrit en

termes d’interactions avec une interface, mais le comportement du code dépend de l’objet associé avec l’interface à l’exécution et de l’implémentation des méthodes de ces objets

• L’héritage, la composition d’objets et le polymorphisme sont des fonctionnalités importantes d’une conception orientée objet.

Héritage vs Composition• Dans les systèmes OO, deux principales techniques pour construire de

larges objets• Héritage• Composition (Délégation)

• Une nouvelle classe peut être créée en étendant et spécialisant le comportement d’une classe existante, ou elle peut être créé en combinant des classes plus simples pour former une classe composite

Héritage vs Composition (Suite)• La composition (ou délégation) est meilleure que l’héritage dans la

préservation de l’encapsulation du code réutilisée, car l’objet composite accède au composant uniquement par son interface

• Par contraste, en utilisant l’héritage, l’implémentation de la sous classe est déterminée à la conception et est statique

• Les objets resultants sont moins flexibles que les objets instanciés depuis des classes composites parce que les méthodes héritées des parents ne peuvent être modifies à l’execution.

• Le plus grand avantage de l’héritage est la possibilité de changer et spécialiser les comportements des méthodes héritées, en remplaçant sélectivement les comportements des méthodes héritées.

Héritage vs Composition (Suite)

Principe de Liskov• Idéalement, une sous classe préserve le comportement de sa classe parent, tel que le

code client puisse traiter ses instances comme des instances de la classe parent• Principe de substitution de Liskov

• La sous classe supporte toutes les méthodes de la classe parent, et leurs signatures sont compatibles

• Les méthodes de la sous classe doivent vérifier les spécifications des méthodes de la classe parent

• Précondition pre_parent pre⇒ _sub • Postcondition pre_parent (post⇒ _sub post⇒ _parent )

• La sous classe doit préserver toutes les propriétés déclarées de la classe parent

• La substituabilité de Liskov n’est pas un principe rigide. Plutôt, le principe sert comme critère pour déterminer lorsqu’il est sûr de ne pas réexaminer les modules clients d’une classe étendue

Loi de Demeter• Loi de Demeter: Réduire les dépendances en incluant dans chaque

classe composite des méthodes pour opérer sur les composants de la classe

• Le code client qui utilise une classe composite n’a besoin que de connaître le composite et non pas les composants des composites

• Les modèles obéissant à la loi de Demeter ont moins de dépendances de classes, et les classes avec moins de dépendances tendent à avoir moins d’erreur

Loi de Demeter

Types de Relations de classe

association

composition

aggregation

dependency

navigation

generalization

Template de description de classeClass name: Refuel

Category: serviceExternal documents:Export control: PublicCardinality: nHierarchy:

Superclasses: ServiceAssociations:

<no rolename>: fuel in association updatesOperation name: price

Public member of: RefuelDocumentation:

// Calculates fuel final pricePreconditions:

gallons > 0Object diagram: (unspecified)

Template de description de classe (Suite)

Semantics:price = gallons * fuel.price_per_gallontax = price * purchase.tax_rateObject diagram: (unspecified)

Concurrency: sequentialPublic interface:

Operations:price

Private interface:Attributes:

gallonsImplementation:

Attributes:gallons

State machine: noConcurrency: sequentialPersistence: transient

Autres diagrammes UML clés

Patterns OO• Il est aisé de se perdre dans

la conception d’un logiciel• Difficulté à capitaliser

l’expérience• Ecueils: dépendances,

redondances, complexité,…• Inutile de réinventer la roue

• Un patron de conception codifie les décisions de conception et bonnes pratiques pour résoudre un problème particulier de conception selon des principes de conception.

• Un patron de conception doit être éventuellement modifié et adapté pour chaque besoin particulier

Référence intéressante - http://sourcemaking.com/design patterns

Patterns OO: classification• Patterns de création

• i.e. Factory• Patterns structuraux

• i.e. Decorator, Composite• Patterns comportementaux

• i.e. Observer, Visitor, Strategy • Patterns de conccurence

• i.e. Join, Thread Pool

• Les patrons de conception ont été formellement reconnus en 1994 à la suite de la parution du livre Design patterns: Elements of Reusable Software, co-écrit par le Gang of Four (GoF).

• Le livre décrit 23 patrons GoF et comment s’en servir.

Pattern Factory

• Les objets à créer héritent d’une classe abstraite commune C.• Une usine abstraite U permet de créer des objets de type C.• Pour chaque type concret C’, une classe U’ hérite de U.

But: Permettre de créer des objets sans savoir leur type précis.

Pattern StratégieBut: Permettre à un objet de modifier dynamiquement (à l’exécution) un comportement sans changer de classe.

• Le comportement n’est pas implémenté dans la classe de l’objet

• L’objet contient une stratégie et peut en modifier l’instance

• Les stratégies sont implémentées dans différentes classes.

• Il est utile quand plusieurs algorithmes sont disponibles mais le meilleur choix d’algorithme n’est pas à priori connu.

Pattern Décorateur• Le pattern décorateur est

utilisée pour étendre la fonctionnalité d’un objet à l’exécution.

• Le pattern décorateur est une alternative flexible à l’utilisation de l’héritage durant la conception pour créer des sous-classes qui supportent de nouvelles fonctionnalités

• Utilisé dans java.io.

But: Attacher dynamiquement des caractéristiques à des objets sans créer un grand nombre de classes filles.

Pattern Observer

Le pattern observer est une application du style architectural Publish/Subscribe.

But: permettre à des objets de prendre en compte les changements d’autres objets à chaque fois qu’ils se produisent

Pattern Composite

• Un objet composite est une collection d’objets hétérogène potentiellement récursive qui représente une certaine entité composite

• Le pattern composite promeut l’utilisation d’une interface uniforme

But: Traiter de manière indifférente des objets ou ensembles d’objets

Typiquement, opération du composite =

boucle sur ses composants

Pattern Visiteur (Visitor)• La pattern Visitor collecte et

encapsule des fragments d’opérations dans leurs propres classes

• Chaque opération est implémentée comme une sous classe distincte de la classe abstraite Visitor

But: Définir une nouvelle opération sans modifier les classes des éléments sur lesquels ils opèrent.Exemple: Nous souhaitons ajouter un mode débogage sur un ensemble d’objets. Nous ne souhaitons / pouvons pas intégrer les fonctions de debug directement dans les classes concernées.

Pattern Visiteur (Suite)

http://www.informatix.fr/tutoriels/conception/le-design-pattern-visiteur-106

Pattern Visiteur (Suite) class DebugVisitor implements Ivisitor {

public void visit(Dog o) { System.out.println("Breed : " + o.breed); } public void visit(Human o){ System.out.println("Gender : "+ o.gender); } public void visit(IVisitable o){ System.out.println("Not yet"); }}

http://www.informatix.fr/tutoriels/conception/le-design-pattern-visiteur-106

class Dog implements IVisitable{ public String breed = ""; public void accept(IVisitor visitor)

{ visitor.visit(this); } chihuahua}

http://www.google.com/search?hl=en&q=allinurl:docs.oracle.com+javase+docs+api+system



http://www.google.com/search?hl=en&q=allinurl:docs.oracle.com+javase+docs+api+string

Pattern Visiteur (Fin)

public class MainRun { public static void main(String[] args) { DebugVisitor visitor = new DebugVisitor(); Dog dog = new Dog(); /* Display = Breed : chihuahua */ dog.accept(visitor); Human human = new Human(); /* Display = Gender : male */ human.accept(visitor); }}

http://www.google.com/search?hl=en&q=allinurl:docs.oracle.com+javase+docs+api+string

Inversion de contrôle (IoC)• L'inversion de contrôle figure une

nouvelle approche de la programmation de services et de composants.

• Un conteneur d'IoC peut être identifié par trois caractéristiques majeures :• Il contient des objets• Il contrôle la création de ces objets• Il résout les dépendances entre les objets.

• Le conteneur gère le cycle de vie de ces objets. Le programmeur n’a pas à créer les instances ni a libérer les ressources.

• Exemple: Développement de composants permettant de trouver des livres dans une bibliothèque. L’utilisateur pourra demander tous les livres écrits par Victor Hugo, par exemple.

http://gfx.developpez.com/tutoriel/java/ioc/

IoC (Suite) Biblio v1• Manque de

souplesse.• Repose sur

implémentation unique de readbooks

Avec une dépendance directe votre code n'est ni réutilisable ni interchangeable.

IoC (Suite)• Nous souhaitons une bibliothèque

intelligente• Rechercher des livres dans une source

de données quelconque (CSV ou XML)

Biblio v2

Q: Comment substituer CSV à XML ?

L'utilisation d'une interface permet d'abstraire la dépendance et de modifier l'implémentation facilement.

IoC (Suite) Biblio v3 (Singleton)

Le choix d'un singleton permet à présent de modifier l'implémentation de l'import de livres de manière générale.

Q: Comment développer une application qui permet de créer plusieurs bibliothèques ?

IoC (Suite) Biblio v4 (Factory)

• La sélection de l’implémentation adéquate est fortement dépendante du nom de la source.

• Comment libérer le développeur de la charge de gestion des dépendances entre les objets ?

IoC (Suite)

Dépendance explicite avec IbookImporter

Avec l’IoC, l'ajout de dépendances dans votre architecture ne vous demandera aucun effort.

Types IoC

• Injection d’interface (Type 1)• Injection par mutateur (Type 2)• Injection par constructeur

(Type 3)

• Configuration des services et dépendances par

• Code (annotations, ...)• Fichier de configuration

(XML, …)

IoC (Suite)

Biblio v2

IoC

IoC (Principes de fonctionnement)

1

• Création un conteneur d'IoC• Enregistrement des services auprès du conteneur• Demander une référence au service qui nous intéresse

2• Le conteneur créera les instances de la classe appropriée ainsi

que celles de ses dépendances• Dans notre exemple, nous demanderons le service Bookshelf

3

• Le conteneur essayera alors de créer son instance avant de constater qu'elle dépend d'IBookImporter

• Il va donc rechercher une référence à IBookImporter parmi ses services puis l'injecter dans Bookshelf.

• Cette injection peut être réalisée par appel du constructeur ou du mutateur approprié

IoC avec Spring

Spring framework J2EE comprenant des couches:

• Programmation orientée aspect• Authentification et autorisation• Accès aux données (JDBC et NoSQL)• Inversion de contrôle (type 2 et 3)• …

Programmation Orientée AspectProblématiques (Exigences non fonctionnelles) dont l’implémentation se retrouve un peu partout dans les modules du système(crosscutting concerns)

Programmation orientée aspect permet d’implémenter chaque problématique indépendamment des autres puis de les assembler selon des règles bien définies.

https://staff.info.unamur.be/ven/CISma/FILES/2002-baltus.pdf

Programmation Orientée Aspect (Suite)

• Meilleure productivité• Meilleure réutilisation du code• Meilleure adaptation du code

aux changements

La PoA permet d'encapsuler des comportements qui affectaient de multiples classes dans des modules réutilisables.

Programmation Orientée Aspect (Implémentation)

Etape 1. La décomposition des éléments du système. Il s'agit donc d'identifier tous les composants et aspects. On sépare toutes les préoccupations, qu'elles soient fonctionnelles ou non.

Etape 2. L'implémentation de chaque préoccupation. Chaque problématique sera codée séparément dans un composant ou un aspect. Dans un aspect, le programmeur définit aussi les règles d'intégration de l'aspect avec les composants concernés

Etape 3. L'intégration du système. Tout langage OA offre un mécanisme d'intégration appelé le "weaver". Le "weaver", à l'image d'un métier à tisser, va donc composer le système final sur base des règles et des modules qui lui ont été donnés.

Programmation Orientée aspect (Exemple)

Comparaison de l’implémentation d’un

système simple de transaction bancaire dans

un langage objet avec son implémentation

orientée aspect.

Implémentation en langage objet

Programmation orientée aspect On voit que la lisibilité du code en

est améliorée; la classe ne s'occupe plus que des transactions, sans se soucier d'un quelconque enregistrement dans un journal.

Cet aspect assure que chaque fois que la méthode effectuerTransaction de la classe ProcessusTransaction est appelée, on enregistre les informations passées en argument.

Pour que le système soit complet, il nous reste à définir l'aspect de journalisation avec ses règles d'intégration.

Gérer des exigences non fonctionnelles dans la conception• Performance• Sécurité• Evolutivité• Fiabilité• Robustesse• Tolérance aux pannes

http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html

Autres considérations de conception• Gestion des données• Gestion des exceptions• Conception des interfaces• Framework

Métriques de qualité

Introduction• Il est possible d’évaluer la qualité

d’une conception objet ou d’une implémentation à partir de métriques.

• Métriques de Mac Cabe• Métriques de Henry-Kafura• Métriques Objet de Chidamber

et Kemerer• Métriques MOOD d’Abreu.

Complexité structurelle selon Mc Cabe• Métrique la plus utilisée après les lignes de code• Met en évidence la complexité structurelle du code

• On produit un graphe de contrôle qui représente un code• Le nombre de faces du graphe donne la complexité structurelle du

code

Nombre Cyclomatique de Mc CabeC=a – n + 2p

Avec• A=nombre d’arcs du graphe de contrôle• N=nombre de nœuds du graphe de contrôle• P= nombre de composantes connexes (1 le plus souvent)

• Ici, n=8, a=11 et p=1 donc• C=11 – 8 + 2 =5

Calcul direct du nombre de Mc Cabe• Produire un graphe de contrôle et l’analyser peut s’avérer long dans le cas de

programmes complexes• Mc Cabe a introduit une nouvelle manière de calculer la complexité structurelle

avec le nombre de décisions du code• Une instruction IF compte pour 1 décision• Une boucle FOR ou WHILE compte pour 1 décision• Une instruction CASE ou tout autre embranchement multiple compte pour une

décision de moins que le nombre d’alternatives

Nombre de faces et formule de Mc Cabe

• Pourtant , même nombre de faces: la formule serait incorrecte ? Non• Le second graphe est invalide parce qu’il ne possède

pas de nœud d’arrivée

Flux d’informations d’Henry-Kafura• Mesurer la complexité des modules d’un programme en fonction des

liens qu’ils entretiennent• On utilise pour chaque module i:

• Le nombre de flux d’information entrant noté ini

• Le nombre de flux d’information sortant noté outi

• Le poids du module noté poidsi calculé en fonction du nombre de LOC et de sa complexité

La mesure totale HK correspond à la somme des HKi

𝐻𝐾 𝑖=𝑝𝑜𝑖𝑑𝑠𝑖×(𝑜𝑢𝑡𝑖× 𝑖𝑛𝑖)2

Métriques Objet de Chidamber• Ensemble de métriques (Metric suite for Object Oriented

Design)• Evaluation des classes d’un système• La plupart des métriques sont calculées classe par classe• Le passage au global n’est pas clair, une moyenne n’étant pas très

satisfaisante

M1: Méthodes pondérées par classe• WMC: Weighted Methods per Class

x

Un ensemble de n classes comportant chacune méthodes dont la complexité est noté

M2: Profondeur de l’arbre d’héritage• DIT: Depth of Inheritance Tree

• Distance maximale entre un nœud et la racine de la classe d’héritage de la classe concernée

• Calculée pour chaque classe

M3: Nombre d’enfants• NOC: Number Of Children

• Nombre de sous-classes dépendant immédiatement d’une classe donnée, par une relation d’héritage

• Calculée pour chaque classe

M4: Couplage entre classes• Dans un contexte OO, le couplage est l'utilisation de méthodes ou

d'attributs d'une autre classe• Deux classes sont si les méthodes déclarées dans l'une utilisent des méthodes

ou instancie des variables définies dans l'autre• La relation est symétrique: si la classe A est couplée à B, alors B l’est à A

• CBO: Coupling Between Object classes• Pour chaque classe, nombre de classes couplées• Calculée pour chaque classe

M5: Réponses pour une classe (RFC)• {RS}: ensemble des méthodes qui peuvent être exécutées en réponse

à un message reçu par un objet de la classe considérée. • Réunion de toutes les méthodes de la classe avec toutes les méthodes

appelées directement par celles-ci• Calculée pour chaque classe

RFC = |RS|

M6: Manque de cohésion des méthodes• Un module (ou une classe) est cohésif lorsque tous ses éléments sont

étroitement liés• LCOM (Lack of COhesion in Methods) tente de mesurer l’absence de

ce facteur• Posons

• Ii l’ensemble des variables d’instance utilisées par la méthode i• P l’ensemble des paires de (Ii, Ij) ayant une intersection vide• Q l’ensemble des paires de (Ii, Ij) ayant une intersection non vide

LCOM = max (|P| - |Q|, 0)

Métriques MOOD• Ensemble de métriques pour mesurer les attributs des

propriétés suivantes:• Encapsulation• Héritage• Couplage• Polymorphisme

Encapsulation• MHF: Method Hiding Factor (10-30%)

Encapsulation• AHF: Attribute Hiding Factor (70-100%)

𝑴𝑯𝑭=∑𝒊=𝟏

𝑻𝑪𝑨𝒉 (𝑪 𝒊)

∑𝒊=𝟏

𝑻𝑪𝑨𝒅(𝑪𝒊)

Facteurs d’héritage (1/2)• MIF: Method Inheritance Factor (65-80%)

Avec• Mi(Ci) le nombre de méthodes héritées et non surchargées de Ci• Ma(Ci) le nombre de méthodes qui peuvent être appelées depuis la classe i.

𝑴𝑰𝑭=∑𝒊=𝟏

𝑻𝑪𝑴 𝒊(𝑪𝒊)

∑𝒊=𝟏

𝑻𝑪𝑴 𝒂(𝑪 𝒊)

Facteurs d’héritage (2/2)• AIF: Attribute Inheritance Factor

AIF

Facteur de couplage• CF: Coupling Factor (5-30%)

• Mesure le couplage entre les classes sans prendre en compte celui dû à l’héritage

avec

• Client(Ci, Cj) = 1 si la classe i a une relation avec la classe j, et 0 sinon• Les relations d’héritage ne sont pas prises en compte dans les relations

Facteur de polymorphisme• PF: Polymorphism Factor (3-10 %)

• Mesure le potentiel de polymorphisme d’un système

Avec • le nombre de méthodes surchargées dans la classe i• le nombre de nouvelles méthodes dans classe i• DC(Ci) le nombre de descendants de la classe i

Bonnes pratiques de codage

Choses à considérer pendant la phase de codage• Les standards et bonnes pratiques en vigueur dans

l’organisation.• Réutiliser le code d’autres projets• Produire du code de façon à ce qu’il soit réutilisable

dans des futurs projets• Commencer avec la conception détaillée comme cadre

idéal et procéder par itérations jusqu’au code final

Bonnes pratiques de codage• Rendre le code lisible (facile à lire)• Organiser le programme en modules (Packages, etc.)• Trouver le bon niveau de généricité (ni trop spécifique, ni

trop général)• Rendre évidentes les dépendances et le couplage entre

composants• Par le choix des noms des paramètres et des commentaires

Lisibilité - Exemple de structures de contrôle

if (age < 55) benefit = minimum;elseif (AGE < 65) benefit = minimum + bonus;elseif (AGE < 75) benefit = minimum * 1.5 + bonus;else benefit = maximum;

benefit = minimum;if (age < 75) goto A;benefit = maximum;goto C;if (AGE < 65) goto B;if (AGE < 55) goto C;

A: if (AGE < 65) goto B;benefit = benefit * 1.5 + bonus;goto C;

B: if (age < 55) goto C;benefit = benefit * 1.5;

C: next statement

Lisibilité – Exemple avec structure de données

Cas : Déterminer l’impôt fédéral1.Pour les revenus de moins de $10,000, la taxe est de 10%2.Pour les revenus de $10,000 à $20,000, la taxe est de 12%3.Pour les revenus de $20,000 à $30,000, la taxe est de 15%4.Pour les revenus de $30,000 à $40,000, la taxe est de 18%5.Pour les revenus de plus $40,000, la taxe est de 20%

tax = 0.if (taxable_income == 0) goto EXIT;if (taxable_income > 10000) tax = tax + 1000;else{

tax = tax + .10*taxable_income;goto EXIT;

}if (taxable_income > 20000) tax = tax + 1200;else{

tax = tax + .12*(taxable_income-10000):goto EXIT;

}if (taxable_income > 30000) tax = tax + 1500;else{

tax = tax + .15*(taxable_income-20000);goto EXIT;

}if (taxable_income < 40000){

tax = tax + .18*(taxable_income-30000);goto EXIT;

}else

tax = tax + 1800. + .20*(taxable_income-40000);EXIT;

• Définir un tableau pour chaque panier de taux d’imposition

• Algorithme simplifiéfor (int i=2; level=1; i <= 5; i++)

if (taxable_icome > bracket[i]) level = level + 1;

tax= base[level]+percent[level] * (taxable_income - bracket[level]);

Lisibilité – Exemple avec structure de données

Cas : Déterminer l’impôt fédéral

Bonnes pratiques - Algorithmes• Objectif et préoccupation commune: Performance (Vitesse)• Mais l’efficacité peut avoir des coûts cachés

• Coût pour écrire du code plus vite• Coût pour tester le code• Coût pour comprendre le code• Coût pour modifier le code

Recommandations générales pour un code de qualité• Employer du pseudocode• Réviser et réécrire, plutôt que faire du patch• Réutiliser des composants

• Créer des composants conçus pour être réutilisables dans des applications futures.

• Réutiliser des composants initialement développés pour d’autres projets.

Checklist pour décider de la réutilisation de composants• Le composant réalise-t’il la fonction ou fournit-elle les

données requises ? • Moins d’effort est requis que de concevoir le composant

from scratch.• Le composant est-il bien documenté ?

• Fonctionnalités• historique des tests et des révisions

Conseils pour rendre vos composants réutilisables• Rendre les composants génériques.• Séparer les dépendances (pour isoler les sections susceptibles d’être

modifiées).• Concevoir des interfaces génériques et bien-définies.• Documenter toutes les fautes trouvées et corrigées.• Utiliser des conventions de nommage claires.• Documenter les structures de données et les algorithmes.• Garder les sections gérant les communications et les erreurs isolées et

faciles à modifier.

Documentation

Interne• Commentaires (Entête,

variables, signatures, etc.)• Formater correctement pour

faciliter la lecture et la compréhension.

• Documenter les données (dictionnaire des données)

Externe• Décrire le problème• Décrire l’algorithme• Décrire les données

Commentaires d’entête• Quel est le nom du composant ?• Qui a écrit le composant ?• Quelle est la place du composant dans l’architecture globale du

système ?• Quand est-ce que le composant a été écrit et révisé ?• Pourquoi le composant existe ?• Comment est-ce que le composant utilise ses algorithmes, ses

structures de données et de contrôle.

La programmation extrême (XP)

•Les clients: Ils définissent les fonctionnalités utilisant des stories, décrivent les tests détaillés et fixe les priorités.

•Les développeurs: Ils implémentent les stories.

Le Pair Programming (XP)

•Le pilote:contrôlant l’ordinateur et écrivant le code•Le navigateur: contrôle le code du pilote et fait un retour

La documentation reste importante dans les méthodes agiles:• Assiste les développeurs dans la

planification (comme feuille de route)

• Permet de décrire les abstractions clés et définir le périmètre du système

• Contribue à la communication entre les membres d’équipe.

Tests logiciel

Tests logiciel• Tester un logiciel : Exécuter le logiciel avec un ensemble de données

réelles Un programme sans spécifications est toujours correct

• Il faut confronter résultats de l'exécution et résultats attendus• Impossibilité de faire des tests exhaustifs

Ex : 2 entiers sur 32 bits en entrée : 264 possibilités. Si 1ms par test, plus de 108 années nécessaires pour tout tester

• Choix des cas de tests :• Il faut couvrir au mieux l'espace d'entrées avec un nombre réduit d'exemples• Les zones sujettes à erreurs nécessitent une attention particulière

Tests fonctionnels• Identification, à partir des spécifications, des sous-domaines à tester

• Produire des cas de test pour chaque type de sortie du programme• Produire des cas de test déclenchant les différents messages d’erreur

• Objectif: Disposer d’un ensemble de cas de tests pour tester le programme complètement lors de son implémentation

• Test boîte noire parce qu’on ne préjuge pas de l’implémentation• Identification possible des cas de test pertinents avant l’implémentation• Utile pour guider l’implémentation

Exemple• Problème: Créer un ensemble de cas de test pour un programme qui

1. Prend trois nombres a, b et c2. Les interprète comme les longueurs des côtés d’un triangle3. Retourne le type de triangle

ExempleSous-domaines Données de test

Scalènes:• Longueurs par ordre croissant• Longueurs par ordre décroissant• Côté le plus long en second

• (3,4,5) – scalène• (5,4,3) – scalène• (4,5,3) – scalène

Isocèles:• a=b et c plus long• a=c et b plus long• c=b et a plus long• a=b et c plus court• a=c et b plus court• c=b et a plus court

• (5,5,8) – isocèle• (5,8,5) – isocèle• (8,5,5) – isocèle• (8,8,5) – isocèle• (8,5,8) – isocèle• (5,8,8) – isocèle

ExempleSous-domaines Données de testEquilatéraux:• Tous les côtés égaux • (5,5,5) – équilatéral

Pas un triangle:• Côté le plus long en premier• Côté le plus long en second• Côté le plus long en dernier

• (6,4,2) – pas un triangle• (4,6,2) – pas un triangle• (1,2,3) – pas un triangle

Entrées incorrectes:• Une entrée incorrecte• Deux entrées incorrectes• Trois entrées incorrectes

• (-1,2,4) – ent. Incorrectes• (3,-2,-5) – ent. Incorrectes• (0,0,0) – ent. incorrectes

Tests structurels• Tests boîte blanche: détermination des cas de test en fonction du

code• Critère de couverture: Règle pour sélectionner les tests et déterminer

quand les arrêter• Au pire, on peut sélectionner des cas de test au hasard jusqu’à ce que le

critère choisi soit satisfait

• Oracle: Permet de déterminer la sortie attendue associée aux cas sélectionnés

• Difficile à mettre en place si on veut automatiser complètement le processus de test

Couverture de chaque instruction (C0)• Selon ce critère, chaque instruction doit être exécutée avec des

données de test• Sélectionner des cas de test jusqu’à ce qu’un outil de couverture

indique que toutes les instructions du code ont été exécutées

Exemple

• Après le quatrième test, toutes les instructions sont exécutées• Il est rare que le jeu minimal soit bon d’un point de vue fonctionnel

Test de toutes les branches (C1)• Plus complet que C0• Selon ce critère, il faut emprunter les deux directions

possibles au niveau de chaque décision• Nécessite la création d’un graphe de contrôle et de couvrir

chaque arc du graphe

Exemple

Test de tous les chemins• Encore plus complet• Selon ce critère, il faut emprunter tous les chemins possibles dans le

graphe• Chemin: suite unique de nœuds du programme exécutés par un jeu

spécifique de données de test• Peu adapté au code contenant des boucles, le nombre de chemins

possibles étant souvent infini

Exemple

Quelques outils pour le développement de logiciel

Développement distribué et gestion de versions

Git Operations

https://www.git-tower.com/learn/git/ebook/en/command-line/remote-repositories/introduction

Documenter un projet Java (avec Javadoc)

Main Description

Tag Section

Preconditions? Postconditions?

https://docs.oracle.com/javase/7/docs/api/overview-summary.html

JUnit• JUnit désigne un framework de rédaction et d'exécutions de tests unitaires.

Architecture JUnitNaouel Moha, University of Montreal

Junit (Suite)

Automatiser la création et l’installation d’exécutable (Cas de Maven)

• Outil pour la construction (build) automatisée de logiciel pour la plateforme Java.

• Un fichier de configuration (pom.xml – potentiellement complexe) contient la majorité des informations requises pour construire le projet.

• Les différentes phases du cycle de vie:

• Validate• Compile• Test• Package (i.e. jar format)• Integration-test• Verify• Install• Deploy

• Aussi:• Clean• Site (Document pour le projet)

Intégration continue avec JenkinsL'intégration continue est une pratique de développement logiciel dans laquelle les membres d’une équipe intègre leurs travaux fréquemment, usuellement chaque développeur intègre au moins quotidiennement. Chaque intégration est vérifié par un build automatisé pour détecter les erreurs d’intégration le plus tôt possible.

• Jenkins est un outil open source pour la plateforme Java.

• Il supporte de nombreux outils – Subversion / Git, Apache Ant/Maven, Scripts.

• Les builds peuvent être déclenchées soit par un commit, soit par des tâches cron.

• Jenkins intègre des plugins (notamment pour gérer les rapports de test).http://martinfowler.com/articles/continuousIntegration.html

Déploiement d’applications (distribuées) dans des conteneurs Docker• Docker est une solution open source

pour automatiser le déploiement d’applications dans des conteneurs.

• Docker est une technologie Linux qui étend LXC avec une API évoluée.

• L’utilisation principale de Docker est à partir d’une série de commandes de mettre en place un environnement clean réflétant ses paramètres

• On peut par exemple grâce à une image créer un environnement de développement et de test identique à l’environnement de production.

• Il existe des outils d’orchestration des containers (Kubernetes, Swarm, etc.)

• Kubernetes est un outil open source de gestion de containers dans les environnements en cluster.

• Load balancing• Auto-healing• Fonctionnalités de scalabilité

https://techbeacon.com/essential-guide-software-containers-application-development

• Docker est aussi très utilisé dans le cloud car il facilite la portabilité des applications – la virtualisation classique est plus lourde pour la migration de Workload.

Tendances en Ingénierie du logiciel• Frameworks applicatives• Open source• Stratégies cloud• NoSQL• Machine learning• Développement dirigé par les

modèles (Model driven engineering)

• Appoches incrémentales• Tableaux de bords• Environnements de

développement distribués• DevOps

http://resources.sei.cmu.edu/asset_files/Webinar/2015_018_100_438676.pdf

Références• Pfleeger and Atlee, Software Engineering: Theory and Practice, 4th edition.• Michel Winter, Gestion de projet en SSII, ellipses.• Pierre Gérard, Cours de Génie Logiciel, L3 IUT Villetaneuse.• Abdellatif Mezrioui, Cours d’Introduction au Génie Logiciel, INPT Rabat (2004).• Grégory Bonnet, et al., Cours de Génie Logiciel, Université de Caen (2014)• Cyril Rabat, Cours de Systèmes et Applications Réparties, CNAM (2013)• Référence sur les patterns de conception - https://sourcemaking.com

"If I have seen further it is by standing on the shoulders of giants.“

(Isaac Newton)