Ngày nay công nghệ thông tin phát triển mạnh mẽ, kéo theo đó là công nghệ phần mềm ngày một phát triển. Phần mềm đem lại cho người dùng phát triển, xây dựng duy trì một hệ thống nào đó. Như vậy nó có vai trò quan trọng trong thực tiễn, Để một phần mềm được sử dụng nó phải trải qua nhiều khâu từ nhưng khâu đầu tiên xây dựng ý tưởng đến khâu đưa vào thực tiễn. Trong quá trình đó không thể không nhắc đến Thẩm Tra và Xác Nhận. Đây cũng là nội dung chúng em muốn trình bày trong đề tài này. Thẩm tra: Xem xét một sản phẩm có được được làm đúng theo yêu cầu đặc tả hay không. xác nhận tính hợp lệ : Phần mềm cần phải làm những gì mà người dùng thật sự yêu cầu. Việc kiểm tra cho thấy tính phù hợp với các đặc tả. Việc xác nhận cho thấy chương trình đã đáp ứng nhu cầu của người dùng hay chưa. Kế hoạch kiểm tra phải được lập để hướng dẫn quá trình thử nghiệm. Như vậy đây là bước quan trọng khi một phần mềm đưa ra sản phẩm
HỌC VIỆN KỸ THUẬT MẬT MÃ KHOA CÔNG NGHỆ THÔNG TIN BÀI TẬP LỚN MÔN CÔNG NGHỆ PHẦN MỀM ĐỀ TÀI: VERIFICATION AND VALIDATION (XÁC MINH VÀ XÁC NHẬN) Giáo viên hướng dẫn: Lê Bá Cường Nhóm sinh viên thực hiện: Nhóm – Lớp AT6B: Hà Văn Trường Nguyễn Việt Long Đỗ Văn Tiền Nguyễn Như Tỉnh Hà Nội, 10/2012 NHẬN XÉT CỦA GIÁO VIÊN MỤC LỤC Trang Nhận xét giáo viên .1 Mục lục .2 Danh mục hình vẽ Lời nói đầu Giới thiệu 22.1 Lập kế hoạch xác minh xác nhận 10 22.2 Kiểm tra phần mềm 15 Các chương trình kiểm tra trình 17 22.3 Phân tích tĩnh tự động 23 22.4 Xác minh phương pháp hình thức .28 22.4.1 Phát triển phần mềm phòng (Cleanroom) 30 Kết luận 35 DANH MỤC CÁC HÌNH VẼ Danh mục hình vẽ Trang Hình 22.1 Xác minh xác nhận tĩnh xác minh xác nhận tĩnh động Hình 22.2 Các trình gỡ lỗi Hình 22.3 Mô hình trình phát triển phần mềm 11 Hình 22.4 Cấu trúc kế hoạch thử nghiệm phần mềm 13 Hình 22.5 Vai trò đối tượng trình kiểm tra 18 Hình 22.6 Các trình kiểm tra 19 Hình 22.7 Quá trình kiểm tra 22 Hình 22.8 Kiểm tra phân tích tĩnh tự đông 24 Hình 22.9 Ví dụ phân tích tĩnh LINT 27 Hình 22.10 Quá trình phát triển phòng 31 Lời Nói Đầu Ngày công nghệ thông tin phát triển mạnh mẽ, kéo theo công nghệ phần mềm ngày phát triển Phần mềm đem lại cho người dùng phát triển, xây dựng trì hệ thống Như có vai trò quan trọng thực tiễn, Để phần mềm sử dụng phải trải qua nhiều khâu từ khâu xây dựng ý tưởng đến khâu đưa vào thực tiễn Trong trình không nhắc đến Thẩm Tra Xác Nhận Đây nội dung chúng em muốn trình bày đề tài Thẩm tra: Xem xét sản phẩm có được làm theo yêu cầu đặc tả hay không xác nhận tính hợp lệ : Phần mềm cần phải làm mà người dùng thật yêu cầu Việc kiểm tra cho thấy tính phù hợp với đặc tả Việc xác nhận cho thấy chương trình đáp ứng nhu cầu người dùng hay chưa Kế hoạch kiểm tra phải lập để hướng dẫn trình thử nghiệm Như bước quan trọng phần mềm đưa sản phẩm Trong trình thực đề tài nhóm em không khỏi mắc phải thiếu sót Mong thầy đóng góp ý kiến để chúng em hoàn thiện tốt đề tài sau Em xin chân thành cảm ơn Sinh viên thực hiện: Hà văn Trường Nguyễn việt Long Đỗ văn Tiền Nguyễn Tỉnh CHƯƠNG 22: XÁC MINH VÀ XÁC NHẬN Giới thiệu: Mục tiêu: Mục tiêu chương để giới thiệu phần mềm xác minh xác nhận đặc biệt tập trung vào kỹ thuật xác minh tĩnh Khi bạn đọc chương này, bạn sẽ: Giới thiệu thẩm tra xác nhận phần mềm, với thảo luận khác biệt chúng Mô tả trình kiểm tra chương trình vai trò V&V (Verification and Validation) Giải thích phân tích tĩnh kỹ thuật thẩm tra Mô tả trình phát triển phần mềm phòng (Cleanroom software development) Nội dung: 22.1 Lập kế hoạch V&V 22.2 Kiểm tra phần mềm (Software inspections) 22.3 Phân tích tĩnh tự động (Automated static analysis) 22.4 Xác minh phương pháp hình thức Trong sau trình thực hiện, chương trình phát triển phải kiểm tra để đảm bảo đáp ứng đặc điểm kỹ thuật cung cấp chức dự kiến người dùng phần mềm Xác minh xác nhận (V&V) tên đặt cho trình kiểm tra phân tích Xác minh hoạt động diễn giai đoạn trình phát triển phần mềm V&V bắt đầu với đánh giá yêu cầu tiếp tục thông qua đánh giá thiết kế kiểm tra mã để thử nghiệm sản phẩm Xác minh xác nhận hai công việc khác nhau, thường bị nhầm lẫn Boehm (Boehm, 1979) diễn tả cách ngắn gọn khác biệt chúng: ’Xác minh: Phần mềm xây dựng có phù hợp với đặc tả hay không?’ ’Xác nhận: Phần mềm cần phải mà người dùng thật yêu cầu?’ Các định nghĩa cho biết vai trò xác minh liên quan đến việc kiểm tra phần mềm phù hợp với đặc điểm kỹ thuật Chúng ta nên kiểm tra xem đáp ứng yêu cầu quy định chức phi chức Xác nhận, nhiên, trình chung Mục đích việc xác nhận để đảm bảo hệ thống phần mềm đáp ứng mong đợi khách hàng Nó vượt tầm kiểm tra mà hệ thống đáp ứng được, đặc điểm cho thấy phần mềm đáp ứng mà khách hàng mong đợi Hệ thống phần mềm không phản ánh mong muốn thực nhu cầu người sử dụng chủ sở hữu hệ thống Mục tiêu cuối trình xác minh xác nhận thiết lập tin tưởng hệ thống phần mềm "phù hợp cho mục đích” Điều có nghĩa hệ thống phải tốt, đủ cho mục đích sử dụng Mức độ tin cậy cần thiết phụ thuộc vào mục đích hệ thống, mong đợi người sử dụng hệ thống tiếp thị môi trường cho hệ thống: Chức phần mềm: Mức độ tin cậy phụ thuộc vào tầm quan trọng phần mềm đến một tổ chức Ví dụ, mức độ tin cậy cho phần mềm sử dụng để điều khiển hệ thống an toàn cao nhiều so với yêu cầu cho hệ thống phần mềm nguyên mẫu phát triển để chứng minh số ý tưởng Mong đợi người dùng: Là phản ánh chắn ngành công nghiệp phần mềm mà nhiều người sử dụng có kỳ vọng thấp phần mềm họ, không ngạc nhiên phù hợp suốt trình sử dụng Họ sẵn sàng chấp nhận lỗi hệ thống lợi ích việc sử dụng nhiều kể từ năm 90 kỉ XX Bây chấp nhận để cung cấp cho hệ thống không đáng tin cậy, công ty phần mềm phải dành nhiều nỗ lực việc xác minh xác nhận Tiếp thị thị trường: Khi hệ thống thương mại hóa, người bán hàng hệ thống phải đưa vào chương trình cạnh tranh khách hàng, khách hàng sẵn sàng trả tiền cho hệ thống tiến độ theo yêu cầu cho việc cung cấp hệ thống Trường hợp công ty có vài đối thủ cạnh tranh, định để phát hành chương trình trước kiểm tra đầy đủ sửa lỗi họ muốn người vào thị trường Trường hợp khách hàng không sẵn sàng trả giá cao cho phần mềm, họ phải chịu lỗi phần mềm Tất yếu tố phải xem xét định nên dành nhiều nỗ lực vào trình V&V Hình 22.1 Xác minh xác nhận tĩnh, xác minh xác nhận tĩnh động Hình 22.1 cho ta thấy kiểm tra thử nghiệm phần mềm đóng vai trò hỗ trợ trình làm phần mềm Các mũi tên giai đoạn trình mà kỹ thuật sử dụng Vì vậy, kiểm tra phần mềm tất giai đoạn trình làm phần mềm Bắt đầu với yêu cầu, biểu diễn mà phần mềm đọc kiểm tra Yêu cầu đánh giá thiết kế kỹ thuật sử dụng để phát lỗi đặc điểm kỹ thuật thiết kế Trong trình V&V, có hai cách tiếp cận bổ sung cho kiểm tra hệ thống phân tích: Kiểm tra phần mềm đánh giá phân tích kiểm tra đặc trưng cho hệ thống tài liệu yêu cầu, sơ đồ thiết kế mã nguồn chương trình Chúng ta sử dụng kiểm tra tất giai đoạn mã nguồn hệ thống tài liệu liên quan Kiểm tra phần mềm phân tích tự động kỹ thuật V&V tĩnh, không cần phải chạy phần mềm máy tính Kiểm thử phần mềm liên quan đến việc chạy thực thi phần mềm với liệu thử nghiệm Kiểm tra đầu phần mềm cách hoạt động để kiểm tra xem có thực theo yêu cầu không? Thử nghiệm kỹ thuật xác minh xác nhận động Chúng ta thử nghiệm hệ thống nguyên mẫu phiên thực thi chương trình có sẵn Một lợi phát triển gia tăng phiên kiểm tra hệ thống có sẵn giai đoạn trình phát triển Chức kiểm tra thêm vào hệ thống không cần phải có thực đầy đủ trước thử nghiệm bắt đầu Kỹ thuật kiểm tra bao gồm kiểm tra chương trình, tự động phân tích mã nguồn xác minh hình thức Tuy nhiên, kỹ thuật tĩnh kiểm tra tương ứng chương trình phần (xác minh), chứng minh phần mềm hoạt động hữu ích Chúng ta sử dụng kỹ thuật tĩnh để kiểm tra thuộc tính bật phần mềm chẳng hạn hiệu suất độ tin cậy Mặc dù kiểm tra phần mềm sử dụng rộng rãi thử nghiệm chương trình luôn dùng kỹ thuật xác minh xác nhận phần mềm Thử nghiệm liên quan đến việc thực thi chương trình cách sử dụng liệu liệu thực tế xử lý chương trình Chúng ta phát khuyết tật chương trình bất cập cách kiểm tra kết đầu chương trình tìm kiếm bất thường Thử nghiệm có hai loại khác sử dụng giai đoạn khác trình làm phần mềm: Thử nghiệm xác nhận dự định thấy khách hàng muốn phần mềm đáp ứng yêu cầu Là phần thử nghiệm xác nhận, sử dụng thử nghiệm thống kê để kiểm tra việc thực thi chương trình độ tin cậy, kiểm tra xem tình trạng hoạt động hoạt động Khuyết điểm thử nghiệm thiết kế để tìm khiếm khuyết hệ thống sử dụng để mô hoạt động Mục đích kiểm tra lỗi để tìm mâu thuẫn chương trình đặc điểm kỹ thuật Tất nhiên, không cứng nhắc ranh giới phương pháp tiếp cận để thử nghiệm Trong trình thử nghiệm xác nhận, tìm thấy khiếm khuyết hệ thống, khiếm khuyết trình thử nghiệm, số kiểm tra hiển thị chương trình đáp ứng yêu cầu Quá trình V&V gỡ lỗi thường xen kẽ Khi bạn phát lỗi chương trình mà bạn thử nghiệm, bạn phải thay đổi chương trình để sửa chữa lỗi lầm Tuy nhiên, thử nghiệm (hoặc, nói chung xác minh xác nhận) gỡ lỗi có mục tiêu khác nhau: Quá trình xác minh xác nhận dự định để thiết lập tồn khiếm khuyết hệ thống phần mềm Gỡ lỗi trình (Hình 22.2) mà xác định sửa chữa khiếm khuyết Hình 22.2 Các trình gỡ lỗi Không có phương pháp đơn giản để gỡ lỗi chương trình Kỹ gỡ rối tìm kiếm khuôn mẫu đầu ra, nơi mà lỗi tìm thấy sử dụng hiểu biết loại lỗi, khuôn mẫu đầu ra, ngôn ngữ lập trình trình lập trình để xác định vị trí khuyến khuyết Khi gỡ lỗi, sử dụng kiến thức lỗi lập trình phổ biến (chẳng hạn lỗi tăng số đếm) phù hợp với khuôn mẫu quan sát Chúng ta nên tìm lỗi đặc trưng ngôn ngữ lập trình Định vị lỗi chương trình trình đơn giản, lỗi không gần điểm nơi mà chương trình bị lỗi Để xác định vị trí lỗi chương trình, chúng có để thiết kế kiểm tra bổ sung tái tạo lỗi ban đầu xác định vị trí chương trình Chúng theo dõi dòng chương trình tay, gỡ lỗi công cụ thu thập thông tin việc thực thi chương trình giúp xác định vị trí nguồn gốc vấn đề Công cụ gỡ lỗi phần tập hợp công cụ hỗ trợ ngôn ngữ tích hợp với hệ thống biên dịch Chúng cung cấp môi trường thời gian chạy chuyên dụng cho chương trình cho phép truy cập vào bảng biểu tượng trình biên dịch giá trị biến chương trình Chúng ta kiểm soát thực thi “step ping” 10 Lớp lỗi Lỗi liệu Kiểm tra • Có phải tất biến chương trình khởi tạo trước giá trị chúng sử dụng? • Có phải tất đặt tên? • Kích thước tập hợp mảng có nên kích thước mảng? • Nếu chuỗi ký tự sử dụng, dấu phân cách gán rõ ràng? Điều có gây nên tràn đệm không? Lỗi điều khiển • Đối với câu lệnh điều kiện, điều kiện có không? • Mỗi vòng lặp có chắn chấm dứt không? • Thông báo có đặt ngoặc không? • Trong trường hợp thông báo, tất trường hợp bị chiếm dụng không? • Nếu ngắt yêu cầu sau trường hợp thông báo, bao gồm không? Lỗi vào/ra • Có phải ất biến đầu vào sử dụng không? • Có phải tất biến đầu rõ giá trị trước có đầu không? • Đầu vào bất ngờ gây sai lệch không? Lỗi giao diện • Có phải tất gọi hàm chức phương thức có tham số xác? • Các loại tham số hình thức thực tế có phù hợp? Là tham số theo thứ tự không? • Nếu thành phần truy cập nhớ chia sẻ, có mô hình cấu trúc nhớ chia sẻ không? Lỗi quản lý lưu trữ • Nếu cấu trúc liên kết sửa đổi, tất liên kết bố trí cách xác không? 22 Nếu lưu trữ động sử dụng, không gian phân bổ cách xác không? • Không gian có phân bố lại rõ ràng sau không cần thiết hay không? • Lỗi quản lý ngoại lệ • Tất điều kiện lỗi đưa vào ngoại lệ hay chưa? Hình 22.7 Quá trình kiểm tra Một số tổ chức (GiIb Graham, 1993) từ bỏ thử nghiệm thành phần công tác kiểm tra Họ tìm thấy kiểm tra chương trình hiệu việc tìm lỗi, chi phí kiểm tra thành phần không hợp lý Các tổ chức kiểm tra thành phần, kết hợp với hệ thống kiểm tra, chiến lược V&V hiệu Sự đời kiểm tra có ý nghĩa quản lý dự án Quản lý quan trọng kiểm tra chấp nhận đội phát triển phần mềm Chương trình kiểm tra trình công cộng phát lỗi so với trình thử nghiệm thành phần riêng tư Chắc chắn, sai lầm thực cá nhân tiết lộ cho nhà lãnh đạo toàn lập trình theo tổ đội Kiểm tra phải đào tạo để quản lý trình cách cẩn thận để phát triển giáo dục cung cấp hỗ trợ mà không đổ trách nhiệm lên lỗi phát Là tổ chức có kinh nghiệm trình kiểm tra, sử dụng kết kiểm tra để giúp cải tiến quy trình Kiểm tra cách lý tưởng để thu thập liệu loại khiếm khuyết xảy Đội kiểm tra, tác giả mã kiểm tra đề nghị jcác lý lý khiếm khuyết giới thiệu Bất nơi có thể, trình sau sửa đổi để loại bỏ lý cho khiếm khuyết để họ tránh hệ thống tương lai 23 22.3 Phân tích tĩnh tự động: Sự kiểm tra hình thức phân tích tĩnh kiểm tra chương trình mà không thực Như thảo luận, kiểm tra thường thúc đẩy danh sách kiểm tra lỗi chẩn đoán xác định lỗi phổ biến ngôn ngữ lập trình khác Đối với số chẩn đoán lỗi khô khan, tự động trình kiểm tra chương trình chống lại danh sách này, dẫn đến phát triển tự động phân tích tĩnh cho ngôn ngữ lập trình khác Phân tích tĩnh công cụ phần mềm mà quét văn nguồn chương trình phát lỗi dị thường Họ phân tích văn chương trình nhận loại báo cáo chương trình Sau đó, họ phát xem báo cáo hình thành, suy dòng điều khiển chương trình, nhiều trường hợp, tính toán thiết lập tất giá trị cho liệu chương trình Họ bổ sung cho sở phát lỗi cung cấp trình biên dịch ngôn ngữ Chúng sử dụng phần trình kiểm tra V & V tiến trình hoạt động riêng biệt Mục đích phân tích tĩnh tự động để thu hút ý kiểm tra đến dị thường chương trình, chẳng hạn biến sử dụng mà không cần khởi tạo, biến mà không sử dụng liệu có giá trị khỏi phạm vi Một số kiểm tra phát cách phân tích tĩnh thể hình 22.8 Bất thường thường lỗi lập trình thiếu sót, đó, họ làm bật điều mà bị sai chương trình thực Tuy nhiên, nên hiểu bất thường không thiết phải lỗi chương trình Chúng cố ý hậu xấu 24 Các giai đoạn liên quan đến phân tích tĩnh bao gồm: Lớp lỗi Lỗi liệu Lỗi điểu khiển Lỗi vào/ra Lỗi giao diện Lỗi quản lý lưu trữ Kiểm tra phân tích tĩnh Biến sử dụng trước khởi tạo Các biến khai báo không sử dụng Biến gán hai lần không sử dụng phép gán Mảng có hành vi vi phạm ràng buộc Không khai báo biến Mã truy cập tới Rẽ nhánh không điều kiện vòng lặp Biến đầu hai lần mà không gán Loại tham số bất xứng Số tham số bất xứng Không sử dụng kết hàm chức Hàm hức thủ tục không gọi đến Không gán trỏ Con trỏ số học Hình 22.8 Kiểm tra phân tích tĩnh tự đông Phân tích điều khiển lưu lượng: Giai đoạn xác định làm bật vòng lặp với nhiều đầu ra, đầu vào Mã truy cập tới mã bao quanh vô điều kiện lệnh goto nhánh lệnh nơi mà điều kiện bảo vệ không Phân tích sử dụng liệu: Giai đoạn làm bật cách mà biến chương trình sử dụng Nó phát biến sử dụng mà không cần khởi tạo trước đó, biến viết hai lần mà không gán cho nhiệm vụ biến khai báo không sử dụng Sử dụng phân tích liệu phát hiệu thử nghiệm điều kiện, nơi mà thử nghiệm không cần thiết Điều kiện dự phòng điều kiện sai Phân tích giao diện: Phân tích kiểm tra phù hợp thủ tục thông thường, thủ tục khai báo sử dụng chúng 25 Điều không cần thiết ngôn ngữ bậc cao Java sử dụng để thực trình biên dịch tiến hành kiểm tra Phân tích giao diện phát lỗi ngôn ngữ bậc thấp FORTRAN C Phân tích giao diện phát hàm chức thủ tục khai báo không gọi đến kết hàm chức mà không sử dụng Phân tích lưu lượng thông tin: Giai đoạn phân tích xác định phụ thuộc biến đầu vào đầu Trong không phát bất thường cho thấy cách mà giá trị biến chương trình bắt nguồn từ giá trị khác biến Với thông tin này, kiểm tra mã nên tìm thấy giá trị tính toán sai Phân tích luồng thông tin hiển thị điều kiện ảnh hưởng đến giá trị biến Phân tích đường dẫn: Giai đoạn phân tích ngữ nghĩa xác định tất đường dẫn chương trình đưa báo cáo thực đường dẫn Về chất điều tỏ điều khiển chương trình cho phép đường dẫn phân tích riêng Phân tích tĩnh có giá trị lớn sử dụng ngôn ngữ lập trình C C quy định kiểu chặt chẽ, kiểm tra trình biên dịch C hạn chế Cho nên, dễ dàng cho lập trình viên để bị lỗi, công cụ phân tích tĩnh tự động phát số lỗi từ kết chương trình Điều đặc biệt quan trọng C (và đến mức độ thấp hơn, C + +) sử dụng để hệ thống phát triển then chốt Trong trường hợp này, phân tích tĩnh phát số lượng lớn lỗi tiềm tàng làm giảm đáng kể chi phí thử nghiệm Đối với ngôn ngữ C, phân tích tĩnh kỹ thuật hiệu để phát lỗi chương trình Nó bù lại cho điểm yếu thiết kế ngôn ngữ lập trình Tuy nhiên, nhà thiết kế mô-đem ngôn ngữ lập trình Java gỡ bỏ số tính ngôn ngữ dễ bị lỗi Tất biến phải khởi tạo lệnh goto, đó, có khả bị lỗi mã truy cập, quản lý lưu trữ tự động Cách tiếp cận tránh lỗi phát lỗi hiệu việc cải thiện độ tin cậy chương trình Mặc dù phân tích tĩnh cho Java có sẵn, cách không sử dụng rộng rãi Nó rõ ràng cho dù số lượng lỗi phát chứng minh thời gian cần thiết để phân tích đầu họ 26 Để minh họa phân tích tĩnh, chương trình C nhỏ chương trình hệ thống Java Unix Linux bao gồm phân tích tĩnh gọi LINT cho chương trình C LINT cung cấp cho kiểm tra tĩnh, cung cấp trình biên dịch ngôn ngữ bậc cao Java Một ví dụ LINT, b kết đầu thể hình 22.9 Trong bảng ghi phiên cuối Unix, lệnh hiển thị chữ in nghiêng Lệnh (dòng 138) liệt kê chương trình (lệnh vô nghĩa chạy chương trình) Nó định nghĩa chức với tham số, gọi printarray, sau gọi chức với tham số Biến i c khai báo, không gán giá trị Giá trị trả hàm không sử dụng Các dòng 139 cho thấy trình biên dịch C chương trình lỗi gián tiếp trình biên dịch C Điều theo sau lần gọi máy phân tích tĩnh LINT mà phát lỗi chương trình báo cáo chống Các phân tích tĩnh cho thấy biến c i sử dụng không khởi tạo printarray gọi với số khác đối số khai báo Nó xác định việc sử dụng không phù hợp đối số printarray thực tế giá trị hàm chức không sử dụng Công cụ phân tích thay kiểm tra, có số loại lỗi mà phân tích tĩnh phát Ví dụ, phát biến không khởi tạo, phát biến khởi tạo Trong ngôn ngữ bậc thấp C, máy phân tích tĩnh phát hàm chức có sai số loại đối số, phát trường hợp mà đối số sai loại chuyển đến hàm chức Để giải số vấn đề, phân tích tĩnh LCLint (Orcero, 2000 Evans Larochelle, 2002) hỗ trợ việc sử dụng thích mà người sử dụng xác định ràng buộc bình luận chương trình Những hạn chế cho phép lập trình để xác định biến hàm không nên bị thay đổi, sử dụng biến toàn cục, v.v… Các phân tích tĩnh sau kiểm tra chương trình chống lại hạn chế phần mã bật xuất không xác 27 138% more lint_ex.c #indude printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () { int Anarray[5]; int i; char c; printarray (Anarray, i, C); printarray (Anarray); } 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args lint_ex.c(4) :: Iint_ex.c(1 0) printarray, arg used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored Hình 22.9 Ví dụ phân tích tĩnh LINT 28 22.4 Xác minh phương pháp hình thức: Phương pháp hình thức phát triển phần mềm dựa biểu diễn toán học phần mềm, thường đặc điểm kỹ thuật hình thức Các phương pháp hình thức chủ yếu liên quan với phân tích toán học đặc điểm kỹ thuật; chuyển đổi đặc điểm kỹ thuật cho biểu diễn chi tiết hơn, biểu diễn ngữ nghĩa tương đương, hình thức xác nhận biểu diễn hệ thống ngữ nghĩa tương đương cho biểu diễn khác Chúng ta nghĩ đến việc sử dụng phương pháp hình thức kỹ thuật xác minh tĩnh cuối Họ yêu cầu phân tích chi tiết đặc điểm kỹ thuật hệ thống chương trình, sử dụng họ thường tốn thời gian chi phí Do đó, việc sử dụng phương pháp hình thức chủ yếu giới hạn an toàn an ninh then chốt trình phát triển phần mềm Việc sử dụng đặc điểm kỹ thuật toán học hình thức xác minh liên quan ủy quyền Vương quốc Anh phòng tiêu chuẩn an toàn then chốt phần mềm (MOD, năm 1995) Phương pháp hình thức sử dụng giai đoạn khác trình V & V: Một đặc điểm kỹ thuật hình thức hệ thống phát triển phân tích toán học cho không quán Kỹ thuật hiệu việc phát lỗi đặc điểm kỹ thuật thiếu sót, thảo luận Chương 10 Chúng ta xác minh cách hình thức, cách sử dụng đối số toán học (Mathematical arguments), mã hệ thống phần mềm phù hợp với đặc điểm kỹ thuật Điều đòi hỏi đặc điểm kỹ thuật hình thức có hiệu việc phát lỗi lập trình thiết kế số chuyển đổi trình phát triển đặc điểm kỹ thuật hình thức chuyển đổi hình thành thông qua loạt biểu diễn chi tiết trình phòng (Cleanroom process) sử dụng để hỗ trợ trình xác minh hình thức Các đối số cho việc sử dụng đặc điểm kỹ thuật hình thức xác minh chương trình liên kết lực lượng đặc điểm kỹ thuật hình thức cho phân tích chi tiết đặc điểm kỹ thuật Có thể thấy mâu thuẫn tiềm tàng hay thiếu sót có lẽ không phát 29 hệ thống sẵn sàng hoạt động Xác minh hình thức chứng tỏ chương trình phát triển đáp ứng đặc điểm kỹ thuật nó, lỗi triển khai không ảnh hưởng đến độ tin cậy Các đối số chống lại việc sử dụng đặc điểm kỹ thuật hình thức yêu cầu ký hiệu đặc biệt Đây sử dụng đội ngũ nhân viên huấn luyện đặc biệt đứng chuyên gia Do đó, vấn đề với yêu cầu hệ thống che đậy tính hình thức Kỹ sư phần mềm nhận khó khăn tiềm tàng với yêu cầu họ không hiểu miền, chuyên gia tìm thấy vấn đề họ không hiểu đặc điểm kỹ thuật Mặc dù đặc điểm kỹ thuật toán học phù hợp, không rõ thuộc tính hệ thống thực cần thiết Xác minh hệ thống phần mềm không tầm thường nhiều thời gian đòi hỏi phải có công cụ chuyên ngành chứng minh định lý chuyên môn toán học Do đó, trình tốn làm tăng kích thước hệ thống, chi phí xác minh hình thức tăng lên không cân đối Do đó, nhiều người nghĩ xác minh hình thức không hiệu Cùng mức độ tin cậy hệ thống đạt với giá rẻ cách sử dụng kỹ thuật xác nhận khác kiểm tra thử nghiệm hệ thống Đôi khi, đòi hỏi việc sử dụng phương pháp hình thức cho phát triển hệ thống dẫn đến hệ thống đáng tin cậy an toàn Không có nghi ngờ đặc điểm kỹ thuật hệ thống hình thức có khả chứa dị thường mà phải giải nhà thiết kế hệ thống Tuy nhiên, đặc điểm kỹ thuật hình thức chứng không đảm bảo phần mềm xem đáng tin cậy sử dụng thực tế Những lý cho việc là: Đặc điểm kỹ thuật không phản ánh yêu cầu thực tế người sử dụng hệ thống Lutz (Lutz, 1993) phát nhiều thất bại mang lại kinh nghiệm người sử dụng hậu lỗi đặc điểm kỹ thuật thiếu sót mà phát đặc điểm kỹ thuật hệ thống hình thức Hơn nữa, người sử dụng hệ thống hiểu ký hiệu định dạng nên họ đọc đặc điểm kỹ thuật thức trực tiếp để tìm lỗi nhiệm vụ Sự kiểm chứng có sai sót Kiểm chứng chương trình lớn phức tạp, vậy, chương trình lớn phức tạp, họ thường có sai sót 30 Sự kiểm chứng giả định mô hình sử dụng không Nếu hệ thống không sử dụng dự kiến, kiểm chứng không hợp lệ Mặc dù nhược điểm họ, quan điểm tác giả (được thảo luận chương 10) phương pháp hình thức có vai trò quan trọng phát triển hệ thống phần mềm then chốt Các thông số kỹ thuật hình thức hiệu việc phát vấn đề đặc điểm kỹ thuật nguyên nhân phổ biến lỗi hệ thống Xác minh hình thức làm tăng độ tin cậy thành phần quan trọng hệ thống Việc sử dụng phương pháp tiếp cận hình thức ngày tăng đòi hỏi kỹ sư nhiều trở nên quen thuộc với kỹ thuật 22.4.1 Phát triển phần mềm phòng (Cleanroom): Phương pháp hình thức tích hợp với số quy trình phát triển phần mềm Trong phương pháp B (Wordsworth, 1996), đặc điểm kỹ thuật hình thức chuyển đổi thông qua loạt biến đổi xác lĩnh vực riêng biệt cho chương trình SDL (Mitschele-Thiel, 2001) sử dụng việc cho phát triển hệ thống viễn thông VDM (Jones, 1986) Z (Spivey, 1992) sử dụng trình kiểu thác nước Một cách tiếp cận tài liệu sử dụng phương pháp hình thức trình phát triển phòng Cleanroom Phát triển phần mềm phòng Cleanroom (Mills, et al, 1987; Cobb Mills Năm 1990; Linger, 1994; Prowell, et al, 1999) triết lý phát triển phần mềm sử dụng phương pháp hình thức để hỗ trợ kiểm tra phần mềm nghiêm ngặt Một mô hình trình phòng Cleanroom hiển thị hình 22.10 Mục tiêu phương pháp để phát triển phần mềm lỗi phần mềm Tên ”Cleanroom” bắt nguồn cách tương tự với đơn vị chế tạo chất bán dẫn lỗi tránh cách sản xuất bầu không khí siêu Phòng Cleanroom phát triển đặc biệt có liên quan đến chương thay kiểm tra đơn vị thành phần hệ thống kiểm tra để kiểm tra phù hợp thành phần với chi tiết kỹ thuật họ 31 Hình 22.10 Quá trình phát triển phòng Phương pháp tiếp cận phòng Cleanroom để phát triển phần mềm dựa năm chiến lược chính: Đặc tả hình thức: Phần mềm phát triển rõ hình thức Một mô hình chuyển trạng thái cho thấy hệ thống phản ứng với kích thích sử dụng để thể đặc điểm kỹ thuật Phát triển gia tăng: Phần mềm phân chia thành lượng gia tăng phát triển xác nhận cách riêng biệt cách sử dụng trình phòng Cleanroom Những gia tăng quy định cụ thể, với đầu vào khách hàng, giai đoạn đầu trình Lập trình cấu trúc: Chỉ có số hạn chế kiểm soát cấu trúc liệu trừu tượng sử dụng Quá trình phát triển chương trình trình sàng lọc theo bước đặc điểm kỹ thuật Một số hạn chế cấu trúc sử dụng mục đích để hệ thống chuyển đổi đặc điểm kỹ thuật để tạo mã chương trình Xác minh tĩnh: Phát triển phần mềm tĩnh xác minh cách sử dụng kiểm tra phần mềm nghiêm ngặt Không có đơn vị trình thử nghiệm mô-đun cho thành phần mã Thống kê thử nghiệm hệ thống: Tăng phần mềm tích hợp thống kê, thảo luận Chương 24, để xác định độ tin cậy Các thử nghiệm thống kê dựa hồ sơ hoạt động, phát triển song song với đặc điểm kỹ thuật hệ thống thể hình 22.10 32 Có ba nhóm tham gia trình phòng Cleanroom sử dụng để phát triển hệ thống lớn: Nhóm nghiên cứu đặc điểm kỹ thuật: Nhóm chịu trách nhiệm cho việc phát triển trì đặc điểm kỹ thuật hệ thống Nhóm sản xuất thông số kỹ thuật định hướng khách hàng (yêu cầu định nghĩa người dùng) thông số kỹ thuật toán học để xác minh Trong số trường hợp, đặc điểm kỹ thuật hoàn tất, nhóm nghiên cứu đặc điểm kỹ thuật chịu trách nhiệm cho phát triển Nhóm phát triển: Nhóm có trách nhiệm phát triển xác minh phần mềm Phần mềm không thực trình phát triển Cấu trúc hình thức A tiếp cận xác minh dựa kiểm tra mã bổ sung với đối số xác sử dụng Nhóm nghiên cứu: Nhóm chịu trách nhiệm cho việc phát triển tập hợp thử nghiệm thống kê để thực phần mềm sau phát triển Những thử nghiệm dựa đặc điểm kỹ thuật hình thức Trường hợp thử nghiệm phát triển thực song song với việc phát triển phần mềm Các trường hợp thử nghiệm sử dụng để xác nhận độ tin cậy phần mềm Mô hình tăng trưởng độ tin cậy (Chương 24) sử dụng để định phải ngừng thử nghiệm Sử dụng phương pháp tiếp cận phòng Cleanroom dẫn đến phần mềm với lỗi Cobb Mills thảo luận số dự án phát triển phòng Cleanroom thành công có tỷ lệ thất bại thấp thống hệ thống phân phối (Cobb Mills, 1990) Các chi phí dự án so sánh với dự án khác có sử dụng kỹ thuật phát triển thông thường Cách tiếp cận để phát triển gia tăng trình phòng Cleanroom để cung cấp chức khách hàng quan trọng bước đầu Hệ thống chức quan trọng bao gồm gia tăng sau Do đó, khách hàng có hội để thử gia tăng quan trọng trước toàn hệ thống chuyển giao Nếu yêu cầu vấn đề phát hiện, khách hàng phản hồi lại thông thông tin cho nhóm phát triển yêu cầu phiên lượng gia tăng Như với lập trình cực đoan, điều có nghĩa chức khách hàng quan trọng nhận xác nhận đa số Với nấc 33 phát triển, họ kết hợp với gia tăng có hệ thống tích hợp thử nghiệm Do đó, gia tăng có thử nghiệm lại với trường hợp thử nghiệm tăng hệ thống thêm vào Chương trình kiểm tra nghiêm ngặt phần trình phòng Cleanroom Một mô hình trạng thái hệ thống sản xuất đặc điểm kỹ thuật hệ thống Điều cải tiến thông qua loạt mô hình hệ thống chi tiết cho chương trình thực thi Cách tiếp cận sử dụng để phát triển dựa chuyển đổi xác định rõ ràng mà cố gắng trước phục vụ đắn chuyển đổi đến biểu diễn chi tiết Với giai đoạn, thể kiểm tra đối số khắt khe toán học phát triển để chứng minh đầu chuyển đổi phù hợp với đầu vào Những đối số toán học sử dụng trình phòng không, nhiên kiểm chứng hình thức tính đắn Những kiểm chứng hình thức toán học chương trình xác liên quan đến đặc điểm kỹ thuật đắt để phát triển Họ phụ thuộc vào việc sử dụng kiến thức ngữ nghĩa hình thức ngôn ngữ lập trình để xây dựng lý thuyết liên quan đến chương trình đặc điểm kỹ thuật hình thức Những lý thuyết sau phải chứng minh toán học, thường với hỗ trợ định lý chương trình lớn phức tạp Bởi chi phí cao kỹ chuyên môn cần thiết, kiểm chứng thường phát triển cho an toàn, an ninh ứng dụng quan trọng Kiểm tra phân tích hình thức tìm thấy hiệu trình phòng Cleanroom Phần lớn khuyết điểm phát trước thực không giới thiệu vào phần mềm phát triển Linger (Linger, 1994) báo cáo rằng, trung bình, có 2,3 lỗi nghìn dòng mã nguồn phát trình thử nghiệm cho dự án phòng Cleanroom Chi phí phát triển tổng thể không tăng nỗ lực cần thiết để thử nghiệm sửa chữa phần mềm phát triển Selby et al, (Selby, et al., 1987), cách sử dụng sinh viên nhà phát triển, thực thử nghiệm so sánh phát triển phòng Cleanroom với kỹ thuật thông thường Họ nhận thấy hầu hết nhóm sử dụng thành công phương pháp phòng Cleanroom Các chương trình sản xuất chất lượng cao so với người phát triển cách sử dụng kỹ thuật truyền thống mã nguồn có ý kiến nhiều cấu trúc đơn giản đội phòng đáp ứng lịch trình phát triển 34 Phát triển phòng Cleanroom hoạt động thực hành kỹ sư có tay nghề cao cam kết báo cáo thành công phương pháp tiếp cận phòng Cleanroom ngành công nghiệp chủ yếu, không độc quyền, đến từ người cam kết với Chúng ta liệu trình chuyển giao có hiệu với loại khác tổ chức phát triển phần mềm Các tổ chức có cam kết tay nghề kỹ sư Chuyển giao phương pháp tiếp cận phòng Cleanroom hoặc, thật vậy, phương pháp tiếp cận khác mà phương pháp hình thức sử dụng cho tổ chức kỹ thuật tiên tiến thách thức 35 Kết Luận Xác minh xác nhận hai công việc khác nhai Xác minh thiết kế thấy chương trình đáp ứng đặc điểm kỹ thuật Xác nhận nhằm mục đích thấy chương trình đáp ứng yêu cầu người dùng Kế hoạch thử nghiệm phải bao gồm mô tả mục để thử nghiệm, lịch trình thử nghiệm, thủ tục để quản lý trình thử nghiệm, phần cứng yêu cầu phần mềm, vấn đề thử nghiệm có khả phát sinh Kỹ thuật xác minh tĩnh liên quan đến kiểm tra phân tích mã nguồn chương trình để phát lỗi Họ nên sử dụng với chương trình kiểm nghiệm phần trình V & V Chương trình kiểm tra có hiệu việc tìm kiếm lỗi chương trình Mục đích kiểm tra để xác định vị trí lỗi Một danh sách kiểm tra lỗi nên điểu khiển trình kiểm tra Trong chương trình kiểm tra, nhóm nhỏ có hệ thống kiểm tra mã Các thành viên nhóm bao gồm đội ngũ lãnh đạo hay điều hành viên, tác giả mã này, biên tập viên trình bày mã thời gian kiểm tra thử nghiệm xem xét mã từ quan điểm thử nghiệm Phân tích tĩnh công cụ phần mềm xử lý chương trình mã nguồn thu hút ý đến dị thường phần mã không sử dụng biến không khởi chạy Những bất thường kết lỗi mã Phát triển phần mềm phòng Cleanroom dựa kỹ thuật tĩnh để xác minh chương trình thử nghiệm thống kê xác nhận độ tin cậy hệ thống Nó thành công việc sản xuất hệ thống có độ tin cậy cao 36 [...]... thống V & V vào một số giai đoạn Mỗi giai đoạn được điều khi n bằng cách thử nghiệm rằng đã được xác định để kiểm tra sự phù hợp của chương trình với thiết kế và đặc điểm kỹ thuật của nó Là một phần của quá trình lập kế hoạch V & V, chúng ta nên quyết định sự cân bằng giữa cách tiếp cận tĩnh và động để xác minh và xác nhận, lập các tiêu chuẩn và thủ tục cho việc kiểm tra và thử nghiệm phần mềm, thiết... thiết lập danh sách kiểm tra để điều khi n sự kiểm tra chương trình (xem Phần 22.3) và xác định kế hoạch kiểm tra phần mềm Những nỗ lực tương quan dành cho kiểm tra và thử nghiệm phụ thuộc vào kiểu hệ thống đang được phát triển và tổ chức chuyên môn với 12 sự kiểm tra chương trình Như một quy tắc chung, một hệ thống then chốt hơn, nỗ lực nhiều hơn nên được dành cho các kỹ thuật xác minh tĩnh Kế hoạch... minh và xác nhận là một quá trình tốn kém Đối với một số hệ thống, chẳng hạn như các hệ thống thời gian thực với những ràng buộc phi chức năng phức tạp, hơn một nửa ngân sách phát triển hệ thống có thể được dành cho V & V Lập kế hoạch cẩn thận là cần thiết để nhận được kết quả tốt nhất của các quá trình thử nghiệm và kiểm tra, và để kiểm soát chi phí quá trình xác minh và xác nhận Hình 22.3 Mô hình quá. .. Hình 22.3 Mô hình quá trình phát triển phần mềm Chúng ta nên bắt đầu lập kế hoạch xác nhận và kiểm tra hệ thống sớm trong quá trình phát triển Quá trình phát triển phần mềm thể hiện trong mô hình Hình 22 3 đôi khi được gọi là V-model Nó là một ví dụ cụ thể của mô hình thác nước chung (xem Chương 4) và cho thấy rằng kế hoạch kiểm tra nên được bắt nguồn từ các đặc điểm kỹ thuật và thiết kế hệ thống Mô... trong quá trình kiểm tra được thể hiện trong hình 22.6 Trước khi bắt đầu một quá trình kiểm tra chương trình, điều quan trọng là: Vai trò Mô tả Tác giả hoặc chủ sở • Các người lập trình hoặc người thiết kế hữu chịu trách nhiệm sản xuất chương trình, tài liệu Chịu trách nhiệm sửa chữa các khi m khuyết được phát hiện trong quá trình kiểm tra Người kiểm tra • Tìm kiếm các lỗi, thiếu sót và không nhất quán... tích của mã nguồn chương trình để phát hiện lỗi Họ nên được sử dụng với chương trình kiểm nghiệm như là một phần của quá trình V & V Chương trình kiểm tra có hiệu quả trong việc tìm kiếm các lỗi chương trình Mục đích của kiểm tra là để xác định vị trí lỗi Một danh sách kiểm tra lỗi nên điểu khi n quá trình kiểm tra Trong một chương trình kiểm tra, một nhóm nhỏ có hệ thống kiểm tra mã Các thành viên trong... kiểm tra thay đổi vì sự chậm trễ ở các giai đoạn khác trong quá trình phát triển Nếu một phần của một hệ thống là không đầy đủ, toàn bộ hệ thống không thể được thử nghiệm Sau đó chúng ta phải xem xét lại kế hoạch kiểm tra để tái phát triển cho người thử nghiệm cho một số hoạt động khác và mang chúng trở lại khi phần mềm có hiệu lực một lần nữa 15 22.2 Kiểm tra phần mềm: Kiểm tra phần mềm là một quá trình. .. thiết cho một kiểm tra và số lượng mã có thể bị che đậy phụ thuộc vào kinh nghiệm của đội kiểm tra, ngôn ngữ lập trình và lĩnh vực ứng dụng Cả hai Fagan tại IBM và Barnard và Price (Barnard và Price, năm 1994), đã đánh giá quá trình kiểm tra cho phần mềm viễn thông đến kết luận tương tự: 1 Khoảng 500 mã nguồn báo cáo mỗi giờ có thể được trình bày trong giai đoạn tổng quan 2 Trong quá trình chuẩn bị cá... ứng đặc điểm kỹ thuật của nó Xác nhận là nhằm mục đích để cho thấy rằng chương trình đáp ứng yêu cầu người dùng Kế hoạch thử nghiệm phải bao gồm một mô tả của các mục để được thử nghiệm, lịch trình thử nghiệm, các thủ tục để quản lý quá trình thử nghiệm, phần cứng và các yêu cầu phần mềm, và các vấn đề thử nghiệm bất kỳ có khả năng phát sinh Kỹ thuật xác minh tĩnh liên quan đến sự kiểm tra và phân tích... hơn và ít tốn kém hơn so với thử nghiệm khi m khuyết trong phát hiện ra lỗi chương trình Gilb và Graham (Gilb và Graham 1993) cũng tìm thấy điều này là đúng Phê duyệt và thử nghiệm đều có ưu và nhược điểm và nên được sử dụng với nhau trong quá trình xác minh và xác nhận Thật vậy, Gilb và Graham cho rằng một trong những sử dụng hiệu quả nhất là để xem xét các trường hợp thử nghiệm cho một hệ thống Nhận