Business Analyst Sử Dụng Các Scope Model để Quản Lý Phạm Vi Của ...

Có thể bạn quan tâm

Agree & Join LinkedIn

By clicking Continue to join or sign in, you agree to LinkedIn’s User Agreement, Privacy Policy, and Cookie Policy.

Create your free account or sign in to continue your search

Welcome back

Email or phone Password Show Forgot password? Sign in

By clicking Continue to join or sign in, you agree to LinkedIn’s User Agreement, Privacy Policy, and Cookie Policy.

New to LinkedIn? Join now

By clicking Continue to join or sign in, you agree to LinkedIn’s User Agreement, Privacy Policy, and Cookie Policy.

LinkedIn is better on the app

Don’t have the app? Get it in the Microsoft Store.

Open the app Skip to main content

Business Analyst sử dụng các Scope Model để quản lý phạm vi của giải pháp như thế nào?

Việc kiểm soát phạm vi của giải pháp là công việc quan trọng của một Business Analyst chuyên nghiệp. Nhà phân tích kinh doanh sử dụng mô hình hóa quản lý phạm vi giải pháp quản lý như thế nào? Đôi khi công việc này sẽ trở nên phức tạp hơn rất nhiều với các dự án có phạm vi lớn, các thông tin về yêu cầu và giải pháp có thể được viết ra nhiều hơn vài trăm trang giấy. Cùng với lượng thông tin lớn như vậy thì việc quản lý phạm vi trở nên phức tạp hơp, gây nhiều khó khăn trong việc quản lý, truyền tải thông tin đến các stakeholder và thành viên của đội dự án.

Đọc thêm: Những kỹ năng quan trọng cho Business Analyst mới vào nghề

Nhiều Business Analyst dày dạn kinh nghiệm thường dùng cách áp dụng các Scope Model khác nhau để tài liệu hoá phạm vi của giải pháp. Những models này sẽ giúp cho các stakeholder và thành viên của đội dự án có một tầm nhìn rõ ràng hơn về giải pháp, bên cạnh đó sẽ giúp stakeholder dễ dàng đưa ra các quan điểm của mình trong quá trình xét duyệt các giải pháp, thành viên của đội dự án cũng sẽ hình dung rõ ràng hơn để đưa ra chiến lược phát triển và tích hợp tốt nhất,…

Đọc thêm: Những đặc điểm của một chuyên viên phân tích kinh doanh cao cấp

Chúng tôi xin giới thiệu với bạn một số mô hình mà các chuyên viên phân tích nghiệp vụ, phân tích hệ thống chuyên nghiệp thường dùng để quản lý phạm vi của giải pháp.

1) Context Diagram: mô tả bối cảnh của hệ thống, bao gồm các thực thể bên ngoài tương tác với hệ thống. Các thực thể bên ngoài này có thể là các hệ thống khác, các service, hoặc các đơn vị kinh doanh (yếu tố con người), hoặc các database, … Mô hình này cũng giúp xác định các dòng dữ liệu giữa các thực thể bên ngoài và hệ thống chính, và mô tả hướng đi của mỗi dòng dữ liệu. Giới hạn của mô hình này là chỉ mô tả thực thể bên ngoài tương tác trực tiếp với hệ thống dưới dạng khám phá.

2) Functional Decomposition (hay còn gọi là mô hình phân rã chức năng): mô tả một chủ đề được phân rã thành các chủ thể nhỏ hơn. Việc phân rã có thể có nhiều cấp độ tuỳ thuộc phạm vi của chủ đề, có nghĩ là phân rã từ chủ đề xuống các thành phần lớn, và tiếp tục phân rã các thành phần lớn đó thành các thành phần nhỏ hơn. Công việc phân rã chỉ được hoàn thành khi số cấp độ đạt từ ba đến bốn cấp độ.

Việc phân rã nhỏ các thành phần sẽ giúp bạn kiểm soát tốt khối lượng công việc ở mức độ nhỏ, có thể ước lượng được và tìm ra các rủi ro tiềm ẩn bên trong mỗi chủ đề. Kỹ thuật này cũng rất hữu dụng để tạo ra work breakdown structure – WBS và đưa ra ước lượng phù hợp.

3) Process Flow: là sơ đồ dòng chảy của các quy trình được minh hoạ ở mức tổng thể và các đối tượng liên quan đến những quy trình. Một số mô hình dòng chảy phổ biến được gọi là swimlane. Sơ đồ swimlane cho thấy các quá trình hiện ra trên một hàng hoặc nhiều hàng trong một tiến trình thực hiện của hệ thống. Các đường line sẽ kết nối các thực thể giúp bạn thấy rõ sự tương tác giữa các thực thể và sự phụ thuộc của các thực thể với nhau như hình bên dưới.

4) Ecosystem Map: chỉ ra hệ thống dưới góc độ khám phá và hệ thống mà việc gởi nhận thông tin từ hệ thống. Sự khác biệt lớn giữa các mô hình này và mô hình context diagram là các bản đồ hệ sinh thái sẽ hiển thị các hệ thống không tương tác trực tiếp với hệ thống theo phát hiện; đó là hệ thống thượng nguồn và hạ nguồn.

