標籤

電子報訂閱


 

免責聲明

本網站對於任何使用或引用本網站網頁資料引致之損失或損害,概不負責。本網站有權隨時刪除、暫停或編輯本網站所登載之各項資料,以維護本網站之權益。除法律有強制規定外,在任何情況下,本網站對於(1)使用或無法使用本網站之各項服務;(2)經由本網站取得訊息或進行交易;(3)第三人在本網站上之陳述或作為;以及(4)其他與本網站服務有關之事項所致生之任何直接、間接、附帶、特別、懲罰性或衍生性損害,一概不負賠償責任 。

CMMI建置實務第一篇ReqM(下)

此文章由 中華軟協 發表於 2008年11月14日 PM 14:10

作者:台灣應用軟件股份有限公司  譚泉清 顧問

  • 建立一些有關需求管理之查檢表

        為使需求之產出能夠更踏實且有品質的管理,筆者建議應該建立組織自己之需求管理方面之查檢表,筆者僅列舉有關軟體系統籌獲過程中有關使用者調查之查檢表格式供讀者參考,如表六。

 

軟體系統籌獲使用者調查查檢表


營運

1)系統易於使用嗎?

2)系統使用與維護所需之技術知識等級為何?_________________________________________

3)營運者有任何重大的抱怨嗎?

4)是否提供充分的營運者訓練與支援訓練嗎?

5)獲取者的營運人員需要多少時間才能熟悉系統?_____________________________________

 

 

 

 

 

 

可靠性

1)系統已使用多久?_____________________________________________________________

2)在這段期間,發生了多少更新、誤失矯正、及強化事項?_______________________________

3)有提供文件嗎?

4)在這段期間發生了多少個誤失?__________________________________________________

5)系統的哪些部分特別有誤生發生的傾向?___________________________________________

6)系統的哪些其他部分已不能使用,狀況已存在多久了?_________________________________

7)哪些誤失會造成系統當機?_____________________________________________________

8)在發生誤失事件時,有任何的復原程序嗎?

9)復原需要多少時間?___________________________________________________________

10)在站台上有診斷用套裝程式,可以查證系統功能是否正常嗎?

11)供應者有備援的設施可用嗎?

 

 

 

 

 

 

維護服務

1)供應者的可靠性如何?是否易於聯繫?____________________________________________

2)多久需要做一次維護服務?_____________________________________________________

3)供應者的人員是否可以勝任問題處理的工作?

4)維護服務電話到供應者回應之間的平均週轉時間為何?________________________________

5)備援程序是否充分?

6)備援需要多少時間?___________________________________________________________

7)程序上有任何的誤失傾向嗎?

 

 

 

 

 

 

績效

1)每日的交易處理量為何?_______________________________________________________

2)每日例行性處理需要多少時間?__________________________________________________

3)獲取者的檔案大小為何?_______________________________________________________

4)要使用那些檔案?_____________________________________________________________

5)有多少終端站同時進行交易處理?

 

 

 

 

6)在反應時間變慢前,有多少使用者可以上系統,以及系統惡化的嚴重程度如何?_____________

7)多重使用者造成系統惡化的問題如何解決?_________________________________________

8)獲取者的列印容量充分嗎?

9)系統是否在報表作業上使用週邊同作(spooling)?

10)在印表機在運轉時,有任何的終端站被鎖定嗎?

11)你認為的反應時間應該是如何?_________________________________________________

 

 

 

 

 

 

彈性

1)已做過哪些軟體產品的修改?____________________________________________________

2)修改由誰執行?______________________________________________________________

3)變更是在站台上執行的嗎?

4)若變更不是在站台上執行,那麼在何處執行?________________________________________

5)每一個領域的變更需要多少時間?________________________________________________

6)哪些項目已被加入全面發展的軟體中?____________________________________________

7)這些軟體是由誰加入的?_______________________________________________________

8)需要多少時間?______________________________________________________________

9)有任何介面的問題嗎?

10)系統是如何被擴充及提升的?___________________________________________________

11)轉換(conversion)是否成功?____________________________________________________

