Khảo sát và đánh giá sản phẩm phần mềm theo các tiêu chuẩn chất lượng

Từ cách nhìn của khách hàng, chất lượng được xác định là việc đáp ứng nhu cầu và đạt tới sự thỏa mãn; Từ cách nhìn của người phát triển, phần mềm được thiết kế tốt và sản phẩm tuân thủ t

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

VÀ TRUYỀN THÔNG

NÔNG THỊ NHÀN

KHẢO SÁT VÀ ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO CÁC TIÊU CHUẨN

CHẤT LƯỢNG

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

THÁI NGUYÊN - 2012

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

VÀ TRUYỀN THÔNG

NÔNG THỊ NHÀN

KHẢO SÁT VÀ ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO CÁC TIÊU CHUẨN

CHẤT LƯỢNG

Chuyên ngành: Khoa học máy tính

Mã số: 60 48 01 LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

NGƯỜI HƯỚNG DẪN KHOA HỌC PGS TSKH NGUYỄN XUÂN HUY

Thái Nguyên - 2012

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là công trình nghiên cứu, tìm hiểu và tham khảo của riêng tôi Các số liệu trong luận văn là trung thực

Tác giả

Nông Thị Nhàn

LỜI CẢM ƠN

Luận văn này được hoàn thành tại trường Đại học Công nghệ Thông tin và Truyền thông - Đại học Thái Nguyên Dưới sự hướng dẫn của PGS.TSKH NGUYỄN XUÂN HUY Tác giả xin bày tỏ lòng kính trọng và biết ơn sâu sắc tới thầy về sự tận tình hướng dẫn trong suốt thời gian tác giả làm luận văn

Tác giả xin bày tỏ lòng kính trọng và biết ơn tới PGS.TS Nguyễn Thiện Luận

đã cung cấp một số tài liệu trong quá trình làm luận văn

Trong quá trình học tập tại trường Đại học Công nghệ Thông tin và Truyền thông - Đại học Thái Nguyên tác giả thường xuyên nhận được sự quan tâm giúp đỡ, đóng góp ý kiến của các thầy cô trực tiếp giảng dạy và các cán bộ, giáo viên trong trường Tác giả xin bày tỏ lòng biết ơn sâu sắc đến những thầy cô đó

Tác giả xin bày tỏ lòng biết ơn tới Ban Giám Hiệu, các bạn đồng nghiệp trường Trung học Phổ thông Quang Trung đã tạo điều kiện sắp xếp công việc, giúp

đỡ tác giả trong thời gian học tập và làm luận văn

Xin chân thành cảm ơn anh chị em học viên lớp CAO HỌC K9A đã giúp đỡ, động viên, khích lệ tác giả trong quá trình học tập và nghiên cứu

Luận văn sẽ không hoàn thành được nếu không có sự quan tâm, động viên của người thân trong gia đình tác giả Đây là món quà tinh thần, tác giả xin gửi tặng gia đình thân yêu của mình với lòng biết ơn sâu sắc

Tác giả

MỤC LỤC

Lời cam đoan i

Lời cảm ơn ii

Mục lục iii

Danh mục các từ viết tắt v

Danh mục các hình ảnh, hình vẽ vi

MỞ ĐẦU 1

Chương 1 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM, CÁC TIÊU CHÍ ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM 4

1.1 Các thuật ngữ 4

1.2 Quy trình phát triển phần mềm 6

1.2.1 Các giai đoạn của quy trình phát triển phần mềm 6

1.2.1.1 Nghiên cứu sơ bộ 7

1.2.1.2 Phân tích hệ thống phần mềm 7

1.2.1.3 Thiết kế hệ thống 8

1.2.1.4 Xây dựng phần mềm 8

1.2.1.5 Thử nghiệm hệ thống 9

1.2.1.6 Thực hiện, triển khai 9

1.2.1.7 Bảo trì, nâng cấp 9

1.2.2 Các mô hình vòng đời phần mềm 10

1.2.2.1 Mô hình tăng trưởng (growth model) 10

1.2.2.2 Mô hình đồng bộ và ổn định (Synchronize-And-Stabilize Model) 11

1.2.2.3 Mô hình hướng đối tượng (Object-Oriented model) 12

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

1.4 Đánh giá phần mềm 13

1.4.1 Tầm quan trọng của việc đánh giá chất lượng phần mềm 14

1.4.2 Một số mô hình đánh giá chất lượng phần mềm 15

1.4.2.1 Mô hình ISO/IEC-9126 15

1.4.2.2 Mô hình ISO/IEC-14598 19

1.4.2.3 Một số mô hình khác 23

1.5 Các độ đo chất lượng phần mềm - Metrics (ISO/IEC 9126-2) 25

1.5.1 Độ đo trong 26

1.5.2 Độ đo ngoài 27

Chương 2 PHƯƠNG PHÁP ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO TIÊU CHUẨN CHẤT LƯỢNG 29

2.1 Phân loại phần mềm 29

2.1.1 Phân loại theo phương thức hoạt động 29

2.1.2 Phân loại theo khả năng ứng dụng 30

2.1.3 Phân loại theo nhu cầu của người dùng 30

2.2 Độ đo ngoài cho sản phẩm phần mềm 31

2.3 Các tiêu chí đánh giá các nhóm phần mềm 43

2.3.1 Nhóm phần mềm Quản lý giáo dục 44

2.3.2 Nhóm phần mềm Kế toán - Tài chính 46

2.3.3 Nhóm phần mềm tiện ích diệt virus 50

Chương 3 XÂY DỰNG MỘT SỐ TIÊU CHUẨN CHẤT LƯỢNG PHẦN MỀM 55

3.1 Bài toán quản lý trường học và những phần mềm ứng dụng 55

3.2 Đánh giá Phần mềm Quản lý trường học - V.EMIS 57

3.2.1 Tổng quan về V.EMIS 57

3.2.2 Đánh giá phần mềm V.EMIS (V.EMIS.Student) 59

3.2.3 Xây dựng tiêu chí đánh giá phần mềm V.EMIS (V.EMIS.Student) 63

KẾT LUẬN VÀ ĐỀ NGHỊ 67

TÀI LIỆU THAM KHẢO 68

DANH MỤC CÁC HÌNH ẢNH, HÌNH VẼ

Hình 1.1 Mô hình chất lượng ISO/IEC 9126-1 18

Hình 1.2 Qui trình kiểm tra đánh giá sản phẩm phần mềm 19

Hình 1.3 Thang đo chất lượng 21

Hình 1.4 Mối liên hệ giữa tiêu chuẩn ISO 9126 và ISO 14598 23

Hình 3.1 Giao diện chính chương trình V.EMIS.Student phiên bản 1.1.4 59

Hình 3.2 Giao diện chức năng “Nhập danh sách học sinh trúng tuyển” 60

Hình 3.3 Giao diện chức năng “Nạp và sửa hồ sơ ban đầu” 60

Hình 3.4 Giao diện chức năng “Phân phòng thi tự động” 61

MỞ ĐẦU

Cơ sở khoa học của đề tài

Khi nói đến chất lượng phần mềm, có nhiều định nghĩa tùy theo cách nhìn khác nhau Từ cách nhìn của khách hàng, chất lượng được xác định là việc đáp ứng nhu cầu và đạt tới sự thỏa mãn; Từ cách nhìn của người phát triển, phần mềm được thiết kế tốt và sản phẩm tuân thủ theo thiết kế đó (đáp ứng yêu cầu đặc tả chức năng); Ngoài ra chất lượng có thể được xác định như quy trình hiệu quả tạo ra sản phẩm mà không có lỗi nào và cung cấp giá trị đo được cho những người tạo ra sản phẩm và người dùng nó Còn theo định nghĩa hình thức về Chất lượng phần mềm

của Tổ chức Tiêu chuẩn quốc tế ISO trong Bộ Tiêu chuẩn 8402: “Chất lượng là khả

năng đáp ứng toàn diện nhu cầu của người sử dụng về tính năng cũng như công dụng được nêu ra một cách tường minh hoặc không tường minh trong những ngữ cảnh xác định” Những quan niệm và cách nhìn về chất lượng phần mềm nêu trên

có thể đầy đủ nhưng thiếu hẳn yếu tố định lượng

Chất lượng phần mềm luôn là mối quan tâm hàng đầu của người sử dụng Vì vậy, rất cần có những tiêu chí đánh giá cụ thể và phương pháp đo đạc mang yếu tố định lượng Đề tài mong muốn đề xuất các tiêu chí đánh giá phần mềm, giúp khách hàng cũng như người sử dụng có thể đánh giá khách quan về chất lượng phần mềm

sử dụng trong thực tế

Mục tiêu và nhiệm vụ của luận văn

Đề xuất những tiêu chuẩn chung để đánh giá một số nhóm phần mềm từ việc nghiên cứu, tìm hiểu các tiêu chuẩn đánh giá phần mềm đã có, ý nghĩa của các tiêu chuẩn đó Ngoài ra, đề tài tìm hiểu quy trình, phương pháp đánh giá phần mềm, từ

