Báo cáo bài tập tuần phân tích yêu cầu phần mềm

Phân biệt - Requirements Validation Xác nhận yêu cầu Đây là việc kiểm tra rằng có phải một sản phẩm đúng đang được xây dựng hay không.. Với xác nhận yêu cầu, bản đặc tả yê

Trang 1

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ––––––––––––––––––––––––*––––––––––––––––––––––

Báo cáo bài tập tuần

Môn học: Phân tích yêu cầu phần mềm Tuần 4 :DUYỆT VÀ KIỂM SOÁT YÊU CẦU PHẦN MỀM

Nhóm 3

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 Đạt 20111370 CNTT-TT 2.3 K56

Giảng viên: PGS.TS Huỳnh Quyết Thắng

Hà Nội Ngày 16 tháng 5 năm 2014

Phân tích yêu cầu phần mềm Tuần 4 Page 1

Trang 2

Mục lục

Trang 3

1 Phân biệt Requirements Verification và Requirements Validation

1.1 Phân biệt

- Requirements Validation (Xác nhận yêu cầu)

Đây là việc kiểm tra rằng có phải một sản phẩm đúng đang được xây dựng hay không Cần chắc chắn rằng sản phẩm đang xây dựng (hay nâng cấp) sẽ làm thỏa mãn các bên liên quan Điều này được tiến hành bằng việc đối chiếu lại bản đặc tả yêu cầu phần mềm với mục tiêu và yêu cầu của các bên liên quan

- Requirement Verification (Kiểm chứng yêu cầu)

Đây là việc kiểm tra rằng có phải một sản phẩm đang được xây dựng đúng hay không Cần chắc chắn rằng mỗi bước được cho phép trong quá trình xây dựng phần mềm đều mang lại lợi ích cho việc xây dựng sản phẩm đúng Việc này được tiến hành thông qua đối chiếu đối tượng được tạo ra theo bản đặc tả yêu cầu phần mềm với bản đặc tả đó

Sự khác nhau của hai công việc trên chính là ở vai trò của bản đặc tả yêu cầu phần mềm Với xác nhận yêu cầu, bản đặc tả yêu cầu phần mềm

được kiểm tra xem có phản ánh chính xác các yêu cầu của những bên liên quan hay không Còn với kiểm chứng yêu cầu, bản đặc tả yêu cầu được dùng làm mẫu để đánh giá phần mềm đang xây dựng có phù hợp hay không

Trang 4

Các so sánh cụ thể:

Xác nhận yêu cầu

(Requirements Validation)

Kiểm chứng yêu cầu (Requirements Verification)

Xác nhận yêu cầu là các thủ tục kiểm

tra động (thay đổi theo diễn biến của

dự án, tùy vào các bên liên quan), có

tác dụng để sửa chữa đặc tả yêu cầu

Kiểm chứng yêu cầu là các thủ tục kiểm tra tĩnh (có các quy tắc cho sẵn để áp dụng), có tác dụng ngăn ngừa sự sai khác của phần mềm với đặc tả

Là quá trình mang tính chủ quan của

các bên liên quan, phụ thuộc rất

nhiều vào đánh giá của người dùng

Là quá trình mang tính khách quan, các tiêu chuẩn kĩ thuật được áp dụ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 phí thấp nếu chưa tạo ra sản

phẩm), nếu sản phẩm đã được tạo ra

thì chi phí khắc phục rất cao

Khi phát hiện lỗi, việc sửa chữa tốn ít chi phí

1.2 Ảnh hưởng của Xác nhận yêu cầu (Requirements Validation)

Xác nhận yêu cầu là công việc quan trọng trong quá trình phân tích và đặc tả yêu cầu phần mềm

- Những ảnh hưởng của Xác nhận yêu cầu:

+ Việc xác nhận yêu cầu giúp cho các yêu cầu được đặc tả luôn phản ánh đúng nguyện vọng của các bên liên quan Các khách hàng, người dùng được cung cấp bản chạy được của phần mềm và được dùng thử để xem đã đáp ứng được đúng yêu cầu của mình chưa Nếu có bất cứ phát hiện nào, các lỗi đó sẽ được thông báo cho người phát triển để chỉnh sửa Việc này đảm bảo khi sản phẩm được tạo ra sẽ đáp ứng đúng yêu cầu người dùng, và được chấp nhận

+ Việc xác nhận yêu cầu tạo ra sự nhất trí, tin tưởng giữa các bên liên quan, tạo định hướng thống nhất cho giai đoạn thiết kế, viết mã nguồn hệ thống

+ Lỗi của quá trình Xác nhận yêu cầu phát hiện ra dẫn đến sự thay đổi của bản đặc tả yêu cầu phần mềm, dẫn đến một loạt phản ứng dây chuyền, làm thay đổi từ khâu phân tích thiết kế tới viết mã nguồn

1.3 Ảnh hưởng của Kiểm chứng yêu cầu (Requirements Verification)

Kiểm chứng yêu cầu phần mềm được tiến hành thiết kế và lập trình sản phẩm phần mềm

- Những ảnh hưởng của Kiểm chứng yêu cầu:

+ Kiểm chứng yêu cầu giúp phần mềm được tạo ra đúng với đặc tả của yêu cầu phần mềm Nếu phát hiện ra lỗi, những nhà phát triển phần mềm sẽ

Trang 5

được thông báo để sửa chữa, do đó đảm bảo rằng khi phần mềm được hoàn thành thì nó sẽ phù hợp với các đặc tả yêu cầu

+ Việc kiểm chứng yêu cầu giúp rà soát lỗi của những người thiết kế, lập trình, qua đó nâng cao ý thức làm việc cẩn trọng, nghiêm túc của đội ngu phát triển phần mềm

+ Trong giai đoạn thiết kế, Kiểm chứng yêu cầu giúp điều chỉnh những bản thiết kế hệ thống một cách chính xác, tối ưu Các lỗi tạo ra được điều chỉnh trước khi giao cho đội ngu lập trình, làm giảm đáng kể chi phí sửa lỗi + Trong giai đoạn cài đặt, Kiểm chứng yêu cầu giúp điều chỉnh những lỗi lập trình ngay từ các mức thấp, làm giảm chi phí sửa lỗi bởi tránh được việc lan truyền lỗi

+ Các lỗi được phát hiện của Kiểm chứng yêu cầu thường không gây phản ứng dây chuyền, chỉ dẫn đến việc sửa đổi một hoặc một số module của hệ thống

Trang 6

2 Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Simple Check

2.1 Quy trình thực hiện

• Người kiểm duyệt, kiểm soát yêu cầu phải có các kiến thức từ trước (các phản hồi từ khách hàng )

• Quan sát xem có những cái gì sai lệch trong hệ thống hiện tại

• Mô hình hóa : Mô tả và giải thích vấn đề

• Phân tích và kiểm tra các đặc tính của mô hình

2.2 Thời gian thực hiện

Kỹ thuật simple check là kỹ thuật kiểm tra sự khác nhau bằng cách truy xuất nguồn gốc của yêu cầu vì vậy kỹ thuật simple check được thực hiện trong mọi giai đoạn phát triển của phần mềm

2.3 Tác nhân tham gia

• Lập trình viên

• Bộ phận kiểm thử

• Nhà quản lý dự án

3 Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm prototyping

Kỹ thuật Prototyping là một kỹ thuật xây dựng một kiến trúc được cài đặt cụ thể trước để các khách hàng, người dùng hoặc nhà phát triển có thể hiểu rõ thêm về một vấn đề hay giải pháp của nó

Các hướng tiếp cận của Prototyping:

• Bản mẫu trình diễn: Dùng để chứng minh các khái niệm, giải thích các đặc tính thiết kế

• Bản mẫu thăm dò : dùng để xác định vấn đề, thu thập nhu cầu, làm rõ mục tiêu, so sánh các lựa chọn thiết kế

• Bản mẫu thử nghiệm : khai thác các đặc tính kỹ thuật, kiểm tra sự thích hợp của một kỹ thuật

• Bản mẫu tiến triển : được phát triển khi thấy tiến trình tiếp diễn sẽ tương thích với hệ thống

3.1 Quy trình thực hiện

• Lựa chọn các nguyên mẫu để thử nghiệm

Trang 7

• Sau khi đã lựa chọn được các nguyên mẫu để thử nghiệm thì xây dựng các kịch bản thử nghiệm

• Cần phải có một kế hoạch cụ thể để xây dựng các kịch bản thử

nghiệm sao cho bao quát toàn bộ các yêu cầu phần mềm

3.2 Thời gian thực hiện

Kỹ thuật prototyping để trợ giúp cho việc xác định yêu cầu phần mềm nên được thực hiện đồng thời với quá trình xác định yêu cầu phần mềm

3.3 Tác nhân tham gia

• Lập trình viên

• Bộ phần kiểm thử

• Nhà quản lý dự án

Trang 8

4 Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Functional test design

4.1. Quy trình thực hiện.

 Xác định các chức năng mà phần mềm dự kiến sẽ thực hiện

 Tạo ra các dữ liệu đầu vào dựa trên thông số kỹ thuật của chức năng

 Xác định đầu ra dựa trên thông số kỹ thuật củ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 dụng làm việc theo nhu cầu của khách hàng

4.2. Thời gian thực hiện.

Functional test design là một cách tiếp cận kiểm tra, trong đó trường hợp thử nghiệm, điều kiện và dữ liệu có nguồn gốc từ các yêu cầu Nó bao gồm các bài kiểm tra chức năng và cung thuộc tính không có chức năng như hiệu suất, độ tin cậy hoặc khả năng sử dụng

Thử ngiệm chức năng (functional testing) còn gọi là thử nghiệm hộp đen (black box testing) là sự thử nghiệm sử dụng các ca thử nghiệm được thiết kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết Thử nghiệm chức năng nhìn nhận

mô đun được thử nghiệm như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của mô đun, tức là kiểm tra xem có hoạt động đúng với đặc tả hay không Các ca kiểm thử bao gồm các trường hợp bình thường và không bình thường (dữ liệu không hợp lệ ) của mô đun Thông thường, không thể thử nghiệm với mọi dữ liệu, chiến lược chung khi thiết kế dữ liệu thử nghiệm là phân hoạch (dữ liệu) tương đương Phân hoạch tương đương chia miền dữ liệu vào ra thành các vùng, mà mỗi vùng chứa các dữ liệu có cùng hành vi Do đó, đối với mỗi vùng dữ liệu chỉ cần xây dựng một ca thử nghiệm Thêm vào đó

Trang 9

là các ca sử dụng đối với biên giới của các vùng Theo kinh nghiệm, các sai sót về lập trình thường sảy ra đối với các dữ liệu biên

Kiểm tra chức năng ở cấp độ hệ thống phải được phát triển sớm hay muộn ?

- Có 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 có một thử nghiệm liên quan

- Không chức năng (ví dụ, độ tin cậy) hoặc độc quyền (ví dụ, xác định những gì nên không xảy ra) yêu cầu là khó khăn hơn để xác nhận với các thử nghiệm

- 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 của nó - 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 xét nghiệm này có thể phát hiện sai sót trong đặc điểm kỹ thuật (ngay cả trước khi thiết kế và xây dựng hệ thống)!

- Thiếu thông tin hoặc không rõ ràng trong bản mô tả yêu cầu có thể làm cho nó khó khăn để xây dựng các bài kiểm tra

• Một số quy trình phát triển phần mềm (ví dụ như phương pháp nhanh nhẹn) bắt đầu với các bài kiểm thử trước khi trình phát triển phần mềm.(lập trình)

4.3. Tác nhân tham gia.

 Khách hàng

 Bộ phận lập trình

 Bộ phận kiểm thử

 Người quản lí dự án

4.4. Công cụ điển hình

 Dialog map

 Test case

Trang 10

 Ma trận theo dõi các trường hợp sử dụng

Trang 11

5 Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm User manual

Development.

5.1. 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 nó được thực hiện

• Làm thế nào để có được ra khỏi rắc rối

• Những bộ phận của hệ thống đã không được thực hiện

5.2. Thời gian thực hiện

• Giống như thiết kế thử nghiệm chức năng

• Có phải được thực hiện tại một số điểm

• Tiết lộ các vấn đề trước đó

• Buộc một cái nhìn chi tiết yêu cầu

• Đặc biệt hữu ích nếu các ứng dụng giàu giao diện người dùng / cho các yêu cầu khả năng sử dụng

Phác thảo sổ tay người dùng ngay từ sớm trong quy trình phát triển yêu cầu

và dùng nó như là tài liệu đặc tả yêu cầu hoặc như một trợ giúp cho phân tích yêu cầu Một tài liệu sổ tay người dùng tốt sẽ mô tả tất cả các chức năng

mà người dùng thấy được (user – visible functionality) bằng một ngôn ngữ dễ hiểu Các yêu cầu khác như các thuộc tính chất lượng, yêu cầu hiệu suất, chức năng không thấy được đối với người dùng (not visible to users) sẽ được tài liệu hoá trong SRS

5.3. Tác nhân tham gia

• Các PTV

• Các đại diện của NSD (Product champions)

• Tất cả các thành viên của công ty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm:LTV, các nhà kiểm thử, v.v

5.4. Công cụ điển hình

• Một số phần mềm soạn thảo văn bản

• Phần mềm đồ họa

• Một số mẫu hướng dẫn sử dụng có sẵn

Trang 12

6 Kỹ thuật duyệt và kiểm soát yêu cầu phần mềm Reviews and

Inspections

Một nhóm các kỹ sư phần mềm, kỹ sư hệ thống và người có kinh nghiệm trong lĩnh vực yêu cầu phần mềm sẽ cùng đọc và phân tích các yêu cầu, tìm

