Archive for Quality Management 質量管理

Affinity Diagram 親和圖

Affinity Diagram, 親和圖:乃品管新七大手法之一﹐用來將大量的構想﹑觀念﹑對策等整理﹐將類似的想法等歸為同一類﹐以利進一步的分析﹐進而找到對策﹐親和圖常常用在腦力激盪法之後﹐用來整理龐大﹑無章的眾多想法﹐最後收斂到少數幾個可行的方案。此方法為Kawakita Jiro所提出﹐所以又稱為KJ Analysis

  • 將大量腦力激盪下的意見加以分類與編組,以供審查與分析的圖形。
  • This technique allows large numbers of ideas to be sorted into groups for review and analysis
  • used to visually identify logical groupings based on natural relationships

發表迴響

質量管理之工具與技術

  1. Cost-benefit analysis
  2. Cost of quality
  3. Control charts
  4. Benchmarking
  5. Design of experiments
  6. Statistical sampling
  7. Flowcharting
  8. Proprietary quality management methodologies
  9. Additional quality planning tools
  10. Plan Quality and Perform Quality Control tools and techniques
  11. Quality audits
  12. Process analysis
  13. Cause and effect diagrams
  14. Histogram
  15. Pareto chart
  16. Run chart
  17. Scatter diagram
  18. Inspection
  19. Approved change requests review

發表迴響

Cost of quality 品質成本

所謂品質成本 (Cost of quality, COQ) 非指製造合乎品質產品之成本﹐而是指製造不良品所需付出的成本﹐一般稱之為失敗成本﹐是為品質總成本的一部份﹐常見的例子如下:

  • 製品的重工 (Rework)
  • 重新測試
  • 回收﹑修復等成本﹐又可稱為外部失敗成本

(Cost of quality) 係指所有努力達成產品/服務品質而需耗的總成本;它包含確保符合需求以及更正未符合需求所做的所有工作。其中有三可能會發生的成本:預防成本、評鑑成本、及失敗成本;而後者還可以分解內部成本及外部成本。85% 的品質成本是管理階層的直接責任。

Cost of conformance

  • Quality training
  • Studies
  • Surveys

Cost of nonconformance

  • Scrap
  • Rework
  • Inventory cost
  • Warranty cost

發表迴響

項目質量管理十要點

項目質量管理要遵循質量管理體系,管理層在項目開始之前要製訂項目質量管理計劃和標準,並且在項目執行過程中要保證相關利害關係者都要知道本項目的質量管理標準。項目質量管理十要點則高度濃縮了項目質量管理體系的精髓觀念:

  1. 客戶導向。就是以客戶為中心,把客戶的滿意度作為質量標準的尺子。這是ISO-10006體系的首要原則:鑑於顧客是組織的存在之本,因此組織不但應該了解顧客當前的需求,而且要了解其未來潛在之需求,不但要盡力滿足顧客的需求,並爭取超越顧客的期望。一些國際著名公司甚至提出,客戶的滿意度只能說明質量及格,只有超越客戶的期望值,才能獲得客戶對品牌的忠誠。蓋洛普曾經對客戶的滿意度作過一個調查,結果表明客戶的滿意度可以分為三個層次:
    • 提供的服務或產品可以達到安全、準時、便捷的效果;
    • 與客戶建立夥伴關係,提供個性化的產品功能及服務;
    • 通過互動反饋參與客戶的決策,為客戶提供諮詢幫助。
  2. 過程管理。就是將質量管理的關注點從結果檢驗轉變為過程監控。這種過程管理體現在兩個方面:
    • 在時間坐標上,將整個項目實施視為一個工作任務銜接的流程,通過對工作流程的分析,識別和精簡那些無效益的工作環節,理順分工的接口,形成目標合力,減少扯皮內耗。在流程鏈條上建立相互監督機制,讓每個工作環節的下游工序都變成上游工序的客戶,依次對上游進行質量監督。
    • 在空間坐標上,將整個項目實施視為一個各類資源的集成活動,通過對相互依存的組合要素的分析,識別並優化各類要素功能指標,在其銜接的接口處嚴格把關,加強溝通,分享信息和技術資源,確保最終產品的質量標準。
  3. 選對質量標準。企業在體制上需要採用休哈特、戴明、朱蘭、石川、田口等人所創立的質量管理理論,在組織中建立有效的質量管理體系。但是在在具體的項目過程中,則需要採用克勞斯比的理論,努力第一次就將事情做好。項目的質量管理與常規質量管理的區別就在於:項目的質量管理是在驗證了前一過程的質量以後,才會開始進行下一個過程。企業的項目實踐也證明了上述觀點,無論是軟件項目還是工程建設項目的質量管理模式,其共同的特點是在質量計劃中確定質量管理的組織機構、工作職責、工作程序、配置資源、確定各個項目階段的驗證標準。在實施中比照階段的質量標準,驗證項目階段的質量狀態和控制項目質量基準的變更。
  4. 管理層重視。體現了質量管理在整個項目管理中的戰略地位,甚至可以說項目的質量在很大程度上取決於最高領導的重視程度。只有最高領導掛帥,才能決定項目的質量方針,才能製定質量計劃並確保計劃落實,才能動員全員參與,才能調動並配置資源,才能定期評審質量管理體系,才能驅動質量的持續改進。
  5. 實數求據。就是任何有效決策都不能憑主觀的概念和假設,而必須以事實為依據,必須建立在量化分析的基礎上。明確規定收集績效數據的渠道、種類、時間和職責,確保數據信息的精確可靠,用正確的方法進行統計分析,並及時送達信息需求者(如領導、客戶、投資人等),作為決策的依據。
  6. 全員參與。說明質量問題不僅僅是質量檢查人員的職責,而是人人有責。團隊的每個成員都要以主人翁的心態認識自己的工作使命,加強內部溝通,識別容易出現質量風險的職責邊界,把質量責任落實到每一個具體的人頭上,並且通過培訓把不斷提高工作質量變成一種自覺的行為。團隊精神在項目質量管理上也要充分體現,成功的項目都比較強調團隊精神、合作精神,應該說,項目管理流程本質上就要求員工之間的互相協調和理解。
  7. 供方互利。指與上游供應商建立長期互利的合作夥伴關係。放棄單純以價格指標決定採購的政策和殺雞取卵的短期行為,開放與供應商的溝通渠道,相互信任,共享技術成果及商業信息,聯手進行質量改進活動,在合作雙贏的基礎之上謀求雙方長遠利益的最大化。
  8. 持續改進。就是把追求質量精益求精作為組織永恆的目標,不斷識別改進機會,不斷提高質量目標,不斷採取改進措施,從而實現質量的螺旋上升。
  9. 使用恰當的工具。項目質量控制7工具是必須要熟悉的,包括在什麼場景下應該使用何種工具。因果圖(關照問題的根源),控製圖(關注偏差),帕累托圖(2/8原則關注關鍵問題),散點圖(進行相關性分析),流程圖,直方圖和趨勢圖。
  10. 連續循環培訓制度。在很多公司,通常只有很少甚至沒有培訓,員工們不知道何時才能正確的完成他們的工作。消除不適合的培訓是非常困難的。質量管理大師Deming強調:只要工作成果還無法受到統計控制,並且還能獲得更大的好處的時候,培訓就不應當被中止。
    為了應用該原則,一個質量保證組織可以:
    • 建立現代的培訓輔助和實踐
    • 鼓勵質量工作者通過參加研討班或上課不斷的提高質量和測試方面的技術知識
    • 獎勵工作者建立新的研討班和特殊的興趣小組
    • 使用統計技術確定何時培訓被需要,並且何時培訓可以結束

發表迴響

項目管理 : 軟件質量的可靠保證

對軟件開發的各個階段進行管理,增強對軟件開發的控制能力,提高軟件開發質量,這是軟件項目管理的根本目的。

