Font size
WorksheetsQuiz về quy trình ICONIX
Total questions: 118
Worksheet time: 1hrs 9mins
ICONIX Process tập trung vào giai đoạn nào trong vòng đời phát triển phần mềm?
Lập kế hoạch dự án
Kiểm thử phần mềm
Phân tích và thiết kế
Quản lý dự án
ICONIX Process là phương pháp tiếp cận nào?
Phương pháp tối giản nhưng hoạt động
Phương pháp nhanh chóng
Phương pháp tuần tự
Phương pháp xoắn ốc
Yêu cầu chức năng trả lời cho câu hỏi nào?
Làm thế nào để thiết kế hệ thống?
Hệ thống được triển khai như thế nào?
Hệ thống có thể làm gì?
Ai sẽ là người sử dụng hệ thống?
Bốn sơ đồ chính sử dụng trong quy trình ICONIX là sơ đồ nào?
Use case, robustness, state và class diagrams
Use case, robustness, sequence và class diagrams
Use case, component, sequence và class diagrams
Use case, robustness, domain model và class diagrams
Quy trình ICONIX phù hợp với những loại dự án nào?
Dự án chỉ tập trung vào kết quả là chương trình
Các dự án quy mô vừa và nhỏ, trong đó các yêu cầu tương đối rõ ràng và ổn định
Dự án cần nhiều tài liệu chi tiết
Dự án chỉ tập trung vào kết quả là mã nguồn
Đối với quy trình ICONIX, bước nào là quan trọng nhất để đảm bảo yêu cầu và thiết kế đồng nhất với nhau?
Kiểm thử tích hợp
Viết mã nguồn
Đánh giá thiết kế sơ bộ (PDR)
Kiểm thử đơn vị
Trong quy trình ICONIX, hoạt động nào giúp làm rõ và loại bỏ sự mơ hồ trong yêu cầu hệ thống?
Kiểm thử đơn vị
Vẽ sơ đồ lớp
Viết mã nguồn
Phân tích độ bền (robustness analysis)
Việc sử dụng sơ đồ trình tự (sequence diagram) trong quy trình ICONIX nhằm mục đích gì?
Để xác định các yêu cầu không chức năng
Để phân tích tính bảo mật của hệ thống
Để phân tích tính khả thi của dự án
Để phân bổ hành vi cho các lớp đối tượng
Trong quy trình ICONIX, tại sao cần thực hiện đánh giá thiết kế sơ bộ (Preliminary Design Review)?
Trong quy trình ICONIX, tại sao cần thực hiện đánh giá thiết kế sơ bộ (Preliminary Design Review)?
Để xác định tất cả các lỗi trong mã nguồn
Để đảm bảo mô hình miền và use case khớp nhau
Để kiểm thử toàn bộ hệ thống
Để kiểm tra tính chính xác của mô hình dữ liệu
Khi cần liên kết giữa các use case và các đối tượng trong hệ thống, ta sử dụng sơ đồ nào trong quy trình ICONIX?
Sơ đồ miền (domain model)
Sơ đồ trình tự (sequence diagram)
Sơ đồ use case
Sơ đồ độ bền (robustness diagram)
Thông tin nào trong sơ đồ trình tự được dùng để bổ sung vào sơ đồ lớp?
Thông điệp
Đối tượng thực thể
Đối tượng biên
Tác nhân
Khi cần kiểm tra việc tích hợp hệ thống dựa trên các use case trong ICONIX Process, ta nên bắt đầu từ đâu?
Kiểm tra kịch bản chính và các kịch bản thay thế
Kiểm tra giao diện người dùng
Viết mã nguồn cho tất cả các chức năng
Kiểm tra cơ sở dữ liệu
Ta cần làm gì để đảm bảo rằng quá trình phân tích trong quy trình ICONIX tạo ra thiết kế có thể thực hiện được?
Kiểm thử toàn bộ hệ thống
Phát triển sơ đồ lớp
Viết mã nguồn ngay lập tức
Thực hiện phân tích độ bền (robustness analysis) để xác định các đối tượng cần thiết
Mục tiêu chính của buổi đánh giá thiết kế quan trọng (CDR) là gì?
Đánh giá các yêu cầu hệ thống
Kiểm thử mã nguồn
Xác định các sơ đồ lớp
Kiểm tra tính nhất quán giữa thiết kế và yêu cầu
Trong quá trình phát triển phần mềm, nếu có sự thay đổi về yêu cầu, bước nào trong ICONIX Process có thể giúp thích ứng với thay đổi đó?
Kiểm thử toàn bộ hệ thống
Thay đổi mô hình lớp
Viết mã nguồn mới
Cập nhật sơ đồ trình tự và thiết kế chi tiết
Quy trình ICONIX bao gồm bao nhiêu sơ đồ UML cốt lõi?
14
6
Câu hỏi chính mà quy trình ICONIX muốn trả lời là gì?
Làm thế nào để lập trình hướng đối tượng
Làm thế nào để đi từ người dùng đến sản phẩm
Làm thế nào để sử dụng được hết các loại sơ đồ UML
Làm thế nào để có thể đi từ use case đến mã nguồn
Quy trình ICONIX giúp thu hẹp khoảng cách giữa lý thuyết và thực tế như thế nào?
Phát triển hệ thống dựa trên mô hình UML đầy đủ
Liên kết các use case với các đối tượng trong hệ thống
Chuyển đổi nhanh từ yêu cầu thành mã nguồn mà không qua phân tích
Tập trung vào thiết kế trực tiếp từ mã nguồn
Sự khác biệt chính giữa yêu cầu chức năng và yêu cầu hành vi trong quy trình ICONIX là gì?
Yêu cầu chức năng miêu tả cách hệ thống hoạt động, còn yêu cầu hành vi miêu tả giao diện người dùng
Yêu cầu chức năng mô tả những gì hệ thống cần làm, còn yêu cầu hành vi mô tả cách hệ thống và người dùng tương tác
Yêu cầu chức năng mô tả chi tiết các lớp đối tượng, còn yêu cầu hành vi mô tả dữ liệu hệ thống
Cả hai đều là các bước đầu tiên của quá trình phân tích hệ thống
Làm thế nào để một sơ đồ độ bền giúp liên kết use case với mô hình đối tượng?
Tạo ra các đối tượng giao diện (GUI)
Xác định các đối tượng miền và các thông điệp truyền giữa chúng
Liệt kê tất cả các yêu cầu chức năng
Xác định các lỗi tiềm ẩn trong thiết kế
Sau khi hoàn thành giai đoạn phân tích và thiết kế sơ bộ, nếu phát hiện sự khác biệt giữa use case và sơ đồ lớp, ta sẽ xử lý như thế nào?
Bỏ qua sự khác biệt
Thực hiện kiểm thử đơn vị
Cập nhật sơ đồ lớp và use case để đảm bảo chúng khớp với nhau
Kiểm tra mã nguồn
ơ đồ lớp, ta sẽ xử lý như thế nào?
Bỏ qua sự khác biệt
Thực hiện kiểm thử đơn vị
Cập nhật sơ đồ lớp và use case để đảm bảo chúng khớp với nhau
Kiểm tra mã nguồn
Khi thực hiện sơ đồ trình tự, điều gì cần được xem xét đầu tiên để đảm bảo thiết kế đúng?
Các yêu cầu phi chức năng
Sơ đồ lớp
Các bảng cơ sở dữ liệu
Các đối tượng biên và thực thể từ sơ đồ độ bền
Khi nào ta cần thực hiện đánh giá thiết kế chi tiết (Critical Design Review) trong quy trình ICONIX ?
Trước khi thiết kế sơ đồ lớp
Sau khi kiểm thử đơn vị
Sau khi viết mã nguồn
Sau khi hoàn thành sơ đồ trình tự và cập nhật mô hình tĩnh
Tại sao quy trình ICONIX được coi là phù hợp với các dự án theo phương pháp phát triển Agile?
Nó cho phép lặp lại và phản hồi nhanh chóng dựa trên từng use case
Nó tập trung vào việc phát triển toàn bộ hệ thống ngay từ đầu
Nó yêu cầu một kế hoạch chi tiết và nghiêm ngặt từ đầu đến cuối
Nó không cần mô hình hóa các yêu cầu
Việc điều chỉnh mô hình miền trong ICONIX xảy ra khi nào?
Sau khi kiểm thử tích hợp
Trong quá trình kiểm thử đơn vị
Chỉ sau khi viết mã
Khi phát hiện các đối tượng mới trong quá trình thiết kế
Quy trình ICONIX cố gắng giải quyết vấn đề gì trước đây?
Thiếu mô tả chức năng của mã nguồn
Thiếu tài liệu mô tả hệ thống
Thiếu sự chi tiết trong các mô hình
Cồng kềnh và nhiều thứ không cần thiết trong dự án thực tế
Trong quy trình ICONIX, các yêu cầu hành vi được mô tả như thế nào?
Thông qua các bảng cơ sở dữ liệu
Thông qua use case mô tả cách người dùng và hệ thống tương tác
Thông qua mô hình lớp
Thông qua mô hình dữ liệu
Khi cần kiểm tra việc tích hợp hệ thống dựa trên các use case trong ICONIX Process, ta nên bắt đầu từ đâu?
Kiểm tra cơ sở dữ liệu
Viết mã nguồn cho tất cả các chức năng
Khi cần kiểm tra việc tích hợp hệ thống dựa trên các use case trong ICONIX Process, ta nên bắt đầu từ đâu?
Kiểm tra cơ sở dữ liệu
Viết mã nguồn cho tất cả các chức năng
Kiểm tra kịch bản chính và các kịch bản thay thế
Kiểm tra giao diện người dùng
Trong quy trình ICONIX, các yêu cầu hành vi được mô tả như thế nào?
Thông qua mô hình dữ liệu
Thông qua mô hình lớp
Thông qua use case mô tả cách người dùng và hệ thống tương tác
Thông qua các bảng cơ sở dữ liệu
Trong quá trình kiểm thử đơn vị, các bài kiểm thử được viết dựa trên:
Sơ đồ lớp
Kịch bản chính từ sơ đồ trình tự
Use case và các controllers từ sơ đồ độ bền
Mô hình miền
Mô hình miền được minh họa như thế nào?
Như một sơ đồ hoạt động (activity diagram).
Như một sơ đồ triển khai (deployment diagram).
Như một sơ đồ trình tự (sequence diagram).
Như một sơ đồ lớp (class diagram) đơn giản với các đường nối giữa các lớp.
Mô hình miền hiển thị loại quan hệ nào giữa các lớp trong miền?
Quan hệ tổng hợp (aggregation) và tổng quát hóa (generalization).
Quan hệ phụ thuộc (dependency relationships).
Quan hệ đồng thời (concurrent relationships).
Quan hệ tuần tự (sequential relationships).
Mô hình miền đại diện cho phần nào của hệ thống?
Phần tĩnh mô tả cấu trúc của hệ thống.
Phần động mô tả hành vi của hệ thống.
Mô tả các trường hợp sử dụng chi tiết.
Chỉ mô tả các giao diện người dùng.
Mô hình miền là cơ sở đầu tiên cho việc xây dựng sơ đồ nào trong quy trình ICONIX?
Sơ đồ trình tự
Sơ đồ use case
Sơ đồ mạnh mẽ
Sơ đồ hoạt động
Tại sao nên bắt đầu với mô hình miền (domain model) trước khi viết use case?
Vì nó giúp ràng buộc use case vào thực tế và hệ thống sẽ được thiết kế.
Vì use case nên được viết trước để định nghĩa chi tiết.
Tại sao nên bắt đầu với mô hình miền (domain model) trước khi viết use case?
Vì nó giúp ràng buộc use case vào thực tế và hệ thống sẽ được thiết kế.
Vì use case nên được viết trước để định nghĩa chi tiết.
Vì use case không liên quan đến mô hình miền.
Vì mô hình miền phức tạp hơn và nên được thực hiện trước.
Tại sao không nên kỳ vọng sơ đồ lớp cuối cùng sẽ khớp chính xác với mô hình miền?
Vì sơ đồ lớp không quan trọng
Vì mô hình miền đơn giản hơn và không chứa các chi tiết thiết kế cụ thể
Vì sơ đồ lớp chỉ là mô hình tạm thời
Vì mô hình miền không liên quan đến sơ đồ lớp
Khi mô hình miền có quá nhiều mối quan hệ giữa các lớp, ta nên làm gì để cải thiện?
Bỏ bớt các lớp
Giữ nguyên và tiếp tục
Thêm nhiều lớp hơn để giải thích
Sử dụng quan hệ tổng quát hóa (generalization) để đơn giản hóa mối quan hệ
Nếu phát hiện mô hình miền thiếu một số đối tượng quan trọng, ta nên làm gì?
Bỏ qua những đối tượng này
Xây dựng lại mô hình từ đầu
Tạo một sơ đồ mới
Cập nhật mô hình miền để bao gồm các đối tượng bị thiếu
Quan hệ "has-a" trong mô hình miền là loại quan hệ gì?
Tổng quát hóa
Tập hợp (aggregation)
Kế thừa
Quan hệ một-nhiều
Nếu phát hiện hai thuật ngữ "Book" và "Books" trong mô hình miền, bước tiếp theo bạn nên làm gì?
Thêm thuộc tính cho cả hai
Xác định và loại bỏ sự trùng lặp, giữ lại một trong hai thuật ngữ
Giữ lại cả hai thuật ngữ
Tạo lớp mới cho mỗi thuật ngữ
Tại sao khi tạo mô hình miền, cần tập trung vào các đối tượng trong thế giới thực?
Vì phần mềm nên được thiết kế sao cho giống với cách thế giới thực hoạt động, và thế giới thực thay đổi ít thường xuyên hơn so với yêu cầu phần mềm.
Vì nó giúp tránh sử dụng quá nhiều tài nguyên trong quá trình phát triển phần mềm.
Vì các đối tượng trong thế giới thực đơn giản hơn các đ
Mối quan hệ nào sau đây là đúng khi nói về các mối quan hệ trong mô hình miền?
Mối quan hệ giữa các lớp không quan trọng trong mô hình miền.
Tất cả các mối quan hệ trong mô hình miền đều là các mối quan hệ tuần tự.
Mối quan hệ tổng quát hóa (is-a) chỉ thể hiện một lớp cha có nhiều lớp con.
Mối quan hệ tổng hợp (has-a) thể hiện một đối tượng sở hữu một đối tượng khác và mối quan hệ tổng quát hóa (is-a) thể hiện sự kế thừa giữa các lớp.
Mục tiêu của phiên tạo mô hình miền ban đầu là gì?
Tạo ra mô hình hoàn chỉnh mà không cần sửa đổi sau này.
Xây dựng một phiên bản sơ bộ để có thể điều chỉnh trong quá trình làm việc.
Tìm ra các lỗi phần mềm trong hệ thống.
Hoàn thiện mô hình miền ngay từ đầu.
Sơ đồ miền nào dưới đây là đúng?
C.
Sơ đồ miền nào dưới đây là đúng
B.
Mục tiêu chính của mô hình miền là gì?
Để xác định các yêu cầu phi chức năng
Giúp tạo ra một ngôn ngữ chung để truyền đạt thông tin rõ ràng giữa các thành viên dự án
Để thiết kế cơ sở dữ liệu
Để xây dựng mô hình dữ liệu chính xác
Mô hình miền khác gì so với bảng thuật ngữ dự án (project glossary)?
Mô hình miền chỉ sử dụng trong giai đoạn kiểm thử dự án.
Mô hình miền chỉ chứa thông tin về các lớp (classes) trong dự án.
Mô hình miền là một biểu đồ được minh họa, hiển thị mối quan hệ giữa các thuật ngữ.
Mô hình miền không có mối quan hệ với bảng thuật ngữ dự án
Trong mô hình miền, tại sao không nên nhầm lẫn giữa đối tượng và bảng cơ sở dữ liệu?
(a)
Trong mô hình miền, tại sao không nên nhầm lẫn giữa đối tượng và bảng cơ sở dữ liệu?
Vì bảng cơ sở dữ liệu chứa nhiều khóa ngoài
Vì các đối tượng phức tạp hơn bảng dữ liệu
Vì bảng cơ sở dữ liệu không có quan hệ với các đối tượng
Vì đối tượng đại diện cho một thể hiện duy nhất, trong khi bảng cơ sở dữ liệu đại diện cho một tập hợp
Lý do nên bắt đầu với mô hình miền thay vì use case là gì?
Vì use case không cần phải rõ ràng ngay từ đầu
Để tiết kiệm thời gian
Vì mô hình miền dễ thực hiện hơn
Để đảm bảo use case được viết trong bối cảnh của mô hình đối tượng và tránh sự mơ hồ
Vai trò của mô hình miền trong quá trình phát triển hệ thống là gì?
Để đảm bảo giao tiếp rõ ràng, nhất quán giữa các thành viên dự án
Để mô hình hóa cơ sở dữ liệu
Để kiểm thử hệ thống
Để tối ưu hóa mã nguồn
Lợi ích của việc tổ chức mô hình miền dựa trên các trừu tượng trong thế giới thực là gì?
Giúp giảm bớt tài liệu yêu cầu.
Làm cho mô hình khó thay đổi hơn khi yêu cầu thay đổi.
Giúp tăng tốc độ triển khai hệ thống.
Giúp mô hình bền vững hơn trước những thay đổi của yêu cầu phần mềm.
Điểm khác biệt chính giữa một đối tượng và một bảng cơ sở dữ liệu là gì?
Một đối tượng đại diện cho một tập hợp các bản ghi, trong khi bảng đại diện cho một bản ghi duy nhất.
Một đối tượng luôn chứa nhiều thuộc tính hơn bảng cơ sở dữ liệu.
Bảng cơ sở dữ liệu không liên quan gì đến đối tượng trong mô hình miền.
Một đối tượng đại diện cho một thể hiện đơn lẻ, trong khi bảng cơ sở dữ liệu đại diện cho một tập hợp các bản ghi.
Mô hình miền (domain model) trong quy trình ICONIX là gì?
Là "từ điển" thuật ngữ trong dự án
Là sơ đồ quy trình nghiệp vụ
Là một bảng dữ liệu quan hệ
Mô hình miền (domain model) trong quy trình ICONIX là gì?
Là "từ điển" thuật ngữ trong dự án
Là sơ đồ quy trình nghiệp vụ
Là một bảng dữ liệu quan hệ
Là một bản thiết kế cơ sở dữ liệu
Ý nghĩa của các mối quan hệ "has-a" và "is-a" trong mô hình miền là gì?
Chúng chỉ áp dụng cho các lớp giao diện (interfaces).
Chúng không có trong mô hình miền.
Chúng mô tả cách các lớp chứa các lớp khác và các lớp được kế thừa.
Chúng là các mối quan hệ giữa các thuộc tính của lớp.
Mối quan hệ nào dưới đây là ví dụ về quan hệ "is-a"?
Quyển Sách có Mục Lục
Mục Đơn Hàng thuộc Giỏ Hàng
Con Mèo là một Loài Động Vật
Người Dùng có Tài Khoản
Quá trình nào giúp phát hiện các đối tượng bị thiếu trong mô hình miền sau khi phiên tạo mô hình ban đầu hoàn thành?
Kiểm thử hệ thống.
Phân tích mã nguồn.
Triển khai hệ thống.
Phân tích use case và sơ đồ độ bền (robustness diagrams).
Sơ đồ miền nào dưới đây là đúng?
Nguyên tắc nào đúng khi nói về quan hệ giữa các đối tượng trong mô hình miền?
Không sử dụng quan hệ tổng quát hóa (is-a) và tổng hợp (has-a)
Chỉ sử dụng các quan hệ tuần tự để kết nối các đối tượng
Tránh sử dụng bất kỳ quan hệ nào để giữ mô hình đơn giản.
Sử dụng quan hệ tổng quát hóa (is-a) và tổng hợp (has-a) để thể hiện cách các đối tượng liên quan với nhau.
Tại sao việc xây dựng mô hình miền ban đầu chỉ nên kéo dài khoảng 2 giờ?
Vì thời gian giới hạn của dự án
Vì chỉ có các yêu cầu chức năng quan trọng
Vì không cần mô hình lớp chi tiết
Vì mô hình miền sẽ được cập nhật liên tục trong quá trình dự án
Use case là gì trong quy trình ICONIX?
Một sơ đồ thể hiện các mối quan hệ giữa các lớp trong hệ thống.
Một cách có cấu trúc để ghi lại các yêu cầu hành vi của hệ thống.
Use case là gì trong quy trình ICONIX?
Một sơ đồ thể hiện các mối quan hệ giữa các lớp trong hệ thống.
Một cách có cấu trúc để ghi lại các yêu cầu hành vi của hệ thống.
Một công cụ kiểm thử phần mềm tự động.
Một báo cáo tài chính liên quan đến chi phí phát triển.
Use case cung cấp điều gì cho quá trình thiết kế hệ thống?
Một danh sách các công cụ cần sử dụng trong dự án.
Một cách để dự đoán lỗi trong phần mềm.
Một phương pháp để viết tài liệu dự án theo cách tổng quát.
Một nền tảng để thiết kế và ước tính thời gian, công sức một cách đáng tin cậy.
Mục tiêu của use case trong quy trình hướng đối tượng là gì?
Để làm tài liệu trừu tượng về yêu cầu.
Để tạo một tài liệu mô tả toàn bộ quá trình phát triển.
Là bước đầu tiên trong việc thiết kế hướng đối tượng và để nhanh chóng đạt được mã chất lượng cao.
Để xác định chi tiết các cấu trúc dữ liệu trong cơ sở dữ liệu.
Yêu cầu chức năng (functional requirements) thường là gì?
Một sơ đồ thể hiện các đối tượng trong hệ thống.
Một mô hình các trường hợp sử dụng của hệ thống.
Một tập hợp các yêu cầu cao và thấp cấp từ nhiều nguồn, thường được ghi lại liên tiếp trong một tài liệu Word.
Một tài liệu đầy đủ chi tiết về thiết kế hệ thống.
Tại sao không nên thiết kế, lập trình, hoặc ước tính trực tiếp từ tài liệu yêu cầu chức năng (functional specification)?
Vì tài liệu yêu cầu chức năng chỉ dành cho nhóm quản lý.
Vì thiết kế trực tiếp từ tài liệu yêu cầu chức năng giống như chơi trò "chọn số ngẫu nhiên", cần có thêm bước khám phá để làm rõ yêu cầu.
Vì tài liệu yêu cầu chức năng thường có nhiều lỗi.
Vì tài liệu yêu cầu chức năng không liên quan đến quá trình thiết kế phần mềm.
Trong quá trình viết use case, điều gì cần được chú ý nhất?
Xác định yêu cầu phi chức năng
Tạo ra nhiều
Trong quá trình viết use case, điều gì cần được chú ý nhất?
Xác định yêu cầu phi chức năng
Tạo ra nhiều sơ đồ lớp
Sử dụng các thuật ngữ rõ ràng và nhất quán với mô hình miền
Viết mã nguồn trực tiếp từ use case
Khi xây dựng use case, việc tổ chức use case với các tác nhân (actors) có mục đích gì?
Để đảm bảo tính toàn vẹn của hệ thống
Để làm rõ vai trò của từng người dùng và chức năng tương ứng họ thực hiện
Để tối ưu hóa mã nguồn
Để phân tích mô hình dữ liệu
Khi mô hình miền và use case không khớp nhau, bạn nên làm gì?
Kiểm tra lại mô hình dữ liệu
Làm việc lại với khách hàng để thu thập thêm yêu cầu
Cập nhật mô hình miền hoặc use case để đảm bảo sự khớp nhau
Bỏ qua sự không khớp
Khi hệ thống gặp lỗi trong quá trình kiểm thử và không thực hiện đúng theo use case, bước tiếp theo là gì?
Thay đổi yêu cầu ban đầu
Tạo thêm các sơ đồ trạng thái
Chỉnh sửa mã nguồn để phản ánh đúng hành vi trong use case
Xây dựng lại hệ thống từ đầu
Khi phát hiện một đối tượng không được mô tả trong use case nhưng có liên quan đến hệ thống, bạn sẽ làm gì?
Thêm đối tượng vào use case và mô hình miền
Chỉ thay đổi mô hình miền
Xóa bỏ đối tượng
Bỏ qua đối tượng này
Khi viết use case, tại sao cần tránh sử dụng câu bị động?
Để dễ dàng viết mã nguồn
Để đảm bảo rõ ràng ai đang thực hiện hành động và hệ thống phản hồi như thế nào
Để giảm bớt sự phức tạp trong thiết kế
Để mô tả hệ thống theo yêu cầu
Tại sao nên xây dựng mô hình miền ban đầu trước khi viết use case?
Để tránh phải sửa đổi mô hình miền sau khi phân tích use case
Để mô tả chi tiết tất cả các tương tác giữa người dùng và hệ thống ngay từ đầu.
Để đảm bảo mô hình miền hoàn chỉnh ngay từ đầu
Theo quy trình ICONIX, tại sao mô hình miền ban đầu thường được coi là không hoàn chỉnh?
Vì không thể bao gồm tất cả các chức năng trong mô hình đầu tiên.
Vì tất cả các yêu cầu đều phải được xác định rõ ràng trước khi bắt đầu xây dựng mô hình miền
Vì mô hình miền ban đầu chỉ là một bản sơ bộ và sẽ được cải thiện dần qua quá trình phân tích use case.
Vì mô hình miền ban đầu không liên quan đến use case.
Hãy tạo một mô hình miền ban đầu cho một hệ thống bán sách trực tuyến. Bạn sẽ chọn những thực thể nào và tại sao?
Chọn tất cả các thực thể có thể xuất hiện trong hệ thống, để không bỏ sót thông tin nào.
Chọn các thực thể liên quan đến hệ thống thanh toán và giao hàng, vì đó là phần quan trọng nhất trong hệ thống bán sách.
Chọn các thực thể như Sách, Tác giả, và Giỏ hàng, vì đây là các thực thể chính của hệ thống bán sách trực tuyến và phù hợp với nhu cầu người dùng.
Chọn các thực thể liên quan đến quản trị hệ thống, vì nó giúp đảm bảo hệ thống vận hành đúng cách.
Viết một đoạn văn bản mô tả một "sunny-day scenario" cho chức năng Đăng nhập trong hệ thống bán hàng trực tuyến, sử dụng cấu trúc "noun-verb-noun".
Người dùng vào trang đăng nhập, kiểm tra thông tin và đăng nhập thành công.
Hệ thống hiển thị màn hình đăng nhập.
Người dùng nhập mật khẩu và đăng nhập thành công.
Người dùng nhập tên đăng nhập và mật khẩu, sau đó nhấn nút Đăng nhập. Hệ thống xác thực thông tin và đăng nhập người dùng.
Use case giúp trả lời câu hỏi nào liên quan đến hệ thống?
Use case giúp trả lời câu hỏi nào liên quan đến hệ thống?
Sự phân bổ nguồn lực phát triển trong dự án.
Cách hệ thống lưu trữ dữ liệu trong cơ sở dữ liệu.
Hệ thống sẽ được triển khai như thế nào?
Người dùng của hệ thống đang cố gắng làm gì và trải nghiệm người dùng ra sao?
Vai trò của use case trong việc bổ sung cho yêu cầu chức năng là gì?
Để lập danh sách các lỗi tiềm ẩn trong hệ thống.
Để cung cấp một phương pháp có cấu trúc giúp ghi lại các yêu cầu hành vi, hỗ trợ quá trình thiết kế.
Để thay thế hoàn toàn tài liệu yêu cầu chức năng.
Để xác định các trường hợp thử nghiệm phần mềm.
Trong ngữ cảnh của use case, "rainy-day scenario" là gì?
Một kịch bản mô tả các tính năng hiệu năng của hệ thống.
Một kịch bản mô tả giao diện người dùng.
Một kịch bản mô tả cách hệ thống hoạt động trong các tình huống không mong muốn hoặc khi người dùng sử dụng các tính năng ít phổ biến.
Một kịch bản mô tả cách người dùng sử dụng hệ thống trong điều kiện lý tưởng.
Tại sao việc viết use case nên tập trung vào sự tương tác giữa người dùng và hệ thống?
Để tạo sơ đồ trạng thái
Để mô tả rõ ràng các hành vi cần thiết mà hệ thống phải thực hiện
Để xác định các lỗi trong hệ thống
Để đảm bảo tính an toàn của hệ thống
Tại sao việc viết use case theo cấu trúc "noun-verb-noun" lại quan trọng?
Để dễ dàng mô hình hóa cơ sở dữ liệu
Để viết mã nguồn trực tiếp
Để tạo ra một thiết kế hướng đối tượng dễ dàng từ use case
Để tạo sơ đồ lớp
Nếu phát hiện ra một yêu cầu mới trong quá trình viết use case, bạn sẽ làm gì?
Thay đổi toàn bộ thiết kế hệ thống
Cập nhật use case để bao gồm yêu cầu mới
Bỏ qua yêu cầu này
Viết mã nguồn
Nếu phát hiện ra một yêu cầu mới trong quá trình viết use case, bạn sẽ làm gì?
Thay đổi toàn bộ thiết kế hệ thống
Cập nhật use case để bao gồm yêu cầu mới
Bỏ qua yêu cầu này
Viết mã nguồn cho yêu cầu này
Nếu mô hình miền thay đổi trong quá trình phát triển, điều gì cần thực hiện với use case?
Bỏ qua mô hình miền
Cập nhật use case để phù hợp với mô hình miền mới
Tạo sơ đồ trình tự mới
Thay đổi mô hình lớp
Trong quá trình viết use case, bạn phát hiện hệ thống cần phản hồi khi người dùng nhập sai mật khẩu. Hãy mô tả một "rainy-day scenario" cho tình huống này.
Hệ thống chấp nhận mọi đầu vào và cho phép người dùng đăng nhập.
Hệ thống không phản hồi gì và yêu cầu người dùng nhập lại thông tin.
Hệ thống chuyển người dùng đến trang chính.
Hệ thống hiển thị thông báo lỗi "Mật khẩu không đúng" và yêu cầu người dùng nhập lại mật khẩu.
Yếu tố nào sau đây giúp ích đáng kể trong việc xác định use case?
Tạo storyboards và nguyên mẫu (UI mockups, demo chức năng cơ bản).
Viết tài liệu quản lý dự án.
Thực hiện kiểm thử hiệu năng.
Phân tích cấu trúc cơ sở dữ liệu.
Tại sao việc ghi nhận các "rainy-day scenarios" (kịch bản không mong muốn) lại quan trọng khi viết use case?
Vì các kịch bản này giúp xác định những tính năng không cần thiết trong hệ thống.
Vì các kịch bản này không ảnh hưởng đến cách hệ thống hoạt động trong thực tế.
Vì các kịch bản này chỉ hữu ích trong giai đoạn kiểm thử hệ thống.
Vì các kịch bản này cung cấp thông tin về cách hệ thống cần phản hồi khi có lỗi hoặc khi người dùng tương tác với các tính năng ít được sử dụng, đảm bảo hệ thống hoạt động toàn diện và ổn định.
Mục đích chính của use case là gì?
Thể hiện cấu trúc dữ liệu của hệ thống.
Giúp nắm bắt các yêu cầu hành vi của hệ thống để tạo ra thiết kế.
Mục đích chính của use case là gì?
Thể hiện cấu trúc dữ liệu của hệ thống.
Giúp nắm bắt các yêu cầu hành vi của hệ thống để tạo ra thiết kế.
Tạo ra một danh sách các lỗi tiềm ẩn trong hệ thống.
Tìm ra cấu trúc tĩnh của hệ thống
Điều gì làm cho yêu cầu chức năng (functional requirements) trở thành bước đầu tiên trong quá trình thu thập yêu cầu?
Vì yêu cầu chức năng thay thế hoàn toàn các trường hợp sử dụng.
Vì yêu cầu chức năng cung cấp một bản thiết kế chi tiết của hệ thống
Vì yêu cầu chức năng chỉ bao gồm các yêu cầu kỹ thuật.
Vì yêu cầu chức năng là tập hợp các yêu cầu ban đầu từ các bên liên quan, giúp xác định các yêu cầu hành vi cần làm rõ hơn.
Trong quá trình viết use case, nếu người dùng thực hiện một hành động không dự đoán trước, bạn sẽ làm gì?
Bỏ qua yêu cầu hành vi này
Yêu cầu người dùng không thực hiện hành vi đó
Thêm vào "rainy-day scenario" trong use case để mô tả hành vi này
Thay đổi mô hình miền
Điều gì xảy ra với mô hình miền khi các use case được phát triển?
Mô hình miền sẽ giữ nguyên và không thay đổi.
Mô hình miền sẽ được cập nhật và cải thiện liên tục dựa trên thông tin và thay đổi từ use case.
Use case sẽ thay thế hoàn toàn mô hình miền.
Mô hình miền sẽ chỉ được sử dụng lại khi hệ thống hoàn thành.
Khi viết use case, điều gì cần được lưu ý ngoài kịch bản chính (sunny-day scenario)?
Tập trung vào tài liệu kỹ thuật thay vì các tình huống sử dụng thực tế.
Phân tích các kịch bản thay thế (rainy-day scenarios) để mô tả cách hệ thống phản ứng khi xảy ra lỗi hoặc khi người dùng sử dụng các tính năng ít phổ biến.
Chỉ cần tập trung vào kịch bản chính mà không cần các kịch bản khác.
Chỉ viết về cách hệ thống hoạt động trong điều kiện tối ưu.
Ai cần tham gia vào buổi đánh giá yêu cầu?
(a)
Ai cần tham gia vào buổi đánh giá yêu cầu?
Chỉ đội ngũ phát triển.
Nhóm quản lý dự án.
Đại diện khách hàng, người dùng cuối, nhân viên marketing, và các bên liên quan khác.
Chỉ các lập trình viên.
Lợi ích của việc liên kết use case với mô hình miền là gì?
Loại bỏ các lớp dư thừa trong thiết kế.
Tăng tốc độ phát triển giao diện người dùng.
Giảm độ phức tạp của mã nguồn.
Đảm bảo rằng các mô tả use case phù hợp với các đối tượng trong miền.
Nguyên tắc nào là quan trọng nhất khi xây dựng mô hình miền?
Bao quát ít nhất 80% các khái niệm quan trọng từ miền vấn đề.
Đảm bảo rằng tất cả các đối tượng đều được triển khai chi tiết.
Chỉ sử dụng ngôn ngữ kỹ thuật.
Bao gồm tất cả các khía cạnh kỹ thuật.
Lợi ích của việc sử dụng ngôn ngữ chủ động trong mô tả use case là gì?
Loại bỏ hoàn toàn các yêu cầu chức năng.
Làm cho các yêu cầu rõ ràng hơn và dễ hiểu hơn.
Hạn chế số lượng lỗi khi mã hóa.
Giảm thời gian viết tài liệu.
Tại sao việc mời đại diện khách hàng tham gia buổi đánh giá yêu cầu lại quan trọng?
Để tăng cường mối quan hệ giữa khách hàng và nhà phát triển.
Để xác định chi phí thực hiện dự án.
Để đảm bảo rằng yêu cầu hệ thống phản ánh chính xác nhu cầu thực tế của khách hàng.
Để tiết kiệm thời gian hoàn thành dự án.
Điều gì sẽ xảy ra nếu các yêu cầu chức năng bị lẫn vào văn bản mô tả use case?
Đơn giản hóa quá trình kiểm thử.
Gây nhầm lẫn khi phân tích và thiết kế.
Tăng tính rõ ràng của tài liệu.
Tăng tính linh hoạt khi cập nhật yêu cầu.
Khi mô tả các bước trong use case, tại sao cần liên kết các bước này với các đối tượng miền?
Khi mô tả các bước trong use case, tại sao cần liên kết các bước này với các đối tượng miền?
Để tăng tính trừu tượng của tài liệu.
Để tránh sử dụng các thuật ngữ không cần thiết.
Để đảm bảo rằng mô hình miền hỗ trợ trực tiếp các yêu cầu của hệ thống
Để giảm bớt số lượng các bước.
Việc sử dụng giao diện người dùng (GUI) giúp cải thiện đặc tả use case như thế nào?
Loại bỏ nhu cầu sử dụng sơ đồ use case.
Làm rõ hành vi của người dùng và phản hồi của hệ thống.
Giảm thời gian phát triển giao diện.
Tăng khả năng tái sử dụng của các yêu cầu chức năng.
Việc xác định các liên kết "is-a" và "has-a" trong mô hình miền có vai trò gì?
Tăng tính chính xác trong việc mô tả các mối quan hệ giữa các đối tượng.
Làm giảm độ phức tạp của hệ thống.
Loại bỏ nhu cầu tạo các lớp đối tượng.
Đảm bảo rằng các yêu cầu được đáp ứng đầy đủ.
Trong buổi đánh giá yêu cầu, tại sao cần tạo nguyên mẫu (prototype) cho giao diện người dùng?
Để xác minh rằng các yêu cầu được thể hiện đúng trong thiết kế giao diện.
Để giảm chi phí phát triển.
Để tăng số lượng các yêu cầu được xử lý.
Để tạo tài liệu thiết kế chi tiết hơn.
Làm thế nào việc truy vết (traceability) các yêu cầu đến các use case giúp ích cho dự án?
Đảm bảo rằng mọi yêu cầu đều được thực hiện và kiểm tra
Giảm nhu cầu kiểm tra hệ thống.
Tăng độ chi tiết của mô hình miền.
Giảm thời gian viết các use case.
Tại sao việc đặt tên rõ ràng cho các đối tượng trong mô hình miền lại quan trọng?
Để tăng tốc độ hoàn thành mô hình.
Để đơn giản hóa tài liệu hóa hệ thống.
Để giúp khách hàng dễ hiểu hơn về các yêu cầu.
Để đảm bảo rằng các lập trình viên hiểu rõ vai trò của từng đối tượng.
Vai trò của việc tạo các nguyên mẫu giao diện (prototypes) trong buổi đánh giá yêu cầu là gì?
Để tập trung vào các yêu cầu trừu tượng hơn.
Để xây dựng các chức năng phức tạp hơn.
Để xác định các hành vi người dùng mà tài liệu chưa nêu rõ.
Để giảm chi phí phát triển phần mềm.
Bạn đang thực hiện đánh giá một use case, nhưng mô tả quá trừu tượng và khó hiểu. Bạn sẽ làm gì để cải thiện tài liệu?
Sử dụng các từ ngữ chuyên môn để làm tăng tính chuyên sâu của tài liệu.
Cụ thể hóa các hành động của người dùng và phản hồi của hệ thống bằng cách sử dụng giọng chủ động
Bỏ qua các phần trừu tượng và tập trung vào giao diện người dùng.
Chuyển đổi toàn bộ văn bản sang dạng bảng biểu.
Trong quá trình đánh giá, khách hàng phàn nàn rằng hệ thống không đáp ứng được yêu cầu của họ, mặc dù yêu cầu đã được phê duyệt trước đó. Bạn sẽ xử lý thế nào?
Chuyển yêu cầu đến nhóm phát triển mà không thay đổi gì.
Loại bỏ ý kiến của khách hàng vì không phù hợp với giai đoạn hiện tại.
Tạm dừng dự án và yêu cầu khách hàng cung cấp yêu cầu mới.
Thực hiện lại buổi đánh giá yêu cầu với khách hàng để tìm ra sự khác biệt và cập nhật tài liệu.
Mục đích của buổi xem xét yêu cầu (requirements review session) là gì?
Để đảm bảo rằng hệ thống được mô tả khớp với các yêu cầu.
Để thiết kế giao diện người dùng cho hệ thống.
Để kiểm tra tính khả thi của các yêu cầu kỹ thuật.
Để đánh giá khả năng mở rộng của hệ thống.
