2009年7月21日
|
MA
|
| |
|
2009-02-04 作者：人月神話 來源：網絡
轉載地址：http://www.uml.org.cn/cmm/200902043.asp
|
| |
|
度量過程框架:
度量和分析過程域包括：
- 詳細說明度量和分析的目的，使其與已標識的信息需要和目的一致
- 詳細說明度量、數據采集、存儲機制、分析技術以及報告和反饋機制
- 實現數據的采集、存儲、分析和報告
- 提供可用于作出可靠決策的客觀結果，并采取適當的糾正行動
將度量和分析活動與項目的其它過程集成，以支持：
- 客觀的計劃和估計
- 按已制定的計劃和目的跟蹤實際的性能
- 標識和解決與過程相關的問題
- 提供將度量合并到未來的附加過程中去的基礎
注意二級的度量集中在項目級別，項目可以把特定的項目數據和結果存放在項目專用的庫中。當數據在項目間廣泛共享時，數據可以駐留在組織級度量倉庫中。要建立組織級的度量數據庫，應該參考三級的過程域OPD組織過程定義，對于度量中的分析到了四級后需要使用統計學的相關方法和工具進行定量的分析，涉及到四級QPM量化項目管理過程域的內容。
SG 1 調整度量和分析活動(度量的目的和活動要與已標識的信息需要和目的相一致)
- SP 1.1 建立度量目的
- SP 1.2 詳細說明度量
- SP 1.3 詳細說明數據采集和存儲規程
- SP 1.4 詳細說明分析規程
在進行度量計劃和實施度量前，必須要搞清楚度量的目的，度量的目的是通過采集的數據分析，改進我們的過程的有效性，提高效率和改善質量。度量目的的來源可以是管理、技術、項目、產品或過程等方面實現的需要，來源于企業的戰略和商業計劃，項目計劃，管理和技術問題，過程改進計劃等。
關于度量信息的分類，可以分為
- 進度和進展（里程碑的實現和工作單元的執行情況）
- 資源和費用（項目分配的人力資源和其它費用）
- 產品規模和穩定性（軟件的規模，軟件功能范圍和數量的變更）
- 產品質量（缺陷密度，現場缺陷）
- 過程性能（評審效率，缺陷泄露情況，過程符合度，不合格項）
- 技術有效性（軟件架構和軟件重用）
- 客戶滿意度（交付的產品與服務滿足客戶期望的程度）
在SP1.2重點是度量本身要是精確的，可量化的度量。度量可能是基本度量，或者是派生度量。基本度量數據由直接度量獲得。派生度量數據來自其它數據，通常是由兩個或多個基本度量組合而來。如缺陷數是基本度量，而缺陷密度則是派生度量。
在建立了度量的目的和確定了度量的方法后，進入SP1.3要解決度量數據的收集，度量數據的存儲兩個問題。要明確地說明數據如何采集，從何處采集，和何時采集。要指定采集有效數據的規程。為了分析數據，數據要按可訪問的方式存儲，并且要確定是否為可能的重新分析或文檔目的而保存。
當采集和存儲了數據后，就需要選擇合適的數據分析方法和工具，到了QPM量化管理后就會更加強調對于不同的子過程該采用哪些統計學的方法和工具。
SG 2 提供度量結果以處理已標識的信息需要和目的
- SP 2.1 采集度量數據：獲得特定的度量數據
- SP 2.2 分析度量數據
- SP 2.3 存儲數據和結果
- SP 2.4 交流結果
注意在SG1是制定具體的方法和規程，在SP2是實際的度量執行活動。在SP2.1首先是按照度量規程采集我們需要度量的活動的執行數據，在數據采集到后必須對數據進行完整性的檢查，以保證數據的準確有效。度量很多時候無效或沒有起到實際的作用，最大的原因不是在于度量的方法和工具上面，而是在于我們采集到的數據本身是不準確或錯誤的，導致最終分析出來的結果也是錯誤的。
在SP2.2是講按照計劃對度量數據進行分析，必要時要進行額外的分析，結果由有關的項目相關人員評審，并指出將來要對分析作必要的修訂。在完成了度量數據的采集和分析后，我們需要對度量后的數據進行存儲，以作為項目的歷史數據后續可以作為項目計劃和估算的重要參數。
度量數據的存儲主要包括了：
- 度量計劃
- 度量的規格說明
- 已經采集的數據集
- 分析報告和陳述
在二級項目的度量數據主要是服務于項目和個人的需要。到了三級后項目度量數據要存儲到組織級的度量數據庫中，以方便建立組織級的度量基線。具體內容在三級的OPD過程域。
SEI建議的度量元
- 進度性能（里程碑性能、工作單元進展）
- 成本性能（實際與計劃的對照，不一致情況）
- 工作量性能（實際與計劃的對照，不一致情況）
- 需求管理（增加的、刪除的、修改的，需求易變性）
- 程序規模（源碼行數、頁數，實際與計劃的對照）
- 測試性能（需要的測試，通過的測試）
- 缺陷數據狀態（未解決的問題，解決完成的問題，缺陷密度，缺陷來源）
- 過程性能（完成的任務，行動項數）
- 計算機資源利用率（內存占有量，CPU占有量）
- 管理計劃項目過程的性能（對照實際進展做估計，重計劃，項目總結數據）
在三級我們主要到度量要上升到組織級，在GG3中也談到要將度量活動制度化為組織級已經定義的過程，組織可以通過各個項目度量數據的收集來建立組織過程能力基線。在四級中注意重點是度量需要到我們需要監控的各個子過程粒度，同時在度量數據分析的時候需要采用統計學的相關方法和工具進行。具體一些CMMI四級中涉及到度量的要求:
- 根據商業目標確定項目目標，根據項目目標
- 根據質量性能目標選擇最有價值的子過程進行量化管理，粒度到子過程
- 采用統計學的方法和思想而不僅僅是應用SPC
- 可以應該QFD逐層分解來選擇度量技術和子過程
- 度量是使過程受管理的基礎，而不僅僅是為將來收集和跟蹤數據
- 更好的根據過程能力基線PPB管理當前項目性能，過程受控
- 更好的根據過程能力模型PPM預測將來
|
|
{背景}基礎培訓和差距分析的工作已經結束了，感覺和我想象的有點出入...
一、差距分析
內容：過程改進的模型、通用實踐和特定實踐。
收獲：1、我做了錄音，有點細節還是值得再一聽的
2、說的好粗，有待于在專題培訓上面再加強
3、最郁悶的是我的練習沒有獲得附加分且2個多選題寫錯了....
二、差距分析
內容：以訪談的形式對各個角色訪談最后出個差距結果
任務：1、給我布置了整理文檔，這周末就會過來評審
2、早點熟悉，盡快熟悉....
歷時一個月，某些事的塵埃落定：
1、關于合作的咨詢公司：選好且已簽了合同，本周日開始啟動儀式...
2、關于我的學習：理論知識是了解了一些，但是看到場景分析題時仍是束手無策，不會做，而且發現有關軟件質量管理的文章和書籍都很少，好不容易找到一本，看了以后，仍是沒有理清楚書上說的解題思路...
3、學習計劃：走一步看一步，但是每步都要走好！
{背景}公司有過3級的打算，我覺得其實不是為了提高管理的效率去引進CMMI3,有很大的原因是看上了政府的補貼吧O(∩_∩)O~
前段時間就和我說過，想讓我來接這份工作...（不得不接，沒啥思考的余地-_-|||）
這幾天的工作的內容就是約咨詢公司過來了解情況和在網上搜索資料，多找點資料是對自己有利的，在一大堆的事實面前，我已經從剛開始的興奮逐漸退化，但還是不能否認這是個很好的學習機會...
希望自己在這個過程中能全心投入和思考，做到收獲的最大化...
一、軟件需求的來源：
1、項目：由固定客戶以合同或契約形式提出；
2、產品：企業內部市場人員通過對市場上潛在的客戶要求整理得到；
二、影響軟件質量的因素：
1、流程：SQA從流程方面保證軟件的質量；
2、技術：測試從技術方面保證軟件的質量；
3、組織：保證內部協調工作；
三、CMM與CMMI的區別：
1、適用范圍：CMM適用于軟件行業，CMMI加入了部分硬件；
2、表達方式：CMM是階段式的，CMMI是階段式+連續式的；
3、關注點不同：CMMI關注過程，關注需求、過程的度量；
4、CMM是做為評估標準出現的，CMMI是做為過程改進出現；
四、企業如何選擇哪種質量標準：
1、看企業的業務特點：純軟件、規模小的最好選CMM，軟件+硬件且規模大的選CMMI；
2、看企業本身對質量管理的態度：未有良好的質量意識的，最好選CMM，如果有質量意識，能自發的執行的，選CMMI；
3、根據公司預算：金額較少的，選CMM，金額較多的，選CMMI；
4、看想在那方面提高，如果想在過程控制方面提高，選CMMI；
5、對已做過CMM，要提高利益最大化的，建議做CMMI；
五、SQA的主要工作范圍：
1、指導并監督項目按照過程實施；
2、對項目進行度量、分析，增加項目的可視性；
3、審核工作產品，評價工作產品和過程質量目標的符合度；
4、進行缺陷分析，缺陷預防活動，發現過程的缺陷，提供決策參考，租金過程改進；
六、SQA應具備的技能：
1、熟悉過程改進體系；
2、精通軟件質量工程；
3、熟悉業務背景；
4、軟件技術能力，自身的學習能力、動手能力；
5、良好的溝通能力；
七、SQA主要工作方法：
遵循質量管理PDCA（Plan計劃、Do執行、Check檢查、Act改進）循環。
八、軟件度量四個基本度量項：
1、規模（size），軟件工作產品的大小，如SRS文檔頁數、HLD文檔頁數、LLD文檔頁數、代碼量（KLOC）、UT用例數、IT用例數、ST用例數等等；
2、工作量（effort），完成各軟件工作產品和活動所用人時（或人天等），如SRS所用人時數、HLD人時數、編碼人時數、ST測試人時數等等；
3、進度（schedule），各軟件工作產品和活動開始和結束時間；
4、質量（quality）、缺陷（defect），在各軟件工作產品和活動中產生的缺陷數，SRS評審發現缺陷數、HLD評審發現缺陷數、LLD發現缺陷數、ST發現缺陷數等等。
本文出自suiyuxiu的51Testing軟件測試博客：http://www.51testing.com/?134368
{背景}入職三個月了，在此記錄下我的工作歷程。
測試項目：
1、投行管理系統（4.21-5.24）
{測試背景}這個項目是公司早已完成的作品，提供給我們的就是一份簡單的使用說明書和已經寫好的系統，本打算要寫測試用例的，可BOSS要我們三個8天測完，所以我們沒有寫測試用例，就這樣測了下去，實際上5月后我和另個同事又繼續測了三周，這才結束。
2、OA和PM項目綜合管理（5.25-6.11）
{測試背景}內部使用的系統，3人前后花了2周時間；
3、PCBERP(6.12-至今）
{測試背景}系統已在線上，此次是增加一些新的功能；
工作的內容：
1、對所分配的模塊執行測試，測試類型只含功能測試和業務流程測試，功能測試的方法多為邊界值，業務流程測試也只是想到哪就測到哪,沒有做任何的文檔記錄；-_-|||
2、回歸bug，每天提交測試日志。
工作的改進：
1、編寫測試用例和及時補充更新測試用例；
2、認真仔細了解每項工作內容。
下個月（八月）學習安排：
1、完成對C的學習；
2、每天堅持聽2小時的英語，且周末加強學習；
3、開始學習QTP；
4、繼續學習有關測試用例的內容。
{背景}今晚，公司的測試顧問抽空過來給我們這些測試解疑答惑！
1、如何高效的編寫測試用例？
答：從三方面入手：
1）功能點
覆蓋全部的功能點，至少編寫測試點用例（增加、刪除、搜索等）；
2）業務流
所有的流程都要理清楚，適當考慮 場景法；
3）通用的測試用例
記得一定要適時補充。
備注：業務邏輯非常容易出bug
2、在時間較緊的情況下，是否也要編寫測試用例？
答：至少寫測試大綱（個人寫分配的模塊，然后再評審）
包含的內容有：
1）功能點
2）業務流
3）時間
4）測試的完整
3、職業發展的要求
1）基本能力
測試思路、測試邏輯、發現bug的能力
2）QTP
邊看幫助文檔邊實踐
3）有空了解 數據庫的使用、linux技術和網絡技術
記得很清楚，08年的3月份在報紙看到了職業的介紹，晚上就培訓班報了名，接待的工作人員都說我是下決定最快的，畢竟是要面臨一筆不菲的培訓費…緊接著就開始了周末上課，這種狀態一直持續到12月份，年底的蕭條也讓本來比較好找工作的軟測也面臨了不小的尷尬，我沒有找到工作..
年后也是這樣不慍不火的，我一邊編著各種理由去請假找工作，一邊堅持著原來的工作，有一天面試回家的路上，做了個大決定：還是辭職吧，專心找軟測工作！還好，一切還算順利，4月21日找到了新東家，雖然離家有點遠，但我起碼找到自己的新起點。
今天是7月21日，三個月前我找到了自己的第一份測試工作！
注冊這個帳號是為了記錄自己的工作歷程，踏實激進的走好每一步，所以，加油！
接下來要完成的內容是自己三個月的總結報告！