Ứng dụng logic mờ giải bài toán ước lượng nỗ lực phát triển phần mềm theo mô hình agile

ĐẠI HỌC ĐÀ NẴNG
TRƢỜNG ĐẠI HỌC BÁCH KHOA

LÊ DUY TUẤN

ỨNG DỤNG LOGIC MỜ GIẢI BÀI TOÁN ƢỚC LƢỢNG
NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ HÌNH AGILE

TÓM TẮT LUẬN VĂN THẠC SĨ
Khoa học máy tính

Đà Nẵng – Năm 2019


Công trình được hoàn thành tại
TRƯỜNG ĐẠI HỌC BÁCH KHOA

Người hướng dẫn khoa học: TS. LÊ THỊ MỸ HẠNH
Phản biện 1: TS. Huỳnh Hữu Hưng
Phản biện 2: TS. Phạm Văn Trung

Luận văn sẽ được bảo vệ trước Hội đồng chấm Luận văn tốt
nghiệp thạc sĩ Khoa học máy tính họp tại Trường Đại học Bách
khoa vào ngày 02 tháng 06 năm 2019

Có thể tìm hiểu luận văn tại:
Trung tâm Học liệu và truyền thông, Trường Đại học Bách khoa,
Đại học Đà Nẵng.
Thư viện Khoa CNTT, Trường Đại học Bách khoa - Đại học Đà
Nẵng.

Đà Nẵng – Năm 2019


MỞ ĐẦU
I. Lý do chọn đề tài
Trong quản lý dự án phần mềm, khâu ước ước lượng được
xem là vấn đề trực tiếp ảnh hưởng đến sự thành công hay thất bại của
một dự án phần mềm. Thực tế đã có rất nhiều dự án thất bại do trong
khi thực hiện dự án quá trình ước lượng không chính xác dẫn đến kế
hoạch bị phá sản. Trong quá trình thực hiện dự án ta không thể tính
toán, ước lượng chính xác tuyệt đối được chi phí để phát triển phần
mềm, tuy nhiên nếu các con số dự đoán nằm trong khoảng cho phép
sẽ góp phần giảm rủi ro cho dự án phần mềm. Do đó, nếu ta có một
phương pháp ước lượng phần mềm hiệu quả thì sẽ hạn chế được sự
thất bại của một dự án phần mềm.
Hiện nay mô hình phát triển phần mềm linh hoạt (Agile
Software Development) gọi tắt là Agile đã trở nên rất phổ biến trong
ngành phát triển phần mềm, mô hình này khắc phục được những hạn
chế của các phương pháp phát triển phần mềm truyền thống, góp
phần tạo ra phần mềm có thể đáp ứng đúng theo yêu cầu khách hàng
trong thời gian ngắn nhất với hiệu quả cao nhất. Tuy nhiên, cũng
như các phương pháp truyền thống khác, khâu ước lượng nỗ lực phát
triển phần mềm theo mô hình Agile cũng đóng vai trò quyết định đến
sự thành công của một dự án phần mềm.
Dựa trên lý thuyết logic mờ và xét thấy có sự liên quan trong
quá trình ước lượng nỗ lực đến logic mờ. Do đó, tôi đề xuất chọn
luận văn cao học:
"Ứng dụng logic mờ giải bài toán ước lượng nỗ lực phát triển
phần mềm theo mô hình Agile"

II. Mục đích nghiên cứu
Xây dựng được ứng dụng hỗ trợ ước lượng nỗ lực phát triển
phần mềm có ứng dụng logic mờ áp dụng vào mô hình Agile để
giảm thiểu được thời gian, chi phí cho quá trình ước lượng nỗ lực
1


phát triển phần mềm, qua đó góp phần nâng cao hiệu quả cho dự án
phần mềm.
III. Mục tiêu và nhiệm vụ nghiên cứu
1. Mục tiêu:
- Nắm vững lý thuyết về công nghệ phần mềm và kiến thức
về ước lượng nỗ lực phát triển phần mềm
- Nắm vững mô hình phát triển phần mềm Agile
- Nắm vững về lý thuyết logic mờ và áp dụng được logic mờ
vào bài toán ước lượng nỗ lực phát triển phần mềm.
- Xây dựng được ứng dụng để hỗ trợ ước lượng nỗ lực phát
triển phần mềm
2. Nhiệm vụ:
- Nghiên cứu mô hình phát triển phần mềm linh hoạt ở thực
tiễn.
- Nghiên cứu lý thuyết logic mờ và tình hình ứng dụng logic
mờ vào bài toán ước lượng nỗ lực phát triển phần mềm ở hiện tại.
- Tìm hiểu và cài đặt thuật toán có ứng dụng logic mờ vào
bài toán ước lượng nỗ lực phát triển phần mềm
- Thực nghiệm và đánh giá giá kết quả theo yêu cầu mà đề
tài đặt ra
IV. Đối tƣợng và phạm vi nghiên cứu
- Mô hình phát triển phần mềm Agile
- Lý thuyết ước lượng nỗ lực phát triển phần mềm

- Lý thuyết Logic mờ và ứng dụng của logic mờ
V. Phƣơng pháp nghiên cứu
- Phương pháp lý thuyết
- Phương pháp phân tích và tổng hợp
- Phương pháp thực nghiệm
VI. Ý nghĩa khoa học và thực tiễn
- Nghiên cứu và vận dụng được mô hình phát triển phần
mềm Agile trong công việc quản lý dự án phần mềm
2


- Nắm vững phương pháp ước lượng nỗ lực phát triển phần
mềm
- Nắm vững được lý thuyết về logic mờ và áp dụng được vào
bài toán nỗ lực phát triển phần mềm
- Xây dựng được ứng dụng hỗ trợ ước lượng nỗ lực phát
triển phần mềm để có thể áp dụng vào các dự án thực tế
- Kết quả nghiên cứu có thể làm tài liệu tham khảo trong quá
trình ước lượng nỗ lực phát triển phần mềm cho các dự án phần mềm
VII. Dự kiến kết quả đạt đƣợc
- Biết được mô hình phát triển phần mềm Agile
- Biết được kiến thức về logic mờ và ứng dụng kiến thức về
logic mờ để áp dụng vào bài toán ước lượng chi phí
- Xây dựng được ứng dụng để minh họa cho nội dung luận
văn
- Có kết quả thực nghiệm để đánh giá tính thực tế của đề tài

3

CHƢƠNG I: CƠ SỞ LÝ THUYẾT
CƠ SỞ LÝ THUYẾT ƢỚC LƢỢNG NỖ LỰC PHÁT TRIỂN
PHẦN MỀM
1.1 Tổng quan ƣớc lƣợng phần mềm
Ước lượng là công việc tính toán gần đúng một đại lượng
nào đó dựa trên các tập dữ liệu liên quan đến đại lượng đó. Cũng
giống như bất cứ một dự án nào khác, dự án phần mềm cũng cần
phải ước lượng các đại lượng trên với mục đích:
- Dự toán chi phí hợp lý
- Sự chính xác cao
- Đảm bảo tiến độ
- Kiểm soát dự án tốt hơn
- Thể hiện được sự chuyên nghiệp
1.2 Các bƣớc cơ bản trong ƣớc lƣợng phần mềm
Các bước chính trong ước lượng dự án phần mềm là:
- Ước lượng kích thước, phạm vi dự án
- Ước lượng nỗ lực.
- Ước lượng tiến trình.
- Ước lượng chi phí
1.3 Các phương phương pháp ước lượng
Ước lượng phần mềm là một quá trình phức tạp. Đầu vào
của quá trình ước lượng là các thông số, các thông số này ảnh hưởng
đến công việc thực hiện của dự án, có thể chia các thông số thành các
loại sau:
- Thông số về sản phẩm
- Thông số về môi trường
- Thông số về đội ngũ phát triển:
Các phương pháp ước lượng nỗ lực có thể được sử dụng:
- Ước lượng dựa vào chuyên gia:
- Ước lượng dựa vào các dự án cũ:

- Ước lượng bằng các mô hình thực nghiệm:
4


1.4 Tổng quan mô hình Agile
Phương pháp phát triển phần mềm linh hoạt được đưa ra vào
giữa những năm 90 như là một phần của sự nỗ lực chống lại những
phương pháp “nặng nề” – điển hình bởi những quy định khắt khe.
Ban đầu chúng được gọi là “phương pháp nhẹ”. Đến năm 2001, 17
thành viên nổi bật của cộng đồng phát triển phần mềm linh hoạt đã
gặp gỡ tại Snowbird, Utah để thảo luận về cách thức tạo ra phần
mềm linh hoạt hơn, nhanh hơn và hướng con người hơn. Họ đã thông
qua tên gọi chính thức “phương pháp linh hoạt”
1.4.1 Mô hình phát triển phần mềm Agile
Agile là mô hình phát triển phần mềm linh hoạt, dựa trên
phương thức lặp (iterative) và tăng trưởng (incremental). Nó sẽ gắn
kết khách hàng vào quy trình phát triển của phần mềm, mọi người cố
gắng cho ra sản phẩm càng nhanh càng tốt. Sau đó đưa cho khách
hàng dùng thử và phản hồi lại, đội ngũ phát triển sẽ tiếp tục phát
triển các giai đoạn tiếp theo. Tùy vào dự án mà thời gian release ra
sản phẩm dài hay ngắn (có thể 2 tuần, cũng có thể 1 tháng…)
1.4.2 Tuyên ngôn phát triển phần mềm Agile và các nguyên lý
Tuyên ngôn phát triển phần mềm Agile [2]
- Tuyên ngôn 1: Cá nhân và sự tương tác hơn là quy trình và
công cụ.
- Tuyên ngôn 2: Phần mềm chạy tốt hơn là tài liệu đầy đủ.
- Tuyên ngôn 3: Cộng tác với khách hàng hơn là đàm phán
hợp đồng:
- Tuyên ngôn 4: Phản hồi với các thay đổi hơn là bám sát kế
hoạch:

12 nguyên lý sau tuyên ngôn Agile [3]
- Ưu tiên cao nhất là thỏa mãn khách hàng thông qua việc
chuyển giao sớm và liên tục các phần mềm có giá trị.

5


- Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong
quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho
các lợi thế cạnh tranh của khách hàng.
- Thường xuyên chuyển giao phần mềm chạy tốt tới khách
hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian
ngắn hơn.
- Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau
hàng ngày trong suốt dự án.
- Xây dựng các dự án xung quanh những cá nhân có động
lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng
họ để hoàn thành công việc.
- Phương pháp hiệu quả nhất để truyền đạt thông tin tới
nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực
tiếp.
- Phần mềm chạy tốt là thước đo chính của tiến độ.
- Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các
nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ
liên tục không giới hạn.
- Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia
tăng sự linh hoạt.
- Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa
xong – là căn bản.
- Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất

sẽ được làm ra bởi các nhóm tự tổ chức.
- Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để
trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi
của mình cho phù hợp.
1.4.3 Các đặc trƣng của mô hình Agile
- Tính lặp:
- Tính tăng trưởng và tiến hóa
- Tính thích nghi
6


- Nhóm tự tổ chức và liên chức năng:
- Quản lý tiến trình thực nghiệm:
- Giao tiếp trực diện:
- Phát triển dựa trên giá trị
1.5 Giới thiệu Scrum
1.5.1 Giới thiệu
Scrum là một phương pháp Agile dùng cho phát triển sản
phẩm. Scrum là một khung quản lý dự án được áp dụng rất rộng rãi,
từ những dự án đơn giản với một nhóm phát triển nhỏ cho đến những
dự án có yêu cầu rất phức tạp với hàng trăm người tham gia, và kể cả
những dự án đòi hỏi khung thời gian cố định. Trong Scrum, công
việc được thực hiện bởi nhóm Scrum thông qua từng phân đoạn lặp
liên tiếp nhau được gọi là Sprint. Để hiểu được Scrum thì cần hiểu
nguyên lý của Scrum, các Vai trò, Tạo tác, Sự kiện và sự vận hành
của một vòng đời Scrum.
1.5.2 Khung làm việc Scrum
a. Ba giá trị cốt lõi:
a) Minh bạch (Transparency
b) Thanh tra (Inspection):

c) Thích nghi (Adaptation):
b. Ba vai trò:
Ba vai trò trong Scrum là: Product Owner, Nhóm Phát triển,
và ScrumMaster. Tất cả hợp thành nhóm Scrum
c. Năm cuộc họp:
1. Sprint Planning (Họp Kế hoạch Sprint
2. Daily Scrum (Họp Scrum hằng ngày):
3. Sprint Review (Họp Sơ kết Sprint):
4. Sprint Retrospective (Họp Cải tiến Sprint
5. Sprint Planning (Họp Kế hoạch Sprint):
d. Ba công cụ:
- Product Backlog:
7


- Sprint Backlog
- Burndown Chart:
1.5.3 Nguyên lý hoạt động của scrum:
Scrum chia dự án thành các vòng lặp phát triển gọi là các
sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành.

Hình 1.1 Quy trình hoạt động Scrum

8


CHƢƠNG II. LOGIC MỜ VÀ ỨNG DỤNG
2.1 Cơ sở lý thuyết
2.1.1 Cơ sở lý thuyết về logic mờ
Năm 1965 đã ra đời một lý thuyết mới, đó là lý thuyết tập

mờ (Fuzzy set theory) do giáo sư Lotfi A. Zadeh ở trường đại học
Califonia – Berkeley (Mỹ) đưa ra.
Từ khi lý thuyết đó ra đời nó được phát triển mạnh mẽ qua
các công trình của nhiều nhà khoa học trên thế giới. Năm 1972 các
giáo sư Terano và Asai thiết lập ra cơ sở nghiên cứu hệ thống điều
khiển mờ ở Nhật Bản. Năm 1980 hãng Smith Co. bắt đầu nghiên cứu
điều khiển mờ cho lò hơi... Từ những năm đầu thập kỷ 90 thế kỷ
trước cho đến nay hệ thống điều khiển mờ (Fuzzy control system)
được các nhà khoa học, các kỹ sư và sinh viên trong mọi lĩnh vực
khoa học kỹ thuật đặc biệt quan tâm nghiên cứu và ứng dụng trong
sản xuất và đời sống.
2.1.2 Cơ sở toán học của logic mờ
Logic mờ và xác suất thống kê đều nói về sự không chắn
chắn. Tuy nhiên mỗi lĩnh vực đưa ra một khái niệm khác nhau về đối
tượng.
Trong xác suất thống kê sự không chắc chắn liên quan đến
sự xuất hiện của một sự kiện “chắc chắn” nào đó. Ví dụ: Xác suất
mũi tên trúng đích là 0.6. Bản thân sự kiện “trúng đích” đã được định
nghĩa rõ ràng, sự không chắc chắn ở đây là có trúng đích hay không,
và được định lượng bởi mức độ xác suất (trong trường hợp này là
0.6). Loại phát biểu này có thể được xử lý và kết hợp với các phát
biểu khác bằng phương pháp thống kê, như là xác suất có điều kiện
chẳng hạn.
2.1.3. Khái niệm về tập mờ [4]
a. Tập kinh điển
b. Định nghĩa tập mờ
c. Các thông số đặc trưng cho tập mờ
9

d. Các dạng hàm liên thuộc của tập mờ
1

1

1

0.8

0.8

0.8
0.6

0.6

0.6

0.4

0.4

0.4

0.2

0.2

0.2

0

0

0

a)

b)

c)

1

1

0.8

0.8

0.6

0.6

0.4

0.4

0.2

0.2

0

0

d)

e)

Hình 2.4: Các dạng hàm liên thuộc của tập mờ
Có rất nhiều cách khác nhau để biểu diễn hàm liên thuộc của
tập mờ. Dưới đây là một số dạng hàm liên thuộc thông dụng:
- Hàm liên thuộc hình tam giác
- Hàm liên thuộc hình thang
- Hàm liên thuộc dạng Gauss
- Hàm liên thuộc dạng Sigmoidal
- Hàm liên thuộc hình quả chuông
2.1.4. Các phép toán của tập mờ
a. Phép hợp hai tập mờ
b. Phép giao của hai tập mờ
c. Phép bù của một tập mờ

10


2.2 Logic mờ
2.2.1 Khái niệm [5]
Lôgic mờ (Fuzzy logic) được phát triển từ lý thuyết tập mờ để
thực hiện lập luận một cách xấp xỉ thay vì lập luận chính xác theo

logic vị từ cổ điển. Người ta hay nhầm lẫn mức độ đúng với xác suất.
Tuy nhiên, hai khái niệm này khác hẳn nhau; độ đúng đắn của lôgic
mờ biểu diễn độ liên thuộc với các tập được định nghĩa không rõ
ràng, chứ không phải khả năng xảy ra một biến cố hay điều kiện nào
đó.
Lôgic mờ cho phép độ liên thuộc có giá trị trong khoảng đóng 0
và 1, và ở hình thức ngôn từ, các khái niệm không chính xác như
"hơi hơi", "gần như", "khá là" và "rất". Cụ thể, nó cho phép quan hệ
thành viên không đầy đủ giữa thành viên và tập hợp. Tính chất này
có liên quan đến tập mờ và lý thuyết xác suất.
2.2.2 Biến ngôn ngữ
Biến ngôn ngữ là phần chủ đạo trong các hệ thống dùng logic mờ.
Ở đây, các thành
Các luật trong hệ logic mờ mô tả tri thức của hệ. Chúng dùng các
biến ngôn ngữ như là từ vựng để mô tả các tầng điều khiển trong hệ.
Việc giải thích các luật mờ cũng là việc trình bày cách tính các khái
niệm ngôn ngữ.
2.2.3. Mệnh đề mờ
Các phép toán mệnh đề mờ
Phép toán kéo theo mờ
2.2.4 Các phép toán của logic mờ.
Logic mờ cũng giống Logic thông thường đều quy định về các
phép toán như giao, hợp, loại trừ ,cộng, phủ định….Tuy nhiên, cách
tính giá trị của mỗi phép toán lại khác so với logic thông
thương.Dưới đây là một vài phép toán cơ bản:
(A and B) = min (t(A), t(B)) – Phép Giao
(A or B) = max(t(A), t(B)) – Phép Hợp
11

(not - A) = 1 - t(A) - Phép phủ định
Các phép toán nay ảnh hưởng rất nhiều đến một thành phần quan
trọng của hệ Fuzzy là định khoảng giá trị. Đây cũng là cơ sở cho việc
thiết lập các luật trong hệ Logic mờ.
2.2.5 Biến ngôn ngữ.
Một biến ngôn ngữ quy định đến trường nào đó có giá trị nào đó,
hay nói cách khác nó chỉ đến một khoảng giá trị trong hệ thống fuzzy
logic. Giá trị của biến ngôn ngữ cũng là dạng từ ngữ. Thông thường,
người ta gắn các khoảng giá trị số cho một từ ngữ nào đó thể hiện
cho nó.
2.2.6 Các luật trong mô hình logic mờ
Các luật là thành phần điều khiển của một hệ thống logic mờ. Các
luật được thực hiện dựa trên câu lệnh IF……….THEN và một số
phép toán Logic khác như AND, OR, NOT….Trong một hệ thống,
nếu tập luật càng chính xác thì hiệu quả của hệ thống càng cao.
2.2.7 Qui trình hoạt động của Logic mờ

Hình 2.8 Quy trình hoạt động của hệ Logic mờ
2.2.8 Một số ứng dụng
Các hệ thống con của ô tô và các phương tiện giao thông khác, chẳng
hạn các hệ thống con như ABS và quản lý hơi (ví dụ Tokyo
monorail)
Máy điều hòa nhiệt độ
12


Camera
Xử lý ảnh số(Digital image processing), chẳng hạn như phát hiện
biên (edge detection)
Nồi cơm điện

Máy rửa bát
Thang máy
Trí tuệ nhân tạo trong trò chơi điện tử
Các bộ lọc ngôn ngữ tại các bảng tin, diễn đàn (message board) và
phòng chát để lọc bỏ các đoạn văn bản khiếm nhã

13


CHƢƠNG III: ỨNG DỤNG LOGIC MỜ VÀO BÀI TOÁN ƢỚC
LƢỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO MÔ
HÌNH AGILE
3.1 Mô hình tổng quan:
Đề xuất áp dụng logic mờ vào bài toán nỗ lực ước lượng,
đầu vào gồm có các bộ dữ liệu gồm: Số Story Point, hệ số ma sát,
mức độ thực hiện, yếu tố dao động.
Đầu ra là các thông số đã được xử lý: Tốc độ được ước
lượng, Story Size được ước lượng. Từ đó ta sẽ ước lượng được thời
gian và chi phí của quá trình phát triển dự án phần mềm

Hình 3.1 Mô hình đề xuất
Quy ƣớc:
Số Story point: SP
Hệ số ma sát: FR
14


Mức độ thực hiện: ILF
Yếu tố dao động: DF
Đầu ra là các thông số đã được xử lý: Tốc độ được ước lượng, Story

Size được ước lượng. Từ đó ta sẽ ước lượng được thời gian và chi
phí của quá trình phát triển dự án phần mềm
3.2 Bài toán ƣớc lƣợng nỗ lực phát triển phần mềm theo mô hình
Agile
Các khái niệm cơ bản:
- Tốc độ của dự án (Velocity): là tốc độ burn được bao
nhiêu điểm (point) trong một Sprint. Tốc độ dự án phụ thuộc vào các
yếu tố tác động đến dự án (sự biến động của nhóm, các công cụ phát
triển, lỗi nhà cung cấp….) và hệ số ma sát (thành phần đội, yếu tố
môi trường, thái độ thành viên….)
- User Story là gì? Là một bản tóm tắt nhu cầu người dùng.
Đây là công cụ được sử dụng phổ biến trong Extreme Programming
(XP), Scrum và các phương pháp linh hoạt khác để thể hiện nhu cầu
của người dùng.
User Story Point là đại lượng chỉ độ lớn tương đối của các
user story trong cùng một dự án.có thể có các loại sau: rất nhỏ, nhỏ,
vừa, lớn, rất lớn. Mức độ thực hiện của dự án bao gồm các yếu tố
phản ảnh mức độ hiểu biết về các thành phần của dự án bởi các thành
viên trong nhóm. Các mức độ có thể là: đầy đủ kinh nghiệm, một
phần kinh nghiệm, mới hoàn toàn….
Các bƣớc ƣớc lƣợng nỗ lực phát triển phần mềm theo
Agile
1. Định lượng các User Story theo point
2. Xác định vận tốc dự tính của nhóm
3. Xác định kích thước Sprint
4. Xác định số ngày làm việc, số lương chi trả của nhóm
5. Tính chi phí theo giờ, theo ngày, theo sprint của cả nhóm
6. Tính tổng chi phí dự tính của cả dự án
15

3.3 Áp dụng logic mờ vào bài toán ƣớc lƣợng nỗ lực phát triển
phần mềm
Để áp dụng loggic mờ vào bài toán ta sẽ xử lý dữ liệu đầu vào như
sau:

Hình 3.2 Mô hình xử lý dữ liệu
3.3.1 Xác định độ phức tạp (nỗ lực)
- Xác định Story Size:
- Xác định độ phức tạp:
Mức độ
Trọng số
Rất nhỏ (VSS)

1

Nhỏ (SS)

2

Vừa phải (MS)

3

Lớn (LS)

5

Rất lớn (VLS)

8

Bảng 3.3 Trọng số các User Story
Thành phần của nhóm sẽ có gồm có yếu tố: Thành viên mới,
có một phần kinh nghiệm, có kinh nghiệm, cơ hữu. Tương tự, sau khi
16


xác định được thành phần của nhóm ta cũng sử dụng dãy số Fibonaci
để đánh giá mức độ yếu tố thành phần của nhóm.
Yếu tố
Trọng số
Cơ hữu (OS)

1

Kinh nghiệm (FEC)

2

Một phần kinh nghiệm (PEC)

3

Thành viên mới (NC)

5

Bảng 3.4 Yếu tố thành phần nhóm
Độ phức tạp

Trọng số

Rất nhỏ

1

Nhỏ

2

Vừa phải

3

Lớn

5
Bảng 3.5 Giá trị độ phức tạp

3.3.2 Xác định vận tốc
+ Xác định hệ số ma sát FR:
Hệ số ma sát FR được tính theo công thức.
FR =
+ Xác định hệ số dao động DF
Hệ số dao động được tính theo công thức:
DF =
Sau khi đã tìm ra được các giá trị ta sẽ ước lượng thời gian
và chi phí theo các công thức sau:
17

+ Thời gian hoàn thành:
T=
Trong đó:
- ES là tổng số Story Point được ước lượng, ES được tính
bằng tổng số User Story x với Độ phức tạp và được tính theo công
thức.
ES=Com*Size
- Vi: là tốc độ ban đầu của dự án được tính bằng công thức:
Vi=Tốc độ của nhóm/kích thước 1 Sprint
- D: là mức độ ảnh hưởng đến vận tốc, được tính theo công
thức:
D=FR*DF
Với:
+ Chi phí
COST=1.681*TS*T
3.3 Tóm tắt các bƣớc thực hiện:
Đầu vào:
- Tổng số User Story
- Số ngày làm việc trong tháng
- Lương tháng của nhóm
- Số ngày trong 1 Sprint
- Số đơn vị nỗ lực trong 1 Sprint
- Mức độ tin cậy
Các dữ liệu mờ:
- Các yếu tố xác định kích thước Story (bảng 3.1, bảng 3.4)
- Các yếu tố xác định độ phức tạp Story (bảng 3.2, bảng 3.5)
- Các yếu tố xác định hệ số ma sát (bảng 3.6)
- Các yếu tố xác định hệ số dao động (bảng 3.7)

Kết quả:
- Thời gian T được tính theo công thức:
18


T=
- Tổng số Story Point được ước lượng
ES=Com*Size
- Tốc độ ban đầu của dự án được tính bằng công thức:
Vi=Tốc độ của nhóm/kích thước 1 Sprint
- Mức độ ảnh hưởng đến vận tốc:
D=FR*DF
- Hệ số ma sát:
FR =
- Yếu tố dao động:

- Chi phí
COST=1.681*TS*T
3.4 Ví dụ minh họa.
Đầu vào:
- Số User Story: 53
- Tốc độ của nhóm: 5.1
- Sprint size: 10
- Số ngày làm việc trong tháng: 22
- Lương tháng: 5000000
- Các yếu tố ảnh hưởng hệ số ma sát: FR (lấy từ bảng minh
họa)
FR =
- Các yếu tố ảnh hưởng mức độ thực hiện: ILF (lấy từ bảng
minh họa)

19


Kết quả
- Tổng nỗ lực: 300
- Tốc độ ban đầu dự án: 5.1
- Hệ số ma sát: 0.7043
- Hệ số dao động: 0.7675
- Độ giảm tốc: 0.5405
- Vận tốc: 2.4
- Thời gian: 5.6
- Chi phí: 47755
3.5 Chƣơng trình ứng dụng
Trong đề đề tài tôi minh họa ứng dụng ước lượng nỗ lực phát
triển phần mềm theo mô hình Agile với các chức năng sau:
- Xác định độ phức tạp: Người dùng sẽ thêm các Userstory
kèm theo các điều kiện về Story Size và thành phần nhóm, chương
trình sẽ ước lượng tổng nỗ lực của dự án.

Hình 3.9 Giao diện xác định độ phức tạp

20


- Xác đinh tốc độ: người dùng sẽ chọn những yếu tố tác động
đế tốc độ dự án bao gồm 9 yếu tố tác động đến hệ số dao động và 4
yếu tố tác động đến hệ số ma sát.

Hình 3.10 Giao diện xác định tốc độ

21


- Dự đoán kết quả: Sau khi có các thông số, chương trình sẽ
dự đoán các giá trị như: vận tốc, thời gian, chi phí thực hiện dự án.

Hình 3.11 Giao diện dự đoán

22