Giải đề thi kiểm thử phần mềm môn Đảm bảo chất lượng phần mềm | Học viện Công Nghệ Bưu Chính Viễn Thông

lOMoAR cPSD| 58457166 Câu 1 (2 điểm)
Ý nghĩa của các mô hình McCall, ISO9126, ISO 25010 trong việc quản lý yêu cầu của phân mềm là gì ? Câu 2 (3 điểm)
Trực quan hóa sản phẩm phần mềm bằng mẫu thứ (prototype) có những lợi ích gì trong tiến trinh cam kết, tại sao ? Câu 3 (3 điểm)
Những tiêu chí gì dùng để so sánh chất lượng của các mô hình phát triễn phần mềm ? Câu 4 (2 điểm)
Dùng phương pháp gieo lỗi để giới hạn số trường hợp kiểm thừ PM như thế nào ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Câu 1 (2đ) Theo cách tiếp cận hệ thống, việc khám phá yêu cầu (requirements elicitation) được thực
hiện như thế nào ?
Câu 2 (2đ) Môi trường nghiệp vụ (business environment) của phần mềm là gì, vì sao yêu cầu
làm phần mềm phải được xem xét chọn lọc từ môi trường này ?
Câu 3 (2đ) Hãy giải thích nguyên nhân phát sinh yêu cầu đối với phần mềm theo cách tiếp cận hệ thong.
Câu 4 (2đ) Hãy trình bày nguyên lý Paretto (luật 20/80), và cách áp dụng nguyên lý này vào việc
kiểm thử phần mềm.
Câu 5 (2đ) Hãy giải thích 4 yêu cầu cơ bản của SW Evolution (maitenance) và cách tìm hiếu chi
tiết về mỗi yêu cầu này.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Câu 1 (2 điểm)
Nguyên nhân gi đưa đến mô hình chất lượng phần mềm như ISO25010 ? Câu 2 (2 điểm)
Hay cho biết 2 ưu điểm nổi bật của mô hinh UP/RUP so với mõ hình xoắn ốc trong tiến trình làm phần mềm Câu 3 (2 điểm)
Môi trường nghiệp vụ của phần mềm là gì ? Phần mềm ảnh hưởng thế nào đến môi trường này ? Câu 4 (2 điểm)
Vì sao mô hình làm mẫu thử không được xem là mô hình tiến hóa ? lOMoAR cPSD| 58457166 Câu 5 (2 điểm)
White-box test trợ giúp dược gì cho verification ? TRẢ LỜI Câu 1 (2 điểm)
Ý nghĩa của các mô hình McCall, ISO9126, ISO 25010 trong việc quản lý yêu cầu của phân mềm là gì ?
McCall phân chia chất lượng phần mềm thành ba khía cạnh chính:
• Khả năng vận hành: bao gồm các yếu tố như đúng giờ, độ tin cậy,hiệu suất, toàn vẹn, tính hữu dụng
• Khả năng chuyển đổi: bao gồm khả năng bảo trì, tính linh hoạt, khả năng kiểm tra
• Khả năng thích ứng: bao gồm khả năng chuyển đổi, tính tái sử dụng, tính tương thích
ISO 9126 là một tiêu chuẩn quốc tế về chất lượng phần mềm, cung cấp một mô hình phân cấp với
sáu thuộc tính chất lượng chính:
• Chức năng (Functionality): Bao gồm tính phù hợp (suitability), tính chính xác
(accuracy), tính tương tác (interoperability), bảo mật (security), và tính tuân thủ (compliance).
• Độ tin cậy (Reliability): Bao gồm tính trưởng thành (maturity), khả năng chịu lỗi (fault
tolerance), và tính phục hồi (recoverability).
• Khả năng sử dụng (Usability): Bao gồm khả năng hiểu biết (understandability), khả
năng học hỏi (learnability), và tính vận hành (operability).
• Hiệu quả (Efficiency): Bao gồm tính hiệu quả thời gian (time behavior) và hiệu quả tài
nguyên (resource utilization).
• Khả năng bảo trì (Maintainability): Bao gồm tính phân tích (analyzability), tính thay đổi
(changeability), tính ổn định (stability), và khả năng kiểm tra (testability).
• Khả năng chuyển đổi (Portability): Bao gồm tính thích ứng (adaptability), khả năng cài
đặt (installability), tính đồng dạng (conformance), và khả năng thay thế (replaceability).
ISO 25010 là phiên bản nâng cấp của ISO 9126, mở rộng và cập nhật các thuộc tính chất lượng
phần mềm để phản ánh sự tiến bộ trong công nghệ và yêu cầu mới của phần mềm hiện đại. ISO
25010 phân chia chất lượng phần mềm thành tám thuộc tính chính:
• Chức năng (Functional Suitability): Bao gồm tính đầy đủ (functional completeness), tính
đúng đắn (functional correctness), và tính phù hợp (functional appropriateness).
• Độ tin cậy (Reliability): Bao gồm tính trưởng thành (maturity), khả năng chịu lỗi
(availability), và khả năng phục hồi (recoverability).
• Khả năng sử dụng (Usability): Bao gồm tính dễ hiểu (understandability), tính dễ học
(learnability), tính vận hành (operability), khả năng bảo vệ lỗi người dùng (user error
protection), và tính thẩm mỹ (user interface aesthetics). lOMoAR cPSD| 58457166
• Hiệu quả (Performance Efficiency): Bao gồm tính hiệu quả thời gian (time behavior) và
hiệu quả tài nguyên (resource utilization).
• Khả năng bảo trì (Maintainability): Bao gồm tính mô-đun hóa (modularity), tính tái sử
dụng (reusability), tính phân tích (analyzability), tính thay đổi (modifiability), và khả
năng kiểm tra (testability).
• Khả năng tương thích (Compatibility): Bao gồm tính tương thích (co-existence) và khả
năng tương tác (interoperability).
• Bảo mật (Security): Bao gồm tính bảo mật (confidentiality), tính toàn vẹn (integrity),
tính không thể chối cãi (non-repudiation), tính xác thực (authenticity), và tính sẵn có (accountability).
• Khả năng chuyển đổi (Portability): Bao gồm tính thích ứng (adaptability), tính cài đặt
(installability), và khả năng thay thế (replaceability). Ý nghĩa trong quản lý yêu cầu phần mềm
• Các tiêu chí chất lượng được định nghĩa sẵn là sự gợi ý cho các yêu cầu chất lượng o
Yêu cầu chất lượng là tập tiêu chí được chọn
• Ước lượng được mức độ quan trọng của mỗi tiêu chí trong môi trường ứng dụng thực tế.
o Để ước lượng mức độ thực hiện
• Với bộ tiêu chí được chọn làm yêu cầu, cả users lẫn devs đều có thể tự đánh giá chất lượng của PM
o Kiểm thử trên các đặc tính chất lượng được chọn Câu 2 (3 điểm)
Trực quan hóa sản phẩm phần mềm bằng mẫu thứ (prototype) có những lợi ích gì trong tiến trinh cam kết, tại sao ?
Lợi ích của Trực quan hóa Sản phẩm Phần mềm bằng Mẫu thử (Prototype) Giao tiếp hiệu quả:
• Hiểu rõ yêu cầu: Prototype chuyển đổi yêu cầu thành hình ảnh trực quan, giúp các bên
liên quan dễ hình dung sản phẩm cuối cùng.
• Giảm hiểu lầm: Giúp các bên liên quan hiểu rõ chức năng và tính năng, giảm thiểu sai sót và hiểu lầm. Phản hồi nhanh chóng:
• Phản hồi sớm: Người dùng có thể cung cấp phản hồi nhanh chóng, giúp nhóm phát triển điều chỉnh kịp thời.
• Phát hiện vấn đề sớm: Giúp phát hiện và sửa chữa lỗi thiết kế và chức năng ngay từ giai đoạn đầu.
Cải thiện quyết định: lOMoAR cPSD| 58457166
• Ra quyết định dựa trên bằng chứng: Prototype cung cấp cơ sở thực tế để thảo luận và quyết định.
• Tăng cường tham gia: Khuyến khích các bên liên quan tham gia và cam kết nhiều hơn. Tăng cường tin tưởng:
• Tạo niềm tin: Các bên liên quan tin tưởng hơn khi thấy yêu cầu của họ được hiện thực hóa.
• Thiết lập kỳ vọng: Giúp quản lý và thiết lập kỳ vọng thực tế về sản phẩm cuối cùng.
Hỗ trợ phát triển linh hoạt (Agile):
• Thích ứng nhanh: Prototype giúp nhóm phát triển nhanh chóng thích ứng với các thay đổi yêu cầu.
Tiết kiệm thời gian và chi phí:
• Giảm chi phí phát triển lại: Phát hiện và sửa lỗi sớm giúp tiết kiệm chi phí.
• Tiết kiệm thời gian: Xác định yêu cầu rõ ràng và loại bỏ yêu cầu không cần thiết, rút ngắn thời gian phát triển. Câu 3 (3 điểm)
Những tiêu chí gì dùng để so sánh chất lượng của các mô hình phát triễn phần mềm ? Các tiêu chí bao gồm:
o Khả năng đáp ứng yêu cầu khách hàng
o Hiệu quả phát triển o Chất lượng sản
phẩm o Đội ngũ và cộng tác o Khả năng
thích ứng và linh hoạt o Trải nghiệm người dùng Câu 4 (2 điểm)
Dùng phương pháp gieo lỗi để giới hạn số trường hợp kiểm thừ PM như thế nào ?
Phương pháp gieo lỗi (Error Seeding) là một kỹ thuật trong kiểm thử phần mềm nhằm cải thiện
quá trình phát hiện lỗi bằng cách cố tình thêm các lỗi vào hệ thống để đánh giá hiệu quả của các phương pháp kiểm thử.
Cách dùng phương pháp gieo lỗi để giới hạn số trường hợp kiểm thử:
• Xác định khu vực mục tiêu: Chọn các thành phần, module quan trọng hoặc xác định các
khu vực có nguy cơ lỗi cao
• Gieo lỗi có chủ ý: Thêm các lỗi có chủ ý vào mã nguồn hoặc cấu hình của hệ thống. Các
lỗi này có thể bao gồm lỗi logic, lỗi tính toán, hoặc lỗi về giao diện người dùng.
• Thực hiện kiểm thử: Thực hiện các trường hợp kiểm thử hiện tại để xem liệu chúng có
phát hiện được các lỗi đã gieo hay không. lOMoAR cPSD| 58457166
• Đánh giá hiệu quả: Đo lường tỷ lệ phát hiện lỗi của các trường hợp kiểm thử. Nếu tỷ lệ
này thấp, điều này có nghĩa là cần bổ sung hoặc cải thiện các trường hợp kiểm thử.
Câu 1 (2đ) Theo cách tiếp cận hệ thống, việc khám phá yêu cầu (requirements elicitation) được thực
hiện như thế nào ?
Theo cách tiếp cận hệ thống, việc khám phá yêu cầu (requirements elicitation) là quá trình quan
trọng nhằm hiểu và thu thập các yêu cầu của người dùng và các bên liên quan đối với hệ thống phần mềm
o Xác định các bên liên quan: Xác định tất cả các cá nhân, nhóm hoặc tổ chức liên quan
hoặc bị ảnh hưởng bởi hệ thống. o Chuẩn bị và lập kế hoạch: Xác định mục tiêu và
phạm vi của quá trình khám phá yêu cầu. Lập kế hoạch về phương pháp, kỹ thuật, lịch
trình và nguồn lực cần thiết. o Thu thập thông tin:
Phỏng vấn: Trực tiếp trò chuyện với các bên liên quan để hiểu rõ yêu cầu.
Khảo sát và bảng câu hỏi: Thu thập thông tin từ một
lượng lớn người dùng.
Hội thảo và nhóm làm việc: Tổ chức thảo luận để xác
định yêu cầu chi tiết.
o Phân tích yêu cầu:
Mô hình hóa yêu cầu: Sử dụng các công cụ như UML hoặc sơ đồ quy trình.
Phân tích chi tiết: Đảm bảo yêu cầu rõ ràng, đầy đủ và nhất quán.
o Xác minh và xác nhận yêu cầu:
Trình bày và xác nhận các yêu cầu với các bên liên quan.
Thu thập và phân tích phản hồi để điều chỉnh yêu cầu.
o Quản lý yêu cầu:
Tài liệu hóa các yêu cầu đã xác nhận.
Quản lý thay đổi yêu cầu hiệu quả.
Theo dõi và kiểm soát việc thực hiện các yêu cầu trong
suốt vòng đời dự án. Câu 2 (2đ) Môi trường nghiệp vụ (business environment)
của phần mềm là gì, vì sao yêu cầu làm phần mềm phải được xem xét chọn lọc
từ môi trường này ?
Môi trường nghiệp vụ của phần mềm là bối cảnh mà trong đó phần mềm sẽ được triển khai và sử dụng.
Nó bao gồm tất cả các yếu tố nội bộ và bên ngoài ảnh hưởng đến hoạt động và sự thành công của phần
mềm. Các yếu tố bao gồm: • Quy trình kinh doanh • Người dùng cuối • Công nghệ hiện tại
• Quy định và tiêu chuẩn mà phần mềm phải tuân thủ • Mục tiêu kinh doanh
• Sự cạnh tranh của các phần mềm khác lOMoAR cPSD| 58457166
Tại sao yêu cầu làm phần mềm phải được xem xét chọn lọc từ môi trường nghiệp vụ?
• Đảm bảo tính khả thi: phần mềm phải phản ánh đúng nhu cầu thực tế và các điều kiện hoạt
động của môi trường nghiệp vụ để đảm bảo tính khả thi khi triển khai.
• Tối ưu hóa hiệu quả kinh doanh: đảm bảo phần mềm hỗ trợ tốt nhất các mục tiêu kinh doanh,
cải thiện quy trình và tăng hiệu suất làm việc.
• Tích hợp và tương thích: đảm bảo phần mềm mới có thể tích hợp tốt với các hệ thống và công
nghệ hiện có, tránh các xung đột và gián đoạn.
• Tuân thủ quy định và tiêu chuẩn: đảm bảo phần mềm tuân thủ các quy định pháp luật và tiêu
chuẩn ngành, tránh các vấn đề pháp lý và tuân thủ.
• Cải thiện trải nghiệm người dùng: phản ánh đúng nhu cầu và mong muốn của người dùng cuối,
đảm bảo phần mềm dễ sử dụng và hữu ích.
• Giảm thiểu rủi ro và chi phí: giúp xác định và quản lý rủi ro từ sớm, tránh các vấn đề phát sinh sau này.
Câu 3 (2đ) Hãy giải thích nguyên nhân phát sinh yêu cầu đối với phần mềm theo cách tiếp cận hệ thong.
Câu 4 (2đ) Hãy trình bày nguyên lý Paretto (luật 20/80), và cách áp dụng nguyên lý này vào việc
kiểm thử phần mềm.
Nguyên lý Pareto, còn được gọi là Luật 20/80, phát biểu rằng trong nhiều hiện tượng, khoảng
80% kết quả đến từ 20% nguyên nhân. Cách áp dụng :
Xác định các khu vực có rủi ro cao:
• Phân tích lỗi trước đây: Xem xét các báo cáo lỗi từ các phiên bản trước của phần mềm để xác
định các module hoặc chức năng thường xuyên gặp lỗi.
• Xác định module quan trọng: Xác định các phần của phần mềm mà người dùng sử dụng nhiều
nhất hoặc có tác động lớn nhất đến hoạt động của hệ thống.
Tập trung kiểm thử vào các khu vực quan trọng:
• Ưu tiên kiểm thử: Tập trung 80% nỗ lực kiểm thử vào 20% các khu vực có rủi ro cao nhất và
quan trọng nhất của phần mềm. Điều này giúp phát hiện và khắc phục phần lớn lỗi với nỗ lực tối thiểu.
• Phân bổ nguồn lực: Dành nhiều thời gian và tài nguyên hơn cho việc kiểm thử các khu vực này,
bao gồm viết các trường hợp kiểm thử chi tiết và thực hiện kiểm thử sâu hơn.
Xây dựng các trường hợp kiểm thử dựa trên nguyên lý Pareto:
• Thiết kế kiểm thử: Tạo các trường hợp kiểm thử nhắm đến 20% chức năng hoặc mã nguồn mà
bạn tin rằng sẽ gây ra 80% vấn đề.
• Kiểm thử hồi quy: Tập trung kiểm thử hồi quy vào các phần mã nguồn có tiền sử lỗi cao hoặc có thay đổi nhiều.
Phân tích và cải tiến liên tục: lOMoAR cPSD| 58457166
• Phân tích sau kiểm thử: Sau mỗi chu kỳ kiểm thử, phân tích kết quả để xác định xem liệu 20%
các khu vực kiểm thử có thực sự gây ra 80% lỗi không.
• Điều chỉnh chiến lược: Dựa trên phân tích, điều chỉnh chiến lược kiểm thử để ngày càng tập trung
vào các khu vực có khả năng gây ra lỗi cao nhất.
Câu 5 (2đ) Hãy giải thích 4 yêu cầu cơ bản của SW Evolution (maitenance) và cách tìm hiếu chi
tiết về mỗi yêu cầu này. 4 yêu cầu:
Corrective action: sửa lỗi cho PM.
test -> định nghĩa lỗi -> sửa lỗi -> test -> … Cách tìm hiểu chi tiết:
o Phân tích lỗi: Xem xét báo cáo lỗi, log hệ thống và phản hồi của người dùng để
xác định nguyên nhân gốc rễ.
o Quy trình sửa lỗi: Đánh giá quy trình hiện tại để phát hiện lỗi và cải tiến để tăng
tốc độ và hiệu quả sửa lỗi.
o Công cụ và kỹ thuật: Sử dụng các công cụ gỡ lỗi và các kỹ thuật phân tích tĩnh
và động để tìm và sửa lỗi.
• Adaptive action: làm PM thích nghi với môi trường. 3 môi trường: nghiệp vụ,
vận hành, phát triển Cách tìm hiểu chi tiết:
• Nghiên cứu môi trường: Theo dõi các thay đổi trong môi trường hoạt động (ví
dụ: cập nhật hệ điều hành, phần cứng mới).
• Phân tích tác động: Đánh giá tác động của các thay đổi môi trường lên phần mềm hiện tại.
• Lập kế hoạch và thực hiện: Lập kế hoạch cho các thay đổi cần thiết và thực hiện
cập nhật phần mềm tương ứng.
• Perfective action: làm cho phần mềm hoàn hảo hơn. Chức năng & đặc tính của
phần mềm Cách tìm hiểu chi tiết:
• Thu thập phản hồi: Sử dụng khảo sát người dùng, phân tích sử dụng và phản hồi
để xác định các lĩnh vực cần cải thiện.
• Phân tích yêu cầu: Phân tích các yêu cầu mới hoặc thay đổi yêu cầu để xác định
tính khả thi và lợi ích.
• Thiết kế và triển khai: Thiết kế các tính năng nâng cấp và triển khai chúng một
cách hiệu quả, bao gồm kiểm thử và xác nhận.
• Preventive action: dự phòng & ngăn ngừa trước các rủi ro Vd: chống virus,
chống hackers, … Cách tìm hiểu chi tiết:
• Phân tích mã nguồn: Đánh giá mã nguồn để tìm kiếm các điểm yếu, mã lỗi thời hoặc mã khó bảo trì. lOMoAR cPSD| 58457166
• Kiểm toán và đánh giá: Thực hiện các kiểm toán mã và đánh giá bảo trì để xác
định các khu vực cần phòng ngừa.
• Tái cấu trúc và cải thiện: Áp dụng các kỹ thuật tái cấu trúc mã và cải thiện tài
liệu để nâng cao khả năng bảo trì. Câu 1 (2 điểm)
Nguyên nhân gi đưa đến mô hình chất lượng phần mềm như ISO25010 ?
Các yếu tố chính bao gồm:
1. Phức tạp của phần mềm hiện đại
Tính phức tạp gia tăng: Phần mềm ngày càng trở nên phức tạp, với nhiều tính năng và
tương tác hơn. Điều này đòi hỏi các tiêu chuẩn rõ ràng để đánh giá chất lượng trên nhiều khía cạnh.
2. Đa dạng yêu cầu từ người dùng và thị trường
Kỳ vọng cao: Người dùng và khách hàng có kỳ vọng cao về chất lượng, hiệu suất, và bảo mật của phần mềm.
Đa dạng yêu cầu: Các ứng dụng phần mềm phải đáp ứng một loạt các yêu cầu khác nhau,
từ bảo mật, khả năng sử dụng, đến tính di động và bảo trì.
3. Cạnh tranh thị trường
Cạnh tranh gay gắt: Trong môi trường cạnh tranh cao, chất lượng phần mềm là yếu tố
quan trọng giúp các công ty phần mềm duy trì và nâng cao vị thế của mình trên thị trường.
Khác biệt hóa sản phẩm: Các mô hình chất lượng giúp tạo ra các tiêu chuẩn để các công
ty khác biệt hóa sản phẩm của mình thông qua chất lượng.
4. Rủi ro và chi phí
Quản lý rủi ro: Phần mềm kém chất lượng có thể dẫn đến rủi ro nghiêm trọng, bao gồm
mất dữ liệu, vi phạm bảo mật, và giảm hiệu suất kinh doanh.
Tối ưu chi phí: Việc áp dụng các tiêu chuẩn chất lượng giúp giảm thiểu lỗi và chi phí bảo
trì, sửa chữa sau khi phần mềm đã triển khai.
5. Phát triển công nghệ
Tiến bộ công nghệ: Sự phát triển nhanh chóng của công nghệ đòi hỏi các tiêu chuẩn mới
và cập nhật để đánh giá chất lượng phần mềm trong các ngữ cảnh và môi trường mới.
Xuất hiện công nghệ mới: Công nghệ mới như AI, IoT, và điện toán đám mây yêu cầu
các tiêu chuẩn để đảm bảo chất lượng và hiệu suất.
6. Tính tương thích và tích hợp lOMoAR cPSD| 58457166
Tích hợp hệ thống: Phần mềm hiện đại thường cần tích hợp với nhiều hệ thống khác
nhau, đòi hỏi các tiêu chuẩn chất lượng để đảm bảo sự tương thích và hiệu suất.
Tính di động: Khả năng phần mềm chạy trên nhiều nền tảng khác nhau (Windows, Mac,
Android, iOS) đòi hỏi các tiêu chuẩn để đánh giá tính di động và tương thích.
7. Bảo mật và bảo vệ dữ liệu
Bảo mật thông tin: Với việc tăng cường sự quan tâm đến bảo mật và quyền riêng tư, các
tiêu chuẩn chất lượng như ISO/IEC 25010 cung cấp các hướng dẫn cụ thể về bảo mật phần mềm.
Tuân thủ pháp lý: Các quy định và luật pháp về bảo mật dữ liệu yêu cầu phần mềm phải
tuân thủ các tiêu chuẩn chất lượng nghiêm ngặt. Câu 2 (2 điểm)
Hay cho biết 2 ưu điểm nổi bật của mô hinh UP/RUP so với mõ hình xoắn ốc trong tiến trình làm phần mềm
Hai ưu điểm nổi bật của mô hình UP/RUP so với mô hình xoắn ốc trong tiến trình làm phần mềm bao gồm: 1.
Quy trình có cấu trúc và linh hoạtUP/RUP:
Cấu trúc rõ ràng: UP/RUP có một quy trình rõ ràng và chi tiết, được chia thành bốn giai đoạn
chính (Khởi đầu, Lập kế hoạch, Xây dựng, Chuyển giao) với các hoạt động cụ thể trong từng giai đoạn.
Linh hoạt: Cho phép tùy chỉnh quy trình để phù hợp với các loại dự án khác nhau. Nhóm phát
triển có thể điều chỉnh và mở rộng các hoạt động, tác vụ và sản phẩm trung gian dựa trên nhu cầu cụ thể của dự án.
So sánh với Mô hình xoắn ốc:
Mô hình xoắn ốc tập trung vào việc lặp lại các pha phát triển qua nhiều vòng xoắn, nhưng không
có một cấu trúc chi tiết và cố định như UP/RUP. Điều này có thể làm cho việc quản lý và theo dõi
tiến trình trở nên khó khăn hơn đối với các dự án phức tạp. 2.
Tích hợp các thực tiễn tốt nhất và công cụ hỗ trợUP/RUP:
Thực tiễn tốt nhất: UP/RUP tích hợp các thực tiễn tốt nhất trong ngành phần mềm, như phát triển
hướng đối tượng, sử dụng UML (Ngôn ngữ mô hình hóa thống nhất), và kiểm thử liên tục.
Công cụ hỗ trợ: RUP được hỗ trợ bởi nhiều công cụ phần mềm từ IBM Rational, giúp tự động
hóa nhiều phần của quy trình phát triển, từ thiết kế, kiểm thử đến quản lý cấu hình và thay đổi.
So sánh với Mô hình xoắn ốc: lOMoAR cPSD| 58457166
Mô hình xoắn ốc không chỉ định rõ ràng các công cụ và thực tiễn cụ thể để sử dụng. Nó chủ yếu
tập trung vào việc đánh giá rủi ro và lặp lại các pha phát triển mà không có sự tích hợp chi tiết
của các công cụ hỗ trợ và thực tiễn tốt nhất như UP/RUP. Câu 3 (2 điểm)
Môi trường nghiệp vụ của phần mềm là gì ? Phần mềm ảnh hưởng thế nào đến môi trường này ?
Môi trường nghiệp vụ của phần mềm là bối cảnh mà trong đó phần mềm sẽ được triển khai và sử dụng.
Nó bao gồm tất cả các yếu tố nội bộ và bên ngoài ảnh hưởng đến hoạt động và sự thành công của phần
mềm. Các yếu tố bao gồm: • Quy trình kinh doanh • Người dùng cuối • Công nghệ hiện tại
• Quy định và tiêu chuẩn mà phần mềm phải tuân thủ • Mục tiêu kinh doanh
• Sự cạnh tranh của các phần mềm khác
Phần mềm ảnh hưởng thế nào đến môi trường này ?
Câu 4 (2 điểm)Vì sao mô hình làm mẫu thử không được xem là mô hình tiến hóa ?
Dưới đây là lý do vì sao mô hình làm mẫu thử không được xem là mô hình tiến
hóa: 1. Mục tiêu và Phạm vi Mô hình làm mẫu thử:
Mục tiêu: Tạo ra các mẫu thử (prototypes) nhanh chóng để hiểu rõ hơn về yêu cầu của
người dùng và thu thập phản hồi. Mẫu thử thường là phiên bản đơn giản, không đầy đủ
của phần mềm cuối cùng.
Phạm vi: Thường tập trung vào việc làm rõ các yêu cầu và khía cạnh cụ thể của phần
mềm như giao diện người dùng hoặc một tính năng quan trọng. Mô hình tiến hóa:
Mục tiêu: Phát triển phần mềm qua các phiên bản liên tiếp, với mỗi phiên bản đều là một
phần mềm hoàn chỉnh có thể sử dụng được. Quá trình này tiếp tục cho đến khi phần mềm
đạt đến mức độ hoàn thiện cuối cùng.
Phạm vi: Mỗi phiên bản đều mở rộng và cải thiện chức năng so với phiên bản
trước, hướng đến sản phẩm hoàn chỉnh và đầy đủ tính năng. 2. Quy trình Phát triển Mô hình làm mẫu thử:
Quy trình: Tạo ra các mẫu thử nhanh chóng, nhận phản hồi từ người dùng, điều chỉnh yêu
cầu, và sau đó có thể bắt đầu lại từ đầu với một quy trình phát triển khác (thường là mô
hình thác nước hoặc mô hình xoắn ốc).
Không tiến hóa: Mẫu thử không nhất thiết phải phát triển thành sản phẩm cuối cùng.
Chúng chỉ là các công cụ để hiểu rõ yêu cầu và có thể bị loại bỏ sau khi yêu cầu được xác định rõ ràng. Mô hình tiến hóa: lOMoAR cPSD| 58457166
Quy trình: Phát triển phần mềm qua các vòng lặp liên tục. Mỗi vòng lặp tạo ra một phiên
bản phần mềm có khả năng sử dụng và mang tính hoàn thiện hơn phiên bản trước.
Tiến hóa liên tục: Phần mềm được phát triển và cải tiến liên tục cho đến khi đạt đến trạng
thái cuối cùng, với mỗi phiên bản đều được xây dựng trên nền tảng của phiên bản trước. 3. Kết
quả và Sản phẩm Cuối cùng Mô hình làm mẫu thử:
Kết quả: Mẫu thử giúp xác định và làm rõ yêu cầu, không phải là sản phẩm cuối cùng.
Sản phẩm cuối cùng: Thường được phát triển bằng một mô hình khác sau khi yêu cầu đã rõ ràng. Mô hình tiến hóa:
Kết quả: Mỗi phiên bản phần mềm đều là sản phẩm hoàn chỉnh và có thể sử dụng được,
nhưng vẫn tiếp tục được cải tiến và mở rộng.
Sản phẩm cuối cùng: Là kết quả của quá trình phát triển tiến hóa liên tục, với mỗi vòng
lặp góp phần vào hoàn thiện sản phẩm cuối cùng. Kết luận
Mô hình làm mẫu thử không được xem là mô hình tiến hóa vì nó chủ yếu tập trung vào
việc làm rõ yêu cầu thông qua các mẫu thử nhanh chóng và có thể bỏ đi, thay vì phát
triển phần mềm qua các phiên bản tiến hóa liên tục. Mô hình tiến hóa, ngược lại, tập
trung vào việc phát triển và cải thiện phần mềm một cách liên tục qua các vòng lặp, với
mỗi phiên bản đều là sản phẩm hoàn chỉnh hơn phiên bản trước. Câu 5 (2 điểm)
White-box test trợ giúp dược gì cho verification ?
White-box testing hỗ trợ verification của phần mềm bằng cách:
• Kiểm tra logic và cấu trúc mã nguồn: Phát hiện lỗi logic, kiểm tra các nhánh điều
kiện và vòng lặp trong mã.
• Tăng độ bao phủ mã: Đảm bảo tất cả các phần mã quan trọng được kiểm tra, bao
gồm các câu lệnh, nhánh, và đường dẫn.
• Xác minh luồng dữ liệu và biến: Đảm bảo dữ liệu được xử lý đúng cách và các
biến được sử dụng chính xác.
• Phát hiện lỗi bảo mật: Tìm ra lỗ hổng như tràn bộ đệm và SQL injection.
• Tối ưu hóa hiệu suất: Kiểm tra và cải thiện hiệu suất mã, sử dụng tài nguyên hiệu quả.
Nhờ đó, white-box testing giúp xác minh phần mềm một cách toàn diện và chi tiết.