請使用者也參與軟體專案, CMMI-ACQ

先前我在《Bug 數量與軟體品質控制》的回應中提到：從 PM 的角度來看，以使用者和開發者都認可的 use case 為準，必須在此 use case 的範疇下無 bug 才能交貨。不過我觀察國內的 case 好像有個現象，使用者不參與 use case 內容的，彷彿使用者跟這軟體沒關係。依據開發者單方面規劃的 use case 來撰寫 test case 。這種現象好像很正常，但我個人總覺得哪裡不對。

就讓我們這些 programmer 承認吧，我們在進行軟體專案時，口中有 user ，但心中無 user 。使用者總在有意無意之中被排除在外。其實使用者也很關心如何能評量委託他人開發的軟體是否符合需求。例如我現在服務的百貨零售業，前一陣子就為了公司的零售與進銷存系統到底有沒有達到預期目標 (事關付款問題) ，而跟廠商「飛x 高」打了場官司。

到底在軟體工程方法中，有沒有關於甲方 (使用者) 的部份呢？褐雨燕學習筆記中提到了 CMMI 的部份，規範於「CMMI-ACQ(CMMI for Acquisition Organizations」之中，雖然目前還僅僅在草案階段。

樂多舊網址: http://blog.roodo.com/rocksaying/archives/2707786.html

樂多舊回應

alexsjyin@msa.hinet.net(Alex Yin) (#comment-4164291)

Tue, 13 Mar 2007 09:44:44 +0800

正確而言並不適合將使用者與甲方畫下等號。在美國的採購程序中，通常是由使用者(例如飛行員與機工長)提出現有問題，所以在後續之需求訪談中要與使用者確認問題所在，並撰寫出Mission Needs Statement。有問題不一定會進行採購(可以經由教育訓練解決問題)，如果有足夠預算決定採購新的飛機，便由採購單位(例如國軍軍備局，就是甲方)規劃新系統需求，第一各動作就是要做Requirements Elicitation，而後完成類似RFP的Requirements Documents進行招標，承約商就是乙方。現有的軟體工程在IEEE-STD-12207的Acquisition Process就是敘述甲方(軍備局)的activity。

未留名 (#comment-4164665)

Tue, 13 Mar 2007 10:55:40 +0800

在契約書中，甲方指採購軟體需求的公司、組織，不等於 end-user ，但意義上包含 end-user。所以在我們這些軟體開發者眼中，「甲方」和使用者同義；當甲方提出需求變更時，我們總是說使用者又要改功能了... 繼續閱讀：甲方、end-user 與需求落差。

alexsj.yin@msa.hinet.net(尹守紀) (#comment-14180207)

Thu, 09 Aug 2007 10:13:51 +0800

對於你的主題『請使用者也參與軟體專案』，以下的資訊或許對你有所幫助。
1.在IPPD (Integrated Product and Process Development)methodology有組織IPT(Integrated Product Team)方式，IPT由甲方派遣技術代表與乙方的工程人員(包括Programmer、QA、CM、ILS、Test、Installation、..）等共同組成工作小組，所以使用者也等於參與專案，但IPT的使用者僅能對於合約的事項做解釋而不能對於合約做任何決定，所以對於你所提出的「使用者參與user case與test case決定」還是達不到。
2.對於政府採購模式數十年來或是國內外的案例都是甲方在SSR、SDR、PDR、CDR等審查會議中檢視並批核乙方的Product是否符合合約需求，所以如果想要甲方參與「使用者參與user case與test case決定」必須將之載入合約書中，但事實上甲方也不會接受此項要求，因為這牽涉到權責問題，官司會沒完沒了。但如果是公司自行開發產品，將企劃人員視為使用者，「使用者參與user case與test case決定」倒是可行，因為不會有官司的問題。
3.　USE CASE與TEST CASE本身屬於MODELING LANGUAGE的體系之一，對於政府採購合約必須將之轉換為NATURAL LANGUAGE的諸如REQUIREMENT SPECIFICATION、DESIGN DOCUMENT、TEST PLAN、TEST CASE (可參考IEEE文件或MIL-STD文），以個人所知UML方式的產出物尚不能納入政府採購合約的PRODUCT FORMAT。