Báo Cáo Đảm Bảo Chất Lượng Phần Mềm

Đề tài Tìm hiểu nghề Đảm bảo chất lượng phần mềm và ứng dụng tập trung vào việc khám phá quy trình, phương pháp và công cụ được sử dụng để đảm bảo chất lượng của phần mềm và ứng dụng. Nó bao gồm việc nghiên cứu các nguyên tắc cơ bản của kiểm thử phần mềm, tự động hóa kiểm thử, kiểm thử tích hợp và kiểm thử hệ thống. Đồng thời, nó cũng tập trung vào việc áp dụng các kỹ thuật kiểm thử đa dạng như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hồi quy và kiểm thử hồi quy tự động. Bên cạnh đó, đề tài cũng có thể tìm hiểu về các phương pháp và công cụ kiểm thử phần mềm phổ biến như Selenium, Appium, JUnit, và các kỹ thuật liên quan như kiểm thử dựa trên đặc tả và kiểm thử dựa trên rủi ro. Qua đó, nó sẽ giúp hiểu rõ hơn về vai trò quan trọng của đảm bảo chất lượng phần mềm và ứng dụng trong quá trình phát triển sản phẩm công nghệ.

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

-BÁO CÁO THỰC NGHIỆM THUỘC HỌC PHẦN:ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

ĐỀ TÀI Tìm hiểu nghề Đảm bảo chất lượng phần mềm và ứng dụng

Nhóm:

Lớp:

Hà Nội - 2023

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

-BÁO CÁO THỰC NGHIỆM THUỘC HỌC PHẦN:ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

ĐỀ TÀI Tìm hiểu nghề Đảm bảo chất lượng phần mềm và ứng dụng

Sinh viên:

Nhóm:

Lớp:

MỤC LỤC

DANH MỤC BẢNG BIỂU 5

LỜI CẢM ƠN 6

PHẦN I MỞ ĐẦU 7

1 Tên đề tài 7

2 Lý do chọn đề tài 7

3 Mục đích của đề tài 8

4 Mục tiêu của đề tài 8

5 Bố cục của đề tài 8

6 Phương pháp thực hiện đề tài 8

PHẦN II NỘI DUNG 10

CHƯƠNG 1 Tổng quan về Đảm bảo chất lượng phần mềm 10

1.1 Phần mềm 10

1.1.1 Khái niệm 10

1.1.2 Định nghĩa IEEE 10

1.1.3 Đặc điểm của phần mềm 11

1.2 Lỗi phần mềm và nguyên nhân 12

1.2.1 Lỗi phần mềm 12

1.2.2 Nguyên nhân gây lỗi phần mềm 12

1.3 Chất lượng phần mềm 14

1.4 Đảm bảo chất lượng phần mềm 16

1.4.1 Yêu cầu đảm bảo chất lượng phần mềm 17

1.4.2 Đảm bảo chất lượng và kiểm soát chất lượng 17

1.5 Các yếu tố ảnh hưởng đến chất lượng phần mềm 18

1.5.1 Các yếu tố chất lượng phần mềm theo McCall 18

1.5.2 Các yếu tố chất lượng phần mềm theo ISO 9126 và 2001 19

CHƯƠNG 2 Thách thức, xu hướng và lộ trình phát triển nghề SQA 23

2.1 Mục tiêu và thách thức của Đảm bảo chất lượng phần mềm 23

2.1.1 Mục tiêu Đảm bảo chất lượng phần mềm 23

2.1.2 Thách thức của Đảm bảo chất lượng phần mềm 23

2.2 Xu hướng của nghề Đảm bảo chất lượng phần mềm 27

2.3 Lộ trình phát triển của nghề Đảm bảo chất lượng phần mềm 28

2.4 Các kỹ năng để trở thành một kỹ sư SQA 30

2.4.1 Kỹ năng kỹ thuật 30

2.4.2 Kỹ năng mềm 30

CHƯƠNG 3 Ứng dụng của nghề Đảm bảo chất lượng trong thực tiễn 31

