Ôn tập công nghệ phần mềm chương 10

Page 1 of 20

PHẦN MỀM TIẾN HÓA
Các chủ đề :
-

quá trình tiến hóa
o Thay đổi quy trình cho các hệ thống phần mềm
Động lực phát triển chương trình
o Sự hiểu biết về tiến hóa phần mềm
bảo trì phần mềm
o Làm thay đổi hệ thống phần mềm hoạt động
Quản lý hệ thống di sản
o Quyết định về thay đổi phần mềm

Tóm tắt:
-

Phát triển phần mềm và tiến hóa có thể được nhóm lại là một, q trình lặp đi lặp lại có thể
biểu diễn sử dụng một mơ hình xoắn ốc.
Đối với hệ thống tùy chỉnh, chi phí bảo trì phần mềm thường vượt q chi phí phát triển
phần mềm.
Q trình tiến hóa phần mềm được điều khiển bởi các yêu cầu thay đổi và bao gồm phân
tích tác động thay đổi, phát hành lập kế hoạch và thực hiện thay đổi.
Định luật Lehman, có quan điểm cho rằng sự thay đổi là liên tục, mô tả một số những hiểu
biết bắt nguồn từ nghiên cứu lâu dài của quá trình phát triển hệ thống.
Có 3 loại bảo trì phần mềm, cụ thể là: lỗi sửa chữa, thay đổi phần mềm để làm việc trong
một môi trường mới, thực hiện các yêu cầu mới hoặc thay đổi.
Phần mềm tái kỹ thuật liên quan đến tái cơ cấu và tái lập tài liệu phần mềm để làm cho nó
dễ dàng hơn để hiểu và thay đổi.
Tái cấu trúc, làm cho chương trình thay đổi vẫn bảo đảm chức năng, là một hình thức bảo

trì.
Giá trị kinh doanh của một hệ thống di sản và chất lượng các ứng dụng cần được đánh giá
để giúp quyết định nếu một hệ thống nên được thay thế, chuyển đổi, duy trì.

Mục lục:
Thay đổi phần mềm…………………………………………………………………………………………………………3
Tầm quan trọng của sự phát triển……………………………………………………………………………………..3
Một mơ hình xoắn ốc phát triển và tiến hóa……………………………………………………………………….3
Sự tiến hóa và bảo trì……………………………………………………………………………………………………….4
Q trình tiến hóa…………………………………………………………………………………………………………….5
Thay đổi nhận dạng và tiến hóa quy trình…………………………………………………………………………..5
Q trình tiến hóa phần mềm…………………………………………………………………………………………….5
Thay đổi thực hiện……………………………………………………………………………………………………………6
u cầu thay đổi khẩn cấp………………………………………………………………………………………………..6


Page 2 of 20
Quá trình sửa chữa khẩn cấp…………………………………………………………………………………………..6
Vấn đề bàn giao……………………………………………………………………………………………………………..7
Động lực phát triển chương trình……………………………………………………………………………………..7
Thay đổi là khơng thể tránh khỏi………………………………………………………………………………………7
Định luật Lehman……………………………………………………………………………………………………………7
Áp dụng định luật Lehman……………………………………………………………………………………………….8
Bảo trì phần mềm…………………………………………………………………………………………………………..8
Loại bảo trì……………………………………………………………………………………………………………………9
Hình 9.8 Bảo trì phân phối nỗ lực……………………………………………………………………………………9
Chi phí bảo trì………………………………………………………………………………………………………………..9
Hình 9.9 và Phát triển chi phí bảo trì………………………………………………………………………………10
Các yếu tố chi phí bảo trì………………………………………………………………………………………………10
Dự đốn bảo trì……………………………………………………………………………………………………………10

Thay đổi dự đốn…………………………………………………………………………………………………………11
Số liệu phức tạp……………………………………………………………………………………………………………11
Số liệu q trình……………………………………………………………………………………………………………11
Ví dụ về bảo trì Yêu cầu & TÁC ĐỘNG ALANYSIS………………………………………………………………12
Tác động của MR # 162…………………………………………………………………………………………………12
Hệ thống lại kỹ thuật………………………………………………………………………………………………………12
Ưu điểm của tái cấu trúc…………………………………………………………………………………………………12
Quá trình tái cấu trúc………………………………………………………………………………………………………13
Hoạt động quá trình tái cấu trúc………………………………………………………………………………………13
Hình 9.12 Tái cấu trúc phương pháp tiếp cận……………………………………………………………………13
Yếu tố chi phí tái cấu trúc………………………………………………………………………………………………14
Bảo trì bằng tái cấu trúc…………………………………………………………………………………………………14
Sắp xếp và tái cấu trúc……………………………………………………………………………………………………14
' Bad smells ' trong mã chương trình…………………………………………………………………………………14
Quản lý hệ thống di sản…………………………………………………………………………………………………15
Hình 9.13 Một ví dụ về một di sản đánh giá hệ thống………………………………………………………..15
Loại hệ thống di sản………………………………………………………………………………………………………16
Đánh giá giá trị kinh doanh……………………………………………………………………………………………16


Page 3 of 20
Các vấn đề trong đánh giá giá trị kinh doanh……………………………………………………………………16
Đánh giá chất lượng hệ thống…………………………………………………………………………………………17
Đánh giá quá trình kinh doanh…………………………………………………………………………………………17
Yếu tố được sử dụng trong đánh giá mơi trường………………………………………………………………17
Đo lường hệ thống…………………………………………………………………………………………………………19
Một bảo trì điển hình dịng chảy………………………………………………………………………………………19
Bảo trì & Patching…………………………………………………………………………………………………………..19
Patches bảo trì………………………………………………………………………………………………………………20

Thay đổi phần mềm
-

-

Thay đổi phần mềm là khơng thể tránh khỏi.
o Khi có u cầu mới xuất hiện khi phần mềm được sử dụng;
o Những thay đổi môi trường kinh doanh ;
o 1 số lỗi phát sinh cần được sửa chữa ;
o Máy tính và thiết bị mới được thêm vào hệ thống;
o Hiệu suất hoặc độ tin cậy của hệ thống có thể được cải thiện.
Một vấn đề quan trọng đối với tất cả các tổ chức đang thực hiện và quản lý thay đổi hệ
thống phần mềm hiện có của họ.

Tầm quan trọng của sự phát triển
-

Các tổ chức có đầu tư rất lớn trong hệ thống phần mềm của họ - đó là những tài sản kinh
doanh quan trọng.
Để duy trì giá trị của những tài sản cho doanh nghiệp, phần mềm phải được thay đổi và cập
nhật.
Phần lớn các ngân sách phần mềm trong các công ty lớn là dành cho thay đổi và phát triển
phần mềm hiện có hơn hơn phát triển phần mềm mới.

Một mơ hình xoắn ốc phát triển và tiến hóa


Page 4 of 20

Sự tiến hóa và bảo trì

-

-

-

Sự tiến hóa
o Giai đoạn trong vịng đời một hệ thống phần mềm ở trong hoạt động sử dụng và
được phát triểu theoyêu cầu mới được đề xuất và thực hiện trong hệ thống.
Bảo trì
o Ở giai đoạn này, phần mềm vẫn cịn hữu ích nhưng những thay đổi chỉ thực hiện
được những yêu cầu để giữ cho nó sửa lỗi, tức là hoạt động và thay đổi để phản ánh
những thay đổi trong mơi trường của phần mềm. Khơng có những chức năng mới
được thêm vào.
Giai đoại ra


Page 5 of 20
o

Phần mềm này có thể vẫn được sử dụng nhưng nó khơng được thực hiện thay đổi
nào.

Q trình tiến hóa
Q trình tiến hóa phần mềm phụ thuộc vào:
-

Các loại phần mềm được duy trì ;
Quá trình phát triển sử dụng;

Các kỹ năng và kinh nghiệm của những người liên quan.

Đề xuất thay đổi định hướng cho sự phát triển hệ thống.
-

Nên được liên kết với các thành phần bị ảnh hưởng bởi sự thay đổi, do đó các chi phí và tác
động của sự thay đổi phải được ước tính.

Thay đổi nhận dạng và phát triển tiếp tục trong suốt tuổi thọ của hệ thống.

Thay đổi nhận dạng và tiến hóa quy trình

Q trình tiến hóa phần mềm


Page 6 of 20

Thay đổi thực hiện

-

-

Lặp đi lặp lại của quá trình phát triển, nơi các phiên bản vào hệ thống được thiết kế, thực
hiện và thử nghiệm.
Một sự khác biệt quan trọng là giai đoạn đầu tiên của sự thay đổi thực hiện có thể liên quan
đến sự hiểu biết chương trình, đặc biệt là nếu các nhà phát triển hệ thống ban đầu không
chịu trách nhiệm về việc thực hiện thay đổi.
Trong giai đoạn hiểu biết chương trình, bạn phải hiểu làm thế nào chương trình có cấu trúc,
làm thế nào nó cung cấp chức năng và làm thế nào thay đổi được đề xuất có thể ảnh hưởng

đến chương trình.

Yêu cầu thay đổi khẩn cấp
-

Thay đổi khẩn cấp có thể được thực hiện mà khơng đi qua tất cả các giai đoạn của công
nghệ phần mềm quá trình.
o Nếu một lỗi hệ thống nghiêm trọng đã được sửa chữa để cho phép bình thường hoạt
động để tiếp tục;
o Nếu thay đổi môi trường của hệ thống (ví dụ như một bản nâng cấp hệ điều hành )
có hiệu ứng bất ngờ ;
o Nếu có sự thay đổi kinh doanh địi hỏi phải có một phản ứng rất nhanh (ví dụ việc
phát hành một sản phẩm cạnh tranh).

Quá trình sửa chữa khẩn cấp


Page 7 of 20

Vấn đề bàn giao
-

-

Trường hợp đội ngũphát triển đã sử dụng một cách tiếp cận nhanhnhưng nhóm nghiên cứu
q trình tiến hóa lại khơng quen với phương pháp nhanh nhẹn và thích một cách tiếp cận
dựa trên kế hoạch.
o Nhóm nghiên cứu tiến hóa có thể mong đợi tài liệu chi tiết để hỗ trợ phát triển và
điều này khơng được thiết kế trong q trình nhanh nhẹn.
Nơi một cách tiếp cận dựa trên kế hoạch đã được sử dụng phát triển nhưng nhóm nghiên

cứu q trình tiến hóa thích sử dụng phương phápnhanh.
o Nhóm nghiên cứu tiến hóa có thể phải bắt đầu từ đầu phát triển kiểm tra tự động và
mã trong hệ thống có thể khơng có được tái cấu trúc và đơn giản như dự kiến trong
phát triển nhanh.

Động lực phát triển chương trình
-Program evolution dynamics(Động lực phát triển chương trình): là nghiên cứu về các
quá trình thay đổi hệ thống.
- Sau khi một số nghiên cứu thực nghiệm lớn, Lehman và Belady đề xuất rằng có một số '
định luật ' được áp dụng cho tất cả các hệ thống như chúng đã tiến hóa.
- Có quan sát hợp lý c
được phát triển bởi những tổ chức lớn.

áp dụng cho các hệ thống lớn

Nó khơng rõ ràng nếu đây là áp dụng cho các loại phần mềm hệ thống.

Thay đổi là không thể tránh khỏi
-

Yêu cầu hệ thống có khả năng thay đổi trong khi hệ thống đang được phát triển bởi vì mơi
trường đang thay đổi. Do đó, một hệ thống cung cấp sẽ khơng đáp ứng u cầu của mình!
Hệ thống này được kết hợp chặt chẽ với môi trường của họ. Khi một hệ thống được cài đặt
trong một mơi trường nó thay đổi mơi trường và Do đó, thay đổi các yêu cầu hệ thống.
Hệ thống phải được thay đổi nếu nó vẫn cịn hữu ích trong một mơi trường.

Định luật Lehman
Định luật

Mơ tả

tiếp tụ

Một chương trình được sử dụng trong một môi trường thực tếnhất thiết


Page 8 of 20
phải thay đổi, nếu không dần dần sẽ trở nên ít hữu ích trong mơi trường
đó.
Tăng phức tạp

Khi tiến hố, độ phức tạp của phần mềm ln tăng, nếu khơng bỏ cơng
sức để làm giảm nó xuống.

chương trình
tiến hóa lớn

Phát triển chương trình là một q trình tự điều tiết. Hệ thống
các thuộc tính như kích thước, thời gian giữa các phiên bản, và
số lượng lỗi được báo cáo là khoảng bất biến cho mỗi hệ thống phát hành.

tổ chức ổn định

Độổn đị nh là chỉ số quan trọng trong hệ thống điều khiển. Để đảm bảo
độ tiến hoá ổn đị nh, nhân sự cần ổn đị nh qua thời gian.

