Ôn tập thi lại SWR302 Summer 2024

Mục tiêu chính của quản lý rủi ro trong các dự án phần mềm là xác định và đánh giá các mối đe dọa tiềm ẩn có thể ảnh hưởng đến dự án. Quá trình này giúp các nhà phát triển phần mềm nhận thức được những rủi ro tiềm ẩn và có thể chuẩn bị các biện pháp phòng ngừa hoặc giảm thiểu tác động của chúng. Bằng cách xác định các mối đe dọa tiềm ẩn, các nhà phát triển phần mềm có thể tạo ra các kế hoạch dự phòng và thực hiện các biện pháp để giảm thiểu rủi ro, từ đó đảm bảo dự án được thực hiện một cách hiệu quả và an toàn.

Để quản lý rủi ro hiệu quả, cần phải hiểu rõ các yếu tố cơ bản của quá trình này. Trong đó, có ba yếu tố quan trọng là đánh giá rủi ro (Risk assessment), kiểm soát rủi ro (Risk control) và giảm thiểu rủi ro (Risk reduction). Đánh giá rủi ro giúp xác định mức độ nghiêm trọng của rủi ro, từ đó có thể đưa ra quyết định về cách thức xử lý. Kiểm soát rủi ro liên quan đến việc thực hiện các biện pháp để ngăn chặn hoặc giảm thiểu rủi ro. Giảm thiểu rủi ro là quá trình tìm kiếm các giải pháp để giảm thiểu tác động tiêu cực của rủi ro. Ba yếu tố này thường được sử dụng cùng nhau để tạo thành một hệ thống quản lý rủi ro toàn diện.

Giải pháp yêu cầu theo dõi (requirements tracing) là một công cụ quan trọng trong quản lý dự án. Nó cho phép tạo liên kết giữa các nhiệm vụ trong kế hoạch dự án và tiến độ phát triển. Điều này giúp tăng cường theo dõi dự án, đảm bảo rằng các nhiệm vụ được thực hiện đúng theo kế hoạch. Ngoài ra, yêu cầu theo dõi còn giúp xác định các yêu cầu chưa được đáp ứng và cần phải bổ sung. Điều này giúp giảm thiểu chi phí phát triển và tăng cường chất lượng sản phẩm cuối cùng.

Để xử lý một yêu cầu thay đổi, có bốn nhiệm vụ cần được thực hiện. Trước hết, chúng ta phải đánh giá yêu cầu thay đổi (evaluate change request). Tiếp theo, chúng ta phải đưa ra quyết định thay đổi (make change decision). Sau đó, chúng ta phải thực hiện thay đổi (implement the change). Cuối cùng, chúng ta phải kiểm tra lại thay đổi (verify the change) để đảm bảo rằng nó đã được thực hiện đúng cách và không có lỗi nào.

Câu hỏi này yêu cầu bạn xác định thông tin không liên quan đến dự án được giao ngoài (outsourced projects). Các lựa chọn bao gồm: - Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. - Đó là khó khăn hơn để có được ý kiến của nhà phát triển về yêu cầu và để chuyển lại phản hồi của người dùng về phần mềm đã được giao cho nhà phát triển. - Cần có định nghĩa hợp đồng chính thức về yêu cầu, điều này có thể dẫn đến tranh chấp nếu sự khác biệt trong việc giải thích được phát hiện muộn trong dự án. Câu trả lời đúng là: Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. Vì dự án được giao ngoài thường không tận dụng kỹ năng phát triển có sẵn trong nội bộ mà thay vào đó là thuê ngoài để thực hiện.

Trong quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng. Chúng không chỉ ảnh hưởng đến kế hoạch dự án mà còn tác động trực tiếp đến quá trình thiết kế và viết mã nguồn. Yêu cầu cũng giúp xác định các hoạt động kiểm tra và thử nghiệm, đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn và yêu cầu đã được đặt ra. Vì vậy, yêu cầu (requirements) là nền tảng quan trọng để xây dựng một sản phẩm phần mềm chất lượng cao.

Một bản mẫu phần mềm là một bản dựng thử nghiệm của một sản phẩm mới. Nó thường được tạo ra để kiểm tra ý tưởng và xác định các yêu cầu của sản phẩm. Bản mẫu phần mềm có thể được xem là một phần thực hiện của sản phẩm mới, vì nó chỉ bao gồm một số tính năng hoặc chức năng của sản phẩm. Nó cũng có thể được xem là một bản dựng khả thi của sản phẩm mới, vì nó thể hiện một cách khả thi để triển khai sản phẩm. Ngoài ra, bản mẫu phần mềm cũng có thể được xem là một bản dựng sơ bộ của sản phẩm mới, vì nó thường được tạo ra trước khi sản phẩm được hoàn thiện. Tuy nhiên, bản mẫu phần mềm không phải lúc nào cũng là bản dựng hoàn chỉnh của sản phẩm mới.

Throwaway prototype là một loại prototype được xây dựng để đáp ứng nhu cầu cụ thể trong một giai đoạn nhất định. Nó thường được sử dụng khi đội ngũ phát triển gặp phải sự không chắc chắn, mơ hồ, không đầy đủ hoặc không rõ ràng trong yêu cầu. Mục đích chính của một prototype như vậy là để trả lời các câu hỏi, giải quyết sự không chắc chắn và cải thiện chất lượng yêu cầu. Khi xây dựng một prototype như vậy, đội ngũ phát triển không cần phải tuân thủ các kỹ thuật xây dựng phần mềm nghiêm ngặt. Điều này cho phép họ tập trung vào việc giải quyết các vấn đề quan trọng và tạo ra một sản phẩm có thể đáp ứng nhu cầu của khách hàng. Tuy nhiên, nó không phải là một sản phẩm cuối cùng và có thể được loại bỏ sau khi hoàn thành.

Tính chất chất lượng bên ngoài (external quality attribute) là những đặc điểm của một hệ thống hoặc phần mềm mà người dùng quan tâm. Các lựa chọn bên dưới đều là tính chất chất lượng bên ngoài, ngoại trừ một trong số đó. Tính sẵn có (Availability) là khả năng của hệ thống để sẵn sàng sử dụng khi người dùng cần. Tính toàn vẹn (Integrity) là khả năng của hệ thống để đảm bảo dữ liệu được cập nhật và lưu trữ chính xác. Tính an toàn (Safety) là khả năng của hệ thống để đảm bảo an toàn cho người dùng và hệ thống. Tính tái sử dụng (Reusability) là khả năng của hệ thống để được sử dụng lại trong nhiều dự án khác nhau. Tuy nhiên, tính tái sử dụng không phải là một tính chất chất lượng bên ngoài, mà là một tính chất chất lượng bên trong (internal quality attribute).

Các yêu cầu phải được thể hiện theo các dạng sau: Đầu tiên, chúng ta cần đảm bảo rằng yêu cầu có thể thực hiện được (Feasible). Điều này có nghĩa là yêu cầu phải có thể đạt được trong thực tế, không chỉ là một mục tiêu lý thuyết. Thứ hai, yêu cầu phải chính xác (Correct). Điều này có nghĩa là yêu cầu phải rõ ràng, không mơ hồ và không gây hiểu lầm. Cuối cùng, yêu cầu phải có thể kiểm tra được (Verifiable). Điều này có nghĩa là yêu cầu phải có thể đo lường được, có thể xác minh được và có thể đánh giá được. Tóm lại, yêu cầu phải được thể hiện một cách rõ ràng, chính xác và đo lường được để đảm bảo rằng chúng ta có thể đạt được mục tiêu một cách hiệu quả.

Khi viết SRS, việc ghi nhãn các yêu cầu là rất quan trọng. Điều này cho phép chúng ta tham khảo các yêu cầu cụ thể trong yêu cầu thay đổi, lịch sử sửa đổi, liên kết, hoặc ma trận theo dõi yêu cầu. Ngoài ra, việc ghi nhãn yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong nhiều dự án khác nhau. Điều này giúp tiết kiệm thời gian và công sức trong quá trình phát triển phần mềm. Hơn nữa, việc ghi nhãn yêu cầu cũng giúp cải thiện sự hợp tác giữa các thành viên trong nhóm khi họ thảo luận về các yêu cầu.

Sự khác biệt giữa Use Cases và User Stories là gì? Use Cases là một tài liệu kinh doanh xác định yêu cầu phần mềm hoặc tính năng ứng dụng. Trong khi đó, User Stories là một tài liệu kiểm thử xác định các bước để xác minh và xác thực rằng yêu cầu phần mềm hoặc tính năng ứng dụng tồn tại. Use Cases thường được sử dụng để mô tả các yêu cầu kinh doanh và chức năng của ứng dụng, trong khi User Stories được sử dụng để mô tả các yêu cầu kiểm thử và xác thực. Ví dụ, một Use Case có thể mô tả cách một người dùng có thể tạo một tài khoản mới, trong khi một User Story có thể mô tả các bước để kiểm thử tính năng tạo tài khoản mới.

Vậy, định nghĩa chính xác nhất về yêu cầu là gì? Yêu cầu là một tính chất mà sản phẩm phải có để mang lại giá trị cho bên liên quan. Điều này có nghĩa là yêu cầu là một đặc điểm hoặc tính năng mà sản phẩm phải có để đáp ứng nhu cầu hoặc mong muốn của người dùng. Ví dụ, một yêu cầu có thể là một tính năng mới, một chức năng cải tiến hoặc một tính năng bảo mật. Yêu cầu là cơ sở để thiết kế và phát triển sản phẩm, và nó giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu và mong muốn của người dùng. Vì vậy, yêu cầu là một khái niệm quan trọng trong quá trình thiết kế và phát triển sản phẩm.

Phương pháp MoSCoW đóng góp vào việc ưu tiên các yêu cầu dựa trên mục tiêu kinh doanh bằng cách phân loại các yêu cầu thành Must-haves, Should-haves, Could-haves và Won't-haves để hướng dẫn quá trình ưu tiên. Điều này giúp các nhà phát triển và quản lý dự án xác định rõ ràng những yêu cầu quan trọng nhất và ưu tiên chúng trước. Phương pháp MoSCoW cung cấp một khuôn khổ rõ ràng để đánh giá và sắp xếp các yêu cầu, từ đó giúp đảm bảo rằng các dự án được thực hiện một cách hiệu quả và tập trung vào những mục tiêu quan trọng nhất.

Các lý do khiến các công ty ký hợp đồng với các tổ chức cung cấp dịch vụ outsourcing phần mềm bao gồm việc tiết kiệm chi phí và tăng tốc độ phát triển cũng như tiếp cận chuyên môn hóa. Việc hợp tác với các tổ chức này cho phép các công ty tận dụng nguồn lực và chuyên môn của họ mà không cần phải đầu tư vào việc xây dựng và duy trì các bộ phận nội bộ. Điều này đặc biệt hữu ích cho các công ty muốn nhanh chóng triển khai các dự án hoặc giải quyết các thách thức kỹ thuật phức tạp mà họ không có đủ nguồn lực hoặc chuyên môn để giải quyết.

Một bản mock-up được gọi là một --_-spprototype, trong khi một bản concept được gọi là một --_-spprototype. Trong thiết kế sản phẩm, một bản mock-up thường được sử dụng để mô tả hình dạng và bố cục của sản phẩm, trong khi một bản concept được sử dụng để kiểm tra tính khả thi của ý tưởng sản phẩm. Một bản mock-up thường được tạo ra trước khi bắt đầu quá trình thiết kế chi tiết, trong khi một bản concept thường được tạo ra sau khi đã có một ý tưởng sản phẩm rõ ràng. Vì vậy, một bản mock-up thường được gọi là một prototype, trong khi một bản concept thường được gọi là một prototype.

Một bộ sưu tập các định nghĩa cho các phần tử dữ liệu và cấu trúc dữ liệu liên quan đến miền vấn đề. Dữ liệu dictionary là một công cụ quan trọng trong việc quản lý và tổ chức dữ liệu. Nó chứa các định nghĩa chi tiết về các phần tử dữ liệu, bao gồm tên, định nghĩa, loại dữ liệu, và các thuộc tính khác. Dữ liệu dictionary giúp đảm bảo rằng tất cả các bên liên quan đều hiểu và sử dụng dữ liệu một cách thống nhất. Nó cũng giúp giảm thiểu sai sót và tăng cường hiệu suất trong quá trình xử lý dữ liệu.

Các mục trong từ điển dữ liệu đại diện cho các loại phần tử dữ liệu sau: chọn 3 đáp án đúng. Các loại dữ liệu này bao gồm các phần tử cơ bản, cấu trúc và nhóm lặp lại. Các phần tử cơ bản là các giá trị đơn giản như số, chuỗi, boolean. Cấu trúc là một nhóm các phần tử dữ liệu được tổ chức theo một trình tự nhất định. Nhóm lặp lại là một nhóm các phần tử dữ liệu có thể lặp lại nhiều lần. Các loại dữ liệu này được sử dụng để mô tả và lưu trữ dữ liệu trong các ứng dụng và hệ thống thông tin.

Trong đó, SRS (Software Requirements Specification) là một tài liệu quan trọng trong quá trình phát triển phần mềm. Nó mô tả các yêu cầu chức năng và phi chức năng của phần mềm. Các yếu tố không được bao gồm trong SRS template bao gồm các đặc điểm thiết kế, tính năng của hệ thống. Các yếu tố này thường được mô tả trong tài liệu thiết kế phần mềm hoặc tài liệu kỹ thuật khác. Vì vậy, câu trả lời đúng là 'Tính năng của hệ thống'.

Hoạt động thu thập thông tin (elicitation) là một phần quan trọng trong quá trình thiết kế và phát triển sản phẩm. Các hoạt động thu thập thông tin thường bao gồm phỏng vấn người dùng, quan sát người dùng thực hiện công việc của họ và mô hình hóa môi trường ứng dụng. Tuy nhiên, định nghĩa tầm nhìn và phạm vi dự án sản phẩm không phải là một hoạt động thu thập thông tin. Thay vào đó, nó là một hoạt động quan trọng trong quá trình định hướng và lập kế hoạch dự án. Nó giúp xác định mục tiêu và phạm vi của dự án, từ đó hướng dẫn các hoạt động tiếp theo.