評審

•  基本信息

CMMI是Capability Maturity Model Integration的簡稱，即軟件能力成熟度模型集成。由SW-CMM（軟件能力成熟度模型）演化而來。子模型分爲開發模型、服務模型、採購模型。咱們常說的開發模型。

•  宗旨和意義

 一個引領組織得到高績效運營的過程改進框架模型。不是一個單一的過程，而是集成了軟件工程、系統工程、項目管理、過程管理、供應商管理、集成產品開發、敏捷軟件開發等領域的最新實踐，是幾十年來全球軟件工程、系統工程的最佳實踐的總結。它把軟件工程過程當中的每一個可能的環節、步驟活動進行詳細的定義、規範，可是它並無告訴咱們應該怎樣作，而只是告訴咱們應該作些什麼（Not how to do, but what to do）。

• 能力級別

初始級Initial 、已管理級managed、已定義級Managed Defined 、量化管理級 Quantitatively、 持續優化級Optimizing，國內大部分三級？？？

初始級：大體是管理混亂，組織病態，我的主義，成功經驗不可複製。

已管理級： 大體是有穩定開發環境，項目可控，排除任務完成的隨機性，保證項目都會成功。

已定義級： 已經有適合企業和項目的標準流程。並把流程規範化。開始有項目經驗積累。

量化管理級：顧名思義，大體全部的結果可預測，全部過程可量化。

持續優化級： 數據挖掘與創新了。

• 過程域分類

開發模型分爲四大類22個小類。

4大類： 項目管理類、工程類、支持類、過程管理類。

22小類：

【項目管理類】 REQM需求管理、PP項目計劃、PMC項目監控、SAM供應商協議管理、IPM集成項目管理、RSKM風險管理、QPM量化項目管理。

【工程類】RD需求開發、TS技術解決方案、PI產品集成、VER驗證、VAL確認。

【支持類】PPQA過程與產品質量保證、CM配置管理、MA度量與分析、DAR決策分析與解決、CAR緣由分析與解決。

【過程管理類】OPF組織過程焦點、OPD組織過程定義、OT組織培訓、OPP組織過程性能、OPM組織績效管理。

• 角色簡稱

EPG ： 過程改進小組

OT： 培訓

CM： 配置管理

QA： 質量管理

需求：需求

開發：開發

測試：測試

• 開發人員的小冊子

Q1:   開發過程域？

A1： DAR/TS/PI/VER SP2.1/2.2/2.三、公共實踐GP。

Q2：是否知道組織級的方針，有沒接受過培訓？

A2： 有組織級的方針，對於開發來講主要有TS, PI, VER 方針，有接受過方針和過程的培訓。

Q3： 是否制定了計劃？

A3：制定了開發計劃。對整個項目劃分階段，每一個階段的明細任務落實到人頭，也按照前端後端對任務進行劃分。按照既定計劃進行開發。

Q4: 用到了哪些工具、資源？

A4：OFFICE、IDE集成開發工具idea|eclipse、數據庫客戶端鏈接工具navicat|toad、服務器鏈接工具xshell|SecureCRT、版本管理工具git、打包工具maven|ant、比較工具beyond compare、反編譯工具jad-ui,以及網絡上可靠的開源庫等。

Q5：你的職責是什麼？是否清楚定義？

A5：個人職責主要服務於項目的工程構建，包括詳細設計、概要設計的編寫，功能的編碼，系統的集成。

Q6： 都參加過哪些培訓？

A6：參加過CMMI的培訓，學習CMMI的宗旨和意義。參加過公司技術基礎平臺升級的培訓、參加過公司實用工具培訓、參加過公司業務範圍培訓。

Q7：過程有哪些產出？

A7:  git管理的代碼，詳細設計文檔，概要設計文檔，代碼，用戶操做手冊。

Q8：都有哪些人蔘與到了此項活動中？

A8：EPG、QA、PM、CM都是於此活動相關的人員。

Q9:  誰監控該過程?如何監控？

A9: 項目經理會進行監控，有周報，月報，里程碑報告。

Q10: PPQA是否審計過你的工做？

A10:  QA進行審計，有審計檢查單。根據文檔體系對風險和質量進行設計。

Q11: 高層有沒有參與過評審？高層經理是如何關注過程的？

 A11：高層經理會在立項時參加評審，也會參與里程碑報告，咱們項目內沒法解決的問題，也會回報給高層經理解決。

