Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm - Nguyễn Anh Hào
Số trang: 30
Loại file: pdf
Dung lượng: 2.36 MB
Lượt xem: 28
Lượt tải: 0
Xem trước 3 trang đầu tiên của tài liệu này:
Thông tin tài liệu:
Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm trình bày nội dung về cách làm phần mềm, nhìn từ SE, Mô hình phát triển phần mềm, Mô hình thác nước (tuyến tính), Mô hình làm mẫu thử (mô hình lặp), Mô hình xoắn ốc (mô hình tiến hóa), Mô hình hợp nhất (UP/RUP). Mời các bạn tham khảo nội dung chi tiết.
Nội dung trích xuất từ tài liệu:
Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm - Nguyễn Anh Hào 1 SW Quality Assurance 04. Verification (kiểm soát cách làm) Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM 2 A.Cách làm phần mềm, nhìn từ SE Yêu cầu Yêu cầu 1 •Cách làm phải •Phối hợp các được chi tiết bước như thế 2 thành từng bước nào để tạo ra để kiểm soát. phần mềm ? 3 Phần mềm Phần mềm 1. Cách làm có gây ra errors, faults ? hạn chế bằng cách nào ? 2. Sản phẩm có thỏa mãn yêu cầu ? Mô hình phát triễn PM Mô hình phát triễn phần mềm là một khuông mẫu cho một tập hợp các công đoạn (từng bước) liên kết nhau để hướng dẫn cho người phát triễn xác định được cách làm ra phần mềm (kế hoạch) có kiểm soát (hạn chế sai sót). Phần mềm không dùng một lần; nó phải được sử dụng lâu dài, và phải phát triễn theo yêu cầu của người sử dụng, đo đó cách làm PM phải hổ trợ cho các thay đổi * lên PM. Như vậy, có 2 mục tiêu chính mà các mô hình hướng đến: 1. Chuyễn giao PM đạt chất lượng (thoả mãn yêu cầu) 2. Tạo điều kiện thuận lợi cho phần mềm phát triễn liên tục sau khi chuyển giao (ie, làm thêm, không làm lại) * Hổ trợ thay đổi trong cách làm PM Sự thay đổi của PM là sự sửa đổi trên các phiên bản ấn phẩm của phần mềm (bản đặc tả yêu cầu, thiết kế, mã nguồn,…) Quá trình phát triễn PM thực chất là quá trình nhận biết và thực hiện các thay đổi cần thiết cho các ấn phẩm đang sử dụng; trong đó, một dự định thay đổi cần được xem xét từ nhiều khía cạnh để hướng đến chất lượng, ví dụ: 1. Nó gây ra sự khác biệt gì so với mong đợi ? (ie, vai trò) 2. Nó có đáng làm hay không ? (lợi ích/thiệt hại) 3. Nó được hiện thực vào PM như thế nào ? (khó hay dể) Sự xem xét để thực hiện các thay đổi đưa đến nhu cầu trao đổi thông tin để chia sẽ kiến thức hoặc kinh nghiệm, và cần có công nghệ (công cụ) hổ trợ . Các mô hình làm phần mềm hướng đến hổ trợ sử dụng các loại nguồn lực này. 1970 Mô hình thác nước (tuyến tính) (Users) Có ấn phẩm sau từng công đoạn do người phát triễn tạo ra và (Developers) chuyển giao. Khảo sát Người sử dụng chỉ tiếp cận được với ấn phẩm Phân tích cuối cùng sau khi nó đã được làm theo yêu cầu Thiết kế ban đầu. Hiện thực kiểm thử Sửa lại (rework) Bảo trì (Users) 1960 Mô hình làm mẫu thử (mô hình lặp) Yêu cầu Tạo mẫu (User) (Developer) Mẫu ban Mẫu đã cải tiến đầu Người sử dụng điều kiểm thử mẫu Cải tiến mẫu khiển quá trình phát (User) (Developer) triễn mẫu, dựa trên yêu Mẫu cầu và kết quả thực hoàn hiện yêu cầu (mẫu). chỉnh Yêu cầu cải tiến mẫu Ứng dụng Mô hình không yêu cầu mẫu tạo ra các bản đặc tả cho PM để bảo trì sau này. 1986 Mô hình xoắn ốc (mô hình tiến hóa) Planning Customer Risks Lập kế hoạch Communication Yêu cầu & các thay đổi Ước lượng rủi ro Tạo mẫu thử Kiểm tra Đánh giá Xây dựng Thiết kế Customer Design Evaluation Cài đặt Construction Đặc điểm của mô hình xoắn ốc Kết hợp giữa thác nước và làm mẫu thử Mô hình thác nước: Hổ trợ nhóm người phát triễn hệ thống cùng làm việc chung với nhau trên các tài liệu đặc tả. Mô hình mẫu thử: người sử dụng tham gia tư vấn & kiểm tra cho quá trình phát triễn sản phẩm. Hổ trợ cho nhận thức từ bản chất đến chi tiết (từ bất biến đến tùy biến) Cho phép cập nhật ấn phẩm của mỗi công đoạn ở chu kỳ trước, thay vì phải tạo mới Cho phép tiếp tục phát triễn phần mềm trong giai đoạn ứng dụng. 2000~ Mô hình hợp nhất (UP/RUP) 2003 Tài liệu chuyển giao từ chu kỳ trước Introduction to RUP. pdf 10 Các giai đoạn của mô hình UP/RUP Có 4 giai đoạn chính để tạo ra 1 phiên bản PM Inception : xác định vai trò của PM Elaboration: đặc tả chi tiết (yêu cầu) cho PM Construction: thiết kế giải pháp & hiện thực PM Transistion : chuyển giao sử dụng phiên bản đã làm Mỗi giai đoạn gồm có một vài chu kỳ phát triễn Mỗi chu kỳ là một chuổi hành động củng cố cho những đặc tả về PM bằng cách liên kết chúng với thực tế. Mỗi chu kỳ có thể dùng mô hình thác nước/mẫu thử/hướng đối tượng,… ; kết thúc bằng một mẫu thử (hoặc phần mềm) cho những người sử dụng (hoặc stack-holders) cùng nhau đánh giá hoặc sử dụng. 11 Các luồng công việc trong UP/RUP UP có 2 loại luồng công việc (work-flow): tạo ấn phẩm (6 luồng đầu) và hổ trợ tạo ấn phẩm (3 luồng cuối). M ...
Nội dung trích xuất từ tài liệu:
Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm - Nguyễn Anh Hào 1 SW Quality Assurance 04. Verification (kiểm soát cách làm) Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM 2 A.Cách làm phần mềm, nhìn từ SE Yêu cầu Yêu cầu 1 •Cách làm phải •Phối hợp các được chi tiết bước như thế 2 thành từng bước nào để tạo ra để kiểm soát. phần mềm ? 3 Phần mềm Phần mềm 1. Cách làm có gây ra errors, faults ? hạn chế bằng cách nào ? 2. Sản phẩm có thỏa mãn yêu cầu ? Mô hình phát triễn PM Mô hình phát triễn phần mềm là một khuông mẫu cho một tập hợp các công đoạn (từng bước) liên kết nhau để hướng dẫn cho người phát triễn xác định được cách làm ra phần mềm (kế hoạch) có kiểm soát (hạn chế sai sót). Phần mềm không dùng một lần; nó phải được sử dụng lâu dài, và phải phát triễn theo yêu cầu của người sử dụng, đo đó cách làm PM phải hổ trợ cho các thay đổi * lên PM. Như vậy, có 2 mục tiêu chính mà các mô hình hướng đến: 1. Chuyễn giao PM đạt chất lượng (thoả mãn yêu cầu) 2. Tạo điều kiện thuận lợi cho phần mềm phát triễn liên tục sau khi chuyển giao (ie, làm thêm, không làm lại) * Hổ trợ thay đổi trong cách làm PM Sự thay đổi của PM là sự sửa đổi trên các phiên bản ấn phẩm của phần mềm (bản đặc tả yêu cầu, thiết kế, mã nguồn,…) Quá trình phát triễn PM thực chất là quá trình nhận biết và thực hiện các thay đổi cần thiết cho các ấn phẩm đang sử dụng; trong đó, một dự định thay đổi cần được xem xét từ nhiều khía cạnh để hướng đến chất lượng, ví dụ: 1. Nó gây ra sự khác biệt gì so với mong đợi ? (ie, vai trò) 2. Nó có đáng làm hay không ? (lợi ích/thiệt hại) 3. Nó được hiện thực vào PM như thế nào ? (khó hay dể) Sự xem xét để thực hiện các thay đổi đưa đến nhu cầu trao đổi thông tin để chia sẽ kiến thức hoặc kinh nghiệm, và cần có công nghệ (công cụ) hổ trợ . Các mô hình làm phần mềm hướng đến hổ trợ sử dụng các loại nguồn lực này. 1970 Mô hình thác nước (tuyến tính) (Users) Có ấn phẩm sau từng công đoạn do người phát triễn tạo ra và (Developers) chuyển giao. Khảo sát Người sử dụng chỉ tiếp cận được với ấn phẩm Phân tích cuối cùng sau khi nó đã được làm theo yêu cầu Thiết kế ban đầu. Hiện thực kiểm thử Sửa lại (rework) Bảo trì (Users) 1960 Mô hình làm mẫu thử (mô hình lặp) Yêu cầu Tạo mẫu (User) (Developer) Mẫu ban Mẫu đã cải tiến đầu Người sử dụng điều kiểm thử mẫu Cải tiến mẫu khiển quá trình phát (User) (Developer) triễn mẫu, dựa trên yêu Mẫu cầu và kết quả thực hoàn hiện yêu cầu (mẫu). chỉnh Yêu cầu cải tiến mẫu Ứng dụng Mô hình không yêu cầu mẫu tạo ra các bản đặc tả cho PM để bảo trì sau này. 1986 Mô hình xoắn ốc (mô hình tiến hóa) Planning Customer Risks Lập kế hoạch Communication Yêu cầu & các thay đổi Ước lượng rủi ro Tạo mẫu thử Kiểm tra Đánh giá Xây dựng Thiết kế Customer Design Evaluation Cài đặt Construction Đặc điểm của mô hình xoắn ốc Kết hợp giữa thác nước và làm mẫu thử Mô hình thác nước: Hổ trợ nhóm người phát triễn hệ thống cùng làm việc chung với nhau trên các tài liệu đặc tả. Mô hình mẫu thử: người sử dụng tham gia tư vấn & kiểm tra cho quá trình phát triễn sản phẩm. Hổ trợ cho nhận thức từ bản chất đến chi tiết (từ bất biến đến tùy biến) Cho phép cập nhật ấn phẩm của mỗi công đoạn ở chu kỳ trước, thay vì phải tạo mới Cho phép tiếp tục phát triễn phần mềm trong giai đoạn ứng dụng. 2000~ Mô hình hợp nhất (UP/RUP) 2003 Tài liệu chuyển giao từ chu kỳ trước Introduction to RUP. pdf 10 Các giai đoạn của mô hình UP/RUP Có 4 giai đoạn chính để tạo ra 1 phiên bản PM Inception : xác định vai trò của PM Elaboration: đặc tả chi tiết (yêu cầu) cho PM Construction: thiết kế giải pháp & hiện thực PM Transistion : chuyển giao sử dụng phiên bản đã làm Mỗi giai đoạn gồm có một vài chu kỳ phát triễn Mỗi chu kỳ là một chuổi hành động củng cố cho những đặc tả về PM bằng cách liên kết chúng với thực tế. Mỗi chu kỳ có thể dùng mô hình thác nước/mẫu thử/hướng đối tượng,… ; kết thúc bằng một mẫu thử (hoặc phần mềm) cho những người sử dụng (hoặc stack-holders) cùng nhau đánh giá hoặc sử dụng. 11 Các luồng công việc trong UP/RUP UP có 2 loại luồng công việc (work-flow): tạo ấn phẩm (6 luồng đầu) và hổ trợ tạo ấn phẩm (3 luồng cuối). M ...
Tìm kiếm theo từ khóa liên quan:
Đảm bảo chất lượng phần mềm Bài giảng chất lượng phần mềm Mô hình phát triển phần mềm Mô hình thác nước Mô hình làm mẫu thử Mô hình xoắn ốc Mô hình hợp nhấtTài liệu liên quan:
-
Bài giảng Quản trị dự án: Bài 1 - Phần mềm
7 trang 118 0 0 -
Nghiên cứu chất lượng phần mềm: Phần 2
126 trang 83 0 0 -
Bài giảng Kiểm thử và đảm bảo chất lượng phần mềm: Chương 2
27 trang 57 0 0 -
BÀI 2. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
59 trang 41 0 0 -
Nghiên cứu chất lượng phần mềm: Phần 1
105 trang 40 0 0 -
Bài giảng Quản lý dự án: Chương 3 - Chu trình sống của một dự án phần mềm
53 trang 39 0 0 -
Phương pháp phát triển phần mềm linh hoạt
41 trang 37 0 0 -
Bài giảng Đảm bảo chất lượng phần mềm: Duy trì chất lượng - Nguyễn Anh Hào
20 trang 36 0 0 -
49 trang 35 0 0
-
9 trang 34 0 0