Une société lance un appel d'offre auprès de développeurs informatiques : elle cherche un sous traitant qui réalisera un simulateur qu'elle pourra étendre avec ses propres composants qu'elle tient à garder secrets car c'est son savoir-faire). La société vous a communiquée son cahier des charges quelques semaines auparavant, vous laissant le temps de réaliser un prototype. Ce qui vous a permis de vous faire une idée de ce que vous pouvez proposer dans les délais qu'elle vous impose. Elle procède maintenant à la phase de casting.
Cette présentation est un enjeu important. Si vous remportez ce projet, le contrat permet de faire vivre votre société pendant 1 an. La société choisira son sous-traitant en s'appuyant entre autres sur les critères suivants :
- la qualité et la pertinence de la présentation,
- l'imagination et le dynamisme de l'équipe,
- la cohésion et le sérieux de l'équipe,
- les compétences techniques :
- la qualité de l'architecture du logicielle, ses facilités d'extensions,
- la capacité de l'équipe à anticiper et résoudre les problèmes techniques,
- la capacité à tenir un planning : répartir le travail et établir un plan d'intégration
c'est-à-dire :
- identifier les parties techniquement difficiles ou longues à réaliser,
- affecter en conséquences le bon nombre de personnes à chaque partie,
- être capable de modifier cette répartition en fonction des difficultés rencontrées,
- éviter qu'une tâche cruciale repose sur une seule personne,
- définir des interfaces claires, précises et adaptables entre les différentes composantes du logiciel afin de faciliter l'intégration.
- répartir les tâches et structurer le code de manière à pouvoir mener des développements en parallèles et à pouvoir les tester séparement.
- prévoir des phases de validation avec le client des tâches terminées
- établir un plan de test et d'intégration qui permet de tester AU PLUS TÔT car
« coder 2 jours sans pouvoir tester c'est prendre le risque de jeter 2 jours de codage à la poubelle »
Règles absolues :
Il ne s'agit pas de faire la même présentation que celle de l'avant projet. La première présentation était destinée à convaincre un industriel de vous confier le contrat de réalisation d'un logiciel. Cette seconde présentation correspond à la livraison du logiciel. Le public sera constitué d'utilisateurs du logiciel et de développeurs qui seront chargé d'intégrer des extensions à votre logiciel. Voici un exemple de ce que nous attendons :Ceci n'est qu'un exemple de présentation type ; vous êtes libres de parler de ce qui vous semble pertinent. Mais évitez les banalités du genre :
- Présentation pour l'utilisateur : du logiciel et des fonctionnalités réalisées
- Présentation pour les futurs développeurs : des aspects techniques (architecture, classes, algorithmique,...)
- Présentation des difficultés techniques rencontrées et des solutions originales apportés
- Bilan du projet
- Planning effectif et répartition du travail durant le projet
- Décalage par rapport à la proposition de départ et au planning initial
- auto-critique : si c'etait à refaire, que changerions nous ?
- Qu'avons nous appris (en dehors des banalités classiques...)
« nous avons beaucoup appris sur le travail en équipe et le gestion de projet, deux points qui nous seront utiles dans notre future carrière » « ce projet nous a permis de comprendre ce qu'était vraiment le travail d'un ingénieur en informatique »Démonstration du logiciel
Une démo, ça se prépare. Il faut répéter de manière à impressionner le jury / les clients en leur montrant dans le temps imparti un maximum de choses (qui marchent) et en évitant de mettre en évidence les parties qui ne sont pas tout à fait au point. Il faut aussi que la démo soit organisée de manière à ce que les clients puissent suivre et comprendre les réactions du logiciel. Il faut donc choisir des exemples qui soient compréhensibles par le jury. Il faut que la démo présente les fonctionnalités annoncées dans la présentation. C'est à vous de faire la démo. Il est très mal vu de laisser le client se débrouiller tout seul en 10 min avec un logiciel qu'il ne connait pas.Quelques précisions pour les fumistes
- Rappellons que les notes des membres du groupe peuvent varier d'un membre à l'autre.
- Lors de la soutenance nous demandons à chacun le travail qu'il a effectué. Évidemment nous poserons des questions pour vérifier les affirmations de chacun. L'argument consistant à dire "j'ai travaillé sur une partie qui n'a finalement pas été intégré au projet" est irrecevable. Il serait impensable de passer 10 jours à coder quelquechose qui ne sert à rien.
- Nous nous reservons le droit de demander à chaque membre du groupe (par email) son avis sur le travail des autres membres du groupe. Nous recoupons les informations.
- La présence au rendez-vous avec le tuteur est aussi prise en compte.
- L'argument consistant à dire "je travaillais chez moi" n'est pas recevable. On ne fait pas partie d'une équipe si on ne vient pas au réunion.
