Đề cương thiết kế và xây dựng phần mềm

1 Nêu khái niệm phân tích thiết kế phần mềm (Software analysis and development) Thiết kế phần mềm bao gồm chu trình từ xác định kiến trúc, thành phần, giao diện nhân tố khác hệ thống hay thành phần đó, lẫn kết chu trình đó(định nghĩa IEEE ) 2.Phân biệt khái niệm Phương pháp luận (methodologies) Kỹ thuật (technique) Methodologies(Phương pháp luận) Technique(kĩ thuật) - Phương pháp chung(cách tiếp cận) để tạo phần mềm - Hiện có hai luồng phương pháp luận: + Structured Methodology(phương pháp cấu trúc)- (SSADM phân tích cấu trúc phương pháp thiết kế…) + Object Oriented Methodology(phương pháp hướng đối tượng)(OOA/OOD…) - Phương pháp cụ thể giai đoạn phương pháp luận, thực cụ thể phương pháp luận VD: SSADM: dùng kĩ thuật chủ yếu: mơ hình liệu logic, mơ hình luồng liệu, mơ hình ứng xử thực thể OOA/OOD: UML - Được thiết kế để làm chuẩn hoá trình phần mềm (Tham khảo K47) - Phương pháp luận hướng tiếp cận phân tích thiết kế phần mềm nói chung Đây phương pháp tuân theo chuẩn thiết kế đưa nhằm làm chuẩn hóa q trình thiết kế phần mềm Ví dụ: phương pháp tiếp cận xuống, phương pháp tiếp cận hướng liệu, … - Các kĩ thuật phương pháp sử dụng để thực giai đoạn tồn chu trình phát triển phần mềm Ví dụ: o Phương pháp đặc tả hình thức kĩ thuật dùng để mơ tả đặc tả phần mềm dựa luật hình thức o Phương pháp Jackson kĩ thuật dùng để định nghĩa thuật tốn chương trình theo cấu trúc liệu đầu vào Câu : Công cụ (tool): Vai trò, tác dụng Nêu tên số cơng cụ ứng dụng cơng cụ Trả lời : - Vai trò: cung cấp hỗ trợ tự động bán tự động cho quy trình phương pháp phân tích thiết kế phần mềm Nói cách khác cơng cụ phần mềm tạo nhằm mục đích sử dụng chung - Tác dụng: cơng cụ tích hợp thơng tin tạo sử dụng cho việc xây dựng phát triển phần mềm khác Chính việc sử dụng cơng cụ có số tác dụng sau: - o Rút ngắn thời gian phát triển hệ thống o Kích cỡ phát triển rút ngắn lại o Dịch vụ nâng cấp kèm theo Một số công cụ vai trị nó: o CAD: (Computer Aided Design) thiết kế có máy tính hỗ trợ Người làm thiết kế cách nhận hỗ trợ máy tính qua hiển thị đồ họa o CAM: (Computer Aided Manufactoring) chế tạo có máy tính hỗ trợ Hỗ trợ cho quản lý tiến trình, chuẩn bị cho sản xuất, kiểm thử xử lý lắp ráp o CAE: (Computer Aided Engineering) kĩ nghệ có máy tính hỗ trợ Là hệ thống hỗ trợ cho loạt công việc bao gồm từ thiết kế sản phẩm, kiểm thử hiệu chế tạo Câu : Phân tích viên (Software Analyst): Vai trị vị trí cán công ty phần mềm Trả lời : - Vai trị: nhìn nhận u cầu đặt hệ thống phía người dùng lẫn phía hệ thống ví dụ quy mô hệ thống, chức hệ thống, lấy yêu cầu khách hàng… Từ đề chiến lược để thiết kế phát triển hệ thống Do phân tích viên cần phải có yếu tố sau : o Am hiểu công việc cơng nghệ phần mềm o Có nhiều kinh nghiệm thành thạo lập trình phần mềm o Có hiểu biết chung nghiệp vụ o Có kĩ giải vấn đề o Khả giao tiếp tốt o Linh hoạt có khả thích nghi - Vị trí: Có vị trí quan trọng dự án Nếu không đưa phân tích điểm lợi dự án hay điểm yếu cần khắc phục yêu cầu cần thiết đặt dự án dẫn tới thất bại dự án Trong công ty phần mềm, người chịu trách nhiệm phân tích hướng phát triển tương lai công ty đưa ưu nhược điểm mô hình phát triển thời mà cơng ty áp dụng Quá trình phát triển phương pháp tiếp cận phân tích thiết kế phàn mềm - - Hướng tiếp cận hướng tiến trình: o Tập trung vào giải thuật xử lý liệu o Quá trình phát triển phần mềm tập trung thể hiệnc ác phương pháp xử lý liệu o Cấu trúc liệu thông thường rõ o Nhược điểm hướng tiếp cận: tệp liệu khó xây dựng để thỏa mãn phần mềm Hướng tiếp cận hướng liệu: - o Mô tả tổ chức liệu: mô tả liệu lấy đâu sử dụng o Mô hình liệu thành lập mối quan hệ liệu o Sử dụng business rules dể phương pháp xử lý liệu Hướng tiếp cận hướng kiến trúc: o Lựac họn kiến trúcvà công nghệ phần mềm để thực tốn o Áp dụng phương pháp prototyping để nhah chóng xây dựng phần mềm o Sử dụng partern kiến trúc mẫu để phương pháp xử lý liệu So sánh phương pháp tiếp cận phân tích thiết kế phần mềm: phương pháp cổ điển, phương pháp hướng tiến trình, phương pháp hướng liệu - - - So sánh phương pháp tiếp cận phân tích thiết kế phần mềm: Phương pháp cổ điển: phương pháp phân tích thiết kế có cấu trúc Các u cầu hệ thống đích phát triển phân tích việc đặc biệt ý tới chức hệ thống luồng liệu chức Mục đích phương pháp chuyển tiến trình biểu đồ DFD thành module chương trình tiến hành phân chia module cách tiếp cận xuống Phương pháp hướng tiến trình: việc phân tích thiết kế đặt trọng tâm vào chức phần mềm thực Khơng có chuẩn rõ ràng để định nghĩa đơn vị chức việc định nghĩa ảnh hưởng cách nghĩ riêng người thiết kế Khó điều chỉnh yêu cầu cho nhiều người dùng Sử dụngc ác chức chồng chéo khó tránh khỏi Kết hệ thống bao gồm nhiều chức chồng chéo nhân tố làm cho việc bảo trì trở nên khó khăn Phương pháp hướng liệu: liệu khơng thay đổi yêuc ầu hay đòi hỏi người dùng thao tác nghiệp vụ Trong thiết kế hướng liệu hệ thống thiết kế dựa cấu trúc tiến trình liệu Việc phân tích thiết kế tiến hành cho liệu tách bạch với yêuc ầu hay đòi hỏi người dùng thao tác Do tiến trình xác định tích hợp vào thủ tục chuyên dụng liệu Chương Câu 9: Trình bày quy trình thực hiện(Các bước), đặc điểm kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng UseCase Use Case phương pháp luận ngôn ngữ mô hình hóa UML Đó phương pháp luận hoàn chỉnh cho việc phát triển phần mềm hướng đối tượng Use case mô tả qua biểu đồ Use-case Use case mô tả tương tác người dùng với hệ, cho biết actor (Các tác nhân) , chức hệ thống Qua phương pháp mô hình hóa Use case, tác nhân (Actor) bên ngồi quan tâm đến hệ thống mơ hình hóa song song với chức mà họ đòi hỏi từ phía hệ thống (tức Use case) Các tác nhân Use case mơ hình hóa mối quan hệ miêu tả biểu đồ Use case UML Mỗi Use case mô tả tài liệu, đặc tả u cầu khách hàng Xây dựng mơ hình Use-case: - Bước q trình mơ hình hóa Use-Case định nghĩa hệ thống(Xác định phạm vi hệ thống – Hình chữ nhật liền nét) : Vì hệ thống thành phần mơ hình Use Case nên ranh giới hệ thống mà ta muốn phát triển cần phải định nghĩa rõ ràng Định nghĩa ranh giới trách nhiệm hệ thống việc dễ dàng, người ta rõ ràng nhìn tác vụ có khả tự động hóa tốt hệ thống tác vụ tốt nên thực thủ cơng dành cho hệ thống khác Một khía cạnh khác cần ý hệ thống cần phải lớn tới mức độ phiên Cố gắng tối đa cho phiên hệ thống thường cách mà người ta hay thực hiện, mục tiêu tầm khiến cho hệ thống trở nên lớn thời gian để cung cấp hệ thống lâu - Tìm tác nhân(Actor) use-case o Một tác nhân người vật tương tác với hệ thống, sử dụng hệ thống Trong khái niệm "tương tác với hệ thống", ý muốn nói tác nhân gửi thơng điệp đến hệ thống nhận thông điệp xuất phát từ hệ thống, thay đổi thông tin với hệ thống Nói cách ngắn gọn, tác nhân thực Use Case Thêm điều nữa, tác nhân người mà hệ thống khác (ví dụ máy tính khác nối kết với hệ thống loại trang thiết bị phần cứng tương tác với hệ thống) o Một Use Case đại diện cho chức nguyên vẹn mà tác nhân nhận Một Use Case ngôn ngữ UML định nghĩa tập hợp chuỗi hành động mà hệ thống thực để tạo kết quan sát được, tức giá trị đến với tác nhân cụ thể Những hành động bao gồm việc giao tiếp với loạt tác nhân thực tính tốn công việc nội bên hệ thống - Mô tả Use-case - Định nghĩa mối quan hệ Use-case - Kiểm tra phê chuẩn mô hình Ví dụ: Câu 10: Trình bày quy trình thực hiện(Các bước), đặc điểm kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng Prototyping Prototyping phương pháp xác định yêu cầu phần mềm cách đưa mẫu thử Người phát triển dựa vào yêu cầu khảo sát để đưa sản phẩm ban đầu phác thảo công nghệ khác với công nghệ sử dụng Sau có trao đổi với người sử dụng, từ tìm u cầu cách cụ thể, rõ ràng hơn, đặc biệt yêu cầu có tính “mờ” Việc tạo mẫu thử sử dụng nhiều lần nhiều phần giai đoạn khác Các mẫu thử tạo có khả tái sử dụng, mẫu thử sau phát triển liên tiếp nên mẫu thử trước.(Mơ hình tiến hóa) Với mục đích phân tích u cầu phần mềm ta xem mẫu thử yêu cầu phần mềm thực thi riêng lẻ hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng khách hàng hiểu cặn kẽ yêu cầu hệ thống Với mục đích phân tích yêu cầu ta chon xây dựng mẫu thử : throwaway, horizontal, user interface (Nếu muốn nói cụ thể loại người đọc sách Managing Requirement Software chương 13 nhe) Để xây dựng mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát yêu cầu hệ thống, tiến hành trao đổi đàm phán với khách hàng Lựa chọn cơng cụ thích hợp cho việc phát triển mẫu thử Dựa vào yêu cầu khảo sát tạo mẫu tro đổi với người sử dụng, với khách hàng, để phát cụ thể u cầu đặc biệt u cầu có tính “mờ” Tiến hành phát triển theo mẫu thử phê duyệt, sau bước tiếp tục tạo mẫu thử sử dụng mẫu thử có từ trước Câu 11: Trình bày yêu cầu xác định nhiệm vụ phạm vi phần mềm Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi dự án Phạm vi dự án hàm của: • Chức cần có để đáp ứng nhu cầu người dùng • Tài nguyên sẵn sàng cho dự án • Thời gian cần có để thực dự án Phạm vi dự án  Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers, nhân viên đảm bảo chất lượng Nếu thời gian đủ dài, kết công việc tăng lên, khơng tăng tỷ lệ với tài nguyên đầu tư thêm Hiệu tổng thể dự án mà bị giảm sút Thêm tài ngun chí làm chậm dự án cần phải đào tạo hỗ trợ cho nhân mới, làm giảm suất dự án Nhằm mục đích phân tích phạm vi, ta coi tài ngun khơng đổi suốt dự án  Thời gian, thay đổi tài ngun sẵn có khơng đủ để hồn thành chức mong muốn Để phân tích phạm vi, ta coi thời gian yếu tố cố định Chức tổng thể bị giới hạn thời gian (cố định) tài nguyên (cũng cố định), phạm vi khả thi hình chữ nhật màu trắng Nếu hiệu đòi hỏi phải bổ sung đặc tính hệ thống với tài nguyên thời gian sẵn có dự án có phạm vi khả thi Thông thường công nghiệp, dự án dự án vượt phạm vi Câu 12 Xác định quản lý giới hạn yêu cầu phần mềm Một số vấn đề quan trọng xác định giới hạn yêu cầu phần mềm: • • • Thiết lập ranh giới cho yêu cầu cấp cao, tập đặc tính đánh mục phân cho phiên cụ thể sản phẩm Thiết lập mức phác thảo hiệu đặc tính ranh giới Ước lượng rủi ro cho đặc tính, hay xác suất thực gây ảnh hưởng tới lịch trình ngân sách • a Sử dụng liệu này, thiết lập ranh giới đảm bảo phân phối đặc tính có ảnh hưởng đến thành công dự án Ranh giới yêu cầu Mục đích quản lý giới hạn yêu cầu phần mềm nhằm thiết lập ranh giới cho yêu cầu cấp cao dự án Chúng ta xác định ranh giới theo: tập đặc tính chia thành mục, hay yêu cầu phân phối cho phiên cụ thể ứng dụng Ranh giới yêu cầu Ranh giới vạch phải: • • Ít chấp nhận khách hàng Có khả thành cơng hợp lý Bước để tạo ranh giới đơn giản liệt kê đặc tính định nghĩa cho ứng dụng Chìa khóa bước việc điều khiển mức độ chi tiết b Thiết lập mức ưu tiên Trong thiết lập mức ưu tiên, quan trọng khách hàng người dùng, quản đốc người đại diện đó, khơng phải đội phát triển, thiết lập mức ưu tiên từ phận marketing nhà c Định mức Thiết lập mức thô cho hiệu đặc tính ranh giới đề xuất Chia nhóm theo mức: thấp-trung bình-cao d Bổ sung yếu tố rủi ro Chúng ta coi xét rủi ro xác suất việc thực đặc tính gây tác động bất lợi đến lịch trình ngân sách Rủi ro cho phép ước đoán tác động việc gộp đặc tính riêng biệt vào ranh giới Một đặc tính có độ rủi ro cao có tác động xấu đến dự án, tất đặc tính khác hoàn thành thời hạn Rủi ro chia thành mức với hiệu e Thu hẹp phạm vi Thông thường mức ưu tiên, hiệu rủi ro khơng đồng với Có nhiều mục cấp thiết lại có hiệu thấp, nhiều mục hữu dụng lại khó thực Từ đó, ta xem xét ưu tiên cho đặc tính, áp dụng vào tài nguyên cung cấp để tăng tối đa lợi ích cho khách hàng Có thể thêm nhân lực cho đội dự án cho số tính có độ ưu tiên thấp hơn, dành nguồn lực để phát triển tính tối cần thiết Câu 13 Trình bày phương pháp xác định yêu cầu phần mềm từ khách hàng Trong xác định yêu cầu khách hàng, ta phải xem xét có hai dạng khách hàng: -Khách hàng cung cấp yêu cầu nghiệp vụ : Cung cấp thông tin công ty, đặc điểm mức độ cao, mơ hình phạm vi hệ thống -Khách hàng cung cấp yêu cầu người sử dụng " cung cấp thông tin nhiệm vụ cụ thể mà họ làm việc với phần mềm Ta cần phối hợp, kết hợp chặt chẽ với hai loại khách hàng Phương pháp xác định yêu cầu khách hàng : -Lên lịch hẹn gặp rõ ràng thực công việc trao đổi với khách hàng -Tạo môi trường thân thiện với khách hàng thực xác định yêu cầu, tránh làm cho khách hàng khó chịu q trình vấn(đây vấn đề nhạy cảm) -Trong trao đổi với khách, cần tôn trọng quyền lợi khách hàng -Trong trình trao đổi, sử dụng ngôn từ thông dụng, không sử dụng nhiều thuật ngữ tin học -Cần trao đổi công việc khách hàng, nắm bắt, học hiểu công việc đó(để thiết kế xác định chức cho phần mềm xác) Yêu cầu khách hàng giải thích đặc điểm cơng việc chưa hiểu rõ để phần mềm làm tốt dễ sử dụng -Khi xác định yêu cầu khách hàng, cần thực việc đánh trọng số, tức xác định mức độ quan trọng yêu cầu khách hàng để tập trung xây dựng phần mềm hợp lý -Tôn trọng khách hàng, phương pháp khách hàng khác với mình, ý tưởng mới! -Kết thúc q trình trao đổi, cần viết đặc tả phần mềm Câu 14 Trình bày bước (quy trình) Phân tích yêu cầu phần mềm Sau thu thập thông tin yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân tích u cầu Mục đích việc phân tích để xác yêu cầu có dư thừa, mức độ quan trọng yêu cầu -Từ yêu cầu phần mềm, ta xác định biếu đồ use case -Xác định hoạt động nghiệp vụ với điểm bắt đầu kết thúc Trong chu trình này, ta cần xác định đối tượng tham gia, luồng thơng tin điều khiển chu trình -Xác định vấn đề môi trường hoạt động phần mềm -Thực hiền kết nối yêu cầu nghiệp vụ yêu cầu người sử dụng -Mô ta cụ thể xác điều kiện thuận lợi thực yêu cầu Câu 27:Kiểm thử (testing) yêu cầu phần mềm Kiểm thử yêu cầu phần mềm cơng việc thực lại sau có yêu cầu phần mềm từ phía NSD, chủ dự án…Qúa trình trình cân nhắc khả đáp ứng lại yêu cầu phần mềm hạn chế nhân lực, thời gian tài đội ngũ phát triển phần mềm Quá trình kiểm thử phát yêu cầu phần mềm phạm vi giới hạn phần mềm, ảnh hưởng đến kiến trúc hệ thống Nhìn chung kiểm thử phần mềm trình kiểm tra yêu cầu phần mềm, từ đưa yêu cầu hợp lý phương án chấp nhận được, thỏa mãn hai bên người sử dụng người phát triển hệ thống Tại phải kiểm thử yêu cầu phần mềm: - Do tính chất mặt yêu cầu phần mềm: Cách nhìn suy nghĩ phần mềm từ phía người sử dụng cách nhìn, suy nghĩ phần mềm từ phía nhà phát triển - Người sử dụng đưa đòi hỏi cao chẳng liên quan đến trình phát triển phần mềm - NSD đưa yêu cầu đề nghị khó chấp nhận gây khó khăn cho lập trình viên - NSD đưa yêu cầu nhập nhằng mơ hồ, trình kiểm thử có trách nhiệm làm rõ yêu cầu - Phát đặc tính thừa người phát triển hệ thống đưa thêm vào yêu cầu phụ phần mềm từ phía người sử dụng gây tốn không cần thiết - Kiểm tra khả đáp ứng mặt kỹ thuật - Đặc tả rõ ràng chi tiết yêu cầu Tiêu chí kiểm thử u cầu phần mềm - Hồn thiện - Chính xác - Khả thi - Cần thiết - Rõ ràng - Kiểm tra được, xác minh Câu28.Đánh giá yêu cầu phần mềm theo thuộc tính chất lượng phần mềm Người phát triển (developer) hệ thống có trách nhiệm cho việc xác định yêu cầu ứng dụng , Phát triển phần mềm việc thực thi yêu cầu , phân phối tài nguyên ( processor mạng cộng đồng ) Không đơn đáp ứng yêu cầu chức Ngoài hệ thống phải đáp ứng yêu cầu bảo mật , an toàn ,tin cậy , vận hành …vì phần mềm chất lượng phải kết hợp đựoc đặc tính mong muốn : • Thực thi(performance) : từ truyền thống hệ thống thời gian thực khả lập kế hoạch • Tin cậy( dependability):từ truyền thống hệ thống hịan tồn tin cậy • An ninh(security): từ hệ thống phủ , ngân hàng , cộng đồng học thuật • An tồn(safey) : từ truyền thống phân tích rủi ro Performance : Theo định nghĩa IEEE : cấp độ , mà hệ thống hay thành phần hoàn thành chức thiết kế nằm lọat ràng buộc tốc độ , xác , hay việc dùng nhớ • • • • • • • Performance requirements : số lượng yêu cầu định nghĩa term kiện ràng buộc thời gian cho đáp ứng tới kiện Behavior patterns and intensity : số lượng dòng kiện trường hơp tồi tệ ồn định xảy cho dòng kiện Software descriptions : phép toán phần mềm cần để chạy để đáp ứng kiện Resource usage estimates : yêu cầu nguồn liệu cho việc mang theo phép tốn phần mềm giơng thời gian sử lý processor, đòi hỏi I/O , nhớ performance concerns : giống tiêu chuẩn cho việc đánh giá việc lập lịch , ràng buộc thời gian cho việc đáp ứng kiện performance factors : cách cư sử pattern , việc sử dụng tài nguyên, miêu tả phần mềm , cơng việc , phép tốn , mơ tả đòi hỏi hệ thống performance methods :giống tổng hợp phân tích vẽ lên thuyết Hạn chế: -Phân tích domain thường hiệu việc tạo kiến trúc phần mềm -Phân tích domain thường không đủ thân khái niệm domain thường xuyên thay đổi - Hướng tiếp cận Pattern-driven: Kiến trúc xây dựng nhờ sử dụng mẫu kiến trúc có sẵn phù hợp với mục đích ngữ cảnh vấn đề đưa Hạn chế: -Không đủ để giải dải rộng loại kiến trúc -Việc chọn mẫu hoàn toàn phụ thuộc kinh nghiệm người kỹ sư -Không áp dụng mẫu mà phải qua phân tích -Việc kết hợp mẫu không hỗ trợ tốt 4.2 here 15 Các chiến lược phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm Usability: Kiến trúc phần mềm Usability liên quan đến mức độ dễ dàng cho người sử dụng để họ hoàn thành tác vụ mong muốn loại hỗ trợ mà hệ thống cung cấp cho họ Chiến lược: Có hai loại chiến lược hỗ trợ kiến trúc phần mềm Usability, loại lại hướng đến nhóm đối tượng người dùng khác - Loại thứ nhất: thời gian thực, bao gồm chiến lược hỗ trợ người dung trình hệ thống thực thi - Loại thứ hai dựa lặp lại tự nhiên việc thiết kế giao diện người dùng hỗ trợ nhà phát triển giao diện giai đoạn thiết kế Nó có liên quan chặt chẽ tới chiến lược sửa đổi modifiability trình bày Phương pháp đảm bảo thuộc tính chất lượng: Trong q trình phát triển, vấn đề tính tiện dụng phần mềm thực thông qua việc xây dựng nguyên mẫu các kiểm thử người dùng Có thể phân thành lĩnh vực nhỏ sau: - Tìm hiểu đặc tính hệ thống: Nếu người dung không quen với hệ thống cụ thể khía cạnh cụ thể hệ thống, hệ thống làm để cơng việc tìm hiểu trở nên đơn giản hơn? - Sử dụng hệ thống cách hiệu quả: Hệ thống làm để người dung cảm thấy hiệu việc thực thao tác họ? - Tối thiểu hóa lỗi xảy ra: Hệ thống làm để lỗi người dùng có ảnh hưởng tối thiểu đến tồn hệ thống? - Thích ứng hệ thống với yêu cầu người dùng: làm để người dùng (hay thân hệ thống) thích ứng để công việc người dùng trở nên dễ dàng hơn? - Gia tăng độ tin tưởng tính đáp ứng hệ thống người dùng Hệ thống làm người dung tự tin hành động hợp lý thực hiện? 16 Phương pháp ATAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu Đặc điểm: phương thức toàn diện cho kiến trúc định giá (Architecture Tradeoff Analysis Method), cách thức toàn diện cho việc đánh giá kiến trúc phần mềm Bản chất: ATAM có tên thể kiến trúc muốn thỏa mãn mục tiêu cuối phải nào, làm để mục tiêu chất lượng tương tác cân với Nó cịn thiết kế để sử dụng mục tiêu nhằm tập trung ý đối tượng định giá vào phần cấu trúc mục tiêu việc đạt mục đích Kỹ thuật tiêu biểu CBAM: - Phân nhóm tham gia: yêu cầu nhóm: o Nhóm ước lượng: nhóm nằm bên ngồi dự án có nhiệm vụ ước lượng định giá kiến trúc o Nhóm lập định dự án: người trao quyền để theo dõi định trình phát triển dự án o Nhóm khách hàng: Các khách hàng tham gia trình ước lượng - Phân giai đoạn: 0+3 giai đoạn: o Giai đoạn 0: "Partnership and Preparation", trưởng nhóm ước lượng người định dự án họp lại để đưa chi tiết kế hoạch o Giai đoạn 2: giai đoạn ước lượng, nơi người ngồi lại để phân tích chức o Giai đoạn 3: tiếp tục với việc nhóm ước lượng đưa báo cáo cuối - Yêu cầu đầu ATAM: o Ngắn gọn, súc tích mặt kiến trúc o Là khớp nối mục tiêu chức o Đảm bảo yêu cầu mặt chất lượng kịch o Ánh xạ định kiến trúc với yêu cầu chất lượng o Chỉ nhạy cảm hay yếu tố cân chiến lược o Chỉ mạo hiểm rủi ro phát sinh kế hoạch 17 Phương pháp CBAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu Đặc điểm: phương pháp phân tích kiến trúc phần mềm dựa theo lợi ích giá thành Bản chất: Nội dung phương pháp mong muốn tạo chênh lệch lớn lợi nhuận thu từ hệ thống xây dựng giá thành chi phí cho cơng việc thiết kế Kỹ thuật tiêu biểu CBAM: bao gồm bước sau : - Bước 1: Đối chiếu kịch - Bước 2: Lọc kịch - Bước 3: Thu thập kịch có mức ưu tiên - Bước 4: Gán lợi ích - Bước 5: Phát triển kiến trúc kế hoạch cho kịch định cuả chúng trơng đợi vào chất lượng thuộc tính phản hồi từ cấp - Bước 6: Xác định quyền lợi mong đợi chất lượng thuộc tính phản hồi theo cấp phép nội suy - Bước 7: Tính tốn tổng lợi nhuận thu từ kiến trúc kế hoạch - Bước 8: chọn chiến lược kiến trúc dựa ROI nhằm vào hạn chế chi phí lịch trình - Bước 9: Xác nhận lại kết với trực giác Câu 18: Đặc điểm chất phương pháp Function-oriented(structured) Design Bản chất: - Phân rã chức hệ thống thành nhiều phần nhỏ, phần lại thiết kế chi tiết bước sau - Sử dụng kỹ thuật thiết kế từ tổng quan đến chi tiết (top-down) - Mỗi module mức thấp thực phần việc định, liên quan đến công việc module khác Đặc điểm: - Khi có thiết kế hướng cấu trúc tốt, dễ dàng tạo chương trình tốt, có tính hệ thống, giảm nhập nhằng, khó hiểu - Mã chương trình rõ ràng dễ hiểu - Dễ dàng tạo module chương trình - Đơn giản, dễ hiểu, thuận tiện việc triển khai nâng cấp Câu 19: Đặc điểm chất phương pháp Object-Oriented Design Bản chất: Là phương pháp phân tích thiết kế hệ thống dựa bước sau đây: - Phát đối tượng - Xác định thuộc tính phương thức chúng - Xác định cấp bậc đối tượng Đây phương pháp mạnh hiệu thiết kế xây dựng phần mềm Phương pháp nhìn hệ thống, việc, vấn đề theo quan điểm đối tượng, giữ vai trị trung tâm đối tượng Một hệ thống coi tập hợp đối tượng mối quan hệ đối tượng Phương pháp cho ta nhìn đắn hơn, xác giới thực, cho phép mô tả hệ thống tồn thực tế không bị phụ thuộc vào cách mô tả, cách hoạt động máy tính Có ngun tắc phương pháp thiết kế hướng đối tượng: - Tính đóng gói cho phép lớp dùng lại mà khơng cần biết cách hoạt động Vì vậy, việc module hóa trừu tượng hóa lớp cung cấp để che dấu thơng tin - Tính kế thừa cho phép lớp dùng lại cách sử dụng số tính mà lớp sẵn có - Tính đa hình cho phép lớp tổng qt làm việc với nhiều kiểu đối tượng khác Đặc điểm: - Đảm bảo tương ứng mô hình phân tích mơ hình thiết kế: Với phương pháp cổ điển, hệ thống mơ hình phân tích mơ hình thiết kế khơng có tương ứng cao, việc chuyển đổi qua lại hai mơ hình gặp nhiều khó khăn Kết hệ thống có thay đổi việc thực lại trình phân tích thiết kế phức tạp khó khăn Với thiết kế hướng đối tượng, hai mơ hình gần có tương đồng nên gặp phải khó khăn - Tăng tính trừu tượng tốn: Mơ hình hướng đối tượng trì mối liên hệ chặt chẽ liệu thao tác liệu thực thể thống Điều phản ảnh chất giới thực, thiết kế hướng đối tượng đạt tính trừu tượng tốn cao - Tăng tính ổn định trước thay đổi - Tăng tính sử dụng lại - Tăng tính linh hoạt khả mở rộng dễ dàng - Độ tin cậy an toàn cao - Hỗ trợ khả hoạt động song song: Bản chất đối tượng tồn hoạt động độc lập, có tương tác với mơi trường Do đó, trừ có định đặc biệt, đối tượng hoạt động song song - Sử dụng công cụ thiết kế mạnh, UML Câu 20: Đặc điểm chất phương pháp Data-structure Centered Design Bản chất: - Ý tưởng phương pháp so khớp cấu trúc chương trình với cấu trúc liệu mà chương trình sử dụng - Các chức chương trình hồn tồn định nghĩa dựa đặc tính liệu đầu vào đầu Đặc điểm: - Hiện nay, phương pháp thiết kế phần mềm có tính hệ thống - Nó thích hợp với ứng dụng mà cấu trúc liệu (đầu vào đầu ra) rõ ràng Phương pháp áp dụng mà cấu trúc liệu mập mờ, không rõ ràng - Thích hợp cho ứng dụng có liên quan nhiều đến việc xử lý file - Cấu trúc chương trình có mối quan hệ mật thiết với cấu trúc liệu, cấu trúc liệu thay đổi dẫn đến cấu trúc chương trình thay đổi theo - Quá trình thiết kế bao gồm nhiều bước, sau bước thu kết rõ ràng 21.Lược đồ khái niệm : Lược đồ khái niệm hay cịn gọi mơ hình liệu khái niệm đồ khái niệm mối quan hệ Nó mơ tả ngữ nghĩa tổ chức biểu diễn lại thành chuỗi định nghĩa theo cách tự nhiên Đặc biêt, mơ tả đặc điểm quan tổ chức(entity classes), có khuynh hướng tập trung thơng tin, thuộc tính kết hợp phần quan trọng hệ thống Bởi mơ tả lại ngữ nghĩa tổ chức khơng phải thiết kế sở liệu, tồn nhiều mức độ trừu tượng khác Cấu trúc chuẩn ANSI 4-lược đồ bắt đầu với tập hợp lược đồ tức lược đồ mơ tả cách nhìn giới xung quanh người Chúng hợp vào lược đồ khái niệm đơn, siêu tập hợp lược đồ Nếu giới người thay đổi, mơ hình thay đổi theo Mơ hình liệu khái niệm tạo khung cảnh trừu tượng, định nghĩa điều Mơ hình cho phép mà cộng đồng hướng đối tượng gọi thừa kế Tập hợp ví dụ lớp thực thể (entity class) chia vào nhiều lớp mà sở hữu Như thế, ví dụ lớp ví dụ lớp cha Mỗi ví dụ lớp thực thể cha ví dụ nhiều lớp thực thể Mỗi quan hệ lớp cha lớp khơng Phương thức cần ví dụ lớp cha ví dụ lớp Tương tự vậy, mối quan hệ lớp cha lớp tồn hay khơng Nó tồn phương thức cần ví dụ lớp cha ví dụ lớp Ví dụ quan hệ Mỗi người thực nhiều thượng vụ làm ăn Mỗi thương vụ làm ăn người thực … 22.Nêu khái niệm MSF phase MSF MFS(Microsoft Solutions Framework) công cụ cung cấp tập hợp mơ hình, quy tắc cho việc thiết kế phát triển giải pháp doanh nghiệp nhằm đảm bảo thành tố dự án người, tiến trình, cơng cụ đảm bảo quản lý đầy đủ.Đồng thời cung cấp vấn đề thực tế cho việc lên kế hoạch, thiết kế, triển khai nhằm đảm bảo thành công cho giải pháp Các pha:5 pha 1) Phác thảo(envisioning phase): pha đầu tiên, nhiệm vụ tạo bảng mô tả mục đich ràng buộc dự án, xác định đội dự án công việc mà đội dự án cần làm để đáp ứng yêu cầu khách hàng 2) Lên kế hoạch(planning phase) Giai đoan đội dự án xác đinh giải pháp, lên kế hoạch cho giải pháp Trong giai đoạn phải xây dựng đặc tả yêu cầu, lượng giá, chuẩn bị công việc, lập lịch cho dự án 3)Phát triển(developing phase) Qui trình phát triển(Bắt đầu vòng phát triển, tạo ứng dụng mẫu thử, phát triển thành phần giải pháp,xây dựng giải pháp,đóng pha phát triển) 4)Kiểm định(Stabilizing phase) Đội dự án thực tích hợp tải kiểm thử beta Kiểm thử theo kịch, nhận giai vấn đề chuẩn bị xuất bản/ 5)Triển khai(deploying phase) Giai đoạn triển khai giải pháp, chuyển giao hỗ trợ cho khách hàng nhận chấp thuận từ phía khách hàng 23.Nêu q trình thiết kế giao diện tương tác phần mềm 1) 2) 3) 4) Tạo thiết kế sơ khai Cung cấp trợ giúp người dùng Chọn lựa mơ hình giao tiếp Chọn lựa môi trường cho người dùng 24.Nêu yêu cầu giao diện tương tác 1) 2) 3) 4) 5) 6) Thiết kế trực quan Sử dụng hình cách tối ưu Màu sắc hợp lý Dễ dàng truy nhập (các phím tắt) Kiểm sốt truy nhập Tự tạo giá trị mặc định 7) Kiểm tra giá trị đưa vào 8) Sử dụng Menu, Toolbar, Help 25.Nêu số kỹ thuật thiết kế giao diện tương tác - Kỹ thuật sử dụng công cụ thiết kế mẫu thử để thiết kế Form giao tiếp - Điều khiển trực tiếp : Đặc trưng quan trọng bao gồm + Tính nhìn thấy đối tượng quan tâm + Gia tăng hoạt động giao diện với phản hồi nhanh chóng hành động + Thay ngơn ngữ dòng lệnh phức tạp hành động nhằm điều khiển trực tiếp đối tượng thấy - Thiết kế lặp mẫu thử + Quá trình thiết kế nhằm khắc phục tính cố hữu đặc tả khơng đầy đủ Có kỹ thuật mẫu thử  Tung (Throw away) : mẫu thử xây dựng kiểm thử  Gia tăng (Incremental) : sản phẩm cuối xây dựng thành phần riêng biệt, thành phần thời điểm  Tiến hóa (Evolutionary) : mẫu thử khơng bị hủy bỏ mà dùng sở cho lần lặp - Thiết kế thành phần tiến trình nghiệp vụ : + cho phép chuỗi cơng việc quay lui hủy bỏ + dùng lại + phải có tương ứng thành phần giao diện với thành phần tiến trình 26.Đặc điểm mơ hình hóa thiết kế liệu mức khái niệm (conceptual data modeling) Conceptual Data Model Đặc điểm thiết kế mơ hình hóa liệu mức khái niêm bao gồm: • • • Bao gồm thực thể quan trọng mối quan hệ thực thể Khơng có thuộc tính rõ Khơng có khóa rõ Kiểu mơ hình hóa liệu thường dùng trung gian kết nỗi thực thể giải thích cách mà liệu lưu trữ Mặc dù thiết kế mơ hình hóa liệu khơng thiết phụ thuộc vào chuẩn Nhưng phải chắn phải tn theo dạng thông thường: dạng thứ (1NF) dạng thứ (2NF) The first normal form 1NF Luật tổ chức sở liệu • Loại trừ cột giống bảng • Tạo bảng riêng biệt cho nhóm có liệu liên quan and nhận dạng dịng có cột đặc biệt tập cột đặc biệt để tạo khóa (the primary key) The second normal form 2NF Trình bày thêm vấn đề lược bỏ liệu trùng lặp • Tụ họp tất yêu cầu 1NF • Lược bỏ tập liệu màRemove subsets of data that áp dụng cho nhiều dòng bảng đặt chúng vào bảng đặc biệt • Tạo quan hệ bảng bảng kế thừa thơng qua khóa ngồi (foreign keys) Tớ mai có việc nên làm được, có điều tranh thủ làm câu cho kịp Tuy để tránh trùng lặp nên làm từ lên 32.Nêu kỹ thuật thiết kế bảo mật cho ứng dụng (Nguyễn Tiến Thành) Để thiết kế ứng dụng có tính bảo mật, bạn phải đảm bảo kỹ thuật sau thiết kế: Phải tin tưởng vào hệ thống kiểm tra qua thử thách: Bất kì có thể, bạn phải tin tưởng vào hệ thống kiểm tra qua thử thách đề giải pháp riêng bạn Dùng giải thuật qua thử thách cơng nghiệp, đảm bảo tính kỹ thuật, hỗ trợ tảng tốt Đặc biệt hệ thống kiểu nhà cung cấp kiểm thử có hỗ trợ mặt kỹ thuật Nếu bạn định phát triển hệ thống riêng bạn, nên xác nhận kế hoạch kỹ thuật bạn chuyên gia kiểm tra đánh giá lại mức độ bảo mật tổ chức bạn trước sau thực thi giải pháp Không tin tưởng vào đầu vào từ bên ngoài: Bạn phải xác thực tất liệu đưa vào người dùng thiết bị Giả định hệ thống bên ngồi khơng an tồn: Nếu ứng dụng bạn nhận liệu khơng mã hóa, dễ tổn thương từ hệ thống bên ngoài, phải xem thông tin bị xâm phạm Đảm bảo nguyên lý việc quyền nhất: Với tài khoản, đừng cho phép nhiều quyền hạn mức cần thiết Việc truy xuất tài nguyên tài khoản nên có quyền hạn Giảm thành phần liệu có: Hãy cố giảm bớt thành phần liệu mà bạn có ứng dụng Để bạn tập trung vào chức mà bạn cho phải sử dụng đến Mặc định chế độ bảo mật: Không cho phép dịch vụ, tài khoản, kỹ thuật mà bạn thấy rõ ràng không cần thiết Khi bạn triển khai ứng dụng client server, cấu hình mặc định ứng dụng phải bảo mật Không tin tưởng vào biện pháp bảo mật mà tiếng tăm Mã hóa liệu phải có khóa giải thuật qua thử thách Các liệu mật phải lưu trữ với biện pháp ngăn ngừa truy xuất tình Các biện pháp đơn giản, khơng coi bảo mật Nguyên lý theo dõi STRIDE: STRIDE viết tắt Nhận diện giả mạo (spoofing identity) , Sự lục lọi (tampering), Sự từ chối tuân theo luật định (repudiation), phơi bày thông tin (information disclosure), từ chối dịch vụ (denial of service), tìm cách tăng quyền hạn (elevation of privilege) Đó tập hợp mối nguy hiểm bảo mật mà hệ thống cần bảo vệ chống lại chúng 33 Nêu kỹ thuật đảm bảo chất lượng phần mềm giai đoạn thiết kế Để đảm bảo chất lượng phần mềm giai đoạn thiết kế, ta cần thực kĩ thuật sau: Đảm bảo độ xác, tin cậy yêu cầu phần mềm tài liệu Sử dụng sở hạ tầng kĩ thuật tốt Đưa thơng tin quản lí vào Sử dụng kĩ thuật dư thừa Sử dụng công cụ phát triển chất lượng Sử dụng công cụ kiểm tra tin cậy cung cấp theo ứng dụng Sử dụng chế xử lí lỗi thích hợp Giảm số lượng chức ứng dụng thay hồn thiện khuyết điểm ứng dụng 34 Nêu đặc điểm giai đoạn ổn định giai đoạn triển khai 1.Giai đoạn ổn định: Một đặc điểm giai đoạn cường độ công việc đội thực dự án giảm dần xuống công việc quản lý sản phẩm tăng lên Đội phát triển dự án chuẩn bị tạm dừng công việc để chuyển sang giai đoạn phục vụ hỗ trợ Chuẩn bị source-code cho việc bảo trì phát triển tương lai Trong đội quản lý sản phẩm phải tăng cường cơng việc mình, chuẩn bị để triển khai sản phẩm 2.Giai đoạn triển khai: Đội dự án triển khai sản phẩm tới khách hàng Sau đội quản lý sản phẩm phải thường xuyên theo dõi phản ứng tiếp thu phản hồi từ phía khách hàng Đội dự án đồng thời phải sẵn sang cho việc giải vấn đề phát sinh 35 Các yêu cầu đặc tả phần mềm Kiến trúc phần mềm cho hệ thống đóng vai trò trung tâm việc phát triển hệ thống tổ chức tạo kiến trúc Nó cung cấp kế hoạch giai đoạn cho hệ thống cho đội dự án phát triển Nó cho thấy phân cơng cơng việc phải hoàn thành đội dự án phân tích thực thi Đồng thời có cịn thước đo chất lượng dự án: hiệu năng, khả chuyển, an tồn Kiến trúc phần mềm cơng cụ để phân tích từ sơ khai, đảm bảo cho thiết kế cho hệ thống chấp nhận Có thể coi phần kết dính, kết hợp tất pha dự án lại với cho tất stakeholder chúng Chính tầm quan trọng đặc tả phần mềm: kiến trúc hồn hảo chí trở nên vô dụng tất người không hiểu - cần phải miêu tả đặc tả phần mềm chi tiết cách hợp lý, rõ ràng khơng gây nhầm lẫn khó hiểu, đồng thời phải tổ chức cho người khác tìm kiếm thơng tin cần thiết cách dễ dàng -Tài liệu đặc tả cần đủ trừu tượng để nhân viên hiểu nhanh chóng, phải đủ chi tiết để làm kế hoạch cho việc phân tích -Tài liệu đặc tả phải vừa quy tắc: bắt buộc thực theo, vừa nội dung: hướng dẫn, theo kế hoạch để thực công việc -Với người dùng khác nhau, cần có loại tài liệu khác nhau, với mức độ hình thức cung cấp thơng tin khác nhau, tương ứng Tuy nhiên tạo tài liệu đơn đáp ứng tất yêu cầu người dùng -Khái niệm quan trọng gắn liền với đặc tả phần mềm khung nhìn (view) – cho ta thấy nguyên tắc tài liệu đặc tả phần mềm Xây dựng tài liệu đặc tả việc xây dựng tài liệu khung nhìn liên quan, thích hợp sau xây dựng thêm tài liệu có khả áp dụng cho nhiều khung nhìn 36 Định dạng đặc tả phần mềm: Các loại tài liệu Định dạng đặc tả thiết kế phần mềm nhằm tạo tài liệu đặc tả(TLĐT) chung cho nhiều kiến trúc phần mềm khác nhau; nhằm giúp cho người viết TLĐT dễ dàng nguời đọc tài liệu đặc tả nhanh chóng tìm thơnng tin cần cách nhanh chóng Các loại tài liệu đặc tả: 1/ Tài liệu mô tả chính(Primary presentation ): mơ tả phần từ mối quan hệ phần tử 2/ Tài liệu chi tiết danh mục phần tử mô tả mối quan hệ với tài liệu mô tả 3/ Các biểu đồ ngữ cảnh(Context diagram) Chỉ cách miêu tả hệ thống mối quan hệ với môi trường 4/ Tài liệu hướng dẫn, quản lý thay đổi 5/ Architect background (kiến trúc nền): giải thích thiết kế phản ánh khung nhìn(view) 6/ Danh sách thuật ngữ, từ chuyên môn, điều kiện… 7/ Các tài liệu thông tin khác 37 Các quy định chung định dạng đặc tả Một tài liệu đặc tả thiết kế phần mềm cần phải được: 1/ Giao diện thành phần: thành phần có đa giao diện cần xác định khác biệt chúng 2/ Các tài nguyên cung cấp 3/ Các kiểu liệu: kiểu liệu người thiết kế tạo 4/ Các định nghĩa ngoại lệ: ngoại lệ xảy 5/ Các thay đổi xảy cấu hình lại thành phần 6/ Chất lượng mà việc thiết kế mang lại (như khả thực hay độ tin cậy) 7/ Các yêu cầu thành phần 8/ Lý thiết kế giao diện thành phần 9/ Hướng dẫn sử dụng 38 Một số kỹ thuật thiết kế đặc tả Kiến trúc phần mềm hệ thống quan trọng, mơ tả cơng việc phải thực đội thiết kế thực thi Xây dựng đặc tả kiến trúc phần mềm bước hoàn thiện, kiến trúc hoàn hảo vơ dụng khơng hiểu Vì phải xây dựng đặc tả kiến trúc hợp lý +Đặc tả khung nhìn: Khơng có mẫu tiêu chuẩn cho đặc tả khung nhìn Với phần muốn thể hiện, cần phải tuân theo tổ chức tiêu chuẩn Việc bố trí thơng tin rành mạch rõ ràng giúp người viết dễ dàng người đọc tìm kiếm thơng tin nhanh bỏ qua phần khơng cần thiết +Đặc tả hành vi: Statechart hình thức mô tả hệ thống tương tác với nhiều đặc tính hiệu Nó mơ tả phối hợp điều kiện thành phần tác động lẫn chúng theo chuỗi Nó giúp trả lời câu hỏi hành động xảy hệ thống phản ứng lại tác nhân điều kiện cụ thể +Đặc tả giao diện: Giao diện đường giới hạn hai thực thể độc lập gặp tương tác giao tiếp với Đặc tả giao diện bao gồm việc đặt tên, nhận biết đặc tả thông tin thuộc cú pháp ngữ nghĩa Đặc tả gồm thuộc tính yếu tố lựa chọn kĩ thuật khơng nên nêu q nhiều q thơng tin 39.Nêu phương pháp kiểm duyệt, kiểm thử đánh giá đặc tả phần mềm ( Câu nhóm tớ chưa tìm tài liệu, xin bổ sung sau :D) Câu 1:Trình tự thiết kế chi tiết Gồm trình sau: -Thiết kế thành phần phần mềm -Thiết kế vào -Thiết kế liệu vật lý -Tạo tài liệu thiết kế chi tiết -Rà soát lại thiết kế Câu 2: Nêu kỹ thuật thiết kế thành phần phần mềm : Phân chia thành thành phần,xác định đặc tả chức ,Giao diện thành phần Thế thiết kế thành phần phần mềm? Sau giai đoạn thiết kế ngoài, hệ thống phân thành hệ thống Thiết kế thành phân phần mềm áp dụng phương pháp thiết kế hướng cấu trúc để chia hệ thống thành đơn vị chương trình Do đó, cấu trúc chương trình hệ thống rõ ràng • Phân chia thành thành phần: Phân chia thành thành phần nghĩa phân chia hệ thống thành chương trình Các thủ tục phân chia thành thành phần gồm: o Cấu trúc luồng liệu cho thành phần o Phân chia thành phần ( tức phải lược đồ quan hệ thành phần) • Đặc tả chức thành phần bao gồm thủ tục : o Xác định chức thành phần o Xác định liệu vào- o Xác định nguồn vào kết • Xác định giao diện thành phần giai đoạn quan trọng thiết kế thành phần phần mềm Phải đầu vào, đầu cho thành phần Câu 3: Nêu kỹ thuật thiết kế vào /ra :Thiết kế báo cáo ,Thiết kế giao diện người dùng ,Thiết kế hình ,Phương pháp kiểm tra vào /ra thiết kế thông báo Câu 4: Thiết kế liệu vật lý Thủ tục thiết kế liệu vật lý gồm bước: Phân tích đặc trưng liệu Các đặc trưng liệu cần phân tích chặt chẽ thiết kế chuẩn bị theo cách đặc trưng liệu tương ứng tận dụng Cần ý điểm sau: • Các đặc trưng việc dùng liệu:  Đó tệp hay tệp giao tác?  Phải trì (thời gian dài hay tạm thời?)  Nó dùng liệu dự phịng hay trì ghi cập nhật)? • Thêm, xóa hay thay đổi liệu Khối lượng liệu thêm vào, xóa hay thay đổi thời kỳ xác định Nội dung nhiệm vụ cần thực (theo trật tự khóa hay ngẫu nhiên) • Cập nhật: cập nhật hàng ngày/ tháng/năm hay theo thời kỳ xác định? • Cách liệu dùng (dùng cho xử lý lơ thay xử lý trực tuyến) • Bảo trì: liệu khôi phục bị phá hủy? Xác định hệ thống tổ chức liệu cấu trúc logic Cần phải tổ chức liệu thành cấu trúc logic tổ chức vật lý, ý : • Phạm vi việc dùng liệu: Dữ liệu có dự định để dùng hệ thống phát triển hay ko?Hay phải dùng hệ thống khác tệp chính? Hay dùng cho lập trình? • Dữ liệu tạm thời hay liệu để cất giữ? • Dữ liệu có xử lý hay ko? Nó có tăng dần hay tăng nhanh: có phải kiểu liệu tăng dần u cầu trì ghi cập nhật? Xác định phương tiện lưu trữ liệu Cần quan tâm đến đặc điểm phương tiện lưu trữ (dung lượng , phương pháp truy nhập liệu, tốc độ truy nhập, bảo trì, vận hành, giá cả…) để lựa chon cho phù hợp Nếu muốn truy nhập trực tiếp vào liệu dùng khóa, thiết bị ghi nhớ cho phép truy nhập trực tiếp, đĩa từ dùng Thiết kế cách bố trí ghi • Thiết kế trường(field): ý xác định thứ tự item, kích thước trường kiểu liệu, trường dự trữ (để mở rộng), phải thiết kế cho dễ lập trình • Kiểu ghi (bản ghi chiều dài cố định/ko cố định/ Ko xác định) • Bố trí ghi:  Tên ghi, cần chọn ký tự dễ nhớ biểu diễn nội dung liệu Số chữ số để tạo index cho liệu phải đưa vào Một chữ số ký tự chữ số (một byte) Câu 5: Nêu tên tài liệu thiết kế chi tiết - Biểu đồ phân chia thành thành phần Các dạng biểu đồ: biểu đồ luồng liệu, lưu đồ, hệ phân cấp cộng với vào xử lý (hierarchy plus input process output – HIPO) hay phương tiện định làm chuẩn nội - Biểu đồ giao diện thành phần - Đặc tả xử lý thành phần - Tài liệu thiết kế hình - Tài liệu thiết kế biểu mẫu - Tài liệu thiết kế tệp - Tài liệu thiết kế sở liệu Câu 6: Nêu tổ chức tài liệu thiết kế chi tiết - Biểu đồ phân chia thành thành phần Các dạng biểu đồ: biểu đồ luồng liệu, lưu đồ, hệ phân cấp cộng với vào xử lý (hierarchy plus input process output – HIPO) hay phương tiện định làm chuẩn nội Đây biểu đồ phân cấp chức - Biểu đồ giao diện thành phần Là biểu đồ thể kết nối thành phần biểu đồ thông qua luồng kho liệu - Đặc tả xử lý thành phần Bảng chức chương trình, tạo cho chương trình - Tài liệu thiết kế hình Chứa thông tin việc thiết kế giao tiếp người dùng đồ họa GUI, bao gồm mơ hình mẫu sửa đổi cải tiến cho phù hợp với yêu cầu người dùng Tài liệu thiết kế biểu mẫu - Thông tin chi tiết biểu mẫu sử dụng q trình phân tích thiết kế - Tài liệu thiết kế tệp Mô tả kiểu tổ chức tệp vật lý dựa kết phân tích đặc trưng liệu, phương pháp tổ chức logic, chức chương trình … Các kiểu tổ chức tệp vật lý là: + Tệp tổ chức + Tệp tổ chức trực tiếp + Tệp số + Tệp tổ chức phân hoạch + Tệp tổ chức ghi nhớ ảo + Bảng - Tài liệu thiết kế sở liệu Mô tả cách thức tổ chức liệu sở liệu, thể thơng qua mơ hình sở liệu mơ hình liệu gồm sơ đồ thực thể - liên kết, mơ hình mạng, mơ hình phân cấp, mơ hình quan hệ ... thành phần phần mềm Phải đầu vào, đầu cho thành phần Câu 3: Nêu kỹ thuật thiết kế vào /ra :Thiết kế báo cáo ,Thiết kế giao diện người dùng ,Thiết kế hình ,Phương pháp kiểm tra vào /ra thiết kế thông... thiết kế chi tiết -Rà soát lại thiết kế Câu 2: Nêu kỹ thuật thiết kế thành phần phần mềm : Phân chia thành thành phần, xác định đặc tả chức ,Giao diện thành phần Thế thiết kế thành phần phần mềm? ... phần mềm ( Câu nhóm tớ chưa tìm tài liệu, xin bổ sung sau :D) Câu 1:Trình tự thiết kế chi tiết Gồm trình sau: -Thiết kế thành phần phần mềm -Thiết kế vào -Thiết kế liệu vật lý -Tạo tài liệu thiết