La définition du contexte d'un projet web ou mobile est d'une importance capitale pour le succès global du projet, notamment après la réception du RFP (Request for Proposal) ou CPS du client. Le contexte du projet englobe les circonstances, les objectifs, les contraintes et les besoins spécifiques qui entourent le projet. Voici un exemple cas concrète spécifique qui montre comment la définition précise du contexte peut influencer le succès du projet de développement mobile / web:

1 - Contexte du projet : 

D'après notre compréhension du besoin tel que spécifié dans le CPS fournit par Client A:

• Le but de ce projet est la création d’un portail application web pour offrir aux clients et partenaires d'accès au services et fonctionnalités business et ainsi améliorer l'expérience des clients.
• Le service doit offrir une expérience simple, l’interface doit être ergonomique coté UI/UX. l’application doit être performante et sécurisée (architecture, code, infrastructure).
• En plus de permettre aux clients de gérer leur compte et suivi des transactions, l’application offrira des services répondant à la croissance des demandes en ligne: demande des tarifs, enregistrement et validation des commandes, coordination des livraisons, et communication interne avec l’équipe relation clients.
• Le portail doit être intégré au système interne ERP pour la synchronisation des données et l'automatisation des processus tels que: commandes, tickets, factures ..
• Le portail doit être sécurisé pour assurer la protection et la confidentialité totale des données utilisateurs (commandes, identifiants, livraisons .. ), sur tous les plans: architecture, code, base de données, APIs, infrastructure et serveurs.
• Le portail doit être flexible et scalable avec la demande et la croissance des utilisateurs et doit s’adapter aux besoins des évolutions futures. On doit prévoir la possibilité d'intégration de la solution avec différents systèmes (internes ou externes). 
• .......

2- Diagramme fonctionnel: User stories

Ensuite, il faut définir les types des utilisateurs du système, et le digramme fonctionnel qui se définit par des actions:

L’ Admin (super admin de tous les comptes) peut

•  Ajouter les clients disposant d’un compte CIMA dans le système: Création de compte par invitation en utilisant le mail ou mobile.
• Lister et gérer les comptes clients.
• ....

L’ Utilisateur 

Type 1: Client en compte A peut

• Accepter la demande d’invitation (réception d’identifiant dans email ou validation en deux étapes SMS).
• S’identifier dans le lien de portail (/login) en insérant son identifiant et mot de passe.
• Ajouter/Modifier/Lister/Rechercher des clients (individu, entreprise) dans son carnet d'adresse destinataires.
• Paramètrer des sous comptes utilisateurs pour leurs donner accès.
• ......

Diagramme fonctionnel

3- Diagramme de séquence

Ensuite, Vous pouvez définir l'enchainement des actions de l'expérience utilisateur dans le système par un digramme séquentiel qui se définit par des actions:

Diagramme de séquence

4- Architecture choisi: Module et Service 

Définir le type d'architecture choisie pour la solution: Généralement à trois niveaux: Couche front end (présentation UI/UX), Backend des services API qui seront consommés par l’application ou toute application éligible, et la couche base de données.

Le conteneur de code monolith va être composé de services et modules, chacun est responsable d’une logique métier spécifique.

Ex: Account Service est responsable de création et gestion de comptes clients.

Chaque module doit être indépendant du stack ou framework d'implémentation et doit comprendre: Une interface in/out, une couche validation et de sanitization des données pour assurer une haute sécurité, la logique cœur métier et une couche d'accès au données.

Pourquoi une architecture modulaire ?

• Chaque module est responsable de sa propre logique métier.
• Bonne architecture du code.
• Cohésion de la logique métier dans l’unité responsable.
• Découplage et minimisation des dépendances entre modules.
• Chaque module encapsule sa couche de données (migrations et accès)
• Scalabilité future et portabilité du module.
• Les modules communiquent par une interface standard, qui cache l'implémentation interne du code.
• Chaque module peut être implémenté par une stack différentes (PHP, Python, Javascript).
• Chaque service pourrait elle-même être migrée sur son propre monolith ou devenir micro-service.

Diagramme d'un module de service

Nous allons voir dans une partie 2 les spécifications à définir en design du système, déploiement, performance et disponibilité.

Développement des projets à Devinweb

Une équipe TECHNIQUE dédiée à plein temps pour prendre le relais des projets numériques du partenaire:

• Nous vous recommandons la meilleure équipe qui a une expérience relative qui correspond à votre produit.
• Un chef de projet formera la bonne équipe et dessinera la feuille de route et le champ d'application. Une planification grâce à des méthodologies agiles en Sprint pour garantir une livraison et transparence totale en partageant les rapports et les avancements avec le client.