軟件的質量高低取決於其是否符合包括功能性、可靠性、易用性、效率、可維護性、可移植性等在內的六個方面的要求。而要達到這六個方面質量要求,就必須對軟件開發過程中各個環節進行全過程的項目管理,從需求分析、設計、編碼、測試到上線驗收進行控制。根據軟件工程的生命週期,軟件項目可分為項目立項、啟動、需求分析、系統設計、系統開發、系統測試、系統上線、項目驗收和上線後評估等9個階段進行。加強軟件項目管理,就是以軟件工程的各個環節為管理主線,將動態項目管理貫穿其中,通過對軟件開發的項目範圍、項目進度、項目質量、項目溝通、人力資源、項目成本六大核心要素的集成管理,實現軟件開發管理效能的最大化,從而大大提高軟件的開發質量。

準確把握軟件需求
軟件開發項目的提出,應由迫切的業務需求來驅動。很多不成功的軟件項目,往往是由信息技術部門提出,按照技術人員的思路主導開發,並理所當然地被認為能夠在業務部門取得良好的應用效果。這樣的項目由於得不到業務部門的理解和支持,脫離業務需求,多數面臨失敗或半途而廢的命運。因此軟件項目業務需求的迫切性、技術實現的成熟性、經濟效益的可行性等方面的因素,都是考慮的要素,將對項目的成敗產生直接影響。

正確的做法應該是,由軟件的需求單位根據自身業務需要,向信息技術管理部門提出軟件項目的立項建議,對立項的目的、業務需求範圍、技術經濟指標、開發週期要求等方面做簡要概述,再由信息技術管理部門組織業務專家和信息技術專家組成聯合專家組,進行項目立項的可行性論證。通過專家組論證審核後,項目提出單位需要進行開題設計,進一步明確軟件開發範圍、技術路線、進度安排、經費預算、研究人員組成、合作隊伍,並以此為基礎編制完成開題設計書。信息技術管理部門組織專家組對開題設計進行論證,只有業務需求合理、技術路線可行、開發隊伍落實的項目,才能通過專家組審核,進入項目啟動階段。

軟件開發過程的監督和管理
軟件開發項目具有建設範圍難界定、技術含量高、人員流動快、協作性強、開發成功率低等特點。目前國內對軟件項目的監理制度尚不規範,對軟件開發仍然缺乏有效控制。因此由企業的信息技術管理部門設立軟件監督崗位,加強對軟件項目的開發過程管理,就顯得非常必要。

軟件監督的主要職責是在項目的進行過程中,協調業務需求部門和軟件開發方的關係,監控軟件開發任務的執行情況,給開發人員和管理層提供反映軟件過程質量的信息和數據,提高項目透明度,從而保證項目按照計劃實施,實現預期目標。

軟件監督應具備以下三方面的基本素質:

  • 具有較強的工作責任感和良好的溝通能力;
  • 熟悉業務管理流程,掌握軟件開發流程、開發規範以及相關標準;
  • 具有軟件開發項目的建設和管理經驗,掌握項目管理知識;

