1.合約簽定時應明訂工程交付產出物(Products)，並在CDRL文件中載入Contract Products；要完成相關Products，便需要藉助相關Process完成，因此Products與Process架構出專案的主要活動，在專案的PMP (Project Management Plan)或SEMP (System Engineering Management Plan)也必須將此等Products與Process載入，這是說明 “what”的部份，同時在resource章節敘述由何項組織執行何項Products/Process，這是說明 “who”的部份；

2.專案由Risk Management以及Project Management角度進行規劃時，通常會將Process切割成Requirements、Design、Coding & Module Level Test、CSCI Integration Test等Phases，隨箸Phase的進行將完成Software Requirement Specification、Software Top Level Design Document、Software Detail Design Document、Source Coding、Software Transition Plan、Software User Manual、Version Description Document等Products，這是說明 “when”的部份；

3.要撰寫前述的Products或是CSCI documents，就需要參考Standards(例如Software Requirement Specification可參考IEEE-1233，一般而言美國政府已經不在RFP中訂定Standard(Valued Engineering除外)而由Tender在Proposal中自己敘述將參用的標準，因此參與專案的各個相關Process的Engineering Group須將可參用的Standards在PMP或SEMP中敘述（事實上應該在Management Proposal與Technical Proposal中已敘述），這是說明 “how”的部份；

4.文件撰寫完成後需要有審查與納管機制以達成建立baseline的動作，方可方便不同組織能夠依據此baseline document繼續往下一個phase展開後續的工程事項，因此要有Configuration Management的Baseline management程序(Procedures)，Procedures是屬於Process的 “Core part”，通常需要在Procedures中敘述entry criteria與exit criteria，每一家公司的組織架構不同，所以相同的Standard會產生不同的Procedures，Standard是可以是價購的，但Procedures無法由市面購得，Standard是可以放在Library，但Procedure要放在Organization Assets；

5.工程執行過程中會發生需求變更以及設計變更，因此需要有對於技術、時程、人力、預算、… 等變更影響的評估機制，以便在CCB中決定是否同意變更申請（包括軟體版本的配置），因此需要有CM的Change Management的制衡機制；

6.前述所言的軟體發展，如果由Phase的角度分析，Development的最後動作是要在CSCI完成Integration Testing後，確定可於相關的Products中Validate其滿足requirements或users needs，得以舉行Functional Configuration Audit (FCA) 並點收在合約書中所訂定的各項Products (可依據CDRL、CLINS點收)，FCA同時代表研發過程的結案，但如前述所言在發展過程中有可能發生Change requirement的情形，如果在申請需求變更時，專案已進入CSCI Integration Testing時，以標準程序(或Life Cycle)而言，此時的需求變更應被改納入New Block 或New Version而非revision，因此針對不同的CSCI Version會產生FCA1、FCA2、FCA3、…等，買方在量產時可基於成本、時程、架構、維修、市場、..等因素選定FCA2的購型並簽訂生產合約，同時在首批小量生產將CSCI+HWCI整合之實體購型(PCA)置於實體環境中測試其效能(FCA通常僅在Simulation Environment展示其符合requirement)，因此需要CM的FCA與PCA管制機制；FCA是依據軟體生命週期的Functional Baseline與Allocated Baseline之後所執行的Audit Procedures，PCA之後即完成CM的Product baseline；

7.以上所敘述的是工程團隊(Mechanization Team)，在完成products時必須配合CM所執行的Procedures，但是隨着軟體工程的執行，是否能順利的進入下一phase，必須藉助Verification的process以verify products是否可滿足Correct、Complete、Accurate、Consistent、Testable等目摽(Goals，參考IEEE-1012)，Verification可藉助Review、Analysis、Testing等方法(應該在technical proposal的VCRI中敘述，不同的方法會牽涉不同的成本)以確定前述之goals已於此階段完成，verification本身是屬於Project Management的Technical Discipline，其執行過程為(a)文件撰寫者完成初稿時交由Group或Organization的Senior Engineer進行初審(在CSCI Requirement範圍內)、(b)分會與介面相關的Group進行Peer Review、(c)呈送Project Office進行複審(跨多項CIs)，至於V&V的Validation是在Requirement Analysis phase時即由負責Validation的Testing group同時平行進行Test Evaluation Master Plan (TEMP)、Test Procedure、Test Case、以至Testing的執行，此Validation Process包括為了完成測試所必須發展或建置的Simulation Modeling Environment(有些測試是幾乎無法在實體環境中執行的)；

8.前述事項包括有工程發展Process、CM、V&V，每一項都有其應參用的標準(Standards)與程序Procedures，專案的Products與Process是否已依據Standard與Procedures執行，就必須由Quality Assurance (QA)進行Assurance的動作，但QA並無能力去進行確定Correct、Complete、Accurate、Consistent、Testable等工程事項，那些就交由V&V進行即可，但所有交付給客戶的Products都必須先經由QA簽署(完成7.的peer review之後)，再由PM簽署之後呈送CM核可，即可交付客戶，QA簽署之前必須先經由其他的Interfaced Group先簽署，因此在QAP中要敘述QA Group所必須檢視的CSCI products (要簽署文件)、review meeting (要參加會議)、V&V products and testing (要監控測試的執行)；

9.QA、CM、V&V、Mechanization Group都是針對同一個專案的Products，(a)Mechanization Group可依據IEEE-1063、830、1016、1471等Standards撰寫文件、(b)CM可依據IEEE-828進行Baseline、Change management、Audit等變更管理與稽核、(c)V&V可依據IEEE-1012進行V&V，以確定工程產物的Correct、Complete、Accurate、Consistent、Testable、(d)QA依據IEEE-730、PMP所敘述的Standards、Organization assets的Procedures進行與Products/Process相關之各項應執行Standards/Procedures的assurance，所以品質的第一道防線是專案訂定有完整的Standards，組織內有正確且嚴謹的Procedures，且工程人員願意配合執行(通常是公司不願意做)、第二道防線是由Verification確認工程的正確性(通常由老闆直接決定)、第三道防線是QA確定所有事項確實有依規定執行，（前三者屬於預防性(Prevention)）、第四道防線是藉由Validation找出defect(屬於disclose，但問題已存在，通常是想辦法遮蓋掉）。