Bảo trì phần mềm (Software Maintenance) là việc chỉnh sửa một sản phẩm phần
mềm sau khi đã chuyển giao đểsửa lỗi, đểcải tiến hiệu năng (performance) hoặc các
thuộc tính khác, hoặc làm thích ứng sản phẩm trên một môi trường bịthay đổi.
[7]
Trong bảo trì phần mềm chúng ta xem xét hoạt động nâng cấp phần mềm
• Nâng cấp phần mềm: Là việc sửdụng hay triển khai (deploying) một phiên
bản phần mềm mới đểthay thếcho một phiên bản phần mềm khác (cũhơn).
Ví dụ: Nâng cấp phiên bản trình duyệt Firefox 3.0.4 lên Firefox 3.0.7
65 trang |
Chia sẻ: lvbuiluyen | Lượt xem: 1894 | Lượt tải: 2
Bạn đang xem trước 20 trang tài liệu Khóa luận Nghiên cứu một giải pháp bảo trì phần mềm tự động kết hợp với hệthống quản lý cấu hình, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Bùi Chí Tài
NGHIÊN CỨU MỘT GIẢI PHÁP BẢO TRÌ PHẦN
MỀM TỰ ĐỘNG KẾT HỢP VỚI HỆ THỐNG
QUẢN LÝ CẤU HÌNH
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin
HÀ NỘI - 2009
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Bùi Chí Tài
NGHIÊN CỨU MỘT GIẢI PHÁP BẢO TRÌ PHẦN
MỀM TỰ ĐỘNG KẾT HỢP VỚI HỆ THỐNG
QUẢN LÝ CẤU HÌNH
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin
Cán bộ hướng dẫn: ThS. Đào Kiến Quốc
HÀ NỘI – 2009
TÓM TẮT NỘI DUNG
Trong khóa luận tốt nghiệp này, chúng tôi tìm hiểu và nghiên cứu về hệ thống quản
lý cấu hình phần mềm, mà nhiệm vụ quan trọng nhất là quản lý phiên bản. Hầu hết
công cụ quản lý phiên bản hiện thời chỉ chú trọng hỗ trợ cho những nhà phát triển
trong khi phát triển phần mềm nhằm kiểm soát mọi sự thay đổi của phần mềm do nhà
phát triển tạo ra, mà chưa hỗ trợ việc nâng cấp phần mềm tự động về phía khách hàng,
rộng hơn là bảo trì phần mềm tự động. Vì vậy trong khóa luận này, chúng tôi sẽ đề
xuất một giải pháp kết hợp việc nâng cấp tự động với hệ thống quản lý phiên bản.
Dựa trên ý tưởng đó, chúng tôi đã tiến hành phân tích, thiết kế và cài đặt thử
nghiệm chương trình mô phỏng kết hợp nâng cấp phần mềm với hệ thống quản lý
phiên bản.
i
MỤC LỤC
CHƯƠNG 1 MỞ ĐẦU ........................................................................................... - 1 -
1.1. Khái niệm bảo trì phần mềm............................................................................. - 1 -
1.2. Khái niệm quản lý cấu hình phần mềm............................................................ - 1 -
1.3. Vai trò của quản lý cấu hình phần mềm .......................................................... - 1 -
1.4. Hoạt động quản lý cấu hình............................................................................... - 3 -
1.4.1. Các khái niệm cơ bản trong quản lý cấu hình ............................................. - 3 -
1.4.2. Các hoạt động chính trong quản lý cấu hình ................................................ - 3 -
CHƯƠNG 2 THỰC TRẠNG VÀ GIẢI PHÁP.................................................. - 12 -
2.1. Thực trạng......................................................................................................... - 12 -
2.2. Đề xuất giải pháp .............................................................................................. - 13 -
CHƯƠNG 3 PHÂN TÍCH HỆ THỐNG MÔ PHỎNG HOẠT ĐỘNG NÂNG
CẤP TỰ ĐỘNG KẾT HỢP VỚI QUẢN LÝ PHIÊN BẢN............................... - 14 -
3.1. Mục tiêu hệ thống .................................................................................................. - 14 -
3.2. Các chức năng hệ thống ........................................................................................ - 14 -
3.3. Mô hình khái niệm................................................................................................. - 14 -
3.3.1. Các khái niệm ................................................................................................... - 15 -
3.4. Xác định các tác nhân, ca sử dụng và mô tả ca sử dụng .................................... - 15 -
3.4.1. Xác định các tác nhân....................................................................................... - 15 -
3.4.2. Xác định các ca sử dụng (Use Case) ................................................................ - 16 -
3.5. Biểu đồ sử dụng theo gói và mô tả ca sử dụng của hệ thống ............................. - 17 -
3.5.1. Gói quản lý phiên bản....................................................................................... - 17 -
3.5.2. Gói quản lý mã nguồn ...................................................................................... - 21 -
3.5.3. Gói quản lý nâng cấp phiên bản ....................................................................... - 23 -
3.6. Biểu đồ tuần tự hệ thống ....................................................................................... - 25 -
3.6.1. Gói quản lý phiên bản....................................................................................... - 25 -
3.6.2. Gói quản lý mã nguồn ...................................................................................... - 28 -
3.6.3. Gói quản lý nâng cấp phiên bản ....................................................................... - 30 -
3.7. Hợp đồng cho các thao tác hệ thống .................................................................... - 31 -
CHƯƠNG 4 THIẾT KẾ HỆ THỐNG MÔ PHỎNG HOẠT ĐỘNG NÂNG CẤP
KẾT HỢP VỚI QUẢN LÝ PHIÊN BẢN ............................................................ - 37 -
4.1. Biểu đồ tuần tự đối tượng ..................................................................................... - 37 -
4.1.1. Gói quản lý phiên bản....................................................................................... - 37 -
4.1.2. Gói quản lý mã nguồn ...................................................................................... - 42 -
4.1.3. Gói quản lý nâng cấp phiên bản ....................................................................... - 45 -
4.2. Biểu đồ lớp.............................................................................................................. - 47 -
CHƯƠNG 5 CÀI ĐẶT THỬ NGHIỆM ............................................................. - 48 -
ii
5.1. Môi trường triển khai............................................................................................ - 48 -
5.2. Phương pháp triển khai ........................................................................................ - 48 -
5.3. Kết quả triển khai.................................................................................................. - 49 -
CHƯƠNG 6 KẾT LUẬN ..................................................................................... - 58 -
TÀI LIỆU THAM KHẢO..................................................................................... - 59 -
Mở đầu
- 1 -
CHƯƠNG 1
MỞ ĐẦU
Chương này nhằm giới thiệu những khái niệm và hoạt động chung của việc “bảo trì
phần mềm” và “hệ thống quản lý cấu hình”.
1.1. Khái niệm bảo trì phần mềm
Bảo trì phần mềm (Software Maintenance) là việc chỉnh sửa một sản phẩm phần
mềm sau khi đã chuyển giao để sửa lỗi, để cải tiến hiệu năng (performance) hoặc các
thuộc tính khác, hoặc làm thích ứng sản phẩm trên một môi trường bị thay đổi.[7]
Trong bảo trì phần mềm chúng ta xem xét hoạt động nâng cấp phần mềm
• Nâng cấp phần mềm: Là việc sử dụng hay triển khai (deploying) một phiên
bản phần mềm mới để thay thế cho một phiên bản phần mềm khác (cũ hơn).
Ví dụ: Nâng cấp phiên bản trình duyệt Firefox 3.0.4 lên Firefox 3.0.7
1.2. Khái niệm quản lý cấu hình phần mềm
Quản lý cấu hình phần mềm (Software Configuration Management – SCM) là sự
phát triển và áp dụng các chuẩn và các thủ tục để quản lý sự phát triển của hệ thống
sản phẩm. Quản lý cấu hình là hoạt động bao trùm trong suốt tiến trình phần mềm. Bởi
vì những thay đổi có thể xảy ra vào bất cứ lúc nào, hoạt động quản lý cấu hình được
phát triển để xác định thay đổi, kiểm soát thay đổi, đảm bảo rằng những thay đổi đó
được thi hành một cách đúng đắn, và báo cáo những thay đổi đó cho những người liên
quan.[2]
Theo chuẩn CMM và ISO 15504: Mục đích của Quản Lý Cấu Hình là để thiết lập
và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như sản phẩm sau cùng
của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án phần mềm đó.
1.3. Vai trò của quản lý cấu hình phần mềm
Tại sao lại phải quản lý cấu hình ?[3]
Thực tiễn phát triển phần mềm chúng ta thường gặp những sự cố như:
• Một lỗi nào đó của phần mềm đang xây dựng đã tốn công sửa chữa, bỗng
nhiên xuất hiện trở lại.
Mở đầu
- 2 -
• Một chức năng nào đó của phần mềm đã được phát triển và kiểm tra cẩn
thận bỗng thất lạc hoặc biến mất một cách khó hiểu.
• Một chương trình đã được kiểm tra cẩn thận bỗng nhiễn không chạy được
nữa.
• Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức
năng, các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng
bao gồm nhiều tập tin mã nguồn, với nhiều phiên bản khác nhau. Khi tích
hợp hệ thống và biên dịch, trong hàng chục tập tin mã nguồn với hàng trăm
phiên bản, tập tin nào, phiên bản nào là đúng và cần lấy để tiến hành tích
hợp.
Quản lý cấu hình tốt sẽ giải quyết được nhiều vấn đề có thể xảy ra:
• Cập nhật đồng thời: Khi 2 hoặc nhiều lập trình viên làm việc cách biệt nhau
nhưng trên cùng một chương trình hoặc dự án, những thay đổi mà người này
thực hiện có thể phá vỡ kết quả làm việc của người khác. Ví dụ: Sản phẩm
anh A làm ra sử dụng kết quả công việc của anh B, sản phẩm của anh B thay
đổi dẫn đến sản phẩm của anh A không chạy được.
• Chia sẻ mã nguồn: Trong các hệ thống lớn, khi các chức năng chung bị thay
đổi, tất cả những người liên quan phải được biết. Không quản lý mã nguồn
tốt thì không có cách nào đảm bảo tất cả những người liên quan đều được
thông báo những thay đổi đó.
• Vấn đề phiên bản phần mềm (release): Hầu hết các chương trình hoặc hệ
thống lớn được phát triển với nhiều phiên bản từ thấp đến cao. Trong trường
hợp một phiên bản khách đang dùng, phiên bản khác đang được kiểm tra
(test), và một phiên bản khác nữa đang trong quá trình phát triển, khi có một
lỗi xảy ra, việc sửa lỗi phải đồng bộ giữa ba phiên bản này, nếu quản lý mã
Mở đầu
- 3 -
nguồn không tốt, vấn đề đồng bộ rất khó thực hiên được. Nếu lỗi do khách
hàng phát hiện ra, lỗi đó phải được sửa trong tất cả các phiên bản về sau.
Quản lý cấu hình được thực hiện xuyên suốt chu kỳ sống của dự án, từ lúc bắt
đầu đến lúc kết thúc, thậm chí vẫn còn trong giai đoạn bảo trì sản phẩm sau dự án.
1.4. Hoạt động quản lý cấu hình
1.4.1. Các khái niệm cơ bản trong quản lý cấu hình
• Hạng mục cấu hình (Configuration Item - CI): Là tên gọi của các sản phẩm, sản
phẩm trung gian, một file hoặc một nhóm file, tài liệu hoặc một nhóm tài liệu
trong dự án mà ta cần phải quản lý và kiểm soát.
Ví dụ: một file mã nguồn, tài liệu về yêu cầu sản phẩm, bản thiết kế,…
• Ranh giới (Baseline): Là một mốc trong quá trình phát triển phần mềm mà sau
điểm mốc này thì mọi thay đổi phải được thông báo tới tất cả những người có
liên quan.
Ví dụ: Các thành phần của đặc tả thiết kế phải được viết thành tài liệu và
được xem xét lại, các lỗi phải được tìm ra và sửa cho đúng. Một khi mà tất cả
các phần của việc đặc tả đã được xem xét, sửa cho đúng và sau đó được phê
chuẩn thì bản đặc tả thiết kế trở thành một baseline.
1.4.2. Các hoạt động chính trong quản lý cấu hình
Mở đầu
- 4 -
a. Lập kế hoạch quản lý cấu hình
Thông thường việc lập kế hoạch quản lý cấu hình được thể hiện trong một tài liệu
có tên là kế hoạch quản lý cấu hình (Configuration Management Plan – CMP). Bản
kế hoạch này bao gồm các khoản sau:
• Ý nghĩa, mục đích và phạm vi áp dụng của bản kế hoạch.
• Vai trò và trách nhiệm của các nhóm, cá nhân trong dự án thực hiện các
hoạt động khác nhau liên quan đến quản lý cấu hình. Định nghĩa rõ ràng
ai thực hiện, ai tham gia xem xét (review), ai phê duyệt (approve) trên
các hạng mục cấu hình (CI) của dự án, cũng như vai trò của khách hàng,
người sử dụng đầu cuối. Ví dụ minh họa:
Role
Project
Manager
CM
Responsible
CM
Librarian
Tool
Responsible
Subsystem
CCB
Full
System
CCB
Task 1 R S I
Task 2 I R I C
Task 3 I R A C
R: Responsible;A:Approval;S:Support;I:Inform;C:Consult
Mở đầu
- 5 -
• Công cụ, môi trường và cơ sở hạ tầng. Phần này mô tả các công cụ phần
mềm hoặc quy trình thủ tục được sử dụng để hỗ trợ trong việc quản lý
cấu hình, chẳng hạn công cụ quản lý phiên bản sản phẩm (version
control). Mô tả vị trí các máy chủ, máy trạm, cấu hình hệ thống client-
server,…
• Phương pháp nhận diện (identification) và thiết lập các baseline trên các
CI
• Quy ước đặt tên trong dự án, kể cả tên file.
• Quy trình kiểm soát thay đổi (change control process).
• Chỉ định thành viên nhóm kiểm soát cấu hình (Configuration Control
Board –CCB).
• Thông tin nơi lưu trữ các CI.
• Kiểm kê và báo cáo cấu hình (configuration accounting and reporting)
• Quy trình thủ tục lưu trữ và chép dự phòng (backup and archive)
b. Định danh/đánh số các hạng mục cấu hình (Identification of Configuration
Items)
Định danh là một trong những hoạt động nền tảng của quản lý cấu hình.
Mục đích của định danh là để xác định tính duy nhất của một CI, cũng như mối
quan hệ giữa nó với các CI khác. Nó bao gồm việc mô tả tên, đánh số, đánh dấu đặc
trưng cho một CI, giúp nhận biết và phân biệt CI này với CI khác hay thành phần khác.
Trong sản xuất phần mềm, một CI có thể bao gồm một hay nhiều file, ví dụ: một
module ExpMod có thể coi là một CI, nó chứa 2 file khác nhau ExpMod.h và
ExpMod.c
Mỗi CI phải có một số định danh duy nhất, dạng thường thấy là:
__
Ví dụ: PRJ0001_REQB_1.0.4_draft_B
cho biết:
Số ID của dự án: PRJ0001
Số ID của Item: REQB
Mở đầu
- 6 -
Số phiên bản: 1.0.4_draft_B
Trong một dự án, thường số lượng file mã nguồn rất nhiều, do vậy quy tắc
cơ bản cho các file mã nguồn (source code) là: các file cùng tạo nên một khối chức
năng thì nên gom chung thành một CI.
c. Kiểm soát phiên bản (Version Control)
Kiểm soát phiên bản là sự kiểm soát các phiên bản khác nhau của một CI (bao
gồm việc định danh và lưu trữ của CI đó).
Một phiên bản nói dễ hiểu là một thực thể mới của một CI sau khi đã qua một
hoặc nhiều lần xem xét và thay đổi.
Phiên bản của một CI khác với phiên bản của các file thành phần bên trong đó.
Ví dụ phiên bản của CI module “ExpMod” khác với phiên bản của file thành phần
“ExpMod.h” và “ExpMod.c”
Hình 04. Ví dụ phiên bản
Các phiên bản quan trọng của CI có thể được đánh nhãn (label) để đánh dấu và
biểu thị:
• Một “mốc” quan trọng trong tiến trình phát triển CI đó, ví dụ: một phiên
bản được nâng cấp sau một thay đổi lớn.
• Phiên bản mà CI được phê duyệt
• Phiên bản được baseline
d. Quản lý baseline
Các loại baseline thường gặp bao gồm: Chức năng
Kế hoạch
Yêu cầu khách hàng (Requirements)
Mở đầu
- 7 -
Sản phẩm (Product)
Bản phân phối (Release)
Kiểm thử (Test)
Môi trường hoạt động (Environment)
Quản lý baseline bao gồm:
• Chọn các CI cho mỗi loại baseline
• Tiến hành “ghim chết” baseline tại thời điểm sau khi các thay đổi đã
được chấp thuận và phê duyệt
Thông thường baseline được tiến hành tại điểm kết thúc của mỗi pha (phase) hay
các “mốc” quan trọng trong dự án.
Hình 05. Mô tả baseline
Đồng thời, trong quản lý baseline, vai trò và nhiệm vụ của những người thiết lập
và phê chuẩn baseline cũng phải được xác định.
e. Kiểm soát thay đổi (Change Control)
Yêu cầu thay đổi là điều không thể tránh khỏi trong quá trình phát triển hay bảo
trì phần mềm.
Mục đích của “Change Control” là để kiểm soát đầy đủ tất cả các thay đổi ảnh
hưởng đến việc phát triển phần mềm. Đôi lúc chỉ vài thay đổi trong yêu cầu của khách
hàng dẫn đến tất cả các giai đoạn phát triển phần mềm (thiết kế, code, kiểm thử) đều
phải thay đổi theo.
Yêu cầu trong kiểm soát thay đổi là mọi sự thay đổi phải được thông báo đến tất
cả những người hoặc nhóm làm việc có liên quan.
Hình sau mô tả một quy trình kiểm soát thay đổi cơ bản:
Mở đầu
- 8 -
Hình 06. Quy trình kiểm soát thay đổi
Các bước cơ bản trong kiểm soát thay đổi gồm:
• Nghiên cứu, phân tích
• Phê chuẩn hoặc không phê chuẩn
• Thực hiện việc thay đổi
• Kiểm tra việc thay đổi
• Xác lập baseline mới
Khái niệm CCB (Change Control Board) là nhóm kiểm soát thay đổi, nhóm này
được thành lập trong từng dự án.
CCB thông thường bao gồm những người sau trong dự án:
• Người quản lý cấu hình
• Trưởng dự án
• Trưởng nhóm kĩ thuật (Technical lead)
• Trưởng nhóm kiểm thử (Test lead)
• Kỹ sư chất lượng (Quality Engineer)
• Và những ai bị ảnh hưởng bởi các thay đổi
Nhiệm vụ của CCB thường là:
• Bảo đảm tất cả các thay đổi được các bộ phận liên quan nhận biết và
tham gia
Mở đầu
- 9 -
• Xem xét, phê chuẩn hoặc phủ quyết các thay đổi trên các baseline
• Kiểm tra, xác nhận các thay đổi
• Phê chuẩn các bản phân phối sản phẩm đến khách hàng
f. Báo cáo tình trạng cấu hình (Configuration Status Accounting)
Công việc này bao gồm việc ghi nhận và báo cáo tình trạng của các CI cũng như
các yêu cầu thay đổi, tập hợp các số liệu thống kê về các CI góp phần tạo nên sản
phẩm. Nó trả lời các câu hỏi như: có bao nhiêu files bị ảnh hưởng khi sửa chữa một lỗi
phần mềm (bug) nào đó ?
Kết quả của công việc này được ghi lại trong báo cáo Configuration Status
Accounting Report (CSAR). Báo cáo chỉ rõ các điểm:
• Liệt kê tất cả các baseline và các CI thành phần có liên quan
• Làm nổi bật các CI đang được phát triển hoặc vừa bị thay đổi
• Liệt kê các thay đổi đang còn dang dở hay đang hoàn thành, và các
baseline bị ảnh hưởng bởi các thay đổi đó
Báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án.
g. Kiểm định (Auditing)
Có 3 loại kiểm định thường được thực hiện:
CSAR Audit
Kiểm định này thường được làm sau mỗi lần một CSAR được tạo ra, bao
gồm:
• Bảo đảm rằng các baseline mới nhất được liệt kê trong CSAR
• Bảo đảm rằng tất cả các CI tạo nên một baseline được liệt kê
• Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng
với các yêu cầu thay đổi để khẳng định sự thay đổi trên các CI là hợp lý
Physical configuration audit (PCA)
Kiểm định này nhằm mục đích khẳng định xem những gì khách hàng yêu
cầu có được hiện thực trong thực tế hay không, cụ thể bao gồm 2 việc:
• Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc
hiện thực viết code trong dự án: requirements code
Mở đầu
- 10 -
• Xác định những gì sẽ được phân phối cho khách hàng (các file chạy, mã
nguồn, tài liệu đi kèm,v..v..) có đáp ứng với yêu cầu khách hàng không
Functional configuration audit (FCA)
Kiểm định này nhằm mục đích khẳng định xem những gì khách hàng yêu
cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách
hàng hay không, cụ thể là kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu
khách hàng và việc kiểm tra sản phẩm: requirements test
h. Quản lý sản phẩm chuyển giao (release management)
Khái niệm “build” và “release”:
Quá trình phát triển sản phẩm thường qua nhiều lần tích hợp, kết quả của mỗi lần
tích hợp là một bản “build” được hình thành, trong rất nhiều bản “build” đó, một số
bản đáp ứng yêu cầu đã định hoặc lập kế hoạch trước (theo yêu cầu khách hàng), sẽ
được gửi cho khách hàng để kiểm tra hoặc đánh giá. Các bản “build” này sẽ được gọi
là “release”, và công việc tạo ra và phân phối các bản release sẽ được gọi là công việc
“release”. Sản phẩm sau cùng cũng là một bản release, đôi khi còn gọi là “final
release”.
Quản lý release bao gồm nhóm các công việc để bảo đảm rằng tất cả các bản
release gửi cho khách hàng là:
• Hoàn thành, và
• Có thể được tái tạo bởi khách hàng, ví dụ: Khách hàng có thể tạo ra file
chạy (executable) từ các file mã nguồn được gửi tới
Trong quá trình chuyển giao (release), việc quản lý đòi hỏi phải thực hiện các
công việc sau:
• Tiến hành “ghim chết” baseline môi trường phát triển sản phẩm và các
file, tài liệu (sẽ chuyển giao)
• Thực hiện báo cáo CSAR
• Thực hiện các kiểm nghiệm (audit) PCA và FCA
• Đóng gói các file và tài liệu sẽ chuyển giao
• Xác nhận đã nhận bản release từ khách hàng
i. Lưu trữ và chép dự phòng (Backup and Archive)
Mở đầu
- 11 -
Lưu trữ và chép dự phòng là một hoạt động của quản lý cấu hình, đồng thời là
một trong những hoạt động quan trọng của sản xuất phần mềm. Nó giúp khắc phục các
trường hợp rủi ro bị mất mát dữ liệu do thao tác sai, do virus, hoặc do sự cố phần
cứng, phần mềm. Ngoài ra, công việc này còn hỗ trợ cho hoạt động kiể