我們的軟體業面臨需要提升的時刻，到底我們的軟體業缺少的是什麼，是技術、自動化工具、專案管理或者是CMMI的洗禮？

個人以為，首先，我們最缺的其實是使用過「以最佳常規所設計與製造出來之系統、產品或服務」的經驗，所以永遠不知道系統、產品或服務的目標與效果何在。這個部分，是使用者與業者普遍缺乏的能力或經驗。為何需要有這些經驗？因為如此才會體會到工程的重要性。

其次，是缺乏系統工程的能力。獲取者不懂得系統工程，因此找不出自己的需求，開發者不懂系統工程，所以只知道用開發環境去把軟體系統或應用程式「寫」出來。然後，到了最後再來測試系統，用黑箱測試來找問題，沒有辦法在事先把問題找出來，以防範問題的發生。

其三，缺乏軟體工程的常規(practices)，就算有軟體工程的程序，也多半不能稱為「常規」(所謂的practices指的是，日常工作的執行方法或程序，成為組織做事習慣與文化的一部分者，才能稱之為「practices」)，所以開發不出具備品質的產品，系統開發的方法無法重複與重現。

其四才是專案管理，因為專案管理除了與組織業務目標有關之外，還與組織的架構、開發產品的特性、組織的軟體工程常規及系統工程能力有關。專案管理乃是為確保做好系統工程及軟體工程的工作因應而生的。

如果第一、二、三項的能力不增進與提升、就算有PM的觀念又如何，現在具有PMP專業認證者全球有十多萬人，可是，這些人會做專案管理嗎？這是有問題的，因為沒有系統工程、軟體工程的觀念與能力，就看不到，也發展不出需要管理的工作與項目了，當然，真正的專案管理也不會存在。

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

或許當初跑一個「軟體工程」出來就是一項錯誤，讓大家輕忽了「系統工程」，讓大家都把眼光都放到軟體的開發上，而沒有注意到軟體是系統整體的一部分，有軟體產品才能運作，但是如果沒有整體的規劃，系統其他部分，例如伺服器硬體、網路基礎建設的問題，都會影響到軟體效能的展現。

目前整個趨勢的發展，ISO中負責軟體標準發展的委員會，已制定了ISO/IEC 15288這個標準，這個標準中有關於軟體發展的過程是指向ISO/IEC 12207的，現在更有國家的要求要把12207與15288完整整合在一起。而IEEE的SESC(軟體工程標準委員會)，也改名為S2SEC(系統工程暨軟體工程標準委員會)，也就是說，兩者正走向整合。

還是一句老話，軟體工程、自動化工具都不是問題的解，如果缺乏「系統工程」的能力，不懂得如何規劃與設計系統，再強的軟體工程能力也是枉然。因為經由「系統工程」的規劃與設計，會衍生出非常多軟體架構的方案，但是從系統觀點來看，何者是真正Cost-effective，其解答也不在於軟體工程與自動化工具，而在「系統工程」上。

台灣的純軟體業其實已經沒有前景可言，因為在台灣資訊軟體專案的甲乙雙方或者同業的競爭已讓整個狀況惡化到幾乎無法挽救了，未來，在台灣能夠撐起來的，是硬體或產品業(例如，消費性電子產品)。印度人很清楚，他們有夠強的軟體開發能力，他們很久之前就想要與台灣合作，台灣做硬體產品，印度人開發這些硬體產品的軟體。這樣的分工其實很合理，但重點是，如何分工？哪些該分給硬體，哪些該分配給軟體？這需要的是「系統工程」規劃分析與設計的能力，因此，誰掌握了這個能力，才有可能主導這樣的分工，做對自己有利的利潤分配(就好像美國挾其強勁的「系統工程」能力，做完系統分析及設計後，將硬體部分分給台灣代工製造，將軟體的代工分給印度一樣)。這也是我一直強調「系統工程」的原因。創意+「系統工程」能力才是台灣的未來，因為，有了這個能力的組合，其他的國家，例如中國、印度，所能扮演的，只有軟體代工工廠而已，真正的價值核心與競爭優勢，才能長留在台灣。

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

我認為目前台灣軟體從業人員最缺三種觀念: 系統、工程、管理。

由於長期以來市場的需求以及資訊的教育「重技藝而輕管理」，導致如今我們台灣的工程師多半只能開發小型簡單的軟體，而歐美及印度卻能承包動輒上千萬美元的大型軟體系統工程。連成熟的營建業都有規劃設計、營造建置、監造審驗的分工機制，軟體業呢?

我們的軟體產業多半還停留在「工匠師傅」各自獨力完成藝術品的境界。要求程式設計人員填寫工作日誌會被認為是「額外的要求」，因為從來沒有人告訴他們撰寫技術文件是他們工作的一部份，學校也沒有教他們......

我覺得台灣軟體界缺少的是一種熱忱：追求品質(卓越或者自我超越)的熱忱。由於缺少了這種熱忱，做起事來就沒有原動力，變成得過且過，凡事只求交差了事。只要能堂皇其外，那管什麼敗絮其中。只要今天能交得了程式，那管明日維護時的苦痛。只要今天能掌聲響起，那管明日噓聲四起。只要今日業主能驗收，那管明日使用者的當機。只要今日能拿下案子，那管明日專案的失敗與賠錢。

缺少了前述的熱忱與精神的人，您又怎能去期盼他去屨行合約中所作的承諾？您怎能期望這種人能去學習系統工程、軟體工程中的各種技術與方法？

台灣軟體界若再不痛定思痛，任什麼ISO 9000、CMMI、CNS14837、旗艦計畫、認證制度都沒有辦法救得了。這些都是台灣軟體界過去自種的惡因，只有徹底改過遷善，找回或培育出有這種熱忱與精神的軟體從業人員，才能有美好的明天。

若從組織的角度來回答『業界缺什麼？』這個問題，個人認為業界缺的是：『知識』。

“軟體開發”雖不是什麼高科技的行業，但無庸置疑的它是一個『知識密集』的行業。就以筆者現在參與的專案而言，它至少需要下列知識：系統分析與設計的方法(UML或傳統的結構化分析與設計)的知識、程式撰寫(各種語言) 的知識、通訊網路(有線、無線與CTI…)的知識、電腦硬體與作業系統的知識、地理資訊技術的知識、資料庫管理的知識、系統工程與需求配置的知識、型態管理的知識、軟體測試與驗證的知識、專案規劃與監控的知識、軟體品質保證的知識…等十幾種。單一專案已是如此，整個軟體開發的組織要承接各種不同領域的專案，因此，從組織立場所需要的知識是更為寛廣的。要在專案(甚或組織)中完全具足以上這些一般性的知識項目已非易事，但是，真的具足了這些一般性的知識就夠了嗎？當然不是。

您還需要系統的知識來指導您，在什麼時候要投入什麼知識。您必須有系統的將各種知識匯集到您的產品中，而不是一股腦的將所有的知識倒進大鍋中。這個『系統的知識』就是您公司中特有的程序(Process)。您也許會問沒有程序(『系統知識』)和有程序有什麼差別？個人以為它們的差別在於：有程序的組織不論對內或對外不必要的衝突比較少，所有的力量是和諧一致地在時間軸上點點滴滴地增加產品的價值，組織中所有成員的行為是比較能預測的。還有更重要的一點是：有了程序組織才能蓄積能量。這樣說您可能不太明白，打個比方：程序匯集不同知識的方式，就如同涓涓水滴經由百川而納入大海一般，因為有了河流，我們就可以在適當的地形形成湖泊或建立水庫，以備不時之需。同樣地有了程序，我們就可以累積經驗，建立『組織的知識』。

什麼是『組織的知識』？『組織的知識』就是組織過去運用系統知識(執行程序)所累積出來的東西，包括：您在程序中所累積出來的數據資料，以及學到的經驗(Lesson Learned)。『組織的知識』可以幫您記憶過去、改善現狀、預估未來。沒有了『組織的知識』，組織對過去就沒有記憶；也不知現在身在何處；對未來更沒有務實的期許與規劃。

