45
ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM VERIFICATION AND VALIDATION GVHD: Lê Mậu Long ĐẠI HỌC TÔN ĐỨC THẮNG_ KHOA CNTT Nhóm 9 (Xác minh và thẩm định)

ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Embed Size (px)

DESCRIPTION

ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM. VERIFICATION AND VALIDATION. (Xác minh và thẩm định). GVHD: Lê Mậu Long. Nhóm 9. ĐẠI HỌC TÔN ĐỨC THẮNG_ KHOA CNTT. Thành viên nhóm. Nhóm 9. Đặng Thanh Hiếu070109T Nguyễn Thị Ngọc Hân070079T Hà Thị Kim Phượng070052T Trần Anh Hào070088T - PowerPoint PPT Presentation

Citation preview

Page 1: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

VERIFICATION AND VALIDATION

GVHD: Lê Mậu Long

ĐẠI HỌC TÔN ĐỨC THẮNG_ KHOA CNTTNhóm 9

(Xác minh và thẩm định)

Page 2: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Thành viên nhóm

Đặng Thanh Hiếu 070109TNguyễn Thị Ngọc Hân 070079THà Thị Kim Phượng 070052TTrần Anh Hào 070088TPhạm Thị Hà 070085T

Nhóm 9

Page 3: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Nội dung trình bày

Giới thiệu xác minh và thẩm định phần mềm, phân biệt sự khác nhau giữa chúng.

Mô tả quá trình kiểm tra chương trình và vai trò cuả nó trong V & V.

Tìm hiểu kĩ thuật phân tích tĩnh Mô tả quá trình phát triển phần mềm

Cleanroom

Nhóm 9

Page 4: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Xác minh và thẩm định

Xác minh:“Chúng ta có tạo ra sản phẩm đúng hay

không” Phần mềm phải phù hợp với đặc tả của

nó“Chúng ta có tạo ra đúng sản phẩm hay

không”Phần mềm phải đáp ứng đầy đủ yêu cầu

của người sử dụng

Nhóm 9

Page 5: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Quá trình V & V

Là quá trình xoay vòng. V & V phải được ứng dụng ở mỗi bước trong các tiến trình phần mềm.

Có 2 nội dung chính:Phát hiện ra những khuyết điểm trong hệ thống

Ước lượng được hệ thống có hữu ích và tiện lợi để sẵn sàng dùng hay không.

Nhóm 9

Page 6: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Mục đích của V & V

Xác minh và thẩm định phải tạo được sự tin tưởng rằng phần mềm phải phù hợp với mục đích.

Điều này không có nghĩa là nó hoàn toàn không có khuyết điểm

Hơn nữa, nó phải đáp ứng được đầy đủ các chức năng dự định và các loại chức năng sẽ quyết định mức độ tin cậy cần thiết.

Nhóm 9

Page 7: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Sự tin cậy V & V

Phụ thuộc vào mục đích hệ thống, sự mong đợi của người sử dụng và môi trường tiếp thị

Chức năng phần mềm: Mức độ tin cậy được phụ thuộc vào sự đánh giá phần mềm được tổ chức như thế nào

Sự mong đợi của người sử dụng: Người sử dụng ít kì vọng các loại phần mềm

Môi trường tiếp thị: Đưa sản phẩm ra thị trường sớm thì quan trọng hơn là tìm ra những khuyết điểm chương trình

Nhóm 9

Page 8: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Xác minh tĩnh và động

Kiểm tra phần mềm:Liên quan đến phân tích các biểu hiện tĩnh của hệ thống để phát hiện vấn đề(xác minh tĩnh)

Liên quan đến việc ứng dụng và nhận xét các phản hồi sản phẩm.

Nhóm 9

Page 9: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Xác minh tĩnh và động Nhóm 9

Page 10: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Kiểm thử chương trình Nhóm 9

Có thể phát hiện ra những lỗi tiềm ẩn Kĩ thuật thẩm định cho yêu cầu phi chức

năng thì khi chương trình được thực thi nó có thể biết được cách hoạt động.

Nên sử dụng kết hợp các xác minh tĩnh để cung cấp đầy đủ các chức năng của V&V

Page 11: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Các loại kiểm thử Nhóm 9

Kiểm thử các khuyết điểm: Những phương thức kiểm tra được thiết kế để phát hiện

ra những khuyết điểm của hệ thốngMột phương thức kiểm tra khuyết điểm thành công là tìm

thấy những khuyết điểm tồn tại trong hệ thốngKiểm thử thẩm định:

Dùng để chỉ ra rằng các phần mềm đáp ứng được những yêu cầu

Phương thức kiểm tra thành công để chỉ ra rằng những yêu cầu được thực thi chính xác.

Page 12: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Kiểm thử và sửa lỗi Nhóm 9

Kiểm thử khuyết điểm và sửa lỗi là những quá trình riêng biệt

Xác minh và thẩm định là liên quan đến việc chứng minh sự tồn tại những khuyết điểm trong chương trình.

Sửa lỗi là liên quan đến việc xác định vị trí và sửa lỗi.

Sửa lỗi đòi hỏi phải thiết lập một giả thuyết về hoạt động chương trình sau đó kiểm thử những giả thiết này để tìm thấy lỗi hệ thống

Page 13: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Qúa trình sửa lỗi Nhóm 9

Page 14: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Kế hoạch V & V Nhóm 9

Thẩm định và xác minh là 1 tiến trình tốn kém. Kế hoạch an toàn là cần phải xem xét kĩ, kiểm tra và hạn chế chi phí dành cho V & V.

Cần sớm có 1 kế hoạch thẩm định và xác minh hệ thống trong các bước tiến trình.

Cần quyết định dựa trên sự cân bằng giữa thẩm định và xác minh động và tĩnh

Kiểm tra để xác nhận sự tương thích giữa chương trình với phần thiết kế và đặc tả của nó.

Page 15: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Sự phát triển của tiến trình chữ V Nhóm 9

3 Kế hoạch kiểm thử liên kết giữa thành viên phát triển dự án và lập trình

Page 16: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

cấu trúc của kế hoạch kiểm thử phần mềm Nhóm 9

Tiến trình kiểm thử

Yêu cầu truy xuất nguồn gốc.

Danh mục kiểm thử.

Sao lưu lại những thủ tục kiểm thử..

Các yêu cầu về phần cứng và phần mềm.

Những hạn chế.

Page 17: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Kế hoạch kiểm thử phần mềm Nhóm 9

Tiến trình kiểm thửMô tả về các giai đoạn chính của quá trình thử nghiệm. Khả năng lần vết theo yêu cầuNgười dùng quan tâm nhất trong hệ thống đáp ứng yêu cầu của mình và cần phải lên kế hoạch để tất cả các yêu cầu được thử nghiệm riêng lẻ các thành phần kiểm thử Các sản phẩm của quá trình phần mềm nên được kiểm thử theo quy địnhLịch kiểm thửthủ tục ghi nhận kiểm thử.Không phải đơn giản là chạy để kiểm thử. Tất cả các kết quả kiểm thử phải được ghi lại 1 cách hệ thống, nó phải được kiểm toán thật tốt các quá trình kiểm thử để kiểm tra xem nó đã được thực hiện đúng hay không. Các yêu cầu về phần cứng và phần mềnNhững công cụ phần mền và ước tính phần cứng phải sử dụng Những ràng buộcHạn chế ảnh hưởng đến quá trình kiểm thử chẳng hạn như thiếu nhân viên nên được dự kiến.

Page 18: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

kiểm tra phần mềm Nhóm 9

Kiểm tra phần mềm là một quá trình thẩm định và xác minh tĩnh, trong đó một phần mềm được xem xét để tìm ra các lỗi, những bỏ xót và bất thường.

Khi kiểm tra hệ thống, bạn sử dụng kiến thức của hệ thống, ứng dụng của nó và ngôn ngữ lập trình hay mô hình thiết kế để phát hiện lỗi.

Page 19: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Có 3 đặc điểm chính khi kiểm thử Nhóm 9

Vì kiểm tra là một quá trình tĩnh, bạn không phải quan tâm đến sự tương tác giữa các sai sót. do đó, một buổi kiểm tra duy nhất có thể phát hiện ra nhiều sai sót trong hệ thống.

Phiên bản không đầy đủ của một hệ thống có thể được kiểm tra mà không có thêm chi phí.

kiểm tra cũng có thể xem xét các thuộc tính chất lượng rộng lớn hơn của một chương trình như phù hợp với tính di động, tiêu chuẩn và bảo trì.

Page 20: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Kiểm tra và kiểm thử Nhóm 9

Đánh giá và thử nghiệm từng có lợi thế và bất lợi và cần được sử dụng cùng nhau trong quá trình xác minh và thẩm định

Selby and Basili ( Selby, et al., 198.7) thực nghiệm so sánh kiểm tra hiệu quả và ít tốn kém hơn so với kiểm thử trong việc phát hiện lỗi chương trình.

Một trong những sử dụng hiệu quả nhất của kiểm tra là xem xét các trường hợp kiểm thử cho một hệ thống. bạn có thể bắt đầu xác minh và thẩm định hệ thống với kiểm tra sớm trong quá trình phát triển, nhưng một khi hệ thống được tích hợp, bạn cần kiểm tra để kiểm tra giao diện chức năng của nó và chức năng của hệ thống là những gì mà chủ sở hữu của hệ thống thực sự muốn

Page 21: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Kiểm tra chương trình Nhóm 9

Cần một tài liệu chính thức để hỗ trợ các kế hoạch của quá trình kiểm tra.

Khuyết điểm có thể là các lỗi logic, dị thường trong mã có thể chỉ ra một tình trạng sai lệch hoặc không tuân thủ các tiêu chuẩn tổ chức, dự án.

Page 22: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Quá trình kiểm tra Nhóm 9

Page 23: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Thủ tục kiểm tra Nhóm 9

Trình bày tổng quan về hệ thống với đội kiểm tra.

Tài liệu liên quan và mã chương trình được giao cho đội kiểm tra trước.

Kiểm tra và phát hiện các lỗi ghi nhận.Sửa chữa các lỗi được phát hiện.Kiểm tra lại lần nữa.

Page 24: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Vai trò các thành viên Nhóm 9

Page 25: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Các lưu ý trong kiểm tra Nhóm 9

Việc kiểm tra không nên quá 2 giờ và chủ yếu tập trung vào các sai sót, không phù hợp tiêu chuẩn và lập trình kém chất lượng.

Đội kiểm tra không nên đề nghị để sữa các khuyết điểm, không nên khuyên thay đỗi thành phần khác.

Sau kiểm tra, tác giả chương trình nên thay đổi nó để sửa chữa những vấn đề đã xác định.

Bạn cần bản danh sách khác nhau cho các ngôn ngữ lập trình khác nhau, vì mỗi ngôn ngữ có lỗi của riêng đặc trưng của nó

Page 26: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Xem xét kiểm tra Nhóm 9

Page 27: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Xem xét kiểm tra Nhóm 9

Page 28: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Xem xét kiểm tra Nhóm 9

Page 29: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Tốc độ kiểm tra Nhóm 9

Thời gian cần thiết cho một cuộc kiểm tra và số lượng code có thể được bảo vệ tùy 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ác nhân viên kiểm tra mất khoảng một giờ và mỗi thành viên trong nhóm dành 1-2 giờ chuẩn bị cho việc kiểm tra.

Page 30: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

phân tích tĩnh tự động Nhóm 9

Phân tích tĩnh là những công cụ phần mềm quét văn bản mã nguồn của một chương trình và phát hiện lỗi có thể và dị thường.

Chúng phát hiện câu lệnh lỗi theo khuôn định sẵn nhằm mục đích là để thu hút sự chú ý của một kiểm tra viên đến dị thường trong chương trình.

Page 31: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

phân tích tĩnh tự động Nhóm 9

Định dạng lỗi thường gặp Sự kiểm tra phân tích tĩnh

Lỗi dữ liệu -Những biến được dùng trước khi khởi động .-Những biến đã được khai báo nhưng không được sử dụng-Những biến được gán 2 lần nhưng không được sử dụng giữa 2 thao tác-Mảng tồn tại giới hạn những sự vi phạm-Những biến không được khai báo

Lỗi điều khiển -Những đoạn mã không thể ảnh hưởng đến-Những nhánh không chịu ảnh hưởng bởi điều kiện của vòng lặp

Lỗi xuất /nhập -Những biến xuất 2 lần mà không xảy ra giữa những thao tác

Lỗi giao diện -Những kiểu tham số không phù hợp-Số lượng tham số không phù hợp-Không sử dụng kết quả của các hàm chức năng-Những hàm và thủ tục không được gọi

Lỗi quản lý bộ nhớ -Những con trỏ không được xác định-Chỉ số con trỏ

Page 32: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Các giai đoạn phân tích tĩnh Nhóm 9

Sự phân tích dòng điều khiển:Kiểm tra những vòng lặp với nhiều kiểu xuất và nhập,tìm thấy những đoạn code không thể truy cập

Phân tích cách sử dụng dữ liệu: phát hiện ra những biến được sử dụng mà không khởi động ,những biến mà được viết 2 lần mà không có thao tác xen giữa và những biến được khai báo nhưng không sử dụng .

Phân tích giao diện:kiểm tra tính nhất quán của những khai báo thông thường và khai báo thủ tục cũng như cách sử dụng của chúng.

Phân tích luồng thông tin:Xác định sự phụ thuộc của các biến đầu ra .Nó không phát hiện ra những bất thường mà đưa ra những thông tin cho việc kiểm tra code và kiểm duyệt.

Phân tích đường dẫn: Xác định các đường dẫn thông qua chương trình và đưa ra các câu lệnh đã thực hiện trong đường dẫn đó.Điều này có thể hữu ích trong quá trình xem xét .

Cả hai giai đoạn này tạo ra khối lượng lớn thông tin .Chúng phải được sử dụng cẩn thận.

Page 33: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Phân tích tĩnh LINT Nhóm 9

138% more lint_ex.c#include<stdio.h>Printarray(Anarray)Int Anarray;{

ptintf(“%d”,Anarray);}main(){

int Anarray[5] ; int i ; char c;printarray(Anarray,i,c);printarray(Anarray);

}139% cc lint_ex.c140% lint lint_ex.cLint_ex.c(10) :cảnh báo :c có lẽ được dùng trước khi thiết lậpLint_ex.c(10) :cảnh báo :i có lẽ được dùng trước khi thiết lậpPrintarray :biến# của mảngPrintarray,mảng 1 được dùng không nhất quán lint_ex.c(4) ::lint_ex.c(10)Printarray,mảng 1 được dùng không nhất quán lint_ex.c(4) ::lint_ex.c(11)Giá trị trả về của printf luôn bị gạt bỏ

Page 34: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Việc sử dụng phân tích tĩnh Nhóm 9

Thật sự có ích khi sử dụng ngôn ngữ định kiểu yếu như C,trình biên dich có thể phát hiện nhiều lỗi.

Ít hiệu quả hơn đối với ngôn ngữ đã kiểm tra kiểu mạnh như Java,vốn đã phát hiện nhiều lỗi trong quá trình biên dịch.

Page 35: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Thẩm định và phương pháp hình thức Nhóm 9

phương pháp hình thức có thể được sử dụng khi một đặc tả toán học của hệ thống được đưa ra.

Là kĩ thuật xác minh tĩnh cuối cùngChúng liên quan đến phân tích toán học một cách chi tiết của đặc tả và có thể phát triển các đối số chính thức mà một chương trình phù hợp với đặc tả toán học của nó.

Page 36: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Những lập luận của những phương pháp hình thức

Đưa ra một đặc tả toán học đòi hỏi phải phân tích chi tiết về các yêu cầu và điều này có thể phát hiện ra lỗi.

Khi chương trình được kiểm tra cùng với các đặc tả,chúng có thể phát hiện những lỗi thực thi trước khi kiểm tra

Page 37: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Lập luận chống lại phương pháp hình thức

Các chuyên gia trong lĩnh vực ứng dụng không thể hiểu được những kí hiệu chuyên dụng.

Rất tôn kém để phát triển một đăc tả và thậm chí đắt hơn nữa để thấy rằng một chương trình đáp ứng đủ các đặc tả.

Nó có lẽ rẻ hơn các kĩ thuật V&V khác nhưng vẫn đạt được cùng mức độ tin cậy trong chương trình

Nhóm 9

Page 38: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Phát triển phần mềm Cleanroom

Tên gọi này có nguồn gốc từ quá trình “cleanroom" trong chế tạo bán dẫn. Thực tế là tránh lỗi hơn là loại bỏ khiếm khuyết.

Tiến trình phát triển phần mềm này dựa trên:1. Sự phát triển gia tăng2. Đặc tả chính thức3. Xác minh tĩnh có sử dụng những lập luận

chính xác4. Kiểm thử tĩnh để quyết định độ tin cậy của

chương trình.

Nhóm 9

Page 39: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Phát triển phần mềm Cleanroom Nhóm 9

Page 40: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Đặc điểm của quá trình Cleanroom

Các hình thức đặc tả sử dụng mô hình chuyển đổi trạng thái

Sự phát triển ngày càng được mở rộng khi mà sự ưu tiên của khách hàng ngày càng tăng

Cấu trúc chương trình được hạn chế kiểm soát và cấu trúc trừu tượng thì được sử dụng trong chương trình

Xác minh tĩnh được kiểm tra nghiêm ngặt

Nhóm 9

Page 41: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Hình thức đặc tả và sự kiểm tra

Các mô hình trạng thái phụ thuộc vào đặc tả hệ thống và quá trình kiểm tra để kiểm tra chương trình lần nữa theo mô hình này.

Phương pháp lập trình được xác định để tương thích giữa các mô hình và hệ thống

Lập luận toán học được sử dụng để tăng sự tin cậy trong quá trình kiểm tra

Nhóm 9

Page 42: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Các nhóm tiến trình cleanroom

Nhóm đặc tả: Nhóm này chịu trách nhiệm phát triển và duy trì đặc tả hệ thống

Nhóm phát triển: Chịu trách nhiệm phát triển và xác minh hệ thống. Phần mềm này không được thực thi hoặc không biên dịch được trong quá trình.

Nhóm xác nhận: Nhóm này chịu trách nhiệm về việc tổng hợp lại các trường hợp kiểm tra để thực thi phần mềm trước khi phát triển. Mô hình phát triển độ tin cậy được sử dụng để quyết định khi nào thì dừng thử nghiệm

Nhóm 9

Page 43: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Qúa trình đánh giá Cleanroom

Kết quả của việc sử dụng quá trình Cleanroom đã phát hiện ra những khuyết điểm trong phát biểu hệ thống.

Dựa vào sự đánh giá khách quan cho thấy quá trình này thì không đắt hơn các phương pháp tiếp cận khác

Có lỗi ít hơn trong quá trình phát triển truyền thốngTuy nhiên, quá trình này thì không được sử dụng

rộng rãi.

Nhóm 9

Page 44: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Những điểm chính

Xác minh và thẩm định thì không tương tự nhau

Xác minh phải đáp ứng được đặc tả hệ thống. Thẩm định thì đáp ứng được yêu cầu khách hàng

Các công cụ tĩnh có thể phát hiện ra những chương trình không ổn định, có những lỗi trong code

Sự phát triển quá trình Cleanroom phụ thuộc vào sự phát triển ngày càng mở rộng, xác minh tĩnh và thống kê kiểm thử

Nhóm 9

Page 45: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Thanks you for listen to me