Merge branch 'master' of github.com:Crocmagnon/Md-IUT-Cours
This commit is contained in:
commit
06efd3f5bc
3 changed files with 122 additions and 0 deletions
65
gpi/3-La_qualite.md
Normal file
65
gpi/3-La_qualite.md
Normal file
|
@ -0,0 +1,65 @@
|
||||||
|
# Que'est-ce que la qualité ?
|
||||||
|
La notion de qualité a évolué en informatique depuis 1951 :
|
||||||
|
|
||||||
|
- L'aptitude à l'usage (1951)
|
||||||
|
- La conformité aux spécifications (1979)
|
||||||
|
- L'aptitude à satisfaure le client (1984)
|
||||||
|
- L'anticipation des besoins (2000)
|
||||||
|
- La citoyenneté (2010 ?)
|
||||||
|
|
||||||
|
## Les 4 composantes de la qualité
|
||||||
|
|
||||||
|
- Qualité de définition
|
||||||
|
- Qualité de conception
|
||||||
|
- Qualité de réalisation
|
||||||
|
- Qualité de service
|
||||||
|
|
||||||
|
## Les enjeux de la qualité
|
||||||
|
### Enjeu pour le client
|
||||||
|
- La satisfaction
|
||||||
|
+ Il oublie le prix qu'il a payé
|
||||||
|
+ Il oublie le temps pendant lequel il a impatiemment attendu car prix et livraison n'ont lieu qu'une seule fois
|
||||||
|
+ Il se souvient des services qu'elle lui a rendus... ou refusés, car __l'usage est de tous les jours__.
|
||||||
|
- La fidélisation qui rapporte plus que la conquête
|
||||||
|
|
||||||
|
### Enjeu pour le collaborateur
|
||||||
|
- Implication : Toute personne peut contribuer à l'amélioration de son travail
|
||||||
|
- Un mangement mobilisateur
|
||||||
|
|
||||||
|
### Pour l'entreprise
|
||||||
|
- Du savoir faire et des économies, car c'est la non-qualité qui coûte cher :
|
||||||
|
+ 3.9% du CA
|
||||||
|
+ 10.6% de sa VA
|
||||||
|
+ 2/3 de son bénéfice brut
|
||||||
|
|
||||||
|
## La qualité du développement informatique
|
||||||
|
Deux angles pour un logiciel :
|
||||||
|
|
||||||
|
- Les fonctions qu'il réalise
|
||||||
|
- Les caractéristiques de l'utilisation qui comprend :
|
||||||
|
+ Ergonomie
|
||||||
|
+ Conditions d'exploitation
|
||||||
|
+ Correction des erreurs résiduelles
|
||||||
|
+ Évolutions fonctionnelles
|
||||||
|
|
||||||
|
## L'évaluation sur norme ISO 9126
|
||||||
|
### 6 caractéristiques
|
||||||
|
- Capacité fonctionnelle
|
||||||
|
- Fiabilité
|
||||||
|
- Facilité d'utilisation
|
||||||
|
- Efficacité
|
||||||
|
- Capacité à être maintenu
|
||||||
|
- Portabilité
|
||||||
|
|
||||||
|
### 21 sous-caractéristiques
|
||||||
|
#### Capacité fonctionnelle
|
||||||
|
- Aptitude : Les fonctions sont celles qui satisfont aux besoins exprimés et implicites pour des tâches données.
|
||||||
|
- Exactitude : La fourniture des résultats ou d'effets justes ou convenus. Par exemple, cela comprend le degré nécessaire de précision des valeurs calculées.
|
||||||
|
- Interopérabilité : Sa capacité à interagir avec des systèmes donnés.
|
||||||
|
- Conformité réglementaire : Respect de l'application des normes, des conventions, des réglementations ou des prescriptions similaires.
|
||||||
|
- Sécurité : Aptitude à empêcher tout accès non autorisé (accidentel ou délibéré) aux programmes et données.
|
||||||
|
|
||||||
|
#### Fiabilité
|
||||||
|
- Maturité : On s'intéresse à la fréquence des défaillances dues aux défauts logiciels
|
||||||
|
- Tolérance aux fautes : Que se passe-t-il si on utilise mal le logiciel, est-ce que le logiciel peut maintenir un niveau de service en cas de mauvaise utilisation ou de violation de son interface.
|
||||||
|
- Possibilité de récupération : Capacités du logiciel à rétablir son niveau de service et à restaurer les informations directement affectées en cas de défaillance. Mesure du temps et l'effort nécessaires pour le faire.
|
57
uml/1-diagrammes_de_classe_.md
Normal file
57
uml/1-diagrammes_de_classe_.md
Normal file
|
@ -0,0 +1,57 @@
|
||||||
|
# Diagramme de classe
|
||||||
|
On l'utilise pour montrer la structure statique du système et identifier les concepts propres au domaine (les concepts métier qui particient aux cas d'utilisation).
|
||||||
|
|
||||||
|
On l'utilise pendant tout le processus de modélisation. Les diagrammes de classe s'enrichissent : plus on avance dans la modélisation, plus ils sont détaillés.
|
||||||
|
|
||||||
|
Un diagramme de classe décrit les classes et les relations. Pour en construire un, il faut :
|
||||||
|
|
||||||
|
- Définir les classes et leurs responsabilités
|
||||||
|
+ Les classes -> Concepts métiers
|
||||||
|
+ Les attributs
|
||||||
|
+ Les méthodes
|
||||||
|
- Définir les relations entre ces classes
|
||||||
|
|
||||||
|
## Démarche
|
||||||
|
C'est un processus itératif : il faut itérer et affiner le modèle.
|
||||||
|
|
||||||
|
- Pas d'exactitude du modèle à la première réalisation
|
||||||
|
- Nécessité de réaliser des itérations continuelles
|
||||||
|
- Possibilité d'avoir différentes parties du modèle à différents stades d'achèvement
|
||||||
|
- Raffinements probables après l'achèvement d'autres modèles
|
||||||
|
|
||||||
|
On commence à un haut niveau d'abstraction, puis on enrchit le modèle
|
||||||
|
|
||||||
|
- Des données manipulées aux difféents éléments composant le système
|
||||||
|
|
||||||
|
## Démarche conseillée
|
||||||
|
- Identifier les classes et conserver celles qui sont pertinentes
|
||||||
|
+ Éviter d'être trop sélectif au départ
|
||||||
|
+ Éliminer les classes redondantes, sans intérêt
|
||||||
|
- Faire de même avec les associations
|
||||||
|
- Identifier les attributs
|
||||||
|
+ Ne pas pousser la recherche à l'extrême
|
||||||
|
+ Repousser les détails à plus tard
|
||||||
|
- Organiser et simplifier les classes en utilisant l'héritage
|
||||||
|
|
||||||
|
## Contenu du diagramme
|
||||||
|
### Classe
|
||||||
|
__Rappel :__ _Une classe est la description formelle d'un ensemble d'objets ayant une sémantique et des caractéristiques communes._
|
||||||
|
|
||||||
|
Dans le diagramme, on a trois compartiments différents : le __nom__, les __attributs__ et les __opérations__.
|
||||||
|
|
||||||
|
#### Le nom
|
||||||
|
Le nom doit être significatif et évoquer le concept décrit par la classe
|
||||||
|
|
||||||
|
#### Les attributs
|
||||||
|
De la forme `visibilité (+, #, -) nomAttribut : Type`.
|
||||||
|
|
||||||
|
On indique un attribut dérivé (qu'on peut calculer) par un `/` après la visibilité.
|
||||||
|
|
||||||
|
Les attributs de classe sont propres à la classe et non à l'objet. On les souligne.
|
||||||
|
|
||||||
|
Visibilité : private (-), public (+), protected (#)
|
||||||
|
|
||||||
|
### Associations
|
||||||
|
Les associations représentent des relations structurelles entre classes et objets.
|
||||||
|
|
||||||
|
On peut définir le rôle de la classe au sein d'une association. Les rôles agissent comme une propriété (un attribut). Ils peuvent donc avoir une visibilité.
|
Loading…
Reference in a new issue