因著前公司的政治糾葛，肥蝦不得不於10月1日轉移戰場。記得9月27日現在老闆打電話給肥蝦說：「有沒有空跟他去一趟客戶那！」本想說可以接到個新案子，疏緩一下這幾個月來的紛亂。不意去到後發現雙方正為了案子的文件與範圍鬧得不可開交，肥蝦還遭受炮火的轟擊！正所謂吵架無好話，這肥蝦是看淡了，只是這後續如何化解？如何完成專案？才是肥蝦關心的議題。

這個案子的主要爭議點之一就是要交付的文件種類與對文件品質的定義。因著客戶通過CMMI Level3的評審，對於案子文件種類與品質有一定要求；相反的，因著公司(10月1日上任了)內部進行的開發方式與文件撰寫方式，也因一定時間的累積有著自己的看法。因此就造成甲方嫌棄乙方的文件不夠Qualified，乙方認為甲方是變相增加工作範圍，引起雙方的不快，就變成了肥蝦首要面對解決的問題。

針對爭議，惟一的作法就是回到合約主體，看看原有合約到底有哪些條文是否涉及這爭議項目？盡力就合約記載去縮減雙方認知的差距！因為肥蝦不是本案的PM，因此就去請教PM與申請調閱RFP。結果發現了一條：本案專案開發應遵循CMMI相關規定。哇~~~光這一條，至少就得增加成本30%以上！因為本公司並沒採行CMMI，美其名可說我們Follow的是Agile software development，光就這文件的提供不啻要有專人負責，也要配合開發過程逐步產生才行。

因為甲方已經接受了先前第一、二階段的需求分析書、系統分析書、測試計畫書(雖然對方PM是諸多抱怨與覺得委曲，但木已成舟)，因此肥蝦首要的就是設法達成雙方對系統設計規格與程式規格文件的撰寫要項與內容。甲方PM是很有誠意設法完成專案目標(先不論對專案開發範圍的要求是否雙方都能接受！)，因此經過幾次的會商，就甲方提供的樣本進行討論與溝通，雙方作了部分的妥協，肥蝦就只好耐著性子、硬著頭皮，就程式碼回頭來寫相關文件。拼了一個月，經過三、四次的磋商，掰出了三十三份的程式規格書，以及系統設計文件，交付給甲方審查。至於第三階段，肥蝦就能本著自己的想法進行撰寫，但是光桿司令一員，也似無多大作用啦!

在軟體開發與測試流程，從需求分析、系統分析、系統設計、程式規格、程式碼，到對應的測試計畫、測試實例，有著一般普遍接受的V模型。

圖片來源：http://arithmandar.blogspot.tw/2009/08/v-model.html

另外，就物件導向開發文件，UML定義了十種圖示文件：使用案例圖(User Case Diagram)、類別圖(Class Diagram)、物件圖(Object Diagram)、順序圖(Sequence Diagram)、合作圖(Collaboration Diagram)、狀態圖(State Char Diagram)、活動圖(Activity Diagram)、套件圖(Package Diagram)、元件圖(Component Diagram)、部署圖(Deployment Diagram)。其中套件圖不是UML正式規定的圖表，而使用案例圖因為太過簡約，也多會配合使用案例文件。

以上各圖表的定義與使用，網路上與市面上均有各樣的資訊提供，肥蝦在此想要說明的是：文件、開發流程與程式間的對應，如何與實務間進行協調，達成一致性的要求，並且有助於後續系統的維護與開發。

就肥蝦所接觸的現況中，台灣除了資本雄厚、稍有制度的軟體公司(這可跟他們有沒有獲得CMMI或ISO認證無關)，一般多在確認需求分析後，程式設計師就著手Coding，開發所需的系統分析與設計等文件，因為在專案合約多未載明交付時程，都在驗收的時候在拼命補，搞得人仰馬翻，寫出來的文件也跟實際有著相當大的差距。甚者，因為每人的開發與coding習慣不一，文件寫得更是參差不齊，搞得一本多綱，連那目錄都難以統合。

就肥蝦經歷與合作過的廠商夥伴而言，基本上純外商的文件在就定義與內容上均優於本土化的外商；本土化的外商又多優於純本土廠商。若只就台灣設有分公司或公司的廠商而言，不可誨言的，I18M的確是較優的，其它有些廠商雖然也有詳細文件，但系統分析或設計文件，應該比較像是既有系統的說明書，多無法實際反應出客製化過的系統，更難以反映出系統從分析、開發到測試的過程。

在系統開發過程中，每個人對於系統文件與圖表的作法均有自己的偏好或公司的規定。肥蝦個人，習慣上喜愛使用案例圖與文件，流程圖或泳道圖(可能是因為一開始肥蝦是從程序式語言Cobol入門)，系統模組架構圖，操作畫面輸入/出示意圖，資料庫的ER圖表，模組內的程式設計文件(如果是物件化程式就改以類別圖)，並且針對每種圖形，再輔以表格說明。

由於肥蝦是非資訊本科系(後來唸了個世新資管在職碩班，還沒畢業，對不起指導教授ㄚ！)，對於【人】的角色與定位，在系統開發中非常強調，也很在意與專案成員的分工互動中，介面的界定。因此，就一個新系統的開發，個人習慣性的步驟會是：

(1)使用案例圖與表：界定使用者在系統中扮演與操作的角色與定位。

(2)流程圖或泳道圖：界定使用者的作業啟始到結束狀態，其間的系統處理過程，以及與其他使用者的互動。

(3)模組架構圖：界定系統處理過程的區塊切分，以及其間溝通的介面。

(4)用FrontPage畫個使用者介面輸入/出示意圖：確認使用者操作的輸入與輸出要求。

(5)資料庫的ER圖表：界定系統資料存放的方式與儲存的本體，以及配合系統流程的狀態轉移所要配合的儲存資訊與資料。

(6)就每個模組再進一步寫出程式設計文件：針對系統模塊負責的處理要項，明確對應資料庫的表格儲存。

(7)最後就整體系統繪製系統流程圖：界定細部的系統處理與資料轉接過程。

在遞次撰寫文件的過程中，也能不斷的發現問題，回頭審視上一層的文件，進行修正。至於程式規格，就請程式設計師在Coding的同時，根據個人的實際作法，把相關的細節增添進程式設計文件，成為程式規格書。因此肥蝦在進一步查看同仁的程式前，習慣上會要求讓我先看他(她)們寫的規格書，如果覺得可疑，再進一步去看程式碼，利用文件來QA程式碼的品質。

古諺有云：「大軍未動，糧草先行。」對應到系統的開發，至目前為止的經驗，肥蝦也深信：「程式未寫，文件先行。」經由文件逐步取得成員間的共識與反饋。使用案例圖與表，可以取得與使用者間對於系統地位與功能的共識；流程圖或泳道圖，取得開發團隊SA人員間對系統整體的共識；模組架構圖取得SA人員與各開發小組成員間的共識；使用者介面輸入/出示意圖進一步確認使用者對系統的認知；資料庫的ER圖表與程式設計文件獲得程式開發成員間coding的共識與基礎；而程式規格書就用來確認開發成員對於SA(SD)要求認知的回應與實現。

在系統開發架構中，肥蝦以為該簡單的就儘量讓它簡單，最後再就那20%較複雜的作業，思考那簡化單元的串接作法，或再進一步要求其他區塊配合。

在這一次後補程式規格文件過程中，肥蝦就深深體會到如果成員間沒有共識，沒有界定好大家可以自行發揮的範圍，先不論那程式的寫法大家差異很大，只光那DAO讀取資料庫的程式，大家就各出奇招，搞得程式規格實在非常複雜。

系統開發的文件類別，不管在教科書或實務上雖然有一定的共識，但對於每種文件的內容與細節卻是要因案、因人而異，重點在於每種文件的功用，以及誰是閱讀者。如果忽略了文件的主要閱讀對象與其資訊能力，以及他(她)們所盼望從文件中獲得的訊息重點，一份文件不管怎麼寫，一定是大家都有意見的！

以上僅是肥蝦的個人淺見，還請  各位先進多給予指導！在軟體專案的學習中，肥蝦還有很長的路要走、要學，經由您的提攜，希望能縮短一點學習的時間，並且累積更多的能量。