Bài giảng Công nghệ phần mềm - Đảm bảo chất lượng phần mềm và kiểm thử

ó bao nhiêu loại nhân tố ảnh hưởng? „ Cách thức mà nó ảnh hưởng? 2005 Bộ môn CNFM – ĐH Công nghệ 24 NguyÔn V¨n Vþ „ 3 loại (theo McCall ) : (1) đặc trưng chức năng (2) khả năng đương đầu với những thay đổi, (3) khả năng thích nghi với môi trường mới. d1. Loại nhân tố ảnh hưởng 2005 Bộ môn CNFM – ĐH Công nghệ 25 NguyÔn V¨n Vþ „ 3 loại (theo McCall ) : (1) đặc trưng chức năng (2) khả năng đương đầu với những thay đổi, (3) khả năng thích nghi với môi trường mới. d2. Loại nhân tố và mức ảnh hưởng „ Mức độ ảnh hưởng: ƒ Nhân tố trực tiếp (chức năng) ƒ Nhân tố gián tiếp (những gì liên quan đến 1 và 2) Các loại nhân tố và mức độ ảnh hưởng: 2005 Bộ môn CNFM – ĐH Công nghệ 26 NguyÔn V¨n Vþ „Loại (1): Các đặc trưng chức năng ƒ tính đúng đắn, ƒ tính tin tưởng được, ƒ tính hiệu quả, ƒ tính toàn vẹn, ƒ tính khả dụng d3. Các nhân tố ảnh hưởng chất lượng McCall đề xuất 11 nhân tố phân theo loại: 2005 Bộ môn CNFM – ĐH Công nghệ 27 NguyÔn V¨n Vþ d3. Các nhân tố ảnh hưởng châta lượng (t) „ Loại (2)- đương đầu với thay đổi ƒ tính bảo trì được, ƒ tính mềm dẻo, ƒ tính thử nghiệm được „ Loại (3)- thích nghi với môi trường mới ƒ tính mang chuyển được ƒ tính sử dụng lại được ƒ tính liên tác được 2005 Bộ môn CNFM – ĐH Công nghệ 28 NguyÔn V¨n Vþ e. Các độ đo chất lượng „ Để đo mức độ ảnh hưởng cần có độ đo „ McCall đề xuất 21 độ đo sau: 1. Độ kiểm toán được, 2. Độ chính xác, 3. Độ tương đồng giao tiếp, 4. Độ đầy đủ, 5. Độ phức tạp, 6. Độ súc tích (conciseness), 7. Độ nhất quán (consistancy), 8. Độ tương đồng dữ liệu, 2005 Bộ môn CNFM – ĐH Công nghệ 29 NguyÔn V¨n Vþ e. Các độ đo chất lượng „ McCall đề xuất 21 độ đo sau: 9. Độ dung thứ lỗi, 10. Độ hiệu qủa thực hiện, 11. Độ khuếch trương được, 12. Độc lập phần cứng, 13. Độ trang bị đủ đồ nghề (instrumentation), 14. Độ môđun hoá, 15. Độ dễ thao tác, 16. Độ an ninh, 2005 Bộ môn CNFM – ĐH Công nghệ 30 NguyÔn V¨n Vþ e. Các độ đo chất lượng(t) „ McCall đề xuất 21 độ đo sau: 17. Tự tạo tài liệu (self-doccumentation), 18. Độ đơn giản - dễ hiểu, 19. Độc lập phần mềm, 20. Độ lần vết được, 21. Khả năng huấn luyện. 2005 Bộ môn CNFM – ĐH Công nghệ 31 NguyÔn V¨n Vþ e1. Tính đúng đắn 1. Tính đúng đắn là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 32 NguyÔn V¨n Vþ e1. Tính đúng đắn „ Các độ đo liên quan: ƒ Độ đầy đủ, ƒ Độ nhất quán ƒ Độ lần vết được 1.Tính đúng đắn: ƒ làm đúng với cái khách hàng mong muốn ƒ thoả mãn những điều đã được đặc tả (những yêu cầu của đối tượng khác) 2005 Bộ môn CNFM – ĐH Công nghệ 33 NguyÔn V¨n Vþ e2. Tính tin cậy được 2. Tính tin cậy được là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 34 NguyÔn V¨n Vþ e2. Tính tin cậy được 2. Tính tin cậy được • Độ môđun hoá, • Độ đơn giản – dễ hiểu, • Độ lần vết được „ Các độ đo liên quan: • Độ chính xác, • Độ phức tạp, • Độ nhất quán, • Độ dung thứ lỗi, Có thể trông đợi vào sự thực hiện các chức năng dự kiến và mức chính xác được đòi hỏi 2005 Bộ môn CNFM – ĐH Công nghệ 35 NguyÔn V¨n Vþ e3. Tính hiệu quả 3. Tính hiệu quả là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 36 NguyÔn V¨n Vþ e3. Tính hiệu quả „ Các độ đo liên quan: ƒ Độ súc tích, ƒ Độ hiệu qủa thực hiện, ƒ Độ dễ thao tác, 3. Tính hiệu quả: Tổng lượng nguồn lực tính toán và mã yêu cầu để thực hiện các chức năng của chương trình là thích hợp. 2005 Bộ môn CNFM – ĐH Công nghệ 37 NguyÔn V¨n Vþ e4. Tính toàn vẹn 4. Tính toàn vẹn là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 38 NguyÔn V¨n Vþ e4. Tính toàn vẹn ‹ Các độ đo liên quan: ƒ Độ kiểm toán được, ƒ Trang bị đồ nghề đủ, ƒ Độ an ninh, Sự khống chế được việc truy cập trái phép tới phần mềm và dữ liệu của HT 4. Tính toàn vẹn: 2005 Bộ môn CNFM – ĐH Công nghệ 39 NguyÔn V¨n Vþ e5. Tính khả dụng 5. Tính khả dụng là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 40 NguyÔn V¨n Vþ e5. Tính khả dụng „ Các độ đo liên quan: ƒ Độ dễ thao tác, ƒ Khả năng huấn luyện. 5. Tính khả dụng: công sức để học hiểu, thao tác dễ, chuẩn bị đầu vào, thể hiện đầu ra của chương trình là chấp nhận được, khả năng nhớ lâu 2005 Bộ môn CNFM – ĐH Công nghệ 41 NguyÔn V¨n Vþ e6. Tính bảo trì được 6. Tính bảo trì được là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 42 NguyÔn V¨n Vþ e6. Tính bảo trì được nỗ lực cần để định vị và xác định được 1 lỗi trong chương trình là chấp nhận được. Dễ thay đổi và mở rộng ƒ Độ tự cấp tài liệu, ƒ Độ đơn giản ƒ Độ dễ hiểu, 6. Tính bảo trì được: ■ Các độ đo liên quan: ƒ Độ súc tích, ƒ Độ nhất quán, ƒ Trang bị đồ nghề đủ, ƒ Độ mođun hoá, 2005 Bộ môn CNFM – ĐH Công nghệ 43 NguyÔn V¨n Vþ e7. Tính mềm dẻo 7. Tính mềm dẻo là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 44 NguyÔn V¨n Vþ e7. Tính mềm dẻo Có thể cải biên chương trình và nỗ lực cần để cải biên là chấp nhận được. ƒ Độ khái quát, ƒ Độ mođun hoá, ƒ Tự cấp tài liệu, ƒ Độ đơn giản - dễ hiểu, 7. Tính mềm dẻo: ■ Các độ đo liên quan: ƒ Độ phức tạp, ƒ Độ súc tích ƒ Độ nhất quán, ƒ Khuếch trương được, 2005 Bộ môn CNFM – ĐH Công nghệ 45 NguyÔn V¨n Vþ e8. Tính kiểm thử được 8. Tính kiểm thử được là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 46 NguyÔn V¨n Vþ e8. Tính kiểm thử được Công sức cần để kiểm thử chương trình và bảo đảm rằng nó thực hiện đúng chức năng dự định là chấp nhận được 8. Tính kiểm thử được: ■ Các độ đo liên quan: ƒ Độ kiểm toán được, ƒ Độ phức tạp, ƒ Trang bị đồ nghề đủ, ƒ Độ môđun hoá, ƒ Tự cấp tài liệu, ƒ Độ đơn giản - dễ hiểu, 2005 Bộ môn CNFM – ĐH Công nghệ 47 NguyÔn V¨n Vþ e9. Tính mang chuyển được 9. Tính mang chuyển được là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 48 NguyÔn V¨n Vþ e9. Tính mang chuyển được Công sức đòi hỏi để chuyển nó từ một môi trường (phần cứng, phần mềm) này sang một môi trường khác là chấp nhận được 9. Tính mang chuyển được: ■ Các độ đo liên quan: ƒ Độ khái quát, ƒ Độ độc lập phần cứng, ƒ Độ mođun hoá, ƒ Tự cấp tài liệu, ƒ Độc lập hệ thống phần mềm, 2005 Bộ môn CNFM – ĐH Công nghệ 49 NguyÔn V¨n Vþ e10. Tính sử dụng lại được 10. Tính sử dụng lại được là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 50 NguyÔn V¨n Vþ e10. Tính sử dụng lại được Khả năng hệ thống hoặc một phần của nó có thể được dùng lại trong một ứng dụng khác 10. Tính sử dụng lại được: ■ Các độ đo liên quan: • Độ khái quát, • Độc lập phần cứng, • Độ môđun hoá, • Tự tạo tài liệu, • Độc lập hệ thống phần mềm, 2005 Bộ môn CNFM – ĐH Công nghệ 51 NguyÔn V¨n Vþ e11. Tính liên tác được 11. Tính liên tác được là gì? 2005 Bộ môn CNFM – ĐH Công nghệ 52 NguyÔn V¨n Vþ e11. Tính liên tác được Công sức đòi hỏi để ghép nối hệ thống phần mềm với một hệ thống khác là chấp nhận được 11. Tính liên tác được: ■ Các độ đo liên quan: • Độ tương đồng giao tiếp, • Độ tương đồng dữ liệu, • Độ khái quát, • Độ môđun hoá. 2005 Bộ môn CNFM – ĐH Công nghệ 53 NguyÔn V¨n Vþ f. Các nhân tố chất lượng phần mềm FURPS của Hawlett-Packard 1 ƒ F: Functionality – Nhân tố chức năng ƒ U: Usability – Nhân tố khả dụng ƒ R: Reability – Nhân tố tin cậy ƒ P: Performance – Nhân tố thi hành ƒ S: Supportability – Nhân tố mang chuyển 2005 Bộ môn CNFM – ĐH Công nghệ 54 NguyÔn V¨n Vþ f1. FURPS: Nhân tố chức năng Được xác định bằng: ■ tập hợp các tính chất và khả năng của hệ thống ■ độ khái quát các chức năng được thực hiện ■ độ an ninh của toàn hệ thống 2005 Bộ môn CNFM – ĐH Công nghệ 55 NguyÔn V¨n Vþ f2. FURPS: Nhân tố khả dụng Được xác định bằng việc xem xét các nhân tố con người: thói quen, thẩm mỹ, sự hoà hợp và tư liệu cung cấp: Dễ học, dễ thao tác, dễ nhớ, đủ tài liệu, gây hứng thú, 2005 Bộ môn CNFM – ĐH Công nghệ 56 NguyÔn V¨n Vþ f3. FURPS: Nhân tố tin cậy Được đánh giá bằng: ƒ Tần xuất thất bại và độ nghiêm trọng của nó ƒ Tính chính xác của các kết quả ra, ƒ Thời gian làm việc trung bình giữa 2 thất bại kế tiếp, ƒ Khả năng phục hồi sau thất bại, ƒ Khả năng dự đoán trước được thất bại của chương trình 2005 Bộ môn CNFM – ĐH Công nghệ 57 NguyÔn V¨n Vþ f4. FURPS: Nhân tố thi hành Được đánh giá bằng: ƒ Tốc độ xử lý, ƒ Thời gian đáp ứng, ƒ Độ sử dụng nguồn lực, ƒ Năng xuất, và Hiệu năng của các chức năng 2005 Bộ môn CNFM – ĐH Công nghệ 58 NguyÔn V¨n Vþ f5. FURPS: Nhân tố mang chuyển Đánh giá bằng tổ hợp các khả năng: ƒ Mở rộng được, ƒ Thích nghi được, ƒ Tự phục vụ được, ƒ Kiểm thử được, ƒ Sự tương hợp, ƒ Cấu hình được (khả năng tổ chức và khống chế các yếu tố của cấu hình phần mềm, dễ dàng cài đặt hệ thống và dễ dàng định vị các chỗ có vấn đề) Bảo trì được 2005 Bộ môn CNFM – ĐH Công nghệ 59 NguyÔn V¨n Vþ 3. Tiến hóa của hoạt động SQA „ Khi phần mềm trở thành sản phẩm có nhu cầu và đòi hỏi đảm bảo chất lượng: ƒ Từ khách hàng (nhu cầu) ƒ Từ nhà sản xuất (đòi hỏi): đảm bảo tính đồng đều của sản phẩm, cải thiện chất lượng thường xuyên „ Từ thực tiễn: King nghiệm cho phép hoạt động đảm bảo chất lượng phần mềm ngày càng được hoàn thiện. Hiểu về vai trò của nó và tăng thêm các hoạt động đảm bảo chất lượng 2005 Bộ môn CNFM – ĐH Công nghệ 60 NguyÔn V¨n Vþ a. Sự phát triển của SQA ■ Bảo đảm chất lượng là hoạt động cốt yếu của mọi doanh nghiệp làm ra sản phẩm hàng hóa ■ Đảm bảo chất lượng phần mềm diễn ra song song với bảo đảm chất lượng trong chế tạo phần cứng. ■ Các chuẩn bảo đảm chất lượng phần mềm là cơ sở đo chất lượng (Chúng đầu tiên được đưa ra trong quân sự vào những năm 70 và nhanh chóng mở rộng trong thương mại) 2005 Bộ môn CNFM – ĐH Công nghệ 61 NguyÔn V¨n Vþ b. Vai trò và trách nhiệm trong SQA ■ Những người có trách nhiệm bảo đảm chất lượng phần mềm (trong tổ chức): ƒ Kỹ sư phần mềm, ƒ Nhà quản lý dự án, ƒ Khách hàng, ƒ Người bán hàng ƒ Thành viên trong nhóm SQA. 2005 Bộ môn CNFM – ĐH Công nghệ 62 NguyÔn V¨n Vþ b. Vai trò và trách nhiệm trong SQA(t) ■ Nhóm SQA phải đóng vai trò như đại diện của khách hàng - để xem xét chất lượng phần mềm: ƒ Có đáp ứng được các nhân tố chất lượng không? ƒ Có tuân theo các chuẩn dự định trước không? ƒ Các thủ tục, phương pháp, kỹ thuật có thực sự đóng vai trò của chúng trong hoạt động SQA? 2005 Bộ môn CNFM – ĐH Công nghệ 63 NguyÔn V¨n Vþ c. Các hoạt động SQA ■ Có 7 hoạt động chính: (1) Áp dụng công nghệ, kỹ nghệ hiệu quả (phương pháp, công cụ và tiến trình) (2) Tiến hành rà soát kỹ thuật chính thức (3) Thực hiện kiểm thử nhiều tầng (4) Tuân theo các chuẩn phát triển (5) Kiểm soát tài liệu FM và thay đổi của chúng (6) Thực hiện đo lường (7) Báo cáo và quản lý các báo cáo. 2005 Bộ môn CNFM – ĐH Công nghệ 64 NguyÔn V¨n Vþ e1. Vai trò của các hoạt động SQA ■ Tập hợp các phương pháp và công cụ giúp để: • giúp phân tích có được đặc tả tốt, • giúp thiết kế có được thiết kế chất lượng cao. • Trợ giúp kiểm thử hiệu quả ■ Rà soát kỹ thuật chính thức là hoạt động trung tâm. (tác dụng không kém gì thử nghiệm để việc phát hiện khiếm khuyết). ■ Kiểm thử phần mềm (chỉ kiểm thử không thể tìm ra được hầu hết các sai) 2005 Bộ môn CNFM – ĐH Công nghệ 65 NguyÔn V¨n Vþ e1. Vai trò của các hoạt động SQA(t) ■ Áp dụng các chuẩn và các thủ tục chính thức là một nhu cầu và điều kiện cho SQA. Tuy nhiên, còn tuỳ thuộc mỗi công ty. Có 2 loại chuẩn và thủ tục: ƒ do khách hàng, hay chính quyền quy định. ƒ tự công ty đặt ra. ■ Đánh giá sự phù hợp với các chuẩn là một phần của việc rà soát chính thức. ■ Khi cần phải Xác minh sự phù hợp; nhóm SQA có thể tiến hành kiểm toán (audit) riêng. 2005 Bộ môn CNFM – ĐH Công nghệ 66 NguyÔn V¨n Vþ e1. Vai trò của các hoạt động SQA(t) ■ Khống chế đổi thay đóng góp trực tiếp vào chất lượng phần mềm nhờ: ƒ chính thức hoá các yêu cầu đổi thay, ƒ đánh giá bản chất của sự đổi thay, ƒ khống chế các ảnh hưởng của sự đổi thay. ™ Đe doạ chủ yếu của chất lượng đến từ sự thay đổi. Thay đổi là bản chất của phần mềm ™ Thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu ứng phụ lan truyền. Lý do: ■ Khống chế thay đổi áp dụng trong suốt quá trình phát triển và bảo trì 2005 Bộ môn CNFM – ĐH Công nghệ 67 NguyÔn V¨n Vþ ■ Lập và lưu giữ báo cáo về SQA: • phổ biến các thông tin SQA (người cần có thể biêt). • cung cấp các thủ tục để thu thập thông tin ■ Đối tượng báo cáo là kết quả các hoạt động SQA: • rà soát, • kiểm toán, • khống chế đổi thay, • Kiểm thử, • và các hoạt động SQA khác ■ Người phát triển sử dụng theo quy tắc “cần-thì-biết” – trong suốt quá trình dự án e1. Vai trò các hoạt động SQA (t) 2005 Bộ môn CNFM – ĐH Công nghệ 68 NguyÔn V¨n Vþ e2. Mục tiêu của hoạt động SQA ■ Một mục tiêu quan trọng của SQA: • Theo dõi chất lượng phần mềm • Đánh giá ảnh hưởng của thay đổi về phương pháp luận và thủ tục lên chất lượng phần mềm. ‰ Muốn vậy phải thu thập các độ đo phần mềm. ■ Các độ đo phần mềm hướng đến các mặt: • quản lý (thủ tục) • kỹ thuật (phương pháp) • Yêu cầu người dùng 2005 Bộ môn CNFM – ĐH Công nghệ 69 NguyÔn V¨n Vþ 3. Rà soát phần mềm ■ Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗi giai đoạn để phát hiện ra những khiểm khuyết cần sửa chữa trước khi sang giai đoạn sau ■ Mục tiêu: • Chỉ ra các khiếm khuyết cần phải cải thiện. • Khẳng định những phần sản phẩm đạt yêu cầu. • Kiểm soát việc đạt chất lượng kỹ thuật tối thiểu của sản phẩm (có diện mạo không đổi, ổn định) ■ Áp dụng tại các thời điểm khác nhau trong quá trình phát triển phần mềm. 2005 Bộ môn CNFM – ĐH Công nghệ 70 NguyÔn V¨n Vþ a. Các hình thức rà soát ■ Các kiểu rà soát: ƒ Họp xét duyệt không chính thức, ƒ Họp chính thức trước với các thành viên: khách hàng, nhà quản lý, nhân viên kỹ thuật. (tập trung vào các rà soát kỹ thuật chính thức) ƒ FTR chủ yếu do các kỹ sư phần mềm thực hiện (là một phương tiện hiệu quả để cải thiện chất lượng) 2005 Bộ môn CNFM – ĐH Công nghệ 71 NguyÔn V¨n Vþ b. Lợi ích của việc rà soát ■ Sớm phát hiện các “khiếm khuyết” của phần mềm để có thể chỉnh sửa. ■ Các nghiên cứu của công nghiệp phần mềm (TRW, Nippon Electric, Mitre Corp., …) đã chỉ ra: các hoạt động thiết kế tạo ra đến 50% - 60% tổng số các khiếm khuyết tạo ra trong phát triển mềm ■ Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn. trong thiết kế tốn phí 1.0, trước kiểm thử: 6.5, trong kiểm thử: 15 và sau phân phối sẽ ltừ 60. đến 100. 2005 Bộ môn CNFM – ĐH Công nghệ 72 NguyÔn V¨n Vþ b1. Chi phí sửa lỗi trong quá trình phát triển 1 6.5 15 100 0 10 20 30 40 50 60 70 80 90 100 Thiết kê trước test trong test phân phối Chi phí sửa lỗi 2005 Bộ môn CNFM – ĐH Công nghệ 73 NguyÔn V¨n Vþ c. Các loại lỗi ■ Ba loại lỗi có ở mỗi bước của quá trình phát triển phần mềm: • lỗi mới được sinh ra • lỗi còn lại của các bước trước. • lỗi được phóng đại lên do các nhân tố lỗi của các bước trước ■ Nếu không rà soát lỗi tồn lại gia tăng nhanh, và phí cho việc loại trừ các lỗi ngày càng lớn; Nguyên tắc xử lý lỗi: “chi phí bây giờ hay để lại sau phải chi phí nhiều hơn?” 2005 Bộ môn CNFM – ĐH Công nghệ 74 NguyÔn V¨n Vþ d. Rà soát kỹ thuật chính thức (formal technical review - FTR) ■ Rà soát kỹ thuật chính thức là hoạt động bảo đảm chất lượng phần mềm do những người đang tham gia phát triển phần mềm thực hiện . ■Mục tiêu cụ thể là: • Phát hiện các lỗi trong chức năng, trong logic, trong triển khai (implementation). • Kiểm thử sự phù hợp của phần mềm với yêu cầu • Khẳng định phần đã đạt yêu cầu 2005 Bộ môn CNFM – ĐH Công nghệ 75 NguyÔn V¨n Vþ d. Rà soát kỹ thuật chính thức ■Mục tiêu cụ thể là (tiếp): ƒ Bảo đảm phần mềm phù hợp với các chuẩn đã định ƒ Đảm bảo “phần mềm đã được phát triển theo một cách thức nhất quán” (uniform manner) ƒ Làm cho dự án dễ quản lý hơn ƒ Ngoài ra, dùng làm cơ sở huấn luyện các kỹ sư trẻ và cả cho những kỹ sư đã có kinh nghiệm 2005 Bộ môn CNFM – ĐH Công nghệ 76 NguyÔn V¨n Vþ e. Tiến trình hoạt động rà soát Cá nhân báo cáo sản phẩm cần rà soát Xem xét, yêu cầu rà soát sao chép, phân công rà soát rà soát, lập báo cáo Lập chương trình họp rà soát Họp rà soát, Lập báo cáo Hội đồng rà soát Người thực hiện Người quản lý Người phát triển 2005 Bộ môn CNFM – ĐH Công nghệ 77 NguyÔn V¨n Vþ e. Các bước tiến hành ■ Cá nhân phát triển báo cáo lãnh đạo dự án biết sản phẩm của mình đã hoàn tất và cần rà soát. ■ Lãnh đạo dự án thông báo cho người chịu trách nhiệm rà soát; ■ người chịu trách nhiệm lãnh đạo rà soát: • xem xét sản phẩm để đọc, rà soát • tạo ra các bản sao sản phẩm, phân cho 2,3 người rà soát; • Thiết lập chương trình họp rà soát ■ Thực hiện rà soát: thường tốn 1-2 giờ để rà soát, viết các bản ghi chú; tham gia cuộc họp rà soát 2005 Bộ môn CNFM – ĐH Công nghệ 78 NguyÔn V¨n Vþ f. Cuộc họp rà soát ■ Mọi cuộc họp rà soát phải: • Gồm từ 3 đến 5 người liên quan. • Phải chuẩn bị trước, (1 người không quá 2 giờ). • Cuộc họp không nên ít hơn 2 giờ. Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ, cụ thể. • Sản phẩm cho cuộc họp rà soát là: một thành phần (của đặc tả yêu cầu, 1 thiết kế môđun chi tiết, 1 danh sách mã nguồn cho 1 môđun) 2005 Bộ môn CNFM – ĐH Công nghệ 79 NguyÔn V¨n Vþ f. Cuộc họp rà soát (t) ■ Thành phần: lãnh đạo rà soát, các cá nhân rà soát và người tạo ra sản phẩm được rà soát (+ khách). ■ Kết luân đưa ra 1 trong 3 quyết định sau: • Chấp nhận sản phẩm không cần chỉnh sửa • Khước từ sản phẩm vì những lỗi nghiêm trọng • Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải rà soát lại ■ Mọi thành viên tham gia cuộc họp phải ký vào quyết định 2005 Bộ môn CNFM – ĐH Công nghệ 80 NguyÔn V¨n Vþ g. Sản phẩm rà soát ■ Sản phẩm của cuộc họp rà soát: • Báo cáo các vấn đề nảy sinh do các cá nhân rà soát nêu ra • một danh sách các vấn đề cần giải quyết do cuộc họp thống nhất • một văn bản tổng kết cuộc họp rà soát đó. ■ Văn bản tổng kết họp rà soát phải chỉ rõ: • Đã rà soát cái gì • Ai rà soát • Tìm thấy cái gì và Kết luận ra sao 2005 Bộ môn CNFM – ĐH Công nghệ 81 NguyÔn V¨n Vþ g. Sản phẩm rà soát (t) ■ Bản danh sách các vấn đề tồn tại phục vụ cho: • Nhận ra các vùng có vấn đề trong sản phẩm được rà soát • Dùng như một danh sách các khoản mục để chỉ cho các người làm ra sản phẩm cần chỉnh sửa • Thiết lập thủ tục để bảo đảm rằng các khoản mục trong danh sách đó sẽ được chỉnh sửa thực sự 2005 Bộ môn CNFM – ĐH Công nghệ 82 NguyÔn V¨n Vþ h. Phương châm rà soát ■ Cần thiết lập trước Phương châm rà soát, phân phát cho những người làm rà soát để thống nhất và tuân thủ. Một rà soát mà không khống chế được thì có thể còn xấu hơn là không rà soát ■ 10 điều tối thiểu trong phương châm rà soát kỹ thuật chính thức: 2005 Bộ môn CNFM – ĐH Công nghệ 83 NguyÔn V¨n Vþ h. 10 phương châm rà soát (t) 1. Rà soát sản phẩm, không rà soát người làm ra nó. 2. Lập chương trình nghị sự và duy trì nó. 3. Hạn chế tranh luận và bác bỏ: vấn đề cần tranh luận được ghi nhớ cho sau này. 4. Trình bày rõ ràng các vùng có vấn đề, nhưng không gượng ép giải quyết. FTR không giải quyết vấn đề. Giải quyết vấn đề sau FTR và thường do chính người làm sản phẩm thực hiện, có thể nhờ sự trợ giúp của vài cá nhân khác. 2005 Bộ môn CNFM – ĐH Công nghệ 84 NguyÔn V¨n Vþ h. 10 phương châm rà soát (t) 5.Nên có ghi chú trên bảng tường. 6.Giới hạn số người tham dự và kiên trì các dự kiến 7.Lập một danh mục kiểm tra (checklist) cho từng sản phẩm sẽ được rà soát: ƒ giúp lãnh đạo rà soát cơ cấu các cuộc họp FTR, ƒ giúp người rà soát tập trung vào các vấn đề quan trọng. ƒ Danh mục rà soát lập cho từng loại sản phẩm : phân tích, thiết kế, mã hoá, kiểm thử và bảo trì. ƒ Một tập thể các đại diện xem lại danh mục này để trình. 2005 Bộ môn CNFM – ĐH Công nghệ 85 NguyÔn V¨n Vþ h. 10 phương châm rà soát (t) 8. Cấp phát nguồn lực & thời gian cho các FTR: ƒ là 1 nhiệm vụ trong quá trình phát triển ƒ phải dự tính các cải biên cần thiết cho sự kiện chưa dự đoán được (sẽ xuất hiện do 1 FTR). 9. Cần tiến hành huấn luyện chính thức cho các cá nhân rà soát. 10.Rà soát lại các rà soát trước đây. 2005 Bộ môn CNFM – ĐH Công nghệ 86 NguyÔn V¨n Vþ i. Tiến hành rà soát ■ Mọi sản phẩm tao ra ở mỗi bước đều được rà soát (không chỉ sản phẩm cuối cùng) ■ Rà soát được tiến hành suốt quá trình phát triển ■ Tiến trình phát triển chung nhất gồm 4 -5 giai đoạn: ƒ Kỹ nghệ hệ thống (lập KH triển khai) ƒ Phân tích, xác định yêu cầu phần mềm ƒ Thiết kế phần mềm ƒ Kiểm thử phần mềm ƒ Bao trì (với sản phẩm đặt hàng) Rà soát bám sát theo sản phẩm của các giai đoạn này 2005 Bộ môn CNFM – ĐH Công nghệ 87 NguyÔn V¨n Vþ k. Các danh mục rà soát ■ Bảo đảm chất lượng mức này là đánh giá các yêu cầu thẩm duyệt ở mức hệ thống: một cuộc họp lớn gồm các đại diện các đơn vị liên quan. ■ Danh mục rà soát kỹ nghệ hệ thống: a) Các chức năng chủ yếu đã được xác định đủ & rõ ràng (không mơ hồ) ? b) Các giao diện giữa các hệ con của hệ thống đã được xác định đủ & đúng hay chưa? c) Các ràng buộc thực thi đã được thiết lập cho toàn hệ thống và cho từng phần tử hay chưa? 2005 Bộ môn CNFM – ĐH Công nghệ 88 NguyÔn V¨n Vþ k1. Danh mục rà soát kỹ nghệ hệ thống „ Danh mục rà soát trong kỹ nghệ hệ thống (tiếp): d) Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa? e) Khả năng lựa chọn đã là tốt nhất chưa? f) Giải pháp có khả thi kỹ thuật không? g) Có sự hoà hợp giữa các phần tử của hệ thống hay chưa? h) Cơ chế xác minh & thẩm định đã được thiết lập hay chưa? 2005 Bộ môn CNFM – ĐH Công nghệ 89 NguyÔn V¨n Vþ k2. Danh mục rà soát lập kế hoạch ■ Lập kế hoạch dự án phần mềm dựa trên sản phẩm của kỹ nghệ hệ thống để đưa ra các nội dung chủ yếu: • Phạm vi công việc triển khai thực hiện • Ước lượng nguồn lực, giá cả, thời gian công việc • Lịch biểu thực hiện • Tổ chức, nhân sự, cơ chế triển khai • Đánh giá rủi ro & kế hoạch khắc phục • Các kế hoạch khác 2005 Bộ môn CNFM – ĐH Công nghệ 90 NguyÔn V¨n Vþ k2. Danh mục rà soát lập kế hoạch(t) ■ Danh mục rà soát cho việc lập kế hoạch dự án phần mềm bao gồm: a. Phạm vi của phần mềm đã xác định đúng đắn chưa? có bị hạn chế hay không? b. Thuật ngữ có trong sáng không? c. Các nguồn lực (người, chi phí, thời gian): • có tương xứng với phạm vi đó không? • đã sẵn sàng chưa? • cơ sở dự toán giá cả có hợp lý hay không? 2005 Bộ môn CNFM – ĐH Công nghệ 91 NguyÔn V¨n Vþ k2. Danh mục rà soát lập kế hoạch(t) • dữ liệu năng xuất & chất lượng trước đây có được sử dụng hay không? • sự khác biệt của ước lượng đã xử lý chưa? d. Các công việc lên lịch biểu đã: • xác định thích hợp chưa? • sắp xếp trình tự thực hiện đúng logic chưa? • bố trí song song có phù hợp với các nguồn lực đã sẵn có hay không? 2005 Bộ môn CNFM – ĐH Công nghệ 92 NguyÔn V¨n Vþ k2. Danh mục rà soát lập kế hoạch(t) e. Phương án tổ chức và nhân sự hợp lý chưa? f. Rủi ro trong tất cả các hạng mục quan trọng đã: • xác định & và đánh giá đầy đủ chưa? • lập kế hoạch quản lý & KH thích hợp chưa? g. Ngân sách và thời hạn chót dự kiến: • có hiện thực hay không? • có phù hợp với lịch biểu không? 2005 Bộ môn CNFM – ĐH Công nghệ 93 NguyÔn V¨n Vþ k3. Rà soát phân tích yêu cầu phần mềm - ■Rà soát phân tích yêu cầu phần mềm ƒ tập trung vào khả năng viết ra các yêu cầu hệ thống ƒ sự phù hợp và đúng đắn của mô hình phân tích. ■Với các hệ thống lớn thì cần tăng cường: ƒ các rà soát kỹ thuật chính thức ƒ việc đánh giá các nguyên mẫu cũng như các cuộc họp với khách hàng ■ Các yêu cầu của hệ thống phần mềm ƒ Yêu cầu chức năng ƒ Yêu cầu phi chức năng ƒ Yêu cầu ngoại lai 2005 Bộ môn CNFM – ĐH Công nghệ 94 NguyÔn V¨n Vþ ■ Nội dung thẩm định yêu cầu phần mềm: ƒ Phải chỉ ra các nhu cầu người dùng được thỏa mãn chưa. ƒ Các yêu cầu phải nhất quán: không mâu thuẫn nhau. ƒ Các yêu cầu phải đày đủ: phải chứa mọi chức năng và mọi ràng buộc mà người dùng nhắm đến. ƒ Các yêu cầu phải hiện thực: có khả năng thực hiện được. ƒ Sự tương hợp với mô hình hệ thống và kế hoạch triển khai ■ Rà soát phân tích yêu cầu là phục vụ việc thẩm định và xác minh k3. Rà soát phân tích yêu cầu phần mềm (t) - 2005 Bộ môn CNFM – ĐH Công nghệ 95 NguyÔn V¨n Vþ k3. Danh mục rà soát phân tích yêu cầu (t) - ■ Rà soát kỹ thuật chính thức cho khâu phân tích xem xét các chủ đề sau đây: a) Phân hoạch vấn đề (hệ con) có đầy đủ hay không? b) Các giao diện trong và ngoài đã thực sự được xác định chưa? c) Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chính xác hay không? d) Mô hình dữ liệu đã thực sự phản ánh đầy đủ các đối tượng dữ liệu, các thuộc tính và các quan hệ? 2005 Bộ môn CNFM – ĐH Công nghệ 96 NguyÔn V¨n Vþ k3. Danh mục rà soát phân tích yêu cầu (t) - e) Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không? f) Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa? g) Có thực hiện được những ràng buộc quy định bởi các phần tử hệ thống khác hay không? h) Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí hay không? i) Các chuẩn thẩm định có đầy đủ hay không? 2005 Bộ môn CNFM – ĐH Công nghệ 97 NguyÔn V¨n Vþ m. Rà soát thiết kế phần mềm - ■ Rà soát khâu