Bài giảng Nhập môn công nghệ phần mềm - Trương Minh Thái - Chương 6: Quản lý cấu hình

 phiên bản khác nhau của hệ thống
Quản lý cấu hình

 Các chuẩn của CM

 Định nghĩa và sử dụng các chuẩn CM là rất cần thiết để 
xác nhận chất lượng

 Các chuẩn có thể được dựa trên các chuẩn CM bên 
5
ngoài tổng quát và được điều chỉnh cho phù hợp với 
với môi trường cụ thể của tổ chức

 Các chuẩn nên định nghĩa các các thành phần (item) 
được nhận dạng, cách các thay đổi được kiểm soát và 
cách các phiên bản mới được quản lý
Quản lý cấu hình

 Tại sao 1 hệ thống tồn tại ở nhiều cấu hình khác 
nhau?
6
Quản lý cấu hình

 Các cấu hình được tạo ra:

 Cho các máy/ hệ điều hành khác nhau

 Cung cấp các chức năng khác

 Đáp ứng các yêu cầu đặc biệt của người dùng
7
Lập kế hoạch quản lý cấu hình

 Kế hoạch quản lý cấu hình

 Định nghĩa những cái được quản lý (thành phần cấu hình) 
và một sơ đồ được dùng để nhận dạng những thành phần đó

 Định nghĩa người có trách nhiệm đối với các thủ tục CM và 
gửi các thành phần cấu hình tới nhóm quản lý cấu hình
8

 Định nghĩa các chính sách để quản lý phiên bản và kiểm 
soát sự thay đổi 

 Xác định các công cụ mà ta nên được sử dụng để quản lý 
cấu hình và quy trình sử dụng chúng

 Định nghĩa cơ sở dữ liệu CM được sử dụng để lưu thông tin 
cấu hình và những thông tin khác nên được lưu trong CSDL 
đó
Lập kế hoạch quản lý cấu hình

 Nhận dạng các thành phần cấu hình

 Các dự án lớn thường tạo ra hàng ngàn tài liệu mà 
chúng phải được nhận dạng là duy nhất

 Một số tài liệu này phải được bảo quản trong suốt 
9
thời gian sống của phần mềm

 Sơ đồ phân cấp với với các tên đa mức có thể là 
một phương pháp uyển chuyển nhất
Lập kế hoạch quản lý cấu hình

 Nhận dạng các thành phần cấu hình

 Các thành phần cấu hình:

 Các đặc tả

 Các thiết kế
10

 Các chương trình

 Dữ liệu kiểm thử

 Tài liệu hướng dẫn người sử dụng
Lập kế hoạch quản lý cấu hình

 Phân cấp cấu hình
11
Lập kế hoạch quản lý cấu hình

 Cơ sở dữ liệu của quản lý cấu hình

 Tất cả các thông tin CM nên được lưu trong cơ sở dữ 
liệu cấu hình

 Nó còn cho phép các truy vấn về quản lý cấu hình như:
12

 Ai có một phiên bản hệ thống cụ thể?

 Phần cứng và hệ điều hành nào được yêu cầu cho một 
phiên bản cụ thể? 

 Những phiên bản nào bị ảnh hưởng bởi sự thay đổi của 
thành phần X?

 Có bao nhiêu lỗi được báo cáo trong phiên bản T?
Lập kế hoạch quản lý cấu hình

 Cơ sở dữ liệu của quản lý cấu hình

 Có thể là một phần của môi trường được tích hợp nhằm 
hỗ trợ phát triển phần mềm

 Cơ sở dữ liệu CM và các tài liệu được quản lý tất cả được 
13
lưu giữ trong cùng hệ thống

 Các công cụ CASE có thể được tích hợp để liên kết 
một cách trực tiếp các thay đổi với các tài liệu và các 
bộ phận bị ảnh hưởng bởi sự thay đổi

 Một cách phổ biến hơn, cơ sở dữ liệu CM được lưu 
tách biệt vì nó rẻ hơn và linh động hơn
Quản lý sự thay đổi

 Ai là người đưa ra các yêu cầu thay đổi đối với hệ 
thống?
14
Quản lý sự thay đổi

 Quản lý sự thay đổi

 Các yêu cầu thay đổi đối với hệ thống phần mềm có 
thể bắt nguồn từ

 Người dùng
15

 Nhà phát triển

 Áp lực thị trường

 Quản lý sự thay đổi liên quan tới việc theo dõi các thay 
đổi này và đảm bảo rằng chúng được thực hiện theo 
cách hiệu quả nhất về chi phí
Quản lý sự thay đổi

 Qui trình quản lý sự thay đổi
16
Quản lý sự thay đổi

 Biểu mẫu yêu cầu thay đổi (change request form)

 Sự định nghĩa của một biểu mẫu yêu cầu thay đổi là 
một phần của quy trình lập kế hoạch CM

 Biểu mẫu này lưu sự thay đổi được đề nghị, người yêu 
17
cầu thay đổi, lý do tại sao sự thay đổi này được đề nghị 
và tính cấp bách của sự thay đổi

 Nó còn lưu ước lượng về sự thay đổi, phân tích ảnh 
hưởng, chi phí thay đổi và các đề nghị
Quản lý sự thay đổi
18
Quản lý sự thay đổi

 Các công cụ theo dõi sự thay đổi

 Một vấn đề chính trong quản lý sự thay đổi là theo dõi 
trạng thái của sự thay đổi

 Các công cụ theo dõi sự thay đổi theo dõi trạng thái 
19
của từng yêu cầu thay đổi và đảm bảo rằng các yêu cầu 
thay đổi được gửi tới đúng người, đúng thời điểm

 Được tích hợp với các hệ thống e-mail để cho phép sự 
phân phát các yêu cầu thay đổi điện tử
Quản lý sự thay đổi

 Ban kiểm soát sự thay đổi

 Các thay đổi nên được xem lại bởi một nhóm bên bên 
ngoài những người quyết định xem chúng có mang lại 
lợi nhuận hay không theo quan điểm chiến lược và tổ 
20
chức hơn là theo quan điểm kỹ thuật

 Ban kiểm soát sự thay đổi nên là một nhóm độc lập của 
dự án

 Ban kiểm soát sự thay đổi có thể gồm một đại diện cấp 
cao từ phía khách hàng và nhân viên đấu thầu
Quản lý sự thay đổi

 Lịch sử tiến hóa

 Là hồ sơ về các thay đổi được áp dụng cho các thành 
phần mã lệnh

 Nó nên lưu (những nét chính) sự thay đổi được tạo ra, 
21
mối quan hệ đối với sự thay đổi, ai tạo ra sự thay đổi 
và khi nào nó được thực hiện

 Nó có thể được xem như một chú thích trong mã lệnh. 
Nếu một mẫu phần mở đầu chuẩn được sử dụng cho 
lịch sử tiến hóa, các công cụ có thể xử lý nó một cách 
tự động 
Quản lý sự thay đổi

 Lịch sử tiến hóa – Thông tin của phần đầu trang của một 
thành phần
22
Quản lý phát hành và phiên bản

 Phát triển một sơ đồ định danh cho các phiên bản 
của hệ thống

 Lập kế hoạch khi một phiên bản của hệ thống mới 
được tạo ra
23

 Đảm bảo rằng các công cụ và thủ tục quản lý 
phiên bản được áp dụng một cách đúng đắn

 Lập kế hoạch phân phối các phát hành của hệ 
thống mới
Quản lý phát hành và phiên bản

 Nêu sự khác nhau giữa phiên bản, phát hành và 
biến thể?
24
Quản lý phát hành và phiên bản

 Phiên bản / Biến thể / Phát hành 

 Phiên bản (version): Một thể hiện của hệ thống mà nó 
khác biệt chức năng với các thể hiện khác của hệ thống 
theo cách nào đó
25

 Biến thể (variant): Một thể hiện của hệ thống mà nó 
giống về chức năng nhưng khác về phi chức năng với 
các thể hiện khác của hệ thống

 Phát hành (release): Một thể hiện của hệ thống mà nó 
được phân phối cho người dùng bên ngoài nhóm phát 
triển
Quản lý phát hành và phiên bản

 Xác minh phiên bản

 Các thủ tục xác minh phiên bản nên định nghĩa một 
cách rõ ràng việc nhận dạng các phiên bản thành phần

 Ba kỹ thuật cơ bản để xác minh thành phần
26

 Đánh số phiên bản

 Xác minh dựa trên thuộc tính

 Xác minh hướng tới sự thay đổi
Quản lý phát hành và phiên bản

 Đánh số phiên bản

 Sơ đồ đánh số đơn giản nhất sử dụng sự tiến hóa tuyến 
tính

 V1, V1.1, V1.2, V2.1, v.v
27

 Cấu trúc tiến hóa thực tế là một cây hay một mạng hơn 
là một sự liên tục

 Các tên không có ý nghĩa

 Sơ đồ đặt tên phân cấp đưa đến ít lỗi hơn trong việc 
xác minh phiên bản
Quản lý phát hành và phiên bản

 Đánh số phiên bản – Cấu trúc tiến hóa của phiên 
bản
28
Quản lý phát hành và phiên bản

 Xác minh dựa trên thuộc tính

 Các thuộc tính có thể được sử dụng để nhận dạng phiên 
bản

 Các thuộc tính có thể là ngày, người tạo ra, ngôn ngữ 
29
lập trình, khách hàng, trạng thái, v.v

 Cách làm này có thể gây ra các vấn đề về tính đơn nhất 
– tập các thuộc tính phải được chọn để tất cả các phiên 
bản có thể được định danh duy nhất

 Trong thực tiễn, một phiên bản còn cần một tên kết 
hợp để tham khảo dễ dàng 
Quản lý phát hành và phiên bản

 Xác minh dựa trên thuộc tính

 Một thuận lợi quan trọng của xác minh dựa trên 
thuộc tính là nó có thể hỗ trợ các truy vấn 

 Truy vấn chọn ra một phiên bản phụ thuộc vào các 
30
giá trị thuộc tính
Quản lý phát hành và phiên bản

 Nhận dạng hướng tới sự thay đổi

 Tích hợp các phiên bản và các thay đổi được thực hiện 
để tạo ra các phiên bản đó

 Được sử dụng cho hệ thống hơn là cho thành phần
31

 Mỗi một thay đổi hệ thống được đề nghị có một tập 
thay đổi kết hợp mà nó mô tả các thay đổi được thực 
hiện cho các thành phần của hệ thống
Quản lý phát hành và phiên bản

 Quản lý phát hành

 Phát hành hệ thống là một phiên bản của hệ thống mà 
nó được phân phối tới khách hàng

 Nhà cung cấp sản phẩm phần mềm thường chỉ đưa ra 
32
các phát hành mới cho các nền mới hay thêm các chức 
năng mới rất cần thiết

 Các hệ thống hiện nay thường được phát hành trên đĩa 
quang hoặc các tập tin cài đặt có thể tải xuống từ trang 
web
Quản lý phát hành và phiên bản

 Các vấn đề phát hành

 Khách hàng có thể không muốn bản phát hành mới của 
hệ thống

 Quản lý phát hành không nên giả sử rằng tất cả các 
33
phát hành trước đó được chấp nhận. Tất cả những tập 
tin cần cho một phát hành nên được tái tạo khi một 
phát hành mới được cài đặt
Quản lý phát hành và phiên bản

 Đưa ra quyết định phát hành

 Việc chuẩn bị và phân phối một bản phát hành hệ 
thống là một quy trình tốn kém

 Các yếu tố như chất lượng kỹ thuật và tổ chức tác động 
34
đến việc quyết định khi nào đưa ra một phát hành của 
hệ thống mới
35
Quản lý phát hành và phiên bản

 Những thành phần đi kèm khi phát hành một hệ 
thống?
36
Quản lý phát hành và phiên bản

 Phát hành hệ thống

 Không chỉ là một tập các chương trình có thể thực thi 
được

 Mà có thể bao gồm
Các tập tin cấu hình định nghĩa cách thức phát hành được 
37


cấu hình cho một sự cài đặt cụ thể

 Các tập tin dữ liệu cần cho sự vận hành hệ thống

 Một chương trình cài đặt hay một script tiện ích để cài 
đặt hệ thống lên phần cứng đích

 Các tư liệu ở dạng giấy hay dạng điện tử

 Đóng gói và quảng cáo liên quan
Quản lý phát hành và phiên bản

 Tư liệu hóa sự phát hành

 Ghi lại các phiên bản cụ thể của các bộ phận mã nguồn 
được sử dụng để tạo ra mã thực thi

 Lưu bản sao của mã nguồn, mã thực thi, tất cả dữ liệu 
38
và các tập tin cấu hình

 Ghi lại phiên bản của hệ điều hành, thư viện, bộ biên 
dịch và những công cụ được sử dụng để xây dựng phần 
mềm
Xây dựng hệ thống

 Xây dựng hệ thống là quy trình biên dịch và liên 
kết các bộ phận phần mềm vào một chương trình 
mà nó thực hiện trên một cấu hình đích cụ thể

 Các hệ thống khác nhau được xây dựng từ các kết 
39
hợp khác nhau về các bộ phận phần mềm

 Qui trình này hiện nay luôn được hỗ trợ bởi các 
công cụ tự động
Xây dựng hệ thống
40