系統製作

整合多媒體教材開發生命週期各階段系統製作方式，詳述如下：

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 三個演員。

圖 23：劇情、場景、演員相依性關係圖

根據劇情、場景以及多媒體演員素材之間所存在的相依性關係，可定義一個多媒體 教材正向相依矩陣如表 6 來記錄其相依性關係[5]。當各工作階段存在相依性關係，

則於正向相依矩陣對應的相關欄位設定數值為 1，若不存在相依性關係則設定為 0。

所謂的正向相依矩陣其主要意義可由表 6 中的 Dependency-Out-Degree(DOD)的意義 來說明其特性，DOD 的數值大小代表當多媒體教材開發生命週期的任一階段的需求 設計改變時，所影響下一階段的設計工作的範圍大小。以圖 23 為例，SCENE1 中包

含了三段劇情 NLS1、NLS2、NLS3，則在正向相依矩陣中，SCENE1 所對應的 NLS1、

NLS2、NLS3 這三個欄位的值則填入”1”，其他沒有直接正向對應關係的欄位的值則 填入”0”，所以 SCENE1 的 DOD 值為”3”，其內容如表 6。其他各項元件如場景(UI)、

演員(ACTOR)等，依照上述方法將與其具有直接正向相依關係的對應欄位的值一一填 入，即可得到一完整的正向相依矩陣內容。

表 6：多媒體教材正向相依矩陣

(3)場景 UI 設計(UI)

本階段依據 DM 階段建立的場景內容，進行場景相關參數的建立，並於多媒體編輯 軟體中製作相關場景檔案，並經由”檔案上傳”功能，將場景檔案上傳到 MQCS 系統 中進行管理與審查。由於本系統是與智勝國際公司所推出的多媒體編輯軟體”編輯手 ”進行整合，因此在此階段可依據編輯手的場景參數規格如表 7，進行場景 UI 參數 設定。

表 7：編輯手軟體場景參數表

Background Color 16777215 場景背景顏色

PrelmdeEffect 0 轉場特效代碼, 0：無轉場特效

Position 498 318 127 演員位置(X-axis,Y-axis,Depth)

Size 116143 演員大小(Width,Height)

Alpha 1 演員透明度, 0~1

BorderInfo

1.BegPicIdx 開始的 frame index 2.EndPicIdx:結束的 frame index

RecordingCaption EMPTY 錄音檔名稱

RatioEquality 0 等比縮放，0:關閉，1:開啟

2. 需求審查

Stage Req. Definition Software Design Implementation

Index RD DM UI MM CM

3. 需求變更

在單元腳本設計(DM)階段，系統已建立了分鏡、場景、劇情及演員的相依性。透過正 向相依矩陣可清楚得知多媒體教材開發生命週期的任一階段的需求設計改變時，所影 響下一階段的設計工作的範圍大小。

圖 24：需求變更相依性關係圖

如圖24中粗體線部分，當 SCRIPT2 變更其設計或內容時，將會影響到與 SCRIPT2 具有正向相依關係的元件，包含UI1、ACTOR1、ACTOR3、ACTOR4、CM1等。當 需求變更通過審查時，配合前述狀態碼的設計、應用前面所敘述的正向相依矩陣內 容，將所有與SCRIPT2具有正向相依關係的元件(亦即該元件在正向相依矩陣中欄位 值為”1”的元件)，其狀態碼皆會被MQCS系統自動變更為”E”，將這些元件變更為”可 編輯”的狀態，此時這些即可進行需求變更的設計工作。需求變更設計完成後，仍需 依照一般需求審查流程，進行審查。

4. 需求追溯

透過前述多媒體教材正向相依矩陣的建立，即可依照正向相依矩陣所記錄的內容，

進行需求水平追溯。此外可將正向相依矩陣作轉置(Transpose)，可得到另一個多媒 體教材反向相依矩陣(MLCs Backward Dependency Matrix, MBDM)，如表10所示[5]。

反向相依矩陣其主要意義可由 表10.中的Dependency-In-Degree(DID) 的意義來說明 其特性，DID的數值大小代表當多媒體教材開發生命週期(MPLC)的任一階段的設計 需求，受到來自上一階段的設計工作影響的範圍大小。

表 10：多媒體教材反向相依矩陣

綜合多媒體教材正向相依矩陣及反向相依矩陣內所記錄的相依性關係，即可知道當 需求變更發生在多媒體教材開發生命週期的任一階段時，所造成影響的範圍大小，

並以此設計作為滿足 CMMI 對於維護需求的雙向可追蹤性(Bidirectional Traceability) 的能力基礎。