符合CMMI需求管理流程領域之多媒體教材內容製作品質管制系統

國

立

交

通

大

學

資訊學院 資訊學程

碩

士

論

文

符合 CMMI 需求管理流程領域之多媒體教材

內容製作品質管制系統

A Quality Control System for Multimedia Content Creation Based on

Requirement Management Process Area of CMMI

研究生：張錦成

指導教授：陳登吉 教授

符合 CMMI 需求管理流程領域之多媒體教材內容製作品質管制系統

A Quality Control System of Multimedia Content Creation Based on

Requirement Management Process Area of CMMI

研 究 生：張錦成 Student：Chin-Cheng Chang

指導教授：陳登吉 Advisor：Deng-Jyi Chen

國 立 交 通 大 學

資訊學院 資訊學程

碩 士 論 文

A Thesis

Submitted to College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master of Science

in

Computer Science June 2009

Hsinchu, Taiwan, Republic of China

符合 CMMI 需求管理流程領域之多媒體教材

內容製作品質管制系統

學生：張錦成 指導教授：陳登吉 博士

國立交通大學 資訊學院 資訊學程碩士班

摘 要

多媒體教材兼具”教學內容”與”軟體”雙重專業領域的特質，因此多媒體教材除了要 符合 SCORM 的格式外，還需符合軟體工程的理論基礎及品質保證的國際規範。如何運 用低成本與高效率的方式來產生高品質的產品，是多媒體教材製作重要的一環。 基於軟體工程中的「需求管理」概念，本研究採用 CMMI 優越的流程管理手法，設 計並實作出符合 CMMI 需求管理流程領域能力度第二級(已管理階段)規範的多媒體教 材品質管制系統(MLCs Quality Control System， MQCS)。本系統針對多媒體教材製作 流程及教材內容，包含章節結構、單元腳本、場景、素材、劇情等進行審查及管理。對 於教材需求規格、設計內容、素材、教材製作及互動劇情等文件，MQCS 也提供了良好 的管理及自動產生機制。此外，對於多媒體教材在製作過程中發生與原始需求規格不一 致的情形，MQCS 亦提供了不一致性偵測與自動矯正的功能，以確保製作出來的產品能 符合原始教材的需求與規格。 最後，以一個實例導入來顯示 MQCS 的可行性及適用性。本研究所提出的概念， 結果證明透過適當的流程管制方式，對多媒體教材的製作過程進行控管，對提升產出產 品的品質確實具有正面的助益。 關鍵字：能力成熟度整合模式、需求管理、流程管理、多媒體教材、數位學習

A Quality Control System of Multimedia Content Creation Based on

Requirement Management Process Area of CMMI

Student：Chin-Cheng Chang

Advisor：Dr. Deng-Jyi Chen

Degree Program of Computer Science

National Chiao Tung University

Abstract

The Multimedia courseware with the constituents of Content and Software are obligated not only to fulfill SCORM standard, but fundamental theory of Software Engineering as well as International standards of quality assurance. Along with high-quality requirement, creating low-cost and high-efficiency products are the major topics for long in the field of Multimedia Learning Content Creation.

This research is to establish a MLCs Quality Control System on the basis of Requirement Management in Software Engineering and flow management of CMMI Capability Level 2 (Managed). The system could review and manage the Multimedia learning process flow and content in terms of structure, scenatio, UI, source material and script per initial requirements. Moreover, the documents such as requirement, design content, source material, creation of learning content and Interactive script could been managed and generated automatically. Any inconsistency between initial requirements and output content in the creation process would also be detected and corrected by MQCS which ensures the outputproducts meeting the initial requirement and specification.

At last, a practical case was demonstrated for the feasibility and the adaptability of the MQCS.The result showed that the MQCS provides an effective method to have the creation process of multimedia learning content under control and hence, raising the quality of output products.

Keywords: Capability Maturity Model Integrated (CMMI), Requirement Management,

誌 謝

本篇論文的完成，首先要感謝指導教授陳登吉博士對學生的指導。無

論是課堂上的教學、研究的方法、論文的研討及未來的學習方向，無不悉

心教誨，使學生獲益良多，師恩浩蕩，永誌難忘。

此外還要感謝孔崇旭教授於百忙之中對學生所製作的系統給予很多實

務應用上的指正與教導，並對論文內容，字斟句酌，使得本論文更加周延。

同時還要感謝口試委員，提供很多寶貴的意見，讓此篇論文內容更臻於完

備，在此謹致上最高的敬意與謝意。

兩年的研究生涯中，感謝資訊學院師長們的教誨及同窗好友在課業與

生活上的勉勵。研究室瑞彬學長，同窗好友詩雯、信江、仲智，這兩年來

在課業上的相互勉勵及照顧、在系統製作上的合作無間，使得本系統及論

文能順利完成，感謝你們。

最後，要特別感謝我摯愛的家人，由於你們的支持、鼓勵與體諒，我

才能順利的完成學業，願以這份榮耀與喜悅與你們共享。

張錦成 謹誌於

國立交通大學軟體工程研究室

中華民國九十八年六月

目

錄

中文提要

………

i

英文提要

……… ii

誌謝

……… iii

目錄

……… iv

表目錄

……… vi

圖目錄

……… vii

一、

緒論 ……… 1

1.1

研究背景與動機 ……… 1

1.2

研究目的 ……… 1

1.3

研究架構 ……… 2

1.4

研究範圍 ……… 3

1.5

章節概要 ……… 4

二、

文獻探討 ……… 5

2.1

SCORM ……… 5

2.1.1 Content Aggregation Model ………

6

2.1.2 Run-Time Environment ……… 9

2.2

軟體品質 ……… 10

2.3

CMMI ……… 12

2.3.1 CMMI 歷史沿革 ……… 13

2.3.2 表述模式 ……… 14

2.3.3 成熟度等級與能力度等級 ……… 15

2.3.4 流程領域 ……… 17

2.3.5 需求管理流程領域 ……… 19

2.3.6 預期效益 ……… 22

三、

多媒體教材管理系統分析與流程設計 ……… 23

3.1

CMMI 需求管理流程領域分析 ……… 23

3.2

功能性需求與非功能性需求 ……… 26

3.3

多媒體教材製作生命週期 ……… 28

3.4

MQCS 系統流程 ……… 31

四、

系統製作與導入 ……… 35

4.1

系統平台與開發工具 ……… 35

4.2

MQCS 系統架構 ……… 36

4.3

系統製作 ……… 37

五、

實例應用與分析 ……… 46

5.1

課程導入期(RD) ……… 46

5.2

課程規劃期/單元腳本設計(DM) ……… 49

5.3

課程規劃期/場景 UI 設計(UI) ……… 51

5.4

課程製作期/素材製作(MM) ……… 52

5.5

課程製作期/教材製作(CM) ……… 53

5.6

需求審查 ……… 57

5.7

需求變更 ……… 58

5.8

MQCS 系統導入成效 ……… 60

六、

結論與未來研究方向 ……… 61

6.1

結論 ……… 61

6.2

未來研究方向 ……… 62

參考文獻

……… 63

附錄一

……… 65

附錄二

……… 78

表目錄

表 1 階段式與連續式表述之間的差異……… 15 表 2 能力度與成熟度比較表……… 17 表 3 需求管理流程領域的特定目標及特定執行方法……… 19 表 4 MQCS 系統功能性需求表……… 27 表 5 MQCS 系統非功能性需求表……… 28 表 6 多媒體教材正向相依矩陣……… 40 表 7 編輯手軟體場景參數表……… 41 表 8 編輯手軟體演員素材參數表……… 41 表 9 多媒體教材開發生命週期各階段之 QA 表……… 43 表 10 多媒體教材反向相依矩陣……… 45

圖目錄

圖 1 研究架構圖……… 3

圖 2 ADL 的初始願景 ……… 5

圖 3 Assets 集合樣本 ……… 6

圖 4 Sharable Content Object 概念圖 ……… 7

圖 5 Content Organization ……… 8 圖 6 Content Packaging 概念圖 ……… 9 圖 7 RTE 架構圖 ……… 9 圖 8 數位教材品質檢核五大面向 ……… 12 圖 9 能力成熟度模式家族的歷史 ……… 13 圖 10 連續式與階段式表述的結構 ……… 14 圖 11 能力成熟度整合模式的組件 ……… 18 圖 12 需求管理流程領域主要程序圖 ……… 20 圖 13 需求管理與變更追溯管理程序的流程圖 ……… 21 圖 14 需求管理流程領域環境圖 ……… 25

