51Testing软件测试论坛

标题: [转]日式工法打造軟體專案流程 [打印本页]

作者: archonwang 时间: 2005-4-19 09:52
标题: [转]日式工法打造軟體專案流程
原贴地址：http://www.kensystem.com.tw/ken/html/report/case27.htm
无论对于日本这个民族的感情怎样，只要是好的东西，没有理由一并都拒绝。正所谓：师夷长技。

日本一向以品質嚴格出名。日本專案不僅腳踏實地，還可以秉持自己的原則、利用企業文化的方式，創造出最有效率的專案開發手法。且不管其他國家如何追隨歐美的腳步，趕著CMMI的潮流，日本依然堅持自己的品管方式，不需要CMMI背書，世界各地的客戶依然可以信任日本的產出品質，他們到底是如何做到的？

凡致力於軟體品質的工程師不難發現，維護品質最重要的因素就是成本，因為品質=成本。那麼如何有效運用成本達到最高品質管理應該就是我們必須克服的最大議題。目前我們所知有效降低成本的最好方式就是資源再利用，每一次的資源再利用應該都可以節省三成以上的成本。因此，找尋最佳專案進行方式後轉換成專案經驗並建立為企業文化則是刻不容緩的任務。

有效的資源再利用並不只是相信單單在技術方面擁有物件導向的觀念、技術就可以完全有效縮減成本，或是達到資源再利用的任務。前端系統分析的產業知識亦是真正資源再利用的精華所在。了解的專案越多我們越可以發現，專案多餘成本的分布幾乎都集中後期的翻修成本上（如圖1專案成本分布圖所示）。

圖1 專案成本分布圖

需求溝通

翻修成本的產生不外乎是發生在使用者需求變更、系統設計變更上。而一般而言，會發生變更的環節大致上是在使用流程改變、使用者與系統分析師溝通不良、系統設計師與程式設計師溝通不良等問題上。溝通除了面談、會議的面對面溝通以外還有文件上的溝通亦甚為重要，整個系統開發溝通過程與我們從小到大的教學過程很類似（如圖2系統開發溝通示意圖）。面談就好像是老師上課，交付需求結果整理文件就好像是學生交功課一樣。把面談的結果（老師上課的內容）轉換成交付文件的內容（學生交功課），但若排除技術因素，學生交的功課如果連老師都看不懂，那麼老師又該如何告知學生哪裡與他上課的內容（要求的功能）有差異呢？所以只能等到考試當天（系統測試），才發現學生的成績有夠差，答非所問，只好不停的重新上課（從技術人員的角度來看，就視為需求變更）然後要求學生不停的補考（規格變更，程式必須修改），自然就會造成專案成本的浪費。

圖2 系統開發溝通示意圖

排除專案本身無法控制的使用流程變更外，使用者與系統分析師溝通不良、系統設計師與程式設計師溝通不良等問題應該都是可以利用工具及資料庫統一管理的方式來克服。

使用者若有與系統分析師溝通不良的問題存在，應表示系統分析師使用太多的系統語言表達需求訪談的結果，而非利用使用者語言表達需求訪談的結果。原來使用者對電腦這類「高科技」產物都會存有一定的排斥感，覺得那是不同世界的東西，要他確認怎麼可能？甚至部份極端心態會認為如果自己真的「懂」的話，不就自己開發系統就好了嗎？正因為存在著先入為主的排斥感，如果我們還拿著辛苦熬夜畫出來的「系統流程圖」（圖3、5系統流程圖）而非「業務流程圖」（圖4、6業務流程圖）讓使用者確認的話，相信這份文件應該很難獲得使用者簽章的。要獲得使用著的認可，一定要先站在使用著的角度了解他們的業務流程，並將其業務流程文件化後才從中萃取電腦系統所需的資訊。千萬不可只看自己想看的部份，片面認為其他與電腦無關的流程都不重要。要累積產業知識其實也都必須清楚了解使用者端的業務流程，日後才有辦法提出系統流程改善的建議，也可以從系統分析進一步進入顧問的角色。

圖3 系統流程圖（例1）

圖4 業務流程圖（例1）

圖5 系統流程圖（例2）

圖6 業務流程圖（例2）

但若規格變更經常發生在系統設計師與程式設計師溝通不良的問題上，則必須反省系統分析階段的文件化過程是否標準化？系統分析文件內容是否詳盡？分析結果文件是否即時反應客戶需求？要具體解決這個問題，正確使用系統分析工具是唯一解決途徑。只要全公司使用整合資料庫管理系統分析結果，不僅可以達到即時掌握客戶需求的效果，更可以確保系統分析作業過程標準化，產出文件統一化。藉此可以避免各系統分析師描述習慣不同導致實際開發人員無所適從，或是無法正確掌握系統分析師語意之情況發生。加上目前轉檔技術已相當發達，很多致力於標準化的軟體公司甚至都自行開發轉檔介面（Bridge）將前端系統分析結果透過程式移轉至後端開發工具，更進一步節省重複開發人力（前端分析結果的ER Model或GUI操作介面至開發環境不須重複輸入）。
日本企業亦相當重視如何利用工具（CASE Tool）有效提升使用者與系統分析師溝通不良、系統設計師與程式設計師溝通不良的根本問題（如圖7專案工具使用所示）。

