ÔN TẬP GIỮA KỲ

1. ÔN TẬP GIỮA KỲ

2. NỘI DUNG • Phát biểu vấn đề • Tầm nhìn và Phạm vi (Vision and Scope) • Xác định mục tiêu • Xác định yêu cầu • Xác định StackHolder, lớp người dùng • Các kỹ thuật thu nhận yêu cầu • Các kỹ thuật phân tích yêu cầu • Bài tập

3. Product Vision và Project Scope • Vision (hay mission) mô tả thực chất sản phẩm sẽ là cái gì. • Project scopexá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

4. Product Vision và Project Scope • Vision thay đổi tương đối chậm, scope thay đổi linh động theo mỗi dự án tùy thuộc vào các ràng buộc về thời gian (schedule), ngân sách (budget), tài nguyên (resource) và chất lượng (quality) của dự án. • Các tài liệu nên có của mỗi dự án mới • Vision and scope document • Software Requirement Specification (SRS) BM HTTT - Khoa CNTT - HUI

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

6. Vision và Scope Document • Tài liệu bao gồm một mô tảvềcơhội kinh doanh của sản phẩm, tầm nhìn và cácmục tiêu của sản phẩm, báo cáo phạm vi và các giới hạn của sản phẩm, mô tảđặctính của khách hàng (characterization of customers), các ưu tiên của dựán, mô tảcác tiêu chuẩn đánh giá sựthành công của dựán. • Tài liệu cần tương đối ngắn, chỉnên từ3 tới 8 trang, phụthuộc chủyếu vào bản chất và kích thước của dựán. BM HTTT - Khoa CNTT - HUI

7. Vision và Scope Document • Các vấn đề thuộc tầm nhìn và phạm vi (vision and scope) của dự áncần được phân giải rõ trước khi các yêu cầu chức năng (functional requirements)chi tiết được đặc tả đầy đủ. • Một tài liệu tầm nhìn và phạm vi (vision and scope) tốt sẽ cung cấp các tham chiếu cần thiết cho việc thêm, xoá bỏ, chỉnh sửa các yêu cầu trong tiến trình phát triển của dự án. BM HTTT - Khoa CNTT - HUI

8. 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

9. Tài liệu về vision và scope • Yêucầunghiệp vụ nênthuthậptừ nhữngaihiểurõ vì sao họ quantâmđếndự án. Họ là: • Customer • Senior management • Project visionary • Product manager • Subject matter expert • Members of the marketing department. • Kháchhàng • Người có trách nhiệm trong bô phận quản lý • Người hình dung của dự án • Quảnlýsảnphẩm • Cácchuyêngialãnhvục • Thànhviêncủabộphận marketing BM HTTT - Khoa CNTT - HUI

10. 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

11. Scope of a project BM HTTT - Khoa CNTT - HUI

12. Scope of a project BM HTTT - Khoa CNTT - HUI

13. Xác định những người liên quan • Stakeholder: • Bao gồm những người, tổ chức mà là một phần của môitrường hệ thống. Hệ thống cung cấp cho họ những lợi ích và họ có tầm quan trọng trong hệ thống BM HTTT - Khoa CNTT - HUI

14. Stakeholder • Customers • Users • Requirements analysts • Developers • Testers • Documentation writers • Project managers • Legal staff – nhóm người làm việc hợp pháp • Manufacturing people – người sản xuất • Sales, marketing, field support, help desk, …

15. Stakeholder của hệ thống ATM • Khách hàng của ngân hàng • Đại diện của các ngân hàng khác • Người quản lý ngân hàng • Nhân viên thu tiền • Người quản trị CSDL • Người quản lý bảo mật • Kỹ sư bảo trì phần cứng và phần mềm • Những người điều phối ngân hàng… BM HTTT - Khoa CNTT - HUI

16. Stakeholder • Stakeholder không rõ những gì họ thật sự muốn • Stakeholder diễn đạt yêu cầu theo những thuật ngữ riêng của họ • Những stakeholder có thể có những yêu cầu tranh chấp • Nhân tố quyền lực và tổ chức ảnh hưởng tới yêu cầu hệ thống • Những yêu cầu có thể thay đổi trong quá trình phân tích, có thể xuất hiện những nhân tố mới, những thay đổi về môi trường nghiệp vụ BM HTTT - Khoa CNTT - HUI

17. Thực hành • Bạn là người quản lý sản phẩm cho một công tycông cụ máy. Giám đốc yêu cầu bạn phát triểnmột máy cắt mới quần áo để may váy thời trangtheo các kích cỡ và mẫu. Máy được bán chonhững người làm quần áo khắp thế giới • Các stakeholder? • Phân tích và đánh giá các stakeholder? BM HTTT - Khoa CNTT - HUI

18. Answer #1 • Key stakeholders are: • Giám đốc và các cổ đông trong công ty • Nhân viên bán hàng và tiếp thị của công ty • Khách hàng (những người vận hành máy cắt và chủ của họ) • Quan chức chính quyền phụ trách về sức khỏe và an toàn trong mỗi quốc gia mà ta dự định bán máy cho họ. • Các đối thủ cạnh tranh (negative stakeholders). • Nếu công ty có ý định đảm nhận thêm khâu bảo trì máy móc thì đội bảo hành cũng là stakeholder chính.

19. Answer #1 • How will you analyse and validate your stakeholder list? • Kiểm tra (check) và cập nhật (update) danh sách một cách thường xuyên; duyệt lại (review) và theo dõi (follow) thông qua các cuộc tiếp xúc gặp gỡ với stakeholder chính Trang 34

20. Phân loại người dùng • Dựa vào các yếu tố sau: • Mức độ thường xuyên người dùng sử dụng sản phẩm • Kinh nghiệm về miền ứng dụng của họ, sự thành thạo về hệ thống máy tính • Các tính năng mà người dùng sử dụng • Các tác vụ để hỗ trợ xử lý nghiệp vụ • Quyền truy xuất và cấp độ bảo mật BM HTTT - Khoa CNTT - HUI

21. Phân cấp người dùng BM HTTT - Khoa CNTT - HUI

22. Kinhnghiệmphânloạingườidùng • Nên phân loại người dùng sớm để có thể thu thập yêu cầu từ đại diện của mỗi lớp người dùng. • Không nên e ngại nếu lúc đầu có quá nhiều lớp người dùng • Không nên bỏ qua bất kỳ lớp người dùng nào vì sau này có thể sẽ phải rework • Ghép chung các lớp người dùng nào có yêu cầu tương tự nhau. Nên giảm xuống sao cho không quá 15 lớp người dùng khác nhau. BM HTTT Khoa CNTT - HUI

23. Tàiliệungườidùng • Ghi chép các lớp người dùng, tính cách, trách nhiệm, và địa điểm làm việc vào tài liệu SRS Giúp đội phát triển xếp loại độ ưu tiên các yêu cầu Giúp các tester xây dựng cách sử dụng hệ thống (usage profile for the system) và có thể lập kế hoạch cho việc kiểm thử BM HTTT Khoa CNTT - HUI

24. Tìmđạidiệnngườidùng • Mỗi loại dự án đều cần có đại diện người dùng thích hợp để cung cấp tiếng nói chung cho nhóm người dùng đó. • Người đại diện không chỉ tham gia trong giai đoạn thu thập yêu cầu mà trong suốt chu kỳ phát triển dự án BM HTTT Khoa CNTT - HUI

25. Đạidiệnlớpngườidùng(user representatives) • Đối với ứng dụng của công ty: dễ dàng xác định người dùng thực sự cho mỗi lớp người dùng. • Ví dụ: chọn Fred là kỹ sư hóa cho lớp chelmistt • Đối với phần mềm thương mại (commericial software): chỉ có thể có được người dùng thực sự sau khi phát hành phiên bản chạy thử (beta-testing) hay đầu tiên • Nên thiết lập nhóm người tình nguyện (focus group) từ những người dùng phần mềm của mình hay phần mềm của đối thủ BM HTTT Khoa CNTT - HUI

26. Người dùng tiêu biểu PC • PC (Product champion) dùng để chỉ những thànhviên chính trong cộng đồng người dùng cung cấp cho dự án các yêu cầu. • Cs (Champions) là các người dùng thực sự, khôngphải là người đại diện như nhà tài trợ, nhân viêntiếp thị, người quản lý … BM HTTT - Khoa CNTT - HUI

27. Vai trò của Product Champiom • PC (Product champion) thu thập yêu cầu từ các thành viên khác thuộc lớp người dùng mà họ đại diện và hợp nhất lại yêu cầu không giống nhau. • Phát triển yêu cầu là trách nhiệm chung của nhà phân tích và khách hàng đã được chọn, mặc dù nhà phân tích sẽ là người viết yêu cầu. BM HTTT - Khoa CNTT - HUI

28. Một PC tốt • Có cái nhìn rõ ràng về hệ thống mới và ủng hộ hệ thống vì họ thấy được lợi ích dành cho họ từ hệ thống mới này. • Là người cởi mở và được đồng nghiệp tín nhiệm. • Là người hiểu biết thấu đáo về nghiệp vụ và môitrường hoạt động của hệ thống. • Nhận thức được tầm quan trọng của họ đối với sự thành công của dự án. BM HTTT - Khoa CNTT - HUI

29. PC bên ngoài • Khi phát triển phần mềm thương mại, rất khó tìm PC từ bên ngoài. • Nếu có quan hệ công việc gần gũi với 1 số công ty, một số người thể sẵn lòng tham gia vào quá trình thu thập yêu cầu. • Nên khích lệ bằng kinh tế cho các PC bên ngoài như giảm giá sản phẩm hay trả tiền theo giờ khi họ tham gia công việc BM HTTT - Khoa CNTT - HUI

30. Quyền hạn của product champion • Phương pháp dùng PC chỉ tốt khi mỗi champion có quyền đưa ra các quyết định đại diện cho lớp của minh • Nếu quyết định của champion luôn bị gạt bỏ bởi managers hay SW group thì thời gian và thiện chí của họ sẽ bị lãng phí. • Nhưng champion cũng nên nhớ rằng họ không phải là khách hàng duy nhất BM HTTT - Khoa CNTT - HUI

31. Hạn chế tử PC • Làm thế nào để tránh chỉ nghe yêu cầu từ CP mà bỏ qua các nhu cầu từ các khách hàng khác. • Nếu khách hàng đa dạng thì trước tiên cầnnhận biết yêu cầu cơ bản chung cho mọi kháchhàng, sau đó xác định các yêu cầu khác từ cácloại người dùng khác, từ bộ phận tiếp thị, từ khách hàng riêng lẻ,… BM HTTT - Khoa CNTT - HUI

32. Goal và requirement • Goals là cái mà stakeholders muốnthựcthi. • Goals có thể có nhiềumứcđộ khácnhau: • Mứccaonhất (highest level): phátbiểuvềnhiệmvụvàmụctiêu, chính là mission statements and objectives. (Có thể dùng Mission = vision = objective) Mụctiêulâudàithì đượcgọi là policies. • Mứcthấpnhất (lowest level): gọi là chứcnăngcơbảnriêngbiệt (individual functions) BM HTTT - Khoa CNTT - HUI

33. 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

34. Question 2 You are a product manager for a machine tool company. The directors have asked you to develop a new cutting machine to cut cloth for fashionable dresses of all sizes and patterns. The machine will be sold to clothing makers around the world. a. What are the major goals for this project? b. Using the list of stakeholders for this project, identify the likely sources of tension (possible conflict) between stakeholders’ goals.

35. Answer #2 Major goals: • Đưa máy cắt ra thị trường đúng lúc và trong ngân sách dự tính • Phát triển 1 dòng sản phẩm mới. • Đạt được chứng nhận an toàn (safety certificate) ở tất cả các quốc gia dư định bán máy. • Hiểu được yêu cầu trong từng quốc gia mà ta dự định bán máy, • Chuẩn bị tài liệu cho người dùng và người bán hàng bằng nhiều thứ tiếng tương ứng với các quốc gia mà ta dự định bán máy. • Bảo đảm là bộ phận bảo hành phải sẵn sàng • Bảo đảm là bộ phận phân phối tiếp thị đã sẵn sàng • Hiểu rõ các đối thủ cạnh tranh và có chiến lược đối phó

36. Yêu cầu (requirement) 36 Một yêu cầu là một đặc trưng của hệ thống, haylà sự mô tả những việc, mà hệ thống có khả năngthực hiện để hoàn thành mục tiêu của hệ thống Yêu câù cũng có thê ̉là các ràng buộc trong quá trình phát triển hệ thống. Yêu cầu có thể được ràng buộc bởi hợp đồng hayvăn bản Có những yêu cầu ngầm định (implicit) Một yêu cầu có thể được nhận biết (known, spoken)/ không nhận biết (forgotten, unspoken…) Requirements described the “what” of a system, not the “how”

37. Vai trò của yêu cầu • Yêu cầu quan trọng vì nó cung cấp các cơ sở cho tất cả công việc phát triển hệ thống sau đó. • Ngay khi yêu cầu được xác định, nhà phát triển khởi đầu các công việc kỹ thuật khác như: thiết kế hệ thống, phát triển, kiểm thử, thực thi và vận hành.

38. Phân loại yêu cầu • Yêu cầu được phát biểu (stated requirement) • Yêu cầu thực (real requirement)

39. Stated Requirements • Là các yêu cầu được cung cấp bởi khách hàng khi bắt đầu phát triển hệ thống. • Các dạng yêu cầu: • Yêu cầu về thông tin • Dự toán • Bảng báo giá • Phát biểu công việc (statement of work – SOW)

40. Real Requirements • Là các yêu cầu phản ánh nhu cầu xác thực của người dùng. • Thường khác nhau rất lớn giữa yêu cầu phát biểu và yêu cầu thực. • Việc phân tích các yêu cầu khách hàng (stated requirements) được dùng để xác định và tinh chỉnh các nhu cầu thực sự của khách hàng.

41. Requirements Engineering • Là hệ thống các phương thức có liên quan với nhau chỉ định cái mà khách hàng muốn hệ thống làm gì. • There are two majors tasks in the requirements engineering: • Analysis • Modeling

42. Requirements Engineering • Analysis is the process of determining what the customer wishes the system to do and formally creating a list of requirements that the customer can understand and agree to do. • Modeling is a process of interpreting the customer requirements into something that software engineers can understand.

43. Phân loại yêu cầu trong quá trình phân tích yêu cầu • Gồmhailoạichính: • Yêucầuchứcnăng (Function requirements) • Yêucầu phi chứcnăng (Non Functional Requirements)

44. Yêu cầu chức năng(Functional requirements) • Yêu cầu chức năng (Functional requirements): chức năng dịch vụ hệ thống cung cấp. • Xác định chức năng của phần mềm mà các nhà phát triển phải xây dựng để giúp người dùng hoàn thành nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ. • Đôi khi còn được gọi là behavioral requirements. • Ví dụ: “The system shall e-mail a reservation confrimation the user”

45. Yêu cầu chức năng(Functional requirements) • Yêu cầu chức năng (Functional requirements): Yêu cầu chức năng chỉ ra những gì hệ thống làm,chúng thường quan hệ các use-case hay những qui tắc nghiệp vụ (business rule) • Một số yêu cầu chức năng • Chức năng tính toán • Chức năng lưu trữ • Chức năng tìm kiếm • Chức năng kết xuất • Chức năng backup, restore • Chức năng đa người dùng • Chức năng đa phương tiện…

46. Yêu cầu chức năng(Functional requirements) • Thídụ: Trong hệ thống quản lý thư viện • Người dùng có thể tìm kiếm, download, in những bàibáo • Người dùng được cấp một vùng lưu trữ riêng để cóthể copy để lưu trữ tài liệu lâu dài…

47. Yêu cầu phi chức năng(Non-functional requirements • Yêu cầu phi chức năng (Non-functional requirements): Không tập trung vào các chức năng của hệ thống mà chỉ tập trung vào các ràng buộc của hệ thống. Những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…, chủ yếu là những yêu cầu về chất lượng. • Sáu loại chính của yêu cầu phi chức năng: security, privacy, usability, reliability, availability, and performance. • Ràng buộc: phản ảnh những đặc trưng của miền ứng dụng. Chúng có thể là những yêu cầu chức năng hay yêu cầu phi chức năng.

48. Yêu cầu phi chức năng(Non-functional requirements • Một số yêu cầu phi chức năng • Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ… • Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình… • Yêu cầu của người sử dụng: dễ sử dụng, thân thiện • Ràngbuộcvềngânsách • Phùhợpvớicácchínhsáchcủatổchứcsửdụng hệ thống • Yêu cầu tương thích giữa phần cứng và phần mềm • Cácyêucầutừcáctácnhânngoàikhác…

49. Yêu cầu phi chức năng(Non-functional requirements • Vídụ • Trong hệ thống quản lý thư viện • Yêu cầu sản phẩm: giao diện người dùng không chứa frame và applet java • Yêucầutổchức: qui trìnhpháttriểnhệthốngvàtàiliệuphânphốiphảiphùhợptheotiêuchuẩn“STAN-07” (sử dụng ngôn ngữ, phương pháp thiếtkế…) • Yêu cầu ngoài: hệ thống không được lộ thông tincủakháchhàng (tên, sốthamchiếu…)

50. Phân loại yêu cầu