Discussion :

[rvkone]

Salut à tous!
J'effectue actuellement un stage au sein de l'Agence Universitaire Francophone de mon pays.
Il s'agit de mettre en ligne des milliers de notices bibliographiques.
La démarche adopté étant le processus unifié car il convient parfaitement avec la modélisation UML.
Tout va pour le mieux.Cependant, au moment ou je vais rédiger mon rapport de stage, je me plante un peu.
Je ne sais comment le structurer le plan suivant la démarche.
Je m'explique un peu:lors de mon stage de l'année dernière, j'ai adopté la démarche de MERISE.Il fallait seulement structurer le rapport dans le rapport les trois phases essentielles de la démarche qui ont été traité sequentiellement
. ETUDE PREALABLE
. ETUDE DETAILLEE
. ETUDE TECHNIQUE
Mais en processus unifié : certaines activités ont été itéré.(use case, abnalyse , conception, implémentation,...)
La question que je me pose c'est que:
Est-ce qu'il faut rédiger le rapport suivant les itérations , par exemple :
. PHASE INCEPTION
specification des besoins
analyse/conception
implementation
. PHASE ELABORATION
specification des besoins
analyse/conception
implementation
. PHASE CONSTRUCTION
specification des besoins
analyse/conception
implementation
.PHASE TRANSITION
specification des besoins
analyse/conception
implementation
ou d'une autre manière?
Je voudrais que mon raport de stage démontre que j'ai bien suivi le démarche processus unfié
Merci pour l'aide!

[alex00]

Tout d'abord, bon courage pour ton rapport !

Pour le plan, une structure courante est :
1) présentation de la société
2) présentation du but du projet
3) présentation du déroulement du projet
4) présentation du résultat du projet

C'est dans la troisième partie que tu peux mettre en avant UP, en indiquant le déroulement de quelques itérations :
nouveau besoin ou évolution, ou risque majeur ;
ajout dans l'architecture ou son évolution ;
et conclusion de l'itération (test, mise en place, ...).
Et ceci avec quelques diagrames UML bien choisis.

Si tu souhaite vraiment te calquer sur les phases, tu peux :
présenter une vision globale du projet en 2 (inception)
présenter l'architecture et le test en 3 (elaboration, construction)
et enfin donner les résultats puis ouvrir sur le futur en 4 (transition : qui continue après le stage).

Une remarque : entre architecture et test, je ne descendrais pas au niveau du code : c'est trop indigeste en général.

enfin, c'est quelques idées, à toi de t'adapter à ton auditoire.
Alexandre

[rvkone]

Tout d'abord un grand merci pour avoir illuminé le chemin!
Cependant, j'aimerais efectuer quelques precisions sur les objectifs du projets:
En effet le projet a deux objectifs bien précis :
1 - passer du documents papier au document numérique (numérisation, conversion de fichier, archivage,...)
2 - du document numérique à la publication (catalogage,indexation, creation de site internet,...)

Pour le deuxième objectif tout est assez clair!La rédaction suit les phases que vous avez précedemment expliqués.Mais pour la première partie je ne saurais ou mettre la rédaction.

Remarque : la première partie du projet comporte aussi (eh oui!) une phase d'analyse , de conception et de réalisation malgré qu'elle ne suit aucun processus de developpement .
Pourtant,je voudrais que toutes les deux parties cohabitent dans un même et unique rapport de stage (cela va de soi!!) et qu'il y a cohérence.La, je me plante un peu...
Encore merci pour tout!!

[alex00]

pour la première partie, le travail n'est pas du developpement,
mais plutôt de l'organisation.

Au lieu de modéliser un système informatique, tu peux modéliser un système d'information :

acteurs : ceux qui numérisent (business worker), et peut-être (vraiment pas sûr) ceux qui utilisent les documents (business actor ?).
besoins : numériser des documents et les référencer,
analyse : différents types de documents, et donc d'indexations,
conception et deploiment : les technos employés (scanner, OCR, soft maison),
réalisation et test : la mise en place et la vérif.

Enfin, en terme de phases, cf. mon mail précédent :
besoins et risques évoluent en fonctions de la structuration et de l'indexation des [types de] documents pris en compte.

une dernière remarque : il n'y a peut-être pas de business actors, car numériser et archiver des documents n'a aucune valeur en soit :
la valeur est dans l'accès distant et la recherche rapide.
(c'est un cas d'utilisation secondaire : nécessaire mais sans valeur ajoutée directe).

[rvkone]

Merci pour l'aide! ct sympa de votrea part!!a bientôt j'espère

[naimabenmessaoud]

Bonjour

je suis étudiante en M2, je suis en cours de préparation d'une étude de cas pour une société d'industrie qui va automatiser son organisation, gestion du personnel et la fabrication
je modélisa suivant up, je voudrais savoir svp comment on procède pour le choix du nombre d'itérations ?
on m'a dis qu'il est égal au nombre d'acteurs ( d'utilisateurs) ??

MERCI

[maroonet]

bonjour
j'ai lu ce que vous avez écrit mais j'ai pas bien compris quand je peux parler de la conception par ce que j'ai vue des ancienne rapport, et ils ont mis les diagramme de cas d'utilisation dans la phase d'inception alors que les autres diagramme dans la phase d'élaboration, si c'est possible je veux savoir qu'est ce que je doit mettre a chaque phase.
merci d'avance j attend votre réponse impatient par ce que mon travaille s'arrête a cause de ça