Discussion :

[millie]

Note : si on reprend le cas du logiciel de traitement d'images, et si l'on prend la fonctionalité "lire une image", qu'est-ce que cela change au reste que d'un seul coup on veuille lire des png, des bmp, des tiff, ou un nouveau format qui vient de sortir, alors qu'on ne lisait que des jpeg et des gif ?? Dans tous les cas de figure, peu importe le format, on sait qu'en entrée la "fonctionalité" aura un nom (éventuellement complet avec l'ensemble du chemin), et en sortie un buffer (en général unsigned char)et les dimensions..

Je tiens juste à noter que ces formats doivent pourtant être traitées un peu différemment.

- Un TIFF peut être multi-page (et pas un jpg, ni un bmp).
Si un jour on se décide à lire du tiff, c'est qu'il faut également se décider à faire du multi-page, et ca peut être source d'ennui quand tout le programme n'est absolument pas prévu pour ça.

- Il peut y avoir des méta données dans les jpg (Ouverture, focale, ISO, etc.) qui sont non présentes en BMP.
Idem que les niveaux de compressions diffèrent entre chaque format.

- Un fichier RAW en tant que tel doit également être pretraité avant d'être ouvert.

- Certains fichiers d'images dont le nombre de bits par canaux ne correspondent pas au moniteur (souvent 8 bits) doivent être pretraité (tone-mappé) pour pouvoir les afficher. (surtout si on se limite à un tableau d'unsigned char en sortie)


Pour moi, l'ouverture d'image est typiquement un exemple de fonctionnalité simple, qui pourtant devient un peu casse gueule quand on fait intervenir toutes les possibilités des formats. Je n'ai cité que 4 exemples, mais il y en a beaucoup plus.

[souviron34]

Je tiens juste à noter que ces formats doivent pourtant être traitées un peu différemment.

- Un TIFF peut être multi-page (et pas un jpg, ni un bmp).
Si un jour on se décide à lire du tiff, c'est qu'il faut également se décider à faire du multi-page, et ca peut être source d'ennui quand tout le programme n'est absolument pas prévu pour ça.

- Il peut y avoir des méta données dans les jpg (Ouverture, focale, ISO, etc.) qui sont non présentes en BMP.
Idem que les niveaux de compressions diffèrent entre chaque format.

- Un fichier RAW en tant que tel doit également être pretraité avant d'être ouvert.

- Certains fichiers d'images dont le nombre de bits par canaux ne correspondent pas au moniteur (souvent 8 bits) doivent être pretraité (tone-mappé) pour pouvoir les afficher. (surtout si on se limite à un tableau d'unsigned char en sortie)


Pour moi, l'ouverture d'image est typiquement un exemple de fonctionnalité simple, qui pourtant devient un peu casse gueule quand on fait intervenir toutes les possibilités des formats. Je n'ai cité que 4 exemples, mais il y en a beaucoup plus.

c'est exact, mais j'ai été au plus court..

Pour faire une API exhaustuve, il faudrait prévoir 3 buffers de sortie (pour les images 24 bits), une évenutelle table de couleurs et son nombre d eniveaux assoicié, ainsi que 2 flags entrelacé et transparent..

Ce que tu dis à propos de TIFF est relativement hors de propos (mille excuses) , car ton logiciel (comme par exemple si tu décidais de refaire Photoshop) a dans sa spec la définition de ce que doit être une image (à) trait(er)ée..

Mais même pour les méta-données, c'est juste une propriété générale qui peut être ou ne pas être là.. et qui devrait être envisagé de façon générale..



C'est la même chose avec un logiciel d'affichage de film..



Par rapport à la structuration à grande échelle du logiciel, une analyse correcte au départ donnera l'ensemble des paramètres possibles / souhaitables / souhaités..

Qu'un format contienne plus, on peut le lire et non l'exploiter..


Dans un lecteur de DVD, lire du MPEG2 ou du DivX ou du AVI ne change pas (heureusement) les fonctionalités de ta télécommande, qui traite tous les formats de la même manière... Certaines sous-fonctionalités peuvent être inaccessibles (angle de vue par exemple), mais la lecture/pause/arrêt/rewind, FF, etc, sont les mêmes, non ?


Je suppose que la partie "lecture du format" a en sortie un ensemble de booléens spécifiant quelles sont les fonctionalités accessibles ou non..


Globalement il est vrai que les formats d'images sont complexes, mais il n'empêche que par rapport au sujet, (et vu la popularité de ce genre de choses, c'est le pourquoi du choix de cet exemple), cela me semblit un bon exemple du découplage dans l'analyse entre les algos et la fonctionalité en tant que telle.. (et donc l'architecture)..

[millie]

c'est exact, mais j'ai été au plus court..

Comme quoi ce n'est pas aussi simple
Et on peut vite tomber dans de tel piège dans des domaines qu'on ne maitrise pas à fond.

[souviron34]

Comme quoi ce n'est pas aussi simple
Et on peut vite tomber dans de tel piège dans des domaines qu'on ne maitrise pas à fond.

en fait, j'avais rédigé tout un paragraphe avec justement les 3 buffers et tout et tout, mais je me suis dit que ce serait trop complexe par rapport au sujet et au propos... Du coup je l'avais enlevé

[apieum]

Par rapport à la structuration à grande échelle du logiciel, une analyse correcte au départ donnera l'ensemble des paramètres possibles / souhaitables / souhaités..

Je suis désolé, je n'y crois pas trop.
Ton approche me fait penser au RUP.

J'ai certainement pas ton niveau en conception, mais j'ai été confronté à des cas où mon programme avec le temps est devenu tout autre chose que ce que je pouvais imaginer au départ. (template engine -> compilateur, filtre d'abstraction BD -> SGBD NoSQL)

Dans ce cas là, je crois que c'est essentiel d'avoir écrit des tests au fur et à mesure pour ne pas "casser" des fonctionnalités déjà opérationnelles. (je le pense mais je ne le fais pas toujours )

Dans tous les cas il me semble que pour éviter des développements interminables, il faut régulièrement :
- revoir la validité des objectifs du projet (donner un horizon, un cap, ou le rappeler)
- vérifier que ce qui a été codé fonctionne toujours
- passer par des phases d'analyse et de conception

Enfin intégrer et accepter le fait que l'on ne puisse pas tout savoir, pour en tenir compte dans ses développement et aller chercher au fur et à mesure, de plus en plus en détail, les informations, les savoirs qu'il nous manque en commençant par une vue globale la plus large possible et en se concentrant sur les priorités.

Ça ne garantie pas le succès d'un projet mais cela peut y contribuer.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Quelques citations:
( tout droit sorties d'un bouquin ; faut pas exagérer, je vais pas commencé à avoir de la culture, non plus )

La prévision est toujours très difficile surtout lorsqu'elle concerne le futur ( Niels Bohr )

On ne connaîtra les bonnes prévisions qu'au vu des résultats ( John Lowey )

Le changement lui-même est en train de changer. ( Georges Salomon )

On peut changer et rester absurde. ( Jules Renard )

[souviron34]

si tu le dis...

[el_slapper]

...à la fois d'accord avec apieum et Souviron, en fait. Avec souviron parceque partir à l'aveugle est le meilleur moyen de se planter, et avec apieum parcequ'une fois que ça marche, l'imagination des demandeurs d'évolutions est sans limite.....

[professeur shadoko]

Je n'ai jamais vu un utilisateur (ou un client) savoir ce qu'il veut :
- L'utilisateur a un besoin dont il ne comprend qu'une petite partie.
- Il s'imagine inconsciemment une solution et te décrit sa solution comme étant son besoin.
etc....

je suis bien d'accord: les besoins de l'utilisateur doivent être une source d'inspiration! (les confrontations avec l'utilisateur une source de tests).
Sur ce point je ne suis pas d'accord avec certaines interprétations des principes "agiles" qui recommandent de ne se limiter qu'à ce qui est demandé: abstraire et architecturer permet aussi d'anticiper.
De même que la poésie est utile dans la "vraie vie", le beau code est payant (maintenant on risque de s'empailler sur la notion de "beau" ).
L'attitude "nous Monsieur, nous sommes concrets nous collons à vos besoins et nous ne nous embarassons pas de considérations d'intellectuels coupés de la réalité" (citation authentique!) me fait toujours tapoter le menton .....

[FR119492]

Bonjour à tous.
Selon mon expérience personnelle, il y a deux étapes dans la vie d'un développeur:

• Avant la retraite: Comme le client ne sait jamais ce qu'il veut, tu programmes ce que tu veux, mais tu le programmes bien; quand c'est terminé, tu fais preuve de psychologie et tu persuades le client que c'est ce qu'il voulait, voire un peu mieux.
• Après la retraite: Tu fais ce qui te plait; tu programmes ce qui te plait, comme ça te plait; de toute manière, le temps ne compte plus. Et si tu n'aimes pas programmer, tu te dis que, dès le début, tu aurais dû choisir un autre métier.

Jean-Marc Blanc

PS: Comme retraité, tu peux aussi dépanner sur www.developpez.com!

[jota5450]

bjour..

je sais que le topic est mort... mais ...

tu n'as pas fait une bonne analyse ni une bonne conception..

pas tous a fais d´accord...

Ca depand des cas.


Une analyse ou conception peut etre impossible de faire. Et j´explique.

Dans mon equipe de dev, on viens de rendre um soft qui a mis 18 mois a developpez.
Au debut, on avais que quelques idées de ce qu´on devais faire. Le client lui même(plusieurs equipes) ne savais pas encore comment le soft devais se comporter devant quelques situations. Pendant ces 18 mois, on a eu 4 reunions avec le client pour montrer "le produit". Et je peux vous garantir que pendant ces reunions (de plusieurs jours) , ils y avais des tonnes et des tonnes de nouvelles specifications. Resultat: refaire/ supprimer plusieurs parties de code.


Une analyse et conception bien faite au debut est toujours preferable, mais peut etre impossible dans la vie reelle.

[jldgbu]

En effet dans notre discussion on parlait d'un cas idéal où les specs ne changent pas.

Je pense que même dans ce cas et si en plus tu arrives à faire une bonne conception du premier coup, ton soft peut encore évoluer.

Bien évidement pas dans le milieu professionnel, car si tu réponds au besoin...
Mais pour un soft développé perso, si tu avais tout à recommencer tu aurais forcément des idées pour faire mieux et retoucher ta conception.

[jacqueline]

Logiquement il faut faire une analyse des besoins de manière collective, pour ne pas avoir à bricoler l'appli parce qu 'on est passé à coté de quelque chose d'important..

J'ai toujours cet exemple en tête, pour un logiciel de gestion. A coté on lance un projet d'Assurance Qualité, mais rien était prévu pour calculer les indicateurs, comme le coüt de la non qualité, ni pour saisir les données relatives à ce sujet.

C'est ce qui arrive lorsqu 'une équipe projet cogite sur un nouvel outil sans concertation avec les utilisateurs, qui ne sont pas forcément des imbéciles qui tapent sur un clavier pour saisir des données.

Si tout le monde donne son avis, le risque d'inflation est évident.

Aussi certains spécialistes de l'analyse des besoins, recommandent de les classer selon leur importance, la difficulté à les réaliser.

On peut éliminer les plus farfelus..ceux qui coûtent cher en développement pour le peu de gain qu 'ils apportent.

Si ça presse, on peut faire une première version, qui répond aux besoins essentiels, tout en intégrant mentalement les besoins différés, ce qui évite de tout refaire.

C 'est un avis personnel, mais je pense qu 'il faut faire valider l'interface homme machine par les utilisateurs, assez tôt , au lieu de la présenter à la fin. Faire une maquette, la faire tourner avec un outil de simulation .

On te fait des graphiques rudimentaires, d'une mocheté rare, peu configurables, parce que c'est compliqué à faire, il ne faut pas être trop exigeants.. On leur a mis la pression pour qu 'ils nous fassent une exportation pour Excel et chacun pouvait sortir ses graphiques avec des macros, totalement automatisés, et imbatables au point de vue souplesse.. Mais l'équipe projet n 'y avait pas pensé, n'ayant jamais été des utilisateurs, ni même touché aux macros d' Excel.

C'est pire lorsque l'application est structurante et modifie l'organisation de l'entreprise...
on croit faire des économies en décentralisan la saisie vers les opérationnels , sous estimant cette charge de travail supplémentaire, et les problèmes de validation, associés à une notion de pouvoir..

Enfin ne pas laisser de mistigri pour la fin du développement : genre les interfaces avec d'autres applications exotiques, qui peuvent tourner au casse tête, avec des problèmes de synchronisation, qui peuvent remettre en cause le fonctionnement de l'appli ou engendrer des surcoûts inattendus.

C'est la cas de Chorus : des milliers de factures impayées qui s'accumulent, mettant en difficulté des PME, et que l' Etat devra indemniser.

Je trouve que généralement les gens sont trop pressés de se jeter sur le codage, la peur de perdre du temps, ou de ne pas y arriver..

On devrait penser à la fable du lièvre et de la tortue..

Ca n'interdit pas de se jeter sur le codage pour les mistigris, afin de valider au plus vite les boites à chagrin, après on peut revenir à la structure de l'application, l'esprit serein.

Faire un organigramme permet de se poser toutes les questions, au lieu de les découvrir au fur et à mesure du codage ou pire le jour de la validation.

Ca peut permettre de simplifier, de découper en modules, de structurer son programme..

Une autre question à se poser c'est l' analyse des défaillances ( données incohérentes , manquantes, communication défaillante ).Un peu le sentiment que les applictions sont souvent conçues dans un monde idéal où tout marcherait à la perfection.

Une autre notion importante : la sûreté de fonctionnement.

Un site spécialisé indiquait : le côut d'une modif avant codage , c'est 10 € , en cours de codage 100 €, et une fois que l'appli est terminée : 1000 €

Dans le genre d'applis interminables , qui tournent au fiasco, le top c'est le DMP.

Après un premier fiasco, ce projet a fait l'objet d'un audit. : un modèle du genre.

C'est un peu tard , les spécialistes de la gestion de projet recommandent de commencer par une analyse de risques de la conduite de projet. Autrement dit tout ce qui peut le faire capoter, et mettre en face les parades. C'est valable dans tous les domaines, ça se pratique depuis longtemps, mais il semble que ça a tardé à arriver dans l'informatique.

La conduite de projet se résume trop souvent à la planification des tâches ( méthode PERT et diagramme de GANT, et à un suivi des coûts et des délais. Mais faute de faire cette analyse de risques au lancement du projet, on anticipe rien du tout, on ne fait que constater les dégats.

L'audit du DMP : http://lesrapports.ladocumentationfr..._file=0000.pdf

Hélas cet audit n'a servi à rien , ils ont relancé le projet avec les mêmes , dans les mêmes conditions en répétant les mêmes erreurs. C'est la Cour des Comptes qui fait ce constat et eux ont très probablement lu le compte-rendu d'audit.

Un guide publié par le CNRS

Je pense que c'est un bon support, même pour un petit projet, qu 'on conduit seul.

Sur Zdnet, j'ai vu un compte rendu d'un groupe de travail sur la qualité des logiciels.
Difficile pour certains de définir des critères de qualité mesurables à un prestataire, sauf pour la BNP. C'est le processus de développement qu 'il faut mettre sous "assurance qualité" ou contractualiser. C'est ce qui se pratique dans l'industrie à risques avec les processus de certifications, depuis le début de l'étude jusqu'à la maintenance.

Sans aller jusqu 'à ces extrèmes, ce sont des documents à produire, des étapes de validation intermédiaire, des preuves ( la traçabilité ), des commentaires, avec des seuils de nombre de corrections contractuels, une période probatoire , avec des pénalités dissuasives à la clé.

Les prestataires n'ont pas intéret à réduire les délais pour casser les prix et faire une meilleure offre..ni à sous-estimer l'ampleur de la tâche..

J'imagine bien que tous les maîtres d'ouvrage ne sont pas toujours capables de formaliser ces exigences pour les contractualiser.

[kisitomomotene]

L'expérience que j'ai de la conception est que c'est parfois au moment de l'implementation d'une conception qu'apparaisse certain détail qui remette en cause la conception qu'on a faite.
Le problème de la conception est qu'on ne peut pas démontrer par avance qu'on a "bien conçu" et que par conséquence qu'on peut passer à la phase de codage sans possibilité de revenir sur la conception déjà faite.
Donc d'après moi la conception n'est pas la solution au problème du developpement interminable

[fmdao]

En BTSIG, je conseille à mes élèves de ( je résume ) :

1. Essayer d'obtenir un cahier des charges précis et écrit.
2. Faire valider le CdC par sa hiérarchie.
3. S'engager sur ce CdC.
4. Débuter la modélisation/Conception à l'aide d'outil type UML.
5. Coder un premier prototype proprement de préférence en POO.
6. Faire une démos du prototype pour sa hiérarchie.
7. Si le protoype satisfait au CdC, faire la démos au client.
8. Si le client demande des modifs en dehors du CdC revenir à l'étape 1
9. Faire une mise en production.
10. ...

Je leur conseille de tenir au courant leur hiérarchie régulièrement ( si rien n'est prévu par l'entreprise.)

En résumé, on ne peut pas développer sereinement si on ne s'engage pas sur quelque chose de précis.
Ensuite, les outils de conceptions tel que UML permettent de gagner du temps et de s'organiser.
C'est assez difficile à faire comprendre que le developpeur se doit d'être organisé(e), rigoureux et intelligent.

[souviron34]

En BTSIG, je conseille à mes élèves de ( je résume ) :

1. Essayer d'obtenir un cahier des charges précis et écrit.
2. Faire valider le CdC par sa hiérarchie.
3. S'engager sur ce CdC.
4. Débuter la modélisation/Conception à l'aide d'outil type UML.
5. Coder un premier prototype proprement de préférence en POO.
6. Faire une démos du prototype pour sa hiérarchie.
7. Si le protoype satisfait au CdC, faire la démos au client.
8. Si le client demande des modifs en dehors du CdC revenir à l'étape 1
9. Faire une mise en production.
10. ...

Je leur conseille de tenir au courant leur hiérarchie régulièrement ( si rien n'est prévu par l'entreprise.)

En résumé, on ne peut pas développer sereinement si on ne s'engage pas sur quelque chose de précis.
Ensuite, les outils de conceptions tel que UML permettent de gagner du temps et de s'organiser.
C'est assez difficile à faire comprendre que le developpeur se doit d'être organisé(e), rigoureux et intelligent.

Je rélève plien d'incohérences majeures, qui prouve que vous n'avez pas d'expérience de l'industrie, sans parler d'aberrations conceptuelles :

Prenons point à point :

• • Essayer d'obtenir un cahier des charges précis et écrit.

  Il y a 2 cas de figures dans l'industrie : soit on propose un produit sans "demande" partiulière, et c'est à l'entreprise de faire son CdC, soit on répond à un appel d''offre, et il y a un Cdc. Et ce n'est en général pas à un programmeur d'établir le Cdc ou d'y répondre, mais au CP, voire au marketing.
  
  Qu'il faille tout faire pour qu'il soit précis , soit.. Mais là déjà il y a une erreur de fond...
  
  
  
  

• • Faire valider le CdC par sa hiérarchie.

  Voir plus haut... ça se passe plutôt dans l'autre sens... Le Cdc descend la hiérarchie plutôt que la remonte...
  
  
  
  

• • Débuter la modélisation/Conception à l'aide d'outil type UML.

  Primo, en quoi UML est-il spécifiquement nécessaire ????
  
  Secondo, non..... Démarrer la modélisation/conception par un maquettage léger avec le client ou un utilsateur expert est une approche UserCentered et ergonomique beaucoup plus efficace...
  
  Vous mélangez (encore une fois) outil et but d'une part, et d'autre part vous tombez dans le travers des cycles en V : modéliser avant....
  
  
  
  

• • Coder un premier prototype proprement de préférence en POO.

  Que vient faire un conseil de paradigme (POO) là-dedans ?? En quoi cela faciliterait-t-il la création d'un bon prototype ??? Vous re-mélangez outil et but..
  
  D'autre part, vous faites un premier prototype après avoir fait une conception ?????
  
  
  
  

• • Faire une démos du prototype pour sa hiérarchie.

  
  Re-
  
  Vous êtes vraiment imbibé du cycle en V....
  
  Un prototype se montre et s'affine avec des utilisateurs (réels ou potentiels)... En AUCUN cas avec une hiérarchie....
  
  
  
  

• • Si le protoype satisfait au CdC, faire la démos au client.

  
  Voir point plus haut....

En bref, c'est brouillon, peu clair conceptuellement (en mélangeant technique et étape conceptuelle), et surtout faux...

Et c'est une excellente méthode pour avoir des développements interminables....

[_skip]

Primo, en quoi UML est-il spécifiquement nécessaire ????
Secondo, non..... Démarrer la modélisation/conception par un maquettage léger avec le client ou un utilsateur expert est une approche UserCentered et ergonomique beaucoup plus efficace...

C'est ce que prônent toutes les méthodologies agiles finalement : proximité du client, séances régulières, prototypes d'écrans. etc... Tout ce qui évite au développeur de finir avec un produit qui au final répond mal au besoin REEL.

Dans mon equipe de dev, on viens de rendre um soft qui a mis 18 mois a developpez.
Au debut, on avais que quelques idées de ce qu´on devais faire. Le client lui même(plusieurs equipes) ne savais pas encore comment le soft devais se comporter devant quelques situations. Pendant ces 18 mois, on a eu 4 reunions avec le client pour montrer "le produit". Et je peux vous garantir que pendant ces reunions (de plusieurs jours) , ils y avais des tonnes et des tonnes de nouvelles specifications. Resultat: refaire/ supprimer plusieurs parties de code.

Une analyse et conception bien faite au debut est toujours preferable, mais peut etre impossible dans la vie reelle.

Disons que le problème dans ce genre de cas, c'est aussi de se faire payer. Car si le client passe son temps à changer d'avis et venir avec des choses qui n'étaient pas prévus. Les heures de travail doublent ou triplent et les coûts risquent d'exploser.

[fmdao]

Je rélève plien d'incohérences majeures, qui prouve que vous n'avez pas d'expérience de l'industrie, sans parler d'aberrations conceptuelles :

En bref, c'est brouillon, peu clair conceptuellement (en mélangeant technique et étape conceptuelle), et surtout faux...

Et c'est une excellente méthode pour avoir des développements interminables....

Pas la peine de s'énerver .
Alors que dois-je conseiller à mes élèves ( BTS IG ) ?

[souviron34]

Alors que dois-je conseiller à mes élèves ( BTS IG ) ?

conseiller pour faire quoi ????


Le problème de fond est que là vous mélangez de la gestion de projet, de la méthodologie, des paradigmes de langage, des outils, des langages, de la théorie des langages...

On ne sait pas si vous voulez enseigner comment développer, comment gérer un projet, comment utiliser des outils, comment utiliser un ou des langages particuliers, quels sont les différents paradigmes .....

• Si il s'agit de processus de développement, les choses sont conceptuelles : réflexion, analyse, conception, programmation, test, itération...
  
  
• Si il s'agit de gestion de projet, il faut exposer les différents grands types de méthodologies (V, Waterfall, agiles), et lister les avantages et inconvénients... Et, APRES, donner des exemples (par exemple pour Agile Scrum, Xp, RUP...). Mais aussi indiquer les différents rôles (éventuellement hiérarchiques).. Comme je l'ai mentionné, votre compréhension / exposé de la hiérarchie par rapport à un projet est à l'envers de la réalité....
  
  
• Si il s'agit de langages, il faut parler des différents paradigmes (procédural, objet, fonctionnel), et montrer des exemples.. Et l'OO n'a pas plus d'avantages (ou autant d'incovénients) que le reste. ça n'est qu'une philosophie parmi d'autres, qui est certes à la mode mais n'est pas la panacée... Tout n'est qu'une question de point de vue, mais les paradigmes se valent...
  
  
• Si il s'agit d'outils, alors il faut d'abord explorer quelles sont les étapes au cours desquelles il peut y avoir des outils, et, suivant l'étape, UML si vous voulez, mais il peut y avoir aussi tous les outils publics et/ou privés, et ils sont pléthores, utilisés... Mais un outil n'est pas universel, et conseiller UML sans donner de limites et d'encadrement à son utilisation et sans contexte est absurde... En particulier, lors de la conception/modélisation, il y a aussi l'écriture de scénarios, l''enregistrement audio, ou vidéo, d'utilisateurs, et cetc... Il y a aussi les outils de simulation d'interfaces à la main (dessiner à la main une fenêtre avec 2 boutons, et on peut instantanément "cliquer" sur le bouton . Je ne me souviens plus du nom, mais une petite recherche sur les outils de de design d'IHM donnera une liste de produits..). Bref, il y a une foule de produits / d'outils, comme Word, lMS-Project, les diagrammes de Gantt, la suite Rational, etc etc.. Et se limiter à UML ne fait que renforcer une mode sans ouvrir l'esprit à ce qui est disponible, et surtout à ce qui devrait adapté à telle ou telle étape... Par exemple dans les évaluations, il y a les méthodes de points de fonction, COCOMO, etc etc.. Il a aussi les outils de tests, ceux de preuves conceptuelles, etc etc etc..

Voilà pourquoi je disais que c'était brouillon et faux :

les objectifs ne sont pas clairs, et la présentation est fausse et biaisée, et brouillone...



Et dire que vous intervenez dans ce débat pour dire que vous formez des gens !!

Pauvres de nous...



Note : par exemple, "coder un prototype" ne devrait être en AUCUN CAS lié à un langage, un outil ou même un paradigme de langage... C'est une étape du processus de développement.. Qu'on la fasse à la main avec des écrans papier, en VB, en C++, avec un des outils de simulation d'IHM, ou avec n'importe quoi, c'est une phrase conceptuelle décrivant une étape d'un processus... Votre asserrtion "coder un prorotype de préférence en OO" est intrinsèquement absurde, liant 2 choses qui sont orthogonales : une étape d'un processus et un paradigme de langage...

[fmdao]

Et dire que vous intervenez dans ce débat pour dire que vous formez des gens !!

Pauvres de nous...

Merci, j'ai le mérite de me poser des questions contrairement à beaucoup de mes collègues.

[souviron34]

Merci, j'ai le mérite de me poser des questions contrairement à beaucoup de mes collègues.

Ne prenez pas mal mes propos, ce n'est pas mon intention...

Mais votre message initial n'était pas sous forme de question, mais plutôt de "voilà ce que j'enseigne"...


Maintenant il est louable de vouloir s'améliorer et poser des questions...


Mon commentaire à propos de "pauvres de nous" n'était pas particulièrement dirigé contre vous, mais contre ces formations (dont celles que vous avez eues) qui , sous le prétexte "d'informatique", que ça fait moderne, oublient le fond du problème, c'est que pour enseigner il faut maîtriser.... Et que les métiers sont divers, en informatique, et les manières de faire et les concepts aussi.... Mais que fondamentalement, on travaille en informatique comme dans tous les autres métiers du monde : un maçon a besoin d'analyser la situation et les matériaux dont il dispose, de réfléchir à son problème et d'élaborer une solution, puis d'établir de quelle manière il va procéder, et ensuite de rassembler ses matériaux et ses instruments, et enfin de réaliser...


(le fil sur la réforme de Luc Chatel dans la partie Actualités->Politique est à ce titre très intéressante)



Disons que je m'afflige juste du fait que l'enseignement de l'informatique soit (souvent) donné par des personnes n'ayant pas d'exxpérience du métier... Ou bien en tous cas considérant l'informatique comme à part.. Encore une fois c'est comme si on apprenait la théorie de la construction par quelqu'un qui ne s'est jamais cassé le nez sur des vieux mortiers par exemple, ou des sols en pente, ou...



De plus, même dans la théorie, il y a eu des failles dans ce qu'on vous a vous-même appris, puisque votre notion de la hiérarchie et du processus est à l'envers de la réalité...


Le biais de vision est malheureusement beaucoup trop répandu dans notre société actuelle, où le "corporatisme" au mauvais sens du terme prédomine de plus en plus, de même que la diviion tayorienne du travail et des connaissances, au détriment d'une culture générale et d'une relation entre la culture générale, le bon sens, et un métier en particulier...