Concept: Développer des solutions e-business
La construction d'applications e-business sous-entend construire des solutions internet pour implémenter des processus métier. Cela comprend le e-commerce mais s'étend à tous les processus métier à travers une organisation.
Description principale
Activités à travers le cycle de vie :
Concepts : 
Livres blancs :

Introduction

La construction d'applications e-business sous-entend construire des solutions internet pour implémenter des processus métier. Cela comprend le e-commerce mais s'étend à tous les processus métier à travers une organisation. 

Les systèmes e-business peuvent être divisés en :

  • systèmes de première génération qui utilisent simplement le web pour publier des informations
  • systèmes de deuxième génération qui implémentent le e-commerce et des modèles simples de transaction
  • systèmes de troisième génération qui remanient entièrement un processus pour fournir des solutions hautement personnalisées (business-to-consumer ou business-to-business) qui peuvent s'adapter et qui automatisent le processus dans son ensemble en intégrant souvent des systèmes en vigueur et des dispositifs internet

Plus les systèmes sont dans les générations, plus leur développement est complexe.

Activités de la phase de création

L'enchaînement d'activités de base s'applique pour la Phase de création avec les extensions et les variantes suivantes.

Environnement

La  Tâche : Préparation des instructions relatives au projet devient plus importante et se focalise sur ce que les développeurs appellent "instructions de conception graphique" qui est un ensemble d'instructions décrivant (à un niveau élevé)

  • L'humeur du site. Par exemple le site est-il porteur d'autorité, d'enjouement ou de service ? A-t-il un aspect conservateur ou provocant ?
  • Comment les utilisateurs vont-ils accéder au site. Par exemple quelle est leur vitesse de connexion ? Y-a-t'il une vitesse minimum spécifiée ou supposée dans la conception ?
  • Le degré d'interaction avec l'utilisateur. Par exemple, doit-on informer l'utilisateur uniquement ou doit on essayer de communiquer aussi avec l'acteur (communication dans les deux sens) ? La conception de l'application doit-elle être différente selon l'utilisateur qui accède à l'application ?
  • Les navigateurs dont les utilisateurs vont se servir, y compris les différences à travers les systèmes d'opération
  • Si le site va utiliser des cadres
  • Toute limitation de couleur qu'aura le site
  • S'il est applicable, un guide de normes de graphiques (y compris les normes sur les logos et toutes les couleurs de l'entreprise)
  • L'usage de techniques web particulières. Par exemple, effets de survol, animation, alimentation en nouvelles, multimédia etc.

Les "Instructions de conception graphique" évoluent dans les instructions d'interface utilisateur documentées dans le  Produit : instructions relatives au projet ; il s'agit essentiellement d'une première version des instructions d'interface utilisateur.

Recueil des exigences

Il est supposé que les activités suivantes utilisent les résultats d'un exercice de modélisation métier qui se trouve en dehors de la portée de ces instructions.

Cette activité a moins d'importance.  La plupart des problèmes ont déjà dû être repérés lors de la modélisation métier.

Cette activité a moins d'importance. La plupart des besoins des parties prenantes ont dû être trouvés lors de la modélisation métier. Vous devrez néanmoins faire quelques exercices qui ont pour objectif de trouver les exigences non fonctionnelles sur le système.

Cette activité a moins d'importance.  La frontière du système est définie par la frontière du métier puisque le système reflète plus le métier que dans les applications traditionnelles (sous certains rapports, le système est le métier).

Analyse et conception

