Discussion :

[CapucineD]

Bonsoir!


Je commence mon premier projet informatique professionnel, c'est la première fois que je le fais pour un "client" (mon patron).
J'ai la tête sous l'au en raison de la densité de la doc et en raison du fait que je viens d'informatique décisionnelle et que je me lance dans le développement plutôt ingénieur. Je ne veux pas faire ma pauvre fille perdue appelant à l'aide son chevalier servant! Non, je veux y arriver. Je pense plutôt avoir besoin de conseils.

Je dois réaliser une application permettant d’interfacer des périphériques de données vers des antennes de pointage.

I. En clair le travail demandé:

1. Résumer les différents besoins et les manques depuis la doc et le matéril
2. Utiliser l’ensemble des capacités de la caméra (image, enregistrement et suivi d’objet...)
3. Analyser les capacités des différents périphériques et leur limitation, vitesse...
4. Proposer une maquette IHM claire prenant en compte le fonctionnement demandé du programme (faite)
   
   a. Configuration des périphériques branchés par détection
   b. Prendre en compte la scène et la position des périphériques. Par exemple les motorisations ne sont toujours colocalisées. Il faut donc prendre en compte les problèmes de parallaxe et de biais
   c. Définir les limitations d’emploi des motorisations : angles autorisés (azimut site) et angles interdits
   d. Proposer des couplages entre les entrées et les sorties en respectant les équipements tournants et leurs câbles (impossibilité de faire plusieurs tours par exemple par rapport au joint tournant)
   e. Afficher une cartographie type Google en prenant en compte la position du portable et son orientation en fonction du nord (écrire la procédure permettant de récupérer facilement des cartes supplémentaires)
5. Faire valider le processus avant le développement en Visual Basic
6. Développer le programme en intégrant des commentaires (IHM claire) en Visual Basic
7. Tester chaque périphérique avec l’ensemble des fonctionnalités intrinsèques
8. Montrer un couplage périphériques d’entrée / périphériques de sortie
9. Développer l’ensemble des codes permettant de réaliser le travail demandé.
10. Faire une démonstration

II. En plus précis le travail que j'ai à réaliser est le suivant


Les périphériques d'entrée sont:

• Récepteur GPS relié par liaison RS 232
• Balise AIS par liaison RS 232
• Caméra IP
• Interface opérateur : clavier, souris et joystick USB
• Two lines satellites

Les périphériques de sorties:

• Caméra IP
• Deux systèmes de motorisations par liaison RS 232
• Ecran d’IHM opérateur

Pour cela j'ai reçu de la documentation sur:

• Camera IP et protocole PELCO
• Balises AIS et protocole utilisé
• Documentation des Motorisations
• Documentation Visual studio
• Exemples de programmes de pilotages des caméras (l'un en .NET est particulièrement avancé en tant qu'interface graphique)

III. Mes questions face à la première réalisation d'un logiciel pour un client:
Comment m'organiser pour réaliser ce logiciel sachant que je n'ai plus fait de physique depuis la terminale?

Je me suis débrouillée pour trouver un peu de documentation sur

• Format des « Two lines » satellites
• Interfaçage de joystick, souris, caméras...

Mais je ne suis pas tombée sur des sources vraiment sérieuse sur:

• Documentation sur le pilotage de port COM sur Windows 10
• Trame NMEA GPS et son paramétrage

J'ai déjà réalisé un plan d'IHM disponible et commentable ici: https://ishmdesign.mybalsamiq.com/projects/motocam/grid

Je pense devoir commencer avec un diagramme de classe car on m'a aussi donné le déroulement du programme (je pense donc avoir peut-être mis la charrue avant les boeuf en commençant par l'IHM)...:

Déroulement du programme

1. Lancement de l’application (une seule instance)
2. Chargement d’un fichier de configuration (antennes, capacités...)
3. Lecture des paramètres des périphériques branchés.
4. Affichage sur l’IHM de la configuration
5. Enregistrement du fichier de configuration par défaut (en quittant l’application) et avec un autre nom (menu)
6. Réglage du 0 des pointages (Nord ou autre cap)
7. Chargement et enregistrement des limitations des périphériques (risques pour les câbles)
8. Choix du périphériques maitre des motorisations : affichage des angles de pointage : valeurs et graphique (rose des vents par exemple)
9. Couplage possible d’une motorisation ou des deux dans les limites des angles autorisés
10. (marche arrêt sur ordre opérateur ou atteinte d’une limite)
11. Affichage de la position du porteur et des données GPS, AIS...
12. Affichage de l’image de la caméra et de ces fonctions (surveillance, tracking...)
13. Enregistrement de la vidéo comme film ou image (durée et période de répétition pour les
14. images)
15. Quitter l’application et enregistrer la dernière configuration

Voilà, en clair, j'ai des doutes quant à mon organisation pour réaliser ce premier logiciel "pro", et j'ai besoin de conseils car je ne sais plus par ou commencer depuis une semaine. J'ai jusqu'à fin août pour le réaliser!

Merci d'avance pour votre aide!

Capuçine

[Logan Mauzaize]

Mon premier avis et général sur la question : soit Lean.

Faut bien commencer par un bout et ne pas attendre que tout soit terminé pour le montrer. Commence par ce que te semble créés de la valeur sans trop te focaliser sur ce que tu cherches à avoir en terme de produit finit.
A titre d'exemple, on peut imaginer (je n'ai pas vraiment bien lu toute la partie fonctionnelle), une truc sans interface utilisateur, tous les paramètres en dur et qui ne collecte qu'une partie des informations. D'autres préférons une IHM creuse (type magicien d'Oz).

Il faut juste cibler ce qui créé de la valeur. De ce qu'il en ressort par une lecture en diagonale, c'est la captation de données et le paramétrage de l'antenne. Une fois que tu es capable de réaliser "l'enregistrement des données", le reste c'est beaucoup de fignolage, peu de risques, etc.

De mon point de vue, pour un premier développement et déjà avoir en tête l'idée de faire un sketching (surtout avec Balsamiq !) c'est plutôt pas mal. Il est extrêmement fréquent que je conseille aux équipes de faire du wireframing/sketching d'interface (et en général je conseille Balsamiq ou Pencil). Bien sûr le risque en ayant présenté des écrans, c'est qu'ils vont les vouloir (EDIT) très rapidement, ce qui sera un peu à contre-courant du Lean.

Néanmoins, si tu découpes ton logiciel en différentes fonctionnalités, cela restera à eux de déterminer ce qu'ils préfèrent avoir en premier. Si prioriser devient compliquer pour eux, il y a différentes techniques comme le poker planning et autres.



Concernant ta problématique avec un port COM, c'est effectivement peu répandu comme interface désormais. L'USB ayant largement supplanté ce type de connectique, tout comme le parallèle a disparu.


Concernant la physique, je pense que c'est surtout les maths que tu dois adresser. La partie physique étant normalement entièrement pris en charge par l'antenne et qui doit te fournir des informations via une API et/ou un driver. Donc pour les maths, je pense que tu devrais fouiller du côté des bibliothèques du dommaine du SIG. Ce genre de problématique doit être largement répandu dans ce domaine et donc largement traité. Idem pour la partie GPS. N'hésites pas à poster un message dans la section adéquate du forum : http://www.developpez.net/forums/f12...-geographique/


Le travail de conception pourrait éventuellement commencer par un dictionnaire plutôt d'un diagramme de classe. Ca dépend des préférences. En général ce sont plutôt les procédés haut-niveau que l'on commence par modéliser (ex. : diagramme des cas d'utilisation système). Tu peux t'inspirer de MERISE ou RUP par exemple. Dans d'autres approches plus agile, ce sera plutôt la rédaction de User Story.

[el_slapper]

Je plussoie Logan, et j'insiste dans son sens : il faut avoir très vite, et très régulièrement, des trucs à montrer. Pour deux raisons essentielles.

(1)ça évite l'effet tunnel. Si on fait fausse route, les autres nous le diront très vite.
(2)ça permet de communiquer. Montrer l'avancement du projet avec des choses tangibles peut souvent faire la différence entre un projet fini et un projet annulé, le sponsor ayant arrêté de financer faute de progrès visibles(alors qu'en coulisses, ça avançait comme prévu).

le point 2 est désagréable, et souvent mis sous le tapis parcequ'il pousse parfois à prendre des options suboptimales du seul point de vue de la gestion interne du projet. Mais il est pourtant essentiel : si le sponsor n'est pas convaincu qu'on avance, il va hésiter à continuer à financer.

[CapucineD]

Merci beaucoup pour tous vos conseils qui m'ont été très utile dans la préparation de mon plan de travail! C'était vraiment de super réponses très détaillées!