2.Mô tả dự án Tên dự án: Website bán điện thoại Khách hàng: Bà Nguyễn Quỳnh Chi Trưởng nhóm dự án: Phạm Như Cảnh Đội phát triển dự án: o Nguyễn Minh Hiếu o Trần Quang Đức o Nguyễ
Phát biểu bài toán
1.Nhu cầu - mục đích dự án
Mạng Internet ngày càng phát triển, lượng người dùng Internet ở Việt Nam ngày càng nhiều lên tới hơn 80% Việc tiếp thị sản phẩm tới khách hàng là một vấn đề vô cùng quan trọng trong việc phát triển doanh nghiệp Một trong những hướng tiếp cận đó là tạo ra những website bán hàng, nơi khách hàng có thể nhanh chóng tìm ra sản phẩm mong muốn, được so sánh sản phẩm với những sản phẩm cùng giá, sản phẩm rẻ hơn và sản phẩm ở phân khúc cao hơn Xu hướng chuyển đối số ngày càng phát triển dẫn đến các cửa hàng bán lẻ đang dần lấn sân sang mô hình kinh doanh online nhằm tối ưu việc tiếp cận khách hàng đồng thời giảm chi phí marketing bằng những kênh truyền thống.
Tên dự án: Website bán điện thoại
Khách hàng: Bà Nguyễn Quỳnh Chi
Trưởng nhóm dự án: Phạm Như Cảnh
Đội phát triển dự án: o Nguyễn Minh Hiếu o Trần Quang Đức o Nguyễn Việt Đoàn o Dương Quang Lượng
Tôn chỉ dự án
Những đặc điểm nổi bật
Các sản phẩm phải được cập nhật liên tục, khách hàng sẽ luôn tìm thấy một cách nhanh chóng sản phẩm mà họ mong muốn.
Website cần được chạy 24/24, hỗ trợ quảng cáo sales
Các công cụ thống kê, biểu đồ thống kê giúp chủ cửa hàng kiểm soát lượng khách hàng truy cập cũng như số lượng sản phẩm bán chạy nhất số lượng tồn đọng trong kho,
Lợi ích của hệ thống
Tiếp cận nhiều khách hàng tiềm năng.
Tiết kiệm nhiều chi phí.
Xây dựng và quảng bá thương hiệu.
Tăng hiệu quả kinh doanh.
Mục tiêu
Số hóa thông tin sản phẩm: sản phẩm phân loại theo tên, hãng, giá, loại,…
Giao diện thông minh, thân thiện, dễ sử dụng
Quản lý giá và doanh thu
Quản lý đánh giá, bình luận, review sản phẩm của khách hàng thông qua mua hàng online
Quản lý nhập, xuất hàng hóa trong kho, hàng hóa xuất hàng ngày, đơn hàng hủy và trả hàng
Các phương pháp tiếp cận
Cụ thể hóa tối đa các yêu cầu của khách hàng về hệ thống.
Tìm hiểu và phân tích đối tượng sẽ sử dụng hệ thống để biết rõ hơn ta cần phải làm gì.
Lựa chọn ngôn ngữ và công nghệ phù hợp và tối ưu hệ thống.
Lên kế hoạch cụ thể gắn với các mốc thời gian quan trọng.
Tham khảo các hệ thống có chức năng tương tự.
Họp định kỳ để tổng kết các công việc làm được và triển khai tiếp các kế hoạch mới.
Áp dụng mô hình Water fall để thiết kế hệ thống.
Sử dụng ngôn ngữ Java để xây dựng hệ thống backend
Sử dụng các Framework như: ReactJS, Spring Boot
Sử dụng hệ quản trị cơ sở dữ liệu MySQL
Thiết kế cơ sở dữ liệu phù hợp với yêu cầu
Phạm vi dự án
Website hoàn chỉnh với các tính năng: o Đăng nhập, đăng ký o Tìm kiếm theo các cách khác nhau o Đặt đơn hàng, hủy đơn hàng. o Nhập/xuất sản phẩm o Thống kê doanh thu o Thanh toán online
Bản hướng dẫn sử dụng phần mềm
4.2 Ngoài phạm vi dự án
Chạy quảng cáo cho các bên liên quan
Liên kết thanh toán các ví điện tử, thanh toán trực tuyến
Chat bot trả lời tin nhắn
Ngân sách
Dự trù kinh phí: 80.000.000 VNĐ (tám mươi triệu Việt Nam Đồng chẵn)
Ngân sách được giao: 0 VNĐ
Lịch thực hiện
Dự kiến từ khi khởi động dự án đến khi đưa vào hoạt động khoảng 5 tháng (Từ ngày 15/06/2024 đến ngày 12/12/2024)
Ngày 15/06/2024: Khởi động dự án.
Ngày 18/06/2024: Hoàn tất lấy requirements từ khách hàng.
Ngày 21/06/2024: Bàn giao lại các requirements cho nhóm phân tích.
Ngày 01/12/2024: Gửi các bản phân tích cho đội thiết kế
Ngày 24/12/2024: Hoàn tất khâu thiết kế chuyển kết quả sang nhóm phụ trách phát triển.
Ngày 20/01/2024: Hệ thống cơ bản đã phát triển xong chuyển sang cho bên kiểm thử.
Ngày 05/12/2024: Hoàn tất kiểm thử và rà soát chất lượng phần mềm.
Ngày 07/12/2024: Bàn giao sản phẩm cho khách hàng.
Ngày 15/12/2024: Hoàn tất dự án.
Trách nhiệm và vai trò của mỗi thành viên trong dự án
Vị trí Họ và Tên Vai Trò & Trách Nhiệm
Quản lý dự án, tiến độ lập kế hoạch dự án.
Tiếp xúc khách hàng để lấy yêu cầu nghiệp vụ, phân tích làm rõ yêu cầu khách hàng
Thiết kế hệ thống, lập trình hệ thống
3 Design Database Trần Quang Đức
Thiết kế và quản trị CSDL
Nhân viên đảm bảo chất lượng phần mềm, Kiểm thử (QA)
Các giả thiết cần thiết lập
Ứng dụng chạy trên nền tảng Web.
Trong quá trình thực hiện dự án, khách hàng có thể thay đổi một số yêu cầu trong phạm vi cho phép.
Đội phát triển dự án có trách nhiệm hoàn thành công việc đảm bảo thời gian và chất lượng.
Khách hàng phải bồi thường toàn bộ số tiền nếu tự ý bỏ hợp đồng
Bảng phân rã công việc(WBS)
1 Quản lý dự án – Project manager
1.1 Viết tài liệu kế hoạch, phạm vi dự án
1.2 Lập bảng phân rã công việc (WBS)
1.3 Lập bản kế hoạch quản lý rủi ro.
1.4 Lập bản kế hoạch đảm bảo chất lượng
2 Phân tích yêu cầu nghiệp vụ
2.1.1Yêu cầu cho chức năng tìm kiếm
2.1.2Yêu cầu cho chức năng thanh toán
2.1.3Yêu cầu cho chức năng nhập xuất
2.1.4Yêu cầu cho chức năng thống kê doanh thu
2.2 Viết tài liệu cho người dùng
2.2.1 Tài liệu hướng dẫn sử dụng
2.3 Yêu cầu về hệ thống
2.3.1 Yêu cầu về thiết bị sử dụng
3 Phân tích - thiết kế hệ thống
3.1 Xây dựng sơ đồ Use case
3.1.1 Xây dựng sơ đồ use case tổng quan
3.1.2 Xây dựng sơ đồ use case chi tiết từng chức năng.
3.2.2 Vẽ sơ đồ lớp thực thể
4.1 Phân tích kiến trúc phần mềm
5.1 Thiết kế giao diện người dùng
4.1 Xây dựng cơ sở dữ liệu.
4.3 Hệ thống quản lý website bán điện thoại
4.3.2 Chức năng tìm kiếm điện thoại theo hàng và giá tiền.
4.3.3 Chức năng đặt điện thoại, thanh toán trực tuyến.
4.3.4.Chức năng quản lý nhân viên.
5.2 Kiểm thử các chức năng
5.2.1 Kiểm thử chức năng đăng nhập.
5.2.2 Kiểm thử chức năng quản lý xuất/nhập điện thoại.
5.2.3 Kiểm thử chức năng kiểm tra hàng tồn.
5.2.4 Kiểm thử chức năng đặt điện thoại, thanh toán trực tuyến.
5.2.5 Kiểm thử chức năng báo cáo thống kê.
5.3 Báo cáo kiểm thử toàn hệ thống.
6 Triển khai và bàn giao hệ thống
6.1 Triển khai hệ thống trên môi trường của khách hàng.
6.2 Setup hệ thống phù hợp với môi trường cài đặt
6.3 Hướng dẫn người dùng hệ thống.
6.4 Bàn giao lại sản phẩm, tài liệu hướng dẫn đi kèm.
7.1 Tài liệu kết thúc dự án.
WBS TÊN THỜI GIAN DỰ KIẾN
1 Quản lý dự án 20 ngày
2 Lấy yêu cầu và phân tích yêu cầu 20 ngày
3 Phân tích nghiệp vụ 15 ngày
5 Triển khai cài đặt hệ thống 30 ngày
7 Kiểm tra và bàn giao sản phẩm 15 ngày
9 Tổng thời gian dự án 146 ngày
Quản lý thời gian
Xác định thời gian cho các hoạt động trong WBS
WBS TÊN THỜI GIAN DỰ KIẾN
1 Quản lý dự án 20 ngày
2 Lấy yêu cầu và phân tích yêu cầu 20 ngày
3 Phân tích nghiệp vụ 15 ngày
5 Triển khai cài đặt hệ thống 30 ngày
7 Kiểm tra và bàn giao sản phẩm 20 ngày
8 Tổng thời gian dự án 155 ngày
Biểu đồ Gantt
3 Bảng chi tiết công việc (cụ thể)
WBS Name Duration Start_Date Finish_Date
1 Quản lý dự án 20 days
July 12, 2024 5:00 PM 1.1 Viết tài liệu, phạm vi dự án 5 days
1.2 Lập bản phân rã công việc 5 days
Lập bản kế hoạch quản lý rủi ro 5 days
Lập bản kế hoạch đảm bảo chất lượng phần mềm 5 days
Phân tích yêu cầu nhiệm vụ 20 days
2.1 Yêu cầu khách hàng 12 days
Yêu cầu cho chức năng tìm kiếm 3 days
Yêu cầu cho chức năng thanh toán 3 days
Yêu cầu cho chức năng nhập xuất 2 days
Yêu cầu cho chức năng thống kê doanh thu 2 days
July 25, 2024 5:00 PM 2.2 Viết tài liệu người dùng 5 days
Tài liệu hướng dẫn sử dụng 3 days
July 28, 2024 5:00 PM 2.2.2 Điều khoản sử dụng 2 days
2.3 Yêu cầu hệ thống 5 days
2.3.1 Yêu cầu về thiết bị 2 days
2.3.2 Yêu cầu về server 3 days
3 Phân tích yêu cầu hệ thống 15 days
2024 5:00 PM 3.1 Xây dựng sơ đồ usecase 2 days
Xây dựng usecase tổng quan 1 day
3.1.2 Xây dựng usecase chi tiết 1 day
2024 5:00 PM 3.2.1 Trích lớp thực thể 1 day
2024 5:00 PM 3.2.2 Vẽ sơ đồ lớp thực thể 2 days
2024 5:00 PM 3.3 Thiết kế hệ thống 5 days
2024 5:00 PM 3.3.1 Thiết kế classdiagram 3 days
2024 5:00 PM 3.3.2 Thiết kế CSDL 2 days
Phân tích kiến trúc phần mềm 5 days
Thiết kế giao diện người dùng 5 days
4 Xây dựng ứng dụng 35 days
2024 5:00 PM 4.1 Xây dựng cơ sở dữ liệu 3 days
2024 5:00 PM 4.2 Cài đặt môi trường 14 days
2024 5:00 PM 4.3 Xây dựng module 18 days
2024 5:00 PM 4.3.1 Chức năng đăng nhập 4 days
2024 5:00 PM4.3.2 Chức năng tìm kiếm điện 4 days October 6, October 11, thoại 2024 8:00 AM 2024 5:00 PM 4.3.4 Chức năng đặt điện thoại 5 days
Chức năng quản lý nhân viên 5 days
2024 5:00 PM 5.1 Kế hoạch kiểm thử 3 days
2024 5:00 PM 5.2 Kiểm thử các chức năng 20 days
Kiểm thử chức năng đăng nhập 4 days
Kiểm thử chức năng quản lý xuất/nhập điện thoại 4 days
Kiểm thử chức năng kiểm tra hàng tồn 4 days
Kiểm thử chức năng đặt điện thoại, thanh toán trực tuyến 4 days
Kiểm thử chức năng báo cáo thống kê 4 days
Báo cáo kiểm thử toàn hệ thống 2 days
Triển khai và bàn giao hệ thống 15 days
Triển khai hệ thống trên môi trường khách hàng 5 days
Cài đặt hệ thống phù hợp với môi trường 2 days
Hướng dẫn người dùng hệ thống 3 days
Bàn giao sản phẩm và tài liệu đi kèm 5 days
7 Kết thúc dự án 7 days
2024 5:00 PM 7.1 Tài liệu kết thúc dự án 6 days
Quản lý rủi ro
Giải pháp xử lý dự kiến
Xuất phát từ ba mục tiêu cơ bản của dự án là:
● dự án thành công (Win).
● dự án được thực hiện trong ngân sách cho phép (Budget).
● dự án làm hài lòng khách hàng (Satisfaction).
Mục tiêu dự án thành công
a) Xác định yêu cầu từ khách hàng
+ Giao tiếp khó khăn đối với khách hàng.
+ Hiểu sai, thiếu thông tin, không rõ ràng yêu cầu của khách hàng.
+ Yêu cầu bị thay đổi liên tục do khách hàng chưa xác định rõ hoặc yêu cầu thêm hoặc bớt chức năng. b) Lĩnh vực liên quan đến tiến trình:
+ Lập lịch trễ hoặc chưa chính xác.
+ Lịch thực hiện bị nén lại khi gặp sự cố.
+ Lên kế hoạch chưa hoàn thiện, đầy đủ.
+ Ước lượng thiếu công việc thuộc phạm vi dự án.
+ Không đảm bảo được đúng phạm vi của dự án.
+ Code sai yêu cầu chức năng hoặc phân tích thiết kế.
+ Code không được kiểm soát chặt chẽ gây lỗi
+ Mất mát hoặc rò rỉ mã nguồn code.
+ Tài liệu sau mỗi pha phát triển bị thiếu hoặc chưa chính xác.
+ Chậm tiến độ công việc so với dự định.
+ Tiến độ công việc nhanh hơn so với dự định tiềm ẩn rủi ro về chất lượng. c) Chất lượng dự án:
+ Tài nguyên dự án bị lãng phí hoặc bị sử dụng sai mục đích.
+ Một số chức năng của hệ thống chưa đúng yêu cầu của khách hàng hoặc bị thiếu.
+ Tốc độ xử lý chưa đúng dự kiến.
+ Sản phẩm bị lỗi trên một số nền tảng không phổ biến (Vd: trình duyệt cũ, ).
+ Sau kiểm thử vẫn còn sót lỗi.
+ Thiếu khả năng chịu tải lớn khi số lượng người dùng tăng lên đột biến.
+ Kiểm thử quá trình cài đặt kém hiệu quả. d) Thời gian:
Thời gian thực hiện dự án:
+ Ước lượng sai thời gian thực hiện ở một số đầu công việc.
+ Thời gian thực hiện dự án vượt quá kế hoạch. e) Con người:
+ Trình độ chuyên môn của đội dự án không đáp ứng được yêu cầu của dự án.
+ Làm việc thiếu chuyên nghiệp và trách nhiệm.
+ Vai trò trong đội dự án bị lẫn lộn, không rõ ràng.
+ Nhân sự bỏ dự án.
+ Phân bổ nhân sự không hợp lý.
+ Thiếu hoặc thừa nhân lực trong một giai đoạn cụ thể trong quá trình phát triển dự án.
+ Mâu thuẫn nội bộ. f) Công nghệ:
+ Chọn công nghệ không phù hợp với dự án hoặc đã lỗi thời.
+ Tích hợp công nghệ mới vào sản phẩm không thành công.
+ Không được hỗ trợ công nghệ dự án yêu cầu. g) Các lĩnh vực khác:
+ Thời tiết: lũ lụt, động đất, mưa bão,
+ Sự cố: mất mạng, điện, cháy nhà, dịch bệnh,
+ Sức khỏe, tinh thần của thành viên trong đội dự án: bệnh, stress, tinh thần không ổn định
Phân tích rủi ro
Pha phân tích các rủi ro còn được gọi là đánh giá các rủi ro dựa trên các tiêu chí
● Xác định xác suất xảy ra rủi ro Đánh giá về định tính Đánh giá về định lượng
Rất cao Trên 84% Gần như chắc chắn xảy ra
Cao Khoảng 60-84% Nhiều khả năng sẽ xảy ra
Trung bình Khoảng 35-59% Có vẻ như sẽ xảy ra
Thấp Khoảng 12-34% Nhiều khả năng là không xảy ra
● Xác định ảnh hưởng của rủi ro tới các mục tiêu của dự án Đánh giá Mô tả về định tính
Rất cao Nhiều khả năng gây ra việc hủy bỏ dự án
Cao Có vẻ như sẽ gây ra sự gián đoạn đáng kể đối với lịch thực hiện dự án, hoặc làm tăng chi phí dự án hoặc làm giảm năng suất làm việc một cách đáng kể
Trung bình Có vẻ như sẽ gây ra một sự gián đoạn với lịch thực hiện dự án, hoặc làm tăng chi phí dự án hoặc làm giảm năng suất làm việc
Thấp Có vẻ như sẽ gây ra một sự gián đoạn không đáng kể với lịch thực hiện dự án, hoặc làm tăng chi phí dự án hoặc làm giảm năng suất làm việc một cách không đáng kể
● Xác định độ nguy hiểm của rủi ro
Rất cao Cao Trung bình
Rất cao Không chấp nhận được
Cao Rất cao Cao Cao Trung bình
● Phạm vi ảnh hưởng của rủi ro (W - thành công dự án, B - ngân sách, S - thỏa mãn khách hàng)
Sự kiện rủi ro Người chịu trách nhiệm
Xác suất rủi ro xuất hiện Ảnh hưởng của rủi ro
1 Khó khăn trong việc giao tiếp với khách hàng
2 Hiểu sai, truyền tải thiếu thông tin, mất mát hoặc không rõ ràng thống nhất yêu cầu của khách hàng
3 Yêu cầu bị thay đổi do khách hàng chưa muốn phát triển thêm tính năng khác
4 Lập lịch trễ hoặc chưa chính xác
5 Lịch thực hiện bị nén lại khi gặp sự cố
6 Lên kế hoạch chưa hoàn thiện, đầy đủ
7 Ước lượng thiếu công việc thuộc phạm vi dự án
8 Sai phạm vi của dự án
9 Code sai yêu cầu chức năng hoặc phân tích thiết kế
12 Code không được kiểm soát chặt chẽ dẫn đến lỗi hồi quy
11 Mất mát hoặc rò rỉ mã nguồn code
12 Tài liệu sau mỗi pha phát triển bị thiếu hoặc chưa chính xác
13 Chậm tiến độ công việc so với dự định
14 Tiến độ công việc nhanh hơn so với dự định tiềm ẩn rủi ro về chất lượng
15 Tài nguyên dự án bị lãng phí hoặc bị sử dụng sai mục đích
16 Một số chức năng của hệ thống chưa đúng yêu cầu của khách hàng hoặc bị thiếu
17 Tốc độ xử lý chưa đúng dự kiến
18 Sản phẩm bị lỗi trên một số nền tảng không phổ biến (Vd: trình
19 Sau kiểm thử vẫn còn sót lỗi Đội trưởng đội kiểm thử
20 Thiếu khả năng chịu tải lớn khi số lượng người dùng tăng lên đột biến Đội trưởng đội kiểm thử
21 Kiểm thử quá trình cài đặt kém hiệu quả Đội trưởng đội kiểm thử
22 Ước lượng sai thời gian thực hiện ở một số đầu công việc
23 Thời gian thực hiện dự án vượt quá kế hoạch
24 Trình độ chuyên môn của đội dự án không đáp ứng được yêu cầu của dự án
25 Làm việc thiếu chuyên nghiệp và trách nhiệm
26 Vai trò trong đội dự án bị lẫn lộn, không rõ ràng
27 Nhân sự bỏ dự Giám W Thấp Trung Trung 38 án đốc dự án bình bình
28 Phân bổ nhân sự không hợp lý
29 Thiếu hoặc thừa nhân lực trong một giai đoạn cụ thể trong quá trình phát triển dự án
31 Xung đột giữa các phần trong hệ thống
32 Chọn công nghệ không phù hợp với dự án hoặc đã lỗi thời
33 Tích hợp công nghệ mới vào sản phẩm không thành công
34 Không được hỗ trợ công nghệ dự án yêu cầu
35 Thời tiết: mưa bão, lũ lụt, động đất,
36 Sự cố: mất mạng, điện, cháy nhà, dịch
37 Sức khỏe, tinh thần của đội dự án: bệnh, ngộ độc,…
38 Tuyển dụng nhân sự thiếu hợp lý gây lãng phí ngân sách
39 Nhân sự vào ra không kiểm soát dẫn đến chi phí cho nhân sự không hiệu quả
40 Ước lượng chi phí không phù hợp dẫn đến thiếu hụt ngân sách
41 Chi phí phát sinh cho cơ sở vật chất vượt quá ngân sách cho phép
42 Việc đàm phán ngân sách với khách hàng không thành công
43 Khách hàng không đồng ý thêm ngân sách cho dự án
44 Phát sinh sự cố không thể tiếp cận với nguồn vốn
45 Khách hàng không còn khả năng chi trả cho việc phát triển sản phẩm
46 Ngân sách phát sinh cho việc thuê công nghệ hoặc chuyên gia
47 Khách hàng yêu cầu quá khắt khe, đòi hỏi cao
48 Xung đột thành viên trong dự án và thành viên dự án với khách hàng
49 Sự cố phát sinh phía khách hàng khi triển khai cài đặt dự án
50 Sản phẩm chưa đúng yêu cầu từ khách hàng
51 Khách hàng thay đổi yêu cầu chức năng
52 Sản phẩm không đạt yêu cầu khách hàng
53 Sản phẩm bàn giao không đúng hạn
Kế hoạch giải quyết rủi ro
Trong quá trình lập kế hoạch đối phó rủi ro, những người quản lý rủi ro phải cân nhắc lựa chọn các chiến lược đối phó rủi ro cơ bản để từ đó xây dựng các phương án hành động cho phù hợp Các chiến lược đối phó rủi ro cơ bản được chia thành hai nhóm, cho các rủi ro thuộc loại nguy cơ và cơ hội, mỗi nhóm đều có 4 chiến lược cơ bản Các chiến lược đối phó với các rủ ro thuộc loại nguy cơ bao gồm: né tránh (avoid), chuyển giao (transfer), giảm nhẹ (mitigate) và chấp nhận (accept), trong khi các chiến lược cho các rủi ro thuộc loại cơ hội gồm có khai thác (exploit), nâng cao (enhance), chia sẻ (share) và chấp nhận
(accept) a) Chiến lược né tránh tìm cách loại bỏ nguy cơ do rủi ro gây ra hoặc tránh khỏi ảnh hưởng của rủi ro b) Chiến lược chuyển giao được thực hiện thông qua việc chuyển rủi ro cho tổ chức khác xử lý, cũng có thể thông qua bảo hiểm, bảo lãnh thực hiện c) Chiến lược giảm nhẹ/giảm thiểu được thực hiện thông qua các biện pháp được tiến hành để giảm khả năng xuất hiện hoặc ảnh hưởng của rủi ro d) Chiến lược chấp nhận có nghĩa là chấp nhận các rủi ro dù các rủi ro này đã được nhận dạng, đã biết chúng có thể xảy ra và có thể mang lại hậu quả xấu hoặc lợi ích, tuy nhiên, không thể sử dụng các chiến lược khác để quản lý hoặc việc quản lý bằng các chiến lược khác không mang lại hiệu quả hơn về mặt kinh tế Chiến lược này có thể được áp dụng cho cả các rủi ro thuộc loại cơ hội và nguy cơ. đ) Chiến lược khai thác là một chiến lược đối phó với các rủi ro thuộc loại cơ hội Chiến lược này được sử dụng khi người ta muốn cơ hội hình thành Chiến lược này hạn chế các bất định có liên quan để đảm bảo cơ hội chắc chắn xảy ra e) Chiến lược nâng cao được thực hiện nhằm tăng khả năng xảy ra của cơ hội và/hoặc tăng ảnh hưởng tích cực từ cơ hội. f) Chiến lược chia sẻ cơ hội là việc lôi kéo thêm đơn vị thứ ba vào việc thực hiện các hoạt động, cho phép họ chia sẻ cơ hội có từ dự án, bởi sự tham gia của họ có thể khiến khả năng nắm bắt được cơ hội tăng lên,
Theo dõi và kiểm soát rủi ro
Bằng việc thiết lập bảng phân tích rủi ro và kế hoạch giải quyết giúp quản lý dự án có kế hoạch ứng xử với những rủi ro thường xuyên gặp để không ảnh hưởng đến tiến độ của dự án.
Giám sát rủi ro cần được chú trọng, mỗi khi rủi ro được xác định, phân tích và ứng phó thành công, phải đưa ra trước dự án để những thành viên khác nắm được và tránh mắc phải Quản lý cần phải thường xuyên cập nhập lại bảng phân tích rủi ro và kế hoạch giải quyết Để đạt được hiệu quả tốt nhất, những rủi ro đã được phân tích hoặc đang trong quá trình ứng phó cần được đề ra trong các cuộc họp tiến độ dự án định kỳ.Trong cuộc họp cần chỉ rõ tường tận các rủi ro, đặc biệt là các rủi ro có tính nghiêm trọng Việc hiểu rõ ràng và tường tận rủi ro giúp tránh gặp phải những rủi ro tương tự trong tương lai.
Quản lý chất lượng
Tiêu chí đánh giá chất lượng
- Đánh giá chất lượng các bản kế hoạch.
1.2 Giai đoạn lấy yêu cầu
- Thực hiện đã đúng kế hoạch chưa
- Kiểm tra tính chính xác, đầy đủ của tài liệu
- Đánh giá tài liệu xác định yêu cầu chức năng, hệ thống.
- Đã lấy chính xác yêu cầu của khách hàng chưa?
- Tài liệu đã chính xác chưa, mô tả yêu cầu đã rõ ràng chưa?
1.3 Giai đoạn phân tích yêu cầu
- Thực hiện có đúng kế hoạch chưa?
- Các biểu đồ có hợp lý và phù hợp không?
- Việc viết tài liệu đã đầy đủ, chính xác chưa?
- Việc thực hiện có đúng kế hoạch không?
- Thiết kế cài đặt có phù hợp với yêu cầu chức năng không?
- Cơ sở dữ liệu có phù hợp với yêu cầu hệ thống không?
- Tài liệu có chính xác, tường minh, dễ hiểu không?
- Giao diện có thân thiện, phù hợp yêu cầu khách hàng không?
- Tiến độ có đúng kế hoạch không?
- Có đầy đủ chức năng của hệ thống không?
- Code có đúng với thiết kế không?
- Tiến độ có đúng kế hoạch không
- Kiểm thử chức năng có đáp ứng được yêu cầu không?
- Chức năng hoàn thiện có đúng yêu cầu không
Kiểm thử
Trong mục này trình bày chi tiết những hoạt động trong quá trình kiểm tra được thực hiện Những kiểm tra sau sẽ được đặt lịch trong kế hoạch dự án (sắp xếp theo thứ tự thời gian): i Kiểm tra đặc tả sản phẩm ii Kiểm tra thiết kế kiến trúc iii Kiểm tra thiết kế chi tiết iv Kiểm tra kế hoạch quản lý cấu hình sản phẩm
- Kiểm thử trên các hệ điều hành windows:Win7,8,12
- Công cụ kiểm thử: Bugzila, Snipping tool, SVN
- Kiểm thử trên các trình duyệt:Chorme,Cốc cốc, Safia
2.2 Kiểm thử a Các loại hình kiểm thử
Tên Kiểu Người đánh giá Đánh giá Mục đích
Kiểm tra đặc tả sản phẩm
Formal PM Dựa trên tài liệu đặc tả yêu cầu sản phẩm
Xác nhận rằng yêu cầu sản phẩm sẽ được đáp ứng đầy đủ trong đặc tả phần mềm
Xác định những yếu tố kĩ thuật có thể gây ra trong quá trình thực hiện.
Kiểm tra thiết kế kiến trúc
Informnal Nhóm thiết kế và phát triển
Giới thiệu cho nhóm phát triển và thiết kế môi trường sử dụng để phát triển sản phẩm là JAVA J2EE Kiểm tra thiết kế chi tiết
Quản trị dự án; người thiết kế (nhóm thiết kế chi tiết); lập trình viên;
Dựa trên sự hoàn thành của pha thiết kế
(Lặp lại đến khi phải thiết kế lại ít hơn 5% công việc)
Nó không bị ảnh hưởng bởi những mâu thuẫn nội bộ.
Nó đáp ứng đầy đủ đặc tả trong đặc tả yêu cầu sản phẩm.
Có hiệu quả trong quá trình thực thi và phát triển.
Kết quả có thể kiểm thử.
Kiểm tra kế hoạch quản lý cấu hình sản phẩm
Formal Quản trị dự án/ người điều khiển cấu hình;
Lập trình viên và tester.
Sau khi hoàn thành kiểm tra thiết kế chi tiết, trước khi pha mã hóa bắt đầu.
Quản trị dự án hoặc người điều khiển cấu hình trình bày chiến lược lựa chọn cho quản lý cấu hình tới lập trình viên và tester. b Các loại kiểm thử
Kiểm thử Chiến lược Thực thể xem xét
Kiểm thử đơn vị-Unit test
Mỗi thành phần được kiểm thử dựa trên công việc mã hóa để đảm bảo tất cả các công nghệ đều thỏa mãn yêu cầu
Kế hoạch kiểm thử đơn vị đã hoàn thành
Tất cả các test case đã hoàn thành
Tất cả các test case thực hiện thành công
Tất cả các lỗi được tìm thấy phải được sửa
Tất cả các tình huống được kiểm thử.
Tất cả các kiểm thử ngược đều thành công Kiểm thử tích hợp –
Kiểm thử tích hợp được thực hiện khi tất cả các module đã hoàn thành và đã kiểm thử đơn vị, để đảm bảo các chức năng là phù hợp khi tích hợp với các module khác
Kiểm thử đơn vị của mỗi module đã hoàn thành
Mỗi module chức năng thích hợp với
Tất cả các trường hợp kiểm thử tích hợp là thành công
Tất cả các lỗi được tìm thấy chính nó
Tất cả các test case đã phát triển phải được sửa
Tất cả các tình huống được kiểm thử.
Tất cả các kiểm thử ngược đều thành công
Khi tất cả các thay đổi được thực hiện và các chức năng là phù hợp, hệ thống sẽ được kiểm tra tích hợp với các hệ thống khác xem có phù hợp không
Kế hoạch kiểm thử tích hợp đã hoàn thành
Kế hoạch kiểm thử hệ thống đã hoàn thành.
Tất cả các trường hợp kiểm thử hệ thống đã phát triển
Tất cả các trường hợp kiểm thử hiệu năng đã phát triển
Tất cả các test case hệ thống thực hiện thành công
Tất cả các lỗi được tìm thấy phải được sửa
Tất cả các tình huống được kiểm thử.
Tất cả các kiểm thử ngược đều thành côngTất cả các
Tất cả các trường hợp kiểm thử hồi quy đã phát triển
Một môi trường kiểm thử thích hợp đã được thiết lập kiểm thử chức năng hệ thống đều thành công
Chi tiết thực hiện kiểm thử
Modul Kiểu test Kĩ thuật test
Hàm khởi tạo đăng ký, đăng nhập, sửa thông tin cho khách hàng
Kiểm thử luồng điều kiển
NUnit Kiểm thử kết thúc khi một đối tượng người dùng được cấp phát bộ nhớ
Xem thống kê theo dòng sản phẩm điện thoại
Kiểm thử dòng dữ liệu, Kiểm thử luồng điều kiển
NUnit Kiểm thử kết thúc khi trả về danh sách bảng thống kê số lượng điện thoại tồn kho và đã bán đã bán Phương thức kết nối
Kiểm thử dòng dữ liệu, Kiểm thử luồng điều kiển
NUnit Kiểm thử kết thúc khi chuyển tiếp đến trang cần yêu cầu
Phương thức thêm đối tượng (thêm dòng sản phẩm điện thoại khác) vào
Kiểm thử dòng dữ liệu
NUnit Kiểm thử kết thúc khi phương thức trả về giá trị true khi thêm được đối tượng vào csdl và ngược lại
Phương thức sửa đối tượng(sửa thông tin sản phẩm điện thoại) trong CSDL
Kiểm thử dòng dữ liệu
NUnit Kiểm thử kết thúc khi phương thức trả về giá trị true khi sửa được đối tượng vào csdl và ngược lại
Phương thức xóa đối tượng( sản phẩm đã hết hang ) khỏi
Kiểm thử dòng dữ liệu
NUnit Kiểm thử kết thúc khi phương thức trả về giá trị true khi xóa được đối tượng khỏi csdl và ngược lại
Kĩ thuật test Công cụ Tiêu chí hoàn thành
Thực hiện tích hợp từ các đơn vị thấp nhất đến cao hơn
Có thể sử dụng Netbean
Sau tích hợp có các lớp hoàn chỉnh với đầy đủ thuộc tính và phương thức cần thiết
Thực hiện tích hợp các modul đơn giản trước
Có thể sử dụng Netbean
Sau khi tích hợp ta được phần mềm hoàn chỉnh với đầy đủ các chức năng yêu cầu
Công việc Kiểu test Kĩ thuật test Công cụ Tiêu chí hoàn thành
Test những chức năng: Đăng nhập, đăng ký, sửa tài khoản
Kiểm thử tất cả các chức năng
Các tester kiểm thử toàn bộ các tính năng…của phần mềm
Không có công cụ sử dụng
Kiểm thử hoàn tất khi tất cả các tính năng đều đáp ứng yêu cầu của khách hàng sản phẩm
Quản lý thông tin khách hang
Chương trình đo lường
Data to be Purpose PIC When
Quality: No defects detected Đảm bảo yêu cầu
Sau khi Tester xem xét kiểm tra
Schedule Để kiểm tra dự án làm đến đâu.
PM Vào mỗi buổi chiều thứ 2 hàng tuần PM sẽ họp nhóm kiểm tra xem xét mức độ hoàn thành dự án
Quản lý nhân sự
Thông tin thành viên trong đội dự án
Họ tên Ngày sinh Địa chỉ Email Trình độ
Phạm Như Cảnh Hà Nội nhucanh082@gmail.com Đại học
Hà Nội doanviet0000@gmail.com Đại học
Hà Nội mrkezy1404@gmail.com Đại học
Trần Quang Đức Hà Nội ductq@gmail.com Đại học
16/06/1999 Hà Nội luong160699@gmail.com Đại học
Chức vụ trong đội dự án
STT Vị trí Trách nhiệm và công việc Kỹ năng Số lượng
1 Quản lý Quản lý mọi hoạt động của Quản lý dự án 1 dự án dự án
Tiếp nhận yêu cầu khách hàng và phân tích yêu cầu
Khả năng giao tiếp, giải quyết và phân tích vấn đề
Viết chương trình Tích hợp các mô-đun
Sử dụng các ngôn ngữ như Java, Javascript , và các công nghệ.
4 Quản trị cơ sở dữ liệu
Thiết kế, xây dựng hệ thống
Lập trình, thiết kế cơ sở dữ liệu
5 Kiểm thử Kiểm tra các lỗi trong phần mềm, báo cáo và đảm bảo chất lượng phần mềm
Danh sách và vai trò của đội dự án
Bộ phận Số lượng thành viên bộ phận
Vai trò Tên thành viên
Quản lý dự án 1 Quản lý dự án Phạm Như Cảnh
Thu thập yêu cầu 1 Phân tích dữ liệu
Nguyễn Việt Đoàn Thiết kế hệ thống, Lập trình viên
Quản trị cơ sở dữ liệu 1 Thành viên Trần Quang Đức
Kiểm thử 2 Thành viên Dương Quang
Đội dự án
Vai trò Trách nhiệm Trình độ chuyên môn Tên
Quản lý dự án Chịu trách nhiệm toàn bộ dự án Phân công công việc, theo dõi Lập kế hoạch, lập lịch
Giao tiếp tốt Khả năng lãnh đạo tốt
Am hiểu quy trình sản xuất phần mềm.
Thu thập yêu cầu khách hàng Phân tích yêu cầu
Kỹ năng phân tích và giải quyết vấn đề
Quản trị cơ sở dữ liệu
- Thiết kế toàn bộ cơ sở dữ liệu
- Nắm vững kiến thức lập trình
- Có kinh nghiệm trong thiết kế và quản trị hệ cơ sở dữ liệu
Thiết kế toàn bộ hệ thống Có kinh nghiệm thiết kế hệ thống
Lập trình Viết chương trình Biết sử dụng các công cụ phát triển phần mềm
Thành thạo một số ngôn ngữ lập trình
Khả năng đọc tài liệu tiếng Anh tốt
Kiểm thử Viết các test case, thực hiện test các mô-đun của chương trình.
Kỹ năng kiểm thử Dương
Ma trận kĩ năng
Javascript Java SQL Kiểm thử
Ma trận trách nhiệm
STT Mô tả Quản lý dự án
Nhóm thu thập yêu cầu
1 Lấy yêu cầu khách hàng và khảo sát A,C R
5 Kiểm thử và tích hợp A I R
6 Nghiệm thu và bàn giao khách hàng A,R I I I I
R: Người/bộ phận chịu trách nhiệm đầu mối triển khai
A: Người sẽ chịu trách nhiệm phê duyệt các dự án, kế hoạch đó
C: Đôi khi làm một dự án/kế hoạch nếu là R, trước khi đưa lên A duyệt thì cũng cần đâu đó những người tư vấn (tham mưu) để có thể hoàn thiện hơn khi làm
I: Những người mà có thể không làm gì trong dự án/chiến dịch đó, nhưng họ lại là người cần nắm thông tin.
Quản lý giao tiếp
Các thành phần tham gia
- Trưởng dự án: Phạm Như Cảnh
- Thành viên đội dự án:
- Đại diện khách hàng: Nguyễn Quỳnh Chi
Hình thức truyền thông và giao tiếp
2.1 Các kênh trao đổi thông tin giữa 2 bên
2.2 Trao đổi thông tin a Giữa các thành viên đội dự án
Người quản lý Bản tiến độ công việc
Nhóm phân tích Bản xác định yêu cầu
Nhóm thiết kế Bản phân tích yêu cầu
Nhóm cài đặt Bản thiết kế
Nhóm kiểm thử Bản thiết kế, bản yêu cầu b Giữa đội dự án và khách hàng
Khách hàng Tiến độ thực hiện dự án
Nhóm xác định yêu cầu Yêu cầu của khách hàng c Thông tin liên lạc
STT Vai trò trong dự án Họ và tên Thông tin liên lạc
1 Quản lý dự án Phạm Như Cảnh nhucanh082@gmail.com
2 Nhóm thu thập và phân tích
Nguyễn Việt Đoàn doanviet0000@gmail.com
3 Nhóm thiết kế và lập trình Hệ thống
Nguyễn Minh Hiếu mrkezy@gmail.com
4 Nhóm quản trị cơ sở dữ liệu
Trần Quang Đức ductq@gmail.com
4 Nhóm đảm bảo chất lượng và quản lí cấu hình
Dương Quang Lượng luong160699@gmail.com
5 Đại diện khách hàng Nguyễn Quỳnh Chi chinq@ptit.edu.vn
Cách kênh giao tiếp
3.1 Giữa các thành viên trong nhóm với quản lí dự án
+ Thông tin trao đổi: tiến độ công việc, các công việc đang gặp khó khăn, vướng mắc, các vấn đề tồn tại và hướng giải quyết.
+ Hình thức giao tiếp: gặp mặt trực tiếp, mạng xã hội, điện thoại,
3.2 Giữa đội dự án và khách hàng
+ Thông tin trao đổi: Tiến độ công việc, yêu cầu mới của khách hàng, những khó khăn trong việc tiếp nhận yêu cầu mới của khách hàng với bên đội dự án
+ Hình thức giao tiếp: Gặp mặt trực tiếp/online call.
+ Tần suất: Phụ thuộc và khách hàng và đội dự án cũng như tiến độ công việc.
Bảng chi tiết
Mục đích Cách thức giao tiếp
Thời gian Đối tượng tham gia
Bắt đầu dự án Nhóm thu thập yêu cầu và khách hàng
Tiếp nhận dự án từ khách hàng
Bàn bạc và thống nhất phân rã công việc
Sau khi tiếp nhận dự án Đội dự án Hoàn thành WBS
Trao đổi về kế hoạch quản lý truyền thông và giao tiếp
Gặp mặc trực tiếp, Zalo, Facebook,
Sau khi hoàn thành WBS Đội dự án Đưa ra các kênh giao tiếp để thực hiện dự án
Thông báo việc đã làm và kế hoạch thời gian tới
Gặp mặc trực tiếp, Zalo, Facebook,
Hàng tuần Đội dự án Tổng kết công việc đã giải quyết, vấn đề tồn đọng, hướng xử lí,cách tháo gỡ khó khăn
Sau khi hoàn thành việc cài đặt và kiểm thử Đội dự án và khách hàng
Khách hàng tiếp nhận sản phẩm
Quản lý cấu hình
Giới thiệu
Mục đích và nội dung chính của tài liệu này là xác định và mô tả quá trình thực hiện quản lý cấu hình trong dự án.
Tài liệu được viết ra cho các thành viên trong đội dự án có thể theo dõi và nắm bắt được các thay đổi trong quá trình xây dựng phần mềm.
● Mục đích của việc quản lý cấu hình : Giải quyết, né tránh rủi ro hoặc quản trị các yếu tố như:
○ Lỗi xuất hiện và cách xử lý lỗi.
○ Quản lý các phiên bản mã nguồn, tài liệu
● Phạm vi áp dụng : Áp dụng trong toàn dự án.
1.1 Vị trí và Trách nhiệm
STT Vị trí Họ và Tên Vai Trò & Trách Nhiệm
Phạm Như Cảnh Quản lý dự án, tiến độ lập kế hoạch dự án.
Nguyễn Việt Đoàn Tiếp xúc khách hàng để lấy yêu cầu nghiệp vụ, phân tích làm rõ yêu cầu khách hàng
Nguyễn Minh Hiếu Thiết kế hệ thống, lập trình hệ thống s3 Design Database Trần Quang Đức Thiết kế và quản trị CSDL
4 QA - Tester Dương Quang Lượng Nhân viên đảm bảo chất lượng phần mềm, Kiểm thử (QA)
1.2 Định nghĩa và tên viết tắt
Từ viết tắt Định nghĩa Ghi chú
ADD Architecture Design Document Tài liệu thiết kế kiến trúc hệ thống
Kiểm soát cấu hình cơ sở hạ tầng
CI Configuration Item Danh mục cấu hình
CM Configuration Management Quản lý cấu hình
Những danh mục cấu hình phần mềm máy tính DDD Detail Design Document Tài liệu thiết kế chi tiết
PM Project Manager Người quản lý dự án
PTL Project Technical Leader Trưởng nhóm kĩ thuật
PIC Person in Charge Người phụ trách
QA Quality Assurance Officer Người quản lý đảm bảo chất lượng.
Tài liệu yêu cầu đặc tả phần mềm
Source Source Code Mã nguồn
URD User Requirement Document Tài liệu yêu cầu người dùng
TP Test Plan Kế hoạch kiểm thử
TC Test Case Trường hợp kiểm thử
WIP Work in Progress Công việc đang tiến hành
WP Work product Sản phẩm
2 Quy trình quản lý cấu hình
2.1 Nhận biết các CI và quy tắc đặt tên
STT Mục cấu hình (CI) Mô tả Quy ước đặt tên
Tài liệu phân tích yêu cầu RAD
Tài liệu thiết kế hệ thống SDD
3 Unit Testing Kiểm thử đơn vị UT
4 Input Data and Database Dữ liệu đầu vào và cơ sở dữ liệu
5 Data Testing Kiểm tra dữ liệu DT
2.2 Quy trình quản lý cấu hình đường cơ sở
Lịch trình đường cơ sở dự án
STT Tên đường cơ sở
Tiêu chí đường cơ sở PIC
1 Startup Trong vòng 7 ngày từ khi bắt đầu dự án các yêu cầu phiên bản của cấu hình khởi động cơ bản phải được đáp ứng
2 Definition Khi có phương thức, giải pháp mới cho dự án CC
3 Solution Khi kiến trúc phiên bản V1 được phát hành CC
4 Construction Ngay sau khi kết thúc pha cài đặt CC
5 Transition Chuyển tiếp.Bàn giao sau khi hoàn tất kiểm thử và triển khai
6 Wrap-up Sau khi phiên bản cuối cùng được hoàn thiện tất cả các mục cấu hình phải được đáp ứng.
Cấu trúc danh mục và Quyền truy cập
Vùng dành cho những người dùng khác nhau lưu trữ các mục của mình.
Lưu trữ các mục đang sẵn sàng để duyệt lại, rà soát
Lưu trữ các mục đã thông qua hoặc đang chờ thông qua.
Lưu trữ các mục sẵn sàng phát hành và tất cả các phiên bản của các mục
Lưu trữ các phiên bản đã được phát hành cho mỗi mục cấu hình
Mục đích Ứng với vùng
WIP Deliverables Lưu trữ tất cả các mục cấu hình được giao bới khách hàng vào tên thư mục
Documents Tài liệu các bản thiết kế, kiểm thử, xác định yêu cầu
Modify: PM, CC,PIC Read: All
Lưu trữ thời gian họp dự án Chứa thời gian họp với khách hàng
Plan Lưu trữ danh sách đề xuất đánh giá, kế hoạch dự án, lịch trình dự án, các công việc và nhiệm vụ.
Modify: PM,CC,PTL Read: All
Report Lưu trữ các bản báo cáo dự án: Hàng tuần milestone, bản ghi chú được chấp thuận, các bản báo cáo hướng sự kiện
Record Lưu trữ hồ sơ dự án, được chia thành:
+Rà soát: hồ sơ duyệt lại, kiểm thử
+ Thay đổi yêu cầu +Chấp thuận
Source Lưu trữ mã nguồn Archive Refer to VSS directory
User Vùng làm việc của người dùng, lưu trữ các mục sở hữu của người dùng.
Lưu trữ tài liệu hỗ trwoj đội phát triển, cài đặt phần mềm do khách hàng cung cấp…
Lưu trữ tài liệu hướng dẫn tiêu chuẩn biểu mẫu
Audit Lưu trữ sản phẩm do người quản lý chất lượng thực hiện
Name Để phát hành phiên bản cấu hình tại đường cơ sở
Develop Subfolder 1 Lưu trữ mã nguồn cửa
Sub folder 2 Lưu trữ mã nguồn của
Test Subfolder 1 Lưu trữ những đoạn code mã nguồn sẵn sàng để kiểm thử
Sub folder 2 Lưu trữ những đoạn code mã nguồn đã được kiểm thử
Release Sub folder 1 Lưu trữ các phiên bản hoàn chỉnh để phát hành
Sub folder 2 Lưu trữ tài liệu hướng dẫn sử dụng
Quy tắc đặt tên phiên bản
- Phiên bản của tài liệu sẽ có dạng : a.b
- Phiên bản gốc sẽ được đánh số la 0.1 Các phiên bản sửa lại (revisions) tiếp theo sẽ được đánh số là 0.2, 0.3, …
- Phiên bản đầu tiên phát hành 1.0
- Những thay đổi lớn liên quan đến hệ thống : Thay đổi cơ chế hệ thống, nâng cấp nhiều chức năng trong hệ thống… thì phiên 1.0 sẽ lên thành 2., 3.0
- Những thay đổi nhỏ : thêm một chức năng theo yêu cầu của khách hàng, vá lỗi nhỏ sẽ phiên 1.0 sẽ trở thành 1.1, 1.2…
5.2 Dành cho phần mềm và các file mã nguồn
Các phần mềm thực thi và tệp hỗ trợ sẽ được xác định bằng tên và số phiên bản chẳng hạn như “MainDB v1.1.a
﹣ Version Number - Số phiên bản : xuất hiện ở bên trái của số thập phân.
Nó sẽ được cập nhật khi kiến trúc cốt lõi của mục phần mềm thay đổi, như khi một ứng dụng được đại tu hoàn toàn hoặc giao diện người dùng thay đổi cơ bản Trong trường hợp này, phiên bản 1.1a sẽ trở thành phiên bản 2.0.
﹣ Số sửa đổi - Revision Number : xuất hiện ở bên phải số thập phân Nó thay đổi khi các tính năng mới, chức năng hoặc nội dung khác được thêm vào hoặc làm thay đổi đáng kể hệ thống Trong trường hợp bình thường, kiến trúc cốt lõi hoặc giao diện người dùng đã được mở rộng hoặc hạn chế theo một số cách Lý do phổ biến nhất để thay đổi số sửa đổi là khi thêm mô-đun mới hoặc chức năng khác vào phần mềm Trình tự sửa đổi thông thường là 1.0, 1.1 và 1.2, v.v.
﹣ Mức cập nhật - Update level : được thêm vào hoặc tăng lên khi thay đổi duy nhất đối với mục phần mềm là sửa một hoặc nhiều lỗi mà không cần bổ sung bất kỳ chức năng mới nào Phiên bản 1.1 sẽ trở thành v1.1a,v1.1b, v.v Bản cập nhật này đã hết hiệu lực khi một bản sửa đổi kết hợp,bao gồm các bản sửa lỗi và bổ sung tính năng mới, được thực hiện.
Chiến lược sao lưu
Danh mục được sao lưu
Sao lưu vào Loại sao lưu
