Fiches outils - Développer et déployer des applications

Le diagramme de séquence

Un diagramme de séquence est un diagramme d’interaction qui détaille comment les opérations sont effectuées, quels sont les messages envoyés mais aussi quand les opérations sont initiées. Les diagrammes de séquence sont organisés en fonction du temps. Le temps s’écoule de haut en bas de la page. Les objets impliqués dans l’opération sont répertoriés de gauche à droite en fonction de leur participation dans la séquence des messages.

Voici un diagramme de séquence pour effectuer une réservation d’hôtel. L’objet qui initie la séquence de messages est une fenêtre de réservation.

Le diagramme de classe

Un diagramme de classe décrit la structure d’un système en modélisant ses classes, ses attributs, ses opérations et les relations entre les objets. Les diagrammes de classe sont l’un des types de diagrammes les plus utiles dans Unified Modeling Language (UML) pour cartographier clairement la structure d’un système particulier en modélisant ses classes, ses attributs, ses opérations et les relations entre les objets.

Le diagramme de déploiement

Les diagrammes de packaging, aussi connus sous le nom de diagrammes de déploiement ou de diagrammes de composants, sont des représentations visuelles utilisées dans l’ingénierie logicielle pour décrire la structure physique ou matérielle d’un système logiciel. Ces diagrammes permettent de visualiser les dépendances entre les différents composants logiciels, matériels et leurs interconnexions au sein d’une architecture globale.

Composants logiciels et matériels : les diagrammes de packaging représentent les composants logiciels (comme les modules, les bibliothèques, les services, etc.), ainsi que les éléments matériels (comme les serveurs, les dispositifs, les appareils, etc.) qui constituent le système informatique. Ces composants sont généralement représentés sous forme de boîtes ou de rectangles.
Relations et interconnexions : ils mettent en évidence les connexions et les relations entre les composants logiciels et matériels. Ces relations sont illustrées à l’aide de lignes ou de flèches, indiquant la façon dont les différents éléments du système interagissent entre eux, par exemple, les appels de fonctions entre modules logiciels ou les connexions réseau entre serveurs....

Le rôle du propriétaire du produit et sa responsabilité

Le rôle de propriétaire du produit est clairement très souvent incompris. Trop souvent, le nom propriétaire du produit est affecté à des analystes, alors que ceux-ci ont des objectifs différents. En effet, les propriétaires de produits sont responsables d’optimiser la valeur fournie par un produit. Pour ce faire, il fait le lien entre les utilisateurs - en direct ou au travers du service desk -, l’organisation dans son ensemble et les équipes de développement.

C’est ainsi que les propriétaires de produits ont la charge de décrire les attentes, généralement sous la forme de récits utilisateur. Cette tâche peut être déléguée à d’autres personnes, mais c’est à eux de définir les priorités et de décider lorsque cela s’avère nécessaire. C’est également à eux que revient la signature de la livraison.

Évidemment, les activités ne s’arrêtent pas là. Le propriétaire du produit se doit d’analyser, de positionner le produit et d’effectuer une grande part de relationnel. De nombreuses compétences sont nécessaires et un repositionnement de développeur vers un rôle de propriétaire...

Un exemple de liste des fonctionnalités du produit

Une liste des fonctionnalités du produit (product backlog) est l’ensemble des fonctionnalités attendues ou tout du moins espérées. Au sein de cette liste, les récits utilisateur sont triés par ordre d’importance ou tout du moins en termes de valeur créée, comme nous avons pu le voir au chapitre « Mettre en place des fondements stables pour plus d’agilité ». Cette liste est sous la responsabilité du propriétaire du produit tel que décrit ci-dessus.

Sur la base de l’expérience de l’équipe, il est possible d’évaluer la vélocité qui est la moyenne de l’effort délivré dans les périodes précédentes. L’effort est la difficulté à implémenter le récit utilisateur (user story). Ainsi, une fonctionnalité complexe peut être implémentée aisément si celle-ci se base sur une autre fonctionnalité existante. À l’inverse, lorsque les technologies à utiliser ne sont pas connues, l’effort à fournir est plus important même si la demande paraît simple. C’est pour cela que l’effort est dépendant de l’équipe elle-même et non d’une grille prédéfinie.

La date...

La communication d’un changement à venir

Un changement à venir doit être communiqué efficacement vers l’audience adéquate, c’est-à-dire la liste des utilisateurs du ou des services qui sont impactés. Le titre doit refléter le système, une description courte du changement et la date du changement. Pour ce qui est du contenu de la communication en elle-même, elle répond à quelques questions simples :

De quoi parlons-nous ?

Pourquoi ce changement ?

Comment cela vous affectera-t-il ?

Que devez-vous faire ?

Quels tests devez-vous effectuer ?

Qui contacter en cas de question ?

Un exemple de communication de changement est disponible en téléchargement.

La communication d’un incident

Un incident en cours doit être communiqué efficacement vers l’audience adéquate, c’est-à-dire la liste des utilisateurs du ou des services qui sont impactés. Le titre de la communication doit refléter le système et une description courte de l’impact. Pour ce qui est du contenu de la communication en elle-même, elle répond à quelques questions simples :

Système : identification du système informatique, logiciel ou service spécifique affecté par l’incident.
Référence de l’incident : numéro ou code unique attribué à l’incident pour faciliter son suivi et sa référence ultérieure.
Impact de l’incident : description de la portée et des conséquences de l’incident sur les opérations, les utilisateurs ou les services.
Description de l’incident : explication détaillée de la nature, des symptômes et des effets observés de l’incident.
Date de début : moment précis où l’incident a été initialement détecté ou signalé.
Date de fin estimée : heure ou moment prévus pour la résolution ou la clôture anticipée de l’incident.
Personne de contact : individu ou équipe...