Discussion:Processus unifié

Tout ceci fait référence à des produits de Rational (société acquise par IBM) ou commercialisés par des entités annexes (Essentiel UP par exemple).

La société Rational a en son temps recruté les principaux créateurs de méthodes et est devenue de ce fait incontournable sur ce sujet. L'historique a été développé pour montrer les contributions individuelles respectives. L'article a été retravaillé pour faire ressortir les points communs au processus unifié (non propriétaire) et isoler dans une section distincte les variantes propriétaires et commerciales. --Cth027 (discuter) 26 juin 2019 à 09:17 (CEST)

Améliorations nécessaires

J'ai modifié les liens multilingues de cet article pour pointer à présent sur les articles "Unified Process" dans les autres langues. En effet, auparavant il renvoyait sur des articles dédiés dans les autres langues à "Rational Unified Process", qui sont plus spécifiques que le processus général, ce qui aurait pu prêter à confusion.

Il faudrait maintenant:

• ajouter une section historique pour montrer l'évolution de RUP à UP Fait!
• débarrasser l'article de son jargon, et notamment des nombreuses abréviations bilingues (et anglicisme pour lesquels plusieurs ouvrages de référence en français on popularisé depuis un terme français largement accepté) Fait!
• il serait utile de préciser le modèle de phase et d'activités de cette méthode (cf. version anglaise) Fait!
• il faut ABSOLUMENT sourcer le contenu. Fait!
• La partie agile pourrait être issue d'une réflexion personnelle du ou des auteurs, qui bien que pertinente et digne d'intérêt, ne répond pas aux exigences de wikipédia en matière de vérifiabilité des informations. Réglé les principaux arguments ont été fusionnés au sein d'une nouvelle section positionnement, comparant PU et agile entre autres.

--Cth027 (discuter) 1 juin 2019 à 14:52 (CEST)

Titre de l'article

Je propose également de renommer l'article "Processus unifié", car il existe plusieurs livres et nombre d'articles francophones qui utilisent le terme français. Le terme anglais est rappelé dans l'introduction. --Cth027 (discuter) 21 juin 2019 à 18:30 (CEST)

Le renommage a été entrepris par un administrateur wikipedia.

Contenu à discuter

Critique attribuée à Scott Ambler sans référence

Texte en question:

« Selon Scott Ambler, certains fondements de PU ne peuvent coexister avec les préceptes d’agilité : la prééminence et le rôle moteur des diagrammes de cas d'utilisation doit être abandonné[réf. nécessaire]. En effet, s’ils permettent de documenter correctement les comportements du logiciel, ils ne pourront pas servir à piloter toutes les activité du projet : les contraintes, les interfaces utilisateurs et leur cinématique, les règles métier que devront respecter le logiciel ne peuvent être déduites des cas d'utilisation. PU ajoute d’ailleurs un ensemble de « spécifications supplémentaires » pour pallier ce manque. Ainsi, toujours selon Ambler, si l’analyse des besoins peut conduire le projet, les cas d’utilisations ne le peuvent pas et ne constituent qu’une rhétorique marketing propre aux instanciations telles que RUP ou EUP[réf. nécessaire].»

La critique est discutable car: - Martin Fowler considère au contraire PU comme agile. - PU se veut pilotée par les cas d'utilisation mais ne prétend pas que tout doit être déduit rien qu'à partir de ces diagrammes. - Par exemple, dans PU l'interface utilisateur est une activité à part, confié à un "designer" plutôt qu'à un analyste. Le designer travaille avec l'utilisateur pour concevoir l'UI qui doit couvrir un cas d'utilisation. Le DCU sert donc de fil conducteur plutôt que de source unique. - Par ailleurs, il est étonnant que Ambler affirme que EUP utilise les cas d'utilisation comme argument marketing, puisqu'il est co-auteur de EUP.

Il est donc nécessaire de sourcer précisément cette critique, et de présenter de façon équilibrée arguments et contre-arguments.