並行工程/簡介

使命宣言

本華夏公益教科書的宗旨是建立一個活生生的檔案，描述什麼是並行工程以及它如何有用。它面向工作場所的入門級工程師。

定義 並行工程是一個過程，在這個過程中，適當的學科被委派以互動方式工作，以構思、批准、開發和實施滿足預定目標的產品計劃。如 http://www.mne.psu.edu/lamancusa/html/ConcEng.htm 所定義

為什麼要使用華夏公益教科書？

維基協作是一個非常新穎的事物，教師和學生都鮮少為新的維基環境做好準備。但是，我要說，它帶來的益處非常大：參見諸如人體生理學（已遷移到其自己的專用維基網站）和教育基礎與教學評估（已出版第四版）之類的書籍，這些書籍是我們最成功的案例。學生不僅可以透過編寫自己的段落來學習，還可以透過審查和建設性地批評他人的段落來學習。被要求改寫或澄清某件事可能會迫使學生在自己的腦海中重新構建和強化這些想法。所以，即使情況很艱難，也要相信結果會非常有意義！（維基使用者 Whiteknight 的評論）

產品概念

ME 518 並行產品設計課程中的學生進行了一次頭腦風暴，以確定他們希望在關於並行設計的“書”中看到什麼。

產品資料表

關於並行工程華夏公益教科書應該做什麼的說明

並行工程

• 作者：Michael Koch，來自 ME519 論文...請審查和編輯！由於我從另一篇論文中摘錄了它，因此可能存在問題

並行工程方法仍然是一種相對較新的設計管理系統，但在近年來已經成熟，成為一種最佳化工程設計週期的定義明確的系統方法。^[1] 正因為如此，並行工程引起了工業界的廣泛關注，並在眾多公司、組織和大學中得到實施，最著名的是航空航天工業。^[2]

並行工程的基本前提圍繞著兩個概念。第一個概念是，產品的整個生命週期，從功能、可生產性、裝配、可測試性、維護問題、環境影響，最後到處置和回收，都應該在設計初期階段仔細考慮。^[3] 第二個概念是，上述設計活動應該同時發生，或者並行進行。總的目標是，這些過程的並行性質顯著提高了生產力和產品質量，這些方面顯然是當今快節奏市場中的重要因素。^[4] 這種理念是並行工程成功關鍵，因為它允許在設計過程的早期發現錯誤和重新設計，此時專案仍然處於更抽象的、可能還是數字化的領域。透過儘早定位和修復這些問題，設計團隊可以避免在專案轉向更復雜的計算模型，最終進入物理領域時，經常出現的昂貴錯誤。^[5]

如上所述，設計過程的一部分是確保整個產品生命週期都被考慮在內。這包括建立使用者需求，傳播早期概念設計，執行計算模型，建立物理原型，最終制造產品。該過程還包括充分考慮資金、人力資源能力和時間，這些方面通常不會被直觀地考慮，但它們是並行工程系統成功的極其重要的因素。與之前一樣，廣泛的預先規劃允許在實際物理生產開始之前儘早發現不可預見的設計問題，以便在實際物理生產開始之前修改基本概念設計。透過正確地做到這一點，可以節省大量的資金，這通常是公司轉向並行設計框架的決定性因素。^[6]

並行工程取得巨大成功的最重要的原因之一是，從定義上來說，它重新定義了數十年來普遍存在的基本設計過程結構。這種結構基於一個順序設計流程，有時被稱為“瀑布模型”。^[7][8] 並行工程顯著修改了這種過時的方法，而是選擇使用被稱為迭代或整合開發方法的方法。^[9] 兩種方法之間的區別在於，“瀑布”方法以完全線性的方式進行，從使用者需求開始，依次向前推進到設計、實施和額外的步驟，直到你得到一個完成的產品。這裡的問題是，設計系統不會從它所處的步驟向後或向前檢視以解決可能存在的問題。如果出現錯誤，設計通常必須廢棄或大幅修改。另一方面，迭代設計過程更具迴圈性，正如前面提到的，它考慮了產品的整個生命週期，從而允許採用更具進化性的設計方法。^[10] 兩種設計過程之間的區別可以在圖 1 中直觀地看到。

