chƯƠng ii stakeholder-visionandscope · pdf filephải là người đại diện như...

TNYCThu nhận yêu cầu

1

CHƯƠNG II

Stakeholder-VisionAndScope

Thu nhận yêu cầu

1. Xác định những người liên quan (stakeholder)2. Hiểu nhu cầu khách hàng3. Thu nhận yêu cầu từ khách hàng4. Mục tiêu (Goal) và yêu cầu5. Product Vision và Project Scope6. Phương pháp hệ thống mềm

Nội dung

2

Qui trình

3


1. 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ôi trườ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 Stakeholder:users, operators, bill payers, owners, regulatory agencies, victims, sponsors, maintainers, architects, managers, customers, surrogate customers …

4


© 2009 Bahill

Các stakeholder của Boeing 787

Users: passengers that fly on the airplane Operators: fight crews and mechanicsBill payers: airline companiesOwners: stockholders of these companies Regulators: FAASponsor: corporate headquartersMaintenance: ground crewVictims: people living near the airports…

5


6

Cần quan tâm tới qui trình


Các stakeholder khác

Users and operators: employees in the manufacturing plantBill payer: BoeingOwner: stockholders of BoeingRegulators: OSHAVictims: physically and emotionally injured workersAir traffic control tower

7


• Customers• Users • Requirements analysts• Developers• Testers• Documentation writers• Project managers• Legal staff• Manufacturing people• Sales, marketing, field support, help desk, …

Stakeholder

8


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ácNgười quản lý ngân hàngNhân viên thu tiềnNgười quản trị CSDLNgười quản lý bảo mậtKỹ sư bảo trì phần cứng và phần mềmNhững người điều phối ngân hàng…


Stakeholder

Stakeholder không rõ những gì họ thật sự muốnStakeholder 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ấpNhân tố quyền lực và tổ chức ảnh hưởng tới yêu cầu hệ thốngNhữ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ụ


11

Thực hành

Xác định stakeholder

Qui trình

12


2. Hiểu nhu cầu của khách hàng

Nhà phân tích phải ở trong môi trường của khách hàng để khám phá các chi tiết và giải thích cho họThiết kế mềm dẽo và tạo mẫu nhanh là những phương tiện xác định yêu cầu của khách hàng

13


Phát biểu của khách hàng

Khách hàng nói

Cái mà họ thật sự cần

14


Khách hàng là một cá nhân hay 1 tổ chức mong muốn trực tiếp hoặc gián tiếp có lợi từ sản phẩm. Hai loại khách hàng phần mềm:

Khách hàng cấp quản lý (management level)Người dùng cuối (end user)

Khách hàng là ai?

15


Thường là những khách hàng trả tiền hay tài trợ dự án phần mềm. Khách hàng ở cấp quản lý có nhiệm vụ xác định yêu cầu nghiệp vụ

Mô tả mục tiêu nghiệp vụ mà khách hàng, công ty hay các stakeholder muốn hoàn thành.Xác lập các thành phần chính cho phần còn lại của dự án

Các yêu cầu nghiệp vụ không đủ chi tiết để giúp các nhà phát triển biết phải xây dựng cụ thể cái gì

Khách hàng ở cấp quản lý

16


Bao gồm tất cả những ai sẽ thực sự sử dụng sản phẩm Người dùng có thể mô tả việc dùng sản phẩm cho công việc của họ và những mong đợi về chất lượng từ sản phẩm

Khách hàng là người dùng cuối

17


Thường cả hai loại khách hàng này đều cho rằng họ không có nhiều thời gian để làm việc với các nhà phân tích yêu cầu. Đôi lúc họ nghĩ là nhà phân tích sẽ hình dung ra được cái người dùng cần mà không cần phải thảo luận với nhau.

Đặc tính của khách hàng

18


Thường xuất hiện những xung đột giữa yêu cầu nghiệp vụ và yêu cầu người dùng. Yêu cầu nghiệp vụ phản ánh chiến lược của tổ chức và các ràng buộc về tài chính mà người dùng có thể không nhìn thấy được người dùng thường thất vọng thất vọng về hệ thống mới, họ nghĩ mình như “con tốt” của 1 tương lai không như ý…Nhà phân tích nên làm việc với các đại diện chính của người dùng và các nhà tài trợ để hòa giải các xung đột.

Đặc tính của khách hàng

19


Thường có sự mâu thuẫn giữa người phát triển và khách hàngNgười quản lý thường ưu tiên cho việc phù hợp với lịch làm việc của chính họ

Quan hệ khách hàng và nhà phát triển

20


Chất lượng dưới nhiều góc độ

QUALITY SOFTWARE

Developer:easy to design; easy to maintain; easy to reuse its parts

User: easy to learn; efficient to use; helps get work done

Customer:solves problems at an acceptable cost in terms of money paid and resources used

Development manager:sells more and pleases customers while costing less to develop and maintain


Bill of Rights for Software Customers

Expect analysts to speak your language.Expect analysts to learn about your business and your objectives for the system.Have analysts explain all work products created from the requirements process.Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product.Describe characteristics of the product that will make it easy and enjoyable to use...

22


3. Khách hàng với Thu nhận yêu cầu

Xác định tầm quan trọng của quan điểm khách hàngLà một kỹ thuật đòi hỏi nhiều kiến thức

23


1. Nhận biết các lớp người dùng khác nhau2. Xác định các nguồn của yêu cầu người dùng. 3. Chọn và làm việc với cá nhân tiêu biểu cho mỗi

lớp người dùng hay nhóm stakeholder khác nhau.4. Thỏa thuận các yêu cầu với người ra quyết định

của dự án.

Các bước tìm hiểu khách hàng

24


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

Các khó khăn khi thu thập

25


Thực hiện nhiệm vụ với thời gian tiêu tốn cao (lặp) nhưng nếu không đầu tư thời gian thì có thể dẫn đến hậu quả: phải thực hiện lại, trễ hạn, khách hàng không thỏa mãn

Nhiệm vụ của nhà phân tích

26


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ẩmKinh nghiệm về miền ứng dụng của họ, sự thành thạo về hệ thống máy tínhCác tính năng mà người dùng sử dụngCác tác vụ để hỗ trợ xử lý nghiệp vụQuyền truy xuất và cấp độ bảo mật

Phân loại người dùng

27


Phân cấp người dùng

28


Giao tiếp giữa user va ̀ developer

29


PC (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. Cs (Champions) là các người dùng thực sự, 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ý …

Người dùng tiêu biểu PC

30


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

Một PC tốt

31


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

PC bên ngoài

32


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ì nên trước tiên cần nhận biết yêu cầu cơ bản 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ẻ,…

Cầu lưu ý

33


Hệ thống theo dõi hóa chất (Chemical Tracking)

34


Bạn là người quản lý sản phẩm cho một công ty công cụ máy. Gáim đốc yêu cầu bạn phát triển một máy cắt mới quần áo để may váy thời trang theo các kích cỡ và mẫu. Máy được bán cho nhữ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?

Thực hành

35


Mục tiêu là cái mà stakeholder muốn thực thi. Mục tiêu có thể có nhiều mức độ khác nhau:

Mức cao nhất: phát biểu về nhiệm vụ và mục tiêu Mức thấp nhất: những chức năng riêng biệt

4. Mục tiêu (Goal) và yêu cầu

36


Mục tiêu chi tiết sẽ trở thành yêu cầu nó cần có đặc tính:

Có thể kiểm chứng đượcPhân loại ưu tiên

Mục tiêu và yêu cầu


Mục tiêu - Ví dụ

Game cho phép các thành viên trong gia đình chơi dễ dàng. Game dành cho những gia đình có trẻ 5-7 tuổi, họ có thể bắt đầu chơi sau 3 phút khởi động. Tiêu chuẩn chấp nhận: qua kiểm thử tính sử dụngNhững người phát hành game cho phép khách hàng thỏa mãn nhiều hơn bằng cách sử dụng SOA (service-oriented architecture)


Mục tiêu và yêu cầu

40

Dr 54-75


Phân biệt giữa yêu cầu nghiệp vụ và yêu cầu phần mềmThườ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à phải phù hợp với yêu cầu nghiệp vụ.Yêu cầu nghiệp vụ

Tự động hóaBằng tay

Yêu cầu nghiệp vụ

41


Ví dụ

Tự động hóa: các nghiệp vụ thường kỳ như tính lương, quản lý điểm…Thực hiện bằng tay: ví dụ đánh giá tổn hại nhân thọ, đánh giá rủi ro (nhưng có thể lưu trữ)…

42


Mục tiêu nghiệp vụ của người quản lý kiosk:Tạo ra doanh thu bằng cách cho thuê hay bán các kiosk cho ngững người bán lẻBán hàng tiêu dùngThu hút khách hàng đến các thương hiệu hàng hóaCung cấp các hàng hóa đa dạng

Phần mềm quản lý Kiosk

43

srse


Mục tiêu nghiệp vụ của người bán lẻ:Thu lợi nhuận cao nhất từ diện tích mặt bằng đang cóThu hút khách hàngÁp dụng hệ thống thông tin để tăng doanh số và lợi nhuận

Phần mềm quản lý Kiosk

44


Người quản lý muốn tạo 1 hướ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 trước khi nhà phân tích phân tích yêu cầu phần mềm.

Xung đột

45


Xung đột mục tiêu nên được phát hiện sớm từ các stakeholder và việc phân tích mục tiêu, cách giải quyết sẽ được khi đưa ra trong dự thảo thiết kếTrong một số trường hợp chỉ cần một phác thảo đơn giản là đã xác định được một hướng tiếp cận có khả thi không?Một vài trường hợp, không thể nào tìm ra được giải pháp khả thi giải quyết xung đột mục tiêu

Giải quyết xung đột

46


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 tiêu)Project scope ≅ boundaries (phạm vi dự án)

Quy trình phát triển yêu cầu

47


Vision (hay mission) mô tả thực chất sản phẩm sẽ là gìProject scope xác định một phần của product vision dài hạnVision dùng để chỉ đến cả hệ thống phần mềm, nó phản ánh mục tiêu nghiệp vụ của hệ thống, còn scope trong quá trình phát triển tăng tiến chỉ liên quan đến một lần lặp

5. Product Vision và Project Scope

48


49


Product vision và Project scope

50


Tài liệu về vision và scope chứa các yêu cầu nghiệp vụ, xác định các giai đoạn phát triểnCác tài liệu khác có cùng mục đích:

Project charter Business case documentMarket requirements document (MRD)

Tài liệu về vision và scope

51


Chủ nhân của tài liệu vision và scope là:Người tài trợ (sponsor) của dự ánNgười chi tiền (funding authority)

Người phân tích yêu cầu có thể làm việc với người chủ để viết tài liệu vision và scope.

Tài liệu về vision và scope

52


Khách hàngNgười có trách nhiệm trong bô phận quản lýNgười hình dung của dự ánQuản lý sản phẩmCác chuyên gia lãnh vụcThành viên của bộ phận marketing

Người tham gia

53


Một trong các rủi ro lớn nhất của hệ thống là để cho phạm vi “phình dần ra”, 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

Lưu ý

54


Mẫu tài liệu vision và scope

55

srse


Thực hành

1.1 Lý do chính khi đưa ra sản phẩm?1.2 Sự hấp dẫn đối với thị trường1.3 Mục tiêu thị trường và những điều kiện cho thành công1.4 Nhu cầu (marketplace competition, timing issues, user acceptance, implementation issues…)2.1 For [target customer]Who [statement of the need or opportunity]The [product name]Is [a product category]That [key benefit, compelling reason to buy or use]Unlike [primary competitive alternative, current system, or current business process],Our product [statement of primary differentiation and advantages of new product].

56


Thực hành

2.2 những khác biệt, những đặc trưng mới2.3 giả định: dự định thay thế hệ thống nào đó…, phụ thuộc vào qui định chờ ban hành, chính sách…3.3 giới hạn và loại trừ4.1 những nhóm người nào được những lợi ích gì4.2 những gì là bắt buộc, có thể điều chỉnh… (features (or scope), quality, schedule, cost, and staff)

57


6. Phương pháp hệ thống mềm

Hệ thống mềm (soft system) bao gồm những vấn đề nhạy cảm về xã hội, chính trị cũng như kỹ thuật. Nó bao gồm không chỉ sản phẩm hay dịch vụ mà cả con người các thủ tục và các mối quan hệ của con người với nhau

58


Quá trình phát triển

59


Phương pháp luận hệ thống mềm SSM (Soft Systems Methodology - Checkland)Khuyên chúng ta nhìn hệ thống một cách mềm dẽo 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.

Phương pháp SSM

60


1. Bắt đầu bằng mô hình bức tranh phong phú (rich picture)

2. Từ những người liên quan xác định biên3. Xác định giao tiếp4. Đánh giá chọn lựa biên

Các bước SSM

61


1. Bắt đầu bằng mô hình bức tranh phong phúMô hình chỉ ra những gì đang xảy ra trong nghiệp vụBiểu diễn ngữ cảnh và phạm vi thông dụng không chính quyChứa các khái niệm và vấn đề có liên quan được stakeholder đề cập đến.

Bước 1

62


1. 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.SSM có thể xác định nhu cầu sản phẩm của hệ thống 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.

Đặc điểm của Bức tranh phong phú

64


2. Từ stakeholder đến biênMột số stakeholder quan trọng 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 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 đó. • Máy bay, robot sản xuất, cũng cần được lắp đặt,

cấu hình, kiểm thử và bảo trì bởi con người.

Đặc điểm của Bức tranh phong phú (2)

65


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ẩmMột số người vận hànhCá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 và kết hợp với nhau để cung cấp các dịch vụ.

B2. Xác định biên: Hệ thống

66


Ví dụ một vài hệ thống

67


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.

Xác định phạm vi hệ thống

68


Kết hợp các stakeholder thích hợp lại với nhau, ví dụ đội bay và đội bảo trìQuyết định chọn lựa và cân đối các phạm vi đã phác thảoXác định phạm vi và giao tiếp của hệ thống.

B3. Xác định giao tiếp

69


Giao tiếp giữa hệ thống bảo trì và hệ thống aircraft bây giờ là nội bộ.

Hệ thống Bảo trì và giả lập/ huấn luyện là các hệ thống conDự án sẽ phải thiết kế giao diện cho cả Hệ thống Bảo trì và giả lập/ huấn luyện

Ví dụ về giao tiếp

70


Giao diện với hệ thống bảo trì nên:Tương tự như các giao diện của aircraft khác, nhằm tối thiểu hóa nhu cầu xây dựng công cụ mới, trang thiết bị và huấn luyện Nó có thể có thiết kế đặc biệt thích hợp nhằm tối đa hóa tính hiệu quả của việc bảo trì

Ví dụ về giao tiếp

71


Là nhiệm vụ khó khăn và then chốtTại sao khó khăn?Tại sao then chốt?

B4. Đánh giá chọn lựa biên

72

chƯƠng ii stakeholder-visionandscope · pdf filephải là người đại diện như...

Documents