Author: Chen Wang

Key Capabilities to succeed in Automotive Industry

Take a look at passenger cars 10 years ago, and compare with cars nowadays, can you point out the differences regarding to driving experience and safety?  Those are the typical answers you will get: infotainment system, connected cars, driver-assisting features

Posted in 經驗分享 Tagged with: , , , , ,

FAQ: CMMI, ASPICE, 26262, What’s the difference?

1、CMMI評鑑和A-SPICE認證,有和區別? 答:二者都是對項目的流程來檢視工作產品與訪談,主要區別: a、認證方法:精神一樣且非常類似,都是組成評估小組來檢視工作產品與進行訪談。但CMMI的評鑑要求更多,如ATM人數與資格、證據充分性、項目數量與代表性、評鑑時間要求等。 b、評鑑方式:CMMI評鑑可分為階段式(Maturity Level)或連續式(Capability level),一般是以階段式為主。而ASPICE是連續式,且最低的評估範圍稱為HIS Scope,所以要不就是滿足HIS範圍的過程域到某一能力等級(如3),要不然就是由客戶指定的過程域來進行評鑑。 c、評鑑等級:ASPICE有31個過程域,每個過程域成熟度可分為0到5個等級,至於要評估哪些過程域,且每個過程域要到哪個等級,在評鑑前需要確認,類似CMMI的連續式評估方式 2、A-SPICE與ISO26262之間的區別有哪些?兩者之間能不能整合?若能,怎樣整合? 答:前者是基礎建設是用來打地基用的,地基穩了,後者才可以蓋高樓,可以整合,也必須整合 ASPICE與CMMI一樣,主要是建立流程與溝通方式,使得大家作事有一定的方法與依據,定義了車用電子產品開發生命週期中各階段,軟件的做事方法,屬於基礎建設。 而26262則是針對與安全相關的功能,特別深入的要求,所以透過ASPICE或CMMI的導入,​​先完成基礎建設(生命週期各階段的溝通與工作方式),然後再針對功能安全強化生命週期各階段相關活動的作法。舉例而言,透過CMMI/ASPICE會建立同行評審、測試的流程,一旦導入26262則就不需要再建立流程了,只要在現有流程上強化對不同功能安全等級的評審與測試作法(檢查項、測試工具/方法等)。 我們對客戶均說明一定要先導入CMMI後再推動26262,否則非常容易造成片面的改善,見樹不見林。

Posted in 經驗分享 Tagged with: ,

CMMI 2015 年的統計資料出爐了…

CMMI研究院2015的年報剛出爐,我們摘要了幾個有趣的數字: 1915:2015評鑑數又打破了歷年紀錄 (2014年1634個評鑑),每年持續成長 (詳下圖) 61:2015年世界上共有61個國家內的公司,採用CMMI作為產品開發與服務的流程改善模式,而全世界總共有98個國家的公司導入了CMMI。 17:又是一個雙位數的成長!相較於2014年,2015年有著平均17%的增長率,其中以美國 (28%)、墨西哥 (27%)、中國 (22%) 增長率最高,而思辨顧問執行了17個評鑑,涵蓋台灣與大陸。 6:台灣2015的評鑑數量 以上數字代表了什麼?

Posted in 最新資訊 Tagged with: , , ,

你的軟體專案有量化的度量嗎?臉書有!

度量與分析(Measurement and Analysis)的必要性不容易被接受,大部分時候主管與專案團隊都專注於近期目標的達成,即使度量與分析可以對專案管理與日後的改善提供很寶貴的資訊,度量分析工作的優先性常被放在很低。依據度量結果所提供的資訊,我們可以收集的度量值可分為三類:專案(Project)、產品(Product)、與流程(Process)類,希望回答的問題是專案的狀態、產品的品質、與流程的績效。前兩類度量大家比較熟悉,第三類則較少使用。其實專案狀態、產品品質是流程績效的果,流程類的度量才是解決問題的密碼。
你知道臉書(facebook)如何度量他們的軟體發行(software release)流程嗎?臉書發行團隊(release team)用以判斷某項功能增修是否同意納入本次發行的考慮因子,應用程式碼修改的程度(size of diff)以及程式碼審查的溝通/複查次數(back and forth of code review)。看看這裡的例子,測試的bug數與趨勢是產品類的度量,如果bug都解決了,為何臉書發行團隊還需要應用”size of diff”以及”back and forth of code review”去決定是否放行?值得參考。

Posted in 經驗分享 Tagged with: , , , , , ,

功能安全生命週期介紹

上次有介紹軟體功能安全的概念、國際標準與應用領域、生命週期等觀念,其中有提到:”…也就是說如何在產品生命週期各階段(產品概念、需求分析與系統設計、細部設計/開發/整合與測試、安裝/移轉與維運、汰除)考量所需的功能安全作為” 所以,這次我們將更深入的來談談生命週期的觀念,透過回答下列問題,希望各位對於功能安全能有一個基礎性的了解:

1. 為何功能安全要有生命週期?沒有會怎樣?
2. 功能安全的生命週期包含哪些階段與活動?
3. 與軟體開發有何關係?
4. 與CMMI流程改善的關聯性?

Posted in 經驗分享 Tagged with: , , , , , , ,

化阻力為助力-專案管理的創新思惟:引導資策會創研所同仁省思現有工作方式與所面臨的阻力及挑戰,並持續改善

化阻力為助力-專案管理的創新思惟:思辨顧問公司很榮幸在8月6日到資策會創研所,引導同仁省思現有工作方式與所面臨的阻力及挑戰,並透過溝通與對話來形成後續改善的方向。 資策會創新應用服務研究所(簡稱創研所)的關鍵任務之一為協助政府促成國內創新資訊應用的發展,透過核心技術的研究,有效協助產業創新以提昇服務價值,其中的服務體驗工程(Service Experience Engineering – SEE)方法,係藉由系統化方式,協助業者建立創新應用服務的成功典範,發展台灣成為全球應用服務創新櫥窗。 創研所同仁身負此重任,除了專案上的工作外,較少有機會讓相關同仁聚在一起討論工作上所面臨的阻力與挑戰,於是組織利用這個會議,由思辨顧問公司的資深顧問王誠引導大家,透過經驗的省思與小組腦力激盪,找出大家關心的阻力與挑戰,以供組織後續協助大家面對挑戰與提昇能力的參考。

Posted in Uncategorized

身為領導者的你,激勵團隊的唯一方法還是胡蘿蔔與棍子嗎?

從事流程改善的我們(思辨顧問),總是需要面對一群知識工作者(軟體開發人員),也知道除非已到緊要關頭,要不然胡蘿蔔與棍子的效果都不好,就算有效那也是一時的。所以,在協助客戶的團隊進行流程改善時,我們是從”人、團隊”來著手,藉著團隊智慧來提升個人與團隊的能力,先讓人覺得”值得”後,流程改善也就比較能順水推舟了。

Posted in 經驗分享

EPG Club流程改善分享聚會 – 2013年4月18日

老闆希望有一套好的管理方法,同時證明我們可以有紀律的顧好品質!主管非常贊成有一套流程來管理專案,但又怕因為流程而影響了專案的生產力與時程。專案成員的感覺是又來了!事情都做不完了,還要寫一大堆沒用的文件(刻板印象:流程 =文件)。身為任重道遠的EPG,想幫助他們卻又不知如何著手,而你自己呢?對自己的期望與生涯發展又是什麼?
藉由這個聚會,讓我們大家分享EPG的酸甜苦辣:你做哪些事?有哪些挑戰?遇到哪些困難?你如何接招與應戰?有哪些洞見?同時,我們更希望建立可以激盪與碰撞的社群,並讓大家對於EPG的角色有更多認識(You are NOT alone),透過分享與成長,讓EPG能夠更有信心、更順利地推動流程改善!進而讓EPG成為公司重要的戰略資產!

Posted in 經驗分享