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

Sécurité Discussion :

Logiciel fiable, réalité ou utopie ?


Sujet :

Sécurité

  1. #41
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Ok, cela dit tu reconnaîtras que les buffer overflows sont des failles de sécurité bien plus fréquentes que ce genre d'erreur.
    Oui tout à fait.

    Mais bon, en même temps, si on bannit C et C++ parce qu'il y a un risque de buffer overflows, de problèmes de pointeurs ou autres soucis sur du bas niveau, alors il va aussi falloir bannir Java parce que la JVM est lourde, les langages interprétés parce qu'ils sont lents et qu'on ne peut pas détecter les problèmes à la compilation...

    Bon, sachant que même OCaml a ses limites, au final on fait quoi ? On abandonne tout et on se met au Haskell ?
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  2. #42
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Mais bon, en même temps, si on bannit C et C++ parce qu'il y a un risque de buffer overflows, de problèmes de pointeurs ou autres soucis sur du bas niveau, alors il va aussi falloir bannir Java parce que la JVM est lourde, les langages interprétés parce qu'ils sont lents et qu'on ne peut pas détecter les problèmes à la compilation...
    Je propose simplement de prendre le mieux adapté. Et je pense que le C/C++ sont adaptés à très peu de projets et certainement pas à un OS du fait des problèmes de sécurité et vérifiabilité. Pour ça il y a, comme je l'écrivais, Swift, Go, M# et compagnie : des langages de plus haut niveau que le C/C++ mais taillés pour les besoins aujourd'hui satisfaits par les C/C++.

  3. #43
    Membre confirmé
    Inscrit en
    Septembre 2004
    Messages
    314
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 314
    Points : 463
    Points
    463
    Par défaut
    Sauf que la qualité d'une solution ne se limite pas simplement au logiciel developpé, mais à tous les composants (maillons) de la solution.
    Si ton application est secure en terme de code réseaux, rien ne te protège des conventuelles failles des composants externes (Firewall, Routeurs, etc ...). Dans ce cas, et c'est souvent un vecteur utilisé par les pirates de haut vol, le developpeur ne peux se porter garant de la securité dans l'ensemble de la solution.

  4. #44
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par Nicam Voir le message
    Sauf que la qualité d'une solution ne se limite pas simplement au logiciel developpé, mais à tous les composants (maillons) de la solution.
    Si ton application est secure en terme de code réseaux, rien ne te protège des conventuelles failles des composants externes (Firewall, Routeurs, etc ...). Dans ce cas, et c'est souvent un vecteur utilisé par les pirates de haut vol, le developpeur ne peux se porter garant de la securité dans l'ensemble de la solution.
    Bien sûr et alors ? Ca veut dire qu'on se fout de tout ce qui pourrait améliorer le problème à *notre* niveau ? Le sujet est les failles de sécurité au niveau du logiciel, pas la sécurisation d'une installation complète. Il faut bien travailler un niveau après l'autre.
    "Non mais chef, on s'en fout des tests, de toute façon je suis sûr que la JVM et le CPU sont bogués et pourris de failles."

  5. #45
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Bien sûr et alors ? Ca veut dire qu'on se fout de tout ce qui pourrait améliorer le problème à *notre* niveau ?
    D'ailleurs, je dirais qu'en tant que développeur de la solution de ton niveau, si tu es capable de garantir preuve en main que ton logiciel fait son boulot et que la faille qu'on t'a montré est bien à la fois protégée par ton code et par ta spec, tu as juste à dire "de mon côté tout est OK, le problème n'est pas de mon fait, va voir dans les autres morceaux de ton système".

  6. #46
    Nouveau membre du Club
    Inscrit en
    Octobre 2003
    Messages
    11
    Détails du profil
    Informations forums :
    Inscription : Octobre 2003
    Messages : 11
    Points : 25
    Points
    25
    Par défaut
    Vous avez le budget pour des évolutions ou corrections de bug ?

    Moi je connais la réponse

  7. #47
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2012
    Messages
    371
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2012
    Messages : 371
    Points : 1 002
    Points
    1 002
    Par défaut
    Citation Envoyé par Nervix Voir le message
    Vous avez le budget pour des évolutions ou corrections de bug ?

    Moi je connais la réponse
    Moi aussi la réponse qu'on sort c'est : trop cher.


  8. #48
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par Nervix Voir le message
    Vous avez le budget pour des évolutions ou corrections de bug ?
    Pas besoin, c'est déjà compris dans le budget.

    Après tout, le boulot d'un développeur, c'est de fournir des logiciels sans bug. Donc pourquoi on doit payer pour qu'il enlève des bugs ?

    Et même si je change mes spécifications 18 fois d'affilée, en rajoutant des nouvelles demandes et contraintes à chaque fois, il faut que ça reste dans le budget initial (et que ça soit livré dans le temps imparti).
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  9. #49
    Membre confirmé
    Inscrit en
    Septembre 2004
    Messages
    314
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 314
    Points : 463
    Points
    463
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Bien sûr et alors ? Ca veut dire qu'on se fout de tout ce qui pourrait améliorer le problème à *notre* niveau ? Le sujet est les failles de sécurité au niveau du logiciel, pas la sécurisation d'une installation complète. Il faut bien travailler un niveau après l'autre.
    "Non mais chef, on s'en fout des tests, de toute façon je suis sûr que la JVM et le CPU sont bogués et pourris de failles."
    Le sujet porte sur le concept de logiciel fiable, réalité ou utopie. Au fil des messages, on a porté notre focus sur la sécurité, pour finalement se limiter au code de l'application.
    Ma remarque est juste pour rappeler qu'en terme de sécurité (puisqu'on en parle), il ne faut SURTOUT PAS se limiter à l'applicatif, mais prendre en compte l’environnement dans sa globalité (ou en tout cas, ce qui est possible).

    Ca dire quoi ? ca veut dire que lorsque tu vas budgétiser tes tests de qualité, si tu mises tout sur la qualité lié à ton logiciel, tu risques de cramer énormément d'argent à blinder ton soft, alors que tu négliges les autres points.
    Au niveau de ton logiciel, tu vas donc faire de la sur qualité (qui coûte très cher), mais ta solution globale ne sera pas sécurisé pour autant car c'est le maillon le plus faible qui compte.

    par exemple : tu as crée une application web, que tu vas déployer sur un serveur apache, sur un OS linux.
    Tu a super bien travaillé ton code, tu as testé toutes tes entrées, ton code est safe. Normal, tu as passé 15 jours /h pour sécuriser au mieux. Tu n'as surtout pas envie de dire à ton chef que tu t'en fous des tests.
    Tu as installé apache, tu as bien vérifié les droits, tu as patché le bordel comme il se doit, parce que pour toi, on ne plaisante pas avec la sécurité !
    Ton linux est mis à jour, tu as fermé tous les ports inutiles, et blah blah blah ....
    Sauf que ... le mot de passe root, c'est ... root (admettons).

    Au final, tu as dépensé de l'argent pour faire de la sécurisation d'application, peut être plus qu'il n'en faut, mais ton serveur ainsi configuré à une esperence de vie de quelques heures...

    Alors, c'est peut être rigolo dit comme ca, mais des moyens de faire tomber des serveurs, accéder à ce qu'on ne devrait pas, etc ..., il y en a un petit paquet.
    Tu peux t'user le paf à sur-securiser ton application, si le reste n'est pas au niveau ... tu fais de la sur-qualité logiciel.

    Pas la peine de t'exciter comme ca .... ;-)

  10. #50
    Membre averti Avatar de pascalCH
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    Juillet 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juillet 2006
    Messages : 187
    Points : 369
    Points
    369
    Par défaut Et si on prenait le problème à l'envers ?
    Pour résumer la flopée de réactions - plus pertinentes les une que les autres - on pourrait dire :

    • Le logiciel fiable n'existe pas.
    • Les budgets pour tester sont inexistants.
    • Les Chefs de projets ont d'autres chats à fouetter (les développeurs ?)
    • Les développeurs ont d'autres chats à fouetter (leurs compilateur ?).
    • Les clients sont des crétins incapables d'exprimer leurs besoins correctement.
    • Les outils sont déjà buggés à la base (certes c'est pas forcément faux).
    • Le développement en n-tiers devient inextricable (hélas ce n'est que trop vrai).
    • etc.


    Est-ce une raison pour baisser les bras ? Est-on condamné à ne plus jamais fournir un logiciel fonctionnant correctement et suffisamment solide pour résister aux attaques de base ( j'écarte les attaques ciblées qui nécessitent des moyens différents) ?

    Non !! ai-je envie de répondre et , comme je le dis dans le titre du message, tentons de prendre le problème à l'envers...

    Comme il apparait plutôt difficile de "dresser" les étages supérieurs (direction de projet - client - etc.) replions-nous sur nous même et mettons en œuvre des moyens, les plus simples possibles pour, à minima, mettre en évidence que les dysfonctionnements ne sont pas de notre responsabilités (note : si chacun se met dans cette situation, quelle que soit sa position et sa responsabilité, ça devrait finir par porter ses fruits - expérience(s) vécue(s)).

    Commençons par "en bas" : les développeurs :

    Dernier maillon de la chaine - parfois , hélas, seul maillon de la chaine - c'est sur lui que ça finira par retomber; donc, ami développeur et tête de Turc, source de tous les ennuis de la planète, de l'univers et au delà, que faire ?
    Et bien, utilisons un truc plutôt pratique et sécurisant : les tests unitaires ! Non ! ne partez pas tout de suite, je vais essayer de vous prouver que :
    • Ca ne prend pas plus de temps d'en faire que de ne pas en faire.
    • Ca va aider à faire le nécessaire et RIEN QUE le nécessaire.
    • Ca va permettre de prouver que ce que vous avez fait est ce que l'on vous a demandé en rien d'autre.
    • Les "merdes" ne sont pas de votre responsabilités.
    • Si les spécifications changent, vous êtes prêt a les prendre en compte.
    • Ca va sortir dans les temps.
    • Cerise sur la gâteau, ça sera testé.. sérieusement


    Allons au fait : les tests unitaires, c'est quoi ?

    Pour faire simple, un test unitaire est un bout de code, généralement exécuté dans un environnement particulier, qui va torturer un autre bout de code, bien souvent dans des conditions non conformes aux spécifications, qui a pour but de s'assurer de deux choses :
    • Dans les cas prévus, le bout de code fonctionne correctement.
    • Dans tous les autres cas, le bout de code ne s'exécute pas et réagi d'une façon ou d'une autre pour prévenir l'appelant que ça ne s'est pas passé comme prévu.


    Notez bien, le "Dans tous les autres cas", c'est ça qui est important, la méthode pour faire du "soviétique" est de dire : c'est prévu pour marcher comme ça et rien de plus, on ne se pose pas de question du genre : "et si...."; c'est pas prévu ? on refuse de traiter le problème, et on passe à la suite.

    Un exemple : Qu'est ce qu'un code postal français ?
    réponse : un champ alphanumérique de 5 caractères ne comportant que des chiffres. (accessoirement, on peut ajouter "existant dans la liste de référence de la poste disponible auprès des services pro de la poste").

    Donc, la validation (initiale) d'un champ code postal passera par la vérification qu'une donnée genre "44600" est acceptée puis :
    • "1234" est refusé car un caractère trop court
    • "123456" est refusé car un caractère trop long
    • "A2345", "1A345", "12A45" "123A5" "1234A" sont refusé car un caractères n'est pas numérique, cette multitude de tests pour la même raison est importante, elle va permettre de tester le code sans faire d'hypothèse sur la structure du code.


    Si on se projette dans un développement orienté objets, le fameux champ code postal sera sans doute une propriété d'une structure d'adresse et il existera une méthode setCodePostal(..) ou assimilée qui sera donc torturée par une série de 8 tests unitaires.

    Et oui, 8 test unitaires pour un si petit bout de code de rien du tout... et pourtant, à coup de copier/coller dans votre EDI préféré, il y en a pour moins de 5 minutes, et au moins, le setCodePostal sera bétonné, si un fourbe vient à pourrir le corps de la méthode, il sera découvert sur le champ !
    Bien sûr, le top serait que celui qui fait les spécifications soit capable de faire le jeu de tests, ça viendra petit à petit.

    Ce qu'il faut se rappeler, quand on écrit les tests, c'est que l'on est dans la peau de l'utilisateur de la fonction qu'on teste, si on éprouve des difficultés à écrire les tests, c'est que la méthode est mal définie, inappropriées, hors sujet ou, plus souvent, l’œuvre d'une personne qui à imaginé un problème ou une fonctionnalité qui n'existe pas; Une fonction difficile à tester est une fonction qui va générer des problèmes a court ou moyens termes.

    Je vais arrêter là pour le moment, entrainez vous à écrire des tests, quand vous serez à 20% de couverture, vous serez déjà au Nirvana... arrivé à 100% ce sera RTT à temps plein !!
    La nature fait des choses extraordinaires, observons la et restons humble, on ne nous demande pas de refaire le monde mais juste de reproduire virtuellement des choses existantes ....

    et n'oubliez pas si vous aimez et quand vous avez la réponse

  11. #51
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Ouaip, c'est toujours ça les tests unitaires, mais concrètement ça teste que le composant fait bien ce qu'on voulait qu'il fasse. Pas qu'il fait ce qu'il devrait faire.
    On peut tester toutes les entrées et ainsi vérifier que toutes les sorties nous plaisent. Mais pas que ce soient les bonnes. C'est ça le problème que je rencontre le plus souvent, moi*.

    (* Sorti du collègue qui a changé un code sans me le dire, et du fait que j'ai pas le droit de mettre mes tests sur le repo central que tout le monde peut réutiliser parce que "y en a trop et on veut pas maintenir tout ce code")
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  12. #52
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par pascalCH Voir le message
    Un exemple : Qu'est ce qu'un code postal français ?
    Et c'est là que ton commercial arrive en disant "bon, on a fait un super logiciel pour la France, maintenant on va l'adapter pour le vendre à l'international"

    Donc :
    - les codes postaux n'ont pas forcément 5 caractères
    - certains codes postaux ont des caractères alphanumériques (ex: "PO4 0PL")
    - certains pays n'ont même pas de codes postaux (ex: l'Irlande pour le moment)

    Maintenant que les tests précédents sont devenus caduques, il va falloir trouver une autre solution pour vérifier la saisie utilisateur. Ça ne va pas être facile (ex. trouver un service en ligne qui donne la ville en fonction du code postal, et qui marche pour différents pays)

    Bref, quand on veut prendre un exemple de tests unitaires, il vaut mieux se baser sur quelque chose d'un peu plus immuable comme les lois de la nature (plutôt que des lois définies par l'homme, qui changent tout le temps).
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  13. #53
    Membre averti Avatar de pascalCH
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    Juillet 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juillet 2006
    Messages : 187
    Points : 369
    Points
    369
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Et c'est là que ton commercial arrive en disant "bon, on a fait un super logiciel pour la France, maintenant on va l'adapter pour le vendre à l'international"

    Donc :
    - les codes postaux n'ont pas forcément 5 caractères
    - certains codes postaux ont des caractères alphanumériques (ex: "PO4 0PL")
    - certains pays n'ont même pas de codes postaux (ex: l'Irlande pour le moment)

    Maintenant que les tests précédents sont devenus caduques, il va falloir trouver une autre solution pour vérifier la saisie utilisateur. Ça ne va pas être facile (ex. trouver un service en ligne qui donne la ville en fonction du code postal, et qui marche pour différents pays)

    Bref, quand on veut prendre un exemple de tests unitaires, il vaut mieux se baser sur quelque chose d'un peu plus immuable comme les lois de la nature (plutôt que des lois définies par l'homme, qui changent tout le temps).
    Justement (j’espérai un post dans ce genre) !

    en quoi, passer le logiciel à l’international remettrait en cause les tests existants ?

    Dans ce cas - histoire vécue - il ne s'agit que d'une simple modification des exigences donc, ajout de tests complémentaires adaptés à la nouvelle demande - ce qui va nécessiter un boulot assez considérable pour celui qui va se farcir les jeux de tests; ré ingénierie de la solution et modification (dans ce cas, plutôt ré écriture) du code avec, au moins comme garde fou, les tests unitaires du début qui permettent de s'assurer que la version initiale continue à fonctionner.

    Concernant l'histoire vécue, le "commercial de l'étape" a failli manger son chapeau - pardon, sa casquette - quand je lui ai présenté l'addition !
    La nature fait des choses extraordinaires, observons la et restons humble, on ne nous demande pas de refaire le monde mais juste de reproduire virtuellement des choses existantes ....

    et n'oubliez pas si vous aimez et quand vous avez la réponse

  14. #54
    Membre averti Avatar de pascalCH
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    Juillet 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juillet 2006
    Messages : 187
    Points : 369
    Points
    369
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Ouaip, c'est toujours ça les tests unitaires, mais concrètement ça teste que le composant fait bien ce qu'on voulait qu'il fasse. Pas qu'il fait ce qu'il devrait faire.
    On peut tester toutes les entrées et ainsi vérifier que toutes les sorties nous plaisent. Mais pas que ce soient les bonnes. C'est ça le problème que je rencontre le plus souvent, moi*.
    Je m'inquiète un peu de la formule que j'ai surlignée en rouge dans ton post.
    Un test digne de ce nom spécifie les entrées, mais également, le résultat attendu et ce, en détail;
    une campagne de tests définie un jeu de données de tests et pour chaque cas, le résultat attendu.
    Il semble évident que si on ne dispose pas précisément du résultat attendu, c'est bien difficile de coder quelque chose de cohérent.
    Je pense que tu es dans une situation - ô combien trop fréquente - où le prescripteur est incapable d'exprimer correctement et précisément ce qu'il attend du logiciel-composant-fonction...
    A part sortir la batte de base-ball, les casques lourds et les barbelés monter au front, pas grand chose comme solution, en tout cas ce n'est plus de la responsabilité du développeur mais des étages au dessus.

    Un client, ça s'éduque !
    La nature fait des choses extraordinaires, observons la et restons humble, on ne nous demande pas de refaire le monde mais juste de reproduire virtuellement des choses existantes ....

    et n'oubliez pas si vous aimez et quand vous avez la réponse

  15. #55
    Membre averti Avatar de pascalCH
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    Juillet 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 66
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juillet 2006
    Messages : 187
    Points : 369
    Points
    369
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Bien sûr et alors ? Ca veut dire qu'on se fout de tout ce qui pourrait améliorer le problème à *notre* niveau ? Le sujet est les failles de sécurité au niveau du logiciel, pas la sécurisation d'une installation complète. Il faut bien travailler un niveau après l'autre."
    Rhoooooo !!!

    Maladie du siècle, tant qu'on va garder la terminologie "développer un logiciel", on ne s'en sortira pas; tant que l'amalgame entre "développer" et "développeur" sera fait on perdra de vue que l'industrie du logiciel est une industrie et pas un passe temps pour jeunes boutonneux farfelus ou vieux soixante-huitard sur le retour !

    Pour réaliser un logiciel, il faut une équipe pluridisciplinaire, des gens qui pensent, des qui imagine, des qui font, des qui vérifient, des qui cherchent; et ce pour tous les aspects : environnement - technologies - déploiement - évolutivité - marché - etc.

    Et cette équipe, elle rame, mais tout le monde rame dans le même sens et concernant les aspects sécurité-solidité-fiabilité cela doit être traité de la même façon que l'assurance qualité dans l'entreprise, de façon transversale; cela veux dire que c'est l'affaire de tous !
    La nature fait des choses extraordinaires, observons la et restons humble, on ne nous demande pas de refaire le monde mais juste de reproduire virtuellement des choses existantes ....

    et n'oubliez pas si vous aimez et quand vous avez la réponse

  16. #56
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    Citation Envoyé par pascalCH Voir le message
    Je m'inquiète un peu de la formule que j'ai surlignée en rouge dans ton post.
    Pourtant, j'ai pas mal bourlingué et regardé à quoi ressemble l'informatique fournie comme un service dans ce système mondialisé qui est le nôtre.
    Et il me semble que cette formule résume plutôt bien l'état de l'art pour ce qu'il est.

    On me dit dans l'oreillette que certains domaines qui utilisent des fournisseurs informatiques, exigent un processus qualité mieux cerné. Armée, NASA, médical, les systèmes internes des banques. Ok, chouette, mais c'est pas là-dedans que je bosse.

    Citation Envoyé par pascalCH Voir le message
    Il semble évident que si on ne dispose pas précisément du résultat attendu, c'est bien difficile de coder quelque chose de cohérent.
    N'est-ce pas ? Pourtant, c'est là plus de 7 problèmes sur 10 parmi ceux que je dois gérer. Plus 2 problèmes sur 10 où un collègue a fait une connerie. Quand je sais quel est le résultat attendu, il y a bien longtemps que mes erreurs se font rares (et d'ailleurs il y a aussi les cas où ce n'est pas une question d'erreur de résultat mais de consommation inappropriée de ressources. Souvent la consommation de ressources ne peut pas être monitorée par tests unitaires, ou au prix d'une complexification dont la légitimité se discute.)

    Citation Envoyé par pascalCH Voir le message
    Je pense que tu es dans une situation - ô combien trop fréquente - où le prescripteur est incapable d'exprimer correctement et précisément ce qu'il attend du logiciel-composant-fonction...
    A part sortir la batte de base-ball, les casques lourds et les barbelés monter au front, pas grand chose comme solution, en tout cas ce n'est plus de la responsabilité du développeur mais des étages au dessus.

    Un client, ça s'éduque !
    Bien sûr ! Mon client me paie pour que je lui tape sur les doigts et lui donne des leçons, pas pour que je lui fournisse une livraison qu'il pourra utiliser dans les cas décrits.

    Mes clients sont conscients du fait qu'ils n'ont pas forcément tenu compte du fait que je sais pas lire leurs pensées, que ça va faire des erreurs, et que le contrat de maintenance est là pour ça (et pas gratuit pour ça.) Ils font leurs propres tests puisque leur infrastructure, ce n'est pas vraiment possible de la répliquer, et de toute façon ils ont pas voulu qu'on essaie. Ça permet de déceler là où leurs demandes étaient mal fichues et de réparer comme il faut. Puis, quand on est parti en prod et qu'il y a des ratés, ils perdent un peu d'argent, on détermine si oui ou non on a tenu nos engagements et c'est le cas, alors ils perdent aussi un peu d'argent pour qu'on fasse un correctif. Et le raté disparaît et on attend le suivant. Et l'informatique n'est pas vraiment vraiment fiable, mais elle l'est la plupart du temps et elle rend bien service. Normal dans ces conditions que certains s'en satisfassent.

    Hélas, en réalité tout n'est pas qu'histoire de clients. Sauf à considérer mes commerciaux comme des clients. Attention à pas trop dire que c'est de leur faute et tout : oui ce qu'ils produisent pourrait être de bien meilleure qualité, mais ça aurait un prix. Et on n'arrive pas à le payer. C'est vraiment beaucoup de boulot, parce que l'état de l'art actuel, c'est que personne sait faire des specs. Fournisseurs, clients, partenaires, services, thirdparties, ce sont tous des nuls en specs. À cause de ça, ceux qui veulent faire une vraie spec manquent de manière de vérifier la qualité de leur travail. Et faire des tests unitaires ne nous dit pas trop, ni si on a vraiment couvert toutes les entrées, ni si le résultat est bon.
    Je pense surtout aux intégrations avec les réseaux sociaux. Mis à part, à mon humble avis, Google, les specs sont risibles et la nature du service empêche de couvrir plus du tiers du fonctionnel avec des tests unitaires. Il serait possible d'avoir mieux. Si les réseaux sociaux proposaient mieux.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  17. #57
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par pascalCH Voir le message
    Ca ne prend pas plus de temps d'en faire que de ne pas en faire.
    Non, ça c'est faux. On peut dire plein de choses des tests mais ça prend du temps et ça coûte de l'argent, même si cela peut être rentable dans certaines conditions (logiciels amenés à connaître des changements perpétuels, coût important des erreurs, etc). Ne serait-ce que parce que pour faire du "vrai" test unitaire (voir ci-dessous) il faut deux lignes de test par ligne de code.

    Pour faire simple, un test unitaire est un bout de code, généralement exécuté dans un environnement particulier, qui va torturer un autre bout de code, bien souvent dans des conditions non conformes aux spécifications, qui a pour but de s'assurer de deux choses :
    • Dans les cas prévus, le bout de code fonctionne correctement.
    • Dans tous les autres cas, le bout de code ne s'exécute pas et réagi d'une façon ou d'une autre pour prévenir l'appelant que ça ne s'est pas passé comme prévu.
    Non, ça c'est seulement la définition d'un test. Un test unitaire a autant de définitions que de personnes et de contextes. Historiquement, pour Kent Beck, l'unité était la moindre fonction, publique ou privée. Pour d'autres c'est uniquement la surface publique (excluant aussi tout ce qui est interne à une DLL). De nos jours l'unité est souvent la fonctionnalité métier (ce qui semble être ton cas).

    A mon sens la bonne unité est la fonction. Dans ce cas les tests unitaires ne peuvent pas suffire car certains problèmes n'apparaissent que lors du couplage de tous ces éléments. Il faut alors leur adjoindre des tests fonctionnels et des tests d'intégration. Qui plus est ce genre de tests s'accorde mal avec le typage statique (voir ci-dessous).

    Un exemple : Qu'est ce qu'un code postal français ?
    C'est très bien ces petits exemples mais maintenant retour à la réalité : bien trop souvent ton boulot est de faire un test qui prendra en entrée un graphe d'objets complexe et devra tester en sortie un autre graphe complexe, tout en faisant intervenir un agent asynchrone, des opérations réseau ou des options globales de configuration. Et cela ne sera jamais simple, parce qu'un problème complexe a des réponses complexes et parce que la multiplication des facteurs crée une explosion combinatoire du nombre de tests à réaliser (d'où l'intérêt d'utiliser la fonction comme unité plutôt que la fonctionnalité).

    Déjà que, non, tes tests pour le code postal ne te prennent pas cinq minutes mais plutôt vingt (le temps de naviguer parmi les 500 fichiers, de réfléchir à tous les cas que tu dois tester, de trouver des noms et commentaires appropriés, de les implémenter, de refaire tourner tes 10k tests, de trouver le bogue que tu as introduit dans ton test, etc), dans la réalité tes tests sont bien trop souvent des monstres excessivement laids nécessitant de nombreux mock-ups et ayant requis, entre autres pollutions du code, de multiplier l'usage d'interfaces plutôt que de types concrets, interfaces dont le seul intérêt est rendre le code testable et qui nuisent à la navigation dans le code (et ne me parle pas de maintenabilité : falacieux et yagni), ou d'ajouter des constructeurs spécifiques aux tests, des constantes de compilation, des options, etc.

    Est-ce que je m'avance si je dis que dans ton cas tu fais beaucoup de CRUD+RAD (les DB sont aisément testables) ou de projets de petite envergure et que cela biaise beaucoup ta vision des choses ? Ou que tu ne mets plus les mains dans le cambouis ?


    Ne t'y trompe pas : je ne prône pas l'abandon des tests. Pas du tout. En revanche je bondis quand quelqu'un explique, surtout avec autant d’aplomb que toi, que c'est gratuit et fastoche, que c'est la réponse universelle et miraculeuse, et que si on se bat avec la complexité c'est parce qu'on est trop nazes. En réalité les tests sont parfois bien plus complexes et chronophages que le code lui-même, rendre un code testable est une contrainte de plus sur le code qui cause une augmentation non-linéaire de la complexité du développement, et ces tests ne sont pas une garantie d'absence de bogues même à 100% de couverture de code (ce qui est d'ailleurs un objectif absurde).

    Citation Envoyé par pascalCH Voir le message
    Dans ce cas - histoire vécue - il ne s'agit que d'une simple modification des exigences donc, ajout de tests complémentaires adaptés à la nouvelle demande - ce qui va nécessiter un boulot assez considérable pour celui qui va se farcir les jeux de tests; ré ingénierie de la solution et modification (dans ce cas, plutôt ré écriture) du code avec, au moins comme garde fou, les tests unitaires du début qui permettent de s'assurer que la version initiale continue à fonctionner.
    Mais tu as également eu à modifier les tests initiaux pour définir le pays à prendre en compte. Certes, ce n'est pas grande chose dans une approche white box. Mais cette approche est insuffisante. Dans une approche gray/black box dès lors que tu changes l'implémentation tu dois revoir ton choix de tests, par définition.

    Le point qui était soulevé était que tout changement du comportement désiré nécessite de modifier les tests en plus de modifier le code. C'est incontestable.

    Citation Envoyé par pascalCH Voir le message
    Il semble évident que si on ne dispose pas précisément du résultat attendu, c'est bien difficile de coder quelque chose de cohérent. Je pense que tu es dans une situation - ô combien trop fréquente - où le prescripteur est incapable d'exprimer correctement et précisément ce qu'il attend du logiciel-composant-fonction...
    Attention, tout le monde ne travaille pas dans une SSII ou une agence. Et pour beaucoup d'entre nous c'est à nous qu'incombe de définir précisément certains comportements attendus du logiciel, pour de bonnes raisons. Et parfois cela nécessite une expérimentation, donc des prototypes dont l'un deviendra le code final.

    D'ailleurs je crois que toute spécification est forcément incomplète. Une spécification complète s'appelle un programme, c'est à dire un document qui spécifie étape par étape chaque opération à effectuer.

    Enfin il me semble que si le client peut comprendre inéluctabilité des bogues et la nécessité parfois de revenir sur un travail déjà accompli, nous pouvons, nous, comprendre l'inéluctabilité des bogues dans les spécifications, la nécessité parfois dde reveir tardivement sur certaines spécifications, et ne pas prétendre éduquer qui que ce soit. Non ?

    Citation Envoyé par pascalCH Voir le message
    Et cette équipe, elle rame, mais tout le monde rame dans le même sens et concernant les aspects sécurité-solidité-fiabilité cela doit être traité de la même façon que l'assurance qualité dans l'entreprise, de façon transversale; cela veux dire que c'est l'affaire de tous !
    Le contexte initial de la discussion était que de toute façon même si ton logiciel était fiable il y aurait un bogue dans le routeur ou le CPU. Et bien non les drivers de cisco ne sont pas de ma responsabilité et personne n'attend que j'aille les vérifier. Inutile de nous sortir un refrain convenu sur la transversalité et l'amour universel.

  18. #58
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 2 529
    Points : 4 739
    Points
    4 739
    Par défaut
    Fiabilité ?

    Préalables :
    1- Les spécifications des clients sont fiables et claires. Elles sont déjà prévues pour s’inscrire dans un processus d’évolution cohérent de leur besoins, au fil de l’évolution et d’accompagnement sur le futur, pour le « produit ».
    2- Il y a un budget temps pour le dossier d’analyse, il représente le double de celui du développement, il est rédigé par la personne qui encadrera l’équipe de dev, lesquels sont associés et « sensibilisé » régulièrement lors de réunions informatives lors de sa rédaction.
    3- La rédaction technique du code est réalisée en parallèle avec le développement.
    4- Le code développé regorge de commentaires, écrits dans une langue accessible.
    5- ….

    Je préfère en rester la, ce type de rêve me fait du mal…
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  19. #59
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    222
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 222
    Points : 766
    Points
    766
    Par défaut
    J'ai rapidement parcouru les réactions des uns et des autres et à mon avis le problème vient de l’utilisation du mot fiable dans le titre de l'article que ce n'est pas vraiment de ça dont-il parle. Ou en tout cas le mot fiable (reliable en anglais) est peut-être trop flou.

    Le software reliability est une banche à part entière de l'informatique, qui s'intéresse plutôt à l'absence de pannes, d'erreurs, de bugs etc... Bref, tout ce qui est adressé par des techniques différentes de tests, méthodes formelles, etc. suivant le budget et les impératifs (pou un jeu ou le pilote automatique d'un avion on y mettra pas le même prix). On s'intéresse à comparer, une spec ou un cahier des charges avec la réalisation qui en est faite.

    L'article nous parle ici de problème de sécurités, de failles, de contournements... ce qui n'est pas la même chose. On peut trouver des failles dans du logiciel qui ne contient aucun bug. Dans le domaine de la fiabilité on peut rechercher à améliorer les specs, les process de développement et les techniques de vérification. Mais en ce qui concerne la sécurité, comme dit dans une des premières réponses:
    Citation Envoyé par tontonnux Voir le message
    Le problème c'est que beaucoup de "failles" viennent de comportements (au sens large) qui n'avaient pas été envisagés.

    Du coup, la question devient: "Peut-on envisager ce qu'on n'a pas envisagé ?".
    Réponse: "Bah... non."

    On peut envisager qu'il y aura des problèmes et mettre en place des process forts de détection et de gestion de ces problèmes.
    Vouloir éviter les problème n'a donc aucun sens. En revanche, on peut toujours essayer de mieux les gérer.
    Il y a certainement de bonnes règles à respecter (que personnes ne respecte en pratique) genre vérifier systématiquement les pointeurs nul ou que les entrées correspondent à 100% au sous-ensemble attendu. Un des problèmes en informatique c'est que les fonctions spécifiées ne sont jamais "totales" alors qu'elles le sont en pratique: Question: "Quest-ce qu'on fait si la valeur de ce int en entrée ne fait pas partie de l'enum attendu? ou si le flux xml n'est pas 100% conforme au modèle pris en charge?", réponse: "t'inquiète, ça n'arrivera jamais!"

    Mais, à part sur certains logiciels sécuritaires qui bénéficieront du temps et des budgets nécessaires (et encore), la pression est beaucoup mise sur la date de livraison ou la rapidité d'exécution que sur la sécurité. En plus, on se dit souvent: "je fais ça comme ça pour le moment et j'y reviendrai pour faire propre" et on y'a plus prioritaire qui arrive avant qu'on ne puisse y revenir.

  20. #60
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par pascalCH Voir le message
    Justement (j’espérai un post dans ce genre) !

    en quoi, passer le logiciel à l’international remettrait en cause les tests existants ?
    Voir le message de DonQuiche.

    Je suis entièrement d'accord avec lui.


    Citation Envoyé par pascalCH Voir le message
    Concernant l'histoire vécue, le "commercial de l'étape" a failli manger son chapeau - pardon, sa casquette - quand je lui ai présenté l'addition !
    Histoire vécue, le "commercial de l'étape" (ou plus exactement "les actionnaires du groupe" ) ont décrété que les développements coûtaient trop cher et ont transféré l'ensemble de l'activité IT au Maroc. De ce que j'ai pu comprendre, niveau qualité c'est pas ça et au niveau du personnel, c'est pas facile à gérer (dès qu'ils en ont l'opportunité, ils vont voir ailleurs...)

    Oui, la qualité ça a un coût, et tout le monde n'est pas prêt à payer.

    C'est comme dans toutes les industries (pas juste en informatique), il faut savoir : Quelle est la qualité recherchée ? Combien vous êtes prêts à payer pour cela ? De combien de temps on dispose ?

    Si on te répond : "on veut 0 défaut, sans que ça nous coûte un centime de plus, et pour demain", il faut leur dire d'aller voir ailleurs (et par "ailleurs" je veux dire "au pays des Bisounours...").
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

Discussions similaires

  1. Réponses: 89
    Dernier message: 01/01/2017, 21h08
  2. Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?
    Par mattj dans le forum Débats sur le développement - Le Best Of
    Réponses: 88
    Dernier message: 04/09/2012, 01h40
  3. Conception : réalité ou utopie
    Par grunk dans le forum ALM
    Réponses: 3
    Dernier message: 24/03/2011, 22h13
  4. [Fondements] Preuve de programme: utopie ou réalité ?
    Par DrTopos dans le forum Débats sur le développement - Le Best Of
    Réponses: 115
    Dernier message: 05/10/2007, 17h12
  5. Réponses: 13
    Dernier message: 09/08/2006, 23h25

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