ĐẠ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

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

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



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


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

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.


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

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



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

 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




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

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;





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.






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



Ướ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ớ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:



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

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


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


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.