XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI , ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Ngành Kỹ thuật phần mềm , ĐỀ TÀI XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM , Giảng viên HD Hà Nội 1 LỜI CẢM ƠN Để hoàn thiện được đề tài Bài tập lớn môn Đảm bảo chất lượng phần mềm, em xin gửi lời cảm ơn chân thành đến trường Đại học Công nghiệp Hà Nội, khoa Công nghệ thông tin đã tạo điều kiện cho em được học tập Em xin gửi lời cảm ơn chân thành đến các thầy cô trong khoa Công nghệ thông tin đã truyền đạt ch.

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Ngành Kỹ thuật phần mềm ĐỀ TÀI: XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Giảng viên HD : TS Vũ Đình Minh Hà Nội LỜI CẢM ƠN Để hoàn thiện đề tài Bài tập lớn môn Đảm bảo chất lượng phần mềm, em xin gửi lời cảm ơn chân thành đến trường Đại học Công nghiệp Hà Nội, khoa Công nghệ thông tin tạo điều kiện cho em học tập Em xin gửi lời cảm ơn chân thành đến thầy cô khoa Công nghệ thông tin truyền đạt cho em nhiều kiến thức trình học tập trường Đặc biệt em xin chân thành cảm ơn đến thầy giáo TS.Vũ Đình Minh Trong suốt q trình làm tập lớn thầy ln giúp đỡ, hướng dẫn tận tình, truyền đạt kiến thức kinh nghiệm cho em để em hồn thành đề tài Em cố gắng hoàn thiện báo cáo tập lớn tốt tránh thiếu sót Em mong nhận góp ý thầy bạn để báo cáo em hoàn thiện Em xin chân thành cảm ơn! LỜI MỞ ĐẦU Ngày nay, Cơng nghệ thơng tin có bước phát triển mạnh mẽ theo chiều rộng chiều sâu Máy tính điện tử khơng cịn thứ phương tiện quý mà ngày trở thành cơng cụ làm việc giải trí thơng dụng người, khơng cơng sở mà cịn gia đình Đứng trước vai trị thông tin hoạt động cạnh tranh gay gắt, tổ chức doanh nghiệp tìm biện pháp để xây dựng hồn thiện hệ thống thơng tin nhằm tin học hóa hoạt động tác nghiệp đơn vị Tự động hóa ngày có vai trị quan trọng kinh tế tồn cầu kinh nghiệm hàng ngày Các kỹ sư cố gắng làm cho thiết bị tự động hoá kết hợp với cơng cụ tốn học tổ chức để tạo hệ thống phức tạp cho phạm vi nhanh chóng phát triển rộng lớn ứng dụng hoạt động người Hiện công ty tin học hàng đầu giới không ngừng đầu tư cải thiện giải pháp sản phẩm nhằm cho phép tiến hành thương mại hóa Internet Thơng qua sản phẩm công nghệ này, dễ dàng nhận tầm quan trọng tính tất yếu thương mại điện tử Với thao tác đơn giản máy có nối mạng Internet bạn có tận tay cần mà khơng phải nhiều thời gian Bạn cần vào trang dịch vụ thương mại điện tử, làm theo hướng dẫn click vào bạn cần Các nhà dịch vụ mang đến tận nhà cho bạn Để tiếp cận góp phần trình xây dựng, phát triển đảm bảo chất lượng cho phần mềm nhóm chúng em tìm hiểu đưa đánh giá cho trình phân tích thiết kế tự động nghiên cứu tới cơng cụ phần mềm hỗ trợ phân tích thiết kế tự động Với hướng dân tận tình thầy Vũ Đình Minh chúng em hồn thành tập lớn Tuy cố gắng để tìm hiểu, phân tích, cài đặt sử dụng tránh khỏi thiếu sót Chúng em mong nhận thơng cảm góp ý Thầy Chúng em xin chân thành cảm ơn MỤC LỤC MỞ ĐẦU Tên đề tài “ Xác minh (Verification) Thẩm định (Validation) Đảm bảo chất lượng phần mềm ” I Lý chọn đề tài Trong trình phát triển phần mềm, thường gặp phải vấn đề : Chúng ta có tạo sản phẩm hay khơng? Phần mềm có phù hợp với đặc tả hay khơng? Phần mềm có đáp ứng u cầu khách hàng hay khơng? Chúng ta có tạo sản phẩm hay không? Để giải vấn đề nêu sử dụng mơ hình V&V suốt q trình phát triển phần mềm để tạo phần mềm đặc tả yêu cầu khách hàng Mục đích đề tài Tìm hiểu mơ hình V&V q trình phát triển kiểm tra phần mềm So sánh điểm giống khác Xác minh Thẩm định Mô tả q trình kiểm tra chương trình vai trị chúng mơ hình V&V Bố cục đề tài Nội dung đề tài trình bày chương Chương : Tổng quan đảm bảo chất lượng phần mềm Chương : Xác minh Thẩm định Chương : Mơ hình V Cleanroom CHƯƠNG TỔNG QUAN VỀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 1.1 Chất lượng phần mềm đảm bảo chất lượng phần mềm a Định nghĩa chất lượng phần mềm • Có nhiều định nghĩa chất lượng phần mềm đưa tổ chức, cá nhân khác Trong phạm vi viết trình bày số định nghĩa tiêu biểu *Định nghĩa theo IEEE(1991):  Định nghĩa 1: Chất lượng phần mềm mức độ mà hệ thống, thành phần hệ thống hay tiến trình đáp ứng yêu cầu đặc tả  Định nghĩa 2: Chất lượng phần mềm mức độ mà hệ thống, thành phần hệ thống hay tiến trình đáp ứng yêu cầu mong đợi khách hàng hay người sử dụng *Phân tích hai quan điểm IEEE: • Theo quan điểm thứ IEEE: bị phụ thuộc nhiều vào tài liệu đặc tả yêu cầu, dẫn đến việc xấc định yêu cầu bị sai, thiếu phần mềm làm với đặc tả chưa phần mềm có chất lượng • Theo quan điểm thứ hai IEEE: khách hàng đơi khơng có kiến thức cơng nghệ, họ đưa mong muốn vơ lý thay đổi u cầu với phần mềm nhiều lần, chí thay đổi giai đoạn cuối Điều gây nhiều khó khăn cho việc phát triển phần mềm *Định nghĩa theo Pressman: Chất lượng phần mềm phù hợp yêu cầu cụ thể hiệu chức năng, tiêu chuẩn phát triển phần mềm ghi lại rõ ràng tài liệu với đặc tính ngầm định tất phần mềm phát triển chuyên nghiệp Định nghĩa Pressman đề xuất ba yêu cầu với chất lượng phần mềm phải đáp ứng phát triển phần mềm : • Các yêu cầu chức rõ ràng nhân tố định chất lượng đầu phần mềm • Các tiêu chuẩn chất lượng phần mềm nói đến trơng hợp đồng • Các đặc tính ngầm định cần đáp ứng trình phát triển cho dù khơng nói đến rõ ràng hợp đồng b Định nghĩa đảm bảo chất lượng phần mềm Định nghĩa theo Daniel Galin: Đảm bảo chất lượng phần mềm (Software Quality Assure) tập hợp hành động cần thiết lên kế hoạch cách hệ thống để cung cấp đầy đủ niềm tin trình phát triển phần mềm phù hợp để thành lập yêu cầu chức kỹ thuật yêu cầu quản lý theo lịch trình hoạt động giới hạn ngân sách c Đặc trưng ảnh hưởng tới chất lượng phần mềm • Tính đắn : mức độ mà dự án hoàn thành đặc tả • Tính hiệu quả: dùng tài ngun thực lưu giữ • Tính linh hoạt: dễ làm thay đổi yêu cầu thay đổi môi trường vận hành • Tính tồn vẹn: bảo vệ dự án khỏi truy nhập khơng phép • Tính liên tác: nỗ lực yêu cầu để tích hợp hệ thống vào hệ thống khác • Tính bảo trì: nỗ lực yêu cầu để định vị sửa lỗi dự án mơi trường vận hành • Tính khả chuyển: nỗ lực u cầu để truyền dự án từ môi trường sang môi trường khác • Tính tin cậy: khả khơng hỏng • Tính tái dụng: dễ dùng lại phần mềm hồn cảnh khác • Tính kiểm thử được: dễ dàng kiểm thử dự án để đảm bảo khơng lỗi đáp ứng đặc tả • • • Tính khả dụng: dễ dùng phần mềm Tính tái dụng: dễ dùng lại phần mềm hồn cảnh khác Tính kiểm thử được: dễ dàng kiểm thử dự án để đảm bảo khơng lỗi đáp ứng đặc tả • Tính khả dụng: dễ dùng phần mềm Tất nhiên, giới hoàn hảo tất tiêu chí đáp ứng, thực tế việc bù trừ phần dự án phát triển Thường phần mềm hiệu lại không khả chuyển, tính khả chuyển u cầu mã phụ thêm, làm giảm tính hiệu Tính khả dụng chủ quan thay đổi tuỳ theo kinh nghiệm người dùng Khi dùng tiêu chí để xác định mục tiêu đảm bảo hệ thống phần mềm, mục đích việc dùng hệ thống phải tính tới Trong giới thực phát triển phần mềm, tiêu chí chất lượng nhận diện áp dụng cho mức độ khác biệt xem kết định bù trừ 1.2 Lỗi phần mềm nguyên nhân gây lỗi phần mềm 1.2.1 Lỗi phần mềm Có nhiều nguyên nhân gây lỗi phần mềm, biểu lỗi khác giai đoạn phát triển phần mềm Có ba loại lỗi phần mềm : Error: Là phần code mà khơng phần tồn kết lỗi ngữ pháp, logic lỗi khác sinh nhà phân tích hệ thống, lập trình viên thành viên khác đội phát triển phần mềm Fault: Là errors mà gây hoạt động khơng xác phần mềm ứng dụng cụ thể Failures: Các faults trở thành failures chúng “activated” người dùng cố gắng áp dụng phần mềm cụ thể bị faulty Do đó, nguồn gốc failure errors 1.2.2 Nguyên nhân gây lỗi phần mềm Việc phát lỗi cần thiết, tìm nguyên nhân gây lỗi để tránh lỗi tương lai thực quan trọng Chín nguyên nhân gây lỗi phần mềm thống kê sau tổng kết sau nhiều năm nghiên cứu : • Định nghĩa yêu cầu lỗi • Lỗi giao tiếp khách hàng người phát triển • Sự thiếu rõ ràng yêu cầu phần mềm • Lỗi thiết kế logic • Lỗi coding • Khơng phù hợp với tài liệu thị coding • Thiếu sót q trình kiểm thử • Lỗi thủ tục • Lỗi tài liệu Nội dung cụ thể nguyên nhân xác định sau : - Định nghĩa yêu cầu bị lỗi Việc xác định lỗi yêu cầu, thường khách hàng, nguyên nhân lỗi phần mềm Các lỗi phổ biến loại là: • Sai sót định nghĩa u cầu • Khơng có u cầu quan trọng • Khơng hồn chỉnh định nghĩa u cầu • Bao gồm yêu cầu không cần thiết, chức mà không thực cần thiết tương lai gần - Các lỗi giao tiếp khách hàng nhà phát triển Hiểu lầm giao tiếp khách hàng nhà phát triển nguyên nhân bổ sung cho lỗi ưu tiên áp dụng giai đoạn đầu q trình phát triển: • Hiểu sai dẫn khách hàng nêu tài liệu yêu cầu • Hiểu sai yêu cầu thay đổi khách hàng trình bày với nhà phát triển văn giai đoạn phát triển • Hiểu sai yêu cầu thay đổi khách hàng trình bày lời nói với nhà phát triển giai đoạn phát triển • Hiểu sai phản ứng khách hàng vấn đề thiết kế trình bày nhà phát triển • Thiếu quan tâm đến đề nghị khách hàng đề cập đến yêu cầu thay đổi khách hàng trả lời cho câu hỏi nêu nhà phát triển phần nhà phát triển - Sai lệch có chủ ý từ yêu cầu phần mềm Trong số trường hợp, nhà phát triển cố tình chệch khỏi u cầu tài liệu, hành động thường gây lỗi phần mềm Các lỗi trường hợp sản phẩm phụ thay đổi Các tình thường gặp là: • Phát triển module phần mềm Các thành phần sử dụng lại lấy từ dự án trước mà khơng cần phân tích đầy đủ thay đổi thích nghi cần thiết để thực cách xác tất yêu cầu • Do thời gian hay áp lực ngân sách, nhà phát triển định bỏ qua phần yêu cầu chức nỗ lực để đối phó với áp lực 10 tế • Xác minh không liên quan đến executing code Xác thực liên quan đến executing code • Xác minh sử dụng phương pháp đánh giá, hướng dẫn, kiểm tra kiểm tra bàn Xác thực sử dụng phương pháp Black Box Testing, White Box Testing non-functional testing • Xác minh kiểm tra xem phần mềm có thẩm định thơng số kỹ thuật hay không Thẩm định kiểm tra xem phần mềm có đáp ứng yêu cầu mong đợi hay khơng • Xác minh tìm thấy lỗi sớm chu kỳ phát triển Thẩm định tìm thấy lỗi mà xác minh khơng thể bắt • So sánh thẩm định xác minh kiểm thử phần mềm Các mục tiêu trình xác minh kiến trúc phần mềm, thiết kế, sở liệu, v.v trình Thẩm định nhắm mục tiêu đến sản phẩm phần mềm thực tế • Việc xác minh thực nhóm QA Xác thực thực tham gia nhóm thử nghiệm với nhóm QA • So sánh Xác minh kiểm tra Thẩm định quy trình xác minh đến trước thẩm định quy trình thẩm định diễn sau xác minh - Biểu đồ so sánh Xác minh (Verification) Thẩm định (Validation)  Quá trình xác minh bao gồm kiểm tra tài liệu, thiết kế, mã chương trình  Đây chế động để kiểm tra thẩm định sản phẩm thực tế  Nó khơng liên executing code  Nó ln liên quan đến việc thực thi mã quan đến việc 19  Nó sử dụng phương pháp Black Box Testing, White Box Testing non-functional testing  Nó kiểm tra xem phần mềm có đáp ứng yêu cầu mong đợi khách hàng hay khơng  Nó tìm thấy lỗi mà q trình xác minh khơng thể bắt  Mục tiêu sản phẩm thực tế  Với tham gia nhóm thử nghiệm, xác thực thực thi mã phần mềm  Nó đến sau xác minh Xác minh sử dụng phương pháp đánh giá, hướng dẫn, kiểm tra desk- checking, v.v  Kiểm tra xem phần mềm có tuân theo đặc điểm kỹ thuật hay khơng  Nó phát lỗi sớm chu kỳ phát triển  Mục tiêu ứng dụng kiến trúc phần mềm, đặc điểm kỹ thuật, thiết kế hoàn chỉnh, mức độ cao thiết kế sở liệu, v.v   Nhóm QA thực xác minh đảm bảo phần mềm theo yêu cầu tài liệu SRS Nó đến trước xác thực  2.3 Xác minh thẩm định theo tiêu chuẩn a, ISO / IEC 12207:2008 Các hoạt động Verification • Xác minh yêu cầu: tham gia eview yêu cầu • Xác minh thiết kế: tham gia đánh giá tất tài liệu thiết kế bao gồm HLD LDD • Kiểm tra code: thực review code • Xác minh tài liệu: kiểm tra hướng dẫn sử dụng tài liệu liên quan khác Các hoạt động Validation • Chuẩn bị tài liệu test requirement, test case thơng số test khác để phân tích kết test 20 • Đánh giá yêu test requirement, test case thông số kỹ thuật khác phản ánh yêu cầu phù hợp để sử dụng • Test giá trị biên, stress chức • Test thơng báo lỗi trường hợp có lỗi nào, ứng dụng kết thúc • Kiểm tra xem phần mềm có đáp ứng yêu cầu nghiệp vụ phù hợp để sử dụng hay khơng b, CMMI Các hoạt động Verification • Thực peer reviews • Xác minh work product lựa chọn • Chuẩn hóa quy trình cách thiết lập qui tắc để lên kế hoạch thực đánh giá Các hoạt động Validation • Thẩm định sản phẩm component sản phẩm phù hợp với mơi trường • Khi validation thực hiện, theo dõi kiểm sốt • Rút học kinh nghiệm thu thập thơng tin cải tiến • Thiết lập quy trình định c,IEEE 1012 Mục tiêu hoạt động Verification Validation sau: Phát sửa lỗi sớm Khuyến khích tăng cường can thiệp quản lý vào bên qui trình rủi ro sản phẩm Cung cấp biện pháp hỗ trợ vòng đời phần mềm, nhằm tăng cường tuân thủ yêu cầu schedule budget 2.4 Vai trò xác minh thẩm định phát triển phần mềm Các vai trò khác Xác minh thẩm định (V&V) SDLC quy trình kiểm thử phần mềm đưa đây: - Phân tích : Xác định nguồn gốc : Khả xác định nguồn gốc định nghĩa 21 thuộc tính mơ tả mức độ mà truy tìm đến điểm xuất xứ Nó mơ tả khả thiết lập mối quan hệ tiền nhiệm - kế thừa sản phẩm làm việc với sản phẩm khác Nó giúp chúng tơi truy tìm u cầu phần mềm trở lại yêu cầu hệ thống ban đầu thiết lập hoạt động khái niệm Vấn đề đảm bảo yêu cầu đáp ứng xác u cầu hệ thống khơng có thêm thứ yêu cầu phần mềm Trong kỹ thuật này, xác định xem yêu cầu bắt nguồn có phù hợp với mục tiêu ban đầu, quy luật vật lý công nghệ mô tả tài liệu hệ thống hay khơng - Phân tích giao diện Là phân tích chi tiết đặc tả yêu cầu giao diện vịng đời phát triển phần mềm Nó giúp xác định giao diện ứng dụng để xác định yêu cầu đảm bảo thành phần tương tác với cách hiệu Các tiêu chí đánh giá giống tiêu chí đặc tả u cầu giúp chúng tơi xác định yêu cầu khả tương tác Mục tiêu phân tích giao diện phần mềm, phần cứng người dùng - Phân tích mức độ nghiêm trọng Mức độ nghiêm trọng đưa cho yêu cầu phần mềm yêu cầu kết hợp thành chức năng, mức độ nghiêm trọng tổng hợp yêu cầu tạo thành mức độ nghiêm trọng cho chức tổng hợp Phân tích mức độ phê bình cập nhật thường xuyên sau có thay đổi yêu cầu Điều thay đổi gây tăng giảm mức độ nghiêm trọng chức năng, điều phụ thuộc vào cách yêu cầu sửa đổi tác động đến mức độ nghiêm trọng hệ thống Phân tích Mức độ nghiêm trọng có bước sau: • Bước xây dựng sơ đồ luồng điều khiển (CFD) hệ thống với phần tử khối đại diện cho chức 22 phần mềm • Sau đó, tiếp theo, theo dõi chức quan trọng yêu cầu chất lượng với trợ giúp sơ đồ luồng điều khiển • Phân loại tất chức phần mềm truy tìm quan trọng để thực chức yêu cầu chất lượng quan trọng phần mềm • Tập trung phân tích bổ sung vào chức phần mềm quan trọng theo dõi • Cuối cùng, lặp lại phân tích mức độ nghiêm trọng cho quy trình vịng đời để kiểm tra xem chi tiết triển khai có thay đổi trọng tâm mức độ nghiêm trọng hay không • Phân tích rủi ro Rủi ro thực hoạt động xác định yêu cầu Trong phân tích này, mối nguy rủi ro xác định cách tinh chỉnh yêu cầu hệ thống thành yêu cầu phần mềm chi tiết 23 CHƯƠNG MƠ HÌNH V VÀ MƠ HÌNH PHỊNG SẠCH 3.1 Mơ hình V - Mơ hình V mơ hình SDLC việc thực thi quy trình diễn theo hình chữ V Nó cịn gọi mơ hình Xác minh thẩm định Mơ hình V phần mở rộng mơ hình thác nước dựa liên kết giai đoạn thử nghiệm cho giai đoạn phát triển tương ứng Điều có nghĩa giai đoạn chu kỳ phát triển, có giai đoạn thử nghiệm liên kết trực tiếp Đây mơ hình có tính kỷ luật cao giai đoạn bắt đầu sau hoàn thành giai đoạn trước - Theo V-Model, giai đoạn thử nghiệm tương ứng giai đoạn phát triển lên kế hoạch song song Vì vậy, có giai đoạn Xác minh bên giai đoạn 'V' xác thực phía bên Giai đoạn mã hóa tham gia vào hai mặt VModel Hình minh họa sau mơ tả giai đoạn khác Mơ hình V SDLC 24 3.2 Các giai đoạn xác minh - Phân tích yêu cầu kinh doanh Đây giai đoạn chu kỳ phát triển mà yêu cầu sản phẩm hiểu theo quan điểm khách hàng Giai đoạn liên quan đến việc trao đổi chi tiết với khách hàng để hiểu mong đợi yêu cầu xác họ Đây hoạt động quan trọng cần quản lý tốt, hầu hết khách hàng khơng chắn họ cần xác Việc lập kế hoạch thiết kế kiểm tra chấp nhận thực giai đoạn u cầu nghiệp vụ sử dụng làm đầu vào cho kiểm tra chấp nhận - Thiết kế hệ thống Khi bạn có yêu cầu sản phẩm rõ ràng chi tiết, đến lúc thiết kế hệ thống hoàn chỉnh Thiết kế hệ thống có hiểu biết chi tiết hóa thiết lập phần cứng giao tiếp hoàn chỉnh cho sản phẩm phát triển Kế hoạch kiểm tra hệ thống phát triển dựa thiết kế hệ thống Thực điều giai đoạn sớm để lại nhiều thời gian cho việc thực thi thử nghiệm thực tế sau - Thiết kế kiến trúc • Thơng số kỹ thuật kiến trúc hiểu thiết kế giai đoạn Thông thường, nhiều cách tiếp cận kỹ thuật đề xuất dựa tính khả thi kỹ thuật tài chính, định cuối đưa Thiết kế hệ thống chia nhỏ thành mô-đun đảm nhận chức khác Đây gọi Thiết kế Cấp cao (HLD) • Việc truyền liệu giao tiếp mô-đun bên với giới bên (các hệ thống khác) hiểu xác định rõ ràng giai 25 đoạn Với thông tin này, kiểm tra tích hợp thiết kế lập thành văn giai đoạn - Thiết kế module Trong giai đoạn này, thiết kế nội chi tiết cho tất mô-đun hệ thống định, gọi Thiết kế mức thấp (LLD) Điều quan trọng thiết kế phải tương thích với mô-đun khác kiến trúc hệ thống hệ thống bên khác Các kiểm tra đơn vị phần thiết yếu trình phát triển giúp loại bỏ tối đa lỗi sai sót giai đoạn sớm Các kiểm tra đơn vị thiết kế giai đoạn dựa thiết kế mơ-đun bên - Giai đoạn mã hóa • Mã hóa thực tế mơ-đun hệ thống thiết kế giai đoạn thiết kế thực giai đoạn Mã hóa Ngơn ngữ lập trình phù hợp định dựa yêu cầu hệ thống kiến trúc • Việc mã hóa thực dựa hướng dẫn tiêu chuẩn mã hóa Mã trải qua nhiều lần đánh giá mã tối ưu hóa để có hiệu suất tốt trước dựng cuối đưa vào kho lưu trữ 3.3 Giai đoạn thẩm định  Kiểm tra đơn vị • Các kiểm tra đơn vị thiết kế giai đoạn thiết kế mô-đun thực thi mã giai đoạn thẩm định Kiểm thử đơn vị kiểm tra cấp mã giúp loại bỏ lỗi giai đoạn đầu, phát tất lỗi kiểm thử đơn vị Kiểm thử tích hợp 26 • Các Kế hoạch Kiểm tra Tích hợp phát triển Giai đoạn Thiết kế Kiến trúc Các kiểm tra xác minh nhóm tạo kiểm tra độc lập tồn giao tiếp với Kiểm thử hệ thống Kiểm thử hệ thống liên kết trực tiếp với giai đoạn thiết kế hệ thống Kiểm tra hệ thống kiểm tra toàn chức hệ thống giao tiếp hệ thống phát triển với hệ thống bên Hầu hết vấn đề tương thích phần mềm phần cứng phát trình thực kiểm tra hệ thống Kiểm thử chấp nhận Thử nghiệm chấp nhận liên kết với giai đoạn phân tích yêu cầu kinh doanh liên quan đến việc thử nghiệm sản phẩm môi trường người dùng Kiểm tra chấp nhận phát vấn đề tương thích với hệ thống khác có sẵn mơi trường người dùng Nó phát vấn đề phi chức lỗi tải hiệu suất môi trường người dùng thực tế 3.3 Ứng dụng mơ hình V V- Ứng dụng mơ hình gần giống mơ hình thác nước, hai mơ hình thuộc loại Các yêu cầu phải rõ ràng trước dự án bắt đầu, việc quay lại thực thay đổi thường tốn Mơ hình sử dụng lĩnh vực phát triển y tế, lĩnh vực có tính kỷ luật nghiêm ngặt - Các trường hợp cần sử dụng mơ hình V • Các u cầu xác định rõ ràng, ghi chép rõ ràng cố định • Định nghĩa sản phẩm ổn định • Cơng nghệ khơng động nhóm dự án hiểu rõ 27 • Khơng có u cầu mơ hồ khơng xác định • Dự án ngắn hạn 3.4 Ưu nhược điểm mơ hình V 3.4.1 Ưu điểm Ưu điểm phương pháp V-Model dễ hiểu dễ áp dụng Sự đơn giản mơ hình giúp bạn dễ dàng quản lý Điểm bất lợi mơ hình khơng linh hoạt để thay đổi trường hợp có yêu cầu thay đổi, điều phổ biến giới động ngày nay, việc thực thay đổi trở nên tốn Các ưu điểm phương pháp V-Model sau: • Đây mơ hình có tính kỷ luật cao giai đoạn hồn thành lúc • Hoạt động tốt cho dự án nhỏ hơn, nơi yêu cầu hiểu rõ • Đơn giản dễ hiểu sử dụng • Dễ dàng quản lý độ cứng mơ hình Mỗi giai đoạn có phân phối cụ thể quy trình xem xét 3.4.2 Nhược điểm • Rủi ro cao khơng chắn • Khơng phải mơ hình tốt cho dự án phức tạp hướng đối tượng • Mơ hình cho dự án dài diễn • Không phù hợp với dự án mà u cầu có nguy thay đổi từ trung bình đến cao 28 • Khi ứng dụng giai đoạn thử nghiệm, khó để quay lại thay đổi chức • Khơng có phần mềm hoạt động sản xuất cuối vịng đời 3.5 Mơ hình phần mềm phịng (Cleanroom) - Đây cách tiếp cận kỹ thuật sử dụng để xây dựng tính đắn phần mềm phát triển - Khái niệm đằng sau kỹ thuật phần mềm phòng loại bỏ phụ thuộc vào quy trình tốn - Kỹ thuật phần mềm phòng bao gồm cách tiếp cận chất lượng việc viết mã từ đầu hệ thống cuối tập hợp lại thành hệ thống hoàn chỉnh 3.5.1 Các nhiệm vụ sau xảy kỹ thuật phòng sạch: Lập kế hoạch gia tăng • Trong nhiệm vụ này, kế hoạch gia tăng phát triển • Chức gia số, kích thước dự kiến gia số lịch trình phát triển phịng tạo • Cần ý phần tăng thêm chứng nhận tích hợp thời gian thích hợp theo kế hoạch Thu thập yêu cầu 29 • Việc thu thập yêu cầu thực kỹ thuật truyền thống phân tích, thiết kế, viết mã, kiểm tra gỡ lỗi • Mơ tả chi tiết u cầu cấp độ khách hàng phát triển Đặc điểm kỹ thuật cấu trúc hộp • Phương pháp đặc tả sử dụng cấu trúc hộp • Cấu trúc hộp sử dụng để mô tả đặc điểm kỹ thuật chức • Cấu trúc hộp phân tách lập hành vi, liệu thủ tục gia số Thiết kế trang trọng • Thiết kế phịng đặc điểm kỹ thuật tự nhiên cách sử dụng phương pháp tiếp cận cấu trúc hộp đen • Đặc điểm kỹ thuật gọi hộp trạng thái biểu đồ mức thành phần gọi hộp rõ ràng Xác minh tính đắn • Phịng tiến hành hoạt động xác minh tính đắn xác thiết kế sau mã • Việc xác minh bắt đầu với cấu trúc hộp kiểm tra mức cao sau chuyển sang chi tiết thiết kế mã • Mức độ diễn cách áp dụng 'câu hỏi sửa chữa' • Các phương pháp tốn học hình thức khác sử dụng để xác minh tính khơng có nghĩa thông số kỹ thuật Tạo mã, kiểm tra xác minh • Đặc tả cấu trúc hộp biểu diễn ngôn ngữ chuyên biệt chúng dịch sang ngơn ngữ lập trình thích hợp • Sử dụng đánh giá kỹ thuật để biết tính cú pháp mã Lập kế hoạch kiểm tra tĩnh • Phân tích, lập kế hoạch thiết kế công dụng dự kiến phần mềm • Hoạt động phịng tổ chức song song với đặc điểm kỹ thuật, xác minh tạo mã Kiểm tra sử dụng thống kê 30 • Việc kiểm tra tồn diện phần mềm máy tính Bắt buộc phải thiết kế số lượng trường hợp thử nghiệm giới hạn • Kỹ thuật sử dụng thống kê thực tập hợp thử nghiệm bắt nguồn từ mẫu thống kê tất lần thực thi chương trình có • Những mẫu thu thập từ người dùng từ nhóm đối tượng nhắm mục tiêu Chứng nhận • Sau xác minh, kiểm tra sửa chữa tất lỗi, phần gia tăng chứng nhận sẵn sàng để tích hợp 3.5.2 Mơ hình quy trình phịng • Cách tiếp cận mơ hình hóa kỹ thuật phần mềm phịng sử dụng phương pháp gọi đặc tả cấu trúc hộp • Một 'hộp' chứa hệ thống khía cạnh hệ thống cách chi tiết • Thông tin đặc điểm kỹ thuật hộp đủ để xác định tinh chỉnh mà không phụ thuộc vào việc triển khai hộp khác Mơ hình quy trình phịng sử dụng ba loại hộp sau: Hộp đen • Hộp đen xác định hành vi hệ thống • Hệ thống phản ứng với kiện cụ thể cách áp dụng tập hợp quy tắc chuyển đổi Hộp trạng thái • Hộp bao gồm liệu trạng thái hoạt động tương tự đối tượng • Hộp trạng thái đại diện cho lịch sử hộp đen tức liệu chứa hộp trạng thái phải trì tất q trình chuyển đổi Hộp rõ ràng • Chức chuyển tiếp sử dụng hộp trạng thái xác định hộp rõ ràng 31 • Nó đơn giản nói hộp rõ ràng bao gồm thiết kế thủ tục cho hộp trạng thái 32 Tài liệu tham khảo https://labs.flinters.vn/sqa/su-khac-nhau-giua-xac-minh-va-xac-nhantrong-kiem-thu-phan-mem/ https://viblo.asia/p/tong-quan-ve-dam-bao-chat-luong-phan-memal5XRBbLRqPe https://viblo.asia/p/mo-hinh-phat-trien-phan-mem-v-la-gi07LKXwAr5V4 https://quantrimang.com/ky-thuat-clean-room-la-gi-165050 33 ... quan đảm bảo chất lượng phần mềm Chương : Xác minh Thẩm định Chương : Mơ hình V Cleanroom CHƯƠNG TỔNG QUAN VỀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 1.1 Chất lượng phần mềm đảm bảo chất lượng phần mềm a Định. .. nâng cao hiệu phát triển phần mềm hoạt động SQA 13 CHƯƠNG XÁC MINH VÀ THẨM ĐỊNH TRONG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM 2.1 Khái niệm xác minh thẩm định 2.1.1 Xác minh ? • Xác minh trình đánh giá sản... sánh Xác minh kiểm tra Thẩm định quy trình xác minh đến trước thẩm định quy trình thẩm định diễn sau xác minh - Biểu đồ so sánh Xác minh (Verification) Thẩm định (Validation)  Quá trình xác minh