Câu hỏi: SWR302 - Phần 13: Tái sử dụng yêu cầu và nối sang kế hoạch, thiết kế, kiểm thử

Viết yêu cầu cụ thể cho một miền (domain-specific) thường được thực hiện ở mức độ trừu tượng cao và phạm vi rộng. Điều này có nghĩa là các yêu cầu này được viết dựa trên các khái niệm và mô hình cụ thể của miền đó, giúp đảm bảo rằng các yêu cầu được đáp ứng chính xác và đầy đủ. Ví dụ, khi viết yêu cầu cho một hệ thống quản lý bệnh viện, các yêu cầu cụ thể cho miền này sẽ được viết dựa trên các khái niệm và mô hình liên quan đến quản lý bệnh viện, chẳng hạn như quản lý hồ sơ bệnh án, quản lý thuốc, v.v. Mức độ trừu tượng cao và phạm vi rộng giúp đảm bảo rằng các yêu cầu được viết một cách toàn diện và chính xác.

Kỹ thuật lập trình phần mềm dựa trên việc tái sử dụng là một chiến lược kỹ thuật lập trình phần mềm, trong đó quá trình phát triển được thiết kế để tái sử dụng phần mềm đã tồn tại. Điều này có nghĩa là các phần mềm đã được phát triển trước đó sẽ được sử dụng lại trong các dự án mới, thay vì phải xây dựng lại từ đầu. Việc tái sử dụng phần mềm có thể giúp giảm thiểu thời gian và chi phí phát triển, cũng như cải thiện chất lượng phần mềm. Nó cũng giúp các lập trình viên học hỏi từ kinh nghiệm của người khác và tránh lặp lại những sai lầm đã biết. Tái sử dụng phần mềm cũng có thể giúp tạo ra các phần mềm có khả năng mở rộng và linh hoạt hơn.

Khi chúng ta có kiến thức về nhiều loại tổ chức, lĩnh vực và thế giới vấn đề khác nhau, chúng ta có thể tái sử dụng các yêu cầu, tái sử dụng các giả định, tái sử dụng các tính chất của lĩnh vực và nhiều hơn thế. Điều này giúp chúng ta giảm thiểu thời gian và công sức trong việc phát triển các hệ thống thông tin. Ngoài ra, kiến thức này cũng giúp chúng ta có thể dễ dàng thích nghi với các thay đổi trong môi trường và các yêu cầu mới. Vì vậy, câu trả lời đúng là "true".

Hoạt động nào không thuộc quy trình kiểm thử? Quy trình kiểm thử bao gồm các hoạt động thiết kế kiểm thử sớm, có người dùng tạo ra các kiểm thử chấp nhận, theo dõi yêu cầu đến kiểm thử, cập nhật kế hoạch khi yêu cầu thay đổi. Tuy nhiên, hoạt động không thuộc quy trình kiểm thử là thiết kế kiểm thử dựa trên yêu cầu. Thiết kế kiểm thử nên được thực hiện độc lập với yêu cầu để đảm bảo tính khách quan và toàn diện. Việc thiết kế kiểm thử dựa trên yêu cầu có thể dẫn đến kiểm thử không đầy đủ hoặc không chính xác.

Ví dụ về yêu cầu tương tự cho các nền tảng đa dạng là cơ hội tái sử dụng yêu cầu. Điều này xảy ra khi một ứng dụng được triển khai trên nhiều nền tảng khác nhau, chẳng hạn như Mac và Windows hoặc iOS và Android. Mặc dù có thể có một số khác biệt về yêu cầu chi tiết và/hoặc thiết kế giao diện người dùng dựa trên nền tảng, nhưng vẫn sử dụng một bộ yêu cầu cốt lõi. Điều này cho phép tái sử dụng các yêu cầu và giảm thiểu sự lặp lại trong quá trình phát triển phần mềm.

Một cơ hội để tái sử dụng yêu cầu quy trình kinh doanh là khi các quy trình kinh doanh thường xuyên được chia sẻ giữa các tổ chức và cần được hỗ trợ bởi phần mềm. Nhiều tổ chức duy trì một bộ mô tả quy trình kinh doanh được tái sử dụng trên các dự án IT. Ví dụ, một tổ chức có thể có quy trình kinh doanh chung cho việc quản lý nhân sự, bao gồm việc tuyển dụng, đào tạo và đánh giá hiệu suất. Phần mềm được thiết kế để hỗ trợ các quy trình kinh doanh này có thể được tái sử dụng trên các dự án khác, giảm thiểu thời gian và chi phí phát triển.

Hoạt động không thuộc về quy trình thiết kế và mã hóa là: "Trace requirements to design and code". Hoạt động này liên quan đến việc theo dõi các yêu cầu để đảm bảo chúng được thực hiện một cách chính xác trong quy trình thiết kế và mã hóa. Tuy nhiên, nó không phải là một phần của quy trình thiết kế và mã hóa chính thức. Các hoạt động khác như "Have developers review requirements", "Use quality attributes to drive architecture", "Allocate requirements to components", và "Use requirement priorities to drive process iteration" đều là các bước quan trọng trong quy trình thiết kế và mã hóa.

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

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.

Các lợi ích của việc tái sử dụng yêu cầu hiệu quả bao gồm: Tái sử dụng yêu cầu giúp giảm thời gian phát triển dự án, giảm chi phí phát triển và giảm thiểu công việc lặp lại. Điều này đạt được bằng cách sử dụng lại các yêu cầu đã được xác định trước đó trong dự án khác, từ đó giảm thiểu thời gian và chi phí phát triển. Ngoài ra, tái sử dụng yêu cầu cũng giúp giảm thiểu công việc lặp lại và cải thiện chất lượng của dự án. Điều này đạt được bằng cách sử dụng các yêu cầu đã được xác định trước đó để phát triển dự án mới, từ đó giảm thiểu công việc lặp lại và cải thiện chất lượng của dự án.

Đáp án đúng: "To save time, improve consistency, and reduce risks". Requirements reuse (tái sử dụng yêu cầu) là dùng lại những yêu cầu đã viết, đã rà soát, có khi đã kiểm chứng trên hệ thống trước, cho dự án mới; ví dụ yêu cầu bảo mật, đăng nhập, hay quy tắc nghiệp vụ chung. Lợi ích là bớt công khơi gợi và viết lại, các sản phẩm trong cùng tổ chức nhất quán hơn, và rủi ro thấp hơn vì yêu cầu đã được chứng minh chất lượng. "To eliminate stakeholder reviews" sai vì yêu cầu dùng lại vẫn phải được bên liên quan xem xét xem có phù hợp với bối cảnh mới không. "To finalize the coding phase" sai vì tái sử dụng yêu cầu thuộc phát triển yêu cầu, không nhằm chốt giai đoạn viết mã, dù đôi khi kéo theo dùng lại thiết kế và mã. "To reduce prototyping efforts" sai vì giảm làm prototype không phải mục đích chính; prototype vẫn có thể cần để thẩm định yêu cầu mới.

Khi áp dụng lại các yêu cầu đã tồn tại, hiệu suất của dự án sẽ được cải thiện đáng kể. Điều này đạt được bằng cách giảm thiểu thời gian và công sức trong quá trình thu thập yêu cầu. Khi các yêu cầu đã được xác định và áp dụng lại, các nhà phát triển có thể tập trung vào việc triển khai và kiểm tra các yêu cầu này, thay vì phải dành thời gian để thu thập và xác định chúng từ đầu. Ngoài ra, việc áp dụng lại các yêu cầu cũng giúp giảm thiểu sự phức tạp và giảm thiểu khả năng xảy ra sai sót trong quá trình triển khai.

Công cụ mà Seilevel đã phát triển để hỗ trợ việc ước tính nỗ lực phát triển yêu cầu là một bảng tính để ước tính nỗ lực yêu cầu. Bảng tính này giúp các chuyên gia yêu cầu ước tính chính xác nỗ lực cần thiết để hoàn thành các yêu cầu, từ đó giúp các nhà quản lý dự án lập kế hoạch và phân bổ nguồn lực một cách hiệu quả hơn. Bằng cách sử dụng bảng tính này, các chuyên gia yêu cầu có thể xem xét các yếu tố như mức độ phức tạp của yêu cầu, thời gian cần thiết để hoàn thành yêu cầu và các nguồn lực cần thiết để hoàn thành yêu cầu.

Tỷ lệ nhà phát triển đến phân tích kinh doanh trong dự án thông thường (default) thường được coi là 3:1. Điều này có nghĩa là một nhà phân tích kinh doanh có thể tạo ra đủ yêu cầu để giữ bảy nhà phát triển bận rộn. Tuy nhiên, tỷ lệ này có thể thay đổi tùy thuộc vào quy mô và phức tạp của dự án. Trong một số trường hợp, tỷ lệ có thể cao hơn hoặc thấp hơn 3:1. Ví dụ, trong dự án nhỏ, tỷ lệ có thể là 1:1, trong khi trong dự án lớn, tỷ lệ có thể là 6:1 hoặc thậm chí 9:1. Vì vậy, tỷ lệ 3:1 chỉ là một ước tính chung và có thể không áp dụng được cho mọi dự án.

Khi áp dụng lại các yêu cầu (requirements reuse) từ góc độ của người dùng, lợi ích chính là cải thiện sự nhất quán chức năng giữa các ứng dụng kinh doanh liên quan. Điều này giúp đảm bảo rằng các ứng dụng có thể tương tác và tích hợp với nhau một cách liền mạch, giảm thiểu sự phức tạp và tăng cường hiệu suất. Ngoài ra, việc áp dụng lại các yêu cầu cũng giúp giảm thiểu sự lặp lại và cải thiện tính nhất quán trong toàn bộ hệ thống. Điều này đặc biệt quan trọng trong các tổ chức lớn có nhiều ứng dụng và hệ thống khác nhau.

Quá trình lập kế hoạch dự án bao gồm các hoạt động liên quan đến việc lập kế hoạch và quản lý dự án. Trong các lựa chọn trên, có một hoạt động không thuộc về quá trình lập kế hoạch dự án. Đó là "Có các nhà phát triển xem xét các yêu cầu". Hoạt động này không phải là một phần của quá trình lập kế hoạch dự án, mà là một phần của quá trình kiểm tra và xác minh các yêu cầu. Quá trình lập kế hoạch dự án bao gồm các hoạt động như sử dụng yêu cầu để ước tính kích thước dự án, cập nhật kế hoạch khi yêu cầu thay đổi, sử dụng ưu tiên yêu cầu để điều khiển vòng lặp quá trình, v.v. Vì vậy, hoạt động "Có các nhà phát triển xem xét các yêu cầu" không thuộc về quá trình lập kế hoạch dự án.

Mô tả về cơ hội tái sử dụng yêu cầu bảo mật: Trong nhiều trường hợp, yêu cầu bảo mật và xác thực người dùng thường giống nhau trên các hệ thống khác nhau. Ví dụ, các hệ thống có thể có yêu cầu chung rằng tất cả sản phẩm phải có đăng nhập đơn giản sử dụng Active Directory cho xác thực người dùng. Điều này cho phép tái sử dụng yêu cầu bảo mật và giảm thiểu thời gian và chi phí phát triển. Ngoài ra, việc tái sử dụng yêu cầu bảo mật cũng giúp đảm bảo tính nhất quán và bảo mật trên toàn hệ thống.

Khi áp dụng yêu cầu tái sử dụng dựa trên quan điểm của người dùng, lợi ích chính là cải thiện sự nhất quán chức năng giữa các ứng dụng kinh doanh liên quan. Điều này có nghĩa là các ứng dụng sẽ có giao diện và chức năng tương tự nhau, giúp người dùng dễ dàng sử dụng và hiểu biết. Ngoài ra, yêu cầu tái sử dụng cũng giúp giảm thiểu sự lặp lại và cải thiện hiệu suất phát triển. Từ đó, các ứng dụng sẽ được phát triển nhanh chóng hơn và có chất lượng cao hơn.

Đáp án đúng: "A requirements effort estimation spreadsheet.". Seilevel, một công ty tư vấn chuyên về kỹ nghệ yêu cầu, xây dựng một bảng tính ước lượng công sức phát triển yêu cầu: người dùng nhập các đại lượng như số tác nhân, số quy trình nghiệp vụ, số màn hình hay số báo cáo dự kiến, bảng tính quy đổi ra số giờ cần cho khơi gợi, phân tích, đặc tả và thẩm định. Công cụ này phục vụ lập kế hoạch cho chính hoạt động phát triển yêu cầu, giúp BA và quản lý dự án dành đủ thời gian cho yêu cầu thay vì đoán mò. "A coding tool for developers." sai vì công cụ không liên quan tới viết mã, nó dùng ở giai đoạn yêu cầu. "A time-tracking tool for project managers." sai vì công cụ ghi giờ chỉ đo thời gian đã tiêu, còn bảng tính của Seilevel dự báo công sức trước khi làm. "A documentation tool for stakeholders." sai vì nó không dùng để soạn hay lưu tài liệu yêu cầu mà chỉ để ước lượng khối lượng việc.