圖 15 需求管理 4 大模組 Use Case Model 圖 ……… 26

圖 16 多媒體教材開發生命週期流程圖 ……… 31 圖 17 MQCS 系統流程圖 ……… 32 圖 18 MQCS 系統需求變更流程圖 ……… 34 圖 19 MQCS 系統環境架構圖 ……… 35 圖 20 MQCS 系統功能架構圖 ……… 36 圖 21 SCORM 教材架構圖 ……… 37 圖 22 需求狀態碼及流程圖 ……… 38 圖 23 劇情、場景、演員相依性關係圖 ……… 39 圖 24 需求變更相依性關係圖 ……… 44 圖 25 多媒體教材原始電子檔 ……… 46 圖 26 分析原始多媒體教材章節內容……… 47 圖 27 MQCS 教材章節架構建立 ……… 47 圖 28 MQCS 章節資料送審 ……… 48 圖 29 MQCS 章節資料審查 ……… 48 圖 30 MQCS 需求指派 ……… 49

圖 31 MQCS 單元腳本設定畫面……… 49 圖 32 原始教案分鏡內容……… 50 圖 33 MQCS 劇情、演員設定畫面 ……… 50 圖 34 MQCS SCO 審查通過畫面 ……… 51 圖 35 MQCS 場景 UI 設定畫面 ……… 51 圖 36 MQCS 場景 UI 需求追溯畫面 ……… 52 圖 37 MQCS 演員素材設定畫面 ……… 53 圖 38 MQCS 場景 UI 參數設定畫面 ……… 54 圖 39 MQCS 開、退場演出方式設定畫面 ……… 54 圖 40 MQCS 演員參數設定畫面 ……… 55 圖 41 MQCS 互動劇情演員參數設定畫面 ……… 56 圖 42 MQCS 教材製作與上傳畫面 ……… 57 圖 43 MQCS 需求審查畫面一 ……… 57 圖 44 MQCS 需求審查畫面二 ……… 58 圖 45 MQCS 需求變更畫面 ……… 59 圖 46 MQCS 需求變更審查畫面 ……… 59

一、 緒論

1.1 研究背景與動機

科技領導生活，網際網路就是現代科技最偉大的發明之ㄧ。近年來由於網際網路的 高度發展，人們的生活、工作、娛樂與資訊傳遞的方式已大為改變。在學習方面，網路科 技也大幅改變了傳統的學習型態，由於學習環境、學習方法、學習工具與網路科技的進步， 新的學習形式與內涵不斷地被提出，而與網際網路高度整合的數位化多媒體教材的設計與 使用也越來越普及。如何運用低成本與高效率的方式來產生具有高品質的多媒體教材，已 成了當前的一項重要的課題。早期各個組織與單位所建立的網路多媒體教材，因沒有一致 的標準與規範，缺乏互通性，使得教材內容無法分享、整合，不僅管理不易，也造成了教 學資源的浪費。為了有效解決教材重複利用性低、無法在不同教學平台上交換的問題，對 於多媒體教材的使用、分享、管理及整合，國內外相關組織提出了許多教材的標準，其中 由美國國防部的研究機構 ADL(Advanced Distributed Learning Initiatice)所制定的 SCORM (Sharable Content Object Reference Model)標準最受到重視。SCORM 的主要目的，是提供 一個標準的溝通方式，讓各個學習資源可以在不同的學習管理系統(Learning Management System，LMS)上重複使用，節省教材開發時間，提高教材的可移植性。 SCORM 雖然提供了一套數位教材製作的標準，讓教材可以在不同教學平台之間流 通、呈現及重組，但基本上 SCORM 只實現了教材內容規格的一致化，對於教材的品質， 卻沒有一套明確的規範。亦即依據 SCORM 的規範所製作出來的數位教材並無法保證能製 作出高品質的多媒體教材。由於多媒體教材兼具”教學”與”軟體”雙重專業領域的特質，因 此要開發高品質的多媒體教材除了要符合 SCORM 的標準之外，還要能符合軟體工程領域 的理論基礎及品質保證的國際規範。因此本研究將以軟體工程中的「需求管理」為基礎， 整合 CMMI 的規範，提出一套多媒體教材開發的品質管制手法，來確保能製作出符合 CMMI 規範的高品質多媒體教材。

1.2 研究目的

在軟體開發的過程中，需求管理(Requirement Management)是極為重要的一環，不僅 影響到軟體產品的開發時程、管理成本，更會影響到軟體產品的品質。所以在軟體工程、 系統工程及產品工程中，需求管理一直是被高度重視的一個議題。而在國際上也有許多相 關的標準，例如：IEEE 12207、ISO/IEC 12207、MIL-STD-490、CMMI…等。其中又以美

國 卡 內 基 美 隆 大 學 的 軟 體 工 程 學 會 (Carnegie Mellon University Software Engineering Institute ， CMU/SEI) 所 提 出 的 「 能 力 成 熟 度 整 合 模 式 」 (Capability Maturity Model Integration，CMMI)中的需求管理流程領域整合了大部分的標準。

本研究的主要目的在提出一套以需求管理為基礎的多媒體教材開發品質管制方法，設 計並實作出符合 CMMI 規範的多媒體教材品質管制系統(MLCs Quality Control System， MQCS)。其主要目的分為三部份：

一、符合 CMMI 軟體品質規範

依據 CMMI 需求管理流程領域(Requirement Management Process Area)所規範的特定 目標(Specific Goal)與特定執行方法(Specific Practice，SP)為主要依據，設計多媒體教材開 發流程品質管制系統，讓教材開發者有一定的規範可以遵循，以確保能製作出高品質的數 位多媒體教材。 二、建立製作流程品質管制機制 主要根據多媒體教材開發生命週期的每一階段，在製作過程中透過流程管理與審查的 方式，驗證每個階段的半成品是否符合系統的需求規格。藉此方法來確保產品的正確性， 提高多媒體教材的品質。 三、與多媒體教材編輯軟體整合 傳統作法上，多媒體教材設計人員會依據需求規格文件及多媒體教材的分鏡腳本內 容，在多媒體開發軟體(例如編輯手、Flash…)中進行設計，這種方式容易因為開發人員的 專業能力與需求認知的差異，造成開發出來的多媒體教材產品無法完全符合原始規格的需 求。本系統提供分鏡腳本、劇情、演員等相關參數設定的介面，透過 XML 格式可將這些 設定好的參數匯入多媒體開發軟體中，以確保在多媒體開發軟體所設計出來的教材內容符 合原始需求規範，降低開發人員因專業能力及認知差異影響到多媒體教材產品品質的因 素。

1.3 研究架構

本研究架構如圖 1 所示，透過文件探討，分析出多媒體教材 SCORM 的相關規範， 並以一個 SCO (Sharable Content Object)為需求管理的單位，整合 CMMI 需求管理流程領

理論基礎，設計並實作一套在網路平台執行的多媒體教材開發品質管制系統(MQCS)。並 以一個多媒體教材開發的實例應用，來展示系統的成效，驗證 MQCS 的可行性與適用性。

圖 1：研究架構圖

1.4 研究範圍

本論文的研究範圍專注在如何導入並實作 CMMI 標準中的需求管理流程領域的特定 目標及其執行方法，來管控多媒體教材製作的品質，通過 CMMI 評鑑不在本論文研究範 圍。 CMMI 中可以使用階段式表述以及連續式表述兩種方式。階段式表述適用於具規模 的、完整的組織，並不適用於本研究。連續式表述模式可彈性選用所要改善的流程領域數 量及範圍，故本研究採用連續式表述模式，並選擇導入需求管理流程領域(附錄二)，以達 到符合能力度等級二(管理級)為目標。

1.5 章節概要

本論文共分六個章節，其內容簡述如下： 第一章「緒論」，說明本論文研究機動的描述與希望達成之研究目的，並對論文章節做 簡單的介紹。 第二章「文獻探討」，探討與本研究相關的背景知識與文獻，如 SCORM、軟體品質、 CMMI 的規範架構與標準。 第三章「系統分析與流程設計」，說明依據CMMI規範為基礎，分析需求、流程及設計 多媒體教材品質管制（MQCS）系統。 第四章「系統製作與導入」，依據第三章所分析出來的需求與流程，提出系統的架構並 作細部的功能設計。規劃在網路環境下，以Server-Client 主從架構開發多媒體教材 開發流程品質管制本系統。 第五章「實例應用與分析」，在本章節中以MQCS系統來管控一個實際的多媒體教材案 例，展示MQCS之可行性及適用性。 第六章「結論與未來研究方向」，說明本研究的結論，並對未來研究方向提出建議。

二、文獻探討

2.1 SCORM

SCORM 是由美國政府與國防部共同推動 ADL 先導計畫（Advanced Distributed Learning Initiative ） 所 提 出 ， 集 合 教 材 開 發 廠 商 、 使 用 者 與 IMS （ Global Learning Consortium）、AICC（Aviation Industry CBT Committee）、IEEE 等標準化的推動單位， 共同彙整美國各界過去在教材標準上的努力成果，進而研訂出一套相互關連的技術規範， 希望能透過建立一套可共享、可重複使用、可移植的教材開發機制，來縮短教材開發時程、 降低開發成本、讓所有的線上教材都能夠在不同的學習平台及學習裝置上流通自如。其主 要目的則在確保學習者無論在何時何地，都能及時獲得所需的高品質訓練或學習資源。圖 2 顯示出 ADL 的初始願景，在於達成教材可互通取得，並重新依需求組合成另一門教 材，以對任何時間、任何地點的學習有所幫助。 圖2：ADL的初始願景

SCORM 的幾個主要的精神為： 1. Accessibility：易存取性，可以從不同的地方取得教學元件。 2. Adaptability：適應性，可以依據學習者的學習情況，適時地調整學習內容。 3. Affordability：可負擔性，增加效益及產出，減少教材開發的時間與成本。 4. Durability：耐久性，可以禁得起技術的革新，不需重新花費、設計及製作。 5. Interoperability：可流通性，教學元件要能在任何的開發系統與教學平台上使用。 6. Reusability：重複使用性，依不同的應用或教學情境，可以彈性合併教學元件。

SCORM所訂定規格主要包含了內容聚合模型（Content Aggregation Model，CAM）與執行 環境（Run-Time Environment，RTE）等兩部份，皆有許多發展成熟的規格。

2.1.1 Content Aggregation Model

內容聚合模型(CAM)規定了如何描述與定義一個學習主題（Learning Content）並且敘 述了如何使這個課程成為一個可以共享學習資源，能在不同的學習管理平台與各種的學習 資源庫中流通共享[1][2]。SCORM CAM 包含三方面：Content Model、Metadata 以及 Content Packaging。 1. Content Model 定義了SCORM學習元件的內容模型，呈現教學內容的結構與關係，主要包含了以下三種 學習物件：Asset、SCO、Content Organization。 (1) Asset：學習物件最基本的單元，中文稱做教學素材，是以電子檔案的型態呈現，如 影音、文字、聲音等網路上常見的媒體格式，都是可以被 Asset 所認可的集合，如 圖3。 圖3：Assets 集合樣本 (Source：ADL, 2004)

(2) Sharable Content Object (SCO)： SCO是一個學習管理平台在執行環境（Run-Time Environment，RTE）所能追蹤到的基本學習元件，也是在學習管理平台之間所傳遞 的教學資源的最小單位，圖4 為一個SCO概念圖。一個 SCO 在教學設計上必須具 備獨立性，因此在教學設計時，需根據課程需要重新組裝各個 SCO ，才不會發生 內容相似的學習資源重複出現於課程當中，所以SCO是教學應用的最小學習資源， 且此學習資源可以有效地再利用[3][4][5]。

圖4：Sharable Content Object概念圖 (Source：ADL, 2004)

(3) Content Organization ：定義如何封裝與組合數個學習元件成為一個課程結構，以呈 現教學活動的行為，是一個教材內容的結構，包含了數個SCO或Asset，成為有意義 的學習單元。內容組織 （Content Organization）將教材內容以巢狀的階層性結構來 顯示預期使用的教材及一個活動與其他活動之間的相關性，如圖5 所示。 Content Organization 是由 Asset 或SCOs 組成項目（Item），每個 Item代表一個學習活動 ，可能是一個課程、一個模組、或一堂課等。因為Content Organization 是提供教學 設計者能夠開發一套教學內容並將教學素材或教材安排在合適的教學項目當中。這 樣的教學內容亦可視為一個教材，來提供其他的教學內容開發時，作為教學進行的 一個教材。因此不單單賦予教學涵義的素材集合可以稱為教材，且導入教學設計者 的經驗所開發的教學內容亦可稱之，這樣的架構，讓SCORM 在教學設計上針對教 材與教學內容具有相當大的彈性(Flexibility)與重複使用性(Reusability)。

