A voir également:
- Une description métier de la solution?????
- Driverpack solution - Télécharger - Divers Utilitaires
- Solution prs chronopost - Forum Mobile
- Ou est charlie solution tome 1 - Forum Loisirs / Divertissements
- My sims ds solution ✓ - Forum Jeux vidéo
- Ou est charlie le livre magique solution - Forum Loisirs / Divertissements
3 réponses
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 :)
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.
