Một số kỹ thuật ước lượng dự án và đánh giá phần mềm

Việc ước lượng dự án phần mềm không phải là một khoa học chính xác, nhưng tổ hợp các dữ liệu lịch sử tốt kết hợp với việc sử dụng các kỹ thuật ước lượng có thể cải thiện độ chính xác của

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

MỤC LỤC

MỞ ĐẦU 5

CHƯƠNG 1 TỔNG QUAN VỀ ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM VÀ ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM 7

1.1 Ước lượng dự án phần mềm 7

1.1.1 Ước lượng kích cỡ (LOC & FP) 9

1.1.2 Ước lượng công sức 12

1.1.3 Ước lượng về tài nguyên 14

1.2 Đánh giá chất lượng phần mềm 16

1.2.1 Các nhân tố chất lượng phần mềm 16

1.2.2 Đánh giá thông qua tính đúng đắn 19

1.2.3 Đánh giá thông qua tần suất bảo trì 19

1.2.4 Đánh giá thông qua tính toàn vẹn 20

1.2.5 Đánh giá dựa trên khả năng tiếp cận người dùng 20

CHƯƠNG 2 KỸ THUẬT ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM 21

2.1 Phương pháp Function Points 21

2.1.1 Giới thiệu 21

2.1.2 Tính hay ước tính 23

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

2.1.4 Các bước thực hiện 29

2.1.5 Thí dụ áp dụng phương pháp Function Points 36

2.2 Phương pháp Use Case Points 37

2.2.1 Giới thiệu về phương pháp UCP 37

2.2.2 Vai trò của biểu đồ Use Case trong ước lượng phần mềm 38

2.2.3 Các bước thực hiện với phương pháp ước lượng UCP 40

2.2.4 Thí dụ áp dụng phương pháp UCP 45

2.3 Các mô hình ước lượng dự án phần mềm 47

2.3.1 Tổng quan về các mô hình ước lượng kinh nghiệm 47

2.3.2 Mô hình ước lượng COCOMO (Contructive Cost Model) 48

2.3.3 Mô hình ước lượng Putnam 87

2.4 Công cụ ước lượng tự động 89

CHƯƠNG 3 KỸ THUẬT ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM 92

3.1 Độ đo chất lượng phần mềm 92

3.2 Khoa học phần mềm của HALSTEAD 93

3.3 Đo độ phức tạp của Thomas McCabe 95

3.4 Độ tin cậy phần mềm 96

3.5 Cách tiếp cận bảo đảm chất lượng phần mềm 97

CHƯƠNG 4 PHÁT TRIỂN CHƯƠNG TRÌNH ỨNG DỤNG 100

4.1 Mục tiêu 100

4.2 Tóm lược cơ sở khoa học 100

4.2.1 Các bước tính Function Points trong chương trình 100

4.2.2 Các bước tính Use Case Points trong chương trình 104

4.3 Cài đặt 105

KẾT LUẬN 108

TÀI LIỆU THAM KHẢO 109

PHỤ LỤC 110

DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT

COCOMO Contructive Cost Model

KSLOC Thousand of Source Line Of Code

IFPUG Internatinal Function Point Users Group

FPA Function Point Analysis

ILF Internal Logical File

ELF External Logical File

SQA Software Quality Assurance

SMPEEM Mô hình đánh giá nỗ lực dự án bảo trì phần mềm SMI Chỉ số chín muồi phần mềm

TCF Technical Complex Factor

UUCP Unadjusted Use Case Point

UAW Unadjusted Actors Weight

UUCPW Unadjusted Use Case Point Weight

UFP Unadjusted Function Points

VAF Value Adjustment Factor

WBS Work Breakdown Structure

MỞ ĐẦU

Mặc dù việc nghiên cứu về các chủ đề này đã được quan tâm nhiều trên thế giới, nhưng ở Việt Nam các nghiên cứu và ứng dụng chỉ mới ở bước đầu Thực vậy, nhu cầu ước lượng tốt dự án phần mềm để tránh rủi ro là vấn đề bức xúc của các công ty sản xuất phần mềm, tổ chức thực hiện dự án phần mềm Việc định giá cho phần mềm cũng vậy, cần có sự đánh giá chính xác dựa trên chất lượng thực tế của phần mềm

Tiến trình quản lý dự án kỹ nghệ phần mềm bắt đầu với một tập các hoạt

động gọi chung là lập kế hoạch dự án Hoạt động đầu tiên trong những hoạt động

này là ước lượng Người lập kế hoạch dự án phần mềm phải ước lượng ba điều trước khi một dự án bắt đầu: dự án kéo dài bao lâu, cần bao nhiêu nỗ lực và bao nhiêu người cần tham gia Bên cạnh đó, người lập kế hoạch phải dự kiến các tài nguyên (phần cứng và phần mềm) sẽ cần tới và rủi ro trong dự án Như vậy, khi một

dự án phần mềm được lập kế hoạch, cần phải đưa ra những ước lượng về công sức con người cần có, thời hạn dự án theo ngày tháng và chi phí của dự án Những việc này được tiến hành như thế nào? Trong nhiều trường hợp ước lượng được thực hiện bằng cách dùng kinh nghiệm qúa khứ xem như hướng dẫn duy nhất Nếu một dự án mới rất giống về kích cỡ và chức năng với một dự án quá khứ thì rất có thể dự án mới sẽ đòi hỏi xấp xỉ khối lượng công sức, mất một khoảng thời gian, chi phí như

dự án cũ Nhưng điều gì sẽ xảy ra nếu dự án mở ra một “miền đất mới” Khi đó chỉ riêng kinh nghiệm quá khứ có thể không đủ [4]

Ngày nay, phần mềm là yếu tố tốn kém nhất trong nhiều hệ thống dựa trên máy tính Lỗi lầm ước lượng chi phí lớn có thể tạo ra sự chênh lệch giữa lợi nhuận

và thất thoát Việc bội chi có thể là thảm hoạ cho người phát triển

Để giải quyết vấn đề trên, đã có rất nhiều kỹ thuật ước lượng được nghiên cứu và ứng dụng rộng rãi trong ngành công nghiệp phần mềm Mặt khác, để ước lượng dự án được chính xác, đòi hỏi phải dùng ít nhất hai trong các kỹ thuật để kiểm tra chéo Bằng cách so sánh và điều tiết các ước lượng được suy ra khi dùng các kỹ thuật khác nhau, người lập kế hoạch có thể suy ra một ước lượng chính xác Việc ước lượng dự án phần mềm không phải là một khoa học chính xác, nhưng tổ hợp các dữ liệu lịch sử tốt kết hợp với việc sử dụng các kỹ thuật ước lượng có thể cải thiện độ chính xác của ước lượng

Vấn đề “nóng” thứ hai đang được quan tâm là đánh giá phần mềm, vì đây là

cơ sở chính xác để đưa ra giá thành của phần mềm cũng như để phân biệt các tổ chức sản xuất phần mềm cạnh tranh trên một sản phẩm cùng loại Khác với việc

ước lượng dự án phần mềm (được tiến hành trong khoảng thời gian giới hạn lúc bắt đầu dự án phần mềm, và được cập nhật đều đặn trong tiến trình dự án) việc đánh giá phần mềm được tiến hành khi phần mềm đã được mã hoá và được cập nhật sau một thời hạn nhất định khi phần mềm được đưa vào sử dụng Để đánh giá phần mềm, một tập các kỹ thuật cũng được phát triển và ý nghĩa hơn, từ những nghiên cứu về chất lượng cũng như cách đánh giá nó, quy trình đảm bảo chất lượng cho phần mềm

đã được xây dựng

Mục đích của luận văn này không nằm ngoài việc nghiên cứu đầy đủ các kỹ thuật ước lượng phổ biến, các cách đánh giá chất lượng phần mềm hiện có và xây dựng một công cụ ước lượng tự động có thể áp dụng trong thực tế Nội dung luận văn chia thành ba phần, phần đầu (chương 1) đưa ra tổng quan về ước lượng dự án phần mềm và đánh giá chất lượng phần mềm trong quản lý dự án phần mềm, trên cơ

sở đó, phần hai (chương 2 và 3) đi sâu vào các kỹ thuật ước lượng và kỹ thuật đánh giá cụ thể, phần cuối cùng (chương 4) dựa trên những nghiên cứu thu được, phát triển một công cụ ước lượng tự động dùng để ước lượng công sức và ngày công cho

dự án phần mềm./

 Trì hoãn việc ước lượng tới giai đoạn sau của dự án (hiển nhiên chúng ta có thể đạt được ước lượng chính xác 100% khi dự án đã hoàn tât);

 Dùng các kỹ thuật phân rã để sinh ra ước lượng về chi

Ba tuỳ chọn còn lại là những cách tiếp cận có thể đứng được tương đối đối với ước lượng dự án phần mềm Một cách lý tưởng, các kỹ thuật được lưu ý cho từng tuỳ chọn nên được áp dụng nối tiếp nhau, mỗi tuỳ chọn được dùng như một

phép kiểm tra chéo cho tuỳ chọn khác Các kỹ thuật phân rã lấy quan điểm „chia để

trị‟ cho việc ước lượng dự án phần mềm Bằng cách phân rã một dự án thành các chức năng chính và các nhiệm vụ kỹ nghệ phần mềm có liên quan, việc ước lượng

chi phí và nỗ lực có thể được thực hiện theo kiểu từng bước Các mô hình ước

lượng theo kinh nghiệm có thể được dùng để bổ sung cho các kỹ thuật phân rã và

đưa ra một cách tiếp cận ước lượng tiềm năng có giá trị theo đúng nghĩa của nó Một mô hình dựa trên kinh nghiệm (dữ liệu lịch sử) có dạng:

d = f(vi) d: là một trong một số các giá trị ước lượng (như công sức, chi phí, thời hạn

dự án )

vi: các tham biến độc lập được chọn lựa (LOC hoặc FP được ước lượng)

Có các công cụ ước lượng tự động cài đặt cho một hay nhiều kỹ thuật phân rã (hay mô hình kinh nghiệm) Khi được tổ hợp với một giao diện người-máy tương tác, các công cụ tự động hoá đưa ra một tuỳ chọn cho việc ước lượng Trong một hệ thống như vậy, các đặc trưng của tổ chức phát triển (như kinh nghiệm, môi trường…) và phần mềm cần phát triển sẽ được mô tả Các ước lượng chi phí và nỗ lực được suy ra từ dữ liệu này [4]

Một dự án khi được thực hiện hoặc lập kế hoạch sẽ cần phải đánh giá được

độ lớn của nó, các tài nguyên cần thiết, lịch thực hiện và các cột mốc quan trọng như: gửi tài liệu, bắt đầu kiểm thử, bàn giao Thông thường thì giá thành và lịch trình thực hiện của một dự án thường mang tính rủi ro nhất do không được đánh giá đúng mức Một số trong các những lý do đó là:

 Giá thành và lịch trình thường được quyết định trước bởi các đối tượng ngoài

dự án như: khách hàng, chủ đầu tư…;

 Công việc phân tích thiết kế không phải bao giờ cũng bao quát hết các trường hợp, tình huống, các yêu cầu chưa được hiểu hết, hiểu đúng;

 Thường thì khách hàng không hiểu được việc phát triển phần mềm là một công việc có tính công nghệ cao với giá thành cao

Quy trình ước lượng chi phí phần mềm dưới đây mô tả các bước cần thiết cho việc bắt đầu đánh giá một vòng đời phần mềm và sau đó là theo dõi, tinh chỉnh những đánh giá xuyên suốt thời gian thực hiện dự án Thiết lập quy trình này càng sớm sẽ giúp cho việc đánh giá được chính xác hơn, tin cậy hơn, từ đó có thể xác định

rõ ràng các nhân tố liên quan tới giá thành của dự án Quy trình này cũng đồng thời cung cấp các phương pháp cho dự án cách thức quản lý các rủi ro liên quan tới chi phí và lịch trình dự án

Quy trình ước lượng là một quá trình liên tục, được thực hiện không ngừng trong thời gian thực hiện dự án Các hoạt động của nó bao gồm:

5 Đánh giá rủi ro;

6 Kiểm tra / xác nhận;

7 Theo dõi và báo cáo về tiến độ;

8 Đánh giá và cải tiến quy trình

Các hoạt động ước lượng kích cỡ, nỗ lực và chi phí cần được thực hiện trước khi xây dựng vì thứ tự trên là bắt buộc trong tất cả các mô hình tính toán giá thành Tuy nhiên việc xây dựng lịch trình thường được bắt đầu thực hiện trước khi hoàn thành tất cả công việc xác định các nỗ lực Ngoài ra, việc sớm thiết lập bảng cấu trúc phân việc (Work Breakdown Structure - WBS) giúp việc phân chia các nỗ lực

ra các phần việc độc lập mà có thể lập lịch hoặc xét mức độ ưu tiên xem thực hiện phần việc nào trước

1.1.1 Ƣớc lƣợng kích cỡ (LOC & FP)

Kích cỡ của phần mềm thường được đánh giá bằng đại lượng số lượng dòng

mã (Source Lines of Code - SLOC) hoặc số nghìn dòng mã (Thousands of Source

Ước lượng kích cỡ Ước lượng nỗ lực/chi phí

Ước lượng lịch trình

Ước lượng hệ thống máy tính

Quản lý rủi ro

Kiểm tra/xác thực Theo dõi, báo cáo về dự án

Đánh giá và cải tiến quy trình

(ít nhất 2 người cùng tham gia xây dựng )

Lines of Code - KSLOC) Phần mềm thường được phát triển theo cách viết mới hoàn toàn hoặc dùng một hay nhiều module có sẵn, do vậy việc ước lượng các đoạn

mã đã có cũng cần được quan tâm như việc ước lượng các đoạn mã mới cần viết thêm Việc tích hợp các module sẵn có và có vẻ đơn giản nhưng thực sự thì các nỗ lực dành cho nó cũng không kém so với việc phát triển mới từ đầu Kích cỡ cũng có thể được đánh giá qua đơn vị điểm chức năng (Function Points) Các điểm chức năng được đánh giá dựa trên chức năng của phần mềm và thường được áp dụng trong pha tìm hiểu yêu cầu Dòng mã (LOC – Line Of Code) và điểm chức năng (FP – Function Point) là những dữ liệu cơ sở để từ đó tính ra độ đo hiệu năng Dữ liệu LOC và FP được dùng theo hai cách trong việc ước lượng dự án phần mềm như:

(1) Các biến ước lượng được dùng để lấy “kích cỡ” cho từng phần tử phần mềm

(2) Độ đo vạch ranh giới được thu thập từ những dự án quá khứ và được dùng chung với các biến ước lượng để xây dựng các dự tính chi phí và công sức

Ước lượng LOC và FP là các kỹ thuật ước lượng phân biệt, nhưng cả hai đều

có một số đặc trưng chung Người lập dự án bắt đầu với một tuyên bố về phạm vi phần mềm, từ đó, dự định phân rã phần mềm thành các chức năng nhỏ hơn có thể được áp dụng riêng biệt LOC và FP sẽ được ước lượng cho từng chức năng con đó

Độ đo tính hiệu năng vạch ranh giới (như LOC/người-tháng hay FP/người-tháng) sau đó được áp dụng cho biến ước lượng thích hợp và ước lượng về chi phí và công sức từ đó được suy dẫn ra Các ước lượng chức năng con được tổ hợp lại để tạo ra một thiết kế ước lượng tổng thể cho toàn bộ dự án

Các ước lượng kỹ thuật LOC và FP khác nhau ở mức độ chi tiết cần cho việc phân rã Khi LOC được dùng như biến ước lượng thì việc phân rã chức năng thường được thực hiện cho các mức chi tiết đáng kể Vì dữ liệu cần cho việc ước lượng điểm chức năng ở mức vĩ mô hơn, nên mức độ phân rã được dùng khi FP là biến ước lượng sẽ ít chi tiết hơn Cũng cần lưu ý rằng LOC được ước lượng trực tiếp trong khi FP được xác định gián tiếp bằng cách ước lượng số cái vào, cái ra, tệp dữ liệu, câu hỏi, và giao diện ngoài kèm theo 14 giá trị điều chỉnh độ phức tạp sau:

Fi:

1 Hệ thống có đòi hỏi sao lưu và phục hồi không?

2 Có đòi hỏi trao đổi dữ liệu không?

3 Có chức năng xử lý phân tán không?

4 Có đòi hỏi cao về làm việc tốt không?

5 Hệ thống có chạy trong môi trường hiện có mà nặng về vận hành tiện ích không?

6 Hệ thống có đòi hỏi việc vào dữ liệu trực tuyến không?

7 Việc vào dữ liệu trực tuyến có đòi hỏi phải xây dựng thao tác đưa vào thông qua nhiều màn hình thao tác không?

8 Tệp chính có phải cập nhật trực tuyến không?

9 Cái vào, cái ra, tệp, truy vấn có phức tạp không?

10 Xử lý bên trong có phức tạp không?

11 Mã chương trình có được thiết kế để dùng lại không?

12 Việc chuyển đổi và cài đặt có được đưa vào trong thiết kế không?

13 Hệ thống có được thiết kế cho nhiều cài đặt trong các tổ chức khác nhau không?

14 Liệu ứng dụng có được thiết kế để làm thuận tiện cho việc thay đổi và dễ dàng cho người dùng không?

Bất kể là biến ước lượng nào được dùng, người lập kế hoạch dự án về cơ bản phải đưa ra một phạm vi các giá trị cho từng chức năng đã phân rã Bằng cách dùng

dữ liệu lịch sử hay trực giác, người lập kế hoạch ước lượng một giá trị LOC hay FP lạc quan, có thể nhất và bi quan cho từng chức năng

Giá trị kỳ vọng cho LOC hay FP sau đó được tính Giá trị kỳ vọng cho biến ước lượng, E, có thể được tính như trung bình trọng số của ước lượng LOC hay FP lạc quan (a), có thể nhất (m) và bi quan (b)

ta có thể tính độ lệch của ước lượng, tuy nhiên, độ lệch dựa trên một dữ liệu không chắc chắn (ước lượng) phải được dùng một cách thận trọng

Một khi giá trị kỳ vọng của biến ước lượng đã được xác định thì ta áp dụng dữ liệu hiệu năng LOC và FP Tại giai đoạn này, người lập kế hoạch áp dụng một trong hai cách tiếp cận khác nhau:

1 Giá trị biến ước lượng toàn bộ cho tất cả các chức năng con có thể được nhân lên với độ đo hiệu năng trung bình tương ứng với biến ước lượng đó Chẳng hạn, nếu ta giả sử rằng đã ước lượng 310 FP về tổng số và hiệu năng trung bình FP dựa trên các dự án quá khứ 5.5 FP/người-tháng thì tổng công sức cho dự án sẽ là:

Công sức =

5 5

310

= 56 người-tháng

2 Giá trị biến ước lượng cho từng chức năng con có thể được nhân lên với giá trị hiệu năng được điều chỉnh dựa trên một mức độ nhận biết được về độ phức tạp của các chức năng con Đối với các chức năng có độ phức tạp trung bình người ta dùng độ đo hiệu năng trung bình Tuy nhiên nó được điều chỉnh lên hay xuống dựa trên việc cao hơn hay thấp hơn độ phức tạp trung bình đối với chức năng con đăc biệt Ví dụ, nếu độ phức tạp trung bình

là 490 LOC/người-tháng, chức năng con phức tạp hơn đáng kể so với độ trung bình đó, có thể phản ánh một hiệu năng được ước lượng chỉ vào cỡ

300 LOC/người-tháng và chức năng đơn giản là 650 LOC/người-tháng Các ước lượng này có đúng không? Câu trả lời duy nhất cho câu hỏi này là: Chúng ta không thể chắc chắn được Mọi kỹ thuật ước lượng, dù phức tạp đến đâu cũng phải được kiểm tra chéo bằng các tiếp cận khác [4]

Giống như kỹ thuật LOC và FP, ước lượng công sức bắt đầu với việc phác hoạ các chức năng phần mềm thu được từ phạm vi dự án Một loạt các nhiệm vụ kỹ nghệ phần mềm - phân tích yêu cầu, thiết kế, mã hoá và kiểm thử - phải thực hiện cho từng chức năng

Hình 2 Phát triển ma trận công sức - chức năng

Người lập kế hoạch ước lượng công sức (người - tháng) sẽ cần để hoàn thành từng nhiệm vụ kỹ nghệ phần mềm cho từng chức năng phần mềm Những dữ liệu này chứa trong ma trận trung tâm của bảng Tỷ lệ lao động (chi phí/đơn vị công sức) được áp dụng cho từng nhiệm vụ kỹ nghệ phần mềm Rất có thể là tỷ lệ lao động sẽ thay đổi với mỗi nhiệm vụ Nhân viên cấp cao tham gia nhiều vào nhiệm vụ phân tích yêu cầu và thiết kế; nhân viên tập sự (thường lương thấp) tham gia vào các nhiệm vụ thiết kế về sau, mã hoá và kiểm thử

Chi phí và công sức cho từng chức năng và nhiệm vụ kỹ nghệ phần mềm được tính vào bước cuối Nếu ước lượng công sức được thực hiện độc lập với ước lượng LOC và FP thì bây giờ có hai ước lượng cho chi phí và công sức để so sánh và củng

cố Nếu cả hai tập các ước lượng này biểu lộ sự phù hợp hợp lý với nhau thì có lý

