Duyệt và kiểm soát yêu cầu phần mềm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ––––––––––––––––––––––––*–––––––––––––––––––––– Báo cáo bài tập tuần Môn học: Phân tích yêu cầu phần mềm Tuần 4 :DUYỆT VÀ KIỂM SOÁT YÊU CẦU PHẦN MỀM Nhóm 3 Danh 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 K56 Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56 Đoàn Văn Đạt 20111370 CNTT-TT 2.3 K56 Giảng viên: PGS.TS. Huỳnh Quyết Thắng Hà Nội Ngày 16 tháng 5 năm 2014 Mục lục 1. Phân biệt Requirements Verification và Requirements Validation 1.1. Phân biệt - Requirements Validation (Xác nhận yêu cầu) Đây là việc kiểm tra rằng có phải một sản phẩm đúng đang được xây dựng hay không. Cần chắc chắn rằng sản phẩm đang xây dựng (hay nâng cấp) sẽ làm thỏa mãn các bên liên quan. Điều này được tiến hành bằng việc đối chiếu lại bản đặc tả yêu cầu phần mềm với mục tiêu và yêu cầu của các bên liên quan. - Requirement Verification (Kiểm chứng yêu cầu) Đây là việc kiểm tra rằng có phải một sản phẩm đang được xây dựng đúng hay không. Cần chắc chắn rằng mỗi bước được cho phép trong quá trình xây dựng phần mềm đều mang lại lợi ích cho việc xây dựng sản phẩm đúng. Việc này được tiến hành thông qua đối chiếu đối tượng được tạo ra theo bản đặc tả yêu cầu phần mềm với bản đặc tả đó. Sự khác nhau của hai công việc trên chính là ở vai trò của bản đặc tả yêu cầu phần mềm. Với xác nhận yêu cầu, bản đặc tả yêu cầu phần mềm được kiểm tra xem có phản ánh chính xác các yêu cầu của những bên liên quan hay không. Còn với kiểm chứng yêu cầu, bản đặc tả yêu cầu được dùng làm mẫu để đánh giá phần mềm đang xây dựng có phù hợp hay không. Các so sánh cụ thể: Xác nhận yêu cầu (Requirements Validation) Kiểm chứng yêu cầu (Requirements Verification) Xác nhận yêu cầu là 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ầu Kiểm chứng yêu cầu là cá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ùng Là 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 cao Khi phát hiện lỗi, việc sửa chữa tốn ít chi phí 1.2. Ảnh hưởng của Xác nhận yêu cầu (Requirements Validation) Xác nhận yêu cầu là công việc quan trọng trong quá trình phân tích và đặc tả yêu cầu phần mềm. - Những ảnh hưởng của Xác nhận yêu cầu: + Việc xác nhận yêu cầu giúp cho các yêu cầu được đặc tả luôn phản ánh đúng nguyện vọng của các bên liên quan. Các khách hàng, người dùng được cung cấp bản chạy được của phần mềm và được dùng thử để xem đã đáp ứng được đúng yêu cầu của mình chưa. Nếu có bất cứ phát hiện nào, các lỗi đó sẽ được thông báo cho người phát triển để chỉnh sửa. Việc này đả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. + Việc xác nhận yêu cầu tạo ra sự nhất trí, tin tưởng giữa các bên liên quan, tạo định hướng thống nhất cho giai đoạn thiết kế, viết mã nguồn hệ thống. + Lỗi của quá trình Xác nhận yêu cầu phát hiện ra dẫn đến sự thay đổi của bản đặc tả yêu cầu phần mềm, dẫn đến một loạt phản ứng dây chuyền, làm thay đổi từ khâu phân tích thiết kế tới viết mã nguồn. 1.3. Ảnh hưởng của Kiểm chứng yêu cầu (Requirements Verification) Kiểm chứng yêu cầu phần mềm được tiến hành thiết kế và lập trình sản phẩm phần mềm - Những ảnh hưởng của Kiểm chứng yêu cầu: + Kiểm chứng yêu cầu giúp phần mềm được tạo ra đúng với đặc tả của yêu cầu phần mềm. Nếu phát hiện ra lỗi, những nhà phát triển phần mềm sẽ được thông báo để sửa chữa, do đó đả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. + Việc kiểm chứng yêu cầu giúp rà soát lỗi của những người thiết kế, lập trình, qua đó nâng cao ý thức làm việc cẩn trọng, nghiêm túc của đội ngũ phát triển phần mềm + Trong giai đoạn thiết kế, Kiểm chứng yêu cầu giúp đ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. Các lỗi tạo ra được điều chỉnh trước khi giao cho đội ngũ lập trình, làm giảm đáng kể chi phí sửa lỗi. + Trong giai đoạn cài đặt, Kiểm chứng yêu cầu giúp điều chỉnh những lỗi lập trình ngay từ các mức thấp, làm giảm chi phí sửa lỗi bởi tránh được việc lan truyền lỗi. + Các lỗi được phát hiện của Kiểm chứng yêu cầ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. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Simple Check 2.1. Quy trình thực hiện Ngườ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ình 2.2. Thời gian thực hiện Kỹ thuật simple check là kỹ 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. 2.3. Tác nhân tham gia Lập trình viên Bộ phận kiểm thử Nhà quản lý dự án 3. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm prototyping Kỹ thuật Prototyping là một kỹ thuật xây dựng một kiến trúc được cài đặt cụ thể trước để các khách hàng, người dùng hoặc nhà phát triển có thể hiểu rõ thêm về một vấn đề hay giải pháp của nó. Các hướng tiếp cận của Prototyping: Bản mẫu trình diễn: Dùng để chứng minh các khái niệm, giải thích các đặc tính thiết kế. Bản mẫu thăm dò : dùng để xác định vấn đề, thu thập nhu cầu, làm rõ mục tiêu, so sánh các lựa chọn thiết kế Bản mẫu thử nghiệm : khai thác các đặc tính kỹ thuật, kiểm tra sự thích hợp của một kỹ thuật Bản mẫu tiến triển : được phát triển khi thấy tiến trình tiếp diễn sẽ tương thích với hệ thống. 3.1. Quy trình thực hiện Lựa chọn các nguyên mẫu để thử nghiệm Sau 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ềm 3.2. Thời gian thực hiện Kỹ thuật prototyping để trợ giúp cho việc xác định yêu cầu phần mềm nên được thực hiện đồng thời với quá trình xác định yêu cầu phần mềm 3.3 Tác nhân tham gia Lập trình viên Bộ phần kiểm thử Nhà quản lý dự án Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Functional test design Quy trình thực hiện. Xác định các chức năng mà phần mềm dự kiến ​​sẽ thực hiện Tạ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ăng Xác định đầu ra dựa trên thông số kỹ thuật của chức năng Thực hiện các trường hợp thử nghiệm So sánh các kết quả đầu ra thực tế và dự kiến Kiểm tra xem các ứng dụng làm việc theo nhu cầu của khách hàng Thời gian thực hiện. Functional test design là một cách tiếp cận kiểm tra, trong đó trường hợp thử nghiệm, điều kiện và dữ liệu có nguồn gốc từ các yêu cầu. Nó bao gồm các bài kiểm tra chức năng và cũng thuộc tính không có chức năng như hiệu suất, độ tin cậy hoặc khả năng sử dụng. Thử ngiệm chức năng (functional testing) còn gọi là thử nghiệm hộp đen (black box testing) là sự thử nghiệm sử dụng các ca thử nghiệm được thiết kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết. Thử nghiệm chức năng nhìn nhận mô đun được thử nghiệm như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của mô đun, tức là kiểm tra xem có hoạt động đúng với đặc tả hay không. Các ca kiểm thử bao gồm các trường hợp bình thường và không bình thường (dữ liệu không hợp lệ...) của mô đun. Thông thường, không thể thử nghiệm với mọi dữ liệu, chiến lược chung khi thiết kế dữ liệu thử nghiệm là phân hoạch (dữ liệu) tương đương. Phân hoạch tương đương chia miền dữ liệu vào ra thành các vùng, mà mỗi vùng chứa các dữ liệu có cùng hành vi. Do đó, đối với mỗi vùng dữ liệu chỉ cần xây dựng một ca thử nghiệm. Thêm vào đó là các ca sử dụng đối với biên giới của các vùng. Theo kinh nghiệm, các sai sót về lập trình thường sảy ra đối với các dữ liệu biên. Kiểm tra chức năng ở cấp độ hệ thống phải được phát triển sớm hay muộn ? - Có 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 - Không chức năng (ví dụ, độ tin cậy) hoặc độc quyền (ví dụ, xác định những gì nên không xảy ra) yêu cầu là khó khăn hơn để xác nhận với các thử nghiệm - 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)! - Thiếu thông tin hoặc không rõ ràng trong bản mô tả yêu cầu có thể làm cho nó khó khăn để xây dựng các bài kiểm tra • 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 trình phát triển phần mềm.(lập trình). Tác nhân tham gia. Khách hàng Bộ phận lập trình Bộ phận kiểm thử Người quản lí dự án. Công cụ điển hình Dialog map Test case Ma trận theo dõi các trường hợp sử dụng Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm User manual Development. Quy trình thực hiện Làm thế nào để cài đặt và bắt đầu với hệ thống Mô 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ện Giống như thiết kế thử nghiệm chức năng Có phải được thực hiện tại một số điểm Tiết lộ các vấn đề trước đó Buộc một cái nhìn chi tiết yêu cầu Đặc biệt hữu ích nếu các ứng dụng giàu giao diện người dùng / cho các yêu cầu khả năng sử dụng Phá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ầu. Một tài liệu sổ tay người dùng tốt sẽ mô tả tất cả các chức năng mà người dùng thấy được (user – visible functionality) bằng một ngôn ngữ dễ hiểu. Các yêu cầu khác như các thuộc tính chất lượng, yêu cầu hiệu suất, chức năng không thấy được đối với người dùng (not visible to users) sẽ được tài liệu hoá trong SRS. Tác nhân tham gia Các PTV Cá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.v Công cụ điển hình Một số phần mềm soạn thảo văn bản Phần mềm đồ họa. Một số mẫu hướng dẫn sử dụng có sẵn. Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Reviews and Inspections Một nhóm các kỹ sư phần mềm, kỹ sư hệ thống và người có kinh nghiệm trong lĩnh vực yêu cầu phần mềm sẽ cùng đọc và phân tích các yêu cầu, tìm ra các vấn đề tiềm tàng để thảo luận, và thống nhất với nhau các công việc cần làm để giải quyết những vấn đề đó. Đây là một kỹ thuật kiểm chứng yêu cầu được sử dụng rộng rãi. Có rất nhiều bằng chứng về tính hiệu quả của kỹ thuật này. Kỹ thuật này có thể rất tốn kém: Cần chuẩn bị và lên kế hoạch cẩn thận Cần kiểm tra trước khi duyệt Cần một danh sách kiểm duyệt phù hợp Một số kỹ thuật kiểm duyệt và kiểm soát yêu cầu phần mềm: Phân theo hình thức Đọc văn bản yêu cầu phần mềm: Yêu cầu một người không là tác giả của văn bản yêu cầu phần mềm đó đọc và kiểm duyệt. Đọc và phê duyệt: Khuyến khích người kiểm duyệt đọc cẩn thận hơn và có trách nhiệm hơn. Đọc lướt: Đây là kỹ thuật không chính thức, ở mức tổng quát cao, đọc để có cái nhìn tổng quát về văn bản yêu cầu. Kỹ thuật này có thể cần phải được dẫn dắt bởi tác giả văn bản/chuyên gia. Kỹ thuật kiểm duyệt chính thức (Formal Inspections): kiểm duyệt một cách chi tiết, cụ thể và có cấu trúc. Xác định rõ ràng vai trò của những người tham gia kiểm duyệt cũng như xác dịnh rõ điều kiện để kết thúc việc kiểm duyệt. Kiểm duyệt tập trung: Các chuyên viên kiểm duyệt có vai trò xác định, mỗi chuyên viên chỉ tìm kiếm một số lỗi nhất định trong yêu cầu phần mềm. Kiểm duyệt tích cực: Tác giả văn bản sẽ hỏi trực tiếp các chuyên viên kiểm duyệt các câu hỏi liên quan đến văn bản. Quy trình thực hiện Plan review. Đội kiểm duyệt được lựa chọn, thời gian, địa điểm gặp mặt cũng được ấn định. Phân phát tài liệu liên quan Văn bản yêu cầu phần mềm được phân phát cho các thành viên đội kiểm duyệt. Chuẩn bị cho việc kiểm duyệt các yêu cầu Mỗi thành chuyên viên kiểm duyệt đọc các yêu cầu để tìm ra các xung đột, thiếu sót, mâu thuẫn, lệch chuẩn và các vấn đề khác Tổ chức gặp mặt Các vấn đề và nhận xét của mỗi cá nhân về văn bản yêu cầu phần mềm sẽ được đưa ra thảo luận, và các việc cần làm để giải quyết các vấn đề sẽ được đưa ra. Thực hiện các việc cần làm (kết quả của bước 4) Giải quyết các vấn đề bằng cách tuân thủ thực hiện các hành động đã thống nhất ở bước 4. Duyệt lại văn bản. Văn bản yêu cầu phần mềm được duyệt lại để kiểm chứng sự hợp lý của các hành động đã thống nhất. Kết quả của bước này, hoặc là văn bản cuối cùng được chấp nhận, hoặc là cần được kiểm duyệt lại. Đôi khi, để giảm thiểu chi phí của quá trình kiểm duyệt yêu cầu, cần phải thực hiện bước "pre-review checking". Nghĩa là kiểm tra văn bản và tìm kiếm các vấn đề trực tiếp, như là thiếu yêu cầu phần mềm, thiếu tuân thủ theo chuẩn, Thời gian thực hiện Có 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ập. Khi đó, các vấn đề vẫn còn tồn tại trong các yêu cầu phần mềm. Và cần phải loại bỏ các vấn đề này trước khi đem văn bản yêu cầu đi thương thảo. Áp dụng khi cần xác minh rằng các yêu cầu mình viết ra sẽ thỏa mãn các bên liên quan. Hay nói cách khác, tìm sự đồng thuận từ phía khác hàng. Tác nhân tham gia Những người đến từ những lĩnh vực khác nhau sẽ mang đến những kỹ năng và kiến thức khác nhau để kiểm duyệt các yêu cầu phần mềm Họ sẽ cảm thấy được tham gia và có vai trò trong quá trình xây dựng yêu cầu phần mềm, và họ sẽ hiểu hơn về nhu cầu/yêu cầu của các bên còn lại. Nhóm kiểm duyệt luôn luôn có ít nhất một bên chuyên gia, một bên người dùng. Các vấn đề khi kiểm duyệt: Tính rõ ràng của yêu cầu: Các yêu cầu được diễn tả một cách "tệ", khó hiểu, hoặc có thể vô tình bỏ qua thông tin nào đó đã được thu thập trong suốt quá trình xác định yêu cầu. Thiếu thông tin: Một số thông tin trong văn bản yêu cầu phần mềm bị thiếu. Xung đột yêu cầu: Có xung đột nghiêm trọng giữa các yêu cầu (các yêu cầu phủ định nhau). Các bên liên quan cần thương lượng để giải quyết xung đột. Các yêu cầu không thực tế: Các yêu cầu có vẻ như không thể thực hiện được (unimplementable) với trình độ công nghệ hiện tại, hoặc với ràng buộc nào đó trong hệ thống. Các bên liên quan trong tình huống này cần bàn bạc để quyết định làm cho yêu cầu đó trở nên thực tế hơn. Kỹ thuật Fagan Inspection. 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. Mỗi lần họp bàn không quá 2 tiếng. Chỉ cần khoảng đó thời gian các thành viên tham gia kiểm duyệt tập trung vào công việc. 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ập. Điều quan trọng là các số liệu này tác giả văn bản yêu cầu phần mềm không được biết đến. Người đó chỉ như là một người giám sát suốt quá trình kiểm duyệt. Có một người chịu trách nhiệm điều tiết buổi họp bàn, bắt đầu việc kiểm duyệt, dẫn dắt buổi gặp và đảm bảo các vấn đề được tìm thấy phải được sửa chữa. 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). Các vấn đề được ghi lại theo khuôn dạng đặc biệt. Fagan Inspection giống như "brain storming" trong phát hiện yêu cầu phần mềm. Nó là một phiên động não để phát hiện các vấn đề trong yêu cầu phần mềm. Cần kiểm duyệt lại nếu nhiều hơn 5% văn bản yêu cầu phải thay đổi. (bởi việc sửa chữa 1 lỗi nào đó, lại phát sinh một lỗi mới. Sửa càng nhiều, càng dễ sinh ra lỗi mới).