Lập kế hoạch hệ thống quản lý chất lượng phần mềm Software Quality System Plan

Trường Cao đẳng Công Nghệ Thông Tin Tp.HCM
Khoa CNTT
TUYÊN BỐ DỰ ÁN
Đồ án môn: QUẢN LÝ ĐỀ ÁN CNPM
Nhóm: 1 - Lớp: C10CNPM3
Tên đề tài: Lập kế hoạch Hệ thống quản lý chất lượng phần mềm
(Software Quality System Plan)
2. Ngày bắt đầu: 11/09/2012 Ngày kết thúc: 19/11/2012
3. Danh sách các thành viên:
1. Trương Văn Việt (NT) MSSV:11000411 DT:01882345521
Email:
2. Trần Thị Hoàng Oanh MSSV:11000435 DT:0977899090
Email:
3. Nguyễn Thị Hoài Thương MSSV:11000365 DT:01657181001
Email:
4. Mục tiêu của đề tài:
1. Hiểu được về SQS Plan và cách thức triển khai SQS Plan.
2. Hiểu rõ các yếu tố để đánh giá hệ thống chất lượng phần mềm.
3. Hiểu các vấn đề ảnh hưởng đến phạm vi và quyền hạn của thống chất lượng
phần mềm.
4. Ứng dụng SOS vào dự án phần mềm ACIS.
5. Nội dung thực hiện:
1. Giới thiệu tổng quan về SQS
1.1/ Các tiêu chuẩn (Standards)
1.2/ Xem xét, xem lại (Reviewing)
1.3/ Kiểm tra (Testing)
1.4/ Phân tích lỗi (Defect analysis)
1.5/ Quản lý cấu hình (Configuration Management - CM)
1.6/ Bảo mật (Security)
1.7/ Đào tạo, huấn luyện (Education/Training)
1.8/ Quản lý người cung cấp, thầu phụ (Vendor Management)

1.9/ An toàn (Safety)
1.10/ Quản lý rủi ro (Risk Management)
SQSP là gì? SQSP là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết
các HTQLCLPM. Kết quả của hoạt động này thường là một (hoặc nhiều) tài liệu
gọi là bản kế hoạch.
2. Xây dựng kế hoạch SQS Plan
• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm.
• Xác định nhân lực, vật lực và chi phí.
• Chỉ định phương pháp, cách tiếp cận để thực thi dự án.
• Lập kế hoạch làm việc chi tiết.
• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án.
• Kế hoạch quản lý cấu hình và quản lý các rủi ro.
• Các kế hoạch khác.
• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án.
3. Ứng dụng SQS vào dự án thực tế:
Ứng dụng SOS vào dự án phần mềm ACIS.
4. Đánh giá - kết luận - đề xuất, cải tiến
6. Các phương pháp tiếp cận:
- Tìm hiểu các tài liệu liên quan đến hệ thống chất lượng phần mềm.
- Các Ebook về quản lý chất lượng phần mềm.
- Tham khảo một số Website giới thiệu các dự án thực tế.
7. Kết quả dự kiến :
- Hiểu được hệ thống chất lượng phần mềm.
- Các yếu tố, các vấn đề liên quan đến chất lượng của một phần mềm.
- Tìm hiểu thiết lập kế hoạch đảm bảo chất lượng phần mềm và ứng dụng lập kế
hoạch cho dự án phần mềm ACIS
8. Tài liệu tham khảo:
1. “Shari Lawrence Pfleeger et al. Solid Software, Upper Saddle River”, NJ: Prentice
Hall, 2002.
2. Roger S. Pressman, “Software Engineering: A Practitioner's Approach”, New York:

McGraw-Hill, 2001.
3. John W. Horch, “Practical Guide to Software Quality Management”, 2003, Second
Edition, Artech House.
4. G. Gordon Schulmeyer, “Handbook of Software Quality Assurance”, 2008, Fourth
Edition, Artech House, INC.
5. Link Website tham khảo:
- : Website chuyên về mảng SQS
Plan.
-
nghe/2006/05/1189009/quan-ly-chat-luong-phan-mem/ : Tham khảo về các nội
dung cơ bản của SOS Plan.
- : Tài liệu cơ bản về SOS Plan (Tiếng
Anh)
- (Dự án ACIS)
[1] John W. Horch, Practical Guide to Software Quality Management, 2003,
Second Edition, Artech House
[2] G. Gordon Schulmeyer, Handbook of Software Quality Assurance, 2008,
Fourth Edition, Artech House, INC
-
Phân công công việc:
1) Trương Văn Việt
• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm
• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án
• Các kế hoạch khác
• Ứng dụng vào dự án
• Đánh giá – Kết luận
2) Trần Thị Hoàng Oanh
• Xác định nhân lực, vật lực và chi phí
• Lập kế hoạch làm việc chi tiết
• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án

• Ứng dụng vào dự án
• Đánh giá – Kết luận
3) Nguyễn Thị Hoàng Thương
• Tìm hiểu tổng quan về SOS Plan
• Chỉ định phương pháp, cách tiếp cận để thực thi dự án
• Kế hoạch quản lý cấu hình và quản lý các rủi ro
• Ứng dụng vào dự án
• Đánh giá – Kết luận
KẾ HOẠCH THỰC HIỆN ĐỀ TÀI
STT Ngày Nội dung
Chữ ký
GVHD
1 19/09/2012
Xác định đề tài và những việc cần làm để thực
hiện đề tài
2 26/09/2012 Tìm hiểu tổng quan về SOS Plan
3 10/10/2012
Tìm hiểu sâu hơn các vấn đề liên quan đến Hệ
thống Quản Lý Chất lượng phần mềm
4 20/10/2012 Tìm hiểu 1 dự án có ứng dụng SOS Plan
5 22/10/2012
Ứng dụng kế hoạch Hệ Thống Quản Lý Chất
lượng phần vào 1 dự án (Ứng dụng SOS vào dự
án phần mềm ACIS)
6 05/11/2012 Hoàn chỉnh và viết báo cáo
7 13/11/2012 Tuần lễ dự trù đề hoàn chỉnh đề tài
8 19/11/2012 Nộp đề tài
MỤC LỤC

Phần 1. GIỚI THIỆU 1

1. Tổng quan: 1
1.1. Quản lý chất lượng phần mềm là gì? 1
1.2. Giới thiệu Hệ thống quản lý chất lượng phần mềm 2
1.2.1. Mục tiêu 2
1.2.2. Hoạt động và yếu tố cơ bản 2
1.3. Lập kế hoạch Hệ thống quản lý chất lượng phần mềm 12
2. Đánh giá hiện trạng chung: 13
3. Đề xuất nội dung nghiên cứu: 14
4. Nội dung thực hiện: 14
Phần 2: PHƯƠNG PHÁP LẬP KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG 14
1. Ước lượng phạm vi và kích thước dự án: 14
1.1. Phạm vi và kích thước 14
1.1.1. Tổng quan: 14
1.1.2. Quy trình quản lý phạm vi: 15
1.1.3. Lập kế hoạch phạm vi: 15
1.1.3.1. Thảo quy định phạm vi dự án: 15
1.1.3.2. Thảo tôn chỉ dự án: 17
1.1.3.3. Thảo bảng kê công việc: 18
1.2. Khối lượng công việc phải làm 19
2. Xác định nhân lực và chi phí: 20
2.1. Nhân lực: 20
2.1.1. Các dạng tổ chức: 21
2.1.2. Chức năng cơ bản trong các cấu trúc tổ chức: 22
2.1.3. Chức năng cơ bản trong các cấu trúc tổ chức: 22
2.1.4. Các đối tượng liêu quan dự án: 23
2.2. Chi phí: 25
2.2.1. Lập kế hoạch về nguồn tài nguyên: 25
2.2.1.1. Nguyên tắc ước lượng chi phí: 26
2.2.1.2. Chi phí nguyên vật liệu: 27
2.2.1.3. Chi phí cơ sở vật chất: 28

2.2.2. Ước tính chi phí: 28
2.2.2.1. Ước lượng chính quy: 29
2.2.2.2. Ước tính sử dụng kết quả chào thầu: 29
2.2.2.3. Thông tin lịch sử hay cơ sở dữ liệu dự án: 30
2.2.2.4. Ước lượng theo giai đoạn: 30
2.2.2.5. Ước lượng theo tham số: 31
2.2.2.6. Ước lượng dưới lên: 32
2.2.2.7. Ước lượng trên xuống: 33
2.2.2.8. Độ tin cậy trong ước lượng: 33
2.2.3. Dự toán ngân sách cho các chi phí (kế toán dự án): 35
2.2.4. Kiểm soát chi phí: 35
2.2.4.1. Theo dõi kinh phí qua các chỉ tiêu: 35
2.2.4.2. Kiểm soát - điều chỉnh phí: 36
2.2.4.3. Tiến hành cập nhật kinh phí: 37
3. Phương pháp, cách tiếp cận để thực thi dự án: 38
3.1. Thế nào là dự án thành công: 38
3.2. Sự thành công – thất bại của dự án: 38
3.3. Các công việc cơ bản của quản trị dự án: 39
3.4. Triển khai dự án: 39
4. Lập kế hoạch làm việc chi tiết: 40
4.1. Giới thiệu: 40
4.2. Cấu trúc phân rã chi tiết công việc (WBS): 42
4.3. Các yếu tố của kế hoạch dự án toàn diện 45
5. Kế hoạch phối hợp và hỗ trợ hoàn thành dự án: 46
5.1. Xác định thông tin-thiết kế kế hoạch trao đổi thông tin: 47
5.1.1. Yêu cầu trao đổi thông tin: 47
5.1.2. Lập kế hoạch truyền thông – kế hoạch trao đổi thông tin: 48
5.2. Phân phối thông tin – xác định các kênh trao đổi thông tin: 49
5.3. Báo cáo hiệu quả dự án: 50
6. Kế hoạch quản lý cấu hình và quản lý các rủi ro: 51

6.1. Kế hoạch quản lý cấu hình: 51
6.1.1. Giới thiệu: 51
6.1.2. Lập kế hoạch quản lý cấu hình: 52
6.1.2.1. Định danh các chỉ số cấu hình IC: 52
6.1.2.2. Kiểm soát phiên bản 53
6.1.2.3. Quản lý baseline 53
6.1.2.4. Kiểm soát thay đổi 54
6.1.2.5. Báo cáo tình trạng cấu hình 55
6.1.2.6. Kiểm tra và xem xét (Auditing) 55
6.1.2.7. Quản lý release 55
6.1.2.8. Lưu trữ và chép dự phòng 56
6.2. Kế hoạch quản lý rủi ro: 57
6.2.1. Giới thiệu: 57
6.2.2. Kế hoạch quản lý rủi ro: 57
6.2.2.1. Nhận diện rủi ro: 58
6.2.2.2. Phân tích và phân loại rủi ro: 60
6.2.2.3. Kiểm soát rủi ro: 62
6.2.2.4. Giám sát và điều chỉnh: 63
7. Các kế hoạch khác: 64
8. Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án: 64
8.1. Định nghĩa cấu trúc tài liệu dự án: 64
8.2. Quy trình quản lý yêu cầu thay đổi: 64
Phần 3: ỨNG DỤNG KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM
VÀO DỰ ÁN ACIS 65
Phần 4: ĐÁNH GIÁ - KẾT LUẬN 83
1. Kết quả đạt được: 83
2. Hạn chế 84
3. Đề xuất – cải tiến 84
DANH SÁCH HÌNH ẢNH, HÌNH VẼ
Hình 1. Các nội dung liên quan tới hệ thống chất lượng phần mềm 1

Hình 2. Vòng đời phát triển phần mềm 2
Hình 3. Các hoạt động chính trong hệ thống quản lý chất lượng phần mềm 3
Hình 4. Các tiêu chuẩn 4
Hình 5. Tổng quan về chu trình phát triển phần mềm 6
Hình 6. Quy trình kiểm tra đơn giản 7
Hình 7. Quản lý cấu hình các hoạt động 9
Hình 8. Biểu đồ khối thể hiện tầm quan trọng về mục tiêu chất lượng và chu kỳ phát triển
phần mềm, mỗi thành phần có liên hệ chặt chẽ với nhau 12
Hình 9. Chức năng cơ bản trong các cấu trúc tổ chức 22
Hình 10. Sơ đồ tổ chức theo cấu trúc dự án ma trận 23
Hình 11. Quy trình cơ bản quản lý rủi ro 57
Hình 12. Mối quan hệ và trình tự các bước trong quy trình kiểm soát rủi ro 59
Hình 13. Ví dụ đơn giản dùng sơ đồ xương cá định vị rủi ro 61
Hình 14. Một số chiến lược và minh họa các phương pháp đối phó rủi ro thường gặp 62
DANH SÁCH BẢNG BIỂU
Bảng 1. Phân tích lỗi 8
Bảng 2. Các dạng tổ chức nhân lực 21
Bảng 3. Các đối tượng liên quan dự án trong các dự án điển hình 24
Bảng 4. Các thành phần của Hiệu suất chi phí và Biến động chi phí 35
Bảng 5. Các công thức tính trong EMV 37
Bảng 6. Yêu cầu trao đổi thông tin 48
Bảng 7.Các phương pháp trao đổi thông tin 49
Bảng 8. Phân tích biến động ngân sách 51
Phần 1. GIỚI THIỆU
1. Tổng quan:
1.1. Quản lý chất lượng phần mềm là gì?[1]
Lâu nay, nói đến chất lượng phần mềm, không ít người nghĩ ngay đến vấn đề là xác định
xem phần mềm đó có phát sinh lỗi hay không, có "chạy" đúng như yêu cầu hay không và
cuối cùng thường quy về vai trò của hoạt động kiểm tra phần mềm (testing) như là hoạt
động chịu trách nhiệm chính.

Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tình
của hoạt động phát triển phần mềm, điều họ cần quan tâm là liệu sản phẩm cuối cùng
giao cho họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.
Tuy nhiên theo quan điểm của người phát triển phần mềm, thực tế cho thấy hoạt động
kiểm tra phần mềm là quan trọng, nhưng không đủ để đảm bảo sản phẩm sẽ được hoàn
thành đúng hạn và đúng yêu cầu. Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải
làm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiều
thời gian để sửa chữa.
Thực tế cho thấy, để đảm bảo được hai tiêu chí "đơn giản" trên của khách hàng, đòi hỏi tổ
chức không chỉ vận hành tốt khâu kiểm tra phần mềm, mà phải tổ chức và duy trì sự hoạt
động nhịp nhàng của cả một hệ thống các công việc liên quan đến một dự án phần mềm,
từ đây xuất hiện một khái niệm có tên là “hệ thống quản lý chất lượng phần mềm”
(HTQLCLPM).
Hình 1. Các nội dung liên quan tới hệ thống chất lượng phần mềm
Lập kế hoạch quản lí chất lượng phần mềm Trang 11
Hiện có nhiều mô hình cung cấp các tiêu chuẩn cũng như hướng dẫn để triển khai
HTQLCLPM. Hai trong số những mô hình được áp dụng rộng rãi hiện nay là ISO 9001-
2000 và CMM/CMMi. Trong khi ISO 9001-2000 là tiêu chuẩn quản lý chất lượng dành
cho tất cả các ngành nghề với những điều khoản ngắn gọn và mang tính tổng quát, thì
CMM/CMMi là một bộ tập hợp khá đồ sộ các kinh nghiệm thực hành (gần 450 trang với
CMM, và gần 700 trang với CMMi) có thể làm người đọc chưa có kinh nghiệm khó biết
được các hoạt động và yếu tố đặc trưng cơ bản của HTQLCLPM là gì.
1.2. Giới thiệu Hệ thống quản lý chất lượng phần mềm [1]
Hệ thống quản lý chất lượng phần mềm bao gồm các quy trình được thực thi xuyên suốt
chu kỳ phát triển của dự án phần mềm nhằm quản lý chất lượng hệ thống phần mềm sao
cho không vượt quá yêu cầu của khách hàng, các chuẩn của công ty, tổ chức để đảm bảo
được chất lượng phần mềm.
1.2.1. Mục tiêu [1]
SQS thường có 2 mục tiêu:
• Mục tiêu thứ nhất: xây dựng chất lượng cho phần mềm ngay từ giai đoạn bắt đầu. Điều

này đồng nghĩa với việc bảo đảm các yêu cầu cho phần mềm phải được định nghĩa, diễn
đạt và hiểu một cách đúng đắn giữa người đưa ra yêu cầu và người thực hiện yêu cầu.
• Mục tiêu thứ hai: bảo đảm chất lượng của phần mềm xuyên suốt quá trình phát triển
(software life cycle – SLC).
Hình 2. Vòng đời phát triển phần mềm
1.2.2. Hoạt động và yếu tố cơ bản [1]
Một HTQLCLPM hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành, chúng
khác nhau tùy theo từng tổ chức khi triển khai.
Lập kế hoạch quản lí chất lượng phần mềm Trang 12
Có 10 hoạt động và yếu tố cơ bản nhất thường gặp:
Hình 3. Các hoạt động chính trong hệ thống quản lý chất lượng phần mềm
1 Các tiêu chuẩn (Standards) [1]
Sản xuất phần mềm ngày nay không còn đơn thuần mang tính sáng tạo ngẫu hứng như
trước đây, mà đang trở thành một lĩnh vực được kiểm soát chặt chẽ, theo những tiêu
chuẩn nhất định. Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệu
quả nhất, được đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electrical
and Electronics Engineers, Inc – Học viện các kỹ sư điện và điện tử), từ các tổ chức quốc
tế như ISO (International Organization for Standardization), hoặc các quy tắc chuẩn hóa
để giao tiếp giữa sản phẩm với nhau hoặc đơn giản do chính tổ chức phát triển PM đề
ra để áp dụng cho chính họ.
Lập kế hoạch quản lí chất lượng phần mềm Trang 13
Hình 4. Các tiêu chuẩn
Các tiêu chuẩn có thể bao gồm tất cả các khía cạnh của một chu kỳ phát triển PM, trải dài
suốt mọi pha phát triển. Bất kể tiêu chuẩn xuất phát từ đâu, từ nội bộ công ty, hoặc từ
ngoài, nó đều phải có một số đặc điểm sau:
• Tính cần thiết (Necessity)
• Tính khả thi (Feasibility)
• Tính đo lường được (Measurability)
Các tiêu chuẩn nên được chọn và thể hiện sao cho khi sử dụng, các khía cạnh kỹ thuật
cần thiết sẽ được nhấn mạnh, tránh trường hợp hiểu sai hoặc sa vào những tiểu tiết phụ

trợ. Một ví dụ thường thấy là tiêu chuẩn định dạng cho tài liệu, mục đích của tiêu chuẩn
là để bảo đảm khía cạnh chất lượng về kỹ thuật của tài liệu. Tuy nhiên, trong rất nhiều
trường hợp tiêu chuẩn đã bị hiểu sai và sa đà vào việc kiểm tra các chi tiết về mặt hình
thức. Lưu ý là để bảo đảm các tiêu chuẩn được nghiêm túc thực hiện, chúng phải mang
tính bắt buộc và được quy định ở chính sách cấp công ty.
Một dạng phổ biến bắt buộc phải có của tiêu chuẩn là hệ thống các “quy trình”, kèm theo
các bộ phận phụ thuộc như “thủ tục”, “hướng dẫn”, “mẫu biểu”, “tiêu chuẩn”,…. Tùy
Lập kế hoạch quản lí chất lượng phần mềm Trang 14
theo lĩnh vực hỗ trợ mà chúng có các tên tương ứng, chẳng hạn: quy trình sản xuất PM,
quy trình kiểm soát chất lượng, quy trình kiểm tra
2 Xem xét, xem lại (Reviewing) [1]
Mục đích là để cung cấp thông tin trực quan về tình trạng của các hoạt động xảy ra trong
suốt quá trình sản xuất và cài đặt PM.
Xem xét trên sản phẩm – thường được gọi là xem xét kỹ thuật – bao gồm hai loại: chính
thức hoặc không chính thức. Xem xét không chính thức thường được thực hiện trong quá
trình phát triển sản phẩm, còn xem xét chính thức thường được thực hiện tại thời điểm
kết thúc các chặng phát triển.
Điểm khác nhau chính về mặt kỹ thuật giữa xem xét chính thức và không chính thức là ở
mức độ nghiêm ngặt của quy trình và các bước thực hiện. Chẳng hạn, xem xét chính thức
buộc phải lên kế hoạch, ghi nhận tất cả các lỗi phát hiện và giám sát đến khi tất cả lỗi đã
được sửa chữa, xem xét không chính thức thì không bắt buộc.
Trong thực tế, có khá nhiều định nghĩa và nhiều loại xem xét khác nhau. Về tổng quan,
IEEE định nghĩa có ba loại:
• Review: Cuộc họp chính thức nhằm trình bày một vấn đề, một tài liệu, một sản phẩm
cho những người quan tâm, người sử dụng, khách hàng nhằm thu thập ý kiến phản
hồi hoặc đạt được sự thỏa thuận phê chuẩn trên vấn đề, tài liệu hoặc sản phẩm được
trình bày.
• Walkthrough: Kỹ thuật đánh giá không chính thức, qua đó tác giả của một tài liệu, sản
phẩm giải thích tài liệu, sản phẩm đó cho một nhóm đồng nghiệp. Các đồng nghiệp
này sẽ đặt câu hỏi hoặc cho ý kiến bổ sung về một số lĩnh vực để bảo đảm chất lượng

kỹ thuật của tài liệu hoặc sản phẩm.
• Inspection: Kỹ thuật đánh giá chính thức, qua đó tài liệu, sản phẩm được những
người không phải là tác giả hoặc trực tiếp liên quan kiểm tra một cách chi tiết để phát
hiện lỗi, các vi phạm tiêu chuẩn, hoặc các vấn đề khác (nếu có). Về cơ bản, nó được tổ
chức và thực hiện chặt chẽ hơn walkthrough. Vai trò của những người tham gia được
phân định rõ ràng. Tài liệu chuẩn bị cho việc xem xét được chuẩn bị trước chu đáo.
Một điểm cần hết sức lưu ý để bảo đảm việc xem xét mang lại hiệu quả là: mục tiêu
chính của việc xem xét nhằm để tìm ra lỗi. Một trong những lý do chính khiến cho rất
Lập kế hoạch quản lí chất lượng phần mềm Trang 15
nhiều cuộc xem xét không mang lại hiệu quả như mong muốn là các cuộc xem xét đó bị
"lún" vào việc thảo luận các giải pháp để sửa chữa lỗi. Sửa lỗi thường yêu cầu phải có sự
phân tích kỹ lưỡng cũng như phải chấp nhận các phản biện trên các phương pháp sửa lỗi,
công việc này hoàn toàn không phù hợp cho một buổi xem xét tìm lỗi. Một khi tìm thấy
lỗi, nó nên được giao cho một/nhóm người phân tích và giải quyết, việc xem xét chỉ nên
chú tâm vào việc chỉ ra các sai sót.
Hình 5. Tổng quan về chu trình phát triển phần mềm
3 Kiểm tra (Testing) [1]
Kiểm tra lỗi (testing) là một hoạt động sống còn trong sản xuất PM. Kiểm tra lỗi nhằm
mục đích chứng minh rằng các yêu cầu đối với PM là được thỏa mãn. Các hoạt động
kiểm tra bao gồm các bước: lập kế hoạch, thiết kế test, thi hành test, và báo cáo kết quả
kiểm tra.
Ở đây muốn nhấn mạnh đến bước lập kế hoạch kiểm tra bắt đầu từ giai đoạn nhận và phát
triển yêu cầu. Tương tứng với mỗi yêu cầu là một phương pháp kiểm tra thích hợp. Một
yêu cầu không thể coi là hoàn chỉnh nếu như nó không thể kiểm tra được. Kế hoạch kiểm
tra được thiết lập ngay từ chặng phát triển yêu cầu. Do yêu cầu thường thay đổi xuyên
suốt dự án, kế hoạch kiểm tra do đó cũng phải thay đổi theo.
Lập kế hoạch quản lí chất lượng phần mềm Trang 16
Hình 6. Quy trình kiểm tra đơn giản
4 Phân tích lỗi (Defect analysis) [2]
Trong thực tế, lỗi là phần “luôn hiện diện” trong mọi phần mềm từ giai đoạn phát triển sơ

