Modèles de cycle de vie

Auteurs principaux : Kevin Forsberg, Rick Adcock, auteur collaborateur : Alan Faisandier

Le modèle de cycle de vie est l’un des concepts clés de l’ingénierie des systèmes (SE). Un cycle de vieLe cycle de vie d’un système-système consiste généralement en une série d’étapesdes étapes régulées par un ensemble de décisions de gestion qui confirment que le système est suffisamment mature pour quitter une étape et entrer dans une autre.

Thèmes

Chaque partie du SEBoK est divisée en domaines de connaissances (KA), qui sont des regroupements d’informations ayant un thème connexe. Les domaines de connaissances sont à leur tour divisés en sujets. Ce KA contient les sujets suivants :

• Moteurs et choix de processus du cycle de vie du système
• Modèles de processus du cycle de vie du système : Vee
• Modèles de processus du cycle de vie du système : Itératif
• Intégration des modèles de processus et de produits
• Lean Engineering

Voir l’article Matrice d’exemples de mise en œuvre pour une mise en correspondance des études de cas et des vignettes incluses dans la partie 7 avec les sujets traités dans la partie 3.

Type de produits/services à valeur ajoutée

Le modèle de cycle de vie générique montre juste l’approche à une seule étape pour procéder aux étapes du cycle de vie d’un système. L’ajout de valeur (en tant que produit, service ou les deux) est un objectif commun à toutes les entreprises, qu’elles soient publiques ou privées, à but lucratif ou non. La valeur est produite en fournissant et en intégrant les éléments d’un système dans un produit ou un service conformément à la description du système et en le transformant en une utilisation productive. Ces considérations sur la valeur conduiront à diverses formes de l’approche générique de gestion du cycle de vie présentée à la figure 1. En voici quelques exemples (Lawson 2010):

• Une entreprise manufacturière produit des écrous, des boulons et des rondelles de sécurité, puis vend ses produits en tant qu’éléments à valeur ajoutée destinés à être utilisés par d’autres entreprises ; à leur tour, ces entreprises intègrent ces produits dans leur système à valeur ajoutée plus englobant, comme un avion ou une automobile. Leurs exigences seront généralement pré-spécifiées par le client ou par les normes industrielles.

• Une entreprise de vente en gros ou au détail offre des produits à ses clients. Ses clients (particuliers ou entreprises) acquièrent les produits et les utilisent comme éléments de leurs systèmes. Le système de soutien de l’entreprise évoluera probablement de manière opportuniste, à mesure que de nouvelles capacités d’infrastructure ou de nouveaux modèles de demande émergeront.

• Une entreprise de services commerciaux telle qu’une banque vend une variété de produits en tant que services à ses clients. Cela comprend les comptes courants, les comptes d’épargne, les prêts et la gestion des investissements. Ces services apportent une valeur ajoutée et sont incorporés dans les systèmes clients des individus ou des entreprises. Le système de soutien de l’entreprise de services est également susceptible d’évoluer de manière opportuniste, à mesure que de nouvelles capacités d’infrastructure ou de nouveaux modèles de demande apparaissent.

• Une entreprise de services gouvernementaux fournit aux citoyens des services qui varient considérablement, mais qui peuvent inclure des services tels que les soins de santé, les autoroutes et les routes, les pensions, l’application de la loi ou la défense. Le cas échéant, ces services deviennent des éléments d’infrastructure utilisés dans des systèmes plus vastes et englobants qui intéressent les particuliers et/ou les entreprises. Les initiatives majeures, telles qu’un système de contrôle du trafic aérien de nouvelle génération ou un système de gestion de crise à l’échelle d’une métropole (ouragan, typhon, tremblement de terre, tsunami, inondation, incendie), seront suffisamment complexes pour suivre une approche de développement et de mise en service évolutive. Au niveau élémentaire, il y aura probablement des cycles de vie pré-spécifiés à passage unique.

• Pour les systèmes aéronautiques et automobiles, il y aurait probablement un cycle de vie pré-spécifié à passages multiples pour capitaliser sur les premières capacités dans le premier passage, mais architecturé pour ajouter d’autres capacités à valeur ajoutée dans les passages ultérieurs.

• Une entreprise diversifiée de développement de logiciels fournit des produits logiciels qui répondent aux exigences (besoins) des parties prenantes, fournissant ainsi des services aux utilisateurs du produit. Elle devra être développée pour avoir des capacités qui peuvent être adaptées pour être utilisées dans les différentes approches du cycle de vie des clients et aussi avec des capacités de ligne de produits qui peuvent être rapidement et facilement appliquées aux développements de systèmes similaires des clients. Son modèle d’affaires peut également inclure la fourniture au client de capacités de soutien et d’évolution du cycle de vie du système.

Dans ces exemples, il y a des systèmes qui restent stables sur des périodes raisonnablement longues et d’autres qui changent rapidement. La diversité représentée par ces exemples et leurs processus illustre pourquoi il n’existe pas de processus unique pouvant être utilisé pour définir un cycle de vie de systèmes spécifique. Les approches de gestion et de leadership doivent tenir compte du type de systèmes concernés, de leur longévité et de la nécessité de s’adapter rapidement aux changements imprévus, qu’il s’agisse de la concurrence, de la technologie, du leadership ou des priorités de la mission. A leur tour, les approches de gestion et de leadership ont un impact sur le type et le nombre de modèles de cycle de vie qui sont déployés ainsi que sur les processus qui seront utilisés dans tout cycle de vie particulier.

Il existe plusieurs approches incrémentales et évolutives pour séquencer les étapes du cycle de vie afin de traiter certaines des questions soulevées ci-dessus. Le domaine de connaissances Modèles de cycle de vie résume un certain nombre de modèles de cycle de vie incrémentaux et évolutifsévolutifs, y compris leurs principales forces et faiblesses, et discute également des critères pour choisir l’approche la mieux adaptée.

Catégories de modèle de cycle de vie

Le modèle de cycle de vie du système générique de la figure 1 ne s’adapte pas explicitement à toutes les situations. Un système simple, précédant et suivant peut n’avoir besoin que d’une seule phase dans l’étape de définition, alors qu’un système complexe peut en nécessiter plus de deux. Dans le cas des systèmes à construire (par opposition aux prototypes jetables), une grande partie du développement peut avoir lieu pendant la phase de définition. L’intégration, la vérification et la validation du système peuvent suivre la mise en œuvre ou l’acquisition des éléments du système. Dans le cas des logiciels, en particulier ceux qui sont testés en premier et ceux qui sont construits quotidiennement, l’intégration, la vérification et la validation sont intimement liées à la mise en œuvre des éléments. De plus, avec la troisième révolution industrielle à venir, celle de l’impression tridimensionnelle et de la fabrication numérique (Whadcock 2012), non seulement le développement initial mais aussi la production initiale peuvent être réalisés pendant la phase de conception.

Le logiciel est un support flexible et malléable qui facilite l’analyse itérative, la conception, la construction, la vérification et la validation à un degré plus élevé que ce qui est généralement possible pour les composants purement physiques d’un système. Chaque répétition d’un modèle de développement itératif ajoute du matériel (code) à la base logicielle en expansion, dans laquelle la base de code élargie est testée, retravaillée si nécessaire, et dont il est démontré qu’elle satisfait aux exigences de la ligne de base.

Le logiciel peut être acheté, vendu, livré et mis à niveau électroniquement partout dans le monde à portée de communication numérique, ce qui rend sa logistique sensiblement différente et plus rentable que le matériel. Il ne s’use pas et ses correctifs modifient son contenu et son comportement, ce qui rend les tests de régression plus complexes qu’avec les correctifs matériels. En raison de sa nature discrète, ses tests ne peuvent pas compter sur la continuité analytique comme c’est le cas pour le matériel. L’ajout de 1 à 32767 dans un registre de 15 bits ne produit pas 32768, mais 0 au lieu de cela, comme cela a été expérimenté dans des situations graves, telles que l’utilisation du missile Patriot.

