Transcript 下載/瀏覽
應用軟體開發之同步程度與 績效關係之研究 科技管理學刊第十卷第二期 94年6月 作者：鄭錳新、賴士葆、溫肇東 報告人：楊小嬌 壹、研究摘要 動機：雖然已經有許多學者探討同步工程 在製造業的應用，但應用於開發軟體產品 的探討並不多。 目的：探討應用軟體產品開發專案之同步 程度與績效間之關係 對象：國內的軟體公司開發應用軟體的專 案，團隊成員3 至10 人 壹、研究摘要 問卷回收率：28.8%（發出450 份問卷，回 收有效問卷107 份） 研究內容：實證的方式，探討同步程度與 專案績效之關係，以及需求穩定性、和目 標困難度是否會對上述關係產生影響 研究架構圖 研究結果 同步程度會影響資源性績效 而同步程度與資源性績效之關係，會受需 求穩定性與目標困難度的影響 所以在應用軟體的開發過程中，將開發階 段同步進行，可以縮短開發時間、節省成 本 貳、文獻探討 一、軟體與開發模式 二、同步工程與同步程度 三、需求穩定性與困難度 四、專案績效 軟體與硬體產品不同 軟體是經由開發完成的，而不是按照傳統 的製造概念製造出來的。 軟體不會用壞，但經過使用狀況或外在環 境的改變，可能會不再適用。 軟體的分類：應用軟體、系統軟體 軟體開發--瀑布模式 可透過階段間之回饋， 能儘早修正錯誤以減 少系統修改或重做之 成本 軟體開發--漸增模式 由一個最關鍵的子系統開始，一部份一部份地開 發，直到系統完整為止 軟體開發--雛型模式 先針對使用者需求較清楚的部份或資訊人員能 掌握的部份，依分析、設計與實施等步驟快速 開發雛型 雛型十生命週期模式 雛型模式與瀑布模式相互結合 軟體開發--螺旋模式 採用由內至外的螺旋狀圓圈來表示系統的演 進過程，並且加入風險分析的工作 軟體開發—同步模式 由各團隊同時進行開發，只在整合及系統測 試時合併 軟體工程的同步層次 專案階段內重疊 跨階段重疊 硬體軟體重疊 跨專案重疊 Blackburn . Hoedemaker and wassenhove ( 1996 ）探討同步軟體工程時，訪問了歐美 與日本的150 個軟體開發專案經理，各項因素 能夠縮短軟體開發時間的效果；結果顯示， 程式碼的再利用與同步開發為重要因素 同步工程 是一種整合的系統方法，從開始設計時， 就考慮到產品發展週期的所有要素，包括 考慮品質成本、排程、設備，使產品設計 與相關程序（包括製造支援）均能同步進 行 微軟的軟體開發模式 採取同步且穩定的產品開發方式 同步是指個別成員和不同的小組能同時進 行工作 穩定是指產品功能隨著專案進度逐步增加 而穩定，並不是最後才設法使產品穩定下 來 微軟的軟體開發模式 產品開發與測試平行進行 以願景說明書指導細部設計、規格會不斷改變 設定功能開發優先順序、將專案分成三到四個里程 碑 常常同步進行「日常的工作建構」、而且以「里程 碑」使產品穩定 固定的交貨日期、許多版本一起進行開發 在開發過程中，顧客持續地回饋 產品與開發過程的設計，使得大型團隊可以像小型 團隊般的工作· 同步的分類(一) 時間同步：許多不同的人員或群體同時執 行某些企業活動 資訊同步：參與成員能同時分享資訊 同步的分類(二) 專案階段同步：產品生命週期的階段中將 開發活動重疊進行 設計同步：是指設計過程中的相關活動重 疊進行，例如電子與軟體系統的設計活動 中，系統與零件的設計是同步進行的 產品同步：在新產品發展計畫中，不同的 相關產品需要協調的作法，通常是指不同 世代產品開發中的同步作業 專案的特徵 有開始與結束的日期，是暫時性的工作。 使用組織內的有限資源 具有特定的目標 產生唯一的結果 常常設有個別專案的預算 應用軟體開發之同步程度與績效關係之研 究仰 影響需求穩定的因素 規模 不確定性 相依性 ＊軟體專案因為開發時間長、使用者的需求 可能發生變化，而使得需求不穩定 影響專案困難度的層面 起源：是由哪個人或哪個部門發起這個專 案呢？不同的發起者，會有不同的需求 產品：這是指專案的產品或最終結果· 例如 是硬體專案或軟體專案 市場：專案有不同的贊助來源，例如個人 或家庭、公司、顧客、政府 規模：不同的專案規模大小，會影響其複 雜程度。 專案績效 在時間內完成 在預估的成本範圍內 達到品質的目標 合乎顧客的需求 參、研究架構與變數 衡量同步程度的方式 本研究將軟體開發活動分成下列階段：規 劃、需求分析、設計、撰寫程式、單元測 試、系統整合測試 以「同步程度」來衡量各階段與前一個階 段重疊省于的程度；故由第二至第六階段 各有同步程度 其操作性定義如下： 各階段的「同步程度」＝與前個階段重疊進 行的時間／該階段的花費時間。 衡量專案績效的問項 開發成本符合預算 完成時間符合原設定目標 畫面符合原設定的格式 作業流程符合原設定 系統反應時間符合原來的要求 使用者滿意程度 高階管理者滿意程度 專案管理者滿意程度 系統分析師滿意程度 衡量目標困難度的問項 在預算內完成類似的軟體 在預定時間內完成類似的軟體 分析與設計方式的困難度 程式語言的困難度 所使用的電腦系統的困難度 衡量需求穩定性的問項 畫面規格的需求 檔案規格的需求 硬碟容量需求 作業流程的需求 反應時間的需求 *「需求穩定性」是指專案是否會經常修改 研究假說 H1：同步程度越高，專案績效越高 以同步工程方式開發產品，可縮短產品上 市的前置時間、節省成本、提高產品品質、 提高團隊成員的滿意度 將某些階段的工作重疊進行，則等於是把 後面階段的工作提前進行，故有助於早日 達成預定的進度；亦即，可以提早完成軟 體產品的時間，故專案的績效會提高 H2：同步程度與專案績效之關係， 會受目標困難度之影響 當專案成員對所使用的軟體工具不熟悉， 則專案的「困難度」升高 專案的完成期限很迫切，更會使得專案的 困難度升高 軟體模組之間具有「相依性」，這也會使 專案的目標「困難度」升高 當專案目標困難度低時，適合較高的同步 程度，同步程度與專案績效成正向關係 H3：同步程度與專案績效之關係， 會受需求穩定性之影響 在開發軟體產品時，若使用者的需求無法 明確表達或確定時，則軟體的需求穩定性 就低，可能使得開發的時程延後，此種狀 況不適用同步程度高的做法，應等需求確 定後再繼續進行後續的階段 需求不穩定的情形下，也不適用同步程度 高的做法，因為可能系統規格重新設計， 而使得程式也需修改、甚至重新撰寫程式 H3：同步程度與專案績效之關係， 會受需求穩定性之影響 如果軟體的需求穩定性不高，則軟體的規 格經常修改、需反覆進行開發過程；此時 將開發工作重疊省于，反而會比循序方式 更慢完成開發、產品品質也更差· 所以，當 軟體的需求穩定性很低時，同步程度高不 一定有利。 肆、資料蒐集與分析結果 樣本 為了避免專案規模的差異過大而影響分析 果，由軟體協會的成員中選出有開發軟體 的公司、且成員為3 至10 人的團隊 問卷經過預測後才正式寄給受訪者 一家公司中可依照專案的數目寄出1 到3 份 問卷。 問卷回收 本研究發出450 份問卷，回收111份，扣除 4 份無效問卷，剩餘有效問卷107 份，故有 效回卷率為23.8% 回收資料分析—電腦機型 以PC 單機與網路居大多數(佔72% ) Mini電腦佔16% 大型主機佔12% 回收資料分析—軟體及語言 套裝軟體有29% 非套裝軟體則有71% 有33%的專案使用Vb語言進行系統開發 回收資料分析 大約有1 / 3 是傳統的資訊系統，使用大型 主機或Mini電腦 有1 / 5 是屬於PC 的遊戲或教學等軟體 其餘則為PC 連上網路的資訊系統開發 信度分析 目標困難度的Cronbacha a為0 . 74 需求穩定性的Cronbacha a為0 . 71 專案績效： 管理性績效的Cronbacha a 為0 . 79 功能性績效的Cronbacha a 為0 . 73 資源性績效的Cronbacha a 為0 . 82 效度分析 內容效度是衡量工具內容的適切性 由於本研究問卷之設計是彙整了國內外相 關文獻、且經由專家指導再進行預試，故 本問卷具有效度 假說檢定結果 分群與檢定結果 專案績效因素分析 同步程度與資源性績效的關係 同步程度高時，資源性績效較高 部份支持H1 假說 目標困難度對同步程度與專案績效關係 同步程度高低與資源性績效之關係，會受到 目標困難度高低的影響，部份支持H2 假說 目標困難度對同步程度與專案績效關係 當目標困難度高時，同步程度與資源性績效 的關係並不顯著；但是在困難度低時，同步 程度越高則資源性績效越高。 需求穩定性對同步程度與專案績效關係 同步程度高低與資源性績效之關係，會受到 需求穩定性的影響，部份支持H3 假說 需求穩定性對同步程度與專案績效關係 需求穩定性高時，採取高同步程度的軟體開 發方式，資源性績效較高；但是需求穩定性 低時，同步程度並不會影響專案績效 伍、結論與後續研究建議 研究結果 當同步程度越高時，資源性績效越高 同步程度與管理性績效、功能性績效的關 係不顯著 當目標困難度高時，同步程度與資源性績 效的關係並不顯著；但是在困難度低時， 同步程度越高則資源性績效 需求穩定性高時，採取高同步程度的軟體 開發方式，資源性績效較佳；需求穩定性 低時，同步程度並不會影響專案績效 後續研究建議 專案經理的領導風格、專案成員的能力與經驗 背景，可能會影響同步活動與專案績效，故值 得繼續研究 組織文化與激勵方式，可能會影響專案成員的 工作方式與專案績效，將來可以研究這些因素 的影響 軟體可以在許多不同地點開發，再將各模組連 接起來· 由於企業的經營與分工已全球化，將 來可以探討跨國的軟體產品開發方式與專案績 效之關係。