Phát triển website bán điện thoại di động cho cửa hàng điện thoại Tiến Đạt

lOMoAR cPSD| 45349271
TRƯỜNG Đ䄃⌀I H伃⌀C CÔNG NGHÊ THÔNG TIN V䄃 TRUY쨃N THÔNG̣
KHOA CÔNG NGHỆ THÔNG TIN
BÁO CÁO B䄃I TẬP NHÓM
MÔN H伃⌀C: NHẬP MÔN CÔNG NGHỆ PHẦN M쨃M
Đ쨃 T䄃I: PHÁT TRIÊN WEBSITE BÁN ĐIỆN THO䄃⌀I DI ĐỘNG CHO CỬA
H䄃NG ĐIỆN THO䄃⌀I TIẾN Đ䄃⌀T Giảng viên Nguyễn Thị Dung
Sinh viên thực hiện Triệu La Huỳnh (Nhóm trưởng) Vi Văn Hoàng Nguyễn Duy Bình Đỗ Mạnh Hùng Nguyễn Trung Thành Lớp: CNTT K20R N14 lOMoAR cPSD| 45349271 Lời giới thiệu
Ngày này trong nhịp sống hối hả của con người thì việc giành thời gian để ra ngoài
để mua sắm trở nên là 1 điều quá xa sỉ.. Những lo lắng về giao thông không an toàn và hạn
chế trong việc mua hàng truyền thống có thể tránh được trong khi mua sắm trực tuyến. Với
mua sắm trực tuyến(online), bạn cũng không cần phải lo lắng về điều kiện thời tiết. Người
tiêu dùng và các khách hàng là những tổ chức, công ty,… đang dần chuyển sang mua sắm
trực tuyến nhiều hơn nhằm tiết kiệm thời gian
Chính vì thế việc mua sắm online càng trở nên quan trọng và cần thiết,chỉ cần 1 cú
click chuột thì họ có thể có được sản phẩm mà mình mong muốn.Việc mua sắm online có
nhiều ưu điểm là có thể sở hữu mọi thứ thông qua các cú click chuột chứ không cần phải
đến tận nơi để mua hàng. Sau khi vào website bán hàng, chọn sản phẩm, chỉ cần đặt hàng
(order) người bán sẽ mang sản phẩm đến tận nhà bạn. Mua sắm online cho phép mua hàng
bất cứ khi nào bạn muốn. Các cửa hang trên mạng không bao giờ đóng cửa, có thể mua
sắm 24/24 giờ và 7 ngày trong tuần. Mua sắm ở các chợ, trung tâm thương mại hay cửa
hàng rất khó để bạn có thể so sánh đặc điểm và giá của sản phẩm với nhau. Khi mua hàng
online, bạn dễ dàng so sánh và đưa ra lựa chọn sản phẩm phù hợp nhất. Đôi khi bạn gặp
phải những người bán hàng khó tính tại một số địa điểm bán hàng. Mua sắm online thì
khách hàng chẳng phải để ý đến chuyện ấy nữa. Vậy nên nhóm chúng em đã lựa chọn đề
tài xây dựng một website bán hàng cho một cửa hàng. MỤC LỤC
CHƯƠNG 1: TỔNG QUAN V쨃 QUY TRÌNH PHÁT TRIỂN PHẦN
M쨃M.......................................3
1.1. Quy trình ph愃Āt triển phần mềm.........................................................................3
1.1.1. Quy trình ph愃Āt triển phần mềm là gì?...................................................3
1.1.2. Một số quy trình cho ph愃Āt triển phần mềm..........................................6 1.2.
Mô hình Agile quy trình Scrum........................................................................12 1.2.1.
Agile là gì?............................................................................................12 1.2.2.
Ưu nhược điểm của Agile.....................................................................12 1.2.3.
Tuyên ngôn Agile..................................................................................13 1.2.4.
Đặc trưng của Agile..............................................................................13 1.2.5.
Các phương pháp phát triển phần mềm theo mô hình Agile................15 1.2.6.
Scrum là gì?..........................................................................................16 1 lOMoAR cPSD| 45349271 1.2.7.
Đặc điểm của SCRUM..........................................................................16 1.2.8.
Ưu nhược điểm của mô hình Scrum....................................................17
1.2.9. C愃Āc nhân tố tạo nên 1 quy trình Scrum..............................................17
1.2.10. Tổ chức dự 愃Ān (Organization)..............................................................18
1.2.11. Tài liệu (atifacts)...................................................................................19
1.2.12. Quy trình (process)...............................................................................19 CHƯƠNG 2: LẬP KẾ
HO䄃⌀CH..............................................................................................................21
2.1. Ph愃Āt triển phần mềm theo mô hình..................................................................21 2.2.
Thiết kế theo cấu trúc........................................................................................21 2.3.
Phạm vi...............................................................................................................22 2.4.
Thời gian............................................................................................................22 2.5.
Kinh phí..............................................................................................................22 2.6.
Nhân sự...............................................................................................................22 2.7.
Chi tiết công việc:..............................................................................................22
2.8. Kết quả dự kiến.................................................................................................23
2.9. Phân tích rủi ro dự
愃Ān.......................................................................................23
CHƯƠNG 3: ĐẶC TẢ PHẦN M쨃M......................................................................................................25 3.1.
Đặc tả phần mềm...............................................................................................25
3.1.1. Khảo s愃Āt hệ thống.................................................................................25
3.1.2. Đ愃Ānh gi愃Ā hiện
trạng..............................................................................25 3.1.3. Ph愃Āt biểu bài
to愃Ān.................................................................................26
CHƯƠNG 4: PHÂN TÍCH THIẾT KẾ WEBSITE BÁN ĐIỆN THO䄃⌀I DI
ĐỘNG..........................30 4.1.
Phân tích thiết kế hệ thống...............................................................................30 4.1.1.
Biểu đồ use case....................................................................................30 4.1.2.
Biểu đồ trình tự....................................................................................47
4.1.3. Biểu đồ cộng t愃Āc....................................................................................54 4.1.4.
Biểu đồ lớp chi tiết................................................................................63 4.2.
Thiết kế qua hình vẽ..........................................................................................63 2 lOMoAR cPSD| 45349271
4.2.1. Thiết kế giao diện bên người dùng......................................................64
4.2.2. Thiết kế giao diện bên admin...............................................................66
CHƯƠNG 5: C䄃I ĐẶT DEMO..............................................................................................................69 5.1.
Giao diện người dùng........................................................................................69 5.2.
Giao diện admin.................................................................................................71 5.3.
Kiểm thử.............................................................................................................73 5.3.1.
Kỹ thuật kiểm thử................................................................................73 5.3.2.
Kiểm thử đặt hàng................................................................................74 5.3.3.
Kiểm thử tìm kiếm điện thoại..............................................................75 5.4.
Kế hoạch bảo trì bảo dưỡng.............................................................................76 Tài liệu tham
khảo...............................................................................................................................77 KẾT
LUẬN..........................................................................................................................................77
CHƯƠNG 1: TỔNG QUAN V쨃 QUY TRÌNH PHÁT TRIỂN PHẦN M쨃M
1.1.Quy trình ph愃Āt triển phần mềm
1.1.1. Quy trình ph愃Āt triển phần mềm là gì?
- Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác và các
kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sản phẩm phần
mềm. Nhìn chung, một quy trình phát triển phần mềm bao gồm các giai đoạn như
sau: a. Đặc tả phần mềm
- Nhiệm vụ: Thực hiện khảo sát chi tiết yêu cầu của khách hàng để từ đó tổng hợp vào
tài liệu giải pháp. Tài liệu này phải mô tả đầy đủ các yêu cầu về chức năng, phi chức năng và giao diện.
- Kết quả: Đầu ra của giai đoạn này là Tài liệu đặc tả yêu cầu
- Đặc tả phần mềm (hay còn gọi là kỹ thuật xác định yêu cầu) là quy trình tìm hiểu và
định nghĩa những dịch vụ nào được khách hàng yêu cầu và các ràng buộc trong quá
trình vận hành và xây dựng hệ thống.
Quy trình xác định yêu cầu bao gồm bốn pha chính:
- Nghiên cứu tính khả thi: Nghiên cứu tính khả thi giúp xác định những yêu cầu của
người sử dụng có thoả mãn những công nghệ hiện tại hay không. Về góc độ kinh
doanh, nghiên cứu khả thi nhằm xác định hệ thống đưa ra có mang lại lợi nhuận 3 lOMoAR cPSD| 45349271
không. Việc nghiên cứu khả thi nên được thực hiện một cách nhanh chóng và không
quá tốn kém. Kết quả của việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây
dựng hệ thống nữa hay không.
- Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các yêu cầu hệ thống thông
qua một số phương pháp như: quan sát hệ thống hiện tại, phỏng vấn và thảo luận với
người sử dụng, phân tích nhiệm vụ, phân tích tài liệu hoặc hệ thống cũ … Trong pha
này, chúng ta có thể phải xây dựng một hoặc nhiều mô hình hệ thống và các mẫu thử.
- Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập được. Có hai loại
yêu cầu cần được xác định: •
Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự nhiên. Kiểu yêu cầu
này được viết bởi người sử dụng. •
Yêu cầu hệ thống: là những tài liệu có cấu trúc, đươc mô hình hoá, mô tả chi tiết về
các chức năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống sẽ
định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành bản hợp đồng giữa
khách hàng và nhà thầu. Các yêu cầu hệ thống được chia làm 2 loại:
- Các yêu cầu hệ thống chức năng: Là các dịch vụ mà hệ thống phải cung cấp
- Các yêu cầu phi chức năng: Là các ràng buộc mà hệ thống phải tuân theo
- Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có đúng thực tế hay
không, có thống nhất không, có đầy đủ không. Nếu phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này
Hình 1.1: Quy trình xác định yêu cầu 4 lOMoAR cPSD| 45349271 a. Thiết kế
Nhiệm vụ: Thực hiện thiết kế và tổng hợp vào tài liệu thiết kế.
Kết quả: Tài liệu thiết kế tổng thể, thiết kế module, thiết kế CSDL
- Là quá trình thiết kế cấu trúc phần mềm dựa trên những tài liệu đặc tả. Hoạt động
thiết kế bao gồm những công việc chính sau:
- Thiết kế kiến trúc: Thiết kế các hệ thống con cấu thành lên hệ thống cần xây dựng
và mối quan hệ giữa chúng được xác định và tư liệu hoá.
- Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về các dịch vụ của
nó và những ràng buộc khi nó vận hành.
- Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những hệ thống
con khác phải được thiết kế và tư liệu hoá.
- Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các giao diện
tương tác với chúng phải được thiết kế.
- Thiết kế cấu trúc dữ liệu (thiết kế dữ liệu): cấu trúc dữ liệu được sử dụng để cài đặt
hệ thống phải được thiết kế một cách chi tiết và cụ thể.
- Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ phải được
thiết kế chi tiết và chính xác.
Hình 1.2: Mô hình chung của quy trình thiết kế b. Lập trình
Nhiệm vụ: Lập trình viên thực hiện lập trình dựa trên tài liệu Giải pháp và Thiết kế
đã được phê duyệt. Kết quả: Source code.
- Là quy trình chuyển đổi từ tài liệu đặc tả hệ thống thành một hệ thống thực, có thể
vận hành được và phải loại bỏ các lỗi của chương trình. 5 lOMoAR cPSD| 45349271
- Lập trình là một hành động cá nhân, không có quy trình lập trình chung. Người lập
trình phải thực hiện một số kiểm thử để phát hiện ra lỗi trong chương trình và loại bỏ
nó trong quy trình gỡ lỗi.
- Trong ba giai đoạn: thiết kế, cài đặt và bảo trì thì thiết kế là giai đoạn quan trọng
nhất, chịu trách nhiệm đến 80% đối với sự thành công của một sản phẩm. Cài đặt là
việc thực thi những gì đã thiết kế. Nếu trong quá trình cài đặt có xuất hiện vấn đề thì
phải quay lại sửa bản thiết kế. Quá trình thiết kế tốt là cơ sở để quản lý và giảm chi phí
cho công việc bảo trì phần mềm sau này. c. Kiểm thử
Nhiệm vụ: Tester tạo kịch bản kiểm thử (test case) theo tài liệu đặc tả yêu cầu, thực
hiện kiểm thử và cập nhật kết quả vào kịch bản kiểm thử, log lỗi trên các tool quản lý lỗi.
Kết quả: Test case , lỗi trên hệ thống quản lý lỗi. d. Triển khai
Nhiệm vụ: Triển khai sản phẩm cho khách hàng.
Kết quả: Biên bản triển khai với khách hàng.
1.1.2. Một số quy trình cho ph愃Āt triển phần mềm
- Có khá nhiều mô hình phát triển phần mềm hiện nay ví dụ như:
a. Mô hình Agile 6 lOMoAR cPSD| 45349271
Hình 1.3: Mô hình phát triển phần mềm Agile b. Mô hình tháp nước
Hình 1.4: Phát triển phần mềm theo mô hình tháp nước
c. Mô hình chữ V 7 lOMoAR cPSD| 45349271
Hình 1.5: Phát triển phần mềm theo mô hình chữ V
d. Mô hình xoắn ốc – spiral Model
Hình 1.6: Phát triển phần mềm theo mô hình xoắn ốc
e. Mô hình mẫu thử (Prototyping model) – Mô hình xây dựng tiến triển 8 lOMoAR cPSD| 45349271
Hình 1.7: Mô hình mẫu thử f.
Mô hình phát triển
dựa trên thành phần
Hình 1.8: Mô hình phát triển dựa trên thành phần
Hình 1.9: mô hình ph愃Āt triển dựa trên thành phần
g. Mô hình phát triển ứng dụng nhanh
Hình 1.10: Mô hình phát triển ứng dụng nhanh 9 lOMoAR cPSD| 45349271
h. Mô hình tăng trưởng
Hình 1.11: Mô hình tăng trưởng
i. Phát triển các hệ thống hình thức hóa
Hình 1.12: Phát triển hệ thống hình thức hóa 10 lOMoAR cPSD| 45349271
j. Phát triển hướng sử dụng lại
Hình 1.13: Phát triển theo hướng sử dụng lại
1.2.Mô hình Agile quy trình Scrum 1.2.1. Agile là gì?
- Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm
đến tay người dùng càng nhanh càng tốt càng sớm càng tốt.
1.2.2. Ưu nhược điểm của Agile a. Ưu điểm
- Bàn giao sản phẩm nhanh chóng , liên tục => đảm bảo sự hài lòng của khách hàng -
Khách hàng, dev và tester liên tục trao đổi với nhau => hợp tác, trao đổi hàng ngày => gần gũi hơn.
- Việc vừa trao đổi vừa feedback qua lại trong quá trình phát triển sẽ giúp nâng cao
giá trị của sản phẩm.
- Tiến độ được theo dõi sát xao mỗi ngày.
- Có thể đối ứng dễ dàng theo các thay đổi yêu cầu, thay đổi đặc điểm giữa quá trình phát triển.
b. Nhược điểm
- Phát triển theo mô hình Agile thường sẽ tạo lịch trình cho mỗi thay đổi, mỗi yêu cầu
nên việc kiểm soát, tiến độ tổng thể project khá khó. 11 lOMoAR cPSD| 45349271
- Dự án có thể dễ dàng off-track(lệch hướng) nếu đại diện khách hàng không rõ kết
quả cuối cùng mà họ muốn.
- Đôi khi đặc điểm giao tiếp với khách hàng thường xuyên của mô hình Agile bị phản
tác dụng, dự án sẽ phát triển trong tình trạng khách hàng cứ mãi trao đổi mà không đưa
ra được yêu cầu chính xác.
1.2.3. Tuyên ngôn Agile
- Các nhà phát triển nhấn mạnh mười hai nguyên lý phía sau Tuyên ngôn Agile để
giúp các nhà phát triển có được gợi ý trong thực hành và vận dụng các phương pháp
Agile trong thực tiễn. Các nguyên lý được liệt kê sau đây:
1) Ư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ị.
2) 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.
3) 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.
4) 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.
5) 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.
6) 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.
7) Phần mềm chạy tốt là thước đo chính của tiến độ.
8) Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và
người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
9) Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
10) Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
11) Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
12) Đội sản xuất sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn.
Sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.
1.2.4. Đặc trưng của Agile 12 lOMoAR cPSD| 45349271
a. 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). - Trong mỗi phân đoạn này, 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.
- Các phương pháp 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.
b. 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ác phần nhỏ này thường là đầy đủ, có khả năng chạy 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 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.
c. 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.
- Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay đổi.
d. 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.
- Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc
phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản
lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất.
e. Quản lý tiến trình thực nghiệm (Empirical Process Control) 13 lOMoAR cPSD| 45349271
- Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán
lý thuyết hay các tiền giả định (prescription).
- Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ
dàng thích nghi và gia tăng tính linh hoạt.
- Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có
thể kiểm soát được tiến trình, và nâng cao năng suất lao động.
f. Giao tiếp trực diện (face-to-face communication)
- Về yêu cầu của khách hàng, Agile khuyến khích nhóm phát triển trực tiếp nói chuyện
với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản.
- Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên
(thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế. g.
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 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ận hành được cơ chế “làm việc dựa trên giá trị”, nhóm Agile thường làm việc
trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng). Cộng tác trực tiếp
với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án.
- Nhờ đó các dự án Agile thường giúp khách hàng tối ưu hóa được giá trị của dự án.
Một cách gần như trực tiếp, Agile gia tăng đáng kể độ hài lòng của khách hàng.
1.2.5. C愃Āc phương ph愃Āp ph愃Āt triển phần mềm theo mô hình Agile
- Có 3 phương pháp phát triển trong mô hình Agile: Scrum, Extreme
programming,phát triển theo chức năng người dùng.
- Trong bài đề tài này chúng ta sẽ sử dụng phương pháp phát triển Srum. 1.2.6. Scrum là gì? 14 lOMoAR cPSD| 45349271
Hình 1.14: Mô hình agile – quy trình Scrum
- Scrum là một quy trình phát triển phần mềm theo phương pháp Agile. Chính vì thế,
Scrum tuân thủ các nguyên tắc của Agile Manifesto.
- Tuy nhiên, Agile và Scrum không phải là một. Hãy nhớ lại, Agile là gì? Agile là
một phương pháp, bao gồm những giá trị cốt lõi và nguyên tắc nhất định còn Scrum là quy
trình “hiện thực hoá” những giá trị và nguyên tắc của Agile.
- Với nguyên tắc chủ đạo là chia nhỏ phần mềm cần sản xuất ra thành các phần nhỏ
để phát triển (các phần nhỏ này phải đọc lập và Release được), lấy ý kiến khách hàng và
thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng
những gì khách hàng mong muốn.
- Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường
mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay
đổi và yêu cầu tốc độ cao.
1.2.7. Đặc điểm của SCRUM
- Scrum (hay agile nói chung) được xếp vào nhóm “Feature-driven development”.
Sản phầm được phát triển theo tính năng, chứ không phát triển sản phẩm theo kiến trúc hệ thống.
- Scrum khác với các mô hình Agile ở chỗ nó là mô hình hướng khách hàng
(Customer oriented), vai trò của khách hàng trong việc đánh giá sản phẩm rất quan
trọng. Chỉ sau mỗi sprint (2-4 tuần) khách hàng sẽ thấy được sự thay đổi của sản phẩm của
mình qua đó đưa ra phản hồi sớm để định hướng. -> Thích ứng nhanh với sự thay đổi yêu cầu 15 lOMoAR cPSD| 45349271
- Scrum giảm thiểu tài nguyên dành cho việc quản lý mà tập trung nhiều hơn cho
những công việc liên quan trực tiếp đến việc làm ra sản phẩm. Bằng cách giảm vai trò quản
lý (PM) bằng cách đẩy việc quản lý tới từng người,
- Giảm thời gian dành cho việc viết tài liệu bằng cách tăng thời gian trao đổi trực tiếp.
Thông thường khi estimate công việc, thì team estimate cả thời gian dành cho
communication để hoàn thành task đó nữa.
- Tập trung vào sản phẩm, sản phẩm mới là đích cuối cùng chứ không phải qui trình.
1.2.8. Ưu nhược điểm của mô hình Scrum a. Ưu điểm
- 1 người có thể làm nhiều việc ví dụ như dev có thể test luôn
- Phát hiện lỗi sớm hơn rất nhiều so với các phương pháp truyền thống f
- Khách hàng nhanh chóng thấy được sản phẩm do đó đưa ra phản hồi sớm
- Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu
b. Nhược điểm
- Trình độ của nhóm là có một kĩ năng nhất định
- Phải có sự hiểu biết về mô hình agile
- Khó khăn trong việc quyết định ngân sách và thời gian
- Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo dài khi
có nhiều yêu cầu thay đổi từ khách hàng
- Vai trò của PO rất quang trọng, PO là người quyết định hướng sản phẩm. nếu PO không
làm tốt sẽ ảnh hưởng đến kết quản chung
1.2.9. C愃Āc nhân tố tạo nên 1 quy trình Scrum
- Một cách đơn giản có 3 thành tố quang trọng cấu thành Scrum: Tổ chức
(Organization), Qui trình (Process), Tài liệu (Atifacts). Trong mỗi thành tố có 03 thành tố
con. Như vậy, chúng ta chỉ cần hiểu và áp dụng được 9 thành tố này là có thể áp dụng SCRUM.
- Tổ chức (Organization): Tổ chức nhóm dự án và Roles (Vài trò)
• Product Owner (Người sở hữu sản phẩm)
• ScrumMaster (Người điều phối ) 16 lOMoAR cPSD| 45349271
• Development Team (Nhóm phát triển)
- Tài liệu (Atifacts): các kết quả đầu ra
• Product Backlog (Danh sách các chức năng cần phát triển của sản phẩm)
• Sprint Backlog (Danh sách các chức năng cần phát triển cho mỗi giai đoạn)
• Estimation (Kết quả ước lượng của Team)
- Qui trình(Process): Qui định cách thức vận hành của SCRUM
• Sprint Planning meeting (Họp để hoạch định cho mỗi giai đoạn)
• Sprint Review (Họp để tổng kết cho mỗi giai đoạn)
• Daily Scrum Meeting (Họp review hàng ngày)
1.2.10.Tổ chức dự 愃Ān (Organization)
a. Product owner
- Product Owner là người sở hữu sản phẩm, người quyết định sản phẩm có những chức
năng nào và là người quyết định Product Backlog. Thông thường Role này được khách
hàng hoặc người đại diện cho khách hàng đảm nhận. b. ScrumMaster
- Scrum Master là người đảm bảo các qui trình của Scrum được thực hiện đúng và
thuận lợi, giúp đỡ cho Team thực hiện công việc phát triển sản phẩm một cách tốt nhất.
c. Development Team (Nhóm phát triển)
- Một nhóm từ 4-7 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm. Nhóm dự án
phải làm việc với Product Owner để quyết định những gì sẽ làm trong Sprint (giai đoạn
)này và kết quả sẽ ra sao. Đồng thời nhóm cũng thảo luận để đưa ra các giải pháp, ước
lượng thời gian thực hiện công việc, họp đánh giá kết quả công việc. Nếu dự án lớn chúng
ta cần chia ra thành các dự án nhỏ.
1.2.11.Tài liệu (atifacts)
a. Product Backlog -
Product Backlog là danh sách các chức năng cần được phát triển của sản phẩm.
Danh sách này do Product Owner quyết định. Nó thường xuyên được cập nhật để
đáp ứng được nhu cầu thay đổi của khách hàng cũng như các điều kiện của dự án.
b. Sprint Backlog
- Sprint là một giai đoạn phát triển trong quá trình phát triển sản phẩm, nó được
khuyến khích có chiều dài từ 2 – 4 tuần. Mỗi Sprint được xác định bằng thời gian phát triển, 17 lOMoAR cPSD| 45349271
danh sách các chức năng phát triển (Sprint Backlog). Mỗi sprint phải Release được sản
phẩm để đảm bảo lấy được ý kiến khách hàng, qua được các qui trình phát triển của sản
phẩm nhằm rút kinh nghiệm và tránh sự cố sau này.
- Sprint Backlog là danh sách chức năng phát triển trong Sprint, nó được quyết định
bởi cuộc họp Sprint Planning. Sprint Backlog là các chức năng được chọn từ Product
Backlog dựa trên mức độ ưu tiên và khả năng của team phát triển.
c. Estimation (ước lượng) -
Trong SCRUM thì các thành viên của Team sẽ tự lựa chọn Task cho mình và ước
lượng thời gian phát triển dự kiến và chịu trách nhiệm với ước lượng này. Sau khi hoàn
thành sẽ cập nhật vào bảng Sprint Backlog.
1.2.12.Quy trình (process)
a. Sprint Planning meeting (Họp lập kế hoạch cho mỗi Sprint)
- Như chúng ta đã biết ở trên Sprint là một giai đoạn phát triển có thời gian từ 2-4 tuần.
Để chuẩn bị cho mỗi Sprint team cần phải họp để xác định những chức năng nào (story) sẽ
phát triển trong giai đoạn này (sprint backlog), kết quả đầu ra dự kiến (Goal, kết quả
Release), Estimate (ước lượng ai làm việc gì) và thảo luận các giải pháp. Tất cả được ghi
thành biên bản để có cơ sở thực hiện và Review sau này.
b. Sprint Review
- Là cuộc họp để đánh giá lại kết quả thực hiện của Sprint vừa qua, xác định những chức
năng được Release, những chức năng tiếp tục sửa hoặc phát triển thêm, xác định những vấn
đề phát sinh và bàn phương án giải quyết, bổ sung Product Backlog v….
c. Daily Scrum Meeting (hay còn gọi là Standup Meeting) -
Daily Scrum Meeting là cuộc họp hàng ngày và được đề nghị không quá 15 phút và
họp đứng để đảm bảo thời gian họp không bị kéo dài vào đầu mỗi ngày, mỗi thành viên chỉ trả lời 3 câu hỏi: -
Hôm qua bạn làm được gì? - Phát sinh vấn đề gì? - Hôm nay bạn sẽ làm gì? 18 lOMoAR cPSD| 45349271 -
Nếu thành viên gặp vấn đề thì nên làm việc riêng để giải quyết để không mất nhiều
thời gian của các thành viên. Scrum Master phải đảm bảo cuộc họp này được thực hiện đúng qui định. -
Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product
Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án
căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng
mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn
mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến,
nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.
CHƯƠNG 2: LẬP KẾ HO䄃⌀CH
2.1. Ph愃Āt triển phần mềm theo mô hình -
Phát triển phần mềm theo mô hình Agile quy trình Scrum -
Agile: Là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm
đến tay người dùng càng nhanh càng tốt càng sớm càng tốt -
Scrum: Là một quy trình phát triển phần mềm theo phương pháp Agile.
Chính vì thế, Scrum tuân thủ các nguyên tắc của Agile Manifesto. 19