ôn tập công nghệ phần mềm nâng cao

Câu 1: Tiến trình phần mềm là gì? Vẽ sơ đồ bức tranh toàn cảnh và trình bày sơ lược. Giải thích các
pha hoạt động nền tảng.
-

-

Tiến trình phần mềm bao gồm 1 tập hợp các hoạt động được thực hiện bởi con người nhờ
vào:
o Vận dụng các phương pháp , tri thức kinh nghiệm.
o Sử dụng các công cụ hỗ trợ.
Bức tranh toàn cảnh: Coi đề cương
Các pha hoạt động nền tảng:
o Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải
được định nghĩa.
o Phân tích, thiết kế: phân tích, thiết kế dữ liệu, xử lý, giao diện
o Phát triển, xây dựng: xây dựng hệ thống
o Xác nhận phần mềm (kiểm thử): kiểm thử chức năng, kiểm lỗi hệ thống
o Bảo trì/ Tiến hoá phần mềm: hỗ trợ sửa lỗi, theo dõi thay đổi yêu cầu, nâng cấp.

Câu 2: Sự trưởng thành phần mềm là gì? So sánh tổ chức phần mềm chưa trưởng thành và tổ chức
phần mềm trưởng thành. Theo anh chị làm thế nào để nâng cao tính trưởng thành của các tồ chức /
công ty phần mềm?
-

-

-

Sự trưởng thành phần mềm là mức độ hay quy mô mà một tiến trình phần mềm:
o Được định nghĩ tường minh trong tổ chức sản xuất phần mềm
o Được vận hành nhờ vào sự

 Quản lý
 Kiểm soát
 Đánh giá định lượng
Tổ chức phần mềm chưa trưởng thành:
o Đặt nặng vai trò cá nhân: phụ thuộc vào sự tuỳ biến, linh động, “chữa cháy” của các
chuyên viên và nhà quản lý
o Tiến trình phần mềm (nếu có): không vận dụng nghiêm ngặt, không kiểm soát nghiêm
túc trong quá trình vận hành.
o Quản lý đề án: Không kiểm soát được tiến độ, không kiểm soát được kinh phí.
o Chất lượng sản phẩm:
 Không có các tiêu chí khách quan để đánh giá
 Xem nhẹ các hoạt động cải tiến chất lượng (việc duyệt lại hồ sơ phần mềm, thanh
tra sản phẩm, kiểm thử,…) bị rút ngắn thời gian hoặc bỏ hẳn khi đề án có khả
năng bị trễ hạn.
 Khách hàng không thể hình dung rõ về sản phẩm mãi đến khi nào được giao nộp.
Tổ chức phần mềm trưởng thành:
o Tiến trình phần mềm:
 Được mô tả tường minh bằng các văn bản, truyền đạt tới mọi thành viên tham gia
vào hoạt động sản xuất phần mềm


Phân định rõ ràng các vai trò và trách nhiệm của thành viên tham gia vào tiến
trình phần mềm.
 Được vận hành, kiểm soát định lượng, tuân thủ xuyên suốt trong quá trình sản
xuất phần mềm.
 Được tiến hoá để phù hợp với các thay đổi về môi trường công nghệ.
• Cập nhật, cải tiến tiến trình phần mềm trên cơ sở phân tích về lợi ích kinh
tế.
• Giảm sự phụ thuộc vào cá nhân, tận dụng sức mạnh đồng đội.
o Quản lý đề án:

 Chuẩn bị kỹ càng kế hoạch sản xuất
 Ước tính ngân sách và kiểm soát được chi phí
 Làm chủ thời gian và tiến độ thực hiện các đề án
o Chất lượng sản phẩm: đúc kết được các tiêu chi khách quan và định hướng.
 Để đánh giá được chất lượng sản phẩm
 Để phân tích các sự cố về sản phẩm
 Để đạt được các kết quả mong đợi về sản phẩm
Để nâng cao tính trưởng thành cần:
o Phát triển năng lực, kỹ thuật cá nhân
o Phát triển, áp dụng các phương pháp, kỹ thuật mới.
o Cải tổ môi trường công nghệ -> Chi phí tăng
o Sử dụng các chuẩn về chất lượng quy trình, chất lượng sản phẩm: ISO (các phiên bản),
PSP, CMMI,…
o Đáp ứng các chuẩn mực quốc tế
o Nâng cao quá trình phát triển phần mềm, tăng nhân lực
o Khó khăn về đào tạo con người -> Chi phí tăng


-

Câu 3: CMMI là gì? Những lợi ích mà CMMI mang lại cho ngành công nghiệp phần mềm?
-

-

CMMI- Mô hình trưởng thành năng lực tích hợp:
 Là một khung các giải pháp tối ưu cho quá trình sản xuất phần mềm.
 Không tập trung mô tả chính các quá trình mà chỉ mô tả đặc điểm của các quá trình hiệu
quả→ đưa ra các chỉ dẫn cho các công ty để họ có thể tự mình phát triển hoặc điều chỉnh
các quá trình của họ.

Lợi ích :
 Lợi ích chung:
o Nâng cao kiến thức và kỹ năng của lực lượng lao động
o Đảm bảo tính tổ chức, không riêng rẻ từng cá thể
o Duy trì tài sản con người, nguồn nhân lực chủ chốt của tổ chức
 Về mặt quản lý:
o Giảm thời gian, chi phí nhưng vẫn đạt chất lượng cao
o Gia tăng khả năng thành công của dự án
o Gia tăng sự hợp tác giữa các chức năng sản xuất


o Gia tăng khả năng theo dõi, điều khiển tổng hợp các dự án
Về mặt nhân sự:
o Trao đổi thông tin dễ dàng thông qua sử dụng thuật ngữ chung
o Nâng cao tinh thần đội ngũ lao động:
 Tạo môi trường làm việc ổn định
 Vạch rõ vai trò và trách nhiệm của từng vị trí công việc
 Đánh giá đúng năng lực, công nhận đúng thành tích
 Liên tục phát triển các kỹ năng→ cơ hội thăng tiến
 Về mặt kỹ thuật:
o Gia tăng sự tập trung và tính nhất quán trong công việc:
 Triển khai và quản lý nhu cầu của tổ chức và người sử dụng
 Thiết kế và triển khai hệ thống
 Tích hợp hệ thống
 Quản lý rủi ro
 Đo lường và phân tích


Câu 4: sự ra đời của CMMI? Trình bày sơ lượt 2 thể hiện chính của CMMI(khái niệm, đặc điểm, cấu
trúc)?

-

Khái niệm:
o Vào năm 1990, Viện công nghệ phần mềm(SEI) đại học Carnegie Mello công bố mô
hình CMM (Capability Maturity Model) – Mô hình trưởng thành năng lực.
o Mục đích: giúp các đơn vị sản xuất phần mềm có khả năng khắc phục được các nhược
điểm quan trọng trong quá trình sản xuất phần mềm như:
 Kém chất lượng
 Chậm trễ trong thực hiện dự án
 Lãng phí chi phí quá lớn
 Không thoả mãn yêu cầu khách hàng
 Kém khả năng dự báo và có nhiều rủi ro
o CMM được tạo ra thông qua việc phân tích hoạt động của các tổ chức sản xuất phần
mềm được quản lý tốt
o CMM bao gồm 316 nguyên tắc hoạt động, được nhóm lại thành 18 hạng mục khác nhau.
Các nguyên tắc này tập trung vào các mặt như:
 Quản lý yêu cầu
 Quản lý thay đổi
 Lập kế hoạch dự án theo dõi việc ước lượng so với thực tế
 Theo dõi các hoạt động nhằm đảm bảo chất lượng
 Tiến hành các cuộc thảo luận ngang hàng
 Huấn luyện nhân viên các kỹ thuật liên quan đến công việc của họ
o CMM chỉ tập trung chủ yếu vào góc độ phần mềm của dự án và nó không nhìn nhận
một cách toàn diện về một tổ chức


Mô hình CMM được phát triển thành nhiều phiên bản, tương ứng với các đặc thù cũa
từng công ty=> không thể hiện sự thống nhất và gây tốn kém
o Chuẩn CMMi là sự tổng hợp của các biến thể CMM, ra đời nhằm khắc phục các nhược
điểm của CMM, là một sự mở rộng về phạm vi của CMM (từ việc chỉ tập trung vào

phần mềm => quản lý đến mức tổ chức).
Staged Representation
o Khái niệm: Là phương pháp sử dụng một tập các định sẵn (predefined sets) của vùng
tiến trình (PA) nhằm định nghĩa một kịch bản cải tiến (improvement path) cho các tổ
chức. Ta gọi kịch bản cải tiến này là mức độ trưởng thành (Maturity Level).
o Đặc điểm:
 Cung cấp một chuỗi các cải tiến đã được chứng minh, cái trước làm nền tảng cho
cái tiếp theo.
 Sử dụng mức độ trưởng thành để mô tả cả tiến.
 Cung cấp một đánh giá tổng kết các kết quả thống kê và cho phép so sánh giữa
các tổ chức.
o Cấu trúc: Xem đề cương
Continuous Representation
o Khái niệm: là phương pháp cho phép một tổ chức lựa chọn một vùng tiến trình cụ thể
và cải tiến nó (nhiều hay ít).
o Đặc điểm:
 Cho phép lựa chọn thứ tự các cải tiến sao cho thích hợp nhất với mục tiêu kinh
doanh của tổ chức và làm giảm các rủi ro.
 Cho phép so sánh giữa các tổ chức dựa trên nền tảng PA-to-PA
 Sử dụng mức độ năng lực để mô tả việc cải tiến tiến trình.
o Cấu trúc: xem đề cương
o

-

-

Câu 5: Độ đo phần mềm là gì? Trình bày các phép đo cơ bản, cho ví dụ minh họa?
-

-

Tại sao phải đo:
o Để có cơ sở phân tích, đánh giá một các khách quan về một vấn đế hay một đối tượng
nào đó.
o Nghi nghờ, đặt giả thuyết, muốn tìm hiểu -> đo -> kết quả -> phân tích -> kết luận, dự
đoán,..
o Mỗi số đó: không phản ánh hết mọi khía cạnh của đối tượng (độ phức tạp của phần
mềm, của thuật toán,…)
 Cần phối hợp nhiều độ đo, vận dụng thêm các tiếp cận định tính (độ hài lòng của khách
hàng).
Các phép đo cơ bản:
o Đo dựa vào tỉ số: chia 1 đại lượng cho 1 đại lượng khác,tử số và mẫu số của tỉ số là số
phần tử của hai tập hợp rời nhau.




VD:

Ý nghĩa của tỉ số =
Thường có phạm vi từ 1:10 đến 1:1 phụ thuộc vào quy mô tổ chức tiến
trình phát triển phần mềm
• Với các tỉ số nhỏ: đội ngũ xây dựng phần mềm làm cả việc kiểm tra các
chức năng chi tiết, trong khi đội ngũ kiểm tra phần mềm thực hiện kiểm tra
ở mức độ hệ thống.
• Với các tỉ số lớn: đội ngũ kiểm tra phần mềm có trách nhiệm chính trong
pha kiểm tra phần mềm và đảm bảo chất lượng.
• Đề án phi thuyền con thoi: 70 nhân viên kiểm tra, 49 nhân viên phát triển
phần mềm, kết quả đo: ~ 7:5 .Lớn hơn nhiều so với các đề án thông

thường.
o Đo dựa vào tỉ lệ: tỉ lệ khác với tỉ số ở chỗ tử số tham gia vào một phần của mẫu số . Tỉ
số thường dung cho 2 nhóm người, trong khi tỉ lệ có thể dung cho nhiều phạm trù trong
một nhóm. Có thể nhiều hơn 2 phạm trù:
 VD:
