第二章 文獻回顧與評述
第四節 系統維護方法論
雖然已經有數眾多的系統開發方法論問世，相較之下，卻沒有多少個系統維 護方法論。然而，學術界逐漸開始承認系統維護有著不同於系統開發特性 （April et al.,2005;Abran et al.,2004）並且漸漸開始發展系統維護方法論。
在 1990 年代，有著非常稀少的系統維護方法論被提出。舉例而言，Simple reuse model（SRM）（Basili,1990）是一個簡單的模型，把系統維護單純視為軟體 物件的再用。IEEE 1219（IEEE,1998）是一個流程模型，其中包含了問題辨認、
分析、設計、實作、系統測試、接受度測試、和交付等階段。
截至今日，有一些其他的系統維護方法被發展出來。例如，Mantema（Polo et al.,2002）是一個有四階段流程模型的方法論，此四階段包括：維護流程定義、
無法預先規劃的維護（緊急更正）、可預先規劃的維護（非緊急更正、預防、完 善、與適應）、以及遷移與退役。Corrective maintenance maturity model（CM3）
（Kajko-Mattsson,2002）是一個針對更正性維護的龐大且非常詳細的模型，CM3 的重點在於問題管理，包含了問題報告、問題分析、與問題解決。Adaptive development and maintenance（ADM）（Pahl,2004）有著以下三個階段：透過劇本 為基礎設計來進行參與式的需求工程、可改寫的架構設計與雛形設計、以及評估
與演進導向的改變與維護。
此外，SMmm（April et al.,2005）設計來與能力成熟度模式（CMMi）互補，
其包含四個流程領域：流程管理、要求管理、演進工程、以及演進工程的支援。
SMmm是一個流程模型並有數種軟體維護的成熟度。SMmm針對要求管理的第二 層級成熟度擬定了六項詳細的規定，此第二級成熟度是SMmm目前所發展出的最 高層級，這六項規定在第六章有所說明。而SMmm流程模型包含了下列七個階段
（如第三章第二節的圖 5），而軟體演進工程階段是要求管理、營運支援、系統 更正、系統演進的集合。
(1) 交付前與轉移：這是指開發者把系統交給維護者之前的時期。
(2) 要求管理：此階段負責去處理系統的日常問題與維護要求。
(3) 營運支援：此階段包含的工作有系統的評估、顧問、以及教育訓練。
(4) 系統更正：此階段的工作是修理系統的故障，使系統能正常運作。
(5) 系統演進：這個階段包含了適應性、完善性、功能更新、與功能減少的活動。
(6) 導入狀況監控：此階段是為了確定維護後的系統在實際運作上是否有窒礙難 行之處。
(7) 系統重生（Rejuvenation）、遷移與退役：此階段的作用包含改善可維護性、
把系統遷移到另一個環境、或拋棄老舊系統。
本研究所提議的方法論選定 SMmm 作為實務性的互補品，其理由有三。第 一，SMmm主要源自於是從實務者的觀點而提出。第二，此模型後來也考慮了多 種系統維護相關的國際標準，例如 ISO/IEC 12207 與 IEEE 1219。第三，SMmm 針對要求管理提出了一組詳細的指導方針。
Enhancive maintenance model（EMM）（Kajko-Mattsson et al.,2006）是從三個 組織所衍生歸納而得，此功能更新維護流程中的開端有四個階段：功能更新提 交、功能更新分析、決策、與簽訂合約。
表1 包含了上述七種系統維護方法論以及本研究所提出的方法論，依照出刊 年份由早到晚排列。在表1 中，這些系統維護方法論依照下列五種特色類型來進
行評估：
z 特定維護類型：此特色類型是去說明該方法論是否是針對特定系統維護類 型來設計的。一些方法論是適用於各種各樣的系統維護類型，而一些方法 論則是只針對特定系統維護類型來設計。
z 做法的詳細度：此特色類型是要顯示系統維護方法論是否提供在其所提的流 程中提供了詳細的做法。
z 考量衝突解決：此評估準則是去判斷各方法論是否對多元觀點所發生的衝突 提供了協助解決的步驟。
z 考量需求變更：此評估準則是去判斷各方法論是否提供了根據回饋資訊來修 改既有維護需求的機制。也就是說，在維護需求被正式批准或被採用之 後，在接下來的設計、撰寫程式、與導入階段，都可能發現一些之前沒有 考慮到的阻礙而習得新的教訓，而有時就必須據此去更動維護要求才是良 策。
z 隱喻：方法的背後往往有其哲學的立場，而揭露方法背後的隱喻，可說是揭 露其基本精神的一種方式，這在下一節會專門對此加以說明。
表 1 揭露了關於現存七種系統維護方法論的一些有趣的現象。第一，除了 CM3 問題管理與 EMM 之外，大部分的方法論都不是針對特定維護類型而設計 的。第二，這些沒有針對特定維護類型而設計的方法論，雖然大多都提出了流程 概念的概觀，但是卻往往沒有提出詳細的做法、或具體的步驟。第四，現存的方 法論並沒有考量到多元觀點往往會造成衝突，而沒有設計協助衝突解決的流程。
第五，現存的方法論通常沒有考慮維護需求可以在要求確定後，再根據後續階段 的回饋資訊來進行變更。
上述的現象可說具備下列的意涵。首先，具備詳細做法的單一方法論很難去 顧及所有類型的系統維護或顧及維護流程的所有階段。一個詳細的方法論比起概 略的方法論比較適合容易被想採用方法論的業界人士所接受，所以，比起概略的 方法論，針對特定系統維護類型與特定的維護流程階段來設計詳細的方法論是較
為可行的也較容易實施。第二，系統維護往往會與商業活動互相影響，而商業活