Cnpm c2 phan tich

phân tích công nghệ phần mềm giúp chúng ta hiểu thêm về cách xây dựng phần mềm và chỉnh sửa chúng file này còn cho ta thêm các bước cơ bản về làm nên một trang web đơn giản và các phương pháp, từng bước để làm

Chương 2 Phân tích và đặc tả yêu cầu

Nội dung

II Các loại yêu cầu

III Xác định và đặc tả yêu cầu

I Đại cương

II Các loại yêu cầu

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

Mô tả các chức năng (dịch vụ) mà phần mềm sẽ cung cấp Gồm

 Yêu cầu chức năng nghiệp vụ

Công việc có thật trong thế giới thực, có 4 loại

nghiệp vụ thông dụng trong các lĩnh vực: lưu trữ, tra cứu, tính toán, kết xuất

 Yêu cầu chức năng hệ thống

Công việc phát sinh do sử dụng máy tính như:

phân quyền, sao lưu/phục hồi, cấu hình, báo động nhắc nhở

Các loại yêu cầu (tt)

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

 Các ràng buộc về chất lượng, môi trường, chuẩn sử dụng, qui trình phát triển…

phân tích

 Ví dụ:

 Yêu cầu về sản phẩm

 Yêu cầu của tổ chức

 Yêu cầu ngoài

Các loại yêu cầu (tt)

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

III Xác định và Đặc tả yêu cầu

Qui trình xác định yêu cầu (tt)

các tài liệu yêu cầu của hệ thống

thuộc vào miền ứng dụng, con người và tổ chức xây dựng yêu cầu

số hoạt động sau: phát hiện yêu cầu, phân tích

yêu cầu, đánh giá yêu cầu và quản lý yêu cầu

 Trong thực tế, các yêu cầu luôn luôn thay đổi, thậm chí ngay khi đang xây dựng hệ thống

định các yêu cầu

Qui trình xác định yêu cầu (tt)

Quy trình thu thập và phân tích yêu cầu

Quy trình thu thập và phân tích yêu cầu

 Thu thập yêu cầu (Requirements discovery)

 Phải trao đổi với khách hàng thu thập hết các yêu cầu của họ

 Phân loại và quản lý yêu cầu (Requirements

classification and organisation)

 Tổ chức phân loại, gom nhóm các yêu cầu sao cho dễ quản lý

 Sắp xếp và điều chỉnh yêu cầu (Prioritisation and

negotiation)

 Sắp xếp thứ tự các yêu cầu và điều chỉnh các yêu cầu mâu

thuẫn

 Đặc tả yêu cầu (Requirements specification)

 Đặc tả (Tài liệu hóa) các yêu cầu để chuyển qua giai đoạn kế tiếp

Các phương pháp thu thập yêu cầu

Chiến lược thu thập

 Gồm các yếu tố sau:

 Các nguồn thông tin thu thập

 Các phương pháp áp dụng cho mỗi nguồn thông tin

Các khó khăn

 Khách hàng chỉ có khái niệm mơ hồ

 Khách hàng hay thay đổi yêu cầu

 Các yêu cầu có tính đặc thù

 Hệ thống nhiều người dùng

 Người đặt hàng có thể khác người dùng thật sự

Các phương pháp thu thập (tt)

Nghiên cứu tài liệu

 Đây là một sự quan sát gián tiếp, giúp cho PTV nắm

được những quy trình hoạt động

 Thông qua việc nghiên cứu:

 Thường mất nhiều thời gian ( Có thể quay phim ?! )

 Người bị quan sát thường khó chịu do đó cần sự hợp

tác của mọi người

Các phương pháp thu thập (tt)

tập trung vào một chủ điểm, chi tiết nhất định

thể  mở rộng dần phạm vi

Các phương pháp thu thập (tt)

bày

dụng

theo

Các phương pháp thu thập (tt)

số thuật ngữ chuyên môn

Các phương pháp thu thập (tt)

lời

thông tin về hệ thống

Các phương pháp thu thập (tt)

thiên lệch

cầu

quan tâm của người trả lời

2 Với một dự án chấp thuận được, người phân tích

xây dựng một cách biểu diễn vắn tắt cho yêu cầu

3 Sau khi đã duyệt xét mô hình yêu cầu, tạo ra một

đặc tả thiết kế vắn tắt cho bản mẫu

4 Phần mềm bản mẫu đựợc tạo ra và kiểm

thử

6 Lặp lại các bước 4 và 5 cho tới khi tất cả

