Những cách mở rộng phần mềm

Thay đổi phần mềm ● Thay đổi phần mềm là điều không thể tránh khỏi • Các yêu cầu mới xuất hiện khi phần mềm vẫn đang được sử dụng; • Môi trường nghiệp vụ thay đổi; • Các sai sót pahỉ đư

Những cách Mở rộng phần mềm

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 2

Mục tiêu

● Giải thích tại sao việc thay đổi là không thể tránh

khỏi khi mà phần mềm vẫn còn hữu ích

● Thảo luận về việc bảo trì phần mềm và các chỉ số về

Thay đổi phần mềm

● Thay đổi phần mềm là điều không thể tránh khỏi

• Các yêu cầu mới xuất hiện khi phần mềm vẫn đang

được sử dụng;

• Môi trường nghiệp vụ thay đổi;

• Các sai sót pahỉ được sửa chữa;

• Các máy tính và thiết bị mới được thêm vào hệ thống;

• Hiệu năng hoặc độ tin cậy của hệ thống có thể phải

được nâng lên.

● Vấn đề cơ bản đối với tổ chức là thực hiện và quản

lý việc thay đổi đối với các hệ thống phần mềm đang tồn tại

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 4

Tầm quan trọng của sự mở rộng

● Các tổ chức có những đầu tư khổng lồ cho các hệ

thống phần mềm của họ - chúng là những tài sản thương mại quan trọng

● Để bảo toàn giá trị của những tài sản này, chúng

cần phải được thay đổi và cập nhật

● Một phần rất lớn trong ngân sách phần mềm của

các công ty lớn được giành để nâng cấp các phần mềm hiện có chứ không phải để phát triển các phần mềm mới

Mô hình mở rộng xoắn ốc

Specifi cation Im plem ention

Validation Operation

Start Release 1

Release 2 Release 3

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 6

● Cần phải tiến hành các nghiên cứu về các qui trình

thay đổi hệ thống

● Lehman và Belady đã đề nghị một số “luật” cần phải

áp dụng cho tất cả các hệ thống khi cần phải thay đổi

● Ngoài ra cần phải có những quan sát nhạy cảm chứ

không chỉ dựa vào “luật” Những quan sát này thường thích hợp với các hệ thống lớn được phát triển bởi các tổ chức lớn

Cách thức mở rộng chương trình

Các luật của Lehman

Law Description

Continuing change A program that is used in a real-world environment necessarily

must change or become progressively less useful in that environment

Increasing complexity As an evolving program changes, its structure tends to become

more complex Extra resources must be devoted to preserving and simplifying the structure

Large program evolution Program evolution is a self-regulating process System

attributes such as size, time between releases and the number of reported errors is approximately invariant for each system release

Organisational stability Over a program’s lifetime, its rate of development is

approximately constant and independent of the resources devoted to system development

Conservation of

familiarity

Over the lifetime of a system, the incremental change in each release is approximately constant

Continuing growth The functionality offered by systems has to continually increase

to maintain user satisfaction

Declining quality The quality of systems will appear to be declining unless they

are adapted to changes in their operational environment

Feedback system Evolution processes incorporate multi-agent, multi-loop

feedback systems and you have to treat them as feedback systems to achieve significant product improvement

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 8

● Sửa lại một chương trình sau khi đã được đưa vào

sử dụng

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

đổi chính đối với kiến trúc của hệ thống

● Những thay đổi được thực hiện bằng việc sửa đổi

các thành phần hiện có và thêm những thành phần mới vào hệ thống

Bảo trì phần mềm

● Các yêu cầu hệ thống rất có khả năng sẽ thay đổi

trong khi hệ thống đang được phát triển bởi vì môi trường luôn nuôn biến động Do đó những hệ thống

đã được chuyển giao có thể sẽ không đáp ứng được các yêu cầu của người sử dụng

● Các hệ thống thường gắn kết với môi trường của

chúng Khi một hệ thống được cài đặt trong một môi trường nó sẽ thay đổi môi trường này và do vậy sẽ làm thay đổi các yêu cầu hệ thống

● Do đó, các hệ thống PHẢI được bảo trì nếu chúng

vẫn muốn còn có ích trong môi trường của nó

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

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 10

● Bảo trì sửa chữa các lối của phần mềm

• Sửa lỗi trong phần mềm để đáp ứng yêu cầu của hệ thống

● Bảo trì làm thích nghi một phần mềm trong một môi

trường vận hành khác

• Thay đổi một hệ thống sao cho nó có thể hoạt động trong

một môi trường khác với môi trường ban đầu.

● Bảo trì thêm hoặc sửa chức năng của hệ thống

• Sửa lại hệ thống để thoả mãn các yêu cầu mới.

Các kiểu bảo trì

Phân bổ các nỗ lực bảo trì

Functionality addition or

m odification (65%)

Fault repair (17%)

Software adaptation (18%)

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 12

● Thường lớn hơn chi phí phát triển (từ 2 lần đến 100

lần tuỳ thuộc vào ứng dụng)

● Bị ảnh hưởng bởi các yếu tố kỹ thuật và cả các yếu

tố phi kỹ thuật

● Chi phí càng tăng lên khi phải bảo trì lâu dài Bảo trì

sẽ làm thay đổi cấu trúc phần mềm vì vậy các bảo trì sau đó sẽ càng ngày càng khó hơn

● Những phần mềm dùng lâu năm có thể đòi hỏi chi

phí bảo hành cao hơn

Các chi phí cho bảo trì

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 14

● Tính ổn định của đội bảo trì

• Chi phí bảo trì sẽ giảm bớt nếu duy trì ổn định một đội bảo trì

trong một thời gian dài.

● Các trách nhiệm trong hợp đồng

• Người phát triển một hệ thống có thể không có trách nhiệm

bảo trì qui định trong hợp đồng vì vậy họ không có động cơ

để thiết kế hệ thống sao cho có thể dễ dàng thay đổi sau này.

● Kỹ năng của nhân viên bảo trì

• Nhân viên bảo trì thường thiếu kinh nghiệm và có kiến thức

hạn chế trong lĩnh vực nghiệp vụ của ứng dụng.

● Tuổi và cấu trúc của chương trình

• Khi các chương trình đã cũ, cấu trúc của chúng sẽ bị suy

giảm và chúng trở nên khó hiểu và khó thay đổi.

Các nhân tô ảnh hưởng đến chi phí bảo trì

Dự đoán trước về bảo trì

● Dự đoán cho bảo trì liên quan đến việc đánh

giá những bộ phận của hệ thống có thể gây ra vấn đề và có chi phí bảo trì cao

• Việc chấp nhận thay đổi tuỳ thuộc vào khả năng có thể

bảo trì được của những thành phần bị ảnh hưởng bởi

sự thay đổi này;

• Việc thực hiện các thay đổi sẽ làm cho hệ thống bị suy

biến và giảm sút 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í của các thay đổi phụ thuộc vào khả năng bảo trì.

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 16

Dự đoán bảo trì

Predicting maintainability

Predicting system changes

Predicting maintenance costs

What will be the lifetime maintenance costs of this

system?

What will be the costs of maintaining this system over the next year?

What par ts of the system will be the most expensive

to maintain?

How many change

requests can be

expected?

What par ts of the system are

most likely to be affected by

change requests?

Qui trình mở rộng hệ thống

Release planning

Change implementa tion

System release

Impact analysis

Change

requests

Platform adaptation

System enhancement Fault repair

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 18

Sửa chữa khẩn cấp

Modify source code

Deliver modified system

Analyse source code Change

requests

Tái cơ cấu hệ thống

● Tái cấu trúc hoặc viết lại một phần hoặc tất cả một

hệ thống cũ mà không làm thay đổi chức năng của nó

● Thích hợp khi một số chứ không phải tất cả các hệ

thống con của một hệ thống lớn đòi hỏi bảo trì thường xuyên

● Tái cơ cấu qui trình bao gồm những nỗ lực nhằm

làm cho hệ thống dễ bảo trì hơn Hệ thống có thể phải cấu trúc lại và viết lại tài liệu mô tả

Bùi Th H ng Ch ng 12 M r ng ph n m m Trang 20

Ưu điểm của tái cơ cấu qui trình

● Giảm bớt rủi ro

• Khi phát triển một phần mềm mới thường có

những rủi ro cao Có thể có những vân đề về phát triển, những vấn đề về đội ngũ thực hiện

và những vấn đề về đặc tả

● Giảm bớt chi phí

• Chi phí cho tái cơ cấu qui trình thường ít hơn

rất nhiều so với chi phí phân tích một phần mềm mới

Qui trình tái cơ cấu

Reverse

en gin eering

Program docu m en tation

Data re-en gin eerin g

Original data

Prog ram structu re

im provem en t

Program

m odu larisation

Structu red program

Re-en gineered data

M odu larised program

Origin al

program

Sou rce code

tran slation

• Phá bỏ hoàn toàn và sửa lại những qui trình nghiệp vụ

đến nay không còn thích hợp nữa;

• Tiếp tục duy trì hệ thống;

• Chuyển đổi hệ thống bằng cách tái cơ cấu qui trình để

nâng cao khả năng bảo trì của nó;

• Thay thế ht bằng một hệ thống mới.

● Chiến lược được lựa chọn phụ thuộc vào chất

lượng của hệ thống và giá trị thương mại của nó

Phân loại các hệ thống cũ

● Chất lượng thấp, giá trị thương mại thấp

• Những hệ thống này nên phá bỏ toàn bộ

● Chất lượng thấp, giá trị thương mại cao

• Những hệ thống này có đóng góp quan trọng về thương

mại nhưng bảo trì lại tốn kém Nên tái cơ cấu lại qui trình hoặc thay thế nếu sẵn có một hệ thống thích hợp.

● Chất lượng cao, giá trị thương mại thấp

• Tuỳ thuộc vào chi phí mà có thể đạp bỏ hoặc vẫn sử

dụng.

● Chất lượng cao, giá trị thương mại cao

• Tiếp tục hoạt động với các bảo trì thông thường.