khởi đến khi nó không còn được sử dụng.
Các tổ chức phần mềm thường dùng thuật ngữ “chất lượng” để chỉ zero, hay một lượng
nhỏ các lỗi trên sản phẩm phần mềm, một số khác lại gắn liền khái niệm “chất lượng” với
sự hài lòng của khách hàng. Trên quan điểm khách hàng, bất kể lúc nào, hễ phần mềm
“chạy” không tốt, không đáp ứng sự mong đợi đều được xem là có lỗi, bất kể do code sai,
hoặc do hiểu nhầm yêu cầu, thậm chí là một chức năng “nên có” nhưng hiện thời chưa
sẵn sàng.
Phân tích lỗi được thực hiện trên tất cả lỗi được tìm thấy, nhằm mục đích tìm hiểu nguyên
nhân và xu hướng gây ra lỗi, định hướng cho việc sửa chữa các lỗi hiện hành cũng như
phòng ngừa, triệt tiêu khả năng xảy ra lỗi trong tương lai. Phân tích lỗi là con đường
chính yếu phục vụ cho việc giảm sự xuất hiện lỗi.
Phân tích lỗi không chỉ nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang xây
dựng, xa hơn nó cho ta thấy được những điểm yếu cần cải tiến của quy trình phát triển
PM. Thông tin về lỗi của các dự án trong quá khứ sẽ cho ta thấy được nên cải tiến, thay
Lập kế hoạch quản lí chất lượng phần mềm Trang 17
đổi quy trình phát triển PM như thế nào để các dự án trong tương lai tránh đi vào "vết xe
đổ” của các dự án trước.
Số liệu phục vụ cho việc phân tích lỗi có thể đến từ nhiều nguồn khác nhau. Mỗi tổ chức
tuỳ theo nhu cầu và đặc điểm riêng, tự định nghĩa và thu thập các số liệu này.
Lỗi trong quá trình phân tích và sửa chữa có thể được phân loại để có hành động phù
hợp, tuỳ theo các đặc tính khác nhau mà chúng thể hiện. Các đặc tính trong Bảng: “Các
thuộc tính của lỗi” thường được sử dụng trong nhiều hệ thống phân tích lỗi.
Phân loại Mô tả
Độ nghiêm
trọng
(Severity)
Ảnh hưởng của lỗi đối với PM đang được xây dựng, bao gồm các mức:
• Critical: Rất nghiêm trọng, có thể làm cho PM "chết cứng" và không
sử dụng được.
• Major: Nghiêm trọng, buộc phải sửa chữa để có thể sử dụng được như

yêu cầu đề ra.
• Minor: Nhẹ, tuy không làm PM ngưng chạy, nhưng làm cho việc sử
dụng PM khó khăn hoặc gây bất tiện cho người dùng
• Cosmetic: Không ảnh hưởng đến chức năng hay hiệu năng của PM
được quy định trong yêu cầu (như vấn đề thẩm mỹ hoặc thông báo sai
chính tả).
Độ ưu tiên
(Priority)
Độ ưu tiên sửa lỗi khi so sánh với các lỗi khác, bao gồm các mức:
• E = emergency; độ ưu tiên cao nhất, lỗi phải được sửa ngay, nếu
không công việc sẽ không thể tiếp tục.
• H = high, độ ưu tiên cao; công việc sẽ bị ngăn trở rất nhiều nếu như
lỗi vẫn chưa được sửa.
• M = medium, độ ưu tiên trung bình; công việc sẽ gặp vài khó khăn
nếu như lỗi vẫn chưa được sửa.
• L = low; độ ưu tiên thấp nhất; công việc không bị ảnh hưởng nhưng
lỗi vẫn phải được sửa.
Nguồn xuất
phát lỗi
(Source)
Thời điểm hoặc giai đoạn gây ra lỗi, ví dụ các chặng sau:
• R = requirements
• D = design
• C = code
Chặng phát
hiện lỗi
(Phase)
Thời điểm hoặc giai đoạn phát hiện lỗi, ví dụ các chặng sau:
• R = requirements
• D = design

