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

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

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:

Nguyễn Đức Cương 20111203 CNTT-TT 2.3 K56

1

1 Requirements Verification và Requirements Validation

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ử

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

- Mỗi (chức năng) yêu cầu cần phải có một thử

nghiệm liên quan

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ả

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)!

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

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

Tác nhân tham gia

Nhóm kiểm duyệt

Người dùng

Các vấn đề khi kiểm duyệt:

Tính rõ ràng của yêu cầu

Thiếu thông tin

Xung đột yêu cầu

Các yêu cầu không thực tế

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

Có một người chịu trách nhiệm điều tiết buổi họp bàn

7 Fagan Inspection.

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)