2.2.1. Công cụ Cocomo
• Cocomo viết tắt của Constructive Cost Model [8].
Cocomo là mô hình do Barry Boehm thiết kế nhằm dự báo (ƣớc tính) số
Ngƣời – Tháng (man-months) trong triển khai sản phẩm phần mềm.
Mô hình này dựa trên khảo sát (nghiên cứu) 60 dự án tại công ty Northrop
Grumman cuối năm 2002.
Chƣơng trình đƣợc viết bằng ngôn ngữ PL/I (Programming Language/One.
Ngôn ngữ thƣơng mại và khoa học phối hợp nhiều chức năng của FORTRAN và COBOL), từ 2000 đến 100.000 dòng lệnh.
• Cocomo bao gồm 3 dạng:
Basic COCOMO.
Intermediate COCOMO: Chi phí đƣợc tính nhƣ độ lớn của phần mềm theo
dòng lệnh. Cộng thêm đánh giá sản phẩm, phần cứng, nhân lực và các thuộc tính của dự án.
Detailed COCOMO: tích hợp mọi đặc trƣng của Cocomo trung gian cộng
thêm đánh giá của chi phí ảnh hƣởng (phân tích, thiết kế,…) trong mỗi giai đoạn của qui trình công nghệ phần mềm (the software engineering process) • Cocomo có thể áp dụng cho ba lớp dự án phần mềm:
Organic Projects: đội ngũ nhỏ có kinh nghiệm ứng dụng tốt, và làm việc trên môi trƣờng với những yêu cầu không quá cứng nhắc.
Semi-detached Projects: đội ngũ có kinh nghiệm hỗn hợp, và làm việc trên
môi trƣờng với những yêu cầu không quá cứng nhắc.
Embedded Projects: đƣợc triển khai trong điều kiện chặt chẽ phần cứng, phần
mềm và các ràng buộc về vận hành.
2.2.1.1. Basic COCOMO.
Basic COCOMO: Mô hình cho giá trị đơn, chi phí đƣợc tính nhƣ độ lớn của phần mềm theo dòng lệnh.
Phƣơng trình của Basic COCOMOcó dạng:
E=ab(KLOC)bb; D=cb(E)db; P=E/D Trong đó:
E = Ƣớc tính của Ngƣời/Tháng
D = Thời gian triển khai tính theo tháng
KLOC = Số dòng lệnh (đơn vị=1000) ƣớc tính của sản phẩm dự án phần
mềm.
Hệ số ab, bb, cb và db đƣợc cho bởi bảng sau đây:
Software Project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.2 2.5 0.32
P = Số ngƣời đƣợc yêu cầu
Cocomo cơ bản rất tốt cho ƣớc tính chi phí thô, dễ dàng và nhanh. Tuy nhiên, sự chính xác sẽ bị giới hạn vì thiếu một số nhân tố chƣa kể đến là sự khác nhau trong ràng buộc về phần cứng, kinh nghiệm và khả năng chuyên nghiệp của con ngƣời, việc sử dụng các công cụ hiện đại và các đặc trƣng khác có ảnh hƣởng đến chi phí phần mềm.
Intermediate COCOMO là mở rộng của mô hình Basic COCOMO, và đƣợc dùng để ƣớc tính thời gian lập trình trong triển khai sản phẩm phần mềm. Sự mở rộng này, xem xét trên một tập hợp “Chi phí của các đặc trƣng các bộ phận điều khiển (driver)” đƣợc chia thành 4 nhóm (15 tính chất):
Đặc trưng của sản phẩm:
Yêu cầu về tính độ tin cậy của phần mềm
Khối lƣợng CSDL (database) của ứng dụng
Tính phức tạp của sản phẩm.
Đặc trƣng của phần cứng
Ràng buộc về tính năng Run-time
Ràng buộc về Bộ nhớ
Tính không ổn định của môi trƣờng máy ảo.
Yêu cầu về thời gian chuyển hƣớng (turnabout time)
Đặc trưng về Chuyên gia.
Khả năng phân tích
Khả năng về kỹ sƣ PM (Software engineer)
Kinh nghiệm ứng dụng
Kinh nghiệm về máy ảo
Kinh nghiệm về ngôn ngữ lập trình
Đặc trưng về Dự án
Sử dụng các công cụ phần mềm
Ứng dụng các phƣơng pháp của CNPM (software engineering)
Yêu cầu về triển khai lịch biểu (development schedule)
Mỗi tính chất đƣợc đánh giá (cho điểm) theo thang điểm có 6 mức từ rất chậm (very low) đến quá cao (extra high). Dựa trên thang điểm, hệ số cố gắng (effort multiplier) sẽ đƣợc xác định theo bảng sau: Tích các hệ số cố gắng = EAF (Effort Adjustment Factor, thƣờng có giá trị từ 0.9 - 1.4.)
Cost Drivers Ratings Rất chậm Chậm Bình thƣờng Cao Rất cao Quá cao Đặc trƣng của sản phẩm
Yêu cầu về độ tin cậy phần mềm 0.75 0.88 1.00 1.15 1.40
Khối lƣợng CSDL của ứng dụng 0.94 1.00 1.08 1.16
Tính phức tạp của sản phẩm 0.70 0.85 1.00 1.15 1.30 1.65
Đặc trƣng về phần cứng
Ràng buộc về tính năng Run-time. 1.00 1.11 1.30 1.66
Ràng buộc về bộ nhớ 1.00 1.06 1.21 1.56
Tính không ổn định của môi trƣờng máy ảo 0.87 1.00 1.15 1.30
Yêu cầu về thời gian turnabout 0.87 1.00 1.07 1.15
Đặc trƣng về chuyên gia
Khả năng phân tích 1.46 1.19 1.00 0.86 0.71
Kinh nghiệm ứng dụng 1.29 1.13 1.00 0.91 0.82
Khả năng của kỹ sƣ phần mềm 1.42 1.17 1.00 0.86 0.70
Kinh nghiệm về máy ảo. 1.21 1.10 1.00 0.90
Kinh nghiệm về ngôn ngữ lập trình 1.14 1.07 1.00 0.95
Đặc trƣng về dự án
Ứng dụng của phƣơng pháp CNPM. 1.24 1.10 1.00 0.91 0.82
Sử dụng các công cụ phần mềm 1.24 1.10 1.00 0.91 0.83
Yêu cầu về development schedule 1.23 1.08 1.00 1.04 1.10
Phƣơng trình Intermediate COCOMO có dạng:
E=ai(KLOC)(bi).EAF
Trong đó:
– E = Ƣớc tính của Ngƣời/Tháng
– KLOC = Số dòng lệnh (đơn vị=1000) ƣớc tính của sản phẩm dự án
– EAF đƣợc cho bởi bảng trên.
– Hệ số ai và bi đƣợc cho bởi bảng sau đây.
Software Project ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
Thời gian triển khai D đƣợc tính từ E tƣơng tự nhƣ Cocomo Cơ bản
2.2.1.3. Mô hình Cocomo II.
Cocomo II là mô hình cho phép ƣớc tính chi phí, sự cố gắng và lịch biểu khi lập kế hoạch cho một dự án phần mềm mới [6]. Gồm có 3 module: Tổng hợp ứng dụng; Thiết kế sớm; và Hậu thiết kế cụ thể là;
Mô hình tổng hợp ứng dụng bao gồm các nỗ lực làm bản mẫu để phát hiện và hạn chế những rủi ro tiềm năng nhƣ giao diện ngƣời dùng, tƣơng tác giữa phần mềm và môi trƣờng triển khai, hiệu năng, và sự phát triển của công nghệ.
Mô hình thiết kế sớm bao gồm việc tìm hiểu các kiến trúc phần mềm/hệ thống
khác nhau và các khái niệm về nghiệp vụ. Trong giai đoạn này, không có đủ thông tin hỗ trợ việc ƣớc lƣợng chính xác chi phí. Chức năng tƣơng ứng với giai đoạn này trong mô hình Cocomo II bao gồm việc sử dụng điểm chức năng và một tập hợp gồm 7 “hƣớng dẫn chi phí”.
Mô hình hậu kiến trúc bao gồm việc xây dựng và bảo trì một sản phẩm phần
mềm thực sự (không còn nằm trên thiết kế nữa). Trong giai đoạn này, sẽ tiết kiệm đƣợc chi phí nếu một kiến trúc vòng đời phần mềm đƣợc xây dựng từ trƣớc, phù hợp với nhiệm vụ của hệ thống và thao tác thực hiện, lƣờng trƣớc rủi ro; và kiến trúc này đƣợc thiết lập nhƣ là một khung làm việc cho sản phẩm. Mô hình Cocomo II tƣơng ứng với giai đoạn này cũng tƣơng tự nhƣ mô hình Cocomo gốc và Ada Cocomo. Nó sử dụng các hƣớng dẫn nguồn (Source Instruction) và/hoặc điểm chức năng; một tập gồm 17 hƣớng dẫn chi phí; một tập gồm 5 nhân tố xác định số mũ tỷ lệ của dự án. Những nhân tố này thay thế cho các phƣơng thức phát triển trong mô hình Cocomo gốc, cũng nhƣ 4 nhân tố của mô hình Ada Cocomo [6].
Tóm lại, Cocomo II cung cấp một chuỗi ba giai đoạn các mô hình ƣớc lƣợng cho các dự án phần mềm về tạo ứng dụng, tích hợp hệ thống và kiến trúc nền tảng.
Về chiến lƣợc xử lý, những dự án phần mềm thuộc khu vực tạo ứng dụng, tích
hợp hệ thống và kiến trúc nền tảng sẽ bao gồm sự kết hợp của ba mô hình xử lý chính. Mô hình phù hợp sẽ phụ thuộc vào từng ứng dụng cụ thể.
Mô hình Cocomo II thiết lập ban đầu quan hệ ƣớc lƣợng chi phí (CER) đƣợc cung cấp bởi mô hình Cocomo II [4]. Tham số CER cho phép ngƣời dùng biểu diễn khả năng xử lý thông tin theo từng giai đoạn thời gian về mặt kích thƣớc phần mềm tƣơng đƣơng, và ƣớc lƣợng chi phí đầu tƣ chu kỳ sống của phần mềm theo từng giai đoạn về kích cỡ của phần mềm và sản phẩm của dự án, con ngƣời và thuộc tính dự án.
Vấn đề cốt lõi của mô hình chi phí phần mềm Cocomo II là quan hệ toán học gồm 24 biến sử dụng để ƣớc lƣợng số nỗ lực của ngƣời – tháng đƣợc yêu cầu để phát triển sản phẩm phần mềm đƣợc định nghĩa bởi các biến. Bằng cách nhân số nỗ lực của dự án với chi phí trên một ngƣời – tháng, chúng ta có thể ƣớc lƣợng đƣợc chi phí của dự án.
Các tham số của Cocomo II bao gồm kích cỡ tƣơng đƣơng của sản phẩm trong hàng nghìn dòng lệnh (KSLOC) hoặc điểm chức năng; đặc điểm về con ngƣời nhƣ: khả năng, kinh nghiệm, tính liên tục; thuộc tính dự án nhƣ thời gian thực hiện, ràng buộc về lƣu trữ; thuộc tính sản phẩm nhƣ độ phức tạp, khả năng tái sử dụng và yêu cầu về độ tin cậy.
Các phân tích hồi qui đã xác định kích thƣớc và ảnh hƣởng của từng tham số lên nỗ lực dự án. Ví dụ, ảnh hƣởng của tham số RELY (Required Software Reliability) lên hiệu năng dự án đƣợc thể hiện ở hình sau:
Hình 2.1: Quan hệ giữa chi phí phát triển phần mềm và yêu cầu độ tin cậy (RELY)
Dựa vào tỷ lệ đánh giá RELY đƣợc hiển thị bên trái của hình 2.1, về nguy cơ lỗi hoặc ảnh hƣởng của lỗi về hành vi điều hành sản phẩm và kết quả. Kể từ khi những nỗ lực xảy ra gần kết thúc, khi dự án về mức độ trung bình của nó. Nó bổ sung vào 54% thời gian trong quá trình thử nghiệm trƣớc khi trả lời khách hàng về sản phẩm. Phân tích hồi quy của 161 dự án sản xuất một phạm vi nỗ lực tƣơng đối giữa các báo cáo dự án về độ tin cậy yêu cầu là rất thấp và các báo cáo dự án đánh giá rất cao.
Hệ số nỗ lực tƣơng ứng liên quan đến một giá trị trên danh nghĩa là 1.0 cho thấy chi phí liên quan một nguồn cho mỗi mức đánh giá, giả định rằng mức độ đánh giá của biến khác là liên tục. Vì vậy, chi phí tƣơng đối của một sản phẩm quan trọng an toàn sẽ là 26% cao hơn so với một sản phẩm phần mềm trong nội bộ trên danh nghĩa. Giá trị này thể hiện ảnh hƣởng của các nỗ lực để ngăn chặn, phát hiện, và sửa chữa các lỗi phần mềm so với việc giảm thiểu nỗ lực phải làm lại do phát hiện lỗi sớm.
Các kết quả trên đƣợc tóm tắt trong hình 2.1. Dựa trên dữ liệu từ một tập hợp con của dự án, chúng tôi cũng có thêm một quy mô sản phẩm sơ bộ của thời gian trung bình giữa các lỗi (Mean Time Between Failures - MTBF) tƣơng ứng với các tác động liên quan của lỗi sản phẩm, xảy ra từ 1 giờ MTBF cho RELY rất thấp đến 300K giờ MTBF cho RELY rất cao, nó cũng đƣợc hiển thị trong hình 2.1. Ví dụ, mức thấp, tổn thất, dễ dàng khôi phục đƣợc kết hợp với RELY mức thấp dựa vào đánh giá phù hợp cho 1 MTBF là 10 giờ, hoặc khoảng lỗi thất bại nghiêm trọng mỗi ngày. Trong khi một đánh giá RELY cao tƣơng ứng với một MTBF là 10, 000 giờ, hoặc khoảng 1.14 năm.
2.2.2. Công cụ Coqualmo
COQUALMO (Constructive Quality Model) là một mô hình ƣớc lƣợng có thể sử dụng để dự đoán số lƣợng các lỗi còn lại/KSLOC (hàng nghìn dòng lệnh) hoặc lỗi/FP (Function Point) trong một sản phẩm phần mềm [7]. Nó cho phép ngƣời dùng xác định các mức đầu tƣ theo pha thời gian trong việc cải tiến thuộc tính độ tin cậy, và để ƣớc lƣợng kết quả các mức của thuộc tính độ tin cậy theo từng pha thời gian. Phiên bản hiện tại của Coqualmo ƣớc lƣợng mật độ lỗi dƣới dạng một mô hình giới thiệu lỗi ƣớc tính tỉ lệ lỗi mà yêu cầu phần mềm, thiết kế và mã đƣợc giới thiệu, và một mô hình loại bỏ lỗi.
Hình 2.2: Cấu trúc mô hình COQUALMO
Tỉ lệ lỗi giới thiệu đƣợc xác định nhƣ một hàm của tỷ lệ cơ bản đƣợc thay đổi từ các thừa số xác định từ Cocomo II với các thông số thuộc tính dự án, con ngƣời, thuộc tính sản phẩm. Ví dụ, một xếp hạng Very Low cho ứng dụng kinh nghiệm sẽ dẫn đến một sự gia tăng đáng kể trong yêu cầu về lỗi giới thiệu, và sự gia tăng nhỏ trong lỗi về mã. Mô hình gỡ bỏ lỗi ƣớc lƣợng tỷ lỗi gỡ bỏ nhƣ một hàm của mức độ đầu tƣ trong công cụ phân tích tự động, xem xét chéo và thực hiện kiểm thử.
Tỷ lệ lỗi giới thiệu cơ sở cho Coqualmo là 9 lỗi yêu cầu/KSLOC, 19 lỗi thiết kế/KSLOC và 33 lỗi mã/KSLOC. Để cho đơn giản, có thể làm tròn đến 10, 20, 30 tổng cộng là 60 khiếm khuyết giới thiệu. Coqualmo ƣớc lƣợng hàm giảm mật độ lỗi thể hiện ở hình 2.3. COCOMO II COQUALMO Mô hình giới thiệu khiếm khuyết Mô hình loại bỏ khiếm khuyêt Số lƣợng khiếm khuyết còn lại Mật độ khiếm khuyết trên một đơn vị kích cỡ Phân tích tự động Xem xét chéo Thực hiện kiểm thử Ƣớc lƣợng kích cỡ phần mềm Thuộc tính về con ngƣời, sản phẩm, dự án, nền tảng của phần mềm
Hình 2.3: Quan hệ giữa lỗi phát hiện và xếp hạng gỡ lỗi
2.3. Phân tích chất lƣợng phần mềm dựa trên giá trị. 2.3.1. Chất lƣợng phần mềm dựa trên giá trị (VBSQ). 2.3.1. Chất lƣợng phần mềm dựa trên giá trị (VBSQ).
2.3.1.1. Định nghĩa thuộc tính chất lượng phần mềm dựa trên giá trị.
VBSQ (value-based software quality): chất lƣợng phần mềm dựa trên giá trị. Thuộc tính chất lƣợng phần mềm dựa trên giá trị đƣợc định nghĩa khác với cách định nghĩa truyền thống trong đó chúng đƣợc tham chiếu trực tiếp tới những giá trị của các đối tƣợng quan trọng. Những định nghĩa truyền thống nhƣ thời gian trung bình giữa các lỗi MTBF (Mean Time Between Failures) cho độ tin cậy đƣợc tham chiếu tới các đặc tính mà các đối tƣợng dựa vào nhƣ: độ chính xác, hiệu năng. Các định nghĩa này đi xa hơn so với những định nghĩa truyền thống không những để thay đổi trong mô tả mà còn để phân biệt giữa sự phụ thuộc giá trị của các đối tƣợng. Các định nghĩa cũng cố gắng mang lại sự sắp xếp về các thuật ngữ nhƣ độ an toàn, sự tồn tại, tính bảo mật, tính riêng tƣ.
a. Các thuộc tính protection: tính an toàn, tính bảo mật, tính riêng tư.
Có rất nhiều định nghĩa khác nhau về tính an toàn, tính bảo mật, tính riêng tƣ. Chúng ta sẽ đề xuất định nghĩa chúng dựa trên giá trị sao cho ít mơ hồ nhất, thích hợp với những chuẩn hiện tại, và hợp lý. Ta có bảng định nghĩa về tính an toàn, tính bảo mật, tính riêng tƣ nhƣ sau:
Bảng 2.1: Khung định nghĩa về tính an toàn, tính bảo mật, tính riêng tƣ
Bản chất rủi ro
Nguyên nhân rủi ro Quá trinh xác thực,
nguyên nhân tự nhiên
Quá trình không xác thực
Rủi ro vật lý Tính an toàn Tính an toàn, bảo mật
Rủi ro thông tin Tính riêng tƣ Tính riêng tƣ, bảo mật
Định nghĩa hiện tại về độ an toàn, bảo mật, riêng tư
Sử dụng IEEE-1228 [IEEE 1994] theo tiêu chuẩn dựa trên Kế hoạch an toàn phần mềm. Định nghĩa về “độ an toàn phần mềm” là “tự do từ các mối nguy hiểm phần mềm”; “mối nguy hiểm” là tình trạng của phần mềm mà xảy ra sự cố; và “sự cố” là "một sự kiện không có kế hoạch hay một loạt các sự kiện mà kết quả là gây chết, thiệt hại, hƣ hỏng hệ thống".
Vì vậy, định nghĩa về độ an toàn tập trung vào việc bảo vệ các thực thể vật lý (gây chết, tổn thƣơng, thiệt hại tới thiết bị, tài sản hoặc môi trƣờng). Ngƣợc lại, định nghĩa về "bảo mật thông tin" trong NIST đặc biệt công bố 800-37 tập trung vào việc bảo vệ tài sản công nghệ thông tin. Nó định nghĩa là "Việc bảo vệ thông tin và hệ thống thông tin từ những truy cập trái phép, sử dụng, tiết lộ, làm gián đoạn, sửa đổi, hoặc tiêu huỷ để cung cấp bảo mật, tính toàn vẹn và tính sẵn sàng". Bảo vệ về "tính bảo mật" bao gồm sự riêng tƣ cá nhân và thông tin độc quyền. "Integrity" bảo vệ chống lại thông tin sửa đổi không đúng và tiêu huỷ. "Sẵn sàng" bảo vệ kịp thời và truy cập thông tin đáng tin cậy.
Định nghĩa dựa trên giá trị về độ an toàn, bảo mật, riêng tư:
Định nghĩa dựa trên giá trị về độ an toàn, bảo mật và sự riêng tƣ nhƣ sau: