Phương pháp phát triển phần mềm linh hoạt potx

Phương pháp phát triển phần mềm linh hoạt
Agile Software Development


Nhóm nghiên cứu:
- Tri
ệu Minh Tiến
- Nguy
ễn Viết Tùng
- Ph
ạm Đức Khánh
(Chương trình Việt - Nhật * Đại học Bách Khoa Hà Nội)
HEDSPI HUT

Tài li
ệu tham khảo:
- Agile software development methods - Review and analysis
Pekka Abrahamsson, Outi Salo & Jussi Ronkainen, 2002
- An Introduction to Agile Methods
Steve Hayes (Khatovar Technology)
Martin Andrews (Object Consulting)
- Internet

…

I. Tổng quan:
1. S
ự cần thiết của một mô hình phát triển phần mềm mới
Chúng ta đã vi
ết phần mềm được 30 năm nhưng những gì chúng ta đã làm
đ

ược còn rất ít. Thành công của chúng ta được thúc đẩy bởi sự tưởng tượng, sáng
t
ạo của con người. Chúng ta càng viết ra nhiều phần mềm thì sự đòi hỏi, yêu cầu
c
ủa con người càng nhiều. Chính vì vậy, những nhà quản lý và phát triển phần
mềm tiếp tục tìm kiếm phương thức phát triển phần mềm tốt hơn. So với 30 năm
tr
ước chúng ta đã có 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 những công cụ hỗ trợ, sự đào
tạo tốt hơn và có những hiểu biết sâu hơn về lý thuyết phần mềm. Internet đã thay
đ
ổi cách con người giao tiếp với nhau, thúc đẩy sự trao đổi thông tin và thay đổi
m
ột cách triệt để sự kỳ vọng của con người về cách thức phần mềm làm việc.
Chúng ta c
ũng có số lượng đáng kể những phương pháp khác nhau giúp xác định
con đường phát triển phần mềm tốt nhất và đó chính là khía cạnh của việc phát
tri
ển phần mềm mà chúng ta sẽ tập trung vào trong thời gian tới.
a. Nh
ững hạn chế của mô hình phát triển phần mềm truyền thống
Đã có r
ất nhiều mô hình phát triển phần mềm được tạo ra trong những năm
qua. Có th
ể kể đến như:
- Pure waterfall
- Code-and-Fix
- Spiral
- Modifed Waterfalls

- Evolutionary Prototyping
- Staged Delivery
- Evolutionary Delivery
- Design-to-Schedule
- Design-to-Tools
- Commercial Off-the-shelf Software
Khi xây d
ựng các phương pháp truyền thống người ta đã cố gắng trang bị
cho chúng khả năng dự đoán trước. Với khả năng này ta có thể tạo ra một bản
k
ế hoạch tại thời điểm đầu của dự án và xác định được thời gian hoàn thành dự
án d
ựa theo bản kế hoạch này. Và vấn đề cố hữu trong quá trình thực hiện dự
án v
ẫn là “sự thay đổi yêu cầu của người dùng”. Thông thường khách hàng
không thay đổi yêu cầu của họ bởi vì họ biết rằng chi phí để thay đổi rất đắt.
Tuy nhiên ph
ần mềm không phải là thứ hữu hình. Khách hàng không chỉ khó
đ
ể xác định một cách chính xác cái gì là cần thiết mà cũng khó để hiểu tại sao
việc thay đổi lại khó khăn như vậy. Họ mong đợi một phần mềm phải có tính
m
ềm dẻo. Những phương pháp truyền thống đã đưa ra những thủ tục nhằm
ngăn ch
ặn sự thay đổi yêu cầu từ phía khách hàng. Điều này giúp duy trì bản
k
ế hoạch dự án đã xây dựng ban đầu nhưng lại không đảm bảo rằng kết quả
cuối cùng là những gì mà khách hàng mong muốn. Khả năng dự đoán trước có
th
ể là điều ước ao nhưng ta chỉ có thể đạt được điều đó với giá phải trả là sự

gi
ảm sút chất lượng phần mềm không thỏa mãn được đòi hỏi của khách hàng.
V
ới những hạn chế như vậy của những phương pháp phát triển phần mềm
truyền thống, 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ỏ chúng bây giờ? Phải chăng một vài
th
ứ đã thay đổi. Trong suốt thập niên 80 những thay đổi cơ bản đã xảy ra và
kết quả là hình thành nên “thế giới nhanh” – thế giới của sự toàn cầu hóa và
“th
ế giới chậm” của những ai tự tách mình ra khỏi quá trình toàn cầu hóa. Sự
phát triển phần mềm diễn ra trong thế giới nhanh và sự thay đổi diễn ra đồng
th
ời ở công nghệ, tài chính, thông tin và đi kèm với chúng là sự dỡ bỏ những
hàng rào chính tr
ị được duy trì suốt thời kỳ chiến tranh lạnh. 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.
b. S
ự nổi lên của phương pháp linh hoạt
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 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 linh hoạt
Ph
ương pháp phát triển phần mềm linh hoạt được đưa ra vào giữa những năm
90 nh
ư là một phần của sự nỗ lực chống lại những phương pháp “nặng nề” – điển
hình bởi những quy định khắt khe. Ban đầu chúng được gọi là “phương pháp nhẹ”.
Đ
ến năm 2001, 17 thành viên nổi bật của cộng đồng phát triển phần mềm linh hoạt
đã g
ặp gỡ tại Snowbird, Utah để thảo luận về cách thức tạo ra phần mềm linh hoạt
hơn, nhanh hơn và hướng con người hơn. Họ đã thông qua tên gọi chính thức
“ph
ương pháp linh hoạt”. Và cũng trong hội nghị này, Agile Manifesto – tuyên
ngôn v
ề phương pháp linh hoạt được đưa ra và được công nhận rộng rãi như là
m
ột định nghĩa chuẩn của phương pháp phát triển linh hoạt kèm theo những
nguyên tắc cơ bản. Bản tuyên ngôn hướng tới những giá trị:
- S
ự độc lập và sự tương tác dựa trên các quy trình và công cụ : sự vận động
linh ho

ạt nhấn mạnh mối quan hệ và cộng đồng các nhà phát triển phần mềm và
vai trò c
ủa con người được phản ánh trong hợp đồng, trái với những quy trình đã
được thể chế hóa và những công cụ phát triển. Trong thực tiễn nó tự thể hiện
thông qua nh
ững mối quan hệ chặt chẽ trong nhóm, việc tạo ra môi trường làm
vi
ệc gần gũi, và những thủ tục khác để nâng cao tinh thần của nhóm.
- Vận hành phần mềm dựa trên tài liệu hướng dẫn toàn diện : các mục tiêu
quan tr
ọng của nhóm phát triển phần mềm là liên tiếp đưa ra những phần mềm đã
được kiểm thử. Những phiên bản mới thường được đưa ra hàng tháng thậm chí ở
m
ột vài phương pháp là hằng giờ hoặc hàng ngày. Những nhà phát triển luôn cố
g
ắng giữ cho mã nguồn đơn giản, rõ ràng nhất có thể, bởi vậy gánh nặng về tài
li
ệu hướng dẫn được giảm bớt.
- Sự cộng tác với khách hàng dựa trên thương thảo hợp đồng : mối quan hệ
và s
ự hợp tác giữa những nhà phát triển và khách hàng được định rõ thông qua
nh
ững bản hợp đồng chặt chẽ. Những dự án càng lớn thì càng cần một bản dự
thảo hợp đồng chặt chẽ. Quá trình thương lượng nên được đánh giá như là
ph
ương tiện để đạt được và duy trì mối quan hệ. Nhìn từ quan điểm kinh doanh,
ph
ương pháp phát triển linh hoạt tập trung vào việc nhanh chóng đưa ra được
nh
ững sản phẩm có thể đáp ứng những yêu cầu cơ bản của khách hàng ngay sau

