Merge remote-tracking branch 'EII/master'
This commit is contained in:
commit
2b3e882810
BIN
Cours Cryptographie/Ressources/partiel2017.JPG
Normal file
BIN
Cours Cryptographie/Ressources/partiel2017.JPG
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 492 KiB |
|
|
@ -5,24 +5,24 @@ Architecture monolithique
|
|||
|
||||
## Principes du monolithique
|
||||
|
||||
"qui est fait d'un seul bloc" => code dans un seul fichier.
|
||||
créé à partir des premiers langages pour comminuqer avec machines (le B, le C). On scriptait tout dans un seul fichier.
|
||||
Ca a perduré avec le temps.
|
||||
"Qui est fait d'un seul bloc" => code dans un seul fichier.
|
||||
Créé à partir des premiers langages pour comminquer avec les machines (le B, le C). On scriptait tout dans un seul fichier.
|
||||
Ça a perduré avec le temps.
|
||||
=> ça a donné crise du logiciel par la suite
|
||||
|
||||
## Application monolithique
|
||||
|
||||
Ne fonctionne qu'avc une seule technologie parce que c'est conçu pour aller d'un point A à un point B
|
||||
Ne fonctionne qu'avec une seule technologie parce que c'est conçu pour aller d'un point A à un point B
|
||||
Conçu pour remplir un but de la façon la plus simple possible.
|
||||
Ça bloque donc au niveau technologique => restreint dans techno utilisée de base.
|
||||
Le logiciel a une seule techno et donc c'est ce logiciel qui fait tout, quel que soit le niveua de l'action.
|
||||
Difficulté dans changement : on doit tout reprendre pour la moindre modification, il fuadrait tout réécrire, sinon ça risque de pas s'mboiter avec le reste. De plus en plus compliqué de modifier quand logiciel grossit.
|
||||
Excellentes possibilités doptimisation du code par contre : on doit répondre à un besoin simple et on réfléchi à l'optimisation de son exécution.
|
||||
Le logiciel a une seule techno et donc c'est ce logiciel qui fait tout, quel que soit le niveau de l'action.
|
||||
Difficulté dans changement : on doit tout reprendre pour la moindre modification, il faudrait tout réécrire, sinon ça risque de pas s'emboiter avec le reste. De plus en plus compliqué de modifier quand le logiciel grossit.
|
||||
Excellentes possibilités d'optimisation du code par contre : on doit répondre à un besoin simple et on réfléchit à l'optimisation de son exécution.
|
||||
|
||||
### Déploiement
|
||||
|
||||
il est assez simple, car on a un serveur, un processus.
|
||||
encore une fois ça pousse à l'optimisation : bons temps de réponse, exécution rapide.
|
||||
Il est assez simple, car on a un serveur, un processus.
|
||||
Encore une fois ça pousse à l'optimisation : bons temps de réponse, exécution rapide.
|
||||
|
||||
### Gestion de projet
|
||||
|
||||
|
|
@ -46,8 +46,8 @@ Il permet en effet plus facilement de revenir sur l'étape précédente. Ça ap
|
|||
|
||||
Miam :
|
||||
|
||||
* Plutôt avec des lanages bas niveau => grnade maitrise logicielle et matérielle, logiciels très optimisés. On fait des géants très performants avec ça
|
||||
* L'application va faire tous les traitements de A à Z => facile à conceptualiser, à concevoir. Moins de complexité dnas la gestion et la construction que microservice.
|
||||
* Plutôt avec des langages bas niveau => grande maitrise logicielle et matérielle, logiciels très optimisés. On fait des géants très performants avec ça
|
||||
* L'application va faire tous les traitements de A à Z => facile à conceptualiser, à concevoir. Moins de complexité dans la gestion et la construction que microservice.
|
||||
* Facilité de déploiement !
|
||||
|
||||
Berk :
|
||||
|
|
@ -61,15 +61,15 @@ Joli tableau dans le prezi
|
|||
|
||||
## Conclusion
|
||||
|
||||
la monolithique est encore très utilisée aujourd'hui, bien que microservices soient préconisés
|
||||
La monolithique est encore très utilisée aujourd'hui, bien que microservices soient préconisés
|
||||
La majorité des logiciels aujourd'hui sur un PC par exemple est en monolithique.
|
||||
Les microservices sont surtout présents dnas web
|
||||
Entreprises s'y mettent mais logique et trucs présents sont encor en monolithique.
|
||||
Les microservices sont surtout présents dans le web
|
||||
Entreprises s'y mettent mais logique et trucs présents sont encore en monolithique.
|
||||
|
||||
On est vraiment bloqués sur une techno
|
||||
Forte possibilité d'amélioration du code
|
||||
Gestion de projet en cascade et V
|
||||
un seul truc qui fait tout
|
||||
Un seul truc qui fait tout
|
||||
|
||||
## Bouiche
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
COBIT
|
||||
========================
|
||||
===
|
||||
|
||||
*20/04/18*
|
||||
|
||||
## Introduction
|
||||
## Exposé
|
||||
|
||||
### Introduction
|
||||
|
||||
**C**ontrol O**b**jectives for **I**nformation and related **T**echnology
|
||||
|
||||
|
|
@ -10,7 +13,7 @@ Fait en 1994, publié en 1996
|
|||
|
||||
La plus utilisée = version 4.1
|
||||
|
||||
## Principe
|
||||
### Principe
|
||||
|
||||
Sert à optimiser trucs informatiques :
|
||||
|
||||
|
|
@ -19,13 +22,12 @@ Sert à optimiser trucs informatiques :
|
|||
* mesurer sa performance et sa maturité
|
||||
* ...
|
||||
|
||||
Se presente sous tableau avec grille (consulté - supervise... comme dans EBIOS (?))
|
||||
Se presente sous forme d'un tableau avec grille (consulté - supervise... comme dans EBIOS (?))
|
||||
Y a plusieurs vues, hein, une tétrachié même
|
||||
|
||||
### Version 4.1
|
||||
|
||||
## Version 4.1
|
||||
|
||||
BAsé sur un pentagone qui fournit des processus pour lier différents "trucs" :
|
||||
Basé sur un pentagone qui fournit des processus pour lier différents "trucs" :
|
||||
|
||||
* alignement stratégique
|
||||
* value delivery : valeur des métiers
|
||||
|
|
@ -33,16 +35,170 @@ BAsé sur un pentagone qui fournit des processus pour lier différents "trucs" :
|
|||
* resources management: bonne gstion du temps et budget et personnes
|
||||
* performance mesurement : permet de se mesurer dans efficacité
|
||||
|
||||
## Version 5
|
||||
### Version 5
|
||||
|
||||
Version 4 juste basée sur gouvernance, là ou le 5 est sur management et gouvernance : englobe entreprise entière
|
||||
|
||||
Version 5 a 5 principes aussi. Au lieu de se baser sur un seul référentiel, ils créent un "méta réfentiel" qui en englobe plusieurs. => toutes les bonnes pratiques d'une entreprise.
|
||||
|
||||
## Bouiche
|
||||
### Bouiche
|
||||
|
||||
TOGAF 9 : savoir qu'il existe et ce qu'iul fait c'est bof
|
||||
TOGAF 9 : savoir qu'il existe et ce qu'il fait c'est bof
|
||||
Prince2 : plus important
|
||||
ITIL : aussi
|
||||
PMBOK : c'est un plus sur un CV - vraiment à connaitre
|
||||
COSO
|
||||
|
||||
## Cours
|
||||
|
||||
### Définition
|
||||
|
||||
Référentiel pour l'audit et la gouvernance des technologies de l'information
|
||||
|
||||
S'intéresse en particulier aux objectifs liés à informatique. Le prince est de dire quoi faire, mais pas comment.
|
||||
|
||||
### Historique
|
||||
|
||||
Créé par ISACA (en France : AFAI)
|
||||
|
||||
Plusieurs versions avec le temps : de 1 à 5 de 1996 à 2013
|
||||
|
||||
La version 5 a évolué pour prendre en compte business model des entreprises utilisant COBIT et leurs environnements technologiques. COBIT peut ainsi s'appliquer à toutes les entreprises peu importe lieu ou culture.
|
||||
|
||||
### Application
|
||||
|
||||
Possible dans de nombreux dommaines d'une entreprise :
|
||||
|
||||
- Sécurité de l'information
|
||||
|
||||
- Gestion des risques
|
||||
|
||||
- Gouvernance et gestion du SI
|
||||
|
||||
- Activités d'audit
|
||||
|
||||
- Conformité avec législation et règlementation
|
||||
|
||||
- Opérations financières ou rapports sur responsabilité sociale
|
||||
|
||||
### Objectifs
|
||||
|
||||
- Faire le lien entre risques métiers, besoins de contrôle et questions techniques pour de meilleures pratiques d'audit
|
||||
|
||||
- Apporter une logique de contrôle et de management pour gérer les solutions techniques et les risques business
|
||||
|
||||
- Fournir un langage commun pour permettre aux dirigeants de communiquer entre eux sur objectifs et résultats
|
||||
|
||||
### Principe
|
||||
|
||||
- Redessine les processus SI, structures organisationnelle et systèmes de production de façon à aligner la gouvernance IT sur la stratégie de l'entreprise.
|
||||
|
||||
- Pour chaque processus, fournit indicateurs clés d'objectifs et de performance et des facteurs clé de succès basés sur ce que l'entreprise a besoin de faire (et non sur la façon de le faire)
|
||||
|
||||
5 principes :
|
||||
|
||||
- Répondre aux besoins des parties prenantes
|
||||
|
||||
- Couvrir l'entreprise de bout en bout
|
||||
|
||||
- Appliquer un référentiel unique et intégré
|
||||
|
||||
- Faciliter une approche globale
|
||||
|
||||
- Distinguer la gouvernance de la gestion
|
||||
|
||||
### Étapes
|
||||
|
||||
1. Quels sont les déclencheurs ?
|
||||
|
||||
2. Où en sommes nous acutellement ?
|
||||
|
||||
3. Où aimerions nous être ?
|
||||
|
||||
4. Que doit-on faire pour y arriver ?
|
||||
|
||||
5. Comment y parvenir ?
|
||||
|
||||
6. Avons-nous atteint notre objectif ?
|
||||
|
||||
7. Comment continuer d'avancer ?
|
||||
|
||||
### Domaines et processus (COBIT 4)
|
||||
|
||||
34 processus regroupées en 4 domaines
|
||||
|
||||
1. Planing and Organization
|
||||
|
||||
Comment utiliser au mieux technologies pour que l'entreprise atteigne ses objectifs ?
|
||||
11 processus
|
||||
|
||||
2. Acquisition and Implementation
|
||||
|
||||
Comment définir, acquérir, mettre en œuvre les technologies nécessaires en adéquation avec les business process ?
|
||||
6 processus
|
||||
|
||||
3. Delivery and Support
|
||||
|
||||
Comment garantir l'efficacité et l'efficience des systèmes technologiques en action ?
|
||||
13 processus
|
||||
|
||||
4. Monitoring
|
||||
|
||||
Comment s'assurer que la solution mise en œuvre corresponde bien aux besoins de l'entreprise dans une perspective stratégique ?
|
||||
4 processus
|
||||
|
||||
|
||||
|
||||
### Critères de qualitification d'un jugement
|
||||
|
||||
1. Efficacité
|
||||
|
||||
2. Efficience
|
||||
|
||||
3. Confidentialité
|
||||
|
||||
4. Intégrité
|
||||
|
||||
5. Disponibilité
|
||||
|
||||
6. Conformité
|
||||
|
||||
7. Fiabilité
|
||||
|
||||
|
||||
|
||||
Les données concernées sont :
|
||||
|
||||
- Données
|
||||
|
||||
- Applications
|
||||
|
||||
- Technologies
|
||||
|
||||
- Installation
|
||||
|
||||
- Personnel
|
||||
|
||||
|
||||
|
||||
### Package
|
||||
|
||||
L'outil dispose du package avec ces ressources :
|
||||
|
||||
- Executive summary
|
||||
Résumé rapide pour managers pressés
|
||||
|
||||
- Framework
|
||||
Cadre de référence qui explique la méthode, les domaines, les processus
|
||||
|
||||
- Control Objectives
|
||||
215 objectifs de contrôle
|
||||
|
||||
- Audit Guidelines
|
||||
Comment assurer un audit efficace
|
||||
|
||||
- Implementation Tool Set
|
||||
Outils pour la mise en œuvre de COBIT
|
||||
|
||||
- Management Guideline
|
||||
Guide du management
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Cours général
|
||||
========================
|
||||
Génie logiciel
|
||||
===
|
||||
|
||||
## Cycles du développement informatique
|
||||
|
||||
|
|
@ -9,7 +9,6 @@ Gérer tests et erreurs
|
|||
|
||||
### Les documents livrés
|
||||
|
||||
|
||||
### Les risques
|
||||
|
||||
* humains
|
||||
|
|
@ -17,11 +16,10 @@ Gérer tests et erreurs
|
|||
|
||||
Sont à prévoir en tant que manager, leur probabilité, leur type, et la solution préconisée
|
||||
|
||||
|
||||
### La maintenance
|
||||
|
||||
* Corriger ls bugs, erreurs résiduelles = maintenance corrective
|
||||
* maintenance adaptative
|
||||
* Corriger les bugs, erreurs résiduelles = maintenance corrective
|
||||
* Maintenance adaptative
|
||||
* Maintenance évolutive
|
||||
|
||||
## Les modèles de développement
|
||||
|
|
@ -38,13 +36,12 @@ Valorise l'humain, le travail, implique le client.
|
|||
|
||||
## Cycle de vie d'un projet
|
||||
|
||||
|
||||
## Random
|
||||
|
||||
Il faut écouter les membres de son équipe. u_u
|
||||
si on les implique, ils apprennent.
|
||||
Si on les implique, ils apprennent.
|
||||
|
||||
__________________________________
|
||||
---
|
||||
|
||||
*25/05/18*
|
||||
|
||||
|
|
@ -60,7 +57,6 @@ __________________________________
|
|||
|
||||
L'exam sera un QCM avec une 50aine de questions. 2h.
|
||||
|
||||
|
||||
## Mémoire
|
||||
|
||||
Faut avoir un plan. du moment que y a un plan c'est bon. Faut déjà essayer maintenant de voir si y a assez de matière pour faire un mémoire.
|
||||
Faut avoir un plan. Du moment que y a un plan c'est bon. Faut déjà essayer maintenant de voir si y a assez de matière pour faire un mémoire.
|
||||
|
|
|
|||
|
|
@ -1,42 +1,125 @@
|
|||
Design pattern
|
||||
========================
|
||||
===
|
||||
|
||||
# Intro
|
||||
## Exposé
|
||||
|
||||
Ca aide les dev à bien oprganiser leur code
|
||||
### Intro
|
||||
|
||||
# Catégories
|
||||
Ca aide les dev à bien organiser leur code
|
||||
|
||||
Création : anièr de crér un objet ou un ensemble d'objet
|
||||
### Catégories
|
||||
|
||||
Création : manière de créer un objet ou un ensemble d'objets
|
||||
Comportement : manière d'interprétation du code et des objets
|
||||
Structure :
|
||||
|
||||
# Avantages
|
||||
### Avantages
|
||||
|
||||
modularité : modules bien précis, on sait ou chercher
|
||||
cohésion
|
||||
couplage : modules s'intancient ls uns dnas les autres pour etre réutilisés
|
||||
rutilisablilité : bibliothèques, frameworks utiles à d'autres
|
||||
- Modularité : modules bien précis, on sait ou chercher
|
||||
|
||||
# incovénient
|
||||
- Cohésion
|
||||
|
||||
complexité : c'est dur à apprendre (long)
|
||||
effrot abstraction/synthèse : gros travail préalable et faut le prendr en main
|
||||
- Couplage : modules s'instancient les uns dans les autres pour être réutilisés
|
||||
|
||||
# Les frameworks qui utilisent
|
||||
- Réutilisabilité : bibliothèques, frameworks utiles à d'autres
|
||||
|
||||
### Incovénient
|
||||
|
||||
Complexité : c'est dur à apprendre (long)
|
||||
Effort abstraction/synthèse : gros travail préalable et faut le prendre en main
|
||||
|
||||
### Les frameworks qui l'utilisent
|
||||
|
||||
.net en implémentation
|
||||
JavaServer Faces
|
||||
MVC
|
||||
spring
|
||||
Spring
|
||||
|
||||
# Conclusion
|
||||
### Conclusion
|
||||
|
||||
c'est quand même utile
|
||||
C'est quand même utile
|
||||
|
||||
# Bouiche
|
||||
### Bouiche
|
||||
|
||||
C'est orienté objet, langage objet.
|
||||
Il a pas assez parlé des API
|
||||
API : bibliothèque qui pourront être réutilisés dans d'autres codes
|
||||
il est ilportant en design pattern de réutiliser ce squi a déjà été fait
|
||||
il est important en design pattern de réutiliser ce qui a déjà été fait
|
||||
|
||||
|
||||
|
||||
## Cours
|
||||
|
||||
### Historique
|
||||
|
||||
Création au début des années 70, à l'origine issu de l'architecture puis appliqué au monde logiciel dans les années 90
|
||||
|
||||
### Définition
|
||||
|
||||
Solution éprouvée à un problème récurrent dans la conception d'applications orientées objet (optimisation, évolutivité, clarté...)
|
||||
|
||||
Se définit en amont du développement et est indépendant du langage.
|
||||
|
||||
Chaque design pattern se caractérise par
|
||||
|
||||
- Un nom
|
||||
|
||||
- Une problématique
|
||||
|
||||
- Une solution
|
||||
|
||||
- Une conséquence
|
||||
|
||||
### Objectif
|
||||
|
||||
Rendre le code plus efficace
|
||||
|
||||
### Catégories
|
||||
|
||||
En tout 23 design patterns regroupés en 3 catégories :
|
||||
|
||||
- Création : instantiation et configuration des classes et objets
|
||||
|
||||
- Structure : Organisation des classes d'une application
|
||||
|
||||
- Comportement : Organisation des objets pour qu'ils collaborent entre eux.
|
||||
|
||||
#### Création
|
||||
|
||||
L'idée est de créer des objets de manière appropriée à la situation. Les modèles les plus utilisés :
|
||||
|
||||
- Factory method : instancier plusieurs objets d'une même classe, aux paramètres différents
|
||||
|
||||
- Singleton : instancier un seul objet d'une classe donnée
|
||||
|
||||
#### Structure
|
||||
|
||||
Facilitent la conception via un moyen simple de réaliser des relations entre entités.
|
||||
|
||||
Le plus utilisé : Decorator.
|
||||
Permet de redéfinir certaines méthodes d'une classe pour certaines instances uniquement
|
||||
|
||||
|
||||
|
||||
#### Comportement
|
||||
|
||||
Identifient les modèles de communication entre les objets et les reproduisent
|
||||
|
||||
Le plus utilisé : Observer
|
||||
Une classe aux valeurs changeante contacte directement celle chagrée de l'affichage lorsque sa valeur change
|
||||
|
||||
|
||||
|
||||
### Avantages / Inconvénients
|
||||
|
||||
| Avantages | Inconvénients |
|
||||
| ----------------------------------------------------------------------- | ---------------------------------------------------- |
|
||||
| Gain de rapidité, de qualité et baisse des coûts | Difficile d'accès, nécessite d'être expérimenté |
|
||||
| Réutilisabilité et bonnes pratiques | Difficile de savoir lequel des 23 est le plus adapté |
|
||||
| Bonne doc et aide à la communication entre développeurs car bien connus | Utile uniquement sur POO |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Exam
|
||||
========================
|
||||
===
|
||||
|
||||
5/10 questions par exposé
|
||||
|
||||
|
|
|
|||
|
|
@ -1,19 +1,17 @@
|
|||
Exposé MicroServices & Webservices
|
||||
========================
|
||||
|
||||
Alexandre et Morgan
|
||||
===
|
||||
|
||||
## Présentation
|
||||
|
||||
C'est quoi ? > Méthod de devloppement logiciel basé sur conception de plusieurs tout petits services indépendants et autonomes.
|
||||
C'est quoi ? > Méthode de développement logiciel basé sur conception de plusieurs tout petits services indépendants et autonomes.
|
||||
Opposé au monolithique.
|
||||
Système minimaliste, souple : si on intervient ou conçoit un service, on a en soit pas à se soucier des autres, ni de redéployer l'application en entier.
|
||||
Système minimaliste, souple : si on intervient ou conçoit un service, on a en soit pas à se soucier des autres, ni à redéployer l'application en entier.
|
||||
|
||||
4 points principaux : **componentization**
|
||||
|
||||
1 > Cohérence et logique et logique système : KISS, ou you has one job
|
||||
1 > Cohérence et logique système : KISS, ou you has one job
|
||||
|
||||
2 > spécificité des fonctionnalités : ils sont tous indépendants l suns des uns, is un tombe les autres non.
|
||||
2 > Spécificité des fonctionnalités : ils sont tous indépendants les uns des uns, si un tombe les autres non.
|
||||
|
||||
3 > Autonomie des services
|
||||
|
||||
|
|
@ -22,34 +20,41 @@ Système minimaliste, souple : si on intervient ou conçoit un service, on a en
|
|||
Opposition monolithique et microservices : monolithique = une grosse BDD partagée
|
||||
micros : plein de petites, parfois partagées pour quelques microservices
|
||||
|
||||
## Communication des ms entre eux
|
||||
## Communication des microservices entre eux
|
||||
|
||||
Deux grosses manières : REST et bus de message
|
||||
Deux grosses manières : REST et BUS de message
|
||||
|
||||
### REST : par http(s)
|
||||
#### Avantage :
|
||||
tous les services se comprennent (grand interopérabilité entre systèmes et applications)
|
||||
assez simple à mettre en place
|
||||
|
||||
#### Avantages :
|
||||
|
||||
- Tous les services se comprennent (grande interopérabilité entre systèmes et applications)
|
||||
|
||||
- Assez simple à mettre en place
|
||||
|
||||
#### Inconvénient :
|
||||
débordment de messages http(s), chacun envoyant les siens, surcharge réseau
|
||||
|
||||
### Bus de messages
|
||||
un serveur réceptionne tous les messages et le tranmet aux autres services
|
||||
il ne les traite pas ! renvoie juste, plutot rapide
|
||||
- Débordement de messages http(s), chacun envoyant les siens, surcharge réseau
|
||||
|
||||
### BUS de messages
|
||||
|
||||
Un serveur réceptionne tous les messages et le transmet aux autres services
|
||||
Il ne les traite pas ! Renvoie juste, plutôt rapide
|
||||
|
||||
#### Inconvénient :
|
||||
fragile, si le serveur tombe c'est la merde.
|
||||
|
||||
Fragile, si le serveur tombe c'est la merde.
|
||||
|
||||
|
||||
|
||||
Les ms impliquent de repenser l'équipe de dev, qui s'oriente autour des fonctionnalités et non des compétence smétier. on a aussi des petites équipes et une orientation servis = un produit
|
||||
|
||||
|
||||
Les microservices impliquent de repenser l'équipe de dev, qui s'oriente autour des fonctionnalités et non des compétences métier. On a aussi des petites équipes et une orientation un service = un produit
|
||||
|
||||
## Avantages et inconvénients
|
||||
|
||||
### avantages
|
||||
### Avantages
|
||||
|
||||
dévelopements et déploiement indépendant : Petites équipes, différents langages pour chaque service.
|
||||
|
||||
## Démonstration technique
|
||||
- Développements et déploiement indépendants
|
||||
|
||||
- Petites équipes, différents langages pour chaque service.
|
||||
|
|
|
|||
|
|
@ -1,44 +1,50 @@
|
|||
ITIL
|
||||
========================
|
||||
règle des problèmes récurrent en POO
|
||||
===
|
||||
|
||||
objectif : améliorer efficacité
|
||||
Règle des problèmes récurrent en POO
|
||||
|
||||
# Histoir
|
||||
Objectif : améliorer l'efficacité
|
||||
|
||||
années 80 > datacenter se décentraliser et architectures distribuées. Gouvernement royaue uni
|
||||
## Histoire
|
||||
|
||||
Années 80 > Datacenter se décentralise et architectures distribuées. Gouvernement Royaume-Uni
|
||||
|
||||
S'appuie sur 5 publications essentielles
|
||||
|
||||
s'appui sur 5 publicatiosn essentielles
|
||||
- Service Strategy
|
||||
- Service Design
|
||||
- Service Transition
|
||||
- Service Operation
|
||||
- Continual service
|
||||
|
||||
Je suis crevé j'bandonne
|
||||
|
||||
Je suis crevé j'abandonne
|
||||
|
||||
## Gestion infrastructure
|
||||
|
||||
les infra informatique sont gérées par tout ce qui est nécssaire pour fournir service
|
||||
Les infra informatique sont gérées par tout ce qui est nécessaire pour fournir service
|
||||
|
||||
## les experts de l'infra en ITIL
|
||||
|
||||
y aplein d'experts
|
||||
Y a plein d'experts
|
||||
|
||||
# Gestion des accès
|
||||
|
||||
processus d'application de politique de sécu.
|
||||
Processus d'application de politique de sécu.
|
||||
|
||||
# Service desk
|
||||
poitn contact unique entre client et service informatiuqe 'suivi incident ou probleme)= tout contact passe par là
|
||||
en général divisé en niveuax 1/2/3 > service alors dit verticaux
|
||||
on peut aussi les avoir en horizontaux : 1 répond et gère au max sinon réoriente vers un spécialiste
|
||||
jamais un usr contacte un niveua supérieur en direc tou un presta externe
|
||||
|
||||
Point de contact unique entre client et service informatique
|
||||
Suivi incident ou probleme = tout contact passe par là
|
||||
|
||||
En général divisé en niveaux 1/2/3 > Les services sont alors dit verticaux
|
||||
On peut aussi les avoir en horizontaux : 1 répond et gère au max, ou sinon réoriente vers un spécialiste
|
||||
|
||||
Un utilisateur ne contacte jamais un niveau supérieur ou un prestataire en direct
|
||||
|
||||
# Gestion des évènements
|
||||
|
||||
y faut faire roter vers les gens compétent
|
||||
Y faut faire roter vers les gens compétent
|
||||
*(ok alors là j'étais vraiment fatigué je sais même pas ce que j'ai voulu dire)*
|
||||
|
||||
# Gestion des problèmes
|
||||
|
||||
|
|
@ -48,8 +54,8 @@ J'ai rien compris
|
|||
|
||||
# Bouiche
|
||||
|
||||
dit qu'il faut retenir en ITIL que le plus important c'est qu'il faut retenir de ses erreurs
|
||||
Dit qu'il faut retenir en ITIL que le plus important c'est qu'il faut retenir de ses erreurs
|
||||
On enregistre tout, on loggue tout
|
||||
Il y a plusiuers versions d'ITIL
|
||||
ITIL c'est du bon sns, c'est une organisation de service.
|
||||
Il y a plusieurs versions d'ITIL
|
||||
ITIL c'est du bon sens, c'est une organisation de service.
|
||||
Ça apprend à organiser un service desk.
|
||||
|
|
@ -13,6 +13,41 @@ A la base pour gestion stocks, il a fallu l'adapter pour gestion projet. Tudeap,
|
|||
|
||||
# Cours
|
||||
|
||||
**Objectif**
|
||||
### Objectif
|
||||
|
||||
Tendre le flux et mettre en avant les faiblesses d'une ligne de production
|
||||
|
||||
|
||||
|
||||
### Principe
|
||||
|
||||
Tableau à colonne dans lequel sont placées des cartes. Nombre maximum de carte par tableau défini à l'avance. Cartes passent d'une colonne à une autre. On mesure ainsi le **WIP** : Work In Progress
|
||||
|
||||
Il est primordial de mesurer le "lead-time" : temps moyen pour compléter un item. Il devient ainsi plus prévisible (et court) avec le temps.
|
||||
|
||||
|
||||
|
||||
### Étapes
|
||||
|
||||
- Idées : Toutes les idées placées dans colonne 1
|
||||
|
||||
- Sélection : faite à partir idée par le leaeder, placées dans colonne 2
|
||||
|
||||
- Développement : le développeur choisit ses tâches et les place en colonne 3
|
||||
|
||||
- Déploiement : Développeur demande à déployer sa fonctionnalité et la place en colonne 4
|
||||
|
||||
- Validation : Le développeur demande validation par le leader et place la tâche en colonne 5
|
||||
|
||||
|
||||
|
||||
### Avantages/Inconvénients
|
||||
|
||||
| Avantages | Inconvénients |
|
||||
| -------------------------------------------- | --------------------------------------------------------------------------- |
|
||||
| Mise en place progressive de la méthodologie | Besoin de flux simples et de faible intensité |
|
||||
| Points de blocage visibles très tôt | Besoin de fiabilité et de réactivité chez équipe de prod comme fournisseurs |
|
||||
| Collaboration dans l'équipe encouragée | L'organisation doit être de qualité |
|
||||
| Fort impact visuel avec réelle efficacité | Difficile à gérer sur de gros projets |
|
||||
| Facilite la communication | |
|
||||
| Simplicité | |
|
||||
|
|
|
|||
|
|
@ -1,15 +1,18 @@
|
|||
Prince2
|
||||
========================
|
||||
===
|
||||
|
||||
*25/05/18*
|
||||
|
||||
## Bouiche
|
||||
|
||||
si l'outil que tu vas mettre en place présente des changements, mmgmgmgmgm mg mgmgmmgngmnmgnmgng
|
||||
*Y avait un peu de bruit, j'ai noté de que j'ai réussi à comprendre tant bien que mal*
|
||||
|
||||
Si l'outil que tu vas mettre en place présente des changements, mmgmgmgmgm mg mgmgmmgngmnmgnmgng
|
||||
|
||||
- Bin si
|
||||
Bin au niveau vous save zmgnmgngnmgngmngmngmgngnm ?
|
||||
- en France, ? J'ai pas les chiffres mais beaucoup d'entrprise forment leurs employés
|
||||
- en France, ? J'ai pas les chiffres mais beaucoup d'entreprises forment leurs employés
|
||||
|
||||
mnnmngmmngmngmgn
|
||||
- en france ? 1,7%
|
||||
|
||||
- En france ? 1,7%
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
RAD
|
||||
========================
|
||||
===
|
||||
|
||||
*19/04/18*
|
||||
|
||||
**R**apid **A**pplication **D**evelopment
|
||||
|
|
@ -25,7 +26,7 @@ Y a plusieurs phases, avec des documents liés à chacune.
|
|||
|
||||
### Inconvénients du RAD
|
||||
|
||||
Il parle de recherche d'emploi, je sais pas pouruqoi. Das l'idée, ça fait partie des grosses compétences recherchées dnas le métier :
|
||||
Il parle de recherche d'emploi, je sais pas pourquoi. Dans l'idée, ça fait partie des grosses compétences recherchées dans le métier :
|
||||
|
||||
- gestion de projet
|
||||
- rigueur et méthode
|
||||
|
|
@ -45,4 +46,3 @@ Après RAD2 sont arrivé des méthodes liées
|
|||
* SCRUM
|
||||
* UP
|
||||
* ASD et FDD
|
||||
|
||||
|
|
|
|||
|
|
@ -1,81 +1,77 @@
|
|||
SOA
|
||||
========================
|
||||
===
|
||||
|
||||
Service Oriented Architecture
|
||||
|
||||
## HistoriqueHistorique
|
||||
|
||||
jusqu 90, les trucs étaient sur des gros serveurs (mainframe) en arhci monolothiques
|
||||
Jusqu 90, les trucs étaient sur des gros serveurs (mainframe) en archi monolothiques
|
||||
|
||||
en 90 est apparu le client/serveur avec l'appartition / la démocratisation des PC
|
||||
Puis distribué années 2000
|
||||
En 90 est apparu le client/serveur avec l'appartition / la démocratisation des PC
|
||||
Puis distribué dans les années 2000
|
||||
|
||||
### Client / serveur
|
||||
|
||||
soit cnetré sur le client, soit centré su rle servur. Schéma sur PDF. Réseau entre es dux, l'un a plus de charge que l'autre.
|
||||
Le problèm : dépendances, biblioth_ques, api à importer...
|
||||
|
||||
|
||||
#### Application web
|
||||
|
||||
Très ouvertes/ fcails à déplyer
|
||||
Très ouvertes / faciles à déployer
|
||||
|
||||
#### cloud computing
|
||||
#### Cloud computing
|
||||
|
||||
Location d'ordi pour que les autres se dédouanent de la gestion
|
||||
|
||||
|
||||
|
||||
Ca a été très centralisé, puis moins avec client/serveur, puis on es tpassé au distribué
|
||||
Ça a été très centralisé, puis moins avec client/serveur, puis on est passé au distribué
|
||||
|
||||
## Les architectures de service
|
||||
|
||||
### Principaux composants
|
||||
|
||||
Un service : un composant, une fonctionnalité d'un SI mis à disposition ds clients.
|
||||
Il fonctionne ne boite noire : on se fout de savoir comment il fonctionne. On le vuet performant, robuste, et indépendant de notre contexte (n tant que client)
|
||||
Un service : un composant, une fonctionnalité d'un SI mis à disposition des clients.
|
||||
Il fonctionne en boîte noire : on se fout de savoir comment il fonctionne. On le veut performant, robuste, et indépendant de notre contexte (en tant que client)
|
||||
|
||||
### solution métier
|
||||
L'utilisateur ne s'intéresse pas au service mais à l'applicatio qui utilise ce service. On en a deux la backend et la frontend. Tout ça compose la "solution métier"
|
||||
### Solution métier
|
||||
|
||||
L'utilisateur ne s'intéresse pas au service mais à l'application qui utilise ce service. On en a deux : la backend et la frontend. Tout ça compose la "solution métier"
|
||||
|
||||
### SOA 1.0
|
||||
|
||||
né dnas les années 2000. Première génération
|
||||
Né d'un besoin fort de se connecter ua beosin.
|
||||
Né dans les années 2000. Première génération
|
||||
Né d'un besoin fort de se connecter au besoin.
|
||||
|
||||
avantage : ouverture du SI
|
||||
inconvénient : les dev ont pris le monoplithe tel quel et mis des servics autour : pas de robustesse et de performance
|
||||
Avantage : ouverture du SI
|
||||
Inconvénient : les dev ont pris le monolithe tel quel et mis des services autour : pas de robustesse et de performance
|
||||
|
||||
### SOA 2.0
|
||||
|
||||
architecture microservice
|
||||
Architecture microservice
|
||||
|
||||
ce qui change, c'est la façon de voir son entreprise :
|
||||
chaque section devient un service. Vision "verticale"
|
||||
Ce qui change, c'est la façon de voir son entreprise : chaque section devient un service. Vision "verticale"
|
||||
|
||||
inconvénient : le microservice a une durée de vie courte. Ca change très vite, faut pouvoir suivre la cadence. plein de services dans des technos différentes,
|
||||
Inconvénient : le microservice a une durée de vie courte. Ça change très vite, faut pouvoir suivre la cadence. Plein de services dans des technos différentes,
|
||||
|
||||
### SOA 3.0
|
||||
|
||||
devient un truc de mode : tout le monde en veut et veut un truc multi partenaires
|
||||
Avec l'essort des objets connectés on évolue vers des archis plus reactives et besoin de temps réel
|
||||
Devient un truc de mode : tout le monde en veut et veut un truc multi-partenaires
|
||||
Avec l'essort des objets connectés on évolue vers des archis plus réactives et besoin de temps réel
|
||||
|
||||
on rajoute par rapport à la précédent eune couche IoT, qui communiquera directement avec les obj connectés, et plusieurs gestionnaires, APÏ pour interface rles différents servies entre eux, ainsi qu'un gestionnaire d'PAI.
|
||||
On rajoute par rapport à la précédente une couche IoT, qui communiquera directement avec les objets connectés, et plusieurs gestionnaires, API pour interfacer les différents servies entre eux, ainsi qu'un gestionnaire d'API.
|
||||
|
||||
on a encore deux parties front/back
|
||||
On a encore deux parties front/back
|
||||
|
||||
Archi plus complexe car besoins ont évolué
|
||||
Architecture plus complexe car besoins ont évolué
|
||||
|
||||
## Idées reçues
|
||||
|
||||
SOA liée à techno ou protocole particuliers : ** FAUX**
|
||||
Lié à un outil : **FAUX** (si on utilise par exemple un esp, un répartisseur de mssage utilisé par quelqu'un d'autre en SOA, il ne sera pas forcément en SOA)
|
||||
SOA est liée à une techno ou un protocole particulier : **FAUX**
|
||||
Lié à un outil : **FAUX** (si on utilise par exemple un esp, un répartisseur de message utilisé par quelqu'un d'autre en SOA, il ne sera pas forcément en SOA)
|
||||
SOA n'est pas égal à webservice ou microservice
|
||||
Un webservice n'est pas non plus un SOA
|
||||
SOA se réfléchi, c'est pas adapté à tout
|
||||
|
||||
|
||||
## Conclusion
|
||||
|
||||
SOA c'est un esemble de concepts et de pratqiues qui permettent de mettre en place une architecture.
|
||||
Nécessite d eraisonner sur archi de l'application, la méthodologie mise ne oeuvre. Et tout organisation n'est pas adapté au SOA
|
||||
SOA c'est un esemble de concepts et de pratiques qui permettent de mettre en place une architecture.
|
||||
Nécessite de raisonner sur archi de l'application, la méthodologie mise en oeuvre. Et toute organisation n'est pas adaptée au SOA
|
||||
|
|
|
|||
|
|
@ -1,36 +1,38 @@
|
|||
# Scrum
|
||||
|
||||
*25/05/18*
|
||||
|
||||
# Exposé
|
||||
## Exposé
|
||||
|
||||
## Définition
|
||||
### Définition
|
||||
|
||||
Permet de résoudre problèmes complexes
|
||||
Axé notamment sur la création de valeur
|
||||
|
||||
## Rôles
|
||||
### Rôles
|
||||
|
||||
product owner > joue le rôle du client
|
||||
scrum master > chef de projet
|
||||
équipe de dev > indéterminée, pas de hiérarchie interne.
|
||||
|
||||
## Sprint
|
||||
### Sprint
|
||||
|
||||
Mini projet qui dure un mois. Date de début et date de fin définies.
|
||||
Évite le cycle en V : pas de retour en arrière par rapport aux étapes d'avant, on évolue plutôt.
|
||||
|
||||
## Sprint planification
|
||||
### Sprint planification
|
||||
|
||||
L'équipe s'autogère et prévoit elle meme en moins de 8 heure de ce qu'elle va faire pendant ce sprint
|
||||
|
||||
## Melee quotidienne
|
||||
### Melee quotidienne
|
||||
|
||||
Réunion quotidienne de 15min pour faire le point entre tous et bilan de la veille.
|
||||
|
||||
# Cours
|
||||
## Cours
|
||||
|
||||
Fondé sur méthode agile
|
||||
|
||||
**Trois axes principaux**
|
||||
### **Trois axes principaux**
|
||||
|
||||
- Transparence
|
||||
|
||||
|
|
@ -38,11 +40,11 @@ Fondé sur méthode agile
|
|||
|
||||
- Adaptation
|
||||
|
||||
**Objectif**
|
||||
### **Objectif**
|
||||
|
||||
Livrer rapidement un produit même partiel répondant aux attentes (ou partie), et l'améliorer.
|
||||
|
||||
**Avantage/Inconvénients**
|
||||
### **Avantage/Inconvénients**
|
||||
|
||||
| Avantages | Inconvénients |
|
||||
| ------------------------------------------------------- | -------------------------------- |
|
||||
|
|
@ -53,7 +55,7 @@ Livrer rapidement un produit même partiel répondant aux attentes (ou partie),
|
|||
| Meilleur rendement via répartition de la responsabilité | |
|
||||
| Facilitation de la communication dans le groupe projet | |
|
||||
|
||||
**Acteurs**
|
||||
### **Acteurs**
|
||||
|
||||
- Product Owner : représente le client, gestion du "backlog de produit"
|
||||
|
||||
|
|
@ -61,7 +63,7 @@ Livrer rapidement un produit même partiel répondant aux attentes (ou partie),
|
|||
|
||||
- Équipe : pas de rôle prédéfini car en autogestion, pas de hierarchie interne, en charge de la production de l'incrément
|
||||
|
||||
**Planification**
|
||||
### **Planification**
|
||||
|
||||
- Backlog produit : liste des fonctionnalités attendues d'un produit. Évolue dans le temps // Product Owner
|
||||
|
||||
|
|
|
|||
|
|
@ -1,43 +1,46 @@
|
|||
XP
|
||||
========================
|
||||
===
|
||||
|
||||
Rappels d'agiles
|
||||
|
||||
Historique
|
||||
|
||||
créé en 1999 par 3 chefs de projet . débuté en 96 à la bas eun système de calcul des rémunéraitons
|
||||
Créé en 1999 par 3 chefs de projet . Débuté en 96, à la base un système de calcul des rémunérations
|
||||
Doit être le plus simple possible : KISS
|
||||
|
||||
Principe : faire simple et efficace au plus possible.
|
||||
|
||||
travail direct avec le client sur des cycles très court. travail en binôme
|
||||
Méthode non révolutionnair,e mais pousse les 12 principes d'agile à l'extrême
|
||||
Travail direct avec le client sur des cycles très courts. Travail en binôme
|
||||
|
||||
Méthode non révolutionnaire, mais pousse les 12 principes d'agile à l'extrême
|
||||
|
||||
## Valeurs
|
||||
tout le monde travaille ensmbl : bcp de communication et de respect. Autorité très respectée
|
||||
|
||||
Tout le monde travaille ensemble : beaucoup de communication et de respect. Autorité très respectée
|
||||
Faire simple
|
||||
|
||||
tests d'acceptance sont réalisés par le clint
|
||||
tests unitaires sont utilisés par toutes méthodes d'agile
|
||||
Tests d'acceptance sont réalisés par le client
|
||||
Tests unitaires sont utilisés par toutes méthodes d'agile
|
||||
|
||||
## Pratiques
|
||||
|
||||
Le dev se préoccupe donc pas du produit final, mais just du dev. En cas d'erreur ils ont toujours les feedboack
|
||||
réunions fréquente sou pas mal de trucs sont décidés (planning game)
|
||||
client très intégré, il srt de "beta tester"
|
||||
metaphore : scénario global qui sert de
|
||||
rythmr : pas plus de 40h de travail par semaine
|
||||
convention de nommage unique pour tout l'équipe pour garantir compréhension du code
|
||||
Réunions fréquentes où pas mal de trucs sont décidés (planning game)
|
||||
Client très intégré, il sert de "beta tester"
|
||||
Métaphore : scénario global qui sert de
|
||||
Rythme : pas plus de 40h de travail par semaine
|
||||
Convention de nommage unique pour toute l'équipe pour garantir compréhension du code
|
||||
|
||||
## roles
|
||||
## Rôles
|
||||
|
||||
petites équipes en XP (5 max)
|
||||
vérificateur s'assure que la commmunication dnas l'équipe est ok, peut éve,tuellmeent demander aide
|
||||
client écrit les user story
|
||||
développeur définissent tache ingénirie, tmps pour les fair,e iplémntent stories et test unitaires
|
||||
tester implémente les test fonctionnles réalisés
|
||||
coach planifie les réunions, note résultats, est le mentor de l'équipe mais ne dit pas comment travailler. Supervise mais chacun reste autonome
|
||||
Petites équipes en XP (5 max)
|
||||
Vérificateur s'assure que la commmunication dans l'équipe est ok, peut éventuellement demander de l'aide
|
||||
Client écrit les user story
|
||||
Développeurs définissent les tâche d'ingénierie, le temps pour les faire, implémentent les stories et font les tests unitaires
|
||||
Testeur implémente les tests fonctionnels réalisés
|
||||
Coach planifie les réunions, note les résultats, est le mentor de l'équipe mais ne dit pas comment travailler. Supervise mais chacun reste autonome => EQUIPE EN RÉSEAU, EH OUAIS MAGUEULE
|
||||
|
||||
Un membre de l'équipe peut avoir plusieurs roles (tout n'est pas compatible)
|
||||
Un membre de l'équipe peut avoir plusieurs rôles (tout n'est pas compatible)
|
||||
|
||||
## Planification et gestion
|
||||
|
||||
|
|
@ -45,11 +48,11 @@ Un planning de livraison est réalisé permettant de réaliser un planning d'it
|
|||
|
||||
## Conception et développement
|
||||
|
||||
on les garde simple : on se base sur une petite partie à chaque fois.
|
||||
solutions pointues pour réduire erreurs et éviter d'ajouter fonctionnalités inutiles : on vise l'utile à l'instant t
|
||||
On les garde simple : on se base sur une petite partie à chaque fois.
|
||||
Solutions pointues pour réduire erreurs et éviter d'ajouter fonctionnalités inutiles : on vise l'utile à l'instant *t*
|
||||
|
||||
## Recommandations
|
||||
|
||||
une rétrospective au moins toutes les 3 itérations
|
||||
Une rétrospective au moins toutes les 3 itérations
|
||||
|
||||
une des méthodo les plus utilisées
|
||||
Une des méthodo les plus utilisées
|
||||
|
|
|
|||
Loading…
Reference in a new issue