TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
*
TIỂU LUẬN
IT6161 QUẢN TRỊ DỰ ÁN CNTT VÀ QUẢN LÝ THAY ĐỔI
Đề tài: Nguyên tắc và thực hành quản lý thay đổi cho dự án phần mềm
theo chuẩn CMMI

Giảng viên hướng dẫn:
TS. Vũ Thị Hương Giang
Học viên thực hiện:
Lê Thị Thu Hà
Đào Minh Tuấn
Nguyễn Thu Huyền

Lớp:
Cao học 2012A – Hưng YênNăm 2012
2
MỤC LỤC
1. Giới thiệu chuẩn CMMI 3
1.1. Ứng dụng CMMI 4
1.2. Các level của CMMI 4
1.3. Các Vùng quy trình của CMMI 4
2. Các thay đổi trong dự án phần mềm 5
3. Quản lý thay đổi cho dự án phần mềm theo chuẩn CMMI 6
3.1. Vùng quy trình Configuration Management (CM) 6
3.1.1. Mục đích của quản lý cấu hình 6
3.1. 2. Nguyên tắc 6

5.
BCT Báo cáo test
6.
QLYC Quản lý yêu cầu
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
2
1. Giới thiệu chuẩn CMMI
Mô hình CMMI (Capability Maturity Model Integration) là một khung các giải
pháp tối ưu cho quá trình sản xuất phần mềm. Phiên bản CMMI-DEV hiện nay
(CMMI cho chuyên viên phát triển), mô tả những giải pháp tốt nhất trong quá trình
kiểm soát, đo lường và kiểm tra các quy trình phát triển phần mềm. Mô hình CMMI
không tập trung mô tả chính các quá trình mà chỉ mô tả đặc điểm của các quá trình
hiệu quả, vì vậy mô hình CMMI đưa ra chỉ dẫn cho các công ty để họ có thể tự mình
phát triển hoặc điều chỉnh chính các quá trình của họ.
Hình 1. Mô hình CMMI
Mô hình CMMI được mô tả trên trang web chính thức CMMI website :dự án
CMMI là một nỗ lực chung nhằm cung cấp các mô hình để cải thiện nâng cấp các sản
phẩm và quy trình. Trọng tâm chính của dự án là tập trung xây dựng các công cụ hỗ
trợ việc cải thiện các quy trình dùng để phát triển và ổn định các hệ thống và sản
phẩm. Kết quả của dự án CMMI là một bộ các sản phẩm cung cấp một phương pháp
tiếp cận tích hợp trên toàn doanh nghiệp để cải thiện các quy trình sản xuất mà vẫn có
thể giảm bớt nhân công dư thừa, độ phức tạp, và chi phí từ việc sử dụng các mô hình
CMM (quy trình quản lý sản xuất phẩn mềm) riêng lẻ và nhiều mô hình CMM.
Mô hình này xác định năm cấp độ của CMM đối với một công ty :
1. Khởi đầu (lộn xộn, không theo chuẩn): đây là điểm khởi đầu để sử dụng một quy trình
mới.
2. Lặp (quản lý dự án, tuân thủ quy trình) : Quy trình này được lặp lại nhiều lần
3. Xác lập (thể chế hóa): Quy trình này được xác lập/ xác nhận như một quy trình doanh
nghiệp tiêu chuẩn.
4. Kiểm soát (định lượng): Tiến hành kiểm soát và đo lường quy trình sản xuất phần

triển khai dự án hoặc sau đó, thậm chí từ phía nhà cung cấp. Chính vì thế mà cần phải
có một qui trình quản lý các thay đổi, nhằm đánh giá tác động của những yêu cầu thay
đổi có thể gây ra, tính quan trọng của mỗi yêu cầu, chi phí để thực hiện việc thay đổi
và cuối cùng quyết định có chấp nhận các yêu cầu thay đổi đó hay không.
Quản lý thay đổi là một phần quan trọng của một dự án thành công. Một quy
trình quản lý thay đổi định nghĩa các bước sử dụng để xác định và thực hiện các thay
đổi đối với một dự án bao gồm cả phạm vi của nó. Các yếu tố trong một quá trình
quản lý thay đổi bao gồm mục đích của kế hoạch quản lý thay đổi, thay đổi các thủ
tục kiểm soát, vai trò và trách nhiệm cho sự thay đổi quản lý, yêu cầu thay đổi một
hình thức, và yêu cầu thay đổi một bản ghi.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
5
3. Quản lý thay đổi cho dự án phần mềm theo chuẩn CMMI
CMMI bao gồm hàng loạt các quy trình trong phát triển phần mềm từ khi bắt
đầu dự án đến khi kết thúc, kèm theo là các tài liệu đi kèm, quản lý cấu hình,… Do
quy mô của tiểu luận nhỏ và thời gian không cho phép nên tiểu luận sẽ chỉ tập trung
vào nguyên tắc và thực hành quản lý thay đổi trong hai vùng quy trình chính là
Configuration Management và Requirements Management.
.
3.1. Vùng quy trình Configuration Management (CM)
3.1.1. Mục đích của quản lý cấu hình
Mục đích của quản lý cấu hình (CM) là thiết lập và duy trì tính toàn vẹn của
sản phẩm bằng cách sử dụng nhận dạng cấu hình, kiểm soát cấu hình, tình trạng cấu
hình kế toán, và kiểm toán cấu hình.
Vùng quy trình trong Quản lý cấu hình liên quan đến các hoạt động sau đây:
• Xác định cấu hình của sản phẩm được lựa chọn thành đường cơ sở tại thời
điểm đã nêu
• Kiểm soát những thay đổi mục cấu hình
• Xây dựng hoặc cung cấp các thông số kỹ thuật để xây dựng các sản phẩm
làm việc từ hệ thống quản lý cấu hình

