Bài giảng phát triển vận hành và bảo trì phần mềm chương 4

3.1.1 Định nghĩa• Bảo trì là công việc tu sửa, thay đổi phần mềm đã được phát triển chương trình, dữ liệu, các loại tư liệu đặc tả,.. – Sửa các yêu cầu và các chỗ hổng thiết kế– Cải tiến

Chương 4

BẢO TRÌ PHẦN MỀM

MỤC TIÊU:

 Hiểu được vai trò của việc bảo trì phần mềm

 Nắm được các vấn đề liên quan đến bảo trì: phân

loại, phương pháp, chi phí bảo trì …

 Hiểu được một số quy trình và các chiến lược cải

tiến phần mềm

 Tìm hiểu về tái kỹ nghệ

NỘI DUNG CHÍNH

3.1 Giới thiệu

3.2 Tiến trình bảo trì

3.3 Một số hiệu ứng lề

3.4 Những vấn đề về bảo trì hiện nay

3.5 Các kỹ thuật cho bảo trì

3.6 Ma trận các chủ đề bảo trì p/m và tài

liệu tham khảo

3.1 Giới thiệu

3.1.1 Định nghĩa

• Bảo trì là công việc tu sửa, thay đổi phần

mềm đã được phát triển (chương trình, dữ liệu,

các loại tư liệu đặc tả, ) theo những lý do nào đó

• Bảo trì thường không bao gồm những thay

đổi chính liên quan tới kiến trúc của hệ thống.

• Những thay đổi trong hệ thống thường được

cài đặt bằng cách:

– điều chỉnh những thành phần đang tồn tại và

– bổ sung những thành phần mới cho hệ thống.

3.1.2 Tại sao phải bảo trì

• Bảo trì là không thể tránh khỏi vì:

– Các yêu cầu hệ thống thay đổi khi hệ thống đang được xây dựng

=> hệ thống được chuyển giao có thể không thoả mãn các yêu cầu của nó.

– Hệ thống gắn kết chặt chẽ với môi trường của nó

=> thay đổi môi trường sẽ thay đổi các yêu cầu của hệ thống.

– Các hệ thống phải được bảo trì nếu chúng muốn

là những phần hữu ích trong môi trường nghiệp vụ.

– Sửa các yêu cầu và các chỗ hổng thiết kế

– Cải tiến thiết kế

– Tạo các nâng cấp

– Giao tiếp với các hệ thống khác

– Chuyển đổi chương trình sang nền tảng p/cứng,

p/mềm, … phù hợp

3.1.2 Tại sao phải bảo trì

• Các khía cạnh chính mà bảo trì tập trung là:

– Bảo trì điều khiển toàn bộ các chức năng của hệ

=> P/mềm phải được cải tiến và bảo trì

3.1.2 Tại sao phải bảo trì

3.1.3 Phân loại bảo trì

Bảo trì tu chỉnh và phòng ngừa được xếp vào loại

bảo trì sửa chữa

Bảo trì thích nghi và hoàn thiện thuộc loại

nâng cấp

a) Bảo trì để tu chỉnh

• Là bảo trì khắc phục những khiếm khuyết có trong phần mềm

• Một số nguyên nhân điển hình

– Kỹ sư phần mềm và khách hiểu nhầm nhau

– Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết

– Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, thiết kế sai, biên soạn sai

– Thiếu chuẩn hóa trong phát triển phần mềm

• Các bước thực hiện: dò lại thiết kế để tu sửa

c) Bảo trì để hoàn thiện

• Là việc tu chỉnh phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn

• Những nguyên nhân chính:

– Mở rộng thêm chức năng mới cho hệ thống

– Cải tiến quản lý kéo theo cải tiến tài liệu vận hành

và trình tự công việc

– Thay đổi người dùng hoặc thay đổi thao tác

• Còn gọi là tái kỹ nghệ (re-engineering), với

mục đích đưa ra một thiết kế của cùng một chức năng nhưng có chất lượng cao hơn

• Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt

3.1.3 Chi phí bảo trì

• Chi phí bảo trì thường lớn hơn chi phí xây

dựng gấp từ 2 đến 100 lần phụ thuộc vào từng ứng dụng:

– Chi phí bảo trì bị ảnh hưởng bởi cả các yếu tố kỹ

thuật và phi kỹ thuật.

– Nếu bảo trì càng nhiều, sẽ càng làm thay đổi cấu

trúc phần mềm và do đó sẽ làm cho việc bảo trì càng trở lên khó khăn hơn.

– Phần mềm có tuổi thọ càng cao thì cần chi phí

bảo trì càng cao

Phân bổ chi phí bảo trì

Các yếu tố ảnh hưởng đến chi

kế lại cho các thay đổi trong tương lai.

• Kỹ năng của nhân viên: nhân viên bảo trì thường không có kinh nghiệm và hiểu biết về miền ứng dụng của họ bị hạn chế.

• Tuổi thọ và cấu trúc chương trình: khi tuổi thọ

và cấu trúc chương trình bị xuống cấp thì chúng càng trở lên khó hiểu và thay đổi nhiều.

Dự đoán bảo trì

• Dự đoán bảo trì:

– liên quan tới việc đánh giá những phần nào của

hệ thống có thể gây ra lỗi và cần bao nhiêu chi phí để bảo trì.

• Khả năng chịu được sự thay đổi

– phụ thuộc vào khả năng bảo trì của các thành

phần bị ảnh hưởng bởi sự thay đổi đó.

• Thực hiện các thay đổi

– có thể làm hỏng hệ thống và giảm khả năng bảo

trì của nó.

• Chi phí bảo trì

– phụ thuộc vào số lượng các thay đổi và

– chi phí thay đổi phụ thuộc vào khả năng bảo trì.

• Có thể dự đoán bảo trì thông qua việc đánh giá độ phức tạp của các thành phần hệ thống.

• Độ phức tạp của thành phần phụ thuộc vào:

– Độ phức tạp của cấu trúc điều khiển

– Độ phức tạp của cấu trúc dữ liệu

– Kích thước của đối tượng, phương thức và mô-đun.

• Ngoài ra, ta có thể sử dụng các phép đo quy trình để

đánh giá khả năng bảo trì của hệ thống.

– Số lượng các yêu cầu cần bảo trì sửa lỗi.

– Thời gian trung bình cần thiết để phân tích ảnh hưởng

– Thời gian trung bình để cài đặt một yêu cầu thay đổi.

– Số lượng các yêu cầu cần giải quyết.

Dự đoán bảo trì

Dự đoán thay đổi

– Dự đoán số lượng các thay đổi có thể xảy ra và

tìm hiểu mối quan hệ giữa hệ thống và môi trường của nó.

Làm thế nào để giảm độ phức tạp bảo trì

• Sử dụng các kỹ thuật kiểm thử tốt hơn trong suốt

quá trình phát triển

• Tạo ra các tài liệu tốt hơn, tuân theo các chuẩn và

các quy ước

• Dự đoán các thay đổi trong tương lai trong suốt giai

đoạn xác định yêu cầu

– Thiết kế hướng đến sự mở rộng: chi phí bảo trì dòng mã lớn hơn gấp 20 đến 40 so với giai đoạn xd dòng mã đó

• Thiết kế cấu trúc hệ thống để không ràng buộc với

các thay đổi trong tương lai

• Tách ra các thành phần mà có thể thay đổi trong

tương lai

• Giành sự cố gắng hơn trong quá trình thiết kế ban

đầu để có được các yêu cầu đúng của người sử dụng

• Khi quyết định lựa chọn hoạt động bảo trì hay thay

thế phần mềm, ta cần trả lời các câu hỏi sau:

– Chí phí bảo trì không quá cao?

– Tính tin cậy của hệ thống có được chấp nhận không?

– Hệ thống có không mất đi khả năng thích nghi với các thay

đổi trong tương lai với một giản đồ và chi phí hợp lý

– Hệ thống có thực hiện dựa trên các ràng buộc đã mô tả

trước không?

– Các chức năng không làm hạn chế tính hữu ích của hệ

thống?

– Không thể có các hệ thống khác mà làm công việc tương tự

nhanh hơn, tốt hơn và rẻ hơn?

– Chi phí bảo trì phần cứng không trở nên đắt đến nỗi mà phần cứng có thể bị thay thế

=> Nếu tất cả các trả lời đều là Yes thi ta mới nên tiến hành bảo trì

Làm thế nào để giảm độ phức tạp bảo trì

• Để cải thiện hệ thống hiện có, người ta

đã đề xuất 4 chiến lược cơ bản:

– Tách hệ thống và chỉnh sửa các quy trình

nghiệp vụ

– Tiếp tục bảo trì hệ thống

– Biến đổi hệ thống bằng cách tái kỹ nghệ

