Tất cả câu hỏi

ERD (Entity-Relationship Diagram) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Để xác định câu trả lời sai, chúng ta cần hiểu rõ về các thành phần của ERD. Câu trả lời sai là 'Individual instances of an entity will have the same attribute values'. Điều này không đúng vì các bản sao riêng lẻ của một thực thể sẽ có các giá trị thuộc tính khác nhau. Ví dụ, trong một bảng khách hàng, mỗi khách hàng sẽ có một địa chỉ riêng biệt. Câu trả lời đúng về ERD bao gồm: 'The cardinality, or multiplicity, of each relationship is shown with a number or letter on the lines that connect entities and relationships', 'Each entity is described by one or more attributes' và 'The diamonds in the ERD represent relationships, which identify the logical linkages between pairs of entities'.

Một Entity Relationship Diagram (ERD) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Nó mô tả mối quan hệ giữa các thực thể (entity) trong một hệ thống dữ liệu. Các thành phần chính của một ERD bao gồm: thực thể (entity), mối quan hệ (relationship), quan hệ giữa thực thể (association), thuộc tính (attribute). Trong các lựa chọn trên, chỉ có một thành phần không phải là một phần của ERD. Đó là 'Cardinality'. Cardinality chỉ là một khái niệm trong ERD, nó mô tả số lượng thực thể tham gia vào một mối quan hệ. Nó không phải là một thành phần độc lập của ERD.

Một nhà phân tích kinh doanh có thể chuyển đổi tiếng nói của khách hàng thành các thành phần mô hình cụ thể bằng cách xác định các từ khóa như danh từ, động từ và các tuyên bố điều kiện có thể ánh xạ đến các thành phần mô hình phân tích tương ứng. Điều này giúp họ hiểu rõ hơn về nhu cầu và mong muốn của khách hàng, từ đó tạo ra các mô hình phân tích chính xác và hiệu quả. Ngoài ra, việc xác định các từ khóa cũng giúp nhà phân tích kinh doanh tránh được sự nhầm lẫn và đảm bảo rằng các mô hình phân tích được xây dựng dựa trên thông tin chính xác và đáng tin cậy.

Khi chọn kỹ thuật biểu diễn phù hợp cho mô hình phân tích, nên tuân theo các hướng dẫn sau. Mỗi quy trình kinh doanh có thể được biểu diễn bằng các sơ đồ lưu lượng dữ liệu ở mức cao hoặc các sơ đồ Swimlane thể hiện vai trò và trách nhiệm trong quy trình. Ngoài ra, logic phức tạp có thể được biểu diễn hiệu quả bằng các cây quyết định hoặc bảng quyết định, thể hiện các kết quả có thể xảy ra hoặc các yêu cầu chức năng độc đáo. Điều này giúp đảm bảo sự rõ ràng và tránh nhầm lẫn trong quá trình phát triển.

Đáp án đúng: "Consistency, ensuring that requirements do not conflict with other requirements or higher-level business, user, or system requirements.". Ngoài đặc tính của từng yêu cầu riêng lẻ, cả tập yêu cầu còn phải có bốn đặc tính: complete (đầy đủ), consistent (nhất quán), modifiable (sửa được) và traceable (truy vết được). Định nghĩa nhất quán trong đáp án là đúng: yêu cầu không mâu thuẫn nhau và không mâu thuẫn với yêu cầu nghiệp vụ, yêu cầu người dùng hay yêu cầu hệ thống ở tầng trên. "Completeness, meaning it is acceptable if some necessary information is absent as long as the core requirements are documented." sai vì đầy đủ nghĩa là không thiếu thông tin cần thiết, chỗ chưa biết phải đánh dấu TBD. "Modifiability, which allows changes to be made without maintaining a history of changes or considering dependencies among requirements" sai vì sửa được đòi hỏi giữ lịch sử thay đổi và nắm quan hệ giữa các yêu cầu. "Traceability, where requirements should be loosely linked and not necessarily connected to their origin or to derived elements" sai vì truy vết đòi hỏi nối mỗi yêu cầu ngược về nguồn gốc và xuôi tới thiết kế, mã, test.

Đáp án đúng: "Ensuring clarity, consistency, and avoiding ambiguities". Hệ thống phức tạp có rất nhiều yêu cầu đan xen giữa nhiều nhóm người dùng và hệ thống con, nên thách thức chính của việc đặc tả là viết sao cho mỗi yêu cầu rõ ràng, các yêu cầu không mâu thuẫn nhau và không có cách hiểu kép; đây là các đặc tính chất lượng của một bộ yêu cầu tốt mà hoạt động đặc tả và thẩm định phải bảo đảm. Phương án "Eliminating low-priority requirements" sai vì yêu cầu ưu tiên thấp vẫn được ghi lại và có thể làm ở bản sau; ưu tiên hóa không phải thách thức của việc viết tài liệu. Phương án "Skipping stakeholder validation" là một thói quen xấu, không phải thách thức cần vượt qua. Phương án "Focusing only on functional needs" sai vì hệ thống phức tạp càng cần đặc tả cả yêu cầu phi chức năng như hiệu năng, bảo mật, độ tin cậy.

Một quy tắc kinh doanh là một tuyên bố xác định hoặc hạn chế một khía cạnh nào đó của kinh doanh để kiểm soát hoặc ảnh hưởng đến hành vi của nó. Điều này có nghĩa là quy tắc kinh doanh xác định các điều kiện hoặc hạn chế nào cần được tuân thủ để đảm bảo hoạt động kinh doanh được thực hiện một cách hiệu quả và chính xác. Ví dụ, một quy tắc kinh doanh có thể xác định rằng một khách hàng phải là người lớn mới có thể thực hiện một giao dịch mua hàng trực tuyến. Việc xác định và áp dụng các quy tắc kinh doanh giúp đảm bảo rằng hoạt động kinh doanh được thực hiện một cách nhất quán và chính xác. Ngoài ra, việc phân loại các quy tắc kinh doanh giúp hiểu rõ cách chúng có thể được áp dụng trong một ứng dụng phần mềm, chẳng hạn như sử dụng hạn chế để thực hiện các điều kiện nhất định.

Prototyping trong kỹ thuật yêu cầu giúp giảm thiểu rủi ro trong quá trình thiết kế yêu cầu bằng cách cung cấp cho các bên liên quan một hình ảnh trực quan để xác minh các yêu cầu không rõ ràng. Quá trình này cho phép các bên liên quan xem xét và phản hồi về các yêu cầu trước khi triển khai hệ thống. Điều này giúp đảm bảo rằng các yêu cầu được hiểu đúng và giảm thiểu rủi ro phát sinh từ các yêu cầu không rõ ràng. Ngoài ra, prototyping cũng giúp xác định và giải quyết các vấn đề sớm, từ đó tiết kiệm thời gian và nguồn lực cho dự án.

Trong quá trình thu thập yêu cầu (requirements elicitation), prototyping đóng vai trò quan trọng. Prototyping là quá trình tạo ra mô hình hoặc bản demo của sản phẩm để thu thập phản hồi từ các bên liên quan. Điều này giúp làm rõ các yêu cầu không rõ ràng và thu thập phản hồi từ các bên liên quan. Quá trình này giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu và kỳ vọng của khách hàng. Ngoài ra, prototyping còn giúp tiết kiệm thời gian và nguồn lực trong quá trình phát triển sản phẩm.

Đáp án đúng: "To provide concise, actionable descriptions of features from the user’s perspective". User story là mô tả ngắn một nhu cầu theo góc nhìn người dùng, thường dạng là một vai trò, tôi muốn làm gì để đạt lợi ích gì, kèm tiêu chí chấp nhận; trong agile chúng là đơn vị yêu cầu được đưa vào backlog, ước lượng, xếp ưu tiên và làm rõ dần qua trao đổi. Phương án "To replace the Vision and Scope document" sai vì tầm nhìn và phạm vi ở tầng yêu cầu nghiệp vụ vẫn cần trong agile để định hướng, story ở tầng người dùng nằm bên dưới. Phương án "To prioritize non-functional requirements" sai vì story chủ yếu diễn đạt nhu cầu chức năng, còn ưu tiên là việc làm trên backlog. Phương án "To finalize the system's architecture" sai vì kiến trúc là quyết định thiết kế, user story không chốt kiến trúc.

Đáp án đúng: "Use Cases describe the interactions between the system and external entities.". Use case (ca sử dụng) mô tả một chuỗi tương tác giữa tác nhân (actor) bên ngoài, có thể là người dùng hay hệ thống khác, với hệ thống để đạt được một mục tiêu có giá trị cho tác nhân. Đây là kỹ thuật thu nhận yêu cầu người dùng (user requirements), dùng trong khơi gợi và phân tích. "Use Cases are static and do not evolve throughout the software development process." sai vì ca sử dụng được tinh chỉnh dần: ban đầu chỉ có tên và mô tả ngắn, sau đó thêm luồng chính, luồng thay thế, ngoại lệ và có thể đổi khi hiểu biết thay đổi. "Use case diagrams are the primary tool to document requirements" sai vì sơ đồ ca sử dụng chỉ là bức tranh tổng quan về phạm vi và các tác nhân; giá trị nằm ở phần đặc tả bằng văn bản, và yêu cầu chức năng chi tiết vẫn phải ghi trong SRS. "Use Cases are not useful in capturing user requirements." sai vì thu nhận yêu cầu người dùng chính là công dụng chủ yếu của ca sử dụng, giúp tập trung vào việc người dùng cần làm thay vì vào tính năng rời rạc.

Tên các trường hợp sử dụng nên được viết theo cách mô tả. Ví dụ, nếu trường hợp sử dụng liên quan đến việc đăng ký tài khoản, tên trường hợp sử dụng có thể là 'Đăng ký tài khoản mới'. Điều này giúp cho các nhà phát triển và người dùng dễ dàng hiểu được mục đích và chức năng của trường hợp sử dụng. Tên trường hợp sử dụng nên được viết một cách rõ ràng, ngắn gọn và dễ hiểu, giúp cho việc giao tiếp và hợp tác giữa các thành viên trong nhóm được hiệu quả hơn.

Tạo một ma trận theo dõi trong một dự án giúp đảm bảo rằng tất cả các yêu cầu được liên kết với các giai đoạn thiết kế, thử nghiệm và triển khai. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện một cách có hệ thống và toàn diện. Ma trận theo dõi giúp xác định rõ ràng 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 cần được xử lý. Điều này giúp giảm thiểu khả năng xảy ra lỗi và đảm bảo rằng dự án được hoàn thành đúng hạn. Ngoài ra, ma trận theo dõi còn giúp cải thiện sự hiểu biết và giao tiếp giữa các thành viên trong dự án, giúp đảm bảo rằng tất cả mọi người đều có cùng một bức tranh về dự án.

Elicitation trong kỹ thuật yêu cầu (requirements engineering) là quá trình thu thập thông tin về yêu cầu của người dùng hoặc các bên liên quan (stakeholders). Quá trình này nhằm mục đích xác định rõ những gì người dùng mong muốn và cần có trong hệ thống hoặc sản phẩm. Elicitation thường bao gồm các hoạt động như phỏng vấn, quan sát, phân tích dữ liệu và các phương pháp khác để thu thập thông tin về yêu cầu của người dùng. Quá trình này rất quan trọng vì nó giúp đảm bảo rằng hệ thống hoặc sản phẩm đáp ứng được nhu cầu và mong muốn của người dùng.

Hoạt động tổ chức và chia sẻ ghi chú thuộc về việc chuẩn bị cho việc thu thập thông tin. Khi bạn chuẩn bị cho việc thu thập thông tin, bạn cần phải tổ chức và sắp xếp các ghi chú của mình để dễ dàng truy cập và sử dụng. Điều này giúp bạn có thể thu thập thông tin một cách hiệu quả và chính xác hơn. Việc tổ chức và chia sẻ ghi chú cũng giúp bạn có thể dễ dàng chia sẻ thông tin với các thành viên khác trong nhóm, từ đó giúp việc thu thập thông tin trở nên nhanh chóng và hiệu quả hơn.

