Référence : Sommerville, Software Engineering, 10 ed., Chapter 2

Un processus logiciel est un ensemble structuré d’activités requises pour développer un système logiciel. Notez que nous parlons d’un « processus logiciel » — et non d’un « processus de développement logiciel. »

Il existe de nombreux types de processus logiciels, mais chacun d’entre eux implique ces quatre types d’activités fondamentales :

• Spécification du logiciel – définir ce que le système doit faire ;
• Conception et mise en œuvre du logiciel – définir l’organisation du système et mettre en œuvre le système ;
• Validation du logiciel – vérifier qu’il fait ce que le client veut ;
• Évolution du logiciel – changer le système en réponse aux besoins changeants du client.

Un modèle de processus logiciel est une représentation abstraite d’un processus. Il présente une description d’un processus à partir d’une certaine perspective particulière. Lorsque nous décrivons et discutons des processus logiciels, nous parlons généralement des activités de ces processus, comme la spécification d’un modèle de données, la conception d’une interface utilisateur, etc. et de l’ordre de ces activités.Les descriptions de processus peuvent également inclure :

• Les produits, qui sont les résultats d’une activité de processus ;
• Les rôles, qui reflètent les responsabilités des personnes impliquées dans le processus ;
• Les conditions préalables et postérieures, qui sont des énoncés qui sont vrais avant et après qu’une activité de processus ait été promulguée ou qu’un produit ait été produit.

Les processus pilotés par un plan sont des processus où toutes les activités du processus sont planifiées à l’avance et où les progrès sont mesurés par rapport à ce plan. Dans les processus agiles, la planification est incrémentale et il est plus facile de modifier le processus pour refléter l’évolution des exigences des clients. Dans la pratique, la plupart des processus pratiques comprennent des éléments des deux approches, planifiée et agile.

Le modèle en cascade Modèle piloté par le plan. Phases séparées et distinctes de spécification, de conception du logiciel, d’implémentation, de test et de maintenance. Développement incrémentiel La spécification, le développement et la validation sont imbriqués. Le système est développé sous la forme d’une série de versions (incréments), chaque version ajoutant des fonctionnalités à la version précédente. Peut être piloté par un plan ou agile. Intégration et configuration Basé sur l’existence d’un nombre important de composants/systèmes réutilisables. Le processus de développement du système se concentre sur l’intégration de ces composants dans un système plutôt que de les développer à partir de zéro. Peut être piloté par un plan ou agile.

Dans la pratique, la plupart des grands systèmes sont développés à l’aide d’un processus qui incorpore des éléments de tous ces modèles.

Il y a des phases distinctes identifiées dans le modèle en cascade :

Analyse et définition des exigences Les services, les contraintes et les objectifs du système sont établis en consultant les utilisateurs du système. Ils sont ensuite définis en détail et servent de spécification du système. Conception du système et du logiciel Le processus de conception des systèmes attribue les exigences aux systèmes matériels ou logiciels en établissant une architecture globale du système. La conception du logiciel consiste à identifier et à décrire les abstractions fondamentales du système logiciel et leurs relations. Implémentation et tests unitaires Au cours de cette étape, la conception du logiciel est réalisée sous la forme d’un ensemble de programmes ou d’unités de programme. Les tests unitaires consistent à vérifier que chaque unité répond à ses spécifications. Intégration et tests du système Les différentes unités de programme ou programmes sont intégrés et testés en tant que système complet afin de s’assurer que les exigences du logiciel ont été satisfaites. Après les tests, le système logiciel est livré au client. Exploitation et maintenance Normalement (mais pas nécessairement), cette phase du cycle de vie est la plus longue. Le système est installé et mis en service. La maintenance consiste à corriger les erreurs qui n’ont pas été découvertes lors des étapes précédentes du cycle de vie, à améliorer la mise en œuvre des unités du système et à améliorer les services du système à mesure que de nouvelles exigences sont découvertes.

Le principal inconvénient du modèle en cascade est la difficulté de s’adapter aux changements une fois le processus en cours. En principe, une phase doit être terminée avant de passer à la phase suivante. Les problèmes du modèle en cascade sont les suivants :

