Thế nào là hoạt động bảo trì hiệu chỉnh?

Kết dính (cohesion) là thước đo mức độ liên quan chức năng của các phần tử trong một module. Kết dính gom góp (coincidental cohesion) là mức kết dính thấp nhất, xảy ra khi các phần tử trong module không liên quan gì đến nhau, chỉ đơn giản là được nhóm lại với nhau một cách ngẫu nhiên. Do đó, đáp án đúng là: Các công việc không liên quan với nhau, song lại bị bó vào một mô đun.

Trong quá trình xác định yêu cầu phần mềm, các yêu cầu thường được chia thành hai loại chính: yêu cầu chức năng (functional requirements) và yêu cầu phi chức năng (non-functional requirements).

- Yêu cầu chức năng mô tả những gì hệ thống *cần phải làm*. Chúng định nghĩa các chức năng, tính năng, hoặc hành vi cụ thể mà hệ thống phải cung cấp. Ví dụ: "Người dùng có thể đăng nhập vào hệ thống", "Hệ thống phải tính toán tổng giá trị đơn hàng", v.v.

- Yêu cầu phi chức năng mô tả *cách* hệ thống thực hiện các chức năng. Chúng liên quan đến các thuộc tính chất lượng của hệ thống, chẳng hạn như hiệu suất, bảo mật, khả năng mở rộng, khả năng sử dụng, v.v. Ví dụ: "Hệ thống phải phản hồi trong vòng 2 giây", "Hệ thống phải bảo mật thông tin cá nhân của người dùng", v.v.

Các lựa chọn khác không phản ánh cách phân loại yêu cầu chuẩn trong kỹ thuật phần mềm.

Trong phát triển phần mềm, con người là yếu tố quan trọng nhất. Vì con người (nhà phát triển, kỹ sư, quản lý dự án, v.v.) là những người tạo ra, duy trì và phát triển phần mềm. Quy trình, sản phẩm và thời gian đều quan trọng, nhưng chúng đều phụ thuộc vào con người. Một quy trình tốt sẽ không hiệu quả nếu không có những người có năng lực thực hiện nó. Một sản phẩm tốt sẽ không thể ra đời nếu không có những người có tầm nhìn và kỹ năng để tạo ra nó. Và thời gian sẽ không có ý nghĩa nếu không có những người biết cách quản lý và sử dụng nó một cách hiệu quả.

* Con người: Yếu tố then chốt quyết định sự thành công của dự án phần mềm. Bao gồm kỹ năng, kinh nghiệm, sự phối hợp và tinh thần làm việc của các thành viên.
* Quy trình: Đóng vai trò quan trọng trong việc định hướng và quản lý dự án, nhưng không thể thay thế vai trò của con người.
* Sản phẩm: Là kết quả của quá trình phát triển, chịu ảnh hưởng trực tiếp từ chất lượng đội ngũ và quy trình.
* Thời gian: Là yếu tố cần được quản lý chặt chẽ, nhưng không phải là yếu tố quan trọng nhất.

Do đó, đáp án đúng nhất là Con người.

Kỹ thuật xây dựng phần mềm từ các thành phần đã được thiết kế trong các lĩnh vực công nghệ khác nhau là kiến trúc hướng thành phần (Component architecture).

* Component architecture (Kiến trúc hướng thành phần): Tập trung vào việc xây dựng hệ thống phần mềm bằng cách lắp ráp các thành phần (components) độc lập, có khả năng tái sử dụng. Các thành phần này có thể được phát triển bởi các nhóm khác nhau, sử dụng các công nghệ khác nhau, và sau đó được tích hợp lại để tạo thành một hệ thống hoàn chỉnh.

* Extreme Programming (XP): Là một phương pháp phát triển phần mềm linh hoạt, tập trung vào việc giao tiếp liên tục, phản hồi nhanh chóng và sự đơn giản. XP không trực tiếp liên quan đến việc xây dựng phần mềm từ các thành phần có sẵn từ các lĩnh vực khác.

* Evolutionary prototyping (Xây dựng mẫu tiến hóa): Là một phương pháp xây dựng phần mềm bằng cách phát triển các phiên bản mẫu (prototypes) và liên tục cải tiến chúng dựa trên phản hồi của người dùng. Mặc dù có thể sử dụng các thành phần có sẵn, trọng tâm chính không phải là lắp ráp các thành phần từ các lĩnh vực khác.

* Open-source development (Phát triển mã nguồn mở): Là một mô hình phát triển phần mềm mà mã nguồn được công khai và cho phép mọi người sử dụng, sửa đổi và phân phối. Mặc dù các dự án mã nguồn mở có thể sử dụng các thành phần từ các lĩnh vực khác, nhưng đây không phải là định nghĩa cốt lõi của phát triển mã nguồn mở.

Theo thống kê, lỗi trong công nghệ phần mềm thường xuất phát nhiều nhất từ giai đoạn phân tích yêu cầu. Việc thu thập, làm rõ và đặc tả yêu cầu không chính xác hoặc không đầy đủ sẽ dẫn đến các sai sót kéo theo trong các giai đoạn thiết kế, viết code và kiểm thử sau này. Kiểm tra và bảo trì, thiết kế, và viết code cũng có thể gây ra lỗi, nhưng số lượng lỗi thường ít hơn so với lỗi phát sinh từ giai đoạn phân tích yêu cầu ban đầu.