Dự đoán nỗ lực phát triển phần mềm theo quy trình agile sử dụng thuật toán tối ưu bày đàn

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

TRẦN THÁI BẢO

DỰ ĐOÁN NỖ LỰC PHÁT TRIỂN PHẦN MỀM
THEO QUY TRÌNH AGILE
SỬ DỤNG THUẬT TOÁN TỐI ƯU BẦY ĐÀN

LUẬN VĂN THẠC SĨ KỸ THUẬT

Đà Nẵng - Năm 2017


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

TRẦN THÁI BẢO

DỰ ĐOÁN NỖ LỰC PHÁT TRIỂN PHẦN MỀM
THEO QUY TRÌNH AGILE
SỬ DỤNG THUẬT TOÁN TỐI ƯU BẦY ĐÀN
Chuyên ngành: Khoa học máy tính
Mã số:

60.48.01.01

LUẬN VĂN THẠC SĨ KỸ THUẬT

Người hướng dẫn khoa học: TS. LÊ THỊ MỸ HẠNH

Đà Nẵng - Năm 2017


i

LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi. Các số liệu, kết quả
nêu trong luận văn là hoàn toàn trung thực và chưa từng được ai công bố trong bất kỳ
công trình nào khác.
Tác giả luận văn

TRẦN THÁI BẢO


ii

TRANG TÓM TẮT ĐỀ TÀI
DỰ ĐOÁN NỖ LỰC PHÁT TRIỂN PHẦN MỀM
THEO QUY TRÌNH AGILE SỬ DỤNG THUẬT TOÁN TỐI ƯU BẦY ĐÀN
Học viên: TRẦN THÁI BẢO
Mã số: 60.48.01.01

Khóa: 31

Chuyên ngành: Khoa học máy tính
Trường Đại học Bách khoa - ĐHĐN

Tóm tắt - Trong các quy trình phát triển phần mềm hiện đại, ước lượng nỗ lực phát triển
phần mềm đóng một vai trò quan trọng. Sự thành công hay thất bại của dự án phụ thuộc
rất lớn vào độ chính xác của kết quả ước lượng nỗ lực và tiến độ thực hiện. Ngày này,

nhiều nghiên cứu tập trung vào việc đề xuất các mô hình mới để nâng cao tính chính xác
của các kết quả dự đoán; Tuy nhiên, vấn đề đánh giá chính xác nỗ lực là một vấn đề đầy
thách thức đối với các nhà nghiên cứu, đặc biệt là khi nói đến các dự án sử dụng các
phương pháp linh hoạt (Agile). Nghiên cứu này nhằm mục đích đề xuất thuật toán tối ưu
hóa bầy đàn (PSO – Particle Swarm Optimization) để tối ưu hóa các thông số của công
thức đã được đề xuất trước đó [9] dựa trên tốc độ nhóm và các yếu tố về Story Point. Các
kết quả thực nghiệm chỉ ra rằng phương pháp tiếp cận của tôi đã vượt trội hơn các
phương pháp trong các nghiên cứu khác về tính chính xác của các kết quả dự đoán.
Từ khóa - Ước lượng nỗ lực phần mềm; phát triển phần mềm linh hoạt; User Story; tối
ưu bầy đàn; thuật toán tối ưu hóa.

AGILE SOFTWARE DEVELOPMENT EFFORT ESTIMATION USING
PARTICLE SWARM OPTIMIZATION ALGORITHM
Abstract - In modern software development processes, estimating software development
efforts plays an important role. The success or failure of projects depends greatly on the
accuracy of effort estimation and schedule results. Nowadays, Many studies focus on
proposing novel models to enhance the accuracy of predicted results; However, the
question of accurate estimation of effort has been a challenging issue with regards to
researchers, especially when it comes to projects using agile methodologies. This study
aims to use a Particle Swarm Optimization (PSO) algorithm to optimize the parameters of
the previously proposed estimation formula [9] based on the group velocity and the
factors of Story Point. The experimental results indicated that our approaches
outperformed methods in other studies in terms of the accuracy of predicted results.
Key words - Software effort estimation; agile software development; user story; particle
swarm optimization; swarm optimization algorithm.


iii

MỤC LỤC

L
LỜI CAM ĐOAN ............................................................................................................i
TRANG TÓM TẮT ĐỀ TÀI .......................................................................................... ii
MỤC LỤC ..................................................................................................................... iii
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT .................................................vi
DANH MỤC CÁC BẢNG ........................................................................................... vii
DANH MỤC CÁC HÌNH .......................................................................................... viii
MỞ ĐẦU .........................................................................................................................1
1. Lý do chọn đề tài .........................................................................................................1
2. Mục đích và ý nghĩa của đề tài ....................................................................................1
3. Mục tiêu và nhiệm vụ ..................................................................................................2
4. Đối tượng và phạm vi nghiên cứu ...............................................................................3
5. Phương pháp nghiên cứu .............................................................................................3
6. Phương tiện và công cụ triển khai ...............................................................................3
7. Dự kiến kết quả đạt được.............................................................................................4
8. Nội dung nghiên cứu và dự kiến cấu trúc luận văn .....................................................4
CHƯƠNG 1. CƠ SỞ LÝ THUYẾT ................................................................................6
1.1. ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM ..........................................6
1.1.1. Khái niệm .............................................................................................................6
1.1.2. Bốn bước cơ bản trong ước lượng dự án phần mềm Bốn bước chính trong ước
lượng dự án phần mềm là: ...............................................................................................8
1.2.1. Ước lượng kích cỡ, phạm vi ..................................................................................8
1.1.2.2. Ước lượng nỗ lực ................................................................................................9
1.1.2.3. Ước lượng lịch trình .........................................................................................10
1.1.2.4. Ước lượng chi phí .............................................................................................11
1.1.3. Các phương pháp ước lượng nỗ lực ...................................................................13
1.1.3.1. Ước lượng chuyên gia ......................................................................................13
1.1.3.2. Ước lượng đánh giá bằng kinh nghiệm quá khứ ..............................................13
1.1.3.3. Ước lượng đánh giá bằng các mô hình ước lượng thực nghiệm ......................13
1.2. MÔ HÌNH PHÁT TRIỂN PHẦN MỀM AGILE ..................................................14

1.2.1. Sự cần thiết của một mô hình phát triển phần mềm mới ....................................14
1.2.2. Tìm hiểu chung về Agile ....................................................................................14
1.2.2.1. Tuyên ngôn của Agile .......................................................................................15
1.2.2.2. Các quy tắc của Agile .......................................................................................19
1.2.2.3. Các đặc trưng của Agile ...................................................................................20
1.2.3. Quy trình vận hành Agile ....................................................................................23


iv

1.2.3.1. Lập kế hoạch.....................................................................................................23
1.2.3.2. Phân tích ...........................................................................................................23
1.2.3.3. Thiết kế và lập trình ..........................................................................................23
1.2.3.4. Kiểm thử (Test) .................................................................................................24
1.2.3.5. Bàn giao sản phẩm ...........................................................................................24
1.3. CÁC PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT ....................24
1.3.1. Các khái niệm trong SCRUM .............................................................................25
1.3.2. Lập kế hoạch Sprint ............................................................................................26
CHƯƠNG 3. THUẬT TOÁN TỐI ƯU BẦY ĐÀN .....................................................29
2.1. GIỚI THIỆU ..........................................................................................................29
2.1.1. Bài toán tối ưu tổng quát và phân loại ................................................................29
2.1.1.1. Giới thiệu bài toán tối ưu tổng quát ..................................................................29
2.1.1.2. Phân loại các bài toán tối ưu.............................................................................30
2.1.2. Trí tuệ bầy đàn ....................................................................................................30
2.2. MÔ PHỎNG HÀNH VI KIẾM MỒI CỦA ĐÀN CHIM .....................................31
2.3. KIẾN TRÚC THUẬT TOÁN PSO .......................................................................32
2.4. TRIỂN KHAI VÀ CÀI ĐẶT THUẬT TOÁN ......................................................36
2.4.1. Biểu diễn bằng mã giả ........................................................................................36
2.4.2. Lưu đồ thuật toán................................................................................................ 38
2.4.3. Quy trình thực hiện ..............................................................................................39

TIỂU KẾT CHƯƠNG 2: ...............................................................................................39
CHƯƠNG 3. ỨNG DỤNG THUẬT TOÁN TỐI ƯU BẦY ĐÀN ƯỚC LƯỢNG ......40
NỖ LỰC PHÁT TRIỂN PHẦN MỀM THEO QUY TRÌNH AGILE ..........................40
3.1. PHÂN TÍCH BÀI TOÁN ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM
THEO QUY TRÌNH AGILE.........................................................................................40
3.1.1. Mô hình tổng quan của bài toán .........................................................................41
3.1.2. Ước lượng trong mô hình Agile .........................................................................41
3.1.2.1. Các khái niệm cơ bản .......................................................................................41
3.1.2.2. Xác định nỗ lực (Story point) ...........................................................................43
3.1.2.3. Xác định vận tốc dự án (Agile Velocity) ..........................................................46
3.2. ÁP DỤNG THUẬT TOÁN BẦY ĐÀN ĐỂ ƯỚC LƯỢNG NỖ LỰC PHÁT
TRIỂN PHẦN MỀM .....................................................................................................49
3.2.1. Đề xuất giải pháp ước lượng nỗ lực phát triển phần mềm theo quy trình Agile
.......................................................................................................................................49
3.2.2. Đo lường chất lượng dự đoán .............................................................................50
3.2.3. Biểu diễn cá thể của thuật toán PSO và hàm thích nghi cho bài toán dự đoán
.......................................................................................................................................51
3.2.4. Bộ dữ liệu thực nghiệm .....................................................................................52
3.2.5. Thực nghiệm .......................................................................................................53


v

3.2.5.1. Thiết lập thông số .............................................................................................53
3.2.5.2. Huấn luyện........................................................................................................53
3.2.5.3. Đánh giá kết quả đạt được ................................................................................54
3.3.KẾT LUẬN ............................................................................................................55
TIỂU KẾT CHƯƠNG 3 ................................................................................................56
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ....................................................................57
TÀI LIỆU THAM KHẢO .............................................................................................58

QUYẾT ĐỊNH GIAO ĐỀ TÀI.
BẢN SAO KẾT LUẬN CỦA HỘI ĐỒNG, BẢN SAO NHẬN XÉT CỦA CÁC
PHẢN BIỆN.


vi

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
STT

Ký hiệu/Viết tắt

Diễn giải

1

BDD

Behavior Driven Development - Phát triển hướng hành vi

2

COCOMO

Constructive Cost Model - Mô hình giá cấu thành

3

ER

Effort Rating - Tỉ lệ nỗ lực

4

FP

5

Iteration

6

LOC

7

Sprint

8

TDD

9

User Story

10

User Story Point

Function Point: Ước lượng kích cỡ của phần mềm được phát
triển theo chức năng, độ phức tạp
Phân đoạn;
Trong các phương pháp phát triển linh hoạt, iteration chỉ
một phân đoạn với khoảng thời gian ngắn nhằm phát triển
một phần nhỏ của hệ thống. Một dự án sẽ gồm nhiều phân
đoạn được lặp đi lặp lại
Line Of Code: Ước lượng kích cỡ của phần mềm được phát
triển theo số dòng lệnh
Phân đoạn nước rút trong Scrum;
Một phân đoạn là một chu kỳ lặp đi lặp lại công việc
tương tự nhằm tạo ra các phần tăng trưởng (increment)
cho hệ thống. Sprint thường kéo dài từ một tuần tới một
tháng. Trong suốt dự án, thời gian cho một Sprint là cố
định. Từ “sprint” có nghĩa là giai đoạn nước rút, ám chỉ sự
gấp gáp và tập trung cao độ trong khoảng thời gian ngắn
để làm việc.
Test Driven Development - Phát triển hướng kiểm thử
Là một bản tóm tắt về nhu cầu của 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. Thông thường, User Story do
khách hàng hoặc đại diện của khách hàng, người thực sự
hiểu về nghiệp vụ và nắm bắt được chính xác yêu cầu của
mình đối với nhóm phát triển.
Đại lượng chỉ độ lớn tương đối của các User Story trong
cùng một dự án. Trong một phiên hoạch định trước Sprint,
nhóm phát triển dùng Scrum Poker để đánh giá độ lớn, bé
các Story này và ghi các giá trị đó lên các User Story Card.

vii

DANH MỤC CÁC BẢNG
Số hiệu
bảng
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.

Tên bảng
Qui mô, kích thước của Story
Độ phức tạp của User Story
Các yếu tố ma sát
Các yếu tố thay đổi
Bộ dữ liệu được lấy từ Zia [7]
Phạm vi các tham số của mô hình đề xuất.
Kết quả nỗ lực ước lượng được huấn luyện từ 15 dự án
Kết quả thực nghiệm và so sánh các kết quả ước lượng

Trang
43
44
47
48

52
53
53
55


viii

DANH MỤC CÁC HÌNH
Số
hiệu
hình
1.1.
1.2.
1.3.
1.4.
2.1.
2.2.
2.3.
2.4.
3.1.

Tên hình
Đồ thị hội tụ ước lượng. Độ chính xác của ước lượng chỉ được
cải tiến trong quá trình phát triển. Nguồn tham khảo [1]
Tiến trình cơ sở ước lượng dự án.
Các phân đoạn lặp đi lặp lại trong mô hình Agile
Quy trình hoạt động của Scrum
Mô phỏng hành vi kiếm mồi của đàn chim
So sánh di chuyển của đàn kiến và đàn chim trong không gian

2 chiều
Sự thay đổi điểm tìm kiếm của PSO
Lưu đồ thuật toán
Sơ đồ của giải pháp được triển khai trong đề tài.

Trang

7
12
21
27
32
33
34
38
50


1

MỞ ĐẦU
1. LÝ DO CHỌN ĐỀ TÀI
Ước lượng nỗ lực phần mềm có một vai trò hết sức quan trọng trong quá trình
phát triển phần mềm. Sự thành công hay thất bại của dự án phụ thuộc rất lớn vào độ
chính xác của kết quả ước lượng nỗ lực và tiến độ. Do đó, đề tài được dự kiến để tìm
ra một phương pháp để ước lượng nỗ lực phát triển phần mềm chính xác. Kỹ thuật ước
lượng được chia làm ba loại dựa trên hàm toán học, kinh nghiệm của chuyên gia và
các phương pháp học máy. Sự đa dạng của các phương pháp phát triển phần mềm mới
đã dẫn đến sự hạn chế của phương pháp truyền thống.
Trong những năm gần đây, sự xuất hiện của quá trình phát triển phần mềm linh

hoạt (Agile) đã đáp ứng được tiến độ của các phương pháp công nghệ phần mềm mới.
Việc sử dụng các phương pháp linh hoạt cho phép các tổ chức đáp ứng sự biến động
trong chu trình phát triển phần mềm. Áp dụng một phương pháp ước lượng trong quá
trình phát triển phần mềm là một nhiệm vụ khó khăn mà chúng ta cần phải lường trước
kích thước và độ phức tạp của các sản phẩm sẽ được xây dựng để xác định những việc
cần làm tiếp theo. Phát triển phần mềm theo quy trình Agile đã trở nên phổ biến trong
ngành công nghiệp và thay thế các phương pháp tiếp cận thông thường của sự phát
triển phần mềm. Phát triển phần mềm linh hoạt là một nhóm các phương pháp và
phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn
lặp (Iterative) và tăng trưởng (Incremental), theo đó nhu cầu và giải pháp tiến hóa
thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng.
Trí thông minh của bầy đàn đã trở thành một sự quan tâm nghiên cứu của nhiều
nhà khoa học về các lĩnh vực liên quan trong những năm gần đây. Một loạt các khái
niệm mới, kỹ thuật và các ứng dụng tính toán lấy cảm hứng từ thiên nhiên đã được đề
xuất, được sử dụng để giải quyết với một loạt các vấn đề tối ưu hóa trong các lĩnh vực
đa dạng đã được chứng minh là có hiệu quả trong trong việc xử lý các vấn đề tính toán
phức tạp và nhiều thành công đã được công nhận. Đa số các phương pháp được lấy
cảm hứng từ hiện tượng sinh học hoặc các hành vi xã hội và chủ yếu là động vật, côn
trùng.
Dựa trên cơ sở của thuật toán lấy cảm hứng từ tự nhiên và bài toán ước lượng nỗ
lực phát triển phần mềm trong mô hình Agile, tôi đề xuất chọn đề tài luận văn cao học:
“Dự đoán nỗ lực phát triển phần mềm theo quy trình Agile sử dụng thuật
toán tối ưu bầy đàn”

2. MỤC ĐÍCH VÀ Ý NGHĨA CỦA ĐỀ TÀI
2.1. Mục đích
 Xây dựng ứng dụng hỗ trợ ước lượng thời gian, nỗ lực phát triển của dự
án phần mềm theo quy trình Agile.

2

 Giảm thiểu được thời gian, chi phí cho quá trình ước lượng nỗ lực phát
triển phần mềm.
 Dựa trên mức dự đoán của phần mềm ước lượng, sẽ đưa ra kế hoạch
hợp lý về mặt nhân sự, cơ sở vật chất, phần mềm công nghệ, đồng thởi
phải ước tính cần bao nhiêu chuyên gia, kỹ sư lập trình,… và đầu tư cho
những dự án có nhiều tiềm năng. Vì vậy, một phần mềm có khả năng
ước lượng thông minh và chuyên sâu về nỗ lực cần có cho một dự án
phần mềm sẽ cần thiết cho việc lập kế hoạch và dự toán chi phí của bất
kỳ dự án nào.
2.2. Ý nghĩa khoa học
 Nắm vững và vận dụng tốt mô hình phát triển Agile trong việc quản lý
dự án phần mềm.
 Nắm vững các thành phần và phương pháp ước lượng nỗ lực trong việc
quản lý dự án.
 Nắm vững và ứng dụng tốt thuật toán tối ưu bầy đàn để tối ưu các ước
lượng nỗ lực cần cho một dự án phần mềm.
 Kết quả của quá trình nghiên cứu có thể làm tài liệu tham khảo cho việc
ước lượng nỗ lực trong dự án phát triển phần mềm theo quy trình Agile.
2.3. Ý nghĩa thực tiển
Đề xuất giải pháp ước lượng nỗ lực phát triển phần mềm theo quy trình Agile
mang lại những ý nghĩa to lớn trong việc quản lý dự án phần mềm thực tế:
 Dự toán chi phí hợp lý trong việc sử dụng nhân sự, tài nguyên cho các
dự án phần mềm.
 Sự chính xác cao: Sự chính xác được đánh giá trên phương diện ước
tính chi phí và các nguồn lực trong dự án.
 Đảm báo tiến độ dự án theo đúng kế hoạch ban đầu.
 Kiểm soát dự án tốt hơn: Ước lượng phần mềm mang một cái nhìn tổng
quát về tiến độ, chi phí và khả năng thực thi của dự án. Dựa trên đó, sẽ

đễ dàng phát hiện và khắc phục các sự cố, rủi ro trong triển khai dự án.
 Bên cạnh việc ước lượng thời gian, chi phí với sự chính xác cao sẽ dẫn
tới sự thành công hay thất bại của dự án thì ước lượng nỗ lực phát triển
phần mềm còn là công cụ thể hiện sự chuyên nghiệp của công ty.
3. MỤC TIÊU VÀ NHIỆM VỤ
3.1. Mục tiêu
Mục tiêu chính của đề tài là ước lượng nỗ lực phát triển phần mềm. Để thực
hiện được mục tiêu này cần đạt được:


3

 Nắm vững kiến thức về mô hình phát triển phần mềm Agile
 Hiểu biết về ước lượng nỗ lực phát triển phần mềm
 Nắm vững kiến thức về thuật toán tối ưu bầy đàn (PSO)
 Áp dụng được thuật toán PSO để tối ưu hóa các tham số vào việc ước
lượng nỗ lực phát triển phần mềm theo mô hình Agile.
3.2. Nhiệm vụ
 Nghiên cứu về thuật toán PSO
 Nghiên cứu lý thuyết về ước lượng nỗ lực phát triển phần mềm theo quy
trình Agile
 Sử dụng thuật toán PSO để tối ưu các tham số được sử dụng trong công
thức ước lượng nỗ lực phát triển phần mềm theo quy trình Agile
 Phân tích và cài đặt thuật toán cho bài toán ước lượng nỗ lực
 Đánh giá kết quả theo yêu cầu của đề tài.
4. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU
4.1. Đối tượng nghiên cứu
 Nghiên cứu thuật toán tối ưu bầy đàn (PSO)
 Cơ sở lý thuyết về phát triển phần mềm theo quy trình Agile.
4.2. Phạm vi nghiên cứu

 Nghiên cứu thuật toán dựa trên hành vi kiếm mồi của đàn chim
 Nghiên cứu về ước lượng nỗ lực phát triển phần mềm theo mô hình
Agile.
5. PHƯƠNG PHÁP NGHIÊN CỨU
Sử dụng kết hợp nhiều phương pháp, trong đó chủ yếu là nghiên cứu lý thuyết
và nghiên cứu thực nghiệm.
5.1. Phương pháp nghiên cứu lý thuyết:
 Tìm hiểu, tra cứu, phân tích và tổng hợp từ sách, các bài báo, tạp chí
khoa học, các trang web, các bài luận văn thạc sĩ trong nước và nước
ngoài có liên quan đến đề tài.
5.2. Phương pháp thực nghiệm:
 Cài đặt và áp dụng thuật toán tối ưu bầy đàn để dự đoán nỗ lực phát
triển phần mềm theo quy trình Agile
 So sánh và đánh giá kết quả.
6. PHƯƠNG TIỆN VÀ CÔNG CỤ TRIỂN KHAI
 Máy tính cài đặt hệ điều hành Windows


4

 Môi trường phát triển phần mềm Matlab
7. DỰ KIẾN KẾT QUẢ ĐẠT ĐƯỢC
7.1 Về lý thuyết
 Hiểu được khái niệm, tính chất của thuật toán tối ưu bầy đàn
 Hiểu được cách phát triển phần mềm theo quy trình Agile
 Hiểu và triển khai việc ước lượng nỗ lực phát triển phần mềm theo
quy trình Agile.
7.2 Về thực nghiệm
 Đề xuất giải pháp ước lượng nỗ lực phát triển phần mềm theo quy trình
Agile sử dụng thuật toán tối ưu bầy đàn

 Đánh giá hiệu quả của giải pháp đề xuất.
8. NỘI DUNG NGHIÊN CỨU VÀ DỰ KIẾN CẤU TRÚC LUẬN VĂN
8.1 Nội dung nghiên cứu
 Thu thập và tổng hợp các tài liệu liên quan đến thuật toán bầy đàn nói chung
và thuật toán đàn chim kiếm mồi nói riêng
 Thu thập, tổng hợp và phân tích kỹ thuật ước lượng nỗ lực phát triển phần
mềm theo mô hình Agile
 Ứng dụng thuật toán đàn chim kiếm mồi để ước lượng nỗ lực phát triển
phần mềm theo mô hình Agile
 Thu thập, phân tích các kết quả; từ đó đánh giá hiệu quả giải thuật.
8.2 Dự kiến bố cục luận văn
Mở đầu
-

Tính cấp thiết của đề tài

-

Mục tiêu của luận văn

-

Ý nghĩa thực tiễn

-

Đối tượng và phạm vi nghiên cứu

-

Dự kiến kết quả đạt được

Chương 1: Cơ sở lý thuyết
-

Tổng quan

-

Tiếp cận ước nỗ lực phát triển phần mềm theo quy trình Agile

-

Mô hình ước lượng nỗ lực cho các dự án Agile

-

Quy trình vận hành Agile

-

Một số phương pháp phát triển phần mềm theo quy trình Agile

Chương 2: Thuật toán tối ưu bầy đàn


5

-

Giới thiệu

-

Kiến trúc thuật toán PSO

-

Mô phỏng hành vi kiếm mồi của đàn chim

-

Triển khai và cài đặt thuật toán

Chương 3: Ứng dụng thuật toán tối ưu bầy đàn ước lượng nỗ lực phát triển
phần mềm theo quy trình Agile.
-

Giới thiệu

-

Thu thập dữ liệu, phân tích, mô hình đánh giá

-

Áp dụng thuật toán để ước lượng nỗ lực phát triển phần mềm

-

Đánh giá hiệu suất của thuật toán bầy đàn

-

So sánh thuật toán so với một số thuật toán hiện có

Kết luận và hướng phát triển


6

CHƯƠNG 1

CƠ SỞ LÝ THUYẾT
Trong các quy trình phát triển phần mềm hiện đại, ước lượng nỗ lực phát triển
phần mềm đóng một vai trò quan trọng. Sự thành công hay thất bại của dự án phụ
thuộc rất lớn vào độ chính xác của kết quả ước lượng nỗ lực và tiến độ thực hiện.
Công việc đầu tiên của người quản lý dự án là ước lượng - ước lượng về kích cỡ, về
chi phí, về thời gian tiến hành dự án. Việc này thông thường được tiến hành bằng
cách phân rã phần mềm cần phát triển thành các khối nhỏ và áp dụng các kinh
nghiệm (các thông số như kích cỡ, chi phí, năng lực nhân viên, ...) đối với các phần
mềm đã phát triển trước đó, đánh giá công việc. Ngày nay, nhiều nghiên cứu tập
trung vào việc đề xuất các mô hình mới để nâng cao tính chính xác của các kết quả
dự đoán. Trong chương này, tôi trình bày cơ sở lý thuyết về ước lượng nỗ lực và mô
hình phát triển phần mềm Agile.
1.1. ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM
1.1.1. Khái niệm
Ước lượng dự án phần mềm hiệu quả là một hoạt động quan trọng, đồng thời
cũng là một thách thức trong phát triển phần mềm. Ước lượng là một trong những
nền tảng cho việc lập lịch dự án một cách hiệu quả. Lập kế hoạch và điều khiển dự

