Đề tài “Tìm hiểu về quy trình phát triển phần mềm theo Agile” pptx

Trường đại học điện lực Khoa CNTT
MỤC LỤC
LỜI MỞ ĐẦU 5
BẢNG PHÂN CÔNG CÔNG VIỆC 6
PHẦN I. TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM VÀ QUY TRÌNH PHÁT TRIỂN
PHẦN MỀM 7
I. Tìm hiểu chung về công nghệ phần mềm 7
1. Công nghệ phần mềm là gì ? 7
- Phần mềm máy tính là gì? Phần mềm máy tính (Computer software) là các sản phẩm do
nhà phát triển phần mềm thiết kế và xây dựng nhằm phục vụ một mục đích nào đó 7
II. Quy trình phát triển phần mềm truyền thống 8
1. Đặc điểm 8
- Các phương pháp truyền thống là các phương pháp thiên về kế hoạch, quá trình phát triển
phần mềm phải tuân theo một quy trình nghiêm ngặt. Trong quá trình phát triển phần mềm,
rất nhiều tài liệu được tạo ra, được xét duyệt và đó là một yếu tố quan trọng trong quản lí
rủi ro 8
- Với các phương pháp này, toàn bộ quá trình phát triển thường được lên kế hoạch chi tiết
và các tài liệu trước cũng như trong quá trình phát triển được chuẩn bị đầy đủ. Quá trình
phát triển được thực hiện theo quy trình được định trước, và việc tuân thủ quy trình sẽ làm
tăng chất lượng phần mềm và giảm rủi ro 8
- Theo các phương pháp này thì quá trình sản xuất phần mềm giống như sản xuất các mặt
hàng công nghiệp khác. Những người phát triển thực hiện công việc một cách nghiêm ngặt
theo các chuẩn và quy trình, không yêu cầu sáng tạo nhiều. Những người quản lí chỉ cần
tăng năng lực sản xuất và đạt được các mục tiêu như: 8
- Giảm thiểu lỗi và công việc diễn ra trơn tru 8
- Cố gắng giữ ổn định: về tổ chức, sản lượng… 9
- Chuẩn hóa mọi thao tác và buộc mọi người tuân theo một cách nghiêm ngặt 9
- Không cho phép sự sai sót 9
2. Các bước trong mô hình truyền thống 9
3. Một số mô hình phát triển phần mềm truyền thống (phát triển theo kế hoạch) 10
a. Mô hình thác nước (waterfall model) 10

Hình 1: Mô hình thác nước 11
b. Mô hình làm bản mẫu (Prototyping model) 12
Hình 2: Mô hình làm bản mẫu 13
c. Mô hình xoắn ốc (The spiral model) 13
Hình 4:Mô hình đài phun nước 16
PHẦN II. TÌM HIỂU QUY TRÌNH AGILE 16
I. Sự ra đời của mô hình agile 16
1. Sự cần thiết của một mô hình phát triển phần mềm mới 16
2. Agile là gì? 17
II. Tìm hiểu chung về agile 17
1. Tuyên ngôn agile 17
Tuyên ngôn Agile được viết như sau: “Chúng tôi tìm kiếm những phương pháp tốt hơn để
phát triển và giúp người khác phát triển phần mềm. Qua hoạt động đó, chúng tôi sẽ trân
trọng: cá nhân và sự tương tác hơn là quy trình và công cụ; phần mềm hoạt động được hơn
là việc thu thập tư liệu phát triển; hợp tác với khách hàng hơn là thương thuyết về hợp
đồng; phản ứng theo sự thay đổi hơn là theo sát kế hoạch. Nghĩa là, mặc dù có những giá trị
cố hữu ở ‘cánh hữu’ (truyền thống), nhưng chúng tôi trân trọng các giá trị ‘cánh tả’ (của đổi
mới) nhiều hơn” 17
- Cá nhân và tương tác hơn là quy trình và công cụ: Câu đầu tiên này cho ta thấy không
phải lúc nào cũng có giải pháp cho mọi thứ, mà giải pháp chính là nằm bên trong của công
Bài tập lớn công nghệ phần mềm
1
Trường đại học điện lực Khoa CNTT
việc. Và đề tìm được giải pháp, thì không chỉ dựa vào các lý thuyết mà phải trực tiếp làm
công việc phát triển phần mềm. Tất nhiên quy trình và công cụ cũng là điều quan trọng. Sẽ
không thể có một phần mềm tốt nếu như quy trình và công cụ không tốt. Nhưng điều mà
bản tuyên ngôn nhấn mạnh là vai trò của từng cá nhân và mối quan hệ giữa các cá nhân
trong đội ngũ phát triển phần mềm. Ý nghĩa quan trọng nhất của Agile là mọi người cùng
làm việc trong nhóm, chia sẻ thông tin thoải mái với nhau hơn là tập trung theo sát một quy
trình hay công cụ nào đó 18

- Phần mềm hoạt động được hơn là việc thu thập tư liệu để phát triển: Điều này không có
nghĩa là chúng ta không phải thu thập lại tư liệu để phát triển, chỉ là ít nhấn mạnh thu thập
tư liệu và tập trung nhiều hơn cho việc hoàn tất công việc. Bởi vì đối với một dự án muốn
thành công thì phải thu thập tài liệu đầy đủ. Nhưng bản thân tài liệu cũng không thể giúp
được gì nếu không có một sản phẩm phần mềm thực sự. Vì thế, việc tạo ra sản phẩm phần
mềm quan trọng hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một
cách chính xác 18
- Hợp tác với khách hàng hơn là thương thuyết hợp đồng: Việc ký kết hợp đồng là quan
trọng nhưng không đủ. Một môi trường hợp tác tốt sẽ giúp cho những người phát triển đưa
ra giải pháp tốt nhất cho khách hàng. Các hợp đồng định nghĩa những điều khoản ràng buộc
mà trong đó cả hai bên đối tác phải tuân theo, những người phát triển cần hợp tác với khách
hàng để có thể hiểu rõ yêu cầu cũng như những gì cần phải đưa ra. Agile tập trung vào việc
khuyến khích khách hàng cùng tham gia vào dự án hơn là chỉ viết hợp đồng để rồi khách
hàng sẽ chẳng làm gì với nhóm dự án phần mềm 18
- Phản ứng theo thay đổi hơn là theo sát kế hoạch: Việc lập kế hoạch cho phát triển phần
mềm là không thể thiếu. Kế hoạch giúp công việc định hướng tốt hơn. Tuy nhiên thực tế có
rất nhiều thay đổi, và cứ nhất nhất tuân theo kế hoạch sẽ dễ dẫn đến thất bại. Do đó cần đáp
ứng với thay đổi để có sự điều chỉnh sao cho phù hợp. Chính vì vậy, nhóm phát triển luôn
sẵn lòng đón nhận thay đổi hơn là chỉ làm theo kế hoạch dự án (có trước) vì thay đổi luôn
diễn ra và cả kế hoạch dự án cũng sẽ thay đổi khi yêu cầu thay đổi 19
2.Nguyên tắc agile: 19
3. Đặc điểm của mô hình agile: 21
III. Quy trình thực hiện 22
Hình 5: Mô hình Agile tổng quát 22
1. Lập kế hoạch 22
2. Phân tích 23
3. Thiết kế và lập trình 23
4. Test 23
5 . Bàn giao sản phẩm 24
IV. Những vấn đề cần xem xét để quyết định chọn phát triển theo hướng agile 24

1. Cần trả lời những câu hỏi sau 24
2. Điều kiện áp dụng quy trình agile 24
VI. Ưu nhược điểm của phương pháp: 26
1. Ưu điểm: 26
- Agile là sự lựa chọn rất tốt cho các dự án nhỏ bởi dự án nhỏ thường có những yêu cầu
không được xác định rõ ràng và có thể thay đổi thường xuyên. Với phương pháp này bạn
phải chia yêu cầu ra thành những nhiệm vụ nhỏ mà có thể dễ dàng quản lý 26
- Với agile khách hàng có thể được xem trước dự án trong quá trình phát triển vì Agile phát
triển phần mềm theo hướng tăng dần và có thể đưa cho khách hàng xem từng nhiệm vụ đã
thực hiện .Bằng việc đó sẽ không bị chậm và khách hàng sẽ có sản phẩm sơ lược thay vì
đợi đến khi dự án hoàn thành. Chính vì vậy, nếu qua mỗi giai đoạn, mỗi nhiệm vụ của phát
triển dự án mà có sai sót hay yêu cầu thay đổi từ khách hàng chúng ta có thể dễ dàng sửa
đổi 26
Bài tập lớn công nghệ phần mềm
2
Trường đại học điện lực Khoa CNTT
- Agile chia dự án ra thành những thành phần nhỏ và giao cho mỗi người. Hàng ngày mọi
người đều phải ngồi họp với nhau trong một thời gian ngắn để thảo luận tiến độ và các vấn
đề nảy sinh lên mọi vấn đề đều có thể được giải quyết nhanh chóng 26
- Tỷ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác. 27
Hình 6: So sánh agile với các phương pháp khác 27
Và tỷ lệ thành công của agile thì gấp 3 lần so với Waterfall: Theo báo cáo “CHAO
Manifesto” năm 2011 của Standish Group, các dự án agile có tỷ lệ thành công gấp 3 lần
so với những dự án không dùng agile 27
2. Rủi ro và giải pháp 28
V.Công cụ quản lí dự án với agile: agilebench.com 29
1. Khái niệm 29
2. Nội dung 29
VI. So sánh phát triển theo mô hình truyền thống và phát triển theo Agile 30
Hình 8: So sánh agile và các phương pháp truyền thống 31

CHƯƠNG III.CÁC PHƯƠNG PHÁP THEO AGILE 32
I.Tìm hiểu chung 32
Hình 9: Một số phương pháp agile 32
Hình 10: So sánh các phương pháp phát triển phần mềm 33
II. Các quy trình phát triển theo hướng Agile 33
1. Quy trình Scrum 33
a. Giới thiệu 33
Scrum là một phương pháp luận được viết bởi Ken Schwaber và Mike Beedle. Thuật ngữ
Scrum được đưa ra dựa trên một bài viết của Takeuchi và Nonaka (1986) mà trong đó giới
thiệu một quy trình phát triển phần mềm nhanh có khả năng thích nghi 33
Phương pháp phát triển phần mềm Scrum được biết đến như một phương pháp quản lý
nâng cao, áp dụng cho các hệ thống hiện có. Do đó, có thể áp dụng Scrum với các phương
pháp phát triển phần mềm khác 33
Ý tưởng chính của Scrum là cho rằng việc phát triển một hệ thống cần phải quản lý một
loạt các đại lượng như yêu cầu, thời gian, tài nguyên hay công nghệ dùng để phát triển, mà
những đại lượng này hoàn toàn có thể thay đổi trong quá trình phát triển. Từ đó cho thấy
quá trình phát triển dự án mang tính không ổn định, phức tạp và khó đoán trước. Do đó, cần
phải có một quy trình phát triển có tính linh hoạt cao để có thể áp ứng được những thay đổi
này, và sản phẩm đầu ra phải có tính ứng dụng cao đáp ứng nhu cầu khách hàng 33
b. Nguyên tắc 34
d. Quy trình 35
Hình 11: Quy trình Scrum 35
e. Các tác nhân tham gia: 38
Nhược điểm: 39
- Vai trò của PO rất quan trọng (Là tiếng nói của khách hàng trong việc đánh giá sản phẩm.
Người hiểu rõ cái mà khách hàng cần. Thông thường PO là khách hàng hoặc một Business
Analysis). PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết
quả chung 39
- Khi phát triển dự án theo Scrum thì dự án sẽ không có detail design. Do vậy mỗi thành
viên của dự án cũng sẽ là một người thiết kế hệ thống. Do vậy nếu phối hợp không tốt thì

