Nguyễn Xuân Huy Giáo trình KIỂM ĐỊNH PHẦN MỀM Mục lục Lời nói đầu Chương Nhập đề 1.1 Sản phẩm phần mềm 1.2 Các thành phần sản phẩm phần mềm 1.3 Các tiêu chí chất lượng sản phẩm phần mềm 1.4 Một số khái niệm khác 13 1.5 Mô hình phát triển phần mềm 14 1.6 Qui trình phát triển phần mềm 15 Chương Lỗi sản phẩm phần mềm 18 2.1 Thế lỗi phần mềm? 18 2.2 Tại lỗi phần mềm xuất hiện? 19 2.3 Chi phí sửa lỗi 22 Chương Kiểm định phần mềm 24 3.1 Khái niệm chung 24 3.2 Hai vấn đề trọng tâm: K&K 27 3.3 Qui trình kiểm định phần mềm 30 3.4 Tính không đầy đủ kiểm định 36 3.5 Thanh sát (inspection) kiểm điểm (review) 40 3.6 Test tự động 42 Chương Kiểm định phát triển 47 4.1 Kiểm định đơn vị 48 4.1.1 Định nghĩa 48 4.1.2 Các yêu cầu kiểm định đơn vị 49 4.1.3 Sinh trường hợp test cho kiểm định đơn vị 51 4.2 Kiểm định cấu phần 54 4.3 Kiểm định hệ thống 60 Chương Phát triển theo kiểm định săn đuổi 65 5.1 Qui trình 65 5.2 Lợi ích 66 5.3 Kết luận 68 Chương Kiểm định thực tế 70 6.1 Khái niệm chung 70 6.2 Kiểm định dựa yêu cầu 71 6.3 Thiết kế test theo kịch 72 6.4 Kiểm định hiệu 73 Chương Kiểm định khách hàng 76 7.1 Khái niệm chung 76 7.2 Kiểm định alpha 80 7.3 Kiểm định beta 80 7.4 Kiểm định chấp thuận 81 Thảo luận 85 TÀI LIỆU THAM KHẢO 179 Phụ lục Ghi nhớ 181 Phụ lục Tổng quan kĩ nghệ phần mềm 183 Phụ lục Thuật ngữ 209 Lời nói đầu Giáo trình giới thiệu số kiến thức kiểm định phần mềm, nhánh quan trọng thuộc lĩnh vực công nghệ phần mềm Kể từ năm sáu mươi kỉ 20, công nghệ phần mềm hình thành nguyên lí khoa học phát triển ngày mạnh mẽ Có thể hiểu công nghệ phần mềm lĩnh vực công nghệ thông tin nhằm nghiên cứu đề xuất nguyên lí, qui trình công nghệ, phương pháp, công cụ trợ giúp trình thiết kế, cài đặt bảo trì sản phẩm phần mềm đáp ứng tiêu chất lượng: tính đúng, tính khoa học, tính tin cậy, tính vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển hoàn thiện Kiểm định phần mềm nhánh công nghệ phần mềm có nhiệm vụ kiểm tra xác minh tiêu chí chất lượng nói Theo nghĩa hẹp, kiểm định phần mềm tập trung chủ yếu vào việc kiểm tra tính phần mềm Tính phần mềm hiểu phần mềm thực thi đắn xác yêu cầu người thiết kế mô tả thiết kế Các yêu cầu hình thành sở trao đổi thống nhóm phát triển phần mềm với khách hàng Khoảng năm sáu mươi kỉ 20 bùng nổ tranh luận toán tử đầy nghi vấn – toán tử GOTO ngôn ngữ lập trình Chính tranh luận làm nảy sinh ý tưởng nguyên lí công nghệ phần mềm Điều thú vị là, từ ngày đầu sơ khởi chập chững công nghệ phần mềm, phương pháp hình thức đời phát triển nhanh chóng Hàng loạt công trình nghiên cứu có ý nghĩa nhà tin học đầu đàn Dijkstra, Dahl, Hoare, Boehm nâng kĩ thuật lập trình lên tầm cao, mang tính chặt chẽ hoàn thiện, gần với ngành khoa học xác (Dijkstra, Dahl, and Hoare, 1972) Dahl Lời nói đầu _ Dijkstra đề xuất nguyên lý lập trình theo đặc tả hình thức, Hoare xây dựng hệ tiên đề chứng minh tính chương trình thông qua phương pháp toán học suy luận logic, Boehm Dijkstra chứng minh tính đủ hai cấu trúc điều khiển lặp while, sở đề xuất khái niệm D-cấu trúc với lời khuyên lập trình viên nên sử dụng ba cấu trúc điều khiển cách sáng tao nhã cấu trúc tuần tự, cấu trúc rẽ nhánh cấu trúc lặp điều kiện trước (Boehm, 1979) Do nhu cầu thị trường, hệ thống phần mềm phức tạp ngày tăng trưởng Cùng với nó, hoạt động kiểm định ngày gánh trách nhiệm thêm nặng nề chuyên nghiệp Nếu trước đây, lập trình viên thường đảm đương nhiệm vụ kiểm định đoạn mã viết ngày nay, việc không thể, chưa nói đến khả không khuyến khích Các phương pháp kiểm định hình thành phát triển đa dạng Có thể nói, ngày nay, mô hình phát triển phần mềm định vài qui trình sản xuất phần mềm Đến lượt mình, qui trình sản xuất phần mềm lại định vài qui trình kiểm định hiệu tương ứng Giáo trình đặt hai mục tiêu sau đây: Giới thiệu khái quát qui trình phương pháp kiểm định phần mềm, sâu vào phương pháp tiên tiến có hiệu theo nghĩa phương pháp kiểm chứng thực tế; Định hướng cho học viên số kĩ trợ giúp tổ chức đạo nhóm kiểm định phần mềm sở làm phần mềm Nội dung giáo trình tương đương với học phần khoảng 60 tiết Giáo trình kiến trúc sau: Chương giới thiệu số khái niệm sở công nghệ phần mềm với giả định bạn đọc biết nhiều sản phẩm phần mềm tiêu chí đánh giá sản phẩm phần mềm, mô hình qui trình phát triển phần mềm Nội dung chương dành cho thảo luận lỗi phần mềm, phân tích chủ yếu dạng lỗi tiềm ẩn phần mềm nguyên nhân sinh lỗi Chương trình bày qui trình tổ chức thực thi hoạt động kiểm định phần mềm Lời nói đầu _ Các chương giáo trình, từ chương đến chương giới thiệu nhóm phương pháp kiểm định phần mềm: kiểm định phát triển, kiểm định thực tế kiểm định người sử dụng Trước biên soạn giáo trình này, người viết tiếp thu nhiều kiến thức bổ ích nội dung công nghệ phần mềm phương pháp luận truyền thụ từ giáo sư John Vũ, kĩ sư trưởng Công nghệ thông tin hãng Boeing, giáo sư kiêm nhiệm Viện nghiên cứu phần mềm Đại học Carnegie Mellon (CMU) giáo sư Anthony Lattanze, CMU Tiến sĩ John Kang, chủ nhiệm Khoa Quốc tế CMU thày Lê Công Cơ, Q hiệu trưởng trường Đại học Duy Tân Đà Nẵng cấp kinh phí tạo nhiều điều kiện thuận lợi cho người viết thăm tham gia khoá đào tạo công nghệ phần mềm CMU PGS TS Đoàn Văn Ban, PGS TS Đặng Văn Đức, Nghiên cứu viên Ngô Trung Việt, Viện Công nghệ thông tin, Viện Khoa học Công nghệ Việt Nam, TS Hồ Cẩm Hà, trưởng khoa Công nghệ thông tin Đại học Sư phạm Hà Nội thường xuyên trao đổi cung cấp thông tin cho người viết vấn đề đương đại công nghệ phần mềm Trong thời gian biên soạn giáo trình này, thạc sĩ Lê Thị Mỹ Hạnh, Khoa Công nghệ thông tin trường Đại học Bách khoa, Đại học Đà Nẵng cung cấp số hình vẽ trợ giúp soạn thảo trình bày văn Người viết chân thành cảm ơn hỗ trợ quí báu chân tình thày đồng nghiệp Người viết mong nhận ý kiến bình luận đánh giá bạn đọc gửi theo địa sau đây: Nguyễn Xuân Huy, Chủ tịch Hội đồng tư vấn Giáo dục Microsoft, MB: 0903203800, E-mail: nxhuy564@gmail.com Hà Nội, ngày Giỗ Tổ, 10 tháng Ba năm Nhâm Thìn N X Huy Chương Nhập đề Chương nhắc lại số khái niệm để chuẩn bị cho việc tiếp thu khái niệm kiểm định phần mềm khái niệm trọng tâm giáo trình: Nội dung 1.1 Sản phẩm phần mềm 1.2 Các thành phần sản phẩm phần mềm 1.3 Các tiêu chí chất lượng sản phẩm phần mềm 1.4 Một số khái niệm khác 1.5 Mô hình phát triển phần mềm 1.6 Qui trình phát triển phần mềm 1.1 Sản phẩm phần mềm Phần mềm (bộ) chương trình cài đặt máy tính thực nhiệm vụ tương đối độc lập nhằm phục vụ cho nhiều ứng dụng cụ thể: quản lý họat động máy tính áp dụng máy tính họat động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,… Thí dụ S1 Hệ điều hành Ubutu; S2 Môi trường lập trình C++ Devcpp; S3 Hệ thông tin quản lí: CN2; Chương Nhập đề _ S4 Game: Lines; … 1.2 Các thành phần sản phẩm phần mềm Theo quan điểm hệ thống, sản phẩm phần mềm xem hệ thống bao gồm nhiều phân hệ Mỗi phân hệ lại xây dựng từ cấu phần Mỗi cấu phần bao gồm đơn vị nhỏ Các thành phần phần mềm liên kết với thông qua mối quan hệ tương tác Thí dụ Một hệ thống thông tin bao gồm phân hệ sau đây: Phân hệ quản lí nhân sự, phân hệ quản lí sản phẩm, phân hệ quản lí tài (kế toán – tài vụ), phân hệ quản lí hành chính, phân hệ tiếp thị,… Các phân hệ xây dựng từ cấu phần sau: Cấu phần quản lí liệu, cấu phần quản lí lưu trữ, cấu phần quản lí mạng,… Mỗi cấu phần lại tổ hợp từ đơn vị, lớp (class - theo tiếp cận hướng đối tượng), thư viện chương trình, đơn thể (module), chẳng hạn: Lớp cửa sổ hình, lớp thực đơn, thư viện hàm số học, … Trong tài liệu thuật ngữ sau hiểu tương đương ngữ nghĩa: Hệ thống, Phần mềm, Hệ thống phần mềm, Sản phẩm phần mềm; Chương trình (bộ chương trình) Các thuật ngữ cấu phần, đơn thể, đơn vị, chi tiết hệ thống (phần mềm) hiểu theo nghĩa tương đối, phân định rõ ràng Chương Nhập đề _ Khi cần thiết, trường hợp cụ thể, ngữ nghĩa khái niệm làm rõ văn cảnh Đặc tả sản phẩm Duyệt lại sản phẩm Phản hồi từ phiên cũ Tài liệu thiết kế Thông tin cạnh tranh Kiến trúc phần mềm Tài liệu kiểm định Khảo sát khách hàng Lịch biểu Dữ liệu Mã nguồn Sản phẩm cuối Bộ cài, Module trợ giúp, Hướng dẫn khử lỗi, Bẫy lỗi, Thực đơn, Biểu tượng, Âm thanh, Hướng dẫn sử dụng, Nâng cấp, Cập nhật, Trợ giúp sản phẩm… phẩm…ProductSupport Information, … Hình 1.1 Sản phẩm phần mềm Với số phần mềm đơn giản, thí dụ tập lập trình, kiểm định không đặt nhiều vấn đề gay cấn Vì lí đó, nguyên lí, mô hình kĩ thuật kiểm định định hướng chủ yếu đến hệ thống phần mềm bao gồm nhiều cấu phần có quan hệ hữu với 1.3 Các tiêu chí chất lượng sản phẩm phần mềm Dưới liệt kê phân tích vắn tắt số tiêu chí xác định chất lượng sản phẩm phần mềm (Huy, 1996): Chương Nhập đề _ TC1 Tính Tính sản phẩm phần mềm hiểu sản phẩm phần mềm thực thi đầy đủ xác yêu cầu đặc tả thiết kế Thí dụ Trong thiết kế đặc tả phần mềm S xếp mảng có tối đa 10000 phần tử tình sau coi sai: - Phần mềm S không mảng rỗng mảng không chứa phần tử nào; - Phần mềm S không mảng có 10000 phần tử; - Phần mềm S tăng, không giảm; - Phần mềm S gây lỗi ta yêu cầu (lại) mảng sắp; - Phần mềm S không thực thi với mảng có phần tử giống TC2 Tính khoa học Giao diện thiết kế hợp lý, gần với tư kì vọng tự nhiên người sử dụng; chức đặt khoa học, thể logic hệ thống; di chuyển vị trí, thay đổi kích thước, màu sắc giao diện, kiểu văn bản, hình vẽ, đồ thị, bảng biếu… Thí dụ Phần mềm dạy học P dùng cho học sinh tiểu học hiển thị dòng thông báo, thực đơn trợ giúp với cỡ chữ xem vi phạm vệ sinh học đường Phần mềm đặt màu sắc ngẫu hứng nên gây phản cảm người sử dụng: họ tên học sinh ghi màu đỏ, điểm – màu vàng, nhận xét giáo viên – màu tím Phần mềm S cung cấp hai lệnh có chức tương tự cú pháp khác nhau, chẳng hạn: asc(a, n) – tăng mảng a gồm n phần tử; dec(n, a) – giảm mảng a gồm n phần tử 10 Phụ lục Tổng quan kĩ nghệ phần mềm _ kịp với thay đổi thực tế Do bước dần trở thành quan trọng có ánh hưởng nhiều tới cách tiếp cận giải vấn đề Việc xây dựng hệ thống lần khác xa với việc xây dựng hệ thống để hoạt động lâu dài hữu ích Chúng ta thấy để giải vấn đề thực tế cần phải tiến hành theo trình tự đây, vấn đề lập trình hay rộng hơn, vấn đề mô thực tế máy tính Điều đưa tới việc cần xem xét kĩ vấn đề có liên quan tới không gian vấn đề, không gian toán, không gian giải pháp bước chuyển từ không gian vấn đề sang không gian giải pháp, tức việc giải vấn đề Trên sở xem xét qui mô lớn mà thấy rõ vấn đề phương pháp luận Vấn đề, giải pháp giải vấn đề Các tổ chức tạo chuyển giao sản phẩm dịch vụ để đáp ứng cho nhu cầu đòi hỏi khách hàng Các yêu cầu đặc trưng vấn đề hay toán Sản phẩm dịch vụ giải cho yêu cầu đặc trưng giải pháp Để chuyển giao giải pháp có giá trị (chất lượng tối đa với chi phí tối thiểu phạm vi thời gian tối thiểu), tổ chức phải nắm bắt (thu nhận), trao đổi (dùng chung), sử dụng tri thức Giá trị giải pháp xác định phẩm chất sản phẩm hay dịch vụ, chi phí sản phẩm hay dịch vụ, thời gian cần để tạo sản phẩm hay cung cấp dịch vụ Các tổ chức giải vấn đề cho khách hàng mình, nhân viên giải vấn đề cho người chủ lao động, bác sĩ giải vấn đề cho bệnh nhân, vân vân Bên kiểu quan hệ này, tri thức nhân tố thành công chủ chốt Các tổ chức dùng công nghệ để phát tán trao đổi thông tin nhân viên giải vấn đề nghiệp vụ Công nghệ công cụ; người biết cách áp dụng thực hoá tiềm nó, vô dụng Bởi giới nghiệp vụ giới công nghệ luồng biến đồi thường hằng, nên yêu cầu phải quản lí độ phức tạp tăng lên bên nỗ lực tiếp diễn Tuy nhiên, không nên quên công nghệ phương tiện cho mục đích thân mục đích Để thực việc giải vấn đề, khách hàng người cung cấp giải pháp cần có số văn pháp lí ràng buộc, dạng dự án hợp đồng Dự án nỗ lực giải vấn đề Chúng bao gồm việc hiểu hay quan niệm vấn đề, giải vấn đề, thực hay thực giải pháp 197 Phụ lục Tổng quan kĩ nghệ phần mềm _ Các thực thể người hay tổ chức tham gia vào dự án biết tới người tham dự Một số người tham dự người mà vấn đề giải cho Họ chịu trách nhiệm đóng góp tri thức để hiểu vấn đề kiểm chứng lại giải pháp Những người tham dự khác chịu trách nhiệm đóng góp tri thức để thực giải pháp Kết dự án biết tới việc chuyển giao sản phẩm làm việc Chúng sản phẩm hay dịch vụ giải cho vấn đề Ta xét tổ chức gặp khó khăn việc phân bổ tối ưu nhân viên cho dự án khác Tổ chức muốn có hệ thông tin để trì thông tin nhân viên dự án Giải pháp phải cung cấp khả để phân bổ nhân viên cho dự án dựa kĩ họ nơi họ sử dụng tốt Trong giải vấn đề này, cách tiếp cận tổng thể phải đề cập tới cách hiểu quan niệm vấn đề, suy diễn giải pháp cho vấn đề, thực hay thực hoá giải pháp Cách tiếp cận xác định cách xem xét vấn đề (mô thức) với mục đích để hiểu Chúng ta áp dụng tri thức tình qui tắc khác (trực cảm) thu từ kinh nghiệm khác để suy diễn giải pháp (thông qua vật phẩm) Nỗ lực tổ chức (vòng đời) chuỗi bước (hoạt động) (có thể tương tranh) quản lí để phát triển sản phẩm có kết Vấn đề xuất bên khung cảnh (miền hay không gian) nghiệp vụ Giải pháp phải thực để khớp với bên kết cấu (miền hay không gian) công nghệ thông tin tổ chức Vấn đề (hệ thống) nghiệp vụ phải hoàn toàn hiểu rõ dạng yêu cầu nghiệp vụ, sản phẩm hay hệ thông tin phải hiểu đầy đủ dạng cách thức đáp ứng cho yêu cầu Hệ thông tin kết hay sản phẩm phần mềm phải tổ chức (kiến trúc) để khớp vào kết cấu công nghệ tổ chức Khi quan niệm vấn đề làm việc hướng tới việc thực giải pháp nắm tri thức (mô hình) vấn đề nghiệp vụ hệ thông tin, định (góc nhìn kiến trúc) cách đề cập tới vấn đề khác nhau, nên có khả mô tả trao đổi thông tin (các biểu đồ) Phương pháp xác định cách tiến hành nỗ lực giải vấn đề Chúng xác định cách tiếp cận giải vấn đề cấu phần Chúng xác định cách vấn đề giải pháp xem xét mối quan hệ với cách tiếp cận giải vấn đề; điều biết khía cạnh mô tả phương pháp mô tả cho cách thức tri thức nắm bắt trao đổi vấn đề giải pháp Các phương pháp xác định cách tiếp cận 198 Phụ lục Tổng quan kĩ nghệ phần mềm _ giải vấn đề dùng để giải vấn đề suy dẫn giải pháp; điều biết tới khía cạnh qui tắc phương pháp mô tả cho cách thức tri thức bẩy để giải vấn đề Phương pháp xác định mặt mô tả cách thức vấn đề giải pháp xem xét, xác định mặt qui tắc cách thức nỗ lực giải vấn đề thực tế hoá Tiến trình việc thực phương pháp Chúng dùng cách tiếp cận giải vấn đề phương pháp để giải vấn đề thực giải pháp Các tiến trình xác định phương pháp; điều biết khía cạnh tĩnh tiến trình mô tả cách vấn đề giải Các tiến trình áp dụng phương pháp bên dự án để giải vấn đề; điều biết khía cạnh động tiến trình Vì dự án phức tạp nên phương pháp nên dùng để cung cấp kết cấu cho tiến trình giải vấn đề Chúng nên xem xét gợi ý khuyến cáo tổ chức tạo điều kiện cho tiến trình giải vấn đề xem xét qui tắc không linh động cứng nhắc, hạn chế nghệ thuật giải vấn đề Phương pháp luận việc phân loại, hay tuyển tập có tổ chức tốt phương pháp có liên quan; đó, phương pháp phần phương pháp luận Vấn đề thường nói tới tình chúng biểu diễn cho điều kiện tại; giải pháp tương tự nói tới tình chúng biểu thị cho điều kiện đích mà cố gắng đạt tới, xem Hình 1.1 199 Phụ lục Tổng quan kĩ nghệ phần mềm _ Mô tả Thông minh Quan niệm Giải Vấn đề Vấn đề Các yêu cầu vấn đề áp đặt lên giải pháp Thực Giải pháp Tri thức Thu nhận Trao đổi Sử dụng Đặc tả giải pháp thoả mãn cho yêu cầu Qui tắc Hình 1.1 Góc nhìn chung giải vấn đề Một tình không gây khó khăn xử lí vấn đề để hiểu nó; nhiên, giải pháp lại không khác việc hiểu tình Điều phát sinh việc xác định đặc trưng, thay yêu cầu, tình cung cấp góc nhìn mô tả khiết tình mà góc nhìn mô tả hay qui tắc giải pháp Điều thường tiến hành giải pháp cho vấn đề tồn tại, giải pháp có cần hiểu hay đánh giá Việc giải vấn đề (Hình 1.2) bao gồm nỗ lực hay tiến trình hợp tác giải vấn đề Những nỗ lực bao gồm điều sau:  Quan niệm biểu diễn vấn đề dạng dễ uốn nắn trao đổi Điều cho phép vấn đề biểu diễn ngôn ngữ thao tác trao đổi với người khác  Xác định yêu cầu vấn đề áp đặt lên giải pháp nó, tức là, yêu cầu gây vấn đề mà giải pháp phải thoả mãn  Đạt tới mô tả vấn đề việc nhắm tới câu hỏi sau: Vấn đề gì? Các yêu cầu vấn đề mà giải pháp phải thoả mãn gì? 200 Phụ lục Tổng quan kĩ nghệ phần mềm _ Trong dự án, vấn đề trả lời tối thiểu với đủ mức chi tiết, nỗ lực đạt tới góc nhìn mô tả vấn đề  Nhận diện hay xác định giải pháp thoả mãn yêu cầu vấn đề áp đặt  Đạt tới mô tả giải pháp việc nhắm tới câu hỏi sau: Giải pháp gì? Đặc tả cho giải pháp thoả mãn yêu cầu vấn đề áp đặt gì? Bên dự án, vấn đề trả lời tối thiểu với đủ mức chi tiết, nỗ lực đạt tới góc nhìn mô tả giải pháp Mô tả Giải vấn đề ®Ò Yêu cầu Đặc tả Giải pháp Vấn đề Vấn đề Vấn đề Vấn đề Vấn đề Giải pháp Giải pháp Giải pháp Giải pháp Thu gọn (Phân tích) Mở rộng (Hợp thành) Qui tắc Hình 1.2 Góc nhìn chi tiết giải vấn đề Nếu giải pháp định cho vấn đề, yêu cầu vấn đề ấn định lên giải pháp nhóm lại, phân loại, tổ chức thành vấn đề cấp dưới, giải tương tranh Một vấn đề cấp dẫn hay phân tách cách đệ qui thành vấn đề cấp Các vấn đề cấp giải tương tranh, giải pháp cho vấn đề nguyên thuỷ mở rộng hay hợp thành đệ qui từ giải pháp cấp Tiến trình dẫn tiếp tục giải pháp cho vấn đề nguyên thuỷ suy dẫn Bởi tiến trình đệ qui nên góc nhìn mô tả 201 Phụ lục Tổng quan kĩ nghệ phần mềm _ dùng để phát góc nhìn qui tắc Hơn nữa, việc phân tách cho phép nhiều việc giải vấn đề song song tương tranh toàn tiến trình giải Việc giải vấn đề tiếp tục sau:  Đạt tới việc qui định bước bên giải pháp giải cho vấn đề việc đề cập tới câu hỏi sau: giải pháp có yêu cầu riêng (hay vấn đề phụ thuộc) thoả mãn nào? Trong phạm vi dự án, câu hỏi trả lời cách tối thiểu với đủ mức chi tiết cần thiết, nỗ lực đạt tới góc nhìn qui tắc giải pháp  Thực việc biểu diễn cho giải pháp dạng cụ thể dùng Tri thức cấu phần chèn lấp lên cần phải thâu tóm (thu nhận), truyền trao (dùng chung), làm đòn bẩy (sử dụng) để tạo điều kiện thuận tiện cho tiến trình Toàn tri thức bao gồm nỗ lực phân mảnh thành nhóm, với nhóm liên kết với phần nỗ lực (quan niệm, vấn đề, giải pháp, việc giải vấn đề hay thực hiện) điểm thời gian nêu Mối liên kết có ý nghĩa phần tử tri thức ảnh hưởng tới nỗ lực; tức phần tử tri thức thu nhận, dùng chung hay sử dụng bên nỗ lực giải vấn đề Thông minh khả tiến hành tiến trình giải vấn đề việc tổ chức tri thức phân loại áp dụng tri thức cách có chiến lược qua nỗ lực giải vấn đề để suy giải pháp Vòng đời Cách tiếp cận giải vấn đề tổ chức (theo vòng đời) để đưa viễn cảnh quản lí viễn cảnh phát triển Hai viễn cảnh làm cho nỗ lực phát triển hệ thống quản lí thực 202 Phụ lục Tổng quan kĩ nghệ phần mềm _ Vòng đời Giai đoạn tiến hoá Vòng lặp Giai đoạn quan niệm Pha lặp Giai đoạn dừng Pha phát triển Khởi đầu Lập kế hoạch Thực Kiểm soát Kết thúc Hình 1.3 Vòng đời Vòng đời (Hình 1.3) chia sau Vòng đời tuyển tập giai đoạn phân chia nỗ lực thành nhiều giai đoạn nỗ lực, quản lí kiểm soát Mỗi giai đoạn bên vòng đời phần rời rạc luồng logic để giải vấn đề Mỗi giai đoạn có vào, đòi hỏi áp dụng nguyên tắc, kĩ thuật công cụ lên vào để sinh ra; có tiêu chuẩn vào cho việc đưa vào hay khởi đầu giai đoạn; có tiêu chuẩn để hay kết thúc giai đoạn Điều làm nảy sinh việc kiểm điểm sản phẩm có đạt chất lượng không từ để định liệu có tiếp tục hay bỏ dở toàn nỗ lực Nhìn chung người ta phân ba giai đoạn: giai đoạn quan niệm, giai đoạn tiến hoá giai đoạn dừng Giai đoạn quan niệm bao gồm việc nhận vấn đề hay hội cam kết giải vấn đề Giai đoạn tiến hoá bao gồm nhiều chu kì tiến hoá từ việc khởi đầu, lập kế hoạch, thực hiện, kiểm soát kết thúc nỗ lực Giai đoạn dừng bao gồm việc nhận giải pháp không yêu cầu kết thúc việc áp dụng giải pháp theo cách thức có trật tự 203 Phụ lục Tổng quan kĩ nghệ phần mềm _ Riêng giai đoạn tiến hoá, chu kì tiến hoá cụ thể là:  Khởi đầu bao gồm việc nhận chu kì tiến hoá cần việc đề cập tới vấn đề hay có  Lập kế hoạch bao gồm thiết kế trì xếp để thực việc giải vấn đề  Thực bao gồm việc phối hợp nguồn tài nguyên để tiến hành kế hoạch giải vấn đề  Kiểm soát bao gồm việc điều phối đo tiến trình cho biện pháp sửa đổi tiến hành cần  Kết thúc bao gồm việc thức hoá chấp nhận chu kì nghị cho vấn đề để theo chu kì sau khởi đầu Giai đoạn tiến hoá bao gồm hay nhiều chu kì phát triển (chu kì tiến hoá), nơi chu kì phát triển lại bao gồm nỗ lực phân phối cấu phần chu kì phát triển Nó bao gồm việc tiến hoá sản phẩm trưởng thành chín muồi qua tồn Chu kì pha phát triển Chu kì pha phát triển (xem Hình 1.4) có đặc trưng: Mỗi chu kì phát triển bao gồm bốn pha (khởi đầu, soạn thảo, xây dựng chuyển giao) làm phát sinh hệ sản phẩm Góc nhìn vòng đời thường gọi viễn cảnh quản lí cung cấp báo mức cao tiến độ dự án 204 Phụ lục Tổng quan kĩ nghệ phần mềm _ Quan niệm Vấn đề Khởi đầu Giải Vấn đề Soạn thảo Giải pháp Xây dựng Chu kì phát triển Thực Chuyển giao Thế hệ sản phẩm Hình 1.4 Các pha phát triển bên chu kì phát triển Pha phát triển khởi đầu thường dùng chu kì lặp bao gồm hoạt động sau: Xác định định phạm vi giới hạn, mục tiêu yêu cầu Thiết lập trường hợp hay luận nghiệp vụ, bao gồm việc xác định tầm nhìn, xác định tiêu chuẩn thành công, định giá rủi ro, ước lượng thời gian chi phí, xác định kế hoạch Hội tụ vào việc hiểu hay hình thành khái niệm vấn đề luận để giải (định phạm vi trường hợp nghiệp vụ) Pha phát triển soạn thảo (lập kế hoạch) thường dùng chu kì lặp bao gồm hoạt động sau: Soạn thảo đặc tả nỗ lực từ pha trước Lập vạch ranh giới phạm vi giới hạn đầy đủ, mục tiêu yêu cầu Lập vạch ranh giới trường hợp nghiệp vụ việc làm đông cứng góc nhìn, đông cứng tiêu chuẩn thành công, làm dịu bớt rủi ro cao Lập vạch ranh giới kế hoạch với lịch biểu Phân phối yêu cầu nhiều chu kì lặp bên pha xây dựng Hội tụ vào việc hiểu hay hình thành khái niệm vấn đề để xác định yêu cầu mà vấn đề áp đặt lên giải pháp cho (nắm bắt yêu cầu phân tích yêu cầu), thiết lập kiểm chứng tảng cho giải pháp toàn 205 Phụ lục Tổng quan kĩ nghệ phần mềm _ thể (thiết kế kiến trúc), phân phối yêu cầu chu kì lặp pha phát triển xây dựng (lập kế hoạch) Pha phát triển xây dựng (thực hiện) thường dùng nhiều chu kì lặp bao gồm hoạt động sau: Cập nhật trường hợp nghiệp vụ việc quản lí rủi ro xảy trì kế hoạch lịch biểu Xây dựng phát triển sản phẩm việc thực nhiều chu kì lặp Pha tập trung vào điều sau:  hiểu hay làm tiến hoá yêu cầu mà vấn đề áp đặt lên giải pháp (các yêu cầu) cho vấn đề soạn thảo giải pháp xác định,  soạn thảo đặc tả giải pháp (phân tích),  cập nhật tảng cho giải pháp toàn thể (thiết kế kiến trúc) tảng cần để hỗ trợ cho giải pháp đặc biệt (thiết kế chi tiết) yêu cầu chu kì lặp,  sinh giải pháp (cài đặt) cho yêu cầu chu kì lặp,  kiểm chứng giải pháp (làm hợp lệ tích hợp) theo yêu cầu chu kì lặp,  đưa hay tích hợp (hay chuyển giao) giải pháp (triển khai) hay tập Pha phát triển chuyển giao (đóng) thường dùng chu kì lặp bao gồm hoạt động sau: Triển khai sản phẩm cuối nỗ lực hay giải pháp cho vấn đề Định giá phân loại sản phẩm chuyển tiếp nỗ lực Tập trung vào việc cung cấp tích hợp hay chuyển giao giải pháp (triển khai) 206 Phụ lục Tổng quan kĩ nghệ phần mềm _ Chu kì pha lặp Chu kì pha lặp (hình 1.5) có đặc trưng sau: Quan niệm Giải Vấn đề Vấn đề Yêu cầu Phân tích Thiết kế Giải pháp Thực Kiểm chứng Thực Triển khai Cấu phần phát triển Quản lí Hỗ trợ Cấu phần hỗ trợ Chu kì phát triển Thế hệ sản phẩm Hình 1.5 : Tập trung vào pha lặp bên chu kì lặp  Mỗi chu kì lặp bao gồm hai cấu phần hỗ trợ (quản lí hỗ trợ) sáu cấu phần phát triển (yêu cầu, phân tích, thiết kế, thực hiện, làm hợp lệ triển khai) Nó làm phát sinh việc phát hành sản phầm Cách nhìn vòng đời thường gọi viễn cảnh phát triển đưa báo mức thấp tiến độ dự án  Pha quản lí (kiểm soát) bao gồm việc quản lí chu kì lặp tổng thể  Pha hỗ trợ (kiểm soát) bao gồm việc hỗ trợ cho nhu cầu yêu cầu người tham dự chu kì lặp; điều bao gồm hỗ trợ môi trường phát triển lập cấu hình, định nghĩa chuẩn, hướng dẫn  Bên pha phát triển soạn thảo (lập kế hoạch), pha lặp sau dùng tới: 207 Phụ lục Tổng quan kĩ nghệ phần mềm _ - Pha yêu cầu (nắm bắt yêu cầu) phân tích (phân tích yêu cầu) bao gồm việc hiểu hay hình thành khái niệm vấn đề để xác định yêu cầu giải pháp phân phối yêu cầu chu kì lặp pha phát triển xây dựng (lập kế hoạch) - Pha thiết kế (thiết kế kiến trúc) bao gồm việc thiết lập kiểm chứng tảng cho giải pháp toàn thể  Bên pha phát triển xây dựng (thực hiện) pha lặp sau áp dụng: - Pha yêu cầu bao gồm việc hiểu hay soạn thảo yêu cầu mà vấn đề áp đặt lên giải pháp cho vấn đề soạn thảo giải pháp xác định - Pha phân tích bao gồm việc soạn thảo đặc tả giải pháp Pha xoay quanh việc áp dụng tri thức - Pha thiết kế bao gồm việc cập nhật tảng cho giải pháp tổng thể (thiết kế kiến trúc) tảng cần để hỗ trợ cho giải pháp đặc thù (thiết kế chi tiết) cho yêu cầu chu kì lặp Pha xoay quanh việc áp dụng tri thức - Pha thực bao gồm việc sinh giải pháp cho yêu cầu chu kì lặp - Pha làm hợp lệ (và tích hợp) bao gồm việc kiểm chứng giải pháp yêu cầu chu kì lặp - Pha triển khai bao gồm việc cung cấp tích hợp hay chuyển giao giải pháp hay tập 208 Phụ lục Thuật ngữ acceptance advance agile application architecture behaviour case change class clean room client client–server complex component context database debugging decision dependability design development distributed system document driven dynamic engineering environment chấp nhận tăng, tiến, nâng cao linh lợi áp dụng kiến trúc hành vi trường hợp thay đổi, sửa đổi lớp phòng khách hàng khách - chủ phức hợp cấu phần ngữ cảnh, ngữ nghĩa sở liệu gỡ lỗi định tính tin cậy thiết kế phát triển hệ thống phân tán tài liệu, hồ sơ lái, săn đuổi động, động thái công nghệ, kĩ nghệ môi trường Phụ lục Thuật ngữ _ error evolution extreme formal language formal specification function guide implementation informal specification inspection interaction language management method mock object model natural language nature object object-oriented open open source pattern plan practical process professional program project property prototype quality real real-time lỗi tiến hoá, tiến triển cận, cực ngôn ngữ hình thức đặc tả hình thức chức năng, hàm hướng dẫn cài đặt, triển khai đặc tả phi hình thức sát lặp ngôn ngữ quản lí, quản trị phương pháp đối tượng nhép mô hình ngôn ngữ tự nhiên tự nhiên đối tượng hướng đối tượng mở mã nguồn mở mẫu kế hoạch thực tế qui trình chuyên nghiệp chương trình dự án tính chất (khai báo) mẫu chất lượng thực thời gian thực 210 Phụ lục Thuật ngữ _ release testing requirement reuse review risk scala scenario schema side effect software software engineering source specification stakeholder static structure system technique technology test case test, testing test-driven development tools UML (Unified Modeling Language) UML Design unit user user testing validation verification view kiểm định thực tế yêu cầu tái sử dụng kiểm điểm cố thang, độ kịch sơ đồ, lược đồ hiệu ứng phụ phần mềm công nghệ (kĩ nghệ) phần mềm nguồn đặc tả người có thẩm quyền tĩnh cấu trúc hệ thống kĩ thuật công nghệ trường hợp kiểm định kiểm định phát triển theo kiểm định săn đuổi công cụ ngôn ngữ mô hình hoá thống thiết kế UML đơn vị người sử dụng kiểm định người sử dụng kiểm dụng kiểm tra nhìn, khung nhìn 211 [...]... kiểm định hoặc/và có thể sẵn sàng phát hành được chưa? Mô hình chung của qui trình kiểm định phần mềm được thể hiện trong hình 3.5 Thiết kế Phân tích Thiết kế các trường hợp kiểm định Chuẩn bị dữ liệu kiểm định Các trường hợp kiểm định Mã hóa KIỂM THỬ Thực thi chương trình với dữ liệu kiểm định Dữ liệu kiểm định So sánh kết quả kiểm định Kết quả kiểm định Kết quả kiểm định Hình 3.5 – Qui trình kiểm định. .. chất lượng Công nghệ phần mềm Đảm bảo chất lượng ph mềm Xác minh và thẩm định phần mềm Kiểm định phần mềm (a) Ngữ cảnh quy trình Xác minh và thẩm định phần mềm Kiểm định phần mềm (b) Ngữ cảnh chất lượng Hình 3.3 - Kiểm định phần mềm trong một số ngữ cảnh 3.2 Hai vấn đề trọng tâm: K&K Khi khảo sát chất lượng của một phần mềm ta quan tâm đến hai vấn đề trọng tâm sau đây (Boehm, 1979) : Kiểm tra (Verification):... (Sommerville, 2011): 1 Kiểm định phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm nhằm đảm bảo rằng phần mềm đáp ứng đầy đủ các yêu cầu của bản thiết kế và các yêu cầu đó đáp ứng đúng những gì mà người sử dụng mong đợi; 2 Kiểm định phần mềm là qui trình bắt buộc trong các dự án phát triển phần mềm; 26 Chương 3 Kiểm định phần mềm _ 3 Kiểm định phần mềm là một... cáo kiểm định trong đó mô tả chi tiết kết quả của tất cả các trường hợp kiểm định đã thực thi: mục đích kiểm định, dữ liệu vào, kết quả dự kiến, kết quả thực tế, kết luận (đúng/sai)… Phân tích Thiết kế Mã hóa KIỂM ĐỊNH - Kế hoạch kiểm định - Các trường hợp kiểm định - Dữ liệu kiểm định Bàn giao sản phẩm - Các báo cáo kiểm định Hình 3.4 Kiểm định trong qui trình phát triển phần mềm 30 Chương 3 Kiểm định. .. vấn đề này ở những phần tiếp theo Mục tiêu của kiểm định phần mềm là thiết kế tài liệu, qui trình kiểm định một cách có hệ thống và thực thi qui trình này sao cho có hiệu quả, tiết kiệm được thời gian, công sức và chi phí Trên quan điểm qui trình, kiểm định phần mềm là một phần của kiểm tra và kiểm dụng phần mềm Kiểm tra và kiểm dụng là hai khái niệm thuộc phạm vi của công nghệ phần mềm và sẽ được giới... Qui trình kiểm định phần mềm 3.4 Tính không đầy đủ của kiểm định 3.5 Thanh sát (inspection) và kiểm điểm (review) 3.6 Test tự động 3.1 Khái niệm chung Kiểm định phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện Tuy nhiên, trong nhiều bối cảnh, hoạt động của chương trình có thể chưa bộc lộ lỗi Kiểm định phần mềm là quá trình khảo sát, kiểm tra, thực thi một hệ thống phần mềm để xác định. .. trong các mục tiếp theo Công nghệ phần mềm lại là một phần của công nghệ hệ thống Nhìn từ ngữ cảnh chất lượng, kiểm định phần mềm cũng là một phần phần của kiểm tra và kiểm dụng phần mềm, nên cũng có thể xem như là một phần của hoạt động quản lí chất lượng phần mềm Mục tiêu kiểm định 1 Phát hiện lỗi sớm 2 Giảm thiểu thời gian 3 Giảm thiểu chi phí Hình 3.1 - Kiểm định phần mềm trong một số ngữ cảnh Tỉ lệ... Ta xây dựng phần mềm có đúng như dự định? Kiểm dụng (Validation): Có đúng là ta xây dựng phần mềm đó? Kiểm tra và kiểm dụng phần mềm nhằm chứng tỏ rằng phần mềm đó đáp ứng đầy đủ và chính xác các yêu cầu của khách hàng đã được đặc tả trong bản thiết kế và phần mềm đó thực thi, hoạt động đúng như kì vọng của khách hàng 27 Chương 3 Kiểm định phần mềm _ Kiểm định chương trình trên các... trình kiểm định phần mềm Mục đích của kiểm định là thiết kế một chuỗi các trường hợp kiểm định, gọi là các bộ test, có khả năng phát hiện lỗi cao Để cho việc kiểm định đạt được kết quả tốt cần có sự chuẩn bị về kế hoạch kiểm định, thiết kế các trường hợp kiểm định và các dữ liệu kiểm định cho từng trường hợp Đây chính là đầu vào cho giai đoạn kiểm định Và sản phẩm (đầu ra) của giai đoạn kiểm định chính... đen: kiểm định dựa trên chức năng hay kiểm định vào/ra Các phương pháp hộp trắng: kiểm định dựa vào cấu trúc bên trong của hệ thống 31 Chương 3 Kiểm định phần mềm _ 4 Xử lý đo lường kiểm định bằng cách thu thập dữ liệu Chú ý rằng kiểm định viên không thể trực tiếp cải tiến chương trình mà họ chỉ có thể đánh giá nó 5 Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có vượt qua được kiểm ... toán: 4, văn: 3, ngoại ngữ: Công thức tính là: [(Điểm thi toán  4) + (Điểm thi văn  3) + (Điểm thi ngoại ngữ  3)] / 10 Nếu sửa số mã lệnh chương trình chắn gây nhiều phiền toái việc phổ biến cập... rộng; (3) Chiều dài rắn biến mất, chí trở thành số âm Trong trường hợp có ba lớp người: Người đặt hàng A, người phát triển hệ thống B người sử dụng C Kì vọng người sử dụng không xảy tình (1)- (3). .. khảo sát chất lượng phần mềm ta quan tâm đến hai vấn đề trọng tâm sau (Boehm, 1979) : Kiểm tra (Verification): Ta xây dựng phần mềm có dự định? Kiểm dụng (Validation): Có ta xây dựng phần mềm