Bài giảng Bảo trì phần mềm - Phần 3: Các vấn đề then chốt trong bảo trì phần mềm (ĐH Cần Thơ)

Bài giảng Bảo trì phần mềm - Phần 3: Các vấn đề then chốt trong bảo trì phần mềm cung cấp cho người học các kiến thức: Các vấn đề về kỹ thuật, các vấn đề trong quản lý, các vấn đề về dự đoán chi phí bảo trì phần mềm, các vấn đề về phép đo bảo trì phần mềm. Mời các bạn cùng tham khảo.

Trang 1

BẢO TRÌ PHẦN MỀM

PHẦN III – CÁC VẤN ĐỀ

THEN CHỐT TRONG BTPM

Các vấn đề về kỹ thuật

Các vấn đề trong quản lý

Các vấn đề về dự đoán chi phí bảo trì phần mềm

Các vấn đề về phép đo bảo trì phần mềm

Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ

3

Các vấn đề về kỹ thuật

 Sự hiểu phần mềm

 Kiểm thử

 Phân tích sự tác động

 Tính có thể bảo trì

4

Sự hiểu phần mềm

 Bảo trì viên thường bảo trì phần mềm mà họ không tham gia phát triển

 Các nghiên cứu chỉ ra rằng 40% - 60% công sức bảo trì được dành để hiểu phần mềm được bảo trì

 Sự hiểu biết trở nên khó khăn hơn:

Trang 2

Kiểm thử

 Kiểm thử đầy đủ lặp lại trên một bộ phận chính

của phần mềm có thể gây tốn kém đáng kể cả về

thời gian và tiền bạc

 Kiểm thử hồi quy, tái kiểm thử lựa chọn của một

phần mềm hay một bộ phận của phần mềm để

đảm bảo rằng sự sửa đổi không gây ra các ảnh

hưởng không dự tính trước, là quan trọng trong

bảo trì

6

Kiểm thử

 Những trở ngại trong kiểm thử:

 Khó tìm thời gian để kiểm thử

 Không có dữ liệu kiểm thử tin cậy hay phù hợp cho việc kiểm thử các thay đổi được tạo ra.

 Không phải luôn dễ dàng trong việc dự đoán được những ảnh hưởng của các thay đổi về mã lệnh và thiết kế cũng như trong việc xử lý chúng.

7

Phân tích sự tác động

 Phân tích sự tác động là rất quan trọng cho sự tiến

hóa của hệ thống phần mềm

 Việc làm này là cần thiết để mở rộng và thích ứng

với những yêu cầu thay đổi (cả chức năng và phi

chức năng) mà không phá hủy tính toàn vẹn của

kiến trúc.

8

Phân tích sự tác động

 Xem lại nội dung phân tích sự tác động trong phần II.

 Để thực hiện tốt việc phân tích sự tác động, bảo trì viên phải có kiến về cấu trúc và nội dung của phần mềm.

 Những phần mềm được thiết kế với tính có thể bảo trì sẽ giúp cho việc phân tích sự tác động rất thuận lợi.

Trang 3

Tính có thể bảo trì

 Định nghĩa

dàng trong việc duy trì, cải tiến, thích ứng hay hiệu

chỉnh phần mềm để thỏa mãn những yêu cầu được xác

định

điểm của chất lượng

10

Tính có thể bảo trì

 Các đặc điểm nhỏ hơn của tính có thể bảo trì phải được xác định, được xem xét và được quản lý trong suốt các hoạt động phát triển phần mềm để giảm các chi phí bảo trì

 Tính có thể bảo trì bị ảnh hưởng bởi: kiến trúc, thiết kế, mã lệnh, ngôn ngữ lập trình, và các hoạt động kiểm thử

 Tính bảo trì có thể được cải thiện qua:

11

Các vấn đề trong quản lý

 Bố trí nhân sự

 Các vấn đề về quy trình

 Chọn nhóm bảo trì

 Gia công bảo trì phần mềm

12

Bố trí nhân sự

 Sự phân cấp các nhu cầu của con người

Trang 4

 Những yêu cầu đối với nhân sự bảo trì

bao giờ nhìn thấy

trong việc giao tiếp với người dùng, trong việc đoán

trước sự thay đổi

đề; để hiểu các công việc bên trong của một hệ thống

lớn; để hiệu chỉnh cấu trúc, mã lệnh và tài liệu của hệ

thống.

14

 Bố trí nhân sự nói về cách thu hút và giữ được các nhân viên bảo trì phần mềm

 Những yếu tố ảnh hưởng

 Áp lực về tinh thần

 Thiếu huấn luyện phù hợp cho bảo trì viên

 Tốc độ thay thế nhân sự bảo trì cao

15

Các vấn đề về quy trình

 Quy trình phần mềm là một tập hợp các hoạt động,

phương pháp, thực tiễn và các biến đổi mà con người

sử dụng để phát triển và bảo trì phần mềm và các sản

phẩm liên quan.

 Các hoạt động của bảo trì phần mềm có nhiều điểm

chung với phát triển phần mềm tại mức quy trình.

 Bảo trì phần mềm cũng có những hoạt động riêng,

không có trong phát triển phần mềm.

16

Các vấn đề về quy trình

 Một số hoạt động của bảo trì không có trong phát triển phần mềm:

 Chuyển giao phần mềm từ tổ chức phát triển sang

tổ chức bảo trì

 Viết cam kết, hợp đồng bảo trì

 Chấp nhận hay từ chối các yêu cầu thay đổi

 Phân tích sự tác động Chúng là những thách thức đối với quản lý.

Trang 5

Chọn nhóm bảo trì

 Trách nhiệm bảo trì phần mềm sẽ được giao cho:

18

 Những thuận lợi khi giao nhiệm vụ bảo trì cho nhóm phát triển

giữa nhóm phát triển và nhóm bảo trì.

khối lượng công việc.

mềm.

19

 Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm

phát triển

 Nhà phát triển có thể rời khỏi tổ chức khi hoạt động bảo trì

được thực hiện

 Nhân sự mới có thể không hài lòng với khối lượng công

việc bảo trì

 Người có trách nhiệm bảo trì không được huấn luyện đầy

đủ nếu chuyên gia phát triển rời khỏi tổ chức

 Nhà phát triển thường tốn quá nhiều thời gian cho việc hoàn

thiện hệ thống đã phát triển

 Thường nhóm phát triển ban đầu được giao các dựa án mới

20

 Những thuận lợi khi giao nhiệm vụ bảo trì cho nhóm bảo trì

 Các tài liệu được tạo ra tốt hơn

 Bảo trì viên biết được các điểm mạnh, yếu của hệ thống.

 Các thủ tục thay thế nhân sự được xây dựng.

 Các thủ tục thực hiện sự thay đổi được thiết lập.

Trang 6

 Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm

bảo trì

tiện

22

 Nhóm phát triển phần mềm thường không cần thiết được giao nhiệm vụ bảo trì phần mềm

 Nhóm bảo trì thường được chọn để đảm bảo rằng

hệ thống hoạt động chính xác và tiến hóa nhằm đáp ứng các yêu cầu về sự thay đổi của người dùng

 Sự quyết định nên được đưa ra trên cơ sở của từng trường hợp

23

Gia công bảo trì phần mềm

chính

và các chi tiết hợp đồng.

khi tiến hành ký kết hợp đồng.

phần mềm.

lập quy trình, …

24

Phép đo bảo trì phần mềm

 Các thực thể có thể đo

 Mục đích của việc đo

 Một số phép đo

Trang 7

Các thực thể có thể đo

 Phép đo BTPM tập trung nhiều hơn vào sự giải

quyết vấn đề và sự quản lý các yêu cầu thay đổi

 Ba thực thể liên quan đến BTPM mà các thuộc

tính của chúng có thể đo là:

 Quy trình: bất cứ hoạt động nào liên quan đến phần

mềm

 Tài nguyên: đầu vào của quy trình

 Sản phẩm: bất cứ kết xuất trung gian hay cuối cùng là

kết quả của quy trình

26

-Nhân công -Công cụ -Ngân sách -Môi trường bảo trì

-Tiền phát hành và chuyển giao -Hỗ trợ vận hành

-Hiệu chỉnh -Cải tiến -Giám sát sự thay đổi -Kiểm thử hồi quy -Quản lý cấu hình

-Tài liệu kỹ thuật -Tài liệu người dùng -Mã nguồn -Mã đối tượng -Báo cáo phân tích tác động -Cơ sở dữ liệu

27

Quy trình bảo trì

Các yêu cầu bảo trì

Số lượng

Phân loại

Công sức

Người - Ngày

Input khác

Các công cụ Các dịch vụ quản lý

Ứng dụng (Trước)

Kích thước chức năng Dòng mã lệnh Đặc điểm môi trường Ứng dụng (Sau)

Kích thước chức năng Dòng mã lệnh Đặc điểm môi trường

Các yêu cầu được hoàn thành

Số lượng Phân loại Kích thước chức năng Dòng mã lệnh Người - Ngày

 Đo quy trình bảo trì

 Xác định các hoạt động chính của quy trình

 Đo các đặc trưng của những hoạt động chính đó

Các

thực

thể

có

thể

đo

28

 Đo tài nguyên

sách

BTPM là:

 Dựa vào kinh nghiệm

 Dùng các mô hình thông số

Trang 8

 Đo sản phẩm phần mềm

 Chất lượng của sản phẩm phần mềm là đặc biệt quan trọng

đối với nhóm bảo trì

 6 đặc trưng của chất lượng sản phẩm phần mềm được xác

định bởi chuẩn ISO 2001

30

Mục tiêu của phép đo phần mềm

 Phép đo phần mềm được cần đến vì chúng được dùng để:

 Đánh giá các phương pháp, thư viện chương trình,

công cụ để đưa ra quyết định cái nào là phù hợp nhất với một công việc cụ thể

 Kiểm soát quy trình của sự thay đổi phần mềm để đảm

bảo các yêu cầu thay đổi được xử lý đúng và trong phạm vi ngân sách.

 Dự báo các khía cạnh khác nhau của chi phí, quy trình

và sản phẩm phần mềm.

 Cải tiến các đặc trưng khác nhau của quy trình, hệ

thống phần mềm (ví dụ: chất lượng, hiệu suất)

31

Đo kích thước (Size)

 Phép đo này thường được tính theo đơn vị ngàn dòng

lệnh (KLOC, KDSI).

 Trong quá trình bảo trì, sự chú ý dồn vào dòng lệnh

“delta” : số dòng lệnh được thêm vào hay được sửa

đổi trong suốt quá trình bảo trì

 Các cách đo kích thước

32

Đo kích thước

 Ưu điểm: Phép đo này dễ xác định và có tương quan mạnh với các phép đo khác như công sức hay mật độ lỗi

 Hạn chế:

vào ngôn ngữ lập trình được sử dụng.

năng suất

Trang 9

Đo độ phức tạp (Complexity)

 Không có một sự thống nhất nào về thuật ngữ “độ phức

tạp”

 Trong bảo trì phần mềm, ta lưu ý xác định độ phức tạp

của chương trình

 Độ phức tạp của chương trình là sự khó khăn trong việc

duy trì, thay đổi và hiểu chương trình

 Độ phức tạp của chương trình liên quan đến cấu trúc

chương trình, nội dung ngữ nghĩa, dòng điều khiển, dòng

dữ liệu và độ phức tạp của giải thuật

34

Đo độ phức tạp

năng gây ra lỗi khi thực hiện một thay đổi

khó và vì thế khả năng có thể bảo trì càng thấp

cần để tạo ra sự thay đổi cho chương trình.

35

 Một chương trình được xem như một đồ thị có hướng với

nút là dòng lệnh và cung là dòng điều khiển giữa các lệnh

 Độ phức tạp của McCabe được tính theo công thức v(F) = e

– n + 2 với:

 e: Tổng số cạnh hay cung

 n: Tổng số nút

 Giá trị này có thể giúp bảo trì viên:

 Cân nhắc xem chương trình có cần được hiệu chỉnh để làm

giảm độ phức tạp hay không

 Ước lượng thời gian cần để hiểu và hiệu chỉnh chương

 Phép đo độ phức tạp của Halstead

Phép đo ảnh hưởng đến độ phức tạp:

E = (n1*N2*(N1+N2)*log(n1+n2)) / (2*n2)

Với:

 n1: Số các toán tử duy nhất được sử dụng

 n2: Số các toán hạng duy nhất được sử dụng

 N1: Tổng số toán tử được sử dụng

 N2: Tổng số toán hạng được sử dụng

Trang 10

 Phép đo độ phức tạp của Halstead

 Phép đo của Halstead được sử dụng rộng rãi vì:

năng lập trình và dòng điều khiển

không dựa vào các tài liệu để tính công sức hay sự hiểu

biết chương trình

38

Đo chất lượng

 Chất lượng sản phẩm

 Số các yêu cầu thay đổi nhận được từ người dùng sau

khi hệ thống được đưa vào vận hành

 Phép đo này chỉ bao gồm các yêu cầu mà chúng liên quan với các lỗiđược phát hiện bởi khách hàng, không bao gồm các yêu cầu thay đổi nhằm cải tiến tính năng mà chúng không có trong đặc tả yêu cầu phần mềm

 Số lượng các yêu cầu thay đổi từ người dùng có thể được xem như chỉ số đo sự hài lòng của khách hàng

 Nó còn có thể được xem là chỉ số đo công sức (nỗ lực) bảo trì

39

 Chất lượng sản phẩm

 Số lỗi được phát hiện sau khi hệ thống phần mềm đi

vào hoạt động, thường là sau năm đầu tiên chuyển

giao

 Các loại lỗi giống nhau được phát hiện bởi nhiều hơn

một người được tính như một lỗi đơn

 Số lượng người sử dụng báo cùng một lỗi có thể được

dùng như một phép đo về độ quan trọng của lỗi=> một

mức ưu tiên nên được gán cho lỗi

40

 Chất lượng quy trình

 Kế hoạch

Thời gian thực hiện công việc theo kế hoạch - Thời gian thực hiện công việc trong thực tế để đạt được sự phát hành cho khách hàng đầu tiên Thời gian thực hiện công việc theo kế hoạch

 Phép đo này được biểu diễn ở dạng tỷ lệ phần trăm

 Số âm có nghĩa là có sự sơ suất trong quá trình bảo trì

 Số dương có nghĩa là phát hành sớm

Trang 11

 Chất lượng quy trình

 Năng suất

Số dòng mã lệnh được thêm vào hay được sửa đổi Công sức tạo ra sự bổ sung hay sự sửa đổi

 Công sức là tổng thời gian từ lúc phân tích các yêu cầu

thay đổi cho đến khi thực hiện thành công sự thay đổi

42

Đo tính dễ hiểu

 Tính dễ hiểu của chương trình không chỉ phụ thuộc vào mã nguồn mà còn phụ thuộc vào các yếu tố khác như tài liệu sẵn có, quy trình bảo trì

và nhân sự bảo trì.

 Tính dễ hiểu thường tỷ lệ nghịch với độ phức tạp.

43

Đo tính có thể bảo trì

 Tính có thể bảo trì không chỉ bị giới trong mã

nguồn mà còn liên quan tới sự đặc tả, sự thiết kế

và các tài liệu về kế hoạch kiểm thử

 Một số phép đo cho từng đặc điểm con của tính

có thể bảo trì

 Đo tính có thể phân tích

 Đo tính ổn định

 Đo tính dễ thay đổi

 Đo tính có thể kiểm thử

44

Đo tính có thể bảo trì

 Đo tính có thể phân tích

 Các phép đo công sức của bảo trì viên hay các tài nguyên được phát triển nhằm cố gắng dự đoán các thiếu sót hay các nguyên nhân lỗi, hay xác định các phần được hiệu chỉnh

 Đo tính dễ thay đổi

 Các phép đo công sức của bảo trì viên có liên quan tới việc thực hiện một hiệu chỉnh xác định

 Đo tính ổn định

 Các phép đo hành vi không mong đợi của phần mềm, bao gồm những vấn đề được bắt gặp trong suốt sự kiểm thử

 Đo tính có thể kiểm thử

 Các phép đo công sức của bảo trì viên và người sử dụng trong việc cố gắng kiểm thử phần mềm được hiệu chỉnh

Trang 12

Đo chi phí

46

Ước lượng chi phí bảo trì

 Các mối quan hệ cần lưu ý

 Các yếu tố kỹ thuật ảnh hưởng đến việc ước lượng

 Các yếu tố phi kỹ thuật ảnh hưởng đến việc ước lượng

 Ước lượng chi phí bằng mô hình điểm chức năng

 Ước lượng chi phí bằng mô hình COCOMO II

47

Các mối quan hệ cần lưu ý

 Mối quan hệ giữa khối lượng công việc BTPM và

thời gian ứng dụng

48

Các mối quan hệ cần lưu ý

trong khung làm việc của bảo trì phần mềm

Trang 13

Các yếu tố kỹ thuật ảnh hưởng

đến chi phí

 Ngôn ngữ lập trình

 Phong cách lập trình

 Chất lượng tài liệu

 Sự độc lập của các thành phần

 Độ phức tạp của chương trình

 Kiểm thử

 Các kỹ thuật quản lý cấu hình

50

Các yếu tố phi kỹ thuật ảnh hưởng đến chi phí

 Lĩnh vực ứng dụng

 Sự ổn định về nhân sự

 Tuổi của phần mềm

 Sự phụ thuộc của phần mềm vào môi trường

 Nhu cầu của người sử dụng

51

Ước lượng chi phí bảo trì bằng mô

hình điểm chức năng

 Các loại điểm chức năng

 Các thành phần cơ bản trong từng loại điểm chức

năng

 Bảng giá trị để tính từng loại điểm chức năng

 Công thức tính điểm chức năng trong BTPM

52

Mô hình điểm chức năng

 Các loại điểm chức năng

• Các điểm chức năng dữ liệu(Data Function Points) được đặc trưng bởi hai yếu tố:

• ILF (Internal Logical File)

• EIF (External Interface File)

• Các điểm chức năng xử lý

(Transaction Function Point) được đặc trưng bởi ba yếu tố:

• EI (External Inputs)

• EO (External Outputs)

• EQ (External Inquiries)

Định dạng
Số trang	18
Dung lượng	1,23 MB