để nâng cấp khả năng bảo trì của nó.

– Thay thế hệ thống bằng một hệ thống mới

3.2.1 Cải thiện phần mềm

• Việc lựa chọn chiến lược cải tiến hệ thống

phụ thuộc vào chất lượng hệ thống và giá trị nghiệp vụ của nó như sau:

– Chất lượng thấp và giá trị nghiệp vụ thấp : những

hệ thống này nên được tách ra.

– Chất lượng thấp và giá trị nghiệp vụ cao : những hệ thống này có giá trị nghiệp vụ cao nhưng chi phí bảo trì khá lớn Ta nên tái kỹ nghệ hoặc thay thế bởi một hệ thống thích hợp

– Chất lượng cao và giá trị nghiệp vụ thấp : thay thế bằng các thành phần code

– Chất lượng cao và giá trị nghiệp vụ cao : tiếp tục sử dụng và bảo trì hệ thống theo cách thông thường.

3.2.1 Cải thiện phần mềm

• Việc đánh giá giá trị nghiệp vụ được thực hiện

từ nhiều khung nhìn khác nhau Phỏng vấn các stakeholder khác nhau và đối sánh kết quả thu được Các stakeholder thường là:

– Người sử dụng cuối

– Khách hàng của doanh nghiệp

– Người quản lý dây chuyền sản xuất

– Người quản lý công nghệ thông tin

– Người quản lý cao cấp

3.2.1 Cải thiện phần mềm

• Đánh giá chất lượng hệ thống thông qua:

– Quy trình nghiệp vụ: quy trình nghiệp vụ

đã hỗ trợ cho các mục tiêu nghiệp vụ như thế nào?

– Môi trường hệ thống: môi trường hệ thống

có hiệu quả như thế nào và chi phí để bảo trì nó.

– Khả năng ứng dụng: chất lượng của ứng dụng?

3.2.1 Cải thiện phần mềm

3.2 2 Mô hình tiến trình bảo trì

• Mô hình tiến trình bảo trì theo IEEE

Phân loại và nhận dạng

Phân tích ảnh hưởng

Cài đặt Thiết kế

Kiểm thử

Hệ thống

Kiểm thử Chấp thuận

Phát hành Yêu cầu

sửa đổi

• Các hoạt động của tiến trình bảo trì theo ISO/IEC

– tương tự như IEEE,

– Chúng được kết hợp theo trình tự như sau:

3.2.2 Mô hình tiến trình bảo trì

Cài đặt

tiến trình

Bảo trì chấp thuận Phân tích vấn

đề sửa đổi

Cài đặt sửa đổi

• Thực hiện phân tích ban đầu

– Xác minh vấn đề cần sửa đổi

• Phát triển các giải pháp cho việc cài đặt

sửa đổi

• Tư liệu hóa các giải pháp

• Lựa chọn giải pháp sửa đổi được khách

hàng chấp thuận

Phân tích vấn đề sửa đổi

• Phát triển các kế hoạch bảo trì

• Thiết lập các thủ tục cho việc sửa đổi

Bảo trì chấp thuận

• Kiểm tra lại với dữ liệu người dùng

• Đảm bảo hệ thống người dùng

chấp thuận

• Đảm bảo rằng sự chuyển dịch là phù

hợp với chuẩn

• Phát triển một kế hoạch chuyển dịch

• Thông báo cho người dùng về các kế

hoạch chuyển dịch

• Đảm bảo dữ liệu cũ có thể truy cập

Chuyển dịch

• Phát triển một kế hoạch nghỉ hưu,

• Thông báo cho người dùng về các kế

hoạch nghỉ hưu

• Đảm bảo rằng dữ liệu cũ có thể truy

cập

Nghỉ hưu

3.2.3 Các hoạt động bảo trì

• Tương tự như các hoạt động phát triển

p/mềm

– Phân tích, thiết kế, mã hóa, kiểm thử và tư

liệu hóa (theo mô hình tiến trình trên)

Hiểu mã nguồn

Tác dụng của việc hiểu mã nguồn:

– Phân tích ảnh hưởng: xác định mọi hệ thống, thành phần hệ thống bị ảnh hưởng bởi một y/cầu thay đổi

– Ước lượng các tài nguyên cần thiết để hoàn thành việc thay đổi

– Xác định các rủi ro được tạo bởi sự thay đổi

– Hiệu ứng lề của việc thay đổi

– Tiến trình bảo trì là không đủ nếu chỉ

• lưu vết các sửa đổi yêu cầu và các báo cáo vấn đề

– Sản phẩm p/m và bất kỳ thay đổi nào của

nó đều phải được quản lý bởi tiến trình quản lý cấu hình p/m (SCM)

• nhằm xác định các cấu hình của hệ thống tại các điểm riêng lẻ

• điều khiển các thay đổi cho cấu hình

Quản lý cấu hình

• Cần lập kế hoạch bảo trì

• Lựa chọn kỹ thuật hỗ trợ các hoạt động

– đảm bảo chất lượng p/m (SQA) và

– V&V hệ thống sau tiến trình bảo trì

Đảm bảo chất lượng hệ thống

• Là hoạt động quan trọng của tiến trình

bảo trì

• Ước lượng chính xác các tài nguyên :

– Thời gian bảo trì – Chi phí

– Phạm vi bảo trì – Các biến đổi của tiến trình sau phát hành – Những hỗ trợ cho bảo trì

Lập kế hoạch bảo trì [IEEE

1219], [ISO/IEC 14764]

3.2.4 Tiến trình bảo trì khẩn cấp

Hiểu phần mềm đã có

• Theo tài liệu nắm chắc các chức năng

• Theo tài liệu chi tiết nắm vững đặc tả

chi tiết, điều kiện kiểm thử,

• Dò đọc chương trình nguồn, hiểu trình

tự xử lý chi tiết của hệ thống

=> 3 việc trên đều là công việc thực thi trên bàn

Tu sửa phần mềm đã có

• Bảo trì chương trình nguồn, tạo các

môđun mới và dịch lại

• Thực hiện kiểm thử unit và tu chỉnh

những mục liên quan có trong tư liệu đặc tả

• Chú ý theo sát tác động của môđun

được sửa đến các thành phần khác trong hệ thống

Phát triển phần mềm mới

• Khi có y.c thêm chức năng mới

– phải phát triển chương trình cho phù hợp

với yêu cầu

• Cần tiến hành từ thiết kế, lập trình, gỡ

lỗi và kiểm thử unit (như trong mô hình bảo trì p.m)

• Phản ảnh vào giao diện của phần mềm

( thông báo, phiên bản, )

• Dùng các dữ liệu trước đây khi kiểm

thử để kiểm thử lại tính nhất quán

• Chú ý hiệu ứng lề trong chỉnh sửa

Kiểm thử sau bảo trì

• Kiểm tra nội dung thay đổi có trong tư

liệu đặc tả ko

• Cách ghi tư liệu có phù hợp với mô tả

môi trường phần mềm mới hay không ?

Lập biểu quản lý bảo trì

Ví dụ về tiến trình bảo trì :

• Người sử dụng tìm ra một vấn đề và báo cáo

với nhân viên hỗ trợ

• Nhân viên hỗ trợ mô tả chi tiết vấn đề và gửi

đến nhóm đánh giá

• Nhóm đánh giá phân tích và xác định vấn đề

– Liệu vấn đề đã được biết chưa

– Liệu người sử dụng có đang sử dụng phần mềm

một cách đúng đắn

– Vấn đề nghiêm trọng như thế nào,

• Người quản lý giao cho lập trình viên giải

quyết vấn đề dựa trên việc đánh giá mức độ

ưu tiên

• Lập trình viên bảo trì giải quyết vấn đề:

– Khôi phục lại các tài liệu, mã nguồn và các thiết bị

liên quan khác từ bản phát hành trước

– Vạch ra các khiếm khuyết và cố định nó

– Kiểm tra các thay đổi

– Cập nhật tất cả các tài liệu có liên quan, mô hình

hệ thống, mã nguồn, cấu trúc dữ liệu,

– Tích hợp các thay đổi vào bản phát hành tiếp theo

• Người sử dụng nhận phiên bản phần mềm

đã được cập nhật hoặc các gói dịch vụ,

Ví dụ về tiến trình bảo trì:

3.3 Một số hiệu ứng lề của bảo trì

• Sửa đổi phần mềm là công việc nguy

hiểm, ta thường gặp 3 loại hiệu ứng lề chính như sau:

– Hiệu ứng lề của việc thay đổi mã nguồn

– Hiệu ứng lề của việc thay đổi dữ liệu

– Hiệu ứng lề của việc thay đổi tài liệu

Hiệu ứng lề của việc thay đổi mã

nguồn

• Một thay đổi đơn giản tới một câu lệnh đơn

cũng có thể đem lại một hậu quả thảm khốc.

• Mặc dù không phải các ảnh hưởng đều là

tiêu cực, nhưng việc sửa lỗi luôn dẫn đến các vấn đề phức tạp.

• Mặc dù tất cả các thay đổi mã lệnh chương

trình đều có thể tạo ra lỗi, nhưng tập hợp các thay đổi sau có thể gây ra nhiều lỗi hơn:

• Tập hợp các thay đổi gây ra nhiều lỗi:

– Một chương trình con bị xóa hay thay đổi.

– Một dòng nhãn bị xóa hay thay đổi.

– Một biến bị xóa hay thay đổi.

– Các thay đổi để tăng khả năng thực hiện.

– Việc mở và đóng file bị thay đổi.

– Các phép toán logic bị thay đổi.

– Việc thay đổi thiết kế chuyển thành các thay đổi

lớn về chương trình

– Các thay đổi ảnh hưởng đến việc chạy thử các

trường hợp biên.

Hiệu ứng lề của việc thay đổi dữ liệu

• Trong quy trình bảo trì,

– việc sửa đổi thường được tiến hành đối

với các phần tử riêng rẽ của cấu trúc dữ liệu.

– Khi dữ liệu thay đổi, việc thiết kế phần

mềm sẽ không còn phù hợp với dữ liệu và lỗi có khả năng xảy ra.

• Hiệu ứng lề của dữ liệu xảy ra như là kết quả của việc thay đổi cấu trúc dữ liệu.

– Định nghĩa lại các hằng số cục bộ.

– Định nghĩa lại cấu trúc bản ghi/cấu trúc file – Tăng hoặc giảm kích thước một mảng.

– Thay đổi dữ liệu tổng thể.

– Định nghĩa lại các cờ điều khiển và các con

Hiệu ứng lề của việc thay đổi tài liệu

• Việc bảo trì không chỉ tập trung riêng vào

việc sửa đổi mã.

• Sự ảnh hưởng của tài liệu xảy ra khi

– thay đổi chương trình nguồn mà không thay đổi tài liệu thiết kế và tài liệu hướng dẫn sử dụng.

=> Bất cứ lúc nào có thay đổi về:

• Luồng dữ liệu,

• cấu trúc phần mềm,

• các thủ tục hay bất cứ cái gì có liên quan,

 tài liệu kỹ thuật phải được cập nhật.

• Tài liệu thiết kế phản ánh không đúng trạng

thái hiện tại của phần mềm có lẽ còn tồi tệ hơn không có tài liệu.

• Hiệu ứng lề xảy ra trong các lần bảo trì sau đó

• Đối với người sử dụng, phần mềm tốt chỉ khi có

tài liệu hướng dẫn sử dụng chúng một cách chính xác.

• Thực tế một vài yêu cầu bảo hành có thể đòi

hỏi:

• không được thay đổi thiết kế của phần mềm hoặc

• Không thay đổi mã chương trình ,

• mà chỉ cần chỉ ra sự thiếu rõ ràng trong tài liệu

3.4 Những vấn đề về bảo trì

hiện nay

• Sáng kiến trong quy trình phát triển p/mềm

• Sáng kiến trong quy trình bảo trì phần mềm

• Phát triển những kỹ thuật mới cho bảo trì

Sáng kiến trong quy trình phát triển

phần mềm

(1) Chuẩn hóa mọi khâu trong phát triển

phần mềm (2) Người bảo trì chủ chốt tham gia vào

giai đoạn phân tích và thiết kế (3) Thiết kế để dễ bảo trì

Sáng kiến trong quy trình bảo trì

phần mềm

(1) Sử dụng các công cụ hỗ trợ phát triển phần mềm

(2) Chuẩn hóa thao tác bảo trì và các công

cụ của môi trường bảo trì

(3) Lưu lại những thông tin lịch sử bảo trì (4) Dự án nên cử một người chủ chốt làm công việc bảo trì sau khi dự án kết thúc giai đoạn phát triển

Phát triển những kỹ thuật mới

cho bảo trì

• Công cụ phần mềm hỗ trợ bảo trì

• Cơ sở dữ liệu cho bảo trì

• Quản lý tài liệu, quản lý dữ liệu, quản lý

chương trình nguồn, quản lý dữ liệu thử, quản lý tiền sử bảo trì