圖5： Content Organization (Source: ADL, 2004）

2. Metadata

SCORM參考了 IEEE LTSC組織所定義的Learning Object Metadata (LOM) 標準，為前 述的各種Content Model分別定義了描述的方法，使這些學習元件可以很容易的被定義、分 類、搜尋、跨平台分享及重複使用。另外還需包括了一個清單檔（imsmanifest.xml），來 描述課程的結構（Content Structure）。這些Meta-data產生的XML檔案，是為了讓學習管 理平台匯入課程時，用來讀取以瞭解課程結構的目的所必須存在的，透過這些Meta-data 所提供的資訊，學習管理平台就可以對各個課程資源進行有效的管理或搜尋，藉以達到教 材共享的目的。 3. Content Packaging 主要是用來定義學習資源模型的組裝規則及包裝格式，其主要目的在於提供一個標準 的封裝方式，使學習資源可以在不同的學習平台上被使用，只要符合這個統一格式的 PIF，就可以很容易的被學習管理平台搜尋、分析並進行交換，達到再利用的目的。在 Content Packaging 概念下，一個 PIF 的 imsmanifest.xml 的檔案如圖6 所示。

圖6： Content Packaging 概念圖 (Source: ADL, 2004）

2.1.2 Run-Time Environment

SCORM 執行時期環境(RTE) 在描述管理執行環境的學習管理系統（LMS）的要 件。亦即發送教學內容的過程，標準化內容與平台之間的溝通方式，以及標準化用來傳遞 學習者學習程的Data Model。SCORM RTE 也描述了Sharable Content Objects（SCOs）的 基本要件，以及它們如何透過API（Application Programming Interface）及Data Model 來與 平台溝通。SCORM RTE 架構如圖7所示。

圖7： RTE 架構圖 (Source：ADL, 2004)

2.2 軟體品質

多媒體教材，兼具「教學」及「軟體」這兩個專業領域特性，因此多媒體教材的品 質可從「教學」及「軟體」這兩個面向來進行探討。在「教學」品質部份，可遵循 SCORM 相關規範來確保所製作出來的多媒體教材其品質能符合預期的教學目標。SCORM的相關 規範與架構已在2.1節具體描述，本節將以多媒體教材的「軟體」品質面向進行探討。 在競爭激烈的資訊科技領域中，「品質」是一個高度與顧客滿意度相關的名詞，其代 表提供的產品與服務是否是即時的、有成本效益的、且能符合顧客的要求。提昇軟體品質 亦是軟體工程（Software Engineering）研究領域中的一項重要探討議題，在軟體的開發上， 有品質的軟體不但可以滿足顧客的需求及期望，亦可以藉由適當的軟體品質管理機制，來 達成設計優良品質軟體產品所需穩定的開發環境[5]。 常見的軟體品質特性包含可用性（Availability）、正確性（Correctness）、可靠性 （Reliability）、性能（Performance）、友善性（Friendliness）、可再用性（Reusability）、 可移轉性（Transferability）、安全性（Safety）、測試性（Testability）、可驗證性（Verifiability）、 維護性（Maintainability）以及可管理性（Manageability）等。ISO 8402-1986 定義軟體品 質是包含產品或服務特徵和特性的整體，以及其符合情況和需求的能力，其品質因子包含 有 效 率 性 （ efficiency ） 、 更 改 彈 性 （ flexibility ） 、 安 全 性 （ integrity ） 、 互 動 性 （ interoperability）、可維護性（maintainability）和可攜性（protability）。根據諸多的品 質特性與影響要素，可以概略定義為“明確說明功能及性能的要求，明確提供軟體開發產 品標準文件和所有專門開發軟體所期望內容特徵相符合的特性。實施軟體品質管制的目標 是以提供顧客高品質與低成本的軟體產品為職責。為達成此目的可以採取改進軟體產品設 計、軟體產品開發與軟體設計規格的一致性（Consistency）、減少軟體開發成本與提高軟 體開發效率。 目前多媒體教材製作的品質管制概況，以國外而言，較廣為人知的有兩個單位，一個 是美國麻省理工學院開放式課程(MIT Open Course Ware)[6]，另一個單位是英國開放式大 學 Open University[7]。 MIT 開放性課程之多媒體教材較趨向於單向、靜態性的 PDF、PPT 與文字檔，而 Open University 近幾年所發展之 web 2.0 多媒體教材，相較於 MIT 來說，更 為繁複和動態，其重視溝通、交流與創新，並廣泛應用於各式平台，如 OpenLearn、moodle 等，利用 Open University 的平台及其他社交網站進行學習，應用於語言、行銷等領域，深 受學習者喜愛。其多媒體教材的品質管制方式，Open University 主要透過流程管理來進行 品質控管，於各製作階段不斷進行檢核，以確認教材品質[8]。以我國而言，由數位典藏 與數位學習國家型科技計畫指導，經濟部工業局主辦，財團法人中衛發展中心承辦之數位

學習品質認證中心，自九十四年度開始辦理認證作業至今，已有百餘件通過數位教材品質 認證。數位學習品質認證中心成立的目的為提供數位多媒體教材與服務之評鑑規範與審查 機制，協助達成品質評鑑規範之認證要求，提高國內數位學習之品質，進而提升我國數位 學習產業之國際地位。 我國數位學習品質認證中心所認證之教材，並非以流程控管方式進行認證，主要是以 教材成品來進行品質檢核。根據數位學習品質認證中心數據分析，民國九十七年度教材品 質認證通過率約為五成，無法通過品質評鑑的品質問題大多為「正確性」問題。正確性的 評估包含教材內所有的圖、文、影音、動畫等所有型態，雖然這些錯誤，均非致命的學習 概念錯誤，但學習者進行學習時，容易降低學習者對於該教材之信任度。這些無法達成正 確性的品質問題，分析歸納後主要有以下七項品質問題[8]： 1. 解說不正確 2. 舉例不適當 3. 錯別字 4. 圖片錯誤 5. 字句不通順 6. 專有名詞前後不一 7. 語音與文字不一致 以上這些國內製作的多媒體教材常見的品質問題，若能在多媒體教材開發過程中，使用適 當的品質手法對製作流程中的產品品質進行審查與控管，相信能大幅改善以上這些缺失， 進而製作出高品質的多媒體教材。 根據數位學習品質認證中心所認證之多媒體教材內容品質，其品質認證的五大面向如 圖 8 所示，分別為： 1. 學習導引：導引、操作指引與求助功能、學習追蹤。 2. 創意：設計開發人員的巧思與創意。 3. 教學設計：教學目標、教學方法、練習與形成性評量、總結性評量，促進學習之策略 及其一致性。 4. 教材內容：正確性、內容組織與完整性。 5. 教學媒體：媒體設計與運用、介面設計、媒體元素。

圖 8：數位教材品質檢核五大面向 (Source：數位學習品質認證中心、本研究整理) 在多媒體教材品質認證的五大面向中，”創意”為主觀認定，無法用一個統一的標準來衡 量。”學習導引”與”教學設計”可遵循 SCORM 的規範來達成。而在”教材內容”與”教學媒體” 這兩個面向，若能在教材製作過程中，透過適當的品質管制方法(例如：本研究所提出的 MQCS 系統)，即可製作出高品質的多媒體教材，這也是本研究最主要的目標。

2.3 CMMI

能力成熟度整合模式 (Capability Maturity Model Integration，CMMI)是一個針對產品 與服務發展的流程改善成熟度模式。它包含發展與維護活動的最佳執行方法，涵蓋產品從 起始到交付與維護的生命週期[9][10]。CMMI 模式整合了發展與維護所必需的知識體系， 例如軟體工程、系統工程、硬體與設計工程、工程服務與採購等，這些在過去都是各別闡 述 。 適 用 於 發 展 的 CMMI (Capability Maturity Model Integration for Development, CMMI-DEV )取代之前適用於軟體工程及系統工程的CMMI (CMMI-SE/SW)，以真實地反 映這些知識體系的廣泛整合，以及組織的模式應用。CMMI-DEV 對於產品與服務的發展 與維護活動，提供廣泛整合的解決方案。

2.3.1 CMMI 歷史沿革

CMMI 是美國國防部委託卡內基美隆大學軟體工程學院(SEI)發展出來的，作為採購 者評估供應者(發展者)的流程能力度與組織成熟度的標準[10]。自1991 年起CMMs 陸續 發展應用於許多專業領域，較著名的包含了系統工程、軟體工程、軟體採購、及整合的產 品與流程發展(Integrated Process & Product Development)等模式。於2000 年整合軟體工 程、系統工程、整合式產品開發等專業領域而發表了整合式模式CMMI v1.0 版，於2002 年 加入委外作業管理後而為v1.1 版。在2006 年8 月發表CMMI v1.2版，應用「群集」概念， 以一組核心組件的集合，提供高度共通內容給特定應用模式，將最佳執行方法擴展至新領 域。2006 年公佈的CMMI-DEV 發展模式(CMMI-Development)、2007 年11 月發表的 CMMI-ACQ 採購模式(CMMI-Acquisition)，以及正在規劃發展中的服務模式。此重要改 變的意義在於同步提昇供需雙方在發展、採購及服務等各面向的流程管理能力，以達到雙 贏的效果。CMMI-DEV 發展模式，係以發展者角度規範思考流程模式，目的是為了協助 組織改善其產品與服務之發展及維護流程。圖9為能力成熟度家族歷史。 圖 9 能力成熟度模式家族的歷史 (Sorece：CMMI for Development Version 1.2)

2.3.2 表述模式

CMMI 支援兩種改善途徑。一個途徑是針對組織所選擇的一個流程領域（或多個流 程領域），使組織能夠漸進地改善流程，使用階段式表述模式(Stage Representation)。另一 個途徑是組織漸進地解決連續的一組流程領域，使組織改善一組相關的流程，使用連續式 表述模式(Continuous Representation)，這兩種改善途徑使用不同的表述方式。對於階段式 表述，使用「成熟度等級」；對於連續式表述，使用「能力度等級」。等級描述改善從一 個不清楚定義的狀態到使用量化資訊，決定與管理改善的狀態，這個改善必須符合組織經 營目標。為達到一個特定等級，組織必須滿足流程領域或一組流程領域中所有適當的目 標。無論是成熟度等級或是能力度等級，它們被當做改善的目標。這兩種表述也提供執行 流程改善的方法，以達到經營目標。圖10 說明了連續式與階段式表述的結構。 圖10：連續式與階段式表述的結構 (Source：CMMI for Development Version 1.2)

階段式表述強調軟體流程改善是循序漸進式，每個層級的完成都是下個層級的基礎。而連 續式的表述則是強調企業可以依據自身的企業目標與願景來自由的選擇流程領域加以改 善。表1為階段式與連續式表述之間的差異。

表1：階段式與連續式表述之間的差異 連續式表述 階段式表述 組織依據其流程改善目標，選擇流程領 域與能力度等級 組織依據成熟度等級，選擇流程領域 使用能力度等級度量改善 使用成熟度等級度量改善 能力度等級： ● 度量跨組織的特定流程領域能力度 ● 等級從 0 到 5 成熟度等級： ● 度量跨組織的一組流程領域成熟度 ● 等級從 1 到 5 能力度等級摘要當做目標與追蹤流程 改善績效 成熟度等級當做目標與追蹤流程改善 績效 對等的階段式允許一個組織使用連續 式表述進行流程改善並引申成熟度等 級以當做評鑑的一部份 並不需要一個對等的機制來反推劉序 式表述

(Source：CMMI for Development Version 1.2)

2.3.3 成熟度等級與能力度等級

階段式表述使用成熟度等級，應用於跨流程領域的組織流程改善的達成。這些等級有 預測下一個從事的專案之一般產出的方式。成熟度有五個等級，編號為1到5，每個等級的 內容簡述如下： 等級 1：没有固定流程、無法提供穩定環境、資源，經常超出專案時程及預算。成功經 驗無法重複，偶而會成功、大都只靠少數有經驗的人才能完成。 等級 2：建立了基本的專案管理過程。按步就班地發展系統、追蹤費用、根據專案進度 表來進行發展。對於相似的專案，可以重覆使用以前的經驗及成果。 等級 3：軟體發展工程和管理活動已標準化，且被集結成為一個組織的標準和流程資產。 所有軟體的發展和維護都在這個標準基礎上制定與執行。 等級 4：對軟體發展過程和產品品質都有很好的歸納，產品成果和發展過程都可用數量 方式控制。可界定流程變異之特殊原因，並適當矯正，軟體發展過程及產品品 質的定量管理。 等級 5：經發展過程的定量回饋機制，不斷產生新思想，並研擬新技術來最佳化相關過 程。組織及專案必須追求持續的、可度量的過程改進，包括缺失預防、技術更 新管理和流程改造管理。

連續式表述使用能力度等級，應用於個別流程領域的組織流程改善的達成。這些等級對一 個流程領域有遞增地改善流程的方式。有六個能力度等級，編號為0到 5，每個等級的內 容簡述如下： 等級 0：沒有執行或部分執行的流程。無法滿足流程領域的一個或多個特定目標，以 及因沒有制度化部分執行流程的理由，這個等級沒有一般目標。 等級 1：滿足流程領域特定目標的流程，支援並使所需工作能夠產出工作產品。由能力 度第1 級所導致的重大改善可能會隨著時間而失去， 因為它們沒有被制度化。 等級 2：具有基礎建設支援流程，任用具備技能的人員，並給予足夠的資源以產出可控 制的產品；納入相關的關鍵人員；監督、控制及審查；並評估遵循流程說明的 程度，確保現有的執行方法能在有壓力的情況下，仍維持運作。 等級 3：流程根據組織的調適指引調適組織標準流程，並納入工作產品、度量與其他流 程改善資訊至組織流程資產。專案的標準、流程說明與程序由組織標準流程調 適而得，以符合特定專案或組織單位，因而更具一致性。 等級 4：使用適當的統計和其它量化的技術進行控制。建立品質和流程績效的量化目標 ，並以該目標為管理流程的準則。以統計的術語瞭解品質和流程績效，並在流 程生命週期受到管理。 等級 5：利用瞭解流程中的共同變異原因，改善流程。最佳化流程以漸進與創新的改善 ，專注於持續改善流程績效。

表2為能力度與成熟度的比較[9][10]。

表2：能力度與成熟度比較表

(Source：CMMI for Development Version 1.2)

2.3.4 流程領域

流程領域是一個領域下相關執行方法的集合，當它們共同執行時，滿足一系列被視為

對改善該領域是重要的目標。CMMI for Development Version 1.2 有以下22個流程領域： • 原因分析及解決方案(CAR) • 建構管理(CM) • 決策分析與解決方案(DAR) • 整合專案管理+IPPD(IPM+IPPD) • 度量與分析(MA) • 組織創新與發展(OID) • 組織流程定義+IPPD（OPD+IPPD） • 組織流程專注(OPF) • 組織流程績效(OPP) • 組織訓練(OT) • 產品整合(PI) • 專案監控(PMC) • 專案規劃(PP) • 流程與產品品質保證(PPQA) • 量化專案管理(QPM) 等級 連續式表述 能力度等級 階段式表述 成熟度等級 等級 0 不完整級 無 等級 1 執行級 初始級 等級 2 管理級 管理級 等級 3 調適級 調適級 等級 4 量化管理級 量化管理級 等級 0 最佳化級 最佳化級

• 需求發展(RD) • 需求管理(REQM) • 風險管理(RSKM) • 供應商協議管理(SAM) • 技術解決方案(TS) • 確認(VAL) • 驗證(VER) CMMI 模式組件被群組成三個類型：必要的、期望的與助益的。反映如何解釋它們[10]。 (1) 必要的組件：說明一個組織要滿足某一個流程領域所需要達成的成果，此成果必須很 明顯地被一個組織的流程所執行。 (2) 期望的組件：包含特定執行方法和一般執行方法。在目標被認定已滿足之前，執行方 法或其可行的替代方案，都必須表現於組織已規劃和已實行的流程之內 。 (3) 助益的組件：提供細部描述協助組織著手思考，如何達成必要的組件與期望的組件。 流程領域與相關的模式組件其關係，如圖11 所示。 圖11：能力成熟度整合模式的組件 (Source：CMMI for Development Version 1.2)

2.3.5 需求管理流程領域

本研究以設計並實作出符合 CMMI 需求管理流程領域成熟度Level 2 的多媒體教材 品質管制系統為目標，因此有必要對需求管理流程領域作詳細說明。需求管理流程領域的 目的是管理專案產品及產品組件之需求，並界定這些需求與專案計畫和工作產品間之差 異。需求可以說是專案必須提供滿足使用者需要，或是待發展的產品及產品組件的清單。 在專案成立時，即應該開始進行需求管理相關工作，包括瞭解需求、取得專案參與人員對 需求的承諾並加以記錄、管理需求變更、維護需求的雙向追溯性（traceability）、界定專 案計畫與工作產品和需求間的差異等等。良好的需求管理是有效執行專案的基礎，無法適 當地瞭解需求、不完整的需求記錄、缺乏使用者參與、使用者有不實際的期待、無法控制 需求變更，都將會導致專案成本超支、延遲交貨、品質不良及客戶不滿意。因此，需求管 理的主要目的就是要避免上述情況的發生，並有效地管理使用者需求，以確保最終產品及 產品組件均符合使用者需求，此外還必須能有效控制需求變更在影響專案的時程、成本與 品質的最少狀況下，這也就是需求管理對專案的重要性[11]。在CMMI 中所規範之需求管 理流程領域的連續式表述之特定目標及特定執行方法如表3所示。 表3：需求管理流程領域的特定目標及特定執行方法 (Source：需求管理流程領域導入指引，資策會，2006) 1. 需求管理的流程規劃 需求管理作業按專案進行之時程與作業性質，分析歸納為「需求管理規劃程序」 及「需求變更追溯管理程序」等兩項程序[11]，如圖12所示。 連續式表述 特定目標 / 執行方法 說明 SG1 需求管理 管理需求，並界定需求與專案計畫及 工作產品間之差異。 SP1.1 暸解需求 與需求提供者一起瞭解需求之意義。 SP1.2 取得需求承諾 自專案參與人員取得需求承諾。 SP1.3 管理需求變更 在專案進行期間管理需求的變更。 SP1.4 維護需求的雙向追溯性 維護需求及專案計畫與工作產品間的 雙向追溯性。 SP1.5 界定專案計畫與工作和 產品需求間的差異 界定專案計畫與工作產品和需求間的 差異。

圖12：需求管理流程領域主要程序圖 (Source：需求管理流程領域導入指引，資策會，2006) 2. 需求管理規劃程序 需求管理相關活動規劃，必需在專案規劃初始，或者視專案作業需要，進行個別需求 管理活動。另外，在產生需求變更時，或發現需求與專案計畫和工作產品之間有差異時， 即啟動需求變更追溯管理程序。需求管理與變更追溯管理程序的流程圖如圖13所示。

圖13：需求管理與變更追溯管理程序的流程圖 (Source：需求管理流程領域導入指引，資策會，2006)

3. 需求管理的實施

準。在實施需求管理時，有一些值得注意的地方： (1) 確實了解需求追溯表中，需求內容與專案需求之間的追溯性。 (2) 選擇適合的需求變更處理方式。由於需求管理作業的重要性，因此，系統必須在需求 基準的建立與維護方面多做注意。 (3) 一個比較容易忽視但很危險的是有時候每項需求變更都不大，但在整個專案生命週 期累積下來的需求變更其影響就變的很大。因此，有必要定期加以統計分析，一方 面可瞭解需求變更的趨勢是否已經逐漸縮小，同時評估所累積的需求變更對專案成 本之影響，並適時提出警訊。 (4) 評估結合需求管理工具的使用。當專案需求項目數量很多又變更頻繁時，應考慮評 估結合適用的需求管理工具來減輕負擔。

2.3.6 預期效益

根據 SEI 2007年的分析報告指出，導入CMMI廠商的平均效益如下[12]： 1. 生產力提高 35% 2. 產品上市時間縮短 19% 3. 產品發行後缺失率減少 39% 4. 節省成本對投入軟體流程改善成本的比例為 5：1 5. 產品錯誤率約降低了 15％。 6. 生產力提高了 30％。 由此可知流程是組織持續改善的要素之一，CMMI 模式可提供指引改善組織流程規範， 以及發展、取得及維護產品或服務的管理能力。

三、多媒體教材管理系統分析與流程設計

由第二章的文獻探討可知道，「品質」就是能符合需求。而需求，則是應該被開發出 來的規格。由於多媒體教材兼具「教學」與「軟體」兩種專業領域特性，所以必須針對這 兩大專業領域進行規範及管理。在教學領域方面，多媒體教材必須依據 SCORM 的相關規 範，以確保開發出來的教材產品能正確有效的引導學習者進行學習，達成教學目標。在軟 體領域方面，為了有效率的進行需求及流程管理，避免產生多媒體教材內容正確性的錯 誤，必須在多媒體開發製作過程就進行系統化的管理與審查。而在開發流程管理方面，國 際上也有許多相關標準，例如 ISO/IEC 12207 軟體工程標準、IEEE/EIA 12207 標準、CMMI 等，其中又以美國卡內基美隆大學(Carnegie-Mellon University， CMU)的軟體工程研究所 (Software Engineering Institute， SEI)所提出的國際性標準能力成熟度整合模式(Capability Maturity Model Integrated， CMMI)整合了大部分國際標準的內容最具有代表性。CMMI 優越的流程改善、管理的能力及品質規範，近年來也獲得世界上大部分軟體開發組織的認 同與採用。 本研究的主要目標，在於提出一套於多媒體教材品質管制方法，於多媒體教材的製作 過程中，實作以 CMMI 需求管理流程領域的各項管制方式，來達到製作出符合能力度第 二級的高品質多媒體教材。因此本章將針對 CMMI 需求管理流程領域進行分析，並整合 多媒體教材開發的生命週期，設計、製作出符合上述目標的多媒體教材管理系統(MLCs Quality Control System, MQCS)。

3.1 CMMI需求管理流程領域分析

CMMI需求管理流程領域的主要目的是管理專案產品及產品組件之需求，並界定這些 需求與專案計畫和工作產品間之差異[11]。所有專案都是從瞭解需求開始，需求可以說是 專案必須提供滿足使用者需要的清單，或是待發展的產品及產品組件的清單。在專案成立 時，即應該開始進行需求管理相關工作，包括瞭解需求、取得專案參與人員對需求的承諾 並加以記錄、管理需求變更、維護需求的雙向追溯性（traceability）、界定專案計畫與工 作產品和需求間的差異等等。良好的需求管理是有效執行專案的基礎，無法適當地瞭解需 求、不完整的需求記錄、缺乏使用者參與、使用者有不實際的期待、無法控制需求變更， 都將會導致專案成本超支、延遲交貨、品質不良及客戶不滿意。因此，需求管理的主要目 的就是要避免上述情況的發生，並有效地管理使用者需求，以確保所有專案之最終產品及

產品組件均符合使用者需求，此外還必須能有效控制需求變更在影響專案的時程、成本與 品質的最少狀況下，這也就是需求管理對專案的重要性。需求在專案生命週期各階段會繼 續演進為專案計畫、需求規格、設計文件、原始程式碼、測試文件等之內容。這些項目是 在不同發展階段的工作產品，但前後之間關係密切，任何一項工作產品內容變更都有可能 對其他項目造成影響。換言之，需求會影響專案的所有工作產品。然而，以一開始時使用 者需求管理最為重要，因為對需求能愈早掌握就愈能減輕因需求變更所衍生之影響。本研 究參考CMMI中有關於需求管理(Requirements Management, REQM)的流程領域(Process Area, PA)中的相關規範，共有1個特定目標(Specific Goal，SG)及5個特定執行方法(Specific Practices，SP)，其內容如下[11]：

SG 1 管理需求(Manage Requirements)

管理需求，並界定需求與專案計畫及工作產品間之差異。 SP 1.1 瞭解需求(Obtain an Understanding of Requirements)

與需求提供者一起瞭解需求之意義。

SP 1.2 取得對需求的承諾(Obtain Commitment to Requirements) 自專案參與人員取得需求承諾。

SP 1.3 管理需求變更(Manage Requirements Changes) 在專案進行期間管理需求的變更。

SP 1.4 維護需求的雙向追溯性(Maintain Bidirectional Traceability of Requirements) 維護需求及專案計畫與工作產品間的雙向追溯性。

SP 1.5 界定專案工作與需求之間的差異(Identify Inconsistencies between Project Work and Requirements)

界定專案計畫與工作產品和需求間的差異。

SEI 針對需求管理(REQM)提出環境圖(Context Diagram)如圖 14 所示[10]，並以此說明各項 規範之間的關係性。

圖14：需求管理流程領域環境圖

(Source: Introduction to CMMI ，SEI)

本研究針對多媒體教材開發製作過程，以 CMMI 中需求管理流程領域的五項規範及 環境圖為基礎，歸納並分析出系統開發的四大模組，分別為： 1. 需求新增：需求的新增與建立，來自於需求提供人員(專案關鍵人員)。專案管理人員 在與需求提供管理人員一起了解需求的定義並取得需求承諾之後，始得新 增該需求。 2. 需求變更：專案進行期間，由於開發設計上的需要或需求提供人員的需求改變，可提 出需求變更以符合產品實際的需要。 需求的變更必須經由適當的程序進行 管理。 3. 需求審查：不論是需求的新增或需求變更的提出，都需要經由專案審查委員的審核確 認才可進行。 由於需求的變更可以在專案的任一時期提出，於是需求的審 查也必須在專案的任一時期進行。所有需求審查通過後即可發行，並需納入 建構管理。 4. 需求追溯：不論需求的新增或變更，系統都必須建立需求的水平追溯與垂直追溯，同 時必須納入建構管理， 讓專案相關人員可以在專案進行中進行需求追溯查 詢。 為了清楚的表示這四大模組在多媒體教材開發過程中與相關人員的關連性，本研究以軟體 工程中的 User Case Model 來表示其相關性，如圖 15 所示。

圖15：需求管理4大模組Use Case Model (Source: 本研究整理)

3.2 功能性需求與非功能性需求

需求區分為功能性需求、非功能性需求與專業領域需求，本節主要在探討與分析功能 性需求及非功能性需求這兩項。功能性需求就是系統該提供什麼樣的功能，非功能性需求 是指系統的特性與限制。依據 CMMI 需求管理流程領域的特定目標(SG)與特定執行方法 (SP)，本研究分析出所要開發的 MQCS 系統之四大模組所需之功能性需求與非功能性需 求，以表列的方式表示如下。 1. 功能性需求 MQCS 系統之功能性需求，包含需求管理、需求審查、需求變更及需求追溯四大模組 所需之功能，並整合 CMMI 需求管理流程領域特定目標(Specific Goal)及特定執行方法 (Specific Practices)所需執行之功能項目，如表 4。

表 4：MQCS 系統功能性需求表 功能性需求 描述 參與人員 CMMI REPA SG / SP 建立專案 建立新教材專案，包括專 案代碼、名稱、專案執行 人員、權限設定、需求任 務指派 專案經理 SG1 需求管理 需求新增 新增原始需求，包括需求 代碼、名稱、內容描述、 參考附件 允許需求提供 人員 專案經理 系統分析人員 SG1 需求管理 SP1.1 瞭解需求 需求編修 編輯、修改、刪除需求內 容 系統設計人員 SG1 需求管理 SP1.1 瞭解需求 需求變更 已通過審查之需求，因原 設計規格、內容、附件.. 等不同因素需要，進行設 計變更 允許需求提供 人員 系統設計人員 SP1.3 管理需求變更 需求審查 依據需求接受準則進行一 般需求審查及需求變更審 查 需求審查委員 專案經理 SP1.2 取得需求承諾 需求檢視 透過列表或產生文件的方 式檢視需求內容及相關資 訊 專案關係人 SG1 需求管理 需求水平追溯 檢視需求功能間的水平追 溯關聯 專案關係人 建構管理人員 SP1.4 維護需求雙向追溯性 需求垂直追溯 追溯系統開發生命週期間 所產出的產品之關聯 專案關係人 建構管理人員 SP1.4 維護需求雙向追溯性

需求變更追溯 追溯需求變更的相關資訊 專案關係人 建構管理人員 SP1.3 管理需求變更 一致性檢查 檢查產品與需求間的不一 致性並與予矯正 系統設計人員 SP1.5 界定專案計畫與工作 和產品需求間的差異 (Source: 本研究整理) 2. 非功能性需求 MQCS 系統之非功能性需求包含 Client-Server 架構、多人同時上線使用、Web-based 的系統介面、權限管理及相關系統開發資源等項目，如表 5。 表 5：MQCS 系統非功能性需求表 非功能性需求 描述 類別 Web-based 多人使用 網頁程式 可多人同時上線使用 環境建置 User 權限 專案經理、系統開發人員、專案關係人需各 自有不同權限 安全性 可移植性 可跨平台使用(Windows 、UNIX、Linux…) 系統可攜性 提供發展資源 Open Source ZK：http://tw.zkoss.org/ Java：http://java.sun.com/j2se/1.5.0/docs/api/ 系統資源 (Source: 本研究整理)

3.3 多媒體教材製作生命週期

多媒體是創意呈現的基本要素，如何使用多媒體來表達教材所要呈現意境或禪釋的理 論觀念是多媒體教材製作最主要的課題。多媒體教材的製作首先必須選定腳本(script), 此 腳本是用來勾勒多媒體教材內容所要表達意境或禪釋的理論觀念。腳本情節中需要各種不 同的多媒體資料來協助使教材內容的意境表達或理論觀念的禪釋更貼切或更容易讓讀者

了解。這些多媒體資料包括影片, 圖片, 聲音, 動畫, 以及文字。而腳本內的情節是用來描 述這些多媒體資料之間的空間及時間的關係。就多媒體教材的開發生命週期來看，參考交 通大學軟體工程實驗室所提出的研究內容[13]，可歸納出其基本步驟如下： 1. 多媒體教材的教案設計。 2. 根據教案的內容設計分鏡腳本(Storyboard)。 3. 根據分鏡腳本(Storyboard)的劇情需要，設計多媒體教材的場景及使用者介面(User Interface)。

4. 根據分鏡腳本(Storyboard) 的劇情、多媒體教材的場景與使用者介面(User Interface) 的需要，設計教材所需的多媒體素材演員(如文字、圖片、動畫、影片、音樂)。 5. 使用適當的多媒體編輯工具，根據分鏡腳本(Storyboard)的劇情內容，將多媒體教材 的場景及使用者介面(User Interface)與素材，組合成一完整的多媒體教材。 在軟體工程(Software Engineer)領域裡，有系統地進行軟體的規劃、分析、設計、程 式製作與維護等工作的軟體製作程序(Software Process)已經廣泛為軟體開發者所遵循與應 用，來提高軟體的生產力和軟體的品質。軟體製作程序的主要的階段 [14] 如下:

1. 軟體需求確認階段 (Requirements Definition Phase) 2. 軟體設計階段 (Design Phase)

3. 軟體實作階段 (Implementation Phase)

4. 軟體測試及驗證階段 (Verification and Validation Phase) 5. 軟體維護階段 (Maintenance／Evolution Phase) 同樣地，多媒體教材也是「軟體」的一種，其開發流程也適用於一般軟體工程中的軟 體製作生命週期中的各個階段。不同的是有別於一般軟體程式，因多媒體教材軟體額外具 有「教學」的性質及使用多媒體形式呈現的特性，其製作過程的生命週期與一般軟體程式 稍有不同，其主要的發展階段詳述如下： 1. 課程導入期 (RD)：主要的工作是根據教學目的、教學對象與教學環境的需求，使用 原創設計或是選定現有適當的學習教材或教案，作為開發多媒體教材的原始教學內 容與依據 2. 課程規劃期/單元腳本設計 (DM)：主要的工作是設計多媒體教材的分鏡腳本，此分

鏡腳本是用來說明多媒體教材內容所要表達意境或觀念。腳本內的劇情同時需要描 述這些多媒體素材之間與場景的空間及時間的關係。 3. 課程規劃期/場景 UI 設計 (UI)：主要的工作是設計多媒體教材的使用者界面，美術 編輯者依據多媒體教材的分鏡腳本中每一幕場景的需要，設計多媒體教材內容的使 用者界面。 4. 課程製作期/素材製作 (MM)： 主要的工作是根據多媒體教材的分鏡腳本劇情的需要 ，設計腳本中每段劇情所需要使用不同資料格式的多媒體素材，來協助了解教材內容 的意境表達或觀念。 常見的多媒體資料格式種類包括聲音、影片、圖片、動畫及文 字。 5. 課程製作期/教材製作 (CM)：主要的工作是多媒體教材內容的編輯及製作，需要使 用多媒體編輯軟體或程式開發工具，根據分鏡腳本的劇情描述，將多媒體素材及場 景之間的空間及時間的關係，製作成一幕幕的多媒體教材內容。而此步驟所使用的 多媒體編輯軟體或程式開發工具，對於多媒體教材的最終成品有關鍵性的影響。

在多媒體教材開發生命週期(MLCs Process Life Cycle, MPLC)中的每一個階段，都必 須經過需求內容審查的方式確認需求承諾，作為下一個階段開發的依據，以此方式來確保 製作出來的多媒體教材產品品質。然而無可避免地，與一般的程式軟體開發過程一樣，需 求變更(Requirements Change)亦會發生在多媒體教材開發生命週期的任一階段。當發生需 求變更時，為了避免不一致性(Inconsistency)品質問題的產生，同樣要進行需求變更審查， 並透過需求的水平追溯與垂直追溯，確認需求變更對於最終產品所造成影響的範圍大小， 並做為下一個階段開發的依據。多媒體教材開發生命週期的流程，如圖16所示。

圖 16：多媒體教材開發生命週期流程圖 (Source: 交通大學軟體工程實驗室)

3.4 MQCS系統流程

依據前兩節的分析，本研究整合了CMMI需求管理流程領域中的規範所歸納出來的功 能性需求，與多媒體製作生命週期流程，提出MQCS系統流程，內容包含了需求管理、需 求新增、一般需求製作流程，一般需求審查、需求變更管理流程、變更審查、變更追溯、 需求追溯等系統功能。MQCS系統流程圖，如圖17所示。

圖17：MQCS系統流程圖

MQCS 系統流程說明：

依據 SCORM 的架構規範，SCO(Sharable Content Object)為最基本的具有教學意義的 單元，並且具有獨立性，因此本研究定義以一個 SCO 作為基本的管理及設計的需求單元， 一份教材由若干個 SCO 依據其所歸屬的章節結構所組成。MQCS 的需求管理以每一個需 求單元 SCO 作為管理對象。 1. 課程導入期/教學內容設計(RD)：由多媒體教材開發專案管理人員依據教案內容建立新 專案，並依據 SCORM 規範中的每個章節單元的最底層一定是 SCO 之架構原則，設定 教材的章節單元 SCO 架構，MQCS 系統自動賦予 SCO 一個獨立的編碼，以便系統識 別與管理，並進行 RD 階段審查。審查通過後，針對每一個需求單元(SCO)進行需求指 派，將教材內容所有的需求單元 SCO 指派給多媒體教材設計人員進行設計。 2. 課程規劃期/單元腳本設計(DM)：設計人員依據每一個需求單元(SCO)的分鏡腳本內

容，進行分鏡、劇情、場景及演員設計。此階段最主要的工作，是將單元腳本內的情 節，依據多媒體資料之間相互的時間與空間關係，選定或設計適當的多媒體素材將其 在 MQCS 系統中設定成一幕幕的多媒體教材內容。設計完成後必須進行 DM 階段審 查，審查通過後，始得進行場景 UI 及演員素材製作。 3. 課程規劃期/場景 UI 設計(UI)：依據 DM 階段所設定的場景 UI 內容，使用多媒體製作 工具(本研究使用智勝國際所開發的編輯手)[15]進行實質的場景 UI 檔案編輯製作。製 作完成的場景 UI 檔案，必須上傳到 MQCS 系統中，進行 UI 階段審查。 4. 課程製作期/素材製作(MM)：依據 DM 階段所設定的演員內容，使用多媒體製作工具 進行實質的素材檔案編輯製作。多媒體教材的演員素材可包含文字、圖片、動畫、聲 音、影片...等格式。製作完成的素材檔案，必須上傳到 MQCS 系統中，進行 MM 階段 審查。 5. 課程製作期/教材製作(CM)：依據 DM 階段所設計的分鏡、劇情腳本內容，使用 UI 及 DM 階段審查通過的多媒體素材，在多媒體製作工具中，使用前階段已審查通過 的場景 UI 及演員素材多媒體檔案，實際編輯製作出該需求單元(SCO)的多媒體教材 內容。製作完成後必須上傳到 MQCS 系統中，進行 CM 階段審查。審查通過後， 該單元需求(SCO)的設計工作才算完成。 由以上 MQCS 系統針對一個單元需求(SCO)的開發設計流程說明，可發現在多媒體教材開 發生命週期的每一個階段所開發出來的半成品，都必須通過審查才能進入下一階段。 MQCS 藉由對每一個多媒體教材開發階段都必須進行需求審查的機制，來落實流程控管 (Process Control)的理念，即時找出多媒體教材在製作過程中所產生的正確性錯誤，以確保 最終能製作出具有高品質的多媒體教材。 如前所述，在多媒體教材開發生命週期的任一個階段都可能會產生需求變更。當需求 變更發生時，必須執行需求變更程序並進行需求變更審查。MQCS 系統需求變更流程如圖 18 所示。

圖 18：MQCS 系統需求變更流程圖 MQCS 系統需求變更流程說明： 在多媒體教材開發生命中期中的任一階段，於該階段審查完成後，因為開發設計上的需要 或需求提供人員的需求改變，設計人員可提出需求變更。需求變更提出後，須經由審查小 組或專案負責人依據該需求的水平追溯及垂直追溯資訊，界定評估該需求變更所影響的範 圍大小，進行需求變更審查，決定是否同意需求變更。所有的需求變更資訊將自動儲存在 MQCS 系統中，以供需求變更追溯查詢。

四、系統製作與導入

依據第三章所分析的結果為基礎，本章節主要說明如何在 MQCS 系統中製作需求管 理、需求審查、需求變更、需求追溯四大模組內容，並整合 CMMI 需求管理流程領域及 多媒體開發生命週期流程中的每一個階段，實作出所有的功能性需求與非功能性需求，以 達到 MQCS 的系統目標。

4.1 系統平台與開發工具

為了提供多媒體教材開發人員可以同時上線進行多媒體教材的設計與開發，本系統 採用 Web-based 的程式設計介面，在網際網路(Internet)上透過瀏覽器(Browser)執行。為了 讓系統可以有較好的集中管理和控制能力﹐本系統使用 Client-Server 架構，如圖 19。客戶 端（Client）可為個人電腦或小型工作站，本身就具備完整獨立作業能力；伺服器端（Server） 則是一台較大型的伺服器或電腦主機，而在客戶端及伺服器端之間則藉由 TCP/IP 通信協 定連結，形成通訊網路來互相傳遞的資料。由客戶端發出服務的請求，訊息傳給 Apache 伺服器後，再由 Apache 伺服器經由 MySQL 資料庫系統進行相關資料記錄及處理，然後 再將資料或結果傳給客戶端。 圖 19：MQCS 系統環境架構圖 Web Browser Windows XP

User Interface Level OS Client JAVA / ZK Application Level JDBC Middleware Level

Apache Server Web Server / DB Server

MySQL Server UNIX

Server

考慮到一般使用者的普遍使用環境，在使用者端主要是使 Windows XP 作業系統， 而遠端伺服器網站之建置則是使用 Linux 作業系統，搭配 Apache 網站伺服器，並以 MySQL 為其後端資料庫，系統作業環境如下： 開發環境： z 系統開發工具： Java JDK 1.6.0、ZK 3.6.0 z 系統開發平台： Microsoft Windows XP 伺服器端： z 作業系統：Linux 平台 z 網站伺服器：Apache Tomcat 5.5 z 資料庫伺服器：MySQL 5.0 以上 使用者端：

z 作業系統 Microsoft Windows 98, Me, NT 4.0, XP, 2000, 2003 z 網頁瀏覽器 Microsoft Internet Explorer 6.0 以上

4.2 MQCS 系統架構

MQCS 系統功能依權限不同而有不同功能選項，如圖 20 所示。

圖 20：MQCS 系統功能架構圖

專案管理人員：負責多媒體教材開發之專案建立、教材章節架構建立、編修權限設定、 單元需求任務指派、需求管理、各階段一般需求審查、需求變更審查、 需求文件管理等。 系統設計人員：管理、編修及製作被指派的單元需求內容、需求變更作業、審查狀況查 詢、需求文件產生及一致性檢查等。 專案關係人：參與專案的所有人員，可進行專案內容檢視、查詢。

4.3 系統製作

MQCS 系統功能性需求分為需求管理、需求審查、需求變更、需求追溯四大模組， 整合多媒體教材開發生命週期各階段系統製作方式，詳述如下： 1. 需求管理 (1)教學內容設計(RD) 依據 SCORM 教材架構如圖 21，可清楚得知 SCO 為最基本的具有教學意義的單元。 圖 21：SCORM 教材架構圖 (Source：交通大學軟體工程實驗室) 因此本系統將 SCO 定義為最基本的需求單位，由系統自動賦予一個唯一識別碼作為 需求代碼，以便進行管理。需求的指派、編修、製作皆以此具有唯一識別碼的 SCO

作為管理的標的。為了有效地管理每個需求(SCO)的開發設計狀況，每個需求都以一 個狀態碼來表示目前該需求的狀態。 此狀態會隨著該需求在開發設計中進展到不同 的階段、流程而由系統自動變更其狀態碼內容。需求狀態碼及其流程如圖 22 所示。 圖 22：需求狀態碼及流程圖 狀態碼意義及流程說明如下： E：編修狀態。當一個單元需求(SCO)被建立及審查完成後，該單元需求會被 MQCS 系統自動賦予狀態碼”E”，並可被專案管理人員指派給系統開發人員進行設計。 系統設計人員可以編輯及修改狀態碼為”E”的需求單元內容。 V：送審狀態。 當設計人員於多媒體教材開發生命週期中的任一階段，編輯完需求 內容並儲存後，必須將該階段所編輯的需求內容透過”送審”的功能項目，送出審 查。一旦該需求內容送審後，其狀態碼會由系統自動變更為”V”，表示該需求已 進入送審階段，此時該需求內容只能查詢，無法做任何變更。 N：審查駁回。當需求送審後，若無法通過審查，其狀態碼會被系統自動變更為”N”， 此時設計人員可以對該需求重新進行編輯、修改，編修完畢後重新送審。 Y：審查通過。當需求送審後，若通過審查，其狀態碼會被系統自動變更為”Y”。 狀 態碼為”Y”的需求單元，除非進行需求變更程序，否則其內容將無法再被更改。 C：需求變更。已經通過審核，狀態碼為”Y”的需求單元，若要變更其設計內容，可 經過變更程序，申請變更原需求內容。當執行需求變更申請程序時，該需求單元

狀態碼會被系統自動變更為”C”，表示該需求單元目前為需求變更申請階段。經 過需求變更審查後，若審查人員同意變更，則該需求之狀態碼會被系統自動 變更為”N”，此時設計人員就可以對該需求單元內容進行編輯、修改。若審查 人員不同意變更，則該需求之狀態碼會被系統自動回覆為”Y”，表示該需求單 元將以上次審查通過的內容為準，設計人員無法對其內容進行任何修改。 MQCS 系統透過狀態碼與相關的作業流程，來實作並達到需求管理的目的。 (2)單元腳本設計(DM) 在本階段，需求單元內容將根據原始教案的單元腳本內容進行下列工作： -- 建立分鏡(SCENE)：依據腳本內容設定分鏡資料。 -- 建立場景(UI) ：依據腳本內容建立場景資料。 -- 設定劇情(SCRIPT)：依據腳本內容設定劇情內容。 -- 設定演員(ACTOR) ：依據腳本內容建立多媒體演員資料。 -- 建立相依性關係：依據腳本內容設定分鏡、場景、劇情、演員的相依關係，可使 用節點圖表示，如圖 23 所示。 圖 23 中，一個分鏡 SCENE1(分鏡一)包含了三段劇情 SCRIPT1(劇情一)、SCRIPT2(劇情二)、 SCRIPT3(劇情三)、這三段劇情共同使用一個場景 UI1(場景一)。 而場景 UI1 中使用 了 ACTOR1(演員一)、ACTOR2(演員二)、ACTOR3(演員三)、ACTOR4(演員四)這四 個演員。同時劇情 SCRIPT1 使用了 ACTOR1、ACTOR2、ACTOR3 三個演員，劇情 SCRIPT2 使用了 ACTOR1、ACTOR3、ACTOR4 三個演員，而劇情 SCRIPT3 使用了 ACTOR2、 ACTOR3、ACTOR4 三個演員。