Activités à travers le cycle de vie :
Concepts :
Livres blancs :
|
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.
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.
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 test , Tester 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.
L'enchaînement d'activités de base s'applique pour la Phase de
construction avec les extensions et les variantes suivantes.
-
Activité : Planification de l'intégration
Les deux tâches Tâche : intégration du sous-système du plan et Tâche : intégration du système du plan doivent traiter des
différents types d'éléments d'implémentation créés dans la phase de construction.
-
Activité : Implémentation de composants
La Tâche : Implémentation des éléments de conception met
l'accent sur plusieurs types d'éléments différents :
-
Pages Web, applets, scripts, graphiques et autres éléments qui "s'exécutent" dans l'environnement du
navigateur.
-
Pages du côté serveur, scripts, servlets et autres éléments qui "s'exécutent" dans l'environnement du
serveur Web.
-
Extension des codes d'exécutable aux applications existantes
-
Tables de base de données, déclencheurs, procédures mémorisées et autres éléments qui s'exécutent dans
le système de gestion de base de données
Les différences d'outils et de technologies de déploiement entre ces différents types d'éléments signifient
qu'il existe un nombre de variantes similaires sur la Tâche : Implémentation des éléments de conception. Il y aura
des adaptations similaires dans l'Activité : intégration de chaque sous-système et Activité : intégration du système.
-
Activité : Définir la mission d'évaluation
La planification de test est toujours orientée sur le test de performance mais elle s'oriente de plus en plus
sur le test fonctionnel. Une approche de test légèrement différente est requise pour chacun des différents
types d'éléments qui comprennent une application. Il y aura des adaptations similaires dans les activités de
test Vérifier l'approche de test, Tester et évaluer, Accomplir une mission acceptable, Améliorer les actifs de test, dans lesquels l'accent mis sur
le test orienté sur la performance architecturale passe au test fonctionnel, assurant que les détails relatifs
au comportement du système sont corrects.
-
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.
|
|
|