2. Partie B : Description technique du marché
2.5 Description des marchés partiels
Concrètement, le marché peut se subdiviser en 7 marchés partiels : ces marchés partiels, qui délimitent l’étendue du marché, sont décrits en détail ci-dessous.
Le début des projets partiels doit être précédé d’une phase de prise de connaissance et d’analyse permettant au personnel du soumissionnaire de :
• prendre connaissance de la documentation existante,
• prendre connaissance des méthodes de travail utilisées,
• prendre connaissance des outils utilisés.
On peut escompter qu’un trajet de prise de connaissance de 20 jours minimum sera nécessaire pour prendre connaissance de et comprendre en détail la situation existante.
2.5.1
Marché partiel 1 : extension de la méthodologie FUP et implémentation ITIL
L’objet de ce marché partiel réside dans la mise en concordance de la méthodologie FUP et du processus ITIL ainsi que dans l’intégration du processus de développement d’application dans les processus d’ITIL change et de release management, le tout incluant l’harmonisation (avec éventuelle rationalisation et/ou intégration) des outils de gestion.
Le soumissionnaire joindra au FUP les descriptions de processus, les procédures et les délivrables de la discipline UP “Déploiement”. L’objet de la discipline réside dans la mise en production fructueuse de versions d’un produit et dans leur mise à la disposition des utilisateurs. Plus spécifiquement, dans le contexte du SPF, il s’agit d’élaborer le logiciel à partir des sources existantes des catalogues standard et de l’installer dans les différents environnements cibles du SPF.
Le soumissionnaire pourra éventuellement proposer des améliorations à apporter à la structure standard du projet, améliorations qui, pour le FUP, ont été définies dans le document FUP-Project Setup.
Cette réponse doit être complétée par la définition et par la création d’un système automatisé de Build Applications à partir du Standard code-source Catalogue Starteam du SPF. Ce système de
“développement” doit au minimum soutenir le cycle de vie des applications et implémenter un “modèle de promotion” qui lui corresponde.
(voir marché partiel 2)
L’intégration entre les procédures FUP et les procédures ITIL doit être clarifiée et exprimée en relation avec la bibliothèque de référence APM et avec les outils déjà implémentés par le service
d’encadrement ICT.
Il est possible de fournir une réponse aux besoins en matière de “Change Management” par
l’adjonction au FUP des descriptions de processus, des procédures et des délivrables de la discipline UP “Change Management” et, plus spécifiquement, de ceux qui se rapportent au “Configuration Management” pour les objets contribuant à l’élaboration des applications et au “Status &
Measurement Management”.
(voir marché partiel 3)
Documentation méthodologique et opérationnelle à produire
1) Une analyse détaillée du contexte et de la formalisation des besoins discutés avec le SPF sur le plan technique ;
2) Un document “FUP - D6 – Déploiement-Discipline” décrivant les processus de la discipline
‘déploiement’. Les conditions encadrant les déploiements vers les différents environnements doivent être décrites, avec une distinction entre les conditions génériques applicables à l’ensemble des projets et les conditions spécifiques qui concernent des projets déterminés ou des types de versions particuliers (bug-fix, par exemple) ;
3) Un document “FUP – D6 – Déploiement-Mode opératoire” décrivant les procédures à mettre en œuvre pour l’exécution des processus décrits au moyen du logiciel standard du SPF ; 4) Les documents “FUP-D6-Déploiement-Modèles/Templates” décrivant et formalisant les
outputs créés au moyen de la procédure décrite au point 3 ;
5) Un document décrivant les procédures automatisées qui permettent l’implémentation des procédures ;
6) Un document décrivant la transition entre la phase de projet (sous la direction d’un chef de projet) à la phase de “service operation” pour la gestion du service opérationnel (gérée par le fournisseur de services) ;
7) Un document “ FUP – D7 – Change Management- Discipline” qui décrit les processus de la discipline “Change Management” en répondant aux besoins explicités au point 5. Ce document pourra, de préférence, s’inscrire dans le prolongement des procédures de changement déjà décrites dans le cadre du Modèle d’Alignability Process ;
8) Un document “ FUP – D7 – Change Management-Mode opératoire” décrivant les procédures à mettre en œuvre pour l’implémentation des processus décrits au moyen du logiciel standard du SPF ;
9) Les documents “ FUP – D7 – Change Management- Modèles/Templates” décrivant et formalisant les outputs créés au moyen des procédures décrites au point 7 ;
10) La révision des documents FUP existants et impactés par les prestations décrites du point 2 au point 8.
Remarque importante #1 :
L’attention du soumissionnaire est expressément attirée sur le fait que l’on attend de lui que toutes les descriptions et analyses méthodologiques soient exécutées. La méthodologie doit être explicitée à l’aide d’exemples concrets, ce point faisant partie intégrante du marché.
Les changements au sein des outils automatisés (Borland Starteam, HP Openview Servicedesk, etc.) seront toutefois apportés par les administrateurs système des outils concernés. En ce qui concerne les changements apportés aux outils implémentés (Borland Starteam, HP Openview Servicedesk, etc.), l’on peut tabler sur l’assistance des administrateurs des outils du SPF Finances, le
soumissionnaire n’ayant ici qu’un rôle consultatif.
Remarque importante #2 :
Les documents fournis doivent respecter les versions standard en matière de mise en page et de présentation de la documentation FUP. Le soumissionnaire devra en outre les fournir au format WORD et au format DocBook. Des exemples de documents FUP standard sont disponibles sur le site Web du SPF Finances, via les liens suivants :
Nl : http://www.minfin.fgov.be/portail2/nl/modernisation/ict.htm Fr : http://www.minfin.fgov.be/portail2/fr/modernisation/ict.htm
2.5.2
Marché partiel 2 : automatisation totale ou partielle du déploiement à partir des répertoires de code source Borland Starteam
L’objet de ce marché partiel réside dans le développement et l’implémentation d’un jeu d’outils adapté permettant de réaliser le déploiement des applications sur la base des répertoires de code source Borland Starteam. Dans le cadre du présent marché, cet aspect ne concerne que les applications développées en Java et en SQL ; les applications écrites en PHP, COBOL ou autres langages sont exclues du champ du marché.
Le SPF Finances dispose déjà d’éléments permettant de simplifier l’automatisation des procédures :
• FUP-MO-D4-Buildscript.doc,
• FUP-Project Setup,
• l’Infrastructure et l’application de change management définis dans le Modèle “d’Alignability Process” et implémentés dans le HP Openview Servicedesk,
• le Delivery Management avec les fournitures d’applications ou de composants logiciels,
• le portail utilisateurs avec le “request center” et le catalogue de services.
Les versions actuelles des outils de développement sont :
• outils développés en J2EE : Ant, Maven2 (Maven 2 est le standard, Ant est obsolète mais toujours utilisé),
• répertoire source : Borland Starteam 2005/2008 sous Windows Server 2003,
• environnement cible : DB2 UDB v9.x, Weblogic 8.1 sp5, WebLogic 10.3, JBoss 4.2.2.
Le soumissionnaire décrira, sur la base des procédures et de la documentation existante, les
différentes phases du trajet qui permettront d’automatiser les procédures décrites ci-dessus ainsi que les résultats escomptés au terme de chacune d’entre elles.
Doivent, au minimum, être décrites les phases suivantes :
• Phase 1 : enregistrement des builds (ou de tous les éléments destinés au build) dans les répertoires Starteam par le biais de labels ou de views de versions univoques, en ce compris tous les éléments à mettre en œuvre lors du déploiement (manuels d’installation, etc.) ;
• Phase 2 : extraction des délivrables des répertoires Starteam, de préférence selon une méthode automatisée renvoyant de manière univoque à la totalité des composants de la livraison. La préférence est accordée à l’extraction des délivrables, ce qui conduit à un build automatique, avec activation automatique de tests unitaires et une interprétation automatique des résultats ;
• Phase 3 : livraison des composants d’application aux équipes techniques à titre de processus de changement et de mise en production fortement intégrés ou inclus dans l’outil de service management IT ;
• Phase 4 : révision minutieuse et univoque de la DSL (Definite Software Library, telle que décrite dans le processus de mise en production ITIL) et de la CMDB (Configuration Management database) en accordant la préférence à l’automatisation de cette phase.
Le soumissionnaire développera les procédures automatisées permettant d’exécuter ces phases et élaborera la documentation y afférente à l’intention des diverses personnes et services impliqués (chefs de projets, ICT-Operations, développeurs).
La description des différentes étapes doit être exhaustive et précise, afin de permettre aux équipes du SPF FIN d’en assurer la maintenance et la poursuite du développement par la suite.
2.5.3
Marché partiel 3 : implémentation des processus de changement et de mise en production (change & release) de l’application dans l’outil HP Openview Servicedesk
L’objet de ce marché partiel réside dans le développement de modèles (templates) de changement et d’ordres de travail permettant d’implémenter les processus de changement et de mise en production pour le déploiement d’application dans l’outil d’IT Service Management et de garantir que la CMDB permette de gérer les interdépendances entre les applications et de suivre les versions des
applications dans les différents environnements.
Les éléments suivants sont disponibles avant le début de ce marché partiel :
• une description très détaillée du changement et de la mise en production suivant le modèle d’Alignability process ;
• le catalogue des “requests for change” ;
• les modules destinés à la gestion de l’infrastructure et du changement d’application dans HP Openview Servicedesk ;
• l’application “delivery management” avec les méthodes de travail actuelles pour la fourniture d’applications ou de composants d’applications sur la plateforme CCFF ;
• un portail utilisateurs avec le “request center” et le catalogue de services.
Le soumissionnaire procédera à une analyse de la situation existante et proposera les améliorations, intégrations, extensions et/ou rationalisations nécessaires. Tous les éléments doivent être fournis pour l’implémentation des processus de changement et de mise en production dans l’environnement standard de l’IT Service management.
2.5.4
Marché partiel 4 : organisation pratique et coaching des testeurs d’ICT-Applications
L’objet de ce marché partiel réside dans le développement d’une méthode de travail pratique pour l’exécution de tests d’acceptation et la prestation d’une assistance dans l’exécution quotidienne des tests à une équipe de testeurs d’acceptation (encore à constituer) au sein du département ICT-Applications.
Au cours des dix-huit derniers mois, un grand nombre de collaborateurs du SPF Finances ont été recyclés pour s’orienter, à partir de la fonction de développeurs COBOL, vers des métiers IT impératifs dans le cadre du développement et de la maintenance des applications développées pour la mise en œuvre de la réforme CoperFin au sein du SPF Finances.
Il s’agit essentiellement des métiers IT suivants :
• analyste
• concepteur
• développeur front office
• développeur back office
• testeur
Plus de 100 personnes au total ont été formées, dont 30 pour le profil de testeur.
Ce marché partiel se concentre sur la fonction de testeur, et plus particulièrement sur la prestation d’une assistance dans l’organisation de leurs activités au bénéfice de ces testeurs récemment formés.
L’assistance doit comporter, entre autres, les éléments suivants :
• mise au point et utilisation d’un plan de test d’acceptation, définition des moments de test incluse ;
• utilisation pratique d’un plan de test d’acceptation (tel que défini dans FUP) ;
• utilisation pratique de notes de mise en production pour la définition du contenu des scénarios de test ;
• utilisation pratique de scripts Loadrunner et QuickTest pour les tests d’acceptation, les tests de non-régression et les tests de chargement ;
• utilisation de l’environnement de test ACC et coordination avec les équipes opérationnelles (middelware team, database team, monitoring team) pour la réalisation des tests ;
• gestion pratique des ensembles de test, des données de test et de scripts d’ensembles de test ;
• sélection de scripts réutilisables pour un monitorage d’application end-to-end dans la phase de production et fourniture de ces scripts au monitoring team ;
• reporting des anomalies détectées ;
• accréditation des versions logicielles.
Le SPF Finances attache une grande importance à un cycle de développement interactif. Plusieurs moments intermédiaires (milestones) sont en principe prévus pour les tests d’acceptation dans la méthodique de développement et l’approche du projet.
Ces moments de test intermédiaires doivent permettre :
• de détecter à temps les retards dans le cycle de développement si des moments de test (milestones) ne sont pas organisés ; ces retards doivent être signalés comme des “feux clignotants” au chef de projet et au PMO central ;
• d’évaluer le logiciel implémenté par rapport à l’architecture proposée initialement ; la détection automatique de certaines dérogations à l’architecture (par exemple des interdépendances d’éléments spécifiques à la plateforme) doit primer ; les anomalies doivent être signalées à l’architecte du logiciel et au team CCFF central.
• de procéder d’emblée à des tests partiels et unitaires dans le but de détecter le plus tôt possible les problèmes et d’obtenir une première indication concernant la qualité des ensembles de test de l’application fournie.
2.5.5
Marché partiel 5 : assistance dans la mise au point de méthodes de travail automatisées dans le but de maintenir les environnements de
développement et de packaging de l’équipe de développement à jour et en situation de cohérence avec l’environnement de production
L’objet de ce projet partiel est de fournir une assistance dans le développement d’une méthode pratique permettant de maintenir à jour les environnements de développement utilisés par les équipes de développement logiciel et de garantir la cohérence entre les plateformes de développement et de production.
Concrètement, il s’agit de procéder à des actualisations des versions du logiciel de base (systèmes d’exploitation, serveurs Web, serveurs d’applications, serveurs de bases de données) et des composants centraux de développement d’applications (CCFF framework, primitifs d’accès aux données, etc.).
Dans la pratique, on constate dans un certain nombre de cas que le flux entre les versions
d’applications de l’environnement de développement vers l’environnement de production n’est pas optimal. La plupart des manquements sont causés par un packaging erroné, des chemins de classes erronés, des db scripts inadaptés, etc.
Une des causes réside vraisemblablement dans le fait que les environnements de développement sont gérés par les équipes de développement, alors que les environnements TEST, ACC et PROD le sont par les équipes techniques opérationnelles. Il en résulte que la plupart des environnements de développement en restent à la version initiale de la configuration, alors que l’environnement de production évolue en permanence. Bien évidemment, cette situation génère des différences entre les environnements, ces différences n’apparaissant au grand jour que lors des nouvelles livraisons afférentes aux applications.
L’objectif poursuivi est celui d’une meilleure fluidité dans la transition des versions des applications des environnements de développement vers l’environnement de production. La mesure dans laquelle il est possible de remédier à ce problème sera étudiée en :
• rendant les configurations des divers environnements visibles clairement et dans les détails pour les équipes de développement par le truchement de la consultation de la CMDB centrale ;
• mettant en place un mécanisme de mise à jour “semi-automatique” des environnements de développement grâce à l’actualisation périodique (à l’initiative des équipes techniques opérationnelles) des versions du logiciel de base et des composants de base des
environnements (CCFF framework, primitifs d’accès…) vers un niveau égal ou comparable au niveau de la production. Cette mise à jour inclut également l’actualisation des templates destinés aux machines virtuelles mises à la disposition des développeurs actuellement.
Dans ce cadre, le soumissionnaire n’aura qu’un rôle purement consultatif.
2.5.6
Marché partiel 6 : formation et coaching des équipes concernées
L’objet de ce projet partiel est de pourvoir à la formation et au coaching (en collaboration avec la ICT Academy du SPF Finances) des équipes de développement et équipes techniques concernées.
Le département ICT du SPF Finances comporte une entité (la ICT Academy) chargée des formations internes des collaborateurs ICT. Parallèlement à une série de formateurs permanents, la ICT
Academy recourt fréquemment aux services de formateurs occasionnels provenant du SPF Finances et d’ailleurs. Les cours sont dispensés dans la langue des participants et sont (presque toujours) organisés dans les locaux du North Galaxy, avenue du Roi Albert II 33, 1030 Bruxelles.
La ICT Academy propose les services suivants pour l’organisation de formations :
• gestion et révision du catalogue “NEEVA” des formations disponibles ;
• soutien logistique par la mise à disposition des participants aux cours de locaux de formation, de projecteurs et de PC ;
• organisation pratique des cours : convocation des participants, tenue des listes de présence, gestion du calendrier, copie du matériel didactique, etc.
Le soumissionnaire doit, dans le cadre de ce marché partiel, assurer la formation des :
• équipes de développement du SPF Finances, avec une attention particulière accordée aux architectes impliqués dans le packaging des applications et dans le lancement des tests d’acceptation ainsi que dans le trajet menant à la production ;
• équipes techniques du SPF Finances impliquées dans le déploiement des applications au sein des environnements INT, ACC et PROD ;
• chefs de projets du SPF Finances et des chefs de projets des sous-traitants du SPF Finances impliqués dans un ou plusieurs projets de développement.
La formation doit se rapporter aux éléments développés dans le cadre des projets partiels 1 à 5.
L’on attend du soumissionnaire un training qui mette fortement l’accent sur l’utilisation pratique des outils développés.
Le soumissionnaire doit fournir les diapositives des présentations et pourvoir à la conception du matériel didactique (par exemple d’une application type servant d’exemple parcourant le trajet de test et de développement).
Le soumissionnaire doit tenir compte du fait que la formation doit être dispensée à 20 groupes (10 groupes néerlandophones, 10 groupes francophones).
2.5.7
Marché partiel 7 : mesure de la performance et de la maturité du processus de déploiement
L’objet de ce projet partiel réside dans le développement d’une méthode de mesure permettant de monitorer le processus de déploiement au moyen d’indicateurs de performance clés (KPI) adaptés donnant des indications relatives à l’avancement et à la qualité du processus de déploiement de l’application.
Le service d’encadrement ICT du SPF Finances monitorer l’avancement du processus de déploiement au moyen d’indicateurs de performance clés (KPI).
Les KPI développés tiendront compte, au minimum, des dimensions suivantes :
• la complexité du déploiement
4 types de déploiement peuvent être distingués dans les KPI :
• first releases
• major releases
• minor releases
• bug fixing
• par plateforme technologique
On n’emploie pas partout les mêmes processus de déploiement. Le contenu peut, dans le cadre du présent marché, se limiter aux environnements Java/SQL de la plateforme ATLAS.
• la qualité du déploiement en fonction de mesures objectives pouvant inclure entre autres :
• les résultats des tests d’intégration et d’acceptation,
• le nombre d’itérations des fournitures avant que l’application puisse être mise en production,
• l’augmentation ou la diminution des erreurs http après la réception,
• l’augmentation ou la diminution des erreurs dans les logs techniques et fonctionnels,
• l’augmentation ou la diminution des temps de réponse et de la disponibilité,
• …
Il est en outre, dans ce cadre, expressément renvoyé aux KPI relatifs au change management et au release management prévus dans “l’Alignability Process Model” et aux KPI afférents aux processus CobiT AI6, AI7 et DS9.
Les KPI doivent fournir des indications relatives au caractère souhaitable d’une révision post-implémentation pour certains changements et déploiements.
L’on attend du soumissionnaire la réalisation d’une implémentation des KPI dans le cadre de laquelle les sources des données doivent être identifiées et les visualisations de données voulues
développées, le tout s’accompagnant d’un reporting périodique du processus adapté (avec descriptif détaillé des déploiements en cours au moment du reporting et courbes graphiques montrant
l’amélioration ou la régression du temps écoulé et de la qualité).