Génie Logiciel - Gérer le cycle de vie d'une application

Gérer le cycle de vie
d’une application
12018 - schneider.julien@gmail.com GÉNIE LOGICIEL - GÉRER LE CYCLE DE VIE D'UNE APPLICATION

Mener un projet
FAISABILITE MISE EN OEUVRE CLOTUREEMERGENCE GO
NO GO
GO
NO GO
GO
NO GO
GO
NO GO
Arbitrage d’un projet : allocation d’une enveloppe
Recueil du besoin & Etude d’architecture
Par application :
• Planning
• Spécification
• Développement
• Test
• Déploiement
Bilan et clôture du projet.
Validation du budget et planning
2018 - schneider.julien@gmail.com GÉNIE LOGICIEL - GÉRER LE CYCLE DE VIE D'UNE APPLICATION 2

PLAN
DEV
DEPLOY
TEST
SPEC
Utilisateurs
Projet Projet Projet
UtilisateursUtilisateurs
Version de l’application

Application ?
◦ Peut être une librairie : non déployable.
◦ Possède :
◦ Du code: souvent plusieurs langages.
◦ Des structures de données : SQL ou pas.
◦ Des données de base :
◦ fichiers statiques (CSS, images, PDF, …).
◦ Paramètres
◦ Inclut (souvent) des librairies.
◦ Peut-être installée sur :
◦ Un serveurs d’application : tomcat, jboss, weblogic, …
◦ Sur une machine :
◦ Virtuelle ou physique.
◦ Via des containeurs (docker).
◦ Sur le filesystem directement.
◦ Communique avec d’autres applications :
◦ Dans le même système d’information.
◦ A l’extérieur de son système d’information.

d’une application
D I F F É R E N T S C Y C L E S D E V I E
P L A N I F I E R
S P É C I F I E R
D É V E L O P P E R
T E S T E R
D É P L O Y E R

d’une application
P L A N I F I E R
S P É C I F I E R
T E S T E R
D É P L O Y E R

Différents cycles de vie
La littérature distingue de nombreux cycles de vie:
◦ Issus de l’industrie hors informatique : prédictifs
◦ Cascade
◦ V
◦ …
◦ Issus de industrie de l’informatique :
◦ Itératifs et incrémentaux
◦ Spirale
◦ Unified Process (UP) :
◦ RUP
◦ 2TUP
◦ …
◦ Agile (itératifs et incrémentaux et adaptatifs)
◦ Rapid Application Développent
◦ SCRUM
◦ Extreme programming
7
([AGILE_MANIF])

Cascade
Sa raison d’être : les conséquences
d'une modification en amont du cycle
ont un impact majeur sur les coûts
en aval.
Exemples : BTP, industrie, …
Les étapes ont les caractéristiques
suivantes :
• Livrables définis au préalable ;
• se terminent à une date précise ;
• ne se terminent que lorsque les
livrables sont jugés satisfaisants
par les producteurs de l’étape
suivante => Retour arrière
impossible à moins de
recommencer dès le début.
8
Exigences
Conception
Développement
Test
Déploiement

V
(Améliore le modèle en cascade)
Met en évidence des phases en vis-à-vis
:
en cas d'anomalie, le retour ne se fait
pas au début du cycle
Mets en évidence la préparation dans
les étapes descendantes des étapes
montantes.
Permet une répartition contractualisée
des responsabilités au dessous ou au
dessous d’une ligne horizontale.
Utilisation historique dans le cadre
d’un développement au forfait :
obligation de résultat.

Rational Unified Process
C’est la méthode préconisée par les
principaux auteurs d’UML :
• Guidé par les cas d’utilisation et
leur description
• Centré sur l’architecture logiciel :
production de diagrammes uml
complémentaires (classe,
séquence, composant,
déploiement)
• Itératif & Incrémental
Utilisée sans le dire dans de
nombreuses méthodologies.
Différences avec les méthodes agiles :
 Le logiciel est livré à la fin de
l’ensemble des itérations