軟件監督的工作任務主要有:

  • 確保軟件按照業務需求方確認的範圍進行開發。
  • 保證軟件開發進度符合雙方確認的計劃指標。
  • 保證軟件開發過程中存在的不符合要求的問題能夠及時得到溝通和處理,必要時需要將問題反映給管理層。
  • 確保項目組中軟件開發人員隊伍相對穩定。
  • 保證軟件開發過程和開發出來的軟件符合相應標準和規範。
  • 收集軟件開發過程中的成功經驗,為企業提供軟件開發過程的有效控制方法和規範。

 

  1. 監督管理的範圍
    《需求分析說明書》是對軟件開發範圍的書面表達依據。由於《需求分析說明書》往往是採用軟件設計的術語編寫,因此常常令計算機背景知識較少的業務需求方難以理解,也就很難發現需求報告中與實際需求不符之處,更難提出建設性的意見。
    軟件監督要對軟件開發範圍進行管理,首先要確定雙方都能認可的《需求分析說明書》。如要求軟件開發方對《需求分析說明書》做出進一步更詳細的解釋,編制業務模型,以便用戶方准確地理解《需求分析說明書》的內容,能及早地發現需求與實際的偏差。這也是對需求分析工作的總結與確認。
    在項目需求分析階段,雙方必須全面地、盡可能細緻地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求,以及對項目進行評估的各種評價標準。
    《需求分析說明書》完成後,軟件監督應組織項目組與業務需求方共同討論,聽取業務需求方的意見和建議,並進行相應的修改完善。各方確認《需求分析說明書》內容後,需在說明書上簽字確認。
    在軟件開發過程中,雙方應嚴格按照簽字確認的《需求分析說明書》中規定的業務範圍進行開發。有些需求可能在項目初期很難確定,在開發過程中需要不斷地加以修正,項目軟件監督要及時與用戶充分溝通,建立可以直接聯繫的渠道,共同進行需求確認,保證項目範圍可控。
  2. 進度管理
    為確保項目按時、按量、保質完成,必須控制任務和跟踪里程碑。按照軟件項目的開發規律,將軟件開發過程分為幾個重要階段,對這幾個階段的關鍵事件設立里程碑進行跟踪管理。項目進度管理可以通過以下方式完成:
    ●制定項目里程碑管理運行表(里程碑管理表的主要內容見表1)。
    表項目里程碑管理運行表
    ●定期舉行項目狀態會議,由軟件開發方報告進度和問題,用戶方提出意見。
    ●比較各項任務的實際開始日期與計劃開始日期是否吻合。
    ●確定正式的項目里程碑是否在預期完成。
    從軟件項目實施的過程來看,很少有一個項目是完全按照實施計劃來進行的,因為再好的計劃也不能完全預見所有的問題,並事先制訂出對策。計劃可以調整,但是調整必須合理,並得到業務需求方和管理層的批准。當有問題發生時,其直接的表現就是實施結果偏離了原來的計劃和目標,在這種情況下,軟件監督就要及時發現這種偏離,並分析這種原因,如果是因為原來的計劃和目標制訂的不合理,或者發生了預料之外的情況而又無法克服,這樣就必須調整計劃和目標。
  3. 溝通管理
    信息系統本身就是溝通的產物。軟件開發過程實際上就是將手工作業轉化成計算機程序的過程。軟件開發的原料和產品就是信息,中間過程傳遞的也是信息,而信息的產生、收集、傳播、保存正是溝通管理的內容。可見溝通不僅僅是軟件項目管理的必要手段,更重要的,溝通是軟件生產的手段和生產過程中必不可少的工序。
    軟件開發的柔性標準需要溝通來彌補。軟件開發不像加工螺釘、螺母,有具體的標準和檢驗方法。軟件的標準柔性很大,比如在用戶的心裡好用是軟件成功的標準,而這個標准在軟件開發前很難確切地、完整地表達出來。因此,開發過程項目組和用戶的溝通互動是解決這一現實問題的惟一辦法。
    軟件監督要有效地安排開發方軟件人員與需求方使用人員的交流,保證有暢通的交流渠道。制定完善的項目匯報製度,明確溝通時間、頻率和渠道。按照項目匯報製度定期組織項目組向業務需求方和管理層匯報,包括項目進度計劃、已完成工作、與計劃的比較、存在的問題、措施和建議以及下一步工作計劃等。
  4. 軟件版本管理
    目前的軟件開發是團隊開發的時代,軟件開發技術更新迅速,開發人員流動頻繁,因此對軟件版本的管理就顯得尤其重要。在軟件開發的過程中,在多人共同開發一個軟件時,會出現多人同時修改軟件的情況,這是不可避免的,由於部分功能模塊版本可能要進行不斷地升級完善,而老的軟件版本又沒有即使更新,隨著時間的推移,開發人員對自己機器上的不同版本間的差異就會模糊不清。另外由於軟件開發工期的壓力,開發人員只將注意力集中在設計和編碼上,未將文檔納入到版本控制中。為了解決這些問題,軟件監督就要注意跟踪記錄整個軟件的開發過程,包括軟件本身及其相關文檔,重視代碼的一致性。這一工作可以通過應用軟件版本管理的工具軟件實現,如Microsoft公司的Visual SourceSafe等對源代碼和整個項目進行管理,從而建立正常的軟件版本管理機制,
    把握正確的驗收方法
    軟件項目驗收是對軟件項目成果的檢驗和確認,也是對軟件項目範圍的再確認。軟件驗收應是一個過程的概念,包括驗收前的系統測試、數據移植、系統上線和正式驗收四個階段。
    1.系統測試
    系統測試是對系統進行全面的測試,應在測試環境中進行,以確保系統的功能和技術設計滿足企業的業務需求,並能正常運行。系統測試階段應包括以下主要流程和工作內容:
    (1)制訂測試計劃,包括編制測試用例,建立測試環境。
    (2)測試。在測試環境中,項目組根據需要,對系統依次進行單元測試、集成測試、壓力測試和用戶接受測試,記錄測試結果並由相關測試人簽字確認,編制相應的測試報告。對於未通過測試的內容,項目組應查找失敗的原因,並修改相應程序或設置,重新進行測試。除了進行充分的系統功能測試,測試應包含與內部控制相關的測試內容,如係統認證和授權、交易完整性及數據真實、完整性的有關功能。
    (3)提交測試報告、用戶確認簽字。項目組撰寫測試報告,將測試報告提交給各相關用戶,用戶應在測試報告上簽字確認。
    2.數據移植
    新系統上線時如需要將原始數據移植到新系統,則應完成以下主要工作內容:
    (1)制訂數據移植/轉換計劃。除了要定義數據收集的格式、範圍、進度外,還要考慮系統接口的影響,並建立了數據移植完整性和準確性測試方法以及意外事件處理程序。
    (2)數據收集。如果項目實施涉及到數據收集,應由數據收集小組根據數據收集格式,對數據進行收集,數據收集小組在收集數據時應培訓業務部門的數據提供人員,以確保數據提供人員了解和掌握對數據收集的各項規定和要求。
    (3)數據移植前的測試。在測試環境中對數據移植方法進行測試,書面記錄測試結果,解決測試中發現的問題,進行問題記錄並歸檔。
    (4)數據導入並核查結果。
    項目組成員將數據導入系統,並在導入後按照事先制定的數據移植完整性和準確性測試方法對系統中的數據做進一步的核查,確保導入數據的質量。如有意外,按照事先制定的意外事件處理程序處理,並留下記錄。數據移植完成之後,用戶應對數據移植結果簽字確認。
    (5)數據移植後要進行適當時間的試運行,確認數據移植的真實性和完整性。試運行時間視具體系統的規模、影響程度而定。對影響較大的系統,至少應試運行三個完整的月結週期。
    3.系統上線
    系統上線階段應包括以下的主要流程和工作內容:
    (1)上線前準備工作。在上線前,軟件開發方應制定係統上線計劃,包括上線檢查清單、上線支持人員、退回機制等,並提交《上線申請表》。系統上線計劃和《上線申請表》應經過信息技術部門和業務部門管理層的正式批准,並通知各相關部門。
    (2)系統上線。所有的上線準備工作做好之後,由軟件監督人員確認上線系統版本正確性後,與用戶確認系統上線時間,下達上線指令。系統上線操作人員將最後版本的系統程序移植到生產環境。
    4.正式驗收
    正式驗收前,軟件開發方應向信息技術管理部門提交軟件開發過程中各階段性文檔,包括需求分析說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、源程序代碼、可供安裝使用的系統安裝程序、系統管理員手冊、用戶使用手冊、測試計劃、測試報告、用戶報告、數據移植計劃及報告、系統上線計劃及報告、用戶意見書、驗收申請等。
    信息技術管理部門接到驗收申請後,組織專家對項目進行初審。初審通過後,組織管理層領導、業務管理人員和信息技術專家成立項目驗收委員會,負責對軟件項目進行正式驗收。
    軟件監督應根據軟件開發方在整個軟件開發過程中的表現,向驗收委員會提出全面的軟件監督報告,並根據開題設計書、軟件開發合同以及《需求分析說明書》,制定驗收標準,提交驗收委員會。信息技術管理部門組織由驗收委員會、軟件監督、軟件開發方參加的項目驗收會,軟件開發方以項目匯報、現場應用演示等方式匯報項目完成情況,驗收委員會根據驗收標準對項目進行評審,形成最終驗收意見。

軟件質量的六個考核要素
1.功能性:滿足用戶的要求,在預定環境下能夠完成預期的功能。
2.易用性:用戶容易理解和使用功能,操作方便,符合用戶業務習慣。
3.可靠性:軟件按照設計要求,在規定時間和條件下不出故障,具有異常捕獲功能並提供異常處理與恢復功能。
4.效率:降低系統資源的開銷,響應時間快,提高用戶工作效率。
5.可維護性:遵從統一的標準和規範,編碼具有良好的可讀性。為滿足用戶新的要求,或當環境發生了變化,或運行中發現了新的錯誤時,能夠對一個已投入運行的軟件進行相應診斷和修改。
6.可移植性:一個軟件(或軟件的部分功能模塊)能再次用於其他相關聯的應用。

發表迴響

實施質量控制 – 成果

1. 質量控制衡量 Quality Control Measurements
質量控制衡量是質量控制活動的結果,依據質量保證過程QA用以對實施組織的質量標準和過程進行重新評估和分析。

2. 確認的缺陷補救 Validated Defect Repair
對被補救項目進行重新檢驗,在做出決策通知之前決定是否接受或拒絕。被拒絕的項目可能需要進一步的消缺處理。

3. 質量基準(更新)Quality Baseline (Updates)

4. 推薦的糾正措施 Recommended Corrective Actions
糾正措施指質量控制量度結果表明製造或開發過程超出既定參數,為糾正這種情況而採取的行動。

