Un logiciel « libre » au développement sous contrôle! Une charte de développement langage, environnement, architecture outils de développement collaboratifs.

Présentation au sujet: "Un logiciel « libre » au développement sous contrôle! Une charte de développement langage, environnement, architecture outils de développement collaboratifs."— Transcription de la présentation:

1 Un logiciel « libre » au développement sous contrôle! Une charte de développement langage, environnement, architecture outils de développement collaboratifs SGBD cibles Une charte graphique (GUI) Partage des travaux forums utilisateurs/développeurs Gestion des versions Gestion des Frameworks Gestion de la documentation

2 Le cœur : le référentiel base de données Gestion des versions des dictionnaires de données Gestion des demandes d évolution ou modification Gestion des effets de bords sur les applications clientes.

3 le référentiel base de données Un serveur BD de développement unique –Tout le monde peut disposer de la dernière version en cours de développement Un serveur BDs de test possible pour chaque établissement: –2 Bases possibles une base de test = version de développement à un instant t une base de test réplication de la base d exploitation à un instant t

4 le référentiel base de données Aujourd hui: –Un modérateur garant de son évolution, de sa cohérence, de son renseignement et de sa diffusion procédure de demande de travaux Demain: –Un outil de développement collaboratif de gestion et de synchronisation des bases de données au sens « users Orcale »

5 Langages, outils, environnement Lapplication de base et ses modules sont développés avec loutil WebObjects disponible sur plate-forme Wintel ou Mac OS X Le langage pour tout nouveau module est JAVA. La modélisation base de données est faite avec EOF (inclus avec WebObject) Larchitecture pour tout nouveau module est une architecture n-tiers

6 SGBD cibles Par défaut il sagit dOracle Toute autre source de données est possible pour autant qu il existe un « adaptor » ou un driver ODBC ou JDBC en version 5.0 Modéliser avec EOF crée un niveau dabstraction indépendant des SGBD et permet de mixer plusieurs sources de données distinctes dans un même modèle –Attention ce nest pas forcément simple!

7 Gestion des demandes de travaux maintenance corrective et évolutive Toute demande est enregistrée suivant un modèle prédéfini Chaque demande fait lobjet: –dun traitement indiquant: la durée laction réalisée –dune information auprès des utilisateurs et des développeurs Les demandes sont traitées par les développeurs responsables (chefs de projets, de modules ou dObjets

8 Forums et liste de discussions Un forum utilisateur associé à une liste de diffusion est créé. –Les modifications consécutives à une maintenance évolutive apparaissent dans ce forum Un forum développeur associé à une liste est créé.

9 Ressources en ligne Une charte graphique devra être élaborée Les ressources graphiques seront en ligne suivant un dépôt de type CVS La méthodologie objet employée devrait permettre la réalisation dobjet métier, de palettes, de bundles qui seront disponibles sous forme de « Frameworks » ré-utilisables ou partageables Univers BO et requêtes Business Query

10 Les programmes sources: côté client Disponible sur un serveur CVS à l aide d un client CVS disponible sous Windows ou sur Mac. Tout module ayant vocation à sappuyer sur lapplication est déposé dans cette base (« Repository ») Chaque développeur ou établissement peut en disposer pour lenrichir, le corriger ou le tester.

11 « Reporting » et Infocentre Business Object WebIntelligence Business query Univers en ligne

12 La documentation 2 types de documentations: –Technique –Utilisateur La documentation technique recouvre plusieurs sous-types et engage chaque développeur. Elle nécessite une méthodologie commune et des outils idoines. La documentation utilisateur est intégrée au projet ou sous-projet. Son squelette est réalisé par le développeur mais sa version définitive est lobjet dun non informaticien. Elle est disponible en ligne.

13 Procédure de validation Développement et test –niveau développeur/chef de projet/utilisateur Phase Bêta: –niveau chef de projet/utilisateur choisi et volontaire Mise en exploitation –niveau utilisateur

14 Principes de mutualisation lapplication nest pas un produit commercial ; elle ne peut-être ni achetée ni vendue, ni cédée à des tiers nadhérant pas aux termes de la présente charte.. développée par lUniversité de la Rochelle, celle ci consent à la mettre à disposition gratuitement à dautres universités qui demanderaient à en disposer, sous les conditions prévues aux articles suivants. la mise à disposition doit être sollicitée auprès de luniversité de La Rochelle ; elle donne lieu à établissement d'une convention. la mise à disposition de lapplication implique pour létablissement demandeur son engagement écrit à respecter les clauses de la présente charte.

15 Principes de mutualisation les établissements qui décident dopter pour lapplication sengagent dans une démarche de mutualisation : -mutualisation des développements, -mutualisation de la documentation, -mutualisation de la maintenance.

16 Principes de mutualisation Il n y a pas obligation pour un établissement désireux dexploiter l application dêtre, pour les opérations ci-dessus, un membre actif si ce dernier ne dispose pas des moyens nécessaires. Cependant, luniversité demandeuse doit sengager, en contrepartie, à participer aux financements des coûts induits que pourraient engendrer l accès à l application (accompagnement, formation, implantation, suivi et maintenance, assistance, hot line, …) Ces coûts, éventuels, sont estimés par lensemble des partenaires sur la base du prix de revient de la prestation. En cela les pratiques de certains service de formation continues ou des futurs (?) SAIC pourront constituer une base de réflexion.

17 Principes de mutualisation les universités ayant opté pour lapplication et adhéré aux principes de la présente charte se réunissent dans un comité dapplication (dont la composition sera précisée mais associera politiques, experts fonctionnels et informaticiens): -de donner un avis sur toute nouvelle adhésion, -dorganiser et gérer les coopérations des différentes universités, -de faire le point régulièrement sur les développements nécessaires (ici il sera nécessaire d y ajouter les utilisateurs) lUniversité de la Rochelle se réserve la propriété de lapplication et demeure la garante de sa cohérence.

18 Participation « active » Rappel: lusage du logiciel est gratuit. –1)Participation financière lorsque létablissement utilisateur souhaite une assistance ou des aménagements spécifiques sans pour autant disposer des moyens nécessaires en local –2)Prise en charge de modules (ou objet métier!) comme la Paie par exemple par un établissement adhérant à la charte. Lintégration au système existant serait assurée par La Rochelle

19 Relations avec les autres applications Compatibilité Harpège à 100% prévue rentrée 2001 (en cours de réalisation par La Rochelle) Compatibilité Apogée à 100% prévue rentrée 2002

20 Vers un Logiciel de Gestion Intégrée La compatibilité avec les applications HARPEGE et APOGEE assurera à la communauté la disponibilité de lensemble des applications développées dans le cadre de cette charte. Cet ensemble constituant un système d information intégré modulaire.