3.1 Ứng dụng các chuẩn và mô hình của SQA trong quản lý chất lượng phần mềm 31 3.1.1 Chuẩn ISO 9000 31

3.1.2 Mô hình CMMI 31

3.1.3 Khác biệt giữa ISO 9000 và CMMI 32

3.2 Kịch bản và kết quả kiểm thử trong thực tiễn 32

KẾT LUẬN 37

1 Những vấn đề đã giải quyết trong đề tài 37

2 Hạn chế 37

3 Hướng phát triển 37

TÀI LIỆU THAM KHẢO 38

DANH MỤC BẢNG BIỂ

Bảng 2.1 So sánh sản phẩm phần mềm và sản phẩm công nghiệp 26Bảng 2.2: So sánh sản phẩm phần mềm và các sản phẩm công nghệ khác 27Bảng 3.1: Kiểm thử chức năng thêm danh mục mới của trang web:

http://devpro.vn/admin.php 36

LỜI CẢM ƠN

Chúng em xin chân thành cảm ơn giảng viên ThS Nguyễn Đức Lưu

-người trực tiếp hướng dẫn, chỉ dạy chúng em trong suốt quá trình học tập học phần này và tìm hiểu để hoàn thành đề tài này Chúng em đã nhận được sự quan tâm giúp đỡ, hướng dẫn tận tình, tâm huyết của thầy Những gì chúng em nhận được không chỉ dừng lại ở kiến thức môn học mà nhiều hơn thế đó là những lời khuyên, chia sẻ thực tế từ thầy Chính nhờ phương pháp dạy học của thầy mà chúng em có cơ hội khám phá và phát huy khả năng của bản thân Những buổi thuyết trình chính là cơ hội tuyệt vời giúp chúng em rèn luyện sự tự tin, kỹ năng giao tiếp và kỹ năng làm việc nhóm Đây cũng chính là hành trang quan trọng giúp chúng em tự tin bước chân vào môi trường làm việc thực tế Với khoảng thời gian chưa nhiều nhưng với sự quyết tâm và cố gắng của từng thành viên trong nhóm, nhóm chúng em đã hoàn thành đề tài bằng chính khả năng của từng thành viên trong nhóm Tuy nhiên để hoàn thiện hơn, chúng

em rất mong nhận được những đánh giá, đóng góp ý kiến từ thầy và các bạn Chúng em xin chân thành cảm ơn!

Sinh viên nhóm 4

ra những hậu quả nghiêm trọng, như lỗi hệ thống, thất bại của dự án, tổn thất vềtài nguyên và uy tín của tổ chức Do đó, đảm bảo chất lượng phần mềm đóng vaitrò quan trọng trong quá trình phát triển phần mềm.

Sự chuyển đổi liên tục trong công nghệ và các xu hướng mới như phát triểnphần mềm Agile và DevOps đã làm thay đổi cách chúng ta tiếp cận SQA Điềunày đặt ra những thách thức mới và yêu cầu kiến thức sâu về công nghệ và quytrình phát triển phần mềm Bằng cách nắm vững các phương pháp và công cụhiện đại trong SQA, nhóm em tin rằng có thể đóng góp tích cực vào lĩnh vựcnày trong tương lai

“Đảm bảo chất lượng phần mềm” là một học phần rất hay và thực tế Dĩnhiên, không phải học xong là chúng em có thể trở thành những kỹ sư SQAngay được Thế nhưng thông qua học phần này, chúng em có được cái nhìn trựcquan hơn về quy trình đảm bảo chất lượng phần mềm; được học cách xác định,phân tích và lập kế hoạch SQA một cách hiệu quả Nhận thức được tầm quantrọng của đảm bảo chất lượng phần mềm, nhóm 4 đã bắt tay thực hiện đề tài

“Tìm hiểu nghề Đảm bảo chất lượng phần mềm và ứng dụng”.

3 Mục đích của đề tài

Đề tài “Tìm hiểu nghề Đảm bảo chất lượng phần mềm và ứng dụng”

nhằm khám phá vai trò quan trọng của SQA trong việc đảm bảo tính ổn định vàtin cậy của phần mềm Đồng thời cung cấp kiến thức cơ bản về SQA cho việc ápdụng trong thực tế, nghiên cứu xu hướng, cách thức hoạt động và thách thức củanghề

4 Mục tiêu của đề tài

Nắm vững kiến thức về SQA: Hiểu rõ quy trình, phương pháp và công cụliên quan đến SQA để cung cấp một nền tảng kiến thức về lĩnh vực này

Đánh giá tầm quan trọng của SQA: Xác định và thấu hiểu vai trò quantrọng của SQA trong việc đảm bảo chất lượng, tin cậy và hiệu quả của phầnmềm

Ứng dụng SQA trong thực tế: Cung cấp kiến thức cơ bản và hệ thống giátrị để áp dụng SQA trong các dự án phần mềm và công việc liên quan

Nghiên cứu và cập nhật kiến thức: Thăm dò các xu hướng mới, thách thức,

và ví dụ thực tế trong lĩnh vực SQA để cung cấp một cái nhìn toàn diện và cậpnhật về lĩnh vực này

5 Bố cục của đề tài

Nội dung chính của đề tài gồm 4 chương:

Chương 1: Tổng quan về Đảm bảo chất lượng phần mềm

Trình bày về khái niệm cơ bản của SQA, và các yếu tố ảnh hưởng của

nó trong quá trình phát triển phần mềm

Chương 2: Thách thức, xu hướng và lộ trình phát triển nghề SQA

Tập trung phân tích các thách thức và xu hướng hiện đại mà cácchuyên gia SQA phải đối mặt, đồng thời đưa ra lộ trình phát triển nghềSQA và các kỹ năng cần thiết để thành công trong lĩnh vực này

Chương 3: Ứng dụng SQA trong thực tế

Kiểm thử thủ công với trang web http://devpro.vn/admin.php

6 Phương pháp thực hiện đề tài

Tìm hiểu, thu thập thông tin liên quan đến Đảm bảo chất lượng phầnmềm

Thảo luận và phân tích thông tin đã thu thập

Viết báo cáo

Tạo slide thuyết trình về đề tài

PHẦN II NỘI DUNG CHƯƠNG 1 Tổng quan về Đảm bảo chất lượng phần mềm 1.1 Phần mềm

1.1.1 Khái niệm

Phần mềm dưới góc nhìn của người sử dụng:

− Chương trình thực thi được trên máy tính hoặc thiết bị chuyên dụng khác

− Nhằm hỗ trợ cho các nhà chuyên môn trong từng lĩnh vực chuyên ngành thực hiện tốt hơn các thao tác nghiệp vụ của mình

Phần mềm dưới góc nhìn của Chuyên viên Tin học: Đây là một hệ thốngbao gồm 3 thành phần cơ bản:

Trong đó:

Chương trình máy tính (code): giúp máy tính vận hành thực hành thực thi

các yêu cầu

Thủ tục: được yêu cầu để định nghĩa theo một thứ tự và lịch biểu của một

chương trình khi thực thi, phương pháp được triển khai và chịu trách nhiệmcho thực thi các hoạt động cần thiết cho việc tác động vào phần mềm

Tài liệu:

 Cần thiết cho người phát triển, sử dụng và bảo trì

 Cho phép sự phối hợp và cộng tác giữa các thành viên trong đội ngũphát triển; rà soát các sản phẩm lập trình và thiết kế

 Cung cấp một sự miêu tả cho ứng dụng và những phương pháp thíchhợp cho việc sử dụng

 Cung cấp cho đội ngũ bảo trì tất cả những thông tin yêu cầu về mãnguồn và công việc và cấu trúc cho từng module

