Quiz: SWR302_FA24_FE - Đề thi FE học kì FALL 2024 có đáp án và giải thích chi tiết

Một Requirements Traceability Matrix (RTM) là một công cụ quan trọng trong quá trình quản lý yêu cầu. Mục đích chính của RTM là theo dõi mối quan hệ giữa các yêu cầu và các tài liệu khác liên quan đến dự án. Điều này giúp đảm bảo rằng tất cả các yêu cầu đã được đáp ứng và các tài liệu khác đều phù hợp với yêu cầu. RTM cũng giúp xác định các yêu cầu nào đã được thực hiện và các yêu cầu nào vẫn còn chưa được thực hiện. Điều này giúp dự án được quản lý một cách hiệu quả và giảm thiểu các vấn đề phát sinh trong quá trình thực hiện.

Yêu cầu cấp cao của một sản phẩm chứa nhiều hệ thống phụ là yêu cầu hệ thống. Yêu cầu hệ thống là một loại yêu cầu kỹ thuật cao cấp, mô tả các đặc điểm kỹ thuật của hệ thống, bao gồm cả các yêu cầu về phần mềm và phần cứng. Nó bao gồm các yêu cầu về kiến trúc hệ thống, giao tiếp giữa các hệ thống phụ, và các yêu cầu về bảo mật, tính khả dụng và hiệu suất. Yêu cầu hệ thống thường được xác định bởi các chuyên gia kỹ thuật và được sử dụng để hướng dẫn việc thiết kế và phát triển hệ thống. Ví dụ, yêu cầu hệ thống có thể bao gồm việc mô tả kiến trúc hệ thống, giao thức giao tiếp giữa các hệ thống phụ, và các yêu cầu về bảo mật và tính khả dụng.

Trong quá trình phát triển phần mềm, yêu cầu kỹ thuật (Requirements Engineering) là một bước quan trọng để đảm bảo rằng sản phẩm cuối cùng đáp ứng được nhu cầu của khách hàng. Yêu cầu kỹ thuật có thể được chia thành các bước sau: - Yêu cầu thu thập (Requirements Elicitation): Là quá trình thu thập thông tin về nhu cầu của khách hàng, bao gồm cả các yêu cầu không được nói ra. - Yêu cầu xác nhận (Requirements Confirmation): Là quá trình xác nhận lại các yêu cầu đã thu thập để đảm bảo rằng chúng chính xác và đầy đủ. - Yêu cầu quản lý (Requirements Management): Là quá trình quản lý và theo dõi các yêu cầu trong suốt quá trình phát triển phần mềm. - Yêu cầu phát triển (Requirements Development): Là quá trình xây dựng và xác định các yêu cầu chi tiết cho sản phẩm cuối cùng. Trong đó, yêu cầu thu thập (Requirements Elicitation) là bước quan trọng đầu tiên để đảm bảo rằng các yêu cầu của khách hàng được thu thập chính xác và đầy đủ.

Khách hàng có quyền được doanh nghiệp hiểu rõ về hoạt động kinh doanh và mục tiêu của họ. Họ cũng có quyền mô tả các đặc điểm sẽ giúp sản phẩm dễ sử dụng hơn. Ngoài ra, khách hàng có quyền nhận được một hệ thống đáp ứng được nhu cầu chức năng và tiêu chuẩn chất lượng của họ. Điều này giúp đảm bảo rằng hệ thống được thiết kế phù hợp với nhu cầu và mong muốn của khách hàng.

Khách hàng là một phần của nhóm người có liên quan đến hoạt động kinh doanh của doanh nghiệp. Họ là những người có thể ảnh hưởng đến doanh nghiệp hoặc ngược lại. Khách hàng là một trong những nhóm quan trọng nhất trong các bên liên quan. Họ cung cấp thông tin về nhu cầu và mong muốn của mình, giúp doanh nghiệp hiểu rõ hơn về thị trường và sản phẩm của mình. Ngoài ra, khách hàng còn là nguồn cung cấp thông tin về sản phẩm và dịch vụ của doanh nghiệp, giúp doanh nghiệp cải thiện và phát triển sản phẩm của mình. Vì vậy, khách hàng được coi là một phần của nhóm các bên liên quan, cụ thể là một phần của nhóm khách hàng.

Trong bước phân tích yêu cầu, kỹ thuật nào không phổ biến để thể hiện yêu cầu?

Việc ưu tiên các yêu cầu là một bước quan trọng trong quy trình phát triển phần mềm. Mục đích chính của việc này là đảm bảo rằng nhóm phát triển tập trung vào các tính năng quan trọng nhất hoặc có tính cấp thiết nhất trước. Điều này giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng được nhu cầu của khách hàng và mang lại giá trị cao nhất. Ngoài ra, việc ưu tiên các yêu cầu còn giúp xác định được từng phiên bản hoặc increment nào sẽ chứa các tính năng hoặc tập hợp yêu cầu cụ thể. Điều này giúp nhóm phát triển có thể lập kế hoạch và quản lý dự án một cách hiệu quả hơn.

Kỹ năng phân tích là một phần quan trọng của công việc phân tích kinh doanh. Để trở thành một nhà phân tích kinh doanh hiệu quả, bạn cần có khả năng suy nghĩ logic, phân tích dữ liệu và đưa ra quyết định sáng suốt. Ngoài ra, kỹ năng giao tiếp và làm việc nhóm cũng rất quan trọng, giúp bạn xây dựng mối quan hệ tốt đẹp với các thành viên trong nhóm và đảm bảo rằng tất cả mọi người đều hiểu rõ mục tiêu và yêu cầu của dự án. Kỹ năng học hỏi và thích nghi cũng rất cần thiết, giúp bạn cập nhật kiến thức và kỹ năng mới để đáp ứng nhu cầu của công ty và thị trường. Cuối cùng, kỹ năng lãnh đạo và tổ chức cũng rất quan trọng, giúp bạn quản lý và điều phối các hoạt động của dự án một cách hiệu quả.

Một nhà phân tích kinh doanh có nhiều nhiệm vụ quan trọng trong quá trình phát triển dự án. Đầu tiên, họ phải xác định các yêu cầu kinh doanh của dự án, hiểu rõ về mục tiêu và yêu cầu của khách hàng. Sau đó, họ phải xác định các bên liên quan và lớp người dùng của dự án, bao gồm cả các bên có thể ảnh hưởng đến dự án. Cuối cùng, họ phải dẫn dắt quá trình ưu tiên yêu cầu, đảm bảo rằng các yêu cầu quan trọng nhất được ưu tiên thực hiện trước.

Kỹ thuật được sử dụng để thể hiện phạm vi của một dự án là gì? Để trả lời câu hỏi này, chúng ta cần hiểu rõ về các kỹ thuật khác nhau được sử dụng trong việc thể hiện phạm vi của một dự án. Ecosystem map (Bản đồ hệ sinh thái) và Context diagram (Bản đồ ngữ cảnh) là hai kỹ thuật được sử dụng để thể hiện phạm vi của một dự án. Ecosystem map giúp thể hiện các thành phần và mối quan hệ giữa chúng trong hệ sinh thái của dự án, trong khi Context diagram giúp thể hiện các đối tượng và mối quan hệ giữa chúng trong ngữ cảnh của dự án. Cả hai kỹ thuật này đều giúp người lập kế hoạch và quản lý dự án hiểu rõ về phạm vi của dự án và có thể đưa ra quyết định sáng suốt.

Khi định nghĩa rõ phạm vi của một dự án phần mềm trong tài liệu phạm vi, điều này giúp tránh hiện tượng phạm vi dự án mở rộng không kiểm soát được (scope creep). Điều này có thể dẫn đến lãng phí thời gian, tài nguyên và chi phí. Bằng cách xác định rõ phạm vi dự án, các nhà phát triển có thể tập trung vào các yêu cầu chính và tránh các yêu cầu không liên quan. Điều này giúp đảm bảo dự án được hoàn thành đúng hạn và đạt được mục tiêu mong muốn.

