XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

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

ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM
Ngành Kỹ thuật phần mềm

ĐỀ TÀI: XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM
BẢO CHẤT LƯỢNG PHẦN MỀM

Giảng viên HD : TS. Vũ Đình Minh

Hà Nội
1


LỜI CẢM ƠN
Để hoàn thiện được đề tài Bài tập lớn môn Đảm bảo chất lượng phần
mềm, em xin gửi lời cảm ơn chân thành đến trường Đại học Công nghiệp Hà
Nội, khoa Công nghệ thông tin đã tạo điều kiện cho em được học tập. Em xin
gửi lời cảm ơn chân thành đến các thầy cô trong khoa Công nghệ thông tin đã
truyền đạt cho em rất nhiều kiến thức trong quá trình học tập tại trường. Đặc
biệt em xin chân thành cảm ơn đến thầy giáo TS.Vũ Đình Minh. Trong suốt
q trình làm bài tập lớn thầy ln giúp đỡ, hướng dẫn tận tình, truyền đạt
kiến thức và kinh nghiệm của mình cho em để em hồn thành đề tài này.
Em đã cố gắng hoàn thiện báo cáo bài tập lớn tốt nhất nhưng không thể
tránh được những thiếu sót. Em rất mong nhận được sự góp ý của các thầy cô
và các bạn để báo cáo này của em được hoàn thiện hơn. Em xin chân thành
cảm ơn!

2

LỜI MỞ ĐẦU
Ngày nay, Cơng nghệ thơng tin đã có những bước phát triển mạnh mẽ theo cả
chiều rộng và chiều sâu. Máy tính điện tử khơng cịn là một thứ phương tiện quý
hiếm mà đang ngày càng trở thành một cơng cụ làm việc và giải trí thơng dụng của
con người, khơng chỉ ở cơng sở mà cịn ngay cả trong gia đình.
Đứng trước vai trị của thơng tin hoạt động cạnh tranh gay gắt, các tổ chức và
các doanh nghiệp đều tìm mọi biện pháp để xây dựng hồn thiện hệ thống thơng tin
của mình nhằm tin học hóa các hoạt động tác nghiệp của đơn vị.
Tự động hóa ngày càng có vai trị quan trọng trong nền kinh tế toàn cầu và
trong kinh nghiệm hàng ngày. Các kỹ sư đang cố gắng làm cho các thiết bị tự động
hố kết hợp với các cơng cụ tốn học và tổ chức để tạo ra các hệ thống phức tạp cho
một phạm vi đang nhanh chóng phát triển rộng lớn của các ứng dụng và hoạt động
của con người. Hiện nay các công ty tin học hàng đầu thế giới không ngừng đầu tư
và cải thiện các giải pháp cũng như các sản phẩm nhằm cho phép tiến hành thương
mại hóa trên Internet. Thơng qua các sản phẩm và công nghệ này, chúng ta dễ dàng
nhận ra tầm quan trọng và tính tất yếu của thương mại điện tử. Với những thao tác
đơn giản trên máy có nối mạng Internet bạn sẽ có tận tay những gì mình cần mà
không phải mất nhiều thời gian. Bạn chỉ cần vào các trang dịch vụ thương mại điện
tử, làm theo hướng dẫn và click vào những gì bạn cần. Các nhà dịch vụ sẽ mang đến
tận nhà cho bạn.
Để tiếp cận và góp phần trong q trình xây dựng, phát triển và đảm bảo chất
lượng cho phần mềm nhóm chúng em đã tìm hiểu và đưa ra được những đánh giá
cho q trình phân tích thiết kế tự động khi nghiên cứu tới các cơng cụ phần mềm hỗ
trợ phân tích thiết kế tự động.
Với sự hướng dân tận tình của thầy Vũ Đình Minh chúng em đã hồn thành
bài tập lớn này. Tuy đã cố gắng hết sức để tìm hiểu, phân tích, cài đặt và sử dụng
nhưng chắc rằng cũng khơng thể tránh khỏi những thiếu sót. Chúng em rất mong
nhận được sự thơng cảm và góp ý của Thầy. Chúng em xin chân thành cảm ơn

3

MỤC LỤC

4


MỞ ĐẦU
Tên đề tài
“ Xác

minh (Verification) và Thẩm định (Validation) trong Đảm bảo
chất lượng phần mềm ”
I. Lý do chọn đề tài
Trong quá trình phát triển phần mềm, chúng ta sẽ thường gặp phải các vấn đề như :
Chúng ta có tạo ra sản phẩm đúng hay khơng?
Phần mềm có phù hợp với đặc tả của nó hay khơng?
Phần mềm có đáp ứng được yêu cầu của khách hàng hay khơng?
Chúng ta có tạo ra đúng sản phẩm hay khơng?
Để giải quyết được các vấn đề nêu trên chúng ta có thể sử dụng mơ hình V&V
trong suốt q trình phát triển phần mềm để có thể tạo ra được một phần mềm đúng
như đặc tả và yêu cầu của khách hàng .
1. Mục đích của đề tài
Tìm hiểu về mơ hình V&V trong q trình phát triển và kiểm tra phần mềm .So
sánh được điểm giống và khác nhau giữa Xác minh và Thẩm định .Mơ tả được q
trình kiểm tra chương trình và vai trị của chúng trong mơ hình V&V
2. Bố cục đề tài
Nội dung đề tài được trình bày trong 3 chương
Chương 1 : Tổng quan về đảm bảo chất lượng phần mềm
Chương 2 : Xác minh và Thẩm định.

