Phát triển phần mềm ITSS

Bài 3: Chất lượng sản phẩm phần mềm

References
[1] ISO/IEC 12207:2008, Systems and
software engineering — Software life
cycle processes.
[2] ISO/IEC 9126-1:2001, Software
engineering – Product quality – Part 1:
Quality model.
[3] ISO/IEC 14598-1:1999, Information
technology – Software product
evaluation – Part 1: General overview.

2
Tại sao lại là tiêu chuẩn chất lượng?
 Trong những ngày đầu tiên của phần mềm máy
tính, nó được cho là đủ để phần mềm có thể nhận
ra chức năng thiết kế của nó.
 Khi các hệ thống máy tính chiếm các vị trí quan
trọng, các nhu cầu khác như hệ thống đáng tin cậy
hoặc hiệu suất cao, phát sinh.
 Ngày nay, hệ thống máy tính như hệ thống dựa
trên Web được vận hành bởi rất nhiều người dân
thường, những người không được đào tạo để sử
dụng hệ thống như vậy.

3
Tại sao lại là tiêu chuẩn chất lượng?
 Bạn có bất kỳ kinh nghiệm như dưới đây:
 "Chúng tôi đã phát triển hệ thống theo thông số kỹ
thuật của khách hàng nhưng khách hàng nói 'Điều
đó là vô ích!! Chúng tôi không thể sử dụng nó vì
giao diện phức tạp'" Phần mềm vender.
 Cần xem xét những đặc điểm chất lượng nào?

4
Nội dung
1. Chất lượng sản phẩm phần mềm là gì
2. Mô hình chất lượng phần mềm
3. Quy trình đánh giá chất lượng
4. Hệ thống quản lý chất lượng

5
Nội dung
1. Chất lượng sản phẩm phần mềm là gì
2. Mô hình chất lượng phần mềm
3. Quy trình đánh giá chất lượng
4. Hệ thống quản lý chất lượng

6
Tiêu chuẩn mô hình chất lượng phần mềm
 Trong những năm 1970, mô hình hóa chất lượng
phần mềm đã được thử theo một số cách. Trong
số đó, Mô hình chất lượng của Boehm là nghiên
cứu mang tính bước ngoặt.
 Trong mô hình chất lượng của mình, đặc điểm
chất lượng được cấu trúc như ba lớp phân cấp
như cấp cao, trung cấp, và đặc điểm nguyên thủy.
 Các đặc điểm cấp trung gian đã bao gồm "Tính di
động", "Độ tin cậy", "Hiệu quả", "Khả năng sử
dụng" vv, được sử dụng ngày nay cũng là đặc điểm
chất lượng phần mềm.

7
Mô hình chất lượng phần mềm
 Và sau đó ISO / IEC 9126 "Đánh giá sản phẩm phần
mềm: Đặc điểm chất lượng và hướng dẫn sử dụng
chúng" đã được phát triển, dựa trên kết quả
nghiên cứu tiếp theo của Boehm. Nó có hiệu lực
vào năm 1991.

 Trong chương này, tổng quan về Mô hình chất

lượng phần mềm tiêu chuẩn mới nhất được giới
thiệu dựa trên "ISO / IEC 9126-1: 2001, Kỹ thuật
phần mềm - Chất lượng sản phẩm - Phần 1: Mô
hình chất lượng"

8
1. Chất lượng sản phẩm phần mềm là gì?
 Chất lượng phần mềm được giải thích là
 ".....khả năng đáp ứng nhu cầu đã nêu và ngụ ý" trong
"ISO/IEC 9126-1:2001 Kỹ thuật phần mềm -- Chất lượng sản
phẩm -- Phần 1: Mô hình chất lượng"
 Chất lượng phần mềm được phân loại theo ba loại
phẩm chất tùy thuộc vào ai và khi chúng được
đánh giá
 Chất lượng phần mềm nội bộ: Chất lượng được đánh giá bởi
nhà phát triển trong phân tích, thiết kế và quá trình xây
dựng.
 Chất lượng phần mềm bên ngoài: Chất lượng được đánh giá
bởi nhà phát triển hoặc người thử nghiệm trong quá trình
thử nghiệm
 Chất lượng sử dụng: Chất lượng được đánh giá bởi người
dùng sau khi phân phối sản phẩm
9
Đánh giá chất lượng sản phẩm phần mềm
 Chất lượng sản phẩm phần mềm có thể được
đánh giá bằng cách đo lường [2]
 Thuộc tính nội bộ: thường là các biện pháp tĩnh
của các sản phẩm trung gian
 hoặc bằng cách đo lường các thuộc tính bên
ngoài: thường bằng cách đo lường hành vi của mã
khi thực hiện
 hoặc bằng cách đo lường chất lượng trong các
thuộc tính sử dụng.

[2]: Session 5.1; pp. 3

10
Chất lượng trong vòng đời
 Mục tiêu là để sản phẩm có hiệu quả cần thiết
trong một bối cảnh sử dụng cụ thể [2]

[2]: Figure Quality in the lifecycle in Session 5.1; pp. 3

11
Chất lượng trong vòng đời phần mềm
 Có các chế độ
xem khác nhau
về chất lượng
sản phẩm và
các chỉ số liên
quan ở các giai
đoạn khác
nhau trong
vòng đời phần
mềm [2]
[2]: Figure Quality in
the software lifecycle
in Session 5.2; pp. 4

12
Nội dung
1. Chất lượng sản phẩm phần mềm là gì?
2. Mô hình chất lượng phần mềm
2.1. Chất lượng sử dụng
2.2. Chất lượng phần mềm bên ngoài
2.3. Chất lượng phần mềm nội bộ
3.Quy trình đánh giá chất lượng
4. Hệ thống quản lý chất lượng

13
2.1. Chất lượng sử dụng
 Chất lượng sử dụng được đánh giá là
 Làm thế nào sản phẩm phần mềm có thể đáp ứng nhu cầu của
người dùng trong "Hiệu quả", "Năng suất", "An toàn" và "Sự
hài lòng"?
 Chất lượng sử dụng là quan điểm của người dùng về chất
lượng của một môi trường có chứa phần mềm, và được đo từ
kết quả của việc sử dụng phần mềm trong môi trường, chứ
không phải là thuộc tính của chính phần mềm [2].
[2]: Figure Quality
model for quality in use
in Session 7; pp. 12

14
2.1. Chất lượng sử dụng (2)
 Sau khi giao hàng sản phẩm phần mềm, Chất lượng sử
dụng rất có thể sẽ được đánh giá bằng khảo sát bảng
câu hỏi cho người dùng.
 Kết quả đánh giá chất lượng sử dụng là một nguồn
cấp dữ liệu trở lại cho phiên bản tiếp theo hoặc thế hệ
của sản phẩm
 Đạt được chất lượng sử dụng phụ thuộc vào việc đạt
được chất lượng bên ngoài cần thiết, do đó phụ thuộc
vào việc đạt được chất lượng nội bộ cần thiết [2]
  Để có được đánh giá tốt về chất lượng sử dụng
của người sử dụng, nó là cần thiết để có được điểm
số cao về chất lượng phần mềm nội bộ & bên ngoài
trong giai đoạn phát triển
[2]: Session 7; pp. 12
15
2.1. Chất lượng sử dụng (3)
 Bốn đặc điểm
 Hiệu quả[2]
• Khả năng của sản phẩm phần mềm cho phép người
dùng đạt được các mục tiêu được chỉ định với độ
chính xác và đầy đủ trong một ngữ cảnh sử dụng cụ
thể
 Năng suất[2]
• Khả năng của sản phẩm phần mềm cho phép người
dùng chi tiêu một lượng tài nguyên thích hợp liên
quan đến hiệu quả đạt được trong một bối cảnh sử
dụng cụ thể.

[2]: Session 7.1; pp. 12

16
2.1. Chất lượng sử dụng (4)
 Bốn đặc điểm (tiếp.)
 An toàn [2]
• Khả năng của sản phẩm phần mềm để đạt được
mức độ rủi ro có thể chấp nhận được đối với con
người, doanh nghiệp, phần mềm, tài sản hoặc môi
trường trong một bối cảnh sử dụng cụ thể
 Sự hài lòng [2]
• Khả năng của sản phẩm phần mềm để làm hài lòng
người dùng trong một bối cảnh sử dụng nhất định

[2]: Session 7.1; pp. 13

17
2.2. Chất lượng phần mềm bên ngoài
 Chất lượng phần mềm bên ngoài có 6 quan điểm
sau đây để đánh giá, đặt tên là "đặc điểm chất
lượng"
 Chức năng: Khả năng cung cấp các chức năng để đáp ứng
nhu cầu
 Độ tin cậy: Khả năng duy trì mức hiệu suất của nó
 Khả năng sử dụng: Khả năng được hiểu, được mua lại, và
được sử dụng dễ dàng, và hấp dẫn
 Hiệu quả: Khả năng cung cấp so sánh hiệu suất cao với
lượng tài nguyên được sử dụng
 Khả năng bảo trì: Khả năng được duy trì dễ dàng
 Tính di động: Khả năng được chuyển từ môi trường này
sang môi trường khác

18
2.2. Chất lượng phần mềm bên ngoài
(2)
 Mỗi đặc tính chất lượng bên ngoài cũng có thể
được coi là một loại yêu cầu như
 Yêu cầu chức năng: Phần mềm có chức năng gì?
• Yêu cầu khá nổi tiếng!! Nó không phải là dễ dàng như
vậy để phân tích, xác định và đánh giá nó
 Và có 5 loại yêu cầu không có chức năng
• Yêu cầu về độ tin cậy
• Yêu cầu về khả năng sử dụng
• Yêu cầu hiệu quả
• Yêu cầu về khả năng bảo trì
• Yêu cầu về tính di động
 Bạn có thể hình ảnh làm thế nào để xác định và
đánh giá chúng của ứng dụng phần mềm?

19
2.2. Chất lượng phần mềm bên ngoài
(3)
 Mỗi đặc điểm chất lượng có một số đặc điểm phụ
mà trên đó các nhà phát triển có thể xây dựng
chất lượng vào phần mềm và đánh giá nó
 Khái niệm về các đặc điểm phụ cho chất lượng
