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

Trong quản lý dự án, việc xác định và ưu tiên rủi ro là một phần quan trọng để đảm bảo dự án được thực hiện một cách hiệu quả và an toàn. Có nhiều phương pháp để xác định rủi ro, nhưng phương pháp phổ biến nhất là sử dụng phương pháp phân tích rủi ro (Risk Analysis). Phương pháp này bao gồm việc xác định, phân tích và ưu tiên rủi ro dựa trên mức độ nghiêm trọng và khả năng xảy ra của chúng. Để ưu tiên rủi ro, chúng ta cần xem xét cả khả năng xảy ra và tác động tiềm ẩn của rủi ro. Khả năng xảy ra của rủi ro được đo lường bằng mức độ xác suất xảy ra, trong khi tác động tiềm ẩn được đo lường bằng mức độ ảnh hưởng đến dự án. Bằng cách xem xét cả hai yếu tố này, chúng ta có thể xác định rủi ro nào cần được ưu tiên xử lý đầu tiên. Phương pháp này giúp đảm bảo rằng chúng ta tập trung vào những rủi ro có khả năng gây thiệt hại lớn nhất và có thể thực hiện các biện pháp phòng ngừa hoặc giảm thiểu rủi ro một cách hiệu quả.

Story point là một khái niệm quan trọng trong Agile và Scrum, được sử dụng để đo lường mức độ khó khăn của một User story. Mục đích của story point là giúp đội ngũ phát triển dự án có thể ước tính thời gian và công sức cần thiết để hoàn thành một User story. Story point thường được biểu diễn bằng một số điểm (points) và có thể được sử dụng để tạo ra một bảng xếp hạng các User story dựa trên mức độ khó khăn của chúng. Điều này giúp đội ngũ phát triển dự án có thể ưu tiên và sắp xếp các User story một cách hiệu quả hơn. Story point không liên quan trực tiếp đến mã code, chức năng hoặc kiến trúc của dự án, mà chỉ liên quan đến mức độ khó khăn của một User story.

Một Business analyst (BA) là người chịu trách nhiệm thu thập, phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. Các nhiệm vụ chính của một BA bao gồm: - Communicate requirements: Truyền đạt yêu cầu của khách hàng hoặc tổ chức đến các thành viên khác trong dự án. - Document requirements: Lưu trữ và quản lý yêu cầu của khách hàng hoặc tổ chức. - Analyze requirements: Phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. - Elicit requirements: Thu thập và xác định nhu cầu của khách hàng hoặc tổ chức. - Assurance requirements: Đây là một nhiệm vụ không phải là trách nhiệm chính của một BA. Assurance requirements thường liên quan đến việc đảm bảo rằng các yêu cầu đã được thực hiện đúng và đáp ứng được nhu cầu của khách hàng hoặc tổ chức. Điều này thường là trách nhiệm của các chuyên gia khác như kiểm toán viên hoặc chuyên gia đảm bảo chất lượng. Vì vậy, Assurance requirements là một nhiệm vụ không phải là trách nhiệm chính của một Business analyst.

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 phát triển và cải thiện liên tục. Agile khuyến khích sự tương tác giữa các thành viên trong dự án, bao gồm cả khách hàng, để đảm bảo rằng dự án được thực hiện đúng theo yêu cầu và mong muốn của họ. Trong Agile, các thành viên trong dự án thường xuyên họp và thảo luận để cập nhật và điều chỉnh kế hoạch dự án. Điều này giúp dự án được thực hiện nhanh chóng và hiệu quả hơ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.

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.

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.

Vision và Scope Document là một tài liệu quan trọng trong quá trình phát triển dự án, nó được sử dụng để định nghĩa mục tiêu, phạm vi và yêu cầu của dự án. Vision Document thường được xây dựng dựa trên các yêu cầu kinh doanh, nó giúp xác định mục tiêu và hướng đi của dự án. Scope Document thì lại tập trung vào việc xác định phạm vi của dự án, bao gồm các yêu cầu và hạn chế của dự án. Vì vậy, Vision và Scope Document được coi là một phần quan trọng của quá trình phát triển dự án và được xây dựng dựa trên các yêu cầu kinh doanh.

