DESIGN OF EXPERIMENTS (DOE)


A. DESIGN OF EXPERIMENTS (DOE) là gì?

DOE là một phương pháp có hệ thống nhằm xác định các yếu tố (factors) đầu vào cấu thành sản phẩm hay các yếu tố trong quá trình sản xuất (Xi, Zi) có quan hệ mật thiết với mục tiêu đầu ra của sản phẩm hay quy trình sản xuất (Y). Trên cơ sở đó ta có thể kiểm soát nhằm đạt mục tiêu đầu ra thông qua việc lựa chọn các tổ hợp đầu vào hay kiểm soát các yếu tố trong quá trình sản xuất.




 Lưu ý: 
1/ Xi là những factors ta có thể kiểm soát được như chọn phương pháp nào để làm UT, hay bao nhiêu eforts bỏ ra cho REQ review
2/ Zi: Là các factors ta không thể điều chỉnh trong quá trình sản xuất: Ví dụ nhiệt độ môi trường tại thời điểm chạy mô hình...

Dùng DOE như thế nào?

1/ DOE được dùng để chọn và tối ưu thiết kế để đạt được mục tiêu đầu ra cho sản phẩm. Hay dùng để chọn quy trình và phuwowng pháp phù hợp nhằm đạt được mục tiêu đề ra

2/ DOE cũng được áp dụng để theo dõi và kiểm soát nhằm tăng khả năng đạt mục tiêu đề ra

Đây là công cụ rất hay, với công cụ này bạn kiểm soát các mục tiêu như năng suất, chất lượng... như cách bạn dùng Earned Value Management để kiểm soát ngân sách và tiến độ vậy

Ví dụ thực tế:

Ví dụ: Khi sản xuất phần mềm, ta muốn yêu cầu đầu ra là mật độ lỗi tìm ra trong quá trình khách hàng nghiệm thu sản phẩm UATR (UATR= số lỗi / độ lớn sản phẩm – FP, KLOC, SP). Ví dụ ta đặt mục tiêu là 8% (Cho phép tối đa 8 lỗi trên 100 FP (Function Point) sản phẩm). Vậy UATR chính là Y.

Bài toán PM cần giải trước khi lập kế hoạch dự án là tìm các Xi  cho phương trình Y = F (Xi, Zi): Quy trình nào, phương pháp nào cần dùng trong quá trình sản xuất để chắc chắn đạt mục tiêu Y (UATR = 8%) nêu trên?


Ví dụ: Quy trình SX phần mềm: REQ-> DE-> Code&UT-> Test -> Deliver

1.      REQ:
a.       X1: REQ validation type (X1.1: Manual Prototyping, X1.2: Online Prototyping, Simulation…)
b.      X2: REQ Review methods (X2.1: Pass-around, X2.2: Walkthrough, X2.3: Inspection)
c.       X3: Requirement review efforts
2.      DE:
a.       X4: Design method (X4.1: 4 view +1, X4.2: Object-oriented Design, X4.3: Structure Design…)
b.      X5: DE Review methods (X5.1: Pass-around, X5.2: Walkthrough, X5.3: Inspection)
c.       X6: DE review efforts
3.      Code:
a.       X7: Code Review methods (X7.1: Pass-around, X7.2: Walkthrough, X7.3: Inspection)
b.      X8: Code review efforts
c.       X9: UT methods: (X9.1. Manual UT, X9.2: Automation UT (TDD)
4.      Test:
a.       X10: Test method (X10.1: Manual Testing, X10.2: Automation Testing)

Để giải bài toán này, PM cần tìm ra phương trình Y = F(Xi- i=1..10) sao cho kết quả sẽ là 95% chắc chắn dự án sẽ đạt mục tiêu UATR<= 8%. Thường để làm việc này, ta phải dựa vào historical data của nhiều dự án trước đó, xây dựng mô hình (Process Performance Model – dung regression & simulation) sau đó dung phần mềm mô phỏng như Crystal Ball của Oracle để chạy và lấy kết quả.


Ví dụ: Kết quả Y = F (X1.2, X2.3, X3 (40 hours), X4.1, X5.3, X6 (50hours), X7.3, X8 (200 hours), X9.2, X10.2)

Và đây là bộ quy trình tốt nhất cần áp dụng để đạt mục tiêu chất lượng đề ra  UATR <= 5% (0.08). Kết quả như trong hình sau cho thấy rằng ta có 92% chăc chắn đạt dc mục tiêu với bộ quy trình đã chọn




Giá trị của DOE không chỉ là xác địng tổ hợp đầu vào, quy trình cần áp dụng để đạt mục tiêu mà còn giúp ta kiểm soát để đạt mục tiêu trong quá trình sản xuất

Ví dụ: Ta có thể điều chỉnh efforts bỏ ra để làm code review sao cho xác suất đạt được mục tiêu là trên 90%...

Đây là kết quả mình chạy mô phỏng bằng Crystal Ball khi đang viết code và UT:


è      Có tới 99% xác suất đạt mục tiêu -> Yên tâm! Nếu dự báo kết quả không tốt, ta cần điều chỉnh lại các yếu tố đầu vào để tăng khả năng đạt mục tiêu. Sau đó chạy lại mô hình để kiểm ra kết quả

LLàm sao để xây dụng PPM (Product/Process Performance Model):

Câu chuyện này hơi dài dòng và cần kỷ năng làm thống kê nên không tiện để viết hết ra đây. Về tổng thể thì việc phân tích Xi và Zi là như nhau. Phương trình Y = f (xi, zi) là cần thiết. Điều khác biệt là mình chỉ có thể điều chỉnh X để đạt mục tiêu
 

      Các bước chính như sau :
1. Plan và collect histrorical data
2. Group và Xử lý data (theo Stratification): Loại bỏ ourliers, baseline data (mean, std...) - dùng Minitab
3. Tìm Xi và Zi có "quan hệ" mật thiết với Y
4. Regression tìm phương trình Y = F (Xi, Zi)
5. Xây dựng mô hình ( Mình dùng Crystal Ball)
6. Thử nghiệm mô hình
7. Deploy và áp dụng mô hình

Đây là công cụ rất hay, với công cụ này bạn kiểm soát các mục tiêu như năng suất, chất lượng... như cách bạn dùng Earned Value Management để kiểm soát ngân sách và tiến độ vậy

Tuy nhiên, hạn chế nhất của nó là rất khó xây dựng mô hình đặc biệt nó cần khối lượng lớn historical data chính xác và tin cậy - và điều này thì không dễ chút nào với doanh nghiệp mà việc quản lý dự án chưa trở nên chuẩn hóa, chuyên nghiệp, chưa ổn định (stable) giũa nhiều dự án cùng loại

Thanks and regards,
-----------------------------------------------------------------------------------------------------------------------------
Quy Hoang PMP, PMI-ACP |Scrum Master| Agile Coach | PMO Manager
Email: hoangsyquy@gmail.com|Website: www.tmasolutions.com
Mobile: +84-908 106 080 | Skype: hoangsyquy

Comments

Popular posts from this blog

PHƯƠNG PHÁP QUẢN LÝ LINH HOẠT (AGILE) VÀ CHỨNG CHỈ QUỐC TẾ PMI-ACP

X-Life Cycles: Adaptive or Predictive?