được giới thiệu dựa trên "ISO / IEC 9126-1: 2001
Kỹ thuật phần mềm - Chất lượng sản phẩm - Phần
1: Mô hình chất lượng"

20
2.2.1. Chức năng
 Chúng tôi tuyên bố trong slide 3.4.1 trong Chương
1: "Các yêu cầu chức năng và giao diện bên ngoài
phần mềm được phân tích và xác định bằng cách
sử dụng Sơ đồ trường hợp sử dụng và kịch bản
trường hợp sử dụng".
 Các đặc điểm phụ điển hình của Chức năng là:
 Phù hợp: Khả năng cung cấp các chức năng phù hợp để đáp
ứng nhu cầu.
 Độ chính xác: Khả năng cung cấp các chức năng chính xác để
đáp ứng nhu cầu.
• ví dụ: Số lượng số liệu tính toán đáng kể.

21
2.2.1. Chức năng (2)
 Ở đó, không chỉ phù hợp, chính xác, mà còn các
đặc điểm phụ sau đây rất quan trọng đối với Chức
năng
 Khả năng tương tác: Khả năng tương tác với các hệ thống
khác.
• ví dụ: Để đảm bảo khả năng tương tác với các hệ thống khác trong
Hệ thống Quản lý Đại học.
 Bảo mật: Khả năng bảo vệ chống truy cập trái phép.
• ví dụ: Chỉ người dùng đã đăng ký mới có thể đăng nhập vào hệ
thống. Chỉ người dùng đăng nhập vào hệ thống mới có thể truy cập
vào từng cơ sở như Hệ thống đăng ký khóa học, và ...

 Tuân thủ chức năng: Khả năng tuân thủ các tiêu
chuẩn hoặc quy ước liên quan đến chức năng.
 ví dụ: Tuân thủ "luật bảo vệ thông tin cá nhân"

22
2.2.1. Chức năng (3)
 Sau đó, câu hỏi tiếp theo là làm thế nào để đánh
giá và xây dựng trong các yêu cầu chức năng và
giao diện?
 Trong dòng trên của sự phát triển, chúng ta phải
tiến hành một số loại đánh giá như Đánh giá thiết
kế bên ngoài và nội bộ, Đánh giá mã hóa ...
 Và trong thử nghiệm, nó cũng quan trọng dựa trên
chức năng

23
2.2.2. Độ tin cậy
 Bốn đặc điểm phụ của độ tin cậy
 Trưởng thành: Khả năng tránh sự thất bại gây ra bởi lỗi ngầm
trong phần mềm.
• ví dụ: NÓ thường được yêu cầu bởi MTBF (Mean Time Between Failures).
 Lỗi khoan dung: Khả năng duy trì hiệu suất được chỉ định khi lỗi
xảy ra trong phần mềm.
• ví dụ: "Hệ thống sẽ có sẵn 24 giờ một ngày, 7 ngày một tuần, với không
quá 10% thời gian xuống."
 Recoverability: Khả năng thiết lập lại hiệu suất được chỉ định và
phục hồi dữ liệu khi thất bại xảy ra trong phần mềm.
• ví dụ: MTTR thường yêu cầu (Thời gian trung bình để khôi phục).
 Tuân thủ độ tin cậy: Khả năng tuân thủ các tiêu chuẩn hoặc quy
ước liên quan đến độ tin cậy.
Trong quá trình phân tích yêu cầu, yêu cầu độ tin cậy
được xác định và trong quá trình thử nghiệm, các yêu cầu
được đánh giá

24
2.2.3. Khả năng sử dụng
 Các đặc điểm phụ của Khả năng sử dụng
 Dễ hiểu:
• Dễ dàng hiểu các khái niệm / khả năng áp dụng của
phần mềm
• Ví dụ: Sinh viên mới đăng ký có thể hiểu khóa học
Reg. Sys. Nó là cần thiết khái niệm thống nhất và
khả năng áp dụng như hệ thống quản lý đại học
 Khả năng học tập
• Dễ dàng học tập hoạt động và sử dụng phần mềm
• Ví dụ: Các hướng dẫn để tìm hiểu các hoạt động
trong vòng 10 phút, là bắt buộc. Hệ thống trợ giúp
cho người dùng mới để hỗ trợ tất cả các hoạt động
chính là bắt buộc

25
2.2.3. Khả năng sử dụng (2)
 Các đặc điểm phụ của Khả năng sử dụng (cont.)
 Khả năng dễ vận hành
• Dễ dàng vận hành và quản lý vận hành phần mềm
• ví dụ: Học sinh mới đăng ký có thể vận hành nó mà
không cần hướng dẫn sử dụng
•  Đề nghị để có phong cách hoạt động tương tự như IE
với chip công cụ
 Hấp dẫn
• Khả năng trở thành phần mềm hấp dẫn cho người dùng
 Tuân thủ khả năng sử dụng
• Khả năng tuân thủ các tiêu chuẩn hoặc quy ước liên
quan đến khả năng sử dụng

26
2.2.3. Khả năng sử dụng (3)
 Làm thế nào để xây dựng và đánh giá khả năng sử dụng
cần thiết?

 Trước đó, các nhà phát triển phải thỏa thuận với khách
hàng.
 Tạo mẫu cho "màn hình người dùng và, nếu có thể, các
hoạt động chính", trong quá trình Phân tích Yêu cầu Phần
mềm.
"Tạo mẫu giao diện người dùng"
 Trong quá trình thiết kế, chúng được tích hợp và đánh
giá với các đánh giá.
 Và trong quá trình thử nghiệm, kiểm tra đánh giá khả
năng sử dụng nội bộ có hiệu quả
27
2.2.4. Hiệu quả
 Các đặc điểm phụ của Hiệu quả
 Hành vi thời gian
• Để hiển thị thời gian phản hồi, thời gian xử lý và tốc
độ thông lượng được thực hiện như thế nào để thực
hiện chức năng
• Ví dụ: Hệ thống sẽ hỗ trợ tối đa 50 người dùng hoạt
động đồng thời hoạt động "Đăng ký khóa học" và tất
cả người dùng có thể nhận được kết quả của hoạt
động trong vòng 10 giây
 Hành vi tài nguyên
• Khả năng sử dụng đầy đủ số lượng tài nguyên như bộ
nhớ / đĩa và tài nguyên giao tiếp
 Tuân thủ hiệu quả
• Khả năng tuân thủ các tiêu chuẩn hoặc quy ước liên
quan đến hiệu quả
28
2.2.4. Hiệu quả (2)
 Trang chiếu trước đó được cho biết như một ví dụ
về hành vi Thời gian
 Hệ thống sẽ hỗ trợ tối đa 50 người dùng hoạt động đồng
thời hoạt động "Đăng ký khóa học" và tất cả người dùng có
thể nhận được kết quả của hoạt động trong vòng 10 giây
 Tuy nhiên, đây cũng là yêu cầu hệ thống. Điều này
có nghĩa là
 Trong thiết kế hệ thống, khả năng cắt đứt, lưu trữ, mạng và
kiến trúc hệ thống được thiết kế và xác định!
 Phát triển phần mềm thường đạt được theo hệ thống có
điều kiện.
 Câu hỏi tiếp theo là khi nào và làm thế nào để xây
dựng trong các yêu cầu và đánh giá nó?

29
2.2.4. Hiệu quả (3)
 Hiệu suất phần mềm* thiết kế và đánh giá
 *): "Hiệu suất" là thuật ngữ chung, có liên quan chặt chẽ
đến "hiệu quả thời gian" của các đặc điểm phụ chất lượng
 Trong quá trình thiết kế kiến trúc phần mềm
 nhà phát triển thiết kế hoặc chọn kiến trúc phần mềm đáp
ứng các yêu cầu
 các nhà phát triển đánh giá thiết kế được đáp ứng các yêu
cầu hay không!!
 Làm thế nào để thiết kế và làm thế nào để đánh giá?  Sau
này
 Trong chương trình / phần mềm thử nghiệm của quá trình
tích hợp phần mềm
• nhà phát triển đánh giá và xác nhận phần mềm để đáp ứng các yêu
cầu
• Làm thế nào để kiểm tra và làm thế nào để xác nhận?

30
2.2.5. Khả năng bảo trì
 Các đặc điểm phụ của khả năng bảo trì
 Khả năng phân tích
• Dễ chẩn đoán thiếu sót hoặc nguyên nhân của sự thất bại
• Dễ dàng xác định địa điểm cần sửa đổi
• Ví dụ: Tài liệu hướng dẫn bảo trì được yêu cầu
 Khả năng thay đổi
• Dễ dàng thay đổi, ví dụ, dựa trên thay đổi thiết kế
• Ví dụ: Java là cần thiết để phát triển phần mềm. (Bởi vì có rất nhiều
lập trình viên Java)
 Độ ổn định: Khả năng tránh những tác động không mong
muốn của việc sửa đổi
 Khả năng kiểm chứng: Dễ kiểm tra
 Tuân thủ bảo trì: Khả năng tuân thủ các tiêu chuẩn hoặc quy
ước liên quan đến hiệu quả

31
2.2.6. Tính di động
 Các đặc điểm phụ của khả năng bảo trì
 Khả năng thích ứng: Dễ thích nghi với môi trường được chỉ
định khác nhau
 Khả năng cài đặt: Dễ cài đặt trong một môi trường được chỉ
định.
• Ví dụ: Nó thường được yêu cầu như "Các nhà điều hành phụ trách
có thể cài đặt phần mềm ít hơn 2 giờ".
 Cùng tồn tại: Khả năng cùng tồn tại với một phần mềm được
chỉ định.
 Khả năng thay thế (Khả năng tương thích): Khả năng thay
thế một phần mềm được chỉ định và được sử dụng với cùng
một môi trường.
• Ví dụ: "Nó có thể được thay thế sản phẩm trước đó mà không cần
chuyển đổi dữ liệu".
 Tuân thủ tính di động: Khả năng tuân thủ các tiêu chuẩn
hoặc quy ước liên quan đến tính di động.

32
2.2.7. Tóm tắt
 Tất cả các đặc điểm và đặc điểm phụ rất quan
trọng. Tuy nhiên, chúng có thể được tính trọng số
tùy thuộc vào loại phần mềm được phát triển,
người dùng và môi trường của phần mềm đang
chạy.
  Trong "Hệ thống đăng ký khóa học", Độ tin cậy,
Khả năng sử dụng, Hiệu quả (Hành vi thời gian)
được xem là các yêu cầu phi chức năng/đặc điểm
chất lượng quan trọng.
  Có thể nghĩ rằng những đặc điểm chất lượng
này được chỉ định bởi khách hàng

33
2.2.7. Tóm tắt (2)
 Không chỉ các yêu cầu chức năng, đối với các yêu
cầu phi chức năng, các nhà phát triển phải được
phân tích, xác định và thỏa thuận với khách hàng.
Và các nhà phát triển phải xây dựng và đánh giá
các yêu cầu / đặc điểm chất lượng
 Đôi khi, nó phải được coi là hoạt động trong
quá trình phát triển phần mềm như trường hợp
độ tin cậy, khả năng sử dụng, hiệu quả (hành vi
thời gian) trong "Hệ thống đăng ký khóa học".

34
2.3. Chất lượng phần mềm nội bộ
 Đặc điểm và đặc điểm phụ giống như chất lượng
phần mềm bên ngoài.

[2]: Figure 4 - Quality model for external and

internal quality
in clause 6, pp.7
35
2.3. Chất lượng phần mềm nội bộ (2)
 The difference between Internal & External
Software quality is when they are evaluated.
As a result, the metrics, which means
measurement, rating and evaluation way, are
different.
  Internal Software Quality is required and
evaluated within from software requirements
analysis process to software integration
process by software developer.
  The metrics are internal metrics such as
“number of failure pointed out in the review
(Reliability)”, “number of internal call to
database from a specified major use case
operation (Time behavior)”
Theses metrics are measured in the reviews.

36
2.3. Chất lượng phần mềm nội bộ (2)
 Sự khác biệt giữa chất lượng phần mềm nội bộ &
bên ngoài là khi chúng được đánh giá. Kết quả là, các
số liệu, có nghĩa là cách đo lường, xếp hạng và đánh
giá, là khác nhau.
 Chất lượng phần mềm nội bộ được yêu cầu và
đánh giá trong phạm vi từ quy trình phân tích yêu
cầu phần mềm đến quy trình tích hợp phần mềm của
nhà phát triển phần mềm.
 Các số liệu là các chỉ số nội bộ như "số lỗi được chỉ
ra trong đánh giá (Độ tin cậy)", "số cuộc gọi nội bộ
đến cơ sở dữ liệu từ một hoạt động trường hợp sử
dụng lớn được chỉ định (Hành vi thời gian)"
 Số liệu đề tài được đo lường trong các bài đánh giá.

37
Nội dung
1. Chất lượng sản phẩm phần mềm là gì?
2. Mô hình chất lượng phần mềm
 2.1. Chất lượng sử dụng
 2.2. Chất lượng phần mềm bên ngoài
 2.3. Chất lượng phần mềm nội bộ
3. Quy trình đánh giá chất lượng
4. Hệ thống quản lý chất lượng

38
3. Quy trình đánh giá chất lượng
Giới thiệu quy trình đánh giá chất lượng cơ bản tại đây, dựa trên "ISO/IEC
14598-1:1999, Công nghệ thông tin – Đánh giá sản phẩm phần mềm –
Phần 1: Tổng quan chung"

1.Thiết lập các yêu cầu đánh giá: Mục đích đánh giá và, ai và trong cảnh
nào mỗi đánh giá sẽ được quyết định

2. Thiết lập các đặc điểm kỹ thuật đánh giá: Phương pháp đo lường, tiêu
chí đánh giá được thiết lập

3. Đánh giá thiết kế: Lập kế hoạch đánh giá

4. Đạt được đánh giá:

1. thu thập giá trị đánh giá,
2. so sánh với giá trị chứng nhận,
3. 3. trên tất cả các bản án

39
3.1. Xác nhận chất lượng trong thiết kế/thi công
- Phương pháp đánh giá trong quá trình thiết kế và thi
công -
 Trong quá trình thiết kế phần mềm hoặc xây dựng,
một số loại đánh giá được tiến hành
 Mục đích:
 Để đảm bảo thông số kỹ thuật chất lượng cao (sản phẩm
trung gian) hoặc mã nguồn.
 Để đánh giá chất lượng của mã nguồn hoặc mã nguồn đo
lường số liệu nội bộ.
 Vật liệu mục tiêu:
 Mỗi deliverable của từng quá trình như yêu cầu đặc điểm kỹ
thuật, thông số kỹ thuật thiết kế cơ bản / kiến trúc, thông số
kỹ thuật thiết kế chi tiết, mã số, kiểm tra đặc điểm kỹ
thuật ...

40
3.1. Xác nhận chất lượng trong thiết kế/thi công
- Loại đánh giá và mục đích – (2)

 Đánh giá không chính thức:

 các đánh giá được tiến hành không chính thức trong nhóm
nhỏ
 Các đánh giá được thực hiện bởi một trưởng nhóm hoặc một
thành viên của nhóm cũng như tự xem xét được bao gồm
trong loại đánh giá này.

41
3.1. Xác nhận chất lượng trong thiết kế/thi công
- Loại đánh giá và mục đích – (3)
 Đánh giá thiết kế:
 Đây là đánh giá cuối cùng để xác nhận và phê duyệt
