Onglet 3 – Conception (Design)
3.1 Niveau de modélisation
Simple HTML modélisation non applicable
Uniquement données en Entité-Relation
E-R + Flux (SASD, Gane-Sarson, etc.)
E-R + Flux + Traitements détaillés
Modélisation objet complète OMT/UML
Le niveau de modélisation doit être adapté au type d'application. Il est, par exemple, inutile et disproportionné de mettre en œuvre une approche de modélisation merisienne lors d'une simple application décisionnelle requérant uniquement la définition d'un niveau de structuration des données préalablement existantes.
Un environnement performant dispose d'outils comme AMC*Designor, Rose, etc. Un environnement moyen correspond à des outils le plus souvent propriétaires. RAD requiert les outils les plus performants pour une conception optimale en direct.
3.2 Le modélisateur connaît l'environnement fonctionnel
Au niveau de la conception, et particulièrement pour le décisionnel ou le stratégique, les modèles de traitement merisiens sont remplacés par le principe de la hiérarchie de fonctions. (si le paramètre est non applicable, choisir l’option " Parfaitement ").
Lorsqu’un informaticien dispose d'une expérience fonctionnelle et particulièrement lorsqu'il a déjà modélisé une classe application, il lui est infiniment plus aisé d'obtenir un nouveau modèle parfaitement adapté au cas spécifique tout en bénéficiant des points forts, des détails et des exceptions révélées par son expérience antérieure.
3.3 Architecture de conception " en vue de modifications "
Cette architecture permet d'obtenir un état de livraison permanente et de réaliser des applications évolutives. Concevoir en vue de modification nécessite de connaître plusieurs techniques complémentaires qui se retrouvent généralement dans les approches objets. L'architecture de conception en vue de modification est basée sur les techniques objets : dissimulation, modularité, abstraction, encapsulation, cohésion, couplage, hiérarchie, héritage, polymorphisme, algorithmique, structuration (traitements et données).
Cette option de développement représente de la rigueur, et un investissement qui se rentabilise par la facilité de modification qui en résulte. La justification de cet investissement implique donc un type d'application avec un minimum d'espérance de vie ou un type d'application stratégique nécessitant une forte capacité d'adaptation immédiate.
3.4 La documentation technique produite par l’AGL (de conception) est suffisante
La documentation d'analyse doit être entièrement gérée par l'AGL de conception et doit être considérée comme suffisante. Répondre :
OUI si la production automatique de l’AGL est suffisante pour les besoins techniques (en général de maintenance) ;
NON si vous devez produire une documentation de conception manuellement pour satisfaire à divers besoins (qu’il faudra faire justifier ROI à l’appui).
La documentation technique a pour seul objectif de faciliter le développement et la maintenance qui en est le prolongement naturel. On distingue plusieurs formes de documentation technique :
La documentation de Cadrage (spécification) inclut généralement sous une forme textuelle le cahier des charges et les divers documents destinés à faciliter la compréhension des exigences.
La documentation Design (conception) inclut sous une forme graphique les modèles de données, de traitements et de communication. Ces informations doivent impérativement être gérées dans un AGL spécialisé permettant de générer automatiquement des rapports sous forme de textes à partir de l'expression graphique des modèles.
La documentation de Construction (codage) doit désormais répondre impérativement aux particularités du mode "Windows" qui distribue des portions de codes dans chaque événement de chaque objet de l'IHM. Pour être réellement utilisable cette documentation doit être totalement intégrée au code qu'elle décrit et structurée au niveau de l'application, du module, de l'objet et de l'événement.
3.5 Réutilisation existant fonctionnel (%)
Cet existant peut être une ancienne application, ou un modèle de données issu d'une autre application, ou le contenu des pages HTML en format DOC propre. (Dans ce dernier cas, si vous négociez et composez le contenu des pages, choisir l’option " 0" (zéro) pour ce paramètre).
Lors de la refonte d'une application, étudiez la partie fonctionnelle existante. Lorsqu'elle est satisfaisante (qualité, complétude) et actualisée, elle permet un gain de temps appréciable et évite de nombreux tâtonnements ou erreurs. Dans le cas d'une nouvelle application, il est souhaitable de réaliser un benchmarking.
3.6 Résolution application cible
La résolution CIBLE détermine la résolution de développement. Cet aspect conditionne à la fois l’ergonomie des applications, le confort et la productivité des utilisateurs. En termes de retour sur investissement, il représente la pierre angulaire de la décision (figure 90).
3.7 Résolution de développement
La résolution de développement doit permettre un affichage simultané de l’écran cible et des palettes d'outils. Cette possibilité conditionne la performance de développement. Développer professionnellement une application en mode VGA requiert une résolution d’au moins 1024*768 et un écran de 17 pouces. Si l’application cible est SVGA, la résolution de développement doit être XGA appliquée à un écran de 20 ou 21 pouces. De nombreuses études démontrent la rentabilité à court terme (2/3 mois) du couple haute résolution et écran adéquat..
