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.
AMBIENT/
Chủ đề:
Nội dung Text: 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
- 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ừ
Giải pháp
user 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
Application
Operation
Implementation Hệ thống đặc tả yêu cầu cho PM
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 tiêu
Nơi Nguồn lực
phát Phương án & rủi ro
sinh
yêu Yêu cầu Y/c Khả thi
Kế hoạch thực hiện(BPP)
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 (nếu có).
- 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ụ
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
