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

- 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

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ủ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

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á

• 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.

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

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.

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

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ì?

(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

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

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

- 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