Plateforme intégrée et concise pour supporter les activités de gestion de
projets et plus généralement «systèmes
complexes», liées ou non à logiciel. L'environnement est destiné à une utilisation par le
public le plus large possible : enseignants, étudiants, ingénieurs
logiciels, architectes, développeurs, dans le cadre de travail collectif mais aussi industriel et personnel.
La prinicipale caractéristique des ces activités est la complexité. Maîtriser la complexité est le
maître mot de ce projet, il cherche donc avant tout à rester simple, concis et ergonomique,
pour aider à la gestion de grands projets individuels ou collectifs, impliquant un nombre apriori
illimité d'acteurs, mais il doit aussi être utilisable pour des tâches beaucoup plus simplesc telles
que les activités de tous les jours comme l'organisation d'un voyage ou d'un départ en
vacances par exemple.
Dans le cas particulier de l'enseignement JuX est actuellement utilisé pour préparer des cours
et des projets d'étudiants. Les ressources internes développées sont spécialisées en Génie Logiciel et
en Interaction Homme-Machine, mais d'un côté la conception est générale et n'est pas
spécifique à un domaine donné. De l'autre côté l'evironnement préconise et oraganise
l'utilisation de l'existant (sans duplication), tout particulièrement les ressources
internet (cours, présentations, articles, sites, portails, etc.), ce qui devient
possible, mais largement sous-exploité, grâce au haut débit, à la fiabilité croissante et à la nature de
plus en plus persistante (moins de liens rompus) et bien organisée des publications, qui sont de plus évolutives.
Motivation : maîriser la complexité.
Approche : Le projet s'appuie priniciaplement sur deux concepts : celui
de la complexité (cf. E. Morin) et celui de qualité appliquée aux artefacts de l'activité
(projet, documentation, support de formation, etc.) mais aussi à
l'environnement lui-même.
Solution proposée :
Approche projet, oragnisation et gestion centralisées, concises et ergonomiques.
Cela veut dire avant tout « ne pas
réinventer la roue », mais utiliser les systèmes et les ressources existantes
sans modification, sans duplication, mais en les intégrant dans la gestion
centralisée avec d'éventuels simples commentaires et structurations permettant d'avoir une
petite idée sur la pertinence du système ou de la ressource pour l'activité
en cours et d'automatiser son intégration. Dans le cadre l'ACAO, domaine
d'application futur, ces structurations seront exploités pour construire
des graphes de concepts (paysages) et des proposition de parcours (softlines) ponctués
par des activités pratiques et des exemples concrets permettant de fixer les idées.
JuXUP : MDA, Intégration avec les systèmes existants, en particulier les IDEs
en adoptant les standards tels que XMI. Étude de cas.
JuXUP est appliqué au développement de JuX, au développment des exemples et
des ressources et à la gestion du contenu, y compris la publication sur
Internet, à la préparation des cours, à la gestion des projet des projets
des étudiants.
RJuX :
Ressources Jux : artefacts de supports d'enseignement et
des projets JuX, éventuellement structurées sémantiquement (Concept, Notion, Thème (statique), Softline (Dynamique)),
sachant que JuX préconoise que tout document soit un
projet.
Ressources locales non « JuXifiées ».
Ressources Internet (profitant des récents progrès : haut débit, fiabilité du réseau et des
ressources) :
Pas de duplication, simple référence (lien hypertexte),
éventuellement commenté.
Extraction de méta-information (sémantique) du
contenu structuré au format source (p.e. Mot-clefs et titres dans une
publication scientifique au format Microsoft Word ou Power Point,
Open Office ou encore PDF).
Applications furutres : Base de connaissances IHM (cf. ???), TCAO (cf. ???) et ACAO.
Optimiser l'effort
Il existe des outils pour toutes les activités mentionnées ci-dessus, pourquoi alors développer un autre
outil? La réponse en deux mots est « de les mettre ensemble avec un effort
optimal ».
Exemple : Liens et Calendrier
Par exemple, en se limitant au cas simple de l'utilisation de deux outils existants
et même intégrés dans un même logiciel, les navigateurs proposent une
fonctionnalité de base, l'enregistrement et l'organisation des liens, et intègrent,
sous forme d'extension (plugin) un gestionnaire de calendrier. À première vue
il n'y a pas de lien direct entre ces deux outils, et le navigateur ne fournit
aucune facilité de communication entre eux, si ce n'est la possibilité d'associer
un URL (un seul) à un événement ou à une tâche dans le calendrier. Pourtant,
lorsqu'on considère des activités comme la préparation de cours ou le développement de logiciel
le lien devient évident : il serait pratique d'associer les ressources (référencées par les
liens) à l'activité. Même pour partir un voyage, un lien vers le site de
la SNCF et un autre vers le plan de la destination pourraient se révéler utiles.
C'est là que JuX intervient pour « boucher les trous », en utilisant
l'existants, les outils du navigateur, et en s'appuyant sur les standards et les usages
communs et répandus qui deviennent des standards de facto. Concrètement,
il propose une organisation des tâches telle que établie dans le milieu industriel :
une tâche consomme des « artefacts » en entrée et en produit d'autres en sortie.
Ainsi, les liens appartiennent à la première catégorie et les plans et supports de
cours ou les composantes du logiciel produit appartiennent à la deuxième catégorie.
Il est ensuite possible de raffiner la planification (propriété de la tâche, décomposition,
séquencement, etc.) et de visualiser le résultat sous différentes forme : page HTML,
tableau colorié ou réseau PERT http://fr.wikipedia.org/wiki/PERT.
Planification des Tâches
En poursuivant un peu plus cet exemple, d'autres outils, tel que les gestionnaires
d'emploi du temps ou les IDEs, proposent des fonctionnalités
plus évoluées, mais au lieu de simplifier (en fait aider à maîtriser la complexité,
car il n'est pas possible de simplifier un système complexe par sa nature), ils ne
font que rajouter d'autres éléments et donc augmenter la complexité.
Dans le cas des gestionnaires
d'emploi du temps il est possible par exemple d'exporter les tâches planifiées
à l'usage d'un gestionnaire de calendrier, mais d'abord cette fonctionnalité
n'est pas dynamique et on n'y peut rien si le système n'est pas ouvert. De
plus il pourrait exporter les activités sous forme d' événements et non pas
sous forme de tâche, qui serait plus souhaitable. À l'autre bout, le gestionnaire
de calendrier propose une visualisation graphique des événements, mais les tâches
ne sont représentées que sous forme de liste, pas très pratique. Dans l'opération
d'exportation/ importation on risque aussi de perdre des parties importantes de
l'inforamtion, telles que la catégorie ou le regroupement des séances de cours au sein d'une même
séquence. Ce qui oblige à une édition tâche par tâche dans le gestionnaire des
calendriers pour profiter de ses fonctionnalités telles que les alarme ou la
définition des propriétés.
Cas du Développement du Logiciel
Dans le cadre du développement du logiciel, les IDEs intègrent l'extraction
et la visualisation des tâches « à la hâte », notées habituellement en commentaire avec
une séquence clef, personnelle, telle que TODO, XXX ou ???. Il s'agit d'un usage
courant qui devient un stanard, mais là aussi l'outil propose une simple
visualisation et aucune fonctionnalité évoluée, il est même pas possible d'extraire
cette liste ou de la copier/coller dans un document de gestion de projet.
Solutions Proposées
JuX propose des solutions pour ce genre de situation en s'appuyant sur un format
intermédiaire bien structuré et flexible (en XML) : dans le premier cas il est possible d'exporter/modifier/importer
les formats standards des tâches d'un gestionnaire d'emploi de temps ou de calendrier.
Le même type de fonctionnalité est proposé dans le deuxième cas, avec en plus la possibilité
de conversion semi-automatique des tâches « à la hâte » en véritables tâches planifiées et intégrées
dans le projet.
Modélisation et Complexité
Un dernier exemple, encore dans un cadre plus complexe, celui du
du développement du logiciel : la modélisation, qui offre bien des avantages et s'avère même
indispensable, est de plus en plus utilisée, et a priori elle constitue une préciesue
aide pour maîtriser la complexité inhérente au logiciel. Mais le modèle, une autre collection d'artefacts
liés par des relations de dépendances peu évidentes,
est un autre facteur de complexité. Sans une bonne intégration de la gestion du projet et
du modèle la situation devient le plus souvent ingérable.
Origines et Concepts de JuX
JuX est né de l'expérience de la vie réelle en gestion de projet, en
développement et en enseignement. Ces activités portent sur et produisent un grand
nombre d'artefacts et de s'appuient souvent sur un travail d'équipe. Un système qui
comprend un gand nombre d' éléments (dans le
sens large du terme, y compris les personnes, les tâches, les artefacts, etc.)
est « complexe » ou « compliqué ». La différence selon le dictionnaire [Le Ptit Larousse
1982] est que le premier est « difficile à
analyser », tandis que le second est « impossible à appréhender ». Difficile n'est
pas impossible, et beaucoup d'ingénieurs et d'architectes informaticiens aiment
et raitent avec des systèmes complexes, parce que
il est de plus en plus possible de déléguer la partie difficile à
l'ordinateur. L'expercience, montre
qu'il est le plus souvent pratiquement impossible de faire aboutir un projet logiciel
réalisé par une équipe d'étudiants en aapliquant un procédé ou une méthode
de A à Z, en partant d'une description primaire, ou même des exigences précises,
jusqu'au
déploiment, y compris les phases de spécification, d'analyse,
de conception, d'implemntation et déploiment, et leurs détails, ainsi que les
activités annexes telles que la gestion du travail d'équipe et la documentation
utilisateur et technique.
Dans le secteur industriel la même situation se rencontre
fréquemment. Selon l'étude CHAOS, en 2004, seulement 29% des projets
logiciels étudiés ont réussi, 59% ont été « achevés », c'est à dire terminés avec
un système opérationnel, mais à des frais supplémentaires et/ou du retard et/ou
des fonctionnalités réduites. Le problème réside dans l'utilisation encore
très répandue de l'ancienne organisation selon « modèle en cascade » séquentiel,
fort probablement à cause de sa simplicité.
Round Trip Engineering
L'approche moderne repose sur itératif « Round Trip Engineering », qui est
habituellement utilisé par les chercheurs et a été appliquée à du domaine public
et de projets de logiciels libres et a prouvé son efficacité, produire des
logiciels de haute qualité, comme Emacs, et plus tard sous Linux.
Le tout est que cette approche est plus « complexe » et nécessite un niveau
supérieur à l'organisation. Donc, si on le met avec les facteurs de complexité
ci-dessus mentionnées et de prendre en considération le travail collaboratif
distant, nous avons un système très complexe. Il n'y a qu'une seule façon
d'éviter de tomber dans une situation compliquée: maîtriser la complexité. C'est
là que Jux espère être utile: il propose des concepts pour l'organisation sur la
base hiérarchique, la définition et itroducing éléments du système mondial
d'abord, afin d'avoir une idée générale et de savoir où nous allons, puis
progressivement les détails les différentes composantes en fonction de nos
progrès pour comprendre le système. Détails peut exiger plus de détails jusqu'à
atteindre unités elemntary, les choses que nous connaissons bien, comme les
unités de programmation ou des instructions.
Mise en OEuvre
Jux s'appuie sur des méthodes expérimentées et prouvées et des processus, des
normes, recommandations et pratiques approuvées répandue commune. Il utilise les
outils existants et des systèmes et des ressources (principalement des logiciels
de soutien et le concept général d'apprentissage). Ce qu'il fait est:
centraliser le tout avec concision "contrôlable" descriptions, qui, à la
connaissance designer, aucun autre outil ne, synthizes ressources de formation
disponibles (normes, des tutoriels, des FAQ, des logiciels libres, etc) selon
ponctuelles besoins et introduit des éléments et reources où manque l'on trouve,
par exemple complet encore raisonnablement petites études de cas, les
définitions telles que le workflow de gestion JuXUP, qui ne figure pas
habituellement dans d'autres procédés, et «les cas d'utilisation technique»,
comme le jeu du système dans la modélisation, ce qui n'est pas non plus fait par
des pratiques communes.
Ainsi, le projet ne concerne pas le développement de nouveaux outils pour ce qui
est déjà fait, mais vise l'intégration avec les systèmes existants tels que les
IDE, les plates-formes de modélisation, de production de documents, les
plates-formes d'applications Web, des outils de communication, et de
gestionnaire de calendrier. Cette intégration est une priorité est de haut
niveau dans la conception de Jux afin d'être en mesure de jouer un rôle central
dans la gestion de la complexité avec un effort optimal. Description
* Jux intention est d'être très ergonomique, elle est fondée sur la notion
de «qualité», la qualité de l'environnement lui-même première, la qualité
des artefacts produits (logiciels, documentatin, le soutien et les
orientations trainin, etc) et la qualité de l'enseignement et la formation .
Elle s'appuie sur MDA (Model Driven Architecture) et définit l'instance
JuXUP du processus unifié de développement de logiciels et de mangement de
projet. Le procédé est appliqué au projet Jux lui-même, qui fournit un
exemple réel de sa mise en application.
* En plus de la gestion de projet, Jux est effectivement utilisé pour la
préparation des cours, considérés comme des projets à deux niveaux: le
travail des enseignants et le travail de l'élève.
* Jux est utilisé pour la production de la documentation sur le génie
logiciel et de HCI. présentation actuelle est statique, mais les futures
versions comprennent le traitement dynamique pour CSCW et CSCL.
Le projet est basé sur XML, les documents sont écrits en XML et traitées par
divers outils, y compris XSLT, C et Java, scripts shell Unix et une collection
de macros JEdit. Comme mentionné ci-dessus, Jux ne "réinventé la roue", comme on
dit en français, mais il s'appuie et intègre opérationnels existants et prouvé
(gratuit) des systèmes et des outils, ainsi technique et documentation de
l'utilisateur est produit en utilisant DocBook.
Organisation est centralisée dans un sile sigle XML: un fichier de projet
comprend la planification en fonction de JuXUP ainsi que des liens à tous les
artefacts du projet: DOCUMENTATION gestion, le développement technique et
utilisateur. Un autre petit fichier fournit un haut niveau, l'utilisateur et
«nouveau développeur» vue orientée de l'architecture du système. outils de
transformation XML sont ensuite utilisés afin d'offrir différentes vues du
projet et / ou de ses objets:
* vue du développement montre tous les détails y compris des commentaires
en-tête mis en évidence et les tâches TODO.
* Voir le projet est similaire à l'exception des observations précédentes et
TODO tâches.
* Présentation vue montre la version publiée du projet, effectivement
appliquées aux cours pour lesquels ce point de vue représente la page
publiée à l'usage de l'étudiant (planification bien sûr, les ressources,
liens, etc.)
* Afin d'aider les "maîtrise de la complexité», les méta-informations
(telles que le type d'un élément, phase, un artefact - entrée ou de sortie,
etc) et les propriétés (telles que la priorité d'une tâche et l'état) sont
représentés par "intuitive" couleurs. Jux documents sont riches en couleur
et de fournir des installations de navigation tels que les menus
automatiquement généré pour haut-niveau (par exemple les phases du projet)
et des menus et / ou sous-menus pour les éléments de niveau secondaire
(workflows, par exemple). Comme la structure de base de données interne (le
modèle XML) est presque complètement défini, une plus grande attention est
effectivement portée à improvments présentation qui sont rapidement
développés et mis en oeuvre, tels que les tableaux présentant les équipes
avec des menus curseur sensibles témoignent de compétences de chaque acteur
avec un bref curriculum vitae -comme description.
* Parmi les autres points de vue:
o tables sythetic gestion de projet, de couleur en fonction des rôles
(utilisateur, expert du domaine, architecte, analyste, concepteur et
développeur), priorité de la tâche et le statut et avancement de la
production d'artefacts; o pages d'évaluation dynamique donnant de référence
rapide pour la production de chaque membre de l'équipe et l'édition note
rapide. L'évaluation est sauvegardé dans un fichier XML pour un traitement
ultérieur.
Pour aider à la complexité maître, JuXUP fait un usage intensif de la couleur à
tous les niveaux: les éléments du processus (phases, flux de travail, activités,
tâches et artefacts), des références de projet (modèles, les caractéristiques,
les composants, les utilisateurs et documentations techniques, le code source et
les binaires), UML modèles, et les documents publiés.
Jux comprend minimale des installations de balisage de texte, y compris
hyperlists, et un minimum d'annotation sémantique (Concept, concept et le
thème). Les travaux en cours comprend un support pour la gestion des tâches et
le traitement automatiques dynamique des ressources Jux (ingénierie sotware,
développement de projet, travail en équipe, outils, exemples de projets, ...)
afin de fournir automatiquement guidé la formation selon le concept de biens non
durables (court pour les logiciels et autochtones lignes chanson).
Jux est encore (et sera pour longtemps) en cours de développement mais les
pièces develpped sont opérationnels et effectivement en fonction. Ceci est rendu
possible parce JuXUP, inspirée par les méthodes agiles et de l'expérience,
affirme que d'un prototype opérationnel devrait être mis au point tout le long
du processus de développement, qui est aussi extrèmement important de vérifier
que le système est produit selon les exigences, à l'expert de domaine
spécifications ans aux attentes des utilisateurs finaux.
Selon mon expérience, la version 0.3 (troisième itération) est la conclusion de
la phase d'inspection et le point d'entrée aux phases suivantes. il devrait être
le premier présentable version et devrait permettre specifactions précise pour
le début de détail (technique) de modélisation. Je travaille actuellement sur la
version 0,3 Jux, l'évaluation des travaux antérieurs, l'étude des modèles
existants et des systèmes, l'évolution planifying et extensions (vers CSCW et
CSCL), la définition interafaces intégration avec les outils et systèmes,
l'élaboration de spécifications, le développement des niveaux élevés du modèle
et l'élaboration de spécifications.
Il vaut la peine de noter que dans l'ingénierie JuXUP aller-retour est appliqué
à l'intérieur de chaque phase et non pas sur toutes les phases. En cas de réel
de grands changements, l'ensemble du processus est appliqué à nouveau pour mise
à jour majeure. Deux autres méthodes spécifiques de l'approche générale UP sont
appliquées à l'intérieur de chaque phase: FFD pour l'interface graphique et des
fonctionnalités avant droite, ce qui aide à définir les spécifications précises
nécessaires à la deuxième méthode plus en profondeur qui s'appuie sur OMT.
- Thèmes
- Recommendations pour les "feuilles" à consulter en fonction des
objectifs et de l'avancement.