i chƣơng 0 bẢo ĐẢm chẤt lƢỢng phẦn mỀm...
TRANSCRIPT
i
MỤC LỤC
MỤC LỤC ........................................................................................... i
Chƣơng 0 BẢO ĐẢM CHẤT LƢỢNG PHẦN MỀM ................... 5
0.1 NHỮNG MÔ HÌNH VÀ NHỮNG TIÊU CHUẨN VỀ CHẤT LƢỢNG. 5
0.1.1 Thế nào là chất lƣợng phần mềm? ............................................ 5
0.1.2 Thế nào là mô hình chất lƣợng? ............................................... 6
0.1.3 Thế nào là mô hình CMM - Capability Maturity Model? .......... 7
0.1.4 Lịch sử của mô hình CMM? ..................................................... 7
0.1.5 Thế nào là mô hình CMMI - Capability Maturity Model
Intergration? ........................................................................................ 7
0.1.6 Bộ CMM "trƣởng thành" là gì? ................................................ 8
0.1.7 CMM Mức độ 1 là gì? .............................................................. 8
0.1.8 CMM Mức độ 2 là gì? .............................................................. 8
0.1.9 CMM Mức độ 3 là gì? .............................................................. 9
0.1.10 CMM Mức độ 4 là gì? .......................................................... 10
0.1.11 CMM Mức độ 5 là gì? .......................................................... 10
0.2 NHỮNG CHUẨN VÀ MÔ HÌNH CHẤT LƢỢNG KHÁC ................. 11
ii
0.2.1 ISO 9000 là gì? ...................................................................... 11
0.2.2 Những vùng thiết yếu của ISO 9000-3 có tiêu điểm chất lƣợng là
gì? 11
0.2.3 Six Sigma là gì? ..................................................................... 12
0.3 KIỂM TRA PHẦN MỀM ................................................................... 12
0.3.1 Vai trò của sự kiểm tra đối với chất lƣợng phần mềm là gì? .... 12
0.3.2 Sự khác nhau giữa an error, a bug, a fault, and a failure? ........ 13
0.3.3 Có sự khác nhau ở đó giữa sự xác minh - Verification và sự phê
chuẩn - Validation phải không? .......................................................... 13
0.3.4 Mục đích của kiểm tra là gì? .................................................. 13
0.3.5 Những nguyên lý cơ bản của sự kiểm tra phần mềm là gì? ...... 14
0.3.6 Test ở mức đơn vị là gi? (Unit Test) ....................................... 14
0.3.7 Kiểm tra hộp đen là gì? (Black Box Testing) .......................... 15
0.3.8 Kiểm tra toàn diện là gì? (Exhausive Testing) ........................ 15
0.3.9 Kiểm tra giá trị biên là gì? (Boundary Value Testing) ............. 15
0.3.10 Sự phát sinh trƣờng hợp kiểm tra ngẫu nhiên là gì? .............. 16
0.3.11 Sự kiểm tra lớp tƣơng đƣơng là gì? (Equivalence class testing)
16
0.3.12 Có những bất lợi trong kiểm tra hộp đen không? .................. 17
0.3.13 Thế nào la kiểm tra hộp trắng?(WhiteBox Testing) ............... 17
0.3.14 Sự kiểm tra tích hợp hệ thống là gì? (System Integration
Testing) 18
0.3.15 Sự kiểm tra tích hợp gia tăng là gi? (Iincremental Integration
Testing) 18
iii
0.3.16 Sự kiểm tra kịch bản là gi? (Scenario Testing) ...................... 18
0.3.17 Sự kiểm tra khắc nghiệt là gì? (Stress Testing) ..................... 19
0.3.18 Kiểm tra Alpha là gi?(Alpha testing) .................................... 19
0.3.19 Kiểm tra Beta là gi?(Beta Testing) ....................................... 19
0.3.20 Kiểm tra hồi quy là gi? (Regression Testing) ........................ 19
0.3.21 Khi nào nên ngừng việc kiểm tra? ........................................ 20
0.4 ĐỘ ĐO (Metrics) ................................................................................ 20
0.4.1 Một số động lực cho phép đo là gì? ........................................ 20
0.4.2 Những loại nào có thể đo phần mềm? ..................................... 21
0.4.3 Độ đo những dòng mã LOC (Lines of Code) .......................... 21
0.4.4 Độ đo McCabe ....................................................................... 22
0.4.5 Độ đo Halsteal ....................................................................... 23
0.4.6 FPs (Function Points) là gi? ................................................... 24
0.4.7 Những điểm đặc tính là gì? (Feature Points) ........................... 25
0.4.8 Có những độ đo đặc biệt cho phần mềm hƣớng đối tƣợng
không? 25
0.4.9 Những điểm đối tƣợng là gì? (Object Points) .......................... 25
0.4.10 Những điểm trƣờng hợp sử dụng là gì? (Use Case Points) .... 26
0.4.11 Kỹ thuật GQM là gì? (Goal Question Metric) ....................... 26
0.5 SỰ CHỊU ĐỰNG LỖI ........................................................................ 27
0.5.1 Những điểm kiểm tra là gì? (Check Points) ............................ 27
0.5.2 Những khối khôi phục là gì? (Recovery Blocks) ..................... 27
0.6 SỰ BẢO TRÌ VÀ TÍNH DÙNG LẠI .................................................. 28
0.6.1 Cái gì có nghĩa là sự bảo trì phần mềm? ................................. 28
iv
0.6.2 Kỹ thuật đảo ngƣợc là gì? ...................................................... 28
0.6.3 Mô hình tiến trình bảo trì ....................................................... 29
0.6.4 Sử dụng lại phần mềm là gì? .................................................. 30
0.6.5 Nguyên lý Pareto là gì? .......................................................... 30
0.7 BÀI TẬP CHƢƠNG 0 ........................................................................ 31
5
CHƢƠNG 0 BẢO ĐẢM CHẤT LƢỢNG PHẦN
MỀM
Sơ lược
- Những mô hình và những chuẩn về chất lƣợng.
- Kiểm tra phần mềm
- Những độ đo
- Sự chịu đựng lỗi.
- Sự bảo trì và tính dùng lại
0.1 NHỮNG MÔ HÌNH VÀ NHỮNG TIÊU CHUẨN VỀ CHẤT LƢỢNG
0.1.1 Thế nào là chất lượng phần mềm?
Có nhiều cách mà những ngƣời cổ đông có thể nhận biết đƣợc phần mềm
có chất lƣợng, tất cả dựa vào sự có mặt hay vắng mặt ở mức độ nhất định
của một thuộc tính này hay một thuộc tính khác. Một số định nghĩa hình
thức thích hợp, tuy nhiên, nhƣ định nghĩa trong ISO 8402:2000 Quality
Management and Quality Assurance - Vocabulary Standard.
Chất lƣợng là toàn thể những đặc tính và những đặc trƣng của một sản
phẩm hay dịch vụ dựa trên khả năng nó thỏa mãn những nhu cầu đƣợc phát
biểu hay áp đặt. Một chính sách có chất lƣợng mô tả toàn bộ những dự định
và phƣơng hƣớng của một tổ chức đối với chất lƣợng, nhƣ đƣợc biểu thị
một cách hình thức bởi ban quản lý cấp cao. Quản lý có chất lƣợng là khía
cạnh của toàn bộ chức năng quản lý xác định và thi hành chính sách có chất
lƣợng. Cuối cùng, một hệ thống có chất lƣợng là cấu trúc có tổ chức, trách
6
nhiệm, thủ tục, tiến trình, và những tài nguyên để thực hiện quản lý có chất
lƣợng.
Chẳng hạn, Voas và Agresti [2004] đề xuất rằng chất lƣợng đƣợc gồm có
một tập những thuộc tính hành vi khóa nhƣ:
- Sự tin cậy ( R - reliability).
- Sự thực hiện ( P - performance).
- Chịu đựng lỗi (F - fault tolerance)
- Sự an toàn (Sa - safety).
- Sự an ninh (Se - security).
- Tính sẵn sàng (A - availability).
- Có thể kiểm đƣợc (T - testability).
- Bảo trì đƣợc ( M - maintainability)
Munson [2003] bàn luận chất lƣợng nhƣ một tập những mục tiêu:
- Học đo đúng đắn những ngƣời, những quá trình, những sản phẩm, và
những môi trƣờng.
- Học làm khoa học cần thiết để để lộ ra những miền này tƣơng tác nhƣ
thế nào.
- Đƣa vào tiến trình việc học từ những lỗi quá khứ.
- Đƣa vào tiến trình việc học từ những thành công quá khứ.
- Đƣa vào tiến trình phép đo và quá trình cải tiến
Tất cả những sự khác nhau này đảm bảo chất lƣợng thích hợp và phần lớn
phù hợp với những mô hình chất lƣợng phổ biến.
0.1.2 Thế nào là mô hình chất lượng?
Một mô hình chất lƣợng là một hệ thống dùng để mô tả những nguyên lý và
những thực hành bên dƣới sự trƣởng thành quá trình phần mềm. Một mô
hình chất lƣợng khác với một mô hình chu trình sống vì mô hình chu kỳ
sống đƣợc dùng để mô tả sự tiến hóa của mã từ quan niệm thông qua sự
giao hàng và sự bảo trì. Một mô hình chất lƣợng đƣợc định ra để giúp đỡ
những tổ chức phần mềm cải thiện sự trƣởng thành của những tiến trình
phần mềm của họ nhƣ một đƣờng dẫn tiến hóa từ những quá trình đặc biệt,
hỗn loạn đến trƣởng thành, đƣa kỷ luật vào những tiến trình phần mềm. Mô
hình phần mềm nổi tiếng và đƣợc dung rộng rãi nhất trong công nghiệp
phần mềm là mô hình CMM - Capability Maturity Model.
7
0.1.3 Thế nào là mô hình CMM - Capability Maturity Model?
CMM là một mô hình chất lƣợng phần mềm gồm có năm mức. Có thể đoán
trƣớc, hiệu quả và điều khiển những quá trình phần mềm của một tổ chức
để tin rằng sẽ tiến bộ khi tổ chức chuyển lên năm mức này.
CMM cho phần mềm là không phải một mô hình chu trình cuộc sống,
Nhƣng có thể là một hệ thống mô tả những nguyên lý và những thực hành
sự trƣởng thành bên dƣới của quá trình phần mềm. CMM đƣợc định ra để
giúp đỡ những tổ chức phần mềm cải thiện sự trƣởng thành của những tiến
trình phần mềm của họ nhƣ một đƣờng dẫn tiến hóa từ những quá trình đặc
biệt, hỗn loạn đến trƣởng thành, đƣa kỷ luật vào những tiến trình phần
mềm.
0.1.4 Lịch sử của mô hình CMM?
CMM có những nền tảng trong công việc bắt đầu vào 1986 Tại U.S. DoD
để giúp đỡ cải thiện chất lƣợng của việc giao hàng sản xuất bởi những
ngƣời đấu thầu phần mềm chính phủ. Công việc đƣợc ủy nhiệm xuyên qua
Tập đoàn MITRE, và sau đó di chuyển tới Viện công nghệ phần mềm (SEI
- Software Engineering Institute) tại Trƣờng đại học Carnegie Mellon.
Watts Humphrey là tác giả ban đầu, và sau đó là Mark Paulk, Curtis Bill, và
những ngƣời đóng vai trò lãnh đạo trong sự phát triển của CMM [ Paulk ....
2005]. CMM sự vay mƣợn nặng nề từ Sự Quản lý Chất Lƣợng Tổng Quát
và công việc của Philip Crosby.
0.1.5 Thế nào là mô hình CMMI - Capability Maturity Model
Intergration?
Sự tích hợp mô hình CMM- I là một phiên bản chung hơn của CMM mà
thích hợp cho những sự nỗ lực khác bên cạnh phần mềm. CMM- I gồm có
ba phần: một cho phần mềm (SW- CMM), một cho kỹ thuật hệ thống bao
gồm sản phẩm tích hợp và sự phát triển xử lý (SECMM), và một bao gồm
một số khía cạnh thu nhận (IPD- CMM). Bộ sản phẩm CMM- I gồm có
nhiều mô hình tích hợp, những khóa học và một phƣơng pháp định giá.
8
0.1.6 Bộ CMM "trưởng thành" là gì?
Bộ này gồm có một sự tập của những mô hình trƣởng thành cho những khía
cạnh khác của doanh nghiệp phần mềm. Bao gồm:
- Phần mềm CMM (SW Software).
- Quá trình Phần mềm Cá nhân (PSP Personal Software Process).
- Quá trình Phần mềm Đội (TSP Team Software Process).
- Những ngƣời CMM ( P People).
- Phần mềm Thu nhận CMM (SA Software Acquisition).
- Kỹ thuật hệ thống CMM (SE System Engineering).
- Phát triển sản phẩm tích hợp CMM (IPD Integrated Product
Development).
- Sự tích hợp CMM ( CMM- I)
Những mức độ của CMM:
- Khởi đầu.
- Nhắc lại.
- Định nghĩa.
- Quản lý.
- Tối ƣu
Mức 0 không chính thức đƣợc đoán nhận, nhƣng đôi khi nó đƣợc đặc trƣng
nhƣ "sự hỗn loạn".
0.1.7 CMM Mức độ 1 là gì?
Mức 1 đƣợc gọi là mức "khởi đầu". Trong mức 1, tổ chức đƣợc đặc trƣng
bởi những quá trình phần mềm đặc biệt và hỗn loạn. Mức 1 không cần phải
đƣợc định nghĩa cẩn thận và những tổ chức có thể có một số khía cạnh tại
Mức 1 trong khi những cái đƣợc tiến triển khác xa hơn nữa. Đa số những tổ
chức có tể trƣng bày một số "túi" của hành vi Mức 1.
0.1.8 CMM Mức độ 2 là gì?
Mức 2 là mức "nhắc lại". Ở đây, những quá trình quản lý dự án cơ bản đƣợc
thiết lập để theo dõi chi phí, lịch biểu, và chức năng. Quá trình cần thiết
9
đúng chỗ để lặp lại những thành công trƣớc đó trên những dự án với những
ứng dụng tƣơng tự. Quá trình khóa tập trung trên:
- Quản lý những yêu cầu.
- Lập kế hoạch dự án phần mềm.
- Theo dõi dự án phần mềm.
- Giám sát.
- Quản lý phần mềm ký hợp đồng phụ.
- Bảo đảm chất lƣợng phần mềm.
- Quản lý cấu hình phần mềm
Cần mất khỏang18 tháng để nâng cấp từ mức 1 đến mức 2.
0.1.9 CMM Mức độ 3 là gì?
CMM mức 3 là mức "định nghĩa". Ở đây tổ chức đƣợc đạt đƣợc mức 2
trƣởng thành cộng với quá trình phần mềm cho cả những hoạt động quản lý
và thiết kế đƣợc lấy tài liệu, tiêu chuẩn hóa, và tích nhất vào trong một quá
trình phần mềm chuẩn cho tổ chức. Mọi dự án sử dụng một phiên bản đƣợc
phê chuẩn, chỉnh sửa quá trình phần mềm chuẩn của tổ chức để phát triển
và bảo trì phần mềm.
Những vùng quá trình khóa tại mức này gửi cả dự án lẫn vấn đề tổ chức,
nhƣ tổ chức thiết lập một cơ sở hạ tầng làm thành cơ quan công nghệ phần
mềm và những quá trình quản lý có hiệu quả ngang qua mọi dự án. Những
vùng quá trình khóa:
- Tiêu điểm quá trình tổ chức.
- Định nghĩa quá trình tổ chức.
- Chƣơng trình huấn luyện.
- Quản lý phần mềm tích hợp.
- Kỹ thuật sản phẩm phần mềm.
- Phối hợp liên nhóm.
- Bắt cặp xem xét.
Một cách đặc trƣng, mọi dự án sử dụng một phiên bản đƣợc phê chuẩn,
chỉnh sửa quá trình phần mềm chuẩn của tổ chức để phát triển và bảo trì
phần mềm.
10
0.1.10 CMM Mức độ 4 là gì?
Mức 4 là mức "quản lý" và nó gồm có tất cả những đặc trƣng của mức 3. Ở
đây, những biện pháp chi tiết của quá trình phần mềm và chất lƣợng sản
phẩm đƣợc tập hợp. Cả quá trình phần mềm lẫn những sản phẩmphần mầm
đƣợc định lƣợng rõ và kiểm soát.
Những vùng quá trình khóa ở đây tập trung vào việc thiết lập một sự hiểu
biết định lƣợng của cả hai quá trình phần mềm và sản phẩm công việc phần
mềm đƣợc xây dựng. Chúng là quản lý quá trình định lƣợng và quản lý chất
lƣợng phần mềm.
0.1.11 CMM Mức độ 5 là gì?
Mức 5 là mức "Tối ƣu hóa". Nó gồm có những đặc trƣng của mức 4 cộng
với bằng chứng của sự cải tiến quá trình liên tục đƣợc cho phép bởi sự phản
hồi định lƣợng từ quá trình và từ việc dẫn dắt những ý tƣởng và những công
nghệ có tính chất đổi mới. Những vùng quá trình chìa khóa tại mức này bao
trùm những vấn đề mà cả tổ chức và những dự án phải gửi tới sự thi hành
liên tục, sự cải tiến quá trình phần mềm đo đƣợc. Chúng là sự ngăn ngừa
lỗi, quản lý thay đổi công nghệ, và quản lý thay đổi quá trình.
Profile sự truơởng thành (của) 70 tổ chức đƣợc chứng nhận CMM
11
0.2 NHỮNG CHUẨN VÀ MÔ HÌNH CHẤT LƢỢNG KHÁC
0.2.1 ISO 9000 là gì?
ISO 9000 là một tiêu chuẩn chung, tóan cầu cho sự cải tiến chất lƣợng. Tổ
chức tiêu chuẩn hóa quốc tế sở hữu tiêu chuẩn này.
Tập hợp đƣợc mô tả vào 5 tiêu chuẩn, ISO 9000 thông qua ISO 9004, ISO
9000 đƣợc thiết kế sẽ đƣợc áp dụng vào trong một sự đa dạng rộng rãi của
những môi trƣờng sản xuất.
ISO 9001 thông qua ISO 9004 ứng dụng vào doanh nghiệp theo phạm vi
những hoạt động của họ. Bộ ISO 9004 và ISO 9000- X là những tài liệu
cung cấp những hƣớng dẫn cho những miền những ứng dụng đặc biệt.
ISO 9000-3 (1997) thực chất là một phiên bản phát triển của ISO 9001 với
tƣờng thuật bổ sung vây quanh phần mềm. Tiêu chuẩn này đƣợc chấp nhận
rộng rãi trong Châu Âu và ngày càng tăng ở U.S. và Châu Á.
0.2.2 Những vùng thiết yếu của ISO 9000-3 có tiêu điểm chất lượng là gì?
- Trách nhiệm quản lý.
- Những yêu cầu hệ thống chất lƣợng.
- Những yêu cầu xem xét hợp đồng.
- Những yêu cầu thiết kế sản phẩm.
- Điều khiển tài liệu và dữ liệu.
- Mua những yêu cầu.
- Khách hàng cung cấp những sản phẩm.
- Phân biệt sản phẩm và có thể theo dấu đƣợc.
- Những yêu cầu điều khiển tiến trình.
- Điều tra và kiểm tra
- Điều khiển việc kiểm tra, đo, và thiết bị kiểm tra.
- kiểm tra và tình trạng kiểm tra.
- Kiểm sóat những sản phẩm không phù hợp.
- Những hoạt động để hiệu chỉnh và phòng ngừa.
- Dùng, kho và giao hàng.
- Điều khiển những bản ghi chất lƣợng.
- Những yêu cầu kiểm toán chất lƣợng bên trong.
12
- Những yêu cầu huấn luyện.
- Những yêu cầu dịch vụ.
- Kỹ thuật thống kê
CMM-I là một mô hình cho sự tuyệt diệu hoạt động, trong khi ISO 9000-3
là một tiêu chuẩn cho những hệ thống phần mềm có chất lƣợng.
0.2.3 Six Sigma là gì?
Đƣợc phát triển bởi Motorola, Six Sigma là một triết học quản lý đƣợc dựa
vào sự biến đổi quá trình chuyển động lại. Six Sigma tập trung vào điều
khiển một quá trình để bảo đảm rằng những đầu ra trong vòng sáu sự lệch
chuẩn (Six Sigma) từ phƣơng tiện những mục đích xác định. Six Sigma
đƣợc thực hiện Sử dụng định nghĩa, đo, cải thiện, phân tích, và kiểm soát
(DMIAC - Define, Measure, Improve, Analyze, and Control)
Định nghĩa là mô tả quá trình sẽ đƣợc cải thiện, thông thƣờng xuyên qua
một vài loại mô hình qui trình nghiệp vụ. Đo là xác định và nắm những độ
đo liên quan cho mỗi khía cạnh của mô hình quá trình.
Tiến bộ rõ ràng là thay đổi một số khía cạnh nào của quá trình sao cho
những sự thay đổi có lợi đƣợc nhìn thấy trong những độ đo liên quan, bằng
việc tấn công khía cạnh mà sẽ có sự hoàn vốn cao nhất. Phân tích và kiểm
soát là sử dụng việc theo dõi đang diễn ra của những độ đo tới mô hình xem
xét liên tục, quan sát những độ đo, và tinh lọc quá trình khi cần.
0.3 KIỂM TRA PHẦN MỀM
0.3.1 Vai trò của sự kiểm tra đối với chất lượng phần mềm là gì?
Sự kiểm tra phần mềm có hiệu quả sẽ cải thiện chất lƣợng phần mềm.
Trong thực tế, thậm chí việc kiểm tra có dự kiến và đƣợc thực hiện kém sẽ
cải thiện chất lƣợng phần mềm nếu nó tìm thấy những lỗi. Sự kiểm tra là
một hoạt động chu trình cuộc sống. Hoạt động kiểm tra bắt đầu từ sự khởi
đầu sản phẩm và tiếp tục thông qua sự giao hàng phần mềm và sự bảo trì.
Tập hợp những báo cáo lỗi và giao cho họ việc sửa chữa cũng là một hoạt
động kiểm tra. Nhƣng nhƣ một hoạt động chu trình sống, những hoạt động
kiểm tra có giá trị nhất xuất hiện lúc bắt đầu dự án. Boehm và Basili [2005]
13
thông báo rằng kết quả tìm kiếm và sửa chữa một vấn đề phần mềm sau khi
sự giao hàng thƣờng đắt hơn kết quả tìm kiếm và sửa chữa nó trong pha
kiểm tra những yêu cầu 100 lần. Và khoảng 40 tới 50% trong số nỗ lực trên
những dự án phần mềm hiện thời đƣợc tiêu thụ trên công việc có thể tránh
đƣợc.
0.3.2 Sự khác nhau giữa an error, a bug, a fault, and a failure?
Có nhiều hơn với một sự khác nhau tinh tế giữa những thuật ngữ error, bug,
fault và failure. Thật ra, viêc sử dụng "bug" làm nản chí bởi vì bằng cách
nào đó nó ngụ ý rằng một lỗi vào trong chƣơng trình không xuyên qua hoạt
động của ai đó hết. Thuật ngữ đƣợc thích hợp cho một lỗi trong yêu cầu,
thiết kế hay mã là "error" hay "defect" Sự biểu thị của một defect trong thời
gian hoạt động của hệ thống phần mềm đƣợc gọi là một fault. Một lỗi mà
gây ra hệ thống phần mềm không thỏa mãn một trong số những yêu cầu của
nó đƣợc gọi là failure.
0.3.3 Có sự khác nhau ở đó giữa sự xác minh - Verification và sự phê
chuẩn - Validation phải không?
Sự xác minh, hay sự kiểm tra, xác định liệu có phải những sản phẩm của
một pha đã cho trong chu kỳ phát triển phần mềm hoàn thành những yêu
cầu đƣợc thiết lập trong suốt pha trƣớc đây. Sự Xác minh trả lời câu hỏi
"Am I building the product right?"
Sự phê chuẩn quyết định tính chính xác của chƣơng trình cuối cùng hay
phần mềm đối với những nhu cầu và những yêu cầu của ngƣời sử dụng. Sự
phê chuẩn trả lời câu hỏi "Am I building the right product?"
0.3.4 Mục đích của kiểm tra là gì?
Sự kiểm tra là sự thực hiện một chƣơng trình hay bộ phận chƣơng trình với
những đầu vào và những đầu ra đều vừa đƣợc dự đoán lại vừa đƣợc quan
sát với mục đích là tìm thấy những lỗi hay những sự lệch từ những yêu cầu.
Dù sự kiểm tra sẽ đƣa ra những lỗi, nhƣng chỉ là một trong số những mục
đích của nó. Cái khác sẽ tăng sự tin tƣởng trong hệ thống. Có lẽ, sự kiểm
tra phần mềm là sự suy nghĩ của ý định loại bỏ mọi lỗi. Tuy nhiên, sự kiểm
14
tra có thể chỉ phát hiện sự có mặt của những lỗi, không kiểm tra đƣợc việc
nó không tồn tại; bởi vậy, chƣa bao giờ có thể đƣợc biết khi nào mọi lỗi đã
đƣợc nhận diện. Thay vào đó, sự kiểm tra phải độ tin cậy trong hệ thống,
mặc dù nó có thể vẫn còn chứa đựng những lỗi chƣa bị phát hiện, bằng việc
bảo đảm rằng phần mềm đó thỏa mãn những yêu cầu của nó. Những chỗ
khách quan này nhấn mạnh trên kỹ thuật thiết kế và những yêu cầu đƣợc
phát triển kỹ đƣợc ghi lại. Hơn nữa, một kế hoạch kiểm tra hình thức cung
cấp tiêu chuẩn đƣợc dùng trong việc quyết định liệu có phải hệ thống đã
thỏa mãn những tài liệu những yêu cầu cần phải đƣợc phát triển. Một sự
kiểm tra tốt là một sự kiểm tra có khả năng cao trong việc tìm thấy lỗi. Một
sự kiểm tra thành công là một sự kiểm tra phát hiện ra lỗi.
0.3.5 Những nguyên lý cơ bản của sự kiểm tra phần mềm là gì?
- Mọi sự kiểm tra cần phải có thể theo dấu đƣợc đối với những yêu cầu
khách hàng.
- Những sự kiểm tra cần phải dự kiến lâu dài trƣớc khi sự kiểm tra bắt
đầu.
- Nhớ rằng nguyên lý Pareto ứng dụng vào sự kiểm tra phần mềm.
- Sự kiểm tra nên bắt đầu "cục bộ" và tiến triển về phía sự kiểm tra
"Theo qui mô lớn".
- Sự kiểm tra toàn diện không thực tế.
- Để có hiệu quả nhất, sự kiểm tra cần phải đƣợc chỉ đạo bởi một nhóm
độc lập.
0.3.6 Test ở mức đơn vị là gi? (Unit Test)
Vài phƣơng pháp có thể đƣợc dùng để kiểm tra những mô đun riêng lẻ hay
những đơn vị. Kỹ thuật này có thể đƣợc sử dụng bởi tác giả đơn vị (đôi khi
gọi là sự kiểm tra bàn) và bởi đội kiểm tra độc lập để luyện tập mỗi đơn vị
trong hệ thống. Kỹ thuật này có thể cũng đƣợc ứng dụng vào những hệ
thống con (những tập hợp của những mô đun liên quan đến cùng chức
năng). Kỹ thuật sẽ đƣợc bàn luận bao gồm kiểm tra hộp đen và kiểm tra hộp
trắng.
15
0.3.7 Kiểm tra hộp đen là gì? (Black Box Testing)
Trong sự kiểm tra hộp đen, chỉ những đầu vào và những đầu ra của đơn vị
đƣợc cho rằng; làm sao những đầu ra phát sinh dựa vào một tập đặc biệt của
những đầu vào đƣợc bỏ qua. Một kỹ thuật nhƣ vậy, nhƣ bản thân sự độc lập
trong việc thi hành mô đun, có thể đƣợc ứng dụng vào bất kỳ số lƣợng mô
đun nào với cùng chức năng.
Một số kiểm tra sử dụng rộng rãi kỹ thuật kiểm tra hộp đen bao gồm:
- Sự kiểm tra toàn diện.
- Sự kiểm tra giá trị biên.
- Sự phát sinh kiểm tra ngẫu nhiên.
- Sự kiểm tra trƣờng hợp xấu nhất
Một khía cạnh quan trọng của việc sử dụng kỹ thuật kiểm tra hộp đen đƣợc
định nghĩa rõ ràng những giao diện tới những mô đun đƣợc yêu cầu. Những
chỗ này hấn mạnh thêm trên ứng dụng của vùng phân chia con Parnas và
những nguyên lý tách riêng giao diện tới thiết kế mô đun.
0.3.8 Kiểm tra toàn diện là gì? (Exhausive Testing)
Sự kiểm tra toàn diện bao gồm việc giới thiệu mỗi đơn vị mã với mỗi sự kết
hợp đầu vào khả thi. Sự kiểm tra tòan diện có thể làm việc tốt trong trƣờng
hợp một số lƣợng những đầu vào nhỏ với một phạm vi đầu vào hạn chế
chẳng hạn, một đơn vị mã ƣớc lƣợng một số lƣợng nhỏ số Boolean đƣợc
nhập vào. Tuy nhiên, một vấn đề chính với sự kiểm tra toàn diện là vụ nổ tổ
hợp trong số lƣợng những trƣờng hợp kiểm tra. Chẳng hạn, giả thiết một
chƣơng trình nhập vào 5 số 32- bít và lấy ra 1 số 32- bít. Làm một kiểm tra
hộp đen thuần túy, sự kiểm tra toàn diện chúng tôi cần kiểm tra những mọi
sự kết hợp khả dĩ của năm số 32- bít đƣợc nhập vào. Điều đó phải có 232
.
232
. 232
. 232
. 232
= 2160
trƣờng hợp kiểm tra. Dù chúng tôi đã có thể ngẫu
nhiên sinh ra và chạy những trƣờng hợp kiểm tra này, mỗi trƣờng hợp mất
1μ giây, toàn bộ kiểm tra mất hơn hơn 4.6 * 1034
năm để hoàn thành!
0.3.9 Kiểm tra giá trị biên là gì? (Boundary Value Testing)
Sự kiểm tra trƣờng hợp giá trị biên hay góc giải quyết vấn đề nổ tổ hợp
bằng việc kiểm tra một vài tập con rất nhỏ của những sự kết hợp đầu vào
đƣợc xác định nhƣ những "Ranh giới" đầy ý nghĩa của đầu vào.
16
Chẳng hạn, cho rằng mã trƣớc đó đƣợc bàn luận với năm số 32- bít đƣợc
nhập vào. Nếu những sự nhập vào kiểm tra bị hạn chế đối với mỗi sự kết
hợp của min, max, và những giá pháp định cho mỗi đầu vào, thì bộ kiểm tra
gồm có 35 = 243 trƣờng hợp điển hình. Một bộ kiểm tra của kích thƣớc này
có thể đƣợc xử lý dễ dàng với sự phát sinh trƣờng hợp kiểm tra tự động
Một phiên bản mạnh hơn của sự kiểm tra này có thể đƣợc tìm thấy nếu
chúng ta kiểm tra những giá trị chỉ ít hơn so với và lớn hơn mộ chút so với
toàn bộ những ranh giới, hoặc chúng ta có thể lựa chọn nhiều hơn một giá
trị cho mỗi đầu vào.
0.3.10 Sự phát sinh trường hợp kiểm tra ngẫu nhiên là gì?
Sự phát sinh trƣờng hợp kiểm tra ngẫu nhiên, hay sự thử có cơ sở thống kê,
có thể đƣợc sử dụng cho cả sự kiểm tra đơn vị lẫn mức hệ thống. Loại kiểm
tra này bao gồm việc đƣa ra đơn vị mã tới nhiều những trƣờng hợp kiểm tra
đƣợc phát sinh ngẫu nhiên qua thời gian nào đó. Mục đích của cách tiếp cận
này sẽ mô phỏng sự thực hiện của phần mềm dƣới những điều kiện hiện
thực.
Những trƣờng hợp kiểm tra đƣợc phát sinh ngẫu nhiên đƣợc dựa vào việc
thống kê xác định của những đầu vào đƣợc mong đợi. Thống kê thông
thƣờng đƣợc tập hợp bởi những ngƣời sử dụng chuyên gia của những hệ
thống tƣơng tự hoặc là, nếu không một ai tồn tại, có thể đoán. Chủ ý của
loại kiểm tra này sẽ mô phỏng cách dùng tiêu biểu của hệ thống.
Hạn chế chính (của) một kỹ thuật nhƣ vậy là những hàm phân phối xác suất
nằm bên dƣới cho những biến số vào có thể không có sẵn hay sai. Bởi vậy,
những trƣờng hợp kiểm tra phát sinh ngẫu nhiên có khả năng nhớ những
điều kiện với xác suất thấp của biến cố. Đây chính xác là những kiểu điều
kiện mà có thể đƣợc xem xét trong thiết kế của mô đun. Việc không kiểm
tra những kịch bản này sẻ gây lỗi.
0.3.11 Sự kiểm tra lớp tương đương là gì? (Equivalence class testing)
Sự kiểm tra lớp tƣơng đƣơng bao gồm phân chia những không gian kiểm
tra khả thi đƣợc nhập vào một đơn vị mã hay nhóm của những đơn vị mã
vào trong một tập đại diện đƣợc nhập vào.
17
0.3.12 Có những bất lợi trong kiểm tra hộp đen không?
Một bất lợi là nó có thể bỏ qua hay không thể với tới đƣợc những mã chết.
Ngoài ra, nó có thể không kiểm tra tất cả của những đƣờng dẫn điều khiển
trong Mô đun. Nói cách khác, ngƣời ta hy vọng kiểm tra hộp đen kiểm tra
chỉ kiểm tra cái gì sẽ xảy ra, không phải cái gì không đƣợc dự định. Kỹ
thuật kiểm tra hộp trắng hay rõ ràng có thể đƣợc dùng để giải quyết vấn đề
này
0.3.13 Thế nào la kiểm tra hộp trắng?(WhiteBox Testing)
Sự kiểm tra hộp trắng (đôi khi gọi là clear or glass box testing) tìm kiếm để
kiểm tra cấu trúc mã nằm bên dƣới. Vì lý do này nó cũng đƣợc gọi là sự
kiểm tra cấu trúc.
Trong khi mà những sự kiểm hộp đen là dữ liệu đƣợc điều khiển, những sự
kiểm tra hộp trắng là lôgic đƣợc điều khiển nghĩa là, họ đƣợc thiết kế để
kiểm tra mọi đƣờng dẫn trong đơn vị mã. Chẳng hạn, trong chức năng cơ
chế từ chối của hệ thống kiểm tra hành lý, mọi đƣờng dẫn bị lỗi cần đƣợc
kiểm tra bao gồm những hoàn cảnh giải quyết những sự thất bại đồng thời
và nhiều hơn.
Sự kiểm tra hộp trắng cũng có lợi thế là nó có thể khám phá những đƣờng
dẫn mà mã không thể đƣợc thực hiện. Mã không thể với tới đƣợc này
không đƣợc mong muốn vì đó là một dấu hiệu mà lôgic sai, nó tiêu phí bộ
nhớ không gian mã, và nó có thể tình cờ đƣợc thực hiện trong trƣờng hợp
sai của bộ đếm chƣơng trình máy tính.
Những chiến lƣợc kiểm tra hộp trắng sau đây sẽ đƣợc bàn luận (tuy nhiên,
đây là không phải một danh sách toàn diện của kỹ thuật kiểm tra hộp trắng
):
- Sự kiểm tra đƣờng dẫn DD (Decision to Decision).
- Sự kiểm đƣờng dẫn DU (Define Use).
- Phƣơng pháp đƣờng dẫn cơ sở McCabe.
- Những kiểm tra mã.
- Chứng minh chƣơng trình hình thức
18
0.3.14 Sự kiểm tra tích hợp hệ thống là gì? (System Integration Testing)
Sự kiểm tra tích hợp bao gồm sự kiểm tra của những nhóm những thành
phần tổng hợp để tạo ra một hệ thống hay hệ thống con. Những sự kiểm tra
đƣợc bắt nguồn từ yêu cầu đặc tả hệ thống. Thách thức chính trong sự kiểm
tra tích hợp là định vị nguồn của lỗi khi một sự kiểm tra thất bại. Sự kiểm
tra tích hợp gia tăng làm giảm bớt vấn đề này.
Một khi những mô đun riêng lẻ đã đƣợc kiểm tra, sau đó những hệ thống
con hay toàn bộ hệ thống cần đƣợc kiểm tra. Trong những hệ thống lớn
hơn, quá trình có thể bị hỏng vào trong một loạt những sự kiểm tra hệ thống
con và sau đó là một sự kiểm tra toàn bộ hệ thống.
Nếu một lỗi xuất hiện trong thời gian kiểm tra mức hệ thống, lỗi này phải
đƣợc sửa chữa. Lý tƣởng, mỗi sự trƣờng hợp kiểm tra thay đổi mô đun phải
đƣợc chạy lại và mọi sự kiểm tra mức hệ thống trƣớc đây phải đƣợc chạy
thành công. Tập hợp của những trƣờng hợp kiểm tra hệ thống thƣờng đƣợc
gọi là một bộ kiểm tra hệ thống.
0.3.15 Sự kiểm tra tích hợp gia tăng là gi? (Iincremental Integration
Testing)
Đây là một chiến lƣợc phân chia hệ thống bằng cách nào đó để giảm bớt mã
đƣợc kiểm tra. Chiến lƣợc kiểm tra gia tăng bao gồm :
- Sự kiểm tra top-down.
- Sự kiểm tra bottom-up.
- Vùng phân chia những loại hệ thống khác.
Trong thực tế, đa số sự tích hợp bao gồm một sự kết hợp những chiến lƣợc
này.
0.3.16 Sự kiểm tra kịch bản là gi? (Scenario Testing)
Đây là kiểu kiểm tra hệ thống cho những hệ thống hƣớng đối tƣợng bao
gồm xác định những kịch bản từ những use-case và bổ sung vào bằng
những sơ đồ tƣơng tác cho thấy những đối tƣợng liên quan trong kịch bản.
19
0.3.17 Sự kiểm tra khắc nghiệt là gì? (Stress Testing)
Trong sự kiểm tra này, hệ thống đƣa ra một sự rối loạn lớn ở đầu vào;
chẳng hạn, hành lý đến tại nhịp độ cực đại cho một thời kỳ mở rộng. Một
mục tiêu của loại kiểm này là sẽ nhìn thấy hệ thống thất bại nhƣ thế nào.
Sự kiểm tra khắc nghiệt có thể cũng hữu ích trong việc giải quyết những
trƣờng hợp và những điều kiện nơi hệ thống chịu tải nặng chẳng hạn, khi
những sự kiểm tra cho việc sử dụng bộ nhớ hay bộ xử lý phối hợp với
những ứng dụng khác và tài nguyên hệ điều hành để xác định nếu sự thực
hiện chấp nhận đƣợc.
Sự kiểm tra khắc nghiệt đặc biệt hữu ích trong những hệ thống phân tán, mà
có thể trƣng bày sự giảm phẩm cấp khốc liệt khi mạng trở nên quá tải.
0.3.18 Kiểm tra Alpha là gi?(Alpha testing)
Đây là sự kiểm tra hợp lệ hệ thống gồm có phân phối và thực hiện phần
mềm trong nội bộ. Loại kiểm tra này thông thƣờng đƣợc đi theo sau bởi sự
kiểm tra beta.
0.3.19 Kiểm tra Beta là gi?(Beta Testing)
Sự kiểm này, đi theo sau sự kiểm tra Alpha, bao gồm những phiên bản sơ
bộ của phần mềm có hiệu lực đƣợc phân phối cho những khách hàng thân
thiện kiểm tra phần mềm dƣới sự sử dụng thực tế. Dựa vào sự phản hồi từ
sự kiểm tra beta, những sự sửa chữa hay những sự nâng cao đƣợc bổ sung
và sau đó sự kiểm tra hồi quy đƣợc thực hiện.
0.3.20 Kiểm tra hồi quy là gi? (Regression Testing)
Sự kiểm tra hồi quy (có thể cũng đƣợc thực hiện tại mức đơn vị) đƣợc dung
làm cho có hiệu lực phần mềm đƣợc cập nhật chống lại sự một tập những
trƣờng hợp kiểm tra mà đã thực hiện. Bất kỳ trƣờng hợp kiểm tra mới nào
cần cho những sự nâng cao đƣợc thêm vào bộ kiểm tra, và phần mềm đƣợc
làm cho có hiệu lực chỉ khi đó là một sản phẩm mới. Sự kiểm tra hồi quy là
một sự kiểm tra trọn vẹn gắn liền với sự kiểm tra tích hợp khi những môđun
mới đƣợc thêm vào hệ thống con đã đƣợc kiểm tra.
20
0.3.21 Khi nào nên ngừng việc kiểm tra?
Có vài tiêu chuẩn mà có thể đƣợc dùng để xác định khi sự kiểm tra cần phải
ngừng. Bao gồm :.
- Khi bạn chạy quá thời gian.
- Khi sự kiểm tra không gây ra những sự thất bại mới.
- Khi sự kiểm tra không để lộ ra những lỗi mới.
- Khi bạn không thể nghĩ của bất kỳ trƣờng hợp kiểm tra mới nào.
- Khi bạn đạt đến một điểm "lợi tức giảm dần".
- Khi hƣớng dẫn phạm vi đã đƣợc đạt tới.
- Khi mọi lỗi đã đƣợc loại bỏ [Jorgensen 2002]
Nhƣng cách tốt nhất để biết khi sự kiểm tra hoàn thành là khi nào phạm vi
kiểm tra độ đo những yêu cầu đã đƣợc thỏa mãn.
0.4 ĐỘ ĐO (Metrics)
0.4.1 Một số động lực cho phép đo là gì?
Chìa khóa kiểm soát bất cứ cái gì là phép đo. Phần mềm không có khác về
điểm này, nhƣng câu hỏi đƣa ra "Những khía cạnh nào của phần mềm có
thể đƣợc đo?"
Những độ đo có thể đƣợc sử dụng trong công nghệ phần mềm trong nhiều
cách. Đầu tiên, những độ đo nhất định có thể đƣợc sử dụng trong thời gian
sự phát triển những yêu cầu phần mềm để tham gia ƣớc lƣợng chi phí. Ứng
dụng hữu ích khác cho những độ đo là làm điểm chuẩn. Chẳng hạn, nếu
một công ty có một tập những hệ thống thành công, thì những độ đo tính
toán cho những hệ thống đó sẽ làm một bộ những đặc trƣng mong đợi và đo
đƣợc dùng để tìm kiếm hay so sánh trong những hệ thống tƣơng lai.
Đa số những độ đo có thể cũng đƣợc sử dụng cho sự kiểm tra cảm giác về
sự đo lƣờng những thuộc tính mong đợi của phần mềm và giới hạn sự thiết
lập trên những ranh giới của tiêu chuẩn đó. Hay chúng có thể đƣợc sử dụng
trong thời gian pha kiểm tra và cho những mục đích gỡ lỗi để giúp tập trung
vào những nguồn thích hợp của những lỗi.
Tất nhiên, những độ đo có thể đƣợc dùng để theo dõi tiến độ dự án. Thật ra,
một số công ty thƣởng cho những ngƣời làm thuê dựa vào số lƣợng phần
mềm đƣợc phát triển mỗi ngày nhƣ đƣợc đo bằng một số phƣơng pháp đo
21
sẽ đƣợc bàn luận (Ví dụ, những chỉ dẫn nguồn đƣợc chuyển giao, những
điểm chức năng hay những dòng mã…)
0.4.2 Những loại nào có thể đo phần mềm?
Những ứng cử viên tiêu biểu bao gồm :.
- Những dòng mã.
- Những đƣờng dẫn mã.
- Tỉ lệ lỗi.
- Thay đổi những tỉ lệ.
- Thời gian dự án trôi qua.
- Ngân quỹ chi tiêu
0.4.3 Độ đo những dòng mã LOC (Lines of Code)
Đặc trƣng dễ dàng nhất của phần mềm có thể đo đƣợc là số lƣợng những
dòng mã nguồn kết thúc. Đo hàng nghìn những dòng mã (KLOC), "đồng
hồ" mét cũng đƣợc tham chiếu tới nhƣ những chỉ dẫn nguồn phân phát (DSI
Delivered Source Instructions) hay những sự phát biểu bình luận nguồn mã
(NCSS Noncommented source Code StatementS). Nghĩa là, chúng tôi đếm
những lệnh chƣơng trình có thể thực hiện (Loại trừ những sự phát biểu bình
luận, những tập tin đầu mục, những sự phát biểu định dạng, macros và bất
cứ cái gì mà không đƣa ra nhƣ mã có thể thực hiện sau khi biên soạn hay
gây ra việc chiếm bộ nhớ.)
Độ đo liên quan khác là những dòng mã nguồn (SLOC Source Lines Of
Code), sự khác nhau chính là một dòng mã nguồn đơn đó có thể trải qua vài
hàng. Chẳng hạn, một sự phát biểu if-then-else là một SLOC đơn, nhƣng
phân phát nhiều những chỉ dẫn nguồn.
Một trong những sự bất lợi chính của việc sử dụng những dòng mã nguồn
nhƣ một độ đo là nó có thể chỉ đƣợc đo sau khi mã đã đƣợc viết. Trong khi
những dòng mã có thể đƣợc ƣớc lƣợng, cách tiếp cận này ít chính xác hơn
so với đo mã sau khi nó đã đƣợc viết.
Tuy vậy, KLOC là một độ đo hữu ích, và trong nhiều trƣờng hợp nó tốt hơn
so với không đo cái gì. Nhiều độ đo khác đƣợc cơ bản dựa vào những dòng
mã.
22
Delta KLOC đo có bao nhiêu dòng mã thay đổi trong một khoảng thời gian
nào đó. Một biện pháp nhƣ vậy có lẽ hữu ích trong trƣờng hợp một dự án
gần kết thúc sự phát triển mã, Delta KLOC đƣợc kỳ vọng nhỏ. Ngoài ra,
những độ đo cũng đƣợc bắt nguồn từ KLOC.
0.4.4 Độ đo McCabe
Để thử đo sự phức tạp phần mềm, McCabe [1976] đã giới thiệu một độ đo,
sự phức tạp cyclomatic, để đo chƣơng trình điều khiển luồng. Khái niệm
này tuy phù hợp tốt với lập trình thủ tục nhƣng không phải tất yếu với sự
lập trình hƣớng đối tƣợng, ở đó có những sự thích nghi cho sự sử dụng lập
trình hƣớng đối tƣợng. Trong bất kỳ trƣờng hợp nào, độ đo này có hai sự sử
dụng cơ bản:
- Để chỉ định sự phức tạp leo thang trong một mô đun nhƣ nó đƣợc mã
hóa và bởi vậy giúp đỡ những ngƣời viết mã xác định "kích thƣớc"
những mô đun của họ.
- Để xác định cận trên trên số lƣợng những sự kiểm tra phải đƣợc thiết
kế và thực hiện.
Sử dụng độ đo McCabe trong việc tính toán số lƣợng trƣờng hợp kiểm tra
tối thiểu cần đi ngang qua mọi đƣờng dẫn mã độc lập tuyến tính đã đƣợc
bàn luận.
Sự phức tạp cyclomatic dựa trên việc xác định số lƣợng những đƣờng dẫn
độc lập tuyến tính trong một môđun chƣơng trình, gợi ý rằng sự phức tạp
tăng với con số này và sự tin cậy giảm bớt.
Để tính toán độ đo, thủ tục sau đây đƣợc làm theo. Xem xét lƣu đồ của một
chƣơng trình. Hãy để e là số lƣợng những cạnh và n là số lƣợng những nút.
Thành lập sự phức tạp cyclomatic, C, nhƣ sau:
C = e − n + 2 (6.1)
Sự tƣơng ứng của những sự phát biểu ngôn ngữ và lƣu đồ
23
0.4.5 Độ đo Halsteal
Những độ đo của Halstead đo dung lƣợng thông tin, hay việc ngôn ngữ lập
trình đƣợc sử dụng cƣờng độ cao nhƣ thế nào. Những độ đo Halstead đƣợc
dựa vào số lƣợng những phần tử phân biệt, cú pháp và những cặp bắt đầu-
kết thúc (hay tƣơng đƣơng chúng, nhƣ dấu ngoặc móc mở và đóng trong
Java hay C). Từ những điều này, một thống kê chiều dài chƣơng trình đƣợc
xác định. Bỏ qua những phƣơng trình bởi vì chúng hiếm khi đƣợc tính toán
bằng tay. Từ những thống kê này, một "chƣơng trình từ vựng," V, và mức
chƣơng trình, L, đƣợc dẫn xuất. L đƣợc giả định là một độ đo mức độ trừu
tƣợng của chƣơng trình. Nó đƣợc tin tƣởng rằng việc tăng số này sẽ tăng độ
tin cậy của hệ thống.
Lƣu đồ cho mã giảm tiếng ồn trong hệ thống kiểm tra hành lý
Trong bất kỳ trƣờng hợp nào, từ V và L, E đƣợc định nghĩa nhƣ:
E = V/L (6.2)
Việc giảm bớt mức nỗ lực đƣợc tin để tăng độ tin cậy cũng nhƣ sự dễ dàng
thi hành.
Theo nguyên tắc, chiều dài chƣơng trình có thể đƣợc lƣợng giá và, bởi vậy,
hữu ích trong chi phí và ƣớc lƣợng chƣơng trình. Chiều dài là độ đo "phức
tạp" của chƣơng trình dƣới dạng cách dùng ngôn ngữ và, do đó, có thể đƣợc
dùng để lƣợng giá những tỉ lệ lỗi.
24
0.4.6 FPs (Function Points) là gi?
Những điểm chức năng (FPs) đƣợc giới thiệu vào cuối những năm 1970 khi
một sự thay thế tới những độ đo dựa vào nguồn sự đếm hàng đơn giản. Cơ
sở của FPs nhƣ là những ngôn ngữ lập trình mạnh hơn đƣợc phát triển, số
lƣợng những hàng nguồn cần thiết để thực hiện một chức năng đã cho giảm
bớt. Nghịch lý, tuy nhiên, chi phí phép đo LOC chỉ báo một sự giảm trong
năng suất, nhƣ những chi phí cố định của sự sản xuất phần mềm phần lớn là
không đƣợc thay đổi.
Giải pháp tới nghịch lý ƣớc lƣợng nỗ lực này sẽ đo chức năng của phần
mềm qua những số lƣợng giao diện giữa những mô đun và những hệ thống
con trong những chƣơng trình hay những hệ thống. Một lợi thế lớn của độ
đo FP là nó có thể đƣợc tính toán trƣớc khi bất kỳ sự mã hóa nào xuất hiện.
Sau đây là 5 đặc trƣng phần mềm cho mỗi mô đun, hệ thống con hay hệ
thống đại diện cho FPs (của) nó.
- Số lƣợng những đầu vào tới ứng dụng (I).
- Số lƣợng những đầu ra (O).
- Số lƣợng những sự điều tra ngƣời sử dụng (Q).
- Số lƣợng những hồ sơ đƣợc dùng. (F)
- Số lƣợng những giao diện ngoài (X)
25
0.4.7 Những điểm đặc tính là gì? (Feature Points)
Những điểm đặc tính là một mở rộng của FPs đƣợc phát triển bởi Nghiên
cứu Năng suất Phần mềm, Inc. vào 1986. Những điểm đặc tính gửi những
thực tế mà độ đo FP cổ điển đƣợc phát triển cho viêc quản lý hệ thống
thông tin và, bởi vậy, không phải đặc biệt thích hợp với nhiều hệ thống
khác, nhƣ thời gian thực, nhúng, truyền thông, và phần mềm điều khiển tiến
trình. Động lực là những hệ thống trƣng bày những mức cao của sự phức
tạp thuật toán, nhƣng những đầu vào và những đầu ra thƣa thớt.
Độ đo điểm đặc tính đƣợc tính toán trong một thái độ tƣơng tự nhƣ FP trừ
một nhân tố mới đó cho số lƣợng những giải thuật, A, đƣợc thêm vào.
0.4.8 Có những độ đo đặc biệt cho phần mềm hướng đối tượng không?
Trong khi bất kỳ vấn đề nào nào trƣớc đó bàn luận những độ đo có thể đƣợc
sử dụng trong mã hƣớng đối tƣợng, những độ đo khác tốt hơn đƣợc thỏa
mãn cho điều này đƣợc thiết lập. Những độ đo hƣớng đối tƣợng đƣợc tính
toán trên ba mức:
- Những phƣơng pháp - methods
- Những lớp - classes
- Những gói - packages
0.4.9 Những điểm đối tượng là gì? (Object Points)
Đây là một điểm chức năng giống nhƣ độ đo và không phải đặc biệt đƣợc
dự định cho sự sử dụng với mã hƣớng đối tƣợng, nhƣ tên của nó. Cũng nhƣ
FPs, đó là một ƣớc lƣợng có trọng số của những đặc tính chƣơng trình rõ
ràng sau đây:
- Số lƣợng những màn hình riêng biệt.
- Số lƣợng những báo cáo.
- Số lƣợng những mô đun ngôn ngữ thế hệ thứ ba cần hỗ trợ mã ngôn
ngữ phát sinh thứ tƣ.
Những điểm đối tƣợng là một giải pháp tới FPs khi những ngôn ngữ phát
sinh thứ tƣ đƣợc sử dụng
26
0.4.10 Những điểm trường hợp sử dụng là gì? (Use Case Points)
Những điểm trƣờng hợp sử dụng (UCPs) cho phép ƣớc lƣợng một kích
thƣớc và nỗ lực của ứng dụng từ những trƣờng hợp sử dụng của nó. UCPs
đƣợc dựa vào số lƣợng những diễn viên, những kịch bản, và kỹ thuật viên
và những nhân tố môi trƣờng khác nhau trong sơ đồ trƣờng hợp sử dụng.
Phƣơng trình UCP đƣợc dựa vào bốn biến:
- Hệ số phức tạp kỹ thuật (TCF technical complexity factor).
- Hệ số phức tạp môi trƣờng (ECF environment complexity factor).
- Không đƣợc điều chỉnh sử dụng những điểm trƣờng hợp (UUCP
unadjusted use case points).
- Hệ số năng suất (PF productivity factor)
Phƣơng trình:
UCP = TCP * ECF * UUCP * PF
UCPs là một kỹ thuật ƣớc lƣợng một cách tƣơng đối mới.
0.4.11 Kỹ thuật GQM là gì? (Goal Question Metric)
GQM là một kỹ thuật phân tích giúp đỡ trong sự chọn lọc một độ đo thích
hợp. Để sử dụng kỹ thuật, bạn theo sau ba quy tắc đơn giản sau. Đầu tiên,
phát biểu những mục đích của phép đo; nghĩa là, cái gì là tổ chức cố gắng
để đạt đƣợc? Tiếp theo, dẫn xuất ra từ mỗi mục đích những câu hỏi mà phải
đƣợc trả lời để xác định phải chăng những mục đích đang đƣợc thỏa mãn.
Cuối cùng, quyết định cái gì phải đƣợc đo để có khả năng để trả lời những
câu hỏi.
Ví dụ:
Giả thiết một trong số những mục đích của tổ chức của các bạn sẽ ƣớc
lƣợng hiệu lực của tiêu chuẩn coding. Vài câu hỏi có liên hệ bạn có thể hỏi
để đánh giá phải chăng mục đích này đã đƣợc đạt đƣợc:
- Ai đang sử dụng tiêu chuẩn?
- Năng suất ngƣời viết mã là gì?
- Mã có chất lƣợng là gì?
Đối với những câu hỏi này, những độ đo tƣơng ứng có thể là.
Tỉ lệ của những ngƣời viết mã đang sử dụng tiêu chuẩn là gì?.
Làm sao có số LOC hay FPs thay đổi đƣợc phát sinh mỗi ngày trên ngƣời
viết mã?
27
Làm sao có những biện pháp chất lƣợng thích hợp cho mã thay đổi? (
Những biện pháp thích hợp có thể là những lỗi đƣợc tìm thấy theo LOC hay
sự phức tạp cyclomatic.)
Bây giờ khung này đã đƣợc thiết lập, những bƣớc thích hợp có thể đƣợc lấy
để tập hợp, phân tích, và gieo rắc dữ liệu cho sự nghiên cứu.
0.5 SỰ CHỊU ĐỰNG LỖI
0.5.1 Những điểm kiểm tra là gì? (Check Points)
Những điểm kiểm tra là một cách để tăng sự chịu đựng lỗi. Trong sơ đồ
này, những kết quả trung gian đƣợc viết vào bộ nhớ tại những vị trí cố định
trong mã, gọi là những điểm kiểm tra, cho những mục đích chẩn đoán. Dữ
liệu trong những sự định vị này có thể đƣợc sử dụng với mục đích gỡ lỗi,
trong thời gian xác minh hệ thống, và trong thời gian sự xác minh điều hành
hệ thống.
Sự thi hành điểm kiểm tra
0.5.2 Những khối khôi phục là gì? (Recovery Blocks)
Sự chịu đựng Lỗi có thể đang gia tăng xa hơn nữa bằng cách sử dụng
những điểm kiểm tra phối hợp với những điểm khởi động lại đƣợc xác định
trƣớc trong phần mềm. Những điểm khởi động lại này đánh dấu những khối
khôi phục trong phần mềm.
28
Ở chỗ cuối của mỗi khối khôi phục, những điểm kiểm tra đƣợc kiểm tra cho
"hợp lý." Nếu những kết quả không hợp lý, thì xử lý lấy lại tại sự bắt đầu
của khối khôi phục đó hay tại điểm nào đó trong một khối trƣớc đây.
Điểm, tất nhiên, là thiết bị phần cứng nào đó đó (hay quá trình khác mà độc
lập với một điểm trong câu hỏi) đƣợc cung cấp những đầu vào sai tới khối.
Bằng việc lặp lại sự xử lý trong khối, với dữ liệu hợp lệ đƣợc giả định
trƣớc, lỗi sẽ không đƣợc lặp lại.
Mỗi khối khôi phục đại diện cho một quá trình song song thừa tới khối
đƣợc kiểm tra. Không may, dù chiến lƣợc này tăng độ tin cậy của hệ thống,
nó có thể có một tác động khốc liệt trên sự thực hiện bởi vì sự đau đầu đƣợc
thêm vào bởi điểm kiểm tra và sự lặp lại của sự xử lý trong một khối.
Sự thi hành khối khôi phục
0.6 SỰ BẢO TRÌ VÀ TÍNH DÙNG LẠI
0.6.1 Cái gì có nghĩa là sự bảo trì phần mềm?
Sự bảo trì phần mềm là “sự sửa chữa những lỗi, và sự thi hành những sự
thay đổi cần thiết cho phép một hệ thống hiện có thực hiện những nhiệm vụ
mới và thực hiện những nhiệm vụ cũ dƣới những điều kiện mới" [Dvorak
1994].
0.6.2 Kỹ thuật đảo ngược là gì?
Nói chung, kỹ thuật đảo ngƣợc là quá trình phân tích một hệ thống phụ
thuộc để xác định những thành phần của nó. Kỹ thuật đảo ngƣợc đôi khi
29
đƣợc gọi là đổi mới hay cải tạo. Trong khi có những ý nghĩa tiêu cực để đảo
ngƣợc kỹ thuật nhƣ trong sự ăn trộm một thiết kế, kỹ thuật đảo ngƣợc,
trong mẫu nào đó, thiết yếu đối với sự cải tiến của thiết kế hay thi hành hay
cho sự khôi phục của tài liệu trong trƣờng hợp một hệ thống có thể đã đƣợc
thu nhận hợp pháp từ một hãng thứ ba.
Một mô hình quá trình kỹ thuật đảo ngƣợc
0.6.3 Mô hình tiến trình bảo trì
Trong tất cả các pha, có lẽ mô hình bảo trì là ít hiểu rõ nhất. Pha bảo trì nói
chung gồm có một loạt những quá trình kỹ thuật để kéo dài cuộc sống của
hệ thống. Có ba kiểu bảo trì:
- Thích nghi - thay đổi kết quả đó từ những sự thay đổi ngoài đến hệ
thống nào phải trả lời.
- Hiệu chỉnh - thay đổi sự bảo trì bao quanh đó để sửa lỗi.
- Hoàn thiện - Mọi sự bảo trì khác bao gồm những sự nâng cao, những
sự thay đổi tài liệu, những sự cải tiến hiệu quả, …
Một mô hình bảo trì rộng rãi minh họa mối quan hệ giữa những dạng khác
nhau của sự bảo trì.
30
Mô hình tiến trình bảo trì
0.6.4 Sử dụng lại phần mềm là gì?
Sử dụng lại phần mềm thuần khiết là một giải thƣởng cao trong công nghệ
phần mềm. Rõ ràng đáng mong có một tập hợp trộn- và- hợp, làm cho
những thành phần phần mềm có hiệu lực có thể dễ dàng đƣợc kéo bật ra
những ứng dụng phần mềm tùy biến. Tuy nhiên, sử dụng lại phần mềm thực
tế là một sự khai thác kinh nghiệm khó học. Dù những môđun phần mềm là
không phải hiện thân rõ ràng đƣợc sử dụng lại, những bài học đƣợc học từ
những dự án phần mềm trƣớc đây mà tƣơng tự cần phải đƣợc kết chuyển.
Hầu hết chi phí cất giữ có thể đƣợc mong đợi bằng việc sử dụng lại những
mô hình chuyên biệt về miền. Để sử dụng lại lôgic chuyên biệt về miền, tuy
nhiên, những ngƣời phát triển phải phân chia rõ ràng lôgic miền từ ứng
dụng. Họ cũng phải phân biệt rõ ràng lôgic độc lập miền.
Bởi vậy, cách tốt nhất để bắt đầu một chƣơng trình sử dụng lại phần mềm là
từ việc làm nhỏ và học cách thực hiện. Cố gắng để xác định vài môđun
phần mềm nhỏ mà là những ứng cử viên tốt cho việc sử dụng lại và tập
trung vào việc chuẩn bị những mô đun này cho việc sử dụng lại.
0.6.5 Nguyên lý Pareto là gì?
Pareto là một nhà toán học ý thế kỷ 19 và đầu thế kỷ 20 và nhà kinh tế học
quan tâm đến những luật của cơ hội. Những sự quan sát của ông ấy có thể
đƣợc áp dụng trong vài cách tới việc sử dụng lại phần mềm và sắp đặt.
Chẳng hạn, nguyên lý Pareto có thể gợi ý rằng:
31
- 20% của mã đóng góp tới 80% trong số chi phí phát triển phần mềm.
- 20% của mã đóng góp 80% trong số những lỗi.
- 20% của những lỗi tính toán cho 80% trong số chi phí để sửa lỗi.
- 20% của những mô đun tiêu thụ 80% trong số thời gian thực hiện.
Những phần trăm, dĩ nhiên, chủ quan. Nhƣng những sự quan sát này cung
cấp sự hiểu thấu vào trong tiếp cận việc sử dụng lại phần mềm nhƣ thế nào,
sự kiểm tra, và nỗ lực lập kế hoạch.
0.7 BÀI TẬP CHƢƠNG 0