Bien débuter son développement pour ArcGIS : Partie 1 - Professionnaliser sa gestion de projet

mer 06-04-2011 Nicolas Py

ESRI

De par leurs formations initiales souvent de haut niveau, les géomaticiens sont généralement au fait des techniques de gestion de projet mais ne possèdent que rarement des bases solides en informatique et plus précisément en génie logiciel.

Hors, le métier a beaucoup évolué : on assiste chez ESRI à une complexification et à une multiplication des langages et plates-formes capables d’intéragir avec ArcGIS tandis que plus généralement les logiciels open-source se démocratisent, les volumes de données et les attentes de fonctionnalités augmentent. Ces évolutions font que le géomaticien se voit dans l’obligation d’élargir son champ de compétences dans la direction de celui du développeur, ne serait-ce que pour automatiser ses traitements.

Dans cette présentation, l’objectif sera donc d’effleurer les concepts, méthodes et outils spécifiques à l’industrie logicielle afin de permettre à minima au géomaticien de dialoguer avec un développeur, et au mieux d’intégrer ces outils dans sa pratique quotidienne.

Copyrights
http://creativecommons.org/licenses/by-nc-nd/2.0/fr/

Contexte

Dans cette première partie, je vais tenter d’expliciter les raisons qui amènent à constater un déficit de connaissances du génie logiciel de la part des géomaticiens. Ses processus, méthodes et outils pourraient cependant s’avérer utiles, voire indispensables.

Le Géomaticien, de + en + informaticien

La démarche métier, initiée par l’association GeoRezo (1), offre un aperçu du métier de géomaticien. Les différents sondages, études et analyses montrent principalement:

Une très large représentation des formations « Géographie –Environnement», en augmentation entre 2003 et 2005,
Une grande spécialisation et une haute technicité du métier: en 2005, comme en 2003, plus de 65% de la population ciblée a un diplôme bac+5,
Le caractère pluri-disciplinaire du métier,
Une demande croissante de compétences en développement.

De ce constat, il n’est pas exagéré d’attribuer à la majorité des géomaticiens un déficit de compétences et de connaissances dans les processus et méthodes employés dans l’industrie informatique et plus particulièrement dans celle du développement logiciel. Les géomaticiens possèdent cependant sûrement la capacité de combler ce déficit.

ESRI et le développement à façon

Les logiciels ESRI permettent depuis longtemps déjà une personnalisation de l’outil, comme par exemple la possibilité d’enchaîner les traitements (scripts), de créer ses propres menus, fonctionnalités, … adaptés aux exigences métier de l’utilisateur.

Cette personnalisation a été rendue possible dès 1986 pour ArcInfo Workstation dans sa version 4 avec l’apparition du langage AML (2). Pour ArcView, il a fallu attendre la version 3 en 1996 et la naissance du langage Avenue (3). Pour la gamme ArcGIS enfin, l’apparition des ArcObject (4) s’est faite en 1999 avec la version 8.

FIGURE 1: EVOLUTION DES SOLUTIONS ESRI (SOURCE: HTTP://WWW.WIKI.GIS.COM/WIKI/INDEX.PHP/FILE:SDS10FIG2.1_SWEVOLUTION.JPG )

Depuis cette date, avec une accélération lors des ces toutes dernières années, on assiste à deux phénomènes concomitants:

Un rapprochement vers les langages standards:
- D’une part, l’abandon progressif des plates formes ArcView et ArcInfo (respectivements de statuts ‘Mature support’ depuis 2002 et ‘General availability’ depuis 2008), avec comme corollaire le désintérêt des géomaticiens pour leurs langages,
- D’autre part, la fin du support du VBA (5) dans ArcGIS après la version 9.4/10, que l’on peut mettre en relation avec l’apparition dans cette même version des add-ins (6), permettant l’ajout de fonctionnalités codées en langage .Net.
Une diversification des langages capables d’intéragir avec ArcGIS:
- Le Python (7), apparu en version 9 en 2004, permettant également la naissance du model builder (8),
- Le support du média internet, via ArcIMS en 2002 et ArcGIS Server en Web ADF en 2006,
- Les APIs riches pour ArcGIS Server en 2008,
- Le supports des smartphones (9) en 2009/2010.

Ainsi, la personnalisation du logiciel glisse d’un modèle propriétaire robuste, documenté et facile d’emploi vers des langages plus génériques, induisant ainsi un besoin accru de compétences générales en développement informatique.

Plus généralement en géomatique

Plus généralement, on assiste également à une démocratisation des logiciels à fonctionnalités géographiques, open source ou non, tant professionnels que ‘récréatifs’ (cf. (10), cartographie collaborative, …).

Cette démocratisation s’accompagne d’une augmentation des fonctionnalités des logiciels SIG open-source (11), (12) ainsi que d’une élévation des attentes d’un SIG, passant pour simplifier du stockage d’une représentation du réel à un outil de modélisation (cf. (13) , vision geodesign ESRI (14))

De part ma veille technologique sur les forums géomatiques francophones, j’ai également noté une tendance à l’augmentation du volume et de la qualité/précision des données traitées ainsi qu’à la multiplication des logiciels employés. Parallèlement, on assiste à une augmentation des demandes d’automatisation des tâches et traitements.

Il est donc raisonnable d’imaginer un accroissement des scripts et bouts de code présents sur les machines des géomaticiens, dont la gestion en raison de leur nombre ou de la multiplication de leurs versions peut devenir délicate.

Objectif de la présentation

Nous pouvons maintenant tirer l’objectif de cette présentation.

La gestion de projet (au sens large) est déjà largement enseignée dans les formations dont sont issus les géomaticens (à majorité de cursus supérieur ou égal à bac+3), avec par exemple les concepts de maitrise d’ouvrage ou d’œuvre, les diagrammes de Gantt, les méthodes d’affectations de ressources…

La gestion d’un projet informatique fait appel à des méthodes, processus et outils plus spécifiques dont la connaissance peut s’avérer utile voire indispensable au géomaticien, c’est donc ces spécificités que je vais tenter d’expliciter.

Au final, nous couvrirons donc le champ sémantique utilisé en développement par un aperçu des méthodes, concepts et outils employés dans les projets informatiques afin au minimum d’en acquérir le vocabulaire et l’idée générale.

Le génie logiciel

Dans cette partie, il s’agit de :

Définir simplement le génie logiciel,
Dégager d’un point de vue chronologique les phases qui le composent,
Découvrir ses bénéfices.

Définition

Encore relativement peu formellement explicité sur le web et à périmètres et définitions variables, le génie logiciel peut être compris comme « l'ensemble des méthodes, des techniques et outils concourant à la production d'un logiciel, au-delà de la seule activité de programmation. ». Une définition un peu plus longue peut être lue à http://fr.wikipedia.org/wiki/G%C3%A9nie_logiciel .

FIGURE 2: LES TERMES DU GENIE LOGICIEL... (SOURCE: HTTP://GEEKANDPOKE.TYPEPAD.COM/GEEKANDPOKE/2010/02/THIS-TIME.HTML )

L’illustration ci-dessus a été choisie afin de présenter une dualité forte et quasi constamment présente dans l’industrie du logiciel, à savoir le surcroit de travail qu’impose la formalisation des processus comparé aux gains apportés par cette formalisation. Il manque encore en effet au génie logiciel une explicitation des seuils à partir desquels les méthodes ou outils doivent être employés. C’est par contre à ce niveau que s’inscrit l’expérience du chef de projet…

Composantes

On peut de manière générale distinguer trois phases principales et communes à toutes les méthodes du génie logiciel, sous-ensemble de la gestion de projet (15) :

La phase d’analyse, dans laquelle les besoins sont explicités, les technologies utilisables envisagées et comparées, l’architecture générale du logiciel définie.
La phase de programmation, le cœur du développement.
La phase de livraison, où l’on vérifie que le logiciel fonctionne ailleurs que sur l’ordinateur du développeur (et donc de préférence sur celui de l’utilisateur), où le client valide que ce qui a été développé correspond à ses attentes…

Pourquoi en parler ici ?

Le génie logiciel, enseigné dans les parcours informatiques, n’est que peu décrit dans les ouvrages génériques traitant de programmation. Or, les méthodes et techniques du génie logiciel évitent l’anarchie ou l’auto-gestion en permettant, pour simplifier, l’emploi d’un cadre commun de dialogue et de partage de l’information sur le projet. Elles permettent notamment de :

Garder une trace des:
- Besoins
- Problèmes rencontrés
- Réponses apportées
Faciliter:
- Maintenance des logiciels
- MàJ des logiciels
- Ré-emploi de morceaux de code
Travailler de façon approfondie
- Plusieurs développeurs
- Développement important (2-3 semaines ?)
Faire aboutir le projet
Augmenter la qualité du logiciel produit

La formalisation du développement qui en découle permet ainsi d’obtenir une assurance sur le niveau de qualité du logiciel produit.

Les risques d’un projet informatique

FIGURE 4: LES RISQUES D'UN PROJET INFORMATIQUE (SOURCE INCONNUE).

Cette illustration à vocation humoristique explicite cependant quasi parfaitement les écueils qu’un projet informatique peut rencontrer.

Phase d’analyse

Première des trois phases communes à toutes les méthodes du génie logiciel, la phase d’analyse permet de fixer les orientations du projet, les besoins exprimés par le client, les différentes alternatives permettant d’y répondre et indique les choix qui ont été faits. Ces choix permettent alors la définition de l’architecture qui va être employée.

Spécifications

Elles décrivent de manière formelle et exhaustive le produit informatique à réaliser (http://fr.wikipedia.org/wiki/Sp%C3%A9cification_%28informatique%29).

Conception

La phase de conception permet de décrire de manière non ambiguë, le plus souvent en utilisant un langage de modélisation (UML, Merise, …), le fonctionnement futur du système, afin d'en faciliter la réalisation.

FIGURE 5: LA DEMARCHE DE MODELISATION (D'APRES HTTP://LAURENT-AUDIBERT.DEVELOPPEZ.COM/COURS-UML/HTML/COURS-UML056.HTML).

Architecture

L'architecture informatique décrit la structuration d'un système informatique en termes de composants et d'organisation de ses fonctions (http://fr.wikipedia.org/wiki/Architecture_informatique).

Physique VS Logique
Par groupe de composants informatiques :
- conception logicielle
- conception matérielle
- concept Middleware
- conception réseau

En résumé

Un bête éditeur de texte peut suffire à réaliser la phase d’analyse, à accompagner éventuellement avec un logiciel capable de générer des diagrammes.

Phase de développement: Des méthodes

Au commencement était l’empirisme. Puis l’informaticien à créé la première méthode de développement, théorisant son expérience et les bonnes pratiques communément admises. Vint ensuite l’informatisation de plus en plus poussée de la société, générant un nombre toujours plus élevé de programmes informatiques… De ce foisonnement ont forcément découlés d’autres contextes de développement, incluant d’autres besoins de formalisation ou l’apparition de nouveaux problèmes… Au final, il n’existe plus une méthode unique de développement mais des familles, aux avantages et inconvénients bien différenciés.

Définition générale

D’après (16), une méthodes de développement est « Ensemble séquentiel de phases, dont le nom et le nombre sont déterminés en fonction des besoins du projet, permettant généralement le développement d’un service ou d’un produit ».

Méthode de dév en cascade

Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle.
Le processus de développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques (17) :

de produire des livrables définis au préalable ;
de se terminer à une date précise ;
de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de
validation-vérification.

FIGURE 6: LES ETAPES DE LA METHODE DE DEVELOPPEMENT EN CASCADE (D'APRES HTTP://WWW.LABOITEAPROG.COM/ARTICLE-MODELE_DE_CYCLE_DE_DEVELOPPEMENT-47-4).

Méthode de dév en V

Le principe de ce modèle, est que chaque étape de décomposition du système possède une phase de test. Chaque phase du projet à une phase de test qui lui est associée. Beaucoup de tests sont ainsi créés, ce qui implique une réflexion. On sait progressivement si on s'approche de ce que le client désire.

FIGURE 7: LES ETAPES DE LA METHODE DE DEV EN V (D'APRES HTTP://WWW.LABOITEAPROG.COM/ARTICLE-MODELE_DE_CYCLE_DE_DEVELOPPEMENT-47-4).

Méthode de dév en spirale

Un cycle est décomposé en étapes.

Analyse préliminaire pour le premier cycle; pour les autres cycles, on détermine les objectifs, contraintes à partir du résultat du cycle antérieur.
Analyse des risques, création de prototype
Développement et test
Planification du cycle suivant

Les prototypes créés à chaque cycle permettent de réduire les risques et de guider la conception pour obtenir un système qui répond au besoin du client. Chaque cycle de la spirale fait en sorte que le système soit de plus en plus complet.

FIGURE 8: LES ETAPES DE LA METHODE DE DEV EN SPIRALE (D'APRES HTTP://WWW.LABOITEAPROG.COM/ARTICLE-MODELE_DE_CYCLE_DE_DEVELOPPEMENT-47-4).

Les méthodes ‘agiles’

Elles :

S’inscrivent dans le modèle en spirale
Buzzword
RAD, XP, Scrum, Test Driven Dev., Intégration continue
Formées à la base en opposition au modèle classique du développement en cascade
Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling, noté AG) visent à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement (http://www.commentcamarche.net/contents/genie-logiciel/methodes-agiles.php3).

Méthode de dév à la Rache

D’après ses auteurs (http://www.cafenware.com/la-rache/), « RACHE: Rapid Application Conception and Heuristic Extreme-programming : méthodologie de génie logiciel qui va vachement bien à vos projets ! ».

FIGURE 9: LA METHODE DE DEV A LA RACHE.

Cette méthode, décrite de façon humoristique sur le site de ses inventeurs, permet de rappeler que l’empirisme n’est pas forcément à négliger…

Taxonomie des méthodologies

Une classification de ces méthodes à été proposée par C. Moustier :

FIGURE 10: TAXONOMIE DES METHODES DE DEVELOPPEMENT (SELON C. MOUSTIER (HTTP://FR.WIKIPEDIA.ORG/WIKI/FICHIER:TAXONOMIEM%C3%A9THODOLOGIES.PNG ).

En résumé

Pour la majorité des géomaticiens, dans le cas de

Petites structures
Petits projets
Faible nombre de personnes réellement impliquées

la méthode de développement à la Rache peut éventuellement suffire…

La formalisation entraîne pourtant l’adoption de bonnes pratiques et rend la gestion du projet plus confortable.

Elle s’avère cependant indispensable dans les autres cas pour assurer un produit de qualité et évolutif…

Phase de développement: Des outils

Les outils du génie logiciel permettent un partage efficace et sécurisé des tâches et de l’information nécessaires au développement d’un logiciel. Les principaux vont être succinctement décrits dans cette partie.

Gestion des tâches, quoi ?

C’est un ensemble de fonctionnalités permettant de:

Segmenter un projet en tâches élémentaires
Les attribuer (ressources)
Ne pas en oublier (bloc note!)
Avoir un rapport de leur avancement
Y adjoindre des documents
Accumuler des retours d’expérience (temps passé, problèmes rencontrés, …)
répartir et segmenter le travail en gardant une maîtrise et une vue d’ensemble

On la retrouve dans les logiciels classiques en gestion de projet (MS Project) ou dans ceux intégrés avec d’autres outils de génie logiciel (Jira, Trac).

FIGURE 11: EXEMPLE DE TACHE JIRA (SOURCE : HTTP://WWW.OCEANOBSERVATORIES.ORG/SPACES/DOWNLOAD/ATTACHMENTS/20087430/J... ).

Gestion des tâches, quand ?

Comme annoncé en introduction, le coût de mise en place de mécanismes pour un projet ne doit pas être supérieur aux bénéfices (souvent difficiles à estimer objectivement) apportés par cette mise en place. Pour faire simple, la gestion des tâches doit être employée dès le moment où le niveau de complexité dépasse ce que peut appréhender un développeur seul. Autrement dit, dès que le travail à effectuer s’étale trop dans le temps et/ou qu’il y a collaboration.

Gestion de versions, quoi ?

Elle permet de gérer les différentes versions du code écrit ainsi que de :

Retrouver une modification du code, son auteur, les commentaires qu’il y a associés,
Gérer des versions du logiciel, ses évolutions…

A employer dès le début d’un projet, même petit, même avec un seul développeur les coûts étant très largement inférieurs aux bénéfices !

La gestion de version est développée dans SIG2010_Bien débuter son développement pour ArcGIS, partie 2, Professionnaliser son code.

Gestion de bug, quoi ?

Il s’agit (18) de

Centraliser les problèmes/bugs rencontrés
- Description
- Fonctionnalité touchée
- Comment reproduire le dysfonctionnement
- Capture d’écran
- Message d’erreur
- …
Mais aussi les améliorations demandées
Avec une hiérarchie (bloquant, mineur, …)
Ainsi que la réponse apportée (révision si gestion de version).

FIGURE 12: EXEMPLE DE BUG ENREGISTRE DANS JIRA (SOURCE : HTTP://JIRA.ATLASSIAN.COM/SECURE/ATTACHMENT/11605/JIRABUG2.JPG).

Gestion de bugs, quand ?

Là encore, de façon logique :

Quand le nombre d’utilisateurs est élevé
Quand les utilisateurs sont extérieurs à l’entreprise
Quand les utilisateurs sont peu ou pas à même de décrire le bug par téléphone…

En résumé, quand la communication entre le développeur et l’utilisateur est compliquée.

Tests unitaires, quoi ?

Il s’agit de :

Ecrire du code pour vérifier du code
S’assurer du fonctionnement d’une partie du logiciel
Répétable
Vérifient l’impact d’une modification du code sur le reste du logiciel
Et donc vérifier la non-régression
Détecter les bugs plus tôt
Argument qualité
Aide au suivi de l’avancement

Une description plus complète sera trouvé dans SIG2010_Bien débuter son développement pour ArcGIS, partie 2, Professionnaliser son code.

La forge

Les différents outils présentés précédemment permettent d’introduire le concept de forge, ensemble logiciel qui rassemble dans un même environnement les différents gestionnaires (des tâches, de versions, de bugs, …). Outre leur rassemblement, la forge propose également un interfaçage de ces logiciels. Ainsi, un bug, une fonctionnalité, sera lié à une version (pour son existence, mais également sa résolution) ainsi qu’à une fonction/tâche et pourra être affecté à un développeur…

Intégration, quoi ?

Compilation de l’ensemble du projet :

Vérifie que le résultat des modifications du code source ne nuit pas au reste du logiciel.
Peut être continue, via le lancement automatisé (quotidien, à chaque commit, …) des tests unitaires.
Cf. :
- http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue
- http://www.martinfowler.com/articles/continuousIntegration.html
- http://hudson-ci.org/
- http://netbuildconfigurator.codeplex.com/

Intégration, quand ?

Projet complexe
Existence
- De gestionnaire de version
- De tests unitaires
Plusieurs développeurs travaillant concomitamment

Tests holistiques

I.e. grandeur réelle, en situation d’utilisation
Vérifier que tout fonctionne correctement ensemble (// tests unitaires, spécifiques à un «module»):
Installation
Configurations de machines différentes
Utilisation réelle
Données réelles (en carto, peuvent êtres plus complexes, volumineuses, …)
Aux environs de la beta (beta-testeur !)

Chez ESRI: http://blogs.esri.com/Dev/blogs/holistictesting/archive/2010/04/09/Holis...

En résumé

La professionnalisation de la phase de développement d’un logiciel fait appel à des outils spécifiques.

Leur installation ainsi que leur utilisation peuvent s’avérer complexes et engendrer un surcroit de travail mais apporter du confort et des gains dans la qualité du logiciel produit voire dans la productivité du développeur.

La principale difficulté pour le géomaticien consiste alors à définir le seuil à partir duquel les gains seront supérieurs aux coûts ainsi que le ROI des outils, plus que variable (gestion de source $ VS intégration continue $$$$$ par ex)

Phase de livraison

Cette phase s’effectue une fois l’écriture du code terminé. De manière simple, il s’agit de tout rassembler pour préparer le transfert du logiciel terminé vers les utilisateurs.

Packaging / déploiement, quoi ?

Packaging :

Compilation du code
Mise en relation de l’ensemble des composants: logiciels, modules, documentation…
Script packaging

Déploiement :

Installer le logiciel chez le client
Aide à la prise en main
Script de déploiement
DS2010: DEV54_Deploying Desktop and Engine Applications in .NET.pdf (19)

Packaging / déploiement, Cas particulier.

Le code, pour plus de facilité de compréhension, partage des tâches, … a pu être séparé en de multiples dll.

Ces dernières, lors du déploiement, peuvent être incluses dans le programme principal…

Cf. par exemple :

« Embed an assembly as a resource, exemplified with Log4Net » http://www.codeproject.com/KB/DLL/EmbedAssemblyAsResource.aspx
Et plus simplement ILMerge,
- http://www.codeproject.com/KB/dotnet/mergingassemblies.aspx
- http://www.microsoft.com/Downloads/details.aspx?familyid=22914587-B4AD-4EAE-87CF-B14AE6A939B0&displaylang=en
- http://ilmerge-gui.devv.com/Download.aspx

Réception

Faire constater au client

Que l’ensemble des livrables (exécutables, manuels, …) a été livré
Que les fonctionnalités demandées ont été implémentées
Et qu’en l’état actuel (sans garantir l’absence totale de bugs!), le logiciel est utilisable en production

Passage des cahiers de tests (document présentant des cas d’utilisation, i.e. les manipulations utilisateurs, avec les résultats attendus)

Conclusion

Chez ESRI

A ma connaissance, ESRI a pour la première fois cette année communiqué sur les processus et méthodes de développement utilisés…

Les présentations sont disponibles à l’URL :
http://proceedings.esri.com/library/userconf/devsummit10/tech/tech_23.ht...
et la vidéo à l’URL :
http://gisupdates.esri.com/video/devsummit2010/DEV75.wmv

Conclusion

Les méthodes et outils présentés permettent notamment, dès lors qu’ils ont été mis en place avec succès, d’obtenir une assurance sur la qualité du logiciel produit tout en facilitant son élaboration.

Pour la première fois, ESRI Inc communique sur ces/ses (!) méthodes de développement, preuve de la prise de conscience de l’importance que peut revêtir l’assurance qualité logicielle dans un marché des SIG mouvant, concurrencé par l’Open Source.

Connaître ces pratiques, voire les adopter, permettra aux géomaticiens développeurs de mieux interfacer leurs travaux avec le noyau ArcGIS tout en améliorant la gestion de leurs projets, facteur non négligeable dans le contexte économique actuel…

Merci à :
Le Doc, Lud, Warg, David, ClaireLk, Christelle, Benoît, Et les autres
Pour leurs relectures et commentaires

(1) Cf. http://georezo.net/wiki/_media/main:formetiers:poster_metier_mathian_200...

(2) http://en.wikipedia.org/wiki/ArcInfo, http://en.wikipedia.org/wiki/ARC_Macro_Language, http://downloads2.esri.com/support/product%20life%20cycle/ao_/ArcInfoWor...

(3) http://support.esri.com/index.cfm?fa=knowledgebase.gisDictionary.search&..., http://downloads2.esri.com/support/product%20life%20cycle/other_/ArcView...

(4) http://en.wikipedia.org/wiki/ArcGIS, http://downloads2.esri.com/support/product%20life%20cycle/ao_/584ArcGIS_...

(5) http://blogs.esri.com/Dev/blogs/arcobjectsdevelopment/archive/2009/03/30...

(6) http://www.arcorama.fr/2010/03/developer-summit-2010-plenary-session_24...., http://proceedings.esri.com/library/userconf/devsummit10/papers/tech/int...

(7) http://www.esri.com/news/arcuser/0405/files/python.pdf

(8) http://support.esri.com/index.cfm?fa=knowledgebase.gisDictionary.search&...

(9) http://blogs.esri.com/Dev/blogs/arcobjectsdevelopment/archive/2010/02/19..., http://geo.geek.nz/esri/run-arcgis-server-maps-on-your-blackberry-for-free/

(10) http://brehat.ec-nantes.fr/ogrs2009/download/Keynotes/From%20a%20niche%2...

(11) http://www.innovativegis.com/basis/MapAnalysis/Topic27/Topic27.htm

(12) http://www.esri.com/news/arcwatch/0210/feature.html

(13) http://brehat.ec-nantes.fr/ogrs2009/download/Keynotes/Free%20and%20Open%...

(14) An Overview on Current Free and Open Source Desktop GIS Developments. International Journal of Geographical Information Science, Volume 23, Issue 10 October 2009 , pages 1345 – 1370

(15) http://fr.wikipedia.org/w/index.php?title=Gestion_de_projets&redirect=no

(16) http://glmd.110mb.com/filessem2/Cycle%20de%20vie%20du%20logiciel%20et%20...

(17) http://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement

(18) http://fr.wikipedia.org/wiki/Logiciel_de_suivi_de_probl%C3%A8mes

(19) http://proceedings.esri.com/library/userconf/devsummit10/tech/tech_19.html