248 câu hỏi
Tiêu chuẩn ISO-14598 đưa ra:
Đưa ra quy trình đánh giá tính an toàn cho sản phẩm phần mềm.
Đưa ra quy trình đánh giá hiệu quả của phần mềm.
Đưa ra quy trình đánh giá chất lượng cho sản phẩm phần mềm.
Đưa ra quy trình đánh giá tính khả dụng cho sản phẩm phần mềm.
Trong phát triển phần mềm, yếu tố nào quan trọng nhất?
Con người.
Quy trình.
Sản phầm.
Thời gian.
Kỹ thuật nào sau đây là xây dựng phần mềm từ các thành phần đã được thiết kế trong lĩnh vực công nghệ khác nhau?
Extreme programming.
Evolutionary prototyping.
Component architecture.
Open-source development
IEEE 830-1993 là một khuyến nghị tiêu chuẩn cho
Software requirement specification.
Software design.
Testing.
Coding.
Kỹ sư phần mềm không cần
Kiến thức về phân tích thiết kế hệ thống.
Kiến thức về cơ sở dữ liệu.
Lập trình thành thạo bằng một ngôn ngữ lập trình.
Kinh nghiệm quản lý dự án phần mềm.
Tính khả thi của phần mềm dựa vào các yếu tố sau:
Nghiệp vụ và tiếp thị.
Phạm vi, ràng buộc và thị trường.
Công nghệ, tiền bạc, thời gian và tài nguyên.
Kỹ năng và năng lực của nhà phát triển.
Phần mềm dự báo thời tiết thu thập các số liệu về nhiệt độ, độ ẩm, … xử lý tính toán để cho ra các dự báo thời tiết là 1 ví dụ của loại phần mềm:
Phần mềm hệ thống (System software)
Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)
Phần mềm thời gian thực (Real time software)
Phần mềm nghiệp vụ (Business software)
Loại phần mềm gì là 1 tập hợp các chương trình để cung cấp dịch vụ cho các chương trình khác:
Phần mềm hệ thống (System software)
Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)
Phần mềm thời gian thực (Real time software)
Phần mềm nghiệp vụ (Business software)
Phần mềm quản lý tài chính của một công ty là:
Phần mềm nghiệp vụ (Business software)
Phần mềm hệ thống (System software)
Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software)
Phần mềm thời gian thực (Real time software)
Theo một báo cáo của IBM, "31% các dự án bị hủy bỏ trước khi chúng được hoàn thành, 53% vượt dự toán trung bình 189% và cứ mỗi 100 dự án, có 94 dự án khởi động lại". Lý do nào cho số liệu thống kê trên?
Thiếu đào tạo đầy đủ về công nghệ phần mềm.
Thiếu đạo đức phần mềm và sự hiểu biết.
Quản lý các vấn đề trong công ty.
Ảnh hưởng của sự suy thoái kinh tế.
Điều nào không đúng?
Công nghệ phần mềm thuộc ngành khoa học máy tính.
Công nghệ phần mềm là một phần của ngành kỹ thuật hệ thống (System Engineering).
Khoa học máy tính thuộc ngành công nghệ phần mềm.
Công nghệ phần mềm có liên quan với việc phát triển và cung cấp các phần mềm hữu ích.
Mối quan tâm chính của công nghệ phần mềm là gì?
Sản xuất phần cứng.
Sản xuất phần mềm.
Cấu hình mạng.
Phần mềm có thể dùng lại.
Điều nào là đặc trưng của một thiết kế phần mềm tốt?
Thể hiện kết nối mạnh mẽ giữa các mô-đun của nó.
Thực hiện tất cả các yêu cầu trong mô hình phân tích.
Bao gồm các trường hợp thử nghiệm cho tất cả các thành phần
Cung cấp một bức tranh hoàn chỉnh của phần mềm.
Theo thống kê từ những thách thức đối với công nghệ phần mềm thì lỗi nhiều nhất là do
Kiểm tra và bảo trì
Phân tích yêu cầu
Thiết kế
Viết Code
Yêu cầu có thể chia ra thành các lọai nào sau đây?
Chức năng, phi chức năng, yêu cầu hệ thống.
Chức năng, phi chức năng
Chức năng, phi chức năng, yêu cầu miền ứng dụng.
Chức năng, phi chức năng, yêu cầu nghiệp vụ.
2 hình thức dùng mô tả yêu cầu là:
Yêu cầu người dùng và yêu cầu hệ thống.
Yêu cầu chức năng và yêu cầu phi chức năng.
Yêu cầu chủ động và yêu cầu thụ động.
Yêu cầu cụ thể và yêu cầu trừu tượng.
Loại khả thi nào không được xem xét trong phân tích khả thi
Khả thi về kinh tế.
Khả thi về thực hiện.
Khả thi vể kỹ thuật.
Khả thi về chất lượng .
Tính chất cần có của dữ liệu trong phân tích yêu cầu
Có định hướng thời gian.
Có giá trị pháp lý.
Tính mô tả trừu tượng
Có thể mô tả bằng toán học.
Câu hỏi nào có liên quan đến phân tích thiết kế?
Đáp án
Thời gian hoàn thành dự án có đủ không?
Làm thế nào chuyển thiết kế dữ liệu logic sang thiết kế dữ liệu vật lý?
Các xử lý nào được tiến hành và các thông tin chi tiết liên quan?
Đâu là phạm vi của hệ thống phần mềm?
Tính chất nào không cần thiết cho phân tích dữ liệu ?
Cấu trúc dữ liệu.
Đầy đủ.
Bảo mật.
Độ lớn.
Phân tích yêu cầu bao gồm 3 hoạt động theo đúng thứ tự ?
Làm tài liệu yêu cầu, làm rõ yêu cầu, xem xét yêu cầu.
Làm rõ yêu cầu, xem xét yêu cầu, làm tài liệu yêu cầu.
Xem xét yêu cầu, làm tài liệu yêu cầu, làm rõ yêu cầu.
Làm rõ yêu cầu, làm tài liệu yêu cầu, xem xét yêu cầu.
Làm rõ yêu cầu (Eliciting requirements) là
Giao tiếp với khách hàng và người sử dụng để xác định các yêu cầu của họ.
Các yêu cầu được ghi nhận lại theo nhiều hình thức.
Các yêu cầu được tổng hợp lại theo nhiều hình thức.
Xem các yêu cầu có ở tình trạng không rõ ràng?
Yêu cầu nào là yêu cầu chức năng?
Cảnh báo người dùng khi dung lượng trống trên đĩa còn 20%.
Thực hiện thao tác thêm, xem, xóa, sửa dữ liệu nghiệp vụ.
Cảnh báo ngày hệ thống bị sai.
Yêu cầu chỉnh lại ngày giờ hệ thống mỗi khi làm việc.
SRS là viết tắt của:
Software Requirement Specification.
System Requirement Specification.
Studying Requirement Specification.
Solve Requirement Specification.
Phát biểu nào sau đây là không đúng khi nói đến quá trình thu thập yêu cầu:
Yêu cầu rất khó phát hiện.
Yêu cầu rất dễ bị thay đổi.
Yêu cầu phải luôn thống nhất.
Yêu cầu luôn được biết một cách chính xác.
Kết quả của giai đoạn thu thập yêu cầu là:
Bảng ước tính chi phí dự án
Tài liệu đặc tả yêu cầu phần mềm.
Lược đồ ngữ cảnh
Lược đồ Use case và các được đồ khác.
Ai là người viết tài liệu SRS?
Người quản lý dự án.
Phân tích viên.
Lập trình viên.
Khách hàng.
Kết quả cuối cùng của giai đoạn xác định và phân tích yêu cầu là:
Tài liệu SRS.
Sơ đồ DF
D.
Sơ đồ Use case
Sơ đồ ER
D.
Mục nào sau đây không bao gồm trong tài liệu SRS?
Yêu cầu chức năng
Yêu cầu phi chức năng
Mục tiêu thực hiện
Hướng dẫn sử dụng
Loại hình đặc tả nào được dùng phổ biến trong tài liệu SRS?
Đặc tả cấu trúc dữ liệu.
Đặc tả chức năng.
Đặc tả bằng sơ đồ.
Đặc tả đối tượng.
Độ lớn (Volume) trong phân tích yêu cầu là:
Là số lượng máy tính chạy phần mềm.
Là số lượng dữ liệu phát sinh trong một chu kỳ nào đó.
Là số lượng các nghiệp vụ hệ thống phải tiến hành trong một chu kỳ nào đó.
Là số lượng người làm việc với phần mềm.
Sơ đồ nào sau đây không cần thiết trong phân tích yêu cầu?
Use Case.
Entity Relationship Diagram.
State Transition Diagram.
Activity Diagram.
Có bao nhiêu đặc trưng khi xem xét phân tich yêu cầu khả thi?
2
3
4
5
Có bao nhiêu giai đoạn trong phân tích yêu cầu?
3
4
5
6
Có bao nhiêu nguyên lý đặc tả yêu cầu?
3
5
7
8
CASE là từ viết tắt của
Cost Aided Software Engineering.
Computer Aided Software Engineering.
Control Aided Software Engineering
Computer Analyzing Software Engineering.
Kỹ thuật thu thập yêu cầu nào cần đến chuyên gia?
Interview.
Observation.
Expert
Delphi.
Kỹ thuật thu thập yêu cầu cầu nào cần đến sự nhất trí của số đông?
Prototype.
Facilitated Workshops
Observation
Questionnaires & Surveys
Mục nào không dùng cho đặc tả yêu cầu:
Đặc tả cú pháp.
Đặc tả đối tượng.
Đặc tả chức năng.
Đặc tả kỹ thuật.
Mục nào không dùng cho đặc tả yêu cầu:
Đặc tả thao tác.
Đặc tả mô hình.
Đặc tả bằng sơ đồ.
Đặc tả thuật toán.
Loại hình đặc tả nào không có?
Đặc tả hình thức.
Đặc tả phi hình thức.
Đặc tả toán học.
Đặc tả hỗn hợp.
Xác nhận yêu cầu (Requirements Validation) được tiến hành bởi
Phân tích viên và lập trình viên.
Phân tích viên và khách hàng.
Phân tích viên và các bên có liên quan.
Phân tích viên và người dùng.
Khi xác nhận yêu cầu, cần phải làm sáng tỏ các từ nào sau đây:
“một số”, “đôi khi”, “thường”, “thông thường”, “bình thường”, “phần lớn”, “đa số”.
Danh từ là số nhiều hay số ít.
Tính từ chỉ trạng thái.
Động từ ở hình thức chủ động hay bị động.
Câu hỏi không được kỹ sư phần mềm hiện nay quan tâm nữa
Tại sao chi phí phần cứng máy tính quá cao?
Tại sao phần mềm mất một thời gian dài để hoàn tất?
Tại sao người ta tốn nhiếu chi phí để phát triển một mẩu phần mềm?
Tại sao những lỗi phần mềm không được loại bỏ trong sản phẩm trước khi xuất xưởng
Mô hình phát triển ứng dụng nhanh
definition, development, support
what, how, where
programming, debugging, maintenance
analysis, design, testing
Mô hình phát triển ứng dụng nhanh
Một cách gọi khác của mô hình phát triển dựa vào thành phần
Một cách hữu dụng khi khách hàng không xàc định yêu cầu rõ ràng
Sự ráp nối tốc độ cao của mô hình tuần tự tuyến tính
Tất cả mục trên
Mô hình tiến trình phần mềm tiến hóa
Bản chất lặp
Dễ dàng điều tiết những biến đổi yêu cầu sản phẩm
Nói chung không tạo ra những sản phẩm bỏ đi
Tất cả các mục
Mô hình phát triển phần mềm lặp lại tăng thêm
Một hướng hợp lý khi yêu cầu được xác định rõ
Một hướng tốt khi cần tạo nhanh một sản phẩm thực thi lõi
Một hướng tốt nhất dùng cho những dự án có những nhóm phát triển lớn
Một mô hình cách mạng không nhưng không được dùng cho sản phẩm thương mại
Mô hình phát triển phần mềm xoắn ốc
Kết thúc với việc xuất xưởng sản phẩm phần mềm
Nhiều hỗn độn hơn với mô hình gia tăng
Bao gồm việc đánh giá những rủi ro phần mềm trong mỗi vòng lặp
Tất cả điều trên
Mô hình phát triển dựa vào thành phần
Chỉ phù hợp cho thiết kế phần cứng máy tính
Không thể hỗ trợ phát triển những thành phần sử dụng lại
Dựa vào những kỹ thuật hỗ trợ đối tượng
Không định chi phí hiệu quả bằng những độ đo phần mềm có thể định lượng
Để xây dựng mô hình hệ thống, kỹ sư phải quan tâm tới một trong những nhân tố hạn chế sau :
Những giả định và những ràng buộc
Ngân sách và phí tổn
Những đối tượng và những hoạt động
Lịch biểu và các mốc sự kiện
Trong kỹ thuật tiến trình nghiệp vụ, ba kiến trúc khác nhau được kiểm tra
Hạ tầng kỹ thuật, dữ liệu, ứng dụng
Hạ tầng tài chánh, tổ chức và truyền thông
Cấu trúc báo cáo, cơ sở dữ liệu, mạng
Cấu trúc dữ liệu, yêu cầu, hệ thống
Thành phần nào của kỹ thuật tiến trình nghiệp vụ là trách nhiệm của kỹ sư phần mềm
Phân tích phạm vi nghiệp vụ
Thiết kế hệ thống nghiệp vụ
Kế hoạch sản phẩm
Kế hoạch chiến lược thông tin
Những thành phần kiến trúc trong kỹ thuật sản phẩm là
Dữ liệu, phần cứng, phần mềm, con người
Dữ liệu, tài liệu, phần cứng, phần mềm
Dữ liệu, phần cứng, phần mềm, thủ tục
Tài liệu, phần cứng, con người, thủ tục
Đặc tả hệ thống mô tả
Chức năng và hành vi của hệ thống dựa vào máy tính
Việc thi hành của mỗi thành phần hệ thống được chỉ
Chi tiết giải thuật và cấu trúc hệ thống
Thời gian đòi hỏi cho việc giả lập hệ thống
Cách tốt nhất để đưa tới việc xem xét việc đánh giá yêu cầu là
Kiểm tra lỗi mô hình hệ thống
Nhờ khách hàng kiểm tra yêu cầu
Gởi họ tới đội thiết kế và xem họ có sự quan tâm nào không
Dùng danh sách các câu hỏi kiểm tra để kiểm tra mỗi yêu cầu
Sử dụng bảng lần vết giúp
Debug chương trình dựa theo việc phát hiện lỗi thời gian thực
Xác định việc biểu diễn những sự thi hành giải thuật
Xác định, điều khiển và theo vết những thay đổi yêu cầu
Không có mục nào
Mẫu mô hình hệ thống chứa thành phần
Input
Output
Giao diện người dùng
Tất cả mục trên
Tác vụ nào không được biểu diễn như là một phần của phân tích yêu cầu phần mềm
Định giá và tổng hợp
Mô hình hóa và thừa nhận vấn đề
Lập kế hoạch và lịch biểu
Đặc tả và xem xét
Đích của kỹ thuật đặc tả ứng dụng thuận tiện (FAST - facilitated application specification techniques) là nhờ người phát triển và khách hàng
Xây dựng một nguyên mẫu nhanh chóng
Học công việc lẫn nhau
Làm việc với nhau để phát triển một tập những yêu cầu ban đầu
Làm việc với nhau để phát triển những đặc tả phần mềm kỹ thuật
Ai là người không thích hợp để tham dự vào nhóm FAST (facilitated application specification techniques)
Kỹ sư phần cứng và phần mềm
Đại diện nhà sản xuất
Đại diện thị trường
Nhân viên tài chánh cao cấp
Những yêu cầu nào được quan tâm suốt QFD (quality function deployment)
exciting requirements
expected requirement
normal requirements
technology requirements
Phân tích giá trị được dẫn ra như là một phần của QFD (quality function deployment) nhằm xác định
Chi phí của hoạt động đảm bảo chất lượng của dự án
Chi phí quan hệ của những yêu cầu qua việc triển khai chức năng, tác vụ và thông tin
Độ ưu tiên quan hệ của những yêu cầu qua việc triển khai chức năng, tác vụ và thông tin
Kích thước của bản ý kiến khách hàng
Use-cases là một kịch bản mà mô tả
Phần mềm thực hiện như thế nào khi được dùng trong một tình huống cho trước
Những công cụ CASE sẽ được dùng như thế nào để xây dựng hệ thống
Kế hoạch xây dựng cho sản phẩm phần mềm
Những test-case cho sản phẩm phần mềm
Nội dung thông tin biểu diễn những đối tượng điều khiển và dữ liệu riêng biệt mà bao gồm những thông tin mà
Cần thiết để trình bày tất cả output
Được đòi hỏi cho việc xử lý lỗi
Được đòi hỏi cho hoạt động tạo giao diện hệ thống
Được biến đổi bởi phần mềm
Dòng thông tin biểu diễn cách thức mà dữ liệu và điều khiển
Quan hệ với một dữ liệu và điều khiển khác
Biến đổi khi mỗi lần dịch chuyển qua hệ thống
Sẽ được thực thi trong thiết kế cuối cùng
Không có mục nào
Cấu trúc thông tin biểu diển tổ chức nội của
Những cấu trúc dữ liệu dùng để biểu diễn loại dữ liệu
Mô hình bố trí nhân viên dự án
Mô hình truyền thông dự án
Những dữ liệu khác nhau và những mục điều khiển
Loại mô hình nào được tạo ra trong phân tích yêu cầu phần mềm
Chức năng và hành vi
Giải thuật và cấu trúc dữ liệu
Kiến trúc và cấu trúc
Tính tin cậy và tính sử dụng
Trong ngữ cảnh của phân tích yêu cầu, hai loại phân tách vấn đề là
bottom-up và top-down
horizontal and vertical
subordinate và superordinate
Không có mục nào
Khung nhìn (view) nào được quan tâm đầu tiên trong phân tich yêu cầu phần mềm
actor view
data view
essential view
implementation view
Tạo nguyên mẫu tiến hóa thường thích được dùng hơn tạo nguyên mẫu bỏ đi bởi vì
Cho phép tái sử dụng nguyên mẫu đầu
Không đòi hỏi làm việc nhiều với khách hàng
Dễ dành thực hiện nhanh
Nhiều tin cậy hơn
Những mục nào không là nguyên tắc cho việc biểu diễn yêu cầu
Biểu đồ phải thu hẹp về số và toàn vẹn trong sử dụng
Hình thức và nội dung biểu diễn thích hợp với nội dung
Những biểu diễn phải có thể xem xét lại
Dùng không hơn 7 màu dương và 2 màu âm trong biểu đồ
Mục nào không là một mục đích cho việc xây dựng một mô hình phân tích
Xác định một tập những yêu cầu phần mềm
Mô tả yêu cầu khách hàng
Phát triển một giải pháp tóm tắt cho vấn đề
Thiết lập một nền tảng cho thiết kế phần mềm
Sơ đồ luồng dữ liệu
Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu
Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu
Chỉ ra những quyết định logic chính khi chúng xuất hiện
Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài
Biểu đồ quan hệ thực thể
Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu
Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu
Chỉ ra những quyết định logic chính khi chúng xuất hiện
Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài
Biểu đồ dịch chuyển trạng thái
Đưa ra hình ảnh về các đối tượng dữ liệu
Đưa ra hình ảnh chức năng biến đổi luồng dữ liệu
Chỉ ra hình ảnh dữ liệu được biến đổi như thế nào bởi hệ thống
Chỉ ra những tương tác của hệ thống đối với sự kiện bên ngoài
Phân tích văn phạm của bản tường thuật xử lý là bước đầu tiên tốt nhất để tạo ra
Tự điển dữ liệu
Biểu đồ dòng dữ liệu
Biểu đồ quan hệ thực thể
Biểu đồ dịch chuyển trạng thái
Biểu đồ dòng điều khiển
Cần thiết để mô hình những hệ thống hướng sự kiện
Được đòi hỏi cho tất cả hệ thống
Được dùng trong biểu đồ dòng dữ liệu
Hữu dụng trong mô hình hóa giao diện người dùng
Từ điển dữ liệu chứa những mô tả của mỗi
Mục cấu hình phần mềm
Đối tượng dữ liệu phần mềm
Biểu đồ phần mềm
Hệ thống ký hiệu phần mềm
Mô hình thiết kế không quan tâm tới
Kiến trúc
Dữ liệu
Giao diện
Phạm vi dự án
Sự quan trọng của thiết kế phần mềm có thể được tóm tắt bằng từ đơn
Accuracy
Complexity
Efficiency
Quality
Một đặc trưng của thiết kế tốt là
Cho thấy sự liên kết mạnh giữa các module
Thực hiện tất cả yêu cầu trong phân tích
Bao gồm những test case cho tất cả thành phần
Kết hợp mã nguồn nhằm mục đích mô tả
Mục nào không là đặc trưng chung trong các phương pháp thiết kế
Quản lý cấu hình
Ký hiệu thành phần chức năng
Nguyên tắc đánh giá chất lượng
Heuristic tinh chế
Loại trừu tượng nào được dùng trong thiết kế phần mềm
Điều khiển
Dữ liệu
Thủ tục
Tất cả mục trên
Loại mô hình nào không được có trong kiến trúc phần mềm
Dữ liệu
Động
Xử lý
Cấu trúc
Cấp bậc điều khiển thể hiện
Thứ tự quyết định
Việc tổ chức của các module
Sự lặp lại của những hoạt động
Sự tuần tự của các tiến trình
Thủ tục phần mềm tập trung vào
Cấp bậc điều khiển trong một cảm nhận trừu tượng hơn
Xử lý chi tiết của mỗi module riêng biệt
Xử lý chi tiết của mỗi tập module
Quan hệ giữa điều khiển và thủ tục
Nguyên nhân của việc sinh lỗi do thiết kế mức thành phần trước khi thiết kế dữ liệu là
Thiết kế thành phần thì phụ thuộc vào ngôn ngữ còn thiết kế dữ liệu thì không
Thiết kế dữ liệu thì dễ thực hiện hơn
Thiết kế dữ liệu thì khó thực hiện
Cấu trúc dữ liệu thường ảnh hưởng tới cách thức mà thíết kế thành phần phải theo
Mục đích của tham chiếu chéo những yêu cầu (ma trận) trong tài liệu thiết kế là nhằm
Cho phép người quản lý theo dõi năng suất của nhóm thiết kế
Xác minh là tất cả các yêu cầu đã được xem xét trong thiết kế
Chỉ ra chi phí kết hợp với mỗi yêu cầu
Cung cấp cho việc thực thi tên của những nhà thiết kế cho mỗi yêu cầu
Mục nào không là một phần của kiến trúc phần mềm
Chi tiết giải thuật
Cơ sở dữ liệu
Thiết kế dữ liệu
Cấu trúc chương trình
Đặc trưng nào là đúng cho kho dữ liệu, không phải là cơ sở dữ liệu đặc trưng
Hướng mức nghiệp vụ và kích thước lớn
Thông tin đúng và hợp thời
Tích hợp và không thường thay đổi
Tất cả những mục trên
Mẫu kiến trúc nhấn mạnh tới những thành phần
Ràng buộc
Tập hợp những thành phần
Mô hình ngữ nghĩa
Tất cả những mục
Nhằm xác định những mẫu kiến trúc hay kết hợp những mẫu phù hợp nhất cho hệ thống đề nghị, kỹ thuật yêu cầu dùng để khám phá
Giải thuật phức tạp
Đặc trưng và ràng buộc
Điều khiển và dữ liệu
Những mẫu thiết kế
Tiêu chuẩn đánh giá chất lượng của một thiết kế kiến trúc phải dựa vào
Tính truy cập và tính tin cậy của hệ thống
Dữ liệu và điều khiển của hệ thống
Tính chức năng của hệ thống
Những chi tiết thực thi của hệ thống
Trong phương pháp phân tích kiến trúc, mô tả mẫu kiến trúc thường dùng khung nhìn
Dòng dữ liệu
Module
Tiến trình
Tất cả các mục trên
Khi một luồng tổng thể trong một đoạn của biểu đồ luồng dữ liệu có tính trình tự cao và theo sau những những đường thẳng sẽ thể hiện
Liên kết thấp
Module hóa tốt
Luồng giao dịch (transaction)
Luồng biến đổi (transform)
Khi luồng thông tin trong một đoạn của sơ đồ luồng dữ liệu thể hiện bằng một mục đơn mà bẩy một luồng dữ liệu khác theo một trong nhiều đường sẽ thể hiện
Liên kết thấp
Module hóa tốt
Luồng giao dịch (transaction)
Luồng biến đổi (transform)
Một bổ sung cần thiết nhằm biến đổi hay ánh xạ giao dịch để tạo một thiết kế kiến trúc đầy đủ là
Sơ đồ quan hệ - thực thể
Từ điển dữ liệu
Mô tả việc xử lý cho mỗi module
Những Test-case cho mỗi module
Những nguyên lý thiết kế giao diện nào không cho phép người dùng còn điều khiển tương tác với máy tính
Cho phép được gián đoạn
Cho phép tương tác có thể undo
Che dấu những bản chất kỹ thuật với những người dùng thường
Chỉ cung cấp một cách thức xác định cứng khi hoàn thành tác vụ
Những nguyên lý thiết kế giao diện cho phép người dùng ít phải nhớ
Xác định những shortcut trực quan
Biểu lộ thông tin theo cách diễn tiến
Thiết lập những trường hợp mặc định có ý nghĩa
Tất cả những mục trên
Sự toàn vẹn (consistency) giao diện ngầm định
Những kỹ thuật input giữ tương tự suốt ứng dụng
Mỗi ứng dụng phải có look and feel riêng biệt
Cách thức điều hướng (navigational) nhạy với ngữ cảnh
Câu a và b
Mô hình nào đưa ra hình ảnh tiền sử (profile) người dùng cuối của hệ thống dựa vào máy tính
Mô hình thiết kế
Mô hình người dùng
Mô hình của người dùng
Mô hình nhận thức hệ thống
Mô hình nào đưa ra hình ảnh hệ thống trong đầu của người dùng cuối
Mô hình thiết kế
Mô hình người dùng
Hình ảnh hệ thống
Mô hình nhận thức hệ thống
Mô hình nào đưa ra hình ảnh look and feel cho giao diện người dùng cùng những thông tin hỗ trợ
Mô hình thiết kế
Mô hình người dùng
Mô hình hình ảnh hệ thống
Mô hình nhận thức hệ thống
Những hoạt động khung nào thường không kết hợp với những quá trình thiết kế giao diện người dùng
Ước lượng giá
Xây dựng giao diện
Định trị giao diện
Phân tích người dùng và tác vụ
Hướng tiếp cận nào để những phân tích tác vụ của người dùng trong thiết kế giao diện người dùng
Người dùng cho biết những ưa thích qua bản câu hỏi
Dựa vào ý kiến của những lập trình viên có kinh nghiệm
Nghiên cứu những hệ thống tự động liên quan
Quan sát thao tác người dùng
Những vấn đề thiết kế chung nổi trội lên trong hầu hết giao diện người dùng
Kết nối tiền sử người dùng (profile) và shortcut chức năng
Xử lý lỗi và thời gian đáp ứng của hệ thống
Quyết định hiển thị hình ảnh và thiết kế icon
Không có mục nào
Những hệ thống phát triển giao diện người dùng đặc trưng cung cấp những kỹ thuật cho việc xây dựng những nguyên mẫu giao diện bao gồm
Tạo code
Những tool vẽ
Định trị input
Tất cả mục trên
Những bản câu hỏi có ý nghĩa nhất đối với những người thiết kế giao diện khi được hoàn tất bởi
Khách hàng
Những lập trình viên có kinh nghiệm
Người dùng sản phẩm
Người quản lý dự án
Nhiều đo lường hữu dụng có thể thu thập khi quan sát những người dùng tương tác với hệ thống máy tính gồm
Thời gian cho ứng dụng
Số khiếm khuyết (defect) phần mềm
Tính tin cậy của phần mềm
Thời gian đọc tài liệu trợ giúp
Một bảng quyết định được dùng
Để tư liệu tất cả những trạng thái phụ thuộc
Để hướng dẫn phát triển kế hoạch quản lý dự án
Chỉ khi xây dựng hệ chuyên gia
Khi một tập phức tạp những điều kiện và hoạt động xuất hiện trong thành phần
Ngôn ngữ thiết kế chương trình (PDL) thường là một
Sự kết hợp giữa cấu trúc lập trình và văn bản tường thuật
Ngôn ngữ lập trình truyền thống theo luật riêng của nó
Ngôn ngữ phát triển phần mềm có thể đọc bởi máy
Một cách hữu dụng để biểu diễn kiến trúc phần mềm
Những độ đo phức tạp vòng (cyclomatic complexity metriC. cung cấp cho người thiết kế thống tin về số
Chu kỳ trong chương trình
Số lỗi trong chương trình
Những đường logic độc lập trong chương trình
Những phát biểu của chương trình
Kiểm thử điều kiện là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case
Dựa vào kiểm thử đường cơ bản
Thử thách điều kiện logic trong module phần mềm
Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến
Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp
Kiểm thử luồng dữ liệu là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case
Dựa vào kiểm thử đường cơ bản
Thử thách điều kiện logic trong module phần mềm
Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến
Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp
Kiểm thử lặp là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case
Dựa vào kiểm thử đường cơ bản
Thử thách điều kiện logic trong module phần mềm
Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến
Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp
Kiểm thử Black-box cố gắng tìm ra những lỗi
Chức năng không đầy đủ hay không đúng
Những lỗi giao diện
Những lỗi thực thi
Tất cả mục trên
Lý do tốt nhất cho việc dùng nhóm kiểm tra phần mềm độc lập là
Những người phát triển phần mềm không cần làm bất kỳ kiểm thử nào
Những người lạ sẽ kiểm phần mềm rất chặt
Những người kiểm thử không được dính dáng tới dự án cho đến khi kiểm thử bắt đầu
Mâu thuẩn về quyền lợi giữa những người phát triển và những người kiểm thử sẽ giảm
Trong một dự án thành công sử dụng chiến lược
Đưa ra những xem xét kỹ thuật hình thức ưu tiên trước khi kiểm thử
Chỉ rõ những yêu cầu trong theo một cách thức có thể định lượng
Quan tâm tới việc sử dụng những nhóm kiểm thử độc lập
Tất cả mục trên
Kiểm thử tích hợp Top-down có thuận lợi chính là
Những module mức thấp không bao giờ cần kiểm thử
Những điểm quyết định chính được kiểm thử sớm
Không có những stub cần phải viết
Không có mục nào
Kiểm thử tích hợp bottom-up có những thuận lợi chính
Những điểm quyết định chính được kiểm thử sớm
Không có những driver cần được viết
Không có những stub (nhánh) cần phải viết
Không đòi hỏi kiểm thử hồi quy (regression)
Hướng debug
Backtracking
Brute force
Sự loại trừ nguyên nhân
Tất cả các mục
Những kiểm tra chấp nhận thường được đưa ra bởi
Người phát triển
Những người dùng cuối
Nhóm kiểm thử
Những kỹ sư hệ thống
Ai là người không thích hợp để tham dự vào nhóm FAST (facilitated application specification techniques)
Kỹ sư phần cứng và phần mềm
Đại diện nhà sản xuất
Đại diện thị trường
Nhân viên tài chánh cao cấp
Ba giai đoạn tổng quát của công nghệ phần mềm
definition, development, support
what, how, where
programming, debugging, maintenance
analysis, design, testing
Biểu đồ dịch chuyển trạng thái
Đưa ra hình ảnh về các đối tượng dữ liệu
Đưa ra hình ảnh chức năng biến đổi luồng dữ liệu
Chỉ ra hình ảnh dữ liệu được biến đổi như thế nào bởi hệ thống
Chỉ ra những tương tác của hệ thống đối với sự kiện bên ngoài
Biểu đồ dòng điều khiển
Cần thiết để mô hình những hệ thống hướng sự kiện
Được đòi hỏi cho tất cả hệ thống
Được dùng trong biểu đồ dòng dữ liệu
Hữu dụng trong mô hình hóa giao diện người dùng
Biểu đồ quan hệ thực thể
Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu
Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu
Chỉ ra những quyết định logic chính khi chúng xuất hiện
Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài
Cách tốt nhất để đưa tới việc xem xét việc đánh giá yêu cầu là
Kiểm tra lỗi mô hình hệ thống
Nhờ khách hàng kiểm tra yêu cầu
Gởi họ tới đội thiết kế và xem họ có sự quan tâm nào không
Dùng danh sách các câu hỏi kiểm tra để kiểm tra mỗi yêu cầu
Cấp bậc điều khiển thể hiện
Thứ tự quyết định
Việc tổ chức của các module
Sự lặp lại của những hoạt động
Sự tuần tự của các tiến trình
Câu hỏi không được kỹ sư phần mềm hiện nay quan tâm nữa
Tại sao chi phí phần cứng máy tính quá cao?
Tại sao phần mềm mất một thời gian dài để hoàn tất?
Tại sao người ta tốn nhiếu chi phí để phát triển một mẩu phần mềm?
Tại sao những lỗi phần mềm không được loại bỏ trong sản phẩm trước khi xuất xưởng
Cấu trúc thông tin biểu diển tổ chức nội của
Những cấu trúc dữ liệu dùng để biểu diễn loại dữ liệu
Mô hình bố trí nhân viên dự án
Mô hình truyền thông dự án
Những dữ liệu khác nhau và những mục điều khiển
Chất lượng sản phẩm liên quan: product operation, product transition, product revision. Thuộc tính nào liên quan tới product revision:
Reliability
Maintainability
Testability
Portability
Chỉ phát biểu sai, bộ 3 ràng buộc
Phạm vi
Thời gian
Chi phí
Chất lượng
Chỉ phát biểu sai, các nhóm phần mềm (SUB-Team):
Gồm một nhóm người
Sub-Team System analysis có nhiệm vụ ước tính lợi nhuận
Gồm một số người và nó phải tồn tại trong suốt dự án
Có thể 1 người
Chỉ phát biểu sai, để đạt được độ đo PUM thấp:
Cải tiến quy trình
Giảm lỗi giá
Gia tăng số bản bán được
Giảm thời gian sửa lỗi
Chỉ phát biểu sai. Kiểm thử áp lực
Thường áp dụng trong hệ thống phân bố
Nếu quá tải thiết kế thì không cần xem xét tới lỗi hệ thống
Có thể xem là một dạng của kiểm thử thực thi
Thử thách dựa vào tải thiết kế cực đại
Chỉ phát biểu sai, lãnh vực hỗ trợ trong quản lý dự án
Quản lý rủi ro
Quản lý mua sắm
Quản lý tích hợp
Quản lý truyền thông
Chỉ phát biểu sai. Mô hình hướng ngắt
Cho phép đáp ứng nhanh
Dễ lập trình
Ít gây ra xung đột
Thường dùng trong hệ thống thời gian thực
Chỉ phát biểu sai. Phương pháp Brute Force
“Để máy tính tìm ra lỗi”
Gần giống với phương pháp “vét cạn”
Là một phương pháp hiệu quả
Thường lặp đi lặp lại thủ tục đơn giản nhiều lần
Chỉ phát biểu sai. Thiết kế dữ liệu ở mức thành phần:
Thiết kế cơ sở dữ liệu
Hiện thực thuộc tính dữ liệu thành cấu trúc dữ liệu
Phát triển một tập những trừu tượng dữ liệu
Tinh chế các đối tượng dữ liệu
Chỉ phát biểu sai. V & V (Verification and Validation)
Đánh giá hệ thống có tính sử dụng hay không
Liên quan tới vấn đề debug và bảo mật
Nó và kiểm thử là hai lãnh vực riêng
Nhằm kiểm tra phần mềm phải thực hiện những gì người dùng thực sự cần
Chỉ ra mục sai. Trong mô hình WebE trong mô hình phân tích có
Phân tích nội dung
Phân tích cấu hình
Phân tích tương tác
Phân tích điều hướng (naviation)
Chỉ ra phát biểu sai. Help:
Có nhiều điểm vào nên người dùng có thể vào hệ thống help từ nhiều nơi
Help! Nghĩa là “Help. I’m in trouble”
Help như một số tay hướng dẫn on-line
Những chỉ báo cho biết vị trí của người dùng trong hệ thống help
Chỉ ra phát biểu sai. Quá trình kiểm nghiệm phần mềm
Phải có khả năng tìm ra lỗi cao
Phải có tính chọn lọc
Nhằm xác định phần mềm không có lỗi
Không nên dư thừa và quá phức tạp
Chọn 5 hoạt động chính, tổng quát trong quá trình xây dựng phần mềm
Giao tiếp, lập kế hoạch, mô hình hóa, xây dựng, triển khai
Phân tích, thiết kế, lập trình, gỡ lỗi, bảo trì
Không có mục nào
Giao tiếp, quản lý rủi ro, ước lượng, sản xuất, kiểm tra lại
Có mấy loại vòng lặp
4
3
2
5
Công nghệ Web có những đặc điểm
Nó thường dùng mô hình gia tăng (incremental process model)
Thời gian chuyển giao sản phẩm rất nhanh
Những thay đổi (change) diễn ra nhanh chóng
Nó là một công nghệ mới, nó cần phải tách xa công nghệ trước đây
Dòng thông tin biểu diễn cách thức mà dữ liệu và điều khiển
Quan hệ với một dữ liệu và điều khiển khác
Biến đổi khi mỗi lần dịch chuyển qua hệ thống
Sẽ được thực thi trong thiết kế cuối cùng
Không có mục nào
Đặc điểm nào sau đây được sử dụng để đánh giá một bản thiết kế tốt?
Thể hiện tất cả các yêu cầu trong pha phân tích
Chứa cả các trường hợp kiểm thử của tất cả các thành phần
Cung cấp một mô tả hoàn thiện về phần mềm
Câu a và c
Đặc tả hệ thống mô tả
Chức năng và hành vi của hệ thống dựa vào máy tính
Việc thi hành của mỗi thành phần hệ thống được chỉ
Chi tiết giải thuật và cấu trúc hệ thống
Thời gian đòi hỏi cho việc giả lập hệ thống
Đặc trưng nào là đúng cho kho dữ liệu, không phải là cơ sở dữ liệu đặc trưng
Hướng mức nghiệp vụ và kích thước lớn
Thông tin đúng và hợp thời
Tích hợp và không thường thay đổi
Tất cả những mục trên
Để xây dựng mô hình hệ thống, kỹ sư phải quan tâm tới một trong những nhân tố hạn chế sau:
Những giả định và những ràng buộc
Ngân sách và phí tổn
Những đối tượng và những hoạt động
Lịch biểu và các mốc sự kiện
Đích của kỹ thuật đặc tả ứng dụng thuận tiện (FAST - facilitated application specification techniques) là nhờ người phát triển và khách hàng
Xây dựng một nguyên mẫu nhanh chóng
Học công việc lẫn nhau
Làm việc với nhau để phát triển một tập những yêu cầu ban đầu
Làm việc với nhau để phát triển những đặc tả phần mềm kỹ thuật
Độ đo chất lượng của việc khử lỗi là tỷ số của
Số lần giải quyết trong tháng và tổng số vấn đề phát sinh trong tháng
Số lần bảo trì vượt thời gian quy định và tổng số lần bảo trì
Tát cả đều đúng
Số lần sai lầm trong việc sửa lỗi và tổng số lần sửa lỗi
FP (Function Point) là
Độ đo sản phẩm cuối
Độ đo năng suất phần mềm hướng kích thước
Tất cả đều sai
Độ đo năng suất phần mềm hướng chức năng
Hình thức kiểm nghiệm tích hợp hướng đối tượng
Kiểm nghiệm trên cơ sở thread
Kiểm nghiệm trên cơ sở sử dụng
Câu A, B đúng
Câu A, B sai
Hướng debug
Backtracking
Brute force
Sự loại trừ nguyên nhân
Tất cả các mục
Hướng tiếp cận nào để những phân tích tác vụ của người dùng trong thiết kế giao diện người dùng
Người dùng cho biết những ưa thích qua bản câu hỏi
Dựa vào ý kiến của những lập trình viên có kinh nghiệm
Nghiên cứu những hệ thống tự động liên quan
Quan sát thao tác người dùng
Khả năng được chấp nhận trong các yêu cầu đối với phần mềm
Là tính tin cậy
Tất cả đều sai
Là sự chấp nhận được về giao diện
Là sự phù hợp với yêu cầu người sử dụng
Khi luồng thông tin trong một đoạn của sơ đồ luồng dữ liệu thể hiện bằng một mục đơn mà bẩy một luồng dữ liệu khác theo một trong nhiều đường sẽ thể hiện
Liên kết thấp
Module hóa tốt
Luồng giao dịch (transaction)
Luồng biến đổi (transform)
Khi một luồng tổng thể trong một đoạn của biểu đồ luồng dữ liệu có tính trình tự cao và theo sau những những đường thẳng sẽ thể hiện
Liên kết thấp
Module hóa tốt
Luồng giao dịch (transaction)
Luồng biến đổi (transform)
Khung nhìn (view) nào được quan tâm đầu tiên trong phân tich yêu cầu phần mềm
actor view
data view
essential view
implementation view
Kiểm nghiệm hướng đối tượng thường dùng
Kiểm nghiệm tích hợp đối tượng
Kiểm nghiệm hộp đen
Kiểm nghiệm thừa kế
Kiểm nghiệm hộp trắng
Kiểm nghiệm tích hợp module
Có thể tích hợp từ trên xuống dưới
Tát cả đều đúng
Có thể tích hợp từ dưới lên theo cách tích hợp theo chiều ngang
Có thể tích hợp từ dưới lên theo cách tích hợp theo chiều sâu
Kiểm thử Black-box cố gắng tìm ra những lỗi
Chức năng không đầy đủ hay không đúng
Những lỗi giao diện
Những lỗi thực thi
Tất cả mục trên
Kiểm thử điều kiện là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case
Dựa vào kiểm thử đường cơ bản
Thử thách điều kiện logic trong module phần mềm
Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến
Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp
Kiểm thử lặp là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case
Dựa vào kiểm thử đường cơ bản
Thử thách điều kiện logic trong module phần mềm
Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến
Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp
Kiểm thử luồng dữ liệu là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case
Dựa vào kiểm thử đường cơ bản
Thử thách điều kiện logic trong module phần mềm
Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến
Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp
Kiểm thử tích hợp bottom-up có những thuận lợi chính
Những điểm quyết định chính được kiểm thử sớm
Không có những driver cần được viết
Không có những stub (nhánh) cần phải viết
Không đòi hỏi kiểm thử hồi quy (regression)
Kiểm thử tích hợp Top-down có thuận lợi chính là
Những module mức thấp không bao giờ cần kiểm thử
Những điểm quyết định chính được kiểm thử sớm
Không có những stub cần phải viết
Không có mục nào
Kiểm thử vòng lặp lồng nhau
Tất cả đều đúng
Khi xét vòng lặp nào thì cần test Min+1, typical, max-1
Kiểm thử từ ngoài vào trong
Nếu các vòng lặp là độc lập thì xem như là vòng lặp đơn
Liên kết (Coupling) là một chỉ báo chất lượng cho biết mức độ mà module
Tập trung vào chỉ một điều
Kết nối với module khác và môi trường bên ngoài
Có thể hoàn thành chức năng của nó trong một cách thức phù hợp về thời gian
Có thể được viết với sự rắn chắc nhiều hơn
Loại mô hình nào được tạo ra trong phân tích yêu cầu phần mềm
Chức năng và hành vi
Giải thuật và cấu trúc dữ liệu
Kiến trúc và cấu trúc
Tính tin cậy và tính sử dụng
Loại mô hình nào không được có trong kiến trúc phần mềm
Dữ liệu
Động
Xử lý
Cấu trúc
Loại trừu tượng nào được dùng trong thiết kế phần mềm
Điều khiển
Dữ liệu
Thủ tục
Tất cả mục trên
Lý do tốt nhất cho việc dùng nhóm kiểm tra phần mềm độc lập là
Những người phát triển phần mềm không cần làm bất kỳ kiểm thử nào
Những người lạ sẽ kiểm phần mềm rất chặt
Những người kiểm thử không được dính dáng tới dự án cho đến khi kiểm thử bắt đầu
Mâu thuẩn về quyền lợi giữa những người phát triển và những người kiểm thử sẽ giảm
Mật độ lỗi (defect density) thuộc độ đo
Độ đo chất lượng sản phẩm cuối
Độ đo quá trình sản xuất
Độ đo dự án phần mềm
Độ đo chất lượng bảo trì
Mẫu kiến trúc nhấn mạnh tới những thành phần
Ràng buộc
Tập hợp những thành phần
Mô hình ngữ nghĩa
Tất cả những mục
Mẫu mô hình hệ thống chứa thành phần
Input
Output
Giao diện người dùng
Tất cả mục trên
Milestone
Thường có output là những word product
Là thời điểm cuối của một hoạt động xử lý
Có thể chuyển giao một két quả của dự án
Tất cả đều đúng
Mô hình nào đưa ra hình ảnh hệ thống trong đầu của người dùng cuối
Mô hình thiết kế
Mô hình người dùng
Hình ảnh hệ thống
Mô hình nhận thức hệ thống
Mô hình nào đưa ra hình ảnh look and feel cho giao diện người dùng cùng những thông tin hỗ trợ
Mô hình thiết kế
Mô hình người dùng
Mô hình hình ảnh hệ thống
Mô hình nhận thức hệ thống
Mô hình nào đưa ra hình ảnh tiền sử (profile) người dùng cuối của hệ thống dựa vào máy tính
Mô hình thiết kế
Mô hình người dùng
Mô hình của người dùng
Mô hình nhận thức hệ thống
Mô hình phát triển dựa vào thành phần
Chỉ phù hợp cho thiết kế phần cứng máy tính
Không thể hỗ trợ phát triển những thành phần sử dụng lại
Dựa vào những kỹ thuật hỗ trợ đối tượng
Không định chi phí hiệu quả bằng những độ đo phần mềm có thể định lượng
Mô hình phát triển phần mềm dựa trên mẫu thử là
Một mô hình rất rủi ro, khó đưa ra được một sản phẩm tốt
Phương pháp tốt nhất được sử dụng trong các dự án có nhiều thành viên
Một phương pháp hữu ích khi khách hàng không thể xác định yêu cầu một cách rõ ràng
Một phương pháp thích hợp được sử dụng khi các yêu cầu đã được xác định rõ ràng
Mô hình phát triển phần mềm lặp lại tăng thêm
Một hướng hợp lý khi yêu cầu được xác định rõ
Một hướng tốt khi cần tạo nhanh một sản phẩm thực thi lõi
Một hướng tốt nhất dùng cho những dự án có những nhóm phát triển lớn
Một mô hình cách mạng không nhưng không được dùng cho sản phẩm thương mại
Mô hình phát triển phần mềm tuần tự tuyến tính còn gọi là
Mô hình hỗn độn
Mô hình nước suối
Mô hình xoắn ốc
Mô hình chu kỳ sống cổ điển
Mô hình phát triển phần mềm xoắn ốc
Kết thúc với việc xuất xưởng sản phẩm phần mềm
Nhiều hỗn độn hơn với mô hình gia tăng
Bao gồm việc đánh giá những rủi ro phần mềm trong mỗi vòng lặp
Tất cả điều trên
Mô hình phát triển ứng dụng nhanh
Một cách gọi khác của mô hình phát triển dựa vào thành phần
Một cách hữu dụng khi khách hàng không xàc định yêu cầu rõ ràng
Sự ráp nối tốc độ cao của mô hình tuần tự tuyến tính
Tất cả mục trên
Mô hình thiết kế không quan tâm tới
Kiến trúc
Dữ liệu
Giao diện
Phạm vi dự án
Mô hình tiến trình phần mềm tiến hóa
Bản chất lặp
Dễ dàng điều tiết những biến đổi yêu cầu sản phẩm
Nói chung không tạo ra những sản phẩm bỏ đi
Tất cả các mục
Một bảng quyết định được dùng
Để tư liệu tất cả những trạng thái phụ thuộc
Để hướng dẫn phát triển kế hoạch quản lý dự án
Chỉ khi xây dựng hệ chuyên gia
Khi một tập phức tạp những điều kiện và hoạt động xuất hiện trong thành phần
Một bổ sung cần thiết nhằm biến đổi hay ánh xạ giao dịch để tạo một thiết kế kiến trúc đầy đủ là
Sơ đồ quan hệ - thực thể
Từ điển dữ liệu
Mô tả việc xử lý cho mỗi module
Những Test-case cho mỗi module
Một đặc trưng của thiết kế tốt là
Cho thấy sự liên kết mạnh giữa các module
Thực hiện tất cả yêu cầu trong phân tích
Bao gồm những test case cho tất cả thành phần
Kết hợp mã nguồn nhằm mục đích mô tả
Mục đích của tham chiếu chéo những yêu cầu (ma trận) trong tài liệu thiết kế là nhằm
Cho phép người quản lý theo dõi năng suất của nhóm thiết kế
Xác minh là tất cả các yêu cầu đã được xem xét trong thiết kế
Chỉ ra chi phí kết hợp với mỗi yêu cầu
Cung cấp cho việc thực thi tên của những nhà thiết kế cho mỗi yêu cầu
Mục nào không là đặc trưng chung trong các phương pháp thiết kế
Quản lý cấu hình
Ký hiệu thành phần chức năng
Nguyên tắc đánh giá chất lượng
Heuristic tinh chế
Mục nào không là một mẫu kiến trúc (pattern)? Mẫu
Concurrency
Persistence
Distribution
Borker
Mục nào không là một mục đích cho việc xây dựng một mô hình phân tích
Xác định một tập những yêu cầu phần mềm
Mô tả yêu cầu khách hàng
Phát triển một giải pháp tóm tắt cho vấn đề
Thiết lập một nền tảng cho thiết kế phần mềm
Mục nào không là một phần của kiến trúc phần mềm
Chi tiết giải thuật
Cơ sở dữ liệu
Thiết kế dữ liệu
Cấu trúc chương trình
Mục nào không phải là một loại kiến trúc (style): kiến trúc
Luồng dữ liệu
Kiến trúc ngữ cảnh
Gọi trả về
Tầng
Mục nào liên quan tới phân tích người dùng:
Mô hình hệ thống của người dùng
Trong tình huống đặc trưng thì người dùng thực hiện công việc gì?
Những feedback từ việc đánh giá của người dùng
Nếu người dùng xảy ra lỗi thì hậu quả như thế nào?
Ngôn ngữ thiết kế chương trình (PDL) thường là một
Sự kết hợp giữa cấu trúc lập trình và văn bản tường thuật
Ngôn ngữ lập trình truyền thống theo luật riêng của nó
Ngôn ngữ phát triển phần mềm có thể đọc bởi máy
Một cách hữu dụng để biểu diễn kiến trúc phần mềm
Nguyên nhân của việc sinh lỗi do thiết kế mức thành phần trước khi thiết kế dữ liệu là
Thiết kế thành phần thì phụ thuộc vào ngôn ngữ còn thiết kế dữ liệu thì không
Thiết kế dữ liệu thì dễ thực hiện hơn
Thiết kế dữ liệu thì khó thực hiện
Cấu trúc dữ liệu thường ảnh hưởng tới cách thức mà thíết kế thành phần phải theo
Nhằm xác định những mẫu kiến trúc hay kết hợp những mẫu phù hợp nhất cho hệ thống đề nghị, kỹ thuật yêu cầu dùng để khám phá
Giải thuật phức tạp
Đặc trưng và ràng buộc
Điều khiển và dữ liệu
Những mẫu thiết kế
Nhiều đo lường hữu dụng có thể thu thập khi quan sát những người dùng tương tác với hệ thống máy tính gồm
Thời gian cho ứng dụng
Số khiếm khuyết (defect) phần mềm
Tính tin cậy của phần mềm
Thời gian đọc tài liệu trợ giúp
Những bản câu hỏi có ý nghĩa nhất đối với những người thiết kế giao diện khi được hoàn tất bởi
Khách hàng
Những lập trình viên có kinh nghiệm
Người dùng sản phẩm
Người quản lý dự án
Những độ đo phức tạp vòng (cyclomatic complexity metriC. cung cấp cho người thiết kế thống tin về số
Chu kỳ trong chương trình
Số lỗi trong chương trình
Những đường logic độc lập trong chương trình
Những phát biểu của chương trình
Những gì làm cho khó đưa ra những yêu cầu
Hiểu rõ những yêu cầu người dùng
Sự thay đổi
Tất cả các mục
Phạm vi, giới hạn
Những hệ thống phát triển giao diện người dùng đặc trưng cung cấp những kỹ thuật cho việc xây dựng những nguyên mẫu giao diện bao gồm
Tạo code
Những tool vẽ
Định trị input
Tất cả mục trên
Những hoạt động khung nào thường không kết hợp với những quá trình thiết kế giao diện người dùng
Ước lượng giá
Xây dựng giao diện
Định trị giao diện
Phân tích người dùng và tác vụ
Những kiểm tra chấp nhận thường được đưa ra bởi
Người phát triển
Những người dùng cuối
Nhóm kiểm thử
Những kỹ sư hệ thống
Những mục nào không là nguyên tắc cho việc biểu diễn yêu cầu
Biểu đồ phải thu hẹp về số và toàn vẹn trong sử dụng
Hình thức và nội dung biểu diễn thích hợp với nội dung
Những biểu diễn phải có thể xem xét lại
Dùng không hơn 7 màu dương và 2 màu âm trong biểu đồ
Những nguyên lý thiết kế giao diện cho phép người dùng ít phải nhớ
Xác định những shortcut trực quan
Biểu lộ thông tin theo cách diễn tiến
Thiết lập những trường hợp mặc định có ý nghĩa
Tất cả những mục trên
Những nguyên lý thiết kế giao diện nào không cho phép người dùng còn điều khiển tương tác với máy tính
Cho phép được gián đoạn
Cho phép tương tác có thể undo
Che dấu những bản chất kỹ thuật với những người dùng thường
Chỉ cung cấp một cách thức xác định cứng khi hoàn thành tác vụ
Những thành phần kiến trúc trong kỹ thuật sản phẩm là
Dữ liệu, phần cứng, phần mềm, con người
Dữ liệu, tài liệu, phần cứng, phần mềm
Dữ liệu, phần cứng, phần mềm, thủ tục
Tài liệu, phần cứng, con người, thủ tục
Những yêu cầu nào được quan tâm suốt QFD (quality function deployment)
exciting requirements
expected requirement
normal requirements
technology requirements
Những vấn đề thiết kế chung nổi trội lên trong hầu hết giao diện người dùng
Kết nối tiền sử người dùng (profile) và shortcut chức năng
Xử lý lỗi và thời gian đáp ứng của hệ thống
Quyết định hiển thị hình ảnh và thiết kế icon
Không có mục nào
Nội dung thông tin biểu diễn những đối tượng điều khiển và dữ liệu riêng biệt mà bao gồm những thông tin mà
Cần thiết để trình bày tất cả output
Được đòi hỏi cho việc xử lý lỗi
Được đòi hỏi cho hoạt động tạo giao diện hệ thống
Được biến đổi bởi phần mềm
Phân tích giá trị được dẫn ra như là một phần của QFD (quality function deployment) nhằm xác định
Chi phí của hoạt động đảm bảo chất lượng của dự án
Chi phí quan hệ của những yêu cầu qua việc triển khai chức năng, tác vụ và thông tin
Độ ưu tiên quan hệ của những yêu cầu qua việc triển khai chức năng, tác vụ và thông tin
Kích thước của bản ý kiến khách hàng
Phân tích văn phạm của bản tường thuật xử lý là bước đầu tiên tốt nhất để tạo ra
Tự điển dữ liệu
Biểu đồ dòng dữ liệu
Biểu đồ quan hệ thực thể
Biểu đồ dịch chuyển trạng thái
Sơ đồ luồng dữ liệu
Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu
Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu
Chỉ ra những quyết định logic chính khi chúng xuất hiện
Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài
Sử dụng bảng lần vết giúp
Debug chương trình dựa theo việc phát hiện lỗi thời gian thực
Xác định việc biểu diễn những sự thi hành giải thuật
Xác định, điều khiển và theo vết những thay đổi yêu cầu
Không có mục nào
Sự quan trọng của thiết kế phần mềm có thể được tóm tắt bằng từ đơn
Accuracy
Complexity
Efficiency
Quality
Sự toàn vẹn (consistency) giao diện ngầm định
Những kỹ thuật input giữ tương tự suốt ứng dụng
Mỗi ứng dụng phải có look and feel riêng biệt
Cách thức điều hướng (navigational) nhạy với ngữ cảnh
Câu a và b
Tác vụ nào không được biểu diễn như là một phần của phân tích yêu cầu phần mềm
Định giá và tổng hợp
Mô hình hóa và thừa nhận vấn đề
Lập kế hoạch và lịch biểu
Đặc tả và xem xét
Tài liệu nào sau đây sẽ được tạo ra trong pha thiết kế hệ thống?
Kế hoạch kiểm thử
Mã lệnh
Thiết kế chi tiết
Lập kế hoạch
Tạo nguyên mẫu tiến hóa thường thích được dùng hơn tạo nguyên mẫu bỏ đi bởi vì
Cho phép tái sử dụng nguyên mẫu đầu
Không đòi hỏi làm việc nhiều với khách hàng
Dễ dành thực hiện nhanh
Nhiều tin cậy hơn
Thành phần nào của kỹ thuật tiến trình nghiệp vụ là trách nhiệm của kỹ sư phần mềm
Phân tích phạm vi nghiệp vụ
Thiết kế hệ thống nghiệp vụ
Kế hoạch sản phẩm
Kế hoạch chiến lược thông tin
Theo Boris Beizer, thiết kế Testcase cần theo ràng buộc (contraint)
Theo một cách thức đầy đủ
Tất cả đều đúng
Nỗ lực và thời gian là tối thiểu
Nhằm khám phá lỗi
Theo chiến thuật kiểm nghiệm phổ biến, kiểm nghiệm tính năng tương quan với
Phân tích toàn bộ hệ thống
Thiết kế
Phân tích yêu cầu
Mã hóa
Thủ tục phần mềm tập trung vào
Cấp bậc điều khiển trong một cảm nhận trừu tượng hơn
Xử lý chi tiết của mỗi module riêng biệt
Xử lý chi tiết của mỗi tập module
Quan hệ giữa điều khiển và thủ tục
Tiêu chuẩn đánh giá chất lượng của một thiết kế kiến trúc phải dựa vào
Tính truy cập và tính tin cậy của hệ thống
Dữ liệu và điều khiển của hệ thống
Tính chức năng của hệ thống
Những chi tiết thực thi của hệ thống
Tiêu chuẩn ISO để hướng dẫn thực hiện cho lĩnh vực phần mềm là
ISO 9001
Tất cả đều sai
ISO 15288
ISO 9000-3
Trong biểu diễn lịch biểu dự án Critical path là đường
Là một đường duy nhất
Có thời gian ngắn nhất
Có thời gian dài nhất
Tất cả đều đúng phụ thuộc vào dự án
Trong độ đo hiệu quả khử lỗi DRE, số lỗi tiềm tàng là
Tất cả đều sai
Số lỗi do khách hàng phát hiện
Toàn bộ lỗi được phát hiện sau đó
Toàn bộ lỗi chưa phát hiện
Trong kỹ thuật tiến trình nghiệp vụ, ba kiến trúc khác nhau được kiểm tra
Hạ tầng kỹ thuật, dữ liệu, ứng dụng
Hạ tầng tài chánh, tổ chức và truyền thông
Cấu trúc báo cáo, cơ sở dữ liệu, mạng
Cấu trúc dữ liệu, yêu cầu, hệ thống
Trong mô hình CMM (Software Capability Maturity Model) có mấy mức độ trưởng thành
5 mức độ
4 mức độ
6 mức độ
3 mức độ
Trong mô hình phân tích thành phần dựa vào kịch bản (Scenario based element) được dùng cho
Thiết kế kiến trúc
Thiết kế thành phần
Thiết kế giao diện
Thiết kế dữ liệu/class
Trong một dự án thành công sử dụng chiến lược
Đưa ra những xem xét kỹ thuật hình thức ưu tiên trước khi kiểm thử
Chỉ rõ những yêu cầu trong theo một cách thức có thể định lượng
Quan tâm tới việc sử dụng những nhóm kiểm thử độc lập
Tất cả mục trên
Trong ngữ cảnh của phân tích yêu cầu, hai loại phân tách vấn đề là
bottom-up và top-down
horizontal and vertical
subordinate và superordinate
Không có mục nào
Trong nhận diện rủi ro, việc không đáp ứng về lịch biểu thuộc loại rủi ro
Về con người
Về ước lượng
Về yêu cầu
Về tổ chức
Trong phương pháp phân tích kiến trúc, mô tả mẫu kiến trúc thường dùng khung nhìn
Dòng dữ liệu
Module
Tiến trình
Tất cả các mục trên
Trong tích hợp module, gom cụm (cluster) được dùng trong
Tích hợp từ dưới lên
Tích hợp big-bang
Tích hợp từ trên xuống
Tích hợp tăng vòng
Từ điển dữ liệu chứa những mô tả của mỗi
Mục cấu hình phần mềm
Đối tượng dữ liệu phần mềm
Biểu đồ phần mềm
Hệ thống ký hiệu phần mềm
Use-cases là một kịch bản mà mô tả
Phần mềm thực hiện như thế nào khi được dùng trong một tình huống cho trước
Những công cụ CASE sẽ được dùng như thế nào để xây dựng hệ thống
Kế hoạch xây dựng cho sản phẩm phần mềm
Những test-case cho sản phẩm phần mềm
Vấn đề nào sau đây liên quan chính đến pha thiết kế?
Khả thi
Dữ liệu
Tất cả các mục
Phạm vi dự án
Xét đường độc lập cơ bản, nếu có 7 node phân nhánh thì ta có số đường thực thi cơ bản độc lập là
8
7
9
6