5. 推薦的預防措施 Recommended Preventive Actions
預防措施指為預防製造或開發過程超出既定參數(可通過質量控制量度結果反映)而採取的行動。

6. 請求的變更 Requested Changes
如果根據推薦的糾正措施或預防措施,需要對項目進行變更,則應按照既定的整體變更控製過程啟動變更請求。

7. 推薦的缺陷補救 Recommended Defect Repair
缺陷係指一個部件不滿足要求或規範,需對其進行補救或替換。識別缺陷並推薦由質量控制部門或類似部門進行處理。項目管理團隊應盡可能地最大程度降低需要補救的缺陷數量。可通過缺陷記錄單的形式,徵集補救建議。該項通常在問題自動跟踪系統中實施。

8. 組織過程資產(更新)Organization Process Assets (Updates)

  • 完成的核對表(Completed checklists)。如果採用核對表,則完成的核對表應成為項目記錄的一部分。
  • 經驗教訓文檔(Lessons learned documentation)。質量控製過程中掌握的偏差成因、採取糾正措施的理由和依據,以及其他各種類型的經驗教訓都應形成文檔形式,使之成為項目和實施組織歷史數據庫的一部分內容。應在整個項目生命期內總結經驗教訓並形成文檔,如果不可能,則至少應在項目收尾時進行匯總。

9. 確認的可交付成果 Validated Deliverables
質量控制的目的在於確定可交付成果的正確性。實施質量控製過程的結果是可交付成果得以驗證。

10. 項目管理計劃(更新)Project Management Plan (Updates)
對項目管理計劃進行更新,以反映實施質量控製過程產生的質量管理計劃變更。申請的項目管理計劃及其從屬計劃的變更(修改、增添或刪除)通過整體變更控製過程進行審查和處理。

發表迴響

實施質量控制 – 工具與技術

質量控制工具與技術的前7種工具和技術被譽為質量7工具。

1. 因果圖 Cause and Effect Diagram
因果圖又叫石川圖或魚骨圖,它直觀地顯示出各項因素如何與各種潛在問題或結果聯繫起來。

2. 控製圖 Control Charts
控製圖旨在確定一個過程是否穩定,是否具有可預測的績效結果。控製圖也可作為數據收集工具,表明過程何時受特殊原因影響而使過程失控。同時也可以反映一個過程隨著時間推移而體現的規律。這構成了過程變量之間交互作用的圖形表現形式,可藉此得出問題的答案:過程變量是否在可接受的範圍內?通過對控製圖數據點規律的檢查,可以揭示波動幅度很大的過程數值,過程數值的突然變動,或偏差日益增大的趨勢。通過對過程結果的監控,可有利於評估過程變更的實施是否帶來預期的改進。如果過程處於正常控制範圍之內,就不應對其進行調整。但如果沒有處於正常控制之內時,則需要對其進行調整。控制上限和控制下限一般都設定在±3個六西格瑪(標準差)的位置。
控製圖可用於項目生命期過程,也適用於產品生命期過程。在項目中使用控製圖的例子是,確定成本偏差或進度偏差是否在可接受標準的範圍之外(±10%)。在產品中使用控製圖的例子是,評定測試期間發現的缺陷量按照組織的質量標準是否可以被接受或認可。
控製圖可用於監測任何類型的結果變量。雖然控製圖經常用於追踪重複性活動,如批量加工件,但也可用於監測成本與進度偏差,範圍變更的大小和頻度,項目文檔中的錯誤,以及其他管理結果,幫助確定項目管理過程是否處於正常控制範圍之內。

3. 流程圖 Flowcharting
流程圖用於幫助分析問題發生的緣由。它以圖形的形式展示一個過程,可以使用多種格式,但所有過程流程圖都具有幾項基本要素,即活動、決策點和過程順序。它表明一個系統的各種要素之間的交互關係。流程圖可協助項目團隊預期將在何時、何地發生質量問題,因此有助於應對方法的製定。

4. 直方圖 Histogram
直方圖指一種橫道圖,可反映各變量的分佈。每一欄代表一個問題或情況的一個特徵或屬性。每個欄的高度代表該種特徵或屬性出現的相對頻率。這種工具通過各欄的形狀和寬度來確定問題的根源。

5. 帕累托圖 Pareto Chart
帕累托圖是按照發生頻率大小順序繪製的直方圖,表示有多少結果是由已確認類型或範疇的原因所造成的。
按等級排序的目的是指導如何採取糾正措施。項目團隊應首先採取措施糾正造成最多數量缺陷的問題。從概念上說,帕累托圖與帕累託法則一脈相承,該法則認為:相對來說數量較小的原因往往造成絕大多數的問題或者缺陷。此項法則往往稱為二八原理,即80%的問題是20%的原因所造成的。也可使用帕累托圖匯總各種類型的數據,進行二八分析。

6. 趨勢圖 Run Chart
趨勢圖可反映偏差的歷史和規律。它是一種線形圖,按照數據發生的先後順序將數據以圓點形式繪製成圖形。趨勢圖可反映一個過程在一定時間段的趨勢,一定時間段的偏差情況,以及過程的改進或惡化。趨勢分析是藉助趨勢圖來進行的。趨勢分析指根據過去的結果用數學工具預測未來的成果。趨勢分析往往用於監測:

  • 技術績效(Technical performance)。多少錯誤或缺陷已被確認,其中多少尚未糾正。
  • 費用與進度績效(Cost and schedule performance)。每個時期有多少活動在活動完成時出現了明顯偏差。

7. 散點圖 Scatter Diagram
散點圖顯示兩個變量之間的關係和規律。通過該工具,質量團隊可以研究並確定兩個變量的變更之間可能存在的潛在關係。將獨立變量和非獨立變量以圓點繪製成圖形。兩個點越接近對角線,兩者的關係就越緊密。

8. 統計抽樣 Statistical Sampling
統計抽樣指從感興趣的群體中選取一部分進行檢查(例如,從總數為75張的工程圖紙目錄中隨機選取10張)。適當的抽樣往往可以降低質量控制費用。統計抽樣已經形成了規模可觀的知識體系。在某些應用領域,項目管理團隊有必要熟悉多種不同的抽樣技術。

9. 檢查 Inspection
檢查係指檢查產品,確定是否符合標準。一般而言,一項檢查的結果包括測量結果。可在任一層級上進行檢查,如可檢查單項活動的結果,也可檢查項目的最終產品。檢查有各種不同的名稱,例如,審查、產品審查、審計和實地查看等。在某些應用領域,這些術語的含義較窄,較具體。也可通過檢查技術驗證缺陷補救情況。

10. 缺陷補救審查 Defect Repair Review
缺陷補救審查是質量控制部門或類似部門採取的措施,目的在於確保產品缺陷得以補救並使之與要求或規範相符。

發表迴響

Older Posts »