Phân tích dữ liệu xác minh

Xác minh phần cứng là một vấn đề đòi hỏi nhiều dữ liệu hoặc nặng về dữ liệu. Kỹ sư xác minh nhận ra điều này và dành phần lớn thời gian để xử lý các tập dữ liệu lớn và phức tạp phát sinh từ quá trình xác minh.

Trong "Vấn đề nan giải của việc xác minh phần cứng” chúng tôi đã khám phá những thách thức chính xung quanh việc xác minh hệ thống và IP phần cứng phức tạp. “Tình trạng tiến thoái lưỡng nan về tính hoàn thiện” khiến các nhóm kỹ thuật phụ thuộc nhiều vào dữ liệu và phân tích dữ liệu, để làm cho các quy trình chưa hoàn thiện có thể đo lường và giới hạn, đồng thời cho phép các nhóm phát triển sản phẩm đưa ra quyết định dựa trên dữ liệu về chất lượng phê duyệt cho việc phát hành sản phẩm.

Vì vậy, trên thực tế, một trong nhiều kỹ năng cốt lõi của Kỹ sư xác minh giỏi là phân tích dữ liệu.

Kỹ sư xác minh giỏi cần phải là Nhà phân tích dữ liệu giỏi.

Các kỹ sư xử lý khối lượng dữ liệu khổng lồ: bộ thử nghiệm, kết quả thử nghiệm, kết quả bao phủ, dữ liệu sử dụng và lập kế hoạch tài nguyên, dữ liệu kiểm soát phiên bản, phân tích miễn trừ, theo dõi lỗi và lỗi cũng như tối ưu hóa liên tục và cải tiến liên tục thông qua phân tích xu hướng và phân tích nguyên nhân gốc rễ.

Khi làm như vậy, Kỹ sư xác minh sử dụng nhiều nguồn dữ liệu khác nhau để đảm bảo các dự án đang đi đúng hướng và tiến tới mục tiêu dự án, đồng thời đảm bảo có sẵn thông tin chính xác để hỗ trợ các quyết định phê duyệt ở các mốc chất lượng quan trọng xảy ra trong vòng đời phát triển sản phẩm.

Dữ liệu xác minh cũng mang đến cơ hội lớn để tối ưu hóa và hợp lý hóa quy trình xác minh.

ROI của sản phẩm được phân phối cuối cùng được xác định chủ yếu bởi chi phí phát triển và đã có tài liệu rõ ràng rằng 70% chi phí trở lên trong số này là do các hoạt động xác minh. Vì vậy, cần phải cẩn thận để đảm bảo rằng các hoạt động xác minh được thực hiện hiệu quả và không lãng phí.

Tất nhiên, mức độ hoang tưởng lành mạnh sẽ rất hữu ích theo quan điểm của Kỹ sư xác minh vì có sự buộc phải thực hiện ngày càng nhiều chu kỳ xác minh vì việc thoát lỗi đến tay khách hàng hoặc người dùng cuối có thể cực kỳ tốn kém, gây ảnh hưởng và có khả năng gây tổn hại về mặt danh tiếng! Nhìn thấy "Cái giá của lỗi” nơi chúng tôi khám phá sự cân bằng giữa “chi phí tìm ra lỗi” (chi phí xác minh) so với “chi phí không tìm thấy lỗi” (chi phí tác động của việc thoát khỏi lỗi).

Thông tin chi tiết từ dữ liệu

Giá trị của dữ liệu xác minh được nhận ra khi nó mang lại những hiểu biết quan trọng.

Hãy coi những hiểu biết sâu sắc như những câu hỏi.

Một cái nhìn sâu sắc có thể là một câu hỏi cấp cao mà Giám đốc kỹ thuật đang hỏi nhóm kỹ thuật để hiểu mức độ hiệu quả hoặc hiệu quả của quá trình phát triển sản phẩm. Đó cũng có thể là câu hỏi được đặt ra bởi đội ngũ lãnh đạo cấp cao, đội ngũ chất lượng hoặc đội ngũ bán hàng và doanh thu.

Những hiểu biết sâu sắc cũng có thể thúc đẩy chiến lược cải tiến liên tục được thực hiện nhờ sự hiểu biết về tính hiệu lực và hiệu suất.

Trong một số trường hợp, những hiểu biết sâu sắc có thể không thể đoán trước hoặc bất ngờ. Sự tò mò và cách tiếp cận phân tích để làm sạch, hiểu, khám phá và xác thực dữ liệu cũng như xem xét các quan điểm phân tích có thể tiết lộ những quan sát mà trước đây không có. Những hiểu biết sâu sắc bất ngờ này đôi khi mang đến cơ hội thách thức hiện trạng và suy nghĩ lại về các thực tiễn đã được thiết lập. Tuy nhiên, cần phải cẩn thận để thách thức và xác nhận các giả định.

Hãy lưu ý rằng đôi khi có thể làm cho các phân tích phù hợp với câu chuyện hơn là ngược lại.

Sẽ rất hữu ích khi nghĩ đến những hiểu biết sâu sắc trong bối cảnh ngăn xếp giá trị dữ liệu, như được minh họa trong Hình 1 Kim tự tháp nghịch đảo của Analytics.

Thông tin chi tiết cho phép đưa ra quyết định dựa trên dữ liệu.

Thông tin chi tiết được cung cấp nhờ Phân tích dữ liệu tốt, do đó được kích hoạt bởi Mô hình dữ liệu được xây dựng từ Nguồn dữ liệu được tải vào Hồ dữ liệu. Vấn đề là phải tìm ra những Quyết định dựa trên dữ liệu nào được doanh nghiệp yêu cầu trước tiên và để điều này thúc đẩy việc thu thập dữ liệu, đường dẫn dữ liệu và phân tích dữ liệu chứ không phải ngược lại!

Hình 1 Kim tự tháp nghịch đảo của Analytics

Dữ liệu thô ở đáy kim tự tháp có ít giá trị trừ khi nó sạch và chính xác và được cung cấp thông qua đường dẫn dữ liệu thúc đẩy các phân tích mạnh mẽ mang lại hiểu biết sâu sắc có giá trị cao.

Cấu trúc của dữ liệu và lý do chúng ta nên quan tâm…

Nếu chúng ta tuân theo các mối quan tâm ở Cấp độ thực thi nhằm thúc đẩy hoạt động xác minh xuất sắc cho đến thực tế kỹ thuật xác minh – các hoạt động hàng ngày – thì chúng ta có thể mô tả rõ hơn những gì đang diễn ra ở từng giai đoạn.

Theo quan điểm của CFO và CEO, có nhiều vấn đề cần lo lắng, nhưng khi liên quan đến việc phát triển kỹ thuật cho tất cả các sản phẩm mang lại doanh thu quan trọng của công ty thì vấn đề chỉ tập trung vào những vấn đề này.

Hình 2 Chi phí, Chất lượng, Giao hàng

Khách hàng muốn nhà cung cấp của họ đạt được kết quả tương tự, nghĩa là nỗ lực xác minh mà bạn bỏ ra phải hiệu quả và hiệu suất để mang lại các giải pháp tiết kiệm chi phí cho họ. Để đạt được điều này, quy trình thiết kế và xác minh của bạn phải được trang bị tốt để tránh hội chứng được gọi là “hộp đen”, theo đó sản phẩm được giao đến nơi mà không có ý tưởng rõ ràng về nỗ lực xác minh đã phát hiện lỗi tốt đến mức nào và có thể không có cách xử lý tốt. về chi phí hoặc thời gian của dự án.

Sự xuất sắc phụ thuộc vào dữ liệu tốt và văn hóa kỹ thuật biết cách khai thác nó.

Hình 3 Đường dẫn dữ liệu, bên dưới, cho thấy tầm quan trọng của việc phân tích nhằm cung cấp thông tin chuyên sâu về nỗ lực xác minh nhằm đánh giá tính hiệu lực và hiệu quả. Các phân tích hữu ích yêu cầu sự tương quan của thông tin từ các bộ dữ liệu khác nhau được tạo ra bởi hoạt động hàng ngày của Kỹ sư thiết kế và Xác minh.

Hình 3 Đường dẫn dữ liệu

Đây là một thử nghiệm tư duy hữu ích để đo lường nỗ lực xác minh của bạn nằm ở đâu so với các câu hỏi màu cam, ở mỗi giai đoạn của quy trình dữ liệu ở trên. Có lẽ đáng ngạc nhiên là không phải tất cả các nhóm kỹ thuật đều có khả năng xử lý đủ tốt về loại dữ liệu họ có, vị trí của dữ liệu đó, mức độ sạch sẽ và cách khai thác dữ liệu đó. Ở phần sau của bài viết, chúng tôi khám phá việc tạo ra văn hóa tò mò và những năng lực cần thiết để thực hiện quá trình chuyển đổi này.

Hình 4 Những thách thức về dữ liệu bên dưới minh họa một số thách thức mà các nhóm có thể gặp phải khi phát triển các phân tích cần thiết để đưa ra quyết định đúng đắn, nhằm thúc đẩy các quy trình xác minh cải tiến quan trọng và chỉ ra các khoản đầu tư cần thiết vào công cụ và phần cứng.

Hình 4 Những thách thức về dữ liệu

Những thách thức này không phải chỉ xảy ra đối với việc xác minh phần cứng mà phải được khắc phục để đạt được khả năng phân tích ở cấp độ cơ bản.

Việc phân tích từ các tập dữ liệu đa dạng có thể cực kỳ phức tạp, đặc biệt khi liên quan đến mối tương quan giữa chúng. Một ví dụ đơn giản là minh họa việc phát hiện lỗi ở các giai đoạn khác nhau của vòng đời sản phẩm để bạn có thể đánh giá tiến độ so với Kế hoạch xác minh của mình.

Các câu hỏi chuyên sâu khác yêu cầu kỹ thuật dữ liệu phức tạp hơn để cung cấp thông tin cần thiết. Ở các công ty nhỏ hơn, nhiệm vụ này có thể được giao cho nhóm kỹ thuật hoặc có thể được thuê ngoài. Với tư cách là “kỹ sư dữ liệu giỏi”, nhóm xác minh cần phải thoải mái khi suy nghĩ về những vấn đề này.

Các nhóm lớn hơn có thể có nguồn lực dồi dào về kỹ thuật/phân tích dữ liệu nội bộ để thực hiện những phát triển nội bộ này. Trong cả hai trường hợp, nhóm Xác minh cần phải thông thạo các thách thức về dữ liệu để đảm bảo họ nhận được những gì cần thiết nếu muốn phát triển hoặc cải thiện hoạt động phân tích. Nhìn thấy Bước 1: Đào tạo các kỹ sư của bạn cách suy nghĩ như Nhà phân tích dữ liệu.

Chất lượng dữ liệu, bẫy khối lượng dữ liệu…

Trọng tâm của chúng tôi trong sách trắng này là thảo luận về “Phân tích dữ liệu” trong bối cảnh tổ chức, tự động hóa, làm sạch và trực quan hóa các tập dữ liệu xác minh mà hầu hết các nhóm đều đã có. Tuy nhiên, bạn không thể thảo luận về chủ đề này mà không đặt câu hỏi: –

Còn AI thì sao? Tôi có thể sử dụng nó không?

Mọi người đều nhận thức được tiềm năng mà Machine Learning (ML) hiện đang được nhúng vào các công cụ EDA (xem Bước 2: Khai thác công cụ EDA nâng cao), cũng như các cơ hội mà khoa học dữ liệu mang lại để cải thiện việc nhắm mục tiêu phạm vi bao phủ và phân tích dữ liệu để giúp phân tích dễ dàng hơn. Mặc dù bài viết này sẽ đề cập đến những chủ đề này nhưng nó chủ yếu tập trung vào cách tận dụng tốt nhất dữ liệu để mang lại hiểu biết sâu sắc hơn về quy trình xác minh.

Hình 5 Các bộ dữ liệu nhỏ, chất lượng thấp là rào cản đối với việc phát triển phân tích hoặc triển khai thành công các kỹ thuật ML/AI tiên tiến.

Mặc dù không có con số công khai nào cho thấy có bao nhiêu nhóm kỹ thuật đã triển khai thành công ML và AI, nhưng có thể nhiều nhóm sẽ gặp phải vấn đề về chất lượng dữ liệu hoặc kích thước của tập dữ liệu.

Trong bài viết kích thích tư duy của họ, “Khảo sát các ứng dụng machine learning trong xác minh chức năng”, Yu, Foster và Fitzpatrick khẳng định, “Do thiếu tập dữ liệu lớn, nhiều nghiên cứu phải giải quyết các kỹ thuật ML tương đối thô sơ, chỉ yêu cầu các tập dữ liệu huấn luyện nhỏ với hàng trăm mẫu. Tình hình đã ngăn cản việc áp dụng các kỹ thuật và thuật toán ML tiên tiến”.

Trong Hình 5 (Chất lượng dữ liệu), ở trên, rất khó để phân tích một lượng nhỏ dữ liệu xác minh không đáng tin cậy với bất kỳ mức độ tin cậy nào – bạn thấy mình đang gặp khó khăn Bẫy 1. Trong trường hợp này, lựa chọn hợp lý là đầu tư vào việc làm sạch dữ liệu của bạn và phát triển các phân tích xuất sắc – không dễ dàng chuyển sang ML/AI trong Cấp 2 từ Bẫy 1.

Một lượng lớn thông tin chất lượng thấp có thể rất khó quản lý và hiểu, khiến nó không phù hợp với các kỹ thuật ML hoặc AI, chưa nói đến bất kỳ kỹ thuật dữ liệu cần thiết nào cần thiết để tạo ra những phân tích tốt – Đây là Bẫy 2. Giống như các tập dữ liệu nhỏ hơn, hoạt động dọn dẹp quy mô lớn được chỉ định. Vì những lý do này, chất lượng dữ liệu kém và tập dữ liệu nhỏ hơn đặt ra những thách thức đáng kể cho các công ty muốn chuyển sang các công cụ EDA hỗ trợ ML và các kỹ thuật AI tiên tiến hơn.

Một bước hợp lý và cần thiết hơn đối với nhiều tổ chức là tận dụng tốt hơn dữ liệu họ có để tạo ra các phân tích hữu ích nhằm đưa ra quyết định đúng đắn và cải tiến liên tục.

Mặc dù việc “chỉ” tạo ra những phân tích tốt có vẻ kém thú vị hơn việc chuyển thẳng sang ML/AI trong Cấp 2, chúng có thể vẫn khó triển khai cho đến khi dữ liệu của bạn được làm sạch và một số thách thức được nêu trong Hình 4 đã được khắc phục.

Giả sử bạn đã tổ chức kỹ thuật dữ liệu của mình, được xây dựng trên nền tảng dữ liệu chất lượng cao và các phân tích tuyệt vời để soi sáng những góc tối và nhiều lỗi đó, thì đã đến lúc suy nghĩ về những thông tin chi tiết cần tìm kiếm.

Thông tin chi tiết: “Xác minh của tôi có hiệu quả không?”

Quay lại phần “Thông tin chi tiết”, nhiều thông tin từ bộ dữ liệu xác minh có thể được phân loại là thông tin chi tiết về hiệu suất và hiệu suất. Hãy bắt đầu với hiệu quả. Điều đó có ý nghĩa gì đối với nhóm xác minh và ai khác muốn biết về điều đó?

Hiệu quả có thể được mô tả như một hàm theo cách sau: –

Mỗi biến trong công thức có thể được ghi lại trong một cơ sở dữ liệu riêng biệt và được mô tả bằng một tập hợp các lược đồ dữ liệu.

Sự phong phú của các lược đồ dữ liệu được sử dụng để thu thập dữ liệu có tác động trực tiếp đến chất lượng phân tích có thể được tạo ra từ dữ liệu đó.

“Mô hình dữ liệu” kết nối các nguồn này bằng cách sử dụng khóa chính để cho phép tương quan dữ liệu. Sau khi nhóm đã xác định được những phân tích nào là cần thiết, có thể cần phải xây dựng các lược đồ dữ liệu.

Thông tin chi tiết về hiệu quả yêu cầu các phân tích cho thấy tính hiệu quả của testbench về khả năng thực hiện tiến trình xác minh, được xác định là tăng mức độ phù hợp và/hoặc tìm lỗi. Nếu testbench không nâng cao phạm vi bao phủ hoặc tìm ra lỗi thì nó có thể không hiệu quả, trừ khi các mục tiêu xác minh đã được đáp ứng đầy đủ.

Tiện ích của phân tích tốt là khả năng phân tích tính hiệu quả của testbench theo kiểu trực quan để các nhóm phát triển có thể thực hiện các cải tiến có mục tiêu khi triển khai testbench. Các cải tiến liên tục đạt được thông qua việc lặp lại quá trình tái cấu trúc mã, tối ưu hóa hiệu suất hoặc tái kiến ​​trúc, nhằm tăng khả năng của testbench trong việc khắc phục lỗi và phạm vi bảo hiểm với ít hạt giống hoặc chu kỳ hơn. Phân tích được sử dụng ở từng giai đoạn để chứng minh những cải tiến thực tế.

INSIGHT: “Testbench của tôi có tìm thấy lỗi không?”

Để làm được điều này, chúng tôi cần các lược đồ dữ liệu cho phép phân tích trực quan hóa và đi sâu vào đường cong lỗi theo thời gian. Chúng tôi kỳ vọng sẽ thấy đường cong lỗi tích lũy phẳng dần và bão hòa theo thời gian; hoặc đường cong tỷ lệ lỗi đạt đỉnh rồi giảm xuống XNUMX.

Tốt hơn hết là hãy liên hệ các đường cong lỗi này với nỗ lực xác minh để đưa ra dấu hiệu thực sự về nỗ lực xác minh so với các lỗi được tìm thấy.

Và với hệ thống phân cấp xác minh, chẳng hạn như Đơn vị->Hệ thống phụ->Top->Hệ thống, bộ phận phân tích cần có khả năng trình bày dữ liệu về lỗi và nỗ lực ở mỗi cấp độ và cho phép người dùng xem các cấp độ khác nhau cũng như các đơn vị hoặc phụ khác nhau như thế nào. -Hệ thống so sánh Khả năng phân tích như vậy cung cấp những hiểu biết sâu sắc về môi trường xác minh hiệu quả và môi trường nào rõ ràng là không hiệu quả. Từ đó, các nhóm có thể đưa ra quyết định về việc nên đầu tư nỗ lực kỹ thuật vào đâu để mang lại lợi nhuận cao nhất.

Điều đó có ý nghĩa gì về mặt dữ liệu?

Để làm điều này, chúng tôi cần kết hợp dữ liệu lỗi với dữ liệu kết quả xác minh để có thể khám phá xem có bao nhiêu chu kỳ xác minh đang diễn ra giữa các lần tìm lỗi - và xem xét điều này trong suốt vòng đời phát triển sản phẩm vì nó sẽ thay đổi tùy theo giai đoạn nào của quá trình phát triển sản phẩm. sự phát triển của sản phẩm.

INSIGHT: “Testbench của tôi có tăng phạm vi phủ sóng không?”

Việc phân tích cũng cần phải tương quan giữa dữ liệu phạm vi phủ sóng với dữ liệu nỗ lực xác minh. Nếu phân tích cho thấy đường cong lỗi đã bão hòa và mức độ bao phủ đã bão hòa thì nhóm kỹ thuật có thể sử dụng thông tin này để đưa ra quyết định về những việc cần làm tiếp theo; Chạy nhiều chu kỳ hơn? Chạy ít chu kỳ hơn? Cải thiện môi trường xác minh?

Hơn nữa, với dữ liệu về lỗi và phạm vi bảo hiểm được thu thập trong toàn bộ vòng đời phát triển sản phẩm cũng như tất cả các phương pháp xác minh được áp dụng, bạn có thể suy luận về tính hiệu quả tương đối của từng phương pháp. tức là bạn phải xem xét tính hiệu quả trong bối cảnh của toàn bộ vòng đời xác minh và giai đoạn bạn đang ở. Ví dụ: Kiểm thử đơn vị có thể tỏ ra không hiệu quả (không tìm thấy nhiều lỗi) do quá trình xác minh chính thức hoặc cấp cao nhất trước đó đã thực hiện tốt công việc loại bỏ hầu hết các lỗi. Vì vậy, bạn phải xem xét toàn bộ vòng đời xác minh và thứ tự được chọn để thực hiện các phương pháp khác nhau.

Thông tin chi tiết: “Xác minh của tôi có hiệu quả không?”

Câu hỏi quan trọng thứ hai liên quan đến hiệu quả. Bạn có thể có sự kích thích và kiểm tra hiệu quả, nhưng liệu việc xác minh có thể được thực hiện với lượng nhân lực và nền tảng tối thiểu và liệu nó có thể được thực hiện trong thời gian ngắn nhất không?

Hiệu quả là một hàm của các yếu tố sau: -

Để hiểu hiệu quả, bạn phải xem chi tiết về:

• Các thử nghiệm riêng lẻ để hiểu liệu chúng có được thực hiện hay không có kiến ​​trúc và được thực hiện một cách tối ưu để đạt hiệu suất cao nhất với mục tiêu đã cho phương pháp.
• Hồi quy Luồng công việc để hiểu liệu họ có đang thực hiện công việc một cách tối ưu và không lãng phí tài nguyên hay không bằng cách chạy lại toàn bộ tập hợp hồi quy một cách không cần thiết khi nhiều lượt chạy có mục tiêu sẽ hiệu quả hơn.
• Có sẵn năng lực nền tảng có thể được chia sẻ giữa nhiều nhóm. Có thiếu nguồn lực dẫn đến sử dụng kém hiệu quả không?
• Sản phẩm hiệu suất của nền tảng, cả phần cứng (điện toán, lưu trữ và mạng) cũng như các công cụ EDA đang chạy khối lượng công việc xác minh.

Thông tin chuyên sâu này cho chúng tôi biết mức độ hiệu quả của các thử nghiệm mô phỏng được triển khai. Nếu một testbench hoạt động rất chậm, nó sẽ tiêu tốn nhiều tài nguyên giấy phép tính toán và mô phỏng hơn. Các thử nghiệm chậm có thể cần phải được triển khai lại để chúng chạy nhanh hơn. Câu hỏi này liên quan đến kiến ​​trúc và phương pháp thử nghiệm đơn vị hoặc hệ thống con.

Thông tin chi tiết về hiệu quả yêu cầu các phân tích tiết lộ hiệu suất tương đối của môi trường xác minh được theo dõi theo thời gian để có thể xác định những thay đổi về hiệu suất cũng như quan sát và điều tra các ngoại lệ. Vì các điểm chuẩn thử nghiệm sẽ khác nhau tùy theo kiến ​​trúc và cách triển khai, nên dự kiến ​​sẽ có một số mức độ thay đổi hiệu suất, nhưng việc có sẵn bảng điều khiển phân tích tốt để giám sát các môi trường này sẽ cho phép phát hiện sớm các tác động hiệu suất có thể phát sinh từ các phương pháp mã hóa kém hoặc sự xuống cấp của nền tảng/môi trường/công cụ. Khi các nhóm có thể xem dữ liệu này – họ có thể khắc phục những sự cố này.

Nếu không có phân tích, các nhóm sẽ mù quáng về hiệu quả. 

Thu thập dữ liệu lỗi là các bước quan trọng nhất hướng tới khả năng phân tích Cấp 1!

Chúng tôi đã thảo luận về giá trị của lỗi trong loạt bài viết The Quest for Bugs, nhưng cũng đáng để trình bày lại ở đây tại sao Dữ liệu lỗi là một trong những nguồn dữ liệu xác minh phong phú nhất và có thể mang lại những hiểu biết hữu ích nhất chẳng hạn như tính hiệu quả của việc xác minh.

Lỗi là một nguồn thông tin chi tiết và học hỏi tuyệt vời, NHƯNG chỉ khi bạn thu thập chúng!

…và việc thu thập dữ liệu lỗi có chất lượng tốt là một thách thức.

Với đủ dữ liệu lỗi chính xác, bạn có thể thu thập thông tin chi tiết về cả tính hiệu quả của chiến lược xác minh và chất lượng thiết kế của mình (Mức 1). Nếu bạn xem xét toàn bộ thiết kế, liệu một số đơn vị hoặc chức năng có gây ra nhiều lỗi hơn những đơn vị hoặc chức năng khác không và nếu có thì nguyên nhân của điều này là gì? Có thể thực hiện các bước để giảm số lượng lỗi được đưa vào mã? Dữ liệu lỗi có chỉ ra các điểm nóng có độ phức tạp không. Nguyên nhân cơ bản của những lỗi này là gì và có thể tránh được lỗi ngay từ đầu không? Từ góc độ hiệu quả của việc xác minh, phương pháp nào là hiệu quả nhất trong việc tìm ra lỗi nhanh chóng? Bạn có đang tốn nhiều nguồn lực để chạy các chu trình xác minh mà không tìm thấy lỗi không?

Bạn có thể “chuyển sang trái” và tìm ra những lỗi đó sớm hơn trong vòng đời phát triển sản phẩm cũng như bão hòa đường cong lỗi sớm hơn, nghĩa là phát hành sản phẩm sớm hơn không?

Để trả lời những câu hỏi này, bạn cần đảm bảo rằng bạn đang thu thập đủ dữ liệu lỗi và có lược đồ lỗi đầy đủ để nắm bắt thông tin chính xác về việc phát hiện lỗi, tác động của lỗi và nguyên nhân gốc của lỗi. Nếu bạn có một tập dữ liệu lỗi phong phú, bạn sẽ có thể tìm hiểu sâu các phân tích lỗi để trả lời nhiều câu hỏi trong số này và có thể tiết lộ một số thông tin chi tiết không mong muốn. Chào mừng bạn đến với Phân tích cấp 1!

Thử thách thường là thuyết phục đội ngũ kỹ thuật của bạn có thói quen ghi lại lỗi.

Đó là một thực hành kỹ thuật hoặc văn hóa kỹ thuật. Một số nhóm chỉ làm điều này như một phần tự nhiên trong công việc của họ, các nhóm khác thì ít sẵn lòng hơn và coi việc ghi nhật ký lỗi là một chi phí chung để đạt được tiến bộ trong tương lai.

Các nhóm kỹ thuật cần xem giá trị cụ thể từ việc phân tích lỗi là động lực để thu thập dữ liệu. Nhưng tất nhiên, đó là vấn đề “con gà và quả trứng”; không có dữ liệu lỗi hoặc dữ liệu lỗi chất lượng kém = không có phân tích hoặc phân tích có giá trị thấp.

Khi nào là thời điểm thích hợp để bắt đầu ghi lỗi? Làm thế nào để bạn đảm bảo rằng dữ liệu lỗi là đầy đủ và chính xác?

Có 3 động lực chính cho việc ghi lỗi: –

1. Làm việc theo nhóm và giao tiếp: danh sách nhiệm vụ để phát triển các sản phẩm phức tạp (phần cứng hoặc phần mềm), dài và có thể có sự tham gia của nhiều người. Trừ khi các lỗi được ghi lại và theo dõi một cách cẩn thận, nếu không sẽ có nguy cơ lỗi xảy ra do thực hành kém. Thông thường, người báo cáo lỗi và người giải quyết lỗi không phải là cùng một người, vì vậy bạn cần ghi lại và theo dõi các thông tin liên lạc về lỗi (phân loại, phân tích và giải pháp) để đảm bảo không có gì lọt qua mạng.
2. Theo dõi tiến độ và đăng xuất: Khi dự án chuyển tiếp qua vòng đời phát triển sản phẩm, cần phải hiểu đường cong lỗi trông như thế nào tại bất kỳ thời điểm nào. Tỷ lệ lỗi hiện tại là bao nhiêu? Có bao nhiêu lỗi còn tồn tại ở mỗi điểm đăng xuất? Đường cong lỗi có xu hướng đi đúng hướng như mong đợi không? Chúng ta có bao nhiêu lỗi nghiêm trọng so với các lỗi lớn và nhỏ?
3. Cải tiến liên tục: Bằng cách phân tích dữ liệu phát hiện lỗi và nguyên nhân gốc rễ của lỗi, chúng tôi có thể sử dụng những thông tin chi tiết này để cải thiện hiệu lực và hiệu suất của các phương pháp thiết kế và xác minh của mình. Đây là nơi liên tục học hỏi từ các lỗi, cả trong một dự án và giữa các dự án, thực sự có thể giảm chi phí, cải thiện chất lượng và giảm thời gian tiếp thị các sản phẩm phức tạp.

Nếu bạn có thể thu thập dữ liệu lỗi một cách chính xác và nhất quán thì bạn sẽ có được nhiều thông tin chi tiết ở trên. Hơn nữa, nếu bạn có thể kết hợp dữ liệu lỗi này với các nguồn dữ liệu thú vị khác như dữ liệu thực hiện thử nghiệm, dữ liệu mốc quan trọng của dự án hoặc dữ liệu tiêu thụ tài nguyên thì sẽ có thêm thông tin chi tiết mạnh mẽ có thể làm sáng tỏ lợi ích chi phí cho các nỗ lực kỹ thuật của bạn.

Bước 1: Đào tạo các kỹ sư của bạn cách suy nghĩ như Nhà phân tích dữ liệu

Trong Hình 5, chúng tôi đã mô tả các lộ trình thoát khỏi bẫy dữ liệu/khối lượng để hướng tới các khả năng Cấp 1 và 2. Chúng ta cũng có thể xác định ba giai đoạn cụ thể hơn cần đạt được để đạt được tiến bộ.

Như chúng tôi đã đề cập, phân tích dữ liệu là kỹ năng cốt lõi của Kỹ sư xác minh, cho dù họ có nhận ra hay không. Tuy nhiên, đôi khi không có những kiến ​​thức cơ bản về tính lưu loát của dữ liệu và đây là điều bạn có thể đào tạo các kỹ sư của mình. Thông thường, phân tích dữ liệu có thể khá cơ bản; có thể là trích xuất dữ liệu tĩnh được hiển thị dưới dạng bảng Excel hoặc tốt hơn là biểu đồ Excel. Những phân tích cơ bản này là các chế độ xem dữ liệu tĩnh có thể cần được cập nhật thủ công và thường xuyên và được trình bày dưới dạng ảnh chụp nhanh kịp thời để báo cáo dự án hoặc theo dõi tiến độ.

Phân tích trực tiếp và hoàn toàn tự động là cách tốt nhất. Các kỹ sư và người quản lý cần có khả năng truy cập phân tích dữ liệu bất cứ lúc nào và tin tưởng rằng những gì họ đang thấy là dữ liệu chính xác và đầy đủ mới nhất. Họ cần có khả năng tự phục vụ các phân tích này và không dựa vào các kỹ sư hoặc nhà phân tích dữ liệu để làm mới và phân phối các phân tích theo yêu cầu. Yêu cầu này dẫn đến nhu cầu cung cấp các hình ảnh trực quan thân thiện với người dùng được củng cố bởi các đường ống dữ liệu tự động tiêu thụ dữ liệu tại nguồn, làm sạch và chuyển đổi dữ liệu đó thành các mô hình dữ liệu đáng tin cậy để có thể xây dựng các hình ảnh trực quan tương tác.

Vì vậy, ở đây cần có nhiều kỹ năng hơn là năng lực cơ bản về bảng tính và biểu đồ.

Chúng tôi ủng hộ việc đào tạo một số kỹ năng dữ liệu cốt lõi cho các kỹ sư để giúp họ hiểu và trình bày dữ liệu của mình theo cách mang lại những hiểu biết sâu sắc. Một số hoạt động này có thể được thuê ngoài bởi các nhà phân tích dữ liệu đã được đào tạo, nhưng kiến ​​thức cốt lõi trong lĩnh vực này đảm bảo rằng Kỹ sư xác minh thu thập và phân tích các tập dữ liệu phù hợp cũng như hiểu dữ liệu nào là cần thiết và cách diễn giải dữ liệu đó. Nó cũng tạo ra một góc nhìn về dữ liệu (hoặc sự lưu loát của dữ liệu), trong đó các kỹ sư bắt đầu hiểu cách đọc dữ liệu, cách thao tác và biến đổi dữ liệu cũng như cách cảnh giác với những cạm bẫy có thể tạo ra kết quả sai lệch, chẳng hạn như mối quan hệ nhiều-nhiều giữa các phần tử dữ liệu. .

• Thu thập dữ liệu: Dữ liệu của bạn đến từ đâu? Nguồn gốc của dữ liệu là gì và tất cả dữ liệu đó có được thu thập không? Điều này thường đòi hỏi một số công cụ đo lường quy trình xác minh để thu thập dữ liệu và gửi dữ liệu đến Hồ dữ liệu. Đổi lại, điều đó có nghĩa là bạn cần tìm ra lược đồ dữ liệu chính xác để nắm bắt tất cả các trường bắt buộc cần thiết để hỗ trợ phân tích. Đây phải là một quy trình tự động để tính năng thu thập dữ liệu được bật theo mặc định. Ghi lại dữ liệu, bất kể sau đó bạn có cần lọc và lấy mẫu dữ liệu đó để phân tích hay không.
• Làm sạch dữ liệu: Hầu hết dữ liệu thô cần được làm sạch hoặc xử lý ở một mức độ nào đó để loại bỏ các giá trị rỗng hoặc trùng lặp, chẳng hạn như sửa lỗi hoặc các mục nhập không hợp lệ hoặc để lấp đầy các khoảng trống dữ liệu. Điều này có thể được thực hiện theo cách tương tác nhưng tốt nhất nên thực hiện theo cách xử lý hàng loạt tự động bất cứ khi nào có thể. Làm sạch dữ liệu có thể được viết bằng Python numpy và gấu trúc ví dụ: các thư viện, nơi các hoạt động dữ liệu mạnh mẽ có thể được thực hiện trên các khung dữ liệu chỉ bằng một vài bước. (Nhiều Kỹ sư xác minh sẽ sử dụng Python để viết kịch bản và xử lý quy trình xác minh, vì vậy việc bổ sung các thư viện phân tích dữ liệu này và các khái niệm xung quanh thao tác khung dữ liệu không phải là một bước khó khăn).
• Kỹ thuật dữ liệu: Đây là bước mà dữ liệu được chuyển đổi và xử lý thành định dạng phù hợp để trực quan hóa dữ liệu. Điều này có thể liên quan đến việc nối và hợp nhất các nguồn dữ liệu khác nhau để có thể tạo ra các mối tương quan quan trọng nhằm mang lại những hiểu biết sâu sắc về dữ liệu. Xem Hình 4 Những thách thức về dữ liệu. Đôi khi được gọi là mô hình dữ liệu, nó là lược đồ kiểm soát cách các bảng dữ liệu khác nhau được nối với nhau bằng cách sử dụng các phần tử chung (khóa chính) để liên kết chúng với nhau. Nó cũng có thể liên quan đến các trục, tập hợp, tóm tắt hoặc tạo ra các phần tử dữ liệu được tính toán hoặc dẫn xuất. Ví dụ: các nhóm xác minh có thể muốn đối chiếu dữ liệu kết quả thực thi thử nghiệm mô phỏng với dữ liệu theo dõi lỗi để hiểu mức độ hiệu quả của các thử nghiệm khác nhau trong việc tìm ra lỗi trong RTL. Ngoài ra, năng lực kỹ thuật dữ liệu có thể mở rộng sang cơ sở dữ liệu - ví dụ: cách thiết lập cơ sở dữ liệu có cấu trúc như MySQL hoặc cơ sở dữ liệu phi cấu trúc (hoặc Hồ dữ liệu) như MongoDB hoặc Hadoop. Có nhiều điều để tìm hiểu trong lĩnh vực này và đó là lĩnh vực mà các kỹ sư dữ liệu và nhà phân tích dữ liệu sẽ chuyên sâu, vì vậy, với tư cách là Kỹ sư xác minh hoặc Kỹ sư thiết kế, có thể hiểu rõ ngành học này nhưng nên thuê ngoài công việc kỹ thuật dữ liệu cho các chuyên gia dữ liệu.
• Truy vấn dữ liệu: Đây có thể giống một bộ kỹ năng kỹ thuật dữ liệu hơn, nhưng một số khả năng SQL cơ bản có thể hữu ích để hỗ trợ khám phá sớm các tập dữ liệu, trước khi có sẵn trực quan hóa dữ liệu đầy đủ. Khám phá bộ dữ liệu là một năng lực quan trọng khi được cung cấp dữ liệu mới và trước khi thiết lập bất kỳ phân tích tự động nào. SQL là năng lực cốt lõi của hầu hết các Nhà phân tích dữ liệu.
• Trực quan hóa dữ liệu: Cuối cùng, phần sẽ mang lại kết quả và thông tin chi tiết chính là nơi dữ liệu được hiển thị trực quan và người dùng cuối có thể tương tác với dữ liệu. Đôi khi được gọi là “Thông tin kinh doanh” vì nó trình bày thông tin tình báo hoặc hiểu biết sâu sắc về tình trạng của doanh nghiệp (hoặc trạng thái của một dự án phát triển sản phẩm). Không nên đánh giá thấp tầm quan trọng của việc học các kỹ năng trực quan hóa dữ liệu tốt và có nhiều tùy chọn công cụ tốt rất thú vị để học và có thể mang lại những hình ảnh trực quan ấn tượng rất nhanh, ví dụ: PowerBI hoặc Tableau. Học cách sử dụng những công cụ này một cách hiệu quả sẽ tạo ra sự quan tâm và hứng thú thực sự đối với dữ liệu, vì vậy đây là một kỹ năng cốt lõi đáng giá để bổ sung vào bộ kỹ năng của Kỹ sư thiết kế hoặc xác minh.

Bước 2: Khai thác công cụ EDA nâng cao

Ngành công nghiệp EDA đã nghiên cứu các cách khai thác AI và ML để nâng cao việc cung cấp công cụ của họ trong vài năm nay. Điều này được kích hoạt bởi cả khối lượng dữ liệu lớn được tạo ra bởi nhiều công cụ xác minh EDA cũng như sự xuất hiện và hoàn thiện của các thuật toán ML chung có thể phù hợp với nhiều vấn đề về dữ liệu xác minh. Những công cụ này thường được cung cấp dưới dạng phiên bản mới của các công cụ hiện có có thể được cấp phép hoặc cải tiến của các công cụ hiện có, nơi hiệu suất và hiệu quả được cải thiện nhờ ML cơ bản. Người dùng cuối có thể không cần biết rằng ML đang được các công cụ sử dụng hoặc thay đổi cách họ sử dụng các công cụ đó, nhưng các công cụ sẽ hoạt động tốt hơn. Điều này tạo ra rào cản thấp trong việc nhóm xác minh của bạn áp dụng công cụ nâng cao hơn nếu bạn chọn làm như vậy và không cần phải đào tạo thành nhà khoa học dữ liệu hoặc học ML. Chúng tôi sẽ không thảo luận về các dịch vụ cụ thể của các nhà cung cấp EDA hoặc cố gắng khảo sát thị trường ở đây. Quan điểm của chúng tôi là thế này:

Các nhóm xác minh nên được khuyến khích khám phá và đánh giá các dịch vụ có sẵn…

… để xem liệu quy trình làm việc và vòng đời phát triển sản phẩm của họ có mang lại lợi ích về mặt chi phí hay không. Do ngành EDA không ngừng phát triển nên các công cụ được cung cấp và công cụ xác minh đã trở thành một lĩnh vực có tính đổi mới cao trong ngành EDA trong một thời gian. Nhóm xác minh có trách nhiệm theo dõi những phát triển mới nhất và hợp tác với các nhà cung cấp EDA để đảm bảo lộ trình công nghệ của nhà cung cấp EDA có thể đáp ứng các yêu cầu hiện tại và tương lai của họ.

Một số cách (nhưng không phải tất cả) mà ML đang tăng cường cung cấp công cụ EDA nằm trong các lĩnh vực sau: –

• Tăng tốc gỡ lỗi bằng cách sử dụng phân cụm lỗi và phân tích chữ ký tự động.
• Tối ưu hóa thực thi để đảm bảo cài đặt công cụ tối ưu được sử dụng cho các lần chạy mô phỏng.
• Tối ưu hóa các lựa chọn động cơ chính thức để xác minh chính thức.
• Tăng tốc đóng phạm vi bảo hiểm bằng cách xếp hạng lựa chọn thử nghiệm và tối ưu hóa.

Bạn có thể coi quy trình xác minh như một tập hợp dữ liệu đầu vào và đầu ra dữ liệu, như minh họa bên dưới. Cả tập dữ liệu đầu vào và tập dữ liệu đầu ra được tạo đều có thể là ứng cử viên cho các cơ hội ML. Chúng tôi biết có thể tốn bao nhiêu công sức vào việc phân tích phạm vi bao phủ và phân tích kết quả kiểm tra. Ngay cả những cải tiến nhỏ về hiệu suất và hiệu quả trong những lĩnh vực then chốt này cũng có thể mang lại những khoản tiết kiệm đáng kể về chi phí, chất lượng và thời gian đưa ra thị trường.

Hình 6 ML cho công cụ EDA

Bước 3: Đào tạo các kỹ sư của bạn suy nghĩ như Nhà khoa học dữ liệu

Cho đến nay, chúng ta đã nói về các kỹ năng cốt lõi cần thiết để thực hiện phân tích dữ liệu thành thạo, nhưng tất nhiên có cả một nhánh phân tích dữ liệu thường được gọi là Khoa học dữ liệu, điều này rất thú vị và hấp dẫn vì nó mang đến cho chúng ta cơ hội khai thác dữ liệu của mình theo những cách khác nhau và mang lại những hiểu biết sâu sắc hơn về dữ liệu mà có thể không đạt được chỉ bằng trực quan hóa dữ liệu. Thường được gọi là ML hoặc Machine Learning, có một nguyên tắc lâu đời mà tất cả mọi người đều có thể tiếp cận được nếu được đào tạo cơ bản hơn một chút. Có sẵn các thư viện thuật toán làm sẵn; bạn có thể tìm thấy nhiều thứ trong số này được gói gọn một cách tiện lợi trong Python học hỏi thư viện chẳng hạn. Các kỹ sư xác minh tò mò thích đổi mới và giải quyết vấn đề xung quanh hiệu quả và hiệu quả của việc xác minh. Đây là những vấn đề hấp dẫn và đầy thử thách và việc giải quyết chúng bằng cách học và áp dụng các kỹ năng ML mới có thể mang lại động lực cao. Học những kỹ năng mới này cũng rất vui và thú vị và có nhiều nền tảng học tập trực tuyến tuyệt vời có thể đưa bạn từ con số XNUMX trở thành anh hùng trong một thời gian rất ngắn, ví dụ: Truy vấn dữ liệu, DataCamp, Udemy, coursera, mật mã, đến tên một vài.

Nếu nhóm kỹ thuật của bạn đã thành thạo các kỹ năng trực quan và phân tích dữ liệu cơ bản, đường dẫn dữ liệu của bạn rõ ràng và chính xác, đồng thời bạn đang thu thập đủ dữ liệu, thì sẽ có nhiều vấn đề tối ưu hóa trong quá trình xác minh có thể chín muồi đối với phương pháp ML - ví dụ: giảm tập hồi quy và tối ưu hóa, mô hình dự đoán nhu cầu tài nguyên, tối ưu hóa việc đóng vùng phủ sóng, v.v.

Ngoài ra, ngày nay còn có nhiều hứng thú về AI, đặc biệt là ứng dụng Generative AI vào các vấn đề như tạo thử nghiệm hoặc viết mã. Chúng ta sẽ không khám phá chủ đề đó ở đây nhưng khi Kỹ sư xác minh bắt đầu suy nghĩ và hành động như các nhà khoa học dữ liệu, có thể có nhiều cơ hội để thực hiện những cải tiến rõ ràng đối với cách xác minh các thiết kế phức tạp bằng cách sử dụng ít tài nguyên hơn, trong thời gian ngắn hơn và mang lại những sản phẩm có chất lượng cao hơn.

Tổng kết

Xác minh phần cứng là một vấn đề nặng về dữ liệu.

Kỹ sư xác minh đã biết điều này từ lâu và công việc hàng ngày của họ liên quan đến việc thu thập, xử lý và báo cáo về một số tập dữ liệu lớn. Lý do đây là một vấn đề nặng về dữ liệu là vì việc xác minh về bản chất là một vấn đề mở. Các nhóm kỹ thuật cần những phân tích sâu sắc để làm cho quy trình mở này có thể đo lường được và hữu hạn. Một số nhóm kỹ thuật vẫn đang làm việc với phân tích và trực quan hóa ở cấp độ bảng tính, thường sử dụng ảnh chụp nhanh dữ liệu tĩnh và các thao tác dữ liệu thủ công vốn tốn nhiều thời gian để cập nhật. Có thể có nhiều nguồn dữ liệu khác nhau chứa trong nhiều hệ thống khác nhau, điều này gây khó khăn cho việc kết hợp dữ liệu và tạo ra các mối tương quan sâu sắc.

Đối với nhiều người, thách thức là làm thế nào để khai thác dữ liệu xác minh bằng phân tích dữ liệu, điều này sẽ mang lại những cơ hội quan trọng để cải thiện việc xác minh phần cứng.

Có sẵn các nguyên tắc hoàn thiện để hỗ trợ việc này, đặc biệt là trong lĩnh vực kỹ thuật dữ liệu, phân tích dữ liệu và trực quan hóa dữ liệu. Các nhóm kỹ thuật cần nâng cao kỹ năng phân tích dữ liệu hiện đại hoặc thu hút các kỹ sư dữ liệu chuyên nghiệp, nhà phân tích dữ liệu, nhà khoa học dữ liệu để đưa những khả năng này vào quá trình phát triển sản phẩm. Điểm cuối là một tập hợp các phân tích tương tác và thời gian thực trực quan, dễ tiếp cận, chính xác và tự phục vụ. Người tiêu dùng phân tích không còn cần phải đưa ra yêu cầu để xem báo cáo cập nhật nữa. Họ phải tự mình truy cập vào các hình ảnh trực quan và hiểu cách xem chi tiết và lọc theo chế độ xem họ yêu cầu, họ có thể lưu hoặc nhúng chế độ xem này làm chế độ xem yêu thích, biết rằng đây là dữ liệu thời gian thực và tin tưởng rằng dữ liệu là chính xác. Việc tạo báo cáo trở thành nhiệm vụ ít phiền toái hơn khi bạn có số liệu phân tích trực tiếp trong tầm tay. Tính khả dụng được cải thiện và khả năng tiếp cận có nghĩa là việc phân tích được dành cho những người cần dữ liệu và hơn thế nữa, sự tò mò sẽ tiết lộ những hiểu biết sâu sắc chưa từng biết trước đây khi dữ liệu dễ xem và khám phá hơn nhiều.

Nếu bạn không làm gì khác, hãy tinh chỉnh các hành vi và quy trình thu thập dữ liệu lỗi của bạn…

… bởi vì phân tích lỗi có thể tiết lộ những hiểu biết sâu sắc có thể được xử lý trong thời gian tới.

Đó là mục tiêu phân tích dữ liệu xác minh cơ bản. Làm điều này đầu tiên. Thiết lập một đường dẫn dữ liệu rõ ràng, chính xác và đầy đủ trong đó điểm cuối là trực quan hóa dữ liệu có thể khám phá tuyệt vời. Ngoài ra, còn có nhiều khả năng hơn nữa để khám phá các tập dữ liệu sâu hơn và khai thác các kỹ thuật nâng cao hơn như ML hoặc AI để hiểu các mẫu dữ liệu chưa từng thấy trước đây và xây dựng các vòng phản hồi thành các quy trình và quy trình công việc để tối ưu hóa và giảm thời gian, công sức và chi phí. Chúng tôi lưu ý rằng tất cả các nhà cung cấp công cụ xác minh EDA chính thống đều đã xây dựng ML cho nhiều dịch vụ công cụ nâng cao của họ. Chúng có thể được khai thác ngay hôm nay mà không cần đào tạo kỹ sư của bạn thành nhà khoa học dữ liệu. Hầu hết các hoạt động xác minh đều liên quan đến một số loại lặp lại hoặc sàng lọc để đạt được kết quả. Bạn có thể đạt được điều đó với độ chính xác % chấp nhận được trong một khoảng thời gian ngắn bằng cách sử dụng ML/AI. Các nhóm hoặc nhóm nâng cao hơn đang thu hút các nhà khoa học dữ liệu được đào tạo có thể nhận ra những lợi ích này khi mức độ trưởng thành của dữ liệu ngày càng tăng và các nhóm kỹ thuật áp dụng văn hóa dữ liệu mạnh mẽ.

tác giả:
Bryan Dickman, Công ty TNHH Tư vấn Valytic,
Joe Convey, Công ty TNHH Acuerdo.

Cũng đọc:

Cuộc tìm kiếm lỗi: “Shift-Left, Right?”

Cuộc tìm kiếm lỗi: “Đúng theo thiết kế!”

Cuộc tìm kiếm bọ: Bọ sức mạnh

Cuộc tìm kiếm lỗi: “Chu kỳ sâu”

Cuộc tìm kiếm lỗi: Vấn đề nan giải của việc xác minh phần cứng

Chia sẻ bài đăng này qua:

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://semiwiki.com/eda/335551-the-quest-for-bugs-verification-is-a-data-problem/