do vững chắc để tin rằng các ước lượng là tin cậy Mặt khác, nếu các kết quả của hai kỹ thuật phân rã này không chỉ ra sự phù hợp thì phải nghiên cứu thêm và phải tiến hành phân tích

Điều gì xảy ra khi thiếu sự phù hợp giữa các ước lượng? Việc trả lời câu hỏi

yêu cầu phải đánh giá lại thông tin đã dùng làm ước lượng Những ước lượng khác biệt lớn thường do hai nguyên nhân:

1 Phạm vi của dự án chức được người lập kế hoạch hiểu chưa thích đáng hoặc

bị hiểu sai

2 Dữ liệu hiệu năng được dùng trong kỹ thuật dòng mã là không thích hợp đối với ứng dụng hiện tại, đã lạc hậu hoặc đã bị hiểu sai

Người lập kế hoạch phải xác định được nguyên nhân của sự phân tán và củng

cố lại ước lượng

1.1.3 Ƣớc lƣợng về tài nguyên

Đầu tiên là việc ước lượng về tài nguyên Hình 3 mô tả các tài nguyên cần

có cho nỗ lực phát triển phần mềm Ở đáy là các công cụ - phần cứng và phần mềm

- phải có để hỗ trợ cho nỗ lực phát triển Ở mức cao hơn tài nguyên chính là con người - yếu tố bao giờ cũng cần tới Mỗi tài nguyên đều được xác định với bốn thuộc tính: mô tả tài nguyên, phát biểu về tính có sẵn, thời gian hạn định cần có tài nguyên, thời hạn tài nguyên cần được sử dụng Hai đặc trưng cuối có thể xem như cửa sổ thời gian

Hình 3 Tài nguyên

Tính sẵn có của tài nguyên đối với một cửa sổ phải được thiết lập ở giai đoạn thực hành sớm nhất

Công cụ phần cứng, phần mềm

- Ngày bàn giao

Tài nguyên con người

Người lập kế hoạch bắt đầu bằng việc ước lượng phạm vi và lựa chọn kỹ năng cần để hoàn thành việc phát triển Cả vị trí trong tổ chức (như người quản lý, kỹ sư phần mềm cấp cao…) và tính chuyên môn (như viễn thông, cơ sở dữ liệu, bộ vi xử lý) đều phải xác định rõ Với những dự án tương đối nhỏ (1 người-năm hay ít hơn) riêng một người có thể thực hiện tất cả các bước kỹ nghệ phần mềm, với việc tư vấn các chuyên gia cần thiết Số người cần cho dự án phần mềm có thể được xác định chỉ sau khi đã xây dựng được ước lượng nỗ lực phát triển (như người-tháng hay người-năm)

Tài nguyên phần cứng

Ngay từ đầu, chúng ta đã tham khảo tới phần cứng như là tiềm năng tính toán Bên trong vấn đề tài nguyên, phần cứng cũng là một công cụ cho việc phát triển phần mềm Có ba loại phần cứng cần phải được xem xét tới trong việc lập kế hoạch

dự án phần mềm: hệ thống phát triển, máy đích và các phần tử khác của hệ thống mới

Hệ thống phát triển (cũng được gọi là hệ thống chủ) là một máy tính và các thiết

bị ngoại vi có liên quan sẽ được dùng tới trong khi phát triển phần mềm Chẳng hạn, máy tính 32-bit có thể phục vụ như hệ thống phát triển cho một bộ vi xử lý 16-bit máy đích – trên đó phần mềm cuối cùng sẽ được thực hiện Hệ thống phát triển được dùng bởi vì nó có thể hỗ trợ cho nhiều người dùng, duy trì khối lượng thông tin lớn có thể dùng chung cho nhóm phát triển phần mềm, và hỗ trợ cho sự phân loại phong phú về công cụ phần mềm Vì phần lớn các tổ chức phát triển đều có nhiều vị trí đòi hỏi thâm nhập vào hệ thống phát triển nên người lập kế hoạch phải

mô tả cẩn thận cửa sổ thời gian cần thiết và kiểm chứng rằng tài nguyên có sẵn

Tài nguyên phần mềm

Như ta dùng phần cứng làm công cụ để xây dựng phần cứng mới, chúng ta dùng phần mềm để hỗ trợ cho việc phát triển phần mềm mới Bộ dịch hợp ngữ nguyên thủy đã được viết trong ngôn ngữ máy và được dùng để phát triển nhiều trình hợp dịch phức tạp Xây dựng trên khả năng của các phần mềm phiên bản trước, người phát triển cuối cùng được chuyển sang các trình biên dịch ngôn ngữ cấp cao và các công cụ khác Bất kỳ một thảo luận nào về tài nguyên phần mềm

cũng đều sẽ không đầy đủ nếu không thừa nhận về tính sử dụng lại - tức là việc tạo

ra và dùng lại các khối xây dựng phần mềm Các khối xây dựng như vậy phải được lên danh mục cho dễ tham khảo, phải được chuẩn hoá cho dễ ứng dụng và phải được làm hợp lệ cho việc tích hợp dễ dàng Các khối phần mềm sẽ có sẵn để cho phép việc xây dựng các chương trình lớn với việc phát triển từ „tay trắng‟ ở mức tối thiểu Thư viện các phần mềm tái dụng đã có cho các ứng dụng thương mại, các hệ

thống và công việc thời gian thực, các vấn đề khoa học và công nghệ Tuy nhiên, còn ít có các kỹ thuật hệ thống để bổ sung cho một thư viện, các giao diện chuẩn cho phần mềm dùng lại còn khó tăng cường, vấn đề chất lượng và bảo trì cần có còn chưa được giải quyết, và điều cuối cùng, người phát triển thường không biết rằng các khối xây dựng phần mềm đã có sẵn Người lập kế hoạch phần mềm nên xem xét tới hai quy tắc khi phần mềm dùng lại được xác định như một tài nguyên:

1 Nếu phần mềm hiện có đáp ứng được yêu cầu thì hãy dùng nó Chí phí để có được phần mềm hiện có gần như bao giờ cũng ít hơn chi phí để phát triển một phần mềm tương đương

2 Nếu phần mềm hiện có đòi hỏi phải có sửa đổi nào đó trước khi nó được tích hợp đúng đắn với hệ thống thì hãy xử lý cho cẩn thận Chí phí để sửa đổi phần mềm hiện có đôi khi có thể còn lớn hơn chi phí phát triển phần mềm tương đương

Trong thực tế, các tài nguyên phần mềm lại thường hay bị bỏ qua trong khi lập kế hoạch, chỉ trở thành mối quan tâm trong giai đoạn phát triển của tiến trình kỹ nghệ phần mềm Ta nên xác định yêu cầu tài nguyên phần mềm sớm, nhờ đó, việc đánh giá kỹ thuật cho các phương án có thể được tiến hành và thu được đúng hạn

1.2 Đánh giá chất lượng phần mềm

Đánh giá chất lượng phần mềm là một công việc khó khăn vì chất lượng phần mềm phụ thuộc vào nhiều yếu tố kể từ khi bắt tay vào xây dựng một phần mềm cho tới khi nó được bàn giao cho khách hàng và vẫn còn tiếp tục trong quá trình phần mềm đó được sử dụng

1.2.1 Các nhân tố chất lƣợng phần mềm

Các nhân tố chất lượng phần mềm được coi như những cái mốc để đánh giá

chất lượng phần mềm Các nhân tố chất lượng phần mềm được mô tả sau đây hội tụ vào ba khía cạnh quan trọng của sản phẩm phần mềm là: các đặc trưng vận hành, khả năng trải qua thay đổi, và tính thích nghi với môi trường mới Một sản phẩm phần mềm cần được xét theo các tiêu chuẩn dưới đây

Tính đúng đắn: Phần mềm thực hiện chính xác những mục tiêu và chức năng

đã đề xuất ở giai đoạn thiết kế Tính đúng đắn của phần mềm được xác minh qua những căn cứ sau:

1 Tính đúng đắn của thuật toán;

2 Tính tương đương của chương trình với thuật toán Thuật toán có thể đúng

nhưng chương trình lập ra không tương đương với thuật toán nên dẫn đến

kết quả sai Trong trường hợp này người ta nói rằng việc mã hoá bị sai;

3 Tính đúng đắn của chương trình có thể được chứng minh trực tiếp trong văn

bản của chương trình;

4 Tính đúng đắn của chương trình có thể được khẳng định dần dần qua việc

kiểm thử (testing), qua việc áp dụng chương trình trong một khoảng thời

gian đủ lớn trên một diện khá rộng với tần suất sử dụng cao;

5 Các tác giả của phần mềm cần cung cấp đầy đủ những luận chứng và kết

quả xác nhận tính đúng đắn của sản phẩm Những tài liệu đó bao gồm: Chương trình có kèm theo các luận đề phục vụ cho việc chứng minh, các phương pháp và kỹ thuật kiểm thử chương trình, các kết quả chạy thử, các giấy chứng nhận hay nhận xét của cá nhân đơn vị đã khảo sát và áp dụng

chương trình

Tính khoa học: Tính khoa học của sản phẩm được thể hiện qua những mặt sau

1 Khoa học về cấu trúc: Bản thân phần mềm được chia thành những đơn vị

cân đối, không trùng lập nhau về chức năng, có quan hệ hữu cơ với nhau, có thể tổ hợp thành nhiều chức năng mới Bản thân thuật toán và chương trình được thiết kế và cài đặt một cách có cấu trúc

2 Khoa học về nội dung: Các thuật toán dựa trên thành tựu mới của toán học

và tin học phải có cơ sở chặt chẽ

3 Khoa học về hình thức thao tác: Tên của các lệnh phải hợp lý, thể hiện tính

logic và phù hợp với tư duy tự nhiên của người dùng Ví dụ: một hệ thống biểu thị cả tiếng Anh, tiếng Việt lẫn lộn sẽ được xem là vi phạm tính khoa học về hình thức Trong trường hợp như vậy cách giải quyết tốt nhất là là thiết kế hai chế độ giao tiếp một bằng tiếng Anh, một bằng tiếng Việt Ví dụ: Các thông báo lỗi phải rõ ràng và bao gồm các chú giải sau: lỗi số mấy,

nội dung lỗi, nơi xảy ra lỗi, cách giải quyết

Tính hữu hiệu: Tính hữu hiệu của một sản phẩm được xác định qua những tiêu

chuẩn sau:

1 Hiệu quả kinh tế, ý nghĩa hoặc giá trị thu được do áp dụng sản phẩm đó;

2 Tốc độ xử lý của sản phẩm (v) tính bằng tỉ lệ giữa khối lượng đối tượng xử

lý (m) và tổng số đơn vị thời gian cần thiết để xử lý khối lượng trên (t): v=m/t;

3 Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác

định ua khối lượng tối đa của các đối tượng mà sản phẩm đó quản lý;

4 Dung lượng bộ nhớ mà tối đa trong RAM mà chương trình sử dụng;

Tính sáng tạo: Tính sáng tạo của sản phẩm phần mềm thể hiện qua các đặc

điểm sau:

1 Sản phẩm đó được thiết kế và cài đặt lần đầu tiên trên thế giới ;

2 Sản phẩm được sản xuất phục vụ cho những đặc thù riêng của Việt Nam Ví

dụ: bộ xử lý văn bản tiếng Việt, bộ chương trình nhận dạng các loại men gốm, hoa văn trang trí…;

3 Sản phẩm phần mềm có những điểm khác về mặt nguyên lý so với các sản

phẩm hiện hành;

4 Sản phẩm đó có những ưu thế nổi bật so với các sản phẩm cùng loại hiện

hành;

Tính an toàn: Sản phẩm trong trường hợp cần thiết có cơ chế bảo mật và

bảo vệ các đối tượng do nó phát sinh hay quản lý Bản thân sản phẩm cũng cần được đặt trong một cơ chế bảo mật nhằm chống sự sao chép trộm hoặc làm biến dạng sản phẩm đó

Tính toàn vẹn: Tính toàn vẹn của sản phẩm thể hiện qua những chức năng

sau:

1 Không gây ra nhập nhằng trong thao tác, đảm bảo tính nhất quán về cú pháp,

có cơ chế ngăn ngừa việc phát sinh ra những đối tượng sai quy cách hoặc mâu thuẫn với các đối tượng có sẵn (dữ liệu, đơn thể…);

2 Có cơ chế khôi phục lại toàn bộ hoặc một phần những đối tượng thuộc diện

quản lý của sản phẩm trong trường hợp có sự cố như hỏng máy, mất điện đột ngột…;

Tính đầy đủ: Tính đầy đủ của một sản phẩm được đánh giá thông qua tập

các chức năng mà sản phẩm đó cung cấp Tập các chức năng cần và nên thoả mãn các tính chất sau:

1 Tính đối xứng: Nếu có thao tác phát sinh thì nên có thao tác huỷ bỏ và ngược

lại Ví dụ: Một hệ thống quản lý các bảng điện tử đã có thao tác thêm một số cột vào bảng hiện có thì cần có thêm thao tác đối xứng là xoá một số cột từ bảng hiện có;

2 Tính tiêu chuẩn: Sản phẩm phần mềm cần đạt được một số tiêu chuẩn tối

thiểu được thừa nhận trên thị trường thế giới hoặc trong khoa học Ví dụ: một hệ quản lý tệp cần có các chức năng tối thiểu sau: Tạo các tệp, Huỷ bỏ các tệp, Sao chép các tệp, Tổ chức thư mục cho các tệp, Cập nhật dữ liệu vào tệp, Quản lý được nhiều loại tệp (tệp văn bản, tệp chương trình, tệp dữ liệu…), các lệnh thao tác tệp có thể hoạt động đơn lẻ nhưng cũng có thể

nhúng vào các ngôn ngữ lập trình cao cấp…

Tính độc lập: Sản phẩm phần mềm cần và nên đảm bảo tính độc lập với các

đối tượng sau:

1 Độc lập đối với thiết bị Sản phẩm có thể cài đặt dễ dàng trên nhiều loại máy

và có thể quản lý được nhiều thiết bị đi kèm với máy Những sửa đổi để thích nghi là không đáng kể;

2 Độc lập với cấu trúc của đối tượng mà sản phẩm đó quản lý Ví dụ: Một hệ

quản trị CSDL có tính độc lập cao sẽ không đòi hỏi người dùng phải viết lại chương trình ứng dụng khi chuyển từ việc quản lý các tệp tuần tự sang các tệp tuần chỉ và ngược lại;

3 Độc lập với nội dung của đối tượng mà sản phẩm đó quản lý Ví dụ: đơn thể

COPPY có thể sao chép các tệp không phục thuộc gì vào nội dung cụ thể của các tệp đó ra sao (rỗng hay không rỗng, lưu văn bản hay chương trình, lưu

mã nhị phân hay mã trung gian…)

Tính phổ dụng: Sản phẩm phần mềm có thể áp dụng cho nhiều lĩnh vực cho

nhiều chế độ làm việc khác nhau

Tính đơn giản: Sản phẩm có tính đến những yếu tố tâm lý sau đây của đông

1.2.2 Đánh giá thông qua tính đúng đắn

Một chương trình phần mềm phải vận hành đúng nếu không nó sẽ ít giá trị đối với người sử dụng Tính đúng đắn là mức độ mà các phần mềm thực hiện được chức năng được trông đợi ở nó Cách đo thông dụng nhất cho tính đúng đắn là số khiếm khuyết theo KLOC, với số khiếm khuyết được định nghĩa như việc thiếu tuân thủ theo yêu cầu đã được kiểm chứng Khiếm khuyết do người dùng báo cáo lại về chương trình sau khi đã được xuất xưởng để dùng đại trà và được tính theo từng thời kì chuẩn, điển hình là 1 năm

1.2.3 Đánh giá thông qua tần suất bảo trì

Việc bảo trì phần mềm ngốn nhiều công sức hơn bất kì hoạt động kỹ nghệ phần mềm nào khác Tính bảo trì được thể hiện thông qua một số yếu tố chính:

- Có thể chỉnh sửa được nếu phát sinh lỗi trong quá trình sử dụng;

- Có thể thích nghi khi môi trường thay đổi;

- Có thể nâng cấp được do yêu cầu cụ thể đặt ra

Tuy nhiên việc đo trực tiếp tính bảo trì là hoàn toàn không khả thi, do vậy phải dùng một cách đo gián tiếp Một khoảng thời gian trung bình được đề xuất cho mỗi phần mềm Khoảng thời gian này cần cho việc phân tích sự thay đổi yêu cầu, thiết kế sửa đổi thích hợp, cài đặt sự thay đổi và kiểm thử nó

1.2.4 Đánh giá thông qua tính toàn vẹn

Tính toàn vẹn của phần mềm được thể hiện bằng khả năng trụ được của nó đối với sự tấn công (cả ngẫu nhiên lẫn có chủ định) vào sự an toàn của nó Những

sự công kích có thể được tiến hành trên ba thành phần phần mềm:

- Chương trình;

- Dữ liệu;

- Tư liệu

Để đo tính toàn vẹn của một phần mềm cần xác định hai thuộc tính phụ:

- Sự đe doạ: “Đe doạ là xác suất để cho việc công kích sẽ xuất hiện trong thời gian đã nêu”;

- Độ an toàn: “Độ an toàn là xác suất rằng sự công kích sẽ bị đẩy lùi”

Cả hai thuộc tính đã nêu ở trên có thể được ước lượng hay suy dẫn từ kinh nghiệm

Ta có công thức về tính toàn vẹn như sau:

Tính toàn ven= [ 1-đe doạ (1-an toàn) ] 1.2.5 Đánh giá dựa trên khả năng tiếp cận người dùng

Sự thành công của một sản phẩm phần mềm phụ thuộc rất nhiều vào yếu tố

“thân thiện” đối với người sử dụng Dù cho phần mềm được xây dựng với rất nhiều tính năng có giá trị, tuy nhiên việc người dùng khó tiếp cận với phần mềm đó thì hậu quả tất yếu là phần mềm đó sẽ thất bại Tính “thân thiện”có thể được đo dưới bốn dạng đặc trưng:

- Kĩ năng vật lý (và/hoặc trí tuệ để học hệ thống);

- Thời gian cần thiết để người dùng tiếp cận hiệu quả với hệ thống;

- Sự tăng lên rõ rệt về mặt hiệu năng (so với cách tiếp cận mà hệ thống thay thế);

- Một xác nhận chủ quan (có thể thông qua bảng hỏi)

Bốn nhân tố ở trên chỉ là một cách lấy mẫu cho những điều đã được đề nghị

là cách đo cho chất lượng phần mềm

CHƯƠNG 2 KỸ THUẬT ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM

Phương pháp Function Points và Use Cases Points là hai phương pháp được

sử dụng rộng rãi nhất hiện nay để ước lượng nguồn lực cho việc phát triển một phần mềm

Function Point (FP) là phương pháp ước lượng được phát triển bởi Allan Albrecht và được ban bố rộng rãi vào năm 1979, cung cấp độ đo được ứng dụng chung và không phụ thuộc vào công nghệ được sử dụng cho việc phát triển phần mềm Function Point là một phương pháp chuẩn để tính kích thước phần mềm dựa trên việc phân tích các chức năng mà phần mềm đó phải thực hiện

Phương pháp Use Cases Points (UCP) là phương pháp do hãng Rational giới thiệu, dùng để xác định kích thước một phần mềm đặc biệt là đối với phần mềm dùng ngôn ngữ hướng đối tượng trong phân tích, thiết kế và xây dựng Trên thực tế

có một mối quan hệ giữa các use case và code vì các use case phức tạp thường sẽ tốn nhiều thời gian để code hơn UCP dựa trên việc xác định độ phức tạp của các Actor và các giao dịch trên mỗi Use Cases Các điểm mà phương pháp UCP quan tâm khi ước lượng kích thước phần mềm là:

 Số lượng và độ phức tạp của các Use case trong hệ thống;

 Số lượng và độ phức tạp của các Actor (thực hiện) trong hệ thống;

 Các yêu cầu non-functional khác như (ngôn ngữ lập trình, động lực của nhóm phát triển,…);

 Môi trường để phát triển hệ thống (ngôn ngữ lập trình, động lực của nhóm phát triển,…)

2.1.1 Giới thiệu

[2] Mô hình điểm chức năng được ra đời vào năm 1979 tác giả Allan Albrecht và năm 1984, Nhóm những người sử dụng điểm chức năng quốc tế (Internatinal Function Point Users Group – IFPUG) đã đưa ra cách rõ ràng các quy tắc, thiết lập các chuẩn cho việc sử dụng mô hình này Phân tích điểm chức năng (Function Point Analysis – FPA) cung cấp một phương pháp luận tiêu chuẩn cho việc ước lượng các chức năng của ứng dụng phần mềm FPA đo các chức năng từ quan điểm của người sử dụng, dựa chính vào các yêu cầu của người dùng Các điểm chức năng đạt được bằng việc đo những ứng dụng phần mềm từ hai dạng sau :

 Kích cỡ của các yêu cầu chức năng, được tính bằng cách gán trọng số cho mỗi chức năng đã rõ Sau đó ta tính được đại lượng Điểm chức năng chưa được hiệu chỉnh (Unadjusted Function Points – UFP) ;

 Tính đại lượng Nhân tố hiệu chỉnh giá trị (VAF – Value Adjustment Factor), nhân tố này phản ánh đặc tính của hệ thống phần mềm đang xây dựng chẳng hạn như độ phức tạp môi trường, độ phức tạp của ứng dụng hay ta còn gọi là các yêu cầu phi chức năng