Khi tham gia vào nhiều đại diện người dùng khác nhau thay vì chỉ dựa vào một đại diện duy nhất, chúng ta có thể đảm bảo được một cái nhìn toàn diện hơn về nhu cầu đa dạng của người dùng. Điều này giúp chúng ta hiểu rõ hơn về những mong muốn và kỳ vọng của người dùng, từ đó có thể thiết kế và phát triển sản phẩm hoặc giải pháp phù hợp hơn với nhu cầu của họ. Ngoài ra, việc tham gia vào nhiều đại diện người dùng còn giúp chúng ta nhận ra và giải quyết được những rủi ro tiềm ẩn mà chúng ta có thể bỏ qua nếu chỉ dựa vào một đại diện duy nhất.

Người dùng là một phần của nhóm khách hàng của sản phẩm. Tuy nhiên, người dùng không nhất thiết phải là khách hàng. Ví dụ, một người dùng có thể là nhân viên của công ty sử dụng sản phẩm, nhưng không phải là khách hàng của sản phẩm. Một người dùng cũng có thể là người sử dụng sản phẩm miễn phí, nhưng không phải là khách hàng. Do đó, người dùng không phải là một phần của nhóm khách hàng của sản phẩm. Thay vào đó, người dùng là một phần của nhóm người sử dụng sản phẩm.

Để xác định liệu bạn đã hoàn thành yêu cầu thu thập thông tin (requirements elicitation) hay chưa, bạn cần xem xét các tín hiệu sau. Đầu tiên, khi người dùng lặp lại các vấn đề họ đã thảo luận trước đó, điều đó có thể là dấu hiệu cho thấy bạn đã thu thập đủ thông tin. Thứ hai, nếu các yêu cầu mới được đề xuất đều được xác định là nằm ngoài phạm vi (out of scope), điều đó cho thấy bạn đã thu thập đủ thông tin về yêu cầu chính. Cuối cùng, nếu các yêu cầu mới được đề xuất đều có mức độ ưu tiên thấp, điều đó cũng cho thấy bạn đã thu thập đủ thông tin về yêu cầu chính.

Trong quá trình quan sát thụ động cho việc thu thập thông tin về nhiệm vụ, người quan sát sẽ không tham gia vào quá trình mà họ đang quan sát. Họ sẽ không hỏi bất kỳ câu hỏi nào, cũng không can thiệp vào quá trình đó. Thay vào đó, họ sẽ chỉ quan sát và ghi lại các hành động của người dùng mà không gây ảnh hưởng đến quá trình đó. Điều này giúp người quan sát có thể thu thập thông tin chính xác và khách quan về cách người dùng thực hiện các nhiệm vụ.

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.

Một Use Case Diagram là một loại hình ảnh được sử dụng trong thiết kế phần mềm để mô tả các trường hợp sử dụng của một hệ thống. Mục đích chính của Use Case Diagram là để mô tả các hành vi của hệ thống và các tương tác giữa hệ thống và người dùng. Chúng thường được sử dụng để xác định các yêu cầu của hệ thống và để phân tích các yêu cầu này. Use Case Diagram không phải là để mô tả giao diện người dùng đồ họa (GUI) mà cần được thực hiện. Thay vào đó, chúng mô tả các hành vi của hệ thống và các tương tác giữa hệ thống và người dùng. Điều này có nghĩa là Use Case Diagram không thể được sử dụng để mô tả giao diện người dùng đồ họa mà cần được thực hiện. Vì vậy, đáp án "Use case diagrams show the graphical user interface that needs to be implemented" là không đúng.

Một công ty phát triển ứng dụng đang cố gắng triển khai hệ thống lưu trữ dựa trên đám mây cho ứng dụng bản đồ mới của họ. Hệ thống đám mây sẽ quản lý độ dài và độ rộng kinh độ và vĩ độ của dữ liệu để theo dõi vị trí người dùng. Trong trường hợp này, cần một cơ sở dữ liệu có khả năng xử lý dữ liệu lớn và nhanh chóng, cũng như có khả năng quản lý dữ liệu phân tán. Aerospike và Vertica đều có khả năng này, nhưng Aerospike được thiết kế đặc biệt cho các ứng dụng đòi hỏi tốc độ cao và khả năng mở rộng lớn. Tuy nhiên, Redis cũng là một lựa chọn tốt vì nó có khả năng xử lý dữ liệu lớn và nhanh chóng, cũng như có khả năng quản lý dữ liệu phân tán. Nhưng Redis được thiết kế đặc biệt cho các ứng dụng đòi hỏi tốc độ cao và khả năng mở rộng lớn, vì vậy nó là lựa chọn tốt nhất cho ứng dụng bản đồ này.

Để tìm kiếm các quy tắc kinh doanh, bạn có thể tham khảo các nguồn sau: Thứ nhất, kiến thức phổ biến từ tổ chức, thường được thu thập từ những người đã làm việc với doanh nghiệp trong một thời gian dài và hiểu rõ chi tiết về cách thức hoạt động của nó. Điều này giúp bạn hiểu được quy trình và quy tắc kinh doanh của tổ chức. Thứ hai, hệ thống di sản (Legacy systems) chứa các quy tắc kinh doanh trong yêu cầu và mã nguồn của chúng. Điều này cho phép bạn hiểu được cách thức hoạt động của hệ thống và các quy tắc kinh doanh được áp dụng. Thứ ba, phân tích tài liệu hiện có, bao gồm các yêu cầu kỹ thuật từ dự án trước, quy định, tiêu chuẩn ngành, tài liệu chính sách doanh nghiệp, hợp đồng và kế hoạch kinh doanh. Điều này giúp bạn hiểu được quy tắc kinh doanh và cách thức hoạt động của doanh nghiệp. Tóm lại, việc tìm kiếm quy tắc kinh doanh là một quá trình phức tạp và đòi hỏi sự tham gia của nhiều nguồn lực khác nhau.

Mỗi lựa chọn đều đóng vai trò quan trọng trong mô tả chi tiết của Software Requirements Specification (SRS). Tuy nhiên, 'System feature' không phải là một phần quan trọng trong mô tả tổng quan của SRS. SRS thường bao gồm các phần như 'Product perspective' (khái quát về sản phẩm), 'User classes and characteristics' (khái quát về người dùng), 'Operating environment' (khái quát về môi trường hoạt động), 'Design and implementation constraints' (khái quát về hạn chế trong thiết kế và triển khai), 'Assumptions and dependencies' (khái quát về giả định và phụ thuộc). 'System feature' thường được sử dụng để mô tả các tính năng cụ thể của hệ thống, chứ không phải là mô tả tổng quan.

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ả.

Mục tiêu quan trọng của việc viết yêu cầu là đảm bảo rằng bất kỳ ai đọc yêu cầu đều có cùng hiểu biết về yêu cầu đó. Điều này có nghĩa là yêu cầu phải rõ ràng, dễ hiểu và không gây nhầm lẫn. Mục tiêu này giúp tránh những hiểu lầm không cần thiết và đảm bảo rằng tất cả các bên liên quan đều có cùng mục tiêu. Ví dụ, nếu yêu cầu không rõ ràng, một người đọc có thể hiểu nó một cách khác với người đọc khác, dẫn đến việc thực hiện sai yêu cầu. Vì vậy, việc viết yêu cầu một cách rõ ràng và dễ hiểu là rất quan trọng để đảm bảo rằng tất cả các bên liên quan đều có cùng hiểu biết về yêu cầu.

Để minh họa mối quan hệ giữa các đối tượng dữ liệu, nên sử dụng các loại biểu diễn sau đây. Hãy chọn 2 đáp án đúng. Entity-relationship diagram (Biểu đồ quan hệ thực thể) là một công cụ được sử dụng để minh họa mối quan hệ giữa các thực thể trong cơ sở dữ liệu. Nó giúp chúng ta hiểu rõ về cấu trúc dữ liệu và mối quan hệ giữa các thực thể. Data dictionary (Từ điển dữ liệu) là một tài liệu mô tả cấu trúc và mối quan hệ giữa các dữ liệu trong cơ sở dữ liệu. Nó giúp chúng ta hiểu rõ về dữ liệu và cách sử dụng chúng. Class diagram (Biểu đồ lớp) là một công cụ được sử dụng để minh họa mối quan hệ giữa các lớp trong một hệ thống. Nó giúp chúng ta hiểu rõ về cấu trúc hệ thống và mối quan hệ giữa các lớp. Context diagram (Biểu đồ ngữ cảnh) là một công cụ được sử dụng để minh họa mối quan hệ giữa các hệ thống và môi trường xung quanh. Nó giúp chúng ta hiểu rõ về hệ thống và cách nó tương tác với môi trường xung quanh. Tóm lại, để minh họa mối quan hệ giữa các đối tượng dữ liệu, chúng ta nên sử dụng Entity-relationship diagram và Data dictionary.

Swimlane diagram là một loại biểu đồ được sử dụng để minh họa các quy trình hoặc quy trình kinh doanh. Nó thường được sử dụng để hiển thị các bước trong một quy trình, cùng với các cá nhân hoặc nhóm chịu trách nhiệm thực hiện từng bước. Trong một Swimlane diagram, các bước quy trình thường được hiển thị dưới dạng hình dạng đặc biệt. Câu hỏi yêu cầu bạn xác định hình dạng nào thường được sử dụng để hiển thị các bước quy trình trong một Swimlane diagram.

Một mô hình dữ liệu là một hình ảnh trực quan thể hiện các đối tượng dữ liệu và các tập hợp dữ liệu mà hệ thống sẽ xử lý và mối quan hệ giữa chúng. Nó giúp xác định cấu trúc dữ liệu và cách dữ liệu được liên kết với nhau trong hệ thống. Mô hình dữ liệu thường được sử dụng trong thiết kế cơ sở dữ liệu và phát triển phần mềm để đảm bảo dữ liệu được tổ chức và quản lý một cách hiệu quả.

Khi xây dựng hệ thống thông tin, việc tham gia của các bên liên quan, bao gồm cả chuyên gia dữ liệu, vào quá trình xác định yêu cầu dữ liệu là rất quan trọng. Điều này giúp đảm bảo một cái nhìn toàn diện về nhu cầu và phức tạp của dữ liệu. Bằng cách tham gia vào quá trình này, các chuyên gia dữ liệu có thể cung cấp kiến thức chuyên môn và kinh nghiệm để giúp xác định chính xác yêu cầu dữ liệu của hệ thống. Điều này giúp tránh những sai sót và nhầm lẫn trong quá trình thiết kế và phát triển hệ thống, từ đó đảm bảo hệ thống hoạt động chính xác và hiệu quả.

Khi hệ thống phần mềm của khách hàng đã phát triển và họ muốn hệ thống này có thể xử lý 10 lần số lượng giao dịch hơn trước, thì điều này liên quan đến chất lượng đặc trưng của hệ thống phần mềm. Chất lượng đặc trưng này là khả năng mở rộng của hệ thống phần mềm. Khả năng mở rộng của hệ thống phần mềm là khả năng của hệ thống phần mềm để tăng cường khả năng xử lý của nó mà không làm giảm hiệu suất của hệ thống. Trong trường hợp này, hệ thống phần mềm không thể xử lý 10 lần số lượng giao dịch hơn trước do các quá trình monolithic và logic được kết nối chặt chẽ. Do đó, chất lượng đặc trưng mà hệ thống phần mềm này đang thiếu là khả năng mở rộng.

Tuyên bố trên đề cập đến tính chất chất lượng nào của hệ thống? Hệ thống cần phải có khả năng nhập bất kỳ cấu trúc hóa học hợp lệ nào từ công cụ ChemDraw phiên bản 13.0 hoặc trước đó và MarvinSketch phiên bản 5.0 hoặc trước đó. Điều này cho thấy hệ thống cần phải tương tác và tích hợp được với các công cụ khác nhau, không phụ thuộc vào phiên bản. Khả năng này được gọi là tính tương tác (Interoperability). Tính tương tác là khả năng của hệ thống để tương tác và tích hợp được với các hệ thống, ứng dụng hoặc thiết bị khác, đảm bảo rằng dữ liệu được trao đổi và sử dụng một cách chính xác và hiệu quả.

Phương pháp prototyping được đề cập trong câu hỏi là Evolutionary prototype. Đây là phương pháp tạo mẫu để làm rõ yêu cầu của người dùng, sau đó xây dựng và thêm các tính năng mới vào mẫu này từng bước một, và cuối cùng là phát hành sản phẩm cuối cùng dựa trên nó. Phương pháp này cho phép người dùng tham gia tích cực vào quá trình phát triển sản phẩm, giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu và mong muốn của họ.

Khi ưu tiên yêu cầu, bạn sẽ tập trung vào các tính năng có giá trị cao hơn. Điều này giúp bạn có thể quản lý dự án một cách hiệu quả hơn, giảm thiểu sự tham gia của các bên liên quan và giảm thiểu sự lan rộng của phạm vi dự án. Việc ưu tiên yêu cầu giúp bạn tập trung vào những gì thực sự quan trọng và cần thiết cho dự án, từ đó giúp bạn có thể hoàn thành dự án một cách nhanh chóng và hiệu quả hơn. Ngoài ra, việc ưu tiên yêu cầu cũng giúp bạn có thể giảm thiểu sự phức tạp và tăng cường sự linh hoạt trong việc quản lý dự án.

Trước hết, chúng ta cần hiểu rằng việc ưu tiên là một cách để xử lý các yêu cầu cạnh tranh cho các nguồn lực hạn chế. Khi đó, việc xác định ưu tiên tương đối của từng khả năng sản phẩm cho phép chúng ta lập kế hoạch xây dựng để cung cấp giá trị với chi phí tối ưu. Trong quá trình này, chúng ta cần phân loại các khả năng sản phẩm theo mức độ ưu tiên cao hay thấp. Mức độ ưu tiên cao nhất thường được dành cho các khả năng sản phẩm mang lại giá trị cao nhất cho tổ chức, trong khi mức độ ưu tiên thấp nhất thường được dành cho các khả năng sản phẩm không quá quan trọng. Vì vậy, khi được hỏi về cách sắp xếp các mức độ ưu tiên, chúng ta cần chọn đáp án "tối đa, tối thiểu".

Quá trình đánh giá sản phẩm dự án để xác định xem nó có đáp ứng nhu cầu của khách hàng hay không được gọi là Verification. Validation là quá trình xác định xem sản phẩm dự án có đáp ứng yêu cầu của khách hàng hay không. Checklist là một công cụ được sử dụng để đánh giá sản phẩm dự án. Testing là quá trình kiểm tra sản phẩm dự án để xác định xem nó có hoạt động đúng hay không. Tuy nhiên, Testing không phải là quá trình đánh giá sản phẩm dự án để xác định xem nó có đáp ứng nhu cầu của khách hàng hay không. Vì vậy, Testing là lựa chọn không đúng.

Câu hỏi này yêu cầu bạn xác định hoạt động không liên quan đến xác minh yêu cầu. Trong quá trình phát triển yêu cầu, có bốn thành phần chính: xác định yêu cầu, phân tích yêu cầu, xác minh yêu cầu và xác định yêu cầu. Xác minh yêu cầu là một hoạt động quan trọng để đảm bảo yêu cầu có tất cả các tính chất mong muốn của yêu cầu chất lượng cao. Nó cũng đảm bảo rằng yêu cầu đã được viết đúng và có liên quan đến mục tiêu kinh doanh. Tuy nhiên, câu trả lời không chính xác trong lựa chọn này là "Itis the fourth component of requirements development." vì nó chỉ là một phần của quá trình phát triển yêu cầu, không phải là hoạt động xác minh yêu cầu.

Các yếu tố sau đây có thể ngăn cản việc tái sử dụng yêu cầu. Yêu cầu được viết bằng ngôn ngữ tự nhiên có thể chứa các sự không rõ ràng, thiếu thông tin và giả định ẩn. Điều này có thể dẫn đến việc khó khăn trong việc hiểu và thực hiện yêu cầu. Vì vậy, việc tái sử dụng yêu cầu sẽ gặp khó khăn khi yêu cầu không được viết rõ ràng và chính xác.

Trong câu này, từ 'reuse' ám chỉ việc sử dụng lại các yêu cầu xác thực từ dự án trước đó. Từ 'all' chỉ ra rằng tất cả các yêu cầu xác thực đều có thể được sử dụng lại. Từ 'authentication requirements' ám chỉ các yêu cầu xác thực. Từ 'previous project' ám chỉ dự án trước đó. Từ 'library of reusable components' ám chỉ thư viện các thành phần có thể được sử dụng lại. Từ 'copy' ám chỉ việc sao chép các thành phần từ thư viện. Từ 'dimensions' ám chỉ các khía cạnh hoặc phương diện của việc sử dụng lại các yêu cầu xác thực. Vì vậy, câu này đang đề cập đến việc sử dụng lại các yêu cầu xác thực từ dự án trước đó bằng cách sao chép chúng từ thư viện các thành phần có thể được sử dụng lại.

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 dự án cải tiến (enhancement project) là một loại dự án trong đó các khả năng mới được thêm vào một hệ thống hiện có. Điều này có nghĩa là dự án cải tiến không thay thế hệ thống hiện có hoàn toàn, mà thay vào đó, nó bổ sung thêm các tính năng hoặc khả năng mới để cải thiện hiệu suất, tính năng hoặc trải nghiệm người dùng của hệ thống hiện có. Dự án cải tiến thường được thực hiện để đáp ứng nhu cầu mới của khách hàng, cải thiện hiệu suất hệ thống hoặc bổ sung thêm các tính năng mới để cạnh tranh với các đối thủ trong ngành. Ví dụ, một công ty có thể thực hiện dự án cải tiến để thêm tính năng mới vào hệ thống quản lý khách hàng của mình, chẳng hạn như khả năng theo dõi và phân tích dữ liệu khách hàng. Điều này sẽ giúp công ty có thể hiểu rõ hơn về nhu cầu và hành vi của khách hàng, từ đó có thể cung cấp dịch vụ tốt hơn và tăng cường mối quan hệ với khách hàng.

Một thách thức phổ biến mà cả các dự án cải tiến và thay thế thường gặp phải là sự phản đối từ người dùng. Người dùng đã quen thuộc với cách hệ thống hoạt động hiện tại có thể không thích những thay đổi mà họ sắp phải đối mặt. Điều này có thể dẫn đến sự kháng cự và khó khăn trong việc chấp nhận những thay đổi mới. Người dùng có thể cảm thấy không thoải mái với những thay đổi này, đặc biệt là nếu họ đã quen thuộc với cách hệ thống hoạt động trước đây. Vì vậy, việc hiểu được nhu cầu và mong muốn của người dùng là rất quan trọng trong việc đảm bảo rằng những thay đổi mới được chấp nhận và sử dụng một cách hiệu quả.

Câu hỏi này yêu cầu bạn xác định lựa chọn không liên quan đến giải pháp đóng gói. Giải pháp đóng gói là một phần của quá trình phát triển phần mềm, nơi bạn có thể mua hoặc sử dụng một phần hoặc toàn bộ giải pháp đã được thiết kế sẵn. Trong khi đó, việc xây dựng hệ thống bằng cách sử dụng nhân viên của mình là một phần của quá trình phát triển phần mềm truyền thống, nơi bạn xây dựng hệ thống từ đầu mà không sử dụng giải pháp đóng gói. Vì vậy, câu trả lời đúng là "Bạn xây dựng hệ thống bằng cách sử dụng nhân viên của mình".

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.

Quá trình quản lý yêu cầu (Requirements Management) là một phần quan trọng trong vòng đời phát triển phần mềm. Nó bao gồm việc thu thập, xác định, phân tích, xác định và quản lý yêu cầu của khách hàng. Trong các hoạt động sau, hoạt động nào được coi là một phần của nỗ lực quản lý yêu cầu?

Các hoạt động sau đây thuộc về các hoạt động cốt lõi của quản lý yêu cầu. Quản lý yêu cầu là một phần quan trọng trong chu kỳ phát triển sản phẩm, giúp đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện chính xác. Các hoạt động cốt lõi của quản lý yêu cầu bao gồm kiểm soát phiên bản, kiểm soát thay đổi, theo dõi trạng thái yêu cầu và theo dõi yêu cầu. Kiểm soát phiên bản giúp quản lý các phiên bản của yêu cầu, kiểm soát thay đổi giúp đảm bảo rằng các thay đổi được thực hiện một cách có hệ thống, theo dõi trạng thái yêu cầu giúp theo dõi tiến độ của yêu cầu và theo dõi yêu cầu giúp đảm bảo rằng các yêu cầu được thực hiện chính xác.

Để 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.

Change Control Board (CCB) là một nhóm người có trách nhiệm quyết định xem một thay đổi dự án có được chấp thuận hay không. Họ chịu trách nhiệm xem xét và đánh giá các đề xuất thay đổi, sau đó quyết định có chấp thuận hay không. CCB thường bao gồm các thành viên quan trọng như nhà quản lý dự án, nhà phát triển, người kiểm tra chất lượng và khách hàng. Mục tiêu của CCB là đảm bảo rằng các thay đổi được thực hiện một cách có trách nhiệm và không ảnh hưởng đến chất lượng dự án. Họ cũng đảm bảo rằng các thay đổi được thực hiện một cách hợp lý và không gây ra bất kỳ sự cố nào. Trong quá trình làm việc, CCB thường phải xem xét các yếu tố như tác động của thay đổi đến dự án, chi phí của thay đổi, thời gian thực hiện và khả năng thành công của thay đổi. Nếu CCB chấp thuận một thay đổi, họ sẽ tạo ra một bản ghi chép chi tiết về thay đổi đó, bao gồm lý do thay đổi, tác động của thay đổi và kế hoạch thực hiện. Điều này giúp đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về thay đổi và có thể thực hiện nó một cách hiệu quả.

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.

Để 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.

Risk management là quá trình quản lý và giảm thiểu rủi ro trong một dự án hoặc hoạt động kinh doanh. Quá trình này bao gồm nhiều bước khác nhau, bao gồm đánh giá rủi ro, kiểm soát rủi ro và quản lý rủi ro. Trong câu hỏi này, chúng ta được hỏi về các thành phần không phải của quản lý rủi ro.

Trong các dự án Agile, một epic là một khái niệm quan trọng trong quản lý dự án. Nó được định nghĩa là một tập hợp các user story liên quan đến nhau, thường quá lớn để hoàn thành trong một chu kỳ phát triển (iteration) duy nhất. Điều này có nghĩa là epic có thể bao gồm nhiều user story khác nhau, và nó có thể được thực hiện trong nhiều chu kỳ phát triển khác nhau. Epic cũng có thể được coi là một trong những tính năng quan trọng nhất của dự án, vì nó thường liên quan đến các yêu cầu chính của khách hàng.

Agile là một phương pháp quản lý dự án linh hoạt và nhanh chóng, tập trung vào việc đáp ứng nhu cầu của khách hàng và thích nghi với thay đổi. Một trong những đặc điểm chính của Agile là khả năng thích nghi với các yêu cầu và ưu tiên thay đổi liên tục. Điều này cho phép các dự án Agile phản ứng nhanh chóng với các thay đổi trong thị trường, công nghệ hoặc nhu cầu của khách hàng. Trong khi các dự án truyền thống thường tuân thủ một kế hoạch chi tiết, Agile cho phép các đội phát triển linh hoạt và thích nghi với các thay đổi. Điều này giúp tăng cường hiệu suất và chất lượng của dự án, đồng thời giảm thiểu rủi ro và tăng cường sự hài lòng của khách hàng.

Trong mô hình Use Case, các yếu tố bắt buộc phải có là những gì? Các Use Case phải có tên (Name), điều kiện trước (Pre-condition) và điều kiện sau (Post-condition). Điều kiện trước và sau giúp xác định rõ ràng các yêu cầu của Use Case, trong khi tên của Use Case giúp phân biệt nó với các Use Case khác. Các tác nhân (Actors) cũng là một phần quan trọng của Use Case, nhưng chúng không phải là bắt buộc. Vì vậy, đáp án đúng là ["Pre-condition", "Name", "Post-condition"].