Đang tải... (xem toàn văn)
đề cương ôn thi phân tích và thiết kế phần mềm
65 SE-K48 ĐỀ CƯƠNG PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM ************************* ĐỀ CƯƠNG PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM 1 ************************* 1 Chương 0. Cơ sở của phân tích và thiết kế phần mềm 5 1. Nêu khái niệm phân tích và thiết kế phần mềm (Software analysis and development) 5 2.Phân biệt khái niệm Phương pháp luận (methodologies) và Kỹ thuật (technique) 5 3.Công cụ (tool): Vai trò, tác dụng. Nêu tên một số công cụ chính và ứng dụng của những công cụ này 5 4. Phân tích viên (Software Analyst): Vai trò và vị trí của cán bộ này trong công ty phần mềm 6 5. Quá trình phát triển của phương pháp tiếp cận phân tích và thiết kế phàn mềm 6 6. So sánh các phương pháp tiếp cận phân tích và 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 dữ liệu 7 7. Hãy nêu phân loại phần mềm theo ứng dụng 7 8. [Thiếu] 7 Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm 7 1. Mô tả quy trình công nghệ học yêu cầu phần mềm ( Requirement Engineering ). 7 2. Hãy nêu bản chất của yêu cầu phần mềm. 9 3. Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng. 9 4. Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm 9 5. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (interview). 10 6. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Hội thảo. 10 7. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Brainstorming 11 8. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Storyboarding 12 9. Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng UseCase. 12 10. Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng Prototyping. 14 11. Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm 14 12. Xác định và quản lý giới hạn của các yêu cầu phần mềm 15 13. Trình bày phương pháp xác định các yêu cầu phần mềm từ khách hàng 17 14. Trình bày các bước (quy trình) .Phân tích các yêu cầu phần mềm 17 15. Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm 17 16. Nêu các tiêu chí chất lượng và đo lường chất lượng yêu cầu phần mềm. 18 17. Phân biệt các khái niệm kiểm thử và đánh giá các yêu cầu phần mềm. 18 18. Quan hệ giữa yêu cầu và thực hiện. [Chưa làm] 19 19. Sử dụng phương pháp Traceability để kiểm thử các yêu cầu phần mềm 19 65 SE-K48 20. Hãy cho biết khái niệm ROI và phương pháp xác định ROI khi xây dựng 20 các yêu cầu phần mềm 20 21. Kỹ thuật quản lý thay đổi yêu cầu phần mềm 22 22. Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm 23 23. Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm 23 24. Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU) 24 25. Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm 24 26. Nêu phương pháp và kỹ thuật kiểm duyệt (review) lại các yêu cầu đã xây 24 dựng 24 27. Kiểm thử (testing) yêu cầu phần mềm 24 28. Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm 25 29. Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm 26 30. Nêu tên một số kỹ thuật phát hiện các yêu cầu phần mềm 28 31. Phân loại người sử dụng có vai trò như thế nào trong phát hiện các yêu cầu phần mềm. 28 32. Nêu tên các kỹ thuật mô hình hoá yêu cầu phần mềm. Hãy đưa ra giải thích ngắn gọn về đặc điểm của từng kỹ thuật. 28 33. Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS. 29 34. Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm. Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết. 29 35. Nêu các phương pháp theo dõi vết của yêu cầu phần mềm. 29 36. Quản lý thay đổi yêu cầu phần mềm 30 37. chức năng của EA hỗ trợ đặc tả yêu cầu phần mềm. 31 38. Các chức năng của EA hỗ trợ mô hình hóa yêu cầu phần mềm. 33 39. Các kỹ thuật trong EA giúp phân tích yêu cầu phần mềm. 34 Chương 2. Thiết kế phần mềm (Software Design) 36 1.Nêu quy trình thiết kế phần mềm mức Logic 36 2. Các phương pháp tạo các thiết kế mức logic (Logical Design) 36 3. Đặc tả tài liệu thiết kế mức logic 36 4. Kiểm thử và tối ưu thiết kế mức logic 37 5. Quá trình mô hình hóa dữ liệu mức logic 37 6. Quá trình và các phương pháp tạo các thiết kế mức vật lý 38 7. Nêu phương pháp xác định các yêu cầu đối với kiến trúc phần mềm 38 8. Nêu các hướng tiếp cận xây dựng kiến trúc phần mềm 39 9. Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability, 43 Performance, Security, Testability, Usability 43 10. Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability, Performance, Security, Testability, Usability. 44 12. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm Modifiability. 45 13. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm 45 Performance 45 65 SE-K48 14. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm 46 Security 46 15. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm 47 Testability 47 16. Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm Usability: 47 17. Phương pháp ATAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu 48 18. Phương pháp CBAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu 48 Câu 19: Đặc điểm và bản chất của phương pháp Function-oriented(structured) Design 49 Câu 20: Đặc điểm và bản chất của phương pháp Object-Oriented Design 49 Câu 21: Đặc điểm và bản chất của phương pháp Data-structure Centered Design 51 22. Nêu đặc điểm và bản chất phương pháp Component-based Design (CBD) 51 23.Nêu khái niệm về MSF và các phase trong MSF 52 24.Nêu quá trình thiết kế giao diện và tương tác phần mềm 52 25.Nêu các yêu cầu của giao diện và tương tác 52 26.Nêu một số kỹ thuật trong thiết kế giao diện và tương tác 53 27.Đặc điểm mô hình hóa thiết kế dữ liệu mức khái niệm (conceptual data modeling) 53 28. Đặc điểm mô hình hóa dữ liệu mức khái niệm 54 29. Quá trình mô hình hóa dữ liệu mức khái niệm 54 30. Nêu một số các kỹ thuật trong mô hình hóa dữ liệu mức khái niệm [Chưa làm] 54 31. Đặc điểm mô hình hóa dữ liệu mức Logic 54 32. Quá trình mô hình hóa dữ liệu mức Logic 55 34. Nêu các kỹ thuật đảm bảo chất lượng phần mềm ở giai đoạn thiết kế 55 35. Nêu các đặc điểm trong giai đoạn ổn định và giai đoạn triển khai 56 36. Các yêu cầu của đặc tả phần mềm 56 37. Định dạng đặc tả phần mềm: Các loại tài liệu 57 38. Các quy định chung về định dạng đặc tả 57 39. Một số kỹ thuật chính trong thiết kế đặc tả 57 40. Nêu các phương pháp kiểm duyệt, kiểm thử và đánh giá các đặc tả phần mềm 58 Các tiêu thức để đánh giá một đặc tả: tính nhất quán, tính thân thiện dễ sử dụng. 58 41. Các chức năng của EA giúp thiết kế phần mềm mức Logic 59 42. Các chức năng của EA giúp phân tích các thuộc tính chất lượng của kiến trúc phần mềm. 59 Chương 3. Xây dựng phần mềm (Software Construction) 59 Câu 1:Trình tự thiết kế chi tiết 59 Câu 2: Nêu các kỹ thuật thiết kế thành phần phần mềm : Phân chia thành các thành phần,xác định đặc tả chức năng ,Giao diện giữa các thành phần 59 Câu 3: Nêu các 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ế màn hình ,Phương pháp kiểm tra vào /ra và thiết kế thông báo 60 Câu 4: Thiết kế dữ liệu vật lý 60 Câu 5: Nêu tên các tài liệu thiết kế chi tiết 61 Câu 6: Nêu tổ chức các tài liệu thiết kế chi tiết 61 65 SE-K48 7. Nêu các biểu mẫu thiết kế màn hình [Không chắc chắn]: 63 8. Nêu các biểu mẫu thiết kế báo cáo [Không chắc chắn]: 63 9. Nêu các phương pháp xét duyệt thiết kế chi tiết 63 10. Nêu trình tự thiết kế chương trình 63 11. Nêu các tiêu chuẩn thiết kế chương trình 64 12. Nêu các tiêu chuẩn phân chia module 64 13.[Thiếu] 65 14. Tạo tài liệu thiết kế chương trình. 65 15. Nêu các phương pháp xét duyệt thiết kế [Chưa làm]. 65 16. Nêu các phương pháp thiết kế chi tiết và sản xuất phần mềm [Chưa làm]. 65 17. Các chức năng của EA giúp thiết kế chi tiết phần mềm. 66 Câu 18. Các chức năng của EA giúp thiết kế dữ liệu mức vật lí. 66 65 SE-K48 Chương 0. Cơ sở của phân tích và thiết kế phần mềm 1. Nêu khái ni ệ m phân tích và thi ế t k ế ph ầ n m ề m (Software analysis and development) Thiết kế phần mềm bao gồm cả chu trình từ xác định kiến trúc, thành phần, giao diện và các nhân tố khác của một hệ thống hay một thành phần nào đó, lẫn kết quả của chu trình đó(định nghĩa của IEEE ). 2.Phân biệt khái niệm Phương pháp luận (methodologies) và 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 ra phần mềm. - Hiện tại có hai luồng chính của các 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 và phương pháp thiết kế…) + Object Oriented Methodology(phương pháp hướng đối tượng)(OOA/OOD…) - Được thiết kế ra để làm chuẩn hoá quá trình phần mềm - Phương pháp cụ thể trong một giai đoạn của phương pháp luận, thực hiện cụ thể của phương pháp luận. VD: SSADM: dùng 3 kĩ thuật chủ yếu: mô hình dữ liệu logic, mô hình luồng dữ liệu, mô hình ứng xử thực thể OOA/OOD: UML (Tham khảo K47) - Phương pháp luận là các hướng tiếp cận khi phân tích thiết kế phần mềm nói chung. Đây là các phương pháp tuân theo một chuẩn thiết kế nào đó được đưa ra nhằm làm chuẩn hóa quá trình thiết kế phần mềm. Ví dụ: phương pháp tiếp cận trên xuống, phương pháp tiếp cận hướng dữ liệu, … - Các kĩ thuật là các phương pháp được sử dụng để thực hiện một giai đoạn nào đó trong toàn bộ chu trình phát triển phần mềm. Ví dụ: o Phương pháp đặc tả hình thức là kĩ thuật dùng để mô tả các đặc tả của phần mềm dựa trên các luật hình thức. o Phương pháp Jackson là kĩ thuật dùng để định nghĩa thuật toán của một chương trình theo cấu trúc dữ liệu đầu vào. 3.Công cụ (tool): Vai trò, tác dụng. Nêu tên một số công cụ chính và ứng dụng của những công cụ này Trả lời : - Vai trò: cung cấp những hỗ trợ tự động hoặc bán tự động cho các quy trình và phương pháp phân tích thiết kế phần mềm. Nói cách khác công cụ chính là những phần mềm được tạo ra nhằm mục đích sử dụng chung. - Tác dụng: khi một công cụ được tích hợp thì những thông tin do nó tạo ra có thể được sử dụng cho việc xây dựng và phát triển các phần mềm khác. Chính vì vậy việc sử dụng công cụ có một số tác dụng như sau: 65 SE-K48 o Rút ngắn thời gian phát triển hệ thống o Kích cỡ phát triển được rút ngắn lại o Dịch vụ nâng cấp được kèm theo - Một số công cụ và vai trò của nó: o CAD: (Computer Aided Design) thiết kế có máy tính hỗ trợ. Người làm ra bản thiết kế bằng cách nhận sự hỗ trợ của 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ý và 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 một loạt các công việc bao gồm từ thiết kế sản phẩm, kiểm thử hiệu năng và chế tạo. 4. Phân tích viên (Software Analyst): Vai trò và vị trí của cán bộ này trong công ty phần mềm Trả lời : - Vai trò: nhìn nhận được các yêu cầu đặt ra đối với hệ thống cả về phía người dùng lẫn về phía hệ thống ví dụ như về quy mô hệ thống, về chức năng của hệ thống, lấy được các yêu cầu của khách hàng… Từ đó đề ra các chiến lược để thiết kế và phát triển hệ thống. Do đó phân tích viên cần phải có các yếu tố sau : o Am hiểu về công việc của công nghệ phần mềm. o Có nhiều kinh nghiệm và thành thạo trong lập trình phần mềm. o Có hiểu biết chung về nghiệp vụ. o Có các kĩ năng giải quyết vấn đề. o Khả năng giao tiếp tốt. o Linh hoạt và có khả năng thích nghi. - Vị trí: Có vị trí quan trọng đầu tiên trong một dự án. Nếu không đưa ra được những phân tích điểm lợi của dự án hay những điểm yếu cần khắc phục cũng như những yêu cầu cần thiết đặt ra của dự án thì có thể dẫn tới thất bại dự án. Trong một công ty phần mềm, là người chịu trách nhiệm phân tích những hướng phát triển trong tương lai của công ty cũng như đưa ra những ưu nhược điểm của các mô hình phát triển hiện thời mà công ty đang áp dụng. 5. Quá trình phát triển của phương pháp tiếp cận phân tích và 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 các giải thuật và xử lý dữ 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ý dữ liệu. o Cấu trúc dữ liệu thông thường không được thể hiện rõ o Nhược điểm của hướng tiếp cận: các tệp dữ liệu rất khó xây dựng để thỏa mãn phần mềm. - Hướng tiếp cận hướng dữ liệu: o Mô tả tổ chức của dữ liệu: mô tả dữ liệu được lấy ở đâu ra và sử dụng như thế nào o Mô hình dữ liệu được thành lập cũng như mối quan hệ giữa các dữ liệu này o Sử dụng các business rules dể chỉ ra phương pháp xử lý dữ 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 hiện bài toán 65 SE-K48 o Áp dụng phương pháp prototyping để nhah chóng xây dựng được phần mềm o Sử dụng các partern kiến trúc mẫu để chỉ ra phương pháp xử lý dữ liệu 6. So sánh các phương pháp tiếp cận phân tích và 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 dữ liệu So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm: - Phương pháp cổ điển: là phương pháp phân tích và thiết kế có cấu trúc. Các yêu cầu về hệ thống đích được phát triển được phân tích bằng việc đặc biệt chú ý tới chức năng của hệ thống và luồng dữ liệu giữa các chức năng. Mục đích của phương pháp này là chuyển các tiến trình trong biểu đồ DFD thành các module chương trình và tiến hành phân chia các module bằng cách tiếp cận trên xuống. - Phương pháp hướng tiến trình: việc phân tích và thiết kế đặt trọng tâm vào các chức năng do phần mềm thực hiện. Không có chuẩn rõ ràng để định nghĩa đơn vị chức năng do đó việc định nghĩa này có thể ảnh hưởng bởi cách nghĩ riêng của người thiết kế. Khó điều chỉnh các yêu cầu cho nhiều người dùng. Sử dụngc ác chức năng chồng chéo nhau là khó tránh khỏi. Kết quả là hệ thống bao gồm nhiều chức năng chồng chéo nhau là một trong những nhân tố làm cho việc bảo trì trở nên khó khăn. - Phương pháp hướng dữ liệu: dữ liệu không thay đổi bởi các yêuc ầu hay đòi hỏi của người dùng về thao tác nghiệp vụ. Trong thiết kế hướng dữ liệu hệ thống được thiết kế dựa trên cấu trúc tiến trình dữ liệu. Việc phân tích thiết kế được tiến hành cho dữ liệu được tách bạch với yêuc ầu hay đòi hỏi của người dùng về thao tác. Do vậy tiến trình được xác định và tích hợp vào trong các thủ tục chuyên dụng dữ liệu. 7. Hãy nêu phân loại phần mềm theo ứng dụng Phân loại phần mềm theo ứng dụng: - Phần mềm hệ thống - Phần mềm thời gian thực - Phần mềm quản lý - Phần mềm công nghệ và khoa học - Phần mềm nhúng - Phần mềm trí tuệ nhân tạo 8. [Thiếu] Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm 1. Mô tả quy trình công nghệ học yêu cầu phần mềm ( Requirement Engineering ). Quy trình công nghệ học phần mềm được chia thành 2 giai đoạn: Phát triển yêu cầu và Quản lý yêu cầu. Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn: Phát hiện yêu cầu, Phân tích yêu cầu, Đặc tả yêu cầu và kiểm thử yêu cầu. 65 SE-K48 HÌNH 1-2. Phân cấp công nghệ học yêu cầu. - Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn: Phát hiện yêu cầu Phân tích yêu cầu Đặc tả yêu cầu Kiểm thử yêu cầu. - Quản lý yêu cầu được hiểu là :”thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu của dự án phần mềm” (CMU/SEI 1995). Quản lý yêu cầu gồm các bước sau. Xác định giới hạn yêu cầu phần mềm. (Requirement baseline). Duyệt các giới hạn của phần mềm. Quản lý các thay đổi yêu cầu phần mềm. Quy trình phát triển được thể hiện trên hình vẽ sau: HÌNH 1-3. Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu. 65 SE-K48 Mô tả quy trình như sau: Maketing Customer Managerment lấy yêu cầu từ khách hàng, sau đó các yêu cầu đó được tổng hợp lại, phân tích, thỏa thuận với khách hàng, rà soát lại ( Đây là quá trình phát triển yêu cầu ). Kết quả của quá trình phát triển yêu cầu là bản Baseline Requrirements. Tài liệu này được chuyển chuẩn hóa và làm mốc cho cả quá trình thay đổi ( gọi là phiên bản cơ sở 1.0). Phiên bản cơ sở 1.0 được gửi cho khách hàng, bộ phận MCM lại tiếp tục đàn phán với khách hàng trên cơ sở phiên bản này, những yêu cầu thay đổi được tổng hợp, xử lý cập nhập lại Baseline Requirements. Với mỗi thay đổi cập nhập lại gồm : thay đổi cái gì, ai là người thay đổi, thay đổi ảnh hưởng như thế nào đến hệ thống, đề phòng ra sao. Tất cả các thông tin trên được chuẩn hóa thành phiên bản 1.1. Bây giờ phiên bản 1.1 được lấy làm cơ sở. Quy trình cứ tiếp tục cho đến khi có sự thống nhất từ khách hàng và đội phát triển. 2. Hãy nêu bản chất của yêu cầu phần mềm. Bản chất của yêu cầu phần mềm là mâu thuẫn. Sự mâu thuẫn thể hiện ở ý niệm về yêu cầu phần mềm xuất phát từ khách hàng và từ người sử dụng. • Các yêu cầu phần mềm xuất phát từ người sử dụng đối với người phát triển phần mềm thông thường quá trừu tượng, ở mức cao. • Ngược lại yêu cầu phần mềm được mô tả từ người phát triển đối với người sử dụng lại ở mức quá thấp, quá chi tiết cho nên người sử dụng không thể hiểu hết được. Vì sự mâu thuẫn đó nên IEEE 1997 đã đưa ra một định nghĩa yêu cầu phần mềm nhìn từ góc độ người sử dụng và người phát triển, và những yêu cầu đó cần được đúc kết thành một văn bản để thống nhất giữa 2 bên. Định nghĩa IEEE: • Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để giải quyết một vấn đề hoặc để giải quyết một mục tiêu. (1) • Điều kện hay khả năng cần phải thỏa mãn hoặc cần có của 1 hệ thống hoặc 1 thành phần hệ thống nhằm đáp ứng 1 hợp đồng, 1 tiêu chuẩn hoặc 1 đặc tả của một tài liệu khác.(2) • Văn bản thể hiện các điều kiện khả năng được thể hiện ở (1) và (2). 3. Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng. Định nghĩa IEEE về yêu cầu phần mềm từ phía khách hàng: • Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để giải quyết một vấn đề hoặc để giải quyết một mục tiêu. (1) 4. Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm Thói quen tốt: • Luôn hỏi lại người dùng những gì mình chưa hiểu hết về yêu cầu của họ. • Không chỉ khảo sát yêu cầu với một loại người sử dụng, mà phải bao quát tất cả những người sử dụng. • Đánh dấu những điểm chưa rõ trong đặc tả: Đôi khi chúng ta thiếu một số thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với người sử dụng để hiểu 65 SE-K48 chi tiết hơn. Tất cả những chỗ như vậy đc đánh đấu là TBD( Tobe determined). Tất cả TBD này phải đc giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm. Thói quen không tốt: • Tự mình nghĩ ra những yêu cầu của người dùng, hay tự cho mình là người dùng phần mềm. • Người sử dụng là chuyên viên trong lĩnh vực nào đó nên có thói quen nghĩ là tất cả các phân tích viên đề là các chuyên gia trong lĩnh vực đó Đưa ra các yêu cầu ngắn gọn mà ko miêu tả kỹ lưỡng hơn chúng là gì. 5. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (interview). Đặt ra các câu hỏi về bản chất của các vấn đề người dùng. Để giải quyết vấn đề này, cần sử dụng các câu hỏi: - Người sử dụng là ai? - Khách hàng là ai? - Nhu cầu của họ có khác nhau không? - Trong trường hợp nào thì có thể tìm thấy giải pháp cho vấn đề này? Nội dung của cuộc phỏng vấn có thể được thực hiện theo mẫu như sau: - Thiết lập tiểu sử người dùng hay khách hàng. - Đi vào vấn đề - Tìm hiểu về môi trường người dùng - Tóm tắt lại những gì thu được. - Phân tích đầu vào trên các vấn đề của khách hàng. - Đi vào giải pháp của mình (nếu thích hợp). - Đi vào cơ hội. - Đi vào sự đáng tin cậy, hiệu quả và các nhu cầu hỗ trợ. - Những yêu cầu khác - Bao quát lại - Tổng kết phân tích. Những điểm cần lưu ý khi tiến hành phỏng vấn: - Chuẩn bị trước nội dung cần phỏng vấn. Xem lại các câu hỏi trước khi tiến hành phỏng vấn. - Trước cuộc phỏng vấn nên tìm hiểu về nền tảng của các bên liên quan và công ty được phỏng vấn. - Ghi lại những câu trả lời trong quá trình phỏng vấn (Không cố gắng lấy ra thông tin trong lúc này). - Tham khảo mẫu trong quá trình phỏng vấn để đảm bảo đặt ra những câu hỏi đúng đắn. 6. Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Hội thảo. [...]... 2 Thi t kế phần mềm (Software Design) 1.Nêu quy trình thi t kế phần mềm mức Logic • Thi t kế mức logic là sự mô tả giải pháp về mặt tổ chức, cấu trúc và mối quan hệ giữa các phần của giải pháp từ góc nhìn của đội dự án • Pha thi t kế logic bắt đầu sau pha thi t kế mức khái niệm • Quy trình: o Phân tích thi t kế mức logic: o Lọc danh sách các công cụ và công nghệ thích hợp o Xác định các dịch vụ và. .. và các mối quan hệ chủ đạo o Tối ưu thi t kế logic: o Trau chuốt thi t kế logic o Kiểm tra, phê chuẩn thi t kế logic • Đầu ra của thi t kế logic: o Mô hình đối tượng mức logic o Thi t kế giao diện người dùng ở mức cao o Mô hình dữ liệu mức logic Đầu ra của thi t kế logic là cơ sở cho thi t kế vật lý 2 Các phương pháp tạo các thi t kế mức logic (Logical Design) Sử dụng lược đồ usecase để tạo thi t kế. .. cầu phần mềm để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống Các liên kết này thường được thể hiện giữa các thành phần: • Các trường hợp sử dụng (yêu cầu phần mềm) • Các yêu cầu chức năng (functional requirement) • Các thành phần thi t kế( design element) • Mã chương trình (code) • Trường hợp kiểm thử(test case) Đảm bảo yêu cầu phần mềm( Thẩm định&xác minh các yêu cầu phần mềm) :... ràng buộc lên thi t kế hoặc triển khai như hiệu suất , chất lượng…) 23 Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm Là hiểu biết hệ thống của khách hang vào thời điểm thi t kế và phát triển phần mềm Đó là hợp đồng đảm bảo về cả khách hang và sự hiểu biết hệ thống,các nhu cầu khác trước khi ấn định thời điểm 65 SE-K48 24 Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU) -Giao... xây dựng phần mềm hợp lý -Tôn trọng khách hàng, ngay cả khi phương pháp của khách hàng khác với mình, vì có thể đó là ý tưởng mới! -Kết thúc quá trình trao đổi, cần viết các đặc tả phần mềm 14 Trình bày các bước (quy trình) Phân tích các yêu cầu phần mềm Sau khi thu thập được các thông tin về yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân tích các yêu cầu đó Mục đích của việc phân tích này là... đưa thêm vào hoặc các yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thi t Kiểm tra khả năng đáp ứng về mặt kỹ thuật Đặc tả rõ ràng và chi tiết các yêu cầu - Tiêu chí kiểm thử yêu cầu phần mềm Hoàn thi n Chính xác Khả thi Cần thi t Rõ ràng Kiểm tra được, xác minh được - Quy trình kiểm thử yêu cầu phần mềm: • Bussiness Requirement • Use Case • Functional Requirement Các công cụ sử... theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm Phương pháp theo dõi các yêu cầu phần mềm: Theo dõi dấu vết của một yêu cầu phần mềm cho phép chúng ta quản lý được các yêu cầu phần mềm này, nguồn gốc của nó, các mối liên quan của nó và cách thực hiện, kiểm thử, bảo dưỡng và phát triển nó 04 thao tác cần thi t với quá trình theo dõi dấu vết của một yêu cầu phần mềm: • Forward to Requirement:... khách hàng -Trong quá trình trao đổi, sử dụng các ngôn từ thông dụng, không sử dụng nhiều các thuật ngữ tin học -Cần trao đổi về công việc của khách hàng, nắm bắt, học và hiểu các công việc đó(để khi thi t kế và xác định chức năng cho phần mềm chính xác) Yêu cầu khách hàng giải thích từng đặc điểm công việc nếu chưa hiểu rõ để phần mềm được làm ra sẽ tốt và dễ sử dụng hơn -Khi xác định được các yêu cầu... máy tính, các thi t bị ngoại vi đang có, và ảnh hưởng của chúng lên phần mềm sẽ xây dựng Nó xác định cách mà phần mềm mới phải tương tác với hệ thống đã có và những ràng buộc quan trọng phải được quản lý cẩn thận • Software Requirement được hiểu là các yêu cầu về phần mềm bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thi t kế và giao diện, các yêu cầu đặc biệt khác do... phát triển phần mềm Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của 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 là một quá trình kiểm tra các yêu cầu phần mềm, từ đó đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên là người sử dụng và người phát triển hệ thống Tại sao phải kiểm thử yêu cầu phần mềm: 65 SE-K48 . 65 SE-K48 ĐỀ CƯƠNG PHÂN TÍCH VÀ THI T KẾ PHẦN MỀM ************************* ĐỀ CƯƠNG PHÂN TÍCH VÀ THI T KẾ PHẦN MỀM 1 ************************* 1 Chương 0. Cơ sở của phân tích và thi t kế phần mềm. 3: Nêu các 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ế màn hình ,Phương pháp kiểm tra vào /ra và thi t kế thông báo 60 Câu 4: Thi t kế dữ liệu vật lý. nêu phân loại phần mềm theo ứng dụng Phân loại phần mềm theo ứng dụng: - Phần mềm hệ thống - Phần mềm thời gian thực - Phần mềm quản lý - Phần mềm công nghệ và khoa học - Phần mềm nhúng - Phần