「台灣軟體業不出三年就全趴下啦」兩年前聽一位政府部門之資訊單位主官如是說。當時CMMI在經濟部工業局的全力支持下，如火如荼地進行著。而在現在的時點上看來，CMMI的浪潮已過，除了一些過關收尾的導入案之外，似乎聽不到軟體業界有公司再談論這個話題的，而從事CMMI輔導的顧問公司現在也多是門可羅雀。

當初國內軟體公協會及政府部門在鼓吹並積極推動CMMI時，都認為軟體產業將會因為CMMI的洗禮而更具競爭力，但是從今天的情況來看，CMMI評鑑通過的總數至少有85家(不排除尚未於工業局CMMI網站登入的通過者)，但是我們軟體業看來並沒有真的取得預想的提升了。儘管有人認為軟體業在CMMI浪潮推動下沒有起色，是因為沒有外在的要求，因此希望能夠從修改政府採購法，促使政府部門在執行資訊業務委外的選商階段，某些規模的案子，即限定唯CMMI三級的公司方能參加投標，另外也希望政府部門能導入CMMI-ACQ，期能帶動有資訊業務委外需求之企業能效法，在甲乙雙方都有充分的成熟度下，促進整個軟體產業的提升。

其實，CMMI就像ISO 9001、ISO/IEC 27001、ISO/IEC 20000、ISO 14001等等一樣，就是一個管理制度，這個制度除非軟體公司真的將之認定為脫胎換骨、更上層樓的利器，願意全力投入，否則通通都可以用忽悠、欺騙的方式取得「那一張證照」。國內有位SEI Certified Lead Appraisor曾說：「通過CMMI評鑑只能證明一件事：該公司在過去的一段時間中，曾依據CMMI的要求實踐過，但不保證在未來該公司在取得資格後，仍將繼續貫徹這些要求」。所以從以前到現在，政府部門沒有把這些制度證照當成政府部選商的資格，的確是明智之舉。而確實，有了這張證照並不代表所有必要的工程常規都會在資訊業務委外專案中被實踐。

或許那位資訊部門主官所言有可能成真，但是這不會是主管產業發展的經濟部所樂見的，所以應該要有一些在短期之內可以做到，又不必花太多錢，且能夠挽救現在之頹勢的作法吧。筆者認為回到國家標準的範疇裡運作才是最好的方式，只是，所謂在國家標準範疇裡運作，並不是將CMMI相關文件或者是之前所談到已經訂為國家標準的管理系統標準納到政府採購法裡，而是回歸到軟體發展、運作及維護或資訊服務提供的過程國家標準的應用上。

目前軟體發展、運作及維護與資訊服務提供之過程的國家標準就屬「CNS 14837軟體生命週期過程」及「CNS 15008系統生命週期過程」兩項。這兩項標準與CMMI、ISO 9001之流的標準不同之處，它不是一個管理系統的標準，它們描述的主體不是組織，它們談的是在產品的生命週期裡，該做些什麼。在此兩項標準中，界定了所有與產品生命週期有關的過程、活動、及工作項目，每一個過程都有兩個很重要的元件：過程的目的(purpose)及過程的成果(outcomes)，因此它們較CMMI在契約與專案的應用上更為明確且直接。在實務上，該兩項標準可以成為RFP及契約工作條款(statement of work)的來源，因為它們已經將軟體產品生命週期裡應做到的事情羅列出來，對於獲取者而言，在發展RPF或契約的工作條款時，就從這個標準中去挑出獲取者所認為在專案中應該要執行的活動及工作，這包括供應者應該要做的事情，以及獲取者為敦促供應者的工作進度可以採取的措施。

為使得這件事情是可行的，建議行政院要求政府機關各部門修改資訊業務委外有關的採購作業規定，其修改的部分包括將作業規定裡的作業程序(包含對得標廠商的審查與稽核、履約督導等專案管理工作)依據國家標準CNS 14837中第5.1節獲取過程(在未來的新版的CNS 14837將為第6.1.1節)。其次則是在作業規定裡明確規定：「依循採購法的要求，有關資訊業務委外的產品發展、運作與維護及資訊服務之提供，其過程應依循CNS 14837(或ISO/IEC 12207)與CNS 15008(或ISO/IEC 15288)，並以該兩項標準所列之活動與工作，提列購案的工作條款(SOW)」(此乃基於政府採購法的順水推舟作法，應不致有窒礙之處)。另外，由於CNS 14837與CNS 15008所談的過程，需要依照專案的性質與規模等裁適，但是此種裁適並不可能導致該標準的完全不採用(除非該案不屬於產品發展、運作與維護或資訊服務提供)，就算是預算金額10萬元以下，只要是涉及「產品發展、運作與維護或資訊服務提供」，就必須遵循該兩項國家標準或使用該兩項國家標準進行相關的作業(含裁適過程)。資訊業務委外的經辦人，根據CNS 14837及CNS 15008提列的工作條款，亦應附帶說明CNS 14837及CNS 15008中活動與工作項目的採用與不採用的理由表，連同RFP/契約草案送交會計室(或由專案的顧問)審查。對於供應者而言，因為所有過程的目的與過程成果都很明確，基於過程目的與成果之達成所應執行的活動與工作都很明確，供應者能明確理解這些活動與工作執行的意義，而對於獲取者而言，因為目的、成果、活動、工作都很明確，所以也容易執行相關的審查、稽核、履約督導的相關工作。這都將較獲取者拿著不明不白的契約，供應者拿著一紙信心度有疑慮之管理系統評鑑通過證書執行的專案，可見度及成功率更高。這類的規定如果明確，則相關的政風、審計單位在執行稽核或相關作業之察查時，亦能夠有共同的依據，有助於審計工作之進行。

將CNS 14837及CNS 15008等兩項國家標準明定為資訊業務委外案之工作依據，除可滿足政府採購法之要求外，由於此兩項標準即可成為甲乙雙方在資訊軟體相關業務執行時溝通的共同語言，將較單方面由廠商拿著自己家的軟體發展、運作與維護及資訊服務程序(定義how to do)執行專案工作，對獲取者而言更加透明，且由於此為國家標準，將較公司自家的「內部標準」更具有公信力。而，由於此兩項國家標準均係源於國際標準，亦獲得IEEE完全採用(收納為IEEE之標準)，國內廠商習於這兩標準的要求，亦將有助於其國際業務的拓展。

----------------
引文:

個人非常贊同泰龍兄建議政府：『依循採購法的要求，有關資訊業務委外的產品發展、運作與維護及資訊服務之提供，其過程應依循CNS 14837(或ISO/IEC 12207)與CNS 15008(或ISO/IEC 15288)，並以該兩項標準所列之活動與工作…』云云

不過談到“台灣軟體業救亡圖存”這個議題時，個人認為：首先軟體業要先要認知到自身的處境並自覺到須要救助，才有可能得到外力的幫助，正所謂“自救人救”。因此，所有的“軟體族”人，我們首先要問問我們自己：是否覺得需要外力的救助？答案如果是否定的，那麼泰龍兄和其他所有關心台灣軟體業前途的先進與先知們，您們真的幸苦了，您們可以歇歇了。如果答案是肯定的，那麼我們要再問問我們自已：我們採取了何種“自救”的措施？

就軟體業的“自救”之道，個人認為可以這麼做：就是大家到網路上把『Software Engineering Code of Ethics and Professional Practice』這份文件下載下來，研讀它並試著去實踐它。進一步再影響週遭的其它人，讓更多的軟體人來實踐它。我想如果一半以上的台灣軟體人的行為向它靠攏時，這個行業應該會明顯地向好的方向轉變；當有百分之六十以上的軟體人可以實踐它時，我想：要這個行業不好，也難。

台灣軟體業要何去何從？就看你我如何“自救”。最後用下面這句話，祝福台灣軟體人一族和所有的台灣人：願大家轉好運，好運大家轉。

周茂松

在此的救亡圖存，其實是從政府權責單位與相關公協會來看的。

就算軟體業自己不認為需要救助，但是因為軟體產出品質之良窳，攸關所有stakeholder(包含所有的使用者、納稅義務人、受軟體正常與不正常運作結果影響之人員....等等)的權益，這件事不該是行業裡的事情，而是政府該做的事情，就像建築不符合stakeholder的利益，乃至會損及生命財產安全，政府就必須有相對的法令規章來保障stakeholder。如果可能，立法院也應考慮制訂：「資訊軟體品質保障法」或是「資訊軟體利害關係人權益保護法」之類的法規。(我們對於法律的制定，應該打破「美英日等國是否已制訂類似的法律？」的思維模式。筆者以為，人權立國的台灣，更應該從保障人民權益的角度去制定這類的法律。事實上，當軟體業者從自己是stakeholder的角度出發時，也會認為這個法律是需要存在，他們不也常常罵微軟的產品有多糟糕。就像過去我在帶專案時，當業者對我抱怨管得太龜毛，我說「你們從自己是納稅義務人的角度看，會希望我如何管理這個案子？」當下這些人是啞口無言。)

即使像世界上的一些宗教也一樣，因為沒有辦法確保眾生都可以領悟各自宗教的精義，身體力行，行善摒惡，並潛移默化，最終達到澈悟之境，所以佛教有謂十八層地獄、六道輪迴，基督教有謂末世的審判......，其目的不就在告訴其信徒與社會上的人，哪些事不能做，做的話會有什麼樣的懲罰，所以大家就不該去做。但是想想看其效果如何能？宗教最終還是只能渡化有緣人吧。

軍人與警察等職業的人該如何養成呢？給他們所有該知道的Code of ethics and professional practices(事實上不論公務人員、軍人、警察、老師.....等等職業都各有相對的倫理與專業常規)，如果沒有相對的一些法律與罰則的協助，是否能夠提高專業人員養成的效率與效果？(個人軍旅生涯二十多年，軍校教育就有七年，但是所有的對軍人的教育訓練，並沒有因為出了學校而停止，只是換了方式，在軍校裡鮮少聽到「陸海空軍刑法」，教的都是Code of ethics and professional practices的思想觀念與技術層次，但是到了部隊裡，常常要給官兵上軍刑法的內容及案例宣教，以確保其行為舉止符合要求)。

我想整個軟體業界不該是在學的學生了，還需要一些提示與諄諄教誨，因為他們產生的軟體可不是學校裡學生習作的產物，讓老師評分用的，而是要在大環境裡，在各種可能的挑戰(包括惡意碼與未授權的使用)下，對使用者提供服務，為stakeholder創造或維護其利益。也因為如此，他們應該受到的是監督而不是教育與協助，尤其是訂製軟體，並不同於off-the-shelf軟體產品。訂製軟體是客戶先提出需求也給了錢，因此應該受到相對的保障，而off-the-shelf的產品是產品已經完成了，大家可以視需要，依照成本、利益、風險等考慮，要不要成為其客戶。(時有聽業者說：「連微軟都有瑕疵了，對我要求那麼多是不合理的」，其實訂製軟體與商場現成軟體情況是不同的)筆者在此都是針對訂製軟體的業者，而不是商場現成軟體。

儘管筆者恰好身處於這個領域，且長久以來受到的教育與工作性質與這個領域有很緊密的關聯，但是，我的思考是從stakeholder的角度出發的，不是台灣軟體業的振衰起弊，是軟體業的社會責任，就如同所有法律的制定，是為了保障社會最大的集體利益，而不會是單一行業的利益。

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
想想，有多少人開始騎機車戴安全帽，開車繫安全帶，是出於對於自身安全的考量呢？好像是交通法規開罰之後，大家為了不被罰才開始的吧！而我們又可以看到，在鄉間偏遠之處，警察看不到的地方，不開罰單的地方，多少人是能不戴就不戴安全帽呢？這個情況不止是在台灣就算在中國也是一樣，在中國只要求駕駛人要繫安全帶，我上他們的車，自主性地繫上安全帶還會被駕駛人制止(這個有點好笑)，我得老實說「我已養成習慣」才行....，所以華人社會似乎是有規定而且要有罰才會去遵循，對於自身的利害常常也是選擇性地視而不見或心存僥倖呢！

----------------
引文:

法律主要的功能，在於傷害“事件發生之後”，讓受害者求償有門或者讓加害者受到應有的懲罰；其次才是，消極的“嚇阻”傷害“事件的發生於事前”。正如“家庭暴力防治法”不能有效遏止家暴事件的發生。因此，為了有效促使“品質能真正地注入於軟體產品中，以滿足stakeholder的需要”，必不能只仰賴消極的嚇阻力量，而必須同時求助於“積極的力量”。

此一“積極力量”的來源分為兩個層次，一為組織的層次，另一為個人的層次。在組織的層次上，首先在客戶(主要的stakeholder)方面：要依其外部的失敗成本，提列一合理百分比作為預算，以要求供應商進行必要的品質活動；而在供應商方面：要能夠知道在什麼樣的成本之下，可提供什麼樣的資源，透過那些過程與活動，以達到什麼樣的品質水準。另外在個人層次上：參與在軟體開發活動中的人員，要具備有大前研一（國際知名管理大師）所謂的“專業實力”，也就是：「每個人都要衷心銘記，任何工作都應該以客戶為重，並且決心為此獻身。」而要能夠達到這個標準，個人以為每個人都要具備“長期的約束力與驅動力”。因為“長期”才能顯示其“衷心銘記”; 因為“自我約束”才能做到“以客戶為重”：因為“自我驅動”才能展現“決心獻身”。

有了此一認識，再逐一審視“Software Engineering Code of Ethics and Professional Practice”的八項條款，您就會知道：其中第一條有關Public的條款、第二條有關Client and Employer的條款、第四條有關Judgment的條款、第五條有關Management的條款主要在提供軟體人員所須要的“約束力”；而第三條有關Product的條款、第六條有關Profession的條款、第七條有關Colleagues的條款、第八條有關Self的條款 主要在提供軟體人員所須要的“驅動力”。所以，個人以為：唯有台灣多數的軟體從業人員認同並起而實踐這份文件的內涵，這個行業才夠格稱得上是一個具有“專業實力”的行業。

當台灣的軟體業真正成為：具有“專業實力”的行業，不只已完成其“救亡圖存”的工作，更進一步應該能夠有效提供其“專業實力”以服務其它的行業。此一境界才是整個台灣社會與人民所真正樂見的結果。

一件事情的成功，往往是有許多因緣條件聚合而成。因此，我們想要促成一件美事的發生，也必須多管齊下，而不能獨尊一法。個人非常贊同泰龍兄的提議，只是覺得要再加上其它條件，才能畢其全功。

最後再次，祝福 台灣軟體一族和所有的台灣人：願大家轉好運，好運大家轉。

為了保障用路人的安全而遏止酒後駕車，相關的交通法規罰則修訂加重並實施，如果這樣的法規的實施後，因酒後駕車造成之傷亡快速的降低，就有其積極的效果存在。當因為服從且養成酒後不開車的習慣，甚至於對酒後開車會有罪感的人多了，就可以造成質的變化，整個社會的風氣會起來，人民不酒後駕車文化才能養成。如果沒有菸害防治法，有多少吸菸者會真正出於對別人的尊重而不在辦公場所及密閉空間裡吸菸？沒有菸害防治法，只是勸導，吸菸的人同樣會問你....「不准我吸菸，那我的權益何在？討厭菸味的人有人權，吸菸的人就沒有人權嗎？」很多人原本吸菸的人戒菸，除了是因為菸對於人體的危害之外，還有就是可以吸煙的空間越來越少了。

