Sử dụng tri thức trong việc phát triển các dự án công nghệ thông tin luận văn ths công nghệ thông tin 1 01 10 pdf

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

THẠCH HÒANG VIỆT

SỬ DỤNG TRI THỨC
TRONG VIỆC PHÁT TRIỂN
CÁC DỰ ÁN CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠCH SỸ

HÀ NỘI 2007

3


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

THẠCH HÒANG VIỆT

SỬ DỤNG TRÍ THỨC TRONG VIỆC PHÁT TRIỂN CÁC DỰ ÁN

CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠCH SỸ CÔNG NGHỆ THÔNG TIN
MÃ SỐ: 0.01.10

Người Hướng Dẫn : PGS .TS.

HÀ NỘI 2007

4


MỤC LỤC

BẢNG CÁC KÝ HIỆU VIẾT TẮT .................................................................. 7
MỞ ĐẦU....................................................................................................... 9
CHƢƠNG 1.
1.1

QUẢN LÝ QUÁ TRÌNH PHÁT TRIỂN DỰ ÁN ................... 10

Lập kế hoạch dự án ....................................................................... 10

1.1.1 Lập kế hoạch dự án ................................................................. 10
1.1.2 Tính toán lợi nhuận của dự án................................................. 10
1.2

Lập kế hoạch, quản lý và đánh giá chất lƣợng ........................... 11

1.2.1 Triển khai chức năng chất lượng ............................................. 11
1.2.2 Chất lượng phần mềm ............................................................. 11
1.2.3 Đặc trưng chất lượng phần mềm ............................................. 12
1.3

Quản lý tiến trình ............................................................................ 14

1.3.1 Tổng quan về lập kế hoạch tiến trình và quản lý tiến độ .......... 14
1.3.2 Lập kế hoạch tiến trình ............................................................ 15

1.3.3 Quản lý tiến trình ..................................................................... 16
1.4

Năng suất phần mềm ..................................................................... 18

1.4.1 Về ước lượng .......................................................................... 18
1.4.2 Các phương pháp ước lượng .................................................. 18
1.5

Tổ chức phát triển.......................................................................... 21

1.5.1 Các phong cách tổ chức .......................................................... 22
1.5.2 Tổ chức phát triển .................................................................... 23
1.6

Kết luận ........................................................................................... 27

CHƢƠNG 2.
2.1

LÝ THUYẾT CHẮC CHẮN ................................................. 28

Tổng quan về lý thuyết chắc chắn ................................................ 28

2.1.1 Lập luận không chính xác trong MYCIN .................................. 28
2.1.2 Thể hiện dấu hiệu không chắc chắn ........................................ 29
2.1.3 Thể hiện các luật không chắc chắn ......................................... 29
2.1.4 Suy luận không chắc chắn ....................................................... 29
2.1.5 Tổ hợp dấu hiệu từ nhiều nguồn ............................................. 30
2.1.6 Độ tin cậy thực......................................................................... 30

2.1.7 Cơ sở của lý thuyết chắc chắn ................................................ 31
2.2

Nhân tố chắc chắn dƣới khía cạnh xác suất ............................... 33

4


2.2.1 Dấu hiệu không chắc chắn ...................................................... 33
2.2.2 Lan truyền chắc chắn đối với các luật có giả thiết đơn ............ 35
2.2.3 Lan truyền chắc chắn đối với các luật nhiều giả thiết .............. 35
2.2.4 Lan truyền chắc chắn đối với các luật có cùng kết luận........... 36
2.2.5 Lan truyền chắc chắn đối với các luật phức hợp ..................... 39
2.3

Ví dụ về nhân tố chắc chắn ........................................................... 39

2.4

Kết luận ........................................................................................... 40

CHƢƠNG 3.
3.1

ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM ................................... 42

Quy trình ƣớc lƣợng dự án phần mềm ........................................ 42

3.1.1 Ước lượng cỡ dự án phần mềm .............................................. 43
3.1.2 Ước lượng khối lượng công việc ............................................. 44

3.1.3 Ước lượng thời hạn ................................................................. 45
3.1.4 Ước lượng dự toán .................................................................. 45
việc

3.2
46

Quy trình ƣớc lƣợng dự án dựa trên cấu trúc phân rã công

3.2.1 Tổng quan quy trình ước lượng ............................................... 46
3.2.2 Thiết kế hệ thống ..................................................................... 47
3.2.3 Ước lượng mỗi một hệ thống con ............................................ 48
3.2.4 Kế hoạch công việc.................................................................. 53
3.3

Ƣớc lƣợng sử dụng mô hình điểm trƣờng hợp sử dụng .......... 55

3.3.1 Ước lượng sử dụng mô hình UCPs ......................................... 55
3.3.2 Áp dụng mô hình UCPs trong thực tế ...................................... 59
3.4

Biến đổi quy trình ƣớc lƣợng dự án phần mềm ......................... 62

3.4.1 Phân loại các loại dự án phần mềm cần ước lượng ................ 62
3.4.2 Quy trình ước lượng dự án phần mềm thực tế ........................ 63
3.5

Kết luận ........................................................................................... 76

CHƢƠNG 4.

4.1

ƢỚC LƢỢNG DỰ ÁN DÙNG LÝ THUYẾT CHẮC CHẮN 77

Ƣớc lƣợng cỡ dự án...................................................................... 78

4.1.1 Phân loại dự án theo IBM Rational .......................................... 78
4.1.2 Phân loại dự án theo quy định của Đề án 112 ......................... 78
4.1.3 Phân loại dự án theo SLOC ..................................................... 80
4.1.4 Xây dựng bảng nhân tố chắc chắn .......................................... 81
4.2

Ƣớc lƣợng khối lƣợng công việc ................................................. 82

4.2.1 Phân loại rủi ro ......................................................................... 83

5


4.2.2 Khả năng kết hợp giữa quản lý rủi ro và lý thuyết chắc chắn .. 84
4.2.3 Áp dụng các luật chắc chắn vào trong ước lượng ................... 85
4.2.4 Dùng các luật để nâng cao khả năng chắc chắn của dự án .... 89
4.3

Ƣớc lƣợng lịch biểu....................................................................... 92

4.4

Ƣớc lƣợng dự toán ........................................................................ 95

4.5

Kết luận ........................................................................................... 98

KẾT LUẬN ................................................................................................. 99
TÀI LIỆU THAM KHẢO............................................................................ 101

6


BẢNG CÁC KÝ HIỆU VIẾT TẮT

Số thứ tự

Từ viết tắt

Ý nghĩa

1

A&D

Phân tích và thiết kế

2

CF

Nhân tố chắc chắn

3

COCOMO

Mô

hình

xây

dựng

dự

toán.

Cost

Constructive Model
4

5

DAPM

Dự án phần mềm.

ECF

Nhân tố phức tạp môi trường

Effort

Tổng thời gian nỗ lực để hoàn thành một
công việc

6

FP

Điểm chức năng

7

Impl

Cài đặt

8

LOC

Số dòng lệnh (Line Of Code)

9

PDCA

Kế hoạch, thực hiện, kiểm tra, hành động

10

PMI

Viện Nghiên cứu quản lý dự án.

11

PM

Quản trị dự án

12

QFD

Triển khai chức năng phát triển

13

Reqs

Yêu cầu

14

Schedule

Lịch biểu

15

SLOC

Số nguồn dòng lệnh (Source Line Of Code)

16

TCF

Nhân tố phức tạp kỹ thuật

17

UCP

Điểm trường hợp sử dụng ( Use case Point)

7


18

UCPM

Mô hình điểm trường hợp sử dụng.

19

UCPs

Điểm những trường hợp sử dụng.

20

UUCPs

Điểm trường hợp sử dụng không thích ứng

21

WBS

Cấu trúc phân rã công việc (Work breakdown Structure)

8


MỞ ĐẦU
Với việc ngày càng có nhiều công ty nước ngoài lựa chọn Việt Nam để đầu
tư vào lĩnh vực gia công phần mềm, và chính phủ cũng đang đầu tư mạnh mẽ cho
công nghệ thông tin, các công ty tin học, và công nghệ thông tin luôn phải đối mặt
với những thách thức trong việc ước lượng dự án phần mềm, và quản lý phát
triển dự án phần mềm. Là ngành mũi nhọn, tin học, và công nghệ thông tin ngày
càng phải đổi mới và phát triển để có được các biện pháp tân tiến và hiệu quả
nhất cho việc ước lượng dự án, và quản lý phát triển dự án phần mềm, nhằm theo
kịp và đáp ứng được nhu cầu phát triển của xã hội.
Là một phương pháp quản lý có những đặc thù riêng biệt, ước lượng và
quản lý dự án phần mềm là một lĩnh vực không quá mới với nhiều thành phần và
kỹ thuật khác nhau. Luận văn sẽ trình bày một số vấn đề cơ bản về quá trình quản

lý phát triển dự án phần mềm, đặc biệt là ước lượng dự án phần mềm, với một số
phương pháp, kỹ thuật ước lượng như: Ước lượng dựa trên COCOMO, ước
lượng dựa trên Cấu trúc phân rã công việc, Ước lượng dựa trên Điểm chức năng,
Ước lượng dựa trên Điểm trường hợp sử dụng v.v .
Để triển khai thử nghiệm nhằm đánh giá các phương pháp đã trình bày,
luận văn tiến hành xây dựng quy trình “Ước lượng dự án phần mềm”. Trong quy
trình này, có vận dụng phương pháp ước lượng dựa trên Mô hình Cấu trúc phân
rã công việc và dựa trên thực tế áp dụng quy trình phát triển dự án tại công ty
Vietsoftware International. Quy trình này nhằm đưa ra phương pháp để ước lượng
một cách nhanh nhất, đơn giản nhất, và gần với thực tế nhất. Trên cơ sở quy trình
đó, luận văn sẽ tiếp tục trình bày việc áp dụng tri thức vào việc phát triển dự án.
Nội dung nghiên cứu của đề tài tập trung chủ yếu vào các vấn đề:


Chương 1: Tập trung vào một số lý lý thuyết liên quan đến quản lý
quá trình phát triển dự án phần mềm



Chương 2: Trình bầy về các khái niệm, luật của lý thuyết chắc chắn.



Chương 3: Phân tích đánh giá một số quy trình ước lượng dự án
phần mềm để từ đó đưa ra quy trình ước lượng dự án phần mềm.



Chương 4: Sử dụng tri thức trong việc ước lượng dự án phần mềm.

9


CHƢƠNG 1.

QUẢN LÝ QUÁ TRÌNH PHÁT TRIỂN DỰ ÁN

1.1 Lập kế hoạch dự án
Để hoàn thành thành công một dự án phát triển, việc lập kế hoạch và quản
lý dựa trên các kế hoạch là quan trọng. Việc chuẩn bị kế hoạch cho phép nhìn
toàn cảnh về dự án. Dự án cần được phát triển rõ ràng, có khả năng kiểm tra và
nghiên cứu trước các vấn đề rủi ro của dự án.
Ngoài ra còn cần xem xét mục đích, chức năng và nhìn bao quát về hệ
thống, cũng như khối lượng công việc và số nhân công cần cho dự án.
1.1.1 Lập kế hoạch dự án
Việc lập kế hoạch dự án được thực hiện, nhằm tạo ra những kết quả :


Những đầu ra (mã lệnh, chương trình, tài liệu), công việc, lịch biểu, quản lý
chất lượng, quản lý rủi ro và những vấn đề khác.



Cơ cấu tổ chức của dự án. Cơ cấu gồm những thành viên tham gia dự án
và đóng vai trò nào đó trong dự án. Những người có vai trò quản trị dự án,
quản trị chất lượng,.. sẽ đảm nhận cụ thể những công việc gì trong quá
trình phát triển và quản lý dự án.



Quy định môi trường phát triển bao gồm phần cứng và phần mềm và các
điều kiện khác về an toàn bảo mật trong dự án kèm theo, nếu có.



Chi phí phát triển, bao gồm chi phí cho nhân sự, trang thiết bị, chi tiêu và
các chi phí có liên quan khác.
Người ta xây dựng kế hoạch chi tiết theo những kết quả trên. Những kế

hoạch này cung cấp cơ sở để đánh giá tính khả thi triển khai dự án. Ngoài ra, kế
hoạch được dùng làm mục đích cho việc quản lý dự án, sau khi dự án được phê
duyệt.
1.1.2 Tính toán lợi nhuận của dự án
Việc phát triển hệ thống được thực hiện như một phần của hoạt động kinh
doanh, nên các yêu tố sinh lợi cần được thăm dò sau khi phát triển dự án, một
cách tự nhiên. Điều này có nghĩa là việc đánh giá chi phí- hiệu quả là cần thiết.
Nếu việc phát triển hệ thống cho thấy nó không sinh lợi từ giai đoạn lập kế hoạch,

10


thì dự án sẽ không được chấp thuận. Chẳng hạn như, hệ thống là cần thiết để
đáp ứng các yêu cầu của luật pháp hay quy chế.
Nếu việc tính toán lợi nhuận được đưa ra tại giai đoạn lập kế hoạch, thì
điều thường xảy ra là vào lúc hoàn thành người ta thấy dự án này hoàn toàn
chẳng lợi lộc gì. Chẳng hạn, ta có thể xét kịch bản sau đây : Khách hàng thay đổi
yêu cầu vào giai đoạn thiết kế, làm tăng khối lượng công việc cần thiết. Các chức
năng được đưa ra trước đây thực tế không được hỗ trợ thỏa đáng. Những thứ
mua từ bên ngoài lại kém về chất lượng, làm phát sinh nhiều việc phải làm lại và
ảnh hưởng tới thời hạn giao hàng. Một số kịch bản chỉ được đưa ra khi nào các

dự án được tiến hành. Có thể nói rằng dự án đó có thể là không được thực hiện
như đã lập kế hoạch.
Do đó việc xem xét lại các kế hoạch trong từng giai đoạn trở thành cần
thiết, để duy trì tính sinh lợi. Những sửa đổi về các đặc tả phải được phản ánh
đúng. Cho nên, để an toàn chất lượng, cần phải tiến hành việc quản lý những thay
đổi diễn ra trong dự án.

1.2 Lập kế hoạch, quản lý và đánh giá chất lƣợng
1.2.1 Triển khai chức năng chất lƣợng
Mục đích chính của kiểm thử phần mềm là loại bỏ các lỗi và duy trì chất
lượng đã được thiết kế, QFD là một công nghệ giúp cho phần mềm đạt chất
lượng cao hơn. QFD được giới thiệu để tăng chất lượng của thiết kế phần cứng.
Đại cương về QFD là :
Với QFD, chất lượng của phần mềm bao gồm các hệ con và các phân hệ,
được biểu diễn như đặc trưng chất lượng. Nó cho phép đánh giá và sử dụng cho
việc kiểm soát chất lượng của các hệ thống con và các phân hệ bên trong nó.
1.2.2 Chất lƣợng phần mềm
Nói rằng „‟Máy tính thông minh lắm‟‟ là không đúng. Đúng hơn phải nói là, „‟
Phần mềm (chương trình) này thông minh lắm‟‟. Trong thực tế, việc đưa dữ liệu ký
tự vào thay vì các số làm cho máy tính bị kết thúc bất thường. Để tránh điều này,
với một chương trình có thể kiểm tra dữ liệu được đưa vào và yêu cầu chương
trình phải đưa ra yêu cầu thông báo người dùng phải nhập lại số liệu- nếu dữ liệu
không hợp lệ (không phải là số, hoặc ngày tháng chẳng hạn). Nói cách khác, việc

11


đưa ra chức năng kiểm tra lỗi làm cho chương trình thông minh hơn, làm tăng
chất lượng phần mềm.
Một chức năng như vậy không nên phụ thuộc vào khả năng của người lập

trình. Nó phải được tính trước trong giai đoạn thiết kế, nơi các yêu cầu của người
dùng được cụ thể hóa chi tiết. Nếu như việc kiểm tra được xác nhận như một nhu
cầu tiềm tàng của người dùng, nhưng lại không được mô tả trong đặc tả trong giai
đoạn thiết kế, thì chức năng này sẽ không bao giờ có được. Những thiếu sót bắt
nguồn từ các đặc tả yêu cầu(giai đoạn sớm nhất), có thể chỉ được phát hiện ra
trong kiểm thử vận hành (giai đoạn muộn nhất). Hậu quả là có thể là điều không
sửa chữa được, ngay cả khi đã tìm ra khiếm khuyết.
Nói cách khác, nếu có đủ thời gian trong các giai đoạn đầu cho việc kiểm
soát và sửa chữa sai sót, thì khối lượng cần sửa đổi trong các giai đoạn sau sẽ
được rút bớt lại. Thực tế người ta nói : „‟Một giờ được dùng để sửa các khiếm
khuyết trong những giai đoạn đầu, tiết kiệm từ ba tới mười giờ làm việc trong
những giai đoạn cuối‟‟. Để làm tăng chất lượng phần mềm, người ta thực hiện chu
trình :
1. Kế hoạch;
2. Thực hiện;
3. Kiểm tra;
4. Hành động.
Việc thực hiện theo chu trình trên là rất quan trọng. Nó sẽ giúp chúng ta
loại bỏ được phần lớn những rủi ro trong quá trình thực hiện dự án từ những giai
đoạn sớm nhất trong dự án.
1.2.3 Đặc trƣng chất lƣợng phần mềm
Có nhiều phương pháp đánh giá phần mềm. Ở đây chúng ta cùng xem xét
đến sáu mô tả đặc trưng được liệt kê trong ISO/IEC 9126 được nêu trong hình
sau.
 Chức năng (đặc trưng chức năng)


Các chức năng cần cho hệ thống được thực hiện (tính thích hợp);



Độ chính xác chức năng được cung cấp (tính chính xác);



Các chức năng đáp ứng cho đặc tả (tính tuân thủ);

12




Cung cấp sự dễ dàng khi kết nối với các hệ thống khác (tính liên tác);



Cung cấp tính an ninh cơ bản.
Tính phù hợp
Tính chính xác
Tính chức năng

Tính tuân thủ
Tính liên tác
Tính an ninh
Tính chín muồi

Tính tin cậy

Dung sai
Khôi phục được

Tính hiểu được

Tính dùng được

Đặc trưng
chất lượng

Tính học được
Tính vận hành
được
Hành vi thời gian

Tính hiệu quả
Hành vi tài nguyên
Tính phân tích được
Tính bảo trì

Tính thay đổi được
Tính ổn định
Tính kiểm thử được
Tính thích ứng

Tính khả chuyển

Tính cài đặt
Tính tuân thủ
Tính thay thế được

Hình 1.2.1: Sáu đặc trưng chất lượng phần mềm
 Tính tin cậy



Phần mềm không có lỗi được gọi là chín muồi;



Một mức độ hệ thống nào đó được duy trì ngay cả khi xuất hiện trục trặc:
dung sai;



Hoạt động bình thường được khôi phục sẵn sàng khi lỗi xuất hiện: tính khôi
phục được.
 Tính dùng được (dễ dùng)



Vận hành dễ dàng: Tính hiểu được



Dễ nhớ: khả năng học hiểu.



Cho phép quản lý thao tác dễ dàng: tính vận hành.

13

 Tính hiệu quả


Cung cấp những đáp ứng tố và hiệu năng cao : hành vi thời gian;



Cho phép dùng hiệu quả các tài nguyên hệ thống: hành vi tài nguyên.
 Tính bảo trì



Cho phép phân tích dễ dàng các tài liệu thiết kế và chương trình khi tìm ra
lỗi: khả năng phân tích;



Cho phép mở rộng và sửa đổi dễ dàng cho hệ thống: tính thay đổi được;



Việc sửa đổi hệ thống không ảnh hưởng tới các hệ thống khác: tính ổn định;



Không đòi hỏi kiểm thử mất công sức sau khi tiến hành sửa đổi: tính kiểm
thử được.
 Tính khả chuyển



Có tính thích ứng: tính thích ứng;



Cung cấp công việc thiết đặt dễ dàng: khả năng thiết đặt;



Tuân thủ các đặc tả chuyển: tính tuân thủ;



Cho phép dễ dàng thay thế bằng phần mềm khác: khả năng thay thế.

1.3 Quản lý tiến trình
Quản lý tiến trình được chia thành lập kế hoạch tiến độ và quản lý tiến
trình. Ở đây, các đặc trưng, và phương pháp được áp dụng sẽ được giải thích ở
dưới đây.
1.3.1 Tổng quan về lập kế hoạch tiến trình và quản lý tiến độ
Lập kế hoạch tiến trình xuất hiện khi việc phát triển hệ thống được hoàn
thành dựa trên việc hoàn thành các tiến trình khác nhau. Một số công việc lớn
phải mất nhiều năm để hoàn thành. Do đó, việc lập kế hoạch tiến độ chính xác là
một việc quan trọng. Một dự án phát triển mới gồm nhiều nhân tố không chắc
chắn mà không thể nào xác định được chính xác trong giai đoạn lập kế hoạch tiến
độ. Do đó, khi tiến độ công việc được thúc đẩy, việc giải quyết linh hoạt cho các
tính huống như: làm cho ngày chuyển giao sớm hơn (tùy theo tinh huống), hay tối
thiểu hóa việc chậm trễ, trở thành cần thiết.
Trong khi đó quản lý tiến trình là việc quản lý quá trình diễn biến của công
việc. Chúng ta cần kiểm tra lại tiến độ công việc và tiến hành hành động nào đó

14


đối với công việc có tiến độ bị chậm so với kế hoạch làm việc. Hiệu năng công
việc phát triển hệ thống bị chia sẻ cho nhiều người. Do đó, sự chậm chễ của
người này trong công việc dẫn tới sự chậm trễ trong tiến độ của người kia, dẫn tới
sự chậm trễ trong tiến độ của dự án xem như một điều tất yếu. Hậu quả là, việc
quản lý tiến trình thấu đáo là cần thiết để tối ưu tác động của việc chậm trễ. Cũng
như để phát hiện ra vấn đề dễ nhất có thể giải quyết được.
1.3.2 Lập kế hoạch tiến trình
Sơ đồ Gantt và PERT được dùng trong hầu hết các dự án và được coi như
những phương pháp hcuẩn để lập kế hoạch tiến độ.
 Sơ đồ Gantt: Còn được gọi là sơ đồ thanh. Dưới đây là một ví dụ về sơ

đồ Gantt:

Hình 1.3.1: Sơ đồ Gantt
Đặc trưng của sơ đồ Gantt là cung cấp các biểu đồ trực quan theo đó thời
gian cần thiết để hoàn thành một công việc được thể hiện bằng một thanh ngang
có điểm bắt đầu là thời gian bắt đầu và kết thúc là thời gian kết thúc công việc.
Các thứ tự ưu tiên của các công việc không được thể hiện trên bản đồ Gantt.
Đồng thời các công việc gây ra sự chậm trễ đến các công việc khác cũng không
được vẽ ra.


Biểu đồ PERT (Program Evaluation and Review Technique) cung cấp
một số kỹ thuật để sinh ra lịch biểu đồ cho từng phần công việc (tiến độ)
của một dự án, và quản lý chúng dựa trên biểu đồ. Dưới đây là một ví dụ
của biểu đồ PERT

15


Hình 1.3.2: Biểu đồ PERT


Biểu đồ PERT có thể giải quyết việc phát triển các hệ thống quy mô lớn và
phức tạp.



Nó có khả năng tính toán tổng số ngày cần thiết (tổng số ngày tối thiểu).



Thứ tự công việc cần được thực hiện được biểu diễn rõ ràng làm sáng tỏ
các điểm quản lý quan trọng.



Số ngày và thứ tự thực hiện được thể hiện trên các cạnh. Các nút là số các
công việc cần thực hiện được đánh số từ 1 tới n (n là tổng số công việc cần
thực hiện trong dự án).
Đường đi được sinh ra bằng cách nối các nút, với từng nút mà thời gian

sớm nhất có thể và thời gian muộn nhất có thể là như nhau (không được phép
thay đổi hay co dãn) được gọi là đường Gantt. Công việc trên đường này là quan
trọng nhất trong tiến trình quản lý.
1.3.3 Quản lý tiến trình

Việc quản lý tiến trình được tiến hành theo hai quan điểm sau:
1. Định thời gian bắt đầu và kết thúc của từng phần việc
2. Trạng thái tiến độ của công việc cá nhân của từng người.
Quản lý việc định thời gian bắt đầu và kết thúc của từng việc
Việc quản lý được tiến hành sao cho từng phần việc được bắt đầu như đã
được xác định trong bản kế hoạch và được kết thúc như được xác định bằng mọi
phương pháp, bằng cách kiểm tra trang thái tiến độ tức khắc của từng phần việc
và bằng cách lấy những cách đo thích hợp dựa trên trạng thái đó.
Sau đây ta xét các lý do cho việc chậm trễ trong công việc:


Kỹ năng của các kỹ sư liên quan không đủ;



Việc lập kế hoạch và mục tiêu không được xem xét thích hợp;

16




Các vấn đề liên quan tới nhân sự;



Vấn đề ngân sách;



Trục trặc phần cứng hoặc phần mềm.
Khi chậm trễ trong công việc được phát hiện ra người quản lý, như người

lãnh đạo dự án, phải đề ra các biện pháp để giải quyết tình huống này và lấy
những biện pháp cụ thể, như thay đổi tiến độ, sớm nhất có thể được.
Để tạo khả năng cho các biện pháp như vậy, mọi thành viên lực lượng lao
động phải báo cáo trang thái tiến độ của công việc của mình một cách đều đặn
thông qua nhật ký công việc hay báo cáo công việc tuần. Nói riêng, khi một tình
huống bất ngờ xuất hiện, người đó phải báo cáo sớm nhất có thể.
Lập lịch
Lập lịch cho từng thành viên lực lượng lao động: Việc lập lịch được dùng
để phân bổ công việc của từng tiến trình cho từng thành viên lực lương lao động
để quyết định thứ tự của từng phần việc được tiến hành, và để quản lý trang thái
tiến độ công việc trên cơ sở hàng ngày. Việc lập lịch cũng có hiệu quả để làm cho
thời gian chuyển giao sơm hơn và tối thiểu việc chậm trễ.
Ví dụ: Thiết kế ngoài, cho việc thiết kế tổng thể một hệ thống, bao gồm
nhiều phần việc trong đó có một số lớn các kỹ sư hệ thống (Ses) có tham dự vào.
Trong ví dụ này, việc lập lịch trở thành như sau khi được xem xét theo quản điểm
người lãnh đão và quan điểm của thành viên lực lượng lao động, tương ứng:
1. Người lãnh đạo dự án


Công việc thiết kế hệ thống được chia thành một số việc nhỏ.



Mỗi việc được phân bổ cho từng thành viên tùy theo mức độ kỹ
năng của người đó.



Việc lập lịch cho từng thành viên (từng công việc) được thực hiên.



Hướng dẫn phân bổ công việc được trao cho từng thành viên.



Việc hoàn thành của từng công việc được kiểm tra bằng cách đọc
nhật ký công việc hay báo cáo tuần của từng thành viên.



Tiến hành những biện pháp linh hoạt, như thay đổi kế hoạch nếu
cần, khi phát hiện ra chậm trễ trong công việc.

2. Thành viên phát triển dự án

17




Người đó tự quản lý mình bằng cách so sánh trạng thái tiến độ công
việc với lịch công việc đã được phân bố và cố gắng giữ thời gian kết
thúc như kế hoạch.



Người đó báo cáo về trạng thái tiến độ công việc thông qua nhật ký
công việc hay báo cáo tuần, bên cạnh việc báo cáo khi công việc
hoàn thành xong.

Như đã mô tả ở trên, quản lý tiến trình được tiến hành bằng việc tổ hợp kế
hoạch tiến trình thô và lập lịch chi tiết.

1.4 Năng suất phần mềm
Để đánh giá năng suất phần mềm, phải đánh giá được quy mô phần mềm.
Việc phát triển phần mềm bao gồm nhiều đầu ra khác nhau tuỳ theo từng tiến
trình, như cá đề án, đặc tả yêu cầu, đặc tả thiết kế, đặc tả thiết kế, đặc tả chương
trình, và chương trình nguồn. Tuy nhiên, phần nhiều trong chúng được tạo ra
bằng công việc kiểu thủ công, tùy thuộc phần lớn vào kinh nghiệm và cảm giác
con người. Do đó, việc ước lượng chi phí cũng phụ thuộc chủ yếu vào kinh
nghiệm và cảm giác để cải thiện tình hình này, người ta đề nghị dùng kỹ nghệ
phần mềm. Sau đó nhiều phương pháp ước lượng chi phí đã được đề nghị, và
một số trong chúng bây giờ đang được dùng.
1.4.1 Về ƣớc lƣợng
Chẳng hạn cần ước lượng chi phí để xây dựng một căn nhà. Mái, cửa và
cửa sổ tất cả đều thấy được. Do đó nếu bản thiết kế sơ bộ được thiết kế thì chi
phí có thể được ước lượng. dựa trên không gian sàn nhà và các nhân tố khác..
Tuy nhiên, tệp, cơ sở dữ liệu và chương trình phần mềm tất cả đều không
nhìn thấy được (tài sản vô hình). Do đó, các ước lượng trong giai đoạn thiết kế chi
tiết trở thành khác biệt lớn với các ước lượng trong giai đoạn lập kế hoạch cơ sở.
Hậu quả là ước lượng về phát triển nên được tiến hành trong nhiều giai đoạn
được mô tả như sau:


Trong giai đoạn lập kế hoạch cơ sở;



Trong giai đoạn thiết kế ngoài;



Trong giai đoạn thiết kế trong.

1.4.2 Các phƣơng pháp ƣớc lƣợng

18


Có một số phương pháp sau đây để ước lượng tỉ lệ phát triển:
Ước lượng dựa theo dữ liệu quá khứ
Trong phương pháp này, các ước lượng về hệ thống được phát triển và
suy ra dựa trên dữ liệu thực của hệ thống tương tự đã xây dựng trong quá khứ.
Có hai cách để làm ước lượng.


Toàn bộ tiến trình phát triển hệ thống được phân hoạch thành một số
bước, và các ước lượng được suy dẫn ra dựa trên dữ liệu thực cho
công việc tương tự.



Hệ thống được phân hoạch thành một số module chương trình, và các
ước lượng được suy ra dựa trên dữ liệu thực tế cho các module
chương trình tương tự.

Với hệ thống tương tự trong quá khứ, các lỗi cơ sở khó mà bị bao hàm vào
nhiệm vụ ước lượng là tương đói đơn giản. Số lỗi trong các ước lượng trở nên
lớn hơn nếu hệ thống quá khứ thích hợp không được chọn cho công việc ước
lượng
Phương pháp áp dụng dựa trên LOC
Phương pháp dựa trên LOC là hay được dùng nhất làm phương pháp cho
việc ước lượng kích cỡ phát triển. Với phương pháp này, kích cỡ phát triển được
ước lượng bằng số dòng mã, và dựa trên dữ liệu này, khối lượng tài nguyên cần
thiết được ước lượng ra.




Thủ tục:

Hệ thống được diễn tả như một tập các module chương trình;
Các chức năng hệ thống được phân hoạch thành các module chương trình,
với mối quan hệ giữa chúng được chỉ ra bằng biểu đồ khối cấu trúc hay các
phương tiện khác;



Tính toán kích cỡ của từng chương trình;



Số các LOC trong từng module chương trình trong biểu đồ được ước
lượng. Rồi tổng số cá LOC được tính toán;



Ước lượng nhân lực cho tất cả các chương trình cần làm;



Tổng số các LOC được chuyển thành tổng nhân lực, như dữ liệu và ngườitháng (số người cần thiết nhân với số tháng cần thiết). Chẳng hạn, nếu việc

19


phát triển hệ thống cần nỗ lực làm việc 2 năm của 20 người, thì nhân lực là
20 người x 24 tháng=480 người- tháng;


Ước lượng trên cơ sở tiến trình: Khối lượng nhân lực được phân bố cho
từng tiến trình, như lập kế hoạch cơ sở và các thiết kế khác nhau, với số
phần trăm phân bố được quyết định dựa trên dữ liệu quá khứ;



Ước lượng về nhân lực gián tiếp: trọng số nhân lực đối với các công việc
như phân tích và thiết kế hệ thống, và trọng số cho nhân lực đối với công
việc hành chính sẽ được quyết định;



Tổng nhân lực ướng lượng: Tổng nhân lực được tính bằng việc kết tập dữ
liệu nhân lực cho từng tiến trình;



Về đặc trưng nó cung cấp phương pháp tiêu biểu nhất.
Nếu có các chuẩn rõ ràng để ước lượng chương trình LOC và để chuyển

chúng thành khối lượng nhân lực, thì tính toán được tổng giá trị dự án là khá đơn
giản.
Phương pháp dựa trên nhiệm vụ chuẩn
Với phương pháp dựa trên nhiệm vụ chuẩn, công việc được chia ra trên cở
sở đầu ra hay trên cơ sở xử lý bằng WBS (Work Breakdown Structure). Sau đó
ước lượng chi tiết đwocj thực hiện cho từng đơn vịvà ước lượng kết quả được
tích luỹ theo phương pháp bottom-up.
 Kiểm tra đầu ra và công việc được yêu cầu
 Hệ thống được chia ra thành một cấu trúc phân cấp dựa trên WBS, và

tất cả các đầu ra sản phẩm cần được phát triển trong dự án được liệt kê
ra. Sau đó tất cả những công việc cần thực hiện để làm ra sản phẩm này
được chọn.
 Kích cỡ của từng công việc được chuyển thành khối lượng nhân lực
 Khối lượng nhân lực cần cho từng đơn vị công việc được chọn được

đưa ra ước lượng theo những chuẩn nào đó, như dữ liệu thực tế cho
chuẩn đã có tác dụng trong quá khứ.
 Kết tập toàn bộ nhân lực
 Khối lượng nhân lực cần cho từng đơn vị công việc được tính tổng lại

Phương pháp dựa trên điểm chức năng (Function Point)

20

Với phương pháp FP, từng chức năng được đưa vào trong hệ thống sẽ
được diễn đạt đinh lượng bằng một phương pháp nàp đó, và do vậy dữ liệu được
biểu diễn theo định lượng được dùng như cách đo ước lượng
Phương pháp này khác cơ bản với ba phương pháp trên trong việc dùng
từng chức năng được cung cấp cho khách hàng và xem nó như đơn vị đo
Phương pháp dựa trên Mô hình Dự toán Thành Phẩm (COnstruction COst
MOdel)
Mô hình COCOMO, một phương pháp ước lượng do Boehm đề xuất, phù
hợp với việc ước lượng cá hệ thống cỡ trung và lớn.
Với mô hình COCOMO, hệ thống được phân lớp dựa trên ba mô hình: cỡ
nhỏ, cỡ bình thường, cỡ lớn. Sau đó từng mô hình, nhân lực phát triển tổng cộng
và thời kỳ phát triển được tính toán từ số các câu lệnh được dự kiến vào lúc hệ
thống được trao cho người dung.
Phương pháp dựa trên mô hình Use Case Point (UCP- điểm trường hợp sử
dụng)
Với phương pháp UCP, từng trường hợp sử dụng UC được đưa vào trong
hệ thống sẽ được diễn đạt định lượng bằng một phương pháp nào đó, và do vậy
dữ liệu được biểu diễn theo định lượng được dùng như cách đo ước lượng.
Phương pháp này gần như tương tự với phương pháp FP ở trên nhưng khác ở
chỗ sử dụng các Use Case Point như là những đơn vị cơ bản nhất để đo lường và
đánh giá. Use Case là đơn vị cơ sở và cơ bản thể hiện các trường hợp sử dụng
được mô tả lại dưới dạng tài liệu nhằm thỏa mãn và thống nhất cách thức hoạt
động của nó trong các trường hợp cụ thể. Use Case là thành phần không thể
thiếu đối với các hệ thống phân tích thiết kế hướng đối tượng.

1.5 Tổ chức phát triển
Có nhiều điểm đóng góp cho sự thành công của việc phát triển hệ thống,
kể cả các khoản mục liên quan tới quản lý công việc đa dạng như sau:


Sự tham gia tích cực của người dùng (thiết lập tổ chức phát triển);



Quản lý tiến trình kỹ lưỡng và quản lý tiến trình của công việc từng người;



Quản lý chất lượng hệ thống kỹ lưỡng.
Việc phát triển hệ thống quy mô lớn cần thời gian phát triển lâu (đôi khi

nhiều năm), và đòi hỏi số tiền và tài nguyên nhân lực rất lớn.

21


Tuy nhiên, không phải bi quan rằng việc phát triển hệ thống thất bại trong
giai đoạn lập kế hoạch cơ sở hay giai đoạn thiết kế hay việc phát triển được hoàn
tất nhưng chất lượng lại quá nghèo nàn không dùng được trong vận hành thực tế.
Một cách tự nhiên, công việc phát triển được quản lý bởi một người quản
lý, chẳng hạn, người quản lý dự án. Tuy nhiên, việc quản lý đúng công việc của
riêng từng thành viên phát triển và tạo ra đầu ra chất lượng cao là nhân tố quan
trọng dẫn đến việc phát triển hệ thống tới thành công
Điều quan trong thứ nhất để đưa việc phát triển hệ thống tới thành công là
thiết lập một tổ chức phát triển vững chắc. Làm tiến độ công việc đúng theo lịch
phát triển hệ thống (lịch mức cao nhất) đã tạo ra trong giai đoạn lập kế hoạch cơ
sở là điều tiên quyết lớn nhất cho sự thành công. Hơn nữa, liệu công việc có tiến
hành trôi chảy hay không cũng có thể được nói là tùy thuộc phần lớn vào công
việc hợp tác của các thành viên lực lượng lao động.
1.5.1 Các phong cách tổ chức

Kiểu phong cách tổ chức phát triển nào nên được dùng còn tùy theo quy
mô phát triển hay những người nào là nòng cốt của đội phát triển. Tuy nhiên, sự
tham dự của người dùng là không thể thiểu được trong bất kỳ tổ chức nào. Trong
nhiều việc phát triển hệ thống thành công, tổ chức của người dùng tham dự vào
việc lập kế hoạch cở sở và thiết kế ngoài.
Hơn nữa việc phát triển hệ thống thường xuyên được tiến hành trong sự
hợp tác với các công ty phát triển bên ngoài. Chẳng hạn, việc bắt đầu cho giai
đoạn thiết kế được thực hiện nội bộ, còn việc lập trình thì thuê khoán ngoài với
các công ty khác.
Ví dụ về tổ chức phát triển dưới đây chỉ ra một tổ chức cho một dự án quy
mô nhỏ, trong khi hình tiếp theo nêu ra một tổ chức cho dự án quy mô lớn.
Ví dụ: dự án quy mô nhỏ:

22


Tổ chức phát triển
hệ thống

Người dùng

Chịu trách nhiệm

Phát triển hệ thống

Hình 1.5.1: Sơ đồ tổ chức dự án quy mô nhỏ
Ví dụ: dự án quy mô lớn:
Tổ chức đứng đầu
về phát triển hệ
thống

Công ty phát triển
bên ngoài

Người đứng đầu
tổ chức

Bộ phận phát triển
hệ thống

Quản lý dự án
Trao đổi

Đối tác 1

Đối tác 2

Người dùng 1

Lãnh Đạo dự
án 1

Người dùng 2

Lãnh Đạo dự
án 2

Hình 1.5.2: Sơ đồ tổ chức dự án quy mô lớn
1.5.2 Tổ chức phát triển
Tổ chức phát triển nhận các yêu cầu hệ thống hóa từ người dùng và tiến

hành công việc về lập kế hoạch cơ sở, các kiểu thiết kế, lập trình và các kiểu kiểm
thử. Gần đây, trong nhiều trường hợp các tổ dự án nội bộ thực hiện công việc về
lập kế hoạch cơ sở và thiết kế, còn lập trình và kiểm thử được ủy quyền cho các

23


công ty phát triển phần mềm bên ngoài. Tuy nhiên, tổ chức phát triển vẫn tiến
hành công việc kiểm nhanạ sau khi kiểm thử đã hoàn tất.
Các kiểu tổ chức phát triển:
Định nghĩa của NASA về dự án là „ Các nhiệm vụ được tiến hành trong
nhiều tổ chức kéo dài từ một tới năm năm và có liên quan lẫn nhau‟. Nói cách
khác dự án chỉ ra một tổ chức với các mục đich xác định kéo dài trong một
khoảng thời gian giới hạn.
Có 3 kiểu tổ dự án điển hình đó là: Tổ người lập trình chính, Tổ chuyên gia,
Tổ phân cấp
 Tổ người lập trình chính:

Tổ người lập trình chính là một tổ dự án bao gồm một số tương đối nhỏ tối
đa mười thành viên, với người lập trình chính có hoàn toàn trách nhiệm thực hiện
quyền lãnh đạo trong việc phân bổ công việc cho từng thành viên một cách rõ
ràng và làm tăng năng suất và chất lượng.
Người lập trình
chính

Người lập trình dự
phòng
Trợ lý

Người lập trình

Người lập trình

Người lập trình

Hình 1.5.3: Sơ đồ tổ chức Người lập trình chính
Đặc trưng: dự án quy mô tương đối nhỏ có thể chấp nhận kiểu tổ chức này.
Đặc điểm khác biệt là có người lập trình dự phòng và trợ lý dự án, phù hợp với
việc rèn luyện người lập trình chính và có xu hương gây ra sự suy giảm tinh thần
của người lập trình.

24


Chuyên gia ngôn
ngữ

Chuyên gia tài liệu

Chuyên gia Kiểm
Thử

Người lập trình
chính

Chuyên gia Chất
lượng

Chuyên gia Phân
tích thiết kế

Chuyên gia Tools

Hình 1.5.4: Sơ đồ tổ chức Tổ chuyên gia

 Tổ chuyên gia:

Tổ chuyển gia là một kiểu sửa đổi của tổ người lập trình chính, và bao gồm
một người lập trình chính và nhiều chuyên gia kỹ thuật
Người lập trình chính tạo ra tất cả chương trình còn các chuyên gia kỹ
thuật chịu trách nhiệm các lĩnh vực đặc biệt (như công cụ phát triển, kiểm thử, tài
liệu, cơ sở dữ liệu) giúp cho công việc của người lập trình chính, mở rộng khả
năng của người lập trình chính tời mức tối đa có thể. Điều quan trọng nhất là các
thành viên có kỹ năng mức cao.
 Tổ phân cấp: bao gồm một người quản lý dự án, nhiều người lãnh đạo

dự án và các thành viên.
Người quản lý
dự án

Người lãnh đạo
dự án

Thành viên

Thành viên

Người lãnh đạo
dự án

Thành viên

Thành viên

Người lãnh đạo
dự án

Thành viên

Hình 1.5.5: Sơ đồ tổ chức Tổ phân cấp

25

Thành viên


Kiểu tổ chức này được sử dụng rộng rãi ở Nhật :


Nó được chấp nhận trong việc phát triển phần mềm quy mô tương
đối lớn.



Trao đổi trở nên kém thích hợp hơn, nếu só với tổ người lập trình
chính.

Vai trò của các thành viên trong tổ chức
 Người chịu trách nhiệm tổ chức phát triển (người quản lý dự án):

Trong nhiều trường hợp người chịu trách nhiệm của tổ chức phát triển trở
thành người quản lý dự án. Người quản lý, tại một vị trí quan trọng, hoàn toàn
chịu trách nhiệm cho dự án phát triển.
Người quản lý dự án không chỉ có kỹ năng công nghệ thông tin mức cao,
mà còn phải có khả năng quản lý dự án và khả năng lập kế hoạch. Thêm vào đó,
việc duy trì trao đổi đúng đắn bên trong công ty và với các bên ở ngoài công ty là
một vai trò quan trọng của người quản lý.
Người quản lý dự án có vai trò:


Lập kế hoạch, soạn thảo kế hoạch, thực hiện và ước lượng dự án.



Trao đổi với người dung và các tổ chức có liên quan (kể cả bên trong và
bên ngoài công ty)



Tạo nguồn lực cho công việc và dự án (kể cả việc triển khai nhân sự và tạo
quyền lực)



Công việc quản lý khác.
 Người lãnh đạo dự án:

Người lãnh đạo dự án đóng vai trò phân bổ người quản lý dự án, đặt hoạt
động tổ chức nhóm vào trật tự, hay hành dodọng như người đứng giữa các thành
viên phát triển và người quản lý dự án.

Một tổ chức được người lãnh đạo điều khiển được gọi là nhóm dự án con,
thực hiện công việc phát triển thực tại hay công việc hỗ trợ phát triển (kỹ thuật
kiểm thử, chuẩn hóa hay các công việc khác).
Được chỉ dẫn bởi người lãnh đạo dự án, các thành viên phát triển thực hiện
các công việc phát triển thực tế (thiết kế, lập trình,..) hay công việc hỗ trợ phát
triển.

26