Modèles de processus de développement des SI

De Baripedia
Modèles de processus de développement des SI
Faculté Faculté d'économie et de management
Département Services généraux GSEM
Professeur(s) Jolita Ralyte[1]
Cours Gestion de projet

Lectures


Processus de Développement des SI[modifier | modifier le wikicode]

Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.

Le cycle de vie d'un SI décrit succintement les phases par lesquelles passe un système d'information depuis le besoin initial jusqu'au retrait du système, la documentation et les décisions qui jalonnent le cycle.

Activités de développement des SI[modifier | modifier le wikicode]

  • Spécification des exigences et des contraintes du système, établissement du cahier des charges
  • Conception de la solution, production d'un modèle du système à développer
  • Implémentation du système
  • Test du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins
  • Installation du système chez le client et vérification de son fonctionnement
  • Maintenance du système, réparation des fautes

Modèles standards de développement des SI[modifier | modifier le wikicode]

Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les activités/étapes de développement des SI vus dans le point précédent.


Code-and-fix[modifier | modifier le wikicode]

Modèle dirigé par la programmation.

Compréhension du problème -> Programmation -> Test contre spécification -> Fin si satisfait, sinon Mise au point du code et retour au Test contre spécification

Transformation automatique[modifier | modifier le wikicode]

Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.

Ce modèle nécessite un outil logiciel qui fait de telles transformations.

Spécification -> Validation -> Transformation si validé, sinon retour à Spécification.

Cascade / Waterfall[modifier | modifier le wikicode]

Processus de développement en cascade/waterfall

Processus de nature plutôt linéaire, centré activités avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière. Ce modèle est hérité de l'industrie lourde (construction de bâtiments, usines, etc.). Les phases nécessitent de plus en plus de ressources. Ce modèle est donc plus adapté aux grands projets de développement qui n'offrent que peu de possibilités d'interactions avec tous les membres de l'équipe qui dépassent la centaine.

Initiation - Étude de faisabilité[modifier | modifier le wikicode]

  • Analyser le problème
  • Définir les objectifs
  • Définir les frontières du système
  • Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)
  • Évaluer la faisabilité technique, économique, opérationnelle.

Spécification des exigences[modifier | modifier le wikicode]

  • Définir le périmètre du SI
  • Analyser le domaine d'application
  • Identifier les exigences :
    • fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI
    • non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.
  • Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)
  • Déterminer la priorité des besoins
  • Valider les exigences avec les utilisateurs
  • Élaborer un glossaire de termes

Analyse[modifier | modifier le wikicode]

Exploration des solutions possibles :

  • Analyser les exigences
  • Proposer une ou plusieurs solutions conceptuelles
    • Vue structurelle du système (modèle objet)
    • Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)
  • Proposer une architecture d'implémentation
  • Valider toutes les propositions avec les utilisateurs

Conception[modifier | modifier le wikicode]

Spécification détaillée de la solution choisie :

  • Définir le modèle physique de la base de données
  • Définir les contraintes d'intégrité
  • Choisir le SGBD
  • Modéliser les interfaces utilisateur
  • Définir les standards de sécurité du système
  • Définir l'architecture du système

Construction[modifier | modifier le wikicode]

Développement du code :

  • Créer les programmes
  • Créer et remplir les bases de données
  • Intégrer les sous-systèmes
  • Écrire la documentation

Tests[modifier | modifier le wikicode]

  • Tester les programmes
  • Tester le système global

Mise en place[modifier | modifier le wikicode]

  • S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place
  • Installer le système
  • Former l'utilisateur

Modèle en V[modifier | modifier le wikicode]

Méthode de développement en V

Décomposition du système en composants qui peuvent être développés de manière indépendante. Ce modèle permet d'avoir une meilleure réactivité que le modèle en cascade : il permet de limiter les retours en arrière en cas d'anomalie.

Modèle en W[modifier | modifier le wikicode]

Modèle de développement en W

Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.

Modèle en W : accent sur les tests[modifier | modifier le wikicode]

Modèle de développement en W avec accent sur les tests

Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les tests à toutes les phases de développement.

Développement évolutif[modifier | modifier le wikicode]

Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.

Détermination des besoins -> Programmation -> Expérimentation -> Version N -> Détermination des besoins -> ...

Spirale[modifier | modifier le wikicode]

Modèle de développement en spirale

Ce modèle reprend les différentes étapes du modèle en V en mettant un accent sur la gestion du risque, qui se retrouve à chaque début d'itération de la spirale.

RAD - Rapid Application Development[modifier | modifier le wikicode]

Modèle de développement RAD

Le RAD est un modèle linéaire en 5 phases et itératif pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :

  1. Travaux préparatoires
  2. Session participative
  3. Travaux de conclusion

Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.

Initialisation[modifier | modifier le wikicode]

Préparation et organisation du projet

  • Répertorier l'ensemble des intervenants
  • Définir les objectifs stratégiques du projet
  • Évaluer la faisabilité du projet
  • Évaluer les moyens nécessaires
  • Établir un accord entre le client et le fournisseur
  • Lancement du projet

Cadrage[modifier | modifier le wikicode]

Analyse et spécification des exigences :

  • Définir la hiérarchie des objectifs
  • Définir la hiérarchie des fonctions
  • Planifier les changements des processus "métier"
  • Définir les ressources nécessaires et le cycle de développement
  • Valider les objectifs et les contraintes

Conception[modifier | modifier le wikicode]

Conception de la solution :

  • Modéliser :
    • Établir une liste détaillée des fonctionnalités
    • Créer le modèle de données exhaustif
  • Préparer la documentation technique
  • Valider la conception d'ensemble
  • Choisir les technologies et les valider
  • Valider les modèles et le prototype
  • Valider les charges et le planning

Construction[modifier | modifier le wikicode]

Développement collaboratif et incrémental

  • Détailler chaque module
  • Réaliser (coder) les modules
  • Intégrer les modules
  • Tester les modules
  • Tester l'intégration
  • Documenter

Différents modules peuvent être développés en parallèle

Finalisation[modifier | modifier le wikicode]

Préparer la mise en oeuvre :

  • Préparer le système à l'installation
  • Rédiger les manuels utilisateurs
  • Rédiger le manuel d'exploitation
  • Préparer la formation
  • Établir le plan de formation
  • Établir le plan de démarrage (reprises de données, bascule technique,...)

Tester le système Démarrer le système :

  • Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation
  • Mettre en oeuvre le plan de démarrage
  • Audit du fonctionnement et évaluation des écarts
  • Améliorer et optimiser le système
  • Former les utilisateurs

RUP - Rational Unified Process[modifier | modifier le wikicode]

Processus itératif et incrémental divisé en 4 phases :

  1. Initialisation : définition de l'objectif du projet et préparation d'un contrat de réalisation
  2. Élaboration : planification du projet, spécification de la solution proposée, proposition d'une architecture de base
  3. Construction : développement du produit
  4. Transition : transition du produit chez les utilisateurs.

Ces 4 phases sont elles-mêmes divisées en N itération, à la fin desquelles Il y a une version du produit livrable.

Workflows[modifier | modifier le wikicode]

Étapes à réaliser dans chaque itération :

  • Modélisation d'entreprise (entreprise/business modeling)
  • Analyse des besoins
  • Analyse et conception
  • Implémentation
  • Test
  • Déploiement
  • Gestion de changements
  • Gestion de projet
  • Préparation d'environnement

XP - Extreme Progamming[modifier | modifier le wikicode]

Modèle itératif à deux niveaux :

  • Itérations de livraison - un plan de livraison doit être défini avec le client
    • une livraison - une version opérationnelle du logiciel
    • durée de développement - quelques mois
  • Itérations de développement - une fonctionnalité livrable est décomposée en plusieurs fonctions simples :
    • développement par binômes
    • les utilisateurs participent aux chois des itérations et aux tests
    • durée - 2-4 semaines
    • résultat - une ou plusieurs fonctions qui peuvent être intégrées dans la version livrable

Rôles[modifier | modifier le wikicode]

  • Programmeur : est responsable de la conception technique et le codage évolutif
  • Client : doit exprimer ses exigences sous forme de scénarios (user stories) et écrire des jeux de tests fonctionnels
  • Testeur : aide le client à élaborer des jeux de test et à les exécuter
  • Tracker : est responsable de la gestion du temps : planification et contrôle
  • Coach : est responsable du soutien technique des membres de l'équipe
  • Manager / chef de projet : les rôles peuvent être combinés : un chef de projet peut réunir les rôles de manager, tracker et coach.

SCRUM[modifier | modifier le wikicode]

Développement itératif et incrémental, fait référence à l'organisation d'un jeu de rugby :

  • avant-jeu : préparation, conception de haut niveau du système et son architecture : le périmètre et la base du contenu du système
  • jeu : développement itératif organisé en sprints de 2-4 semaines
  • après-jeu : livraison finale du système, clôture du projet.

Vocabulaire[modifier | modifier le wikicode]

  • Product backlog

Une liste priorisée de besoins et exigences que veut le client, exprimé dans son vocabulaire et sa terminologie métier, souvent en termes de scénarios (user stories)

  • Sprint backlog

Une liste de tâches identifiées par l'équipe du projet à réaliser pendant un sprint afin d'implémenter les scénarios sélectionnés pour ce sprint.

  • Daily scrum

Chaque jour on organise une courte réunion (15 minutes) pour fixer et/ou ajuster les objectifs de la journée

  • Product owner (propriétaire)

Représente le client en ce qui concerne les spécifications des exigences et les acceptations

  • Scrum master (capitaine d'équipe)

Anime au quotidien l'équipe de développement, recadre le projet en cas de difficulté. Ce rôle donne lieu à une certification

  • Team members (les membres d'équipe)

Architectes, développeurs, testeurs, administrateurs de base de données, etc. Les mebres d'équipe disposent d'une certaine autonomie dans l'organisation de leurs travaux.

=User story[modifier | modifier le wikicode]

Le scénario est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur. Ces user stories émergent au cours d'ateliers de travail menés avec le Métier, le Client et/ou les utilisateurs.

Le modèle de structure d'une User Story

  • En tant tant que <rôle, personne, user type>
  • Je veux <fonctionnalité, tâche, action>
  • Afin de <valeur ajoutée, résultat>

Exemples :

  • En tant qu'acheteur en ligne, je veux pouvoir ajouter des items à mon panier afin d'enregistrer mes achats que je ne souhaite pas acheter dans l'immédiat.
  • En tant qu'utilisateur, je veux réserver une chambre d'hôtel afin de...
  • En tant qu'utilisateur, je veux annuler une réservat5ion afin de...
  • En tant que recruteur, je veux déposer des offres d'emploi afin de...
  • En tant que je une diplômé, je veux déposer un CV afin de...
  • En tant que jeune diplômé, je veux supprimer un CV afin de...


Annexes[modifier | modifier le wikicode]

Références[modifier | modifier le wikicode]