最近更新: 2007-02-07

請使用者也參與軟體專案, 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。