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

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ên


Nă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

Theo dõi và kiểm soát thay đổi ( SG 2 ) 6
3.1. 3. Thực hành 7
3.2. Vùng quy trình Requirements Management (REQM) 10
3.2.1. Mục đích của REQM 10
3.2. 2. Nguyên tắc 11
Quản lý Yêu cầu (SG 1) 11
3.2. 3. Thực hành 12
Quản lý Yêu cầu thay đổi (SP 1,3 ) 12
4. Case study: Quy trình quản lý thay đổi 14
4.1. Mục đích 14
4.2. Phạm vi áp dụng 14
4.3. Nội dung quy trình 14
4.3.1. Quy trình thực hiện thay đổi 14
4.3.2. Mô tả quy trình 14
5. Kết luận 15
6. Tài liệu tham khảo 16
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
1
DANH MỤC CÁC HÌNH
Hình 1. Mô hình CMMI 3
THUẬT NGỮ VÀ VIẾT TẮT
STT Thuật ngữ/Viết tắt Ý nghĩa
1.
KH Khách hàng
2.
MTYC Mô tả yêu cầu
3.
YCTD Yêu cầu thay đổi
4.
QLCH Quản lý cấu hình

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

mềm
5. Tối ưu (cải tiến quy trình): Kiểm soát quy trình bao gồm việc cân nhắc kỹ để cải tiến/
tối ưu hóa quy trình.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
3
1.1. Ứng dụng CMMI
Các công ty thương mại và chính phủ sử dụng mô hình CMMI để hỗ trợ viêc
xác định cải tiến quy trình để xây dựng hệ thống, xây dựng phần mềm và phát triển
quy trình và sản phẩm tích hợp.
Công ty sử dụng quy trình này để phát triển, thu thập và duy trì các sản phẩm
và dịch vụ và để làm chuẩn cho chính họ chống lại các công ty khác. Các quy trình tốt
hơn cũng có thể là những quy trình có giá rẻ hơn và kết quả chất lượng tốt hơn, cũng
như là những quy trình này ước tính thời gian thực cho dự án chính xác hơn.
Tuy nhiên, cũng giống như tất cả các cơ cấu khác, CMMI không thể nhanh
chóng phù hợp với tất cả các công ty mà không ảnh hưởng đến sự phát triển của công
ty đó. SEI cho biết việc cải thiện các dự án sẽ được tính bằng tháng và năm chứ
không phải chỉ tính bằng ngày và tuần.Vì việc cải thiện dự án thường đòi hỏi phải có
nhiều kiến thức và nguồn lực nên các công ty lớn hơn có thể có được kết quả tốt hơn
từ CMMI. Tuy nhiên, việc thay đổi quy trình CMMI cũng có thể giúp ích cho các
công ty nhỏ hơn.
SEI không cấp giấy chứng nhận cho bất cứ loại hình CMMI nào. Đơn giản là
SEI chỉ cấp giấy phép hoạt động và cho phép các nhà thẩm định hàng đầu tiến hành
đánh giá.
1.2. Các level của CMMI
1.3. Các Vùng quy trình của CMMI
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
4
2. Các thay đổi trong dự án phần mềm
Trong quá trình triển khai dự án phần mềm, luôn có những yêu cầu thay đổi
đối với bản kế hoạch ban đầu từ phía khách hàng hoặc người sử dụng trong quá trình

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

• Duy trì tính toàn vẹn của đường cơ sở
• Cung cấp tình trạng chính xác và dữ liệu cấu hình hiện tại cho các nhà phát
triển, người dùng cuối, và khách hàng
Các sản phẩm làm việc đặt dưới sự quản lý cấu hình bao gồm các sản phẩm
được gửi đến khách hàng, sản phẩm công việc nội bộ, sản phẩm đã mua, công cụ, và
các mặt hàng khác được sử dụng trong việc tạo ra và mô tả các sản phẩm làm việc
này .
3.1. 2. Nguyên tắc
Theo dõi và kiểm soát thay đổi ( SG 2 )
Thay đổi đối với các sản phẩm công việc thuộc phạm vi quản lý cấu hình được
theo dõi và kiểm soát.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
6
Các thực hành cụ thể theo mục tiêu cụ thể này phục vụ để duy trì đường cơ sở
sau khi được thành lập bởi các thực hành cụ thể theo mục tiêu Thiết lập đường cơ sở
cụ thể.
3.1. 3. Thực hành
Theo dõi Các yêu cầu thay đổi (SP 2,1)
Theo dõi yêu cầu thay đổi cho các hạng mục cấu hình.
Yêu cầu thực hiện thay đổi không chỉ đối với yêu cầu mới mà còn đối với yêu
cầu thay đổi trong các sản phẩm làm việc nhưng bị thất bại hoặc khuyết tật .
Yêu cầu thay đổi được phân tích để xác định tác động của sự thay đổi sẽ có
trong sản phẩm làm việc, các sản phẩm liên quan đến lao động, ngân sách, và lịch
trình.
Ví dụ sản phẩm làm việc
1. Các yêu cầu thay đổi
Subpractices
1. Bắt đầu và ghi lại các yêu cầu thay đổi trong cơ sở dữ liệu yêu cầu thay
đổi.
2. Phân tích tác động của thay đổi và các bản sửa lỗi được đề xuất trong các

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.

Kiểm soát này bao gồm theo dõi các cấu hình của từng hạng mục cấu hình, phê duyệt
một cấu hình mới nếu cần thiết, và cập nhật các đường cơ sở.
Ví dụ sản phẩm làm việc
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
8
1. Lịch sử sửa đổi của các cấu hình
2. Đường cơ sở
Subpractices
1. Kiểm soát thay đổi mục cấu hình trong suốt vòng đời của sản phẩm hoặc
dịch vụ.
2. Có được quyền thích hợp trước khi thay đổi mục cấu hình được nhập
vào hệ thống quản lý cấu hình.
Ví dụ, ủy quyền có thể đến từ các CCB, người quản lý dự án, sở hữu sản phẩm,
hoặc khách hàng.
Kiểm tra và kiểm tra mục cấu hình trong hệ thống quản lý cấu hình để kết hợp
với những thay đổi một cách duy trì tính chính xác và toàn vẹn của mục cấu hình.
Ví dụ về các bước check-in và check-out bao gồm những điều sau đây:
• Xác nhận rằng các phiên bản được ủy quyền
• Cập nhật các mục cấu hình
• Lưu trữ các đường cơ sở thay thế và lấy các đường cơ sở mới
• Bình luận về những thay đổi được thực hiện cho mục
• Ràng buộc thay đổi cho các sản phẩm công việc liên quan như yêu cầu, những câu
chuyện của người dùng, và các xét nghiệm
4.Thực hiện đánh giá để đảm bảo rằng những thay đổi đã không gây ra tác dụng không
mong muốn về đường cơ sở (ví dụ, đảm bảo rằng những thay đổi đã không bị tổn hại sự
an toàn, an ninh của hệ thống).
5. Ghi lại thay đổi mục cấu hình và các lý do cho những thay đổi cho phù hợp.
Nếu thay đổi được đề xuất cho các sản phẩm làm việc được chấp nhận, một
lịch trình được xác định hợp với sự thay đổi vào các sản phẩm công việc và các khu
vực bị ảnh hưởng khá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

