Giáo trình Công nghệ phần mềm - Chương 7: Bảo trì phần mềm và quản lý thay đổi phần mềm

t hay nhiều mức chi tiết, bao gồm cả các mô hình làm việc. Các tài nguyên của dự 
án được xếp đặt làm sao để sản xuất các phiên bản phần mềm được mô tả theo yêu cầu 
phải nhỏ đi. Phiên bản nguyên mẫu làm cho người dùng, người thiết kế và quản trị... 
có thể xem lại được phần mềm. Quá trình đó sẽ tiếp tục khi được đề nghị, với phiên 
bản đang chạy chuẩn bị sẵn sàng phát hành sau vài lần làm lại.
Nếu các mức nguyên mẫu khác nhau được phát triển, nó có thể có một bộ các 
phụ tùng phần mềm có thể được sử dụng khi nhận được yêu cầu bảo trì hiệu chỉnh. Ví 
dụ một module phân tích có thể được thiết kế và thực hiện theo hai cách khác nhau 
nhưng có cùng giao diện bên ngoài. Một phiên bản của module có được sử dụng trong 
phần mềm làm việc. Nếu module đó hỏng, một phụ tùng có thể được lắp thay ngay.
Mặc dù chiến lược phụ tùng thay thế cho phần mềm có vẻ khác thường một 
chút, nhưng không có bằng chứng gì nó tỏ ra tốn kém, khi chúng ta tính đến chi phí 
cho tất cả chu kỳ sống của phần mềm. 
7.5. QUẢN LÝ THAY ĐỔI PHẦN MỀM 
Các ứng dụng thường xuyên phải thiết kế lại do sự phân công của một nhóm 
quản lý mới, dự án vượt quá ngân sách, ứng dụng chậm và có nhiều lỗi, và sự thiếu tin 
tưởng của chủ sử dụng về việc các kỹ sư phần mềm hiểu rõ các yêu cầu của mình,...
Các thay đổi có thể là các yêu cầu, thiết kế, chương trình, giao diện, phần cứng 
hoặc phần mềm phải mua. Phần lớn các thay đổi bắt nguồn từ bên trong tổ chức phát 
triển ứng dụng, nhưng cũng có thể được kích hoạt từ các tác nhân bên ngoài, ví dụ như 
thay đổi về luật. 
Việc quản lý thay đổi ứng dụng giúp cho nhóm triển khai bỏ qua những ý thích 
chợt nảy ra của người sử dụng trong khi vẫn cho phép thực hiện các yêu cầu hợp lý.
7.5.1. Các thủ tục quản lý thay đổi
Quản lý điều khiển thay đổi có hiệu lực từ khi sản phẩm đầu tiên được chấp 
nhận là hoàn thiện cho đến khi dự án kết thúc. Trước tiên, các sản phẩm công việc cơ 
sở được tạo lập để đưa vào quản lý. Một sản phẩm công việc cơ sở là một sản phẩm 
được coi là hoàn thiện và là cơ sở cho các công việc hiện tại khác của nhóm triển khai 
dự án. Ví dụ như, một tài liệu cơ sở là bản quy định yêu cầu chức năng sau khi nó đã 
được chấp nhận bởi người sử dụng.
151
Chương 7: Bảo trì phần mềmvà quản lý thay đổi phần mềm
Dưới đây là ví dụ một quá trình của các thao tác yêu cầu thay đổi của một đặc 
tả chức năng:
• Tạo yêu cầu mở.
• Khai báo file tác động
• Phê chuẩn file về thời gian và chi phí do chủ, người sử dụng ký.
• Hoàn thiện danh sách và kiểm soát về thay đổi của người điều hành dự án.
• File tài liệu liên quan đến thay đổi. Nếu tài liệu hoặc chương trình bị thay 
đổi, thì xác định ngày và các mục cập nhật đã hoàn thiện. Nếu các thủ tục 
hoặc thử nghiệm bị thay đổi, xác định các ngày mà việc sửa đổi xảy ra.
• Mẫu yêu cầu đóng file được chủ/người sử dụng thông qua.
• Tóm tắt các ngày tháng, quá trình và chi phí.
Trước tiên, tài liệu cơ sở được giữ nguyên, sau đó thêm vào các yêu cầu thay 
đổi. Khi quy định chức năng được cập nhật để điều tiết thay đổi, nó được đóng băng 
lại và công việc lại tiếp tục. Ba yêu cầu trước có thể được thêm vào ứng dụng nếu 
chúng không làm thay đổi ứng dụng nhiều. Chúng cũng có thể bị bỏ qua cho đên sau 
khi ứng dụng đã được thực hiện.
Các thay đổi có thể phân loại theo một số cách. 
• Thứ nhất, chúng được phân theo kiểu như loại bỏ lỗi, cải tiến thực hiện hoặc 
thay đổi chức năng. 
• Thứ hai, thay đổi phân loại thành yêu cầu và lựa chọn. 
• Thứ ba, phân theo độ ưu tiên như khẩn cấp, lệnh với một ngày kết thúc yêu 
cầu, lệnh với ngày bắt đầu yêu cầu hoặc ưu tiên thấp. 
• Thông thường, kiểu loại bỏ lỗi là khẩn cấp theo yêu cầu, trong khi thay đổi 
chức năng là bảo dưỡng lệnh theo yêu cầu, và cải tiến thực hiện là lựa chọn 
và có thể không có ưu tiên.
Việc biết được loại yêu cầu thay đổi quyết định xem liệu nó có cần phải chịu 
điều khiển thay đổi hay không. Các thay đổi khẩn cấp thường phá vỡ thủ tục điều 
khiển thay đổi do các công việc thực hiện tuần tự nhưng chúng lại được tài liệu hoá 
sau khi thay đổi đã kết thúc. Tất cả các loại thay đổi khác đều phải tuân theo các điều 
khiển thay đổi. Ví dụ như thay đổi về yêu cầu chức năng có thể xảy ra bất cứ lúc nào, 
nhưng khi quy định yêu cầu chức năng được thông qua thì nó đóng băng cho đến khi 
ứng dụng hoạt động. Các thay đổi phải chịu sự điều khiển thay đổi: chúng được thêm 
vào danh sách yêu cầu thay đổi để xem xét trong tương lai trừ khi đó là một thiết kế 
khẩn cấp.
Một thủ tục điều khiển thay đổi yêu cầu người sử dụng phải đệ trình một lời yêu 
cầu thay đổi chính thức cho người điều hành dự án:
• Người sử dụng gửi cho người điều hành dự án và người chủ một mẫu yêu 
cầu thay đổi.
• Người điều hành dự án và kỹ sư phần mềm triển khai một khai báo tự động. 
Vào lúc đó, danh sách kiểm soát của người điều hành dự án được dùng để 
xác định tất cả các hoạt động và thay đổi công việc có liên quan tới yêu cầu.
• Yêu cầu thay đổi được thảo luận với chủ sử dụng để vạch ra các thay đổi về 
ưu tiên, tiến trình và chi phí.
152
Chương 7: Bảo trì phần mềmvà quản lý thay đổi phần mềm
• Thoả thuận được chính thức hoá và chủ sử dụng thông qua thay đổi về tiến 
trình và chi phí.
• Sử dụng khai báo tác động, ứng dụng và tất cả các tài liệu có liên quan được 
thay đổi. 
• Thực hiện thay đổi: khi các nhiệm vụ hoàn thành, xoá nhiệm vụ trong danh 
sách kiểm soát của người điều hành dự án.
• Chủ sử dụng thông qua việc đóng yêu cầu và yêu cầu được đóng.
• Người điều hành dự án và kỹ sư phần mềm định nghĩa các tác động tiến 
trình và chi phí của thay đổi. Sau đó các thay đổi được bàn bạc với người sử 
dụng. Dựa trên thương lượng với người sử dụng, thay đổi được gán một ưu 
tiên hoạt động, và chi phí và tiến trình được thay đổi.
Yêu cầu, ngày dự định hoạt động, thay đổi tiến trình và tăng chi phí được thêm 
vào một file quá trình dự án. Các thay đổi có thể được quản lý bởi một nhân viên điều 
khiển thay đổi, là một người có nhiệm vụ bảo dưỡng quá trình dự án và các bản ghi 
điều khiển thay đổi, và hàng tháng in ra một bản báo cáo điều khiển thay đổi. Một file 
điều khiển thay đổi chứa tất cả các yêu cầu, thư từ và tài liệu về các thay đổi. Một yêu 
cầu thay đổi mở có thể được tạo ra khi yêu cầu được đưa ra và một số lượng thay đổi 
được gán. Yêu cầu thay đổi mở nằm trong file cho đến khi yêu cầu được hoàn thành, 
đóng và được báo cáo.
Khi thay đổi được thực hiện, các mục có ảnh hưởng được cập nhật, bao gồm tư 
liệu tương ứng, mã,... Một danh sách kiểm soát của người điều hành dự án được dùng 
để loại bỏ các hoạt động đã được yêu cầu. Tài liệu mới được nhân viên điều khiển thay 
đổi sắp xếp và phân phối nó cho những người có quan tâm. Ngày hoàn thành thay đổi 
được đưa vào file điều khiển thay đổi. Thay đổi được xác định khi được đóng trong 
báo cáo tình trạng tới và yêu cầu mở được chuyển từ file điều khiển thay đổi sang.
Dựa trên tổ chức này, người điều hành hệ thống có thể theo dõi các yêu cầu 
thay đổi cúa dự án để nhận biết sự thành công trong nhóm các yêu cầu. Chi phí thay 
đổi chung của một năm thường được sử dụng như là một chỉ tiêu để chỉ ra xem ứng 
dụng đang có triển vọng hay cần vứt bỏ hay cần công nghệ hoá lại. Trong những 
trường hợp này, cả chi phí và số lượng các yêu cầu thay đổi đều được theo dõi thông 
qua quá trình điều khiển thay đổi. Các báo cáo tổng kết bởi dự án thay đổi trong một 
thời kỳ nhất định, hoặc so sánh theo thời kỳ có thể được triển khai. 
7.5.2. Ghi quyết định theo thời gian
Khi bắt đầu một dự án, người điều hành dự án và kỹ sư phần mềm quyết định 
sử dụng các công cụ để lưu trữ quá trình quyết định. Có nghĩa là có thể dùng công cụ 
điện tử hoặc một phiên bản viết tay và các quyết định được duy trì dưới dạng văn bản. 
Với công cụ điện tử, các bản sao điện tử được lưu trữ. Với công cụ ghi tay, phiên bản 
cũ được cập nhật và đổi tên khi một tài liệu thay đổi. Ví dụ như, các quy định chức 
năng của công ty ABC có thể được đặt tên là ABCFS-mmddyy, trong đó ABC là công 
ty, FS là viết tắt của quy định chức năng (Functional Specification) và mmddyy là 
ngày tháng. Phần ngày tháng của tên sẽ thay đổi do bất kỳ một thay đổi quan trọng nào 
của tài liệu. Thủ tục quản lý thay đổi sẽ được nói đến trong phần tiếp theo.
153
Chương 7: Bảo trì phần mềmvà quản lý thay đổi phần mềm
7.5.3. Quản lý thay đổi tài liệu
Các thay đổi tài liệu có thể được xác định bởi một bảng nội dung các thay đổi 
tại đầu mỗi tài liệu. Bảng nội dung các thay đổi bao gồm ngày hiệu lực, các phần bị 
ảnh hưởng của tài liệu và một tóm tắt về thay đổi. Mục đích của bảng nội dung các 
thay đổi là để tóm tắt tất cả các thay đổi cho người đọc.
Các thay đổi nên được đánh dấu đỏ trong văn bản để xác định được bộ phận 
thay đổi. Nếu nội dung cũ là quan trọng thì nó có thể được đưa vào trong chú ý, được 
ghi ngày tháng, và được dán nhãn là phiên bản trước. Cần nhớ rằng bạn cũng phải giữ 
tài liệu phiên bản cũ để dùng cho quá trình phát triển.
154
Chương 7: Bảo trì phần mềmvà quản lý thay đổi phần mềm
TÀI LIỆU THAM KHẢO
1. Ngô Trung Việt, Kỹ nghệ phần mềm - bản dịch, Nhà xuất bản Giáo dục, 1999.
2. Đoàn Văn Ban, Phân tích thiết kế và lập trình hướng đối tượng, Trung tâm 
Khoa học Tự nhiên và Công nghệ Quốc gia,1996.
3. Lê Đức Trung, Công nghệ phần mềm, Nhà xuất bản Khoa học và Kỹ thuật, 
2002.
4. Khoa Công nghệ Thông tin - Đại học Khoa học Tự nhiên Hà Nội, Bài giảng về 
nhập môn công trình học phần mềm, Hà Nội, 1997.
5. Lê Đức Trung, Những viên ngọc trong kỹ thuật lập trình - bản dịch, Trung tâm 
Tin học và Điện tử Phương Đông, 1992 .
6. Roger S. Pressman Ph.D, Software engineering a practitioner's - 5th, McGraw-
Hill book Co.-Singapore, 2001. 
7. Yourdon, E. Software reuse, Application development strategies, Vol. 6, No. 
12, December 1994, pp.1-16.
8. Sommerville I., Software engineering - 4th, Addison Wesley, 1995.
9. Eldon Wig, Industry Software engineering course - VCIT project, Intellitec 
Consulting Inc., Hà Nội 10/1999.
155