Requirements baseline là một khái niệm quan trọng trong quy trình phát triển hệ thống, nó đại diện cho một tập hợp các yêu cầu mà các bên liên quan đã đồng ý, thường xác định nội dung của một phiên bản cụ thể hoặc một vòng lặp phát triển. Requirements baseline giúp đảm bảo rằng hệ thống được phát triển đáp ứng được nhu cầu và kỳ vọng của các bên liên quan, đồng thời giúp giảm thiểu rủi ro và tăng cường hiệu suất phát triển. Khi tạo ra một requirements baseline, các nhà phát triển cần xem xét kỹ lưỡng các yêu cầu của hệ thống, bao gồm cả các tính năng, chức năng, và đặc điểm kỹ thuật. Điều này giúp đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu của các bên liên quan và đáp ứng được nhu cầu của người dùng cuối cùng. Requirements baseline cũng giúp các nhà phát triển theo dõi và quản lý các yêu cầu của hệ thống, từ đó giúp cải thiện hiệu suất phát triển và giảm thiểu rủi ro. Tóm lại, requirements baseline là một khái niệm quan trọng trong quy trình phát triển hệ thống, giúp đảm bảo rằng hệ thống được phát triển đáp ứng được nhu cầu và kỳ vọng của các bên liên quan.

Risk assessment là quá trình đánh giá và xác định các rủi ro tiềm ẩn trong một dự án. Quá trình này bao gồm việc phân tích và xác định các mối đe dọa, xác định mức độ nghiêm trọng của rủi ro và xác định các biện pháp phòng ngừa và giảm thiểu rủi ro. Mục tiêu của risk assessment là giúp dự án tránh được các rủi ro tiềm ẩn và giảm thiểu tác động của chúng khi chúng xảy ra. Quá trình này thường được thực hiện bởi các chuyên gia trong lĩnh vực dự án và rủi ro.

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

Requirements development tools là các công cụ được sử dụng để phát triển và xác định các yêu cầu của một dự án. Các công cụ này giúp các nhà phát triển và người sử dụng xác định rõ ràng các yêu cầu của dự án, từ đó tạo ra một sản phẩm đáp ứng được nhu cầu của người dùng. Các loại công cụ này bao gồm Elicitation tools, Prototyping tools và Modeling tools.

Planguage là một ngôn ngữ được thiết kế để giúp các nhà phát triển và quản lý dự án thể hiện rõ ràng và chính xác các thuộc tính chất lượng và mục tiêu dự án khác. Ngôn ngữ này cung cấp một bộ từ khóa phong phú cho phép người dùng tạo ra các tuyên bố chính xác về các thuộc tính chất lượng và mục tiêu dự án. Điều này giúp cho việc quản lý dự án trở nên dễ dàng hơn và giảm thiểu khả năng xảy ra sai sót. Planguage được sử dụng rộng rãi trong các dự án phần mềm và công nghệ để đảm bảo rằng các mục tiêu và yêu cầu của dự án được thực hiện một cách chính xác và hiệu quả.

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

Extent of reuse là một khái niệm quan trọng trong thiết kế và phát triển phần mềm, đặc biệt là trong lĩnh vực tái sử dụng mã nguồn. Nó đề cập đến mức độ mà một yêu cầu chức năng hoặc một phần của yêu cầu chức năng có thể được tái sử dụng trên một dự án mới. Trong thực tế, tái sử dụng không chỉ giới hạn ở việc sao chép và dán một yêu cầu chức năng đơn lẻ mà còn bao gồm cả việc tái sử dụng các yêu cầu chức năng phức tạp hơn như các trường hợp sử dụng, yêu cầu hiệu suất, yêu cầu sử dụng người dùng và các quy tắc kinh doanh. Mức độ tái sử dụng có thể khác nhau tùy thuộc vào tính chất của yêu cầu chức năng và mức độ phức tạp của dự án.

Trong sơ đồ trường hợp sử dụng, mũi tên từ người dùng đến trường hợp sử dụng thể hiện rằng người dùng đó là người dùng cho trường hợp sử dụng. Điều này có nghĩa là người dùng đó sẽ tương tác với hệ thống để đạt được mục tiêu của trường hợp sử dụng. Ví dụ, nếu một người dùng là người đặt hàng trực tuyến, thì mũi tên từ người dùng đến trường hợp sử dụng 'Đặt hàng trực tuyến' thể hiện rằng người dùng đó là người dùng cho trường hợp sử dụng này. Điều này giúp xác định rõ ràng vai trò của người dùng trong hệ thống và đảm bảo rằng hệ thống đáp ứng được nhu cầu của người dùng.

Trong một tài liệu yêu cầu phần mềm, phần mô tả giao diện người dùng thuộc về phần nào?

Trong quá trình phát triển yêu cầu, việc thiết lập cơ chế quản lý thay đổi yêu cầu là rất quan trọng. Điều này giúp dự án có thể thích nghi với nhu cầu thay đổi trong quá trình thực hiện, đồng thời vẫn duy trì được sự kiểm soát. Khi yêu cầu thay đổi, cơ chế này sẽ giúp dự án cập nhật và điều chỉnh các yêu cầu phù hợp, tránh gây ra sự cố hoặc lãng phí tài nguyên. Ngoài ra, cơ chế này cũng giúp dự án duy trì được sự minh bạch và rõ ràng trong quá trình thay đổi, đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về các thay đổi và tác động của chúng.