Báo cáo môn Đảm Bảo Chất Lượng Phần Mềm Đề tài Phân tích các thành phần đảm bảo chất lượng phần mềm cho dự án X

Trường Đại Học Công Nghiệp Hà Nội
Khoa công nghệ thông tin
----------

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

Đề tài: Phân tích các thành phần đảm bảo chất
lượng phần mềm cho dự án X

GVHD: TS. Vũ Đình
Minh
Lớp: IT6008.2

Khóa: K14

Mã
SV: Họ và tên: Trần Quang Hưng
2019601992
Họ và tên: Trần Anh Tuấn
Mã
SV:
Họ và tên: Ngô Văn Bằng
2019601107
Mã
SV: Họ và tên: Lý Văn Ngọc Đại
2019603303
Họ và tên: Trần Lê Mạnh
Mã
SV:
2019603574

Mã
SV:
2019602246


Hà Nội, 2021


Trường Đại Học Công Nghiệp Hà Nội
Khoa công nghệ thông tin
----------

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

Đề tài: Phân tích các thành phần đảm bảo chất
lượng phần mềm cho dự án X

GVHD: TS. Vũ Đình
Minh
Lớp: IT6008.2

Khóa: K14

Mã
SV: Họ và tên: Trần Quang Hưng
2019601992
Họ và tên: Trần Anh Tuấn
Mã
SV:

Họ và tên: Ngô Văn Bằng
2019601107
Mã
SV: Họ và tên: Lý Văn Ngọc Đại
2019603303
Họ và tên: Trần Lê Mạnh
Mã
SV:
2019603574
Mã
SV:
2019602246


Hà Nội, 2021


Mục lục
Lời Nói Đầu.........................................................................................................1
Danh mục các thuật ngữ, ký hiệu và các chữ viết tắt.............................................2
Chương 1. Tích hợp các hoạt động chất lượng trong vòng đời dự án.............3
1.1. Phương pháp phát triển phần mềm truyền thống và các phương
pháp khác.........................................................................................................3
1.1.1.

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

1.1.2.

Mơ hình Agile................................................................................5

1.1.3.

So sánh mơ hình thác nước và mơ hình Agile................................9

1.2. Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm...11
1.3. Xác minh, thẩm định và đánh giá chất lượng....................................12
Chương 2. Rà soát.............................................................................................14
2.1. Định nghĩa về rà soát của IEEE............................................................14
2.2. Mục tiêu rà soát......................................................................................14
2.3. Những rà sốt thiết kế hình thức...........................................................15
2.4. Các rà sốt ngang hàng (peer review)...................................................17
2.5 Các ý kiến chuyên gia..............................................................................20
Chương 3. Đảm bảo chất lượng của các thành phần bảo trì phần mềm.......24
3.1. Giới thiệu................................................................................................24
3.2. Cơ sở cho chất lượng bảo trì phần mềm cao........................................24
3.2.1. Cơ sở 1: Chất lượng gói phần mềm...................................................24
3.2.2. Cơ sở 2: Chính sách bảo trì..............................................................26
3.3. Các thành phần chất lượng phần mềm tiền bảo trì.............................27
3.3.1. Xem xét lại hợp đồng bảo trì.............................................................27
3.3.2. Lập kế hoạch bảo trì..........................................................................28
3.4. Các cơng cụ đảm bảo chất lượng phần mềm........................................31
3.4.1. Cơng cụ SQA cho bảo trì sửa lỗi.......................................................31
3.4.2. Cơng cụ SQA cho bảo trì cải thiện chức năng...................................32
3.4.3. Cơng cụ SQA cơ sở cho bảo trì phần mềm........................................32
3.4.4. Cơng cụ SQA cho giám sát quản lý bảo trì phầm mềm......................36
Chương 4. CASE Tool và ảnh hưởng của nó lên chất lượng phần mềm.......40


4.1. Khái niệm CASE Tool............................................................................40

4.2. Đóng góp của Case Tool cho chất lượng phần mềm............................42
4.3. Đóng góp của Case Tool cho chất lượng bảo trì phần mềm................45
4.4. Đóng góp của Case Tool cho quản lý dự án..........................................46
Chương 5. Đảm bảo chất lượng phần mềm của các yếu tố bên ngoài cùng
tham gia.............................................................................................................47
5.1. Những thành phần bên ngồi đóng góp vào dự án phần mềm...........47
5.2 Rủi ro và lợi ích của giới thiệu người tham dự ngoài...........................48
5.3. Những mục tiêu đảm bảo chất lượng về sự đóng góp người tham gia
bên ngồi........................................................................................................50
5.4. Các cơng cụ đảm bảo chất lượng những đóng góp của các thành viên
đóng góp bên ngồi........................................................................................51
Tài liệu tham khảo............................................................................................53


1

Lời Nói Đầu

Trong mơi trường kinh doanh ngày nay, nếu muốn giữ
vững tỷ lệ chiếm lĩnh thị trường - chưa nói gì đến việc tăng
tỷ lệ đó - cần thiết phải xây dựng được hệ thống đảm bảo
chất lượng các phần mềm trong doanh nghiệp đạt tiêu
chuẩn nhất định.
Ngày nay, các khách hàng xem trọng chất lượng sản
phẩm hơn là sự tin tưởng đối với các doanh nghiệp trong
nước, và trong mọi trường hợp giá cả chưa hẳn đã là nhân
tố quyết định trong sự lựa chọn của khách hàng. Chất lượng
đã thay thế giá cả, và điều đó đúng với cả công nghiệp,
công nghệ, dịch vụ và nhiều thị trường khác. Đặc biệt trong
thị trường công nghệ hiện nay, các phần mềm càng được

quan tâm nhiều hơn về việc chất lượng có đảm bảo hay
khơng ?
Có thể nói chất lượng sản phẩm đóng vai trị quan trọng
quyết định sự sống còn của các doanh nghiệp phần mềm
hiện nay.
Dưới đây là các lý do tại sao chất lượng phần mềm quan
trọng và ảnh hưởng to lớn đến các doanh nghiệp phần
mềm, vì:





Đáp ứng kỳ vọng của khách hàng
Tăng uy tín, danh tiếng và hình ảnh cho doanh nghiệp
Đáp ứng hoặc vượt trên các tiêu chuẩn ngành
Quản lý chi phí hiệu quả


2

Trong bài báo cáo này, chúng ta cùng tìm hiểu các
thành phần ảnh hưởng đến việc đảm bảo chất lượng phần
mềm trong vòng đời dự án phần mềm.


3

Danh mục các thuật ngữ, ký hiệu và các chữ viết tắt
Từ viết tắt

QA

Viết đầy đủ
Quality Assurance

Chức năng / Ý nghĩa
Người chịu trách nhiệm đảm
bảo chất lượng sản phẩm
thông qua việc đưa ra quy
trình làm việc giữa các bên

ER

Entity -

liên quan.
Mô tả các đối tượng trong thế

Relationship

giới thực bằng các thực thể,

Failure

quan hệ.
Lỗi phần mềm
Phần mềm bán sẵn

Design Review
Software Quality

Rà soát thiết kế
Bộ phận giám sát và quản lý

Assurance

chất lượng

COTS
software
DR
SQA


4

Chương 1. Tích hợp các hoạt động chất
lượng trong vịng đời dự án
1.1.

Phương pháp phát triển phần mềm truyền thống và các phương
pháp khác
1.1.1. Mơ hình thác nước
Có rất nhiều mơ hình phát triển phần mềm truyền thống như:
thác nước (Waterfall model), mơ hình chữ V (V model), xoắn ốc
(Spiral model)… Nhưng mơ hình thác nước là mơ hình truyền thống
nổi tiếng và được nhiều người biết đến rộng rãi nhất.
Mơ hình thác nước có vịng đời phát triển phần mềm bao gồm
các giai đoạn sau:

Requirement
Analysis

System
Design

Implementation

Testing

System
Deployment

System
Maintenance

Các hoạt động liên quan đến các giai đoạn khác nhau như sau:
• Requirement Analysis (Phân tích yêu cầu): Đây là pha đầu tiên
trong các dự án sử dụng mơ hình thác nước với mục đích xác định và
phân tích tất cả các nhu cầu kinh doanh, các yêu cầu từ người dùng
đối với sản phẩm, các rằng buộc và rủi ro yêu cầu.
• System Design (Thiết kế hệ thống): Từ những yêu cầu được xác
định trong bước 1, nhóm dự án tạo ra thiết kế cho sản phẩm để đáp
ứng tất cả các yêu cầu đó, bao gồm cả thiết kế phần cứng, thiết kế
phần mềm, ngơn ngữ lập trình, lưu trữ dữ liệu. Đây đồng thời cũng là
phần giúp bạn xác định dự án sẽ hữu ích thế nào đối với người dùng.
Nếu bước này gặp vấn đề thì rất có thể phải quay lại bước 1 để thực
hiện lại.

5

• Implementation (Thực hiện): Khi hệ thống đã được thiết kế đầy đủ
và cụ thể, các nhóm chức năng của sản phẩm sẽ được thực hiện trong
giai đoạn này để đáp ứng các tiêu chuẩn đã thực hiện ở bước trước.
Đây là giai đoạn mà các nhiệm vụ công việc được thảo luận ở bước 2
được tiến hành và cũng là giai đoạn mà đội ngũ lập trình sẽ là nguồn
lực chủ yếu được sử dụng.
• Testing (Kiểm thử): Ở giai đoạn này, thường sẽ là công việc của đội
ngũ QA (Quality Assurance) và tester nhằm tìm kiếm và báo cáo các
lỗi trong hệ thống cần được xử lý. Việc này bao gồm tất cả các hoạt
động kiểm thử tính năng và phi tính năng. Đây là giai đoạn cực kỳ
quan trọng mà nhóm khơng được phép mắc sai lầm nhằm đảm bảo
hệ thống được kiểm tra đầy đủ, các mục tiêu thiết kế và chức năng
người dùng yêu cầu được đáp ứng và các nhu cầu kinh doanh được
giải quyết.
• System Deployment (Phát triển hệ thống): Đây là giai đoạn mà
sản phẩm được triển khai vào môi trường mà người dùng có thể bắt
đầu sử dụng được. Hay nói cách khác là giai đoạn mà sản phẩm thực
sự đi vào hoạt động. Trong giai đoạn này, nhóm dự án cần đảm bảo
các yếu tố như: môi trường đang hoạt động, khơng có lỗi trên server,
các tiêu chí test đã được đáp ứng hoặc kiểm tra lại môi trường sau
khi ứng dụng được triển khai để đảm bảo sản phẩm khơng gặp vấn
đề.
• System Maintenance (Bảo trì hệ thống): Đây là giai đoạn cuối
cùng của q trình, trong đó nhóm dự án tập trung giải quyết các vấn
đề của khách hàng. Trong các dự án phần mềm, đây thường là giai
đoạn các bản được phát hành để cập nhật và sửa lỗi.
 Như đã được nêu ra bên trên, mô hình thác nước chỉ thực hiện theo
một quy trình tuần tự, chảy đều đặn xuống dưới như một dòng thác

6

và được sử dụng trong quá trình phát triển phần mềm. Khơng thể
thay đổi bất cứ điều gì khi phát sinh u cầu của khách hàng, vì nó
ln tn theo một thứ tự nhất định. Điều này dẫn đến việc phải đối
mặt với một số vấn đề như: khách hàng sẽ khơng nhận được sự hài
lịng, u cầu sẽ được chờ xử lý, khơng có lợi nhuận, lãng phí thời
gian.
1.1.2. Mơ hình Agile
Những phương pháp phát triển phần mềm theo cách truyền
thống ngày càng bộc lộ nhiều nhược điểm và tỷ lệ các dự án thất bại
cao trong thời kỳ bùng phát của ngành cơng nghệ. Nhận ra vấn đề
đó, một số cá nhân và công ty riêng lẻ đã đưa ra các phương pháp
phát triển phần mềm hiện đại hơn và khác nhau để thích ứng với tình
hình mới.
Agile là một phương pháp phát triển phần mềm rất gần đây
(hay chính xác hơn là một nhóm các phương pháp) dựa trên tuyên
ngôn nhanh. Điều này đã được phát triển để giải quyết một số thiếu
sót trong phương pháp phát triển phần mềm truyền thống. Các
phương pháp nhanh nhẹn dựa trên việc ưu tiên cao cho sự tham gia
của khách hàng sớm trong chu kỳ phát triển. Nó khuyến nghị kết hợp
kiểm tra bởi khách hàng sớm và thường xuyên nhất có thể. Kiểm tra
được thực hiện tại mỗi điểm khi có phiên bản ổn định. Nền tảng của
Agile dựa trên việc bắt đầu thử nghiệm từ khi bắt đầu dự án và tiếp
tục trong suốt đến cuối dự án. Quy trình Scrum và Extreme là hai
trong số các biến thể phổ biến nhất của phương thức Agile.
Hình 1.1 Agile Model

7

Khái niệm Agile là phương thức phát triển phần mềm linh
hoạt, được ứng dụng trong quy trình phát triển phần mềm với mục
tiêu là đưa sản phẩm đến tay người dùng càng nhanh càng tốt.
4 tuyên ngôn cần tuân thủ trong phương pháp Agile
 Cá nhân và sự tương hỗ quan trọng hơn quy trình và
cơng cụ: Trọng tâm đặt lên con người, xây dựng tương
tác và hỗ trợ giữa các thành viên trong nhóm. Những
thành viên có năng lực, chịu tương trợ nhau trong công
việc sẽ mang đến thành công cho dự án.
 Phần mềm dùng được tốt hơn tài liệu đầy đủ: Tập
trung thời gian để làm ra phần mềm hoàn chỉnh đáp
ứng hoàn hảo yêu cầu khách hàng.
 Cộng tác với khách hàng quan trọng hơn đàm phán
hợp đồng: Hiểu được khách hàng cần gì để tư vấn và
điều chỉnh sản phẩm thay vì chỉ dựa vào các điều
khoản trong hợp đồn


8

 Phản hồi thay đổi hơn là bám sát kế hoạch: Agile
khuyến khích thích nghi với sự thay đổi, đó có thể là
thay đổi về cơng nghệ, nhân sự, deadline,..
12 nguyên tắc quan trọng của Agile
 Đáp ứng toàn diện nhu cầu khách hàng thông qua việc
giao hàng sớm và sản phẩm có giá trị.
 Thay đổi yêu cầu được chào đón, thậm chí là rất muộn

trong q trình phát triển.
 Giao phần mềm chạy được cho khách hàng một cách
thường xuyên.
 Nhà kinh doanh và các kỹ sư phần mềm cần làm việc
cùng nhau trong suốt dự án.
 Xây dựng dự án xung quanh các cá nhân có động lực.
Cung cấp sự hỗ trợ cần thiết, môi trường làm việc và
niềm tin để hồn thành cơng việc.
 Trao đổi trực tiếp là cách truyền đạt thông tin hiệu quả
nhất.
 Thước đo chính của tiến độ là phần mềm chạy tốt.
 Phát triển liên tục và bền vững.
 Cải tiến sự linh hoạt bằng cách quan tâm đến kỹ thuật và
thiết kế.
 Nghệ thuật tối đa hóa lượng cơng việc chưa xong - Sự
đơn giản là cần thiết.
 Nhóm tự tổ chức
 Thích ứng thường xuyên với những thay đổi.
Đặc trưng của Agile
 Tính lặp (Iterative): Dự án sẽ được thực hiện trong các
phân đoạn lặp đi lặp lại (Iteration hoặc Sprint), thường
có khung thời gian ngắn (từ 1 - 4 tuần). Trong mỗi phân


9

đoạn, nhóm phát triển thực hiện đầy đủ các cơng việc
cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế,
triển khai, kiểm thử để cho ra các phần nhỏ của sản
phẩm.

 Tính tăng trưởng và tiến hóa (Incremental &
Evolutionary): Cuối các phân đoạn, nhóm cho ra các
phần nhỏ của sản phẩm cuối cùng, thường là đầy đủ, có
khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử
dụng. Theo thời gian, phân đoạn này tiếp nối phân đoạn
kia, các phần chạy được này sẽ được tích lũy, lớn dần
lên cho tới khi toàn bộ yêu cầu của khách hàng được
thỏa mãn.
 Tính thích nghi (adaptive): Do các phân đoạn chỉ kéo
dài trong một khoảng thời gian ngắn và việc lập kế
hoạch cũng được điều chỉnh liên tục, nên các thay đổi
trong quá trình phát triển (yêu cầu thay đổi, thay đổi
công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có
thể được đáp ứng theo cách thích hợp.
 Nhóm tự tổ chức và liên chức năng: Các cấu trúc nhóm
này tự phân cơng cơng việc mà không dựa trên các mô
tả cứng về chức danh hay làm việc dựa trên một sự phân
cấp rõ ràng trong tổ chức. Nhóm tự tổ chức đã đủ các kĩ
năng cần thiết để có thể được trao quyền tự ra quyết
định, tự quản lí và tổ chức lấy cơng việc của chính mình
để đạt được hiệu quả cao nhất.
 Quản lý tiến trình thực nghiệm (Empirical Process
Control): Các nhóm Agile ra các quyết định dựa trên các


10

dữ liệu thực tiễn thay vì tính tốn lý thuyết hay các tiền
giả định. Agile rút ngắn vòng đời phản hồi để dễ dàng
thích nghi và gia tăng tính linh hoạt nhờ đó có thể kiểm

sốt được tiến trình, và nâng cao năng suất lao động.
 Giao tiếp trực diện (face-to-face communication): Agile
khơng phản đối việc tài liệu hóa, nhưng đánh giá cao
hơn việc giao tiếp trực diện thay vì thơng qua giấy tờ.
Agile khuyến khích nhóm phát triển trực tiếp nói chuyện
để hiểu rõ hơn về cái khách hàng thực sự cần. Trong
giao tiếp giữa nội bộ nhóm, Agile khuyến khích trực tiếp
trao đổi và thống nhất với nhau về thiết kế của hệ thống
và cùng nhau triển khai thành các chức năng theo yêu
cầu.
 Phát triển dựa trên giá trị (value-based development):
Một trong các nguyên tắc cơ bản của agile là “sản phẩm
chạy tốt chính là thước đo của tiến độ”. Nhóm Agile
thường cộng tác trực tiếp và thường xuyên với khách
hàng để biết yêu cầu nào có độ ưu tiên cao hơn, mang
lại giá trị hơn sớm nhất có thể cho dự án.
1.1.3. So sánh mơ hình thác nước và mơ hình Agile
Trước khi đi vào nhận xét giữa 2 mơ hình, ta cùng nhìn qua
ưu, nhược điểm của 2 mơ hình này.
Mơ hình Thác nước
Ưu điểm
Đây là mơ hình đơn giản, dễ áp

Nhược điểm
Khơng phải mơ hình lý tưởng

dụng, quy trình rõ ràng theo từng

cho các dự án lớn và dài ngày.

11

bước.
Dễ quản lý và bảo trì bởi cách tiếp

Khơng hiệu quả đối với những

cận tuyến tính và cố định theo từng

dự án đối mặt với các yêu cầu

bước.
Các tiêu chí đầu vào và đầu ra được

khơng rõ ràng từ đầu.
Khó thích ứng với thay đổi bao

xác định rõ ràng nên dễ dàng trong

gồm yêu cầu, kế hoạch, phạm vi

công tác kiểm tra chất lượng.
Hoạt động hiệu quả trong các dự án

dự án…
Độ trực quan thấp và giá trị

nhỏ, với các yêu cầu rõ ràng.

chuyển giao chậm khi đến cuối
chu trình người dùng mới nhìn
thấy và sử dụng sản phẩm.

Có nhiều tài liệu cung cấp cho
khách hàng.

Mơ hình Agile
Ưu điểm
Thực hiện thay đổi dễ dàng
Không cần phải nắm mọi thông tin

Nhược điểm
Khó lên kế hoạch dự án
Bắt buộc phải hướng dẫn và đào

ngay từ đầu
Bàn giao nhanh hơn
Chú ý đến phản hồi của khách hàng

tạo chi tiết
Ít tài liệu hướng dẫn
Bắt buộc phải hợp tác để dự án

và người dùng
Cải tiến liên tục

thành cơng
Chi phí cao

 Qua trên ta có thể thấy, mơ hình Agile khắc phục hầu hết các nhược
điểm mà mơ hình thác nước truyền thống gặp khó khăn trong quá
trình phát triển.
o Các phương pháp truyền thống sử dụng lập kế hoạch làm cơ
chế kiểm soát của họ, trong khi các mơ hình Agile sử dụng
phản hồi từ người dùng làm cơ chế kiểm sốt chính.
o Agile có thể được gọi là phương pháp lấy con người làm trung
tâm hơn các phương pháp truyền thống.


12

o Mơ hình Agile cung cấp phiên bản hoạt động của sản phẩm từ
rất sớm so với các phương pháp truyền thống để khách hàng
có thể sớm nhận ra một số lợi ích.
o Thời gian chu kỳ thử nghiệm của Agile tương đối ngắn so với
các phương pháp truyền thống, bởi vì thử nghiệm được thực
hiện song song với phát triển.
o Hầu hết các mơ hình truyền thống rất cứng nhắc và tương đối
kém linh hoạt hơn mơ hình Agile.
 Vì tất cả những ưu điểm này, Agile được ưa chuộng hơn các phương
pháp truyền thống tại thời điểm này.
1.2.

Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm
Những hoạt động đảm bảo chất lượng là hướng quy trình, nó liên kết

tới sự hồn thành của một pha dự án, sự hoàn tất một mốc dự án, và nhiều
hơn nữa. Những hoạt động đảm bảo chất lượng được tích hợp vào trong kế
hoạch phát triển. Những người lên kế hoạch đảm bảo chất lượng cho một

dự án cần xác định:
Khi lập kế hoạch đảm bảo chất lượng cho một dự án, cần xác định
danh sách hoạt động đảm bảo chất lượng cần thiết cho dự án. Với mỗi hoạt
động, cần xác định:
 Thời gian.
 Loại hoạt động đảm bảo chất lượng áp dụng.
 Người thực hiện hoạt động và tài nguyên yêu cầu.
Tài nguyên yêu cầu cho việc khắc phục sai sót và thay đổi.
Hình 1.2 Tiến trình quản lý chất lượng phần mềm

Các yếu tố ảnh hưởng tới hoạt động đảm bảo chất lượng phần mềm:


13

 Yếu tố dự án, bao gồm:
o Độ lớn của dự án.
o Sự phức tạp và độ khó của kỹ thuật.
o Phạm vi của những thành phần sử dụng lại.
o Hậu quả nếu dự án bị lỗi.
 Yếu tố nhóm, bao gồm:
o Trình độ chun mơn của những thành viên trong nhóm.
o Sự quen thuộc của nhóm với dự án và kinh nghiệm của
nhóm trong lĩnh vực.
o Tính sẵn sàng của những thành viên có thể trợ giúp
nhóm.
o Sự hiểu biết giữa những thành viên trong nhóm, hay nói
cách khác là số thành viên mới trong nhóm.
1.3.

Xác minh, thẩm định và đánh giá chất lượng

Ba khía cạnh đảm bảo chất lượng của sản phẩm phần mềm được sát hạch
dưới dạng:
 Xác minh (Verification).
 Thẩm định (Validation).
 Đánh giá (Qualification).
Xác minh (Verification): là một quá 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
người phát triển phần mềm có đi đúng hướng để tạo ra sản phẩm cuối cùng.
• Các sản phẩm trung gian bao gồm các tài liệu được tạo ra trong các
giai đoạn phát triển như: đặc tả yêu cầu, tài liệu thiết kế, thiết kế cơ
sở dữ liệu, sơ đồ ER, các test case…
• Xác minh kiểm tra xem sản phẩm có được xây dựng đúng theo yêu
cầu và đặc điểm kỹ thuật thiết kế khơng.
• Thực hiện mà khơng cần chạy phần mềm


14

Thẩm định (Validation): là quá trình đánh giá một hệ thống hoặc một
thành phần trong suốt quá trình phát triển hoặc lúc kết thúc của quá trình
phát triển để xác định xem liệu nó có được làm ra đúng như những yêu cầu
cụ thể như những yêu cầu lúc đầu đưa ra khơng.
• Thẩm định xác định xem phần mềm có phù hợp với nhu cầu sử dụng
và đáp ứng nhu cầu nghiệp vụ khơng.
• Được thực hiện cùng với việc chạy phần mềm
Đánh giá chất lượng (Qualification): là quá trình xác định một hệ thống
hoặc một thành phần có phù hợp với việc sử dụng hay khơng.
• Đánh giá chất lượng tập trung vào những khía cạnh hoạt động, ở đó

việc bảo trì là vấn đề chính.
• Một thành phần phần mềm đã được phát triển và tài liệu hóa theo
những chuẩn, kiểu, và cấu trúc chuyên nghiệp sẽ dễ dàng để bảo trì
hơn những thành phần có code lạ.


15

Chương 2. Rà soát
2.1. Định nghĩa về rà soát của IEEE
Định nghĩa của IEEE(1990), q trình rà sốt là:
“Một q trình hoặc một cuộc họp mà trong đó một sản phẩm công việc
hoặc một tập các sản phẩm công việc được đưa ra tới toàn thể cá nhân
tham gia vào dự án, các giám đốc, người dùng, khách hàng và các bên
quan tâm đến dự án nhằm lấy ý kiến phê bình và phê chuẩn”
Một số phương pháp dùng để xem xét lại tài liệu:
- Xem xét lại thiết kế hình thức (Formal design reviews)
- Xem xét lại ngang hàng (Peer reviews)
- Ý kiến chuyên gia
2.2. Mục tiêu rà soát
Mục đích được chia làm 2 loại: mục đích trực tiếp và gián tiếp.

 Mục đích trực tiếp:
 Phát hiện lỗi phân tích và thiết kế.
 Xác định các rủi ro mới.
 Xác định sự sai lệch so với mẫu, các kiểu thủ tục và qui ước.
 Để phê chuẩn sản phẩm của phân tích hoặc thiết kế.
 Mục đích gián tiếp:
 Nơi họp mặt khơng chính thức để trao đổi về những kiến
thức chuyên môn.

 Ghi lại những lỗi phân tích và thiết kế sẽ hỗ trợ một cơ sở
cho những hoạt động sửa chữa lỗi trong tương lai.
2.3. Những rà sốt thiết kế hình thức
Rà sốt thiết kế hình thức(DRs-formal Design Reviews) là rà soát duy
nhất cần thiết cho việc phê duyệt sản phẩm thiết kế.


16

Rà sốt thiết kế hình thức có thể được thực hiện tại bất cứ mốc phát
triển nào yêu cầu sự hồn thiện của tài liệu phân tích hay thiết kế.
Một danh sách các review thiết kế chính thức:
 DPR – Development Plan Review: Review kế hoạch phát triển
 SRSR – Software Requirement Specification Review: Review





đặc tả yêu cầu phần mềm
PDR – Preliminary Design Review: Review thiết kế sơ bộ
DBDR- Detailed Design Review: Review thiết kế chi tiết
TPR – Test Plan Review: Review kế hoạch kiểm thử
STPR – Software Test Procedure Review: Review thủ tục kiểm









thử phần mềm
VDR- Version Description Review: Review mô tả phiên bản
OMR- Operator Manual Review: Review vận hành thủ công
SMR- Support Manual Review: Review trợ giúp thủ công
TRR- Test Readiness Review: Review sự sẵn sàng kiểm thử
PRR- Product Release Review: Review bản phát hành sản phẩm
IPR-Installation Plan Review: Review kế hoạch cài đặt

Các nhân tố ảnh hưởng tới DRs





Những người tham gia
Sự chuẩn bị trước
Phiên DR
Các hoạt động sau DR được đề xuất

Những người tham gia rà sốt thiết kế
Gồm có Review leader và review team.
 Review Leader:
o Có kiến thức và kinh nghiệm trong việc phát triển kiểu
dự án được review
o Có thâm niên ở mức độ bằng với hoặc cao hơn của
project leader
o Có mối quan hệ tốt với project leader và đội dự an
o Có vị trí bên ngồi đội dự án

 Review team:


17

o Phần lớn khơng thuộc đội dự án
o Kích thước từ 3-5 người
o Đa dạng về kinh nghiệm và phương pháp
Sự chuẩn bị cho một phiên bản DR
Được hoàn thành bởi 3 thành viên: review leader, review team và
development team..
Chuẩn bị của Review leader
 Bổ nhiệm các thành viên nhóm
 Lập lịch các phiên review
 Phân chia tài liệu thiết kế cho các thành viên của nhóm
Chuẩn bị của Review team
 Xem lại tài liệu thiết kế
 Danh sách bình luận
Chuẩn bị của Development team
 Trình diễn ngắn tài liệu thiết kế
 Checklist các công việc review
Phiên DR
Một cuộc họp phiên DR thơng thường gồm có:
 Trình diễn ngắn gọn về tài liệu thiết kế
 Các bình luận của các thành viên review team
 Kiểm tra và xác nhận thảo luận mỗi bình luận
Các quyết định về tài liệu thiết kế để xác định tiến trình dự án. Các
quyết định có thể có 3 loại :
• Phê duyệt đầy đủ
• Phê duyệt từng phần

• Từ chối phê duyệt


18

Các hoạt động hậu review
 Báo cáo Review
Review leader thực hiện sau phiên review
Bao gồm:
 Tổng kết các thảo luận review
 Quyết định về sự tiếp tục của dự án
 Danh sách các hoạt động cần thiết phải làm
 Tên thành viên chịu trách nhiệm theo sát việc hiệu chỉnh
 Tiến trình theo dõi
 Review leader thực hiện
 Chắc rằng việc hiệu chỉnh được thực hiện đúng đắn
 Việc theo dõi cần được ghi lại
2.4. Các rà soát ngang hàng (peer review)
Mục đích chính của peer review là xác định lỗi và độ lệch dựa vào các
chuẩn. Có hai phương pháp peer reviews:
 Xét duyệt (inspection)
 Kiểm tra từng bước (walkthrough).
Walkthrough phát hiện sai sót và ghi chú lên tài liệu. Inspection phát
hiện sai sót và kết hợp với nỗ lực để cải tiến.
Những người tham gia vào peer reviews
Một đội peer review tối ưu 3-5 người tham gia.
Tất cả những người tham gia nên là những người cùng địa vị của nhà
thiết kế hệ thống phần mềm.
Một đội peer review đề cử bao gồm:
• Một leader review.

• Một người thực thi (author).
• Các chuyên gia đặc biệt (specialized professionals).


19

Phân công trách nhiệm trong đội (team assignments)
Hai trong số các thành viên sẽ là:
• Một người dẫn chương trình
• Một người viết tài liệu trong cuộc thảo luận.
Chuẩn bị cho phiên peer review

 Leader:
o Xác định những đoạn trong tài liệu thiết kế sẽ đuợc review
o Lựa chọn thành viên nhóm
o Lập lịch cho những phiên review
o Đưa tài liệu cho các thành viên trong đội trước phiên
review
 Đội peer review: yêu cầu của inspection khá tỉ mỉ, còn
walkthrough chỉ yêu cầu đơn giản.
o Inspection: Đọc & liệt kê chú thích của họ
o Walkth-rough : Đọc các đoạn sẽ được review
Phiên peer review
• Inspection
o Presenter đọc một đoạn tài liệu và thêm vào nếu cần thiết.
o Những người liên quan hoặc đưa ra chú thích, hoặc phản
ứng với những lời chú thích trong tài liệu.
• Walkthrough
o Bắt đầu bằng sự trình bày ngắn của author (thường ko phải
là presenter) hoặc tổng quan về dự án và những đoạn thiết

kế sẽ được review.
o Scribe ghi lại vị trí, mơ tả, kiểu, đặc điểm (sai sót, những
phần thiếu, những phần thêm vào) của mỗi lỗi được chấp
nhận.
Quy tắc thời gian: phiên không nên vượt quá 2 giờ, hoặc lập lịch
không nhiều hơn 2 ngày.
Tài liệu sau mỗi phiên review: