Instructions: Discriminants du processus
Ces instructions décrivent les facteurs affectant la façon dont un processus est personnalisé pour un projet.
Relations
Description principale

Présentation

Le processus de développement logiciel est influencé par les facteurs suivants :

  • Facteurs de domaine : domaine d'application, processus métier à prendre en charge, communauté des utilisateurs et offres proposées par les concurrents.
  • Facteurs du cycle de vie : temps d'accès au marché, durée de vie prévue du logiciel et versions futures prévues.
  • Facteurs techniques : langage de programmation, outils de développement, base de données, infrastructures de composants et systèmes logiciels existants.
  • Facteurs d'organisation.

Ces facteurs n'ont pas tous la même importance. Les sections suivantes décrivent certains des facteurs principaux (ceux le plus susceptibles d'avoir un impact sur l'aspect général du processus de développement) et vous indiquent comment implémenter le processus et les outils dans l'organisation de développement.

Le contexte métier décrit le contexte dans lequel le logiciel est développé. Il existe différents types de contextes métier affectant l'optimisation de la personnalisation du processus. Voici des exemples de contextes métier :

  • Mission contractuelle : le développeur crée un logiciel en fonction de spécifications client données et pour ce client uniquement.
  • Développement commercial ou spéculatif : le développeur produit et couvre les coûts de mise sur le marché du logiciel.
  • Projets internes : le client et le développeur font partie de la même organisation.

Il existe de nombreuses situations intermédiaires, par exemple, lorsque seule une partie du développement logiciel est sous-traitée ou que la dispersion géographique est un facteur supplémentaire. Le nombre total de parties prenantes différentes est un bon indicateur du contexte métier.

Le contexte métier a un impact sur le niveau de formalisme et la rigidité du projet. Plus les parties prenantes acheteuses, les clients, les entités de régulation, les sous-traitants, etc. impliqués sont nombreux, moins le projet est susceptible de produire des preuves formelles, comme des documents, des rapports et des prototypes, lors des jalons importants.

Ampleur de l'effort de développement logiciel

L'ampleur de l'effort de développement logiciel est définie par certaines mesures, comme les lignes de code source (SLOC, Source Lines of Code), les instructions source fournies ou les points de fonctions, le nombre de mois-homme ou tout simplement le coût.

L'ampleur de l'effort a un impact sur le niveau de formalisme et la rigidité du projet. Plus le projet et l'équipe de développement sont importants et, quel que soit le contexte métier, plus les différentes équipes et les responsables ont besoin de formalisme et de visibilité pour les exigences, les interfaces et les indicateurs de progression. Les problèmes de communication dans le cadre de projets de grande ampleur sont accentués lorsque les équipes sont dispersées géographiquement.

Degré de nouveauté

Le degré de nouveauté est fondé sur ce qui a précédé cet effort logiciel relatif à l'organisation de développement et, plus particulièrement, si le développement a atteint un second cycle ou un cycle ultérieur. Il inclut la maturité de l'organisation, son processus, ses actifs, ses compétences actuelles et ses problèmes (constitution et formation d'une équipe, acquisition des outils et d'autres ressources).

Le degré de nouveauté d'un projet affecte le processus de façon totalement différente. Un nouveau projet (le premier de ce type) affecte la configuration dynamique de façon significative : les phases de création et d'élaboration seront plus longues et peuvent s'étaler sur plusieurs itérations. De même, l'accent sera davantage mis sur l'élicitation et l'enregistrement des exigences, sur la modélisation des cas d'utilisation, sur l'architecture et sur la réduction des risques. Si un projet est un cycle d'évolution d'un système précédent, la gestion des modifications est encore plus cruciale et l'intégration de code existant génère des défis techniques.

Le degré de nouveauté ne concerne pas uniquement le système en cours de développement, il est également lié à la maturité des organisations car l'introduction de nouvelles techniques ou de nouveaux outils affecte le processus. En particulier, les étapes l'introduction par phase du processus Rational Unified Process à proprement parler dans l'organisation doivent être soigneusement étudiées. Lors de l'adoption d'un nouveau processus, une organisation montre une certaine inertie et la stratégie d'adoption doit prendre en compte une transition sans à coups des pratiques existantes aux nouvelles.