bảo tồn quen thuộc

Qua cácphiên bản mới, thay đổi gia tăng trong mỗi bản phát hành là
khoảng không đổi.

tiếp tục tăng
trưởng

Các chức năng được cung cấp bởi hệ thống phải liên tục tăng để duy trì sự
hài lòng cho người sử dụng.

chất lượng giảm
sút

Chất lượng của hệ thống sẽ giảm trừ khi họ sửa đổi để phản ánh những
thay đổi trong hoạt động môi trường của họ.

hệ thống thơng tin
phản hồi

Q trình tiến hóa kết hợp nhiều ngun nhân, hệ thống thơng tin phản hồi
đa vịng và bạn phải xem nó là hệ thống điều khiển để cải thiện hệ thống.

Áp dụng định luật Lehman
-

-

Định luật Lehman dường như áp dụng cho các hệ thống lớn, hệ thống phù hợp được phát
triển bởi các tổ chức lớn.
o Xác nhận vào đầu năm 2000 bởi công việc của Lehman vào ngày lễ
dự án.
Nó khơng phải là rõ ràng làm thế nào họ nên được sửa đổi cho
o Thu nhỏ sản phẩm phần mềm ;

o Hệ thống kết hợp một số lượng đáng kể của COTS thành phần ;
o Các tổ chức nhỏ ;
o Hệ thống Kích thước trung bình.

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

Sửa đổi một chương trình sau khi nó đã được đưa vào sử dụng.
Thuật ngữ này được sử dụng chủ yếu cho việc thay đổi phần mềm tùy chỉnh.
Sản phẩm phần mềm chung chung được cho là phát triển để tạo ra phiên bản mới.
Bảo dưỡng không thường liên quan đến những thay đổi lớn về kiến trúc của hệ thống.
Thay đổi được thực hiện bằng cách thay đổi thành phần hiện tại và thêm các thành phần
mới vào hệ thống.

Loại bảo trì


Page 9 of 20
-

-

-

Bảo trì sửa chữa lỗi phần mềm
o Thay đổi một hệ thống để sửa chữa thiếu sót trong cách đáp ứng yêu cầu của khách
hàng.
Bảo trì để phần mềm thích nghi với mơi trường của nhiều hệ điều hành
o Thay đổi một hệ thống để nó hoạt động trong một mơi trường khác nhau (máy tính,
hệ điều hành, vv) từ thực hiện ban đầu của nó.

Bảo trì để thêm vào hoặc thay đổi chức năng của hệ thống
o Sửa đổi hệ thống để đáp ứng yêu cầu mới.

Hình 9.8 Bảo trì phân phối nỗ lực

Chi phí bảo trì
-

Thường lớn hơn chi phí phát triển (2 * đến 100 * tùy thuộc vào ứng dụng).
Bị ảnh hưởng bởi cả hai yếu tố kỹ thuật và phi kỹ thuật.


Page 10 of 20
-

Tăng lên khi phần mềm được duy trì.
Bảo trì cấu trúc phần mềm bị sửa đổi như vậy làm cho bảo trì thêm khó khăn hơn.
Phần mềm q cũ có thể có chi phí hỗ trợ cao (ví dụ ngơn ngữ lập trình cũ, trình biên dịch ,
vv.)

Hình 9.9 và Phát triển chi phí bảo trì

Các yếu tố chi phí bảo trì
-

-

-

nhóm ổn định

o Chi phí bảo trì được giảm nếu các nhân viên cùng tham gia với họ trong một thời
gian.
trách nhiệm theo hợp đồng
o Các nhà phát triển của một hệ thống có thể khơng có hợp đồng trách nhiệm bảo trì,
khơng có động cơ để thiết kế cho sự thay đổi trong tương lai.
kỹ năng nhân viên
o Nhân viên bảo trì thường thiếu kinh nghiệm và có giới hạn kiến thức tên miền.
Tuổi tác và cấu trúc chương trình
o Như các chương trình có tuổi, cấu trúc của chúng là suy thối và nó trở thành khó
hiểu và khó thay đổi.

Dự đốn bảo trì
-

Dự báo bảo trì là quan tâm đến đánh giá phần nào của hệ thống có thể gây ra vấn đề và có
chi phí bảo dưỡng cao
o Thay đổi chấp nhận phụ thuộc vào khả năng bảo trì của thành phần bị ảnh hưởng
bởi sự thay đổi ;
o Thực hiện thay đổi làm giảm hệ thống và làm giảm quá trình bảo trì ;
o Chi phí bảo dưỡng phụ thuộc vào số lượng các thay đổi và chi phí thay đổi phụ thuộc
vào bảo trì.


Page 11 of 20

Thay đổi dự đoán
-

Dự đoán số yêu cầuthay đổi và sự hiểu biết về mối quan hệ giữa hệ thống và mơi trường
của nó.

Hệ thống chặt chẽ cùng yêu cầu thay đổi bất cứ khi nào môi trường thay đổi.
Yếu tố ảnh hưởng mối quan hệ này là
o Số lượng và phức tạp của giao diện hệ thống ;
o Số yêu cầu hệ thống vốn đã không ổn định ;
o Các quy trình kinh doanh mà hệ thống được sử dụng.

Số liệu phức tạp
-

Dự đoán của bảo trì có thể được thực hiện bằng cách đánh giá sự phức tạp của các thành
phần hệ thống.
Các nghiên cứu đã chỉ ra rằng nỗ lực bảo trì nhất là trên một số lượng tương đối nhỏ của
các thành phần hệ thống.
Phức tạp phụ thuộc vào
o Phức tạp của cấu trúc điều khiển ;
o Phức tạp của cấu trúc dữ liệu ;
o Đối tượng, phương pháp (thủ tục) và kích thước mơ-đun.

Số liệu q trình
-

-

Số liệu q trình có thể được sử dụng để đánh giá khả năng bảo trì
o Số lượng yêu cầu để bảo trì khắc phục;
o Thời gian trung bình cần thiết để phân tích tác động ;
o Thời gian trung bình thực hiện để thực hiện một yêu cầu thay đổi ;
o Số lượng yêu cầu thay đổi nổi bật.
Nếu bất kỳ hoặc tất cả càng tăng, điều này sẽ chỉ ra khả năng bảo trì giảm.

Page 12 of 20

Ví dụ về bảo trì u cầu &TÁC ĐỘNG ALANYSIS
-

-

Yêu cầu bảo trì 78 ( bảo trì khắc phục u cầu )
o Các tính tốn đó xảy ra sau khi người chơi thay đổi giá trị của chất lượng, và đề nghị
giữ tổng số bất biến, nhưng họ khơng thực hiện.
Ví dụ, nếu những phẩm chất là sức mạnh = 10, sự kiên nhẫn = 0,8 và độ bền = 0,8
(tổng = 11,6 ) , và người chơi điều chỉnh sức mạnh để 11 , sau đó kết quả là sức
mạnh = 11, sự kiên nhẫn = 0 và sức chịu đựng = 0 , tổng không là 11,6 .
Yêu cầu bảo dưỡng 162 ( Bảo trì bảo trì hồn hảo )
o Sửa đổi gặp để trị chơi bắt đầu với khu vực và kết nối trong một phong cách phối
hợp. Khi người chơi đạt cấp độ 2 trạng thái, tất cả các khu vực và các kết nối được
hiển thị trong một phong cáchnâng cao phối hợp , mà là đặc biệt đến cấp 2 , vv.Ban
đồ họa sẽ cung cấp các hình ảnh.

Tác động của MR # 162

Hệ thống lại kỹ thuật
-

Tái cơ cấu hoặc một phần viết lại hoặc tất cả của một hệ thống di sản mà khơng thay đổi
của nó chức năng
Áp dụng một số nơi nhưng không phải tất cả các hệ thống phụ của một hệ thống lớn hơn
yêu cầu thường xuyên bảo trì.
Tái kỹ thuật bao gồm việc thêm nỗ lực để làm họ dễ dàng hơn để duy trì. Hệ thống có thể

được tái cấu trúc và tái tài liệu.

Ưu điểm của tái cấu trúc
-

giảm nguy cơ
o Có nguy cơ cao phát triển phần mềm mới. Có thể có vấn đề phát triển, các đặc
điểmvấn đề nhân sự và vấn đề kỹ thuật.


Page 13 of 20
-

chi phí giảm
o Chi phí tái cơ cấu thường là ít hơn so với chi phí đáng kể phát triển phần mềm mới.

Quá trình tái cấu trúc

Hoạt động quá trình tái cấu trúc
-

Dịch mã nguồn
o Chuyển đổi mã sang một ngôn ngữ mới.
kỹ thuật đảo ngược
o Phân tích chương trình để hiểu nó ;
Cải thiện cấu trúc chương trình
o Tái cơ cấu tự động cho dễ hiểu ;
chương trình modularisation
o Sắp xếp lại cấu trúc chương trình ;
tái cấu trúc dữ liệu

o Làm sạch và tái cơ cấu dữ liệu hệ thống.

Hình 9.12 Tái cấu trúc phương pháp tiếp cận


Page 14 of 20

Yếu tố chi phí tái cấu trúc
-

Chất lượng của phần mềm được thiết kế lại.
Công cụ hỗ trợ dành cho tái cấu trúc.
Mức độ chuyển đổi dữ liệu đó là cần thiết.
Sự sẵn có của đội ngũ nhân viên chuyên gia cho tái cấu trúc.
o Điều này có thể là một vấn đề với hệ thống cũ dựa trên cơng nghệ khơng cịn sử
dụng rộng rãi.

Bảo trì bằng tái cấu trúc
-

Tái cấu trúc là quá trình làm cho các cải tiến cho một chương trình để làm chậm sự suy
thối thơng qua sự thay đổi.
Bạn có thể nghĩ sắp xếp như ' bảo trì ' làm giảm các vấn đề của sự thay đổi trong tương lai.
Tái cấu trúc liên quan đến việc sửa đổi một chương trình để cải thiện nó cấu trúc, giảm độ
phức tạp của nó hoặc làm cho nó dễ hiểu hơn.
Khi bạn cấu trúc lại chương trình, bạn khơng nên thêm chức năng mà là tập trung vào cải
thiệnchương trình.

Sắp xếp và tái cấu trúc
Tái kỹ thuật diễn ra sau khi một hệ thống đã được duy trì trong một thời gian và chi phí bảo dưỡng

ngày càng tăng.Bạn sử dụng cơng cụ tự động để xử lý và kĩ sư đã dùng trong hệ thống cũ để tạo ra
một hệ thống mới được bảo trì tốt hơn.
-

Tái cấu trúc là một quá trình liên tục cải thiện trong suốt quá trình phát triển và tiến hóa.
Nónhằm tránh những cấu trúc và mã phân hủy làm tăng chi phí và khó khăn trong việc duy
trì một hệ thống.

' Bad smells ' trong mã chương trình
-

đang lặp lại


Page 15 of 20
Cùng mã hoặc tương tự có thể được bao gồm tại các địa điểm khác nhau trong một
chương trình. Điều này có thể được loại bỏ và thực hiện như một phương phápđơn
hoặc chức năng đó được gọi là theo yêu cầu.
phương pháp dài
o Nếu một phương pháp quá dài, cần được thiết kế lại như một số phương pháp ngắn
hơn.
Chuyển đổi ( trường hợp ) báo cáo
o Thường liên quan đến những sự trùng lặp, trong đó chuyển đổi phụ thuộc vào
loại một giá trị. Các báo cáo chuyển đổi có thể được phân tán xung quanh một
chương trình. Trong các ngơn ngữ hướng đối tượng, bạn thường có thể sử dụng
đa hình để đạt được điều tương tự.
vón cục dữ liệu
o Khối dữ liệu xảy ra khi cùng một nhóm các dữ liệu (các lĩnh vực trong các lớp học,
các thông số trong các phương pháp) lại xảy ra ở một vài nơi trong một chương
trình. Chúng có thể được thay thế bằng một đối tượng đóng gói tất cả các dữ liệu.

Lý thuyết chung
o Điều này xảy ra khi các nhà phát triển bao gồm tổng qt trong một chương trình
trong trường hợp nó là cần thiết trong tương lai. Điều này thường có thể chỉ đơn
giản là được gỡ bỏ.
o

-

-

-

-

Quản lý hệ thống di sản
-

-

Các tổ chức dựa vào hệ thống di sản phải chọn một chiến lược phát triển các hệ thống
o Loại bỏ hoàn toàn hệ thống và sửa đổi quy trình kinh doanh khi nó khơng cịn cần
thiết ;
o Tiếp tục duy trì hệ thống;
o Chuyển đổi hệ thống bằng cách tái cơ cấu để cải thiện vàbảo trì nó;
o Thay thế hệ thống với một hệ thống mới.
Chiến lược được lựa chọn nên phụ thuộc vào chất lượng hệ thống và giá trị kinh doanh của
mình.

Hình 9.13 Một ví dụ về một di sản đánh giá hệ thống

Page 16 of 20

Loại hệ thống di sản
-

-

Chất lượng thấp , giá trị kinh doanh thấp
o Các hệ thống này cần phải được loại bỏ.
Chất lượng thấp , giá trị kinh doanh cao
o Những đóng góp một phần kinh doanh quan trọng nhưng đắt tiền để duy trì. Nên
được tái thiết kế hoặc thay thế nếu thích hợp hệ thống có sẵn.
Chất lượng cao, giá trị kinh doanh thấp
o Thay thế với COTS, bỏ hồn tồn hoặc duy trì.
Chất lượng cao, giá trị kinh doanh cao
o Tiếp tục hoạt động trong sử dụng bảo trì hệ thống bình thường.

Đánh giá giá trị kinh doanh
-

-

Đánh giá nên quan điểm khác nhau vào tài khoản
o Hệ thống người dùng cuối cùng ;
o Khách hàng doanh nghiệp ;
o Cán bộ chuyên môn ;
o quản lý CNTT ;
o Lãnh đạo cao cấp.
Phỏng vấn các bên liên quan khác nhau và đối chiếu kết quả.

Các vấn đề trong đánh giá giá trị kinh doanh
-

Việc sử dụng các hệ thống


Page 17 of 20
Nếu hệ thống chỉ được sử dụng thường xun hoặc một số ít người, họ có thể có
một giá trị kinh doanh thấp.
Các quy trình kinh doanh được hỗ trợ
o Một hệ thống có thể có một giá trị kinh doanh thấp, nếu việc sử dụng
quy trình kinh doanh của nó khơng hiệu quả.
hệ thống tin cậy
o Nếu một hệ thống không phải là đáng tin cậy và những vấn đề ảnh hưởng trực tiếp
khách hàng doanh nghiệp, hệ thống có giá trị kinh doanh thấp.
Kết quả đầu ra hệ thống
o Nếu doanh nghiệp phụ thuộc vào kết quả đầu ra của hệ thống, thì hệ thống có một
giá trị kinh doanh cao.
o

-

-

-

Đánh giá chất lượng hệ thống
-

-

Đánh giá quá trình kinh doanh
o Như thế nào quá trình kinh doanh hỗ trợ các mục tiêu hiện tại của việc kinh doanh?
đánh giá môi trường
o Làm thế nào có mơi trườnghiệu quả của hệ thống và như thế nào là đắt tiền khi duy
trì hệ thống?
đánh giá ứng dụng
o Chất lượng của các hệ thống phần mềm ứng dụng là gì?

Đánh giá quá trình kinh doanh
-

-

Sử dụng một cách tiếp cận quan điểm định hướng và tìm câu trả lời các bên liên quan hệ
thống
o Có một mơ hình q trình xác định và nó theosau?
o Làm các phần khác nhau của tổ chức sử dụng các quá trình khác nhau cho các
cùng chức năng?
o Làm thế nào có q trình được điều chỉnh?
o Các mối quan hệ với các quá trình kinh doanh khác là gì và những cần thiết?
o Là q trình hỗ trợ có hiệu quả của các ứng dụng di sản phần mềm?
Ví dụ - một hệ thống du lịch đặt hàng có thể có một thấp giá trị kinh doanh do việc sử dụng
rộng rãi đặt hàng dựa trên web.

Yếu tố được sử dụng trong đánh giá môi trường
Yếu tố

Câu hỏi

ổn định nhà cung
cấp tỉ suất hư hỏng

Là nhà cung cấp vẫn còn tồn tại? Là nhà cung cấp tài chính ổn định và
khả năng tiếp tục tồn tại? Nếu nhà cung cấp khơng cịn trong kinh doanh,
khơng ai khác duy trì hệ thống? Khơng phần cứng có một tỷ lệ cao của thất
bại báo cáo? Hiện phần mềm hỗ trợ vụ tai nạn và hệ thống lực lượng khởi
động lại?


Page 18 of 20
Tuổi thọ

Làm thế nào cũ là phần cứng và phần mềm? Cũ phần cứng và
phần mềm hỗ trợ, lỗi thời hơn nó sẽ được. Nó vẫn có thể hoạt động
chính xác nhưng có thể có ý nghĩa kinh tế và kinh doanh
lợi ích cho di chuyển đến một hệ thống hiện đại hơn.

Hiệu suất

Là hiệu suất của hệ thống đầy đủ? làm hiệu suấtcác vấn đề có ảnh hưởng
đáng kể trên hệ thống người

yêu cầu hỗ trợ

Những hỗ trợ địa phương được yêu cầu của phần cứng và
phần mềm? Nếu có chi phí cao liên quan với điều này
hỗ trợ, nó có thể là giá trị xem xét thay thế hệ thống.

chi phí bảo trì

Các chi phí bảo trì phần cứng và hỗ trợ là gì
giấy phép phần mềm? Phần cứng cũ hơn có thể cao hơn
chi phí bảo trì hệ thống hiện đại hơn. Phần mềm hỗ trợ
có thể có chi phí bản quyền hàng năm cao.

Khả năng tương tác

Có vấn đề interfacing hệ thống để hệ thống khác?
Có thể trình biên dịch, ví dụ, được sử dụng với phiên bản hiện hành
của hệ điều hành? Được mô phỏng phần cứng cần thiết?

Yếu tố được sử dụng trong đánh giá ứng dụng
Yếu tố
Hiểu biết

Tài liệu
Dữ liệu

Hiệu suất
Ngơn ngữ lập trình

cấu hình
quản lý

Câu hỏi
Làm thế nào biết được khó khăn để hiểu được mã nguồn của hiện tại
hệ thống? Làm thế nào những cấu trúc điều khiển phức tạp được sử
dụng? Biến có chức năng j trong hàm của nó?

Hệ thống tài liệu gì có sẵn? Là tài liệu hồn chỉnh, nhất qn, và hiện tại?
Nó có phải một mơ hình dữ liệu rõ ràng cho hệ thống? Đánh giá nào cho
dữ liệu trên các tập tin trùng lặp? Các dữ liệu được sử dụng bởi hệ
thốngtrongthời điểm phù hợp?
Là hiệu suất của các ứng dụng đầy đủ? làm hiệu suất các vấn đề có ảnh
hưởng đáng kể trên hệ thống người
Trình biên dịch hiện đại có sẵn cho các lập trìnhngơn ngữ được sử dụng
để phát triển hệ thống? Là lập trình ngơn ngữ vẫn được sử dụng để phát
triển hệ thống mới?
Có phải tất cả các phiên bản của tất cả các bộ phận của hệ thống bằng
cách một quản lý hệ thống quản lý cấu hình? Là có một rõ rang Mơ tả của
các phiên bản của các thành phần được sử dụng trong hệ thống hiện tại?

kiểm tra dữ liệu

Không kiểm tra dữ liệu cho hệ thống tồn tại? Là có một kỷ lục
kiểm tra hồi quy thực hiện khi tính năng mới đã được thêm vào hệ thống?

kỹ năng nhân viên

Có những người có sẵn những người có những kỹ năng để duy trì


Page 19 of 20
ứng dụng? Có những người có sẵn những người có kinh nghiệm
với hệ thống?

Đo lường hệ thống
-

Bạn có
o
o
o

thể thu thập dữ liệu định lượng để đánh giá về chất lượng của hệ thống ứng dụng
Số lượng yêu cầu thay đổi hệ thống ;
Số lượng các giao diện người dùng khác nhau được sử dụng bởi hệ thống;
Khối lượng dữ liệu được sử dụng bởi hệ thống

Một bảo trì điển hình dịng chảy

Bảo trì & Patching


Page 20 of 20

Patches bảo trì
Thuận lợi

Khơng thuận lợi

• Giữ khách hàng hài lịng trong ngắn hạn
• Cho phép tiếp tụchoạt động và thử nghiệm
mà không lặp đi lặp lại lỗi
• Tránh các lỗi khác
• Cho phép sửa chữa thử nghiệm

•
•

•
•
•
•
•

Bản sao làm việc
vá và sửa chữa cuối cùng cả hai thực hiện
Đơi khi khơng bao giờthay thế
sửa chữa thích hợp hoãn lại mãi mãi!
sửa chữa phức tạp
phải loại bỏ
tài liệu quá trình phức tạp