có thể dẫn đến việc sản phẩm rất khó "sửa chữa" 39
e. Nhận xét 43
XP đưa ra một cách chi tiết về hướng dẫn thực hiện, được mô tả rõ ràng từ cách thực
hiện cho đến những lợi ích thu được từ các hoạt động này. Việc thực hiện theo hướng
dẫn này có thể giải quyết được khá nhiều những vấn đề thường gặp phải trong các dự án
hiện nay và tăng thêm khả năng thành công của dự án 43
3. Phương pháp phát triển phần mềm thích nghi ASD 43
Bài tập lớn công nghệ phần mềm
3
Trường đại học điện lực Khoa CNTT
Hình14: Quy trình ASD 44
III. Đánh giá và so sánh các phương pháp 47
1.Đặc điểm chính 47
2. Khả năng và phạm vi áp dụng 48
KẾT THÚC 49
TÀI LIỆU THAM KHẢO 49
Bài tập lớn công nghệ phần mềm
4
Trường đại học điện lực Khoa CNTT
LỜI MỞ ĐẦU
Đi cùng với xu thế phát triển mạnh mẽ của các ngành công nghệ khác
trên thế giới, công nghệ phần mềm cũng đang mở ra một cánh cửa cho các tiếp
cận tiến bộ. Khá nhiều công ty, tổ chức đã nhận thức được tầm quan trọng của
ngành công nghệ này và đã có những bước tiếp cận đáng ghi nhận. Tuy nhiên,
song song với những bước phát triển như vậy, nhiều mặt hạn chế
về chất lượng phần mềm vẫn đã và đang là mối quan tâm của nhiều người, nhiều
tổ chức.
Là sinh viên của khoa công nghệ thông tin, chúng em sớm đã được tiếp
cận với môn công nghệ phần mềm và tìm hiểu khá nhiều qui trình hỗ trợ và
nâng cao chất lượng phần mềm. Chúng em đã nhận thức được tầm quan trọng

của các quy trình phát triển phần mềm. Mỗi qui trình có những mặt vượt trội
riêng và nhìn chung mục đích chính của chúng cũng để nâng cao chất lượng sản
phẩm và hạn chế rủi ro cho phần mềm làm ra. Tuy nhiên, trong những qui trình
ấy chúng em nhận thấy phát triển phần mềm theo Agile là khá tiềm năng. Chính
vì vậy, chúng em đã chọn đề tài báo cáo là “Tìm hiểu về quy trình phát triển
phần mềm theo Agile”.
Nhóm sinh viên thực hiện:
Đỗ Thị Thanh Tuyền
Nguyễn Quang Hoàng
Đoàn Thị Kim Dung
Trần Văn Thành
Hà Thị Thu Hương
Dương Văn Hà
Bài tập lớn công nghệ phần mềm
5
Trường đại học điện lực Khoa CNTT
BẢNG PHÂN CÔNG CÔNG VIỆC
Tên nhóm Thành viên Nội dung công việc
Nhóm 1 Đỗ Thị Thanh Tuyền
Nguyễn Quang Hoàng
Phần I: Tổng quan về công nghệ phần
mềm và quy trình phát triển phần
mềm.
Cụ thể: Tìm hiểu chung về công nghệ
phần mềm, quy trình phát triển phần
mềm. Tìm hiểu và rút ra nhận xét ưu
điểm, nhược điểm của các mô hình
phát triển phần mềm truyền thống
(phát triển theo kế hoạch).
Nhóm 2 Đoàn Thị Kim Dung

Trần Văn Thành
Phần II: Quy trình phát triển phần
mềm theo Agile.
Cụ thể: Tìm hiểu chung về agile, sự
ra đời, nguyên lý làm việc, đặc điểm
và các bước phát triển phần mềm theo
agile. Rút ra ưu nhược điểm của agile
và so sánh agile với các phương pháp
khác đặc biệt là các phương pháp
trước nó
Nhóm 3 Hà Thị Thu Hương
Dương Văn Hà
Phần III: Các quy trình phát triển
phần mềm theo hướng Agile
Cụ thể:Tìm hiểu 3 quy trình phát triển
phần mềm được áp dụng theo nguyên
lý của agile là Scrum, ASD và XP.
Lưu ý: Các nhóm phải tìm hiểu tất cả các phần nhưng chú trọng nhiều hơn vào
các phần đã được giao.
Bài tập lớn công nghệ phần mềm
6
Trường đại học điện lực Khoa CNTT
PHẦN I. TỔNG QUAN VỀ CÔNG NGHỆ PHẦN
MỀM VÀ QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
I. Tìm hiểu chung về công nghệ phần mềm.
1. Công nghệ phần mềm là gì ?
- Phần mềm máy tính là gì? Phần mềm máy tính (Computer software) là
các sản phẩm do nhà phát triển phần mềm thiết kế và xây dựng nhằm phục vụ
một mục đích nào đó.
- Công nghệ phần mềm là gì? Công nghệ phần mềm (Software

Engineering) là các hoạt động bao gồm: phát triển, đưa vào hoạt động, bảo trì,
và loại bỏ phần mềm một cách có hệ thống.
- Mục tiêu của công nghệ phần mềm là tạo ra những phần mềm tốt nhất
với thời gian ngắn nhất, giảm đến tối thiểu những rủi ro có thể gây ra cho các
khách hàng.
- Ngành học công nghệ phần mềm bao trùm kiến thức, các công cụ, và
các phương pháp cho việc định nghĩa yêu cầu phần mềm, cũng như việc thực
hiện các tác vụ thiết kế, xây dựng, kiểm thử (software testing), và bảo trì phần
mềm.

Ngoài ra, công nghệ phần mềm còn sử dụng kiến thức của các lĩnh vực
như kỹ thuật máy tính, khoa học máy tính, quản lý, toán học, quản lý dự án,
quản lý chất lượng, công thái học phần mềm (software ergonomics), và kỹ nghệ
hệ thống (systems engineering).
2. Lịch sử phát triển của công nghệ phần mềm.
- Thập niên 1940: Chương trình máy tính được viết bằng tay.
- Thập niên 1950: Các công cụ đầu tiên xuất hiện như phần mềm biên
dịch Macro Assembler và phần mềm thông dịch đã được tạo ra. Các trình dịch
được tối ưu hóa lần đầu tiên ra đời.
- Thập niên 1960: Các công cụ thế hệ thứ hai như trình dịch tối ưu hóa và
kiểm tra mẫu được thực hiện. Khái niệm công nghệ phần mềm được bàn thảo
rộng rãi.
Bài tập lớn công nghệ phần mềm
7
Trường đại học điện lực Khoa CNTT
- Thập niên 1970: Các công cụ phần mềm như UNIX các vùng chứa mã,
các lệnh make… được kết hợp với nhau.
- Thập niên 1980: Các máy PC và máy trạm ra đời. Cùng lúc đó có mô
hình dự toán khả năng. Lượng phần mềm tiêu thụ mạnh.
- Thập niên 1990: Phương pháp lập trình hướng đối tượng ra đời. Các quá

trình nhanh như lập trình cực hạn được chấp nhận rộng rãi. Chính vì vậy, máy
tính và internet phát triển rộng rãi.
- Hiện nay: Các phần mềm biên dịch như là .net, PHP, Java làm cho việc
phát triển phần mềm dễ dàng hơn. Quy trình phát triển phần mềm hỗ trợ cũng đa
dạng.
II. Quy trình phát triển phần mềm truyền thống.
1. Đặc điểm.
- Các phương pháp truyền thống là các phương pháp thiên về kế hoạch,
quá trình phát triển phần mềm phải tuân theo một quy trình nghiêm ngặt. Trong
quá trình phát triển phần mềm, rất nhiều tài liệu được tạo ra, được xét duyệt và
đó là một yếu tố quan trọng trong quản lí rủi ro.
- Với các phương pháp này, toàn bộ quá trình phát triển thường được lên
kế hoạch chi tiết và các tài liệu trước cũng như trong quá trình phát triển được
chuẩn bị đầy đủ. Quá trình phát triển được thực hiện theo quy trình được định
trước, và việc tuân thủ quy trình sẽ làm tăng chất lượng phần mềm và giảm rủi
ro.
- Theo các phương pháp này thì quá trình sản xuất phần mềm giống như
sản xuất các mặt hàng công nghiệp khác. Những người phát triển thực hiện công
việc một cách nghiêm ngặt theo các chuẩn và quy trình, không yêu cầu sáng tạo
nhiều. Những người quản lí chỉ cần tăng năng lực sản xuất và đạt được các mục
tiêu như:
- Giảm thiểu lỗi và công việc diễn ra trơn tru.
Bài tập lớn công nghệ phần mềm
8
Trường đại học điện lực Khoa CNTT
- Cố gắng giữ ổn định: về tổ chức, sản lượng…
- Chuẩn hóa mọi thao tác và buộc mọi người tuân theo một cách nghiêm
ngặt.
- Không cho phép sự sai sót.
2. Các bước trong mô hình truyền thống

• Xác định yêu cầu:
Đây là bước đầu tiên của quy trình phát triển phần mềm. Nó gồm 2 khía
cạnh:
- Mô hình hóa nghiệp vụ: Liên quan đến việc hiểu các nghiệp vụ chung của
phần mềm trong văn cảnh cụ thể của nó.
- Mô hình hóa yêu cầu hệ thống: Xác định được yêu cầu thực sự của khách
hàng, xem khách hàng cần gì để biết được ta sẽ phải làm gì, không cần làm gì và
xác định càng chi tiết càng rõ ràng càng tốt.
• Phân tích yêu cầu:
Phân tích có nghĩa là phải xem xét xem ta đang phải đối mặt với vấn đề gì?
Trước khi đi vào thiết kế ta phải phân tích vấn đề một cách rõ ràng. Từ đó mới
biết ta thực sự hiểu về sản phẩm mà khách hàng yêu cầu hay chưa? Điều này
liên quan đến khách hàng, người dùng cuối.
• Thiết kế:
Trong pha thiết kế chúng ta hành động để giải quyết vấn đề hay nói cách
khác chúng ta đưa ra những quyết định dựa trên kinh nghiệm, ước lượng hay
trực giác. Ta thiết kế và xem nó sẽ được triển khai như thế nào. Thiết kế hệ
thống thường phân ra thành 1 hệ thống con logic (tiến trình) và hệ thống con vật
lý (máy tính, mạng) quyết định cách thức máy móc làm việc với nhau từ đó lựa
chọn công nghệ.
• Đặc tả:
Pha đặc tả thường bị bỏ qua. Thuật ngữ đặc tả được dùng theo nhiều cách
khác nhau. Ví dụ như đầu ra của pha yêu cầu là một đặc tả về hệ thống ta cần
Bài tập lớn công nghệ phần mềm
9
Trường đại học điện lực Khoa CNTT
làm, thuật ngữ đặc tả dùng để mô tả hành vi mong đợi của một thành phần trong
chương trình. Đặc tả có thể dùng trong trường hợp sau:
- Là cơ sở để kiểm tra thiết kế phần mềm trong thực thi hệ thống.
- Văn bản là các thành phần phần mềm có thể cài đặt bởi bên thứ ba.

- Để mô tả cách thức code hay sử dụng lại code trong các ứng dụng khác.
• Cài đặt:
Giai đoạn này chúng ta sẽ viết các đoạn code nhỏ cho các chương trình con.
Công việc chính là viết phần thân các phương thức trong lớp thiết kế.
• Kiểm thử:
Sau khi phần mềm đã hoàn thành thì cần kiểm tra lại xem nó có đáp ứng nhu
cầu khách hàng hay chưa. Cách tốt nhất mà người ta hay làm là thực hiện các
test nhỏ trong suốt quá trình phát triển phần mềm hệ thống để đảm bảo chất
lượng.
• Triển khai:
Giai đoạn này quan tâm đến phần cứng và phần mềm tại nơi người dùng
cuối.
• Bảo trì:
Sau khi hệ thống được triển khai có thể có nhiều lỗi hệ thống hay cũng có thể
khách hàng yêu cầu sửa đổi nâng cấp…Vì, vậy cần có quá trình bảo trì hệ thống.
3. Một số mô hình phát triển phần mềm truyền thống (phát triển theo kế
hoạch)
a. Mô hình thác nước (waterfall model)
• Ý tưởng:
Mô hình thác nước hay còn gọi là mô hình tuyến tính hay mô hình kinh điển
(classic model). Trong mô hình này, quy trình phát triển trông giống như một
dòng chảy, với các giai đoạn được thực hiện theo trật tự nghiêm ngặt và không
có sự quay lui hay nhảy vượt giai đoạn. Cụ thể, quá trình sẽ được thực hiện tuần
tự qua các giai đoạn: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử,
liên kết và bảo trì. Tức là mô hình này sẽ xem quá trình xây dựng một sản phẩm
Bài tập lớn công nghệ phần mềm
10
Trường đại học điện lực Khoa CNTT
phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì
chuyển đến giai đoạn sau. Sau khi phân tích yêu cầu thì đặc tả yêu cầu, đưa cho

khách hàng xem xét. Nếu khách hàng chấp nhận thì sẽ tiến hành tuần tự một loạt
các giai đoạn như trên. Chỉ đưa sản phẩm cho khách hàng khi đã hoàn thiện.
• Mô tả mô hình:

Hình 1: Mô hình thác nước
• Ưu điểm:
- Tài liệu đầy đủ lên dễ bảo trì
- Dễ phân công công việc, phân bố chi phí, giám sát công việc.
- Kiến trúc hàng đợi ổn định.
• Nhược điểm:
- Đôi khi tài liệu đặc tả mang tính chất kĩ thuật lên làm khách hàng khó mà
hiểu hết được và do đó dễ dẫn đến hiểu sai yêu cầu khách hàng.
- Mối quan hệ giữa các giai đoạn không được thể hiện.
- Hệ thống phải được kết thúc ở từng giai đoạn do vậy khó mà thực hiện theo
thay đổi của khách hàng yêu cầu.
Bài tập lớn công nghệ phần mềm
11
Phân tích
yêu cầu
Thiết kế
Cài đặt và
thử nghiệm
đơn thể
Thử nghiệm
tổng thể
Bảo trì và
phát triển
Trường đại học điện lực Khoa CNTT
- Chỉ tiếp xúc với khách hàng ở pha đầu tiên nên phần mềm không đáp ứng
nhu cầu khách hàng. Hơn nữa làm tuần tự đến giai đoạn cuối hoàn thiện mới bàn

giao sản phẩm cho khách hàng thì dễ tạo ra sản phẩm không phải cái khách hàng
cần.
- Chi phí phát triển dự án lớn mà khả năng rủi ro cao.
b. Mô hình làm bản mẫu (Prototyping model)
• Ý tưởng:
Dựa vào những yêu cầu của khách hàng người phát triển phần mềm sẽ
xây dựng một mẫu thử ban đầu đưa cho người sử dụng xem xét, sau đó tinh
chỉnh qua nhiều mẫu thử cho đến khi thỏa mãn yêu cầu người sử dụng thì dừng
lại.
Có 2 phương pháp với mô hình này:
- Phát triển thăm dò: Thực hiện với những yêu cầu rõ ràng và sau đó bổ
sung thêm những yêu cầu mới của khách hàng và dừng khi tất cả các yêu cầu
của khách hàng được thỏa mãn.
- Loại bỏ mẫu thử: Thường sử dụng trong trường hợp yêu cầu không rõ
ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao cho khách
hàng. Từ đó ta sẽ biết được yêu cầu nào là cần thiết với người dùng. Như vậy
phương pháp này sẽ giúp sáng tỏ yêu cầu người dùng.
• Mô hình:

Bài tập lớn công nghệ phần mềm
12
Phác
thảo nét
chính
Xây dựng
phần mềm
Sử dụng
phần mềm
Hệ thống
thích hợp

Chuyển
giao
phần
mềm
Đ
S
Trường đại học điện lực Khoa CNTT
Hình 2: Mô hình làm bản mẫu
• Ưu điểm:
Thu được nhiều phiên bản hệ thống lên luôn đáp ứng nhu cầu khách hàng.
• Nhược điểm:
- Thiếu tầm nhìn của cả quy trình
- Hệ thống thường có cấu trúc nghèo nàn.
- Yêu cầu các kĩ năng đặc biệt (ví dụ: ngôn ngữ để tạo mẫu thử nhanh
chóng).
- Chỉ nên áp dụng với hệ thống nhỏ hoặc vừa.
c. Mô hình xoắn ốc (The spiral model)
• Ý tưởng:
Nó có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và
đồng thời thêm một thành phần mới – phân tích rủi ro.
Đầu tiên, nhóm phát triển sẽ thu thập nhu cầu khách hàng (những yêu cầu này có
thể đầy đủ hoặc còn mơ hồ). Sau đó, thực hiện một số phân tích để tăng hiểu
biết về vấn đề được đặt ra ở pha xác định yêu cầu.Tiếp theo, phác thảo ra một hệ
thống phù hợp nhất với yêu cầu ban đầu. Mặc dù những bước trước là chưa
hoàn chỉnh nhưng vẫn tiến hành viết code. Khi đã hoàn thành code ban đầu ta
đưa cho khách hàng xem xét.
Bằng cách đó thông qua mỗi chu trình chúng ta sẽ tăng thêm sự hiểu biết
về vấn đề nào đó và về các giải pháp đã được đề xuất. Qua nhiều lần xoắn ốc,
chúng ta có thể mổ xẻ yêu cầu và phân tích thiết kế một cách chính xác hơn để
đáp ứng với các yêu cầu nhiều hơn.

Sau khi hệ thống hoàn thành, có lẽ qua 3 hoặc 4 lần xoắn ốc chúng ta có
thể thực hiện kiểm tra hệ thống một cách nghiêm ngặt.
Bài tập lớn công nghệ phần mềm
13
Trường đại học điện lực Khoa CNTT
• Mô hình
Hình 3: Mô hình xoắn ốc
• Ưu điểm:
- Phân tích rủi ro làm tăng độ tin cậy dự án.
- Cho phép thay đổi yêu cầu cho mỗi vòng xoắn.
- Một rủi ro nào đó chưa được giải quyết, dự án sẽ chấm dứt.
- Kiểm soát rủi ro ở từng giai đoạn phát triển
- Đánh giá chi phí chính xác hơn các phương pháp khác
• Nhược điểm:
- Phức tạp và không thích hợp với các dự án nhỏ, ít rủi ro.
- Cần có kĩ năng tốt về phân tích rủi ro.
Bài tập lớn công nghệ phần mềm
14
Kế hoạch Phân tích rủi ro
Khách hàng đánh giá Xây dựng sản phẩm
Lập kế hoạch và thu
tập yêu cầu ban đầu
Kế hoạch dựa
trên
các đánh giá
của
khách hàng
Đánh giá
sản phẩm
Hướng hoàn

