Slide bài tập tuần 4 phân tích yêu cầu phần mềm

Phân tích yêu cầu phần mềm
Bài tập tuần 4
Giảng viên: PGS.TS. Huỳnh Quyết Thắng
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
1
1. Requirements Verification và
Requirements Validation

Phâ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ầu
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í

Ảnh hưởng của Xác nhận yêu cầu (Requirements Validation):
o
Đả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.
o
Tạo ra sự thống nhất giữa các bên liên quan
o
Phản ứng dây chuyền

Ảnh hưởng của Kiểm chứng yêu cầu (Requirements Verification):
o
Đả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.
o
Rà soát lỗi của những người thiết kế, lập trình
o

Đ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.
o
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 Check

Quy trình thực hiện

Thời gian thực hiện

Tác nhân tham gia
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
Thời gian thực hiện

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.
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. Prototyping

Quy trình thực hiện

Thời gian thực hiện

Tác nhân tham gia
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
Thời gian thực hiện

Thực hiện đồng thời với quá trình xác định yêu cầu
phần mềm
Tác nhân tham gia

Lập trình viên


Bộ phần kiểm thử

Nhà quản lý dự án
4. Functional test design

Quy trình thực hiện

Thời gian thực hiện

Tác nhân tham gia

Công cụ điển hình
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


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

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 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
5. User manual Development.

Quy trình thực hiện

Thời gian thực hiện

Tác nhân tham gia

Công cụ điển hình
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

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
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.
6. Reviews and Inspections

Quy trình thực hiện

Thời gian thực hiện

Tác nhân tham gia

Các vấn đề khi kiểm duyệt:
Quy trình thực hiện

Plan review.

Phân phát tài liệu liên quan

Chuẩn bị cho việc kiểm duyệt các yêu cầu


Tổ chức gặp mặt

Thự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ệ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