12)花費了多少時間?____________________________________________________________

13)花費了多少成本?____________________________________________________________

14)有多少人參與?_____________________________________________________________

 

 

 

 

 

 

安裝

1)系統是否依計畫安裝?

2)安裝需要多少時間?___________________________________________________________

3)安裝需要多少成本?___________________________________________________________

4)供應者的安裝訓練是否足夠?

5)供應者的安裝支援是否適當且完整?

6)系統是否平順地停止結束?

7)是什麼異常事項破壞了安裝作業?________________________________________________

8)系統安裝需要哪些環境上的變更?________________________________________________

 

 

 

 

 

 

成本

1)在安裝與訓練期間,是否有未預期的費用發生?______________________________________

2)在安裝與訓練後,是否有未預期的費用發生?________________________________________

3)獲取者的服務協議是否合乎成本效益?

4)哪些新產品強化的成本是由供應者吸收?___________________________________________

5)更新或矯正軟體發生的費用為何?________________________________________________

6)軟體客製化工作的成本為何?____________________________________________________

7)軟體客製化工作是否包括文件更新?

8)你覺得系統在哪些領域最具成本效益?____________________________________________

9)你覺得系統在哪些領域最不符合成本效益?_________________________________________

 

 

 

 

 

 

資訊安全

1)使用者與檔案的資訊安全等級是否足夠?

2)未獲授權的交易處理或程式可以執行嗎?

3)會計稽核管制是否令人滿意?

4)會計稽核管制是否滿足獲取者的會計師?

 

 

 

 

 

 

文件

1)文件是否準確?

2)文件是否充分?

3)文件是否保持最新?

 

 

 

 

 

 

雜項

1)為什麼要採購該系統?_________________________________________________________

2)如果你現在在市場上,你會購入該系統嗎?

3)你會做什麼樣的變更?_________________________________________________________

4)你認為實作什麼樣的變更比較實際?______________________________________________

5)你從系統的其他使用者處學到了什麼?____________________________________________

表六 軟體系統籌獲過程中有關使用者調查之查檢表範例

 

  • 與需求管理有關之其他成熟度模式

        與軟體籌獲成熟度模式( Software Acquisition Capability Maturity Model,簡稱SA-CMM ),SA-CMM是有關組織取得或採購軟體相關系統之成熟度模式,用以評估與改善軟體籌獲流程。

 

結論

        拉拉雜雜項讀者報告了一些有關需求管理之建置經驗,綜合上述所列之簡要介紹,筆者僅將我認為有關需求管理之成功要點,整理如下,供讀者參考,希望對讀者有所助益。

 

  • 一定要有統一的需求接受及上線處理單位。
  • 內部應先規劃與排定上線的相關程序。
  • 正式的向客戶解釋說明上線的規劃,及其可以帶來更好的軟體及長期而言更好的服務品質。
  • 主動與客戶預先排定未來的需求,讓客戶覺得我們很有制度的在進行這件事。
  • 可以由一個較大的event作為開始
  • 如一個較大的需求,同一時期的需求可以安排一起上線。
  • 與需求管理搭配的作業,如測試驗證及版本控管等工作一定要作好,不要讓客戶失去信心。
  • 設置緊急處理管道,緊急需求及錯誤可在控制下緊急處理。
  • 於專案進行各階段均應收集可供改進之資訊。
  • 在需求管理的有效投入,可以有效降低在開發過程中變更的風險。
  • 小心而有策略的處理客戶需求,是專案成功的基礎,開始時不把需求弄清楚,問題只會更大。
  • 客戶的信賴取決於資訊人員在客戶端的專業形象,而專案的成敗往往取決於客戶的信賴感。
  • 實施好的軟體工程流程,引導客戶把眼光放遠,急於解眼前問題,往往帶來更大的問題。
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Be the first to rate this post

分類: 軟體產業通訊

標籤: ,

轉寄文章 | 永久連結 | Comments (0) | 評論 RSSRSS comment feed | 點閱次數:218

Related posts



Comments are closed