QUẢN LÍ DỰ ÁN PHẦN MỀM

ĐỀ TÀI : PHẦN MỀM QUẢN LÍ BÁN VÉ XEM PHIM

THÀNH VIÊN B16DCCN084 : PHẠM MINH ĐỨC

B16DCCN123 : PHẠM THỊ LINH
B16DCCN125 : NGUYỄN HỒNG HẢI
B16DCCN387 :NGÔ VĂN TUẤN
B16DCCN405 :ĐOÀN THU VÂN
NỘI DUNG CHÍNH

PHÁT BIỂU BÀI TOÁN QUẢN LÍ TÀI NGUYÊN CON NGƯỜI

TÔN CHỈ DỰ ÁN QUẢN LÍ GIAO TIẾP VÀ TRUYỀN THÔNG

QUẢN LÍ THỜI GIAN, LẬP LỊCH QUẢN LÍ CHẤT LƯỢNG

QUẢN LÍ RỦI RO QUẢN LÍ CẤU HÌNH

S L I D E 2
I. PHÁT BIỂU BÀI TOÁN
1. TỔNG QUAN VỀ DỰ ÁN

1.1 MỤC ĐÍCH

Phần mềm tạo ra nhằm phục vụ các công việc đặt vé, bán
vé và thanh toán cho rạp chiếu phim một cách nhanh chóng
và thuận tiện hơn

1.2.ĐỐI TƯỢNG SỬ DỤNG

Nhân viên của rạp chiếu phim:
-Nhân viên bán vé
-Nhân viên quản trị hệ thống
-Nhân viên quản lí rạp

S L I D E 4
1.3 Phạm vi
* Phạm vi quản lí

Quản lí thông tin

- Thông tin phim Đặt vé Bán vé Thanh toán
- Thông tin rạp
- Thông tin phim

* Phạm vi không quản lí

Quản lí cơ sở vật Quản lí dịch vụ

Quản lí nhân sự chất
2. Chức năng

QUẢN LÍ PHIM VÀ PHÒNG CHIẾU ĐẶT VÉ

QUẢN LÍ TÀI KHOẢN THANH TOÁN

TÌM THÔNG TIN KHÁCH HÀNG XEM BÁO CÁO THÔNG KÊ

3. CÔNG NGHỆ

- Winform Appication with Java.

- Framework: Spring MVC.
- UI Design: Ngx-admin.
- Database Management: MongoDB.
* Các công cụ hỗ trợ lập trình: Visual Studio, Eclipse. Dbeaver.

S L I D E 6
4. CAM KẾT VỀ CHẤT LƯỢNG SẢN PHẨM
- Có đầy đủ chức năng theo yêu cầu của khách hàng
- Có bản đặc tả, hướng dẫn chi tiết cho người dùng
- Giao diện thân thiện với người dùng
- Có tính an toàn và bảo mật cao
- Được đăng kí bản quyền, không cung cấp mã nguồn cho bên thứ ba
- Có tài liệu mô tả hướng dẫn nâng cấp và bảo trì hệ thống khi cần
- thiết.

5. THỜI HẠN BÀN GIAO

- Thời hạn giao sản phẩm : 06 tháng kể từ ngày 15/8/2019
đến
15/02/2020.

6. CHI PHÍ
- Chi phí bảo trì hệ thống và sửa các lỗi phát sinh: 0đ.
- Tổng chi phí ước lượng: 0đ.

S L I D E 7
1. Tổng quan

1.1. Mô tả dự án
- Phần mềm được tạo ra nhằm phục vụ các công việc đặt vé, bán vé
và
thanh toán cho rạp chiếu phim. Bao gồm các chức năng đặt vé, bán
vé,
thanh toán và quản lý thông tin khách hàng và nhân viên.

1.2. Mục tiêu của dự án

- Phần mềm Quản lý bán vé rạp chiếu phim được tạo ra nhằm phục
vụ các công việc đặt vé, bán vé và thanh toán cho rạp chiếu phim 1
cách nhanh chóng và thuận lợi hơn.

S L I D E 9
1.3 Các phương pháp và cách tiếp cận

* Cách tiếp cận

- Khảo sát yêu cầu về giao diện và chức năng mà khách hàng
mong muốn xây dựng hệ thống.
- Tìm hiểu đối tượng khách hàng sử dụng hệ thống.
- Lựa chọn công nghệ phù hợp để phát triển hệ thống.
* Phương pháp
- Sử dụng ngôn ngữ Java để phát triển dự án
● Winform Appication with Java.
● Framework: Spring MVC.
- UI Design: Ngx-admin.
- Database Management: MongoDB.

S L I D E 1 0
2. Phạm vi
2.1 Sản phẩm bàn giao
- Quản lý thông tin người dùng, phim, rạp chiếu, khách
- Đặt vé
- Bán vé
- Hệ thống thanh toán
- Bộ máy tìm kiếm thông tin
- Cơ sở hạ tầng chô bảo mật
- Hệ thống đăng ký người dùng
- Quản lý thông tin giao dịch
- Xem báo cáo thống kê
2.2 Ngoài phạm vi dự án
- Quản lý nhân sự chấm công nhân viên
- Quản lý cơ sở vật chất
- Mua bỏng, nước

S L I D E 1 1
3. Ngân sách và lịch thực hiện chung
3.1. Ngân sách
- Tổng ngân sách: 0đ

3.2. Lịch thực hiện

- Ước tính thời gian phát triển hệ thống là 2 tháng
- Dự được dự định bắt đầu vào 01/03/2019 năm 2019 đến 10/05/2019
- Phiên bản đầu tiên dự định bàn giao trong vòng 5 tháng
- Cam kết bảo trì hệ thống định kỳ 6 tháng/ lần, thời gian bảo hành là 2 năm
và chịu trách nhiệm đảm bảo vận hành hệ thống không xảy ra lỗi.

S L I D E 1 2
4. Những người tham gia
Đội phát triển dự án.
- Người dùng: Nhân viên bán hàng, quản lý
- Người dùng: Khách hàng mua vé
- Khách hàng: Những người có nhu cầu xem phim tại các cụm rạp

5. Các giả thiết được thiết lập

- Hệ thống sẽ được xây dựng theo mô hình MVC
- Hệ thống sẽ chạy trên các tài nguyên của máy tính (điện thoại) và mạng có sẵn
- Khách hàng sẽ ký nhận các sản phẩm bàn giao trung gian trong vòng tuần sau mỗi lần bàn giao
- Đội phát triển dự án nội bộ sẽ thực hiện công việc
- Sản phẩm phải được đăng ký bản quyền, không cung cấp mã nguồn cho bên thứ ba
- Cung cấp các bản đặc tả, hướng dẫn sử dụng chi tiết cho người dung.
- Chúng tôi sẽ hợp tác với một bên thứ ba để tạo ra các hệ thống bảo mật

S L I D E 1 3
1. SƠ ĐỒ LẬP LỊCH TỔNG QUÁT
2. CHI TIẾT LẬP LỊCH VÀ THỰC HIỆN DỰ ÁN
- Ước tính thời gian từ lúc kích hoạt dự án tới lúc hoàn thành dự án là 3-6 tháng.
- Dự án bắt đầu từ ngày 1/3/2019 và kết thúc vào ngày 10/5/2019(không tính ngày thứ
7, chủ nhật và các ngày nghỉ lễ).

2.1 Các mốc thời gian quan trọng của dự án

STT Tên công việc Ngày bắt đầu Ngày kết thúc Thời gian

1 Quản lý dự án phần 1/3/2019 1/3/2019 1 ngày

mềm
2 Lấy yêu cầu 04/03/2019 28/03/2019 15 ngày

3 Phân tích 25/3/2019 28/3/2019 4 ngày

4 Thiết kế 29/3/2019 5/4/2019 6 ngày

5 Cài đặt 8/4/2019 29/4/2019 16 ngày

6 Kiểm thử 2/5/2019 9/5/2019 6 ngày

7 Triển khai với khách 10/5/2019 10/5/2019 1 ngày

hàng
S L I D E 1 7
2. CHI TIẾT LẬP LỊCH VÀ THỰC HIỆN DỰ ÁN
2.2 Thời gian thực hiện công việc chi tiết
2.2.1 Giai đoạn 1: Quản trị dự án phần
mềm

2.2.2 Giai đoạn 2: Lấy yêu cầu

2.2.3 Giai đoạn 3: Phân tích hệ thống

S L I D E 1 8
2.2.4 Giai đoạn 4: Thiết kế hệ thống.

2.2.5 Giai đoạn 5: Cài đặt hệ thống.

S L I D E 1 9
2.2.6 Giai đoạn 6: Kiểm thử hệ thống.

2.2.7 Giai đoạn 7: Triển khai với khách hàng.

S L I D E 2 0
1. Lên kế hoạch quản lý rủi ro.
1.1. Chính sách quản lý rủi ro.
-Rủi ro trong thời gian thực hiện dự án là không thể tránh khỏi. Đầu tiên phải xác định rủi ro càng sớm càng tốt để giảm tối
thiểu thiệt hại cho nó gây lên.
-Xác định trách nhiệm của mỗi thành viên trong đội dự án để khắc phục hậu quả.
1.2. Khả năng chấp nhận rủi ro
- Khi xác định rủi ro và phân rõ trách nhiệm từng thành viên. Thành viên đôi khi phải chấp nhận rủi ro. Bắt tay vào công việc
để giảm thiểu tác hại do rủi ro gây lên.
1.3. Các công cụ và kỹ thuật.
- Lập kế hoạch cho các buổi thảo luận, báo cáo về tình trạng công việc bao gồm:
● Phương pháp giảm thiểu rủi ro.
● Xác định thời gian, mức độ gây hậu quả.

S L I D E 2 2
2. Xác định rủi ro
2.1. Rủi ro về phần mềm

S L I D E 2 3
II. Xác định rủi ro
2.2. Rủi ro về khách hàng

S L I D E 2 4
II. Xác định rủi ro
2.3. Rủi ro về kinh phí

S L I D E 2 5
II. Xác định rủi ro
2.4. Rủi ro về tiến trình

S L I D E 2 6
II. Xác định rủi ro
2.5. Rủi ro về con người

S L I D E 2 7
3. Phân tích rủi ro
Mã Sự kiện rủi ro Người chịu trách nhiệm Phạm vi ảnh hưởng (W/B/S) Ảnh hưởng Mức độ nghiêm trọng
của rủi ro

1 Nghiệp vụ khi thiết kế phần mềm, nhân viên Toàn bộ nhân viên Ngân sách (B)/thỏa mãn khách Rất cao Rất cao
vẫn chưa nắm rõ. hàng(S).

2 Thiết bị hỗ trợ bên ngoài gặp trục trặc hoặc Giám đốc dự án Ngân sách (B)/thỏa mãn khách Thấp Trung bình
lỗi. hàng(S).

3 Thời gian hoàn thành dự án quá hạn. Giám đốc dự án Thành công(W)/Ngân sách (B)/thỏa Rất cao Rất cao
mãn khách hàng(S).

4 Thiết kế khách hàng không phù hợp. Giám đốc dự án Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).

5 Kiểm soát mã nguồn không tốt. develop Thành công(W)/Ngân sách (B)/thỏa Cao Trung bình
mãn khách hàng(S).

6 Thay đổi các trang thiết bị hỗ trợ . Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Thấp Trung bình
mãn khách hàng(S).

7 Không được khách hàng hỗ trợ . Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Trung bình Trung bình
mãn khách hàng(S).

S L I D E 2 8
3. Phân tích rủi ro
Mã Sự kiện rủi ro Người chịu trách nhiệm Phạm vi ảnh hưởng (W/B/S) Ảnh hưởng của rủi Mức độ nghiêm
ro trọng

8 Khách hàng cần bổ sung thêm tính năng . Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).

9 Khách hàng chậm tiền. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Trung bình Trung bình
mãn khách hàng(S).

10 Kinh phí về nhân sự vượt quá. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Trung bình Trung bình
mãn khách hàng(S).

11 Nghiệp vụ phát sinh kinh phí. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Thấp Thấp
mãn khách hàng(S).

12 Các thiết bị phát sinh cần mua. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Trung bình Thấp
mãn khách hàng(S).

13 Các ứng dụng ngoài phát sinh. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Thấp Thấp
mãn khách hàng(S).

14 Lên kế hoạch thiếu. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).
S L I D E 2 9
3. Phân tích rủi ro
Mã Sự kiện rủi ro Người chịu trách nhiệm Phạm vi ảnh hưởng (W/B/S) Ảnh hưởng của rủi Mức độ nghiêm
ro trọng

15 Một số công nghệ cũ không còn được sử dụng develop Thành công(W)/Ngân sách (B)/thỏa Trung bình Trung bình
trong thời điểm hiện tại. mãn khách hàng(S).

16 Thiết kế thiếu chức năng cho khách hàng. designer Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).

17 Lãng phí thời gian Tất cả thành viên. Thành công(W)/Ngân sách (B)/thỏa Rất cao Cao
mãn khách hàng(S).

18 Không đúng tiến độ Tất cả thành viên. Thành công(W)/Ngân sách (B)/thỏa Rất cao Rất cao
mãn khách hàng(S).

19 Thành viên trong nhóm không hoà hợp. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Trung bình . Cao
mãn khách hàng(S).

20 Xung đột giữa các thành viên trong nhóm. Tất cả thành viên. Thành công(W)/Ngân sách (B)/thỏa Trung bình Trung bình
mãn khách hàng(S).

21 Xung đột với khách hàng. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Cao Trung bình
mãn khách hàng(S).
S L I D E 3 0
3. Phân tích rủi ro

Mã Sự kiện rủi ro Người chịu trách nhiệm Phạm vi ảnh hưởng (W/B/S) Ảnh hưởng của rủi Mức độ nghiêm
ro trọng

22 Thiếu người tham gia dự án. Tất cả thành viên. Thành công(W)/Ngân sách (B)/thỏa Trung bình Trung bình
mãn khách hàng(S).

23 Làm việc không hiệu quả. Tất cả thành viên. Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).

24 Thành viên rời đi khi dự án đang thực hiện. Thành viên. Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).

25 Thành viên làm việc theo ước muốn. Giám đốc dự án. Thành công(W)/Ngân sách (B)/thỏa Cao Cao
mãn khách hàng(S).

S L I D E 3 1
4. Cách giải quyết rủi ro
Mã Sự kiện rủi ro Chiến lược làm giảm nhẹ Công việc làm giảm nhẹ

1 Nghiệp vụ khi thiết kế phần mềm, nhân viên vẫn chưa nắm Làm giảm xuất. Liên tục rà soát ứng dụng trong các milestone tránh trường hợp
rõ. làm sai nghiệp vụ.

2 Thiết bị hỗ trợ bên ngoài gặp trục trặc hoặc lỗi. Tránh gây rủi ro. Lựa chọn nhà cung cấp thiết bị uy tín.

3 Thời gian hoàn thành dự án quá hạn. Làm giảm xác suất. Thương lượng với khách hàng.

4 Thiết kế khách hàng không phù hợp. Làm giảm xác suất. - Liên tục đàm phán với bên khách hàng.
- Nhân viên bắt buộc phải nắm rõ nghiệp vụ.
- Design cần nắm rõ thiết kế của ứng dụng.

5 Kiểm soát mã nguồn không tốt. Tránh gây rủi ro. -Sử dụng phần mềm quản lý mã nguồn.
- Đào tạo cho nhân viên cách sử dụng để tránh gây ra mất mát
hoặc kiểm soát mã nguồn không tốt.

6 Thay đổi các trang thiết bị hỗ trợ trong quá trình phát triển Chấp nhận và mặc kệ rủi ro. - Nắm rõ những công việc cần thiết sử dụng trang thiết bị bên
dự án. ngoài trong toàn bộ dự án.
- Phân tích trường hợp sử dụng để lựa chọn thiết bị phù hợp.
S L I D E 3 2
4. Cách giải quyết rủi ro
Mã Sự kiện rủi ro Chiến lược làm giảm nhẹ Công việc làm giảm nhẹ

7 Không được khách hàng hỗ trợ . Làm giảm xác suất. -Đòi hỏi khách hàng cần phải hỗ trợ đội phát triển trong quá
trình gia công.

8 Khách hàng cần bổ sung thêm tính năng . Làm giảm xác suất. - Liệt kê chức năng, nghiệp vụ của ứng dụng trong bản SOW.
- Tôn chỉ dự án cần chỉ rõ phần thiết kế và nghiệp vụ của từng
chứng năng tránh hiểu nhầm cho khách hàng .
- Hợp đồng chặt chẽ gói gọn trong các chức năng đã thoả thuận.

9 Khách hàng chậm tiền. Làm giảm xác suất. - Thái độ nhã nhặn với khách hàng.

10 Kinh phí về nhân sự vượt quá. Làm giảm xác suất. -Giám sát chặt chẽ quá trình gia công.
- Bố trí thêm hoặc tách người khỏi dự án dựa trên mô hình làm
việc.

11 Nghiệp vụ phát sinh trả phí. Chấp nhận và mặc kệ rủi ro. -Cố gắng tìm phương khác.
- Có thể sử dụng phương pháp trả phí.

12 Các thiết bị phát sinh cần mua. Chấp nhận và mặc kệ rủi ro. -Có thể sử dụng phương pháp trả phí.

S L I D E 3 3
4. Cách giải quyết rủi ro
Mã Sự kiện rủi ro Chiến lược làm giảm nhẹ Công việc làm giảm nhẹ

13 Các ứng dụng ngoài phát sinh. Chấp nhận và mặc kệ rủi ro. -Tìm cách giải quyết khác.
-Có thể sử dụng phương pháp trả phí.

14 lên kế hoạch không đầy đủ.. làm giảm xác suất. -Thường xuyên tổ chức các buổi họp cả đội phát triển
-Lắng nghe các góp ý về kế hoạch của cả đội..
-Bổ xung thêm các kế hoạch chưa có trong bản kế hoạch.

15 Một số công nghệ cũ không còn được sử dụng trong thời Chấp nhận và mặc kệ rủi ro, -Tìm công nghệ mới.
điểm hiện tại. Chuyển toàn bộ hay một phần rủi -Trong trường hợp không tìm được, có thể thương lượng lại với
ro. khách hàng để tìm phương án giải quyết mới.

16 Thiết kế thiếu chức năng. làm giảm xác suất. -Thường xuyên tổ chức các buổi rà soát phần mềm.
-Đàm phán với khách hàng.

17 Lãng phí thời gian. Làm giảm xác suất. -Đẩy nhanh giai đoạn bắt đầu cũng như kết thúc dự án.
- Tránh các khoảng thời gian chết giữa các đội.

18 Không đúng tiến độ. Mất uy tín gây tổn thất kinh tế. -Đội Test cần thực hiện test kỹ các chức năng tránh các lỗi
nghiêm trọng có thể xảy ra trong quá trình chạy phần mềm.
- Đội develop cần nắm rõ nghiệp vụ,Stránh
L I giấu
D Elỗi. 3 4
4. Cách giải quyết rủi ro
Mã Sự kiện rủi ro Chiến lược làm giảm nhẹ Công việc làm giảm nhẹ

19 Thành viên trong nhóm không hoà hợp. Chấp nhận và mặc kệ rủi ro. - Tổ chức các buổi teambuilding gắn kết các thành viên trong
đội.
- Thường xuyên có các buổi nói chuyện giữa các thành viên.