Sự xuất hiện của kỹ thuật điểm chức năng đã cho phép cộng đồng công nghệ tin học - viễn thông gia tăng đáng kể khả năng áp dụng phép đo phần mềm so với việc sử dụng phương pháp dòng mã truyền thống Nhưng việc tính điểm chức năng đòi hỏi phải thực hiện một mức lập tài liệu mô tả hoàn thiện và chi tiết Có ít nhất hai tình huống mà trong đó phương pháp ước tính (một phương pháp tương thích nhưng có thể thay thế cho các quy tắc tiêu chuẩn đối với điểm chức năng) có thể có tính quyết định Trường hợp đầu tiên xảy ra khi một dự án phát triển hoặc tăng cường đang trong giai đoạn ban đầu mà đơn giản là không thể thực hiện phép tính điểm chức năng theo các tiêu chuẩn IFPUG (tức là trong nghiên cứu khả thi) Trường hợp thứ hai xảy ra khi cần ước tính tài sản phần mềm hiện có, nhưng không

có tài liệu hoặc thời gian cần thiết và nguồn lực để thực hiện phép tính điểm chức năng chi tiết Căn cứ trên những tình huống này và các tình huống tương tự, nhu cầu

về các phương pháp ước tính - không phải là tính - các điểm chức năng đã phát sinh

từ các tổ chức tham gia kinh doanh phần mềm Tài liệu kỹ thuật đưa ra một số phương pháp ước tính mà có thể được kiểm tra và so sánh Vì vậy, phần này trình bày các đặc điểm của một số phương pháp đáng chú ý (các điểm chức năng sớm, các mô hình ILF đem lại kết quả trái ngược) và cả mô hình đánh giá so sánh chung theo điểm chuẩn, hữu ích cho việc đánh giá các phương pháp bổ sung

FP - điểm chức năng: là thước đo kiểu hàm được sử dụng rộng rãi nhất, thích hợp cho việc xác định kính cỡ của ứng dụng phần mềm Nó dựa trên năm hàm lôgic

có thể được người sử dụng xác định, chia thành hai kiểu hàm dữ liệu và ba kiểu hàm giao dịch (bảng 1) Đối với một ứng dụng phần mềm đã cho, mỗi phần tử trong bảng này sẽ được xác định kích thước và mức độ quan trọng, có tính đến các phần

tử đặc trưng của nó, ví dụ các tham chiếu tệp hoặc các trường lôgic [2]

Bảng 1 Chỉ số độ phức tạp với số UFP tương ứng

Các số thu được (UFP - FP không điều chỉnh) được xếp vào các bộ hàm bổ sung, thay đổi hoặc xoá và được kết hợp với hệ số điều chỉnh giá trị (VAF) để thu

được số cuối cùng của FP Một công thức riêng cuối cùng được sử dụng cho từng kiểu tính: ứng dụng, dự án phát triển hoặc dự án tăng cường

2.1.2 Tính hay ƣớc tính

Nhìn chung, sự phân tích FP được coi là kỹ thuật xác định kích thước phần mềm sớm và hiệu quả Nhưng nếu xem xét các cách tính IFPUG tiêu chuẩn thì nó ngụ ý bao hàm một bộ tài liệu mô tả đầy đủ và chi tiết về những yêu cầu hàm của người sử dụng đối với ứng dụng bất cứ phần mềm cần được đo nào

Có ít nhất hai tình huống mà trong đó phương pháp ước tính (một phương pháp tương thích nhưng có thể thay thế cho các quy tắc tiêu chuẩn đối với FP) có thể có tính quyết định Trường hợp đầu tiên xảy ra khi một dự án phát triển hoặc tăng cường ở trong giai đoạn ban đầu mà đơn giản là không thể thực hiện phép tính

FP theo các tiêu chuẩn IFPUG (tức là trong nghiên cứu khả thi) Trên thực tế, việc tính tiêu chuẩn đòi hỏi phải xác định các phần tử, mà không phải luôn luôn có thể được xác định khi bắt đầu dự án, nhưng đó là khi mà yêu cầu dự báo công sức, thời gian và chi phí dựa trên sự ước tính kích thước chắc chắn sẽ lớn hơn so với vào lúc kết thúc giai đoạn xác định đặc điểm chức năng Trường hợp thứ hai xảy ra khi cần ước tính tài sản phần mềm hiện có, nhưng không có tài liệu hoặc thời gian cần thiết

và nguồn lực để thực hiện phép tính FP chi tiết.(2.1.1)

Ngoài quá trình đo tiêu chuẩn một cách chính xác, mà nên luôn luôn thực hiện khi có thể được, các phương pháp ước tính khác nhau đã được đề xuất để đáp ứng nhu cầu đánh giá kích thước của dự án phần mềm càng sớm càng tốt hoặc với việc sử dụng các nguồn lực càng ít càng tốt: "ước tính" có nghĩa là sử dụng ít thời gian và công sức hơn để thu được giá trị xấp xỉ của FP Những ưu điểm của kỹ thuật ước tính rõ ràng là đối lập với độ chính xác nhỏ hơn không thể tránh khỏi khi khảo sát các FP, nhưng khía cạnh này thường được bản thân những người sử dụng phương pháp tự đánh giá

Vì vậy, chúng ta cần luôn luôn phân biệt rõ giữa các thuật ngữ và khái niệm khác nhau: "Tính FP", có nghĩa là đo kích thước phần mềm bằng cách sử dụng các phương pháp IFPUG tiêu chuẩn như thông thường, trong khi đó "ước tính FP" có nghĩa là đánh giá gần đúng cũng kích thước đó nhờ các phương tiện khác

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

Các Chức năng trong mô hình

Mô hình FP xác định 5 kiểu chức năng cơ sở để ước lượng quy mô của phần mềm Hai kiểu chức năng dữ liệu là các file logic trong (ILF) và các file giao diện ngoài (EIF) và 3 kiểu chức năng giao tác còn lại là các dữ liệu đầu vào ngoài (EI),

dữ liệu đầu ra ngoài (EO) và các phần hỏi đáp ngoài (EQ)

Để lựa chọn mô hình FP, việc tính toán điểm chức năng của dự án duy trì và tăng cường phần mềm gồm 3 thành phần chức năng: (l) chức năng ứng dụng nằm

trong phần yêu cầu đối với người sử dụng trong dự án; (2) chức năng chuyển đổi; và (3) thừa số điều chỉnh giá trị (VAF)

Chức năng ứng dụng bao gồm các điểm chức năng được bổ sung, thay đổi và xoá bởi dự án bảo trì Chức năng chuyển đổi bao gồm các điểm chức năng được cấp phát bởi một quá trình chuyển đổi Thừa số điều chỉnh giá trị (VAF) dựa trên cơ sở

14 đặc tính trọng lượng Mức độ ảnh hưởng nằm trong khoảng từ 0 đến 5, từ không ảnh hưởng đến ảnh hưởng mạnh

Công thức cho tính toán điểm chức năng dự án bảo trì và tăng cường phần mềm được xác định như sau:

EFP = (ADD + CHG + CFP) x VAFa + (DEL x VAFb) (3.1) Trong đó, EFP điểm chức năng dự án tăng cường phần mềm, bổ sung (ADD), thay đổi (CHG), xoá bỏ (DEL)

Các điểm chức năng được tính toán như là chức năng ứng dụng và CFP có nghĩa là điểm chức năng không được điều chỉnh được bổ sung bởi quá trình chuyển đổi VAFa và VAFb thừa số điều chỉnh giá trị của ứng dụng tuần tự sau và trước dự

án

Các Counts điểm chức năng là một phép đo kích cỡ phần mềm ưu tiên phù hợp hơn so với các dòng mã lệnh Điểm chức năng hiện tại là kích cỡ chức năng đo được sử dụng thường xuyên nhất và nó tiếp tục đạt được sự gắn kết trong trường hệ thống thông tin quản lý và đã chứng tỏ thành công trong xây dựng các mô hình hiệu suất và dự toán chi phí dự án

Tuy nhiên, thừa số điều chỉnh giá trị (VAF) của mô hình này được giới thiệu nguyên bản cho một dự án phát triển phần mềm mới

Có một vài ví dụ về thừa số điều chỉnh giá trị (VAF) như là truyền đạt dữ

liệu, xử lý phân phối và thực thi, v.v Các thừa số này không thể áp dụng trong môi

trường bảo trì và không thể đo lường bằng cách nhìn khách quan [2]

Các thừa số hiệu suất về việc duy trì phần mềm

Nhìn chung, các chi phí bảo trì khó dự toán, bởi các chi phí này liên quan đến số lượng sản phẩm, quy trình và các thừa số tổ chức liên quan đến hiệu suất bảo

trì phần mềm

Một vài mô hình không phân biệt các thừa số hiệu suất của việc bảo trì phần mềm với các thừa số hiệu suất của phát triển phần mềm Tuy nhiên, các thừa số hiệu suất của bảo trì phần mềm khác với các thừa số hiệu suất của phát triển phần mềm

Bộ phận điều khiển chi phí duy trì lớn gắn liền với kích cỡ, tuổi thọ và tính phức tạp Sommerville quả quyết rằng các thừa số hiệu suất liên quan đến môi trường bảo trì phần mềm có thể bao hàm các đặc tính như là độc lập về module,

ngôn ngữ lập trình, kiểu lập trình

Trong năm 1985, từ những nghiên cứu về hiệu suất phần mềm (SPR) đã giới thiệu một cách mới trong tính toán các điểm chức năng Kỹ thuật nghiên cứu hiệu

suất phần mềm nhằm xử lý tính phức tạp là phải tách tính phức tạp tổng thể thành 3 phạm vi riêng biệt: Tính phức tạp thuộc về vấn đề, tính phức tạp mã và tính phức tạp dữ liệu Theo cách này, nỗ lực hoàn thiện các phép tính cũng có thể được giảm xuống

Các bảng câu hỏi trong quá trình nghiên cứu đã yêu cầu thu thập những thông tin về các đặc tình môi trường gồm cả các ràng buộc về kỹ thuật (thời gian đáp ứng, an ninh, số lượng người từ dụng, nền), dụng cụ và kỹ thuật bảo trì (phương pháp luận phát hiện, các dụng cụ tình huống) và các thừa số liên quan đến nhân sự (số lượng lập trình viên, kinh nghiệm) Trong các triển vọng của sản phẩm phần mềm, quy mô của cả hiểu biết về phần mềm và kiểm tra giao điện module có thể giảm xuống bởi kết cấu phần mềm tốt, bởi vì kết cấu dạng module và thứ bậc có thể giảm được số lượng giao diện cần kiểm tra

