NGÂN HÀNG CÂU HỎI THI
ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM
1
NGÂN HÀNG CÂU HỎI THI TỰ LUẬN
Tên học phần: Đảm bảo chất lượng phần mềm Mã học phần: INT 416
Ngành đào tạo: Trình độ đào tạo:
Màu xám: bỏ qua
Màu đỏ: bắt buộc
Còn lại: cần học
1. Ngân hàng câu hỏi thi
Câu hỏi loại 1 điểm
Câu hỏi 1.1: Lỗi phần mềm là gì? Nguyên nhân gây ra lỗi phần mềm?
Lỗi phần mềm - Software Error : Là các phần code sai do lôi cú pháp, logic hoăc lôi do phân
tích, thiết kế.
Câu hỏi 1.2: Cơ sở để kiểm định chất lượng phần mềm?
Câu hỏi 1.3: Đảm bảo phần mềm xuất phát từ đâu? Tiến triển của nó như
thế nào?
Câu hỏi 1.4: Kể ra các độ đo đặc trưng chất lượng chính của McCall? Giải
thích nội dung của nó?
McCall đề xuất 22 độ đo sau:
(1) Độ kiểm toán được: có thể kiểm tra dễ dàng về việc tuân thủ các chuẩn
(2) Độ chính xác: Độ chính xác của tính toán và điều khiển
(3) Độ tương đồng giao tiếp: mức độ sử dụng các giao diện, giao thức và giải thông chuẩn.
(4) Độ đầy đủ: mức độ theo đó các việc cài đặt đầy đủ cho các chức năng yêu cầu đã được đạt tới.
(5) Độ phức tạp: tránh dùng chương trình có độ phức tạp cao
(6) Độ súc tích (conciseness): độ gọn của chương trình dưới dạng số dòng mã.
(7) Độ hoà hợp (consistancy): việc dùng kỹ thuật thiết kế và tư liệu thống nhất trong toàn bộ
chương trình.
(8) Độ tương đồng dữ liệu: việc dùng các cấu trúc và kiểu dữ liệu chuẩn trong toàn bộ chương trình
(9) Độ dung thứ lỗi: những hỏng hóc xuất hiện khi chương trình gặp phải một lỗi được chấp nhận.
(10) Độ hiệu qủa thực hiện: hiệu năng khi chạy của chương trình
(11) Độ khuếch trương được:Mức độ theo đó thiết kế kiến trúc, dữ liệu hay thủ tục có thể được mở
rộng.
(12) Độ khái quát: độ rộng rãi của ứng dụng tiềm năng của các thành phần chương trình.
(13) Độ độc lập phần cứng: mức độ theo đó phần mềm tách biệt được với phần cứng mà nó vận
hành.
(14) Trang bị đồ nghề đủ (instrumentation):mức độ theo đó chương trình điều phối thao tác của
riêng nó và xác định các lỗi xuất hiện
(15) Độ đo mođun hoá: sự độc lập chức năng của các thành phần trong chương trình
2
(16) Độ dễ thao tác: Việc dễ vận hành trong chương trình
(17) Độ an ninh: có sẵn cơ chế kiển soát hay bảo vệ chương trình và dữ liệu.
(18) Độ tự tạo tài liệu (self-doccumentation): mức độ theo đó mã gốc cung cấp tài liệu có ý nghĩa.
(19) Độ đơn giản - dễ hiểu: mức độ theo đó người ta có thể hiểu được chương trình không khó
khăn.
(20) Độ độc lập hệ thống phần mềm: mức độ theo đó chương trình được độc lập với các tính năng
ngôn ngữ lập trình, các đặc trưng hệ điều hành và những ràng buộc môi trường không chuẩn khác.
(21) Độ lần vết được: khả năng theo dõi các dấu vết của một biểu diễn thiết kế hay thành phần của
chương trình thực hiện so với yêu cầu
(22) Độ đo khả năng huấn luyện: Mức độ theo đó phần mềm trợ giúp làm cho người dùng mới
dùng được hệ thống.
Câu hỏi 1.5: Nêu các đặc trưng chất lượng theo Hawlett? Giải thích nội
dung mỗi loại?
Câu hỏi 1.6: Trình bày kỹ thuật Walkthrough
Câu hỏi 1.7: Trình bày kỹ thuật Inspection
Câu hỏi 1.8: Trình bày tóm tắt SQA trong tiêu chuẩn ISO 9000-3
Câu hỏi 1.9: Trình bày các đặc tính chất lượng ISO 9126.
Câu hỏi 1.10: Trình bày tóm tắt SQA trong tiêu chuẩn IEEE std1028
Chất lượng phần mềm là:
(1) Mức độ mà một hệ thống, thành phần, hay tiến trình đáp ứng được đặc tả yêu cầu _by
Philip Crosby
(2) Mức độ mà một hệ thống, thành phần, hay tiến trình đáp ứng được nhu cầu/mong muốn
của khách hàng/người dùng. _ by Joseph M. Juran
Lập kế hoạch và cài đặt một cach hệ thống!
chỉ ra tiến độ và và truyền tải sự tin cậy của phần mềm đang phat triển
Với tiến trình phat triển phần mềm
một phương pháp luận; một cách thức để làm;
Với đặc tả yêu cầu kỹ thuật phải có.
SQA bao gồm cả tiến trình phat triển và có thể cả bảo trì dài hạn. Do vậy, ta cần xem xét vấn đề về
chất lượng cho cả phat triển và bảo trì trong SQA
Hành động SQA phải bao gồm cả lập lịch và lập ngân sach.
SQA phải chỉ ra cac vấn đề nảy sinh khi không đap ứng được ràng buộc thời gian– bỏ bớt chức
năng? Ràng buộc ngân sach có thể thoả hiệp được khi nguồn lực được phân bổ bị là không đủ cho
phat triển và/hoặc bảo trì.
Câu hỏi 1.11: Trình bày các mức tiêu chuẩn trong CMM?
CMMI viết tắt cho Capability Maturity Model Integration - Mô hình trưởng thành năng lực tích hợp
- và là khuôn khổ cho cải tiến qui trình phần mềm. Nó dựa trên khái niệm về các thực hành tốt nhất
về kĩ nghệ phần mềm và giải thích kỉ luật mà các công ty có thể dùng để cải tiến các qui trình của họ
CMM bao gồm 5 levels và 18 KPAs (Vùng quy trình quan trọng - Key Process Area).
Nói cách khác mỗi một level đều tuân theo một chuẩn ở mức độ cao hơn. Muốn đạt được chuẩn cao
hơn thì các chuẩn của các level trước phải thoả mãn. Mỗi level đều có đặc điểm chú ý quan trọng
của nó cần các doanh nghiệp phải đáp ứng được.
3
Level 1 thì không có KPAs nào cả
Level 2 : có 6 KPAs
Level 3: có 7 KPAs
Level 4: có 2 KPAs
Level 5: có 3 KPAs
18 KPAs của CMM được đều có 5 thuộc tính(chức năng) chung trong đó có các qui định về
key pratice là những hướng dẫn về các thủ tục(procedure), qui tắc(polities), và hoạt động
(activites)của từng KPA.
Mô hình này xác định năm cấp độ của CMM đối với một công ty : Khởi đầu (lộn xộn, không
theo chuẩn) - Lặp (quản lý dự án, tuân thủ quy trình) - Xác lập (thể chế hóa) - Kiểm soát (định
lượng) - Tối ưu (cải tiến quy trình).
Level 1
Level 1 là bước khởi đầu của CMM, mọi doanh nghiệp, công ty phần mềm, cá nhóm, cá
nhân đều có thể đạt được. Ở lever này CMM chưa yêu cầu bất kỳ tính năng nào. Ví dụ: không yêu
cầu quy trình, không yêu cầu con người, miễn là cá nhân, nhóm, doanh nghiệp… đều làm về phầm
mềm đều có thể đạt tới CMM này.
Level 2
Có 6 KPA nó bao gồm như sau:
- Requirement Management (Lấy yêu cầu khách hàng, quản lý các yêu cầu đó)
- Software Project Planning (Lập các kế hoạch cho dự án)
- Software Project Tracking (Theo dõi kiểm tra tiến độ dự án)
- Software SubContract Managent (Quản trị hợp đồng phụ phần mềm)
- Software Quality Assurance (Đảm bảo chất lượng sản phẩm)
- Software Configuration Management (Quản trị cấu hình sản phẩm => đúng yêu cầu của
khách hàng không)
Level 3
4
Các vùng tiến trình chủ chốt ở mức 3 nhằm vào cả hai vấn đề về dự án và tổ chức, vì một tổ
chức (công ty) tạo nên cấu trúc hạ tầng thể chế các quá trình quản lý và sản xuất phần mềm hiệu quả
qua tất cả các dự án. Chúng gồm có Tập trung Tiến trình Tổ chức (Organization Process Focus),
Phân định Tiến trình Tổ chức (Organization Process Definition), Chương trình Đào tạo (Training
Program), Quản trị Phần mềm Tích hợp (Integrated Software Management), Sản xuất Sản phẩm
Phần mềm (Software Product Engineering), Phối hợp nhóm (Intergroup Coordination), và Xét duyệt
ngang hàng (Peer Reviews).
Level 4
Các vùng tiến trình chủ yếu ở mức 4 tập trung vào thiết lập hiểu biết định lượng của cả quá
trình sản xuất phần mềm và các sản phẩm phần mềm đang được xây dựng. Đó là Quản lý quá trình
định lượng (Quantitative Process Management) và Quản lý chất lượng phần mềm (Software Quality
Management).
Lực lượng lao động làm việc theo đội, nhóm và được quản lý một cách định lượng.
Level 5
Các vùng tiến trình chủ yếu ở mức 5 bao trùm các vấn mà cả tổ chức và dự án phải nhắm tới để
thực hiện hoàn thiện quá trình sản xuất phần mềm liên tục, đo đếm được. Đó là Phòng ngừa lỗi
(Defect Prevention), Quản trị thay đổi công nghệ (Technology Change Management), và Quản trị
thay đổi quá trình (Process Change Management) Để đạt được level 4 thì phải đo lường và chuẩn
hóa. Đo lường hiệu quả đáp ứng công việc, chuẩn hóac phát triển các kỹ năng, năng lực cốt lõi.
Câu hỏi 1.12: Mục tiêu của SQA là gì? Các hoạt động chính đảm bảo chất
lượng phần mềm là những hoạt động nào?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần mềm có chất
lượng cao.
• Có 7 hoạt động chính:
(1) Áp dụng công nghệ kĩ thuật hiệu quả (phương pháp, công cụ)
(2) Tiến hành rà soát kỹ thuật chính thức
(3) Thực hiện kiểm thử nhiều tầng
(4) Tuân theo các chuẩn phát triển
(5) Kiểm soát tài liệu Fm và thay đổi của chúng
(6) Thực hiện đo lường
(7) Báo cáo và bảo quản lý các báo cáo.
Câu hỏi 1.13: Khảo sát nhu cầu SQA gồm những nội dung gì? Nhằm trả lời
các câu hỏi gì?
- Gồm ba nội dung nhằm trả lời ba câu hỏi
+ Kiểm kê các chính sách SQA: chính sách, thủ tục, chuẩn nào đã có trong các pha phát
triển?
+ Đánh giá vai trò của kỹ nghệ phần mềm, bảo đảm chất lượng trong tổ chức hiện tại có
quyền lực đến đâu?
+ Đánh giá mối quan hệ SQA: Giao diện chức năng giữa SQA với các đơn vị khác như thế
nào? Với các người thực hiện rà soát kỹ thuật chính thức, quản lý cấu hình và thử nghiệm.
Một khi ba câu hỏi trên đã được trả lời thì mức độ mạnh hay yếu đã được minh bạch.
- Nếu có nhu cầu SQA thì cần phải tiến hành đánh giá cẩn thận bằng quy tắc bỏ phiếu.