Chương 3 : Mơ hình V và Cleanroom

5


CHƯƠNG 1. TỔNG QUAN VỀ ĐẢM BẢO CHẤT
LƯỢNG PHẦN MỀM
1.1 Chất lượng phần mềm và đảm bảo chất lượng phần mềm
a. Định nghĩa chất lượng phần mềm
•

Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ
chức, cá nhân khác nhau. Trong phạm vi của bài viết này trình bày một số
định nghĩa tiêu biểu.

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

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



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

*Phân tích hai quan điểm của IEEE:
• Theo quan điểm thứ nhất của IEEE: chúng ta sẽ bị phụ thuộc quá nhiều vào
tài liệu đặc tả của yêu cầu, dẫn đến nếu việc xấc định yêu cầu bị sai, thiếu thì một

phần mềm được làm đúng với đặc tả chưa chắc đã là một phần mềm có chất
lượng.
• Theo quan điểm thứ hai của IEEE: khách hàng đơi khi khơng có kiến thức
về cơng nghệ, họ có thể đưa ra những mong muốn hết sức vơ lý và có thể thay đổi
u cầu với phần mềm nhiều lần, thậm chí thay đổi ngay trong giai đoạn cuối.
Điều này gây nhiều khó khăn cho việc phát triển phần mềm.
*Định nghĩa theo Pressman: Chất lượng phần mềm là sự phù hợp của các yêu cầu
6


cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần mềm được ghi
lại rõ ràng bằng tài liệu với các đặc tính ngầm định của tất cả các phần mềm được
phát triển chuyên nghiệp.
Định nghĩa của Pressman đề xuất ba yêu cầu với chất lượng phần mềm phải
được đáp ứng khi phát triển phần mềm :
•

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

•

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

•

Các đặc tính ngầm định cần được đáp ứng trong q trình phát triển cho dù
khơng được nói đến rõ ràng trong hợp đồng
b. Định nghĩa đảm bảo chất lượng phần mềm
Định nghĩa theo Daniel Galin: Đảm bảo chất lượng phần mềm (Software

Quality Assure) là một tập hợp các hành động cần thiết được lên kế hoạch một
cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm
phù hợp để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản
lý theo lịch trình và hoạt động trong giới hạn ngân sách.
c. Đặc trưng ảnh hưởng tới chất lượng phần mềm
•

Tính đúng đắn : mức độ mà dự án hồn thành các đặc tả của nó

•

Tính hiệu quả: dùng tài ngun trong thực hiện và lưu giữ.

•

Tính linh hoạt: dễ làm thay đổi được yêu cầu do thay đổi trong
môi trường vận hành.

•

Tính tồn vẹn: bảo vệ dự án khỏi truy nhập khơng được phép.

•

Tính liên tác: nỗ lực được u cầu để tích hợp hệ thống vào hệ
thống khác.

•

Tính bảo trì: nỗ lực được yêu cầu để định vị và sửa lỗi trong dự
án trong môi trường vận hành của nó.
7


•

Tính khả chuyển: nỗ lực được yêu cầu để truyền dự án từ mơi
trường này sang mơi trường khác.

•

Tính tin cậy: khả năng khơng hỏng.

•

Tính tái dụng: dễ dùng lại phần mềm trong hồn cảnh khác.

•

Tính kiểm thử được: dễ dàng kiểm thử dự án để đảm bảo rằng
nó khơng lỗi và đáp ứng đặc tả.

•
•
•

Tính khả dụng: dễ dùng phần mềm.
Tính tái dụng: dễ dùng lại phần mềm trong hồn cảnh khác.
Tính kiểm thử được: dễ dàng kiểm thử dự án để đảm bảo rằng

nó khơng lỗi và đáp ứng đặc tả.

•

Tính khả dụng: dễ dùng phần mềm.

Tất nhiên, trong một thế giới hoàn hảo tất cả những tiêu chí này sẽ được đáp
ứng, nhưng trong thực tế việc bù trừ là một phần của mọi dự án phát triển.
Thường phần mềm hiệu quả nhất lại không khả chuyển, vì tính khả chuyển sẽ
u cầu mã phụ thêm, làm giảm tính hiệu quả. Tính khả dụng là chủ quan và thay
đổi tuỳ theo kinh nghiệm của người dùng. Khi dùng các tiêu chí này để xác định
mục tiêu đảm bảo của hệ thống phần mềm, mục đích và việc dùng hệ thống phải
được tính tới. Trong thế giới thực của phát triển phần mềm, tiêu chí về chất lượng
được nhận diện và áp dụng cho mức độ khác biệt xem như kết quả của các quyết
định bù trừ.
1.2 Lỗi phần mềm và nguyên nhân gây ra lỗi phần mềm
1.2.1 Lỗi phần mềm
Có nhiều nguyên nhân gây ra lỗi phần mềm, biểu hiện của các lỗi cũng khác nhau ở
mỗi giai đoạn phát triển phần mềm. Có ba loại lỗi phần mềm chính :
Error: Là các phần của code mà khơng đúng một phần hoặc tồn bộ như là kết quả
của lỗi ngữ pháp, logic hoặc lỗi khác được sinh ra bởi các nhà phân tích hệ thống,
8


một lập trình viên hoặc các thành viên khác của đội phát triển phần mềm.
Fault: Là các errors mà nó gây ra hoạt động khơng chính xác của phần mềm
trong một ứng dụng cụ thể.
Failures: Các faults trở thành failures chỉ khi chúng được “activated” đó là khi
người dùng cố gắng áp dụng các phần mềm cụ thể đó bị faulty. Do đó, nguồn gốc
của bất kì failure nào là một errors.

1.2.2 Nguyên nhân gây ra lỗi phần mềm
Việc phát hiện ra lỗi là cần thiết, nhưng tìm ra nguyên nhân gây lỗi để tránh lỗi trong
tương lai mới thực sự quan trọng. Chín nguyên nhân gây ra lỗi phần mềm thống kê
sau đây đã được tổng kết sau nhiều năm nghiên cứu :
•

Định nghĩa yêu cầu lỗi.

•

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

•

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

•

Lỗi thiết kế logic.

•

Lỗi coding.

•

Khơng phù hợp với tài liệu và chỉ thị coding.

•

Thiếu sót trong q trình kiểm thử.

•

Lỗi thủ tục.

•

Lỗi tài liệu.

Nội dung cụ thể mỗi nguyên nhân được xác định như sau :
- Định nghĩa các yêu cầu bị lỗi
Việc xác định các lỗi yêu cầu, thường do khách hàng, là một trong
những nguyên nhân chính của các lỗi phần mềm. Các lỗi phổ biến
nhất loại này là:
•

Sai sót trong định nghĩa các u cầu.

•

Khơng có các u cầu quan trọng.
9


•

Khơng hồn chỉnh định nghĩa các u cầu.

•

Bao gồm các yêu cầu không cần thiết, các chức năng mà không thực sự cần
thiết trong tương lai gần.

- Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển
Hiểu lầm trong giao tiếp giữa khách hàng và nhà phát triển là nguyên nhân bổ sung
cho các lỗi ưu tiên áp dụng trong giai đoạn đầu của q trình phát triển:
•

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

•

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

•

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

•

Hiểu sai về phản ứng của khách hàng đối với các vấn đề thiết kế trình bày của
nhà phát triển.

•

Thiếu quan tâm đến các đề nghị của khách hàng đề cập đến yêu cầu thay đổi
và khách hàng trả lời cho các câu hỏi nêu ra bởi nhà phát triển trên một phần

của nhà phát triển.

- Sai lệch có chủ ý từ các yêu cầu phần mềm
Trong một số trường hợp, các nhà phát triển có thể cố tình đi chệch
khỏi các yêu cầu trong tài liệu, hành động thường gây ra lỗi phần
mềm. Các lỗi trong những trường hợp này là sản phẩm phụ của các
thay đổi. Các tình huống thường gặp nhất là:
•

Phát triển các module phần mềm Các thành phần sử dụng lại lấy từ một dự án
trước đó mà khơng cần phân tích đầy đủ về những thay đổi và thích nghi cần
thiết để thực hiện một cách chính xác tất cả các yêu cầu mới.

•

Do thời gian hay áp lực ngân sách, nhà phát triển quyết định bỏ qua một
phần của các yêu cầu các chức năng trong một nỗ lực để đối phó với áp lực
10


này.
•

Nhà phát triển-khởi xướng, khơng được chấp thuận các cải tiến cho phần
mềm,mà khơng có sự chấp thuận của khách hàng, thường xuyên bỏ qua các
yêu cầu có vẻ nhỏ đối với nhà phát triển. Như vậy những thay đổi "nhỏ" có
thể, cuối cùng, gây ra lỗi phần mềm.

-Các lỗi thiết kế logic
Lỗi phần mềm có thể đi vào hệ thống khi các chuyên gia thiết kế

hệ thống-các kiến trúc sư hệ thống, kỹ sư phần mềm, nhà phân tích,
vv.
- Xây dựng phần mềm yêu cầu. Các lỗi điển hình bao gồm:
+Định nghĩa các yêu cầu phần mềm bằng các thuật tốn sai lầm.
+ Quy trình định nghĩa có chứa trình tự lỗi.
+ Sai sót trong các định nghĩa biên.
+ Thiếu sót trong các trạng thái hệ thống phần mềm được yêu cầu.
+Thiếu sót trong định nghĩa các hoạt động trái pháp luật trong hệ thống phần mềm.
-Các lỗi coding
Một loạt các lý do các lập trình viên có thể gây ra các lỗi code. Những
lý do này bao gồm sự hiểu lầm các tài liệu thiết kế, ngôn ngữ sai sót
trong ngơn ngữ lập trình, sai sót trong việc áp dụng các CASE và các
công cụ phát triển khác, sai sót trong lựa chọn dữ liệu…
-Khơng tn thủ theo các tài liệu hướng dẫn và mã hóa
Hầu hết các đơn vị phát triển có tài liệu hướng dẫn và tiêu chuẩn
mã hóa riêng của mình để xác định nội dung, trình tự và định dạng
của văn bản, và code tạo ra bởi các thành viên. Để hỗ trợ yêu cầu này,
đơn vị phát triển và công khai các mẫu và hướng dẫn mã hóa. Các
thành viên của nhóm phát triển, đơn vị được yêu cầu phải thực hiện
theo các yêu cầu này.
11


-Thiếu sót trong q trình thử nghiệm
Thiếu sót trong q trình thử nghiệm ảnh hưởng đến tỷ lệ lỗi bằng cách để lại một
số lỗi lớn hơn không bị phát hiện hoặc không phát hiện đúng. Những kết quả yếu
kém từ các nguyên nhân sau đây:
•

Kế hoạch thử nghiệm chưa hồn chỉnh để lại phần khơng được điều chỉnh của

phần mềm hoặc các chức năng ứng dụng và các trạng thái của hệ thống.
Failures trong tài liệu và báo cáo phát hiện sai sót và lỗi lầm.

•

Nếu khơng kịp thời phát hiện và sửa chữa lỗi phần mềm theo như của chỉ
dẫn không phù hợp trong những lý do cho lỗi này.

•

Khơng hồn chỉnh sửa chữa các lỗi được phát hiện do sơ suất hay thời gian áp
lực.

-Các lỗi thủ tục
Các thủ tục trực tiếp cho người sử dụng đối với các hoạt động là cần thiết ở mỗi
bước của q trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm
phức tạp, nơi các tiến trình được tiến hành một vài bước, mỗi bước trong số đó có
thể có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian.
-Các lỗi về tài liệu
• Các lỗi về tào liệu là vấn đề của các đội phát triển và bảo trì
đều có sai sót trong tài liệu thiết kế và trong tài liệu hướng dẫn
tích hợp trong thân của phần mềm. Những lỗi này có thể là
nguyên nhân gây ra lỗi bổ sung trong giai đoạn phát triển tiếp
và trong thời gian bảo trì.
• Cần nhấn mạnh rằng tất cả các nguyên nhân gây ra lỗi đều là
con người, công việc của các nhà phân tích hệ thống, lập
trình, kiểm thử phần mềm, các chuyên gia tài liệu, và thậm
chí cả các khách hàng và đại diện của họ.
1.3 Những mục tiêu đảm bảo chất lượng phần mềm
12

Phát triển phần mềm ln đi đơi với bảo trì, vì vậy các hoạt động bảo
đảm chất lượng phần mềm đều có mối liên quan chặt chẽ đến bảo
trì. Những mục tiêu đảm bảo chất lượng phần mềm tương ứng với
giai đoạn phát triển và bảo trì được xác định cụ thể như sau :
- Phát triển phần mềm (hướng tiến trình)
•

Đảm bảo một mức độ chấp nhận được rằng phần mềm sẽ thực hiện
được các yêu cầu chức năng.

•

Đảm bảo một mức đọ cấp nhận được rằng phần mềm sẽ đáp ứng được
các yêu cầu về lịch biểu và ngân sách

•

Thiết lập và quản lý các hoạt động để cải thiện và nâng cao hiệu quả
của phát triển phần mềm và các hoạt động SQA.

-Bảo trì phần mềm (hướng sản phẩm)
• Đảm bảo một mức độ chấp nhận được rằng phần

mềm sẽ thực hiện được các yêu cầu chức năng.
• Đảm bảo một mức đọ cấp nhận được rằng phần mềm

sẽ đáp ứng được các yêu cầu về lịch biểu và ngân
sách

• Thiết lập và quản lý các hoạt động để cải thiện và

nâng cao hiệu quả của phát triển phần mềm và các
hoạt động SQA.

13


CHƯƠNG 2. XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM
BẢO CHẤT LƯỢNG PHẦN MỀM
2.1 Khái niệm về xác minh và thẩm định
2.1.1 Xác minh là gì ?
•

Xác minh là một q trình đánh giá các sản phẩm làm việc trung gian của một
vòng đời phát triển phần mềm để kiểm tra xem liệu rằng chúng ta có đi đúng
hướng để tạo ra sản phẩm cuối cùng.

•

Xác minh là để chắc chắn rằng sản phẩm được thiết kế để cung cấp tất cả các
chức năng cho khách hàng.

•

Xác minh được thực hiện từ lúc bắt đầu của quá trình phát triển phần mềm.
Nó bao gồm các đánh giá và các cuộc họp, rà soát, kiểm tra, ... để đánh giá tài
liệu, kế hoạch, việc lập trình, các u cầu và các thơng số kỹ thuật.

•

Giả sử bạn đang thiết kế một cái bàn thì ở đây, xác minh là việc kiểm tra tất cả
các thành phần của chiếc bàn đó, liệu cả bốn cái chân của nó có kích thước
chính xác hay khơng. Nếu một chân của chiếc bàn khơng đúng kích cỡ thì dẫn
đến việc sẽ làm mất cân bằng các chân còn lại. Tương tự như vậy trong trường
hợp khi phát triển một sản phẩn phần mềm hoặc ứng dụng, đòi hỏi các chức
năng đều phải vận hành đúng và chính xác. Nếu bất kỳ một chức năng nào của
14


