Bài giảng Bảo đảm chất lượng phần mềm và kiểm thử

§¹i häc Quèc gia Hμ néi - §¹i häc c«ng nghÖ Bé m«n C«ng nghÖ phÇn mÒm BÀI GiẢNG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM VÀ KiỂM THỬ NguyÔn V¨n Vy Email: vynv@coltech.vnu.vn, mobile: 0912.505.291 Hà nội - 2005 2005 Bộ môn CNFM – Đại học Công nghệ 2 NguyÔn V¨n Vþ THẨM ĐỊNH VÀ XÁC MINH Phần III 2005 Bộ môn CNFM – Đại học Công nghệ 3 NguyÔn V¨n Vþ „ Các loại kiểm thử „ Thẩm định và xác minh Nội dung – Tài liệu ™ Roger S. Pressman. Software Engineering, a Practitioner’s Approach. 3th Edition, McGraw-Hill, 1992, Bản dich của Ngô Trung vIệt, Phần 4, tập 4 (Chương 17, 18, 23 –bản 2001) ™ Ian Sommerville. Software Engineering, Sixth Edition, Addion Wesley, 2001, Phần 5 và 6. chương 20 ™ E.M.Bennatan, Software Project Management : a practitioner’s approach, McGRAW-HILL Book Company, 2001 ™ Nguyễn Văn Vỵ, Nguyễn Việt Hà. Giáo trình kỹ nghệ phần mềm, Đại học Công nghệ, ĐHQGHN, 2006. 2005 Bộ môn CNFM – Đại học Công nghệ 4 NguyÔn V¨n Vþ g1. Khái niệm kiểm thử hệ thống ‰ Hệ thống dựa trên máy tính do nhiều bên xây dựng, người phát triển phần mềm chỉ là một ‰ Việc kiểm thử hệ thống dễ có nguy cơ các bên tham gia “đổ lỗi cho nhau”. ‰ Những sai có thể nảy sinh từ: • Các dữ liệu qua giao diện của các thành phần được kiểm thử • Đường xử lý liên kết các thành phần • Sự tích hợp lỗi từ các thành phần khác nhau • Những hạn chế khác đến năng lực do ảnh hưởng từ các thành phân: chịu lỗi, an toàn, thực thi g. Kiểm thử hệ thống 2005 Bộ môn CNFM – Đại học Công nghệ 5 NguyÔn V¨n Vþ ‰ Yêu cầu đặt ra: • mô phỏng các dữ liệu xấu & các sai tiềm tàng tại giao diện phần mềm. • Kiểm thử kết quả của mỗi đường liên kết • Báo cáo các kết quả kiểm thử phân định từng phần, từng loại làm chứng cứ phòng ngừa đổ lỗi cho nhau. • Việc hoạch định và thiết kế các ca kiểm thử hệ thống theo những cách nhìn khác nhau sao cho bảo đảm phần mềm được kiểm thử đầy đủ, chính xác các loại yêu cầu g1. Khái niệm về kiểm thử hệ thống 2005 Bộ môn CNFM – Đại học Công nghệ 6 NguyÔn V¨n Vþ g2. Mô hình kiểm thử hệ thống Dữ liệu qua giao diện có thể sai, gây sai, phóng đại sai sai? Phóng đại sai? Gây sai? sai? 2005 Bộ môn CNFM – Đại học Công nghệ 7 NguyÔn V¨n Vþ g3. Các loại kiểm thử hệ thống 1. Kiểm thử chức năng (mức hệ thống) 2. Kiểm thử phục hồi (chịu lỗi) 3. Kiểm thử an ninh (sức chịu tấn công) 4. Kiểm thử thi hành (thông suốt, kịp thời) 5. Kiểm thử chịu tải (qui mô, giá trị nhạy cảm) 2005 Bộ môn CNFM – Đại học Công nghệ 8 NguyÔn V¨n Vþ g4. Kiểm thử chức năng mức hệ thống ‰ Chức năng mức hệ thống bao gồm các chức năng giao diện, các chức năng mức người dùng hay đầu ra cuối cùng khỏi hệ thống ‰ Các chức năng này thường mang tính tích hợp. Nên sau khi phát hiện sai phải quay lại kiểm thử từng phần cấu thành trước nó ‰ Các giao diện (người dùng, hệ thống) được xem như điểm phân định giữa các phần để kiểm thử 2005 Bộ môn CNFM – Đại học Công nghệ 9 NguyÔn V¨n Vþ † Nhiều hệ thống cần phải phục hồi sau lỗi, để tiếp tục xử lý trong một thời gian đã đặc tả trước, có thể: „ hệ thống cần thứ lỗi: nghĩa là xử lý lỗi bắt buộc không được làm ngừng hoạt động của toàn hệ thống. „ lỗi phải được khắc phục dần theo chu kỳ đã đặc tả. † kiểm thử phục hồi là bắt phần mềm phải thất bại để xem khả năng phục hồi của nó đến đâu. † Độ tin cây là một độ đo đánh giá khả năng phục hồi g4. Kiểm thử phục hồi 2005 Bộ môn CNFM – Đại học Công nghệ 10 NguyÔn V¨n Vþ Có 2 cách phục hồi: ‰ Phục hồi tự động: bằng khởi động lại (cơ chế checkpoint). Sau khi phục hồi dữ liệu, hệ thống tự tiếp tục hay khởi động lại thì được đánh giá là đúng đắn. ‰ Phục hồi có sự can thiệp của con người. Lúc này cần đánh giá thời gian trung bình để sửa chữa trong giới hạn cho phép hay không? g4. Kiểm thử phục hồi 2005 Bộ môn CNFM – Đại học Công nghệ 11 NguyÔn V¨n Vþ ‰ Là kiểm tra mọi cơ chế bảo vệ được xây dựng trong hệ thống xem có đạt hiệu quả đề ra trước các đột nhập hay không? ‰ Xét tất cả các loại đột nhập có thể “trước mặt”, “ngang xườn” và “sau lưng”. ‰ Khi thử nghiệm an ninh, người kiểm thử sẽ đóng vai trò của kẻ đột nhập. g5. Kiểm thử an ninh 2005 Bộ môn CNFM – Đại học Công nghệ 12 NguyÔn V¨n Vþ † Về nguyên tắc: Mọi đột nhập là có thể nếu đủ thời gian và nguồn lực. † Bài toán thiết kế hệ thống an ninh đặt ra là: „ làm cho việc đột nhập tốn phí nhiều hơn giá trị thu được do đột nhập „ Công sức bỏ ra xây dựng công cụ bảo vệ phải ít hơn giá trị mất đi nếu bị đột nhập Chi phí công cụ bảo vệ < lợi ich do bảo vệ khỏi đột nhập Chi phí để đột nhập > lợi ích thu được từ đột nhập g5. Kiểm thử an ninh 2005 Bộ môn CNFM – Đại học Công nghệ 13 NguyÔn V¨n Vþ ‰ Các kỹ thuật hộp trắng và hộp đen được dùng để đánh giá chức năng và sự thi hành của chương trình ở mức bình thường. ‰ Kiểm thử chịu tải là vận hành hệ thống khi sử dụng nguồn lực với số lượng, tần suất và cường độ dị thường. ‰ Một loại khác của thử nghiệm áp lực là kiểm thử độ nhạy: cố gắng làm bộc lộ các tổ hợp dữ liệu (lớp dữ liệu vào có hiệu lực) hay sự kiện mà có thể gây ra việc xử lý không ổn định hoặc không chính xác. g6. Kiểm thử chịu tải 2005 Bộ môn CNFM – Đại học Công nghệ 14 NguyÔn V¨n Vþ ‰ Với hệ nhúng & hệ thời gian thực, phần mềm cung cấp chức năng nhưng không phù hợp với các yêu cầu thi hành đều là không chấp nhận được. ‰ kiểm thử thi hành được thiết kế để kiểm thử việc vận hành (run-time) của phần mềm khi hệ thống được tích hợp. ‰ kiểm thử thi hành xuất hiện trong tất cả các bước của quá trình kiểm thử, tuy nhiên chỉ khi tất cả các phần tử của hệ thống đã được tích hợp thì kiểm thử mới thực sự là chắc chắn. ‰ Việc thi hành đúng bao gồm cả số lượng, chất lượng (hoạt động và hiệu năng) g7. Kiểm thử thi hành 2005 Bộ môn CNFM – Đại học Công nghệ 15 NguyÔn V¨n Vþ † Thường gắn liền với kiểm thử áp lực vì cả hai thường đòi hỏi các dụng cụ phần cứng và phần mềm chuyên dụng. Vì cần đo sự tổng hợp nguồn lực (trong, ngoài) và Nhờ dụng cụ ngoại lai để giám sát các khoảng vận hành, các sự kiện ngắt (log) khi nó xuất hiện, có thể lấy mẫu các trạng thái máy. † Có thể làm bộc lộ các tình thế dẫn đến sự suy giảm hiệu năng hoặc thất bại hệ thống tiềm ẩn. g7. Kiểm thử thi hành 2005 Bộ môn CNFM – Đại học Công nghệ 16 NguyÔn V¨n Vþ h1. Khái niệm kiểm thử chấp nhận ‰ Kết thúc kiểm thử tích hợp, phần mềm đã được lắp ráp trong một gói, các sai giao diện đã chỉnh sửa, Các kiểm thử cuối cùng bắt đầu - kiểm thử chấp nhận hay thẩm định (acceptation/validation testing) ‰ Thẩm định là thắng lợi nếu các chức năng phần mềm ở một chừng mức nào đó là thoả mãn sự mong đợi hợp lý của người đặt hàng ‰ Mục tiêu thẩm định: xem phần mềm có đáp ứng được yêu cầu khách hàng không? h. Kiểm thử chấp nhận- thẩm định 2005 Bộ môn CNFM – Đại học Công nghệ 17 NguyÔn V¨n Vþ ‰ Cái “mong đợi hợp lý” của khách hàng thể hiện: • Trong Đặc tả yêu cầu phần mềm bao gồm cả mô tả được gọi là tiêu chuẩn kiểm thử phần mềm • Thông qua đánh giá trực tiếp khi sử dụng ‰ Thẩm định phần mềm được thực hiện thông qua một loạt các kiểm thử hộp đen để thuyết minh sự phù hợp của nó với các yêu cầu. h1. Khái niệm kiểm thử chấp nhận 2005 Bộ môn CNFM – Đại học Công nghệ 18 NguyÔn V¨n Vþ † Một kế hoạch phác ra những lớp kiểm thử cần tiến hành và một thủ tục kiểm thử xác định các ca kiểm thử sẽ thực hiện để thuyết minh sự phù hợp với các yêu cầu. † Cả kế hoạch & thủ tục được thiết kế để bảo đảm rằng: „ Tất cả các yêu cầu được thoả mãn, „ Các yêu cầu thi hành đã chính xác, „ Tài liệu đúng đắn và „ Các yêu cầu khác là thoả đáng. h1. Khái niệm kiểm thử chấp nhận 2005 Bộ môn CNFM – Đại học Công nghệ 19 NguyÔn V¨n Vþ † Sau mỗi ca kiểm thử, phần mềm ở vào một trong hai trường hợp sau: „ Các đặc tính chức năng hoặc sự thực hiện phù hợp với đặc tả và được chấp nhận. „ Các lệch lạc so với đặc tả và mong đợi được phát hiện và một danh sách các khiếm khuyết được tạo ra. Các sai sót không chỉnh sửa trong giai đoạn này. Thường phải thảo luận lại với khách hàng để thiết lập một phương pháp giải quyết các sai lệch này. h2. Tiêu chuẩn kiểm thử thẩm định 2005 Bộ môn CNFM – Đại học Công nghệ 20 NguyÔn V¨n Vþ † Người phát triển không thể đoán trước được khách hàng thực sự dùng một chương trình như thế nào: „ Các chỉ dẫn sử dụng có thể bị hiểu lầm. „ Các tổ hợp dữ liệu lạ có thể bị sử dụng định kỳ. „ Đầu ra là rõ ràng đối với người kiểm thử nhưng có thể lại khó hiểu đối với người dùng. h3. Kiểm thử Alpha và Beta 2005 Bộ môn CNFM – Đại học Công nghệ 21 NguyÔn V¨n Vþ ‰ Khi các phần mềm dành cho 1 người đặt hàng, thì hoạt động kiểm thử chỉ được 1 khách hàng tiến hành để thẩm định mọi yêu cầu. ‰ Tiến hành kiểm thử này do người sử dụng đầu cuối thực hiện, không phải là người đặt hàng. ‰ Kiểm thử chấp nhận có thể tiến hành vài tuần hoặc vài tháng một lần, nhờ đó mà bộc lộ được các lỗi tích luỹ làm suy giảm hệ thống theo thời gian. h3.1. Kiểm thử Alpha & Beta 1 khách 2005 Bộ môn CNFM – Đại học Công nghệ 22 NguyÔn V¨n Vþ † Khi phần mềm dành cho nhiều người đặt hàng, thì kiểm thử chấp nhận bởi một khách hàng là không thực tế. Quá trình kiểm thử alpha và kiểm thử bêta cho nhiều người tiến hành là bắt buộc. Chỉ những người sử dụng đầu cuối mới có thể phát hiện được các sai cho lớp người dùng đa dạng. h3.2. Kiểm thử Alpha & Beta n khách 2005 Bộ môn CNFM – Đại học Công nghệ 23 NguyÔn V¨n Vþ † kiểm thử alpha được bên phát triển tiến hành: „ Phần mềm được người dùng thực hiện trong bối cảnh “tự nhiên” „ Người phát triển “nhòm qua vai” người sử dụng để báo cáo các sai và các vấn đề sử dụng (vì thế còn gọi là kiểm thử sau lưng). † kiểm thử alpha được tiến hành trong một môi trường được điều khiển (theo kế hoạch của người phát triển). † Dữ liệu cho kiểm thử Alpha thường là dữ liệu môphỏng h3.3. Kiểm thử Alpha 2005 Bộ môn CNFM – Đại học Công nghệ 24 NguyÔn V¨n Vþ † kiểm thử bêta được nhiều người đặt hàng tiến hành , không có mặt Người phát triển. † kiểm thử bêta là áp dụng trong môi trường thực, không có sự kiểm soát của người phát triển. † Khách hàng sẽ báo cáo tất cả các vấn đề (thực hoặc tưởng tượng) mà họ gặp trong quá trình kiểm thử cho người phát triển một cách định kỳ. † Theo các báo đó Người phát triển cải biên và chuẩn bị phân phối bản phát hành bản hoàn thiện cho toàn bộ những người đặt hàng. h3.4. Kiểm thử Beta 2005 Bộ môn CNFM – Đại học Công nghệ 25 NguyÔn V¨n Vþ ‰ Kết quả của kiểm thử thường mới chỉ ra lỗi và cho thấy những triệu chứng vấn đề của phần mềm. Nguyên nhân của lỗi hay vấn đề có thể chưa rõ: Biểu lộ bên ngoài của sai & nguyên nhân bên trong của sai có thể không có quan hệ rõ ràng. ‰ Kiểm thử thành công dẫn đến việc gỡ rối. Gỡ rối không phải là kiểm thử mà là tìm nguyên nhân gây lỗi để loại trừ lỗiÆ khác với kiểm thử i. Nghệ thuật gỡ rối (debugging) 2005 Bộ môn CNFM – Đại học Công nghệ 26 NguyÔn V¨n Vþ † Quá trình gỡ rối luôn dẫn tới hai khả năng: „ Tìm ra nguyên nhân, chỉnh sửa và khử được lỗi. „ Không tìm được nguyên nhân. Trường hợp này cần thiết kế một ca kiểm thử để giúp việc thẩm định nghi ngờ và như vậy công việc tìm sai lại dẫn đến tiếp tục kiểm thử như một vòng lặp. a. Tiến trình gỡ rối Kiểm thử Gỡ rối Khử lối Kiểm thử Lỗi Tìm ra nguyên nhân Không tìm ra nguyên nhân 2005 Bộ môn CNFM – Đại học Công nghệ 27 NguyÔn V¨n Vþ † Gỡ rỗi là khó khăn: „ Triệu chứng có thể xa nguyên nhân (về không gian). „ Triệu chứng có thể tạm thời biến mất khi có một sai khác được sửa. „ Triệu chứng có thể thực gây ra bởi sai của người dùng mà không dễ theo dõi được. „ Triệu chứng có thể là kết quả của vấn đề thời gian chứ không phải là vấn đề xử lý. b. Khó khăn của gỡ rối 2005 Bộ môn CNFM – Đại học Công nghệ 28 NguyÔn V¨n Vþ ■ Có thể khó tái thể hiện các điều kiện đầu vào (ứng dụng thời gian thực, thứ tự đầu vào không xác định). ■ Triệu chứng có thể là bị gián đoạn (các hệ nhúng với liên kết phần cứng và phần mềm không tháo rời được). ■ Triệu chứng có thể do các nguyên nhân được phân tán trong một số các nhiệm vụ chạy trên các bộ xử lý khác nhau. b. Khó khăn của gỡ rối 2005 Bộ môn CNFM – Đại học Công nghệ 29 NguyÔn V¨n Vþ ‰ Nhiều bằng chứng cho rằng tài gỡ lỗi là bẩm sinh của con người. ‰ Người này thì giỏi gỡ rối, kẻ khác lại không; và rất khó dạy và khó học gỡ rối. ‰ Tuy nhiên người ta cũng đã có vài đề xuất phương cách gỡ rối. c. Vấn đề tâm lý trong gỡ lỗi 2005 Bộ môn CNFM – Đại học Công nghệ 30 NguyÔn V¨n Vþ ‰ Nói chung có 3 lựa chọn cách gỡ rối: „ Vũ dũng vô mưu. „ Lần theo vết cũ. „ Loại trừ dần các nguyên nhân. d. Các cách thức gỡ rối 2005 Bộ môn CNFM – Đại học Công nghệ 31 NguyÔn V¨n Vþ † Phương cách vũ dũng vô mưu là cách chung nhất, nhưng lại ít hiệu quả nhất; Chỉ áp dụng phương sách này khi không còn cách nào khác. † Triết lý “hãy để cho máy tính tìm ra sai”: xem xét tất cả, ghi lại tất cả với hy vọng tìm ra trong đống thông tin khổng lồ đó cái nguyên nhân của sai! † Một cách nghĩ thô thiển, thường không khả thi d1. Phương cách vũ dũng vô mưu 2005 Bộ môn CNFM – Đại học Công nghệ 32 NguyÔn V¨n Vþ † Phương cách lùi theo vết cũ cũng là ít thông dụng, và có thể dùng thắng lợi trong các chương trình nhỏ. † Bắt đầu lần ngược từ chỗ có triệu chứng sai trong mã nguồn (bằng tay!) cho tới khi định vị được sai. † Khi số dòng lệnh tăng lên thì số con đường đi ngược có thể nhiều đến mức không quản lý nổi. d2. Phương cách lần theo vết cũ 2005 Bộ môn CNFM – Đại học Công nghệ 33 NguyÔn V¨n Vþ † Cách làm: tổ chức lại dữ liệu liên quan đến xuất hiện sai để cô lập nguyên nhân tiềm ẩn. † Một giả thiết nguyên nhân được đưa ra từ dữ liệu trên được dùng để chứng tỏ hoặc phản chứng giả thiết đó. một danh sách các nguyên nhân tiềm ẩn được vạch ra và các kiểm thử được tiến hành để loại trừ các nguyên nhân trong danh sách đó. † Nếu kiểm thử chỉ ra một nguyên nhân nào đó có hứa hẹn thì tinh chế tiếp dữ liệu liên quan để cô lập lỗi d3. Phương cách loại trừ nguyên nhân 2005 Bộ môn CNFM – Đại học Công nghệ 34 NguyÔn V¨n Vþ † Mỗi khi tìm thấy lỗi thì phải chỉnh sửa. Nhưng sửa một sai có thể gây ra sai khác. Làm sao để sửa triệt để? † Trước khi sửa nên tự hỏi để tìm giải pháp: „ Nguyên nhân này có thể sinh ra ở phần khác của chương trình hay không? (trong nhiều tình thế, một khiếm khuyết chương trình có thể gây ra một mẫu sai logic mà nó có thể được sinh ra ở một nơi khác). d3. Phương cách loại trừ nguyên nhân 2005 Bộ môn CNFM – Đại học Công nghệ 35 NguyÔn V¨n Vþ „ Lỗi nào có thể được sinh ra tiếp? Trước khi chỉnh sửa nên xét lại mã nguồn (tốt hơn hết là xét lại thiết kế) để đánh giá sự gắn kết giữa logic và cấu trúc dữ liệu. „ Làm gì để ngăn cản lỗi này ngay từ chỗ đầu tiên? (thường có nhiều giải pháp để nhà thiết kế lựa chọn). d3. Phương cách loại trừ nguyên nhân 2005 Bộ môn CNFM – Đại học Công nghệ 36 NguyÔn V¨n Vþ † Quản lý cấu hình phần mềm „ Là tập các hoạt động để quản lý các thay đổi của phần mềm trong suốt vòng đời của nó. „ Là một loại hoạt động bảo đảm chất lượng phần mềm, được áp dụng cho tất cả các pha kỹ nghệ „ Bao trùm suốt tiến trình phát triển và tiến hóa của phần mềm. Quản lý cầu hình (software configuration management - SCM): 2005 Bộ môn CNFM – Đại học Công nghệ 37 NguyÔn V¨n Vþ † Nội dung quản lý cấu hình phần mềm bao gồm: „ Xác định các thay đổi. „ Kiểm soát các thay đổi. „ Bảo đảm các thay đổi được thực hiện. „ Báo cáo các thay đổi cho người quan tâm. a. Nội dung quản lý cầu hình 2005 Bộ môn CNFM – Đại học Công nghệ 38 NguyÔn V¨n Vþ †Quản lý cấu hình khác bảo trì phần mềm: „ Bảo trì phần mềm là các hoạt động kỹ nghệ xuất hiện sau khi phân phối phần mềm và đi vào hoạt động. „ Quản lý cấu hình phần mềm là các hoạt động theo dõi và kiểm soát, từ khi bắt đầu dự án phát triển phần mềm và chỉ kết thúc khi phần mềm không hoạt động nữa. b. Phân biệt với bảo trì 2005 Bộ môn CNFM – Đại học Công nghệ 39 NguyÔn V¨n Vþ † Kết quả của tiến trình kỹ nghệ phần mềm là các thông tin có thể được chia thành 3 loại: „ Các chương trình máy tính (cả mức nguồn và mức chạy được). „ Các tài liệu mô tả chương trình máy tính (nhắm đến cả những người thực hành kỹ thuật lẫn những người dùng). „ Các cấu trúc dữ liệu (cả bên trong và ngoài chương trình). c. Thành phần của phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 40 NguyÔn V¨n Vþ † Các khoản mục cấu thành lên các thành phần phần mềm được tạo ra như là những chế tác (artifact) của tiến trình kỹ nghệ phần mềm được tập hợp lại trong một cái tên chung gọi là cấu hình phần mềm. † Các chế tác này có nhiều mức khác nhau: „ Bộ phận - tổng thể (phạm vi) „ Chưa hoàn thiện – hoàn thiện (theo tiến trình, chất lượng) „ Ở các mức tiến hóa khác nhau (các phiên bản – version) d. Cầu hình phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 41 NguyÔn V¨n Vþ † Đường mốc giới (baseline) là khái niệm được đặt ra: ■ Trước mốc giới, cấu hình có thể thay đổi nhanh chóng và không chính thức. ■ Sau mốc giới, cần các thủ tục đặc biệt và chính thức để đánh giá và kiểm soát sự thay đổi cấu hình. † Đường mốc giới để đánh dấu việc cập nhật hay phân phát 1 vài khoản mục cấu hình phần mềm. † Tại đường mốc, các khoản mục cấu hình phần mềm lần đầu được đưa vào cơ sở dữ liệu dự án hay được lấy ra sửa đổi và sẽ được cập nhật trở lại e. Công cụ quản lý cấu hình 2005 Bộ môn CNFM – Đại học Công nghệ 42 NguyÔn V¨n Vþ e. Công cụ quản lý cấu hình Đường mốc giới 4 5 3 2 1 5…..... 4…..… 3…..… 2…..… 1….….Entry ? ? ? Check in Check out Chế tác dự án cấu hình được quản lý 5 5 2005 Bộ môn CNFM – Đại học Công nghệ 43 NguyÔn V¨n Vþ † Đặc tả hệ thống (system specification) † Kế hoạch dự án phần mềm (project baseline) † Đặc tả yêu cầu (software riquirements) : ƒ Đặc tả yêu cầu phần mềm. ƒ Nguyên mẫu thi hành được hoặc nguyên mẫu “giấy tờ” ƒ Sổ tay sử dụng sơ cấp f. Các khoản mục cấu hình phần mềm (software configuration items - sci) 2005 Bộ môn CNFM – Đại học Công nghệ 44 NguyÔn V¨n Vþ † Các đặc tả thiết kế (design specification) : ƒ dữ liệu (data design). ƒ kiến trúc (architectural design). ƒ Môđun (modul design). ƒ giao diện (inteface design). ƒ đối tượng (objject design - nếu dùng kỹ thuật hướng đối tượng) f. Các khoản mục cấu hình phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 45 NguyÔn V¨n Vþ † Mã nguồn (source code) và kiểm thử (test): ƒ Kế hoạch và thủ tục kiểm thử . ƒ Các ca kiểm thử & các kết quả được ghi lại. ƒ Các sổ tay vận hành & sổ tay lắp đặt. ƒ Chương trình thi hành được. ƒ Các môđun & mã thi hành được ƒ Các môđun đã liên kết f. Các khoản mục cấu hình phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 46 NguyÔn V¨n Vþ † Mô tả cơ sở dữ liệu ƒ Lược đồ & cấu trúc các file ƒ Nội dung hồ sơ ban đầu † Sổ tay người sử dụng † Các tài liệu bảo trì ƒ Các báo cáo những vấn đề phần mềm ƒ Các yêu cầu bảo trì ƒ Đặt thay đổi kỹ nghệ ƒ Các chuẩn & các thủ tục cho kỹ nghệ phần mềm. f. Các khoản mục cấu hình phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 47 NguyÔn V¨n Vþ † Trách nhiệm nguyên thuỷ của quản lý cấu hình phần mềm là kiểm soát các thay đổi † Sau này thêm các trách nhiệm: „ Xác định các khoản mục cấu hình, các version của phần mềm; „ kiểm toán cấu hình phần mềm nhằm bảo đảm phần mềm đã được phát triển đúng và „ báo cáo mọi thay đổi đã được áp dụng cho cấu hình đó. g. Sự hình thành quản lý cấu hình 2005 Bộ môn CNFM – Đại học Công nghệ 48 NguyÔn V¨n Vþ † 5 nhiệm vụ cụ thể quản lý cấu hình phần mềm: „ Xác định cấu hình „ kiểm soát version „ kiểm soát đổi thay, „ kiểm toán cấu hình, „ báo cáo thay đổi. † Mọi cuộc thảo luận về quản lý cấu hình phần mềm cần đưa ra các câu hỏi: h. Nhiệm vụ quản lý cấu hình 2005 Bộ môn CNFM – Đại học Công nghệ 49 NguyÔn V¨n Vþ 1. Làm thế nào để tổ chức xác định và quản lý được nhiều version của chương trình sao cho có thể thay đổi nó để thích nghi 1 cách hiệu quả? 2. Làm thế nào