Envoyé par ZenZiTone
J'en connais un qui va, au gré de sa carrière, finir par perdre ses illusions. (bien sur, ça donne des trucs qui "tombent en marche" un certain temps, mais c'est plus fréquent qu'on ne l'imagine).
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
J'en connais un qui va, au gré de sa carrière, finir par perdre ses illusions. (bien sur, ça donne des trucs qui "tombent en marche" un certain temps, mais c'est plus fréquent qu'on ne l'imagine).
Je comptais un peu sur vous pour m'aviser sur les traitements de Merise.
Hello CinePhil,
C'est ce qui correspond au Traitements de Merise, c'est juste ? -Je comptais un peu vous requérir à ce sujet (après avoir fait pareil avec Monsieur de Sainte Marie, qui m'a donné deux références dont la vôtre).
Pour ma part, j'ai rédigé un tuto sur les "neuf" formes normales, mais avant relecture, j'envisageais d'inclure les Traitements, partie encore plus conséquente que pour les données - les traitements sont aussi normalisables et comprennent de nombreux graphiques voisins. Ajoutons à cela le livre de Pascal André et Alain Vailly qui dit que ces modèles incluent des interprétations très variables parfois dénommés différemment en dehors de Merise, et on y perd son latin.
En fait, j'aurais besoin d'un avis:
Que pensez-vous des Traitements de Merise, est-ce que leur lecture suivie d'un résumé pédagogique fait durant des heures libres (p. ex.: 20H à 22H) peut être faisable en 2 ans ?
Et c'est là qu'au grand dam! des concepteurs, on se met à dénormaliser, puis à opter pour le "NoSQL", à mon avis.
Le diagramme de cas d'utilisation UML correspond davantage au Modèle Conceptuel de Flux de Merise.C'est ce qui correspond au Traitements de Merise, c'est juste ?
La partie traitements de Merise tient davantage du diagramme d'états-transitions UML ou du diagramme de séquence UML.
Il y a déjà la bible de fsmrel sur le sujet.
Je ne comprends pas bien la question... S'agit-il de constituer un cours sur les traitements par la méthode Merise ?Que pensez-vous des Traitements de Merise, est-ce que leur lecture suivie d'un résumé pédagogique fait durant des heures libres (p. ex.: 20H à 22H) peut être faisable en 2 ans ?
=> En une seule UE de l'IPST-CNAM en 2007, nous avons vu l'intégralité de Merise et pas mal d'UML. Cours de M. Mazet : Ingénierie des systèmes d'information : Méthodes avancées. Et mise en pratique partielle dans l'UE suivante : Méthodologie des systèmes d'information : Audit et gouvernance.
Pour le peu que j'en sache, NoSQL est utile dans le big data : des données massives mais sans besoin d'intégrité référentielle forte.Et c'est là qu'au grand dam! des concepteurs, on se met à dénormaliser, puis à opter pour le "NoSQL", à mon avis.
Un SGBDR est indispensable lorsque ce besoin d'intégrité référentiel est fort... et la conception rigoureuse de la BDD qui va avec.
Seulement des réflexions philosophique et des NF introuvables.
Oui, vous avez compris.
En d'autres termes, c'est faisable... je suppose que UE signifie unité d'enseignement; genre une heure par semaine pendant vingt-huit semaines (vingt-huit heures) ?
Ceci dit, je n'ai pas (eu) de cours sur les traitements (seulement pour la partie des données), donc je dois me taper tout la méthode Merise/2.
Je n'aurais pas dû vous poser la question - je vous prends inutilement du temps, alors que je devrais pouvoir m'auto-évaluer. Mon petit tuto des NF comprendrait les neuf en partant des ultra-fondamentaux (définitions de donnée vs info, réflexions à tendance philosophique sur les différents types de clés clés et pourquoi on les appelées ainsi (toujours très important, ça, le pourquoi d'un terme), et autres y c. pour débutants), c'est à dire notamment D/KNF que je n'avais pas trouvée dans ladite Bible vis-à-vis de laquelle le document constituerait une vue complémentaire, ainsi que EK/NF, qui quant à elle est quasiment introuvable sur le net (j'ai eu l'autorisation d'une mathématicienne de citer son document). Bon, ça me permet de tâter le terrain; je crois que je n'ai pas vos encouragements; mais bon, c'est pas dit du tout que je le publie, surtout si je dois intégrer ces fameux traitements.
Je m'attendais dans cette discussion au listing des étapes de conception d'un projet, du genre
- cahier des charges
- puis rédaction des spécifications fonctionnelles
etc.
Là on se focalise sur la modélisation: Merise, UML etc....
Alors que la tendance est aujourd'hui aux méthodes "Agile" comme SCRUM! Où l'on ne perd pas trop de temps à la conception et à la modélisation: sinon on finit par coder complètement le projet sans avoir rien écrit aucune ligne de code!!! Le temps de la modélisation prendra des mois quoi????
Agile ne signifie pas qu'il n'y a plus de conception. Du moins j'espère !
Simplement, Agile permet de faire un projet par morceau et de commencer un morceau sans attendre que toute la conception d'un projet soit terminée. C'est du moins comme ça que j'ai compris la chose.
Oui, c'est l'idée.
On commence en effet un projet par lister succinctement les fonctionnalités que l'on désire.
C'est pour permettre de les trier par priorité et importance.
Par contre, ensuite, à mesure que l'on avance sur le projet, on spécifie précisément les fonctionnalités en haut de cette liste, pour l'itération suivante.
De même, l'équipe en début d'itération se concerte ensemble (auto-organisation) pour définir les modifications architecturales à réaliser pour les fonctionnalités actuellement à réaliser.
C'est l'idée d'avoir des spécifications qui sont réellement précise et à jours au moment où on développe les fonctionnalités correspondantes.
Mais aussi ça évite d'imaginer une architecture hyper-complexe du départ lié à de futures fonctionnalités qui finalement ne seront jamais implémentées.
Pour ma part, je vois trois étapes suivant l'"élaboration" du cahier des charges.
Bien vu, Randriano,
En plus, sans ré-intervention de l'auteur du thème, on a dévié.
Par contre, Merise, en tout généralité, est une méthode - donc on ne peut pas l'ignorer (à moins de choisir une autre méthode, mais comme l'a dit CinePhil, on peut encore panacher (respecter la méthode Merise avec des schéma UML).
Là où la question d'origine n'a pas de sens, c'est qu'elle n'a pas de contexte. Au minimum, il faudrait exposer une problématique (But visé, stade actuel (compétences (p. ex.: les collaborateurs modélisent avec tels types de diagrammes UML), et les moyens qu'on se propose pour effectuer le chemin (souhait des collaborateurs d'appliquer UML aux données de manière brute (un livre expose l'application d'UML aux DB), ou au contraire souhait d'opter pour une méthode plus dédiée à cela).
Avec ce peu (pas) d'élément(s), CinePhil a très bien répondu en mentionnant le côté central de la DB - ce qui a orienté sur Merise.
Moi, voici comme je dirais:
- Normalisation (selon qu'on a élaboré soi-même le cahier des charges ou non). Si c'est un client qui a soumis le cahier des charges, il faudra certainement encore normaliser. (Et éventuellement poser des questions complémentaires.) Notons que - dans l'absolu - la normalisation ne concerne pas que les données (DB), mais aussi les Traitements (partie dynamique).
- Etablir les modèles (conceptuels), et les soumettre au client. Penser à les lui faire signer, comme le cahier des charges complété par les questions.
- Réaliser - c'est là où je suis le plus bref, tellement ça peut partir dans toutes les directions. Je rejoins CinePhil en disant: commencer par la DB (implémenter le modèle logique (Merise) ou autre modèle sémantiquement équivalent dans le système choisi). Pour les traitements, je n'ai aucune idée comment on implémenter ça. Sans doute des requêtes (dans le sens général du terme) ayant la possibilité d'être automatisées.
En hypothèse, on devrait avoir Quoi, et quel But.
En fait, OSryx,
Il y a plusieurs exposés et choix discutables dans votre message:
Bonjour,
Supposons que je développe une application bureau avec Java SE, suivant le modèle de développement Cycle-V. J'ai terminé la rédaction du cahier des charges de ma future application , j'y ai exprimé les fonctionnalités du système ainsi que l'ensemble du besoin (fonctionnel et non-fonctionnel) du client. J'ai établit ce que l'application idéal fera dans un document que je peux appeler *User Requirements document*.
Maintenant, je passe à la conception de l'architecture de l'application ainsi que la conception détaillée. Cette partie je ne comprends pas en quoi elle consiste ?
L'idée que j'ai est comme suit : d'abord je mets au point un diagramme des cas d'utilisation, et pour chaque cas d'utilisation je mets au point un diagramme de séquence, pour qu'enfin je réalise un diagramme des classes. Ce dernier me permettra de générer du code source de base.
Est ce que c'est correct ? Et au sujet du système de gestion de base données, je le fais intervenir à quel stade de la conception ?
Toute aide est la bienvenue
- Le User Requirements Document fait doublon avec le cahier des charges;
- On ne sait pas qui est le client. Si c'est quelqu'un d'autre que vous-même, vous serez amené à le compléter grâce aux question que vous poserez à ce client.
- On n'a pas à supposer que vous développez en Java SE, en tout cas pas à l'étape censée suivre le cahier des charges - c'est même contre-indiqué, car cela peut influencer les conseils sur une simple "hypothèse".
- Un choix discuté, c'est le modèle en V. Selon ma connaissance, ça consiste à l'extrême à retourner sur la conception à partir de l'implémentation, et ce n'est pas applicable à tout - en particulier, quasiment pas aux bases de données.
- Curieusement, le but consistant à savoir quel besoin doivent être satisfaits, ce n'est pas exprimé.
- (Selon Kevininternet, les diagrammes de classe sont en UML les diagrammes les plus utiles.)
- Heureusement, vous finissez par questionner au sujet de la base de données - ça devrait figurer en premier.
En fait, j'ai l'impression que vous avez pris le problème à l'envers:
Vous placez le développement en Java SE en premier, alors que vous ne vous questionnez au sujet de QUOI manipuler qu'en dernier.
Cf. mon précédent post pour les principales étapes.
Amicalement
Ce que je sais c'est qu'il n'y a pas de théorie exacte de la rédaction des cahiers des charges surtout quand c'est un informaticien voire développeur comme nous qui l'écrit.
Dès fois cela inclut déjà la conception de l'architecture de l'application. C'est ce que je fait!
C'est la conception disons détaillée qui suit le CDC selon moi mais le terme est vague, c'est à priori composée de plusieurs sous-étapes: Modélisation, etc.
C'est le point qui semble, à la base, assez loufoque dans cette discussion.
Le cahier des charges, c'est un document que fournit le client au prestataire en vue de la réalisation.
Il peut, bien sur, en sous traiter la rédaction mais a priori en aucun cas à la partie qui sera chargée de la réalisation; ce serait en effet assez aberrant.
Ca dépend
Bien vu Randriano,
Mais tout dépend de qui soumet le CC. Si tu te le soumets à toi-même, alors oui, bien-sûr que tu vas y inclure la normalisation et tout ça. Par contre, si c'est un client qui ne connaît rien à l'informatique, tu ne peux pas exiger qu'il le fasse. C'est l'étape que tu vas automatiquement ajouter.
Après, la question est: comment faire le retour au client (si possible: avant réalisation).
Dans Merise, il est bien claire que tu ne vas pas commencer à lui exposer le modèle logique, car cela consisterait notamment à lister toutes les règles que j'ai mentionnées en hyper-lien d'un post de la page précédente.
Par contre, le concept est très adapté, puisqu'il suffit à donner l'idée
Répondre avec citation
Partager