SlideShare ist ein Scribd-Unternehmen logo
1 von 357
Downloaden Sie, um offline zu lesen
Génie Logiciel
(Software Engineering)
Licence Informatique
Dr DIALLO Mohamed
diallo.med@gmail.com
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
Contenu
VH
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 tard
Logiciel 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%
0%
10%
20%
30%
40%
50%
60%
Origine des erreurs
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)
A. Mezrioui, Introduction au Génie Logiciel, 2004
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
A. Mezrioui, Introduction au Génie Logiciel, 2004
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
Pfleeger et Atlee, Software Engineering: Theory and Practice
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
Pfleeger et Atlee, Software Engineering: Theory and Practice
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
Pfleeger et Atlee, Software Engineering: Theory and Practice
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
Pfleeger et Atlee, Software Engineering: Theory and Practice
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 ?
Pfleeger et Atlee, Software Engineering: Theory and Practice
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)
Pfleeger et Atlee, Software Engineering: Theory and Practice
Processus de développement
Cycle de vie
La 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 client
2. Analyse des risques
3. Conception
4. Implémentation
5. Tests
6. 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.
Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
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
Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
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
Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
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
Ph. Legall – Training TAD.
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.
Ph. Legall – Training TAD.
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-2
Activité_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 construction
1/ Pré-requis : les activités du WBS et leur durée sont identifiées
2/ Créer les activités de début et fin
3/ Créer les jalons et toutes les activités du WBS ayant une durée
4/ Lier les activités entre elles
5/ 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
0
DEBUT
PROJET
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
0
DELAI
OBJECTIF
+ 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 ressources
MOYENS
nécessaires à la réalisation
des activités du projet/affaire
INDICATEURS
Suivis au niveau de la
conduite du projet/affaire
FINALITES
LES
RESSOURCES
NATURE
Main d'œuvre
Frais
CATEGORIE
Pour la main d'œuvre :
Ingénieur, Technicien...
CARACTERISTIQUES
COUT UNITAIRE
Taux 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 EN
QUANTITE RESSOURCE
PAR ACTIVITE
OU
100 heures sur activité
10 jours
EXPRIMEES EN
UNITE RESSOURCE
PAR UNITE
DE 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
8
7
6
5
RESSOURCE A
RESSOURCE B
RESSOURCE C
Périodes
(calendrier des disponibilités)
Quantité disponible
par 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
Semi-détaché 2,5 0,35
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
Semi-détaché 3,0 1,12
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 risques
Risque 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. Impact
Matériel non dispo Accélérer le dév.
du matériel
Concevoir 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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Caractéristiques des exigences
•Correctes
•Cohérentes
•Sans ambiguïtés
•Complètes
•Faisable
•Pertinence
•Testable
•Traçabilité
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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)
Pfleeger and Atlee, Software Engineering: Theory and Practice
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écifications
Combinent 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é
Pfleeger and Atlee, Software Engineering: Theory and Practice
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ées
Pfleeger 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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Documentation
des exigences
1. Introduction to the Document
1.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 SRS
2. 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 Requirements
4. Appendices
Standards de
l’IEEE pour SRS
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Notation des exigences – Echelle de 1 à 5
1. 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.
Pfleeger and Atlee, Software Engineering: Theory and Practice
Notation des exigences – Testeurs /
Concepteurs
a) Les exigences sont bien
rédigées
• 1 et 2 dominent
b) Les exigences doivent être
révisées
• 4 et 5 dominent
Pfleeger and Atlee, Software Engineering: Theory and Practice
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
Pfleeger and Atlee, Software Engineering: Theory and Practice
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)
http://alistair.cockburn.us/
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
Exemple
Rajouter 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
Pfleeger and Atlee, Software Engineering: Theory and Practice
Client/Serveur
• Deux types de
composants:
• Composant Serveur
offre des services
• Clients y accèdent en
utilisant un protocole
requête/réponse
Pfleeger and Atlee, Software Engineering: Theory and Practice
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 couche
Modè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 Objet
Conception 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 communes
Modifier 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)
Coincidental
Logical
Temporal
Procedural
Communicational
Functional
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
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel
Introduction au génie logiciel

Weitere ähnliche Inhalte

Was ist angesagt?

Correction Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfCorrection Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfslimyaich3
 
Analyse et conception des systèmes d’information
Analyse et conception des systèmes d’informationAnalyse et conception des systèmes d’information
Analyse et conception des systèmes d’informationMireille Blay-Fornarino
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLLilia Sfaxi
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriMansouri Khalifa
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-CorrectionLilia Sfaxi
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMireille Blay-Fornarino
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Heithem Abbes
 
Design Patterns
Design PatternsDesign Patterns
Design PatternsKoffi Sani
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Ayed CHOKRI
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptxLatifaBen6
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRouâa Ben Hammouda
 
TP1-UML-Correction
TP1-UML-CorrectionTP1-UML-Correction
TP1-UML-CorrectionLilia Sfaxi
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Présentation Tests Fonctionnels
Présentation Tests FonctionnelsPrésentation Tests Fonctionnels
Présentation Tests FonctionnelsDATANYWARE.com
 

Was ist angesagt? (20)

Correction Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdfCorrection Examen 2016-2017 POO .pdf
Correction Examen 2016-2017 POO .pdf
 
Analyse et conception des systèmes d’information
Analyse et conception des systèmes d’informationAnalyse et conception des systèmes d’information
Analyse et conception des systèmes d’information
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGL
 
Test logiciel
Test logicielTest logiciel
Test logiciel
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifié
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
 
Cours uml
Cours umlCours uml
Cours uml
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
TP1-UML-Correction
TP1-UML-CorrectionTP1-UML-Correction
TP1-UML-Correction
 
Modele rapport pfe esprit
Modele rapport pfe  espritModele rapport pfe  esprit
Modele rapport pfe esprit
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
 
Présentation Tests Fonctionnels
Présentation Tests FonctionnelsPrésentation Tests Fonctionnels
Présentation Tests Fonctionnels
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 

Andere mochten auch

Mia-Software at MD Day 2010
Mia-Software at MD Day 2010Mia-Software at MD Day 2010
Mia-Software at MD Day 2010fmadiot
 
Software Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTourSoftware Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTourJean-Laurent de Morlhon
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesEric Le Merdy
 
Crm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.comCrm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.comguest43084e
 
LRA_presentation2011[1]
LRA_presentation2011[1]LRA_presentation2011[1]
LRA_presentation2011[1]Nathon Chacon
 
Citizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture BooksCitizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture Bookstreyveazey
 
Institutional Repositories: What the Open Access agenda means for a modern in...
Institutional Repositories: What the Open Access agenda means for a modern in...Institutional Repositories: What the Open Access agenda means for a modern in...
Institutional Repositories: What the Open Access agenda means for a modern in...Gaz Johnson
 
17 02-24 lara investor presentation
17 02-24 lara investor presentation17 02-24 lara investor presentation
17 02-24 lara investor presentationLara_Exploration
 
The Stars My Destination
The Stars My DestinationThe Stars My Destination
The Stars My DestinationGaz Johnson
 
Joseph Kony and the LRA
Joseph Kony and the LRAJoseph Kony and the LRA
Joseph Kony and the LRAchristyleigh19
 
Leicester Research Archive (LRA): the work of a repository administrator
Leicester Research Archive (LRA): the work of a repository administratorLeicester Research Archive (LRA): the work of a repository administrator
Leicester Research Archive (LRA): the work of a repository administratorGaz Johnson
 
Macro diagrams and definitions
Macro diagrams and definitionsMacro diagrams and definitions
Macro diagrams and definitions12jostma
 
Le Software Defined Storage, pour éliminer toutes les contraintes du stockage
Le Software Defined Storage, pour éliminer toutes les contraintes du stockageLe Software Defined Storage, pour éliminer toutes les contraintes du stockage
Le Software Defined Storage, pour éliminer toutes les contraintes du stockageNoham MEDYOUNI
 
Bâtir une équipe F Lussier V1.2 Fra
Bâtir une équipe F Lussier V1.2 FraBâtir une équipe F Lussier V1.2 Fra
Bâtir une équipe F Lussier V1.2 FraFrederick Lussier
 
3.4 Demand And Supply Side Policies
3.4   Demand And Supply Side Policies3.4   Demand And Supply Side Policies
3.4 Demand And Supply Side PoliciesAndrew McCarthy
 
3.3 Macro Economic Models
3.3   Macro Economic Models3.3   Macro Economic Models
3.3 Macro Economic ModelsAndrew McCarthy
 

Andere mochten auch (20)

Mia-Software at MD Day 2010
Mia-Software at MD Day 2010Mia-Software at MD Day 2010
Mia-Software at MD Day 2010
 
Software Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTourSoftware Craftsmanship : en Pratique - AgileTour
Software Craftsmanship : en Pratique - AgileTour
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
 
Software Craftsmanship: En pratique
Software Craftsmanship: En pratiqueSoftware Craftsmanship: En pratique
Software Craftsmanship: En pratique
 
Crm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.comCrm Software Salesboom.com Salesforce.com
Crm Software Salesboom.com Salesforce.com
 
LRA_presentation2011[1]
LRA_presentation2011[1]LRA_presentation2011[1]
LRA_presentation2011[1]
 
Citizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture BooksCitizens of the World: Finding Joy through International Picture Books
Citizens of the World: Finding Joy through International Picture Books
 
Lesion renal aguda LRA
Lesion renal aguda LRALesion renal aguda LRA
Lesion renal aguda LRA
 
Institutional Repositories: What the Open Access agenda means for a modern in...
Institutional Repositories: What the Open Access agenda means for a modern in...Institutional Repositories: What the Open Access agenda means for a modern in...
Institutional Repositories: What the Open Access agenda means for a modern in...
 
17 02-24 lara investor presentation
17 02-24 lara investor presentation17 02-24 lara investor presentation
17 02-24 lara investor presentation
 
The Stars My Destination
The Stars My DestinationThe Stars My Destination
The Stars My Destination
 
Joseph Kony and the LRA
Joseph Kony and the LRAJoseph Kony and the LRA
Joseph Kony and the LRA
 
Leicester Research Archive (LRA): the work of a repository administrator
Leicester Research Archive (LRA): the work of a repository administratorLeicester Research Archive (LRA): the work of a repository administrator
Leicester Research Archive (LRA): the work of a repository administrator
 
Missles flight control systems
Missles flight control systemsMissles flight control systems
Missles flight control systems
 
Macro diagrams and definitions
Macro diagrams and definitionsMacro diagrams and definitions
Macro diagrams and definitions
 
Le Software Defined Storage, pour éliminer toutes les contraintes du stockage
Le Software Defined Storage, pour éliminer toutes les contraintes du stockageLe Software Defined Storage, pour éliminer toutes les contraintes du stockage
Le Software Defined Storage, pour éliminer toutes les contraintes du stockage
 
Présentation Conférence des TechTrends
Présentation Conférence des TechTrendsPrésentation Conférence des TechTrends
Présentation Conférence des TechTrends
 
Bâtir une équipe F Lussier V1.2 Fra
Bâtir une équipe F Lussier V1.2 FraBâtir une équipe F Lussier V1.2 Fra
Bâtir une équipe F Lussier V1.2 Fra
 
3.4 Demand And Supply Side Policies
3.4   Demand And Supply Side Policies3.4   Demand And Supply Side Policies
3.4 Demand And Supply Side Policies
 
3.3 Macro Economic Models
3.3   Macro Economic Models3.3   Macro Economic Models
3.3 Macro Economic Models
 

Ähnlich wie Introduction au génie logiciel

Analyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdfAnalyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdfJordaniMike
 
coursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdfcoursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdfHervKoya
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppthbadir
 
introduction génie logiciel-1.ppt
introduction génie logiciel-1.pptintroduction génie logiciel-1.ppt
introduction génie logiciel-1.pptSafaeElhouicha
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
491723007-Assurance-Qualite-de-Logiciel-1.pdf
491723007-Assurance-Qualite-de-Logiciel-1.pdf491723007-Assurance-Qualite-de-Logiciel-1.pdf
491723007-Assurance-Qualite-de-Logiciel-1.pdfHalimaDOUIBI
 
Solutions Linux2008 Construire Sa Vision Qualite
Solutions Linux2008 Construire Sa Vision QualiteSolutions Linux2008 Construire Sa Vision Qualite
Solutions Linux2008 Construire Sa Vision Qualitefrancois.le.droff
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileNormandy JUG
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyonClement Bouillier
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelAgile Montréal
 
2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciellauraty3204
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logicielguest0032c8
 
Developement logiciel: comment livrer de la qualite ?
Developement logiciel: comment livrer  de la qualite ?Developement logiciel: comment livrer  de la qualite ?
Developement logiciel: comment livrer de la qualite ?Innobec
 
2 relation-acteurs-projet
2 relation-acteurs-projet2 relation-acteurs-projet
2 relation-acteurs-projetbriann_guillaud
 

Ähnlich wie Introduction au génie logiciel (20)

Analyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdfAnalyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdf
 
coursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdfcoursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdf
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
 
introduction génie logiciel-1.ppt
introduction génie logiciel-1.pptintroduction génie logiciel-1.ppt
introduction génie logiciel-1.ppt
 
Assurance qualité
Assurance qualitéAssurance qualité
Assurance qualité
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Hands on Sonar
Hands on SonarHands on Sonar
Hands on Sonar
 
491723007-Assurance-Qualite-de-Logiciel-1.pdf
491723007-Assurance-Qualite-de-Logiciel-1.pdf491723007-Assurance-Qualite-de-Logiciel-1.pdf
491723007-Assurance-Qualite-de-Logiciel-1.pdf
 
Esiea - 5A - Archi 1/3
Esiea - 5A - Archi 1/3Esiea - 5A - Archi 1/3
Esiea - 5A - Archi 1/3
 
Qualite1
Qualite1Qualite1
Qualite1
 
Solutions Linux2008 Construire Sa Vision Qualite
Solutions Linux2008 Construire Sa Vision QualiteSolutions Linux2008 Construire Sa Vision Qualite
Solutions Linux2008 Construire Sa Vision Qualite
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet Agile
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel
 
Gl rappels ac
Gl rappels acGl rappels ac
Gl rappels ac
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
 
Developement logiciel: comment livrer de la qualite ?
Developement logiciel: comment livrer  de la qualite ?Developement logiciel: comment livrer  de la qualite ?
Developement logiciel: comment livrer de la qualite ?
 
2 relation-acteurs-projet
2 relation-acteurs-projet2 relation-acteurs-projet
2 relation-acteurs-projet
 

Mehr von Mohamed Diallo

Mehr von Mohamed Diallo (8)

Cours 70 410 - J5
Cours 70 410 - J5Cours 70 410 - J5
Cours 70 410 - J5
 
Cours 70 410 - J4
Cours 70 410 - J4Cours 70 410 - J4
Cours 70 410 - J4
 
Cours 70 410 - J3
Cours 70 410 - J3Cours 70 410 - J3
Cours 70 410 - J3
 
Cours 70 410 - J2
Cours 70 410 - J2Cours 70 410 - J2
Cours 70 410 - J2
 
Cours 70 410-1
Cours 70 410-1Cours 70 410-1
Cours 70 410-1
 
Techniques d’etudes et de recherche
Techniques d’etudes et de rechercheTechniques d’etudes et de recherche
Techniques d’etudes et de recherche
 
Crypto-talk-gea-1401
Crypto-talk-gea-1401Crypto-talk-gea-1401
Crypto-talk-gea-1401
 
Introduction
IntroductionIntroduction
Introduction
 

Introduction au génie logiciel

  • 1. Génie Logiciel (Software Engineering) Licence Informatique Dr DIALLO Mohamed diallo.med@gmail.com UFRMI 2017.
  • 2. 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
  • 3. 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
  • 4. Contenu VH 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
  • 5. La crise du logiciel et l’évolution de l’ingénierie du logiciel
  • 6. Matériel et logiciel • Matériel est relativement fiable (marché standardisé) • Les problèmes liés à l’informatique sont essentiellement des problèmes logiciels
  • 7. 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
  • 8. 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
  • 9. 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/
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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 $.
  • 14. 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 tard Logiciel payé mais non livré Neuf grands projets de gestion de l’administration américaine ($6,8 millions)
  • 15. 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
  • 16. 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
  • 17. 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.
  • 18. 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% 0% 10% 20% 30% 40% 50% 60% Origine des erreurs Specification Conception Codage Etape du cycle Coût relatif Développement 33% Maintenance 67% A. Mezrioui, Introduction au Génie Logiciel, 2004
  • 19. 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) A. Mezrioui, Introduction au Génie Logiciel, 2004
  • 20. 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 A. Mezrioui, Introduction au Génie Logiciel, 2004
  • 21. 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 ?
  • 22. 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
  • 23. 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
  • 24. 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 Pfleeger et Atlee, Software Engineering: Theory and Practice
  • 26. 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.
  • 27. 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
  • 28. 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 Pfleeger et Atlee, Software Engineering: Theory and Practice
  • 29. Méthodes et Notations (Analyse et Conception) •Documenter •Faciliter la communication •Offrir des vues multiples •Unifier différentes vues
  • 30. 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 Pfleeger et Atlee, Software Engineering: Theory and Practice
  • 31. 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
  • 32. 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
  • 33. 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 Pfleeger et Atlee, Software Engineering: Theory and Practice
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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)
  • 38. Nouvelle tendance dans les recrutements scorify.me
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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...)
  • 45. 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é
  • 47. 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
  • 48. 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
  • 49. Facilité de maintenance • Un logiciel ne s’use pas • Pourtant, la maintenance absorbe une très grosse partie des efforts de développement
  • 50. 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
  • 51. 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 ? Pfleeger et Atlee, Software Engineering: Theory and Practice
  • 52. 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
  • 53. 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) Pfleeger et Atlee, Software Engineering: Theory and Practice
  • 55. Cycle de vie La 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
  • 56. Composantes du cycle de vie d’un logiciel • Etude de faisabilité • Spécification • Organisation du projet • Conception • Implémentation • Tests • Livraison • Maintenance
  • 57. 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
  • 58. Membres d’une équipe de développement
  • 59. 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
  • 60. 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
  • 61. 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
  • 62. 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
  • 63. 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
  • 64. 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
  • 65. 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)
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. 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)
  • 71. 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…
  • 72. 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
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. Le cycle de vie en cascade
  • 77. 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.
  • 78. 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
  • 79. Le cycle de vie en « V » • Adapté pour des projets dont le domaine est bien maitrisé
  • 80. 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
  • 81. 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
  • 82. Le modèle en spirale • Un modèle mixte • A chaque cycle recommencer: 1. Consultation du client 2. Analyse des risques 3. Conception 4. Implémentation 5. Tests 6. 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
  • 83. 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
  • 84. 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
  • 85. 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
  • 86. Exemples de Méthodes agiles • Extreme programming (XP) • Scrum: 30-day iterations; multiple self-organizing teams, daily scrum coordination
  • 87. Gestion de projet: Vers les méthodes agiles Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
  • 88. 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. Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
  • 89. 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
  • 90. 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
  • 91. 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 Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
  • 92. 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 Diallo Daouda, Exposé sur les méthodes agiles, AGITEL 2016
  • 94. 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%
  • 95. 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
  • 96. 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
  • 97. 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
  • 98. 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
  • 99. 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.
  • 100. 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 Ph. Legall – Training TAD.
  • 101. 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. Ph. Legall – Training TAD.
  • 102. 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é
  • 103. WBS
  • 104. 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
  • 105. 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
  • 106. 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-2 Activité_A durée PERT Activité_A Durée Activité_BDélai éventuel Date_Début Date_fin Date_Début Date_fin POTENTIEL
  • 107. 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.
  • 108. 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,
  • 109. Exemples Dates de début et de fin désignation durée AvancementMarge
  • 110. Méthode de construction 1/ Pré-requis : les activités du WBS et leur durée sont identifiées 2/ Créer les activités de début et fin 3/ Créer les jalons et toutes les activités du WBS ayant une durée 4/ Lier les activités entre elles 5/ 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.
  • 111. 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 0 DEBUT PROJET 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é
  • 112. 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 0 DELAI OBJECTIF + 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.
  • 113. 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)
  • 114. 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)
  • 115. 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
  • 116. 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.
  • 117. 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
  • 118. 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
  • 119. 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)
  • 120. Exemple de GANTT : SP COBRA Planning de référence
  • 121. 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.
  • 122. Les ressources MOYENS nécessaires à la réalisation des activités du projet/affaire INDICATEURS Suivis au niveau de la conduite du projet/affaire FINALITES LES RESSOURCES NATURE Main d'œuvre Frais CATEGORIE Pour la main d'œuvre : Ingénieur, Technicien... CARACTERISTIQUES COUT UNITAIRE Taux horaire, …
  • 123. 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 EN QUANTITE RESSOURCE PAR ACTIVITE OU 100 heures sur activité 10 jours EXPRIMEES EN UNITE RESSOURCE PAR UNITE DE TEMPS 10 heures par jour 10 jours D1 D2 DUREE ACTIVITE
  • 124. La disponibilité des ressources • Les ressources "disponibles" sont les moyens dont on dispose effectivement 8 7 6 5 RESSOURCE A RESSOURCE B RESSOURCE C Périodes (calendrier des disponibilités) Quantité disponible par unité de temps
  • 125. 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.
  • 126. 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
  • 127. 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
  • 128. 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.
  • 129. 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
  • 130. 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
  • 131. 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.
  • 132. 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.
  • 133. 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
  • 134. 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)
  • 135. 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
  • 136. 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
  • 137. 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 Semi-détaché 2,5 0,35 Embarqué 2,5 0,32
  • 138. 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
  • 139. Les attributs du logiciel • Besoin en fiabilité • Taille de la base de données • Complexité du produit
  • 140. 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)
  • 141. 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 • …
  • 142. 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
  • 143. 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 Semi-détaché 3,0 1,12 Embarqué 2,8 1,20
  • 144. 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
  • 145. 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
  • 146. 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
  • 147. 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
  • 149. 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
  • 150. 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
  • 151. 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
  • 152. 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
  • 153. 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
  • 154. 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
  • 155. 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
  • 157. 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é
  • 158. Exemples de types de risques Risque 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
  • 159. 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
  • 160. 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
  • 161. 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
  • 162. Exemples de stratégies d’atténuation des risques Risque Réd. Proba Réd. Impact Matériel non dispo Accélérer le dév. du matériel Concevoir 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
  • 164. 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é
  • 165. 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
  • 166. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 167. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 168. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 169. 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
  • 170. 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
  • 171. 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
  • 172. 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
  • 173. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 174. Caractéristiques des exigences •Correctes •Cohérentes •Sans ambiguïtés •Complètes •Faisable •Pertinence •Testable •Traçabilité Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 175. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 176. 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) Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 177. 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
  • 178. 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
  • 179. 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é.
  • 180. 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
  • 181. 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
  • 182. 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
  • 183. 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.
  • 184. DFD: Variante (Cas d’utilisation UML)
  • 185. 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
  • 186. Tables de décisions • Table de décision pour les fonctions de la bibliothèque: • Borrow • Return • Reserve • Unreserve
  • 187. 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
  • 188. 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
  • 189. 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
  • 190. 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.
  • 191. 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
  • 192. Langages de spécifications Combinent 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
  • 193. 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
  • 194. 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é Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 195. 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ées Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 196. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 197. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 198. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 199. Documentation des exigences 1. Introduction to the Document 1.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 SRS 2. 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 Requirements 4. Appendices Standards de l’IEEE pour SRS Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 200. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 201. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 202. 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
  • 203. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 204. Notation des exigences – Echelle de 1 à 5 1. 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. Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 205. Notation des exigences – Testeurs / Concepteurs a) Les exigences sont bien rédigées • 1 et 2 dominent b) Les exigences doivent être révisées • 4 et 5 dominent Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 206. 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
  • 207. 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/
  • 208. 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é
  • 209. Exemple Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 210. 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)
  • 211. 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
  • 212. 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
  • 213. 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) http://alistair.cockburn.us/
  • 214. 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
  • 215. Exemple Rajouter 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
  • 217. 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
  • 218. 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
  • 219. 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
  • 220. Exemple d’architecture logicielle (modèle de référence) Modèle de référence Pour un compilateur
  • 221. Processus de conception • La conception logicielle est un processus itératif • Le résultat final est le SAD (Software Architecture Document)
  • 222. 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
  • 223. Styles architecturaux et stratégies • Modèle en couche • Publish-Subscribe • Filtres et tubes • Client-Serveur • Pair-à-pair • MVC (Modèle Vue Contrôleur)
  • 224. 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 Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 225. Client/Serveur • Deux types de composants: • Composant Serveur offre des services • Clients y accèdent en utilisant un protocole requête/réponse Pfleeger and Atlee, Software Engineering: Theory and Practice
  • 228. Client / Server – Architecture N-tiers
  • 230. 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
  • 231. 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
  • 232. 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
  • 233. Exemple de Système en couche Modèle OSI
  • 234. 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)
  • 236. 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é
  • 237. 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)
  • 238. 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
  • 239. 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
  • 240. 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
  • 241. 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.
  • 242. 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
  • 243. 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
  • 244. Couplage par données communes Modifier les données partagées a un impact sur tous les composants ayant accès à ces données
  • 245. 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é
  • 246. Cohésion • La cohésion mesure à la dépendance entre les éléments internes à un module (e.g. données, fonctions, modules internes) Coincidental Logical Temporal Procedural Communicational Functional Informational HIGH COHESION
  • 247. 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