SG 1 Quản lý Yêu cầu
SP 1,1 Hiểu Yêu cầu
SP 1,2 đạt được cam kết để yêu cầu
SP 1,3 Quản lý Yêu cầu thay đổi
SP 1,4 Duy trì Truy xuất nguồn gốc hai chiều của yêu cầu
SP 1,5 Đảm bảo sự liên kết giữa làm việc và các yêu cầu của dự án
Chúng ta sẽ xem xét mục tiêu SP1,3: Quản lý yêu cầu thay đổi
3.2. 2. Nguyên tắc
Quản lý Yêu cầu (SG 1)
Yêu cầu được quản lý và mâu thuẫn với kế hoạch dự án và các sản phẩm làm
việc được xác định.
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
11
Dự án duy trì một hiện tại và các yêu cầu trong suốt thời gian của dự án đã
được phê duyệt thiết lập bằng cách làm những điều sau đây:
• Quản lý tất cả các thay đổi yêu cầu
• Duy trì mối quan hệ giữa các yêu cầu, kế hoạch, dự án, và các sản phẩm làm
việc
• Đảm bảo sự liên kết giữa các yêu cầu, kế hoạch, dự án, và các sản phẩm làm
việc
• Hành động khắc phục
3.2. 3. Thực hành
Quản lý Yêu cầu thay đổi (SP 1,3 )
Quản lý thay đổi yêu cầu khi chúng phát triển trong quá trình thực hiện dự án
Yêu cầu thay đổi cho một loạt các lý do. Khi nhu cầu thay đổi và tiến hành
công việc, thay đổi này có thể phải được thực hiện với yêu cầu hiện tại. Đó là điều
cần thiết để quản lý những bổ sung và thay đổi một cách hiệu quả và hiệu quả. Để có
hiệu quả phân tích tác động của thay đổi, nó là cần thiết rằng nguồn gốc của yêu cầu
từng được biết đến và lý do cho sự thay đổi được ghi chép lại. Dự án có thể muốn
theo dõi các biện pháp thích hợp các yêu cầu biến động để đánh giá liệu phương pháp

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

Dev, Tester QT_TV2_KT
Nhóm dự án BM_[TV2_CSYC]_NTNB
PL BM_[TV2_DTCG]_BBLV
PL, Trainer, cán
bộ liên quan
BM_[TV2_DTCG]_BBLV
BM_[TV2_CSYC]_DSTD
QA QT_TV2_QLCH
4.3.2. Mô tả quy trình
4.3.2.1. Chỉnh sửa và Kiểm thử
Trong trường hợp kết quả đào tạo không có yêu cầu cần chỉnh sửa thì chuyển
thẳng sang pha Hỗ trợ khách hàng, bỏ qua bước khảo sát yêu cầu và các bước 4.3.2.1,
4.3.2.2
• Chỉnh sửa:
o Cán bộ đươc phân công có trách nhiệm chỉnh sửa chương trình theo đúng các
yêu cầu thay đổi được phân tích, tổng hợp trong file 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
14
Yêu cầu chỉnh sửa
Lưu hồ sơ
Chỉnh sửa và Kiểm thử
Nghiệm thu nội bộ
Cập nhật phiên bản
Hỗ trợ khách hàng
-
+
BM_[QLYC]_QLYC trong quy trình QT_QLYC. Việc chỉnh sửa này phải
tuân theo các quy định lập trình
o Sau khi các yêu cầu thay đổi được thực hiện, QA có trách nhiệm cập nhật các
CI/WP dự án đã thay đổi (đặc biệt là source code) phục vụ việc quản lý cấu

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ừ

KH. PL hoặc cán bộ được phân công nhận yêu cầu gửi cho PM quyết định có thực
hiện hay không.
• Mọi công việc hỗ trợ KH đều phải được ghi nhận vào Biên bản làm việc với
khách hàng theo biểu mẫu BM_[DTCG]_BBLV có chữ ký xác nhận của KH.
• Danh sách tham dự BM_[CSYC]_DSTD có thể đính kèm với Biên bản làm việc.
4.3.2.5. Lưu hồ sơ
• PM/QA được phân công lưu các hồ sơ đã được thông qua theo Quy trình quản lý
cấu hình QT_QLCH.
5. Kết luận
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
15
6. Tài liệu tham khảo
[1] CMMI Product Team. CMMI
®
for Development, Version 1.3, November 2010.
[2] Anne Mette Jonassen Hass. Configuration Management Principles and Practice,
December 30, 2002.
[3] Ronald Kirk Kandt. Organizational Change Management Principles and
Practices, Jet Propulsion Laboratory, 4800 Oak Grove Dr., Pasadena, CA 91 109,
USA ronald. k. .
Học viên thực hiện: Lê Thị Thu Hà - Đào Minh Tuấn – Nguyễn Thu Huyền
16