khi dự án được tiến hành; do đó làm giảm nguy cơ vỡ hợp đồng.
- Đáp
ứng với thay đổi dựa trên một kế hoạch theo sau : nhóm phát triển gồm
c
ả những nhà phát triển phần mềm và đại diện khách hàng nên được cung cấp
thông tin đầy đủ, họ có đủ thẩm quyền và đươc ủy thác để xem xét những sự điều
ch
ỉnh cần thiết trong suốt vòng đời của quy trình phát triển phần mềm. Như vậy
nh
ững người tham gia được chuẩn bị để đối mặt với những thay đổi và có thể đưa
ra đ
ược bản hợp đồng hỗ trợ và cho phép sự thay đổi.

M
ột số nguyên tắc đi kèm sau tuyên ngôn có thể kể đến như:
- Ph
ần mềm chạy ổn định được bàn giao thường xuyên (hàng tuần hoặc
hàng tháng)
- Nh
ững thay đổi yêu cầu dù muộn luôn được hoan nghênh
- S
ự hợp tác gắn bó khăng khít giữa nhà kinh doanh và những nhà phát
tri
ển phần mềm
- Đối thoại trực tiếp là hình thức giao tiếp tốt nhất
- D
ự án được tiến hành bởi những cá nhân nhiệt tình, tận tụy, đáng tin cậy
- Luôn luôn chú tr
ọng tới kỹ thuật và thiết kế
- S

ự đơn giản
- Các nhóm tự tổ chức
- S
ự thích nghi với những những thay đổi
3. So sánh v
ới các phương pháp khác
Phương pháp phát triển linh hoạt đôi khi bị đánh giá là thiểu tính kỉ luật.
Nh
ững nhận xét như vậy gây ra sự hiểu lầm. Để hiểu vấn đề một cách đúng đắn, ta
có thể hình dung rằng những phương pháp phát triển phần mềm hiện có nằm trên
m
ột trục đi từ “khả năng thích ứng” tới “khả năng dự đoán trước” thì phương pháp
phát tri
ển linh hoạt nằm về phía “khả năng thích ứng”.
Nh
ững phương pháp nằm về phía “khả năng thích ứng” có thể thích nghi
nhanh chóng với những thay đổi của thực tế. Khi mà những yêu cầu của dự án
thay đ
ổi, nhóm thực hiện cần phải có những điều chỉnh thích hợp. Họ sẽ gặp khó
khăn đ
ể mô tả chính xác những gì sẽ xảy ra trong tương lai. Tương lai càng xa thì
sự khó khăn đó càng lớn. Nhóm thực hiện có thể báo cáo chính xác công việc sẽ
đ
ược tiến hành trong tuần tới nhưng chỉ có thể báo cáo những tính năng nào sẽ
đ
ược xây dựng trong tháng tới. Và khi được hỏi về phiên bản phần mềm trong 6
tháng ti
ếp theo thì họ chỉ có thể đưa ra được những tính năng chung nhất hoặc đưa
ra kinh phí dự kiến.
Trong khi đó nh

ững phương pháp nằm về phía “khả năng dự báo trước” trong
h
ợp đồng với khách hàng, tập trung vào xây dựng một kế hoạch chi tiết cho tương
lai. Nhóm thực hiện dự án có thể báo cáo chính xác những tính năng và công việc
c
ần thực hiện trong toàn bộ quy trình phát triển phần mềm. Bản kế hoạch được tối
ưu hoá cho những mục tiêu đã đặt ra lúc đầu và sự thay đổi có thể khiến cho công
vi
ệc đã hoàn thành trở nên vô nghĩa. Nhóm phát triển dự án sẽ xây dựng một bảng
kiểm soát những thay đổi để đảm bảo rằng chỉ những thay đổi có giá trị mới được
xem xét đ
ến.
a. Phân bi
ệt với mô hình thác nước
Ph
ương pháp phát triển linh hoạt có vài điểm chung nhỏ với mô hình thác
n
ước. Hiện nay mô hình thác nước vẫn được sử dụng phổ biến. Nó được lên kế
ho
ạch trước và được tiến hành lần lượt qua các bước nắm bắt yêu cầu, phân
tích, thi
ết kế, viết code và kiểm thử một cách nghiêm ngặt. Vấn đề của mô hình
thác nước là sự phân chia cứng nhắc dự án thành các giai đoạn riêng biệt và do
đó r
ất khó khăn khi muốn thay đổi yêu cầu. Chi phí để thực hiện lại rất đắt.
Đi
ều đó có nghĩa là mô hình thác nước không thích hợp khi mà không thể xác
đ
ịnh chính xác, rõ ràng yêu cầu của khách hàng hoặc những yêu cầu có thể
thay đổi trong quá trình tiến hành dự án. Phương pháp phát triển linh hoạt,

trong h
ợp đồng, sẽ nhanh chóng đưa ra sản phẩm hoạt động ổn định với những
tính năng c
ơ bản giúp khách hàng sớm được sử dụng sản phẩm phục vụ mục
đích của họ. Sau đó nhóm phát triển tiếp tục nâng cấp sản phầm trong suốt thời
gian ti
ến hành dự án, hàng tuần hoặc tháng sẽ bổ sung những tính năng được
được phát triển và kiểm thử toàn diện.
Theo khía c
ạnh này, những người chỉ trích phương pháp linh hoạt có thể
qu
ả quyết rằng những tính năng này không được xem xét trong quy mô toàn dự
án. N
ếu người tài trợ dự án lo ngại về thời gian hoàn thành toàn bộ dự án đã
được định trước hay ngân sách đầu tư cho dự án thì phương pháp linh hoạt có
th
ể không thích hợp. Tuy nhiên lời chỉ trích này gặp phải sự phản đối của cộng
đ
ồng phát triển phần mềm linh hoạt. Họ cho rằng với SCUM (một phương
pháp phát triển linh hoạt sẽ được tìm hiểu kĩ hơn ở phần sau), nhóm phát triển
có th
ể đấy nhanh tiến độ thực hiện và liên tục cải thiện kế hoạch chiến lược.
Vài nhóm phát tri
ển phần mềm linh hoạt sử dụng mô hình thác nước với
quy mô nh
ỏ trong các giai đoạn của dự án.
b. Phân bi
ệt với “Cowboy coding”
Khi nh
ững thành viên trong nhóm làm bất cứ điều gì họ cho là đúng, không

tuân th
ủ kỷ luật, nguyên tắc thì người ta gọi đó là “Cowboy coding”. Sự
thường xuyên đánh giá lại các kế hoạch của phương pháp phát triển linh hoạt,
s
ự chú trọng vào giao tiếp mặt đối mặt trực tiếp và vấn đề tài liệu hướng dẫn đi
kèm khá ít đôi khi khi
ến cho người dùng lầm tưởng nó với “cowboy coding”.
Tuy nhiên th
ực tế là nhóm phát triển phần mềm linh hoạt luôn làm việc theo
một quy trình đã được vạch rõ ( và thường rất kỷ luật và nghiêm ngặt).
Gi
ống như tất cả các phương pháp phát triển phần mềm, kỹ năng và kinh
nghi
ệm của người sử dụng quyết định để mức độ thành công hoặc thất bại của
sản phẩm. Càng có nhiều hệ thống kiểm soát khắt khe được nhúng vào trong
quy trình phát tri
ển thì trách nhiệm của người sử dụng càng được nâng cao.



II. Các ph
ương pháp phát triển phần mềm linh hoạt
Các ph
ương pháp phát triển phần mềm linh hoạt hiện nay bao gồm: Extreme
programming (XP), Scrum, Crystal family of methodologies, Feature Driven
Development (FDD), The Rational Unified Process, Dynamic Systems
Development Menthod (DSDM), Adaptive Software Development, Open Sourse
Software Development, ngoài ra còn có các ph
ương pháp khác.
1. Lập trình cực hạn - Extreme programming (XP)

XP là m
ột phương pháp xây dựng phần mềm mới, dựa trên lý thuyết phương
pháp phát triển phần mềm linh hoạt được phát triển bởi Kent Beck, Ward
Cunningham, and Ron Jeffries, nó nh
ấn mạnh vào sự cộng tác, tạo ra phần mềm
m
ột cách nhanh chóng, và phát triển mở rộng một cách khéo léo trong quá trình
th
ực hành. Nó được cô đọng lại trong bốn giá trị: sự giao tiếp (communication),
đơn giản hóa (simplicity), sự phản hồi (feedback), và thế mạnh (courage).
N
ếu bạn làm việc trong một môi trường mà ở đó các nhu cầu được chờ để
thay đ
ổi và các khách hàng sẽ được lợi từ việc bàn giao phần mềm sớm và
thường xuyên thì chắc chắn nên xem xét XP . Các nhóm làm theo XP sẽ thường
xuyên nh
ận ra rằng họ đang bàn giao các sản phẩm phần mềm chất lượng cao
v
ới số lượng rất lớn và nhanh hơn trước đây rất nhiều.
[
XP bao gồm một tập hợp các luật giá trị và thực hành giúp người lập trình
mô t
ả chi tiết các hành vi. Vòng đời của XP gồm có các pha: Khảo sát
(Exploration), L
ập kế hoạch (Planning), Các bước lặp để phát hành (Iteration to
Release), Sản xuất (Productionizing), Bảo trì và kết thúc (Maintenance and
Death).

Theo mô tả của Beck’s (1999b) thì pha ban đầu là pha “Khám phá”. Trong
pha này khách hàng vi

ết ra các yêu cầu về sản phẩm vào các “story card”. Mỗi
“story card” sẽ mô tả một đặc trưng sẽ được thêm vào trong chương trình. Trong
khi đó nhóm phát tri
ển sẽ giới thiệu những công cụ, công nghệ, những thực thi
mà h
ọ sẽ sử dụng trong dự án đó. Công nghệ sử dụng cần được kiểm tra và kiến
trúc có th
ể được phân tích bằng cách xây dựng một nguyên mẫu. Pha này có thể
kéo dài vài tuần đến vài tháng tùy thuộc vào từng dự án và nhóm phát triển.
Ở pha thứ hai đó là pha “Lập kế hoạch” là tập hợp các thứ tự ưu tiên cho
nh
ững yêu cầu và thống nhất nội dung cho phiên bản phần mềm đầu tiên. Người
lập trình đầu tiên phải ước lượng khả năng đáp ứng các yêu cầu này và lập thời
gian bi
ểu cho việc thực hiện. Khoảng thời gian để đưa ra bản phát hành đầu tiên
th
ường không vượt quá 2 tháng.
Pha “L
ặp để phát hành” bao gồm một số bước lặp trong hệ thống để tạo ra
bản phát hành đầu tiên. Thời hạn đã đặt ra trong bước lập kế hoạch có thể bị sụp
đ
ổ nếu như thời gian để thực thi các bước lặp từ một đến bốn tuần. Bước lặp đầu
tiên t
ạo ra một hệ thống bao gồm kiến trúc của cả một hệ thống. Điều đó đạt
được bằng cách thực thi những yêu cầu có tác động mạnh mẽ đến việc xây dựng
c
ấu trúc của cả hệ thống. Khách hàng sẽ quyết định yêu cầu nào được chọn qua
m
ỗi bước lặp. Các hàm kiểm tra được tạo bởi khách hàng sẽ chạy khi mỗi bước
l

ặp kết thúc. Đến khi kết thúc bước lặp cuối cùng thì sản phẩm đã được hoàn
thành.
Pha “S
ản xuất” sẽ có các kiểm tra thêm đối với hoạt động của hệ thống trước
khi t
ạo ra một hệ thống hoàn chỉnh giao cho khách hàng. Trong pha này, những
thay đổi mới vẫn có thể được phát hiện và sự quyết đinh sẽ được đưa ra nếu
chúng n
ằm trong bản phát hành hiện tại. Trong suốt pha này, các bước lặp cần
đ
ược đẩy nhanh hơn giảm từ ba tuần xuống còn khoảng một tuần. Các ý kiến và
yêu c
ầu bổ xung sẽ được ghi nhận lại và thực hiện ở pha tiếp theo.
Trong khi phiên bản đầu tiên đang được khách hàng sử dụng thì nhóm phát
tri
ển vẫn phải đồng thời vừa giữ cho hệ thống làm việc liên tục vừa duy trì
nh
ững bước lặp mới để tạo ra các phiên bản kế tiếp. Để làm được việc này, pha
“Phân tích” đòi h
ỏi những cố gắng để chăm sóc khách hàng. Vì vậy tốc độ có thể
bị chậm lại sau khi sản phẩm đã hoàn thành. Trong pha này có thể yêu cầu kết
h
ợp một số người mới làm thay đổi cấu trúc của nhóm lập trình.
Pha “Chết” bắt đầu khi khách hàng không còn yêu cầu nào nữa để thi hành.
Lúc này khách hàng đã th
ỏa mãn với những chức năng mà phần mềm đem lại.
Đây là lúc thích hợp để viết tài liệu cần thiết về hệ thống, lúc hệ thống đã ổn
đ
ịnh, không có sự thay đổi trong kiến trúc, thiết kế hay lập trình. “Chết” cũng có
th

ể xảy ra nếu như hệ thống không đạt được kết quả mong đợi hoặc nó quá đắt
đ
ể phát triển tiếp.
Đối với người lập trình phải viết chương trình và kiểm thử một cách càng
đ
ơn giản và càng rõ ràng càng tốt. Điều đầu tiên tạo nên thành công của phương
pháp phát tri
ển phần mềm XP là sự giao tiếp và hợp tác giữa các lập trình viên
khác và các thành viên trong nhóm.
Khách hàng vi
ết ra yêu cầu và các hàm kiểm tra và quyết định khi nào các
yêu c
ầu được thỏa mãn. Khách hàng tập hợp các thực thi ưu tiên cho các yêu
c
ầu.
Kiểm định viên sẽ giúp khách hàng viết hàm kiểm tra. Họ chạy hàm kiểm tra
m
ột cách thường xuyên, thông báo rộng rãi kết quả kiểm tra và duy trì công cụ
ki
ểm tra.
Người theo dõi sẽ đưa ra các phản hồi trong XP. Họ xác định các ước lượng
đ
ược tạo bởi nhóm lập trình và đưa ra phản hồi trong việc làm thế nào nhóm lập
trình có th
ể tuần tự cải thiện các ước lượng trong tương lai một cách chính xác.
Ng
ười này cũng theo sát sự tiến triển của mỗi vòng lặp để ước lượng xem có hay
không việc đạt tới kết quả trong phạm vi nguồn lực cho phép và thời gian ràng
bu
ộc hoặc có gi thay đổi cần thiết trong quá trình xử lý.

Hu
ấn luyện viên là người chịu trách nhiệm cho toàn bộ quá trình phát triển
phần mềm. Việc hiểu rõ XP có vai trò quan trọng cho phép huấn luyện viên có
th
ể hướng dẫn cho những thành viên trong nhóm tuân theo.
Chuyên gia là nh
ững người có kiến thức chuyên biệt về vấn đề nào đó, họ có
nhi
ệm vụ hướng dẫn nhóm lập trình giải quyết các vấn đề chuyên biệt của họ.
Người quản lý là người đưa ra những quyết định. Để làm được việc đó anh ta
ph
ải giao tiếp với nhóm lập trình để quyết định những tình huống tức thời, và để
nh
ận định những khó khăn hoặc thiếu hụt trong quá trình thực hiện.
XP bao g
ồm một tập các ý tưởng và thực thi dựa trên những phương pháp
luận đã có (Beck 1999a). Chính sự quyết định đã tạo nên cấu trúc. Trong khi
khách hàng đ
ưa ra những quyết định mang tính thương mại thì những người lập
trình l
ựa chọn công nghệ, đó chính là ý tưởng của Alexander (1979). Loại hình
phát triển nhanh XP có nguồn gốc từ những ý tưởng hình thành sau Scrum
(Takeuchi and Nonaka 1986) và ngôn ng
ữ mô hình của Cunningham (1986).
Việc lập dự án sử dụng XP dựa trên những yêu cầu từ phía khách hàng được vẽ
ra t
ừ những tình huống sử dụng (Jacobsen 1994) và phương pháp phát triển phân
ph
ối sinh ra bởi Gilb (1988). Cũng như mô hình xoắn ốc, sự phản hồi ban đầu là
mô hình thác n

ước cả hai đều có ảnh hưởng lên phương pháp XP. Phép ẩn dụ
của XP khởi đầu từ nghiên cứu của Lakoff, Johnson (1998) và Coyne (1995).
Cu
ối cùng thì môi trường làm việc vật lý đã được Coplien (1998), DeMarco và
Lister (1999) tìm ra.

Mục tiêu mà XP nhắm đến là việc phát triển phần mềm thành công cho dù có
s
ự mập mờ và yêu cầu liên tục bị thay đổi trong một nhóm lập trình. Những
bước lặp ngắn với phiên bản phát hành nhỏ và tốc độ phản hồi nhanh, sự tham
gia c
ủa khách hàng, sự trao đổi và hợp tác, những bước lặp liên tục và kiểm
đ
ịnh, chung quyền sở hữu phần lập trình, những tài liệu hạn chế và phương pháp
lập trình theo cặp là những đặc trưng chính của phương pháp XP.
Th
ực thi của XP được biểu diễn theo cấu trúc của Beck (1999ª). Đó là các
b
ước Lập kế hoạch  Bản phân phối nhỏ và ngắn  Phép ẩn dụ  Thiết kế
đ
ơn  Tái tạo  Lập trình theo cặp  Quyền sở hữu tập thể  Bước lặp liên
tục  40 giờ mọt tuần  Khách hàng có mặt  Chuẩn lập trình  Không gian
làm vi
ệc mở  Quy tắc, luật lệ.
Beck cho r
ằng phương pháp XP sẽ dần dần được chấp nhận:
“Nếu bạn muốn thử XP, cho những mục đích tốt đẹp thì đừng cố nuốt tất cả
m
ột lúc. Chọn ra vấn đề tồi tệ nhất trong xử lý hiện thời của bạn và cố xử lý nó
v

ới phương pháp XP.”
Một trong những ý tưởng nền tảng của XP là không có xử lý nào phù hợp với
m
ọi dự án tuy nhiên vẫn có những hành vi có thể được cân đối lại cho phù hợp
với những yêu cầu của các dự án cá nhân riêng lẻ.
Trong th
ực tế không có một báo cáo kinh nghiệm nào về tất cả các thực thi
c
ủa XP được thực hiện. Mặc dù vậy vẫn có một bộ phận các thực thi của XP
đ
ược Beck báo cáo (Grenning 2001, Schuh 2001). XP là một phương pháp được
tài liệu hóa nhiều nhất trong lập trình linh hoạt và đang được tiếp tục nghiên cứu
và có nhi
ều bài báo và kinh nghiệm về các nhánh khác nhau trong XP.
Nh
ư phát biểu của Beck (1999b), phương pháp XP không có nghĩa là tương
thích mọi nơi, và những giới hạn của nó vẫn chưa được đồng nhất. Điều đó đòi
h
ỏi những kinh nghiệm và những nghiên cứu đã được thí nghiệm kiểm chứng về
nh
ững triển vọng khác nhau. Tuy nhiên trong số đó có vài thứ đã được đồng
nh
ất.
XP được dùng cho các nhóm phát triển nhỏ và vừa. Beck (1999b) cho rằng
m
ột nhóm nên có từ 3 đến tối đa là 20 thành viên. Môi trường vật lý cũng hết sức
quan tr
ọng trong XP. Sự trao đổi và cộng tác giữa các thành viên phải được
thường xuyên. Văn hóa kinh doanh tác động đến một đơn vị phát triển là một
v

ấn đề trọng tâm của XP. Bất kỳ một sự chống đối các thực thi hoặc nguyên tắc
c
ủa XP của bất kỳ thành viên, quản lý, khách hàng cũng có thể đủ làm thất bại
d
ự án. Tất nhiên công nghệ có thể cũng không thể vượt qua những trở ngại để
đem lại thành công cho XP.
Nh
ững nghiên cứu vẫn đang được triển khai. Có nhiều tài liệu đã được xuất
b
ản nó về nhiều diện mạo khác nhau của XP, tuy nhiên chắc chắn là nó sẽ được
nhìn nhận là một phương pháp thực tế hơn là một phương pháp hàn lâm, hầu hết
các trang tâm đi
ểm về kinh nghiệm sử dụng XP trong những phạm vi khác nhau,
và nh
ững kinh nghiệm tìm kiếm trên những thực thi của nó.
2. Scrum
Thu
ật ngữ “Scrum” được trình bày lần đầu tiên trong bài báo của Takeuchi
và Nonaka (1986) v
ề khả năng thích nghi, nhanh chóng, tính tự tổ chức trong
vi
ệc phát triển phần mềm. Thuật ngữ “Scrum” có nguồn gốc từ một chiến thuật
trong môn bóng b
ầu dục ám chỉ việc đưa bóng vào cuộc.
Scrum gần như được phát triển cho việc xử lý phát triển hệ thống. Đó gần
nh
ư dựa trên kinh nghiệm trong việc áp dụng những ý tưởng lý thuyết điều khiển
x
ử lý trong công nghiệp để phát triển hệ thống và đưa đến kết quả là việc giới
thiệu lại ý tưởng về tính mềm dẻo, tính thích nghi, và tính năng suất. Nó không

đ
ịnh nghĩa cho bất kỳ một công nghệ phát triển phần mềm nào trong pha thực
thi. Scrum tập trung vào việc làm thế nào để các thành viên trong nhóm tạo nên
đ
ược một hệ thống mềm dẻo trong một môi trường luôn luôn thay đổi.
Ý t
ưởng chính của Scrum là phát triển hệ thống bao gồm vài môi trường và
công ngh
ệ có thể thay đổi (ví dụ như: yêu cầu, thời gian, nguồn lực. công
nghệ…) phù hợp với sự thay đổi của hệ thống trong suốt quá trình xử lý. Điều
này khi
ến cho việc phát triển là không thể dự đoán trước được và rất phức tạp,
đòi h
ỏi hệ thống phải hết sức mềm dẻo để đáp ứng được những thay đổi. Và kết
quả là sản phẩm sẽ rất hữu ích khi đến tay khách hàng.
Scrum giúp đ
ẩy mạnh những kỹ thuật thực thi sẵn có trong một tổ chức, nó
bao g
ồm những hoạt động quản lý thường xuyên nhắm đến việc nhận ra bất kỳ
thi
ếu hụt nào hoặc những trở ngại trong quá trình phát triển phần mềm.
Thực thi Scrum bao gồm 3 pha là các pha: pre-game, development, post-
game.
Pha pre-game bao gồm hai pha con là : Lập kế hoạch và kiến trúc (hay thiết kế
bậc cao hơn)
Lập kế hoạch bao gồm định nghĩa về hệ thống sắp được phát triển. Một bản
li
ệt kê các công việc chưa làm được được tạo chứ đựng những yêu cầu của khách
hàng trong thời điểm hiện tại. Các yêu cầu này có thể bắt nguồn từ khách hàng,
ng

ười buôn bán, người phân phối tiếp thị, người cung cấp hay từ chính người
phát tri
ển phần mềm. Các yêu cầu được ưu tiên và các khó khăn khi thực thi phải
đ
ược ước lượng trước. Sản phẩm chưa hoàn chỉnh phải được cập nhật những cái
mới, những yếu tố cụ thể hơn, để tạo ra được những đánh giá chính xác. Việc lập
k
ế hoạch cũng bao gồm việc lập đội phát triển, chọn các công cụ và những tài
nguyên khác, đánh giá r
ủi ro, kiểm soát vấn đề, đào tạo và phê chuẩn. Ở mỗi
bước lặp các sản phẩm cập nhật cần được đội phát triển đánh giá xem dự án tiến
tri
ển được đến đâu để lập kế hoạch cho các bước lặp tiếp theo.
Pha ki
ến trúc bao gồm các kiến trúc đã được lập kế hoạch sẵn trong mỗi sản
ph
ẩm ở mỗi bước lặp. Trong trường hợp nâng cao một hệ thồng có sẵn, những
sự thay đổi cần thiết cho bước thực thi Backlog và xác định rõ những vấn đề mà
b
ạn có thể gặp phải. Một cuộc họp để nhìn lại thiết kế của một hệ thống được tổ
ch
ức để thông qua đề xuất cho việc thực thi và những quyết định sẽ được đưa ra
trong buổi họp này. Thêm vào đó, kế hoạch mở đầu cho một phiên bản phát hành
c
ũng được chuẩn bị.
3. Crystal family of methodologies
Đây là ph
ương pháp bao gồm một lượng các phương thức khác nhau cho việc
chọn lựa một phương pháp tối ưu nhất cho một dự án cụ thể. Bên cạnh những
ph

ương thức, cách tiếp cận Crystal bao gồm những nguyên tắc đan xen các
ph
ương thức phù hợp với những thay đổi liên tục của các dự án khác nhau.
Mỗi thành viên trong gia đình Crystal được đánh dấu bằng những màu sắc
khác nhau tùy thu
ộc vào “sức nặng” của nó. Sức nặng càng lớn thì màu càng
đ
ậm. Đối với những dự án lớn yêu cầu nhiều sự hợp tác và nhiều phương pháp
“m
ạnh mẽ” hơn những dự án nhỏ. Càng được phê bình nhiều thì sản phẩm làm
ra càng hoàn thiện. Lược đồ dưới đây sẽ cho biết khả năng tiềm tàng của thất bại
khi h
ệ thống bị lỗi. Trong đó Sự thoải mái (C), tiền tự do làm theo ý mình (D) ,
ti
ền cần thiết (E), vòng đời (L).


Có nh
ững quy tắc, đặc điểm và giá trị thông thường được đặt ra cho những
ph
ương thức trong gia đình Crystal. Đầu tiên dự án phải sử dụng chu kỳ phát
tri
ển phần mềm tăng dần, và đạt mức tăng lớn nhất trong vòng mỗi 4 tháng, tốt
nhất là trong vòng từ 1 đến 3 tháng. Điều cực kỳ quan trọng là sự hợp tác và giao
ti
ếp giữa các thành viên trong nhóm. Phương pháp Crystal không giới hạn số
l
ượng phương pháp thực thi, số lượng công cụ, số lượng các sản phẩm, và đặc
biệt cho phép các thực thi của các phương thức khác nhiuw Scrum hay XP
H

ơn nữa, cách tiếp cận này còn cho phép giảm bớt các sản phẩm trung gian và
th
ể hiện cụ thể trong phạm vi một quy ước cho các dự án riêng lẻ và phát triển
chúng nh
ư là các dự án mở.
Hiện nay có 3 phương thức chính trong Crystal đó là: Crystal Clear, Crystal
Orange, Crystal Orange Web.
T
ất cả các phương thức trong gia đình Crystal đều dựa trên những chuẩn hợp
đồng đã ký, sản phẩm, chi phí, công cụ, và các quy tắc chuẩn để thực thi trong
su
ốt quá trình sản xuất. Crystal Clear và Crystal Orange là hai trong số các thành
viên c
ủa gia đình Crystal đã được xây dựng và sử dụng (Cockburn 1998,
Cockburn 2002a). Crystal Orange (Cockburn 1998) c
ũng biểu diễn các hoạt
động trong một quá trình.
Crystal Clear được thiết kế cho những dự án rất nhỏ được phát triển bởi
kho
ảng 6 thành viên. Tuy nhiên với cá phần mở rộng của nó có thể phù hợp với
một dự án có từ 8-10 thành viên. Một đội sử dụng phương thức Crystal nên làm
vi
ệc cùng nhau trong một phòng để tiện việc trao đổi, bàn bạc.
Crystal Orange đ
ược thiết kế cho một dự án cỡ vừa, có từ 10 đến 40 thành
viên và v
ới thời gian thực hiện dự án là 1 đến 2 năm. Dĩ nhiên một dự án có 50
thành viên vẫn có thể sử dụng phương thức này nhưng với điều kiện phải thêm
vào cho nó ph
ương thức kiểm chứng. Một dự án sử dụng Crystal Orange có thể

đ
ược chia nhỏ cho nhiều nhóm phát triển với cross-functional sử dụng chiến
lược Holistic Deliversity. Tuy nhiên phương thức này không dành cho bản phát
tri
ển môi trường. Crystal Orange nhấn mạnh tầm quan trọng của time-to-market.
S
ự hoán đổi giữa phân phối rộng rãi và sự thay đổi nhanh trong yêu cầu và thiết
k
ế kết quả trong một số giới hạn các phiên bản cho phép giảm bớt giá thành để
bảo trì chúng nhưng vẫn giữ cho chức năng giao tiếp giữa các đội phát triển
đ
ược hiệu quả.
Policy standards:
Đây là nh
ững thực thi cần được áp dụng trong suốt quá trình phát triển phần
m
ềm. Cả Crystal Clear và Crystal Orange đều đưa ra các tiêu chuẩn chính sách
sau:
1. M
ở rộng các bản phân phối một cách đều đặn
2. Quy trình theo dõi những thành phần quan trọng được đưa vào các phiên
b
ản, chú ý vào những quyết định hơn là viết tài liệu
3. H
ướng sự chú ý của người dùng.
4. Nghiên cứu chức năng tự động hóa kiểm chứng
5. Coi nh
ư có 2 người sử dụng đang quan sát bạn làm việc
6. H
ội thảo về sản phẩm và những điều chỉnh phương thức thực thi ở đầu

vào
ở giữa mỗi bước lặp
Chỉ có sự khác biệt duy nhất trong chính sách của 2 phương thức này là.
Crystal Clear cho r
ằng nên tăng phiên bản khoảng 2 đến 3 tháng một lần, trong
khi Crystal Orange l
ại cho rằng nên mở rộng tối đa là 4 tháng.
Nh
ững chính sách này đặc trưng của phương thức Crystal, tuy nhiên
chúng có thể bị thay thế bằng những phương thức tương đương như XP và
Scrum.
Work products:
Cockburn cho rằng các sản phẩm của Crystal Clear và Crystal Orange thường
có nh
ững quy mô khác nhau. Tuy nhiên cũng có những sản phẩm tương tự nhau
như: phiên bản liên tục, mô hình đối tượng thông thường, sổ tay người dùng, các
tr
ường hợp kiểm thử, mã di trú.
Thêm vào đó Crystal Clear bao g
ồm những chú thích để mổ tả các đặc điểm,
trái l
ại ở Crystal Orange lại đòi hỏi các tài liệu đặc tả yêu cầu.
Local matters:
Đó là nh
ững thủ tục của Crystal mới được ứng dụng, tuy nhiên nó hoàn toàn
tách bi
ệt với bản thân dự án, những thủ tục này có phạm vi khác nhau giữa hai
phương thức Crystal Clear và Crystal Orange. Cả hai phương thức trên đều cho
r
ằng mẫu cho một sản phẩm tốt là mã nguồn, kiểm tra truy hồi, và sử dụng giao

di
ện chuẩn có thể cài đặt và bảo trì bởi chính đội phát triển.
Tools:
Công c
ụ mà Crystal Clear yêu cầu là công cụ biên dịch, công cụ tạo các
phiên b
ản, công cụ cấu hình và quản lý và các trang in. Công cụ tối thiểu mà
Crystal Orange yêu c
ầu là công cụ tạo các phiên bản, lập trình, kiểm thử, giao
tiếp, theo dõi dự án, đồ họa và biện pháp trình diễn.


Standards:
Crystal Orange đ
ề xuất việc lựa chọn những ký hiệu chuẩn, thiết kế thỏa
thu
ận, định dạng chuẩn và chất lượng chuẩn (Cockburn 1998) sẽ được sử dụng
trong d
ự án.
Activities:
Các hoạt động được thể hiện qua sơ đồ sau:

4. Feature Driven Development
Feature Driven Development (FDD) là ph
ương pháp tiếp cận linh hoạt dành
cho phát triển hệ thống. FDD không bao phủ toàn bộ quy trình phát triển phần
m
ềm mà nó tập trung vào giai đoạn thiết kế và xây dựng. Tuy nhiên nó được
thi
ết kế để làm việc với những hoạt động khác của một dự án phát triển phần

m
ềm và không yêu cầu bất cứ một mô hình quy trình riêng nào. Nó tập trung vào
chất lượng sản phẩm xuyên suốt quy trình.
FDD bao g
ồm 5 quy trình liên tục và cung cấp những phương thức, kỹ thuật
và nh
ững hướng dẫn mà nhà đầu tư cần đến để chuyển giao hệ thống. Phần lặp
của quy trình FDD hỗ trợ phát triển linh hoạt với sự thích nghi nhanh chóng với
nh
ững thay đổi muộn trong yêu cầu của khách hàng.


- Phát tri
ển một mô hình toàn thể (Develop an Overall Model)
Khi vi
ệc phát triển một mô hình toàn thể bắt đầu, các chuyên gia trong lĩnh
vực này họ đã nhận thức được phạm vi, khung cảnh và yêu cầu của hệ thống để
xây d
ựng. Các yêu cầu được tài liệu hóa như việc sử dụng các trường hợp hoặc
các ch
ức năng đặc biết sẽ có thể xuất hiện ở bước này. Tuy nhiên FDD không
địa chỉ rõ ràng vấn đề lấy lại và quản lý các yêu cầu. Các chuyên gia cũng được
g
ọi là “walkthrough” trong mỗi đội và là người kiến trúc sư chính có hiểu biết
cao v
ề hệ thống.
Mô hình này có th
ể được chia nhỏ ra thành các nhóm và mỗi nhóm sẽ có các
“walkthrough” phụ trách. Sau “walkthrough” các thành viên trong nhóm phát
tri

ển sẽ chia làm các nhóm nhỏ để trao đổi và thảo luận nhằm xây dựng một hệ
th
ống tốt nhất.
- Xây dựng một danh sách các tính năng (Build a Features List)
Nh
ững chuyên gia, mô hình đối tượng, và những tài liệu về những yêu cầu đã
có để tạo ra nền tảng tốt cho việc xây dựng một liệt kê các tính năng thông minh
cho h
ệ thống đang được phát triển. Trong bản liệt kê, người phát triển hệ thống
s
ẽ trình bày mỗi chức năng giá trị riêng biệt được xây dựng trong hệ thống. Chức
năng s
ẽ được trình bày trong các nhóm bao gồm các chức năng trọng yếu đã
được cài đặt. Thêm vào đó, các tính năng quan trọng này lại được chia ra cho các
đ
ặc điểm khác thiết lập. Sự biểu diễn lại này khác nhau đối với các phạm vi khác
nhau. Li
ệt kê này sẽ được kiểm tra lịa bởi người dùng hoặc các nhà đầu tư cho
một hệ thống hiệu quả và trọn vẹn.
- L
ập kế hoạch nhờ vào tính năng (Plan by Features):
Bao g
ồm việc tạo ra các kế hoạch cao cấp hơn, mỗi đặc điểm sẽ được sắp xếp
theo th
ứ tự quyền ưu tiên và phụ thuộc và được ấn định cho người đứng đầu
nhóm lập trình. Ngoài ra, các lớp được đồng nhất trong một quy trình “mô hình
phát tri
ển toàn thể” sẽ được phân công cho các lập trình viên khác.

- Thiết kế theo tính năng và xây dựng theo tính năng (Design by

Feature and Build by Feature):
-

Một nhóm nhỏ các tính năng được lựa chọn từ tập hợp các tính năng. Những
nhóm tính năng này đ
ược các đội phát triển. Quy trình thiết kế bằng tính năng
và xây dựng bằng tính năng là những thủ tục có thể được lặp lại trong suốt quá
trình nh
ững tính năng đã lựa chọn được sản xuất. Một bước lặp cần từ vài ngày
cho t
ới tối đa 2 tuần để thực hiện. Sau khi thực hiện thành công một bước lặp,
nh
ững tính năng đã hoàn thành được đưa vào trong chương trình chính trong khi
vòng lặp thiết kế và xây dựng bắt đầu với một nhóm các tính năng mới từ tập các
tính năng.

5. The Rational Unified Process
Ration Unified Process (vi
ết tắt làRUP) được phát triển bởi Philippe
Kruchten, Ivar Jacobsen và nh
ững thành viên khác tại Ration Corporation để bổ
sung cho UML (Unified Modelling Language).
RUP là m
ột phương thức tiếp cận những hệ thống hướng đối tượng, và được
s
ử dụng để nắm bắt các yêu cầu mẫu và xây dựng nền tảng hệ thống. RUP
nghiêng v
ề hướng phát triển hướng đối tượng. Nó không bác bỏ hoàn toàn
những phương thức khác, mặc dù UML đặc biệt thích hợp với phát triển OO
Vòng đ

ời của một dự án RUP được chia làm 4 giai đoạn : Khởi đầu
(Inception), D
ự thảo (Elaboration), Xây dựng (Construction) và Chuyển giao
(Transition).

Những giai đoạn lại được chia thành những vòng lặp nhỏ (interation).
Khoảng thời gian của một vòng lặp có thể từ 2 tuần tới 6 tháng.
- Giai đo
ạn Khởi đầu (Inception): Xem xét yêu cầu khách hàng và
đ
ưa ra các tiêu chí của dự án. Nhóm phát triển đưa ra những kiến trúc xây dựng
khác nhau, b
ản kế hoạch và chi phí ước tính cho toàn bộ dự án. Ngoài ra những
ước tính cho giai đoạn Dự thảo tiếp theo cũng được xây dựng.
- Giai đoạn Dự thảo (Elaboration): Đây là giai đoạn xây dựng nền
t
ảng kiến trúc phần mềm. Quy trình, cơ sở hạ tầng, và môi trường phát triển
được mô tả chi tiết. Sau giai đoạn này, hầu hết các tình huống sử dụng và tất cả
c
ả nhân tố ảnh hưởng được xác định và mô tả. Vào cuối giai đoạn, những phân
tích đ
ược thực hiện để đánh giá khả năng xuất hiện rủi ro, sự ổn định của kiến
trúc và chi phí xây d
ựng so với những gì bước đầu đã xác định.
- Giai đoạn Xây dựng (Construction): tất cả những thành phần còn lại
và tính năng c
ủa ứng dụng được phát triển, tích hợp vào sản phẩm và kiểm thử.
K
ết quả của giai đoạn xây dựng được tạo ra nhanh nhất có thể trong khi vẫn đảm
bảo chất lượng sản phẩm. Một hoặc vài phiên bản được hoàn thành trong giai

đo
ạn này trước khi chuyển sang giai đoạn Chuyển giao.
- Giai đo
ạn chuyển giao (Transition Phase): là giai đoạn khi mà sản
ph
ẩm phần mềm đủ điều kiện để đưa tới cộng đồng người dùng. Dựa trên những
phản hồi của người dùng, những phiên bản tiếp theo sẽ được vá lỗi hoặc gỡ bỏ đi
nh
ững tính năng không cần thiết. Giai đoạn chuyển giao bao gồm kiểm thử beta,
phân ph
ối thí điểm, đào tạo người dùng, duy trì hệ thống, đưa sản phẩm ra thị
trường, phân phối và thành lập đội kinh doanh.

6. Dynamic Systems Development Method (DSDM)
K
ể từ khi ra đời năm 1994, DSDM dần dần trở thành framework số 1 cho
việc phát triển ứng dụng nhanh (RAD) ở UK. DSDM là frame work miễn phí và
không b
ị ràng buộc bởi luật bản quyền dành cho sự phát triển RAD, được duy trì
b
ởi DSDM Consortium. Những nhà phát triển duy trì rằng ngoài việc phục vụ
như là một trong các phương pháp thông thường đã được chấp nhận DSDM cũng
cung c
ấp một framework kiểm soát cho RAD, được bổ sung bởi sự hướng dẫn
cách ki
ểm soát hiệu quả.
Ý t
ưởng cơ bản đằng sau DSDM là thay vì cố định số lượng chức năng trong
một sản phẩm và sau đó điểu chỉnh thời gian và chi phí để hoàn thành, nó sẽ cố
đ

ịnh thời gian và chi phí hoàn thành và sau đó điều chỉn số lượng chức năng sao
cho phù h
ợp.

DSDM bao g
ồm 5 giai đoạn: feasibility study, business study, functional
model iteration, design and build iteration và implementation. Hai giai đo
ạn đầu
đ
ược thực hiện liên tiếp nhau và hoàn thành cùng thời điểm. 3 giai đoạn cuối,
mỗi khi công việc phát triển hiện thời được hoàn thành, sẽ được lặp lại với quy
mô l
ớn hơn.
- Feasibility study là giai đoạn mà sự thích hợp của DSDM đối với dự
án đ
ược đánh giá. Thông qua kiểu dự án và nhiều yếu tố khác quyết định được
đ
ưa ra, sử dụng DSDM hay là không. Thêm vào đó, giai đoạn này còn đề cập
đ
ến tính khả thi về kĩ thuật trong suốt dự án, những rủi ro trong đó và đưa ra bản
báo cáo tính khả thi và bản phác thảo kế hoạch phát triển.

- Business study là giai đo
ạn những đặc điểm cơ bản của nhiệm vụ cần thực
hi
ện và công nghệ được phân tích. Phương pháp tiếp cận được đề nghị để tổ
ch
ức các hội thảo, nơi mà các chuyên gia của khách hàng tập trung đầy đủ để
có thể xem xét, đánh giá tất cả các mặt có liên quan của hệ thống và có thể
quy

ết định những gì được ưu tiên phát triển. Những quy trình nhiệm vụ chịu
ảnh hưởng và những lớp người dùng được mô tả trong Business Area
Definition. Việc xác định những lớp người dùng chịu ảnh hưởng đã thu hút
đ
ược khách hàng. Sự mô tả ở mức cao hơn của những quy trình được trình bày
trong Business Area Definition v
ới dạng thích hợp như mô hình thực thể liên
k
ết,…
- Functional model iteration là giai đoạn lặp và gia tăng đầu tiên. Trong mỗi
b
ước lặp, nội dung và phương pháp tiến cận được lên kế hoạch, đi qua bước
l
ặp đó và kết quả được phân tích cho các bước lặp tiếp theo. Khi cả việc phân
tích và viết mã hoàn thành, bản dùng thử được xây dựng và những kinh
nghi
ệm thu được từ chúng được sử dụng để nâng cấp mô hình phân tích. Bản
dùng thử không bị loại bỏ hoàn toàn mà dần dần đi theo hướng nâng cao chất
l
ượng, như vậy chúng có thể được đưa vào trong hệ thống cuối cùng. Mô hình
ch
ức năng đươc tạo ra như là một đầu ra, gồm mã bản dùng thử và mô hình
phân tích. Ki
ểm thử cũng là một phần cơ bản của giai đoạn này.
- Design and build iteration là giai đoạn mà hệ thống được tập trung xây dựng.
Đ
ầu ra là một hệ thống đã được kiểm thử đáp ứng tối thiểu yêu cầu khách
hàng. Thi
ết kế và tính năng bản dùng thử được đánh giá bởi người dùng và
những phát triển sau này sẽ dựa trên những đánh giá đó.

- Implementation là giai đo
ạn hệ thống được chuyển tử môi trường phát triển
sang môi tr
ường sản xuất thực tế. Công việc đào tạo, huấn luyện người dùng
đ
ược tiến hành và hệ thống được vận hành bởi họ. Nếu như khi triển khai thu
hút được số lượng lớn người dùng thì giai đoạn bổ sung cũng có thể được lặp
l
ại. Bên cạnh hệ thống, đầu ra của giai đoạn bổ sung cũng gồm tài liệu hướng
d
ẫn người dùng và bản báo cáo đánh giá dự án. Dựa trên kết quả đánh giá dự
án, kế hoạch về những phát triển sau này được xây dựng. DSDM vạch rõ bốn
kh
ả năng có thể xảy ra. Nếu hệ thống đáp ứng được toàn bộ các yêu cầu thì
vi
ệc phát triển thêm là không cần thiết. Nhưng nếu vẫn còn có những yêu cầu
h
ệ thống chưa đáp ứng được thì quy trình phát triển có thể phải tiến hành lại từ
bắt đầu tới kết thúc. Nếu như một vài chức năng bị bỏ qua thì quy trình phát
tri
ển có thể tiến hành lại từ functional model iteration. Cuối cùng, nếu một số
v
ấn đề kĩ thuật không được tập trung do eo hẹp về thời gian, chúng có thể được
hoàn thành khi tiến hành lại vòng lặp, bắt đầu từ giai đoạn thiết kế và xây
d
ựng.
7. Phát tri
ển phần mềm thích nghi
Phát tri
ển phần mềm tương thích (Adaptive Software Development-ASD)

được phát triển bởi James A.Highsmith III. Hiện nay có khá nhiều các nguyên
t
ắc của ASD khác với những tài liệu nghiên cứu của Highsmith trước kia về
ph
ương pháp phát triển lặp. Một trong những tiền thân được biết đến nhiều nhất
c
ủa ASD là “RADical Software Development” (phát triển phần mềm căn bản),
mô hình được phát triển bởi sự cộng tác của Highsmith và S. Bayer và được giới
thi
ệu trong “Bayer and Highsmith” 1994.
Trọng tâm chính của ASD là vào những vấn đề trong việc phát triển các hệ
th
ống lớn và phức tạp. Phương pháp này đã kích thích mạnh mẽ việc phát triển
lặp với việc chế thử liên tục. Về cơ bản ,ASD là “giữ cho cân bằng ở ranh giới
c
ủa sự hỗn loạn”,do đó,mục đích của ASD là cung cấp một khuôn mẫu vói
nh
ững hướng dẫn đầy đủ để tránh cho dự án lâm vào tình trạng hỗn loạn,khó
ki
ểm soát mặc dù đôi khi nó cũng làm hạn chế những sáng tạo hay những đột
phá.
M
ột dự án ASD được thiết kế theo 3 chu kì,được biểu diễn bởi hình sau :

Các bước này được đặt tên theo cách để nhấn mạnh vào vai trò của việc thay
đổi trong tiến trình.
Ở đây, “Speculation”xem xét , nghiên cứu) được dùng thay cho “Planning”
(lên k
ế hoạch) bởi vì 1 kế hoạch thì nhìn chung là chỉ được nhìn nhận như là 1
cái gì đó không ch

ắc chắn lắm,do đó mà những sự sai lệch sẽ dẫn đến thất bại.
Tương tự như vậy, “Collaborate”(cộng tác) được sử dụng để nhấn mạnh vào tầm
quan tr
ọng của làm việc theo nhóm như là ý nghĩa của việc phát triển những hệ
th
ống có sự thay đổi cao.”Learn”(học tập) lại nhấn mạnh vào sự cần thiết của
kiến thức và sửa lỗi, và trong thực tế là những yêu cầu có thể thay đổi liên tục
trong su
ốt quá trình phát triển. Hình sau đây sẽ miêu tả chi tiết hơn về chu kì
phát tri
ển thích nghi:

Bước khởi tạo dự án định ra những nền tảng của dự án và được bắt đầu bằng
cách định ra những nhiệm vụ của dự án.Những nhiệm vụ này cơ bản là lập ra
m
ột khung thô cho sản phẩm cuối,và tất cả các việc phát triển sẽ được chỉ đạo để
các nhi
ệm vụ được hoàn thành.Một trong những cái quan trọng nhất trong việc
định ra các nhiệm vụ cho dự án là phác thảo ra những thông tin nào cần thiết cho
d
ự án.Các mặt quan trọng của nhiệm vụ được định ra theo 3 phần: tầm nhìn của
d
ự án,dữ liệu dự án,1 sản phẩm đầu ra chi tiết. Ý nghĩa của những tài liệu này
đ
ược được giải thích chi tiết trong Highsmith 2000. Bước khởi tạo dự án sửa lại
bảng lịch trình kế hoạch tổng thể cũng như lich trình và các mục tiêu cho mỗi
chu kì phát tri
ển. Chu kì điển hình kéo dài từ 4 cho đến 8 tuần. ASD rõ ràng là
h
ướng thành phần hơn là hướng nhiệm vụ. Trong thực hành,điều này có ý nghĩa

là trọng tâm được đặt vào kết quả và chất lượng hơn là nhiệm vụ hay tiến trình
đ
ược sử dụng trong quá trình tạo ra kết quả ấy. Tiền đề cho những chu kì phát
tri
ển xa hơn là kết quả của việc lặp đi lặp lại việc kiểm tra chất lượng mà trọng
tâm là t
ập trung vào phát triển các chức năng của phần mềm trong suốt chu kì.
Một yếu tố quan trọng nữa trong việc đưa ra các đánh giá,kiểm tra là sự có mặt
c
ủa khách hàng ,ví dụ như là 1 nhóm các chuyên gia. Tuy nhiên từ khi các đánh
giá,ki
ểm tra chất lượng trở nên hiếm dần (chúng chỉ được thực hiện vào cuối của
mỗi chu kì) thì sự có mặt của khách hàng trong ASD cũng chỉ được làm trong
các phiên phát tri
ển ứng dụng kết nối (joint application development (JAD)).
M
ột phiên JAD là vô cùng quan trọng cho công việc, đây là nơi mà khách hàng
và nhà phát tri
ển gặp nhau và thảo luận về những yêu cầu về các tính năng của
sản phẩm, và để nâng cao việc truyền thông với nhau. ASD không đề xuất ra