Affichage des résultats du sondage: À quel moment passez-vous à une nouvelle version d'un langage ?

Votants
21. Vous ne pouvez pas participer à ce sondage.
  • Quand la nouvelle version est supportée par les technologies que j'utilise

    8 38,10%
  • Quand j'estime que la nouvelle version intègre suffisamment de nouveautés intéressantes

    9 42,86%
  • Quand celle que j'utilise arrive ou approche sa fin de vie

    6 28,57%
  • Dès que la migration est plutôt facile à faire

    6 28,57%
  • J'ai une préférence pour les versions LTS

    5 23,81%
  • J'attends toujours les feedbacks des premiers utilisateurs pour me décider

    5 23,81%
  • Le choix m'est imposé en général par mon entreprise ou mes clients

    6 28,57%
  • Autre (à préciser)

    2 9,52%
  • Pas d'avis

    0 0%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
  1. #21
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 558
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 558
    Points : 17 085
    Points
    17 085
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    Moi j'aurais mis "plateformes/runtimes plus supportés" et pas "langages plus supportés". Dire qu'un langage n'est plus supporté n'a pas grand sens.

    ../..

    Tous ces mots ont un sens, ce n'est pas pour qu'on les utilise à tort et à travers.
    Tout à fait...

    Et je pense que, si j'étais méchant () je dirais "bien fait !!" par rapport au constat du PO..

    Car dans le fond, on nous fait miroiter depuis presque 20 ans que c'est super, les biblios, les frameworks, etc etc... Les "nouveaux devs" ne jurent que par ça, tout comme leurs chefs...

    Tant pis pour eux si ils "oublient" que les versions changent rapidement, et qu'ils se basent sur ces "features"...


    En fait, comme tu le dis, du point de vue des langages les choses évoluent beaucoup plus lentement, sans parler de certains acceptant les délais mis en place lors des "anciens" langages (5 ans pour avertir d'une obsolescence prévue- 10 ans pour la mettre en place) comme Fortran, C, etc etc..


    La règle de base que j'ai toujours eue est : ne JAMAIS utiliser les "features" spéciales , sauf pour les "flags/drapeaux" de compil' ... Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionalités dont on a besoin pour faire tout ce qu'on veut en programmation....

    Et si on ne sait pas s'en servir, on n'est pas un "programmeur", donc - à mon avis - on n'a rien à faire dans une équipe de fabrication d'un logiciel...



    Citation Envoyé par clementmarcotte Voir le message
    Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées
    C'est surtout que c'est plutôt l'inverse : on faisait des programmes pour qu'ils durent.... Les langages utilisés - comme celui que tu cites - est toujours là 40 ans plus tard... Comme mes programmes en Fortran ou C...

    En ce qui concerne le "bug de l'an 2000", c'est surtout qu'on n'y avait pas pensé... et qu'on n'avait pas les moyens techniques :

    • d'une part 20 ans c'est long et personne en 1980 ne pensait que dans le monde entier tout serait connecté.... et que donc une "faille" pourrait créer un chaos à l'échelle planétaire.... (ce qui d'ailleurs n'a pas été le cas et a été une mine d'or pour toutes les SSII....)

    • Mais d'autre part, la mémoire était "ridicule" par rapport à aujourd'hui .. J'ai fait des programmes de traitement d'images en 1986 avec 64K de mémoire "programme" et 64K de "data"... 3 lignes d'une image 512x512 8-bits, OU uniquement le "switch" des fonctionalités (un switch contenant juste "addition, soustraction, multiplication, zoom, déplacement, et sauvegarde, avec l'appel des fonctions" était tout ce que pouvait prendre la mémoire) .. Donc on fait ce qu'on peut avec les moyens qu'on a ...


      Exemple d'un programme en 1984-86 sur PDP 11/23 :

      Code FORTRAN : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      program toto()
      integer*8 icode
       
      READ (5, *) icode
       
      switch (icode) {
       case lire : 
           call readim()
           break
       case ecrire : 
           call writeim()
           break
       case add: 
           call add()
           break
       case sub : 
           call sub()
           break
       case mul : 
           call mul()
           break
       case zoom : 
           call zoom()
           break
       case shift : 
           call shift()
           break
      }
      END
      (ou à peu près, je fais de mémoire... )





    Citation Envoyé par clementmarcotte Voir le message
    Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.
    Avec raison...

    Quand quelque chose marche, pourquoi le remplacer ???

    On proteste contre l'obsolescence programmée, mais les programmes non-obsolètes, pourquoi les changer si ce n'est parce que on ne trouve plus de programmeurs capables de comprendre/modifier ces programmes...

    J'ai vu des échecs monumentaux, et j'ai participé à ce que je soupçonne être des échecs monumentaux (les retards de la SNCF qui augmentent dans les dernières années par exemple...)... lors de ré-écritures... D'une part parce que la connaissance accumulée est loin d'être entièrement documentée, et il faudrait aller la rechercher profondément dans le code, en comprenant absolument tout et en reconstruisant tous les arbres et le flux, mais aussi parce que fondamentalement tout nouveau code génère son lot de bugs... par définition....



    (un bon lien que j'ai déjà donné à ce sujet est ici : Rewrites Considered Harmful?, et, bien qu'écrit en 2004, il ne vieillit pas )



    PS: j'ai voté "quand ça arrive en fin de vie"
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  2. #22
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 820
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 820
    Points : 20 461
    Points
    20 461

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Car dans le fond, on nous fait miroiter depuis presque 20 ans que c'est super, les biblios, les frameworks, etc etc... Les "nouveaux devs" ne jurent que par ça, tout comme leurs chefs...

    Tant pis pour eux si ils "oublient" que les versions changent rapidement, et qu'ils se basent sur ces "features".
    un lien rigolo qui va avec ça : https://workplace.stackexchange.com/...-forced-on-the

    quelques extraits avant que ça ne soit définitivement clos :

    Citation Envoyé par un manager pas très au point
    We recently implemented a mandate that everyone has to now use a Windows laptop with various security tools installed on it for auditing, backup, and legal purposes. A new software tool for how we write code (i.e. a Visual Studio) also now has to be used.(.../...) 5 particular senior engineers are objecting to this. They have some common setup where they do almost everything from the command-line and using some antiquated console text editors (vim and emux, I think). (.../...) After finally having their laptops seized and replaced, their productivity as a whole has dropped off a cliff. (.../...)

    I refuse to believe that a command-line interface and antiquated text editor gives that much of a performance boost to these guys, as I've seen very productive Windows developers as well (though our product is Linux). They are senior level and smart, and I think this is just their way of pouting, but I need them to get back to business as usual.
    Citation Envoyé par souviron34 Voir le message
    La règle de base que j'ai toujours eue est : ne JAMAIS utiliser les "features" spéciales , sauf pour les "flags/drapeaux" de compil' ... Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionnalités dont on a besoin pour faire tout ce qu'on veut en programmation....
    Tiens, ça me rappelle ce vieux blog de Joel Spolsky. Identifier les dépendances, et les éliminer.

    Citation Envoyé par souviron34 Voir le message
    Quand quelque chose marche, pourquoi le remplacer ???

    On proteste contre l'obsolescence programmée, mais les programmes non-obsolètes, pourquoi les changer si ce n'est parce que on ne trouve plus de programmeurs capables de comprendre/modifier ces programmes...
    Parceque ça fait bien sur le CV, une refonte réussie. D'ailleurs, j'ai plusieurs refonte réussies à mon actif, et ça fait très bien sur mon CV. Même que parfois, on m'a dit que j'en faisais trop à ce sujet(pourtant c'est vrai).....

    Citation Envoyé par souviron34 Voir le message
    J'ai vu des échecs monumentaux, et j'ai participé à ce que je soupçonne être des échecs monumentaux (les retards de la SNCF qui augmentent dans les dernières années par exemple...)... lors de ré-écritures... D'une part parce que la connaissance accumulée est loin d'être entièrement documentée, et il faudrait aller la rechercher profondément dans le code, en comprenant absolument tout et en reconstruisant tous les arbres et le flux, mais aussi parce que fondamentalement tout nouveau code génère son lot de bugs... par définition....
    (un bon lien que j'ai déjà donné à ce sujet est ici : Rewrites Considered Harmful?, et, bien qu'écrit en 2004, il ne vieillit pas )[/QUOTE]

    C'est pour ça qu'une bonne refonte repart directement du code existant(merde, deux joel Spolsky dans le même commentaire, je dépasse les quotas). Si j'étais parti d'une feuille blanche, je me serais planté dans les grandes largeurs.

    Quand j'ai refondu les avis d'échéance d'un assureur, j'ai trouvé une bonne quinzaine de fois exactement le même code(je change juste le nom des données) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    IF CODE-ROUTAGE  "09" OR "59"
        MOVE "C" TO STYLE-ROUTAGE
    END-IF.
    Et personne dans la boite ne savait ce que ça voulait dire. Le code datait de 1972, et on était en 2008. après des mois, on a fini par trouver : en fait, il y avait un contrat spécial pour les courriers vers l'Alsace Lorraine(qui correspondait aux codes région 09 et 59, l'appellation code routage était trompeuse), et il fallait y associer une certaine tarification. Le truc, c'est que 36 ans de maintenance mal maitrisée avait dispersé ce code absolument partout, on le retrouvait dans chaque programme spécifique à un produit, parfois même plusieurs fois.

    Cet exemple démontre à la fois l'importante d'une refonte(il n'en restait plus qu'un seul exemplaire après mon passage - ils on gagné plus d'un équivalent temps plein en maintenance sur l'appli après la refonte), mais aussi la nécessite de repartir du code - la seule documentation vraiment fiable. Jamais personne n'aurait deviné ça si je n'étais pas tombé dessus. Et on aurait eu des problèmes de facturation des envois courrier à répétition.

    La doc c'est de la merde. Seul le code fait foi. Et plus il est ancien, plus il a accumulé de savoir-faire. Une bonne refonte valorise ce savoir faire. Une mauvaise refonte le méprise. Moi, j'ai toujours réussi mes refontes parceque j'ai toujours respecté les petits rustines et autres verrues mises en place par mes prédécesseurs. Elles avaient toutes une raison d'être. Elles pouvaient être mal faites, être refactorisables, mais elles devaient rester. Toutes.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #23
    Candidat au Club
    Homme Profil pro
    Consultant informatique
    Inscrit en
    janvier 2017
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : janvier 2017
    Messages : 4
    Points : 4
    Points
    4

    Par défaut NON PERTINENT

    21 réponses: ce sondge n'est pas pertinent. 21 réponses ne peuvent refléter la réalité

  4. #24
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 423
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 423
    Points : 12 860
    Points
    12 860

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionalités dont on a besoin pour faire tout ce qu'on veut en programmation....
    ehhh monsieurs Souviron34 et El_slapper je crois qu'il faudrait régler vos montres, on n'est plus il y a 20 ou 30 ans à faire des programmes en langage C avec la philosophie de Kerningan et Richie !
    Stricto sensu vous avez raison mais maintenant un projet informatique du fait de l'assemblage de technologies existantes ce que l'on appelle pompeusement "intégration logicielle" c'est du développement avec 50-70 % de dépendances et modules externes.
    Et que faire du code maintenant dans un projet d'entreprise ça se réduit plus à faire du paramétrage qu'à faire du code encore faudrait-il faire la nuance entre ces deux notions certes.
    D'ailleurs c'est pour ça que des géants comme IBM, Salesforces,Google commercialisent des systèmes d'API web sur le Cloud.
    Sans compter des trucs comme la Blockchain..
    Maintenant on est arrivé l'interconnectivité web via des API modulaires.
    Ce qui fait qu'une entreprise qui veut développer un projet informatique via une SSII ou non ,en fait va développer une partie très limitée du projet,tout le reste c'est des modules externes donc forcément payant
    Ne dites pas : "chercher la petite bête" mais plutôt "effectuer un travail d'entomologiste."
    Pour corriger des bugs c'est pareil

  5. #25
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 558
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 558
    Points : 17 085
    Points
    17 085
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Mat.M Voir le message
    ehhh monsieurs Souviron34 et El_slapper je crois qu'il faudrait régler vos montres, on n'est plus il y a 20 ou 30 ans à faire des programmes en langage C avec la philosophie de Kerningan et Richie !
    Stricto sensu vous avez raison mais maintenant un projet informatique du fait de l'assemblage de technologies existantes ce que l'on appelle pompeusement "intégration logicielle" c'est du développement avec 50-70 % de dépendances et modules externes.
    ../..
    Ce qui fait qu'une entreprise qui veut développer un projet informatique via une SSII ou non ,en fait va développer une partie très limitée du projet,tout le reste c'est des modules externes donc forcément payant
    As-tu lu le post original ???????
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  6. #26
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 423
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 423
    Points : 12 860
    Points
    12 860

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    As-tu lu le post original ???????
    oui je l'ai lu ,errare humanum est perseverare diabolicum
    Citation Envoyé par souviron34 Voir le message
    Quand quelque chose marche, pourquoi le remplacer ???
    je l'ai écris un milliard de fois sur ce forum ; l'économie de marché donc le marché des hautes technologies et des gros éditeurs de logiciel forcent les choses à se renouveler donc effectivement par le biais de l'obsolescence.

    Ce qui leur permet de gagner de l'argent et de faire des montagnes de dollar$ .

    Bref le projet informatique que la moindre entreprise a mis avec tant de peine à finaliser, une fois bien finalisé et fonctionnel, les gros éditeurs ( suivez mon regard ) vont vous dire que le projet est technologiquement obsolète et qu'il faut passer à une nouvelle voie technologique ( comme le Cloud ) alors que l'entreprise n'en a absolument pas besoin..

    bref l'entreprise ou bien vous et moi vont devoir mettre la main à la poche pour de nouveaux investissements technologiques coûteux alors que oui ça tourne très bien et qu'il ne faut rien changer effectivement.

    De toute façon les gros éditeurs ils s'en fichent royalement si le projet informatique échoue, ils sont là pour vendre leurs produits.
    J'ai travaillé dans un paquet d'entreprises sur des projets logiciels notamment pour un éditeur de logiciel d'immobilier il faut acheter Ms-Office en même temps que le logiciel pour sortir des rapports
    Citation Envoyé par souviron34 Voir le message
    D'une part parce que la connaissance accumulée est loin d'être entièrement documentée
    d'un autre côté produire des tonnes de documentation est-ce bien utile ? La on est dans l'absolutisme bureaucratique qui consiste à décrire tout ce que l'on fait au lieu de produire des chose de manière concrète
    Ne dites pas : "chercher la petite bête" mais plutôt "effectuer un travail d'entomologiste."
    Pour corriger des bugs c'est pareil

  7. #27
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 474
    Points : 2 110
    Points
    2 110

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    La doc c'est de la merde. Seul le code fait foi.
    Citation Envoyé par Mat.M Voir le message
    d'un autre côté produire des tonnes de documentation est-ce bien utile ? La on est dans l'absolutisme bureaucratique qui consiste à décrire tout ce que l'on fait au lieu de produire des chose de manière concrète
    Attention, sans une documentation à jour, seuls les développeurs peuvent vraiment savoir comment fonctionne le logiciel.
    Or, quand des clients remontent des problèmes au centre d'assistance, moins le personnel du centre d'assistance connaît le fonctionnement du logiciel, plus il a tendance à relayer directement les problèmes aux développeurs, même les problèmes qui ne viennent pas de bogues du logiciel.
    Les développeurs perdent alors du temps à faire du travail du centre d'assistance "au lieu de produire des choses de manière concrète".

  8. #28
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 423
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 423
    Points : 12 860
    Points
    12 860

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Attention, sans une documentation à jour, seuls les développeurs peuvent vraiment savoir comment fonctionne le logiciel.
    je n'ai jamais affirmé le contraire ; cependant il faut savoir mettre le curseur comme il faut, faut pas en faire des tonnes comme il ne faut pas en faire de manière insuffisante.
    Or faire trop de documentation c'est coûteux à mon sens ; cela va à l'encontre de l'intérêt de l'informatisation qui a pour but de simplifier les choses.
    Citation Envoyé par Pyramidev Voir le message
    Or, quand des clients remontent des problèmes au centre d'assistance, moins le personnel du centre d'assistance connaît le fonctionnement du logiciel, plus il a tendance à relayer directement les problèmes aux développeurs, même les problèmes qui ne viennent pas de bogues du logiciel.
    Les développeurs perdent alors du temps à faire du travail du centre d'assistance "au lieu de produire des choses de manière concrète".
    ça c'est toute la problèmatique d'un projet logiciel...souvent les fonctionnalités du logiciel sont insuffisantes ou mal définies, par manque de ressources humaines et financières.
    Cela rejoint quelque part ce qu'écrivent Souviron34 et El_slapper..
    Et puis avec le turn-over des équipes techniques notamment de développeurs ça n'arrange vraiment pas les choses.
    Ne dites pas : "chercher la petite bête" mais plutôt "effectuer un travail d'entomologiste."
    Pour corriger des bugs c'est pareil

  9. #29
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 820
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 820
    Points : 20 461
    Points
    20 461

    Par défaut

    Citation Envoyé par Mat.M Voir le message
    je n'ai jamais affirmé le contraire ; cependant il faut savoir mettre le curseur comme il faut, faut pas en faire des tonnes comme il ne faut pas en faire de manière insuffisante.
    Or faire trop de documentation c'est coûteux à mon sens ; cela va à l'encontre de l'intérêt de l'informatisation qui a pour but de simplifier les choses.
    Le truc aussi, c'est qu'indépendamment de la problématique technique(origine de ce fil) ou du manque de ressources(que tu évoques après), un logiciel, ça change assez vite au niveau des fonctionnalités. Donc maintenir une doc à jour, c'est extrêmement couteux, et généralement faux...sauf si la doc est juste un point d'entrée. Plus elle est précise, et plus vite elle est fausse. Trouver le juste milieu est souvent un casse-tête.

    Citation Envoyé par Mat.M Voir le message
    ça c'est toute la problèmatique d'un projet logiciel...souvent les fonctionnalités du logiciel sont insuffisantes ou mal définies, par manque de ressources humaines et financières.
    Cela rejoint quelque part ce qu'écrivent Souviron34 et El_slapper..
    Et puis avec le turn-over des équipes techniques notamment de développeurs ça n'arrange vraiment pas les choses.
    Et aussi par une vision projet : on a le projet d'ajouter des trucs, one ajoute des trucs, ça marche, on est contents..... Mais ça manque d'une vision globale de l'application. C'est la nouvelle marotte de Martin Fowler et de son ami Sriram Narayan. Narayan insiste en particulier sue le "you build it, you run it".

    Et Narayan insiste aussi sur un point rigolo : l'avantage du mode projet est que le "succès" pour les managers est facile à mesurer. Sur un produit en travail continu, il est plus délicat(même si pas impossible) de mettre en œuvre des KPI pertinents. D'ou la tendance des managers à se ruer sur le mode projet pour faire briller leur carrière.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Discussions similaires

  1. Requete sur des champs qui ne sont pas dans une autre table
    Par jean christophe dans le forum Débuter
    Réponses: 4
    Dernier message: 20/05/2010, 19h05
  2. Réponses: 2
    Dernier message: 28/12/2007, 19h14
  3. obtenir des entrees qui ne sont pas dans une table
    Par firejocker dans le forum SQL Procédural
    Réponses: 7
    Dernier message: 27/12/2007, 00h07
  4. Réponses: 6
    Dernier message: 29/06/2007, 11h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo