Bảo đảm chất lượng sản phẩm công nghệ tiêu chuẩn Nhật Bản



"Nhật Bản được biết đến là một trong các quốc gia hàng đầu thế giới về hàng loạt các sản phẩm chất lượng cao khiến cả thế giới phải thán phục. Tương tự, các sản phẩm công nghệ trước khi được ra đời ngoài việc phải trải qua quá trình kiểm thử gắt gao, để trở thành một sản phẩm được công chúng tin tưởng, nó còn phải đảm bảo được chất lượng. Vậy căn cứ vào đâu để có thể biết được rằng sản phẩm công nghệ đó đã đạt các tiêu chuẩn hay chưa? Bài viết này sẽ giới thiệu những tiêu chuẩn cơ bản nhất để đánh giá các sản phẩm đó.

Trước hết, chúng ta cùng liệt kê một số tiêu chuẩn thông dụng sử dụng quốc tế và một số tại Nhật, vì mục đích của bài viết không phải tìm hiểu kĩ về từng loại chất lượng, chúng ta sẽ đi tìm hiểu về từng vấn đề cần quan tâm trong đánh giá chất lượng thông qua so sánh các loại tiêu chuẩn với nhau".

1.Tiêu chuẩn quốc tế về đánh giá chất lượng các sản phẩm software ISO/IEC JTC 1/SC 7/WG 6.

2.Ngoài ra còn một số chỉ tiêu thuộc các hiệp hội đánh giá chất lượng tại Nhật Bản như: JUAS,IPA/SEC,JEITA,SLA.

Dưới đây chúng ta sẽ tìm hiểu lần lượt về 

⭐Mục đích

⭐Người sử dụng

⭐Đối tượng

⭐Tóm lược định nghĩa

⭐Tóm lược về các đặc tính,thông số(metrics) về chất lượng

⭐Quy trình sử dụng các tiêu chuẩn chất lượng

1.Mục đích


a.SC 7/WG 6 (SQuaRE) 


-Đánh giá thông qua việc kĩ thuật hóa các yêu cầu chất lượng của sản phẩm

-Kiểm định và định ra tiêu chuẩn đánh giá sau khi kĩ thuật hóa các yêu cầu về chất lượng của phần mềm.

-Bao gồm 2 bản model chất lượng về cấu hình để điều chỉnh,phối hợp với các thuộc tính của quá trình phát triển phần mềm có chất lượng mà khách hàng đề ra. Thêm vào đó, cung cấp cách thức đo lường phù hợp với đo lường thuộc tính chất lượng sản phẩm phầm mềm mà cả các kĩ sư phát triển phầm mềm,bên kiểm tra đánh giá và bên nghiệm thu sản phẩm đều có thể sử dụng.

b.JUAS (UVCII)


Khách hàng có thể định nghĩa được một cách chính xác non-functional requirement trong bản kĩ thuật về phát triển hệ thống thông tin.

c.Non-functional requirement grade 


Giúp giải quyết các hiểu lầm trong quá trình hội ý về non-functional requirement giữa người sử dụng và nhà cung cấp. 

Người sử dụng có thể cho hiển thị non-functional requirement một cách chi tiết.

Nhà cung cấp có thể đề xuất những phương thức thực hiện hoặc non-functional requirement một cách chi tiết.

d.IPA/SEC 


Bảo đảm và nâng cao độ tin cậy của hệ thống thông tin hỗ trợ các công việc liên quan đến hệ thống các cơ sở hạ tầng quan trọng.

Thúc đẩy,khuyến khích áp dụng các cơ chế quản lý chất lượng sản phẩm trong phát triển phần mềm của hệ thống thông tin cơ sở hạ tầng quan trọng. Cụ thể, để có thể triển khai việc thực thi các đề án khi vận hành và phát triển hệ thống, đối với hệ thống thiết lập hồ sơ,quản lý chất lượng,kiểm tra các đề án dựa trên phân tích các trường hợp có thể gây tổn hại, chúng ta phải thực hiện xác minh tính hiệu quả , kiểm chứng thông qua dữ liệu thực tế cũng như thu thập các thông tin tham khảo cần thiết để thực hiện các đề án đó.

e.JEITA (software developing SLA)


Đối với toàn bộ vòng đời của hệ thống IT, bằng cách ứng dụng SLA/SLM, chúng ta sẽ xoay vòng vòng lặp PDCA: gửi phản hồi đến quy trình “Phát triển hệ thống”về các vấn đề liên quan đến chất lượng sản phẩm của các dịch vụ công nghệ thông tin mà ta có thể thấy được thông qua quy trình “vận hành, bảo toàn hệ thống” ; xác định được mức độ nâng cao chất lượng sản phẩm của dịch vụ IT. 

f.JEITA (SLA guideline) 


Khi các công ty nhà nước sử dụng dịch vụ IT, chỉ ra cách sử dụng SLA một cách hữu hiệu nhất để có thể tạo ra sự cân bằng thích hợp trong 3 yếu tố: chất lượng dịch vụ, rủi ro, chi phí trong mối quan hệ giữa nhà cung cấp dịch vụ và người sử dụng, cho thấy các phương pháp tạo thành SLA cũng như chỉ tiêu đánh giá chung nhất của SLA đã được hội ý và chọn ra.  

2.Người sử dụng


a.SC 7/WG 6 (SQuaRE) 


Kĩ sư phát triển, người sử dụng,tổ chức đánh giá,người nhận kết quả hệ thống,phần mềm 

b.JUAS (UVCII)


Tại  công ty sử dụng sản phẩm đó, người chịu trách nhiệm về bản thông số kĩ thuật về phát triển hệ thống thông tin.

Trong quá trình kiểm chứng, vẫn cần xác nhận rằng toàn bộ những yêu cầu về hệ thống thông tin đã được định nghĩa được thực hiện hay chưa, thế nên người chịu trách nhiệm test hoặc review cũng có thể sử dụng các chỉ tiêu loại này.

Ngoài những người trực tiếp sử dụng được nêu ở trên, còn có giám đốc dự án hằng ngày thực hiện công việc làm rõ các định nghĩa trong bản thông số kĩ thuật về những yêu cầu liên quan đến bảo toàn, phát triển hệ thống một cách gián tiếp.

c.Non-functional requirement grade 


Người chịu trách nhiệm đặt hàng,tiếp nhận đơn hàng, liên quan đến quyết định,đưa ra các đề xuất, trình bày non-functional requirement khi phải định nghĩa những yêu cầu đó trong quá trinh phát triển hệ thống.

d.IPA/SEC 


Phòng hệ thống chịu trách nhiệm các công việc liên quan đến cơ sở hạ tầng quan trọng, những người chịu trách nhiệm phát triển phần mềm. 

e.JEITA (software developing SLA)


Người nhận ủy thác và người đi thuê ngoài dịch vụ phát triển phần mềm,dịch vụ vận hành công nghệ thông tin.

f.JEITA (SLA guideline) 


Người sử dụng và bên cung cấp dịch vụ IT

(Không nhất thiết phải là bên outsource mà có thể là bộ phận IT trong công ty. Cũng như thế, người sử dụng dịch vụ IT không chỉ đơn thuần là người cuối cùng sử dụng dịch vụ khi ra lò, mà còn có thể là bộ phận IT đó luôn).

3.Đối tượng


a.SC 7/WG 6 (SQuaRE) 


Chất lượng sản phẩm lúc sử dụng,chất lượng hệ thống,phần mềm.

b.JUAS (UVCII)


10 phương diện của yêu cầu về non-function của hệ thống thông tin doanh nghiệp: tính chức năng,độ tin cậy,khả năng sử dụng,tính hiệu suất,tính bảo đảm,khả năng linh động, tính hiệu quả,khả năng vận hành,yêu cầu kĩ thuật.

c.Non-functional requirement grade 


Những phương pháp để xác nhận giữa người đặt hàng và người nhận đơn hàng đối với non-functional requirement của nền tảng hệ thống.

