Modèles de processus du cycle de vie des systèmes : Vee

Auteurs principaux : Dick Fairley, Kevin Forsberg, auteur collaborateur : Ray Madachy

Il existe un grand nombre de modèles de processus de cycle de vie. Comme indiqué dans l’article Moteurs et choix de processus du cycle de vie des systèmes, ces modèles se répartissent en trois grandes catégories : (1) les processus principalement préspécifiés et séquentiels ; (2) les processus principalement évolutifs et simultanés (par exemple, le processus rationnel unifié et diverses formes des modèles Vee et en spirale) ; et (3) les processus principalement interpersonnels et sans contrainte (par exemple, le développement agile, Scrum, la programmation extrême (XP), la méthode de développement de systèmes dynamiques et les processus basés sur l’innovation).

Cet article se concentre spécifiquement sur le modèle Vee comme principal exemple de processus préspécifiés et séquentiels. Dans cette discussion, il est important de noter que le modèle Vee, et les variations du modèle Vee, abordent tous le même ensemble de base d’activités d’ingénierie des systèmes (SE). La principale différence entre ces modèles est la façon dont ils regroupent et représentent les activités SE susmentionnées.

Les implications générales de l’utilisation du modèle Vee pour la conception et le développement de systèmes sont abordées ci-dessous ; pour une compréhension plus spécifique de la façon dont ce modèle de cycle de vie a un impact sur les activités d’ingénierie des systèmes, veuillez consulter les autres domaines de connaissances (KA) dans la partie 3.

Un modèle de processus principalement préspécifié et séquentiel : Le modèle Vee

La version séquentielle du modèle Vee est présentée à la figure 1. Son noyau implique une progression séquentielle des plans, des spécifications et des produits qui sont baselinés et mis sous gestion de configuration. La flèche verticale à deux têtes permet aux projets d’effectuer des analyses simultanées des opportunités et des risques, ainsi qu’une validation continue en cours de processus. Le modèle Vee englobe les trois premières étapes du cycle de vie énumérées dans le tableau  » Étapes du cycle de vie générique  » du manuel d’ingénierie des systèmes de l’INCOSE : recherche exploratoire, concept et développement (INCOSE 2012).

Figure 1. Côté gauche du modèle séquentiel Vee (Forsberg, Mooz et Cotterman 2005). Reproduit avec la permission de John Wiley & Sons Inc. Tous les autres droits sont réservés par le propriétaire du droit d’auteur.

Le modèle Vee approuve la définition des étapes du cycle de vie et de leurs objectifs ou activités du manuel d’ingénierie des systèmes de l’INCOSE (INCOSE 2012), comme le montre la figure 2 ci-dessous.

Figure 2. Un exemple des étapes, de leurs buts et des principaux points de décision. (SEBoK Original)

Le INCOSE Systems Engineering Handbook 3.2.2 contient une version plus détaillée du diagramme de Vee (2012, Figures 3-4, p. 27) qui intègre les activités du cycle de vie dans le modèle de Vee plus générique. Un diagramme similaire, développé à la Defense Acquisition University (DAU) des États-Unis, peut être vu dans la figure 3 ci-dessous.

Figure 3. Le diagramme d’activité Vee (Prosnik 2010). Publié par l’Université d’acquisition de la défense (DAU)/Département de la défense des États-Unis (DoD).

Application du modèle Vee

Lawson (Lawson 2010) développe les activités de chaque étape du cycle de vie et note qu’il est utile de considérer la structure d’un modèle générique d’étape du cycle de vie pour tout type de système d’intérêt (SoI), tel que représenté à la figure 4. Ce modèle (T) indique qu’une ou plusieurs étapes de définition précèdent une ou plusieurs étapes de production où la mise en œuvre (acquisition, approvisionnement ou développement) de deux ou plusieurs éléments du système a été accomplie.

Figure 4. Structure générique (T) des étapes des modèles de cycle de vie des systèmes (Lawson 2010). Réimprimé avec l’autorisation de Harold Lawson. Tous les autres droits sont réservés par le propriétaire du copyright.

La figure 5 montre les étapes génériques du cycle de vie pour une variété de parties prenantes, d’un organisme de normalisation (ISO/CEI) à des organisations commerciales et gouvernementales. Bien que ces étapes diffèrent dans le détail, elles ont toutes un format séquentiel similaire qui met l’accent sur les activités de base comme indiqué dans la figure 2 (définition, production et utilisation/retrait).

Figure 5. Comparaisons des modèles de cycle de vie (Forsberg, Mooz et Cotterman, 2005). Reproduit avec la permission de John Wiley & Sons. Tous les autres droits sont réservés par le propriétaire du copyright.

Il est important de noter que de nombreuses activités tout au long du cycle de vie sont itérées. C’est un exemple de récursion (glossaire)récursion (glossaire) comme discuté dans l’introduction de la partie 3.

Fondamentaux des étapes du cycle de vie et de la phase de gestion du programme

Pour cette discussion, il est important de noter que :

• Le terme étape fait référence aux différents états d’un système pendant son cycle de vie ; certaines étapes peuvent se chevaucher dans le temps, comme l’étape d’utilisation et l’étape de soutien. Le terme « stade » est utilisé dans la norme ISO/IEC/IEEE 15288.

• Le terme phase fait référence aux différentes étapes du programme qui soutiennent et gèrent la vie du système ; les phases ne se chevauchent généralement pas. Le terme « phase » est utilisé dans de nombreux modèles bien établis comme un équivalent du terme « étape »

Gestion de programmeLa gestion de programme emploie des phases, des jalonsmilestones, et des portes de décisiondes portes de décision qui sont utilisées pour évaluer l’évolution d’un système à travers ses différentes étapes. Les étapes contiennent les activités réalisées pour atteindre les objectifs et servent à contrôler et à gérer la séquence des étapes et les transitions entre chaque étape. Pour chaque projet, il est essentiel de définir et de publier les termes et les définitions connexes utilisés sur les projets respectifs afin de minimiser la confusion.

Un programme typique est composé des phases suivantes :

• La phase de pré-étude, qui identifie les opportunités potentielles pour répondre aux besoins des utilisateurs avec de nouvelles solutions qui ont un sens commercial.
• La phase de faisabilité consiste à étudier la faisabilité des concepts alternatifs pour atteindre une deuxième porte de décision avant d’initier la phase d’exécution. Au cours de la phase de faisabilité, les exigences des parties prenantes et les exigences du système sont identifiées, les solutions viables sont identifiées et étudiées, et des prototypes virtuels (glossaire)prototypes (glossaire) peuvent être mis en œuvre. Au cours de cette phase, la décision d’aller de l’avant est basée sur :
  • si un concept est faisable et est considéré comme capable de contrer une menace identifiée ou d’exploiter une opportunité ;
  • si un concept est suffisamment mature pour justifier la poursuite du développement d’un nouveau produit ou d’une nouvelle ligne de produits ; et
  • s’il faut approuver une proposition générée en réponse à une demande de proposition.
• La phase d’exécution comprend les activités liées aux quatre étapes du cycle de vie du système : développement, production, utilisation et soutien. Généralement, il y a deux portes de décision et deux jalons associés aux activités d’exécution. Le premier jalon donne l’occasion à la direction d’examiner les plans d’exécution avant de donner son feu vert. Le deuxième jalon permet d’examiner les progrès accomplis avant de prendre la décision de lancer la production. Les portes de décision pendant l’exécution peuvent être utilisées pour déterminer s’il faut produire le SdI développé et s’il faut l’améliorer ou le retirer.

Ces points de vue de gestion de programme s’appliquent non seulement au SdI, mais aussi à ses éléments et à sa structure.

Stades du cycle de vie

Les variantes du modèle Vee traitent des mêmes stades généraux d’un cycle de vie :

