Bài giảng Đảm bảo chất lượng phần mềm: Đặc tả phần mềm - Nguyễn Anh Hào

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:20

Thêm vào BST

Báo xấu

39
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng Đảm bảo chất lượng phần mềm: Đặc tả phần mềm trình bày nội dung về định yêu cầu là gì, hai khía cạnh mô tả cho phần mềm, người sử dụng, làm phần mềm thoả mãn yêu cầu, các yếu tố tham gia đặc tả yêu cầu, các mô hình chất lượng của sản phẩm phần mềm,... Mời các bạn tham khảo nội dung chi tiết.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Đảm bảo chất lượng phần mềm: Đặc tả phần mềm - Nguyễn Anh Hào

1 SW Quality Assurance 02. Đặc tả phần mềm  Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM
2 Yêu cầu là gi ?  Yêucầu (requirements) là đặc tả cho những gì cần phải được hiện thực (được thoả mãn). đặc tả hành vi xử lý của phần mềm (functions) đặc tả các đặc tính của phần mềm (characteristics) đặc tả các ràng buộc đ/v cách thức phát triễn phần mềm (constraints).  Yêu cầu không tường minh (needs) là những mong muốn được cho là cần thiết, nhưng không được đặc tả.  Cả yêu cầu lẫn mong muốn đều góp phần quyết định chất lượng của phần mềm. Software_Requirements, 3rd edition, 2013.pdf: Page 6
3 2 khía cạnh mô tả cho PM 1. Người sử dụng cần nêu ra các yêu cầu đ/v PM để nó thoả mãn cho nhu cầu sử dụng của họ.  VD: đáng tin cậy (reliability)|user là PM cho kết quả chính xác trong mọi tình huống. 2. Nhà phát triễn cần biết các chức năng và đặc tính được mong đợi từ PM để làm ra nó.  ie. developers cần biết  Yêu cầu chức năng (functional requirements)  Yêu cầu đặc tính (non-functional requirements)  Ví dụ : yếu tố đáng tin cậy|user được developer hiểu là nhất quán (consistency), chịu đựng được hư hỏng (fault tolerance) & chính xác (accuracy), là những thuộc tính cố hữu của PM mà developer có thể kiễm soát được.
4 Làm PM thoả mãn yêu cầu (1)  Thông thường, nhà phát triễn sẽ phiên dịch yêu cầu và mong muốn của người sử dụng thành đặc tả chức năng và đặc tính của phần mềm sẽ xây dựng. Vấn đề là:  Liệu các yêu cầu từ users có đủ để làm ra phần mềm có chất lượng ?  Ie, đôi khi user không nói ra nhưng devs phải biết.  Cácđặc tính chất lượng được yêu cầu từ users được hiểu như thế nào cho đúng để cài đặt ?  Hiểu đúng: không hiểu lầm, cả user lẫn devs đều có chung một ý niệm như nhau đối với yêu cầu.
5 Mối quan hệ giữa các đặc tả dot arrow = “is the origin of…”, arrow = “are stored in …” Software_Requirements, 3rd edition, 2013.pdf: Page 8
6 Các yếu tố tham gia đặc tả yêu cầu Slide trước chỉ ra rằng một chức năng của phần mềm được đặc tả từ 5 nguồn:  1. Yêu cầu từ users (user requirements doc)  2. Quy tắc quản lý tổ chức (business rules)  3. Đặc tính chất lượng được mong đợi ở sản phẩm phần mềm (quality attributes), bắt nguồn từ quy tắc quản lý.  4. Yêu cầu của hệ thống có chứa phần mềm.  5. Các giao tiếp ngoài. Phần mềm có chất lượng chỉ khi các đặc tả trên đã được hiểu đúng và làm đúng, trong đó có đặc tả về các đặc tính chất lượng được mong đợi (bắt nguồn từ quy tắc quản lý).
7 Làm PM có chất lượng (2) Thực tế: Người sử dụng có thể mô tả được yêu cầu chức năng, nhưng khó mô tả những đặc tính nào của PM (reusability, maintainability,… ) quyết định chất lượng của PM. Đặc tính được yêu cầu đôi khi bị nhầm lẫn, vd: dể sử dụng (do năng lực của người sử dụng), chạy nhanh (do tài nguyên cấp cho PM),… Vấn đề trong việc mô tả yêu cầu đ/v SPPM: Cần chuẩn hoá các yêu cầu chất lượng đ/v phần mềm (gọi là các yếu tố chất lượng, quality factors, “QF”) để hiểu đúng và sử dụng đúng từ 2 phía. Cần ánh xạ các yếu tố chất lượng thành những đặc tính cố hữu của phần mềm để devs cài đặt chúng vào trong sản phẩm.
8 Các mô hình chất lượng của SPPM Các mô hình chất lượng PM trong SE: McCall (1977), B. Boelm, … ISO 9126 (2000) → ISO 25010 →SQuaRE,… Vai trò của các mô hình này: Chuẩn hoá các yếu tố chất lượng của phần mềm ở góc độ sử dụng (tránh trùng lặp, mâu thuẩn hoặc hiểu lầm). Ánh xạ các yếu tố chất lượng thành các đặc tính của sản phẩm phần mềm. (Để đánh giá mức độ thoả mãn các yêu cầu chất lượng từ các đặc tính được thiết kế của phần mềm.)
9 Mô hình Mc.Call (1977) Chuyển giao Cập nhật Xây dựng Sử dụng (vận hành) 1. PM cần thỏa mãn các yêu cầu & mong đợi từ 3 khía cạnh: chuyển giao, vận hành và cập nhật. 2. Các yếu tố chất lượng (quality factors) được đưa ra từ 3 khía cạnh này, để users và devs “hiểu nhau” (có chung quan điểm). 3. Quality factors được mô hình “phiên dịch” thành các đặc điểm của PM (quality criteria) cho devs tiến hành xây dựng PM.
10 Mô hình Mc.Call (1977) Quality Factors = external quality factors
11 Mc.Call : OPERATION 1. Correctness: là khả năng cung cấp các kết quả chính xác chấp nhận được. 2. Reliability: Là khả năng hoạt động ổn định trong những điều kiện bất thường và tránh được các kết xuất sai. ◦ Khả năng chịu lỗi. ◦ Khả năng tự phục hồi. 3. Usability: Là khả năng giúp người sử dụng hiểu được, học được và sử dụng được phần mềm. 4. Integrity: Là khả năng bảo vệ thông tin và dữ liệu để ngăn chặn sự truy cập, đọc hay chỉnh sửa trái phép. 5. Efficiency: Là khả năng thực hiện tất cả các chức năng một cách hợp lý tương ứng với lượng tài nguyên được phép sử dụng.
12 Mc.Call : TRANSITION 1. Portablity: Là khả năng dùng được PM trong nhiều môi trường khác nhau. ◦ Thích nghi với nhiều môi trường (lớp nền, services, …) ◦ Cùng nhau tồn tại trong môi trường (no conflict) ◦ Thay thế cho phần mềm khác có cùng chức năng 2. Reusability: Là khả năng sử dụng lại được một hoặc nhiều thành phần của PM. ◦ PM có thể tháo rời thành nhiều gói dùng lại được 3. Interoperability: khả năng cộng tác giữa các thành phần, hoặc giữa PM với các hệ thống khác. ◦ PM có giao tiếp & phương thức hợp chuẩn.
13 Mc.Call : REVISION 1. Maintainability: Là mức độ trợ giúp từ PM cho người bảo trì, để giảm thiểu nổ lực tìm ra nguyên nhân hư hỏng (failures), sửa chữa hoặc cải tiến. ◦ Cấu trúc thành phần của PM thuận lợi cho bảo trì ◦ Có tài liệu đặc tả tốt về phần mềm (q.lý cấu hình) 2. Flexibility: Là mức độ đáp ứng linh hoạt của PM cho các yêu cầu đa dạng trong phạm vi sử dụng các chức năng được thiết kế. ◦ Dự trù trước các tình huống tùy biến của chức năng 3. Testability: Là mức độ trợ giúp người kiểm tra đánh giá, chẩn đoán để tìm lỗi hoặc để xác định những chổ cần sửa của phần mềm. ◦ Bẩy lỗi và báo lỗi trong chương trình
14 Mc.Call:Mapping Quality Factors Quality Criteria Traceability Correctness Completeness Consistency Reliability Accuracy OPERATION Error tolerance Efficiency Execution efficiency Storage efficiency Integrity Access control Access audit Usability Operability Training Communicativeness
15 Mc.Call: Mapping Quality Factors Quality Criteria Simplicity Maintainability REVISION Conciseness Testability Instrumentation Self-descriptiveness Flexibility Expandability Generality Modularity TRANSITION Portability Software-system independence Machine independence Reusability Communication commonality Interoperability Data commonality
16 ISO 9126 (2000) : tiếp cận 1. Chất lượng PM có từ việc sử dụng nó trong một ngữ cảnh cụ thể (quality in use) 2. Giống McCall: external quality attributes (QF) phụ thuộc vào internal quality attributes (Quality Criteria). ISO 9126-1 standard.pdf
17 ISO 9126 (2000) : nguyên lý Specs Product Evaluation User’s view Dev’s view
18 ISO 9126 (2000): SW characteristics development supports
19 ISO 9126 (2000): SW in use Specified users, specified goals in a specified context of use Satisfaction application supports Quality Effectiveness Productivity in use Safety
20 ISO 9126 : Mapping Internal attributes (Criteria) Attribute External attributes (QF) Sub-characteristic Characteristic ISO 9126-1 standard.pdf