IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Ce qui fait la différence entre un simple projet et un bon projet


Sujet :

Débats sur le développement - Le Best Of

  1. #41
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    Enfin dernière remarque, tu sembles penser qu'il est effectivement possible de trouver tous les bugs existants dans une application. Pourtant, tout le monde sait qu'en informatique, le 0 défaut n'existe pas. S'il existait une méthode miracle qui t'assure qu'un programme ne contient aucun bug, tout le monde s'en servirait et le mot "bug" n'existerait que dans son sens premier...
    Tu peux utiliser un outil comme Coq, qui peut vérifier à 100% qu'un code donné en Coq correspond bien à une spécification de haut-niveau (évidemment si celle-ci est incorrecte...), la solution existe donc, mais le coût d'utilisation d'une telle méthode pour écrire des programmes non-triviaux est énorme et complètement disproportionné par rapport aux bénéfices pour une entreprise normale. Maintenant il y a des cas où tu préfères que ton code soit certifié conforme à la spécification (le domaine médical, les logiciels d'avions de ligne, ... tous les cas mettant en jeu la vie humaine), mais même dans ces cas, les outils de certifications ne sont pas toujours utilisés. (J'ai parlé de Coq, mais ce n'est qu'un exemple, d'ailleurs mal adapté à un certain nombre d'autres contraintes souvent rencontrées dans les cas critiques (temps réel), il existe par exemple des méthodes de certification pour du C (ex : Caduceus), ...)

    --
    Jedaï

  2. #42
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Points : 4 170
    Points
    4 170
    Par défaut
    si l'expert guide bien l'analyse statique, ça peut réduire les fausses alertes, et permettre aux développeurs de se consacrer sur les vraies erreurs
    Tien, je n'avais même pas pensé que l'analyse statique pouvait signaler de fausses erreurs...

    à l'époque de Pasteur, tout le monde savait que la génération spontanée était une évidence, à celle de Copernic que le Soleil tournait autour de la Terre... on a même tué ou failli tuer ces hommes pour avoir dit le contraire. Pourtant, force est de constater que notre conception de ces problématiques a bien changé depuis
    Bonne réponse. Mais c'était une façon rapide de dire que depuis le début de l'informatique, les mathématiciens essaient de traiter l'informatique comme s'il s'agissait de mathématiques.
    A ce titre, ils ont tenté les spécifications formelles. Pour arriver très vite à la conclusion que dans la pratique, il y a tellements de cas que c'est très vite incompréhensibles et inutilisables, même sur des problèmes simples.
    Dans le même ordre d'idée, ils ont démontré que du fait de l'explosion combinatoire dont tu parles, même le programme le plus simple devient très vite intestable de façon exhaustive car le nombre de cas de figure à tester devient vite astrosnomique. Ce qui fait qu'on ne peut jamais garantir qu'un programme est sans bug.


    Peut-être qu'un jour, on découvrira que c'est tout à fait possible, ou que les machines seront tellement puissantes qu'on pourra traiter l'explosion combinatoire sans problèmes. Mais la majorité des développeurs ne travaille pas dans un labo de recherche et doit se contenter de solutions réalisables, rapides fiables et surtout rentables...

    D'autant plus que rien de tout ça ne permet de détecter les erreurs de conception ni les erreurs de spécifications. Et je ne parle même pas du client qui a dit blanc tout en pensant noir alors qu'en réalité, il voulait violet...

  3. #43
    Membre actif
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    250
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 250
    Points : 259
    Points
    259
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    D'autant plus que rien de tout ça ne permet de détecter les erreurs de conception ni les erreurs de spécifications. Et je ne parle même pas du client qui a dit blanc tout en pensant noir alors qu'en réalité, il voulait violet...
    De toute facon, les specifications changent toujours et ne restent jamais figees. L'informaticien (le maitre d'oeuvre) a la responsabilite de bien savoir ce que le client lui a demande (maitrise d'ouvrage) pour ne pas se faire avoir. Et bien lui faire comprendre quand changement il y a. La gestion des exigences est aussi un metier a part...

  4. #44
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par _vince_ Voir le message
    Et bien lui faire comprendre quand changement il y a. La gestion des exigences est aussi un metier a part...


    NON.. Le rôle d'un utilsateur n'est PAS de savoir qu'il y a un changement dans le logiciel.

    On en revient à ce qu'on disait au-dessus : si une nouvelle demande génèrera côté logiciel un travail énorme, c'est qu'il y a une erreur de conception (ou d'analyse de départ) fondamentale.

    Là tu parles avec une "équipe interne" d'utilisateurs.

    Mais toi, par exemple en tant qu'utilisateur Windows, tu acceptes d'être convaincu par M$ qu'il faut que tu changes ta manière de faire ?????????
    "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

  5. #45
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    (.../...)On en revient à ce qu'on disait au-dessus : si une nouvelle demande génèrera côté logiciel un travail énorme, c'est qu'il y a une erreur de conception (ou d'analyse de départ) fondamentale.(.../...)
    ben non, on est pas d'accord sur le sujet. On ne peut pas tout demander à une application existante. Quand tu conçois une application, c'est dans un cadre donné. 20 ans plus tard, le cadre n'a rien à voir. Et les modifications deviennent hyper-couteuses. A tel point qu'une refonte devient nécéssaire.

    Surtout, ça nécéssite de surdimensionner certains points. On m'a répondu qu'il fallait faire du N-N partout. Mais c'est gourmand en ressources machines et en temps de développement. Quand tu as 80 tables, et qu'à chaque fois tu dois te farcir le N-N avec tout ce que ça implique, tu facilites peut-être les évolutions futures, mais tu ne finiras jamais ton projet. Utilité?????

    Je ne dis pas qu'il ne faille pas laisser de place aux évolutions ultérieures. Mais des choix doivent être faits, à un moment ou un autre. Aucune application ne peut TOUT faire. Toutes, cependant, peuvent être amenées à subir des modifications majeures qui obligeront à les repenser(ce qui est long et couteux).

    Ce que tu appelles erreur fondamentale, moi j'appelle ça évolution de la société. On ne sait pas ce que sera la loi, le marché, ou l'activité économique dans 10 ans. Si certaines évolutions sont prévisibles(genre l'an 2000), d'autres sont moins anticipables(le changement de référentiel monétaire de 2002, par exemple). Peux tu prétendre que si tu avais bossé avant 1997(date de vote du passage à l'Euro, si mes souvenirs sont exacts), tu aurais implémenté dans tout tes programmes un grigri permettant de changer de monnaie d'un claquement de doigts? Moi, je n'ai pas cette prétention. Et j'aurais mangé des modifs merdiques pendant 2 ans pour migrer tout ça. Cela fait de moi un concepteur minable?

    Et si tu sais faire l'application ultime auto-adaptatrice, je suis preneur de la méthode......
    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.

  6. #46
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Mais toi, par exemple en tant qu'utilisateur Windows, tu acceptes d'être convaincu par M$ qu'il faut que tu changes ta manière de faire ?????????
    Ca dépend si la nouvelle manière de faire est plus rentable.

  7. #47
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    ...
    Mais pourquoi etre susceptible comme ca ?? je ne parlais pas de toi, mais en general..

    Et d'autre part, je maintiens, comme je l'ai dit plus haut, que, meme si on ne ferais pas du N*N, on ferait du dynamique..

    n = GetLeftRelations("TOTO")

    m = GetRightRelations("TOTO");

    ou quelque chose du genre...

    En quoi est-ce impossible ????
    "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

  8. #48
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par davcha Voir le message
    Ca dépend si la nouvelle manière de faire est plus rentable.
    absolument, mais ca n'etait pas la maniere de dire
    "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

  9. #49
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Et ne pas oublier en vrac:
    • le plan de test
    • La tracabilité depuis les besoins utilisaters aux tests de validation en passant par les spécifications fonctionelles, les specifications détaillées
    • Les indicateurs de qualité
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  10. #50
    Membre régulier Avatar de TheCaribouX
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2008
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mars 2008
    Messages : 255
    Points : 122
    Points
    122
    Par défaut
    Citation Envoyé par Graffito Voir le message
    Et ne pas oublier en vrac:
    • le plan de test
    • La tracabilité depuis les besoins utilisaters aux tests de validation en passant par les spécifications fonctionelles, les specifications détaillées
    • Les indicateurs de qualité
    Aurais-tu des conseils à donner pour les deux premiers?

    et qu'est-ce que "les indicateurs de qualité" ?
    (désolé, je débute...)

  11. #51
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Je vais essayer de résumer, pour plus de détails, il faudra se référer aux diverses méthodologies de dévellopement.

    Pour la traçabilité, on donne une référence unique :
    1. à chaque élément des besoins utilisateur,
    2. à chaque élement des spécifications fonctionnelles,
    3. à chaque élement des spécifications détaillées.
    et on vérifie pour chaque document que chaque élement de l'étape précédente est couvert par un élément de l'étape en cours (=> matrice de tracabilité)

    Pour le plan de tests, on référence chaque test élémentaire, on indique la méthode de test et les résultats attendus (et évidemment on trace vers les spécifs détaillées).
    Pour les résultats de test, on identifie les sesssions de tests par une référence, l'environnement, la date.
    Face à chaque test élémentaire, on met la session, le résultat pour cette session et un éventuel commentaire.

    Pour les idicateurs qualité, voir wikipedia.Measurement_of_software_quality_factors
    Exemples pratiques de "mesures":
    - nombre de problèmes constatés par période,
    - temps d'indisponibilité,
    - délai de correction des erreurs.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  12. #52
    Membre régulier Avatar de TheCaribouX
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2008
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mars 2008
    Messages : 255
    Points : 122
    Points
    122
    Par défaut
    Merci!

  13. #53
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Je dois dire que je suis surpris de ce que je lis, dommage que j'arrive à la fin du débat.
    Déjà on parle de programmation défensive, et je ne suis que moyennement d'accord avec ce que je lis.

    1) Lorsqu'on parle de saisie utilisateur, je suis entièrement d'accord que ces données doivent être soigneusement validées avant d'être utilisées. Il est clair que s'il en a la possibilité, l'utilisateur sera capable de saisir un 30 février dans un champ date.

    2) Concernant les données internes au programme, celles qui ne sont pas saisies par l'utilisateur. Est-ce que cela a forcément toujours un sens de procéder à une validation des paramètres? Pour reprendre un exemple cité ci-dessus, vérifier qu'une collection passée est non-nulle avant de faire un foreach?

    Je dirai que cela dépend de la fonction, si celle-ci est exposée sur une façade telle qu'un webservice, une dll mise à disposition d'une autre équipe ou d'un tiers, alors oui c'est indispensable.
    En revanche, si cette fonction se situe dans un contexte maitrisé de l'application, suivant comment ça ne fait qu'ajouter des lignes de codes superflues qui nuisent à la lisibilité et que l'on aurait tendance à copier-coller de gauche à droite entre les overloads et les fonctions *qui ont à peu près la même gueule*.
    Soyons clairs, si la fonction est documentée correctement, c'est à dire que l'on précise que les paramètres ne sont pas nullables, le développeur qui appelle cette fonction et se prend un nullpointerException il saura à quoi s'en tenir.

    3) Si vous devez écrire une valeur dans le fichier de configuration de votre application, devez-vous forcément vérifier des situations telles que le manque d'espace disque ou l'absence de droits d'écriture avant d'appeler les méthodes File.Write ou autres ???
    Personnellement, je me contente de mettre tout cela dans une méthode de haut niveau qui catche un éventuel IOException pour le décorer d'une exception personnalisée "ConfigFileException" que je laisse remonter jusque dans le handler global de mon application, après quoi celle-ci se termine avec une joli message d'erreur "(....) Un problème est survenue avec le fichier de configuration", le message de l'exception vient ensuite.

    D'ailleurs c'est un cas tellement rare que l'on pourrait presque laisser l'IOException brute remonter.

  14. #54
    Membre actif
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    250
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 250
    Points : 259
    Points
    259
    Par défaut
    Comme dit plus haut, l'important est de relier les tests et les exigences entre eux pour etre sur que tu testes bien les fonctionnalites demandees dans les specs.

    @Frank:
    On n'utilise pas les meme vocabulaire. Voici ce que j'entends par programmation par contrat:
    http://en.wikipedia.org/wiki/Asserti...gn_by_contract

    @skip:
    Ce que j'essaie d'expliquer, c'est que le programmeur doit aussi se proteger de ses propres erreurs de logique. Par exemple en C++, un programmeur utilise un pointeur qui pointe sur rien alors qu'il pense que le pointeur pointe sur quelque chose de valide.

    @souviron34:
    Je veux dire que les developpeurs doivent faire attention a ce que le client ne fasse pas passer un bug alors que c'est un changement de specs.

  15. #55
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Ce que j'essaie d'expliquer, c'est que le programmeur doit aussi se proteger de ses propres erreurs de logique. Par exemple en C++, un programmeur utilise un pointeur qui pointe sur rien alors qu'il pense que le pointeur pointe sur quelque chose de valide.
    C'est bien vrai, cependant il faut faire très attention à ne pas utiliser de tests qui occultent des situations imprévues.
    -Une application qui plante à cause d'une situation imprévue, c'est gênant.
    -Une application qui continue de s'exécuter malgré une situation imprévue, c'est encore pire car c'est dangereux!
    Donc conclusion ce qui n'est pas prévu ne doit pas être géré, ou alors doit être reporté correctement, que ce soit sous forme d'une exception ou autre.

    On a différent moyen de se préparer aux erreurs de dévs. Le conseil que je donne et qui pour moi fait une bonne partie de la différence entre un pro et un bricoleur est le suivant : Utilisez toujours sauf exceptions du code fortement typé.
    Préférez toujours taper un
    String.getBytes( System.Encoding.Charset.UsAscii.getName() )
    plutot qu'un String.getBytes( "UsAscii").

    C'est un exemple assez gros, mais vous avez l'avantage que la première solution est vérifiée à la compilation, la deuxième n'est qu'une chaine littérale qui se plantera en runtime si par malheur elle est écrite fausse.
    Plus vous avez de code vérifié à la compilation, moins vous aurez de chance que le client trouve des bugs avant vous.

    Une deuxième chose qui rejoint la première, les tests unitaires. Très important pour tester la non-régression du code. Parfois onéreux en temps, mais sur le moyen terme on y gagne.
    On peut aussi faire du développement piloté par les tests, une excellente approche selon moi, hélas elle est pas toujours évidente à mettre en oeuvre lorsque l'on a une source de donnée derrière.

  16. #56
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par _skip Voir le message
    (.../...)
    On peut aussi faire du développement piloté par les tests, une excellente approche selon moi, hélas elle est pas toujours évidente à mettre en oeuvre lorsque l'on a une source de donnée derrière.
    Tu peux détailler ce point-là? Je ne vois pas ce que ça peut être.....
    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.

  17. #57
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    En cherchant Test-driven development on trouve un paquet de ressources là dessus, c'est un peu ce qui est parfois mis en avant dans le développement agile.
    En gros, l'idée générale c'est d'écrire des cas de test AVANT l'implémentation de la fonctionnalité.

  18. #58
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    ça me fout les jetons, ça. J'ai eu l'exemple VRAI d'un forfait ou les cas-tests étaient écrits à l'avance. Sur certaines fonctions, les types avaient codé en dur les réponses au cas test(par exemple, pour une somme de 1000, avec 4,5% d'interêt, le cas-test attendait 45. Alors le programme donnait toujours 45. Quel que soit le montant ou le taux d'interêt).

    Plus généralement, je me suis aperçu en faisant l'aller-retour entre les fonctions de développeur et de testeur, que(spécifiquement en transactionnel) des cas-tests complets(établi suivant les règles de l'art, et couvrant l'ensemble des besoins) étaient très insuffisants. Et que les utilisateurs avaient l'art de taper sur l'apli jusqu'à ce qu'elle casse. Et que les autres applications avaient aussi tendance à faire des choses plus évoluées que ce que l'on pense au départ(cas typique du client qui décède ou change de banque entre les 2 parties de l'application). En bref, même avec des équipes de bonne foi, se baser sur le résultat attendu me semble insuffisant pour prétendre avoir tester la robustesse de l'appli.....(N.B. - en Batch, ce genre de problèmatique est beaucoup moins forte, et si on ne se fait pas piéger par du codage en dur, la démarche ne me parait pas aberrante).
    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.

  19. #59
    Membre actif
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    250
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 250
    Points : 259
    Points
    259
    Par défaut
    Citation Envoyé par _skip Voir le message
    En cherchant Test-driven development on trouve un paquet de ressources là dessus, c'est un peu ce qui est parfois mis en avant dans le développement agile.
    En gros, l'idée générale c'est d'écrire des cas de test AVANT l'implémentation de la fonctionnalité.
    Je me demande combien de developpeurs pratiquent le TDD ? Et si oui, est-ce que c'est la meme personne qui teste et qui code ?

  20. #60
    Membre expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Points : 3 134
    Points
    3 134
    Par défaut
    Et si oui, est-ce que c'est la meme personne qui teste et qui code ?
    Surtout pas ! Il faut un regard exterieur, un point de vue différent. Sinon, on va tester "pour que cela marche" et c'est tout (à moins d'avoir une excellente rigueur/méthode).
    Hervé Delannoy, Ingénieur études&développement.

    Je n'accepte pas les demandes de mise en relation MSN/yahoo sans motif.
    ------------------------------------------------------------------------
    Si , ni , ne peuvent vous aider, mais nous oui, pensez à un pti et au !
    Merci de vous relire
    ____________________________________________________________________________________
    Recherche joueurs de "Magic" sur Lille et environs.
    Donner plutôt que jeter.

Discussions similaires

  1. [MySQL] utilitaire graphique qui fait la relation entre les table
    Par Amel_B dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 09/11/2008, 12h44
  2. API Windows différence entre fonctions simple EX et A
    Par Astraya dans le forum Windows
    Réponses: 3
    Dernier message: 11/02/2008, 10h39
  3. like ne fait pas différence entre les valeurs ?
    Par karimphp dans le forum Langage SQL
    Réponses: 3
    Dernier message: 26/06/2007, 18h27
  4. Quelle différence entre "réel simple" et "déc
    Par pyxosledisciple dans le forum Access
    Réponses: 2
    Dernier message: 11/01/2006, 12h51
  5. Réponses: 6
    Dernier message: 31/08/2005, 18h27

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