yêu cầu thay đổi.
Thay đổi được đánh giá thông qua các hoạt động để đảm bảo rằng chúng phù
hợp với tất cả các yêu cầu kỹ thuật và dự án.
Thay đổi được đánh giá tác động của chúng vượt ra ngoài dự án ngay lập tức
hoặc các yêu cầu hợp đồng. Thay đổi một mục được sử dụng trong nhiều sản phẩm có
thể giải quyết một vấn đề ngay lập tức trong khi gây ra một vấn đề trong các ứng
dụng khác.
Thay đổi được đánh giá tác động của kế hoạch phát hành
3.Phân loại và ưu tiên các yêu cầu thay đổi.
Yêu cầu khẩn cấp được xác định và giới thiệu đến một cơ quan khẩn cấp nếu
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
7
thích hợp.
Thay đổi được phân bổ cho các đường cơ sở trong tương lai.
4.Xem lại thay đổi yêu cầu được giải quyết trong các đường cơ sở tiếp theo
với các bên liên quan có liên quan và được sự đồng thuận của họ.
Tiến hành đánh giá yêu cầu thay đổi với sự tham gia thích hợp. Ghi lại các bố
trí của mỗi yêu cầu thay đổi và lý do cho quyết định, bao gồm các tiêu chí thành công,
một kế hoạch hành động ngắn gọn nếu thích hợp, và cần đáp ứng hoặc không được
đáp ứng bởi sự thay đổi. Thực hiện các hành động cần thiết trong các kết quả bố trí và
báo cáo cho các bên liên quan có liên quan.
5.Theo dõi trạng thái của yêu cầu thay đổi cho đến khi hoàn thành.
Yêu cầu thay đổi được đưa vào hệ thống phải được xử lý một cách hiệu quả và
kịp thời. Sau khi yêu cầu thay đổi đã được xử lý, nó là rất quan trọng để đóng các yêu
cầu cho các hành động đã được phê duyệt phù hợp ngay sau đó là thực tế. Các hành
động kết quả mở lớn hơn so với danh sách tình trạng cần thiết, mà lần lượt kết quả
trong chi phí và nhầm lẫn.
kiểm soát Khoản mục cấu hình (SP 2,2 )
Kiểm soát thay đổi mục cấu hình.
Kiểm soát được duy trì so với cấu hình của đường cơ sở sản phẩm công việc.

Cơ chế kiểm soát có thể được cấu hình phù hợp với loại thay đổi. Ví dụ, những
cân nhắc chính có thể là ít nghiêm ngặt đối với thay đổi thành phần mà không ảnh
hưởng đến các thành phần khác.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
9
Mục cấu hình thay đổi được phát hành sau khi xem xét và phê duyệt các thay
đổi cấu hình. Thay đổi không chính thức cho đến khi chúng được phát hành.
3.2. Vùng quy trình Requirements Management (REQM)
3.2.1. Mục đích của REQM
Mục đích của Quản lí yêu cầu (REQM) là để quản lý các yêu cầu của sản
phẩm và các thành phần sản phẩm của dự án và đảm bảo sự liên kết giữa những yêu
cầu và kế hoạch của dự án và các sản phẩm làm việc.
Quy trình quản lý Yêu cầu quản lý tất cả các yêu cầu nhận được hoặc tạo ra
bởi dự án, bao gồm cả các yêu cầu kỹ thuật và không phải kỹ thuật cũng như các yêu
cầu đối với dự án do tổ chức.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
10
Đặc biệt, nếu Yêu cầu vùng quá trình phát triển được thực hiện, quy trình của
nó sẽ tạo ra sản phẩm và yêu cầu thành phần sản phẩm đó cũng sẽ được quản lý theo
các quy trình quản lý yêu cầu.
Tất cả các dự án có yêu cầu. Trong trường hợp các hoạt động bảo trì, thay đổi
này dựa trên thay đổi các yêu cầu hiện tại, thiết kế, hoặc thực hiện. Trong các dự án
cung cấp tăng khả năng sản phẩm, những thay đổi cũng có thể là do nhu cầu của
khách hàng phát triển, công nghệ trưởng thành và lỗi thời, và sự phát triển các tiêu
chuẩn. Trong cả hai trường hợp, những thay đổi yêu cầu, nếu có, có thể được ghi chép
trong các yêu cầu thay đổi từ khách hàng hoặc người sử dụng cuối cùng, hoặc họ có
thể mang hình thức của yêu cầu mới nhận được từ quá trình yêu cầu phát triển. Bất kể
nguồn gốc hoặc hình thức của họ, các hoạt động được điều khiển bởi các thay đổi yêu
cầu được quản lý phù hợp.
Mục tiêu cụ thể và thực hành Tóm tắt thông tin

tiếp cận mới hoặc được sửa đổi, bổ sung để thay đổi kiểm soát là cần thiết.
Ví dụ sản phẩm làm việc
1. Yêu cầu thay đổi các yêu cầu
2. Yêu cầu thay đổi các báo cáo tác động
3. Yêu cầu tình trạng
4. Yêu cầu cơ sở dữ liệu
Subpractices
1. Tài liệu tất cả các yêu cầu và yêu cầu thay đổi được đưa ra hoặc được tạo ra
bởi dự án.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
12
2. Duy trì một lịch sử thay đổi yêu cầu, bao gồm cả các lý do cho sự thay đổi.
Duy trì lịch sử thay đổi giúp để theo dõi các yêu cầu biến động.
3. Đánh giá tác động của thay đổi yêu cầu từ quan điểm của các bên liên quan.
Yêu cầu thay đổi có ảnh hưởng đến kiến trúc sản phẩm có thể ảnh hưởng đến nhiều
bên liên quan.
4. Thực hiện yêu cầu và thay đổi dữ liệu có sẵn cho dự án.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
13
4. Case study: Quy trình quản lý thay đổi
4.1. Mục đích
Quy trình này quy định cách thức chỉnh sửa phần mềm theo yêu cầu khách
hàng trước khi bàn giao cho khách hàng.
4.2. Phạm vi áp dụng
Quy trình áp dụng cho tất cả các dự án phần mềm.
4.3. Nội dung quy trình
4.3.1. Quy trình thực hiện thay đổi
Trách nhiệm Trình tự công việc Biểu mẫu, tài liệu liên quan
PM, PL, Trainer,
TKDA BM_[TV2_QLYC]_QLYC

hình. Đồng thời cập nhật trạng thái các yêu cầu này vào file Quản lý yêu cầu
BM_[QLYC]_QLYC
o Việc tổ chức kiểm tra, review code phải được thực hiện bắt buộc đối với những
phân hệ/ module mới của các sản phẩm truyền thống.
o PM, PL, có trách nhiệm tổ chức họp review code định kỳ (theo kế hoạch trong
Kế hoạch dự án), thông báo kết quả và tổ chức họp như trong Hướng dẫn họp
dự án.
• Kiểm thử:
Giai đoạn Kiểm thử tuân theo Quy trình Kiểm thử
4.3.2.2. Nghiệm thu nội bộ
• Nếu dự án cài đặt phiên bản chuẩn, không có thêm yêu cầu chỉnh sửa từ khách
hàng thì không cần tiến hành Nghiệm thu nội bộ
• TL báo cáo kết quả test.
• PL demo các module, phiên bản theo kịch bản (slide nếu cần) đã được chuẩn bị và
Demo lại các phần đã sửa lỗi theo kết quả test cuối cùng.
• QA trình bày các vấn đề nổi bật về chất lượng và việc đáp ứng các yêu cầu khách
hàng của phiên bản nghiệm thu (mang theo Phụ lục hợp đồng, file QLYC)
• KM đóng góp ý kiến về chương trình và buổi họp.
• Kết thúc buổi họp PM quyết định thông qua phiên bản nghiệm thu hay không. Nếu
không phải có quyết định về ngày nghiệm thu lại. Quyết định của PM về kế hoạch
sửa các lỗi tồn đọng, kế hoạch test lại (nếu có).
• Chú ý: PL có trách nhiệm chuyển lại source code, phiên bản chương trình đã
thông qua trong buổi nghiệm thu cho QA.
4.3.2.3. Cập nhật phiên bản
• Sau khi nghiệm thu nội bộ thành công, PL hoặc cán bộ được phân công lấy phiên
bản của chương trình từ bên QA đi update cho khách hàng.
• Cán bộ đi update phiên bản có trách nhiệm điền đầy đủ thông tin vào Biên bản làm
việc theo biểu mẫu.
4.3.2.4. Hỗ trợ khách hàng
• Sau khi cài đặt cho KH sử dụng chương trình có thể phát sinh một số yêu cầu từ