我們常常在CMMI裡看到"一致性(consistent/consistency)"這個詞，也要求在文件審查的時候，要特注意到一致性。請問，一致性的意思是什麼？在文件審查的時候，一致性要怎麼審查呢？

提供個人參與軍規系統發展的經驗供參考。當甲方需求明確之後就會編定WBS文件（後續由乙方制定work package），在美國國會未制定自願性共識法案之前（目前由乙方propose），甲方可選定各項流程所引用標準，諸如型態管理要依循MIL-STD-973或MIL-STD-480體係，當後續進行所謂Preliminary Design、Detail Design、Implementation、Integration、Testing Task時，對於Lower Level Specification就可以進行Traceability分析，俾往下追蹤不要漏掉合約規定該做的事項、也要做逆向的Traceability分析，不要夾帶不該有的Task (此對於Cost Type Contract非常重要)；每一項文件所使用的工程用語就必須求取與前述所規範標準相關定義的ㄧ致性，否則會產生Verification的困擾，諸如不同的軟體工程標準對於所謂的CSCI、Component、Module、Unit有不同的定義，如果未先求取與相關標準進行定義的ㄧ致性就會發生verification的困擾，其他諸如國內較少訂定的MTBF，也會發生不同的標準或不同的領域（美國甚至於陸海空軍對於同一名詞有不同的定義）有不同的計算方式、或是包括work package應撰寫內容會有出入。我曾經在去年親臨一項會議，當場發生雙方對於所謂的雲端運算的定義有極大差異的事實，因此雙方在無ㄧ致性之下就談不下去了。

在軟體發展專案中，一致/一致性(consistency)的判斷，其實也連帶影響到正確(correctness)與完成(或完備)(completeness)的判斷，尤其是對系統需求以降的發展文件。這類的文件，會隨著生命週期發展階段的推進、產品工程工作而演化，描述設計或應實作的結果。

所謂的"一致/一致性"，與"符合/符合性(conformance)"，兩者在意義正並不完全相同。conformance通常指產出或結果，對於格式、計畫、規定等的符合、遵循、順從。"符合"的認定，須有一明確、可見的準則(包括，格式、計畫、規定、程序步驟等等)存在，而"符合與否"的認定，並不太需要做推論，而是直接將所見事實與依據做比較。

"一致/一致性(consistency)"一詞，可能對於以英語為母語者，極為普遍，沒有模糊的地帶，故在工程或工程管理相關標準上，並無特別的定義，但也因為如此，使得非以英語為母語者，在一些文件或設計的審查上，"一致性"並沒有特別受到注意，而實務上以檢查：文件是否與格式相符合，用語是不是一致，描述的要求是不是符合寫作的規範...等等代之。

要瞭解consistency該做什麼，及如何運用在審查上，首先應從該字的意義入手，在英英字典裡，consistency的解釋是the state of always being the same in thought, behaviour,etc; keeping to the same principles.(在思想、行為等上，總是(保持)相同的狀態；或固守相同的原則)。將此字義應用在工作上，就可以知道，從事文件/設計審查，面對"一致/一致性"的要求時，應該關注的事項了。

透過一系列生命週期階段發展出來的產品，在各個階段所展現出來的，不論是什麼，對於"一致/一致性"，要注意的是產品的構想、行為、功能，是不是都被把握住了。舉個簡單的例子：

假設軟體發展專案，是要發展一個網頁式風險管理電子儀表板。在需求文件中述及：所有曝險率高的風險項目，以紅色代號顯示於儀表板上。在設計文件上，可能看到的是，對於高曝險率的風險項目以色碼"FF0000"來顯示；在實作的網頁應用(程式)上，則是要看到"FF0000"被應用在正確的場合中。

對於其他非工程設計文件的一致性審查亦是如此，如：

假設在契約或RFP中，規定了產品的發展，應採用螺旋式生命週期模型，則在專案管理計畫中，除了呈現螺旋式生命週期模型的圖片外，亦應看到根據此生命週期模型安排的活動、工作，專案的甘特圖，亦要體現出螺旋式生命週期模型的時程安排。

當掌握了一致/一致性所應該看到的情況後，就可以更進一步去考量文件裡的各項描述是不是正確，敘述是不是完成/完備了。

----------------
引文:

有關於軟體審查中，檢查表如何設計，以促使審查小組成員注意一致性的問題，可以參閱：
http://www.youtube.com/watch?v=FyHKUS_letY

----------------
引文: