tiểu luận quản lý cấu hình phần mềm

Hải Phòng, tháng 08 năm 2006
1
TRƯỜNG ĐẠI HỌC HẢI PHÒNG
  
Giảng viên: ……………………
Sinh viên : 1. Trịnh Văn Chiến ( T )
2. Nguyễn Văn Tùng A
3. Cao Thăng Long
4. Trần Văn Tuấn
5. Trần Quyết Cường
Lớp học Cử Nhân Tin K8

BÁO CÁO CÔNG NGHỆ PHẦN MỀM
Đề TàI
QUảN Lý CấU HìNH PHầN MềM
Hải Phòng, tháng 9 năm 2010
1. Quản lý cấu hình phần mềm (Configuration Management) 2
1.1 Quản lý cấu hình phần mềm là gì? 2
1.2 Nội dung của quản lý cấu hình phần mềm 2
1.3 Nhiệm vụ của quản lý cấu hình 4
1.4 Lợi ích của việc quản lý cấu hình phần mềm 4
2. Xác định cấu hình phần mềm 5
3. Kiểm soát phiên bản 6
4. Kiểm soát thay đổi 7
4.1 Qui trình kiểm soát sự thay đổi 8
4.2 Các hoạt động kiểm soát sự thay đổi 9
5. Kiểm toán cấu hình phần mềm 11
5.1 Rà soát kỹ thuật chính thức 11
5.2 Kiểm toán cấu hình phần mềm 11
6. Báo cáo hiện trạng 12
7. Một số công cụ tự động hỗ trợ quản lý cấu hình và quản lý thay đổi 12

7.1 Công cụ hỗ trợ cho sự cộng tác (Collaborative Work Tools) 12
7.2 Công cụ hỗ trợ về tài liệu (Documentation Tools) 13
7.3 Công cụ đối chiếu thiết kế phần mềm (Tools for Reverse Engineering of
Software) 14
7.4 Công cụ quản lý cấu hình (Tools for Configuration Management) 15
8. Vài nét về USDP (Unified Software Development Process) 15
8.1 Giới thiệu chung 15
8.2 Lịch sử phát triển 15
8.3 Kiến trúc tổng quát của RUP 16
Tài liệu tham khảo 18
2
Mục lục Trang
QUẢN LÝ CẤU HÌNH PHẦN MỀM
CONFIGURATION MANAGEMENT
Trong quá trình phát triển các hệ thống thông tin, rất hiếm khi không có thay đổi.
Người dùng thường xuyên quên mất các yêu cầu và chỉ nhớ đến chúng sau này trong
khi tiếp nhận bản thiết kế. Không những thế, sự thay đổi còn xảy ra ngay trong các
giai đoạn phát triển ứng dụng. Sự thay đổi có thể được hình thành cho yêu cầu từ phía
người dùng thay đổi, các bản thiết kế có sự điều chỉnh. Chính sự điều chỉnh này làm
thay đổi qui trình mã hoá và sửa lỗi, những thay đổi đó cần được lưu lại để người phát
triển có thể quản lý được sự tiến hoá của phần mềm.
Sự thay đổi là một trong nhiều lý do khiến cho các dự án đi đến thất bại. Nhưng
hiện nay thực sự chưa phương pháp hiệu quả để hạn chế sự thay đổi và người phát
triển hệ thống phần mềm coi quản lý sự thay đổi đó là một phần trong qui trình quản
lý dự án phần mềm. Qui trình quản lý đó được gọi là quản lý cấu hình phần mềm.
1. Quản lý cấu hình phần mềm (Configuration Management)
1.1 Quản lý cấu hình phần mềm là gì?
Quản lý cấu hình phần mềm là tập hợp các hoạt động dùng để quản lý các thay đổi
của phần mềm trong suốt vòng đời của phần mềm.
Chúng ta cũng cần phân biệt giữa quản lý cấu hình phần mềm và bảo trì phần

mềm. Bảo trì phần mềm là các hoạt động được thực hiện sau khi phần mềm đi vào
hoạt động. Còn quản lý cấu hình phần mềm là hoạt động bao trùm suốt quá trình phát
triển phần mềm thông qua việc theo dõi, kiểm soát phần mềm từ khi bắt đầu phát triển
đến khi phần mềm không còn hoạt động nữa.
Quản lý cấu hình phần mềm được xem là một hoạt động nhằm đảm bảo chất lượng
phần mềm. Vì thông qua các báo cáo liên quan đến sự thay đổi có thể lượng hoá và
đánh giá được qui trình và chất lượng của cả hệ thống phần mềm được xây dựng.
1.2 Nội dung của quản lý cấu hình phần mềm
Nội dung của quản lý cấu hình phần mềm là:
+ Xác định được những thay đổi diễn ra trong quá trình phát triển.
+ Kiểm soát được các thay đổi xuất hiện
3
+ Đảm bảo các thay đổi xuất hiện đã được thực hiện sửa đổi.
+ Báo cáo các kết quả của việc sửa đổi được ghi nhận và gửi đến những người
có trách nhiệm quản lý và xác minh lại sự thay đổi đó.
Quản lý cấu hình phần mềm được thể hiện thông qua các khoản mục sau:
+ Đặc tả hệ thống: bao gồm các tài liệu thu nhận được sau khảo sát, các bước
phân tích đánh giá tài liệu và đưa ra những phác hoạ trong hệ thống dự kiến
sẽ xây dựng. Các đặc tả này thường bao gồm những qui trình nghiệp vụ, nội
dung thông tin cần mà phần mềm cần xử lý.
+ Kế hoạch dự án phần mềm: là tài liệu phân chia khối lượng công việc và
hoạch định thời gian và tiến trình các công việc đó.
+ Đặc tả yêu cầu: thể hiện những yêu cầu liên quan đến phần mềm, những
công việc mà phần mềm sẽ phải đáp ứng sau khi hoàn thành.
+ Đặc tả thiết kế:
- Đặc tả thiết kế dữ liệu
- Đặc tả thiết kế kiến trúc
- Đặc tả thiết kế môđun
- Đặc tả thiết kế giao diện
+ Đặc tả mã nguồn và kiểm thử phần mềm:

- Kế hoạch và thủ tục kiểm thử
- Các ca kiểm thử và các kết quả kiểm thử
- Sổ tay vận hành và sổ tay lắp đặt
- Chương trình thi hành
- Các môđun và mã thi hành được
- Các môđun đã liên kết được
+ Đặc tả cơ sở dữ liệu:
- Lược đồ và cấu trúc các file.
- Nội dung hồ sơ ban đầu.
+ Tài liệu bảo trì:
4
- Các tài liệu liên quan đến công tác bảo trì phần mềm.
1.3 Nhiệm vụ của quản lý cấu hình
Hình 1: Nhiệm vụ của quản lý cấu hình
+ Xác định cấu hình phần mềm.
+ Kiểm soát phiên bản phần mềm
+ Kiểm soát thay đổi.
+ Kiểm toán cấu hình phần mềm
+ Thiết lập các báo cáo liên quan đến những thay đổi trong phần mềm.
Việc quản lý cấu hình cần phải trả lời được các câu hỏi sau:
+ Làm thế nào để tổ chức và quản lý được nhiều phiên bản (Version) của phần
mềm sao cho những thay đổi đem lại sự hiệu quả?
+ Làm sao để tổ chức kiểm soát toàn bộ thay đổi trước và sau khi giao phần
mềm cho người sử dụng?
+ Ai sẽ chịu trách nhiệm về việc chấp thuận và thiết lập thứ tự ưu tiên cho các
thay đổi khi có nhiều thay đổi cùng được đề xuất?
+ Làm thế nào đảm bảo được việc thay đổi đã thực hiện đúng?
+ Dùng cơ chế nào để đánh giá các thay đổi khác nhau?
5
Trên một diện hẹp thì quản lý cấu hình phần mềm còn được coi là quản lý mã

nguồn (Source Code).
1.4 Lợi ích của việc quản lý cấu hình phần mềm
Công việc quản lý cấu hình phần mềm đem lại những ích lợi sau:
+ Cung cấp cho người phát triển phiên bản mới nhất của phần mềm
+ Quản lý được các mã nguồn được lưu trữ phân tán
+ Quản lý được các phiên bản khác nhau của phần mềm
+ Ghi chú lý do của sự thay đổi mã nguồn phần mềm và nội dung thay đổi đó
như thế nào.
+ Tạo sự dễ dàng cho phép người phát triển có thể truy cập lại các phiên bản
cũ trước đó thông qua hồ sơ hay các báo cáo được thiết lập,
+ Giúp tích kiệm được không gian đĩa do không phải cùng một lúc lưu trữ
nhiều phiên bản khác nhau trong giai đoạn phát triển.
+ Cung cấp việc truy cập an toàn và đơn giản đối với bản copy tổng thể về các
kết quả bàn giao đã được thông qua.
+ Kiểm soát được thực trạng của các kết quả bàn giao và mối quan hệ qua lại
lẫn nhau giữa các kết quả này.
+ Cung cấp một kho chứa an toàn đối với các kết quả bàn giao.
+ Cho phép việc kiểm soát và tiết lộ có nguyên tắc các kết quả bàn giao thông
qua vòng đời của nó, với đầy đủ các dấu tích lịch sử, đảm bảo phiên bản
đúng và cập nhật, đã được kiểm tra và phát hành
+ Kiểm soát thay đổi cuả các kết quả bàn giao, đảm bảo các kết quả này được
lưu theo đúng thứ tự .
+ Cung cấp việc lập báo cáo về hiện trạng của các kết quả bàn giao và những
thay đổi của chúng.
2. Xác định cấu hình phần mềm.
6
Xác định cấu hình phần mềm là quá trình thiết lập các đối tượng và đặt tên cho các
đối tượng trong qui trình phát triển phần mềm. Cần đặt tên không trùng lặp cho các
khoản mục trong cấu hình phần mềm để kiểm soát quản lý và tổ chức lại theo phương
pháp hướng đối tượng.

Xác định cấu hình phần mềm chia thành hai loại đối tượng:
+ Đối tượng cơ bản: là một “đơn vị văn bản” được kỹ sư phần mềm tạo ra
trong quá trình phân tích, thiết kế, lập mã và kiểm thử.
+ Đối tượng hỗn hợp: được cấu thành từ các đối tượng cơ bản.
Mỗi đối tượng có một bộ các đặc tính mà thể hiện của nó là duy nhất phân biệt với
các đối tượng khác gồm:
+ Tên đối tượng: dùng để định danh và đại diện cho đối tượng.
+ Mô tả đối tượng phần mềm bằng một danh sách các khoản mục, dữ liệu liên
quan đến đối tượng:
- Kiểu khoản mục cấu hình phần mềm: là tài liệu, chương trình hay dữ
liệu.
- Chứng thư dự án: xác định vị trí của đối tượng nằm trong giai đoạn
nào, phần nào của dự án tổng thể.
- Thông tin thay đổi hay thông tin liên quan đến phiên bản.
+ Danh sách các nguồn lực: là tất cả các thực thể được cung cấp, xử lý, tham
khảo và các thức khác mà đối tượng cần đến.
+ Mối quan hệ giữa các đối tượng là quan hệ bộ phần hay toàn bộ, thể hiện
thông qua đồ thị các đối tượng. Các mối quan hệ khác tương tác giữa các đối
tượng.
Để kiểm soát thay đổi của các đối tượng ta sử dụng đồ thị tiến hoá cho từng đối
tượng. Đồ thị tiến hoá mô tả lịch sử đổi thay của đối tượng đó.
3. Kiểm soát phiên bản
Trước hết, chúng ta cần tìm hiểu thế nào là phiên bản? Phiên bản (Version) là một
thực thể mới của một đối tượng cấu hình (CI: Configuration Item) sau khi đã qua một
7
hoặc nhiều lần xem xét và thay đổi. Kiểm soát phiên bản là tổ hợp các thủ tục và các
công cụ để quản lý các phiên bản khác nhau của các đối tượng cấu hình đã được tạo ra
trong qui trình xây dựng phần mềm.
Quản lý cấu hình cho phép đặc tả cấu hình thay thế của hệ thống phần mềm thông
qua những phản hồi của người dùng khi đưa ra những mong muốn mới liên quan đến

phần mềm. Để xây dựng một biến thể mới cho phần mềm và xác lập những thay đổi
so với các phần mềm trước đó người ta gắn mỗi phiên bản phần mềm với một số đặc
điểm đặc trưng cho nó hay còn gọi là một “bộ thuộc tính”. Một phiên bản phần mềm
mới được xây dựng khi các đặc trưng của phần mềm trước đó đã không còn đáp ứng
được nhu cầu mới của sự phát triển, và sự thay đổi đó là đáng kể về mặt công nghệ.
Phiên bản Delta: Delta có nghĩa là sự khác biệt. Một file Delta là một file thể hiện
sự khác biệt giữa các phiên bản của một phần mềm. Các phiên bản là các bản sao của
một chương trình biểu diễn các thay đổi dần dần. Khi một phiên bản Delta được giữ
lại thể hiện rằng chương trình logic chính được thay đổi một lần. Sau đó, phiên bản
Delta được ứng dụng trên phiên bản chính với những thay đổi đã được thực hiện ta sẽ
thu được các phiên bản Delta.
Phiên bản Alpha: là các phiên bản phần mềm đầu tiên được đưa cho các đối tác
có kinh nghiệm thử nghiệm. Các đối tác ở đây là một lớp người dùng nhỏ, có kinh
nghiệm trong việc triển khai hệ thống. Thông tin được phản hồi là các lỗi được phát
hiện, các góp ý liên quan đến việc cải thiện chất lượng phần mềm.
Phiên bản Beta: Sau khi khắc phục các thiếu xót trong các phiên bản Alpha, phm
đã trở nên hoàn thiện hơn và được tung ra cho lớp người dùng rộng hơn để có thể thu
nhận được nhiều ý kiến đóng góp từ mọi ngành nghề, mọi đối tượng có mục đích và
yêu cầu khác nhau.
8
Hình 2: Sơ đồ kiểm soát phiên bản
Các phiên bản được phân biệt thông qua các con số đi kèm theo sau tên của phần
mềm. Ví dụ một số phiên bản của phần mềm Total Commander: Total Commander
5.0; Total Commander 5.25; Total Commander 6.0; Total Commander 6.3. Ở đây,
chúng ta thấy sự khác biệt trong tên gọi các phiên bản là các con số đi kèm, khoảng
cách giữa các số thường thể hiện sự cải tiến trong phần mềm. Các con số ở hàng đầu
tiên chỉ khi các tính năng của phần mềm được thay đổi cơ bản, còn các thông số sau
chỉ sự cải tiến nhỏ giữa các phiên bản.
4. Kiểm soát thay đổi
Trong quá trình phát triển phần mềm có qui mô lớn không thể không có những

thay đổi. Nếu những thay đổi này không được kiểm soát sẽ dẫn đến tình trạng thiếu
nhất quán, hỗn độn trong toàn bộ hệ thống và dẫn đến sự thất bại của phần mềm.
Chính vì vậy chúng ta cần có sự kiểm soát các thay đổi diễn ra trong quá trình xây
dựng và phát triển hệ thống phần mềm.
Phương thức được sử dụng để kiểm soát thay đổi là phối hợp cả các qui trình thủ
tục, cả con người và các công cụ tự động để tạo ra một cơ chế kiểm soát sự thay đổi
hiện quả.
4.1 Qui trình kiểm soát sự thay đổi
9
* Sơ đồ qui trình kiểm soát sự thay đổi trong dự án phần mềm
10
Nhận ra nhu cầu thay đổi
Người dùng đệ trình yêu cầu thay đổi
Người phát triển đánh giá
Sinh ra các báo cáo về thay đổi
Người có thẩm quyền quyết định kiểm soát thay đổi
Yêu cầu bị bác bỏ
Thông báo cho người dùng
Xếp hạng yêu cầu, tạo thứ tự thay đổi
Phân đối tượng cấu hình cho cá nhân
Các khoản mục đối tượng cấu hình “Check out”
Thực hiện thay đổi
Rà soát thay đổi (kiểm toán)
Các khoản mục đối tượng cấu hình “Check in”
Thiết lập các đường mốc kiểm thử
Tién hành các hoạt động đảm bảo chất lượng kiểm thử
Xem lại các thay đổi sẽ được bao gồm trong lần phần phát
mới
Xây dựng lại phiên bản mới của phần mềm
Rà soát sự thay đổi của các khoản mục cấu hình (kiểm toán)

Bao gồm các thay đổi vào trong phiên bản mới
Phân phối phiên bản mới
Hình 3. Qui trình kiểm soát sự thay đổi trong dự án
11
4.2 Các hoạt động kiểm soát sự thay đổi
Khi một yêu cầu thay đổi được đệ trình cần phải được xác định lại giá trị của yêu
cầu thay đổi đó nhằm:
- Sử dụng kỹ thuật thích hợp để thực hiện thay đổi đó.
- Xác định các hiệu ứng phụ có thể ảnh hưởng lên tổng thể các đối tượng
cấu hình khác và lên các chức năng hệ thống, lên chi phí dành cho dự án có thể
diễn ra khi thực hiện sự thay đổi này.
Kết quả đánh giá về sự thay đổi được báo cáo cho người có thẩm quyền kiểm soát
thay đổi (CCA) – người có quyền cao nhất trong việc kiểm soát tình trạng và quyết
định sự thay đổi đó có được thực hiện hay không.
Khi một thay đổi được chấp thuận, một lệnh thay đổi kỹ thuật (ECO) được tạo ra.
Lệnh này mô tả các đổi thay cần phải làm, các ràng buộc cần phải tuân thủ, các tiêu
chuẩn rà soát và kiểm toán sẽ được thực hiện sau khi thực hiện thay đổi.
Hình 4. Quá trình kiểm soát sự thay đổi trên các đối tượng
Đối tượng cần thay đổi được “Check out” khỏi cơ sở dữ liệu dự án, được thực hiện
sự thay đổi và các hoạt động bảo đảm chất lượng phần mềm cần được áp dụng. Sau
đó, đối tượng này sẽ được “Check in” vào cơ sở dữ liệu và một cơ chế kiểm soát phiên
bản được thực hiện. Quá trình “Check in” và “Check out” thực thi hai điều quan trong
của kiểm soát thay đổi là kiểm soát truy cập và kiểm soát đồng bộ. Kiểm soát truy cập
quản trị những gì mà người kỹ sư có thẩm quyền truy cập và sửa đổi đặc tả cấu hình
12
đặc biệt. Kiểm soát đồng bộ giúp đảm bảo các thay đổi song song hoàn thành bởi
những người khác nhau sẽ không bị viết đè lên nhau. Quá trình “Check out” một đặc
tả cấu hình dựa trên yêu cầu thay đổi đã được chấp thuận và thứ tự thay đổi kỹ thuật
cho phép người kỹ sư phần mềm có thể thực hiện. Chức năng kiểm soát truy câp sẽ
đảm bảo rằng người kỹ sư phần mềm có thẩm quyền “Check out” các đối tượng đó và

kiểm soát đồng bộ sẽ khoá đối tượng đó trong cơ sở dữ liệu dự án sao cho không thể
cập nhật được dữ liệu này cho đến khi phiên bản “Check out” hiện thời được thay thế.
Tuy nhiên, có thể có nhiều bản sao của cùng một đối tượng được “Check out” nhưng
chỉ cỏ bản sao có thẩm quyền mới được cập nhật.
Một bản sao của đối tượng đường mốc gọi là phiên bản trích ly được thay đổi bởi
các kỹ sư. Sau khi được thay đổi và đảm bảo chất lượng phần mềm thì phiên bản thay
đổi đó sẽ được “Check in” ngược trở lại cơ sở dữ liệu dự án và các đối tượng và
đường mốc giới được xác lập liên quan đến đối tượng được thay đổi sẽ được mở khoá
và thực hiện theo đối tượng đã được thực hiện thay đổi. Đường mốc được tạo ra khi
đối tượng đó đã được rà soát kỹ thuật chính thức và được chấp thuận. Sau đó kiểm
soát thay đổi mức dự án sẽ được thực thi. Trước hết, người phát triển phải được sự
chấp thuận của người quản lý dự án (nếu dự án là cục bộ) hoặc được sự chấp thuận
của người có thẩm quyền kiểm soát sự đổi thay nếu thay đổi ảnh hưởng đến các khoản
mục khác trong cấu hình phần mềm.
Quá trình kiểm soát thay đổi với nhiều thủ tục quá chặt chẽ có nguy cơ tạo ra sự
cứng nhắc, quan liêu trong điều phối sự thay đổi. Nếu không tổ chức và kiểm tra tốt,
sự kiểm soát thay đổi có thể dẫn đến việc cản trở tiến trình phát triển của cả dự án.
Hầu hết các người phát triển phần mềm đều có cơ chế kiểm soát thay đổi, họ tạo ra
một số tầng kiểm soát khác nhau trên những mức khác nhau trong dự án để việc kiểm
soát thay đổi có thể dễ dàng được thực hiện và quản lý từ mức thấp đến mức cao của
toàn thể dự án.
Trong một số trường hợp, việc sinh ra nhiều thủ tục chính thức như các yêu cầu,
các báo cáo thay đổi và thứ tự thay đổi có thể được bỏ qua. Tuy nhiên việc đánh giá
từng thay đổi vẫn được tiến hành và tất cả các thay đổi vẫn được theo dõi và rà soát.
Kiểm soát thay đổi chính thức được hình thành khi sản phẩm đã được phân phát cho
13
khách hàng. Thẩm quyền kiểm soát thay đổi đóng một vai trò tích cực trong dự án
phần mềm và phụ thuộc vào đặc tính của dự án phần mềm.
Người có thẩm quyền cần có cái nhìn tổng thể, đánh giá được ảnh hưởng của thay
đổi đối với các yếu tố bên ngoài các khoản mục cấu hình phần mềm như:

- Thay đổi ảnh hưởng tới phần cứng như thế nào?
- Thay đổi ảnh hưởng tới sự thực thi như thế nào?
- Thay đổi ảnh hưởng tới sự nhìn nhận của khách hàng đối với sản
phẩm như thế nào?
- Thay đổi ảnh hưởng tới chất lượng và độ tin cậy của sản phẩm như
thế nào?
-
5. Kiểm toán cấu hình phần mềm
Mục đích của việc kiểm soát phiên bản, kiểm soát sự thay đổi giúp người phát triển
dự án duy trì được trật tự, tránh được tình trạnh hỗn độn trong toàn bộ hệ thống phần
mềm. Tuy nhiên, ngay cả các cơ chế kiểm soát thành công nhất cũng chỉ theo dõi
được sự thay đổi cho đến khi một đối tượng cấu hình kỹ thuật được sinh ra thay thế
cho cấu hình đối tượng trước đó. Như vậy, làm thế nào để đảm bảo sợ thay đổi đó
được thực thi? Để đảm bảo sự thay đổi đó được thực thi chúng ta cần có 2 hoạt động
sau:
- Rà soát kỹ thuật chính thức.
- Kiểm toán cấu hình phần mềm.
5.1 Rà soát kỹ thuật chính thức
Rà soát kỹ thuật chính thức tập trung vào sự đúng đắn về mặt kỹ thuật của đối
tượng cấu hình đã được thực hiện sửa đổi. Người rà soát đánh giá sự phù hợp với các
khoản mục và cấu hình khác có liên quan trong toàn bộ hệ thống phần mềm, tránh
được việc bỏ sót và không kiểm soát được các hiệu ứng phụ có thể xảy ra khi đối
tượng cấu hình này được thay đổi có thể gây nên.
5.2 Kiểm toán cấu hình phần mềm
14
Kiểm toán cấu hình phần mềm là sự bổ sung cho rà soát kỹ thuật chính thức bằng
cách đánh giá một đối tượng cấu hình trên các đặc tính mà thường không được xét đến
trong quá trình rà soát.
Kiểm toán cấu hình đòi hỏi và trả lời được các câu hỏi sau:
- Thay đổi được đặc tả theo trật tự thay đổi kỹ thuật thông qua đã được thực

