• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Assurance Qualité  S O A
 

Assurance Qualité S O A

on

  • 2,142 views

Présentation décrivant les nouveaux défis qu'amènent les projets SOA au niveau de l'assurance qualité.

Présentation décrivant les nouveaux défis qu'amènent les projets SOA au niveau de l'assurance qualité.

Statistics

Views

Total Views
2,142
Views on SlideShare
2,138
Embed Views
4

Actions

Likes
0
Downloads
58
Comments
0

2 Embeds 4

http://technoblog.axon-id.com 3
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Assurance Qualité  S O A Assurance Qualité S O A Presentation Transcript

  • Journée de la qualité informatique du CRIM : Pour maximiser vos investissements en TI 13 décembre 2007
  • Contenu du document
    • À propos d’AXON
    • Une définition rapide de SOA
    • Implications SOA sur l’assurance qualité
    • Description du projet : Étude de cas SOA
    • La démarche préconisée pour l’assurance qualité
    • Recommandations
    • Questions
  • À propos d’AXON
    • Historique
      • Société fondée en 1998
      • Spécialisée en développement de solutions d’affaires Web
      • Expertise reconnue en architecture SOA, intégration, développement d’application Web riches (RIA ), transformation et modernisation d’applications d’entreprise
      • Capacité à réaliser des projets d’envergure
      • De vraies réalisations SOA
  • Une définition rapide de SOA
    • L'architecture orientée services est une approche de développement et un modèle d'interaction applicative qui met en oeuvre des services selon des standards définis, de façon à permettre un partage efficace des fonctionnalités à moindres coûts
    • L'architecture orientée services est une réponse aux problématiques que rencontrent les entreprises en termes de réutilisation, d‘interopérabilité et de réduction de couplage entre les différents systèmes d'information.
    • Une approche informatique (on ne parle pas d’outils) qui implique un rapprochement des unités d’affaires et des TI afin de répondre aux défis des entreprises en termes de :
          • Réutilisation
          • Agilité
          • Efficacité
          • Partage des applications
  • Une définition rapide de SOA
    • Les bénéfices d’affaires attendus sont :
          • 1. Efficacité d'affaires
            • Plus grande agilité et meilleure réponse à la dynamique de marché
            • Plus grande efficacité des processus
            • Meilleur déploiement des ressources
          • 2. Réduction des coûts
            • Réduction des frais d'entretien
            • Réduction des efforts nécessaires pour supporter les changements organisationnels
            • Choix technologiques plus flexibles étant donné le couplage lâche des applications
          • 3. Réduction des risques
            • Niveau plus élevé de qualité de services des TI
            • Déploiement itératif
            • Développement plus rapide qui assure un meilleur retour sur investissement
          • 4. Consolidation des actifs applicatifs
            • Réutilisation des composants ayant une bonne valeur « Affaires »
            • Intégration des composants dans un optique d’optimisation des processus d’affaires
  • Une définition rapide de SOA
  • Implications SOA sur l’assurance qualité
    • Impossible de continuer à tester comme avant parce que:
      • L’utilisation d’un service par plusieurs applications dans l’entreprise augmente les risques d’impacts dans le développement ou la modification des services
      • SOA implique un nouveau groupe de tests qui débute plus tôt dans le cycle et qui nécessite une distribution différente des efforts
      • Adaptation des testeurs à des documents supplémentaires
      • Implication de plusieurs équipes conjointement : architectes, développeurs, etc….
      • Le rapprochement “affaires” et TI prôné par SOA doit aussi se faire au niveau de l’AQ … les testeurs doivent comprendre les besoins d’affaires et technologiques du projet
      • Puisque SOA implique une évolution constante, l’AQ devient un projet continuel
      • Les tests fonctionnels et unitaires sont beaucoup plus complexes dans un environnement “ouvert” et il faut ajouter des tests de régression, d’intégration , de processus d’affaires, de performance et de sécurité.
      • Plus d’emphase doit être mise sur les tests concernant les aspects d’architecture
      • Il faut des environnements de tests adaptés à l’approche SOA
  • Les défis de L’AQ avec SOA
    • La complexité de mettre en place des environnements de tests complets et représentatifs
    • La nécessité d’effectuer des tests “horizontaux” plutôt que “verticaux”
    • La constatation que l’automatisation et les tests des fonctions seules ne suffisent pas
    • La réorganisation des efforts nécessaires pour procéder à tous les tests requis (doc)
    • L’ampleur et la diversité des tests
    • L’implication de plusieurs équipes de façon simultanée (gestion des attentes, planification, etc…)
    • La gestion du changement pour une entreprise qui mène son premier projet SOA
    • L’assurance qualité dès que possible à tous les niveaux
  • L’AQ dès que possible à tous les niveaux Fonctions AQ Résultats Anomalies Corrections
  • L’AQ dès que possible à tous les niveaux Intrants Tâche Extrants
    • Un cas d’utilisation
    • L’architecture
    • Un design
    • Le code
    • Un service
    • Une fonction
    QA QA Un cas d’utilisation Effectuer le design Document de design
  • De nombreux joueurs impliqués
  • Description du projet SOA : Étude de cas
    • Les grands objectifs
      • D’affaires
        • Diminuer la durée moyenne des appels au SAC
        • Simplifier l’intégration et la formation du nouveau personnel
        • Optimiser l’ensemble des processus
        • Augmenter la vitesse de réaction face au marché
        • Assurer une qualité très élevée lors des déploiements
      • Technologiques
        • Capitaliser sur l’existant
        • Augmenter la flexibilité des applications
        • Réutilisation des fonctions dans plusieurs applications
        • Assurer l’évolutivité des systèmes
        • Former le personnel technique
  • Description du projet SOA : Étude de cas
    • Les défis
        • Complexité du processus d’affaires
        • Peu de connaissance et de documentation sur les règles d’affaires et les systèmes existants
        • Changements importants à tous les niveaux de l’organisation
        • Révision complète des processus de développement et d’assurance qualité en raison de la stratégie retenue
        • Projet d’envergure sur plusieurs années
  • Description du projet SOA : Étude de cas
    • La stratégie
        • Mise en place d’une architecture orientée services (SOA)
        • Mise en service des composants RPG, réutilisés par une application Java
        • Révision des processus opérationnels et des processus de développement
        • Mise en place d’une nouvelle structure de gestion de projet
        • Sélection d’outils pouvant supporter les concepts d’architecture et la stratégie de développement
        • Mise en place d’un processus d’essais « horizontaux »
        • Mise en place d’un processus de formation et d’accompagnement continu
  • La démarche préconisée au niveau de l’assurance qualité
    • Objectifs de la démarche
      • Mise en place d’un processus d’essai qui supporte bien la stratégie SOA
      • Intégration des essais le plus rapidement possible dans le processus
      • Possibilité de tester les composants réalisés avant d’avoir les écrans « fonctionnels »
      • Créer et intégrer rapidement les différentes équipes d’essais
      • S’assurer de la qualité du code et des fonctions en continu
  • La démarche préconisée au niveau de l’assurance qualité
    • Processus
    Définition des besoins Comité utilisateurs Création des UC Analystes D’affaires QA UC Comité approbation Identification des services Architecture & design Architecte organiques Architecte services QA services QA architecture Création des services Création des grilles Création des classes applicatives Création des classes d’essais QA services QA Java Assemblage Groupe architecture Équipe réalisation Équipe réalisation Outil FIT Outil Junit QA Fonctionnel Équipe QA & Outil Selenium Équipe QA
  • La démarche préconisée au niveau de l’assurance qualité dév JAVA Tests unitaires automatisés Assemblage Résultat VERT Résultats ROUGE Exécution quotidienne Programmation Des interfaces Réalisation des interfaces et de l’orchestration des services dév JAVA Programmation Orchestration Programmation Des classes de tests unitaires Résultats ROUGE
  • La démarche préconisée au niveau de l’assurance qualité Dév RPG Testeur dév JAVA FIT Runner Charger JAR Assemblage Résultat FIT VERT Résultat FIT ROUGE SOA Exécute FIT Charger HTML SOA Exécute FIT Programmation Service Création tableaux FIT Programmation FIT Réalisation des services
  • La démarche préconisée au niveau de l’assurance qualité Intégration & QA continu Testeur Couche interfaces Couche orchestration Couche de services Compilation Junit Métriques Compilation Junit Métriques Compilation FIT Métriques Essais fonctionnels Enregistrement des scripts Selenium Construction & AQ quotidienne Construction & AQ quotidienne
  • La démarche préconisée au niveau de l’assurance qualité Métriques sur la qualité du code
  • La démarche préconisée au niveau de l’assurance qualité Métriques sur la qualité du code
  • La démarche préconisée au niveau de l’assurance qualité Création des tableaux FIT
  • La démarche préconisée au niveau de l’assurance qualité Résultats FIT
  • La démarche préconisée au niveau de l’assurance qualité Sommaire des essais FIT
  • La démarche préconisée au niveau de l’assurance qualité Essais fonctionnels
  • La démarche préconisée au niveau de l’assurance qualité Tests fonctionnels réussis
  • La démarche préconisée au niveau de l’assurance qualité Tests fonctionnels échoués
  • La démarche préconisée au niveau de l’assurance qualité
    • Les résultats
    X
  • Recommandations
    • Adoptez des outils d’automatisation de tests … mais le succès ne dépend pas que des outils, il faut adhérer aux meilleures pratiques de l’AQ
    • Adapter la structure de l’organisation pour inclure de l’AQ dans toutes les phases du cycle de développement
    • Prévoir les budgets pour implanter une infrastructure (environnement) de tests
    • Définissez une stratégie de tests dès le départ
    • Entreprendre un projet de gestion du changement étant donné l’implication de nombreuses équipes.
  • Questions