Discussion :

[sphinx.ma]

Bonjour,

Débutant et faisant des recherches pour passer de Merise à UP.

en avançant dans l'étude d'openUP et en cours d'assimilation du concept d' "itération" je me pose la question suivante :

Étant donné qu'on part à chaque itération avec un cas d'utilisation jusqu'à son implémentation et test, puis on repart sur un autre cas d'utilisation...

Et en prenant l'exemple tout bête d'une classe donnée "Utilisateur"

Dans le premier cas d'utilisation cette classe n'aura par exemple que 5 propriétés... dans une itération N et pour traiter un autre cas d'utilisation on doit la faire passer à 7 propriétés...

Il est nécessaire de passer en revue tout le code utilisant cette classe ou du moins la documentation pour voir si ce changement n'a pas d'impacts sur le déroulement des cas d'utilisation déjà traités...

Perte de temps par rapport à une approche non itérative?

[montesq]

Bonjour,

Débutant et faisant des recherches pour passer de Merise à UP.

en avançant dans l'étude d'openUP et en cours d'assimilation du concept d' "itération" je me pose la question suivante :

Étant donné qu'on part à chaque itération avec un cas d'utilisation jusqu'à son implémentation et test, puis on repars sur un autre cas d'utilisation...

Et en prenant l'exemple tout bête d'une classe donné "Utilisateur"

Dans le premier cas d'utilisation cette classe n'aura par exemple que 5 propriétés... dans une itération N et pour traiter un autre cas d'utilisation on doit la faire passer à 7 propriété...

Il est nécessaire de passer en revue tout le code utilisant cette classe ou du moins la documentation pour voir si ce changement n'a pas d'impacts sur le déroulement des cas d'utilisation déjà traités...

Perte de temps par rapport à une approche non itérative?

D'où l'intérêt des tests de non-régressions automatisés...
Non ce n'est pas une perte de temps car de toute façon ton modèle de données ne sera jamais figé, il y a aura toujours une évolution 1 semaine, 1 mois, 1 an après qui nécessitera de modifier ce modèle. Et là tu seras bien content dès le début d'avoir automatisé les tests...

[sphinx.ma]

je comprends parfaitement...d'où l'intérêt de la POO...

Mais j'ai peur que ce concept ne soit que théorique, car en pratique et surtout pour un développeur, lui demander de repasser en revue la documentation (ou le code source) de toute une partie qu'il a codé la semaine dernière rien que pour rajouter une fonctionnalité risque d'être lassant pour lui...

Essentiellement en considérant le nombre d'itérations qui risque d'être x2, x3,....

Il comprendra qu'il doit le faire pour une erreur dans le code, mais pour rajouter une fonctionnalité, j'imagine mal la scène...

avez vous un retour d'expérience par rapport à la gestion des projets sous UP?

[Patriarch24]

Mais j'ai peur que ce concept ne soit que théorique, car en pratique et surtout pour un développeur, lui demander de repasser en revue la documentation (ou le code source) de toute une partie qu'il a codé la semaine dernière rien que pour rajouter une fonctionnalité risque d'être lassant pour lui...

Il existe des outils de rétro engineering pour créer des modèles de classes, de séquences, etc. Si le développeur en question est paumé, il peut utiliser ces outils-là. De plus, rien n'empêche que ces outils soient utilisés par un serveur d'intégration (toutes les nuits par exemple) pour générer les modèles à partir du code.
Autre possibilité : le travail en binôme et la responsabilité collective du code -> tous les développeurs travaillent par paire, et sur l'intégralité du code (en tournant régulièrement). Ainsi, on est plus à même de trouver quelqu'un dans l'équipe capable de donner des indications sur l'architecture.

[montesq]

Mais j'ai peur que ce concept ne soit que théorique, car en pratique et surtout pour un développeur, lui demander de repasser en revue la documentation (ou le code source) de toute une partie qu'il a codé la semaine dernière rien que pour rajouter une fonctionnalité risque d'être lassant pour lui...

Je ne comprends pas ta remarque. Dans la mesure où les tests sont automatisés, le développeur n'a pas besoin de passer en revue quoi que ce soit.
Par exemple sur le projet du CMS Drupal, chaque patch proposé par un membre de la communauté est ajouté sur un serveur spécifique qui exécute automatiquement l'ensemble des tests qui ont été codés précédemment pour s'assurer qu'aucune fonctionnalité n'est cassée. Si le patch passe le test, il peut potentiellement être commité par la suite dans le CVS. Dans le cas contraire, le patch doit être retravaillé.
Bien sûr il faut avoir une couverture de test la plus exhaustive possible et c'est pourquoi les certaines méthodes (XP me semble-t'il) préconisent même d'écrire toujours le test d'une fonctionnalité avant la fonctionnalité en elle-même.