Developing information systems

# Developing information systems ## Objectifs et prérequis Ce chapitre vise à fournir aux élèves de Upper Sixth une compréhension approfondie du cycle de vie des systèmes d'information, en mettant l'accent sur les processus de développement, les outils de conception, les méthodes de test et la gestion opérationnelle. À l'issue de ce cours, l'élève sera capable de : - Décrire les étapes du processus de développement d'un système d'information (SDLC) et justifier le choix d'un modèle adapté. - Utiliser des outils de conception (DFD, ERD, UML) pour modéliser les besoins fonctionnels et non fonctionnels d'un système. - Élaborer un plan de test complet (unitaires, d'intégration, système, d'acceptation) et interpréter les résultats. - Appliquer les principes de gestion des systèmes d'information (maintenance, évolution, sécurité, formation) pour assurer leur pérennité. Prérequis : notions de base en algorithmique, bases de données relationnelles, et concepts généraux d'informatique (matériel, logiciel, réseau). ## Introduction Dans le contexte camerounais et africain, où la digitalisation des services publics et privés s'accélère, la capacité à concevoir, développer et gérer des systèmes d'information fiables est devenue une compétence stratégique. Ce chapitre ne se limite pas à une approche théorique : il s'appuie sur des exemples concrets issus de secteurs locaux (santé, éducation, agriculture, administration) pour illustrer chaque concept. L'accent est mis sur la rigueur méthodologique, la pertinence des outils et l'importance du suivi post-déploiement, souvent négligé mais crucial pour la réussite d'un projet. ## I. System Development Process ### Définition et objectifs > Le processus de développement d'un système d'information (System Development Process ou SDLC - Software Development Life Cycle) est une séquence structurée d'activités visant à concevoir, développer, tester, déployer et maintenir un système répondant à des besoins métier spécifiques, dans le respect des contraintes de temps, de coût et de qualité. Ce processus transforme un besoin non formalisé en une solution technique opérationnelle. Il garantit la traçabilité entre les exigences initiales et le produit final, réduit les risques d'échec et facilite la communication entre les parties prenantes (utilisateurs, développeurs, gestionnaires). ### Modèles de SDLC Plusieurs modèles existent, chacun adapté à des contextes différents : #### Modèle en cascade (Waterfall) - **Définition** : Modèle linéaire et séquentiel où chaque phase doit être entièrement achevée avant de passer à la suivante. - **Phases** : Analyse des besoins → Conception → Implémentation → Test → Déploiement → Maintenance. - **Propriétés** : Simple à comprendre, facile à gérer, mais rigide. Peu adapté aux besoins évolutifs. - **Exemple résolu** : Un ministère de l'Éducation souhaite développer un système de gestion des notes scolaires. Les besoins sont clairement définis (entrées : notes des élèves, sorties : bulletins, moyennes). Aucun changement majeur n'est attendu pendant le développement. Le modèle en cascade est choisi. - *Étape 1* : Recueil des besoins auprès des proviseurs et enseignants (2 semaines). - *Étape 2* : Rédaction du cahier des charges fonctionnel et technique. - *Étape 3* : Conception de l'architecture (base de données, interfaces). - *Étape 4* : Développement en Java/PHP. - *Étape 5* : Tests unitaires puis d'intégration. - *Étape 6* : Déploiement dans 50 écoles pilotes. - *Étape 7* : Formation des utilisateurs et maintenance corrective pendant 6 mois. - **Limitation** : Si un besoin change (ex : ajout de la gestion des absences), il faut revenir à l'analyse, ce qui coûte cher et prend du temps. #### Modèle itératif et incrémental - **Définition** : Le système est développé par cycles successifs (itérations), chaque itération livrant une version fonctionnelle partiellement complète du produit. - **Propriétés** : Permet des retours précoces des utilisateurs, réduit les risques d'erreur majeure, s'adapte aux changements. - **Exemple résolu** : Une startup agricole veut une application mobile pour suivre les rendements des champs. - *Itération 1* : Saisie manuelle des rendements par champ et génération d'un tableau de bord simple (livré en 1 mois). - *Itération 2* : Ajout de la géolocalisation via GPS et alertes sur les faibles rendements (livré en 2 mois). - *Itération 3* : Intégration avec météo locale et recommandations d'engrais (livré en 3 mois). - À chaque itération, les utilisateurs testent et donnent du feedback. Le produit évolue vers la version finale. - **Avantage** : Si la météo change soudainement et rend une fonctionnalité moins pertinente, elle peut être ajustée sans tout reprendre. #### Modèle en spirale - **Définition** : Combine développement itératif et analyse systématique des risques. Chaque boucle comprend : détermination des objectifs, évaluation des risques, développement et test, planification de la prochaine itération. - **Propriétés** : Idéal pour les projets complexes, à haut risque (ex : systèmes de défense, santé). - **Exemple résolu** : Un hôpital régional souhaite un système de gestion des dossiers patients intégré aux appareils médicaux. - *Boucle 1* : Analyse des risques liés à la confidentialité des données (RGPD-like). Prototypage d'un module d'authentification. - *Boucle 2* : Test de sécurité sur le module d'authentification. Développement du module de saisie des signes vitaux. - *Boucle 3* : Évaluation du risque d'interopérabilité avec les appareils. Intégration d'une norme HL7. - Chaque boucle réduit un risque majeur avant de passer à la suivante. #### Modèle Agile (Scrum) - **Définition** : Approche itérative et incrémentale centrée sur la collaboration, l'adaptabilité et la livraison fréquente de valeur. Utilise des sprints (cycles de 2-4 semaines), des réunions quotidiennes, et un backlog priorisé. - **Propriétés** : Très réactif aux changements, favorise l'implication des utilisateurs, nécessite une culture d'équipe mature. - **Exemple résolu** : Une ONG veut une plateforme de suivi des dons en temps réel. - *Sprint 1* (2 semaines) : Livraison du formulaire de don et affichage du total collecté. - *Sprint 2* : Ajout de la possibilité de commenter les dons et affichage par région. - *Sprint 3* : Génération automatique de reçus fiscaux PDF. - À la fin de chaque sprint, une revue avec les donateurs et les équipes terrain permet d'ajuster le backlog. - **Outils utilisés** : Jira, Trello, tableaux Kanban. ### Choix du modèle Le choix dépend de : - **Stabilité des besoins** : Cascade si fixes, Agile/itératif si évolutifs. - **Taille et complexité du projet** : Spirale pour les gros projets à risque. - **Compétences de l'équipe** : Agile nécessite de l'expérience en collaboration. - **Contraintes de temps** : Incrémental permet une livraison précoce de valeur. - **Culture organisationnelle** : Certaines administrations préfèrent la rigueur du cascade. > À retenir : Aucun modèle n'est universellement supérieur. Le bon choix résulte de l'analyse du contexte projet, pas d'une préférence idéologique. ### Exercices d'application corrigés **Exercice 1** : Une université veut remplacer son système d'inscription en ligne par une nouvelle plateforme permettant aussi le paiement des frais et l'accès aux ressources numériques. Les besoins sont partiellement connus : l'inscription est urgente pour la prochaine rentrée, mais les fonctionnalités de paiement et de ressources pourraient évoluer selon les retours des étudiants. Quel modèle de SDLC recommanderiez-vous et pourquoi ? *Correction* : Modèle itératif et incrémental. - *Justification* : Le besoin d'inscription est stable et urgent → première incrément. - Les fonctionnalités de paiement et de ressources sont susceptibles d'évoluer → développées en itérations suivantes après feedback. - Permet de lancer une version minimale viable (inscription seulement) à temps pour la rentrée, puis d'enrichir le système. - Évite les risques du cascade (blocage si un besoin change) et la surcharge du spirale (trop lourd pour ce niveau de risque). **Exercice 2** : Un projet de système de gestion des stocks pour une coopérative agricole utilise le modèle en cascade. Après la phase de conception, les utilisateurs réalisent qu'ils ont besoin d'une fonctionnalité de suivi des lots par numéro de série pour respecter les normes d'export. Que se passe-t-il et quelle est la meilleure solution ? *Correction* : - Dans le modèle en cascade, revenir à l'analyse des besoins après la conception est coûteux et retardant : il faut refaire la conception, puis l'implémentation, etc. - Meilleure solution : reconnaître que le modèle en cascade est inadapté ici. Passer à un modèle itératif (ex : Scrum) pour intégrer cette nouvelle exigence dans une prochaine itération sans tout reprendre. - Alternativement, si le contrat l'impose, faire une demande de changement formelle (avec réévaluation des coûts et délais), mais cela reste lourd. ## II. System Design Tools ### Introduction Une fois les besoins analysés, la phase de conception traduit les exigences fonctionnelles et non fonctionnelles en une spécification technique pouvant être implémentée. Les outils de modélisation permettent de représenter le système sous différents angles (données, processus, objets) pour garantir la cohérence, faciliter la communication et réduire les ambiguïtés. ### 1. Diagrammes de flux de données (DFD - Data Flow Diagrams) > Un DFD représente le mouvement des données entre les entités externes, les processus et les réserves de données dans un système. Il ne montre pas le contrôle ou le timing, mais uniquement ce qui arrive, où il va, et où il est stocké. - **Notations** : - Entité externe : carré (source ou destination des données, hors du système). - Processus : cercle ou rectangle arrondi (transforme les données entrantes en données sortantes). - Réserve de données : deux lignes parallèles (stocke les données, ex : base de données, fichier). - Flux de données : flèche nommée (indique le type de donnée échangée). - **Niveaux** : - DFD niveau 0 (contexte) : montre le système entier comme un seul processus, avec ses interactions avec les entités externes. - DFD niveau 1 : décompose le processus du niveau 0 en sous-processus majeurs (généralement 3 à 7). - DFD niveau 2+ : décomposition supplémentaire si nécessaire. - **Règles de cohérence** : - Chaque flux de données entrant dans un processus doit avoir une signification pour ce processus. - Chaque flux de données sortant d'un processus doit être dérivé de ses entrées. - Les réserves de données doivent être liées à au moins un processus (lecture ou écriture). - **Exemple résolu** : Système de bibliothèque scolaire. - *Entités externes* : Étudiant, Bibliothecaire. - *Réserves de données* : Livres, Emprunts. - *Processus* : Rechercher livre, Enregistrer emprunt, Retourner livre, Générer rappel. - *DFD niveau 0* : - Étudiant → [Système de bibliothèque] → Bibliothecaire - Flux : Demande de livre (Étudiant → Système), Résultat recherche (Système → Étudiant), Détails emprunt (Système → Bibliothecaire), Confirmation retour (Bibliothecaire → Système), Alerte retard (Système → Étudiant). - *DFD niveau 1* (décomposition du processus "Système de bibliothèque") : - Processus 1.0 : Rechercher livre - Entrées : Demande de livre (Étudiant), Catalogue (Réserve Livres) - Sorties : Résultat recherche (Étudiant) - Processus 2.0 : Enregistrer emprunt - Entrées : Détails emprunt (Bibliothecaire), Livre disponible (Réserve Livres) - Sorties : Emprunt enregistré (Réserve Emprunts), Confirmation emprunt (Bibliothecaire) - Processus 3.0 : Retourner livre - Entrées : Livre retourné (Étudiant), Emprunt existant (Réserve Emprunts) - Sorties : Livre disponible (Réserve Livres), Confirmation retour (Bibliothecaire) - Processus 4.0 : Générer rappel - Entrées : Emprunts en retard (Réserve Emprunts) - Sorties : Alerte retard (Étudiant) - **Exercice d'application corrigé** : *Construire le DFD niveau 0 et niveau 1 pour un système de gestion des rendez-vous médicaux dans un centre de santé. Entités : Patient, Médecin, Réceptionniste. Réserves : Patients, Rendez-vous. Processus : Prendre rendez-vous, Annuler rendez-vous, Consulter agenda, Envoyer rappel.* *Correction* : - Niveau 0 : - Patient → [Système de rendez-vous] → Médecin - Réceptionniste → [Système de rendez-vous] → Système - Flux : Demande RDV (Patient → Système), Confirmation RDV (Système → Patient), Annulation (Réceptionniste → Système), Agenda mis à jour (Système → Médecin), Rappel envoyé (Système → Patient). - Niveau 1 : - P1.0 : Prendre rendez-vous - Entrées : Demande RDV (Patient), Créneaux disponibles (Réserve Rendez-vous) - Sorties : RDV confirmé (Réserve Rendez-vous), Confirmation RDV (Patient) - P2.0 : Annuler rendez-vous - Entrées : Demande annulation (Réceptionniste), RDV existant (Réserve Rendez-vous) - Sorties : RDV annulé (Réserve Rendez-vous), Confirmation annulation (Réceptionniste) - P3.0 : Consulter agenda - Entrées : Demande agenda (Médecin), RDV du jour (Réserve Rendez-vous) - Sorties : Agenda du jour (Médecin) - P4.0 : Envoyer rappel - Entrées : RDV à venir (Réserve Rendez-vous), Heure actuelle (horloge système) - Sorties : Rappel envoyé (Patient) ### 2. Diagrammes Entité-Relation (ERD - Entity-Relationship Diagram) > Un ERD modélise la structure statique des données d'un système en représentant les entités (objets du monde réel), leurs attributs et les relations entre elles. Il sert de base à la conception d'une base de données relationnelle. - **Notations** (modèle de Chen ou Crow's Foot) : - Entité : rectangle (nom de l'entité au singulier, ex : Étudiant). - Attribut : ovale lié à l'entité par une ligne. - Clé primaire : attribut souligné. - Relation : losange (verbe décrivant l'association, ex : emprunte). - Cardinalité : indique combien d'instances d'une entité peuvent être associées à une instance de l'autre. - 1:1 (un à un) - 1:N (un à plusieurs) - N:M (plusieurs à plusieurs) → nécessite une table d'association. - **Étapes de construction** : 1. Identifier les entités à partir des noms substantifs du cahier des charges. 2. Déterminer les attributs de chaque entité (y compris les clés). 3. Trouver les relations entre entités à partir des verbes d'action. 4. Déterminer la cardinalité et la participation (obligatoire/optionnelle). 5. Vérifier l'absence de redondance et appliquer les règles de normalisation si nécessaire. - **Exemple résolu** : Système de gestion scolaire. - *Entités* : Étudiant, Cours, Enseignant, Inscription. - *Attributs* : - Étudiant : id_étudiant (PK), nom, prénom, date_naissance, email. - Cours : id_cours (PK), nom_cours, crédits, niveau. - Enseignant : id_enseignant (PK), nom, prénom, spécialité. - Inscription : id_inscription (PK), date_inscription, note. - *Relations* : - Étudiant **inscrit** à Cours → relation *Inscription* (N:M entre Étudiant et Cours). - Cardinalité : Un étudiant peut s'inscrire à plusieurs cours (N), un cours peut avoir plusieurs étudiants (N). - Participation : Optionnelle pour Étudiant (peut ne pas s'inscrire), optionnelle pour Cours (peut n'avoir aucun inscrit). - Enseignant **enseigne** Cours → relation *Enseigne* (1:N entre Enseignant et Cours). - Cardinalité : Un enseignant peut enseigner plusieurs cours (N), un cours est enseigné par un seul enseignant (1). - Participation : Obligatoire pour Cours (doit avoir un enseignant), optionnelle pour Enseignant (peut ne pas enseigner ce semestre). - *ERD* : - Étudiant <--(N) Inscription (N)--> Cours - Enseignant <--(1) Enseigne (N)--> Cours - Attributs de Inscription : id_inscription (PK), date_inscription, note. - Attributs de Enseigne : aucun (relation simple), ou on pourrait ajouter semestre, année académique comme attributs de la relation. - **Exercice d'application corrigé** : *Modéliser en ERD un système de gestion des ventes pour une boulangerie. Entités : Client, Produit, Vente, Ligne de vente. Un client peut effectuer plusieurs ventes. Une vente contient plusieurs lignes de vente (un produit avec quantité). Un produit peut apparaître dans plusieurs lignes de vente (différentes ventes).* *Correction* : - Entités : - Client : id_client (PK), nom, téléphone. - Produit : id_produit (PK), nom, prix_unitaire, catégorie. - Vente : id_vente (PK), date_vente, total. - Ligne de vente : id_ligne (PK), quantité, prix_ligne. - Relations : - Client **effectue** Vente → 1:N (un client peut faire plusieurs ventes, une vente appartient à un seul client). - Vente **contient** Ligne de vente → 1:N (une vente a plusieurs lignes, une ligne appartient à une seule vente). - Produit **est référencé dans** Ligne de vente → N:1 (un produit peut être dans plusieurs lignes, une ligne référence un seul produit). - *Alternative* : Vente et Produit en relation N:M via Ligne de vente comme table d'association. - ERD : - Client <--(1) Effectue (N)--> Vente - Vente <--(1) Contient (N)--> Ligne de vente - Produit <--(1) Référencé dans (N)--> Ligne de vente - Attributs Ligne de vente : quantité, prix_ligne (calculé : quantité × prix_unitaire du Produit, mais souvent stocké pour éviter les recalculs). - *Note* : Le prix_ligne est stocké pour garantir l'historique des prix (si le prix du produit change, les anciennes ventes conservent leur prix d'origine). ### 3. Diagrammes UML (Unified Modeling Language) > UML est un langage de modélisation standardisé qui propose différents types de diagrammes pour représenter les aspects statiques (structure) et dynamiques (comportement) d'un système orienté objet. #### Diagramme de classes - Représente les classes, leurs attributs, leurs méthodes et les relations entre classes (héritage, association, agrégation, composition). - **Notations** : - Classe : rectangle divisé en trois compartiments (nom, attributs, méthodes). - Attribut : -visibilité nom : type = valeur_défaut. - Méthode : +visibilité nom(paramètres) : type_retour. - Association : ligne simple entre deux classes. - Agrégation : losange vide (relation "a un", faible couplage). - Composition : losange noir (relation "fait partie de", fort couplage, durée de vie liée). - Héritage : triangle creux (spécialisation). - **Exemple résolu** : Système de bibliothèque. - Classe *Livre* : -isbn : String, -titre : String, -auteur : String, -disponible : boolean, +emprunter() : void, +retourner() : void. - Classe *Étudiant* : -id : String, -nom : String, -prenom : String, +emprunterLivre(l : Livre) : void. - Classe *Emprunt* : -date_emprunt : Date, -date_retour_prevue : Date, -livre : Livre, -étudiant : Étudiant. - Relations : - Étudiant *emprunte* Livre → association (ou via Emprunt). - Emprunt *contient* Livre → composition (un emprunt n'existe que s'il y a un livre et un étudiant ; si l'emprunt est supprimé, le lien livre-étudiant disparaît, mais le livre et l'étudiant persistent). - Étudiant *a* Emprunt → agrégation (un étudiant peut avoir plusieurs emprunts, mais un emprunt appartient à un seul étudiant). - **Exercice d'application corrigé** : *Décrire en UML classe un système de gestion des comptes bancaires. Classes : Compte, CompteCourant, CompteEpargne, Client, Transaction. Un client peut avoir plusieurs comptes. Un compte peut être courant ou épargne. Une transaction affecte un compte.* *Correction* : - Classe *Client* : -id_client : String, -nom : String, -prenom : String, +ajouterCompte(c : Compte) : void. - Classe *Compte* (abstraite) : -numero : String, -solde : double, +deposer(m : double) : void, +retirer(m : double) : boolean. - Classe *CompteCourant* hérite de Compte : -decouvertAutorise : double, +retirer(m : double) : boolean (vérifie solde + découvert >= m). - Classe *CompteEpargne* hérite de Compte : -tauxInteret : double, +calculerInteret() : double. - Classe *Transaction* : -id : String, -date : Date, -type : String (DEPOT/RETRAIT), -montant : double, -compte : Compte. - Relations : - Client *a* Compte → agrégation (1:N). - CompteCourant *est un* Compte → héritage. - CompteEpargne *est un* Compte → héritage. - Transaction *concerne* Compte → association (1:N du côté Compte). - **Autres diagrammes UML utiles** : - Diagramme de cas d'utilisation : montre les interactions entre acteurs et le système (fonctionnalités). - Diagramme de séquence : montre l'ordre des échanges de messages entre objets au fil du temps. - Diagramme d'activité : représente un flux de travail ou un algorithme (comme un organigramme orienté objet). ### Tableau comparatif des outils de modélisation | Outil | Type de représentation | Meilleur usage | Limitation | |-------|------------------------|----------------|------------| | DFD | Flux de données (processus-centré) | Comprendre qui fait quoi avec quelles données | Ne montre pas la logique de contrôle ni la structure des données en détail | | ERD | Structure des données (entité-centré) | Concevoir la base de données relationnelle | Ne montre pas les processus ou le comportement dynamique | | UML (classes) | Structure objet et relations | Concevoir un système orienté objet, détaillé | Peut être trop détaillé pour les premiers stades ; nécessite une culture OO | > À retenir : Les outils de modélisation sont complémentaires. Un bon concepteur utilise le DFD pour comprendre les flux, l'ERD pour structurer les données, et l'UML pour détailler la logique objet. Aucun ne suffit seul. ### Exercices d'application corrigés **Exercice 1** : Pour un système de suivi des récoltes agricoles (enregistrement des semis, traitements, rendements par parcelle), quel outil de modélisation serait le plus approprié en première étape pour comprendre les interactions entre les acteurs (agriculteur, technicien) et les données (dates, quantités, produits utilisés) ? Justifiez. *Correction* : DFD. - *Justification* : L'objectif est de comprendre qui saisit quelles données, qui les consulte, et comment elles circulent (ex : technicien enregistre traitement → données stockées → agriculteur consulte rendement). Le DFD excelle à représenter ces flux entre acteurs externes, processus et réserves de données. L'ERD serait prématuré (on ne connaît pas encore bien la structure des données), et l'UML trop détaillé pour une première compréhension globale. **Exercice 2** : Dans un ERD pour un système de gestion des prêts universitaires, l'entité "Prêt" est liée à "Étudiant" et à "Livre". Un étudiant peut avoir plusieurs prêts en cours, et un livre peut être prêté à plusieurs étudiants (mais pas en même temps). Quelle est la cardinalité correcte entre Étudiant et Prêt, et entre Livre et Prêt ? Expliquez pourquoi une table d'association n'est pas nécessaire ici. *Correction* : - Entre Étudiant et Prêt : 1:N (un étudiant peut avoir plusieurs prêts, un prêt appartient à un seul étudiant). - Entre Livre et Prêt : 1:N (un livre peut être associé à plusieurs prêts au fil du temps, mais un prêt concerne exactement un livre). - *Pourquoi pas de table d'association ?* Parce que la relation entre Étudiant et Livre est médiée par l'entité Prêt, qui possède ses propres attributs (date_prêt, date_retour_prevue, statut). Si nous avions mis une relation directe N:M entre Étudiant et Livre, nous aurions perdu la capacité à stocker ces attributs du prêt. L'entité Prêt transforme la relation N:M implicite en deux relations 1:N, permettant de conserver l'historique et les détails de chaque transaction de prêt.