回到我們的主題。由於近年來在各方的努力之下，軟體品質、軟體工程、軟體過程改善的相關理論與實踐，其論述與教育訓練課程真的多到不可勝數，甚至於可以說軟體品質的話題已經到了陳腔濫調的地步，軟體業界甚至於已經認為了無新意，這從各個軟體品質相關單位所提供課程的招生人數或可以得到一些印證，所以顯然，對於軟體品質與軟體過程改善，大家不是不知道。但是，客戶認為軟體品質是廠商應該要做，所以不用要求，相對的，廠商卻認為，客戶沒有要求，所以可以不用做，因此，就可以省很多工。例如，我們談FCA、PCA，這對於軟體產品而言，可是件非常重要的事，可是，客戶不認為他們需要管或提出要求，因為，只要出軟體問題了，找廠商來解決就對了，自己沒有能力也沒有必要去trace文件與產品，而廠商則會認為：「軟體產品出問題，客戶找我就好了，我保證把問題解決，至於我怎麼解決客戶就不用管了，文件與產品現況對不起來，影響到工作的效率與效益，其相關的成本我自己會負責，客戶也不需要管」。由於獲取者與供應者間有這樣「互補」且「對應」的心態與「默契」才是問題的癥結所在。
我也很同意Albert所提“Software Engineering Code of Ethics and Professional Practice”對於業界的重要性及效用。但現在實務上的問題會是：於有沒有環境可以讓大家來實踐這些常規？客戶會不會配合？在專案期間，客戶給不給廠商實踐這些常規的空間？沒有的話，該如何營造這樣的環境？客戶不給的話該怎麼辦？一年的專案，如果合理的開發時間是九個月，而客戶說不行(可能因為採購作業已經耗掉了三個月的時間)，我要專案kick-off之後六個月開始上線試用，然後我們再慢慢修改，這與來的契約是完全兩回事，在這樣的專案條件下，這些practices要如何implement？

如果沒有環境可以實踐這些軟體工程的常規，那麼，如何「經由量變而產生質變」，進而最終獲得整個產業能力的提升呢？

----------------
引文:

不管在那一個行業，品質問題本來就是以實踐為主的課題，而非理論論述的課題。推動品質的人實不應以他人認為這是陳腔濫調而氣餒。

現階段各個軟體品質相關單位所提供課程的招生人數，確實少得可悲。但這並不表示，軟體品質已被多數軟體從業人員理解、誓願要實踐(對不起，也許各位網友認為用“誓願”是言重了，不過大前研一認為這是專業人員與非專業人員的分野)並有能力將它實踐於工作中。只要大多數軟體人不能將應有的品質注入於工作成果中，那麼有心從事軟體品質推廣工作的人，就不能說這項教育訓練的課程已過多了。反而應依循我們自身所建議的PDCA的做事方式，深切檢討推廣的方式在哪個環節上出了問題？我們本身是否有持續地檢討與改進？

泰龍兄所描述的：“獲取者與供應者間有這樣「互補」且「對應」的心態與「默契」…”的現象。以個人淺薄的見解認為這是由於，掌握有編列預算實權的人，對軟體品質的認識有嚴重的徧差所導致。因此，我們應針對這個實質問題找出實質的解決辦法。個人沒什麼創見，只是覺得可仿效品質大師戴明在日本所用過的方法，就是對這些高階管理人員進行必要的演講，以期喚醒他們的良知良能(個人以為追求品質是人類的良知良能)。

