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.
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.
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.
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).
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.
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.
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
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.
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.
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.
Les systèmes sont classés en fonction de leur complexité technique et de leur complexité de gestion
|