ra các vấn đề tiềm tàng để thảo luận, và thống nhất với nhau các công việc cần làm để giải quyết những vấn đề đó

Đây là một kỹ thuật kiểm chứng yêu cầu được sử dụng rộng rãi Có rất nhiều bằng chứng về tính hiệu quả của kỹ thuật này

Kỹ thuật này có thể rất tốn kém:

• Cần chuẩn bị và lên kế hoạch cẩn thận

• Cần kiểm tra trước khi duyệt

• Cần một danh sách kiểm duyệt phù hợp

Một số kỹ thuật kiểm duyệt và kiểm soát yêu cầu phần mềm:

Phân theo hình thức

1 Đọc văn bản yêu cầu phần mềm: Yêu cầu một người không là tác

giả của văn bản yêu cầu phần mềm đó đọc và kiểm duyệt

2 Đọc và phê duyệt: Khuyến khích người kiểm duyệt đọc cẩn thận

hơn và có trách nhiệm hơn

3 Đọc lướt: Đây là kỹ thuật không chính thức, ở mức tổng quát

cao, đọc để có cái nhìn tổng quát về văn bản yêu cầu Kỹ thuật này có thể cần phải được dẫn dắt bởi tác giả văn bản/chuyên gia

4 Kỹ thuật kiểm duyệt chính thức (Formal Inspections): kiểm

duyệt một cách chi tiết, cụ thể và có cấu trúc Xác định rõ ràng vai trò của những người tham gia kiểm duyệt cung như xác dịnh

rõ điều kiện để kết thúc việc kiểm duyệt

5 Kiểm duyệt tập trung: Các chuyên viên kiểm duyệt có vai trò xác

định, mỗi chuyên viên chỉ tìm kiếm một số lỗi nhất định trong yêu cầu phần mềm

6 Kiểm duyệt tích cực: Tác giả văn bản sẽ hỏi trực tiếp các chuyên

viên kiểm duyệt các câu hỏi liên quan đến văn bản

6.1. Quy trình thực hiện

1Plan review

Đội kiểm duyệt được lựa chọn, thời gian, địa điểm gặp mặt cung được ấn định

2Phân phát tài liệu liên quan

Văn bản yêu cầu phần mềm được phân phát cho các thành viên đội kiểm duyệt

Trang 13

3Chuẩn bị cho việc kiểm duyệt các yêu cầu

Mỗi thành chuyên viên kiểm duyệt đọc các yêu cầu để tìm ra các xung đột, thiếu sót, mâu thuẫn, lệch chuẩn và các vấn đề khác

4Tổ chức gặp mặt

Các vấn đề và nhận xét của mỗi cá nhân về văn bản yêu cầu phần mềm sẽ được đưa ra thảo luận, và các việc cần làm để giải quyết các vấn đề sẽ được đưa ra

5Thực hiện các việc cần làm (kết quả của bước 4)

Giải quyết các vấn đề bằng cách tuân thủ thực hiện các hành động đã thống nhất ở bước 4

6Duyệt lại văn bản

Văn bản yêu cầu phần mềm được duyệt lại để kiểm chứng sự hợp lý của các hành động đã thống nhất Kết quả của bước này, hoặc là văn bản cuối cùng được chấp nhận, hoặc là cần được kiểm duyệt lại

Đôi khi, để giảm thiểu chi phí của quá trình kiểm duyệt yêu cầu, cần phải thực hiện bước "pre-review checking" Nghĩa là kiểm tra văn bản và tìm kiếm các vấn đề trực tiếp, như là thiếu yêu cầu phần mềm, thiếu tuân thủ theo chuẩn, …

6.2. Thời gian thực hiện

Có thể áp dụ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 Khi đó, các vấn đề vẫn còn tồn tại trong các yêu cầu phần mềm Và cần phải loại bỏ các vấn đề này trước khi đem văn bản yêu cầu đi thương thảo

Áp dụng khi cần xác minh rằng các yêu cầu mình viết ra sẽ thỏa mãn các bên liên quan Hay nói cách khác, tìm sự đồng thuận từ phía khác hàng

6.3. Tác nhân tham gia

• Những người đến từ những lĩnh vực khác nhau sẽ mang đến những

kỹ năng và kiến thức khác nhau để kiểm duyệt các yêu cầu phần mềm

• Họ sẽ cảm thấy được tham gia và có vai trò trong quá trình xây dựng yêu cầu phần mềm, và họ sẽ hiểu hơn về nhu cầu/yêu cầu của các bên còn lại

• Nhóm kiểm duyệt luôn luôn có ít nhất một bên chuyên gia, một bên người dùng

Định dạng
Số trang	15
Dung lượng	261,42 KB