



















Preview text:
lOMoARcP SD| 58886076 TP.HCM, tháng 05 năm 2025 ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG VIỆT - HÀN ------□&□------ BÀI TẬP LỚN
MÔ HÌNH PHÁT TRIỂN DỰ ÁN – SCRUM i Sinh viên thực hiện: Arất Thị Bích Phượng Lê Đình Phương Đỗ Lê Viết Tài Nguyễn Văn Hoàng Trinh
Giảng viên giảng dạy: ThS. Nguyễn Thanh Tuấn lOMoARcP SD| 58886076 LỜI CẢM ƠN
Nhóm chúng em xin gửi lời chào trân trọng và cảm ơn chân thành đến các thầy cô của
Trường Đại học Công nghệ Thông tin và Truyền thông Việt – Hàn, đặc biệt là giảng viên
ThS. Võ Văn Lường, vì đã tạo điều kiện và hướng dẫn tận tình trong suốt quá trình học
tập và thực hiện bài báo cáo cho học phần “Công nghệ phần mềm”. Trong quá trình thực
hiện, nhóm đã cố gắng nghiên cứu và tìm hiểu một cách nghiêm túc để hoàn thiện bài
báo cáo này. Tuy nhiên, do kiến thức và khả năng tiếp nhận của chúng em còn hạn chế,
khó tránh khỏi những thiếu sót. Vì vậy, nhóm rất mong nhận được ý kiến đóng góp và
nhận xét từ thầy cô để bài báo cáo được hoàn thiện hơn. Cuối cùng, nhóm chúng em xin
chúc thầy cô luôn mạnh khỏe và chúc Trường Đại học Công nghệ Thông tin và Truyền
thông Việt – Hàn ngày càng phát triển vững mạnh.
Chúng em xin chân thành cảm ơn!
Đà Nẵng, tháng 5 năm 2025 Nhóm thực hiện lOMoARcP SD| 58886076 ỤC LỤC LỜI CẢM ƠN 2 MỤC LỤC 3 DANH SÁCH HÌNH ẢNH4
CHƯƠNG 1: TÌM HIỂU MÔ HÌNH PHÁT TRIỂN DỰ ÁN SCRUM 5 1.
Mô hình phát triển phần mềm là gì? 6 2.
Khái quát về mô hình Scrum 6
2.1 Giới thiệu về Agile – nền tảng của Scrum 6
2.2 Lịch sử hình thành và phát triển của mô hình Scrum 6
2.3 Đặc điểm của mô hình Scrum 7 2.4 Giá trị cốt lõi 8 2.5 Các vai trò trong Scrum 8
2.6 Các sự kiện trong Scrum 9 2.7 Quy trình Scrum9
2.7.1 Đầu vào của quy trình 11
2.7.2 Đầu ra của quy trình 11
Chương 2: Tìm hiểu về dự án “Ứng dụng Đặt Phòng Khách Sạn Trực Tuyến” 12 1. Tổng quan về dự án 13 2. Phạm vi dự án 13 3. Yêu cầu của dự án 13 3.1 Yêu cầu người dùng 13 3.2 Yêu cầu kĩ thuật 14 3.3 Yêu cầu hiệu suất 14 4. Lịch trình thời gian 15 5. Chi phí cho dự án 15 6. Nhân lực cho dự án 15
Chương 3: Cách chọn mô hình scrum cho dự án “Ứng dụng Đặt Phòng Khách Sạn Trự c Tuyến” 16 1. Tổng quan 16 2.
Phân tích các tiêu chí để chọn mô hình phát triển phần mềm cho dự án "Ứng dụ
ng Đặt Phòng Khách Sạn Trực Tuyến" 17
2.1. Khách hàng có hiểu hết các yêu cầu (mong đợi của họ) về phần mềm không? 17
2.2. Làm thế nào khách hàng có thể tham gia vào quá trình phát triển phần mềm? 17
2.3. Yêu cầu của phần mềm có rõ ràng và ổn định không ? 18
2.4. Quy mô, kỹ năng, khả năng kỹ thuật phần mềm và sự phù hợp của nhóm
phát triểncho dự án phần mềm? 19
2.5. Mô hình nào phù hợp với công nghệ được chọn để triển khai giải pháp?19
2.6. Mối quan tâm và ưu tiên của khách hàng và các bên liên quan là gì? 20
2.7. Loại, kích thước và độ phức tạp của phần mềm là gì? 20 2.8 Yêu cầu
chất lượng của phần mềm là gì? 20
2.9 Các rủi ro trong quá trình phát triển có được xác định, phân tích và đề xuất không? giải pháp phòng ngừa? 21
2.10 Chi phí và thời gian dành cho dự án phần mềm là bao nhiêu? 22 lOMoARcP SD| 58886076
Chương 4: Kết luận 22 1. Chọn mô hình 23 2. Cách chọn mô hình 23 TÀI LIỆU THAM KHẢO 23 TÀI LIỆU THAM KHẢO 27 DANH SÁCH HÌNH ẢNH lOMoARcP SD| 58886076
CHƯƠNG 1: TÌM HIỂU MÔ HÌNH PHÁT TRIỂN DỰ ÁN SCRUM
1.1 Mô hình phát triển phần mềm là gì?
Mô hình phát triển phần mềm là một khung công tác hoặc phương pháp luận được sử
dụng để tổ chức và quản lý quá trình phát triển phần mềm từ giai đoạn khởi đầu đến khi
hoàn thiện và bảo trì. Các mô hình này xác định các giai đoạn khác nhau của quá trình
phát triển phần mềm, cách thức các giai đoạn này được thực hiện, và các tương tác giữa các giai đoạn đó.
1.2 Khái quát về mô hình Scrum
Hình 3.1 Mô hình Scrum/Agile
1.2.1 Giới thiệu về Agile – nền tảng của Scrum
Agile (viết tắt của Agile Software Development) là một phương pháp tiếp cận linh hoạt
trong phát triển phần mềm, được ra đời nhằm đáp ứng nhu cầu ngày càng thay đổi
nhanh chóng của thị trường và khách hàng. Agile không phải là một quy trình cụ thể
mà là một tập hợp các nguyên tắc được xác định trong Agile Manifesto (Tuyên ngôn
Agile) vào năm 2001, tập trung vào việc:
Ưu tiên con người và sự tương tác hơn các công cụ và quy trình.
Tạo ra sản phẩm phần mềm hoạt động thực tế thay vì tài liệu phức tạp.
Cộng tác chặt chẽ với khách hàng thay vì chỉ dựa vào hợp đồng cứng nhắc. lOMoARcP SD| 58886076
Phản hồi nhanh với sự thay đổi hơn là bám vào kế hoạch cố định.
Agile được thực hiện thông qua các chu kỳ phát triển ngắn gọi là iteration hoặc sprint,
mỗi chu kỳ kéo dài từ 1 đến 4 tuần. Sau mỗi sprint, một phần sản phẩm có thể sử dụng
được sẽ được bàn giao, cho phép nhóm phát triển nhận phản hồi ngay từ sớm và điều
chỉnh phù hợp. Điều này giúp rút ngắn thời gian phát triển, giảm rủi ro và đảm bảo
rằng sản phẩm cuối cùng đáp ứng được yêu cầu thực tế của người dùng. Agile cung cấp
nền tảng cho nhiều khung làm việc, trong đó Scrum là một trong những khung phổ biến
nhất. Scrum kế thừa tinh thần Agile, áp dụng linh hoạt các nguyên tắc cốt lõi để quản
lý và phát triển dự án. Agile chính là nền tảng tư duy giúp Scrum phát huy tối đa lợi ích
của việc phát triển phần mềm dựa trên sự thích nghi và hợp tác liên tục.
1.2.2 Lịch sử hình thành và phát triển của mô hình Scrum
1.4 Giá trị cốt lõi của Scrum
Minh bạch (Transparency): Mọi thông tin liên quan đến dự án đều được chia sẻ một cách
công khai và minh bạch với tất cả các thành viên trong nhóm. Không có thông tin nào
bị giấu kín hoặc không được chia sẻ.
Thanh tra (Inspection): Việc kiểm tra và đánh giá thường xuyên được thực hiện để đảm
bảo rằng công việc đang được thực hiện đúng theo kế hoạch và đạt được mục tiêu đã đề ra.
Thích nghi (Adaptation): Nhóm Scrum luôn sẵn sàng thay đổi và điều chỉnh kế hoạch
dựa trên những thông tin mới và những thay đổi trong môi trường. 1.5 Các vai trò trong Scrum
Product Owner: Là người đại diện cho khách hàng, người sử dụng hoặc những người có
nhu cầu về sản phẩm. Họ có trách nhiệm tối đa hóa giá trị của sản phẩm bằng cách quản
lý và ưu tiên các yêu cầu của khách hàng.
Scrum Master: Là một vai trò then chốt giúp nhóm Scrum làm việc hiệu quả bằng cách
tuân thủ nguyên lý, các kỹ thuật và quy tắc của Scrum. Scrum Master không phải là
người quản lý của Nhóm mà là một lãnh đạo theo phong cách phục vụ. Scrum Master
làm tất cả những gì trong thẩm quyền phục vụ Product Owner, Nhóm Phát triển, và Tổ
chức đi đến thành công. lOMoARcP SD| 58886076
Scrum Team là một nhóm tự tổ chức, đa chức năng, làm việc cùng nhau để tạo ra một
sản phẩm tăng dần trong mỗi Sprint. Scrum team bao gồm các thành viên thực hiện công
việc để hoàn thành các nhiệm vụ trong một sprint Scrum.
1.6 Các sự kiện trong Scrum
User story: là một phần không thể thiếu trong Scrum. Nó là một cách mô tả ngắn gọn,
đơn giản về một tính năng mà người dùng mong muốn có trong sản phẩm. Các User
Story sẽ được thêm vào Product Backlog và được ưu tiên trong từng Sprint. Trong Sprint
Planning, nhóm sẽ chọn các User Story từ Product Backlog và chuyển chúng thành các
Task cụ thể, sau đó thực hiện trong Development Work.
Cấu trúc cơ bản của một User Story thường gồm 3 phần:
Là một... (As a...): Xác định vai trò của người dùng. Ví dụ: "Là một khách hàng". Tôi
muốn... (I need...): Mô tả mục tiêu mà người dùng muốn đạt được. Ví dụ: "Tôi muốn tìm kiếm sản phẩm".
Để mà... (So that...): Giải thích lợi ích mà người dùng nhận được khi có tính năng này.
Ví dụ: "Để dễ dàng tìm thấy sản phẩm mình cần"
Sprint Planning (Lập kế hoạch Sprint): Xác định công việc cần làm trong một Sprint cụ thể.
Daily Scrum: Buổi gặp mặt ngắn 15 phút hằng ngày của tất cả các thành viên Nhóm
Phát triển để thanh tra và tái lập kế hoạch cho nhóm.
Sprint review: Kiểm tra, dùng thử sản phẩm, thảo luận về tình hình của sản phẩm, hướng
đi tiếp theo và thu thập phản hồi từ khách hàng.
Sprint Retrospective (Tổng kết Sprint): Cải thiện quá trình làm việc của nhóm. 1.7 Quy trình Scrum
Quy trình Scrum là một khung làm việc linh hoạt, giúp các nhóm làm việc hiệu quả và
tối ưu hóa quy trình phát triển sản phẩm. Quy trình này bao gồm nhiều bước và sự kiện
liên quan, từ lập kế hoạch, thực hiện, kiểm tra đến cải tiến.
1.7.1 Chu trình của một Sprint
Một Sprint trong Scrum kéo dài từ 2 đến 4 tuần và bao gồm các hoạt động sau: Sprint
Planning: Lập kế hoạch cho Sprint, xác định mục tiêu và các công việc cần hoàn thành.
Daily Scrum: Cuộc họp hàng ngày để đồng bộ tiến độ công việc và giải quyết các trở ngại.
Development Work: Thực hiện các công việc đã lên kế hoạch. lOMoARcP SD| 58886076
Sprint Review: Đánh giá kết quả của Sprint, trình bày sản phẩm hoàn thành và nhận phản hồi.
Sprint Retrospective: Phân tích quy trình làm việc và đưa ra các cải tiến cho Sprint tiếp theo.
1.7.2 Quy trình các bước thực hiện của Scrum
Để đảm bảo tính nhất quán và hiệu quả, quy trình Scrum được thực hiện theo các bước sau:
Bước 1: Lập Kế Hoạch Sprint
Product Owner và Development Team hợp tác để chọn các mục từ Product Backlog đưa vào Sprint Backlog.
Nhóm xác định mục tiêu của Sprint và lập kế hoạch chi tiết cho từng công việc.
Bước 2: Tthực hiện Sprint
Development Team làm việc để hoàn thành các mục trong Sprint Backlog.
Daily Scrum diễn ra mỗi ngày để cập nhật tiến độ và giải quyết các vấn đề. Bước 3: Đánh Giá Sprint
Sprint Review diễn ra vào cuối mỗi Sprint, nhóm trình bày sản phẩm đã hoàn thành cho các bên liên quan.
Nhận phản hồi từ các bên liên quan và điều chỉnh Product Backlog nếu cần.
Bước 4: Cải Tiến Quy Trình
Sprint Retrospective giúp nhóm xem xét và cải tiến quy trình làm việc.
Nhóm đưa ra các hành động cải tiến cho Sprint tiếp theo.
1.7.3 Đầu vào của quy trình
Khi bắt đầu một dự án sử dụng mô hình Scrum, đầu vào quan trọng nhất là Product
Backlog. Đây là danh sách tất cả các yêu cầu của khách hàng (User Stories - được hình
thành từ các requirement) cần thực hiện trong sản phẩm, được sắp xếp theo thứ tự ưu
tiên. Đây là nguồn tài liệu chính để lên kế hoạch cho các Sprint.
Đầu vào cho từng sprint:
Sprint Backlog: Là danh sách các công việc được lựa chọn từ Product Backlog, dựa trên
mục tiêu Sprint và khả năng của nhóm. Định hướng các nhiệm vụ cần thực hiện trong
Sprint. Đây là tài liệu chính để nhóm phát triển hoàn thành mục tiêu của Sprint.
Phản hồi từ khách hàng và các bên liên quan: Thu thập phản hồi thực tế từ khách hàng,
người dùng cuối, hoặc các bên liên quan sau khi sản phẩm được triển khai hoặc kiểm lOMoARcP SD| 58886076
thử. Giúp điều chỉnh mục tiêu hoặc phát hiện lỗi nhanh chóng. Đảm bảo sản phẩm phù
hợp với nhu cầu thực tế và kịp thời đáp ứng mong muốn của khách hàng.
Dữ liệu từ các Sprint trước: Bao gồm bài học kinh nghiệm, các công việc chưa hoàn
thành, hoặc những khó khăn gặp phải trong các Sprint trước. Hỗ trợ cải thiện năng suất
và hiệu quả. Đưa ra hướng giải quyết các vấn đề tồn đọng để tối ưu quy trình làm việc.
Sprint Planning: Phiên họp đầu tiên của Sprint, nơi đội phát triển, Product Owner và
Scrum Master cùng thảo luận để quyết định các công việc sẽ được thực hiện. Xác định
rõ ràng các công việc cần làm và lên kế hoạch hợp lý. Đảm bảo tất cả các thành viên
hiểu mục tiêu và phạm vi công việc của Sprint.
Sprint Goal: Mục tiêu cụ thể mà nhóm muốn đạt được trong Sprint. Hướng dẫn đội nhóm
tập trung vào nhiệm vụ chính, tránh phân tán công việc. Đo lường thành công của Sprint
dựa trên việc hoàn thành Sprint Goal.
1.7.4 Đầu ra của quy trình
Quy trình Scrum tạo ra một sản phẩm phát triển liên tục thông qua nhiều Sprint. Đầu ra
cuối cùng của quy trình là một sản phẩm hoàn chỉnh hoặc tính năng đáp ứng được các
yêu cầu và sẵn sàng đưa vào sử dụng. Đây là mục tiêu chính của toàn bộ quy trình
Scrum, mang lại giá trị thực tế cho khách hàng và người dùng. Đầu ra của mỗi Sprint:
Increment: Một phiên bản hoạt động của sản phẩm, bao gồm các tính năng mới hoặc cải
tiến của phần mềm được xây dựng trong Sprint, có thể sẵn sàng để phát hành hoặc sử
dụng ngay. Mang lại giá trị thực tế và thể hiện tiến độ của dự án.
Sprint Backlog: Danh sách các nhiệm vụ đã hoàn thành hoặc còn dang dở trong Sprint
trước. Sprint Backlog thường được sử dụng để đánh giá hiệu quả làm việc và cung cấp
tài liệu tham khảo để tối ưu hóa hiệu suất trong các Sprint tiếp theo.
Sprint Review: Là buổi họp cuối Sprint, nơi nhóm trình bày kết quả công việc cho các
bên liên quan để nhận phản hồi. Kiểm tra xem sản phẩm có đáp ứng được yêu cầu và kỳ
vọng không. Hỗ trợ điều chỉnh Product Backlog và xác định ưu tiên cho Sprint tiếp theo.
Sprint Retrospective: Một cuộc họp nội bộ giữa các thành viên Scrum để thảo luận về
những gì đã làm tốt và cần cải thiện trong Sprint tiếp theo.
1.8 Công cụ hỗ trợ quản lý dự án theo mô hình Scrum JIRA:
Công cụ quản lý dự án và theo dõi lỗi. lOMoARcP SD| 58886 076 Hình 2: JIRA
Asana: Công cụ quản lý công việc, dễ sử dụng và miễn phí cho nhóm nhỏ. Hình 3: Asana
Trello: Bảng quản lý công việc trực quan theo phong cách Kanban. Hình 4: Trello lOMoARcP SD| 58886076
CHƯƠNG 2: TÌM HIỂU VỀ DỰ ÁN “ỨNG DỤNG ĐẶT PHÒNG KHÁCH SẠN TRỰC TUYẾN” 2.1 Tổng quan về dự án
Tên dự án: Ứng dụng Đặt Phòng Khách Sạn Trực Tuyến (Hotel Booking App). Mô tả:
Dự án "Ứng dụng Đặt Phòng Khách Sạn Trực Tuyến" là một hệ thống phần mềm cho
phép người dùng đặt phòng khách sạn trực tuyến thông qua một nền tảng website hoặc ứng dụng di động. Mục tiêu:
Cung cấp giải pháp đặt phòng nhanh chóng, tiện lợi cho khách hàng cá nhân.
Tạo nền tảng quản lý hiệu quả cho các chủ khách sạn.
Tạo nền tảng quản lý hiệu quả cho các chủ khách sạn.
Tiết kiệm thời gian tìm kiếm và đặt phòng cho khách hàng.
Nâng cao khả năng tiếp cận khách hàng và tối ưu hóa vận hành cho khách sạn. 2.2 Phạm vi dự án Chức năng chính:
Tìm kiếm khách sạn: Theo vị trí, giá cả, tiện nghi, hoặc đánh giá.
Đặt phòng trực tuyến: Chọn phòng, xác nhận thông tin, và thanh toán ngay trên ứng dụng. Quản lý tài khoản:
+ Người dùng: Lịch sử đặt phòng, cập nhật thông tin cá nhân.
+ Chủ khách sạn: Quản lý tình trạng phòng, giá cả, và lịch sử đặt phòng.
Thông báo tự động: Xác nhận đặt phòng, nhắc nhở cận ngày, và thông báo ưu đãi. Hỗ
trợ đa ngôn ngữ và đa phương thức thanh toán: Thẻ tín dụng, ví điện tử (Momo,
ZaloPay), và chuyển khoản ngân hàng.
Hướng phát triển trong tương lai:
Đặt vé máy bay hoặc tour du lịch.
Gợi ý khách sạn bằng AI dựa trên thói quen người dùng (triển khai ở giai đoạn sau). 2.3 Yêu cầu của dự án
2.3.1 Yêu cầu người dùng Đối tượng người dùng:
Người dùng (khách hàng): lOMoARcP SD| 58886076
Tìm kiếm và đặt phòng khách sạn dễ dàng, tiết kiệm thời gian, hiển thị thông tin minh
bạch (giá, tiện nghi, chính sách).
Dễ sử dụng, giao diện thân thiện.
Thanh toán an toàn và linh hoạt. Chủ khách sạn:
Quản lý phòng, giá cả và kiểm tra lịch sử đặt phòng một cách tiện lợi.
Báo cáo doanh thu và trạng thái phòng nhanh chóng. 2.3.2 Yêu cầu kĩ thuật Backend:
Ngôn ngữ lập trình: Node.js/Express.js.
Cơ sở dữ liệu: PostgreSQL hoặc MongoDB.
Quản lý trạng thái: Redis (để caching và quản lý phiên đăng nhập). Frontend: Giao diện web: React.js.
Ứng dụng di động: React Native (hỗ trợ cả iOS và Android). API tích hợp:
Google Maps API (định vị khách sạn).
Stripe/PayPal API (thanh toán trực tuyến). Hạ tầng:
AWS (Amazon Web Services) hoặc Google Cloud Platform cho khả năng mở rộng và vận hành.
CI/CD: Jenkins hoặc GitLab CI/CD để triển khai nhanh. Bảo mật:
Mã hóa TLS/SSL, sử dụng JWT cho quản lý phiên.
Tuân thủ các tiêu chuẩn PCI DSS cho giao dịch thanh toán.
2.3.3 Yêu cầu hiệu suất Thời gian phản hồi:
Các thao tác quan trọng (tìm kiếm, đặt phòng, thanh toán) phải hoàn thành trong vòng 2-3 giây.
Giao diện phải tải hoàn chỉnh trong dưới 1 giây đối với kết nối mạng thông thường.
Khả năng xử lý đồng thời: lOMoARcP SD| 58886076
Hệ thống cần hỗ trợ ít nhất 5000 người dùng đồng thời trong giai đoạn đầu và có thể mở
rộng để hỗ trợ 10.000+ người dùng trong tương lai. Dung lượng lưu trữ:
Lưu trữ lịch sử đặt phòng và dữ liệu khách sạn trong tối thiểu 5 năm mà không gây ra suy giảm hiệu suất. Khả năng chịu lỗi:
Hệ thống phải duy trì thời gian hoạt động (uptime) trên 99.9%, với cơ chế phát hiện lỗi
tự động và chuyển đổi dự phòng.
Tối ưu hóa bộ nhớ và băng thông:
Sử dụng kỹ thuật nén dữ liệu và caching để giảm thiểu sử dụng băng thông, tăng tốc độ phản hồi. Kiểm tra tải:
Ứng dụng sẽ được kiểm tra tải với các công cụ như JMeter hoặc Gatling để đảm bảo
hiệu suất ổn định ngay cả khi có lưu lượng cao đột biến. 2.4 Lịch trình thời gian
Giai đoạn 1: Thu thập yêu cầu và lập kế hoạch (1 tháng).
Giai đoạn 2: Thiết kế hệ thống và giao diện (2 tháng).
Giai đoạn 3: Phát triển backend và frontend (4 tháng).
Giai đoạn 4: Tích hợp API và kiểm thử (2 tháng).
Giai đoạn 5: Triển khai và vận hành (1 tháng).
Tổng thời gian: 10 tháng. 2.5 Chi phí cho dự án Chi phí phát triển:
Backend & Frontend: $50,000 - $70,000.
Hạ tầng và vận hành: $10,000/năm.
Thiết kế và marketing: $15,000.
Tổng chi phí ước tính ban đầu: $75,000 - $100,000.
Duy trì và nâng cấp: $10,000 - $20,000/năm. 2.6 Nhân lực cho dự án
Dự án cần khoảng 15 người, chia thành các nhóm theo vai trò và trách nhiệm cụ thể.
Quản lý và điều phối: 2 người
Nhóm phát triển phần mềm: 9 người lOMoARcP SD| 58886076
Nhóm kiểm thử : 2 người
Nhóm vận hành và hỗ trợ: 2 người lOMoARcP SD| 58886076
CHƯƠNG 3: CÁCH CHỌN MÔ HÌNH SCRUM CHO DỰ ÁN “ỨNG DỤNG ĐẶT
PHÒNG KHÁCH SẠN TRỰC TUYẾN” 3.1 Tổng quan
Việc chọn một mô hình phù hợp cho mỗi dự án là rất quan trọng. Vì mỗi dự án có các
đặc điểm, mục tiêu và yêu cầu riêng biệt nên một mô hình phù hợp sẽ giúp dự án đạt
được hiệu quả tối ưu, tiết kiệm thời gian và chi phí, đồng thời đảm bảo chất lượng và
tiến độ. Trong quá trình tìm hiểu về mô hình quản lý dự án, nhóm em đã nghiên cứu và
so sánh nhiều mô hình khác nhau để xác định mô hình nào phù hợp nhất cho dự án "Ứng
dụng Đặt Phòng Khách Sạn Trực Tuyến".
Dự án "Ứng dụng Đặt Phòng Khách Sạn Trực Tuyến" cần một mô hình quản lý dự án
linh hoạt để có thể đáp ứng các yêu cầu thay đổi liên tục từ khách hàng, người dùng và
thị trường. Dự án này có các đặc điểm quan trọng như sự phát triển nhanh chóng của
tính năng, thay đổi liên tục về giao diện người dùng, cập nhật chính sách khách sạn, và
sự cần thiết phải tích hợp các dịch vụ mới (như vé máy bay, tour du lịch). Vì vậy, một
mô hình quản lý dự án cứng nhắc như Waterfall hay V-Model sẽ khó có thể đáp ứng yêu
cầu thay đổi linh hoạt và phát triển nhanh chóng của dự án.
Do đó, mô hình Scrum là lựa chọn tối ưu cho dự án "Ứng dụng Đặt Phòng Khách Sạn
Trực Tuyến" vì tính linh hoạt cao, khả năng thay đổi theo yêu cầu và tiến độ nhanh
chóng với các sprint ngắn, phù hợp với nhu cầu thay đổi tính năng liên tục trong dự án
này. Để hiểu rõ hơn việc vì sao chọn mô hình Scrum, nhóm em đã phân tích theo các
tiêu chí như dưới đây.
3.2 Phân tích các tiêu chí để chọn mô hình phát triển phần mềm cho dự án "Ứng dụng
Đặt Phòng Khách Sạn Trực Tuyến"
3.2.1. Khách hàng có hiểu hết các yêu cầu (mong đợi của họ) về phần mềm không?
Khách hàng đã hiểu rõ các yêu cầu cơ bản của ứng dụng, bao gồm: tính năng tìm kiếm
khách sạn theo vị trí, giá cả, tiện nghi và đánh giá, khả năng đặt phòng trực tuyến, thanh
toán an toàn và quản lý tài khoản cá nhân. Tuy nhiên, các yêu cầu có thể thay đổi hoặc
bổ sung trong suốt quá trình phát triển, đặc biệt là khi triển khai các tính năng bổ sung
như AI để gợi ý khách sạn, tích hợp dịch vụ tour du lịch hoặc vé máy bay. Sự thay đổi
này đòi hỏi khách hàng phải liên tục cập nhật và đồng thuận với nhóm phát triển về các
tính năng mới hoặc điều chỉnh. Do đó, nếu chọn mô hình Scrum để quả dự án này thì lOMoARcP SD| 58886076
scrum sẽ cho phép khách hàng tham gia liên tục và đưa ra phản hồi về yêu cầu trong
từng sprint. Điều này giúp đáp ứng nhanh chóng các thay đổi và bổ sung yêu cầu, đảm
bảo phần mềm phát triển đúng với mong đợi của khách hàng.
Đối với các mô hình khác: -
Waterfall: Mô hình Waterfall yêu cầu phải được xác định rõ ràng ngay từ đầu
vàkhông thay đổi trong suốt quá trình phát triển. Điều này có thể gây khó khăn khi khách
hàng muốn thay đổi hoặc bổ sung yêu cầu trong khi dự án đang triển khai. -
V-Shaped: Giống như Waterfall, mô hình V-Shaped yêu cầu các giai đoạn phát
triểnphải hoàn thành tuần tự và không thể thay đổi yêu cầu một cách linh hoạt. Điều này
không phù hợp với nhu cầu thay đổi yêu cầu của khách hàng trong suốt quá trình phát triển. -
Spiral: Mô hình Spiral có khả năng linh hoạt hơn, cho phép thay đổi và bổ sung
yêucầu trong các vòng lặp. Tuy nhiên, quy trình này khá phức tạp và tốn kém, không
phải là lựa chọn tối ưu cho một dự án có yêu cầu thay đổi nhanh chóng nhưng không
đòi hỏi quá trình phân tích rủi ro sâu. -
Iterative and Incremental: Mặc dù mô hình này có sự thay đổi trong từng vòng
lặp,nhưng thiếu sự rõ ràng và kiểm soát như Scrum. Điều này có thể dẫn đến sự không
nhất quán trong yêu cầu và gây khó khăn trong việc theo dõi tiến độ.
3.2.2. Làm thế nào khách hàng có thể tham gia vào quá trình phát triển phần mềm? Với
tính thay đổi về yêu cầu khách hàng nên đòi hỏi dự án phải có sự tham gia của khách
hàng trong quá trình phát triển dự án. Do đó, Scrum là mô hình phù hợp để áp dụng
trong trường hợp này. Khi áp dụng mô hình Scrum, khách hàng có thể tham gia vào quá
trình phát triển phần mềm thông qua các cuộc họp định kỳ như Sprint Review và Sprint
Planning. Trong các cuộc họp này, nhóm phát triển sẽ trình bày những tính năng đã hoàn
thành trong sprint trước và nhận phản hồi từ khách hàng về những thay đổi hoặc bổ sung
cần thiết. Ngoài ra, khách hàng có thể tham gia vào giai đoạn kiểm thử người dùng để
đảm bảo tính năng phần mềm phù hợp với mong muốn và nhu cầu thực tế của họ. Cụ thể hơn:
Khách hàng tham gia qua vai trò Product Owner: Product Owner là đại diện của khách
hàng, làm việc trực tiếp với đội phát triển để quản lý Product Backlog, xác định yêu cầu và ưu tiên chúng. lOMoARcP SD| 58886076
Tương tác định kỳ qua Sprint Review: Khách hàng tham dự các buổi Sprint Review để
đánh giá kết quả của từng Sprint. Điều này đảm bảo khách hàng có thể kiểm tra sản
phẩm thực tế và đưa ra phản hồi kịp thời.’
Phản hồi liên tục: Scrum khuyến khích sự tương tác thường xuyên giữa đội phát triển
và khách hàng thông qua các cuộc họp định kỳ và giao tiếp mở. Để biết rõ cần có những
thay đổi gì khi khách hàng đưa ra.
Đối với các mô hình khác: -
Waterfall: Mô hình Waterfall có quy trình phát triển tuần tự và yêu cầu các yêucầu
phải được xác định và hoàn thành từ đầu. Khách hàng khó có thể tham gia vào quá trình
phát triển sau khi các yêu cầu đã được xác định, điều này hạn chế sự linh hoạt trong việc thay đổi yêu cầu. -
V-Shaped: Mô hình V-Shaped yêu cầu các giai đoạn phát triển phải hoàn
thànhtuần tự và không có sự tham gia của khách hàng trong suốt quá trình phát triển.
Do đó, khách hàng sẽ không có cơ hội đưa ra phản hồi trong khi sản phẩm đang được
phát triển, gây khó khăn cho việc điều chỉnh phần mềm. -
Spiral: Mô hình Spiral cho phép khách hàng tham gia vào các giai đoạn pháttriển
thông qua việc phân tích rủi ro và điều chỉnh yêu cầu, nhưng quá trình này phức tạp và
tốn kém, không phù hợp với nhu cầu tham gia liên tục và nhanh chóng của khách hàng. -
Iterative and Incremental: Mô hình này có vòng lặp để khách hàng tham gia
vàđiều chỉnh yêu cầu trong các giai đoạn phát triển. Tuy nhiên, thiếu sự kiểm soát và rõ
ràng trong các giai đoạn phát triển, dễ dẫn đến sự không nhất quán trong yêu cầu và tiến
độ, điều này có thể gây khó khăn cho khách hàng trong việc theo dõi và tham gia đầy đủ.
3.2.3 Yêu cầu của phần mềm có rõ ràng và ổn định không ?
Các yêu cầu phần mềm trong dự án đã được xác định khá rõ ràng, bao gồm các tính năng
chính như tìm kiếm khách sạn, đặt phòng, quản lý tài khoản người dùng, và thanh toán
trực tuyến. Tuy nhiên, do dự án yêu cầu tính linh hoạt cao (ví dụ, khả năng thêm các
dịch vụ mới như vé máy bay, tour du lịch), các yêu cầu có thể thay đổi trong quá trình
phát triển. Vì vậy, yêu cầu không hoàn toàn ổn định và cần có sự điều chỉnh trong suốt
vòng đời dự án. Trong khi đó, Scrum không yêu cầu phần mềm phải rõ ràng và ổn định lOMoARcP SD| 58886076
ngay từ đầu. Scrum cho phép thay đổi và điều chỉnh yêu cầu một cách linh hoạt trong
suốt quá trình phát triển nên Scrum là lựa chọn tốt nhất.
Đối với các mô hình khác:
Đối với các mô hình khác: Waterfall: Không phù hợp vì yêu cầu phải được xác định rõ
ràng và ổn định từ đầu, không cho phép thay đổi linh hoạt trong quá trình phát triển. V-
Shaped: Cũng không phù hợp vì yêu cầu cần được xác định hoàn toàn trước khi bắt đầu
phát triển và không dễ dàng thay đổi trong suốt quá trình.
Spiral: Mặc dù cho phép thay đổi yêu cầu, nhưng Spiral quá phức tạp và yêu cầu phân
tích rủi ro thường xuyên, không tối ưu cho dự án này.
Iterative and Incremental: Mặc dù có thể thay đổi yêu cầu qua các vòng lặp, nhưng thiếu
sự kiểm soát rõ ràng như Scrum, có thể dẫn đến thiếu nhất quán trong yêu cầu và tiến độ.
3.2.4 Quy mô, kỹ năng, khả năng kỹ thuật phần mềm và sự phù hợp của nhóm phát tri
ển cho dự án phần mềm?
Đội ngũ phát triển của dự án gồm 9 người, bao gồm các lập trình viên backend, frontend,
kiểm thử và chuyên gia quản lý dự án. Các thành viên trong đội ngũ có kỹ năng và kinh
nghiệm phù hợp để phát triển ứng dụng với các công nghệ như Node.js, Express.js,
React.js, và React Native. Đội ngũ này có khả năng phát triển hệ thống với chất lượng
cao, đảm bảo tính tương thích giữa các nền tảng và có thể mở rộng ứng dụng trong tương
lai. Tuy nhiên, đội ngũ sẽ cần bổ sung các chuyên gia về AI và dữ liệu lớn khi triển khai
các tính năng như gợi ý khách sạn hoặc dự đoán nhu cầu. Đội ngũ phát triển của dự án
"Ứng dụng Đặt Phòng Khách Sạn Trực Tuyến" cần có sự phối hợp nhịp nhàng và có đủ
kỹ năng để phát triển các tính năng phức tạp, bao gồm cả backend, frontend và tích hợp
API. Do đó, Scrum được chọn cho dự án vì tính linh hoạt, cho phép thay đổi yêu cầu và
ưu tiên nhanh chóng trong các Sprint ngắn. Mô hình này cũng giúp đội ngũ tự quản lý
và phối hợp hiệu quả, thích ứng với thay đổi nhanh. Với Scrum, việc phát triển và kiểm
thử tính năng diễn ra nhanh chóng, đảm bảo tiến độ và dễ dàng điều chỉnh khi có thay đổi yêu cầu.
Đối với các mô hình khác:
Waterfall: Quy trình cứng nhắc, khó thay đổi yêu cầu trong suốt phát triển. Không linh
hoạt trong việc quản lý nhóm nhỏ và phát triển nhanh chóng. lOMoARcP SD| 58886076
V-Shaped: Cần hoàn thành từng giai đoạn tuần tự, không dễ điều chỉnh yêu cầu và thay
đổi nhanh chóng, thiếu tính linh hoạt.
Spiral: Quá phức tạp và chi phí cao, yêu cầu đội ngũ có kỹ năng phân tích rủi ro cao,
không phù hợp với dự án cần phát triển nhanh và chi phí hợp lý.
Iterative and Incremental: Có vòng lặp nhưng thiếu sự kiểm soát rõ ràng như Scrum,
khó theo dõi tiến độ và dễ bị thiếu sự rõ ràng trong yêu cầu.
3.2.5 Mô hình nào phù hợp với công nghệ được chọn để triển khai giải pháp? Dự án sẽ
sử dụng các công nghệ như Node.js, React, AWS,... tất cả đều yêu cầu khả năng phản
hồi nhanh và thay đổi linh hoạt trong quá trình phát triển.
Scrum rất phù hợp với công nghệ thay đổi nhanh và yêu cầu phản hồi liên tục từ khách
hàng. Việc sử dụng các công cụ và công nghệ hiện đại như React, AWS là lý tưởng để
triển khai trong môi trường Scrum. Cụ thể:
Node.js/Express.js, React.js/React Native: Scrum giúp phát triển và điều chỉnh tính năng
nhanh chóng qua các Sprint ngắn, phù hợp với các công nghệ cần sự linh hoạt và thay đổi liên tục.
PostgreSQL/MongoDB, Redis: Scrum cho phép thay đổi và mở rộng cơ sở dữ liệu, quản
lý trạng thái linh hoạt trong từng Sprint, đảm bảo hiệu suất tốt.
Google Maps API, Stripe/PayPal: Scrum giúp tích hợp và thử nghiệm các API này nhanh
chóng và liên tục, đảm bảo tính năng hoạt động ổn định.
AWS, CI/CD: Scrum giúp triển khai và mở rộng hệ thống trên AWS, đồng thời tối ưu
hóa quy trình CI/CD để phát triển nhanh và hiệu quả.
Bảo mật (TLS/SSL, JWT, PCI DSS): Scrum hỗ trợ phát triển và kiểm thử các tính năng
bảo mật liên tục, đảm bảo tuân thủ các tiêu chuẩn an toàn.
Đối với các mô hình khác:
Waterfall: Không linh hoạt, khó thay đổi yêu cầu trong quá trình phát triển.
V-Shaped: Khó điều chỉnh và phát triển nhanh chóng, yêu cầu các giai đoạn phải hoàn thành tuần tự.
Spiral: Quá phức tạp và chi phí cao, không cần thiết cho dự án này.
Iterative and Incremental: Mặc dù có vòng lặp nhưng thiếu sự rõ ràng và kiểm soát như Scrum.
3.2.6 Mối quan tâm và ưu tiên của khách hàng và các bên liên quan là gì? lOMoARcP SD| 58886076
Khách hàng quan tâm đến trải nghiệm người dùng, bao gồm giao diện trực quan, tốc độ
xử lý nhanh, hỗ trợ đa nền tảng và khả năng tìm kiếm linh hoạt. Họ cũng ưu tiên bảo
mật thông tin cá nhân, tích hợp thanh toán trực tuyến an toàn và đảm bảo ứng dụng được
hoàn thiện trong thời gian ngắn với chi phí hợp lý. Đồng thời, các bên liên quan như nhà
quản lý khách sạn mong muốn hệ thống hỗ trợ tích hợp với công cụ hiện có, cung cấp
báo cáo kinh doanh chi tiết và dự đoán xu hướng. Người dùng cuối cần ứng dụng hoạt
động ổn định, dễ sử dụng, trong khi nhà đầu tư mong muốn sản phẩm mang lại lợi ích
cao và có khả năng mở rộng. Nếu sử dụng mô hình Scrum thì có thể phát triển phần
mềm theo từng Sprint, đảm bảo rằng các ưu tiên này được thực hiện nhanh chóng và kịp
thời. Scrum cũng cho phép các yêu cầu ưu tiên của khách hàng được thay đổi và điều
chỉnh qua từng sprint, đảm bảo rằng ưu tiên của khách hàng luôn được đáp ứng. Đối với các mô hình khác:
Waterfall: Các ưu tiên của khách hàng chỉ có thể được điều chỉnh sau khi đã xác định
yêu cầu ban đầu, dẫn đến ít sự linh hoạt trong việc thay đổi ưu tiên.
Iterative and Incremental: Hỗ trợ thay đổi ưu tiên qua các vòng lặp, nhưng việc kiểm
soát và phản hồi yêu cầu không nhanh nhạy như Scrum.
V-Shaped: Phù hợp khi yêu cầu rõ ràng và ít thay đổi, nhưng không thể đáp ứng hiệu
quả các yêu cầu điều chỉnh trong quá trình phát triển.
Spiral: Cho phép thay đổi và cải tiến linh hoạt, phù hợp với yêu cầu thay đổi liên tục.
Tuy nhiên, mô hình này phức tạp và chi phí cao hơn so với Scrum.
3.2.7 Loại, kích thước và độ phức tạp của phần mềm là gì?
Đây là một ứng dụng thuộc loại hệ thống giao dịch trực tuyến, với yêu cầu xử lý đồng
thời số lượng lớn người dùng và thao tác như tìm kiếm phòng, đặt phòng, thanh toán,
và quản lý thông tin khách hàng. Kích thước của dự án ở mức trung bình đến lớn, do
cần tích hợp nhiều tính năng, bao gồm hỗ trợ đa nền tảng (web và di động), bảo mật
thanh toán trực tuyến và kết nối với hệ thống quản lý của các khách sạn. Độ phức tạp
tăng cao bởi tính năng tìm kiếm nâng cao, lọc theo nhiều tiêu chí, tích hợp các cổng
thanh toán, và yêu cầu về bảo mật dữ liệu người dùng.
Với đặc điểm như vậy, mô hình phát triển phần mềm cần linh hoạt để xử lý yêu cầu thay
đổi thường xuyên và cho phép kiểm thử từng phần sớm. Scrum sẽ phù hợp, vì chúng