Bài giảng Công nghệ phần mềm

Phân tích 
va chạm 
Kế hoạch giải 
thoát hệ thống 
Thực hiện 
thay đổi
Giải thoát 
hệ thống
Bảo trì mang 
tính hoàn thiện 
Bảo trì mang 
tính thích nghi 
Bảo trì mang 
tính sửa chữa 
Đôi khi thay đổi yêu cầu có liên quan đến các vấn đề của hệ thống và phải đ−ợc khắc phục ngay. 
Ví dụ nh−, một lỗi trong hệ thống của khách hàng phải đ−ợc sửa chữa nhanh chóng để đáp ứng 
đ−ợc các yêu cầu kinh doanh thông th−ờng. Khuynh h−ớng tự nhiên trong tình huống này là 
thông qua một tiến trình nh− mô hình sau: 
 Việc sửa chữa ngay đôi khi rất cần thiết nếu nh− vấn đề đó ảnh h−ởng đến hiệu lực của hệ 
thống. Tuy nhiên, sự nguy hiểm trong cách tiếp cận này là các tài liệu thiết kế không đ−ợc cập 
nhật. Mã và thiết kế dần dần trở nên xa rời hệ thống. Khó có thể tránh đ−ợc vấn đề này bởi các 
nhân viên bảo trì buộc phải giải quyết những tình thế khẩn cấp mới cho phần mềm. Nếu một kỹ 
s− làm những thay đổi trong mã nguồn tạm nghỉ công việc tr−ớc khi bản thiết kế đ−ợc cập nhật 
thì sau đó anh ta sẽ rât khó khăn trong việc nắm bắt những thay đổi mới trong thiết kế. 
Một vấn đề mang tính khẩn cấp hơn trong việc sửa chữa hệ thống là phải hoàn thành một cách 
nhanh nhất có thể đ−ợc. Cách giải quyết đ−ợc sử dụng đôi khi thích hợp hơn giải pháp tối −u. 
Điều này thúc đẩy tiến trình già hoá phần mềm, vì vậy những thay đổi trong t−ơng lai ngày càng 
khó hơn. Nếu coi bảo trì là một tiến trình độc lập, nó th−ờng đ−ợc xem nh− là một sự lặp lại các 
tiến trình phát triển. Những yêu cầu mới phải đ−ợc phát triển một cách có hệ thống và đ−ợc chấp 
thuận. Các thành phần của hệ thống phải đ−ợc thiết kế lại và thực hiện. Từng phần hay toàn bộ 
hệ thống phải đ−ợc kiểm tra lại. Mô hình đ−ợc minh hoạ trong hình 1.3 sau: 
Tiến trình phát triển đ−ợc các tổ chức coi nh− những tiến trình phần mềm thông th−ờng. Nếu sự 
thay đổi là cần thiết, nó sẽ đ−ợc thay đổi nh− một phần của tiến trình phần mềm. 
Việc lặp lại tiến trình phát triển có hiệu quả khi những thay đổi không lớn và có thể thực hiện 
đồng loạt. Nếu phải thực hiện việc sửa chữa mã nguồn, các vấn đề của tài liệu trở nên mâu thuẫn 
và suy giảm tính cấu trúc, điều đó có thể tránh nếu các yêu cầu thay cho việc sửa chữa những 
vấn đề còn tồn tại ch−a đ−ợc giải quyết sau khi các lỗi mã hoá đã bị cố định. Nó có thể đ−ợc 
thực hiện lại một cách cẩn thận sau khi phân tích kỹ. Tất nhiên việc sửa chữa mã có khi bị dừng 
lại. Tuy nhiên một cách lựa chọn tốt hơn để giải quyết vấn đề này sẽ đ−ợc tìm ra sau vài lần 
phân tích. 
II/ Tài liệu hệ thống: 
Sản xuất và bảo trì tài liệu hệ thống là một sự hỗ trợ đáng kể cho kỹ nghệ bảo trì. Tài liệu hệ 
thống bao gồm tất cả các tài liệu mô tả sự thực hiện của hệ thống, từ những đặc tả yêu cầu rồi 
Thay 
đổi yêu 
Sửa chữa mã 
nguồn
Phân phối sửa 
chữa hệ thống 
Cập nhật 
yêu cầu
Phân tích 
thay đổi 
Phát triển 
phần mềm 
Phân tích 
mã nguồn
Thay đổi 
yêu cầu 
cuối cùng là chấp nhận kế hoạch kiểm tra. Tài liệu có thể đ−ợc sinh ra để hỗ trợ tiến trình bảo trì 
bao gồm: 
• Tài liệu yêu cầu và một lý do kết hợp. 
• Một tài liệu mô tả các cấu trúc hệ thống. 
• Đối với mỗi ch−ơng trình trong hệ thống, một bản mô tả kiến trúc là một ch−ơng trình. 
• Mỗi thành phần có một đặc tả và một mô tả thiết kế riêng. 
• Danh sách các ch−ơng trình mã nguồn cần đ−ợc chú thích. Nếu các tên có ý nghĩa đ−ợc sử 
dụng sẽ tránh đ−ợc những vấn đề còn mơ hồ. Nhiều mã ch−ơng ttrình có thể lập tài liệu mà 
không cần có những bình luận mang tính chú thích. Các ch−ơng trình chú giải chỉ cần giải 
thích những phần mã phức tạp và cung cấp các mối quan hệ giữa các ph−ơng thức mã hoá 
đ−ợc sử dụng. 
• Tài liệu kiểm chứng mô tả mỗi ch−ơng trình đ−ợc kiểm chứng nh− thế nào, thông tin có 
quan hệ với yêu cầu đ−ợc kiểm chứng. 
• Một h−ớng dẫn bảo trì hệ thống mô tả các vấn đề hiểu biết về hệ thống và mô tả những thành 
phần của hệ thống phụ thuộc vào phần cứng và phần mềm. Bản h−ớng dẫn cũng giải thích sự 
tiến triển của hệ thống nh− thế nào để thích hợp cho việc tính toán. Trong thiết kế tài liệu hệ 
thống cũng cần có tính cấu trúc và việc h−ớng dẫn tổng quát ng−ời đọc một cách quy củ và 
mô tả chi tiết hơn các khía cạnh của hệ thống. Một điều rất quan trọng là tài liệu phải rõ ràng 
và dễ đọc. Trong đó các chuẩn trình bày cần không mâu thuẫn với manul ng−ời sử dụng. 
III/ Ch−ơng trình tiến triển động: 
Ch−ơng trình tiến triển động nghiên cứu về những thay đổi của hệ thống. Đa số những nghiên 
cứu trong lĩnh vực này đ−ợc thực hiện bởi Lehman vàBelady (1985). Từ những nghiên cứu này 
họ đã đề xuất một tập các quy tắc liên quan đến sự thay đổi hệ thống. Họ cho rằng các quy tắc 
này không thay đổi và cần đ−ợc ứng dụng rộng rãi. 
Các quy tắc của Lehman là một trong những ví dụ trong kỹ nghệ phần mềm của những học 
thuyết đ−ợc hình thành từ quan sát thực tiễn. Đó lấy thực tiễn của các nghành khoa học khác để 
làm nền tảng cho những học thuyết hình thành từ quan sát, để thực hiện những quan sát một 
cách khách quan trong kỹ nghệ phần mềm là rất khó khăn và tốn kém. 
Lehman và Belady đã khảo sát quá trình phát triển của nhiều phần mềm. Những quy tắc đ−ợc 
đ−a ra đều xuất phát từ hình thức này. Những quy tắc đ−ợc chỉ ra trong bảng sau: 
Quy tắc 
Tiếp tục thay đổi 
Tăng sự phức tạp 
Mở rộng ch−ơng 
trình lớn 
Mô tả 
Một ch−ơng trình đ−ợc sử dụng trong môi tr−ờng thế giới 
thực cần thiết phải có những thay đổi để có ích hơn trong 
môi tr−ờng ứng dụng 
Khi một ch−ơng trình thay đổi, tính cấu trúc phải đ−ợc 
duy trì và nó sẽ trở nên phức tạp hơn. Các ph−ơng tiện có 
sẵn bên ngoài phải đ−ợc dùng cho việc duy trì và đơn 
giản hoá cấu trúc. 
Tiến hoá ch−ơng trình là một tiến trình tự điều khiển. Các 
thuộc tính của hệ thống nh− kích cỡ, thời gian giữa những 
lần giải 
Sự gắn chặt tính 
tổ chức 
Sự duy trì tính 
thân thiện 
Thoát, và số các lỗi đ−ợc phát hiện là gần nh− bất biến 
trong mỗi lần hệ thống đ−ợc đ−a ra sử dụng. 
Qua thời gian sống của ch−ơng trình, tỉ lệ phát triển xấp 
xỉ một hằng số và phụ thuộc vào các ph−ơng tiện có sẵn 
dùng cho việc phát triển hệ thống. 
Qua thời gian sống của hệ thống, những thay đổi sau mỗi 
lần đ−a vào sử dụng xấp xỉ một hằng số 
Quy tắc đầu tiên nói rằng bảo trì hệ thống là một tiến trình không thể tránh đ−ợc. Sửa chữa lỗi 
chỉ là một phần trong hoạt động bảo trì. Hệ thống các yêu cầu luôn luôn thay đổi. Vì vậy một hệ 
thống phải phát triển nếu nó muốn duy trì tính hữu ích. Lý do cho vấn đề này là môi tr−ờng hệ 
thống thay đổi theo thời gian và các yêu cầu của khách hàng cũng thay đổi. 
Quy tắc thứ hai là khi một hệ thống bị thay đổi, tính cấu trúc cũng giảm dần. Việc thêm các mã 
phải đ−ợc chấp nhận, nếu không tính cấu trúc bị giảm sút và bị đảo lộn. Tiến trình bảo trì có thể 
bao gồm các hoạt động xây dựng lại cấu trúc một cách rõ ràng nhằm tăng khả năng thích nghi 
của hệ thống. 
Quy tắc thứ ba có lẽ là điều thú vị nhất và đáng quan tâm nhất trong các quy tắc của Lehman. 
Nó dự đoán rằng mỗi hệ thống lớn đều có một động lực của chính nó, đ−ợc thành lập tại giai 
đoạn tr−ớc của tiến trình phát triển. Điều khiển bảo trì có thể không đ−ợc làm, tuy nhiên nó 
muốnnhững thay đổi của hệ thống đ−ợc đề cập. Lehman và Belady đã dự đoán rằng quy tắc này 
là một kết quả của cấu trúc cơ bản và các nhân tố có tính tổ chức. 
Một hệ thống v−ợt quá kích th−ớc nhỏ nhất, nó tác động giống nhau lên một khối cố định, với 
kích cỡ hạn chế và có nhiều thay đổi lớn hơn bởi vì các thay đổi hình thành nên các lỗi mới làm 
giảm các chức năng của hệ thống. Nếu một thay đổi lớn đ−ợc đề xuất sẽ mang lại nhiều lỗi mới 
và làm giảm tính hữu ích của những thay đổi bắt nguồn trong một phiên bản mới của hệ thống 
Những hệ thống lớn th−ờng đ−ợc sử dụng trong các tổ chức lớn. Những tổ chức này th−ờng có 
thói quan liêu, làm giảm tiến trình thay đổi và là nhân tố quyết định xem có chi ngân sách cho 
những hệ thống riêng lẻ hay không. Những thay đổi hệ thống lớn hơn đòi hỏi đ−a ra những 
quyết định mang tính tổ chức và những thay đổi để dự kiến ngân sách. 
Cần phải có thời gian để đ−a ra quyết định. Trong thời gian đó, những vấn đề về thay đổi hệ 
thống đ−ợc −u tiên hơn. Ta cần phải sắp xếp những thay đổi để tiến trình phê chuẩn đ−ợc bắt 
đầu lại thuận lợi hơn. Hơn nữa, tỷ lệ những thay dổi của hệ thống đ−ợc quản lý một cách cục bộ 
bởi các tiến trình làm nên những quyết định của tổ chức. 
Quy tắc thứ t− của Lehman cho rằng hầu hết các ch−ơng trình lớn dự kiến làm việc trong một 
trạng thái đ−ợc gọi là “bão hoà”. Điều này cũng đ−ợc dự đoán qua quy tắc thứ năm, nó gợi ý 
rằng sự tiến triển của ch−ơng trình phụ thuộc nhiều vào quyết định của ng−ời điều khiển. Quy 
tắc này xác nhận rằng sự phát triển cao độ phần mềm lớn là không thực hiện đ−ợc nếu nh− tổng 
phí truyền thông giữa những ng−ời thiết kế chiếm −u thế trong công việc của họ. Quy tắc thứ 
năm của Lehman đề cập đến sự gia tăng các thay đổi trong mỗi lần hệ thống đ−ợc đ−a vào sử 
dụng. 
Những quan sát của Lehman chỉ có thể nhận biết một cách chung chung. Chúng nên đ−ợc đ−a 
vào những tính toán trong việc lập kế hoạch bảo trì. Nó có thể bị bỏ qua trong một lần nào đó vì 
những lý do th−ơng mại. 
Nó có thể xuất hiện theo những cách hoàn toàn khác nhau và rõ ràng giữa những lần đ−a các sản 
phẩm ch−ơng trình vào thực hiện theo các quy tắc của Lehman. Ví dụ nh− trong vòng m−ời năm 
Microsoft word đã thay đổi từ một bộ sử lý từ đơn giản thao tác trong bộ nhớ 256k tới một khối 
khổng lồ. Bây giờ nó cần nhiều Gigabit bộ nhớ và tốc độ xử lý cao. Điều này d−ờng nh− trái với 
quy tắc thứ ba và thứ t− của Lehman. 
Tuy nhiên tôi nghi ngờ rằngch−ơng trình này không thực sự là những phiên bản có thứ tự. Hơn 
nữa những cái tên giống nhau còn tồn tại là những lý do th−ơng mại nh−ng ch−ơng trình cũng có 
những kế thừa lớn giữa những lần phát hành. 
Tóm lại, bảo trì là một phần tất yếu trong tiến trình xây dựng phần mềm. Những ng−ời làm thiết 
kế luôn phải chú trọng tới b−ớc này, nó đòi hỏi nhiều thời gian và công sức.