1. Trang chủ
  2. » Giáo Dục - Đào Tạo

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

147 1,3K 1
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 147
Dung lượng 5,98 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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

Trang 1

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

Trang 2

Nội dung

 Xác định những người liên quan (stakeholder)

 Hiểu nhu cầu khách hàng

 Thu nhận yêu cầu từ khách hàng

 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

Trang 3

Qui Trình

Trang 4

Stakeholder: An individual, group of people,

organisation or other entity that has a direct or indirect interest (or stake) in a system.

 A stakeholder’s interest in a system may arise

from using the system, benefiting from the

system (in terms of revenue or other advantage),

being disadvantaged by the system (in terms, for instance, of cost or potential harm), being

responsible for the system, or otherwise being affected by it.

Stakeholder là gì

Trang 5

• 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, …

Stakeholder

5

Trang 6

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 …

Trang 7

Các stakeholder của Boeing 787

Users: passengers that fly on the airplane

Operators: fight crews and mechanics

Bill payers: airline companies

Owners: stockholders of these companies

Regulators: FAA

Sponsor: corporate headquarters

Maintenance: ground crew

Victims: people living near the airports…

Trang 8

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

Trang 9

Các stakeholder khác

Users and operators: employees in the

manufacturing plant

Bill payer: Boeing

Owner: stockholders of Boeing

Trang 10

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

Trang 11

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

Trang 12

Phân tích thông tin thị trường, stakeholder, và nhu cầu của người dùng để suy dẫn các yêu cầu chức năng và phi chức năng.

Hiểu được ảnh hưởng của các yêu cầu đến nghiệp vụ

Hợp nhất các yêu cầu này lại để hoàn thành các đặc tả yêu cầu và hệ thống

Các hoạt đ ng đầu tiên của ộng đầu tiên của

requirements engineering

Trang 13

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

Trang 14

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

Trang 15

Khách hàng là ai?

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)

Trang 16

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à

Trang 18

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

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

Trang 19

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

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

Trang 20

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

Thường có sự mâu thuẫn giữa người phát triển và khách hàng

Ngườ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ọ

Trang 21

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

Trang 22

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

Trang 23

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àng

Là một kỹ thuật đòi hỏi nhiều kiến thức

Trang 24

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

1 Nhận biết các lớp người dùng khác nhau

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

Trang 25

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

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ọ

Trang 26

Managing the Customer Relationship

Cần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise)

Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt  việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạn

It is out experience that constant communication with the customer

Trang 27

Phân loại yêu cầu của khách hàng

Không nên mong đợi khách hàng sẽ cung cấp 1 danh mục có thứ tự, hoàn chỉnh và đầy đủ mọi nhu cầu của họ

Analysts cần phải phân loại vo số thông tin lộn xộn mà họ thu thập được thành các loại khác nhau sao cho có thể ghi nhận và sử dụng được một cách hiệu quả

Trang 28

Chín loại yêu cầu của khách hàng

Trang 29

1 Tránh làm phiền đến đời sống và công

việc thường ngày của khách hàng

2 Chuẩn xác tối đa, phân biệt rõ thông tin

thật giả

3 Nắm bắt điểm máu chốt, loại bỏ thông

tin không cần thiết

4 Không được tùy tiện để lộ thông tin của

khách hàng ra ngoài.

Nguyên tắc khi thu thập thông tin khách hàng

29

Trang 30

Các từ đồng nghĩa:

Nhà phân tích yêu cầu (Requirements

analyst)

Nhà phân tích hệ thống (Systems analyst)

Kỹ sư yêu cầu (Requirements engineer)

Nhà quản lý yêu cầu (Requirements

manager)

Nhà phân tích (Analyst)Systems analyst

Nhà phân tích yêu cầu -

Requirements analyst

Trang 31

 Nhà phân tích là người chuyển các ý tưởng thành những đặc tả yêu cầu.

 Nhà phân tích là người có quan hệ truyền thông với các stakeholder, giúp các stakeholder tìm thấy sự khác nhau giữa cái họ muốn và cái họ thực sự cần

 Là người có nhiệm vụ cơ bản là thu thập, phân tích, ghi chép và kiểm tra nhu cầu của các stakeholder

 Họ như là một cầu nối giữa cộng đồng khách hàng và đội phát

triển phần mềm.

 Nhà phân tích đóng vai trò trung tâm trong việc thu thập và phổ biến thông tin, còn người quản lý dự án (project manager) giữ

vai trò lãnh đạo trong việc truyền đạt thông tin dự án

Vai trò của analyst

31

Trang 32

Requirements analyst

Trang 33

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

Analyst trước tiên phải hiểu mục tiêu của người dùng, sau đó xác định các yêu cầu chức năng, cho phép người quản lý dự án làm các ước tính, các developers thiết kế, xây dựng và kiểm định sản phẩm

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

Trang 34

 Xác định yêu cầu nghiệp vụ - Define business

requirements.  

 Xác định các stakeholder và các lớp người dùng-dentify project stakeholders and user classes.  

 Rút ra những yêu cầu - Elicit requirements

 Viết đặc tả yêu cầu-Write requirements specifications

 Mô hình hóa yêu cầu-Model the requirements

 Điều hành việc đánh giá yêu cầu-Lead requirements

validation

 Phân loại ưu tiên các yêu cầu- Facilitate requirements

prioritization

 Quản lý yêu cầu - Manage requirements

Nhi m vụ của Requirements analyst ệm vụ của Requirements analyst

Trang 35

 Kỹ năng lắng nghe - Listening skill

 Kỹ năng phỏng vấn - Interviewing and questioning skill

 Kỹ năng phân tích - Analytical skill,

 Kỹ năng điều khiển - Facilitation skills.  

 Kỹ năng quan sát - Observational skills.

 Kỹ năng viết - Writing skills

 Kỹ năng tổ chức - Organizational skills

 Kỹ năng mô hình hóa - Modeling skills

 Kỹ năng giao tiếp - Interpersonal skills

 Tính sáng tạo - Creativity

 Assignment ??

Kỹ năng của nhà phân tích

35

Trang 36

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

Trang 37

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

Trang 38

Kinh nghiệm phân loại người dù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

Trang 39

Tài liệu người dù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ử

Trang 40

Các lớp người dùng trong hệ thống

Chemical tracking

Trang 41

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

Trang 42

Đại diện lớp người dùng

(user representatives)

 Each user class needs to be represented

 Đố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

Trang 43

Focus Group

 Phải đảm bảo nhóm tình nguyện đại diện cho loại người dùng mà nhu cầu của họ giúp ta phát triển hệ thống.

 Nên bao gồm cả người dùng thành thạo và người dùng ít kinh nghiệm

 Nếu nhóm tình nguyện chỉ toàn những người mơ mộng (blue –sky thinkers) không thực tế thì có thể

sẽ thu được những yêu cầu phức tạp mà người dùng bình thường không hề nghĩ đến

Trang 44

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

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ý …

Trang 45

Vai trò của Product Champiom(PC)

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

Trang 46

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

Trang 47

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

Trang 48

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

Trang 50

Hệ thống theo dõi hóa chất

(Chemical Tracking)

Trang 51

Giao tiếp giữa user và developer

Trang 52

Vấn đề về người dùng và khách hàng

 Người dùng không hiểu họ muốn gì

 Người dùng không tuân theo một bộ yêu cầu đã

được tài liệu hóa

 Người dùng nhất định đòi hỏi các yêu cầu mới sau

khi chi phí và kế hoạch phát triển đã được hoạch

định xong.

 Mức độ giao tiếp với người dùng là thấp

 người dùng thường không tham gia các đợt thẩm

định hoặc không thể tham gia.

 Người dùng không hiểu kỹ thuật

Trang 53

Vấn đề về kỹ sư/nhà phát triển

 Trong quá trình phân tích yêu cầu, các vấn đề sau có thể nảy sinh từ phía các kỹ sư và nhà phát triển:

 Nhân viên kỹ thuật và người dùng cuối có thể có ngôn từ khác nhau Kết quả là họ có thể tin rằng họ hoàn toàn đồng thuận cho đến khi sản phẩm hoàn thiện được đưa ra.

 Các kỹ sư và nhà phát triển có thể cố lái cho các yêu cầu khớp với một hệ thống hay mô hình sẵn có, thay vì phát triển một hệ thống theo sát nhu cầu của khách hàng

 Việc phân tích có thể do các kỹ sư hoặc lập trình viên thực hiện, thay vì các nhân viên có kỹ năng và kiến thức miền ứng dụng để có thể hiểu các nhu cầu của khách hàng một cách đúng đắn

Trang 54

Một số hướng giao tiếp giữa

Ví dụ; yêu cầu đến từ người quản lý người

dùng cuối có thể phản ánh không chính xác nhu cầu thực của người dùng

Trang 55

Một số hướng giao tiếp giữa

Trang 56

Một số hướng giao tiếp giữa

Nên dưa các thuật ngữ nghiệp vụ (domain

terms) vào glossary

Trang 57

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 Who are your key stakeholders?

b How will you analyse and validate your

stakeholder list?

Exercise

57

Trang 58

Thực hành

Bạn là người quản lý sản phẩm cho một công ty công

cụ máy G iám đố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

1. Các stakeholder?

2. Phân tích và đánh giá các stakeholder?

Trang 59

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

Ngày đăng: 07/05/2017, 17:38

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w