• C = code
Loại lỗi
(Type of
defect)
Cho biết lỗi thuộc loại nào (nhằm thống kê và phân tích xu hướng của
lỗi)
Phương
pháp tìm lỗi
(Method)
Kỹ thuật dùng để tìm ra lỗi, ví dụ:
• I = inspection – khảo sát lỗi
• D = debugging or unit testing – dò lỗi hoặc kiểm tra mức đơn vị
Lập kế hoạch quản lí chất lượng phần mềm Trang 18
• T = testing – kiểm tra mức hệ thống
Bảng 1. Phân tích lỗi
5 Quản lý cấu hình (Configuration Management) [1]
Mục đích của quản lý cấu hình (QLCH) là để thiết lập và bảo đảm tính toàn vẹn của các
sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án PM, xuyên suốt chu
kỳ sống của dự án đó.
QLCH bao gồm nhiều hoạt động, tuy nhiên về cơ bản chúng bao gồm bốn hoạt động
chính: nhận dạng (identification), kiểm soát (control), kiểm kê báo cáo (accounting) và
kiểm tra đánh giá (audit). Tùy theo độ lớn và độ phức tạp của dự án, phạm vi và mức độ
áp dụng của các hoạt động QLCH sẽ khác nhau. Với những hệ thống lớn và phức tạp,
mỗi hoạt động QLCH phải do những người được giao trách nhiệm (role) cụ thể phụ
trách. Tùy yêu cầu, một số hoạt động QLCH được làm không chính thức (informal) hoặc
chính thức (formal), nhằm quản lý tốt quá trình phát triển của phần mềm, đặc biệt là quản
lý sự thay đổi trong dự án.
Hình 7. Quản lý cấu hình các hoạt động
6 Bảo mật (Security) [2]
Bảo mật luôn là vấn đề gây nhức nhối vì thường không được nhận thấy cho đến khi hệ

thống bị chọc thủng. Bảo mật có ba khía cạnh chính, bảo mật nội dung dữ liệu, bảo mật
dữ liệu đang được truyền (trên đường truyền) và bảo mật về mặt vật lý của vật chứa dữ
liệu. Các hoạt động bảo mật được áp dụng cho cả nội dung dữ liệu lẫn bản thân vật lý của
vật chứa dữ liệu.
Các yếu tố hay nguyên nhân tác động đến dữ liệu hoặc trung tâm dữ liệu của hệ thống
phần mềm rất đa dạng. Đó có thể là tự nhiên hoặc cố ý, chẳng hạn thiên tai, cháy, virus,
Lập kế hoạch quản lí chất lượng phần mềm Trang 19
hacker, phá hoại của chính nhân viên công ty, ăn cắp dữ liệu, thậm chí ngày nay còn do
các hoạt động khủng bố gây ra. Trong một số tổ chức, việc bảo mật dữ liệu lưu trữ và dữ
liệu chuyển dịch được xem là vấn đề sống còn.
Một lý do gây hỏng dữ liệu rất thường gặp là dữ liệu bị thay đổi một cách vô tình không
kiểm soát được. Một khi dữ liệu đã không đúng, điều tất yếu là hệ thống phần mềm sử
dụng dữ liệu đó sẽ cho ra những kết quả sai. Đối với người dùng, đó là một hệ thống
không tốt, thậm chí là không dùng được.
Một hệ thống phần mềm “tốt” phải chú ý tới tất cả những yếu tố có thể ảnh hưởng đến dữ
liệu hoặc hoạt động của hệ thống. Một hệ thống “tốt” còn phải tính đến khả năng phục
hồi dữ liệu, phục hồi hoạt động của hệ thống khi xảy ra sự cố.
7 Đào tạo, huấn luyện (Education/Training) [1]
Nói đơn giản, huấn luyện nhằm trang bị cho những người phát triển cũng như sử dụng
phần mềm có đủ kiến thức và kỹ năng để thực hiện công việc của họ.
Tất cả mọi biện pháp quản lý, kỹ thuật sản xuất, công cụ hỗ trợ trong sản xuất phần mềm
đều trở nên vô hiệu hoặc có hiệu quả hết sức hạn chế nếu những người tham gia phát
triển và sử dụng phần mềm không đủ kiến thức, kỹ năng cần thiết. Liên quan đến lý do
này, các tiêu chuẩn quản lý chất lượng như ISO, CMM/CMMi đều xác lập khả năng, kiến
thức và kỹ năng của những người phát triển phần mềm là một trong những yêu cầu cốt
yếu để bảo đảm các tiêu chí và mục tiêu về chất lượng.
Một khía cạnh khác thường được cho là ít quan trọng nhưng thực ra lại mang tính quyết
định, đó là khả năng hiểu để sử dụng phần mềm của người sử dụng. Người sử dụng
thường chỉ có ý tưởng về yêu cầu đối với phần mềm và không biết sử dụng hoặc sử dụng
không đúng cách làm phần mềm “chạy” sai hoặc không hết chức năng. Do vậy huấn

