Les projets SI

Propriétaire du système : c'est le “client final” – celui qui repésente les utilisateurs, et l'utilisation du système. Il sera responsable de “ce qu'on fait avec le système” – des résultats et données contenues dans le système. C'est l'approbateur des “besoins utilisateurs” – et l'arbitre pour des choix. On peut avoir un propriétaire “dedié” projet. Il est responsable de la formation des utilisateurs.

Propriétaire de processus : propriétaire du ou d'un des processus à automatiser.

Le “responsable développement” ou “responsable support” (selon le cycle de vie du système). Il est responsable du bon développement du système et de son état validé…devant le propriétaire.

Unité qualité (selon le cas) : approuve certain documents clés et est chargé de la vérification du respect des réglements.

Le fournisseur : peut être un fournisseur de logiciel (COTS), ouun prestataire de service

Experts techniques – tous les documents techniques.

Qualité d'un système

• Un système de qualité est
  • un système qui fait de façon fiable ce pourquoi il est prévu
  • et qui continue à le faire de façon durable
• un des moyens d'y arriver est d'appliquer une démarche de validation…qui ne se limite pas au seul test.
• Rappel (ISO 9001:2008)
  1. Démontrer l'aptitude à fournir régulièrement un produit conforme aux exigences du client et aux exigences réglementaires applicables
  2. Chercher à accroitre la satisfaction dess cliend par l'application efficace du système, et en particulier, mettre en ouevre des processus d'amèlioration continue.

Le but de la planification de la validation est de trouver la meilleure démarche de construction et de validation possible, en fonction des enjeux et impacts du système.

Cette démarche de validation se base sur un nombre d'activités, et est à dimensionner pour chaque système!

La planification de la validation permet de dégager les axes plus ou moins prioritaires.

Une des base de la planification est de connaître “l'importance du système” afin de mettre l'effort au bon endroit.

Le plan de validation décrit les différentes activités, leurs enchainements,

Le plan de validation décrit le périmètre (par exemple interfaces inclus ou non) et tous les critères particuliers à remplir pour la mise en production.

On y trouvera également, dans le cas d'un système qu'on remplace, les éléments de migration éventuelle des données historiques.

Il décrit également la séquence et les enchainements des différentes étapes de validation.

Le plan de validation … démarré au début inclura les étapes de sélection du fournisseur.

Les activités de sélection/contrôle du fournisseur peuvent varier:

• selon l'impact du système sur
  • l'activité (stocks)
  • l'impact réglementaire
  • confidentialité
  • sécurité (HSE)
  • …
• selon l'expérience du fournisseur,
  • dans ce type de produit,
  • dans ce type d'industrie,
  • le nombre d'exemplaires vendus
  • certifications
  • …

Elles intègrent : une évaluation, ou un audit selon la criticité retenue. Cet audit peut être initial ou répété selon le type de maintenance choisi.

Il est donc important d'être rapidement sûr de la méthode de maintenance.

• les besoins explicites (fonctionnels)
• besoins implicites (ex suppression des données obsolètes)
• besoins dérivés : besoins de sécurité, par ex
• classement des priorités des besoins
• origine des besoin (ex. réglementation)
• besoins de performance qui permettent de définir mieux les mantenances fures (ex suvegards particulières)

Les besoins peuvent être révisés en fonction de l'avancement de la conception: par exemple pour “abandonner” des besoins ou les différer (versions ultérieures). Il faut documenter ces choix.

Les besoins utilisateurs sont d'une importance capitale, que ce soit pour l'achat de solutions ou le développement.

Ils sont le reflet de ce que veut le “client”

Ils ne sont pas forcément le reflet de ce que l'on confie à un intégrateur de système (lettre de mission ou contrat).

Ils sont impérativement approuvés par les responsable projets et propriétaire (+ qualité)

Ils permettent – déjà à ce stade là – de définir les tests (critères)! (cycle en v!)

Dans le conception du système

• On cherche la solution technique au problème du “client” (propriétaire)
• Souvent, à ce stade des itérations se produisent entre les besoins et la conception (besoins irréalisables techniquement, par ex)
• La conception du système se base à la fois sur une certaine part de standards techniques (impératifs de maintenance) si l'entreprise en a et des contraintes d'intégration dans le système d'information de l'entreprise. Il est impératif dans le cadre de ctte conception d'intégrer les architectes/urbanistes du système d'information si ceux-ci existent…
• La conception du système doit permettre de satisfaire les besoins clients y compris la performance, et de préparer les phases de maintenance.

Les éléments de conception doivent être documentés/

• pour préparer la construction et le développement
• pour pouvoir être utilisés lors des phases de maintenance

Un document souvent omis est très important, il s'agit de la vision d'ensemble du système. (résumé des fonctions et de l'architecture du système)

Les documents de conception sont également fonction des “documentations intégrées” des différents développements (ex dictionnaire des données)

Le niveau d'approbation des documents de conception est au minimum technique (par des experts du domaine) mais pourrait intégrer le propriétaire.

La conception du système comprend également les éléments de sécurité

• faut-il crypter certaines données ?
• quels sont les niveaux d'accès aux différents fonctions ?
• quels sont les processus d'administration de la sécurité ?
• quels sont les moyens de garantir la ségrégation des rôles ?
• quelles sont les règles d'archivage des données ?

On rappelle que la conception doit être traçable par rapport aux besoins!

Le développement du système se base impérativement sur une gestion de la configuration robuste.

• comment gérer les différentes versions
• y a-t-il des modules communs
• y a-t-il des risques de développement en parallèle
• comment gérer la mise en production

Les pratique minimales en ce sens s'accordent pour

• avoir des version logicielles répertoriées
• enregistrer ces versions au moment des différentes phases d'essai
• savoir gérer retours en arrière (sauvegardes)
• avoir des pratiques robustes d'analyse d'impact
• faire évoluer ces version lors des modification.

Exemple de pratiques à risque

Version existante : v1.0

• l'équipe projet travaille sur la nouvelle version du système. Le projet dure 8 mois. et intègrera de nombreuse améliorations fonctionnelles
• mais en utilisation il y a un bug

Plusieurs réponses

• tests de non régression
• l'identification de la version “origine” permet d'éviter l'écrasement de la correction
• les outils de gestion de config permettant de tavailler par checkout permettant de detecter au moment du dév qu'autre chose est en cours
• ségrégation des accès dév/prod

Les standards de développement permettent :

• un développement plus facilement maintenable, par d'autres personnes que les développeurs
• de rechercher plus facilement les “bogues”
• et d'éviter les bogues (développement plus réfléchi et plus propre)
• on peut avoir des standards de conception

La revue de code permet :

• de revoir la conformité au standard
• de vérifier la logique de certains modules (première phase de débogue)
• de vérifier la conformité à la conception voulue

• documentation en entête : num de version, l'auteur, la date, raison de modif, version de départ
• standards de nommage des modules, fonctions, variables, fonctions, classes, constantes
• standards de présentation
• standards de commentaires
• standards de message d'erreur (si besoin)
• pas de code mort

• primordiale si on réalise la maintenance en interne
• doit être réalisée suffisamment tôt, afin d'éviter de devoir accepter les erreurs car on est trop tard dans le projet
• ne trouvera que les erreur si les développeurs n'ont pas vu le standard avant
• doit être réalisée par une autre personne que le développeur
• pourrait être réalisée par le fournisseur : en fonction de ce que l'on en connait et de la maintenance voulue (idéalement, implication des personnes du support)
• si non corrigées les réserves doivent être connues et approuvées par le responsable de la maintenance.

N.B. les activités de développement sont “technique” (pas d'implication propriétaire).

Vision d'ensemble du test

Les tests permettent de

• détecter les erruers
• prouver que les besoins sont satisfaits
• conserver les preuves exigées per les réglementations si approprié

Les tests obéissent à la même logique que les autres éléments du cycle en V:

• un plan
• des activitées
• un rapport

suite à prendre dans le support du cours.

Le plan de test définit

• ce que l'on cherche à obtenir
• comment on va gérer les erreurs de test, qui les approuve
• comment on va (et si on va) gérer les scripts de test, qui les approuve, qui les exécute, qui les écrit
• les séquences des scripts
• les manières de vérifier
• que quelle installation le test est fait (installation doit être similaire à l'installation de production e l'impact des différences soigneusement analysé)

L'effort de test est variable. Ce qui permet de définir cet effort est:

• l'importance du besoin à tester
• la complexité technique des moyens mis en œuvre pour le satisfaire

Le niveau de détail de formalisation des test est également adaptable en fonction des exécutants et de la réglementation.

Dans la définition des tests, on pensera à définir quelles preuves de test on retient (dans le cas de systèmes réglementés).

• Idéalement l'installation du système utilisé pour le test a utilisé la même méthode d'installation que l'installation de production. Ceci permet de valider également la façon d'installer.
• La méthode d'installation doit être décrite et/ou automatisée ceci afin de pouvoir répliquer (plusieurs installations cas de sinistre conduisant à réinstaller, équipe support différente de l'équipe projet).
• Cette installation du système doit aussi traiter de l'infrastructure (on parle souvent d'infrastructure qualifiée)
• Cette bonne installation doit être vérifiée

Le rapport de test final doit statuer sur :

• les exécutions et le résultat des tests
• le traitement des problèmes
• le respect du plan de test

Il doit être approuvé par le propriétaire pour donner l'accord sur el résultat des tests ainsi que le responsable de support. Le propriétaire donne aussi son accord sur l'acceptation des points potentiellement non corrigés.

La qualité (si approprié) approuve également le document.

Afin de vérifier si le besoin est satisfait, il est nécessaire de construire la traçabiité entre les tests et les besoins.

Afin de pouvoir ajuster au mieux les tests, il est nécessaire de savoir comment on a répondu au besoin techniquement.

La traçabilité Besoin Conception – Test nous permet de faire ceci.

De plus elle sera utilisée pour :

• Faire des

La mise en place du système doit comprendre aussi l'ensemble des processus qui permettent son utilisation et sa maintenance.

Les sauvegardes et restaurations doivent être mises en place et vérifiées (NB pendant la phase projet aussi, ne pas la faire est risquer de perdre tout le travail déjà fait)

L'ensemble de la sécurité doit être décrit :

• quels sont les profils, que peuvent -ils faire
• quelle est la formation nécessaire à chaque profil
• quel est le processus d'attribution des accès, de revue des accès ?
• A-t-on prévu des antivirus ? Des accès externes ? Des accès clé USB ?

La criticité du système pour le propriétaire doit être étudiée impérativement, afin de voir, si en l'absence du système (cas de sinistre) il y a des moyens de continuer l'activité. Y a-t-il des processus dégradés à mettre en place, des moyens de “finir proprement” la production en cours?

Le point important est de savoir pendant combien de temps, le propriétaire peut fonctionner en fonctionnement dégradé (ou sans le système). NB en cas de restauration une perte de données peut arriver (données de la journée si restauration à l'état d'hier).

Le pire n'est jamais certain, mais il peut arriver!!

Ce point donne des éléments importants pour :

• la construction du système (tolérance aux pannes, systèmes à recouvrement automaitsés ou fonctionnement en doublon)
• Les attentes par rapport à des délais de reconstruction standard
• L'organisation en cas de crise
• Le retour à la normale

Le plan de continuité son documentés, et un test permet de vérifier s'ils sont réalistes.

Le plan de continuité d'un système peut aussi être questionné pour des aspects réglementaires.

Les activités de support, elles-même sont de plusieurs ordres :

• en premier lieu, basée sur l'expérience, une analyse des défaillances potentielles permettra d'ajuster les différentes opérations de maintenance et la structure de maintenance.
• Ces opérations de support vont du changement d'un périphérique (on pourra prévoir des périphériques déjà configurés en “spare” dans la zone d'utilisation) jusqu'à une reconstruction complète en cas de sinistre grave.
• L'opération de reconstruction doit être décrite et testée, elle doit répondre aux besoins client en termes de temps d'inutilisation maximale.
• Pour le test, elle doit être déroulée, de préferance par des personnes “non projet” ceci permettant

La partie “process” de support doit être étudié :

• à qui signale-t-on un problème? (numéro générique ou équipe de support dédié?)
  • quel est le processus d'escalade (problème non résolu)?
• yatil des priorités de problèmes ?
• yatil un support 24/7
• yatil de la maintenance préventive? qui est en charge?
• fait-on appel à des fournisseurs externes? yati un contrat?

L'acceptation du système correspond à la dernière étape avant utilisation. Elle permet de statuer sur

• la validation du système, ceci incluant tous les processus de support

On vérifie que l'ensemble des points identif… : la suite et fin.