Hình dưới đây là một ví dụ: một hệ thống nhập lệnh từ trang web sẽ không gửi đơn đặt hàng cho các hệ thống thực hiện đơn hàng, mà sẽ gửi dữ liệu sản phẩm vào hệ thống tồn kho và hệ thống thu mua. Các hệ thống kiểm kê sẽ gửi các giao dịch hàng tồn kho đến hệ thống kế toán. Hệ thống kế toán cũng nhận lệnh các giao dịch từ hệ thống thu mua. Mặc dù hệ thống thực hiện đơn hàng không tương tác trực tiếp với hệ thống kế toán, đó là cả hai cùng tồn tại trong một hệ sinh thái; và do đó, sẽ được thể hiện trên bản đồ hệ sinh thái. Các hệ thống theo sự khám phá này sẽ được hiển thị với một phác thảo táo bạo hơn so với các hệ thống khác trong bản đồ hệ sinh thái.

5) Use Case Diagram: là một sơ đồ mô tả trực quan phạm vi của giải pháp, bằng cách hiển thị các Một Use Case Diagram có thể xác định các loại khác nhau của người sử dụng một hệ thống và các chức năng khác nhau với những người dùng thực hiện sử dụng hệ thống.

6) Feature Tree: chính là fishbone diagram cho phép trình bày các tính năng bên trong hệ thống. Nó cũng gần giống vớ mô hình phân rã chức năng – functional decomposition. Feature Tree phân chia các tính năng ở mức chung thành các tính năng ở mức nhỏ hơn.

Đọc thêm: Kỹ thuật phân tích phân tích nguyên nhân gốc rễ (Root Cause Analysis)

Không có lý do gì để vượt qua ba cấp độ của tính năng, bạn có thể mã hoá màu sắc dùng để thể hiện những tính năng nào đang nằm trong phạm vi cho phép, những tính năng nào đang vượt ra khỏi phạm vi cho phép đó hoặc các tính năng của phiên bản tương lai. Đây là mô hình lý tưởng cho các giám đốc sản phẩm hoặc các quản lý cấp cao, những hình ảnh rõ ràng sẽ giúp nhận ra một sự hiểu biết nhanh chóng và đưa ra kế hoạch phù hợp để phát triển tính năng.

Nguồn: apexglobal.com.vn

> Đọc thêm

Like Like Celebrate Support Love Insightful Funny Comment Share 2 Comments Dung Nguyen Thanh, graphic

Business Analyst Sử Dụng Các Scope Model để Quản Lý Phạm Vi Của ...

Welcome back

More articles by Giang Nguyen Duc

ITIL Service Design là gì? Service Design mang lại giá trị gì?

ITIL Service Strategy là gì? Service Strategy mang lại giá trị gì?

Đào tạo ITIL Service Operation tại Việt Nam

Workshop: User Story Thực Chiến

Đào tạo ITIL Expert đâu tiên ở Việt Nam

CÁCH ĐẶT CÂU HỎI ĐÚNG

Bạn đang tìm hiểu Agile là gì? Scrum là gì?

ITIL là gì? Tại sao cần học ITIL?

Business Analyst là ai? Business Analyst làm gì trong doanh nghiệp?

Tại sao IIBA lại thay đổi định nghĩa về Business Analysis trong cuốn BABOK v3 mới nhất?

Explore content categories

Mô Hình Hóa Kiến Trúc Phần Mềm Với C4 - Viblo

Tạo Kiến Trúc Phân Mềm Tinh Gọn Nhất Với C4 Model

The C4 Model For Software Architecture - InfoQ

What Is A C4 Model? How To Make C4 Software Architecture Diagrams

Lập Sơ đồ Microservices Với Mô Hình C4 - HelpEx

Ghi Lại Kiến trúc Của Các Dự án Của Bạn Với Mô Hình C4

4+1 Architectural View Model - Wikipedia

C4.5 Hỏi Gì đáp Nấy - Ông Xuân Hồng

Kích Thước Khổ Giấy C – Phong Bì | C0, C1, C2, C3, C4, C5, C6, C7 ...

Liên Hệ

Sign in to view more content

Welcome back

More articles by Giang Nguyen Duc

ITIL Service Design là gì? Service Design mang lại giá trị gì?

ITIL Service Strategy là gì? Service Strategy mang lại giá trị gì?

Đào tạo ITIL Service Operation tại Việt Nam

Workshop: User Story Thực Chiến

Đào tạo ITIL Expert đâu tiên ở Việt Nam

CÁCH ĐẶT CÂU HỎI ĐÚNG

Bạn đang tìm hiểu Agile là gì? Scrum là gì?

ITIL là gì? Tại sao cần học ITIL?

Business Analyst là ai? Business Analyst làm gì trong doanh nghiệp?

Tại sao IIBA lại thay đổi định nghĩa về Business Analysis trong cuốn BABOK v3 mới nhất?

Explore content categories

Liên Hệ