Rubriques

Présentation Haut de la page

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

  • Des facteurs de domaine, tels que le domaine d'application, le processus métier à prendre en charge, la communauté des utilisateurs et les offres disponibles proposées par les concurrents.
  • Des facteurs de cycle de vie, tels que le temps d'accès au marché, la durée de vie escomptée du logiciel et les versions futures planifiées.
  • Des facteurs techniques, tels que le langage de programmation, les outils de développement, la base de données, les infrastructures de composants et les systèmes logiciels existants.
  • Des facteurs organisationnels.

Le degré d'importance de ces facteurs est variable. Les sections suivantes décrivent quelques uns des facteurs principaux susceptibles d'affecter la structure générale du cas de développement et le mode d'implémentation du processus et des outils dans l'organisation de développement.

Le contexte métier Haut de la page

Il existe différents types de contextes métier déterminant la configuration optimale du processus. Voici quelques exemples de contextes métier :

  • Travail contractuel où le développeur produit un logiciel pour un client spécifique seulement.
  • Développement spéculatif ou commercial où le développeur produit et couvre les coûts de lancement du logiciel sur le marché.
  • Projets internes où le client et le développeur font partie de la même organisation.

Il existe de nombreuses situations intermédiaires, comme par exemple, celles où seule une partie du développement logiciel est sous-traitée, celles où la dispersion géographique est un facteur supplémentaire, etc. Le nombre total de parties prenantes distinctes est un bon indicateur du contexte métier.

Le contexte métier affecte le degré de cérémonie, le niveau de formalité et la rigidité du processus. Plus le nombre de parties prenantes-acheteurs, clients, sous-traitants, organismes de réglementation et autres parties impliquées est important, plus le projet devra produire des preuves formelles, telles que des documents, des rapports et des prototypes, lors des étapes clé du projet.

L'importance des efforts de développement logiciel Haut de la page

Importance des efforts investis dans le développement logiciel définie par certaines métriques, comme les lignes de code source (SLOC), les instructions source livrées, le nombre de personnes-mois et simplement les coûts.

L'importance des efforts affectera le degré de cérémonie, de formalité et la rigidité du processus. Plus le projet est complexe, plus l'équipe de développement est importante, et quel que soit le contexte métier, plus le degré de cérémonie et de visibilité des exigences, des interfaces et des indicateurs de progression doit être élevé pour les diverses équipes et la direction. Les problèmes de communication dans des projets complexes sont aggravés par la dispersion géographique des équipes.

Le degré de nouveauté Haut de la page

Le degré de nouveauté varie en fonction de ce qui précède cet effort de développement logiciel par rapport à l'organisation de développement et en particulier, selon que le développement intervient dans un second cycle ou un cycle ultérieur. Ceci inclut la maturité de l'organisation et de son processus, ses ressources, son pool de compétences actuelles et des questions telles que la constitution et la formation d'une équipe, l'acquisition d'outils et d'autres ressources.

Le degré de nouveauté du projet affecte le processus d'une manière radicalement différente. Un nouveau projet - le premier en son genre - affecte considérablement la configuration dynamique : les phases de création et d'élaboration seront plus longues et peuvent s'étaler sur plusieurs itérations. Une plus grande attention sera également accordée au choix et à la détermination des exigences en ce qui concerne la modélisation des cas d'utilisation, l'architecture et la limitation des risques. Pour un projet qui représente un cycle d'évolution d'un système précédent, la gestion du changement est plus importante et l'intégration du code existant pose quelques défis techniques.

La nouveauté ne concerne pas seulement le système en cours de développement, mais également la maturité des organisations en cause, car l'introduction de nouvelles techniques ou de nouveaux outils affecte le processus. En particulier, l'introduction du processus RUP (Rational Unified Process) dans une organisation doit être soigneusement organisée en plusieurs étapes. Une organisation présentera une certaine inertie dans l'adoption d'un nouveau processus et le cas de développement doit tenir compte d'une transition souple entre les anciennes et les nouvelles pratiques.

Type d'application Haut de la page

Il existe différents types d'application, comme par exemple, les systèmes incorporés en temps réel, les systèmes d'informations distribués, les systèmes de télécommunication, les outils CASE (Computer-Aided Software Engineering), etc. Le type d'application affectera le processus, notamment en ce qui concerne les contraintes spécifiques imposables par le domaine, telles que la sécurité, les performances, l'internationalisation, les contraintes de mémoire, etc.

Le type d'application peut affecter le processus si l'application est stratégique. C'est le cas d'un système de commande de vol d'un avion. Un système stratégique requiert généralement un degré élevé de cérémonie, aussi bien pour effectuer un suivi des exigences que pour assurer la qualité du produit. Une application stratégique exige également un nombre plus important de ressources dans la phase de test.

Le type de développement ou le domaine cible soulève des problèmes au niveau du processus, tels que :

  • Les techniques et les outils de prise en charge d'activités spécifiques, comme par exemple, la génération automatique de code pour les automates à états.
  • Les procédures de certification, comme pour les instruments médicaux, par exemple.
  • La conformité aux normes : par exemple, pour des questions d'ordre comptable ou fiscal et pour les équipements de télécommunication.

Type de développement Haut de la page

Il existe plusieurs types de développement, tels que :

  • Le travail contractuel, où vous développez un produit pour un client spécifique. Le nombre de parties prenantes à gérer et avec lesquels négocier est plus important lorsque vous effectuez un travail sous contrat. Des artefacts externes supplémentaires plus formels sont souvent nécessairesparce que le client ou des représentants souhaitent contrôler la progression et rester informés. Assurez-vous que les artefacts révisés par le client sont faciles à comprendre. Parfois, il est nécessaire de créer un jalon où le projet peut offrir un prix fixe pour le reste du projet. Dans ce cas, vous devrez peut-être ajouter un nouveau jalon ou ajuster les jalons existants. Dans d'autres cas, vous devrez peut-être ajuster le modèle de cycle de vie utilisé par le client à l'aide d'autres jalons et phases.
  • Le développement spéculatif, où vous développez un produit pour un marché de masse. Dans un développement spéculatif, un directeur (de produits) marketing agit en tant que client au sein de l'organisation même. Le délai de commercialisation est souvent plus important que les fonctions dans le cadre d'un développement spéculatif, et le besoin de revues formelles se fait moins sentir.
  • Le développement interne, où vous développez un produit fourni à un autre service de la société. Il est possible que vous deviez vous ajuster à un autre modèle de cycle de vie si vous effectuez une livraison à un autre projet n'utilisant pas le processus RUP. Il peut être acceptable d'être plus technique dans la description des artefacts, car la plupart de ces derniers seront revus par des homologues.
  • Des études préalables, où vous ne développez généralement pas de produit. L'objectif d'un projet de pré-étude consiste à savoir s'il est possible de concevoir un produit. Un projet de pré-étude ne comporte pas les mêmes jalons qu'un projet traditionnel.

Le processus de développement actuel Haut de la page

Dans la plupart des cas, il n'est pas nécessaire de remplacer le processus de développement logiciel actuellement appliqué à l'organisation, car vous implémenterez souvent le nouveau processus de développement étape par étape, en axant la priorité sur les domaines les plus stratégiques et les plus importants. Une partie du processus de développement logiciel actuel peut même continuer à exister pendant quelque temps, voire pour toujours.

Problèmes et causes racine Haut de la page

Un aspect primordial de la compréhension d'une organisation de développement logiciel est de saisir les problèmes qui se posent au niveau du processus de développement logiciel existant. Ce dernier influence les domaines du processus sur lesquels vous vous concentrerez au début de l'implémentation du processus. Il est important de rappeler que s'il n'existe aucune méthode de travail conventionnelle dans l'organisation, il peut être inutile de rechercher des problèmes. Voir la section ../workflow/environm/co_iproj.htm -- This hyperlink in not present in this generated websiteConcepts : Implémentation d'un processus dans un projet. Dans ce cas, vous serez plutôt amené à identifier les causes racine des problèmes. Pour remédier aux problèmes, vous vous attacherez à traiter les causes racine en améliorant le processus, en introduisant des outils permettant d'automatiser ce dernier et en formant les individus. 

