BÀI TẬP TL MÔN QLDA CNTT IT 22 028

TRƯỜNG ĐẠI HỌC MỞ HÀ NỘI

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

TRUNG TÂM ĐÀO TẠO TRỰC TUYẾN

Độc lập – Tự Do – Hạnh phúc

***
ĐỀ SỐ: 02
BÀI KIỂM TRA TỰ LUẬN
Học phần: QLDA CNTT
Họ tên: LÊ CÔNG KIÊN. Ngày sinh: 03/02/1976. Tài khoản học tập: kienlc
Lớp: CVP313. Mã số SV: 20C-10-42.3-02367
Câu hỏi 2: Trình bầy khái niệm, ý nghĩa của WBS. WBS nên được chia nhỏ đến
mức độ nào? Cho ví dụ
Trả lời:
a/ Khái niệm, ý nghĩa của WBS:
WBS là một danh sách chi tiết các bước cần để hoàn thánh một dự án. Nó cung cấp
nhiều lợi ích cho người quản lý dự án. Việc xây dựng WBS buộc người quản lý dự án
phải cố gắng tư duy để hiều những cái sẽ phải làm để kết thúc dự án. Nếu phân tích
đúng đắn, khoa học, nó cho phép xác định các bước chính xác để làm xong dự án.
WBS thiết lập nền tảng hệ thống hóa các cơng việc vững chắc, làm cơ sở cho các
ước lượng thời gian và chi phí hiện thực. Danh sách chi tiết các nhiệm vụ tạo điều kiện
cho tính chi phí riêng cho các hoạt động và toàn bộ dự án. Bằng việc làm các ước lượng
thời gian cho các nhiệm vụ chi tiết, người quản lý dự án có thể " tích lũy " dữ liệu liên
kết với từng mức của WBS để xây dựng một bức tranh hợp thành, chỉnh thể về dự án.
Một WBS tốt cũng cho phép người quản lý dự án xây dựng việc giải trình giữa các
thành viên tổ dự án. Sau khi liệt kê tất cả các nhiệm vụ người quản lý dự án có thể phân
công công việc cho từng người. Điều này thể hiện khơng khí dân chủ, thẳng thắn, đầy
trách nhiệm và giải trình giữa các thành viên tổ.

Người quản lý dự án có thể dùng WBS để xây dựng lịch biểu hữu dụng. Một danh sách
cụ thể các nhiệm vụ, làm cơ sở cho các ước lượng hiện thực và việc xây dựng cuối cùng


về các lịch biểu. Bên cạnh đó, nó làm cho người quản lý dự án có khả năng phát triển
các lịch biểu, được biết đến như lịch biểu tầng.
Cuối cùng, việc xây dựng một WBS tốt buộc các vấn đề cơ bản sớm nảy sinh trong dự
án thay vì muộn ( Khi cịn khó khăn hơn để thay đổi tình huống ). Việc xây dựng WBS
địi hỏi những đóng góp đáng kể từ những người tham dự dự án ( Như: người quản lý
dự án, khách hàng, thành viên tổ, người tài trợ dự án và quản lý cấp cao ).
Các đặc trưng của WBS
Đặc trưng chính của WBS là có khuynh hướng trên xuống. Người quản lý dự án bắt
đầu với sản phẩm cuối cùng và chia nó ra thành những yếu tố nhỏ hơn, các sản phẩm
trung gian hay sản phẩm con. Hình dưới chỉ ra việc tổ chức này của WBS.
Việc chia ra là rất giống với việc chuẩn bị dàn bài cho một bài văn. Mỗi chủ đề đều
được chia thành những chủ đề con, và mỗi chủ đề con lại được chia thêm nữa thành các
cấu phần.

Một đặc trưng khác của WBS là được tách thành nhiều mức. Không phải tất cả " nhánh
" của WBS đều cần bung ra hết. Bản thân mức là khơng có ý nghĩa chính. Mỗi mức đơn
giản cho phép bạn tạo ra lịch biểu và báo cáo tóm tắt thơng tin tại từng mức đó.


Câu hỏi đặt ra là WBS để lộ ra cái gì? Trình tự của từng nhiệm vụ là khơng quan trọng.
Mặc dầu mọi người quen đọc từ trái sang phải, khơng có trình tự nào cần được suy diễn
ra cả. Nếu bạn nghĩ theo kiểu trình tự thì việc xây dựng WBS có thể sẽ rất nản lịng. Nó
buộc bạn phải nghĩ về cái gì cần được làm, thay vì khi nào nó cần được làm. Bạn có thể
đưa vào các cách thức và khi nào cho các nhiệm vụ sau khi cấu trúc nên WBS, tức là
khi bạn xây dựng lịch biểu

Quá trình phân rã (Decomposition)
Những phụ thuộc phức tạp trong các dự án CNTT đòi hỏi tất cả các cơng việc phải
được định nghĩa để có thể vạch ra chính xác mối tương tác giữa chúng. Nhất thiết phải
phân tách các kết quả chuyển giao ở cấp cao thành những gói cơng việc dễ quản lý và
phân cơng nhằm lập ra các sơ đồ mạng, tính tốn và phân tích đường tới hạn, phác thảo
lịch trình và ngân sách.
Cấu trúc chi tiết công việc WBS xác định phạm vi của dự án bằng cách liệt kê ra tất
cả những dự án nhỏ (sub-project) hoặc những kết quả chuyển giao trong một dự án.
Công tác phân tách cấu trúc chi tiết công việc là việc đội dự án phân tách những dự án
nhỏ hoặc những kết quả chuyển giao thành những cơng việc cấu thành và các gói cơng
việc cần thiết để thực hiện dự án.
Một cấu trúc chi tiết công việc được coi là đã phân tách khi:


-

Các cơng việc cấu thành (component tasks) hoặc các gói cơng việc phải là những

việc duy nhất có thể phân biệt được với các công việc khác và dễ xác định bởi những
người sẽ thực hiện cơng việc, ví dụ "nâng cấp Cửa hàng số 7" chứ không phải là "nâng
cấp địa điểm bán lẻ".
-

Các công việc cấu thành hoặc các gói cơng việc phải có thời gian được xác định rõ

ràng hoặc một nỗ lực có thể lập lịch được.
-

Các cơng việc cấu thành và các gói cơng việc phải đủ cụ thể để thiết lập các giới

hạn chi phí và lịch trình bằng các metric chung như đơ la hoặc số giờ làm việc.
-

Trách nhiệm và thẩm quyền đối với các cơng việc cấu thành hoặc gói cơng việc có

thể được giao cho một người hoặc một nhóm.
-

Cần thiết phải phân tách một cấu trúc chi tiết công việc mức cao thành những gói

cơng việc có thể quản lý và phân cơng được vì cấu trúc chi tiết công việc là một tài liệu
đầu vào quan trọng đối với rất nhiều tài liệu kế hoạch dự án cần được xây dựng.
Cấu phần của WBS
WBS bao gồm 2 cấu phần chính. Phần thứ nhất của WBS được gọi là cấu trúc sản
phẩm (PBS). PBS giống như WBS nói chung, địi hỏi lấy viễn cảnh trên xuống. Hình
trên minh họa cho cấu trúc phần sản phẩm.
Lần nữa việc chia ra này của PBS là tương tự với dàn bài của bài văn - mỗi chủ đề
được chia thành các chủ đề con và mỗi chủ đề con lại được chia nhỏ thêm thành các cấu
phần. Mức độ bung ra tùy theo mức độ phức tạp của sản phẩm. Nói chung sản phẩm
càng phức tạp thì số các mức càng lớn hơn.
PBS cũng chiếm phần trên của cấu trúc phân việc. Mỗi nhánh của PBS lại được phân
nhỏ hơn thành các mức khác nhau. Sản phẩm toàn bộ và từng sản phẩm con được mô tả
bằng danh từ hay chủ ngữ.


Phần thứ hai của WBS được gọi là cấu trúc phân nhiệm vụ, cũng cịn được biết là
TBS. Nó bao gồm các nhiệm vụ, nhiệm vụ con để xây dựng từng sản phẩm con và
chung cuộc xây dựng nên sản phẩm toàn bộ.
TBS, cũng giống như PBS. Được chia thành nhiều mức và địi hỏi viễn cảnh trên
xuống. Hình trên chỉ ra cấu trúc phân nhiệm vụ. Số mức của việc bung ra tùy thuộc vào

độ phức tạp của sản phẩm tồn bộ hay sản phẩm con. Nói chung dự án càng phức tạp thì
lại càng cần nhiều mức.
TBS khơng giống PBS, nó chiếm phần thấp hơn của WBS. Mỗi nhánh của TBS có
thể được chia thành các mức khác nhau. Mỗi nhiệm vụ và các yếu tố thấp hơn đều được
mô tả bằng động từ ra lệnh ( động từ hành động ) và một bổ ngữ. Do đó một TBS bao
gồm phần xác định ( động từ ra lệnh ) và phần xử lý ( bổ ngữ ). Nếu gộp cả 2 sẽ cho ta
phần vị ngữ trong một câu mà chủ ngữ là các PBS.
Trong một số cơng ty, phần PBS trước nhất cịn động từ hoạt động thì được thêm vào
phía trước danh từ. Mỗi nhiệm vụ tiếp đó được bung ra thành các mức chi tiết hơn. Đặc
trưng khác ở chỗ mỗi khoản mục trong WBS ( cả phần PBS và TBS ) đều có số duy
nhất, hay mã. Số này định danh vị trí, hay mức của phần từ bên trong WBS.
Hãy xét ví dụ được nêu trong hình dưới đây:


Không phần tử nào được liệt kê trong WBS lại có cùng số hay mã, và khi bạn tiến
xuống các mức thấp hơn thì số trở lên lớn hơn.
b/ WBS nên được chia nhỏ đến mức đợ nào? Cho ví dụ
Sử dụng kỹ thuật phân rã để chia tách các sản phẩm/công việc mức cao hơn thành
các sản phẩm/công việc mức thấp hơn. Có thể phân rã theo nhiều mức, mức độ phân rã
tùy thuộc vào độ lớn và độ phức tạp của dự án.
Cần chia tách công việc đến mức thấp nhất để có thể ước tính được thời gian, chi
phí cho cơng việc, giám sát và kiểm sốt được khi thực hiện. Các công việc được chia
tách ở mức thấp nhất sau đây gọi chung là công việc. Các cơng việc có mối quan hệ
logic với nhau được tiến hành để tạo ra một sản phẩm trung gian gọi chung là nhóm
cơng việc.
Cấu trúc phân chia cơng việc là tập hợp của danh sách các sản phẩm và danh sách
các công việc. Các bước tạo các danh sách này gồm:


- Xác định các sản phẩm trung gian; Lập danh sách sản phẩm;

- Xác định các công việc;
- Lập danh sách công việc.
Mỗi sản phẩm, công việc trong WBS cần được gán một mã duy nhất, gọi là mã định
danh. Mã định danh nên được thiết lập theo dạng phân cấp tương ứng với cấu trúc của
WBS. Mã định danh sẽ giúp kiểm sốt phạm vi, ngân sách, chi phí thực tế, và lịch trình
tốt hơn, đặc biệt khi sử dụng các cơng cụ hỗ trợ.
 Trình tự phân rã:
1) Phân rã các sản phẩm
- Phân rã từ sản phẩm chung nhất (sản phẩm cuối cùng) thành các sản phẩm ở
mức thấp hơn;
- Phân rã tiếp tục các sản phẩm ở mức thấp hơn cho tới mức thấp nhất có thể.
- Lập thành danh sách các sản phẩm vừa được phân rã
2) Phân rã các công việc
- Phân rã các công việc (ở dưới sản phẩm mức thấp nhất) thành các công việc ở
mức thấp hơn;
- Phân rã tiếp tục các công việc mức thấp hơn cho tới mức cuối cùng (mức lá).
- Lập thành danh sách các công việc vừa được phân rã.
 Yêu cầu của phân rã công việc
Vấn đề đặt ra, cơng việc đến mức nào thì dừng? Do vậy yêu cầu chung khi phân rã
công việc là:
 Rõ ràng, dễ hiểu, dễ định nghĩa khi cần;
 Tính khả thi: Có thực hiện được bởi một cá nhân hoặc một nhóm, trong
điều kiện của dự án và/hoặc với trang thiết bị dự án có thể đáp ứng;
 Thời gian: Có thể ước lượng được thời gian thực hiện bởi cá nhân/nhóm;
 Chi phí: Có thể tính được giá thành của cơng việc;
 Có thể lập được lịch biểu phù hợp với tiến trình chung của dự án (xác định
được thời điểm bắt đầu, kết thúc);
Nhìn chung một cơng việc có thời gian ước tính nhiều hơn 2 tuần (hoặc 80 giờ) thì
nên phân rã tiếp.

Mức cuối cùng (mức lá) sẽ toàn bộ là các công việc. Các công việc mức lá là
những công việc mà có thể dễ ước lượng được thời gian và chi phí. Đây chính là cách
phân rã kiểu top-downKhi cơng việc được phân rã chi tiết, khả năng lập kế hoạch, quản
lý và kiểm sốt cơng việc được nâng cao. Tuy nhiên, phân rã quá mức có thể dẫn đến
vụn vặt, sử dụng không hiệu quả các nguồn lực, giảm hiệu quả trong việc thực hiện
cơng việc và khó tổng hợp số liệu.
Ví dụ: Dự án xây dựng “Hệ thống quản lý DT”
WBS của dự án được thiết lập theo phận sự trách nhiệm. Sử dụng công cụ
phân rã để phân chia các hoạt động của dự án và tập hợp thành một bảng WBS
được mô tả như sau:
0

Hệ thống quản lý DT
(1)

1

Quản lý dự án

1.1

Lập kế hoạch

1.2

Tổ chức các cuộc họp

1.3

Điều hành dự án

2

Phân tích

2.1

Lập Tài liệu xác định yêu cầu

2.2

Khảo sát chi tiết

2.3

Lập Tài liệu đặc tả yêu cầu

3

Thiết kế

3.1

Thiết kế tổng thể

3.2

Thiết kế chi tiết

4

Xây dựng hệ thống

5

Tích hợp và kiểm thử chấp nhận

5.1

Tích hợp hệ thống

5.2

Kiểm thử chấp nhận


6

Vận hành hệ thống

6.1

Đào tạo người dùng

6.2

Hỗ trợ khách hàng

6.3

Hoàn thiện sản phẩm

7

Kết thúc dự án