Il existe un grand nombre de modèles potentiels de processus de cycle de vie. Ils se répartissent en trois grandes catégories :

1. primairement des processus pré-spécifiés et séquentiels (par exemple, le modèle en cascade à une étape)
2. primairement des processus évolutifs et simultanés (par exemple, le développement allégé, le processus rationnel unifié et diverses formes des modèles en V et en spirale)
3. primairement des processus interpersonnels et émergents (par exemple. le développement agile, la mêlée, la programmation extrême (XP), la méthode de développement de systèmes dynamiques et les processus fondés sur l’innovation)

L’émergence de systèmes matériels-logiciels intégrés et interactifs a rendu les processus pré-spécifiés potentiellement nuisibles, car les interfaces homme-système les plus efficaces ont eu tendance à émerger avec son utilisation, ce qui a conduit à d’autres variations de processus, comme le SE doux (Warfield 1976, Checkland 1981) et les processus d’intégration homme-système (Booher 2003, Pew et Mavor 2007). Jusqu’à récemment, les normes de processus et les modèles de maturité ont tenté de couvrir toutes les éventualités. Ils comprenaient des processus étendus pour la gestion des acquisitions, la sélection des sources, les examens et les audits, l’assurance qualité, la gestion de la configuration et la gestion des documents, qui, dans de nombreux cas, devenaient trop bureaucratiques et inefficaces. Cela a conduit à l’introduction d’approches plus allégées (Ohno 1988 ; Womack et al. 1990 ; Oppenheim 2011) et agiles (Beck 1999 ; Anderson 2010) pour les approches concurrentes matériel-logiciel-facteurs humains, telles que les modèles en V concurrents (Forsberg 1991 ; Forsberg 2005) et le modèle en spirale d’engagement incrémental (Pew et Mavor 2007 ; Boehm et Lane 2007).

Dans le prochain article sur les moteurs et les choix de processus du cycle de vie des systèmes, ces variations sur le thème des modèles de cycle de vie seront identifiées et présentées.

Responsabilité de l’ingénierie des systèmes

Qu’importe les modèles de cycle de vie déployés, le rôle de l’ingénieur de systèmes englobe l’ensemble du cycle de vie du système d’intérêt. Les ingénieurs systèmes orchestrent le développement et l’évolution d’une solution, de la définition des besoins à l’exploitation et finalement jusqu’au retrait du système. Ils s’assurent que les experts du domaine sont correctement impliqués, que toutes les opportunités avantageuses sont exploitées et que tous les risques importants sont identifiés et, si possible, atténués. L’ingénieur système travaille en étroite collaboration avec le chef de projet pour adapter le cycle de vie générique, y compris les principaux points de décisionpoints de décision, afin de répondre aux besoins de leur projet spécifique.

Les tâches d’ingénierie des systèmes sont généralement concentrées au début du cycle de vie ; cependant, les organisations commerciales et gouvernementales reconnaissent la nécessité de l’ES tout au long du cycle de vie du système. Souvent, cet effort continu consiste à modifier ou à changer un système, un produit ou un service après son entrée en production ou sa mise en service. Par conséquent, l’ES est une partie importante de toutes les étapes du cycle de vie. Au cours des étapes de production, de soutien et d’utilisation (PSU), par exemple, le SE exécute l’analyse des performances, la surveillance des interfaces, l’analyse des défaillances, l’analyse logistique, le suivi et l’analyse des changements proposés. Toutes ces activités sont essentielles au soutien continu du système.

Tous les gestionnaires de projet doivent s’assurer que l’aspect commercial (coût, calendrier et valeur) et l’aspect technique du cycle de projet restent synchronisés. Souvent, l’aspect technique dirige le projet. Il incombe aux ingénieurs système de s’assurer que les solutions techniques envisagées sont compatibles avec les objectifs de coût et de calendrier. Cela peut nécessiter de travailler avec les utilisateurs et les clients pour réviser les objectifs afin de les adapter aux limites de l’entreprise. Ces questions justifient également la nécessité d’espacer les points de décision de manière appropriée tout au long du cycle du projet. Bien que la nature de ces points de décision varie selon les grandes catégories ci-dessus, chacun d’entre eux implique une validation en cours de processus entre les développeurs et les utilisateurs finaux. La validation en cours de processus pose la question suivante : « Ce que nous planifions ou créons va-t-il satisfaire les besoins des parties prenantes ? » La validation en cours de processus commence à l’initialisation du projet pendant la découverte des besoins de l’utilisateur et se poursuit à travers les activités quotidiennes, les examens formels de la porte de décision, la livraison du produit final ou de la solution, les opérations, et finalement jusqu’à la fermeture et l’élimination du système.

Works Cited

Anderson, D. 2010. Kanban. Sequim, WA : Blue Hole Press.

Beck, K. 1999. Extreme Programming Explained. Boston, MA : Addison Wesley.

Boehm, B. et J. Lane. 2007. « Utilisation du modèle d’engagement incrémentiel pour intégrer l’acquisition de systèmes, l’ingénierie des systèmes et l’ingénierie logicielle ». CrossTalk. Octobre 2007 : 4-9.

Booher, H. (ed.) 2003. Handbook of Human Systems Integration (Manuel d’intégration des systèmes humains). Hoboken, NJ, USA : Wiley.

Checkland, P. 1999. Systems Thinking, Systems Practice, 2nd ed. Hoboken, NJ, USA : Wiley.

Cusumano, M., et D. Yoffie. 1998. Competing on Internet Time, New York, NY, USA : The Free Press.

Forsberg, K. et H. Mooz. 1991. « The Relationship of System Engineering to the Project Cycle », Proceedings of INCOSE, octobre 1991.

Forsberg, K., H. Mooz, et H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ : J. Wiley & Sons.

ISO/IEC/IEEE. 2015.Ingénierie des systèmes et des logiciels – processus du cycle de vie des systèmes.Genève, Suisse : Organisation internationale de normalisation (ISO)/Commission électrotechnique internationale (CEI), Institute of Electrical and Electronics Engineers.ISO/IEC 15288:2015.

Lawson, H. 2010. Un voyage à travers le paysage des systèmes. Londres, Royaume-Uni : College Publications.

Ohno, T. 1988. Système de production Toyota. New York, NY : Productivity Press.

Oppenheim, B. 2011. Lean pour l’ingénierie des systèmes. Hoboken, NJ : Wiley.

Pew, R. et A. Mavor (eds.). 2007. L’intégration homme-système dans le processus de développement des systèmes : A New Look. Washington, DC, USA : The National Academies Press.

Warfield, J. 1976. Systems Engineering. Washington, DC, USA : Département américain du commerce (DoC).

Whadcock, I. 2012. « Une troisième révolution industrielle ». The Economist. 21 avril 2012.

Womack, J.P., D.T. Jones, et D. Roos 1990. La machine qui a changé le monde : L’histoire de la production allégée. New York, NY, USA : Rawson Associates.

Références primaires

Blanchard, B.S., et W.J. Fabrycky. 2011. Ingénierie et analyse des systèmes, 5e éd. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA : Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3e éd. Hoboken, NJ : J. Wiley & Sons.

INCOSE. 2012. Manuel d’ingénierie des systèmes, version 3.2.2. San Diego, CA, USA : Conseil international de l’ingénierie des systèmes (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Un voyage à travers le paysage des systèmes. Londres, Royaume-Uni : College Publications.

Pew, R. et A. Mavor (Eds.). 2007. L’intégration homme-système dans le processus de développement des systèmes : A New Look. Washington, DC, USA : The National Academies Press.

Références supplémentaires

Chrissis, M., M. Konrad, et S. Shrum. 2003. CMMI : Directives pour l’intégration des processus et l’amélioration des produits. New York, NY, USA : Addison Wesley.

Larman, C. et B. Vodde. 2009. Scaling Lean and Agile Development. New York, NY, USA : Addison Wesley.

Les trois livres suivants ne sont pas référencés dans le texte du SEBoK, et ne sont pas non plus des  » textes  » d’ingénierie des systèmes ; cependant, ils contiennent d’importantes leçons d’ingénierie des systèmes, et les lecteurs de ce SEBOK sont encouragés à les lire.

Kinder, G. 1998. Navire d’or dans la grande mer bleue. New York, NY, USA : Grove Press.

C’est un excellent livre qui suit une idée de sa conception à sa mise en œuvre finalement réussie. Bien que l’ingénierie des systèmes ne soit pas abordée, elle est clairement illustrée dans l’ensemble du processus, de la définition précoce du projet à l’élaboration de concepts alternatifs, en passant par l’exploration par étapes et les « expériences de pensée », jusqu’à la résolution des difficultés en cours de route. Il montre également le problème de ne pas anticiper les problèmes critiques en dehors du champ habituel du projet et de l’ingénierie. Il a fallu environ cinq ans pour localiser et récupérer les 24 tonnes de lingots d’or et de pièces de monnaie du navire coulé dans l’océan à 2 500 mètres de profondeur, mais il a fallu dix ans pour gagner la bataille juridique avec les avocats représentant les compagnies d’assurance qui revendiquaient la propriété sur la base de polices vieilles de 130 ans qu’elles avaient émises aux propriétaires de l’or en 1857.

McCullough, D. 1977. Le chemin entre les mers : la création du canal de Panama (1870 – 1914). New York, NY, USA : Simon & Schuster.

Bien que l' »ingénierie des systèmes » ne soit pas mentionnée, ce livre met en évidence de nombreuses questions d’ingénierie des systèmes et illustre le besoin de SE en tant que discipline. Le livre illustre également le danger d’appliquer un concept précédemment réussi (le canal de niveau de la mer utilisé à Suez une décennie plus tôt) dans une situation similaire mais différente. Ferdinand de Lesseps a dirigé les projets de Suez et de Panama. Il illustre le danger de l’absence d’un cycle de projet basé sur les faits et de portes de décision significatives tout au long du cycle du projet. Elle met également en évidence le danger de fournir un statut de projet sans visibilité. Cinq ans après le début du projet décennal, les investisseurs ont appris que le projet était achevé à plus de 50 %, alors qu’en réalité, seuls 10 % des travaux étaient terminés. La deuxième phase de développement, menée par Stevens en 1904, s’est concentrée sur le « déplacement de la terre » plutôt que sur le creusement d’un canal, un concept d’ingénierie des systèmes essentiel à l’achèvement du canal. The Path Between the Seas a remporté le National Book Award for history (1978), le prix Francis Parkman (1978), le prix Samuel Eliot Morison (1978) et le prix Cornelius Ryan (1977).

Shackleton, Sir E.H. 2008. (Publié à l’origine dans par William Heinemann, Londres, 1919). Sud : La dernière expédition antarctique de Shackleton et de l’Endurance. Guilford, CT, USA : Lyons Press.

C’est l’histoire étonnante de la dernière expédition antarctique de Shackleton et de l’Endurance de 1914 à 1917. La leçon d’ingénierie des systèmes est l’évaluation continue et quotidienne des risques par le capitaine, le chef d’expédition et l’équipage alors qu’ils sont restés coincés dans la glace arctique pendant 18 mois. Les 28 membres d’équipage ont survécu.

Vidéos pertinentes

• Approche de la NASA en matière d’ingénierie des systèmes – Ingénierie des systèmes spatiaux 101 w/ NASA