圖7 專案工具使用

案例一: JM&C公司

舉幾個日本大型企業為例，軟體專案開發工程從前端系統分析至系統完成、上線測試幾乎都有支援工具協助開發。且目前皆是利用工具資料庫的觀念將前端分析資料不停的往下一個階段拋轉，以其達到即時資料更新的目的並杜絕前後端資料不一致的根本問題。
例如：（JAPAN ENERGY CORPORATION）（如圖8）遵循TCSM（The Client Server Methodology）方法論（由JM&C公司所提倡之C/S型Business Application開發方法論）之精神，將系統分析階段的資料轉入資料庫設計工具後，再利用程式開發工具進行系統開發。而（JAPAN ENERGY CORPORATION）發揚TCSM的精神為「前端分析要仔細、後端開發要快速」並視為軟體專案開發之執行重點。

圖8（JAPAN ENERGY CORPORATION）工具應用實例

案例二: 三菱商事

三菱商事（MITSUBISHI CORPORATION）（如圖9）則是以制定公司內部系統開發標準規約之「系統開發實務基準」為目的，利用複數開發工具與套裝軟體串接使用，藉以提高開發生產力，並規定於開發層面必須遵守 DOA、Prototyping、RAD 等使用者可積極參與之系統開發方式。且因三菱商事之軟體開發工程約有80%為委外開發，因此如何將作好知識管理，將產業知識傳承於公司內部並可與外包商有良好互動，亦是三菱商事整合制定「系統開發實務基準」時之重大考量。

圖9 三菱商事（MITSUBISHI CORPORATION）工具應用實例

案例三: 東海ＮＴＴ

東海ＮＴＴ通信（NTT DATA TOKAI CORPORATION）（如圖10）為了滿足1. 克服大規模專案（細部設計結束前平均40位、最多時70位開發人員同時作業）開發、2. 因契約形態不同，業務組合已脫離既有「人、物、金」觀念，較為繁雜、3. 舊系統程式依附程式設計師之個人技術程度，新系統應排除個人屬性將品質統一化、4. 參與專案開發子公司眾多，必須統一開發手法與技術、5. 除了必須適用總公司之制度變更，並需可彈性應對大規模與緊急規格變更、6. 設計資訊一元化，隨時可取得最新規格書、7. 不被環境左右之應用系統，AS/400平台之舊系統評價相當高，新系統亦被要求相同品質之種種要求，鎖定應用前端系統分析工具管理專案開發工程，更善加利用前端系統分析工具與後端開發工具之資料拋轉功能，成功開發歷時3年、DBMS為Oracle8、使用終端機6000～7000台、橫跨4間公司之大型專案。

圖10 東海ＮＴＴ通信（NTT DATA TOKAI CORPORATION）工具應用實例

案例四: 日立情報

日立情報（Hitachi Information Systems, Ltd.）（如圖11）因與客戶溝通不良，經常發生規格確認延遲等問題。且因前端分析工程較依存人的運用，常會因設計者經驗不足而導致不可避免的循環修改成本浪費。故為解除與客戶間之溝通差異（GAP）、減少設計缺陷並降低設計矛盾點、提升知識能力並確實累積公司經驗，日立情報不僅導入前端系統分析工具，更自行開發與後端程式開發工具-VB（Visual Basic）之資料移轉介面。不僅可以將前端分析工具之GUI操作介面透過程式自動移轉至後端程式開發工具，更可以利用後端程式開發工具自動產生VB程式碼，朝自動化軟體工程更加邁出一大步。

圖11 日立情報（Hitachi Information Systems, Ltd.）工具應用實例

參考上述幾個日本大型企業之軟體專案開發手法後，我們可以得知人工開發手法已無法滿足各種大型專案之需求，過去小型專案雖不講究程序標準化，但隨著軟體專案規模逐漸擴大，軟體專案開發工程如何建立標準、文件如何規格化、產業知識如何累積都是各大企業開始注意的重要議題。相信有程序及經過標準化的工具開發手法一旦成為企業文化，即使不需要CMMI的背書，有制度的專案品質亦可以得到客戶的信賴。

作者簡介
馮文郁
學歷：日本中央大學商學部畢業
經歷：曾多次參與日本／台灣、台灣／大陸共同開發之軟體專案、92年9月取得軟體品質工程師資格認證。

[ Last edited by archonwang on 2005-4-19 at 09:54 ]

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)