SCRUM
• Fortement ritualisé et
codifié : vocabulaires,
rôles, cérémonies.
• Itératif, incrémental et
adaptatif.
• L’application est livrée et
évaluée par les
utilisateurs ou leurs
représentants à la fin de
chaque sprint.

Différences philosophiques
Prédictif
◦ Des livrables papiers sont produits à chaque étape et englobent l’ensemble des éléments de la
backlog de la version.
◦ Le gros risque est l’effet tunnel : obsolescence de l’application au moment de son déploiement.
Itératif et incrémental
◦ Chaque élément de la backlog (use case dans les méthodes Up & héritières) est traité
indépendamment.
◦ Moins d’effet tunnel mais l’application est mise en place à la fin des itérations.
Agile
◦ Chaque élément de la backlog est traité indépendamment.
◦ L’application est livrée très régulièrement et éprouvée par les utilisateurs ou leurs représentants.
◦ Repose sur la capacité humaine et technologique à livrer le logiciel rapidement et à s’adapter
continuellement.

Rythmes
Tous ces cycles partagent les mêmes étapes :
◦ Planifier
◦ Spécifier
◦ Développer
◦ Tester
◦ Déployer
Ils diffèrent sur :
◦ Le rythme de livraison de l’application.
◦ Les formalismes à utiliser.
◦ La maîtrise des coûts / délais / périmètres.
13
PLAN
DEV
DEPLOY
TEST
SPEC

Rythmes
14
DEV DEPLOYPLAN TESTSPEC
Prédictif
Itératif et incrémental
Agile

Coût / Calendrier / Périmètre

Le cas « Agile »
Ne pas confondre agilité dans le cadre de développement (SCRUM par
exemple) et l’agilité dans le cadre des projets.
« L’humain avant les processus et outils » ≠ ne rien formaliser !
Pas de document de référence = pertes de temps
Il faut maintenir à jour à minima :
◦ Diagramme de cas d’utilisation UML
◦ Diagramme de classe UML
◦ Wiki
 Pouvoir intégrer facilement quelqu’un dans l’équipe.

https://jeembee.wordpress.com/

d’une application
P L A N I F I E R
S P É C I F I E R
T E S T E R
D É P L O Y E R

Planifier
La roadmap de l’application

Planifier
La roadmap de l’application
La roadmap :
◦ C’est le planning des versions de l’application : date et contenu.
◦ Doit être connue par l’ensemble des parties prenantes de l’application.
◦ Peut être déterminée quand sont connus :
◦ L’effort nécessaire à la réalisation de chaque demande.
◦ L’ordonnancement de la backlog.
◦ la capacité de production de l’équipe (jour-homme ou story point).
◦ Nommage des versions :
◦ Les noms des versions de l’application doivent parler à toutes les parties prenantes :
◦ Androïd Nougat
◦ Ubuntu 17.04

Planifier
Les backlogs
Backlog de l’application : c’est l’ensemble des choses à faire sur
l’application.
 Evolue beaucoup
Backlog de la version : c’est l’ensemble des choses à faire sur
une version d’application.
 Doit évoluer le moins possible. Risque : des sprints qui se
contredisent.
Backlog du sprint : c’est l’ensemble des choses à faire sur un
sprint.
◦ Rien ne doit y être rajouté ou enlevé.

Planifier
Les backlogs
Qui ?
De nombreux acteurs sont parties prenantes de la vie d’une
application :
◦ Des personnes dans l’équipe responsable de l’application : responsable
d’application, product owner, concepteur, expert fonctionnel, développeur,
testeur, support, exploitant, utilisateur …
◦ Des personnes au niveau entreprise : business analyst, chef de projet,
architecte, …

Planifier
Les backlogs
Quoi ?
Type de demandes dans la backlog :
◦ Nouvelle fonctionnalité
◦ Amélioration
◦ Correctif
◦ Réusinage de code
◦ Documentation
24
Pour les utilisateurs ou leurs représentants
Pour l’équipe responsable de l’application