Difficulté à faire face au changement Le cloisonnement inflexible du projet en étapes distinctes rend difficile la réponse à l’évolution des exigences du client.Par conséquent, ce modèle n’est approprié que lorsque les exigences sont bien comprises et que les changements seront assez limités pendant le processus de conception. Peu de systèmes d’entreprise ont des exigences stables. Très peu d’applications dans le monde réel Le modèle en cascade est surtout utilisé pour les grands projets d’ingénierie de systèmes où un système est développé sur plusieurs sites.Dans ces circonstances, la nature planifiée du modèle en cascade aide à coordonner le travail.

Avantages du développement incrémental :

Coût réduit des changements Le coût de l’adaptation aux exigences changeantes des clients est réduit. La quantité d’analyse et de documentation à refaire est bien moindre que ce qui est requis avec le modèle en cascade. Retour d’information fréquent Il est plus facile d’obtenir un retour d’information du client sur le travail de développement effectué. Les clients peuvent commenter les démonstrations du logiciel et voir dans quelle mesure il a été mis en œuvre. Livraison plus rapide Il est possible de livrer et de déployer plus rapidement des logiciels utiles pour le client. Les clients sont en mesure d’utiliser et d’obtenir de la valeur du logiciel plus tôt que ce qui est possible avec un processus en cascade.

Problèmes avec le développement incrémental (du point de vue de la gestion):

Le processus n’est pas visible Les gestionnaires ont besoin de livrables réguliers pour mesurer les progrès. Si les systèmes sont développés rapidement, il n’est pas rentable de produire des documents qui reflètent chaque version du système. La structure du système tend à se dégrader au fur et à mesure que de nouveaux incréments sont ajoutés À moins que du temps et de l’argent ne soient consacrés au refactoring pour améliorer le logiciel, les changements réguliers tendent à corrompre sa structure. L’incorporation de nouvelles modifications du logiciel devient de plus en plus difficile et coûteuse.

Cette approche est basée sur la réutilisation systématique où les systèmes sont intégrés à partir de composants existants ou de systèmes COTS (Commercial-off-the-shelf).Les étapes du processus comprennent:

• Analyse des composants;
• Modification des exigences;
• Conception du système avec réutilisation;
• Développement et intégration.

La réutilisation est maintenant l’approche standard pour construire de nombreux types de systèmes d’entreprise.

Types de composants logiciels :

• Services Web qui sont développés selon des normes de service et qui sont disponibles pour une invocation à distance.
• Collections d’objets qui sont développées comme un paquet à intégrer avec un cadre de composants tel que .NET ou J2EE.
• Systèmes autonomes du commerce (COTS) qui sont configurés pour être utilisés dans un environnement particulier.

Les véritables processus logiciels sont des séquences imbriquées d’activités techniques, collaboratives et managériales ayant pour objectif global de spécifier, concevoir, mettre en œuvre et tester un système logiciel.

Les quatre activités de base du processus que sont la spécification, le développement, la validation et l’évolution sont organisées différemment selon les processus de développement. Dans le modèle de la cascade, elles sont organisées en séquence, alors que dans le développement incrémental, elles sont intercalées.

Spécification du logiciel Processus consistant à établir les services requis et les contraintes relatives au fonctionnement et au développement du système. Processus d’ingénierie des exigences :

• Étude de faisabilité : est-il techniquement et financièrement possible de construire le système ?
• Élicitation et analyse des exigences : qu’est-ce que les parties prenantes du système exigent ou attendent du système ?
• Spécification des exigences : définir les exigences en détail
• Validation des exigences : vérifier la validité des exigences

Conception et mise en œuvre du logiciel Processus consistant à convertir la spécification du système en un système exécutable.

• Conception logicielle : concevoir une structure logicielle qui réalise la spécification;
• Mise en œuvre : traduire cette structure en un programme exécutable;

Les activités de conception et de mise en œuvre sont étroitement liées et peuvent être imbriquées. Les activités de conception comprennent :

• La conception architecturale : identifier la structure globale du système, les principaux composants (parfois appelés sous-systèmes ou modules), leurs relations et la façon dont ils sont répartis.
• La conception des interfaces : définir les interfaces entre les composants du système.
• Conception des composants : prendre chaque composant du système et concevoir comment il va fonctionner.
• Conception de la base de données : concevoir les structures de données du système et la façon dont elles doivent être représentées dans une base de données.

Validation du logiciel La vérification et la validation (V & V) visent à montrer qu’un système est conforme à sa spécification et répond aux exigences du client du système.

• Validation : construisons-nous le bon produit (ce que le client veut) ?
• Vérification : construisons-nous le bon produit ?

V & V implique des processus de vérification et de révision et des tests de système. Le test du système consiste à exécuter le système avec des cas de test qui sont dérivés de la spécification des données réelles à traiter par le système. Les tests sont l’activité V & V la plus utilisée et comprennent les étapes suivantes :

• Test de développement ou de composants : les composants individuels sont testés indépendamment ; les composants peuvent être des fonctions ou des objets ou des groupements cohérents de ces entités.
• Test du système : test du système dans son ensemble, le test des propriétés émergentes est particulièrement important.
• Test d’acceptation : test avec les données du client pour vérifier que le système répond aux besoins du client.

Evolution du logiciel Le logiciel est intrinsèquement flexible et peut changer. Comme les exigences changent à travers les circonstances commerciales changeantes, le logiciel qui soutient l’entreprise doit également évoluer et changer.Bien qu’il y ait eu une démarcation entre le développement et l’évolution (maintenance), cela est de moins en moins pertinent car de moins en moins de systèmes sont complètement nouveaux.

Le changement est inévitable dans tous les grands projets logiciels.Les changements dans l’entreprise entraînent des exigences nouvelles et modifiées pour le systèmeLes nouvelles technologies ouvrent de nouvelles possibilités pour améliorer les mises en œuvre.Les changements de plates-formes nécessitent des changements d’application.Le changement entraîne des remaniements, de sorte que les coûts du changement comprennent à la fois les remaniements (par ex.par exemple, la réanalyse des exigences) que les coûts de mise en œuvre de nouvelles fonctionnalités.

Deux stratégies pour réduire les coûts de reprise :

Éviter les changements Le processus logiciel comprend des activités qui peuvent anticiper les changements possibles avant qu’une reprise significative ne soit nécessaire. Par exemple, un système prototype peut être développé pour montrer certaines caractéristiques clés du système aux clients. Tolérance au changement Le processus est conçu de manière à ce que les changements puissent être pris en compte à un coût relativement faible, ce qui implique normalement une forme de développement incrémentiel. Les changements proposés peuvent être mis en œuvre dans des incréments qui n’ont pas encore été développés. Si cela est impossible, alors un seul incrément (une petite partie du système) peut devoir être modifié pour intégrer le changement.

Un prototype est une version initiale d’un système utilisée pour démontrer des concepts et essayer des options de conception. Un prototype peut être utilisé dans :

• Le processus d’ingénierie des exigences pour aider à l’élicitation et à la validation des exigences ;
• Dans les processus de conception pour explorer les options et développer un design d’interface utilisateur ;
• Dans le processus de test pour exécuter des tests dos à dos.

Avantages du prototypage :

• Amélioration de la convivialité du système.
• Un rapprochement avec les besoins réels des utilisateurs.
• Amélioration de la qualité de la conception.
• Amélioration de la maintenabilité.
• Réduction de l’effort de développement.

Les prototypes peuvent être basés sur des langages ou des outils de prototypage rapide. Ils peuvent impliquer de laisser de côté des fonctionnalités :

• Le prototype doit se concentrer sur les domaines du produit qui ne sont pas bien compris ;
• La vérification et la récupération des erreurs peuvent ne pas être incluses dans le prototype ;
• Focus sur les exigences fonctionnelles plutôt que non fonctionnelles telles que la fiabilité et la sécurité.

Les prototypes doivent être jetés après le développement car ils ne constituent pas une bonne base pour un système de production :

