Posté par jc-QualityStreet le 2 février 2008
Mais tout d’abord, une petite question : selon vous, parmi la centaine de posts de ce blog, quel est le “billet le plus consulté” ?
Allez… quelques secondes de réflexion…
Bon fin du suspens (et quel suspens !) … le billet gagnant se trouve être (et de loin) …
“Spécifications, Exigences et Cahier des charges : Quoi, Comment ?”, l’un des billets de mon TOP 14.
Je ne me risquerai pas à émettre des conclusion hâtives sur cette statistique (car les facteurs l’influençant sont nombreux).
Je ne m’aventurerai pas non plus à postuler que le billet en question est celui qui VOUS intéresse le plus, vous les habitués de Qualitystreet, lecteurs assidus qui venez d’horizons souvent différents mais qui vous retrouvez dans ma vision des projets, de la qualité et dans cette convergence vers laquelle je tends.
Alors surpris ? Moi non (mais je triche car je consulte mes stats), et Vous ?…
J’espère que les lecteurs de “ce billet le plus consulté” trouvent déjà dans celui-ci ce qu’ils recherchent… Pour les y aider davantage, voici un petit “best of” de billets Qualitystreet relatifs à l’Ingénierie des exigences (besoins, spécifications, analyse ….), mais rassurez-vous nous en reparlerons, dans des contextes agiles, à partir d’un référentiel CMMI ou même en mixant les deux!
- Spécifications, Exigences et cahier des charges: Quoi, Comment ?
- Spécifications, Exigences et cahier des charges: Qui, Quand
- Modèle de Kano: si précieux pour…
- La voix de l’utilisateur, entre recueil du besoin et gestion de l’incertitude
- Un user proxy mais pas d’utilisateurs
- Une interface conviviale (1/3)
- Une interface conviviale (2/3)
- Une interface conviviale (3/3)
- Use cases, User Stories
- Use cases, User Stories: les différences
- Use Case, UML, oui mais …
- User stories, plus appropriées ?
Si vous avez le courage d’en lire ou en avez lu certains :); dites-moi celui qui vous inspire le plus, sinon plus simplement faites nous partager vos meilleures sources.
Posté par jc-QualityStreet le 7 novembre 2007
L’ISO 9126 « Software Product Quality » (2001) et l’ISO SQuaRE « Software Product Quality Requirement and Evaluation » (2005) (fusion de 9126 et 14598, son volet évaluation) font partie de ces normes qu’il est bon de connaître quand on travaille dans le développement de logiciels ou plus largement dans la conception de services interactifs.
MàJ du 08/11/2007 : Pour une définition plus précise de l’ergonomie et de l’utilisabilité, jetez-un oeil à ce billet ”Ergonomie = Utilité + Utilisabilit锑
L’essentiel pour moi, Ergonome
- La mise en avant de l’Utilisabilité (facilité d’utilisation) : c’est l’une des 6 caractéristiques du modèle de qualité
- La présence de l’Attractivité en plus de sous caractéristiques plus classiques : c’est la reconnaissance de l’esthétisme, de l’affect, du “beau” au niveau de l’interface… élément qui fait régulièrement débat
- L’introduction (forme révisée) du concept de “Quality in use” avec 4 caractéristiques : Efficacité, Efficience, Sûreté, Satisfaction… mon “Ergonomie en 3 mots” pourrait pourquoi pas, se transformer en une “ergonomie en 4 mots”
- La mise en oeuvre des mesures
En bref
ISO 9126 et ISO SQuaRE fournissent un modèle, fait de caractéristiques et sous-caractéristiques, permettant de lier les qualités externes d’un logiciel à ses qualités internes, et introduisent fort justement (même si on a tendance à l’oublier) le concept de “Quality in use” (« the user’view of the quality of the software product when it is used in a specific environment and a specific context of use ») : une vraie porte ouverte vers les Tests Utilisateurs et l’observation en contexte.
6 caractéristiques de qualité (avec un focus sur l’Utilisabilité)
- Capacité fonctionnelle
- Fiabilité
- UTILISABILITE (en anglais, “usability” qu’on peut traduire aussi par “facilité d’utilisation”, c’est à dire un “Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs”) : Facilité de compréhension, Facilité d’apprentissage, Opérabilité, Attractivité, Conformité aux standards d’ergonomie
- Rendement
- Maintenabilité
- Portabilité
Pourquoi ça m’intéresse ? Qu’est ce que ces normes m’apportent ?
- La qualité des produits est mon leitmotiv, ce vers quoi je tends…
- Ces normes sont à elles seules le symbole de la convergence de plusieurs disciplines de l’ingénierie
- C’est la reconnaissance de ma propre discipline, l’Ergonomie, de mon rôle et de mon expertise (en particulier sur les questions relatives à la facilité d’utilisation), cela peut légitimer mon intervention
- C’est un point d’entrée idéal pour l’ingénierie des exigences (du recueil à la gestion des exigences en passant par l’analyse du besoin): j’utilise ces caractéristiques pour qualifier les exigences fonctionnelles et non fonctionnelles recueillies
- Cela facilite ma collaboration avec les services QA (Quality Assurance) et sur un projet avec un Responsable de test
- Il existe un lien fort avec des domaines de processus CMMI, niveau 2 et 3, je pense notamment à RD “Développement des exigences”, REQM “Gestion des exigences”, VER “Vérification”, VAL “Validation”, TS “Solution technique”, MA “Mesure et Analyse” …
Posté par jc-QualityStreet le 5 octobre 2007
N’oubliez pas qu’un cas d’utilisation est avant tout TEXTUEL, et n’associez donc pas aussi radicalement ce cas d’utilisation (Use Case) au diagramme UML: privilègiez plutôt la démarche.
En effet, se lancer dans la rédaction des cas d’utilisation, pour décrire un besoin fonctionnel (spécifications), c’est se lancer dans une véritable démarche d’analyse, progressive, parfois lente, parsemée d’ateliers de travail, d’entretiens …
C’est aussi adopter une vraie réflexion en termes d’utilisateurs (acteurs), de buts et de tâches.
Croyez-moi, c’est bien là l’essentiel.
Le diagramme des cas d’utilisation UML (« Use Case diagram ») est quant à lui trés précieux pour bénéficier d’une vue globale sur l’application; il permet de visualiser immédiatement les liens entre acteurs et cas d’utilisation, ou encore de délimiter explicitement les différents packages. « Modéliser graphiquement » est un principe du Processus Unifié (ceci dit toujours fonction des destinataires), donc le diagramme des Use Cases ne doit pas absolument pas être négligé !
Pour ma part, ce n’est pourtant pas le diagramme qui m’a séduit …
j’ai découvert les cas d’utilisation en 2000 quand j’étais consultant au Luxembourg et j’ai très rapidement perçu, en les construisant (et grâce à de bons mentors), la forte complémentarité à la fois avec la démarche Ergonomique (profil utilisateurs, réflexion sur les buts et scénarios, UCD …) et avec les activités, livrables de l’Ergonome ou Designer d’interaction (Personas, Storyboard, Diagramme de Tâches, Wireframes).
Le fait que les cas d’utilisation se focalisent seulement sur le Quoi (Fonctionnel et Métier) _c’est une règle d’or_, sans décrire les éléments d’interfaces (Ecrans et enchaînement), laissés aux spécialistes de l’IHM, est aussi un élément que j’ai beaucoup apprécié, selon moi un vrai point fort.
Modéle générique de cas d’utilisation
Donc, depuis tout ce temps, j’évangélise … en insistant principalement sur 6 points :
- La démarche de découverte et de construction progressive des cas d’utilisation: l’essentiel …
- La forte adéquation avec le développement itératif (dans l’estimation, la priorisation, la planification, le traitement)
- La complémentarité avec le travail de l’Ergonome
- La lisibilité, le formalisme des cas d’utilisation (élément clé de son efficacité et de son acceptation par les équipes)
- La gestion des modifications (pas si simple que ça!)
- Le lien fort avec les cas de tests et une approche de validation fonctionnelle (c’est l’idéal!)
… Et je recommande toujours « Rédiger des cas d’utilisation efficaces », d’Alistair Cockburn, la référence que je conseille à tous ceux qui souhaitent s’attaquer à l’analyse système ou mètier.
Enfin, même si aujourd’hui je me retrouve davantage dans les User stories, je reste convaincu de la pertinence des cas d’utilisation dans pas mal de contextes … quand ils sont bien rédigés 
Posté par jc-QualityStreet le 3 septembre 2007
Plus qu’une simple tendance, le rapprochement des Méthodes Agiles et du CMMI (Capability Maturity Model Integration), ou plus exactement l’usage de pratiques de développement Agiles (qui ont le vent en poupe) dans une dynamique de processus guidée par le CMMI (version1.2 DEV d’aout 2006) est bel et bien réel.
Les exemples concernant XP et SCRUM (voir les études de Mickael Spayd, Mark Paulk, Hillel Glazer ou encore Jeffrey Dutton) se multiplient depuis quelques années.
Dernier exemple en date (trés bien documenté d’ailleurs), celui de Codice Software (un éditeur espagnol), “SCRUM Meets CMMi, Agility and discipline combined“, avec à la clé l’atteinte d’un niveau 2 de maturité et une vision trés pragmatique de la combinaison des deux approches (un vrai travail sur REQM, “Gestion des exigences”, des domaines complètement nouveaux et pas des plus simples dans un contexte Agile: PPQA, “Assurance Qualité Processus et Produit” et MA, “Mesure et Analyse”….).
Dans un contexte plus général, cette démarche de réconciliation Agile CMMI (c’est un bien grand mot !) est soutenue, et c’est trés positif, par des acteurs majeurs des deux “camps”, mais elle implique aussi, selon moi, à notre niveau, l’acceptation de certains prérequis:
- D’abord considèrer le CMMI tel qu’il est, à savoir, un modèle, un guide, et non pas un processus ou une méthode de développement.
- Se souvenir que le CMMI définit seulement le QUOI (par ses objectifs par exemple) et non pas le COMMENT, même si le modèle propose quelques pistes. Et c’est vrai que cette absence de COMMENT a laissé la part belle aux méthodes dites traditionnelles (cascade ou V) toujours bien ancrées.
- Ne pas oublier que seule l’atteinte des objectifs généraux (GG, liés à un niveau de maturité) et spécifiques (SG,liés à un domaine de processus) est requise lors d’une évaluation SCAMPI (méthodes standards d’évaluation). Les pratiques (GP, génériques liées à un niveau et SP, spécifiques liées à un domaine de processus) ne sont quant à elles pas obligatoires, et des alternatives (Agiles notamment) sont envisageables : c’est un bon point d’entrée.
- S’arracher des idées reçues concernant les deux Mondes … (vaste débat), rechercher l’ouverture, et d’un point de vue pratique, au quotidien, s’appuyer sur des leviers organisationnels exploitables.
David Anderson a su trouver les mots justes lors de l’Agile2005:
A key to achieving more agility with the CMMI is to realize that the practices are primarily advisory or indicative only. To meet a CMMI appraisal, an organization must demonstrate that the goals of a process area are being achieved. This is done by identifying evidence of practices. However, the practices need not be the ones described in the CMMI specification. The organization is free to propose alternatives practices and appropriate evidence. The appraisal team must then agree to whether this is appropriate to demonstrate the goal. This provides a process designer with a great deal of freedom.
En conclusion, si vous entendez les mots Agile et CMMI dans la même phrase, ne fuyez pas … soyez curieux … et dites OUI à la convergence.
Posté par jc-QualityStreet le 28 août 2007
Agilité rime souvent avec Absence de documentation : voilà une idée reçue bien nuisible qui doit être combattue avec force … car mener un projet en utilisant les méthodes Agile (Agile UP, xxUP, XP, SCRUM…), n’a jamais signifié « ne produire aucune documentation ».
A l’origine de cette confusion ? Peut être une mauvaise interprétation de l’Agile Manifesto et de l’une de ses 4 valeurs « un logiciel fonctionnel plutôt qu’une documentation complète », ou plus simplement la facilité, un manque de volonté voire de compétences de certaines équipes de développement souvent soumises à un timing toujours plus serré …
Soyons clairs, privilégier l’application (ou un prototype) qui marche, plutôt que la documentation, à la fois pour mesurer l’avancement d’un projet et valider ce qu’on fait est un principe agile de base, indispensable et dont je suis entièrement convaincu (la documentation ne doit jamais servir d’indicateur de productivité). Mais aujourd’hui, peu de projets peuvent se passer d’une documentation (au sens large) précise et adaptée.
Ma position tient donc en quelques mots … « JUSTE CE QU’IL FAUT », en réfléchissant attentivement :
- A la Valeur du doc (ou de l’artefact) par rapport à l’Effort pour le produire et surtout le maintenir, sans perdre de vue que notre but, notre métier, c’est faire du soft, c’est concevoir des applications informatiques, ce n’est pas produire du papier !
- En termes de réponse à un besoin, de bénéfice pour le projet, de feedback …
- Et toujours en fonction de destinataires potentiels
Car être agile c’est avant tout penser communication, feedback, réactivité et adaptation plutôt que lourdeur, lenteur et bureaucratie, et croyez-moi une telle approche nécessite même une grande discipline ! Etre agile, c’est donc documenter de façon intelligente, appropriée et précise son projet en s’appuyant sur ce dont on a réellement besoin et ce qui est attendu pour éviter un gaspillage de temps et d’argent.
L’expérience me montre que l’utilisation d’un certain nombre de documents est quasi obligatoire sur la plupart des projets (la Vision par exemple, et d’autres pour la gestion de projet, les spécifications, …), et que certains contextes nécessitent plus naturellement (sans imposer) un certain formalisme (je pense à l’Offshore ou encore au CMMI, Capability Maturity Model Integration …). D’ailleurs, à l’autre extrême (autre idée reçue), se référer aux bonnes pratiques du modèle CMMI ne signifie pas pour autant, excès de bureaucratie et documentation à outrance.
Tout est donc affaire de mesure … SCRUM (la méthode Agile la plus populaire du moment) ou encore la conduite efficace de projets agiles vont dans ce sens.
Le Processus Unifié (dans une version customisée et adaptée à l’entreprise) peut assurer un très bon compromis, en permettant de constituer rapidement un excellent référentiel de doc. et bonnes pratiques que le chef de projet devra de nouveau ajuster à chaque projet (par l’intermédiaire du Plan de projet, élément incontournable d’UP qu’on retrouve aussi dans les pratiques du processus PP (« Planification du Projet »), l’un des 7 processus de niveau 2 du CMMI 1.2).
Pour le reste, les qualités de l’auteur de la documentation feront la différence pour la rendre correcte, précise et pertinente mais aussi lisible, légère et acceptable : en effet rédiger des cas d’utilisation ou même des user stories ne s’improvise pas, tout comme décrire des « personas », faire des diagrammes UML, des grilles fonctionnelles, rédiger un guide utilisateur, définir un plan de projet ou encore maintenir un plan d’itération …
