Rich picture là gì

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

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 Discovery BM HTTT - Khoa CNTT - HUI

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

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

Goal và requirement BM HTTT - Khoa CNTT - HUI

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. Page 75 discovery BM HTTT - Khoa CNTT - HUI

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

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 Chapter 5 Defining the Vision Through Business Requirements software requirement.chm BM HTTT - Khoa CNTT - HUI

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

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

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 Page 83 discovery BM HTTT - Khoa CNTT - HUI

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ụ. Video\ Dissecting business from software requirement.mht BM HTTT - Khoa CNTT - HUI

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

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

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

BM HTTT - Khoa CNTT - HUI

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

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

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. Page 97 discovery BM HTTT - Khoa CNTT - HUI

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

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

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

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

BM HTTT - Khoa CNTT - HUI

Đặ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

Đặ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

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

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

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

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

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

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

Đá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 Page 107 discovery BM HTTT - Khoa CNTT - HUI

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

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

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

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

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

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

Lược đồ ngữ cảnh truyền thống [tradional context diagram] Ưu điểm Nhược điểm Assignment12 Page 114 discovery BM HTTT - Khoa CNTT - HUI

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

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

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

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

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

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

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

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

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

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

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 Their application domain experience and computer systems expertise Các tính năng người dùng sử dụng Nhiệm vụ mà họ thực thi khi xử lý nghiệp vụ Quyền truy xuất và cấp độ bảo mật BM HTTT - Khoa CNTT - HUI

Phân loại người dùng BM HTTT - Khoa CNTT - HUI

Tìm đại diện người dù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

Cách giao tiếp giữa user và developer BM HTTT - Khoa CNTT - HUI

Product Champion Product champion dùng để chỉ những thành viên chính trong cộng đồng người dùng cung cấp cho dự án các yêu cầu. Phương pháp product champion là 1 cách hiệu quả để tạo mối quan hệ customer- development. Champions là các người dùng thực sự [actual user] , không phải là người đại diện như nhà tài trợ, nhân viên tiếp thị, người quản lý … BM HTTT - Khoa CNTT - HUI

Product Champion 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 các 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

Đặc tính của một product champoin 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ôi trường hoạt động của hệ thống. Họ có quyền đòi hỏi được nhìn nhận 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

Product champoin bên ngoài Khi phát triển phần mềm thương mại [commercial software], rất khó tìm product champions 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 bạn, họ có 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 product champions 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

Product Champion Làm thế nào để tránh chỉ nghe yêu cầu từ champions 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ì nên trước tiên cần nhận biết yêu cầu cơ bản [core requirement] chung cho mọi khách hàng, sau đó xác định các yêu cầu khác từ các loạ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

Các họat động của champion Assignment 13 Chapter 6 the product champion SW requirement.chm BM HTTT - Khoa CNTT - HUI

Ví dụ: champion trong hệ thống Chemical Tracking BM HTTT - Khoa CNTT - HUI

Một số vấn đề liên quan đến champion Assignment 14 BM HTTT - Khoa CNTT - HUI