›
›

Giáo trình Công nghệ phần mềm - Chương 4: Quy trình xác định yêu cầu

pdf 75 trang Gia Huy 17/05/2022 3841
Download
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Công nghệ phần mềm - Chương 4: Quy trình xác định yêu cầu", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfgiao_trinh_cong_nghe_phan_mem_chuong_4_quy_trinh_xac_dinh_ye.pdf

Nội dung text: Giáo trình Công nghệ phần mềm - Chương 4: Quy trình xác định yêu cầu

  1. Bài 2 Phân tích và đặc tả yêu cầu 1
  2. Phân tích và đặc tả yêu cầu • Vai trò của phân tích và đặc tả • Một số kỹ thuật mô hình hóa • Đặc tả yêu cầu • Định dạng tài liệu yêu cầu 2
  3. Tài liệu „ N.V. Vỵ, N. V. Hà, Giáo trình kỹ nghệ phần mềm, ch−ơng 2. „ N.V. Vỵ, Phân tích thiết kế HTTT hiện đại – H−ớng cấu trúc và h−ớng đối t−ợng, NXB Thống kê „ Zhiming Liu, Object-Oriented Software Development with UML, UNU/IIST Report „ Sommerville, Software Engineering „ Pressman, Software Engineering 3
  4. Khái niệm, tầm quan trọng „ Phân tích yêu cầu là khâu kỹ thuật đầu tiên, bao gồm nhiều b−ớc nhỏ: „ nghiên cứu khả thi „ phân tích, mô hình hóa „ đặc tả, „ thẩm định yêu cầu „ Là sự phối hợp cả nhà phát triển và khách hàng „ Có vai trò đặc biệt quan trọng trong tiến trình phát triển phần mềm 4
  5. Giá phải trả cho sự tìm và sửa lỗi 5
  6. Quá trình hình thành yêu cầu 6
  7. 2.1 Phân tích yêu cầu • Tìm hiểu xem hệ thống cần làm cái gì? • Cần tuân thủ những ràng buộc gì? (tài liệu yêu cầu là cơ sở của hợp đồng đ−ợc ký) "Đặc tả yêu cầu phần mềm" • hiểu vấn đề • chi tiết hóa đặc tả bài toán • biểu diễn lại 7
  8. Phân tích yêu cầu: các công đoạn „ Xác định khách hàng, cùng khách hàng phát hiện các yêu cầu „ Xây dựng mô hình phân tích (hiểu bài toán) „ dữ liệu „ chức năng „ trạng thái „ Làm bản mẫu đối với các chức năng ch−a rõ ràng „ Tạo đặc tả yêu cầu phần mềm „ Thẩm định đặc tả yêu cầu 8
  9. Khó khăn của phân tích „ Khách hàng chỉ có khái niệm mơ hồ về yêu cầu „ ng−ời phát triển phải chi tiết hóa thành các yêu cầu phần mềm có thể phát triển đ−ợc „ Khách hàng rất hay thay đổi yêu cầu „ ng−ời phát triển cần tỉnh táo để xác định đúng các yêu cầu (cái gì là cốt yếu, bền vững) 9
  10. Khó khăn trong phân tích(t) • Các yêu cầu th−ờng mang tính đặc thù - khó hiểu, khó định nghĩa - không có chuẩn biểu diễn • Hệ thống đa ng−ời sử dụng - yêu cầu đa dạng, mức −u tiên khác nhau - yêu cầu mâu thuẫn nhau • Ng−ời đặt hàng khác ng−ời dùng thực sự không nắm vững yêu cầu 10
  11. Mục tiêu và yêu cầu • Mục tiêu: là cái h−ớng tới Ví dụ:“Có giao diện thân thiện" • Yêu cầu: là cái cụ thể kiểm tra đ−ợc Ví dụ: "Giao diện đồ họa có các lệnh đ−ợc chọn bằng menu" nhiệm vụ của ng−ời phân tích là xác định các yêu cầu 11
  12. Các loại yêu cầu Có thể phân loại yêu cầu phần mềm thành: • Yêu cầu chức năng mô tả một chức năng (dịch vụ) cụ thể mà phần mềm cần cung cấp • Yêu cầu phi chức năng các ràng buộc về chất l−ợng, về môi tr−ờng, chuẩn sử dụng, qui trình phát triển phần mềm 12
  13. Yêu cầu phi chức năng • Yêu cầu về sản phẩm tốc độ, độ tin cậy, bộ nhớ, giao diện, qui trình tác nghiệp, • Yêu cầu về tiến trình phát triển các chuẩn, ph−ơng pháp thiết kế, ngôn ngữ lập trình • Yêu cầu ngoại lai về chi phí, về bản quyền, 13
  14. Tiến trình phân tích yêu cầu 14
  15. Nguyên lý phân tích 1 Mô hình hóa miền thông tin Phải hiểu và biểu diễn đ−ợc miền thông tin (problem domain): „ định danh dữ liệu (đối t−ợng, thực thể) „ xác định các thuộc tính của chúng „ thiết lập các mối quan hệ giữa các dữ liệu 15
  16. Nguyên lý phân tích 2 Mô hình hóa chức năng Bản chất của phần mềm là biến đổi thông tin „ định danh các chức năng (biến đổi thông tin) „ xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống (luồng dữ liệu) „ xác định các tác nhân tạo dữ liệu và tác nhân tiêu thụ dữ liệu (tác nhân) 16
  17. Nguyên lý phân tích 3 Mô hình hóa hành vi Phần mềm (hệ thống) có trạng thái (hành vi) „ xác định các trạng thái của hệ thống „ ví dụ: giao diện đồ họa, phần mềm điều khiển, „ xác định các dữ kiện làm thay đổi hành vi hệ thống „ ví dụ: bàn phím, chuột, các cổng thông tin 17
  18. Nguyên lý phân tích 4 Phân hoạch, làm mịn các mô hình Làm mịn, phân hoạch và biểu diễn các mô hình ở các mức khác nhau „ làm mịn các mô hình dữ liệu „ tạo cây (mô hình) phân rã chức năng „ biểu diễn hành vi ở các mức chi tiết khác nhau 18
  19. Nguyên lý phân tích 5 Tim hiểu vấn đề bản chất „ Nhìn nhận bản chất của yêu cầu (làm gì?, điều kiện gì?) - What? „ Ch−a quan tâm đến cách thức cài đặt (làm nh− thế nào?) – How? 19
  20. Ph−ơng pháp thu thập yêu cầu • Phỏng vấn • Quan sát • Điều tra bằng bảng hỏi • Nghiên cứu tài liệu • Joint Application Design - JAD 20
  21. Phỏng vấn • Chuẩn bị: kế hoạch, danh sách tham dự, địa điểm, • Câu hỏi: - câu hỏi có/không - câu hỏi mô tả • Cách thức tiến hành: - theo nhóm, ít nhất 2 ng−ời - phân công hỏi và ghi chép 21
  22. Các mức trừu t−ợng của yêu cầu Yêu cầu nên đ−ợc biểu diễn ở nhiều mức trừu t−ợng khác nhau Có nhiều đối t−ợng ng−ời đọc: • ng−ời sử dụng • nhà quản lý • lập trình viên • kỹ s− bảo trì 22
  23. Các mức trừu t−ợng của yêu cầu Xác định yêu cầu: • mô tả các dịch vụ mà phần mềm cung cấp • viết bằng ngôn ngữ tự nhiên • h−ớng ng−ời dùng Đặc tả yêu cầu: • tài liệu có cấu trúc • mô tả chi tiết, chính xác về yêu cầu • dùng làm bản hợp đồng 23
  24. Ví dụ: chức năng kiểm tra chính tả Định nghĩa: thông báo các lỗi chính tả của văn bản Đặc tả: - các lỗi chính tả đ−ợc gạch đỏ bên d−ới - lỗi soạn thảo đ−ợc gạch xanh bên d−ới Lỗi chính tả: - từ đơn không có trong từ điển Lỗi soạn thảo: - thừa dấu cách - không viết hoa đầu câu 24
  25. Đòi hỏi đối với đặc tả yêu cầu • Tính đầy đủ - mọi yêu cầu của ng−ời dùng phải đ−ợc mô tả • Tính không đ−ợc mâu thuẫn lẫn nhau • Tính chính xác: yêu cầu không đ−ợc mơ hồ -ng−ời phát triển sẽ làm cái nhỏ nhất - chi phí phát sinh do sửa đổi yêu cầu rất cao 25
  26. Thẩm định yêu cầu Nội dung cần thẩm định đặc tả yêu cầu: 1.Thỏa mãn đ−ợc nhu cầu của ng−ời dùng 2.Yêu cầu không mâu thuẫn nhau 3.Yêu cầu phải đầy đủ (chức năng; ràng buộc) 4.Yêu cầu phải hiện thực 26
  27. Quan hệ giữa phân tích và thiết kế • Phân tích chỉ nên đ−a ra giả sử tối thiểu về thiết kế hệ thống • Yêu cầu phải không mâu thuẫn với kỹ thuật máy tính và tài nguyên hiện có 27
  28. 2.2 Một số ph−ơng pháp mô hình hóa • Biểu đồ phân rã chức năng • Biểu đồ luồng dữ liệu • Biểu đồ thực thể quan hệ • Mô hình hóa h−ớng đối t−ợng 28
  29. Biểu đồ phân rã chức năng Function Decomposition Diagram - FDD • Xác định phạm vi của hệ thống • Phân hoạch chức năng • Tạo nền tảng cho thiết kế kiến trúc hệ thống 29
  30. Ví dụ: Biểu đồ phân rã chức năng 30
  31. Biểu đồ luồng dữ liệu Data Flow Diagram - DFD • Cách thức dữ liệu đ−ợc xử lý trong hệ thống • Có nhiều mức chi tiết khác nhau (phân tích có cấu trúc) • Có nhiều biến thể và mở rộng khác nhau - hệ thời gian thực 31
  32. DFD: Khái niệm Tác nhân ngoài: - đối t−ợng bên ngoài hệ thống - phát sinh hoặc tiếp nhận thông tin Tiến trình: thao tác đối với thông tin (biến đổi) Luồng dữ liệu: - luồng thông tin di chuyển trong hệ thống Kho dữ liệu: nơi l−u trữ dữ liệu 32
  33. DFD: Ký pháp Có nhiều cách biểu diễn khác nhau tác nhân tiến trình luồng dữ liệu kho dữ liệu 33
  34. DFD - Các b−ớc xây dựng • Phân rã chức năng hệ thống • Liệt kê các tác nhân, các khoản mục dữ liệu • Vẽ DFD cho các mức 34
  35. DFD – Một số nguyên tắc • Các tiến trình phải có luồng vào và luồng ra • Không có luồng dữ liệu trực tiếp giữa tác nhân với tác nhân hay kho dữ liệu • Luồng dữ liệu không quay lại nơi xuất phát • Bắt đầu bằng DFD mức 0, liệt kê các tác nhân ngoài ở mức 0 35
  36. Cấp bậc DFD a b x P y level 0 c p2 a f p1 p4 b d p5 p3 e g level 1 36
  37. Biểu đồ ngữ cảnh • Hệ thống mô tả bằng một tiến trình • Không có kho dữ liệu • Liệt kê các tác nhân ngoài đặt vé hệ thống khách hàng bán vé vé DFD hệ thống bán vé 37
  38. DFD mức 1 khách hàng bảng giờ tầu Kiểm tra Phân tích giờ tầu yêu cầu Đặt chỗ Phát hành khách hàng vé chỗ đã đặt bảng giá vé 38
  39. Biểu đồ thực thể - quan hệ Entity - Relation Diagram Phân tích cấu trúc dữ liệu thực thể thuộc tính quan hệ kế thừa 39
  40. Tầm quan trọng của E-R „ Phân tích dữ liệu độc lập với xử lý „ Nghiên cứu miền thông tin „ Tạo ra mô hình trừu t−ợng h−ớng khách hàng „ Xác định mối liên hệ giữa các dữ liệu 40
  41. E-R: định nghĩa Thực thể: - là các đối t−ợng thế giới thực mà chúng ta muốn xử lý - có thể là đối t−ợng thực hoặc trừu t−ợng Thuộc tính: đặc điểm của thực thể Quan hệ: - mối liên hệ giữa các thực thể - là thông tin cần l−u trữ/xử lý Kế thừa: - quan hệ kế thừa giữa các thực thể 41
  42. E-R: Ví dụ tên mã sv địa chỉ sinh viên phim l−u bản sao trữ 42
  43. E-R: Ví dụ name label text icon image text label 43
  44. Lực l−ợng tham gia quan hệ (0, m) object relationship object 1 (1, 1) 2 object relationship 1 object2 (0, m) (1, 1) 44
  45. E-R: Xác định thực thể và quan hệ Thực thể: - là các danh từ (trong câu mô tả yêu cầu) - có các thuộc tính khóa (xác định duy nhất) Quan hệ: - hoạt động xẩy ra giữa các thực thể - có nghĩa với hoạt động của hệ thống - là động từ 45
  46. E-R: Các b−ớc „ Mô tả các thực thể và sự liên kết giữa các thực thể „ Mô tả các thực thể và các mối quan hệ „ Mô tả các thực thể, mối quan hệ và các thuộc tính 46
  47. Từ điển dữ liệu „ Ph−ơng pháp (văn phạm) có tính hình thức để mô tả dữ liệu mà hệ thống xử lý „ Ký pháp để mô tả các dữ liệu điều khiển và miền giá trị của chúng (vd. on/off) „ Chứa đựng các thông tin về nơi (mô đun) và cách thức xử lý dữ liệu „ Th−ờng đ−ợc tạo bằng các công cụ trợ giúp (CASE) 47
  48. Khoản mục từ điển dữ liệu „ Tên (Name): tên dữ liệu „ Biệt danh (Aliases): tên gọi khác „ Vị trí (Where): tên các mô đun xử lý „ Cách thức (How): vai trò của dữ liệu, cách thức xử lý „ Ký pháp (Description): ký pháp mô tả dữ liệu „ Format: kiểu dữ liệu, giá trị mặc định 48
  49. Ví dụ từ điển dữ liệu integrated telephone number office system output phone system Build the requirements dictionary: Name: telephone number Aliases: phone number, number Where/How read-phone-number (input) used: display-phone-number (output) analyze-long-distance-calls (input) Description: telephone no. = [ local extension | outside no. | 0 ] outside no. = 9 + [ service code | domestic no. ] service code = [ 211 | 411 | 611 | 911 ] domestic no. = ( ( 0 ) + area code ) + local number area code = *three numeral designator* Format: alphanumeric data 49
  50. 2.3 Làm bản mẫu trong phân tích Trong nhiều tr−ờng hợp, mô hình chạy thử là ph−ơng pháp duy nhất để xác định yêu cầu phần mềm lớn, phức tạp bản mẫu (= trực quan) Các loại bản mẫu: • bản mẫu phần mềm: phát triển yêu cầu • bản mẫu phần cứng: kiểm tra thiết kế 50
  51. Các b−ớc làm bản mẫu B−ớc 1: Đánh giá yêu cầu và xác định có nên làm bản mẫu không độ phức tạp, chủng loại, khách hàng B−ớc 2: Biểu diễn vắn tắt yêu cầu yêu cầu chức năng/yêu cầu phi chức năng B−ớc 3: Thiết kế nhanh kiến trúc, cấu trúc dữ liệu 51
  52. Các b−ớc làm bản mẫu B−ớc 4: Phát triển, kiểm thử - sử dụng các thành phần sẵn có - dùng các ngôn ngữ bậc cao - các thuật toán dễ cài đặt B−ớc 5: Ng−ời dùng đánh giá b−ớc quan trọng nhất??? B−ớc 6: Lặp lại 2~5 cho đến khi đủ yêu cầu 52
  53. Ưu điểm • Loại bớt hiểu nhầm • Phát hiện thiếu hụt chức năng vd: soạn thảo kéo theo kiểm tra chính tả • Phát hiện các điểm yếu: - khó sử dụng, - thao tác không an toàn • Kiểm tra tính khả thi/hữu ích - có thể xây dựng đ−ợc không - có thực sự cần không 53
  54. Ưu điểm (t) • Làm cơ sở cho đặc tả làm phần mềm giống nh− thế này, nh−ng tốt hơn • Huấn luyện ng−ời sử dụng • Hỗ trợ kiểm thử (so sánh kết quả) làm bản mẫu là kỹ thuật tránh rủi ro 54
  55. Nh−ợc điểm của bản mẫu • Các yêu cầu phi chức năng th−ờng không đ−ợc thể hiện đầy đủ • Làm tăng chi phí: cần phải −ớc l−ợng chính xác chi phí của bản mẫu • Các yêu cầu thay đổi quá nhanh khiến bản mẫu trở nên vô nghĩa • Ng−ời dùng không dùng bản mẫu theo cách thông th−ờng (kết quả đánh giá không có giá trị) 55
  56. Ngôn ngữ làm bản mẫu „ Java „ Visual Basic „ Prolog, Lisp, Python „ Các ngôn ngữ script khác „ Perl, php, shell script 56
  57. Bản mẫu giao diện/ bản mẫu trực quan „ Sử dụng các ngôn ngữ/công cụ trực quan „ VB „ Delphi, J Builder „ FrontPage „ Sử dụng lại một l−ợng lớn các th− viện có sẵn „ Tính cấu trúc không cao, khó tích hợp kết quả của nhiều nhóm, khó bảo trì 57
  58. 2.4 Các ph−ơng pháp đặc tả Đặc tả phi hình thức • đặc tả bằng ngôn ngữ tự nhiên • dễ hiểu - không chặt chẽ, dẫn tới hiểu nhầm - có nhiều cách biểu diễn cho một khái niệm khó phân hoạch, khó sửa đổi "không ai biết chắc chắn phải làm gì khi ch−a có đặc tả" 58
  59. Các ph−ơng pháp đặc tả Đặc tả hình thức hình vẽ + biểu thức ??? - đặc tả bằng công thức toán học - đặc tả bằng sơ đồ - đặc tả bằng ngôn ngữ đặc tả "không ai biết chắc chắn phải làm gì khi ch−a có đặc tả" 59
  60. Đặc tả hình thức ::= | ::= { } ::= . { } | . { } E | E ::= | ::= + | - Pascal number syntax 60
  61. Đặc tả hình thức (t) unsigned integer digit unsigned number + unsigned integer . digit E unsigned integer - 61
  62. Đặc tả hình thức (t) • Ưu điểm tính chính xác (duy nhất) của định nghĩa đúng đắn??? • Nh−ợc điểm - khó hiểu, tốn thời gian mô tả - không áp dụng đ−ợc với mọi bài toán (các yêu cầu phi chức năng) phối hợp giữa đặc tả hình thức và đặc tả phi hình thức 62
  63. Các ngôn ngữ đặc tả hình thức Đặc tả yêu cầu: Z: mô tả biến đổi trạng thái Đặc tả thiết kế: - RAISE - flowchart, pseudo code 63
  64. Pseudo code Procedure Write_name if sex = male print “Mr.” else print “Ms.” print Name end Procedure 64
  65. DFD, E-R, UML vừa dùng cho phân tích, vừa h−ớng tới thiết kế 65
  66. 2.5 Tài liệu yêu cầu • Chỉ mô tả về chức năng, ràng buộc • Không mô tả về ph−ơng pháp cài đặt • Phải dễ thay đổi (có cấu trúc) - khó xác định đ−ợc đầy đủ chính xác ngay - phải qua nhiều b−ớc xét duyệt lại 66
  67. Định dạng của tài liệu yêu cầu Software Requirement Specification-SRS Chuẩn IEEE 830-1984 1. Giới thiệu 2. Mô tả chung 3. Yêu cầu chi tiết 67
  68. định dạng của tài liệu yêu cầu (SRS) 1. Giới thiệu 1.1 Mục đích 1.2 Phạm vi 1.3 Định nghĩa (định nghĩa, từ viết tắt) 1.4 Tài liệu tham khảo 1.5 Mô tả cấu trúc tài liệu 68
  69. định dạng của tài liệu yêu cầu (SRS) 2. Mô tả chung 2.1 Tổng quan về sản phẩm 2.2 Chức năng sản phẩm 2.3 Đối t−ợng ng−ời dùng 2.4 Ràng buộc tổng thể 2.5 Giả thiết và sự lệ thuộc 69
  70. định dạng của tài liệu yêu cầu (SRS) 3. Yêu cầu chi tiết 3.1 Yêu cầu chức năng 3.1.1 Yêu cầu chức năng 1 3.1.1.1 Giới thiệu 3.1.1.2 Dữ liệu vào 3.1.1.3 Xử lí 3.1.1.4. Kết quả 3.1.2 Yêu cầu chức năng 2 3.1.n Yêu cầu chức năng n 70
  71. định dạng của tài liệu yêu cầu (SRS) 3. Yêu cầu chi tiết 3.2 Yêu cầu giao diện ngoài 3.2.1 Giao diện ng−ời dùng 3.2.2 Giao diện phần cứng 3.2.3 Giao diện phần mềm 3.2.4 Giao diện truyền thông 3.3 Yêu cầu hiệu suất 3.4 Ràng buộc thiết kế 71
  72. 3. Yêu cầu chi tiết 3.5 Thuộc tính 3.5.1 Tính bảo mật 3.5.2 Tính bảo trì 3.6 Các yêu cầu khác Phụ lục 72
  73. Câu hỏi ôn tập 1. Phân tích yêu cầu nghĩa là gì? 2. Mục tiêu của phân tích yêu cầu là gì? 3. Các công đoạn của tiến trình phân tích yêu cầu? 4. Nhứng khó khăn của phân tích yêu cầu? 5. Có những loại yêu cầu nào? 6. Nêu những yêu cầu phi chức năng? 7. Nêu các nguyên lý của phân tích yêu cầu? 73
  74. Câu hỏi ôn tập 8. Nêu các ph−ơng pháp thu thập thông tin về yêu cầu? 9. Đặc tả yêu cầu cần có những tính chất gì? 10. Nội dung cần thẩm định yêu cầu là gì? 11.Các ph−ơng pháp mô hình hoá để phân tích yêu cầu là những ph−ơng pháp nào? 12.Nêu các b−ớc làm mẫu để xác định yêu cầu? 74
  75. Câu hỏi ôn tập 12.Ph−ơng pháp làm mẫu để xác định yêu cầu có những −u và nh−ợc điểm gi ? 13.Những ngôn ngữ nào đ−ợc dùng làm mẫu? 14. Có những loại ph−ơng pháp đặc tả nào? Mô tả tóm tắt nội dung của nó? 15. Trình bày nội dung đặc tả yêu cầu theo chuẩn IEEE 843-1984? 75