từng sản phẩm được phân phối của từng quy trình.
 Việc xem xét được thực hiện chính thức và ghi lại bởi
người quản lý dự án.
 Các vấn đề nổi bật được phát hiện trong quá trình xem
xét được chính thức theo dõi để được giải quyết.

42
3.2. Làm thế nào để xây dựng và đánh giá chất
lượng? -Trong trường hợp nghiên cứu "Hệ
thống đăng ký khóa học"(1)-

 Chọn các đặc điểm phụ chất lượng quan trọng cho dự
án
 Đối với "Hệ thống đăng ký khóa học" của chúng tôi,
các đặc điểm phụ chất lượng sau đây được chọn và
cần được xây dựng và đánh giá
 Chức năng: Phù hợp với các chính sách xem xét chung / cụ thể,
các đánh giá được tiến hành. Và kiểm tra bên ngoài (Chức năng)
có sẵn trong quá trình thử nghiệm
Trải nghiệm và giảng dạy ở các lớp sau
 Bảo mật: Dựa trên các tiêu chuẩn hệ thống, xác nhận tính bảo
mật.
 Độ tin cậy: Xác nhận kiến trúc như Multiplexing của Máy chủ
Web đảm bảo khả năng chịu lỗi. Trong kiểm tra hệ thống, nó có
sẵn để đo MTBF (Có nghĩa là thời gian giữa các thất bại).

43
3.2. Làm thế nào để xây dựng và đánh giá
chất lượng? -Trong trường hợp nghiên cứu
"Hệ thống đăng ký khóa học"(1)-
 Đối với nghiên cứu tình huống "Hệ thống đăng ký
khóa học" của chúng tôi,
 Khả năng sử dụng: Phương pháp tạo mẫu có sẵn trong quá
trình phân tích yêu cầu.
Kinh nghiệm và bài giảng trong các lớp học sau
Trong kiểm tra hệ thống, đánh giá người dùng có sẵn.
 Hiệu suất: Điều tra và tạo mẫu nếu cần thiết.
Xem trang chiếu tiếp theo. Và giải thích thêm về việc xem
xét và xác nhận sẽ được thêm vào trong lớp "Kiến trúc xác
nhận".
 Bảo trì: Tùy thuộc vào người sử dụng hoặc hệ thống thiết bị.

44
3.3. Cách xây dựng và đánh giá hiệu suất trong
nghiên cứu tình huống
 Điều tra một số trường hợp phát triển dựa trên
Struts để xác nhận struts dựa trên phát triển đáp
ứng các yêu cầu thực hiện như
 "Hệ thống sẽ hỗ trợ tối đa 50 người dùng hoạt động đồng
thời hoạt động "Đăng ký khóa học" và tất cả người dùng có
thể nhận được kết quả của hoạt động trong vòng 10 giây."
 Nếu chúng ta không thể tìm ra báo cáo trường
hợp phát triển phù hợp, Tạo mẫu để xác nhận
struts dựa trên phát triển đáp ứng các yêu cầu
thực hiện là rất hiệu quả.
 Trong trường hợp này, tạo mẫu này nên đạt được
trong phân tích yêu cầu phần mềm hoặc quá trình
kiến trúc phần mềm

45
3.4. Quản lý rủi ro về chất lượng -Làm thế
nào để lựa chọn các đặc điểm chất lượng
quan trọng-
 Trong 3.2, Chúng tôi chọn đặc điểm chất lượng
quan trọng, và đặc biệt tập trung vào độ tin cậy,
khả năng sử dụng, hiệu suất.
 Tại sao chúng tôi tập trung vào độ tin cậy, khả năng
sử dụng, hiệu suất? Và chúng tôi đã lập kế hoạch
ứng phó, và kế hoạch đánh giá / thử nghiệm.
 Đây là những ví dụ điển hình về Quản lý rủi ro trong
Dự án Phát triển Phần mềm.
 Bất kỳ rủi ro chất lượng khác trong nghiên cứu
trường hợp "Hệ thống đăng ký khóa học"?

46
Nội dung
1. Chất lượng sản phẩm phần mềm là gì?
2. Mô hình chất lượng phần mềm
 2.1. Chất lượng sử dụng
 2.2. Chất lượng phần mềm bên ngoài
 2.3. Chất lượng phần mềm nội bộ
3. Quy trình đánh giá chất lượng
4. Hệ thống quản lý chất lượng

47
4.1. "Hệ thống quản lý chất lượng" là gì
 "Hệ thống quản lý chất lượng" là hệ thống kiểm
soát/quản lý tổ chức về chất lượng sản phẩm hoặc
dịch vụ mà họ cung cấp.
 "Hệ thống quản lý chất lượng" hỗ trợ các tổ chức
cung cấp dịch vụ hoặc sản phẩm chất lượng cao
được khách hàng hài lòng.
 Tiêu chuẩn quản lý chất lượng quốc tế ISO 9000
cung cấp cơ sở để thiết lập hệ thống quản lý chất
lượng hiệu quả và hiệu quả trong các tổ chức nhà
cung cấp.

48
ISO 9000 family
 ISO 9000: 2005 “Quality Management
System – Fundamentals and vocabulary”
 ISO 9001: 2008 “Quality Management
System – Requirements”
 ISO/ITCTR 90003: 2004 “Software
Engineering – Guidelines for the
application of ISO 9001:2000 to Computer
Software”

49
4.2. Tám "Nguyên tắc quản lý chất lượng"
 ISO 9000 quy định 8 Nguyên tắc quản lý chất
lượng là khái niệm cơ bản cho tất cả các hệ thống
quản lý chất lượng, được liệt kê trong những điều
sau đây:
 1. Tập trung vào khách hàng: Sự hài lòng của khách hàng là
mục tiêu quan trọng nhất của Hệ thống quản lý chất lượng.
 2. Lãnh đạo: Các nhà lãnh đạo quản lý thể hiện tầm nhìn và
mục tiêu chất lượng để tổ chức thống nhất mục đích và định
hướng của họ.

50
4.2. Eight “Quality Management Principles” (2)
 3. Sự tham gia của mọi người: Tất cả mọi người,
chẳng hạn như bộ phận quản lý, lập kế hoạch, bán
hàng và phát triển cần được tham gia đầy đủ và có
động lực để thực hiện các mục tiêu của tổ chức.
 4. Cách tiếp cận quy trình: Các hoạt động và nguồn
lực của Hệ thống quản lý chất lượng nên được
quản lý và thiết lập như một quy trình.
 5. Cách tiếp cận hệ thống để quản lý: Các quy trình
liên quan nên được tích hợp như một hệ thống để
quản lý hiệu quả và thực hiện các mục tiêu tổ chức
(do đó, hệ thống được gọi là Hệ thống quản lý chất
lượng).

51
4.2. Eight “Quality Management Principles” (3)
 Cải tiến liên tục: Hệ thống quản lý chất lượng cần
được cải tiến liên tục, không nên chỉ được thiết
lập, để thực hiện các mục tiêu tổ chức bằng cách
sử dụng kế hoạch, làm, kiểm tra và chu kỳ hành
động.
 Cách tiếp cận thực tế để ra quyết định: Các quyết
định quản lý chất lượng nên dựa trên dữ liệu
được đo lường đặc biệt trong dự án này hoặc
trước đó.
 Mối quan hệ nhà cung cấp cùng có lợi: Mối quan
hệ có đi có lại giữa các nhà cung cấp và tổ chức là
một trong những yếu tố quan trọng để thực hiện
mục tiêu cao hơn của tổ chức.
52
4.3. Application to Software
Development Project
-User Needs and Requirements-
 Trong trường hợp ứng dụng cho một dự án phát
triển phần mềm,
 Tiêu chuẩn hệ thống quản lý chất lượng đòi hỏi tổ
chức phải "hiểu nhu cầu của khách hàng, đáp ứng
yêu cầu của khách hàng và phấn đấu vượt quá
mong đợi của khách hàng".

53
4.3. Ứng dụng vào dự án phát triển phần mềm
-Nhu cầu và yêu cầu của người dùng (2)-
 Trong Dự án Phát triển Phần mềm, trong quá trình
Phân tích Yêu cầu,
 Các yêu cầu đối với phần mềm cần được phân tích, xác định
và xem xét bởi các bên liên quan bao gồm cả phía khách hàng.
 Trong quá trình này, điều quan trọng là phải làm rõ những đặc
điểm chất lượng nào là quan trọng đối với khách hàng và tập
trung họ phát triển phần mềm.
 dựa trên sự hiểu biết về nhu cầu của khách
hàng.
 Trong quá trình này, yêu cầu trình độ phần mềm cần
được phát triển.
 dựa trên sự hiểu biết về nhu cầu của khách hàng
và một số nỗ lực để đáp ứng chúng.

54
4.3. Ứng dụng vào dự án phát triển
phần mềm -Quá trình phát triển-

 Trong mỗi dự án, các quy trình phát triển phần

mềm cần được quy định cụ thể để đảm bảo các
sản phẩm được phát triển có chất lượng tốt.
 Quá trình này thường được chỉ định dựa trên quá
trình phát triển phần mềm tiêu chuẩn trong tổ
chức.
 Trong quá trình phát triển, các mục sau đây được
chỉ định.
 Đầu vào/đầu ra và quy trình làm việc của quy trình,
 Quản lý, thành viên, môi trường, phương pháp và đào tạo
của quá trình

55
4.3. Ứng dụng vào dự án phát triển phần mềm -Quá
trình phát triển- (2)

 Trong quá trình này, cũng có chất lượng sau đây

liên quan đến quá trình phụ nên được bao gồm
hoặc đại diện.
 Quá trình xem xét liên quan đến những người bên nhà
phát triển như người bán, phát triển và kiểm tra và
những người bên phía khách hàng.
 Quá trình cải tiến chất lượng, trong đó các bên liên
quan của dự án nỗ lực phát triển sản phẩm chất lượng
tốt bằng cách sử dụng chu kỳ Plan-Do-Check-Action.

56
4.3. Ứng dụng cho Dự án phát triển phần mềm -
Cách tiếp cận thực tế để xây dựng và đánh giá
chất lượng-
 Trong quản lý chất lượng bao gồm xây dựng và
đánh giá, việc ra quyết định nên được thực hiện
dựa trên dữ liệu được đo lường trong dự án hoặc
các dự án có kinh nghiệm.
 Trong Dự án Phát triển Phần mềm:
 Việc ra quyết định quản lý chất lượng như thiết lập giá trị
mục tiêu chất lượng, chất lượng đánh giá của phần mềm
nên được thực hiện dựa trên dữ liệu được đo lường.
 Việc ra quyết định giao hàng cũng nên được thực hiện dựa
trên dữ liệu đánh giá chất lượng và dữ liệu kết quả thử
nghiệm.

57
4.4. Implementation Approach to Quality
Management System -Quality Manual: a
Document for specifying QMS-
 QMS của tổ chức phải được chỉ định, ghi lại và quản lý bởi
"Hướng dẫn sử dụng chất lượng".
 Trong "Hướng dẫn sử dụng chất lượng", toàn bộ bức tranh
về hệ thống quản lý chất lượng của tổ chức:
 Phạm vi của hệ thống quản lý chất lượng: Những phòng ban / dự án nào
được bao gồm trong QMS?
 Định hướng và mục tiêu chất lượng: Lãnh đạo quản lý nên tuyên bố
chúng ở đây và chia sẻ với các bên liên quan
 Thành lập thủ tục bằng văn bản
 Hệ thống tài liệu
 Mô tả mối tương quan giữa các quy trình trong hệ thống quản lý chất
lượng.
 Hướng dẫn sử dụng chất lượng là một đường cơ sở để cải
thiện hệ thống.
58
4.4. Phương pháp tiếp cận thực hiện hệ
thống quản lý chất lượng -Các thủ tục
bằng văn bản-
 Các thủ tục công việc bằng văn bản của các quy trình và
hoạt động liên quan đến chất lượng cần được thiết lập.
 Ví dụ, trong Dự án Phát triển Phần mềm,
 Quy trình liên quan đến khách hàng như định nghĩa/đánh giá yêu cầu
của người dùng.
 Quy trình quản lý tài liệu bao gồm kiểm toán/xem xét nội bộ, kiểm soát
thay đổi.
 Quy trình quản lý mã nguồn bao gồm kiểm toán / xem xét nội bộ, quản
lý cấu hình, hành động khắc phục, hành động phòng ngừa.
 Quy trình quản lý hồ sơ chất lượng.
 Quy trình quản lý sản phẩm không tuân thủ.
 Đây có thể được mô tả như là một phần của chất lượng
hướng dẫn sử dụng hoặc như là một tài liệu thủ tục bằng
văn bản cá nhân.
59
4.4. Implementation Approach to Quality
Management System
- Documentations and their Development &
Change Control-

 Những loại tài liệu nào được phát triển và duy trì
trong dự án này nên được thiết lập. Đối với dự án
phát triển phần mềm:
 Kế hoạch phát triển, Thông số kỹ thuật yêu cầu,
 Thông số kỹ thuật thiết kế chức năng / kiến trúc / chi tiết,
 Kiểm tra đặc điểm kỹ thuật,
 Hướng dẫn sử dụng (, Mã nguồn) Một số lần chúng được
giao
 Để hoàn thành phát triển của mỗi tài liệu, nó là cần
thiết để phê duyệt chính thức bằng thủ tục phê
duyệt như quản lý / đánh giá khách hàng.
60
4.4. Phương pháp tiếp cận thực hiện hệ
thống quản lý chất lượng
- Tài liệu hướng dẫn và phát triển của họ &
Kiểm soát thay đổi (2)-
 Change control procedure, how to
change each document when change
requests are coming, should be
established
 Principles of the procedure are
 After the approve, changes are carried out.
 Evaluate extent of the impact, and confirm
them by testing or review.
 Notify the related stakeholders.

61
4.5. Tóm tắt
- Chúng ta có thể làm gì bằng cách sử dụng các tiêu chuẩn...

 Trong "ISO9001: 2008", yêu cầu về hệ thống quản lý chất

lượng được mô tả.
 Tiêu chuẩn này có thể được sử dụng trong kiểm toán bằng
cách:
 phòng kiểm toán nội bộ, hoặc
 tổ chức kiểm toán bên ngoài bao gồm tổ chức kiểm toán chính thức.
 Sử dụng tiêu chuẩn iso 9000 series nội bộ, các tổ chức như
các công ty có thể tạo hoặc nâng cấp "Hệ thống quản lý
chất lượng" bao gồm cả hệ thống tài liệu đáng tin cậy.
 Họ cũng hy vọng sẽ được khách hàng tin tưởng, điều đó có
nghĩa là để có được sự hài lòng của khách hàng tốt hơn.

62
4.5. Tóm tắt
-Hệ thống chứng nhận ISO9001-
 Chứng nhận ISO 9001: 2008 có thể nhận được
bằng cách vượt qua kiểm toán bởi các tổ chức
kiểm toán chính thức.

 "Chứng nhận" của ISO 9001:2008 cho thấy;

 Các phạm vi sản phẩm hoặc dịch vụ được hiển thị

được thực hiện bởi tổ chức trong đó hệ thống
quản lý chất lượng đã được tìm thấy phù hợp với
"Hệ thống quản lý chất lượng tiêu chuẩn ISO 9001:
2008".

63