Tìm hiểu ước lượng dự án phần mềm với Cocomo II và xây dựng chương trình ứng dụng

Khi nhận được yêu cầu xây dựng một phần mềm từ khách hàng, những người quản lý trong các công ty phần mềm phải đánh giá, ước lượng được độ phức tạp của phần mềm, nguồn nhân lực cân thiết

Trang 1

LUẬN VĂN TÓT NGHIỆP

TÌM HIỂU ƯỚC LƯỢNG DỤ ÁN PHẢN MÈM

VỚI COCOMO II VÀ XÂY DỰNG CHƯƠNG TRÌNH ỨNG DỤNG

SVTH:

NGUYEN CONG NGUYEN 02DHTH140 GVHD: ThS NGUYEN CHANH THANH

| J3/6/0o36z9 | — 2007 _ TP HỖ CHÍ MINH

Trang 2

BỘ GIÁO DỤC & ĐÀO TẠO CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

NHIỆM VỤ THỰC HIỆN ĐÒ ÁN TÓT NGHIỆP

Bộ môn : Công Nghệ Phần Mềm

Họ và tên : NGUYEN CONG NGUYEN MSSV : 02DHTH140

ĐOÀN THANH THÚY MSSV: 02DHTH242 Ngành : Công Nghệ Phần Mềm Lớp : 02CNPM

o_ Tìm hiểu lịch sử phát triển của COCOMO II

o Tìm hiểu các phương trình ước lượng của dự án

o_ Tìm hiểu mô hình ước lượng dự án phần mềm - COCOMO II

o_ Tìm hiểu các ứng dụng đã được phát triển theo COCOMO II

> Phần phân tích, thiết kế & xây dụng ứng dụng minh họa: .o_ Phân tích yêu cầu

o Ung dụng mô hình ước lượng của COCOMO II vào dự án

phần mềm

c_ Xây dựng cơ sở dữ liêu

Trang 3

o Xay dung các form

Nội dung và yêu cầu đồ án tốt nghiệp GIÁO VIÊN HƯỚNG DẪN CHÍNH

đã thông qua (Ký và ghi rõ họ tên)

Người duyệt (chấm sơ bộ) : G2211

Ngày bảo vệ : ~-erierrirrrirrrr

Điểm tông quát : -.+

Trang 4

ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP.HCM

HỘI ĐÒNG CHÁM THI TÓT NGHIỆP — 7P Hồ Chí Minh, tháng 01 năm 2007

NGÀNH: CÔNG NGHỆ THÔNG TIN

PHIEU CHAM DIEM HUONG DAN LUAN VAN TOT NGHIEP

ÁP HH ng GD g 0 9 00 0 0:40 0000 090.40 0-4 0040 0.0 4100400000000 600 0 6000 010.400 09000000 0.0.0.0 0.4.9.6 0/0000 0.0.0.4 0.640.000 0/06 094 0 409 000:0E00.0 00006 5000406084008600000000540000000400000000 6

PO Đo ĐÓ ĐÓ GỌI G0 000 0000500094 0:00 00.006.004 4008.4062060 060 60.00.0109 400.000 010 00-600 04-0 4060-6041 6 0-60 6 0 679 42.0:0060:.0 0/60 4010 2.010.900 0.00 200.019 0/000 0000860000000 2400002-00000 0200000006006

Đề HH nh GP GHI GIÓ G ĐI" Bo 0ì HI H0 000 0/900 4.04000/00 0000 000-0040 0000060 6:5 0010.040 0/00/00 6-0/000 0.000 0:00 000/2 0.0 0P 6 P0 000066 00 0000000060040 0004000000Đ9000006060600060668%

ÔÁ 9 S9 6 GIÓ TH BIẾT GP G0 0000 000.010.006 0:00 0 010.000 0.0000 0 0 00 0000 1000 00/0 160/000 02 0060 011 0 00080 040000060004590040000600099000004000000090500460090090990099

Trang 5

ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP.HCM

HOI DONG CHAM THI TOT NGHIEP TP Hồ Chí Minh, tháng 02 năm 2007

NGÀNH: CÔNG NGHỆ THÔNG TIN

PHIẾU CHAM PHAN BIEN LUAN VAN TOT NGHIEP

Án ĐI GP 8005 0/60000:00 0 0 0 0900000600609 0606000600606 0 5 0 0P 49000900 00 2 0.0 0.0-4-010-0.0:00 60:00 06.9 200 c0 0 0:0 0000006 P K00 000090990040000000090000090060060086608 Q.00, 000 200.0, tin PHI 0G 000/8 0000060040090000 0 00 00600 600:960/0 00059600400 06008000 0.60 44:0 000 02-0000 00-500 000.0 00 0000/60 6001020 000400490000090500400400 00006 06006 OMe m acer mn rece ees Cen eH eee eC DEE EDR T MOLDED ORDO ORO ADC OR SHOES ENED EES ESE CRUSE EAEEOSEEOFESDEEEEE REDS EOES OPER EER ECHR DOR OME EERE SED SODEOHEOEE ĐƠƠ9 0 9000 0 000 0/0009 00 00 ĐH HP SP G0 00098909 0600400000500 060000600 60/9.0/6 5.96 0.400 4 0 6:0 0:40 010 9000008 0.00 0900.0404.010 000000 600/0 000 0/400 5005.040400 06/0/20 0/06 003.00 6 0:00 tê 000 04

« ĐÓ PO 00000006006 006.010 000 0:0 0 0/00 00.019.060.610 09.6 6 0 40.6 6.0 0 n2 0 9 0 0 4 P0 000.006 0/66 000 4.010 40:06 0:65 0 6 0.200 0.40 0:6 4 0/06 0066.000 D0 00000900900000000000000009906406660066

Án ĐO TH n9 Ịn 0 t9 0 P.9 0/8 0/0 0.0/00 0 00000 0 000 S6 9 09.00.006.000 206.6 019.0 6: 4 00020 006900 0.00/040.00 0/040 010 4000 60.00 0.49 0 0 0.0.0.0 206 0 i6 0-4210 0:6 0 BH 0D 0P 600000000000006000606060066

4 Ơn KG HC HC P00 DI 9 000.06 006.4001600 800 0 00686006910 60 65 0 00.0010 0 6 6004 05.0.0006 BI 0 0 0.040 0.0.0 200.4 0.0.4.0 0 0:0 6 0/0 6-0 0.0400 0 2.0 0 000 2 00 tớ 0n n" An HP “SP Đen GD 0009600899048 4Q Ọ Đ n VU SH SN ĐC 000900 0005900000000 0006009600006 0 0/605.6600490900 006 00:0 B600 0 000 000.2000000 000 00/000 000000400090008005900400000200084000000 s04, G0 no PHI G0 0 0.000 96/0.00/00 0 0094 00.00.0800 0066066000/06 0/000 4.60 6900 4-0606 0 0 4 50600 000 400000050000 0.04400000048000 6006 6-0/0 0 078 0.620.400 00/6 6 0069.000 00 0400049008 9009998 06

ÓC I9 0 0000 0 0 006.006.460 Si 0 60.690 0 ĐH 40060089 65900000 00 0:06 0000 0/00 040012: 6.0 6-5 0.019.400 0 4 00008 0068 lá o6 GIÁ ĐÀ GP SP G0000 00006000009060090070900900060000904004060 606

Á ĐÓ ĐỌ n9 0 4 0 P0 0, 006000000 010000 0000.019.9400 006006006 0060000000 00008 6090400.06:0 6606 0/0 6.610 04 0000.600 9/0000/040 4000/0060 0600000000 040000940000000004000000040006840080 90668 n9 001000 000 008.0 00.400.400.004 06:6 006: 0060 960.0000600 E00 0/4: 0:0 0 0/410 0000.440.0000 0 0/0 2 000-590-0000 0 0/0 0.0 2 0000 0060/60 0 6:0 0090600000000000090000000000092600090605090660460Đ

Q ĐH n9 CÓ ĐÓ 0060 600040000/0 0.006.040 000 6 906 Ree Hee Se EOS AS COS OOL EU DEBE Da HED ERGO ESO RASHES DOO DSED ESSE OE ESEEEESESEESE EOE EE SECS EERE REOR ERS ORESOOEOSSOOD

Oo ee 00.00040000 6 8.0 6:0 46:0 0.0000 0000 ire irre errr irrrerrsr itr rrrr irre etter rirerrirrr errr rrr rr rrr rtr tery

CĐ ĐI DI 0 ĐI 9 N90 00000.040.000: 5040/006/0 06 000.000 060.06 0 0.060 0/000-00M.0 4 0:0 P.0 00.440 0010/00 0.0.0 0.0 4.0/67 49 0:66 0:68 206 9 60 KIÀ G4 GP BÀ G0 NH0 000000009000 0000006090400000600 66

«CẢ Go 9 HH GA 0 0 0000 060/06 000 6.010 0000 000 PP 0 609960 9000 06 06 0.600 40:56 00 900 4 0 0.409 6.010.490 0.6.0-0.0 0.420 4-0 Đ 4c M4 Ó 0 9 200 6:00 6 6:0 060 m0 006000 000000000404006009090005009904909040 0060866

ÁP D90 0009 000 069 0 40060 0, 9.600 0 0.0400 006900 5005000 80000068000 000 0/49 86 0.06.0/6.5 0.6 600 00/6/96 000.010 0 40 206/00 0/009 0/00/60 0:00 40/00 0 005.0100.000 004 00000.005.060 9.000 0.0 2:0 0 0/6 6006 5 0 10 SP 0009000600

Trang 6

LỜI CÁM ƠN

Trong quá trình học tập tại trường Đại học Kỹ thuật Công nghệ Tp Hồ Chí Minh, chúng em đã được quý thầy cô truyền đạt những kiến thức vô cùng

quý báo Những kiến thức đó chính là nền tảng vững chắc và là hành trang cho

quá trình làm việc trong tương lai sắp đến của chúng em sau khi ra trường Luận văn này là kết quả của sự vận dụng kiến thức học tập tại trường trong

suốt những năm qua vào thực tê công việc

Em chân thành cảm ơn quý thầy cô, đặc biệt là thầy hướng dẫn Nguyễn

Chánh Thành đã tận tình hướng dẫn cho chúng em, tạo mọi điều kiện cho

chúng em hoàn thành luận văn

Tp Hồ Chí Minh, tháng 01 năm 2007

Trang 7

MỤC LỤC

Chương 1: GIỚI THIỆU CHƯNG -. 2°-©eszererxtttrtr.rrrrkrrrrtrrrrrie 1

Ni na Ó 1

1.2 Giới thiệu chung về luận văn «+22 << kersetrrExererserrrrrrreerrr 2

1.3 Công cụ và môi trường phát 7.0 3

Chương 2: TỎNG HỢP KIÊN THỨC LIÊN QUAN ĐÉN LUẬN VĂN 4

b n‹ 8 4

2.2 Lịch sử phát triỂn -52++envt tr 4

2.3 Các mô hình trớc lƯỢng se ++z +91 xen n 0004110066 5

2.3.1 Mô hình Application Composition - se series 5

2.3.2 MG hinh Post-Architecture .sccceccssscesccsoeseensssencnccsseesceesesenecesaneces 7

2.3.3 MO hinh Early Design cescssssssssssccssececsseseeseeesseesssssssnescsneesanvessansessons 7

2.4 Các thông số được sử đụng trong các mô hình ước lượng . 8

2.4.1 {ồng số dòng mã lệnh cần cho dự án eseserrre 8

2.4.2 Trọng số gia giảm của dự án -. -c ccsstrsserrrtriseritrrirrrrierie 8

2.4.3 Trọng số điều khiển chỉ phí của dự án -. -eerxecrrerrrrsrrre 11

2.5 Các phương trình ước lượng . -s< s7 es=sssserrirserrerrrririeeree 21

2.5.1 Phương trình ước lượng công SỨC .- -5« << ensereereeeerse 21

2.5.2 Hệ số ước lượng công SUC sesccssecsssssessseccnseesserscenecsenrsessenessssescusensase 23

2.5.3 Phương trình ước lượng kế hoạch .-. -csssss<seceeereereererrerxxee 23

VN 0 177 " 24

2.6 Mô hình tiến trình thực thi dự án cccssecterxerrrrrrrrrrerrrreg 24

Chương 3: PHÂN TÍCH NHIỆM VỤ CỦA LUẬN VĂN - 26

3.1 Nhiệm vụ của luận văn -. - cà ss sec 411134101161 1110140 110010160 26

3.2 So sánh giữa các mô hình ước lượng dự án -e-eesseree 26

uống ng vn 29

Chương 4: THIẾT KÉ VÀ THỰC HIỆN CHƯƠNG TRÌNH 31

4.1 Quá trình hoạt động của chương trình: .-. - << sssseeersererre 31

Trang 8

4.2 Biểu đồ Usecase tổng thể của chương trình -s-c -ecseerserre 33

4.2.1 Tạo mới dự án - -< + + cxtenhe81261 1128010102 0840001814141 1100 g 34

4.2.3 Quản lý loại dự án -«c-sentreneettiee H1 36

4.2.5 Chỉnh sửa thông tin dự ám -.- 5< nen the 37 4.2.6 Sao chép dự án - sec 1111010101001 38

4.3.2 Sao chép dự án -.«-«ss+tk s12 5111111100103 01-81.04 44

4.3.3 Ước lượng mở rộng -. -s 2 2©-z+eetsstsstsererersrrserersererske 45

4.3.6 Xem công thức ước lượng . - «+ s-ssseeseeeenie nen 0140166 47

4.3.§ Thêm mô đu 5 + E4 94152% 8258515558909 1t ng 0114 48 4.3.9 Thêm ngôn ngữ - . - sex 114 141<n 10m g0 010101004000 48

4.4 Biểu đồ tuần tự thể hiện chỉ tiết hoạt động của chương trình 50 4.4.1 Tạo mới dự án - 5c << ng 000803001 0104063116141 10 0313 50

4.4.2 Sao chép dy 40 csscssesssesssensenseesssssesssnsseseaeserenenensenenesonsontessenensees 51

4.4.3 Ước lượng mở rộng - -: +©-s+sexserserserrrserersrrersersrrerrrrke 52 4.4.4 Chính sửa thông tin dự án <seeeirirereierrreieeeieeree 53

4.4.7 MỞ dự án -< s4 00119 11 01001 1T T000188811E10 1.0107 e 55

Trang 9

4.4.8 Thêm loại dự án sa <c HH HH HH1 HA n0118141880401001 161k 56 4.4.9 Thêm ngôn ngit ccssceseesconccseenssersssersteessensenseenessenseeseuseeseescesneeneraes 56 4.4.10 Thêm mnôđun - 5 5< 5< S242 91081181189 <1216420810810 14 E1." 57

4.5 Biểu đồ thành phần - 22s +s©xeYrdeEkrErkErkeerkeeekrrrkrrkerire 58

4.5.1 ClasslLIĐFAT 0G 5< 1 nh HH HH4 30101401401801001010150 58 4.5.2 DataACeSS .cscccrcsssescsessersossesensssnsssssssssnsarscesnsseesseseossansneaesanseeneseees 58 4.5.3 ProjectEstimations .ccssssssssessessssssssessonsessenesesecssersesaescenenseenseeeesees 59 4.5.4 BusinessControl scccscssscssssecsseceseecssenecesnssesesssssnssssnesseesssssesense esas 60

| 4.6 Biểu đồ triển Khai ces scsssssssccssessecsssssssssssssssescssssssesesssnneccecsssnssesessanassess 60

| 4.7 Thiết kế cơ sở dit LGU .ossccssssssseccnsessnsscssesnssenseeeseeeecetnneeeneevneeennsinets 61

4.8.7 Ước lượng mở rỘNg, - - «- 7< sex 4 x1xx.rxrrrrerrkrersre 71

Chương 5: KÉT LUẬN VÀ ĐỊNH HƯỚNG PHÁT TRIÉN 72

5.1 Những công việc đã thực hiện - -Ă HH2 em 72 5.2 Hạn chế và hướng phát triỂn -2 cc++rvrevrxerrrerrrrersrksetrerrrkreri 72

In 1 74

Phụ lục 1: Chỉ tiết của từng cÌass -. s-©ss+rxtevterreevrerrrerkerrkertksereere 74

Phụ lục 2: Giải thích thuật ngữ tiếng Anh s2 cstesnsiirrkrerree 77 Phụ lục 3: Tài liệu tham khảo . - - << cv n9 84 1 H20 0781083308 79

Trang 10

Đoàn Thanh Thúy - 02DHTH242 Nguyễn Công Nguyên - 02DHTH140

hiệu quả và phù hợp với nhu cầu thực tế thì rất khó Vì vậy để xây dựng thành công một phần mềm ta cần rất nhiều yếu tế về nhân lực, chỉ phí, đồng thời

một yếu tố giữ vai trò then chốt góp phần thành công cho một dự án phần mềm

đó là ước lượng dự án phần mềm Khi nhận được yêu cầu xây dựng một phần mềm từ khách hàng, những người quản lý trong các công ty phần mềm phải đánh giá, ước lượng được độ phức tạp của phần mềm, nguồn nhân lực cân thiết

để xây dựng phần mềm, lịch biểu hoạt động của phần mềm và những chỉ phí phải bỏ ra để có thể xây dựng phần mềm một cách có hiệu quả nhất và ít có rủi

ro nhất

Để hỗ trợ cho việc ước lượng dự án phần mềm ta có nhiều mô hình ước

lượng khác nhau, một trong những mô hình ước lượng khá phổ biến và được sử

dụng nhiều đó là ước lượng dự án phần mềm theo mô hình COCOMO II

(Constructive Cost Model) được xây dựng béi Barry Boehm

Luận văn này được thực hiện để hướng sinh viên tiếp cận về hoạt động

ước lượng kích thước và lập dự toán cho dự án phần mềm trong ngành công nghiệp phần mềm Đồng thời có thể xây dựng được một phần mềm để hỗ trợ

việc ước lượng cho dự án phần mềm theo mô hình COCOMO II

Trang 1

Trang 11

1.2 Giới thiệu chung về luận văn

Nội dung chính của luận văn là xây dựng một phần mềm ứng dung dé

hỗ trợ việc ước lượng dự án phần mềm Phần mềm ứng dụng này dùng để hỗ trợ việc lập dự toán về công sức, thời gian và nhân lực một cách hiệu quả và thích hợp nhất nhằm giảm bớt rủi ro trong việc xây dựng phần mềm Đồng thời chương trình ứng dụng này cũng hoàn toàn dựa vào mô hình ước lượng

COCOMO II Phần mềm sẽ được ước lượng theo hai mô hình chính, đó là:

Early Design (tham khảo trong phần 2.3.3) và Post-Architecture (tham khảo

trong phần 2.3.2)

Sau đây là một số chức năng cơ bản của phần mềm ứng dụng:

e© Tạo mới một dự án: kết quả là dự toán về công sức (effort), thoi gian (duration) và nhân lực (staffing) cho dự án vừa được tạo mới

e_ Ước lượng mở rộng: với kết quả về công sức của dự án vừa ước lượng ở

phần tạo mới dự án, dựa vào tỉ lệ phần trăm công sức của từng nhóm người tham gia phát triển phần mềm, chương trình sẽ đưa ra những

hướng dẫn là nên cần bao nhiêu nhân viên phân tích yêu câu, bao nhiêu

nhân viên phân tích thiết kế, bao nhiêu nhân viên quản lý, bao nhiêu nhân viên kiểm tra,

e©_ Mở dự án: mở một dự án bất kỳ đã được ước lượng sau đó có thể chỉnh stra cdc scale driver (trọng số gia giảm) và cost driver (trong số chỉ phí

của dự án), LOC (tổng số dòng mã lệnh của dự án cần ước lượng)

e© Tìm dự án: để người dùng xem tất cả các thông tin ước lượng và thông tin mô tả liên quan đến một dự án có những chức năng mà người dùng cần tìm kiếm

e Sao chép dự án: sao chép một dự án ban đầu (bao gồm tất cả các thông

tin liên quan đến dự án) thành một dự án mới

e Chỉnh sửa dự án: cập nhật lại các thông tin liên quan của dự án ngoại trừ các trọng số scale driver, cost driver va LOC

e Xem công thức dự án: xem công thức ước lượng dự án ở hai mô hình ước lượng Early Design và Post-Architecture (nêu ở phần 2.3)

Trang 2

Trang 12

e_ Báo cáo: xuất ra báo cáo về kết quả ước lượng, dé cho người dùng có cái

nhìn tổng quan về kết quả ước lượng của dự án, đồng thời có thể dễ

đàng trong việc in ấn để báo cáo

1.3 Công cụ và môi trường phát triển

Chương trình được hiện thực trên môi trường DotNet amework 2.0 và

C#, sử dụng Visual Studio 2005 cùng với hệ quản trị cơ sở dữ liệu SQL Server

2000

Sử dụng Visual Studio 2005 để lập trình vì phần mềm này không đời hỏi

tính bảo mật cao, hỗ trợ rất mạnh cho lập trình viên về mọi mặt và sử dụng

ngôn ngữ lập trình C# là ngôn ngữ lập trình có tính hướng đối tượng cao Hệ

quản trị cơ sở đữ liệu SQL Server 2000 thì rất mạnh về cơ sở dữ liệu, và tính

ổn định cao

Trang 3

Trang 13

Chương 2 TONG HOP KIÊN THỨC LIEN QUAN ĐẾN LUẬN VĂN

Qua các tính toán ta có thể ước tính được khoảng chỉ phí, công sức và

dự đoán về phân chia công việc từ trường hợp tốt nhất đến trường hợp xấu nhất

có thể xảy ra cho đự án Nó cho phép người dùng lên kế hoạch, đưa ra những

yêu cầu về tài nguyên và nhân lực cần phải có dựa trên chỉ phí và lượng công

việc được dự đoán trước

2.2 Lịch sử phát triển

Ban đầu là COCOMO sau đó phát triển dần dần lên COCOMO II

e 1981: COCOMO được giới thiệu trong sách “Software Engineering Economics” ctia Dr Barry Bochm Mô hình này sau này được gọi là

“COCOMO 81”

e 1987: Ada COCOMO va COCOMO cai tién được giới thiệu bởi tổ chức

SEI (Software Engineering Institute)

e 1988, 1989: Ada COCOMO duoc cai tién

e_ 1995, 1996: sách về COCOMO II được xuất bản

e 1997: sy diéu chỉnh đầu tiên của COCOMO II, sách được phát hành bởi Dr Boehm có tên là “COCOMO II.1997”

e 1998: sự điều chỉnh tiếp theo của COCOMO II, sách được phát hành có tên

là “COCOMO II.1998”

e_ 1999: COCOMO II.1998 được đối tên thành COCOMO II.1999 và sau đó

là COCOMO II.2000

Trang 4

Trang 14

Đoàn Thanh Thúy - 02DHTII242 Nguyễn Công Nguyên - 02DHTH140

e 2000: sách “Software Cost Estimation with COCOMO II” của Dr Barry Boehm được xuất bản để chỉ dẫn làm thế nào áp dụng mô hình ước lượng

mới nhất COCOMO II vẫn tiếp tục được nghiên cứu và cải tiến để trở

thành một công cụ để ước lượng chỉ phí, nhân lực và thời gian tương ứng với sự phát triển phần mềm trong tương lai

2.3 Các mô hình ước lượng

Bảng 2.1: Các mô hình ước lượng con của COCOMO II

Các chặng trong quá trình | Các mô hình ước lượng con của phát triển phần mềm COCOMOII

Inception Application Composition

Elaboration Early Design

Construction Post-Architecture

2.3.1 M6 hinh Application Composition

M6 hinh application composition duge sử dụng trong các trường hợp dự án chứa đựng những rủi ro tiềm ấn cao về giao diện, tương tác giữa hệ thống và phần mềm, Trong trường hợp này ta sử dụng khái niệm Object points (tính điểm ước lượng theo từng đối tượng) đề ước

lượng thay vì dùng số đòng mã lệnh (LOC) để ước lượng

Việc đo lường kích thước phần mềm được tính bằng cách đếm số

lượng màn hình, báo cáo, và những thành phần tích hợp thêm (third-

generation components) được dùng trong hệ thống Mỗi đối tượng có 3 mức độ: đơn giản (simple), vừa (medium), phức tap (difficult)

Bảng 2.2: Tính điểm cho số lượng màn hình hiển thị

Số lượng bảng dữ liệu

Số lượng màn hình hiến thị | Tổng số <4 | Tông số <8 Tổng số 8+

3-7 đơn giản vừa phức tạp

Trang ð

Trang 15

Bảng 2.3: Tính điểm cho số lượng các báo cáo

r: phần trăm (%) số đối tượng được sử đụng lại từ đự án cũ

object points: tổng số điểm được cho dựa trên bảng 2.2, 2.3, 2.4

Bảng 2.5: Tính điểm cho PROD

Khả năng và kinh nghiệm | Rat | Thấp | Trung |Cao| Rat

của đội ngũ lập trình viên | thấp bình cao

bình cao

Công sức (effort) được tính theo công thức:

Effort = NOP / PROD PROD: tan suat san xuat trung binh (Average productivity rates)

Trang 6

Trang 16

Đoàn Thanh Thuy - 02DHTH242 Nguyên Công Nguyên - 02DHTH¡40

2.3.2 Mô hình Post-Architecture

Mô hình này là mô hình ước lượng chỉ tiết nhất và nó được mở

rộng khi kiến trúc của phần mềm được xây dựng Mô hình này dùng

trong quá trình phát triển và bảo trì sản phẩm phần mềm trong các quá trình khởi tạo ứng dụng (Application Generator), tích hợp hệ thống (System Integration), ho%c quá trình phát triển các thành phần (Infrastructure đevelopmen†)

Những thông tin đưa vào trong mô hình COCOMO HH Post- Architecture:

e SLOC (Kích thước dự án)

e Labor rate (tan suất lao động)

e 5 scale driver (trọng số gia giảm), 17 cost driver (trong số phí) Những kết quả có được từ mô hình ước lượng COCOMO II Post-

Architecture:

Effort (công sức), schedule (thời gian): được đo bằng số người trên

tháng (Person Months - PM) hoặc lịch biéu (Calendar Months - CM)

Những kết quả khác:

e Mức sản xuất SLOC/PM (PROD)

Tổng chỉ phí để phát triển phần mềm tính bằng USD (COST) Chi phi $/SLOC (INST)

Số người làm toàn thời gian (full-time) cần trong dự án (FSWP)

Những rủi ro - Associated Risk (RISK)

2.3.3 Mô hình Early Design

Mô hình này thường sử dụng trong chặng đầu của dự án phần

mềm khi ta vẫn chưa biết rõ về kích thước của dự án cần phát triển, tính

chất của nền tảng hướng đến, tính chất của nguồn nhân lực cần cho dự

án, chỉ tiết cụ thể của những qui trình được sử dụng Mô hình này chỉ sử

dụng 7 trọng số chỉ phí (cost driver): PERS (Personnel Cabability Cost

Driver), PREX (Personnel Experience Cost Driver), FCIL (Facilities

Trang 7

Trang 17

Doan Thanh Thuy - 02DHTH242 Nguyễn Công Nguyên - 02DHTH140

Cost Driver), SCED (Development Schedule Cost Driver), PDIF (Platform Difficulty Cost Driver), RCPX (Product Reliability and Complexity), RUSE (Required Reusability Cost Driver)

2.4 Cac thông số được sử dụng trong các mô hình ước lượng

2.4.1 ông số dòng mã lệnh cần cho dự án (Source Lines of Code) Những tính toán trong COCOMO II dựa trên những ước lượng vẻ kích

cỡ của dự án (SLOC) SLOC được định nghĩa như sau:

Chỉ những đòng mã nguồn được tạo ra từ những người điều khiển,

kiểm tra (test driver) và phần mềm hỗ trợ khác

Những dòng mã nguồn được tạo ra bởi nhân viên trong dự án — bao gồm mã lệnh được tạo bởi các lập trình viên

Một dòng mã lệnh là một dòng mã có trật tự logic

Những khai báo được tính là những dòng mã (SLOC)

Những chú thích không được tính như những dòng mã (SLOC)

2.4.2 Trọng số gia giảm của dự án (Scale Driver)

Trong mô hình COCOMO II, trọng số ảnh hưởng quan trọng nhất

về thời gian và chỉ phí của dự án là trọng số gia giảm (scale driver) Gôm có 5Š trọng số:

Precedentedness (tiền lệ, giá trị định tính)

Development Flexibility (tính linh động, mềm dẻo)

Architecture / Risk Resolution (cấu trúc / giải pháp đối phó rủi ro) Team Cohesion (tính đoàn kết trong đội ngũ)

Process Maturity (qui trình làm việc)

Bảng 2.6: Ý nghĩa của 5 trọng số gia giảm

Việt tắt Tên và diễn giải

PREC Precendenfedness: năm bắt, hiêu biệt về những mục tiêu sản

phẩm và yêu câu kỹ thuật của tô chức

FLEX | Development Flexibiliqy: Biếu hiện mức độ tương thích với

Trang 8

Trang 18

RESL | sự hiểu biết về kiến trúc sản phẩm phần mềm và tính nghiêm

trọng của những vấn đề rủi ro không giải quyết được

TEAM Team cohesion: gitt ving tinh chac chin cua nhig d6i trong

tham gia và sẵn sàng làm việc với nhau như một đội

PMAT Process Maturity: tinh chic chin cua tién trinh phan mém

dung dé sản xuất ra sản phẩm

> PREC: thể hiện sự hiểu rõ về dự án mới như thé nao

Để ước tính ta trả lời câu hỏi: So sánh giữa dự án mới này với các dự án

mà nhóm của bạn đã làm trước đó như thế nào?

Mức cao nhất: rất quen thuộc, rat rd Rất cao: rất quen thuộc

Cao: không quen thuộc Trung bình: có một số phần chưa từng làm Thấp: có nhiều phần chưa từng làm

Rất thấp: hầu như chưa từng làm

> FLEX: diễn tả mức độ thích ứng của nhóm bạn với những yêu cầu của

phân mềm và các chuẩn giao tiệp bên ngoài

Để ước tính ta trả lời câu hỏi: Những qui trình, mục tiêu của bạn có linh động không?

Mức cao nhất: những mục tiêu thông thường Rất cao: có một số phần phải phù hợp

Cao: thông thường phải phù hợp Trung bình: có thé nới lỏng một số phần

Thấp: đôi khi có thể nới lỏng một số phần

Rất thấp: rất nghiêm ngặt

Trang 9

Trang 19

> RESL: ti lé phan tram ban hiéu về kiến trúc của dự án phần mềm và một

Rat thấp: một ít (20%)

>» TEAM: tinh hgp tac

Để ước tính ta trả lời câu hỏi: Bạn mô tả thế nào về mối quan hệ với

khách hàng?

Mức cao nhất: hầu như rất hợp tác Rất cao: mức độ hợp tác cao Cao: khá hợp tác

Trung bình: hợp tác Thấp: có một số khó khăn trong việc hợp tác Rất thấp: rất khó hợp tác

> PMAT: sự thành thạo trong công việc của bạn

Để ước tính ta trả lời câu hỏi: Cấp độ của tổ chức bạn theo chuẩn của

SEI Maturity Scale?

Mức cao nhất: SEI CMM cấp 5 Rất cao: SEI CMM cấp 4

Cao: SEI CMM cấp 3 Trung bình: SEI CMM cấp 2

Thấp: SEI CMM cấp 1 (cao hơn một nửa)

Rất thấp: SEI CMM cấp 1 (thấp hơn một nửa)

Trang 10

Trang 20

Doan Thanh Thiy - 02DHTH242 Nguyên Công Nguyên - 02DHTH140

Bảng 2.7: giá trị của 5 scale driver

Wii) Rất thập | Thập | Trung | Cao Rất | Mức cao

PREC 4.05 3.24 2.42 1.62 0.81 0.00 FLEX 6.07 4.86 3.64 2.43 1.21 0.00 RESL 4.22 3.38 2.53 1.69 0.84 0.00 TEAM 4.94 3.95 2.97 1.98 0.99 0.00 PMAT 4.54 3.64 2.73 1.82 0.91 0.00

2.4.3 Trong số điều khiến chỉ phí của dự án (Cost Driver)

COCOMO II có 17 trọng số chỉ phí (cost driver) đành cho mô hình Post-Architecture (xem ở mục 2.3.2) và 7 cost drivers cho mô hình Early Design (xem ở mục 2.3.3) Bạn ước lượng dự án, môi trường phát

triển và nhóm làm việc để thiết lập cho mỗi trọng số chỉ phí (cost

driver) Cost driver là những thừa số nhân (multiplicative factor) mà nó xác định yêu cầu công việc để hoàn thành dự án phần mềm của bạn

Bảng 2.8: Cost driver cho mô hình Post-Architecture

liệu lớn có trong việc phát triển sản phẩm

CPLX

Product Complexity: mé ta tinh phitc tạp của sản phâm trong

5 lĩnh vực: control operations (những hoạt động diéu khién),

computational operations (nhitng hoat động có sử dụng máy

tính), device-dependent operations (những hoạt động phụ thuộc vào thiết bị), data management operations (những hoạt động quản lý dữ liệu), and user interface management operations (những hoạt dộng quản lý giao diện người dùng)

Trang 21

Doan Thanh Thiy - 02DHTH242 Nguyễn Công Nguyên - 02DHTH140

xây dựng các component (thành phân) thay cho việc tái sử

dụng những dự án hiện tại hay tương lai

Analyst Capability: năm giữ khả năng phân tích và thiệt kê,

tính hiệu quả và tính tỉ mỉ, và khả năng giao tiếp và khả năng cộng tác

PCAP

Programmer Capability: năm giữ khả năng, tính hiệu quả và

tính tỉ mi, và khả năng giao tiếp và khả năng cộng tác

Những lập trình viên nên là một nhóm hơn là những cá nhân riêng rẻ

ngữ lập trình và kinh nghiệm lập trình của nhóm dự án

TOOL

phẩm của những công cụ từ việc chỉnh sửa đơn giản và

những công cụ lập trình để tương thích, những công cụ hỗ

Trang 12

Trang 22

SITE Multi-Site Development sắp xêp thự tự vị trí, và sự hỗ trợ

trong việc giao tiếp

" Mức cao nhất (extra high)

"_ Rất cao (very high)

Các trọng số chỉ phí được ước tính dựa trên những gợi ý tham khảo từ

chương trình Costar 7.0 của tổ chức Sofistar Systems (website: www.SoftstarSystems.com) như sau:

Nhân lực

>_ ACAP (Analyst Capability): các nhà phân tích là những người làm việc

với các yêu cầu của dự án, phân tích thiết kế ở mức cao và cả chỉ tiết

ACAP đánh giá khả năng phân tích và thiết kế, sự hiệu quả và tính cần

thận, cũng như khả năng giao tiếp của các nhà phân tích thiết kế Nhưng

ta không cần xem xét về kinh nghiệm

Để ước tính ta trả lời câu hỏi: Khả năng thành thạo của các nhà phân

tích thiết kế cho đự án này như thế nào?

" Mức cao nhất: 90% trong nhóm

“ Rất cao: 75% trong nhóm

Trang 13

Trang 23

> AEXP (Applications Experience): đây là sự đánh giá về mức độ kinh

nghiệm của nhóm phát triển dự án này

Để ước tính ta trả lời câu hỏi: Kinh nghiệm của nhóm phát triển của bạn

= Rat thdp: thấp hơn hoặc bằng 2 tháng

> PCAP (Programmer Capability): đánh giá phải đựa trên năng lực của cả đội ngũ lập trình viên chứ không dựa trên khả năng của từng cá nhân

Yếu tố chính nên được xem xét là khả năng, mức độ hiệu quả, tính cẩn

thận và khả năng giao tiếp và hợp tác

Để ước tính ta trả lời câu hỏi: Năng lực của đội ngũ lập trình viên của

bạn trong dự án này thế nào?

> PEXP (Platform Experience): đánh giá sự quan trọng về khả năng sử

dụng nhiều nền tảng khác nhau, bao gồm giao diện người dùng, cơ sở đữ

liệu, mạng và khả năng về ứng dụng phân tán

Để ước tính ta trả lời câu hỏi: Kinh nghiệm của đội ngũ của bạn về nền

tảng của dự án này thế nào?

" Rấtcao:6năm

Trang 14

Trang 24

= R&t thap: 2 thang

> LTEX (Language and Tool Experience): đánh giá kinh nghiệm lập trình

và sử dụng các phần mềm công cụ của nhóm phát triển hệ thống và hệ

thống con của ứng dụng

Để ước tính ta trả lời câu hỏi: Kinh nghiệm của đội ngũ của bạn về lập trình và việc sử dụng các công cụ như thê nào?

Rất cao: 6 năm Cao: 3 năm Trung bình: 1 nim Thấp: 6 tháng Rất thấp: nhỏ hơn hoặc bằng 2 tháng

> PCON (Personnel Continuity): đánh giá về khoảng thời hạn của việc thay đổi nhân viên trong công ty bạn hàng năm

Để ước tính ta trả lời câu hỏi: Tốc độ đổi mới trong tổ chức bạn như thế nào?

Dự án

Rất cao: 3% mỗi năm Cao: 6% mỗi năm Trung bình: 12% mỗi năm

Thấp: 24% mỗi năm

Rất thấp: 48% mỗi năm

»> TOOL (Use of Software Tools): công cụ để xây dựng phần mềm

Để ước tính ta trả lời câu hỏi: Những công cụ nào đội ngũ bạn sẽ sử

dụng?

Rất cao: thuần thục, tích hợp với việc xử lý, phương thức và khả

năng sử dụng lại

Trang 15

Trang 25

Đoàn Thanh Thuy - 02DHTH242 Nguyên Công Nguyên - 02DHTH140

Cao: tốt, tích hợp ở mức độ vừa phải

Trung bình: cơ bản, tích hợp ở mức vừa

Thấp: sơ sài, ít tích hợp

Rất thấp: chỉ sử dụng công cụ chỉnh sửa, lập trình và gỡ lỗi

> SITE (Multi-Site Development): đánh giá hai yếu tố đó là sắp xếp thự tự

vị trí và sự hỗ trợ trong việc giao tiếp

Để ước tính ta trả lời câu hỏi: Nhóm của bạn có được phân ra các vị trí khác nhau không? Họ giao tiếp với nhau như thế nào?

Mức cao nhất: hầu hết đều được sắp thứ tự, tương tác qua các

thiết bị đa phương tiện

Rất cao: cùng một tòa nhà, giao tiếp qua video conferencing (giao

tiếp trực tiếp bằng phim ảnh)

Cao: cùng một thành phố hoặc một vùng, giao tiếp băng rộng Trung bình: nhiều thành phố và công ty khác nhau, giao tiếp qua thư điện tử (e-mail)

Thấp: nhiều thành phố và công ty khác nhau, giao tiếp qua điện thoại & máy fax

Rất thấp: quốc tế, giao tiếp qua điện thoại, và thư điện tử

> SCED (Required Development Schedule): danh gid nhitng qui dinh rang

buộc với nhóm phát triển phần mềm Việc làm gấp rút sẽ dẫn đến việc

tốn nhiều công sức trong các giai đoạn phát triển sau

Để ước tính ta trả lời câu hỏi: Lịch làm việc có bị rút ngắn so với tiến độ

thông thường không?

Rất cao: 160% của tiến độ thông thường Cao: 130% của tiến độ thông thường Trung bình: 100% của tiến độ thông thường Thấp: 85% của tiến độ thông thường

Rat thấp: 75% của tiến độ thông thường

Trang 16

Trang 26

Để ước tính ta trả lời câu hỏi: Phần mềm của bạn sẽ chiếm dụng bao

nhiêu thời gian sử dụng CPU?

=_ Mức cao nhất: 95% thời gian thực thi

" Rất cao: 85% thời gian thực thi

= Cao: 70% thời gian thực thi

s_ Trung binh: 50% thời gian thực thi

> STOR (Storage Constraint)

Để ước tính ta trả lời câu hỏi: Phần mềm của bạn sẽ sử dụng bao nhiêu

> PVOL (Platform Volatility): ‘Platform’ có nghĩa là độ phức tạp của

phần cứng và phần mềm (hệ điều hành, hệ quản trị cơ sở dữ liệu, ) mà phần mềm cần để thực thi các tác vụ Nền tảng bao gồm các trinh biên

dịch hoặc là những hỗ trợ để phát triển hệ thống phần mềm

Để ước tính ta trả lời câu hỏi: Bao lâu những nền tảng như hệ điều hành,

hệ quản trị cơ sở dữ liệu thay đổi?

"_ Rất cao: chủ yếu thay đổi mỗi 2 tháng, có lúc thay đổi mỗi 2 ngày

= Cao: chủ yếu thay đổi mỗi 2 tháng, có lúc thay đổi mỗi 2 tuần

= Trung binh: cha yéu thay đổi mỗi 6 tháng, có lúc mỗi 2 tuần

» Thấp: chủ yếu thay đổi mỗi 12 tháng, có lúc thay đổi mỗi tháng Sản phẩm

> RELY (Require Software Reliability): đây là việc đo lường phạm vi của

các chức năng mở rộng trong dự tính qua một khoảng thời gian

Trang 17

Trang 27

Để ước tính ta trả lời câu hỏi: Hậu quả của việc phần mềm bị thất bại là gì?

“ RẤt cao: rủi ro cho cuộc sống con người

= Cao: mat mat cao vé tai chinh

= Trung binh: vira phai, đễ khôi phục lại những mất mát

= Thấp: thấp, dễ đàng khôi phục lại những mất mát

= Rat thap: không thuận tiện một ít

> DATA (Data Base Size): đo lường về sự ảnh hưởng của một lượng lớn

dữ liệu với việc phát triển phần mềm Phải quan tâm đến kích thước của

cơ sở dữ liệu là để ước lượng công sức bỏ ra để tạo những đữ liệu kiểm

thir cho chương trình

Để ước tính ta trả lời câu hỏi: Bao nhiêu dữ liệu cần thiết để kiểm tra phần mềm?

" Rất cao: Data >= 1000

#® Cao: 100 <= Data < 1000

" Trung binh: 10 < Data < 100

= Thap: Data < 10 Với:

Data = D/P = DataBaseSize(bytes) / ProgramSize(SLOC)

Đata: là dữ liệu của dự án

DataBaseSize: kích thước dự liệu được tính theo đơn vị là byte

ProgramSize: chính là SLOC (kích thước của dự án phần mềm)

> CPLX (Product Complexity): su phitc tap gdm 5 phần, kiểm soát sự vận

hành, tinh toán việc vận hành, vận hành những thiết bị phụ thuộc, quản

lý dữ liệu vận hành, và quản lý hoạt động trên giao diện người dùng Lựa chọn phạm vi hoặc những phạm vi liền nhau mà tiêu biểu cho sản phẩm hoặc một hệ thống con của sản phẩm Độ phức tạp là mức độ trung bình của các phạm vi đó

Để ước tính ta trả lời câu hói: Phần mềm sẽ phức tạp như thế nào?

Trang 18

Trang 28

Doan Thanh Thuy - 02DHTH242 Nguyên Công Nguyên - 02DHTH140

" Mức cao nhất: mã lệnh tỉnh vi, những con số khó phân tích, giao tiếp ngôn ngữ tự nhiên

= Rất cao: mã lệnh khó, những phần chênh lệch ngang nhau

= Cao: ma lénh phức tạp, phân tích số học, đữ liệu vào ra về vật lý

" Trung bình: mã lệnh lồng vào nhau, những thủ tục toán học chuẩn, nhiều file

Thấp: mã lệnh không phức tạp, một số tính toán, giao diện đơn

Để ước tính ta trả lời câu hỏi: Bạn có phát triển những thành phần có thể tái sử dụng trong phần mềm không?

" Mức cao nhất: sử dụng lại cho nhiều dự án khác nhau

"Rất cao: sử dụng lại cho dự án khác

Cao: sử dụng lại cho chương trình khác

Trung bình: sử dụng lại cho dự án này

Thấp: không sử dụng lại

> DOCU (Documentation Match to Life-cycle Needs): danh gia dya trén

sự thích hợp giữa các tài liệu của dự án với sự cần thiết trong vòng đời của phần mềm

Để ước tính ta trả lời câu hỏi: Bao nhiêu tài liệu bạn cần làm?

« RẤI cao: quá thừa so với sự cần thiết

"Cao: thừa

« Trung bình: vừa đủ

=_ Thấp: không bao quát hết các nhu cầu

Trang 19

Trang 29

= Rất thấp: không bao quát nhiều nhu cầu Bảng 2.9: Giá trị của các trọng số chỉ phí

M6 hinh Early Design chi str dung 7 cost driver

Trang 20

Trang 30

Đoàn Thanh Thuy - 02DHTH242 Nguyễn Công Nguyện - 02DHTH140

Bảng 2.10: Trọng số chỉ phí tương ứng giữa hai mô hình Early Design

và Post-Architecture

Cost Driver Cost Driver tương ứng

Mô tá trong mô hình Post-

Architecture RCPX Product Reliability RELY, DATA, CPLX,

and Complexity DOCU

PERS Personnel Capability | PCAP, ACAP, PCON

PREX Personnel Experience | PLEX, APEX, LTEX

SCED Development SCED

Driver |thấp | thấp bình cao cao

2.5 Các phương trình ước lượng:

2.5.1 Phương trình ước lượng công sức (Effort Equation)

Những ước lượng về công sức bỏ ra để phát triển phần mềm,

‘danh gia thong qua Person Months (PM), PM là lượng

; Trang 21

[sifovosb2§ |

Trang 31

Doan Thanh Thiy - 02DHTH242 Nguyễn Công Nguyên - 02DHTH140

thời gian làm việc của một người cần để phát triển một dự án phần mềm

trong một tháng Con số này không bao gồm những ngày nghỉ lễ nhưng

bao gồm những ngày nghỉ cuối tuần Ví dụ một dự án có thể ước lượng được cần 50 PM công trong kế hoạch là 11 tháng

Mô hình Post-Archifecture

Effort = 2.94 * EAF * (KSLOC)”

M6 hinh Early Design

Effort = 2.45 * KLOC * EAF

Trong đó:

EAF: 1a Effort Adjustment Factor (hé số chỉnh sửa công việc) bắt ngưồn từ cost driver

E: là lũy thừa được tính từ 5 scale driver

Số tỉ lệ E được tính trên mối quan hệ tỉ lệ giữa sự kiểm soát được và không

kiểm soát được vẻ thời gian, tiền bạc trên những kích thước khác nhau của các

dự án phần mềm

o_ Nếu E< 1.0, nghĩa là dự án trong thời gian và ngân sách cho phép

o_ Nếu E =0 nghĩa là cân bằng nhau

o Néu E > 1.0 nghĩa là dự án vượt thời gian và ngân sách cho phép

Trường hợp này thường xảy ra do hai yếu tố: chỉ phí cho những giao tiếp cá nhân tăng lên và chi phi tăng lên cho việc tích hợp hệ thống lớn

E =1.01 + 0.01 SUM(Wi)

Trong đó:

Wi la tap 5 trong số gia giảm (scale driver)

Mỗi scale driver có 1 số mức độ: rất thấp, thấp, trung bình, cao, rat cao,

mức cao nhất Mỗi mức độ có một trọng số (weight) được ký hiệu là W

Trang 22

Trang 32

Ví dụ: một dự án với tất cả cost driver ở mức trung bình và scale driver

có giá trị EAF là 1.00 và lũy thừa E là 1.0997 Giả sử rằng dự án được xây dựng bao gồm 8,000 dòng mã lệnh, COMOCO II ước lượng được

28.9 Person-Months cần để hoàn thành dự án

Effort = 2.94 * (1.0) * (8)!” = 28.9 Person-Months

2.5.2 Hệ số ước lượng công sức (Effort Adjustment Factor)

Hệ số ước lượng công sức trong phương trình công sức là sản phẩm

đơn giản của những hệ số nhân công sức (effort multiplier) tương ứng với những cost driver cho dựa án

EAF = tích các cost driver

Ví dụ:

Nếu dự án của bạn ước tính độ phức tạp rất cao (hệ số nhân công sức là

1,34), và ở mức thấp cho hệ số Language & Tools Experience (hệ số nhân công sức là 1,09), và tất cả những trọng số chỉ phí (cost driver)

được định mức là trung bình (hệ số nhân công sức là 1,00), EAEF được

tính:

Effort Adjustment Factor = EAF = 1.34 * 1.09 = 1.46

Effort = 2.94 * (1.46) * (8)"°?” = 42.3 Person-Months

2.5.3 Phương trình ước lượng kế hoạch (Schedule Equation)

Phương trình kế hoạch COCOMO II dự đoán trước số tháng yêu cầu

dé hoàn thành dự án phần mềm của bạn Trong suốt thời gian của dự án

dựa trên tuyên đoán công việc bằng phương trình công việc

Duration = 3.67 * (Effort)F

Trong đó:

Effort: là nỗ lực công việc tính từ phương trình ước lượng công sức

SE : là lũy thừa được tính từ 5 scale driver

Trang 23

Trang 33

Vị dụ:

Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 người

2.6 Mô hình tiến trình thực thi dự án (process performance model)

Dựa vào công sức (effort) được tính toán ở mô hình ước lugng Early

Design và Post-Architecture, chúng ta có thể tính tỉ lệ phần trăm công sức của

từng nhóm nhân viên tham gia dự án, công sức của từng nhóm được tính theo tỉ

lệ phần trăm sau đây:

e Thu thập và quản lý thay đổi yêu cầu dự án phan mém (requirement)

e Kiểm tra dự án phần mềm (test) chiếm 17,00% tổng công sức

e_ Triển khai dự án phần mềm (deployment) chiếm 3,50% tổng công sức

e_ Quản lý dự án phần mềm (management) chiếm 10,00% tông công sức

e Thiết lập môi trường phát triển phần mềm (evironment) chiếm 2,00%

tông công sức

Trang 24

Trang 35

¢ Quan lý cấu hình chiếm 2,00% tổng công sức

e - Đảm bảo chất lượng chiếm 2,00% tổng công sức

e Huấn luyện nhân viên (training) chiếm 1,00% tổng công sức

e Khắc phục lỗi, sự cố chiếm 1,00% tổng công sức

(Tất cả các số liệu về tỉ lệ phần trăm công sức để hoàn thành dự án ở trên được trích từ tài liệu của giáo viên hướng dẫn)

Trang 25

Trang 36

Doan Thanh Thúy - 02DHTH242 Nguyễn Công Nguyên - 02DHTH]40

mon g muén khéng?

e Sự giải thích: người sử dụng có thể hiểu được làm thế nào mô hình đưa

ra được những ước lượng không? Mô hình có giúp người dùng biết được những công việc gì cần phải làm không?

e Chi tiết mô hình có dễ đàng đưa ra sự ước lượng cho một hệ thống phần

mềm bao gồm một số các hệ thống con các nhóm chức năng con không?

Mô hình có đưa ra những phân tích về các chặng và các hoạt động trong

việc phát triển dự án phần mềm không?

h hướng tương lai: mô hình có tránh sử dụng những thông tin mà sẽ

không cần thiết khi cho đến khi dự án kết thúc không?

e Sự hạn chế: mô hình có tránh sử dụng những yếu tố không cần thiết hoặc những yếu tố không có tác động đáng kể cho kết quả ước lượng

c lượng mà ta lựa chọn Với những dự án rất quen thuộc ta nên sử

phương thức ước lượng chuyên gia vì nó có thể ước lượng nhanh

và đáng tin cậy Còn với những dự án lớn và ít quen thuộc hơn thì ta nên áp

dụng những mô hình sử dụng thuật toán như COCOMO II Nếu COCOMO II

không phù hợp thì ta có thể sử dụng ESTIMACS hoặc những phương thức ước lượng dựa trên các chức năng (function point) trong những chặng đầu của quá

trình phát triển phần mềm vì trong những giai đoạn đầu thì ước lượng theo số

Trang 37

c có

dong ma lệnh của chương trình (SLOC - Source Lines Of Code) sẽ khó hơn và

có độ tin cậy tương đối thấp

Chúng ta chọn COCOMO II bởi vì nó có những ưu điểm sau đây: có

| x 3 `

khả năng thích ứng tốt với qui trình phát triển phần mềm, đồng thời nó có khả

năng cải tiến và xác định khả năng ước lượng

Nhimg diém manh cia COCOMO II

e Don gian — can it dit ligu vao (chỉ cần dựa trên SLOC) để ước lượng

cong sitc (effort) va chi phi (cost)

Nhimng diém yéu cia COCOMO II

e Độ chính xác của các hằng số trong tính tóan quyết định độ chính xác

của kết quả

số đồng mã lệnh thực tế của chương trình

Bang 3.1: So sánh về các tham số sử dụng và các hoạt động được sử dụng để

ước lượng trong các mô hình ước lượng phần mềm

Trang 38

Continuity Personnal

Trang 39

Presentation: các form nhập liệu

Business: các thành phần (componen†) tính toán các ước lượng

Data Access: cdc thanh phan (component) truy xuất và làm việc với

Trang 40

T cố

Doan Thanh Thúy - 02DHTH242 Nguyên Công Nguyên - 02DHTH140

Chương 4

THIET KE VA THUC HIEN CHUONG TRÌNH

4.1 Quá trình hoạt động của chương trình

Chương trình hỗ trợ người dùng trong việc lập dự toán phần mềm gồm có một số chap năng tiêu biểu sau:

¢ Tạo mới dự án đồng thời lập dự toán cho dự án thông qua ước lượng và ước lượng mở rộng

sẽ có phần hỗ trợ ước lượng cho phép người dùng thống kê những mô đun và

tạo thành giá trị LOC cho dự án thông qua từng mô đun và ngôn ngữ của mô

đun đó N

thì gồm 5 cale driver và 17 cost driver Nhưng nếu mô hình ước lượng là Early

u người dùng chọn mô hình ước lượng là mô hình Post-Architecture

Design thì ta chỉ có 5 scale driver và 7 cost driver Ngoài ra trong lúc ước

lượng chúng ta có thể chọn một dự án đã ước lượng rồi tương tự với dự án mà

mình đang muốn ước lương rồi sau đó có thể để nguyên hoặc chỉnh sửa những

trọng số NI scale driver và cost driver của dự án vừa chọn Kết quả ước lượng của mỗi dự án phần mềm sẽ là công sức, thời gian và nhân lực

Thong qua công sức của kết quả ước lượng chúng ta sẽ dựa vào phần

trăm của từng nhóm nhân viên thực thi dự án ta sẽ tính được tổng số công sức

Định dạng
Số trang	88
Dung lượng	3,87 MB