請問您的組織具足了一般的知識嗎？有一套『系統知識』嗎？有您們自己的『組織知識』嗎？如果對這三個問題的回答有一半以上是否定的，那麼業界是不是缺少知識呢？

一、工具：硬體代工、軟體自然也是代工。
每每自認品牌已經創立了，主導者稍稍一改遊戲規則，
臺灣就慌了手腳，累死累活替人作嫁空歡喜，
術語叫做"消防隊"。
二、工具：所有的資訊建立好了，卻因為需求者(買主)換了系統，
所有資訊面臨轉換或廢棄，根本無從累積經驗成知識，
面對的挑戰全是"如何重覆同一件事以不同指令"。

看到sywaddr1先生發表的意見後，我要對前次表達的意見做一些補充。

上次提到三個名詞：『一般的知識』、『系統的知識』與『組織的知識』。首先我們要了解，這三種知識是依知識的層級來劃分的：『一般的知識』它在知識的金字塔的最底層，中間是『系統的知識』，最上層是『組織的知識』。這是它們之間的關係。

『一般的知識』是：所有各個學門的知識，譬如：軟體語言、系統分析、系統工程、軟體工程、通訊工程、專案管理…等都是，通常我們稱它們為專業知識。它是市面上可以買到的，它存在於書本、文獻與個人的大腦中。『系統的知識』是：一個由一群具有不同的專業知識(一般的知識)的知識工作者所構成的組織，如何運用(滙集)這些存在於組織成員腦中的知識的知識。它大多是由各個組織自行發展(建立)而來的，通常在一般的知識市場(書店、教育機構)上是買不到的，要買它的話只有向專業的顧問(或顧問公司)才買得的。當然組織也可以藉由技術移轉來得到它，但是，組織必須在技轉後改變組織文化，若不能改變組織文化，那將只是『船堅礮利』而已。或者也可經由企業購併的方式得到它，不過組織必須能夠在購併後保有被購併的公司的企業文化，否則，也可能只是空歡喜一埸，最終還是得不到它。『組織的知識』是：組織內的成員在工作中確實依循組織具有的系統知識執行工作，依此而累積出來的各種成果。它包括：各種數據、資料；以及在工作過程中由於犯錯而學到的各種教訓。這些知識是這個組織所特有的，除非能將這些組織知識專變成系統知識或一般知識，否則，它會與組織共存亡。也就是組織存在的時候，這些知識也存在並且能發揮作用；當組織不存在時，它也就不能發揮作用而失去其價值。

瞭解這些後，我們可以看看sywaddr1先生所提到的現象。

首先，他談到『硬體代工、軟體自然也是代工。每每自認品牌已經創立了，主導者稍稍一改遊戲規則，臺灣就慌了手腳』。我想這是任何從事代工者所必須面對的現實情況。『代工』通常發生在產品發展或製造過程的下游；在自然界或人類所創建的環境中，下游總是被上游的變化所影響或主宰的。除非離開這樣的環境，否則，我們只有面對它。

其次，他說到『所有的資訊全建立好了，卻因為需求者(買主)換了系統，所有資訊面臨轉換或廢棄，根本無從累積經驗成知識。我要問的是：上游買主的改變是不是一定會造成下游代工者不能累積經驗成知識昵？個人認為這兩者間沒有必然的關係，真正影響代工組織能不能累積經驗成知識的是：有沒有需要？此話怎講？我的意思是當代工組織在執行『代工』的工作時，是否“需要”密集的知識(譬如：晶圓與筆記型電腦的代工)，如果需要密集的知識，那麼，組織就“有必要而且一定能”累積經驗成知識，只是“願不願”與“知不知”的問題。如果組織從事的只是“包水餃”式的代工(只需單一技能或知識，任一代工產品只需要一個步驟或極少的幾個步驟，而且這些步驟彼此間沒有先後順序的必要)。那麼，組織就沒有必要發展『系統的知識』，沒有系統知識也就不會有『組織的知識』。簡言之：組織要不要與能不能累積經驗成知識，端視組織從事的是不是『知識密集』的工作？如果，答案是肯定的。那麼剩下來的的只是“願不願”與“知不知”而已。

軟體品質協會管理師 周茂松

各位先進們所言句句中的，也是目前軟體業界的常態。
我先提出一般人從接受刺激到行為產生的流程列出：
環境刺激->開始思考->觀念建立->知識產生->行為產生--重覆-->習慣建立

先進們已經對此一流程提出許多的看法，但我提出另一個想法：「環境」。

人是個奇特的生物，會隨著「環境」改變以適應環境，現在諸位所看到軟體產業的現況其實只是這個環境的產物。環境沒有給人思考的機會，自然不用什麼特殊的觀念想法因應，只需要附合現況的知識配合，不需要新的知識，自然有這樣的行為產生。

對照台灣的電腦硬體產業，集合了產、官、學界的努力配合一流人才與顧客才有今天的成就。但今天的軟體產業，缺少了官方關注與資助、學界的人才沒有流入軟體業界、業界沒有良好的環境與機會發展，自然產生現在的結果。但是弔詭的是，這似乎也是惡性循環的結果：因為環境不健全，只能用特殊的方式生存，因為只能用特殊的方式生存，只有具有特殊生存方式的廠商能存活。

假設：有任何一個台灣的軟體廠商，能接到國外的軟體外包案，由國外顧客來要求軟體品質，為了顧客的需求和商業利益吸引，台灣廠商的層次一定能提昇。就像是台積電、鴻海的客戶都是國際大廠一樣，一定要認證，才能接案子！

我相信，知識產生後的行為都很好完成，重點是在環境、思考與觀念，這些才是最難改變也是最關鍵的地方，這些重點這也是我們現在之所看到如此這般的真正原因。

前幾次，都把重點放在“業界缺什麼？”的問題上，今天，我想探討一下“為何軟體產品老是做不好？”這個本質的問題。為了回答這個問題，我覺得可以把它稍微改一下成為：“為何軟體品質老是做不好？”要知道這個問題的答案，首先我們要知道軟體品質從那裡來？

個人以為：正如同“交易”是由“需求(demand)”與“供給(provide)”而來； “軟體品質”是由“要求(request)”與“承諾(commitment)” 而來。為了對這個概念有比較精確的理解，我們須要對“要求”與“承諾”這兩個詞有比較精準的解釋。我採用牛津字典的解釋，“要求(request)”的意思為：『the action of asking for something formally and politely』；“承諾(commitment)” 的意思為：『agreeing to use money, time or people in order to achieve something 』。將它套用到我們的問題，於是，軟體品質的產生是由於：
1. 需要軟體的人或組織正式地對軟體品質提出請求；
2. 供應(開發)軟體產品的人或組織同意利用錢、時間與人員去實現軟體品質。

到此，我們就可以充份理解為何我們“老是做不好軟體產品”了。因為，在我們的環境中沒有人或組織“對軟體提出正式的品質要求”，這個可以由各個標案的RFP中得到印證。看到這兒別以為，我們這些從事軟體開發的人就可以把軟體沒有品質的責任，名正言順地全推給需要軟體的人或組織。“要求”與“承諾”是『雞生蛋，蛋生雞』的問題，只要有心，從任何一點都可以把這個惡性循環變成良性循環。假設，今天若有人不論國內或國外，願意給我們很高的利潤來開發一套對軟體品質有明確要求的系統，唯一的條件是若不能在“時限內完成”“符合軟體品質要求的系統”，會有“高額的罸款”。試問：今天有膽量來承接，並有能力完成這樣的系統有多少人？為何其他的人不敢？原因無它，沒能力、沒知識而已。何以沒能力又沒知識？無它，因為我們沒有熱情與氣魄對“軟體品質”做出真正的承諾。

看看CMMI第四章中GP2.9的最後一句話，您會更明白我的意思。

軟體品質協會 管理師 周茂松