ETUDE PREALABLE

Phase EP.2 Conception

EP.2.1 Objectifs

 Concevoir la nouvelle solution dans les grandes lignes: propositions

de traitements.

organisationnelles: répartition des tâches et des responsabilités, automatisation.

d'architecture technique

de scénarios d'évolution

 On reste à un niveau "macro", conceptuel.

Notamment, on ne prend en compte que les procédures 'normales' représentatives sélectionnées dans la phase précédente.

EP.2.2 Activités de réalisation

 Si vous recherchez un progiciel

 Les activités de conception devraient être réduites à l'essentiel: fonctions, processus et données. Le but est d'avoir un inventaire de référence qui sera utilisé plus tard, afin de s'assurer que les progiciels répondent aux besoins.

 Prendre des contacts préliminaires afin d'êtres informé des possibilités des progiciels, des fonctions assurées habituellement, des règles de gestion courantes.

 Principes & règles de gestion

 rappeler les principes & règles de gestion;

 implémenter les principes & règles de gestion sous une forme systématique

ordinogrammes

tables de décision

 dans la mesure du possible, décrire les règles sous une forme paramétrable évolutive.

 Applications et systèmes

  Décrire les applications et systèmes par leurs caractéristiques essentielles

fonctions; hiérarchie des fonctions.

intrants (inputs): données , documents, ...

extrants (outputs)

acteurs principaux.

Diagramme de Flux de Données ( /Application )

 On prêtera une attention particulière aux interfaces, c.à.d. aux objets qui sont l'output d'un système, et l'input de l'autre.

 Dans la description des systèmes, les données peuvent être mentionnées de façon encore très schématique (data store)

  Traitements: décrire les fonctions du système

La description des fonctions suit les mêmes règles que la description des applications.

Elle s'opère à un niveau de détail plus fin.

La description des fonctions remplace avantageusement la description des traitements ( Modèle Conceptuel des Traitements ) de la méthode Merise . En effet, les fonctions décrivent les traitements à réaliser, mais indépendamment des choix techniques & d'organisation, et sans que l'on doive préciser tous les détails du mode de fonctionnement.

Diagramme de Flux de Données (/Fonction)

 Décrire les données [ Modèle conceptuel des données ]

 Commencer à établir l'inventaire des données à traiter (données déjà informatisées et non encore informatisées)

 Généraliser les données à un niveau abstrait, conceptuel, paramétrable et évolutif

  éviter un modèle des données reposant sur des cas particuliers, des occurences

 Structurer les données selon une forme normalisée pure, sans tenir compte à ce stade

ni des contraintes techniques de distribution, vitesse d'accès, redondance, archivage, ...

ni des aspects "psychologiques": interface utilisateurs, autorisations d'accès, vues, ...

  Appliquer les règles de normalisation de Codd

"L'idée de base en normalisation est d'organiser l'information dans une base de données comme suit:

  Chaque type d'objet distinct a un identifiant du type, qui devient le nom d'une relation de base

 Chaque object distinct d'un type déterminé doit avoir un identifiant d'instance qui est unique pour ce type d'objet; ceci est nommé sa clé primaire

 Chaque fait dans une base de données est un fait au sujet d'un objet identifié par sa clé primaire

 Chacun de ces faits ne contient rien autre que des valeurs unitaires, propriétés immédiates de l'objet

 De tels faits sont rassemblés dans une relation unique s'ils concernent des objets du même type. Le résultat est une collection de faits, tous du même type.

Notez que cette méthode ne fait pas de distinction entre objets abstraits et objets concrets. De plus, il n'y a pas de distinction entre les entités et les relations."

Codd, "The Relational Model for Database Management", version 2, 17.5.1

Diagramme Entité-Relation

Diagramme Entité-Relation

 Organisation

 Décrire dans les grandes lignes, sans entrer dans les détails de procédures

Choix d'automatisation

Modes de communication

Impact organisationnel

EP.2.3 Activités de gestion de projet

 Etablir une estimation de la (ou des) solutions(s) retenue(s) en terme de

• coût, ressources nécessaires
• bénéfice
• planning
• risque

EP.2.4 Activités d'assurance qualité

 Contrôle par relecture, simple ou croisée.

 Facteurs clefs: vérifier que les besoins trouvent une solution

NB: à ce stade, la solution n'est pas encore entièrement décrite, l'inventaire des données n'est pas encore complet, etc. Il s'agit donc d'une première évaluation qui devra être complétée durant les phases suivantes:

Etude préalable - Généralisation

Etude détaillée - Conception

 au niveau des fonctions & traitements, et en les croisant avec le modèle des données

 vérifier par pointage systématique que les besoins exprimés durant l'étude préalable pourront trouver une solution

 évaluer

les besoins qui ne trouveraient pas de solution

les limitations éventuelles, notamment en terme d'organisation (niveau d'automatisation).

au niveau des données

 veiller à ce que l'inventaire des données soit établi selon une forme systématique.

 éditer des tables d'occurrences démontrant comment le modèle conceptuel des données peut prendre en charge les données physiques (important pour obtenir la compréhension des utilisateurs et leur motivation !).

 cet inventaire peut être une base pour la réalisation des jeux de tests et du paramétrage de démarrage.

EP.2.5 Activités de clôture

 A l'issue de cette phase, on doit choisir une (ou plusieurs) solution(s)

 au niveau fonctionnel

Qu'est-ce qui doit être fait ?

au niveau organisationnel

Qui fait quoi ? Comment ? Caractéristiques principales.

Services responsables

Mode d'automatisation.

 Cette solution porte encore sur les cas représentatifs normaux .

 La décision se prend en ayant déjà une bonne connaissance des implications techniques, organisationnelles, budgétaires, de planning, de sécurité.

 Vérifier que la solution choisie corresponde aux objectifs fixés (ou les adapter).