Trang_danh_cho_Sinhvien - Nguyễn Thế Dũng Chapter3

Trang_danh_cho_Sinhvien - Nguyễn Thế Dũng Chapter3 tài liệu, giáo án, bài giảng , luận văn, luận án, đồ án, bài tập lớn...

MÔN HỌC

CÔNG NGHỆ PHẦN MỀM

Chương 3

Phân tích: Xác định Yêu cầu

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM

Phân tích: Xác định Yêu cầu

3.1 yêu cầu

3.1.1 yêu cầu 3.1.2 phân loại yêu cầu

3.2 Quy trình xác định yêu cầu

3.2.1 Phân tích khả thi 3.2.2 Phát hiện và phân tích yêu cầu 3.2.3 Đặc tả yêu cầu

3.2.4 Đánh giá yêu cầu

3.3 Quản lý yêu cầu

Giai đoạn phân tích

ƒ Mô tả những gì khách hàng yêu cầu

ƒ Thiết lập một nền tảng cho thiết kế phần mềm

ƒ Xác định một tập những yêu cầu mà có thể thẩm định khi phần mềm được xây dựng

system description

analysis model

design model

Quá trình phân tích

the problem requirements elicitation

build a prototype

create analysis models

develop Specification Review

Phân tích yêu cầu

• Phân tích yêu cầu

ƒ Xác định các đặc trưng của phần mềm

ƒ Xác định giao tiếp của phần mềm với những thành

phần khác

ƒ Thiết lập những ràng buộc mà phần mềm phải có

• Phân tích yêu cầu cho phép những kỹ sư phần mềm (analyst hay modeler):

ƒ Dựng nên những yêu cầu cơ bản dựa vào những yêu cầu thu thập trước đó

ƒ Xây dựng những mô hình kịch bản người, hoạt động

chức năng, lớp và quan hệ của chúng, hành vi hệ thống

và lớp, và luồng dữ liệu.

3.1.1 Yêu cầu

những dịch vụ mà khách hàng yêu cầu đối với hệ

thống cùng với những ràng buộc cho việc hoạt động

ƒ Yêu cầu cần:

• Phải rõ ràng, có thể là cơ sở cho việc xác định giá cả

• Phải trình bày chi tiết, có thể là cơ sở cho việc thực

Mức độ mô tả yêu cầu

ƒ Viết cho người dùng

ƒ Thường bằng ngôn ngữ tự nhiên cộng với các biểu đồ

ƒ Mô tả các dịch vụ và những ràng buộc hoạt động

Vd: xác định và đặc tả

Người đọc

3.1.2 Phân loại yêu cầu

• Yêu cầu chức năng: chức năng dịch vụ hệ thống

cung cấp

• Yêu cầu phi chức năng: những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…

• Yêu cầu miền ứng dụng: phản ảnh những đặc

trưng của miền ứng dụng

Yêu cầu chức năng

ƒ Chức năng tính toán

ƒ Chức năng lưu trữ

ƒ Chức năng tìm kiếm

ƒ Chức năng kết xuất

ƒ Chức năng backup, restore

ƒ Chức năng đa người dùng

ƒ Chức năng đa phương tiện…

Ví dụ

báo

thể copy để lưu trữ tài liệu lâu dài

Yêu cầu phi chức năng

ƒ Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ…

ƒ Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình…

ƒ Yêu cầu của người sử dụng

ƒ Ràng buộc về ngân sách

ƒ Các chính sách của tổ chức sử dụng hệ thống

ƒ Yêu cầu tương thích giữa phần cứng và phần mềm

ƒ Các tác nhân ngoài khác…

Phân loại yêu cầu phi chức năng

• Các yêu cầu về sản phẩm : hiệu năng, khả năng sử

dụng, độ tin cậy…

• Các yêu cầu của tổ chức sử dụng hệ thống : thời gian bàn giao, yêu cầu phù hợp với hệ thống cũ…

• Các yêu cầu ngoài: được xác định từ các tác nhân

từ bên ngoài như các yêu cầu về luật pháp, yêu cầu tôn trọng tính riêng tư…

Yêu cầu phi chức năng

Ví dụ

• Yêu cầu sản phẩm: giao diện người dùng không

chứa frame và applet java

• Yêu cầu tổ chức: qui trình phát triển hệ thống và tài liệu phân phối phải phù hợp theo tiêu chuẩn “STAN- 95”

• Yêu cầu ngoài: hệ thống không được lộ thông tin

của khách hàng

Mục tiêu (Goal) và đo lường (measure)

• Người dùng có kinh nghiệm có thể sử dụng tất cả các chức năng sau 2 giờ huấn luyện Sau khi huấn luyện người dùng có kinh nghiệm sẽ không có lỗi trung bình quá 2 lỗi/ngày

Đo lường

Property Measure

Speed Processed transactions/second

User/Event r esponse time Screen refresh time

Robustness Time to restart after failure

Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements

Number of target systems

Tranh chấp giữa các yêu cầu phi chức năng

ƒ Để trọng lượng thấp và lượng điện tiêu thụ thì cần phải dùng những chip có trọng lượng nhỏ và tiêu thụ năng lượng thấp

ƒ Nhưng có thể phải sử dụng nhiều chip hơn

Yêu cầu miền ứng dụng

ứng dụng của hệ thống nó phản ánh các thuộc tính

và ràng buộc của lãnh vực ứng dụng

quyền vài tài liệu phải được xóa ngay

Các vấn đề về yêu cầu miền ứng dụng

ƒ Yêu cầu cần diễn đạt theo ngôn ngữ miền ứng

dụng, khó hiểu cho người phát triển

• Ẩn ý

ƒ Những chuyên gia miền thường quá thuộc trong lãnh vực của mình nên họ thường làm những yêu cầu miền không tường minh

dựa vào ngôn ngữ Prolog

ƒ Thời gian xử lý : tiền mặt phải giao trước 16h30

ƒ Thời gian yêu cầu cho xử lý ngoài : báo cáo hàng tháng phải gởi trước ngày 4 của tháng sau

ƒ Thời gian đáp ứng qua giao diện : khi người dùng enter thì hệ thống phải hồi đáp trong vòng 2 giây

3.2 Qui trình xác định yêu cầu

• Qui trình xác định yêu cầu (Requirements

engineering- RE)

Mô hình xoắn ốc

3.2.1 Phân tích khả thi

ƒ Xác định hệ thống có đóng góp vào mục tiêu của

tổ chức hay không

ƒ Kiểm tra xem hệ thống có thể được xây dựng bằng cách sử dụng công nghệ hiện tại và ngân sách cho phép.

ƒ Kiểm tra xem liệu hệ thống có được tích hợp với

các hệ thống khác đang sử dụng hay không.

Phân tích khả thi

ƒ Nếu hệ thống không được cài đặt thì sao?

ƒ Vấn đề xử lý hiện tại như thế nào?

ƒ Hệ thống đề xuất sẽ trợ giúp theo cách thức nào?

ƒ Những rắc rối về việc tích hợp là gì?

ƒ Có cần kỹ thuật mới không? Đòi hỏi kỹ năng gì?

ƒ Cần có những kỹ năng gì?

ƒ Hệ thống đề nghị hỗ trợ những tiện ích gì?

3.2.2 Phát hiện và phân tích yêu cầu

thể xuất hiện những nhân tố mới, những thay đổi về môi trường nghiệp vụ

Stakeholder của hệ thống ATM

Các hoạt động của qui trình

• Phát hiện yêu cầu: tiếp xúc với các stakeholder để

phát hiện ra các yêu cầu của họ bao gồm các yêu cầu miền ứng dụng

• Phân loại và sắp xếp yêu cầu: nhóm các yêu cầu có

liên quan lẫn nhau và tổ chức chúng thành những

nhóm gắn kết

• Sắp thứ tự ưu tiên và điều chỉnh các yêu cầu: định thứ

tự ưu tiên của các yêu cầu, phát hiện và giải quyết

xung đột giữa các yêu cầu.

• Tư liệu hóa yêu cầu (documentation)

Các hoạt động của qui trình

Khung nhìn (Viewpoint)

thống, nó biểu diễn các vấn đề về hệ thống dưới

những góc nhìn khác nhau của các stakeholder

toàn diện hơn

Phân loại khung nhìn

ƒ Người và những hệ thống khác tương tác trực tiếp với hệ thống

ƒ Những người có thể không dùng hệ thống nhưng ảnh hưởng tới hệ thống

ƒ Những đặc trưng và ràng buộc của miền mà ảnh hưởng tới yên cầu

VD: Hệ thống cấp bậc của khung nhìn

Phỏng vấn

những phần quan trọng nhất của quy trình xác định yêu cầu

ƒ Phỏng vấn đóng: tập các câu hỏi đã được định

nghĩa trước và có nhiều đáp án để stakeholder lựa chọn trả lời.

ƒ Phỏng vấn mở: tất cả các vấn đề không được xác định trước và stakeholder phải tự giải thích và

phát biểu theo quan điểm của mình.

Phỏng vấn (tt)

ƒ Thu thập được tất cả các hiểu biết về công việc

phải làm của stakeholder