Tỉ lệ =
• Dùng để khảo sát cho 1 phần mềm bất kỳ
• Độ đo này phụ thuộc vào quan niệm khách hàng
o Giá trị đo lớn: Phần mềm có chất lượng tốt
o Giá trị đo nhỏ: Phần mềm có chất lượng không tốt
 Có thể không phản ánh được “chất lượng bản chất” của phần mềm đang
khảo sát.
o Đo dựa vào tỉ lệ phần trăm (%): Tỉ lệ % có được bằng cách nhân tỉ lệ với 100
 VD: Xem đề cương
•

Câu 6: Sự cần thiết của độ đo kích thước(độ lớn) của phần mềm? trình bày các loại độ đo kích thước
phần mềm.?
-

Cần có đơn vị tính kích thước hay độ lớn của phần mềm để có thể:
o So sánh giữa các phần mềm với nhau
o Làm cơ sở để tính năng suất lao động trung bình.

o

Làm cơ sở để ước lượng một phần mềm:
“bằng cỡ bao nhiêu đơn vị phần mềm”

o

Làm cơ sở để quy ra tiền. Ví dụ: hiện trung bình cần 100 USD để sản xuất ra 1 đơn vị
phần mềm


Làm cơ sở để báo cáo. Ví dụ, năm 2013, công ty phần mềm PSV đã xuất khẩu tổng
cộng 453 đơn vị phần mềm.
Độ đo hướng kích thước
o Dựa trên số dòng mã nguồn
o Đơn vị tính: LOC/pm hay KLOC/pm
Kích thước =
LOC (Line of Code) hay SLOC
KLOC (Thousand lines of code) hay KSLOC
Thời gian thực hiện: quy về tháng (month)
Số người tham gia: person
Đơn vị pm: person X month
VD: đề cương
o Các vấn đề:
 Có thể nhiều chỉ thị/ lệnh nằm trên cùng một dòng -> để có LOC chính xác:
chuẩn hoá cách viết, dùng các công cụ hỗ trợ,…
 Phụ thuộc vào ngôn ngữ lập trình: khó so sánh năng suất giữa các đề án, giữa các
công ty có sử dụng ngôn ngữ lập trình khác nhau.
 Số dòng mã nguồn chỉ thực sự chính xác sau khi đã hoàn tất phần mềm -> phải có
phương pháp để ước tính LOC.
o Các phần mềm: Code Analyzer, LocMetrics hoặc VS2010 trở lên.
Độ đo hướng chức năng:
o Mục đích: có được con số đặc trưng cho hệ thống chức năng của mỗi phần mềm.
 Đơn vị tính là FP (Function Point), không phụ thuộc vào ngôn ngữ lập trình.
 Có thể ước lượng sớm độ lớn phần mềm (nhờ các thông tin từ phân tích yêu cầu,
thiết kế tổng thể,… của hệ thống).

 Làm cơ sở chung để tính năng suất, chi phí
 Ví dụ: Công ty ABC:
• Chi phí trung bình là 1150 USD/FP
• Mỗi nhân viên có năng suất lao động là 65FP/m (trung bình 65 đơn vị FP
được làm ra trong 1 tháng)
o Công thức:
o

-

-

Đo năng suất sản xuất phần mềm =
Câu 7: Độ đo PUM? Khuyết điểm của PUM? Các phương pháp làm giảm PUM? Phương pháp nào là
tích cực? hãy giải thích.
-

PUM – Problems per User Month
Công thức:
PUM =
VD: Triển khai 1 phần mềm cho 15 khách hàng trong 6 tháng, có 65 sự cố báo lại: = 0.72

-

Liên hệ giữa PUM và chất lượng


-

PUM giảm  Chất lượng tăng

