l’informatique efficience
TRANSCRIPT
L’informatique efficience
Informatique par la pratique : Création d’un serveur de jeux de quizz
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
L’efficience
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Qu’est-ce l’efficience ?•L'efficience est l'optimisation des outils mis en œuvre pour parvenir à un résultat. Elle se mesure sous la forme d'un rapport entre les résultats obtenus et les ressources utilisées
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Efficience # Efficacité• qui est le rapport entre les résultats obtenus et les objectifs fixés
Efficacité C’est efficace mais pas efficient
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Efficience # Rentabilité• qui est le rapport entre les revenus obtenus et les capitaux investis
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Efficience > Efficacité > RentabilitéRentabilité Efficacité Efficience
Optimise les ressources employés et diminuent leur coût
L’efficacité : Atteindre les objectifs fixés
Atteindre les objectifs fixésUtilisés les bonnes ressources
Pas de surcoût
L’atteinte des objectifs fixés n’est pas obligatoire
Surcoût / Surdimensionnement des ressources employés
Difficile à mettre en place les humains mais nécessaire
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
L’exploitabilité
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Qu’est-ce que l’exploitation informatique• L'exploitation informatique est l'activité qui consiste à maintenir
opérationnel de manière stable, sûre et sécurisée un outil informatique dans un environnement de développement, de qualification, de formation, ou de production, dans ses parties matérielles et logicielles
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
VABE : Vérification d’Aptitude à la Bonne Exploitabilité1. Vérifier que l’applicatif est conforme aux Normes édictées par la Production Informatique
(intégration de l’applicatif dans la supervision, dans l’ordonnanceur, normalisation de l’applicatif pour en faciliter son exploitation, …)
2. Vérifier la pertinence de la supervision3. Vérifier la cohérence de l’intégration des traitements dans la plan de production global ainsi
que des procédures de reprise des traitements4. Vérifier que les niveaux de Qualité de Service (notamment les SLA) sur lesquels la Production
Informatique va s’engager sont atteignables et perdurables.5. Vérifier la présence, la pertinence de procédure d’exploitation et les dérouler6. Vérifier le Plan de Reprise d’Activité conformément aux besoin du client (DMIA, etc….)
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
La scalabilité
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Evolutivité / Scalabilité # Evolué• Un système capable d’accueillir 200 personnes lorsqu’on est que 50 personnes n’est pas scalable
mais évolué. En effet il permet d’atteindre 50 personnes mais que se passera-t-il si on dépasse les 200 personnes ?
#• Un système capable d’accueillir les 50 personnes et d’être facilement évolutif et rapide sera plus
scalable dans le temps. En effet
• Que se passera-t-il lorsque les 200 personnes seront dépassés ? Le système de palier par 50 le permettra tout aussi facilement mais celui prévu initialement pour 200 peut-être pas ?
Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet
Le JITA : Juste in time applicatif
Le JITA : Garantir le retour marché• Le juste-à-temps concerne tous les aspects de la logistique en amont
et en aval du développement, de la transitique interne à l'usine et les relations avec la sous-traitance.• Le principe du juste-à-temps est que la production est "tirée" par la
demande et non par l'offre : il faut produire puis livrer (dans un temps très court) ce qui est demandé "instantanément" par le client (production en "flux tendu").
1 Système complexe est un ensemble de sous systèmes imbriqués et assemblés pour produire une vue unique
Réutilisabilité
La réutilisabilité • Grand principe de développement qui consiste à réutiliser le code (code source ou API)
produit par d'autres. Cette pratique à beaucoup d'avantages :• Réduction du temps de développement• Moindre complexité de l'application (par externalisation dans des API de certaines fonctions)• Moindres compétences en interne nécessaires, certaines portions de code n'étant
compréhensible que par quelques gourous)• Plus grande sûreté de fonctionnement : des API largement répandues et réutilisées ont moins
de chance de contenir des bugs résiduels• Grande communauté utilisatrice de l'API produisant de la documentation et isolant
rapidement des bugs.• Pourquoi réinventer la roue ? Autant réutiliser du code produit par d'autre, dans le respect du
droit d'auteur et des licences d'utilisation de ce code.
Quelques lois informatiques
Quelques lois en informatique à connaitre• loi d'Osborn: "les constantes ne le sont pas, les variables ne le seront pas" :
• Ceci traduit des défauts récurrents de conception dans les programmes dans lesquels les programmeurs définissent en constantes des données qu'ils tentent de modifier, provoquant ainsi des bugs ; et des variables que les fonctions ne modifient jamais faute de rencontrer la condition favorable qui provoquerait ce changement de valeur.
• Loi de Parkinson : Loi selon laquelle, "tout comme les gaz parfaits, les données tendent à remplir tout l'espace dont elles disposent". • Ainsi, concevoir des ordinateurs avec toujours plus de capacité mémoire encourage les développeurs d'applications à en consommer
plu
• Loi de Murphy : Tout ce qui est susceptible de mal tourner, tournera nécessairement mal
• Loi de Gates : la vitesse d'exécution des logiciels est divisée par 2 tous les 18 mois à technologie constante
• Loi des scouts : « Personne ne connait tout car il ne connait que ce qu’il a besoin ». Plusieurs personnes ensemble connaissent plus qu’une personne seule
• Deuxième loi des scouts : Laisse le lieu que tu quittes plus propre que tu ne l’as trouvé si tu veux le retrouver propre
Méthode InformatiqueIl n’existe pas de méthode parfaite
Approche traditionnelle vs Agie
Scrum vs KanbanScrum Kanban
BacklogC’est l’endroit ou l’équipe va planifier les sprints et estimer les stories qui seront affectées aux sprints.
WorkflowVous pouvez mapper vos colonnes aux états de vos workflows JIRA. Ces colonnes pourront changer si votre workflow change, en ajoutant ou retirant simplement des colonnes.
Planification des Sprints
En général lorsque l’on planifie les sprints, le product owner et le project manager se réunissent avec les développeurs et leur demandent des etimations. Ces informations peuvent être entrées directement dans JIRA Agile.
SwimlanesLes swimlanes sont très pratiques pour séparer et organiser les demandes. Un exemple peut être de grouper les demandes par attribution. On peut ainsi voir facilement combien de demandes sont affectées à chaque développeur.
Agile BoardIl s’agit du mode Travail, où l’on peut voir le tableau Agile en tant que tel, avec une colonne par statut. Il permet de voir l’avancement d’un sprint.
ContraintesIl est possible de positionner des contraintes minimum et maximum sur le nombre de demandes se trouvant dans chaque colonne. La couleur de fond de la colonne changera en fonction du respect ou non des contraintes. Cela offre un visuel simple pour la prise de décision.
RapportsAvec les Scrum boards, vous disposez de plusieurs rapports d’avancement des sprints.Burndown Chart – vérifie l’avancement des équipes par rapport à ce qui était prévu. Si le scope initial du sprint a été modifié, cela sera également visible dans ce rapport. Les autres rapports disponibles sont : Sprint Report, Epic Report, Velocity Chart, Version Report, etc.
RapportsKanban dispose également de rapports.Un rapport qui est très utile en Kanban est le Control Chart. Il permet de mesurer le temps de cycle pour les demandes. C’est-à-dire qu’il calcule le temps moyen effectif pour traiter les demandes.
Scrum+KanbanCe board permet d’appliquer les fonctionnalités basiques de Kanban pour améliorer le traitement des stories.
Quelle méthode est la plus efficiente ?• IL N’Y EN A PAS : IL FAUT ADAPTER CHAQUE METHODE A L’EQUIPE
Quelle méthode adopter, si l’équipe est nombreuse et/ou que les fonctions sont très complexe ?Adopter la méthode itérativeQuelle méthode adopter, si l’équipe est petite et qu’on souhaite démarrer rapidement ?Adopter la méthode KANBANQuelle méthode adopter si on a besoin d’un état des lieux détaillé d’avancé du projet ?Adopter la méthode SCRUM
La méthode Efficiente• Elle n’existe pas mais si elle existait elle se rapprocherait plus de
Kanban, car la méthode doit être
• La plus simple• Permettre le plus de participation entre les équipes• Permettre une communication continu entre les différents membres• Permettre une autodocumentation du développement pour simplifier
l’intégration de nouveaux membres
Peut-on appliquer le Kanban au grand projet?• Telle quelle non !• Mais un grand projet est une erreur en lui-même• Un grand projet doit être divisible• Un grand projet regroupe plusieurs domaines ou phases• Chaque domaine ou phase doit être un projet à part entière
• Avec un début, une ou plusieurs mêlées et un fin
Synopsis d’un projet efficientId
ées
Atel
ier d
e vis
ion
Stor
y map
ping
Swot
/ Ro
adm
ap
Back
log
Défin
ition
de
l’équ
ipe
Défin
ition
d’u
n
plan
de
rele
ase
Spéc
ifica
tion
géné
rale
Déve
lopp
emen
t
Spéc
ifica
tion
par l
’exem
ple
Réal
isatio
n du
déve
lopp
emen
tTe
st u
nita
ire Test
d’a
ccep
tanc
eIn
tégr
ation
co
nten
u Test
d’
inté
grati
on
Clie
nt/U
tilisa
teur
Direction de Projet / Architect L’équipe Devops L’équipe Devops / client
De l’idée au projet
Boite à idées / Atelier de visions
Story mapping Agile RoadmapProduct Backlog
Intervenants : Direction de projets / Product Manager / Architecte et Chef de projet
Mise en place de l’équipe
Product Owner /Stake HolderQA ValidatorDeveloperBusiness UserSystem Administrator
Exploitation, Durabilité, Performance, Déploiement,
Supervision, Monitoring, Configuration
Service
Pourquoi ne pourrait-on pas ?Comment pourrait-on ?Quelle-est la première étape pour aller d'ici à là ?Que peut-on arrêter de faire ?
Planning, coût, risque, opportunités, validation
Planning, coût, risque, opportunités, validation
Plan release1 Plan release est une subdivision du Product BackLog. On doit définir• Les major features à livrer• Jalons de date• On peut estimer la capacité nécessaire et les réactions à entreprendre
Constat sur les spécifications• Les principes et pratiques abordés par cet article ont pour point de départ les constats suivants :
• Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey).
• Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv – 1996).
• Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995).
Spécification générale • En approche efficiente, il est strictement interdit de réaliser des
spécifications détaillés car le temps passés à réaliser ces spéc allongent le JITA ce qui augmente le risque de rejet de l’application• Exclure toute connotation technique et détails d’IHM de la
spécification écrite. La documentation technique de type architecture (logicielle ou matérielle) trouvera sa place dans un dossier d’architecture si le projet le nécessite ainsi que dans le code source• Privilégier le vocabulaire de l’utilisateur, le langage naturel (plutôt que
télégraphique), au présent (plutôt qu’au futur) et décrire l’expérience utilisateur.
Processus de réalisation par story
Développement• Le développement est le fait de passer les tests unitaires au vert et
rien d’autre• Aucun surplus ne doit être réalisé• Le développement doit être évolutif mais non évolué• Chaque classe doit mettre de ce quelle a à faire
Celui qui sait, fait ! Une classe par fonction ! Une application modulaireJe me limite au minimum pour être au vert !
Test D’intégration• Un développeur chargé de l’intégration des différentes fonctions du système doit
appliquer la même que le développeur d’une fonction• Les tests d’intégration doivent couvrir les aspects suivants
• Fonction, Déploiement, Configuration, Journalisation, Debugging, Monitoring, Compatibilité et conformité
• Un environnement d’intégration doit être prévu et similaire à la production (en nombre de composants mais d’unité)
• Les tests d’intégration doivent être automatisés
• Les tests d’intégration doivent être restitué dans un cahier d’acceptation
• Les développeurs d’intégration sont responsable de la branche intégration dans le contrôleur de source.
• Les tests d’intégration doivent être définis entre les développeurs et les administrateurs
Validation QA• La Validation se fait à l’intégration de chaque fonctionnalité
et non à la fin du projet de développement
• La QA s’assure la conformité du développement et des spécifications
• La QA s’assure que les tests d’acceptance sont en vert
• La QA s’assure que les documents et spécifications intégrent bien les derniers cas d’usage spécifiés et développés
• La QA s’assure que les tests fonctionnels humains sont conformes aux spécifications
• La QA est garant du temps de traitement de l’application conformément aux prérequis
Le changement• Changement chez le client
• L’équipe projet doit accompagner le client dans son changement pour éviter les effets boomerang
• Des ateliers changement doivent être prévu dès le départ pour former les utilisateurs à la future version et non pas attendre la fin du projet
• Les animateurs doivent remonter à l’équipe projet toute remarque des utilisateurs via un jeu de questionnaire
• Un atelier de relecture des retours clients doit être prévu pour éviter le rejet futur
• Changement chez le développeur• Les spécifications doivent être flexible pour permettre le changement à tout
moment• Les Développements doit être suffisant mais trop
Evolution des besoins de transport
Formaliser les spécifications• La matrice Given-When-Then est un format recommandé pour le test fonctionnel d'une
User Story:
• (Given) (Etant donné) un contexte,• (When) (Lorsque) l'utilisateur effectue certaines actions,• (Then) (Alors) on doit pouvoir constater telles conséquences
• Par exemple:• Etant donné un solde positif de mon compte, et aucun retrait cette semaine,• Lorsque je retire un montant inférieur à la limite de retrait,• Alors mon retrait doit se dérouler sans erreur ou avertissement
• Des outils tels que JBehave, RSpec ou Cucumber encouragent l'utilisation de cette formule
Les outils• Les outils du développeur
• Développement• Visual studio 2015• Resharper
• Test – contrôle de qualité• Ncrunch• Nunit
• Spécification• Specflow
• Contrôle de source• Team Service Git
• Planing / Tâche• Team Service Work Item
• Les outils du Build• Build
• Team Service Build• Test – automatique
• Nunit runer• Team Service Test
• Spécification• Specflow generator for doc
• Contrôle de source• Team Service Git
• Planing / Tâche• Team Service Work Item
• Release• Hosting
• Azure• Partage de packages
• Team Service Package