Une description métier de la solution?????
Fermé
miroutta
-
8 mars 2008 à 09:18
Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 - 8 mars 2008 à 13:42
Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 - 8 mars 2008 à 13:42
A voir également:
- Une description métier de la solution?????
- Pack solution - Télécharger - Divers Utilitaires
- Mots entre amis messenger solution ✓ - Forum jeux en ligne
- Island questaway solution français ✓ - Forum Jeux vidéo
- Solution rébus image ✓ - Forum Loisirs / Divertissements
- Bloquée dans The Island: Castaway - Forum Jeux vidéo
3 réponses
tarek_dotzero
Messages postés
817
Date d'inscription
jeudi 19 juillet 2007
Statut
Membre
Dernière intervention
12 avril 2022
120
8 mars 2008 à 10:45
8 mars 2008 à 10:45
Salut,
Dans une conception, il est tres important de prendre en compte le metier, c'est à dire la nature de travail humain dans le système même si ce dernier est automatisé.
De ce que votre encadreur demande, je peux dire que vous faites un projet de la forme de "conception et réalisation d'un système de gestion de...".
Voilà dans la partie description metier: vous vous concentrez sur les derniers points, loin des algorithmes, schémas de conception, algorithmes, schéma de la base, vous devez repondre à la question:
* Comment l'utilisateur final (l'emploier) arrive à accomplir ça tâche en utilisant le système.
Ou quelque chose proche de tout ce bla bla
Bon Courage :)
Dans une conception, il est tres important de prendre en compte le metier, c'est à dire la nature de travail humain dans le système même si ce dernier est automatisé.
De ce que votre encadreur demande, je peux dire que vous faites un projet de la forme de "conception et réalisation d'un système de gestion de...".
Voilà dans la partie description metier: vous vous concentrez sur les derniers points, loin des algorithmes, schémas de conception, algorithmes, schéma de la base, vous devez repondre à la question:
* Comment l'utilisateur final (l'emploier) arrive à accomplir ça tâche en utilisant le système.
Ou quelque chose proche de tout ce bla bla
Bon Courage :)
Mahmah
Messages postés
496
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
22 juin 2010
125
8 mars 2008 à 13:42
8 mars 2008 à 13:42
Salutations,
Vous allez rire, je n'en ai pas vraiment la même définition.
La partie métier d'un programme c'est le coeur sur lequel il travaille.
En prenant l'exemple d'une banque, la partie métier comprendra des objets représentant un client, un compte, des transactions, des historiques, des conseillers etc... C'est tout ce qui fait parti du contexte pour lequel tu développes le programme, en somme tout ce qui existe dans la vraie vie et qui va se retrouver dans ton programme.
A l'inverse, la partie applicative est toutes les bricolettes ou implémentations techniques dont tout le monde se fout bien à part toi, par exemple les factory, les listener qui préviennent un conseiller qu'un client est dans le rouge etc...
Oui c'est une règle (et ça c'est métier) mais la manière dont tu la gères toi, ton client s'en tape royalement.
Même question sur un autre forum
Je pense qu'il t'es demandé de spécifier ce que normalement on t'a expliqué car tu n'es pas banquier ni banquière et tu ne peux pas l'inventer. Le but me parait simple: 1) Vérifier que tu as compris tous les éléments du projet. 2) Qu'un autre programmeur puisse prendre la suite ou modifier ton programme sans avoir à refaire le travail de recherche sur le fonctionnement non informatique du programme.
En conclusion je dirais:
Lister les éléments intervenants dans la vie réelle. Lister leurs attributs. (Un client a un nom, un numéro de client etc) Présenter les relations qu'ils ont entre-eux. (que ce soit "un client reçoit un mail lors de l'expédition de son colis" ou "Les frais de port sont calculés suivant la formule 'pouet-pouet' pour tout poids compris entre X et Y et...")
Et surtout en méga conclusion je dirais:
Si tu as une question et un type qui t'encadre, fait simplement le lien entre les deux. ^^
M.
Vous allez rire, je n'en ai pas vraiment la même définition.
La partie métier d'un programme c'est le coeur sur lequel il travaille.
En prenant l'exemple d'une banque, la partie métier comprendra des objets représentant un client, un compte, des transactions, des historiques, des conseillers etc... C'est tout ce qui fait parti du contexte pour lequel tu développes le programme, en somme tout ce qui existe dans la vraie vie et qui va se retrouver dans ton programme.
A l'inverse, la partie applicative est toutes les bricolettes ou implémentations techniques dont tout le monde se fout bien à part toi, par exemple les factory, les listener qui préviennent un conseiller qu'un client est dans le rouge etc...
Oui c'est une règle (et ça c'est métier) mais la manière dont tu la gères toi, ton client s'en tape royalement.
Même question sur un autre forum
Je pense qu'il t'es demandé de spécifier ce que normalement on t'a expliqué car tu n'es pas banquier ni banquière et tu ne peux pas l'inventer. Le but me parait simple: 1) Vérifier que tu as compris tous les éléments du projet. 2) Qu'un autre programmeur puisse prendre la suite ou modifier ton programme sans avoir à refaire le travail de recherche sur le fonctionnement non informatique du programme.
En conclusion je dirais:
Lister les éléments intervenants dans la vie réelle. Lister leurs attributs. (Un client a un nom, un numéro de client etc) Présenter les relations qu'ils ont entre-eux. (que ce soit "un client reçoit un mail lors de l'expédition de son colis" ou "Les frais de port sont calculés suivant la formule 'pouet-pouet' pour tout poids compris entre X et Y et...")
Et surtout en méga conclusion je dirais:
Si tu as une question et un type qui t'encadre, fait simplement le lien entre les deux. ^^
M.
