Kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG
NGHỆ





_












TRỊNH THỊ LÌNH

KỸ THUẬT HỖ TRỢ KIỂM SOÁT
CHẤT LƯỢNG PHẦN MỀM







LUẬN VĂN THẠC
SĨ

Hà Nội –
2011
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG
NGHỆ










TRỊNH THỊ LÌNH

KỸ THUẬT HỖ TRỢ KIỂM SOÁT
CHẤT LƯỢNG PHẦN MỀM





Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
M
ã số: 60 48 10




LUẬN VĂN THẠC
SĨ





NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Nguyễn Trường Thắng

Hà Nội –
2011

3
MỤC LỤC
DANH MỤC CHỮ VIẾT TẮT 5
LỜI MỞ ĐẦU 6
CHƯƠNG I: NỀN TẢNG LÝ THUYẾT 8
1.1. Quy trình phát triển phần mềm 8
1.1.1. Khái niệm 8
1.1.2. Một số mô hình phát triển 8
1.1.3. Mô hình phân tầng (layer) 11
1.1.4. Lập trình hướng đối tượng 12
1.2. Chất lượng phần mềm 13
1.2.1. Khái niệm 13
1.2.2. Đảm bảo chất lượng phần mềm (SQA_ Software Quality Assuarance) 14
1.2.3. Chuẩn phần mềm 23
1.2.4. Kiểm soát chất lượng phần mềm 23

CHƯƠNG II: MỘT SỐ KỸ THUẬT HỖ TRỢ KIỂM SOÁT CHẤT LƯỢNG PHẦN MỀM
26
2.1. Đánh giá 26
2.2. Tổ chức môi trường làm việc 28
2.2.1. Làm việc nhóm 28
2.2.2. Quy ước lập trình 29
2.3. Mô đun hóa các chức năng 30
2.4. Kỹ thuật kiểm thử 31
2.4.1. Kiểm thử đơn vị 32
2.4.2. Kiểm thử tích hợp 32
2.4.3. Kiểm thử chấp nhận 33
2.4.4. Kiểm thử hồi quy 33
4
2.4.5. Danh sách lỗi và chức năng bổ sung 33
2.5. Kỹ thuật hỗ trợ kiểm soát phiên bản 36
2.5.1. Một số đặc điểm cơ bản của công cụ kiểm soát phiên bản SVN 36
2.5.2. Vòng đời làm việc điển hình là: 39
CHƯƠNG III: ỨNG DỤNG THỰC TIỄN 41
3.1. Giới thiệu về dự án V.EMIS 41
3.2. Môi trường làm việc 42
3.2.1. Tổ chức môi trường làm việc 42
3.2.2. Quy ước lập trình 44
3.3. Thực hiện mô đun hóa các chức năng 48
3.4. Kết quả khi áp dụng kỹ thuật kiểm thử 51
3.5. Áp dụng kỹ thuật kiểm soát phiên bản 54
KẾT LUẬN 61
TÀI LIỆU THAM KHẢO 63

5
DANH MỤC CHỮ VIẾT TẮT

Chữ
viết tắt
Tiếng Anh
Tiếng Việt
CMM
Capability Maturity Model
Mô hình thuần thục khả năng
CMMI
Capability Maturity Model
Integration
Mô hình thuần thục khả năng tích hợp
CSDL
Database
Cơ sở dữ liệu
IEEE
Institute Electrical and Electronic
Engineers
Institute Electrical and Electronic
Engineers
ISO
International Standards
Organization
Tổ chức chuẩn Quốc tế
VCS
Version control system
Hệ thống kiểm soát phiên bản
QA
Quality Assuarance
Đảm bảo chất lượng
QC

Quality control
Kiểm soát chất lượng
SLC
Software life cycle
Vòng đời phát triển phần mềm
SQA
Software Quality Assuarance
Đảm bảo chất lượng phần mềm
SQAP
Software Quality Assuarance Plan
Kế hoạch đảm bảo chất lượng phần mềm
SQC
Software Quality Control
Kiểm soát chất lượng phần mềm
SVN
Subversion
Subversion
V&V
Verification and Validation
Xác minh và thẩm định
6
LỜI MỞ ĐẦU
Trong xã hội công nghệ thông tin ngày càng phát triển kéo theo ngành công
nghệ phần mềm cũng phát triển. Yêu cầu đặt ra đối với chất lượng mỗi sản phẩm
phần mềm trở nên nghiêm ngặt. Trong khi đó, quy trình phát triển phần mềm được
thực hiện với nhiều giai đoạn khác nhau và với rất nhiều hoạt động khác nhau. Mỗi
giai đoạn đều giữ một vai trò nhất định để góp phần xây dựng nên một phần mềm
đảm bảo chất lượng theo như chuẩn đảm bảo chất lượng. Một trong những vai trò rất
quan trọng đó là hoạt động kiểm soát chất lượng phần mềm. Nhiệm vụ chính là kiểm
soát xem phần mềm có đảm bảo yêu cầu chất lượng đặt ra hay không, các kiểm thử

