"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.
0 Comments:
Post a Comment