Tất cả câu hỏi

Một nhà phân tích kinh doanh (Business Analyst) đóng vai trò quan trọng trong quá trình phát triển sản phẩm. Họ có nhiệm vụ chính là thu thập và xác định các yêu cầu kinh doanh của doanh nghiệp. Điều này bao gồm việc phân tích các yêu cầu của khách hàng, xác định các yêu cầu chức năng và không chức năng, cũng như xác định các yêu cầu về quy trình và quy định. Ngoài ra, nhà phân tích kinh doanh còn có nhiệm vụ xác định các lớp người dùng của sản phẩm, tức là xác định các nhóm người dùng khác nhau và các yêu cầu của họ đối với sản phẩm. Điều này giúp doanh nghiệp hiểu rõ hơn về nhu cầu của khách hàng và phát triển sản phẩm phù hợp với nhu cầu của họ.

Khi viết yêu cầu, hai mục tiêu quan trọng là đảm bảo rằng bất kỳ ai đọc yêu cầu đều có thể hiểu nó một cách tương tự và mỗi người đọc đều có thể hiểu nó theo cách mà tác giả đã dự định. Điều này có nghĩa là yêu cầu phải rõ ràng, cụ thể và không có sự hiểu lầm. Điều này giúp đảm bảo rằng các nhà phát triển hiểu đúng yêu cầu và thực hiện nó một cách chính xác. Ngoài ra, khi yêu cầu được viết một cách rõ ràng và dễ hiểu, nó giúp giảm thiểu sự hiểu lầm và tăng cường sự đồng thuận giữa các bên liên quan. Điều này đặc biệt quan trọng trong các dự án lớn hoặc phức tạp, nơi mà sự hiểu lầm có thể dẫn đến các vấn đề nghiêm trọng và tốn kém.

Để minh họa mối quan hệ giữa các đối tượng dữ liệu, cần sử dụng các loại biểu diễn sau: Entity-relationship diagram và Class diagram.

Requirements engineering là quá trình thiết kế và phát triển các yêu cầu của một hệ thống hoặc sản phẩm. Quá trình này có thể được chia thành các bước khác nhau, bao gồm yêu cầu phát triển, quản lý yêu cầu, thu thập yêu cầu và xác nhận yêu cầu. Yêu cầu phát triển là quá trình xác định và mô tả các yêu cầu của hệ thống hoặc sản phẩm. Yêu cầu quản lý là quá trình theo dõi và cập nhật các yêu cầu của hệ thống hoặc sản phẩm. Thu thập yêu cầu là quá trình thu thập thông tin từ các bên liên quan để xác định các yêu cầu của hệ thống hoặc sản phẩm. Xác nhận yêu cầu là quá trình xác nhận rằng các yêu cầu đã được thu thập và mô tả chính xác. Trong câu hỏi này, hai đáp án đúng là yêu cầu phát triển và quản lý yêu cầu vì chúng là hai bước quan trọng trong quá trình requirements engineering.

Trong Agile development, user stories và epics là hai khái niệm quan trọng trong việc quản lý và triển khai dự án. User stories là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, thường được viết dưới dạng 'Tôi muốn làm gì để đạt được kết quả gì'. Chúng thường được sử dụng như một điểm bắt đầu cho các cuộc thảo luận chi tiết hơn về yêu cầu của người dùng. Ví dụ, 'Tôi muốn có thể xem lại lịch sử giao dịch của mình để theo dõi các giao dịch đã thực hiện'.

Một yêu cầu không chức năng (non-functional requirement) là một yêu cầu không liên quan trực tiếp đến chức năng của hệ thống. Yêu cầu này thường liên quan đến các tính chất của hệ thống, chẳng hạn như hiệu suất, bảo mật, độ tin cậy, khả năng mở rộng, v.v. Trong câu hỏi này, có ba lựa chọn yêu cầu liên quan đến giao tiếp giữa client và server. Lựa chọn A và C là hai yêu cầu không chức năng vì chúng liên quan đến định dạng và mã hóa dữ liệu được truyền đi, chứ không phải là chức năng chính của hệ thống. Lựa chọn B là một yêu cầu chức năng vì nó liên quan đến khả năng của người dùng trong việc chọn số khóa học.

Một use case là mô tả cụ thể về một trường hợp sử dụng của một hệ thống hoặc ứng dụng. Để tạo ra một use case hiệu quả, cần phải xác định các yếu tố bắt buộc. Trong đó, 'Actors' và 'Name' là hai yếu tố quan trọng.

Để đại diện cho phạm vi của một dự án, có hai kỹ thuật được sử dụng phổ biến: Ecosystem map và Context diagram. Ecosystem map là một công cụ giúp xác định và thể hiện các thành phần và mối quan hệ giữa chúng trong một hệ sinh thái dự án. Nó giúp các nhà phát triển và quản lý dự án hiểu rõ hơn về cấu trúc và tương tác của các thành phần khác nhau trong dự án. Ecosystem map thường bao gồm các yếu tố như người dùng, sản phẩm, dịch vụ, quy trình và công nghệ. Nó giúp xác định các điểm tương tác và mối quan hệ giữa các thành phần khác nhau trong dự án. Context diagram là một công cụ giúp thể hiện phạm vi của một dự án bằng cách mô tả các yếu tố và mối quan hệ giữa chúng trong một bối cảnh cụ thể. Nó giúp các nhà phát triển và quản lý dự án hiểu rõ hơn về yêu cầu và giới hạn của dự án. Context diagram thường bao gồm các yếu tố như người dùng, sản phẩm, dịch vụ, quy trình và công nghệ. Nó giúp xác định các điểm tương tác và mối quan hệ giữa các thành phần khác nhau trong dự án. Trong khi Use case và ERD là các kỹ thuật khác nhau được sử dụng trong thiết kế và phát triển dự án, chúng không được sử dụng để đại diện cho phạm vi của một dự án.

Product champions là những người đại diện cho một nhóm người dùng cụ thể trong một dự án. Họ có vai trò quan trọng trong việc thu thập yêu cầu từ các thành viên của nhóm người dùng mà họ đại diện và giải quyết bất đồng. Họ cũng đóng vai trò là điểm liên hệ chính giữa các thành viên của nhóm người dùng và nhà phân tích kinh doanh của dự án. Điều này giúp đảm bảo rằng yêu cầu của người dùng được hiểu và thực hiện một cách chính xác. Ngoài ra, product champions cũng có thể tham gia vào việc lập kế hoạch và thực hiện các yêu cầu của người dùng, nhưng điều này không phải là nhiệm vụ chính của họ. Trong khi đó, việc thực hiện các tiêu chuẩn mã hóa và viết tài liệu yêu cầu không phải là nhiệm vụ của product champions.

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

Câu hỏi này liên quan đến khái niệm stakeholder trong quản lý dự án. Stakeholder là bất kỳ cá nhân hoặc tổ chức nào có lợi ích hoặc ảnh hưởng đến dự án. Trong câu hỏi này, các stakeholder được liệt kê bao gồm nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp, nhà thầu và nhà đầu tư mạo hiểm. Tuy nhiên, không phải tất cả các stakeholder đều là khách hàng. Ví dụ, nhân viên pháp lý và kiểm toán viên tuân thủ có thể là stakeholder nhưng không phải là khách hàng. Vì vậy, câu trả lời đúng là 'False', vì không phải tất cả các stakeholder đều là khách hàng.

Một công cụ so sánh thử nghiệm (test comparator tool) thường được liên kết với hỗ trợ công cụ cho việc thực thi và ghi nhật ký thử nghiệm (test execution and logging). Công cụ này giúp so sánh kết quả thử nghiệm giữa các phiên bản khác nhau của một sản phẩm hoặc hệ thống, giúp phát hiện ra các vấn đề và cải thiện chất lượng sản phẩm. Công cụ so sánh thử nghiệm thường được sử dụng trong quá trình thử nghiệm và kiểm tra chất lượng sản phẩm, giúp đảm bảo rằng sản phẩm đáp ứng các yêu cầu và tiêu chuẩn chất lượng.

Test cases được tạo từ use cases là một phương pháp quan trọng trong việc phát triển và kiểm thử phần mềm. Mục đích chính của việc tạo test cases từ use cases là để đảm bảo rằng phần mềm hoạt động đúng như mong đợi trong các tình huống thực tế. Khi tạo test cases từ use cases, các nhà phát triển và kiểm thử viên có thể xác định các trường hợp sử dụng quan trọng và tạo ra các kịch bản kiểm thử để kiểm tra tính đúng đắn của phần mềm. Điều này giúp phát hiện ra các lỗi và sai sót trong quá trình sử dụng thực tế của hệ thống, từ đó cải thiện chất lượng phần mềm. Các test cases được tạo từ use cases cũng giúp đảm bảo rằng phần mềm đáp ứng được các yêu cầu của người dùng và hoạt động đúng như mong đợi trong các tình huống khác nhau. Vì vậy, các test cases được tạo từ use cases là rất hữu ích trong việc phát hiện ra các lỗi và sai sót trong quá trình sử dụng thực tế của hệ thống.

Re-testing và regression testing là hai khái niệm liên quan đến quá trình kiểm thử phần mềm. Re-testing là quá trình chạy lại các thử nghiệm đã được thực hiện trước đó để đảm bảo rằng các vấn đề đã được sửa chữa và phần mềm vẫn hoạt động đúng như mong đợi. Regression testing, mặt khác, là quá trình kiểm thử phần mềm để xác định xem các thay đổi gần đây đã gây ra bất kỳ tác động phụ nào không. Điều này bao gồm việc kiểm tra xem các thay đổi đã ảnh hưởng đến các chức năng khác của phần mềm hay không. Regression testing thường được thực hiện sau khi có các thay đổi lớn trong phần mềm, chẳng hạn như cập nhật hoặc sửa lỗi. Mục tiêu của regression testing là đảm bảo rằng phần mềm vẫn hoạt động đúng và không có bất kỳ tác động phụ nào sau khi có các thay đổi. Vì vậy, đáp án "Re-testing is running a test again; regression testing looks for unexpected side effects" là đúng.

Exit criteria là một phần quan trọng trong quy trình kiểm thử phần mềm. Nó xác định điều kiện để dừng lại kiểm thử, giúp đảm bảo rằng kiểm thử được thực hiện một cách hiệu quả và có ý nghĩa. Exit criteria có thể bao gồm nhiều yếu tố khác nhau, chẳng hạn như đạt được một mức độ chính xác nhất định, hoàn thành một số lượng kiểm thử nhất định, hoặc đạt được một kết quả mong muốn. Trong trường hợp này, đáp án đúng là "All of the others", vì exit criteria có thể bao gồm nhiều yếu tố khác nhau ngoài những gì được liệt kê trong các lựa chọn khác.

Kick Off phase là giai đoạn đầu tiên của một đánh giá chính thức trong quy trình phát triển phần mềm. Mục tiêu của giai đoạn này là thiết lập mục tiêu và hướng dẫn cho đánh giá. Trong Kick Off phase, người dẫn đánh giá sẽ giải thích rõ ràng và chi tiết về mục tiêu, yêu cầu và phạm vi của đánh giá. Đ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ề mục tiêu và yêu cầu của đánh giá, từ đó có thể thực hiện đánh giá một cách hiệu quả và chính xác. Ngoài ra, giai đoạn này cũng giúp thiết lập mối quan hệ giữa người dẫn đánh giá và các bên liên quan, tạo điều kiện cho việc trao đổi thông tin và thảo luận trong suốt quá trình đánh giá.

Static analysis là một kỹ thuật được sử dụng để kiểm tra mã nguồn của một chương trình để phát hiện ra các lỗi hoặc vấn đề tiềm ẩn. Các lỗi thường được phát hiện bởi phân tích tĩnh bao gồm các vấn đề về tiêu chuẩn lập trình, tham chiếu biến với giá trị chưa được định nghĩa, và các lỗ hổng bảo mật. Tuy nhiên, ngoài ra còn có nhiều loại lỗi khác mà phân tích tĩnh có thể phát hiện, chẳng hạn như lỗi logic, lỗi về kiểu dữ liệu, lỗi về cấu trúc dữ liệu, v.v. Vì vậy, đáp án đúng là 'Tất cả các lựa chọn khác' (All of the others).

Để tạo một trường hợp kiểm tra hiệu quả, điều quan trọng nhất là phải xác định kết quả mong đợi trước khi thực hiện. Điều này có nghĩa là trước khi chạy thử nghiệm, bạn cần xác định rõ ràng kết quả mong muốn của thử nghiệm. Điều này giúp đảm bảo rằng thử nghiệm được thiết kế để phát hiện lỗi nếu có, và giúp bạn xác định được liệu thử nghiệm đã đạt được kết quả mong muốn hay chưa. Ngoài ra, việc xác định kết quả mong đợi trước khi thực hiện cũng giúp bạn tránh được những thử nghiệm không cần thiết và giúp bạn tập trung vào những thử nghiệm quan trọng.

System testing là một phần quan trọng của quá trình kiểm thử phần mềm, giúp đảm bảo rằng hệ thống phần mềm đáp ứng được các yêu cầu chức năng và phi chức năng. Trong đó, các yêu cầu chức năng (Functional requirements) bao gồm các tính năng và chức năng mà hệ thống phần mềm cần phải thực hiện, chẳng hạn như nhập liệu, xử lý dữ liệu, xuất kết quả, v.v. Các yêu cầu phi chức năng (Non-functional requirements) bao gồm các tính chất và đặc điểm của hệ thống phần mềm, chẳng hạn như hiệu suất, độ tin cậy, bảo mật, v.v. Khi thực hiện system testing, các kỹ sư kiểm thử cần phải kiểm tra cả hai loại yêu cầu này. Điều này giúp đảm bảo rằng hệ thống phần mềm không chỉ đáp ứng được các yêu cầu chức năng mà còn đáp ứng được các yêu cầu phi chức năng. Ví dụ, một hệ thống phần mềm có thể đáp ứng được yêu cầu chức năng nhập liệu và xử lý dữ liệu, nhưng nếu không đáp ứng được yêu cầu phi chức năng hiệu suất, thì hệ thống phần mềm có thể sẽ chậm và không hiệu quả. Do đó, system testing nên kiểm tra cả hai loại yêu cầu này để đảm bảo rằng hệ thống phần mềm đáp ứng được tất cả các yêu cầu chức năng và phi chức năng. Điều này giúp đảm bảo rằng hệ thống phần mềm hoạt động đúng và hiệu quả, đáp ứng được nhu cầu của người dùng và mang lại giá trị cho tổ chức. Tóm lại, system testing nên kiểm tra cả hai loại yêu cầu chức năng và phi chức năng để đảm bảo rằng hệ thống phần mềm đáp ứng được tất cả các yêu cầu và hoạt động đúng và hiệu quả.

Khi nói về khả năng kiểm tra hoàn toàn, chúng ta đang đề cập đến việc liệu có thể kiểm tra một chương trình để đảm bảo nó không có lỗi hay không. Khả năng kiểm tra hoàn toàn là không thể đạt được trong thực tế, và điều này có những hậu quả quan trọng. Thứ nhất, chúng ta không thể chắc chắn rằng chương trình là hoàn toàn lỗi. Điều này có nghĩa là, ngay cả khi chúng ta đã kiểm tra chương trình một cách kỹ lưỡng, vẫn có thể có lỗi ẩn chưa được phát hiện. Thứ hai, do không có điểm dừng chắc chắn cho quá trình kiểm tra, điều này có thể khiến một số nhà quản lý dễ dàng tranh luận rằng không cần kiểm tra quá nhiều. Điều này có thể dẫn đến việc bỏ qua các bước kiểm tra quan trọng, khiến chương trình trở nên không an toàn và hiệu quả. Cuối cùng, do không có câu trả lời dễ dàng cho các nhiệm vụ kiểm tra nào nên luôn được yêu cầu, vì mỗi nhiệm vụ đều tốn thời gian có thể được sử dụng cho các nhiệm vụ quan trọng khác. Điều này có thể dẫn đến việc ưu tiên sai lầm trong quá trình kiểm tra, khiến chương trình trở nên không hiệu quả và không an toàn.