Dữ liệu cần thiết cho sự vận hành của hệ thống:

 Dữ liệu bao gồm các tham số đầu vào, mã nguồn và danh sách tênthích hợp với phần mềm để đặc tả những cái cần thiết cho người sửdụng thao tác với hệ thống

 Dữ liệu cần thiết là chuẩn dữ liệu test

 Dựa trên sự tư duy để sáng tác ra phần mềm

 Phần mềm được sử dụng qua các versions

1.2 Lỗi phần mềm và nguyên nhân

1.2.1 Lỗi phần mềm

Có ba loại lỗi phần mềm chính:

Sai sót- Error: sự không nhất quán giữa giá trị đầu ra của phần mềm so

với giá trị đúng tương ứng với một đầu vào Một sai sót (error) là một sựnhầm lẫn hay sự hiểu sai trong quá trình phát triển của phát triển

Lỗi - Fault: một trạng thái là nguyên nhân làm cho hệ thống hỏng khi thực

hiện chức năng nào đó Lỗi xuất hiện trong phần mềm như là kết quả củamột sai sót Lỗi (fault, defect) xuất hiện trong phần mềm như là kết quả củamột sai sót

Hỏng hóc - Faulure: sự bất lực của phần mềm khi thực hiện một chức

năng theo đặc tả Một hỏng hóc (failure) là kết quả của một lỗi xuất hiệnlàm cho chương trình không hoạt động được hay hoạt động nhưng cho kếtquả không như mong đợi Các faults trở thành failures chỉ khi chúng được

“activated”, đó là khi người dùng cố gắng áp dụng các phần mềm cụ thể đó

bị faulty Do đó, nguồn gốc của bất kì Fauilure là một Error

1.2.2 Nguyên nhân gây lỗi phần mềm

Có 9 nguyên nhân gây lỗi phần mềm chính:

Lỗi định nghĩa yêu cầu:

 Sai sót trong định nghĩa các yêu cầu

 Không có các yêu cầu quan trọng

 Không hoàn chỉnh định nghĩa các yêu cầu

 Bao gồm các yêu cầu không cần thiết, các chức năng mà không thực

sự cần thiết trong tương lai gần

Thiếu sót trong quá trình kiểm thử:

 Kế hoạch kiểm thử chưa hoàn chỉnh

 Không hoàn thành sửa chữa các lỗi được phát hiện (do sơ suất hay áplực thời gian…)

Lỗi coding là do lập trình viên gây ra, như: sự hiểu lầm các tài liệu thiết kế,

sai sót trong ngôn ngữ lập trình, sai sót trong việc áp dụng CASE và cáccông cụ phát triển khác, sai sót trong lựa chọn dữ liệu

Lỗi thiết kế logic:

 Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai

 Quy trình định nghĩa có chứa trình tự lỗi

 Sai sót trong các định nghĩa biên

 Thiếu sót trong các trạng thái hệ thống phần mềm được yêu cầu

 Thiếu sót trong định nghĩa hoạt động trái luật trong hệ thống phầnmềm

Lỗi thủ tục: Các thủ tục trực tiếp cho người sử dụng đối với các hoạt động

là cần thiết ở mỗi bước của quá trình Chúng có tầm quan trọng đặc biệttrong các hệ thống phần mềm, nơi các tiến hành nhiều bước, mỗi bướctrong số đó có thể có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quảtrung gian

Lỗi tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo trì

đều có sai sót trong tài liệu thiết kế và trong tài liệu hướng dẫn tích hợptrong thân của phần mềm Những lỗi này có thể là nguyên nhân gây ra lỗi

bổ sung trong giai đoạn phát triển tiếp và trong thời gian bảo trì

Sự thiếu rõ ràng của các yêu cầu phần mềm:

 Sử dụng modun từ một dự án trước đó mà không phân tích đầy đủ vềthay đổi và thích nghi để phù hợp với yêu cầu mới

 Nhà phát triển bỏ qua một phần của các yêu cầu các chức năng

 Nhà phát triển bỏ qua các yêu cầu “nhỏ”, cuối cùng gây ra lỗi phầnmềm

Lỗi giao tiếp khách hàng và người phát triển:

 Hiểu sai chỉ dẫn của khách hàng như đã nêu trong các tài liệu yêu cầu

 Hiểu sai các yêu cầu thau đổi của khách hàng được trình bày với nhàphát triển bằng văn bản trong giai đoạn phát triển

 Hiểu sai của các yêu cầu thay đổi của khách hàng được trình bày bằnglời nói với nhà phát triển trong giai đoạn phát triển

 Hiểu sai về phản ứng của khách hàng đối với cá vấn đề thiết kế trìnhbày của nhà phát triển Thiếu quan tâm đến các đề nghị của kháchhàng đề cập đến yêu cầu thay đổi và khách hàng trả lời cho các câuhỏi nêu ra bởi nhà phát triển trên một phần của nhà phát triển

Không phù hợp với tài liệu và chỉ thị coding: Hầu hết các đơn vị phát

triển có tài liệu và tiêu chuẩn để xác định nội dung, trình tự và định dạngcủa văn bản, và code tạo ra bởi các thành viên Để hỗ trợ yêu cầu này, đơn

vị phát triển các mẫu và hướng dẫn mã hoá Các thành viên của nhóm pháttriển, đơn vị được yêu cầu phải thực hiện theo các yêu cầu này

1.3 Chất lượng phần mềm

Chất lượng sản phẩm phần mềm (software quality) là khả năng đáp ứngtoàn diện nhu cầu của người dùng về tính năng cũng như công dụng được nêu ramột cách tường minh hoặc không tường minh trong những ngữ cảnh xác định

Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổchức, cá nhân khác nhau:

Định nghĩa theo IEEE (1991):

 Định nghĩa 1: Chất lượng phần mềm là mức độ mà một hệ thống,thành phần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặctả.

 Định nghĩa 2: Chất lượng phần mềm là mức độ mà một hệ thống,thành phần hệ thống hay tiến trình đáp ứng được yêu cầu và sự mongđợi của khách hàng hay người sử dụng

Theo quan điểm thứ nhất của IEEE: chúng ta sẽ bị phụ thuộc quá nhiều vàotài liệu đặc tả của yêu cầu, dẫn đến nếu việc xác định yêu cầu bị sai, thiếu thìmột phần mềm được làm đúng với đặc tả chưa chắc đã là một phần mềm có chấtlượng

Theo quan điểm thứ hai của IEEE: khách hàng đôi khi không có kiến thức

về công nghệ, họ có thể đưa ra những mong muốn hết sức vô lý và có thể thayđổi yêu cầu với phần mềm nhiều lần, thậm chí thay đổi ngay trong giai đoạncuối Điều này gây nhiều khó khăn cho việc phát triển phần mềm

Định nghĩa theo Pressman:

Chất lượng phần mềm là sự phù hợp của các yêu cầu cụ thể về hiệu năng

và chức năng, các tiêu chuẩn phát triển phần mềm được ghi lại rõ ràng bằng tàiliệu với các đặc tính ngầm định của các phần mềm được phát triển chuyênnghiệp

Định nghĩa của Pressman đề xuất ba yêu cầu với chất lượng phần mềmphải được đáp ứng khi phát triển phần mềm:

 Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượngđầu ra của sản phẩm

 Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trọng hợp đồng

 Các đặc tính ngầm định cần được đáp ứng trong quá trình phát triểncho dù không được nói đến rõ ràng trong hợp đồng

Một số khái niệm khác về chất lượng phần mềm:

− Là sự thoả mãn yêu cầu, sản phẩm có đủ những đặc tính làm thoả mãnkhách hàng để tạo ra sự hài lòng về sản phẩm

− Không có thiếu sót trong sản phẩm:

 Mức độ mà một sản phẩm (hệ thống, một thành phần hay một xử lý)làm thoả mãn cho các yêu cầu đã được định nghĩa

 Mức độ mà sản phẩm làm thoả mãn cho khách hàng, cho nhu cầu củangười sử dụng hoặc cho các kỳ vọng về nó (IEEE, 1991)

Dưới quan điểm của người sử dụng và nhà phát triển phần mềm:

− Chất lượng phần mềm dưới góc nhìn của người sử dụng: Mức độ làmthoả mãn cho yêu cầu được đặc tả (requirements) hoặc mong đợi (needs)đối với phần mềm, với chi phí và thời gian hợp lý:

 Tính đúng đắn: đầy đủ, chính xác

 Tính tiện dụng: dễ học, giao diện trực quan, tự nhiên

 Tính hiệu quả: tối ưu sử dụng CPU, tối ưu sử dụng bộ nhớ, tối ưu sửdụng thiết bị

 Tính tương thích: Import/ Export dữ liệu, tính tương tác

 Tính tiến hoá: một trong các tính chất quan trọng nhất được quan tâmxem xét trong ngành Công nghệ Phần mềm Sự hoàn thiện dần và gắnliền với sự tiến hoá của phần cứng

− Chất lượng phần mềm dưới góc nhìn của người phát triển:

 Dễ làm & dễ cập nhật: sử dụng lại, hợp chuẩn, tiếp nhận công nghệmới, mềm dẻo

 An toàn

1.4 Đảm bảo chất lượng phần mềm

Đảm bảo chất lượng phần mềm (SQA) là đảm bảo dự án phần mềm sẽ hoànthành đúng đặc tả, theo chuẩn mực định trước; các chức năng đòi hỏi, không cóhỏng hóc và các vấn đề tiềm ẩn

Đảm bảo chất lượng phần mềm điều khiển và cải tiến tiến trình phát triểnphần mềm ngay từ khi dự án bắt đầu Nó có tác dụng “phòng ngừa” cái xấu, cáikém chất lượng.

Mục tiêu cuối cùng của đảm bảo chất lượng phần mềm là thoả mã kháchhàng (customer satisfaction) về:

− Thời gian

− Ngân sách

− Chất lượng

Theo Daniel Galin: Đảm bảo chất lượng phần mềm là một tập các hoạt

động đã được lập kế hoạch và có hệ thống, cần thiết để cung cấp đầy đủ sự tincậy vào quy trình phát triển phần mềm hat quy trình bảo trì phần mềm của sảnphẩm hệ thống phần mềm phù hợp với các yêu cầu chức năng kỹ thuật cũng nhưcác yêu cầu quản lý mà giữ cho lịch biểu và hoạt động trong phạm vi ngân sách

1.4.1 Yêu cầu đảm bảo chất lượng phần mềm

Yêu cầu chung của đảm bảo chất lượng phần mềm:

− Tuân thủ đặc tả là nền tảng để đo lường chất lượng

− Các chuẩn (standards) được xác định trước dùng để phát triển các tiêuchí chất lượng và dẫn dắt quá trình công nghệ

− Bên cạnh tuân thủ các yêu cầu tường minh (trong đặc tả), phần mềmphải tuân thủ các đặc tả không tường minh (dễ dùng, dễ bảo trì, tin cậy)

1.4.2 Đảm bảo chất lượng và kiểm soát chất lượng

Đảm bảo chất lượng (QA-Quality Assurance): là người chịu trách nhiệm

đảm bảo chất lượng sản phẩm thông qua việc đưa ra quy trình làm việc giữa cácbên liên quan

 Giám sát để đảm bảo các tiêu chuẩn về quy trình sản xuất phần mềmđược định nghĩa và tuân thủ nghiêm túc

 Công việc của QA liên quan đến quy trình (process)

Kiểm soát chất lượng (QC-Quality Control): là người chịu trách nhiệm

thực hiện công việc kiểm tra chất lượng phần mềm Có 2 vị trí QC thông thường

