Template Soạn Sách

Bản ghi

1 MỤC LỤC MỤC LỤC... i Chƣơng 0 BẢO ĐẢM CHẤT LƢỢNG PHẦN MỀM NHỮNG MÔ HÌNH VÀ NHỮNG TIÊU CHUẨN VỀ CHẤT LƢỢNG Thế nào là chất lƣợng phần mềm? Thế nào là mô hình chất lƣợng? Thế nào là mô hình CMM - Capability Maturity Model? Lịch sử của mô hình CMM? Thế nào là mô hình CMMI - Capability Maturity Model Intergration? Bộ CMM "trƣởng thành" là gì? CMM Mức độ 1 là gì? CMM Mức độ 2 là gì? CMM Mức độ 3 là gì? CMM Mức độ 4 là gì? CMM Mức độ 5 là gì? NHỮNG CHUẨN VÀ MÔ HÌNH CHẤT LƢỢNG KHÁC i

2 0.2.1 ISO 9000 là gì? Những vùng thiết yếu của ISO có tiêu điểm chất lƣợng là gì? Six Sigma là gì? KIỂM TRA PHẦN MỀM Vai trò của sự kiểm tra đối với chất lƣợng phần mềm là gì? Sự khác nhau giữa an error, a bug, a fault, and a failure? Có sự khác nhau ở đó giữa sự xác minh - Verification và sự phê chuẩn - Validation phải không? Mục đích của kiểm tra là gì? Những nguyên lý cơ bản của sự kiểm tra phần mềm là gì? Test ở mức đơn vị là gi? (Unit Test) Kiểm tra hộp đen là gì? (Black Box Testing) Kiểm tra toàn diện là gì? (Exhausive Testing) Kiểm tra giá trị biên là gì? (Boundary Value Testing) Sự phát sinh trƣờng hợp kiểm tra ngẫu nhiên là gì? Sự kiểm tra lớp tƣơng đƣơng là gì? (Equivalence class testing) Có những bất lợi trong kiểm tra hộp đen không? Thế nào la kiểm tra hộp trắng?(whitebox Testing) Sự kiểm tra tích hợp hệ thống là gì? (System Integration Testing) Sự kiểm tra tích hợp gia tăng là gi? (Iincremental Integration Testing) 18 ii

3 Sự kiểm tra kịch bản là gi? (Scenario Testing) Sự kiểm tra khắc nghiệt là gì? (Stress Testing) Kiểm tra Alpha là gi?(alpha testing) Kiểm tra Beta là gi?(beta Testing) Kiểm tra hồi quy là gi? (Regression Testing) Khi nào nên ngừng việc kiểm tra? ĐỘ ĐO (Metrics) Một số động lực cho phép đo là gì? Những loại nào có thể đo phần mềm? Độ đo những dòng mã LOC (Lines of Code) Độ đo McCabe Độ đo Halsteal FPs (Function Points) là gi? Những điểm đặc tính là gì? (Feature Points) Có những độ đo đặc biệt cho phần mềm hƣớng đối tƣợng không? Những điểm đối tƣợng là gì? (Object Points) Những điểm trƣờng hợp sử dụng là gì? (Use Case Points) Kỹ thuật GQM là gì? (Goal Question Metric) SỰ CHỊU ĐỰNG LỖI Những điểm kiểm tra là gì? (Check Points) Những khối khôi phục là gì? (Recovery Blocks) SỰ BẢO TRÌ VÀ TÍNH DÙNG LẠI Cái gì có nghĩa là sự bảo trì phần mềm? iii

4 0.6.2 Kỹ thuật đảo ngƣợc là gì? Mô hình tiến trình bảo trì Sử dụng lại phần mềm là gì? Nguyên lý Pareto là gì? BÀI TẬP CHƢƠNG iv

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 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 5

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 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. 6

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 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 ]. 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 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á. 7

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" 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 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 8

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 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. 9

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 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 10

11 0.2 NHỮNG CHUẨN VÀ MÔ HÌNH CHẤT LƢỢNG KHÁC 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 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 (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 Á Những vùng thiết yếu của ISO 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. 11

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 là một tiêu chuẩn cho những hệ thống phần mềm có chất lƣợng 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 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] 12

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 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 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?" 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 13

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 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 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. 14

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 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ó = 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 * năm để hoàn thành! 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. 15

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ó 3 5 = 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 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 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. 16

17 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 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 17

18 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 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 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. 18

19 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 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 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 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. 19

20 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) 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 20

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ã ) 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 Độ đ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ã. 21

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 Độ đ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 đồ 22

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 đầukế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. 23

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) 24

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 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 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 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 25

26 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 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ã? 26

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 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 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. 27

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 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] 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 28

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ô hình tiến trình bảo trì Một mô hình quá trình kỹ thuật đảo ngƣợc 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ì. 29

30 0.6.4 Sử dụng lại phần mềm là gì? Mô hình tiến trình bảo trì 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 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: 30

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 31