Planifier
Gérer les backlogs
Où ?
Quel outillage pour gérer les backlog ?
◦ Kanban post’it
◦ Logiciel :
◦ Tableur
◦ En ligne : Trello, Taiga, …
◦ Intégrés avec les outils de développement :
◦ Open source :
◦ Mantis (php)
◦ Bugzilla (php)
◦ Redmine (ruby)
◦ Gitlab CE
◦ …
◦ Propriétaire :
◦ JIRA (java)
◦ Gitlab EE
◦ …
25
[KANBAN]
[BT_WIKI]

Planifier
La backlog d’une application
Comment ?
La backlog d’application doit être :
◦ Cultivée. La backlog d’application évolue dans le temps, il faudra la mettre à jour.
◦ Nettoyée. Les demandes qui ne seront jamais traitées doivent-être annulée : les rouvrir plus tard
ou ouvrir de nouvelles demandes similaires.
◦ Partagée. Pour favoriser le travail collaboratif, l’accès aux données doit-être facile et transparent.
◦ Intégrée. Il faut veiller à l’intégration avec le reste des outils :
◦ Gestionnaire de Configuration Logiciel
◦ Plateforme d’Intégration Continue
◦ Gestionnaire de tests
◦ Gestionnaire de changement
A éviter :
◦ Ne pas avoir de backlog.
◦ Avoir plusieurs backlog de l’application.
◦ Confondre la backlog de l’application avec la backlog de version ou de sprint.

Planifier
La backlog d’une application
Demande
de
Projet
Plateforme d’Intégration Continue
Tests
unitaires
Construction
paquetage
Construction
rapports qualité
Environnements
DEV DEPLOYPLAN TESTSPEC
backlog
Mise en production
(version)

Planifier
Ordonnancer une backlog
Pourquoi ?
◦ Pour pouvoir construire une backlog « fille ».
Ex : Pour être capable de définir une backlog de version ou de sprint, il faut que la
backlog de l’application soit ordonnancée.
◦ Pour savoir quoi mettre en œuvre en premier.
Ex : En tant que développeur, quelle est ma prochaine tâche ?
Comment ?
◦ Chaque demande doit être priorisée par rapport à une autre demande, ceci dans la limite
du possible.
◦ Les valeurs et les coûts des demandes doivent être mis en relation de façon formelle.
Attention :
◦ Le but n’est pas d’avoir un devis mais une idée de ce qu’on a envie de faire en premier.
Il ne faut pas transformer l’exercice en chiffrage précis.
◦ Il faut arriver à vite porter l’attention sur les éléments les plus important de la backlog
pour raffiner si besoin l’ordonnancement.

Planifier
Présentation d’UML
◦ Diagrammes de cas d’utilisation et exercices associés

Planifier

Planifier
Différentes techniques d’ordonnancement :
◦ Discussion ouverte :
◦ On arrive à ordonnancer… ou pas
◦ Difficile d’aller au-delà de priorité basse, moyenne, haute
◦ Assez subjectif
◦ Estimation de l’apport métier d’une demande
◦ Nécessité technique  pas de discussion possible ;)
La priorisation d’une demande dépend de deux variables :
◦ La valeur que va apporter une demande à l’entreprise.
◦ L’effort que va devoir fournir l’entreprise pour l’implémenter.

Planifier
Estimer l’effort de mise en œuvre
Techniques basées sur la comparaison et l’expérience :
◦ Méthode Delphi : questionnement anonyme et itératif d’un pôle d’experts sur
des sujets précis.
◦ Abaque (souvent dans le cadre d’un contrat de maintenance, ou de
développement forfaitisé) : s’appuie sur une liste de cas d’utilisation par
exemple.
Techniques basées sur des formules de calcul
◦ Points de fonction
◦ 5 types de points de fonction représentant les différentes problématiques de mise en œuvre
informatique
◦ CoCoMo
◦ à partir de la quantité de ligne de code à produire
 Objectif : avoir un nombre de jH

Planifier
33
jH vs Story Point

Planifier
Planning poker :
◦ plusieurs tours de chiffrage, le plus haut et le plus bas se justifient à chaque
fois. (utilisation d’un développement déjà réalisé comme base de
comparaison)
◦ Valeurs de carte s’inspirant de la « suite de Fibonacci » : 1 2 3 5 8 13 20 40
100…
Nécessaire pour :
◦ Suivre l’avancement : burndown chart.
◦ Déterminer la vélocité (ou capacité) d’une équipe dans la méthode SCRUM à
la fin d’un sprint et mieux planifier le prochain sprint
 Objectif : avoir un story point sur chaque item de la backlog.
34
[BC_WIKI]

Planifier
◦ WSJF = Weighted Shortest Job First
◦ C'est une technique d’ordonnancement qui vise à prioriser en premier les éléments ayant un rapport
valeurs / effort le plus élevé.
◦ Ligne = chaque item de la backlog
◦ Colonnes =
◦ Valeur métier
◦ Criticité temporelle
◦ Réduction risque ou apporteur opportunité
◦ Effort (story point)
◦ Colonne par colonne, mettre 1 pour la demande la plus basse et déterminer la valeur des autres lignes
par comparaison.
◦ Valeur possible : 1 2 3 5 8 13 20
35
𝑊𝑆𝐽𝐹 =
𝑉𝑎𝑙𝑒𝑢𝑟 + 𝐶𝑟𝑖𝑡𝑖𝑐𝑖𝑡é 𝑡𝑒𝑚𝑝𝑜𝑟𝑒𝑙𝑙𝑒 + 𝑟é𝑑𝑢𝑐𝑡𝑖𝑜𝑛 𝑟𝑖𝑠𝑞𝑢𝑒 𝑜𝑢 𝑎𝑝𝑝𝑜𝑟𝑡𝑒𝑢𝑟 𝑑′
𝑜𝑝𝑝𝑜𝑟𝑡𝑢𝑛𝑖𝑡é
𝐸𝑓𝑓𝑜𝑟𝑡 𝑟𝑒𝑠𝑡𝑒 à 𝑓𝑎𝑖𝑟𝑒
=
𝑉𝑎𝑙𝑒𝑢𝑟 + 𝐶𝑇 + 𝑅𝑅. 𝐴𝑂
𝐸𝑓𝑓𝑜𝑟𝑡
[SAFE]

Planifier
Mise en situation :
◦ Priorisation d’une backlog d’application avec la technique WSJF
Nouveau
Externe
Non modifié
Légende
DDV-CAS-01
Rechercher un
produit
<<extend>> DDV-CAS-02
Consulter la fiche
d'un produit
<<extend>>
<<extend>>
DDV-CAS-03
Ajouter un produit
au panier
DDV-CAS-04 Editer le
contenu du panier
<<extend>>
DDV-CAS-05
Confirmer la
commande
Client
DDV-CAS-00 Accéder à
Doudou Ville
<<extend>>
Régler la
commande en
ligne
<<include>>
Préparateur de commande
DDV-CAS-07 Préparer
une expédition
DDV-CAS-08 Réaliser une
expédition
Responsable préparateur
DDV-CAS-09 Valider une
expédition importante
DDV-CAS-10 Lister les
commandes à
préparer
<<extend>>
DDV-CAS-11 Lister les
expédition à expédier
<<extend>>
Administrateur
DDV-CAS-06 Annuler
tout ou partie d'une
commande
Mettre à jour le
catalogue
Exemple de diagramme de cas d’utilisation - Site web « Doudou Ville »2018 - schneider.julien@gmail.com GÉNIE LOGICIEL - GÉRER LE CYCLE DE VIE D'UNE APPLICATION 36

d’une application
P L A N I F I E R
S P É C I F I E R
T E S T E R
D É P L O Y E R

Spécifier
Spécifier : « Indiquer quelque chose avec toutes les précisions
nécessaires pour qu'aucune équivoque ne subsiste ». Larousse
Grand débat « éternel » entre :
◦ Les adeptes de la rigueur : formalisme, document exhaustif, …
◦ Les adeptes des relations humaines : la discussion.

Spécifier
Spécifier le comportement de l’application
Plus le cycle de vie de l’application est agile, plus le découpage doit être fin pour permettre
l’agilité.
◦ Prédictif. On parle alors d’un livrable de « Spécification Fonctionnelle »
L’ensemble des cas d’utilisation sont spécifiés.
◦ Itératif et incrémental :
Chaque cas d’utilisation est décrit et développé indépendamment.
◦ Agile :
 Par cas d’utilisation, puis par user story.
Le découpage est le plus fin possible pour pouvoir :
◦ Faire tenir les tâches sur un sprint
◦ Avoir un suivi du « burndown cart » réaliste : pouvoir réagir rapidement sur des dérives.

Spécifier
Comportement : décrire un cas d’utilisation
Définir le(s) cas d’utilisation (raffiner si besoin) :
◦ Diagramme de cas d’utilisation : acteurs UML & cas d'utilisation.
Décrire chaque cas d’utilisation :
◦ Un tableau pour résumer le cas d’utilisation.
◦ Un diagramme d’activité annoté.
◦ IHM du système : maquettes dynamiques ou pas.
◦ (Chaque scénario en détail = préparation de la partie test)

Spécifier
Exemple : le DAB Oney - Diagramme de cas d’utilisation
Client
Client Oney
Transporteur de billets
Technicien
Retirer de
l'argent au
comptant
Retirer de
l'argent à crédit Réaliser la
maintenance
Ajouter des
billets
Retirer les
cartes
avalées
Saisir le code PIN
de la carte
<<include>>
<<include>>

Spécifier
Exemple : le DAB Oney : spécification du cas d’utilisation du cas d’utilisation « Retirer de l’argent
au comptant ».
42
Description Dans ce cas d’utilisation, le système permet à l’utilisateur de retirer de l’argent au comptant : choix ticket ou pas,
choix du montant de transaction.
Le système vérifie l’identité du porteur de carte et la disponibilité des fonds.
Déclencheur(s) du
cas d’utilisation
Ce cas est exécuté lorsque l’acteur insère sa carte bancaire dans le DAB et veut réaliser un retrait au comptant.
Pré-conditions Le DAB est en état « en attente ».
Post-conditions Scénario nominal :
Le client a pris le montant d’argent désiré.
Le client a repris sa CB.
Scénario alternatif « Erreur de saisie fatale »:
La CB du client a été avalée par le DAB.
Scénario alternatif « Retrait non autorisé »:
Le client a repris sa CB.
Dans tous les cas :
Le DAB est en état « en attente »
Tableau pour résumer le cas d’utilisation2018 - schneider.julien@gmail.com GÉNIE LOGICIEL - GÉRER LE CYCLE DE VIE D'UNE APPLICATION

Client Système
Insérer la carte bancaire
dans le DAB
Choisir de faire un retrait
d'argent au comptant
Saisir le code PIN de la
carte bancaire
Prendre les billets
Vérifier le code PIN saisi
Libérer la carte bancaire
Récupérer la carte
bancaire
Libérer les billets
Choisir la montant de
retrait
Proposer les montants de retrait possibles
Vérifier le montant demandé
Déterminer si nouvel essai autorisé
[ Code KO ] [ Code OK ]
[ Montant OK ] [ Montant KO ]
Afficher le menu
Demander la saisie du code PIN
Afficher l'écran d'attente
Diagramme d’activité pour
décrire le déroulé du cas
d’utilisation « Retirer de
l’argent au comptant ».

Spécifier
Présentation d’UML
◦ Diagrammes d’activités et exercices associés

Spécifier
Comportement : décrire des user story
Définir le(s) user story :
◦ Libellé :
En tant que « Acteur », je dois pouvoir « action » afin de « objectif à atteindre ».
Ex : En tant que « Client », je dois pouvoir cliquer sur un bouton dans le panier afin de le supprimer.
◦ Description :
◦ Scenario détaillé pour être capable de tester l’implémentation.
1. Ajouter un article au panier.
2. Aller dans le panier.
3. Appuyer sur l’icone de suppression de l’article.
4. L’article est supprimé du panier.
5. L’article est mis dans les articles récemment supprimés du panier.
◦ IHM du système : maquettes dynamiques ou pas.
Une User Story se rapproche d’un scenario de cas d’utilisation.
45
[US_WIKI]