Exemples de problèmes fréquents

Voici quelques exemples de problèmes les plus fréquemment rencontrés :

  • Incapacité à gérer la portée : l'organisation essaie régulièrement d'accomplir un plus grand nombre de tâches qu'elle ne le peut.
  • Incapacité à déterminer les exigences : l'organisation ne parvient pas à spécifier les exigences.
  • Incapacité à gérer l'évolution des exigences.
  • Incapacité à gérer les exigences : certaines exigences ne sont pas prises en compte dans le produit final.
  • Incapacité à évaluer : l'organisation est trop optimiste quant à sa capacité à livrer dans les délais.
  • Conception déficiente : l'organisation excelle dans la satisfaction des exigences, mais pas dans la conception des systèmes. Quels types de problèmes rencontre-t-elle ? Les systèmes sont-ils difficiles à gérer et à améliorer ? Rencontre-t-elle des problèmes de performance, de convivialité, de capacité, etc. ?
  • Incapacité à fabriquer des produits de qualité : le produit comporte un trop grand nombre de défauts, peut-être en raison d'un manque de test, mais généralement d'une incapacité à définir et à gérer les exigences, ainsi que d'une conception déficiente.
  • Performances logicielles inacceptables.
  • Faible degré de convivialité.
  • Conflits entre les développeurs : manque de contrôle de la propriété et de la gestion de la configuration. Ainsi, les développeurs effectuent des changements conflictuels, ce qui occasionne une perte de travail.
  • Découverte tardive des problèmes. 
  • Difficultés de passage des cas d'utilisation à la conception.
Exemples de causes racine

Un problème est souvent le symptôme d'une anomalie. Vous devez identifier les causes racine des problèmes. Voici quelques exemples de causes racine les plus courantes :  

  • Gestion insuffisante des exigences
  • Communications ambiguës et imprécises
  • Architectures effritées
  • Complexité accablante
  • Incohérences non identifiées dans les exigences, les conceptions et les implémentations
  • Insuffisance des tests
  • Evaluation subjective de l'état du projet
  • Limitation des risques retardée en raison d'un développement en cascade
  • Propagation incontrôlée des changements
  • Insuffisance de l'automatisation
  • Aucun moyen systématique de concevoir des interfaces utilisateur
  • Aucun moyen de passer des cas d'utilisation à une conception

Facteurs organisationnels Haut de la page

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

Les facteurs organisationnels ont également un impact sur le mode de configuration du processus. Par exemple, si les individus de l'organisation ont utilisé précédemment une description du processus de développement logiciel, il sera alors plus facile d'utiliser d'abord le processus RUP. Dans le cas contraire, vous avez la possibilité de limiter la portée de la description du projet. Vous pouvez également investir plus d'efforts dans la simplification de la compréhension et de l'utilisation du cas de développement, en veillant à ce que ce dernier fasse référence aux parties du processus RUP qui offriront la plus grande valeur.

Si certains domaines sont nouveaux pour de nombreux individus, il convient de créer les principes et conseils les plus adéquats possibles afin de faciliter la transition. Par exemple, si le langage de programmation est nouveau pour de nombreux individus, vous souhaiterez alors disposer de principes et conseils de programmation et de principes de conception solides pour appuyer leur formation.

Attitudes Haut de la page

Les attitudes négatives de la part du personnel de l'organisation envers l'adoption d'une nouvelle technologie, d'un nouveau processus ou de nouveaux outils est probablement la plus grande menace à la réussite de l'implémentation d'un processus et d'outils. Un enthousiasme débordant pour le processus peut également poser problème, dans la mesure où les individus sont trop centrés dessus.

Pour évaluer les attitudes des individus envers la nouvelle technologie, le nouveau processus et les nouveaux outils, posez les questions suivantes :

  • Quels avantages peut-on tirer de la nouvelle technologie ? Cette dernière peut-elle résoudre certains problèmes actuels ? Quels problèmes peut poser la nouvelle technologie ?
  • Quels avantages peut-on tirer du nouveau processus ? Ce dernier peut-il résoudre certains problèmes actuels ? Quels problèmes peut poser le nouveau processus ?
  • Quels avantages peut-on tirer des nouveaux outils ? Ces derniers peuvent-ils résoudre certains problèmes actuels ? Quels problèmes peuvent poser les nouveaux outils ?

Pour évaluer la motivation des individus, répondez d'abord aux questions suivantes :

  • Tous les employés de l'organisation comprennent-ils pourquoi un changement est nécessaire ?
  • Tous les employés sont-ils conscients des actions de la concurrence et de quel mode elle affecte l'entreprise ?
  • Tous les employés sont-ils conscients des changements technologiques dans l'industrie et de quel mode ces derniers affectent l'entreprise ?  

Les signes d'une attitude négative peuvent inclure les déclarations suivantes :

  • "Le processus ne constitue pas une aide, mais une entrave."
  • "Le processus implique la production d'un grand nombre de documents."
  • "Le processus est encombrant."

Voici quelques manières de contrer les attitudes négatives :

  • ~Motivez les individus en insistant sur les problèmes actuels.
  • Expliquez qu'un processus ne dicte pas vos actions. Le processus doit d'abord être considéré comme un "système d'aide", dans lequel vous recherchez des conseils, des définitions, etc.
  • Expliquez que vous n'utilisez que des petites parties du processus. Personne ne peut maîtriser le processus complet et ce n'est pas non plus l'objectif. Comparez le processus à une étagère de livres que vous consultez lorsque vous nécessitez des informations.
  • Exécutez un projet pilote réussi où vous démontrez que le nouveau processus et les nouveaux outils fonctionnent. Incluez un ou deux sceptiques au projet pilote. 

Voici quelques signes d'enthousiasme débordant :

  • Les individus reposent entièrement sur le processus et pensent que ce dernier va résoudre tous leurs problèmes.
  • Le processus est l'arme fatale ou la formule magique qui, si elle est suivie, garantira un succès.
  • L'équipe de projet souhaite investir beaucoup de temps et d'efforts dans la personnalisation du processus sans évaluer d'abord les problèmes liés au processus qui doivent être résolus. 

Voici quelques moyens de calmer l'enthousiasme débordant :

  • Définissez les attentes. Le processus constitue une aide, mais ne résoudra pas les problèmes. La résolution des problèmes incombe aux individus.
  • Persuadez les individus de ne pas perdre excessivement de temps dans la personnalisation du processus.
  • Attirez l'attention des individus sur le développement des produits logiciels.

Complexité technique et managérielle Haut de la page

Différents types de systèmes et leurs projets peuvent être classés en termes de complexité technique du système et de complexité managérielle. La figure suivante illustre un concept de classement des différents systèmes. Par exemple, un tableur conventionnel pour petites entreprises présente souvent un faible degré de complexité technique et est facile à gérer. L'autre extrême est un projet de système d'armement classique, d'un niveau technique et d'une gestion souvent complexes.

L'augmentation de la taille du système, de la durée du projet ou du contexte métier accroît aussi généralement la complexité managérielle. L'augmentation de la nouveauté, que ce soit dans le domaine du problème ou dans l'espace de solution, accroît la complexité technique. Il existe aussi une interaction entre complexité managérielle et complexité technique : de nombreux projets de grand envergure sont également techniquement complexes. Il en résulte :

  • Une complexité managérielle accrue qui engendre un plus grand degré de cérémonie, notamment un plus grand nombre de révisions et d'étapes clé et des artefacts supplémentaires.
  • Une complexité technique accrue qui entraîne l'adoption de techniques, de rôles et d'outils spécifiques et par conséquent, un plus grand nombre d'activités.

Diagramme décrit dans le texte d'accompagnement.

Les systèmes sont classés en termes de complexité technique et de complexité managérielle



RUP (Rational Unified Process)   2003.06.15