Mô Hình Yêu Cầu Tương tác khách Quy mô dự án

(+/ - ) hàng (+/-) ( + /-)

Agile model & scrum + + -
Process
Rapid Applicatinon + + -
Development

I, Mô hình Agile model & Scrum Process:

1, Đặc trưng của Agile:

*, Tính lặp (Iterative):

-Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân
đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn
(từ 1 – 4 tuần).

- Nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế
hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác
nhau) để cho ra các phần nhỏ của sản phẩm. Agile thường phân rã mục tiêu
thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể,
và không thực hiện việc lập kế hoạch dài hạn.

*, Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary):

- Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của
sản phẩm cuối cùng có khả năng chạy tốt, được kiểm thử cẩn thận và có
thể sử dụng ngay

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

*, Tính thích ứng (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.

-Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay đổi.

*, Nhóm tự tổ chức và liên chức năng

*, Quản lý tiến trình thực nghiệm (Empirical Process Control)
*, Giao tiếp trực diện (face-to-face communication)
*, Phát triển dựa trên giá trị (value-based development)

2, Scrum :

*, 3 giá trị cốt lõi :

-Minh bạch (transparency): tầm nhìn (vision) về sản phẩm, yêu cầu
khách hàng, tiến độ công việc, các khúc mắc và rào cản v.v.
-Thanh tra (inspection) : đảm bảo cho việc phát lộ các vấn đề cũng
như giải pháp để thông tin đa dạng và hữu ích
-Thích nghi (adaptation) : Dựa trên các thông tin minh bạch hóa từ các
quá trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi
một cách tích cực, nhờ đó mang lại thành công cho dự án
*, 3 vai trò:
-Product Owner (chủ sản phẩm): Là người chịu trách nhiệm về sự
thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối
cùng đầu ra của các nhà phát triển phần mềm.
-Scrum Master: Là người có hiểu biết sâu sắc về Scrum và đảm bảo
nhóm có thể làm việc hiệu quả với Scrum.
-Development Team (Đội sản xuất, hay Nhóm phát triển): Một nhóm
liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các
 yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ
thống.
*, 4 events :
-Sprint Planning( họp kế hoạch sprint): Công việc lập kế hoạch bao
gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận
biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết
để hoàn tất các tác vụ.
-Daily Scrum ( họp sơ kết sprint): họp hằng ngày trong khoảng 15
phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các
khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint.
-Sprint Review( Họp sơ kết Sprint): rà soát lại các công việc đã hoàn
tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi
cần thiết cho sản phẩm.
-Sprint Retrospective( Họp cải tiến sprint): nhóm phát triển sẽ rà soát
lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc
cũng như bản thân sản phẩm
*, Các công cụ Scrum:
-Product backlog: Product Owner chịu trách nhiệm sắp xếp độ ưu tiên
cho từng hạng mục
-Sprint backlog: phân tích các yêu cầu theo độ ưu tiên từ cao xuống
thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng
danh sách công việc
-Burndown Chart: có thể được dùng để theo dõi tiến độ của Sprint
hoặc của cả dự án
3. Yêu cầu :

-Yêu cầu đề áp dụng mô hình Agile model & Scrum Process thành công:

+, Sự hợp tác và giao tiếp: Các thành viên trong nhóm cần có tinh thần hợp tác cao và
sẵn sàng giao tiếp cởi mở với nhau.
+, Kỷ luật và trách nhiệm: Các thành viên cần tuân thủ các quy tắc và quy trình của mô
hình Agile, đồng thời chịu trách nhiệm cho công việc của mình.

+,Khả năng thích ứng: Các thành viên cần sẵn sàng thích ứng với thay đổi và điều chỉnh
kế hoạch khi cần thiết.
+, Định rõ mục tiêu và yêu cầu: Xác định rõ mục tiêu và yêu cầu của dự án. Điều này
giúp định hình Product Backlog và đưa ra các ưu tiên phát triển sản phẩm.
+, Quy trình làm việc theo Sprint ngắn: Thường 1-4 tuần, xác định rõ phạm vi và mục
tiêu cho từng giai đoạn.
+, Lựa chọn mô hình Agile phù hợp: Có nhiều mô hình Agile khác nhau, ví dụ như
Scrum, Kanban, Lean, v.v. Mỗi mô hình có những ưu điểm và nhược điểm riêng, cần lựa
chọn mô hình phù hợp nhất với dự án của bạn.
+, Họp hàng ngày (Daily Scrum): Rà soát tiến trình, giải quyết vấn đề nhanh chóng.
4. Tương tác khách hàng:

+,Ưu tiên cao nhất 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ị.

+,Tổ chức các cuộc họp trong và sau mỗi Sprint để nhận phản hồi về tính năng, chức
năng mới. Linh hoạt điều chỉnh yêu cầu, ưu tiên theo phản hồi của khách hàng trong quá
trình phát triển.
+,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.

+, Sprint review: Khách hàng xem xét và đánh giá phần mềm được phát triển sau mỗi
sprint. Phản hồi của khách hàng được sử dụng để cải thiện sản phẩm trong các sprint tiếp
theo.

+, Tính minh bạch: Khách hàng được cung cấp thông tin đầy đủ về dự án, bao gồm tiến
độ, rủi ro và chi phí.

5. Quy mô dự án:
-Nên áp dụng cho dự án có quy mô vừa và nhỏ do:

+, Do đặc trưng của agile phân đoạn sprint có khung tgian ngắn từ 1-4 tuần để cho ra
các phần nhỏ của sản phẩm và không thực hiện việc lập kế hoạch dài hạn.
+, Các cuộc họp, trao đổi ý kiến giữa các bên có liên quan như daily scrum sẽ dễ
dàng hơn khi quy mô nhóm nhỏ hơn.
+, Dễ theo dõi tiến độ và chủ động điều chỉnh kế hoạch nếu cần thiết trong quy mô
nhỏ hơn.

+, Dự án có tính chất đơn giản, quy mô nhỏ và ít thay đổi: Mô hình Agile và Scrum
Process có thể không phù hợp với các dự án đơn giản, quy mô nhỏ và ít thay đổi vì
overhead (chi phí) của việc áp dụng mô hình có thể cao hơn lợi ích thu được.

+,Dự án có yêu cầu nghiêm ngặt về quy trình và tuân thủ: Mô hình Agile và Scrum
Process có thể khó áp dụng cho các dự án có yêu cầu nghiêm ngặt về quy trình và tuân
thủ, ví dụ như các dự án phát triển phần mềm cho các ngành regulated (bị quản lý) như y
tế, tài chính.
6. Ưu điểm và nhược điểm:
*, Ưu điểm:
+, Agile là một phương pháp linh hoạt, linh động và tăng cường tương tác và phản hồi

+,đặt khách hàng lên hàng đầu và tập trung vào việc cung cấp giá trị cho khách hàng sớm
nhất từ thể hiện thực của sản phẩm

+, thay đổi yêu cầu linh hoạt trong quá trình phát triển, đáp ứng tốt với môi trường ngày
càng biến động và thay đổi.

+, Scrum là một phương pháp quản lý dự án theo mô hình linh hoạt, có tính minh bạch
thanh tra thích nghi

+,Tăng khả năng phản hồi nhanh và sáng tạo thông qua các sprint ngắn, tăng tính kỷ luật
và hiệu quả làm việc của nhóm thông qua daily scrum
*, Nhược điểm:
+, khó định lượng và ước tính thời gian, công sức, và nguồn lực cần thiết cho dự án

+, Agile cần sự tương tác và phối hợp tốt giữa các thành viên trong nhóm.

+,Khó dự báo chính xác thời gian và chi phí dự án.

+,Scrum hữu ích cho nhiều dự án phần mềm nhỏ và vừa, yêu cầu linh hoạt.

+,phụ thuộc vào tương tác và phản hồi liên tục giữa các thành viên trong nhóm

+,phải thực hiện đầy đủ các nguyên tắc của scrum

II, Mô hình Rapid Applicatinon Development

-RAD : phương pháp quản lý dự án và phát triển phần mềm có tính linh hoạt và tập trung
vào việc phát triển nhanh chóng của ứng dụng.

*, Khi nào nên sử dụng mô hình RAD :

-Thời gian ngắn hạn: RAD thích hợp cho các dự án có khung thời gian chặt chẽ. Nó nhấn
mạnh vào các chu kỳ phát triển nhanh chóng, giúp tăng tốc quá trình triển khai dự án.

-Dự án nhỏ và trung bình:

-Phạm vi dự án rõ ràng: Mặc dù RAD linh hoạt, nhưng việc có một phạm vi dự án rõ ràng
và mục tiêu cụ thể cũng rất quan trọng. Sự mơ hồ về mục tiêu dự án có thể dẫn đến khó
khăn trong việc tận dụng RAD một cách hiệu quả.

-Ngân sách và tài nguyên: Đảm bảo rằng các tài nguyên cần thiết, bao gồm các công cụ
và môi trường phát triển luôn sẵn sàng cho các dự án RAD. Có sẵn các tài nguyên này có
thể giúp tăng tốc quá trình phát triển

*, Các giai đoạn trong mô hình RAD :

-Business Modeling: nhóm dự án hợp tác chặt chẽ với các bên liên quan và người dùng
để xác định yêu cầu kinh doanh và mục tiêu. Giai đoạn này liên quan đến việc thu thập
thông tin về luồng công việc, các quy tắc và thủ tục của doanh nghiệp

-Data Modeling: Trọng tâm chuyển sang thiết kế cấu trúc cơ sở dữ liệu mà phần mềm sẽ
sử dụng. Nhóm dự án xác định các dữ liệu, mối quan hệ, thuộc tính và quy tắc bảo đảm
tính toàn vẹn dữ liệu, tạo mô hình dl logic mô tả chính xác tt -> đảm bảo ứng dụng có thể
xử lý dữ liệu hiệu quả và hỗ trợ các chức năng cần thiết

-Process Modeling: thiết kế luồng hoạt động và tương tác trong ứng dụng phần mềm,
nhấn mạnh việc định nghĩa luồng làm việc của người dùng, các quy tắc kinh doanh và
quy trình của hệ thống.

-Application Generation: bao gồm việc phát triển thực tế của phần mềm bằng cách sử
dụng các công cụ và kỹ thuật phát triển nhanh -> Trọng tâm là tạo mã một cách nhanh
chóng trong khi duy trì tính nhất quán và chất lượng

-Testing and Turnover: phần mềm trải qua quá trình kiểm tra toàn diện để xác định và
khắc phục các lỗi hoặc sự cố. Kiểm tra bao gồm kiểm tra chức năng, kiểm tra hiệu suất,
kiểm tra khả năng sử dụng và nhiều hơn nữa. Khi phần mềm được xem là ổn định và đáp
ứng các yêu cầu đã chỉ định, nó sẽ được chuyển giao cho người dùng cuối

1, Yêu cầu:
+,Sự tham gia tích cực của khách hàng: Khách hàng cần tham gia tích cực vào quá
trình phát triển để đảm bảo phần mềm đáp ứng nhu cầu của họ.

+,Cam kết của ban lãnh đạo: Ban lãnh đạo cần cam kết hỗ trợ mô hình RAD và cung
cấp các nguồn lực cần thiết.

+,Đội ngũ phát triển có kỹ năng: Đội ngũ phát triển cần có kỹ năng và kinh nghiệm sử
dụng các công cụ và kỹ thuật RAD.

+,Môi trường làm việc phù hợp: Môi trường làm việc cần hỗ trợ sự cộng tác và giao
tiếp giữa các thành viên trong nhóm.
+,Áp dụng phân tích và thiết kế theo phương pháp từ trên xuống (top-down), tập
trung vào các tính năng then chốt.
+,Thông tin phản hồi liên tục trong suốt quá trình phát triển từ người dùng/khách hàng
+,yêu cầu sự nhanh chóng và thường xuyên cập nhật theo sự thay đổi của yêu cầu và
môi trường kinh doanh
+, Tài liệu tài nguyên đầy đủ
2. Tương tác khách hàng:
+Phản hồi người dùng: Bằng cách tạo mẫu và cho phép người dùng thử nghiệm sớm,
bạn có thể thu thập phản hồi từ họ và cải thiện sản phẩm theo thời gian.

+Tích hợp sâu với người dùng: Đối với các ứng dụng yêu cầu sự tích hợp sâu với sự
tham gia của người dùng, như các ứng dụng dựa trên giao diện người dùng, RAD là một
lựa chọn tốt.

+, Giao tiếp liên tục: Đội ngũ phát triển thường xuyên giao tiếp với khách hàng để cập
nhật tiến độ dự án và giải đáp các thắc mắc.

+Tính minh bạch: Khách hàng được cung cấp thông tin đầy đủ về dự án, bao gồm tiến
độ, rủi ro và chi phí.
+, Cải thiện chất lượng sản phẩm: Phản hồi của khách hàng giúp cải thiện chất lượng
sản phẩm liên tục trong suốt quá trình phát triển.

3. Quy mô dự án:

-Mô hình Rapid Applicatinon Development nên áp dụng cho các dự án có quy mô vừa
và nhỏ do:

+,RAD thích hợp cho các dự án có khung thời gian chặt chẽ. Nó nhấn mạnh vào các
chu kỳ phát triển nhanh chóng, giúp tăng tốc quá trình triển khai dự án. Nếu bạn cần triển
khai một giải pháp phần mềm một cách nhanh chóng, RAD có thể giúp bạn đáp ứng các
thời hạn chặt chẽ. Trong tgian ngắn hạn từ 2-3thang

+,Mô hình RAD hiệu quả nhất cho các dự án nhỏ và trung bình. Nó có thể không phù
hợp cho các dự án lớn, phức tạp đòi hỏi kế hoạch và tài liệu chi tiết.

+, Dự án lớn và phức tạp: Mô hình RAD có thể khó áp dụng cho các dự án lớn và phức
tạp vì quy trình phát triển lặp đi lặp lại có thể khó quản lý.

+, Dự án đòi hỏi tính chính xác cao: Mô hình RAD có thể không phù hợp với các dự
án đòi hỏi tính chính xác cao vì việc phát triển nhanh chóng có thể dẫn đến lỗi.

+, Tài nguyên chi phí, quản lý tốn kém: Việc sử dụng các công cụ và kỹ thuật phát
triển nhanh có thể tốn kém.
4. Ưu điểm và nhược điểm:

*, Ưu điểm:

+,Phát triển nhanh chóng: RAD tập trung vào việc phát triển nhanh chóng, giúp giảm
thời gian triển khai dự án so với các mô hình phát triển truyền thống. Điều này đặc biệt
hữu ích khi cần triển khai nhanh để đáp ứng yêu cầu kịp thời.
+,Sự linh hoạt: Với tính linh hoạt của mô hình này, bạn có thể điều chỉnh yêu cầu và
thậm chí thay đổi hướng của dự án một cách dễ dàng. Điều này rất hữu ích khi có yêu cầu
thay đổi trong quá trình phát triển dự án.
+,Phản hồi người dùng: Bằng cách tạo mẫu và cho phép người dùng thử nghiệm sớm,
bạn có thể thu thập phản hồi từ họ và cải thiện sản phẩm theo thời gian.
+,Tích hợp sâu với người dùng: Đối với các ứng dụng yêu cầu sự tích hợp sâu với sự
tham gia của người dùng, như các ứng dụng dựa trên giao diện người dùng, RAD là một
lựa chọn tốt.
+,Giảm rủi ro: Tích hợp liên tục với người dùng giúp giảm rủi ro về việc phát triển một
sản phẩm không đáp ứng yêu cầu. RAD có thể giúp thấy các vấn đề sớm, từ đó tiết kiệm
thời gian và nguồn lực so với việc phát hiện lỗi ở giai đoạn sau của dự án.

*, Nhược điểm:
+,Không phù hợp cho dự án lớn và phức tạp: Mô hình RAD thích hợp cho dự án nhỏ
và trung bình, nhưng không phải lúc nào cũng phù hợp cho các dự án lớn và phức tạp đòi
hỏi kế hoạch và tài liệu chi tiết.
+,Yêu cầu kỹ năng cao: Để triển khai RAD một cách hiệu quả, đội ngũ phát triển cần có
kỹ năng cao và sử dụng các công cụ giúp phát triển nhanh.
+,Tài nguyên: RAD đòi hỏi tài nguyên như máy tính mạnh và môi trường phát triển hiệu
quả để đảm bảo khả năng tạo mã và kiểm thử nhanh chóng.
+,Quản lý khó khăn: Do sự phát triển nhanh chóng và linh hoạt, quản lý dự án có thể trở
nên khó khăn. Điều này đòi hỏi sự quản lý cẩn thận để đảm bảo sự tuân thủ các mục tiêu
dự án và lịch trình.
+,Thiếu tài liệu chi tiết: Do tập trung vào việc phát triển nhanh, RAD thường thiếu tài
liệu chi tiết. Điều này có thể gây khó khăn cho việc bảo trì và mở rộng sản phẩm sau khi
nó đã được triển khai.