phần mềm hoặc ứng dụng khơng đạt đúng tiêu chí hoặc có lỗi được tìm thấy
thì sẽ dẫn đến việc thất bại của q trình phát triển sản phẩm đó. Do đó, việc
xác minh là rất quan trọng và nó diễn ra ở bước khởi đầu của q trình phát
triển.
•

Nó trả lời cho các câu hỏi như: Có phải tơi đang xây dựng một sản phẩm đúng
không? Tôi đang truy cập dữ liệu đúng không? (đặt ở đúng nơi; thực hiện
đúng cách).

•

Đây là một mức độ hoạt động thấp

•

Được thực hiện trong suốt quá trình phát triển dựa trên những thao tác chủ
chốt như rà soát, đánh giá và kiểm tra, phản hồi của người cố vấn, đào tạo,
bản danh sách và tiêu chuẩn.

•

Thể hiện tính thống nhất, đầy đủ và chính xác của phần mềm ở từng giai đoạn
và giữa mỗi giai đoạn của vòng đời phát triển.
2.1.2 Tại sao phải xác minh ?

•

Theo mơ hình trưởng thành năng lực (CMM), chúng ta có thể định nghĩa rằng
kiểm định là quá trình đánh giá phần mềm để xác định xem các sản phẩm của
một giai đoạn phát triển nhất định có đáp ứng được các điều kiện áp đặt vào
đầu của giai đoạn đó hay khơng.

-

Ưu điểm của kiểm định phần mềm:

•

Kiểm định giúp hạ thấp khiếm khuyết trong các giai đoạn phát triển sau này.

•

Kiểm định các sản phẩm ở giai đoạn khởi đầu của sự phát triển sẽ giúp hiểu rõ
sản phẩm một cách tốt hơn.

•

Nó làm giảm nguy cơ thất bại trong các ứng dụng phần mềm hoặc ứng dụng
sản phẩm.

•

Nó giúp việc xây dựng các sản phẩm đúng theo các thông số kỹ thuật của
khách hàng và nhu cầu.
15


2.1.3 Thẩm định là gì
•

Thẩm định là q trình đánh giá sản phẩm cuối cùng để kiểm tra xem phần
mềm có đáp ứng được u cầu nghiệp vụ khơng? Hoạt động validation bao
gồm smoke testing, functional testing, regression testing, systems testing
etc…

•

Thẩm định là xác định xem hệ thống có phù hợp với yêu cầu và thực hiện các
chức năng mà nó được dự định và đáp ứng các mục tiêu của tổ chức và nhu
cầu của người dùng hay khơng.

•

Thẩm định được thực hiện vào cuối của quá trình phát triển và diễn ra sau khi
việc kiểm định được hoàn thành.

•

Nó trả lời cho các câu hỏi như: Tơi đang xây dựng đúng sản phẩm hay không?

Tôi đang truy cập vào đúng dữ liệu hay không? (về các dữ liệu cần thiết để
đáp ứng các yêu cầu).

•

Đây là một hoạt động cấp cao.

•

Thực hiện sau khi một sản phẩm được xây dựng theo các tiêu chí nhằm đảm
bảo rằng các sản phẩm tích hợp một cách chính xác vào mơi trường.

•

Xác định tính đúng đắn của sản phẩm cuối cùng của một dự án phát triển đối
với các nhu cầu và yêu cầu của người sử dụng.
2.1.4 Tại sao phải thẩm định

•

Theo mơ hình trưởng thành năng lực (CMM), chúng ta có thể định nghĩa thẩm
định là q trình đánh giá các phần mềm trong hoặc ở cuối của quá trình phát
triển để xác định xem nó đáp ứng các u cầu và quy định khơng.

•

Một sản phẩm có thể đạt u cầu trong khi thẩm định , vì nó được thực hiện
trên giấy và không chạy hoặc chức năng ứng dụng nào được yêu cầu. Tuy
nhiên, khi cùng một thời điểm đó sản phẩm đã được thẩm định trên giấy
nhưng sau đó các sản phẩm chạy có thể thất bại trong khi kiểm định. Điều này

có thể xảy ra vì khi một sản phẩm hoặc ứng dụng được xây dựng theo các đặc
16


điểm kỹ thuật nhưng những thông số kỹ thuật không chính xác vì thế họ
khơng thể giải quyết các u cầu của người sử dụng.
-

Ưu điểm của thẩm định phần mềm:

•

Trong q trình thẩm định nếu một số khiếm khuyết bị bỏ qua sau đó trong
q trình thẩm định nó có thể được phát hiện thì là lỗi.

•

Nếu trong q thẩm kiểm định một số đặc điểm kỹ thuật bị hiểu nhầm và việc
phát triển đã xảy ra sau đó trong q trình thẩm định khi thực hiện chức năng
đó là sự khác biệt giữa kết quả thực tế và kết quả mong đợi có thể được hiểu.

•

Thẩm định được thực hiện trong quá trình kiểm thử như kiểm thử chức năng,
kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử tải, kiểm thử tương thích, ...

•

Thử nghiệm giúp trong việc xây dựng các sản phẩm đúng theo yêu cầu của
khách hàng và đáp ứng nhu cầu của họ.

•

