Apprendre une nouvelle chose tous les jours
Une table de décision est un excellent outil à utiliser à la fois pour les tests et la gestion des exigences. Il s’agit essentiellement d’un exercice structuré permettant de formuler des exigences lorsqu’il s’agit de règles métier complexes. Dans une table de décision, la logique métier est bien divisée en conditions, actions (décisions) et règles pour représenter les différents composants qui forment la logique métier.
Continue readingNous rencontrons toujours ces termes dans le développement de logiciels. Parfois, les gens parlent d’une fonctionnalité du logiciel, d’une exigence ou d’un cas d’utilisation, d’éléments du backlog ….. Quelle est la convention des gens du logiciel pour utiliser cela ou quoi ?
Continue readingDans le domaine du développement de logiciels, le terme « estimation » comprend une évaluation quantitative du travail nécessaire pour réaliser une tâche de développement donnée, généralement exprimée en termes de durée (heure/jour) ou d’unité estimée (story point). L’objectif est de consolider un certain nombre de ces estimations individuelles afin d’obtenir une indication de la durée, du travail ou du coût global du projet logiciel.
Continue reading
Un diagramme de cas d’utilisation UML est la principale forme d’exigences système/logiciel pour un nouveau programme logiciel en cours de développement. Les cas d’utilisation spécifient le comportement attendu (quoi) d’un système, et non la méthode exacte pour y parvenir (comment). Un ensemble complet de cas d’utilisation spécifie toutes les différentes façons d’utiliser le système et définit donc tous les comportements requis du système en délimitant la portée du système.
Continue reading
Un cas d’utilisation est une description écrite de la manière dont un utilisateur exécute une tâche sur votre système. Il décrit le comportement du système du point de vue de l’utilisateur lorsqu’il répond à une demande. Chaque cas d’utilisation est représenté comme une séquence d’étapes simples, commençant par l’objectif de l’utilisateur et se terminant lorsque l’objectif est atteint.
Continue reading
Use Case 2.0 est une approche évolutive et agile qui utilise les cas d’utilisation pour capturer les exigences et conduire le développement incrémental d’un système pour les satisfaire. Elle vous aide à comprendre comment le système sera utilisé et vous guide dans le développement d’un système approprié pour soutenir les utilisateurs.
Continue reading
Un diagramme de cas d’utilisation modélise les différents types d’utilisateurs qui interagissent avec le système pour résoudre un problème. En tant que tel, il décrit les objectifs des utilisateurs, les interactions entre les utilisateurs et le système, et le comportement requis du système pour satisfaire ces objectifs. Les cas d’utilisation définissent les interactions entre les acteurs externes et le système pour atteindre des objectifs particuliers. Un diagramme de cas d’utilisation contient quatre composants principaux
Continue readingAu cours de l’été 2011, Ken Schwaber et Jeff Sutherland ont révisé leur guide Scrum. Ils y ont supprimé un comportement établi de longue date et connu de Scrum, à savoir l’engagement de l’équipe envers le propriétaire du produit et les clients. L’engagement a été remplacé par la prévision. Ils affirment que les équipes peuvent prévoir leur travail, mais pas s’y engager.
Continue reading
La définition de l’achèvement (DoD) est une liste d’exigences auxquelles une histoire d’utilisateur doit se conformer pour que l’équipe puisse la qualifier de complète. Alors que les critères d’acceptation d’une histoire d’utilisateur consistent en un ensemble de scénarios de test qui doivent être satisfaits pour confirmer que le logiciel fonctionne comme prévu.
Continue reading
Chaque sprint se termine par une réunion de bilan en deux parties. Cette réunion commence par un examen et une démonstration par le client et se termine par une rétrospective de l’équipe. Ces deux éléments ont lieu le dernier jour du sprint. La revue de sprint se concentre sur l' »inspection » et l' »adaptation » de l’incrément (potentiellement expédiable), tandis que la rétrospective du sprint se concentre davantage sur l' »inspection » et l' »adaptation » du processus du sprint.
Continue reading