Discussion :

[Pinkwyzard]

Bonjour à tous ,

Je me tourne vers vous car, même après avoir relus les définition, je n'arrive pas à saisir la différence entre le Plan Assurance Qualité et le Plan Qualité.

si vous savez, n'hésiter pas.

Merci

[hegros]

Je ne sais pas s'il existe vraiment une différence fondamentale entre les deux en tout cas je crois qu'on peut dire qu'un PAQ (plan assurance qualité) peut avoir plusieurs noms. Un que j'utilise est plan de développement ce qu'on rédige en début de projet qui est en fait aussi un PAQ

[CinePhil]

Un peu d'histoire.... et pas seulement appliquée à l'informatique mais à tous les systèmes qualité...

En 1987 est née la série des normes ISO 9000, dont le trio ISO 9001, 9002 et 9003. Ces trois normes étaient des exigences en matière de système d'assurance qualité.
Dans la norme des définitions relatives à ce sujet (ISO 8402) se trouvait alors je crois la notion de Plan d'assurance qualité.

A la dernière révision de la famille ISO 9000, laquelle à vu la fusion du trio en une seule norme ISO 9001, on est passé au concept de système de management de la qualité.
Et dans les définitions, qui ont cette fois intégré l'ISO 9000 (ISO 8402 a disparu), on trouve la notion de Plan qualité.

En fait, ces deux notions recoupent bien la même chose : Les dispositions d'organisation spécifiques à un projet et qui précisent, complètent ou dérogent au système de management qualité de l'organisme.

Je n'ai plus la norme sous la main mais ça doit être grosso modo ça.

[sgirard2002]

bonjour,
le plan qualité précise les dispositions nécessaires pour mener à bien le projet.
le plan assurance qualité ne contient que les disposition inhérentes à l'assurance qualité.

la différence se voit plus facilement dans les normes aéronautiques comme la DO178B qui différencie les différents processus

SG / ingé qualité

[CinePhil]

Euh... ben là je ne vois pas la différence ! Et comme je ne connais pas la DO178B...

Tu peux développer STP ?

[sgirard2002]

