Ví dụ bạn hãy tưởng tượng sẽ chế tạo một con Robot đồ chơi của trẻ em. Nếu bạn dùng một khối nhựa và đúc thành một hình robot hoàn chỉnh. Khi đó nếu con robot đó bị hỏng trong phần nào đó hay nhu cầu thay đổi, bạn sẽ phải làm lại từ đầu. Nhưng nếu bạn đúc thành từng bộ phận nhỏ như tay, chân, thân hình … rồi sau đó lắp ghép chúng lại với nhau. Khi đó con robot có bị hỏng phần nào thì bạn chỉ cần sửa phần đó rồi ráp chúng lại, làm như thế nhanh hơn. Hơn nữa nếu bạn muốn sản xuất một loại robot mới thì cũng có thể sử dụng lại một bộ phận đã sản xuất nào đó của con robot trước.

Khi được chia nhỏ ra, mỗi phần nhỏ đó được test cẩn thận bằng Unit test bởi chính các developer. Khi tích hợp chúng lại được integation test.

JUnit và Cactus.

1. Refactoring: Giống như vệc bạn trang trí lại căn nhà mà không cần phải cơi nới, xây thêm hay xây lại, “refactoring” (xin lỗi, tôi chưa tìm được từ tiếng Việt nào thích hợp để dịch) cho phép chúng ta chuyển đổi mã lệnh để làm cho ứng dụng tốt hơn, đẹp hơn mà không phá hỏng nó (các bạn có thể tìm hiểu thêm về kỹ thuật này trong cuốn Refactoring: Improving the Design of Existing Code).
2. Developer Testing: Phần mềm do chính các lập trình viên được kiểm định thay vì do các nhóm tester độc lập làm. Công cụ là “unit test”, cho phép từng phần nhỏ của phần mềm được kiểm định ngay trong quá trình phát triển trước khi lắp ghép vào ứng dụng. (xin xem thêm cuốn Test Driven Development: By Example)

Trích:
http://www.web2vietnam.com/2007/10/18/l%e1%ba%adp-trinh-vien-b%e1%ba%a1n-s%e1%ba%bd-b%e1%bb%8b-dao-th%e1%ba%a3i-ngay-mai/

Thực ra cái mô hình Waterfall bây giờ đã thể hiện nhược điểm cứng nhắc, không linh hoạt. Tuy nhiên nó vẫn là mô hình được ứng dụng nhiều, chỉ có điều đang thay đổi trở nên nhỏ hơn thôi.

Agile là mô hình linh hoạt, nhưng trong mỗi khung thời gian của nó vẫn dùng mô hình Waterfall đó, công thêm yêu cầu về khả năng mở rộng linh hoạt của hệ thống.