• Aucun résultat trouvé

III. DESCRIPTION DES EXIGENCES TECHNIQUES

III.3 D ESCRIPTIF DE LA DEMANDE

III.3.1

Contexte global

Le SPF met de nombreuses applications à la disposition des fonctionnaires, des citoyens et des entreprises.

Ces applications, aux fonctionnalités étendues, s’appuient sur un environnement technique complexe. De plus, ces applications doivent pouvoir répondre simultanément aux demandes d’un grand nombre d’utilisateurs. A titre d’exemple, Tax-On-Web doit permettre, en période de pointe, de traiter 12 déclarations IPP (Impôt sur les personnes physiques) par seconde avec un temps de réponse garantissant un confort d’utilisation suffisant.

En parallèle, le SPF a mis dernièrement en œuvre plusieurs projets ayant pour objectif de systématiser et d’industrialiser les activités de contrôle de qualité des logiciels développés par des équipes internes ou externes. On peut notamment citer, outre la systématisation des tests de performances automatisés et la mise en place d’un Test Competence Center, le déploiement d’outils d’analyse de qualité automatisée de code Java…

C’est dans ce contexte que la division ICT-Infrastructure est chargée de valider les performances des applications mises à la disposition des utilisateurs. Une équipe interne dédicacée utilise HP Performance Center pour définir, développer et exécuter, en collaboration avec l’équipe projet et les divisions ICT concernées, les scénarios de tests. Cette même équipe est chargée d’analyser les résultats et d’en effectuer le rapportage auprès du comité de pilotage des projets concernés. Le suivi de l’exécution et l’analyse des résultats est effectué en collaboration avec un SPOC dédicacé d’ICT-Opérations. Actuellement, cette équipe se compose d’un informaticien-chef de projet, d’un expert ICT senior. Deux experts ICT juniors apportent ponctuellement leur soutien à ces deux personnes. Lors de l’exécution des tests, l’équipe travaille en étroite collaboration avec les différents centres de compétence des divisions Infrastructure et Opérations pour monitorer le déroulement des tests et analyser les résultats obtenus.

Après une période de démarrage ayant permis en 2010 de valider, entre autres, les performances de l’application Tax On Web 2010, cette phase de tests de performance est devenue un point de passage obligé pour les applications stratégiques du SPF. Les campagnes de test 2011 permettront, notamment, de valider les applications STIPAD et STIMER. On constate également une demande accrue de tests de validation de certaines composantes de l’infrastructure ICT (Filenet,...) et en parallèle, des besoins de tests spécifiques de certains composants applicatifs (signature digitale,…). Cette augmentation du nombre d’applications à traiter, ainsi que leur complexité croissante, fait donc apparaître des besoins de support dédicacé à ces activités.

Dans ce contexte, le SPF souhaite définir un processus efficace de gestion et d’exécution de tests de performance. Ce processus devra définir les tâches de l’équipe de tests ICT-Infrastructure, et décrire les interactions avec les autres divisions et entités du SPF concernées. Ce processus devra être compatible avec les processus développés dans le contexte du centre de compétences TCC d’ICT-Applications, ainsi qu’avec les processus ITIL d’ICT-Operations. Il sera également nécessaire de former les testeurs à l’utilisation de ces processus et des outils qui y sont associés.

L’expérience acquise au cours de projets similaires à celui décrit dans ce cahier des charges montre que l’aide et le coaching fournis par des experts des logiciels HP Performance Center est parfois indispensable pour permettre l’exécution d’une campagne de tests concluante. Le SPF souhaite donc pouvoir disposer de l’assistance ponctuelle d’experts HP Performance Center pour pouvoir coacher les membres de l’équipe tests dans la rédaction de scripts de test complexes.

L’expérience acquise par l’équipe SPF au cours des campagnes de test effectuées en 2010 montre que, fréquemment, plusieurs campagnes de test doivent être exécutées simultanément. Dans cette situation, il peut être nécessaire de faire appel temporairement à des ressources supplémentaires. Le SPF souhaite pouvoir faire appel à un ou plusieurs experts pour faire face à un besoin temporaire par rapport à un projet spécifique, et ce dès le démarrage du projet.

III.3.2

Plateforme de testing

Le SPF Finances veut consolider son expertise dans le domaine de testing de performance pour répondre aux missions citées plus haut.

Pour cela, le SPF souhaite s’appuyer sur les compétences et les outils déjà présents, sur la discipline D5 définie dans FUP. Ceci permettra de garantir l’adéquation de la solution retenue avec les autres disciplines de la méthodologie FUP et les outils permettant de la mettre en oeuvre.

Le SPF souhaite également rester compatible avec les résultats obtenus par le TCC d’ICT-Applications. Ce Testing Competence Center est organisé autour de la méthodologie T-Map, adaptée pour prendre en compte les spécificités de l’organisation du SPF, ainsi que de la méthodologie FUP.

Le testing de performances étant aussi un effort de génie logiciel, il est logique de trouver les pratiques communes habituellement utilisées dans le développement aussi dans les efforts de testing de performance : analyser et planifier, estimer les efforts de testing, gestion de configuration, mesures, outils et procédures.

III.3.3

Methodologie de testing

L’objectif majeur pour la mise en place de ce Performance Test Center est d’améliorer la stabilité et la performance des applications livrèes, ainsi que de l’infrastructure technique sur lesquelles elles s’appuient.

Ces applications peuvent être aussi bien des applications développées sur mesure pour le SPF que des packages COTS paramètrisés pour répondre aux besoins spécifiques du SPF.

Dans ce contexte, la définition d’une méthodologie structurée orientée vers les tests de performance est donc un point de passage obligé dans la mise en place du Performance Test Center.

Pour ce faire, il faut également prendre en compte l’approche T-MAP mise en place pour le Test Competence Center d’ICT-Applications.

Le soumissionnaire devra décrire les processus adaptés au contexte spécifique des tests de performance en décrivant les techniques pratiques utilisées pour certaines activités clés : le planning, l’analyse, le design, l’exécution, la gestion des risques, la définition des métriques et mesures, la gestion de configuration du testware…

Le soumissionnaire devra décrire les techniques et activités prévues dans sa méthodologie pour des projets de tests de performance. Pour cela, il tiendra compte des différents types d’activités du centre de compétence : tests de scénarios business, tests d’éléments d’infrastructure (Filenet, IAM,…), tests de composants d’application (signature digitale),….

Le soumissionnaire devra fournir des suggestions de Quick Wins pouvant être applicables à l’organisation actuelle, avant la mise en place de la solution définitive qu’il propose.

Le soumissionnaire devra indiquer comment les spécifications non-fonctionnelles liées à la performance sont suivies et communiquées aux acteurs concernés, et ce tout au long du cycle de vie de l’application. Il s’appuiera pour cela sur le cycle de vie FUP, ainsi que sur les déliverables associés.

Le soumissionnaire accordera une attention particulière aux interactions entre le centre de compétence et les différents intervenants (ICT-Operations, équipe projet), ainsi qu’aux problèmes liés à l’exécution des tests de performance dans des environnements complexes, dont les composantes peuvent avoir un cycle de vie distinct de l’application testée. Il proposera des mécanismes de communication et de synchronisation permettant de limiter l’impact de ces problèmes.

Le soumissionnaire portera également une attention particulière à l’intégration des outils de test avec les logiciels de monitoring utilisés par ICT-Opérations (HP OpenView).

III.3.4

Organisation du Performance Test Center

Le Performance Test Center est une unité de la division ICT Infrastructure. Cependant, ses travaux se dérouleront en interaction étroite avec d’autres acteurs du service d’encadrement ICT et d’autres services opérationnels.

Au cours de la préparation des tests de performance, l’unité travaillera en étroite collaboration avec l’équipe projet ICT et Business afin de définir les objectifs de la campagne de tests.

Au cours de l’exécution des tests de performance, cette unité travaillera en étroite collaboration avec la division ICT-Operations et l’équipe projet ICT.

Au cours de l’analyse et de la publication des résultats, l’unité travaillera en étroite collaboration avec les trois acteurs nommés précédemment.

Le soumissionnaire devra proposer une structure d’organisation qui tienne compte de la double mission du Performance Test Center : validation indépendante et assistance aux projets

Le soumissionnaire devra clarifier les rôles des différentes divisions tout au long du cycle de vie d’un projet de testing de performance.

Le soumissionnaire devra définir les différents rôles prévus par la méthodologie adaptée.

L’adjudicataire devra clarifier et préciser, lors de l’initiation du projet, la vision et les missions du Performance Test Center. Ces visions et missions seront communiquées au reste de l’organisation.

III.3.5

Processus et outils de support

Une bonne exécution des activités de testing suppose l’exécution d’activités de support. Ces activités de support devront être limitées à celles qui ont une valeur ajoutée dans le cycle de test.

Gestion de configuration

Le soumissionnaire décrira le processus de gestion de configuration utilisé dans un projet de testing de performances et les métriques utilisées pour le suivi de la qualité. Il mettra en évidence les problèmes liés à l’évolution de l’application, des jeux de données traités par celle-ci, ainsi que de l’environnement d’exécution au cours de la campagne de tests.

Support par l’outil de testing

Le SPF Finances utilise en standard HP Performance Center 9.52 pour le testing de la performance. HP Quality Center est utilisé comme outil de suivi des activités de testing. Il faut noter que l’évolution vers Performance Center 11 aura probablement lieu au cours de 2011.

Si une adaptation de l’outil peut s’avérer nécessaire pour supporter les activités du performance Test Center, le soumissionnaire peut faire des suggestions et recommandations quant à l’utilisation de l’outil.

Gestion de la communication

Afin de favoriser l’interaction avec le reste de l’organisation, un plan de communication doit être établi comprenant par exemple : le reporting vers le management, le reporting vers les autres divisions, le reporting vers les projets, la communication au sein de l’équipe. Le soumissionnaire portera également une grande attention à la communication nécessaire vers les équipes projets pour lesquelles le PTC effectuera les tests.

Gestion de la qualité

Un des objectifs du Test Competence Center est d’améliorer la qualité des applications par une validation indépendante. Le centre doit aussi garantir la qualité de ses activités.

Le soumissionnaire devra décrire comment la méthodologie proposée assure la qualité des processus qu’elle met en œuvre.

Le soumissionnaire fournira un PQP pour l’implémentation de la méthodologie et la mise en place du Performance Test Center (voir plus loin)

Mesures et validation

Pour pouvoir mesurer et suivre la qualité des activités de testing, des applications testées et pouvoir améliorer le processus, il est utile que certaines métriques soient mises en place et que certaines mesures soient communiquées régulièrement aux acteurs concernés :

Le soumissionnaire devra décrire les principales métriques prévues dans sa méthodologie et les techniques utilisées pour réaliser ces métriques. Pour définir ces métriques, le soumissionnaire tiendra compte de l’architecture d’entreprise du SPF.

Base de connaissance et aide en ligne

Le Performance Test Center doit disposer de toute la documentation nécessaire sur les processus, les procédures les Faq, bref toute info dont il a besoin pour remplir sa mission. Cette base de connaissance doit être centralisée, accessible à tout moment par toute l’équipe, avec des possibilités de recherche étendues.

Le soumissionnaire devra décrire comment il compte réaliser cette base de connaissance Portail/Dashboard

La communication avec le reste de l’organisation peut se faire à un haut niveau où les résultats des tests sont communiqués et un suivi de la qualité des applications testées. Pour l’équipe du Performance Test Center, ceci constitue aussi un guichet unique par lequel ils peuvent accéder à leur espace de travail.

Le soumissionnaire proposera les recommandations et suggestions pour réaliser ce genre de guichet unique

Gestion des données et environnement de test

Au vu des dépendances citées plus haut et l’interaction avec le reste de l’organisation, il faudra déterminer des protocoles d’interaction avec les divisions directement impliquées dans le testing de performances.

La préparation des données de test doit pouvoir répondre à des contraintes légales (privacy), techniques (volume et disponibilité de données) et organisationnelles. Les testeurs doivent être en possession des données correctes, cohérentes et représentatives des différents niveaux de test à réaliser. Dans ce contexte, le soumissionnaire est invité à prendre connaissance du cahier des charges « Test Data Management Tools » publié par le SPF.

