應用CMMI 於校園單一簽入環境開發之流程改善

(1)

應用 CMMI 於校園單一簽入環境開發之流程改善

Applying CMMI to the Process Improvement for Campus Single

Sign-on Environment Development

廖岳祥 許書斌 亞洲大學資訊科學與應用學系 副教授兼系主任 微程式資訊股份有限公司 [email protected] [email protected]

摘要

學校是培養國家人材及提昇國家競爭力最重要的來源，隨著資訊科技的進步，學校也積極導入相關的新技術，應用於校內各領域，並將舊有行政流程轉換為電子化服務系統，目的便是增加行政效率，並提昇教學品質。但也因資訊技術快速進步與多樣化，各電子化服務建置時均使用不同的使用者認證系統，提供的服務數量隨著時間增加，也同時增加管理者的負擔。因此，近年來國內各大專院校積極導入「單一簽入環境」，期待藉此機制簡化管理。但由於各校建置單一簽入環境時，管理者的認知不同，也沒有一套標準的程序可依循，造成最後結果無法符合使用者實際的需求。而 CMMI 模式則可提供組織於軟體開發時遵循的參考，其中的需求發展流程領域說明於軟體開發初期，蒐集、分析使用者需求所需的程序與相關程序。本研究目的為建立一流程模型，於個案學校導入 CMMI 模式，並利用品質機能展開的方法，將使用者的需要轉換為軟體技術需求，而且為確認模型的可行性，參考 SCAMPI 評鑑方法製作問卷，以確認執行的結果。期待此模型可作為學校開發軟體及導入其它流程領域的基礎，以進一步持續改善軟體開發流程。關鍵字：CMMI、需求發展、需求工程、品質機能展開、單一簽入

一、緒論

在知識經濟時代中，優秀的創新人才是競爭力的主要來源，而學校肩負著培育人才強化國家競爭力的重責大任，除了需要有前瞻的眼光之外，更要隨時掌握時代潮流，創造符合時代趨勢的良好學習環境。在面對現今的大環境，校園 e 化已是刻不容緩的重要工作，因此教育部積極推動「教育行政、校園 e 化」，也成為各校評鑑時的參考重點。校園 e 化的建設層面非常廣泛，除了需要有完善的校園網路及資訊設備等硬體基礎建設外，也需要有易於應用的軟體環境，同時更需要兼顧人員素質的提升，唯有各方面的密切配合，才能提高行政支援的效能及效率，以提供更良好的學習及教學研究環境。學校為提供師生多樣化的學習環境，在學校 e 化過程中利用資訊科技建置許多系統服務，而跨平台各系統間的組態設定、帳號管理、系統管理與權限控管也日益複雜。提供使用者日漸繁雜的系統服務時，卻也可能增加管理者負擔及使用者的困惑。以下例舉在學校資訊化過程中，管

(2)

理者及使用者經常遇到的問題。 z 管理者方面： 1. 跨不同系統以及各應用程式之帳號管理與即時性管理問題。 2. 開發異質平台帳號管理元件需投資大量人力、時間與開發成本。 3. 系統管理與權限設定複雜，影響行政效能。 4. 為維護各系統帳號，管理者需先學習各種不同資料庫語法與原則，新進人員可能無法於短時間內熟悉。 5. 無法在不同系統資料庫中一次找尋相同關鍵性資料。 6. 面對大量新、舊生與畢業生時，無法同步管理與建立大量帳號。 z 使用者方面：各系統登入帳號、密碼不同，甚至系統網址也不同，使用者不易記憶，若使用簡易的密碼，卻可能造成安全問題。因此，如何簡化學校跨平台系統管理，建置校園單一簽入(Single Sign On)環境，提供跨系統平臺的帳號與電腦資源整合性的管理，已是最基本的建置。由於單一簽入最重要的部份即為認證伺服器，審視國內、外大專院校及 ISP 的解決方案都以 LDAP(Lightweight Directory Access Protocol)目錄存取服務作為核心技術，並有相當多的成功案例。因此，學校在建置單一簽入亦可以 LDAP Server 作為核心，再將校內所提供的各項資訊服務依序整合。而建置校園資訊入口網站 (Campus Information Portal, CIP)已成為校園主要的潮流趨勢，校園單一簽入環境將可作為建置校園資訊入口網站的基礎[15]。

二、文獻探討

面對二十一世紀的高科技環境，由於資訊科技的進步，開發的軟體也日益複雜，以分散式元件軟體為例，軟體的部分元件可能由使用者自行開發，部分則可能由其它軟體供應商提供，最後才整合為最終產品。為縮短開發時程與節省成本，並提供更良好的服務，軟體開發組織逐漸體會到，除了需有良好的軟體流程管理與維護能力之外，軟體開發流程也必須不斷地精進或改善，才能真正符合使用者的需求。目前市面上已有許多相關的成熟度模式、流程標準、方法論等，可協助軟體開發組織改善流程，但不幸的是，大部分的改善方法均只著重於特定領域，未提供完整的系統性改善模式。而能力成熟度整合模式則提供適用於軟體工程、系統工程、整合式產品開發，以及委外作業管理等跨流程領域的改善模式，並包含從軟體開發到完成，整個開發生命周期的持續改善規範，是提昇各種工程品質的基礎[5,6,7]。

2.1 能力成熟度整合模式

能力成熟度整合模式已是被廣泛應用的流程改善方法，以下將分別簡述能力成熟度整合模式的起源、表述方式、需求發展的內容與評估方法。 2.1.1 能力成熟度整合模式的起源 能力成熟度整合模式 (Capablilty

Maturity Models Integration, CMMI），最早

是由美國卡內基美隆大學 (Carnegie Mellon University, CMU)的軟體工程研究學院 (Software Engineering Institute,

SEI），在美國國防部的贊助與 Mitre公司

(3)

熟度模型(SW-CMM，Capability Maturity Model for Software)發展而來。即使這些模式已證實可改善組織流程，但若組織同時採用跨領域的多種模式時，因各模式的架構、內容及方法不同，卻可能反而付出更高的成本，甚至限制改善的效果。因此，為解決CMM的不足，SEI於1991年正式發表 CMM(Capability Maturity Model)1.0 版。即使如此，SEI仍持續專注於改善CMM 版本內容。最後於2001年發表軟體流程成熟度架構的成果「 Capability Maturity

Model Integration, CMMI」。

CMMI為一組整合現有模式的組合，並有足夠的彈性，方便組織改善流程與改善產品及服務、取得與維護的管理能力。 SEI隨後於2002年發表CMMI 1.1修正版，藉由許多軟體開發組織分享的最佳執行成果，再一次地改善與服務相關的流程內容，以滿足與服務相關的需求，並於 2006 年發表CMMI 1.2版。 2.1.2 能力成熟度整合模式的評估 目前已有許多企業、組織採用能力成熟度整合模式，或對導入能力成熟度整合模式所帶來的好處感到興趣，陸續有許多組織導入能力成熟度整合模式。而CMMI 評估需求 (Appraisal Requirements for CMMI, ARC)便提供評鑑方法開發人員、資深管理階層與一般使用者，於導入多個能力成熟度整合模式流程領域時，一組較符合需求與降低成本的評估方法[8]。 ARC標準將能力成熟度整合模式評鑑需求定義為 A、B、C三個等級各評鑑等級主要的不同在於： 1. 對評鑑結果的信心度 2. 最後產生的評比 3. 評鑑所花費的成本與時間長短其中以等級 A的評鑑結果，具有最高的信心度，但也需較高的成本與較長的時間，必需滿足所有 ARC的評鑑資格，也是目前唯一能提供評比的方式。

SCAMPI(Standard CMMI Appraisal Method for Process Improvement)是一種被廣泛應用的評鑑方法，為導入能力成熟度整合模式的組織提供評鑑時所需要的文件及相關工作的具體實施指南，可滿足 Appraisal Requirements for CMMI Class A 等級所有的需求，並強調其正確性、可重覆性與評估結果的可信度[9]。

2.2 需求工程

在軟體開發工程中，需求工程是軟體開發流程的第一個階段。良好的專案需求管理需考量：使用者利益，相關人員的需求，相關的投資，發展的優先順序，需求的合理性，以及各需求之間的關係。需求工程是一種系統化的需求制定過程，過程中以不斷地對問題進行分析、並將所獲得的結果以各種表達方式記錄成文件，同時查驗所瞭解事項是否正確，再定出相關的需求。在設計階段開始之前，必須先掌握與未來狀況有關的知識，而需求工程的重點便是在資訊的蒐集，以及各種可能解決方案的分析，找出能滿足已知未來需求的設計。為縮短軟體開發時間，需求工程是軟體開發流程中非常重要的階段。若誤解需求，將增加日後修改成本及延長軟體開發時間。Davies的研究提到，於軟體開發後期修正問題所花費的成本，為於需求工程階段時修正的兩百倍[11]。

(4)

2.3 品質機能展開

使用者的想法通常無法直接表達具體的需求，因此與供應商進行需求工程時更加困難。若誤解需求，將增加日後修改成本及延長軟體開發時間。而品質機能展開 (Quality Function Deployment, QFD)，最初是由日本的赤尾洋二與水野滋於1960年代所共同提出，最初被應用於造船廠改善造船品質。以及當時日本汽車工業快速的成長，不斷發展史無前例的車型，即使普遍認為「品質」非常重要，卻沒有實際的方法說明「如何做」；雖然也有QC的流程圖，卻得等到產品正式生產之後，才可進行評估。因此赤尾博士所提出理論，目的便是將顧客的品質需求轉換為工程特性，進而改善工程及製造，以確保完成品的設計品質。品質屋簡單分為六個階段如下所述 [12]：

1. The Whats Room：利用與使用者溝通、訪談，整理出使用者的需要(顧客的聲音)，誘導使用者提出一致性、完整且真實的需求，並與使用者確認之後列於品質屋的左方。 2. 根據與使用者溝通、訪談，以及市場研究，定義左方使用者需求的重要性，分別給予重要性權重分數。

3. The Hows Room：於品質屋上方，列出為達成左方使用者需求所需要的技術。左方每一個使用者需求，至少對應到一個以上的技術。 4. 分別定義左方使用者需求與上方所需技術的關聯重要性，並定義相關係數。例如，「9」代表強烈相關；「3」代表中度相關；「1」代表少相關；「空白」代表兩者無相關性。 5. 將「重要性權重分數」與「關聯重要性相關係數」利用矩陣演算公式運算。例如，使用者需要「A、B、C」的重要性權重分數分別為「6.5、7.0、5.5分」，與「需要的技術 b」的關聯重要性相關係數分別為「0、9、9分」，經過矩陣演算公式如下： A*b + B*b + C*b (1) 6.5*0 + 7.0*9 + 5.5*9 = 112.5 (2) 並將每項功能的矩陣演算結果，紀錄於品質屋的下方。 6. 將品質屋下方的結果加以排序，便可得知實際執行的優先順序。圖2.1 品質機能展開圖品質機能展開最常被應用於工業界，近年來也有利用此技術提升醫院服務品質的研究。除此之外，教育界也有許多學者應用QFD技術改善教育品質。將顧客的聲音反應於製造或服務上，以符合顧客對產品或服務品質的需要。

(5)

2.4 單一簽入與開發校園資訊系統

即使許多企業或組織已體認「單一簽入環境」的重要性，並實際進行建置，但至目前為止，相關的研究卻仍非常少，而且這些研究大多以企業環境為主，較少提及校園環境。儘管如此，因企業與校園環境有許多相似之處，仍可作為建置校園單一簽入環境時的參考。企業內通常存在許多資訊系統，如同校園環境般，為整合繁多複雜的系統，近年許多企業相繼建置企業入口網站(EIP)，許多學者也進行分析成功建置企業入口網站的關鍵因素，例如，使用者接受度、管理階層支持度、企業環境文化等，其中，是否能統一使用者資料，並整合異質平台與同步資料庫，也是關鍵因素之一[13]。簡毓麟的研究，說明以目錄服務 (Directory Service) 系統為基礎，透過 Meta-Directory與企業應用整合技術，評估及比較多種市面上現有套裝軟體，將企業內多種系統整合為Web單一簽入環境。雖然此研究的建置架構已加入許多良好的系統技術及安全性機制，但評估方式卻以各套裝軟體市佔率及功能比較為主，尚未加入使用者實際的想法。因此，使用套裝軟體雖然可快速建置，卻難免無法完全符合使用者需要，而各套裝軟體之間的連結，也將有其限制[4]。吳伯誠的研究中提到，於建置校園資訊系統時，導入能力成熟度整合模式相關流程領域，主要專注於流程改善，研究流程最後並製作效益評估表，作為研究結果的確認。此研究結果顯示，於建置校園資訊系統時導入能力成熟度整合模式，確實可改善開發流程。但此研究的評估方法，並未使用SCAMPI、ARC等評鑑方法，尚屬可惜[1]。蔡永泰的研究，便是說明如何於導入能力成熟度整合模式軟體需求發展領域時，利用品質機能展開的技術，將能力成熟度整合模式需求發展領域各特定執行方法對應執行品質機能展開的程序，建立客戶需求擷取流程，蒐集使用者需求，以提高軟體專案產品與使用者的期望之相符程度，間接提昇使用者對產品的滿意度。但此研究較著重於理論說明，若應用到實務導入，仍有不足之處[3]。因此，本研究將建置一套流程模型，將以使用者需求為基礎，利用品質機能展開方法，實際於個案學校導入，並參考 SCAMPI、ARC評鑑方法作確認，以彌補之前研究的不足。

三、研究方法

隨著資訊技術的進步，組織內的資訊系統也日益繁多且複雜，建置單一簽入 (Single Sign-on)環境已是近年資訊發展的趨勢。一般軟體開發組織於建置新系統時，經常會面臨兩難的情形，若選擇自行開發相關整合系統，卻沒有標準的開發程序可以依循；若選擇使用套裝軟體，卻可能無法完全符合組織需求。由於本研究作者任職公司與個案學校已有長期合作默契，可取得較可信任資訊，因此於個案學校於建置校園單一簽入環境專案時，與學校管理者共同合作，導入能力成熟度整合模式的需求發展流程領域，建置流程模型，蒐集組織管理者的需要，轉換為系統功能，最後建置符合需求的單一簽入環境。

(6)

3.1 個案說明

學校是培養國家人才最重要的地方，近年來，隨著資訊科技的進步，校園e化已是刻不容緩的重要工作。各大專院校為提升教學品質，陸續利用各種資訊技術建置學校的資訊系統，例如校務行政系統，選課系統，線上學習系統，人事差勤系統等。但無論是學校管理者自行開發，或由委託校外廠商開發，若缺乏訓練或規範，學校與一般企業均可能遇到類似的問題，如開發流程沒有標準，開發文件沒有統一、也未適當保存，開發時程也無法確定，甚至最後的產品不符實際需求。 3.1.1 個案背景 個案學校創校於民國二十九年，學校歷經幾十年的變革，為提升全校師生教學環境品質，學校的計算機與網路中心組織成員共約10人，主要業務除了學校內所有資訊相關作業，各資訊系統主機與網路硬體設備維護之外，近年來推動許多建置資訊系統專案，提供使用者Web化的系統服務，將行政流程及使用者學習方式，逐漸轉換為電子文件作業，以提高行政效率。個案學校計算機與網路中心單位及人員架構，如圖3.1所示。圖3.1 個案學校單位及人員架構 3.1.2 個案導入CMMI前之狀況 即使學校擁有經過多年執行專案的經驗，不論系統是由學校管理者自行開發，或委託校外廠商協助開發，均有成功與失敗的案例。經過學校管理者檢視各專案的執行經驗，由於每個專案需求與特性均不同，無法於專案執行時，確實掌握每個專案執行的進度與結果，學校管理者也整理目前開發資訊系統的情形如下所述： 1. 沒有標準軟體開發流程 2. 未強制規定需保留相關文件 3. 無法保證系統品質 4. 無法得知最正確的使用者資料參考上述個案的情況分析，評估目前個案軟體需求發展的能力度幾近於軟體能力成熟度整合模式的Level 0。因此，學校管理者便開始尋找可用的改善模式，期待能改善現有的流程。本研究便是於個案學校導入軟體能力成熟度整合模式，為更充分暸解學校需求，將利用品質機能展開的技術，當作誘導使用者提出需求的工具，確實滿足學校建置單一簽入環境的需求，提高資訊系統的品質與使用者滿意度。

3.2 專案說明

由於學校各系統建置時間與技術不同，在學校資訊化過程中跨平台各系統間的組態設定、帳號管理、系統管理與權限控管也愈來愈複雜，使用者資料存在於多個資料庫而無法統一建立或修改。管理人員需花費大量時間維護，影響行政效率，使用者也常因學校提供的服務繁多，不易記憶各系統的帳號、密碼，因此無法充分利用學校資源，最後反而造成使用者困擾

(7)

與資源浪費。 3.2.1 專案目標 學校目前所使用的郵件系統，使用 OpenLDAP為認證中心，已成為使用者每天持續使用的資訊系統之一。管理者有鑑於成功的資訊系統所帶來的好處，期待參考此資訊系統的建置經驗，為提供校內師生能使用瀏覽器更方便地存取校方所提供的各項服務，學校管理者計劃建置單一簽入環境(SSO)，甚至計劃未來可建置校園入口(CIP)網站。因此，期待此專案能達成下列目標： 1. 利用使用者於OpenLDAP的資料，整合現有的資訊系統。 2. 採用Web-Based技術建立跨平台帳號認證管理中心，管理者可利用瀏覽器管理與設定。 3. 建立跨平台帳號管理機制與多功能加值服務。 4. 採用符合RFC標準的LDAP認證與管理機制，使程式開發人員易於開發整合機制。 5. 簡化管理者重覆輸入各資訊系統使用者資料的人力。 6. 降低系統管理人力與技術需求，並簡化管理工作負擔，即使管理者職務調動，新的管理者也可於短時間內暸解工作內容與維護。 7. 建立標準的系統開發流程，提供日後開發人員的參考。 8. 建立系統開發流程所需的文件格式標準，並保留存檔。 9. 提高操作手冊內容的正確性，以方便日後的管理者開發與維護。 10. 相關關鍵人員可隨時確認專案進度，確保專案完成時間。 11. 提高使用者對學校資訊系統的滿意度。 12. 提高管理者建立使用者資料的正確性，減少人為疏失。 13. 簡化使用者登入資訊系統程序，提高資訊系統的使用率，避免資源浪費，進而提升教育品質。 3.2.2 專案計畫 依學校現有環境，預定整合的系統計有：郵件系統，教學務行政系統，實習系統，線上教學系統，人事差勤系統，個人網頁，無線網路認證。因此，需建置帳號管理系統，整合校園服務。為方便未來學校自行開發與整合，所建置的單一簽入整合平台，需使用RFC標準協定進行整合。此專案除建置校園單一簽入環境之外，也將於執行過程首度導入軟體能力成熟度整合模式，期待能當作日後專案執行的參考。專案計畫內容說明，如表3.1所示。表3.1 專案計畫內容計畫項目內容組織經營目標 1. 降低校園資訊系統開發成本 2. 提升教育品質預期專案效益 1. 提高行政效率 2. 減少人為疏失 3. 提高資訊系統使用率 4. 減少管理者工作負擔 5. 易於整合未來建置的系統 6. 作為日後建置校園入口網站的基礎專案規劃內容 1. 建立跨平台帳號認證管理系統 2. 自動化建立各資訊系統使用者帳號 3. 整合各資訊系統至單一認證中心 4. 自動同步使用者資料 5. 自動設定個人網頁主機空間

(8)

3.2.3 專案改善流程 執行「校園單一簽入環境」專案時，目的為整合校內多個資訊系統，需先制定一標準專案流程，建置帳號管理系統，將使用者資料匯入LDAP資料庫中，最後逐一整合校內各資訊系統。本研究預期改善流程，如圖3.2所示。圖3.2 預期改善流程依使用者需求及組織經營目標，本研究選擇演進模式(Evolutionary Model)作為專案生命週期模式，於建置校園單一簽入環境專案成立後，將專案分為數個功能子系統，並排列優先順序分段進行，直至專案結束為止。專案執行方法，如圖3.3所示 [2]。圖3.3 專案執行方法 3.2.4 專案系統架構 本研究專案採用Client/Server系統架構，Server端程式均以「C/C++, Perl」程式語言撰寫，並於系統中加入資料快取機制，以增加系統處理效率。帳號管理系統架構，如圖3.4所示。圖3.4 帳號管理系統架構圖

3.3 實作說明

本研究專案為建置校園單一簽入環境，此次建置帳號管理系統的同時，也將利用軟體能力成熟度整合模式改善開發流程。由於個案學校是初次導入，將著重於單一流程領域的改善，因此，選擇連續式表述的需求發展流程領域定義作為指標，期待能達到需求發展流程領域 Level 3的要求。 3.3.1 導入CMMI需求發展流程領域前說 明與評估 本研究專案以計算機與網中心主任為主導人，個案學校的使用者帳號業務，主要由計算機與網路中心的「校務行政組」與「網路管理組」負責，業務相關人員共九人，其中又以「網路管理組」最為重要。但管理者尚不暸解軟體能力成熟度整合模

(9)

式相關內容，因此，需先向相關人員說明軟體能力成熟度整合模式運作流程，使其充分暸解需求發展領域內容。並於實作導入軟體能力成熟度整合模式之前，利用訪談的方式，並參考陳含迷於「應用整合能力成熟度模型於醫療資訊系統開發流程改善之研究」所製作的問卷[2]，評估個案導入前的專案開發能力，也可暸解目前個案學校帳號作業與軟體開發流程常見的問題。此份問卷原為經濟部工業局軟體生產力提升計畫中所使用的軟體開發能力評估問卷，經陳含迷[2]重新整理設計，可分為四個部分，分別說明如下所述： 1. 軟體專案規劃 2. 軟體產品開發 3. 軟體品質保證 4. 軟體建構管理與資料管理可將各評核項目標準對照連續式表述模式的六個能力度等級，但因需求發展流程領域並不適用於Level 4的量化管級與 Level 5的最佳化級，因此，只分為0至3共四個分級。本研究將利用此份問卷分別於個案學校導入軟體能力成熟度模式前後，邀請帳號業務相關人員各進行一次評估。於此份問卷中將各項評核項目的評核結果，定義「Level 0」表示分數為「0」；「Level 1」表示分數為「1」；「 Level 2」表示分數為「2」；「Level 3」表示分數為「3」，最後將各個評核項目的能力度代表分數合計加總並平均。問卷對象除作者本人之外，為求評估客觀起見，特別邀請單位二級主管參與，為使評核人員暸解能力等級的分別，也於問卷中向評核人員說明能力等級內容。 3.3.2 需求發展流程領域特定目標與特定 執行方法本研究以個案學校執行的建置校園單一簽入環境專案為實作對象，為達成學校單一簽入整合環境，需建置帳號整合管理系統，提供管理者管理帳號，作為未來建置校園入口網站的基礎。於專案執行時導入需求發展流程領域，建立符合專案的流程模型。需求發展流程領域內容主要是描述客戶、產品及產品組件等三種需求，說明相關關鍵人員的需要，包含需符合軟體開發生命週期的各階段與特性有關的需要，以及符合相容於現有環境的條件。而品質機能展開是將使用者的需要轉換為產品功能需求的技術，本研究將品質機能展開的執行程序內容，配合上述軟體能力成熟度整合模型的需求發展特定執行目標，如表3.2所示。表3.2 需求發展與品質機能展開執行內容需求發展特定目標 特定執行方法 品質機能展開 執行內容 SG1 發展客戶需求 SP1.1誘導需要 SP1.2發展客戶需求與相關關鍵人員溝通、訪談，轉換為客戶需求後，列入品質屋左方「使用者需要」欄，並依訪談結果，定義重要性權重分數。 SG2 發展產品需求 SP2.1建立產品與產品組件需求分別評估每項「使用者需要」所需使用的技術，列入品質屋上方

(10)

「需要的技術」欄，並定義各項使用者需要與技術的「關聯重要性相關係數」。 SG3 分析並確認需求 SP3.3分析需求 SP3.4分析需求以取得平衡利用品質機能展開矩陣運算，確認各項產品功能開發的優先順序。 SG1 發展客戶需求特定目標包含「SP1.1、SP1.2」兩個特定執行方法，而本研究將 SG1的特定執行方法，對應前述 2.3品質機能展開技術的第一階段與第二階段。 SG2 發展產品需求特定目標包含「SP2.1、SP2.2、SP2.3」三個特定執行方法，本研究利用品質機能展開技術的第三階段與第四階段，以達成SP2.1特定執行方法的定義。 SG3 分析並確認需求特定目標包含「SP3.1、SP3.2、SP3.3、SP3.4、SP3.5」五個特定執行方法，組織可於執行SP3.3 時，利用品質機能展開技術的第五階段，將「重要性權重分數」與「關聯重要性相關係數」做矩陣運算，且將最後的運算結果，作為執行SP3.4時各項產品功能開發的優先順序。將軟體能力成熟度整合模型的需求發展與品質機能展開品質屋整合，可將各特定執行方法與品質機能展開程序的關係說明，如圖3.5所示。圖3.5 需求發展與品質機能展開對應關係 SG1 發展客戶需求於整個軟體開發流程之中，關鍵人員的需要是開發結果是否成功的關鍵。由於關鍵人員提出的需要可能被誤解或互相矛盾，而軟體能力成熟度整合模式的需求發展流程領域，便是專注於明確界定與暸解關鍵人員的需要、期望、限制及界限。需求發展流程領域的SG1特定執行目標為「發展客戶需求」，其中分為SP1.1、SP1.2 兩個特定執行方法如下所述： z SP1.1 誘導需要 SG1特定目標的SP1.1特定執行方法為「誘導需要」。本研究執行SP1.1時配合品質機能展開技術的第一階段，與相關關鍵人員溝通、訪談，轉換為客戶需求後，列入品質屋左方「使用者需要」欄。但由於個案學校的軟體開發流程並未標準化，也沒有標準的使用者需求問卷訪談流程，為使關鍵人員盡可能提出此專案的需要與期望，需經過多次反覆的討論與確認。因此，本研究利用圖3.6所示的客戶需求蒐集流程模型，以正確地蒐集客戶需求。

(11)

圖3.6 客戶需求蒐集流程參考上述客戶需求蒐集流程模型，首先利用開放性問卷與訪談，與學校系統管理者溝通，以蒐集使用者需求。本研究問卷及訪談對象為處理帳號流程相關人員，共八人，依第一次問卷與訪談的結果定義第二次問卷的項目，製作「使用者需求問卷訪談紀錄表」。 z SP1.2 發展客戶需求 SG1特定目標的SP1.2特定執行方法為「發展客戶需求」。可配合品質機能展開技術的第二階段，將各管理者的問卷結果，經過統計與分析，計算每個項目的平均值，作為品質機能展開的需求重要性權重分數。例如，各管理者對「需於穩定的平台開發」項目的問卷結果分別為「1，3， 5，7，1，3，5，7分」，利用加總與平均，最後可將平均值「4分」作為品質機能展開左方使用者需求項目「需於穩定的平台開發」的重要性權重分數。因此，為建立標準的流程模型，本研究利用圖3.7所示的SG1特定目標執行流程，重新整理製作SP1.1、SP1.2特定執行方法所需要的表單，以滿足 SP1.1、SP1.2 特定執行方法的內容。圖3.7 SG1特定目標執行流程 SG1特定執行目標流程的對應表單說明，如表3.3所示。表3.3 SG1特定執行方法流程對應表單 特定執行方法 流程對應表單 SP1.1 誘導需要使用者需求問卷訪談紀錄表 SP1.2 發展客戶需求品質機能展開方法的使用者需求重要性權重分數統計結果 SG2 發展產品需求執行SG1發展客戶需求之後，需再分析客戶的需求與操作概念，才可精準地定義詳細的產品功能，而「產品與產品組件需求」便是說明產品生命週期各階段的需要。可依據產品與產品組件需求，配置產品的各項功能及定義產品的介面，最後當作技術解決方案的基礎。需求發展流程領域的SG2特定執行目標為「發展產品需求」，其中分為 SP2.1、SP2.2、SP2.3三

(12)

個特定執行方法如下所述： z SP2.1 建立產品與產品組件需求使用者可能是以自己的方式表達需要，因此軟體開發人員於設計產品功能之前，需先轉換使用者的需求，才可以專業術語表示產品的功能需求。SG2特定目標的SP2.1特定執行方法為「建立產品與產品組件需求」，於本研究專案進行時，經過相關領域的專業軟體開發人員分析與評估暸解使用者的需要之後，軟體開發人員認為，以目前個案學校的資訊環境架構，不僅需開發「帳號管理系統」管理使用者帳號，為連結學校部分的資訊系統，還需提供由其它系統主動連結的介面，同時也需考量未來的擴充性。因此建議使用模組化的方式開發帳號管理系統，配合微軟公司的ADO(ActiveX Data Objects)運作機制，才可達成本研究專案「建置校園單一簽入環境」的目標。本研究執行SP2.1特定執行方法時，使用品質機能展開技術的第三階段，分析每項「使用者需要」所需使用的技術，並紀錄於本研究製作的「使用者需要與技術需求對應表」，將結果列入品質屋上方「需要的技術」欄。由於各使用者需要所使用的技術可能不同，甚至互相衝突或矛盾，為整體評估每種技術對各項使用者需要所造成的影響，需再利用品質機能展開技術的第四階段，定義各項使用者需要與技術的「關聯重要性相關係數」。「9」代表強烈相關；「3」代表中度相關；「1」代表少相關；「空白」代表兩者無相關性。 z SP2.2 配置產品組件需求 SG2特定目標的SP2.2特定執行方法為「配置產品組件需求」。本研究個案學校管理者所提出的需求，經過專業軟體開發人員分析所需使用的技術，可作為技術解決方案的基礎，並紀錄於個案學校既有的「產品功能設計規格表」。 z SP2.3 界定介面需求為達成使者需求所對應的產品功能，軟體內部可能需由許多組件組成，因此需定義功能或組件之間的連結介面，才可適度發揮系統所有功能。執行本研究專案時，為方便各系統管理者利用帳號管理系統以外的介面，連結或管理 LDAP 中的使用者資料，需分別開發帳號管理系統與 ADO 認證模組，並定義兩者之間輸入與輸出的運作流程，紀錄於本研究製作的「產品介面需求定義表」。本研究於執行SG2特定目標流程時，使用圖3.8所示的執行流程，並利用品質機能展開第三階段與第四階所需的「使用者需要與技術需求對應表」，與個案學校既有的「產品功能設計規格表」，重新整理製作「產品介面需求定義表」，以滿足SP2.1、 SP2.2、SP2.3特定執行方法的內容。圖3.8 SG2特定目標執行流程

(13)

SG2特定執行目標流程的對應表單說明，如表3.4所示。表3.4 SG2特定執行方法流程對應表單 特定執行方法 流程對應表單 SP2.1 建立產品與產品組件需求使用者需要與技術需求對應表 SP2.2 配置產品組件需求產品功能設計規格表 SP2.3 界定介面需求產品介面需求定義表 SG3 分析並確認需求需求發展流程領域的 SG3 分析並確認需求所定義的特定執方法，可支援「發展客戶需求」與「發展產品需求」兩個特定目標的需求發展過程，包含需求的分析，以及確認需求是否符點使用者的預期。也需分析為滿足關鍵人員的需要、期望、限制與介面，對系統整體運作的影響，並考量專案的範圍、任務需要、預算限制、市場潛力，才可決定所需的必要功能。而確認需求，則可增加產品確實符合期望的可能性。需求發展流程領域的 SG3 特定執行目標為「分析並確認需求」，其中分為 SP3.1、SP3.2、SP3.3、SP3.4、SP3.5 五個特定執行方法。 z SP3.1 建立操作概念及劇本使用者通常會依相對應的流程操作系統，因此可於開發軟體時請關鍵人員說明操作程序，當作開發時的參考。「劇本」便是使用產品時可能發生的事件順序，而產品的操作概念通常是依設計方案與劇本開發。開發人員可分析劇本再調整操作概念，進而發展細部的需求。為減輕管理者的工作負擔，減少建置帳號流程所需的時間，需先暸解個案學校未執行「校園單一簽入」專案前的流程。因此作者邀請與處理使用者資料業務相關的管理者，示範說明既有的操作流程，分析既有操作程序的不便之處，模擬利用帳號管理系統建置帳號的流程，並隨時與管理者確認其他相關單位配合的可行性，制定經過改善的操作流程，將此劇本作為開發系統與系統功能操作方法的重要參考。 z SP3.2 建立必要功能的定義需求發展流程領域 SP3.2 特定執行方法所提「功能的定義」，是說明如何使用產品的資訊。為方便管理者大批建立、刪除使用者資料，帳號管理系統需提供整批匯入的功能，但系統人員開發此功能前，需先與管理者討論儲存使用者資料所需要的欄位，並分別定義群組匯入檔與帳號匯入檔的格式，以及確認管理者確實可轉換使用者資料為此格式，才可於帳號管理系統正確建立群組架構與使用者。 z SP3.3 分析需求需求發展的 SP3.3 特定目標為「分析需求」。個案學校執行 SP3.3 分析需求時，使用品質機能展開技術的第五階段，將之前請專業技術人員分析使用者需求與所需技術的「關聯重要性相關係數」，與「需求重要性權重分數」做矩陣運算。由於本研究專案將分別建置帳號管理系統與 ADO 認證模組，因此在做矩陣運算之前，可將 ADO 認證模組中類似的規格整合為單一功能來分析，最後將運算結果紀錄於品質屋的下方。 z SP3.4分析需求以取得平衡專案通常有預算、時間與可用資源的

(14)

限制，為在使用者需要與專案的限制之間取得平衡，並使專案結果維持一定的品質，需整體考量各項需求與所需的資源。因此執行需求發展的「SP3.4 分析需求以取得平衡」時，利用品質機能展開的矩陣運算方法分析，最後將運算結果依權重分數排序，並紀錄於作者製作的「系統功能開發程序表」，作為開發帳號管理系統功能順序的參考，以降低產品的開發成本與風險。 z SP3.5 確認需求於開發軟體系統初期，可以使用多種方法分析、模擬，與關鍵人員確認開發的功能是否確實符合需求，執行需求確認，則可更加確保最終的產品達到期待的結果。因此本研究於分析需求與完成功能設計後，參考「「系統功能開發程序表」製作「功能確認表」，再次向管理者說明各項功能與限制，取得管理者的確認後，始可進行程式開發。本研究導入需求發展流程領域的SG3 特定目標時，使用如圖3.9所示的 SG3特定目標執行流程，先分析管理者的操作流程，與管理者共同制定匯入檔欄位及格式，以符合個案學校各系統的需要，並利用品質機能展開矩陣運算的結果，定義系統功能開發先後程序，最後需得到管理者的確認，便可進行開發。圖3.9 SG3特定目標執行流程 SG3 特定目標流程時的對應表單說明，如表3.5所示。表3.5 SG3特定執行方法流程對應表單 特定執行方法 流程對應表單 SP3.1 建立操作概念及劇本系統操作流程說明 SP3.2 建立必要功能的定義群組架構與使用者匯入檔範例 SP3.3 分析需求品質機能展開矩陣運算 SP3.4 分析需求以取得平衡系統功能開發程序表 SP3.5 確認需求功能需求確認表

四、研究結果與效益分析

本研究於個案學校執行「建置校園單一簽入環境」專案時導入CMMI模式，著重於改善單一流程領域的導入，因此選擇 CMMI模式的需求發展流程領域所定義相關執行目標與方法，作為制度化管理的原則，以縮短系統開發流程與成本，改善校園資訊系統的開發流程。並利用品質機能

(15)

展技術誘導、分析與確認使用者需求，參考矩陣運算結果作為開發帳號管理系統功能的順序，確實滿足使用者的需求，達成專案目標，間接地提高使用者滿意度與軟體品質。而本研究的預期目標為達到 CMMI模式需求發展流程領域至少Level 2 的要求，以下說明導入時程，並分析結果，比較導入前後的差別。

4.1 導入時程

本研究自民國九十五年九月開始進行，直至民國九十六年五月為止，為期九個月。專案實際執行時程為五個月，目標為於執行「建置校園單一簽入環境」專案流程時，利用CMMI v1.2作為流程改善的依據，並依照CMMI模式需求發展流程領域的定義，改善單一流程領域。實作導入前，先向個案學校的關鍵人員說明CMMI 模式相關內容，並做第一次落差分析，利用品質機能展開技術的問卷、訪談與分析方法確認使用者需求後，依照CMMI模式需求發展領域的定義建置帳號管理系統，與整合校內各資訊系統，以甘特圖說明執行進度，如圖4.1所示。圖4.1 專案導入時程

4.2 流程分析

本研究為建立標準化的流程模型，於執行各特定目標時，製定符合CMMI模式中各流程的表單，本章節將說明各流程分析結果。 4.2.1 評估使用者需求重要性 為蒐集使用者需求，依照第三章3.3.2 節1.1及1.2點所述，本研究利用開放性問卷與訪談方式，配合如圖3.6所示客戶需求蒐集流程，參考第一次訪談結果製作「使用者需求問卷訪談紀錄表」，作為第二次問卷的項目（A~X）。並將各項目的評核結果，定義「不重要」表示重要性權重分數為「1分」；「一般」表示重要性權重分數為「3分」；「重要」表示重要性權重分數為「5分」；「非常重要」表示重要性權重分數為「7分」。將回收的問卷結果統計分析，可計算各項使用者需求的重要性權重分數平均值，如表4.1所示。表4.1 需求重要性權重分數統計結果使用者需求 A B C D E F 平均值 6.5 7.0 5.5 5.6 5.8 3.0 使用者需求 G H I J K L 平均值 3.5 4.8 5.5 7.0 7.0 5.3 使用者需求 M N O P Q R 平均值 5.5 1.5 4.5 7.0 1.9 3.3 使用者需求 S T U V W X 平均值 7.0 7.0 7.0 7.0 7.0 3.3 4.2.2 使用者需求對應技術需求 依照第三章3.3.2節2.1點所述，專業軟

(16)

體開發人員參考表4.1使用者需求及重要性問卷，利用「使用者需要與技術需求對應表」，評估每項「使用者需要」所需使用的技術（a-w），以及對其它使用者需要的影響，定義「關聯重要性相關係數」，「9」代表強烈相關；「3」代表中度相關；「1」代表少相關；「空白」代表兩者無相關性。 4.2.3 操作流程 本研究個案學校教務處可於每學期的暑假期間，取得新生的資料，再由學校註冊組轉交給系統管理者，最後由各系統管理者分別建立各資訊系統帳號，專案完成前的帳號建立流程，如圖4.2所示。圖4.2 專案執行前的帳號建立流程本研究專案所計劃建置的帳號管理系統完成後，管理者將註冊組的人事資料轉換為帳號管理系統匯入檔格式，可直接於 Web管理介面整批匯入便可自動建立各資訊系統的使用者帳號，因此，依照第三章 3.3.2節3.1點所述，建立帳號流程可改善，如圖4.3所示。圖4.3 改善後的帳號建立流程 4.2.4 品質機能展開矩陣 軟體開發人員確認本研究專案的使用者需求與系統功能後，依照第三章3.3.2節 3.3點所述，利用品質機能展開的技術，將「需求重要性權重分數 (A-X) 」與「關聯重要性相關係數 (a-w)」做矩陣運算。品質機能展開矩陣運算的結果如表 4.2所示。其中，由於「l，m，n – u，v，w」為 ADO認證模組功能，因此可獨立類別排序。表4.2 品質機能展開分析結果功能 a b c d 運算結果 58.5 306.1 38.2 31.5 開發順序 5 1 8 9 功能 e f g h 運算結果 43.2 54.3 105.9 110.7 開發順序 7 6 4 3 功能 i j k l 運算結果 112.5 9 13.5 273.3 開發順序 2 11 10 3

(17)

功能 m n-u v w 運算結果 315.9 345.6 63.9 45.6 開發順序 2 1 4 5 利用品質展開機能矩陣運算的結果，可得知使用者需求與所需技術的重要性，因此依照第三章 3.3.2 節 3.4 點的執行結果，可排列開發帳號管理系統與ADO認證模組功能的先後程序。

4.3 效益分析

本研究於個案執行CMMI需求發展流程領域之前後，參考SCAMPI與ARC的規範，並利用「軟體開發能力評估問卷」各進行一次落差分析，評核個案學校導入 CMMI前後的能力度。結果證實利用本研究的方法，確實可達到誘導、確認使用者需求的目的，且依照品質機能展開技術的矩陣運算結果，排列系統功能的重要性，定義開發的先後順序，最後確實可滿足使用者需求。可將上述評估結果整理為效益評估表，如表4.3所示。表4.3 效益評估表項目改善 前流程 改善後流程 軟體開發流程無標準流程建立標準化的開發流程，可作為日後流程持續改善的基礎軟體開發文件無強制規定管理文件的分發、儲存、交付與文件格式，均有標準流程與格式範例，並進行版本控制軟體功能修改無標準流程需經標準流程變更功能規格，並詳細紀錄以供日後追蹤軟體開發時程無法預期或不合乎預期可預期軟體開發時程，確實於預估時間內完成，有效控制開發成本軟體功能品質無法保證符合需求系統功能開發結果，均可確實符合使用者需求系統管理者交接無標準流程軟體開發流程與文件已制度化管理，交接之後可於短時間內熟悉軟體維護流程無標準流程建立標準的維護流程，並管理維護紀錄，可供日後系統改版時的參考。經由前述的評估方法分析，確實可明顯提升個案學校的開發能力，與改善軟體開發流程。

五、結論與未來研究方向

目前一般大專院校對於 CMMI 領域相關知識仍較陌生，於開發軟體系統時，

(18)

也較缺乏標準的流程，因此經常於軟體開發生命週期花費較多的時間與成本。本研究於個案學校執行「建置校園單一簽入環境」專案時，導入 CMMI 模式的需求發展流程領域，配合品質機能展開的技術蒐集、分析使用者的需求，所建置的系統確實能達成使用者的期望。

5.1 結論

研究結果顯示，於個案學校導入本研究流程模型的結果，已達成下列成果： 1. 建置一套制度化的軟體開發流程模型，作為學校建置單一簽入整合環境的標準，也可作為日後流程改善的基礎。 2. 雖然本研究個案需求結果為建置校園單一簽入整合環境，但此流程模型將可提供學校開發其它軟體時的參考，以達到此流程模的重覆可利用性。 3. 利用本研究的流程模型，可於軟體開發初期，確認使用者需求及所需技術，避免各需求間的衝突，也可評估現有環境的限制，分析軟體功能的可行性，以節省開發軟體成本與縮短開發時間。 4. 利用本研究的流程模型，可依照使用者的需求重要性，定義軟體功能開發的程序，即使軟體因故無法如期全部完成，仍可先使用軟體部分功能，解決最重要的問題。 5. 由於已有標準化的軟體開發流程，若有人員異動，也可於短時間內接手處理，避免影響行政效率。 6. 協助個案學校管理者暸解 CMMI 模式內容，即使本研究僅改善單一流程領域，但可作為日後導入其它流程領域的基礎。

5.3 未來研究方向

本研究將持續研究CMMI模式，並整合所有資源，提供適合學校環境且更有效的流程改善模型，甚至未來執行其它非軟體類的專案時，也將參考本研究的建置經瞼，導入更多的流程領域，以改善學校的行政流程。也由於目前國內大部分的大專院校尚未深入運用CMMI模式，因此，未來的研究者可持續於國內大專院校環境討論CMMI模式的應用，進而提昇學校的形象與教學品質。

參考文獻

[1] 吳伯誠，”應用能力成熟度整合模式於校園資訊系統專案改善之研究”，中華民國品質學會第42屆年會暨第12屆全 國品質管理研討會，2006。 [2] 陳含迷，”應用整合能力成熟度模型 (CMMI)於醫療資訊系統開發流程改善之研究”，碩士論文，亞洲大學資訊 工程學系研究所，2005。 [3] 蔡永泰，”應用品質機能展開與能力成熟度整合模式於軟體需求發展”，碩士論文，亞洲大學資訊工程學系研究 所，2006。 [4] 簡毓麟，”網站系統單次簽入之企業應用整合”，交通大學電機資訊學院資訊 學程研究所，2004。

[5] CMMI Porduct Team, “Capability Maturity Model Integration (CMMI), Version 1.1: CMMI for System Engineering, Software Engineering, Integrated Product and Process Development, and Suppier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1)

(19)

Continuous Representation“, March 2002.

[6] CMMI Porduct Team, “Capability Maturity Model Integration (CMMI), Version 1.1: CMMI for System Engineering, Software Engineering, Integrated Product and Process Development, and Suppier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1) Staged Representation“, March 2002.

[7] CMMI Porduct Team, “Capability Maturity Model Integration (CMMI) for Development, Version 1.2”, August 2006.

[8] CMU/SEI, CMU/SEI-2006-TR-011, “Appraisal Requirement for CMMI”, Version 1.2 (ARC 1.2), August 2006. [9] CMU/SEI, CMU/SEI, “Standard

CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1.2: Method Definition Document”, August 2006.

[10] John J. Cristiano, Jeffrey K. Liker, and Chelsea C. White, “Key Factors in the Successful Application of Quality Function Deployment (QFD)”, IEEE Transactions on Engineering Management, vol. 48, no. 1, February 2001.

[11] Marjo Kauppinena, Matti Vartiainenb, Jyrki Kontioa, Sari Kujalaa, Reijo Sulonen, “Implementing requirements engineering processes throughout organizations: success factors and challenges”, Information and Software Technology 46, pp. 937-953, 2004. [12] Prasad Rajagopal, Roger Lee, Thomas

Ahlswede, Chia-Chu Chiang, Dale Karolak, “A New Approach for

Software Requirements Elicitation”, Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN'05), pp. 32-42, May 2005.

[13] Ulrich Remus, “Critical Success Factors of Implementing Enterprise Portals”, Proceedings of the 39th Hawaii International Conference on System Sciences, 2006.

[14] Wesley James Lloyd, Mary Beth Rosson, James D. Arthur, “Effectiveness of Elicitation Techniques in Distributed Requirements Engineering”, Proceedings of the IEEE Joint

International Conference on Requirements Engineering, 2002.

[15] Yi-Shiung Yeh, Wei-Shen Lai, Chung-Jaye Cheng, “Applying lightweight directory access protocol service on session certification authority”, Computer Networks 38, pp. 675–692, 2002.

應用CMMI 於校園單一簽入環境開發之流程改善