Vous êtes sur la page 1sur 61

COURS GÉNIE LOGICIEL

Patrick Nourrissier – ISGA Rabat 2022


Présenter les principes, méthodes et outils du
génie logiciel

Parler de développement: méthodes, test, code,


gestion de versions/de configurations,
OBJECTIFS DU métriques

COURS Références

• cours d’Olivier Perrin et de P. Fontaine


• cours de M. Dumas
• cours/livre de I. Sommerville présentation de
L. Torvalds
PLAN
• Introduction

• Méthodes

• Tests

• Gestion des configurations

• Code/patrons

• Métriques

• Outils
L’ARCHITECTURE
… cela évolue lentement…
L’ARCHITECTURE
… cela grossit petit à petit…
L’ARCHITECTURE
…pour devenir dense…
L’ARCHITECTURE
… et complexe !!!
L’ARCHITECTURE
…voir fantastique !
DANS LE DOMAINE DU LOGICIEL...
ARCHITECTURE/
L’ENNEMI
Côté fiabilité: le
bug

2ème guerre mondiale : problèmes électroniques dans les radars appelés


bugs. Utilisation de “bug” serait beaucoup plus ancienne.

Cause d’un mal-fonctionnement dans un Mark II : papillon de nuit coincé dans


un relais. Bug soigneusement intégré au livre de bord, le 9 septembre 1947
LES BUGS CÉLÈBRES
Therac-25 (1985-1987) : appareil radio-thérapeutique. Ariane 5 (1996) : réutilisation inappropriée de code d’Ariane
Problème lié aux filtres. Coût : ≥ 5 décès. 4. Effet : explosion. Coût : 109 $

Mars

1985–1987 1996

NASA Mars Rover (21 janvier 2004) : paralysé à cause


d’une erreur système : trop de fichiers ouverts sur la
mémoire flash
LES BUGS CÉLÈBRES(CONT.)
Intel Pentium FDIV : erreur dans l’opération FDIV,
précision

Plus récemment, Intel Sandy Bridge et les failles de sécurité Spectre et Meltdown

