Bài giảng Software quality assurance: Ứng xử với yêu cầu đ/v phần mềm - Nguyễn Anh Hào

Bài giảng Software quality assurance: Ứng xử với yêu cầu đ/v phần mềm cung cấp cho người học các kiến thức: Ứng xử với yêu cầu, yêu cầu đ/v phần mềm có từ đâu, các ứng xử cơ bản đ/v yêu cầu,... Mời các bạn cùng tham khảo.

SW Quality Assurance 03 Ứng xử với yêu cầu đ/v PM  Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM Yêu cầu gi ?  Yêu cầu (requirements) đặc tả cho cần phải thoả mãn cách làm đặc tả hành vi xử lý phần mềm (functions) đặc tả đặc tính phần mềm (characteristics) đặc tả ràng buộc đ/v cách thức phát triễn phần mềm (constraints) cầu không tường minh (needs) mong muốn cho cần thiết, không đặc tả  Cả yêu cầu lẫn mong muốn góp phần định chất lượng phần mềm  Yêu Software_Requirements, 3rd edition, 2013.pdf: Page Ứng xử với yêu cầu Yêu cầu đv PM : Yêu cầu phải hiểu để làm Không dựa vào mô tả người sử dụng Yêu cầu phải đầy đủ & quán Vì PM hệ thống Yêu cầu phải đưa đến hành động khả thi Yêu cầu thay đổi để có PM tốt Cách làm cần hổ trợ cho thay đổi yêu cầu Sự truyền đạt yêu cầu có đặc điểm: S.M.A.R.T Yêu cầu đ/v PM có từ đâu ? Môi trường ứng dụng PM (hệ thống lớn) Các vấn đề nghiệp vụ cần giải hệ thống Yêu cầu user giải pháp nghiệp vụ vấn đề Môi trường vận hành PM (nguồn lực: người | phương pháp | công cụ) Máy tính thiết bị dùng cho PM Người sử dụng (trực tiếp gián tiếp) phần mềm Flat-form phần mềm: hệ điều hành, mạng,… Môi trường phát triễn PM Các công cụ làm phần mềm: pm để lập trình,… Năng lực chun mơn người làm phần mềm Phương pháp, kỹ thuật (công nghệ) chọn để làm phần mềm Các ứng xử đ/v yêu cầu Nhận biết kiễm soát yêu cầu (CMMI-level 2-RM)  Phát nhu cầu sử dụng PM yêu cầu từ người sử dụng, có thay đổi yêu cầu  Nghiên cứu khả thi: Xác định ích lợi phần mềm xây dựng (nên làm không) phương án làm Khám phá yêu cầu (CMMI-level 3-RD)  Phát triễn yêu cầu cho việc xây dựng phần mềm Truyền đạt u cầu (Comunicating)  Mơ hình hố, tài liệu đặc tả, làm mẫu thử (demo) Kiễm chứng yêu cầu (validation)  Chứng minh đặc tả yêu cầu phản ánh mong đợi đ/v PM (Review) 1.Nhận biết & kiễm soát yêu cầu  PM khơng phục vụ cho người sử dụng; phục vụ cho hệ thống lớn vd: website bán hàng phục vụ cho cơng việc kinh doanh kế tốn công ty Người sử dụng làm phần công việc hệ thống Yêu cầu đ/v PM = yêu cầu hệ thống lớn  Yêu cầu từ hệ thống nêu từ người sử dụng (hoặc stake-holders), phải xem xét cách có hệ thống vì: Để tránh chủ quan Để khẳng định tính đắn yêu cầu Bảo đảm tính quán hệ thống Problem domain Yêu cầu đ/v PM từ quan điểm hệ thống Vấn đề (External Quality Factors) Yêu cầu từ user Giải pháp FR1 FR2 Yêu cầu chất lượng NFR Design domain Phần mềm C1 Kết cấu hệ thống 10 C2 Các hổ trợ (công nghệ) Đặc tính PM (Internal Attributes) Hệ thống đặc tả yêu cầu cho PM Implementation Operation Application dot arrow = “is the origin of…”, arrow = “are stored in …” Software_Requirements, 3rd edition, 2013.pdf: Page CMMI-L2: Quản lý yêu cầu Quản lý yêu cầu (Requirements Management, RM): hành động tìm hiểu yêu cầu đ/v PM từ khách hàng (users), cam kết làm thỏa mãn yêu cầu, kiễm soát thay đổi đ/v yêu cầu biết, gắn yêu cầu với công việc (kế hoạch thực hiện) làm thỏa mãn yêu cầu  Ie, thiết lập yêu cầu từ quan điểm sử dụng PM CMMI DEV-V1.3 (2010).pdf Page 341 & 325 CMMI-L2: Quản lý yêu cầu (RM) 10 Hiểu yêu cầu từ khách hàng  Tiêu chí diễn đạt nội dung : S.M.A.R.T  Có tương tác để kiễm chứng (vd: làm mẫu thử) Khẳng định trách nhiệm thực yêu cầu  Bằng tiến trình cam kết Gắn yêu cầu vào kế hoạch thực hiện, để theo dõi việc thực (tracking & oversight)  Ngăn ngừa loại bỏ không quán yêu cầu hành động thực Kiễm soát thay đổi yêu cầu  Nhận biết thay đổi yêu cầu (vd: version), thay đổi tương ứng bên phần mềm  Cân nhắc chi phí thực & lợi ích từ thay đổi Dị vết yêu cầu 26  Vết (trace): nguồn gốc (ie, đặc tả biết) phát sinh đặc tả  vd: giải thuật (là đặc tả mới) đưa để thực chức yêu cầu (là đặc tả biết)  Nó liên kết đặc tả mức phát triễn (phân tích, thiết kế, lập trình, )  Việc dị vết yêu cầu mức để bảo đảm tính liên kết quán & mạch lạc (dễ hiểu) tài liệu đặc tả cho trình phát triễn cập nhật phần mềm  Dò vết từ hồ sơ phân tích → hồ sơ thiết kế → mã nguồn & cấu trúc liệu  Tracing dùng cho phát triễn lẫn kiễm thử phần mềm Các khía cạnh để dị vết 27  Tồn diện (coverage): đặc tả đưa mức chi tiết (ie, giải pháp ) có đáp ứng trọn vẹn đặc tả mức bên (ie, yêu cầu ) không ?   Tác động (impact): Nếu thay đổi (phát sinh, sửa, hủy) đặc tả mức bên trên, đặc tả mức chi tiết bị ảnh hưởng (cần phải thay đổi theo) ?   Ý nghĩa: phát thiếu sót (khơng đủ) đặc tả Ý nghĩa: phạm vi bị tác động thay đổi yêu cầu Dẫn xuất (derivation): đặc tả mức chi tiết sinh từ đặc tả mức (ie, phải có lý để tồn tại), lại nằm mức ?  Ý nghĩa: phân hoạch đặc tả vào mức phát triễn cho phù hợp với nội dung thực mức Dò vết xây dựng đặc tả Impact: Những Impact analysis đặc tả chi tiết bị ảnh hưởng thay đổi đặc tả mức cao ? User’s requirements Product requirements Coverage: Đặc Coverage tả chi tiết đầy đủ chưa ? Component requirements Derivation analysis 28 Derivation: Những đặc tả chi tiết cần thiết, cần nằm mức ? Requirements Engineering, 2nd Edition - 2005.pdf 29 Dò vết kiễm thử đặc tả (V-model) Coverage: Các test-cases Coverage User’s requirements Product requirements định nghĩa đủ chưa ? Acceptance Test cases Impact analysis Derivation analysis System Test cases Component requirements Component Test cases Kiễm chứng yêu cầu 30  Là hành động chứng minh đặc tả yêu cầu đ/v PM phản ánh “mong đợi” từ mơi trường mà phát triễn & vận hành  Mong đợi: phát biểu từ tác nhân  Các hành động phân tích mối quan hệ phần mềm với môi trường suốt chu kỳ sống nó, để khẳng định đặc tả cần thiết, đầy đủ  Phương pháp:     Revew, Làm mẫu thử Định nghĩa tiêu chí nghiệm thu Kiễm thử yêu cầu (để phát sai) Giả lập yêu cầu (để phát thiếu) 31 Dự án: Khảo sát & phân tích  Khảo sát trạng hệ thống công việc đưa nhận định bối cảnh phát sinh vấn đề, yêu cầu giải pháp để giải vấn đề mà PM hổ trợ thực  Xem xét: nhu cầu sử dụng PM từ môi trường nghiệp vụ, khả triễn khai áp dụng PM từ môi trường vận hành, cách thức xây dựng PM môi trường phát triễn từ khía cạnh học thuật, mơ hình phát triễn, công nghệ chuẩn … để đưa nhận định vấn đề giải pháp  Theo dõi thay đổi mơi trường này; chúng làm thay đổi yêu cầu ban đầu (UP/RUP: giám sát mơi trường & quản lý cấu hình) Dự án: Thiết kế phần mềm 32  Thiết kế phần mềm hệ thống công việc giải pháp cho vấn đề biết, đặc tả chi tiết để xây dựng, kiễm thử triễn khai ứng dụng phiên PM : Đặc tả chức kết cấu PM (các usecase, class, layers, package/subsystem,…) Đặc tả chi tiết để lập trình (mơ đun, liệu, giải thuật, giao tiếp, công nghệ / chuẩn,…) Đặc tả chi tiết kiễm thử: test cases, test plans Đặc tả cách vận hành PM (mơ hình vận hành, vai trị users, flat-forms, giao tiếp với hệ thống khác,… ) Yêu cầu & giải pháp dự án (1) 33  Yêu cầu dùng để xây dựng giải pháp, mà sau PM → phát yêu cầu đầy đủ cho PM sớm tốt Yêu cầu yêu cầu từ chất vấn đề, khơng thay đổi (invariances) Tạo điều kiện cho users tiếp cận sớm với PM (user involvement) để nhận tư vấn thiết thực Yêu cầu & giải pháp dự án (2) 34  Xem xét tồn diện khía cạnh phát triễn, vận hành, tiến hóa PM để đưa yêu cầu cách phối hợp nhiều chuyên gia  Tổ chức họp / forum / workflow  Ý kiến từ người sử dụng ưu tiên, thường diễn tả yêu cầu từ tổ chức (nghiệp vụ, môi trường vận hành, hiệu dùng tài nguyên, ), nhiên họ giải vấn đề trước mắt, không giải vấn đề sử dụng lâu dài PM (cơng nghệ, an tồn, cải tiến, ) u cầu & giải pháp dự án (3) 35  PM thực chức theo yêu cầu chưa có sẵn, nên khó hình dung cách xử lý → cần mô tả hành vi chúng cách trực quan để tác nhân (users, devs, managers) dể tiếp thu  Bằng lược đồ (DFD,UMLs)  Bằng CASE tools: Rational Rose/ Power Designer/Oracle Designer, ) làm mẫu thử bỏ (throw-away prototype)  Agile: Bằng source code làm Yêu cầu & giải pháp dự án (4) 36  Lỗi khó phát → việc kiểm thử PM cần thực sớm, để tránh gây hậu (làm lại, rework) sau Các cơng đoạn ban đầu (phân tích, thiết kế, lập trình) cần kiểm thử Xác định test cases trước đặc tả nội dung xử lý chức Đặc tả tổng quát cần phải kiểm thử (và sửa cho đúng) trước đặc tả chi tiết (top down approach) Tự động hóa việc kiểm thử cần thiết Yêu cầu & giải pháp dự án (5) 37  Tài liệu phát triễn PM phải mơ tả cách có hệ thống; truyền đạt yêu cầu thành giải pháp rõ ràng, suốt (~traceability)  Mọi vấn đề/giải pháp mức quán (consistency)  Mỗi yêu cầu cụ thể hóa thành giải pháp chi tiết mức thấp (impact)  Mỗi chi tiết phải giải vấn đề mức cao (derive)  Liệu yêu cầu mức cao có giải pháp mức chi tiết ? (coverage) Yêu cầu & giải pháp dự án (6) 38  Yêu cầu chức phi chức cần phát triễn đồng thời  Các yêu cầu phi chức quy chuẩn thành yếu tố chất lượng (external quality factors) diễn tả thành đặc tính cài đặt vào PM mơ hình McCall, ISO9126, ISO 25010,  Xem xét đồng thời yêu cầu chức & tính PM để định cách thức cài đặt chức (vd: chọn giải thuật phù hợp) Xem xét thiết kế: ý nghĩa 39 Để phát lỗi phân tích, lỗi thiết kế nội dung mà hồn thiện, thay đổi sửa chữa phải làm thỏa mãn cho đặc tả ban đầu, phải chấp thuận Để phát rủi ro ảnh hưởng đến dự án Để tìm lệch chuẩn chất lượng  Sửa chữa sai lệch dự kiến góp phần cải thiện giao tiếp & phối hợp thực nhờ tính quán & phổ biến chẩn Để phê duyệt phân tích, thiết kế sản phẩm, cho phép nhóm dự án tiếp tục thực giai đoạn 40 Các phương pháp xem xét thiết kế Peer review : để hoàn thiện thiết kế Formal design review : để phê duyệt thiết kế, Expert opinion: để tư vấn thêm ... làm phần mềm Các ứng xử đ/v yêu cầu Nhận biết kiễm soát yêu cầu (CMMI-level 2-RM)  Phát nhu cầu sử dụng PM yêu cầu từ người sử dụng, có thay đổi yêu cầu  Nghiên cứu khả thi: Xác định ích lợi phần. .. Page Ứng xử với yêu cầu Yêu cầu đv PM : Yêu cầu phải hiểu để làm Không dựa vào mô tả người sử dụng Yêu cầu phải đầy đủ & quán Vì PM hệ thống Yêu cầu phải đưa đến hành động khả thi Yêu cầu thay... triễn yêu cầu : hành động khám phá yêu cầu từ hệ thống, phát triễn yêu cầu ban đầu thành yêu cầu chi tiết cho công đoạn làm phần mềm kiễm chứng phù hợp yêu cầu thực tế  Ie, chi tiết hoá yêu cầu