Xét đường độc lập cơ bản, nếu có 7 node phân nhánh thì ta có số đường thực thi cơ bản độc lập là

Độ đo mức độ bảo trì là một chỉ số đánh giá hiệu quả của quá trình bảo trì. Các lựa chọn đều có thể là các độ đo mức độ bảo trì khác nhau, tùy thuộc vào mục tiêu đánh giá cụ thể:

• A. Số vấn đề giải quyết trong tháng / tổng số vấn đề phát sinh trong tháng: Đo lường khả năng giải quyết các vấn đề phát sinh một cách nhanh chóng và hiệu quả.
• B. Số lần bảo trì vượt quá tiêu chuẩn thời gian / tổng số lần bảo trì: Đánh giá khả năng tuân thủ thời gian bảo trì tiêu chuẩn.
• C. Số lần bảo trì sai sót / tổng số lần bảo trì: Đo lường chất lượng của quá trình bảo trì, thể hiện số lượng các sai sót xảy ra.
• D. Thời gian trung bình của một lần bảo trì: Đo lường hiệu quả thời gian của mỗi lần bảo trì.

Như vậy, tất cả các đáp án đều có thể được sử dụng để đo lường mức độ bảo trì, tùy thuộc vào khía cạnh bảo trì nào cần được đánh giá. Tuy nhiên, đáp án C. Số lần bảo trì sai sót /tổng số lần bảo trì thể hiện trực tiếp và quan trọng nhất chất lượng của quá trình bảo trì, vì nó cho biết tần suất xảy ra lỗi trong quá trình bảo trì.

Mô hình phát triển phần mềm dựa trên mẫu thử (prototype) được sử dụng khi yêu cầu của khách hàng chưa rõ ràng. Khi đó, việc xây dựng một bản mẫu (prototype) giúp khách hàng hình dung rõ hơn về sản phẩm cuối cùng, từ đó đưa ra các yêu cầu cụ thể và chính xác hơn.

A. Sai. Mô hình prototype không phù hợp khi các yêu cầu đã được xác định rõ ràng, vì nó sẽ gây lãng phí thời gian và nguồn lực. B. Sai. Số lượng thành viên trong dự án không phải là yếu tố quyết định việc sử dụng mô hình prototype. C. Đúng. Khi khách hàng không thể xác định yêu cầu một cách rõ ràng, mô hình prototype là một phương pháp hữu ích để khám phá và làm rõ các yêu cầu. D. Sai. Mô hình prototype không phải là một mô hình rủi ro nếu được quản lý đúng cách. Nó có thể giúp giảm thiểu rủi ro bằng cách phát hiện và giải quyết các vấn đề sớm trong quá trình phát triển.

Giai đoạn tổng quát của công nghệ phần mềm thường được chia thành ba giai đoạn chính: Định nghĩa (Definition), Phát triển (Development) và Hỗ trợ (Support).

• Định nghĩa (Definition): Giai đoạn này tập trung vào việc xác định rõ yêu cầu của phần mềm, bao gồm những gì phần mềm cần làm, mục tiêu của dự án, và các ràng buộc liên quan.
• Phát triển (Development): Giai đoạn này bao gồm việc thiết kế, lập trình và kiểm thử phần mềm. Đây là giai đoạn mà phần mềm thực sự được xây dựng.
• Hỗ trợ (Support): Giai đoạn này bao gồm việc bảo trì, sửa lỗi và nâng cấp phần mềm sau khi nó đã được triển khai. Mục tiêu là đảm bảo phần mềm hoạt động ổn định và đáp ứng nhu cầu của người dùng.

Các lựa chọn khác không phản ánh chính xác các giai đoạn tổng quát của công nghệ phần mềm:

• "what, how, where" mô tả các khía cạnh của yêu cầu, nhưng không phải là giai đoạn tổng quát.
• "Programming, debugging, maintenance" chỉ là các hoạt động cụ thể trong giai đoạn phát triển và hỗ trợ.
• "Analysis, design, testing" cũng là các hoạt động cụ thể trong giai đoạn định nghĩa và phát triển.

Thành phần kiến trúc trong kỹ thuật sản phẩm bao gồm các yếu tố chính: dữ liệu (data), phần cứng (hardware), phần mềm (software) và các thủ tục (procedures) cần thiết để vận hành và quản lý hệ thống. Do đó, đáp án C là chính xác nhất.

Các lựa chọn khác không đầy đủ hoặc không chính xác vì:

• Lựa chọn A thiếu 'thủ tục'.
• Lựa chọn B thiếu 'thủ tục' và thay 'con người' bằng 'tài liệu' là không phù hợp.
• Lựa chọn D thiếu 'dữ liệu' và bao gồm 'con người' không phải là một thành phần kiến trúc trong kỹ thuật sản phẩm.

Phân tích yêu cầu phần mềm bao gồm các công việc như mô hình hóa và thừa nhận vấn đề, đặc tả và xem xét yêu cầu, định giá và tổng hợp các yêu cầu. Tuy nhiên, lập kế hoạch và lịch biểu là các công việc thuộc giai đoạn quản lý dự án, không phải là một phần của phân tích yêu cầu.