Accueil du site > Les articles > Méthode SDMS, phase définition des besoins.
Version à imprimer Enregistrer au format PDF

Méthode SDMS, phase définition des besoins.

mercredi 12 mai 2004, par David Malle Visites  20586 Première mise en ligne le jeudi 9 octobre 2003.

Un projet géré via la méthode SDMS est découpé en 10 phases de 9 tâches chacune. Chacune des phases a une liste de tâches qui leur sont propres.

La seconde de ces phases est la définition des besoins. Son contenu est énuméré de manière plus précise sur cette page. Cette énumération n’est pas assez complète pour se substituer au contenu de la méthode elle même. Toutefois, elle constitue un atout interressant pour la conduite de projet.


Rappel des 10 phases.


    - DS / EO, Demande de service - Etude d’opportunité
    - DBS, Définition des besoins
    - CAS, Choix d’architecture
    - SES, Spécifications externes
    - SIS, Spécifications internes
    - PRG, Programmation
    - TST, Tests
    - CONV, Conversion
    - INST, Installation
    - BILAN, Bilan

DBS : définition des besoins.

Définition des besoins ou :


    - Définir le domaine
    - étudier l’existant
    - analyser l’existant

définir les exigences liées au nouveau système Une fois la définition des besoins approuvée, le planning de développement est mis en place et la rédaction du plan d’assurance qualité commence.

Un certain nombre de tâches sont à accomplir durant cette phase : 1- Identifier la portée du projet.


    - Définir le domaine du projet et les hypothèses de départ.
    - Identifier les utilisateurs impliqués.
    - Esquisser les modèles logiques et physique.
    - Situer le domaine du projet dans le domaine de gestion.
    - Identifier les actions nécessaires à la préparation de l’équipe projet.
    - Préparer le plan d’assurance qualité
2 - Conduire les entretiens.

    - Préparer les entretiens.
    - Mener les entretiens.
    - Résumer et passer en revue les résultats des entretiens.
    - Etablir et tenir à jour la liste des documents recueillis.
3 - Documenter le système existant.

    - Etablir la liste indentée des processus.
    - Elaborer les représentations graphiques.
    - Documenter les traitements (les processus).
    - Documenter les stockage des données.
    - Documenter les flux de données.
    - Etablir et tenir à jour le dictionnaire des données.
    - Terminer la documentation du modèle.
4 - Analyser le système existant.

    - Identifier les composants logiques du système.
    - Etablir la liste indentée des fonctions.
    - Elaborer le modèle logique des données.
    - Décrire les fonctions et les flux des données.
    - Etablir et tenir à jour le dictionnaire des données.
    - Terminer la documentation du modèle logique.
    - Faire la synthèse des problèmes et des besoins.
5 - Définir les objectifs du système proposé.

    - Préciser les objectifs du nouveau système.
    - Identifier les changements à effectuer dans le modèle logique du système existant.
    - Construire chaque mini-modèle identifié.
6 - Définir les exigences logiques (conceptuelles) du système proposé.

    - Identifier les composants logiques du système.
    - Etablir la liste indentée des fonctions.
    - Elaborer le modèle logique des données.
    - Décrire les fonctions et les flux de données.
    - Etablir et tenir à jour le dictionnaire des données.
    - Terminer la documentation du modèle logique.
7 - Définir les exigences physiques du système proposé.

    - Ordonner les objectifs du système.
    - Définir les exigences physiques imposées sur les données.
    - Définir les exigences physiques imposées sur les fonctions et les flux de données.
    - Identifier l’impact sur les autres systèmes et les bases de données partagées.
8 - Préparer le document définition des besoins du système (DBS) 9 - Actualiser le planning et faire approuver le document DBS

    - Préparer le plan de travail et les estimations pour la phase CAS. Actualiser le plan d’assurance qualité.
    - Faire revoir et approuver le document DBS.

Particularités :

Le résultat de la tâche 1 doit être approuvée par la hiérarchie utilisateur et la hiérarchie informatique avant d’engager les autres tâches de cette phase.

La tâche 2 est menée en parallèle de la tâche 3.

S’il n’existe pas de documentation du système existant, la tâche 3 peut nécessiter un travail important. Dans tous les cas, l’équipe projet décide au départ du niveau de documentation à atteindre en ce qui concerne l’existant.

En cas d’évolution du système existant, modéliser los de la tâche 4, les composants physiques qui font partie de la zone à modifier.Pour les fonctions dont les règles vont changer entre le système existant et le nouveau système, ne pas les documenter au niveau de détail le plus fin.

Une fois la tâche 6 achevée, le modèle logique détaillé du nouveau système peut être obtenu. L’équipe projet peut décider de ne pas atteindre ce niveau de détail et terminer le modèle dans la phase spécifications externes (SES).

La tâche 6 achevée, le niveau de détail doit être suffisant pour entreprendre la phase Choix d’architecture (CAS), sans avoir à affiner le modèle logique du nouveau système. Le niveau de définition doit permettre d’assurer la cohérence du nouveau système.

Ne vous arrêtez pas là. Plongez vous dans les chapitres décrivant chacune des phases de la méthode SDMS, en cliquant sur les raccourcis ou, en fouinant via notre moteur de recherche.

 [1]