Những bảng biểu,số liệu hóa mà người đặt hàng yêu cầu trong non-functional requirement của nền tảng cơ bản của hệ thống. 

d.IPA/SEC 


Những chỉ số tham khảo trong các qui trình lên kế hoạch,định nghĩa các yêu cầu,phát triển,vận hành và bảo toàn hệ thống thông tin cơ sở hạ tầng quan trọng và những target value tham khảo chúng. 

e.JEITA (software developing SLA)


Những SLA của các qui trình phát triển sau:

-Frame chung năm 2007

Định nghĩa các yêu cầu đối với hệ thống
Định nghĩa các yêu cầu đối với phần mềm, thiết kế phương pháp căn bản, thiết kế chi tiết,programming,kết hợp phần mềm,kiểm thử xác nhận chất lượng phần mềm.

Kết hợp hệ thống, kiểm thử xác nhận chất lượng hệ thống.

-Cam kết mô hình cải tiến độ tin cậy

Thiết kế hệ thống

Thiết kế phần mềm, programming,kiểm thử phần mềm

Kết hợp hệ thống,kiểm thử hệ thống,kiểm tra chấp nhận áp dụng

-Điều chỉnh mối liên quan với “SLA guideline”

f.JEITA (SLA guideline) 

Xem xét SLA của những hình thái IT service sau đây: Network,collocation,hosting,IT infrastructure outsourcing, business operation outsourcing, application management outsourcing,full-outsourcing,business process outsourcing, maitainance service·help desk·support service,security service. 

4.Tóm lược định nghĩa


a.SC 7/WG 6 (SQuaRE)


ISO/IEC 25000  series, System and Software product Quality Requirement and Evaluation (SQuaRE)

 -Bộ phận Quản lý chất lượng sản phẩm

 -Bộ phận chất lượng mẫu

 -Bộ phận đo lường chất lượng

 -Bộ phận yêu cầu chất lượng

 -Bộ phận đánh giá chất lượng

 -Bộ phận mở rộng

b.JUAS(UVCII)


 -230 chỉ tiêu trong 10 lĩnh vực

 -Định nghĩa, phương pháp đo lường , thước đo đo lường,  phương pháp giải thích của mỗi một chỉ tiêu

 -Cách thực hiện các chỉ tiêu trong các qui trình phần mềm từ định nghĩa các yêu cầu đến duy trì, vận hành.

 c.Non-functional requirement grade:

 “Hướng dẫn sử dụng (bản sử dụng)” và “Hướng dẫn sử dụng (bản giải nghĩa)” đã giải thích về định nghĩa các từ. hoặc hướng suy nghĩ cúa các tool, hoặc cách sử dụng non-functional requirement grade.

 -”Grade graph” nêu ví dụ về giá trị các mức độ của từng model system, liên quan đến những hạng mục non-function requirement quan trọng đối với khách hàng.

 -”List item” hiển thị các level và list non-functional requirement mà user hoặc ventor đều đồng ý.

 -Cây phả hệ: công cụ giúp có cái nhìn tổng thể,khái quát về từng mục trong list item hoặc grade graph.

 d.IPA/SEC


 -Điều tra thông tin profiling Hệ thống thông tin cơ sở hạ tầng quan trọng.

 -List item các phương pháp dùng để nâng cao độ tin cậy.

 -Metrics và reference value để quản lý định lượng (product, process).

 e.JEITA(software developing SLA)


 -Chỉ tiêu đánh giá chất lượng phát triển phần mềm.

 -Chỉ tiêu đánh giá liên kết với qui trình duy trì,vận hành và phát triển hệ thống.

 f.JEITA(SLA guideline)


 -SLA process.

 -481 hạng mục của Mức độ của dịch vụ,phương pháp đo lường, đơn vị đo lường, tiêu chuẩn lựa chọn, giá trị mức độ dịch vụ (giá trị tham khảo) liên quan đến dịch vụ, process, resource.

 - Mẫu hợp đồng.

 -Các ví dụ về 4 ngành công nghiệp: chế tạo, tài chính, logistics, service.

 5.Tóm lược về các đặc tính,thông số(metrics) về chất lượng


 a.SC 7/WG 6 (SQuaRE)


 -Model chung:

 Coi SQuaRE Model tham khảo thông thường, Chất lượng sản phẩm life cycle model của sản phẩm phần mềm, cấu tạo model chất lượng sản phẩm làm căn bản, hiển thị model chất lượng trong và ngoài, model chất lượng lúc sử dụng, model chất lượng dữ liệu, metrics chất lượng sản phẩm.

 -Model chất lượng trong và ngoài của sản phẩm

 Đối với các sản phẩm đang vận hành, đang được phát triển, định nghĩa những đặc tính của chất lượng sản phẩm như là tính chức năng, tính tin cậy, tính sử dụng, tính hiệu suất, tính duy trì, tính di động và hơn thế nữa, định nghĩa ra những đặc tính phụ.

 -Model chất lượng sản phẩm lúc sử dụng

 Định nghĩa ra các đặc tính của chất lượng sản phẩm lúc sử dụng sản phẩm như là tính hiệu quả, tính sản xuất, tính an toàn, tính hài lòng.

 - Chất lượng sản phầm dữ liệu

 Accuracy, Completeness, Consistency, Credibility, Currentness, Accessibility, Compliance, Confidentiality, Efficiency, Precision, Traceability, Understandability, Availability, Portability, Recoverability.

 -Metrics của chất lượng sản phẩm

 Định nghĩa ra các metrics của từng đặc tính của chất lượng sản phẩm.

b.JUAS (UVCII)


 Qui định10 đặc tính đối với non-functional requirement của hệ thống thông tin:

 tính chức năng, tính tin tưởng, tính sử dụng, tính hiệu suất, tính duy trì, tính di động (6 đặc tính của chất lượng hệ thống thông tin), hạn chế tổn hại, tính hiệu quả, tính vận hành, yêu cầu kĩ thuật.

 c.Non-functional requirement grade


 Bằng cách phân loại, sắp xếp chỉnh lý một cách tổng thể các mục yêu cầu thành 6 hạng mục lớn để có thể clarify rõ ràng hơn những non-functional requirement liên quan đến nền tảng hệ thống cũng như nhận thức chung được để không xảy ra rò rỉ giữa user-vendor, để nâng cao tính toàn diện. Ngoài ra,bằng cách thực hiện quá trình đồng nhất chi tiết hóa từng giai đoạn của model system, grade graph, item list, non-functional requirement item, sẽ hạn chế được việc xảy ra những hiểu lầm không đáng có giữa user và vendor.

 -Thiết lập 6 non-functional requirement item lớn bao gồm tính khả dụng, tính năng-tính mở rộng, vận hành-tính bảo đảm, tính di chuyển, bảo mật an toàn, môi trường hệ thống-sinh thái, quyết định các item nhỏ và vừa rồi thể hiện qua cây phả hệ.

 -Cứ mỗi một model system (Hệ thống gần như không có các ảnh hưởng xã hội, hệ thống mà các ảnh hưởng xã hội bị hạn chế, hệ thống bị ảnh hưởng xã hội lớn) đều chỉ ra grade graph đã định nghĩa mức độ tiêu chuẩn của non-functional requirement item.

Khi nói đến Đặc tính về chất lượng của hệ thống, đặc biệt là những yêu cầu về chất lượng liên quan đến nền tảng hệ thống, ngoài ISO/IEC 9126-1 thể hiện những đặc tính về chất lượng của sản phẩm phần mềm, còn tồn tại những yêu cầu chất lượng khác. Ví dụ: những mục liên quan đến vận hành, di chuyển hệ thống, môi trường cài đặt hệ thống hoặc hệ sinh thái..

 d.IPA/SEC


Với mục đích nâng cao độ tin cậy của hệ thống thông tin cơ sở hạ tầng quan trọng, cần phải chú ý đến những đặc tính còn thiếu sót trong các đặc tính của phần mềm, xác định các metrics đánh giá process và product, chỉ ra từng đinh nghĩa, thời gian lúc đo, cách sử dụng.

e.JEITA (software developing SLA)


Sắp xếp chỉnh lý Tiêu chuẩn đánh giá chất lượng sản phẩm như dưới đây (liên quan đến product, process, resource của phát triển phần mềm.

 -Product:

 ISO/IEC 9126-2 chất lượng bên ngoài: (phù hợp với qui trình phát triển)

 ISO/IEC 9126-3 chất lượng bên trong : (phù hợp với qui trình kiểm định)

 -Process:

 Chỉ số liên quan đến tình trạng chuẩn bị, tình hình thực hiện

 -Resource:

 Khả năng,chứng chỉ của developers, chứng nhận vendor

 Khi đang kiểm tra SLA/SLM của qui trình “phát triển hệ thống” ta phải đồng thời nhận thức được mối liên hệ của nó với qui trình tiếp ngay sau nó “Vận hành, bảo đảm hệ thống”, 2 qui trình này luôn kết nối với nhau, và để SLM của chúng đều liên kết với nhau, luôn phải chuẩn bị cho “chỉ tiêu đánh giá liên kết qui trình phát triển-vận hành”

 f.JEITA (SLA guideline)


 Qui định từng giá trị SLA, service level item (SLO) cho từng item đánh giá IT service, item đánh giá IT process management, item đánh giá IT resource. Phân chia và chỉnh lý các item về service level thành 8 nhóm chính: tính khả dụng, tính bảo mật, tính nguyên vẹn, độ tin cậy, tính xác thực, hiệu năng, tính mở rộng.

 6.Quy trình sử dụng các tiêu chuẩn chất lượng


 a.SC 7/WG 6 (SQuaRE)


 Qui trình của định nghĩa yêu cầu về chất lượng sử dụng đo lường chất lượng được qui định trong ISO/IEC 25030, qui trình đánh giá chất lượng được qui định trong ISO/IEC 25040

b.JUAS (UVCII)


 Phân thành giai đoạn khi chuẩn bị sửdụng và giai đoạn lúc sử dụng thực tế:

 1.Giai đoạn lúc chuẩn bị sử dụng:

 Đối với hệ thống thông tin của cá nhân công ty phát triển phần mềm đó, phải chọn

 ra những chỉ tiêu cần thiết hoặc quan trọng, đặt ra “những non-functional requirement cần định nghĩa, phù hợp với phát triển hệ thống thông tin mới”.

 2.Giai đoạn sử dụng trong thực tế:

 Tại bản thông số kĩ thuật của những requirement có ghi rõ những chỉ tiêu đã được định sẵn và những chỉ tiêu đã được định sẵn được coi là non-functional requirement với những giá trị được thực hiện trong hệ thống thông tin. Những chỉ tiêu đã được ghi rõ trong giai đoạn thông số yêu cầu thì trong giai đoạn kiểm chứng, phải xác nhận những function requirement và những thứ đó sẽ được thực hiện.

 c.Non-functional requirement grade


 1.Chọn model system:

 Chọn ra business necessary liên quan đến non-functional requirement,

 2.Quyết định level của những item quan trọng:

 Sử dụng list item, xác nhận level yêu cầu liên quan đến toàn bộ các mục của non-functional requirement.

 d.IPA/SEC


 So sánh từng giá trị mục tiêu với metrics đo đạc tại từng thời điểm: Trước khi thực hiện task, sau khi thực hiện task (hoặc là đang thực hiện task), sau khi hoàn thành dự án. Kiểm soát chất lượng sản phẩm mang tính định lượng.

 Kết quả của phân tích không chỉ là kiểm soát dự án, mà còn feedback cho tiêu chuẩn qui trình phát triển, kết nối với cải thiện qui trình. Kết quả đó phản ánh chân thực đối với dự án từ đó về sau, góp phần hướng tới cải thiện liên tục.

 e.JEITA(software developing SLA)


 (Phương pháp áp dụng những chỉ tiêu đánh giá chất lượng)

 Ở quy trình tiếp theo, phải áp dụng sau khi quyết định từ những chỉ tiêu đánh giá chất lượng liên quan đến product, process, resource, và service level item (SLO).

 (Phương pháp áp dụng những chỉ tiêu đánh giá liên quan qui trình phát triển, vận hành)

 1.Áp dụng vào acceptance test:

 Trước khi thực hiện acceptance test, phải qui định các tiêu chuẩn, các mục cần kiểm tra, sau đó áp dụng vào lúc thực hiện test này. Tiêu chuẩn và các mục cần kiểm tra sẽ được chọn từ các chỉ tiêu đánh giá liên kết với qui trình vận hành, phát triển và các chỉ tiêu liên quan đến các sản phẩm của chỉ tiêu đánh giá chất lượng. Hơn thế nữa, cũng có thể tham khảo kết quả của test và đánh giá giữa kì hoặc SLA của phát triển phần mềm.

 2.Áp dụng trong operation test:

 Qui định những tiêu chuẩn, mục đề cần kiểm tra trước khi thực hiện operation test, áp dụng lúc thực hiện test đó. Tiêu chuẩn và các mục cần kiểm tra sẽ được chọn trong các chỉ tiêu đánh giá liên kết qui trình vận hành, phát triển hoặc các chỉ tiêu liên quan đến product của chỉ tiêu đánh giá chất lượng sản phẩm. Hơn thế nữa, cũng có thể tham khảo các mục đánh giá có thể được đồng ý với tư cách là SLA của vận hành, bảo đảm.

 f.JEITA (SLA guideline)


 Step0:Tự đánh giá: SLA check list:Phân tích những yếu điểm sau khi thực hiện tự đánh giá trước khi thực hiên các mục SLA.

 Step1:Lựa chọn trong các đối tượng ngành :Phân loại ngành :Lựa chọn hình thái thích hợp từ 10 ngành nghề là đối tượng hiện tại.

 Step2:Lựa chọn nghiệp vụ:phân loại nghiệp vụ:Lựa chọn nghiệp vụ từ 10 nghiệp vụ hiện tại.

 Step3:Lựa chọn dịch vụ:List dịch vụ:Lựa chọn 1 trong 8 dịch vụ hiện tại.

 Step4:Lựa chọn mức độ ảnh hưởng:Bảng SLA(toàn bộ):Suy nghĩ đến business risk, chọn từ những nhân tố có khả năng ảnh hưởng đến dịch vụ.

 Step5:Lựa chọn SLO:Bảng SLA(chi tiết):suy nghĩ về business cost, thông qua các loại CHỈ TIÊU/CẦN THIẾT, và các mục CĂN BẢN/RIÊNG,lựa chọn các item ở mức độ cần thiết tối thiểu nhất.

 Step6:Lựa chọn giá trị level:bảng SLA(chi tiết):Lựa chọn giá trị tiêu chuẩn (giá trị mục tiêu) của dịch vụ đang được thực hiện trong công việc hiện tại.

 Step7:Đánh giá,kiểm chứng những chỉ tiêu:So sánh xem trạng thái của công việc hiện tại với mức độ tiêu chuẩn của dịch vụ đang thực hiện có mức độ của giá trị như nhau hay không, sao đó chỉnh sửa lại setting value.

 Step8:Soạn thảo hợp đồng:Hợp đồng mẫu:Thêm các item SLA đã được quyết định và các phương pháp đánh giá vào hợp đồng.

 Step9:Vận hành thử:Thỏa thuận mẫu SLA:Chỉnh sửa các giá trị đánh giá và các SLA item đã được thiết lập, sau đó hiệu đính lại bản thỏa thuận.

 Step10:Chính thức vận hành:Báo cáo tình trạng SLA mẫu:Tóm tắt lại những mục được ghi trong bản thỏa thuận SLA dưới dạng kết quả đánh giá vào bản báo cáo.
If you liked this article

Let's subscribe the updates of Scuti!
Share on Google Plus

About Ruby Stone

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.
    Blogger Comment
    Facebook Comment

0 Comments:

Post a Comment