IT003-111-T19_Nhóm 10_Case study 7.4
DANH SÁCH THÀNH VIÊN NHÓM
ST
T
Mã SV Họ và tên Nhiệm vụ Ký tên
1
030125090540 Nguyễn Thị Hoàng
Ngân
- Tìm tài liệu, dịch bài, bài
phân tích, trả lời câu hỏi
2
030125090515 Nguyễn Thảo Nguyên - Tìm tài liệu, dịch bài, làm
powerpoint, kịch bản thuyết
trình
3
030125090992 Phạm Thị Minh Tâm - Tìm tài liệu, thuyết trình,
trả lời câu hỏi
4
030125090812 Nguyễn Lâm Ngọc
Thảo
- Tìm tài liệu, bài phân tích,
giải pháp, kết luận, tổng
hợp bài word, chỉnh sửa
word
5
030125090758 Cấn Thị Minh Thúy - Tìm tài liệu, dịch bài, bài
phân tích, trả lời câu hỏi
6
030125090909 Thái Lai Thị Minh
Trang
- Tìm tài liệu, lời mở đầu,

tóm tắt case study, chỉnh
sửa word
1
IT003-111-T19_Nhóm 10_Case study 7.4
MỤC LỤC
LỜI MỞ ĐẦU 3
BÀI DỊCH CASE STUDY 4
TÓM TẮT TÌNH HUỐNG 7
BÀI PHÂN TÍCH 8
1. Mô hình thác nước (Waterfall model) 8
1.1. Đặc điểm 8
1.1.1. Khái niệm 8
1.1.2. Các giai đoạn của mô hình thác nước 8
1.2. Ưu điểm, nhược điểm của mô hình thác nước 11
1.2.1. Ưu điểm 11
1.2.2. Nhược điểm 11
2. Phương pháp phát triển linh hoạt Agile 13
2.1. Đặc điểm 13
2.2. Ưu điểm, nhược điểm của phương pháp Agile 14
2.2.1. Ưu điểm 14
2.2.2. Nhược điểm 15
3. Giải pháp 17
4. Kết luận 19
TÀI LIỆU THAM KHẢO 20
LỜI MỞ ĐẦU
Ngày nay, với sự phát triển mạnh mẽ của nền kinh tế và mức độ cạnh tranh giữa các doanh
nghiệp ngày càng khốc liệt, việc ứng dụng công nghệ thông tin vào các hoạt động kinh tế, sản xuất
kinh doanh, bán hàng, xúc tiến thương mại, quản trị doanh nghiệp… là rất quan trọng tuy nhiên chỉ
2
IT003-111-T19_Nhóm 10_Case study 7.4

dừng lại ở những hệ thống thông tin hỗ trợ cho cấp tác nghiệp là chưa đủ. Hệ thống thông tin trong
kinh doanh càng lúc càng đi sâu và phát triển mạnh mẽ hơn, hỗ trợ cho cả việc ra quyết định, điều
hành doanh nghiệp, đây là nhân tố góp phần vào sự thành công của doanh nghiệp.
Song, vấn đề khó khăn là làm thế nào để nhà quản trị chọn lựa được giải pháp tốt nhất phù
hợp với mô dình doanh nghiệp để xây dựng hiệu quả hệ thống thông tin kinh doanh. Trong đó, công
cụ ứng dụng của công nghệ thông tin được sử dụng rộng rãi và phổ biến đó là các mô hình phát triển
phần mềm. Và phương pháp cổ điển mô hình thác nước (Waterfall Method) ra đời vào năm 1970, là
một mô hình nổi tiếng và vẫn được áp dụng trong quy trình phát triển phần mềm tại một số các công
ty ra đời hiện nay. Mô hình này hỗ trợ cho việc thiết kế, sản xuất phần mềm theo yêu cầu của khách
hàng.
Tuy nhiên, trong sự phát triển nhanh chóng của công nghệ cùng với những thay đổi thường
xuyên của môi trường xung quanh như kinh tế tài chính, thông tin,… Mô hình thác nước ngày càng
bộc lộ những thiếu sót của mình từ đó dẫn đến sự xuất hiện những phương pháp phát triển phần
mềm mới, linh hoạt hơn, nhanh chóng hơn và tiết kiệm hơn. Và phương pháp phát triển linh hoạt
(Agile Development Methods) là một phần của xu hướng tất yếu được tạo ra dựa trên tiêu chí nhanh
nhẹn và linh hoạt
Vậy đâu là sự lựa chọn tốt nhất giữ mô hình thác nước và phương pháp Agile. Liệu phương
pháp Agile có thật sự tốt để thay thế cho mô hình truyền thống thác nước. Đây chính là đề tài mà
nhóm muốn nhắc đến, bài làm của nhóm vẫn còn nhiều sai sót, rất chân thành đón nhận sự góp ý
của thầy và các bạn. Xin chân thành cảm ơn!
3
IT003-111-T19_Nhóm 10_Case study 7.4
BÀI DỊCH CASE STUDY
BÀI TẬP TÌNH HUỐNG 7.4
SỬ DỤNG PHƯƠNG PHÁP THÁC NƯỚC- WATERFALL, PHÁT TRIỂN LINH
HOẠT- AGILE TẠI CÔNG TY TÀI CHÍNH MELLON
Sự chuyển hướng của Công ty tài chính Mellon sang phương pháp phát triển phần mềm linh
hoạt - Agile là một phần của một xu hướng mới. "Mỗi ngân hàng đầu tư và quỹ phòng ngừa rủi ro
mà tôi đã nói đều đang nhắm đến phương pháp Agile" ông Chapman của hãng SunGard nói.
Phương pháp phát triển linh hoạt- một thuật ngữ tương đối mới được dựa trên sự phát triển

lặp- có nghĩa là phát triển phần mềm trong những phân khúc nhỏ, dễ quản lý, có thể được sửa đổi vì
nhu cầu thay đổi, nhưng vẫn sử dụng cơ chế phân phối một cách nghiêm ngặt.
Trong lịch sử, sự tiếp cận phát triển phần mềm sử dụng khắp phố Wall là phương pháp
Waterfall-"thác nước", nó đòi hỏi phải có sự phân tích nghiêm ngặt, kéo dài và cung cấp các tài liệu
cần thiết về nhu cầu. Ví dụ như đối với một dự án 1 năm, người ta dành ra từ 3 đến 6 tháng để phân
tích những nhu cầu cần thiết. "Những nhà kinh doanh được trông đợi xác định ra 100% các nhu cầu
của họ- cái đặt lên hàng đầu, thậm chí cả trước khi dự án khởi động" Chapman nói. "Mọi người
thường mắc vào tình trạng tê liệt phân tích – đó là họ mất hàng tháng để cố gắng xác định ra những
gì họ muốn."
Ba đến sáu tháng còn lại có thể được dành để thiết kế phần mềm, theo đó, chương trình thực
cuối cùng được viết ra. "Chuyện chắc chắn xảy ra là những nhu cầu sẽ thay đổi, việc tích hợp chúng
lại- các nhu cầu, trở nên rất khó khăn và những mối nguy hiểm trong quá trình phát triển phần mềm
sẽ xảy ra vào giai đoạn cuối của nỗ lực phát triển phần mềm. Phương pháp thác nước có kết quả
hoạt động không được tốt trong việc phân phối."
Phát triển phần mềm linh hoạt- Agile được thiết kế để cung cấp phần mềm một cách nhanh
chóng hơn nhưng vẫn duy trì chất lượng cao. Trong phương pháp Agile, cứ mỗi hai đến bốn tuần,
các nhà kinh doanh sẽ nhận được một số lượng nhỏ các mã để xem xét và nhận lấy cơ hội thay đổi
nhu cầu ban đầu. “ Hãy tưởng tưởng một quỹ phòng ngừa rủi ro nơi mà hệ thống thương mại các
sản phẩm tín dụng phát sinh theo truyền thống sẽ mất một năm để được xây dựng bằng cách sử dụng
phương pháp Waterfall, ngược lại với những nhà kinh doanh viết những tài liệu đó trong 6 tháng
4
IT003-111-T19_Nhóm 10_Case study 7.4
bằng phương pháp Agile, sẽ mất 2 tuần để các hệ thống được phân phối, và nó cũng sẽ ổn nếu bạn
thay đổi suy nghĩ của mình.” Chapman nói. "Đối với các quỹ phòng ngừa rủi ro cá biệt, phương
pháp tiếp cận Agile là một sự thích hợp cực kỳ tốt bởi vì các nhà quản lý danh mục đầu tư muốn mọi
việc được hoàn thành một cách nhanh chóng."
Nhưng mỗi dự án chỉ thích hợp với phương pháp lặp ngắn, Chapman thừa nhận. “ Ở phố
Wall điều đó thì không dễ dàng bởi vì có rất nhiều các hệ thống khác mà bạn cần phải tích hợp lại ",
ông nói. "Nhưng tôi nghĩ rằng có một số phần của phương pháp Agile bạn vẫn có thể sử dụng để cải
thiện các dự án."

Sự phát triển Agile có 3 cấp độ: nhà phát triển, dự án, doanh nghiệp. “Không ai trong phố
Wall sử dụng Agile khi đã đạt mức độ doanh nghiệp”, Chapman nói. “Nhiều vấn đề đào tạo cần phải
thay đổi trong phạm vi các ngân hàng- nó sẽ mất một khoảng thời gian nào đó. Nhưng tôi nghĩ mỗi
dự án sẽ đạt được một vài lợi ích nhất định từ việc cố gắng phân chia dự án thành những phân khúc
nhỏ, dễ quản lý để có thể được phân phối một cách nhanh nhạy và có tính lặp cao hơn.”
Chapman dám chắc rằng phương pháp Agile thậm chí còn cải thiện được chất lượng phần
mềm, bởi vì họ chú trọng việc thử nghiệm. Các phương pháp Agile khuyến khích các nhà phát triển
tự làm thử nghiệm riêng của họ, thường là các mã hóa và phát triển quy trình thử nghiệm tự động
cho những chương trình mà họ cung cấp.
Chapman còn thêm vào rằng: “ Phương pháp phát triển linh hoạt- Agile và CMMI dễ dàng
tương thích lẫn nhau- bạn có thể sử dụng CMM và CMMI cải thiện phương pháp agile”. Mặt khác ,
ông quả quyết rằng, cố gắng sử dụng CMM và CMMI để kiểm soát trong phương pháp thác nước-
Waterfall sẽ chỉ đem lại gánh nặng cho các dự án bằng thói quan liêu và thủ tục hành chính.
Nguồn:www.wallstreetandtech.com/advancedtrading/showArticle.jhtml?
articleID=199601961&cid=RSSfeed_TechWebaccessed via www.computing.co.uk
Câu hỏi:
1) Lời nhận xét “ Khi yêu cầu thay đổi, việc tích hợp trở nên khó khăn và những mối nguy
hiểm trong quá trình phát triển phần mềm sẽ xảy ra vào giai đoạn cuối của nỗ lực phát triển phần
mềm ” muốn đề xuất điều gì về việc tiếp cận bằng phương pháp thác nước truyền thống đến phát
triển phần mềm đối với khâu thiết kế hệ thống ?
2) Bạn có nghĩ rằng, có bất kì rủi ro nào sẽ xảy ra trong việc cố gắng tạo ra sự cắt giảm nhỏ
xung quanh phương pháp truyền thống để thiết kế hệ thống hay không ?
5
IT003-111-T19_Nhóm 10_Case study 7.4
TÓM TẮT TÌNH HUỐNG
Ở công ty tài chính Mellon, việc chuyển đổi sang phương pháp phát triển phần mềm linh hoạt
(Agile Development Methods) là một xu thế tất yếu. Nó dựa trên sự phát triển lặp: phát triển phần
mềm ở những phần nhỏ, dễ quản lý, có thể chỉnh sửa khi có yêu cầu thay đổi thông qua một cơ chế
tương đối nghiêm ngặt.
Trước đây, mô hình được sử dụng phổ biến ở phố Wall là phương pháp mô hình thác nước

(Waterfall Method). Ở phương pháp này, nhu cầu của khách hàng đòi hỏi phải được phân tích một
cách chặt chẽ, phức tạp trong một thời gian dài vì thế mọi người bị mắc kẹt trong một tiến trình
phân tích và phải mất hàng tháng để xác định là họ muốn gì. Ví dụ đối với dự án kéo dài một năm,
quy trình phân tích đã chiếm từ ba đến sáu tháng và ba đến sáu tháng tiếp theo dành cho việc thiết
kế phần mềm, rồi mới bắtt đầu viết chương trình. Theo Chapman: “Sự thay đổi các yêu cầu là không
thể tránh khỏi, khi đó việc thống nhất khó mà đạt được, và những rủi ro phát sinh vào cuối tiến trình
của phần mềm”.
Phương pháp phát triển phần mềm linh hoạt được thiết kế nhằm cung cấp phần mềm theo nhu
cầu của khách hàng một cách nhanh chóng hơn mà vẫn đảm bảo dược chất lượng cao. Trong
phương pháp này, cứ mỗi hai đến bốn tuần, các nhà thiết kế nhận được một đoạn mã nhỏ để xem
trước, sau đó sẽ đưa ra yêu cầu thay đổi nếu cần thiết. Tuy nhiên Chapman cũng thừa nhận rằng
không phải bất cứ dự án nào cũng tương thích với phương pháp lặp, nhưng vẫn có những khía cạnh
của phương pháp lập trình linh hoạt có thể áp dụng để cải thiện dự án.
6
IT003-111-T19_Nhóm 10_Case study 7.4
BÀI PHÂN TÍCH
1. Mô hình thác nước (Waterfall model)
1.1. Đặc điểm:
1.1.1. Khái niệm :
Mô hình thác nước còn được gọi là mô hình tuần tự tuyến tính, quy định trình tự các giai
đoạn cần phải thực hiện khi xây dựng một hệ thống thông tin. Mô hình thác nước có thể được minh
họa như trong hình 1. Các giai đoạn được tiến hành tuần tự và mỗi giai đoạn bắt đầu sau khi giai
đoạn trước kết thúc. Mỗi giai đoạn đều có liên kết quay ngược lại giai đoạn trước đó để sửa chữa
những sai sót trong giai đoạn trước đó.
Hình 1. – Mô hình thác nước
1.1.2. Các giai đoạn của mô hình thác nước:
• Khởi tạo:
Giai đoạn khởi tạo là giai đoạn đầu tiên trong một dự án phát triển hệ thống thông tin. Mục
đích là để ược lượng tính khả thi của dự án và đưa ra các bước chuẩn bị để đảm bảo các dự án thành
7

IT003-111-T19_Nhóm 10_Case study 7.4
công. Giai đoạn khởi tạo bao gồm cả các tác nhân kích thích (từ môi trường bên ngoài và bên trong)
mà từ đó phát sinh nhu cầu về hệ thống thông tin kinh doanh
• Đánh giá khả thi
Đánh giá khả thi là công việc cần phải thực hiện khi bắt đầu một dự án để đảm bảo rằng dự
án này là một kế hoạch kinh doanh có thể thực hiện được. Bản báo cáo khả thi phân tích yêu cầu và
ảnh hưởng của hệ thống mới đồng thời xem xét các giải pháp triển khai thích hợp.
• Phân tích hệ thống:
Quá trình phân tích nhằm nắm bắt yêu cầu nghiệp vụ của hệ thống trong thực tế bằng cách
phỏng vấn, quan sát trực tiếp người dùng cuối tại nơi làm việc hay xem xét các tài liệu có sẵn trong
hệ thống. Có 3 nhiệm vụ chính trong giai đoạn này:
- Đầu tiên, cần phải xác định rõ hệ thống hiện tại vận hành như thế nào.
- Thứ hai, đưa ra mô hình về hệ thống hiện tại để đảm bảo sự thỏa thuận giữa các chuyên gia phần
mềm và người dùng cuối.
- Cuối cùng, một bản đặc tả các yêu cầu về hệ thống mới được đưa ra.
Nếu trong quá trình xác định yêu cầu, việc thực hiện một yêu cầu nào đó được phát hiện là
không khả thi thì phải quay lại bước đánh giá khả thi và thực hiện phân tích bổ sung cho các giải
pháp.
• Thiết kế hệ thống:
Quá trình thiết kế hệ thống nhằm xác định hệ thống mới sẽ làm việc như thế nào, bao gồm
giao diện người dùng, các module (một đơn vị có chức năng riêng trong hệ thống máy tính hay tin
học) chương trình, tính bảo mật, thiết kế cơ sở dữ liệu.
Nhiệm vụ của giai đoạn này là chuyển đổi những đặc tả yêu cầu thành các bản thiết kế khác
nhau để từ đó có thể chọn ra bản thiết kế tốt nhất.
Nếu trong quá trình thiết kế, có một yêu cầu nào đó không rõ ràng hay không thể thể hiện
thành một bản thiết kế thì sẽ phải quay trở lại giai đoạn phân tích và xác định chi tiết hơn nữa yêu
cầu về hệ thống mới.
• Xây dựng hệ thống:
Đây là giai đoạn xây dựng phần mềm được thực hiện bởi các lập trình viên bao gồm: lập
trình, xây dựng cơ sở dữ liệu, kiểm thử, lập tài liệu hướng dẫn, tập huấn sử dụng,…

8
IT003-111-T19_Nhóm 10_Case study 7.4
Quá trình này bao gồm 3 bước nhỏ hơn:
+ Xây dựng cơ sở dữ liệu
+ Lập trình
+ Kiểm lỗi
Kết quả quá trình xây dựng hệ thống là một hệ thống thông tin đã được kiểm lỗi và sẵn sàng
cho việc chuyển đổi dữ liệu hay đưa vào sử dụng thực tế.
Nếu ở bước kiểm lỗi phát hiện rằng hệ thống không đáp ứng những yêu cầu ban đầu được
xác định ở bước phân tích thì sẽ phải quay lại bước thiết kế hệ thống để xác định xem có lỗi nào
trong quá trình chuyển đổi yêu cầu hay không. Nếu giai đoạn thiết kế diễn giải chính xác nhưng hệ
thống không đáp ứng nhu cầu của người dùng thì sẽ phải quay lại bước phân tích để xác định yêu
cầu của hệ thống một cách chính xác hơn.
• Triển khai hệ thống và chuyển đổi:
Quá trình này bao gồm việc cài đặt phần cứng và mạng cho hệ thống mới, kiểm thử bởi
người tiêu dùng và tập huấn sử dụng. Đồng thời bao gồm việc chuẩn bị và tiến hành thay đổi, nâng
cấp hệ thống cũ thành hệ thống mới. Tại bước này, sẽ phát hiện được là hệ thống thống thông tin
mới có hoạt động tốt và thực sự đáp ứng những yêu cầu của người dùng hay không? Nếu phát sinh
lỗi thì đòi hỏi quay trở lại các giai đoạn trước đó, tùy vào tính chất và mức độ nghiêm trọng của lỗi.
• Xem lại và bảo trì:
Một khi hệ thống thông tin được vận hành trong thực tế, nó sẽ gặp phải những yêu cầu thay
đổi theo thời gian. Sau một khoảng thời gian hoạt động, hệ thống cần phải được thay đổi và thích
nghi với sự thay đổi của yêu cầu kinh doanh.
- Giai đoạn bảo trì bao gồm 2 loại: sửa chữa các tính năng, sửa lỗi cho phù hợp với đặc tả ban đầu và
thêm các tính năng mới.
- Giai đoạn xem lại: xem xét mức độ thành công của dự án và rút ra các bài học trong tương lai. Giai
đoạn này thường được tiến hành 6 tháng sau khi chạy thực tế hệ thống.
1.2. Ưu điểm, nhược điểm của mô hình thác nước:
1.2.1.Ưu điểm:
Đây là mô hình phát triển sớm nhất nên nó có ý nghĩa lý thuyết cao, nó là một mô hình tốt để

giới thiệu về quá trình phát triển hệ thống thông tin.
9
IT003-111-T19_Nhóm 10_Case study 7.4
Thuận lợi của mô hình thác nước là có thể dễ dàng phân chia quá trình phát triển hệ thống
thành những giai đoạn hoàn toàn độc lập, đơn giản và rõ ràng với một thời hạn nhất định để dễ dàng
quản lý. Mỗi khâu của chu trình phát triển được triển khai trong một khuôn khổ nghiêm ngặt.
Mô hình thác nước hạn chế tối thiểu các cố gắng dành cho những hoạt động không cho ra kết
quả (mỗi giai đoạn phải có kế hoạch cụ thể và kết quả của giai đoạn trước sẽ tiếp nối cho sự bắt đầu
của giai đoạn tiếp theo) nên buộc phải hoàn thành từng giai đoạn. Cho nên dễ dàng quản lý đầu vào
và đầu ra của từng giai đoạn.
Phạm vi của mô hình có thể áp dụng cho các dự án nhỏ (vì tính đơn giản của nó) và dự án
cực kỳ lớn (do tính rõ ràng cẩn thận của nó). Thích hợp với các dự án mà yêu cầu hệ thống rõ ràng
và ít thay đổi.
1.1.2. Nhược điểm:
Trong mô hình thác nước truyền thống của lĩnh vực phát triển phần mềm, khâu phân tích nhu
cầu là khâu quan trọng nhất. Như bảng 2 đã chỉ ra, theo dữ liệu từ nhiều tổ chức khác nhau đã chỉ ra
rằng trong những dự án lớn, một lỗi được phát hiện trong khâu phân tích yêu cầu trong giai đoạn
thiết kế thì chỉ tốn gấp 3 lần so với chi phí để sửa lại nó nếu được phát hiện trong giai đoạn phân
tích. Tương tự nếu bị phát hiện trong giai đoạn xây dựng thì tốn gấp 5 đến 10 lần chi phí; trong giai
đoạn triển khai hệ thống thì gấp 10 lần; trong giai đoạn bảo trì đánh giá thì sẽ tốn gấp 10 đến 100 lần
chi phí. Dự án càng lớn thì chi phí sửa chữa sẽ càng tăng. Việc xác định các yêu cầu một cách chính
xác là chìa khóa thành công của một dự án, có lẽ còn quan trọng hơn cả công nghệ thiết kế nữa. Do
đó mô hình chỉ thích hợp khi các yêu cầu phần mềm được rõ ràng và không bị thay đổi (hoặc chỉ
giới hạn ở khâu thiết kế). Trong khi đó có rất ít hệ thống có yêu cầu rõ ràng và ổn định.Những cuộc
nghiên cứu tại IBM và các công ty khác đã tìm ra rằng trung bình một dự án sẽ trải qua 25% thay
đổi trong yêu cầu trong suốt quá trình phát triển hệ thống. [4, pp. 44 - 45]
10
IT003-111-T19_Nhóm 10_Case study 7.4
Hình 2: Chi phí để sửa một lỗi sẽ tăng một cách đáng kể theo thời giam kể từ khi bắt đầu đến
lúc kiểm thử. (Điều này luôn luôn đúng kể cả dự án có tính liên tục cao hay tính lặp cao). [4, pp. 35]

Trong một dự án điển hình bản thân khách hàng cũng không thể miêu tả một cách đáng tin
cậy và chính xác về những yêu cầu trước khi họ có thể nhìn thấy mô hình hoạt động.Vấn đề ở đây là
chỉ khi làm việc nhiều với nó, bạn mới hiểu rõ về nó nhất. Khi khách hàng tiếp xúc với hệ thống họ
mới hiểu rõ hơn về những cái mà họ cần và điều này sẽ tạo ra sự một sự thay đổi lớn về yêu cầu.
Tuy nhiên, mô hình thác nước được xem là quá cứng nhắc và thiếu thực tế. Quá trình phát triển hệ
thống được chia thành các phần độc lập tạo nên nhiều khó khăn khi có thay đổi về yêu cầu từ khách
hàng.Với mô hình thác nước, việc theo kịp các thay đổi là không thể thực hiện vì vòng quy trình của
nó quá dài.
Một vấn đề nữa đó là tồn tại một khoảng cách về giao tiếp giữa người sử dụng và người thiết
kế. Thông thường, khách hàng và các kĩ sư phần mềm thất bại trong khâu giao tiếp để hiểu nhau bởi
vì họ ở hai thái cực khác nhau và hiểu các khâu kĩ thuật khác nhau. Trong lịch sử, các nhà phát triển
hệ thống bị cô lập với người sử dụng thông qua rào cản về mặt thuật ngữ, do đó gây bất lợi trong
việc trao đổi các vấn đề nghiệp vụ. Vấn đề thuật ngữ chuyên môn có thể làm chậm lại tiến trình phát
triển trong một số dự án. Một chu trình với những yêu cầu được cụ thể khắt khe thực sự là một chu
trình không đáp ứng được yêu cầu khách hàng.
Với những phân tích trên về phương pháp phát triển phần mềm truyền thống thác nước, ta thắc
mắc rằng tại sao chúng lại được sử dụng và nếu chúng đã được sử dụng trong quá khứ thì lại từ bỏ
11
IT003-111-T19_Nhóm 10_Case study 7.4
chúng bây giờ? Phải chăng một vài thứ đã thay đổi. Sự phát triển phần mềm diễn ra một cách nhanh
chóng và sự thay đổi diễn ra đồng thời ở lĩnh vực công nghệ, tài chính, thông tin. Mọi việc diễn ra
nhanh hơn. Những đối thủ xuất hiện, sự thành công hay thất bại chỉ là ranh giới mong manh. Vòng đời
của sản phẩm ngắn hơn và người dùng thì hay thay đổi. Không có gì là ngạc nhiên khi những phương
pháp phù hợp với thập niên 70 lại thất bại trong thập niên 80 và 90. Trong thập kỉ 90 nhiều người đã
nhận ra mọi thứ đã thay đổi bằng cách này hay cách khác. Những người này đã quan tâm tới những
phương pháp phát triển phần mềm linh hoạt hơn, phù hợp hơn với môi trường làm việc luôn luôn vận
động.
Mặc dù chi tiết những phương pháp này là khác nhau nhưng chúng đều có
chung một số
nguyên tắc và trong một phạm vi nào đó những phương pháp này thường được nhóm lại với nhau dưới

tên gọi “những phương pháp linh hoạt -Agile methodologies”.
2. Phương pháp phát triển linh hoạt Agile
2.1. Đặc điểm
Phương pháp phát triển linh hoạt Agile cho phép các dự án được hoàn thành nhanh chóng mà
vẫn đảm bảo được yêu cầu về chất lượng và dễ dàng trong việc sửa chữa, cập nhật khi những yêu
cầu thay đổi vào bất cứ giai đoạn nào của dự án cho đến khi dự án kết thúc và sản phẩm được giao
cho khách hàng. Phương pháp phát triển linh hoạt có những đặc điểm sau:
Thứ nhất, nó được phát triển dựa trên quy trình phát triển lặp (interative development) – mỗi
dự án sẽ được chia ra thành nhiều mảng nhỏ, dễ sử dụng và dễ sửa đổi khi yêu cầu của khách hàng
thay đổi. Dự án sẽ được thực hiện từng theo từng mảng nhỏ này, giống như những dự án nhỏ, hết dự
án này quy trình sẽ lại bắt đầu với dự án tiếp theo cho đến khi tất cả những yêu cầu của khách hàng
được đáp ứng và dự án được bàn giao.
Thứ hai, với phương pháp Agile, cứ mỗi hai hay bốn tuần, nhóm lập trình viên sẽ giao cho
khách hàng một phần của dự án, khách hàng sẽ kiểm tra và được khuyến khích đưa ra những ý
tưởng mới, những yêu cầu mới hoặc thay đổi những yêu cầu của dự án. Theo đó, nhóm lập trình
viên có thể cập nhật và sửa đổi sản phẩm theo đúng yêu cầu của khách hàng thay vì chỉ căn cứ vào
hợp đồng và làm việc. Cần lưu ý là việc làm này không giống với phương pháp Waterfall, việc sửa
đổi này giúp cho ứng dụng tốt hơn, đẹp hơn và không phá hỏng nó, không buộc phải bắt đầu lại từ
đầu.
Thứ ba, với phương pháp Agile, từng phần nhỏ của dự án phần mềm sẽ được kiểm tra ngay
trong quá trình làm dự án và việc này do chính các lập trình viên làm thay vì phải có các nhóm kiểm
12
IT003-111-T19_Nhóm 10_Case study 7.4
tra (tester) độc lập. Bằng cách sử dụng công cụ “unit test” (kiểm tra từng phần), từng phần của dự án
sẽ được kiểm tra ngay trong quá trình phát triển trước khi tích hợp vào phần mềm.
Thứ tư, phương pháp Agile nhấn mạnh vào việc gặp mặt trao đổi hàng ngày giữa các thành
viên trong nhóm dự án. Khác với phương pháp phát triển truyền thống, các thành viên của nhóm dự
án được chia ra phát triển từng mảng riêng biệt, với phương pháp này, tại mỗi thời điểm, cả nhóm
cùng tập trung phát triển một mảng của dự án. Vì vậy, nó yêu cầu các thành viên có sự tập trung về
địa lí, cùng bàn bạc thảo luận hàng ngày để hoàn thành dự án đúng thời hạn.

Thứ năm, phương pháp Agile dựa vào việc phát triển trên từng nhóm nhỏ (10 thành viên trở
xuống), các thành viên phải là những người có kĩ năng cao và hiểu biết về dự án, hơn nữa, các thành
viên trong nhóm cần tin tưởng lẫn nhau, chia sẻ thông tin với nhau. Với nhóm ít thành viên, các
thành viên cũng cần có nhiều kĩ năng hơn so với việc lập trình và kiểm thử truyền thống.
Với những đặc điểm như trên, hiện nay phương pháp phát triển linh hoạt đang ngày càng
được ứng dụng rộng rãi với những phần mềm trị giá hàng chục triệu, thậm chí hàng trăm triệu đô la
Mỹ (USD).
2.2. Ưu điểm, nhược điểm của phương pháp Agile
2.2.1 Ưu điểm
Như đã phân tích ở trên, phương pháp Agile hoạt động dựa trên nguyên tắc lặp, tức là, mỗi
dự án được chia thành nhiều module nhỏ, mỗi module đều thực hiện những chức năng giống nhau
được lặp đi lặp lại: tập hợp yêu cầu, lập kế hoạch, phân tích, code, test…Cũng với một trình tự như
vậy nhưng mô hình thác nước hướng đến cách tiếp cận cấu trúc có định trước, nó không có sự linh
hoạt trong việc phân chia các giai đoạn của dự án, mỗi khâu phải đảm bào hoàn thành chính xác
100% trước khi chuyển sang khâu tiếp theo. Đây có thể coi là sự khác nhau cơ bản dẫn đến những
khác nhau tiếp theo của hai phương pháp
Thứ nhất, về rủi ro của phương pháp. Phương pháp Agile đã khắc phục được vấn để rủi ro
cao khi có lỗi xảy ra. Với các module nhỏ hoạt động như nhau, Agile cho phép dự án được kiểm tra
một cách thường xuyên bởi cứ cuối mỗi giai đoạn thử nghiệm đều có thể đưa ra kết quả. Như thế
đảm bảo phát hiện và loại bỏ các lỗi sai trong vòng phát triển, kết quả sẽ được kiểm tra lại hai lần
sau đợt sàng lọc lỗi đầu tiên, từ đó, giảm thiểu tối đa rủi ro cho mình cũng như khách hàng, tiết kiệm
được thời gian cũng như chi phí dành cho dự án.
13
IT003-111-T19_Nhóm 10_Case study 7.4
Thứ hai, tính linh hoạt và sự phù hợp với thực tế của mô hình thác nước gần như bị triệt tiêu
đến thời điểm bàn giao dự án cho khách hàng, đặc biệt là đối với những ngành nghề mang tính chất
nhạy cảm cao với thông tin thị trường, thường xuyên thay đổi như tài chính ngân hàng…nhưng
phương pháp Agile lại hoàn toàn ngược lại. khách hàng của Agile lại có thể thay đổi yêu cầu của
mình trước những biến động bất thường của thị trường, vì cứ cuối mỗi giai đoạn của Agile sẽ có một
chương trình hợp lý được lập trình nhằm giải quyết và sửa chữa những ý tưởng mới.

Thứ ba, phương pháp Agile phù hợp với những dự án nhỏ, có tính chất thay đổi thường
xuyên, yêu cầu thời gian hoành thành nhanh chóng và rủi ro thấp.
Thứ tư, đặc tính tự điều chỉnh của phương pháp Agile chính là tận dụng tốt hơn việc lập trình
và chương trình hướng đến đối tượng phù hợp, nghĩa là phương pháp này sỡ hữu mô hình hoạt động
đưa ra những kết quả kịp thời ngay cả khi phương pháp này không phù hợp hoàn toàn với những chỉ
định của khách hàng. Trong khi đó, mô hình thác nước chỉ đưa ra được một kết quả duy nhất và bất
kỳ rắc rối hay trì hoãn nào đều khiến khách hàng thất vọng. Cùng với đó là việc phương pháp Agile
thậm chí còn cải thiện chất lượng phần mềm do chúng chú trọng vào việc thử nghiệm. Phương pháp
Agile khuyến khích các lập trình viên tự mình thử nghiệm, thường xuyên yêu cầu họ đưa ra các thử
nghiệm trước khi đưa ra bất kỳ mã nào và phát triển những thói quen kiểm tra tự động cho các
chương trình họ đưa ra.
2.2.2. Nhược điểm.
Không có phương pháp nào luôn tối ưu và phương pháp phát triển linh hoạt Agile cũng vậy.
Một trong những yêu cầu tiên quyết trong dự án phát triển phần mềm linh hoạt là các thành viên
tham gia phải có trình độ cao và tương đối cân bằng, có tinh thần làm việc tích cực và kỷ luật cá
nhân cao để đáp ứng nhu cầu liên tục tự sáng tạo và cải tiến. Nếu bạn có một dự án phân phối toàn
cầu và các nhân viên phát triển ở nhiều nước khác nhau thì họ có thể sẽ không giao tiếp nhanh với
nhau được, vì vậy, bạn không nên dùng Agile. Nếu các thành viên trong nhóm không được huấn
luyện cách làm việc nhóm thì cũng sẽ khó mà dùng được phương pháp Agile. Nếu các nhân viên
phát triển không có kỹ luật và kỹ năng cao liên quan đến công nghệ phần mềm thì phương pháp
Agile có thể sẽ không hiệu quả vì nó đòi hỏi những kỹ năng tinh túy mà nhiều lập trình viên thường
không có được.
Ngoài ra, mô hình nhóm thực hiện không cùng vị trí địa lý với chủ dự án (offshore) thường
yêu cầu phải có một đại diện khách hàng có mặt cùng địa điểm với nhóm phát triển. Người này có
14
IT003-111-T19_Nhóm 10_Case study 7.4
thể kịp thời giải đáp các thắc mắc ngay khi có vấn đề phát sinh và duy trì phần mềm phát triển đúng
hướng. Nếu tốc độ sáng tạo nhanh nhưng phản hồi chậm cũng dẫn tới phí phạm tài nguyên dự án và
có thể chuyển sang hướng phát triển không phù hợp.
Ông Cem Kaner, Giáo sư ngành Công nghệ phần mềm - Học viện Kỹ thuật Florida ở Mỹ,

cho rằng ưu điểm lớn nhất của phương pháp Agile là khả năng đưa ra và theo đuổi nhiều hướng đi
trong quá trình phát triển. Nhưng đây cũng chính là khuyết điểm của nó. “Những hướng phát triển
sai sẽ tiêu tốn nguồn lực của dự án, nhất là quỹ thời gian. Theo phương pháp này, thường phải đợi
đến khi kết thúc các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp không. Do đó, nếu
phải tiêu tốn thời gian liên lạc giữa nhóm phát triển và khách hàng thì dự án kéo lùi tiến độ. Trong
thực tế, nếu khách hàng ở nước ngoài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và múi
giờ. Khi đó, phương pháp phát triển phần mềm linh hoạt sẽ là không hợp lý”. [6]
Bên cạnh đó, các chuyên gia trong lĩnh vực phần mềm cũng đồng ý rằng phát triển phần mềm
linh hoạt thường khó mở rộng quy mô, không phù hợp với các dự án phần mềm lớn có nhiều nhân
lực. Các dự án lớn thường được chia làm nhiều phần nhỏ, cấu trúc tương đối chặt chẽ và không có
chỗ cho sai sót. Các nhóm phát triển cần thống nhất rất cao về định hướng và hầu như không còn
nhiều chỗ cho sáng tạo, dù nó cũng cần qua nhiều thảo luận để đưa vào ứng dụng thực tế. Với các
dự án này, các nhóm thực hiện nếu có sẽ là một phần của kiến trúc lớn, dưới sự kiểm soát chặt chẽ
khách hàng.
Những điểm nói trên đi ngược với bản chất của phương pháp Agile. Sẽ rất khó quản lý khi dự
án đạt quy mô vài ngàn nhân lực. Do đó, hiện tại phương pháp Agile được áp dụng chủ yếu cho các
dự án tầm trung trở xuống, ở các mảng ứng dụng web, ứng dụng trên di động và các dự án gia công
kiểm thử trong và ngoài nước.
3. Giải pháp.
Theo những phân tích trên thì cả hai phương pháp phát triển phần mềm là mô hình thác nước
truyền thống và phương pháp phát triển linh hoạt Agile đều có những ưu và nhược điểm nhất định.
Vấn đề quan trọng không phải là bạn so sánh những nhược điểm hay ưu điểm của hai mô hình để
lựa chọn giữa hai phương pháp mà bạn phải xác định được mô hình nào cùng với những ưu điểm
của nó sẽ phục vụ tốt cho dự án phát triển của bạn, có thể mô hình đó vẫn có những nhược điểm ảnh
hưởng đến dự án của bạn nhưng đó vẫn là lựa chọn tốt nhất vì nó đã phát huy tối đa ưu điểm của
mình cho dự án của bạn, giúp bạn giảm thiểu những ảnh hưởng không tốt mà mô hình đó mang lại.
15
IT003-111-T19_Nhóm 10_Case study 7.4
Dưới đây là một số câu hỏi bạn cần có câu trả lời trước khi quyết định sử dụng phương pháp mô
hình thác nước hay Agile

Các nhu cầu ổn định tới mức nào?
Một trong những nhân tố lớn nhất tác động đến sự lựa chọn phương pháp phát triển phần
mềm là tính rõ ràng và ổn định của các nhu cầu về dự án. Việc thường xuyên thay đổi nhu cầu sau
khi dự án bắt đầu có thể làm trật chương trình ra khỏi kế hoạch ban đầu. Trong nhiều trường hợp,
việc lựa chọn phương pháp Agile là sẽ cung cấp cho bạn một cơ hội để cân nhắc những nhu cầu mới
sau khi dự án khởi động. Nói cách khác, nếu bạn tiến hành một dự án phát triển truyền thống với
những quy định nghiêm ngặt, các yêu cầu đã được đặt ra trước khi đến với các giai đoạn sau để đảm
bảo hoàn thành hệ thống, phương pháp thác nước có thể được xem là một lựa chọn tốt.
Ai là người sử dụng cuối cùng của hệ thống?
Hãy dành một ít thời gian của bạn để biết về những người sử dụng cuối cùng và các bên liên
quan. Họ là ai? Họ có thể bị phân tán hay kiểm soát không? Làm cách nào họ tác động được đến dự
án. Một nhóm người sử dụng cuối cùng có kiểm soát tác động khá nhiều đến dự án, họ có thể giúp
bạn xác định các nhu cầu và quản lí sự thay đổi. Điều này có nghĩa là bạn có thể kiếm được những
nhu cầu bền vững cho phép bạn sử dụng mô hình thác nước.
Nói cách khác, nếu người sử dụng cuối cùng bị phân tán, bạn có thể có được phạm vi rộng
hơn những nhu cầu, nhưng bạn không thể định nghĩa nó cho đến khi những người sử dụng cuối
cùng này sử dụng qua hệ thống và bắt đầu đề nghị cần có những đặc điểm gì mới (để thêm vào cái
cũ). Ví dụ như khi Google bắt đầu cung ứng Gmail và tất các sản phẩm kèm theo như Google Doc,
Lịch BETA vì họ muốn biết phản hồi của người thử nghiệm sản phẩm cuối cùng và để cải thiện dựa
trên phản ứng (hồi đáp) từ những người này (trước khi đưa ra sản phẩm chính thức). Hoặc hãng
Microsoft, nhà phát triển những phần mềm thông dụng nhất thế giới như Windows hay Office, cũng
áp dụng phương pháp phát triển nhanh trong hệ thống những phương pháp sử dụng để phát triển
phần mềm. Microsoft hay Google chọn phương pháp Agile nhiều vì họ có những nhóm sử dụng thử
nghiệm (sản phẩm) cuối khá rộng.
Kích thước của dự án như thế nào?
Một dự án cho một tổ chức kinh doanh lớn thường yêu cầu một số lượng lớn các đội dự án để
phân chia rõ ràng công việc. Quy mô khâu phân chia phải cân xứng với kích thước của các đội dự
16
IT003-111-T19_Nhóm 10_Case study 7.4
án được phân chia. Do vậy, những đội dự án lớn được phân chia việc lớn hơn và được giải thích cặn

kẽ hơn về công việc. Với việc làm như trên, mô hình thác nước trở nên thật lí tưởng.
Phạm vi xác định của một đội dự án?
Nếu bạn có nhiều các dự án được đặt trong những vị trí địa lí khác nhau, sự phối hợp trong
công việc cần được chi tiết và chặt chẽ hơn. Phân công công việc cần được xác định rõ để tránh lộn
xộn và dư thừa. Trong nhiều trường hợp, mô hình thác nước có thể đem lại nhiều lợi ích vì nó cung
cấp các khâu phân chia công việc và mốc thời gian rõ ràng. Áp dụng phương pháp Agile vào các đội
khác biệt về địa lí có thể xem như một thử thách khó khăn vì phương pháp Agile đòi hỏi phải có sự
giao tiếp thường xuyên giữa có thành viên để cùng thảo luận, chia sẻ thông tin cho việc hoàn thành
dự án.
Các nguồn tài nguyên quan trọng là gì?
Một vài dự án yêu cầu những nguồn tài nguyên riêng, hiếm hoặc kết hợp được với thiết bị
chuyên dụng. Trong trường hợp những nguồn tài nguyên đó không có sẵn ngay và phải yêu cầu lên
kế hoạch, đội dự án cần đảm bảo những nguồn tài nguyên này đủ dùng trong suốt quá trình sử dụng
theo kế hoạch. Hơn thế nữa, khâu kiểm định nên được diễn ra trên tất cả các quá trình có thể có
trong suốt thời gian chờ nguồn tài nguyên sẵn sàng. Mặt khác, yêu cầu có thêm những nguồn tài
nguyên như thế khác nữa có thể sẽ gây ra một vài sự trì hoãn cho dự án. Trong nhiều trường hợp,
phương pháp thác nước có thể là cách tiếp cận tốt nhất, nơi mà mỗi mốc công việc có thể hoàn thành
trước khi tiến trình chuyển sang khâu kế tiếp và bạn được đảm bảo rằng những nguồn lực tới hạn đã
sẵn sàng để sử dụng. [7]
4. Kết luận.
Mô hình thác nước thích hợp cho sự phát triển của các chương trình đã được ổn định. Trong
các tình huống mà các nhà thiết kế của một chương trình phần mềm có thể dự đoán chính xác những
sai sót có thể phát sinh thì mô hình thác nước là sự lựa chọn thích hợp. Mặc dù vẫn có các sai sót
nhưng mô hình thác nước có được sự dễ dàng trong việc quản lý và các chi phí phát triển có thể
được xác định trước. Còn phương Agile được áp dụng trong mọi lĩnh vực của phát triển phần mềm.
Nó phụ thuộc rất nhiều vào nỗ lực của cả đội ngũ lập trình hơn là dựa vào một vài chuyên gia lập
trình.
Vấn đề quan trọng ở đây không là việc cố gắng so sánh sự khác biệt cơ bản giữa hai mô hình
thác nước và Agile. Những gì cần làm là thiết kế một mô hình lý tưởng, phù hợp với môi trường
17

IT003-111-T19_Nhóm 10_Case study 7.4
công ty, với dự án. Điều quan trọng là có được sự nhanh nhẹn chứ không chỉ làm Agile. Nói cách
khác, việc lựa chọn phương pháp Agile không nên được thực hiện một cách cứng nhắc nếu có yêu
cầu thay đổi. Cá nhân, nhóm và các tổ chức phải đủ linh hoạt để thay đổi cách tiếp cận của họ cho
phù hợp với điều kiện thay đổi của môi trường bên trong và bên ngoài.
TÀI LIỆU THAM KHẢO
I. Sách tham khảo, bài luận, báo cáo
1. ThS. Nguyễn Ngọc Đức, ThS. Nguyễn Huỳnh Anh Vũ (2011), Hệ thống thông tin quản trị,
Nxb lao động – xã hội.
2. Pekka Abrahamsson (2002), Agile software development methods – Review and analysis,
tech. report, VTT Publications 478
3. Roger Fance (2011), Is Agile or Water the best? The answer is not binary!, UXC
Consulting.
4. Steve McConnell (2004), Code Complete, 2
nd
Edition. Redmond, Microsoft Press.
II. Nguồn Internet
5. Dương Trọng Tấn (2011), Tổng quan Agile – Phần 1: Đặc trưng. Được lấy về ngày
19/11/2011 từ:
/>6. Nhật Khang (2011), Phát triển phần mềm linh hoạt. Được lấy ngày 13/11/2011, từ:
/>mem-linh-hoat/
7. ExecutiveBrief Staff (2007), Which life cycle is best for your project? Được lấy ngày
18/11/2011, từ:
/>8. Gina Lijoi (2010), Can we combine Agile and Waterfall development strategies?. Được lấy
về ngày 14/11/2011 từ:
/>strategies.html
18
IT003-111-T19_Nhóm 10_Case study 7.4
9. Gray Pilgrim (2011), Waterfall Model Vs Agile. Được lấy về ngày 14/11/2011 từ:
/>

19