Bài giảng Nhập môn Công nghệ phần mềm: Phần 3 - ThS. Phan Phương Lan

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

Thêm vào BST

Báo xấu

71
lượt xem 8
download

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

Bài giảng "Nhập môn Công nghệ phần mềm - Phần 3: Ước lượng chi phí" cung cấp cho người đọc 3 nội dung chính bao gồm: Các loại đánh giá, ước lượng chi phí, xác định giá trị phần mềm theo công văn 2589/BTTTT. Mời các bạn cùng tham khảo nội dung chi tiết.

Chủ đề:

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

Lưu

Nội dung Text: Bài giảng Nhập môn Công nghệ phần mềm: Phần 3 - ThS. Phan Phương Lan

Các loại đánh giá NHẬP MÔN  Đánh giá phân tích yêu cầu CÔNG NGHỆ PHẦN MỀM  Đánh giá thiết kế kiến trúc  Đánh giá thiết kế chi tiết  Đánh giá cài đặt PHẦN III – ƯỚC LƯỢNG  Đánh giá kiểm thử CHI PHÍ  Đánh giá mức độ tin cậy  Đánh giá mức độ sẵn sàng  Đánh giá bảo trì Ths. Phan Phương Lan 1 3 Ths. Phan Phương Lan Nội dung Đánh giá phân tích yêu cầu  Các loại đánh giá  Số lượng yêu cầu nr trong một đặc tả nr = nf + nnf  Ước lượng chi phí  nf: số lượng yêu cầu  Xác định giá trị phần mềm theo công văn  nnf: số lượng yêu cầu không chức năng 2589/BTTTT  Độ cô đọng (specificity) hay súc tích của một đặc tả (ít nhầm lẫn)  nui là số lượng các yêu cầu được thẩm định là tốt 2 4 Ths. Phan Phương Lan Ths. Phan Phương Lan 1
Đánh giá phân tích yêu cầu Đánh giá thiết kế kiến trúc  Độ hoàn chỉnh (completness) của yêu cầu chức năng  Sự độc lập của module  nu : số lượng các yêu cầu chức năng duy nhất  ni : số lượng đầu vào  S1: tổng số các module định nghĩa trong kiến trúc  ns : số lượng các trạng thái được đặc tả chương trình  Mức độ hợp lệ của các yêu cầu  S2 : số lượng các module mà sự chính xác trong hoạt động phụ thuộc vào dữ liệu đầu vào hoặc xuất ra các dữ liệu được sử dụng ở chỗ khác (không tính các  nc: số lượng yêu cầu được thẩm định là đúng module điều khiển)  nnv : số lượng yêu cầu chưa được thẩm định 5 7 Ths. Phan Phương Lan Ths. Phan Phương Lan Đánh giá thiết kế chi tiết Đánh giá thiết kế kiến trúc  Mức độ nối kết (coupling) của một phân hệ với các phân hệ khác Đối với kiến trúc phân cấp  k : hằng số tỷ lệ  Độ phức tạp cấu trúc  M được xác định:  fout(i) =fan-out(i) là số lượng module được gọi bởi module i  di : số lượng tham số dữ liệu đầu vào  Độ phức tạp dữ liệu xác định mức độ phức tạp  ci : số lượng tham số điều khiển đầu vào  d0 : số lượng tham số dữ liệu đầu ra bên trong của module i  c0 : số lượng tham số điều khiển đầu ra  v(i) : số lượng biến đầu vào và đầu ra.  gd : số lượng các biến toàn cục sử dụng như dữ liệu  Độ phức tạp kiến trúc của hệ thống  gc : số lượng các biến toàn cục sử dụng như điều khiển  w : số lượng các phân hệ đã gọi (fan-out)  r : số lượng các phân hệ gọi đến (fan-in) 6 8 Ths. Phan Phương Lan  Ths. Phan Phương Lan Các giá trị k, a, b và c phải được xác định bằng thực nghiệm 2
Đánh giá cài đặt Đánh giá mức độ tin cậy  Độ dài mã nguồn  Độ tin cậy (realibility) của phần mềm có thể được xác định bằng thời gian trung bình giữa các lỗi  n1 : số lượng các toán tử khác nhau (mean-time-between-failure)  n2 : số lượng các toán hạng khác nhau MTBF= MTTF + MTTR  N1 : số lượng các toán tử với  N2 : số lượng các toán hạng  MTTF là thời gian trung bình để có lỗi xảy ra (mean-  Số lượng lỗi dự đoán (/KDSI) time-to-failure)  MTTR là thời gian trung bình để sửa chữa lỗi (mean- time-to-repair). 9 11 Ths. Phan Phương Lan Ths. Phan Phương Lan Đánh giá kiểm thử Đánh giá mức độ sẵn sàng  Công thức xác định thời gian cần có để kiểm thử  Độ sẵn sàng (availability) của phần mềm có thể được xác định theo công thức  ftarget là số lượng lỗi dự đoán  ftotal là số lượng lỗi dự đoán thực sự xảy ra sau đó  th là thời gian kiểm thử xảy ra lỗi 10 12 Ths. Phan Phương Lan Ths. Phan Phương Lan 3
Đánh giá bảo trì Xác định kích thước phần mềm  Sự bền vững của sản phẩm phần mềm  Đếm số dòng mã lệnh (Lines of Code - LOC)  Theo số lượng chức năng (Files-Flows-Processes - FFP)  MT : số lượng các module  Tiếp cận hướng đối tượng (Object Points – OP)  Fc : số lượng các module bị thay đổi  Theo các điểm đặc điểm (Feature Points - FTP)  Fa : số lượng các module được thêm vào  Theo số lượng trường hợp sử dụng (Use Case Points  Fd : số lượng các module bị xóa đi – UCP)  Theo điểm chức năng (Function Points – FP) 13 15 Ths. Phan Phương Lan Ths. Phan Phương Lan ¦íc lượng chi phí phần mềm Xác định kích thước phần mềm  Ước lượng chi phí  Đếm số dòng mã lệnh (Lines of Code - LOC)  Dựa trên kích thước, độ phức tạp  Có thể sử đếm theo đơn vị ngàn dòng lệnh  Dựa vào dữ liệu quá khứ (thousand lines of code – KLOC, thousand delivered source instructions - KDSI) khi số dòng  Chi phí tỉ lệ với công sức (effort) phát triển phần mềm mã lệnh của một phần mềm là khá lớn.  Chi phí tính dựa theo công sức cho các giai đoạn phát  Các vấn đề cần quan tâm khi đếm: triểm phần mềm: khởi đầu, phân tích, thiết kế, cài đặt,  Tính toán kích thước cho các giai đoạn khác nhau kiểm thử nhưng chưa tính đến giai đoạn bảo trì.  Cài đặt trên các ngôn ngữ lập trình khác nhau  Đơn vị tính của công sức: người-tháng (hoặc người-  Cách đếm số dòng mã lệnh ngày)  Mã lệnh tạo ra bằng công cụ dùng để hỗ trợ phát 14 triển 16 Ths. Phan Phương Lan Ths. Phan Phương Lan 4
Xác định kích thước phần mềm Xác định kích thước phần mềm  Theo số lượng chức năng (Files-Flows-Processes  Theo các điểm đặc điểm (Feature Points - - FFP) FTP)  Áp dụng đối với các ứng dụng xử lý dữ liệu có kích thước trung bình.  Sử dụng cho các phần mềm chịu ảnh hưởng  Tập tin (File): tập hợp các mẩu tin (vật lý hay luận lý) mạnh về giải thuật: có liên hệ với nhau.  Thời gian thực (real-time software)  Dòng (Flow): giao diện dữ liệu giữa sản phẩm và môi  Nhúng (embedded software) trường như màn hình, báo cáo,…  Xử lý (Process): (về chức năng mà nói ) đó chính là  Truyền thông (communication software) một định nghĩa logic hay toán học dùng để thao tác trên dữ liệu. 17 19 Ths. Phan Phương Lan Ths. Phan Phương Lan Xác định kích thước phần mềm Xác định kích thước phần mềm  Theo số lượng trường hợp sử dụng (Use Case Points – UCP) Số lượng dòng mã lệnh ước lượng theo các trường hợp sử dụng:  Tiếp cận hướng đối tượng (Object Points – OP)  Kích thước phần mềm được xác định theo sẽ  N: số lượng trường hợp sử dụng hiện hành dựa trên số lượng các kịch bản, các lớp chính,  LOCavg : số lượng LOC trung bình cho hệ thống cùng kiểu  LOCadjust : thể hiện sự điều chỉnh dựa trên n phần trăm của LOCavg lớp hỗ trợ, tỷ lệ giữa số lượng lớp hỗ trợ và lớp với n được định nghĩa cục bộ và thể hiện sự khác nhau giữa phần chính và số lượng các hệ thống con. mềm này với các phần mềm khác (tính trung bình)  Sa : số lượng kịch bản hiện tại cho mỗi trường hợp sử dụng  Sh : số lượng kịch bản trung bình cho mỗi trường hợp sử dụng cho hệ thống cùng kiểu  Pa : số lượng trang hiện tại cho mỗi trường hợp sử dụng  Ph : số lượng trang trung bình cho mỗi trường hợp sử dụng cho hệ 18 thống cùng kiểu 20 Ths. Phan Phương Lan Ths. Phan Phương Lan 5
Xác định kích thước phần mềm  Theo điểm chức năng (Function Points – FP): Các loại Xác định kích thước phần mềm điểm chức năng  EI: External Inputs  EO là một tiến trình căn bản trong đó dữ liệu phát  EO: External Outputs sinh được truyền từ bên trong ra bên ngoài phạm  EQ: External Inquiries vi ứng dụng.  ILF: Internal Logical File  Nó có thể là report hay các tập tin kết xuất được gửi  EIF: External Interface File cho ứng dụng khác và được tạo ra từ những thông tin có trong một hay nhiều ILF hoặc EIF.  Dữ liệu phát sinh là các dữ liệu được xử lý dựa trên truy tìm trực tiếp và hiệu chỉnh thông tin từ các ILF/IEF. (Dữ liệu phát sinh thường là kết quả của các giải thuật hay sự tính toán.) 21 23 Ths. Phan Phương Lan Ths. Phan Phương Lan Xác định kích thước phần mềm Xác định kích thước phần mềm  EI là một tiến trình căn bản trong đó dữ liệu được  EQ là một tiến trình căn bản có hai chiều nhập dữ truyền từ bên ngoài vào bên trong phạm vi của liệu và xuất dữ liệu nhằm truy xuất dữ liệu từ một ứng dụng. hay nhiều ILF/EIF.  Dữ liệu có thể từ màn hình nhập liệu hoặc từ một ứng  Dữ liệu nhập không cập nhật ILF/EIF và dữ liệu xuất dụng khác. không phải là dữ liệu phát sinh.  Dữ liệu có thể là thông tin điều khiển hoặc thông tin  EQ có thể là các thao tác tìm kiếm, truy vấn dữ liệu từ nghiệp vụ. các ILF/EIF.  Dữ liệu (trừ thông tin điều khiển) được sử dụng để cập nhật một hoặc nhiều ILF. 22 24 Ths. Phan Phương Lan Ths. Phan Phương Lan 6
Xác định kích thước phần mềm Xác định kích thước phần mềm  ILF là một nhóm các dữ liệu có liên quan về mặt  Công thức tính điểm chức năng FP logic có thể nhận dạng bởi người sử dụng trong FP = Điểm chức năng thô x (0.65 + 0.01 x Tổng phạm vi ứng dụng và được cập nhật thông qua EI. các mức độ ảnh hưởng của các nhân tố hiệu  EIF là một nhóm các dữ liệu có liên quan về mặt chỉnh ) logic chỉ được sử dụng cho mục đích tham khảo.  14 nhân tố hiệu chỉnh (có mức độ ảnh hưởng Dữ liệu nằm ở nên ngoài phạm vi ứng dụng và nằm trong phạm vi từ 0 (không quan trọng hay được cập nhật bởi EI của các ứng dụng khác. Nó không thích hợp hay không ảnh hưởng) tới 5 được lưu trữ trong tập tin. (cực kỳ quan trọng hay cần thiết tuyệt đối hay ảnh hưởng nhất) 25 27 Ths. Phan Phương Lan Ths. Phan Phương Lan Xác định kích thước phần mềm Xác định kích thước phần mềm  Trọng số cho các dạng chức năng  Các nhân tố hiệu chỉnh 1. Data communication 8. Online update 2. Distributed function 9. Complex processing 3. Performance 10. Reusability 4. Heavily used configuration 11. Installation ease 5. Transaction rate 12. Operation ease  Công thức tính số điểm chức năng chưa được hiệu chỉnh 6. Online data entry 13. Multiple site UFP = a1 x EI + a2 x EO + a3 x EQ + a4 x ILF + a5 x EIF 7. End-user efficiency 14. Facilitate change với a1, a2, a3, a4, a5 là giá trị các điểm chức năng theo độ phức tạp cho trong bảng trên. 26 28 Ths. Phan Phương Lan Ths. Phan Phương Lan 7
Xác định kích thước phần mềm ¦íc lượng chi phí phần mềm  Điểm chức năng FP có thể được dùng để dự đoán số dòng  Ước lượng thực nghiệm lệnh LOC  Mô hình Walston và Felix LOC = AVC * số điểm chức năng FP  Mô hình Bailey và Basili với AVC : yếu tố phụ thuộc vào ngôn ngữ lập trình được  Mô hình COCOMO sử dụng  Tham khảo thêm các mô hình khác trong giáo trình 29 31 Ths. Phan Phương Lan Ths. Phan Phương Lan Xác định kích thước phần mềm Mô hình Walston và Felix  Một trong các mô hình giải thuật sớm nhất (1977)  Mô hình được đề nghị sau khi nghiên cứu 60 dự án của IBM  Có 29 yếu tố ảnh hưởng tới hiệu suất  Công thức ước lượng công sức E E = 5.2 x S 0.91 (người - tháng) Với S là kích thước được ước lượng của hệ thống (theo KDSI) Tham khảo thêm Bảng chuyển đổi giữa LOC và FP trong  Công thức ước lượng thời gian thực hiện T Giáo trình Nhập môn Công Nghệ Phần Mềm T= 2.5 x E0.35 (tháng) 30 32 Ths. Phan Phương Lan Ths. Phan Phương Lan 8
Mô hình Walston và Felix Mô hình Bailey và Basili  Mỗi yếu tố sẽ nhận 1 trong 3 giá trị tùy thuộc vào  Mô hình được đề nghị năm 1981 bởi Bailey và Basili sự tác động của nó tới hiệu suất  Mô hình này sử dụng cơ sở dữ liệu của 18 dự án viết bằng ngôn ngữ Fortran tại trung tâm Goddard Space Flight của  1 (cao): làm tăng hiệu suất NASA  0 (trung bình): không ảnh hưởng tới hiệu suất  Các nhóm yếu tố ảnh hưởng tới công sức: phương pháp,  -1 (thấp): làm giảm hiệu suất độ phức tạp và kinh nghiệm  Công thức ước lượng công sức ban đầu E E = 5.5 + 0.73 x S 1.16 (người - tháng) với S là kích thước được ước lượng của hệ thống (theo KDSI) 33 35 Ths. Phan Phương Lan Ths. Phan Phương Lan Mô hình 1. Customer interface complexity 16. Use of design and code Walston 2. User participation in requirements inspections 17. Use of top-down development và Felix definition 3. Customer-originated program design changes 18. Use of a chief programmer team Mô hình Bailey và Basili 4. Customer experience with the 19. Overall complexity of code application area 5. Overall personnel experience 20. Complexity of application processing  Mỗi yếu tố ảnh hưởng tới công sức nhận một trong các 6. Percentage of development programmers who participated in the 21. Complexity of program flow giá trị từ 0 đến 5 design of functional specifications 7. Previous experience with the 22. Overall constraints on program’s Total methodology Cumulative complexity Cumulative experience operational computer design (METH) (CPLX) (EXP) 8. Previous experience with the 23. Design constraints on the programming language program’s main storage Tree charts Customer interface Programmer 9. Previous experience with 24. Design constraints on the complexity qualifications applications of similar size and program’s timing Top-down design Application complexity Programmer machine complexity experience 10. Ratio of average staff size to 25. Code for real-time or interactive project duration (people per month) operation or for execution under Formal documentation Program flow complexity Programmer language severe time constraints experience 11. Hardware under concurrent 26. Percentage of code for delivery Chief programmer Internal communication Programmer application development teams complexity experience 12. Access to development computer 27. Code classified as Formal training Database complexity Team experience open under special request nonmathematical application and input/output formatting programs Formal test plans External communication 13. Access to development computer 28. Number of classes of items in the complexity closed database per 1000 lines of code Design formalisms Customer-initiated 14. Classified security environment 29. Number of pages of delivered program design changes for computer and at least 25% of documentation per 1000 lines of code Code reading programs and data 15. Use of structured programming 34 Unit development 36 Ths. Phan Phương Lan folders Ths. Phan Phương Lan 9
Mô hình COCOMO 81 Mô hình COCOMO 81 trung gian  Mô hình COCOMO 81 được đề nghị bởi Boehm  C¸c hÖ sè ph¸t triÓn  Dạng cơ bản: áp dụng cho nhóm nhỏ, môi trường quen thuộc  Dạng trung bình: áp dụng cho dự án khá lớn, có một ít kinh nghiệm  Dạng lớn: áp dụng cho dự án lớn, môi trường mới  Bảng các hệ số khi phát triển sản phẩm (sử dụng mô hình COCOMO 81 trung gian) 37 39 Ths. Phan Phương Lan Ths. Phan Phương Lan Mô hình COCOMO 81 trung gian Mô hình COCOMO 2  Công sức E = ab x S^bb x EAF  Mô hình COCOMO 81 được phát triển trên giả  ab và bb: được xác định dựa vào bảng mức độ khó khi thiết rằng tiến trình phát triển phần mềm thác nước phát triển phần mềm được sử dụng và tất cả các phần mềm được phát  EAF (effort adjustment factor): hệ số hiệu chỉnh công triển từ đầu. sức. Nó được tính bằng tích của các hệ số phát triển  Mô hình COCOMO 2 được thiết kế để thích ứng  S là kích thước được ước lượng của hệ thống (theo với những cách tiếp cận khác nhau đối với sự phát KDSI) triển phần mềm  Thời gian T = cb x E^db  Số lượng người P = E/T 38 40 Ths. Phan Phương Lan Ths. Phan Phương Lan 10
Mô hình COCOMO 2 Mô hình COCOMO 2  COCOMO 2 kết hợp chặt chẽ các mô hình con nhằm đưa ra các dự đoán phần mềm chi tiết  Các mô hình con trong COCOMO 2:  Mô hình Application composition. Mô hình này giả sử rằng hệ thống được tạo thành từ các thành phần có thể tái sử dụng. Nó được thiết kế để ước lượng công sức phát triển bản mẫu.  Mô hình Early design: được sử dụng tại giai đoạn thiết kế kiến trúc khi các yêu cầu là sẵn (và thiết kế chi tiết vẫn chưa được bắt đầu) 41 43 Ths. Phan Phương Lan Ths. Phan Phương Lan Mô hình COCOMO 2 Mô hình Application composition  Các mô hình con trong COCOMO 2:  Để ước lượng công sức cần để lập bản mẫu các dự án và cho các dự án được phát triển bằng cách kết hợp các thành  Mô hình Reuse: được sử dụng để tính công sức tích phần sẵn có. hợp các thành phần có thể dùng lại được và / hoặc mã  Được dựa trên số lượng điểm ứng dụng (đối tượng). chương trình mà nó được tự động sinh ra bởi các công cụ dịch chương trình hay thiết kế. Nó thường được sử  Công thức ước lượng công sức dụng kết hợp với mô hình Post - architecture. E = ( NAP x (1 - %reuse/100 ) ) / PROD (người – tháng)  Mô hình Post-architecture: được sử dụng ngay khi kiến  NAP: số lượng điểm ứng dụng. trúc hệ thống đã được thiết kế và các thông tin chi tiết  %reuse: % mã lệnh được tái sử dụng từ các dự án khác. hơn về hệ thống là sẵn có.  PROD: hiệu suất, phụ thuộc vào kinh nghiệm và khả năng của nhà phát triển cũng như tính trưởng thành và 42 khả năng của công cụ . 44 Ths. Phan Phương Lan Ths. Phan Phương Lan 11
Mô hình Application composition Mô hình Application composition  Bảng xác định hiệu suất PROD  Tính số lượng điểm ứng dụng  Đếm số lượng màn hình, báo cáo và module Developers’ experience and Very low Low Nominal High Very  Xác định độ phức tạp cho từng thành phần (1 màn hình hay capability high CASE maturity and Very low Low Nominal High Very 1 báo cáo hay 1 module) theo bảng sau capability high For Screens For Reports Productivity factor 4 7 13 25 50 Number and source of data tables Number and source of data tables Number of Total < 4 Total < 8 Total 8+ Number of Total < 4 Total < 8 Total 8+ views (3 sections (3 contained server, server, server, >5 contained server, server, 3- server,
Mô hình Early design Mô hình Early design  Ước lượng công sức khi các yêu cầu đã được chấp nhận và thiết kế hệ thống đang được thực  C¸c hÖ sè W hiện  Công thức ước lượng công sức E = a x Sb x M với  M: tích của 7 hệ số nhân  a : hằng số thực nghiệm (2.5)  S kích thước được ước lượng của hệ thống (theo KDSI)  b = 1.01 + 0.01 x Wi (i:1 - 5) 49 51 Ths. Phan Phương Lan Ths. Phan Phương Lan Mô hình Early design Mô hình Post-architecture  Các hệ số nhân phản ánh khả năng của nhà phát triển, các yêu cầu phi chức năng, sự hiểu biết rõ về nền tảng  Sử dụng cùng một công thức như mô hình early phát triển, v.v. design nhưng có tới 17 hệ số nhân  RCPX - product reliability and complexity  Công sức E = a x Sb x M với  RUSE - the reuse required  M: tích của 17 hệ số nhân  PDIF - platform difficulty  a : hằng số thực nghiệm (2.5)  PREX - personnel experience  S kích thước được ước lượng của hệ thống (theo  PERS - personnel capability KDSI)  SCED - required schedule  b = 1.01 + 0.01 x Wi (i: 1 – 5)  FCIL - the team support facilities  Giá trị của các hệ số này nằm trong khoảng từ 0 (rất thấp) đến 5 (vô cùng cao) 50 52 Ths. Phan Phương Lan Ths. Phan Phương Lan 13
Mô hình Post-architecture  17 hệ số nhân M 53 Ths. Phan Phương Lan Xác định giá trị phần mềm theo công văn 2589/BTTTT  Sinh viên tự đọc giáo trình: Chương 5 + Phụ lục C 54 Ths. Phan Phương Lan 14