Revision as of 01:11, 2 March 2009

Structuration d'OpenFlyers

OpenFlyers correspond à deux choses :

• la société OpenFlyers
• le logiciel OpenFlyers

Outils de développement

Wiki

L'édition de la plupart des pages wiki est libre. Il suffit simplement de s'être identifié avant de pouvoir poster. Pour cela il faut demander un accès (en précisant idenfiant et mot de passe souhaité) à devteam at openflyers.org

Néanmoins, cette liberté totale ne peut "s'épanouir" qu'avec quelques règles permettant à tout un chacun de suivre le plus facilement possible les évolutions des pages du wiki.

Voici donc quelques propositions de règles à respecter :

• N'hésitez-pas à éditer les pages pour corriger les fautes d'orthographe.
• Si vous souhaitez améliorer la mise en page, faites attention de bien vérifier au préalable que toute modification sur les titres ne va pas causer de liens morts.
• Si vous souhaitez rajouter une remarque sur une spec déjà rédigée, utilisez de préférence l'onglet "discussion" rattaché à la page.
• Lorsque vous soulevez plusieurs points, utilisez :
  • soit des * pour créer des puces comme ici (<-là, juste à gauche<-)
  • soit des titres différents à l'aide des == si vous considérez que cela méritera des réponses séparées pour chaque thème soulevé.
• N'oubliez-pas de signer à la fin de votre paragraphe en utilisant l'icône prévue à cet effet (avant dernière icône en partant de la droite au-dessus du formulaire d'édition).

Pour suivre les modifications du wiki, c'est ici : modifs

Listes de diffusion

• opendev at openflyers.org (pour l'ensemble des participants au projet openflyers)
• beta at openflyers.org (pour les béta-testeurs)
• coding at openflyers.org (pour les programmeurs)
• of-commit at openflyers.org (pour le suivi des mises à jour du SVN)

Si vous souhaitez intégrer l'équipe de développement et être abonné à une des listes, il faut en faire la demande auprès du responsable de l'équipe : devteam at openflyers.org

SVN (subversion)

Organisation du développement

Nous essayons de structurer le développement afin d'être plus efficace et de ne pas perdre des choses en route. Le schéma présenté ci-après correspond plus à un idéal qu'une réalité ;-)

Spécifications

Il existe trois niveaux de spécifications :

• Les idées générales (cahier de résa, gestion des comptes, mécanique, etc.).

Les idées générales sont présentées synthétiquement sur la roue OpenFlyers. Elles regroupent les axes de développement validés depuis la création d'OF. Les priorités de spécifications sur tel ou tel axe sont définies par l'ensemble de l'équipe. À l'heure actuelle, le cahier est fait, la gestion des adhérents est également terminée et nous spécifions sur la saisie des vols et la gestion des comptes pilotes.

• La composition générale de chaque axe est décrite au travers de notions (types d'avion, profils, etc.).

La détermination des notions est, en général, laissée plutôt à l'appréciation de l'équipe de programmation. Car c'est elle qui va par la suite implémenter ces notions et qui peut mesurer la difficulté de tel ou tel aspect. De plus, les utilisateurs finaux ne sont pas forcément les mieux placés pour appréhender les différentes utilisations possibles. Ils cherchent en général une solution qui correspond uniquement à leur besoin.

• Les fonctionnalités.

Elles sont déterminées par l'ensemble de l'équipe de développement.

Le wiki constitue le support pour décrire les fonctionnalités et les notions.

A côté de ces spécifications "fonctionnelles", il existe des spécifications de programmation. Elles sont du ressort de l'équipe de programmation. L'axe suivi est : respect des standards et modularité.

Implémentation des spécifications

L'implémentation est effectuée par l'équipe de programmation dans les languages PHP, JavaScript, XHTML, XML, XSLT et avec comme support de base de données MySQL.

Le choix des fonctionnalités à implémenter est décidé de deux manières :

• S'il s'agit du coeur d'une idée, elle est implémentée dans le cadre de l'idée.
• S'il s'agit d'une fonctionnalité annexe, cette dernière est votée lors de réunions de l'association avec l'équipe de programmation.

Certaines fonctionnalités qui ne nécessitent qu'un très faible investissement en temps peuvent être laissées à l'appréciation de tel ou tel programmeur à partir du moment où elles s'insèrent dans le cadre voulu et qu'elles ne dénaturent pas l'application.

Afin de faciliter l'implémentation de fonctionnalités annexes, la version 2 d'OF utilisera un système de listage en xml regroupant les options activables par un club.

Votes

Afin de répondre mieux aux attentes des clubs et des utilisateurs, nous envisageons de mettre en place un système de vote. La recherche d'un tel outil fait parti des tâches en suspens (s'il y a un volontaire...). Succinctement, voici des éléments qui pourraient composer le cahier des charges d'un tel outil :

• authentification des votants et attribution du droit à voter (but : éviter qu'une même personne ne vote deux fois).
• Pondération des votes (but: donner plus de poids aux développeurs, programmeurs, clubs hébergés par l'association).
• système de gestion des spécifications futures avec :
  • possibilité de vote
  • ajout par tout un chacun de nouvelles specs
  • classement thématique des specs