Produit: Processus de développement
Ce produit décrit le processus que doit utiliser un projet pour obtenir le résultat escompté. Ce produit est également appelé processus de développement logiciel.
Objet
L'objectif du processus de développement est de guider et d'assister les membres du projet. "Informations au bout des doigts" est une métaphore qui illustre correctement l'objectif de ce produit.
Relations
RôlesResponsable: Modifié par:
Entrée versObligatoire:
  • Aucun
Facultatif: Externe:
  • Aucun
Description principale

Chaque processus est composé d'une structure de division à n niveaux. Les méthodes principales contiennent des explications pas à pas expliquant comment atteindre des objectifs de développement spécifiques. Ces méthodes ne dépendent pas de leur position dans le cycle de développement. Les processus utilisent ces méthodes et les lient dans des séquences semi-ordonnées qui sont personnalisées pour certains types de projets. Un processus est donc un ensemble de descriptions de travaux partiellement ordonné, destiné à atteindre un objectif de développement plus élevé, comme la publication d'un système logiciel. Un processus se concentre sur le cycle et la séquence des tâches dans la structure divisée.

Il existe plusieurs types de processus : Processus de livraison et Pattern de capacité.

Processus de livraison

Un processus de livraison décrit une approche intégrée complète permettant de mener à bien un type de projet de développement particulier. Un processus de livraison couvre un cycle de développement du début à la fin. Yb processus de livraison est utilisé comme modèle de planification et d'exécution d'un projet. Il offre un modèle de cycle de vie complet, composé de phases prédéfinies, d'itérations et d'activités détaillées par des séquences de méthodes dans des structures divisées. Il est défini sur base de l'expérience des projets ou engagements précédents et/ou des meilleures pratiques d'une approche de développement et de livraison. Il définit ce qui est produit, comment, et l'effectif requis en utilisant des structures divisées de travail, de produit et d'équipe. Par exemple, un responsable de processus peut définir différents processus de livraison pour les projets de développement de logiciel en faisant varier l'échelle d'engagement et d'effectif requis, le type d'application à développer, les méthodes et technologies utilisées, etc. Bien que le processus de livraison couvre la totalité d'un projet, il laisse certaines questions, trop spécifiques au projet, sans réponses. Par exemple, une structure divisée définit les éléments qui disposent de plusieurs occurrences ou qui peuvent être répétés, à l'aide des attributs correspondants ; mais elle n'indique pas le nombre d'occurrences ou de répétitions/itérations de ces éléments. Ces décisions sont prises par le responsable de projet lors de la planification d'un projet particulier, d'une phase de projet ou d'itérations d'un projet.

Pattern de capacité

Un pattern de capacité décrit un ensemble d'activités réutilisable dans les zones de processus courantes. Les patterns de capacités expriment et communiquent des connaissances de processus pour une zone d'intérêt clé, comme une discipline, et sont directement utilisables pour guider son travail. Ils servent également de briques permettant d'assembler des processus de livraison ou de plus grands patterns de capacités qui garantissent une réutilisation optimale et l'application des pratiques clés qu'ils illustrent. Exemples de patterns de capacité : "gestion des exigences basées sur les cas d'utilisation", "analyse de cas d'utilisation" ou encore "tests d'unité". Généralement, mais pas obligatoirement, les patterns de capacités ont la portée d'une discipline et offrent le détail d'activités complexes réutilisables, de relations aux rôles qui effectuent les tâches dans ces activités et aux produits qui sont utilisés et générés. Un pattern de capacité n'est pas lié à une phase ou itération particulière d'un cycle de développement, et ne devrait pas en impliquer. En d'autres mots, un pattern devrait toujours être conçu pour être applicable à tout point d'un processus de livraison. Ceci offre plus de flexibilité dans la assignation des activités aux phases du processus de livraison auquel le pattern est appliqué.

Il est généralement recommandé de concevoir un pattern de capacités afin qu'il génère un ou plusieurs éléments génériques. Une configuration type est que chaque activité du pattern génère un élément et que le descripteur de la dernière tâche de l'activité émette cet élément de manière explicite. Ceci permet au responsable de processus de sélectionner les patterns ou les activités en choisissant les éléments livrables requis. Ce processus offre également une approche d'intégration simple : une activité d'un pattern de capacité est liée à la phase ou à l'itération nécessaire à la production du livrable de l'activité.

Propriétés
Facultatif
PlanifiéYes
Considérations clés
Vous pouvez décider ne pas enregistrer la totalité du processus dans le processus de développement. Dans certains cas, une grande part des responsabilités, des décisions relatives au processus et des produits en particulier est déléguée à des participants au projet de développement logiciel. Par exemple, si l'équipe dispose d'un responsable de projet expérimenté et fiable, vous pouvez lui laisser prendre les décisions relatives à la production de plans et aux méthodes associées. De même, de nombreux responsables de projet ne s'occupent pas de la façon dont chaque membre de l'équipe conçoit la partie du système dont il a la charge tant qu'il livre la fonctionnalité attendue en temps et en heure et en respectant un niveau de qualité acceptable.

La principale raison motivant le recours à la description du processus est de permettre le partage d'informations entre plusieurs personnes. Dans le cas contraire, les coûts de gestion de la description du processus peuvent être trop élevés. Vous pouvez donc décider de ne pas établir ou gérer de description du processus pour une ou plusieurs disciplines. Cela ne signifie pas que vous ne consacrez pas d'effort à cette ou ces disciplines, ni que vous lui/leur accordez peu d'importance. Par exemple, vous pouvez employer un excellent responsable des tests, lui fournir toute l'assistance dont il a besoin, mais lui laisser le soin de choisir sa méthode de travail et de déterminer les produits à produire.

Plus d'informations