【正文】 何種情況下采取何種措施和方法等說明。 ? 質(zhì)量控制度量結(jié)果。應用與質(zhì)量計劃制定過程的工具和方法也基本適用于質(zhì)量保證過程。 ? 項目質(zhì)量管理計劃。 包括度量、考察、測試、對比等。對項目實際執(zhí)行情況的統(tǒng)計。 ? 趨勢分析。 ? 可接受的決定。 ? 檢查表。 軟件質(zhì)量管理的實施 定義過程 開發(fā)產(chǎn)品 評估產(chǎn)品質(zhì)量 改正過程 過程標準化 N Y 合格？ 圖 軟件質(zhì)量管理貫穿產(chǎn)品生產(chǎn)的全過程 軟件質(zhì)量管理的實施 遵循以下一些基本原則 ： ? 控制項目所有過程的質(zhì)量。 ? 有效的質(zhì)量體系應滿足顧客和組織內(nèi)部雙方的需要和利益。 ? 確定軟件產(chǎn)品中不需要或者不希望改進的部分。 ? 管理評審。 個人或者小組的工作由評審小組進行評審。 軟件項目評審階段 選擇評審小組 安排地點時間 分發(fā)文檔 評審 通知和完成 評審表格 圖 評審過程 軟件項目評審的作用 原始要求 正確的規(guī)格說明 錯誤的規(guī)格說明 需求分析 正確的設計 錯誤的設計 對錯誤說明的設計 正確的編碼 錯誤的編碼 對錯誤說明的編碼 對錯誤設計的編碼 正確的功能 可改正的錯誤 潛伏的錯誤 不可改正的錯誤 不完善的產(chǎn)品 設計 編碼 測試 圖 錯誤“積累”及“放大”效應 不符合需求的產(chǎn)品 可行的產(chǎn)品 軟件項目評審的作用 表 需求階段錯誤對后期的影響 階 段 錯誤擴張倍數(shù) 需求分析階段 1 設計階段 (概要 、 詳細 ) 3~6倍 編碼階段 10倍 集成測試階段 15~40倍 系統(tǒng)測試階段 30~70倍 運行 40~100倍 小組的度量包括內(nèi)容： 1）多個人開發(fā)的軟件主要功能的缺陷數(shù)量 2）正式技術評審中發(fā)現(xiàn)的缺陷率（正常和缺陷的比例） 3）正式技術評審中度量的工作量（人員、時間） 等等 項目小組的過程度量來源與個人，但結(jié)果決不應該歸因于個人 軟件度量禮儀： 度量如果被務用，會產(chǎn)生更大的問題，因此提出“ 軟件度量禮儀” 1）解釋度量數(shù)據(jù)使用通用的觀念，考慮組織的敏感性 2）收集個人或小組的測量要定期反饋 3）不要用度量去評價個人 4）要討論共識的度量指標 5）不要用度量威脅個人或小組 6）度量數(shù)據(jù)不要作為否定什么的論據(jù)，應強調(diào)它用于改善的目的 7）不要糾纏某個度量而忽視了其他更重要的度量 軟件的錯誤來源 通常包括： (P60) ? 來源于處理邏輯 ?來源于數(shù)據(jù)處理 ?來源于標準化處理 ?來源于規(guī)約（規(guī)定和要求） ?來源于用戶界面 ?來源于錯誤檢測 ?來源于硬件接口 ?來源于軟件接口 用餅圖給出分析結(jié)果的例子 123軟件接口 6% 硬件接口 % 錯誤檢測 % 用戶界面 % 規(guī)約 % 標準 % 數(shù)據(jù)處理 % 邏輯 20% 1需求 2設計 3編碼 用魚骨圖表示錯誤或缺陷的原因的例子 規(guī)約缺陷 遺漏 二義性 選擇了錯誤的用戶進行調(diào)研 不夠充分的調(diào)研 使用過時的信息 不正確 變更 （ 5）軟件質(zhì)量度量 影響軟件質(zhì)量的 3個主要因素： ?操作：軟件產(chǎn)品的操作使用 ?修改：軟件產(chǎn)品的修改 ?變遷：軟件產(chǎn)品的環(huán)境改變 軟件測量的基本指標： ?正確性 ?可維護性 ?完整性 ?可用性 軟件質(zhì)量度量的重要指標：缺陷排除效率（ defect remove efficiency DRE） DRE = E /（ E + D）（ E交付之前發(fā)現(xiàn)的錯誤數(shù)； D交付后所報告的缺陷數(shù) ） 理想的情況是： DER= 1，即是： D=0?？删S護性軟件與不可維護軟件相比， MTTC （ meantimetochange）平均修改時間較低 完整性 完整性 =?[1 威脅性 ? (1 安全性 )] 威脅性：規(guī)定時間內(nèi)某類型攻擊的可能性 安全性：對某類型攻擊的擊退可能性 可用性 量化“用戶友好性”。 軟件度量計劃 ?確定業(yè)務目標 ?明確想要研究的內(nèi)容 ?確定子目標 ?確定子目標的實體和屬性 （使用資源、工作產(chǎn)品、源代碼、測試案例、修改請求、工程任務、進度安排） ?確定測度的目標 ?確定可量化的問題和相關的指標，可用它們來幫助實現(xiàn)測度 ?確定以上問題的指標和元素的指標，它們可以對收集測量有幫助 ?定義可操作的測量 ?確定實現(xiàn)測量的動作 ?準備實現(xiàn)測量的計劃 例：家庭安全系統(tǒng) 業(yè)務目標： ?通過產(chǎn)品改善用戶的滿意度 ?系統(tǒng)易于使用 ?縮短新產(chǎn)品推向市場的時間 ?提供對產(chǎn)品技術支持的手段 ?改善整體收益率 采用“目標驅(qū)動”的軟件度量計劃方法： ISO9000與 CMM 二者相關性和不同點 ， 參見教材 p125表 : ? 二者之間的 相關性是很明顯的 ： 都著眼于質(zhì)量和過程管理 ， 兩者都為了解決同樣的問題 ， 直觀上是相關的 。 關鍵點 ： 項目人力資源管理的關鍵 解決方案 問題 局部解決方案 新知識 現(xiàn)存知識 經(jīng)驗和專業(yè)知識 圖 問題解決過程 軟件項目中人員的工作方式 ? 一個項目的成功，首先必須是每個項目組成員的成功，其次是項目組成員協(xié)作的成功。 這種類型的人員被工作本身所激勵，在軟件項目里，他們是那些被挑戰(zhàn)軟件開發(fā)智能所激勵的技術人員。 ? 面向合作型。 團隊領導 ? 權力 —— 發(fā)命令的正當?shù)燃墮嗔Α? ? 資金 —— 給員工漲工資和增加福利的權力。 ? 友誼 —— 項目經(jīng)理和其他人之間建立良好人際關系的能力。 項目團隊交流 ? 團隊規(guī)模的大小。 影響團隊里成員之間交流的主要因素有： 項目團隊交流 (a) 星型結(jié)構(gòu) (b) 網(wǎng)狀結(jié)構(gòu) 圖 團隊的交流方式 團隊發(fā)展的階段 ? 1. 形成期 。 成員們開始運用各自技能著手執(zhí)行分配到的任務 ， 開始緩慢推進工作 。 項目團隊積極工作 ， 共同實現(xiàn)項目目標 。 然而 ， 激勵并不是一種簡單的刺激行為 ， 而是一個復雜的過程 ， 即從感覺到的需求出發(fā) ， 由此引起要實現(xiàn)的目標 ， 隨即產(chǎn)生一種實現(xiàn)目標的動機和一系列的行動 ， 最后滿足了自己的需求 。隱性知識深深地植根于行為本身，植根于個體受到的環(huán)境約束 知識轉(zhuǎn)化 ? 人類知識是通過隱性知識和顯性知識之間互相的社會作用來進行創(chuàng)造和傳播 ? 顯性知識需要大量的科學分析，所以過分強調(diào)顯性知識只會使自己步履維艱 ? 隱性知識的夸大會使自己固步自封 識別和理解人 ? 了解一個人對用好一個人至關重要，因為人們發(fā)現(xiàn)人的某些特征是不可改變的，而這些特征決定了一個人可以做好哪些事情，不可以做好哪些事情 ? 而其中對這一特質(zhì)的研究就集中在人格上 人格 Personality ? 心理學家談論人格時，指的是個體整個心理系統(tǒng)成長和發(fā)展的動力概念 ? Gordon Allport的定義：個體內(nèi)部身心系統(tǒng)的動力組織，它決定了個體對環(huán)境獨特的調(diào)節(jié)方式 ? 從管理的角度上說，人格是指個體所有的反應方式和與他人交往方式的總和。在產(chǎn)品構(gòu)造以前的期間內(nèi)的交流大都是無形的工作產(chǎn)品交接，例如，設計思想，核心需求模式 ? 現(xiàn)代的工程化技術試圖使這部分的無形轉(zhuǎn)變成有形的可度量的產(chǎn)品 ? UML 知識的交流 ? 協(xié)作的關鍵：知識在團隊內(nèi)部有效的傳播 ? 顯性知識：規(guī)范化，系統(tǒng)化，易于溝通和分享。 解決問題的步驟 ? 對問題做出說明 ? 找出問題的可能原因 ? 收集數(shù)據(jù) ， 確定最有可能的原因 ? 得出可能方案 ? 評估可行方案 ? 決定最佳方案 ? 修訂項目計劃 ? 實施方案 ? 判斷問題是否得以解決 團隊沖突根源 ? 1. 工作內(nèi)容 ? 2. 資源分配 ? 3. 項目成本 ? 4. 先后次序 ? 5. 組織問題 ? 6. 個體差異 團隊沖突處理 處理沖突的 5種方法： 回避 、 妥協(xié) 、 競爭 、 迎合 和 合作 確定的 回避 競爭 妥協(xié) 合作 迎合 企圖滿足他人關心之事 不確定的 不合作 合作 不同對策的結(jié)果 沖突一方的滿意程度 僵局 贏 /輸 妥協(xié) 雙贏 輸 /贏 沖突另一方的滿意程度 圖 沖突管理的 5種可能結(jié)果 激勵的概念 激勵 ， 簡單地說就是調(diào)動人的工作積極性 ， 把潛力充分發(fā)揮出來 。 團隊成員之間 、 團隊與項目經(jīng)理之間的關系已經(jīng)確立 ， 絕大部分個人矛盾得到解決 ， 項目團隊接受了特定的工作環(huán)境 ， 項目規(guī)程得以改進和規(guī)范化 ， 控制及決策權從項目經(jīng)理移交給了項目團隊 ， 凝聚力開始形成 ， 有了團隊的感覺 ， 每個人都覺得自己是團隊的一員 ， 他們也接受其他成員作為團隊的一部分 。 ? 2. 震蕩期 。 ? 團隊成員的地位和個性。 ? 團隊忠誠的另外一個結(jié)果就是“集體思維”。 ? 工作挑戰(zhàn) —— 根據(jù)員工完成一項特定任務的喜好來安排工作的能力，這是一個內(nèi)在的刺激因素。 ? 預算 —— 感知到的項目經(jīng)理授權他人使用自由支配資金的能力。直到現(xiàn)在在軟件項目開發(fā)中還沒有很多這種類型的人員，因為在這個過程中明顯缺乏人員之間的交互活動。 這種類型的人員主要被自我的成功所激勵。 ? 對團隊動態(tài)的理解能幫助軟件項目經(jīng)理和軟件工程師在一個團隊里工作。 ? 項目人力資源管理概述 ? 項目團隊建設 ? 項目團隊的沖突管理 ? 團隊的激勵 ? 組織計劃 六、人力資源管理 項目人力資源管理 主要過程包括：組織計劃編制 、 人員獲取 、 團隊建設 3個階段 9項基本活動 。畫圖 。缺陷是發(fā)布后的軟件在標準的給定期限，所報出的使用與需求不符的缺陷 可維護性： 錯誤容易修改；環(huán)境變化容易適應。這種類型的評審和設計與代碼檢查不同，因為系統(tǒng)不可能被詳細地描述。管理評審是重要的項目檢查點，在這些檢查點上，經(jīng)常做一些關于項目將來開發(fā)計劃或者產(chǎn)品生存能力的決策。 軟件項目評審的基本概念 軟件項目有以下幾種類型的評審： ? 設計或者程序檢查。 ? 搞好質(zhì)量管理的關鍵在于領導。 ? 質(zhì)量管理的中心任務是建立并實施文檔化管理的質(zhì)量體系。 ? 過程調(diào)整。 ? 返工?？梢杂糜诒O(jiān)控項目的技術參數(shù)，例如，一般規(guī)模的軟件存在多少個錯誤以及多少識別和修改，多少錯誤仍然未被發(fā)現(xiàn)等；也可以用于對費用和進度參數(shù)的預測。 包括原因結(jié)果圖、系統(tǒng)流程圖、處理流程圖等。 監(jiān)控項目的進度和費用變化、范圍變化的幅度和頻率、項目的其他管理結(jié)果等。 ? 檢查表。 軟件項目質(zhì)量保證 《 軟件質(zhì)量保證計劃 》 : 1. 計劃目的 2. 參考文獻 3. 管理 組織 任務 責任 4. 文檔 目的 要求的軟件工程文檔 其他文檔 5. 標準和約定 目的 約定 7. 測試 8. 問題報告和改正活動 9. 工具 、 技術和方法 10. 媒體控制 11. 供應者控制 12. 記錄收集 、 維護保密 13. 培訓 14. 風險管理 6. 評審和審計 目的 評審要求 軟件需求的評審 設計評審 軟件驗證和確認評審 功能評審 物理評審 內(nèi)部過程評審 管理評審 軟件項目質(zhì)量控制 依據(jù) : ? 項目的階段工作成果。 ? 操作說明。 各種檢查表是記錄項目執(zhí)行情況和進行分析的工具，既可以簡單，也可以復雜，但需要項目小組形成一種較標準的體系。質(zhì)量計劃提供了對整個項目進行質(zhì)量控制、質(zhì)量保證及質(zhì)量改進的基礎。對于軟件開發(fā)，設計原型解決核心技術問題和主要需求也是可行和有效的。 流程圖是一個由箭線和結(jié)點表示的若干因素關系圖，可以包括原因結(jié)果圖、系統(tǒng)流程圖、處理流程圖等。質(zhì)量管理的基本原則是效益與成本之比盡可能大。 ? 軟件需求中通常有一組“隱含需求”是很少被提及的，如對易維護的要求，如果軟件符合了明確需求卻沒有滿足隱含需求，軟件的質(zhì)量仍然值得懷疑。 ? 項目的標準及規(guī)格等。 ? 有效的工程技術。 檢驗 統(tǒng)計質(zhì)量控制 質(zhì)量保證 質(zhì)量管理 全面質(zhì)量管理 圖 質(zhì)量管理發(fā)展階段 全面質(zhì)