Il est important de rappeler dans ce contexte que les testeurs ne disposent pas de la connaissance

« métier » des applications qu’ils doivent tester. Donc, le choix et la définition de ces jeux de données restera du ressort de l’équipe projet concernée.

Le soumissionnaire devra définir la stratégie appropriée pour une gestion efficace des données de test.

Le soumissionnaire devra faire des recommandations sur l’utilisation et la gestion des environnements de test, dédiés ou par le Performance Test Center et les équipes de développement. Il indiquera également comment les interactions avec la division ICT-Operations, qui gère ces environnements, seront traitées.

III.3.6

Implémentation de la plateforme de testing

LE SPF souhaite que le soumissionnaire mette en œuvre une approche pragmatique qui exploitera les compétences déjà présentes, exploitera les leçons tirées des activités actuelles de l’équipe « Tests de performance », et structurera les processus de travail devant être mis en œuvre. Tout ceci, bien évidemment, en respectant les fondements ICT déjà présents ou en cours d’implémentation.

Le SPF demande que l’équipe du soumissionnaire qui participera à cette implémentation réponde au profil suivant :

• Expérience dans la mise en place de méthodologies de testing dans un environnement technique et organisationnel similaire à celui du SPF

• Expérience prouvée de l’utilisation des outils standards du SPF : HP Performance Center

Le soumissionnaire justifiera ces différents points au moyen des CVs standardisés présentés en annexe D.

Le SPF donne préférence à une implémentation par phases :

• Prise de connaissance de l’existant (FUP-D5, TCC, « lessons learned » des campagnes de tests de performance antérieures,…)

• Analyse de l’écart entre FUP-D5, TCC, le fonctionnement actuel de l’équipe « tests de performance » et la méthodologie proposée.

• Propositions d’amélioration et implémentation : Sur base de l’analyse d’écart, une proposition d’amélioration et d’implémentation sera soumise au SPF pour accord.

• Phase pilote : l’implémentation de la solution d’amélioration se fera sur un projet à déterminer par le SPF Finances. Ce projet sera représentatif des projets SPF, tant dans son environnement technique que fonctionnel. L’expérience de la phase pilote permet d’ajuster la méthodologie et l’organisation du Performance Test Center. C’est dans cette phase aussi que les différents besoins en ressource seront clarifiés et consolidés. Cette phase pilote donnera lieu à une décision Go/No Go du comité de pilotage du projet. De cette décision dépendra le roll-out complet du projet. Cette phase pilote durera au maximum 6 mois calendrier à partir de la notification du marché. En cas de NO GO, le SPF ne passera pas à la phase de roll-out complet et ne commandera pas les prestations associées.

• Roll-out complet : Les différents aspects de la méthodologie sont implémentés et les services de testing sont ouverts à tous les projets. Le roll-out complet doit avoir terminé dans les 36 mois suivant la notification de l’attribution du marché.

En parallèle, le SPF souhaite pouvoir disposer au cours de ce trajet, de prestations de coaching et d’accompagnement assistant les testeurs dans la mise en œuvre de la méthodologie de test et des outils correspondant, le soumissionnaire fournira des prestations de coaching. Ce coaching devra tenir compte des spécificités de l’équipe initiale (testeurs senior et junior) et devra être d’un niveau adapté à celles-ci.

Le soumissionnaire décrira un plan de coaching initial, cohérent avec les formations dispensées et la stratégie d’implémentation de la méthodologie.

Le soumissionnaire devra décrire, dans un plan global reprenant tous les aspects d’un projet d’implémentation, son approche pour l’implémentation de cette plateforme de testing. Il y reprendra aussi le plan de formation et coaching du Performance Test Center.

Le soumissionnaire devra prendre en compte le fait que le noyau du Performance Test Center est constitué de l’équipe qui, actuellement, réalise les tests de performance à la demande des projets. Il n’est donc pas envisageable de compter sur une disponibilité totale de cette équipe pour les activités liées au projet pilote, à la mise en place du Performance Test Center ou aux formations. Cette disponibilité pourra être influencée par les besoins opérationnels du SPF. Le soumissionnaire devra tenir compte de ce facteur dans le planning de ses activités.

Documents relatifs