在數位產品交付中整合硬體和軟體開發

軟體在推動世界運作的過程中，每一天都變得越來越重要。產品包含的軟體越多，開發過程就越複雜，出錯的機會也越高。與此同時，比起過去，進行創新並將複雜優質產品更快推向市場的壓力也更大了。此外還必須有效管理硬體、軟體和服務創新的平行開發流程以確保透明度，並全部整合到單一產品中。

如果製造商不想在複雜產品開發最佳化的競賽中落後，就需要大幅改進流程、系統和團隊心態，否則一開始就以設計複雜產品為主要業務的競爭對手將會取而代之。

這項演變的關鍵：

• 建立有條理的整體系統觀點
• 使用系統工程方法
• 讓組織接納跨專業領域的思維
• 運用合適的 PLM/ALM 工具

從商業角度來看，這些發展對製造商來說既是機遇也是挑戰。有鑒於競爭加劇和創新的壓力，軟體驅動的產品能加快開發時間，並為全新的商業模式開拓道路，可說是大好機會。

但為何這也是一項挑戰呢？

跨專業領域的團隊

從產品開發人員的角度來看，由於使用多種軟體，而且元件之間的相互關係非常緊密，因此即使機械方面的變動更少，整個系統的複雜性仍會增加。除此之外，軟體本身通常是由不同的開發團隊所開發，而這些團隊會各自以自己的方式和速度管理創新週期，因此難以協調這些團隊的工作，並整合不同的平行開發流程。

系統驗證

製造商還必須考慮如何驗證整個系統，尤其是針對攸關安全的產品。根據產業和所驗證的產品，相關標準會要求每個開發步驟和每項變更都應該可追溯到原始要求。

不連貫的工具鏈

用於軟體開發的工具組已經演變成我們今天所知的應用程式生命週期管理 (ALM)，其流程模型已納入現代的系統工程中。然而，許多公司從過去到現在仍著重於管理許多個別的元件。在整個公司一致實施的產品生命週期管理 (PLM) 概念 (方法和工具)，並不總是能夠確保從需求規格到成品均維持一致性。

如果觀察主要著重於機械和機電產品的公司如何整合日漸增加的軟體，我們可以發現下列傾向：

方法 A：將軟體視為硬體的附屬物

這表示將軟體視為硬體的延伸或補充 (類似「軟體只是另一個零件編號」)。軟體元件等同於機電元件，而且會標上零件編號。雖然您還是至少可以辨別產品結構中的 ECU，但不可能識別出單階 BOM 中的所有相依性。

方法 B：讓 ALM 和 PLM 並存

在某些情況下，組織會在 PLM 環境以外建立一個獨立的平行 ALM 環境，也就是「我不知道他們在做什麼，也不感興趣」的情況。

如果軟體開發人員擺脫機電開發的束縛，就可以充分利用 ALM 環境的彈性應變能力。軟體經過最佳化之後可以快速改版，以非常敏捷的方式滿足當前客戶的需求。

然而，在 PLM 和 ALM 完全分離的情境下，組織往往會忽略應該將這兩種環境同步化。不幸的是，這種不一致的情形會延續到生產和成品中

遺憾的是，上述兩種情境都不適合用於推動機械工程、電子和複雜軟體之間的功能共生。

軟體驅動產品開發最佳化的「藝術」在於建立流程、方法和工具，為所有參與開發的部門提供透明度、高效率的協同合作中樞，以及有助各方蓬勃發展的所有工具。

話雖如此，仍然需要協調所有單獨的領域，以確保最終的個別產品能符合所有需求和功能要求。然而，這不只牽涉到工具和方法，還需要進行廣泛和深入的組織變革，而且員工的意願至關重要。因此我們建議指派專員主動監督變更過程，並為組織中的協調工作提供強有力的指導。

其次，在複雜的技術開發環境中，需要積極控管協同開發流程，而系統工程中使用的方法恰好能提供合適的基礎。這種方法已經包括非常實用的工具組，可用於調整產品或系統的所有元件，以滿足共用需求。

是要嚴謹地導入其中一種系統工程標準，還是只做為指導方針，純粹是偏好問題；當然，如果您必須向客戶或其他相關負責人證明自己符合指定標準 (按照某些產業的要求)，是否遵照標準就非常重要。

方法論基礎

貴公司必須選用適當的程序模型 (例如 V 模型)，並做為指導方針。

這在軟體驅動產品的領域代表什麼意義？您在一開始就應該要考慮產品應具備的功能，以及應滿足哪些其他需求 (例如標準)。您應該盡可能公正地進行判斷，不要預先決定採用特定方法。

後續步驟包括：

• 描述您的產品應具備哪些功能
• 在架構階段合理劃分系統
• 提供相依性的初始抽象定義
• 建立同步化的機制

請務必記住，儘管您盡了一切努力簡化過程，硬體和軟體子系統之間的相依性還是很快就會變得非常多樣化和複雜。因此，您的 IT 環境必須盡可能協助您追蹤所有這些相依性。

建立以上提到的方法模型類型能奠定基礎，使您能夠在整段開發流程中可靠地因應開發軟體驅動產品的挑戰，端對端系統工程尤其能提供至關重要的支援。

如今，大多數公司已經透過某種方式實踐這些概念中的許多要素，只是通常缺乏最佳化和更具目標性的協調；不過只要轉變為正確的心態，讓特定人員負責監督，並使用足夠的工具來支援您的工作，就能解決這些問題。