La Tâche : conception de l'interface utilisateur produit une carte de navigation. Une carte de navigation est une vue de solution Web qui montre comment les utilisateurs vont naviguer sur le site, représentée par un "arbre" montrant les différentes hiérarchies. Chaque niveau du diagramme montre le nombre de fois qu'il faut cliquer pour obtenir l'écran ou la page correspondant. Vous voulez généralement ne devoir cliquer qu'une seule fois à partir de la première page (la page d'accueil) pour avoir accès aux zones les plus importantes du site. La carte de navigation est un récapitulatif des Storyboards, qui commence par identifier les fenêtres importantes ou les pages Web de chaque cas d'utilisation et prend en compte comment l'utilisateur navigue entre ces éléments.

Activités de la phase d'élaboration

L'enchaînement d'activités de base s'applique pour la Phase d'élaboration avec les extensions et les variantes suivantes.

  • Activité : Définir une architecture candidate

    La Tâche : analyse architecturale tire partie du fait qu'une application Web est connue pour disposer d'une architecture relativement bien définie, avec un ensemble de mécanismes bien définis (navigateurs Web, applets et servlets Java, ASP et JSP, etc.). Une simple structure en couches comme décrit dans Concept : Organisation en couches suffit généralement à moins que l'infrastructure préfabriquée du développement de l'application ne soit plus précise. Dans bon nombre de cas, il peut y avoir des architectures standard prédéfinies que l'on peut acheter ou réutiliser à partir de projets précédents de développement Web. Les infrastructures prédéfinies d'application Web comme WebSphere d'IBM ou Windows DNA de Microsoft, fournissent ce genre d'élément paramétré architectural.

    Les applications Web ne disposent pas de temps d'indisponibilité programmé. Il se peut que l'architecture ait besoin (et c'est généralement le cas) de prévoir une mise à niveau du système lorsqu'il est en cours d'exécution et de passer sur des serveurs en veille lors du premier échec du serveur ou lorsque la maintenance ou les mises à niveau du serveur s'effectuent. Certaines infrastructures prédéfinies d'application Web fournissent des outils pour le support de production. Si les exigences de votre application sont à haute disponibilité, vous devrez quand même prévoir d'acheter ou de construire l'infrastructure nécessaire pour supporter cette exigence et d'intégrer le support de cette capacité dans l'architecture.

  • Activité : Analyser le comportement

    La Tâche : Concevoir l'interface utilisateur est effectuée de façon itérative à l'intérieur des itérations de l'élaboration. Les premières exécutions portent sur la production de "réalisations de conception créative" qui sont des maquettes de la conception des pages Web clés du site. Ces "réalisations" sont des images "planes" composées avec les graphiques de la fenêtre du navigateur pour donner l'apparence d'une fenêtre de navigation. Leur principal avantage est qu'elles reportent l'investissement en prototypes HTML plus élaborés et plus coûteux jusqu'à ce qu'il y ait un consensus sur une direction graphique précise du site.

    Elles sont créées en se rapportant aux exigences d'interface des cas d'utilisation les plus importants et en développant beaucoup de conceptions alternatives (10 ou plus) pour son apparence. Les trois options les plus intéressantes sont choisies pour être présentées aux parties prenantes. Cela se fait de façon itérative jusqu'à ce qu'il y ait un accord sur la conception Web finale, qui résulte en un ensemble de Storyboards et une Carte de navigation.

    Une fois l'accord passé, les réalisations de conception évoluent vers un prototype d'interface utilisateur au travers des exécutions répétées de la Tâche : prototype de l'interface utilisateur. Le prototype Web interface utilisateur initial supporte des parties du système (les cas d'utilisation les plus importants et les plus significatifs architecturalement). Il est important d'avoir une architecture solide dans le cas d'utilisation flux des événements avant de développer les prototypes pour s'assurer que c'est bien cette fonctionnalité qui assure la représentation de l'interface utilisateur et non l'inverse.

    Le prototype Web est élargi dans les itérations suivantes, ajoutant progressivement une plus grande couverture des cas d'utilisation et des exercices plus approfondis de l'architecture.

    La Tâche : analyse de cas d'utilisation reste relativement inchangée, excepté qu'il est important de se focaliser aussi sur la logique métier sous-jacente et pas uniquement sur le comportement de l'interface graphique (la partie qui va s'exécuter soit sur le serveur Web soit sur le serveur de l'application). Si vous ne le faites pas, la partie la plus significative du système sera oubliée. Les pages Web sont représentées en tant que classes de "frontière", les données élémentaires en tant que classes d'"entité" et le comportement du côté serveur (pages de serveur actives, servlets etc.) est représenté via des objets de "contrôle".

    Tout de suite après l'analyse de cas d'utilisation, la Tâche : identification_conception_éléments_temps réel_conception détaille le Produit: classes d'analyse, les mappant sur les mécanismes existants dans l'infrastructure préfabriquée du développement Web et réutilisant les éléments de conception existants à partir de projets ou d'itérations précédents si possible. Cela demande souvent un réajustement de la portée et de la définition des classes d'analyse identifiées afin de pouvoir atteindre le degré de réutilisation désiré.

    Une description plus détaillée de l'utilisation du langage UML pour décrire les applications Web se trouve dans Livre blanc : modélisation des architectures d'application Web avec le langage UML.

  • Activité : préparation de l'environnement.

    Outre le développement des instructions relatives à l'interface utilisateur, des éléments de conception (les images graphiques discrètes assemblées pour la construction des pages Web d'un site) sont créés. Il est primordial, pour l'utilisation du site, que l'interface utilisateur soit cohérente dans tout le site. Celui-ci doit fournir un acquis utilisateur cohérent. Pour cela, le projet doit invariablement utiliser un ensemble d'éléments graphiques standard à travers tout le site.

    Le développement de ces éléments est un prolongement de la  Tâche : Préparation des instructions relatives au projet qui comprend la création des instructions relatives à leur utilisation. Assurez-vous que tous les membres de l'équipe comprennent bien quand et comment utiliser ces éléments. Des exemples d'éléments de conception Web comprennent les éléments graphiques comme dispositifs de navigation et les arrière-plans. La réutilisation d'éléments graphiques standard de haute qualité à travers tout le site assure une cohérence, réduit le temps d'accès sur le marché et le coût de développement et augmente la qualité en déployant un ensemble plus restreint d'éléments de meilleure qualité.

    La préparation des instructions se fait conjointement au développement du Prototype interface utilisateur Web initial pour l'élaboration du guide de style du site. Ce guide de style spécifie, entre autre, quand et comment utiliser les éléments de conception Web, les schémas de couleurs, les polices de caractères, les feuilles de style en cascade et les détails relatifs au fonctionnement et au positionnement des éléments de navigation.

  • Activité : Détail de l'architecture

    La Tâche : Identification des mécanismes de conception porte plus sur le mappage des exigences non fonctionnelles du système sur les mécanismes que fournit l'infrastructure préfabriquée du développement Web. Les mécanismes non fournis par cette infrastructure (si elle existe) devront être identifiés et il faudra trouver de nouvelles solutions.

    La Tâche : Description de l'architecture en phase d'exécution se concentre essentiellement sur le serveur Web, les plateformes de serveur d'application (voir Concept : Schémas de distribution) et les processus et unités d'exécution utilisés ici pour gérer l'accès concurrent dans l'application. Il y a généralement peu ou pas de contrôle exercé sur le traitement des machines du côté client.

    La Tâche : Description de la distribution change d'objectif en ne se focalisant plus sur "quel genre de noeuds de serveur avoir" mais sur "combien de noeuds de chaque type de serveur avoir" L'infrastructure préfabriquée du développement Web va généralement fournir un nombre défini de types de serveur (serveurs web, serveurs d'application, serveurs mail, serveurs de passerelle de communication) avec des frontières fonctionnelles relativement bien définies. En conséquence, la compétence de l'architecte du logiciel est de déterminer comment traiter les exigences de mise à l'échelle et de tolérance de défaut à l'aide des types de serveur disponibles, en précisant généralement combien il faut de serveur de chaque type. Il faut aussi établir des plans de mesure pour déterminer comment savoir que des serveurs supplémentaires sont nécessaires.

  • Activité : Définir la mission d'évaluation

    La planification porte, à un degré très élevé, sur le test de performance afin de s'assurer que l'application Web peut supporter les augmentations significatives du nombre d'utilisateurs concurrents. En conséquence, les activités de test Vérifier  l'approche du testTester et évaluer, Accomplir une mission acceptable, Améliorer les actifs de test se focaliseront davantage sur le test des performances afin de s'assurer que l'architecture est à échelle variable.  

    D'autres types de test importants sont le test de convivialité et le test de structure. Il faut tester l'interaction entre utilisateurs pour vérifier que la structure de l'application Web est bien appropriée pour ses utilisateurs. Dans certains cas, vous êtes forcés d'avoir l'application sur internet de manière à pouvoir surveiller comment les utilisateurs font usage de l'application.

    Un autre type de test qui demande beaucoup de temps est le test de navigateur puisque la compatibilité entre les navigateurs et les versions de navigateurs limite souvent les options de conception dans les interfaces utilisateurs.

  • Activités : Implémentation des composants, Intégration de chaque sous-système et Intégration du système

    Afin de valider les décisions relatives à l'architecture prises jusqu'à présent, un ou plusieurs prototypes architecturaux sont développés et testés, impliquant l'exécution successive de l'Activité : implémentation des composants, Activité : intégration de chaque sous-système et Activité : intégration du système. Le test, comme mentionné ci-dessus, doit porter en particulier sur la variation d'échelle de l'application face aux augmentations imprévisibles dans la charge du système.

Activités de la phase de construction

L'enchaînement d'activités de base s'applique pour la Phase de construction avec les extensions et les variantes suivantes.

Activités de la phase de transition

  • L'édition du produit dans l'environnement Web tend à être incrémentielle, continue et moins focalisée sur la distribution traditionnelle des supports. La planification de l'édition doit être ajustée en conséquence.
  • La formation de l'utilisateur dans l'environnement Web tend à être intégrée dans la conception du site Web lui-même si bien que l'utilisation du site se fait de manière intuitive. La création de manuels de formation traditionnels ou de documentation diminue et l'accent est de plus en plus mis sur la conception graphique et la conception du contenu au frontal du processus.
  • Le support d'application de la production dans l'environnement Web doit porter sur la capacité à maintenir une grande disponibilité sous une charge imprévisible. Il doit aussi pouvoir être capable de continuer à fonctionner lorsque les serveurs principaux échouent et pouvoir tenir compte des mises à niveau du serveur pendant que le système est en cours d'exécution.
  • Il faut qu'il y ait un transfert de connaissances de l'équipe de développement à l'équipe de support de production pour que le personnel du support de production soit capable d'exécuter le système et d'effectuer la maintenance habituelle.
  • Faire un suivi de la manière dont les utilisateurs font usage de l'application. Cette information est utile pour savoir qui utilise l'application et comment elle est utilisée. Ces observations peuvent vous aider à développer des éditions supplémentaires afin d'améliorer l'interaction entre utilisateurs.
Les étapes de cette page sont développées en coopération avec Context Integration. Lien vers le logo Context