Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 5 12345 DernièreDernière
Affichage des résultats 1 à 20 sur 89
  1. #1
    Membre habitué

    Homme Profil pro Matthias
    Inscrit en
    septembre 2005
    Messages
    36
    Détails du profil
    Informations personnelles :
    Nom : Homme Matthias
    Âge : 29
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : septembre 2005
    Messages : 36
    Points : 134
    Points
    134

    Par défaut Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?

    Il s'agit en fait d'un débât en deux parties.

    La première peut se résumer à cette question sur programmers.stackexchange.com. Le développeur qui pose la question semble surpris de constater que l'essentiel de son métier n'est pas le développement de nouveaux logiciels mais plutôt la maintenance de logiciels existants. Il évalue même le rapport entre les deux à 90%/10%.
    La première question est donc : pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants ?
    Personnellement je pense que, sans atteindre une proportion de 90/10, la maintenance constitue l'essentiel du métier: on doit modifier des logiciels existants et concevoir de nouveaux logiciels en pensant à leur maintenabilité.

    La deuxième - la question principale - est donc la suivante : Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ? J'inclus dans cette question à la fois le métier de développeur (analyste/développeur...) et celui d'ingénieur d'étude et de développement, dont les responsabilités en matière d'architecture logicielle sont supérieures.

    Je ne dirais pas où j'ai fait mes études car je sais que les programmes ont pas mal changé là-bas depuis et je ne veux pas faire de mauvaise pub, mais pour ma part je n'ai pas été formé correctement à la réalisation de logiciels dans un milieu professionnel. En particulier je n'ai reçu aucune formation en ce qui concerne la maintenabilité. Jamais je n'ai appris à concevoir une application avec pour objectif de la rendre maintenable dans le cadre de mes études. Je trouve cela d'autant plus surprenant que la littérature sur le sujet existe depuis les années 90', je pense notamment à Robert C. Martin. En fait, pour caricaturer, j'ai plus l'impression que l'on forme plus les étudiants à créer des applications "de loisir" que des applications professionnelles.

    Une petite idée pour conclure: en stage on demande généralement aux étudiants de réaliser un projet complet. Pendant leurs études ils doivent réaliser un grand nombre de projets du début à la fin. Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  2. #2
    Modérateur
    Avatar de sevyc64
    Homme Profil pro Yves
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    6 970
    Détails du profil
    Informations personnelles :
    Nom : Homme Yves
    Âge : 41
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 970
    Points : 17 854
    Points
    17 854

    Par défaut

    Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
    Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!

    Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
    Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.
    Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  3. #3
    Membre habitué

    Homme Profil pro Matthias
    Inscrit en
    septembre 2005
    Messages
    36
    Détails du profil
    Informations personnelles :
    Nom : Homme Matthias
    Âge : 29
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : septembre 2005
    Messages : 36
    Points : 134
    Points
    134

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    il leur ait plus enseigner tout ce qui est analyse, conception
    Un problème que j'ai coutume de relever lorsque je discute du sujet : que ce soit sur le Web, dans les livres ou en cours, les notions telles que les design patterns sont presque toujours enseignés à l'envers.
    Un cours de conception objet pourrait par exemple débuter par : "Le cours d'aujourd'hui sera consacré au pattern Stratégie. Le pattern Stratégie consiste..." En revanche le cours ne commencera pratiquement jamais par "Reprenons l'exemple de la semaine dernière: nous voulons ajouter un nouveau moyen de faire blabla, qui pourrait être utilisé par la classe X à la place de la classe Y. Pour l'instant la classe X instancie un Y dans son constructeur..."

    En tout cas peut-être un élément de réponse à:
    Citation Envoyé par sevyc64 Voir le message
    ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    avec lequel je suis entièrement d'accord.
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  4. #4
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 151
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 151
    Points : 10 327
    Points
    10 327

    Par défaut

    Les rapports classiques sont entre 70/30 et 80/20 pour de la maintenance. Un lien présent sur la discussion de stack est à 64/36.

    Après, la distinction n'est pas toujours évidente. En 2008, j'ai été amené à refondre un existant de 1972(une génération d'impressions à destination des clients). Dans le même langage. Par bien des aspects, c'était du projet : nouveau code, nouveau formats de fichiers, nouvelle sortie pour l'impression..... mais aussi de la maintenance préventive : en remettant le code dans un ordre logique(après 36 ans de maintenance, ça bavait de partout, et les mêmes données étaient modifiées bien des fois tout au long du traitement), en corrigeant au passage certains bugs que personne n'avait jamais detecté, en refactorisant les algorithmes, et tout simplement en s'insérant "en douceur" dans les chaines existantes, au même endroit que les anciennes.

    Suivant comment on compte, on arrivera à 60% ou 90%. Mais on travaille majoritairement sur ce qui marche.


    Pour ce qui est de la formation, c'est pareil partout. J'ai fait une formation d'ingénieur plasturgiste, et nous étions bien mieux préparés à la R&D qu'à la production, qui constituait une part non négligeable des emplois. Mais peut-être était-ce quand même mieux identifié qu'en informatique. Nous savions qu'il fallait des ingénieurs de production, bien avant d'être diplômés.

    Pour ce qui est des capacités des codeurs frais sortis des écoles, j'en sais rien. Je fais surtout du cobol, et on a assez peu de jeunots.....
    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.

  5. #5
    Membre habitué

    Homme Profil pro Matthias
    Inscrit en
    septembre 2005
    Messages
    36
    Détails du profil
    Informations personnelles :
    Nom : Homme Matthias
    Âge : 29
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : septembre 2005
    Messages : 36
    Points : 134
    Points
    134

    Par défaut

    Je n'avais pas pensé à cet aspect lorsque je rédigeais mon message initial, mais peut-être que cobol est l'exemple absolu.
    Cobol représente, si l'on en croit MicroFocus, une part importante des applications actuellement utilisées dans les entreprises, et donc une part importante de l'activité maintenance/évolution. Pourtant je ne pense pas que beaucoup de formations l'incluent dans leurs programmes:
    Je fais surtout du cobol, et on a assez peu de jeunots...
    Personnellement je n'ai jamais vu de carte perforée pour de vrai
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  6. #6
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 151
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 151
    Points : 10 327
    Points
    10 327

    Par défaut

    Citation Envoyé par mattj Voir le message
    Je n'avais pas pensé à cet aspect lorsque je rédigeais mon message initial, mais peut-être que cobol est l'exemple absolu.
    Cobol représente, si l'on en croit MicroFocus, une part importante des applications actuellement utilisées dans les entreprises, et donc une part importante de l'activité maintenance/évolution. Pourtant je ne pense pas que beaucoup de formations l'incluent dans leurs programmes:
    En même temps, MicroFocus a tendance à en rajouter(pour des raisons marketing évidentes). Cobol, c'est une niche, y'en a, et y'a des gens qui savent faire. Pas besoin de milliards de jeunots, parfois y'en a un qui se forme sur le tas, et ça suffit(à mon grand regret, j'aimerais être une ressource rare, donc chère).

    Citation Envoyé par mattj Voir le message
    Personnellement je n'ai jamais vu de carte perforée pour de vrai
    Moi non plus. Mon père non plus(et il a commençé en 72).
    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.

  7. #7
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par mattj Voir le message
    Pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants?
    Citation Envoyé par sevyc64 Voir le message
    Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
    Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!
    @sevyc64 : Je ne suis pas d'accord avec ta "séparation", très française.. Ce n'est pas parce qu'on reste longtemps dans la même boîte que l'on fait plus de maintenance..

    Cela dépend du domaine, principalement.. et du profil de qui on parle...

    Il est relativement évident que dans la fabrication de sites Web et d'applis mobiles ou web, on fait plus de dev que de maintenance...

    Par contre (et là à mon avis il y a effectivement une énorme lacune de connaissances, de prise de conscience et de formation, que ce soit pour les jeunes diplômés ou les profs) dans une grande majorité de domaines industriels la maintenance est le coeur, pour la simple raison de la durée de vie et du coût de développement de la plupart des logiciels..

    Outre les héritages (de Fortran , Cobol, C, Prolog, Pascal, Delphi, VB, Motif, ou Forms et autres GKS) de "vieux" outils fonctionnant parfaitement, et représentant non seulement une masse de code considérable mais également une connaissance et un débuggage souvent à toute épreuve (à l'époque c'était souvent des gens du métier qui développaient, et il y a souvent plus de 30 ans de débuggage), même les nouveaux doivent répondre à des impératifs de durée de vie longue... Et souvent même les sites / applis Web...

    De ce que je vois des formations et des devs présentés ici (sans même compter les sites où on clique et où on voit que ce n'est pas mis à jour depuis 5 ans...), il y a effectivement une lacune profonde en ce qui concerne la maintenabilité et le fait de prendre en compte le futur, et je ne parle pas du futur à 2 ans....

    Mais tout ceci, et je l'ai déjà dit ailleurs, provient à mon avis essentiellement et de l'engouement des jeunes vers l'info dû aux jeux et au contact très tôt avec la progammation, et à l'engouement (indû) des moins jeunes pour l'info et de la culture de l'enfant-roi où tous ces jeunes sont des "petits génies" en puissance, et la "créativité" est la source de tout...

    Moi qui suis maintenant un "vieux", je savais dès 1982 que les formations en info étaient juste le remplacement des formations de "secrétaires", et q'on allait former des générations d'"ouvriers" , pas manuels mais intellectuels..

    Tout ce que vous notez provient de celà : à la base 3 illusions :

    • une illusion d'abord que "tout ce qui et nouveau est bien et tout ce qui est ancien est obsolète"
    • une illusion ensuite que "n'importe qui avec de la créativité peut devenir Steve Jobs ou Bill Gates"
    • et enfin une illusion que "n'importe qui avec de la créativité pourra trouver un boulot lui correspondant".


    ça se saurait si tout le monde pouvait être architecte ou compositeur... ou même si n'importe quel musicien pouvait être compositeur... ça se saurait si n'importe quel physicien pouvait avoir un Prix Nobel ou avoir une équation à son nom... ça se saurait si n'importe quel mathématicien pouvait laisser un théorème... Pourquoi l'informatique serait-elle différente ???

    Ce qui a été mal transmis et mal assimilé est que, dans l'info comme en musique, la majorité des "instrumentistes" jouent les oeuvres de quelques autres...

    La prise en compte de ça débouche immédiatement sur la notion de maintenabilité....

    De plus, l'engouement et l'enseignement de langages plus ou moins ésotériques ou de "dernière" génération propae cette idée qu'il n'y a pas à penser au passé (et donc au futur)... (voir plus bas...)



    Citation Envoyé par mattj Voir le message
    Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel?
    Citation Envoyé par sevyc64 Voir le message
    Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.
    Je ne travaille que peu avec des jeunes, mais il suffit de voir ici, que ce soit sur les forums techniques ou sur ce forum, à propos des debuggers et autres, ou de la lisibilité du code..

    Quant à la conception, il suffit de regarder un peu le forum Conception ou Architecture pour s'apercevoir que le bon sens et la logique sont (souvent) écrasés par l'application de modèles / patterns pré-définis...

    Quant à la doc, n'en parlons pas... Entre le "tout javadoc" et le "rien"...


    Citation Envoyé par mattj Voir le message
    Personnellement je n'ai jamais vu de carte perforée pour de vrai
    Moi si Le sujet de thèse d'une de mes collègues à l'époque était la traduction d'un programme scientifique de cartes perforées en programme "fichier".. Et c'était en 1982 ...
    "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. #8
    Membre Expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 082
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 082
    Points : 2 230
    Points
    2 230

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
    Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.
    Les écoles d'informatique comportent il est vrai pas mal d'enseignements pour le jour où la technique et le codage sont abandonnés (management, gestion de projets, etc.). J'y étais encore il n'y a pas si longtemps.

    Citation Envoyé par sevyc64 Voir le message
    Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    Ca s'apprend en école mais après je pense que la mise en place des bonnes pratiques dépend des personnes. C'est là que ce fait la différence entre les développeurs qui font les choses et celles qui les font bien.

    Citation Envoyé par sevyc64 Voir le message
    Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.
    Un gros, que dis-je un énorme +1. Mon apprentissage des débuggeurs se limite officiellement au verso d'une feuille de TP expliquant comment fonctionne GDB dans les grandes lignes (et GDB était loin d'être le point central de ce TP). Pour le reste, c'est un cour de bonnes pratiques si tu choisis la filière orientée développement. Autant dire que c'est succint.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  9. #9
    Membre confirmé Avatar de IsiTech
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2012
    Messages
    93
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2012
    Messages : 93
    Points : 236
    Points
    236

    Par défaut

    Je viens de valider ma L3 Informatique et je continue en master, donc point de vue étudiant.

    On a très peu de cours de conception (Et encore, on a à peine vu le pattern MVC), aucun de gestion de projet, et pas énormément de programmation. Au delà des cours, on a aucune information sur les métiers ou retours de professionnels. Pas de stage non plus hormis stage de fin d'étude. Donc en effet je ne pense pas être bien préparé et informé aux métiers du développement logiciel qui est pourtant ceux qui m'intéressent.

    Concernant le code, on a différents projets à réaliser mais on a aucun retour, on nous communique juste notre note (Et encore...). Avoir un avis sur le projet est déjà compliqué, alors avoir un avis sur le code est impossible. C'est vraiment dommage car on a besoin d'aide extérieure pour améliorer son code.

    Au final je trouve le programme de mon université peu adaptée, c'est d'autant plus bête que c'est une fac bien cotée. C'est vraiment dommage.

  10. #10
    Membre régulier
    Inscrit en
    février 2008
    Messages
    40
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 40
    Points : 73
    Points
    73

    Par défaut

    Pendant mes études il y a quelque chose qui m'a vraiment choqué, en BTS tous nos profs avait une expérience professionnelle en informatique, donc ont étaient vraiment sensibilisés à ces problématiques, pour la maintenance on a même eu un projet "fil rouge" qui à duré sur 2 ou 3 mois.
    Mais après je suis arrivé en L3, et là j'ai vu que la plupart des profs n'avais jamais travaillé de leur vie, ne faisaient que du travail théorique ou des prototypes, et surtout : n'apprenait pas à développer (ne savant pas réellement le faire eux-mêmes). Ça m'a complètement dégouté des cours, le fait que l'on sait que l'on apprend pas grand-chose d'utile et surtout "choqué" de voir des futurs ingénieurs avoir un niveau aussi bas (c'est pas de leur faute, c'est juste les universités qui recrutent n'importe qui comme prof sans regarder les CV), et j'espère vraiment que toutes les universités ne sont pas comme celle où j'ai été.

  11. #11
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 108
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 108
    Points : 7 452
    Points
    7 452

    Par défaut

    Les études d'informatique que j'ai pu faire on pour la plus part du temps été mal adaptée au monde professionnel.

    j'avais par exemple énormément de conception. UML , merise , et on ne pouvait pas faire une ligne de code sans une étude complète. Certes très formateur mais je n'ai depuis jamais eu le temps de le faire réellement (un petit diagramme sur un coin de post it dans le meilleure des cas).
    Parce que entre avoir une conception au poil ou avoir une jolie interface rapidement , le client à vite fait son choix.

    En ce qui concerne la maintenance , c'est un peu le cycle infernal. Etudiants pas formés , donc projet galère à maintenir , ces étudiants non formé ne feront sans doute jamais l'effort de coder en vue de la maintenance et donc ne transmettrons jamais cette expérience à d'éventuels stagiaires.

    Après il y'a aussi la réalité du terrain. Les timelines et les directions non technique te force parfois (hélas) à faire un boulot dégueulasse ...

  12. #12
    Membre chevronné
    Homme Profil pro
    Inscrit en
    juin 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 287
    Points : 739
    Points
    739

    Par défaut

    ... En stage on demande généralement aux étudiants de réaliser un projet complet. Pendant leurs études ils doivent réaliser un grand nombre de projets du début à la fin. Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?
    Je suis totalement d'accord avec ta proposition !
    Un de mes projets de seconde année d'école d'ingénieur a été de réaliser en trois mois un mini DPI (Dossier Patient Informatisé, utilisé dans les hôpitaux).

    S'il est vrai que les trois profs suivant les projets pouvaient difficilement passer en revu tout le code de la demi-douzaine de groupes, la note finale reposaient principalement sur "la gestion du projet" ; çàd avoir rempli ce qu'on avait mis dans le cahier des charges initial.

    L'argument principal étant : "Les trois-quarts d'entre vous passeront chefs de projet dans 3-4 ans" ... et en attendant on fait quoi ?! Et si on veut rester en R&D ?!

    Et j'ai l'impression que c'est pareil pour beaucoup d'écoles d'ingénieurs qui proposent une formation dans le domaine informatique.
    Certes, savoir discerner le besoin du désir du client, concevoir un cahier des charges fonctionnelles et techniques, ça aide à ne pas coder quelque chose qui ne sera jamais utilisé. Mais si la fonctionnalité requiert 10 requêtes en base alors qu'une seule pourrait suffire, il vaut presque mieux que la fonctionnalité n'eut pas existé ...

    Donc en attendant, j'ai appris seul, et ce n'est pas toujours le meilleur moyen de procéder.
    "Donnez un poisson à un Homme, et il mangera un jour. Apprenez-lui à pêcher, et il mangera tous les jours."

  13. #13
    Membre éprouvé
    Inscrit en
    octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : octobre 2007
    Messages : 210
    Points : 448
    Points
    448

    Par défaut

    Ce qu'il manque dans l'enseignement à l'université, ce sont toutes les méthodes de développement de qualité. Test unitaires, Refactoring, nommage correct des classes/méthodes/variables, indentation correct du code (oh purée ça... ne jamais prendre un stagiaire sans CheckStyle!), DRY, principes et mise en place d'une intégration continue, procédures/scripts de déploiement automatisés (devops), gestion des versions logicielles ...


    Pour se dégager de ses responsabilités, l'enseignement évoque la sacro-sainte séparation entre enseignement et monde du travail : "On vous enseigne les bases, le reste vous l'apprendrez en entreprise !".
    Ou encore "On vous enseigne les additions, et pour les multiplications vous les verrez en entreprise".

  14. #14
    Expert Confirmé
    Avatar de GLDavid
    Inscrit en
    janvier 2003
    Messages
    2 684
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 684
    Points : 2 847
    Points
    2 847

    Par défaut

    Bonjour

    Un petit avis qui vaut ce qu'il vaut mais qui confortera les opinions déjà décrites.
    Où plutôt un exemple.
    J'ai été recruté il y a un 18 mois dans une boîte sur un existant: grosse base de données avec des procédures stockées kilométriques et site en PHP.
    La philosophie de la cheffe de projet était: aucun check n'est fait car on travaille avec des gens sérieux.
    Ben voyons !

    Aujourd'hui, je dois faire le support de cette m.... sans nom développée par des jeunes. Je précise que dans cette équipe, je suis le plus âgé. J'ai été consultant auparavant et quand je remettais un projet en production, il était testé, code des unit tests à l'appui et validé par milestones avec le client.
    Ce machin a été développé avec certitude que ça marcherait parce que:
    1) les utilisateurs sont gentils et sérieux et ne font aucune erreur (humains + robots, les robots, j'ai confiance, les humains, moins).
    2) on est des bêtes en PL/SQL donc le support sera vite fait bien fait.

    Vous comprenez pourquoi je regarde ailleurs.
    Au passage, je précise que j'ai formé des stagiaires à ma logique de qualité du temps où j'étais consultant et je suis fier de leur accomplissement. Je suis pour que les jeunes mettent les mains dans le cambouis et aillent au bout de leurs idées. Mais il faut un encadrement ! Si le management est incapable de baliser le chemin, vous pouvez être sûr que le projet sera bien piètre.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  15. #15
    Expert Confirmé

    Développeur NTIC
    Inscrit en
    janvier 2011
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 682
    Points : 3 805
    Points
    3 805

    Par défaut

    Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ?
    Certainement pas les universités ...

    Les écoles françaises non plus

    C'est une question d'adaptabilité, en général il faut un voire plusieurs mois, mais, oui, le métier de développeur est autant composé de maintenance de logiciels existants (voir d'améliorations), que de création de logiciels (du moins, c'est ma vision des choses depuis que je suis dans ma boîte).

  16. #16
    Membre chevronné
    Homme Profil pro Jérôme Frossard
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    192
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérôme Frossard
    Âge : 41
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 192
    Points : 761
    Points
    761

    Par défaut

    Personnellement, à part pour de petits projets peut-être, je ne vois pas vraiment de différence entre développement et maintenance. Lorsqu'on travaille sur des applications dont les versions successives s'étendent sur plusieurs années, une nouvelle version contient du nouveau développement et des améliorations de fonctionnalités existantes, on peut donc voir le travail comme du développement ou de la maintenance. Et même lorsque le projet n'est pas très grand, en utilisant une méthode agile, une partie du travaille consiste en la refactorisation du code existant ce qui peut être vu comme de la maintenance. Dans un cas comme dans l'autre, on a un projet avec un début connu, une fin qui devrait l'être et entre deux on fait de la conception et de la programmation.

    Comme j'ai également travaillé dans une équipe de support de 3ème niveau chargée de la gestion des problèmes, là le travail est un peu différent; il s'agit de rechercher les causes des problèmes et soumettre des propositions de solutions aux équipes de développement, mais il ne s'agit pas de maintenance non plus

  17. #17
    Futur Membre du Club
    Inscrit en
    mai 2006
    Messages
    61
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : mai 2006
    Messages : 61
    Points : 16
    Points
    16

    Par défaut Hum

    Mon baggage universitaire (jusqu'au master) m'a donné tous les outils dont j'ai besoin, des tests unitaires en passant par UML, conventions de nommage, code DRY, différents langages de modélisation, différents langages de développement...

    La seule chose à laquelle je n'étais pas pret était le code qui n'avait pas de tests automatisé, pas de modèle conceptuel écrit, pas de documentation, super copié collé, pas MVC avec des fonctions de plus de 1000 lignes. Enfin bon, je profite des maintenances pour rendre le code plus maintenable quand je modifie pas mal de choses à meme endroits.

  18. #18
    Membre actif
    Homme Profil pro Maxime Estrade
    Développeur en systèmes embarqués
    Inscrit en
    juillet 2009
    Messages
    99
    Détails du profil
    Informations personnelles :
    Nom : Homme Maxime Estrade
    Âge : 25
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2009
    Messages : 99
    Points : 155
    Points
    155

    Par défaut

    Comme toujours on trouve de bon sujet sur Développez

    Je me sens concerné par le sujet puisque je rentre en 5ème année et je commence à toucher au bout de mes études, ou plutôt leur commencement.

    Je pense que l'informatique est bien trop vaste pour aborder tous les sujets durant ses études. Comment former une personne sur une techno/pratique sans un projet qui va avec pour lui démontrer l'intérêt de cette techno/pattern/gdb/etc

    On est dans un domaine où nous sommes en formation continu et où les pratiquent des professionnels sont aussi nombreuses que le les lignes de code d'un projet.

    Si je regarde aujourd'hui, je sais que je maitrise seulement les bases de Visual Studio même si je suis bien conscient de l'étendue des possibilités offertes. Pourtant, je ne les verrais surement jamais sauf si un projet m'amène à m'y intéresser. C'est tellement vaste que prendre un bout arbitrairement pour commencer peut amener à rater l'essentiel.

    A mes yeux, le métier de développeur est difficilement enseignable et oblige à faire des choix restrictif sur ce qui est enseigné. Du coup on se retrouve forcement avec des désaveux lors de notre entrée sur le marché du travail. Il nous manque toujours LA techno que l'entreprise recherche (parmi les 15/20 citées dans l'annonce, évidement).

    Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?

    Edit : quand je parle de techno, j'englobe aussi les outils ... dedans ^^ C'est les techno au sens large du thème.
    Estrade Maxime
    Estrad_m
    Responsable Communication Roll the World.
    {Epitech}.5ème Année

  19. #19
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par LordMacharius Voir le message
    Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?
    Par justement ne pas enseigner des choses pointues, mais des choses génériques, une manière de penser, d'analyser, un esprit critique, et surtout du bon sens et de la logique...

    Dans les autres domaines que l'info, un ingénieur est à peu près équivalent à un Docteur parce que on sait qu'il n'est pas opérationnel, mais on sait qu'il peut apprendre à l'être en 6 mois.

    Parce qu'on lui a enseigné une manière de réfléchir, plus les bases.

    Vouloir faire des gens "immédiatement sur le marché" est la clé de l'échec, car les technos bougent... Alors que le fond reste...

    Culture générale et des concepts de base plutôt que telle ou telle méthodo, tel ou tel langage...

    D'où la remarque par rapport au debugger : ne pas savoir se servir de tel ou tel outil, ça s'apprend suivant l'outil... Raisonner pour débugger, c'est de la logique et de l'analyse, quel que soit l'outil (ou sans).
    "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

  20. #20
    Expert Confirmé

    Développeur NTIC
    Inscrit en
    janvier 2011
    Messages
    1 682
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 682
    Points : 3 805
    Points
    3 805

    Par défaut

    Citation Envoyé par LordMacharius Voir le message
    Comment former une personne sur une techno/pratique sans un projet qui va avec pour lui démontrer l'intérêt de cette techno/pattern/gdb/etc ?
    Ca ne sert strictement à rien de former une personne sur telle ou telle technologie car les technologies évoluent. Ce qu'il faut en revanche, c'est pouvoir analyser, comprendre le fonctionnement d'une nouvelle technologie, apprendre à se la réapproprier pour ensuite apprendre les mécaniques de la programmation et réutiliser cette technologie.

    Voilà pourquoi le métier est intéressant, on ne fera pas la même chose toute notre vie. Et je plains ceux qui ne se tiennent pas à jour et qui seront dépassés dans 2 ans ...

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •