Concepts : Développer des solutions de composant

Rubriques
Activités au cours du cycle de vie :
  1. Introduction
  2. Activités de la phase de lancement
  3. Activités de la phase d'élaboration
  4. Activités de la phase de construction
  5. Activités de la phase de transition
Rubriques supplémentaires:

Introduction Haut de la page

Le développement basé sur les composants est une variante du développement d'applications général dans lequel :

  • L'application est assemblée à partir de composants non intégrés exécutables qui sont développés et déployés de façon relativement indépendante les uns des autres, si possible par différentes équipes.
  • L'application peut être mise à jour en incréments plus petits en mettant uniquement à jour certains des composants qui forment l'application.
  • Les composants peuvent être partagés entre les applications, ce qui crée des opportunités de réutilisation, mais également des dépendances inter-projet.
  • les applications basées sur des composants sont généralement de type réparties bien que cela n'ait pas de relation directe avec le fait qu'elles soient basées sur des composants.

Sur cette page, le terme "composant" est utilisé pour faire référence aux composants déployables et développés de façon indépendante. Toutefois, ailleurs dans RUP, nous utiliserons le terme "composant" dans son acceptation plus générale décrite dans Concepts : Composant, en le précisant si nécessaire.

L'adaptation du Rational Unified Process (RUP) aux défis du développement basé sur les composants est abordée ci-après.

Activités de la phase de création Haut de la page

L'enchaînement des activités de base pour la phase de création s'applique, avec les extensions ou les variantes suivantes :

Gestion de projets

  • ../process/workflow/manageme/wfs_eval.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement des activités : Evaluation de la portée et du risque du projet
  • Une approche axée sur les composants modifie la nature de certains risques et introduit de nouveaux risques. En particulier :

    • Les composants provenant de l'extérieur augmentent le risque car ils introduisent des éléments cruciaux qui ne sont pas sous le contrôle direct de l'équipe du projet
    • Les composants provenant de l'extérieur peuvent réduire le temps de développement, réduisant le risque en termes de ressources
    • Les composants provenant de l'extérieur peuvent déformer l'architecture du système s'ils imposent eux-mêmes des restrictions architecturales
  • ../process/workflow/manageme/wfs_sdp.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement des activités : Planifier le projet
  • Dans l'Activité : Planifier les phases et les itérations, le plan de la phase de construction peut éventuellement afficher le fractionnement du projet en deux pistes différentes mais parallèles : une qui développe les composants propres au domaine et à l'application (situé dans les couches supérieures de l'architecture - voir Concepts : Organisation en couche), et une pour les composants qui ne sont pas propres au domaine et à l'application situés dans les couches inférieures. Dans certains cas, des composants réutilisables seront développés par les équipes de développement gérées de façon indépendante. La décision d'introduire des pistes parallèles est essentiellement une question de ressource et de dotation en personnel née de la volonté de gérer des composants réutilisables comme des ressources indépendantes des applications dans lesquelles les composants sont déployés.

Exigences

Test

Environnement

  • ../process/workflow/environm/wfs_env1.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement des activités : Préparer l'environnement pour le projet
  • Lorsque vous recueillez et préparez les recommandations pour le projet, prenez en compte l'infrastructure spécifique des composants et les contraintes qu'elle impose. Les recommandations doivent indiquer la façon de concevoir et de codifier en utilisant l'infrastructure. Elles doivent également donner une orientation sur la manière de vérifier la conformité avec l'infrastructure de composants elle-même et et les interfaces définies entre les composants.

Activités de la phase d'élaboration Haut de la page

Pour la phase d'élaboration l'enchaînement des activités de base s'applique, avec les extensions et les variantes suivantes :

Exigences

Analyse et conception

  • Détails de l'enchaînement des activités : Concevoir la base de données
  • L'objectif de l'élaboration est de garantir que la stratégie de persistance est évolutive et que la conception de la base de données et le mécanisme de persistance prendra en charge les besoins en débit du système. Les classes persistantes sont identifiées et mappées au mécanisme de persistance. Les cas d'utilisation faisant un usage intensif des données sont analysés pour s'assurer que les mécanismes seront évolutifs. En conjonction avec les détails de l'enchaînement des activités de test, le mécanisme de persistance et la conception de la base de données sont évalués et validés.

Implémentation

Test

  • Détails de l'enchaînement de l'activité : ../process/workflow/test/wfs_dfnevlmsn.htm -- This hyperlink in not present in this generated websiteDéfinir la mission d'évaluation, ../process/workflow/test/wfs_tstandevl.htm -- This hyperlink in not present in this generated websiteTester et évaluer, ../process/workflow/test/wfs_achmsnacp.htm -- This hyperlink in not present in this generated websiteAccomplir une mission acceptable

    Les activités de test dans l'élaboration consistent à valider l'architecture. Pour un système basé sur les composants, cet objectif conduit à :

    • exécuter les interfaces entre les composants, pour s'assurer que les limites des composants sont appropriées, et
    • porter une plus grande attention aux tests de performance, en particulier aux tests d'évolution des performances, pour s'assurer que les volumes de transaction anticipés peuvent être pris en charge

    Toutes les hypothèses inhérentes dans l'infrastructure de composants doivent être également évaluées. Celles-ci incluent en général la capacité d'évolution et le débit des mécanismes de persistance et de gestion des transactions dans lesquels des hypothèses cachées faites par le concepteur des mécanismes amoindrissent souvent en réalité l'architecture de l'application si elle ne comprend pas l'hypothèse.

Gestion de projets

  • ../process/workflow/manageme/wfs_plan.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement des activités : Planifier pour la prochaine itération

    En utilisant les sous-systèmes d'implémentation comme des "unités logiques de responsabilité", le travail de construction peut être divisé en deux "pistes" parallèles ou plus : une qui se concentre sur la fonctionnalité propre à l'application, et une ou plusieurs qui se concentrent sur des composants génériques réutilisables. Cela dépend bien sûr des ressources que l'on aura en personnel et si elles sont suffisantes pour des efforts de développement parallèles. La capacité à diviser les équipes de développement et à travailler en parallèle dépend totalement de la stabilité de l'architecture et plus particulièrement de la qualité et de la stabilité des interfaces entre les composants. Un effort important au niveau de la phase d'élaboration permettra cette division.

Activités de la phase de construction Haut de la page

Pour la phase de construction l'enchaînement des activités de base s'applique, avec les extensions et les variantes suivantes :

Gestion de projets

  • ../process/workflow/manageme/wfs_plan.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement des activités :Planifier pour la prochaine itération

    La planification de la première itération de construction a été décrite précédemment, car elle se produit vers la fin de l'élaboration. Le planning du suivi de l'itération et la capacité à diviser les équipes de développement et à travailler en parallèle continuent à dépendre de la stabilité de l'architecture et de la qualité et de la stabilité des interfaces entre les composants.

Analyse et conception

Implémentation

Test

    Les tests de performance restent importants, mais on porte de plus en plus d'attention aux tests fonctionnels. L'intégralité de la fonctionnalité, les tests de régression de la fonctionnalité existante ainsi que la conformité avec les attentes en matière de performance doivent être satisfaits.

Activités de la phase de transition Haut de la page

  • La version du produit dans l'environnement Web a tendance à être incrémentale et continue, et à moins se concentrer sur la distribution traditionnelle des médias. La planification des versions doit être ajustée en conséquence.
  • La phase se focalise de plus en plus sur la prise en charge de la production
  • Des activités de conversion des données sont réalisées.

RUP (Rational Unified Process)   2003.06.15