Dan Garlasu, dgarlasu@yahoo.

com

1
Ordre du Jour
1. Définitions
2. Ingénierie logicielle et paradigmes logiciels
3. Modèles de cycles de vie des logiciels
 Construire et réparer (Build & Fix)
 Cascade et cascade modifiée (Waterfall)
 Prototypage rapide (Rapid Prototyping)
 Spirale de Boehm (Bohem Spiral)
 Agile

2
  Paradigme
◦ catégorie d'entités partageant une caractéristique commune
◦ Exemples:
 Économie Internet vs ère industrielle
 Logiciel sous licence vs Open Source
 Licence d'utilisation perpétuelle vs SaaS (logiciel en tant que service)
Data Processing Paradigm

Paradigme : provient du mot grec paradeigma, à l'origine un terme scientifique

mais couramment utilisé aujourd'hui pour désigner une perception, une
hypothèse, une théorie, un cadre de référence ou une lentille à travers laquelle
vous voyez le monde. Le pouvoir d'un paradigme précis est qu'il explique et qu'il
guide.
Le paradigme de programmation est un modèle de la façon dont les
programmeurs communiquent un calcul aux ordinateurs;
Le paradigme de conception de logiciels (Software Design Paradigm) est un
modèle de mise en œuvre d'un groupe d'applications partageant des propriétés
communes.
Le paradigme de développement logiciel (Software Development Paradigm)
est souvent appelé génie logiciel, peut être considéré comme un modèle de
gestion pour la mise en œuvre de grands projets logiciels en utilisant les
meilleurs principes d'ingénierie. Ex : COTS (commercial on the shelf), ou Cloud,
etc.
Le paradigme de traitement de données c’est qu’on parle de plus en plus
aujourd’hui. On va discuter plus de ca la semaine prochaine dans l’heure
d’applications.

3
  Modèle pour une classe de langages de programmation partageant un ensemble de
caractéristiques communes
1. Langage de programmation
 système de signes utilisé pour communiquer une tâche/un algorithme à un ordinateur, provoquant
l'exécution de la tâche
2. Calcul
 La tâche à effectuer
3. Paradigme linguistique
 Principes généraux utilisés par un programmeur pour communiquer une tâche/un algorithme à un
ordinateur à l'aide de deux composants :
 Syntaxe - manière de spécifier ce qui est légal dans la structure de phrase de la langue
 Sémantique - signification d'un programme dans cette langue
 Quatre grands paradigmes de langage de programmation:
1. Impératif/procédural
2. Orienté objet
3. Logique
4. Fonctionnel

Généralement, un paradigme de programmation sélectionné définit les

principales propriétés d'un logiciel développé au moyen d'un langage de
programmation supportant le paradigme.
1. évolutivité/modifiabilité – expliquer l'évolutivité
2. intégrabilité/réutilisabilité
3. portabilité – expliquer la portabilité
4. performance
5. fiabilité - produit des résultats cohérents dans des conditions constantes
6. facilité de création

4
  incarne les résultats des idées des gens sur
◦ comment construire des programmes,
◦ les combiner dans de grands systèmes logiciels et
◦ des mécanismes formels sur la manière dont ces idées doivent être
exprimées
 Les phases suivantes sont impactées par le paradigme logiciel
sélectionné :
a. Modèles de conception
b. Composants
c. Architecture logicielle
d. Cadres

Ainsi, nous pouvons dire qu'un paradigme de conception logicielle est un modèle pour une classe de
problèmes qui partagent un ensemble de caractéristiques communes.
Il convient de noter en particulier qu'un paradigme de programmation particulier définit
essentiellement les paradigmes de conception de logiciels. Par exemple, on peut parler de modèles
de conception orientés objet, de composants procéduraux (modules), d'architecture logicielle
fonctionnelle, etc.

5
  solution éprouvée pour un problème de conception général
◦ Modèles architecturaux : expriment une organisation ou un schéma
structurel fondamental pour les systèmes logiciels. Fournir un ensemble de
sous-systèmes prédéfinis, spécifier leurs responsabilités et inclure des
règles et des directives pour organiser les relations entre eux.
◦ Modèles de conception : fournit un schéma pour affiner les sous-systèmes
ou les composants d'un système logiciel, ou les relations entre eux
◦ Idiomes: modèle de bas niveau spécifique à un langage de
programmation. Décrit comment implémenter des aspects particuliers des
composants ou les relations entre eux en utilisant les fonctionnalités du
langage donné

Elle consiste à communiquer des « objets » personnalisés pour résoudre le problème dans un
contexte particulier.
Les modèles ont leur origine dans la programmation orientée objet où ils ont commencé comme des
collections d'objets organisés pour résoudre un problème. Il n'y a pas de relation fondamentale entre
les motifs et les objets ; il se trouve qu'ils ont commencé là. Des modèles peuvent être apparus parce
que les objets semblent si élémentaires, mais les problèmes que nous essayions de résoudre avec
eux étaient si complexes.

6
  Les composants logiciels sont des unités binaires de production,
d'acquisition et de déploiement indépendants qui interagissent
pour former un programme fonctionnel
 Exemples de composants : "Fenêtre", "Bouton poussoir", "Editeur
de texte", etc.
 Problèmes liés aux informations sur l'interopérabilité:
◦ comment exprimer des informations d'interopérabilité (par exemple,
comment ajouter un « bouton poussoir » à une « fenêtre » ;
◦ comment publier ces informations (par exemple bibliothèque avec API
réutilisable via une instruction "include")

Un composant est une partie physique et remplaçable d'un système à qui il se conforme et fournit la
réalisation d'un ensemble d'interfaces ... représente généralement l'emballage physique d'éléments
autrement logiques, tels que des classes, des interfaces et des collaborations.

Un composant doit être compatible et interopérer avec toute une gamme d'autres composants.
Exemples de composants : "Fenêtre", "Bouton poussoir", "Editeur de texte", etc.
Deux problèmes principaux se posent en ce qui concerne les informations d'interopérabilité:
1. comment exprimer des informations d'interopérabilité (par exemple, comment ajouter un
« bouton poussoir » à une « fenêtre » ;
2. comment publier ces informations (par exemple bibliothèque avec API réutilisable via une
instruction « include »)

7
  L'architecture traite de la structure des composants de la
solution
 Une architecture définit les composants du système logiciel,
leur intégration et leur interopérabilité :

• L'intégration
• signifie que les pièces d’un système s'emboîtent bien

• L'interopérabilité
• signifie que plusieurs systèmes travaillent ensemble efficacement
pour produire une réponse

Une architecture logicielle particulière décompose un problème en petits morceaux et tente de trouver
une solution (composant) pour chaque morceau.
Il existe de nombreuses architectures logicielles. Choisir le bon peut être un problème difficile en soi.
Ex : client/serveur vs architecture sur 3 niveaux
Il est très important de faire la distinction entre intégration et interopérabilité!

8
  Mini-architecture réutilisable qui fournit la structure et le comportement
génériques d'une famille d'abstractions logicielles
 Les Cadres peuvent être vus comme un niveau intermédiaire entre les
composants et une architecture logicielle

 Exemple : Supposons qu'une architecture d'un système de traitement

texte sur le web (WBT) réutilise des composants tels que "l'objet
d'entrée d'édition de texte" et les "boutons poussoirs". Un cadre
logiciel peut définir un "éditeur HTML" qui peut être réutilisé pour
construire l'architecture

Exemple : Supposons qu'une architecture d'un système WBT réutilise

des composants tels que "l'objet d'entrée d'édition de texte" et les
"boutons poussoirs". Un cadre logiciel peut définir un "éditeur HTML"
qui peut être réutilisé pour construire l'architecture

