Agile methodology - 1 -

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA CÔNG NGHỆ THÔNG TIN


BỘ MÔN
HỆ THỐNG THÔNG TIN HƯỚNG ĐỐI TƯỢNG ĐỀ TÀI
Phương pháp luận agile và ứng dụng
trong phát triển hệ thống thông tin
hướng đối tượng GV
: TS. Phạm Nguyễn Cương
Nhóm học viên thực hiện
:

2.2 Các phương pháp thực hành của mô hình hóa agile 24
2.3 Phát triển phần mềm theo hướng mô hình hóa agile 26
2.4 Tài liệu hóa theo hướng agile 27
3. Quy trình Scrum 28
3.1 Tổng quan về Scrum 28
3.2 Scrum và Waterfall 28
4. Quy trình XP 31
4.1 Tổng quan về XP 31
4.1 Các đặc điểm của XP 32
5. Phát triển hướng vào tính năng (Feature Driven Development) 37
5.1 Quy trình 37
5.2 Các vai trò và trách nhiệm 40
5.3 Kiểm chứng thực tiễn (Practices) 43
5.4 Sự chấp nhận và kinh nghiệm 44
5.5 Phạm vi sử dụng 44
5.6 Nghiên cứu hiện tại 44
6. The Rational Unified Process 45
6.1 Quy trình 45
6.2 Các vai trò và trách nhiệm 48
6.3 Kiểm chứng thực tiễn 49
6.4 Sự chấp nhận và kinh nghiệm 49
6.5 Phạm vi sử dụng 50
6.6 Nghiên cứu hiện tại 51
7. Tài liệu tham khảo 51

triển
phần mềm
truyền
t
h
ố
n
g

- Đã 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ư:
o Pure waterfall
o Code-and-Fix
o Spiral
o Modifed Waterfalls
o Evolutionary Prototyping
o Staged Delivery
o Evolutionary Delivery
o Design-to-Schedule
o Design-to-Tools
o Commercial Off-the-shelf Software

Agile methodology - 4 - - 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

Agile methodology - 5 - 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”.
- Phát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile)
là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát
triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative)
và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông
qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thường sử
dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và
chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh
hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Ngày
nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển
phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản
xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales,
marketing, giáo dục v.v.
- Thuật ngữ "Agile" chính thức được sử dụng rộng rãi theo cách thống nhất kể
từ khi “Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001. Nhờ tính
linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở
thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty
phát triển phần mềm. Theo khảo sát của hãng nghiên cứu thị trường
Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp
nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi
(xem Hình 1). Hơn thế, một số phương pháp Agile có xuất xứ và được sử
dụng hiệu quả ngoài phạm vi phát triển phần mềm.


Agile methodology - 7 - 1.2.1 Tuyên ngôn Agile
- “Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực
hiện nó và giúp đỡ người khác thực hiện.”
Qua công việc này, các nhà sáng tạo Agile đã đi đến việc đánh giá cao:
- Cá nhân và sự tương tác hơn là quy trình và công cụ
- Phần mềm chạy tốt hơn là tài liệu đầy đủ:
- Cộng tác với khách hàng hơn là đàm phán hợp đồng:
- Phản hồi với các thay đổi hơn là bám sát kế hoạch:
- “Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn
các mục ở bên trái.”
- Mười hai nguyên tắc phía sau tuyên ngôn Agile:
- “Chúng tôi tuân theo các nguyên tắc sau đây”
o Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc
chuyển giao sớm và liên tục các phần mềm có giá trị.
o Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình
phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế
cạnh tranh của khách hàng.
o Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ
vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
o
Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng
ngày trong suốt dự án.
o Xây dựng các dự án xung quanh những cá nhân có động lực. Cung
cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn
thành công việc.
o Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển
và trong nội bộ nhóm phát triển là hội thoại trực tiếp.