Spécifier
Spécifier les données de l’application
L’équipe responsable de l’application doit avoir une vision partagée des données :
◦ Manipulées par l’application.
◦ Sous la responsabilité de l’application.

Spécifier
Données
Présentation d’UML :
◦ Diagrammes de classes
◦ Diagrammes d’état

d’une application
P L A N I F I E R
S P É C I F I E R
T E S T E R
D É P L O Y E R

Développer
1. Organiser le code source
2. Produire le code source
3. Faire relire le code
4. Publier le code source
5. Construire le binaire

Développer
Organiser le code source
Il faut pouvoir distinguer le code source qui permet de :
◦ Accéder au données : couche donnée
◦ Effectuer les traitements des données : couche service.
◦ Piloter les traitements ci-dessus : couche contrôleur.
◦ Afficher les résultats aux utilisateurs : couche UI ou IHM.
◦ …
Pour cela il ne faut pas hésiter à multiplier les paquetages / dossiers.
Si le code n’est pas organisé sa maintenance sera très compliquée.

Développer
Produire le code source
Traçabilité
◦ Il est nécessaire de faire référence à une et une seule demande de la backlog lors du
développement.
Test unitaire / test automatisé
◦ Il est attendu des développeurs modernes d’automatiser les tests unitaires ou d’intégration.
Commentaire
◦ Chaque méthode doit être commenté.
◦ L’intérieur d’une méthode n’a normalement pas besoin d’être commenté sauf si elle dépasse
15 lignes de code (chiffre arbitraire et discutable).
Respect des normes et conventions
◦ Chaque langage a ses normes et ses conventions.
◦ Exemple en java :
◦ Nom de classe commence par une majuscule.
◦ Nom de méthode comme par une minuscule.
◦ …

Développer
Faire relire le code source
La relecture de code est bonne pratique ancestrale 
Elle est même devenue obligatoire au travers d’outils comme Gitlab.
Pourquoi c’est important
◦ Cette relecture renforce l’esprit d’équipe et le passage de compétence, ceci
avec des cas concrets qui complète la documentation.
◦ La difficulté de compréhension du code n’est pas quand on le produit, mais
quand on essaye de le modifier. Il est impossible pour le développeur de
regarder son propre code avec un œil externe : il n’est pas objectif.
 Seul un autre développeur peut se mettre en situation d’appréhender le
code source produit.

Logiciel de GCL (Gestion de Configuration Logiciel)
SVN (Centralisé) vs Git (Distribué)
Développer
Publier du code source - GCL

Développer
Tous les fichiers qui sont utilisés par l’application doivent être mis en gestion
de configuration :
◦ Code source
◦ SQL
◦ Fichier de paramétrage
◦ …
Opérations
◦ Commit
◦ Push / pull (git)
◦ Branch
◦ Tag
◦ …
Livraison de l’application
Un tag doit être effectué sur le logiciel de gestion de configuration logiciel.

Source: RebelLabs Survey Report 2016 Source: Indeed
Développer
La popularité de Git a une croissance spectaculaire

Tag 1.0
Développer
Publier du code source – GCL
56
master
develop
Temps
Tag 0.1 Tag 0.2
commit
merge Les branches principales [BRANCHING]

Tag 1.0
Développer
57
[BRANCHING]
master
hotfixes
develop
Tag 0.1 Tag 0.2
Temps
Corrections urgentes
(hotfixes)

Tag 1.0
Développer
58
master
hotfixes
release
(plusieurs)
develop
Temps
Tag 0.1 Tag 0.2
Branche par version [BRANCHING]

Tag 1.0
Développer
59
master
hotfixes
release
(plusieurs)
develop
feature
(plusieurs)
Temps
Tag 0.1 Tag 0.2
[BRANCHING]
Branche par fonctionnalité (user story par ex)

Développer
Beaucoup de branches = de la complexité.
Comment gérer cette complexité ?
◦ Des normes, ex : toute demande de la backlog doit être implémentée dans
une branche « feature » puis mergé vers une branche principale.
◦ De la cohésion d’équipe : un schéma représentant les branches principales
doit être mis à jour.

Développer
Construire le binaire
Historiquement, la construction des applications se faisait
manuellement : sur le poste du développeur.
Pour accroitre la qualité des applications, ce sont des logiciels qui
réalisent ces tâches :
◦ Import des dépendances
◦ Exécution des tests automatisée
◦ Construction du paquetage exécutable
◦ Déploiement automatique
◦ Ex d’outil : Jenkins, Gitlab CI

Développer
Les composants d’une application contiennent différents
types d’objets :
◦ Interface Homme-Machine
◦ Contrôleur,
◦ Métier,
◦ Données.
Si le cas d’utilisation ou d’une user story fait intervenir
plusieurs applications ou composants…
 Il peut être utile de réaliser un diagramme de
séquence ou un diagramme de collaboration.

Développer
Présentation d’UML :
◦ Diagrammes de séquence

d’une application
P L A N I F I E R
S P É C I F I E R
T E S T E R
D É P L O Y E R

Tester
La phase de test sert à :
◦ Mettre au point la procédure de déploiement.
◦ Vérifier l’atteinte des attendus :
◦ Fonctionnels : Cas d’utilisation, user story, bug…
◦ Non-fonctionnels : performance, dimensionnement, …
◦ Alimenter la backlog de l’application avec les défauts constatés.
◦ Ils seront traités (ou pas).

Tester
Sans spécification, les tests :
◦ Ne sont pas possibles
◦ Ne servent à rien.
Tester est une discipline à part entière, de nombreuses bonnes
pratiques existent :
◦ Méthodes
◦ Outils

Tester
Vocabulaire :
◦ Campagne de test = un ensemble de « cas de test »
◦ Réalisée dans le cadre d’une version d’application.
◦ Les cas de tests déroulés dépendent des exigences portées par la version de l’application : on ne
teste pas pour le plaisir.
◦ Cas de test = un scénario hérité de la spécification = un ensemble de « pas
de test »
◦ pour rappel :
◦ Plusieurs scénarios par cas d’utilisation.
◦ Une user story = un scénario.
◦ Pas de test. (step)
◦ Etape d’un scénario : action + résultat attendu.

Tester
A partir des résultats de l’exécution des tests, il est possible d’établir la
couverture de test concernant la version de l’application : qualité par
rapport aux exigences portées par la version de l’application.
Les tests peuvent être automatisés, le code ainsi produit devient du
code à part entière de l’application :
◦ Ex : Selenium, gatling, …

d’une application
P L A N I F I E R
S P É C I F I E R
T E S T E R
D É P L O Y E R

Déployer
Le contenu d’une demande de déploiement d’une version d’application :
◦ Paquetages applicatif
◦ Script SQL : modification de la structure de données
◦ Fichiers statiques : images, pdf, …
◦ Fichiers de configuration à modifier.
+ où déposer tout ça.

Déployer
Le déploiement s’effectue en relation avec des équipes d’exploitation
qui ne sont pas forcément en proximité des équipes responsables
d’application.
« processus de gestion de changement »
DEVOPS : Fluidifier les relations entre les développeurs et les
opérations.
◦ Procédure de déploiement partagée voir même automatisée.
◦ Paquetage applicatif produit industriellement : confiance.
◦ Pas de paramétrage lié à l’environnement dans le code.

Génie Logiciel - Gérer le cycle de vie d'une application

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Génie Logiciel - Gérer le cycle de vie d'une application

Similaire à Génie Logiciel - Gérer le cycle de vie d'une application (20)

Génie Logiciel - Gérer le cycle de vie d'une application

Notes de l'éditeur