Add second part of needs article
This commit is contained in:
parent
78ded52610
commit
6317896a16
1 changed files with 84 additions and 0 deletions
|
@ -110,3 +110,87 @@ Un bon exemple de décomposition reste les options associés à la commande `ls`
|
|||
En plus de la décomposition, il est important de **caractériser** un besoin en
|
||||
le qualifiant et l'associant à des *domaines de fonctionnements stricts*, à des
|
||||
*contraintes de faisabilités*, etc.
|
||||
|
||||
## Caractérisation des besoins
|
||||
|
||||
comme nous l'avons vu les besoin peuvent être décomposés, mais ils peuvent être
|
||||
aussi **caractérisés** : qualifiés, assocoés à des domaines stricts de
|
||||
fonctionnement, des contraintes de faisabilité etc,
|
||||
|
||||
Pour caractériser et préciser les besoins nous avons besoin:
|
||||
|
||||
* *domaine de fonctionnement**: maîtrise de ce que l'on développe en accord
|
||||
avec le domaine, c'est une part essentielle pour *les tests*. Le vocabulaire
|
||||
doit être choisi avec précision et justifié. Les mots *protocole*, *donnée*,
|
||||
*format*, *configuration logicielle*, *serveur* soivent être justifiés et
|
||||
précisés. Les domaines de valeurs des entrées et sorties soivent être décris
|
||||
et bornés;
|
||||
* *attributs, qualifications, évaluations* de la performances, robustesse,
|
||||
sécurité. Cette partie nécessite de la précision et qualifiés (unité de
|
||||
mesure, taille, confiance);
|
||||
* *faisabilité*: par exemple le réalismes graphiquedans les jeux des années 90
|
||||
était infaisable à la vue des contraintes techniques;
|
||||
* *décrire les difficultés et risques* associés.
|
||||
|
||||
### Par les stories
|
||||
|
||||
Nous pouvons exprimer des besoins en racontant des "histoires", on imagine des
|
||||
scénarios en tant qu'utilisateur par example:
|
||||
|
||||
> En tant que (...) je veux que (...) de manière à ce que (...)
|
||||
|
||||
Nous utililons des phrases standards incluant le destinataire du besoin.
|
||||
|
||||
### Besoins non-fonctionnels quantifié
|
||||
|
||||
Là encore nous avons besoins de précision, prenon l'exemple du besoin non
|
||||
fonctionnel "*Les animations graphiques doivent être fluides* de quoi est-il
|
||||
question:
|
||||
|
||||
* Quel nombre d'image par seconde minimal?
|
||||
* Quelle machine cible? Quelle taille d'image?
|
||||
* Animation précalculée ou générée?
|
||||
* Quel framework / API graphique utilisé (OpenGL, Vulkan, DirectX)?
|
||||
|
||||
En terme de sécurité, des **normes existes** comme *DO-178C* dans les logiciels
|
||||
pour l'aviation avec des niveau de A à E définissant la criticité des impacts.
|
||||
|
||||
Le modèle *Capability Maturity Model Integration* fixe une mesure pour la
|
||||
qualité du travail d'une équipe de dévellopement :
|
||||
|
||||
* *Initial*: peu de contrôle sur les processus, résultats imprévisibles
|
||||
dépendant de la compétence et volonté de l'équipe;
|
||||
* *MAnaged*: processus de gestion de projet caractérisés définis et appliqués,
|
||||
dévellopement planifié;
|
||||
* *Defined*: définition de processus standardisés à toute l'organisation /
|
||||
entreprise;
|
||||
* *Quantitatively*: utilisation systëmatique de mesures et de contrôle sur
|
||||
**tous** les processus;
|
||||
* *Optimizing*: optimisation des processus, amélioration et possibilité de
|
||||
changement intégrés dans le processus.
|
||||
|
||||
### Faisabilité
|
||||
|
||||
Il faut se référer aux documentations et étudiant l'existant dans notre étude de
|
||||
faisabilité. Il est aussi possible de regader ... ce que fait la concurence.
|
||||
C'est à cette étape que nous pouvons utiliser le prototypage et analyser les
|
||||
résultats.
|
||||
|
||||
Il est important de décrire les difficultés et d'estimer leur niveau. Les
|
||||
prototypes et leurs résultats pevent servir pour expliquer ces difficultés.
|
||||
|
||||
### Prioriser
|
||||
|
||||
La priorisation va de pair avec la description des besoins. Il est nécessaire de
|
||||
décrire et déterminer les priorités. Le document *IEEE/ANSI 830-1998* propose
|
||||
trois niveau:
|
||||
|
||||
* **Essentiel**: le logiciel ne sera pas acceptable sans que ce besoin soit
|
||||
réalisé;
|
||||
* **Conditinnel**: besoin qui améliore et/ou étend le logiciel sans que
|
||||
celui-si soit nécessaire pour rendre le logiciel acceptable;
|
||||
**Optionnel**: la valeur de ce besoin n'est pas encore assurée, mais il peut
|
||||
permettre de proposer une **plus** au fournisseur.
|
||||
|
||||
L'échelle de *MoSCoW* : Must, Should, Could, Won't. (un peu à la manière des
|
||||
RFC)
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue