Giáo trình Phân tích yêu cầu phần mềm

pdf

242 trang huongle 5750

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Phân tích yêu cầu phần mềm", để 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:

giao_trinh_phan_tich_yeu_cau_phan_mem.pdf

Nội dung text: Giáo trình Phân tích yêu cầu phần mềm

 Phân tích yêu cầu phần mềm
Phân tích yêu cầu phần mềm Lecture 01 – Công nghệ yêu cầu Chất lượng = Đáp ứng mục tiêu Công nghệ phần mềm có mặt khắp mọi nơi Tác động rất gần đến tất cả các khía cạnh trong cuộc sống Nhưng các kinh nghiệm của chúng ta trong kỹ thuật phần mềm thì thường gặp hạn chế Phần mềm được thiết kế nhằm một mục đích nào đó Nếu nó không thực hiện tốt thì hoặc là : người thiết kế không có sự thấu hiểu một cách đầy đủ mục đích hoặc chúng ta đang sử dụng phần mềm cho mục đích khác với dự định ban đầu Phân tích yêu cầu nhằm xác định chính xác mục đích này Việc hiểu không đầy đủ về mục đích dẫn đến chất lượng phần mềm kém Mục đích được tìm thấy từ các hoạt động của con người E.g. Mục đích của hệ thống ngân hàng đến từ các hoạt động kinh doanh của ngân hàng và nhu cầu từ những khách hàng của họ (e.g. ATM, ) Mục đích thường phức tạp 1
Phân tích yêu cầu phần mềm Thách thức nằm ở đâu ? 2
Phân tích yêu cầu phần mềm Hệ thống nào thì “mềm”? Các thành phần phần mềm cùng loại E.g. Các chức năng lõi trong hệ điều hành, dịch vụ mạng, tầng trung gian (middleware), Có quan hệ về mặt chức năng ổn định, xác định bởi các giao diện kỹ thuật Nhưng chú ý rằng những hệ thống này vẫn chịu tác động bởi hoạt động của con người E.g. khái niệm của một ‘file’, một ‘URL’, etc. Các hệ thống quản lý (Control Systems) E.g. điều hành quy trình bay, điều hành tiến trình công nghiệp, Hầu hết yêu cầu được xác định bởi các quy trình tự nhiên để điều hành Nhưng chú ý rằng các cách thức giao tiếp thì thường mang tính quyết định E.g. các tai nạn phát sinh khi hệ thống không ứng xử theo cách thức mong đợi (Tàu vũ trụ Arian 5 - France) Các hệ thống thông tin (Information Systems) E.g. tự động hóa văn phòng, phần mềm nhóm (groupware), web services, phần mềm hỗ trợ kinh doanh, Các hệ thống này không thể tách riêng khỏi các hoạt động mà chúng hỗ trợ Thiết kế của phần mềm kế thừa trên thiết kế của hoạt động con người Phần mềm và hoạt động con người đồng thiết lập 3
Phân tích yêu cầu phần mềm Định nghĩa RE (Requirements Engineering) Không phải một thời Requirements Engineering (RE) là một kỳ hay một giai đoạn ! tập các hoạt động liên quan tới Người thiết kế cần biết hệ thống sẽ việc xác định và truyền đạt được sử dụng ở đâu Truyền đạt rất quan mục tiêu của một hệ thống phần mềm và như thế nào? trọng khi phân tích chuyên nghiệp, trong lĩnh vực mà Chất lượng nghĩa là chúng được sử dụng. Ở đây, các hoạt Yêu cầu là một phần của nhu đáp ứng mục tiêu. động RE như là cầu nối giữa cầu là gì ??? Không thể nói điều gì về chất lượng trừ khi các nhu cầu trong thực tế của bạn hiểu rõ mục tiêu người dùng, khách hàng, và những ứng viên khác có ảnh hưởng đến một hệ thống phần mềm, và những khả Và một phần của nó thực hiện năng và cơ hội được tạo ra bởi những Cần nhận dạng tất cả được gì ??? các đối tác – không kỹ thuật phần mềm chuyên nghiệp chỉ là người dùng và khach hàng ! 4
Phân tích yêu cầu phần mềm Hậu quả của sai sót Giá để sửa chữa lỗi Một tiến trình phát triển phần mềm điển hình bao gồm: Phân tích yêu cầu Thiết kế phần mềm Lập trình Kiểm thử sự phát triển Kiểm thử sự chấp thuận Vận hành Giá sửa lỗi ngày càng tăng vào thời điểm phát hiện chúng trong tiến trình E.g. Một lỗi về phân tích yêu cầu được tìm thấy phải trả giá 100 lần cao hơn lỗi chương trình. Nguyên nhân dự án thất bại Thống kê các dự án phần mềm US của nhóm Standish: 5
Phân tích yêu cầu phần mềm Hậu quả của sai sót Nguyên nhân dự án thất bại Standish Group (US Software) khảo sát 350 công ty với hơn 8000 dự án phần mềm. 1. Yêu cầu không hoàn chỉnh (13.1%) 2. Thiếu sự hợp tác người dùng (12.4%) 3. Thiếu tài nguyên (10.6%) 4. Mong muốn phi thực tế (9.9%) 5. Thiếu hỗ trợ pháp lý (9.3%) 6. Thay đổi yêu cầu và đặc tả (8.7%) 7. Thiếu hoạch định (8.1%) 8. Hệ thống không cần đến nữa (7.5%) 6
Phân tích yêu cầu phần mềm Hậu quả của sai sót Kiến nghị Lỗi yêu cầu (requirements errors) có thể phải trả giá đắt nếu chúng không được phát hiện và sửa chữa sớm trong tiến trình phát triển. Báo cáo của Boehm và Papaccio (1988) cho thấy ước lượng giá trị tiêu tốn cho việc phát hiện lỗi ở các giai đoạn của một tiến trình phát triển phần mềm như sau : Phân tích yêu cầu (1$) ⇒ Thiết kế (5$) ⇒ Lập trình (10$) ⇒ Kiểm thử (20$) ⇒ Triển khai hệ thống (>200$) Cần dành thời gian để tìm hiểu kỹ vấn đề trong lĩnh vực của chúng và thu thập yêu cầu thật chính xác trong giai đoạn đầu tiên. 7
Phân tích yêu cầu phần mềm Mục tiêu của Phân tích yêu cầu ? Điểm bắt đầu Tập trung chú ý rằng có một “vấn đề” cần được giải quyết e.g. không bằng lòng với trạng thái hiện tại của công việc e.g. một cơ hội kinh doanh mới e.g. một cơ hội để tiết kiệm chi phí, thời gian, tài nguyên sử dụng, etc. Nhà phân tích yêu cầu là một tác nhân của sự thay đổi 8
Phân tích yêu cầu phần mềm Phân tích yêu cầu cần đạt được gì? Định nghĩa được “vấn đề” : (Which) Vấn đề nào cần được giải quyết ? (Xác định ranh giới vấn đề - Boundaries) (Where) Vấn đề ở đâu ? (Hiểu ngữ cảnh/ phạm vi vấn đề - Context/Problem Domain) (Whose) Vấn đề của ai? (Định nghĩa Đối tác - Stakeholders) (Why) Tại sao cần giải quyết? (Định nghĩa Mục tiêu đối tác – ‘stakeholders’ Goals) (How) Hệ thống phần mềm sẽ hỗ trợ như thế nào? (Thu thập Kịch bản - Scenarios) (When) Khi nào cần phải giải quyết ? (Định nghĩa các ràng buộc phát triển - Development Constraints) (What) Điều gì ngăn chặn việc giải quyết chúng? (Định nghĩa tính khả thi và độ rủi ro - Feasibility and Risk) Là chuyên gia trong phạm vi của vấn đề. 9
Phân tích yêu cầu phần mềm Một số khảo sát về RE RE không cần thiết phải theo một tiến trình tuần tự: Không cần phải viết mô tả vấn đề trước mô tả giải pháp Viết lại một mô tả vấn đề có thể giúp ích ở các giai đoạn phát triển Các hoạt động RE tiếp tục xuyên suốt tiến trình phát triển Khai báo vấn đề sẽ không hoàn hảo Các mô hình RE thì chỉ gần đúng với thực tế Sẽ chứa sự thiếu chính xác và không nhất quán Sẽ bỏ sót một số thông tin. Các nhà phân tích luôn làm giảm bớt những rủi ro sẽ có trong vấn đề thực Việc hoàn chỉnh một sự đặc tả có thể không mang lại lợi nhuận Phân tích yêu cầu có giá của nó Đối với những dự án khác nhau, cân bằng lợi nhuận cũng khác nhau Khai báo vấn đề không khi nào được xem là cố định Thay đổi thì chắc chắn sẽ xảy ra, và vì thế phải dự kiến (E.g ) trước Đó sẽ là một cách để kết hợp chặt chẽ các thay đổi một cách định kỳ 10
Phân tích yêu cầu phần mềm Một vấn đề được mô tả E.g. “Ngăn chặn việc truy cập trái phép từ các máy tính” 11
Phân tích yêu cầu phần mềm Yêu cầu là gì ? Đặc tính lĩnh vực (Domain Properties D) Những thứ có thật trong lĩnh vực ứng dụng cho dù chúng ta có thiết kế hệ thống dự định hay không Các yêu cầu (Requirement R) Những thứ trong lĩnh vực ứng dụng mà chúng ta mong muốn trở thành hiện thực bằng cách thực hiện hệ thống dự định Rất nhiều trong chúng bao gồm các hiện tượng mà máy tính không thể truy cập được. Sự đặc tả (Specification S) Là sự mô tả các hành vi mà chương trình phải làm để đáp ứng các yêu cầu Có thể chỉ được viết trong thuật ngữ của sự chia sẻ các hiện tượng! 12
Phân tích yêu cầu phần mềm Đáp ứng với mục tiêu ? Hai tiêu chuẩn kiểm tra tính chính xác (verification) Chương trình (Program) thực hiện trên một máy tính (Computer) cụ thể đáp ứng với đặc tả (Specification) Đặc tả (Specification) được cho trong thuộc tính của lĩnh vực (Domain properties) thỏa mãn các yêu cầu (Requirements) Hai tiêu chuẩn kiểm chứng sự hoàn thiện (validation) Chúng ta đã xem xét (và hiểu) tất cả các yêu cầu (Requirements) quan trọng? Chúng ta đã xem xét (và hiểu) tất cả các thuộc tính lĩnh vực(Domain properties) liên quan? 13
Phân tích yêu cầu phần mềm Ví dụ Requirement R: “Phản lực chỉ có thể xảy ra khi máy bay đang chạy trên đường băng” Domain Properties D: Xung lực bánh xe xảy ra khi và chỉ khi các bánh xe bật ra Các bánh xe bật ra khi và chỉ khi nó chạy trên đường băng Specification S: Phản lực có thể xảy ra khi và chỉ khi có xung lực bánh xe Kiểm tra Phần mềm cho máy bay, P, thực thi trên máy tính trong buồng lái của máy bay, C, có hoàn toàn chính xác như đặc tả, S? S, trong ngữ cảnh của giả thuyết D, có đáp ứng R? Kiểm chứng Giả thuyết của chúng ta, D, về lĩnh vực có thật chính xác? Có thiếu gì không? Yêu cầu, R, có thật sự cần thiết? Có thiếu gì không? 14
Phân tích yêu cầu phần mềm Một ví dụ khác Requirement R: “Cơ sở dữ liệu chỉ có thể được truy cập bởi những người có quyền” Domain Properties D: Những người có quyền thì có passwords Passwords không bao giờ được chia sẻ với những người không có quyền Specification S: Truy cập vào CSDL chỉ được chấp nhận sau khi người dùng gõ vào một password được cấp S + D dẫn đến R Nhưng có liệu rằng giả thuyết về lĩnh vực là sai? 15
Phân tích yêu cầu phần mềm Mô hPhần mềm thì khác biệt gì ? Phần mềm thì khác! Phần mềm thì vô hình, mơ hồ, trừu tượng mục đích của nó là cấu hình một số phần cứng để làm những thứ hữu ích Không có quy luật tự nhiên nào bên trong các hành vi phần mềm Không có các ràng buộc tự nhiên nào trong các phần mềm phức tạp Phần mềm không khi nào mệt mỏi các độ đo truyền thống đáng tin không được áp dụng Phần mềm hoàn toàn có thể thực hiện một công việc lặp đi lặp lại không tạo ra sự thay đổi 16 16
Phân tích yêu cầu phần mềm Quản lý dự án Một nhà quản lý dự án có thể kiểm soát 4 thứ: Tài nguyên (có thể tăng thêm tiền, tiện ích, nhân lực) Thời gian (có thể tăng thời gian, trì hoãn thời hạn, etc.) Sản phẩm (có thể giảm chức năng - e.g. các yêu cầu quá rắc rối) Rủi ro (có thể quyết định các rủi ro nào chấp nhận được) Để thực hiện điều này, nhà quản lý cần theo dõi: Công sức – Cần tốn công sức nhiều thế nào? Tiêu hao bao nhiêu? Thời gian – Lịch biểu được mong đợi ra sao? Còn bao lâu nữa ? Kích cỡ – Kế hoạch vấn đề lớn như thế nào? Phải thiết kế ra sao? Hạn chế – Đã tạo ra bao nhiêu lỗi ? Bao nhiêu lần phát hiện lỗi? Và các lỗi này ảnh hưởng như thế nào đến chất lượng? Khởi đầu, một nhà quản lý cần có sự đánh giá đúng và điều đó chỉ có thể có từ sự phân tích thấu đáo vấn đề. Bạn không thể kiểm soát được cái mà bạn không thể đo lường ! 17
Phân tích yêu cầu phần mềm Các kiểu dự án Các lý do khởi đầu cho một dự án phát triển phần mềm Hướng vấn đề (Problem-driven): sự cạnh tranh, sự khủng hoảng, Hướng thay đổi (Change-driven): nhu cầu mới, sự lớn mạnh, thay đổi doanh nghiệp hoặc môi trường, Hướng cơ hội (Opportunity-driven): bùng nổ một kỹ thuật mới, Hướng kế thừa (Legacy-driven): một phần của kế hoạch trước đó, công việc chưa hoàn thành, Green field Các kiểu quan hệ với khách hàng: Customer-specific – một khách hàng với vấn đề cụ thể Có thể là một công ty khác, với hợp đồng thỏa thuận Có thể là một bộ phận trong cùng công ty Market-based – hệ thống bán ra thị trường Trong một số trường hợp, sản phẩm phải sinh ra khách hàng Đội ngũ tiếp thị phải hành động như những người thay thế khách hàng Community-based – dự định sẽ như một tiện ích chung cho cộng đồng E.g. công cụ nguồn mở (open_ source), các công cụ cho nghiên cứu khoa học Khách hàng tài trợ (nếu nhà tài trợ không chiếm giữ kết quả) Hybrid (kết hợp những kiểu trên) 18
Phân tích yêu cầu phần mềm Chu kỳ sống của một dự án phần mềm Các mô hình chu kỳ sống Rất hữu ích để so sánh các dự án trong ngữ cảnh chung Không đủ chi tiết cho việc hoạch định dự án Các ví dụ: Các mô hình tuần tự: Waterfall, V model Lập bản mẫu nhanh (Rapid Prototyping) Các mô hình giai đoạn: Incremental, Evolutionary Các mô hình vòng lặp: Spiral Các mô hình linh hoạt (Agile Models): eXtreme Programming Sự so sánh: Process Models Dùng cho việc nắm vững và cải tiến tiến trình phát triển phần mềm 19
Phân tích yêu cầu phần mềm Mô hình thác nước (Waterfall Model) Quan điểm phát triển: Là một tiến trình của sự tinh chế theo bậc thang Quan điểm quản trị cấp cao ở cấp độ lớn Các vấn đề: Cách nhìn tĩnh với các yêu cầu – lờ đi khả năng biến đổi Thiếu sự liên quan của người dùng khi đặc tả được viết Có tách biệt không thực tế của đặc tả từ thiết kế Không hỗ trợ cho việc lập bản mẫu, tái sử dụng, etc 20
Phân tích yêu cầu phần mềm Mô hình V (V - Model) 21
Phân tích yêu cầu phần mềm Lập bản mẫu nhanh Lập bản mẫu thì được dùng cho: Hiểu các yêu cầu của giao diện người dùng Xem xét các đặc tính của hướng dự định thiết kế Khảo sát các quy tắc thực thi của hệ thống Các vấn đề: Những người dùng xem bản mẫu như giải pháp Một bản mẫu chỉ là một đặc tả không hoàn chỉnh 22
Phân tích yêu cầu phần mềm Các mô hình giai đoạn chu kỳ sống 23
Phân tích yêu cầu phần mềm Mô hình xoắn ốc (The Spiral Model) 24
Phân tích yêu cầu phần mềm Các mô hình linh hoạt (Agile Models) Lập luận cơ sở E.g. Lập trình cực độ Giảm rào cản về truyền thông Người lập trình giao tiếp với khách hàng ( XP - Extreme Programming) Giảm tiếp cận nặng nề với tài liệu Thay vì viết đặc tả yêu cầu, Việc lập tài liệu thì tốn kém và giới hạn sử dụng thì sử dụng: Có niềm tin giữa con người User story cards (Bản chức năng Không cần thiết phải có các mô hình xử lý thật người dùng) thu hút để thuyết phục cái sẽ làm! Khách hàng trực diện Đáp ứng được cho khách hàng Lập trình cặp đôi (Pair Hơn là tập trung vào việc ký hợp đồng Programming) Phát hành nhặt Điểm yếu E.g. mỗi 3 tuần Trò chơi kế hoạch (Planning Game) Tin tưởng vào trí nhớ của người lập trình Chọn lựa và đánh giá các user story Mã lệnh có thể khó bảo trì cards vào lúc bắt đầu mỗi đợt phát hành Tin tưởng vào truyền thông bằng miệng Viết bản kiểm thử trước viết code Có thể thiếu rõ ràng Mã lệnh chương trình được thiết kế Chấp nhận duy nhất khách hàng đại diện lập tức Các quan điểm khác nhau thì không thể đưa ra Tương tác liên tục Kế hoạch chỉ lập trong thời gian ngắn Tích hợp và kiểm thử mã lệnh vài Không có tầm nhìn xa lần trong một ngày 25
Phân tích yêu cầu phần mềm Lập trình cực độ XP (eXtreme Programing) 26
Phân tích yêu cầu phần mềm Kết luận Học phần này bao gồm hầu hết các công nghệ về yêu cầu: Phân tích hiện trạng vấn đề Khảo sát hoạt động con người Hình thức hóa các yêu cầu để giải pháp phần mềm có thể được thiết kế Học phần này thì khác với hầu hết các học phần CS khác Nó không phải về cách giải quyết vấn đề dùng máy tính như thế nào Nó là việc xác định các vấn đề cần giải quyết như thế nào Nội dung học phần là các hoạt động của con người: Làm sao để thấu hiểu chúng Làm sao để dùng các kỹ thuật phần mềm hỗ trợ chúng 27
Phân tích yêu cầu phần mềm Lecture 2: Quy trình công nghệ yêu cầu (RE - The requirements engineering) Khái niệm Quy trình dùng để khảo sát, phân tích và kiểm chứng tính hợp lệ của các yêu cầu hệ thống Quy trình là một tập các hoạt động nhằm dẫn đến việc phát sinh định nghĩa và đặc tả yêu cầu. 1
Phân tích yêu cầu phần mềm Các đặc tính chung Quy trình RE có nhiều dạng khác nhau, phụ thuộc vào lĩnh vực ứng dụng, các nhân tố liên quan và tổ chức phát triển yêu cầu. Tuy nhiên, có một số đặc tính chung cho các quy trình là : Thu thập yêu cầu (Requirements elicitation) Phân tích yêu cầu (Requirements analysis) Kiểm chứng yêu cầu (Requirements validation) Quản trị yêu cầu (Requirements management) 2
Phân tích yêu cầu phần mềm Các nội dung chính Nghiên cứu khả thi (Feasibility studies) Thu thập yêu cầu và phân tích (Requirements elicitation and analysis) Requirements Kiểm chứng yêu cầu hợp lệ ( validation) Quản trị yêu cầu (Requirements management) . 3
Phân tích yêu cầu phần mềm Các bước trong quy trình 4
Phân tích yêu cầu phần mềm Nghiên cứu khả thi Thực hiện ước lượng nhằm đánh giá sự đáp ứng cho yêu cầu: Kỹ thuật phần cứng Kỹ thuật phần mềm Nghiên cứu khả thi quyết định hệ thống Có giá trị hiệu quả về kinh doanh Có thể phát triển với những ràng buộc ngân sách hiện có Phải rẻ và nhanh chóng Kết quả : Báo cáo khả thi (Feasibility Report) Quyết định điều gì là quan trọng với các lý giải chi tiết Bản báo cáo về tính khả thi của hệ thống Tài liệu đặc tả yêu cầu người dùng 5
Phân tích yêu cầu phần mềm Phân tích làm rõ yêu cầu Quá trình đưa ra các yêu cầu hệ thống Khảo sát hệ thống hiện tại Thảo luận với người dùng và các nhà trung gian tiềm năng Phân tích công việc Có thể phát triển 1 hoặc nhiều mô hình hệ thống khác nhau Giúp nhà phân tích hiểu rõ hệ thống để đặc tả B ả n m ẫ u có thể lập để hiểu rõ các yêu cầu N g h i 6
Phân tích yêu cầu phần mềm Tiến trình phân tích làm rõ yêu cầu Định nghĩa yêu cầu và Kiểm chứng Đặc tả yêu cầu Hiểu phạm Sắp ưu tiên vi vấn đề Đầu vào tiến trình Thu thập Giải quyết Yêu cầu Mâu thuẫn Phân loại 7
Phân tích yêu cầu phần mềm Các hoạt động trong tiến trình Hiểu phạm vi vấn đề (Domain understanding) Thu thập yêu cầu (Requirements collection) Phân loại (Classification) Giải quyết mâu thuẫn (Conflict resolution) Sắp ưu tiên (Prioritisation) Kiểm tra yêu cầu (Requirements checking) 8
Phân tích yêu cầu phần mềm Xác định yêu cầu Là hoạt động chuyển thông tin phát sinh trong suốt tiến trình phân tích thành tài liệu định nghĩa tập hợp các yêu cầu Phản ánh chính xác điều mà người dùng muốn Tài liệu phải được viết để hệ thống sẽ được hiểu bởi Người dùng cuối Những khách hàng của hệ thống. 9
Phân tích yêu cầu phần mềm Đặc tả yêu cầu Bản mô tả các yêu cầu hệ thống được thiết lập như cơ sở của hợp đồng giữa khách hàng và nhà phát triển phần mềm Mô tả thật chi tiết về yêu cầu người dùng và yêu cầu hệ thống hữu ích cho thiết kế Mô tả chính xác để nắm bắt đúng vấn đề Việc lập tài liệu này được thực hiện song song cùng với một số các thiết kế cấp cao khác. Lỗi trong định nghĩa yêu cầu cần được xem xét kỹ lưỡng. Nó phải được sửa chữa theo đúng vấn đề này. 10
Phân tích yêu cầu phần mềm Quản lý yêu cầu Quản lý yêu cầu là tiến trình quản lý sự thay đổi của yêu cầu trong suốt quy trình công nghệ yêu cầu và phát triển hệ thống Yêu cầu thì chắc hẳn là sẽ không hoàn thiện và không nhất quán Các yêu cầu mới thì liên tục phát sinh trong suốt tiến trình khi nhu cầu công việc thay đổi và có sự hiểu rõ hơn về hệ thống đang phát triển Các quan điểm khác nhau có các yêu cầu khác nhau và điều này thường làm phát sinh mâu thuẫn 11
Phân tích yêu cầu phần mềm Kết luận Các hoạt động trong quy trình công nghệ yêu cầu thì không đơn giản để thực hiện một cách tuần tự mà chúng phải lặp đi lặp lại. Phân tích yêu cầu vẫn tiếp tục trong suốt quá trình định nghĩa và đặc tả Các yêu cầu mới vẫn còn tiếp tục phát sinh trong suốt tiến trình Tài liệu yêu cầu phải thay đổi thường xuyên và được đặt dưới sự kiểm soát của một hệ thống quản lý cấu hình . 12
Phân tích yêu cầu phần mềm Lecture 3: Nghiên cứu khả thi (Feasibility Study) Nghiên cứu khả thi là gì? Nghiên cứu điều gì và kết quả ra sao ? Các dạng đặc tính khả thi cần khảo sát Kỹ thuật Kinh tế Lịch biểu Vận hành Mức độ lợi nhuận và chi phí Phân tích lợi tức Phân tích giá trị thực có Phân tích lợi nhuận trên vốn đầu tư So sánh các sự lựa chọn 1
Phân tích yêu cầu phần mềm Tại sao cần nghiên cứu khả thi Mục tiêu: Chỉ rõ việc phát triển dự án : Đề nghị các giải pháp có thể thay đổi. Cung cấp cho nhà quản trị đủ thông tin để biết: Dự án có thể thực hiện được Sản phẩm sau cùng mang đến lợi ích cho người dùng Cần thay đổi những gì Có thể thay đổi hoàn thiện không Hành động của nhà quản trị: Sau khi nghiên cứu khả tính, nhà quản trị cần có ngay quyết định “tiếp tục hay không ?” Cần xem xét vấn đề trong môi trường chiến lược kinh doanh. 2
Phân tích yêu cầu phần mềm Nội dung nghiên cứu khả thi Những vấn đề cần nghiên cứu trong nghiên cứu khả thi Tổ chức của hệ thống hiện hành Các vấn đề với hệ thống hiện hành Các mục tiêu và những yêu cầu khác đối với hệ thống mới Các ràng buộc Những lựa chọn có thể “Gắn với hệ thống hiện hành” luôn luôn là một chọn lựa Các quy trình công việc khác nhau cho việc giải quyết vấn đề Các cấp độ/kiểu tin học hóa khác nhau cho giải pháp Các thuận lợi và bất lợi của mỗi lựa chọn Những vấn đề để kết luận: Tính khả thi của dự án Các lựa chọn tốt hơn 3
Phân tích yêu cầu phần mềm Thực hiện nghiên cứu khả thi Dựa trên các thông tin đã có sẵn (yêu cầu gì), các thông tin thu thập được và viết bản báo cáo. Một số câu hỏi liên quan Liệu hệ thống sẽ không cài đặt được gì ? Quy trình hiện tại cho vấn đề? Hệ thống đưa ra những hỗ trợ như thế nào ? Vấn đề gì sẽ được tích hợp? Kỹ thuật mới nào là cần thiết ? Cần những kỹ năng gì? Các hoạt động nào cần được hỗ trợ bởi hệ thống dự định ? 4
Phân tích yêu cầu phần mềm Khảo sát hiện trạng Khung “PIECES” (The PIECES” framework) Hữu ích cho việc định nghĩa hoạt động của vấn đề cần giải quyết và sự cấp bách của chúng. Performance (Độ thực thi) Information (Sự truyền thông) Economy (Tính kinh tế) Control (Sự kiểm soát) Efficiency (Tính hiệu quả) Services (Các dịch vụ) 5
Phân tích yêu cầu phần mềm Mô h 6
Phân tích yêu cầu phần mềm 4 dạng khảo sát tính khả thi Khả thi về kỹ thuật Khả thi về lịch biểu Dự án có thể thực hiện với các kỹ Liệu có thể thiết kế được một giải thuật hiện tại không ? pháp theo đúng kế hoạch thời gian ? Kỹ thuật nào sẽ có rủi ro ? Với các kỹ thuật hiện có : Khả thi về kinh tế Khả thi về vận hành Dự án có thể thực hiện với các Khi hệ thống đã phát triển, nó sẽ ràng buộc về tài nguyên hiện có ? được sử dụng như thế nào ? Có những ích lợi gì ? Các nguyên tắc về con người và xã hội Chi phí phát triển và vận hành? Có lợi ích đáng kể về chi phí ? 7
Phân tích yêu cầu phần mềm (1) Khả thi về kỹ thuật Kỹ thuật được đề xuất hoặc giải pháp trên thực tế là gì? Hiện tại chúng ta có làm chủ được những kỹ thuật cần thiết? Chúng ta có làm chủ được các nhà chuyên môn về kỹ thuật cần thiết? Kỹ thuật liên quan có đủ hoàn chỉnh để dễ dàng áp dụng vào vấn đề của chúng ta không? Loại kỹ thuật mà chúng ta cần là gì? Một số các tổ chức thích dùng các công nghệ tiên tiến (state-of-the-art) nhưng tốt nhất là dùng kỹ thuật đã hoàn thiện và đã qua trãi nghiệm Một kỹ thuật hoàn thiện sẽ có một số lượng lớn khách hàng làm cơ sở cho việc thu thập các lời khuyên liên quan đến vấn đề và cải thiện chúng. Kỹ thuật cần đến thì có sẵn (in house) hay không? Nếu kỹ thuật có sẵn: nó có khả năng để thao tác được giải pháp? Nếu kỹ thuật không có sẵn: có thể tìm được nó hay không? 8
Phân tích yêu cầu phần mềm (2) Khả thi về kinh tế Mức độ quan trọng có thể được số lượng hóa hay không? Rất sớm khi bắt đầu dự án Cân nhắc liệu vấn đề cần giải quyết có đáng giá không Khi đặc tả yêu cầu và giải pháp đã được xác định Chi phí và lợi nhuận của mỗi sự thay đổi đều được tính toán Phân tích chi phí-lợi nhuận (costs-benefits) Mục tiêu – trả lời các câu hỏi như : Dự án có đáng giá để thực hiện (i.e. lợi nhuận rất cao hơn chi phí)? Chi phí tối thiểu để chắc chắn có thể thực hiện được hệ thống ? Sẽ thu được lợi nhuận trong bao lâu? Sự thay đổi nào sẽ cho ra cách đầu tư tốt nhất? Ví dụ về những thứ cần xem xét: Chọn lựa phần cứng/phần mềm Chọn lựa trong số những cách thỏa thuận về tài chính cho sự thay đổi (cho thuê/đi thuê/mua) Khó khăn Lợi nhuận và chi phí có thể cùng mơ hồ, bị che dấu và/hoặc khó đánh giá Có quá nhiều tiêu chuẩn trong phạm vi thay đổi 9
Phân tích yêu cầu phần mềm Lợi nhuận (Benefits) Chi phí (Costs) Lợi nhuận hữu hình Chi phí phát triển (OTO) Số lượng hóa một cách nhanh chóng Chi phí phát triển và buôn bán: thành giá trị tiền tệ ($) Chi phí cho đội ngũ phát triển Phí tư vấn Các ví dụ: tăng doanh thu Phần mềm đã sử dụng (mua hay thiết kế)? giảm chi phí/lỗi Phần cứng (mua những gì, mua/thuê)? Các tiện ích (địa điểm, phương tiện truyền tăng số liệu nhập/hiệu quả tăng lợi nhuận trên doanh thu thông, nguồn năng lượng, ) sử dụng thời gian làm việc của nhân Chi phí khởi tạo và chuyển đổi: viên hiệu quả hơn Khởi tạo hệ thống, Lợi nhuận vô hình Huấn luyện nhân lực, Chuyển đổi hồ sơ Rất khó số lượng hóa Chi phí vận hành (on-going) Nhưng có thể quan trọng hơn! Nhà phân tích kinh doanh giúp ước Bảo trì hệ thống: lượng giá trị bằng tiền ($) Phần cứng (sửa chữa, thuê, được cấp, ), Các ví dụ: Phần mềm (bản quyền và các hợp đồng), tăng tính linh hoạt của các hoạt động Các tiện ích chất lượng sản phẩm cao hơn/dịch vụ Nhân sự: quan hệ khách hàng tốt Cho vận hành (nhập liệu, sao lưu, ) cải thiện tinh thần nhân viên Cho hỗ trợ (hỗ trợ người dùng, bảo trì Lợi nhuận tích lũy như thế nào? phần cứng và phần mềm, cung cấp, ) Khi nào – cần cân đối thời gian? Chi phí huấn luyện on-going Tổ chức ở đâu? 10
Phân tích yêu cầu phần mềm Ví dụ : Chi phí cho một dự án Client-Server nhỏ Personnel : 2 System Analysis (400 hours/ on $35.00/hr) $28.000 4 Programmer Analysis (250 hours/ on $25.00/hr) $25.000 1 GUI Designer (200 hours/ on $35.00/hr) $7.000 1 Telecommunication Specialist (400 hours/ on $35.00/hr) $2.250 1 System Architect (10 hours/ on $45.00/hr) $4.500 1 Database Specialist (15 hours/ on $40.00/hr) $600 1 System Librarian (250 hours/ on $10.00/hr) $2.500 Expenses : 4 Smalltalk training registration ($3.500.00/ student) $14.000 New Hardware & Software : 1 Development Server (Pentium Pro class) $18.700 1 Server Software (operating system, misc, ) $1.300 1 DBMS Server sofware $7.300 7 DBMS Client software $6.650 Total Development Costs : $118.200 PROJECTED ANNUAL OPERATING COSTS: Personnel : 2 Programmer Analysis (125 hours/ on $25.00/hr) $6.250 1 System Librarian (20 hours/ on $10.00/hr) $200 Expenses : 1 Maintenance Agreement for Pentium Pro Server $995 1 Maintenance Agreement for Server DBMS software $525 Preprinted forms (15.000/ year @/22/form) $3.300 Total Projected Annual Costs : $11 270 11
Phân tích yêu cầu phần mềm Phân tích Chi phí vs. Lợi nhuận Nhận biết chi phí và lợi nhuận Hữu hình và vô hình, một lần và định kỳ Phân chia giá trị chi phí và lợi nhuận Xác định luồng tiền mặt (Cash flow) Dự kiến chi phí và lợi nhuận lâu dài, e.g. 3-5 năm Tính toán Giá trị hiện tại thuần (Net Present Value) (Hiện giá thuần) cho toàn bộ chi phí/lợi nhuận trong tương lai Thực hiện phân tích chi phí/lợi nhuận Tính toán Lợi nhuận trên vốn đầu tư (ROI-Return on Investment): Cho phép so sánh lợi nhuận suốt chu kỳ sống của một giải pháp lựa chọn. ROI = Tổng lợi nhuận = Lợi nhuận chu kỳ sống – Chi phí chu kỳ sống Tổng chi phí Chi phí chu kỳ sống Tính toán Điểm hòa vốn (Break-Even point): Bao lâu (tính bằng số năm) nó sẽ hoàn lại được chi phí tích lũy: @T (Lợi nhuận tích lũy > Chi phí tích lũy) 12
Phân tích yêu cầu phần mềm Tính toán Giá trị hiện tại (Present Value) Một đồng hôm nay đáng giá hơn một đồng ngày mai Sự phân tích của bạn sẽ bình thường hóa giá trị đồng ở “năm hiện tại”. Tỷ lệ chiết khấu (discount rate) Đo lường chi phí cơ hội (opportunity cost): Tiền đầu tư vào dự án này có nghĩa tiền không sẵn dùng cho những thứ khác Lợi nhuận được mong đợi trong những năm sắp tới thì thiên về rủi ro hơn Con số này là của cả công ty- và là đặc trưng của việc kinh doanh. “Mức trung bình trả về hàng năm cho sự đầu tư vào việc kinh doanh này?” Giá trị hiện tại (Present value): Giá trị đồng ở “năm hiện tại” cho chi phí/lợi nhuận năm n trong tương lai đối với một tỷ lệ chiết khấu i 1 Present_Value(n) = (1 + i)n E.g. nếu tỷ lệ chiết khấu là 12%, thì 1 Present_Value(1) = 1/(1 + 0.12) = 0.893 Present_Value(2) = 1/(1 + 0.12)2 = 0.797 13
Phân tích yêu cầu phần mềm Giá trị hiện tại thuần (Net Present value) Đo lường tổng giá trị đầu tư với tất cả các con số được điều chỉnh bằng giá trị đồng ($) hiện tại NPV = PV cộng dồn của tất cả lợi nhuận - PV cộng dồn của tất cả chi phí Giả sử những năm tiếp theo năm thứ 4 Giá trị hiện tại thuần của việc đầu tư này trong dự án sẽ là : sau 5 năm, $13,652 sau 6 năm, $36,168 14
Phân tích yêu cầu phần mềm Phân tích thời hạn thu lợi nhuận (payback) cho dự án thay đổi một hệ thống client-server. 15
Phân tích yêu cầu phần mềm Tính toán thời hạn hoàn vốn (Payback) Có thể tính được điểm hòa vốn (break-even point): Khi nào lợi nhuận của chu kỳ sống vượt trên chi phí chu kỳ sống? Xác định tỷ lệ của một năm sau khi việc thu lợi nhuận thực sự xuất hiện: | beginningYear amount | endYear amount + | beginningYear amount | Trong ví dụ trên : 51,611 / (70,501 + 51,611) = 0.42 Vì thế, thời hạn hoàn vốn (payback) thì xấp xỉ là 3.4 năm (3 + 0.42 = 3.42 năm) 16
Phân tích yêu cầu phần mềm Phân tích lợi nhuận trên vốn đầu tư (ROI) So sánh trên lợi ích tổng thể Thay đổi nào là sự đầu tư tốt? Đo lường ROI là tỷ lệ giá trị của một sự đầu tư trên chi phí của nó. ROI thì được tính như sau: ROI = Lợi nhuận chu kỳ sống – Chi phí chu kỳ sống Chi phí chu kỳ sống Hoặc: ROI = Giá trị hiện tại thuần / Chi phí chu kỳ sống Trong ví dụ trên ROI = (795,440 - 488,692) / 488,692 ≈ 63%, hoặc ROI = 306,748 / 488,692 ≈ 63% Giải pháp với ROI cao nhất là lựa chọn tốt nhất Nhưng cũng cần phải biết thời hạn hoàn vốn nữa để có sự hình dung đầy đủ E.g. Một ROI thấp hơn với thời hạn hoàn vốn sớm hơn có thể sẽ lý tưởng hơn trong một số trường hợp 17
Phân tích yêu cầu phần mềm (3) Khả thi về lịch biểu Phải mất bao lâu để tinh thông kỹ thuật ? Chúng ta có thể có kỹ thuật, nhưng không có nghĩa là chúng ta có các kỹ năng đòi hỏi để áp dụng kỹ thuật đó một cách chính xác. Có thể cần thuê nhân sự mới Hoặc huấn luyện lại đội ngũ nhân viên của hệ thống hiện có. Liệu việc đi thuê hay huấn luyện thì có ảnh hưởng đến lịch biểu ? Đánh giá lịch biểu rủi ro: Chúng ta đã có sự tinh thông về kỹ thuật, hạn cuối (deadline) của dự án đưa ra có hợp lý không? Nếu có một hạn cuối cụ thể, thì đó là thời hạn bắt buộc hay thời hạn mong muốn? Điều gì là ràng buộc thực sự trên hạn cuối dự án? Nếu dự án overrun, thì hậu quả là gì? Không kịp lịch biểu thì không hay, nhưng hệ thống không hoàn thiện thì còn tệ hơn nữa! 18
Phân tích yêu cầu phần mềm (4) Khả thi về vận hành Người dùng và các nhà quản lý cảm thấy như thế nào về vấn đề mà bạn đã nhận ra? các giải pháp thay đổi mà bạn đang khảo sát? Bạn phải đánh giá: Không chỉ liệu một hệ thống có thể hoạt động mà còn liệu một hệ thống sẽ hoạt động hay không. Mọi giải pháp đều gặp sự đối kháng: Ban quản lý có hỗ trợ dự án hay không? Những người dùng cảm thấy vai trò của họ trong hệ thống mới như thế nào? Những người dùng hay nhà quản lý nào có thể chống đối (hoặc không dùng) hệ thống? Môi trường làm việc của người dùng sẽ thay đổi như thế nào? Người dùng và ban quản lý có thể hoặc sẽ đáp ứng được với thay đổi? 19
Phân tích yêu cầu phần mềm Nội dung báo cáo nghiên cứu khả thi 1. M ục đích và phạm vi nghiên cứu 5. Những thay đổi có thể Các mục tiêu (của nghiên cứu) bao gồm cả ‘không thực hiện gì’. Ai được ủy quyền và ai thực hiện nó, 6. Tiêu chuẩn so sánh Các nguồn thông tin, Các quy trình dùng cho việc nghiên Định nghĩa các tiêu chuẩn . cứu, 7. Phân tích các thay đổi Tốn bao nhiêu thời gian, Mô tả mỗi thay đổi 2. Mô tả hiện trạng Đánh giá với các khía cạnh tiêu chuẩn Môi trường tổ chức, các hệ thống Phân tích chi phí/lợi nhuận và những hiện tại. gợi ý đặc biệt. Những tác nhân và các ràng buộc 8. Kiến nghị liên quan. Kiến nghị điều gì và các gợi ý 3. Vấn đề và các yêu cầu Tiếp theo cần làm gì; Cái gì là sai trong hiện trạng ? E.g. có thể đề nghị một giải pháp tạm thời và một giải pháp lâu dài Thay đổi gì thì cần thiết? 4. Các mục tiêu của hệ thống mới 9. Phụ lục Các mục tiêu cầu đạt và mối liên hệ Bao gồm mọi tài liệu hỗ trợ. giữa chúng. 20
Phân tích yêu cầu phần mềm So sánh các sự lựa chọn Chúng ta sẽ so sánh các lựa chọn như thế nào? Khi nào thì có nhiều tiêu chuẩn lựa chọn ? Khi nào thì không có lựa chọn nào trội hơn trên toàn diện? Dùng một ma trận phân tích khả thi (Feasibility Analysis Matrix)! Cột tương ứng với các giải pháp ứng viên; Dòng tương ứng với các tiêu chuẩn khả thi; Các ô chứa chú thích về sự đánh giá khả thi cho mỗi ứng viên; Mỗi dòng có thể gán một cấp độ hoặc điểm cho mỗi tiêu chuẩn e.g., cho tính khả thi về vận hành, ứng viên có thể có các cấp độ 1, 2, 3, etc. Một cấp độ hay điểm số cuối cùng được ghi nhận ở dòng cuối cùng. Các tiêu chuẩn đánh giá khác cũng bao gồm trong ma trận Chất lượng output Dễ sử dụng Hỗ trợ đại lý Chi phí bảo trì Nạp vào hệ thống 21
Phân tích yêu cầu phần mềm Ma trận ví dụ 22
Phân tích yêu cầu phần mềm 23
Phân tích yêu cầu phần mềm 24
Phân tích yêu cầu phần mềm Lecture 4: Thu thập yêu cầu Ranh giới (Boundaries) Phạm vi của vấn đề Các đối tác (Stackholders) Xác định những người làm chủ vấn đề Mục tiêu (Goals) Định nghĩa các tiêu chuẩn thành công Kịch bản (Scenarios) Sử dụng các ví dụ cụ thể để hiểu vấn đề 1
Phân tích yêu cầu phần mềm Nhà phân tích yêu cầu là cầu nối giao tiếp giữa khách hàng và các đối tác của sự phát triển.
Chúng ta bắt đầu từ đâu ? Xác định vấn đề Mục tiêu của dự án là gì ? Sự nhìn nhận của người nêu ra nó ? e.g., “Lập lịch họp hiện giờ thì quá tốn kém” Phạm vi vấn đề Cung cấp phạm vi bàn bạc vấn đề ? e.g. “Xây dựng hệ thống lập lịch họp”, hoặc e.g. “Xây dựng hệ thống quản lý lịch làm việc của nhân viên” hoặc Định nghĩa kịch bản cho giải pháp Đặt vấn đề - tiến trình tương thích để giải quyết nó ? e.g. “Một ai đó muốn lập lịch họp thì phải đến gặp thư ký, viết các chi tiết vào sổ tay thư ký và để lại”, hoặc Phạm vi giải pháp Nêu quá trình xử lý – phần nào sẽ phải được làm tự động và như thế nào ? e.g. “Máy tính cần lập lịch một cách chi tiết, đầu ra là một giải pháp” hoặc e.g. “Giải pháp đạt đến bằng giao tiếp giữa thư ký và máy tính” hoặc 2
Phân tích yêu cầu phần mềm Làm rõ các yêu cầu W6H Kỹ thuật Điểm bắt đầu của các Một số ý kiến cho rằng có một “vấn đề” cần giải quyết nhà báo: e.g. Không hài lòng với tình trạng công việc hiện tại e.g. Một cơ hội kinh doanh mới What? e.g. Một tiềm năng hứa hẹn sẽ tiết kiệm được về chi phí, Where? thời gian, tài nguyên sử dụng, etc. Who? Cần thu thập đủ thông tin để: Why? Định nghĩa được “vấn đề” : (Which) Vấn đề nào cần được giải quyết ? (Ranh giới - Boundaries) When? (Where) Vấn đề ở đâu ? (hiểu ngữ cảnh/ phạm vi vấn đề How? – Context/Problem Domain) (Which?) (Whose) Vấn đề của ai? (Định nghĩa các Đối tác - Stakeholders) (Why) Tại sao cần giải quyết? (Định nghĩa Mục tiêu đối tác – ‘stakeholders’ Goals) (How) Hệ thống phần mềm sẽ hỗ trợ như thế nào? (Thu thập Kịch bản - Scenarios) (When) Khi nào cần phải giải quyết ? (Định nghĩa các ràng buộc phát triển – Development Constraints) (What) Điều gì ngăn chặn việc giải quyết chúng? (Định nghĩa tính khả thi và độ rủi ro - Feasibility and Risk) Là chuyên gia trong phạm vi của vấn đề Nghiên cứu khoanh vùng bao quanh vấn đề mới một cách nhanh chóng Dùng sự ngơ ngác (ban đầu) của bạn như một lý do để đặt những câu hỏi Nhận biết lĩnh vực chuyên môn của người đang nói chuyện với bạn 3
Phân tích yêu cầu phần mềm Nhận dạng vấn đề Vấn đề còn mơ hồ bởi chính khách hàng: E.g. Cửa hàng bán sách của Trường: Người quản lý muốn tin học hóa việc điền vào một form yêu cầu mua sách thay vì nhận yêu cầu bằng lời nói; E.g. Một công ty bảo hiểm lớn: Người quản lý bồi thường muốn giảm thời gian trung bình của một hồ sơ bồi thường bảo hiểm từ 2 tháng xuống 2 tuần. E.g. Một công ty viễn thông: Một CIO (Chief of Information Officer) muốn tích hợp hệ thống hiện có với hệ thống lưu trữ khách hàng của một số chi nhánh thành một hệ thống duy nhất. E.g. Trạm không gian vũ trụ của chính phủ (Government Aerospace Agency) Tổng thống muốn gửi một phái đoàn đến sao Hỏa (Mars) vào năm 2020 Thường chỉ thấy ‘triệu chứng’ hơn là ‘nguyên nhân’: E.g. “Bệnh nhân ở Trung tâm ung bướu muốn chụp X-ray phải chờ hàng tháng” Thời gian chờ chỉ là biểu hiện, không phải vấn đề. Vấn đề phải là: Thiếu máy X-ray; Thiếu đội ngũ chuyên môn; Thiếu bác sĩ xử lý dữ liệu Cách lập lịch hẹn không hiệu quả 4
Phân tích yêu cầu phần mềm Các nguồn bổ sung yêu cầu Mô hình tiến trình yêu cầu của Volere gợi ý một số nguồn bổ sung yêu cầu như sau : 5
Phân tích yêu cầu phần mềm Các đối tác (Stackholders) Xác định đối tác Tất cả những người được hỏi ý kiến trong suốt quá trình thu nhận thông tin cho hệ thống. Ví dụ về đối tác Người dùng (Users) Nhà thiết kế (Designers) Nhà phân tích hệ thống (Systems analysts) Đội ngũ huấn luyện và hỗ trợ người dùng (Training and user support staff) Nhà phân tích kinh doanh (Business analysts) Các tác giả kỹ thuật (Technical authors) Người quản lý dự án (The project manager) ”Khách hàng” (“The customer”) 6
Phân tích yêu cầu phần mềm Tìm kiếm đối tác : Biểu đồ Org Sự tổ chức của biểu đồ chỉ ra Vùng trách nhiệm (dồn theo hướng đi lên) Tuyến phân quyền (giao phó theo hướng đi xuống) Đây là một công cụ nhằm chỉ rõ các đối tác ở đâu Nhưng cần nhớ rằng hầu hết các hoạt động đều phải bao gồm sự liên kết ngang qua biểu đồ org 7
Phân tích yêu cầu phần mềm Các cấp độ phân quyền Qu ản trị cấp cao (top) Thiết lập các mục tiêu Lập kế hoạch trên phạm vi rộng Xác định thị trường mới và sản phẩm cần phát triển Quyết định đối tượng liên doanh và kết quả đạt được. Quản trị trung gian (middle) Sắp đặt các mục tiêu Phân phối & kiểm soát tài nguyên Thực hiện kế hoạch Đo lường sự thực thi Quản trị cấp thấp (lower) Giám sát hoạt động hàng ngày Điều chỉnh các hành động khi cần thiết. Cấp vận hành Thực hiện các hoạt động hàng ngày 8
Phân tích yêu cầu phần mềm Xác định mục tiêu các đối tác Source: Adapted from Anton, 1996 Cách tiếp cận Tập trung vào việc tại sao một hệ thống thì cần đến Phát biểu ‘tại sao’ như là một tập mục tiêu của đối tác Dùng cách tinh chế mục tiêu để đạt được sự đặc tả cho các yêu cầu Phân tích mục tiêu Phát triển mục tiêu Phân cấp mục tiêu chỉ ra sự tinh chế (refinements) và sự chuyển đổi (alternatives) Thuận lợi Mang tính trực quan Việc khai báo rõ ràng các mục tiêu sẽ cung cấp một nền tảng hợp lý để giải quyết các mâu thuẫn Bất lợi Chỉ bắt được một hình ảnh tĩnh – liệu rằng mục tiêu sẽ có thay đổi theo thời gian? Có thể có xu hướng lên (hoặc xuống) mãi trên sự phân cấp mục tiêu 9
Phân tích yêu cầu phần mềm Mô hình hóa mục tiêu Mục tiêu cố định (Hardgoals) Các tác nhân (agents): Mô tả các chức năng cần phải thực Là người chủ của các mục tiêu hiện. Lựa chọn khi nào thì gán các mục Sự đáp ứng các mục tiêu tiêu vào tác nhân: Việc thông tin các mục tiêu Xác định tác nhân trước, và tiếp đến là mục tiêu của chúng Mục tiêu linh hoạt (Softgoals): Xác định mục tiêu trước, và sau đó Không thể thực sự đáp ứng một cách chỉ định chúng cho các tác nhân trong suốt đầy đủ. E.g. Tính chính xác, Độ thực quá trình hoạt động thi, Tính bảo mật, Lời khuyên khi mô hình hóa: Cũng có thể phân lớp một cách Các nguồn phức tạp thì tốt hơn tạm thời: cho mục tiêu Mục tiêu hoàn tất/ngừng Các đối tác liên đới với mỗi mục Chạm tới một số trạng thái mong muốn tiêu - sau cùng Dùng kịch bản để khảo sát sự đáp Mục tiêu duy trì/bỏ đi ứng của các mục tiêu Giữ một số đặc tính không thay đổi Xem xét kỹ lưỡng các trở ngại để Mục tiêu tối ưu giúp suy ra những ngoại lệ Một tiêu chuẩn để chọn lựa hành vi 10
Phân tích yêu cầu phần mềm Ví dụ : Cách phát sinh mục tiêu (Cây mục tiêu) 11
Phân tích yêu cầu phần mềm Mô hình mục tiêu Sự phát sinh mục tiêu Câu hỏi “Tại sao? (Why)” khảo sát các mục tiêu cao hơn (ngữ cảnh) Câu hỏi “Như thế nào? (How)” khảo sát các mục tiêu thấp hơn (hoạt động) Câu hỏi “Cái khác thì thế nào ?(How else)” khảo sát các chọn lựa Quan hệ giữa các mục tiêu: Một mục tiêu hỗ trợ đạt đến cái khác (+) Một mục tiêu làm hại sự đạt đến cái khác (-) Một mục tiêu phát sinh cái khác (++) Đạt được mục tiêu A thì chắc chắn đạt được mục tiêu B Một mục tiêu ngăn chặn cái khác ( ) Đạt được mục tiêu A thì ngăn chặn đạt được mục tiêu B Thứ tự ưu tiên – khi các mục tiêu phải đạt đến theo một thứ tự cụ thể Phân tích trở ngại: Mục tiêu này có thể bế tắc hay không, nếu vậy thì thế nào? Hậu quả của việc bế tắc này là gì ? 12
Phân tích yêu cầu phần mềm Mục tiêu linh hoạt (SoftGoals) Một số mục tiêu có thể không bao giờ được đáp ứng một cách đầy đủ Xem những mục tiêu này như mục tiêu linh hoạt E.g. “hệ thống dễ sử dụng”; “truy cập an toàn” Cũng được biết như là ‘các yêu cầu phi chức năng’; ‘các yêu cầu chất lượng’ Sẽ xem xét những thứ góp phần làm đáp ứng các mục tiêu linh hoạt E.g. Đối với một hệ thống xe lửa: 13
Phân tích yêu cầu phần mềm Softgoals như các tiêu chuẩn lựa chọn 14
Phân tích yêu cầu phần mềm Kịch bản (Scenarios) Source: Adapted from Dardenne, 1993 Kịch bản Mô tả hệ thống sẽ được dùng như thế nào trong thực tế, là dòng đặc tả giao tiếp giữa người thực hiện và hệ thống. Rất hữu ích cho việc thu thập yêu cầu vì con người có thể quan hệ dễ dàng hơn là các câu lệnh trừu tượng khi họ yêu cầu từ hệ thống Có khuynh hướng ngắn gọn (e.g từ 3 đến 9 bước) Có thể là kịch bản động (yêu cầu có hành vi) hoặc tĩnh (không cần sự tương tác) Có thể trình diễn (mô tả hệ thống hiện tại) hoặc suy diễn (nó sẽ thực hiện thế nào) Thuận lợi Rất tự nhiên: các đối tác có khuynh hướng sử dụng chúng một cách tự động E.g “giả sử tôi phải đi bệnh viện – chuyện gì xảy ra trong suốt thời gian nhập viện của tôi?” Câu trả lời thông thường: “Bạn, hoặc người đi cùng bạn đến bàn tiếp nhận. Bạn phải trình thẻ bảo hiểm y tế của bạn và nói rõ vì sao bạn đến bệnh viện. Sau đó, ” Các kịch bản ngắn thì rất tốt cho việc minh họa các giao tiếp cụ thể Bất lợi Thiếu cấu trúc Khó để kiểm tra tính hoàn thiện 15
Phân tích yêu cầu phần mềm Ví dụ về kịch bản (1) Chủ đề: Sắp xếp lịch họp thành công dùng tùy chọn gửi tin nhắn Thành viên: Nam (người đề nghị, không tham dự); Bảo, Cang, Dung (tham dự) Hành động Mục tiêu cần thỏa Trở ngại / Vấn đề b1: Nam yêu cầu cuộc họp, nêu thành Yêu cầu họp; Liệu khung thời gian đã chọn có viên, khung thời gian Danh sách thành viên thể không thực hiện được ? b2: Thư ký của Nam gủi tin nhắn đến ? Họ không có mặt ở đó ? các thành viên Bảo, Cang, Dung b3: Bảo đọc tin nhắn Không thể phát hiện được khi tin nhắn được đọc, điều gì xảy ra khi Cang đọc tin nhắn Thông tin đến các thành viên Bảo đọc nhưng không phản hồi? Dung đọc tin nhắn Liệu các lịch đề nghị có loại trừ b4: Bảo phản hồi với lịch đề nghị lẫn nhau? Cang phản hồi với lịch đề nghị Nhận được lịch đề nghị của các thành viên Chúng ta sẽ cho phép ai ưu tiên Dung phản hồi với lịch đề nghị cao hơn? b5: Thư ký của Nam lập lịch cuộc Xác định phòng họp có thể; họp Đăng ký phòng b6: Thư ký của Nam lưu ý Nam, Thông báo cuộc họp; Làm thế nào để biết chắc họ đã đọc được thông báo? Liệu lịch Bảo, Cang, Dung về thời gian và Xác nhận lại với các thành địa điểm cuộc họp cuộc họp đã không còn thích hợp viên (?) nữa cho ai đó trong số họ? 16
Ví dụ về kịch bản (2a) Chủ đề: Phân tích giao dịch bán hàng trong siêu thị Thành viên: Nhân viên bán hàng, Hệ thống : Scenario thường (trường hợp không có lỗi) b1: Nhân viên bán hàng nhập vào username và password b2: Hệ thống kiểm tra username và password b3: Hệ thống đưa ra thông báo cho biết người dùng đã đăng nhập thành công b4: Hệ thống đưa ra chức năng tương ứng với quyền của nhân viên này. b5: Khi khách hàng mang hàng hóa đến, nhân viên tiến hành quét mã vạch của từng món hàng b6: Tính tiền cho khách hàng sau khi hệ thống quét hết mã vạch b7: Nhập vào số tiền mà khách hàng đưa b8: Nhấp vào nút “Tính” trên menu để hệ thống tính số tiền thừa trả lại cho khách hàng b9: Nhấp nút “In” để in ra hóa đơn. 17
Ví dụ về kịch bản (2b) Chủ đề: Phân tích giao dịch bán hàng trong siêu thị Thành viên: Nhân viên bán hàng, Hệ thống : Altenate Scenario (trường hợp có lỗi xảy ra) A1: Username và Password không đúng (chuỗi A1 bắt đầu từ b2) b3: Hệ thống báo lỗi không đăng nhập được b4: quay về b1 A2: Mã vạch không hợp lệ (chuỗi A2 bắt đầu từ b6) b7: Hệ thống đưa ra thông báo lỗi mã vạch cho nhân viên biết b8: quay lại b6 A3: Nhập vào số tiền không đúng (chuỗi A3 bắt đầu từ b7) b8: Hệ thống thông báo lỗi vì số tiền nhập vào không đúng b9: quay lại b7 A4: Số tiền nhập vào nhỏ hơn số tiền cần trả (chuỗi A4 bắt đầu từ b7) b8: Hệ thống thông báo lỗi vì không thể tính tiền b9: quay lại b7 18
Kết luận Phạm vi thì rất quan trọng Phạm vi vấn đề bạn cần giải quyết là gì? Phạm vi của giải pháp mong muốn là gì? Hỏi các câu hỏi Ai? (Who) và Tại sao? (Why) Ai là các đối tác chủ yếu ? Tại sao họ muốn vấn đề này được giải quyết? Phân tích mục tiêu của họ. Hỏi các câu hỏi Như thế nào?(How) Phải đáp ứng mỗi mục tiêu như thế nào? Một hệ thống mới cần được cải tiến những điều gì? Phát triển các kịch bản . 19
Phân tích yêu cầu phần mềm Lecture 5: Phân tích làm rõ yêu cầu (Eliciting Requirements) Cơ sở suy luận Tại sao việc thu thập yêu cầu thì khó khăn Việc đối phó với những thiên vị (bias) Một tập hợp lớn các kỹ thuật làm rõ yêu cầu: Đọc tài liệu cơ bản (Background Reading) Thu thập dữ liệu “cứng” (Hard data collection) Phỏng vấn (Interviews) Bảng câu hỏi (Questionnaires) Kỹ thuật cộng tác (Group Techniques) Tham gia quan sát (Participant Observation) Điều tra xã hội học (Ethnomethodology) Các kỹ thuật làm rõ tri thức 1
Phân tích yêu cầu phần mềm Khó khăn khi thu thập yêu cầu Kiến thức hẹp về lĩnh vực Rất hiếm khi có biểu mẫu rõ ràng (không viết ra) Phân tán qua nhiều nguồn Với sự mâu thuẫn giữa kiến thức từ các nguồn khác nhau Kiến thức ẩn ý (Vấn đề “nói và làm”) Người ta rất khó để tìm được cách mô tả cho các công việc mà họ thường làm Thiếu quan sát Người chủ vấn đề quá bận rộn với công việc từ hệ thống hiện tại Sự hiện diện của người quan sát có thể làm thay đổi vấn đề Thiên vị (Bias) Người ta không rảnh để nói điều bạn cần biết với bạn Người ta không muốn nói điều bạn cần biết với bạn - Một số dạng thiên vị (Thiên vị về tính thuyết phục (Motivational bias); Thiên vị về quan sát (Observation bias); Thiên vị về nhận thức (Cognitive bias); Thiên vị về ký pháp (Notation bias); ) 2
Phân tích yêu cầu phần mềm Ví dụ Bộ phận phê chuẩn cho vay trong một ngân hàng lớn Người phân tích đang thử thu thập các quy tắc và luật lệ của việc chấp thuận cho vay Tại sao vấn đề này khó khăn: Kiến thức ẩn : Không có tài liệu về các quy luật chấp thuận cho vay được viết ra. Thông tin mâu thuẫn : Nhân viên ở các ngân hàng khác nhau có các ý kiến rất khác nhau về quy luật này. Vấn đề “nói và làm” : Quy trình chấp thuận cho vay được mô tả bởi các nhân viên thì khá khác với sự quan sát của bạn về cái thực sự họ làm. Hiệu ứng thăm dò : Quy trình chấp thuận cho vay được sử dụng bởi các nhân viên trong khi bạn quan sát thì khác với cái mà họ thường dùng. Thành kiến : Nhân viên trong bộ phận này sợ rằng công việc của bạn sẽ tin học hóa công việc hiện có của họ, vì thế họ nhấn mạnh sự cần thiết của họ một cách kỹ lưỡng từng ly từng tí (để thuyết phục bạn rằng công việc chỉ có thể thực hiện được bởi con người!) 3
Phân tích yêu cầu phần mềm Các kỹ thuật làm rõ yêu cầu Kỹ thuật truyền thống Hướng ngữ cảnh (xã hội) Tự xem xét Kỹ thuật cộng đồng Đọc tài liệu cơ bản Tham gia quan sát Nhân chủng học Phân tích “dữ liệu cứng” Phân tích ngôn từ Phỏng vấn Phân tích cuộc đàm thoại Không cấu trúc (câu hỏi mở) Cấu trúc (câu hỏi đóng) Phân tích lời nói Phương pháp xã hội học Khảo sát / Lập bảng câu hỏi Phân tích hệ thống mềm Hội thảo Kỹ thuật nhận thức Kỹ thuật hợp tác Phân tích công việc Tập trung nhóm Phân tích giao thức Brainstorming Hội thảo JAD/RAD Các kỹ thuật làm rõ tri thức Lập bản mẫu Card Sorting Laddering Cùng thiết kế Repertory Grids Proximity Scaling Techniques 4
Phân tích yêu cầu phần mềm (1) Đọc tài liệu cơ bản Nguồn thông tin: Các báo cáo của công ty, sơ đồ tổ chức, tài liệu hướng dẫn giải pháp, báo cáo quy trình nghiệp vụ, các tài liệu của hệ thống hiện có, etc. Thuận lợi: Giúp bạn hiểu tổ chức trước khi tiếp xúc với những người làm việc ở đó. Giúp chuẩn bị về nhiều mặt trước khi tìm hiểu thực tế e.g. nhận thức những mục tiêu kinh doanh của tổ chức. Có được các yêu cầu chi tiết về hệ thống hiện hành. Bất lợi: Tài liệu đã viết thường không hoàn toàn phù hợp với thực tế. Có thể dài dòng với rất nhiều chi tiết không liên quan Phù hợp : Khi bạn không thân thiện với tổ chức mà bạn sắp khảo sát 5
Phân tích yêu cầu phần mềm (2) Dữ liệu “cứng” và Lấy mẫu (Sampling) “Dữ liệu cứng” (Hard data) bao gồm những thông tin chính xác như Các biểu mẫu, Hóa đơn, Báo cáo tài chính, Báo cáo được dùng để ra quyết định, Kết quả thống kê, dữ liệu tiếp thị, Lấy mẫu (Sampling) Lấy mẫu dùng để chọn đại diện từ một tập phổ biến Mục đích lấy mẫu – chọn các phần mà bạn nghĩ có liên quan mà không phải theo quy luật thống kê Simple Random Sampling – chọn phần tử ngẫu nhiên Stratified Random Sampling – phân tầng và chọn mẫu trên mỗi tầng Clustered Random Sampling – chọn một đại diện trên mỗi tập con phổ biến Kích thước mẫu thì rất quan trọng Cân đối giữa giá trị dữ liệu thu thập/ nhà phân tích và các yêu cầu quan trọng Tiến trình: Xác định thu thập dữ liệu gì - e.g. các giao dịch ngân hàng Xác định tập phô biến - e.g. tất cả các giao dịch ở 5 chi nhánh trong 1 tuần Chọn kiểu của mẫu - e.g. simple random sampling Chọn kích thước mẫu - e.g. cứ mỗi 20 giao dịch 6
Phân tích yêu cầu phần mềm Ví dụ về dữ liệu “cứng” (Hard data) Câu hỏi : Dữ liệu này cung cấp gì cho bạn ? Bạn sẽ làm gì với dữ liệu này ? 7
Phân tích yêu cầu phần mềm (3) Kỹ thuật phỏng vấn (Interviews) Source: Adapted from Goguen and Linde, 1993, p154 Các dạng Cấu trúc – chương trình cho các câu hỏi mở rất rõ ràng Không cấu trúc – không có chương trình trước Thuận lợi Thu thập được nhiều thông tin Tốt cho những quan điểm, cảm giác, mục tiêu không bao phủ cũng như các sự việc khó khăn Có thể thăm dò sâu, thích hợp cho việc đặt những câu hỏi nối tiếp để hiểu rõ họ nói gì với bạn Bất lợi Một số lớn dữ liệu mang tính định tính có thể khó phân tích Khó để so sánh với những người thực hiện phỏng vấn khác nhau Phỏng vấn là một kỹ năng khó Các lưu ý Những câu hỏi không thể trả lời - Kiến thức ẩn chứa ngầm Sự sai lệch từ ngữ cảnh Thái độ người phỏng vấn có thể tạo ra một số thiên vị 8
Phân tích yêu cầu phần mềm Một số kinh nghiệm phỏng vấn Bắt đầu Hãy bắt đầu cuộc phỏng vấn bằng một chủ đề vô thưởng vô phạt để tạo sự thoải mái e.g. Thời tiết, tỷ số trận đá bóng tối qua, e.g. Bình luận về một đồ vật trên bàn làm việc của họ : “ Bức hình này đẹp quá ! Bạn chụp nó à ?” Hỏi xem liệu bạn có thể ghi âm cuộc phỏng vấn Đặt máy ghi âm ở nơi có thể nhìn thấy Cho người được phỏng vấn biết rằng họ có thể tắt máy bất cứ lúc nào. Hỏi các câu hỏi dễ trước Có thể là các thông tin cá nhân e.g. “Bạn đã làm việc ở vị trí hiện tại bao lâu rồi?” Sau đó dẫn đến điều cần quan tâm E.g. Liệu bạn đã nghe ai đó nói rằng kế hoạch hoạt động của bạn là sai, e.g.,“Chúng ta có thể nói thêm một chút về điều mà bạn vừa nói không ?” Đặt các câu hỏi còn bỏ ngỏ vào phía cuối cuộc phỏng vấn e.g. “Còn điều gì khác bạn muốn nói thêm không?” 9
Phân tích yêu cầu phần mềm (4) Bảng câu hỏi (Questionnaires) Source: Adapted from Goguen and Linde, 1993, p154. Thuận lợi Có thể thu thập thông tin từ nhiều người một cách nhanh chóng Có thể quản lý được từ xa Có thể thu thập được các nội dung như quan điểm, niềm tin, tính cách Bất lợi Việc đơn giản hóa cấu trúc để lập bảng sẽ cung cấp rất ít ngữ cảnh Không có điều kiện cho người dùng chuyển tải những nhu cầu thực sự của họ Các lưu ý : Thành kiến trong việc chọn lựa mẫu người sẽ trả lời bảng câu hỏi Thành kiến trong việc trả lời các lựa chọn cá nhân Kích thước mẫu nhỏ (thiếu sự thống kê trên diện rộng) Các câu hỏi dạng mở (rất khó để phân tích!) Các câu hỏi mơ hồ (I.e. không phải mọi người đều trả lời cùng câu hỏi) Các câu hỏi chỉ đạo (“Bạn thì phải ?”) Các câu hỏi riêng tư (“Đây là bức hình gì ?”) Lưu ý : Bảng câu hỏi cần phải được lập mẫu và kiểm tra ! 10
Phân tích yêu cầu phần mềm (5) Hội thảo (Meetings) Dùng cho tổng kết và phản hồi E.g. Gặp gỡ các đối tác vào cuối của mỗi giai đoạn: Thảo luận về kết quả các thông tin thu thập được trong giai đoạn đó Kết luận về tập hợp các yêu cầu Thỏa thuận cách thiết kế, etc. Dùng hội thảo để xác nhận những điều đã khảo sát, thảo luận về phương hướng sắp tới Hội thảo là một công cụ quản lý quan trọng Nhằm bác bỏ một dự án đã thay đổi Mỗi cuộc hội thảo sẽ làm sáng tỏ các mục tiêu: E.g. Cách trình bày, giải quyết vấn đề, giải quyết mâu thuẫn, phân tích tiến trình, thu thập và kết hợp sự kiện, huấn luyện, lập kế hoạch, Cần lập kế hoạch hội thảo một cách kỹ lưỡng Thời gian hội thảo phải được sắp xếp thuận tiện Chuẩn bị lịch biểu và phân phát rộng rãi Giữ đúng thời gian và lịch biểu trong suốt hội thảo Bám theo bản báo cáo tổng kết để thảo luận với các thành viên hội thảo Các quy luật đặc biệt được áp dụng là báo cáo hình thức, đi sâu vào vấn đề (walkthroughs), động não (brainstorming), etc. 11
Phân tích yêu cầu phần mềm (6) Kỹ thuật làm việc nhóm Các dạng: Nhóm tập trung (Focus Groups) Chiến lược động não (Brainstorming) Thuận lợi Có sự giao tiếp tự nhiên giữa mọi người hơn là cách phỏng vấn hình thức Có thể đo lường được phản ứng với những chất liệu hỗ trợ (e.g. mô hình, bảng truy vấn, etc) Bất lợi Có thể tạo ra những nhóm làm việc không thân thiện Các vấn đề phát sinh từ ý kiến chung của nhóm Có thể chỉ cung cấp những giải pháp thiển cận cho vấn đề kỹ thuật Đòi hỏi những kỹ năng huấn luyện cao Các lưu ý Có định kiến về một mẫu tiêu biểu nào đó Sự áp đảo và phục tùng 12
Phân tích yêu cầu phần mềm (7) Phát triển ứng dụng nhanh Joint/Rapid Nguyên tắc JAD & RAD: Nhóm làm việc linh động – dùng hội thảo thay vì phỏng vấn Phương tiện nghe nhìn : nhiều phương tiện trực quan, e.g. biểu đồ, màn ảnh rộng, giao diện đồ họa, Tiến trình tổ chức : Các kỹ thuật được dùng là động não nhóm (bainstorming) và phân tích trên xuống (and top-down analysis) Lập tài liệu WYSIWYG : Tài liệu kết quả sau mỗi cuộc họp JAD phải dễ hiểu và phải được lập ra bởi sự thỏa hiệp chung trong suốt cuộc họp Lưu ý: Chọn lựa kỹ lưỡng các thành viên tham dự : Họ sẽ là những người tốt nhất để trình bày lại cho các nhóm đối tác khác nhau Hội thảo nên ít nhất từ 3-5 ngày. Phải gom nhóm các thành viên vào thành đội – mất 1-2 ngày. Lãnh đạo cuộc họp cần chắc chắn rằng mỗi bước thực hiện đều đã được chuẩn bị kỹ lưỡng. Lãnh đạo cuộc họp cần có thời gian quyết định khi có nhiều quan điểm khác nhau – “vấn đề mở” Phòng hội thảo phải đủ phương tiện – dụng cụ trình chiếu, máy ghi âm, etc 13
Phân tích yêu cầu phần mềm (8)Tham gia quan sát Hướng tiếp cận Dành thời gian để quan sát vấn đề Tham gia đủ lâu để trở thành thành viên của nhóm làm việc Thích hợp cho việc xem xét theo chiều dọc của vấn đề Thuận lợi Có kiến thức về môi trường công việc (ngữ cảnh); Phát hiện được nhiều chi tiết mà các phương pháp khác không có được. Bất lợi Cực kỳ tốn thời gian! Thu được quá nhiều kết quả sẽ rất khó để phân tích Không thể nói gì nhiều về sự thay đổi của kết quả đầu ra Cần lưu ý Sự hòa nhập cộng đồng ! 14
Phân tích yêu cầu phần mềm (9) Điều tra xã hội học (Ethnomethodology) Source: Adapted from Goguen and Linde, 1993, p158 Lập luận cơ sở Môi trường xã hội thì có trật tự Trật tự xã hội có thể không rõ ràng, hoặc không thể mô tả được từ nhận thức chung Trật tự xã hội không thể giả thiết có một cấu trúc thứ tự Trật tự xã hội được thiết lập trên cơ sở từng thời điểm hiện tại thông qua sự tập hợp các hoạt động của những thành viên (không theo cấu trúc định sẵn trước) i.e. trật tự xã hội chỉ có thể được quan sát khi người quan sát gia nhập chính họ vào trong đó. Việc quan sát nên thực hiện trong bối cảnh tự nhiên Cần phải xem xét ý nghĩa của phát triển và tiến hóa trong ngữ cảnh đó là như thế nào Dùng “phạm trù chủ thể” Hầu hết tập quán, tục lệ đều theo hướng thừa nhận các phạm trù đã tồn tại trước đó Điều này có thể sẽ đánh lạc hướng người quan sát (e.g. sự tương đồng) Phương pháp điều tra xã hội học cố gắng để dùng các phạm trù chủ thể (Khái niệm) phạm trù nào mà mọi người dùng để lập trật tự cho môi trường xã hội? Phương pháp gì người ta dùng để nhận thức về thế giới xung quanh họ? Dùng cùng phương pháp mà các thành viên đã dùng trong suốt khảo sát E.g bằng cách phát triển một quy luật hợp pháp trong cộng đồng dưới sự quan sát. 15
Phân tích yêu cầu phần mềm Lecture 6: Mô hình hóa yêu cầu Làm rõ các khái niệm Mô hình hóa là gì ? Các yêu cầu; Hệ thống; Tư duy hệ thống (Systems Thinking) Vai trò của Mô hình hóa trong RE Tầm quan trọng của mô hình hóa Hạn chế của mô hình hóa Tổng quan về các ngôn ngữ mô hình hóa Nguyên tắc mô hình hóa Trừu tượng hóa (Abstraction) Phân tách (Decomposition) Quy chiếu (Projection) Mô-đun hóa (Modularity) 1
Phân tích yêu cầu phần mềm Khái niệm : Các định nghĩa Application Domain Machine Domain C - computers D - domain properties R - requirements P - programs Một vài điểm khác biệt Domain Properties: những điều luôn luôn đúng trong lĩnh vực ứng dụng Requirements: những điều chúng ta mong là đúng trong lĩnh vực ứng dụng Specification: mô tả các hành vi chương trình cần thực hiện để đáp ứng với các yêu cầu Hai tiêu chí cho kiểm tra (verification) Chương trình (Program) thực hiện trên một máy tính (Computer) cụ thể đáp ứng với đặc tả (Specification) Đặc tả (Specification) được cho trong thuộc tính của lĩnh vực (Domain properties) thỏa mãn các yêu cầu (Requirements) Hai tiêu chí cho kiểm chứng (validation) Chúng ta đã xem xét (và hiểu) tất cả các yêu cầu (Requirements) quan trọng? Chúng ta đã xem xét (và hiểu) tất cả các thuộc tính lĩnh vực(Domain properties) liên quan? 2
Phân tích yêu cầu phần mềm Khái niệm : Từ hệ thống đến mô hình Source: Adapted from Loucopoulos & Karakostas, 1995, p73 Maintains Needs information information about about Subject System Uses Information system Usage System contracts builds Development System . 3
Phân tích yêu cầu phần mềm Khái niệm : Tư duy hệ thống 4
Phân tích yêu cầu phần mềm Mô hMô hình hóa Mô hình hóa có thể hướng dẫn suy luận Nó có thể giúp bạn chỉ ra câu hỏi gì để hỏi Nó có thể giúp làm nổi rõ các yêu cầu ẩn chứa i.e. giúp bạn hỏi những câu chính xác? Mô hình hóa có thể cung cấp sự đo lường cho quy trình: Việc hoàn thiện của mô hình -> hoàn thiện của suy luận (?) i.e. chúng ta có thể hoàn thiện tất cả các thành phần của mô hinh, được không? Mô hình hóa có thể giúp phơi bày các vấn đề Sự mâu thuẫn trong các mô hình có thể dẫn đến nhiều thứ đáng quan tâm e.g. các yêu cầu xung đột hoặc không thể thực hiện e.g. nhầm lẫn các thuật ngữ, phạm vi, etc e.g. bất đồng giữa các đối tác Mô hình hóa có thể giúp kiểm tra sự thấu hiểu của bạn Lý giải trên các mô hình để hiểu kết quả của nó Nó có đạt được những đặc tính mà chúng ta mong muốn? Xây dựng hình ảnh bằng các mô hình giúp quan sát/kiểm chứng các yêu cầu 5
Phân tích yêu cầu phần mềm RE gồm nhiều bước mô hình hóa Source: Adapted from Jackson, 1995, p120-122 Mô hình thì tốt hơn chỉ là sự mô tả Nó có các hiện tượng của nó và có quan hệ chủ thể giữa các hiện tượng này. Mô hình sẽ hữu ích khi các hiện tượng của mô hình phù hợp một cách có hệ thống với các hiện tượng trong lĩnh vực mà nó cần được mô hình hóa 6
Phân tích yêu cầu phần mềm “Đó chỉ là mô hình” Source: Adapted from Jackson, 1995, p124-5 Rất thường thấy rằng: Hiện tượng trong mô hình thì không hiện diện trong lĩnh vực ứng dụng Hiện tượng trong lĩnh vực ứng dụng thì không có trong mô hình ISBN Book title name DOB (1,n) (0,n) author Person Hiện tượng Hiện tượng không Hiện tượng không được nắm bắt chung thực tế trong mô hình không có hai các tác giả “ma” mỗi quyển sách có ít nhất một tác giả người sinh ra vào bút danh cùng ngày và có nặc danh mỗi quyển sách chỉ có một ISBN duy nhất cùng tên Một mô hình không khi nào là hoàn hảo “Nếu bản đồ và địa hình không giống nhau, hãy tin vào địa hình” Tìm kiếm sự hoàn hảo của một mô hình thì không là việc tốt cho thời gian của bạn 7
Phân tích yêu cầu phần mềm Chọn ký pháp cho việc mô hình hóa Source: Adapted from Loucopoulos & Karakostas, 1995, p72-73 Ngôn ngữ tự nhiên Cực kỳ diễn cảm và linh hoạt hữu ích cho suy diễn, và lập các mô hình ký hiệu dễ đọc Khó để nắm bắt được các quan hệ mấu chốt Ký pháp bán hình thức Nắm được cấu trúc và một số ngữ nghĩa UML phù hợp ở đây Có thể thực hiện (một số) hoạt động, kiểm tra tính nhất quán, ảnh động, etc. E.g. lược đồ, bảng, cấu trúc tiếng Anh, etc. Gần như là trực quan – cho phép chuyển thông tin một cách nhanh chóng đến các dạng đối tác khác nhau Ký pháp hình thức Ngữ nghĩa chính xác, có thể suy luận rộng các mô hình dựa trên cơ sở toán (e.g. lý thuyết tập hợp, FSMs (finite-state machine), etc) Các mô hình rất chi tiết (có thể chi tiết hơn cả cái chúng ta cần) RE hình thức thì không chấp nhận việc mô hình hóa, điều này thì khác với hầu hết các dạng khoa học máy tính khác 8
Phân tích yêu cầu phần mềm Mục tiêu của ký pháp mô hình hóa Source: Adapted from Loucopoulos & Karakostas, 1995, p77 Cài đặt độc lập Dễ phân tích Không mô hình sự hiển thị dữ kiệu, Cho phép phân tích dữ liệu mơ hồ, cách tổ chức bên trong, etc. chưa đầy đủ và không nhất quán Tính trừu tượng Dễ lần vết Đưa ra các khía cạnh thiết yếu Cho phép các phần tử tham chiếu e.g. những thứ không buộc phải thay Cho phép liên kết với thiết kế đổi thường xuyên cài đặt, etc. Tính hình thức Tính khả thi Cú pháp không mơ hồ có thể cho mô hình hoạt động để so Ngữ nghĩa biểu cảm sánh nó với thực tế Tính kiến trúc Tối thiểu hóa Có thể thiết kế từng phần của mô Không dư thừa các khái niệm trong hình để kiểm soát được độ phức tạp lược đồ mô hình hóa và kích thước của nó i.e. không chọn lựa hiển thị các vấn Thiết kế cần có sự giao tiếp dễ dàng đề nào đó không liên quan 9
Phân tích yêu cầu phần mềm Khảo sát các kỹ thuật mô hình hóa Mô hình hóa nghiệp vụ Mô hình hóa tổ chức: i*, SSM, ISAC Mục đích & Mục tiêu Mô hình hóa mục tiêu: Kiến trúc tổ chức KAOS, CREWS Công việc & các phụ thuộc Mô hình hóa thông tin: Tác nhân, vai trò, dự định E-R, Class Diagrams Mô hình hóa thông tin & hành vi Phân tích cấu trúc: SADT, SSADM, JSD Cấu trúc thông tin Phân tích hướng đối tượng: Quan điểm hành vi OOA, OOSE, OMT, UML Kịch bản và tình huống Mô hình máy trạng thái Các phương pháp hình thức: Dòng thông tin SCR, RSML, Z, Larch, VDM Các yêu cầu về thời gian/trình tự Thỏa thuận chất lượng: QFD, win-win, AHP, Mô hình hóa chất lượng hệ thống Đạc tả NFRs: Những gì ‘có thể’: Timed Petri nets (mức độ thực thi) Có thể sử dụng, đáng tin cậy, có thể phát triển, Task models (tính dễ sử dụng) an toàn, bảo mật, khả thi, tương tác, Probabilistic MTTF (độ tin cậy) 10
Phân tích yêu cầu phần mềm Unified Modelling Language (UML) Phương pháp hướng đối tượng thế hệ thứ ba Booch, Rumbaugh & Jacobson là những tác giả đầu tiên Vẫn còn đang tiến hóa Nổ lực chuẩn hóa sự tiến triển trên các dạng hướng đối tượng khác nhau Hoàn toàn là ký pháp Không có phương pháp mô hình nào liên quan tới nó! Được dự định là một thiết kế ký pháp (một số đặc tính không phù hợp với RE) Đã trở thành một công nghệ chuẩn Nhưng được làm chủ bởi IBM/Rational (đã bán nhiều công cụ và dịch vụ UML) Có một khung mô hình (meta-model) chuẩn Use case diagrams Class diagrams Message sequence charts Activity diagrams State Diagrams Module Diagrams Platform diagrams 11
Phân tích yêu cầu phần mềm Meta-Modelling Có thể so sánh lược đồ mô hình hóa dùng meta-models: Mỗi lược đồ sẽ nắm bắt các hiện tượng gì ? Cách thức soạn thảo các mô hình cần dựa theo hướng dẫn nào? Cần thực hiện phân tích gì trên các mô hình? Ví dụ về meta-model: tinh chế Mục tiêu chủ cài đặt tinh Tác nhân Công việc chế được gán cho 12
Phân tích yêu cầu phần mềm Nguyên tắc mô hình hóa Dễ dàng sửa đổi và tái sử dụng Những nhà phân tích có kinh nghiệm thường sử dụng lại kinh nghiệm trước đây của họ họ sử dụng lại các thành phần (của mô hình mà họ đã xây dựng trước đó) họ sử dụng lại cấu trúc (của mô hình mà họ đã xây dựng trước đó) Những nhà phân tích thông minh có thể hoạch định cho tương lai họ tạo ra các thành phần có thể sử dụng lại trong mô hình của họ họ cấu trúc mô hình của họ để chúng dễ dàng sửa đổi Các ý niệm hữu ích: Trừu tượng hóa (Abstraction) : Tháo bỏ các chi tiết để tập trung vào những thứ quan trọng Phân tách (Partitioning) : Phân chia vấn đề thành các phần độc lập, để khảo sát riêng biệt Quy chiếu (Projection) : Phân chia các khía cạnh (views) khác nhau và mô tả chúng một cách riêng biệt Mô-đun hóa (Modularization) : Chọn lựa các cấu trúc ổn định theo thời gian để dễ định vị sự thay đổi Mẫu (Patterns) : Cấu trúc của một mô hình đã có xuất hiện trong nhiều ứng dụng khác nhau 13
Phân tích yêu cầu phần mềm Nguyên tắc 1: Phân tách Sự phân tách Nắm rõ được sự tập hợp (aggregation)/phần của quan hệ (relationship) Ví dụ: Mục tiêu là khai thác một con tàu vũ trụ Phân tách vấn đề thành các vấn đề con: Các chỉ dẫn và cách điều khiển; Quản lý dữ liệu; Chỉ huy và kiểm soát; Kiểm soát môi trường; Theo dõi các thiết bị đo đạc; etc Chú ý: đây không phải thiết kế, chỉ là sự phân tích vấn đề Thiết kế thực sự phải có đủ mọi thành phần, không có liên quan với các vấn đề con này Tuy nhiên, cách chọn lựa của phân tách vấn đề sẽ có thể được phản ánh trong thiết kế 14
Phân tích yêu cầu phần mềm Nguyên tắc 2: Trừu tượng hóa Source: Adapted from Davis, 1990, p48 and Loucopoulos & Karakostas, 1995, p78 Trừu tượng hóa Là cách tìm kiếm sự tương tự giữa các khái niệm bằng việc lờ đi một số các chi tiết Tập trung vào mối quan hệ tổng quan/cụ thể giữa các hiện tượng Phân loại vào thành nhóm các thực thể khi chúng có vai trò tương tự như thành phần của một nhóm độc lập Quan hệ kế thừa biểu diễn sự tương tự giữa các lớp khác nhau trong một mối quan hệ kết hợp ‘(is_a)’ Ví dụ: Yêu cầu là : kiểm soát lỗi trên tàu vũ trụ Phải nhóm các lỗi khác nhau vào thành lớp LỖI Dựa vào vị trí: Dựa vào triệu chứng: lỗi thiết bị đo, không có đáp ứng từ thiết bị; lỗi truyền thông, đáp ứng không chính xác; lỗi xử lý, tự báo lỗi; etc etc 15
Phân tích yêu cầu phần mềm Nguyên tắc 3: Quy chiếu Source: Adapted from Davis, 1990, p48-51 Quy chiếu: Phân chia các lĩnh vực của mô hình thành nhiều khía cạnh (viewpoints) tương tự các phép chiếu được dùng bởi kiến trúc sư trong xây dựng Ví dụ: Cần lập các mô hình về yêu cầu cho tàu vũ trụ Phân chia mô hình : độ an toàn khả năng chỉ huy khả năng chịu lỗi đúng thời gian và trình tự Etc Chú ý: Quy chiếu và Phân tách thì tương tự nhau: Phân tách định nghĩa một ‘phần’ của quan hệ Phép chiếu định nghĩa một ‘khía cạnh’ của quan hệ Phân tách thừa nhận mỗi phần thì tương đối độc lập 16
Phân tích yêu cầu phần mềm Một ví dụ tổng quan về UML Source: Adapted from Davis, 1990, p67-68 Quan hệ thừa kế Quan hệ tập hợp (hệ thống phân cấp trừu tượng) (hệ thống phân cấp phân chia) :patient :patient Name Name Date of Birth physician Date of Birth physician history history 0 1 0 1 0 1 1 1 2 0 2 :in-patient :out-patient :heart :kidney :eyes Last visit Room Natural/artif. Natural/artif. Natural/artif. next visit Bed Orig/implant Orig/implant Vision prescriptions Treatments normal bpm number colour food prefs 17
Phân tích yêu cầu phần mềm Đây là mô hình cho vấn đề gì ? 18
Phân tích yêu cầu phần mềm Kết luận Mô hình hóa đóng vai trò trọng tâm trong RE Cho phép chúng ta khảo sát vấn đề một cách hệ thống Cho phép chúng ta kiểm tra sự hiểu biết của mình Co nhiều lựa chọn ký pháp cho mô hình Trong course này, chúng ta sẽ dùng các dạng ký pháp của UML Tất cả các mô hình thường thiếu chính xác Sử dụng các mô hình được hiệu chỉnh liên tục nhưng có thể biết khi nào ngừng việc hoàn chỉnh mô hình Mỗi mô hình được tạo ra cho một mục đích riêng Mục đích thường không được biểu diễn trong mô hình Vì thế nên mỗi mô hình đều cần có một sự giải thích 19 .
Phân tích yêu cầu phần mềm Lecture 07: Mô hình quan hệ thực thể (Entity Relationship Modelling) Mô hình quan hệ - thực thể (Entity-Relationship Model) Thực thể (Entities) Quan hệ (Relationships) Thuộc tính (Attributes) Các ràng buộc trên thể hiện Bản số (Cardinalities) Khóa định dạng (Identifiers) Tổng quát hóa (Generalization) 1
Phân tích yêu cầu phần mềm Mô hình quan hệ thực thể Lược đồ quan hệ - thực thể (Entity-Relationship Schema) Mô tả các yêu cầu dữ liệu cho một hệ thống thông tin mới Dùng ký hiệu đồ họa một cách trực tiếp, dễ hiểu Chuyển thành lược đồ quan hệ cho thiết kế cơ sở dữ liệu một cách nhanh chóng Nhưng trừu tượng hơn lược đồ quan hệ E.g. có thể hiển thị một thực thể mà không biết các đặc tính của nó. Các thực thể (Entities): Lớp các đối tượng với các đặc tính chung và một phạm vi tồn tại E.g. Thành phố, Bộ môn, Nhân viên, Mua và Bán Một thể hiện của một thực thể là một đối tượng trong lớp được biểu diễn bởi thực thể E.g. Cần Thơ, Đà Lạt là các ví dụ thể hiện của thực thể Thành phố Các quan hệ (Relationships): Các nối kết logic giữa hai hoặc nhiều thực thể. E.g. Cư trú là một quan hệ có thể tồn tại giữa Thành phố và Nhân viên Một thể hiện của một quan hệ là một thể hiện n-tuple của thực thể E.g. bộ (Nam, Cần Thơ), là một thể hiện trong quan hệ Cư trú. 2
Phân tích yêu cầu phần mềm Các ví dụ Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 3
Phân tích yêu cầu phần mềm Ví dụ thể hiện cho liên kết Exam Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Exam 4
Phân tích yêu cầu phần mềm Ý nghĩa thực sự của một sơ đồ ER? Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Course Meets Room Course và Room là các thực thể. Thể hiện của chúng là courses cụ thể (eg CT324) và rooms (eg 202/C1) Meets là một quan hệ. Các thể hiện của nó mô tả các buổi học cụ thể. Mỗi buổi học có chính xác một kết hợp giữa course và room. Các thể hiện của Meets Các thể hiện của Course Các thể hiện của Rooms . 5
Phân tích yêu cầu phần mềm Quan hệ đệ quy (Recursive) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Một thực thể có thể có quan hệ với chính nó E.g Thực thể Nhân viên (Empoyee) có quan hệ đồng nghiệp (colleague) với chính nó. Nếu quan hệ không đối xứng Cần định nghĩa hai vai trò mà mỗi thực thể đóng trong quan hệ. E.g Thực thể Quốc vương (Sovereign) có quan hệ nối ngôi (Succession) với chính nó, nhưng cần định nghĩa hai vai trò tiền nhiệm (Predecessor) và kế nhiệm (successor) khác nhau cho quan hệ. 6
Phân tích yêu cầu phần mềm Quan hệ liên kết ba (Ternary) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 7
Phân tích yêu cầu phần mềm Quan hệ AND/XOR “Mỗi đơn hàng (Order) hoặc chứa các món hàng (contains a part) hoặc yêu cầu dịch vụ (requests a service), nhưng không phải cả hai” “Đối với một đơn hàng (Order), bất cứ khi nào phát sinh một hóa đơn (invoice) thì cũng sẽ có một đợt chuyển hàng (shipment) được thực hiện và cả hai đều là bắt buộc” 8
Phân tích yêu cầu phần mềm Thuộc tính Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Liên kết với mỗi thể hiện của một thực thể (hoặc một quan hệ) là một giá trị thuộc về một tập hợp (phạm vi của thuộc tính - attribute). Phạm vi xác định các giá trị có thể nhận được cho thuộc tính. 9
Phân tích yêu cầu phần mềm Thuộc tính hợp thành (Composite Attributes) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Nhóm thuộc tính của cùng thực thể hoặc quan hệ có ý nghĩa liên kết hoặc cách dùng gần nhau. 10
Phân tích yêu cầu phần mềm Lược đồ với các thuộc tính Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 11
Phân tích yêu cầu phần mềm Bản số (Cardinalities) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Bản số ràng buộc sự tham gia vào quan hệ. Là số tối đa và số tối thiểu của các thể hiện quan hệ mà trong đó một thể hiện của thực thể có thể tham gia vào. E.g. Bản số là mọi cặp số nguyên không âm (a,b) a ≤ b. Nếu a=0 thì sự tham gia của thực thể vào quan hệ là tùy ý Nếu a=1 thì sự tham gia của thực thể vào quan hệ là bắt buộc. Nếu b=1 thì mỗi thể hiện của thực thể hầu như là liên kết với một thể hiện của quan hệ. Nếu b=“N” thì mỗi thể hiện của thực thể liên kết với một số tùy ý thể hiện của quan hệ. 12
Phân tích yêu cầu phần mềm Ví dụ về bản số Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 “Mỗi course có 2 buổi học trong tuần” (2,2) (0,40) Course Meets Room “Một ngày “Một phòng có thể có (0,N) có thể có đến một số không 40 buổi học giới hạn các hàng tuần” buổi học” Day 13
Phân tích yêu cầu phần mềm Dẫn chứng về sơ đồ ER Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Một sơ đồ ER mô tả hiện trạng có thể có trong thế giới thực bằng việc mô hình hóa. (2,2) (0,40) Course Meets Room Dẫn chứng không hợp lệ 14
Phân tích yêu cầu phần mềm Bản số của thuộc tính Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Các bản số thuộc tính đa giá trị Các thuộc tính cũng có thể thì rất khó giải quyết có bản số Để mô tả giá trị tối thiểu và tối đa Việc mô hình hóa thường sẽ tốt hơn bằng của thuộc tính liên kết với mỗi cách thêm vào thực thể các liên kết thể hiện của một thực thể hoặc với quan hệ 1- nhiều (hoặc nhiều-nhiều). một liên kết. Bản số mặc định là (1,1) Các thuộc tính tùy chọn có bản số là (0,1) 15
Phân tích yêu cầu phần mềm Khóa xác định (Identifiers) (“keys”) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Thế nào là thể hiện dùng xác định duy nhất một thực thể? Một khóa xác định có thể được tạo thành bởi một hoặc nhiều thuộc tính của chính thực thể. Nếu các thuộc tính của một thực thể không đủ đáp ứng để xác định các thể hiện một cách rõ ràng, các thực thể khác có thể chứa trong sự xác định. Một quan hệ được xác định bởi khóa xác định của tất cả các thực thể có quan hệ E.g. khóa xác định cho quan hệ (Person-) Owns(-Car) là một kết hợp của khóa xác định Person và Car. khóa nội, một thuộc tính khóa nội, nhiều thuộc tính khóa ngoại, nhiều thuộc tính 16
Phân tích yêu cầu phần mềm Các lưu ý về Khóa xác định Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Khóa và bản số: Một khóa xác định có thể bao gồm một hoặc nhiều thuộc tính, với điều kiện mỗi trong chúng có bản số (1,1) Một khóa ngoại (external identifier) có thể chứa một hoặc nhiều thực thể, với điều kiện mỗi trong chúng là một thành viên của quan hệ mà trong đó thực thể tham gia được xác định với bản số (1,1) Các chu trình Một khóa ngoại có thể bao gồm một thực thể mà nó luân phiên gọi một khóa ngoại khác, chừng nào mà các vòng lặp không sinh nữa; Đa khóa Mỗi thực thể phải có ít nhất một khóa xác định (khóa nội hoặc khóa ngoại) Một thực thể có thể có nhiều hơn một khóa xác định Chú ý : nếu có nhiều hơn một khóa xác định, thì các thuộc tính và thực thể chứa trong một sự xác định có thể là tùy chọn (bản số tối thiểu bằng 0). 17
Phân tích yêu cầu phần mềm Lược đồ với các khóa Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 18
Phân tích yêu cầu phần mềm Hiểu rõ việc chọn khóa 19
Phân tích yêu cầu phần mềm Khái quát hóa (Generalizations) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Chỉ ra quan hệ “là-một” (“is-a”) giữa các thực thể Khái quát hóa: Mỗi thể hiện của một thực thể con cũng là một thể hiện của thực thể cha Mỗi đặc tính của thực thể cha (thuộc tính, khóa xác định, quan hệ hoặc khái quát hóa khác) cũng là một đặc tính của thực thể con. 20
Phân tích yêu cầu phần mềm Các dạng khái quát hóa Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 Khái quát hóa hoàn toàn (Total generalizations): Mỗi thể hiện của thực thể cha là một thể hiện của một trong số các con của nó. Chỉ ra bằng dạng mũi tên tô đậm Khái quát hóa loại trừ (Exclusive generalizations): Mỗi thể hiện của thực thể cha có ít nhất một thể hiện của một trong số các con của nó. Chỉ ra bằng dạng mũi tên rỗng 21
Phân tích yêu cầu phần mềm Mô hình E-R Meta-Model (như sơ đồ E-R) Adapted from chapter 5 of Atzeni et al, “Database Systems” McGraw Hill, 1999 22
Phân tích yêu cầu phần mềm Lecture 08: Mô hình hướng đối tượng Phân tích hướng đối tượng Phân tích cơ sở Định nghĩa lớp (Classes) Các thuộc tính (Attributes) và phương thức (Operations) Biểu đồ lớp UML (Class Diagrams) Quan hệ kết hợp (Associations) Tính bội/Bản số (Multiplicity) Quan hệ tập hợp (Aggregation) Quan hệ hợp thành (Composition) Quan hệ thừa kế (Generalization) . 1
Phân tích yêu cầu phần mềm Phân tích hướng đối tượng Background Mô hình yêu cầu trong thuật ngữ của các đối tượng và dịch vụ mà chúng cung cấp Phát sinh thiết kế hướng đối tượng Được áp dụng để mô hình hóa lĩnh vực ứng dụng hơn là chương trình Động cơ OO (được kiến nghị) là quá ‘tự nhiên’ Khi triển khai một hệ thống, các chức năng thực thi của nó cần được thay đổi thường hơn là các đối tượng đang hoạt động trên nó một mô hình dựa trên các đối tượng (hơn là các chức năng) sẽ rất ổn định vì thế, có kiến nghị rằng các thiết kế hướng đối tượng có thể sẽ còn tiếp tục được duy trì OO nhấn mạnh sự quan trọng của giao tiếp giữa các đối tượng một cách rõ ràng. đã được so sánh với sự mơ hồ của các quan hệ dòng dữ liệu NOTE: Áp dụng OO cho kỹ nghệ yêu cầu vì nó là một công cụ mô hình hóa. Song, chúng ta đang mô hình hóa các thực thể trong lĩnh vực chứ không phải thiết kế hệ thống mới. 2
Phân tích yêu cầu phần mềm UML là gì ? UML (Unified Modeling Language) Một công nghệ chuẩn cho việc mô hình hóa phần mềm hướng đối tượng Là kết quả của sự thống nhất hệ thống ký hiệu của 3 phương pháp hướng đối tượng tiêu biểu : OMT (James Rumbaugh) - Object Modeling Technique OOSE (Ivar Jacobson) - Object-Oriented Software Enginering Booch91 (Grady Booch) Được hỗ trợ bởi một số CASE tools: Rational ROSE TogetherJ Bạn có thể mô hình 80% của hầu hết vấn đề bằng cách dùng chỉ khoảng 20% UML Chúng ta học 20% đó 3
Phân tích yêu cầu phần mềm 4
Phân tích yêu cầu phần mềm Gần như mọi thứ đều có thể là object Source: Adapted from Pressman, 1994, p242 Các thực thể bên ngoài Các thành phần tổ chức tương tác với hệ thống đang được có liên quan tới ứng dụng mô hình hóa E.g. phân chia, nhóm, đội, etc. E.g. people, devices, other systems Nơi chốn Các vật thể thiết lập ngữ cảnh của vấn đề đang là những phần của lĩnh vực đang được mô hình hóa được mô hình hóa E.g. nhà máy, bến tàu, etc. E.g. báo cáo, màn hình, tín hiệu, etc. Các cấu trúc Việc xảy ra hoặc sự kiện định nghĩa một lớp hay nhóm các xuất hiện trong ngữ cảnh của objects hệ thống E.g. bộ cảm biến, bộ bánh xe, máy tính, E.g. chuyển giao tài nguyên, hành etc. động kiểm soát, etc. Một số thứ không thể là objects: Vai diễn các thủ tục (e.g. in ấn, đảo ngược, etc) được đóng bởi những người đang các thuộc tính (e.g. màu xanh, 50Mb, etc) tương tác với hệ thống 5
Phân tích yêu cầu phần mềm Lớp (classes) là gì ? Một lớp mô tả một nhóm các đối tượng (objects) với : Các đặc tính tương tự (thuộc tính - attributes), Cùng hành vi ứng xử (phương thức - operations), Quan hệ như nhau đối với các object khác. Và có chung ngữ nghĩa (“semantics”). Ví dụ Nhân viên (employee): có 1 tên (name), mã số nhân viên (employee#) và bộ phận trực thuộc (department); một nhân viên thì có thể được thuê (hired), và bị sa thải (fired); mỗi nhân viên làm việc trong một hay nhiều dự án. :employee Name (mandatory) Attributes name (optional) employee# department hire() Operations fire() assignproject() (optional) 6
Phân tích yêu cầu phần mềm Tìm lớp (Classes) Tìm lớp từ dữ liệu nguồn: Tìm các danh từ và cụm danh từ trong mô tả vấn đề của các đối tác chứa trong mô hình nếu họ giải thích một cách tự nhiên hoặc cấu trúc thông tin trong ứng dụng. Tìm lớp từ các nguồn khác: Xem xét các thông tin nền tảng; Những người dùng và các đối tác khác; Các mẫu phân tích; Sẽ rất tốt nếu ban đầu có nhiều ứng viên cho lớp Bạn có thể bỏ chúng ngay sau đó nếu chúng hóa ra không hữu ích Quyết định dứt khoát loại bỏ các lớp thì tốt hơn là chỉ suy nghĩ về điều đó. 7
Phân tích yêu cầu phần mềm Chọn lựa lớp Loại bỏ lớp là một khái niệm khi : Không nằm trong phạm vi phân tích; Tham chiếu đến toàn bộ hệ thống; Trùng với các lớp khác; Có quá nhiều mơ hồ hoặc quá chi tiết e.g. có quá nhiều hoặc quá ít thể hiện (instances) Tiêu chuẩn của Coad & Yourdon’s: Giữ lại thông tin : Hệ thống sẽ còn nhớ thông tin về các lớp này của objects? Các dịch vụ cần thiết : Objects trong lớp này có nhận biết các phương thức làm thay đổi giá trị các thuộc tính của chúng ? Đa thuộc tính (Multiple Atributes): Nếu lớp chỉ có duy nhất một thuộc tính, nó có thể đại diện tốt hơn một thuộc tính của lớp khác Thuộc tính chung (Common Attributes): Lớp có chứa các thuộc tính mà có thể chia sẻ với tất cả các thể hiện của đối tượng đó không ? Phương thức chung (Common Operations): Lớp có chứa các phương thức mà có thể chia sẻ với tất cả các thể hiện của đối tượng đó không ? Các thực thể bên ngoài phát sinh hoặc thu nhận các thông tin chủ yếu cho hệ thống nên được đặt thành lớp. 8
Phân tích yêu cầu phần mềm Objects vs. Classes Các thể hiện của một lớp được gọi là đối tượng Một đối tượng được trình bày như sau: Nam : Employee name: Nam Employee #: 234609234 Department: Marketing Hai đối tượng khác nhau có thể có các giá trị thuộc tính giống nhau (như hai người với tên và địa chỉ giống nhau) Đối tượng có quan hệ kết hợp (associations) với đối tượng khác E.g. Nam :employee thì có quan hệ kết hợp với đối tượng Mekong1000 :project Nhưng chúng ta sẽ tìm hiểu quan hệ này ở cấp độ lớp ! Chú ý : Phải bảo đảm rằng thuộc tính thì kết hợp với đúng lớp E.g. bạn không muốn cả managerName và manager# đều là thuộc tính của Project !? 9
Quan hệ kết hợp (Associations) Đối tượng không tồn tại độc lập với những cái khác Một quan hệ (relationship) diễn tả một sự kết hợp trong số những cái khác. Trong UML, có nhiều kiểu quan hệ khác nhau: Quan hệ kết hợp (Association) Quan hệ tập hợp (Aggregation) và Quan hệ hợp thành (Composition) Quan hệ thừa kế (Generalization) Quan hệ phụ thuộc (Dependency) Quan hệ hiện thực hóa (Realization) Chú ý : Hai quan hệ cuối không hữu ích trong quá trình phân tích yêu cầu Sơ đồ lớp chỉ rõ các lớp và mối quan hệ giữa chúng 10
Phân tích yêu cầu phần mềm Bản số (Multiplicity) của Quan hệ kết hợp Hỏi các câu hỏi về quan hệ kết hợp: Một cuộc vận động (campaign) có thể tồn tại mà không có thành viên trong Ban quản lý hay không ? Nếu có, thì quan hệ kết hợp này sẽ là một tùy chọn trong Ban quản lý - 0 hoặc nhiều (0 *) Nếu không, thì nó là tùy chọn – 1 hoặc nhiều (1 *) Nếu nó cần được quản lý bởi 1 và chỉ 1 thành viên trong Ban – chính xác 1 (1) Một câu hỏi khác của quan hệ kết hợp? Mỗi thành viên trong Ban quản lý có cần phải quản lý chính xác chỉ một cuộc vận động không? Không. Vì thế bản số chính xác là 0 hoặc nhiều (0 *) Một số ví dụ biểu diễn của bản số: Tùy chọn (0 hoặc 1) 0 1 Chính xác 1 1 = 1 1 0 hoặc nhiều 0 * = * 1 hoặc nhiều 1 * Một vùng giá trị 2 6 11
Phân tích yêu cầu phần mềm Quan hệ kết hợp lớp Bản số Bản số Một client có Một staffmember có chính xác 1 staffmember 0 hoặc nhiều clients trong như là người liên hệ Tên Danh sách khách hàng của quan hệ (ClientList) :Client :StaffMember companyAddress staffName 1 liên lạc với 0 * companyEmail staff# companyFax staffStartDate Người ClientList companyName liên hệ companyTelephone Hướng Quan hệ kết hợp “liên lạc với” cần đọc Vai trò theo hướng này Vai trò của Staffmember Vai trò trong quan hệ kết hợp này Vai trò của Client là người liên hệ trong quan hệ kết hợp này như là một trong ClientList 12
Phân tích yêu cầu phần mềm Các ví dụ khác 13
Phân tích yêu cầu phần mềm Các lớp quan hệ kết hợp Đôi khi có quan hệ kết hợp của một lớp với chính quan hệ bởi vì chúng ta cần giữ lại thông tin về quan hệ kết hợp và những thông tin này thì không còn tồn tại trong các lớp vào cuối của quan hệ kết hợp E.g. “Chủ quyền” (title) là một đối tượng dùng mô tả thông tin về mối quan hệ giữa người chủ và chiếc xe của cô ấy :person :car Name VIN(vehicle Id Number) 0 * 1 owns Address YearMade DriversLicenceNumber owner Mileage PermittedVehicles :title yearbought initialMileage PricePaid LicencePlate# 14
Phân tích yêu cầu phần mềm Quan hệ tập hợp và Quan hệ hợp thành Quan hệ tập hợp (Aggregation) Đây là một quan hệ “Có một (Has-a)” hay “Toàn thể/Bộ phận (Whole/part)” Quan hệ hợp thành (Composition) Là dạng mạnh hơn của quan hệ tập hợp dùng chứng tỏ quyền sở hữu: nếu đối tượng toàn thể bị hủy, đối tượng bộ phận cũng bị hủy theo. đối tượng toàn thể chịu trách nhiệm về sự sắp xếp các thành phần của nó. 1 :Engine composition :Locomotive 1 * 1 0 1 :Car :Train 0 1 :Person 0 * 0 1 driver 1 passengers aggregation 15
Phân tích yêu cầu phần mềm Quan hệ kế thừa (Generalization) Chú ý : Các lớp con (subclasses) sẽ kế thừa các thuộc tính (attributes), quan hệ (associations) và phương thức (operations) từ lớp cha (superclass) Một lớp con có thể bỏ qua một khía cạnh kế thừa e.g. AdminStaff & CreativeStaff có các phương pháp khác nhau cho cách tính điểm thưởng Các lớp cha có thể khai báo {abstract}, nghĩa là chúng không có thể hiện (instances) Chứng tỏ rằng các lớp con bao phủ tất cả e.g. không có bộ phận nào khác hơn AdminStaff và CreativeStaff 16
Phân tích yêu cầu phần mềm Nói thêm về Quan hệ kế thừa Ích lợi của quan hệ kế thừa Có thể dễ dàng thêm vào các lớp con mới khi có thay đổi tổ chức Tìm kiếm quan hệ kế thừa theo 2 cách: Trên xuống (Top Down) Bạn có một lớp, và việc khảo sát nó có thể được chia nhỏ ra Hoặc bạn có một quan hệ kết hợp diễn tả một “loại của (kind of)” quan hệ E.g. “Hầu hết công việc của chúng ta là quảng cáo cho báo chí – các tờ báo và tạp chí, cũng như là trên các pano quảng cáo và videos” Dưới lên (Bottom Up) Bạn cần lưu ý sự tương tự giữa các lớp mà bạn định nghĩa E.g. “Chúng ta có nhiều sách và dĩa CD trong Thư viện, nhưng tất cả chúng đã được ghi số phân loại theo hệ thống Dewey, và tất cả đều có thể được cho mượn và dặn trước” Nhưng đừng kế thừa chỉ những ích lợi của nó Bảo đảm rằng mọi thứ trong lớp cha được áp dụng vào lớp con Bảo đảm rằng lớp cha thì hữu ích khi một lớp trong nó được sở hữu hoàn toàn Đừng thêm các lớp con hoặc lớp cha không có liên quan vào phân tích của bạn 17
Phân tích yêu cầu phần mềm Sơ đồ lớp :eye Colour Class name aggregation 0 2 Diameter Correction multiplicities :patient 0 1 :kidney Name attributes Operational? Date of Birth 0 1 Height operation Weight 0 1 1 2 :heart generalization Normal bpm 1 Blood type :In-patient :Out-patient Room Last visit :organ Bed next visit Natural/artif. Physician physician Orig/implant donor . 18
Phân tích yêu cầu phần mềm Kết luận Hiểu rõ các đối tượng trong lĩnh vực ứng dụng Định nghĩa tất cả các đối tượng mà đối tác nêu ra Quyết định đối tượng nào quan trọng cho thiết kế của bạn Sơ đồ lớp thiết kế tốt khi: Có quan hệ trực quan giữa các đối tượng trong lĩnh vực Khảo sát các quy tắc nghiệp vụ và giả thiết thông qua bản số Đặc tả cấu trúc của thông tin để (cuối cùng) lưu trữ OO là một cách thức tốt để khảo sát các chi tiết của vấn đề Tránh những chấp vá tự nhiên của cấu trúc phân tích Cung cấp một phương thức chặt chẽ để hiểu rõ thực tế Nhưng cẩn thận Nó lôi cuốn để thiết kế hơn là phân tích vấn đề Trong RE, sơ đồ lớp KHÔNG phản ánh các lớp chương trình (e.g. Java) Đối với các nhà phân tích, dùng các lược đồ UML như là sự phác họa chứ không phải bản thiết kế Tuy nhiên vẫn có thể trở thành bản thiết kế khi được dùng trong một sự đặc tả 19
Kết luận: UML vs ERD Sơ đồ ER tương tự như sơ đồ lớp trong UML Sơ đồ lớp nhấn mạnh thứ bậc lớp (class hierarchies) và các phương thức (operaions) Sơ đồ R nhấn mạnh các mối quan hệ (relationships) và khóa xác định (identity) Nhưng chỉ cần một cho việc phân tích mọi vấn đề cho trước ! ER cung cấp nhiều ký hiệu hơn cho khái niệm cơ sở dữ liệu: Sơ đồ ER cho phép các quan hệ đa chiều (N-ary relationships) (Sơ đồ lớp UML chỉ cho phép quan hệ hai chiều ( binary relationships)) Sơ đồ ER cho phép các thuộc tính đa giá trị. Sơ đồ ER cho phép đặc tả các khóa xác định. Sự lựa chọn tùy thuộc vào mục tiêu cài đặt: Sơ đồ lớp UML cho kiến trúc hướng đối tượng (Object Oriented Architecture) Sơ đồ ER cho CSDL quan hệ (Relational Databases) Nhưng điều này chỉ quan trọng khi bạn dùng chúng cho bản thiết kế Đối với bản phác thảo, sự tương tự với ký hiệu thì quan trọng hơn 20
Phân tích yêu cầu phần mềm Lecture 09: Mô hình hóa tương tác hệ thống Tương tác với hệ thống mới Con người sẽ tương tác với hệ thống như thế nào? Khi nào/Vì sao họ tương tác với hệ thống? Use Cases Giới thiệu mô hình hoạt vụ (use cases) Định nghĩa tác nhân (actors) Định nghĩa tình huống (cases) Các đặc tính mở rộng Biểu đồ tuần tự (Sequence Diagrams) Trình tự thời gian của các sự kiện bao gồm trong hoạt vụ (use case) 1
Phân tích yêu cầu phần mềm Mô tả về sự chuyển dịch Hệ thống Use case sẽ cung cấp những chức năng gì ? Con người sẽ tương tác với nó như thế nào? Mô tả các chức năng từ hướng nhìn của người dùng UML Use Cases Dùng để chỉ: Các chức năng (functions) được cung cấp bởi hệ thống Tác nhân (actors) nào sẽ dùng những chức năng này Mỗi Use Case là: Một mẫu ứng xử mà hệ thống mới được yêu cầu biểu diễn Một trình tự của các hành động có liên quan thực thi bởi một tác nhân và hệ thống thông qua việc đối thoại. Một tác nhân (actor) là : Mọi thứ cần tương tác với hệ thống: Một người (a person); Một vai trò (role) mà những người khác nhau có thể đóng; Một hệ thống khác (bên ngoài) Ranh giới hệ thống (System Boundary) biểu diễn : Như một cái hộp chứa tất cả các use case có liên quan (vẽ dưới dạng khung chữ nhật) Lưu ý : các tác nhân nằm bên ngoài ranh giới hệ thống. Đường nối kết (Communication association) : nối giữa tác nhân và các usecase. 2
Phân tích yêu cầu phần mềm Sơ đồ hoạt vụ (Use Case Diagrams) Nắm bắt mối quan hệ giữa các nhân tố và Use Cases Change a client contact Campaign (Thay đổi quan hệ khách hàng) Staff contact Manager Add a new client (Nhân viên quan hệ khách hàng) (Nhà quản lý (Thêm khách hàng mới) cuộc vận động) Record client payment Accountant (Nhận tiền trả của khách hàng) (Kế toán) 3
Phân tích yêu cầu phần mềm Các ký hiệu trong Sơ đồ hoạt vụ Use case Change a client contact Staff contact Actor Communication association System boundary 4
Phân tích yêu cầu phần mềm Ví dụ Xem danh mục hàng hóa Đăng nhập tài khoản Đặt đơn hàng Khách hàng Chuyển Người giao hàng đơn hàng Kiểm tra đơn hàng 5
Phân tích yêu cầu phần mềm Quan hệ > và > > : khi một uses case thêm hành vi ứng xử vào base case Dùng để mô hình một phần của use case mà người dùng có thể nhìn thấy như hành vi tùy chọn của hệ thống ; Cũng mô hình một sub-case riêng lẻ mà nó chỉ thực thi trong một số điều kiện. >: khi một use case gọi đến một cái khác (giống như gọi thủ tục) Dùng để tránh việc mô tả cùng một dòng sự kiện một vài lần Đặt hành vi chung trong một use case của cái sở hữu nó. Thêm > T• khóa Thêm sách > ••ng nh•p h• th•ng 6
Phân tích yêu cầu phần mềm Mẫu use cases cho một chiếc xe Th• máy Ng••i lái xe Ng••i bán x•ng > > Đổ xăng Kiểm tra Sửa xe Lái xe xăng > > > Sửa xe trên Khởi đường động 7
Phân tích yêu cầu phần mềm Ví dụ sắp xếp lịch họp 8
Phân tích yêu cầu phần mềm Quan hệ kế thừa Lớp tác nhân (Actor classes) Đôi khi rất hữu ích để định nghĩa các lớp của tác nhân E.g. khi một vài tác nhân cùng thuộc về cùng một lớp Một số use cases thì cần bởi tất cả các thành viên trong lớp Các use cases khác thì chỉ cần bởi một số thành viên trong lớp Các tác nhân kế thừa use cases từ lớp Lớp Use Case (Use Case classes) Đôi khi hữu ích để định nghĩa một quan hệ kế thừa của một số use cae Quan hệ kế thừa: Đọc là: “là một thành viên của” hoặc chỉ “là một” 9
Phân tích yêu cầu phần mềm Nhận biết các tác nhân (Actors)) Hỏi những câu hỏi sau: Ai sẽ là người dùng chính của hệ thống? (tác nhân chính) Ai sẽ cần sự hỗ trợ từ hệ thống để làm các công việc hàng ngày của họ? Ai hoặc điều gì sẽ quan tâm đến những kết quả mà hệ thống đưa ra ? Ai sẽ bảo trì, quản lý, điều hành hoạt động của hệ thống ? (tác nhân phụ) Hệ thống cần các thiết bị phần cứng nào ? Hệ thống cần tương tác với những hệ thống nào khác ? Tìm kiếm: Những người trực tiếp sử dụng hệ thống Và những người dùng khác – những người cần các dịch vụ từ hệ thống Có 3 loại Actor chính: Người dùng. Ví dụ: sinh viên, nhân viên, khách hàng Hệ thống khác. Sự kiện thời gian. Ví dụ: Kết thúc tháng, đến hạn 10
Phân tích yêu cầu phần mềm Tìm kiếm Use Cases Đối với mỗi tác nhân, hỏi các câu hỏi sau: Những chức năng nào mà tác nhân đòi hỏi từ hệ thống ? Tác nhân nào cần làm ? Tác nhân có cần đọc (read), tạo ra (create), phá hủy (destroy), sửa đổi (modify) hoặc lưu trữ (store) một số dạng thông tin trong hệ thống ? Tác nhân có phải thông báo về các sự kiện trong hệ thống ? Tác nhân thông báo những gì với hệ thống ? Các sự kiện gì thì cần thiết trong môi trường chức năng của hệ thống? Hoạt động thông thường của tác nhân thì quá đơn giản hoặc quá hiệu quả đối với các chức năng mới được cung cấp bởi hệ thống ? 11
Phân tích yêu cầu phần mềm Lập tài liệu Use Cases Cho mỗi use case: Chuẩn bị tài liệu “luồng sự kiện” (“flow of events”), được viết từ hướng nhìn của một tác nhân. Mô tả chi tiết những cái mà hệ thống cần phải làm chứ không chỉ ra hệ thống sẽ làm nó như thế nào? Các nội dung đặc trưng : Use case bắt đầu và kết thúc như thế nào; Tiến trình bình thường của các sự kiện; Tiến trình thay phiên của các sự kiện; Tiến trình ngoại lệ của các sự kiện; Kiểu tài liệu: Chọn lựa cách hiển thị use case: Biểu đồ hoạt động (Activity Diagrams) – tốt cho tiến trình công việc Biểu đồ hợp tác (Collaboration Diagrams) – tốt cho thiết kế cấp cao Biểu đồ trình tự (Sequence Diagrams) – tốt cho thiết kế chi tiết 12
Phân tích yêu cầu phần mềm Mẫu tài liệu Use Cases Có thể dùng theo mẫu đơn giản như sau: • X. Luồng sự kiện cho Use case ABC • X1. Điều kiện bắt đầu: danh sách những điều kiện phải thỏa mãn trước khi Use case được thực hiện. Ví dụ như: một Use case khác phải thực hiện trước khi Use case này được thực hiện hay người dùng phải có đủ quyền để thực hiện Use case này. Không nhất thiết mọi Use case đều phải có điều kiện bắt đầu. • X2. Luồng chính: mô tả những bước chính sẽ xảy ra khi thực hiện Use case. • X3. Các luồng phụ (luồng con). • X4. Các luồng rẽ nhánh. Trong đó X là số thự tự của Use case trong hệ thống 13
Ví dụ : Luồng sự kiện mô tả Use Case Luồng sự kiện mô tả Use case cho hệ thống rút tiền tự động như sau: 1.1 Điều kiện bắt đầu. 1.2 Luồng chính: 1.2.1 Người dùng đưa thẻ vào máy. 1.2.2. Máy hiển thông báo chào mừng và yêu cầu nhập mã số 1.2.3 Người dùng nhập mã số 1.2.4 Máy xác nhận mã số đúng. Nếu nhập sai mã số, luồng rẽ nhánh E-1 được thực hiện. 1.2.5 Máy hiện ra ba lựa chọn: Rút tiền: luồng con A-1 Chuyển tiền: luồng con A-2 Thêm tiền vào tài khoản: luồng con A-3 1.2.6 Người dùng chọn rút tiền 1.3. Luồng con: 1.3.1 Luồng con A-1: 1.3.1.1 Máy hỏi số lượng tiền cần rút 1.3.1.2 Người dùng nhập số tiền cần rút : Máy kiểm tra trong tài khoản có đủ tiền không. Nếu không đủ luồng rẽ nhánh E-2 được thực hiện 1.4. Luồng rẽ nhánh: 1.4.1 E-1: Người dùng nhập sai mã số :Máy thông báo là người dùng đã nhập sai mã số yêu cầu người dùng nhập lại hoặc hủy bỏ giao dịch. 1.4.2 E-2: Không đủ tiền trong tài khoản 14