Tối ưu hóa lập lịch dự án sử dụng phương pháp cpm và kỹ thuật mạng bayes áp dụng cho các dự án phát triển phần mềm linh hoạt
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.2 MB, 69 trang )
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRẦN ĐÌNH QUANG
TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------
Trần Đình Quang
KỸ THUẬT PHẦN MỀM
TỐI ƢU HÓA LẬP LỊCH DỰ ÁN SỬ DỤNG PHƢƠNG PHÁP
CPM VÀ KỸ THUẬT MẠNG BAYES ÁP DỤNG CHO CÁC DỰ
ÁN PHÁT TRIỂN PHẦN MỀM LINH HOẠT
LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM
…......................................
KHÓA 14B
Hà Nội – 2016
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------
Trần Đình Quang
TỐI ƢU HĨA LẬP LỊCH DỰ ÁN SỬ DỤNG PHƢƠNG PHÁP CPM VÀ
KỸ THUẬT MẠNG BAYES ÁP DỤNG CHO CÁC DỰ ÁN PHÁT
TRIỂN PHẦN MỀM LINH HOẠT
Chuyên ngành : Kỹ thuật phần mềm
LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM
…......................................
NGƢỜI HƢỚNG DẪN KHOA HỌC :
PGS. TS. ĐỖ TRUNG TUẤN
Hà Nội – 2016
MỤC LỤC
Trang
LỜI CAM ĐOAN .......................................................................................................
3
DANH MỤC CÁC BẢNG ..........................................................................................
4
DANH MỤC CÁC TỪ VIẾT TẮT ............................................................................
5
DANH MỤC CÁC HÌNH VẼ.....................................................................................
6
PHẦN MỞ ĐẦU .........................................................................................................
7
1. Lý do chọn đề tài .................................................................................................
7
2. Mục tiêu và nhiệm vụ nghiên cứu .......................................................................
8
3. Bố cục luận văn....................................................................................................
8
CHƢƠNG I. TỔNG QUAN .......................................................................................
9
1.1 Tổng quan về phát triển phần mềm linh hoạt. ...................................................
9
1.1.1 Tun ngơn Agile ........................................................................................
1.1.3 Tính lặp (Iterative) .....................................................................................
1.1.4 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary) ..........................
1.1.5 Tính thích ứng (hay thích nghi – adaptive) ...............................................
1.1.6 Nhóm tự tổ chức và liên chức năng...........................................................
1.1.7 Quản lý tiến trình thực nghiệm (Empirical Process Control) ....................
1.1.8 Giao tiếp trực diện (face-to-face communication) ....................................
1.1.9 Phát triển dựa trên giá trị (value based development) ...............................
1.2 Các vấn đề rủi ro trong phát triển phần mềm linh hoạt ...................................
9
12
13
13
13
14
14
15
15
Kết chương: ........................................................................................................
17
CHƢƠNG II. VẤN ĐỀ LẬP LỊCH BƢỚC LẶP VÀ KỸ THUẬT MẠNG BAYES
...................................................................................................................................
2.1 Vấn đề lập lịch bƣớc lặp trong phát triển phần mềm linh hoạt .......................
18
18
2.1.1 Khái niệm về lập kế hoạch ........................................................................
2.1.2 Vai trò của lập kế hoạch trong quản lý dự án ............................................
2.2 Một số hƣớng tiếp cận giải quyết vấn đề lập lịch bƣớc lặp .............................
19
19
23
2.2.1 Phƣơng pháp sơ đồ Gantt ..........................................................................
2.2.2 Phƣơng pháp sơ đồ PERT .........................................................................
2.2.3 Phƣơng pháp đƣờng Găng (Critical Path Method – CPM) .......................
2.3 Kỹ thuật mạng Bayes .......................................................................................
24
24
25
27
1
2.3.1 Định nghĩa mạng Bayes (BNs)................................................................. 28
2.3.2 Cách xây dựng mạng Bayes...................................................................... 31
2.4 Mơ hình Bayesian Critical Path Method (BCPM).......................................... 33
2.5 Kết hợp giữa CPM và BNs.............................................................................. 35
2.6 Sử dụng BCPM để ƣớc lƣợng thời gian......................................................... 39
Kết chương:........................................................................................................ 48
CHƢƠNG III. LẬP LỊCH DỰ ÁN SỬ DỤNG CPM VÀ KỸ THUẬT MẠNG
BAYES TRONG PHÁT TRIỂN PHẦN MỀM LINH HOẠT................................. 49
3.1 Mô hình hóa bài tốn lập lịch bƣớc lặp.......................................................... 49
3.2 Lập lịch bƣớc lặp dự án sử dụng CPM và kỹ thuật mạng Bayes....................51
3.3 Giải quyết vấn đề lập lịch bƣớc lặp trong phát triển phần mềm linh hoạt......52
3.3.1 Thuật toán giải quyết AISP khơng sử dụng Bayes[7]...............................52
3.3.2 Thuật tốn giải quyết AISP sử dụng mạng Bayes.................................... 54
3.4 Đánh giá thuật tốn sử dụng Bayes với thuật tốn khơng sử dụng Bayes......57
CHƢƠNG IV. THỬ NGHIỆM VÀ ĐÁNH GIÁ.................................................... 58
4.1 Dữ liệu thử nghiệm và sinh dữ liệu................................................................. 58
4.2 Cài đặt giải thuật............................................................................................. 61
4.3 Kết quả thử nghiệm và phân tích..................................................................... 61
KẾT LUẬN VÀ KIẾN NGHỊ.................................................................................. 65
A. Kết luận............................................................................................................ 65
B. Kiến nghị.......................................................................................................... 66
C. Hƣớng phát triển của đề tài.............................................................................. 66
DANH MỤC TÀI LIỆU THAM KHẢO................................................................. 67
2
LỜI CAM ĐOAN
Tôi xin cam đoan: Luận văn "Tối ưu hóa lập lịch dự án sử dụng phương pháp CPM
và kỹ thuật mạng Bayes áp dụng cho các dự án phát triển phần mềm linh hoạt" là
do bản thân tôi tự thực hiện dƣới sự hƣớng dẫn của PGS.TS. Đỗ Trung Tuấn –
Trƣờng ĐH KHTN- ĐHQG Hà Nội, các thông tin số liệu và kết quả trong Luận văn
có nguồn gốc rõ ràng, nội dung của Luận văn chƣa từng đƣợc cơng bố trong bất kỳ
một cơng trình nghiên cứu nào ở trong nƣớc.
Hà Nội, tháng 3 năm 2016
Tác giả Luận văn
Trần Đình Quang
3
DANH MỤC CÁC BẢNG
Bảng 1. Các kế hoạch của dự án............................................................................... 22
Bảng 2. Thời gian và hoạt động của dự án............................................................... 34
Bảng 3. Tóm tắt các thuộc tính cho mơ hình BCPM................................................ 36
Bảng 4. Lịch trình hoạt động của dự án X................................................................ 38
Bảng 5. Các thuộc tính của mơ hình đánh đổi.......................................................... 41
Bảng 6. NPT của “Thời gian”................................................................................... 42
Bảng 7. Thuộc tính của mơ hình dự kiến rủi ro........................................................ 47
Bảng 8. Xảy ra rủi ro phụ thuộc vào “Điều khiển”.................................................. 47
Bảng 9. Bảng dữ liệu cho ví dụ lập lịch đơn giản.................................................... 58
Bảng 10. So sánh kết quả giữa hai hƣớng lập lịch................................................... 63
4
DANH MỤC CÁC TỪ VIẾT TẮT
STT Từ viết tắt
Tên đầy đủ
Giải thích
1
CPM
Critical Path Method
Phƣơng pháp
đƣờng Găng
2
BNs
Bayesian Network
Mạng Bayes
Bayesian Critical
Sự kết hợp
Bayes và CPM
Path Method
để ƣớc lƣợng
3
BCPM
thời gian
Thời gian thực
hiện
4
D
Duration
5
S
Slack
6
ES
Earliest Start
Thời gian bắt
đầu sớm nhất
7
EF
Earliest Final
Thời gian kết
thúc muộn nhất
8
LS
Latest Start
Thời gian bắt
đầu muộn nhất
9
LF
Latest Final
Thời gian kết
thúc muộn nhất
10
AISP
Agile Iteraction
Vấn đề lập lịch
bƣớc lặp trong
Scheduling Problem
phát triển phần
mềm linh hoạt
5
DANH MỤC CÁC HÌNH VẼ
Hình 1. Mức độ phổ biến các phƣơng pháp............................................................. 10
Hình 2. Các phân đoạn lặp đi lặp lại trong Agile..................................................... 12
Hình 3. Sơ đồ mạng cơng việc.................................................................................. 26
Hình 4. Mơ hình minh họa mạng Bayes................................................................... 28
Hình 5. Ví dụ về Bayes Networks............................................................................ 30
Hình 6. Kết quả xây dựng mạng Bayes cho ví dụ thơng báo chng.......................32
Hình 7. Kết quả xây dựng mạng Bayes khi sử dụng thứ tự các nút khác.................33
Hình 8. Sơ đồ AON và sơ đồ AOA.......................................................................... 34
Hình 9. Sơ đồ của đoạn BNs gắn với một hoạt động............................................... 35
Hình 10. Sơ đồ mạng dự án...................................................................................... 37
Hình 11. Sơ đồ BCPM.............................................................................................. 39
Hình 12. Thời gian hoạt động ngun mẫu của BNs................................................ 40
Hình 13. Mơ hình đánh đổi....................................................................................... 41
Hình 14. Sự biến đổi theo thời gian.......................................................................... 43
Hình 15. “Thời gian” thay đổi khi “Tài nguyên” thay đổi....................................... 44
Hình 16. Phân bố các “Tài nguyên”......................................................................... 45
Hình 17. Rủi ro kiểm sốt và khơng kiểm sốt......................................................... 46
Hình 18. Mơ hình dự kiến rủi ro............................................................................... 46
Hình 19. Mơ hình nhân tố khơng biết trƣớc............................................................. 48
Hình 20. Mạng node các nhiệm vụ........................................................................... 59
Hình 21. Lập lịch cho
( khơng áp dụng BNs)..................................................... 59
Hình 22. Lập lịch cho
( áp dụng BNs)................................................................ 59
Hình 23. Lập lịch cho
( khơng áp dụng BNs)..................................................... 60
Hình 24. Lập lịch cho
( áp dụng BNs)................................................................ 60
Hình 25. Kết quả lập lịch khơng sử dụng BNs......................................................... 62
Hình 26. Kết quả lập lịch sử dụng BNs.................................................................... 62
Hình 27. So sánh kết quả sử dụng BNs và không sử dụng BNs...............................64
6
PHẦN MỞ ĐẦU
1. Lý do chọn đề tài
Hiện nay công nghệ thông tin ngày càng đƣợc ứng dụng rộng rãi trong hầu
hết các lĩnh vực của xã hội, điều này dẫn đến các dự án công nghệ thông tin
ngày càng đa dạng, phức tạp hơn. Khi các dự án công nghệ thông tin càng
phức tạp về qui mô, thời gian thực hiện ngắn hơn thì triển khai phát triển dự
án theo phƣơng pháp nào luôn là một vấn đề cần đƣợc quan tâm cũng nhƣ
việc lên kế hoạch thực hiện dự án càng cần đƣợc xem xét một phƣơng pháp
phù hợp và mang tính khả thi cao cho dự án.
Đầu tiên là vấn đề phƣơng pháp để phát triển dự án phần mềm trong những
điều kiện phức tạp nhƣ thiếu thơng tin về tính khả thi của dự án, những yêu
cầu của khác hàng chƣa thực sự thống nhất có thể đơn giản vì sản phẩm là
lần đầu, chƣa có kinh nghiệm,.. bên nhà đầu tƣ dự án cần một lịch trình báo
cáo tiến độ dự án kèm theo đó là các sản phẩm cụ thể theo kế hoạch tiến độ.
Các mơ hình phát triển phần mềm nhƣ mơ hình thác nƣớc, mơ hình xoắn ốc
hay là bản mẫu nhanh… chắc chắn sẽ không phù hợp với nhƣng dự án mà
tính khả thi của dự án chƣa rõ ràng.
Một vấn đề nổi lên là lập kế hoạch và phân bổ nguồn lực trong dự án. Với
những dự án ít đầu việc và ít ngƣời tham gia thì vấn đề lập kế hoạch và lập
lịch dự án một cách thủ công sẽ khơng đáng ngại. Nhƣng với những dự án
lớn, có nhiều đầu việc phức tạp, số lƣợng nhân công lớn (nguồn lực, tài
nguyên) tham gia vào dự án và có nhiều biến động, nhiều rủi ro tiềm ẩn, khi
đó vấn đề lập kế hoạch, lập lịch dự án sẽ gặp khó khăn. Ngƣời làm kế hoạch
sẽ phải tốn nhiều thời gian để tiến hành sửa đổi kế hoạch, lập lịch lại mỗi khi
có sự biến động về nhân sự (hay rộng hơn là thay đổi về nguồn lực thực
hiện). Nhƣ vậy, vấn đề cấp thiết phải làm sao tự động đƣợc việc lên kế
hoạch, lập lịch cho dự án và đánh giá đƣợc tính khả thi của lịch trình, kế
hoạch theo những con số cụ thể.
7
2. Mục tiêu và nhiệm vụ nghiên cứu
Trong trí tuệ nhân tạo “Bayesian Networks” đã đƣợc ứng dụng rộng rãi để
giải quyết nhiều bài tốn phức tạp. Trong đó có các bài toán về lập lịch, lên
kế hoạch thực hiện dự án. Việc áp dụng kỹ thuật mạng Bayes trong lập lịch
cho dự án và phân bổ nguồn lực đã và đang đƣợc nghiên cứu cải tiến rất
nhiều hiện nay.
Luận văn tập trung nghiên cứu các nội dung chính sau đây:
Nghiên cứu tổng quát về phát triển phần mềm linh hoạt
Nghiên cứu về kỹ thuật mạng Bayes và sử dụng mạng Bayes vào
tối ƣu hóa lập lịch cho bƣớc lặp trong phát triển phần mềm linh
hoạt.
Triển khai giải thuật lập lịch theo hƣớng tiếp cận không sử dụng kỹ
thuật mạng Bayes và sử dụng kỹ thuật mạng Bayes.
Phân tích đánh giá các kết quả của các hƣớng tiếp cận
3. Bố cục luận văn
Luận văn đƣợc thực hiện thành 4 chƣơng nhƣ sau:
Chƣơng 1: Giới thiệu tổng quan về phát triển phần mềm linh hoạt (vấn đề
phát triển, vấn đề rủi ro và các vấn đề lập lịch).
Chƣơng 2: Giới thiệu về bài toán lập lịch bƣớc lặp (định nghĩa, một số
hƣớng tiếp cận giải quyết), CPM và kỹ thuật mạng Bayes.
Chƣơng 3: Trình bày thuật tốn giải quyết bài tốn lập lịch bƣớc lặp sử dụng
CPM và kỹ thuật mạng Bayes trong phát triển dự án phần mềm linh hoạt.
Chƣơng 4: Trình bày về dữ liệu thử nghiệm cho bài tốn và đánh giá kết quả
giữa lập lịch khơng sử dụng mạng Bayes và lập lịch sử dụng mạng Bayes.
8
CHƢƠNG I. TỔNG QUAN
1.1 Tổng quan về phát triển phần mềm linh hoạt.
Phát triển phần mềm linh hoạt (agile software development – gọi tắt là agile) là
một triết lí cùng với 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. Agile thƣờng sử dụng cách lập kế hoạch thích
ứng (adaptive planning), việc phát triển và chuyển giao theo hƣớng tiến hóa, sử
dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay
đổi trong quá trình phát triển. Ngày nay, triết lí Agile đã vƣợt xa khỏi khu vực
truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách
thức làm việc, quản lí, sản xuất ở các ngành khác nhƣ sản xuất, dịch vụ, bán hàng,
quảng cáo, giáo dục[4]
1.1.1 Tuyên ngôn Agile
Vào tháng Hai năm 2001, mƣời bảy 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. Đây là cột mốc
quan trọng của agile. Dù trƣớc đó, 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
“Tun 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, 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. Tồn văn tuyên ngôn agile nhƣ sau.[4]
9
Tuyên ngôn phát triển phần mềm linh hoạt
Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực
hiện nó và giúp đỡ người khác thực hiên. Qua công việc này, chúng tôi đã đi
đến việc đánh giá cao:
Cá nhân và sự tƣơng tác hơn là quy trình và cơng
cụ Phần mềm chạy tốt hơn là tài liệu đầy đủ
Cộng tác với khách hàng hơn là đàm phán hợp đồng
Phản hồi v ới các thay đổi hơn là bám sát kế hoạch
“Mặc dù các điều bên phải vẫn cịn giá trị nhưng chúng tơi đánh giá cao
hơn các mục ở bên trái”
1.1.2 Đặc trƣng
Thuật ngữ "Agile" chính thức đƣợc sử dụng rộng rãi một cách thống nhất kể từ khi
“Tuyên ngôn Agile” đƣợc giới thiệu ra cơng chúng năm 2001. Nhờ tính linh hoạt,
đa dạng và hiệu quả cao, các phƣơng pháp agile ngày càng trở thành sự lựa chọn
hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm. Theo
khảo sát của hãng nghiên cứu thị trƣờng Forrester, mức độ phổ biến của agile hiện
đang ở mức cao nhất, và gấp nhiều lần so với các phƣơng pháp truyền thống nhƣ
thác nƣớc hay CMMI (xem hình 1).
Hình 1. Mức độ phổ biến các phương pháp
10
Bên cạnh đó, các nhà phát triển cịn nhấn mạnh mƣời hai ngun lý phía sau
“Tun ngơn Agile” để giúp các nhà phát triển có đƣợc gợi ý trong thực hành và
vận dụng các phƣơng pháp agile trong thực tiễn. Các nguyên lý đƣợc liệt kê sau
đây:
Ƣu tiên cao nhất của chúng tôi 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ị.
Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong q 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 sản phẩm tới khách hàng, từ vài tuần đến
vài tháng.
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.
Tạo điều kiệ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, tin tƣởng họ để hồ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 là nghệ thuật tối đa hóa lƣợng cơng việc.
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.
11
Các nguyên lý này, cùng với năm điểm cốt lõi trong "Tuyên ngôn Agile" sẽ dẫn
đƣờng cho các nhà thực hành agile (agile practictioner) vận dụng tốt các phƣơng
pháp agile vào thực tiễn. Các nguyên lí này đƣợc Jeff Sutherland diễn giải chi tiết.
Có rất nhiều phƣơng pháp agile với các hƣớng tiếp cận rất khác nhau. Bên cạnh các
cách thức tổ chức cơng việc, thiết lập quy trình, các phƣơng pháp agile còn nghiên
cứu và đƣa vào sử dụng các công cụ và kĩ thuật đặc thù nhƣ công cụ tích hợp liên
tục (continuous integration), kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển
hƣớng kiểm thử, phát triển hƣớng hành vi, hay lập trình theo cặp để đảm bảo và gia
tăng tính linh hoạt. Tuy vậy các phƣơng pháp này chia sẻ nhiều đặc trƣng giống
nhau cộng tác nhóm chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp
ứng cao trong suốt vịng đời của dự án.
1.1.3 Tính lặp (Iterative)
Dự án sẽ đƣợc thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (đƣợc
gọi là “Iteration” hoặc “Sprint”) này thƣờng có khung thời gian ngắn (từ 1 đến 4
tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc
cần thiết nhƣ lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các
mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm. Các phƣơng pháp agile
thƣờng phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và
gọn nhẹ nhất có thể và khơng thực hiện việc lập kế hoạch dài hạn. Các phƣơng
pháp nhƣ Scrum thậm chí sử dụng phƣơng pháp lập kế hoạch “just in time” trong
q trình phát triển. Khi đó, thậm chí cơng việc lập kế hoạch, làm mịn kế hoạch
đƣợc thực hiện liên tục trong suốt quá trình làm việc.
Hình 2. Các phân đoạn lặp đi lặp lại trong Agile
12
1.1.4 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)
Cuối các phân đoạn, nhóm phát triển thƣờng cho ra các phần nhỏ của sản phẩm
cuối cùng. Các phần nhỏ này thƣờng là đầy đủ, có khả năng chạy tốt, đƣợc kiểm
thử cẩn thận và có thể sử dụng ngay. Theo thời gian, phân đoạn này tiếp nối phân
đoạn kia, các phần chạy đƣợc này sẽ đƣợc tích lũy, lớn dần lên cho tới khi toàn bộ
yêu cầu của khách hàng đƣợc thỏa mãn. Khác với mơ hình phát triển thác nƣớc,
vốn chỉ cho phép nhìn thấy tồn bộ các chức năng tại thời điểm kết thúc dự án, sản
phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt đƣợc
trạng thái đủ để phát hành.
1.1.5 Tính thích ứng (hay thích nghi – adaptive)
Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn và việc lập kế hoạch
cũng đƣợc điều chỉnh liên tục nên các thay đổi trong quá trình phát triển (yêu cầu
thay đổi, thay đổi công nghệ, thay đổi định hƣớng về mục tiêu v.v.) đều có thể
đƣợc đáp ứng theo cách thích hợp. Ví dụ, Scrum là phƣơng pháp phổ biến nhất
hiện nay thì trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có
thể đƣa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các
yêu cầu này và có thể đƣa vào làm việc trong phân đoạn (đƣợc gọi là Sprint trong
Scrum) tiếp theo. Theo đó, các quy trình agile thƣờng phải thích ứng rất tốt với các
thay đổi.
1.1.6 Nhóm tự tổ chức và liên chức năng
Cấu trúc nhóm agile thƣờng là liên chức năng (cross functionality) và tự tổ chức (self
organizing). Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà
không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân
cấp rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo dõi
tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ không
làm việc theo cơ chế “mệnh lệnh và kiểm sốt” (command and control). Nhóm tự tổ
chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển phần
mềm, do vậy nó có thể đƣợc trao quyền để tự ra quyết định, tự quản lí và tổ chức lấy
cơng việc của chính mình để đạt đƣợc hiệu quả cao nhất.
13
1.1.7 Quản lý tiến trình thực nghiệm (Empirical Process Control)
Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính tốn lý
thuyết hay các tiền giả định (prescription). Việc phân nhỏ dự án thành các phân
đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho
phép điều chỉnh các chiến lƣợc phát triển của mình. Nói cách khác, agile rút ngắn
vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính
linh hoạt. Theo thời gian, các chiến lƣợc này sẽ tiến gần đến trạng thái tối ƣu, nhờ
đó nhóm có thể kiểm sốt đƣợc tiến trình, và nâng cao năng suất lao động.
1.1.8 Giao tiếp trực diện (face-to-face communication)
Một số mô hình phát triển phần mềm dựa rất nhiều vào cơng việc giấy tờ, từ việc
thu thập yêu cầu ngƣời dùng, viết đặc tả hệ thống, các thiết kế hệ thống. Agile
không phản đối công dụng của công việc tài liệu hóa, nhƣng đánh giá cao hơn việc
giao tiếp trực diện thay vì gián tiếp thơng qua giấy tờ. Về u cầu của khách hàng,
agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ
hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản.
Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên
(thực hiện việc mã hóa) và một kĩ sƣ (thực hiện việc thiết kế) giao tiếp với nhau
thông qua bản thiết kế, agile khuyến khích hai ngƣời này trực tiếp trao đổi và thống
nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng
theo yêu cầu.
Bản thân các nhóm agile thƣờng nhỏ (ít hơn mƣời hai ngƣời, một nhóm lớn
thƣờng đƣợc phân nhỏ với cơ chế hợp tác đặc thù để luôn ln có thơng lƣợng giao
tiếp tối đa) để đơn giản hóa q trình giao tiếp, thúc đẩy việc cộng tác hiệu quả. Các
dự án lớn muốn dùng agile thƣờng phải phân thành nhóm nhỏ đồng thời làm việc
với nhau hƣớng đến một mục tiêu chung. Việc này có thể địi hỏi một số nỗ lực
đáng kể trong việc điều phối các mức ƣu tiên giữa các nhóm.
Các nhóm phát triển thƣờng tạo ra các thói quen và cơ chế trao đổi trực diện một
cách thƣờng xuyên. Một trong các cơ chế thƣờng thấy là các cuộc họp tập trung
hằng ngày (daily meeting, daily scrum, standup meeting). Tại đây, tất cả các thành
14
viên đƣợc u cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp
làm gì và đang gặp phải khó khăn nào trong q trình làm việc. Khi cơ chế này
đƣợc thực hiện hiệu quả, nhóm ln ln nắm đƣợc tình hình cơng việc của mình,
có các hành động thích hợp để vƣợt qua các trở ngại để thực hiện thành công mục
tiêu của dự án.
1.1.9 Phát triển dựa trên giá trị (value based development)
Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thƣớc
đo của tiến độ”. Nguyên tắc này giúp nhóm loại bỏ đi các cơng việc dƣ thừa không
trực tiếp mang lại giá trị cho sản phẩm. Ví dụ, một nhóm thấy rằng có thể khơng cần
phải viết ra tất cả các thiết kế của hệ thống, mà họ chỉ cần phác thảo các thiết kế này
lên bảng, rồi cùng nhau triển khai các chức năng của hệ thống. Nhƣng nếu nhƣ chủ
sản phẩm quyết định rằng, khi chuyển giao sản phẩm, nhóm phát triển phải kèm
theo thiết kế chi tiết của hệ thống vì chúng chiếm 20% giá trị của dự án theo yêu cầu
của khách hàng và vì khách hàng cần nó để chứng minh tính đúng đắn của các chức
năng cũng nhƣ để phát triển tiếp các phân hệ tiếp theo của sản phẩm thì nhóm phát
triển sẽ phải thực hiện việc tài liệu hóa đầy đủ.
Để vận hành đƣợc cơ chế “làm việc dựa trên giá trị” các nhóm agile thƣờng làm
việc trực tiếp và thƣờng xuyên với khách hàng (hay đại diện của khách hàng), cộng
tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn
sớm nhất có thể cho dự án. Nhờ đó các dự án agile thƣờng giúp khách hàng tối ƣu
hóa đƣợc giá trị của dự án. Một cách gần nhƣ trực tiếp, agile gia tăng đáng kể độ
hài lòng của khách hàng.[4]
1.2 Các vấn đề rủi ro trong phát triển phần mềm linh hoạt
Phát triển phần mềm linh hoạt là việc tăng sản phẩm đầu ra cả chất lƣợng và số lƣợng
thông qua các bƣớc lặp tăng trƣởng và chỉ thực hiện đƣợc với các dự án tầm trung và
đội phát triển dự án có thể bao quát đƣợc hết phạm vi của dự án phần mềm. Việc
không bao quát hết phạm vi dự án trong các mơ hình phát triển phần mềm khơng riêng
gì mơ hình phát triển phần mềm linh hoạt đều là các rủi ro tiềm ẩn cho dự án. Các rủi
ro không đƣợc phát hiện để đƣa vào tính tốn tính khả thi ban đầu
15
cho dự án ln là những điểm chính gây ra sự thất bại của các dự án. Với các mô hình
phát triển phần mềm nhƣ mơ hình thác nƣớc các rủi ro nếu không đƣợc phát hiện từ
ban đầu sẽ gây thiệt hại lớn nếu dự án thất bại nghĩa là lúc mà rủi ro khơng thể xử lý thì
ngân sách của dự án đã sử dụng quá nhiều. Trong phát triển phần mềm linh hoạt thì các
bƣớc lặp tăng trƣởng sẽ là bộ khung phát triển cho dự án. Nhƣ vậy rủi ro của toàn dự
án sẽ nằm ngay trong chính các bƣớc lặp tăng trƣởng cho dự án. Điều này có nghĩa
rằng chúng ta sẽ cần phải quản lý tốt rủi ro cho các bƣớc lặp phát triển dự án. Ngồi ra
chúng ta cũng cần phải có một khung nhìn chặt chẽ cho tổng thể dự án với việc dự án
sẽ hoàn thành sau khi các bƣớc lặp dự án hồn thành. Để đảm bảo điều này thì sẽ cần
một chiến lƣợc phân định các bƣớc lặp tăng trƣởng của dự án bao gồm chi tiết hóa các
sản phẩm đầu ra cho mỗi bƣớc lặp (các chức năng, mức độ hồn thành, các thành phần
triển khai,…). Ngay chính chiến lƣợc phân định cho các bƣớc lặp tăng trƣởng cũng đã
tiềm ẩn những rủi ro khơng kiểm sốt đƣợc mức độ gia tăng của số lƣợng cũng nhƣ
chất lƣợng các yêu cầu cần đƣợc đáp ứng của dự án. Có nhiều phƣơng án để đảm bảo
đƣợc chiến lƣợc phân định cho các bƣớc lặp là phù hợp và có thể kiểm sốt đƣợc các
bƣớc lặp tăng trƣởng đó là dựa vào các dự án trong lịch sử, đội chuyên gia kỹ thuật
cho dự án bao quát đƣợc hết vấn đề cơng nghệ cho dự án,… Ngồi ra có thể coi một
bƣớc lặp tăng trƣởng là một dự án và chúng ta sẽ phải quản lý các rủi ro cho bƣớc lặp
tăng trƣởng một cách chặt chẽ. Việc áp dụng mơ hình phát triển phần mềm linh hoạt
hiện nay có nhiều hƣớng nhƣ khung làm việc scrum,…cũng tiềm ẩn nhiều rủi ro đối
với các tổ chức, đội ngũ khác nhau. Các rủi ro đến với các đội ngũ chƣa có nhiều kinh
nghiệm phát triển với mơ hình linh hoạt, việc áp dụng chƣa đúng các tƣ tƣởng của
phát triển phần mềm linh hoạt. Đó là chƣa kể đến việc tổ chức đội ngũ chƣa thống nhất
nhƣ khung làm việc scrum thì cần một ngƣời là scrum master,.. và trách nhiệm cũng
nhƣ giới hạn của những ngƣời này đến đâu. Những điều này đều là rủi ro từ việc tổ
chức đội ngũ phát triển dự án chƣa phù hợp nhƣng quan trọng hơn cả là cần kiểm soát
tốt rủi ro lập lich cho các nhiệm vụ của dự án. Bởi lẽ mơ hình phát triển phần mềm linh
hoạt
16
sẽ coi dự án là một tập các nhiệm vụ chun mơn và việc hồn thành các nhiệm vụ
đồng nghĩa với dự án thành công.
Do vậy việc triển khai phát triển phần mềm theo mơ hình phát triển phần mềm linh
hoạt mang lại những ƣu điểm nhƣng cũng đồng thời có những rủi ro cần đƣợc phải
làm rõ và quản lý tốt trƣớc khi bắt tay vào phát triển dự án. Các vấn đề rủi ro có thể
nhìn nhận qua các phƣơng diện sau:
Thiếu tầm nhìn trong cơng nghệ
Tiến độ dự án bị ảnh hƣởng bởi các yếu tố khách quan
Lịch trình thực hiện dự án cũng nhƣ các vòng lặp tăng trƣởng mơ hồ
Các rủi ro tiềm ẩn về tài nguyên con ngƣời
Sự mất cân đối giữa phân bổ chi phí tài chính cho các vòng lặp tăng trƣởng
trong việc phát triển phần mềm
Thiếu hiệu quả trong việc tổ chức áp dụng các mơ hình phát triển linh hoạt
nhƣ scrum.
Kết chương:
Trong chƣơng I luận văn đã trình bày tổng quan cơ bản về phát triển phần mềm
linh hoạt còn gọi là “Agile Software Development”. Những khái niệm đƣợc trình
bày trong chƣơng I là những kiến thức nền tảng cơ bản trong phát triển phần mềm
linh hoạt. Các tính chất đƣa ra là đặc trƣng cho các bƣớc lặp tăng trƣởng mà sau
đây sẽ xem xét đến.
17
CHƢƠNG II. VẤN ĐỀ LẬP LỊCH BƢỚC LẶP VÀ KỸ THUẬT MẠNG
BAYES
2.1 Vấn đề lập lịch bƣớc lặp trong phát triển phần mềm linh hoạt
Trong quản lý dự án vấn đề lập kế hoạch và lập lịch dự án là rất quan trọng. Kế
hoạch tốt giúp các khâu tiếp theo thực hiện và đóng dự án dễ dàng hơn. Việc lập
lịch có thể sẽ phải chỉnh sửa lại nhiều lần tại các thời điểm khác nhau của dự án,
việc điều chỉnh này do sự thay đổi các nhân tố nhƣ thay đổi về nguồn lực thực hiện
dự án (nhân viên ốm, nhân viên nghỉ việc…), do các thay đổi từ phía khách hàng
nhƣ khách hàng yêu cầu thay đổi tính năng sản phẩm. Nếu nhƣ áp dụng đƣơc các
thuật toán vào khâu lập kế hoạch, lập lịch nhằm tự động hóa đƣợc việc lập kế hoạch
sẽ giảm bớt đƣợc sự sai sót và tăng hiệu quả của việc lập kế hoạch.
Phát triển phần mềm linh hoạt đòi hỏi một lịch trình cụ thể cho các bƣớc lặp tăng
trƣởng tƣơng ứng với các khối lƣợng cơng việc cần hồn thành để đáp ứng các giai
đoạn phát triển. Bởi vì chính các bƣớc lặp giai đoạn phải đảm bảo sự tăng trƣởng của
dự án đến tay ngƣời dùng, để càng ngày đầu ra của dự án càng gần những gì ngƣời
dùng hay khách hàng mong muốn. Điều này đòi hỏi nhà quản lý dự án cần có một cái
nhìn rõ ràng về lịch trình phát triển dự án và có một sự chi tiết hóa việc lập lịch cho các
vịng lặp tăng trƣởng trong việc áp dụng mơ hình phát triển phần mềm linh hoạt để
thực hiện dự án. Nhƣ vậy điều quan trọng là nhà quản lý dự án cần phải phân tích và
đƣa ra đƣợc cụ thể các nhiệm vụ chun mơn cần thực hiện để hồn thành dự án. Điều
này đòi hỏi nhà quản lý và đội phát triển cần có kinh nghiệm từ những dự án họ đã trải
qua để có thể đƣa ra đƣợc hết những nhiệm vụ đó. Sau khi có hết những nhiệm vụ cần
thực hiện thì nhà quản lý dự án cần phải có một chiến lƣợc để gom nhóm các nhiệm vụ
vào các bƣớc lặp tăng trƣởng. Điều này đối với những dự án nhỏ với đầu việc chỉ tầm
dƣới 20 thì ngƣời quản lý có thể lập lịch bằng tay. Nhƣng đối với những dự án mà đầu
việc lên con số 100 thì mọi chuyện hồn tồn khác. Lúc này địi hỏi cần có một chƣơng
trình trợ giúp lập lịch cho các nhiệm vụ để giúp nhà quản lý có đƣợc lịch trình cho các
vịng lặp. Nhƣng với các lịch trình đƣa ra sẽ có đảm bảo sau khi hồn thành thì các sản
phẩm cuối của dự án là các sản
18
