Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

m2ilc:qualite_3 [2011/01/14 11:13]
suitable
m2ilc:qualite_3 [2011/01/14 12:01] (Version actuelle)
suitable
Ligne 209: Ligne 209:
  
 FIXME suite à prendre dans le support du cours. FIXME 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).
 +
 +=== Installation du système ===
 +
 +  * 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 FIXME
 +  * 
 +  * 
 +
 +==== F. la préparation du support ====
 + 
 +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 ?
 +
 +=== 2 ===
 +
 +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!!
 +=== 3 ===
 +
 +
 +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.
 +
 +=== 4 ===
 +
 +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 FIXME
 +
 +=== 5 ===
 +
 +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?
 +
 +==== G. L'acceptation du Système ====
 +
 +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... FIXME : la suite et fin.
  
 ==== Les différents processus de maintenance ==== ==== Les différents processus de maintenance ====
 
m2ilc/qualite_3.txt · Dernière modification: 2011/01/14 12:01 par suitable
 
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki