Discussion utilisateur:Rboens/Brouillon
Remarques globales[modifier le code]
- Les références ne sont pas bien formées. Vous devriez aller relire l'article Informatique 2.0. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Certaines sections manquent cruellement de références. J'indique les sections où il manque des références tout le long de la discussion. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Le mot "érosion" n’apparait jamais dans l’article alors que c’est votre sujet. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Je suis d'accord avec GerardPaligot, il y a beaucoup de références pas bien formées et de sections qui manqent de références. AugustinGusti (discuter) 2 janvier 2014 à 00:12 (CET)
- Il faudrait mettre plus de références vers les articles wikipedia pour les mots clés de cet article comme par exemple "architecture logicielle"AugustinGusti (discuter) 2 janvier 2014 à 00:12 (CET)
- Une conclusion à la fin pour résumer tout ce qui a été dit précédemment améliorerait la qualité de cet article AugustinGusti (discuter) 2 janvier 2014 à 00:12 (CET)
- On trouve souvent dans l'article "dégradations logicielles" mais pas du tout "l’érosion des architectures" qui est votre sujet AugustinGusti (discuter) 2 janvier 2014 à 00:12 (CET)
- Il manque une définition de ce qu'est l'érosion de l'architecture logicielle AugustinGusti (discuter) 2 janvier 2014 à 01:06 (CET)
- Le titre vu dans le tableau d' IIR n'est pas celui que nous garderons pour l'article, il nous a servit de repère tout simplement. Nous avons traduit erosion de l'anglais en dégradation par pure préférence mais ce sont des synonymes AntoniaLudunge (discuter) 5 janvier 2014 à 16:16 (CET)
Introduction[modifier le code]
- « Dans l'industrie du logiciel, il arrive de rencontrer plusieurs types de problèmes lors de l'application de certaines modifications. »
- Cette première phrase ne semble pas apporter grand-chose. Si vous la retirez, vous exposez un fait, une règle et les problèmes pratiques liées à cette règle. Vous mentionnez donc deux fois qu’il existe des problèmes. Sauf qu’à la première ligne, le lecteur n’a encore aucune idée de quoi il pourrait s’agir. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Phrase supprimée --Rboens (discuter) 30 décembre 2013 à 19:52 (CET)
- Cette première phrase ne semble pas apporter grand-chose. Si vous la retirez, vous exposez un fait, une règle et les problèmes pratiques liées à cette règle. Vous mentionnez donc deux fois qu’il existe des problèmes. Sauf qu’à la première ligne, le lecteur n’a encore aucune idée de quoi il pourrait s’agir. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « L'architecture logicielle permet de décrire comment doit être conçu le logiciel pour répondre aux spécifications de celui-ci. »
- La tournure de la phrase est un peu lourde et « celui-ci » correspond à quoi ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Le mot "celui-ci" fait référence au "logiciel" et c'est le seul nom masculin de la phrase. Je ne trouve pas cette phrase compliqué je laisse comme ça pour le moment. --Rboens (discuter) 30 décembre 2013 à 20:01 (CET)
- La tournure de la phrase est un peu lourde et « celui-ci » correspond à quoi ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « modèle d'architecture »
- Qu’est ce que le modèle d’architecture ? C’est l’architecture logicielle ? Si oui, il faudrait le mentionner quelque part. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- C'est la représentation de l'architecture logicielle sous forme de modèle. Je peux rajouter le mot "logicielle" mais il est déjà présent pour "implémentation logicielle" dans la même phrase. --Rboens (discuter) 30 décembre 2013 à 20:15 (CET)
- Qu’est ce que le modèle d’architecture ? C’est l’architecture logicielle ? Si oui, il faudrait le mentionner quelque part. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Votre sujet est l’érosion et ce mot ne figure pas dans votre introduction. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Ne soit pas choqué par cela car premièrement le sujet nous servait de repère, et deuxièmement dégradation est un synonyme d'érosion... AntoniaLudunge (discuter) 5 janvier 2014 à 16:17 (CET)
- Aucune référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- L'introduction porte plus sur les décalages entre l’implémentation du projet par rapport à l'architecture logicielle qui a été établie au départ que l’érosion des architecture logicielles. Il faudrait faire quelques modifications pour mieux introduire ce sujet-là AugustinGusti (discuter) 2 janvier 2014 à 00:51 (CET)
- les décalages entre l’implémentation du projet par rapport à l'architecture logicielle fait allusion à l'érosion logicielle AntoniaLudunge (discuter) 5 janvier 2014 à 16:34 (CET)
- Pour "spécifications" et "génie logiciel" il faudrait mettre des références vers les pages wiki qui leurs correspondent AugustinGusti (discuter) 2 janvier 2014 à 00:51 (CET)
- Ajouté --Rboens (discuter) 4 janvier 2014 à 12:09 (CET)
Contexte[modifier le code]
- Le « défaillance » est un synonyme de dégradation ou d’érosion ? Ca ne me semble pas exactement la même chose. Une défaillance indique une mauvaise implémentation qui engendre des comportements non désirable alors que l’érosion n’est pas forcément mauvais dans le sens où il arrive de s’écarter de l’architecture voulue pour une bonne raison comme lié à une technologie. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- En effet, dégradation et érosion sont synonymes mais défaillance pas exactement. Il ne me semble pas mauvais de parler des défaillances lorsque nous parlons de vieillissement logiciel. AntoniaLudunge (discuter) 5 janvier 2014 à 16:44 (CET)
- Une architecture logicielle retarde le vieillissement logiciel ? Pourquoi ? L’architecture logicielle de départ ne vieillit pas avec son implémentation logicielle puisqu’elles sont censées correspondre. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Justement, on parle de vieillissement lorsqu'elles ne correspondent plus. AntoniaLudunge (discuter) 5 janvier 2014 à 16:44 (CET)
- La citation n’est pas bien formée et ça manque globalement de références. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Par « "retarder" » vous voulez dire ralentir ? Je pense qu'il est préférable d’éviter les mots entre guillemets lorsque l'on peut écrire le mot approprié AugustinGusti (discuter) 2 janvier 2014 à 01:02 (CET)
Modifié. --Rboens (discuter) 4 janvier 2014 à 12:13 (CET)
- Il manque des références dans ce paragraphe, notamment pour la définition de la dégradation logicielle. Selon qui cette définition a été donné ? AugustinGusti (discuter) 2 janvier 2014 à 01:13 (CET)
Principe de base[modifier le code]
- « Tout projet est issue [...] »
- Il ne doit pas y avoir de “e” à issu. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Vu. --Rboens (discuter) 30 décembre 2013 à 20:38 (CET)
- « Pour satisfaire les futures utilisateurs [...] »
- Il ne doit pas y avoir de “e” à futurs. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Vu. --Rboens (discuter) 30 décembre 2013 à 20:38 (CET)
- L’image n’a pas de références et est-elle vraiment utile pour aider le lecteur dans la compréhension de ce point ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Je partage l'avis de GerardPaligot,si vous voulez détailler la relation entre besoin,architecture et implémentation par une image vous pouvez vous référer à l'article Cycle de développement (logiciel) autrement l'image ne me parait pas trop utile.AugustinGusti (discuter) 2 janvier 2014 à 01:55 (CET)
- On a créé l'image et on l'a ajouté à la bibliothèque de wikipedia c'est pour ça qu'il n'y a pas de références. Elle représente de manière simple ce qui est décrit dans le paragraphe qui lui est associé (Cycle de développement (logiciel) est trop detaillé) donc je ne la retire pas pour le moment. --Rboens (discuter) 4 janvier 2014 à 12:49 (CET)
- Je partage l'avis de GerardPaligot,si vous voulez détailler la relation entre besoin,architecture et implémentation par une image vous pouvez vous référer à l'article Cycle de développement (logiciel) autrement l'image ne me parait pas trop utile.AugustinGusti (discuter) 2 janvier 2014 à 01:55 (CET)
- Aucune référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « [...]Pour satisfaire les futurs utilisateurs, il est nécessaire d'étudier leurs besoins avant de développer une solution. Grâce à cela, il sera possible de définir une architecture logicielle adaptée, ce qui améliorera les performances de l'application.[...] »
- D'après cette phrase on comprend que grâce a l'étude des besoins des utilisateurs on conçoit une architecture qui améliore les performances de l’application. Le besoin de l'utilisateur et la performance de l'application sont deux choses différentes. Il faudrait enlever ou modifier {{citation|[...]ce qui améliorera les performances de l'application[...]} AugustinGusti (discuter) 2 janvier 2014 à 01:27 (CET)
- Remplacée par « [...]une architecture logicielle adaptée afin d'obtenir un résultat proche de celui escompté. » --Rboens (discuter) 4 janvier 2014 à 21:46 (CET)
- D'après cette phrase on comprend que grâce a l'étude des besoins des utilisateurs on conçoit une architecture qui améliore les performances de l’application. Le besoin de l'utilisateur et la performance de l'application sont deux choses différentes. Il faudrait enlever ou modifier {{citation|[...]ce qui améliorera les performances de l'application[...]} AugustinGusti (discuter) 2 janvier 2014 à 01:27 (CET)
- « [...] Avec une architecture bien définit, l'implémentation de la solution sera facilitée et correspondra mieux aux attentes du client si il n'y a pas de divergences entre les deux. »
- définit => définie;
- Corrigé. --Rboens (discuter) 4 janvier 2014 à 21:46 (CET)
- Il faudrait supprimer "et correspondra mieux aux attentes du client si il n'y a pas de divergences entre les deux." Comment une architecture peut "mieux" correspondre aux attentes du client puisque celle-ci est définie justement à partir de celles-ci?AugustinGusti (discuter) 2 janvier 2014 à 01:27 (CET)
- Ce n'est pas l'architecture mais la solution. La phrase veut dire que moins il y a de divergences entre l'implémentation et l'architecture, plus le résultat sera proche des attentes du client. --Rboens (discuter) 4 janvier 2014 à 21:46 (CET)
- définit => définie;
L’importance de l’architecture logicielle[modifier le code]
- « L'architecture logicielle permet de réaliser entièrement le logiciel sous une forme théorique avant de le réaliser de manière pratique »
Cette phrase sonne vraiment bizarre. Puis, ça serait une bonne chose d’éviter d’utiliser 2 fois le même verbe dans une phrase. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Vous parlez de 6 aspects mais vous faites une liste à puce. Vous devriez peut-être changer pour une liste à numéro. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Il n'y a pas de notion d'ordre entre les différents points donc je ne pense pas qu'une liste à numéro soit nécessaire. On énonce juste 6 aspects. --Rboens (discuter) 4 janvier 2014 à 21:54 (CET)
- Qu’une seule référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « [...] Ceci permet de prévoir les contraintes techniques, d'envisager les extensions de manière adaptée et de garantir la qualité du logiciel. [...] »
- Que veut dire "extensions"? Il faudrait remplacer ce terme par un mot plus approprié AugustinGusti (discuter) 2 janvier 2014 à 02:02 (CET)
- Remplacé par évolutions. --Rboens (discuter) 4 janvier 2014 à 21:54 (CET)
- Que veut dire "extensions"? Il faudrait remplacer ce terme par un mot plus approprié AugustinGusti (discuter) 2 janvier 2014 à 02:02 (CET)
- « [...]Par conséquent, Les [...] »
- Les => les AugustinGusti (discuter) 2 janvier 2014 à 02:02 (CET)
- Corrigé. --Rboens (discuter) 4 janvier 2014 à 21:54 (CET)
- Les => les AugustinGusti (discuter) 2 janvier 2014 à 02:02 (CET)
Liaisons entre architectures et implémentations[modifier le code]
- « Celles-ci permettront de détecter lorsque l'implémentation sera en train de dévier du modèle lors de l'analyse. »
- Tournure de phrase bizarre. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Je suis d'accord avec GerardPaligot, phrase obscure.AugustinGusti (discuter) 2 janvier 2014 à 02:18 (CET)
- Remplacé par « Celles-ci permettront de détecter lorsque l'implémentation sera en train de dévier de l'architecture. » --Rboens (discuter) 4 janvier 2014 à 21:58 (CET)
- « il y a trois types de résultat possible [...] »
- Je ne suis pas certain mais je mettrais "résultat possible" au pluriel. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Convergence : La relation implémenté [...] »
- Il manque un “e” à "implémenté". GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Divergence : La relation implémenté [...] »
- Il manque un “e” à "implémenté". GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « La pratique la plus courante est de modifier le code pour qu'il corresponde à l'architecture [...] »
- Pas de “e” à "correspond“. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Je ne pense pas, c'est du subjonctif. --Rboens (discuter) 4 janvier 2014 à 22:03 (CET)
- Pas de “e” à "correspond“. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- 3 références pour 4 paragraphes. Chaque paragraphe doit au moins contenir une référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
Causes de dégradations logicielles[modifier le code]
- Deux fois “causes”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Ces changements sont nécessaires pour diverses raisons. » Changer "diverses raisons" par "les suivantes raisons" puisque vous les développez après AugustinGusti (discuter) 2 janvier 2014 à 02:33 (CET)
- « Les principales causes causes, p. 279 des dégradations logicielles sont les modifications apportées au code, à la documentation dans le non-respect des règles architecturales »
- Phrase obscure. Quel est le rapport entre la dégradation logiciel et la documentation? Que veut dire règles architecturales?AugustinGusti (discuter) 2 janvier 2014 à 02:47 (CET)
- Mettre les références d'articles au bon format wikipedia AugustinGusti (discuter) 2 janvier 2014 à 02:47 (CET)
Changement des besoins utilisateurs[modifier le code]
- Aucune référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « [...]Ces deux point[...] » point=>points AugustinGusti (discuter) 2 janvier 2014 à 02:54 (CET)
Évolution du matériel[modifier le code]
- Aucune référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET) l'article cité précédemment
- « Une autre cause de dégradations de logicielles est le matériel auquel se rattache le logiciel »
- Se rattache le logiciel veut dire sur lequel est présent le logiciel?Mettre un mot plus approprié AugustinGusti (discuter) 2 janvier 2014 à 03:07 (CET)
- Par exemple? AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)
Allocation mémoire[modifier le code]
- « Une conséquence des causes (modifications de code) entraîne [...] »
Des causes rapportent aux modifications de code ? Si oui, les modifications de code se rapportent à quoi ? Si non, les causes se rapportent à quoi ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Je suis d'accord avec GerardPaligot. Cette phrase devrait être reformulerAugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Reformulation effectuée AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)
- « En effet, plus des modifications sont apportées au logiciel, plus la taille du programme grandit, et plus la taille du programme grandit plus la mémoire demandée au système est conséquente. »
Cette phrase est immense. Elle pourrait être divisée, réduite et vous répétez plusieurs fois le même mot (comme “grandit”). GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Du même avis que GerardPaligot. Il y a trop de répétition du mot "plus"AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- En effet, la répétition est une faute de style mais dans cette phrase elle est utilisée pour illustrer l'idée : "grossissement de programme => grossissement mémoire" AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)
- « Il est difficile de prédéfinir la mémoire à allouer. »
Vous vouliez dire “prévoir” non ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Nous voulons dire définir au préalabla, fixer... enfin des synonymes de prédéfinir. AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)
Idées de solutions[modifier le code]
- Le titre n’est pas français ou changez “de” pour “des”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Il l'est. --Rboens (discuter) 5 janvier 2014 à 12:57 (CET)
- « Certaines technologies (dont certaines citées plus bas) permettant de faire face aux dégradations, cependant il y a certains éléments pratiques à mettre en place pour conserver la qualité des logiciels. »
- Cette phrase est énorme. Vous pouvez la couper avant “cependant”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Phrase coupée. --Rboens (discuter) 5 janvier 2014 à 12:57 (CET)
- Vous répétez plusieurs fois “certain(e)s”. La phrase devient vite lourde. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Modifié. --Rboens (discuter) 5 janvier 2014 à 12:57 (CET)
- Mettre "permettent" à la place de "pemettant" AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 12:57 (CET)
- Cette phrase est énorme. Vous pouvez la couper avant “cependant”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Une seule référence, manque de références. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
Mise en place d’architectures adaptées[modifier le code]
- « Le but de la phase de conception est de créer un design qui peut accueillir des demandes de changements futures [...] »
- Pourquoi vous parlez de design ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Design ici c'est modèle d'architecture étant donné qu'on parle de phase de conception, il te semble inapproprié comme terme? AntoniaLudunge (discuter) 5 janvier 2014 à 15:55 (CET)
- Futurs sans “e”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- "qui peut accueillir" terme mal choisi AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- « Ceci est en contradiction avec l'itérative nature de nombreuses méthodes de développement (extrême pro- programming, le prototypage rapide, etc) car ces méthodologies incorporent généralement de nouvelles exigences qui peuvent avoir un impact architectural, au cours de développement alors qu'une bonne conception nécessite des connaissances au sujet de ces exigences à l'avance(design erosion : problems and causes, p. 106). »
- C‘est la plus longue phrase de tous les temps ! Faut vraiment la diviser. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Qu’est ce que « l’itérative nature » ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- on fait allusion ici aux méthodes utilisant l'itération comme concept de base AntoniaLudunge (discuter) 5 janvier 2014 à 15:55 (CET)
- La fin de la phrase n’est pas compréhensive. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Il manque des virgules et je pense également qu'il faudrait essayer de la diviser.AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- "au cours de développement"=>"au cours du développement"AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Une seule référence pour 3 paragraphes. Manque de références. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
Équilibre entre architecture, code, documentation lors des évolutions[modifier le code]
- Le titre devrait plutôt être “Équilibre entre architecture, code et documentation lors des évolutions”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Lorsqu'il y a des modifications à apporter au logiciel, il semble plus simple (moins cher) d'appliquer ces modifications dans le code. »
Les modifications peuvent être appliquées où ça à part dans le code ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- dans le modèle d'architecture ou encore dans la documentation! Non? AntoniaLudunge (discuter) 5 janvier 2014 à 16:29 (CET)
- « En effet, il faut garantir à chaque itération (modification) dans le code que les règles d'architectures sont respectées [...] »
- Il faut changer “sont” par “soient”. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Pourquoi? AntoniaLudunge (discuter) 5 janvier 2014 à 16:29 (CET)
- Dans "itération (modification)", itération et modification sont deux choses différentes, si par itération on veut dire modification pourquoi ne pas mettre ce mot directement dans cette phrase AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Aucune référence. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
Maintenance[modifier le code]
- « Les processus de maintenances se basent [...] »
Pas de “s” à “maintenance". GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- J'ai un doute, je vais vérifier AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)
- « le modèle de réutilisation complète [...] »
Phrase répétée. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Doublon supprimé AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)
- « La réutilisation permet de gagner du temps, réduire le coût mais peut s'avérer dangereux il est donc important de : [...] »
Il manque un “.” : « … dangereux. Il est donc important de : » GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « modèle de réutilisation complète [...] »
Phrase répétée. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Supprimé AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)
- « Il est important lors de la maintenance, de respecter les règles architecturales surtout lors de l'intégration de nouveaux composants. »
- Virgule avant "surtout" AugustinGusti (discuter) 2 janvier 2014 à 03:01 (CET)
Qu’est ce que cette phrase apporte dans le contexte de la maintenance ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Que l'architecture doit être respectée même en phase de maintenance AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)
Bonnes pratiques[modifier le code]
- Les bonnes pratiques sont exposées sans aucune introduction ni même listé dans une liste à puce. Il faudrait revoir la forme de cette section. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Liste à puce mise en place AntoniaLudunge (discuter) 5 janvier 2014 à 16:10 (CET)
- « Trouver le bon compromis entre les stratégies d'efforts, p. 117 d'efforts : minimal et optimal. »
Qu’est ce que c’est les stratégies d’efforts ? Vous n’en avez jamais parlé avant. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Utiliser le concept PDCA (Plan, Do, Check, Act, p. 289) »
Même chose que pour les stratégies d’efforts. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Manque de références. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Lors de la conception, prévoir une architecture décrivant le logiciel répondant aux besoins clients tout en laissant les "portes ouvertes" permettant de l'étendre; et lors de l'implémentation garder également ses "portes ouvertes" tout en respectant les règles imposées par l'architecture. » Remplacer le mot entre guillemets "portes ouvertes" par le mot approprié (possibilités ou un autre) AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Il faudrait faire une introduction et liste à puce pour cette partie AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Effectué AntoniaLudunge (discuter) 5 janvier 2014 à 16:10 (CET)
Technologies[modifier le code]
Card[modifier le code]
- Manque de références.
- « Ce framework contient deux modules de prétraitement : l'un pour les diagramme UML 2.0 et l'autre pour le code source Java. »
- les diagramme=>les diagrammes
AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
SAVE[modifier le code]
- « Institute for Experimental Software Engineering »
- Vous devriez traduire le début de cette parenthèse. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Traduit. --Rboens (discuter) 5 janvier 2014 à 03:55 (CET)
- Vous devriez traduire le début de cette parenthèse. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Center for Experimental Software Engineering »
- Vous devriez traduire le début de cette parenthèse. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Traduit. --Rboens (discuter) 5 janvier 2014 à 03:55 (CET)
- Vous devriez traduire le début de cette parenthèse. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Ce plugin à également été testé [...] »
- a et pas à. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:55 (CET)
- a et pas à. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « L'étude montre que après quelques semaines, les groupes d'étudiants qui développaient avec le plugin faisaient beaucoup moins d'erreur d'implémentations et que au final le projet était plus proche du résultat attendu que celui des autres groupes. »
- Phrase trop longue. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Remplacé par L'étude montre que après quelques semaines, les groupes d'étudiants qui développaient avec le plugin faisaient beaucoup moins d'erreurs d'implémentations. Au final, le projet était plus proche du résultat attendu que celui des autres groupes. --Rboens (discuter) 5 janvier 2014 à 03:55 (CET)
- Phrase trop longue. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « SAVE est un outils de développemen[...] » outils=>outil AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:55 (CET)
- « [...] les groupes d'étudiants qui développaient avec le plugin faisaient beaucoup moins d'erreur d'implémentations »
- erreur=>erreurs AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:55 (CET)
- erreur=>erreurs AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Manque de références. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
ArchJava[modifier le code]
- « ArchJava est l'une des premières solution développés afin de contrôler [...] »
- des premières solutions développées afin de … GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- des premières solutions développées afin de … GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « Ces contraintes sont spécifiés [...] »
- Ces contraintes sont spécifiées … GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- Ces contraintes sont spécifiées … GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « quelles sont les méthodes autorisés [...] »
- quelles sont les méthodes autorisées … GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- quelles sont les méthodes autorisées … GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- « [...]Etats-unis [...] »
- Etats-Unis… AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- Etats-Unis… AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- « [...]des entitées [...] »
- des entités… AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- des entités… AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- « [...]Peut-on définir l'architecture d'un projet à grande échelle avec ArchJava.Quel est le coup d'un refactoring d'un projet Java vers ArchJava.ArchJava permet-il l'évolution logicielle[...] »
- Il faudrait finir ses phrases avec ?AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- Il faudrait finir ses phrases avec ?AugustinGusti (discuter) 2 janvier 2014 à 03:10 (CET)
- « Une étude a été mené [...] »
- Une étude a été menée ... GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Corrigé. --Rboens (discuter) 5 janvier 2014 à 03:37 (CET)
- Une étude a été menée ... GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)
- Manque de références. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)