luyện cho người sử dụng cũng là một khâu hết sức cơ bản. Nhưng thực tế những người
phát triển phần mềm lại không có thời gian và kỹ năng thực hiện tốt việc huấn luyện, việc
này thường phải do một bộ phận chuyên trách trong công ty thực hiện.
8 Quản lý người cung cấp, thầu phụ (Vendor Management) [1]
Trong các tổ chức phần mềm, mua hay thuê sản phẩm hoặc dịch vụ từ một người cung
cấp thứ ba là rất phổ biến. Việc “mua” có thể bao gồm những mặt hàng đơn giản như máy
Lập kế hoạch quản lí chất lượng phần mềm Trang 20
tính, máy in, cho đến những dịch vụ thuê gia công phần mềm. Chất lượng của sản phẩm
và dịch vụ “mua” này nếu quản lý không tốt sẽ ảnh hưởng quan trọng đến sản phẩm hoặc
dịch vụ của tổ chức cung cấp cho khách hàng của mình.
Đối tượng sản phẩm hoặc dịch vụ cần mua hay thuê rất đa dạng, tùy mỗi loại và độ phức
tạp, các tổ chức sẽ có những biện pháp và mức độ quản lý chất lượng tương ứng.
9 Sự an toàn (Safety)[1]
10 Quản lý rủi ro (Risk Management) [1]
Rủi ro (risk) là một yếu tố tồn tại trong mọi dự án. Quan niệm về quản trị dự án cho rằng
“người quản trị dự án giỏi là người không ngạc nhiên về các sự kiện xảy ra trong dự án”,
điều này có nghĩa là mọi rủi ro tiềm ẩn phải được “nhìn thấy” trước, đi đôi với kế hoạch
giải quyết.
Rủi ro là một sự kiện chưa nhưng có khả năng xảy ra, và khi nó xảy ra thường sẽ đặt một
dự án vào tình huống xấu, hoặc thậm chí là một "tai nạn" cản trở khả năng hoàn thành
các mục tiêu của một dự án. Có nhiều loại cũng như cách xếp các loại rủi ro khác nhau,
tuy nhiên nhìn chung có các loại sau:
• Về kỹ thuật: Chủ yếu xoay quanh việc có hiểu đúng và đủ các yêu cầu đặt ra cho dự án
hay không, cũng như có giải pháp đúng để giải quyết chúng hay không. Việc hiểu sai
yêu cầu cũng như đưa ra giải pháp sai là nguyên nhân hàng đầu làm dự án thất bại.
• Về quản lý: Xoay quanh các vấn liên quan về mặt quản lý. Chúng cũng rất đa dạng,
gồm các loại rủi ro sau: kế hoạch, tài chính, con người, thay đổi yêu cầu
• Về thao tác-vận hành: Liên quan đến việc vận hành hệ thống, bao gồm:
− Huấn luyện cho người sử dụng không đầy đủ
− Sử dụng sai chức năng của sản phẩm, kể cả cố ý hoặc vô tình

− Bảo trì sản phẩm không đầy đủ
• Về môi trường: Bao gồm cả môi trường phát triển, kiểm tra lẫn sử dụng sản phẩm.
Những rủi ro từ bên ngoài, sự không tương thích, virus, …
• Về kiểm tra: Không đủ thời gian hoặc kiểm tra không đúng, không quét hết yêu cầu.
Quy trình cơ bản quản lý rủi ro gồm 4 bước:
− Nhận biết các rủi ro
− Khảo sát mức tác động nếu chúng xảy ra
− Xác định các giải pháp đối phó
− Giám sát các rủi ro và thực thi các giải pháp đối phó
Lập kế hoạch quản lí chất lượng phần mềm Trang 21
Có rất nhiều giải pháp khác nhau để đối phó hay giảm thiểu tác động của rủi ro. Trong
thực tế, các giải pháp thường gồm các loại:
−Loại bỏ: Khi chi phí loại bỏ rủi ro thấp, hoặc rủi ro nếu xảy ra sẽ gây ảnh hưởng cực kỳ
nghiêm trọng.
− Phòng tránh
−Giảm thiểu thiệt hại: Khi không thể phòng tránh hay loại bỏ rủi ro, ta có thể thực thi các
biện pháp để giảm thiểu khả năng xảy ra hoặc giảm thiểu chi phí khắc phục rủi ro nếu nó
xảy ra.
−Chấp nhận: Đành chấp nhận "sống chung với rủi ro" trong trường hợp chi phí loại bỏ,
phòng tránh, làm nhẹ rủi ro là quá lớn, hoặc mức độ tác hại của rủi ro nếu xảy ra là không
đáng kể, hoặc khả năng xảy ra của nó là cực thấp.
Hình 8. Biểu đồ khối thể hiện tầm quan trọng về mục tiêu chất lượng và
chu kỳ phát triển phần mềm, mỗi thành phần có liên hệ chặt chẽ với nhau
1.3. Lập kế hoạch Hệ thống quản lý chất lượng phần mềm [2]
Lập kế hoạch là yêu cầu kinh điển cũng như thao tác cơ bản của hầu hết các hệ thống
quản lý chất lượng phần mềm. Kết quả của hoạt động này thường là một (hoặc nhiều) tài
liệu gọi là bản kế hoạch.
Lập kế hoạch quản lí chất lượng phần mềm Trang 22
Theo quan điểm quản lý hiện đại, các công việc gắn liền với những mục tiêu, ngắn hạn
hoặc dài hạn, đều có thể xem như là một dự án hoặc chuỗi các dự án. Kế hoạch cho dự án

thường bao gồm những điểm chính sau:
• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm
• Xác định nhân lực, vật lực và chi phí
• Chỉ định phương pháp, cách tiếp cận để thực thi dự án
• Lập kế hoạch làm việc chi tiết
• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án
Đây là kế hoạch liên quan đến sự tham gia của những người có ảnh hưởng quan trọng
đến sự thành công hay thất bại của dự án (thuật ngữ chuyên môn gọi là stakeholders).
Những người này thường bao gồm: trưởng dự án, quản lý cấp cao, khách hàng, ban giám
đốc, thầu phụ, nhà cung cấp. Kế hoạch này phải bảo đảm cơ chế để các stakeholders có
thể tham gia vào dự án ở các mức độ và thời điểm mang lại hiệu quả cao nhất.
• Kế hoạch quản lý cấu hình và quản lý các rủi ro
• Các kế hoạch khác
Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc kỹ
thuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tích hợp sản
phẩm, kế hoạch huấn luyện
• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án
Lưu ý là các tài liệu kế hoạch của dự án không phải bất di bất dịch, nó phải được cập nhật
thậm chí thay đổi xuyên suốt dự án khi yêu cầu của dự án thay đổi.
2. Đánh giá hiện trạng chung: [2]
Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá là còn
yếu của các công ty phần mềm Việt Nam. Một số công ty trong nước hiện đã đạt các
chuẩn quốc tế CMM/CMMI trong nâng cao năng lực và quản lý chất lượng phần mềm,
song chỉ đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia công
cho thị trường nước ngoài.
Làm thế nào để một công ty này đạt được chuẩn quốc tế về chất lượng phần mềm? Mỗi
công ty đều có đặc thù riêng, tuy nhiên điều chung nhất là họ đều phải phát triển và duy
trì một Hệ thống quản lý chất lượng phần mềm.
Lập kế hoạch quản lí chất lượng phần mềm Trang 23
3. Đề xuất nội dung nghiên cứu:

Một HTQLCLPM không chỉ có quy trình, kiểm tra hoặc ra lệnh, nó là sự kết hợp gắn bó
của nhiều yếu tố. Mục tiêu sau cùng của HTQLCLPM là, dựa vào kết quả của các yếu tố
cấu thành, cung cấp thông tin làm đầu vào cho những quyết định đúng đắn về quản lý,
mang lợi ích về khi áp dụng các quy trình phát triển PM.
4. Nội dung thực hiện: [2]
• Ước lượng phạm vi và kích thước dự án, khối lượng công việc phải làm
• Xác định nhân lực, vật lực và chi phí
• Chỉ định phương pháp, cách tiếp cận để thực thi dự án
• Lập kế hoạch làm việc chi tiết
• Kế hoạch phối hợp và hỗ trợ hoàn thành dự án
• Kế hoạch quản lý cấu hình và quản lý các rủi ro
• Các kế hoạch khác
Tùy theo nhu cầu cho từng dự án, có thể có nhiều kế hoạch khác, cả về quản lý hoặc
kỹ thuật, một số kế hoạch thường gặp chẳng hạn: Kế hoạch kiểm tra, kế hoạch tích
hợp sản phẩm, kế hoạch huấn luyện
• Tài liệu hóa và cập nhật (khi cần) các bản kế hoạch cho dự án
Phần 2: PHƯƠNG PHÁP LẬP KẾ HOẠCH QUẢN LÝ CHẤT LƯỢNG[2]
1. Ước lượng phạm vi và kích thước dự án:[2]
1.1. Phạm vi và kích thước[2]
1.1.1. Tổng quan
− Phạm vi (Scope) là một danh sách tất cả những gì dự án phải làm (và cũng có thể là
một danh sách tất cả những điều mà dự án không phải làm). Dự án phải có một phạm
vi được viết ra rõ ràng, nếu không dự án sẽ không bao giờ kết thúc.
− Các kết quả chuyển giao (Deliverables) là những sản phẩm của dự án mà sẽ chuyển
giao: như là phần cứng, phần mềm (mua hoặc phát triển), bảo hành, tài liệu, đào tạo
và phương thức chuyển giao.
− Nhóm dự án và các bên liên quan (Stakeholders) phải cùng hiểu những sản phẩm nào
được tạo ra như là kết quả của dự án và chúng được tạo ra như thế nào.
1.1.2. Quy trình quản lý phạm vi [2]
− Khởi thảo: Bắt đầu một dự án hoặc chuyển tiếp sang giai đoạn tiếp theo.

Lập kế hoạch quản lí chất lượng phần mềm Trang 24
− Lập kế hoạch phạm vi: phát triển các tài liệu nhằm cung cấp nền tảng cho các quyết
định về dự án trong tương lai
− Xác định phạm vi: chia nhỏ các sản phẩm trung gian của dự án thành các thành phần
nhỏ hơn, dễ quản lý hơn
− Kiểm tra phạm vi: hợp thức hóa việc chấp nhận phạm vi của dự án
− Điều khiển thay đổi phạm vi: điều khiển những thay đổi của phạm vi dự án.
1.1.3. Lập kế hoạch phạm vi [2]
1.1.3.1. Thảo quy định phạm vi dự án [2]
Quy định phạm vi dùng để thử mức độ gay go cho mỗi yêu cầu thay đổi mà bạn nhận
được. Quy định phạm vi là chỉ dẫn duy nhất của bạn khi ai đó hỏi liệu điều gì sẽ xảy ra
và liệu lỗi đó có được sửa chữa hay không, liệu đặc tính đó có được xây dựng hay không,
liệu giao diện đó có thay đổi hay không hay liệu họ có được đào tạo hay không ?
Thảo quy định phạm vi là công việc khó khăn và buồn tẻ nhưng cần thiết. Quy định
phạm vi phải có tài liệu yêu cầu được nghiên cứu cẩn thận.
Nguyên tắc: Tập hợp thông tin phù hợp cho kết luận tuân theo các nguyên tắc sau:
− Đảm bảo rằng loại dự án và quy mô dự án được xác định rơ:
+ Xem xét việc sử dụng kế hoạch dự án tích hợp cho dự án thêm / chuyển / thay đổi và
các dự án vi mô.
+ Chuẩn bị cho quy định phạm vi phức tạp hơn và lớn hơn cho cá dự án vĩ mô.
− Đảm bảo rằng các phần có thể chuyển giao và ranh giới dự án được xác định rơ:
+ Tài liệu có xác định rơ cái sẽ được hoàn thành và không được hoàn thành như
mộtphần của dự án hay không?
+ . .Các yêu cầu bắt buộc và không bắt buộc có xác định rơ hay không? Các tiêu chí
chấp thuận cho các kết quả chuyển giao đă được phác thảo chưa?
+ Tài liệu có xác định rơ mỗi phần có thể chuyển giao nào sẽ bằng ngôn ngữ không
biệt ngữ hay không?
+ Bạn có biết khi nào dự án hoàn tất không?
+ Tính đến ngày tháng bắt đầu và ngày tháng hoàn tất theo mục tiêu trong đó có thời
đoạn tương đối với ngày tháng bắt đầu theo lư thuyết và / hoặc ngày tháng bắt đầu

/kết thúc.
+ Tính đến hậu quả của những ngày tháng bị trễ hạn theo toàn bộ dự án cũng như các
mốc quan trọng cụ thể.
− Đảm bảo rằng trách nhiệm được xác lập rơ:
+ Đảm bảo rằng tất cả các bên liên quan hiểu vai tṛ và trách nhiệm của họ trong dự án.
+ Cân nhắc việc sử dụng ma trận trách nhiệm.
Lập kế hoạch quản lí chất lượng phần mềm Trang 25