Le défaut affecte particulièrement les composants Cougar Point (Intel H67 et P67)
dédiés à Sandy Bridge. « Dans certains cas, explique Intel, les ports le Serial-ATA
(SATA) gérés par les chipsets peuvent se dégrader au fil du temps, ce qui pourrait
affecter les performances ou les fonctionnalités des périphériques SATA liés tels que
les disques durs et les lecteurs DVD. » Ennuyeux. Même si le processeur n’est pas
directement touché par ce défaut de fabrication, il n’en risque pas moins d’entraîner
une baisse des performances globale du système, freiné par la fluidité de circulation
des données. Un comble pour une plate-forme de dernière génération dont les hautes
performances sont mises en avant.
LES BUGS CÉLÈBRES(CONT.)
Airbus 320 (http://www.youtube.com/watch?v=2eQpUgHkBcg)

Collection de bugs

‣ http://www5.in.tum.de/~huckle/bugse.html

‣ http://en.wikipedia.org/wiki/Software_bug

‣ http://www.risks.org/
L’ENNEMI
Côté délais
LESDÉLAIS
FF4

‣ de juin à mars: 10 mois


LES DÉLAIS (CONT.)
Chrome

Anthony
Laforge
LES DÉLAIS (CONT.)
« We market features, not releases.
»
IDÉESREÇUES
Idée grossière du logiciel à réaliser suffisant pour commencer le programme
‣ idée imprécise = source d’erreur
Programme terminé et fonctionne : travail terminé
‣ maintenance = travail important

‣ coût de maintenance élevé


Changement des spécifications possible car logiciel = produit souple
‣ changement de spécifications : coûteux, allongent délais
Si réalisation logiciel en retard % délais prévus : ajouter programmeurs, ajouter
personnel :
‣ nécessite période de familiarisation
‣ temps passé à communiquer augmente avec taille du
‣ groupe réduction productivité de chacun
CONSTAT D’ÉCHEC
« The CHAOS Summary Report » :

‣ 24% des développements applicatifs sont des échecs

‣ 84% des projets critiques n'atteignent pas leurs objectifs

‣ 54% ont rencontré des dépassements de coûts

‣ 79% ont des dépassements d'échéanciers

« Le coût moyen d'une mise à jour technologique est de 18% du coût original
du projet » (CIO Magazine)
QUESTIONS QUE SEPOSE UN CHEF DE PROJET

Comment diminuer les délais et les coûts de mes projets ?

Où sont mes spéciifications à jour ?

Comment capitaliser le savoir faire de mes équipes ?

Comment être plus agile avec les évolutions ?


COMMENT JUGER DE LA QUALITÉ DU LOGICIEL
• Répond aux attentes

• Correct : réalise les spécifications

• Coût initial contrôlé

• Délai initial contrôlé

• Maintenance facile : extension aisée, coûts, et délais contrôlés


LA VISIONIDÉALE
LARÉALITÉ…
POURQUOI EST-CE DE PLUS EN PLUS COMPLEXE ?
• Exigences en hausse

• Taille en hausse

• Logiciels de plus en plus critiques

• Dépendances entre logiciels

• Sous-traitance
SPÉCIFICATION DESBESOINS
Besoins fonctionnels

Spécifier :
‣ entrées, avec sources, précision, valeurs acceptées, format
‣ sorties, avec destination, précision, plage de valeur,

‣ format formats pour les rapports, pages web...

‣ interfaces hardware et softwares


‣ interfaces de communication, avec protocoles, hand-shaking,
correction d’erreur
‣ tâches de l’utilisateur
‣ données utilisées pour chaque tâche, et les données résultant de
chaque tâche
SPÉCIFICATION DES BESOINS(CONT.)
Besoins non-fonctionnels

Spécifier

‣ temps de réponses pour toutes les opérations

‣ autres temps: transfert de données...

‣ niveau de sécurité, conséquences d’une erreur, informations vitales,


détection d’erreur, recouvrement après erreur

‣ caractéristiques techniques nécessaires : CPU, espae disque et mémoire

‣ développements futurs, changement d’OS, d’interface à prévoir


SPÉCIFICATION DES BESOINS(CONT.)
Qualité de l’expression des besoins

‣ besoins écrits dans le langage de l’utilisateur ? Qu’en pense l’utilisateur ?

‣ besoins mutuellement (in)consistants ?

‣ compromis spécifiés ? (p.ex. robustesse, correction)

‣ niveau de détail des besoins ?

‣ besoins suffisamment bien décrits pour être livrés à un tiers

‣ besoins vérifiables (test) ?

‣ spécification des modifications probables des besoins


SPÉCIFICATION DES BESOINS(CONT.)
Complétude des besoins

‣ si un besoin n’est pas encore totalement connu, est-ce spécifié ?

‣ un produit vérifiant tous les besoins (et que les besoins) sera-t-il acceptable ?

‣ n’y a-t-il pas des “besoins de complaisance” ? des besoins irréalisables ?


ANALYSE ET FORMALISATION DES BESOINS AU SEIN DU PROJET
Contexte et projet
• Présentation du contexte
• Décrire le contenu du projet
Architecture fonctionnelle
• Représenter l’intégration de l’application dans le système existant
• Identifier les flux externes de façon exhaustive
• Identifier et lister la totalité des fonctions attendues
• Décrire de façon détaillée chaque fonction :
• définition et objectif
• description fonctionnelle : traitements, enchaînements, règles de gestion, contrôles sur les données
• Reprise de l’existant
• Décrire de façon détaillée les principes de reprise
• Indiquer le scénario de reprise
Les flux
• Schéma général des flux
• Représenter la totalité des flux externes et internes, exprimés en entrée/sortie
Identification des Partenaires

acteurs externes Clients

ANALYSE ET Répartition Production

FORMALISATION DES géographique Ventes

BESOINS
Liste des différents
Fonctions
profils de chaque Habilitations
acteur concerné

Fonctionnel
Contraintes Technique
identifiées dans les Réglementaire
Organisationnel
domaines suivants : …
CAS PRATIQUE
EXEMPLE DE MISE EN APPLICATION
Contexte du projet
• Vous êtes une entreprise de fabrication de vêtements de sport, ayant un site
de prod. et magasin d'usine
• L'entreprise compte 60 personnes, ayant un site de production et un magasin
d'usine (Nouveau site)
• Dernière modification du site vitrine réalisée il y a plus de 2 ans
• Information du Système d'Information interne :
• Catalogue produits (~ 80 000 articles)
• Tarification par famille de pdts (5)/ remise/famille/client ou / article
• 10 000 comptes client avec un besoin de vendre en ligne
• Relation B commerciale en BtoB (Relation difficile avec les revendeurs)
• Parc informatique géré en interne (système AS400)
• Informaticien dédié à l'ensemble des tâches (intéressé par les nouvelles
technologies Web)
Questions
• Que pouvez vous déduire du contexte et besoins exprimés par ce client ?
• Quels sont les services que vous pourriez proposer ?
• Quelles sont les difficultés de ce type de projet ?
• Quelle stratégie prendriez vous pour faire ce projet et éviter les
dépassements de temps et d’argent ?
ARCHITECTURE
• Organisation du programme, aperçu de l’architecture, avec justification

• Blocs principaux définis, avec tâches, et interfaces

• Modules critiques décrits et justifiés

• Description de l’organisation des données (et BD), avec justification

Description de l’interface utilisateur

• Description de l’estimation de l’utilisation des ressources rares (threads,


connexions BD, réseau...)

• Besoin en termes de sécurité


ARCHITECTURE (CONT.)
Estimation budget et délais pour chaque module

Passage à l’échelle

Internationalisation

Étude de faisabilité technique

Réutilisation de code Architecture évolutive


LESCLASSIQUES...

• Cascade

• V

• Spirale
...ET LES PLUS RÉCENTES
• XP

• Scrum
CASCADE
Waterfall

Requirements
definition

software design
acteurs: client, analyste, chef de
projet
Implementation

system testing

Operation and
maintenance
CASCADE(CONT.)
Modèle orienté plan

Linéaire

‣ succession d’étapes

Une étape doit être achevée avant de pouvoir passer à la

suivante Pas de changement possible une fois que le

processus est lancé


CASCADE(CONT.)
Modèle adapté lorsqu’il y a plusieurs sites de développement
‣ tous les sites se coordonnent grâce au plan de développement

Difficulté pour répondre à des changements de spécifications


‣ modèle adapté lorsqu’il y a peu de changements au niveau des spécifications

‣ …mais il y a très souvent des changements !

Projet monolithique
‣ produit global livré en une seule fois Phase d’intégration souvent problématique !

‣ Phase de développement sans les utilisateurs


MODÈLE ENV

Analyse besoins Recette

Spécification Validation

Conception
Intégration
architectural
e
Conception
détaillée Test unitaire

Programmation
MODÈLE ENV (CONT.)
Ne pas voir ce modèle comme un cycle de vie

‣ par exemple, test ko Test unitaire

• retour en arrière ?
Programmation
• pendant le test, on code ?

Mais plutôt comme les dépendances entre les disciplines du développement

‣ les activités à gauche génèrent des entrées pour les activités à droite

Conception
Test unitaire
détaillée
MODÈLE ENV (CONT.)

Analyse besoins Recette

Spécification Validation

Conception
Intégration
architectural
e
Conception
Test unitaire
détaillée

Programmation
SPIRALE
Le processus de développement est représenté grâce à une spirale

‣ plus de problème lié à la séquence (par ex. backtracking)

‣ Chaque étape de la spirale représente une étape du processus

Pas d’étapes prédéfinies (e.g. spécification, conception): les itérations de la


spirale sont choisies en fonction de ce dont on a besoin

Prise en compte explicite des risques, et résolution au cours du processus


SPIRALE (CONT.)

Determine objectives,

1 2
Evaluate alternatives,
alternatives and
identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
analysis Proto-
REVIEW type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Unit test
Integration Design
V&V Integration
and test plan
Plan next phase test
Acceptance

4 3
test Develop, verify
Service
next-level product
SPIRALE (CONT.)
Modèle itératif et évolutif

Permet très tôt des retours sur :

‣ les modifications des


spécifications
‣ l’adéquation entre la spécification, la conception et
l’implantation
‣ l’acceptation par le
client
‣ les domaines à risque potentiel (performances du réseau par
exemple)
‣ la validité de la planification du
projet
PROTOTYPAGE
Un prototype est une version initiale d’un système destinée à démontrer
des concepts et à tester des options

Un prototype peut être utilisé lors:

‣ de la phase de spécification des besoins (explication,


vérification)
‣ de la phase liée à la conception de l’interface
utilisateur
‣ de la phase de
tests
BÉNÉFICES DUPROTOTYPAGE
Utilisabilité du système améliorée

Plus proche des besoins de

l’utilisateur Qualité de la conception

améliorée Maintenabilité améliorée

Effort de développement réduit

Establish Define
Develop Evaluate
prototype prototype
prototype prototype
objectives functionality

Prototyping Outline Executable Evaluation


plan definition prototype report
MDA (Model Driven Architecture)
POINT DE DÉPART: CONSTAT
D’ÉCHEC !
MDA (CONT.)
L’architecture a une influence sur
l’implantation

‣ e.g. MVC

Solution imaginée en 2000


‣ utiliser des modèles pour monter en abstraction et faciliter la

communication métiers / IT

‣ séparer les aspects techniques et


fonctionnels
‣ avoir une démarche basée sur les standards
UML
MDA (CONT.)

Démarche

Computation Independent Model


Présente ce que le système doit faire

Platform Independent Model


Ensemble de services permettant
L’extraction des données techniques
Platform Specific Model
Spécificité du PIM + détails nécessaires
! Sur utilisation du système sur une
Plateforme donné
QUELQUE SOIT LAMÉTHODE…
Cela n’évite pas de penser aux bonnes pratiques d'ingénierie :

‣ svn/Git

‣ build automatique et reproductible

‣ intégration continue

‣ tests automatisés

‣ métriques
MÉTHODES AGILES

eXtreme Programming

Si vous voulez

‣ plus de ‣ moins de
logiciel personnes
‣ de qualité ‣ moins de
supérieure gestion
‣ avec des délais ‣ moins de
réduits complexité
‣ pour des budgets ‣ moins d’outils
moindres
‣ avec plus de ‣ engagement des
certitude développeurs
XP

CYCLE DE DÉVELOPPEMENT

Petites releases

Métaphore

Conception

simple Test

Refactoring
Stats. 2018

Pair programming
XP(CONT.)
Propriété collective

Intégration

continue

40h/semaine

Client sur site

Standard de

codage
IDENTIFIER LES FLUX D'INFORMATIONS

 Objectifs
 Identifier les points clés du projet,
 Lever les difficultés ou problèmes techniques,
 Accompagner le client dans la compréhension du
futur système
IDENTIFIER LES PROCESSUS
MAQUETTES FONCTIONNELLES

Objectifs Exigences

• Permettre au client de • Temps de conception


se projeter dans le • Approche fortement
projet, ergonomique,
• Comprendre le • Contraintes techniques
raisonnement appliqué, et technologiques à ne
• Aide à la validation pas minimiser
et/ou la conception • Démonstration par
d'un CDC l'exemple
LES OUTILS : TRELLO ET WEKAN
LES OUTILS : SLACK ET MATTERMOST
LES OUTILS : REDMINE

Vous aimerez peut-être aussi