Vì vậy, các đặc tính khác nhau có ảnh hưởng đến hiệu năng phần mềm cần phải được gạn lọc

Mô hình đánh giá nỗ lực bảo trì dự án

Cách lựa chọn này diễn giải về mô hình đánh giá nỗ lực dự án bảo trì phần mềm (SMPEEM) Sau khi giới thiệu phương pháp, quy trình tính toán và điều chỉnh các điểm chức năng được giải thích Cuối cùng, các điểm chức năng đã được điều chỉnh được áp dụng trong đánh giá nỗ lực bảo trì phần mềm bằng cách sử dụng mô hình SMPEEM

Hình 4 Khái niệm SMPEEM được đề xuất

Tính toán trỏ

chức năng

Điều chỉnh trỏ chức năng

Đánh giá dự án bảo trì

Không được điều chỉnh Điểm

chức năng

Được điều chỉnh Điểm chức năng

Kiểu chức năng Giá trị trọng lƣợng theo tính phức tạp chức năng (W)

Bảng 2: Bảng tính toán điểm chức năng không được điều chỉnh

Một mô hình chức năng theo luật số mũ có thể đánh giá cần phải nỗ lực đến mức độ nào trong dự án bảo trì phần mềm

Tính toán các điểm chức năng

Các điểm chức năng với mỗi siêu loại ứng dụng cần phải được đếm để ước lượng quy mô của dự án bảo trì Có 3 kiểu loại duy trì ứng dụng như: Bổ sung, thay đổi và xoá bỏ Quy tắc đếm điểm chức năng được sử dụng như trong mô hình của tổ chức những người sử dụng điểm chức năng quốc tế (IFPUG)

Kỹ năng của kỹ sư Tri thức của miền ứng dụng

Hiểu biết ngôn ngữ lập trình Kinh nghiệm với phần mềm hệ thống (OS, DBMS)

KAD FPL ESS

Các đặc tính kỹ thuật Kết cấu của các module phần mềm

Độc lập giữa các module phần mềm Tính dễ thay đổi/đọc được của ngôn ngữ

CT

Có thể dùng lại các module phần mềm kế thừa

SSS ISM CRP RLS

Môi trường duy trì Cập nhật tài liệu

Tuân theo tiêu chuẩn kỹ thuật phần mềm

Dễ dàng thử nghiệm

DOC SES

TST

Bảng 3 Các thừa số điều chỉnh giá trị

Một kiểu loại bảo trì ứng dụng có thể nằm trong số 3 kiểu loại chức năng sau: ILF, EIF, EI, EO, hay EQ Mỗi kiểu loại này được đánh giá riêng biệt về tính phức tạp và được đưa ra những giá trị trọng lượng biến đổi từ 3 (đối với EIs đơn giản) đến 15 (đối với ILFs phức tạp) như được trình bày trong Bảng 2

Đếm chức năng không điều chỉnh (FC) được tính toán bằng cách nhân mỗi count thô với trọng lượng ước tính (W):

FC = SoLuongChu cNang W

cNang CacKieuChu

*

Trong đó, FC là điểm chức năng được đếm và W là giá trị đo trọng lượng phức tạp của mỗi kiểu loại chức năng

Điều chỉnh các điểm chức năng

Các thừa số điều chỉnh giá trị

10 thừa số điều chỉnh giá trị (VAFs) được bổ sung để sửa đổi Trong mô hình SMPEEM, 3 kiểu trong số các VAFs gồm: (1) kỹ sư được coi như là triển vọng của

"con người"; (2) tính kỹ thuật được coi như là triển vọng của sản phẩm; (3) các đặc tính môi trường bảo trì được coi như là triển vọng của quy trình

Nhóm đặc tính đầu tiên là kỹ năng của kỹ sư cần thiết cho bảo trì phần mềm, bao gồm 3 nhân tố như: Tri thức của miền ứng dụng, hiểu biết ngôn ngữ lập trình và kinh nghiệm đối với phần mềm hệ thống (OS, DBMS) Các nhân tố này mô tả mức

độ năng lực của nhân viên bảo trì Nếu miền ứng dụng được hiểu rõ, các yêu cầu của hệ thống có thể được phân tích dễ dàng Hơn nữa, các nhân tố kinh nghiệm ứng dụng, kinh nghiệm ngôn ngữ và công cụ và kinh nghiệm nền đo lường hiệu năng của COCOMO 2.0

Nhóm đặc tính kỹ thuật thứ hai chứa dựng 4 nhân tố, đó là: Cấu trúc của module phần mềm, tính độc lập của module phần mềm, tính dễ thay đổi/đọc được của ngôn ngữ chương trình và có thể dùng lại các module phần mềm kế thừa Các nhân tố này đại diện cho trạng thái của các module chương trình Khi phần mềm được bảo trì cấu trúc của nó bị suy biến Các nhân tố thời gian ứng dụng và tính có thể dùng lại được chấp nhận như là các chỉ tiêu đo hiệu năng bề mặt kỹ thuật của phần mềm

Nhóm đặc tính cuối cùng môi trường bảo trì bao gồm các nhân tố tính cập nhật tài liệu, tuân theo các tiêu chuẩn kỹ thuật phần mềm và dễ dàng thử nghiệm các nhân tố này liên quan nhiều hơn đến quy trình bảo trì Tài liệu phù hợp với các nhu cầu vòng đời; tính thuần thục của quy trình và dễ dàng thử nghiệm được tham chiếu như là các nhân tố hiệu năng để giảm chi phí bảo trì

Mười nhân tố này được lựa chọn tập trung vào triển vọng của các nhà quản

lý dự án bảo trì Nhằm điều chỉnh điểm chức năng sau khi đếm nó, như được trình bày trong Hình 4, một vài nhân tố liên quan đến các chỉ tiêu do quy mô của các dự

án bảo trì phải được loại trừ; chẳng hạn như, lưu lượng bảo trì, kích cỡ của hệ thống phần mềm hay cơ sở dữ liệu Bởi vì SMPEEM tập trung vào đánh giá các nỗ lực trong giai đoạn này, một vài nhân tố liên quan đến đo lường ước lượng sản lượng cũng phải được loại trừ: Ví dụ quy mô của các nỗ lực yêu cầu hay nhóm Một vài

nhân tố liên quan đến các đặc tính tổ chức bảo trì cho nguồn ra cũng có thể được loại trừ bởi chúng ta chỉ xem xét các dự án bảo trì nội bộ Chúng ta không tính đến các nhân tố liên quan đến công cụ bảo trì, bởi vì các tổ chức đáp ứng không sử dụng một công cụ bảo trì tự động nào

Phương pháp điều chỉnh

Điểm chức năng không điều chỉnh được nhân với thừa số điều chỉnh giá trị (VAF) để tạo ra điểm chức năng cuối cùng Trong mô hình SMPEEM, ba nhóm đặc tính trong số 10 VAFs có giá trị trọng lượng lần lượt cho mỗi nhóm và cho mỗi thừa

1 hom n

k

1 thuaso

)]

100

Wf ( ) 100

tyoxWf (

5000

d 2 ( ) 100

FP = FC x [0.80 + (0.008 x VAF)] (3.5)

Từ phương trình (3.5), chúng ta có các FPS được điều chỉnh có thể được dùng để tính toán nỗ lực bảo trì phần mềm ước lượng Trong trường hợp VAF =0, FP được tính bằng 80% các counts chức năng không được điều chỉnh

Ngược lại, VAF tối đa (50) cung cấp 120% các counts chức năng không được điều chỉnh tới các FPs cuối cùng

Vì thế, phương trình (3.4) cho chúng ta biết các FPs được điều chỉnh thông qua các dải điều chỉnh khác nhau

Đánh giá nỗ lực bảo trì dự án

Các mô hình ước lượng chi phí phần mềm thường có một thừa số theo luật số

mũ các tính toán các chỉ tiêu tiết kiệm hay không tiết kiệm liên quan về tỷ lệ khi một dự án phần mềm tăng quy mô Thừa số này nhìn chung được đại diện như số

T - thử nghiệm (df = 31)

95% khoảng tin cậy của chênh lệch

Trong đó, các hằng số a và b là các hệ số có thể được giới thiệu từ kết quả hồi quy

Do vậy, nếu FP và VAF bất kỳ dự án bảo trì nào được biết đến, nỗ lực bảo trì có thể được ước lượng theo phương trình (3.6)

2.1.4 Các bước thực hiện

[2] Phương pháp tính số điểm chức năng sử dụng phân tích điểm chức năng được thực hiện qua 5 bước dưới dây:

Bước 1 Phân loại

Phân loại chức năng

Công việc: phân loại các yêu cầu ứng dụng thành các loại chức năng khác nhau, xác

định độ phức tạp của nó và gán giá trị điểm chức năng

Phương pháp FPA phân loại các yêu cầu chức năng của ứng dụng thành năm loại, đó là:

Các chức năng về dữ liệu:

- Internal Logical Files (ILF) - Gồm các file logic được quản lý bởi ứng dụng,

ví dụ như các bảng của CSDL Khái niệm "file" ở đây cần cần được hiểu là một nhóm dữ liệu thường được truy cập cùng với nhau

- External Interface File (EIF) - Gồm các file của các ứng dụng khác được ứng dụng truy xuất đến Ví dụ như bảng nhân viên của hệ thống nhân sự bị truy xuất bởi

hệ thống kế toán, bảng nhân viên là EIF của hệ thống kế toán

Các chức năng về dữ liệu xét dữ liệu ở trạng thái tĩnh Chúng còn được gọi là

kiểu file được tham chiếu (FTR's)

Các chức năng về giao dịch:

- External Inputs (EI) - Là các chức năng nhập dữ liệu, có thể có ảnh hưởng đến một hay nhiều ILE Ví dụ: Nhập chứng từ Trong thực tế, một ứng dụng sẽ có một số lượng rất lớn EI Đây là cách để ứng dụng nhận thông tin hoặc thay đổi hành

vi

- External Outputs (EO) - Là các chức năng cung cấp dữ liệu cho người dùng, thông thường là các báo cáo nghiệp vụ

- External Inquiries (EQ) - Gồm các chức năng tra cứu, trợ giúp, v.v Các

chức năng này chỉ cung cấp thông tin chứ không làm thay đổi các file

Các chức năng về giao dịch xét dữ liệu ở trạng thái động

Mỗi yêu cầu của hệ thống, bao gồm cả các cấu trúc lưu trữ (ví dụ như các thực thể, các tiến trình, đầu ra hay truy vấn) thường được xác định ở giai đoạn đầu của cả tiến trình dự án thông qua quá trình đàm phán với khách hàng, phân tích yêu cầu

Truy vấn

Người dùng

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

là các tính năng mà ứng dụng cung cấp, nhìn từ quan điểm của người sử dụng

Hình 5 Phân loại chức năng

người sử dụng, hoặc do khách hàng cung cấp Các yêu cầu này sẽ đều có thể thuộc một trong năm loại chức năng ở trên

*Hướng dẫn phân loại chức năng:

- Tất cả các file hoặc bảng của CSDL của ứng dụng (kể cả bảng danh mục hay bảng giao dịch) mà yêu cầu Thêm mới/sửa/xóa, đều được coi là ILE, loại trừ các

file làm việc (work files) hay các file tạm trong quá trình tạo báo cáo v.v

- Tất cả các file hoặc các bảng của CSDL của các ứng dụng khác (thường là các file giao diện hoặc bảng) mà ứng dụng dang xét truy xuất đến được coi là các EIF Các ILF của các ứng dụng khác được sử dụng bởi hệ thống cũng được coi là các EIF của hệ thống

- Tất cả các thao tác mà chúng chấp nhận dữ liệu từ ngoài hệ thống vào được coi là EI Dữ liệu có thể là thông tin điều khiển hoặc thông tin tác nghiệp Nếu dữ

liệu là thông tin điều khiển, nó không nhất thiết phải cập nhật một ILF

- Tất cả các báo cáo nghiệp vụ được coi là EO Các EO không làm thay đổi đến các ILF Chúng là các dữ liệu được sinh ra và đưa ra ngoài phạm vi của ứng dụng

Chúng là các dữ liệu được sinh ra và đưa ra ngoài phạm vi của ứng dụng

- Tất cả các tiến trình có kết hợp cả dữ liệu Vào - Ra mà kết quả là dữ liệu được truy vấn ra và không làm thay đổi ILF được gọi là EQ Tất cả các truy vấn nghiệp vụ, trợ giúp cũng được coi là EQ

Để giúp phân biệt rõ ràng hơn giữa EO và EQ, IFPUG phiên bản 4.1 đã có một số thay đổi nhỏ trong cách xác định Đó là, nếu giao dịch có lấy về dữ liệu hoặc cập nhật một ILF thì nó được coi là một EO; nếu không, nó được coi là một EQ

Hướng dẫn xác định các tham số cần thiết cho việc đánh giá độ phức tạp Các tham số đó là:

- Loại bản ghi - Record Element Type (RET)

- Tệp dữ liệu được tham chiếu - File Type Referenced (FTR)

- Trường dữ liệu được tham chiếu - Data Element Type (DET)

Loại chức năng Các tham số Hướng dẫn

ILF và EIF Số loại bản ghi (RET) Đếm số loại bản ghi (RET)

Coi mỗi nhóm dữ liệu là một loại bản ghi Ví dụ:

Purchase Orders RET #1

Purchase Orders No, Data, Supplier Name, Order Value

RET #2 Item Code, Unit Of Measure, Quality Ordered, Rate, etc

RET #3 Item Code, Delivery Schedules

Số trường dữ liệu được tham chiếu (DET)

Đếm số trường dữ liệu được tham chiếu (DET)

Là trường duy nhất con người có thể nhận biết trong ILF không đếm các trường là khoá liên kết, không đếm lặp lại đối với các nhóm dữ liệu

EI Các file dữ liệu được

Số trường dữ liệu được tham chiếu (DEL) là những trường duy nhất

có thể nhận biết trong ILF, được cập nhật bởi

EI

Đếm DET Các trường dự liệu được nhập vàp mang một ý nghĩa nào đó về nghiệp

vụ được coi là một DET Không đếm các thông báo lỗi hoặc các thông báo nhắc trên màn hình Nếu các dữ liệu này được lưu trữ vật

lý tại nhiều nơi thì cũng chỉ coi như một DET

EO Các file dữ liệu được

tham chiếu (DET)

ILF hay EIF được đọc để hoàn thành

EO

Số trường dữ liệu được tham chiếu

Trường duy nhất xuất hiện trong EO

EQ Các file dữ liệu được

tham chiếu (EIF) Các ILF hoặc EIF được đọc

Đếm FTR Đếm các FTR vào và độc lập với nhau

Số trường dữ liệu được tham chiếu (DET)

Đếm các trường duy nhất xuất hiện trong EQ

Bảng 2.5: Hướng dẫn xác định các tham số cần thiết

Cách thức xác định độ phức tạp của một loại chức năng

Sau khi xác định các tham số để tính độ phức tạp: RETs, FETs, DETs của mỗi chức năng, sử dụng bảng đối chiếu để quyết định xem chức năng đó có độ phức tạp

là Thấp/Trung bình/cao Độ phức tạp của một chức năng được xác định từ việc kết hợp các thuộc tính của nó:

Độ phức tạp của ILF và ELF được xác định dựa trên các RET và DET

Độ phức tạp của EI, EO và EI được xác định dựa trên các RET và DET

Riêng trường hợp của EI phải xác định cả VàO và RA, sau đó lấy giá trị lớn nhất

Cách thức gán tổng UFP cho một chức năng

Dựa vào bảng 2.5 để gán tổng các điểm chức năng chưa điều chỉnh (UFP) cho mỗi loại chức năng dựa trên độ phức tạp của nó

Giá trị Function Point được gán cho các chức năng (dựa trên yêu cầu người sử dụng) thuộc các loại chức năng khác nhau sẽ được cộng lại để tính tổng UFP

UFP = Sum (FP của tất cả các loại chức năng)

Bước 3 Gán mức độ ảnh hưởng cho tất cả các đặc trưng chung của hệ thống

Các đặc trưng chung của hệ thống là các yếu tố ảnh hưởng đến độ phức tạp

của việc phát triển, các mục tiêu hiệu năng, cấu hình, độ thân thiện v.v Chúng

được phân thành 14 đặc trưng khác nhau và mức độ ảnh hưởng (DI) thuộc một

trong 3 loại: Có, Có nhưng ít và Không

Các đặc trưng chung của hệ thống (GSC)s là:

 Trao đổi dữ liệu - Data Communications;

 Xử lý dữ liệu phân tán - Distributed Data Processing;

 Tính năng – Performance;

 Cấu hình có tần suất sử dụng lớn - Eieavily Used Confguration;

 Tần suất giao dịch - Transaction Rate;

 Chấp nhận dữ liệu trực tuyến - Online Data Entry;

 Hiệu quả sử dụng của người dùng cuối - End User Efficiency;

 Cập nhật trực tuyến - Online Update;

 Xử lý phức tạp - Complex Processin ;

 Tính tái sử dụng – Reuseability;

 Cài đặt dễ dàng - lnstallation Ease;

 Thao tác dễ dàng - Operation Ease;

 Nhiều địa điểm - Multiple Site;

 Dễ thay đổi - Facilitate Change;

Với mỗi GSC, gán giá trị mức độ ảnh hưởng theo các mức:

0 - không có hoặc không ảnh hưởng;

Thông thường, các giá trị OI được gán như sau:

Gán 0 nếu như GSC là hoàn toàn không có, 3 nếu ảnh hưởng trung bình và 5 nếu ảnh hưởng nhiều Các trường hợp nghi ngờ khác gán giá trị 3

Bước 4 Tính các giá trị của các yếu tố điều chỉnh

Các yếu tố điều chỉnh (Value Adjustment Factor - VAF) được tính theo công thức:

VAF = 0 65 + 0 01 * (TDI)

Với TDI là tổng các giá trị DI của tất cả các yếu tố

Chú ý rằng giá trị VAL tính được sẽ nằm trong đoạn từ 0.65 đến 1.35 vì nếu

tất cả các yếu tố đều có giá trị DI = 5, tổng sẽ là 70 = (14*5) và VAF sẽ là 0.65

+0.01*70=1.35

Giá trị cực đại của VAF là 1.35

Tương tự, nêu như tất cả các yếu tố đều không ảnh hưởng, DI = 0 Khi đó,

VAF = 0.65 Giá trị lý tưởng là TDI = 35 và do đo VAF =1

Bước 5 Tính tổng FP của ứng dụng

FP = UFP * VAF

Các FP được tính toán dựa trên năm bước ở trên sẽ xác định kích thước của ứng dụng dưới góc độ chức năng mà nó cần phải có Tuy nhiên để biết được năng suất dưới dạng số FP/man-day, mỗi tổ chức phải sử dụng các số liệu thông kê từ các

dự án trên những môi trường tương tự trước đó Kích thước của dự án tính bằng FP

là một độ đo chung không kể đến yếu tố môi trường phát triển cũng như kinh nghiệm của nhóm phát triển [2]

Xuất dữ liệu (EO)

Số kiểu file tham chiếu (FTR) Số phần tử dữ liệu

Truy vấn ngoài (EQ)

Số kiểu file tham chiếu (FTR) Số phần tử dữ liệu

Các file logic trong (ILF)

Số kiểu file tham chiếu (FTR) Số phần tử dữ liệu

> = 6 RET Trung bình (10) Cao (15) Cao (15)

Các file giao tiếp ngoài (EIF)

Số kiểu file tham chiếu (FTR) Số phần tử dữ liệu

> = 6 RET Trung bình (7) Cao (10) Cao (10)

Bảng 2.6: Tham chiếu điểm cho các chức năng

2.1.5 Thí dụ áp dụng phương pháp Function Points

Trạm bán đồ uống tự động:

External Inputs=1 và ở mức Low External Output=1 và ở mức Average User Interactions=2 và ở mức High External interfaces File=3 và ở mức Low Files used by the system (Logical Internal File)=1 và ở mức High

Ta có được

Bây giờ hoàn tìm được FP dựa vào công thức sau:

FP= *[0.65+0.01*SUM(Fi)]

1-Hệ thống có yêu cầu sao lưu và khôi phục không ->Đơn giản (2)

2-Có yêu cầu trao đổi dữ liệu không->Bản chất (5)

3-Có chức năng xử lí phân bố không ->Trung bình (3)

4-Có đòi hỏi cao về vấn đề có làm việc tốt không-> Bản chất (5)

5-Hệ thống có chạy trong môi trường có nặng về vấn đề tiện ích không -> Bản chất (5)

6-Hệ thống có đòi hỏi việc vào dữ liệu trực tuyến không->Không ảnh hưởng (0)

7-Việc vào dữ liệu trực tuyến có đòi hỏi phải xây dựng thao tác đưa vào thông qua nhiều màn hình hay thao tác không->Không ảnh hưởng (0)

8-Tệp chính có phải cập nhật trực tuyến không ->Có ý nghĩa (4)

9-Cái vào, ra, tệp, truy vấn có phức tạp không-> Có ý nghĩa (4)

10-Xử lí bên trong có phức tạp không -> Có ý nghĩa (4)

11-Mã chương trình có được thiêt kế để dùng lại không -> Bản chất (5) 12-Việc chuyển đổi và cài đặt có được đưa vào trong thiết kế không -> Bản chất (5)

13-Hệ thống có được thiết kế cho nhiều cài đặt trong các tổ chức khác nhau không

Nhận xét:

* Ưu điểm của phương pháp Function Points

1 Độc lập với kỹ thuật & công cụ lập trình;

2 Dễ hiểu đối với người dùng;

3 Áp dụng được ngay trong giai đoạn đầu của chu trình phần mềm;

4 Áp dụng tốt cho các phầm mềm quản lí (MIS)

* Những khó khăn trong việc sử dụng phương pháp Function Points

1 Xác định mức độ ảnh hưởng của các nhân tố về đặc điểm của hệ thống: thực thế cũng không có một căn cứ nào để đặt trọng số cho các nhân tố này;

2 Phương pháp Function Points không cho thấy mức độ quan hệ giữa các chức năng trong hệ thống, thực tế hệ thống có các chức năng ít có quan hệ với nhau thì dơn giản hơn là hệ thống có mức độ quan hệ giữa các chức năng là phức tạp;

3 Đôi khi đánh giá một phần mềm khi nó đã được hoàn thành là không chính xác Khi có một số chức năng được thêm vào trong quá trình phát triển vì chức năng này sẽ làm ảnh hưởng làm chúng ta phải sửa đổi lại cả các chức năng khác…;

4 Không thích hợp cho các hệ thống thời gian thực, các hệ thống tính toán phức tạp, đánh giá độ phức tạp một cách chủ quan;

2.2 Phương pháp Use Case Points

Được giới thiệu bởi Gustav Karner năm 1993, được áp dụng cho những hệ thống thiết kế theo phương pháp hướng đối tượng, được phát triển từ phương pháp Function Points, sử dụng mô hình use case cho việc ước lượng công sức trong việc phát triển và kiểm thử phần mềm

Việc ướng lượng phần mềm có thể bắt đầu ngay khi một số vấn đề chính của

hệ thống hình thành

2.2.1 Giới thiệu về phương pháp UCP

Những ước lượng về chi phí và lịch biểu trong các dự án phần mềm thường dựa vào việc dự báo về kích cỡ của hệ thống trong tương lai Thật không may, phần mềm thường mang tiếng là thiếu chính xác trong việc ước lượng chi phí và lịch biểu Những ước lượng về nỗ lực thường bao hàm nhiều sự phần tử của tính không chính xác Những ước lượng ở giai đoạn sớm đảm bảo tin cậy thường khó đạt được

do nguyên nhân thiếu những thông tin chi tiết và đầy đủ về hệ thống phần mềm cần xây dựng trong tương lai ở giai đoạn đầu của dự án Tuy nhiên, những ước lượng chính xác và đầy đủ ở giai đoạn đầu của dự án có vai trò quan trọng cho việc thiết lập những hợp đồng hoặc xác định tính khả thi của dự án Những mô hình ước

lượng chi phí trước đây xem kích cỡ của phần mềm như là tham số đầu vào quan trọng và sau đó sử dụng một tập những nhân tố điều chỉnh để tính toán ước lượng

về tổng nỗ lực phát triển Khi phát triển phần mềm theo phương pháp hướng đối tượng, những Use Cases ( UCs) mô tả các yêu cầu chức năng của hệ thống Mô hình

UC vì vậy có thể được sử dụng để dự báo kích cỡ của những hệ thống phần mềm trong tương lai ở pha phát triển đầu tiên của hệ thống

Những mô hình ước lượng phần mềm như SLOC, COCOMO, COCOMO II, phương pháp xác định kích cỡ Function Point Analysis (FPA) đã được sử dụng rộng rãi và hiệu quả trong kỹ nghệ phần mềm, nhưng với những các tiếp cận này cũng còn hạn chế, việc đếm những điểm chức năng đòi hỏi kiến thức chuyên gia hỗ trợ

Bởi vì sự khó khăn của việc ước lượng theo phương pháp SLOC, FP, COCOMO… và những hệ thống hiện đại thường phát triển theo phương pháp hướng đối tượng sử dụng ngôn ngữ Unified Modeling Language (UML), năm 1993, Gustav Karner đã đưa ra phương pháp Use Case Points sử dụng để xác định kích cỡ

và ước lượng những dự án phát triển theo phương pháp hướng đối tượng Phương pháp này được mở rộng từ phương pháp phân tích điểm chức năng và phương pháp

Mk II FPA

Phương pháp ước lượng UCP tính toán nỗ lực phát triển phần mềm theo đơn

vị person – hours dựa vào biểu đồ UC nơi mô tả chính xác và nhất quán các yêu cầu chức năng của hệ thống Các UC được giả định rằng chúng được đưa ra từ một tập hỗn độn các chức năng, sau đó chi tiết và chuẩn hóa để có ít hơn 10 – 12 giao dịch Phương pháp UCP trước đây đã được sử dụng phổ biến trong một số dự án cỡ nhỏ Cho tới gần đây, cách tiếp cận phát triển phần mềm theo phương pháp tăng trưởng

và tiến hóa đang trở lên quan trọng Ta thấy rằng phương pháp UCP có những ưu điểm rất đáng kể, nhưng để có được những ước lượng chính xác ta cần phải xem xét tới những nhân tố ảnh hưởng như nhân tố kỹ thuật, nhân tố môi trường, sự phân loại các UC và tác nhân trong biểu đồ UC

2.2.2 Vai trò của biểu đồ Use Case trong ƣớc lƣợng phần mềm

Hiện nay, cách tiếp cận phát triển phần mềm hướng đối tượng đang được sử dụng phổ biến Ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language – UML) đang được sử dụng để thu thập yêu cầu phần mềm, phân tích, thiết kế và phát

triển phần mềm Biểu đồ UC là công cụ mạnh để thu thập yêu cầu hệ thống Biểu đồ

UC chỉ ra mối quan hệ giữa các tác nhân và các ca sử dụng trong hệ thống

Ca sử dụng: ca sử dụng (Use Case – UC) mô tả tập các hoạt động của hệ thống

theo quan điểm của các tác nhân (Actors) Nó mô tả các yêu cầu của hệ thống và trả

lời cho câu hỏi:

Hệ thống phải làm cái gì (What ?)

Mục tiêu của ca sử dụng trong cả quá trình phát triển phần mềm:

 Mô tả các yêu cầu chức năng của hệ thống, là kết quả của quá trình khảo sát, nghiên cứu các yêu cầu của bài toán và những thoả thuận giữa khách hàng, NSD hệ thống với người phát triển phần mềm

 Làm cơ sở để người phân tích viên hiểu, người thiết kế xây dựng các kiến trúc, người lập trình cài đặt các chức năng, người kiểm duyệt kiểm tra các kết quả thực hiện của hệ thống

Các ca sử dụng đóng vai trò rất quan trọng trong cả quá trình phát triển phần mềm, tất cả các pha phân tích, thiết kế sau này đều dựa vào các ca sử dụng Như

vậy, quá trình được hướng dẫn bởi ca sử dụng (use case driven process) là một cách

hữu hiệu để mô hình hoá hệ thống với UML

Tác nhân: Tác nhân ( Actor) là những thực thể bên ngoài có tương tác với hệ

thống, bao gồm người, vật, thiết bị hay các hệ thống khác có trao đổi thông tin với

hệ thống Nói cách khác, tác nhân đại diện cho người hay một bộ phận của tổ chức mong muốn nhận được các thông tin (dữ liệu) hoặc các câu trả lời từ những ca sử dụng tương ứng

Xác định các tác nhân

Tác nhân là một bộ phận bên ngoài hệ thống nhưng cộng tác chặt chẽ với hệ thống Nó chính là đối tượng mà hệ thống phục vụ hoặc cần có để cung cấp dữ liệu

Do đó, nhiệm vụ trước tiên của người phân tích là xác định các tác nhân

Một trong các kỹ thuật hỗ trợ để xác định các tác nhân là dựa trên các câu trả lời những câu hỏi sau:

 Hệ thống quản lý, sử dụng những thiết bị nào?

 Hệ thống cần tương tác với những bộ phận, hệ thống nào khác?

 Ai hay cái gì quan tâm đến kết quả xử lý của hệ thống?

Xác định các ca sử dụng

Bước tiếp theo là xác định các ca sử dụng dựa trên những tài liệu đặc tả các yêu cầu, thông qua các tác nhân Tương tự như trên, hãy trả lời những câu hỏi sau đây để tìm ra các ca sử dụng:

 Nhiệm vụ chính của các tác nhân là gì?

 Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ thông tin hay không?

 Những thay đổi bên ngoài hệ thống thì tác nhân có cần phải thông báo cho

hệ thống hay không?

 Những tác nhân nào cần được thông báo về những thay đổi của hệ thống?

 Hệ thống cần có những đầu vào / ra nào? từ đâu và đến đâu?

Nói chung, việc xác định được đầy đủ UC và tác nhân là một vấn đề khó khăn Biểu đồ UC không những mô tả các chức năng của hệ thống phần mềm cần xây dựng mà nó còn làm cơ sở để nhóm quản lý dự án đưa ra những ước lượng quan trọng cho quá trình lập kế hoạch dự án

2.2.3 Các bước thực hiện với phương pháp ước lượng UCP

Một số giả định về phương pháp UCP

Để khai thác và sử dụng hiệu quả phương pháp UCP, người dùng phải nắm vững quy trình phát triển phần mềm theo phương pháp hướng đối tượng, có kiến thức cơ bản về ngôn ngữ UML về cách xây dựng biểu đồ UC Trong chương này, ta chỉ đưa ra việc sử dụng phương pháp UCP và không đưa vào chi tiết làm thế nào để xây dựng được biểu đồ UC

Phương pháp ước lượng UCP được thực hiện qua các bước sau đây:

Bước 1: Xác định trọng số của các tác nhân chưa được điều chỉnh (Unadjusted

Actors Weight – UAW)

Đây là bước đầu tiên của phương pháp UCP, tại bước này ta thực hiện việc phân lớp các tác nhân Các tác nhân trong biểu đồ UC của hệ thống được phân chia

ra thành 3 lớp: các tác nhân đơn giản ( Simple Actors), các tác nhân lớp trung bình ( Average Actors) và các tác nhân lớp phức tạp ( Complex Actors) Song song với việc phân lớp là ta gán trọng số cho các tác nhân Việc phân lớp và gán trọng số của các tác nhân được thực hiện theo bảng sau đây:

Trọng số Tác nhân ( FW)

Simple Actors Đây là những tác nhân có giao tiếp với hệ

- Tác nhân lưu trữ CSDL, file hoặc hệ quản trị CSDL

2

Complex Actors Tác nhân tương tác với hệ thống qua GUI 3

Bảng 2.7: Phân loại tác nhân và gán trọng số cho các tác nhân