Nghiên cứu, đánh giá hiệu suất hoạt động của một số giao thức định tuyến trong mạng không dây kiểu AD HOC bằng phương pháp mô phỏng máy tính

Bằng cách so sánh và điều tiết các ước lượng được suy ra khi dùngcá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

ĐẠI HỌC QUỐC GIA HÀ NỘI

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

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

COCOMO Contructive Cost Model

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áccô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á chophầ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ủaphầ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ềutrướ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à baonhiê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àinguyê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ứccon 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ệcnày được tiến hành như thế nào? Trong nhiều trường hợp ước lượng được thực hiệnbằ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ự ánmớ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ự ánmớ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ênmá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êncứu và ứng dụng rộng rãi trong ngành công nghiệp phần mềm Mặt khác, để ướclượ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ùngcá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

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ộtthờ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âydựng một công cụ ước lượng tự động có thể áp dụng trong thực tế Nội dung luậnvăn chia thành ba phần, phần đầu (chương 1) đưa ra tổng quan về ước lượng dự ánphầ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 đánhgiá cụ thể, phần cuối cùng (chương 4) dựa trên những nghiên cứu thu được, pháttriể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./

(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);

Ba tuỳ chọn còn lại là những cách tiếp cận có thể đứng được tương đối đốivớ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 ý chotừ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ácchứ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: 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ươngtá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ôitrườ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ọngnhư: 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ịchtrì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ếtcho việc bắt đầu đánh giá một vòng đời phần mềm và sau đó là theo dõi, tinh chỉnhnhữ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àngsớ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 đồngthờ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ớichi 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ừngtrong thời gian thực hiện dự án Các hoạt động của nó bao gồm:

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ướckhi 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ànthà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ấutrú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ệnphần việc nào trước

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

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

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ếtthê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ứcnăng được đánh giá dựa trên chức năng của phần mềm và thường được áp dụngtrong 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ệuLOC 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ầnmề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 viphầ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ôngsứ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 ramộ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ệcphâ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ếptrong 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ảnphả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 FPlạ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 FPlạc quan (a), có thể nhất (m) và bi quan (b)

Ví dụ:

E= a  4m  b

6cho niềm tin đối với ước lượng có thể nhất và tiếp đó là phân bố xác suất beta.Giả sử rằng có một xác suất rất nhỏ là kết quả của LOC hay FP thực tại sẽ ra ngoài các giá trị và bi quan Bằng cách áp dụng các kỹ thuật thống kê chuẩn chú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 tronghai 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 = 310

5.5 = 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 độ đohiệ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 đâucũ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ệncho từng chức năng

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

Chi phí và công sức cho từng chức năng và nhiệm vụ kỹ nghệ phần mềm đượctí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ượngLOC 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ý

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ỏiyê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ácbiệ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à conngườ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ộctí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ờihạ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

cứng, phần mềm - Mô tả

- Tính sẵn có