là manual QC (không đòi hỏi kinh nghiệm lập trình) và Automatic QC (đòi hỏi

kỹ năng lập trình)

 Khảo sát, chạy thử để đảm bảo phần mềm thoả mãn các yêu cầu vềchức năng và khả năng vận hành

 Báo cáo các lỗi để các bộ phận liên quan chỉnh sửa

 Công việc của QC liên quan đến sản phẩm (product)

1.5 Các yếu tố ảnh hưởng đến chất lượng phần mềm

1.5.1 Các yếu tố chất lượng phần mềm theo McCall

McCall đề ra 11 tiêu chí đảm bảo chất lượng phần mềm, chia thành 3 loại:

− Tiêu chí vận hành sản phẩm (Product operation factors): Hệ thống có

chạy tốt không, có dễ sử dụng không?

 Correctness (Tính đúng đắn): đặc tả về độ chính xác, sự toàn vẹn củaoutput

 Reliability (Tính tin cậy): lỗi khi cung cấp dịch vụ: tỉ lệ lỗi, thời gian

hệ thống chết Khả năng chịu lỗi, khả năng tự phục hồi

 Efficiency (Tính hiệu quả): tài nguyên phần cứng cần để thực hiện cácchức năng của phần mềm

 Integrity (Tính toàn vẹn): bảo mật của hệ thống với việc ngăn chặntruy cập trái phép

 Usability (Tính khả dụng): quy mô nguồn lực để đào tạo nhân viênmới sử dụng hệ thống

− Tiêu chí sửa đổi sản phầm (Product revision factors): Hệ thống có dễ

dàng sửa lỗi không, dễ dàng kiểm thử không?

 Maintainability: Mức công sức cần để bảo trì khi có lỗi, kiến trúc cácmodule như thế nào?

 Flexibility: Đề cập tới nguồn lực để thay đổi phần mềm khi kháchhàng thay đổi

 Testability: Có hỗ trợ test hay không? Tạo file log, backup

− Tiêu chí chuyển giao sản phầm (Product transition factors): Hệ thống có

dễ dàng chuyển đổi sang các phần cứng không, có thể tái sử dụngkhông?

 Portability: Nếu phần mềm cài ở môi trường mới, có giữ đc các tínhnăng như cũ không Thích nghi với nhiều môi trường (lớp nền, 21services…), cùng nhau tồn tại trong môi trường (no conflict), thay thếcho phần mềm khác có cùng chức năng

 Reusability: Có thể tái sử dụng các module nhỏ không, phần mềm cóthể tháo rời thành nhiều gói dùng lại được

 Interoperability: Phần mềm có cần Interface với các hệ thống đã có,phần mềm có giao tiếp & phương thức hợp chuẩn

1.5.2 Các yếu tố chất lượng phần mềm theo ISO 9126 và 2001

Tính chức năng (Functionality) là khả năng của phần mềm cung cấp các

chức năng đáp ứng được nhu cầu sử dụng khi phần mềm làm việc trongđiều kiện cụ thể:

 Tính phù hợp (Suitability): khả năng một phần mềm có thể cung cấp

một tập các chức năng thích hợp cho công việc cụ thể phục vụ mụcđích của người sử dụng

 Tính chính xác (Accuracy): khả năng của phần mềm có thể cung cấp

các kết quả, hiệu quả đúng đắn hoặc chấp nhận được với độ chính xáccần thiết

 Khả năng tương tác (Interoperability): khả năng tương tác với một

hoặc một vài hệ thống cụ thể của phần mềm

 Tính bảo mật/ an toàn (Security): khả năng bảo vệ thông tin và dữ liệu

của sản phẩm phần mềm

Tính tin cậy (Reability) là khả năng của phần mềm có thể hoạt động ổn

định trong những điều kiện cụ thể:

 Tính hoàn thiện (Maturity): khả năng tránh các kết quả sai

 Khả năng chịu lỗi (Fault tolerant): khả năng của phần mềm hoạt động

ổn định tại một mức độ, cả trong trường hợp có lỗi xảy ra ở phần mềmhoặc có những vi phạm trong giao diện