軟體組織為了要結省人力成本(當然也可能是因為好的人才獲得不易，因此希望能夠善用人力資源)，在進行軟體發展的時候，實際上是沒有所謂的「軟體發展生命週期階段」這回事的，因為常常是一個或幾個人共同去實作一個系統，而且每個人負責一塊，從需求到程式碼產品完成，所有該實現的需求是以人腦記憶下來，沒有任何的設計文件，因為他們認為以這種方式做專案是不需要文件的，文件是多餘的，還會增加發展工作的負荷。而這類專案或產品的成功，其實全部是「以人為本」的(全然是CMMI 成熟度等級一的最佳寫照)。除非是甲方做出要求，以各階段文件的交付來規範軟體廠商的軟體發展行為，但現實的情況常常是，就算甲方做出了要求，似乎也不能夠改變什麼。因為要求交付的文件，總是有專人在處理，只要能夠應付過去就好，或者事後再補，也不管文件與產品間是否具備一致性，有沒有相衝突的地方，因此，對於產品品質這回事完全沒有幫助。

　　美國伊利諾州理工學院所發展的SW-TMM(測試能力成熟度模型)中，Level 2的部分，首先強調要把實作與測試分開，以形成「階段」，以免實作與測試混雜而產生困擾，使得實作、測試與除錯三個工作都做不好。軟體發展也是一樣，正規的軟體發展，都會有「階段」劃分的需求。不論你採取什麼樣的開發方式，瀑布式也好、漸增式、演進式、螺旋式也罷，或者是採用RAD(Rapid Application Development)開發方法，其實都是一樣，需要有「階段」的概念，也許有些公司認為，我採用的是「雛型法」，我就是快速地產生一個雛型，讓使用者去試用，然後再依照使用者「真正的」需要，把功能持續地加上去，一方面可以協助確定使用者的需求，二方面也可以提升系統發展的效率，而且，這麼做，當所有的功能都提供之後，就可以直接交付結案了，使用者與系統一同成長，因此，也容易結案。但是，這種做法下的產品，其品質是堪慮的，而且採用此法，常會因為思考不夠周延，很可能東改一個小需求，西另一個問題就可能浮現，同時整個產品架構可能會因為常常修修改改而被變更，但發展者卻無法立即察覺到，只會覺得一直有小bugs在產生。有關雛型法，軟體工程大師級人物Barry Boehm的Spiral Model中的各階段雛型，其功能都是用來找出客戶需求、確定客戶需求的，然後製作成系統文件，而最終產品還是需要依據經過確認的系統文件來實作。(因此，目前許多軟體公司的做法並非Barry Boehm所構想的)

　　將軟體發展生命週期劃分為數個階段，其意義在讓發展人員有機會從全系統的觀點去檢視，到底發展的工作是否完善，到底還有那些問題是沒有考慮到的，這不是在增加發展人員的工作量，反而是為了減少因為重工(rework)產生的成本，因為軟體發展不像蓋房子，軟體在實作完成之前是看不到摸不到的，這不像蓋房子，房子沒蓋出來，至少看得到鋼筋水泥及磚塊，而且可以知道這些是用來蓋你要的房子用的，軟體，到處都是程式指令，但是這些指令到底與你的軟體何干，程式設計人員卻永遠也沒法對使用者說清楚。再者軟體上因為分析、設計錯誤產生的連瑣反應，卻也比建築設計上的錯誤更難以掌握。

　　不論是甲方與乙方，均應共同努力，確實要把工程的階段區分出來，尤其是分析與設計的階段，因為這些都還算是軟體發展的初期階段，為了避免因為未來重工所發生的成本，因此就需要利用這些階段的區隔空檔，審視產品可能的問題，以降低重工發生的機會。

　　對於較大型的軟體系統，更是需要如此，而且透過這樣子的分割，更有助於專案進度的掌握。做軟體系統的人其實是很羨慕蓋房子的人，因為工程進度落後的時候，增加人手就可以解決問題，軟體好像不行。這真是個誤解，做不到這樣的效果，問題就出現在沒有明確去區分生命週期的階段、沒有用工程的方法進行系統的發展、進行有效地分工的結果，其實，軟體發展還是可以像蓋房子一樣，花時間在分析與設計的工作上，把需求弄清楚，完成合理、明確、一致的設計，然後訴諸於文件中，由於有完整的規劃、分析與設計，因此，在程式撰寫時，就可以外包出去，或者在進度落後時，增加人手以趕上進度。當然，看到這裡又有人要開始抱怨--使用者自己都搞不定需求，如何要求我們做好設計的工作，其實這個問題還是出在階段劃分上、以及軟體業者對於各種標準要求，甚至於軟體生命週期過程國家標準及政府採購法沒有弄清楚所致，其實都是有解的。但是不論如何，軟體發展的時候，還是應確實把階段明確切割出來，這對於甲乙雙方都有保障，因為這才有品質掌握與改善的機會與施力點，而且可以節省許多不必要的成本，亦可以加速系統發展期程。

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

你的公司具備軟體發展的能力了嗎？要正確回答這一個問題，首先要瞭解：對一個以發展軟體為主要業務的公司(組織)而言，什麼是公司的能力？

對一個現代的知識工作者而言，如果，他具備了某一領域的『專業知識』以及運用這些專業知識的能力，我們就可以稱這個人具有某方面的能力。將這樣的觀念套用到軟體發展組織上，就變成：當一個組織具備了發展軟體所需要的知識，以及運用這些知識的能力，就表示這個組織具備了『軟體發展』的能力了。當有了這樣的了解之後，問題就變成了：您的公司是否具備了“發展軟體所需要的知識” 以及運用這些知識的能力？

“發展軟體所需要的知識”有那些？對組織本身而言，它包含有：
1. 『系統知識』：發展軟體所需要的軟體生命週期過程(Software life cycle process)，也就是組織自己訂定的一些發展軟體所需要的標準作業程序。
2. 『組織知識』：運用系統知識所累積出來的一些記錄。

組織要擁有系統知識不難，在公司內成立一個小組或找一個人，花些時間就可以擬出來了，甚至找一家顧問公司，也可以買到。致於要有『組織知識』就難了，它先要有人能夠依照組織的『系統知識』來工作。這通常需要組織內部的成員也具有相關的『專業能力(具備專業知識與運用專業知識的能力)』。例如：要執行組織特有的軟體開發過程中的『設計』活動的成員，必須具有合格的『設計』能力，才能確實執行設計的活動。其次，在執行各種活動或工作的過程中一方面要累積『組織的知識』，同時，也要運用過去公司已累積出來的『組織知識』。

由以上的說明，我們可以瞭解到一個組織是否有能力，最終(其實也是第一要務)還是要看組織成員是否有合格的『專業能力』？這也是為什麼林秘書長要大聲疾呼，用「人員專業能力評量」來改善組織成員的能力，進一步改善組織能力的原因。

根據以上的分析，現在，我們己經能夠正確回答－公司是否具備了軟體發展的能力？－這個問題了。如果，答案是否定的。而我們就此打住，那麼這個問題對我們一點幫助都沒有。所以，我們必須進一步追問，我們要如何跨出第一步，才能夠使組織於未來具有軟體發展的能力？個人以為，改變“傳統以來的分工方式”成為“專業分工”才是這正確的第一步。 這裡所謂的“傳統以來的分工方式”就是把系統切分為數個子系統，每個子系統只由一個人負責，包括：分析、設計與程式撰寫，甚至於測試。組織如果依然以這種方式分工，而寄望每一個成員具有合格的『專業能力』，這樣就是要求每一個員工要在各方面都具有『專業能力』，這樣的期望既不合理，也不人道，更不可能。因為在人力市場中，這樣的人是稀有族類，價格也很高。您也許找得到一、兩位這樣的人，但是，絶不是多數的成員都能這樣。所以，要讓組織具有軟體發展的能力的第一步，就是將組織內的分工方式改為『專業分工』－由合格的專業人員執行專業的工作。願　您的公司及早改變，也及早具備軟體發展的能力。

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

如果你問一家小型麵包店老闆：『你們具有製作麵包的能力嗎?』，相信答覆多半是肯定的；但是如果你再問他：『你們具有每天大量製作一萬個麵包的能力嗎? 』，他可能就不是這麼有把握了，因為這已不僅是麵包製作技術的問題，還必須考量人力、分工、製程、品管... 等複雜的管理問題。

同樣的，如果要成為一個專業而具有軟體發展能力的公司，已不僅是技術與人力的問題，而是如何"有秩序"、"有紀律"地讓這些人力與技術持續完成軟體發展的工作，因此制度、分工、管控、文件、評量、考核都是不可或缺的。