Quản lý dự án phần mềm quản lý khách sạn

DỰ ÁN: XÂY DỰNG PHẦN MỀM
QUẢN LÝ KHÁCH SẠN
I. Giới thiệu về dự án
I.1 Giới thiệu
Hiện nay công việc quản lý các khách sạn lớn nếu không có sự hỗ trợ của công
nghệ thông tin sẽ gặp rất nhiều khó khăn.Với số lượng khách hàng, phòng nghỉ
lớn, thường xuyên thay đổi cũng như cập nhật khiến cho việc quản lý trở nên phức
tạp.
Dự án của chúng tôi sẽ được triển khai trong phạm vi của một khách sạn vừa và
đối tượng tập trung là quản lý về khách hàng, phòng cho thuê cũng như danh mục
đặt phòng.
I.2 Thông tin dự án
Tên Dự Án: Xây dựng phần mềm quản lý khách sạn.
Khách Hàng: Khách sạn Việt Nam.
Đại diện: ông Nguyễn Văn A (Quản lý khách sạn)
Trưởng nhóm dự án: Đặng Nhật Quynh
Đội phát triển dự án:
• Đặng Nhật Quynh
• Kiều Tiến Quân
• Lê Quốc Việt
• Đinh Văn Toản
• Vũ Việt Vương
I.3 Phạm vi dự án
- Hệ thống được thiết kế và xây dựng tốt có thể được nâng cấp, thay đổi phù
hợp với nhiều khách sạn khác nhau.
- Khu vực ảnh hưởng trong khách sạn: quầy lễ tân, nhóm quản lý khách sạn,
quản lý website.
- Phạm vi dữ liệu:
 Dữ liệu về khách hàng, phòng khách sạn và thông tin đặt phòng.
 Làm mới thông tin khác.
• Công nghệ thực hiện:

 Java Application
 SQL Server
• Ước lượng thời gian thực thi dự án : 5 tuần ( 1/10/2013 – 7/11/2013)
I.4 Sản phầm bàn giao cuối
• Phần mềm quản lý khách sạn với đầy đủ chức năng yêu cầu.
• Hệ thống cơ sở dữ liệu của dự án do khách hàng cung cấp.
• Mã nguồn chương trình.
• Tài liệu phát triển
I.5 Các bên liên quan
Vai trò Họ tên Liên lạc
Nhà tài trợ dự án
Khách sạn Việt Nam
Đại diện: Nguyễn Văn A
SĐT: 0987654213
Mail:
Khách hàng
Khách sạn Việt Nam
Đại diện: Nguyễn Văn A
SĐT: 0987654213
Mail:
Chuyên gia tư vấn Đặng Nhật Quynh
SĐT: 0127983123
Mail:
Nhóm theo dõi,
đánh giá dự án
Kiều Tiến Quân
Lê Quốc Việt
SĐT: 0435721341
Mail:
I.6 Giả thiết đề ra

• Xây dựng hệ thống với cách tiếp cận hướng đối tượng.
• Sử dụng ngôn ngữ lập trình java làm công cụ chính.
• Hỏi ý kiến thầy (cô) trong quá trình xây dựng hệ thống khi cần.
• Những công nghệ mà nhóm chưa làm chủ được thì sẽ hợp tác với các thành
viên ngoài dự án.
• Hệ thống sẽ có sự thay đổi khi bổ sung các chức năng mới.
• Đội làm dự án sẽ được phân làm nhiều nhóm nhỏ trong quá trình thực hiện.
• Sau khi kết thúc giai đoạn 1 thì sẽ sắp xếp lại nhân sự để thực hiện các giai
đoạn tiếp theo của dự án.
I.7 Tiến trình xây dựng và quản lý dự án
Phần 1: Tôn chỉ dự án
Phần 2: Kế hoạch tích hợp
Phần 3: Kế hoạch quản lý phạm vi dự án
Phần 4: Kế hoạch quản lý thời gian thực hiện
Phần 5: Kế hoạch quản lý chi phí
Phần 6: Kế hoạch quản lý chất lượng dự án
Phần 7: Kế hoạch quản lý nhân lực
Phần 8: Kế hoạch quản lý truyền thông
Phần 9: Kế hoạch quản lý rủi ro
Phần 10: Kế hoạch quản lý mua sắm
I.8 Bảng phân công công việc
Công việc Ngươi thực hiện
• Mô tả chung dự án
• Tôn chỉ dự án
• Kế hoạch tích hợp
Kiều Tiến Quân
• Kế hoạch quản lý phạm vi dự án
• Kế hoạch quản lý thời gian
Đặng Nhật Quynh
• Kế hoạch quản lý chi phí

• Kế hoạch quản lý chất lượng
Lê Quốc Việt
• Kế hoạch quản lý nhân lực
• Kế hoạch quản lý truyền thông
Đinh Văn Toản
• Kế hoạch quản lý rủi ro
• Kế hoạch quản lý mua sắm
Vũ Việt Vương
II. Tôn chỉ dự án
1. Tổng quan về dự án:
Hiện nay công việc quản lý các khách sạn lớn nếu không có sự hỗ trợ của công
nghệ thông tin sẽ gặp rất nhiều khó khăn.Với số lượng khách hàng, phòng nghỉ
lớn, thường xuyên thay đổi cũng như cập nhật khiến cho việc quản lý trở nên phức
tạp. Dự án của chúng tôi sẽ được triển khai trong phạm vi của một khách sạn vừa
và đối tượng tập trung là quản lý về khách hàng, phòng cho thuê cũng như danh
mục đặt phòng.
Các chức năng chính của hệ thống:
• Quản lý đặt phòng.
• Quản lý trả phòng.
• Quản lý khách hàng
2. Mục tiêu
2.1. Mục tiêu doanh nghiệp
- Hỗ trợ công việc tính toán,sắp xếp phòng khi có khách đặt phòng được
nhanh và hiệu quả hơn.
- Quản lý thông tin khách hàng và việc trả phòng chính xác tránh thất
thoát.
- Chương trình có giao diện dễ sử dụng, cài đặt với đầy đủ chức năng
quản lý một khách sạn cần và có thể bổ sung những chức năng mới khi
khách sạn yêu cầu.
2.2 Mục tiêu về công nghệ

- Xây dựng một trang web mới để nhận gửi thông tin phản hồi với khách
hàng.
- Di chuyển cơ sở hạ tầng công nghệ cũ trong vòng 1 ngày và không làm
ảnh hưởng tới quá trình hoạt động, quản lý của khách sạn.
- Đẩy nhanh tốc độ xử lý hiện tại.
3. Yêu cầu nghiệp vụ
- Dự án phần mềm phát triển ở đây là hệ thống quản lý khách sạn.
- Người sử dụng phần mềm : Nhân viên quản lý khách sạn và nhân viên lễ
tân.
- Mục đích của dự án là thiết kế chương trình quản lý khách sạn dễ sử dụng,
dễ cài đặt, chương trình có nhiều tính năng linh hoạt như tìm kiếm phòng
trống, thanh toán trả phòng một cách nhanh chóng và chính xác.
4. Phạm vi công việc
• Hệ thống được thiết kế và xây dựng tốt có thể được nâng cấp, thay đổi phù hợp
với nhiều khách sạn.
• Khu vực ảnh hưởng trong khách sạn: quầy lễ tân, nhóm quản lý xuất nhập,
quản lý trên mạng.
• Phạm vi dữ liệu:
 Dữ liệu về sách và thông tin giao dịch được giữ nguyên.
 Làm mới thông tin khác.
• Công nghệ thực hiện:
 Java Application
 SQL Server
• Ước lượng thời gian thực thi dự án : 5 tuần ( 1/10/2013 – 7/11/2013)
5. Cách phương pháp và cách tiếp cận
• Tìm hiểu, khảo sát quy trình nghiệp vụ của công việc quản lý khách sạn.
• Phân tích, đánh giá hiện trạng và đề ra giải pháp.
• Lựa chọn mô hình phù hợp cho hệ thống.
• Tìm hiểu và đào tạo cho những người sử dụng hệ thống.
6. Các đánh giá, mục tiêu hệ thống:

6.1.Đánh giá hệ thống cũ :
• Có thể gây sai sót khi phải nhập thủ công quá nhiều thông tin về khách hàng
cũng như mượn trả phòng.
• Không trực quan.
• Tốc độ truy xuất CSDL chậm.
6.2. Mục tiêu đặt ra cho hệ thống mới
• Hạn chế việc nhập vào các thông tin mượn trả phòng một cách thủ công
thay vào đó có thể đưa vào một số gợi ý có sắn cho một số trường thông tin.
• Tránh sai sót đến mức thấp nhất có thể được.
• Tính hóa đơn, in và lưu trữ hóa đơn một cách dễ dàng
6.3. Công nghệ và kĩ thuật áp dụng
• Ngôn ngữ lập trình : Java
• Cơ sở dữ liệu chứa các thông tin cần thiết về các đầu sách
• Các yêu cầu đặc biệt : Hệ thống quản lý bán sách là hệ thống yêu cầu tính
chính xác trong việc thống kê các danh mục phòng cũng như thanh toán hóa
đơn trả phòng, dễ sử dụng do đó để có một hệ quản lý khách sạn hoạt động
tốt cần phải có những người nắm vững các hoạt động nghiệp vụ tham gia
trực tiếp vào hệ thống
7. Mô tả sản phẩm.
Xây dựng phần mềm quản lý nhà sách với các chức năng chính:
• Quản lý đặt phòng
• Quản lý trả phòng.
• Quản lý thông tin khách hàng.
• Thanh toán , in hóa đơn trả phòng cho khách.
8. Những sự kiện quan trọng trong dự án
Cột mốc Mô tả Ngày
Lấy yêu cầu từ khách hàng
Gặp gỡ khách hàng lần 2 để lấy
thông tin về sản phầm cần triển
khai cũng như gặp mặt các

chuyên gia tư vấn trong lĩnh vực
01/10/2013
Hoàn thành bản kế hoạch
tổng thể của dự án
Lập kế hoạch tổng thể cho dự án
Hoàn thành các bản kế hoạch
quản lý dự kiến của dự án.
Phân chia công việc.
05/10/2013
Gặp gỡ khách hàng
Trao đổi về bản kế hoạch chung.
Ký kết thỏa thuận trước khi làm.
7/10/2013
Hoàn thành pha lấy yêu
cầu. Tổng kết lần 1
Lập tài liệu pha lấy yêu cầu.
Tổng kết những việc đã làm.
Kiểm thử sản phầm pha.
Xem xét tiến độ công việc so với
kế hoạch.
Định hướng công việc tiếp theo
13/10/2013
Gặp gỡ nhóm theo dõi đánh
giá dự án
Trao đổi bản kế hoạch với khách
hàng. Ký kết thỏa thuận.
Thống nhất tài liệu
Lấy thêm thông tin yêu cầu
14/10/2013
Hoàn thành pha phân tích.

Tổng kết dự án so với kế
Lập tài liệu pha phân tích.
Tổng kết những việc đã làm.
20/10/2013
hoạch lần 2
Kiểm thử sản phẩm pha.
Xem xét tiến độ công việc so với
kế hoạch.
Định hướng công việc tiếp theo
Trao đổi bản kế hoạch với khách
hàng. Ký kết thỏa thuận.
Gặp gỡ nhóm theo dõi đánh
giá dự án
Trao đổi bản kế hoạch với khách
hàng. Ký kết thỏa thuận.
Thống nhất tài liệu
Lấy thêm thông tin yêu cầu
21/10/2013
Hoàn thành pha thiết kế.
Tổng kết dự án so với kế
hoạch lần 3
Lập tài liệu pha lấy thiết kế.
Tổng kết những việc đã làm.
Kiểm thử sản phẩm pha
Xem xét tiến độ công việc so với
kế hoạch.
Định hướng công việc tiếp theo
26/10/2013
Gặp gỡ nhóm theo dõi đánh
giá dự án

Trao đổi bản kế hoạch với khách
hàng. Ký kết thỏa thuận.
Thống nhất tài liệu
Lấy thêm thông tin yêu cầu
27/10/2013
Hoàn thành pha Cài đặt.
Tổng kết dự án so với kế
hoạch lần 4
Lập tài liệu pha lấy cài đặt.
Tổng kết những việc đã làm.
Kiểm thử lần cuối
Xem xét tiến độ công việc so với
kế hoạch.
Định hướng công việc tiếp theo
01/11/2013
Chạy thử nghiệm sản phần Chạy thử nghiệm sản phẩm 02/11/2013
Bàn giao sản phẩm cho
khách hàng
Bàn giao sản phẩm
Tài liệu chuyên môn cho khách
hàng
Hướng dẫn sử dụng sản phẩm
04/11/2013
Họp tổng kết dự án Họp dự án tổng kết chương trình 07/11/2013
9. Thước đo thành công
• Tiết kiệm chi phí tổng thể >5%
• Giảm thời gian làm việc >15%
• Hệ thống hoạt động tốt với đầy đủ chức năng trong tuần chạy thử
• Tốc độ xử lý nhanh hơn hệ thống cũ >5%
10. Rủi ro và vấn đề

Một số rủi ro có thể gặp:
Rủi ro Khả năng Ảnh hưởng
Vấn đề tài chính Thấp Lớn
Nhân viên nghỉ việc hoặc có việc đột
xuất
Cao Lớn
Công việc không hoàn thành đúng chỉ
tiêu
Thấp Bình thường
Thay đổi yêu cầu Cao Bình thường
Thời gian hoàn thành giữa các pha trễ Bình thường Lớn
Phần mềm có nhiều khiếm khiết Thấp Nghiêm trọng
Lỗi tương thích Thấp Bình thường
Cơ sở dữ liệu sai hoặc hỏng Bình thường Lớn
Thay đổi cấp trên Thấp Nghiêm trọng
11. Đội phát triển dự án
Vai trò Trách nhiệm Thành viên
Project Manager
Người quyết định có sử dụng
Quản lý cấu hình hay không,
đưa ra các vai trò tham gia, các
tài nguyên cho dự án.
Đặng Nhật Quynh
Bussiness Analyst
Phân tích các yêu cầu nghiệp vụ
dựa trên những yêu cầu của
khách hàng.
Lê Quốc Việt
Customer Contact
Chắc chắn rằng khách hàng

thỏa mãn theo đúng hợp đồng.
Vũ Việt Vương
Designer, Tester
Lead
Phân tích thiết kế, thực thi hệ
thống.
Chịu trách nhiệm kiểm thử hệ
thống
Đinh Văn Toản
Technical
Triển khai hệ thống tới khách
hàng, chịu trách nhiệm cài đặt
hệ thống, hướng dẫn người
dùng cuối vận hành, bảo trì hệ
thống.
Kiều Tiến Quân
Developer Phát triển phần mềm Tất cả thành viên
12. Ký kết dự án
Khách hàng
Name Signature Date
Nguyễn Văn A 01/10/2013
Nhà tài trợ
Name Signature Date
Nguyễn Văn A 01/10/2013
Quản lý dự án
Name Signature Date
Đặng Nhật Quynh 01/10/2013
III. Kế hoạch quản lý tích hợp
1. Tổng quan về nội dung dự án
1.1 Vòng đời phát triển dự án: Mô hình thác nước.

1.2 Mô hình quản lý dự án: Mô hình nhóm dân chủ vượt quá lập trình viên trưởng.
1.3 Tài nguyên sử dụng
• Kinh phí đầu tư: 120.000.000 VNĐ bao gồm:
o Lương nhân viên tham gia
o Tiền thuê cơ sở vật chất
o Các chi phí phát sinh
o Dữ trữ 10%
• Số thành viên tham gia dự án: 5 người.
1.4 Công cụ thực hiện:
- Trọn bộ Microsoft office: lập kế hoạch dự án.
- Eclipse : Cài đặt chương trình.
- Visual Paradigm: Phân tích, thiết kế, vẽ biểu đồ trong chương trình.
- SQL Server : Lưu trữ CSDL.
1.5 Kỹ thuật sử dụng trong dự án
o J2EE
o SQL
2. Quy trình thực hiện
a) Pha xác định yêu cầu
1.1 Thu thập thông tin: Đặng Nhật Quynh
1.1.1 Từ khách hàng: gặp gỡ, trao đổi với khách hàng
1.1.2 Từ thị trường thực tế (có thể từ các nhà sách khác): khảo sát thị
trường
1.2 Họp nhóm xác định công việc: Đặng Nhật Quynh
I.3 Viết yêu cầu của hệ thống: Kiều Tiến Quân
1.3.1 Về phần mềm
1.3.2 Về phần cứng
1.4 Viết tài liệu: Lê Quốc Việt
1.4.1 Xác định Actor list : Vũ Việt Vương
1.4.2 Lập Glossary
1.4.3 Biểu đồ Usecase +Chi tiết hóa Usecase

1.4.4 Biểu đồ Commnication
1.4.5 Biểu đồ Activity
1.4.6 Lập Usecase survey
1.5 Phác thảo giao diện người dùng (GUI): Đinh Văn Toản
1.6 Kiểm thử tài liệu pha lấy yêu cầu: Đinh Văn Toản
1.7 Trao đổi với khách hàng và nhà đầu tư: Vũ Việt Vương
b) Pha phân tích
2.1 Phân tích tĩnh: Kiều Tiến Quân
2.1.1 Xác định các lớp cơ bản và thuộc tính; vẽ biểu đồ lớp
2.2 Phân tích động: Đặng Nhật Quynh
2.2.1 Vẽ biểu đồ trạng thái
2.2.2 Vẽ biểu đồ cộng tác
2.2.3 Hoàn thiện biểu đồ lớp
2.2.4 Update Glossary
2.3 Kiểm thử pha phân tích: Lê Quốc Việt
c) Pha thiết kế
3.1 Thiết kế kiến trúc hệ thống: Đặng Nhật Quynh
3.1.1 Lựa chọn công nghệ thực hiện
3.1.2 Lựa chọn cấu trúc hệ thống
3.1.3 Lập chính sách truy cập đồng thời
3.1.4 Thiết kế bảo mật
3.1.5 Biểu đồ các tầng nghiệp vụ
3.1.6 Lựa chọn phân vùng hệ thống con
Thiết kế dịch vụ kinh doanh
Thiết kế Database schema
Hoàn thiện giao diện
Thiết kế mô hình lớp từ mô hình lớp pha phân tích
3.2 Thiết kế chi tiết sơ đồ lớp cuối cùng, mô hình hóa sơ đồ lớp: Vũ Duy
Dương
3.3Kiểm thử thiết kế: Kiều Tiến Quân

d) Pha thực thi
4.1 Cài đặt các module
4.1.1 Các lớp thực thể : Lê Quốc Việt
4.1.2 Các lớp biên: Đinh Văn Toản
4.1.2.1 Giao diện Quản lý khách hàng
4.1.2.2 Giao diện Quản lý mượn trả phòng
4.1.2.3 Giao diện chung
4.1.3 Các lớp điều khiển: Vũ Việt Vương
4.1.3.1 Điều khiển Quản lý khách hàng
4.1.3.2 Điều khiển Quản lý mượn trả phòng
4.2 Tích hợp các module: Kiều Tiến Quân
4.2.1 Các chức năng Quản lý khách hàng
4.2.2 Các chức năng Quản lý mượn trả phòng
4.2.3 Tích hợp toàn bộ hệ thống
4.3Xây dựng cơ sở dữ liệu
4.3 Kiểm thử sản phầm: Đặng Nhật Quynh
4.3.1 Kiểm thử đơn vị
4.3.2 Kiểm thử tích hợp
4.3.3 Kiểm thử sản phẩm
4.3.4 Tự kiểm thử
e) Giao sản phẩm cho khách hàng: Đặng Nhật Quynh
5.1Bàn giao sản phẩm cho khách hàng
5.2Lắp đặt sản phẩm
5.3Chạy thử tại khách sạn ABC trong 10 ngày
3. Kế hoạch quản lý cấu hình
1) Ý nghĩa của việc quản lý cấu hình
Việc lập kế hoạch cấu hình nhằm đảm bảo cho hệ thống quản lý sách được cập
nhật và thực hiện các chức năng một cách chính xác.
Cấu hình sẽ được lưu trữ trên với tài khoản là
tien_quan_9x trên internet nhằm đảm bảo:

- Quản lý được hệ thống cấu hình
- Đảm bảo không có mẫu cấu hình nào được thay đổi mà không được phép
- Tiếp nhận, quản lý trạng thái của mỗi cấu hình
- Đảm bảo mẫu cấu hình được tạo ra đúng cách, đúng mục đích
2) Cấu hình trong các pha của dự án
1.1 Lên kế hoạch
Mẫu cấu hình trong pha này gồm:
- Kế hoạch phát triển dự án
- SOW
- WBS
- Use case diagram
1.2 Phân tích yêu cầu
Mẫu cấu hình trong pha này là:
- Bản đặc tả yêu cầu người dùng
- Bản đặc tả yêu cầu hệ thống
- Báo cáo dự án sau pha phân tích
1.3 Thiết kế
Mẫu cấu hình trong pha này là:
- Bản thiết kế sơ đồ lớp
- Bản thiết kế kiến trúc hệ thống
- Bản thiết kế giao diện
- Bản thiết kế CSDL
- Báo cáo dự án sau pha thiết kế
1.4 Cài đặt
- File mã nguồn của chương trình
- Báo cáo dựa sn sau pha cài đặt
1.5 Kiểm thử lần cuối
- Các test case
- Dữ liệu kiểm thử
- Tài liệu kiểm thử

- Bản báo cáo cuối cùng
3) Kế hoạch quản lý cấu hình
3.1 Phạm vi áp dụng:
Được hoàn thành trong pha lập kế hoạch đầu dự án và được thực hiện, kiểm
tra trong tất cả các pha của dự án
3.2 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
3.3 Trách nhiệm của các thành viên trong quản lý cấu hình
STT Thành viên Vai trò, trách nhiệm
1 Quản lý cấu
hình
(Đặng Nhật
Quynh)
 Thiết lập và kiểm soát nơi lưu trữ tài liệu cấu hình
của dự án.
 Phát triển và triển khai các quy trình quản lý cấu
hình của dự án.
 Tạo các bản kế hoạch tức thời , ghi nhận chi tiết các
thay đổi trên các bản kế hoạch đó.
 Quản lý thay đổi trên các bản kế hoạch tức thời.
 Tổ chức và điều phối các cuộc họp của CCB
2 Quản lý dự án
(Kiều Tiến
Quân)
 Giám sát các hoạt động quản lý cấu hình.
 Bảo đảm các yêu cầu cần thiết cho hoạt động quản
lý cấu hình.
3 Thành viên

toàn dự án
 Thực hiện tốt công việc được giao
 Tuân thủ tất cả các quy trình thủ tục của bản kế
hoạch quản lý cấu hình cũng như yêu cầu của người
quản lý cấu hình.
3.4Hoạt động
3.4.1 Định danh cấu hình
Khi qua một bản kế hoạch tức thời, các phiên bản làm việc sẽ được kiểm
tra, nếu thỏa mãn các tiêu chuẩn được định sẵn thì sẽ trở thành mẫu cấu
hình. Các tiêu chuẩn đó là:
- Phiên bản làm việc được khảo sát đúng cách
- Các lỗi phải được khắc phục
- Phiên bản làm việc phải có đầy đủ các tài liệu đi kèm
Mẫu cấu hình phải chứa đầy đủ các thông tin sau:
- Tên cấu hình
- Phiên bản
- Trạng thái
- Ngày khởi tạo
- Nơi lưu trữ
- Người tạo ra
Chú ý: Cấu hình sẽ được lưu trong máy tính của quản lý cấu hình (Vũ
Việt Vương).
3.4.2 Quy ước cách đặt tên
Mẫu cấu hình sẽ được đặt tên theo cách sau:
<mã dự án>_<mã loại>_<R|A|B>_<x>.<y>.<z>
Trong đó:
Ký hiệu Ý nghĩa
<mã dự án> Mã dự án mà mẫu cấu hình thuộc về
<mã loại> Mã loại mẫu cấu hình
<R|A|B>

R: release
A: alpha
B: beta
<x>
Bản kế hoạch tức thời của mẫu cấu hình theo số
thứ tự, bắt đầu từ 1.
<y>
Phiên bản thay đổi đáng kể của mẫu cấu hình, bắt
đầu từ 0
<z>
Phiên bản thay đổi không đáng kể của mẫu cấu
hình, bắt đầu từ 0
3.4.3 Quản lý cấu hình
3.4.3.1 Thêm mới một mẫu cấu hình
Quy trình thực hiện:
- Viết đơn yêu cầu thêm cấu hình
- Viết một bản chứa thông tin về mẫu cấu hình muốn thêm vào
- Các thành viên có liên quan sẽ tổ chức họp bàn để quyết định việc
có nên thêm mẫu cấu hình mới vào không.
- Nếu đồng ý việc thêm mẫu cấu hình mới, sẽ phải thông báo lại cho
quản lý cấu hình để thêm vào thông tin quản lý.
- Gửi thông báo cho các thanh viên trong đội dự án
3.4.3.2 Thay đổi mẫu cấu hình
Quy trình thay đổi mẫu cấu hình
- Viết đơn yêu cầu thay đổi mẫu cấu hình. Trong đó cần nêu rõ lý
do thay đổi, mức độ cấp thiết cần phải thay đổi, sự ảnh hưởng của
thay đổi đó tới các mẫu cấu hình khác….
- Quản lý cấu hình sẽ tiếp nhận những yêu cầu thay đổi đó. Và xem
xét, nếu như thấy mức độ của sự thay đổi là không lớn thì có thể tự
quyết định, còn nếu như mức độ của nó quá lớn thì cần họp bàn đề

ra quyết định.
- Nếu chấp nhận sự thay đổi, cần thêm vào phần thông tin quản lý
và thông báo cho những bên liên quan để thay đổi cho phù hợp.
3.4.3.3Báo cáo trạng thái cấu hình
Công việc thực hiện:
- Báo cáo trạng thái mẫu cấu hình: Tình trạng của các mẫu cấu hình
hiện nay.
- Báo cáo về sự thay đổi của các mẫu cấu hình
- Báo cáo về các hoạt động thanh tra, kiểm soát mẫu cấu hình
Kết quả của công việc này được ghi nhận trong một báo cáo mang tên
Configuration Status Accounting Report (CSAR).
Các báo cáo này được thực hiện thường xuyên và định kỳ trong quá trình
phát triển dự án.
3.4.3.4Kiểm tra cấu hình
a) Mục đích
Kiểm tra các mẫu cấu hình hiện tại, rà soát lỗi nhằm đảm bảo tiến độ
công việc so với kế hoạch.
b) Các kiểu thanh tra
- Thanh tra chức năng:
Kiểm tra những chức năng của một mẫu cấu hình dựa trên những
tài liệu kỹ thuật. Việc thanh tra chức năng được thực hiện trên cả
những mẫu cấu hình thuộc về phần cứng lẫn phần mềm
- Thanh tra vật lý:
Thanh tra những mẫu cấu hình (cả về phần cứng lẫn phần mềm)
ngược lại với những tài liệu kỹ thuật của nó. Việc thanh tra vật lý
chỉ diễn ra khi việc thanh tra chức năng đã hoàn thành. Sau khi
hoàn thành việc thanh tra vật lý thì sẽ cho ra một Product Baseline
(PBL)
Người thực hiện
Quản lý dự án: Kiều Tiến Quân

Quản lý cấu hình: Đặng Nhật Quynh
Công việc kiểm tra
- Lên kế hoạch cho việc thanh tra
- Tập hợp tài liệu cần thiết cho việc thanh tra
- Kiểm tra các mẫu cấu hình, đối chiếu với tài liệu về mẫu cấu hình,
xem nó có đúng với yêu cầu đặt ra ban đầu hay không ?
- Thanh tra sự bổ xung, thay đổi mẫu cấu hình. Sự ảnh hưởng của
chúng với các mẫu cấu hình khác.
- Kiểm tra việc lưu trữ các mẫu cấu hình
- Lập tài liệu về việc thanh tra
3.4.3.5 Sao lưu cấu hình
Trong quá trình thực hiện cần sao lưu dữ liệu ra 2 bản. Công việc cần
thực hiện có kế hoạch. Có thể sao lưu cả bản cứng.
4. Kế hoạch quản lý thay đổi
4.1Mục đích
Tài liệu và báo cáo kế hoạch quản lý thay đổi chứa những thông tin cần thiết
để có thể đạt hiệu quả trong việc quản lý xây dựng phần mềm quản lý nhà sách
Tiền Phong các thay đổi từ khi bắt đầu dự án đến lúc giao cho khách hàng.
Quản lý thay đổi nhằm đảm bảo:
- Đảm bảo thay đổi mang lại lợi ích cho dự án
- Xác định cách thay đổi được thực hiện
- Quản lý cách thay đổi được thực hiện
4.2Mục tiêu
o Xem xét tất cả yêu cầu thay đổi
o Xác định, đánh giá, phê duyệt, theo dõi các thay đổi được thông qua
o Sửa đổi kế hoạch dự án cho phù hợp với những yêu cầu thay đổi
o Các bên liên quan tham gia thảo luận thích hợp
o Trao đổi, đàm phán với những bên bị ảnh hưỏng.
4.3Phạm vi
Kế hoạch quản lý thay đổi được tạo ra trong pha lập kế hoạch dự án.

Quản lý thay đổi được diễn ra mọi thời điểm trong dự án khi mà có một vấn đề
cần thay đổi được đưa ra.
4.4Đối tượng quản lý
- Quản lý dự án: Kiều Tiến Quân
- Quản lý thay đổi: Lê Quốc Việt
- Giám đốc khách sạn: Nguyễn Văn A
4.5Lấy yêu cầu quy trình thay đổi yêu cầu(CR)
Các bước thực hiện:
1) Tạo các yêu cầu thay đổi: Người yêu cầu thay đổi nộp bản mẫu yêu cầu
thay đổi và gửi bản mẫu đã điền đầy đủ thông tin tới Ban kiểm soát sự
thay đổi(CCB). Các bên liên quan sẽ xem xét sự cần thiết cho thay đổi.
2) Trạng thái CR Log: Quản lý thay đổi thêm các yêu cầu thay đổi vào
trong CR Log. Trạng thái của yêu cầu thay đổi được cập nhật trong suốt
quá trình khi cần thiết
3) Đánh giá yêu cầu thay đổi: Nhân viên dự án xem xét yêu cầu thay đổi
và cung cấp ước tính mức độ xử lý và phát triển một giải pháp để giải
quyết thay đổi đó. Sau đó quản lý dự án, quản lý thay đổi và cả đội xem
xét thay đổi
4) Ủy quyền: Phê duyệt các thay đổi để tích hợp những thay đổi đó vào dự
án/ sản phẩm. Bước này thuộc toàn quyền CCB
5) Triển khai: Nếu được chấp nhận, thực hiện những thay đổi cần thiết để
thực hiện sự thay đổi. Đồng thời liên lạc với người đề xuất thay đổi và
các bên liên quan trong dự án. Bước này được thực hiện dưới sự giám
sát của quản lý thay đổi.
4.6Mẫu quản lý thay đổi chung
Một bản mẫu thay đổi chung được lưu trong CR Log phải có đầy đủ các thông
tin sau:
Trạng thái Mô tả
Date Ngày yêu cầu thay đổi được tạo
CR# Sự phân công của quản lý thay đổi

Title Mô tả ngắn gọn về yêu cầu thay đổi
Description
Mô tả sự thay đổi mong muốn
Tác động, lợi ích của việc thay đổi
Submitter
Tên của người đề xuất thay đổi và những người có liên quan
trong quá trình thay đổi yêu cầu
Phone Số điện thoại người đề xuất
E-Mail Email người đề xuất thay đổi
Product Sản phẩm được đề xuất để thay đổi
Version Phiên bản của sản phẩm được đề xuất thay đổi
Priority Phân loại yêu cầu dựa theo sự cấp bách của yêu cầu thay đổi.
4.7Tiêu chí đánh giá yêu cầu thay đổi
Dựa trên độ ưu tiên:
Mức độ ưu tiên Mô tả
Cao Tác động đáng kể tới tiến độ, chi phí, chất lượng.
Ảnh hưởng đến use case chính
Trung Bình Tác động vừa phải tới chi phí, lịch trình hoặc có không
ảnh hướng đến chi phí, lịch trình nhưng làm giảm chất
lượng
Vật chất xuống cấp.
Thấp Yêu cầu không ảnh hướng đến chi phí, lịch trình
Không làm suy giảm chất lượng
Thay đổi các yêu cầu cập nhật trong pha lấy yêu cầu và
thông số kỹ thuật.
Tiến độ thay đổi được đánh giá thông qua những trạng thái sau:
Trạng thái Mô tả
Open Được nhập/ mở nhưng chưa được phê duyệt
Work in
Progress

Yêu cầu thay đổi đã được duyệt, được bàn giao, và công việc
đang tiến triển
In Review Yêu cầu thay đổi đã được hoàn thành và đánh giá cuối cùng
trước khi kiểm thử
Testing Kiểm thử yêu cầu thay đổi sau khi đánh giá
Closed Yêu cầu thay đổi đã được thực hiện xong, và bản cập nhật
đang được đưa ra.
4.8Ban kiểm soát sự thay đổi(CCB)
4.9Trách nhiệm và vai trò của bên liên quan
Vai trò Mô tả
Quản lý thay đổi Quản lý mọi vấn đề liên quan đến yêu cầu
thay đổi diễn ra trong quá trình thực hiện dự
án.
Quản lý quá trình thay đổi
Quản lý dự án Phê duyệt lần cuối những thay đổi.
Họp bàn, đánh giá những yêu cầu thay đổi.
Thành viện dự án - Đề xuất các thay đổi cần thiết để dự án đi
tới thành công
- Thực hiện thay đổi khi yêu cầu thay đổi
Vai trò Tên Liên lạc Mô tả
Quản lý
thay đổi
Lê Quốc Việt 0987654321 - Tiếp nhận và ghi vào CR
Log các yêu cầu thay
đổi.
- Quản lý CR Log
- Quản lý quá trình thay
đổi được thực hiện
- Làm rõ thông tin thay
đổi, những vấn đề liên

quan.
CCB chủ
tịch
Nguyễn Văn A 0981373131 - Phê duyệt những thay
đổi về ngân sách/ tài trợ
- Phê duyệt những thay
đổi về lịch trình
- Phê duyệt bất kỳ thay
đổi mức Cao của dự án
Thành
viên đánh
giá về
những
thay đổi
Đặng Nhật
Quynh
0127536445 - Chỉnh sửa tài liệu để phù
hợp với thay đổi
- Đóng góp ý kiến, đánh
giá về những yêu cầu
thay đổi
đó được phê duyệt.
- Cung cấp thông tin liên quan đến yêu cầu
thay đổi
Khách hàng
Nhà đầu tư
Giám sát dự án
Nhận thông tin về những yêu cầu thay đổi.
Tham gia đánh giá mức độ thay đổi cần thực
hiện