« MULTITEAM » : différence entre les versions
| Ligne 82 : | Ligne 82 : | ||
** Les RAML | ** Les RAML | ||
** Mise à jour de l'ADR | ** Mise à jour de l'ADR | ||
** Script de montée de version | |||
** Doc d'archi (DAT ) | |||
** Doc d'exploitant ( DEX ) | |||
** Doc d'installation ( DIN ) | |||
** Doc de migration ( DMV ) | |||
** README DEV () | |||
** Listing des requêtes HTTP | |||
** workflow | |||
** Modèle de données ? | |||
* DoD Validation QA&UX | * DoD Validation QA&UX | ||
** Validation UX design | ** Validation UX design | ||
Version du 6 mai 2024 à 13:06
Présentation de l'équipe
- GHERIBI Lotfi
- RADEAU Daniel
- BERTOUL Raouaa
- SERIR Soufyane
- LEMAIRE Sandrine
- MINY Jean-Marie
- BERNARD Etienne
- TIZAOUI Mohamed
- BENARBIA Benaissa
- PARIS Alexandre
- NAJI Hossame
- ROBERT Maxime
- FATAN Souhaib
- JOSSE Isabelle
- VILLE Marion
- WELLHOFF Leo
Tableau de suivi des présences (Global)
Planning Qualification Support
Procédures
Procédure d'installation Vitam Core pour développement local v.1.0
DOR : Definition Of Ready
- Estimation et criticité doivent être définie
- Le besoin et le context de l'US doit être compris par tous et retranscrit dans la description
- Un maximum de 7 critères d'acceptances
- Les maquettes doivent être à jour et terminées avec un lien FIGMA
- Il faut anticiper les scénarios UX
- Les traductions doivent être présentes
- Les US doivent être découpées en tâches
- Un tech design validé
- Identifier les aspects de refontes
- Identifier le travail sur les TNR
- Identifier le travail sur l'automatisation
- Fournir des jeux de tests et des exemples
- Les dépendances entre US doivent avoir été identifiées
DOD : Definition Of Done
- DoD Développement
- Tous les critères d'acceptances sont implémentés
- Le Build est valide
- Test nominaux sur INT / BAC à sable / Local
- Alimenter le changelog
- Fournir des jeux de données supplémentaires
- Fournir la requête REST pour les tests d'API
- Review du code OK
- DoD Testing
- TU ( Java et/ou Angular )
- TI
- TNR
- End to End auto
- DoD Documentation
- Compléter le Tech Design
- Les RAML
- Mise à jour de l'ADR
- Script de montée de version
- Doc d'archi (DAT )
- Doc d'exploitant ( DEX )
- Doc d'installation ( DIN )
- Doc de migration ( DMV )
- README DEV ()
- Listing des requêtes HTTP
- workflow
- Modèle de données ?
- DoD Validation QA&UX
- Validation UX design
- Validation nominale
- Validation INT
- Validation ITREC
- DoD Validation PO
- Vérification documentaire
- Relecture finale
Outils
Cette section recense les outils à disposition et leur usage dans le cadre du projet
Jenkins
Gestion des tickets
- Artefact USER STORIES est celui du projet
- Artefact DEMANDE PARTENAIRE est à suivre, recopier dans USER STORIES et à répondre aux partenaires
- Artefact Bugs = tickets de Bug de VITAM que notre recetteuse cherche à traiter avec l’Administration et l’équipe de dev.
Contributions (Git)
Sert à suivre les états des MR. Une MR a le numéro du ticket Tuleap dans le titre (doit l'avoir en tout cas, sinon tu ne peux pas savoir si OK ou KO )
NB : Les accès sont gérés par les devOps
Checkmarx
Attention pour s’authentifier, choisir en option le : « VITAM OpenLdap »