có đáp ứng yêu cầu không?
Ngày nay, các yếu tố về chất lượng (Quality), chi phí (Cost) và thời hạn
(Delivery) thường được coi là 3 tiêu chí căn bản nhất cho sự thành công của một sản
phẩm nói chung và sản phẩm phần mềm nói riêng. Như vậy, để tạo ra một sản phẩm
phần mềm có chất lượng thì hoạt động kiểm tra phần mềm đóng vai trò rất quan
trọng, trong khi đó hoạt động này lại tiêu tốn nhiều chi phí và chiếm tỷ trọng khá lớn
về công sức, thời gian trong một dự án. Do đó một yêu cầu thực tiễn rất cấp thiết là
đội dự án phải có kế hoạch để đảm bảo phần mềm sản xuất ra có chất lượng trong khi
chi phí thấp. Chất lượng phần mềm luôn được kiểm soát trong suốt quá trình sản
xuất, từ lúc nhận yêu cầu cho đến khi sản phẩm đưa vào sử dụng, trong thời gian sử
dụng cho đến khi sản phẩm phần mềm đó lỗi thời hoặc có phần mềm khác thay thế.
Kiểm soát chất lượng phần mềm là quá trình giúp sớm phát hiện khiếm khuyết để từ
đó sớm đi đến khắc phục những khiếm khuyết của phần mềm trong suốt quá trình
phát triển. Phát hiện lỗi và khắc phục lỗi sớm giúp giảm bớt phát sinh lỗi mới và dẫn
đến chi phí cho sửa chữa cũng giảm bớt, nâng cao chất lượng cho phần mềm.
Cơ sở để đánh giá chất lượng phần mềm là: phần mềm khi phát triển phải đáp
ứng các yêu cầu đặt ra cũng như kỳ vọng của khách hàng và của bản thân nhà sản
xuất. Để đánh giá quy trình kiểm soát chất lượng phần mềm, người ta dựa vào bộ
chuẩn. Ví dụ như các bộ chuẩn quốc tế ISO, CMM, CMMI, IEEE…. Đáp ứng điều
đó thì nhiều kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm ra đời nhằm kiểm soát
quá trình phát triển phần mềm của các đội dự án sao cho phần mềm sản xuất ra đảm
bảo chất lượng theo như yêu cầu và mong muốn của khách hàng cũng như người sử
dụng sản phẩm đó. Thấy được tầm quan trọng trong vấn đề kiểm soát chất lượng nên
trong khóa luận này tôi thực hiện nghiên cứu về một số “Kỹ thuật hỗ trợ việc kiểm
soát chất lượng phần mềm”.
Trong thực tế, một phần mềm tốt thì thời gian sống phải dài. Sản phẩm phần
mềm phải liên tục tiến hóa sau khi bàn giao. Phần mềm mà không có sự tiến hóa là
7
phần mềm chết. Điều đó đồng nghĩa với chất lượng phần mềm kém, ít người sử dụng
thậm chí không có người sử dụng. Một ví dụ điển hình là Windows đã tiến hóa trong

20 năm qua, nó gặp phải nhiều lỗi và liên tục sửa chữa, nâng cấp để tạo các phiên bản
mới nhưng vẫn được đông đảo người sử dụng.
Thách thức lớn nhất đối với các đơn vị phát triển phần mềm là sự không ổn định
trong yêu cầu của người dùng. Ngoài ra, phần mềm phải triển khai trên quy mô lớn
mới bộc lộ hết được những khiếm khuyết về chức năng, lôgic trong chương trình do
có nhiều người sử dụng khác nhau. Sản phẩm vừa phát triển với tính năng mới lại
vừa sửa lỗi cũ trong khi triển khai quy mô lớn đó là tình huống khó nhất khi phát
triển phần mềm. Windows là một ví dụ điển hình. Kỹ thuật phát triển phần mềm và
kiểm soát chất lượng trong những hoàn cảnh như vậy là cả một khoa học và công
nghệ làm phần mềm, đòi hỏi kinh nghiệm thực tế và lý thuyết về công nghệ phần
mềm. Vì vậy, khi phần mềm sản xuất muốn đảm bảo chất lượng tốt thì phải luôn
được kiểm soát chặt chẽ.
Nội dung chính được trình bày trong khóa luận:
Chương I: Nền tảng lý thuyết
Giới thiệu một số kiến thức có liên quan như: quy trình phát triển, chất lượng
phần mềm, đảm bảo chất lượng phần mềm, kiểm soát chất lượng phần mềm…. giúp
có cái nhìn sơ bộ về những vấn đề có liên quan đến quá trình phát triển phần mềm
đảm bảo chất lượng.
Chương II: Một số kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm
Nghiên cứu một số kỹ thuật hỗ trợ quá trình kiểm soát chất lượng phần mềm.
Với những kỹ thuật hỗ trợ kiểm soát chất lượng sẽ làm cho sản phẩm phần mềm tạo
ra có chất lượng cao. Với những kỹ thuật được đề cập đến sẽ giúp giải quyết tình
huống khó khăn nhất trong phát triển phần mềm: phần mềm luôn thay đổi, vừa thực
hiện triển khai vừa phát triển.
Chương III: Ứng dụng vào thực tiễn của đội dự án
- Phân tích môi trường phát triển
- Thực hiện mô đun hóa các chức năng
- Áp dụng một số kỹ thuật hỗ trợ kiểm soát chất lượng vào quá trình phát
triển phần mềm.
8

CHƯƠNG I: NỀN TẢNG LÝ THUYẾT
1.1. Quy trình phát triển phần mềm
1.1.1. Khái niệm
Quy trình phát triển phần mềm là tập các giai đoạn và các kết quả tương quan
để sản xuất ra một sản phẩm phần mềm. Quy trình là một trong những yếu tố cực kỳ
quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi
thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có
thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của
công ty, hay ít nhất ở cấp độ dự án. Hầu hết các thao tác này được tiến hành bởi các
kỹ sư phần mềm.
Có 4 giai đoạn là nền tảng của hầu hết các quy trình phần mềm là:
 Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động
phải được định nghĩa.
 Phát triển phần mềm: Để phần mềm đạt được đặc tả thì phải có quy trình phát
triển này.
 Đánh giá thẩm định phần mềm: Phần mềm phải được đánh giá để chắc chắn
rằng nó thực hiện đúng những gì mà khách hàng mong muốn.
 Tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay đổi các
yêu cầu của khách hàng.
1.1.2. Một số mô hình phát triển
Có nhiều mô hình phát triển phần mềm: mô hình thác nước, mô hình chữ V, mô
hình tiến hóa, mô hình mẫu, mô hình xoắn ốc, mô hình CMM/CMMI. Mỗi mô hình
phát triển có những đặc điểm và ưu nhược điểm riêng, nó phù hợp với từng loại dự
án. Nên tùy theo dự án mà người quản lý dự án chọn cho mình mô hình phát triển
riêng, phù hợp với đặc điểm của dự án. Đặc điểm và ưu nhược điểm của mỗi mô hình
phát triển được thể hiện như sau:

9

Mô hình thác nước

Mô hình này làm cho ý nghĩa việc sản xuất phần mềm được thấy rõ hơn:
1. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục tiêu
được hình thành bởi sự trợ ý của hệ thống người tiêu dùng. Sau đó các yếu tố
này được định nghĩa sao cho có thể hiểu được bởi cả người phát triển và người
tiêu dùng.
2. Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quy trình, các bộ phận
và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như tất cả kiến
trúc của các hệ thống này. Thiết kế phần mềm tham gia vào việc biểu thị các
chức năng hệ thống phần mềm mà có thể được chuyển dạng thành một hay
nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm các đơn vị: Trong giai đoạn này, thiết kế phần mềm
phải được chứng thực như là một tập hợp nhiều chương trình hay nhiều đơn vị
nhỏ. Thử nghiệm các đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc
tả của nó.
Xác định yêu cầu
hệ thống
Yêu
cầu
cấp
phát
Thiết kế căn bản
Thiết kế chi tiết
Lập trình
Kiểm thử
Vận hành, bảo trì
Xác định yêu cầu