另外，在軟體專業人員的個人能力層面上，我也認為還需要很多很多的教育訓練。這只要看看市面上提供給程式員(任何語言)的訓練課程時數，再反觀提供給非程式員(如：需求工程師、軟體測試工程師、軟體品質工程師、軟體型態管理員…等等)的軟體專業訓練課程的時數，您就會知道這些訓練課程的時數是不夠的。再看看各軟體開發組織有能力完成以上這些專業工作，並達到所需要的品質水準的人員數量，您也會知道這些專業人員的數量是嚴重不足的。再更深入的瞭解有多少組織能夠落實執行“反覆式”的軟體生命週期模型，您也會知道各組織中能夠進行平行作業的專業人員種類也是不足的。有此“三不足”，就表示有太多太多的工作等著有心人去做，只要持續地走在正確的道路上，就總有到地頭的一天。加油吧，朋友們！

台灣軟體業目前正處於一個惡性循環中，個人以為任何惡性循環都可在任何一點予以切斷。也就是：身處於惡性循環中的任何人，只要自覺並願意，就都可以用自身的力量，在自己所處的那一點上，找出方法將那個環節切斷。願以此與大家共勉。

最後還是祝福，祝福 台灣軟體一族和所有的台灣人：願大家轉好運，好運大家轉。

Albert提到有關於品質大師戴明的經驗，我想在此就該段歷史的研讀所得，與大家分享一下。
二戰後戴明接受麥克阿瑟將軍邀請赴日協助日本復興(1950年)。他以其在西方電子公司任職時(1920年代)，所獲得Walter Shewhart的統計式過程管理的研究成果，(以品質理念)帶動了日本的工業界，但是他之所以可以做到，有很大一部分原因是：他是美國人，而日本人認為他所講的品質理念及技術方法，就是美國工業界所奉行且推動的，所以美國有強大且高度的工業技術水準(當然，這是一項誤認)，因此日本人努力學習，並且非常自我要求地實踐。實際上，如果我們把時間回溯到那個年代(1950年代)，美國的工業講究品質嗎？其實是沒有的。只是日本人根據戴明的想法努力推動，是為了將產品可以順利銷到美國去(怕產品不符美國人的品質要求被打回票)，促進日本國內的經濟而已。因為品質管理的哲學促使了日本產品品質的提升及經濟的發展，到了1980年代，品質管理哲學才回流到美國(美國國家廣播公司的電視節目--「日本能，我們為什麼不能」，這也讓美國人初次認識了他們自家的寶貝--戴明博士)。本質上，日本人一開始推行品質理念與方法，就是順著我提到「由外而內」的方式(經由外在驅動力、約束力而遵行，但漸漸地潛移默化成為工業文化的一部分)，後來日本人真的領悟品質意義，並經由品質改善而獲得豐厚的回報。如果，那時候資訊夠流通，使日本的工業界看清美國工業界根本不是那樣子做事的，我相信，日本人也不會買戴明的帳，甚至於會覺得戴明在浪費他們的時間，因為品質管理與改善是需要一段時間的孕育與成長，無法立竿見影且立即獲利的。

戴明1942年至1950年期間亦對美國的工業界傳授Shewhart的統計式過程管理方法，但是到了1980年代，美國工業界才發現他們落後了日本人一大截。美國工業界先於日本工業界接受這些觀念教育，但是為何會有高達30年的差距呢？....

個人認為做研究的時候，掌握年代、環境、人文、社會、時序、邏輯等等，應該會得到更加深入的理解。在思考問題解答的時候，前述的項目(年代、環境、人文、社會、時序、邏輯等等)，或許也可以提供一些方向吧。

----------------
引文:

泰龍兄所描述的歷史一點都没錯，不過我要說的是：品質管理的理論其實很簡單，也可以說都是老生常談、了無新意。品質管理的可貴之處只在於信、願、行而已。

不論日本人為何信它、美國人為何不信它，這些原因都不重要，重要的是高層的人相信它有效、願意去實踐它而且也真的身體力行了，那麼就能帶來驚人的成效。在傳統製造業上，日本人信戴明的方法，並且實踐了，所以在那個時空下領先了其它國家。在軟體產業上，美國政府(國防部與議院)相信軟體工程那一套，所以在軟體產業上領先了其它國家，也訂出了CMMI這套標準；而印度的軟體領導者相信了CMMI這一套，並且帶頭實踐了它，所以在軟體代工產業上領先了其它國家。

除了信願行外，另一重點則是：這個信願行一定要由上而下的推展，所謂上行下效。各位看官若對照前述三個例子，應該知道所言不虛。品質管理若非由上而下的推展，必然會在上樑不正下樑歪的至理前功虧一潰。這一點不再贅述，就請各位看官自行去印證了。

台灣軟體業要不要改變，要怎麼改變？這一切的決擇，就看台灣軟體產業的領導人與其它各行各業的領導人相信什麼、內心的真實願景是什麼以及如何去實踐他們所相信的以完成他們所想要的(願景)。

最後，除了祝福還是祝福，祝福 台灣軟體一族和所有的台灣人：願大家轉好運，好運大家轉。

有關於軟體工程的部分時序的部分(許多的工程制度、標準與要求，都是在日本人在品質管理上獲得成功之後陸續產生的，尤其是「過程」方法)：
DoD-Std-2168 - 1979(1990)年 DEFENSE SYSTEM SOFTWARE QUALITY PROGRAM
DoD-Std-2167 - 1985年
DoD-Std-2167A - 1988年
MIl-Std-498 - 1994年
ISO/IEC 12207:1995(E) (起草於1987年) (2002年第一修正案，2004年第二修正案、2008年改版為第二版)
EIA/IEEE-J-Std- 016 1995年
IEEE/EIA-12207.0 1996年
ISO/IEC 15288:2002 (2002年初版，2008年第二版)

1990年PB90-185505 美國國防部與美國商務部共同起草的Total Quality Management Guide

有關於CMMI的部分
1986年Watts. Humphrey 著作Managing Software Process (SW-CMM之基礎)
1986年GOA的要求，DoD要求國防部所屬改善軟體專案執行不力的問題，美國空軍向國防部提出解決廠商資格判定的問題的解決之道
1987年美國國防部資助卡內基美隆大學軟體工程學院，發展軟體廠商評量的方法，以及提升軟體工程學術與常規作法。
1993年SW-CMM V1.2版
2002年CMMI V1.1版
2006年CMMI V1.2版

印度人的軟體工程能力是被美國人要求出來，而非印度人的企業領導者對於軟體品質真的有什麼真知灼見，美國的主包商被美國國防部要求軟體工程常規與品質要求的實現，美國的主包商能不好好要求印度的軟體公司嗎？只是在這個時點上，印度的軟體公司站在成熟度的高點上，大家忘了事情是怎麼開始的，只是看到人家脫脫換骨的一面，卻沒有去探討這個脫胎換骨的歷程，當然，現在印度的成功軟體企業的領導者，在軟體品質觀念層次上或許真的改變了(我說得很保守，因為實際上，印度軟體企業，空有CMMI三級以上的成熟度，但是內部過程一團亂的還是很多，這是與我的印度前公司的同事交流心得)。(我習慣了高層在開場場合經過修飾或找人捉刀之作，領導人是否真的有好的觀念與願景，沒有私下交流之前，我不會妄下斷語)。

我同意Albert談到品質管理的「信願行」。但是這三個字的順序，我認為應該是：「行、信、願」。這是事情推動的方法與歷程，否則很容易流於「清談」。所謂「知之非艱，行之惟艱」，現在資訊發達，而大家對於軟體品質管理的，不也正處於「知易行難」的心態中。
「行信願」的順序實在是因為大家總認為自己的情況與別人(典範)不同，遇到的案子的難易與挑戰與別人(典範)不同，因此還是會對於這些學說理論存疑，許多人就是如此，儘管別人已經成功了，但是就是不願照著別人的步伐走，認為以自己的聰明才智，可以找到「更簡單、更省錢、獲利更好」的作法。在這個情況之下，只有靠外力讓他先做，當好處發生了，自然就相信了，再來這個信念才能由上往下地要求與落實。現在導入CMMI或是其他軟體品質制度的公司，好像都「行」了，但是，我們實地去看看吧，接受檢驗的「證據」都是刻意「製造」出來的，而不是真的按著工程方法或制度自然而然地產生的。會發生這種情況的原因就是沒有強烈的外力來驅動與約束(法律會是一項重要的外力來源)。沒有制度化的「行」，後面的信與願就不用提了。

----------------
引文:

“信願行”這三者是一體的不同面向，也可以說沒有先後順序。更確切地說是，先後順序不重要，因為缺了其中任何一項，另外的兩項都是空的。所以，“信願行”、“行信願”或“行願信”都沒關係。

我們就先從“行”談起吧，泰龍兄所說的：『現在導入CMMI或是其他軟體品質制度的公司，好像都「行」了，但是，我們實地去看看吧，接受檢驗的「證據」都是刻意「製造」出來的，而不是真的按著工程方法或制度自然而然地產生的。』這個現象就是：好像有“行”而沒有“信”。因為，如果真的相信CMMI是有效的，怎麼會用刻意「製造」出來的「假證據」自欺欺人？“真的”行了，又怎麼會“好像”行了呢？譬如：常人都相信唯有食用真實的食物，才能讓自己活下去，因此常人就不會餐餐用“嘴邊抹油”(刻意製造的證據)的方式，告訴別人和自己已吃飽了，可以有活力繼續生活與工作下去。任何行為唯相“信”那樣做是可以達成夢想(“願”)(或有效果) 時，才能真實的採取實際“行”動。如果，“行”了一段時間不能滿“願”時，可能有人就產生懷疑而再“不相信”了；或者覺付出太多，而“不願意”去追築這個夢想了。一旦，“不相信”了或“不願意”築夢了，也就“行不下去”了。如果，此時在外力的要求下，就會產生自欺欺人的行為以掩飾自己的“不信”、“不願”或“不行”。

“信”也是一樣，任何人說他相信什麼信念，可是他經常表現出與他所相信的信念不一致的“行”為時，那麼他聲稱他相信那個信念又有何意義？同樣地，如果他的行為表面上看似符合他所相信的信念，但是在他周遭的人可以很明顯地感覺到他的不甘與不願時，那麼他這樣的聲稱與不甘願地行動又有何意義？還不如乾乾脆脆做他所信與所願的來得快樂些。

“願”也是一樣，如果實際上沒有採取任何“行”動，去努力“築夢”，在時間過去後狀況依舊，這樣的願就只是“空夢一場”，也會使自己喪失信譽。同樣的，如果沒有“信”做基礎，就表示沒有築夢的方法或不相信那個方法的可行性，當開始行動後，稍遇挫折就没有信心甚或放棄。最後這個願也只是“幻夢”一個，沒用的啦！

“信願行”要能產生作用，就必須三個同時且真實地存在，缺了其中任何一項都起不了作用的。

最後，祝福大家一起以真實的“信願行”，來為　台灣軟體一族和所有的台灣人“轉好運”。願『大家轉好運，好運大家轉！』

Albert以接近宗教家的思維推動品質管理的觀念。
筆者則是以軍事教育訓練與法制社會的角度與作法推動品質管理的觀念。
目標相同，但是方式不同。
這個議題，應該需要有更多的觀點來演繹，以找出最適合於台灣社會特質、文化、思維與環境，能迅速帶動整個風氣的作法。

----------------
引文:

關於這個議題，我和泰龍兄說得已夠多了。現在，應該由各位看官上場發表您們的看法了。

這個園地需要各位積極地參與以集思廣益，台灣軟體業才會有所轉變。

朋友們，來吧！大家一起來！為　台灣軟體一族和所有的台灣人“轉好運”！