Phân tích yêu cầu phần mềm

Phân tích yêu cầu phần mềmBài tập tuần 4Giảng viên: PGS.TS. Huỳnh Quyết ThắngDanh sách sinh viên:Lê Trung Hiếu 20111568 CNTT-TT 2.3 K56Đàm Văn Hoài 20111600 CNTT-TT 2.3 K56Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56Đoàn Văn Đạt 20111370 CNTT-TT 2.3 K56 11. Requirements Verification và Requirements ValidationPhân biệtẢnh hưởng của Xác nhận yêu cầu (Requirements Validation)Ảnh hưởng của Kiểm chứng yêu cầu (Requirements Verification)Phân biệt:Xác nhận yêu cầu(Requirements Validation)Kiển chứng yêu cầu(Requirements Verification)Các thủ tục kiểm tra động (thay đổi theo diễn biến của dự án, tùy vào các bên liên quan), có tác dụng để sửa chữa đặc tả yêu cầucác thủ tục kiểm tra tĩnh (có các quy tắc cho sẵn để áp dụng), có tác dụng ngăn ngừa sự sai khác của phần mềm với đặc tảLà quá trình mang tính chủ quan của các bên liên quan, phụ thuộc rất nhiều vào đánh giá của người dùngLà quá trình mang tính khách quan, các tiêu chuẩn kĩ thuật được áp dụng để so sánh sản phẩm với đặc tảKhi phát hiện lỗi, cần sửa chữa đặc tả (chi phí thấp nếu chưa tạo ra sản phẩm), nếu sản phẩm đã được tạo ra thì chi phí khắc phục rất caoKhi phát hiện lỗi, việc sửa chữa tốn ít chi phíẢnh hưởng của Xác nhận yêu cầu (Requirements Validation):Đảm bảo khi sản phẩm được tạo ra sẽ đáp ứng đúng yêu cầu người dùng, và được chấp nhận.Tạo ra sự thống nhất giữa các bên liên quanPhản ứng dây chuyềnẢnh hưởng của Kiểm chứng yêu cầu (Requirements Verification):Đảm bảo rằng khi phần mềm được hoàn thành thì nó sẽ phù hợp với các đặc tả yêu cầu.Rà soát lỗi của những người thiết kế, lập trìnhĐiều chỉnh những bản thiết kế hệ thống một cách chính xác, tối ưu.thường không gây phản ứng dây chuyền, chỉ dẫn đến việc sửa đổi một hoặc một số module của hệ thống.2. Simple CheckQuy trình thực hiệnThời gian thực hiệnTác nhân tham giaQuy trình thực hiệnNgười kiểm duyệt, kiểm soát yêu cầu phải có các kiến thức từ trước (các phản hồi từ khách hàng )Quan sát xem có những cái gì sai lệch trong hệ thống hiện tại.Mô hình hóa : Mô tả và giải thích vấn đềPhân tích và kiểm tra các đặc tính của mô hìnhThời gian thực hiệnKỹ thuật kiểm tra sự khác nhau bằng cách truy xuất nguồn gốc của yêu cầu Vì vậy kỹ thuật simple check được thực hiện trong mọi giai đoạn phát triển của phần mềm.Tác nhân tham giaLập trình viênBộ phận kiểm thửNhà quản lý dự án3. PrototypingQuy trình thực hiệnThời gian thực hiệnTác nhân tham giaQuy trình thực hiệnLựa chọn các nguyên mẫu để thử nghiệmSau khi đã lựa chọn được các nguyên mẫu để thử nghiệm thì xây dựng các kịch bản thử nghiệm.Cần phải có một kế hoạch cụ thể để xây dựng các kịch bản thử nghiệm sao cho bao quát toàn bộ các yêu cầu phần mềmThời gian thực hiệnThực hiện đồng thời với quá trình xác định yêu cầu phần mềmTác nhân tham giaLập trình viênBộ phần kiểm thửNhà quản lý dự án4. Functional test design Quy trình thực hiệnThời gian thực hiệnTác nhân tham giaCông cụ điển hìnhQuy trình thực hiệnXác định các chức năng mà phần mềm dự kiến ​​sẽ thực hiệnTạo ra các dữ liệu đầu vào dựa trên thông số kỹ thuật của chức năngXác định đầu ra dựa trên thông số kỹ thuật của chức năngThực hiện các trường hợp thử nghiệmSo sánh các kết quả đầu ra thực tế và dự kiếnKiểm tra xem các ứng dụng làm việc theo nhu cầu của khách hàngThời gian thực hiệnCó thể (và nên) được bắt nguồn từ đặc tả yêu cầu - Mỗi (chức năng) yêu cầu cần phải có một thử nghiệm liên quan Mỗi trường hợp yêu cầu kiểm tra phải được bắt nguồn từ yêu cầu của nó - Phát minh ra các yêu cầu kiểm tra là một kỹ thuật xác nhận hiệu quả Thiết kế các xét nghiệm này có thể phát hiện sai sót trong đặc điểm kỹ thuật (ngay cả trước khi thiết kế và xây dựng hệ thống)! Một số quy trình phát triển phần mềm (ví dụ như phương pháp nhanh nhẹn) bắt đầu với các bài kiểm thử trước khi phát triển phần mềm.(lập trình).Tác nhân tham giaKhách hàngBộ phận lập trìnhBộ phận kiểm thửNgười quản lí dự án.Công cụ điển hìnhDialog mapTest case Ma trận theo dõi các trường hợp sử dụng5. User manual Development.Quy trình thực hiệnThời gian thực hiệnTác nhân tham giaCông cụ điển hìnhQuy trình thực hiệnLàm thế nào để cài đặt và bắt đầu với hệ thốngMô tả các chức năng và làm thế nào nó được thực hiện Làm thế nào để có được ra khỏi rắc rối Những bộ phận của hệ thống đã không được thực hiện Thời gian thực hiệnPhác thảo sổ tay người dùng ngay từ sớm trong quy trình phát triển yêu cầu và dùng nó như là tài liệu đặc tả yêu cầu hoặc như một trợ giúp cho phân tích yêu cầuTác nhân tham giaCác PTVCác đại diện của NSD (Product champions)Tất cả các thành viên của công ty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm:LTV, các nhà kiểm thử, v.vCông cụ điển hìnhMột số phần mềm soạn thảo văn bảnPhần mềm đồ họa.Một số mẫu hướng dẫn sử dụng có sẵn.6. Reviews and InspectionsQuy trình thực hiệnThời gian thực hiệnTác nhân tham giaCác vấn đề khi kiểm duyệt:Quy trình thực hiệnPlan review.Phân phát tài liệu liên quanChuẩn bị cho việc kiểm duyệt các yêu cầuTổ chức gặp mặtThực hiện các việc cần làm (kết quả của bước 4)Duyệt lại văn bản.Thời gian thực hiệnCó thể áp dụng khi mới xây dựng xong bước đầu các yêu cầu phần mềm từ các biện pháp thu thậpTác nhân tham giaNhóm kiểm duyệtNgười dùng.Các vấn đề khi kiểm duyệt:Tính rõ ràng của yêu cầuThiếu thông tinXung đột yêu cầuCác yêu cầu không thực tế7. Fagan Inspection.Khái niệm:Fagan Inspection được đặc trưng bởi các quy định ai sẽ tham gia, bao nhiêu người kiểm duyệt sẽ tham gia và mỗi người có vai trò gì trong kiểm duyệt.Cần 3 - 5 người kiểm duyệt.Tác giả văn bản yêu cầu phần mềm sẽ đóng vai trò như người trình diễn văn bản.Các số liệu được thu thậpCó một người chịu trách nhiệm điều tiết buổi họp bàn7. Fagan Inspection.Tất cả các người kiểm duyệt cần tự chuẩn bị trước bằng cách sử dụng danh sách kiểm duyệt (checklists).