các yêu cầu đã được thu thập đầy đủ và chính xác

Các bước làm bản mẫu (tt)

Lợi ích của làm bản mẫu

 Vấn đề thiếu sót các yêu cầu người dùng,

tính dễ sử dụng có thể được thấy ngay

Hạn chế của làm bản mẫu

 Các đặc điểm hệ thống quan trọng có thể nằm

ngoài bản mẫu

 Các yêu cầu phi chức năng như độ tin cậy, tính

mâu thuẫn và độ an toàn không được biểu thị đầy

đủ trong bản mẫu

 Do tính chưa hoàn thiện (về chức năng/hiệu

năng), người dùng có thể không dùng bản mẫu y như cách dùng một hệ thống thực đang hoạt động

 Chi phí cao nếu không tận dụng được các bản

mẫu

Đặc tả yêu cầu (tt)

Tài liệu đặc tả yêu cầu

thức về những gì cần phải thực hiện bởi đội

phát triển hệ thống

nghĩa về yêu cầu của người sử dụng và yêu cầu hệ thống

kế hệ thống Nó chỉ thiết lập những gì hệ thống

phải làm, chứ không phải mô tả rõ làm như thế

nào

Đặc tả yêu cầu (tt)

2 Mô tả chung

2.1 Giới thiệu chung về sản phẩm 2.2 Các chức năng của sản phẩm 2.3 Đặc điểm của người sử dụng 2.4 Các ràng buộc

2.5 Giả thiết và các phụ thuộc

Đặc tả yêu cầu (tt)

3 Đặc tả yêu cầu:

3.1 Yêu cầu về giao diện 3.2 Yêu cầu chức năng 3.3 Yêu cầu hệ thống

3.4 Ràng buộc thiết kế

3.5 Yêu cầu khác

4 Phụ lục và chỉ mục

IV Thẩm định yêu cầu

Liên quan đến việc kiểm tra tính đúng đắn, tính đầy đủ, tính hiện thực và kiểm tra được của yêu cầu

Cụ thể là trả lời các câu hỏi sau:

Thẩm định yêu cầu (tt)

Các kỹ thuật để thẩm định yêu cầu

1 Rà soát lại các yêu cầu

 Cùng với khách hàng phân tích lại cận thận và có

hệ thống các yêu cầu

 Biểu diễn các yêu cầu thu thập được qua bản mẫu vừa giúp khách hàng thẩm định lại yêu cầu và có thể phát hiện thêm các yêu cầu mới

Quản lý yêu cầu

 Yêu cầu có thể thay đổi do:

 Người trả tiền cho phần mềm và người sử dụng phần mềm hiếm khi là một

 Môi trường nghiệp vụ & kỹ thuật thay đổi

Quản lý thay đổi yêu cầu

 Gán định danh cho các yêu cầu

 Phân tích yêu cầu và các thay đổi của yêu cầu

 Phân tích sự thay đổi và chi phí thay đổi

 Khi chấp nhận thay đổi thì thực hiện thay đổi sao cho dễ dàng

V Phương pháp đặc tả yêu cầu

 Hướng cấu trúc

 Biểu đồ phân rã chức năng (FDD/BFD)

 Biểu đồ luồng dữ liệu (DFD)

Biểu đồ phân rã chức năng

 Tạo nền tảng cho thiết kế kiến trúc hệ thống

Biểu đồ phân rã chức năng (tt)

QL các dự án

Lập kế hoạch

Kế hoạch dài hạn

Kế hoạch ngắn hạn

QL ngân sách

Phân bổ ngân sách

Sử dụng ngân sách

Biểu đồ phân rã chức năng (tt)

Ý nghĩa của FDD

nghiên cứu trong tổ chức

thống Tránh dư thừa hay trùng lắp

trình hệ thống

+

Biểu đồ phân rã chức năng (tt)

Biểu đồ phân rã chức năng – các nguyên tắc

 Nguyên tắc thực chất

Mỗi chức năng được phân rã là một bộ phận thực sự tham gia thực hiện các chức năng đã phân rã ra nó

 Nguyên tắc đầy đủ

Việc thực hiện các chức năng ở mức dưới trực tiếp phải đảm bảo thực hiện được chức năng ở mức trên

+

Biểu đồ phân rã chức năng (tt)

Quy trình xây dựng FDD

 Bước 1: Khảo sát, tìm hiểu tổ chức, các chức

năng nghiệp vụ của tổ chức

 Bước 2 : Mô tả hoạt động của các chức năng

dưới dạng văn bản

 Bước 3 : Dựa vào văn bản mô tả chức năng (ở

bước 2) vẽ sơ đồ FDD

+

Biểu đồ phân rã chức năng (tt)

Biểu đồ phân rã chức năng (tt)

 Chú ý

gì chứ không chỉ ra hệ thống phải làm như thế nào

chức năng quản lý Tất cả chức năng đều quan

trọng và cần xử lý như nhau

+

Biểu đồ phân rã chức năng (tt)

Ví dụ 1: Quản lý bán hàng

 Để quản lý bán hàng, trước hết cty phải tìm kiếm thị trường

Sau khi đã tìm kiếm được khách hàng, cty thực hiện việc ký kết hợp đồng và cuối cùng là giao hàng

 Để tìm kiếm thị trường, cty phải quản cáo và giới thiệu sản

phẩm

 Trong khi ký kết hợp đồng, phải thỏa thuận phương thức thanh

toán và phương thức giao hàng

 Để thực hiện hợp đồng cty phải thực hiện việc giao hàng bằng

cách vận chuyển đến địa chỉ của khách hàng và thu tiền của

khách hàng

+

Biểu đồ phân rã chức năng (tt)

+

Quản lý bán hàng

Tìm kiếm thị trường

Thỏa thuận PT giao hàng

Giao hàng

Vận chuyển hàng

Thu tiền

Biểu đồ phân rã chức năng (tt)

Ví dụ 2: Quản lý tín dụng

 Phòng tín dụng của ngân hàng có nhiệm vụ cho vay và thu nợ

 Khi khách hàng đến vay tiền bộ phận cho vay phải nhận đơn

vay của khách hàng sau đó duyệt đơn xem có đủ điều kiện cho vay hay không rồi chuyển sang bộ phận trả lời đơn Bộ phận trả lời đơn sẽ trả lời khách hàng là từ chối hay chấp nhận cho vay Nếu chấp nhận thì cho vay và đồng thời ghi vào sổ nợ

 Khi khách hàng đến trả tiền thì dựa vào sổ nợ, bộ phận thu nợ

phải xác định kỳ hạn trả nợ của từng khách hàng Nếu trả đúng hạn thì chuyển sang bộ phận xử lý nợ trong hạn Ngược lại

chuyển sang bộ phận xử lý nợ quá hạn Cả 2 bộ phận nầy đều phải ghi vào sổ nợ

+

Biểu đồ phân rã chức năng (tt)

2.2 Xử lý trong hạn

2.3 Xử lý quá hạn

2.4 Ghi sổ nợ

Biểu đồ luồng dữ liệu

 Mô hình luồng dữ liệu là một công cụ mô tả mối quan hệ thông tin giữa các công việc

 Việc xây dựng mô hình luồng dữ liệu là rất cần thiết nhằm mục đích:

 Bổ sung khiếm khuyết của sơ đồ chức năng nghiệp vụ bằng việc bổ sung các luồng thông tin nghiệp vụ

 Cho ta cái nhìn đầy đủ hơn về các mặt hoạt động của hệ thống

 Là một trong số các đầu vào cho quá trình thiết kế hệ thống

 Dùng để xác định nhu cầu thông tin ở mỗi chức năng, cung cấp bức tranh tổng thể của hệ thống và thiết kế sơ bộ về thực hiện các chức năng

 Là phương tiện giao tiếp giữa người phân tích và người sử dụng

50

 Tác nhân: Người, tổ chức, hệ thống khác

 Chức năng xử lý: Thực hiện chức năng nào đó, tiêu thụ

và tạo ra thông tin

 Dữ liệu hay thông tin: Vào hoặc ra khỏi chức năng

 Kho dữ liệu: Lưu trữ dữ liệu được sử dụng bởi nhiều

Biểu đồ luồng dữ liệu (tt)

Ví dụ về DFD: Quản lý tín dụng

 Sơ đồ ngữ cảnh (Mức 0)

+

Quản lý tín dụng

Đơn vay Tiền vay Trả lời

Tiền trả

Biểu đồ luồng dữ liệu (tt)

TT tiền vay TT đối chiếu Tiền còn nợ

Biểu đồ luồng dữ liệu (tt)

Duyệt vay

1.2 Đơn đã kiểm tra

Trả lời

1.3 Đơn đã duyệt

Biểu đồ luồng dữ liệu (tt)

2.1 Xác định kỳ hạn

2.2

Xử lý trong hạn

2.3

Xử lý ngoài hạn

2.4 Ghi nợ

Tiền trả

TT đối chiếu

Nợ trong hạn

Nợ ngoài hạn TT nợ ngoài hạn

Biều đồ thực thể kết hợp

 Thực thể

 Mối quan hệ giữa các thực thể

 Phân tích dữ liệu độc lập với xử lý

Biểu đồ thực thể kết hợp (tt)

 Các ký hiệu

ERD

Biểu đồ thực thể kết hợp (tt)

 Lực lượng tham gia mối quan hệ

Mối quan hệ

59

Làm việc cho

Thể hiện mối quan hệ

NHÂN VIÊN làm việc cho ĐƠN VỊ

Nv1 Nv2 Nv3 Nv4

Đv1 Đv2

Biểu đồ thực thể kết hợp (tt)

 Thực thể:

 Là các danh từ (trong các câu mô tả yêu cầu)

 Có các thuộc tính khóa (xác định duy nhất)

 Hoạt động xẩy ra giữa các thực thể

 Có nghĩa với hoạt động của hệ thống

 Là động từ

Biểu đồ thực thể kết hợp (tt)

chúng

quan hệ

Từ điển dữ liệu

Mục đích

đối tượng được dùng trong hệ thống Cụ thể:

Từ điển dữ liệu (tt)

Định nghĩa luồng dữ liệu

Tên luồng dữ liệu : Hóa đơn

Tên đồng nghĩa : Hóa đơn kiêm phiếu xuất

Tên hàng

Số lượng Thành tiền Giải thích : Giải trình tiền ntrả cho một đơn mua hàng

+

Từ điển dữ liệu (tt)

Định nghĩa dữ liệu sơ cấp

Tên dữ liệu sơ cấp : Ngày mở tài khoản

Mô tả : Là ngày mở tài khoản của một khách hàng

Tên đồng nghĩa : Ngày TK

Hợp thành : Ngày + Tháng + Năm

Mẫu tin, bảng liên quan : bảng Khách Hàng

Các xử lý liên quan : Biên tập đơn hàng

Xây dựng bảng Khách Hàng Đặc điểm dữ liệu : tổng số ký tự : 6, kiểu ký tự số

Các giá trị (miền có thể) : khuôn dạng DDMMYY

năm >= 05 ngày phải <= ngày hiện tại

+

Từ điển dữ liệu (tt)

Định nghĩa bảng

Tên bảng : Nhân viên

Mô tả : Chứa thông tin về các nhân viên trong đơn vị

Tên đồng nghĩa : Không

Hợp thành : Mã số NV

Ho tên NV Ngày bắt đầu công tác Lương

Phòng

Tổ chức : Tuần tự theo Mã số NV

Các xử lý liên quan : Cập nhật nhân viên

Tìm kiếm nhân viên

+

Từ điển dữ liệu (tt)

Định nghĩa chức năng xử lý

Tên chức năng : Kiểm tra đơn hàng

Mô tả : Kiểm tra và biên tập một đơn hàng từ khách hàng, đối

chiếu với tài khoản của khách, đưa ra đơn hàng hợp lệ

để xử lý tiếp hay đơn hàng không hợp lệ để trả lại cho khách hàng

Vào : Đơn hàng, tài khoản của khách hàng

Ra : Đơn hàng hợp hay không hợp lệ

+

68

Mô hình nghiệp vụ - Thu thập yêu cầu

vụ: hệ thống gồm có Ai/Làm những gì/Khi nào

 Actor & Use-case

 Các mối quan hệ : Actor – Actor ; Actor-case, -

Use-case-Use-cace

vai khi tương tác với hệ thống phần mềm

 Actor nằm ngoài phạm vi của hệ thống

 Chỉ quan tâm các thông điệp mà actor gửi hay nhận

 Không quan tâm cấu trúc bên trong của actor

 Chủ yếu / Thứ yếu

 Tích cực / Thụ động

69

Nhận diện các ACTOR

 Ai là người sử dụng chức năng chính của hệ thống ?

 Ai cần sự hỗ trợ từ hệ thống để thực hiện công việc thường nhật của họ ?

 Ai phải thực hiện công việc bảo dưỡng, quản trị và giữ cho

hệ thống hoạt động ?

 Hệ thống sẽ kiểm soát thiết bị phần cứng nào ?

 Hệ thống đang xây dựng cần tương tác với những hệ thống khác hay không ?

 Ai hoặc vật thể nào quan tâm đến hay chịu ảnh hưởng bởi

kết quả mà hệ thống phần mềm tạo ra ?

70

Biểu diễn ACTOR trong UML

<<actor>>

 Ví dụ: Sinh viên, giảng viên và khách đều là độc giả của hệ thống quản lý thư viện: độc giả là actor tổng quát hóa của 2 actor sinh viên và giảng viên

 Ví dụ: một hệ thống đăng ký môn học trong trường

đại học

Tên Actor

72

Khái niệm Use-case

trao đổi bên trong hệ thống và một hoặc một số thông điệp trao đổi với actor

73

Khái niệm Use-case

chèn chuỗi sự kiện của một use-case khác

lệ

xảy ra khi Use-case được thực hiện

Tên Use-case

74

Tìm kiếm Use-case

 Actor yêu cầu chức năng gì của hệ thống ?

 Actor cần phải đọc, tạo, xoá, sửa đổi hoặc lưu trữ thông tin nào đó của hệ thống không ?

 Actor cần thiết phải được cảnh báo về những sự kiện trong hệ thống, hay actor cần phải báo hiệu cho hệ thống về vấn đề nào đó không ?

 Hệ thống có thể hỗ trợ một số công việc thường nhật của actor nào

đó hay không ?

 Hệ thống cần dữ liệu input/ouput nào ? Dữ liệu đó đến từ đâu ?

 Những khó khăn nào liên quan đến hiện thực của hệ thống hiện tại (chẳng hạn hệ thống quản lý bằng giấy tờ nên được thay thế bằng hệ thống quản lý trên máy tính) ?

75

Các quan hệ của Use-case

được thiết lập để hoàn chỉnh biểu đồ Use-case

 Use-case được Actor nào kích hoạt

hoá

 Quan hệ liên kết: extent , incluse

 Quan hệ tổng quát hóa

trường đại học

76

Ví dụ một Use-case đơn giản

Phòng Đào Tạo Sinh Viên

77

Quan hệ liên kết

 Quan hệ liên kết chỉ ra một quan hệ có ý nghĩa giữa hai bên

 Trong thực tế: hành khách với lái xe, sinh viên với giáo viên, giảng viên với môn học …

 Một số tính chất liên quan

 Tên của liên kết

 Một chiều hay 2 chiều

 Bậc: số lượng thực thể tham gia vào liên kết tại mỗi bên

 UML biểu diễn liên kết như là một đoạn thẳng (hai chiều) hoặc mũi tên

78

Quan hệ liên kết giữa Actor và Use-case

 actor kích hoạt use-case và nhận kết quả về: liên kết 2 chiều

 actor kích hoạt use-case, không quan tâm kết quả về: liên

kết 1 chiều

79

Quan hệ gộp giữa 2 Use-case

buộc phải chèn Use-case đích vào

 Tại điểm mở rộng, diễn tiến của use-case nguồn tạm thời

ngừng lại để chuyển sang diễn tiến của use-case đích

 Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại

tiếp tục

Đăng nhập

<<include>>

Tìm kiếm

80

Quan hệ mở rộng giữa 2 Use-case

thể (hoặc không) chèn use-case đích vào tùy thuộc vào

điều kiện rẽ nhánh hoặc tương tác từ actor

 Tại điểm mở rộng, nếu được mở rộng thì diễn tiến của use-case nguồn tạm thời ngừng lại để chuyển sang diễn tiến của use-case đích

 Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại tiếp tục

Đăng ký đặt chỗ (nếu tìm thấy)

<<Extend>>

Tìm kiếm

81

Quan hệ tổng quát hóa

 Là mối quan hệ giữa các đối tượng cùng nhóm tạo nên một đối tượng mang những tính chất chung của các đối tượng kia

 Quan hệ tổng quát hóa giữa các Actor: nhiều actor có chung

một số vai trò -> hình thành actor tổng quát hóa mang vai trò chung đó

 Ví dụ: sinh viên, giáo viên đều có chung use-case login và đều là user của hệ thống -> tạo nên actor user là tổng quát hóa của actor sinh viên

và actor giáo viên

 Quan hệ tổng quát hóa giữa các Use-case: khi có nhiều

use-case là trường hợp cụ thể một use-use-case trừu tượng

 Vì dụ: Use-case login của sinh viên , giáo viên có thể được thực hiện

theo cơ chế khác nhau nhưng cùng mang chung ý nghĩa là đăng nhập 

là các trường hợp cụ thể của Use-case trừu trương LOGIN