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ơ)

Chia sẻ: Thanh Hoa | Ngày: | Loại File: PDF | Số trang:18

Thêm vào BST

Báo xấu

116
lượt xem 16
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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ơ)

Nội dung  Các vấn đề về kỹ thuật BẢO TRÌ PHẦN MỀM  Các vấn đề trong quản lý  Các vấn đề về dự đoán chi phí bảo trì phần PHẦN III – CÁC VẤN ĐỀ mềm THEN CHỐT TRONG BTPM  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ơ 1 2 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Các vấn đề về kỹ thuật Sự hiểu phần mềm  Sự hiểu phần mềm  Bảo trì viên thường bảo trì phần mềm mà họ  Kiểm thử không tham gia phát triển.  Các nghiên cứu chỉ ra rằng 40% - 60% công sức  Phân tích sự tác động bảo trì được dành để hiểu phần mềm được bảo trì.  Tính có thể bảo trì  Sự hiểu biết trở nên khó khăn hơn:  Với dạng biểu diễn theo hướng văn bản.  Khi các tài liệu không được cập nhật hoặc bị mất. 3 4 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 1
Kiểm thử Kiểm thử  Kiểm thử đầy đủ lặp lại trên một bộ phận chính  Những trở ngại trong kiểm thử: của phần mềm có thể gây tốn kém đáng kể cả về  Khó tìm thời gian để kiểm thử. thời gian và tiền bạc.  Không có dữ liệu kiểm thử tin cậy hay phù hợp  Kiểm thử hồi quy, tái kiểm thử lựa chọn của một cho việc kiểm thử các thay đổi được tạo ra. phần mềm hay một bộ phận của phần mềm để  Không phải luôn dễ dàng trong việc dự đoán đảm bảo rằng sự sửa đổi không gây ra các ảnh được những ảnh hưởng của các thay đổi về mã hưởng không dự tính trước, là quan trọng trong lệnh và thiết kế cũng như trong việc xử lý bảo trì. chúng. 5 6 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Phân tích sự tác động 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  Xem lại nội dung phân tích sự tác động trong hóa của hệ thống phần mềm. phần II.  Việc làm này là cần thiết để mở rộng và thích ứng  Để thực hiện tốt việc phân tích sự tác động, bảo với những yêu cầu thay đổi (cả chức năng và phi trì viên phải có kiến về cấu trúc và nội dung của chức năng) mà không phá hủy tính toàn vẹn của phần mềm. kiến trúc.  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. 7 8 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 2
Tính có thể bảo trì Tính có thể bảo trì  Định nghĩa  Các đặc điểm nhỏ hơn của tính có thể bảo trì phải  [IEEE] Tính có thể bảo trì (maintainability) là sự dễ được xác định, được xem xét và được quản lý dàng trong việc duy trì, cải tiến, thích ứng hay hiệu trong suốt các hoạt động phát triển phần mềm để chỉnh phần mềm để thỏa mãn những yêu cầu được xác giảm các chi phí bảo trì. định.  Tính có thể bảo trì bị ảnh hưởng bởi: kiến trúc,  [ISO/IEC] Tính có thể bảo trì là một trong các đặc điểm của chất lượng. 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:  Các quy trình có hệ thống và trưởng thành. 9  Các kỹ thuật, công cụ. 10 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Các vấn đề trong quản lý Bố trí nhân sự  Bố trí nhân sự  Sự phân cấp các nhu cầu của con người  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 11 12 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 3
Bố trí nhân sự Bố trí nhân sự  Những yêu cầu đối với nhân sự bảo trì  Bố trí nhân sự nói về cách thu hút và giữ được các  Phải xử lý những vấn đề mà các nhà phát triển chưa nhân viên bảo trì phần mềm. bao giờ nhìn thấy.  Những yếu tố ảnh hưởng  Cần kỹ năng không chỉ trong việc viết mã lệnh mà còn trong việc giao tiếp với người dùng, trong việc đoán  Áp lực về tinh thần trước sự thay đổi.  Thiếu huấn luyện phù hợp cho bảo trì viên  Kiên trì và có kỹ năng cao để lần tới tận gốc của vấn  Tốc độ thay thế nhân sự bảo trì cao đề; để 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. 13 14 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Các vấn đề về quy trình 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,  Một số hoạt động của bảo trì không có trong phát phương pháp, thực tiễn và các biến đổi mà con người triển phần mềm: sử dụng để phát triển và bảo trì phần mềm và các sản  Chuyển giao phần mềm từ tổ chức phát triển sang phẩm liên quan. tổ chức bảo trì  Các hoạt động của bảo trì phần mềm có nhiều điểm  Viết cam kết, hợp đồng bảo trì chung với phát triển phần mềm tại mức quy trình.  Chấp nhận hay từ chối các yêu cầu thay đổi  Bảo trì phần mềm cũng có những hoạt động riêng,  Phân tích sự tác động không có trong phát triển phần mềm. Chúng là những thách thức đối với quản lý. 15 16 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 4
Chọn nhóm bảo trì Chọn nhóm bảo trì  Trách nhiệm bảo trì phần mềm sẽ được giao cho:  Những thuận lợi khi giao nhiệm vụ bảo trì cho nhóm  Nhóm phát triển ra chính sản phẩm hoặc phát triển  Một nhóm riêng biệt không phải là nhóm phát triển.  Họ có kiến thức tốt nhất về hệ thống.  Họ không cần đến các tài liệu được soạn thảo tỉ mỉ.  Họ không cần thiết lập hệ thống giao tiếp chính thức giữa nhóm phát triển và nhóm bảo trì.  Sự đáp ứng về mặt nhân sự tốt hơn do có sự đa dạng về khối lượng công việc.  Người sử dụng chỉ cần làm việc với một tổ chức phần mềm. 17 18 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Chọn nhóm bảo trì Chọn nhóm bảo trì  Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm  Những thuận lợi khi giao nhiệm vụ bảo trì cho phát triển nhóm bảo trì  Nhà phát triển có thể rời khỏi tổ chức khi hoạt động bảo trì  Các tài liệu được tạo ra tốt hơn. đượ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  Bảo trì viên biết được các điểm mạnh, yếu của hệ việc bảo trì. thống.  Người có trách nhiệm bảo trì không được huấn luyện đầy  Các thủ tục thay thế nhân sự được xây dựng. đủ nếu chuyên gia phát triển rời khỏi tổ chức.  Các thủ tục thực hiện sự thay đổi được thiết lập.  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. 19 20 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 5
Chọn nhóm bảo trì Chọn nhóm bảo trì  Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm  Nhóm phát triển phần mềm thường không cần bảo trì thiết được giao nhiệm vụ bảo trì phần mềm.  Việc chuyển giao hệ thống bị chậm.  Nhóm bảo trì thường được chọn để đảm bảo rằng  Cần những huấn luyện quan trọng. hệ thống hoạt động chính xác và tiến hóa nhằm  Cần thời gian để hiểu hệ thống. đáp ứng các yêu cầu về sự thay đổi của người  Cần thời gian để thiết lập tổ chức bảo trì và các phương dùng. tiện.  Sự quyết định nên được đưa ra trên cơ sở của  Có thể có các vấn đề về tài chính. từng trường hợp.  Có thể chất lượng của sự hỗ trợ từ người dùng kém. 21 22 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Gia công bảo trì phần mềm Phép đo bảo trì phần mềm  Gia công bảo trì đang trở thành một ngành công nghiệp  Các thực thể có thể đo chính.  Mục đích của việc đo  Những thách thức chính với người gia công:  Một số phép đo  Xác định phạm vi của các dịch vụ bảo trì được yêu cầu và các chi tiết hợp đồng.  Kích thước  Mất một khoảng thời gian để đánh giá phần mềm trước  Độ phức tạp khi tiến hành ký kết hợp đồng.  Chất lượng  Gặp thách thức trong việc tiếp nhận sự chuyển giao  Tính dễ hiểu phần mềm.  Tính có thể bảo trì  Cần một khoản đầu tư ban đầu cho cơ sở hạ tầng, thiết lập quy trình, … 23 24 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 6
Các thực thể có thể đo 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 tuân theo tạo ra Tài nguyên bảo trì Quy trình bảo trì Sản phẩm bảo trì  Ba thực thể liên quan đến BTPM mà các thuộc -Nhân công -Tiền phát hành và chuyển giao -Tài liệu kỹ thuật -Tài liệu người dùng tính của chúng có thể đo là: -Công cụ -Ngân sách -Hỗ trợ vận hành -Hiệu chỉnh -Mã nguồn -Môi trường bảo trì -Cải tiến -Mã đối tượng  Quy trình: bất cứ hoạt động nào liên quan đến phần -Giám sát sự thay đổi -Báo cáo phân tích tác động -Kiểm thử hồi quy -Cơ sở dữ liệu mềm -Quản lý cấu hình  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 25 26 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Ứng dụng (Trước) Các Kích thước chức năng Dòng mã lệnh Các thực thể có thể đo thực Đặc điểm môi trường Ứng dụng (Sau) Các yêu cầu bảo trì Kích thước chức năng thể Số lượng Dòng mã lệnh  Đo tài nguyên có Phân loại Quy trình bảo trì Đặc điểm môi trường  Thực hiện ước lượng: công sức, số nhân công và ngân thể Các yêu cầu được hoàn thành sách Công sức Số lượng  Hai phương pháp ước lượng phổ biến nhất trong đo Người - Ngày Phân loại BTPM là: Kích thước chức năng Input khác Các công cụ Dòng mã lệnh  Dựa vào kinh nghiệm Các dịch vụ quản lý Người - Ngày  Dùng các mô hình thông số  Đ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 đó 27 28 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 7
Các thực thể có thể đo Mục tiêu của phép đo phần mềm  Đ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ì.  Phép đo phần mềm được cần đến vì chúng được  6 đặc trưng của chất lượng sản phẩm phần mềm được xác dùng để: định bởi chuẩn ISO 2001  Đá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ệ 29 thống phần mềm (ví dụ: chất lượng, hiệu suất) 30 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Đo kích thước (Size) Đo kích thước  Phép đo này thường được tính theo đơn vị ngàn dòng  Ưu điểm: Phép đo này dễ xác định và có tương lệnh (KLOC, KDSI). quan mạnh với các phép đo khác như công sức  Trong quá trình bảo trì, sự chú ý dồn vào dòng lệnh hay mật độ lỗi. “delta”: số dòng lệnh được thêm vào hay được sửa  Hạn chế: đổi trong suốt quá trình bảo trì.  Không có chuẩn nào cho phép đo LOC và phụ thuộc  Các cách đo kích thước vào ngôn ngữ lập trình được sử dụng.  Đếm số dòng lệnh  Quá đơn giản và không phản ánh được chi phí hay  Tính số điểm chức năng năng suất.  Tính số điểm đặc trưng  Tính số trường hợp sử dụng 31 32  … Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 8
Đo độ phức tạp Đo độ phức tạp (Complexity)  Chương trình càng phức tạp thì bảo trì viên càng có khả  Không có một sự thống nhất nào về thuật ngữ “độ phức năng gây ra lỗi khi thực hiện một thay đổi. tạp”.  Giá trị độ phức tạp càng cao, việc hiểu chương trình càng  Trong bảo trì phần mềm, ta lưu ý xác định độ phức tạp khó và vì thế khả năng có thể bảo trì càng thấp. của chương trình.  Độ phức tạp có thể được sử dụng để dự đoán công sức  Độ phức tạp của chương trình là sự khó khăn trong việc cần để tạo ra sự thay đổi cho chương trình. duy trì, thay đổi và hiểu chương trình.  Hai phép đo phổ biến nhất đo độ phức tạp của mã lệnh:  Độ phức tạp của chương trình liên quan đến cấu trúc  Phép đo của McCabe chương trình, nội dung ngữ nghĩa, dòng điều khiển, dòng  Phép đo của Halstead dữ liệu và độ phức tạp của giải thuật. 33 34 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Đo độ phức tạp Đo độ phức tạp  Phép đo độ phức tạp của McCabe  Phép đo độ phức tạp của Halstead  Một chương trình được xem như một đồ thị có hướng với Phép đo ảnh hưởng đến độ phức tạp: nút là dòng lệnh và cung là dòng điều khiển giữa các lệnh.  Nỗ lực của chương trình  Độ phức tạp của McCabe được tính theo công thức v(F) = e – n + 2 với: E = (n1*N2*(N1+N2)*log(n1+n2)) / (2*n2)  e: Tổng số cạnh hay cung Với:  n: Tổng số nút  n1: Số các toán tử duy nhất được sử dụng  Giá trị này có thể giúp bảo trì viên:  n2: Số các toán hạng duy nhất được sử dụng  Cân nhắc xem chương trình có cần được hiệu chỉnh để làm  N1: Tổng số toán tử được sử dụng giảm độ phức tạp hay không.  N2: Tổng số toán hạng được sử dụng  Ước lượng thời gian cần để hiểu và hiệu chỉnh chương trình. 35 36 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 9
Đo độ phức tạp Đo chất lượng  Phép đo độ phức tạp của Halstead  Chất lượng sản phẩm  Phép đo của Halstead được sử dụng rộng rãi vì:  Số các yêu cầu thay đổi nhận được từ người dùng sau  Chúng dễ tính và không cần sự phân tích sâu các tính khi hệ thống được đưa vào vận hành. năng lập trình và dòng điều khiển  Phép đo này chỉ bao gồm các yêu cầu mà chúng liên quan  Có thể được áp dụng cho bất cứ ngôn ngữ nào với các lỗi được phát hiện bởi khách hàng, không bao gồm  Tuy nhiên phép đo này chỉ dựa trên mã lệnh và mà các yêu cầu thay đổi nhằm cải tiến tính năng mà chúng không dựa vào các tài liệu để tính công sức hay sự hiểu không có trong đặc tả yêu cầu phần mềm. biết chương trình.  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ì. 37 38 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Đo chất lượng Đo chất lượng  Chất lượng quy trình  Chất lượng sản phẩm  Kế hoạch  Số lỗi được phát hiện sau khi hệ thống phần mềm đi 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 vào hoạt động, thường là sau năm đầu tiên chuyển trong thực tế để đạt được sự phát hành cho khách hàng đầu tiên giao. Thời gian thực hiện công việc theo kế hoạch  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.  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ố lượng người sử dụng báo cùng một lỗi có thể được  Số dương có nghĩa là phát hành sớm 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. 39 40 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 10
Đo chất lượng Đo tính dễ hiểu  Chất lượng quy trình  Tính dễ hiểu của chương trình không chỉ phụ  Năng suất thuộc vào mã nguồn mà còn phụ thuộc vào các Số dòng mã lệnh được thêm vào hay được sửa đổi yếu tố khác như tài liệu sẵn có, quy trình bảo trì Công sức tạo ra sự bổ sung hay sự sửa đổi và nhân sự bảo trì.  Tính dễ hiểu thường tỷ lệ nghịch với độ phức tạp.  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. 41 42 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Đo tính có thể bảo trì Đ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  Tính có thể bảo trì không chỉ bị giới trong mã được phát triển nhằm cố gắng dự đoán các thiếu sót hay các nguồn mà còn liên quan tới sự đặc tả, sự thiết kế nguyên nhân lỗi, hay xác định các phần được hiệu chỉnh. và các tài liệu về kế hoạch kiểm thử.  Đ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  Một số phép đo cho từng đặc điểm con của tính thực hiện một hiệu chỉnh xác định. có thể bảo trì.  Đo tính ổn định  Đo tính có thể phân tích  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 ổn định  Đo tính có thể kiểm thử  Đo tính dễ thay đổi  Các phép đo công sức của bảo trì viên và người sử dụng  Đo tính có thể kiểm thử trong việc cố gắng kiểm thử phần mềm được hiệu chỉnh. 43 44 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 11
Đo chi phí Ước lượng chi phí bảo trì  Sẽ được trình bày chi tiết ở phần ước lượng  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 45 46 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Các mối quan hệ cần lưu ý 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à  Mối quan hệ chi phí bảo trì phần mềm và các thành phần thời gian ứng dụng trong khung làm việc của bảo trì phần mềm 47 48 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 12
Các yếu tố kỹ thuật ảnh hưởng Các yếu tố phi kỹ thuật đến chi phí ảnh hưởng đến chi phí  Ngôn ngữ lập trình  Lĩnh vực ứng dụng  Phong cách lập trình  Sự ổn định về nhân sự  Chất lượng tài liệu  Tuổi của phần mềm  Sự độc lập của các thành phần  Sự phụ thuộc của phần mềm vào môi trường  Độ phức tạp của chương trình  Nhu cầu của người sử dụng  Kiểm thử  Các kỹ thuật quản lý cấu hình 49 50 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Ước lượng chi phí bảo trì bằng mô hình điểm chức năng Mô hình điểm chức năng  Các loại đ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 • Các điểm chức năng dữ liệu (Data Function Points) được đặc trưng • Các điểm chức năng xử lý bởi hai yếu tố: (Transaction Function Point) được • ILF (Internal Logical File) đặc trưng bởi ba yếu tố: • EIF (External Interface File) • EI (External Inputs) 51 • EO (External Outputs) 52 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ • EQ (External Inquiries) 13
Mô hình điểm chức năng Mô hình điểm chức năng  Các loại điểm chức năng  Các loại điểm chức năng  ILF là một nhóm các dữ liệu có liên quan về mặt logic có  EO là một tiến trình căn bản trong đó dữ liệu phát sinh thể nhận dạng bởi người sử dụng trong phạm vi ứng dụng được truyền từ bên trong ra bên ngoài phạm vi ứng dụng. và được cập nhật thông qua EI. Nó có thể là các báo cáo hay các tập tin kết xuất được gửi  EIF là một nhóm các dữ liệu có liên quan về mặt logic chỉ cho ứng dụng khác và được tạo ra từ những thông tin có được sử dụng cho mục đích tham khảo. Dữ liệu nằm ở bên trong một hay nhiều ILF hoặc EIF. (Dữ liệu phát sinh ngoài phạm vi ứng dụng và được cập nhật bởi EI của các thường là kết quả của các giải thuật hay sự tính toán.) ứng dụng khác. Nó được lưu trữ trong tập tin.  EQ là một tiến trình căn bản có hai chiều nhập dữ liệu và  EI là một tiến trình căn bản trong đó dữ liệu được truyền từ xuất dữ liệu nhằm truy xuất dữ liệu từ một hay nhiều bên ngoài vào bên trong phạm vi của ứng dụng. Dữ liệu có ILF/EIF. Dữ liệu nhập không cập nhật ILF/EIF và dữ liệu thể là thông tin điều khiển hoặc thông tin nghiệp vụ (thông xuất không phải là dữ liệu phát sinh. qua màn hình nhập liệu hoặc từ một ứng dụng khác). 53 54 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Mô hình điểm chức năng Mô hình điểm chức năng  Tính số điểm chức năng thô (chưa được cân đối)  Các thành phần cơ bản UFP = a1 x EI + a2 x EO + a3 x EQ + a4 x ILF + a5 x EIF  FTR (File Type Referenced) là một loại tập tin được tham với a1, a2, a3, a4, a5 là giá trị các điểm chức năng theo độ khảo bởi một xử lý. FTR phải là một ILF hoặc EIF. phức tạp cho trong bảng sau.  RET (Record Element Type) là các nhóm dữ liệu con liên quan về mặt logic trong ILF/EIF có thể nhận dạng bởi người sử dụng. Hầu hết các RET dựa vào mối quan hệ cha – con.  DET (Data Element Type) là một trường không lặp lại, có thể nhận dạng bởi người sử dụng. DET là thông tin động, không phải là thông tin tĩnh. Nó là các trường nhập dữ liệu, các thông báo lỗi, các trường được hiển thị, các giá trị tính toán, các nút. 55 56 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 14
Mô hình điểm chức năng Mô hình điểm chức năng  Tính số điểm chức năng được cân đối 14 hệ số kỹ thuật Số điểm chức năng được cân đối cho các hoạt động thêm mới Cập nhật trực tuyến 1. Giao tiếp dữ liệu 8. Số điểm chức năng thô (thêm mới) x (0.65 + 0.01 x Tổng các mức độ ảnh hưởng của các hệ số kỹ thuật ) 2. Chức năng phân tán 9. Xử lý phức tạp Số điểm chức năng được cân đối cho các hoạt động sửa đổi 3. Sự thực thi 10. Tính có thể tái sử dụng Số điểm chức năng thô (hiệu chỉnh) x (0.65 + 0.01 x 4. Cấu hình phụ thuộc 11. Dễ cài đặt Tổng các mức độ ảnh hưởng của các hệ số kỹ thuật ) 5. Tỷ lệ giao dịch 12. Dễ vận hành  Ước lượng số dòng lệnh LOC 6. Nhập dữ liệu trực tuyến 13. Đa nơi LOC = AVC * số điểm chức năng được cân đối (thêm mới + sửa đổi) 7. Hiệu suất của người dùng cuối 14. Thay đổi thuận tiện với AVC: yếu tố phụ thuộc vào ngôn ngữ lập trình được sử dụng 14 hệ số kỹ thuật (có mức độ ảnh hưởng nằm trong phạm vi từ 0 (không quan trọng hay không thích hợp hay không ảnh hưởng) tới 5 57 (cực kỳ quan trọng hay cần thiết tuyệt đối hay ảnh hưởng nhất) 58 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Mô hình điểm chức năng Mô hình COCOMO II  Đo kích thước bảo trì phần mềm Bảng Trong đó: xác định giá trị  Base code size: Kích thước mã lệnh cơ sở AVC  MCF (Maintenance Change Factor): Hệ số thay đổi cho một bảo trì. Nó được tính theo công thức: số NNLT  Size Added: Kích thước mã lệnh được thêm vào 59  Size Modified: Kích thước mã lệnh được sửa đổi. 60 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 15
Mô hình COCOMO II Mô hình COCOMO II  MAF (Maintenance Adjustment Factor): Hệ số điều  SU (Software Understanding): Sự hiểu biết về phần mềm (theo tỷ lệ %) chỉnh bảo trì Trong đó:  SU (Software Understanding): Sự hiểu biết phần mềm  UNFM (Programmer Unfamiliarity): Sự không biết rõ của lập trình viên 61 62 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Mô hình COCOMO II Mô hình COCOMO II  UNFM (Programmer Unfamiliarity): Mức độ không  Công sức bảo trì phần mềm biết rõ của lập trình viên.  A: Hệ số công sức (có giá trị 2.94)  E: Hệ số mũ. Nó được xác định theo công thức  B: Hằng số có giá trị 0.91  SF: Hệ số tỷ lệ  EM (Effort Multiplier): Bội số công sức 63 64 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 16
Mô hình COCOMO II Mô hình COCOMO II  Bảng các hệ số tỷ lệ SF  Bảng bội số công sức EM 65 66 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ ILF Lưu ý Tham khảo: Cách EIF  Ước lượng chi phí bảo trì bằng kinh nghiệm tính  Dưới dạng đánh giá của chuyên gia dựa vào sự tương giá trị tự và cấu trúc phân chia công việc các loại  Là phương pháp được sử dụng để hoàn chỉnh kết xuất điểm EI từ mô hình thông số nhằm đạt được một dự đoán. chức năng  Phương pháp tốt nhất cho dự đoán bảo trì phần mềm là kết hợp dữ liệu quá khứ và kinh nghiệm. EO EQ 67 68 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 17
HẾT PHẦN III 69 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 18