• Il peut être impossible de régler le système pour répondre aux exigences non fonctionnelles ;
• Les prototypes sont normalement non documentés ;
• La structure du prototype est généralement dégradée par des changements rapides ;
• Le prototype ne répondra probablement pas aux normes de qualité normales de l’organisation.

Plutôt que de livrer le système en une seule fois, le développement et la livraison sont décomposés en incréments, chaque incrément livrant une partie de la fonctionnalité requise.Les exigences des utilisateurs sont classées par ordre de priorité et les exigences les plus prioritaires sont incluses dans les premiers incréments.Une fois que le développement d’un incrément est lancé, les exigences sont gelées bien que les exigences pour les incréments ultérieurs puissent continuer à évoluer.

Avantages de la livraison incrémentale:

• La valeur pour le client peut être livrée avec chaque incrément de sorte que la fonctionnalité du système est disponible plus tôt.
• Les premiers incréments agissent comme un prototype pour aider à éliciter les exigences pour les incréments ultérieurs.
• Plus faible risque d’échec global du projet.
• Les services du système les plus prioritaires ont tendance à recevoir le plus de tests.

Problèmes de la livraison incrémentale:

• La plupart des systèmes nécessitent un ensemble d’installations de base qui sont utilisées par différentes parties du système. Comme les exigences ne sont pas définies en détail jusqu’à ce qu’un incrément doive être mis en œuvre, il peut être difficile d’identifier les installations communes qui sont nécessaires à tous les incréments.
• L’essence des processus itératifs est que la spécification est développée en même temps que le logiciel. Cependant, cela entre en conflit avec le modèle d’approvisionnement de nombreuses organisations, où la spécification complète du système fait partie du contrat de développement du système.

De nombreuses entreprises de logiciels se sont tournées vers l’amélioration des processus logiciels pour améliorer la qualité de leurs logiciels, réduire les coûts ou accélérer leurs processus de développement. L’amélioration des processus consiste à comprendre les processus existants et à modifier ces processus pour augmenter la qualité du produit et/ou réduire les coûts et le temps de développement.

Approche de la maturité des processus Se concentre sur l’amélioration de la gestion des processus et des projets et sur l’introduction de bonnes pratiques d’ingénierie logicielle. Le niveau de maturité des processus reflète la mesure dans laquelle les bonnes pratiques techniques et de gestion ont été adoptées dans les processus de développement logiciel de l’organisation. Approche agile Se concentre sur le développement itératif et la réduction des frais généraux dans le processus logiciel. Les principales caractéristiques des méthodes agiles sont la livraison rapide des fonctionnalités et la réactivité aux exigences changeantes des clients.

Les activités d’amélioration des processus forment un cycle continu avec une boucle de rétroaction :

• Mesurer un ou plusieurs attributs du processus ou du produit logiciel. Ces mesures forment une ligne de base qui aide à décider si les améliorations du processus ont été efficaces.
• Analyser le processus actuel et identifier les goulots d’étranglement.
• Modifier le processus pour remédier à certaines des faiblesses du processus identifiées. Ceux-ci sont introduits et le cycle reprend pour collecter des données sur l’efficacité des changements.

Mesure du processus

• Dans la mesure du possible, des données quantitatives sur le processus doivent être collectées.
• Les mesures du processus doivent être utilisées pour évaluer les améliorations du processus.
• Les mesures peuvent inclure :
  • Temps pris pour l’achèvement des activités du processus, par ex.g. le temps calendaire ou l’effort nécessaire pour achever une activité ou un processus.
  • Ressources requises pour les processus ou les activités, par exemple l’effort total en jours-personnes.
  • Nombre d’occurrences d’un événement particulier, par exemple le nombre de défauts découverts.

Le modèle de maturité des capacités du SEI

• Initial : Essentiellement non contrôlé
• Répétable : Procédures de gestion du produit définies et utilisées
• Défini : Procédures et stratégies de gestion des processus définies et utilisées
• Géré : Stratégies de gestion de la qualité définies et utilisées
• Optimisation : Stratégies d’amélioration des processus définies et utilisées

.