án có hiệu quả là không thể nếu không có một ước lượng đầy đủ và đáng tin cậy.
Nhiều tổ chức phải chịu các tác động tài chính lên công việc của họ, bị mất lợi thế
cạnh tranh và chậm trễ trong việc hưởng lợi từ kế hoạch và các sáng kiến do các kết
quả ước lượng xấu.
Hình 1.1 (được trích từ tài liệu tham khảo [1]) thể hiện độ hội tụ của ước lượng
trong vòng đời phát triển của các dự án thực tế, ước lượng chỉ được chính xác hóa
dần trong quá trình làm mịn dần dự án. Từ hình 1.1 có thế nhận thấy rằng để đưa ra
được các ước lượng đáng tin cậy và sớm trong vòng đời phát triển của dự án là rất
khó do đó chúng ta cần tập trung nhiều nỗ lực để giải quyết vấn đề này.
Ước lượng thiếu nỗ lực cho một dự án dẫn đến (a) việc bố trí thiếu nhân lực
cho dự án (điều mà thường dẫn đến việc vượt quá khả năng làm việc), (b) quản lý
thiếu các nỗ lực đảm bảo chất lượng (bỏ sót các nguy cơ rủi ro của sản phẩm kém
chất lượng) và (c) tạo ra một lịch trình làm việc quá ngắn (dẫn đến sự mất uy tín do
thời hạn thỏa thuận với khách hàng không được tôn trọng).
Còn đối với những người mà mong muốn tránh khỏi tình huống này bằng cách
thêm nhiều yếu tố thừa vào ước lượng thì ước lượng thừa cho một dự án có thể làm
ảnh hưởng thêm cho tổ chức. Nếu như đưa cho một dự án với nhiều tài nguyên hơn
mức nó thực sự cần mà không có sự quản lý thì tài nguyên đó sẽ bị dùng hết. Điều
này giống như định luật Parkinson được trích từ tài liệu tham khảo [2]:


7

“Một công việc sẽ chiếm trọn vẹn thời gian dự kiến có để hoàn thành công việc đó!”
Ví dụ: Cường là một thành viên nhóm dự án và anh được giao hai tuần để hoàn
thành bảng báo cáo dự báo thị trường. Mặc dù có khả năng hoàn thành công việc đó
chỉ trong vài ngày nhưng anh vẫn dàn trải công việc ra trong khoản thời gian hai
tuần đó để hoàn thành bảng báo cáo.
Dự án khi đó có khả năng phải (a) chi phí nhiều hơn mức cần thiết (một tác
động tiêu cực đến tài chính và có thể làm giảm lợi thế cạnh tranh), (b) mất nhiều

thời gian hơn để hoàn thành (dẫn đến đánh mất các cơ hội) và (c) trì hoãn việc sử
dụng tài nguyên ở các dự án tiếp theo.

Hình 1.1. Đồ thị hội tụ ước lượng. Độ chính xác của ước lượng chỉ được cải tiến trong
quá trình phát triển. Nguồn tham khảo [1]
Ước lượng dự án hiện là một vấn đề khó khăn trong thực tế sản xuất phần mềm.
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. Mức
ước lượng có thể có nhiều sai sót trong các giai đoạn khác nhau do đó thực tế không
dự án nào có thể ước lượng chính xác. Ước lượng chỉ có thể chính xác nếu phân rã
được vấn đề lớn thành các vấn đề nhỏ hơn, đó là kỹ thuật chia để trị.


8

1.1.2. Bốn bước cơ bản trong ước lượng dự án phần mềm
Bốn bước chính trong ước lượng dự án phần mềm là:
1) Ước lượng phạm vi của sản phẩm cần phát triển. Thông thường, điều này
luôn yêu cầu một ước lượng kích cỡ của phần mềm được phát triển theo số
dòng lệnh (LOC – Line Of Code) hoặc điểm chức năng (FP – Function
Point). Trong khi kích cỡ theo LOC là đơn vị kích cỡ cơ sở được dùng bởi
nhiều mô hình tính toán ước lượng hàng đầu, nhiều nhóm phát triển lại
không thích những phép đo này và dùng những đơn vị ít chính quy hơn (số
đặc tính, số yêu cầu thay đổi, số ca sử dụng/số kịch bản, số tường thuật
người dùng, số phát biểu yêu cầu, …).
2) Ước lượng nỗ lực theo đơn vị [người – tháng] hoặc [người – giờ] dùng một
mô hình tính toán liên hệ nỗ lực với kích cỡ của phần mềm và năng suất của
nhóm phát triển.
3) Ước lượng lịch trình theo lịch thời gian (tháng/tuần). Điều này có thể được
tính toán từ nỗ lực được ước lượng và là một hàm số của kích cỡ nhóm phát
triển. Điều quan trọng là phải nhận thức rõ rằng đây không phải là một quan

hệ tuyến tính và ở một số điểm trong lịch trình dự án không thể rút ngắn
lịch trình bằng cách thêm tài nguyên cho việc phát triển.
4) Ước lượng chi phí dự án theo đơn vị tiền tệ. Điều này là một kết hợp của giá
nhân công (có thể được tính toán từ ước lượng nỗ lực) và giá phi nhân công
(ví dụ, giá khấu hao của các phần cứng và phần mềm cần thiết được cung
cấp cho dự án).
1.1.2.1. Ước lượng kích cỡ, phạm vi
Một ước lượng chính xác kích cỡ của phần mềm được xây dựng là bước đầu
tiên cho một ước lượng có hiệu quả. Các tài nguyên thông tin về phạm vi của dự án
nên được thu thập bất cứ nơi nào có thể, bắt đầu với những mô tả chính xác của các
yêu cầu. Ví dụ, một đặc tả các yêu cầu của khách hàng hoặc một đặc tả về hệ thống.
Không nên để cho sự thiếu sót về đặc tả phạm vi làm cản trở việc thực hiện ước
lượng. Tài liệu ước lượng cũng không nên chốt cứng. Trong mọi trường hợp, chúng
ta phải xem xét các mức độ rủi ro và không chắc chắn trong một ước lượng cho mọi
khía cạnh và phải thực hiện lại ước lượng cho dự án ngay khi có thêm thông tin
phạm vi được xác định. Nếu chúng ta thực hiện ước lượng lại một dự án ở những
pha sau của vòng đời dự án, các tài liệu thiết kế có thể được sử dụng để cung cấp
thêm thông tin chi tiết.
Hai cách để có thể ước lượng kích cỡ sản phẩm là:
1) Cách thứ nhất: Bằng phép tương tự.
Nếu chúng ta đã hoàn thành một dự án tương tự trong quá khứ và biết thông tin
kích cỡ sản phẩm đã được phát triển, chúng ta có thể ước lượng mỗi phần chính của


9

dự án mới như là một phép tính phần trăm về kích cỡ phần tương tự với dự án
trước. Ước lượng kích cỡ tổng thể dự án mới bằng cách cộng lại các kích cỡ được
ước lượng của mỗi phần hoặc chia sản phẩm thành những phần cấu thành (các đặc
tính, các ca sử dụng/kịch bản, các yêu cầu người dùng) và đếm chúng. Một số người

dùng những phép đếm thô như là một ước lượng trực tiếp của kích cỡ phần mềm
hoặc chúng ta có thể chuyển chúng thành một đơn vị đo kích cỡ chính thức mà ta
biết, theo một phép tính trung bình, bao nhiêu LOC hoặc FP mà mỗi phần này yêu
cầu trong những dự án trước.
Một người có kinh nghiệm có thể đưa ra những ước lượng kích cỡ tốt, hợp lý
bằng phép tương tự nếu sẵn có các giá trị kích cỡ chuẩn xác của dự án trước và dự
án mới là gần giống với dự án trước.
2) Cách thứ hai: Bằng phép phân tích.
Bằng cách đếm các đặc tính của sản phẩm và dùng một phương pháp như là
điểm chức năng (FP) chúng ta có thể chuyển phép đếm thành một ước lượng của
kích cỡ.
Các đặc tính sản phẩm ở cấp độ vĩ mô có thể chứa các hệ thống con, các
lớp/mô đun, các phương thức/hàm. Các đặc tính sản phẩm ở mức chi tiết hơn có thể
gồm có số lượng các màn hình, các hộp thoại, các tập tin, các bảng cơ sở dữ liệu,
các báo cáo và các thông điệp, …
1.1.2.2. Ước lượng nỗ lực
Một khi chúng ta có một ước lượng kích cỡ của sản phẩm, chúng ta có thể tính
toán ước lượng nỗ lực từ nó. Việc chuyển đổi từ kích cỡ phần mềm sang tổng nỗ
lực của dự án chỉ có thể làm được nếu chúng ta có một vòng đời phát triển phần
mềm xác định và tiến trình phát triển mà ta sử dụng ổn định trên dự án để phân tích,
thiết kế, phát triển và kiểm thử phần mềm.
Một dự án phát triển phần mềm đòi hỏi nhiều yêu cầu hơn công việc viết mã
nguồn đơn thuần. Trên thực tế, việc mã hóa chỉ chiếm chưa đến ¼ tổng thể nỗ lực
dự án. Việc viết và thẩm định tài liệu, thi hành các bản mẫu, thiết kế các phiên bản
có thể phân phối và thẩm định, kiểm thử mã nguồn chiếm phần lớn thời gian của nỗ
lực dự án tổng thể. Ước lượng nỗ lực dự án yêu cầu ta xác định và ước lượng về
thời gian, về nhân lực,… Sau đó tổng hợp lại tất cả các hoạt động ta phải thực hiện
để xây dựng sản phẩm từ kích cỡ được ước lượng.
Hai cách có thể dùng để tính toán nỗ lực từ kích cỡ:
a) Cách thứ nhất: Dùng dữ liệu lịch sử

Dùng dữ liệu của các dự án đã phát triển trước đây của chính tổ chức để xác
định bao nhiêu nỗ lực theo kích cỡ ước lượng mà các dự án đó dùng đến. Một sơ đồ
tính toán liên hệ kích cỡ của sản phẩm và năng suất của nhóm phát triển với nỗ lực


10

dự án được sử dụng thường xuyên cho mục đích này. Dĩ nhiên, cách thức này giả
định rằng (1) tổ chức của chúng ta đã lập tài liệu các kết quả thực tế từ các dự án
trước (2) chúng ta có ít nhất một dự án trong quá khứ với kích cỡ tương tự (tốt hơn
nếu chúng ta có nhiều dự án với kích cỡ tương tự để củng cố và ổn định một mức
độ nào đó của nỗ lực để phát triển các dự án của kích cỡ được đưa ra) và (3) chúng
ta sẽ tuân theo một vòng đời phát triển tương tự, sử dụng một phương pháp phát
triển tương tự, các công cụ tương tự và có một nhóm phát triển với các kỹ năng,
kinh nghiệm tương tự cho dự án mới.
b) Cách thứ hai: Tiếp cận thuật toán
Nếu chúng ta không có dữ liệu lịch sử của chính tổ chức bởi vì chúng ta chưa
bắt đầu thu thập số liệu hoặc vì dự án mới là rất khác so với các dự án trước đó,
chúng ta có thể sử dụng một cách tiếp cận thuật toán đã hoàn thiện và đã được công
nhận rộng rãi (ví dụ mô hình COCOMO của Barry Boehm) để chuyển một ước
lượng kích cỡ thành một ước lượng nỗ lực. Các mô hình này có được từ việc nghiên
cứu một số lượng lớn các dự án đã hoàn thành từ nhiều tổ chức khác nhau để xem
xét các kích cỡ dự án ánh xạ như thế nào với nỗ lực dự án tổng cộng. Các mô hình
“dữ liệu công nghiệp” có thể không được chuẩn xác như là dữ liệu lịch sử của chính
tổ chức nhưng chúng có thể cho chúng ta những ước lượng nỗ lực gần đúng,
hữu ích.
1.1.2.3. Ước lượng lịch trình
Bước thứ ba trong ước lượng một dự án phát triển phần mềm là ước lượng lịch
trình dự án. Điều này thường đòi hỏi ước lượng số lượng người sẽ làm việc trên dự
án, cái gì họ sẽ làm (cấu trúc phân cấp chia nhỏ công việc), khi nào họ sẽ bắt đầu

làm việc trên dự án và khi nào họ sẽ kết thúc. Một khi chúng ta có những thông tin
này, chúng ta cần tính toán để đưa nó vào một lịch trình theo lịch thời gian. Ngoài
ra, dữ liệu lịch sử từ các dự án trong quá khứ của tổ chức hoặc các mô hình dữ liệu
công nghiệp có thể được sử dụng để dự đoán số lượng người mà chúng ta cần cho
một dự án với kích cỡ cho trước và làm thế nào công việc có thể chia nhỏ vào lịch
trình.
Nếu chúng ta không có gì, một quy tắc ước lượng lịch trình [1] có thể được
dùng để lấy các ý tưởng thô của lịch thời gian tổng cổng cần thiết:
Lịch trình theo tháng = 3.0 * (nỗ lực [người - tháng])1/3
Ví dụ, nếu chúng ta đã ước lượng một dự án cần nỗ lực là 65 [người – tháng],
biểu thức trên cho thấy rằng cần lịch trình 12 tháng (3.0*651/3), từ đó suy ra nhóm
dự án có 5 hoặc 6 thành viên (65/12).


11

Trong tài liệu tham khảo [1], tác giả có nêu vấn đề nhiều đề xuất dùng giá trị
2.0, 2.5 hay ngay cả 4.0 để thay thế cho giá trị 3.0 – chỉ bằng cách tiến hành thực
nghiệm thì chúng ta mới có thể chọn được giá trị phù hợp.
Ước lượng lịch trình dự án là một chủ đề rắc rối bởi vì hầu hết các dự án
thường bị chậm trễ và sự chậm trễ do nhiều nguyên nhân. Các yêu cầu được phát
hiện dần dần không được quản lý chủ động. Việc điều khiển chất lượng sản phẩm từ
sớm thường không được chú trọng, dẫn đến dự án sẽ bị chậm trễ khi pha kiểm thử
bắt đầu. Ở những tổ chức chưa có quy trình làm việc chuẩn thì những dự thảo lịch
trình thường bị bỏ qua ngay cả với những người điều hành cấp cao.
Xem xét công việc quản trị dự án và công việc ước lượng lịch trình, chúng ta
thấy rằng công việc ước lượng lịch trình sẽ quan tâm đến việc lên lịch trình ở mức
độ cao của toàn dự án, còn những tính toán chi tiết hơn đòi hỏi các yếu tố phụ
thuộc, đội ngũ nhân viên sẵn có, mức độ tài nguyên, phân công cho từng người sẽ
được thực hiện bởi công việc quản trị dự án.

Nếu ước lượng theo biểu thức tính lịch trình ở trên, ta ước lượng thời gian lịch
trình trước sau đó mới chỉ định số nhân viên. Nhưng nếu được chỉ định một nhóm
phát triển trước, một biểu thức cơ bản cho việc ước lượng lịch trình của bất kỳ hoạt
động quản lý là:
Nỗ lực / Số nhân viên = Lượng thời gian
Dùng biểu thức tổng quát này, một hoạt động mà yêu cầu 8 [người – tháng] của
nỗ lực và có 4 người được chỉ định tham gia có thể được hoàn thành trong thời gian
2 tháng.
8 [người – tháng] / 4 [người] = 2 [tháng]
Thực tế thì việc ước lượng lịch trình sẽ khó hơn rất nhiều. Nó liên quan đến
nhiều yếu tố như:
 Các phụ thuộc của một hoạt động với các hoạt động trước
 Các hoạt động đan xen hay đồng thời
 Đường găng xuyên suốt chuỗi công việc
 Số ca làm việc mỗi ngày, số giờ làm việc hiệu quả trong mỗi ca
 Những gián đoạn như là du lịch, hội nghị, đào tạo hay nghỉ ốm, …
 Số lượng vùng thời gian cho các dự án đối với các công ty đa quốc gia
Như vậy công việc quản trị dự án, công việc ước lượng lịch trình có nhiều mối
liên hệ và được thực hiện theo sự tinh tế của từng người quản lý.
1.1.2.4. Ước lượng chi phí
Có nhiều yếu tố cần quan tâm khi ước lượng chi phí tổng cộng của một dự án.
Những yếu tố đó bao gồm giá nhân công, giá mua hay giá thuê phần cứng, phần


12

mềm, chi phí đi lại cho mục đích gặp gỡ hay kiểm thử, các giao tiếp (ví dụ, các cuộc
gọi điện thoại đường dài, hội thảo video từ xa, …), các khóa đào tạo, không gian
văn phòng, …
Giá nhân công thì có thể được xác định một cách đơn giản nhất bằng phép nhân

giữa nỗ lực ước lượng của dự án (tính theo giờ) với lương nhân công tính trung bình
tổng quát. Một chi phí nhân công chuẩn xác hơn lấy kết quả từ việc sử dụng lương
nhân công rõ ràng cho mỗi vị trí (ví dụ: vị trí kỹ thuật, quản lý chất lượng, quản lý
dự án, người lập tài liệu, cộng tác viên, …). Chúng ta sẽ phải xác định xem bao
nhiêu phần trăm của nỗ lực dự án tổng cộng cần được cấp phát cho mỗi vị trí. Khi
đó dữ liệu lịch sử hoặc các mô hình dữ liệu công nghiệp lại có thể trợ giúp.
Qua việc nghiên cứu 4 bước trong phép ước lượng như trên, đề xuất một tiến
trình cơ sở cho việc ước lượng như được mô tả trong sơ đồ ở Hình 1.2:

Hình 1.2. Tiến trình cơ sở ước lượng dự án.


13

1.1.3. Các phương pháp ước lượng nỗ lực
1.1.3.1. Ước lượng chuyên gia
Các chuyên gia đã có kinh nghiệm triển khai dự án phần mềm, có thể trả lời
ngay các ước lượng. Tuy nhiên không phải lúc nào độ chính xác cũng đáng tin cậy.
Ưu điểm của phương pháp là nhanh và nếu người được hỏi thực sự là một
chuyên gia thì kết quả ước lượng có thể rất chính xác. Nhược điểm chính là ở chỗ
chúng ta cần tìm một chuyên gia có kinh nghiệm trong lĩnh vực tương ứng mà những
chuyên gia đạt được yêu cầu thì lại thường khó tìm. Hơn nữa, độ chính xác phụ thuộc
vào thời gian chuyên gia bỏ ra để đánh giá. Ước lượng sẽ không thể tin cậy được nếu
chuyên gia đó lại giao cho một người khác thực hiện. Ngoài ra, việc chỉ dựa vào ý kiến
và hiểu biết chủ quan của số ít chuyên gia cũng là một điều nguy hiểm.
1.1.3.2. Ước lượng đánh giá bằng kinh nghiệm quá khứ
Phải có số liệu quá khứ, phải hiểu được tình hình hiện tại.
Để khỏi phụ thuộc vào một vài người và làm cho ước lượng của chúng ta có cơ
sở khoa học hơn thì việc lưu giữ quy trình lịch sử là rất cần thiết. Chúng ta hãy viết ra
mỗi công việc cần bao lâu để hoàn thành và ai là người chịu trách nhiệm. Sau đó,

chúng ta có thể so sánh công việc cần đánh giá với những công việc tương tự đã được
thực hiện trong quá khứ và đi tới một ước lượng. Như vậy, cần chia dự án thành những
công việc thường hay lặp lại và dễ so sánh. Trên thực tế, các công ty thường có
khuynh hướng xây dựng các kiểu dự án tương tự nhau. Họ hãy tìm những khối xây
dựng cơ sở, những tài liệu hiện thời và xây dựng các khối này theo kiểu để sau này còn
sử dụng lại được.
1.1.3.3. Ước lượng đánh giá bằng các mô hình ước lượng thực nghiệm
Ước lượng đánh giá bằng mô hình ước lượng thực nghiệm cần phải có tham số
về dự án (các độ đo).
Có nhiều mô hình đã được công bố về ước lượng phần mềm. Mô hình nổi tiếng
như COCOMO, AGILE. Các mô hình này có thể được dùng để ước lượng giá thành
dự án, ngày công (người tháng), lịch biểu (tháng) và biên chế (số nhân viên) cho
dự án.
Các kiểu đầu vào cho COCOMO hay AGILE: Trước hết có thể là chi phí hàng
tháng cho đội ngũ nhân viên. Các kiểu nhân viên có thể là người lập trình, nhà phân
tích, người kiểm thử, nhân viên hành chính, người viết tài liệu kĩ thuật. Các nhân tố chỉ
ra độ phức tạp chung của phần mềm, kích cỡ và máy tính có sẵn được dùng cho việc
phát triển, khả năng và kinh nghiệm của đội ngũ nhân viên và công cụ lập trình được
sử dụng.


14

1.2. MÔ HÌNH PHÁT TRIỂN PHẦN MỀM AGILE
1.2.1. Sự cần thiết của một mô hình phát triển phần mềm mới
Ngày nay, sự phát triển về công nghệ và yêu cầu của người dùng đòi hỏi cao về
công nghệ nên việc phát triển phần mềm để có thể đáp ứng được ngày càng khó
khăn và phức tạp hơn. Chính vì vậy, những nhà quản lí phần mềm đã không ngừng
học hỏi và tìm kiếm để tạo ra phương thức phát triển phần mềm tốt hơn. So với
trước đây, con người đã không ngừng tạo ra những chiếc máy tính rẻ hơn nhanh

hơn, nhiều ngôn ngữ lập trình mạnh mẽ ra đời và với số lượng ngày càng nhiều hơn
thì cần thiết phải có những công cụ hỗ trợ và có những hiểu biết sâu sắc hơn về lý
thuyết phần mềm. Máy tính đã làm thay đổi cả thế giới, thúc đẩy sự trao đổi thông
tin và thay đổi một cách triệt để kỳ vọng của con người về cách thức mà phần mềm
làm việc.
Chúng ta có rất nhiều phương pháp giúp xác định con đường phát triển phần
mềm, ví dụ như một số mô hình:
 Mô hình thác nước
 Mô hình xoắn ốc
 Mô hình hướng đối tượng
Các phương pháp truyền thống kể trên cố gắng trang bị một khả năng dự đoán
trước cho quy trình phát triển phần mềm. Vì vậy, chúng có thể tạo ra một bản kế
hoạch từ thời điểm đầu của dự án và xác định được thời gian hoàn thành của dự án.
Nhưng vấn đề quan trọng nhất vẫn là “sự thay đổi yêu cầu người dùng/khách hàng”.
Bởi vì một phần mềm tốt là phần mềm phải đem lại cho khách hàng sự hài lòng tốt
nhất. Tuy vậy những phương pháp truyền thống có những hạn chế trong quá trình
phát triển phần mềm đó là sự thay đổi về yêu cầu từ phía khách hàng. Điều này chỉ
duy trì kế hoạch của dự án ban đầu nhưng không đem lại sự thỏa mãn hoàn toàn cho
khách hàng khi phát triển phần mềm bời vì với các phương pháp truyền thống còn
thiếu sự cộng tác giữa khách hàng và nhà phát triển trong quá trình triển khai phần mềm.
Chính sự hạn chế từ những phương pháp truyền thống mà cần có một phương
pháp hay quy trình phát triển phần mềm mới ra đời và quy trình phát triển phần
mềm linh hoạt (Agile) đã phần nào đáp ứng được yêu cầu.
1.2.2. Tìm hiểu chung về Agile
Phát triển phần mềm theo quy trình Agile là một nhóm các phương pháp phát
triển phần mềm dựa trên sự phát triển lặp đi lặp lại và sự gia tăng, nơi các yêu cầu
và giải pháp phát triển thông qua sự hợp tác giữa các nhóm tự tổ chức. Nó thúc đẩy
việc lập kế hoạch thích ứng, phát triển tiến hóa, phân phối, cách tiếp cận lặp đi lặp
lại theo thời gian và khuyến khích phản ứng nhanh, linh hoạt để thay đổi. Đây là
một khung khái niệm thúc đẩy các tương tác dự kiến trong suốt chu trình phát triển

15

phần mềm. Các phương pháp linh hoạt bao gồm: Scrum (1995), Crystal Clear, lập
trình cực đoan (1996), phát triển phần mềm thích ứng, phát triển tính năng và
phương pháp phát triển hệ thống động (DSDM) (1995). Đây thường được gọi là các
phương pháp linh hoạt (Agile), sau khi Tuyên ngôn Agile ra đời vào năm 2001.
Phương pháp Agile tồn tại trên sự liên tục từ thích ứng để dự đoán. Các phương
pháp thích nghi tập trung vào việc thích nghi nhanh chóng với những thay đổi thực
tế. Khi nhu cầu của một dự án thay đổi, một nhóm thích nghi cũng thay đổi theo.
Ngược lại, các phương pháp dự đoán tập trung vào việc lập kế hoạch chi tiết trong
tương lai. Một nhóm dự đoán có thể báo cáo chính xác những tính năng, nhiệm vụ
nào được lên kế hoạch cho toàn bộ quá trình phát triển. Các nhóm dự đoán khó có
thể thay đổi hướng khi yêu cầu của khách hàng thay đổi.
Phương thức phát triển phần mềm linh hoạt với mục tiêu là phần mềm phải có
khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không cần phải làm lại từ
đầu. Phương thức này tập trung vào tính đơn giản: tạo ra một phần mềm thật đơn
giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay
đổi vào ngày mai.
Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mềm
trong những khung thời gian ngắn và sự cộng tác chặt chẽ với khách hàng. Mỗi
bước lặp (Iteration) giống như phát triển một phần mềm hoàn chỉnh cũng bao gồm
lấy yêu cầu, làm phân tích thiết kế, viết mã nguồn, kiểm thử và viết tài liệu. Điểm
nổi bật là khả năng sửa chữa biến đổi phần mềm ngay cả khi dự án đã bắt đầu.
Điểm quan trọng làm nên sự khác biệt của Agile so với các mô hình truyền
thống đó là: Các mô hình truyền thống là mô hình theo kế hoạch, còn mô hình Agile
thì không nhất thiết phải tuân theo kế hoạch, nó có thể có những bước đột phá để
tạo ra một phần mềm hiệu quả nhất.
1.2.2.1. Tuyên ngôn của Agile

Vào tháng 2 năm 2001, 17 nhà phát triển phần mềm đã gặp gỡ nhau ở
Snowbird, Utah Resort để thảo luận về các phương pháp phát triển phần mềm gọn
nhẹ và linh hoạt. Họ đã cùng nhau công bố “Tuyên ngôn Phát triển phần mềm linh
hoạt” (“Manifesto for Agile Software Development” – gọi tắt là “Tuyên ngôn
Agile”) để định nghĩa cách hiểu về phát triển phần mềm linh hoạt.
Các phương pháp Agile như XP, Scrum,... đã được sử dụng thành công ở rất
nhiều nơi nhưng phải tới khi có sự xuất hiện của “Tuyên ngôn Agile” cùng với sự ra
đời của các hiệp hội chuyên ngành Agile như Agile Alliance hay Scrum Alliance thì
các phương pháp Agile mới có một sự phát triển vượt bậc. Văn bản này rất ngắn, dễ
hiểu và rất quan trọng vì nó đưa ra các giá trị cốt lõi nhất mà toàn bộ các nhà lý
thuyết cũng như những người thực hành Agile tuân thủ; mặc dù các phương pháp họ
đề xuất hoặc sử dụng trong thực tiễn có thể rất khác nhau. Tuyên ngôn Agile như sau: