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

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 1


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ề
chi phí bảo trì.
Mô tả các qui trình liên quan đến việc mở rộng phần
mềm.
Bàn về một cách tiếp cận dùng để đánh giá các
chiến lược thay đổi các phần mềm thuộc loại di sản.

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 2


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 3


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.

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 4


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

Specifi cat ion

Im plem en t ion

St art
Release 1
Operat ion

Validation

Release 2
Release 3

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 5

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

●

●

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.

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 6


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 7


Bảo trì phần mềm
●

●

●

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ùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 8


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

●

●

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ùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 9


Các kiểu bảo trì
●

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

●

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
•

●

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

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
•

Bùi Th H ng

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

Ch

ng 12. M r ng ph n m m

Trang 10


Phân bổ các nỗ lực bảo trì
Fau lt repair
( 17%)

Soft ware
adapt at ion
( 18 %)

Bùi Th H ng

Ch

Fu n ct ion alit y
addit ion or
m odifi cat ion
( 65 %)

ng 12. M r ng ph n m m

Trang 11


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

●

●

●

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.

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 12


Các chi phí phát triển/bảo trì

Syst em 1
Syst em 2

0

50

100

Developm en t cost s

Bùi Th H ng

Ch

150

200

250

300

350 400

450

500

M ain t en an ce cost s

ng 12. M r ng ph n m m

Trang 13

$


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

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

●

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ì
•

●

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.

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
•

Bùi Th H ng

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.

Ch

ng 12. M r ng ph n m m

Trang 14


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
•

•
•

Bùi Th H ng

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ì.

Ch

ng 12. M r ng ph n m m

Trang 15


Dự đoán bảo trì
What par
ts of the system are
most likely to be affected by
change requests?

What par
ts of the system
will be the most expensive
to maintain?
Predicting
maintainability

Predicting system Predicting
maintenance
changes
costs

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

How many change
requests can be
expected?

Bùi Th H ng

Ch

What will be the lifetime
maintenance costs of this
system?

ng 12. M r ng ph n m m

Trang 16


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

Change
requests

Bùi Th H ng

Impact
analysis

Release
planning

Fault repair

Platform
adaptation

Ch

ng 12. M r ng ph n m m

Change
implementa
tion

System
release

System
enhancement

Trang 17


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

Change
requests

Bùi Th H ng

Analyse
source code

Ch

Modify
source code

ng 12. M r ng ph n m m

Deliver modified
system

Trang 18


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 19


Ư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.

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 20

Qui trình tái cơ cấu
Program
docu m en t at i on

Origin al
program

M odu lari sed
program

Origin al dat a

Reverse
en gin eeri n g
Program
m odu larisat ion

Sou rce code
t ran sl at ion

Dat a
re-en gin eerin g

Prog ram
st ru ct u re
im provem en t
St ru ct u red
program

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Re-en gi n eered
dat a

Trang 21


Cải tiến hệ thống cũ
●

Những tổ chức đang sở hữu các hệ thống cũ cần
phải lựa chọn một chiến lược cải tiến các hệ thống
này
•
•
•
•

●

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ó.

Bùi Th H ng

Ch

ng 12. M r ng ph n m m

Trang 22


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

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

●

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
•

●

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

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
•

Bùi Th H ng

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

Ch

ng 12. M r ng ph n m m

Trang 23