Ôn tập cuối kỳ SWR302 Spring 2023

Validation (xác thực) là một khái niệm quan trọng trong quy trình phát triển phần mềm. Nó giúp xác định xem sản phẩm của một hoạt động phát triển có đáp ứng được yêu cầu của nó hay không. Trong đó, có hai khái niệm liên quan đến xác thực là Verification và Validation. Verification (kiểm tra) liên quan đến việc xác thực xem sản phẩm có đáp ứng được yêu cầu hay không, còn Validation (xác thực) liên quan đến việc xác thực xem sản phẩm có đáp ứng được mục tiêu kinh doanh hay không. Trong câu hỏi này, câu trả lời đúng là "Validation of requirements assesses whether you have written the right requirements: they trace back to business objectives.". Điều này có nghĩa là xác thực yêu cầu giúp xác định xem các yêu cầu đã được viết đúng chưa và chúng có liên quan đến mục tiêu kinh doanh hay không.

Khi phát triển kịch bản kiểm thử dựa trên yêu cầu, kiểm thử viên có thể phát hiện nhiều lỗi liên quan đến yêu cầu. Tuy nhiên, trong các lựa chọn trên, kiểm thử viên không nên tập trung vào việc kiểm tra các quy ước lập trình. Điều này vì quy ước lập trình là các quy định về cách viết mã, không phải là yêu cầu chức năng của hệ thống. Kiểm thử viên nên tập trung vào việc xác định các yêu cầu chức năng không rõ ràng, mâu thuẫn hoặc không thể đo lường được, vì những lỗi này có thể ảnh hưởng đến chất lượng của hệ thống.

Để cải thiện các thuật ngữ không rõ ràng (tốt hơn, nhanh hơn, chất lượng cao hơn), chúng ta cần xác định rõ ràng những gì được hiểu là 'tốt hơn' hay 'nhanh hơn'. Trong đó, cách phù hợp nhất là định lượng được mức độ cải thiện nào là đủ trong 6 lĩnh vực chức năng hoặc khía cạnh chất lượng cụ thể. Điều này giúp đảm bảo rằng mọi người có cùng một tiêu chuẩn và hiểu biết về những gì được coi là 'tốt hơn' hay 'nhanh hơn'. Ví dụ, nếu chúng ta đang cải thiện tốc độ của một hệ thống, chúng ta có thể định lượng được mức độ cải thiện tối thiểu là bao nhiêu phần trăm. Điều này giúp tránh những hiểu lầm và đảm bảo rằng mọi người có cùng một mục tiêu.

Các mối quan hệ giữa Use Case được định nghĩa như sau: Một mối quan hệ Include cho biết một Use Case bao gồm hành vi được mô tả trong Use Case khác. Một mối quan hệ Extend cho biết một Use Case có thể mở rộng hành vi được mô tả trong Use Case khác. Tương tự như kế thừa trong lập trình, mối quan hệ Generalization giữa Use Cases cho biết Use Case con là một dạng cụ thể hơn của Use Case cha. Use Case con thừa kế tất cả các tính năng và mối quan hệ của Use Case cha và có thể thêm mới các tính năng và mối quan hệ. Tất cả các mối quan hệ trên đều đúng và được sử dụng trong việc mô hình hóa Use Case.

Để mô hình hóa các yêu cầu và phân bổ các yêu cầu vào các subsystem, chúng ta cần hiểu rõ khái niệm 'hoạt động nên được thực hiện theo các giai đoạn'. Điều này liên quan đến quá trình phân tích yêu cầu (Requirements Analysis) để xác định các hoạt động cần được thực hiện và phân bổ chúng vào các subsystem phù hợp. Quá trình này bao gồm việc xác định các yêu cầu chức năng và không chức năng, phân tích các yêu cầu và xác định các hoạt động cần được thực hiện. Sau đó, chúng ta sẽ phân bổ các hoạt động này vào các subsystem phù hợp dựa trên các yêu cầu chức năng và không chức năng đã xác định. Quá trình này đòi hỏi sự hiểu biết sâu sắc về các yêu cầu và khả năng của các subsystem.

Khái niệm yêu cầu hệ thống (System Requirement) được định nghĩa là mô tả về một tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc một ràng buộc mà hệ thống phải tuân thủ. Điều này bao gồm các thuộc tính như hiệu suất, độ tin cậy, khả năng tương thích và các yêu cầu khác không liên quan trực tiếp đến chức năng của hệ thống. Yêu cầu hệ thống thường được xác định dựa trên yêu cầu của người dùng, yêu cầu của quy trình kinh doanh và các ràng buộc về kỹ thuật. Mục tiêu của yêu cầu hệ thống là đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu và nhu cầu của người dùng, đồng thời đảm bảo rằng hệ thống có thể vận hành một cách ổn định và hiệu quả.

Quyền lợi của khách hàng phần mềm được quy định trong yêu cầu hóa đơn bao gồm tất cả các lựa chọn sau, EXCEPT: 'Được nghe ý tưởng và phương án thay thế cho yêu cầu và cho giải pháp của họ'. Điều này là không đúng vì khách hàng phần mềm không có quyền được nghe ý tưởng và phương án thay thế từ nhà cung cấp phần mềm. Thay vào đó, khách hàng phần mềm có quyền được cung cấp thông tin chi tiết và chính xác về yêu cầu và giải pháp phần mềm. Họ cũng có quyền nhận được hệ thống phần mềm đáp ứng nhu cầu chức năng và kỳ vọng chất lượng của họ. Cuối cùng, khách hàng phần mềm có quyền được cung cấp thông tin về đặc điểm của sản phẩm giúp sản phẩm dễ sử dụng.

Các dự án được ủy thác thường liên quan đến các nhóm có cùng văn hóa công ty. Điều này có thể mang lại lợi thế vì các thành viên trong nhóm có thể dễ dàng hiểu và làm việc với nhau. Tuy nhiên, cũng có thể là một điểm yếu nếu các thành viên trong nhóm không có đủ kỹ năng hoặc kinh nghiệm để hoàn thành dự án. Văn hóa công ty có thể ảnh hưởng đến cách thức làm việc, cách thức giải quyết vấn đề và cách thức giao tiếp của nhóm. Vì vậy, việc hiểu và quản lý văn hóa công ty là rất quan trọng trong các dự án được ủy thác.

Sơ đồ có thể được sử dụng để giải thích các khái niệm khác nhau trong thiết kế hệ thống. Trong đó, sơ đồ có thể giúp minh họa về phạm vi của hệ thống, mối quan hệ giữa các lớp, thông tin lưu chuyển và các thực thể trong hệ thống. Ví dụ, sơ đồ có thể được sử dụng để minh họa về phạm vi của hệ thống, bao gồm các thành phần và các phần tử quan trọng của hệ thống. Ngoài ra, sơ đồ cũng có thể được sử dụng để minh họa về mối quan hệ giữa các lớp, giúp người xem hiểu rõ về cách các lớp tương tác với nhau. Tóm lại, sơ đồ là công cụ quan trọng trong thiết kế hệ thống, giúp người thiết kế và người xem hiểu rõ về các khái niệm và mối quan hệ trong hệ thống.

Khi các nhà quản lý và các tester tham gia vào quá trình đạt được thỏa thuận về yêu cầu, điều quan trọng là phải đảm bảo rằng các yêu cầu có thể được xác minh. Điều này có nghĩa là các yêu cầu phải cụ thể, rõ ràng và có thể đo lường được. Điều này giúp các tester xác định được các trường hợp thử nghiệm cần thiết và đảm bảo rằng các yêu cầu được thực hiện một cách chính xác. Ngoài ra, các nhà quản lý cũng cần đảm bảo rằng các yêu cầu sẽ không ảnh hưởng đến mục tiêu kinh doanh của họ. Điều này có nghĩa là các yêu cầu phải được thiết kế để đáp ứng nhu cầu của khách hàng và không gây ra bất kỳ thiệt hại nào cho doanh nghiệp. Vì vậy, cả hai điều kiện trên đều là đúng.

Để xác định các lớp người dùng của hệ thống phần mềm mới đang phát triển, chúng ta nên bắt đầu bằng cách hỏi người tài trợ dự án (project sponsor) về những người họ dự kiến sẽ sử dụng hệ thống. Sau đó, chúng ta có thể brainstorm để nghĩ ra càng nhiều lớp người dùng càng tốt. Việc này giúp đảm bảo rằng hệ thống được thiết kế để đáp ứng nhu cầu của tất cả các lớp người dùng.

Trong các lựa chọn trên, Mock-up là thuật ngữ có cùng ý nghĩa với vertical prototype. Vertical prototype thường được sử dụng trong thiết kế sản phẩm hoặc ứng dụng để mô tả bản thiết kế chi tiết và đầy đủ về một phần hoặc toàn bộ sản phẩm. Nó thường bao gồm các chi tiết về giao diện người dùng, chức năng và thiết kế của sản phẩm. Mock-up cũng có ý nghĩa tương tự, thường được sử dụng để mô tả bản thiết kế hoặc mô hình của một sản phẩm hoặc ứng dụng. Nó giúp các nhà thiết kế và phát triển có thể xem xét và đánh giá sản phẩm trước khi triển khai. Trong khi Navigation structure và Tree Navigation liên quan đến cấu trúc và giao diện người dùng của sản phẩm, nhưng chúng không phải là thuật ngữ chính xác để mô tả vertical prototype.

Câu hỏi này yêu cầu bạn đánh giá tính chính xác của tuyên bố rằng tất cả các dự án công nghệ thông tin của doanh nghiệp đều chọn thay thế tất cả các quy trình kinh doanh thủ công bằng tự động hóa quy trình kinh doanh. Tuy nhiên, điều này không phải lúc nào cũng đúng. Một số dự án có thể chọn tự động hóa một số quy trình kinh doanh, nhưng không phải tất cả. Ngoài ra, một số dự án có thể chọn duy trì một số quy trình kinh doanh thủ công vì lý do cụ thể. Vì vậy, tuyên bố này không phải lúc nào cũng chính xác.

Để 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 dấu hiệu sau. Một dấu hiệu tốt là khi các yêu cầu mới được đề xuất đều có mức độ ưu tiên cao. Tuy nhiên, điều này không phải lúc nào cũng đúng. Một dấu hiệu khác là khi các nhà phát triển và kiểm thử viên đánh giá yêu cầu cho một khu vực cụ thể và không có nhiều câu hỏi được đặt ra. Điều này cho thấy yêu cầu đã được rõ ràng và đầy đủ. Một dấu hiệu khác nữa là khi các tính năng mới được đề xuất, yêu cầu của người dùng hoặc yêu cầu chức năng đều được coi là nằm trong phạm vi dự án. Điều này cho thấy yêu cầu đã được thu thập đầy đủ và chính xác. Cuối cùng, nếu người dùng không đưa ra các vấn đề mới mà chưa được đề cập trong các cuộc thảo luận trước đó, thì cũng có thể coi là một dấu hiệu tốt.

Loại nỗ lực nào trong các lựa chọn dưới đây đòi hỏi phải có nhiều yêu cầu và công việc phát triển để tạo ra một sản phẩm phần mềm giải pháp đóng gói? Để sử dụng gói phần mềm như là nó, không cần phải thay đổi hoặc bổ sung thêm bất kỳ điều gì. Điều này có nghĩa là bạn có thể sử dụng nó ngay lập tức mà không cần phải thực hiện bất kỳ công việc nào. Tuy nhiên, nếu bạn muốn sử dụng gói phần mềm này để đáp ứng các yêu cầu cụ thể của mình, bạn sẽ cần phải thực hiện một số công việc để xác định các yêu cầu cụ thể của dự án. Điều này có thể bao gồm việc thu thập thông tin từ khách hàng, xác định các yêu cầu chức năng và không chức năng, và tạo ra các tài liệu yêu cầu chi tiết. Cuối cùng, nếu bạn muốn mở rộng hoặc tùy chỉnh gói phần mềm này để đáp ứng các yêu cầu cụ thể của mình, bạn sẽ cần phải thực hiện một số công việc phát triển phần mềm để tạo ra các tính năng mới hoặc sửa đổi các tính năng hiện có.

Sử dụng biểu đồ Use case giúp bạn biểu diễn mối quan hệ giữa cách dữ liệu được lưu trữ. Biểu đồ này mô tả các trường hợp sử dụng của hệ thống và mối quan hệ giữa chúng. Tuy nhiên, biểu đồ Use case không trực tiếp liên quan đến cách dữ liệu được lưu trữ trong cơ sở dữ liệu. Nó tập trung vào việc mô tả các hoạt động và chức năng của hệ thống, chứ không phải là cách dữ liệu được tổ chức và lưu trữ. Vì vậy, câu trả lời đúng là FALSE.

Khi viết Specification yêu cầu phần mềm, bạn nên viết chi tiết hơn trong trường hợp nào? Câu trả lời đúng là khi khách hàng tham gia sâu vào quá trình phát triển phần mềm. Điều này có nghĩa là khách hàng sẽ tham gia vào các cuộc thảo luận, cung cấp thông tin chi tiết về yêu cầu của họ và sẽ được cập nhật thường xuyên về tiến độ của dự án. Việc này giúp đảm bảo rằng phần mềm cuối cùng được phát triển đáp ứng đúng nhu cầu của khách hàng và giảm thiểu khả năng xảy ra sai sót. Ngoài ra, việc khách hàng tham gia sâu vào quá trình phát triển cũng giúp tăng cường sự hiểu biết và đồng thuận giữa các bên liên quan, từ đó giúp dự án được hoàn thành một cách hiệu quả hơn.

Một bản đồ hệ sinh thái (Ecosystem map) là một công cụ giúp bạn hiểu rõ hơn về các hệ thống liên quan đến hệ thống của bạn và cách chúng tương tác với nhau. Nó giúp bạn xác định ranh giới và các mối quan hệ giữa hệ thống của bạn và các hệ thống khác trong môi trường xung quanh. Bản đồ hệ sinh thái không chỉ giúp bạn hiểu rõ hơn về hệ thống của mình mà còn giúp bạn xác định các cơ hội và thách thức tiềm ẩn trong môi trường xung quanh. Nó cũng giúp bạn xác định các hệ thống quan trọng cần được xem xét khi phát triển hệ thống của mình.

Kỹ thuật xác định ưu tiên yêu cầu dựa trên tầm quan trọng và cấp thiết thuộc về phương pháp MoSCoW. MoSCoW là một kỹ thuật được sử dụng để xác định và sắp xếp các yêu cầu của dự án dựa trên tầm quan trọng và cấp thiết. Các yêu cầu được phân loại thành bốn loại: Must-Haves (phải có), Should-Haves (nên có), Could-Haves (có thể có) và Won't-Haves (không có). Phương pháp này giúp cho các nhà phát triển và quản lý dự án xác định được những yêu cầu quan trọng nhất và ưu tiên thực hiện chúng trước.

Trong phương pháp phát triển dự án Agile, vai trò truyền thống của Business Analyst thường được thay thế bởi Product Owner. Product Owner là người chịu trách nhiệm xác định yêu cầu và mục tiêu của dự án, đồng thời đảm bảo rằng các yêu cầu này được ưu tiên và thực hiện một cách hiệu quả. Họ cũng là người đại diện cho khách hàng và đảm bảo rằng dự án đáp ứng được nhu cầu và kỳ vọng của họ. Trong khi đó, Scrum Master là người hỗ trợ và hướng dẫn đội ngũ phát triển để đảm bảo rằng họ tuân thủ các quy trình và nguyên tắc của Agile. Team là đội ngũ phát triển thực hiện dự án, trong khi Tester là người chịu trách nhiệm kiểm tra và đảm bảo chất lượng của sản phẩm. Vì vậy, trong dự án sử dụng phương pháp Agile, vai trò Business Analyst thường được thay thế bởi Product Owner.