en fait un plan qualité va définir l'ensemble des dispositions que tu t'engages à exécuter pour fournir le produit avec le niveau de qualité souhaité. Donc soit tu as 1 seul plan qui définit tes processus soit tu en as plusieurs suivant le volume :
- développement (=> tu produis quelque chose)
- vérification (=> tu vérifie ta production)
- gestion de configuration (=> tu mets tes produits et ta vérification en configuration)
- assurance qualité (=> tu t'assure par indépendance le respect de la planification, des normes à utiliser, et tu peux le prouver)

dans les normes aéronautiques on rajoute la partie "certification" (=> démonstration de conformité).

suivant la criticité des logiciels la planification est plus ou moins lourde. c'est normal, un logiciel qui peut tuer doit être réalisé avec plus de sécurité qu'un logiciel dont l'erreur ne provoque que des pertes financières.

l'erreur habituelle vient de la notion de qualité et d'assurance qualité :
1- la qualité est décidée par des managers
2- la qualité est exécutée par des opérationnels
3- la qualité est surveillée par l'assurance qualité (avec devoir de prévenance et proposition de solution)

j'espère que ça aura aidé à la compréhension.

NOTA : dans les applications de gestion (65% de l'informatique), la qualité n'a pas besoin d'un niveau très élevé (qualité = faire ce qu'il faut, ni plus ni moins)

[Frank]

Je dirais aussi que le Plan Assurance Qualité permet de définir plusieurs points importants relatifs au projet :

Les objectifs du PAQ
le domaine d'application du PAQ
La responsabilité de réalisation et de suivi du plan
la liste des documents applicables et de référence
les critères d'évolution du PAQ au cours du projet
la terminologie utilisée (pour être sur que nous avons tous la même compréhension des termes utilisés dans le PAQ)
Les métriques utilisées...

je viens d'avoir ma première partie de cours...

[hegros]

L'ISO propose un modèle de document qualité (trouvable facilement sur internet)qui reprends certaines choses que tu énonces Franck

De mémoire il doit y avoir une dizaine de chapitre avec en plus de ce que tu ne cites pas : Gestion de la configuration et gestion des fournisseurs

[Frank]

L'ISO propose un modèle de document qualité (trouvable facilement sur internet)qui reprends certaines choses que tu énonces Franck

De mémoire il doit y avoir une dizaine de chapitre avec en plus de ce que tu ne cites pas : Gestion de la configuration et gestion des fournisseurs

Oui, je sais, c'est pour le prochain cours..

[Franck SORIANO]

Personnellement, ma vision des choses est la suivante :

La "qualité" (et surtout sa perception) est une notion très relative qui dépend beaucoup de l'interlocuteur et du contexte. Pour un logiciel :
- La qualité pour un utilisateur c'est avant tout que le logiciel rende le service pour lequel il l'utilise tous les jours. En un mot le fonctionnel. Il faut que le logiciel facilite la vie de l'utilisateur. Et dans ce cas, même de nombreux bug ne sont pas nécessairement un gros défaut. Une fois que l'utilisateur a appris à les contourner, il finit par ne plus les voir...
- La qualité pour la production c'est une appli stable qui fonctionne toute seule. C'est un site qui ne tombe pas plusieurs fois par jour. Ce sont des serveurs qui n'ont pas besoins d'être redémarré tout le temps. C'est aussi une appli suffisamment légère pour ne pas nécessiter 50 000 machines à surveiller en permanence.
- La qualité pour le développeur, c'est un code facile à lire, à écrire et à maintenir. C'est une appli développée rapidement, en assemblant un maximum de composants tout faits. Peu importe ce qu'il y a derrière, peu importe si c'est une usine à gaz qui va consommer des ressources monstrueuses en production. Du moment que ce n'est pas le développeur qui écrit les boîtes noires, pour lui c'est simple, rapide à développer, facile à comprendre et à maintenir.... En plus c'est beau, c'est sexy, c'est à la mode, c'est génial ! Et peut importe le fonctionnel, ce n'est qu'un prétexte pour mettre en oeuvre son art !

Comme on peut le voir, les critères de qualités peuvent être multiples et variés, parfois même en contradiction les uns avec les autres.

Si on veut qu'un projet aboutisse et donne satisfaction, il faut commencer par définir nos attentes en termes de qualité : Quels seront les critères qu'on va retenir, quels seront leur importances relatives...
Ces choix pourront être différents d'un projet à l'autre. Tout dépend du contexte. Il faut donc commencer par établir un document qui va poser et définir ces choix (le plan qualité ?)

Une fois qu'on a posé notre définition de la qualité que l'on veut pour le projet, il reste à voir quelles dispositions on va prendre pour nous permettre de l'atteindre. On entre alors dans le domaine de l'Assurance Qualité (et du plan d'assurance qualité).

Mes cours d'assurance qualité commencent un peu à dater, mais je crois que ça colle assez bien à tout ce qui a été dit.

[hegros]

D'un point de vue ISO la qualité concerne 2 points :

1-La production du développement (analyse, conception, programmation, test...) qui concerne les activités de développement cela va sans dire

2-L'orchestrage du développement(objectif, estimation, planning, suivi/controle, documentation...) qui concerne les activités de pilotage de projet.


Aussi on parle aussi de qualité interne (comment est conçu le logiciel à l'intérieur : faible couplage, forte cohésion, la maintenabilité...) et de qualité externe (ce que perçoivent les utilisateurs : les écrans, l'utilisabilité, la facilité d'apprentissage...)


Il est possible de faire des arbres qualimétriques. Il me semble que l'ISO définit 12 facteurs et autant de critéres par facteur soit prés d'une centaine de combinaison possible à évaluer pour la qualité

[souviron34]

où l'on voit très bien qu'ISO ne se préoccupe en rien du produit/utilisateur final

...snip
....

très bon résumé...

[hegros]

Si souviron(produit et management).

Cela fait parti des 12 facteurs et 13 critéres de qualité comme la facilité d'apprentissage, l'ergonomie ou encore l'utilisabilité. Tout cela se préoccupe bien de l'utilisateur est c'est ISO.

[toudar]

D'un point de vue ISO la qualité concerne 2 points :

1-La production du développement (analyse, conception, programmation, test...) qui concerne les activités de développement cela va sans dire

2-L'orchestrage du développement(objectif, estimation, planning, suivi/controle, documentation...) qui concerne les activités de pilotage de projet.

Bonjour,

Je me permets d'intervenir sur ce fil pour vous demander si vous avez à disposition de la documentation pour mener à bien un développement d'une base de donnée.

En effet je développe dans une société qui est engagé dans la qualité, nous sommes certifié et on me demande maintenant de produire un tas de documents (à moi de les trouver, sinon c'est pas rigolo ) sur mon travail, rédaction des cahier des charges etc ...

Merci par avance. pour votre aide.

[souviron34]

par définition, si ta société est certifiée, elle les a.

[CinePhil]

Je me permets d'intervenir sur ce fil pour vous demander si vous avez à disposition de la documentation pour mener à bien un développement d'une base de donnée.

C'est par là ==> http://sqlpro.developpez.com/cours/modelisation/merise/

par définition, si ta société est certifiée, elle les a.

Pas forcément.
La norme ISO 9001 n'impose pas de moyens précis. C'est à l'organisme de définir ses propres documents nécessaires. Seuls le manuel qualité et quelques procédures purement d'aspect maîtrise de la qualité sont exigées. De mémoire (je ne suis plus qualiticien depuis plus d'un an et je n'ai pas l'ISO 9001 sous la main) :
- Maîtrise des documents ;
- Maîtrise des non-conformités ;
- Actions correctives ;
- Actions préventives ;
- Audits internes.

Ainsi, un organisme peut se contenter de décrire ses processus de manière graphique, avoir quelques formulaires (lesquels peuvent être informatisés) pour fonctionner et être quand même certifiée. Le temps des procédures documentées et détaillées est révolu depuis fin 2000 (jusqu'à la version 1994 des ISO 9001, 9002 et 9003, une vingtaine de "procédures documentées" étaient exigées).

Pour reprendre le cas de la conception des bases de données, l'organisme peut très bien dire à l'auditeur que c'est la méthode Merise qui est appliquée et l'auditeur pourra le vérifier en cherchant des MCD et des MLD dans les dossiers de projet qui lui seront présentés.

[souviron34]

Le temps des procédures documentées et détaillées est révolu depuis fin 2000 (jusqu'à la version 1994 des ISO 9001, 9002 et 9003, une vingtaine de "procédures documentées" étaient exigées).

Sniff.. Je suis vieux

Pour reprendre le cas de la conception des bases de données, l'organisme peut très bien dire à l'auditeur que c'est la méthode Merise qui est appliquée et l'auditeur pourra le vérifier en cherchant des MCD et des MLD dans les dossiers de projet qui lui seront présentés.

ce qui pour moi n'est pas une certification alors...

Nous sommes en plein dans les mêmes causes que les "audits ratés" des banques menant à la crise financière ou au scandale d'Enron...

[toudar]

Bonjour,

Merci beaucoup pour vos réponses.

En fait j'aurai dû préciser que nous sommes certifiés mais que nous sommes pas du tout dans le domaine de l'informatique, la certification ne porte pas sur le développement des bases mais sur l'ensemble des processus de notre société (argene).

Donc pour l'instant j'essaie de m'améliorer et je recherche donc désesperement des exemples de cahiers des charges pour un dév d1 bdd régidés pour m'en inspirer.

Merci encore.

[CinePhil]

Dans ce cas il faut t'adresser au forum Schéma.

Ton entreprise est certifiée sur l'ensemble de ses processus de production qui doivent être très documentés et régis par des cahiers de bonnes pratiques de laboratoire, comme dans toute entreprise de pharmacie. Mais l'informatique ne figure peut-être pas dans ces bonnes pratiques.

[toudar]

Merci beaucoup, je vais essayer de regarder ça le plus rapidement possible.