- Thời hạn dùng

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

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ăngcầ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ấncá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 địnhchỉ sau khi đã xây dựng được ước lượng nỗ lực phát triển (như người-tháng hayngườ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ểnphầ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ốngmớ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-bitmá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ôngtin lớn có thể dùng chung cho nhóm phát triển phần mềm, và hỗ trợ cho sự phânloạ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 tadù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ềutrì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ảntrướ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 đượclê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 để chophé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ốithiể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ệ

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ònchư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ằngcá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éttớ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ềmtươ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 đổiphầ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ềmtươ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ầnmề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 chotớ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ầnmề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ầnmề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 quanhững căn cứ sau:

2. Tính tương đương của chương trình với thuật toán Thuật toán có thể đúngnhư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;

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ếtquả 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ểmthử 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ợpthà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 đặtmộ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ốngbiểu thị cả tiếng Anh, tiếng Việt lẫn lộn sẽ được xem là vi phạm tính khoahọ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;

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ăntrang 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ạngsả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ớicá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ệnquả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ốithiể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ănbả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ưngcũ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 đượcchứ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ânthủ 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ừngthờ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;

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ậyphả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 chomỗ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:

Để đ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ừ kinhnghiệm

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

Tính toàn ven=  [ 1-đe doạ đe doạ  (1-đe doạ 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ềutí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ướibố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 thaythế);

- 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ầnmềm

Function Point (FP) là phương pháp ước lượng được phát triển bởi AllanAlbrecht và được ban bố rộng rãi vào năm 1979, cung cấp độ đo được ứng dụngchung và không phụ thuộc vào công nghệ được sử dụng cho việc phát triển phầnmềm Function Point là một phương pháp chuẩn để tính kích thước phần mềm dựatrê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ớithiệ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ềmdù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ácActor và các giao dịch trên mỗi Use Cases Các điểm mà phương pháp UCP quantâ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 Phương pháp Function Points

 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ệuchỉnh (Unadjusted Function Points – UFP) ;

xây dựng chẳng hạn như độ phức tạp môi trường, độ phức tạp của ứngdụ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ớiviệ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ấthai tình huống mà trong đó phương pháp ước tính (một phương pháp tương thíchnhư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ăngcườ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ứcnă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ìnhbà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 chungtheo đ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íchhợ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àmgiao dịch (bảng 1) Đối với một ứng dụng phần mềm đã cho, mỗi phần tử trongbả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ó ít nhất hai tình huống mà trong đó phương pháp ước tính (một phươngphá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ặctă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ệctí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ờigian 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úckế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ựchiệ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ớiviệ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ờigian 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ảosá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ụngphươ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ệmkhá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ácphươ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ầnmềm Hai kiểu chức năng dữ liệu là các file logic trong (ILF) và các file giao diệnngoà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

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ấpphá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ầnmề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ệusuấ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ệunguyê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ảotrì 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ầnmề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ệusuấ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ínhphức tạp Sommerville quả quyết rằng các thừa số hiệu suất liên quan đến môitrườ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ớithiệ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

Phương pháp

Cơ cấu của SMPEEM của dựa trên nền tảng các khái niệm trình bày trong

hình 4 Trước tiên, để ước lượng quy mô của nhiệm vụ bảo trì, khái niệm của một

mô hình điểm chức năng được áp dụng Thứ hai, để điều chỉnh điểm chức năng (FP)

liên quan đến môi trường bảo trì, chúng tôi cần giới thiệu khái niệm mới về thừa số

điều chỉnh giá trị (VAF) Các VAF của mô hình này liên quan đến các thuộc tính

của mỗi nhóm đặc tính như: Kỹ năng của kỹ sư, các đặc tính kỹ thuật và môi trường

bảo trì [2]

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

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 đếnmứ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 để ướclượ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)

Kinh nghiệm với phần mềm hệ thống ESS(OS, DBMS)

Tính dễ thay đổi/đọc được của ngôn ngữ CRPCT

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

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

Dễ dàng thử nghiệm

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ăngsau: ILF, EIF, EI, EO, hay EQ Mỗi kiểu loại này được đánh giá riêng biệt về tínhphức tạp và được đưa ra những giá trị trọng lượng biến đổi từ 3 (đối với EIs đơngiản) đến 15 (đối với ILFs phức tạp) như được trình bày trong Bảng 2.

FC = SoLuongChucNang *W (3.2)

CacKieuChucNang

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

VAF nằm trong khoảng từ 0 đến 50 VAF này có thể được sử dụng để điều chỉnh

một count chức năng không được điều chỉnh được tính toán qua phương trình 3.3;

Thay vào đó, FPs có thể được tính toán qua phương trình 3.4, được giới thiệu cho

việc điều chỉnh các counts chức năng như là đơn vị %:

Trong đó,  là giá trị tuyệt đối của dải điều chỉnh Giải điều chỉnh có thể được quyết

định bởi dữ liệu thực và các thí nghiệm lặp lại của tổ chức liên quan Ví dụ, nếu một

tổ chức dự định điều chỉnh các counts chức năng trong khoảng 20%,  của

phương trình 3.4 có thể được thay thế bằng một giá trị tuyệt đối 20 để thành lập

phương trình sau:

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

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ệ khimộ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ố

mũ B trong phương trình:

Nỗ lực= A x (quy mô)B

Trọng lượng T -đe doạ thử nghiệm 95% khoảng tin

cậy của chênh

lệch đặc tính

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

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

Người dùng

Hình 5 Phân loại 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ệuthườ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 ứngdụ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 đếnmộ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ựcthể, 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

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 haybả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 đượccoi 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ặccậ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à:

- 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ạibản ghi Ví dụ:

Purchase OrdersRET #1

Purchase Orders No, Data, SupplierName, Order Value

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

RET #3Item Code, Delivery Schedules

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

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

EI Các file dữ liệu được Đếm các file dữ liệu tham chiếu

Số trường dữ liệu được Đếm DETtham chiếu (DEL) là Các trường dự liệu được nhập vàpnhững trường duy nhất mang một ý nghĩa nào đó về nghiệp

có thể nhận biết trong vụ được coi là một DETILF, được cập nhật bởi Không đếm các thông báo lỗi hoặc

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

Số trường dữ liệu được Trường duy nhất xuất hiện trong EOtham chiếu

tham chiếu (EIF) Đếm các FTR vào và độc lập vớiCác ILF hoặc EIF được nhau

đọc

Số trường dữ liệu được Đếm các trường duy nhất xuất hiện

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ỗichứ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ếthợ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ớnnhấ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) chomỗi loại chức năng dựa trên độ phức tạp của nó

Bước 2 Tính tổng UFP

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ạpcủ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à:

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

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

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

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à 5nế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ôngthứ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ăngsuấ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ư kinhnghiệ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

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

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

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

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

External Inputs=1 và ở mức LowExternal Output=1 và ở mức AverageUser Interactions=2 và ở mức HighExternal interfaces File=3 và ở mức LowFiles 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 nhaukhô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;

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

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

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;

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 nhauthì 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;

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ứcnă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ápFunction Points, sử dụng mô hình use case cho việc ước lượng công sức trong việcphá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ườngdự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ầnmềm thường mang tiếng là thiếu chính xác trong việc ước lượng chi phí và lịchbiể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ôngchí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ầnxây dựng trong tương lai ở giai đoạn đầu của dự án Tuy nhiên, những ước lượngchính xác và đầy đủ ở giai đoạn đầu của dự án có vai trò quan trọng cho việc thiếtlậ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

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 trongtươ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ộngrã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ũngcò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áphướ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ươngphá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ầuchứ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ậphỗ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éttớ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ạicá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: