Bài giảng Đảm bảo chất lượng phần mềm: Ứng xử yêu cầu đối với phần mềm - Nguyễn Anh Hào

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

Thêm vào BST

Báo xấu

22
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: Ứng xử yêu cầu đối với phần mềm trình bày nội dung về ứng xử với yêu cầu, hệ thống đặc tả yêu cầu cho phần mềm, tiến trình cam kết, khám phá yêu cầu, các phương pháp xem xét bản thiết kế. kính mời quý đọc giả 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: Ứng xử yêu cầu đối với phần mềm - Nguyễn Anh Hào

1 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
2 Yêu cầu là gi ?  Yêucầu (requirements) là đặc tả cho những gì cần phải được thoả mãn bằng cách làm. đặ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 Ứng xử với yêu cầu Yêu cầu đv PM : 1. Yêu cầu phải được hiểu đúng để làm đúng Không chỉ dựa vào mô tả của người sử dụng 2. Yêu cầu phải đầy đủ & nhất quán Vì PM là hệ thống. 3. Yêu cầu phải đưa đến hành động khả thi 4. Yêu cầu có thể thay đổi để có PM tốt hơn Cách làm cần hổ trợ cho các thay đổi yêu cầu Sự truyền đạt yêu cầu có 5 đặc điểm: S.M.A.R.T.
4 Yêu cầu đ/v PM có từ đâu ? 1. Môi trường ứng dụng PM (hệ thống lớn) Các vấn đề nghiệp vụ cần giải quyết trong hệ thống Yêu cầu của user và giải pháp nghiệp vụ của vấn đề 2. Môi trường vận hành PM (nguồn lực: con người | phương pháp | công cụ) Máy tính và các thiết bị dùng cho PM Người sử dụng (trực tiếp và gián tiếp) của phần mềm Flat-form của phần mềm: hệ điều hành, mạng,… 3. Môi trường phát triễn PM Các công cụ làm ra phần mềm: pm để lập trình,… Năng lực chuyên môn của người làm phần mềm Phương pháp, kỹ thuật (công nghệ) được chọn để làm phần mềm
5 Các ứng xử cơ bản đ/v yêu cầu 1. Nhận biết và kiễm soát yêu cầu (CMMI-level 2-RM)  Phát hiện nhu cầu sử dụng PM và các yêu cầu từ người sử dụng, trong đó có sự thay đổi yêu cầu  Nghiên cứu khả thi: Xác định ích lợi của phần mềm sẽ xây dựng (nên làm không) và phương án làm 2. 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 3. Truyền đạt yêu cầu (Comunicating)  Mô hình hoá, tài liệu đặc tả, làm mẫu thử (demo) 4. Kiễm chứng yêu cầu (validation)  Chứng minh rằng các đặc tả yêu cầu phản ánh đúng mong đợi đ/v PM (Review)
6 1.Nhận biết & kiễm soát yêu cầu  PM không chỉ phục vụ cho người sử dụng; nó phục vụ cho hệ thống lớn hơn vd: website bán hàng phục vụ cho công việc kinh doanh và kế toán của công ty. Người sử dụng chỉ làm một phần công việc của hệ thống. Yêu cầu đ/v PM = yêu cầu của hệ thống lớn  Yêu cầu từ hệ thống được nêu ra từ người sử dụng (hoặc stake-holders), và phải được xem xét một cách có hệ thống vì: Để tránh chủ quan. Để khẳng định tính đúng đắn của yêu cầu. Bảo đảm tính nhất quán của hệ thống.
7 Yêu cầu đ/v PM từ quan điểm hệ thống Vấn đề Problem domain 1 4 (External Quality Factors) 3 6 Yêu cầu về Yêu cầu từ user Giải pháp chất lượng FR1 FR2 NFR 2 5 7 Phần mềm Design domain 8 9 10 C1 C2 Kết cấu của Các hổ trợ Đặc tính hệ thống (công nghệ) của PM (Internal Attributes)
8 Applicatio Hệ thống đặc tả yêu cầu cho PM n Operation Implementation dot arrow = “is the origin of…”, arrow = “are stored in …” Software_Requirements, 3rd edition, 2013.pdf: Page 8
9 CMMI-L2: Quản lý yêu cầu Quản lý yêu cầu (Requirements Management, RM): là những 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 các thay đổi đ/v yêu cầu đã biết, và 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
10 CMMI-L2: Quản lý yêu cầu (RM) 1. Hiểu đúng 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ử) 2. Khẳng định trách nhiệm thực hiện yêu cầu  Bằng tiến trình cam kết 3. Gắn yêu cầu vào kế hoạch thực hiện, để theo dõi việc thực hiện (tracking & oversight)  Ngăn ngừa và loại bỏ sự không nhất quán giữa yêu cầu và hành động thực hiện 4. Kiễm soát các thay đổi của yêu cầu  Nhận biết sự thay đổi trên yêu cầu (vd: version), và sự thay đổi tương ứng bên trong phần mềm  Cân nhắc chi phí thực hiện & lợi ích từ sự thay đổi
11 Tiến trình cam kết Trợ giúp Khả năng Mục Mục tiêu tiêu Nơi Nơi Nguồn Nguồn lực   phát phát Phương Phương ánán & rủi rủi ro ro sinh sinh yêu yêu Yêu cầu Y/c Khả thi Kế Kế hoạch hoạch thực thực hiện(BPP) hiện(BPP) cầu cầu   Người thực hiện  Kết quả thực hiện 1. Nhận biết yêu cầu từ khách hàng, users hoặc stack-holders 2. Xem xét khả năng thực hiện yêu cầu từ phía dự án 3. Xem xét khả năng thực hiện yêu cầu có thêm trợ giúp từ bên ngoài 4. Cam kết thực hiện yêu cầu khả thi bằng kế hoạch cơ sở (base line project plan, BPP) 5. Thực hiện theo kế hoạch để làm thỏa mãn cho các cam kết
12 Nghiên cứu khả thi Mục đích: xác định vai trò & ý nghĩa của PM trong môi trường vận hành (ie, hệ thống lớn), và khả năng thực hiện yêu cầu từ dự án. Nội dung: trả lời các câu hỏi 1. PM sẽ giúp được gì cho users / tổ chức ? 2. PM có hiện thực được không, với các hổ trợ hiện có (vd: công nghệ) trong giới hạn cho phép về chi phí và thời gian ? 3. PM có vận hành được chung với các PM khác trong môi trường hiện tại không ? 4. Có phương án khả thi được xem xét từ nhiều phương diện : kỹ thuật, kế hoạch, chi phí,…?
13 Quản lý các thay đổi yêu cầu Software_Requirements, 3rd edition, 2013.pdf: Page 18
14 Dự án: Quản lý yêu cầu  Tiền dự án (pre-project) Là một tập hợp có hệ thống các việc cần làm để khẳng định các yêu cầu sẽ được cam kết thực hiện (ghi trong bản hợp đồng) giữa các bên tham gia vào quá trình tạo ra sản phẩm phần mềm.  Mục tiêu của tiền dự án: ◦ Lập tôn chỉ (charter) và hợp đồng (contract) để khẳng định vai trò và trách nhiệm của các bên tham gia dự án, và các tiêu chí để đánh giá, nghiệm thu cho hợp đồng dự án. ◦ Khẳng định kế hoạch hợp tác thực hiện (Project Plan, hoặc BPP).
15 Project Charter 1. Project charter là tập tài liệu xác định một cách hết sức cơ bản về trách nhiệm và quyền hạn của dự án mà các bên có liên quan phải tuân thủ. 2. Nó được các key-person (  stackholders) cùng nhau tạo ra để làm tiên đề cho các hành động phối hợp thực hiện dự án.  ie: mọi vấn đề & giải pháp cụ thể đều được dẫn xuất từ charter này.  Quá trình thực hiện dự án là chuổi các hành động phát hiện, hiệu chỉnh các yêu cầu và tìm giải pháp
16 Project Charter-Nội dung 1. Những vấn đề, hậu quả và cơ hội khắc phục của tổ chức thụ hưởng. 2. Mục tiêu của dự án →giải quyết n vấn đề nào. 3. Yêu cầu đối với sản phẩm/dịch vụ của dự án. 4. Phương pháp thực hiện yêu cầu của dự án 5. Giả định và phụ thuộc của phương pháp 6. Các chuyển giao và mốc chuyển giao 7. Lợi ích từ các chuyển giao 8. Nguồn lực & nơi cấp nguồn lực cho dự án 9. Vai trò và trách nhiệm của stake-holders đối với dự án (trong đó có nhiệm vụ và quyền hạn của trưởng dự án)
17 Lập hợp đồng dự án 1. Lập bản hồ sơ dự thầu (proposal ) hoặc phương án sơ bộ gửi đến khách hàng để hai bên cùng xem xét nội dung yêu cầu & giải pháp trước khi ký hợp đồng. ◦ Đây là giai đoạn khảo sát để nhận biết yêu cầu từ hiện trạng thực tế. 2. Lập bản hợp đồng dự án (contract ) sau khi proposal/phương án sơ bộ đã hoàn chỉnh. 3. Lập bản hợp đồng phụ (sub-contract) với các đối tác bên ngoài để thực hiện một phần việc được outsource từ dự án
18 a) Lập hồ sơ dự thầu 1. Mọi yêu cầu đều phải có phương án khả thi & các phương án được xem xét từ 2 phía (tiến trình cam kết). 2. Mọi yêu cầu được nêu rõ và lập tài liệu (cho từng phiên bản, để có thể thay đổi). 3. Thiết lập quan hệ giữa khách hàng & dự án để hợp tác thực hiện, gồm 1. Thiết lập các kênh thông tin liên lạc; 2. Cách thức nêu yêu cầu & thay đổi yêu cầu; 3. Cách thức chuyển giao và tiêu chí đánh giá; 4. Cách kiểm thử và thông báo lỗi; 5. Cách kết thúc từng giai đoạn (nghiệm thu).
19 b) Lập hợp đồng 1. Hợp đồng có yêu cầu rõ ràng, đầy đủ, không thừa và hoàn toàn khả thi Mọi sự hiểu biết về nội dung dự án (yêu cầu chức năng, vấn đề tài chính, mong muốn của tác nhân, giải pháp của yêu cầu,…) đều được thể hiện trong bản hợp đồng hoặc phụ lục hợp đồng. 2. Mọi sự thay đổi, thêm hoặc bớt trên nội dung hợp đồng đã ký, đều phải được thảo luận và đồng ý giữa các bên. Thay đổi nội dung hợp đồng (cập nhật, nâng cấp sản phẩm) cũng cần có cách thức và điều khoản
20 c) Lập hợp đồng phụ  Phạm vi trách nhiệm của các hợp đồng phụ nhỏ hơn so với hợp đồng chính, nhưng nó lại góp phần tạo ra chất lượng cho hợp đồng chính, do đó: 1. Cần nhận biết sớm và đầy đủ các nguy cơ trễ hạn từ hợp đồng phụ làm trễ hạn hợp đồng chính. 2. Bảo đảm mức chất lượng hợp lý trên các phần việc outsource để làm thoả mãn yêu cầu của hợp đồng chính. 3. Bảo đảm đủ tài liệu để bảo trì các sản phẩm được chuyển giao từ hợp đồng phụ