1. Trang chủ
  2. » Công Nghệ Thông Tin

BẢO TRÌ PHẦN MỀM

39 606 8
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Bảo trì phần mềm
Tác giả GV Phi Loan
Trường học Học Viện Công Nghệ Bưu Chính Viễn Thông
Chuyên ngành Công Nghệ Thông Tin
Thể loại bài giảng
Định dạng
Số trang 39
Dung lượng 581,56 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

• Do thay đổi là điều không thể tránh được  cần phải có cơ chế để đánh giá, kiểm soát và tạo các chỉnh sửa cho phần mềm.. Software maintenance • Thực tế cho thấy: – 2/3 chi phí phần m

Trang 3

• Bảo trì phần mềm là một hoạt động bao quát bao 

gồm nhiều hoạt động như sửa lỗi (error correction),  cải tiến (enhancements of capabilities), và tối ưu hóa  (optimization) phần mềm.

• Do thay đổi là điều không thể tránh được  cần phải 

có cơ chế để đánh giá, kiểm soát và tạo các chỉnh sửa  cho phần mềm. 

• Tất cả các công việc làm thay đổi phần mềm sau khi 

Trang 5

Software maintenance 

• Thực tế cho thấy: 

– 2/3 chi phí phần mềm (cost) là dành cho bảo trì

– Thời gian bảo trì có thể kéo dài 20 năm 

trong khi thời gian phát triển có thể chỉ 1‐2 năm 

Trang 6

• To preserve the value of software over time. 

• Bao gồm:

– Mở rộng và đáp ứng yêu cầu ngày càng tăng của  khách hàng

– Làm cho phần mềm dễ sử dụng hơn, hiệu quả hơn – Có thể ứng dụng công nghệ mới hơn

Trang 10

• Cách khắc phục:

– Khôi phục lại các thao tác của phần mềm– Dùng các miếng vá khẩn cấp (patching)

Trang 11

– A change to one part of a program may affect other sections in an unpredictable manner, 

thereby leading to distortion in the logic of the system

• Nguyên nhân của ripple effect?

– Thiếu thời gian để thực hiện một “impact analysis” đầy đủ trước khi áp dụng thay đổi

Trang 13

(Hoàn chỉnh mở rộng)

• Làm cho hệ thống tốt hơn, nhanh hơn, nhỏ 

hơn, tài liệu đầy đủ hơn, nhiều chức năng và báo cáo hơn…

Trang 14

(Phòng tránh)

• Phát hiện sớm và sửa sai các khuyết điểm vừa mới phát hiện trước khi chúng trở thành các khuyết điểm chính

• Tối ưu hóa mã chương trình để chạy nhanh 

hơn, bộ nhớ được sử dụng hiệu quả hơn

• Cập nhật tài liệu của phần mềm  

Trang 15

Distribution of maintenance effort

Adaptive, 25%

Trang 16

Tối ưu hóa

Độ phức tạp Tài liệu Đặc tính tự mô tả

Sự ổn định

Khả năng kiểm thử Khả năng mở rộng

Trang 17

• Thường rất lớn, chiếm khoảng 40‐70% chi phí của cả chu kỳ phát triển SDLC

• Để giảm chi phí bảo trì, nên đầu tư nhiều vào giai đoạn đầu của SDLC

Trang 21

Reuse Oriented Model

• Bốn bước chính:

– Nhận biết các phần của hệ thống cũ là ứng viên cho tái sử dụng

– Tìm hiểu các thành phần này 

– Chỉnh sửa các thành phần của hệ thống cũ cho phù hợp với các yêu cầu mới

– Tích hợp các thành phần đã chỉnh sửa vào 

Trang 22

Reuse Oriented Model

Components library

Source Code Test Data

Trang 23

• Theo nguyên tắc tiết kiệm chi phí (economical model)

• Mô hình tiết kiệm là không thêm cái mới, và không chỉ cải thiện tính hiệu quả trong bảo trì nhưng còn giúp hiểu rõ hơn quy trình xử lý

Trang 25

• Chi phí bảo hành thường rất lớn, khoảng 40 – 70%  chi phí của các SDLC.

Trang 26

• Boehm đã đưa ra công thức ước tính chi phi bảo trì cho mô  hình COCOMO

• Annual Change Traffic (ACT) là  thừa số chỉ mã nguồn bị thay  đổi (có thể thêm vào, xóa đi hay sửa đổi) trong một năm. ACT 

có liên quan đến số yêu cầu thay đổi

• Annual Maintenance Effort (AME) được tính như sau:

AME= ACT x SDE Với SDE là chi phí phát triển phần mềm (Software development 

Trang 27

ACT cho một hệ thống phần mềm là 15% mỗi  năm. Chi phí phát triển SDE là 600 PM. Ước  tính chi phí bảo trì hàng năm AME nếu thời  gian hoạt động (life time) của dự án là 10 

năm. Tổng chi phí của dự án là bao nhiêu?

Solution:

Chi phí bảo trì là AME = ACT x SDE = 0.15 x 600 

= 90 PM

Trang 28

(Regression testing)

• Kiểm thử trong khi xây dựng (Development testing )

– được dùng để đảm bảo tính đúng đắn của phần  mềm. 

– Thương phải xây dựng kế hoạch kiểm thử

• Khi phần mềm được sửa đổi, thì cần phải kiểm thử  lại hay kiểm thử hồi quy.

• Regression testing is the process of retesting the 

modified parts of the software and ensuring that no  new errors have been introduced into previously 

tested code

Trang 29

• Làm tăng độ tin cậy của chương trình sau khi chỉnh sửa

• Tìm các lỗi do sửa đổi chương trình gây ra

• Bảo đảm chất lượng chương trình

• Bảo đảm chương trình vẫn tiếp tục vận hành sau khi chỉnh sửa

Trang 30

phần phần mềm

Chỉ kiểm thử lại các thành phần bị ảnh hưởng do chỉnh sửa

Dự kiến thời gian kiểm thử Không dự kiến trước thời gian

Trang 31

VàReverse engineering (RE)

?

Trang 33

năng mới hay sửa lỗi cho hệ thống.

Trang 34

reegineering bao gồm 6 hoạt động chính 

Trang 35

Reengineering

Trang 36

Reverse engineering (RE) is the process of 

discovering the technological principles of a 

device, object or system through analysis of its structure, function and operation. 

• Là quá trình phân tích chương trình để cố 

gắng biểu diễn chương trình ở mức trừu 

tượng cao hơn mã nguồn. 

• Được xem là quá trình phục hồi lại thiết kế ( 

Trang 37

• Xuất phát từ thế giới phần cứng, thuật ngữ 

này dùng để chỉ  việc tháo rời sản phẩm phần cứng của đối thủ để tìm hiểu các bí mật về 

thiết kế và xây dựng

• Kỹ thuật dịch ngược này cũng tương tự cho 

phần mềm nhưng chương trình được dịch 

không phải của đối thủ cạnh tranh, và các bí mật cần tìm hiểu là những đặc tả rắc rối, 

Trang 39

Quy trình reverse engineering

Ngày đăng: 18/12/2013, 13:34

HÌNH ẢNH LIÊN QUAN

• Các   mô   hình   bảo   trì - BẢO TRÌ PHẦN MỀM
c   mô   hình   bảo   trì (Trang 2)
– Đối   với   mô   hình   waterfall   thì   - BẢO TRÌ PHẦN MỀM
i   với   mô   hình   waterfall   thì   (Trang 4)
Mô   hình   Quick‐fix - BẢO TRÌ PHẦN MỀM
h ình   Quick‐fix (Trang 19)
Mô   hình   Iterative   Enhancement - BẢO TRÌ PHẦN MỀM
h ình   Iterative   Enhancement (Trang 20)
Mô hình hướng tái sử dụng Reuse Oriented Model Components libraryOld systemRequirements analysisDesign Source Code New system Test Data Requirements analysisDesignSource Code Test Data - BẢO TRÌ PHẦN MỀM
h ình hướng tái sử dụng Reuse Oriented Model Components libraryOld systemRequirements analysisDesign Source Code New system Test Data Requirements analysisDesignSource Code Test Data (Trang 22)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w