por Alex Mathe hace 17 años
209
Ver más
si complémentaire .net et si 2G efficace surtout dans les cas simples pourquoi ne pas faire directement du .net
application face au marché
entreprise
migration de projets realise. Compatibilite? Cout? deroulement?
systeme de livraison
systeme de versionning
sécurité des applications
tunning des performances
migration
évolutive
corrective
test
test unitaire
formulaire
commande
service
documentation
spécification / mesure temps de charge
bugs qui font perdre du temps
calendrier
cf listes sur interfaces web
support
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 ?)
"papier"
éclatement de l'information demande une qualité de rédation supèrieure à la moyenne
nécessite une document très fournies pour chaque application => temps gagné au dev est perdu à ce niveau
conception
Non respect des standards pour les SGBDR connus
schema DB difficilement re-exploitables par des logiciels tiers
logique de contrainte entierement ds 2G et donc non re-utilisable
absence de bonnes pratiques et de pratiques courantes conduit à des erreurs de conception
création de set de formulaire impossible
reponse 2G : gestion au niveau table de tous les contrôles dont étendra le formulaire
architecture
architecture interne
ex : rapport avec bd = contrainte
besoin d'integration <> appli web
approche développeur
2G contraint le schema à s'adapter à son fonctionnement et pas l'inverse
la prise en main difficile de l'ensemble de l'outil
documentation de l'interface elle même = commentaires sur rôle de tel bouton
absence de tutoriaux, de bonnes pratiques, de système d'aide interactif (style chm)
information éclatée
approche métier
la création de l'application n'est pas guidée par une logique métier
nécessite connaissance très complète en 2G qui sont des connaissances techniques avancées
interface inaccessible à un utilisateur lambda
des interfaces web d'aggrégation d'information (type portail)
usine à site web oriente métier
creation de composites
plateforme de gestion de webservice
référentiel de données commun
RAD
application orienté service
2G nous contraint à faire des pseudo service mais ne correspond aux possibilites des standards SoA (dependances, cartographie...)
SoA 2G n'est pas oriente vers HUB web services ou composites de design
agilité des applications
la gestion du specifique devra tjs attendre les dev 2G (cf. toolbar onglet, image / %, ...)
pas de phylo web en general et à moyen terme (2 ans)
rigidite des interfaces trop liees aux data (format affichage, design)
regressions sur les interfaces car aucune possibilite de test
maintenance difficile
eparpillement des informations
non cadrage des dev et difficilie de les contraindre et de meme de les suivre
oui si application pas trop complexe
complémentarité .net
baisse des coûts
oui une fois la personne formée
réactivité accrue
oui pour des systèmes très simples de type mapping de table lecture / écriture sans traitements
abstraction des connaissances techniques
base de registre