Central topic

très compliqué car boîte noire

coûts

simplicité

maintenance

vitesse de développement

workflow

webservices

complexité

ergonomie

installation

base de registre

pas de cadrage

purationde l'interface de dev : suppression des champs inutiles

Etat des lieux / compréhension

ce qu'est 2G

oui pour des systèmes très simples de type mapping de table lecture / écriture sans traitements

oui une fois la personne formée

oui si application pas trop complexe

maintenance difficile

non cadrage des dev et difficilie de les contraindre et de meme de les suivre

eparpillement des informations

regressions sur les interfaces car aucune possibilite de test

rigidite des interfaces trop liees aux data (format affichage, design)

pas de phylo web en general et à moyen terme (2 ans)

la gestion du specifique devra tjs attendre les dev 2G (cf. toolbar onglet, image / %, ...)

SoA 2G n'est pas oriente vers HUB web services ou composites de design

2G nous contraint à faire des pseudo service mais ne correspond aux possibilites des standards SoA (dependances, cartographie...)

RAD

ce que Rhodia veut en faire

référentiel de données commun

plateforme de gestion de webservice

usine à site web oriente métier

creation de composites

des interfaces web d'aggrégation d'information (type portail)

critique

fonctionnel

approche métier

nécessite connaissance très complète en 2G qui sont des connaissances techniques avancées

interface inaccessible à un utilisateur lambda

la création de l'application n'est pas guidée par une logique métier

approche développeur

ergonomie

la prise en main difficile de l'ensemble de l'outil

information éclatée

absence de tutoriaux, de bonnes pratiques, de système d'aide interactif (style chm)

documentation de l'interface elle même = commentaires sur rôle de tel bouton

2G contraint le schema à s'adapter à son fonctionnement et pas l'inverse

technique

architecture

installation

besoin d'integration <> appli web

architecture interne

ex : rapport avec bd = contrainte

conception

création de set de formulaire impossible

reponse 2G : gestion au niveau table de tous les contrôles dont étendra le formulaire

absence de bonnes pratiques et de pratiques courantes conduit à des erreurs de conception

Non respect des standards pour les SGBDR connus

logique de contrainte entierement ds 2G et donc non re-utilisable

schema DB difficilement re-exploitables par des logiciels tiers

support

"papier"

nécessite une document très fournies pour chaque application => temps gagné au dev est perdu à ce niveau

éclatement de l'information demande une qualité de rédation supèrieure à la moyenne

humain

Nécessite un contact étroit avec le support 2Gpour palier à la subtilité du produit (viable à long terme et dans le cadre d'une TMA ?)

projet

spécification / mesure temps de charge

bugs qui font perdre du temps

cf listes sur interfaces web

calendrier

documentation

test

test unitaire

service

commande

formulaire

maintenance

corrective

évolutive

migration

tunning des performances

sécurité des applications

pérennité

entreprise

systeme de versionning

systeme de livraison

migration de projets realise. Compatibilite? Cout? deroulement?

application face au marché

comment faire mieux

Outils hors 2G

si complémentaire .net et si 2G efficace surtout dans les cas simples pourquoi ne pas faire directement du .net

avec 2G

composite visual studio / 2G (moteur de workflow)

capable de comprendre des implications métiers

compétent techniquement <= prise en main de l'outil difficile

expérimenté en conception logiciel pour palier au manque de cadrage de l'outil

dédié sur une longue période à l'outil

capable d'accepter de travailler sur une techno difficilement valorisable sur un CV