Chương 2

1. Chương 2 PHÁT TRIỂN YÊU CẦU PHẦN MỀM Xây dựng tầm nhìn và phạm vi dự án Establishing the Product Vision and Project Scope BM HTTT - Khoa CNTT - HUI

2. Nội dung • Phân biệt goal và requirement • Khái niệm Product Vision và Project Scope • Xác định boundary bằng phương pháp soft system • Xác định yêu cầu chức năng bằng phương pháp hard system • Lược đồ ngữ cảnh BM HTTT - Khoa CNTT - HUI

3. Goal và requirement • Goals là cái mà stakeholders muốn thực thi. • Goals có thể có nhiều mức độ khác nhau: • Mức cao nhất (highest level): chính là mission statements and objectives. (Có thể dùng Mission = vision = objective) • Mục tiêu lâu dài thì được gọi là policies. • Mức thấp nhất (lowest level): gọi là chức năng cơ bản (individual functions) BM HTTT - Khoa CNTT - HUI

4. Goal và requirement • Mục tiêu chi tiết sẽ trở thành requirement khi: • Có thể kiểm chứng được (fully verifiable) • Được xếp loại ưu tiên trong 1 dự án cụ thể BM HTTT - Khoa CNTT - HUI

5. Goal và requirement BM HTTT - Khoa CNTT - HUI

6. Tầm quan trọng của goal • Projects that lack clear goals struggle constantly to understand what their real requirements are, and are unlikely to discover them. • Projects without goals are vulnerable to pressure to add requirements, even if they don’t have the time or money for more work. BM HTTT - Khoa CNTT - HUI

7. Một số ví dụ về goal Goals for a Spacecraft Goals for a Restaurant Tram Goals and Trade-offs Assignment 8 Assignment 9 Assignment 10 BM HTTT - Khoa CNTT - HUI

8. Ví dụ về xung đột yêu cầu nghiệp vụ • Cần xây dựng phần mềm quản lý Kiosk: • Mục tiêu nghiệp vụ của người quản lý kiosk: • Generating revenue by leasing or selling the kiosk to the retailer • Selling consumables through the kiosk to the customer • Attracting customers to the brand • Making a wide variety of products available BM HTTT - Khoa CNTT - HUI

9. Ví dụ về xung đột yêu cầu nghiệp vụ • Mục tiêu nghiệp vụ của người bán lẻ (retailer): • Maximizing revenue from the available floor space • Attracting more customers to the store • Increasing sales volume and profit margins if the kiosk replaces manual operations BM HTTT - Khoa CNTT - HUI

10. Ví dụ về xung đột yêu cầu nghiệp vụ Người quản lý muốn tạo 1 huớng mới năng động, kỹ thuật cao cho khách hàng, còn người bán lẻ thì muốn 1 hệ thống chuyển giao đơn giản, còn khách hàng thì chỉ thích thuận tiện và nhiều tính năng. Ba nhóm người với các mục tiêu khác nhau. Người tài trợ dự án cần giải quyết các xung đột (conflict) trước khi analyst có thể phân tích các yêu cầu phần mềm. BM HTTT - Khoa CNTT - HUI

11. Finding Solutions to Goal Conflicts Xung đột mục tiêu có thể dự đoán được sau khi phân tích mục tiêu và stakeholder nhưng chỉ có thể giải quyết được khi đưa ra được thiết kế phù hợp (candidate design). Trong một số trường hợp chỉ cần phác thảo thiết kế là đã xác định được phương pháp có khả thi không. Một vài trường hợp, không thể nào tìm ra được phương pháp khả thi BM HTTT - Khoa CNTT - HUI

12. Phân biệt yêu cầu nghiệp vụ và yêu cầu phần mềm Business requirements là các phát biểu về nghiệp vụ Software requirements (functional requirements) xác định cái mà hệ thống sẽ làm. Thường các yêu cầu phần mềm được lưu trữ cho các hệ thống phần mềm hiện có hoặc tương lai và nên đồng bộ với yêu cầu nghiệp vụ. BM HTTT - Khoa CNTT - HUI

13. Phân biệt yêu cầu nghiệp vụ và yêu cầu phần mềm Một số yêu cầu nghiệp vụ có thể tự động hóa: máy tính có thể làm mọi việc nhanh hơn, hiệu quả và đáng tin cậy hơn con người đối với hầu hết các nghiệp vụ thường kỳ (routine), như tính lương, quản lý điểm… BM HTTT - Khoa CNTT - HUI

14. Phân biệt yêu cầu nghiệp vụ và yêu cầu phần mềm Một số yêu cầu nghiệp vụ phải thực hiện bằng tay: ví dụ đánh giá tổn hại nhân thọ có thể tùy vào chủ quan của nhân viên bảo hiểm. Không phải tất cả các yêu cầu nghiệp vụ đều có thể số hóa; một số nghiệp vụ có thể cùng đồng hành với công nghệ máy tính. Ví dụ, máy tính không thể đánh giá rủi ro được nhưng có thề lưu trữ các đánh giá này. BM HTTT - Khoa CNTT - HUI

15. Quy trình phát triền yêu cầu • Trước khi thực hiện quy trình này, analyst cần phải xác định : • Product Vision  product goal (mục đích lâu dài) • Project scope  boundaries (phạm vi dự án) BM HTTT - Khoa CNTT - HUI

16. BM HTTT - Khoa CNTT - HUI

17. Product Vision và Project Scope • Vision (hay mission) mô tả thực chất sản phẩm sẽ là cái gì. • Project scope xác định một phần của mục đích lâu dài (long-term product vision) của sản phẩm mà dự án hiện hành đang thực thi. • Vision dùng để chỉ đến cả hệ thống phần mềm, nó phản ánh mục tiêu nghiệp vụ (business objectives) của hệ thống , còn scope chỉ liên quan đến từng dự án riêng lẻ hay một lần lặp trong quá trình phát triển tăng tiến các chức năng của hệ thống. BM HTTT - Khoa CNTT - HUI

18. Product vision và project scope BM HTTT - Khoa CNTT - HUI

19. Scope of a project Cần phải xác định scope (=boundary) của phần mềm. Một trong các rủi ro lớn nhất của hệ thống là để cho scope “phình ra” (‘creep’), không ai biết chính xác hệ thống bao gồm những gì, mất bao lâu và chi phí bao nhiêu để hoàn tất. BM HTTT - Khoa CNTT - HUI

20. Phương pháp “soft system” A soft system is one that involves social, political and emotional issues as well as technology: again, not just products or services but people, procedures and all the relationships between people that make real life complicated but practical. BM HTTT - Khoa CNTT - HUI

21. Phương pháp “soft system” Phương pháp SSM (Soft Systems Methodology của Checkland) khuyên chúng ta thay đổi cách nhìn thế giới, trong khi đó các kỹ thuật hệ thống ‘hard’ cho chúng ta cách nhìn vấn đề một cách cố định. Theo SSM ta nên luôn tự hỏi liệu chúng ta có sai không, và nên triển khai các mô hình và khả năng khác nhau. BM HTTT - Khoa CNTT - HUI

22. Phương pháp soft system Bắt đầu bằng mô hình ‘rich picture’ Từ stakeholder để xác định boundary Xác định giao diện (interface) Đánh giá chọn lựa boundary BM HTTT - Khoa CNTT - HUI

23. Phương pháp “soft system” • Bắt đầu bằng ‘rich picture’ • Lược đồ chỉ ra những gì đang xảy ra trong nghiệp vụ, • Biểu diễn context and scope thông dụng tuy không chính quy • Chứa các khái niệm và vấn đề có liên quan mà được stakeholder đề cập đến. BM HTTT - Khoa CNTT - HUI

24. BM HTTT - Khoa CNTT - HUI

25. Đặc điểm của ‘Rich picture’ • Bạn là 1 phần của hệ thống mềm mà bạn đang quan sát. • Bạn có thể đưa vào sự can thiệp của bạn và cải thiện chính hệ thống đang quan sát. • Soft system có thể xác định nhu cầu của sản phẩm rộng hơn. Nếu đường biên của hệ thống càng rộng thì hệ thống càng trở nên mềm hơn. BM HTTT - Khoa CNTT - HUI

26. Đặc điểm của ‘Rich picture’ • Từ stakeholder đến boundary • Một số stakeholder quan trọng (lớp ngoài của onion) tuy không trực tiếp vận hành sản phẩm như giám đốc công ty nhưng có thể gây áp lực cho người quản lý phần mềm. • Chỉ 1 ít sản phẩm là thực sự độc lập (autonomous) còn hầu hết được vận hành bởi con người và tuân theo các quy tắc và thủ tục nào đó. Thậm chí các sản phẩm tưởng chừng tự vận hành như máy bay, robot nhà máy, cũng cần được lắp đặt, cấu hình, kiểm thử và bảo trì bởi con người. BM HTTT - Khoa CNTT - HUI

27. Phạm vi hệ thống • Hệ thống thường gồm những thành phần sau cùng làm việc với nhau: • Một hay nhiều sản phẩm • Một số người vận hành • Các quy tắc và thủ tục cho biết làm cái gì trong những hoàn cảnh khác nhau. • Thường có nhiều người vận hành (operator) và sản phẩm trong cùng 1 hệ thống và cùng kết hợp lại để cung cấp các dịch vụ. BM HTTT - Khoa CNTT - HUI

28. Ví dụ một vài hệ thống BM HTTT - Khoa CNTT - HUI

29. Xác định phạm vi hệ thống Tùy vào ngữ cảnh, dự án có thể mở rộng phạm vi hơn, chứa nhiều khả năng hơn bên trong phạm vi. BM HTTT - Khoa CNTT - HUI

30. Xác định giao diện (interface) Bằng cách kết hợp quan điểm của các stakeholder thích hợp lại với nhau, ví dụ đội bay và bảo trì, bạn cần phải đi đến quyết định quan trọng và cân đối giữa các phạm vi đã phác thảo ra. Những quyết định này sẽ xác định phạm vi và giao diện của hệ thống. BM HTTT - Khoa CNTT - HUI

31. Ví dụ về giao diện • Vì maintenance nằm bên trong phạm vi hệ thống ‘operable aircraft’, giao diện giữa maintenance và aircraft bây giờ là nội bộ. • Maintenance và simulation/training là các hệ thống con. • Dự án sẽ phải thiết kế giao diện cho cả maintenance và simulation/training. BM HTTT - Khoa CNTT - HUI

32. Ví dụ về giao diện • Giao diện maintenance nên: • Tương tự như giao diện aircraft khác, để giảm thiểu nhu cầu tool mới. • Có thiết kế đặc biệt phù hợp với máy bay mới, để tăng tối đa tính hiệu quả của bảo trì. BM HTTT - Khoa CNTT - HUI

33. Đánh giá chọn lựa boundary • Là nhiệm vụ khó khăn (difficult) và quan trọng (critical) • Tại sao khó khăn? • Tại sao quan trọng? Assignment 11 BM HTTT - Khoa CNTT - HUI

34. Phương pháp hard system Phương pháp hard system chỉ ra cách làm thề nào để xác định được yêu cầu chức năng (functional requirement)  kiểm soát các sự kiện (event) xảy ra thông qua ngữ cảnh và giao diện đã thỏa thuận. . BM HTTT - Khoa CNTT - HUI

35. Lược đồ ngữ cảnh truyền thống(tradional context diagram) Để xác định phạm vi công việc một cách tổng thể. Tránh cho scope không bị phình ra ‘creep’ (khi có 1 số vấn đề do lúc đầu không phát hiện được dần dần lộ ra gây phiền phức mà không có 1 cảnh báo nào trước đó). Lược đồ ngữ cảnh thường không quan tâm đến mọi cái bên ngoài boundary nếu không trực tiếp ảnh hưởng đến giao diện hệ thống BM HTTT - Khoa CNTT - HUI

36. Lược đồ ngữ cảnh truyền thống(tradional context diagram) BM HTTT - Khoa CNTT - HUI

37. Lược đồ ngữ cảnh truyền thống(tradional context diagram) Mũi tên hướng vào hình tròn trên lược đồ biểu diễn 1 ‘event’ Scope được xem như 1 tập các event được ta quyết định là sẽ quản lý nó.  Mỗi sự kiện mà được thỏa thuận nằm trong scope sẽ trở thành 1 yêu cầu BM HTTT - Khoa CNTT - HUI

38. Hai loại sự kiện (event) • External (data or physical) event: the loại sự kiện xảy ra không dự báo trước được, xem như 1 tác nhân (stimulus), kích (wake up) cho hệ thống phải làm gì đó để đáp ứng lại. Tác nhân có thể là: • Message (like a packet of data); • Signal from a sensor • Explicit control input (e.g. a button press, a mouse click, a touch on a touch-sensitive screen). BM HTTT - Khoa CNTT - HUI

39. Hai loại sự kiện (event) Time-triggered event: tín hiệu thời gian( a shared clock on a network) : sự kiện này cũng kích cho hệ thống phải làm gì đó để đáp ứng lại, giống như một tác nhân từ bên ngoài. BM HTTT - Khoa CNTT - HUI

40. Lược đồ ngữ cảnh truyền thống(tradional context diagram) Ưu điểm Nhược điểm Assignment12 BM HTTT - Khoa CNTT - HUI

41. Case study: lược đồ ngữ cảnh BM HTTT - Khoa CNTT - HUI

42. Exercise Choose a style of restaurant and business model (for example, an elegant setting with independent chef; fast-food pizzas and cola; good coffee and cakes with free Internet access, etc): a. Develop a context model for your particular type of restaurant, starting from the (generalised) rich picture. Define carefully what you need to control and include, and what you will obtain from other businesses. b. List the main events your restaurant’s IT system will need to handle. BM HTTT - Khoa CNTT - HUI

43. Tài liệu về vision và scope • Tài liệu về vision và scope chứa các yêu cầu nghiệp vụ thiết lập các giai đoạn phát triển tiếp theo. • Các tài liệu khác có cùng mục đích: • Project charter • Business case document • Market requirements document (MRD) BM HTTT - Khoa CNTT - HUI

44. Tài liệu về vision và scope • Chủ nhân của tài liệu vision and scope là: • Người tài trơ chính (executive sponsor) của dự án • Người chi tiền (funding authority) • Người phân tích yêu cầu (requirements analyst) có thể làm việc với owner để viết tài liệu vision and scope. BM HTTT - Khoa CNTT - HUI

45. Tài liệu về vision và scope • Yêu cầu nghiệp vụ nên thu thập từ những ai hiểu rõ vì sao họ quan tâm đến dự án. Họ là: • Customer • Senior management • Project visionary • Product manager • Subject matter expert • Members of the marketing department. BM HTTT - Khoa CNTT - HUI

46. Mẫu tài liệu vision và scope BM HTTT - Khoa CNTT - HUI

47. Finding the Voice of the Customer BM HTTT - Khoa CNTT - HUI

48. Các bước tìm hiểu khách hàng Nhận biết các loại người dùng khác nhau Xác định các nguồn của yêu cầu người dùng. Chọn lựa cá nhân tiêu biểu cho mỗi loại người dùng hay các nhóm stakeholder khác nhau để làm việc với họ. Thỏa thuận các yêu cầu với người ra quyết định dự án. BM HTTT - Khoa CNTT - HUI

49. Khó khăn khi thu thập yêu cầu từ khách hàng • Việc không phù hợp giữa sản phẩm mà khách hàng mong đợi và sản phẩm mà nhà phát triển xây dựng thường do: • Thiếu sự quan tâm của khách hàng. • Khách hàng thường không biết chính xác cái họ thực sự cần • Nhà phân tích yêu cầu cần thu thập user input, phân tích và xác định rõ cần xây dựng cái gì để giúp người dùng hoàn thành công viêc̣ của họ. BM HTTT - Khoa CNTT - HUI

50. Nhiệm vụ của nhà phân tích Ghi nhận khả năng và tính chất cần thiết của hệ thống mới. Trao đổi thông tin với các stakeholders. Là quá trình lặp mất nhiều thời gian nhưng nếu không đầu tư thời gian thì có thể dẫn đến hậu quả: rework, delayed completion, và customer dissatisfaction. BM HTTT - Khoa CNTT - HUI