phút với lập trình cặp (pair-programming), hằng giờ với tích hợp liên tục
(continuos integration), hằng ngày với standup metting (đứng họp), hằng
phân đoạn với các buổi họp sơ kết và cải tiến.
- Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ
các vấn đề về truyền thông. Chu kỳ thanh-tra-và-thích-nghi làm việc tốt chỉ
khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:
- Tôn trọng giá trị của mỗi cá nhân
- Trung thực trong truyền thông
- Minh bạch về dữ liệu, hoạt động, và quyết định
- Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm
- Cam kế
t với nhóm và các mục tiêu của nhóm
- Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi
trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các
thành viên của nhóm phải thể hiện chúng. Chỉ khi đó nhóm mới có thể phát
huy được hết tiềm năng của mình.
- Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng.
Hầu hết các nhóm tránh lé s
ự thật, sự minh bạch, và tin tưởng vào các
chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột
xuất phát từ truyền thông trung thực trước đây. Để chống lại những khuynh
hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những
xung đột tích cực. Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà
còn đem lại các lợi ích khác:

Agile methodology - 9 - - Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở
ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và

tới khách hàng sau một khoảng thời gian nhất định.

Agile methodology - 10 - - Tất cả các nhóm agile phải xác lập những gì họ muốn nói là “phần mềm
chạy tốt”, cái thường được biết như là định nghĩa hoàn thành. Ở mức độ
cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng
vượt qua tất cả các kiểm thử và có thể được vận hành bởi người dùng
cuối. Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị (unit
test) và kiểm thử hệ thống. Các nhóm tốt nhất còn bao gồm việc kiểm thử
tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong
định nghĩa hoàn thành đối với một phần chức năng. Thông qua nguồn dữ
liệu phong phú từ các dự án, một công ty CMMI Cấp độ 5 cho thấy việc xác
định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính
năng và theo độ ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi
tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi
tốc độ sản xuất và giảm các sai sót đến 40%. Điều này có được từ một
công ty có tỷ lệ sai sót thấp nhất thế giới.
- Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau
một khoảng thời gian nhất định. Đồng thuận với định nghĩa hoàn thành là
một trong những cách thực tế để nhóm agile mang lại hiệu suất và chất
lượng cao, cái cần thiết để hoàn thành mục tiêu này.
1.2.1.3 Cộng tác với Khách hàng hơn là Thương thảo Hợp đồng
- Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên
toàn thế giới. Đi
ều này được cho là vì các dự án nhỏ hơn và mức độ
chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin
phản hồi về phần mềm hoạt động một cách đều đặn hơn. Các tác giả của
bản Tuyên ngôn đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để

đôi so với các dự án truyền thống tính trung bình trên toàn thế giới. Các
phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã
tạo ra một vị trí đặc biệt trong đội hình phát triển để dành riêng cho vị khách
hàng đại diện này.
1.2.1.4 Phản hồi với Thay đổi hơn là Bám sát Kế hoạch
- Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài
lòng khách hàng cũng như mang lại những giá trị kinh doanh. Dữ liệu
ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án
bị thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án
truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng
theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ
thấy không thật sự đúng như những gì họ muốn. Luật Humphrey nói rằng
khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần
mềm hoạt động. Nếu khách hàng không nhìn thấy phần mềm hoạt động
cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin
phản hồi của họ ở thời điểm này. Các phương pháp phát triển linh hoạt tìm

Agile methodology - 12 - kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông
tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển.
- Tất cả các phương pháp phát triển linh hoạt đều được tích hợp sẵn những
tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa
trên những thông tin phản hồi từ phía khách hàng cũng như bên đại diện
của khách hàng. Các kế hoạch được thiết kế để sao cho luôn cung cấp giá
trị kinh doanh cao nhất trước hết. Bởi vì 80% giá trị nằm trong 20% các tính
năng, một dự án phát triển linh hoạt chạy tốt có xu hướng kết thúc sớm,
trong khi hầu hết các dự án truyền thống thường kết thúc trễ. Kết quả là,
khách hàng thì vui vẻ hơn, và các nhà phát triển thì thích thú với công việc

hoạt. Nó không bao gồm các vấn đề thực hành, kỹ thuật cụ thể. Ngược lại,
XP lại tập trung vào các kỹ thuật thực hành cụ thể nhưng không có một bộ
khung làm việc tổng thể cho quá trình phát triển. Điều đó không có nghĩa
rằng Scrum khuyên bạn không nên áp dụng các phương pháp thực hành
cụ thể hay là XP thì không có quy trình. Ví dụ, ban đầu Scrum áp dụng tất
cả các phương pháp thực hành mà bây giờ được biết đến như là XP. Tuy
nhiên, khung làm việc Scrum cho việc phát triển phần mềm được thiết kế
để có được một nhóm nghiên cứu bắt đầu trong hai ba ngày, trong khi thực
hành kỹ thuật phải mất nhiều tháng để thực hiện. Vì vậy, nó để lại câu hỏi
khi nào (hay không) để thực hiện các thực hành cụ thể đối với mỗi đội. Hai
đồng tác giả của Scrum là Jeff Sutherland và Ken Schwaber khuyến nghị
rằng Nhóm Scrum bắt đầu ngay lập tức và tạo ra danh sách các trở ngại và
kế hoạch cải tiến quy trình. Khi việc thực hành về kỹ thuật được xác định là
trở ngại, nhóm nên xem xét các phương pháp thực hành của XP như là
một cách để cải tiến. Các nhóm tốt nhất sử dụng Scrum bổ sung với thực
hành XP. Scrum giúp XP về mặt quy mô, XP giúp Scrum làm việc tốt hơn.
- Bảng sau cho thấy những thuật ngữ quan trọng tương ứng giữa Scrum và
XP.
Scrum XP
Chủ sản phẩm (Product Owner) Khách hàng (Customer)
Scrum Master Huấn luyện viên XP (XP coach)
Nhóm Nhóm
Sprint Phân đoạn (iteration)
Họp Kế hoạch Sprint (Sprint
Planning)
Trò chơi lập kế hoạch (Planning
Game)

tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially
shippable product increment of functionality). Theo thời gian, phân đoạn
này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn

Agile methodology - 15 - dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. Khác
với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các
chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn
dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát
hành.
1.2.2.3 Tính thích ứng (hay thích nghi – adaptive)
- Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập
kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình
phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về
mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp . Ví dụ, trong
Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển
sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu
mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có
thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp
theo. Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi.
1.2.2.4 Nhóm tự tổ chức và liên chức năng
- Cấu trúc nhóm agile thường là liên chức năng(cross-functionality) và tự tổ
chức(self-organizing)
. Theo đó, các nhóm này tự thực hiện lấy việc phân
công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay
làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Các nhóm này
cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề
mà không chờ mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ

- Bản thân các nhóm agile thường nhỏ (ít hơn mười hai người, một nhóm lớn
thường được phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông
lượng giao tiếp tối đa) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc
cộng tác hiệu quả. Các dự án lớn muốn dùng agile thường phải phân thành
nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung.
Việc này có thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức
ưu tiên giữa các nhóm.
- Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực
diện một cách thường xuyên. Một trong các cơ chế thường thấy là các
cuộc họp tập trung hằng ngày (daily meeting, Daily Scrum, standup
meeting). Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của
mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó
khăn nào trong quá trình làm việc. Khi cơ chế này được thực hiện hiệu quả,
nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động
thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự
án.
Agile methodology - 17 - 1.2.2.7 Phát triển dựa trên giá trị (value-based development)
- Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là
thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công
việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm. Ví dụ, một
nhóm thấy rằng có thể không cần phải viết ra tất cả các thiết kế của hệ
thống, mà họ chỉ cần phác thảo các thiết kế này lên bảng, rồi cùng nhau
triển khai các chức năng của hệ thống. Nhưng nếu như chủ sản phẩm
quyết định rằng, khi chuyển giao sản phẩm, nhóm phát triển phải kèm theo


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

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.
2. Mô hình hóa với Agile
2.1 Các giá trị của mô hình hóa Agile
2.1.1 Trao đổi thông tin
- Việc trao đổi thông tin một cách hiệu quả đóng một vài trò cực kì quan trọng
đối với nhóm phát triển cũng như đối với các bên liên quan

Agile methodology - 20 -
Hình 4: Một buổi họp nhóm hằng ngày theo quy trình Scrum
2.1.2 Tính đơn giản
- Nhóm phát triển cần cố gắng tìm ra các giải pháp đơn giản nhất có thể nhằm
thỏa các yêu cầu đã đề ra.

Agile methodology - 21 -
Hình 5: Cách mô hình hóa UI cho một ứng dụng bằng các thẻ và bảng trắng
2.1.3 Sự phản hồi

2.1.4 Thay đổi theo hướng tiếp cận tăng trưởng
- Trong việc đối mặt với các thay đổi, cần chia công việc ra thành từng phần
nhỏ, đánh giá độ ưu tiên và sắp xếp trong các khoảng thời gian hợp lý thay
vì dồn hết tất cả lại trong một lần bàn giao sản phẩm.
2.1.5 Áp dụng đa mô hình
- Mỗi mô hình có điểm mạnh và điểm yếu riêng của nó và sẽ phù hợp với
một hoàn cảnh nhất định. Các phần mềm hiện nay có cúc trúc rất phức tạp

Agile methodology - 23 - và không một công cụ mô hình hóa nào có thể đáp ứng được cho tất cả
các trường hợp mô hình hóa. Chính vì vậy để việc mô hình hóa được hiệu
quả chúng ta cần sử dụng kết hợp nhiều mô hình để mô hình hóa các hệ
thống phần mềm. Mỗi mô hình sẽ đóng một vai trò trong việc diễn tả một
khía cạnh của hệ thống.
2.1.6 Gọn nhẹ đến mức tối thiểu
- Mô hình hóa theo kiểu gọn nhẹ đến mức tối thiểu nghĩa là chúng ta cần tạo
một số lượng mô hình và tài liệu vừa đủ.
- Việc tạo và lưu trữ quá nhiều mô hình, tài liệu không cần thiết cũng đồng
nghĩa với việc chúng ta sẽ phải tốn thời gian cho việc cập nhật các mô
hình, tài liệu đó theo thời gian.
2.1.7 Phần mềm chạy tốt là mục tiêu chính
- Coi phần mềm chạy được là mục tiêu chính là một nguyên tắc cốt lõi là bởi
vì mục tiêu chính của toàn bộ quá trình phát triển phần mềm chính là sản
xuất ra những phần mềm chất lượng cao phù hợp với yêu cầu của các bên
liên quan theo một cách thức hiệu quả nhất. Chính vì vậy việc mô hình hóa
cần bám sát mục tiêu này. Bất kì hoạt động mô hình hóa nào không trực
tiếp đóng góp vào thành quả nhằm sản xuất ra các sản phẩm có chất lượng
cần được cân nhắc loại bỏ ra khỏi quá trình phát triển.

để cài đặt sản phẩm trên nó, các nhóm phát triển các hệ thống khác cần nỗ
lực trong việc hỗ trợ tích hợp, các nhà phát triển chuyên nâng cấp, bảo
dưỡng cần phải thông thạo công nghệ và kĩ thuật được dùng trong dự án.
2.2.2 Dùng các công cụ đơn giản nhất
- Rất nhiều mô hình có thể được vẽ trên bảng, trên giấy. Bất cứ khi nào chúng
ta muốn lưu trữ một lược đồ, chỉ cần chụp lại lược đồ với một máy ảnh số
hay vẽ trên giấy.
- Giá trị của một lược đồ là để làm rõ một vấn đề nào đó, và một khi vấn đề đã
được giải quyết, lược đồ sẽ không cần nhiều giá trị nữa. Chính vì vậy không
nên áp dụng nhiều công cụ mô hình hóa phức tạp.
2.2.3 Cộng tác trong việc mô hình hóa
- Mục tiêu của mô hình hóa là làm rõ một vấn đề hoặc để diễn đạt các ý tưởng
cho những người khách trong nhóm. Vì vậy hóm phát triển cần làm việc
cùng nhau để tạo một bộ các mô hình cơ bản cho dự án.
2.2.4 Chứng minh mô hình bằng mã nguồn
- Mô hình là một thực thể trừu tượng và nên phản ánh chính xác một khía
cạnh của sản phẩm thực. Vì vậy để biết được mô hình có thực sự hoạt động
hay không, cần kiểm nghiệm đó với chính các mã lệnh được viết ra từ nó.
2.2.5 Sử dụng các artifact một cách thích hợp
- Artifact là các sản phẩm phụ được tạo ra trong quá trình phát triển phần
mềm.

Agile methodology - 25 - - Mỗi artifact chẳng hạn như sơ đồ trạng thái của UML, ca sử dụng "use
case", mã nguồn, lược đồ luồng DFD có điểm mạnh và điểm yếu riêng của
nó. Chính vì vậy mỗi artifact chỉ thích hợp trong một ngữ cảnh cụ thể nào đó.
2.2.6 Tạo nhiều mô hình song song
- Không có một mô hình đơn lẽ nào có thể phù hợp với tất cả các yêu cầu mô