Quelle méthode ?

Par contre, entre fada
Moi aussi je cherche le bâto du phadha...
mé ca cé 1 ôtre phil (ki raisthe a fer)

C'est bien rigolo tout ça.
un poil à côté et enfantin quand même. Je cite :
"Le manuel d'une application informatique décrit, si possible d'une manière exhaustive et claire, toutes les fonctionnalités du logiciel."
Et qui a définit les fonctionalités:
- ça peut être l'étude préalable de besoin faite avec l'utilisateur, un cahier des charges fonctionnel rédigé lui aussi en colaboration entre les users et les techniciens;...

Si je ne m'abuse, c'en était à peu près à ce stade lorsque ,et tu as tout a fait raison sur ce point, des users aussi techniciens se sont noyés (c'est malheureusement habituel chez les français habitués à la bite et au couteau) dans des considérations d'un autre âge (dans le développement du projet, s'entend) et confondu leurs différents rôles.
J'avais lancé un fil sur les interfaces qui était justement ce mot d'alerte : les orientations doivent être prises au départ par les utilisateurs qui, selon qu'ils voudront un super bidule dirigiste ou un gentil machin intuitif détermineront par la même les fonctionnalités essentielles.
Quant à rédiger un guide utilisateur, je l'ai toujours fait rédiger PAR les utilisateurs LORS des phases de recettes, parce que ce doit être un document de référence et pour tel, il doit être exact , exhaustif (description et utilisation des interfaces, fonctionnalités et objectifs de chaque procédure) et qu'il n'est pas possible, lors de la phase préalable (celle où je pense en est resté ce projet, de connaître les dialogues dans le détail puisque les fonctionnalités ne sont pas recensées exhaustivemnt,....... blablabla, la poule et l'oeuf.

Pas d'accord
Je te cite : "Dès que l'on sort des applis classiques de bureautique, déjà au niveau des drivers d'imprimante, de sono, de modem, de routeurs, de scan etc... c'est le parcours du combattant. On passe plus de temps à se regarder pédaler qu'à pédaler".

On lève moins souvent le capot avec Linux,ce n'est pas nécessaire si on utilise le système dans les mêmes limites que celui, quasi monopolistique, d'une société bien connue. La différence, c'est que ça fonctionne, donc il n'y a pas besoin de lever le capot.
Rigolo de constater par ailleurs la quantité d'applications portées depuis Linux sur les systèmes officiellement payants : PHPmyadmin, Apache, OpenOffice, Gimp, pour n'en citer que quelques un. Qui tournent par ailleurs indubitablement mieux sur leur système d'origine.

Ce qui fait que certains s'y perdent, c'est qu'ici, il est permis, non-obligatoire, mais permis, de soulever le capot. Et, là comme ailleurs, il est préférable pour la suite des évènements de savoir ce que l'on fait. Promis, je ne démonterai jamais, quoique, une moissoneuse-batteuse.

Je veux bien faire un truc
Mais uniquement les jours de pluie, quand je ne peux pas bosser sur autre chose.
J'ai lu attentivement ton post, Sailsoft, et je pense que tu as raison.
A une lointaine époque, j'ai fait du développement (systèmes de contrôle électronique de documents, entre autres, pour ceux qui connaissent) pour une multinationale d'origine japonaise.
Moi, ma démarche était un peu différente mais je pense qu'elle rejoignait la tienne.
La mienne consistait à demander aux utilisateurs ce qu'ils attendaient d'un soft ou d'une base données, à le mettre sur papier, et à sortir le plus rapidement possible une "maquette" à massacrer par les susdits utilisateurs, afin de confronter leurs demandes avec une utilisation réelle, et modifier le bastringue en fonction.
Si quelqu'un peut me résumer les fonctionnalités attendues et qu'on puisse discuter le coup (priorités,...), je veux bien tenter de dessiner des écrans. Pour le reste, ce que j'ai encore comme connaissances est sans doute trop spécifique d'une part, et trop néenderthalien d'autre part...

c'est rigolo ...
5 posts plus tard c'est reparti dans les querelles de clochers par les spécialistes :-D

Voyons, voyons, ça fait longtemps qu'il n'y a plus grand chose de neuf à inventer comme concepts pour un logiciel de navigation basique pour la plaisance.

A ma connaissance (mais je peux me tromper !) , le seul outil qui n'existe pas en logiciel à acheter pas cher, c'est celui qui permettrait de se fabriquer des cartes vectorielles soi-même au format standard S57 à partir des cartes papier.

Tout le reste (nav basique à partir de cartes raster ou vectorielles, fabrication de cartes raster à partir des cartes papier) se trouve à plus ou moins 100 euros, voire gratuit pour les fonctions basiques.

Cela marque fortement les limites dans lesquelles on peut se mouvoir pour inventer du neuf.

Uninx linux
c'est tres bien,

mais combien de personnes savent ce qu'est VI

car il ne faut pas se leurrer, mettre en place linux n'est pas aussi simple que cela (pour un néophite,héophite) .
parler de noyaux c'est déja passer au dessus de sa connaissance (mis à part ceux de pêche ou autre)

la cartographie numérique, c'est trés bien mais elle ne sait pas gerer l'oeil de l'humain qui à une culture papier

ce que veut un utilisateur, c'est un micro qui ne tombe jamais en panne (soft) et qui réponde à ses exigences à lui.

Je bien d'accord
avec toi, Robert. Peu importe qu'un bourrin fonctionne mieux qu'un autre ou pas, ce qui compte est effectivement ce que les gens utilisent. Ma réaction ne portait que sur des points avec lequels je ne suis pas d'accord, et qui sont bien loin du sujet du fil.

??
J’utilise indépendamment linux et windows, pour moi ce n’est pas un problème,
mais je me met à la place des utilisateurs basiques qui lorsqu’ il faut changer de version
ou ajouter un soft pas toujours bien pensé pour son installation suivant les distributions.

La multiplication des distributions RPM, Read heat , Suse ou autre ne facilite pas
l’engouement et le choix d’aller vers linux

j’avoue que winmachin est mal fait, mais il fonctionne si on ne lui demande pas trop
de choses à la foi car il ne supporte pas plusieurs applications (gourmandes en mémoire(voir maxsea))
en même temps (même si on à le top du top du moment)

mais pour quidam moyen c’est surement vers win qu’il va se retourner

Méthode, suite 1
J'ai quitté un peu le fil pour le week end : avec la dépression qui vient de passer, vous pensez bien que j'allais pas rater la poudre fraiche. J'arrive juste d'une séance de navigation aux sensations dans le coton, avec de temps en temps un sapin qui s'invite dans la réalité qu'on s'arrange à faire passer sur le coté du champ visuel. Whaoooooo ! j'aime glisser sur l'eau, j'y peux rien, même lorsqu'elle est cristallisée. Et y'a une deuxième dépression derrière qui arrive ce soir...

Une parenthèses : je me suis trouvé une fois dans la benne de La Flégère à Cham avec Eric Tabarly. Il a vu que je le reconnaissais, et je crois qu'il n'aimait pas ça. Au sommet il a chaussé, et je me suis dit "tu te fais plaisir, tu skies avec lui". Eh bien j'aime autant vous dire que j'ai eu du mal et que j'ai finalement dû laisser tomber parce que ma douce de l'époque, en rade derrière bien que loin d'être nulle, n'aurait pas apprécié que je la largue pour un coureur des mers ! Sacré skieur, Eric !

Je reviens à mon fil. La discussion sur la méthode elle même, avec quelques interventions d'informaticiens, semble indiquer un certain consensus pour dire que l'important est de tirer les vers du nez des utilisateurs pour savoir ce dont ils ont besoin. Mais, et là je m'adresse aux non informaticiens qui me lisent, il doit être clair qu'on ne va pas leur demander de prendre position sur telle ou telle plateforme technique (un micro, un système d'exploitation, une distribution, etc...). Lorsque j'achète un CD de musique, je me fous de savoir si mon lecteur est un youkaidi ou un josephson. Je mets le CD dedans et j'entends la musique, c'est tout. La question est donc seulement de savoir quelle musique je veux entendre.

L'enfer, c'est bien connu, est pavé de bonnes intentions, et j'ai peur que les informaticiens que nous sommes, surtout lorsqu'ils se retrouvent à plus de deux dans un lieu quelconque, fut il le café du commerce du coin (ou un fil HEO), fassent fuir dans les minutes (ou les posts) qui suivent ceux pour qui l'informatique n'est qu'un outil sur leur bureau (ou sur leur table à carte). Alors, pour parler des mérites de linuxaube version trucmuche ou du langage pouet pouet, faisons un fil entre nous, en annonçant bien la couleur, pour que ceux qui s'en foutent ne perdent pas de temps.

Mais j'aimerais bien lire une discussion entre marins, qui ont quelque expérience de l'utilisation de l'informatique au bureau ou à la maison puisqu'ils sont sur HEO. Quelle que soit le degré (fut-ce le degré zéro) d'expérience de l'informatique en mer qu'ils aient, ils devraient pouvoir dire quels sont les services qu'ils aimeraient avoir de leur micro à bord. J'ai vu une application super sur Excel pour gérer la cambuse. Et je suis certain que des idées comme ça, il y en a d'autres.

Pour ce qui concerne la cartographie, effectivement comme cela a été dit, il y a des produits disponibles dans le commerce. Pour être un peu caustique, je dirais qu'au dernier salon il n'y avait que ça sur les stands. Mais je dois vous dire que pour l'instant, le site internet où je peux charger gratos des cartes vectorielles et le freeware qui permet de les lire, je ne connais pas, du moins pas des vraies cartes marines. Donc si ça n'existe pas, ça reste à faire. Le travail est double : créer les données, présenter les données. Dans les deux cas, je suis certain que le travail collaboratif est LA solution, et que c'est à la portée d'une communauté comme celle des heoiens : et là, l'exemple de Linux est effectivement instructif.

Mais AMHA vouloir faire quelque chose d'aussi précis, complet, évolutif, et donc "de référence" que les cartes marines, par exemple du réputé SHOM, est un leurre. Il faut avoir les cartes papier à bord et il faut savoir s'en servir. Mais quelque chose de plus simple (le trait de cote, les isobathes jusqu'à portée de la quille des voiliers pour les zones d'approche, ou jusqu'à portée de l'ancre pour les zones de mouillage, le balisage principal, par exemple devrait être suffisant. Et je pense qu'il n'y a pas besoin d'être informaticien pour discuter de savoir s'il faut faire des isobathes tous les mètres ou tous les dix mètres.

Par ailleurs, j'insiste sur l'enrichissement permanent par les utilisateurs. J'ai fait pas mal de camping car, à l'époque héroïque où des engins non toujours identifiables étaient bricolés par leurs propriétaires pour servir de villégiature roulante. Et savez vous sur quoi arrivait invariablement la discussion entre adeptes, une fois les présentations des hommes et des machines faites : sur les cartes. Chacun sortait la sienne (sa carte, botpipel), et on échangeait sur les bons coins, reportant force annotations... Après quelques rencontres, la carte toute crayonnée, on savait par exemple, en arrivant dans tel bled, qu'il y avait un robinet derrière une porte en bois sans cadenas dans la guérite à matos du fossoyeur au cimetière, et ainsi on avait le plein à portée de jerrycan.

Inconvénient évidemment, au bout de quelque temps, les autochtones se posent la question de savoir ce que toutes ces fourgonettes vont faire garées devant leur cimetière, il y aura des malins pour comprendre et mettre un cadenas sur la porte. Et il faudra trouver une autre source miraculeuse. Donc la gomme est un instrument aussi important que le crayon pour travailler sur une carte.

Personnellement, je verrais bien quelque chose comme ça pour HEOX. Enfin, je lance le bouchon, et on va voir jusqu'où il va flotter...

quoi qu'on fasse
on butte toujours sur le problème du contenu .
Quelle que soit la source, il est appartient toujours à quelqu'un . Que tu le scannes ou que tu ramasse un CD dans une poubelle .

Or sans un fond cartographique sérieux, il n'y a pas de programme de navigation utile .

Exemple d'un truc dont j'ai souvent eu envie :
La partie terrestre des cartes marines est lamentable .
La partie marine des cartes terrestres (IGN 1/25000) est meilleure que la partie terrestre des cartes marines mais pas assez fiable pour naviguer .
En dépit des liens organiques qui devraient exister entre le SHOM et l'IGN, cela ne change pas .
J'ai souvent eu envie de marier les deux . Je peut le faire tout seul dans mon coin sans grand risque . On sait décoder les fichiers BSB . On sait décoder les fichiers BYO . Passer d'une projection conique (Lambert) à une projection cylindrique (Mercator) n'est pas très compliqué .

Le faire collectivement ou publiquement !
Il s'avère que pour les cartes françaises, qu'elles soient SHOM ou IGN, un éditeur contrôle le jeux et n'hésite pas à employer les grands moyens pour protéger ses "oeuvres" en interdisant même de publier la façon dont elles sont codées (cf E. Sibert). Ce qui veut dire qu'il est risqué d'intervenir sur des fonds cartographiques protégés même pour en enrichir le contenu .

Et il y a peu de chances que cela change !

Bien d'accord Alien
Il ne faut pas oublier que les cartes marines sont d'abord faites pour la navigation professionnelle et que seul leur format est accessoirement adapté à la plaisance.

Où sont passées les cartes anciennes, celles avec les hachures qui figuraient les reliefs et permettaient d'appréhender de loin le profil de la côte ? les cartes US présentent les courbes de niveau, mais sont en noir et blanc sous cette forme.

De toute façon attendu que l'électronique de positionnement prendra de plus en plus le pas sur la nav traditionnelle, ce sont ces procédés qui seront privilégiés par les éditeurs qui paieront le prix aux sources officielles pour avoir les fonds de cartes précis et mis à jour par les mêmes moyens Ces sources ne sont pas près d'être gratuites, le shom et les autres ne vont pas scier la branche sur laquelle ils sont assis.