根據訪談素材,整理出以下內容:
Q:您認為工業軟件與傳統信息化軟件研發的主要區別在哪里?
A:傳統的信息化軟件以處理流程和業務邏輯為主,突出特點當業務需求轉化為軟件處理流程事件和任務的單元時,如果相應的資源配置充分(例如人力、技術路線、組織架構等),軟件過程和成果質量就是可控的。
而工業軟件最顯著的特點是其自身存在不可控的地方,主要原因有以下3 方面:算法的不可控性、技術的不可控性及軟件工程的不可控性。
算法不可控比較容易理解,不是說有了客觀的形式化表達(數學表達),就一定能轉化成有效或有價值的軟件算法,這是算法的不可控。
技術的不可控性主要體現為工業軟件是軟件技術的綜合,如涉及較為復雜的圖形技術,其不同于其他軟件的圖形技術(比如:游戲中的圖形處理),而是要與具體算法和具體功能相匹配、相適應。
軟件工程方面存在的不可控,主要體現在過程溝通。工業軟件涉及工業知識、學科知識與軟件知識的綜合,研發人員包括計算機專業和其他專業學科,例如:物理、數學等等,這就導致軟件過程中存在很大的溝通問題。比如,具備深厚軟件功底的人,讓他理解物理、機械原理就很難,而學科人員可能對軟件的認識又存在很大偏差,因為他的學習體系里沒有這方面知識,也即在軟件工程中存在的最大問題就是缺乏溝通的可理解性。
Q:工業軟件是典型的多學科和跨學科技術產物,你們在協調不同專業背景人員協同工作方面有哪些措施呢?
A:與傳統軟件開發相比,工業軟件的開發有更長的周期和積累過程,這是由不同專業技能的人組合工作時技能和溝通方面的鴻溝所造成的。
一種解決方案是“小組進化”模式,即按照專業劃分研究小組,通過計劃路徑不斷進化從而奠定技術基座,比如圖形圖像處理、基本的軟件架構、開發語言種類、學科專業如結構或者流體。單個研究小組只關注自己的領域,并給予較長的訓練和成長周期,就小組內部而言,溝通這一塊就基本可控了。
具體而言,研究小組的整體績效不以成果為考核目標,而是選定方向上的能力提升為主要目標,實現內部暢通和可控。而在產品級上則跟據需要的技術組合小組,溝通的問題落實在小組上而不是個人上,這樣產品級的溝通也相對可控。這樣,在基于工程需求、工程場景定義相應產品時,相應的儲備資源就能夠形成一個相對比較好的合力。在產品定義及開發時就可以按照標準軟件工程進行計劃和任務。
此外,在研究小組內部要做好資源的冗余設計,雖然會增加成本,但能將不可控因素變成可控。這種模式也存在問題,即將矛盾和風險向上層傳導,例如小組間需要管理層協調,產品定義需要管理層掌控,小組的新設和退出需要管理層判定等等,當然這種情況符合工業軟件研發特點,但對于傳統軟件行業可能不是最佳實踐。
Q:公司人員變動,尤其是工業軟件研發人員變動所帶來的影響是很大的,你們如何管理公司人員變動呢?
A:對于公司而言,人員變動都會產生負面影響,無論是工程專業人員變動還是軟件開發人員變動,都會導致交接和繼承問題,只是在工業軟件中更明顯。軟件本身的唯一生產者是人,這是產生不確定因素的根本原因。對于傳統軟件中人員變動的交接成本是可控的(極端下對業務重新開發)。
工業軟件的人員變動就可能會產生嚴重問題,如果人員變化造成接續人員很難理解前人的思想,尤其當涉及算法這一部分問題時則會更為嚴重。例如,算法思想和實現、數據結構設計思想、圖形技術路線和功能符號性等這些就會存在嚴重問題。
人員變動引發的風險既不可避免,也不存在最佳規避模式。行之有效的實踐就是拿成本置換風險,盡最大可能將工業軟件的不可控因素變成可控,減少整體風險。
對于軟件方面,可供應對的方式是建好研究小組梯隊,增加小組中人員冗余;對于工程人員方面,越是底層和基本算法越要適當引入商業合作,與具備相應能力的穩定科研機構形成供給關系,而不是依靠自身力量發展。本質上,這是在將人員變動的風險進行分攤,也即廣泛開展合作。
Q:對于第三方機構(例如高校)提交的代碼是否會進行重寫?
A:這個問題需要個體評判,一般情況下對于高校科研人員提交的算法,重點修改側重于性能提升,而非功能完善,因為功能是由約定時規定的。性能提升,比如單機環境需要修改為并行環境,以及考慮環境的遷移性、操作系統的兼容性。
Q:能否談談研究團隊的組織及不同研究小組之間的溝通方式?
A:在研發初始階段,一個研究小組只會安排兩個人,但是會賦予他們一項權利,隨著自己研究的深入,可自主吸納更多的人進去,相當于獎懲制度。某個研究小組的成果如果在實際工程應用中效果更好,就可以吸納更多的人進去。相反,如果該研究方向在后續實踐過程中沒有什么貢獻,可能該研究小組就會被合并到其他小組。
同一個研究小組內部研究內容相近,在相近的工作環境中工作,比如說至少是一個公司的人,很有可能還是一個辦公室的人,因此溝通基本不存在問題。如果是不同的研究小組,比如說開發CAD 和CAE 圖形處理的人員,通常是兩個不同的研究小組,因為他們的基礎渲染算法不同,但是由于都是圖形學問題,所以相互還是可以溝通的。
對于專業差別較大的研究小組,其實不需要刻意安排溝通,在項目實施過程中去溝通即可。一是項目實施過程中通常都是相對比較淺顯的問題,如果能夠積極加以討論,溝通問題自然會被解決;二是復雜溝通問題由管理層協調,問題向上傳導。其實就是建立一種機制,給予最基礎資源讓各自有足夠的自由發揮空間,這樣團隊自然如同進化一樣,價值低的方向會逐漸被淘汰,價值高的方向就會不斷地滾動成長。這種模式本質上還是為了應對工業軟件開發中更復雜的不可控性問題。
Q:您認為CAE軟件開發人員需要哪些專業背景?
A:CAE 軟件研發除軟件專業人員外,還需要力學背景人員。一般情況下,一位新員工,尤其是應屆畢業生,進入公司后還有一個相對長的學習過程,很難在一開始就決定他們會朝哪個方向發展,新員工可能最后成長成為一名銷售,或者是一名程序員。也就是說,公司內部有一個再培養過程,但是招聘都需要有一定基礎背景,即純粹的軟件工程或者力學背景。
Q:CAE 軟件開發過程中,對于架構(architecture)和框架(framework)是如何定義的?
A:架構通常指一整套管理模式,比如產品定義、成本、團隊組織和溝通。因此,架構通常有兩個基本目標:降低成本和解決溝通問題。降低成本是指在成本可控的情況下,要盡量壓縮團隊規模,在質量可控的情況下,盡量壓縮工期。
以下十條原則可用于降低成本:明確業務需求、任務優先排序、消除過度設計、最小可行性定義、引入敏捷方法、具備自動測試能力、統一生命周期管理、促進團隊協作、變更響應機制、強化復用代碼。一個團隊怎么建立起有效的溝通方式,則沒有確定答案,需要不斷地嘗試,從而確定適合的溝通方式。
框架則是面向系統的具體規范,也有兩個目標:第一,明確接口,設定好技術規范;第二,明確測量,重點在于最終產品的質量而不是單一模塊的質量。
Q:CAE軟件開發過程中,遇到的痛點問題有哪些呢?
A:一般認為CAE 軟件的痛點在算法上,但個人認為CAE 軟件長期迭代中的主要痛點還是數據結構的問題。
數據結構在軟件中不僅僅是對外數據接口,更重要的是需要定義CAE 內部的大量功能和非功能需求,例如存取特性、運行效率、軟硬件適配、兼容、資源分配、業務邏輯優化等方方面面的問題。數據結構確定之后,其變動越小越好,因為一旦變動,可能影響到各種解釋器、數據傳遞、數據變量的規格等,所引發的問題可能會非常大。
核心問題是:如果邏輯有問題能很容易被發現,而數據結構問題因為傳播路徑干擾,會很難定位和修正。這點在工業軟件中尤為突出,例如數據精度設計偏差可能導致頻繁的數據轉換中錯誤不斷累積。例如,特定數據類型是雙精度的浮點型還是整型,或者字符串類型,從最初始明確下來可能在整個軟件生命周期中都不會再次定義。
Q:CAE 軟件開發過程中,文檔要求、質量規范及支撐工具情況是怎么樣的?您能談談嗎?
A:一般情況下不會刻意要求更多的文檔,而是更關注記錄思路演變,這與CAE 軟件特性相關,即開發的過程和目標存在不確定性。
CAE 軟件目標的不確定性有很大原因是需求實現存在不同路徑,路徑差異可能還非常大。為此,一般將文檔分成兩類:一類是業務人員,要求他們詳細地描述其需求;第二類是開發人員,前期測試不需要文檔支撐,但是要求在其產生成果時做詳細總結。
其他場景與通用軟件開發相同,代碼中需要注釋的地方要求有注釋。
CAE 軟件開發質量保證。這個問題因人而異,比較復雜,舉兩個例子:建立程序封裝界面的可測試框架作為強制開發技術規范;使用任何語言都要求嚴格的代碼形式化檢查。
CAE 軟件開發支撐工具。主要選用合適的版本控制機制和工具,再配合適用的問題追蹤系統。
Q:關于工業軟件人才培養,您有什么好的建議?
A:對于高校相關專業而言,應該將CAE 軟件主流編程語言納入必修課,例如C 和C++,并且貫穿學生的整個學習過程,至少從大二開始,每學期要求用C++語言去完成一個項目。當前整個培養體系中對C++人才的培養遠遠不夠。
公司簡介:上海索辰信息科技有限公司成立于2006 年,總部位于上海,公司人員70%為研發與技術工程師。始終倡導與貫徹軟件自主研發,至今已擁有眾多國際/國內領先的軟件核心技術,獲得自主軟件著作權30 余項,通過ISO9001 和國軍標9001B 質量管理體系認證。遵照“理性創新、和衷共濟、互利共贏”的共同行為準則,基于全球最佳實踐和領先技術,為客戶提供產品全生命周期協同研制系統軟硬件、SAAS 服務。產品和服務覆蓋研發前沿工程、數字化設計及智能制造,客戶廣泛分布在重型機械、地面交通、電子、建筑、航空、航天、兵器、船舶、光電、動力設備等行業。