• Les nouveaux projets commencent généralement par une phase de recherche exploratoire qui comprend généralement les activités de définition du concept, spécifiquement les sujets d’analyse de l’entreprise ou de la mission et la compréhension des besoins et des exigences des parties prenantes. Celles-ci mûrissent à mesure que le projet passe de la phase exploratoire à la phase de concept et à la phase de développement.
• La phase de production comprend les activités de définition et de réalisation du système, ainsi que le développement des exigences (glossaire)exigences (glossaire) et de l’architecture (glossaire)architecture (glossaire) du système par la vérification et la validation.
• La phase d’utilisation comprend les activités de déploiement et d’exploitation du système.
• La phase de soutien comprend les activités de maintenance du système, de logistique et de gestion de la durée de vie du produit et du service, qui peuvent inclure des activités telles que l’extension de la durée de vie ou les mises à jour, les mises à niveau et la modernisation des capacités.
• La phase de retrait comprend les activités d’élimination et de retrait, bien que dans certains modèles, des activités telles que l’extension de la durée de vie ou les mises à jour des capacités, les mises à niveau et la modernisation soient regroupées dans la phase de « retrait ».

Des informations supplémentaires sur chacune de ces étapes peuvent être trouvées dans les sections ci-dessous (voir les liens vers les articles supplémentaires de la partie 3 ci-dessus pour plus de détails). Il est important de noter que ces étapes du cycle de vie, et les activités de chaque étape, sont soutenues par un ensemble de processus de gestion de l’ingénierie des systèmes.

Étape de recherche exploratoire

L’analyse et l’accord des besoins des utilisateurs font partie de l’étape de recherche exploratoire et sont essentiels au développement de systèmes réussis. Sans une bonne compréhension des besoins des utilisateurs, tout système court le risque d’être construit pour résoudre les mauvais problèmes. La première étape de la phase de recherche exploratoire consiste à définir les exigences et les contraintes des utilisateurs (et des parties prenantes). Une partie essentielle de ce processus consiste à établir la faisabilité de la satisfaction des besoins de l’utilisateur, y compris l’évaluation de l’état de préparation de la technologie. Comme pour de nombreuses activités de SE, cela se fait souvent de manière itérative, et les besoins et exigences des parties prenantes sont revus à mesure que de nouvelles informations sont disponibles.

Une étude récente du National Research Council (National Research Council 2008) s’est concentrée sur la réduction du temps de développement des projets de l’US Air Force. Le rapport note que, « en termes simples, l’ingénierie des systèmes est la traduction des besoins d’un utilisateur en une définition d’un système et de son architecture par un processus itératif qui aboutit à une conception efficace du système. » La participation itérative avec les parties prenantes est essentielle à la réussite du projet.

À l’exception de la première et de la dernière porte de décision d’un projet, les portes sont exécutées simultanément. Voir la figure 6 ci-dessous.

Figure 6. Planification des phases de développement. (SEBoK Original)

Étape du concept

Pendant l’étape du concept, des concepts alternatifs sont créés pour déterminer la meilleure approche pour répondre aux besoins des parties prenantes. En envisageant des alternatives et en créant des modèles, y compris des prototypes appropriés, les besoins des parties prenantes seront clarifiés et les problèmes moteurs mis en évidence. Cela peut conduire à une approche incrémentale ou évolutive du développement du système. Plusieurs concepts différents peuvent être explorés en parallèle.

Étape de développement

Le(s) concept(s) sélectionné(s) identifié(s) lors de l’étape de concept sont élaborés en détail jusqu’au niveau le plus bas pour produire la solution qui répond aux exigences des parties prenantesExigences des parties prenantes. Tout au long de cette étape, il est vital de poursuivre l’implication des utilisateurs par la validation en cours de processus (la flèche vers le haut sur les modèles Vee). Sur le matériel, cela se fait par des revues de programme fréquentes et un ou plusieurs représentants résidents du client (le cas échéant). Dans le développement agile, la pratique consiste à intégrer le représentant du client dans l’équipe de développement.