hiện hay chưa? Những biến đổi phụ nào đã được thực hiện khi thực hiện sự
thay đổi của cấu hình đối tượng này?
- Rà soát kỹ thuật chính thức đã được tiến hành để đánh giá sự đúng đắn về
mặt kỹ thuật hay chưa?
- Các chuẩn kỹ nghệ phần mềm đã được thực sự tuân thủ trong quá trình thực
hiện thay đổi chưa?
- Thay đổi đó đã nổi bật lên trong các khoản mục phần mềm hay chưa? Có
đặc tả ngày thực hiện và tác giả của sự thay đổi đó hay chưa? Các thuộc tính
của đối tượng cấu hình đó đã phản ánh đầy đủ sự thay đổi đó chưa?
- Các thủ tục quản lý cấu hình để giám sát, ghi lại và báo cáo về nó có được
tuân thủ hay không?
- Tất cả các khoản mục cấu hình phần mềm liên quan đã được thực sự cập
nhật chưa?
Trong một vài trường hợp các câu hỏi kiểm toán như là một phần của rà soát kỹ
thuật phần mềm nhưng khi quản lý cấu hình phần mềm là một hoạt động chính thức
thì kiểm toán quản lý cấu hình phần mềm lại được tách ra bở một nhóm bảo đảm chất
lượng riêng.
6. Báo cáo hiện trạng
Báo cáo tình trạng cấu hình (CSR: Configuration Status Report) còn gọi là kiếm
toán tình trạng. Đây là một nhiệm vụ trong quản lý cấu hình phần mềm, việc thiết lập
báo cáo hiện trạng giúp trả lời những câu hỏi sau:
- Cái gì đã xảy ra?
- Ai làm? Ai đã thực hiện?
15
- Việc thay đổi đó xảy ra khi nào?
- Thay đổi đó có còn ảnh hưởng nào khác nữa không?
Thông tin báo cáo tình trạng cấu hình gắn chặt với các nhiệm vụ trong phần kiểm
soát thay đổi. Mỗi khi một khoản mục cấu hình phần mềm được ấn định mới hoặc
được cập nhật các chức thư thay đổi thì một nội dung (Entry) sẽ được tạo ra. Mỗi khi
một khoản mục cấu hình phần mềm được chấp thuận bởi người có thẩm quyền thay

đổi cấu hình (có một mệnh lệnh thay đổi kỹ thuật được tạo ra) thì nội dung cũng được
tạo ra. Mỗi khi một kiểm toán cấu hình được tiến hành thì các kết quả của nó được
báo cáo như là một phần của nhiệm vụ báo cáo trạng thái cấu hình.
Đầu ra của báo cáo tình trạng cấu hình có thể được đặt trên một cơ sở dữ liệu trực
tuyến sao cho những người phát triển phần mềm hay bảo trì có thể truy cập các thông
tin đã được thay đổi. Báo cáo tình trạng cấu hình phần mềm đóng một vai trò cốt lõi
trong thắng lợi của một dự án phát triển phần mềm lớn.
Báo cáo tình trạng cấu hình giúp ta loại trờ vấn đề bất cập liên quan nhiều người
bằng cách cải thiện giao tiếp giữa các thành viên. Nếu không có báo cáo tình trạng cấu
hình có thể dẫn đến sự lãng phí về mặt thời gian và nhân lực khi cùng một sự thay đổi
đối tượng cấu hình lại được thực hiện đi thực hiện lại nhiều lần bởi nhiều nhóm khác
nhau.
7. Một số công cụ tự động hỗ trợ quản lý cấu hình và quản lý thay đổi
Mỗi một khâu trong qui trình quản lý cấu hình và quản lý thay đổi phần mềm đều
có nhiều lớp công cụ khác nhau. Ở đây xin trình bày một số công cụ hỗ trợ chính.
7.1 Công cụ hỗ trợ cho sự cộng tác (Collaborative Work Tools)
Công nghệ Media Space cho phép nhiều người tham gia vào cuộc thảo luận nhìn
thấy người đối diện của mình thông qua bộ hiển thị là bản mạch thuỷ tinh trong suốt
có bộ nhớ điện tử trong đó (Clear Board). Board có thể hiện thị hình ảnh của máy
tính, văn bản và đồ hoạ trung thực, sống động của những người tham gia cuộc họp.
Clear Board cho phép con người theo dõi được cả công việc của mình và công việc
của người đang cùng làm việc với mình, làm tiết kiệm thời gian. Công cụ này được
phát triển tại Xerox PARC.
16
Bảng 1. Một số công cụ hỗ trợ cho sự cộng tác:
STT Tên công cụ Nhà cung cấp Chức năng
1 Cruiserd Bellcore Morristown, NJ
Chương trình vẽ đa người
dùng
2 Greyboard

NeXT Computer Moutain
View, CA
3 Groupkit
Dept. of Computer Science
University of Calgary,
Alberta, Canada
Bộ ứng dụng thời gian
thực chạy trên nền UNIX
4 Notes Lotus Deverlopment Corp MA Email chia sẻ dữ liệu
5
Oracle Mail,
Alert, Toolkit
anf Glue
Oracle Corp,
Redwood City CA
Email phát triển ứng dụng
và giao diện cho chương
trình ứng dụng trên mạng
LAN
6 Timbuktu
TM
Farallon Computing, Inc
Bekelye, CA
Chia sẻ phần mềm mềm
một người dùng cho nhiều
người dùng
7
Video
Whiteboard
ACMSIGCHI

roceedings’91,pp
315-322
Chương trình vẽ nhiều
người dùng
8 VideoDraw
ACMSIGCHI
roceedings’90,pp
313-320
7.2 Công cụ hỗ trợ về tài liệu (Documentation Tools)
Là các công cụ cung cấp tiến trình xử lý từ như WordPerfect nhanh chóng bị thay
thế bằng các phần mềm thông minh hơn là các công cụ phát triển tài liệu có khả năng
được sử dụng lâu dài.
Một trong những khó khăn của tiến trình xử lý từ văn bản là bằng cách nào đó tạo
được bản sao hoặc tham khảo chéo các chủ đề khác nhau nhưng có quan hệ qua lại với
nhau. Phần mền Hypertext đã loại bỏ được khó khăn này thông qua việc cho phép
thiết lập quan hệ giữa các mục văn bản. Phần mềm Hypermedia mở rộng của
Hypertext cung cấp audio, video, ảnh đồ hoạ, văn bản và cả dữ liệu. Trong
Hypermedia các công nghệ đa chức năng này tác động qua lại với nhau và cùng thực
thi trên một môi trường. Hơn nữa, do các công cụ không giới hạn số các kết nối tới
một mục và do sử dụng kỹ thuật luôn kết nối máy tính liên tục nên các ứng dụng về tài
17
liệu được giữ ở trạng thái trực tuyến và có khả năng cung cấp các hoạt động qua lại
đối với tất cả những thành viên tham gia phát triển. Khả năng cung cấp các hoạt động
qua lại này bao gồm một đối tượng quản lý HyperLibrary để quản lý những thay đổi
trong nội dung thư viện.
Bảng 2. Một số công cụ duy trì tài liệu
STT Tên công cụ Nhà cung cấp Chức năng
1 Folio Views
Folio Provo, UT Tiện ích đi kèm
WordPerfect hỗ trợ đa

phương tiện và một số
tình năng đặc biệt khác
2 Hipertext
MT
Apple Computer
Cupertino, CA
Cho phép kết hợp văn bản
với đồ hoạ
3 Microsoft Word
Microsoft Inc
Belleview, WA
Xử lý văn bản, hình ảnh
và kiểm tra ngữ pháp
4
Word Perfect and Word
Perfect Mac with
Gramatik
Word Perfect Corp,
Orem, UT
Xử lý văn bản và kiểm tra
ngữ pháp
5 Word and Beyond
Ludeen and
Associate Alameda,
CA
Cho phép kết hợp văn bản
với đồ hoạ
7.3 Công cụ đối chiếu thiết kế phần mềm (Tools for Reverse Engineering of
Software)
Các công cụ này cho phép đối chiếu thiết kế nhanh chóng để người phát triển phần

mềm có thể kiểm soát được hệ thống. Một vài sản phẩm CASE cung cấp công cụ đối
chiếu thông qua sự phân tích mã để quyết định cấu trúc dữ liệu là cơ sở của tiến trình
xây dựng tạo mã cho ứng dụng. Các công cụ này cho phép phân tích, chỉ ra những
mâu thuẫn trong đặc tả các đối tượng, những lỗi tham khảo chéo của những đoạn mã
rối…
Bảng 3. Một số công cụ dùng cho thiết kế
STT Tên công cụ Nhà cung cấp Chức năng
1
ADW/Maintenance
Workstation
Knowledge Ware, Inc
Atlanta, GA
Tạo sơ đồ quan hệ và
biểu đồ luồng dữ liệu
2 Bachman Series Bachman Information Tạo cấu trúc dữ liệu.
18
System, Inc, Burlington, MA
3 Design Recovery
Intersolv, Inc Tạo cấu trúc chương
trình
4 Ensemble
Carde Technologies, Inc,
providence, RI
Tạo các đối tượng hình
học, biểu đồ.
5 Hindsight
Advance Software
Automation, Inc, Santa
Clara, CA
Dùng cho ngôn ngữ C:

tạo tài liệu, biểu đồ cấu
trúc, phân tích đầy đủ.
6 RE for IE
Texas Instument, Inc with
Price Waterhouse
Tạo sơ đồ quan hệ thực
thể, biểu đồ luồng dữ
liệu.
7 Smartsystem
Procase Corp. Santa Clara,
CA
Tạo cấu trúc dữ liệu
8 Via/Reaissance Viasoft, Inc, Phoenix, AZ
9 Microsoft Visio
Microsoft Inc Belleview,
WA
Tạo sơ đồ quan hệ thực
thể, biểu đồ luồng dữ
liệu.
7.4 Công cụ quản lý cấu hình (Tools for Configuration Management)
Những công cụ quản lý cấu hình thương được gọi là thư viện phần mềm hay thư
viện mã được hình thành vào những năm 70. Các công cụ này cung cấp những mô
hình mới hơn, quản lý các biến đổi dễ dàng hơn nhờ các chức năng giải quyết các vấn
đề phức tạp như biên dịch điều kiện.
Bảng 4. Một số công cụ dùng cho quản lý cấu hình phần mềm
STT Tên công cụ Nhà cung cấp Chức năng
1 Copylib
IBM Armonk, NY Cung cấp thư viện phần mềm cho
các máy tính mainframe IBM
2 Data Expeditor

Data Administration,
Inc
Quản lý dữ liệu, dùng để xem các
định nghĩa file của các cung cấp
như Copylib, Librarain, Panvalet.
3 Librarain
Pansophic System, Inc
Liste, IL
Cung cấp thư viện phần mềm cho
các máy tính mainframe IBM
4 Panvalet
Pansophic Systems, Inc
Liste, IL
Cung cấp thư viện phần mềm cho
các máy tính mainframe IBM
5 RUP (Rational
Unified
Rationnal Quản lý toàn bộ các cấu hình liên
quan đến việc phát triển phần
19
Process) mềm….
8. Vài nét về USDP (Unified Software Development Process)
8.1 Giới thiệu chung
UML là ngôn ngữ mô hình hợp nhất giúp xác định toàn bộ hệ thống phần mềm
dưới dạng hình thức, nghĩa là nó không định nghĩa qui trình phân tích, thiết kế và cài
đặt hệ thống. Những người phát triển UML tạo ra một đặc tả của một qui trình phát
triển phần mềm nhằm giải thích cho cách suy nghĩ của họ về việc xây dựng hệ thống
phần mềm.
Hình 5. Mô hình hợp nhất (UP)
Qui trình phát triển phần mềm theo hướng này gọi là Qui trình phát triển phần

mềm hợp nhất (USDP - Unified Software Development Process) hay Qui trình hợp
nhất Rational (RUP - Rational Unified Process) hay đơn giản hơn còn gọi là Qui trình
hợp nhất (UP - Unified Process).
Qui trình hợp nhất bao gồm con người, dự án, sản phẩm, qui trình và công cụ. Con
người là đối tượng tham gia, là người phát triển dự án nhằm tạo ra sản phẩm phần
mềm theo một qui trình và dùng công cụ tự động để hỗ trợ. Qui trình hợp nhất là một
qui trình tiếp cận theo tình huống sử dụng (Use-case-driven). Nghĩa là yêu cầu của
người sử dụng được mô tả trong các use-case, là một chuỗi các hành động được thực
hiện bởi hệ thống nhằm cung cấp một điều gì đó cho người dùng. Các use-case này
được người phát triển sử dụng như nền tảng của chuỗi công việc để tạo ra mô hình
thiết kế và mô hình cài đặt.
8.2 Lịch sử phát triển
20
Hình 6.Lịch sử phát triển của RUP
8.3 Kiến trúc tổng quát của RUP
Hình 7.Kiến trúc tổng quát của RUP
RUP được tổ chức theo 2 trục:
+ Trục hoành: tổ chức theo thời gian phát triển dự án, thể hiện khía cạnh động của
qui trình phát triển. Bao gồm:
- Chu kỳ (Cycles)
- Các pha (Phases)
21
- Các quá trình lặp (interations)
- Các cột mốc (Milestones) đánh dấu sự thay đổi của phần mềm.
Hình 8. Các giai đoạn phát triển
Trục tung: tổ chức theo nội dung công việc, thể hiện khía cạnh tĩnh của qui trình
phát triển phần mềm. Bao gồm việc mô tả các luồng công việc:
- Luồng công việc chính:
 Business modeling
 Requirement

 Analysis & Design
 Implemention
 Test
 Deployment
- Luồng công việc bổ trợ:
 Project Management
 Configuration and Change Management
 Enviroment
1. Roger S.Pressman
22
Tài liệu tham khảo
Software Engineering, a Practitioner’s Approach, 5th Edition, McGraw-
Hill,2001
2. Ian Sommerville
Software Engineering, Sixth Edition, Addion Wesley, 2001
3. E.M.Bennatan
Software Project Management: a practitioner’s approach,
McGraw-Hill Book Company, 2001
4. Ian Sommerville
Software Engineering, 5
th
Edition, Addion Wesley, 1995
5. Conger, Sue A
The New Software Engineering, Wadsworth Publishing, 1994
6. Ngô Trung Việt
Kỹ nghệ phần mềm, tập 1,2,3. NXB Giáo dục 1998
7. Lê Đức Trung
Công nghệ phần mềm, NXB Khoa học & kỹ thuật, 2002
8. Huỳnh Văn Đức, Hoàng Đức Hải
Giáo trình nhập môn UML, NXB Lao động xã hội, 2003

23