Discussion utilisateur:Rboens/Brouillon

Dernier commentaire : il y a 10 ans par AntoniaLudunge dans le sujet Contexte

Remarques globales

modifier
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)Répondre

Introduction

modifier
  • « Dans l'industrie du logiciel, il arrive de rencontrer plusieurs types de problèmes lors de l'application de certaines modifications. »
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)Répondre
  • 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)Répondre
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)Répondre

Contexte

modifier
  • 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)Répondre
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)Répondre
Justement, on parle de vieillissement lorsqu'elles ne correspondent plus. AntoniaLudunge (discuter) 5 janvier 2014 à 16:44 (CET)Répondre

Modifié. --Rboens (discuter) 4 janvier 2014 à 12:13 (CET)Répondre


Principe de base

modifier


  • « [...]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)Répondre
  • « [...] 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. »

L’importance de l’architecture logicielle

modifier
  • « 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)Répondre

Liaisons entre architectures et implémentations

modifier
Ah bon? AntoniaLudunge (discuter) 5 janvier 2014 à 14:55 (CET)Répondre

Causes de dégradations logicielles

modifier
Corrigé AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)Répondre
  • « 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 »
Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)Répondre

Changement des besoins utilisateurs

modifier
Corrigé AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)Répondre

Évolution du matériel

modifier
Par exemple? AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)Répondre

Allocation mémoire

modifier
  • « 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)Répondre

Reformulation effectuée AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)Répondre
  • « 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)Répondre

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)Répondre


  • « 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)Répondre

Nous voulons dire définir au préalabla, fixer... enfin des synonymes de prédéfinir. AntoniaLudunge (discuter) 5 janvier 2014 à 15:41 (CET)Répondre

Idées de solutions

modifier

Mise en place d’architectures adaptées

modifier
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)Répondre
corrigé AntoniaLudunge (discuter) 5 janvier 2014 à 15:55 (CET)Répondre
Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 15:55 (CET)Répondre
  • « 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). »
on fait allusion ici aux méthodes utilisant l'itération comme concept de base AntoniaLudunge (discuter) 5 janvier 2014 à 15:55 (CET)Répondre
Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 15:55 (CET)Répondre

Équilibre entre architecture, code, documentation lors des évolutions

modifier
  • « 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)Répondre

dans le modèle d'architecture ou encore dans la documentation! Non? AntoniaLudunge (discuter) 5 janvier 2014 à 16:29 (CET)Répondre
Pourquoi? AntoniaLudunge (discuter) 5 janvier 2014 à 16:29 (CET)Répondre
Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 16:29 (CET)Répondre

Maintenance

modifier
  • « Les processus de maintenances se basent [...] »

Pas de “s” à “maintenance". GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)Répondre

J'ai un doute, je vais vérifier AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)Répondre
  • « le modèle de réutilisation complète [...] »

Phrase répétée. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)Répondre

Doublon supprimé AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)Répondre
  • « 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)Répondre

Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)Répondre
  • « modèle de réutilisation complète [...] »

Phrase répétée. GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)Répondre

Supprimé AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)Répondre
Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)Répondre

Qu’est ce que cette phrase apporte dans le contexte de la maintenance ? GerardPaligot (discuter) 27 décembre 2013 à 17:55 (CET)Répondre

Que l'architecture doit être respectée même en phase de maintenance AntoniaLudunge (discuter) 5 janvier 2014 à 16:03 (CET)Répondre

Bonnes pratiques

modifier
Liste à puce mise en place AntoniaLudunge (discuter) 5 janvier 2014 à 16:10 (CET)Répondre
  • « 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)Répondre

  • « 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)Répondre

  • « 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)Répondre
Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 16:10 (CET)Répondre
Effectué AntoniaLudunge (discuter) 5 janvier 2014 à 16:10 (CET)Répondre

Technologies

modifier
  • 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)Répondre

Modifié AntoniaLudunge (discuter) 5 janvier 2014 à 16:11 (CET)Répondre
  • « 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. »

ArchJava

modifier
Retour à la page de l’utilisateur « Rboens/Brouillon ».