Chào mừng đến báo cáo môn

quản lý dự án phần mềm

Nhóm 3
 Thành viên trong nhóm

Đỗ Thị Hương Giang

Mai Trung Kiên

Đoàn Thảo Linh Đoàn Mạnh Đình

Đặng Thị Trâm

 Chương I II
ƯỚC LƯỢNG VÀ XÂY DỰNG
DỰ TOÁN NGÂN SÁCH
 Nội dung chính
3.1. Đo và ước lượng các công việc
3.2. Xác định ngân quỹ và lựa chọn dự án
 Ước lượng dự án hiện là khâu yếu nhất hiện nay. Không
ước lượng được thì dự án rất dễ vỡ kế hoạch về thời gian và
tài chính
Thực tế không dự án nào có thể ước lượng chính xác, ước
lượng cần được thực hiện nhiều vòng. Mức ước lượng trong
giai đoạn xác định có thể sai tới 50-100%, trong giai đoạn,
còn trong giai đoạn thiết kế chi tiết chỉ còn 10-25%
Ước lượng chỉ có thể chính xác nếu phân rã được các vấn đề
nhỏ hơn, đó là kỹ thuật chia để trị (divide and conquer)
 3.1. Đo và ước lượng các công việc

Ước lượng công việc

Tester khi làm việc trong 1 dự án Web (rộng hơn là phần mềm) thì
thường sẽ tự đánh giá và ước tính thời gian làm việc của mình bằng nhiều
cách. Đa phần nhiều người sẽ sử dụng kinh nghiệm sẵn có, hoặc Tester nào
hiểu dự án rõ hơn, suy nghĩ logic hơn thì cũng dễ đưa ra sự ước lượng của
chính mình.
Thực ra có một kỹ thuật để giúp Tester ước tính thời gian làm việc của
mình một cách chính xác hơn. Chính xác hơn ở đây chỉ mang tính chất
tương đối và không phải lúc nào cũng đúng trong tất cả mọi trường hợp.
Thực tế là người Tester sẽ phải áp dụng cùng lúc nhiều kỹ thuật để giải
quyết bài toán của mình.
Là một Tester, hẳn bạn sẽ phải trả lời những câu hỏi cơ bản sau: Tại sao
phải làm việc này (ước lượng, đánh giá)? Ai sẽ là người làm việc này?
 Tester tự ước lượng thì làm gì?

Trước hết phải hiểu cho đúng khái niệm cơ bản này: Việc này (đưa ra
sự ước tính) bản chất là một quá trình so sánh và xử lý thông tin để sàng
lọc ra các kết quả mang tính chất gần đúng, không quá sai lệch so với thực
tế. Các kết quả sau khi được sàng lọc được sử dụng cho một mục đích đặc
biệt nào đó. Cho dù các thông tin đầu vào của chúng ta không đầy đủ,
không chắc chắn, không khả thi, và thậm chí là không bền vững. Nhắc lại,
nó là một quá trình. Quá trình tức là gồm nhiều bước.
Đó là khái niệm dễ hiểu nhất có thể. Vậy khi một Tester làm việc, họ sẽ
phải dự đoán, nhẩm tính xem thử với một lượng công việc như vậy, công
sức của họ phải bỏ ra là khoảng bao nhiêu (ngày, giờ, tháng, năm, hoặc cái
gì đó tương đương).
 Thỉnh thoảng việc này cũng mang tính chất tương đương với việc Dự
báo/Dự đoán trước. Tuy nhiên để đạt tới trình độ này đòi hỏi Tester phải làm việc
với nhiều dự án phức tạp, lớn bé khác nhau. Cần một thời gian đủ dài để Tester
có thể lãnh ngộ được khả năng Dự báo/Dự đoán này. Lấy ví dụ về chương trình
Dự báo thời tiết bạn có dễ hình dung không?
Thông thường thì Tester sẽ sử dụng cách đơn giản nhất là kinh nghiệm, kiến
thức của mình để tính toán. Mình nhắc lại hai từ: Tính toán. Vâng, bạn không
nhầm đâu. Nói cách khác, Sự ước lượng của bạn vốn dĩ là sự tính toán tổng hợp
dựa trên những yếu tố thường thấy sau:
 Kinh nghiệm cũ trước đó.
 Thông tin và kiến thức sẵn có trước đó.
 Tự đặt ra giả thuyết.
 Tính toán các rủi ro (Cấp độ này còn cao và nhiều thông tin chuyên sâu nên
không đề cập ở bài này).
 Vậy tại sao chúng ta – Tester – phải làm cái việc này?

Câu trả lời vô cùng đơn giản: Để lan toả sự hiểu biết và chúng ta có cảm giác
rằng dự án sẽ thành công. Nhưng sự thật không chỉ có thế. Khi chúng ta làm dự
án web hay sản phẩm web, chúng ta đều mong muốn trông thấy sản phẩm đó
chạy tốt đến mức nào, chúng ta có thể cảm nhận được bản thân cảm thấy hài
lòng thế nào khi tính năng đó chạy được hay không.
Làm web không phải chỉ đơn giản là lập trình, xây tính năng. Làm web còn là
một quá trình win-win: Bạn ước lượng, bạn học được giá trị nào đó khi việc đã
xảy ra. Cứ thế, nó tiếp tục phát triển.
Đây mới là ý nghĩa thực sự của việc một Tester làm việc gọi là Ước lượng.
 1.Kỹ thuật cơ bản

Một số yêu cầu đầu vào được gọi là kim chỉ nam bỏ túi của Tester:
 Kiểm tra kỹ tất cả các yêu cầu của dự án đã được xác nhận hay chưa.
 Nếu chưa thì xem lại tần suất thay đổi của các yêu cầu này (có thể tầm
2-3 tuần là cập nhật 1 lần).
 Các mong muốn về kết quả trả về của yêu cầu đều rõ ràng.
 Kiểm tra xem các yêu cầu không cần thiết phải test.
 Kiểm tra lần cuối các giả thuyết từ yêu cầu đều rõ ràng và được xác
nhận.
 Done. Mời bạn tham khảo 4 kỹ thuật cơ bản dưới đây. Thông tin mang
tính lý thuyết chút và không đi chuyên sâu về thực hành.
 2. Kỹ thuật Delphi

Cái này thì không cần thiết phải biết sâu làm
gì, vốn dĩ nó được sử dụng cho phần mềm nhiều
hơn, do tính chất đặc thù của nó. Việc áp dụng
phương pháp này nó chỉ phù hợp ở các công ty
dạng enterprise hoặc có định hướng về làm
Research chuyên nghiệp. Khi đó các phương pháp
research có thể áp dụng một cách hiệu quả vào kỹ
thuật Delphi này.
Cơ bản phương pháp này dùng survey, gởi cho các chuyên gia và tiến hành xoay
vòng để thu thập thông tin. Thường thì nếu có kinh nghiệm lâu dài thì có thể áp dụng
kỹ thuật này với các phương pháp khác cho hiệu quả.
Tất nhiên, Tester làm Web thì không cần dùng cái này rồi. Chi tiết mời bạn tra
Google và nghiên cứu thêm để mở mang.
3. Kỹ thuật WBS (Work Breakdown Structure)

Cái này hiện nhóm ET Product chúng

ta đang sử dụng ở cấp độ đơn giản và
mang tính chất vay mượn từ các dự án
phần mềm đặc thù. Tóm tắt thì WBS nên
hiểu như sau: Một tính năng lớn nên
được chia làm nhiều công việc nhỏ hơn.
Mỗi một công việc nhỏ như vậy khi chia
ra nên đủ nhỏ để đảm bảo rằng mình có
thể hoàn tất nó trong khả năng của mình
(100%).
 4. Kỹ thuật tam giác (3 point)
Cái này có công thức như sau: (Thời gian ước
lượng) = Thời gian lý tưởng + (4*Thời gian tối ưu) + Thời
gian chậm nhất / 6
Cái này cũng tương tự WBS là chia nhỏ việc ra,
nhưng khác ở chỗ đơn vị tính là ngày, giờ duy nhất. Ở trên
kia thì WBS có thể tính theo đủ kiểu mình muốn. Một điểm
chú ý là để phán đoán được 3 loại thời gian trong công
thức trên thì cần kết hợp kinh nghiệm và kiến thức của
bản thân để đưa ra con số phù hợp.

Ngày nay thì các kỹ thuật như Planning Poker và Delphi là rất phổ biến. Chúng ta rất có
thể sẽ không bao giờ có cơ hội thực hiện kỹ thuật Delphi này vì nó tốn kém và tốn thời gian.
Rất may là ET đã và đang áp dụng kỹ thuật còn lại là Planning Poker hehe.
Ở khía cạnh công việc thì có một số tool hỗ trợ sẵn kỹ thuật này, nó tự tính toán giúp
chúng ta luôn. JIRA là 1 tool như vậy.
 5. Kỹ thuật ước lượng dựa trên chức năng của dự án

Cái này cũng khó có cái tên tiếng Việt chính xác và ngắn gọn. Nôm na là Tester sẽ
kiểm tra dựa trên bộ tài liệu mô tả/yêu cầu, bản thiết kế, vân vân. Hình thức ước lượng
này sẽ dựa trên quan điểm của người dùng nhiều hơn.
Lấy ví dụ: ước lượng 1 tính năng tầm 3 ngày sử dụng kỹ thuật tam giác ở trên.
Tester còn nghĩ rằng người dùng sẽ dễ gây ra lỗi này ở vị trí X nào đó. Thế là phải thêm
tầm 2 ngày nữa để hoàn tất. Vị chi là 5 ngày. À mà quên, đây chỉ là ví dụ thôi. Có 3 cấp
độ ở kỹ thuật này: Phức tạp, Trung bình, Đơn giản. Mỗi cấp độ sẽ có các tiêu chí chấm
điểm khác nhau. Chúng ta sẽ có 5 nhóm chính, mỗi nhóm sẽ được cho điểm tương ứng
với 3 cấp độ trên.
Kỹ thuật cuối này thì ít được áp dụng nhất ở Việt Nam, một là do nó phức tạp,
hai là nó cần phải được thực nghiệm thời gian dài trước khi có được các bước làm
thực tiễn nhất.
 3.2. Xác định ngân quỹ và lựa chọn dự án

Chi phí và quản lý chi phí DA là gì?

Chi phí là tài nguyên đem vào sử dụng, tiêu hao kết chuyển giá trị vào
sản phẩm mong đợi.
Chi phí thường được đo bằng đơn vị tiền tệ
Quản lý chi phí dự án bao gồm các quy trình cần thiết để đảm bảo
rằng dự án được hoàn thành trong ngân sách đã được phê duyệt
 Quy trình quản lý chi phí DA

- Lập kế hoạch:
+ Ước tính chi phí
Output: Ước tính chi phí các hoạt động, cơ sở ước tính, cập nhật tài liệu dự
án
+ Xác định ngân sách
Output: Chi phí thực hiện cơ bản, yêu cầu tài trợ dự án, cập nhật tài liệu sản
phẩm
- Giám sát và kiểm soát: Kiểm soát chi phí
Output: Đo lường hiệu suất công việc, dự báo ngân sách, cập nhật tài sản quy
trình tổ chức, yêu cầu thay đổi, cập nhật kế hoạch quản lý dự án, cập nhật tài
liệu dự án
 Một số khái niệm cơ bản:

Lợi nhuận (Profits): Chênh lệch giữa doanh thu từ việc bán sản phẩm hàng hoá, cung cấp dịch
vụ với tổng giá thành toàn bộ sản phẩm, hàng hoá tiêu thụ hoặc chi phí dịch vụ tiêu thụ trong kỳ;
Tỷ suất lợi nhuận (Profit margin): là một tỷ số tài chính dùng để theo dõi tình hình sinh lợi của
dự án
Chi phí hữu hình hoặc lợi ích có thể đo lường bằng tiền
Chi phí vô hình khó có thể đo lường bằng tiền
Chi phí trực tiếp
Chi phí gián tiếp
Chi phí chìm là tiền đã được chi tiêu trong quá khứ; khi quyết định đầu tư hoặc tiếp tục DA,
không nên tính bao gồm chi phí chìm
Theo curve theory, mặt hàng được sản xuất lặp đi lặp lại, trong mô hình nhiều đơn vị được sản
xuất thường xuyên thì đơn giá giảm.
Dự trữ được ước tính để giảm thiểu rủi ro chi phí:
+ Khoản dự phòng cho phép các tình huống trong tương lai được lên kế hoạch một phần (ẩn số
đã biết).
+ Quản lý dự trữ cho phép các tình huống trong tương lai có thể đoán trước (đôi khi được gọi là
ẩn số chưa biết).
 3.2.1. Ước tính chi phí:

Quản lý dự án phải có dự toán chi phí một cách nghiêm túc nếu muốn hoàn thành dự án
trong phạm vi ràng buộc ngân sách.
Điều quan trọng là phải biết các loại dự toán chi phí, làm thế nào để chuẩn bị dự toán và các
vấn đề điển hình liên quan đến dự toán chi phí IT
Các loại dự toán chi phí
Kế hoạch quản lý chi phí:
- Kế hoạch quản lý chi phí là một tài liệu mô tả cách tổ chức sẽ quản lý chi phí chênh lệch của
dự án
- Phần lớn trong tổng chi phí dự án thường là chi phí cho nguồn lao động
 Công cụ và kỹ thuật cơ bản ước tính chi phí

1. Ước lượng chính quy

- Ước lượng chính quy dựa trên sự phân tích. Gồm:
 Danh sách các giả định được sử dụng trong việc xây dựng các ước lượng
 Phạm vi biến động cho ước lượng
 Khoảng thời gian ước lượng có hiệu lực
- Ước lượng không chính quy sử dụng suy đoán, phỏng đoán và bản năng
2. Ước tính sử dụng kết quả chào thầu.
3. Thông tin lịch sử hay cơ sở dữ liệu dự án: Thông tin lịch sử bao gồm:
 Báo cáo sự cố
 Yêu cầu kỹ thuật, chức năng và nghiệp vụ
 Kinh phí dự án
 Cấu trúc chi tiết công việc
 Chi phí thực và dữ liệu hiệu suất theo lịch trình
 Bài học thu được
4. Ước tính theo giai đoạn: là kỹ thuật ước tính chi phí và lịch trình riêng cho từng
giai đoạn của dự án.
Công cụ và kỹ thuật cơ bản ước tính chi phí

5. Ước tính từ trên xuống: Ước tính bắt đầu cho toàn bộ dự án sau đó chia ra
thành tỉ lệ đối với mỗi giai đoạn hay loại công việc dự án
6. Ước tính từ dưới lên: liên quan đến dự toán hạng mục công trình hoặc các hoạt
động cá nhân và tổng hợp chúng để có được tổng thể dự án
7. Ước tính theo tham số:
- Các DA lớn được tách thành các đơn vị công việc nhỏ và đưa vào một mô hình
toán học. Có 3 nguồn vào then chốt:
 Thông tin lịch sử bằng đơn vị công việc làm cơ sở
 Tập hợp các đặc tính, yêu cầu và kế hoạch chi tiết
 Mô hình toán học được xây dựng cẩn thận – công thức theo tham số biểu diễn mối
quan hệ công việc
- Một số phương pháp ước lượng theo tham số phổ biến hiện nay: COCOMO (dựa
trên Kilo Lines of Code); COSMIC FFP; Function Point; UseCase Point; Feature
Point…
 Các vấn đề điển hình với dự toán chi phí IT

 Các ước tính được thực hiện quá nhanh

 Thiếu kinh nghiệm ước lượng
 Con người bị đánh giá quá thấp
 Quản lý mong muốn chính xác
Ước tính chi phí mẫu

 Thu thập càng nhiều thông tin càng tốt

 Nếu có thể, ước tính chi phí theo các mục chính trong WBS
 Tạo ra một mô hình chi phí với khả năng dễ dàng thay đổi và lập tài liệu dự
toán
 3.2.2. Xác định ngân sách
Ngân sách liên quan đến việc phân bổ dự toán chi phí cho từng hạng mục công việc theo thời gian
dự án
 WBS là một đầu vào cần thiết cho quá trình chi ngân sách
 Mục tiêu quan trọng là tạo ra một cơ sở chi phí
 Ngân sách theo từng giai đoạn, các nhà quản lý dự án sử dụng để đo lường và giám sát hiệu suất chi
phí
Cơ sở chi phí
Cảm ơn các bạn đã
lắng nghe