Stade de production

Le stade de production est celui où le SdI est construit ou fabriqué. Des modifications du produit peuvent être nécessaires pour résoudre des problèmes de production, pour réduire les coûts de production ou pour améliorer les capacités du produit ou du SdI. Chacune de ces modifications peut influencer les exigences du système et nécessiter une requalification du systèmequalification, revérificationvérification ou revalidationvalidation. Tous ces changements nécessitent une évaluation SE avant que les changements ne soient approuvés.

Stade d’utilisation

Un aspect important de la gestion du cycle de vie du produit est la fourniture de systèmes de soutien qui sont vitaux pour soutenir le fonctionnement du produit. Alors que le produit ou le service fourni peut être considéré comme le système d’intérêt étroit (NSOI) pour un acquéreur, l’acquéreur doit également intégrer les systèmes de soutien dans un système d’intérêt plus large (WSOI). Ces systèmes de support doivent être considérés comme des actifs système qui, en cas de besoin, sont activés en réponse à une situation qui s’est produite dans le cadre du fonctionnement du NSOI. Le nom collectif de l’ensemble des systèmes de soutien est le système de soutien logistique intégré (SLI).

Il est essentiel d’avoir une vision globale lors de la définition, de la production et de l’exploitation des produits et services du système. Dans la figure 7, la relation entre la conception et le développement du système et les exigences de l’ILS est représentée.

Figure 7. Relation entre l’ILS et le cycle de vie du système (Eichmueller et Foreman 2009). Reproduit avec l’autorisation du Comité directeur S3000L de l’ASD/AIA. Tous les autres droits sont réservés par le propriétaire du droit d’auteur.

Les exigences de fiabilité, qui se traduisent par le besoin de maintenabilité et de testabilité, sont des facteurs moteurs.

Stade de soutien

Dans le stade de soutien, le SdI reçoit des services qui permettent un fonctionnement continu. Des modifications peuvent être proposées pour résoudre des problèmes de supportabilité, pour réduire les coûts opérationnels ou pour prolonger la durée de vie d’un système. Ces modifications nécessitent une évaluation SE afin d’éviter la perte des capacités du système en cours d’exploitation. Le processus technique correspondant est le processus de maintenance.

Stade de retrait

Au stade du retrait, le SdI et ses services connexes sont retirés de l’exploitation. Les activités SE de cette étape sont principalement axées sur la garantie que les exigences d’élimination sont satisfaites. En fait, la planification de l’élimination fait partie de la définition du système pendant l’étape de conception. Les expériences du 20e siècle ont démontré à plusieurs reprises les conséquences de l’absence de prise en compte de la mise hors service et de l’élimination des systèmes dès le départ. Au début du 21e siècle, de nombreux pays ont modifié leurs lois pour tenir le créateur d’un SdI responsable de l’élimination appropriée du système en fin de vie.

Revues du cycle de vie

Pour contrôler l’avancement d’un projet, différents types de revues sont prévus. Les plus couramment utilisées sont énumérées ci-dessous, bien que les noms ne soient pas universels:

• La revue des exigences du système (SRR) est prévue pour vérifier et valider l’ensemble des exigences du système avant de commencer les activités de conception détaillée.
• La revue de conception préliminairela revue de conception préliminaire (PDR) est prévue pour vérifier et valider l’ensemble des exigences du système, les artefacts de conception et les éléments de justification à la fin de la première boucle d’ingénierie (également appelée porte « conception à »).
• La revue de conception critiquela revue de conception critique (CDR) est prévue pour vérifier et valider l’ensemble des exigences du système, les artefacts de conception et les éléments de justification à la fin de la dernière boucle d’ingénierie (les conceptions « build-to » et « code-to » sont libérées après cette revue).
• Les revues d’intégrationintégration, vérificationvérification et validationvalidation sont prévues au fur et à mesure que les composants sont assemblés en sous-systèmes et éléments de niveau supérieur. Une séquence de revues est organisée pour s’assurer que tout s’intègre correctement et qu’il existe des preuves objectives que toutes les exigences ont été satisfaites. Il devrait également y avoir une validation en cours de processus que le système, tel qu’il évolue, répondra aux exigences des parties prenantes (voir la figure 7).
• La revue de validation finale est effectuée à la fin de la phase d’intégration.
• D’autres revues liées à la gestion peuvent être planifiées et réalisées afin de contrôler l’avancement correct des travaux, en fonction du type de système et des risques associés.

Figure 8. Côté droit du modèle Vee (Forsberg, Mooz et Cotterman, 2005). Reproduit avec la permission de John Wiley & Sons Inc. Tous les autres droits sont réservés par le propriétaire du copyright.

Works Cited

Eichmueller, P. et B. Foreman. 2010. S3000LTM. Bruxelles, Belgique : Association des industries aérospatiales et de défense de l’Europe (ASD)/Association des industries aérospatiales (AIA).

Faisandier, A. 2012. Architecture et conception de systèmes. Belberaud, France : Sinergy’Com.

Forsberg, K., H. Mooz, et H. Cotterman. 2005. Visualizing Project Management, 3rd ed. New York, NY, USA : J. Wiley & Sons.

INCOSE. 2012. Manuel d’ingénierie des systèmes : Un guide pour les processus et les activités du cycle de vie 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, Kings College, Royaume-Uni.

Références primaires

Beedle, M., et al. 2009. « The Agile Manifesto : Les principes derrière le manifeste agile « . in Le manifeste agile . Consulté le 04 décembre 2014 à l’adresse www.agilemanifesto.org/principles.html

Boehm, B. et R. Turner. 2004. Équilibrer l’agilité et la discipline. New York, NY, USA : Addison-Wesley.

Fairley, R. 2009. Gérer et diriger des projets logiciels. New York, NY, USA : J. Wiley & Sons.

Forsberg, K., H. Mooz, et H. Cotterman. 2005. Visualizing Project Management. 3rd ed. New York, NY, USA : J. Wiley & Sons.

INCOSE. 2012. Manuel d’ingénierie des systèmes : Un guide pour les processus et les activités du cycle de vie 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. Kings College, UK : 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.

Royce, W.E. 1998. Gestion de projet logiciel : A Unified Framework. New York, NY, USA : Addison Wesley.

Références supplémentaires

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

Baldwin, C. et K. Clark. 2000. Design Rules : The Power of Modularity. Cambridge, MA, USA : MIT Press.

Beck, K. 1999. Extreme Programming Explained. New York, NY, USA : Addison Wesley.

Beedle, M., et al. 2009. « The Agile Manifesto : Principes derrière le manifeste agile « . in Le manifeste agile . Consulté en 2010. Disponible sur : www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, et P. Gruenbacher (eds.). 2005. Value-Based Software Engineering. New York, NY, USA : Springer.

Boehm, B. 1988. « Un modèle en spirale du développement logiciel ». IEEE Computer 21(5) : 61-72.

Boehm, B. 2006. « Quelques tendances futures et leurs implications pour les processus d’ingénierie des systèmes et des logiciels ». Ingénierie des systèmes. 9(1) : 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, et R. Madachy. 1998.  » Using the WinWin Spiral Model : A Case Study ». IEEE Computer. 31(7) : 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (sous presse). Embracing the Spiral Model : Créer des systèmes réussis avec le modèle en spirale de l’engagement incrémentiel. Boston, MA, USA : Addison Wesley.

Castellano, D.R. 2004. « Top Five Quality Software Projects ». CrossTalk. 17(7) (juillet 2004) : 4-19. Disponible à : http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Pensée systémique, pratique systémique. New York, NY, USA : Wiley.

Crosson, S. et B. Boehm. 2009.  » Ajustement des points d’ancrage du cycle de vie des logiciels : Lessons Learned in a System of Systems Context ». Actes de la Conférence sur la technologie des systèmes et des logiciels, 20-23 avril 2009, Salt Lake City, UT, USA.

Dingsoyr, T., T. Dyba. et N. Moe (eds.). 2010.  » Agile Software Development : Current Research and Future Directions ». Chapitre dans B. Boehm, J. Lane, S. Koolmanjwong, et R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA : Springer.

Dorner, D. 1996. The Logic of Failure. New York, NY, USA : Basic Books.

Forsberg, K. 1995. « ‘If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment ». Actes du cinquième symposium international annuel de l’International Council on Systems Engineering (INCOSE). 22-26 juillet 1995. St. Louis, MO, USA.

Forsberg, K. 2010. « Les projets ne commencent pas par les exigences ». Proceedings of the IEEE Systems Conference, 5-8 avril 2010, San Diego, CA, USA.

Gilb, T. 2005. Competitive Engineering. Maryland Heights, MO, USA : Elsevier Butterworth Heinemann.

Goldratt, E. 1984. The Goal. Great Barrington, MA, USA : North River Press.

Hitchins, D. 2007. Ingénierie des systèmes : Une méthodologie des systèmes du 21e siècle. New York, NY, USA : Wiley.

Holland, J. 1998. Emergence. New York, NY, USA : Perseus Books.

ISO/IEC. 2010. Ingénierie des systèmes et des logiciels, partie 1 : Guide pour la gestion du cycle de vie. Genève, Suisse : Organisation internationale de normalisation (ISO)/Commission électrotechnique internationale (CEI), ISO/CEI 24748-1:2010.

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 / Commissions électrotechniques internationales / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC. 2003. Ingénierie des systèmes – Guide pour l’application des processus du cycle de vie des systèmes ISO/CEI 15288. Genève, Suisse : Organisation internationale de normalisation (ISO)/Commission électrotechnique internationale (CEI), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. « Les cinq meilleurs projets de logiciels de qualité ». CrossTalk. 16(7) (juillet 2003) : 4-19. Disponible à : http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

Kruchten, P. 1999. The Rational Unified Process. New York, NY, USA : Addison Wesley.

Landis, T. R. 2010. Famille Lockheed Blackbird (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA : Specialty Press.

Madachy, R. 2008. Software Process Dynamics. Hoboken, NJ, USA : Wiley.

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. « Revues d’architecture : Practice and Experience « . IEEE Software. 22(2) : 34-43.

National Research Council of the National Academies (USA). 2008. Ingénierie des systèmes de pré-milestone A et de phase précoce. Washington, DC, États-Unis : The National Academies Press.

Osterweil, L. 1987. « Les processus logiciels sont aussi des logiciels ». Actes de la SEFM 2011 : 9th International Conference on Software Engineering. Monterey, CA, USA.

Poppendeick, M. et T. Poppendeick. 2003. Lean Software Development : an Agile Toolkit. New York, NY, USA : Addison Wesley.

Rechtin, E. 1991. System Architecting : Créer et construire des systèmes complexes. Upper Saddle River, NY, USA : Prentice-Hall.

Rechtin, E., et M. Maier. 1997. L’art de l’architecture des systèmes. Boca Raton, FL, USA : CRC Press.

Schwaber, K. et M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, États-Unis : Prentice Hall.

Spruill, N. 2002. « Top Five Quality Software Projects ». CrossTalk. 15(1) (janvier 2002) : 4-19. Disponible à : http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.

Stauder, T. 2005. « Top Five Department of Defense Program Awards ». CrossTalk. 18(9) (septembre 2005) : 4-13. Disponible sur http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Systèmes sociétaux : Planification, politique et complexité. New York, NY, USA : Wiley.

Womack, J. et D. Jones. 1996. Lean Thinking. New York, NY, USA : Simon and Schuster.

Vidéos pertinentes=

• Introduction de base à l’ingénierie des systèmes (méthode V)
• Introduction de base à l’ingénierie des systèmes (méthode V) Partie 2 de 2