20 Xung đột giữa các thành viên trong nhóm. làm giảm xác suất. -Người quản lý cần nắm rõ từng tính cách của thanh viên để
tránh việc xung đột.

21 Xung đột giữa đội phát triển với khách hàng. Làm giảm xác suất. - Phải tạo cho khách hàng điều kiện tốt nhất để hoàn thành dự
án.

22 Thiếu sự hỗ trợ của người tham gia dự án. Chấp nhận và mặc kệ rủi ro. - Gắn kết các thành viên với nhau, hoà hợp được với nhau thì
việc hỗ trợ lẫn nhau dễ dàng hơn.

23 Làm việc không hiểu quả.. làm giảm xác suất. -Tạo động lực cho các thành viên trong nhóm bằng các phần
thưởng.
-Tạo thời gian thư giãn cần thiết cho nhân viên.

24 Thành viên rời đi khi dự án đang thực hiện. làm giảm xác suất - Hợp đồng rõ ràng với từng nhân viên,
- Tạo môi trường thoải mái nhất cho nhân viên..

25 Thành viên làm việc theo ước muốn. làm giảm xác suất.. -Tìm hiểu tính cách của từng cá nhân,S Lcần
I phải
D E dứt3khoát
5 trong
quá trình làm việc đối với các cá nhân có cái tôi lớn.
5. Kiểm soát rủi ro

- Thu thập và báo cáo thông tin về thực hiện công việc giảm thiểu rủi ro.
- Đánh giá các phương pháp giảm hiểu rủi ro.
- Kiểm tra từng bước khi thực hiện giảm thiểu rủi ro, đề phòng rủi ro mới xảy ra.
- Thay đổi yêu cầu dự án nếu cần vì những rủi ro gặp phải.
- Thay đổi tài liệu của dự án.

S L I D E 3 6
Kế Hoạch Quản Lí Nhân Sự
Vai trò trách nhiệm
STT Vị trí Trách nhiệm Kỹ năng yêu cầu Số lượng

1 Quản lý đội dự án (PM). Quản lý đội dự án - Kỹ năng lãnh đạo. 01

2 Chuyên viên phân tích
nghiệp vụ doanh nghiệp
(BA).
3 Kỹ sư phân tích thiết kế hệ
thống (SA).
4 Kỹ sư lập trình (Lập trình
viên - DEV).
5 Đảm bảo chất lượng phần
mềm/ Kỹ sư kiểm thử
(Tester).
6 Đảm bảo quy trình (QA).
Phân tích mô hình nghiệp vụ
bên phía khách hàng.
Phân tích thiết kế hệ thống.
Thiết kế, cài đặt và bảo trì
CSDL.
Viết mã nguồn chương trình,
thiết kế giao diện.
Đảm bảo chất lương, kiểm
thử phần mềm.
Kiểm tra hiệu năng, chất
lượng phần mềm.
- Kỹ năng đàm phán.
- Có kinh nghiệm quản lý dự
án và quản lý con người.
- Kỹ năng giao tiếp tốt. 01
- Kỹ năng phân tích mô hình
kinh doanh.
- Kỹ năng phân tích thiết kế. 02
- Làm việc thành thạo với
các DBMS, đặc biệt là SQL
Server và My SQL.
- Thành thạo ngôn ngữ Java 04
- Có hiểu biết về Blackbox 01
Test, Whitebox Test, viết
Testcase.
- Có hiểu biết về kiểm 01
tra hiệu năng, chất
lượng phần mềm.

S L I D E 3 8
1. MA TRẬN KĨ NĂNG

Phân tích mô hình Phân tích thiết kế hệ Thiết kế cơ sở dữ diệu Viết mã nguồn
nghiệp vụ thống
Phạm Minh Đức
X
Nguyễn Hồng Hải
X X X
Ngô Văn Tuấn
X X X
Phạm Thị Linh
X
Đoàn Thu Vân
X

S L I D E 3 9
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN

1.1 Kế hoạch tuyển dụng

Giai đoạn Vị trí Số lượng Thời gian

PM 1 08/02/2019 – 28/02/2019
Khởi tạo dự án

BA 1 04/03/2019 – 22/03/2019
Lấy yêu cầu

BA,SA 1 25/03/2019 – 28/03/2019

Phân tích

SA 1 29/03/2019 – 05/04/2019
Thiết kế

Dev 3 08/04/2019 – 29/04/2019

Cài đặt
QA 1

S L I D E 4 0
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN
1.2 Kế hoạch đào tạo
Vị trí Nội dung đào tạo Thời gian đào tạo
PM Quản lý nhân sự. 2 ngày
Quản lý lập lịch. 2 ngày
Quản lý rủi ro. 1 ngày
SA Cơ sở dữ liệu. 2 ngày
Thiết kế giao diện theo yêu cầu khách hàng. 2 ngày
Tối hóa cài đặt. 3 ngày
Cài đặt cho từng chức năng. 3 ngày
DEV Viết junit test. 1 ngày
Tích hợp các chức năng. 2 ngày
Tester Blackbox Test. 2 ngày
Whitebox Test. 2 ngày
Viết Testcase cho từng sản phẩm. 2 ngày
BA Xác định yêu cầu. 3 ngày
Viết Usercase Diagram. 1 ngày
Xác định mô hình nghiệp vụ. 2 ngày
QA Kiểm tra hiệu năng, chất lượng phần mềm. 3 ngày

S L I D E 4 1
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN
1.3 Phân bố nhân sự và công việc cho đúng
STT Họ và tên Vị trí

1 Phạm Minh Đức - Quản lý đội dự án.

2 Nguyễn Hồng Hải
3 Ngô Văn Tuấn
4 Phạm Thị Linh
- Chuyên viên phân tích nghiệp vụ.
- Kỹ sư phân tích thiết kế hệ thống.
- Kỹ sư thiết kế cơ sở dữ liệu.
- Lập trình viên.
- Kỹ sư phân tích thiết kế hệ thống.
- Kỹ sư thiết kế cơ sở dữ liệu.
- Lập trình viên.
- Lập trình viên.

5 Đoàn Thu Vân - Đảm bảo chất lượng phần mềm.

- Lập trình viên.

S L I D E 4 2
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN

1.4 Ma trận phân chia trách nhiệm:

WBS Công việc Phạm Minh Đức Nguyễn Hồng Hải Ngô Văn Tuấn Phạm Thị Linh Đoàn Thu Vân

1 Quản trị dự án
phần mềm.
2 Xác định yêu cầu.

2.1 Thu thập và phân tích L S C C R

yêu cầu về hệ thống.
2.2 Làm việc với chuyên L S
gia nghiệp vụ để tìm
hiểu về quy trình
nghiệp vụ.
2.3 Xác định các đối A L
tượng tham gia hệ
thống.
2.4 Xác định yêu cầu về A L C C R
các chức năng hệ
thống
2.5 Vẽ usecase tổng quan A L S C R
và chi tiết

S L I D E 4 3
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN

1.4 Ma trận phân chia trách nhiệm:

WBS Công việc Phạm Minh Nguyễn Hồng Ngô Văn Tuấn
Đức Hải

3 Phân tích.

3.1 Viết kịch bản chi tiết A L R,C C

cho từng chức năng.

3.2 Xác định các lớp A L R,C C

thực thể.

3.3 Viết báo cáo đặc tả A C

phần mềm.

3.4 Thẩm định và thông A

qua đặc tả phần
mềm.

S L I D E 4 4
1.4 Ma trận phân chia trách nhiệm:
WBS Công việc Phạm Minh Đức Nguyễn Hồng Hải Ngô Văn
Tuấn
4 Thiết kế.
4.1 Thiết kế chi tiết các chức năng.
4.1.1 Thiết kế module quản lý phim. L,C R,C,S C
4.1.2 Thiết kế module quản lý phòng chiếu. L,C R,C,S C
4.1.3 Thiết kế module lên lịch chiếu. L,C R,C,S C
4.1.4 Thiết kế module quản lý đặt vé. L,C R,C,S C
4.1.5 Thiết kế module quản lý nhân sự. L,C R,C,S C
4.1.6 Thiết kế module quản lý nhập phim L,C R,C,S C
4.1.7 Thiết kế module quản lý dịch vụ khác( bỏng, nước,...). L,C R,C,S C
4.1.8 Thiết kế module quản lý khách hàng. L,C R,C,S C
4.1.9 Thiết kế module đặt vé tại quầy. L,C R,C,S C
4.1.10 Thiết kế module xem các loại báo cáo thống kê. L,C R,C,S C
4.1.11 Thiết kế module tìm kiếm phim. L,C R,C,S C
4.1.12 Thiết kế module đặt/hủy vé online cho khách hàng. L,C R,C,S C
4.1.13 Thiết kế module cho chức năng thống kê phim và vé đã L,C R,C,S C
mua.
4.2 Thiết kế giao diện cho các chức năng. L C C
4.3 Viết tài liệu đặc tả thiết kế. L C C
4.4 Thẩm định và thông qua tài liệu thiết kế. A R,L

S L I D E 4 5
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN
1.4 Ma trận phân chia trách nhiệm:
WBS Công việc Phạm Minh Đức Nguyễn Hồng Hải Ngô Văn Tuấn
5 Cài đặt
5.1 Cài đặt cơ sở dữ liệu.
5.2 Cài đặt các modul.
5.2.1 Cài đặt module quản lý phim. L,R C

5.2.2 Cài đặt module quản lý phòng chiếu. C L,R C

5.2.3 Cài đặt module lên lịch chiếu. C L,R
5.2.4 Cài đặt module quản lý đặt vé. C C L,R
5.2.5 Cài đặt module quản lý nhân sự. L,R C
5.2.6 Cài đặt module quản lý nhập phim. C L,R C
5.2.7 Cài đặt module quản lý dịch vụ khác( bỏng, L,R C
nước,...).
5.2.8 Cài đặt module quản lý khách hàng. C L,R
5.2.9 Cài đặt module đặt vé tại quầy. C L,R
5.2.10 Cài đặt module xem các loại báo cáo thống kê. C C L,R
5.2.11 Cài đặt module tìm kiếm phim. C C L,R
5.2.12 Cài đặt module đặt/hủy vé online cho khách L,R C
hàng.
5.2.13 Cài đặt module cho chức năng thống kê phim và C L,R C
vé đã mua.
5.3 Kiểm thử cho từng modul. L,C,R L,R L,R L,R
5.4 Tích hợp các modul. L C C C
S L I D E 4 6
KẾ HOẠCH QUẢN LÍ NHÂN VIÊN

1.4 Ma trận phân chia trách nhiệm:

WBS Công việc Phạm Minh Đức Nguyễn Hồng Hải Ngô Văn Tuấn
6 Kiểm thử
6.1 Kiểm thử tích hợp. S C C C L
6.2 Kiểm thử hệ thống. S C C C L
6.2.1 Kiểm thử hiệu năng. S C C C L
6.2.2 Kiểm thử chức năng. S C C C L
6.2.3 Kiểm thử khả năng chịu lỗi. S C C C L
6.3 Kiểm thử chấp nhận. S C C C L
6.4 Lập tài liệu. R L
7 Triển khai với khách hàng.
7.1 Cài đặt phần mềm với khách hàng. L S
7.2 Hướng dẫn người dùng. L S

A (Approval): Xem xét, phê duyệt

L (Lead): Chịu trách nhiệm đứng đầu.
S (Secondary): Chịu trách nhiệm thứ hai sau Lead.
C (Contributor): Người đóng góp.
R (Reviewer): Người đánh giá, xem xét lại

S L I D E 4 7
1. Mô tả chung

Quản lý giao tiếp là quy trình quản lý quy trình giao tiếp dựa
vào các thông tin cần thiết và yêu cầu của các bên có liên
quan đến dự án.
Xác định các bên liên quan: Đội phát triển dự án, khách
hàng.
Đội phát triển dự án: Cần nhận những thông tin như yêu cầu,
thay đổi yêu cầu của khách hàng, báo cáo tiến độ công việc.
Khách hàng: Cần nhận những thông tin thông báo của đội
phát triển. Gửi đi những thay đổi yêu cầu của phần mềm

S L I D E 4 9
 2. Bảng quản lý truyền thông
Đối tượng nhận Nội dung truyền thông Phạm vi quan tâm Kênh truyền tin Thời gian Người gửi
Các thành viên dự án - Thời gian cần hoàn thành công việc Quản lý toàn bộ hoạt động Email/Pdf Mỗi ngày Trưởng dự án
dự án
- Yêu cầu với mỗi thành viên

Trưởng nhóm dự án - Báo cáo tiến độ Thiết kế chức năng Email/Pdf 3 ngày/1 lần Lập trình viên
- Thông tin chi tiết của công việc
- Những vấn đề khó khăn gặp phải và hướng giải quyết
Trưởng nhóm dự án - Báo cáo tiến độ Thiết kế giao diện cho sản Email/Pdf 1 ngày/1 lần Lập trình viên
- Thông tin chi tiết của công việc
- Những vấn đề khó khăn gặp phải và hướng giải quyết
Kiểm thử Trạng thái và tiến độ công. Tình trạng sản phẩm. Kiểm thử Email/Pdf 3 ngày/1 lần Trưởng nhóm
dự án
Lập trình viên Báo cáo những lỗi hiện đang có trên hệ thống Chức năng của hệ thống Email/Pdf Sau thời gian Nhân viên
kiểm thử kiểm thử

Thành viên dự án - Tổng hợp thông tin từng bộ phận. Báo cáo tiến độ, tình Những công việc đang làm Họp mặt Cuối tuần Trưởng nhóm
trạng công việc dự án
- Những vấn đề khó khăn gặp phải và hướng giải quyết
- Thái độ thực hiện công việc của các thành viên
Khách hàng Thông báo tiến độ, tính năng của sản phẩm. Đánh giá sản phẩm Email/Pdf 2 tuần Trưởng nhóm
dự án

S L I D E 5 0
1. Chiến lược phòng ngừa.
Các lỗi
Yêu cầu thiếu, bị sót
Lỗi bất cẩn trong thiết kế tài liệu
Tuân thủ không chặt chẽ yêu cầu
Code khác với thiết kế
Chiến lược Lợi ích
- Đối chiếu với bản yêu cầu về sản phẩm của khách - Giảm nhiều tỷ lệ “không đạt chất lượng” trong quá
hàng. trình thực hiện.
- Liên hệ với khách hàng để làm rõ. - Nâng cao hiệu suất.
- tìm kiếm tài liệu đặc tả yêu cầu trong các thư mục
cấu hình sao lưu.
- Xác định đúng phạm vi dự án, phân công công việc
rõ ràng
- Review lại nhiều lần trong quá trình viết. - Lợi ích về hiệu xuất vì nhiều lỗi sẽ được phát hiện
sớm.
- Kết hợp với các bản như SOW, tôn chỉ dự án, so sánh
với các tài liệu thiết kế. - Loại bỏ được những khiếm khuyết sẽ xảy ra.
- Xem xét kỹ trước khi bắt đầu thực hiện xây dựng sản
phẩm.
- Mỗi chức năng cần viết testcase cụ thể. Không phải làm lại nhiều lần các chức năng. giảm
đáng kể thời gian làm việc
- Lựa chọn bộ data phù hợp với testcase.
- Sử dụng công cụ phù hợp để test các chức năng.
- Đối chiếu với thiết kế. Giảm đáng kể thời gian làm việc
- Đối chiếu với bản demo gửi cho khách.
S L I D E 5 2
2. Chiến lược kiểm tra.
Sản xuất Phê bình Loại đánh giá Phương pháp Tiêu chuẩn hoàn thành
Sản phẩm Nhóm hoặc 1 người đánh - Danh sách kiếm tra hoặc không Đảm bảo sản phẩn được review lại bởi
giá - Các công cụ được sử dụng PM ít nhất 1 lần
- tự xem xét
- Kế hoạch dự án Quản lý , QA, - Nhóm đánh giá Xem dự án có phát triển đúng với tiến độ, kế -Tính khả thi
- Tiến độ dự án PTL, khách - Nhóm đánh giá hoạch đề ra ko ? Dự án còn khả năng phát triển -Tính chính xác
- Kế hoạch CM hàng - 1 người đánh giá tiếp ko? -Thời gian thực hiện
Phân tích kinh doanh và Nhóm đánh giá
các giấy tờ đặc điểm kỹ
thuật, sử dụng Danh mục
vụ
Tài liệu thiết kế, mô hình Nhóm đánh giá Tài liệu thiết kế hệ thống tổng quan Tài liệu Thiết kế của hệ thống có hơp Tài liệu
đối tượng thiết kệ hệ thống con/chi tiết Mô hình đc sử thiết kế có dễ đọc, hiểu
dụng
Kế hoạch giai đoạn Đánh giá một người Dự án có phát triển đúng tiến độ ko, dự án còn Dự án phải hoàn 100% tiến độ đề ra Dự
khả năng thực hiện các giai đoạn tiếp ko? án còn khả năng tiếp tục thực hiện trong
thơi gian tới

Mã code Tự đánh giá hay Nhóm đánh giá Code có đúng theo thiết kế ko, có đúng tiến độ Code đúng tiêu chuẩn đầu ra
Team Lead ko?
đánh giá hoặc
đánh giá Peer

Cài đặt Nhóm đánh giá,KH Kiểm thử khả năng vận hành. Cài đặt được Đảm bảo cài đặt thành công trên các
trên máy KH hay ko Có lỗi gì phát sinh ko máy của KH Nếu có lỗi, phải thương
lượng vơi KH và tiếp tục fix lỗi Hệ
thống dễ dàng được bảo trì và nâng cấp
S L I D E 5 3
3. Ước tính.
Số mục tiêu của các
% của khiếm khuyết được phát
Đánh giá khiếm khuyết được Cơ bản để ước tính
hiện
phát hiện
Yêu cầu xem lại 15 11% Tham chiếu dự toán dự án tương tự

Xem xét thiết kế 14 9% Tham chiếu dự toán dự án tương tự

Đang xem xét 29 20% Tham chiếu dự toán dự án tương tự

Đơn vị kiểm tra 57 40% Tham chiếu dự toán dự án tương tự

Hội nhập kiểm tra 15 10.2% Tham chiếu dự toán dự án tương tự

Hệ thống thử nghiệm 10 6.8% Tham chiếu dự toán dự án tương tự

Người sử dụng kiểm tra chấp nhận 5 3% Tham chiếu dự toán dự án tương tự

Tổng 143 100%

S L I D E 5 4
1. Giới thiệu

Ý nghĩa của việc quản lý cấu hình:

- Đảm bảo phần mềm được cập nhật và thực hiện các chức năng một cách chính xác.

Việc quản lý cấu hình tốt có thể giải quyết hoặc tránh được một số lỗi như:
- Bug đã tốn nhiều công sức để sửa lại xuất hiện trở lại.
- Mã nguồn đã viết cho một chức năng thất lạc.
- Một chức năng đã được kiểm thử không chạy được nữa.
- Một module có thể có nhiều source code với nhiều version khác nhau, khi tích hợp cần phải biết rõ mà nguồn nào version nào cần được
sử dụng…

Phạm vi áp dụng.
Được hoàn thành trong pha lập kế hoạch và được sử dụng cho các bộ phận:
- Quản trị cấu hình.
- Toàn bộ các pha trong dự án.

Mục đích
- Thiết lập, bảo đảm tính toàn vẹn của sản phẩm trung gian cũng như sản phẩm cuối cùng trong tất cả các pha của dự án.
- Kiểm soát thay đổi hệ thống.
- Thiết lập môi trường phát triển – xây dựng, tổ chức thư mục kho dữ liệu lưu trữ cho dự án.
2. Quy trình quản lý cấu hình
2.1 Quy ước nhận dạng và đặt tên CI
2.1.1 Các mẫu cấu hình:
Phần mềm quản lý bán vé xem phim
SM 1. Khởi tạo dự án
SM 1.1 Tài liệu khởi tạo dự án
PM 2. Lập kế hoạch
PM 2.1 Tài liệu lập kế hoạch dự án Project Plan
PM 2.2 Tài liệu kế hoạch quản lý cấu hình Configuration Management Plan
PM 2.3 Project Charter
PM 2.4 WBS
PM 2.5 Bản báo cáo sau giai đoạn lập kế hoạch
BA 3. Xác định yêu cầu
BA 3.1 Tài liệu khảo sát yêu cầu
BA 3.2 Tài liệu phân tích yêu cầu
BA 3.3 Tài liệu đặc tả yêu cầu ( RSD )
BA 3.4 Tài liệu đặc tả yêu cầu phần mềm ( SRS )
BA 3.5 Tài liệu yêu cầu người sử dụng ( URD )
BA 3.6 Bản báo cáo giai đoạn xác định yêu cầu
SA 4. Thiết kế
SA 4.1 Bản thiết kế tổng thể
SA 4.2 Bản thiết kế chức năng
SA 4.3 Bản thiết kế giao diện
SA 4.4 Bản thiết kế CSDL
SA 4.5 Bản báo cáo sau giai đoạn thiết kế
2. Quy trình quản lý cấu hình
2.1 Quy ước nhận dạng và đặt tên CI
2.1.1 Các mẫu cấu hình:
Phần mềm quản lý bán vé xem phim
C 5. Cài đặt
C 5.1 File database của hệ thống
C 5.2 File tập hợp mã nguồn của modul quản lý phim
C 5.3 File tập hợp mã nguồn của modul quản lý phòng chiếu
C 5.4 File tập hợp mã nguồn của modul lên lịch chiếu
C 5.5 File tập hợp mã nguồn của modul quản lý đặt vé
C 5.6 File tập hợp mã nguồn của modul quản lý nhân sự
C 5.7 File tập hợp mã nguồn của modul quản lý nhập phim
C 5.8 File tập hợp mã nguồn của modul quản lý dịch vụ
C 5.9 File tập hợp mã nguồn của modul quản lý đặt vé tai quầy
C 5.10 File tập hợp mã nguồn của modul xem các loại báo cáo
C 5.11 File tập hợp mã nguồn của modul tìm kiếm phim
C 5.12 File tập hợp mã nguồn của modul đặt và hủy vé online cho khách
C 5.13 File tập hợp mã nguồn của modul thống kê phim và vé đã mua
C 5.14 Bản báo cáo sau giai đoạn viết code xử lý
T 6. Kiểm thử và hiệu chỉnh
T 6.1 Tài liệu kế hoạch kiểm thử đơn vị ( UTP )
T 6.2 Tài liệu kế hoạch kiểm thử tích hợp ( ITP )
T 6.3 Tài liệu kế hoạch kiểm thử hệ thống ( STP )
T 6.4 Bản báo cáo sau giai đoạn kiểm thử…
PTL 7. Triển khai
PTL 7.1 Tài liệu cài đặt chạy thử.( IM )
PTL 7.2 Tài liệu hướng dẫn sử dụng (UM)
PTL 7.3 Bản báo cáo sau giai đoạn triển khai PM 8 Nghiệm thu, bàn giao.
2. Quy trình quản lý cấu hình
2.1 Quy ước nhận dạng và đặt tên CI
2.1.1 Các mẫu cấu hình:
Phần mềm quản lý bán vé xem phim

SM 8.1 Bản ký kết hợp đồng với khách hàng PM 9. Tổng kết dự án.
PM 9.1 Bản báo cáo tổng kết dự án
SM 10. Đóng dự án
SM 10.1 Bản tuyên bố đóng dự án
PTL 11. Phần mềm hệ thống và công cụ hỗ trợ
PTL 11.1 Gói Phần mềm các hệ điều hành Windows, LiNux, Ubuntu, Mac-OS
PTL 11.2 Phần mềm công cụ hỗ trợ
PTL 11.3 Hệ quản trị CSDL SQL Sever
CC 12. Cơ sở hạ tầng phần cứng
CC 12.1 Máy chủ
CC 12.2 Máy trạm
CC 12.3 Băng lưu trữ dữ liệu
CC 12.4 Ổ đĩa cứng
CC 12.5 RAM
2. Quy trình quản lý cấu hình
2.1.2 Xác định và quy ước đặt tên mẫu cấu hình
a. Đánh mã cho các mẫu cấu hình ( mẫu tài liệu…)
Mỗi mẫu cấu hình được xác định bằng 1 mã số theo cách sau:
<Mã cấu hình> =<Mã dự án>_<Loại tài liệu>_ <Tên viết tắt nhóm phụ trách> <Mã quy trình>.<mã số cấu hình trong quy trình> - < Mã
phiên bản >
Trong đó:
<Tên viết tắt của nhóm phụ trách>: Cụm từ gồm 2-3 chữ cái viết tắt tên của nhóm phụ trách sinh tài liệu
Mã quy trình: Là mã của quy trình nơi tài liệu được phát hành
Mã quy trình được thống nhất như sau
STT Tên quy trình Mã quy trình
1 QT Quản lý hợp đồng 01
2 QT Quản lý dự án 02
3 QT Quản lý yêu cầu 03
4 QT Thiết kế phần mềm 04
5 QT lập trình 05
6 QT Kiểm thử 06

7 QT Triển khai 07
8 QT quản lý hợp đồng phụ 08
9 QT quản lý cấu hình và thay đổi 09
10 QT Hỗ trợ khách hàng 10
11 Quản lý chất lượng 11
Loại tài liệu quy định như sau:
STT Kiểu tài liệu Mã viết tắt
1 Tài liệu hướng dẫn GLN
2 Tài liệu quy trình PRC
3 Tài liệu kế hoạch PLN
4 Tài liệu check list CHL
5 Tài liệu danh sách (list) LIST
6 TàI liệu biểu mẫu TPL
7 Tài liệu đặc tả usecase UCS
8 Tài liệu Testcase TC
9 Mã nguồn Source

Đánh số phiên bản xem mục quy ước đánh số phiên bản tài liệu
Ví dụ:
Tài liệu lập kế hoạch của dự án có mã dự án AppFilmManager, kiểu tài liệu kế hoạch mã là PLN, do PM
thực hiện lên có nhóm phụ trách là PM, mã quy trình là 2 và mã số của mẫu cấu hình trong quy trình là 1
có version là 1.1
Vậy mã số đầy đủ của tài liệu là:
AppFilmManager _PLN_PM 2.1 – v1.1
b. Đánh mã dự án - Project code
Mã dự án khác với tên dự án và mỗi dự án được xác định bằng 1
mã số (Project code) theo cách sau:
<Project code> = < Tên viết tắt của phần mềm > < mã đơn vị thực
hiện >
Tên viết tắt của phần mềm: là các chữ cái đầu tiên của
tên phần mềm
Mã đơn vị thực hiện là: số thứ tự của nhóm thực hiện
Ví dụ: Dự án xây dựng phần mềm quản lý bán vé phim do nhóm
thực hiện sẽ có mã là: AppFilmManager2
2.2 Thủ tục cơ sở CI
2.2.1 Đối với tài liệu
2.2 Thủ tục cơ sở CI
2.2.2 Đối với chương trình
2.2 Thủ tục cơ sở CI
2.3 Lịch trình cơ bản của dự án
STT Tên Baseline Tiêu chuẩn Baseline Phụ trách

Tổ chức họp công bố dự án

1 Khởi tạo Hoàn thành việc lập kế hoạc và tạo tài liệu project plan

2 Xác định yêu cầu Sau khi có được tất cả yêu cầu của khách hàng về chức năng và giao diện

Xây dựng hoàn thiện các bản thiết kế chức năng và giao diện. Chuẩn bị đến giai đoạn
3 Thiết kế tiếp theo
cài đặt các modul

Xây dựng chương

4 Hoàn thành việc xây dựng và kiểm thử sản phẩm
trình

Đóng gói, chốt sản phẩm và bàn giao cho khách hàng
6 Bàn giao sản phẩm
2.4 Cấu trúc thư mục & Quyền truy cập

Các vùng thư mục của dự án

Vùng Mục đích Vùng

Vùng phát triển Vùng dành cho lập trình viên lưu trữ code của mình Vùng phát triển

Lưu trữ các tài liệu sẵn sàng để xem xét. Người giám sát sẽ lấy những tài liệu đó tại vùn này.
Vùng giám sát Vùng giám sát

Vùng kiểm thử Lưu giữ mã nguồn chương trình đã hoàn thành, đã kiểm thử qua. Vùng kiểm thử

Lưu giữ những phiên bản sẵn sàng để phát hành và tất cả các phiên bản đã được phát hành.
Vùng phát hành Vùng phát hành
Người sử dụng có thể tìm những phiên bản cần thiết nhất cho công việc của họ tại đây
Vùng lưu trữ những mục cấu hình đã được phát hành để chuẩn bị cho baseline và không th thay đổi
Vùng Lưu trữ bởi bất cứ thành viên nào. Vùng Lưu trữ
2.5 QUY TẮC ĐÁNH SỐ PHIÊN BẢN

Đối với tài liệu: cấp phiên bản được duy trì dưới dạng định danh được đánh số với 2 phần:
Số phiên bản: xuất hiện ở bên trái. Nó chỉ thay đổi khi kiến trúc cốt lõi của sản phẩm thay đổi.

Số sửa đổi: xuất hiện ở bên phải của số thập phân. Nó thay đổi khi nội dung hiện tại được thay đổi, nhưng cấu trúc và dòng chảy tổng
thể của vật phẩm vẫn giữ nguyên. Trình tự sửa đổi thông thường là 1.1, 1.2, v.v.

Đối với tệp nguồn phần mềm: Các tệp thực thi phần mềm và tệp hỗ trợ thường được xác định theo tên và
số phiên bản

Số phiên bản: xuất hiện ở bên trái số thập phân. Nó chỉ thay đổi khi kiến ​trúc cốt lõi của mục phần mềm thay đổi, khi chuyển từ một khu
vực của công cụ phát triển sang một khu vực khác, khi một ứng dụng được đại tu hoàn toàn hoặc giao diện người dùng thay đổi về 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: 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 hoặc thay đổi
đáng kể. 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 giới hạn theo một cách nào
đó. Lý do phổ biến nhất để thay đổi số sửa đổi là khi thêm một 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: được thêm hoặc bớt khi thay đổi duy nhất với mục phần mềm là sửa một hoặc nhiều lỗi, mà không cần thêm bất kì chức
năng nào mới. Phiên bản 1.1 sẽ trở thành v1.1a, v1.1b, v.v. Việc cập nhật này bị hạn chế khi sửa đổi kết hợp, liên quan đến sửa lỗi và bổ
sung tính năng mới, được thực hiện. Trong trường hợp như vậy, số sửa đổi phần mềm được tăng lên và bất kỳ chỉ báo cập nhật nào cũng bị
loại bỏ, như trong v1.1b đến v1.2
2.6 Kiểm soát thay đổi
.
STT Ngày thông qua Sự kiện Hành động

1 7/3/2019 Khách hàng cập nhật thêm yêu cầu vào tài liệu đặc tả Kiểm tra sự khác biệt, cập nhật danh sách yêu cầu

2 Bản thiết kế CSDL thêm cho module quản lý dịch vụ Kiểm tra lại bản thiết kế, vẽ lại thiết kế CSDL bổ xung thêm
module quản lý dịch vụ

3 Mã nguồn thêm module quản lý dịch vụ Viết code xử lý cho module quản lý dịch vụ, kiểm thử đơn vị
cho module này

4 Mã nguồn xóa module xem hướng dẫn sử dụng Xóa code cho module xem hướng dẫn sử dụng, lập tài liệu
hướng dẫn sử dụng bản cứng cho khách hàng

S L I D E 6 8
2.7 Chiến lược sao lưu
.
Vùng lưu trữ Sản phẩm lưu trữ Lưu trữ tại Loại lưu trữ Tần xuất lưu trữ PIC

Google Drive Tài liệu đặc tả Cinema\Back_up\Specifi Đầy đủ 1 lần /tuần BA

cRequirement

Google Drive Bản thiết kế Cinema\Back_up\Design Đầy đủ 1 lần /tuần SA

Google Drive CSDL Cinema\Back_up\Databa Đầy đủ 1 lần /tuần PTL

se

Google Drive Mã nguồn Cinema\Back_up\Source Đầy đủ 1 lần /tuần PTL

Google Drive Báo cáo Cinema\Back_up\Report Đầy đủ 1 lần /tuần CC

S L I D E 6 9
Cảm ơn
Vì đã lắng nghe