thiện của hệ
thống
Bản mẫu đầu tiên
Các bản mẫu tiếp theo
Tiếp tục phát
triển hệ thống?
Phân tích rủi ro trên
cơ sở các yêu cầu ban
đầu
Phân tích rủi ro trên
cơ sở các phản ứng
của khách hàng
Trường đại học điện lực Khoa CNTT
- Yêu cầu thay đổi thường xuyên dẫn đến lặp vô hạn.
- Đòi hỏi năng lực quản lí.
d. Mô hình đài phun nước (mô hình hướng đối tượng).
• Ý tưởng:
Đây là mô hình của cách tiếp cận hướng đối tượng, hệ thống được xem
như là một hệ thống các thực thể tác động qua lại để đạt được một mục đích nào
đó. Mô hình này tương ứng với mô hình thác nước trong cách tiếp cận hướng
thủ tục ở trên. Ở đây, ta thấy trong có những phần lặp và giao nhau giữa các
bước phân tích, thiết kế và cài đặt.
• Ưu điểm
Hỗ trợ việc lặp lại bên trong các giai đoạn song song, song song hóa giai đoạn.
• Nhược điểm:
hiếu kỉ luật thực hiện công việc lung tung bừa bãi.
• Mô hình
•
Bài tập lớn công nghệ phần mềm
15

Các đối tượng trong
không gian lời giải
Các đối tượng trong
chương trình
Bảo
trì
Ứng
dụng
Phát triển
trong tương
lai
LTHĐ
T
TKHĐ
T
PTHĐT
Lập trình hướng đối
tượng
Thiết kế hướng đối
tượng
Phân tích hướng đối
tượng
Các đối tượng
trong không gian
bài toán
Trường đại học điện lực Khoa CNTT
Hình 4:Mô hình đài phun nước
PHẦN II. TÌM HIỂU QUY TRÌNH AGILE
I. Sự ra đời của mô hình agile
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, các phần mềm mà con người ra càng phức tạp. Các thuật toán
ngày càng phức tạp khó xây dựng và quản lí. 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, số
lượng nhiều hơn 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ố quy trình:
- Mô hình thác nước.
- Mô hình xoắn ốc.
- Mô hình hướng đối tượng.
- Mô hình làm bản mẫu.
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 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”.
Bởi vì một phần mềm tốt là phần mềm mà đem lại cho khách hàng sự hài lòng.
Tuy vậy những phương pháp truyền thống đang hạn chế sự thay đổi yêu cầu từ
khách hàng. Điều này giúp duy trì kế hoạch 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.
Bài tập lớn công nghệ phần mềm
16
Trường đại học điện lực Khoa CNTT
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 ấy.
2. Agile là gì?

- Phương pháp phát triển phần mềm Agile (Agile development Method) ra
đời từ đầu những năm 90, với ý tưởng khắc phục những nhược điểm của mô
hình truyền thống cụ thể là mô hình thác nước. Agile là tên gọi chung để chỉ các
phương pháp phát triển nhanh. “Agile” có nghĩa là nhanh nhẹn, khéo léo trong
hành động
-Agile software development (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 chung 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 gồm có lấy yêu cầu, làm phân tích thiết kế, code, test, 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 lê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.
II. Tìm hiểu chung về agile
1. Tuyên ngôn agile
Tuyên ngôn Agile được viết như sau: “Chúng tôi tìm kiếm những phương
pháp tốt hơn để phát triển và giúp người khác phát triển phần mềm. Qua hoạt
động đó, chúng tôi sẽ trân trọng: cá nhân và sự tương tác hơn là quy trình và
Bài tập lớn công nghệ phần mềm
17
Trường đại học điện lực Khoa CNTT
công cụ; phần mềm hoạt động được hơn là việc thu thập tư liệu phát triển; hợp
tác với khách hàng hơn là thương thuyết về hợp đồng; phản ứng theo sự thay đổi
hơn là theo sát kế hoạch. Nghĩa là, mặc dù có những giá trị cố hữu ở ‘cánh hữu’

(truyền thống), nhưng chúng tôi trân trọng các giá trị ‘cánh tả’ (của đổi mới)
nhiều hơn”.
- Cá nhân và tương tác hơn là quy trình và công cụ: Câu đầu tiên này cho
ta thấy không phải lúc nào cũng có giải pháp cho mọi thứ, mà giải pháp chính là
nằm bên trong của công việc. Và đề tìm được giải pháp, thì không chỉ dựa vào
các lý thuyết mà phải trực tiếp làm công việc phát triển phần mềm. Tất nhiên
quy trình và công cụ cũng là điều quan trọng. Sẽ không thể có một phần mềm tốt
nếu như quy trình và công cụ không tốt. Nhưng điều mà bản tuyên ngôn nhấn
mạnh là vai trò của từng cá nhân và mối quan hệ giữa các cá nhân trong đội ngũ
phát triển phần mềm. Ý nghĩa quan trọng nhất của Agile là mọi người cùng làm
việc trong nhóm, chia sẻ thông tin thoải mái với nhau hơn là tập trung theo sát
một quy trình hay công cụ nào đó.
- Phần mềm hoạt động được hơn là việc thu thập tư liệu để phát triển:
Điều này không có nghĩa là chúng ta không phải thu thập lại tư liệu để phát
triển, chỉ là ít nhấn mạnh thu thập tư liệu và tập trung nhiều hơn cho việc hoàn
tất công việc. Bởi vì đối với một dự án muốn thành công thì phải thu thập tài
liệu đầy đủ. Nhưng bản thân tài liệu cũng không thể giúp được gì nếu không có
một sản phẩm phần mềm thực sự. Vì thế, việc tạo ra sản phẩm phần mềm quan
trọng hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một
cách chính xác.
- Hợp tác với khách hàng hơn là thương thuyết hợp đồng: Việc ký kết hợp
đồng là quan trọng nhưng không đủ. Một môi trường hợp tác tốt sẽ giúp cho
những người phát triển đưa ra giải pháp tốt nhất cho khách hàng. Các hợp đồng
định nghĩa những điều khoản ràng buộc mà trong đó cả hai bên đối tác phải tuân
theo, những người phát triển cần hợp tác với khách hàng để có thể hiểu rõ yêu
Bài tập lớn công nghệ phần mềm
18
Trường đại học điện lực Khoa CNTT
cầu cũng như những gì cần phải đưa ra. Agile tập trung vào việc khuyến khích
khách hàng cùng tham gia vào dự án hơn là chỉ viết hợp đồng để rồi khách hàng

sẽ chẳng làm gì với nhóm dự án phần mềm.
- Phản ứng theo thay đổi hơn là theo sát kế hoạch: Việc lập kế hoạch cho
phát triển phần mềm là không thể thiếu. Kế hoạch giúp công việc định hướng tốt
hơn. Tuy nhiên thực tế có rất nhiều thay đổi, và cứ nhất nhất tuân theo kế hoạch
sẽ dễ dẫn đến thất bại. Do đó cần đáp ứng với thay đổi để có sự điều chỉnh sao
cho phù hợp. Chính vì vậy, nhóm phát triển luôn sẵn lòng đón nhận thay đổi hơn
là chỉ làm theo kế hoạch dự án (có trước) vì thay đổi luôn diễn ra và cả kế
hoạch dự án cũng sẽ thay đổi khi yêu cầu thay đổi.
2.Nguyên tắc agile:
Nguyên tắc Miêu tả
Khách hàng tham gia
Khách hàng nên tham gia chặt chẽ
trong suốt quá trình phát triển. Vai trò
của họ là cung cấp và quy định mức độ
ưu tiên các yêu cầu mới về hệ thống,
và đánh giá hệ thống tại các lần lặp
(iterations of the system).
Chuyển giao tăng dần
Phần mềm được phát triển một cách
tăng dần từng đợt (increment), trong đó
khách hàng chỉ ra các yêu cầu cần
được đưa vào mỗi đợt.
Con người thay vì quy trình
Kĩ năng phát triển của đội cần được ghi
nhận và khai thác. Các thành viên của
đội cần được tự do phát triển cách làm
việc của riêng mình mà không cần đến
các quy trình quy phạm định trước.
Chấp nhận thay đổi
Hiểu rằng hệ thống sẽ thay đổi nên

thiết kế hệ thống sao cho nó có thể
Bài tập lớn công nghệ phần mềm
19
Trường đại học điện lực Khoa CNTT
chấp nhận được thay đổi đó.
Gìn giữ tính giản dị dễ hiểu
Chú trọng vào tính giản dị dễ hiểu của
phần mềm đang được phát triển cũng
như của quy trình phát triển. Chủ động
nỗ lực loại bỏ sự phức tạp ra khỏi hệ
thống bất cứ khi nào có thể.
Cụ thể quy trình phát triển phần mềm theo hướng Agile có 12 nguyên tắc như
sau:
- Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao
sản phẩm sớm và liên tục.
- Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào
giai đoạn cuối.
- Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì ngắn tốt
hơn chu kì dài.
- Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng
nhau hàng ngày.
- Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng
họ.
- Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp.
- Các chức năng đã họat động là thước đo chính cho tiến độ dự án.
- Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản
lí…phải có khả năng tham gia dự án một cách liên tục.
- Liên tục cải tiến chất lượng thiết kế và mã nguồn.
- Tính đơn giản giữ vai trò cốt yếu. Làm càng ít càng tốt.
- Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc

tự chủ.
Bài tập lớn công nghệ phần mềm
20
Trường đại học điện lực Khoa CNTT
- Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải
tiến hiệu quả công việc.
3. Đặc điểm của mô hình agile:
- Phát triển dựa trên quy trình phát triển lặp (interative development). Mỗi
dự án được chia thành nhiều mảng nhỏ dễ sử dụng và thay đổi khi khách hàng
yêu cầu thay đổi. Dự án này sẽ thực hiện từng phần nhỏ này như những dự án
nhỏ cho đến khi tất cả các yêu cầu của khách hàng được đáp ứng và dự án được
bàn giao.
- Cứ mỗi khi bàn giao các phần nhỏ được hoàn thành cho khách hàng,
khách hàng có thể đưa ra các thay đổi hoặc yêu cầu mới cho dự án. Theo đó
nhóm phát triển phần mềm sẽ cập nhập và sửa lại sản phẩm cho đúng yêu cầu
khách hàng mà không cần làm lại từ đầu.
- Từng phần nhỏ của dự án sẽ được test ngay trong quá trình làm dự án
bằng các Unit test tương ứng bởi chính các lập trình viên hay các tester độc lập.
Quá trình test được thực hiện trong quá trình phát triển trước khi tích hợp phần
mềm.
- Yêu cầu về việc gặp mặt trao đổi thông tin thường xuyên, cùng bàn bạc
và thống nhất để hoàn thành dự án đúng thời hạn vì trong phương pháp Agile,
tại mỗi thời điểm thì cả nhóm phải cùng tập trung phát triển một mảng của dự
án.
- Vì các quá trình của Agile đều được thực hiện với nhân lực hoàn toàn là
các lập trình viên nhiều hơn và có kinh nghiệm trong lập trình và kiểm thử.
Bài tập lớn công nghệ phần mềm
21
Trường đại học điện lực Khoa CNTT
III. Quy trình thực hiện

Hình 5: Mô hình Agile tổng quát
1. Lập kế hoạch.
Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên.
Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các
phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và
vạch ra lịch trình phát triển cho từng phần tăng trưởng. Kế hoạch tổng thể
sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án. Mỗi phần tăng
trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp.
Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc.
Bài tập lớn công nghệ phần mềm
22
Trường đại học điện lực Khoa CNTT
2. Phân tích.
Agile không dành riêng một khoảng thời gian cố định ban đầu cho
việc phân tích yêu cầu. Trái lại, đại diện của khách hàng sẽ ngồi làm việc
chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng
thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm. Khi cần thông tin,
các lập trình viên chỉ việc đến trao đổi trực tiếp với người này. Đối với những
yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những
ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ họa, đại diện khách
hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình. Một
số dự án thuê người thiết kế giao diện riêng.
3. Thiết kế và lập trình
Trong một dự án, thiết kế của sản phẩm được cải tiến liên tục. Hoạt động
này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven
development hay TDD). TDD gắn kết chặt chẽ các công việc thiết kế,
lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong
hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế
của chương trình. Các lập trình viên tích hợp code vài giờ một lần và đảm bảo
rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho

khách hàng. Mã nguồn được coi là sở hữu tập thể. Mọi người được yêu cầu
sửa lỗi bất kể lỗi đó do ai gây ra.
4. Test.
Tất cả các thành viên trong dự án đều có trách nhiệm đảm bảo chất
lượng sản phẩm. Các lập trình viên thực hiện unit test và integration test. Đại
diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các
customer test. Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên
nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn. Tất cả các
regression test đều được thực hiện tự động (bởi code mới được tích hợp
vào hệthống một cách liên tục) và được chạy bởi các lập trình viên khi
Bài tập lớn công nghệ phần mềm
23
Trường đại học điện lực Khoa CNTT
họ tích hợp code mới vào hệ thống. Lập trình theo cặp góp phần làm tăng
chất lượng công việc.
5 . Bàn giao sản phẩm.
Phần mềm sẽ được trình chiếu hàng tuần và đưa cho khách hàng
xem xét,góp ý. Nếu không có thay đổi thì tiến hành thực hiện và cuối
cùng khi sản phẩm hoàn thành thì bàn giao cho khách hàng.
IV. Những vấn đề cần xem xét để quyết định chọn phát triển theo hướng
agile.
1. Cần trả lời những câu hỏi sau
- Hệ được phát triển thuộc loại nào?
- Hệ có khả năng bị kiểm duyệt từ bên ngoài?
- Vòng đời của hệ?
- Hệ được phát triển lớn hay nhỏ?
- Đội phát triển được tổ chức thế nào?
- Khả năng của người thiết kế và lập trình viên đến đâu?
- Có sẵn những công nghệ nào để hỗ trợ phát triển?
- Có cần phải đặc tả và thiết kế chi tiết trước khi cài đặt hay không?

- Chiến thuật bàn giao có tăng dần khả thi không?
- Có vấn đề văn hóa hay tổ chức nào có thể ảnh hưởng đến phát triển hay
không?
2. Điều kiện áp dụng quy trình agile.
Agile là một phương pháp tốt, tuy nhiên không phải trường hợp nào cũng
áp dụng được phương pháp này. Trước khi quyết định áp dụng Agile cho dự án
của mình, bạn phải trả lời được câu hỏi: đối với dự án này, điều kiện của
công ty như thế này thì liệu phương pháp Agile có giúp bạn thành công hơn
khi áp dụng các phương pháp khác hay không? Các dự án có đặc điểm sau đây
có thể phù hợp với Agile:
• Mức độ rủi ro thấp
Bài tập lớn công nghệ phần mềm
24
Trường đại học điện lực Khoa CNTT
Mức độ rủi ro của dự án có thể được hiểu là khả năng thực hiện và
mức độ thành công của dự án. Dự án nào có tính khả thi thấp, tức là
mức độ rủi ro cao thì không nên áp dụng mô hình này. Bởi vì dự án theo
agile sẽ tốn rất nhiều chi phí. Ví dụ như khách hàng thường xuyên thay đổi yêu
cầu thì bên làm dự án sẽ phải thực hiện lại cho phù hợp yêu cầu. Như vậy, nếu
như rủi ro cuối cùng dự án vẫn không thể hoàn thành thì rất tốn thời gian, công
sức và tiền bạc.
• Thành viên nhóm có kinh nghiệm
Vì Agile tập trung cho các dự án nhỏ và có thời gian hoàn tất ngắn, do đó
phương pháp này đòi hỏi có những cá nhân tài năng, những người sẵn
lòng làm mọi chuyện và có năng lực tổng quát hóa, có thể làm qua
nhiều công đoạn trong vòng đời truyền thống của sản phẩm.
Phương pháp Agile cần có các cá nhân đa năng, có động lực, biết nghiên
cứu, biết phân tích, biết sáng tạo, và có các kỹ năng giao tiếp cần thiết
để hiểu thấu các vấn đề của khách hàng. Họ cũng phải là những người làm
việc nhóm có tính kỷ luật, và là những kỹ sư phần mềm tài ba có thể cho ra đời

sản phẩm đúng hạn thời gian cho phép. Đặc biệt, họ phải có kĩ năng hoạt động
theo nhóm tốt để thường xuyên trao đổi hợp tác với các thành viên trong nhóm.
• Nhu cầu thay đổi thường xuyên
Khi thực hiện phương pháp này, các thành viên trong nhóm sẽ tiếp
xúc thường xuyên với khách hàng, trao đổi thường xuyên để cùng hoàn thiện
dự án. Nếu bên khách hàng có thay đổi yêu cầu, cả hai bên sẽ cùng ngồi với
nhau bàn bạc lại để tìm ra giải pháp tối ưu nhất. Do vậy, đối với các dự án có
tính ổn định cao, ít thay đổi thì áp dụng phương pháp này là không cần thiết.
• Kích thước nhóm nhỏ, các thành viên làm việc cùng một địa điểm
Xuất phát từ yêu cầu trao đổi thông tin thường xuyên giữa các
thành viên trong nhóm, nên phương pháp Agile đòi hỏi nhóm không cần quá
nhiều thành viên, nếu quá nhiều thành viên sẽ làm cho sự quản lý nhóm,
trao đổi giữa các thành viên trong nhóm trở nên không hiệu quả. Mặt
Bài tập lớn công nghệ phần mềm
25