Bảo trì phần mềm - Phần III: Các vấn đề then chốt trong bảo trì phần mềm

 Ước lượng chi phí bảo trì bằng kinh nghiệm  Dưới dạng đánh giá của chuyên gia dựa vào sự tương tự và cấu trúc phân chia công việc  Là phương pháp được sử dụng để hoàn chỉnh kết xuất từ mô hình thông số nhằm đạt được một dự đoán.  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.

pdf18 trang | Chia sẻ: nguyenlam99 | Lượt xem: 1280 | Lượt tải: 0download
Bạn đang xem nội dung tài liệu Bảo trì phần mềm - Phần III: Các vấn đề then chốt trong bảo trì phần mềm, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
11 BẢO TRÌ PHẦN MỀM PHẦN III – CÁC VẤN ĐỀ THEN CHỐT TRONG BTPM Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 2 Nội dung  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ì Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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:  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 25 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ì. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 39 Tính có thể bảo trì  Định nghĩa  [IEEE] Tính có thể bảo trì (maintainability) là sự dễ 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.  [ISO/IEC] Tính có thể bảo trì là một trong các đặc điểm của chất lượng. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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:  Các quy trình có hệ thống và trưởng thành.  Các kỹ thuật, công cụ. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 12 Bố trí nhân sự  Sự phân cấp các nhu cầu của con người Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 413 Bố trí nhân sự  Những yêu cầu đối với nhân sự bảo trì  Phải xử lý những vấn đề mà các nhà phát triển chưa bao giờ nhìn thấy.  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 trước sự thay đổi.  Kiên trì và có kỹ năng cao để lần tới tận gốc của vấn đề; để 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 14 Bố trí nhân sự  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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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ý. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 517 Chọn nhóm bảo trì  Trách nhiệm bảo trì phần mềm sẽ được giao cho:  Nhóm phát triển ra chính sản phẩm hoặc  Một nhóm riêng biệt không phải là nhóm phát triển. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 18 Chọn nhóm bảo trì  Những thuận lợi khi giao nhiệm vụ bảo trì cho 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 19 Chọn nhóm bảo trì  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 20 Chọn nhóm bảo trì  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 621 Chọn nhóm bảo trì  Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm bảo trì  Việc chuyển giao hệ thống bị chậm.  Cần những huấn luyện quan trọng.  Cần thời gian để hiểu hệ thống.  Cần thời gian để thiết lập tổ chức bảo trì và các phương tiện.  Có thể có các vấn đề về tài chính.  Có thể chất lượng của sự hỗ trợ từ người dùng kém. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 22 Chọn nhóm bảo trì  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 23 Gia công 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 chính.  Những thách thức chính với người gia công:  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.  Mất một khoảng thời gian để đánh giá phần mềm trước khi tiến hành ký kết hợp đồng.  Gặp thách thức trong việc tiếp nhận sự chuyển giao phần mềm.  Cần một khoản đầu tư ban đầu cho cơ sở hạ tầng, thiết lập quy trình, Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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  Kích thước  Độ phức tạp  Chất lượng  Tính dễ hiểu  Tính có thể bảo trì Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 725 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 26 Các thực thể có thể đo Tài nguyên bảo trì Quy trình bảo trì Sản phẩm bảo trì -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 tuân theo tạo ra Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 28 Các thực thể có thể đo  Đo tài nguyên  Thực hiện ước lượng: công sức, số nhân công và ngân sách  Hai phương pháp ước lượng phổ biến nhất trong BTPM là:  Dựa vào kinh nghiệm  Dùng các mô hình thông số Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 829 Các thực thể có thể đo  Đ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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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) Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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  Đếm số dòng lệnh  Tính số điểm chức năng  Tính số điểm đặc trưng  Tính số trường hợp sử dụng  Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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ế:  Không có chuẩn nào cho phép đo LOC và phụ thuộc vào ngôn ngữ lập trình được sử dụng.  Quá đơn giản và không phản ánh được chi phí hay năng suất. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 933 Đ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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 34 Đo độ phức tạp  Chương trình càng phức tạp thì bảo trì viên càng có khả năng gây ra lỗi khi thực hiện một thay đổi.  Giá trị độ phức tạp càng cao, việc hiểu chương trình càng khó và vì thế khả năng có thể bảo trì càng thấp.  Độ phức tạp có thể được sử dụng để dự đoán công sức cần để tạo ra sự thay đổi cho chương trình.  Hai phép đo phổ biến nhất đo độ phức tạp của mã lệnh:  Phép đo của McCabe  Phép đo của Halstead Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 35 Đo độ phức tạp  Phép đo độ phức tạp của McCabe  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 trình. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 36 Đo độ phức tạp  Phép đo độ phức tạp của Halstead Phép đo ảnh hưởng đến độ phức tạp:  Nỗ lực của chương trình 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 10 37 Đo độ phức tạp  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ì:  Chúng dễ tính và không cần sự phân tích sâu các tính năng lập trình và dòng điều khiển  Có thể được áp dụng cho bất cứ ngôn ngữ nào  Tuy nhiên phép đo này chỉ dựa trên mã lệnh và mà 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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ì. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 39 Đo chất lượng  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 40 Đo chất lượng  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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 11 41 Đo chất lượng  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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ử Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần 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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 12 45 Đo chi phí  Sẽ được trình bày chi tiết ở phần ước lượng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 48 Các mối quan hệ cần lưu ý  Mối quan hệ chi phí bảo trì phần mềm và các thành phần trong khung làm việc của bảo trì phần mềm Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 13 49 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 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)Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 14 53 Mô hình đ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ó thể nhận dạng bởi người sử dụng trong phạm vi ứng dụng và được cập nhật thông qua EI.  EIF là một nhóm các dữ liệu có liên quan về mặt logic chỉ được sử dụng cho mục đích tham khảo. Dữ liệu nằm ở bên ngoài phạm vi ứng dụng và được cập nhật bởi EI của các ứng dụng khác. Nó được lưu trữ trong tập tin.  EI là một tiến trình căn bản trong đó dữ liệu được truyền từ bên ngoài vào bên trong phạm vi của ứng dụng. Dữ liệu có thể là thông tin điều khiển hoặc thông tin nghiệp vụ (thông qua màn hình nhập liệu hoặc từ một ứng dụng khác). Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 54 Mô hình điểm chức năng  Các loại điểm chức năng  EO là một tiến trình căn bản trong đó dữ liệu phát sinh được truyền từ bên trong ra bên ngoài phạm vi ứng dụng. Nó có thể là các báo cáo hay các tập tin kết xuất được gửi cho ứng dụng khác và được tạo ra từ những thông tin có trong một hay nhiều ILF hoặc EIF. (Dữ liệu phát sinh thường là kết quả của các giải thuật hay sự tính toán.)  EQ là một tiến trình căn bản có hai chiều nhập dữ liệu và xuất dữ liệu nhằm truy xuất dữ liệu từ một hay nhiều ILF/EIF. Dữ liệu nhập không cập nhật ILF/EIF và dữ liệu xuất không phải là dữ liệu phát sinh. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 55  Các thành phần cơ bản  FTR (File Type Referenced) là một loại tập tin được tham khảo bởi một xử lý. FTR phải là một ILF hoặc EIF.  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. Mô hình điểm chức năng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 56  Tính số điểm chức năng thô (chưa được cân đối) UFP = a1 x EI + a2 x EO + a3 x EQ + a4 x ILF + a5 x EIF với a1, a2, a3, a4, a5 là giá trị các điểm chức năng theo độ phức tạp cho trong bảng sau. Mô hình điểm chức năng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 15 57  Tính số điểm chức năng được cân đối Số điểm chức năng được cân đối cho các hoạt động thêm mới 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 ) Số điểm chức năng được cân đối cho các hoạt động sửa đổi Số điểm chức năng thô (hiệu chỉnh) x (0.65 + 0.01 x Tổng các mức độ ảnh hưởng của các hệ số kỹ thuật )  Ước lượng số dòng lệnh LOC LOC = AVC * số điểm chức năng được cân đối (thêm mới + sửa đổi) với AVC: yếu tố phụ thuộc vào ngôn ngữ lập trình được sử dụng Mô hình điểm chức năng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 58 8. Cập nhật trực tuyến 9. Xử lý phức tạp 10. Tính có thể tái sử dụng 11. Dễ cài đặt 12. Dễ vận hành 13. Đa nơi 14. Thay đổi thuận tiện 14 hệ số kỹ thuật 1. Giao tiếp dữ liệu 2. Chức năng phân tán 3. Sự thực thi 4. Cấu hình phụ thuộc 5. Tỷ lệ giao dịch 6. Nhập dữ liệu trực tuyến 7. Hiệu suất của người dùng cuối 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 (cực kỳ quan trọng hay cần thiết tuyệt đối hay ảnh hưởng nhất) Mô hình điểm chức năng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 59 Bảng xác định giá trị AVC cho một số NNLT Mô hình điểm chức năng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 60  Đo kích thước bảo trì phần mềm Trong đó:  Base code size: Kích thước mã lệnh cơ sở  MCF (Maintenance Change Factor): Hệ số thay đổi bảo trì. Nó được tính theo công thức:  Size Added: Kích thước mã lệnh được thêm vào  Size Modified: Kích thước mã lệnh được sửa đổi. Mô hình COCOMO II Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 16 61  MAF (Maintenance Adjustment Factor): Hệ số điều 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 Mô hình COCOMO II Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 62  SU (Software Understanding): Sự hiểu biết về phần mềm (theo tỷ lệ %) Mô hình COCOMO II Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 63  UNFM (Programmer Unfamiliarity): Mức độ không biết rõ của lập trình viên. Mô hình COCOMO II Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 64 Mô hình COCOMO II  Công sức bảo trì phần mềm  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 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 17 65  Bảng các hệ số tỷ lệ SF Mô hình COCOMO II Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 66 Mô hình COCOMO II  Bảng bội số công sức EM Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 67 Lưu ý  Ước lượng chi phí bảo trì bằng kinh nghiệm  Dưới dạng đánh giá của chuyên gia dựa vào sự tương tự và cấu trúc phân chia công việc  Là phương pháp được sử dụng để hoàn chỉnh kết xuất từ mô hình thông số nhằm đạt được một dự đoán.  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. Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 68 ILF EIF EI EO EQ Tham khảo: Cách tính giá trị các loại điểm chức năng Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ 18 69 HẾT PHẦN III Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ

Các file đính kèm theo tài liệu này:

  • pdfbao_tri_phan_mem_phan_iii_cac_van_de_then_chot_trong_bao_tri_phan_mem_6454.pdf
Tài liệu liên quan