ƒ Nắm rõ họ tương tác với hệ thống như thế nào.

được các thuật ngữ của miền ứng dụng, việc diễn

đạt.

ƒ Cởi mở, sẵn sàng lắng nghe stakeholder

ƒ Không có định kiến

ƒ Đưa ra những câu hỏi gợi mở, thân thiện.

Kỹ thuật phỏng vấn

ƒ Ai là người đưa đến những yêu cầu?

ƒ Ai là người sử dụng giải pháp ?

ƒ Giải pháp thành công sẽ mang đến những lợi ích gì ?

ƒ Có thể có cách khác để thực hiện giải pháp ?

ƒ Giải pháp tốt sẽ có output như thế nào ?

ƒ Những vấn đề giải pháp cần giải quyết ?

ƒ Hãy cho biết môi trường của giải pháp ?

ƒ Những vấn đề về thực thi và những ràng buộc ảnh hưởng ?

ƒ Tôi đã hỏi quá nhiều câu hỏi ?

ƒ Những ai có thể cung cấp những thông tin thêm ?

ƒ Tôi có nên hỏi bạn những điều gì khác ?

Các bước phỏng vấn

ƒ Giới thiệu về bản thân

ƒ Sử dụng câu hỏi mở để bắt đầu

ƒ Luôn chú ý câu trả lời

ƒ Có kế hoạch cho nội dung chính

ƒ Kết hợp câu hỏi mở và đóng

ƒ Bám sát trình bày và phát triển chi tiết

Các bước phỏng vấn (tt)

ƒ Luôn cung cấp thông tin phản hồi

ƒ Hạn chế ghi chép

ƒ Có kế hoạch kết thúc

ƒ Tóm tắt nội dung, yêu cầu hiệu chỉnh

ƒ Cho biết ngày họ nhận báo cáo

ƒ Thống nhất ngày lấy lại bản hiệu chỉnh

ƒ Xác nhận lại lịch làm việc

Soạn câu hỏi

ƒ Nhiều hơn 2 câu hỏi về một vấn đề

ƒ Câu hỏi tối nghĩa

ƒ Câu hỏi không có câu trả lời

ƒ Câu hỏi tạo định hướng

ƒ Không xác định được hết các trường hợp trả lời

ƒ Gây nhầm lẫn về thứ tự trả lời

Soạn câu hỏi (tt)

chỉ

Kỹ thuật đặc tả ứng dụng thuận tiện (FAST)

Facilitated Application Specification Techniques

Software Engineering Group

Customer Group

Hướng dẫn FAST

bộ cuộc họp

chuộng

J Wood & D Silver

3.2.3 Đặc tả yêu cầu

Everyone knew exactly what had to be done until someone wrote it down!

Đặc tả yêu cầu

• Đặc tả bằng ngôn ngữ tự nhiên

ƒ Đặc tả yêu cầu của hệ thống bằng ngôn ngữ tự

nhiên thường gặp một số vấn đề sau:

• Không rõ ràng: Ngôn ngữ tự nhiên có thể diễn đạt phong phú nhưng thiếu chính xác

• Quá mềm dẻo: với cùng một vấn đề nhưng có nhiều cách khác nhau để đặc tả

• Thiếu tính cấu trúc

specifications These are no tations based on mathematical concep ts such as finite-state machines orsets These unambiguous specifications reduce the argu ments between customer and

con tractor abou t system func tionality Howeve r, most customers don’t unde rstand formal specifications and a re reluctant to accept it as a system contract.

Hướng dẫn viết yêu cầu

• Đưa ra một định dạng mẫu

• Dùng ngôn ngữ một cách nhất quán

• Phải đánh dấu làm nổi bật phần chính của yêu cầu

• Tránh dùng thuật ngữ máy tính

Đặc tả bằng ngôn ngữ có cấu trúc

nhiên nhưng có sự đồng nhất

Đặc tả dựa vào biểu mẫu

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level

Description Computes the dose of insulin to be delivered wh en the current measured sugar level is in the safe zone between 3 and 7 units.

Inputs Current sugar re ading (r2), the previous two readings (r0 and r1)

Source Current sugar re ading from sensor Other re adings from memory.

Outputs CompDose Š the dose in insulin to be delivered

Destination Main control loop

Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of

increase is decreasing If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result If the result, is rounded to zero then CompDose is set to the minimum dose that can

be delivered.

Requires Two previous readings so that the rate of change of sugar level can be computed.

Pre -condition The insulin reservoir contains at least the maximum allowed single dose of insulin

Post-condition r0 is replaced by r1 then r1 is replaced b y r2

Side-effects None

Đặc tả dạng bảng

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of

increase decreasing ((r2-r1)<(r1-r0))

CompDose = 0

Sugar level increasing and rate of

increase stable or increasing ((r2-r1)

(r1-r0))

CompDose = round ((r2-r1)/4)

If rounded result = 0 then CompDose = MinimumDose

NGÔN NGỮ PDL

từ vựng của ngôn ngữ tự nhiên và cú pháp của ngôn ngữ lập trình có cấu trúc Nó có các tính chất sau

ƒ Cú pháp chặt chẽ của các từ khoá hỗ trợ đặc tả

cấu trúc, khai báo dữ liệu, phân chia module

ƒ Cú pháp tự do của ngôn ngữ tự nhiên giúp miêu tả

NGÔN NGỮ PDL (t.t)

procedure AnalyzeTriangle( a, b, c: in real;

type: out string)

Đặc tả theo mô hình

Cấu trúc tài liệu yêu cầu (ht)

Tài liệu đặc tả theo IEEE

• 3 Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi

chức năng, miền ứng dụng và giao diện

• 4 Phụ lục

• 5 Chỉ mục

Tài liệu: Người dùng

3.2.4 Đánh giá yêu cầu

với những gì khách hành thật sự muốn

việc sửa chữa lỗi yêu cầu sau khi xuất xưởng cao đến

100 lần chi phí sửa lỗi lúc cài đặt (implementation)

Các thuộc tính cần kiểm tra

• Giá trị (validity): Hệ thống cung cấp các chức năng và dịch vụ đáp ứng nhu cầu của khách

hàng

• Toàn vẹn (Consistency): xem xét sự tranh chấp giữa các yêu cầu

• Đầy đủ (Completeness): Xác định đầy đủ các

chức năng mà khách háng yêu cầu

• Hiện thực (Realism): phù hợp với ngân sách và

kỹ thuật

• Kiểm tra được (Verifiability): những yêu cầu có thể kiểm chứng được

Kỹ thuật đánh giá yêu cầu

ƒ Phân tích thủ công có tính hệ thống

ƒ Dùng mô hình có thể thực thi

ƒ Những tình huống kiểm tra khó hay không thể

được thiết kế thì những yêu cầu sẽ khó thực hiện

3.3 Quản lý yêu cầu

các yêu cầu trong quá trình phát hiện yêu cầu và phát triển hệ thống.

là do:

ƒ Những yêu cầu mới xuất hiện khi các yêu cầu

nghiệp vụ thay đổi và khi chúng ta có hiểu biết sâu hơn về hệ thống sẽ xây dựng.

ƒ Các yêu cầu thường xuất hiện các mâu thuẫn do

khung nhìn khác nhau, khách hàng thường đặc tả sai về yêu cầu của stakeholder

ƒ Thứ tự ưu tiên của yêu cầu thay đổi trong quá trình phát triển hệ thống.

ƒ Môi trường nghiệp vụ và môi trường kỹ thuật của

Yêu cầu lâu dài và yêu cầu biến động

thay đổi.

đổi trong quá trình xây dựng hoặc khi hệ thống

được đưa vào sử dụng.

Kế hoạch quản lý yêu cầu

định những hoạt động nhằm cập nhật đúng đắn những thay đổi mà không xáo trộn hệ thống

hiện tại, giảm thiểu chi phí

Quản lý thay đổi

ƒ Những điều kiện về thị trường cũng như việc kinh doanh ép buộc một sự thay đổi yêu cầu về sản

phẩm cũng như những qui tắc kinh doanh.

ƒ Những khách hàng thay đổi yêu cầu: dữ liệu tạo ra

từ những hệ thống thông tin, những chức năng

của sản phẩm, những dịch vụ được cung cấp từ

những hệ thống.

ƒ Tái tổ chức lại đơn vị, tăng, giảm qui mô kinh

doanh tạo ra sự thay đổi trong những ưu tiên dự

án hay cấu trúc nhóm dự án phần mềm.

ƒ Những ràng buộc về tài chánh cũng như lịch trình buộc phải xác định lại hệ thống hay sản phẩm.

Các bước Quản lý thay đổi

• Phân tích vấn đề: Nghiên cứu những vấn đề về yêu cầu và đề xuất những thay đổi

• Phân tích thay đổi và dự tính chi phí: một thay đổi này có thể kéo theo nhiều sự thay đổi khác.

• Cài đặt thay đổi: Điều chỉnh tài liệu của các yêu

cầu và những tài liệu khác để phản ánh sự thay đổi đó.

Quản lý thay đổi

Nguyên nhân của khiếm khuyết

Nguyên nhân của khiếm khuyết đặc tả

Hệ thống phân loại hàng