Q12: 是否遵循了組織的過程定義？

A12: 有裁剪，詳設和概設合併。

Q13:有沒提過改進建議？舉例說明提了一個什麼建議？

A13：有，第1、針對實現同一個功能，各個工程師有不一樣的實現方式，程序質量參差不齊。建議構建一個工具庫，只收納解決某個問題的可靠代碼插件。技能保證程序質量，也能夠提高工做效率。

----------------------------------------------TS【技術解決方案】----------------------------------------------------

Q14 ： 識別了幾個技術方案，如何進行識別的？

A14： 通常是制定兩個或兩個以上的候選方案，主要經過市場調研、技術分析和網絡搜尋等方式來制定方案，而且編寫測試DEMO驗證可行性。

Q15：選擇準則及其權重是怎樣制定的？

A15：選擇準則一般來自於客戶/公司高層的需求、約束、限制，好比：開發週期；開發成本；技術限制；性能要求等並根據這些準則的重要程度設定不一樣的權重。

Q16 ： 用什麼方法選擇技術方案？

A16：使用DAR方法進行技術方案的選擇。邀請專家根據評價準則對候選方案進行打分，得出每一個方案的最終分值，分數高的爲最佳方案。

Q17 ： 如何作設計的？ 

A17：根據需求->概設->詳計->編碼。

Q18：設計評審是怎麼作的？

A18：邀請專家經過會議的方式進行設計說明書的評審，有使用評審檢查單來評審。記錄評審發現的問題，並進行解決。

Q19：技術數據包包含哪些內容？如何使用技術數據包？

A19：技術數據包是編碼的基礎，使用技術數據包進行編碼工做。技術數據包包含項目計劃，需求說明書，設計說明書，編碼規範，接口設計原則等。業務方面嚴格按照需求說明書來進行功能實現，代碼質量方面嚴格按照編碼規範來完成。

Q20：如何設計接口？

A20：根據接口設計原則進行接口的設計，有單一職責、迪米特法則、依賴倒置原則、里氏替換原則、接口隔離原則、開閉原則。主要作到低耦合，高內聚。接口設計原則有可靠性，穩定性、可修改性、可測試性、易理解性、可擴展性等。接口包括內外部接口。內部接口：爲系統各模塊間的接口：外部接口爲系統與外部系統間的接口，以及集成、測試環境的接口等。

Q21：何時作製做、購買、複用分析？

A21：在設計階段進行製做、購買、複用分析。由於公司沒有把軟件外包出去，所以採購是不會考慮的，所以根據項目時間、資源、成本進行分析，若是有可複用的模塊或組件或進行優先考慮，若是沒有會進行開發。目前２個項目都是自行開發。

Q22：用什麼語言編碼？

A22：使用JAVA和React語言進行編碼。公司有提供編碼規範，對於新手要通過編碼規範的培訓與學習，一般在項目編碼前，開發人員會碰個頭進行編碼規範的約定，若是你們都很是熟悉則不用這個活動。

Q23：代碼評審是怎麼作的？單元測試是怎麼作的？

A23：代碼評審一般使用非正式的評審方式，例如，開發人員互查，項目經理檢查等。經過構造假數據、用SWAGGER或者POSTMAN 進行單元測試。

Q24：都編寫了哪些用戶使用的文檔？

A24： 操做手冊\安裝手冊\在線幫助\維護手冊等。

Q25：都編寫了哪些用戶使用的文檔？

A25：用戶手冊。

----------------------------------------------TS【技術解決方案】----------------------------------------------------

----------------------------------------------DAR【決策分析與解決】-----------------------------------------------

Q26：爲何要創建決策分析指南？哪些問題將要進行決策分析？

A26：創建決策分析指南的目的就是要澄清哪些問題須要遵循正式的決策流程，如中高風險的決策；引發進度延期達到必定百分比率或天數，如：15%，10天等；影響項目目標的達成；技術方案的選擇；可以重大的下降成本、提升質量、縮短開發週期、下降風險的問題；採購金額達到必定數值時須要決策，如30萬。

本身話：有風險可能、有延期可能、影響項目目標、技術方案選型、特別下降成本。

Q27：如何創建評價準則？

A27:評價準則通常爲：客戶需求；項目\組織環境影響；項目假設和約束；技術限制；風險；項目週期成本等限制，並根據準則的重要程度設定不一樣的權重。

Q28：如何識別的候選方案？識別了幾個候選方案？

A28：1.和相關干係人一塊兒頭腦風暴、研討會等，2.進行市場，技術調查研究，通常識別2個候選方案。

Q29：選用了什麼評價方法評價候選方案？

A29：專家討論打分法，評價過程記錄在《DAR評價表》中。

Q30: 如何進行的決策？

A30：選取三個專家，項目經理，開發人員，高層經理根據所定義的評價準則對每一個方案進行打分，而後計算每一個方案的最終得分，分數最高的爲最佳方案。

Q31 ： 最終選擇的方案是怎麼作決定的？是否考慮了選擇的方案相關的風險？

A31：選擇得分最高的方案爲最佳方案，選擇的方案記錄在DAR報告中。

----------------------------------------------DAR【決策分析與解決】-----------------------------------------------

----------------------------------------------VER【驗證】--------------------------------------------------------------

Q32： 如何準備同行評審？

A32： 首先，確認是一個正式的或非正式的評審，肯定評審專家，準備評審檢查單，發送評審通知，把評審材料和評審檢查單給評審專家進行提早預審，記錄預審發現的問題。以後進行會議進行評審。

Q33： 都（進行）參與過哪些同行評審？

A33：參加過項目計劃，需求，設計，代碼，測試用例，用戶手冊的評審。 在現場的評審的時候，評審專家一塊兒討論預審所發現的問題，並識別新的問題，記錄評審結果在評審報告中，跟蹤問題的解決。

Q34 ： 有沒有對同行評審的數據進行分析？

A34 ： 分析預審和正式評審所花費的工做量，評審材料的規模，和發現的問題數，計算評審效率：BUG數/人時和評審速率：LOC/h。

----------------------------------------------VER【驗證】--------------------------------------------------------------

-----------------------------------------------PI【產品集成】----------------------------------------------------------

Q35： 是否創建了集成策略？如何進行的產品集成工做？

A35：有產品集成計劃，肯定了集成順序和集成策略。（可跟據實際狀況做答，是一次性集成仍是增量集成？是邊集成邊測試仍是集成完後再測試，有沒有集成的前後順序？）

Q36：集成的時候都須要哪些環境，是怎麼準備的？

A36: 在集成計劃中肯定了集成環境，包括各類軟硬件工具、設備。

Q37:  項目/組織級的集成步驟是怎樣的？集成的入口、出口準則是怎樣的？

A37: 集成計劃中肯定了集成的步驟和準則。全部模塊均經過模塊測試後才能集成，出口就是經過冒煙測試。

Q38 : 如何管理接口？

A38: 接口做爲設計文檔的一部分也要歸入基線管理；當發生變動時要走變動流程。在項目的里程碑評審時要關注接口狀況，確保接口是完整的、正確的。

Q： 如何保證內外部接口是兼容的？是否評審了接口描述？

A：接口在需求和設計文檔中有定義，在進行需求和設計評審的時候就對接口進行了評審，來保證接口的完整性和覆蓋性。並經過集成測試確保接口的兼容性。

Q39 : 集成前是否確認過各個構件是否可用？如何進行確認的？

A39:集成前要確認各個模塊均經過測試，而後進行集成

Q: 如何作集成的？

A : 按集成計劃中定義的集成順序、集成步驟進行集成，從下到上（一次性集成）

Q40: 集成測試是怎麼作的？ 

A40: 一邊集成，一邊測試：

Q41: 交付前要準備什麼？交付的方式是怎樣的? 交給客戶哪些內容？

A41:

1.交付前的準備

    1.交付、安裝、操做環境要部署好

    2.評審需求、設計、產品、測試結果，確保打包交付的順利進行

2.交付的方式

    1.直接部署軟件/產品到用戶的使用環境中，由用戶試運行或驗收

3交付的內容

     打包的可執行程序、用戶手冊等支持文檔

-----------------------------------------------PI【產品集成】----------------------------------------------------------

E 1 : 過去一年中，CMMI改公司帶來的好處和壞處分別有哪些？或公司近一年的最大的改進？

E2：你想要看到什麼改進，如辦公環境，工做方式方法，企業文化等？