Trong phân tích yêu cầu, mục đích và cách sử dụng nhân vật (persona) được mô tả như sau. Hai lựa chọn dưới đây là đúng.

Một trong những lợi ích của việc có một bộ quy tắc rõ ràng cho người ủng hộ sản phẩm là gì? Người ủng hộ sản phẩm đóng vai trò quan trọng trong việc thúc đẩy sự thành công của dự án. Họ giúp đảm bảo rằng dự án được thực hiện một cách hiệu quả và đạt được mục tiêu đề ra. Tuy nhiên, không phải lợi ích nào của việc có một bộ quy tắc rõ ràng cho người ủng hộ sản phẩm cũng chính xác. Một trong những lợi ích không chính xác là đảm bảo dự án sẽ luôn nằm trong ngân sách. Điều này không phải là một lợi ích của việc có một bộ quy tắc rõ ràng cho người ủng hộ sản phẩm. Thay vào đó, nó là một lợi ích của việc quản lý dự án một cách hiệu quả.

Đáp án đúng: "Making them too vague or unmeasurable". Yêu cầu phi chức năng, nhất là thuộc tính chất lượng, hay bị viết chung chung kiểu hệ thống phải thân thiện hoặc phải nhanh; câu như vậy không kiểm chứng được và mỗi người hiểu một kiểu. Cách khắc phục là định lượng: nêu đại lượng đo, cách đo và ngưỡng, ví dụ thời gian phản hồi dưới 2 giây cho 95% yêu cầu, hoặc dùng Planguage. "Prioritizing them over functional requirements" sai vì không có quy tắc nào cấm ưu tiên yêu cầu phi chức năng; tuỳ bối cảnh, bảo mật hay khả dụng có thể quan trọng hơn một chức năng phụ. "Writing them without stakeholder input" là một lỗi có thể xảy ra với mọi loại yêu cầu, không phải cạm bẫy đặc trưng của yêu cầu phi chức năng. "Skipping them in the documentation process" cũng là sai lầm có thật, nhưng câu hỏi hỏi lỗi khi viết chúng; khi đã viết, lỗi phổ biến nhất là mơ hồ và không đo được.

Đáp án đúng gồm hai ý: "A context diagram visually illustrates the boundary between the system being developed and external entities that interact with it." và "The primary purpose of a context diagram is to depict the interactions between the system and external entities without detailing the internal workings of the system.". Context diagram (sơ đồ ngữ cảnh) là mô hình phạm vi: toàn bộ hệ thống được vẽ thành một khối duy nhất ở giữa, xung quanh là các thực thể ngoài như người dùng, tổ chức, hệ thống khác, nối với nó bằng các luồng dữ liệu hay điều khiển; nó cho biết cái gì nằm trong và ngoài ranh giới mà không mở hệ thống ra. Phương án "includes detailed information about the system’s internal processes and data" sai vì chi tiết tiến trình và dữ liệu bên trong thuộc các sơ đồ luồng dữ liệu mức thấp hơn. Phương án "relationship between user interfaces and system components within the boundary" sai vì sơ đồ ngữ cảnh không thể hiện thành phần bên trong ranh giới, cũng không mô hình hóa giao diện người dùng.

Scope creep là một thuật ngữ được sử dụng trong quản lý dự án để mô tả tình trạng khi phạm vi của dự án tiếp tục tăng lên một cách không kiểm soát được trong suốt quá trình phát triển. Điều này có nghĩa là dự án ban đầu được định nghĩa có thể đã thay đổi đáng kể so với kế hoạch ban đầu, dẫn đến việc tăng chi phí, thời gian và nguồn lực. Scope creep thường xảy ra khi các yêu cầu mới được thêm vào dự án mà không được xem xét kỹ lưỡng, hoặc khi các thành viên trong dự án không có khả năng quản lý phạm vi dự án một cách hiệu quả.