9
 Des couches d'abstraction critiques se situent entre le programme d'application et le matériel
réel. L'application est écrite pour un modèle de programmation, qui dicte la manière dont les
éléments du programme partagent les informations et coordonnent leur abstraction, qui est la
frontière entre le programme utilisateur et l'implémentation du système. Cette abstraction est
réalisée par le support du compilateur ou de la bibliothèque en utilisant des primitives
disponibles à partir du matériel ou du système d'exploitation, qui utilise des primitives
matérielles privilégiées.

L'architecture informatique a deux facettes distinctes : l'une est la définition des

abstractions critiques, en particulier la frontière entre matériel et logiciel et la frontière
entre l’utilisateur et le système. L'autre facette est la structure organisationnelle qui
réalise ces abstractions pour fournir des performances élevées de manière rentable.
La couche supérieure est le modèle de programmation qui est la conceptualisation de
la machine que le programmeur utilise dans les applications de codage. Les
applications sont écrites dans un modèle de programmation. Dans le cas le plus
simple, le modèle consiste en la multiprogrammation d'un grand nombre de
programmes séquentiels indépendants. Un modèle de programmation est réalisé en
termes de primitives de communication au niveau de l'utilisateur du système appelé ici
l'abstraction de communication. En règle générale, le modèle de programmation est
intégré dans un langage ou un environnement de programmation, de sorte qu'un
mappage existe entre les constructions de langage génériques et les primitives
spécifiques du système. Ces primitives de niveau utilisateur peuvent être fournies
directement par le matériel, par le système d'exploitation ou par un logiciel utilisateur
spécifique à la machine qui mappe l'abstraction de communication sur les primitives
matérielles réelles.

10
  Génie logiciel - l'établissement et l'utilisation de principes d'ingénierie solides afin
d'obtenir de manière économique un logiciel fiable et fonctionnant efficacement sur de
vraies machines
 Emploie une variété de:
◦ Paradigmes - approches ou philosophies particulières pour la conception, la construction et la
maintenance de logiciels. Les phases suivantes sont fortement affectées par les paradigmes logiciels
sélectionnés :
 Conception
 Mise en œuvre
 L'intégration
 Maintenance
◦ Méthodes (techniques) - dépendaient fortement d'un paradigme sélectionné et peuvent être considérées
comme une procédure pour produire un résultat
◦ Outils - systèmes automatisés mettant en œuvre une méthode particulière
 Discuter la situation actuelle du développement logiciel

Situation actuelle du développement logiciel :

Les personnes qui développaient des systèmes se trompaient constamment dans leurs estimations du temps, des efforts et
des coûts
La fiabilité et la maintenabilité étaient difficiles à atteindre
Les systèmes livrés ne fonctionnaient souvent pas

La complexité et le manque de ressources ont créé une situation sans précédent dans l'industrie informatique :
2 500 milliards de dollars (environ 70 % du budget informatique mondial) sont investis de manière inefficace. En
conséquence, 1 projet sur 5 n'est pas développé et commercialisé.
• La correction de bogues dans les logiciels livrés a la tendance de produir plus de bogues
• Augmentation de la taille des systèmes logiciels
1. NASA
2. Initiative de défense StarWars
3. Administration de la sécurité sociale
4. Systèmes de transactions financières
• Changements dans le rapport entre les coûts matériels et logiciels
1. début des années 60 - 80% des coûts de matériel
2. milieu des années 60 - 40 à 50 % de coûts de logiciel
3. aujourd'hui - moins de 20 % de coûts matériels (!?)
• Rôle de plus en plus important de la maintenance
1. Correction des erreurs, modification, ajout d'options
2. Le coût est souvent le double de celui du développement du logiciel
• Progrès dans le matériel (coûts réduits)
• Progrès dans les techniques logicielles (par exemple, interaction avec l'utilisateur)
• Demandes accrues de logiciels
• Médecine, fabrication, divertissement, édition
• Demande de systèmes logiciels plus grands et plus complexes
• Avions (accidents), NASA (lancements échouées de navettes spatiales),

11
  Les entreprises font face à de nombreux défis lors de la mise en œuvre de nouvelles
technologies
 Certains inconvénients des systèmes d'information en fonction influent les modèles de
sélection
◦ Ne tiennent pas compte des interdépendances entre les critères et les projets candidats qui pourraient
réaliser des économies et des avantages précieux découlant de l'utilisation des TI/SI

PRE-IMPLEMENTATION POST-IMPLEMENTATION

Une mauvaise
planification et Adoption par
gestion du l’utilisateur
projet

TOP
CHALLENGES
Integration
avec Performance et
environment Disponibilité
des TI/SI
existent

La diapositive décrit les défis les plus importants auxquels les entreprises sont
confrontées lorsqu’elles veulent mettre en œuvre un projet. Avant de commencer
le projet, nous voyons une mauvaise planification du projet comme un obstacle
majeur à la réussite du projet. Le deuxième problème de pré-mise en œuvre est
la mauvaise intégration du nouveau projet avec l’infrastructure et les applications
TI/SI existantes. En supposant que ces défis aient été correctement abordés,
dans la phase post-implémentation, le plus souvent, les gestionnaires de projet
s’affrontent avec une résistance a l’adoption par l’utilisateur. Enfin, les
performances ultimes du système ainsi que la grande disponibilité sont des
facteurs qui peuvent contribuer au succès ou à l’échec du projet.

12
1. Implique les activités de production d'un système logiciel et comporte les phases suivantes:
2. Analyse des besoins et spécifications
3. Conception
◦ Conception préliminaire
◦ Conception détaillée
4. Mise en œuvre
◦ Implémentation des composants
◦ Intégration de composants
5. [Documentation du système]
6. Essai
◦ Tests unitaires
◦ Tests d'intégration
◦ Test du système
7. Déploiement
◦ Réception du projet pour d'installation et d'acceptation
8. Maintenance
◦ Rapport et correction de bogues
◦ Modification des exigences et mise à niveau du logiciel

13
Nous allons passer en revue les modèles suivants :
◦ Construire et réparer (Build & Fix)
◦ Cascade et cascade modifiée (Waterfall and Modified Waterfall)
◦ Prototypage rapide
◦ Spirale de Boehm
◦ Agile

14
 • OK pour les petits systèmes simples
• Le coût de ce modèle de processus est en fait bien supérieur au coût d'un projet
correctement spécifié et conçu.
• La maintenance peut également être problématique dans un système logiciel développé
selon ce scénario.

Cela fonctionne bien pour les petits systèmes simples, mais est totalement insatisfaisant pour les
systèmes logiciels de taille appreciable. Il a été démontré empiriquement que le coût de changement
d'un produit logiciel est relativement faible si le changement est effectué lors des phases de la
définition des exigences ou de conception, mais qu'il devient important lors des phases ultérieures.
Le coût de ce modèle de processus est en fait bien supérieur au coût d'un projet correctement
spécifié et conçu. La maintenance peut également être problématique dans un système logiciel
développé selon ce scénario.

15
 Le Modèle en Cascade Cascade Modifié

Le modèle en cascade est dérivé d'autres processus d'ingénierie en 1970. Offre un moyen de rendre
le processus de développement plus structuré. Exprime l'interaction entre les phases successives.
Chaque phase se transforme en cascade dans la phase suivante. Dans le modèle original en
cascade, une séquence stricte était au moins implicite. Cela signifiait qu'une phase devait être
achevée avant que la phase suivante ne commence.
Il ne prévoyait pas non plus de retour d'information entre les phases ni de mise à jour/redéfinition des
phases précédentes. Implique qu'il y a des pauses définies entre les phases, c'est-à-dire que chaque
phase a un début et une fin stricts et sans chevauchement et est effectuée de manière séquentielle.
Le point critique est qu'aucune phase n'est terminée tant que la documentation et/ou les autres
produits associés à cette phase ne sont pas terminés.

Le modèle de cascade modifié a été conçu pour assurer le chevauchement (superposition) et la

rétroaction entre les phases. Plutôt que d'être un simple modèle linéaire, il fallait que ce soit un
modèle itératif. Pour faciliter la réalisation des objectifs, des jalons et des tâches, il est normal de geler
des parties du développement après un certain point de l'itération. La vérification et la validation sont
ajoutées. La vérification vérifie que le système est correct (construire le système correctement). La
validation vérifie que le système répond aux souhaits des utilisateurs (construire le bon système).
Désavantages
Le modèle en cascade (et le modèle en cascade modifié) sont inflexibles dans le découpage du projet
en phases distinctes. Cependant, ils reflètent généralement la pratique de l'ingénierie.

16
 Le prototypage repose sur l'idée de développer une première implémentation pour
les retours des utilisateurs, puis d'affiner ce prototype à travers de nombreuses
versions jusqu'à ce qu'un système satisfaisant émerge.

• Programmation exploratoire - travaillez avec l'utilisateur pour explorer ses besoins et fournir un
système final.
• Prototypage jetable - L'objectif est de comprendre les exigences des utilisateurs et de développer
une meilleure définition des exigences pour le système

Le prototypage, aussi appelé développement évolutif, ou RAD (Rapid Application Development) vise à
améliorer la précision de la perception par le concepteur des besoins de l'utilisateur. Le prototypage repose sur
l'idée de développer une première implémentation pour les retours des utilisateurs, puis d'affiner ce prototype à
travers de nombreuses versions jusqu'à ce qu'un système satisfaisant émerge. Les activités de spécification, de
développement et de validation sont menées en parallèle avec un retour d'expérience rapide sur l'ensemble des
activités. Généralement, le prototypage se caractérise par l'utilisation de langages de très haut niveau, qui ne
seront probablement pas utilisés dans l'implémentation logicielle finale mais qui permettent un développement
rapide, et le développement d'un système avec moins de fonctionnalités par rapport aux attributs de qualité tels
que la robustesse, vitesse, etc... Le prototypage permet de clarifier les besoins des utilisateurs grâce,
notamment, au développement précoce de l'interface utilisateur. L'utilisateur peut alors essayer le système,
même s'il s'agit d'un (sous-)système de ce qui sera le produit final. Cela permet à l'utilisateur de fournir des
commentaires avant qu'un investissement important n'ait été fait dans le développement du mauvais système.
Des expériences de prototypage ont montré que cette approche prenait 40 % de temps en moins et entraînait
45 % de code en moins ; cependant, il produisait un code moins robuste et donc plus difficile à maintenir. La
documentation était souvent sacrifiée ou incomplète. Les attentes de calendrier des utilisateurs et des
gestionnaires avaient tendance à être irréalistes, en particulier en ce qui concerne les prototypes jetables.

Exemple: utilisez Oracle APEX pour le développement rapide d'applications afin de rendre vos données
rapidement et facilement disponibles via une application Web. • Créez de puissantes applications Web
multipages fonctionnelles en quelques minutes • Utilisez des rapports "interactifs" avancés prêts à l'emploi •
Intégrez les fonctionnalités javascript et AJAX avec des actions dynamiques construites par pointer-cliquer •
Créez facilement des graphiques et des diagrammes avec drill-to -fonctionnalités détaillées • Comprendre les
multiples outils en un d'APEX, y compris le développement complet SQL/PLSQL et les capacités
d'administration.

17
  Boehm a proposé un modèle en spirale où chaque tour de la spirale
a. identifie le sous-problème auquel est associé le risque le plus élevé
b. trouve une solution à ce problème

Le processus commence au centre de la spirale. Chaque cycle complété le long de la spirale

représente une étape du processus. Au fur et à mesure que la spirale se poursuit, le produit mûrit.
Dans la méthodologie de génie logiciel Boehm-Spiral, souvent citée et vue, le processus tourne d'une
étape à l'autre, chaque spirale se rapprochant de plus en plus d'une solution finale. Cependant, la
méthodologie de génie logiciel Boehm-Spiral progresse également régulièrement d'une étape à l'autre
avec une révision explicite entre chaque étape. Ainsi, le Boehm-Spiral est un hybride d'une
méthodologie d'ingénierie logicielle séquentielle et cyclique. Cependant, dans la pratique de
l'ingénierie, le terme spirale est utilisé comme nom générique pour toute méthodologie de génie
logiciel cyclique, y compris les cycles menant à des prototypes et à plusieurs
versions.http://infolab.stanford.edu/~burback/watersluice/node53.html

18
 3/3/2022

Le Manifeste Agile - un énoncé de

valeurs

Individus et
over Processus et outils
interactions
Documentation
Logiciel fonctionel over
complète

Collaboration client over Négociation de contrat

Répondre au
over Suivre un plan
changement
Source: www.agilemanifesto.org
Mountain Goat Software,
LLC

19

Exigences

Conception

Mise en oeuvre

Essai (Testing)

Déploiement

Entretien

20

1
 3/3/2022

Changements
Exigences

Conception

Mise en oeuvre
Prend trop longtemps
Essai (Testing) Ignoré

Déploiement

Redouté Entretien

21

Naturellement Chaos!

22

2
 3/3/2022

Accepter la réalité.

23

Alors, contrôler le chaos!

24

3
 3/3/2022

Alons contrôler le chaos.

25

Comment?

26

4
 3/3/2022

SCRUM (mêlée)

27

28

5
 3/3/2022

Une boîte légere à outils agiles

pour la gestion des projets.

29

Personnes
Choses
Comportements

30

6
 3/3/2022

Personnes
(Acteurs)

31

32

7
 3/3/2022

Propriétaire du produit
Scrum Master (Maitre de mêlé)
équipe Scrum

33

Choses

34

8
 3/3/2022

Les choses que nous voulons

faire.

35

Le Produit.

36

9
 3/3/2022

Le produit est décrit comme un

liste des fonctionnalités:
l'arriéré.

37

(L'arriéré)

38

10
 3/3/2022

Les caractéristiques sont

décrites dans le
termes d'histoires d'utilisateurs.

39

L'équipe Scrum estime le

travail associé à chaque histoire.

40

11
 3/3/2022

Les caractéristiques de l'arriéré

sont classés par ordre
d'importance.

41

Résultat: une liste de

classification pondérée des
caractéristiques du produit, une
feuille de route.

42

12
 3/3/2022

Le propriétaire du produit
détient
la liste des arriérés du produit.

43

Scrum (mêlée)
Personnages Choses
Propriétaire du produit Liste des Arierés
Scrum Master Histoires
équipe Scrum Estimations

44

13
 3/3/2022

Comportements

45

Changements
Exigences

Conception

Mise en oeuvre
Prend trop longtemps
Essai (Testing) Ignoré

Déploiement

Redouté Entretien

46

14
 3/3/2022

Exigences

Conception Entretien

Mise en oeuvre Déploiement

Essai (Testing)

47

48

15
 3/3/2022

Pourquoi itératif?

49

Le Prototype conduit au Produit

50

16
 3/3/2022

Retour (Feedback) rapide.

51

Réduction des risques.

52

17
 3/3/2022

Iterations = Sprints
2 - 4 semaines

53

54

18
 3/3/2022

Chaque Sprint a des objectifs

très Spécifique,
Mesurables, Réalisables dans
un intervalle bien définit de
Temps (SMART).

55

Sprints commencent par une

réunion de planification.
Sprints se terminent par une
rétrospective.

56

19
 3/3/2022

Lors de la réunion de
planification, on s’engage à une
quantité de travail.

57

Nous faisons des plans

sommaires
et les assignations.

58

20
 3/3/2022

59

60

21
 3/3/2022

61

62

22
 3/3/2022

Chaque jour, nous avons un

réunion quotidienne de mêlée
(SCRUM/Stand up).

63

1. Qu'avez-vous fait?
2. Il y a des obstacles?
3. Qu’allez vous faire jusqu’à demain?

64

23
 3/3/2022

Comportements

65

66

24
 3/3/2022

Sprint
• Réunion de planification
• Rétrospective
• Réunions quotidiennes

67

Pourquoi Scrum?

68

25
 3/3/2022

C'est simple.

69

Il est non opiniâtre.

70

26
 3/3/2022

Il prévoit des mesures claires.

71

Chaque histoire est estimée.

72

27
 3/3/2022

Au fil du temps, nous pouvons

améliorer les estimations et
remarquer des tendances

73

74

28
 3/3/2022

Maintient les membres de

l’équipe concentrés.

75

Maintient la flexibilité.

76

29
 3/3/2022

Comment on va commencer?

77

1. Personnes engagées (former les

mêlées).
2. Créez l’arriéré (backlog) du produit.
3. Démarrez a itérer.

78

30
 3/3/2022

Il peut prendre plusieurs

sprints avant que cela semble
naturel.

79

Ne restez pas coincé dans le

processus.

80

31
 3/3/2022

Ne restez pas coincé dans des

réunions.

81

Ne pas débattre l'arriéré.

82

32
 3/3/2022

Continuer à essayer.

83

84

33
 SPRINT pour le Processus d’Adoption Cloud

Sprints de deux Planification Coup d'envoi Reunion Retrospective

semaines : du Sprint du Sprint quotidien du Sprint

P R O G R ÈS DE L ' AD O PT I O N C L O U D
Les clients sont profilés par le Consultant Cloud
(étape d'adoption, cas d'utilisation sélectionné, industrie, rôle) en 4 compartiments :

Embarquement Sélection du
scénario d'utilisation Mise en œuvre Lancement de la
production …
Les compartiments et les tâches peuvent changer en fonction des priorités du sprint (décidées toutes les 2 semaines)

Ressources par compartiment: webinaire, e-mail, appel, autre

Prestation : CSC, conseil en vente, gestion des connaissances, adoption numérique

L'équipe CSC (Customer Success Consultants) est divisée en plusieurs équipes scrum, 6 à 8
consultants par équipe

Chaque sprint a un certain nombre de tâches, cela peut varier en fonction des priorités du sprint.

Ils exploitent une clientèle de 2000 comptes. Les clients sont profilés en 4 catégories (buckets) selon
le stade d'adoption du Cloud :
• Embarquement
• Utiliser la sélection de cas
• La mise en œuvre
• Production
Selon la catégorie, les consultants vont entreprendre diverses activités pour faire avancer le client
dans l'entonnoir d'adoption du cloud

85
 Lancement de
Embarquement Sélection du Mise en œuvre la production
(On Boarding) scénario d'utilisation (Go Live)
Implementation
1. Use Case Selection 1. 4th E-mailing campaign
1. On Boarding Brochure
Presentation (Congratulations)
2. On Boarding webinars (Users
2. Use Case selection webinars 2. Check / Discuss Renewal
and Roles, Identity Cloud 1. Implementation One to one Oppty with TSR and OLCSM
(service specific like VPN,
Service, Oracle Cloud webinars – delivered by CSC, (if applicable)
DB12c, etc)
Infrastructure) PreSales or KM 3. Hand-over Account to
3. One to one webinars –
3. One to one webinars 2. Eloqua 3nd E-mailing OLCSM
delivered by CSC, PreSales or
4. 1-st Email blast campaign campaign (Message 1,2,3, 4 – 4. Assist specific issues: Identity
KM
5. Contact Customer by Phone as needed) Domains; Data Center
1 on 1 4. 2nd E-mailing campaign relocation; Security, etc.
3. Check Use case has started
6. Check Services provisioned (Message 1, 2, 3, 4 – as implementation: progress 5. Identify Upsell, Cross-sell
vs MyAccount needed) and estimated Go-live date; opportunities together with
5. Customer call and agreement 4. Send CLM Adoption Survey; Account Team
(cloud.oracle.com)
of 1 or more Use Cases 5. Assist in specific issues: Bugs; (TSR/OC/OLCSM) if
7. Assist 1 on 1 in specific
6. Present Oracle Consulting Deployment; Connectivity; applicable
issues:
and reflect benefits for Sizing etc. 6. Internal Go Live, PR & Social
- Provisioning
implementation Media Public Go Live Tweet
- Credentials reset (User/Pass)
- Welcome E-mail (resend)
7. Send Unsolicited Offer form 7. Nano Reference
OC and engage consultant 8. Public Reference

86

86
Processus d'adoption – Compartiment – Sprint – Tâche

◦ L'équipe Cloud Success est structurée en plusieurs mêlée (Inspiré de la méthodologie Agile).
◦ Une mêlée est composée de 8 personnes dirigées par un Maitre (Scrum master).
◦ Le Maitre (Scrum master) mesure la performance de l'équipe et s'occupe des bloqueurs
◦ L'objectif de l'équipe (mêlée) est de faire progresser les clients à travers les compartiments pour
parvenir à l'adoption
◦ L'activité est organisée en cycles de 2 semaines appelés Sprints.
◦ Le mêlée (L'équipe Scrum) a établi les Tâches à exécuter dans chaque Sprint
◦ Un reunion quotidien (stand-up meeting) de 15 min donne une visibilité sur le projet sur l'avancement des
tâches et expose les bloqueurs empêchant les tâches
◦ Les bloqueurs qui ne sont pas résolus au sein de l'équipe sont remontés au manager
◦ Après l'achèvement de chaque sprint, une retrospective est organisée afin de discuter les réalisations de
la tâche, des inconvénients possibles et des leçons apprises.

Oracle Confidential – Highly Restricted 87

87
 Planification Equipe d’adoption Cloud
du Sprint
Mêlée #1 Mêlée #2 Mêlée #n

Coup d'envoi
du Sprint SPRINT (cycle de 2 semaines)
Reunion
quotidien
Task #1 Task #2 Task #3 Task #m
Compartiments client (Customer Buckets)
Retrospective
du Sprint Embarquement
Sélection du
Mise en œuvre Lancement
scénario

88

Processus d'adoption – Bucket – Sprint – Tâche

L'équipe d’adoption est structurée en plusieurs mêlées (Inspiré de la méthodologie Agile).
Une équipe Scrum (mêlées ) est composée de 6 - 8 personnes dirigées par un Scrum master.
Le Scrum master mesure la performance de l'équipe et s'occupe des bloqueurs
L'objectif de l'équipe Scrum est de faire progresser les clients à travers les seaux pour parvenir à l'adoption
L'activité est organisée en cycles de 2 semaines appelés Sprints.
L'équipe Scrum a établi les Tâches à exécuter dans chaque Sprint
Un reunion quotidien (daily stand-up of the scrum team meeting) de 15 min donne une visibilité sur le projet sur
l'avancement des tâches et expose les bloqueurs empêchant les tâches
Les bloqueurs qui ne sont pas résolus au sein de l'équipe sont remontés au manager
Après l'achèvement de chaque sprint, une revue est organisée afin de discuter des réalisations de la tâche, des
inconvénients possibles et des leçons apprises.

88
 Pourquoi Agile et Scrum
devraient vous intéresser ?

89