Thẩm định là bước cơ bản được thực hiện bởi các kiểm thử viên trong suốt
quá trình kiểm thử. Trong quá trình thẩm định sản phẩm nếu một vài sai lệch
được tìm thấy trong kết quả thực tế từ kết quả mong đợi thì sau đó một lỗi sẽ
được báo cáo hoặc một sự cố sẽ được đề cập. Không phải tất cả các sự cố đều
là lỗi. Nhưng tất cả các lỗi đều là sự cố. Sự cố cũng có thể là kiểu 'câu hỏi'
những chỗ nào các chức năng của sản phẩm khơng rõ ràng dành cho các kiểm
thử viên.

•

Do đó, thẩm định giúp đưa ra các chức năng chính xác của các tính năng và
giúp các kiểm thử viên hiểu được sản phẩm một cách tốt hơn. Nó giúp việc
tạo các sản phẩm thân thiện hơn đối với người sử dụng.

2.1.5 Xác minh và thẩm định tĩnh
Là sự kiểm tra mà khơng thực hiện chương trình như:
•

Xét duyệt thiết kế,

•

Xét duyệt yêu cầu,
17


•

Nghiên cứu mã nguồn,

•

Sử dụng các biến đổi hình thức (suy luận) Để kiểm tra tính đúng đắn của
chương trình .
- Thẩm định và xác minh tĩnh được tiến hành ở mọi
khâu trong vịng đời phần mềm.
- Có thể phát hiện được hầu hết các lỗi lập trình, nhưng khơng thể đánh giá
được tính hiệu quả của chương trình.
2.1.6 Xác minh và thẩm định động

-

Là sự kiểm tra thông qua việc thực hiện chương trình

-

Được tiến hành sau khi đã phát triển chương trình
(mã nguồn). Cả hai hướng nêu trên đều rất quan trọng và chúng bổ khuyết lẫn
nhau. Thẩm định và xác minh động còn được gọi là sự thử nghiệm (kiểm thử)
chương trình. Có hai loại thử nghiệm (động) là:
• Thử nghiệm (tìm) khuyết tật: được thiết kế để phát hiện khuyết tật của hệ
thống (đặc biệt là lỗi lập trình).
• Thử nghiệm thống kê: sử dụng các dữ liệu (thao tác) phổ biến của người
dùng (dựa trên sự thống kê) để đánh giá tính dùng được của hệ thống. Thử
nghiệm cần phải có:
• Tính lặp lại: thử nghiệm phải lặp lại được để phát hiện thêm lỗi và kiểm tra
xem lỗi đã được sửa hay chưa.

• Tính hệ thống: việc thử nghiệm phải tiến hành một cách có hệ thống để đảm
bảo kiểm thử được mọi trường hợp, nếu tiến hành thử nghiệm một cách ngẫu
nhiên thì khơng đảm bảo được điều này.
• Được lập tài liệu: để kiểm soát xem cái nào đã được thực hiện, kết quả như
thế nào....

2.2 Sự khác nhau giữa xác minh và thẩm định.
•

Q trình xác minh bao gồm kiểm tra tài liệu, thiết kế, mã và chương trình
trong khi quá trình thẩm định bao gồm kiểm tra và thẩm định sản phẩm thực
18


tế.
•

Xác minh khơng liên quan đến executing code trong khi Xác thực liên quan
đến executing code.

•

Xác minh sử dụng các phương pháp như đánh giá, hướng dẫn, kiểm tra và
kiểm tra tại bàn trong khi Xác thực sử dụng các phương pháp như Black Box
Testing, White Box Testing và non-functional testing.

•

Xác minh kiểm tra xem phần mềm có thẩm định một thông số kỹ thuật hay
không trong khi Thẩm định kiểm tra xem phần mềm có đáp ứng các yêu cầu

và mong đợi hay khơng.

•

Xác minh tìm thấy các lỗi sớm trong chu kỳ phát triển trong khi Thẩm định
tìm thấy các lỗi mà xác minh khơng thể bắt được.

•

So sánh thẩm định và xác minh trong kiểm thử phần mềm. Các mục tiêu của
quá trình xác minh trên kiến trúc phần mềm, thiết kế, cơ sở dữ liệu, v.v. trong
khi quá trình Thẩm định nhắm mục tiêu đến sản phẩm phần mềm thực tế.

•

Việc xác minh được thực hiện bởi nhóm QA trong khi Xác thực được thực
hiện bởi sự tham gia của nhóm thử nghiệm với nhóm QA.

•

So sánh Xác minh và kiểm tra Thẩm định quy trình xác minh đến trước khi
thẩm định trong khi quy trình thẩm định diễn ra sau khi xác minh.

-

Biểu đồ so sánh
Xác minh (Verification)

Thẩm định (Validation)



Quá trình xác minh bao gồm kiểm
tra tài liệu, thiết kế, mã và chương
trình



Đây là một cơ chế động
để kiểm tra và thẩm định
sản phẩm thực tế



Nó khơng liên
executing code



Nó ln liên quan đến
việc thực thi mã

quan

đến

việc

19



Nó sử dụng các phương
pháp như Black Box
Testing,
White
Box
Testing và non-functional
testing



Nó kiểm tra xem phần
mềm có đáp ứng các yêu
cầu và mong đợi của khách
hàng hay khơng



Nó có thể tìm thấy các lỗi
mà q trình xác minh
khơng thể bắt được



Mục tiêu là một sản phẩm
thực tế



Với sự tham gia của
nhóm thử nghiệm, xác thực
được thực thi trên mã phần
mềm.



Nó đến sau khi xác minh

Xác minh sử dụng các phương
pháp như đánh giá, hướng dẫn, kiểm
tra và desk- checking, v.v.



Kiểm tra xem phần mềm có tn
theo đặc điểm kỹ thuật hay khơng



Nó phát hiện lỗi sớm trong chu kỳ
phát triển



Mục tiêu là ứng dụng và kiến trúc
phần mềm, đặc điểm kỹ thuật, thiết
kế hoàn chỉnh, mức độ cao và thiết
kế cơ sở dữ liệu, v.v.





Nhóm QA thực hiện xác minh và
đảm bảo rằng phần mềm theo yêu
cầu trong tài liệu SRS.
Nó đến trước khi xác thực



2.3 Xác minh và thẩm định theo các tiêu chuẩn
a, ISO / IEC 12207:2008
Các hoạt động Verification
• Xác minh yêu cầu: tham gia eview các yêu cầu.
• Xác minh thiết kế: tham gia đánh giá của tất cả các tài liệu thiết kế bao gồm HLD
và LDD
• Kiểm tra code: thực hiện review code
• Xác minh tài liệu: kiểm tra hướng dẫn sử dụng và các tài liệu liên quan khác.
Các hoạt động Validation
• Chuẩn bị các tài liệu test requirement, test case và các thông số test khác để phân
tích các kết quả test.
20


• Đánh giá rằng yêu các test requirement, các test case và các thông số kỹ thuật khác
phản ánh yêu cầu và phù hợp để sử dụng.
• Test các giá trị biên, stress và các chức năng
• Test các thơng báo lỗi và trong trường hợp có bất kỳ lỗi nào, ứng dụng sẽ kết thúc

• Kiểm tra xem phần mềm có đáp ứng các yêu cầu nghiệp vụ và phù hợp để sử dụng
hay khơng.
b, CMMI
Các hoạt động Verification
• Thực hiện peer reviews.
• Xác minh các work product được lựa chọn.
• Chuẩn hóa quy trình bằng cách thiết lập các qui tắc để lên kế hoạch và thực
hiện các bài đánh giá.
Các hoạt động Validation
• Thẩm định rằng các sản phẩm và các component của sản phẩm là phù hợp với mơi
trường.
• Khi validation được thực hiện, nó được theo dõi và kiểm sốt.
• Rút ra bài học kinh nghiệm và thu thập thơng tin cải tiến.
• Thiết lập một quy trình nhất định.
c,IEEE 1012
Mục tiêu của hoạt động Verification và Validation như sau:
Phát hiện và sửa lỗi sớm Khuyến khích và tăng cường sự can thiệp của quản
lý vào bên trong qui trình và rủi ro sản phẩm. Cung cấp các biện pháp hỗ trợ đối với
vòng đời phần mềm, nhằm tăng cường sự tuân thủ các yêu cầu về schedule và
budget
2.4 Vai trò của xác minh và thẩm định trong phát triển phần mềm
Các vai trò khác nhau của Xác minh và thẩm định (V&V) trong SDLC trong quy
trình kiểm thử phần mềm được đưa ra dưới đây:
-

Phân tích :
Xác định nguồn gốc : Khả năng xác định nguồn gốc có thể được định nghĩa
21

là một thuộc tính mơ tả mức độ mà nó có thể được truy tìm đến điểm xuất xứ
của nó. Nó cũng mơ tả khả năng thiết lập mối quan hệ tiền nhiệm - kế thừa
giữa sản phẩm làm việc này với sản phẩm khác. Nó giúp chúng tơi truy tìm
mọi yêu cầu phần mềm trở lại các yêu cầu hệ thống ban đầu được thiết lập
trong hoạt động khái niệm. Vấn đề là đảm bảo rằng mọi yêu cầu đều đáp ứng
chính xác các yêu cầu của hệ thống và khơng có thêm thứ gì của các u cầu
phần mềm. Trong kỹ thuật này, chúng tôi cũng xác định xem bất kỳ yêu cầu
bắt nguồn nào có phù hợp với các mục tiêu ban đầu, các quy luật vật lý và các
công nghệ được mô tả trong tài liệu hệ thống hay khơng.
-

Phân tích giao diện
Là phân tích chi tiết các đặc tả yêu cầu giao diện trong vòng đời phát triển
phần mềm. Nó cũng giúp chúng tơi xác định giao diện giữa các ứng dụng để
xác định các yêu cầu đảm bảo rằng các thành phần tương tác với nhau một
cách hiệu quả. Các tiêu chí đánh giá cũng giống như các tiêu chí đặc tả u
cầu vì nó giúp chúng tơi xác định các u cầu về khả năng tương tác. Mục tiêu
chính của phân tích này là trên các giao diện giữa phần mềm, phần cứng và
người dùng.

-

Phân tích mức độ nghiêm trọng
Mức độ nghiêm trọng được đưa ra cho mỗi và mọi yêu cầu phần mềm và khi
các yêu cầu được kết hợp thành các chức năng, mức độ nghiêm trọng tổng
hợp của các yêu cầu tạo thành mức độ nghiêm trọng cho chức năng tổng
hợp. Phân tích mức độ phê bình được cập nhật thường xuyên sau khi có bất
kỳ thay đổi yêu cầu mới nào. Điều này là do những thay đổi đó có thể gây ra
tăng hoặc giảm mức độ nghiêm trọng của một chức năng, điều này phụ thuộc
vào cách yêu cầu sửa đổi tác động đến mức độ nghiêm trọng của hệ thống.

Phân tích Mức độ nghiêm trọng có các bước sau:

•

Bước đầu tiên là xây dựng một sơ đồ luồng điều khiển (CFD) của hệ thống
với các phần tử của nó trong đó mỗi khối sẽ chỉ đại diện cho một chức năng
22


phần mềm.
•

Sau đó, tiếp theo, nó sẽ theo dõi mọi chức năng quan trọng hoặc yêu cầu chất
lượng của nó với sự trợ giúp của sơ đồ luồng điều khiển.

•

Phân loại tất cả các chức năng phần mềm được truy tìm là quan trọng để thực
hiện đúng các chức năng và yêu cầu chất lượng quan trọng của phần mềm.

•

Tập trung phân tích bổ sung vào các chức năng phần mềm quan trọng được
theo dõi này.

•

Cuối cùng, nó sẽ lặp lại phân tích mức độ nghiêm trọng cho mọi quy trình
vịng đời để kiểm tra xem các chi tiết triển khai có thay đổi trọng tâm của mức
độ nghiêm trọng hay khơng.

•

Phân tích rủi ro
Rủi ro được thực hiện trong hoạt động xác định yêu cầu. Trong phân tích này,
các mối nguy hoặc rủi ro được xác định bằng cách tinh chỉnh các yêu cầu của
hệ thống thành các yêu cầu phần mềm chi tiết.

23


CHƯƠNG 3 MƠ HÌNH V VÀ MƠ HÌNH PHỊNG SẠCH
3.1 Mơ hình V là gì
- Mơ hình V là một mơ hình SDLC trong đó việc thực thi các quy trình diễn
ra tuần tự theo hình chữ V. Nó cịn được gọi là mơ hình Xác minh và thẩm định .
Mơ hình V là một phần mở rộng của mơ hình thác nước và dựa trên sự liên kết của
một giai đoạn thử nghiệm cho mỗi giai đoạn phát triển tương ứng. Điều này có
nghĩa là đối với mỗi giai đoạn trong chu kỳ phát triển, có một giai đoạn thử nghiệm
được liên kết trực tiếp. Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp
theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước.
- Theo V-Model, giai đoạn thử nghiệm tương ứng của giai đoạn phát triển
được lên kế hoạch song song. Vì vậy, có các giai đoạn Xác minh ở một bên của giai
đoạn 'V' và xác thực ở phía bên kia. Giai đoạn mã hóa tham gia vào hai mặt của VModel.
Hình minh họa sau đây mô tả các giai đoạn khác nhau trong Mơ hình V của SDLC.

24


3.2 Các giai đoạn xác minh
-

Phân tích yêu cầu kinh doanh
Đây là giai đoạn đầu tiên trong chu kỳ phát triển mà các yêu cầu của
sản phẩm được hiểu theo quan điểm của khách hàng. Giai đoạn này liên quan
đến việc trao đổi chi tiết với khách hàng để hiểu những mong đợi và yêu cầu
chính xác của họ. Đây là một hoạt động rất quan trọng và cần được quản lý
tốt, vì hầu hết khách hàng khơng chắc chắn về những gì họ cần chính
xác. Việc lập kế hoạch thiết kế kiểm tra chấp nhận được thực hiện ở giai
đoạn này vì các u cầu nghiệp vụ có thể được sử dụng làm đầu vào cho kiểm
tra chấp nhận.

-

Thiết kế hệ thống
Khi bạn có các yêu cầu về sản phẩm rõ ràng và chi tiết, đã đến lúc thiết
kế hệ thống hồn chỉnh. Thiết kế hệ thống sẽ có sự hiểu biết và chi tiết hóa
thiết lập phần cứng và giao tiếp hoàn chỉnh cho sản phẩm đang được phát
triển. Kế hoạch kiểm tra hệ thống được phát triển dựa trên thiết kế hệ
thống. Thực hiện điều này ở giai đoạn sớm hơn để lại nhiều thời gian hơn cho
việc thực thi thử nghiệm thực tế sau đó.

-

Thiết kế kiến trúc
•

Thơng số kỹ thuật kiến trúc được hiểu và thiết kế trong giai đoạn
này. Thông thường, nhiều hơn một cách tiếp cận kỹ thuật được đề xuất và
dựa trên tính khả thi về kỹ thuật và tài chính, quyết định cuối cùng được
đưa ra. Thiết kế hệ thống được chia nhỏ hơn nữa thành các mô-đun đảm

nhận các chức năng khác nhau. Đây cũng được gọi là Thiết kế Cấp cao
(HLD) .

•

Việc truyền dữ liệu và giao tiếp giữa các mơ-đun bên trong và với thế giới
bên ngồi (các hệ thống khác) được hiểu và xác định rõ ràng trong giai

25