đó áp dụng thử nghiệm để đánh giá một phần mềm cụ thể

Các tổ chức tiêu chuẩn quốc tế như ISO, IEEE, đã công bố các bộ chu ẩn gồm các tiêu chí đánh giá chất lượng sản phẩm phần mềm như:

a ISO 9126: Software engineering Product quality

b ISO 14598: Information technology Software product evaluation

c ISO 12119: Software Packages - Quality Requirement and Testing

d ISO 9000-3: Quality Management and Quality Assurance Standards- part 3

e IEEE Std 1061-1992: Standard for Software Quality Metrics Methodology Trong mỗi bộ chuẩn nêu trên, không phải tất cả đều có thể áp dụng để đánh giá cho mọi phần mềm Trong mỗi bộ chuẩn chúng ta chỉ có thể áp dụng một phần nhỏ phù hợp với mỗi nhóm phần mềm khác nhau Vì vậy, cần có các tiêu chí theo một tiêu chuẩn chung, có mức tương đương với quốc tế để áp dụng Trong phạm vi

đề tài luận văn, với mong muốn tìm hiểu về các tiêu chuẩn, quy trình, phương pháp đánh giá chất lượng phần mềm, giúp khách hàng cũng như người sử dụng có thể đánh giá khách quan về chất lượng phần mềm sử dụng trong thực tế, tôi chọn đề tài

"Khảo sát và đánh giá sản phẩm phần mềm theo các tiêu chuẩn chất lượng"

Đối tượng và phạm vi nghiên cứu

Nghiên cứu, tìm hiểu các tiêu chí đánh giá chất lượng phần mềm của các tổ chức tiêu chuẩn trong nước và quốc tế; Khảo sát một số phần mềm ứng dụng; Áp dụng thử nghiệm đánh giá chất lượng cho một phần mềm cụ thể

Phương pháp nghiên cứu

Tìm hiểu các tiêu chí đánh giá chất lượng sản phẩm phần mềm thông qua việc thu thập, tổng hợp các sách, các bài báo, các tài liệu trên mạng bằng tiếng Việt, tiếng Anh

Nghiên cứu các tiêu chuẩn, hướng dẫn của các tổ chức tiêu chuẩn quốc tế (ISO/IEC, IEEE ) về đánh giá chất lượng sản phẩm phần mềm qua các bộ chuẩn Vận dụng thử nghiệm các tiêu chí đánh giá cho một phần mềm cụ thể

Cấu trúc và nội dung chính của luận văn

Cấu trúc và nội dung chính của luận văn gồm:

Tiêu chuẩn quốc tế, trình bày phương pháp và các tiêu chí đánh giá của các tổ chức đó; Trình bày độ đo các tiêu chí chất lượng phần mềm theo ISO/IEC 9126-2

- Chương 2 Phương pháp đánh giá sản phẩm phần mềm theo tiêu chuẩn chất lượng

Chương này chia nhóm, phân loại các loại phần mềm khác nhau; Trình bày

đề xuất về độ đo ngoài cho sản phẩm phần mềm; Khảo sát và đề xuất phương pháp đánh giá phần mềm theo tiêu chuẩn chất lượng cho một số loại phần mềm; Chi tiết thang điểm cho từng tiêu chí đánh giá cụ thể

- Chương 3 Xây dựng một số tiêu chuẩn chất lượng phần mềm

Đặt vấn đề cho bài toán Quản lý trong trường học hiện nay; Nêu những phần mềm được ứng dụng cho bài toán đó và nhu cầu cần được đánh giá; Áp dụng các phương pháp được đề xuất ở Chương 2, đánh giá Phần mềm Quản lý trường học V.EMIS; Xây dựng một số tiêu chuẩn của Phần mềm Quản lý trường học V.EMIS

- Phần kết luận và hướng phát triển

- Tài liệu tham khảo

Chương 1

QUY TRÌNH PHÁT TRIỂN PHẦN MỀM, CÁC TIÊU CHÍ ĐÁNH GIÁ

SẢN PHẨM PHẦN MỀM

1.1 Các thuật ngữ

Chất lượng: Là một tập hợp các tính chất và đặc trưng của sản phẩm tạo ra

cho nó khả năng thỏa mãn nhu cầu đã được nêu ra hoặc còn tiềm ẩn

Chất lượng ngoài: Là toàn bộ các đặc điểm của sản phẩm phần mềm từ góc

độ của người đánh giá phần mềm độc lập

Chất lượng phần mềm: Là sự đáp ứng các nhu cầu chức năng, sự hoàn thiện

và các chuẩn (đặc tả) được phát triển

Chất lượng trong: Là tổng hợp của tất cả các đặc điểm của sản phẩm phần

mềm từ góc độ của người phát triển phần mềm

Chất lượng sử dụng: Là cách nhìn của người sử dụng về chất lượng sản

phẩm phần mềm khi nó được cài đặt trong một môi trường và ngữ cảnh cụ thể

Đánh giá phần mềm: Tập hợp các tiêu thức xác định chất lượng phần mềm

và các phương pháp xác định tiêu thức này

Đo đạc: Là quá trình gán một giá trị hoặc phân loại cho một thực thể để mô

tả một thuộc tính của thực thể

Luật đo (metric): Là phương pháp đo, cũng như thang đo dùng trong các

phép đo đạc

Mô hình chất lượng: Là tập hợp các tiêu chuẩn dùng để chỉ ra các yêu cầu về

chất lượng cũng như đánh giá chất lượng của sản phẩm phần mềm

Phần mềm: là những chương trình điều khiển các chức năng phần cứng và

hướng dẫn phần cứng thực hiện các tác vụ của mình

Quy trình: Là phương pháp thực hiện hoặc các bước sản xuất ra sản phẩm Sản phẩm phần mềm: Là tập hợp các chương trình máy tính, thủ tục, tài liệu

liên quan, cũng như dữ liệu đi kèm

Tiêu chí: là bộ tiêu chuẩn dùng để kiểm định hay để đánh giá một đối tượng,

mà bao gồm các yêu cầu về chất lượng, mức độ, hiệu quả, khả năng, tuân thủ các qui tắc và qui định, kết quả cuối cùng và tính bền vững của các kết quả

Tiêu chuẩn: Là những quy định thống nhất được xây dựng theo một thể thức

nhất định do một cơ quan có thẩm quyền ban hành để bắt buộc hay khuyến khích áp dụng cho các bên liên quan

Tiêu chuẩn hóa: Là hoạt động thiết lập các điều khoản để sử dụng chung và

lặp đi lặp lại đối với những vấn đề thực tế hoặc tiềm ẩn nhằm đạt được mức độ trật

tự tối ưu trong những khung cảnh nhất định

Tính an ninh, an toàn: Là khả năng của sản phẩm phần mềm bảo vệ các

thông tin và các dữ liệu khi bị xâm nhập bất hợp pháp

Tính dung thứ được: Kết hợp các khả năng mở rộng chương trình, khả năng

thích ứng và tính tiện lợi

Tính dời chuyển được: Là những thuộc tính liên quan đến chi phí vận chuyển

một sản phẩm phần mềm từ ổ cứng gốc đến ổ cứng khác hoặc từ một môi trường hoạt động này đến môi trường hoạt động khác

Tính đơn giản: Mức độ dễ hiểu của một chương trình

Tính hiểu được: Là khả năng của sản phầm phần mềm cho phép người sử

dụng hiểu được phần mềm có thích hợp hay không và sử dụng nó như thế nào

Tính không ổn định: Là các thuộc tính liên quan đến các văn bản thủ tục khi

sản phẩm phần mềm được thay đổi thường xuyên

Tính mềm dẻo: Nỗ lực cần để cải biên một chương trình là chấp nhận được Tính ổn đinh: Là khả năng của sản phẩm phần mềm tránh được các tác

động bất ngờ từ các cải biên của phần mềm

Tính phổ biến: Mức độ tiềm năng trình ứng dụng của các bộ phận trong

chương trình

Tính thẩm tra được: Là không phụ thuộc vào các trình ứng dụng hay các bộ

phận được kiểm tra

Tính thiết thực: Là mức độ sản phẩm các công việc thích hợp được chuyển

tiếp tới các chức năng hợp thức dưới các điều kiện hoặc tình huống khác thường

Tính thử nghiệm được: Là khả năng của sản phẩm phần mềm cho phép cải

biên nó, và quá trình thử nghiệm không ảnh hưởng đến cấu hình và các bộ phận được tạo ra

Tính tiện ích: Là mức độ cho phép nhiều người sử dụng truy cập và sử dụng

phần mềm ở các kiểu khác nhau

Tính tiện lợi: Là khả năng của sản phẩm phần mềm trở nên dễ hiểu, dễ học,

dễ sử dụng và hấp dẫn người sử dụng

Tính tin cậy được: Khả năng của hệ thống có thể cung cấp cho người sử dụng

các thông tin về lỗi dịch vụ

Tính toàn vẹn: Có thể khống chế được việc truy cập của những người không

được phép sử dụng phần mềm và dữ liệu

1.2 Quy trình phát triển phần mềm

Quy trình phát triển phần mềm được bắt đầu từ khi hình thành ý tưởng và bao gồm nhiều vòng đời dưới dạng đường xoắn ốc Quy trình này thể hiện sự hoàn thiện dần từng giai đoạn của dòng sản phẩm theo thời gian Mỗi vòng đời thường bắt đầu từ công đoạn thiết kế, đặc tả các yêu cầu từ phía khách hàng đối với hệ thống và kết thúc sau công đoạn kiểm định chấp nhận một phiên bản của sản phẩm Vòng đời tiếp theo là một bước phát triển để tạo ra một phiên bản mới của dòng sản phẩm do công ty phần mềm đang bảo trì

Quy trình phát triển phần mềm thường được thực hiện bởi thứ tự các thao tác: Phân tích yêu cầu; Thiết kế sơ bộ; Thiết kế chi tiết; Lập trình và kiểm định đơn vị; Tích hợp và kiểm định tích hợp; Kiểm định hệ thống; Khai thác và bảo trì hệ thống

1.2.1 Các giai đoạn của quy trình phát triển phần mềm

Nhiều tổ chức phần mềm khác nhau có thể có các quy trình phát triển phần mềm khác nhau; Tên gọi của mỗi giai đoạn phát triển cũng khác nhau Nhưng hầu hết mọi phần mềm đều được xây dựng theo thứ tự các giai đoạn như:

- Nghiên cứu sơ bộ (Preliminary Investigation);

- Phân tích hệ thống phần mềm (Analysis);

- Thiết kế hệ thống (Design of the System);

- Xây dựng phần mềm (Software Constrution);

- Thử nghiệm hệ thống (System Testing);

- Thực hiện, triển khai (System Implementation);

- Bảo trì, nâng cấp (System Maintenance)

1.2.1.1 Nghiên cứu sơ bộ

Trước khi bắt tay vào một dự án, cần tạo một bức tranh về ý tưởng Ý tưởng này phải nắm bắt các yêu cầu và xuất hiện trong giai đoạn khởi đầu Các hoạt động trong thời gian này thường bao gồm thu thập các ý tưởng, nhận biết rủi ro, nhận biết các giao diện bên ngoài, các chức năng chính mà hệ thống cần cung cấp, và có thể tạo một vài nguyên mẫu dùng để “chứng minh các khái niệm của hệ thống” Ý tưởng có thể đến từ nhiều nguồn khác nhau: Khách hàng, chuyên gia trong lĩnh vực này, các nhà phát triển khác, chuyên gia về kỹ nghệ, các bản nghiên cứu tính khả thi cũng như việc xem xét các hệ thống khác đang tồn tại Một khía cạnh cần lưu ý là code viết trong thời kỳ này thường sẽ bị “bỏ đi”, bởi chúng được viết nhằm mục đích thẩm tra hay trợ giúp các giả thuyết khác nhau, chứ chưa phải code được viết theo kết quả phân tích và thiết kế thấu đáo

Giai đoạn này, nhóm phát triển hệ thống cần xem xét các yêu cầu của doanh nghiệp (cần dùng hệ thống), những nguồn tài nguyên có thể sử dụng, công nghệ cũng như cộng đồng người dùng cùng các ý tưởng của họ đối với hệ thống mới Ngoài ra người ta cũng tiến hành tạo một phiên bản thô của lịch trình và kế hoạch

sử dụng tài nguyên Một giai đoạn nghiên cứu sơ bộ không được thực hiện sẽ dẫn tới các hệ thống không được như mong muốn, tốn nhiều chi phí, bất khả thi và được định nghĩa lầm lạc

Kết quả của giai đoạn nghiên cứu sơ bộ là Báo cao kết quả nghiên cứu tính khả thi Khi hệ thống tương lai được chấp nhận dựa trên bản báo cáo này cũng là lúc giai đoạn phân tích bắt đầu

1.2.1.2 Phân tích hệ thống phần mềm

Đây được coi là giai đoạn quan trọng nhất trong công việc lập trình, người thực hiện nó là nhà phân tích Quá trình phân tích trả lời cho câu hỏi “Hệ thống cần phải làm gì?” Quá trình phân tích này bao gồm việc nghiên cứu chi tiết hệ thống, tìm cho ra nguyên lý hoạt động của nó và những vị trí có thể được cải thiện hoặc nâng cao hơn Ngoài ra, phân tích còn là việc xem xét các chức năng mà hệ thống cần cung cấp, các mối quan hệ giữa chúng, mối quan hệ bên trong với phía ngoài hệ

thống Trong toàn bộ giai đoạn này, nhà phân tích và người dùng cần cộng tác mật thiết với nhau để xác định các yêu cầu đối với hệ thống, tức là các tính năng mới cần phải được đưa vào Những mục tiêu cụ thể của giai đoạn này là:

- Xác định hệ thống cần phải làm gì

- Nghiên cứu thấu đáo tất cả các chức năng cần cung cấp và những yếu tố liên quan

- Xây dựng mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực

- Định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý

- Kết quả của giai đoạn này là bản Đặc tả yêu cầu (Requirements Specifications)

1.2.1.3 Thiết kế hệ thống

Sau giai đoạn phân tích, khi các yêu cầu cụ thể đối với hệ thống đã được xác định, giai đoạn tiếp theo là thiết kế cho các yêu cầu mới Việc thiết kế giải quyết câu hỏi: Hệ thống làm cách nào để thỏa mãn các yếu cầu đã được nêu trong Đặc tả yêu cầu Trong giai đoạn thiết kế, các công việc thường được thực hiện là:

- Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập;

- Nhận biết reports và những output mà hệ thống mới phải sản sinh;

- Thiết kế forms (vẽ trên giấy hay máy tính, sử dụng công cụ thiết kế);

- Nhận biết các thành phần dữ liệu và bảng tạo database;

- Ước tính các thủ tục giải thích quá trình xử lý từ input đến output

Kết quả giai đoạn thiết kế là Đặc tả thiết kế (Design Specifications) Bản Đặc

tả thiết kế chi tiết sẽ được chuyển sang cho các lập trình viên để thực hiện giai đoạn xây dựng phần mềm

1.2.1.4 Xây dựng phần mềm

Đây là giai đoạn viết lệnh (code) thực sự tạo hệ thống Từng người viết code thực hiện những yêu cầu đã được nhà thiết kế định sẵn Cũng chính người viết code chịu trách nhiệm viết tài liệu liên quan đến chương trình, giải thích thủ tục (procedure) do mình tạo nên được viết như thế nào và lý do cho việc này

Để đảm bảo chương trình được viết nên phải thỏa mãn mọi yêu cầu có ghi trước trong Bản đặc tả thiết kế chi tiết, người viết code cũng đồng thời phải tiến

hành thử nghiệm phần chương trình của mình Phần thử nghiệm trong giai đoạn này

có thể được chia thành hai bước chính:

- Thử nghiệm đơn vị: Người viết code chạy thử các phần chương trình của mình với dữ liệu giả (test/dummy) Việc này được thực hiện theo một kế hoạch thử, cũng do chính người viết code soạn ra Mục đích chính trong giai đoạn thử này là xem chương trình có cho ra những kết quả mong đợi Giai đoạn thử nghiệm đơn vị nhiều khi được gọi là “Thử hộp trắng” (White Box Testing)

- Thử nghiệm đơn vị độc lập: Công việc này do một thành viên khác trong nhóm đảm trách, thường chọn người không liên quan trực tiếp đến việc viết code của đơn vị Chương trình cần thử nghiệm để đảm bảo tính “độc lập” Công việc thử nghiệm này cũng được thực hiện dựa trên kế hoạch thử do người viết code soạn nên

Kết quả của giai đoạn này là tài liệu về các mã nguồn của mỗi module cùng với lời chú thích

1.2.1.5 Thử nghiệm hệ thống

Sau khi các thủ tục đã được thử nghiệm riêng, cần phải thử nghiệm toàn bộ

hệ thống Mọi thủ tục được tích hợp và chạy thử, kiểm tra xem mọi chi tiết ghi trong Đặc tả yêu cầu và những mong chờ của người dùng có được thỏa mãn Dữ liệu thử cần được chọn lọc đặc biệt, kết quả cần được phân tích để phát hiện mọi lệch lạc so với mong chờ

Kết quả của giai đoạn Thử nghiệm hệ thống là các mã nguồn đã được hiệu chỉnh cùng các chú thích Kèm theo đó là tài liệu hướng dẫn sử dụng, cài đặt và vận dụng chương trình, giải thích các cơ sở dữ liệu…

1.2.1.6 Thực hiện, triển khai

Trong giai đoạn này hệ thống vừa phát triển sẽ được triển khai Trước khi để người dùng thật sự bắt tay vào sử dụng hệ thống, nhóm các nhà phát triển cần tạo các file dữ liệu cần thiết cũng như huấn luyện cho người dùng để đảm bảo hệ thống được sử dụng hữu hiệu nhất

1.2.1.7 Bảo trì, nâng cấp

Bảo trì và nâng cấp phần mềm là công việc trải qua nhiều thách thức nhất trong quá trình phát triển phần mềm Tùy theo các biến đổi trong môi trường sử

dụng, hệ thống có thể trở nên lỗi thời hay cần phải được sửa đổi nâng cấp để sử dụng có hiệu quả Hoạt động bảo trì hệ thống có thể rất khác biệt tùy theo mức độ

sử đổi và nâng cấp cần thiết

Kết quả của của giai đoạn này là các ghi chép về các sửa đổi đã được thực hiện cùng các lý do

1.2.2 Các mô hình vòng đời phần mềm

Vòng đời phần mềm (SLC - Software Life Cycle) là thời kỳ tính từ khi phần mềm được đề xuất sử dụng cho đến khi bị loại bỏ (tức là hình thành đáp ứng yêu cầu vận hành, bảo trì, cho đến khi loại bỏ không đâu dùng nữa)

Mô hình vòng đời phần mềm là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm

Vòng đời phần mềm được chia thành các pha chính như: Xác định yêu cầu, triển khai, kiểm thử, bảo trì (vận hành)… Phạm vi thứ tự các pha khác nhau tùy theo từng mô hình dự án cụ thể

Vòng đời phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn Có sản phẩm được thiết kế và viết chương trình rất nhanh nhưng lại tốn hàng năm để bảo trì do phải sửa đổi chương trình cho phù hợp với các yêu cầu của khách hàng Cũng có những sản phẩm phần mềm sau một thời gian sử dụng người ta nhận thấy rằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt hơn là bảo trì sản phẩm cũ Có nhiều mô hình khác nhau, một số trong đó được ứng dụng khá phổ biến trên thế giới

1.2.2.1 Mô hình tăng trưởng (growth model)

Một phần mềm ra đời được đưa vào sử dụng, trong quá trình sử dụng ngoài việc phát triển và sửa chữa những sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán hoặc thêm một số chức năng… Mỗi lần nâng cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét, sửa đổi lại tài liệu các pha

Trong mô hình tăng trưởng, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đối độc lập nhau Mỗi thành phần được coi như một phần mềm

nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng Thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn

Ưu điểm của mô hình này là phần đầu tiên chứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng Thời gian làm phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu cầu đặt ra

Tuy nhiên, khó khăn trong việc sử dụng mô hình tăng trưởng chính là sự tích hợp phần mới phát triển với phần chương trình đã có, vì thế thiết kế phải có tính mở và tính mềm dẻo để thích nghi với việc mở rộng dần Sự điều khiển toàn

bộ quy trình phát triển phần mềm có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là khó khăn cho những người bảo trì Nếu không có những nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng

Nếu phần mềm có thể phân chia thành những thành phần tương đối độc lập nhau thì có thể áp dụng mô hình này Với những bài toán như xây dựng phần mềm Quản lý dịch vụ bay ở các công ty hàng không; Chương trình Quản lý tín dụng ngân hàng, Quản lý trường học… Tính liên kết giữa các phần khá cao thì không nên áp dụng mô hình này

1.2.2.2 Mô hình đồng bộ và ổn định (Synchronize-And-Stabilize Model)

Trong mô hình này, pha xác định yêu cầu được thực hiện bằng cách phỏng vấn rất nhiều khách hàng dự kiến Các đặc trưng của nhu cầu khách hàng được liệt

kê theo thứ tự ưu tiên, sau đó tài liệu đặc tả được soạn thảo Tiếp theo, công việc được chia làm ba hoặc bốn phần Phần thứ nhất chứa các đặc trưng quan trọng nhất,

phần thứ hai chứa các đặc trưng quan trọng thứ hai… Mỗi thành phần sẽ được xây dựng bởi một số nhóm nhỏ làm việc song song Cuối mỗi ngày, các nhóm đồng bộ hóa (Synchronize), tức là họ hợp lại các phần họ đã làm riêng biệt thành một phần đồng nhất, sau đó họ kiểm tra, sửa lỗi và kiểm thử Sự ổn định hóa (stabilize) được thực hiện ở giai đoạn cuối của mỗi phần Trong giai đoạn này những lỗi còn sót lại được phát hiện, được sửa chữa và thành phần được đóng gói (frozen), tức là không thực hiện thay đổi nào đối với đặc tả

Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau

có thể được kết hợp và cùng làm việc tốt Một điểm lợi của cách làm này là những người phát triển có thể sớm nhìn thấy sự hoạt động của phần mềm và có thể hiệu chỉnh các yêu cầu ngay trong quá trình các thành phần được xây dựng Mô hình này

có thể áp dụng ngay cả trong trường hợp các đặc tả ban đầu không hoàn thiện

1.2.2.3 Mô hình hướng đối tượng (Object-Oriented model)

Trong mô hình hướng đối tượng, tính lặp giữa các pha và giữa các phần trong một pha xảy ra nhiều hơn so với mô hình khác Một trong những mô hình giống như mô hình hướng đối tượng là mô hình núi đồi, nó được biểu diễn bằng các hình tròn có một phần chồng lên nhau Bên trong các vòng tròn có các mũi tên uốn cong ngụ ý nói rằng trong mỗi pha cũng có tính lặp giữa các phần Các pha có phần chung là:

- Pha yêu cầu và pha phân tích hướng đối tượng

- Pha thiết kế hướng đối tượng, pha lập trình và tích hợp

- Pha sử dụng và bảo trì

Kết luận: Có rất nhiều mô hình vòng đời phần mềm, tuy nhiên các mô hình nói chung có những thành phần tương tự nhau, chúng chỉ khác nhau ở trình tự tổ hợp, lắp ghép các thành phần Điểm khác biệt nổi trội giữa các mô hình là các vòng lặp thể hiện quy trình làm mịn tại các pha của quy trình

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

Như đã nêu ở phần mở đầu, chất lượng phần mềm có nhiều cách định nghĩa khác nhau tùy theo cách nhìn của mỗi đối tượng người dùng Từ cách nhìn của khách hàng, chất lượng được xác định là việc đáp ứng nhu cầu và đạt tới sự thỏa

mãn; Từ cách nhìn của người phát triển, phần mềm được thiết kế tốt và sản phẩm tuân thủ theo thiết kế đó (đáp ứng yêu cầu đặc tả chức năng); Theo Nguyễn Thiện

Luận - “Giáo trình đo lường phần mềm” - Chất lượng là một tập hợp các tính chất

và đặc trưng của sản phẩm tạo ra cho nó khả năng thỏa mãn nhu cầu đã được nêu ra hoặc còn tiềm ẩn Tôi chắc rằng còn nhiều định nghĩa về chất lượng phần mềm hơn nữa Sự mới mẻ trong quan niệm về chất lượng phần mềm chính là độ tin cậy đối với phần mềm đó Khi người sử dụng thỏa mãn với sản phẩm tức là khi nhu cầu được đáp ứng, và phần mềm có độ tin cậy cao thì đó là một phần mềm tốt

Những năm cuối thế kỷ XX, tổ chức ISO đã tập trung nghiên cứu rất nhiều vào vấn đề tiêu chuẩn chất lượng phần mềm Cách tiếp cận về các tiêu chí đánh giá chất lượng phần mềm của ISO càng được quan tâm và áp dụng nhiều hơn Kết quả của sự tập trung này là một loạt các bộ tiêu chuẩn nhằm hướng tới chất lượng toàn diện trong suốt vòng đời của sản phẩm phần mềm từ khi phôi thai cho tới lúc lạc hậu cần thay thế Theo cách tiếp cận của ISO, chất lượng toàn diện của phần mềm cần phải được quan tâm từ chất lượng quy trình tới chất lượng sản phẩm nội bộ Chất lượng sản phẩm đối sánh với yêu cầu của người dùng (chất lượng hướng ngoại)

và chất lượng phần mềm trong sử dụng

Chất lượng phần mềm đóng vai trò vô cùng quan trọng trong ngành Công nghiệp phần mềm Để đảm bảo phần mềm khi ra đời thỏa mãn được nhu cầu của khách hàng, các sản phẩm phần mềm đang gặp phải thách thức mới, đó là vấn đề chất lượng Điều này có nghĩa là sản phẩm phần mềm khi ra đời phải đạt được sự thỏa mãn, hoàn thiện, chuyên nghiệp và luôn đổi mới để đáp ứng được các yêu cầu khắt khe của người dùng Vậy phần mềm có đáp ứng được các đòi hỏi đó hay không cần phải có hoạt động đánh giá cụ thể

1.4 Đánh giá phần mềm

Đánh giá phần mềm là một phương pháp đo, tức là nó xác định giá trị của nguyên mẫu Kết quả của phép đo trả lời cho câu hỏi: Trong hai cái cái nào tốt hơn? Mức độ tốt? Có nhiều phương pháp đo do các tổ chức, các nhóm nghiên cứu đề xuất Tuy nhiên hiện nay chưa có một chuẩn đo phần mềm nào được chấp nhận rộng rãi trên toàn thế giới

1.4.1 Tầm quan trọng của việc đánh giá chất lượng phần mềm

Như đã nói, chất lượng phần mềm đóng vai trò vô cùng quan trọng trong ngành Công nghiệp phần mềm Một sai lầm dù rất nhỏ của phần mềm cũng có thể gây ra hậu quả nghiêm trọng Các nhược điểm trong phần mềm không chỉ gây phiền phức cho người dùng mà còn gây tổn thất rất lớn cho nền kinh tế Chúng ta đã chứng kiến sự cố máy tính Y2K hơn 10 năm về trước (năm 2000) Từ một giải pháp tiết kiệm bộ nhớ (chỉ dùng hai chữ số cuối để biểu diễn năm thay vì bốn chữ số) vào đầu những năm 70 của thế kỷ trước dẫn đến việc 25 năm sau người ta phải bỏ ra nhiều tỷ dollars để khắc phục sự cố này

Ở nước Mỹ ước tính hàng năm thiệt hại do nhược điểm trong phần mềm gây

ra lên đến 59,5 tỷ USD - Theo số liệu của Viện Công Nghệ và Tiêu Chuẩn Quốc Gia (NIST) thuộc Bộ Thương Mại Mỹ Và cũng theo NIST, thử nghiệm để phát hiện và loại bỏ khiếm khuyết ngay từ quá trình sản xuất phần mềm có thể giảm mức thiệt hại khoảng 22,2 tỷ USD trong tổng số 59,5 tỷ này Nhiều doanh nghiệp đã nhận thức đúng về vai trò của chất lượng phần mềm và định hướng xây dựng các quy trình sản xuất phần mềm theo chuẩn quốc tế với mục đích sản xuất phần mềm chất lượng

Ngày nay vấn đề đánh giá chất lượng sản phẩm phần mềm là một trong những vấn đề nòng cốt trong việc phát triển Công nghiệp phần mềm Nó đã được quan tâm không chỉ từ các quốc gia muốn phát triển Công nghiệp phần mềm, mà còn từ rất nhiều các tổ chức, trung tâm, Viện nghiên cứu của một ngành nghiên cứu khoa học về Công nghệ phần mềm

Để đánh giá được chất lượng phần mềm có đáp ứng được nhu cầu cho trước hay không thì cần phải đưa các tiêu chí đánh giá chất lượng ph ần mềm về một tiêu chuẩn chung và phải đánh giá chất lượng ph ần mềm trong thực tế (tức là phần mềm phải qua sử dụng) Hiện nay ở Việt Nam đã có một số tổ chức độc lập xây dựng các tiêu chí đánh giá chất lượng phần mềm như:

- Hiệp hội Doanh nghiệp Phần mềm Việt Nam (VINASA): Hiệp hội này đã thành lập Ban Công tác chất lượng VINASA (VINASA QUALITY COMMITEE -

VQC) Với nhiệm vụ xây dựng “Các tiêu chuẩn và đánh giá chất lượng phần mềm Việt Nam”, tư vấn cho các doanh nghiệp phần mềm về quy trình đảm bảo chất lượng phần mềm, cung cấp cho doanh nghiệp các chỉ tiêu, các tiêu chuẩn để đánh giá chất lượng phần mềm trong các lĩnh vực khác nhau dựa trên các chuẩn quốc tế ISO-9000, ISO-9126, ISO-14598…

- Công ty cổ phần phần mềm Hà Nội (HanoiSoftware): Kinh doanh trên các giải pháp phần mềm cho Website thương mại điện tử, phát triển và triển khai các cổng thông tin tích hợp Xây dựng các sản phẩm phần mềm đáp ứng các mô hình chất lượng của tiêu chuẩn ISO-9126

- Tập đoàn Bưu chính Viễn thông Việt Nam: Thực hiện đánh giá sản phẩm phần mềm theo tiêu chuẩn ISO/IEC 12119: 1994 về “Yêu cầu và kiểm tra chất lượng phần mềm” Các tiêu chí đánh giá về phần mềm của Trung tâm Công nghệ thông tin CDiT thuộc Học viện Bưu chính Viễn thông được xây dựng dựa trên 6 đặc tính chất lượng nêu trong tiêu chuẩn ISO/IEC 9126 và áp dụng tiêu chuẩn ISO/IEC 12119:1994 để đánh giá chung cho các tài liệu hướng dẫn, tài liệu mô tả sản phẩm, chương trình và dữ liệu

Tóm lại, mỗi một tổ chức áp dụng đánh giá phần mềm một cách riêng theo đặc thù của tổ chức đó Ở Việt Nam hiện nay vẫn chưa có một tiêu chuẩn chung nào

để đánh giá chất lượng phần mềm, chưa thể trả lời được câu hỏi đánh giá phần mềm trong nước theo các mặt nào, sử dụng tiêu chuẩn nào, bằng cách nào đánh giá được thực chất chất lượng phần mềm, độ tin cậy và chính xác của các phương pháp đánh giá Để đánh giá chất lượng của sản phẩm phần mềm có đáp ứng được các nhu cầu cho trước hay không thì cần áp dụng tiêu chuẩn và tiêu chí đánh giá cụ thể, có tiến trình đánh giá phù hợp

1.4.2 Một số mô hình đánh giá chất lượng phần mềm

 9126-3 Độ đo trong

 9126-4 Độ đo cho chất lượng sản phẩm phần mềm trong quá trình sử dụng

Mô hình chất lượng ISO-9126 trên thực tế được mô tả là một phương pháp phân loại và chia nhỏ những thuộc tính chất lượng, nhằm tạo nên những đại lượng

đo đếm được dùng để kiểm định chất lượng của sản phẩm phần mềm Dưới đây đưa

ra 6 tiêu chuẩn để đánh giá chất lượng sản phẩm phần mềm trong mô hình chất lượng ISO/IEC 9126-1

- Tiêu chuẩn 1 Tính chức năng (functionality): Khả năng của phần mềm

cung cấp các chức năng đáp ứng được các yêu cầu khi nó được sử dụng với những điều kiện cụ thể Tiêu chuẩn này là tổ hợp của các thuộc tính chất lượng:

+ Tính thích hợp (suitability): Phần mềm cung cấp một tập các chức năng thích

hợp cho một công việc cụ thể cũng như cho những mục tiêu của người sử dụng

+ Tính chính xác (accuracy): Phần mềm có thể cung cấp các kết quả chính xác + Tính tương tác (interoperability): Khả năng tương tác với các hệ thống khác + Tính chấp hành (compliance): Phần mềm có thể tuân theo các tiêu chuẩn,

những quy ước hoặc những điều chỉnh trong pháp luật

+ Tính an ninh - An toàn (security): Phần mềm có thể ngăn ngừa sự truy

nhập trái phép, bảo vệ được các thông tin bảo mật

- Tiêu chuẩn 2 Ổn định và tin cậy (reliability): Phần mềm duy trì hiệu suất

hoạt động của hệ thống khi sử dụng dưới những điều kiện xác định

+ Tính chắc chắn (maturity): Tránh được sự hỏng hóc như kết quả của

những lỗi trong phần mềm

+ Tính tha thứ lỗi (fault tolerance): Phần mềm duy trì hiệu suất hoạt động

trong những trường hợp xảy ra lỗi phần mềm hoặc sự xâm phạm giao diện của nó

+ Tính khôi phục (recoverability): Phần mềm thực hiện và khôi phục dữ liệu

trong trường hợp xảy ra lỗi

+ Tính sẵn sàng (availability): Phần mềm có thể ở trong trạng thái dễ thực hiện

một chức năng tại một thời điểm với những điều kiện xác định của việc sử dụng

- Tiêu chuẩn 3 Dễ sử dụng (usability): Phần mềm có thể hiểu được, học

được, sử dụng được và hấp dẫn người sử dụng

+ Có thể hiểu được (understandability): Giúp cho người dùng xác định được

liệu phần mềm có thích hợp hay không và cách sử dụng nó trong các công việc cụ thể

+ Có thể học tập - Nghiên cứu (learnability): Cho phép người dùng nhanh

chóng thu được các kiến thức thông qua việc sử dụng phần mềm trong công việc của họ

+ Dễ thao tác (operability): Người dùng có thể thao tác và điều khiển phần mềm

- Tiêu chuẩn 4 Hiệu quả (efficiency): Phần mềm cung cấp một hiệu suất

tương đối trong việc sử dụng tài nguyên hệ thống

+ Hiệu quả về thời gian (time behaviour): Thời gian xử lý, thời gian phúc

đáp của hệ thống và lưu lượng công việc

+ Hiệu quả về tài nguyên (resource utilisation): Sử dụng tài nguyên thích

hợp trong một khoảng thời gian hợp lý

- Tiêu chuẩn 5 Cập nhật - Bảo trì (maintainability): Phần mềm có thể sửa

đổi được

+ Phân tích được (analysability): Phần mềm có thể chuẩn đoán những sự

thiếu sót hoặc những nguyên nhân gây lỗi trong phần mềm, hoặc những phần sẽ được sửa đổi trong tương lai được xác định

+ Thay đổi được (changeability): Phần mềm cho phép một sự cải tiến xác

định sẽ được thực hiện

+ Ổn định (stability): Phần mềm giảm thiểu các hiện tượng bất ngờ từ những

nâng cấp của phần mềm

+ Có thể kiểm tra (testability): Cho phép kiểm tra sau khi thay đổi và nâng cấp

- Tiêu chuẩn 6 Linh hoạt (portability): Phần mềm sẽ được chuyển từ môi

trường này sang môi trường khác

+ Tính thích nghi (adaptability): Phần mềm có thể được thay đổi cho phù

hợp với các môi trường khác nhau

+ Cài đặt được (installability): Có thể cài đặt trên một môi trường cụ thể + Cùng tồn tại (co-existence): Có thể tồn tại cùng với các phần mềm khác

trong một môi trường chia sẻ tài nguyên

+ Tuân thủ - Phù hợp (conformance): Tuân theo các quy định hiện hành về

tiêu chuẩn linh hoạt

+ Khả năng thay thế (replaceability): Có thể được sử dụng thay thế cho một

phần mềm cụ thể khác

Hình 1.1 Mô hình chất lượng ISO/IEC 9126-1

1.4.2.2 Mô hình ISO/IEC-14598 [6]

ISO/IEC-14598 đưa ra quy trình kiểm tra đánh giá chất lượng các sản phẩm phần mềm dựa trên ISO/IEC 9126, bao gồm 6 phần chính dưới tiêu đề chung: Công Nghệ Thông Tin - Đánh giá sản phẩm phần mềm

Quy trình kiểm tra đánh giá chất lượng sản phẩm phần mềm được thực hiện với các bước được chỉ ra như hình sau:

Hình 1.2 Qui trình kiểm tra đánh giá sản phẩm phần mềm

Bước 1 Thiết lập các yêu cầu đánh giá

a) Xác định mục đích đánh giá: Người đánh giá cần xác định rõ mục đích

đánh giá nhằm quyết định sản phẩm có được chấp nhận, nghiệm thu hay không Hoặc nhằm so sánh các sản phẩm phần mềm hay lựa chọn sản phẩm trong số các sản phẩm được chỉ định

b) Xác định kiểu sản phẩm phần mềm : Kiểu sản phẩm được đánh giá sẽ phụ

thuộc vào giai đoạn tiến hành đánh giá trong chu trình s ản xuất và mục đích của việc đánh giá Mục tiêu của bước này là đảm bảo khi sản phẩm cuối cùng được sử

dụng bởi người dùng, nó sẽ đáp ứng nhu cầu của người dùng và như vậy nó có đủ các chất lượng cần thiết Chất lượng ngoài có thể chỉ được đánh giá đối với một hệ thống hoàn chỉnh mà sản phẩm phần mềm là một phần của nó Các độ đo ngoài áp dụng khi thực thi phần mềm Các giá trị của các phép đo ngoài phụ thuộc vào phần mềm, như vậy phần mềm phải được đánh giá như một bộ phận của một hệ thống hoạt động Đối với phần mềm mà có các chất lượng đang sử dụng, nó phải đáp ứng các nhu cầu của người dùng để thực hiện nhiệm vụ đặc biệt trong các môi trường cụ thể Phần mềm mà thực hiện thành công trong một môi trường này vẫn có thể có khiếm khuyết trong môi trường khác Việc đánh giá ngoài của các thuộc tính chất lượng nên thực hiện dưới các điều kiện càng gần với các điều kiện trông đợi càng tốt Nếu các yêu cầu chất lượng ngoài chưa đạt được, thì các k ết quả của việc đánh giá có thể được sử dụng như sự phản hồi để sửa đổi phần mềm và từ đó cải thiện chất lượng ngoài, như vậy sẽ hỗ trợ quá trình cải tiến liên tục

Các yêu cầu chất lượng trong được xác định và sẽ cho phép kiểm tra chất lượng của các sản phẩm trung gian Những thuộc tính trong c ủa phần mềm có thể được đo bởi độ đo trong Các độ đo trong nhìn chung được quan tâm khi sản phẩm phần mềm ở trong giai đoạn phát triển Những phép đo trong có thể được sử dụng như những chỉ dẫn cho các thuộc tính ngoài

c) Xác định mô hình chất lượng: Theo mục tiêu và kiểu phần mềm đã xác

định chúng ta có thể lựa chọn một mô hình đánh giá chất lượng sản phẩm phần mềm, trong đó bao gồm các luật và các tiêu chí đánh giá từ khâu thiết kế, xây dựng đến khi đạt được sản phẩm đầu cuối Xác định mô hình ch ất lượng là một khâu quan trọng trong bước xác định các yêu cầu Để đánh giá phần mềm cần thiết phải lựa chọn các tiêu chuẩn chất lượng thích hợp từ các mô hình ch ất lượng Một mô hình trong ISO/IEC 9126-1 là một ví dụ điển hình Những thuộc tính chất lượng cho từng trường hợp cụ thể phụ thuộc vào mục đích của việc đánh giá được xác định bởi một nghiên cứu về yêu cầu chất lượng Mô hình ISO /IEC 9126-1 cung cấp một danh sách kiểm tra hữu ích cho các vấn đề liên quan đến chất lượng, tuy nhiên những mô hình khác có thể thích hợp hơn trong các hoàn cảnh đặc biệt

Bước 2 Xác định chi tiết kỹ thuật

a) Lựa chọn độ đo: Các độ đo có thể khác nhau, tuỳ thuộc vào các môi

trường và giai đoạn của quá trình phát tri ển trong đó chúng được sử dụng Phép đo được sử dụng trong quá trình phát tri ển cần phải được tương quan với người dùng tương ứng phép đo , vì phép đo t ừ cách nhìn c ủa người dùng là cần thiết Những ví

dụ về độ đo là các luật trong ISO/IEC 9126-2 và 3 Khi tiến hành đo đạc, các phép

đo cần phải khách quan, có tính chất thực tiễn và có thể tái thực hiện dễ dàng

b) Thiết lập thang điểm đánh giá : Thiết lập các mức thang đánh giá cho các

độ đo, kết quả số sau khi thực hiện đánh giá sẽ được phân loại dựa theo một thang

đo có các mức khác nhau Các miền giá trị có thể được chia thô như sau:

- Chia thang thành hai miền chính: Không thoả mãn và thảo mãn

- Các miền này lại được chia thành 4 miền con (Hình 1.3)

Các tiêu chí đánh giá thường liên quan đến việc chỉ ra các thuộc tính con về chất lượng hoặc các liên kết mà có đánh trọng số giữa các thuộc tính con

Hình 1.3 Thang đo chất lượng c) Thiết lập tiêu chí đánh giá: Trong mỗi luật bao gồm nhiều tiêu chí hoặc

thuộc tính tạo cơ sở cho việc đánh giá các luật đó

Bước 3 Thiết kế việc đánh giá

Thực chất của việc này là xây dựng kế hoạch đánh giá mà trong đó qui định các hình thức đánh giá và lịch trình cho các công việc đánh giá

Một trong những bước quan trọng trong việc đánh giá là xây dựng bộ dữ liệu kiểm tra Dữ liệu kiểm tra thường là:

Dữ liệu kiểm tra chức năng: Bao gồm các dữ liệu cho phép kiểm tra đánh giá

hoạt động của các chức năng trong chương trình

Dữ liệu kiểm tra điều kiện biên: Một số chú ý khi thực hiện kiểm tra điều kiện biên:

- Nếu các giá trị đầu vào được giới hạn bởi hai giá trị A và B thì các trường hợp kiểm tra nên là A, B, các giá trị ngay trước A và ngay sau B

- Nếu các giá trị đầu vào yêu cầu một số lượng các giá trị khác nhau, hãy thử với các giá trị nhỏ nhất, lớn nhất các giá trị nhỏ hơn và lớn hơn của các giá trị này

- Nếu kết quả đầu ra là một bảng dữ liệu, hãy thử các dữ liệu đầu vào sao cho sinh ra bảng kích thước lớn nhất và bảng kích thước nhỏ nhất

- Đối với các cấu trúc dữ liệu bên trong, nên thử với các giá trị tới hạn của chúng

- Độ lớn của cơ sở dữ liệu: Chương trình sẽ ra sao nếu nhập số lượng dữ liệu rất lớn

Bước 4 Thực hiện đánh giá

Đánh giá chất lượng sản phẩm phần mềm được tiến hành với các bước: Đo đạc trực tiếp, so sánh các tiêu chí đánh giá, dựa trên các kết quả thu được và bảng định mức để đưa ra những kết luận

a) Đo đạc các thuộc tính: Bằng các công cụ phần mềm hoặc kinh nghiệm

của các chuyên gia, dựa vào bộ tiêu chuẩn đã được xây dựng tiến hành đánh giá các sản phẩm phần mềm

b) So sánh các tiêu chí: Theo quy trình đã xây dựng, để có một đánh giá phù

hợp với mục tiêu của công việc, trong các công thức tính điểm đánh giá cần phải xác định một số các hệ số trọng số, nhằm ưu tiên một số tiêu chí nhất định

c) Đánh giá các kết quả thu được: Đánh giá kết quả thu được dựa vào hệ số

chất lượng, được tính bởi công thức:

S V Q T I

S V Q T F

Trong đó:

TQVS - Tổng giá trị chất lượng phần mềm được đánh giá

ITQVS - Tổng giá trị chất lượng phần mềm trong trường hợp lý tưởng

Việc phân cấp phần mềm được dựa trên giá trị của hệ số chất lượng (QF)

Ảnh hưởng của sản phẩm phần mềm

14598-1 14598-2

14598-3 14598-4 14598-5

9126-1

Sản phầm phần mềm

Hình 1.4 Mối liên hệ giữa tiêu chuẩn ISO 9126 và ISO 14598

1.4.2.3 Một số mô hình khác

* Mô hình MIL-STD-498 của Bộ Quốc phòng Mĩ

Bộ tiêu chuẩn trong mô hình này có những đánh giá cho sản phẩm phần mềm mang tính đặc thù Nó bao gồm các tiêu chí sau:

- Mô tả chính xác

- Các trường hợp kiểm tra, thủ tục, dữ liệu, kết quả kiểm tra phải thích hợp

- Thể hiện một định hướng hay

- Thể hiện bằng chứng là một sản phẩm phần mềm thỏa mãn các điều kiện

- Có thể kiểm tra (testable)

- Có thể hiểu được (Understandable)

Các tiêu chí đánh giá trong mô hình này nhằm mục đích xác định chất lượng theo yêu cầu của người đầu tư Ngoài ra trong bộ tiêu chuẩn này còn có các tài liệu

mô tả độ đo, phương pháp đo và đánh giá cho các loại sản phẩm phần mềm

* Mô hình tiêu chuẩn của Úc

Hội đồng tiêu chuẩn Quốc gia của Úc đã lấy các tiêu chuẩn ISO làm cơ sở để xây dựng nên tiêu chuẩn về chất lượng của mình Các thuộc tính biểu thị chất lượng liên quan đến các đối tượng có cấu trúc c ủa chương trình được chia thành 4 loại được xác định như sau:

a) Tính đúng đắn - Correcness

- Có thể tính toán - Computable: Các kết quả tuân theo các luật lệ toán học

- Hoàn chỉnh -Complete: Mọi thành phần đều có cấu trúc

- Có giá trị - Assigned: Các biến phải được gán giá trị trước khi sử dụng

- Chính xác - Precise: Sự chính xác trong tính toán

- Được khởi tạo - Initialized: Phép gán cho các thực thể trước khi sử dụng

- Tiến triển - Progressive: Các nhánh, phép lặp sẽ làm giảm các chức năng

không ổn định

- Thay đổi - Variant: Vòng lặp theo dõi những ảnh hưởng từ các chức năng

hay thay đổi

- Nhất quán, toàn vẹn - Consistent: Không có ảnh hưởng phụ hay những lần

sử dụng sai

b) Cấu trúc - Structured

- Giải quyết - Resolved

- Đồng nhất - Homogeneous

- Hiệu quả - Effective

- Không dư thừa - Non-redundant

- Trực tiếp mô tả vấn đề - Direct Problem

- Có thể điều chỉnh

- Độc lập về giới hạn-Range-independent:Áp dụng cho biến, kiểu, vòng lặp

- Sử dụng - Utilized: Để điều khiển tính dư thừa dữ liệu

c) Tính modun - Modularity

- Tham số hoá - Parameterized: Mọi dữ liệu đầu vào được truy nhập thông

qua danh sách tham số

- Kết hợp - Loosely coupled: Dữ liệu được kết hợp

- Đóng gói - Encapsulated: Không sử dụng biến toàn cục

- Gắn kết - Cohesive: Các mối quan hệ giữa các thành viên được phát huy tối đa

- Đặc điểm chung - Generic: Tạo ra tính độc lập của từng modun

- Trừu tượng

d) Tính mô tả - Descriptive

- Xác định - Specified: Các điều kiện trước và sau phải được chỉ ra

- Chú thích - Documented: Các chú thích gắn liền với mọi khối chương trình

- Tự mô tả - Self-descriptive: Xác định những tên có nghĩa

Kết luận: Từ một số mô hình đánh giá chất lượng sản phẩm phần mềm đã nêu trên, ta có thể thấy ISO là mô hình chuẩn quốc tế, quy định những yêu cầu cần đạt được nhưng không chỉ ra cách thức để thực hiện Còn mô hình Tiêu chuẩn của

Úc, các phép đo được đưa ra chỉ cho ta các kết quả dạng định tính, thang đánh giá không được lượng hóa thành các con số cụ thể để so sánh các mức khác nhau Các

mô hình đánh giá chất lượng đều có các tiêu chí đánh giá đặc thù nhưng thiếu hẳn yếu tố định lượng, cần có một độ đo các tiêu chí cụ thể hơn

1.5 Các độ đo chất lƣợng phần mềm - Metrics (ISO/IEC 9126-2)

Độ đo chất lượng sản phẩm phần mềm bao gồm một số qui định về phạm vi

đo đạc và phương pháp xác định chất lượng sản phẩm phần mềm dựa trên một mô hình chất lượng mà được xác định trước đó Cụ thể hơn có thể chia ra thành hai lĩnh vực: Độ đo trong và độ đo ngoài Hai lĩnh vực đo này được áp dụng trong suốt thời

gian của chu trình sản xuất phần mềm (software life-cycle)

1.5.1 Độ đo trong

Các độ đo trong được đo trong quá trình thiết kế và viết code lệnh chương

trình (trong giai đoạn đầu của quá trình phát triển) Độ đo trong thường sử dụng để:

- Mô tả chất lượng sản phẩm phần mềm, bao gồm các đặc điểm cụ thể đã được định nghĩa trong ISO/IEC 9126-1 khi kiểm thử hay vận hành

- Khẳng định rằng một phần mềm đạt được các yêu cầu chất lượng bên trong Ngoài ra còn để đánh giá số các thuộc tính của một sản phẩm quyết định khả năng của nó có thoả mãn các yêu cầu đã đặt ra và các yêu cầu có liên quan hay không khi được sử dụng dưới những điều kiện đã xác định

Độ đo trong có thể được sử dụng để đo đạc các thuộc tính bên trong, hay chỉ

ra các thuộc tính bên ngoài theo quan điểm của người thiết kế Quan điểm này là không thay đổi trong phần mềm trung gian hay các sản phẩm có thể thực hiện được Các số đo của độ đo trong sử dụng số lần hay tần số của các thành phần tạo nên phần mềm mà chúng xuất hiện trên văn bản mã nguồn, trên sự biểu diễn đồ thị hay bảng các điều khiển, luồng dữ liệu, hay cấu trúc chuyển đổi trạng thái hay trên văn bản của chính sản phẩm và chúng có thể được đo đạc không cần hoạt động

Mặc dù được chỉ ra riêng rẽ, nhưng độ đo trong và độ đo ngoài có mối quan hệ gần gũi với nhau Khi đã xác định được các yêu cầu chất lượng sản phẩm phần mềm, mỗi đặc điểm cụ thể về chất lượng được lên danh sách, những yếu tố đó được coi là cần thiết cho sự hoạt động của phần mềm hay hệ thống chứa phần mềm đó và người dùng Khi đó, các độ đo ngoài tương ứng cùng với mức độ đáp ứng được xác định rõ ràng để lượng hoá các yêu cầu chất lượng và để sử dụng cho việc xác nhận phần mềm thoả mãn các yêu cầu sử dụng cụ thể trong khi phần mềm đang hoạt động

Mặt khác, các thuộc tính chất lượng bên trong của sản phẩm phần mềm được xác định rõ ràng để hình thành kế hoạch xác định các thuộc tính chất lượng bên ngoài

và sau đó đưa chúng vào trong các sản phẩm trung gian trong quá trình phát triển

Từ đó, các độ đo trong tương ứng và mức độ đáp ứng được chỉ rõ để xác định số lượng các thuộc tính chất lượng phần mềm bên trong và để sử dụng trong việc xác định các phần mềm trung gian phù hợp với sự đặc tả chất lượng bên trong trong thời gian phát triển phần mềm

Người ta cho rằng, độ đo trong nên được thiết kế càng phù hợp với mục đích của độ đo ngoài (nếu có thể) càng tốt, để tạo ra tính hợp lý của sự dự đoán các giá trị đã đo đạc của độ đo ngoài Tuy nhiên, nhìn chung là khó có thể thiết kế một mô hình lý thuyết chặt chẽ mà mô hình đó có các độ đo trong quan hệ chặt với mục đích độ đo ngoài Vì vậy, một mô hình lý thuyết không rõ ràng có thể được tạo ra và mức độ của mối quan hệ có thể được xây dựng qua thống kê trong thời gian sử dụng

độ đo

1.5.2 Độ đo ngoài

Các độ đo ngoài thích hợp với sản phẩm phần mềm đã được đánh giá và thường trong giai đoạn sau của quá trình phát triển hoặc sau khi đi vào quá trình vận hành Độ đo ngoài đem lại nhiều lợi ích cho người sử dụng, người đánh giá, người kiểm tra hay người phát triển trong việc đánh giá chất lượng sản phẩm phần mềm

và đưa ra sự trình diễn trong thời gian kiểm tra hoặc vận hành Độ đo ngoài thường được sử dụng để:

+ Mô tả chất lượng sản phẩm phần mềm trong quá trình kiểm tra hay vận hành, bao gồm các đặc điểm cụ thể về tiêu chí chất lượng phần mềm đã định nghĩa trong ISO/IEC 9126-1

+ Xác nhận phần mềm đáp ứng được các yêu cầu chất lượng bên ngoài Các yêu cầu đã đặt ra và các yêu cầu có liên quan khi được sử dụng dưới những điều kiện xác định

+ Dự đoán chất lượng thực tế đang sử dụng, nếu độ đo được sử dụng khi kiểm thử

+ Đánh giá và lấy thông tin phản hồi từ người dùng về mức độ đáp ứng các yêu cầu đặt ra và các yêu cầu có liên quan khi họ thực tế sử dụng

Vì vậy, các độ đo ngoài được thiết kế để đo đạc một sản phẩm phần mềm dựa trên những sự đo đạc hoạt động của các thành phần trong hệ thống, bằng cách

kiểm tra, vận hành và quan sát hệ thống hay phần mềm thực hiện Các phép đo dưới đây được coi là thích hợp cho các độ đo ngoài (measurement)

- Các phép đo hoạt động phần mềm khi kiểm thử, vận hành và trong việc kết hợp với phần mềm, phần cứng hay hệ thống khác

- Các phép đo hoạt động người dùng hay hiệu quả công việc của người dùng

- Các phép đo về các yếu tố khác như các vấn đề của cuộc sống và sức khoẻ con người, các tài nguyên môi trường tự nhiên, sự phá huỷ dữ liệu, tính không nhất quán hay sự sai lệch thông tin, sự mất an toàn, sự giảm sút dịch vụ, giảm sút các mặt thuận lợi hay sự giảm sút lợi nhuận trên thị trường, vấn đề tăng trưởng hay thiệt hại về kinh tế

Lưu ý: Các độ đo ngoài có thể sử dụng để chỉ ra các thuộc tính bên trong, các thuộc tính đó là các tính chất của chính sản phẩm phần mềm Ví dụ, mật độ các lỗi tìm thấy trong khi thực hiện việc kiểm tra có thể được sử dụng để dự báo và chỉ ra mật độ các lỗi còn lại có thể có trong phần mềm Bên cạnh đó, các số đo của các phép đo trong có thể được sử dụng để tính toán các phép đo ngoài Ví dụ, kích thước của chương trình hay kích thước của chức năng có thể sử dụng để chuẩn hoá phép đo ngoài

Kết luận: Dựa vào những cách thức trên, các độ đo cần có chi tiết đo đạc cụ thể mang yếu tố định lượng cho từng tiêu chí đã được nêu trong ISO 9126-1 Chẳng hạn như Sử dụng phép đo gì; Công thức tính; Phạm vi phần tử dữ liệu

Chương 2

PHƯƠNG PHÁP ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM THEO TIÊU

CHUẨN CHẤT LƯỢNG

2.1 Phân loại phần mềm

2.1.1 Phân loại theo phương thức hoạt động

Dựa vào phương thức hoạt động có thể chia phần mềm thành ba loại chính:

* Phần mềm hệ thống: Là phần mềm giúp đỡ hệ thống máy tính hoạt động Nhiệm vụ chính là tích hợp, điều khiển và quản lý các phần cứng riêng biệt của hệ thống máy tính

- Phần mềm hệ thống thực hiện các chức năng như chuyển dữ liệu từ bộ nhớ vào đĩa, xuất văn bản ra màn hình Các phần mềm hệ thống đặc biệt gồm: Hệ điều hành, chương trình điều khiển thiết bị hay trình vận hành (driver), công cụ lập trình, chương trình dịch, chương trình kết nối và chương trình tiện ích

- Thư viện phần mềm cung cấp các chức năng tổng quát cũng được xem là phần mềm hệ thống, như thư viện chuẩn C

- Phần mềm hệ thống được lưu trên các loại bộ nhớ không thay đổi được, như lên chíp, được gọi là phần sụn

* Phần mềm ứng dụng: Có khả năng làm cho máy tính thực hiện trực tiếp một công việc nào đó theo yêu cầu của người dùng Một số phần mềm riêng biệt thường có giao diện và tính năng tương tự, làm người dùng dễ dàng học và sử dụng Các phần mềm thường tương tác được với nhau để đem lại lợi ích cho người dùng Phần mềm ứng dụng được chia thành nhiều loại khác nhau:

+ Phần mềm văn phòng (Offices): Microsoft Office, Vietkey, Unikey, Adobe Reader, Solid Converter…

+ Phần mềm đa phương tiện (Multimedia): Window Media, KMPlayer, Gom, các chương trình convert…

+ Phần mềm đồ họa (Graphics): Photoshop, Corel, AutoCad…

+ Phần mềm tiện ích Internet: Internet Explorer, FireFox, Yahoo Messenger, Skype, các chương trình hỗ trợ dowload, tăng tốc truy cập internet…

+ Phần mềm bảo mật (Security): Các chương trình về Antivirus, Firewall, Deepfreez…

+ Phần mềm trò chơi (Game): Tất cả các games

+ Phần mềm giáo dục: Lecture Maker, Violet, Adobe Presenter, FlashPlayer… + Phần mềm cơ sở dữ liệu: SQL server, Access, Foxpro…

* Phần mềm chuyển dịch mã: Bao gồm trình biên dịch và trình thông dịch Loại chương trình này sẽ đọc các câu lệnh từ mã nguồn được viết bởi các lập trình viên bằng một ngôn ngữ lập trình và dịch nó sang dạng ngôn ngữ máy Cũng có thể dịch sang một dạng khác như là tập tin đối tượng (object file) và các tập tin thư viện (library file) mà các phần mềm khác (như hệ điều hành chẳng hạn) có thể hiểu để vận hành máy tính thực thi các lệnh

2.1.2 Phân loại theo khả năng ứng dụng

Dựa vào khả năng ứng dụng có thể chia phần mềm thành hai loại chính:

* Những phần mềm không phụ thuộc: Bất kỳ khách hàng nào cũng có thể mua để sử dụng Ví dụ, phần mềm về cơ sở dữ liệu như Oracle, đồ họa như Photoshop, soạn thảo và xử lý văn bản…

* Những phần mềm được viết theo đơn đặt hàng hay hợp đồng của một khách hàng cụ thể nào đó (công ty, bệnh viện, trường học…) Ví dụ, phần mềm điều khiển, phần mềm hỗ trợ bán hàng, quản lý nhân viên…

2.1.3 Phân loại theo nhu cầu của người dùng

Dựa vào nhu cầu của người dùng, chia phần mềm làm bẩy nhóm chính:

* Nhóm các hệ điều hành: Các chương trình quản lý ổ đĩa, chương trình quản

lý các tệp, quản lý thư viện, quản trị mạng, quản lý các chương trình dịch

* Nhóm chương trình dịch: Mỗi ngôn ngữ có một chương trình dịch riêng

* Nhóm các chương trình ứng dụng: Gồm có những chương trình soạn thảo văn bản, chương trình xử lý bảng tính điện tử, các chương trình đồ họa, chương trình tạo giao diện thân thiện giữa người dùng và hệ điều hành, các chương trình mở rộng các chức năng tệp

* Nhóm các tiện ích và trò chơi: Chương trình tìm và diệt virus, các trò chơi (games)