Cập nhật nội dung chi tiết về Biểu Đồ Nhân Quả Hay Biểu Đồ Xương Cá mới nhất trên website Techcombanktower.com. Hy vọng thông tin trong bài viết sẽ đáp ứng được nhu cầu ngoài mong đợi của bạn, chúng tôi sẽ làm việc thường xuyên để cập nhật nội dung mới nhằm giúp bạn nhận được thông tin nhanh chóng và chính xác nhất.
Sơ đồ nguyên nhân và kết quả là một sơ đồ biểu thị mối quan hệ có ý nghĩa giữa một nguyên nhân và một kết quả. Nó còn được gọi là Sơ đồ xương cá
Sơ đồ nguyên nhân và kết quả trong 7 công cụ QC
– Đó đại diện cho mối quan hệ có ý nghĩa giữa một nguyên nhân và một kết quả
– Đây là một công cụ rất tốt để phân tích nguyên nhân gốc rễ và là một phần của 7 Công cụ kiểm soát chất lượng cơ bản
– Tiến sĩ Kaoru Ishikawa đã phát triển nó vào năm 1943 trong khi tư vấn cho xưởng thép của Kawasaki tại Nhà máy đóng tàu Kawasaki, vì vậy Tiến sĩ Joseph M. Juran đã đặt tên cho nó là “Ishikawa”
– Sơ đồ này còn được gọi là “Xương cá” vì nó trông giống như xương của cá.
Khi nào chúng ta có thể sử dụng biểu đồ Xương cá hay biểu đồ Ishikawa:
– Khi xác định nguyên nhân gây ra vấn đề (sự cố)
– Xác định tất cả các nguyên nhân gốc rễ có khả năng góp phần gây ra sự cố (rắc rối)
– Đặc biệt là khi suy nghĩ của các thành viên một nhóm khác nhau
– Công cụ này rất hữu ích trong Dự án Six Sigma
Bốn bước để xây dựng sơ đồ xương cá
1. Nêu tác động hoặc vấn đề không mong muốn
2 Xác định các nhóm nguyên nhân chính
4 Xác định các nguyên nhân gốc rễ tiềm năng
Bước 1. Nêu tác động hoặc vấn đề không mong muốn
– Trước hết, chúng tôi sẽ đề cập đến tác động hoặc vấn đề không mong muốn và vẽ một trục xương sống cùng các đường thẳng.
– Sau đó xác định và trình bày một vấn đề (tác động)
Viết vấn đề vào giữa bên phải của biểu đồ hoặc bảng trắng.
– Vẽ một hộp bao quanh vấn đề và một mũi tên ngang chạy đến nó.
Bước 2. Xác định các nhóm nguyên nhân chính
Đối với ngành sản xuất, nó là “6M”
Trong ngành sản xuất “6M” là viết tắt của
Người (Man)
Máy móc (Machine)
Vật liệu (Material)
Phương pháp (Method)
Đo lường (Measurement)
Môi trường (Enviroment)
Đối với ngành thương mại, “6M” được thay thế bằng “8P”
Sản phẩm/ dịch vụ (Product)
Giá (Price)
Khuyến mãi ( promotion)
Địa điểm (place)
Quá trình (process)
Con người ( people)
Dữ liệu vật lý (physical evidence)
Hiệu suất (performance)
Đối với ngành dịch vụ, “6M” được thay thế bằng “4S”
Vùng lân cận
Các nhà cung cấp
Hệ thống
Kỹ năng
– Chúng ta sẽ tiếp tục phân tích các vấn đề gây nên khả năng hoạt động kém của xe hơi
– Viết các loại nguyên nhân là các nhánh từ mũi tên chính
– Nghĩ đến tất cả những nguyên nhân ban đầu của vấn đề
Điều chỉnh bộ chế hòa khí
Lốp không săm
Bảo trì kém
Thói quen lái xe kém
Không có nhận thức
Bôi trơn không đúng cách
Hỗn hợp nhiên liệu sai
Dầu động cơ không phù hợp
Chuyển số không theo trình tự
Chuyển số sai
Lái xe quá nhanh
Bước 4. Xác định nguyên nhân gốc rễ tiềm năng
– Tiếp tục hỏi “Tại sao điều này xảy ra?” đối với mỗi nguyên nhân.
– Viết tất cả những gì thu thập được vào nhánh chính và nhánh phụ.
– Tiếp tục hỏi tại sao và đào sâu hơn mức độ nguồn gốc của vấn đề.
Lợi ích của biểu đồ xương cá hay Ishikawa:
– Giúp xác định nguyên nhân gốc rễ
– Tăng kiến thức
– Khuyến khích tham gia hoạt động nhóm
– Một công cụ tốt để động não
– Xác định các khu vực cụ thể để thu thập dữ liệu
Sơ Lược Về Biểu Đồ Xương Cá Và Sử Dụng Biểu Đồ Xương Cá Trong Quản Lý Chất Lượng Dự Án Test.
I. Giới thiệu về biểu đồ xương cá
1. Biểu đồ xương cá là gì
a. Fishbone diagram (Cause-and-effect diagram, Ishikawa diagram): biểu đồ xương cá
b. Check sheet: phiếu (biểu) kiểm tra
c. Control charts: biểu đồ kiểm soát
d. Histogram: biểu đồ phân bố
e. Pareto chart: biểu đồ Pareto
f. Scatter diagram: biểu đồ phân tán
g. Flow charts: biểu đồ dòng chảy
・Công cụ này do giáo sư Kaoru Ishikawa – một giáo sư chuyên ngành kỹ thuật của trường đại học Tokyo sáng chế vào thập niên 50.
・Công cụ này đã được áp dụng hiệu quả từ những năm 1960s và đã được người Nhật sử dụng rất thành công.
2. Tác dụng của việc sử dụng biểu đồ xương cá
Khi áp dụng biểu đồ này, người dùng sẽ có khả năng tìm ra các nguyên nhân tiềm tàng và nguyên nhân cốt lõi gây nên vấn đề.
Nhìn vào biểu đồ xương cá này, người đọc sẽ cóhình dung đầy đủ nguyên nhân của một vấn đề . Việc lập biểu đồ sẽ chỉ rõ từng nguyên nhân, từ đó có thể đưa ra hướng giải pháp cụ thể cho từng nguyên nhân một.
3. Cách tạo một biểu đồ xương cá
Bước 1: Xác định vấn đề. Vấn đề này chính là hệ quả của nguyên nhân sẽ xác định.
Bước 2 và bước 3 là xác định nguyên nhân chính và nguyên nhân phụ. Có thể thực hiện theo 1 trong 2 cách sau.
Cách 1:
Bước 2: Động não, suy nghĩ tỷ mỉ kỹ lưỡng để tìm ra tất cả các nguyên nhân có thể có của vấn đề. Ở bước này chưa phân biệt nguyên nhân chính và nguyên nhân phụ.
Bước 3: Sắp xếp, tổ chức lại tất cả những kết quả đã động não được. Nhóm các nguyên nhân phụ lại vào trong 1 nguyên nhân chính.
Cách 2:
Bước 3: Tiếp tục động não suy nghĩ những nguyên nhân cụ thể hơn, trực tiếp gây ra nguyên nhân chính (Nguyên nhân cấp 1). Nếu cần phân tích sâu hơn thì tiếp tục tìm ra những nguyên nhân khác nhỏ hơn, trực tiếp gây ra nguyên nhân cấp 1.
+Vẽ 1 ô vuông ở ngoài cùng bên tay phải của tờ giấy
+Vẽ 1 mũi tên nằm ngang , hướng đầu mũi tên về phía ô vuông ở trên
+Bên trong ô vuông trên, viết mô tả vấn đề đang cố gắng giải quyết
+Từ trục chính nằm ngang này, vẽ các nhánh chính và viết tên của các category ở phía trên và phía dưới của đường mũi tên nằm ngang trên (Đây như là các cành to của một thân cây chính)
+Từ các nhánh chính này, vẽ các nhánh phụ và viết nguyên nhân chi tiết cho mỗi category (Đây như là các cành nhỏ và các nhánh con)
4. Khi lập biểu đồ xương cá thì cần chú ý các vấn đề sau
Cần nhìn vấn đề một cách tổng thể toàn diện để có thể tìm ra đầy đủ tất cả các nguyên nhân có thể có.
Sau khi xây dựng , cần đưa biểu đồ ra để toàn bộ các thành viên review lại, bổ sung và chỉnh sửa nếu cần. Ngoài ra có thể hỏi thêm ý kiến của một vài người khác có kiến thức về hoạt động của quá trình.
II. Sử dụng biểu đồ xương cá trong quản lý chất lượng dự án test
Đối với 1 dự án phần mềm, việc đảm bảo chất lượng của đợt test, không để bỏ sót bug là hết sức quan trọng. Ngay khi phát hiện ra tester đã để lọt bug (kể cả giai đoạn đang test và giai đoạn đã release cho khách hàng) thì chúng ta cần phải tìm ra nguyên nhân vì sao để sót lỗi để có hướng ngăn chặn cho những lần test sau.
Khi điều tra nguyên nhân vì sao để sót lỗi, tôi thấy có thể xảy ra các trường hợp sau:
1.1 Đã làm đúng toàn bộ các điều kiện phát sinh bug: môi trường, thao tác v.v, bug có xảy ra nhưng lại không report cho khách hàng do:
Tester không nhận thức đó là bug nên đã không report lên.
Tester nhận thức đó là bug nhưng lại lack không report lên. Ví dụ tester note lại trong testcase bản cứng hoặc bản mềm, sau đó quên không log trong file defect gửi cho khách hàng.
Bug đã chỉ phát sinh đúng 1, 2 lần. Sau đó làm lại thì bug không xảy ra nên Tester đã không report. Hoặc để tái hiện, điều tra thì mất thời gian chuẩn bị môi trường, thời gian test không còn nhiều nên đã không có đủ thời gian tìm hiểu lại, nên không report.
Tester nhận thức là bug, có report lên nhưng bị team leader reject.
Tester nhận thức là bug, có report lên nhưng team leader đã để sót bug này khi tổng hợp để report cho khách hàng.
1.2 Đã không có đầy đủ các điều kiện phát sinh bug nên khi test, bug đã không xảy ra. Vì thế không phát hiện ra được. TH1：Thao tác test đúng, nhưng môi trường test không đúng (Trường hợp lỗi chỉ xảy ra trên 1 môi trường đặc định).
Windows không được update theo đúng require của khách hàng.
Môi trường không sạch: ví dụ như trước đó đã thực hiện install, uninstall nhiều lần rồi.
Thiếu không cài 1 số phần mềm mà khách hàng đã yêu cầu.
Cài sai version của 1 số phần mềm mà khách hàng đã yêu cầu.
Khách hàng không require cụ thể mà cho chọn môi trường, và khi test testcase đó thì đã test trên môi trường khác.
Khách hàng không chỉ định test trên môi trường đó.
TH2： Môi trường test đúng, nhưng thao tác test chưa đúng (Trường hợp lỗi chỉ xảy ra khi thực hiện đúng theo các bước XYZ).
Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã đọc sót testcase, dẫn đến sót thao tác.
Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên tester đã hiểu sai 1 số thao tác nên đã thực hiện thao tác khác.
Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên trong quá trình thực hiện các bước theo testcase, tester đã thực hiện thêm 1 bước nào đó không ghi trong testcase. Tuy nhiên tester lại nhận thức rằng đáng lẽ phải có thêm bước đó, và cũng không confirm lại với khách hàng khi thấy testcase không ghi bước đó.
Testcase đã ghi thao tác cụ thể và nếu thực hiện theo đúng testcase thì sẽ ra bug. Tuy nhiên trong quá trình thực hiện các bước theo testcase, tester đã vô tình thực hiện thêm 1 bước nào đó không ghi trong testcase.
Testcase không ghi thao tác cụ thể, và tester có thể thao tác theo nhiều kiểu khác nhau đều sẽ ra kết quả xác nhận. Và thực tế thì thao tác mà tester đã thực hiện không đúng với thao tác để có thể sinh ra bug.
1.3 Tester đã không test testcase đó
Khách hàng có require test testcase đó nhưng do leader hiểu sai requirement nên đã không giao cho tester test
Khách hàng có require test testcase đó nhưng trong quá trình giao testcase cho tester, leader đã bị giao sót testcase đó: ví dụ in sót, hoặc in bị lỗi, hoặc testcase đó vô tình bị bôi đen đi.
Leader có giao testcase đó nhưng Tester đã bị bỏ sót không test testcase đó.
Khách hàng cho phép chọn testcase random và leader đã không chọn testcase đó.
Khách hàng cho phép chọn testcase random và leader để cho tester tự chọn. Bản thân tester đã không chọn testcase đó.
Khách hàng đã không yêu cầu test testcase đó
Testcase do khách hàng cung cấp, khách hàng đã không tạo testcase đó.
Testcase do dự án viết theo những chỉ định của khách hàng. Trong nội dung chỉ định thì đã không có nội dung đó.
Testcase do dự án viết theo chỉ định của khách hàng. Trong nội dung chỉ định có trường hợp đó nhưng người viết đã bị bỏ sót.
Testcase do dự án viết theo chỉ định của khách hàng. Trong nội dung chỉ định thì có nội dung đó, nhưng khi viết testcase đã không cover được hết các trường hợp thao tác.
All Rights Reserved
Biểu Đồ Xương Cá (Fishbone Diagram) Là Gì? Mục Đích Sử Dụng
Khái niệm
Biểu đồ xương cá hay còn gọi là biểu đồ nhân quả, trong tiếng Anh là fishbone diagram.
Biểu đồ xương cá là loại biểu đồ được thiết kế để nhận biết những mối quan hệ nguyên nhân và kết quả.
Điều này được thực hiện bằng việc hướng dẫn người sử dụng thông qua một loạt các bước theo một cách có hệ thống để nhận biết những nguyên nhân thực tế hoặc tiềm ẩn mà có thể tạo ra một kết quả (đó có thể là một vấn đề khó khăn hoặc một cơ hội cải tiến).
Biểu đồ xương cá được ông Kaoru Ishikawa đưa ra vào những năm 1960. Ông là người tiên phong về quản lí chất lượng tại nhà máy đóng tầu Kawasaki và được xem là người có công với quản lí hiện tại. Vì thế, biểu đồ này còn được gọi là biểu đồ Ishikawa.
Mục đích sử dụng
Biểu đồ xương cá thường sử dụng trong các trường hợp:
– Khi có nhu cầu tìm hiểu một vấn đề để xác định nguyên nhân gốc rễ.
– Khi muốn tìm hiểu tất cả các lí do có thể có tại sao một tiến trình giải quyết vấn đề gặp những khó khăn hoặc những thất bại.
– Khi có nhu cầu nhận diện các lĩnh vực thu thập thông tin.
– Khi muốn tìm hiểu lí do một tiến trình không đưa đến những kết quả mong muốn.
Các bước tạo một Biểu đồ Xương cá
Bước 1: Xác định vấn đề: ghi lại chính xác vấn đề một cách chi tiết ( áp dụng 5w: what, who, when, where, how). Viết vấn đề vào ô bên phải tờ giấy. Sau đó kẻ một đường ngang, chia giấy của bạn ra làm 2. Lúc này bạn đã có “đầu & xương sống” của con cá trong sơ đồ xương cá.
Bước 2: Xác định các nhân tố ảnh hưởng: ứng với mỗi nhân tố, vẽ một nhánh “xương sườn”. Cố gắng liệt kê càng nhiều nhân tố càng tốt, ví dụ hệ thống, cơ sở vật chất, máy móc, nguyên liệu, yếu tố bên ngoài ..v..v… Nếu bạn có 1 nhóm để xử lý vấn đề thì đây là lúc cần áp dụng các kỹ thuật brainstorming.
Bước 3: Tìm ra nguyên nhân có thể có, thuộc về từng nhân tố (đã tìm ra trong bước 2), ứng với mỗi nguyên nhân, lại vẽ một “nhánh xương con”. Nếu nguyên nhân của bạn quá phức tạp, có thể chia nhỏ nó thành nhiều cấp.
Bước 4: Phân tích sơ đồ: sơ đồ đã xây dựng là một danh sách đầy đủ các nguyên nhân có thể xảy ra, bạn có thể kiểm tra, khảo sát, đo lường .v..v.. để xác định đâu là các nguyên nhân chính rồi từ có có những kế hoạch cụ thể để sửa chữa.
(Theo Giáo trình Thống kê doanh nghiệp, NXB Đại học Kinh tế quốc dân)
T.D
Biểu Đồ Thành Phần Và Biểu Đồ Triển Khai
Biểu đồ thành phần (Component Diagram) là biểu đồ mô tả các thành phần và sự phụ thuộc của chúng trong hệ thống. Các thành phần của hệ thống có thể là:
Thành phần mã nguồn, có ý nghĩa vào thời điểm dịch chương trình. Thông thường nó là tập các chương trình cài đặt các lớp. Trong C++, mỗi tệp .cpp và .h là một thành phần. Trước khi phát sinh mã chương trình, phải thực hiện ánh xạ từng tệp vào thành phần tương ứng, thông thường mỗi lớp được ánh xạ vào hai tệp (.cpp, và .h).
Thành phần mã nhị phân là mã trình nhị phân được dịch từ mã chương trình nguồn. Nó có thể là tệp mã đích (.obj), tệp thư viện tĩnh (.lib) hay tệp thư viện động (.dll). Thành phần nhị phân được sử dụng để liên kết, hoặc để thực thi chương trình (đối với thư viện động).
Thành phần thực thi là tệp chương trình có thể thực thi được (các tệp .exe). Nó là kết quả của chương trình liên kết các thành phần nhị phân.
Với biểu đồ thành phần, người phát triển hệ thống thực hiện dịch, triển khai hệ thống sẽ biết thư viện mã trình nào tồn tại và những tệp có thể thực thi (.exe) khi dịch và liên kết thành công.
Giữa các thành phần chỉ có một loại quan hệ phụ thuộc được biểu diễn bằng đường mũi tên đứt nét. Kết nối phụ thuộc cho biết thành phần phụ thuộc phải dịch sau thành phần kia.
Nên tránh phụ thuộc vòng tròn trong biểu đồ thành phần.
Biểu đồ thành phần mô tả sự phụ thuộc giữa các thành phần của hệ thống.
Sự phụ thuộc của các thành phần trong biểu đồ thành phầnTrong UML (và Rose) có một số biểu tượng biểu diễn cho các thành phần, đó là:
Thành phần: biểu tượng thành phần (hình 1) được sử dụng để biểu diễn module chương trình có các giao diện. Trong đặc tả có xác định kiểu Stereotype (AciveX, Applet, DLL, exe, v.v.).
Đặc tả và thân chương trình con: biểu tượng thành phần cho đặc tả chương trình con hình 2b, và đặc tả dạng cài đặt của chương trình con hình 2c. Chương trình con không chứa các định nghĩa lớp.
Chương trình chính: biểu tượng thành phần (tệp) chứa điểm vào của chương trình chính hình 2d, ví dụ trong C/C++ đó là tệp chứa hàm main().
Đặc tả và thân của gói: đặc tả gói hình 2e là tệp header chứa thông tin về các hàm thành phần của lớp, ví dụ đặc gói trong C/C++ là tệp .h định nghĩa các hàm prototype. Biểu tượng cho thân gói hình 2f gồm mã các lệnh của các hàm thành phần của lớp chứa trong gói. Trong C/C++, thành phần này là tệp .cpp.
Đặc tả và nội dung nhiệm vụ: các biểu tượng này (hình 2g, 2h) biểu diễn cho phần đặc tả và nội dung của những nhiệm vụ độc lập.
Các thành phần của hệ thốngTương tự như các phần tử khác trong UML, đối với các thành phần cũng có thể bổ sung một số đặc tả chi tiết:
+ Ngôn ngữ: Rose cho phép lựa chọn ngôn ngữ lập trình cho từng thành phần, như C++, Java, Visual Basic, Oracle 8, v.v.
+ Khai báo: phụ thuộc được gộp vào mã chương trình cho mỗi thành phần. Lệnh #include của C++ được xem như là lệnh khai báo.
+ Lớp: trước khi phát sinh mã chương trình thì lớp phải được ánh xạ vào thành phần. Điều này báo cho Rose biết mã chương trình của lớp sẽ được ghi vào tệp nào. Có thể ánh xạ một hay nhiều lớp vào một thành phần.
Biểu đồ thành phần được xem như là tập các biểu tượng thành phần biểu diễn cho các thành phần vật lý trong một hệ thống. Ý tưởng cơ bản của biểu đồ thành phần là tạo ra cho những người thiết kế và phát triển hệ thống một bức tranh chung về các thành phần của hệ thống.
Biểu đồ triển khai (Deployment Diagram) chỉ ra cấu hình các phần tử xử lý lúc chương trình chạy, các nút trên mạng và các tiến trình phần mềm thực hiện trên những phần tử đó. Nó chỉ ra mối quan hệ giữa các phần cứng và phần mềm của hệ thống. Biểu đồ triển khai chỉ ra toàn bộ các nút trên mạng, kết nối giữa chúng và các tiến trình chạy trên chúng. Ví dụ, biểu đồ triển khai của hệ thống có thể tổ chức như hình 3.
Biểu đồ triển khai của hệ thống
Mỗi nút là một đối tượng vật lý (các thiết bị) có tài nguyên tính toán. Chúng có thể là máy tính, máy in, máy đọc ảnh, thiết bị truyền tin, v.v. Các nút được kết nối với nhau thông qua các giao thức ( protocol) như các giao thức “TCP/IP” ở hình 3.
Các phần tử (nút) của biểu đồ triển khai
Bộ xử lý (Processor): bộ xử lý của máy tính, máy chủ, trạm làm việc, v.v.
Các bộ xử lý được đặc tả chi tiết bằng cách bổ sung thêm các thông tin:
+ Stereotype: để phân nhóm các bộ xử lý.
+ Đặc tính: mô tả các tính chất vật lý của mỗi bộ xử lý như: tốc độ tính toán, dung lượng bộ nhớ, v.v.
+ Lịch biểu (Schelduling): mô tả loại lịch biểu thời gian xử lý, bao gồm:
– Preemptive cho phép những tiến trình có mức ưu tiên cao hơn có thể chiếm quyền xử lý đối với những tiến trình có mức ưu tiên thấp hơn
– Non Preemptive không có ưu tiên, một tiến trình chỉ dừng khi nó tự kết thúc
– Cyclic chỉ ra chu kỳ điều khiển giữa các tiến trình
– Executive: các lịch biểu được điều khiển bằng thuật toán, bằng chương trình
– Manual: tiến trình được điều khiển bằng người sử dụng.
Thiết bị: là máy móc hay bộ phận phần cứng nhưng không phải là bộ xử lý trung tâm, như: màn hình, máy in, máy vẽ, v.v. Thiết bị cũng có thể đặc tả một số thông tin chi tiết như: Stereotype và một số tính chất vật lý.
Tiến trình(Process) là luồng thực hiện của một chương trình trong một bộ xử lý. Một chương trình thực thi được xem như là một tiến trình. Các tiến trình thường được gán các mức ưu tiên và bộ xử lý sẽ thực hiện những tiến trình có mức ưu tiên cao hơn.
Bạn đang đọc nội dung bài viết Biểu Đồ Nhân Quả Hay Biểu Đồ Xương Cá trên website Techcombanktower.com. Hy vọng một phần nào đó những thông tin mà chúng tôi đã cung cấp là rất hữu ích với bạn. Nếu nội dung bài viết hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!