2 不成熟的軟體獲取過程

2.1 背景

許多海軍團隊都低估建立成熟軟體團隊及訓練成其成為精明買家所需之預算與時程。正如全球反恐戰爭，在面臨重大預算縮減時，訓練及過程改善似乎都列於清單之首。

分析顯示，DoD傾向於將系統契約判給對硬體在行的公司，但對其軟體發展(能力)卻一無所知。在CrossTalk Magazine談到陸軍的軟體獲取時，擔任未來戰鬥系統旅戰鬥小組(Future Combat Systems Brigade Combat Team)計畫經理，及軟體及分散式系統助理主任(Associate Director of Software and Distributed Systems)的Edgar Dalrymple，在答覆政府採購軟體方式變革的問題時，說道： “政府部門，至少是陸軍，需停止僅能從傳統國防發包基礎上採購軟體的作法。這些公司有著製造業公司的管理成本(overhead costs)，然而，軟體發展負擔的管理成本應該極小。絕大多數的國防承包商依然是以製造工程師或業務經理來管理。”

海軍主題事務專家(SME)在評估軟體計畫可執行性中所履行的分析，已證實了Dalrymple先生的顧慮。海軍發現，許多簽到大型契約的公司，低報適用至軟體需求工程所需之工夫量，有兩大原因。其一，他們把它當成許多個案中，易於依規格構築之硬體生產般報價。第二，針對新契約，他們以多重商源中某些不俱有構築軍事系統經驗者，編成其軟體團隊。雖然，統包投標者可能具有CMMI Level 3至5的評級，但團隊一開始就以Level 1工作。此等團隊在一開始對於其需求工程並不嚴謹，因為他們還不是一個有向心力的團隊。因此，我們在兩方面跨錯步伐。成本及時程的估算值，並沒有反映具品質之需求發展及分析，專案人員在需求階段，被迫去滿足不切實際且不可執行的計畫。這往往在系統需求審查時才承認，並表示軟體需求已處於反應/趕工的模式下。在強調實獲實管理下，他們被時程推著前進，而帶著不成熟的產品，進到需求審查中。

2.2 所見事實

往往政府部門建議書團隊缺乏過程成熟度/能力，卻又擬定建議徵求書(RFP)。而讓事情更複雜的是，調製契約文件的發包人員，對於軟體密集系統的RFP包裹(條款、條件、資料項目說明書、整合式主時程等等)的調製，既經驗不足又缺乏訓練，然後又要評估所收到的建議書。獲取者(計畫執行辦公室(Program Executive Office, PEO)及計畫辦公室)往往經費不足、無訓練、或在俱高過程成熟度供應者之高能力管理或系統/軟體工程過程的監視上缺乏經驗。獲取者並未要求客觀顯示契約進度之測量資料的交付。
(取材自Guidebook for Acquisition of Naval Software Intensive Systems)

----------------
引文: