Bài giảng Đảm bảo chất lượng phần mềm và kiểm thử - Phần 1: Tổng quan

i tượng khác) „ Các độ đo liên quan: ƒ Độ đầy đủ, ƒ Độ hoà hợp ƒ Độ lần vết được 2005 Bộ môn CNFM – ĐH Công nghệ 16 NguyÔn V¨n Vþ e. Tính tin cậy được „ Tính tin cậy được là gì?: 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 „ Các độ đo liên quan: • Độ chính xác, • Độ phức tạp, • Độ hoà hợp, • Độ dung thứ lỗi, • Độ mođun hoá, • Độ đơn giản – dễ hiểu, • Độ lần vết được 2005 Bộ môn CNFM – ĐH Công nghệ 17 NguyÔn V¨n Vþ f. Tính hiệu quả „ Tính hiệu quả Là gì?: 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, „ Các độ đo liên quan: ƒ Độ súc tích, ƒ Độ hiệu qủa thực hiện, ƒ Độ dễ thao tác, 2005 Bộ môn CNFM – ĐH Công nghệ 18 NguyÔn V¨n Vþ g. Tính toàn vẹn ‹ Tính toàn vẹn Là gì?: là 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 ‹ Các độ đo liên quan: ƒ Độ kiểm toán được, ƒ Trang bị đồ nghề đủ, ƒ Độ an ninh, 2005 Bộ môn CNFM – ĐH Công nghệ 19 NguyÔn V¨n Vþ h. Tính khả dụng ■ Tính khả dụng Là gì?: công sức để học hiểu, thao tác, 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 ■ Các độ đo liên quan: ƒ Độ dễ thao tác, ƒ Khả năng huấn luyện. 2005 Bộ môn CNFM – ĐH Công nghệ 20 NguyÔn V¨n Vþ i. Tính bảo trì được ■ Tính bảo trì được là gì?: 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 ■ Các độ đo liên quan: ƒ Độ súc tích, ƒ Độ hoà hợp, ƒ Trang bị đồ nghề đủ, ƒ Độ mođun hoá, ƒ Độ tự cấp tài liệu, ƒ Độ đơn giản ƒ Độ dễ hiểu, 2005 Bộ môn CNFM – ĐH Công nghệ 21 NguyÔn V¨n Vþ k. Tính mềm dẻo ■Tính mềm dẻo Là gì? nỗ lực cần để cải biên một chương trình là chấp nhận được ■Các độ đo liên quan: ƒ Độ phức tạp, ƒ Độ súc tích ƒ Độ hoà hợp, ƒ Khuếch trương được, ƒ Độ khái quát, ƒ Độ mođun hoá, ƒ Tự cấp tài liệu, ƒ Độ đơn giản - dễ hiểu, 2005 Bộ môn CNFM – ĐH Công nghệ 22 NguyÔn V¨n Vþ m. Tính thử nghiệm được ■ Tính thử nghiệm được là gì?: nỗ lực cần để thử nghiệm 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 ■ 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ệ 23 NguyÔn V¨n Vþ l. Tính mang chuyển được ■ Tính mang chuyển được là gì?: nỗ lự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 phần cứng (phần mềm) khác là chấp nhậ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ệ 24 NguyÔn V¨n Vþ n. Tính sử dụng lại được ■Tính sử dụng lại được là gì?: Khả năng chương trình (hoặc một phần của nó) có thể được dùng lại trong một ứng dụng khá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ệ 25 NguyÔn V¨n Vþ o. Tính liên tác được ■ Tính liên tác được là gì?: nỗ lực đòi hỏi để ghép HT chương trình vào một hệ thống khác là chấp nhận đượ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ệ 26 NguyÔn V¨n Vþ p. 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ệ 27 NguyÔn V¨n Vþ p1. FURPS: Nhân tố chức năng Được định giá bằng tập hợp các tính chất và khả năng của chương trình đó, độ khái quát các chức năng được thực hiện và độ an ninh của toàn hệ thống 2005 Bộ môn CNFM – ĐH Công nghệ 28 NguyÔn V¨n Vþ p2. FURPS: Nhân tố khả dụng Được định giá bằng việc xem xét các nhân tố con người, thẩm mỹ, sự hoà hợp và tư liệu cung cấp 2005 Bộ môn CNFM – ĐH Công nghệ 29 NguyÔn V¨n Vþ p3. FURPS: Nhân tố tin cậy Được đánh giá bằng: ƒ Tần xuất thất bại và độ nghiên trọng của nó ƒ Tính chính xác của các kết quả ra, ƒ Thời gian trung bình giữa hai thất bại kế nhau, ƒ 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ệ 30 NguyÔn V¨n Vþ p4. 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 2005 Bộ môn CNFM – ĐH Công nghệ 31 NguyÔn V¨n Vþ p5. FURPS: Nhân tố mang chuyển Đánh giá bằng tổ hợp các khả năng: ƒ Mở rộng chương trình, ƒ Độ thích nghi ƒ Phục vụ được (bảo trì được) ƒ Thử nghiệm đượ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ệ 32 NguyÔn V¨n Vþ 2. 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ệ 33 NguyÔn V¨n Vþ a. Sự phát triển của SQA ■ Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nào làm ra sản phẩm được người khác dùng ■ Đả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 đầu tiên được đưa ra trong quân sự vào những năm 70 và nhanh chóng mở rộng thương mại 2005 Bộ môn CNFM – ĐH Công nghệ 34 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ệ 35 NguyÔn V¨n Vþ b. Vai trò và trách nhiệm trong SQA ■ 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 với quan điểm của khách hàng: ƒ 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ệ 36 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ụ) (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ệ 37 NguyÔn V¨n Vþ c. 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ả chất lượng cao, • giúp thiết kế có được thiết kế chất lượng cao. ■ Hoạt động trung tâm là rà soát kỹ thuật chính thức. (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ỉ thử nghiệm phần mềm không thể tìm ra được hầu hết các sai) 2005 Bộ môn CNFM – ĐH Công nghệ 38 NguyÔn V¨n Vþ c. Các hoạt động SQA ■ Á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 kiểm chứng (verification) 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ệ 39 NguyÔn V¨n Vþ c. Các hoạt động SQA ■ 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. 2005 Bộ môn CNFM – ĐH Công nghệ 40 NguyÔn V¨n Vþ c. Các hoạt động SQA ■ Khống chế thay đổi áp dụng trong suốt quá trình phát triển và trong quá trình bảo trì ■ 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 đổi thay 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 2 mặt: • quản lý (thủ tục) • kỹ thuật (phương pháp) 2005 Bộ môn CNFM – ĐH Công nghệ 41 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, • thử nghiệm, • 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 c. Các hoạt động SQA 2005 Bộ môn CNFM – ĐH Công nghệ 42 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ệ 43 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 - formal technical review - FTR) ■ 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 phần mềm) 2005 Bộ môn CNFM – ĐH Công nghệ 44 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ệ 45 NguyÔn V¨n Vþ b. 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ệ 46 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 phóng đại lên do các nhân tố lỗi của các bước trước • lỗi còn 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; Vì vậy vấn đề đặt ra là: “chi phí ngay bây giờ hay để lại sau phải chi phí nhiều hơn?” 2005 Bộ môn CNFM – ĐH Công nghệ 47 NguyÔn V¨n Vþ d. Rà soát kỹ thuật chính thức ■ Rà soát kỹ thuật chính thức (FTR) 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ệ 48 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 rằng phần mềm phù hợp với các chuẩn đã định sẵn. ƒ Đả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ó ích ngay cả cho những kỹ sư đã có kinh nghiệm 2005 Bộ môn CNFM – ĐH Công nghệ 49 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ệ 50 NguyÔn V¨n Vþ e. Các bước tiến hành ■ Cá nhân phát triển thông báo cho lãnh đạo dự án biết sản phẩm đã 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 biế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 ■ những 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ệ 51 NguyÔn V¨n Vþ f. Cuộc họp rà soát ■ Mọi cuộc họp rà soát phải: • Có từ 3 đến 5 người liên quan tới việc rà soát. • Phải chuẩn bị trước, tuy nhiên mỗi người không quá 2 giờ chuẩn bị. • 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ể. • Trọng tâm của các cuộc họp rà soát là về sản phẩm: một thành phần (một phần của đặc tả yêu cầu, một thiết kế môđun chi tiết, một danh sách mã nguồn cho 1 môđun) 2005 Bộ môn CNFM – ĐH Công nghệ 52 NguyÔn V¨n Vþ f. Cuộc họp rà soát ■ Thành phần gồm: lãnh đạo rà soát, tất cả các cá nhân rà soát và người tạo ra sản phẩm được rà soát. ■ Cuối buổi phải đưa ra 1 trong 3 quyết định sau đây: • 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 có cuộc họp 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ệ 53 NguyÔn V¨n Vþ f. Cuộc họp rà soát ■ Sản phẩm của cuộc họp rà soát là: • 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 2005 Bộ môn CNFM – ĐH Công nghệ 54 NguyÔn V¨n Vþ f. Cuộc họp rà soá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ệ 55 NguyÔn V¨n Vþ g. 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 nhiệm vụ rà soát, thống nhất tán thành 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ệ 56 NguyÔn V¨n Vþ g. 10 phương châm rà soát 1. Rà soát sản phẩm, không rà soát người làm 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ỏ: các vấn đề cần tranh luận được ghi nhớ cho các thảo luận tiếp tục. 4. Trình bày rõ ràng mạch lạc 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ệ 57 NguyÔn V¨n Vþ g. 10 phương châm rà soá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 sách 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 sách kiểm tra 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 sách này để trình. 2005 Bộ môn CNFM – ĐH Công nghệ 58 NguyÔn V¨n Vþ g. 10 phương châm rà soát 8. Cấp phát nguồn lực & thời gian biểu cho các FTR: ƒ là một 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 một 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ệ 59 NguyÔn V¨n Vþ h. Sản phẩm cần rà soát ■ Mọi sản phẩm được 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ệ 60 NguyÔn V¨n Vþ i. Danh mục rà soát trong kỹ nghệ hệ thống ■ 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ệ 61 NguyÔn V¨n Vþ i.Danh mục rà soát trong kỹ nghệ hệ thống „ Danh mục rà soát trong kỹ nghệ hệ thống (tiếp): a) Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa? b) Khả năng lựa chọn đã là tốt nhất chưa? c) Giải pháp này có khả thi kỹ thuật không? d) Có sự hoà hợp giữa các phần tử của hệ thống hay chưa? e) Cơ chế kiểm chứng & thẩm duyệt đã được thiết lập hay chưa? 2005 Bộ môn CNFM – ĐH Công nghệ 62 NguyÔn V¨n Vþ k. 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ệ 63 NguyÔn V¨n Vþ k. 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ệ 64 NguyÔn V¨n Vþ k. 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ệ 65 NguyÔn V¨n Vþ k. Danh mục rà soát lập kế hoạch 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ệ 66 NguyÔn V¨n Vþ 4. 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ệ 67 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 a. Nhiệm vụ rà soát yêu cầu - 2005 Bộ môn CNFM – ĐH Công nghệ 68 NguyÔn V¨n Vþ a. Danh mục rà soát phân tích yêu cầu - ■ 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ệ 69 NguyÔn V¨n Vþ a. 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ệ 70 NguyÔn V¨n Vþ b. Rà soát thiết kế phần mềm - ■ Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung vào: ƒ thiết kế kiến trúc, ƒ Thiết kế giao diện ƒ thiết kế dữ liệu, ƒ thiết kế thủ tục. ■ Có 2 mức rà soát thiết kế (phù hợp với 2 bước triển khai): ƒ rà soát thiết kế sơ bộ - preliminary design review (đánh giá việc dịch các yêu cầu thành thiết kế chính), ƒ rà soát thiết kế trọn vẹn - design walkthrough (tập trung vào tính đúng đắn của thuật toán, giao diện cấu trúc DL). 2005 Bộ môn CNFM – ĐH Công nghệ 71 NguyÔn V¨n Vþ b1. Tiến trình thiết kế theo quản lý - thiết kế kiến trúc, hệ con khía cạnh quản lý Tiến trình thiết kế nhìn theo các cách khác nhau Thiết kế chi tiết Thiết kế sơ bộ thiết kế dữ liệu thiết kế giao diện thiết kế thủ tục khía cạnh kỹ thuật Thiết kế lôgic Thiết kế vật lý 2005 Bộ môn CNFM – ĐH Công nghệ 72 NguyÔn V¨n Vþ b2. Tiến trình thiết kế theo kỹ thụật - Đặc tả các yêu cầu kiến trúc hệ thốngthiết kế kiến trúc đặc tả trừu tượng thiết kế giao diện thiết kế thành phần thiết kế cấu trúc dữ liệu thiết kế thuật toán đặc tả phần mềm đặc tả giao diện đặc tả thành phần đặc tả cấu trúc dữ liệu đặc tả thuật toán 2005 Bộ môn CNFM – ĐH Công nghệ 73 NguyÔn V¨n Vþ b2. Định hướng rà soát thiết kế - Mục tiêu: Hướng đến thiết kế đảm bảo hai yêu cầu: ■ Phản ánh đúng các yêu cầu đặc tả ƒ Đủ các phần ƒ Đủ chức năng và ràng buộc ƒ Dữ liệu đủ, phù hợp ■ Có chất lượng tốt ƒ Cấu trúc tốt (phân hoạch, giao diện, mô đun hóa) ƒ Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu) ƒ Dữ liệu tốt (cấu trúc, biểu diễn) ƒ Có thể lần vết được (dẽ hiểu, dễ kiểm tra) 2005 Bộ môn CNFM – ĐH Công nghệ 74 NguyÔn V¨n Vþ b3. Rà soát danh mục thiết kế sơ bộ - a) Các yêu cầu phần mềm có được phản ánh trong kiến trúc phần mềm hay không? b) Có đạt được sự môđun hoá hiệu quả không? c) Các môđun có độc lập chức năng hay không? d) Kiến trúc chương trình có được phân tách cấu trúc không? e) Các giao diện đã được xác định cho các môđun và các phần tử hệ thống ngoại lai chưa? 2005 Bộ môn CNFM – ĐH Công nghệ 75 NguyÔn V¨n Vþ b3. Rà soát danh mục thiết kế sơ bộ (t) - f) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa? g) Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa? h) Khả năng bảo trì đã được xem xét chưa? i) Các nhân tố chất lượng đã được đánh giá rõ ràng chưa? 2005 Bộ môn CNFM – ĐH Công nghệ 76 NguyÔn V¨n Vþ - b4. Rà soát danh mục thiết kế toàn bộ(t) a) Thuật toán có hoàn thành chức năng mong muốn không? thuật toán có đúng đắn logic không? b) Độ phức tạp logic có phải chăng hay không? c) Giao diện có phù hợp với thiết kế kiến trúc không? d) Xử lý lỗi đã được đặc tả chưa? e) Cấu trúc dữ liệu cục bộ có thật sự đã được xác định? f) Nguyên lý lập trình cấu trúc đã xuyên suốt chưa? 2005 Bộ môn CNFM – ĐH Công nghệ 77 NguyÔn V¨n Vþ . - i) Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa? j) Dùng hệ điều hành hay là dùng các đặc trưng độc lập ngôn ngữ? k) Có dùng logic component hoặc logic inverse? l) Khả năng bảo trì đã được xét tới chưa? b4. Rà soát danh mục thiết kế toàn bộ(t) 2005 Bộ môn CNFM – ĐH Công nghệ 78 NguyÔn V¨n Vþ c. Rà soát kỹ thuật chính thức khâu lập mã - ■ Mục tiêu: rà soát hướng đến mã nguồn đạt được ƒ Phản ánh đầy đủ, phù hợp với thiết kế ƒ Phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp, khai báo dữ liệu,..) ƒ Văn bản chương trình tốt (không lỗi chính