Transcript 下載/瀏覽
報告者：陳亮憲 班級：碩專資管一甲 學號：NA490004 課程：南臺科大資管所碩專班 軟體工程 授課老師：陳炳文 報告出處：系統動態觀點下軟體開發專案之探討─以某資 訊軟體開發公司為例 作者：吳秀茹，中華大學碩士論文，98年8月 1 研究背景、動機與目的 軟體專案管理 結論 參考文獻 2 研究發現軟體專案開發的問題大多是管理問題，技術 問題所占的比例反而較低；有46 %的軟體專案會超出 成本與時程或沒有完全符合客戶需要，甚至有19 %的 軟體專案是完全失敗，只有35 %的軟體專案可以在受 控制的成本、時程與品質下完成。 因此以通過CMMI 評鑑的廠商為研究對象，建立軟體 開發專案之系統動態模型，預計讓未導入CMMI 廠商 利用此模型進行開發，以快速釐清影響軟體專案成敗 因素，將能降低未來實際導入時的差距。 提供專案管理者快速總觀整個流程概念，釐清各項因 素相互間的因果關係 透過此模型讓專案管理者與專案開發團隊人員，對於 軟體開發每一個階段的影響因素容易達成共識，進而 將有限資源專注投入影響深遠的因素中。 透過此模型建立符合CMMI 開發流程，期以能降低導 入CMMI 的落差與抗拒。 軟體專案管理是透過管理的方法，以降低不確定性與 風險。 將可能會影響專案時程或品質等因素，可以進行事前 預防與調整，以避免軟體專案的問題發生。 進行軟體專案管理時，從時間序列的概念分段進行是 比較容易可行的，生命週期模式正是以時間始末為基 礎所建立的模式。 以下將探討專案管理生命週期模式及軟體開發生命週 期模式。 專案管理生命週期模式有各種不同觀點來看待，可以 是概略的，也可以是非常詳細地定義；典型專案管理 生命週期模式分為初始、中期及結束等 3大階段，每 一個階段有其輸入及產出的工作項目。 路易斯(2005)自己也建立一套專案管理法，則是將專 案管理生命週期模式分為 5個階段：概念、定義、計 畫、執行、結案，且專案的特性會隨生命週期各階段 而改變，故專案規劃所投入的程度從概念、定義階段 大量投入後再逐漸減少。 Adams and Brandt(1983) 則是以專案階段所需完成 任務，來建立專案管理生 命週期模式，分為概念、 規劃、執行與結束等 4個 階段而投入程度在規劃、 執行階段達到高峰。 從以上 3種專案管理生命週期模式可知，專案通常被 分成概念成形、進行規劃、正式執行並監控進度，最 後是結案。 本研究欲探討軟體開發專案，在執行部分通常是指程 式碼開發測試，即進行軟體工程的工作。 故本研究結合以上理論，擬將專案管理生命週期模式 分為 4大階段：專案初始、專案規劃、軟體工程與專 案監控、專案結束。 軟體開發生命週期模式包括瀑布模式、雛型模式、漸 進模式、螺旋模式、演化雛型模式、同步模式等類。 其中瀑布模式(Waterfall Model)由Royce在1970年提 出，是一個發展最成熟且仍被廣泛使用的模式。 軟體開發從考量系統需求開始，然後是軟體需求的評 估，接著規劃執行方案且分析其可行性後才開始程式 設計、編碼、測試活動，最後移交產品給客戶 以V 公司的軟體開發專案，建立一個系統動態模型 從專案初始開始，然後進入專案規劃，再來是系統需 求分析、系統設計、系統開發與系統測試，最後是交 貨與驗收。 進一步利用專案管理生命週期模式，將其軟體開發專 案之流程分為四大階段：專案初始階段、專案規劃階 段、軟體工程與專案監控階段、專案結束階段。 V公司之軟體開發生命週期模式 但傳統的瀑布式軟體開發生命週期模式，是在每一項 程序結束時才審查，並將審查結果列為缺失的部份， 丟回上一層程序再修改，待重新審查確認完成後再到 下一層程序，如此一來，專案進度容易延誤，所發生 的缺失也有可能在等待過程中變得更嚴重。 結合CMMI 工程類流程領域，在每一項程序中建立多 點監控里程碑 由於每一項程序結束時已經先在里程碑時點，完成監 控與缺失矯正，因此不需像傳統的瀑布模式，等程序 結束時才審查，而缺失只能回到上一層執行修改後， 再到下一層重新執行，藉以加速軟體開發的速度。 此瀑布式軟體開發生命週期模式分為專案初始、專案 規劃、系統需求分析、系統設計、系統開發、系統測 試、交貨及驗收等 7個階段。 V 公司軟體專案流程工作表 對外主要是取得客戶需求 並將其需求以明確的功能 敘述文字，記錄成客戶需 求規格書，並促使合約簽 訂完成。 對內則召開專案起始會議， 討論客戶規格可行性並提 出專案授權單。 取得高層主管簽核的專案 授權單，則啟動本階段。 目的在於將專案相關資訊 建立書面文件並擬定專案 執行規劃書，包括界定專 案範圍與時程、估算專案 成本、取得資源(例如： 軟硬體設備與研發人力)、 制定專案成員角色、工作 分配表與里程碑監控點。 將客戶需求規格書內容轉化為系統開發規格，並由專 案管理者、專案開發團隊人員與客戶三方確認系統開 發規格能符合客戶需求。 完成需求分析後，測試人員依審查後的系統需求規格 書，發展系統測試計畫書及驗收測試計畫書。從此階 段開始，需依據專案執行規劃書所訂定里程碑日期， 由專案管理者召開里程碑監控會議，確認系統需求分 析階段可完成並進入下一個階段。最後將經過審查的 文件納管。 專案管理者依系統需求規格書，再次確認系統設計能 符合客戶需求，再次審查系統設計規格書內容的可行 性，並建立專案管理者與專案開發團隊人員共識。 在系統設計告一段落後，依據專案執行規劃書所訂定 里程碑日期，由專案管理者召開里程碑監控會議，確 認系統設計階段可完成並進入下一個階段。最後將經 過審查的文件納管。 正式進行軟體開發；專案開發團隊人員取得經過審查 的系統設計規格書，進行程式編譯。 由於軟體專案常將一個系統分散成各項模組來開發， 以提升軟體產品彈性與開發效率，故需再提出系統元 件整合測試計畫書，做為單元測試的憑據。 在系統開發告一段落後，依據專案執行規劃書所訂定 里程碑日期，由專案管理者召開里程碑監控會議，確 認系統開發階段可完成並進入下一個階段。最後將經 過審查的文件、通過單元測試的軟體程式納管。 將軟體進行整合性系統測試以評估整個產品是否可以 運作。 建立系統測試程序與環境，整合通過單元測試的軟體 程式，進行系統測試並提交系統測試報告。 完成系統測試後，依據專案執行規劃書所訂定里程碑 日期，由專案管理者召開里程碑監控會議，確認系統 測試階段正式可完成並進入下一個階段。最後將經過 審查的文件、通過系統測試的軟體程式納管。 軟體產品完成後則可進行交貨與驗收階段。專案管理 者準備交貨清單、交貨項目與軟體，交付客戶驗收。 一經客戶簽署確認驗收完成，專案管理者則需準備專 案結案報告及召開專案結案會議，檢討本次專案各項 數據，包括成本、工時與軟體缺失等，最後共同確認 結案。 會議結束後收集各項經過審查的文件、工作產品與程 式碼備份之最終版本，納管至專案知識庫，此時專案 才算正式結束。 軟體專案管理提出許多管理方法以提升軟體專案結案 率，因此建立一個全面性的軟體開發專案動態模型， 使專案管理者與開發團隊人員了解每一個階段可能發 生的因素與相互關係，提出解決方案進而降低專案失 敗率。 本研究分析已導入CMMI 流程規範的V 公司，利用系 統動態學所建構之軟體開發專案的系統動態模型，得 知相關因素影響方式，以利提早發現問題並給予適當 解決方案。另一方面可加深專案開發團隊人員整體開 發流程架構觀念，在可能影響的因素發生時即時回饋 給專案管理者，最終得以提高專案品質與結案率。 王志欽(2006)。以系統動態觀點探討應用資訊系統開發專案績效之因果關係。 未出版之碩士論文，世新大學資訊管理學研究所，台北市。 王錦泰、管孟忠(2007)。以系統動態學模式建置專案管理決策支援系統之分析。 資訊管理學術與實務研討會論文集，372-387。 李慧菁(2005)。資訊科技產業產品研發專案關鍵成功因素之研究─ AHP 方法 之應用。未出版之碩士論文，大同大學事業經營學所，台北市。 杜強國(2004)。以系統動力學探討平衡計分卡策略動態搭配原則。未出版之博 士論文，中山大學企業管理研究所，高雄市。 林信惠、黃明祥、王文良(2002)。軟體專案管理研究主題分析。資訊管理學報， 9(1)，153-193。 林信惠、黃明祥、王文良(2005)。軟體專案管理 = Software project management(再版)。台北市：智勝文化事業有限公司。 林傑毓、余孟行(2006)。物流技術特性與技術取得方式之關係─以國內物流產 業為例。運籌研究集刊，9，25-38。 林震岩(1995)。臺灣資訊管理個案第二輯。台北市：華泰文化事業股份有限公 司。 翁武安(2007)。晶圓代工廠商對記憶體事業策略風險分析與探討。未出版之碩 士論文，台灣大學商學研究所，台北市。 財團法人資訊工業策進會資訊系統實驗室(2002)。CMMI 導入指引 V1.0(初版)。 台北市：財團法人資訊工業策進會資訊系統實驗室。