phần mềm
Kiểm chứng
Kiểm chứng
Kiểm thử
Kiểm chứng
Kiểm chứng
Kiểm chứng
Hình 1.1: Mô hình thác nước
10
4. Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay các
chương trình được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và
chứng tỏ được các yêu cầu của phần mềm được thỏa mãn. Sau khi thử nghiệm
phần mềm được cung ứng cho người tiêu dùng.
5. Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là pha lâu
nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt và được dùng
trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa được phát hiện
trong các giai đọan trước của chu kì sống; nâng cấp sự thực hiện của hệ thống
các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện về yêu cầu mới.
Mô hình này, yêu cầu tiếp cận một cách truyền thống, tuần tự và chặt chẽ đối
với việc phát triển phần mềm. Điểm yếu của mô hình này là nó không linh hoạt. Các
bộ phận của đề án chia ra thành những phần riêng của các giai đoạn. Với mô hình
này quá trình lặp lại là không tránh khỏi, nếu không quay lại thì dễ gặp bất trắc mà
lặp lại thì khó quản lý tiến độ dẫn đến không đáp ứng kịp thời yêu cầu của khách
hàng. Không phù hợp với hoàn cảnh phần mềm luôn thay đổi, thực hiện triển khai và
phát triển đồng thời. Thời gian thực hiện dài và khách hàng phải đợi đến giai đoạn
cuối mới có chương trình làm việc được. Nếu đến giai đoạn cuối mới phát hiện lỗi thì
có thể là một thảm họa. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ. Như là
một hệ quả và đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm,
phần cứng.
Mô hình chữ V

Mô hình chữ V gần giống với mô hình thác nước, pha sau thực hiện khi pha
trước đã thực hiện xong. Thực hiện test kết hợp với các pha trước nó.
Ưu điểm: có thể thực hiện một số việc song song, đạt được phần mềm chất
lượng, các pha tương thích và hỗ trợ nhau, các hoạt động kiểm thử được chú trọng.
Nhược điểm: các yêu cầu phần mềm phải được đặc tả rõ ràng, pha trước thực
hiện xong pha sau mới bắt đầu và người sử dụng không có cơ hội tham gia vào quá
trình phát triển.
Mô hình làm bản mẫu
Tạo ra một mô hình như thực tế cho phần mềm cần xây dựng. Thực hiện thiết
kế nhanh các bản mẫu rồi làm mịn dần và thực hiện trình diễn để người dùng đánh
giá rồi tiếp tục làm mịn các yêu cầu. Là cách tiếp cận thực tế nhất, thích hợp với các
hệ thống vừa và nhỏ. Nó được sử dụng hiệu quả khi kết hợp với các mô hình khác.
11
Mô hình xoắn ốc (Boehm-1988)

Hình1.2: mô hình xoắn ốc
Mô hình xoắn ốc dựa trên ý tưởng tối thiểu hóa rủi ro, bằng việc phân tích yếu
tố rủi ro ở mỗi bước lặp và sử dụng phương pháp làm bản mẫu, hoàn thiện và phát
triển hệ thống, duyệt lại và tiếp tục. Với phương pháp này thì các phiên bản được
hoàn thiện dần và luôn có sự tham gia đánh giá của khách hàng. Mô hình này thích
hợp để phát triển các hệ thống phần mềm với quy mô lớn. Trong mô hình này không
có sự phân biệt rõ ràng giữa hoạt động bảo trì và phát triển. Mỗi vòng lặp đại diện
cho một pha của quy trình phát triển phần mềm. Vòng trong cùng tập trung về tính
khả thi, vòng kế tiếp lo về định nghĩa các yêu cầu, kế đến là thiết kế v.v.
Trong mô hình này không có một pha nào được xem là cố định. Tuy nhiên, việc
thay đổi một cách linh hoạt đòi hỏi nhà phát triển và khách hàng phải có sự liên hệ
một cách chặt chẽ.
1.1.3. Mô hình phân tầng (layer)
Trong phát triển ứng dụng, để dễ quản lý các thành phần của hệ thống, cũng như
không bị ảnh hưởng bởi các thay đổi, người ta hay nhóm các thành phần có cùng

chức năng lại với nhau và phân chia trách nhiệm cho từng nhóm để công việc không
bị chồng chéo và ảnh hưởng lẫn nhau. Bạn sẽ nghe nói đến thuật ngữ kiến trúc đa
tầng/nhiều tầng, mỗi tầng sẽ thực hiện một chức năng nào đó, trong đó mô hình ba
tầng là phổ biến nhất. Mô hình ba tầng này là gì? Là tầng trình diễn (Presentation),
tầng logic (Business Logic), và tầng CSDL (Data Access). Các tầng này sẽ giao tiếp
với nhau thông qua các dịch vụ (services) mà mỗi tầng cung cấp để tạo nên ứng
12
dụng, tầng này cũng không cần biết bên trong tầng kia làm gì mà chỉ cần biết tầng kia
cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi.
Tầng trình diễn (Presentation Layer)
Tầng này làm nhiệm vụ giao tiếp với người dùng cuối để thu thập dữ liệu và
hiển thị kết quả/dữ liệu thông qua các thành phần trong giao diện người sử dụng.
Tầng này sẽ sử dụng các dịch vụ do tầng Business Logic cung cấp. Trong .NET thì
bạn có thể dùng Windows Forms, ASP.NET hay Mobile Forms để hiện thực tầng
này.
Trong tầng này có 2 thành phần chính là User Interface Components và User
Interface
- UI Components là những phần tử chịu trách nhiệm thu thập và hiển thị thông
tin cho người dùng cuối. Trong ASP.NET thì những thành phần này có thể là
các TextBox, các Button, DataGrid…
- UI Process Components: là thành phần chịu trách nhiệm quản lý các qui
trình chuyển đổi giữa các UI Components. Ví dụ chịu trách nhiệm quản lý các
màn hình nhập dữ liệu trong một loạt các thao tác định trước như các bước
trong một Wizard…
Business Logic Layer
Tầng này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do
tầng Data Access cung cấp, và cung cấp các dịch vụ cho tầng Presentation. Tầng
này cũng có thể sử dụng các dịch vụ của các nhà cung cấp thứ 3 (3rd parties) để thực
hiện công việc của mình (ví dụ như sử dụng dịch vụ của các cổng thanh toán trực
tuyến như VeriSign, Paypal…).

Data Access Layer
Tầng này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của
ứng dụng. Thường tầng này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu
như SQL Server, Oracle, … để thực hiện nhiệm vụ của mình. Trong tầng này có các
thành phần chính là Data Access Logic, Data Sources, Servive Agents).

1.1.4. Lập trình hướng đối tượng
Lập trình hướng đối tượng (Object-oriented programming - OOP), là kỹ thuật
lập trình hỗ trợ công nghệ đối tượng. OOP được xem là giúp tăng năng suất, đơn giản
13
hóa độ phức tạp khi bảo trì cũng như mở rộng phần mềm bằng cách cho phép lập
trình viên tập trung vào các đối tượng phần mềm ở bậc cao hơn. Ngoài ra, nhiều
người còn cho rằng OOP dễ tiếp thu hơn cho những người mới học về lập trình hơn
là các phương pháp trước đó.
Lập trình hướng đối tượng dựa trên ba đặc trưng cơ bản là bao gói/che dấu
thông tin, kế thừa và đa hình.
Bao gói/che dấu thông tin là đặc trưng cơ bản nhất của OOP. Gồm hai công
việc liên quan mật thiết với nhau: gắn kết dữ liệu và phương pháp xử lý dữ liệu này
thành một thể thống nhất gọi là (lơp) đối tượng, che dấu các cài đặt và cấu trúc dữ
liệu cụ thể của đối tượng, và các đối tượng chỉ đưa ra kết quả thông qua việc cấp các
dịch vụ trên giao diện xác định. Thực hiện tốt việc bao gói/che dấu thông tin sẽ cho
phép chúng ta thao tác với các đối tượng mà không cần biết cách thức cài đặt cụ thể
của nó. Do việc sử dụng đối tượng chỉ cần biết thông tin tối thiểu về giao diện nên
chúng ta dễ dàng sử dụng lại, đồng thời việc bảo trì là dễ dàng. Thêm nữa, do chỉ
thay đổi được trạng thái của đối tượng thông qua các giao diện xác định nên có thể
đảm bảo được các trạng thái của đối tượng là luôn đúng đắn.
Kế thừa là cơ chế đặc biệt của lập trình hướng đối tượng, cho phép xây dựng
một lớp đối tượng mới kế thừa lớp đối tượng đã có. Kế thừa thúc đẩy việc sử dụng lại
trong bản thân một phần mềm cũng như giữa các phần mềm với nhau.
Đa hình là cơ chế cho phép nhìn nhận một đối tượng theo các góc nhìn khác

nhau, đồng thời cho phép các đối tượng khác nhau giải thích cùng một thông điệp
theo các cách thức khác nhau. Cùng với kế thừa, đa hình tạo nên sự mềm dẻo đặc biệt
trong lập trình hướng đối tượng. Đa hình đồng thời là nền tảng cho việc thực hiện các
thiết kế mở và xây dựng các mẫu thiết kế [2].
1.2. Chất lượng phần mềm
1.2.1. Khái niệm
Trả lời câu hỏi thế nào là một phần mềm chất lượng là rất khó, ngay đối với
phần mềm đang hoạt động, những người khác nhau có thể đánh giá về nó rất khác
nhau. 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 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 ngữ cảnh xác định”. Ngay trong định
nghĩa này thì chất lượng cũng được định nghĩa một cách rất mờ, thiếu yếu tố định
lượng. Thêm vào đó, để hiểu hết nhu cầu của người sử dụng quả thực là rất khó. Với
những khó khăn về định lượng trong khái niệm chất lượng phần mềm, để có được
14
một phần mềm tốt, cách thông thường nhất là tiếp cận theo lối chất lượng quy trình.
Nghĩa là nếu ta có quy trình sản xuất tốt thì sẽ có khả năng sản xuất ra sản phẩm
tốt[2],[7]
1.2.2. Đảm bảo chất lượng phần mềm (SQA_ Software Quality Assuarance)
Khi phần mềm trở thành sản phẩm và đòi hỏi đảm bảo chất lượng đáp ứng nhu
cầu của người sử dụng thì hoạt động đảm bảo chất lượng phần mềm là một hoạt động
cốt yếu được các doanh nghiệp sản xuất phần mềm quan tâm hàng đầu. Bởi vì hoạt
động đảm bảo chất lượng phần mềm có những lợi ích: phần mềm có ít các khiếm
khuyết hơn nên giảm phí tổn bảo trì, độ tin cậy cao hơn do đó thoả mãn nhu cầu
khách hàng hơn, năng suất và hiệu quả hơn. Đảm bảo chất lượng phần mềm liên
quan đến việc xem xét tất cả các sản phẩm phần mềm và các hoạt động trong vòng
đời phát triển của chúng. Hoạt động đảm bảo chất lượng phần mềm luôn được tiến
hành song song với quá trình phát triển của nó. Có như vậy nó mới vận hành và đáp
ứng được nhu cầu của người sử dụng và không bị lỗi cùng với thời gian. Kiểm toán

có thể được thực hiện để đảm bảo các sản phẩm và quy trình phù hợp với các chính
sách tổ chức nội bộ và thủ tục phát triển phần mềm, cũng như tiêu chuẩn công
nghiệp.
Bộ tiêu chuẩn chất lượng ISO 9001 của tổ chức ISO, quy định về “Quy trình
đảm bảo chất lượng” trong các tổ chức phát triển phần mềm. Chỉ số ISO 9001, xác
nhận các tổ chức, đơn vị có quy trình đảm bảo chất lượng hợp chuẩn. Bên cạnh đó,
mô hình khác là CMM (Capability Maturity Model) và CMMI (Capability Maturity
Model Integration) cũng đang rất được quan tâm tại Việt Nam. Công ty nhận được
chứng chỉ CMM nghĩa là công ty đó đã đạt được mức độ tương ứng với các cấp độ
CMM của chứng chỉ. Tuy nhiên, chúng ta cần lưu ý đây mới là khả năng chứ chưa
phải là chắc chắn. Ngày nay, 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 được quan tâm từ chất lượng quy trình, tới chất lượng phần mềm nội bộ
(chất lượng trong), chất lượng phần mềm đối chiếu với yêu cầu của người dùng (chất
lượng ngoài) và chất lượng phần mềm trong sử dụng (chất lượng sử dụng).
Ngoài ra, người ta thường nói đến đảm bảo chất lượng tổng thể của phần mềm.
Tức là những giải pháp để đảm bảo đạt được những độ đo khác nhau của phần mềm
trong quá trình phát triển. Người ta hy vọng rằng, trong quá trình phát triển khi các
độ đo đã được đảm bảo thì phần mềm chắc chắn sẽ đạt chất lượng. Chẳng hạn khi nói
đến độ tin cậy của hệ thống, người ta thường quan tâm đến độ đo về tính sẵn sàng.
Tuy nhiên, khi đánh giá về phần mềm, người ta thường đưa ra một số tiêu chí
để nói đến chất lượng tổng thể của nó, đó là các chuẩn về công nghệ phần mềm. Tiếp
theo sẽ giới thiệu về tiêu chí chất lượng phần mềm.
Tiêu chí đánh giá chất lượng của phần mềm bao gồm:
15
- Đạt được các mục tiêu thiết kế đề ra của tổ chức (thực hiện được các chức
năng của tổ chức).
- Chi phí vận hành là chấp nhận được: chi phí không quá cao so với lợi nhuận
mà nó mang lại.
- Đáp ứng được các chuẩn mực của một hệ thống thông tin hiện hành. Chẳng
hạn tính sẵn sàng: thời gian làm việc trong ngày, tuần, thời gian thực hiện một

dịch vụ, một tìm kiếm, kết quả đưa ra đúng chuẩn (mẫu bảng biểu, số chỉ
tiêu,…).
- Sản phẩm tạo ra có giá trị xác đáng: Thông tin đưa ra là đúng đắn, kịp thời, có
ý nghĩa thiết thực với hoạt động chức năng và quản lý, góp phần nâng cao
chất lượng sản phẩm và dịch vụ của tổ chức.
- Bảo trì được: Dễ bảo trì, bảo trì không quá tốn kém.
- Khả dụng: Dễ đọc và dễ sử dụng.
- Mềm dẻo – có khả năng làm thích nghi được: có thể kiểm tra, mở rộng ứng
dụng và phát triển tiếp được.
- Có tính khả chuyển: Có thể chuyển đổi từ môi trường làm việc này sang môi
trường làm việc khác.
Bốn mục tiêu phải đạt được để đáp ứng quá trình đảm bảo chất lượng
phần mềm
- Mục tiêu thứ 1: Hoạt động đảm bảo chất lượng phần mềm có kế hoạch
- Mục tiêu thứ 2: Tuân thủ sản xuất phần mềm, thực hiện theo chuẩn, thủ tục và
yêu cầu được xác minh khách quan
- Mục tiêu thứ 3: Các cá nhân hoặc nhóm có ảnh hưởng phải được thông báo
các hoạt động SQA và kết quả.
- Mục tiêu thứ 4: Quản lý địa chỉ các vấn đề không tuân thủ dẫn đến không
được giải quyết.
Đảm bảo chất lượng phần mềm bắt đầu ngay từ giai đoạn yêu cầu của vòng đời
phát triển sản phẩm. Kế hoạch đảm bảo chất lượng phần mềm (SQAP) nên được
hoàn thành khi giai đoạn yêu cầu có đầy đủ các đặc điểm kỹ thuật mà phần mềm yêu
cầu được cung cấp. Mỗi tổ chức có kế hoạch riêng cho từng dự án. Kế hoạch này
phải được xem xét và có các số liệu cụ thể về chất lượng, phải được nhấn mạnh.
16
Việc thực hiện SQAP bắt đầu vào cuối của giai đoạn yêu cầu và kết thúc khi sản
phẩm không còn sử dụng nữa. SQAP thực hiện trong suốt vòng đời phát triển của
phần mềm không chỉ giai đoạn phát triển.
Các khả năng được áp dụng để đảm bảo chất lượng phần mềm:

- Đánh giá quá trình cụ thể của các mục tiêu đảm bảo chất lượng và các quá
trình trong vòng đời phát triển của sản phẩm. Điều này đưa ra phương pháp
tiếp cận của tổ chức để cải thiện quá trình tiếp theo.
- Theo dõi sản phẩm chất lượng sau khi SQAP hoàn thành, nó được sử dụng
cho chu kỳ phát triển sản phẩm cụ thể để giám sát các hoạt động chất lượng.
- Tài liệu kế hoạch - xây dựng SQAP là kế hoạch phát triển quan trọng trong
đảm bảo chất lượng phần mềm.
- Giám sát phát triển, thực hiện SQAP cung cấp cho việc theo dõi quá trình phát
triển sản phẩm.
- Theo dõi tiến trình trong suốt dự án, SQAP hướng dẫn theo dõi các quá trình
chất lượng phần mềm trong các dự án và quá trình phát triển.
Mục tiêu của phần này là giúp người đọc có thể:
- Xây dựng một kế hoạch đảm bảo chất lượng phần mềm phù hợp với mục tiêu
của chuẩn CMM, hoặc ISO…
- Xác định lợi ích của việc đảm bảo chất lượng phần mềm trong các dự án cụ
thể
- Xây dựng một SQAP hoàn chỉnh cho bất kỳ dự án phát triển phần mềm nào
- Sửa đổi danh sách kiểm tra SQAP cho các dự án cụ thể của tổ chức
- Kết hợp chặt chẽ đảm bảo chất lượng với các tổ chức tổng thể và chương
trình, số liệu dự án
Xây dựng kế hoạch đảm bảo chất lượng phần mềm bao gồm các bước chính
sau:
1. Mục đích
Khung SQAP là một phần đảm bảo chất lượng phần mềm đóng trong quản lý dự
án tổng thể.
- Xác định người sử dụng cuối
17
- Xác định mức độ rủi ro cần thiết cho giải pháp phát triển phần mềm
- Sơ đồ khối phù hợp với hệ thống phần mềm khác
- Dự kiến đối tượng cho SQAP

- Biện minh của dự án
- Chuyển giao phần mềm cụ thể được đảm bảo
- Mô tả mô hình vòng đời phát triển của phần mềm được sử dụng
- Danh sách các phần mềm COTS được sử dụng
2. Tài liệu tham khảo
Danh sách đầy đủ các tài liệu như: tiêu chuẩn công nghiệp, sách giáo khoa… sử
dụng để phát triển SQAP cần phải được sản xuất ở đây. Cùng với các tài liệu tham
khảo bên ngoài, tất cả các chính sách tổ chức và các văn bản thủ tục áp dụng cần
được liệt kê. Tài liệu dự án tham chiếu cần phải được cung cấp, bao gồm:
- Danh sách tài liệu được hình thành trên cơ sở SQAP
- Lý do đưa ra danh sách tài liệu được sử dụng
- Danh sách các sai lệch với chuẩn
- Danh sách chuyển giao phần mềm bao phủ bởi SQAP đó có yêu cầu bổ
sung thực hành hoặc các thủ tục nghiêm ngặt hơn, hoặc thỏa mái hơn.
- Ghi lại độ lệch phản ánh mức độ rủi ro trình bày trong phần cuối cùng
và các tài liệu tham khảo để biện minh cho những sai lệch.
3. Quản lý
Tổ chức: mô tả cấu trúc tổ chức ảnh hưởng và kiểm soát của phần mềm. Một sơ
đồ tổ chức đơn giản cho thấy mối quan hệ của tổ chức phát triển với tổ chức đại diện
lớn hơn. Đó là một tổ chức phát triển hơn 7 người bao gồm các mục:
- Sơ đồ tổ chức tất cả các bên có liên quan và mối quan hệ của họ với tổ
chức phát triển
- Báo cáo và các đường dẫn trong tổ chức
- Quy trình giải quyết xung đột
- Theo dõi vấn đề cơ chế
18
- Thay đổi trách nhiệm ban kiểm soát và tổ chức
Nhiệm vụ:
- Các nhiệm vụ cụ thể được thực hiện trong quá trình SQA, bao gồm
kiểm toán (kiểm tra), báo cáo và xem xét.

- Các hành động cụ thể được thực hiện trên các phân phối cụ thể
- Điểm cụ thể trong vòng đời phát triển phần mềm là SQA đóng vai trò
tích cực trong đó.
- Một sơ đồ quy trình làm việc của các hoạt động SQA trong dự án cụ
thể
Trách nhiệm: một bảng vai trò và trách nhiệm của tất cả các thành viên của nhóm
phát triển phải được hiển thị.
4. Tài liệu
Bao gồm các tài liệu hướng dẫn được theo dõi bởi SQAP. Các tài liệu được liệt kê
ở đây có thể là tập hợp con của tất cả các mục cấu hình theo dõi trong kế hoạch quản
lý cấu hình phần mềm. Các tài liệu khác sẽ được dự án phát triển cụ thể đưa ra: có
thể là tài liệu vì các lý do của hợp đồng….
Danh sách các tài liệu tối thiểu trên một dự án phần mềm:
- Kế hoạch quản lý dự án
- Yêu cầu đặc điểm kỹ thuật phần mềm
- Thiết kế đặc điểm kỹ thuật phần mềm
- Kế hoạch thử nghiệm phần mềm
- Kế hoạch quản lý rủi ro phần mềm
- Kế hoạch quản lý cấu hình phần mềm
- Tài liệu hướng dẫn người sử dụng

5. Tiêu chuẩn, thực hiện, quy ước và số liệu.
19
Đảm bảo chất lượng phần mềm được điều khiển bởi các tiêu chuẩn công nghiệp.
Phần này liệt kê tất cả các yếu tố bên ngoài và yếu tố bên trong có ảnh hưởng đến
chất lượng cuối cùng của sản phẩm phần mềm.
Mục đích:
Đầu tiên là tài liệu tham khảo, liệt kê tất cả các tài liệu tham chiếu có chứa các
chuẩn, các chính sách và các thủ tục của dự án. Nhớ rằng, chức năng SQA là giám
sát, theo dõi và chức năng quản lý kiểm tra, nó không phải là chức năng thực hiện.

Mục đích của nó bao gồm:
- Tham khảo thông qua việc tham khảo tất cả các tài liệu
- Tham khảo thông qua việc giám sát, theo dõi và quản lý chức năng phù
hợp với mỗi tài liệu
- Tham khảo thông qua mỗi vị trí xảy ra trong vòng đời phát triển
Nội dung:
Lý do cơ bản cho tất cả các phần “Các chuẩn, thực tiễn, quy ước và số liệu” để
cung cấp các đường cơ sở cho việc đo sản phẩm dự án. Mặc dù việc tham khảo đưa
ra một bức tranh lớn lý do đằng sau và quá trình theo dõi, giám sát, đảm bảo quản lý.
6. Tổng quan, kiểm toán
Xem xét và kiểm tra là các hoạt động SQA, cung cấp cơ chế kiểm thử để xác định
tiến độ dự án và vòng lặp phản hồi cho các nhà phát triển để kiểm tra chất lượng sản
phẩn trong tiến trình.
Mục tiêu: Bước này sẽ hiển thị các thông tin.
- Xác định kỹ thuật, người quản lý giám sát và kiểm tra thực hiện
- Quy tắc, thủ tục đánh giá và kiểm tra được thực hiện
- Tối thiểu người tham dự kiểm tra, đánh giá để tiến hành
- Tham chiếu tài liệu tất cả các đánh giá và kiểm tra vòng đời dự án.
- Tối thiểu bản ghi chuẩn cho tất cả các giám sát
- Sắp xếp tiến trình cho các vấn đề phát hiện trong suốt quá trình đánh giá và
kiểm tra
- Sử dụng hệ thống theo dõi vấn đề
20
- Sử dụng kiểm soát thay đổi
Đây là những đánh giá cần thiết để hoàn thành các hoạt động SQA của dự án:
- Xem trước kế hoạch quản lý dự án
- Xem xét và chỉ rõ yêu cầu phần mềm
- Xem xét thiết kế phần mềm
- Xem xét lập kế hoạch kiểm thử phần mềm
- Xem xét kế hoạch quản lý rủi ro phần mềm

- Xem xét kế hoạch quản lý cấu hình phần mềm
- Người sử dụng xem tài liệu hướng dẫn
- Chức năng kiểm tra là một phần quan trọng
- Kiểm tra vật lý đối với mã và tài liệu hướng dẫn nội bộ
- Kiểm tra quá trình thiết kế để nhất quán viết mã
- Quản lý đánh giá tiến trình truy cập và tuân thủ thủ tục
- Xem xét các bài học kinh nghiệm từ cuối mỗi dự án