Để PUM thấp, có thể chọn những phương án sau:
o Cải tiến quy trình phát triển phần mềm để giảm các lỗi thực sự.
o Giảm các lỗi giả (giải quyết tốt các vấn đề sử dụng, cải tiến tài liệu, huấn luyện khách
hàng, tăng cường các dịch vụ khách hàng,…)
 Giảm tử số PUM (tích cực)
o Gia tăng số bản bán được (đẩy mạnh việc bán hàng bằng các biện pháp khuyến mãi,
quảng cáo,…)
 Tăng mẫu số PUM (tiêu cực) vì khi các điều kiện thương mại có nhiều thuận lợi, số bản bán
được tăng nhanh sẽ làm giảm giá trị PUM, sẽ gây ra ngộ nhận là chúng ta đã giải quyết tốt
các vấn đề khách hàng, xem nhẹ việc giảm thiểu thực sự các vấn đề (giảm tử số PUM).

Câu 8: Thế nào là sản phẩm phần mểm đạt chất lượng? trình bày các tiêu chuẩn đảm bảo chất lượng
về sản phẩm và tiến trình phần mềm(nguồn gốc, đặc điểm, vai trò…)
-

-

-

-

Sản phẩm phần mểm đạt chất lượng khi:
o Đáp ứng được các yêu cầu kỹ thuật để ra
o Kiểm soát sữ liệu nhập và dự toán được các dữ liệu nhập không hợp lệ
o Đã được kiểm tra và thử nghiệm hoàn toàn bởi những người độc lập
o Có tài liệu hướng dẫn cụ thể rõ ràng
o Nhận biết được tỉ lệ lỗi
Các tiêu chuẩn đảm bảo chất lượng:
o Các kinh nghiệm hoặc các phương pháp hiệu quả nhất, được đề xuất từ các tổ chức IEEE,
ISO,…

o Các quy tắc chuẩn hóa để giao tiếp giữa các sản phẩm với nhau
o Có thể do chính tổ chức phát triển PM đề ra
Đặc điểm của các tiêu chuẩn:
o Tính cần thiết
o Tính khả thi
o Tính đo lường
Các tiêu chuẩn sản phẩm: định nghĩa các đặc tính chung cần được thể hiện.
Các tiêu chuẩn về tiến trình: định nghĩa các thực hiện các tiến trình.
Vai trò của tiêu chuẩn:
o Là chìa khóa tăng hiệu quả quản lý chất lượng
o Tóm lượt được các hoạt động tốt nhất, tránh lặp lại các sai lầm đã qua
o Đảm bảo chất lượng có đúng theo chuẩn đã đưa ra
o Cung cấp nội dung về tiêu chuẩn một cách liên tục để nhân viên mới có thể hiểu và áp dụng

Câu 9: Quản lý cấu hình phần mềm là gì? Nêu và giải thích tại sao cần quản lý cấu hình trong xây
dựng phần mềm?
-

Quản lý cấu hình phần mềm (Software configuration management – SCM)
o Là tiến trình kiểm soát, theo vết các thay đổi của một hệ thống phần mềm


-

-

o Được dùng để quản lý các phiên bản khác nhau của các phần mềm đó
Lý do cần quản lý cấu hình:
o Phần mềm chạy trên nhiều họ máy tính khác nhau
o Phần mềm chạy trên nhiều hệ điều hành khác nhau

o Gồm các chức năng được phát triển cho một nhóm khách cụ thể
o Sử dụng đa ngôn ngữ
o Cần phải sử dụng cây quản lý cấu hình phần mềm
 Chức năng cây quản lý cấu hình:
• Theo dõi và quản lý sự khác nhau giữa các phiên bản
• Đảm bảo các phiên bản mới được bắt ngồn (kế thừa) từ phiên bản gốc trong
một tiến trình được kiểm soát (không được tuỳ tiện, tự phát)
• Đảm bảo các phiên bản mới được giao đến đúng khách hàng và đúng thời gian
quy định.
Các hoạt động trong tiến trình quản lý cấu hình.
o Hoạch định quản lý cấu hình
o Quản lý sự thay đổi phần mềm
o Quản lý phiên bản của phần mềm
o Xây dựng phần mềm từ các thành tố
o Lưu ý:
 Tiến trình quản lý cấu hình chỉ thực sự chạy sau khi một phiên bản đầu của hệ thống
được phát triển.
 Tuy nhiên, một số đề xuất hoạch định tiến trình nên bắt đầu ngay khi khởi động đề án
và hoạt động suốt thời gian phát triển hệ thống.

Câu 10: Tiến trình quản lý thay đổi phần mềm gồm những hoạt động nào? Mô tả thuật toán tiến trình
quản lý thay đổi?
-

-

Tiến trình quản lý sự thay đổi phần mềm bao gồm:
o Phân tích sự đánh giá về mặt kỹ thuật
o Đánh giá chi phí
o Theo dõi “vết” của thay đổi.

Thuật toán tiến trình quản lý thay đổi:

Yêu cầu thay đổi bằng cách điền vào “mẫu yêu cầu thay đổi”
Phân tích các yêu cầu thay đổi
Nếu <thay đổi hợp lý> thì
{
Đánh giá sơ bộ cách thức cài đặt các thay đổi
Ước lượng phí tổn
Ghi nhận các yêu cầu thay đổi vào CSDL
Đệ trình yêu cầu thay đổi tới Bộ phận kiểm soát thay đổi
Nếu thay đổi được chấp nhận thì


{
Lặp lại
{
Tiến hành phần mềm thay đổi theo yêu cầu
Ghi nhận thay đổi, liên kết với yêu cầu thay đổi
Đệ trình phần mềm để phê chuẩn chất lượng
} đến khi (chất lượng phần mềm có thể chấp nhận)
Tạo phiên bản mới
}
Ngược lại
Bác bỏ yêu cầu thay đổi
}
Ngược lại
Bác bỏ yêu cầu thay đổi
Câu 11: Quản lý phiên bản là gì? Trình bày và cho ví dụ về các phương pháp định danh phiên bản?
-

-

-

Quản lý phiên bản là tiến trình định nghĩa, theo dõi và kiểm soát các phiên bản khác nhau nhau
của một hệ thống phần mềm.
Phiên bản (version): là một thể hiện của phần mềm mà có sự thay đổi so với các thể hiện khác
của phần mềm đó.
o Thay đổi có thể bao gồm: chức năng mới, cải tiến hiệu năng, sửa đổi lỗi của phiên bản cũ…
Một số phiên bản có thể tương đương hoàn toàn về mặt chức năng nhưng được thiết kế để
hoạt động cho các cấu hình phần mềm hay phần cứng khác nhau.
Phiên bản phát hành (realease): là một phiên bản được phân phối đến khách hàng. Số lượng
phiên bản của một hệ thống phần mềm nhiều hơn số lượng phiên bản phát hành hệ thống đó.
o Cấu trúc tổng quát của một phiên bản phát hành bao gồm:
 Các chương trình thực thi hay một tập hợp các chương trình.
 Các tập tin cấu hình để xác định cách thức, nghi thức cài đặt cho từng môi trường cụ
thể.
 Các tập tin dữ liệu cần cho sự hoạt động hệ thống
 Một chương trình cài đặt dùng để cài đặt hệ thống phần mềm
 Các tài liệu (giấy/ văn bản điện tử) liên quan đến hệ thống phần mềm (VD: file
ReadMe).
Có 3 phương pháp định danh phiên bản chính:
o Sơ đồ tuyến tính: sơ đồ này giả sử sự tiến hoá của hệ thống phần mềm diễn ra tuần tự,
phiên bản sau tương thích với phiên bản trước:
 Phiên bản đầu tiên: 1.0
 Các phiên bản cơ sở là: 1.0, 2.0, 3.0,…
 Các phiên bản khác bắt nguồn từ phiên bản cơ sở, như: 2.1, 2.1.1, 3.0.1,….
 Khó khăn:

Nếu nhiều phiên bản bắt nguồn từ phiên bản cha thì đánh số phiên bản như thế
nào?
• Nếu nhiều phiên bản của hệ thống được tạo ra và phân phối đến nhiều khách
hàng khác nhau, mỗi khách hàng có một phiên bản duy nhất thì định danh thế
nào.
o Sơ đồ định danh theo dạng mạng: Xem đề cương
o Sơ đồ định danh theo tên:
 VD: V1/VMS/DB server -> là phiên bản của DB server chạy trên hệ điều hành VMS
Lưu ý chung về việc định danh phiên bản:
o Các phương pháp định danh phiên bản đều không phản ánh hết các thuộc tính liên quan đến
mỗi phiên bản phần mềm. Các thuộc tính nên được lưu trong CSDL quản lý cấu hình và bao
gồm ít nhất các thông tin sau:
 Khách hàng
 Ngôn ngữ dùng để phát triển
 Tình trạng phát triển
 Cấu hình phần cứng
 Hệ điều hành
 Ngày tạo phiên bản.
•

-

Bổ sung: chương 4 quản lý chất lượng
Quản lý chất lượng
-

-

Quản lý chất lượng (software quality management): tiến trình liên quan đến việc bảo đảm các
yêu cầu về cấp độ chất lượng (level of quality) của sản phẩm phần mềm.

Quản lý chất lượng bao gồm định nghĩa những tiêu chuẩn chất lượng và các thủ tục thích hợp đồng
thời, bảo đảm việc phát triển phần mềm theo đúng tiêu chuẩn đó.
Đối với bất kỳ 1 tổ chức phần mềm nào thì hoạt động xây dựng mục tiêu chất lượng của sản phẩm
là trách nhiệm của mọi thành viên (quality culture)
Các tính chất cơ bản của chất lượng phần mềm
o An toàn
o Mạnh mẽ trước tấn công
o Dễ kiểm tra
o Ổn định
o Hiệu quả cao
o Bảo mật
o Dễ hiểu
o Tương thích cao
o Linh động
o Dễ học
o Tái sử dụng
Mục tiêu của quản lý chất lượng phần mềm


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 từ mọi nguồn khác nhau 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.
o Bảo đảm chất lượng của phần mềm xuyên suốt quá trình phát triển.
Các hoạt động quản lý chất lượng:
o Đảm bảo chất lượng (Quality Assurance – QA): Thiết lập các thủ tục để tổ chức các tiêu
chuẩn về chất lượng.
o Lập kế hoạch chất lượng (Quality Planning – QP): Lựa chọn những thủ tục có thể áp dụng
và các tiêu chuẩn cho một dự án cụ thể và có thể sửa đổi chúng khi cần.
o Kiểm soát chất lượng (Quality Control - QC): Đảm bảo các thủ tục và tiêu chuẩn được thực
hiện nghiêm túc bởi đội ngũ phát triển phần mềm.

o Chú ý: Quản lý chất lượng cần được tách rời khỏi nhóm phát triển dự án -> Bộ phận độc
lập.
o

-

Tiến trình đo phần mềm:
-

Tiến trình đo phần mềm là tiến trình con của tiến trình kiểm soát chất lượng
Dữ liệu thu thập trong toàn bộ tiến trình con này cần được lưu trữ như tài nguyên
Cơ sở dữ liệu đo được sẽ làm cơ sở để so sánh với các dự án khác.

Độ đo sản phẩm:
-

Tiến trình đo chất lượng là cơ sở để xác định chất lượng sản phẩm phần mềm
Phân loại độ đo sản phẩm:
o Dynamic metrics: liên quan trực tiếp đến thuộc tính chất lượng, dữ liệu đo được tạo ra trong
quá trình thực thi chương trình (thời gian đápn ứng, số lượng lỗi,..) -> dùng đánh giá tính
hiệu quả và tin cậy.
o Static metrics: liên quan gián tiếp đến thuộc tính chất lượng, dữ liệu đo được trong quá trình
biểu diễn hệ thống phần mềm (số dòng mã lệnh) -> dùng để đánh giá tính phức tạp, tính dễ
hiểu và khả năng bảo trì.

Bổ sung: chương 1: Tiến trình thanh tra mã nguồn
-

Tiến trình dò tìm lỗi trong mã nguồn sau khi đã hết lỗi biên dịch (trước khi dịch thành mã thực thi
để chạy và kiểm thử)

Các hoạt động:
o Prepating for Inspectation: Source codes (hardcopies, files) được cung cấp cho mỗi lần
thanh tra.
o Inspection Overview: họp nhanh để giải thích cách bố trí các đoạn mã
o Individual Inspection: Mỗi thanh tra cố gắng phát hiện tất cả các lỗi (defects) trong
chương trình.
o Meeting: Để quyết định các khuyết điểm nào cần phải được báo cáo.
 Tất cả các thanh tra phải tham dự buổi họp này
 Moderator (người nhiều kinh nghiệm trong lập trình)


Rework: Danh sách các lỗi sẽ được đưa ra để tác giả của nó sửa đổi và cải tiến mã nguồn.
Follow up: Sự đúng đắn của giai đoạn rework sẽ được kiểm tra lại trong một buổi họp tổng
kết hoặc những lần thanh tra sau này cho đến khi kết thúc dự án.
o Record keeping: thông tin về sản phẩm, trách nhiệm của các thành viên trong dự án.
Các vai trò:
o Code author: viết code, sửa chữa những lỗi phát hiện được.
o Inspector: tìm lỗi do bỏ sót, không nhất quán trong chương trình.
o Reader: diễn giải các đoạn mã trong cuộc họp thanh tra
o Scribe: ghi lại kết quả cuộc họp
o Moderator: quản lý quy trình và tiện ích việc thanh tra, báo cáo kết quả xử lý đến chief
moderator.
o Chief moderator: chịu trách nhiệm cải tiến tiến trình thanh tra, cập nhật danh sách kiểm
tra, phát hiện các chuẩn
Tools: Code viewers, Code Analysers, File Managers, Workflow Tools,…
Những điểm đáng ghi nhận:
o Tìm được hơn 60% lỗi nếu dùng các phương pháp không hình thức
o Tìm được hơn 90% lỗi nếu vận dụng thêm các phương pháp hình thức, phương pháp toán
học.
o Khảo sát từ 1 đề án lớn (1980): giá phải trả để sửa chữa, khắc phục 1 lỗi phát hiện khi:

 Thanh tra sản phẩm là 1 USD
 Kiểm thử là 13 USD
 Sau khi phát hành là 95 USD
o Mã nguồn đáp ứng các thuộc tính chất lượng (chuẩn mã hoá, tương thích, dễ bảo trì,…).
o
o

-

-

PHẦN BÀI TẬP: đề này tự chế nha, chủ yếu là cách làm thôi
VD: Một công ty có hiệu suất sản xuất là 14FP/PM, chi phí để trả cho 1 người là 500USD, ước lượng chi
phí quy ra tiền USD, quy ra PM
Ci
5
6
7
8
9

Wi
3
4
4
10
7

F1 -> F5: 1
F6 -> F10: 3

F11 -> F14 : 4

Chi phí mỗi FP = = = 35.7 (USD)
Số lượng FP =  X (0.65 + 0.01 X )
= X (0.65 + 0.01 X )


= (5*3 + 6*4 + …. 9*7) X (0.65 + 0.01 X (1+1+1+1+1+3+3+3+3+3+4+4+4+4))
= 210 X (0.65 + 0.01 X (5+15+16))=212.1 (FP)
Chi phí quy ra tiền USD = số lượng FP X chi phí mỗi FP
= 212.1 X 35.7 = 7571.97 (USD)
Quy ra đơn vị PM = = = 15.15