圖 1 – “瀑布”或順序開發方法與迭代開發方法

這種新方法的一個重要部分是，由於並行工程的協作性質，單個工程師在整個設計過程中獲得了更多的話語權。雖然這在很多人看來可能無關緊要或無關緊要，但賦予設計師所有權在員工的生產力和產品的質量中起著至關重要的作用。這源於一個有時不為人知的現實，即一個對自己的工作有滿足感和所有權的個體將會比一個被分配了任務但對總體過程沒有發言權的員工更加努力地工作，並設計出更加強大的產品。^[11]

透過實施這種徹底的變革，許多組織和管理方面的挑戰將會出現，在公司和組織向這種體系轉變時，必須特別注意這些挑戰。從這個角度來看，諸如早期設計評審的實施、工程師之間溝通的實現、軟體相容性以及開放設計流程以允許併發等問題都會帶來自身的問題。 同樣，必須有強大的團隊合作基礎，因為該方法的總體成功取決於工程師有效協作的能力。這通常是一個難以克服的障礙，但必須儘早解決，以避免以後出現問題。

同樣，現在比以往任何時候都更重要的是，軟體在工程設計過程中發揮著巨大作用。無論是從 CAD 軟體包到有限元分析工具，快速輕鬆地修改數字模型以預測未來設計問題的能力對於您使用的任何設計流程都非常重要。但是，在並行工程中，軟體的作用變得更加重要，因為協作的本質必須考慮到每個工程師的設計模型必須能夠相互“溝通”，才能成功地利用並行工程的概念。當我們研究美國宇航局噴氣推進實驗室的 Team-X 設計方法以及分散式並行工程時，我們將更深入地探討這一點，它們都嚴重依賴於複雜的軟體系統整合，將並行工程提升到一個新的水平。

極度協作

• 由邁克爾·科赫輸入，將會回來清理……另外，不確定這是否適合這個地方？
• 我認為這可能更適合“通訊系統”部分，通訊團隊的任何成員同意嗎？

極度協作，這是格洛麗亞·馬克創造的一個術語，用於描述美國宇航局噴氣推進實驗室 Team-X 對並行工程的應用方法。Team-X，也稱為高階專案設計團隊，成立於 90 年代中期，作為美國宇航局內部諮詢小組，以及外部實體在新的太空任務提案設計方面的諮詢小組。其總體目標是減少完成這些定義任務所有方面的提案所需的時間。下面我們將看看極度協作是如何運作的、它為什麼取得成功以及存在哪些侷限性 [20]。值得注意的是，由於該方法已證明可以將生產力提高一倍 [25]，因此許多組織紛紛效仿。

簡而言之，Team-X 方法幾乎與並行工程相同，但他們將該概念進一步發展，基本上將所有設計工程師集中在一個大型房間中，進行密集的並行設計會議。在這個被稱為專案設計中心的房間裡，設計團隊利用聯網計算機訪問資料儲存庫、即時設計資訊以及計算機建模和模擬工具來建立最終設計 [24]。這些設計會議通常持續大約 3 到 4 個小時，來自機械、結構或電氣等各個學科的 10 到 20 名工程師以及一名協調員和客戶共同努力快速有效地建立設計提案 [23]。

圖 2. Team-X 設計會議正在進行中

對這種協作進行預先規劃極其重要，以確保一切到位，以便工程師能夠快速工作並避免設計過程中的停滯。這些停滯，或稱為“延遲”，最終必須不惜一切代價減少。延遲的減少本質上是 XC 取得成功的關鍵。在傳統的協作方法中，工程師可能要等待數天或數週才能獲得重要的設計資訊，從而導致專案延誤。在 XC 中，透過將所有相關的工程師集中在一個地方，延遲被大大減少，從而能夠透過本地協作快速找到並解決問題。我認為這非常有趣，因為 XC 專注於減少設計中最明顯的時效問題 [22]。關於未來的研究，這種型別的協作似乎可以在分散式方式下模擬（即，工程師不在本地，而是僅透過網際網路連線）。

XC 的另一個重要部分是組織結構。XC 的設計理念是平等主義。XC 正常運作需要最少的管理干預。這已在研究中得到證實，研究表明工程師將 10% 的時間浪費在等待管理層批准上，並且工程師諮詢“知識網路”而不是其主管的效率得到了證實。尤其是，平等主義結構在工程設計中的成功證明對於賦權工程師、賦予個人所有權非常重要。在許多領域，這一點已經得到體現，例如社群組織，但今天許多工程組織似乎缺失這一點。證明“扁平化等級制”是組建工程設計團隊的一種可行方式，這似乎可以透過使用分散式協作工程 [22] 來進行更廣泛的應用，這將是本文後面討論的主題。

最後，使 Team-X 的並行工程方法如此成功的是它利用了社會和電子網路。透過將整個設計團隊集中在一起，極度協作成功地使高效的人力網路得以發展，消除了電子郵件、電話和管理層審批等障礙，這些障礙往往會阻礙複雜系統的設計。關於一個設計領域的相關對話可能會被一位工程師無意中聽到，該工程師發現這些資訊有用，因此，關於設計資訊的對話更加開放。此外，由連線的電子表格實現的電子網路使工程師能夠快速共享他們計算出的可能與其他設計師工作相關的資料。總體效果與延遲的減少相關，而延遲是複雜系統設計中的一個主要問題 [21]。

然而，馬克指出了一些侷限性，這些侷限性使該方法無法在所有情況下實施。重要的是，設計團隊必須能夠靈活地適應在社會封閉的環境中大型設計團隊工作所需。如果團隊成員固執或碰巧與同事相處不融洽，這可能是一個主要問題。團隊成員還必須對自己的錯誤被公開廣播到整個團隊持開放態度，因為當發現或質疑錯誤或判斷失誤時，就會發生這種情況。最後，由於一個房間裡可能有多達 20 人，每位工程師必須能夠在嘈雜擁擠的房間裡工作。通常，可以透過仔細選擇團隊輕鬆克服這些侷限性。然而，這些仍然是必須考慮的現實問題 [21]。

總的來說，Team-X 使用的極度協作方法已被一次又一次地證明是非常成功的，當設計工程師能夠集中在一個房間裡時。這些設計已被證明具有很高的質量，並且能夠快速有效地完成 [21]。但是，當所有相關方都不在一個地方時會發生什麼？在下一部分中，我們將研究當前用於連線可能分佈在世界各地的設計工程師的方法。這個主題非常重要，因為越來越多的公司意識到，最具專業知識的人可能不在自己的公司，這是推動向更分散式設計框架轉變的一個關鍵動機 [4]。

分散式並行工程

分散式並行工程是一種快速流行的準新設計方法。簡而言之，分散式並行工程基於與本地並行工程相同的基本概念，但更進一步，利用無處不在的寬頻網際網路連線工程師、經理和使用者，他們可能分散在世界各地，共同建立獨特的產品 [12]。如前所述，推動這一趨勢的主要原因之一是，隨著產品和系統的複雜性不斷提高，專業知識往往不再侷限於本地環境 [4]。出於這個原因，分散式設計已成為任何設計團隊在建立強大功能性產品時必須考慮的一個重要方面 [26]。

由於並行工程的基本概念通常為人所知，分散式並行工程 (DCE) 面臨的主要障礙是軟體層。目前，有大量軟體包，無論是 CAD、CAM、FEA 還是其他軟體，它們都實現了巨大的生產力飛躍，以及對產品功能的深刻洞察，而這些洞察在最近之前是不存在的。但是，這些軟體程式的通訊能力一直是真正成功分散式設計的主要障礙之一 [12]。

許多實體都嘗試設計這種分散式協作系統。Mohamed 提出了一種基於 Web 的系統，允許開發人員共享資料、進行溝通、修改幾何形狀，以及確保整個專案的一致性。“STEP”是一個 ISO 標準，用於分散式工程資訊傳輸 [27]，這是該系統的一個關鍵特性。Quan 和 Jianmin 提出了另一種基於 Web 的方法，該方法利用四個不同的模組來實現產品設計：協同設計、視覺化、製造分析和服務模組。作者還認識到知識處理技術對於捕獲重要的設計資訊以供日後使用的重要性 [12]。Nahm 和 Ishikawa 開發了另一個稱為 ANetCoDE 的基於網際網路的設計環境。這個網路設計系統是為了瞭解產品分解及其增強分散式設計方法的能力而建立的。據作者介紹，該方法非常成功 [28]，經過檢驗，它似乎與 ModelCenter 具有許多相似之處，ModelCenter 是一款專有程式，旨在促進專案協作 [29]。最後，一個主要基於 Web 的軟體包 VOICED 應運而生，其目標是捕獲設計知識並利用它來幫助未來的概念設計 [6]。隨著工程設計變得越來越複雜，知識捕獲的概念在概念設計階段變得越來越重要，它使設計師能夠借鑑過去的知識，避免“重複造輪子”，以及在設計和生產過程的後期避免代價高昂的錯誤 [30]。

所有上述設計系統之間存在的共同點是，基本框架都位於基於 Web 的領域。這對分散式並行工程的想法很重要，因為共享資訊的機制必須能夠從世界任何地方訪問。這使那些參與專案的人能夠快速輕鬆地從任何地方、任何時間訪問資訊，並立即更新相關資訊。

然而，這並不意味著所有工具都必須是基於 Web 的。目前，很難想象有一個功能齊全的有限元分析軟體包可以在虛擬環境中執行。瀏覽器中必須執行的資源數量可能會導致軟體崩潰。當然，只要本地軟體能夠與基於 Web 的協作設計程式互動，這並不重要。這使真正的分散式協作設計環境成為可能，資訊可以輕鬆快速地共享。上述許多分散式並行工程框架都設計了緩解這些問題的方法 [6, 12, 27-30]。

這種日益分散式的協作模式契合了謝列梅托夫提出的“層次”框架，他是墨西哥石油研究所的研究員。他的工作主要集中在石油行業，但也對工程設計具有廣泛的應用。這些層次按以下順序排列，旨在說明在將工程流程向更分散式的協作模式轉變過程中發生的自然演變過程。

第一級目標是確保工程軟體能夠與公司或組織級別的其他應用程式互操作[30]。互操作性取決於“開放標準”，即一套規範軟體包之間相互“通訊”方式的規則。近年來，傑夫·卡普蘭在政府領域大力推動了這一理念，而在工程領域也同樣重要[31]。穆罕默德在他的協作框架中使用 STEP（ISO 10303） [27] 就是開放標準在實踐中的一個很好的例子。

第二級旨在確保軟體包能夠透過將資料儲存在伺服器端並在需要時呼叫資料，整合來自不同位置生成的資料。這有效地減少了錯誤，並允許更輕鬆地擴充套件，同時透過將資料儲存在異地來提高資料完整性。

第三級更進一步，允許透過一個主門戶訪問應用程式，從而使設計流程更加流暢，並在虛擬意義上實現更大的集中化。

最後，第四、第五和第六級更具雄心。它們分別旨在建立虛擬應用程式、使用者生成的虛擬應用程式，以及最終自動生成的應用程式。從直覺上講，這些似乎要困難得多，但它們將帶來的機遇可能非常重大，因為它將迅速分散設計流程，並允許更大的靈活性[30]。

上述層次體系很好地說明了軟體必須經歷的演變過程，以便能夠實現一個健壯的、分散式的協作工程環境。然而，上述層次需要與通常是專有且封閉的系統一起工作，因此難以更改和修改。這是在先前幾節中提到的方法和軟體基礎設施中經常出現的一個重大問題。在大多數情況下，這些方法主要存在於公司或大學等機構中，這些機構在組織結構和必須遵循的協議方面具有不同程度的正式性。然而，這種設計、組織和生產方式正在緩慢發生變化，許多人認為這種變化是革命性的。在下一節中，我們將展望軟體工程領域，在該領域中，“開放”協作的理念已變得極其流行，並催生了諸如 Linux 作業系統、Apache Web 伺服器和維基百科等軟體。

開源軟體開發

• 來自 Michael Koch 的內容將很快整理……另外，我不確定這是否適合放在這裡？

在過去的幾十年裡，開源設計方法，或簡稱為開源，已經從一個有點模糊的概念發展成為許多人認為正在迅速取代已存在數十年的過時的封閉系統的正規化轉變。正如埃裡克·雷蒙德所說，“開源的運作和決策模式允許不同議程、方法和優先事項的併發輸入，這與更封閉、更集中的開發模式不同。”[32] 這種設計模式與本文中提到的更成熟的制度化方法形成對比。

那麼什麼是這種“開源設計方法”呢？本質上，開源是一種相對非結構化的軟體包或產品開發方式。簡而言之，開源軟體開發是指將原始碼透過網際網路公開，並鼓勵對其進行修改、使用和分發，作為產品成功的關鍵[35]。

與並行工程類似，設計和實施由可能在地理上分散的個人以高度並行的方式進行。然而，與前面提到的方法存在著顯著的差異。具體來說，參與者沒有直接的貨幣報酬[33]。貢獻者可以隨時加入或離開，並且不會因這種行為而受到任何影響[1]。原始碼，即軟體的內部運作機制，將與最終的軟體產品一起公開分發[33]，其他開發者可以從該程式碼中開始獨立的專案，也稱為“分支”。分支是一種比較罕見的現象，但在 Linux 和維基軟體等更流行的程式中已經發生過好幾次[1]。開放性使這些專案周圍能夠形成更廣泛的對話，這也是開源成功的關鍵之一。

另一種視覺化設計過程的方法是使用大教堂與集市類比。埃裡克·雷蒙德提出的這種模型被廣泛用於描述開源設計的工作原理。大教堂代表公司，一個高度組織化、封閉和等級化的機構，其任務是生產軟體或飛機等產品。用現代術語來說，大教堂可以比作微軟或波音等公司。另一方面，集市代表一個相對扁平化和開放的組織結構，其中貢獻者具有平等的發言權和代表權[32]。集市作為熙熙攘攘的區域的形象，人們在那裡展示自己的想法和議程，很好地說明了開源的工作方式[33]。這些描述暗示了每個系統成功和失敗的原因。

開源的精妙之處在於，像 Linux 作業系統這樣的大型複雜專案可以被分解成更小的任務，由一大群志願者來完成。透過利用這個龐大的團隊，所利用的腦力在公司環境中是無與倫比的。當然，必須有一個明確定義的審查流程，以確保提交的是高質量的工作，並避免程式碼“分支”的可能性[36]。

同樣地，龐大的志願者團隊允許應用 Linus 的定律，該定律指出：“如果給足夠多的眼睛看，所有的缺陷都是淺顯的。”[32] 這意味著，透過利用這個貢獻者網路，可以找到和修復原始碼或設計中的任何問題。在軟體開發領域，除錯可能是一項繁瑣的工作，尤其是在處理數百萬行程式碼時。透過建立不對稱的分散式網路，由於工作的並行性，這項任務會顯著減少[33]。同樣的理念可以應用於維基百科，資訊在世界各地的使用者之間進行審查和辯論，從而建立了一個強大的資訊資料庫，在現今可能無與倫比。

同樣地，查爾斯·利德位元指出，以往的組織模型嚴重依賴於專家必須彙集到機構中才能創造產品或創新的理念。示例機構包括微軟、斯坦福大學或噴氣推進實驗室。開源的理念顛覆了這一理念，它不依賴於機構，而是依賴於一個由開發者和貢獻者組成的社群，他們受實用性、自豪感和樂趣等因素的驅動來創造創新。對許多人來說，這可能看起來令人費解，但在回顧人們如何圍繞社群需求或問題進行組織的歷史時，就非常有道理了[2]。

總之，開源軟體開發是一種與前面提到的更成熟的設計方法截然不同的方法。開源軟體開發的核心是一個平等主義的設計過程，旨在賦予每個人對其工作內容和解決設計問題的方