Type d'application

Il existe différents types d'applications, comme par exemple les systèmes imbriqués en temps réel, les systèmes d'information distribués, les systèmes de télécommunication et les outils d'ingénierie logicielle assistée par ordinateur. Le type d'application affecte le processus, plus particulièrement en ce qui concerne les contraintes spécifiques que le domaine peut imposer au développement (sécurité, performances, internationalisation, contraintes de mémoire, etc.).

Le type d'application affecte le processus si l'application est vitale (système de contrôle de vol d'un avion par exemple). Un système vital nécessite en général un niveau de formalisme plus élevé, pour effectuer le suivi des exigences et garantir la qualité du produit. Une application vitale nécessite également d'accorder davantage de ressources au test.

Le type de développement, ou domaine cible, génère des problèmes de processus tels que :

  • Techniques et outils pour la prise en charge de tâches spécifiques (génération automatique de code pour les machines finies par exemple).
  • Procédures de certification (pour l'instrumentation médicale par exemple).
  • Conformité aux normes (problèmes comptables ou financiers et problèmes de télécommunication par exemple).

Type de développement

Il existe plusieurs types de développement. Par exemple :

  • Travail contractuel : développement d'un produit pour un client spécifique. Dans le cadre d'un travail contractuel, vous devez gérer et négocier avec davantage de parties prenantes. Des produits formels-externes sont souvent nécessaires car le client, ou ses représentants, veulent surveiller l'avancement et être informés. Assurez-vous que les produits revus par le client sont faciles à comprendre. Il est parfois nécessaire d'avoir un jalon lorsque le projet peut proposer un prix fixe sur le reste du projet. Dans ce cas, il peut être nécessaire d'ajouter un nouveau jalon ou d'ajuster les jalons existants. Dans d'autres cas, vous pouvez devoir ajuster le modèle de cycle de vie utilisé par le client avec d'autres jalons et d'autres phases.
  • Développement spéculatif : développement d'un produit pour un marché de masse. Dans le cadre d'un développement spéculatif, un responsable marketing (produit), au sein de l'organisation, joue le rôle du client. Le temps d'accès au marché est souvent plus important que la fonctionnalité dans le développement spéculatif, et le besoin de revues formelles est moins grand.
  • Développement interne : développement d'un produit délivré à un autre service de l'entreprise. Il peut être nécessaire de procéder à un ajustement et d'utiliser un autre modèle de cycle de vie si vous livrez un produit à un autre projet n'utilisant pas le processus RUP. La description des produits peut être plus technique car ils seront revus, pour la plupart d'entre eux, par des pairs.
  • Etudes préalables : il ne s'agit normalement pas du développement d'un produit. Le but d'un projet d'étude préalable est de rechercher s'il est possible de construire un produit. Un projet d'étude préalable n'a pas les mêmes jalons qu'un projet classique.

Processus de développement actuel

Dans la plupart des cas, vous ne remplacez pas le processus de développement logiciel actuellement utilisé dans l'organisation car, généralement, le nouveau processus de développement est implémenté étape par étape, en se concentrant tout d'abord sur les éléments les plus vitaux et importants. Une partie du processus de développement actuel peut même continuer à exister pendant un certain temps, parfois indéfiniment.

Problèmes et causes racines

Les problèmes identifiés et leur priorité pour le projet ont un impact sur les éléments du processus sur lesquels vous vous concentrerez au début du processus d'implémentation. Notez que si aucune méthode de travail n'est établie dans l'organisation, il est inutile de rechercher des problèmes. Voir Concept : Implémentation d'un processus dans un projet pour plus d'informations. En revanche, il peut être nécessaire d'identifier les causes racines des problèmes. Pour éliminer les problèmes, vous devez vous attaquer à la cause racine en améliorant le processus, en implémentant des outils pour automatiser le processus et en formant du personnel. 

Exemples de problèmes courants

Voici quelques exemples de problèmes courants :

  • Incapacité à gérer la portée (l'organisation essaye généralement d'en faire plus que ce qui est réellement réalisé au final).
  • Incapacité à enregistrer les exigences (il est difficile de définir les exigences).
  • Incapacité à gérer les exigences modifiées.
  • Incapacité à gérer les exigences (celles-ci n'atteignent pas la niveau du produit final).
  • Incapacité à estimer (trop optimiste sur les capacités à fournir le produit dans les temps).
  • Insuffisances de conception (bonnes capacités à répondre aux exigences mais mauvaises capacités de conception de systèmes). Quels sont les problèmes de conception rencontrés ? Les systèmes sont-ils difficiles à gérer et améliorer ? S'agit-il de problèmes de performance, de convivialité, de capacité, etc. ?
  • Incapacité à produire des produits de qualité (le produit a de trop nombreux défauts, par manque de test par exemple, mais également en raison d'une incapacité à enregistrer et gérer les exigences et d'insuffisances de conception).
  • Performances inacceptables du logiciel.
  • Faible convivialité.
  • Désaccords entre développeurs (manque de contrôle sur la gestion de la configuration et de la propriété générant des modifications conflictuelles et une perte de travail).
  • Identification tardive des problèmes. 
  • Difficultés de transition entre les cas d'utilisation et la conception.
Exemples de causes racines

Un problème est souvent un symptôme indiquant que quelque chose ne va pas. Vous devez identifier les causes racines des problèmes. Voici des exemples de causes racines courantes :  

  • Gestion des exigences insuffisante
  • Communication ambiguë et imprécise
  • Architectures fragiles
  • Complexité excessive
  • Incohérences non détectées dans les exigences, conceptions et implémentations
  • Test insuffisant
  • Evaluation de l'état du projet subjective
  • Réduction des risques différée en raison de développement en cascade
  • Propagation des changements non contrôlée
  • Automatisation insuffisante
  • Pas de génération automatique des interfaces utilisateur
  • Aucun moyen de transition entre les cas d'utilisation et la conception

Facteurs liés à l'organisation

L'implémentation du processus dans une organisation dépend de facteurs liés à l'organisation, tels que la capacité de changement de l'organisation, la structure organisationnelle, la culture de gestion et d'organisation du projet, les compétences disponibles, les expériences précédentes et les attitudes actuelles.

Les facteurs liés à l'organisation ont également un impact sur la configuration du processus. Par exemple, si dans l'organisation les personnes utilisaient une description de processus de développement logiciel, il sera plus facile de commencer à utiliser le processus RUP. En revanche, si les personnes de l'organisation n'ont pas utilisé une description de processus de développement logiciel, vous pouvez décider de limiter la portée de la description du processus. Vous pouvez également faire un effort supplémentaire pour faciliter la compréhension et l'utilisation de la description de processus et vous assurez qu'elle contient les informations les plus pertinentes (ou y fait référence).

Si certains aspects sont nouveaux pour de nombreuses personnes, développer les meilleures instructions possibles facilitera la transition. Par exemple, si le langage de programmation est nouveau pour de nombreuses personnes, vous devez disposer d'excellentes instructions de programmation et de conception pour les aider dans leur apprentissage.

Attitudes

Une attitude négative au sein du personnel d'une organisation par rapport à des changements dus à une nouvelle technologie, un nouveau processus ou de nouveaux outils est la plus grande menace qui puisse peser sur l'implémentation d'un processus et d'outils. Trop d'enthousiasme peut également poser des problèmes car les personnes se focalisent trop sur le processus.

Pour évaluer l'attitude des personnes vis à vis de la nouvelle technologie, du nouveau processus ou des nouveaux outils, posez des questions comme :

  • Quels avantages peut apporter la nouvelle technologie ? Sera-t-elle en mesure de résoudre des problèmes actuels ? Quels problèmes peut-elle engendrer ?
  • Quels avantages peut apporter le nouveau processus ? Sera-t-il en mesure de résoudre des problèmes actuels ? Quels problèmes peut-il engendrer ?
  • Quels avantages peuvent apporter les nouveaux outils ? Seront-ils en mesure de résoudre des problèmes actuels ? Quels problèmes peuvent-ils engendrer ?

Pour évaluer la motivation, déterminez les réponses aux questions suivantes :

  • Tout le monde dans l'organisation comprend-il pourquoi ce changement est nécessaire ?
  • Tout le monde est-il conscient de l'activité des concurrents et de son impact ?
  • Tout le monde est-il conscient des changements de technologie dans le secteur d'activité et de leur impact sur le métier ?  

Des signes d'attitude négative peuvent inclure les réflexions suivantes :

  • "Le processus n'aide pas, il gêne."
  • "Le processus implique de créer de nombreux documents."
  • "Le processus est trop pesant."

Voici quelques façons de gérer les attitudes négatives :

  • Motivez les gens en mettant l'accent sur les problèmes actuels.
  • Expliquez qu'un processus ne dicte pas aux gens ce qu'ils doivent faire. Le processus doit être considéré comme un "système d'aide", dans lequel vous pouvez trouver des instructions, des définitions etc.
  • Expliquez que seules certaines petites parties du processus sont utilisées. Personne ne maîtrise l'intégralité du processus, et cela n'est de toute façon pas le but. Comparez le processus à une étagère de livres que vous consultez lorsque vous avez besoin des informations qu'ils contiennent.
  • Créez un projet pilote réussi vous permettant de montrer que le nouveau processus et les nouveaux outils fonctionnent. Intégrez quelques sceptiques à l'équipe du projet pilote. 

Des signes d'attitude trop enthousiaste peuvent inclure :

  • Les personnes se reposent complètement sur le processus et pensent qu'il va résoudre tous leurs problèmes.
  • Le processus est l'arme fatale ou la formule magique qui, lorsqu'elle est utilisée, est une garantie de succès.
  • L'équipe du projet veut consacrer beaucoup de temps et d'effort à la personnalisation du processus sans commencer par évaluer les problèmes relatifs au processus qui doivent être résolus. 

Voici quelques façons de gérer les attitudes trop enthousiastes :

  • Définissez des attentes. Le processus sera une aide mais il ne résoudra pas tous les problèmes. Les équipes résolvent les problèmes.
  • Persuadez les gens de ne pas consacrer trop de temps à la personnalisation du processus.
  • Poussez les équipes à se concentrer sur le développement des produits.

Complexité technique et complexité de gestion

Les différents types de systèmes, et les projets qui leur correspondent, peuvent être classés en fonction de la complexité technique du système et de la complexité de gestion. La figure suivante illustre un concept de classement des différents systèmes. Par exemple, une application de feuille de calcul classique d'une petite entreprise est souvent d'une complexité technique simple et facile à gérer. Un autre extrême est un projet de système d'armement classique, qui est souvent à la fois complexe techniquement et complexe à gérer.

D'une façon générale, plus la durée d'un projet, la taille d'un système ou du contexte métier est importante, plus la gestion est complexe. Plus le degré de nouveauté, dans le domaine concerné ou l'espace de solution, est important, plus la complexité technique l'est au aussi. Il existe une interaction entre la complexité de gestion et la complexité technique, car de nombreux projets de grande envergure sont également complexes sur le plan technique. En résumé :

  • Une complexité de gestion accrue engendre davantage de formalisme, y compris davantage de revues formelles et de jalons, ainsi que davantage de produits.
  • Une complexité technique accrue engendre l'introduction de techniques, de rôles et d'outils spécifiques, et donc davantage de tâches.

Diagramme décrit dans le texte d'accompagnement.

Les systèmes sont classés en fonction de leur complexité technique et de leur complexité de gestion