7. Quản lý rủi ro
Một số dự án yêu cầu một SQAP cũng có một kế hoạch quản lý rủi ro. Các tài
liệu tham khảo SQAP như là một trong những rủi ro cụ thể được giảm nhẹ thông qua
việc sử dụng SQAP. Các mục bao gồm:
- Tham chiếu chéo để có kế hoạch giảm rủi ro cụ thể hỗ trợ bởi SQAP
- Phát biểu cách giảm các lớp rủi ro cụ thể cho dự án
- Xem xét chu kỳ SQA, đặc biệt nhấn mạnh việc giảm nhẹ rủi ro
- Tham khảo những rủi ro định kỳ, với việc xem xét, đánh giá và kiểm tra
SQAP cụ thể
- Yêu cầu báo cáo SQAP rủi ro ở trên và kế hoạch quản lý rủi ro

8. Báo cáo và hành động sửa chữa
21
Phần trên có nêu các tổ chức sẽ thực hiện báo cáo vấn đề, theo dõi vấn đề và kiểm
soát thay đổi. Phần này, liệt kê các quy trình cụ thể để báo cáo vấn đề, hành động
khắc phục và các vấn đề tiếp theo:
- Tham khảo danh sách các vấn đề trước đây và mối quan hệ với các vấn đề và
nghị quyết đưa ra
- Mô tả quá trình theo dõi sản phẩm
- Mô tả quá trình đưa ra vấn đề
- Mô tả vòng đời của sản phẩm cho việc giải quyết vấn đề
- Tham khảo các quá trình tương tác với quá trình quản lý cấu hình

9. Công cụ, kỹ thuật và phương pháp
Đây là hoạt động để hoàn thành việc xác định tất cả các công cụ, kỹ thuật và
phương pháp sử dụng bên trong SQAP
- Danh sách tất cả các công cụ được sử dụng cho SQA trong dự án
- Danh sách những người chịu trách nhiệm quản lý công cụ này
- Mô tả quá trình đảm bảo công cụ có giấy phép
- Xác định tất cả các kỹ thuật cụ thể sử dụng để SQA
- Cung cấp thông tin về việc sử dụng các kỹ thuật ROI.
- Xác định tất cả các phương pháp sử dụng SQA cụ thể
- Cung cấp thông tin về việc sử dụng các phương pháp ROI
- Xác định SCMP xử lý kiểm soát mã.
- Xác định như thế nào SCMP xử lý các phương tiện truyền thông cung cấp các
sản phẩm cuối cùng.

10. Nhà cung cấp kiểm soát (Commercial-off-the-Shelf (COTS))
Để tiết kiệm nguồn tài nguyên chính có thể COTS sản phầm phần mềm. Nếu sản
phẩm COTS được sử dụng trong dự án, đặc biệt chú ý thực hiện đảm bảo chất lượng
của chúng. Hợp đồng các lập trình viên, các kiểm thử viên và chuyên gia tư vấn được
đưa vào dư án phù hợp. Đảm bảo chất lượng nguồn tài nguyên là một vấn đề quản lý
dự án.
22
11. Đào tạo
Đây là ba bước cần thiết để địa chỉ đào tạo SQA trong SQAP:
- Danh sách tất cả các cơ sở đào tạo SQA cần thiết cho các thành viên nhóm
dự án
- Danh sách tất cả các lớp đào tạo bồi dưỡng SQA cần thiết
- Danh sách yêu cầu đào tạo cho các kiểm toán, giám sát, và các vị trí hỗ trợ
12. Thu thập hồ sơ, bảo trì
Quyền sở hữu của tất cả các hồ sơ chất lượng cơ bản của dự án nằm trong chức
năng chất lượng của tổ chức. Các thông tin sau đây phải được cung cấp trong phần

này, và nó có thể soạn sẵn từ một trong những chính sách của tổ chức:
- Vị trí của hệ thống quản lý tập tin chính trong tất cả các hồ sơ dự án
- Lịch trình sao lưu các thông tin dự án;
- Hướng dẫn phục hồi các kho thông tin dự án
- Thời gian lưu giữ hồ sơ dự án tạo ra chất lượng.
Ngoài ra để đánh giá chất lượng phần mềm người ta dựa vào quan điểm chính
sau:
- Yêu cầu phần mềm là cơ sở để đo chất lượng
- Yêu cầu thể hiện bằng đặc tả - đặc tả phải có chuẩn của nó mới kiểm tra được.
- Các chuẩn đặc tả xác định một bộ các tiêu chuẩn phát triển, các tiêu chuẩn này
hướng dẫn cách thức làm ra phần mềm: nếu không tuân thủ các tiêu chuẩn đó
thì hầu như chắc chắn là chất lượng sẽ kém.
- Nếu phần mềm chỉ phù hợp với các yêu cầu đã hiển thị mà chưa phù hợp với
yêu cầu ngầm thì chất lượng phần mềm là đáng nghi ngờ.
- Cần làm rõ yêu cầu và đưa vào đặc tả càng nhiều càng tốt
Thực hiện xác minh và thẩm định (Verification and Validation – V&V) nhằm đảm
bảo phần mềm được phát triển đúng theo như đặc tả và đáp ứng tốt các yêu cầu của
người dùng. Trong đó:
- Xác minh là sự kiểm tra xem sản phẩm có đúng với đặc tả hay không, tức
là chú trọng vào việc phát hiện lỗi của phần mềm qua mỗi bước phát triển.
- Thẩm định là sự kiểm tra xem sản phẩm có đáp ứng được yêu cầu của
người sử dụng hay không, tức là chú trọng vào việc phát hiện sự khác biệt
của sản phẩm làm ra với những gì người sử dụng mong đợi.
23
V&V gồm một loạt các hoạt động của SQA bao gồm rà soát kỹ thuật, kiểm toán
cấu hình và kiểm soát chất lượng, giám sát hiệu năng, nghiên cứu khả thi và mô
phỏng, rà soát tài liệu, rà soát CSDL, phân tích thuật toán, kiểm thử mã nguồn, kiểm
thử chất lượng và kiểm thử cài đặt. Chúng được tiến hành ở mọi giai đoạn của tiến
trình phát triển phần mềm: ở khâu phân tích ta cần thẩm định đặc tả yêu cầu, ở khâu
thiết kế cần xét duyệt xem thiết kế có đúng với đặc tả không, ở khâu lập mã cần rà

soát xem mã nguồn có đúng thiết kế chi tiết không
1.2.3. Chuẩn phần mềm
Các chuẩn phần mềm là rất quan trọng vì những lý do sau:
Các chuẩn phần mềm dựa trên hiểu biết về thực tiễn thích hợp nhất cho công ty.
Kinh nghiệm này thường chỉ đạt được sau rất nhiều lần thử nghiệm và lỗi. Bổ xung
nó vào các chuẩn giúp cho công ty tránh sự lặp lại sai lầm trong quá khứ. Các chuẩn
chứa đựng các kinh nghiệm từng trải này rất có giá trị cho tổ chức.
Các chuẩn phần mềm cung cấp một cái khung cho việc thực thi quá trình đảm
bảo chất lượng. Đưa ra các chuẩn tổng kết thực tiễn, đảm bảo chất lượng bao gồm
việc bảo đảm rằng các chuẩn được tuân theo một cách chặt chẽ.
Các chuẩn phần mềm trợ giúp tính liên tục khi mà một người tiếp tục công việc
của người khác đã bỏ dở. Các chuẩn đảm bảo rằng tất các kỹ sư trong tổ chức chấp
nhận cùng thói quen. Do vậy công sức nghiên cứu khi bắt đầu công việc mới sẽ giảm
xuống.
1.2.4. Kiểm soát chất lượng phần mềm
Kiểm soát chất lượng phần mềm là một tập các thủ tục, được thực hiện bởi tổ
chức để đảm bảo rằng sản phẩm phần mềm sẽ đáp ứng mục đích chất lượng với giá
trị tốt nhất cho khách hàng, và cải tiến không ngừng khả năng của tổ chức cho việc
sản xuất ra sản phẩm phần mềm trong tương lai.
Kiểm soát chất lượng là khâu kiểm tra được đặt xen kẽ giữa các công đoạn sản
xuất và ở khâu thành phẩm để kiểm tra chất lượng của sản phẩm. Các khâu kiểm tra
chất lượng này sẽ phân sản phẩm ra ít nhất là 3 loại: chính phẩm, thứ phẩm và phế
phẩm.
Kiểm soát chất lượng phần mềm đề cập đến quy trình yêu cầu chức năng cũng
như các yêu cầu phi chức năng như hiệu suất, hỗ trợ và khả năng sử dụng. Nó đề cập
đến khả năng để phần mềm thực hiện tốt trong các tình huống không lường trước
được và để giữ một tỷ lệ lỗi tương đối thấp. Để xác định những thủ tục và yêu cầu đề
ra dẫn đến ý tưởng về xác minh, xác thực và kiểm thử phần mềm.
24
Tiến trình này bao gồm việc dò tìm khiếm khuyết, sai sót và thực hiện ngăn

ngừa. Tuy nhiên, ngăn ngừa vẫn là khuynh hướng chủ yếu để giảm chi phí chung về
chất lượng. Ngoài ra, xu hướng của chức năng kiểm soát chất lượng được thực hiện
bởi chính bộ phận sản xuất chứ không phải bộ phận chất lượng. Trong kiểm soát chất
lượng có thể sử dụng một số công cụ như biểu đồ Pareto, biểu đồ nhân quả, lấy mẫu
thống kê, biểu đồ kiểm soát v.v.
Kiểm soát chất lượng (QC) đòi hỏi phần mềm hoặc một bộ phận có năng lực
giám sát và đo lường kết quả dự án để xác định kết quả này có đạt yêu cầu theo tiêu
chuẩn chất lượng đã được đưa ra dựa trên tiêu chuẩn chất lượng Quốc tế và tiêu
chuẩn chất lượng Việt Nam hay không. Nếu kết quả không tốt, cần thực hiện phân
tích nguyên nhận, từ đó xác định nguyên nhân và thực hiện hành động điều chỉnh.
Nói chung, QC cần được thực hiện trong suốt vòng đời của dự án chứ không chỉ tại
thời điểm kết thúc. QC không chỉ quan tâm đến sản phẩm của dự án mà còn đến tiến
trình quản trị dự án tức đo lường thành tích, tiến độ và sai lệch chi phí.
Các đầu vào của kiểm soát chất lượng
Kết quả công việc: kết quả của sản phẩm và kết quả của tiến trình cần được đo
lường và so sánh với tiêu chuẩn chất lượng, kết quả kỳ vọng của sản phẩm cũng như
của dự án có thể được đo lường từ kế hoạch dự án.
Kế hoạch quản lý dự án: hoạt động xác định các tham số cần thiết để QC có thể
đo lường và phản ứng với kết quả của thành quả dự án.
Phiếu kiểm tra: nếu dự án sử dụng phiếu kiểm tra để đảm bảo hoàn thành công
việc, thì phiếu kiểm tra này cũng vẫn được xem là một bộ phận của kiểm soát chất
lượng.
Các nội dung liên quan đến SQC
Lập kế hoạch để kiểm soát chất lượng
Xác định các tiêu chuẩn tham chiếu
Phân tích và so sánh kết quả với các tiêu chuẩn
Báo cáo kết quả cho tất cả các bên liên quan
Các nhiệm vụ SQC trong từng pha phát triển:
- Pha thu thập yêu cầu
 Xác định tính đúng đắn của các yêu cầu

25
 Kiểm tra tài liệu rà soát yêu cầu phần mềm cuối pha
- Pha thiết kế kiến trúc (thiết kế sơ bộ)
 Thiết kế bám sát các chuẩn thiết kế đã được chỉ ra trong kế
hoạch quản lý.
 Kiểm soát các yêu cầu được đưa vào trong các thành phần thiết
kế.
 Kiểm tra tài liệu rà soát thiết kế sơ bộ
- Pha thiết kế chi tiết
 Kiểm tra các mô đun đã đưa vào đều được thiết kế chi tiết, có
phù hợp với chuẩn thiết kế chi tiết đã được đưa ra không?
 Kiểm tra kết quả của việc xét duyệt thiết kế, tài liệu rà soát thiết
kế chi tiết.
- Pha cài đặt phần mềm
 Kiểm soát các hoạt động quản lý cấu hình và thư viện phát triển
phần mềm.
 Kiểm soát các thủ tục kiểm thử chi tiết cho pha tiếp theo.
- Pha tích hợp và kiểm thử
 Viết testcase
 Kiểm soát quá trình kiểm thử.
 Hoàn thành báo cáo kiểm thử và các báo cáo đó là đúng đắn.
 Kiểm soát mức độ sẵn sàng kiểm thử
- Pha chấp nhận và phân phối phần mềm
 Thẩm tra cấu hình cuối cùng để chứng minh rằng tất cả những
thành phần cần phân phối đã sẵn sàng để phân phối.
- Pha thao tác và bảo trì phần mềm
 SQC kiểm soát những hoạt động cụ thể trong từng pha tương
ứng đã mô tả phía trước.