Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu

Nội dung text: Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu

1. NỘI DUNG 1. Tổng quan 2. Quá rình phân tích 3. Xác định yêu cầu 4. Mô hình hóa yêu cầu hệ thống Jens Martensson 2
2. 2.1. Tổng quan và đặc tả yêu cầu ❑Gồm các công đoạn: ❖Nghiên cứu tính khả thi ❖Phân tích mô hình ❖Đặc tả yêu cầu. ❑Được phối hợp giữa nhóm phát triển phần mềm và khách hàng ❑Yêu cầu của khách hàng được thu thập đầy đủ và chi tiết ❑Công cụ: các loại sơ đồ biểu diễn được các khái niệm và mô hình hóa được mối quan hệ giữa các đối tượng trong hệ thống. Jens Martensson 3
3. 2.2. Quá trình phân tích Bao gồm các bước phân tích: ✓Phân tích phạm vi dự án ✓Phân tích yêu cầu sẵn dùng ✓Phân tích mở rộng yêu cầu nghiệp vụ ✓Phân tích yếu tố con người ✓Phân tích yêu cầu bảo mật ✓Phân tích yêu cầu tích hợp ✓Phân tích yêu cầu tốc độ ✓Phân tích thực tiễn nghiệp vụ tồn tại ✓Phân tích yêu cầu vận hành ✓Phân tích yêu cầu khả năng và quy mô ✓Phân tích khả năng mở rộng yêu cầu Jens Martensson 4
4. 2.2. Quá trình phân tích Jens Martensson 5
5. 2.2.1 Phân tích phạm vi dự án ❑Xác định rõ quá trình nghiệp vụ mà phần mềm sẽ xử lý. ❑Một giải pháp nghiệp vụ gồm: ❖Phần triển khai phần mềm: Trong đó yêu cầu nghiệp vụ của khách hàng được hiện thực hóa thành phần mềm cụ thể, ❖Phần thực hiện bởi con người hay chương trình: Là giai đoạn vận hành sử dụng hệ thống Jens Martensson 6
6. 2.2.1 Phân tích phạm vi dự án ❑Mục đích của việc chia giải pháp nghiệp vụ thành 2 phần là: ❖Chia trách nhiệm thành những nhiệm vụ con tương ứng với việc chia chương trình thành các module. ❖Xác định bao nhiêu vùng địa lý liên quan (chi nhánh văn phòng), ❖Ước lượng số người dùng phần mềm, thời gian phần mềm được duy trì, ❖Biết được tính chính xác của yêu cầu phần mềm, ❖Hiểu khách hàng mong đợi dự án được triển khai ❖Xác định được phạm vi của dự án, dự đoán ngân sách, thời gian và nguồn nhân lực. Jens Martensson 7
7. 2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ ❑Xác định yêu cầu nghiệp vụ: ❖ Mỗi dự án sẽ có một hay nhiều yêu cầu nghiệp vụ (tác vụ) liên quan đến việc mô tả công việc cụ thể trong nghiệp vụ. ❖ Một tác vụ có thể được chia nhỏ thành nhiều phần đủ để mô tả công việc chính xác nhất. Jens Martensson 8
8. 2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ Jens Martensson 9
9. 2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ ❑Xác định yêu cầu chất lượng: ❖Mỗi dự án có các yêu cầu liên quan đến khả năng đáp ứng nhanh, bảo mật, phụ thuộc, dễ dùng ❖Chất lượng của dự án là trên mức độ chấp nhận, và sự thỏa mãn nhu cầu của khách hàng. Jens Martensson 10
10. 2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ ❑Phân tích cơ sở hạ tầng hiện hành: ❖Giải pháp PM đưa vào, nếu phù hợp với cơ sở hạ tầng thì sẽ tốt hơn là thay thế hệ thống hiện hành. ❖Sự tương thích với cơ sở hạ tầng hiện hành sẽ đảm bảo khả thi, vì dự án cần làm việc trên phần cứng và phần mềm hiện có. ❖Nếu biết được HĐH, loại mạng đang sử dụng, thông tin cấu hình của máy chủ, và những phần mềm không tương thích với chương trình mới thì sẽ giúp việc phân tích chính xác và hiệu quả hơn. Jens Martensson 11
11. 2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ ❑Phân tích ảnh hưởng kỹ thuật: ❖Nâng cấp, mở rộng chức năng cho hệ thống hiện hành hoặc thay mới. Tuy nhiên, cải thiện hệ thống cũ và tích hợp dễ dàng hơn hệ thống mới. ❑Ví dụ: hệ thống kế toán cũ lưu trữ dữ liệu trên MS Access. Khi nâng cấp hệ thống, có thể chuyển toàn bộ dữ liệu sang SQL Server. Jens Martensson 12
12. 2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ ❑Phân tích ảnh hưởng kỹ thuật: ❖Nên tìm hiểu sự khác biệt về giao tác, bảo mật, và những chức năng khác. ❖Nên tìm hiểu thủ tục chuyển đổi dữ liệu từ hệ thống cũ sang hệ thống mới, có kế hoạch bảo lưu khi việc thực hiện này bị lỗi. ❖Cần có biện pháp đảm bảo an toàn những dữ liệu. Jens Martensson 13
13. 2.2.3. Phân tích yêu cầu bảo mật ❑Xác định các vai trò người dùng của hệ thống: Một hệ thống phần mềm có nhiều mức độ bảo mật ❖Người dùng cuối: chỉ cần quyền truy xuất giới hạn. ❖Quản trị hệ thống: có quyền cao nhất. ❑Xử lý bảo mật phần mềm là kỹ thuật dùng để cấp quyền sử dụng với mức độ bảo mật khác nhau. Jens Martensson 14
14. 2.2.3. Phân tích yêu cầu bảo mật ❑Xác định môi trường bảo mật phần mềm ❖Người dùng phải đăng nhập vào hệ thống để thực hiện các chức năng theo quyền được cấp, nhằm để kiểm soát quyền truy cập các tài nguyên được chia sẽ như tập tin, dịch vụ hệ thống, CSDL. ❖Mức độ kiểm soát của phần mềm được gọi là ngữ cảnh bảo mật. ❖Độ bảo mật của phần mềm không bị giới hạn bởi người dùng. Jens Martensson 15
15. 2.2.3. Phân tích yêu cầu bảo mật ❑Xác định ảnh hưởng bảo mật: ❖Nếu hệ thống cũ có sẵn cơ chế bảo mật, thì hệ thống mới nên điều chỉnh cho phù hợp với cơ chế đã có. ❖Nếu đang thực hiện hệ thống bảo mật mới, cần phân tích tác động của hệ thống trên hệ thống hiện tại: – Hệ thống mới có làm hỏng chức năng của phần mềm hiện tại? – Hệ thống mới có đòi hỏi phải hỗ trợ thêm đăng nhập mở rộng? – Hệ thống mới có hạn chế một số người dùng những tài nguyên mà họ được quyền truy cập trước đây? Jens Martensson 16
16. 2.2.3. Phân tích yêu cầu bảo mật ❑Kế hoạch vận hành: ❖Khi tổ chức của khách hàng thay đổi nhân sự. Những thao tác này đòi hỏi hiệu chỉnh bảo mật CSDL. ❖Nếu người dùng có nhiều vị trí khác nhau, cần lên kế hoạch tái tạo bảo mật CSDL đã được lưu giữ ở các vị trí khác nhau, nhằm tạo thuận lợi cho người dùng là có thể đăng nhập bằng thông tin được lưu ở vị trí gần hơn so với vị trí gốc. Jens Martensson 17
17. 2.2.3. Phân tích yêu cầu bảo mật ❑Kế hoạch kiểm soát và đăng nhập: ❖File nhật ký giao dịch trợ giúp kiểm soát hoạt động cho vấn đề bảo mật, ghi lại tất cả các giao dịch trên hệ thống. ❖Phải lập kế hoạch kiểm soát nhật ký để phát hiện các giao dịch bất thường, và có đề nghị xử lý. Jens Martensson 18
18. 2.2.3. Phân tích yêu cầu bảo mật ❑Xác định mức độ yêu cầu bảo mật ❖Việc triển khai mức độ bảo mật cho phần mềm cần được cân nhắc dựa trên tính hiệu quả và chi phí. ❖Nếu hệ thống không lưu trữ dữ liệu có tính nhạy cảm cao, thì chỉ cần lưu trữ thông tin về “sự xác thực của người dùng”. ❖Nếu hệ thống có lưu trữ các thông tin cần bảo mật, thì cần có chi phí cho chức năng bảo mật và cần phải được kiểm chứng. Jens Martensson 19
19. 2.2.4. Phân tích yêu cầu tốc độ ❑Yêu cầu về tốc độ xử lý của phần mềm: là một yêu cầu khó đối với nhóm phát triển phần mềm. ❖Tốc độ xử lý của phần mềm là sự đáp trả của hệ thống đối với thao tác của người dùng. ❖Tốc độ của phần mềm phụ thuộc vào việc thiết kế hệ thống. ❖Đối với phần mềm phân tán, tốc độ xử lý của phần mềm còn tùy thuộc vào số người truy cập vào hệ thống tại cùng một thời điểm. Jens Martensson 20
20. 2.2.4. Phân tích yêu cầu tốc độ ❑Các yếu tố ảnh hưởng đến tốc độ của phần mềm ❖Tần suất giao dịch: số người sử dụng dịch vụ tại một thời điểm. ❖Băng thông: là một yếu tố ảnh hưởng đến tốc độ của phần mềm. ❖Khả năng chứa: Mức lưu trữ (bộ nhớ chính, phụ) khả năng sẵn sàng đáp ứng. ❖Nút thắt: tốc độ ổ cứng là nút thắt. Cần nhận biết nút thắt của để cải thiện chúng nhằm nâng cao tốc độ. Việc nhận biết nút thắt có thể thực hiện bằng công cụ báo cáo hệ thống Windows NT Performance Monitor. Jens Martensson 21
21. 2.2.5. Phân tích yêu cầu vận hành ❑Khi vận hành phần mềm, chi phí triển khai và chi phí vận hành là vấn đề quan trọng cần được xem xét như sau: ❖Chi phí triển khai có thể giảm nếu phân phối trực tuyến hoặc phần mềm tự động cài đặt, và thao tác vận hành có thể tự động hóa. ❖Nếu phần cứng, phần mềm là thành phần được mua, không được phát triển, thì chấp thuận vận hành từ nhà xưởng hay người ủy thác của sản phẩm. ❖Vận hành sản phẩm trung gian sẽ tiết kiệm chi phí thuê nhân viên mới hay huấn luyện nhân viên cũ để duy trì một hay nhiều thành phần của hệ thống Jens Martensson 22
22. 2.2.6. Phân tích khả năng mở rộng yêu cầu ❑ Theo thời gian, những yêu cầu của giải pháp ban đầu sẽ thay đổi. Nhu cầu của người dùng cũng thay đổi. Do đó đòi hỏi phần mềm cũng phải được mở rộng và cập nhật theo các yêu cầu thay đổi. ❑ Phần mềm thiết kế tốt là phần mềm có khả năng mở rộng được và có thể uyển chuyển cải thiện mà không phải xây dựng lại hoàn toàn. Jens Martensson 23
23. 2.2.6. Phân tích khả năng mở rộng yêu cầu ❑Cách đạt đến những khả năng hạn định: ❖Lưu trữ thông tin và quy tắc nghiệp vụ vào cơ sở dữ liệu ❖Khi chức năng hay thủ tục của phần mềm cần thay đổi, thì thay đổi trong cơ sở dữ liệu mà không cần thay đổi mã nguồn chương trình. ❖Đặt mã nguồn vào trong đoạn mã kịch bản (script) được làm rõ hơn khi biên dịch chương trình; đoạn script có thể bị thay đổi một cách dễ dàng không đòi hỏi bất kỳ biên dịch hay cài đặt lại tập tin nhị phân. ❖Chia phần mềm thành những đối tượng thành phần với nhiệm vụ riêng lẻ. ❖Nếu yêu cầu của các nhiệm vụ thay đổi, thì chỉ đối tượng tương ứng bị thay đổi và biên dịch lại mà không ảnh hưởng đến các thành phần khác. Jens Martensson 24
24. 2.2.7. Phân tích yêu cầu sẵn dùng ❑Phần mềm có tính sẵn sàng cao là những phần mềm không lỗi, không phát sinh các hỏng hóc. Khi một thành phần nào bị hỏng thì chỉ cần khởi động lại sẽ hoạt động bình thường. ❖Việc bảo trì có kế hoạch cũng tác động đến tính sẵn sàng của phần mềm. ❖Một máy chủ chứa các phần mềm lý tưởng luôn có bản sao lưu có thể khởi động khi máy chủ bảo trì. ❖Phần mềm có độ sẵn sàng cao cần có cách luân phiên để kết nối mạng trong trường hợp mạng WAN, LAN ngưng hoạt động. Jens Martensson 25
25. 2.2.8. Phân tích yếu tố con người ❑Yếu tố con người đóng vai trò rất quan trọng trong thiết kế phần mềm, khi thiết kế phần mềm cần phải: ❖Xác định mục tiêu của người dùng, từ đó xác định được các dạng người dùng và những nhu cầu đặc biệt liên quan, nhằm thiết kế phần mềm thích hợp với yêu cầu của người dùng. ❖Xác định những kinh nghiệm sử dụng phần mềm của người dùng. Jens Martensson 26
26. 2.2.9. Phân tích yêu cầu tích hợp ❑Nếu nâng cấp từ một hệ thống cũ, yêu cầu chuyển đổi dữ liệu từ hệ thống cũ sang hệ thống mới thì cần phải có kế hoạch tích hợp từ công cụ có sẵn hoặc xây dựng các tiện ích chuyển đổi. ❑Nếu nhu cầu lưu trữ dữ liệu lớn thì có thể phải xây dựng lại CSDL dựa trên cấu trúc của CSDL hiện tại để tránh phá vỡ mã nguồn của CSDL hiện tại. Jens Martensson 27
27. 2.2.10. Phân tích thực tiễn nghiệp vụ ❑Phân tích thực tiễn nghiệp vụ giúp nhóm dự án hiểu được những nghiệp vụ của doanh nghiệp, xây dựng chức năng phần mềm chính xác hơn, tránh được sai sót. ❖Hiểu được cấu trúc tổ chức và sơ đồ nghiệp vụ của doanh nghiệp là yếu tố quyết định sự thành công của bước phân tích yêu cầu và xây dựng phần mềm. ❖Tìm hiểu những tiến trình, chính sách liên quan trên phần mềm mới Jens Martensson 28
28. 2.2.11. Phân tích yêu cầu khả năng và quy mô ❑Quy mô của phần mềm: là khả năng phục vụ người dùng ❖Để nâng cao khả năng phục vụ, là nâng cấp cơ sở hạ tầng (CPU nhanh, nhiều RAM, ) cả phía người dùng và phía hệ thống (máy chủ). ❖Giải pháp khác là phát triển phần mềm phân tán để có thể hoạt động trên nhiều máy chủ cùng lúc, giúp kiểm soát và đáp ứng việc phân phối tài nguyên và thời gian xử lý. Jens Martensson 29
29. 2.3 . Xác định yêu cầu ❑Mục tiêu của việc xác định yêu cầu: Xác định chính xác và đầy đủ các yêu cầu của phần mềm sẽ được xây dựng. Kết quả của giai đoạn xác định yêu cầu: ❖Danh sách các công việc (liên quan đến những chức năng của phần mềm) sẽ được thực hiện trên máy tính ❖Những mô tả chi tiết về các công việc này khi được triển khai vận hành trong thế giới thực ❖Thông tin khái quát về các hoạt động trong thế giới thực. Jens Martensson 30
30. 2.3.1. Yêu cầu và mô tả yêu cầu ❑Yêu cầu: Là công việc mà phần mềm phải thực hiện, xuất phát từ yêu cầu của khách hàng. ❑Mô tả yêu cầu: ❖Mô tả đầy đủ, rõ ràng và chi tiết các thông tin liên quan đến công việc tương ứng mà phần mềm phải thực hiện, mô tả này phải được nhóm phần mềm và khách hàng hiểu rõ và thống nhất. ❖Bảng mô tả yêu cầu được dùng làm cơ sở để nghiệm thu và đánh giá phần mềm khi được chuyển giao. Jens Martensson 31
31. 2.3.1. Yêu cầu và mô tả yêu cầu ❑Các thông tin trong bảng xác định yêu cầu phần mềm ❖Tên công việc ứng với từng yêu cầu: Cần xác định cụ thể, tránh dùng các tên chung chung, mơ hồ (như “Quản lý độc giả” là chung chung, nên cụ thể hơn như “Đăng ký mượn sách”, “Gia hạn thẻ độc giả”, “Trả sách”) ❖Xác định chính xác người dùng: Những người dùng có vai trò và công việc tương tự nhau sẽ được xếp vào cùng loại. Cùng một công việc có thể có nhiều loại người dùng khác nhau; một loại người dùng có thể thực hiện nhiều công việc khác nhau. Jens Martensson 32
32. 2.3.1. Yêu cầu và mô tả yêu cầu ❑Các thông tin trong bảng xác định yêu cầu phần mềm ❖Xác định chính xác địa điểm, thời điểm tiến hành công việc. ❖Quy trình thực hiện công việc và các quy tắc liên quan, cần phải kiểm tra khi thực hiện công việc. ❑Ví dụ: chương trình quản lý thư viện ❖Chỉ cho những độc giả có thẻ độc giả còn hạn mượn sách, số sách tối đa là 1 và không có sách mượn quá hạn. ❖Mỗi ngày trả trễ phạt 1500 đồng/ngày. Từ ngày trả trễ thứ 10 trở đi sẽ phạt 5000 đồng/ngày, thu hồi thẻ độc giả 2 tuần Jens Martensson 33
33. 2.3.2. Phân loại yêu cầu Jens Martensson 34
34. 2.3.2. Phân loại yêu cầu ❑Yêu cầu chức năng: Danh sách công việc được thực hiện trên máy tính và các thông tin mô tả. ❖Yêu cầu chức năng nghiệp vụ: Các chức năng phần mềm tương ứng với nghiệp vụ của doanh nghiệp. – Chức năng lưu trữ: Tương ứng với công việc ghi chép. Ví dụ: Ghi nhận việc cho mượn sách của một thư viện theo quy định mượn. – Chức năng tra cứu: tìm kiếm, theo dõi hoạt động và xem thông tin về một đối tượng. – Chức năng tính toán: thống kê, tính toán – Chức năng kết xuất: lập báo cáo (theo biểu mẫu). Jens Martensson 35
35. 2.3.2. Phân loại yêu cầu ❖Yêu cầu chức năng hệ thống: Các chức năng phần mềm phát sinh thêm khi thực hiện công việc của phần mềm. – Chức năng môi trường: Định cấu hình thiết bị, thời gian, nhân sự (Số nhân công, loại máy in, ) – Chức năng mô phỏng: Mô phỏng hoạt động của thế giới thực. – Chức năng tự động: Tự động thông báo, nhắc nhở người dùng – Chức năng phân quyền: Phân quyền sử dụng cho các loại người dùng – Quản trị hệ thống: phân quyền người dùng – Chức năng sao lưu: Sao lưu, phục hồi dữ liệu. Jens Martensson 36
36. 2.3.2. Phân loại yêu cầu ❑Yêu cầu phi chức năng: Các yêu cầu liên quan đến chất lượng phần mềm, các ràng buộc cách thực hiện các yêu cầu chức năng. ❖Liên quan đến người dùng cuối – Tính tiến hóa: cho phép người dùng thay đổi lại cách mô tả của yêu cầu chức năng – Tính tiện dụng: giao diện, than thiện, dễ sử dụng, dễ học, đầy đủ thông tin. – Tính hiệu quả: thời gian đáp trả nhanh, dung lượng lưu trữ, chi phí sử dụng tài nguyên hệ thống như sử dụng tối ưu các không gian. – Tính tương thích: Các yêu cầu liên quan đến việc chuyển đổi dữ liệu giữa phần mềm đang xét và các phần mềm khác, sự nhất quán giữa các màn hình trong hệ thống Jens Martensson 37
37. 2.3.2. Phân loại yêu cầu ❖Yêu cầu liên quan đến các chuyên viên tin học – Tính tái sử dụng: khả năng sử dụng lại các thành phần của hệ thống phần mềm cho các hệ thống khác tương đương. – Tính bảo trì: dễ bảo trì, dễ nâng cấp, khi bảo trì sẽ không ảnh hưởng đến dữ liệu trong hệ thống. Jens Martensson 38
38. 2.3.3. Các bước xác định yêu cầu ❑Bước 1: ❖Thực hiện: Khảo sát hiện trạng ❖Kết quả: bảng báo cáo hiện trạng. ❑Bước 2: ❖Thực hiện: Lập danh sách các yêu cầu ❖Kết quả: danh sách các yêu cầu sẽ được thực hiện trên máy tính. Jens Martensson 39
39. 2.3.3. Các bước xác định yêu cầu ❑Đối tượng tham gia xác định yêu cầu: ❖Chuyên viên tin học: Là những người hiểu rõ về khả năng của máy tính, có kiến thức về tin học. Họ lắng nghe chuyên gia để hiểu rõ về nghiệp vụ của hệ thống. ❖Chuyên gia: Là những người có kiến thức chuyên môn và nghiệp vụ của doanh nghiệp. Họ cần lắng nghe ý kiến của các chuyên viên tin học để đảm bảo các yêu cầu của họ là có thể thực hiện được trên phần mềm với chi phí và thời gian hợp lý. Jens Martensson 40
40. 2.3.3.1. Khảo sát hiện trạng ❑Các hình thức thực hiện phổ biến: ❖Quan sát: Theo dõi các hoạt động diễn ra ở thế giới thực có liên quan, có thể ghi âm, ghi hình đối với những tình huống mang tính phức tạp, quan trọng, cần sự chính xác cao ❖Phỏng vấn trực tiếp: Tổ chức phỏng vấn bắt đầu từ cấp lãnh đạo dần xuống các vị trí công việc. Có thể sử dụng các bảng câu hỏi có sẵn các câu trả lời cho đối tượng được phỏng vấn lựa chọn ❖Thu thập thông tin, tài liệu: Các công thức tính toán, quy định; các bảng biểu, mẫu giấy tờ có ít nhiều liên quan. Ví dụ: Phiếu mượn sách tại thư viện. Jens Martensson 41
41. 2.3.3.1. Khảo sát hiện trạng ❑Quy trình thực hiện: ❖Tìm hiểu tổng quan về thế giới thực: Quy mô hoạt động và các hoạt động mà đơn vị có tham gia. ❖Tìm hiểu hiện trạng cơ cấu tổ chức: Tiến hành khảo sát cơ cấu tổ chức các bộ phận, trách nhiệm và quyền hạn. giúp xác định đối tượng sử dụng phần mềm. ❖Tìm hiểu hiện trạng nghiệp vụ: chọn người hoặc bộ phận để thực hiện khảo sát, lập danh sách các công việc mà bộ phận này phụ trách, sau đó tìm hiểu các thông tin chi tiết của từng công việc, bao gồm: Thông tin đầu vào, Quá trình xử lý, Thông tin kết xuất. lưu trữ, tra cứu, tính toán, tổng hợp/thống kê. Jens Martensson 42
42. 2.3.3.2 Lập danh sách các yêu cầu ❑Xác định yêu cầu chức năng nghiệp vụ ❖Cách tiến hành: Chuyên gia đề xuất và chuyên viên tin học sẽ kiểm tra lại ❖Các bước tiến hành: Xác định các công việc mà người dùng sẽ thực hiện trên phần mềm theo từng loại công việc sau: – Lưu trữ, – Tra cứu, – Tính toán, – Kết xuất Jens Martensson 43
43. 2.3.3.2 Lập danh sách các yêu cầu ❑Lập bảng yêu cầu chức năng nghiệp vụ, bảng quy định/công thức và các biểu mẫu. ❑Các biểu mẫu được mô tả chi tiết ngay sau bảng quy định/Công thức Jens Martensson 44
44. 2.3.3.2 Lập danh sách các yêu cầu ❑Ví dụ: Xét phần mềm quản lý thư viện ❑(i) Bảng yêu cần chức năng Jens Martensson 45
45. 2.3.3.2 Lập danh sách các yêu cầu Jens Martensson 46
46. 2.3.3.2 Lập danh sách các yêu cầu ❑Bảng Quy định/ Công thức liên quan Jens Martensson 47
47. 2.3.3.2 Lập danh sách các yêu cầu ❑Bảng Quy định/ Công thức liên quan Jens Martensson 48
48. 2.3.3.2 Lập danh sách các yêu cầu Jens Martensson 49
49. 2.3.3.2 Lập danh sách các yêu cầu Jens Martensson 50
50. 2.3.3.2 Lập danh sách các yêu cầu Jens Martensson 51
51. 2.3.3.2 Lập danh sách các yêu cầu Jens Martensson 52
52. 2.3.3.2 Lập danh sách các yêu cầu ❑Xác định yêu cầu chức năng hệ thống và yêu cầu chất lượng: ❖Cách tiến hành: Chuyên viên tin học và chuyên gia cùng đề xuất và xem xét các yêu cầu. ❖Bước tiến hành – Bước 1: Xem xét các yêu cầu chức năng: phân quyền, sao lưu, phục hồi, định cấu hình hệ thống, – Bước 2: Xem xét các yêu cầu chức năng hệ thống chuyên biệt: yêu cầu về công việc mới, chỉ có thể tiến hành khi thực hiện trên máy tính – Bước 3: Xem xét các yêu cầu về chất lượng theo từng loại tiêu chuẩn sau: Tiến hóa, Tiện dụng, Hiệu quả, Tương thích. Jens Martensson 53
53. 2.3.3.2 Lập danh sách các yêu cầu ❑Sau đó lập bảng yêu cầu tương ứng theo mẫu sau: Jens Martensson 54
54. 2.3.3.2 Lập danh sách các yêu cầu ❑Ví dụ: Xét phần mềm quản lý thư viện (được xây dựng nhằm phục vụ cho 4 bộ phận là: độc giả, thủ thư, ban giám đốc và quản trị hệ thống). (i) Bảng yêu cầu chức năng hệ thống: Jens Martensson 55
55. 2.3.3.2 Lập danh sách các yêu cầu ❑Bảng yêu cầu về chất lượng hệ thống: Jens Martensson 56
56. 2.4. Mô hình hoá yêu cầu hệ thống ❑Mô hình hóa yêu cầu của hệ thống là cách biểu diễn các yêu cầu chức năng của hệ thống đã được xác định trong giai đoạn phân tích bằng các mô hình trực quan giúp cho các bên tham gia có thệ hiểu hệ thống một cách chính xác hơn. Jens Martensson 57
57. 2.4. Mô hình hoá yêu cầu hệ thống ❑Mục tiêu: biểu diễn trực quan và chi tiết hơn về ngữ cảnh vấn đề cần giải quyết và các thông tin cốt lõi trong yêu cầu của hệ thống. ❑Kết quả: các mô hình mô tả toàn bộ hoạt động của hệ thống. ❑Kỹ thuật phân tích: Dựa vào các chức năng đã được xác định và mô tả chi tiết trong bước phân tích, sau đó sử dụng các công cụ mô hình hóa thực hiện các mô hình biểu diễn các chức năng của hệ thống. Jens Martensson 58
58. 2.4.1. Các nguyên lý mô hình hóa ❑Nguyên lý 1: Mô hình hóa phạm vi hệ thống (Domain) ❖Định danh dữ liệu (đối tượng, thực thể), ❖Định nghĩa các thuộc tính, thiết lập các mối quan hệ giữa các dữ liệu ❑Nguyên lý 2: Mô hình hóa Chức năng của hệ thống ❖Đị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 ❖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 Jens Martensson 59
59. 2.4.1. Các nguyên lý mô hình hóa ❑Nguyên lý 3: Mô hình hóa Hành vi Phần mềm (hệ thống) ❖Xác định các trạng thái hệ thống. Ví dụ: giao diện đồ họa ❖Xác định các dữ liệu 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 ❑Nguyên lý 4: Phân hoạch Mô hình ❖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 ❑Nguyên lý 5: Tìm hiểu vấn đề bản chất ❖Chỉ xét bản chất của yêu cầu và không quan tâm đến cách cài đặt. Jens Martensson 60
60. 2.4.2. Sơ đồ phân rã chức năng (FDD) ❑Sơ đồ phân rã chức năng (Function Decomposition Diagram) Biểu diễn các chức năng bằng cách mô tả các tính chất của dữ liệu đầu vào và đầu ra nhằm: ❖Xác định được phạm vi của hệ thống ❖Phân hoạch được hệ thống chức năng ❖Tạo nền tảng cho thiết kế kiến trúc hệ thống Jens Martensson 61
61. 2.4.2. Sơ đồ phân rã chức năng (FDD) Jens Martensson 62
62. 2.4.2. Sơ đồ phân rã chức năng (FDD) Jens Martensson 63
63. 2.4.3. Mô hình bản mẫu (prototype) ❑Mô hình bản mẫu là một phát thảo sơ bộ một số chức năng của hệ thống gồm giao diện, dựa trên các ý tưởng/yêu cầu của khách hàng. ❑Bản mẫu mô tả cách thức phần mềm hoạt động, cách người dùng tương tác với hệ thống và giúp người dùng có thể hình dung được sản phẩm theo yêu cầu. Jens Martensson 64
64. 2.4.3. Mô hình bản mẫu (prototype) ❑Thực hiện bản mẫu ❖Mô hình bản mẫu được tạo bởi kỹ sư phân tích và kỹ sư thiết kế phần mềm ❖Người sử dụng xem bản mẫu và đưa ra ý kiến đóng góp và phản hồi thông tin giúp nhóm phân tích có được yêu cầu chính xác nhất. ❖Nếu người sử dụng đồng ý với bản mẫu thì nhóm phát triển sẽ tiến hành xây dựng phần mềm ❖Ngược lại cả hai phải quay lại giai đoạn xác định yêu cầu. ❖Công việc này được lặp lại liên tục cho đến khi người sử dụng đồng ý với các bản mẫu do nhà phát triển đưa ra. Jens Martensson 65
65. 2.4.4. Sơ đồ luồng dữ liệu (DFD) ❑Sơ đồ luồng dữ liệu (data-flow diagram): Là mô hình biểu diễn luồng dữ liệu và cách thức dữ liệu được xử lý bên trong hệ thống với nhiều mức chi tiết khác nhau. ❑Sơ đồ này có nhiều biến thể mở rộng khác nhau. Jens Martensson 66
66. 2.4.5. Mô hình hướng đối tượng ❑Phương pháp phân tích hướng đối tượng: dựa trên ý tưởng lập trình hướng đối tượng, gồm các khái niệm ❖Ðối tượng (Object): gồm dữ liệu và hành vi tác động lên dữ liệu này. ❖Lớp (Class): tập các đối tượng có cùng cấu trúc dữ liệu và hành vi. ❖Đóng gói (Encapsulation): khả năng hạn chế tác động trực tiếp lên dữ liệu của đối tượng ❖Kế thừa (inheritance): là đặc tính cho phép một lớp kế thừa thuộc tính và hành vi của lớp cha. Jens Martensson 67
67. 2.4.5. Mô hình hướng đối tượng ❑Mô hình hướng đối tượng: mô hình hóa các đối tượng và mối quan hệ giữa các đối tượng ❑Công cụ: sử dụng ngôn ngữ mô hình hóa UML, bao gồm các mô hình biểu diễn các khía cạnh của hệ thống: ❖Biểu diễn hành vi: use case diagram, sequence diagram, activity diagram, ❖Biểu diễn nghiệp vụ: business model ❖Biểu diễn cấu trúc của hệ thống: domain model, class diagram, component diagram. Jens Martensson 68
68. 2.4.5. Mô hình hướng đối tượng ❑Ví dụ: Use Case Diagram Jens Martensson 69
69. 2.4.5. Mô hình hướng đối tượng ❑Ví dụ: class Diagram Jens Martensson 70
70. 2.4.6. Minh họa từ yêu cầu sang mô hình hóa ❑Ví dụ: Phân tích phần mềm quản lý thư viện gồm 4 yêu cầu: ❖Lập thẻ độc giả ❖Nhận sách, ❖Cho mượn sách, ❖Trả sách. Jens Martensson 71
71. 2.4.6. Minh họa từ yêu cầu sang mô hình hóa ❑Mô hình hóa yêu cầu ❖Sơ đồ luồng dữ liệu cho công việc lập thẻ độc giả – D1: Thông tin về thẻ độc giả cần nhập – D4: Thông tin về thẻ độc giả cần lưu trữ trên kho – D5: Thông tin trên thẻ độc giả (trong thế giới thực) Xử lý thẻ độc giả: Kiểm tra tính hợp lệ của thẻ trước ghi nhận và in Jens Martensson 72
72. 2.4.6. Minh họa từ yêu cầu sang mô hình hóa ❑Mô hình hóa yêu cầu ❖Sơ đồ luồng dữ liệu cho công việc nhận sách – D1: Thông tin về thẻ sách cần nhập – D4: Thông tin về sách cần lưu trữ trên kho Xử lý nhập sách: Kiểm tra tính hợp lệ của sách trước khi lưu vào kho Jens Martensson 73
73. 2.4.6. Minh họa từ yêu cầu sang mô hình hóa ❑Mô hình hóa yêu cầu ❖Sơ đồ luồng dữ liệu cho công việc cho mượn sách – D1: Thông tin về độc giả và sách muốn mượn – D3: Thông tin được sử dụng cho việc kiểm tra quy định mượn sách – D4: Thông tin về việc mượn sách Xử lý cho mượn sách: Kiểm tra tính hợp lệ của việc mượn, lưu vào kho Jens Martensson 74
74. 2.4.6. Minh họa từ yêu cầu sang mô hình hóa ❑Mô hình hóa yêu cầu ❖Sơ đồ luồng dữ liệu cho công việc trả sách ❖D1: Thông tin về độc giả và sách trả ❖D3: Thông tin sử dụng cho việc kiểm tra quy định trả sách ❖D4: Thông tin về việc trả sách Xử lý trả sách: Kiểm tra tính hợp lệ của việc trả sách, lưu vào kho. Jens Martensson 75
75. BÀI TẬP ❑1. Phụ lục A trang 170 ❑2. Phụ lục B trang 179 Jens Martensson 76