過去我們傳統軟體系統開發的做法，常是系統分析師兼軟體設計師兼程式設計師又兼軟體測試工程師 …也就是 貴會程理事長常形容的「軟體手工藝業」型態，如果以「軟體工業」或「軟體工程」的角度來看，系統分析師、軟體設計師、程式設計師、測試工程師 … 究竟應該如何分工呢 ?

以 貴會規劃並負責監造管理的「台北市災害應變中心資訊與通訊系統建置案」為例，我看該案的 RFP 要求建置商專案成員包括：專案經理（專案管理師）、系統架構師、系統工程師、軟體分析師、軟體設計師、程式設計師、品質保證經理、測試經理 ... 共 20 人，該案的 RFP 又要求產出「專案管理計畫（含品質保證計畫、驗收計畫）」、「驗證與確認計畫」、「系統需求規格書」、「系統架構設計說明書」、「軟體需求規格書」、「軟體設計說明書」、「測試計畫 (含測試設計規格書) 」、「測試報告書」等文件，請問這些文件的撰寫，分別應該由上列的哪些人擔任呢 ? 能否請哪位老師扼要回答一下 ? 多謝 ORZ !

有關您的問題，簡單回答如下：
「專案管理計畫」由“專案經理”撰寫；
「驗收計畫」由“品質保證經理與測試經理”共同撰寫；
「品質保證計畫」由“品質保證經理”撰寫；
「驗證與確認計畫」由“品質保證經理”撰寫；
「系統需求規格書」由“系統分析師 (或軟體分析師和系統架構師共同) ”撰寫；
「系統架構設計說明書」由“系統架構師”撰寫；
「軟體需求規格書」由“軟體分析師”撰寫；
「軟體設計說明書」由“軟體設計師”撰寫；
「測試計畫」由“測試經理”撰寫；
「測試設計規格書」由“測試工程師”撰寫；
「測試報告書」由“測試經理”撰寫。

補充說明：
1. 在您提到的建置案中沒有“系統分析師”這個專案成員角色，那麼可以由軟體分析師與系統架構師共同擔任撰寫「系統需求規格書」的責任。這樣建議的理由為：軟體分析師應有能力維持“由系統的外部描述(觀看)”系統的能力，但是可能會只看到軟體而忽略了系統的其它部分。而系統架構師會由“系統”來觀照到“整體”，正可彌補軟體分析師之不足。

2. 在您提到的建置案中也沒有“測試工程師”，那麼可以由軟體設計師、系統工程師與程式設計師來擔任設計「測試設計規格」的工作。不過重點是系統中某一功能的「軟體需求規格」、「軟體設計說明」與「程式碼」的撰寫者不要擔任撰寫該功能的「測試設計規格」。

3. 在撰寫「驗收計畫」、「系統需求規格書」與「軟體需求規格書」的過程中，客戶都扮演著重要的角色。

4. 這些專案成員角色所要負責的工作，在軟體工程中是分屬不同的專業知識領域，理想上應由不同的人員擔任。但受限於實際的工作環境找不到那麼多的專業人員時，應確保“每一工作的負責人員與其上、下游的工作人員必須由不同的三個人所擔任。”譬如：A功能的「軟體需求規格」、實現A功能的「軟體設計說明」和測試A功能的「測試設計規格」應分別由三位不同的專案成員負責。

5. 專業分工是組織成長的基礎。祝您有個好的開始。

軟體品質協會專案管理師 周茂松 敬上

我是以工作的觀點來看這個問題。

在專案裡做什麼事的人，應該就那賦予該角色的權責，而不是說什麼事情該由什麼人來做。採取「什麼事情由什麼人來做」的角度來看的話，會面臨專案彈性的問題，因為你實在不好拿捏要由什麼角色的人兼任何種角色會比較好，或許你認為可以將性質相同的工作丟給某一類人去執行比較好，其實像Albertchou所提到的「驗證與確認計畫」由「品質保證經理」來撰寫，這個好像很合理，但是從「品質保證」所要求的「客觀性」與「獨立性」而言，可能是有問題的，品質保證是要從客觀的角度去評估產品與過程對於規範、要求、計畫的符合性，因此，如果驗證與確認計畫是由品質保證經理撰寫，有關於「驗證與確認」的規劃與執行(產品與過程的)狀態，試問在專案之中，將由誰來稽核？這就發生「球員兼裁判」的問題，這是無法取信於人的。更何況軟體的驗證與確認，是一項產品全生命週期的活動，不只是專案層級而已。

在專案或者組織之中，做什麼事的人，就要賦予同等的角色與權責，例如，指派了某位人員撰寫專案管理計畫時，這個人就是專案經理。有些專案經理是由高階主管來兼任的，由他來寫計畫，可能是不可行的，因為，專案計畫可能永遠出不來！那麼，就不該讓那位「位高權重」的經理擔任專案經理的角色，因為如此進行，專案成功的機率是非常低的，主要原因是，那位經理根本無法掌握專案的全般狀況，經理人的職責本來就是規劃、組織、用人、指導、管制等等，如果那位經理不能投入到專案理進行前述的那些職責，他就不該是專案經理。

在專案裡，一個人做什麼事，不是因為其頭銜是什麼才去做什麼事，而是因為做了什麼事情，所以得到工作的頭銜，這樣的話，在專案當中，當你負責寫專案計畫統籌專案的所有事項時，你就是專案經理，當你又負責某個系統的需求發展時，你也是系統分析師，你負責執行測試的規劃時，你也是測試經理。

一個公司的流程可以訂得很廣泛，但是這個廣泛的流程，是要適應在很多不同型式的專案的，如果公司是什麼樣的人做什麼樣的事，那麼一個兩個星期的微型專案，可能會不敷成本的。因為你得有各種不同職類的人：專案經理、測試經理、測試工程師、品質保證工程師、專案助理、系統架構師、系統分析師、系統設計師、軟體分析師、軟體設計師............林林總總，這樣子的話，公司可能撐不了多久就掛了，因為營運成本過高。

所以在專案裡，資源的指派是看人員的「經驗」、「技能分類」及「技能水準」，而不是看頭銜指派的。要不然，就會發生有的人掛名不做事，其他的小小工程師，卻是忙到分身乏術。

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

多謝 albertchou 老師以「台北市災害應變中心資訊與通訊系統建置案」的專案文件撰寫為例，說明專案經理、系統架構師、系統工程師、軟體分析師、軟體設計師、程式設計師、品質保證經理、測試經理 ... 等角色在一個中大型資訊系統建置案的專業分工。

也感謝 tyrone 老師就一般公司或軟體組織裡的角色分工在實務面做了精闢的補充說明，並指引中小型的軟體組織或軟體專案如何彈性調適，也能夠達到「軟體工程」的要求。真是受益良多 !

看到各位這麼關心軟體的品質, 似乎是看到了一絲台灣軟體的亮光,
個人有一些小小的軟體系統的開發經驗, 但實在是有太多的疑問想請教:

台灣的軟體廠商多以萬計, 但絕大多數是以"即興"與"手工"的方式來開發及管理產出,就算是有所謂的通過ISO或一些CMMI的廠商, 充其量只是用來"綁標"或"勾引"客戶之用, 真正在專案進行時是兩條幾乎平行的線(標準製程與產出), 最近的高鐵售票系統及台彩似乎是這樣的結果.

在軟體工程中有了OO及SOA的設計理論及實做方法, 也有許多的CASE tool配合演出, 但遺憾地, 在台灣常聽到的是"原先有做後來放棄了"或"只是拿來當繪圖工具使用"或"太貴了, 用不起". 各位先進不知有沒有思考過: 為什麼? 個人認為在許多的理論與檢討中大都偏向工法的檢討, 而鮮少人(或許是個人認知不足)將工法與成本(物力/人力/時間)做合併的探討, 所以從以前至今, 各個角色產生了一堆堆在架上無用的文件, 只為應付檢查用, 顯然"軟體工法" 與 "投入成本"的相依性是一個軟體系統開發的基礎考量, 是否各位先進能不吝給予指導, 如何在上述的問題上取得一個平衡?

在台灣比例上應該很少上述的大案, 一下子找了一堆寫文件的人, 中小的案子應該是較多吧, 所以不希望是純理論性的說明, 能否多舉一些實例呢? 由小處著手, 個人希望台灣的高品質軟體也有發揚國際的一天, 感謝各位!

Frank

為了避免直接回答您的問題時，可能横生的枝節，我就單刀直入地從“什麼是軟體？”這個最基本的問題談起。

在軟體工程的書中，一開始總會說到：軟體的組成包括：演算法(程式碼)、資料與文件。只要會寫程式的人都能接受這三樣構成要素的前兩項，但是軟體工程的書對“文件”為何成為軟體的第三樣構成要素卻著墨不多。因此，很多人都不知到“文件”所以成為軟體構成要素的“所以然”。當然也就不正視其重要性，其結果就是：“開發軟體的工作”，在這些人的心中就等同於“寫程式”。是嗎？“開發軟體”就真的是等同“寫程式”嗎？

2000年8月31日天下文化出版一本書名為『數位式競爭』(譯自Secrets of Software Success)的書。該書中有句話這麼寫著：「軟體」說穿了，就是以數位形式呈現的知識。這句話很有用，也很重要。如果，我們接受這樣的看法。我們就可以進一步地演繹為：軟體開發的工作就是將原本存在於人腦或者以文字、圖形存在於書面資料中的“高度抽象化的知識”，經過一連串轉換的過程，降低它的抽象程度，直到在目標機器上能夠以數位化呈現時為止的一人或多人的心智活動。而文件就是此一過程中人類心智活動的結果，它代表著該知識(要以數位化形式呈現的知識，後文簡稱其為“目標知識”)“不同抽象程度的化身或不同面向的描述”。

目標知識的不同抽象程度的化身，就是開發活動當中產生的技術文件。如：軟體需求規格書、軟體設計說明書是也。目標知識的不同面向的描述，就是在目標機器上運用該知識的方式，如：使用者手冊、操作者手冊、維護手冊是也。

將目標知識的不同抽象程度的化身，具體以書面形式(文件)呈現出來的目的就是：“檢驗”與“溝通”。因為，可憐，只要是人都會犯錯，所以，它必須被“檢驗”以確保於轉換的過程當中沒有出差錯而“走樣”。另外，轉換的過程通常也不是一個人完成的，所以它要被書面化以便和其它人“溝通”。還有，即使它是一個人開發的，也因為這個過程不是一天就完成，又，人是健忘的，所以要將它書面化以便和未來（三十天後）的我“溝通”。

如果我們認同以上觀點的話，就會同意：軟體開發的過程不等同於“只是寫程式”。我們也會同意“寫文件的人”就是“開發軟體的人”，而不是“另外找的”寫文件的人。

有了以上的認識，現在回答您的問題如下：

小專案要轉換的目標知識的抽象程度，不會比大專案的抽象程度“低”，因此，它仍然要經過相似的轉換過程以降低它的“抽象程度”。雖然，小專案要經過與大專案類似的過程，但是，它的規模小、複雜度低，所以，小專案花在寫文件的人力、時間與成本也就小。所以，專案的規模(大小)影響的只是文件的“總頁數”，大的專案或複雜的專案要寫的文件的“總頁數”比小專案的多，如此而已。

如果，我們打算於軟體開發的過程當中維持良好有效的“溝通”，並在每一個轉換過程中進行有效地“檢驗”，以確保不會發生“走樣”的情形。那麼，“寫文件”是必要的，也是開發軟體人員每天必須執行的工作，而不是另外找人專門寫文件。還有我們也要了解，在我們“寫文件給別人看”的同時，我們也在“看別人寫的文件”。“寫文件”與“看文件”是軟體開發人員每日的工作，“寫程式”也是“寫文件”，寫給“編譯器“看的文件。軟體開發人員如果不寫文件，是無法完成其工作的。它與專案的規模、時程的長短無關，它也是客戶付錢給我們的唯一理由：把他擁有的或打算擁有的“目標知識”以不同的抽象程度(包括數位化的形式)呈現出來。

最後，我們要再了解，將目標知識由某一抽象程度轉換成較低的抽象程度，所使用的方法，會因目標知識當時所具有的抽象程度不同而不同。簡單的說就是： “將使用者需求轉換成軟體需求規格”所用的方式與“將軟體需求規格轉換成軟體設計文件”所用的方式是不同的專業技能。所以，長遠來說，把這些工作分派給不同的人員執行是較符合經濟效益的。因為，唯有專業分工才能“累積專業技能”…

到此相信您已能夠充分理解些觀點，祝您早日踏上步向成功的正途！

軟體品質協會專案管理師 周茂松 敬上

感謝周管理師在有關專案文件上深入淺出的說明,
可能是個人的原語意不清, 所以變成在文件上撰寫之必要性的討論. 個人亦認同撰寫文件是必要的, 而且是一種專業技能, 為的是在開發當時及爾後維護做為依循標準之用.
但在最現實面(或者說時間/人力成本考量), 許多的案子常因所謂成本考慮, 而將系統變更管理所必須執行的文件及作業給忽略掉了, 而且常常是依所謂PM或一些高層的經驗法則來草算, 而在後面再付出挖東牆補西牆的代價, 結果就變成爛案或草草結案. 問其原因, 大部分是"成本考量", 但成本的計算到底有無一些準則或參考點可遵循, 有那些項目, 如何估算? 因為品質與成本似乎是成正比的, 但怎麼算叫做合理, 是否能提供一些參考資料或方法論(實務上如何量化), 一般就是人月幾多錢..., 若蒙指導 甚幸, 感謝!

在不成熟的軟體開發專案組織中所謂的“成本考量”，其實是“不知真實成本”下的“無能的偷工減料”。

我說“不知真實成本”的意思是，估算成本的人根本不知道：
１. “不忽略”必須執行的文件與作業時的成本，和“刻意忽略“時目前可省下的“成本金額”；以及
２. “目前省下的”成本與“日後付出的”代價(挖東牆補西牆所支出的)之間的差異數。

我說“無能的偷工減料”的意思是，決定忽略某些文件及作業的人，可能：
１. “根本就不知道”要執行那些文件及作業；或者
２. “根本就”知道組織“没有能力”做出合格的文件及作業。

誠如您所說的，品質是有成本的。品質成本是：
１. 外部失敗成本；
２. 內部失敗成本；
３. 品質鑑定成本與
４. 品質的預防成本。

通常外部失敗成本遠大於內部失敗成本，內部失敗成本又遠大於品質鑑定成本，品質鑑定成本通常也大於品質的預防成本。在没有品質意識的組織中，通常都會刪減(或者完全不支出)品質的預防成本與品質鑑定成本，更甚者內部失敗成本也是微乎其微。因為產品做好(程式寫好)後完全不檢測，就交給客戶，讓客戶去測試。

有品質成本意識的組織就是寧可發生內部失敗成本，也要儘一切可能防止外部失敗成本的發生。遵循工程方法與進行品質管理的活動，就是想藉由適當地增加預防成本與鑑定成本來降低內部與外部失敗成本。要投入多少金錢到預防成本與鑑定成本中是取決於內部與外部的失敗成本。內部與外部的失敗成本又取決於產品本身的特性、行業的種類、目標市場的文化…等諸多因素。所以，一個組織想要知道品質成本的第一步，先要去弄清楚這些事。這些是没人可代勞的，只有靠自己腳踏實地的蒐集與累積。

另外，寫一份合格的、有用的“文件”要花費多少？是取決於寫文件的人的“個人能力成熟度”，也没有標準。

要找到這些問題的答案，個人認為只有先不計代價的執行：
１. 培養出每個員工依循國際標準做事的能力；
２. 組織依循國際標準要求員工落實執行；
３. 在這個過程中蒐集反映真實的資料。
這樣日久功深，自然就知道了。而且，看得比別人真，比別人切。

世上很多事只有做了才知道，不做就永遠不知道。

願與所有人共勉！

軟體品質協會專案管理師 周茂松 敬上

有關frankjt369所關切“文件撰寫在時間/人力成本的估算考量”，個人提供相關經驗如下：
(1)人力與時程估算隨Domain、Case Tool、Language、Requirements Quality Factor (諸如Reliability、Maintainability、…)、Source Code Reuse %、Productivity (諸如Cleanroom)…等條件因素有關，每一家公司的經驗準則皆不相同，很難有共通性，因此以下的公式既使同一家公司，都必須針對前述之條件因素修正以下之各項係數；
(2)以下引用美國政府一份指導書的一項範例供參考，此範例是統計時間總共6年，針對9個專案，Language為Ada、Platform為VAX、使用Cleanroom所獲得的計劃成本/時程估算指導文件；
(a)個人生產力估算值Productivity=5.0 DLOC per Hour (DLOC：Developed Lines of Code)
(b)程式大小（KDLOC）=(New SLOC) + (Reuse Cost Factor) x (Reused SLOC)，Reuse Cost Factor=0.3 for Ada， (SLOC：Source Lines of Code)
(c)計畫總人力Effort (以人月計) = 1.48 * (KSLOC)**0.98，1人月=157hours，
(d)計畫總人力資源配置QA：CM：Documentation：Management：Development Team=4%：5%：11%：10%：70%
(e)Development Team人力分布比例如下Design：Code：Test：Others=19%：16%：35%：30%
(f)計畫期程duration(以月計) = 4.6 * (Effort)**0.26
(g)Duration Distribution by Phase- Design：Code：Test= 35%：30%：35%
(h)文件總頁次= 34.7 * (KSLOC)**0.93
(i)維護階段成本= 0.12 * (研發成本)
(j)平均人力 (以人計)= 0.24 * (計畫總人力)**0.73
(k)錯誤分布Pie圖-Requirements：Functional Specifications：Design：Code：Previous Change=3%：9%：15%：65%
(l)Error rate=4.3 per KDLOC

假設一個計畫於RFP階段概估有150KSLOC Ada Code，其中有90KSLOC為新發展程式，60KSLOC為Reuse現有程式。(150KSLOC要依據RFP文件中的functionality以及其他諸如reliability、maintainability、safety等quality factor進行估算。)
(A):KDLOC = New SLOC + (Reuse Cost Factor x Reused SLOC)
= 90K + (0.3 x 60K)
= 108K
(B):Effort = DLOC / Productivity
=108 KDLOC / (5.0 DLOC per hour)
=21,600 hours
=138 man-months
(C):計畫總人力資源配置QA：CM：Documentation：Management：Development Team=5.5人月：7.0人月：15人月：14人月：97人月
(D):Development Team人力分布比例如下Design：Code：Test：Others=18人月：15人月：34人月：30人月
(E):計畫期程duration(以月計) = 16.6 months
(F):Duration Distribution by Phase- Design：Code：Test=5.8 calendar months：5 calendar months：5.8 calendar months
(G):文件總頁次=3666 pages
(H):平均人力 (以人計)=8.8 人

因此由以上之程序可獲得全部文件撰寫所需人力為15人月，文件總頁次約3666 pages，PM可再依據Organization Assets配當出Software Life Cycle各本文件的大約頁次，每一份文件的成本可再依據平均薪資予以概算；例如如果資料庫中依據DoD-STD-2167A發展之相似案例（意即Functionality、Reliability、Maintainability、Reliability、VCRI等需求相近似）的Software Design Document (Preliminary Design) 文件頁次為90 pages，可概估出SDD文件報價為90/3666*15人月*157 hours/人月*57USD/per hour=3,295USD(註57USD/per hour是當時個人所參加專案的單位成本合約價，該案是採用成本加獎金Cost plus Award Fee方式計價)。由以上公式大致為Design phase共計有5個日曆月，投入design人力為18人月，撰寫90頁左右的軟體架構設計文件需時57小時，平均1小時撰寫2 page，SDD成本價為3,295 USD。