SlideShare una empresa de Scribd logo
1 de 100
Descargar para leer sin conexión
1
Chương 3
Kỹ thuật yêu cầu
(Requirement Engineering)
2
Nội dung
1. Kỹ thuật yêu cầu là gì
2. Xác định yêu cầu hệ thống là gì
3. Các loại yêu cầu hệ thống
4. Quy trình RE
3
1. Kỹ thuật yêu cầu là gì
(Requirement Engineering)
• Ta dùng Requirement Engineering thay cho Requirement
Analysis
• RE là quá trình lặp bao gồm 3 hoạt động:
– Rút ra yêu cầu từ thực tế (Elicitation)
– Đặc tả yêu cầu (Specification)
– Xác thực (Validation)
• Kết quả của quá trình RE là những đặc tả về hệ thống phần
mềm
4
2. Yêu cầu (Requirement ) là gì?
Requirements described the “what” of a system,
not the “how”
Mô tả cái gì cần cho hệ thốngMô tả cái gì cần cho hệ thống
5
Yêu cầu phần mềm
• Phản ánh sự hiểu biết lẫn nhau về vấn đề giữa người phân tích
và khách hàng
• Nền tảng để xây dựng hợp đồng
• Là sự chuẩn bị cho giai đoạn tiếp theo (giai đoạn phân tích)
• Là tài liệu để kiểm tra hệ thống khi được phát hành
6
Input/ Output của xác định yêu cầu
• Input:
– Các yêu cầu từ khách hàng (Problem statement prepared by
the customers)
• Output:
– Tài liệu đặc tả yêu cầu ( Software requirements
specification – SRS)
7
Mức độ mô tả yêu cầu
• Yêu cầu người dùng:
– Chủ yếu dành cho người dùng
– Viết bằng ngôn ngữ tự nhiên và biểu đồ
– Mô tả dịch vụ và ràng buộc hoạt động
• Yêu cầu hệ thống:
– Tài liệu có cấu trúc mô tả chức năng, dịch vụ và ràng buộc
hoạt động của hệ thống
– Có thể là một phần của hợp đồng
8
Người đọc
9
3. Các loại yêu cầu hệ thống
• Các yêu cầu của hệ thống phần mềm thường được chia thành
ba loại:
– Yêu cầu chức năng
– Yêu cầu phi chức năng
– Yêu cầu miền ứng dụng
• Thực tế khó phân biệt ba loại yêu cầu này một cách rõ ràng.
10
03/11/14 10
Yêu cầu chức năng
• Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các
chức năng hoặc các dịch vụ của hệ thống một cách chi tiết.
• Đặc điểm của yêu cầu chức năng:
– Tính mập mờ, không rõ ràng của các yêu cầu:
• Vấn đề này xảy ra khi các yêu cầu không được xác định
một cách cẩn thận.
– Tính hoàn thiện và nhất quán:
• Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi
tiết và không có sự xung đột hoặc đối ngược giữa các
yêu cầu.
11
Ví dụ
• Trong hệ thống quản lý thư viện:
– Người dùng được cấp tài khoản riêng
– Người dùng có thể tìm kiếm; download; in các bài báo
– Người dùng có thể được cấp một vùng riêng để lưu dữ liệu
12
03/11/14 12
Yêu cầu phi chức năng
• Yêu cầu phi chức năng không đề cập trực tiếp tới các chức
năng cụ thể của hệ thống.
• Yêu cầu phi chức năng thường định nghĩa các thuộc tính như:
– độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ …
– các ràng buộc của hệ thống (khả năng của thiết bị vào/ra,
giao diện …)
• Một số yêu cầu phi chức năng còn có liên quan đến quy trình
xây dựng hệ thống (các chuẩn được sử dụng, các công cụ
CASE, ngôn ngữ lập trình …)
• Các yêu cầu phi chức năng có thể hạn chế những yêu cầu chức
năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ
không sử dụng được.
13
3 yêu cầu phi chức năng cơ bản
• Yêu cầu về sản phẩm:
– Hiệu năng
– Khả năng sử dụng
– Độ tin cậy … của sản phẩm
• Yêu cầu về mặt tổ chức:
– Cơ cấu tổ chức; Chính sách của tổ chức
– Thời gian bàn giao
– Tương thích với hệ thống cũ
• Yêu cầu ngoài:
– Do các tác nhân ngoài hệ thống
– Tính pháp lý
– Tính riêng tư
14
03/11/14 14
Lý do xuất hiện yêu cầu phi chức năng
• 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
15
15
Ví dụ về yêu cầu phi chức năng
• Xác định các yêu cầu phi chức năng của Hệ thống đặt vé tàu
trước
– Yêu cầu về sản phẩm: phải xây dựng website
– Yêu cầu về mặt tổ chức: mạng máy tính nối tất cả các trạm
xe lửa với nhau.
– Yêu cầu ngoài: Hệ thống phải bảo mật
16
03/11/14 16
Ví dụ về yêu cầu phi chức năng
• Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được
của Hệ thống đặt vé tàu trước
– Mục tiêu của hệ thống là dễ sử dụng đối với nhân viên
cũng như hành khách và được tổ chức để sao cho tối thiểu
hoá được lỗi.
– Các yêu cầu phi chức năng có thể thẩm định được: Những
người nhân viên sử dụng có kinh nghiệm có thể sử dụng
được tất cả các chức năng của hệ thống chỉ sau hai tiếng
tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây
ra bởi người sử dụng là không quá hai lỗi một ngày.
17
03/11/14 17
Yêu cầu miền ứng dụng
• Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của
hệ thống và phản ánh các thuộc tính và ràng buộc của miền
ứng dụng.
• Nó có thể là yêu cầu chức năng hoặc phi chức năng.
• Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể
hệ thống sẽ không làm việc được.
• Một số vấn đề liên quan đến yêu cầu miền ứng dụng:
– Khả năng có thể hiểu được: các yêu cầu được biểu diễn
dưới ngôn ngữ của lĩnh vực ứng dụng.
– Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ
nhưng họ không biết cách xây dựng những yêu cầu miền
ứng dụng một cách rõ ràng, mang tính kỹ thuật.
18
Một số ràng buộc
• Ràng buộc trước sau
• Ràng buộc cấu trúc
• Ràng buộc suy diễn
• Ràng buộc thời gian
Môn học loại cơ sở phải học
trước môn học loại chuyên
ngành
Điểm giữa kỳ <4 thì thi lại, nếu
thi lại <4 thì học lại, nếu >=4 thì
được thi cuối kỳ
Dựa vào luật
Lương kỳ 1 phải trả trước ngày
5 hàng tháng
Khi người dùng nhấn Enter thì
chỉ trong 2 giây thì hệ thống phải
hồi đáp
19
4. Quy trình RE
• Thu thập yêu cầu (Requirement Elicitation)
• Phân tích yêu cầu (Requirement Analysis)
• Tạo tài liệu đặc tả yêu cầu (Requirement Documentation)
• Đánh giá yêu cầu (Requirement Review)
20
21
Bước 1: Thu thập yêu cầu
(Requirement Elicitation)
• Mục đích
• Nội dung cần thu thập
• Những khó khăn
• Các kỹ thuật
22
Mục đích
• Tiếp cận với nghiệp vụ, chuyên môn, môi trường hoạt động
của hệ thống
• Tìm hiểu các chức năng, nhiệm vụ và cung cách hoạt động của
hệ thống
• Chỉ ra những chỗ hợp lý cần được kế thừa, những chỗ bất hợp
lý cần khắc phục
23
Nội dung cần thu thập
• Đánh giá tính khả thi về nghiệp vụ và kỹ thuật của hệ thống
• Nhận biết xem ai sẽ giúp xác định yêu cầu và hiểu biết thực
chất của tổ chức
– Operation manager, product manager
– Makerting people
– Internal/external customer
– End-users
– Consultant
– Product engineer, Software engineer
• Xác định môi trường kỹ thuật
• Nhận biết các ràng buộc nghiệp vụ (domain constraint)
24
Những khó khăn thường gặp
1. Khó khăn về phạm vi (Problems of scope): đường biên hệ
thống thường mập mờ, hay khách hàng chỉ nhắm đến các yếu
tố kỹ thuật hơn là mục tiêu tổng thể của hệ thống
2. Khó khăn về hiểu biết khách hàng: khách hàng không biết họ
cần gì, có ý kiến trái ngược nhau về hệ thống cần xây dựng, ít
hiểu biết về kỹ thuật, thời gian giao tiếp với kỹ sư hệ thống
thường rất hạn chế.
3. Khó khăn về tính ổn định: yêu cầu thường thay đổi theo thời
gian
25
Các kỹ thuật thu thập yêu cầu
• Các kỹ thuật thu thập yêu cầu:
– Phỏng vấn (Interview)
• Chọn lựa stakeholder để phỏng vấn
– Phiếu điều tra (questionnaire)
– Thu thập tài liệu : biểu mẫu, báo cáo, thống kê, số liệu,…
– Phiên họp động não ( brainstorm session): kỹ thuật thảo luận nhóm
giúp tìm ra nhanh chóng những ý tưởng mới
– Sử dụng kịch bản (scenario) để phát hiện các yêu cầu của hệ thống.
• Tạo các kịch bản (scenario) để giúp khách hàng/người dùng xác định tốt
hơn các yêu cầu chính của hệ thống
• Một tập hợp các use case sẽ mô tả tất cả các tương tác có thể trong hệ
thống.
26
Bước 2: Phân tích yêu cầu
(Requirement Analysis)
• Mục đích
• Nguyên lý phân tích
• Hướng phân tích
• Các mô hình phân tích
• Các bước phân tích yêu cầu theo hướng dòng dữ liệu
• Nội dung chính của RSC
27
Mục đích
• Phân tích yêu cầu nhằm phân loại và tổ chức các yêu cầu
thành các tập con có liên quan nhau
• Xếp loại các yêu cầu theo nhu cầu của người dùng
• Tổng hợp, điều chỉnh yêu cầu theo hướng tổng quan nhất
• Chỉ ra được hệ thống làm việc gì, làm với dữ liệu nào
28
Nguyên lý phân tích
• Nguyên lý 1: Miền dữ liệu
– Xác định đối tượng dữ liệu
– Mô tả thuộc tính dữ liệu
– Thiết lập quan hệ dữ liệu
• Nguyên lý 2: Miền chức năng
– Xác định chức năng biến đổi dữ liệu
– Chỉ ra luồng dữ liệu trong hệ thống
– Biểu diễn chức năng, luồng dữ liệu, kho dữ liệu
• Nguyên lý 3: Xác định các trạng thái
– Chỉ ra những trạng thái của hệ thống
– Chỉ ra những sự kiện gây biến đối trạng thái
• Nguyên lý 4: Phân tách mô hình
– Tinh chế đối tượng, dữ liệu
– Tạo hệ thống ở cấp bậc chức năng
– Biểu diễn hành vi ở mức chi tiết
• Nguyên lý 5: Sự thiết yếu
– Chú trọng vấn đề thiết yếu
– Loại bỏ những vấn đề chi tiết
29
Nguyên lý davis
• Hiểu vấn đề trước khi tạo mô hình phân tích
• Tạo bản mẫu (prototype) cho phép người dùng hiểu được
tương tác giữa người và máy
• Ghi nhận nguồn gốc và lý do của mỗi yêu cầu
• Dùng nhiều khung nhìn
• Phân loại mức độ ưu tiên của yêu cầu
• Loại bỏ những sự mơ hồ
30
Hướng phân tích
• Phân tích hướng cấu trúc
– Dữ liệu, quá trình biến đổi dữ liệu
– Sử dụng các biểu đồ: chức năng, DFD, ERD, RDM, chuẩn
hóa dữ liệu, từ điển dữ liệu
• Phân tích hướng đối tượng
– Tập trung vào đối tượng, sự tương tác giữa các đối tượng
– Sử dụng UML
31
Các mô hình phân tích
Analysis Model
Scenario-based
Element
Use case diagram
Activity diagram
Scenario-based
Element
Use case diagram
Activity diagram
Flow-oriented
Element
Data Flow Diagram
Control-Flow diagram
Flow-oriented
Element
Data Flow Diagram
Control-Flow diagram
Behavioral
Element
State diagram
Sequence diagram
Behavioral
Element
State diagram
Sequence diagram
Class-based
Element
Class diagram
CRC models
Class-based
Element
Class diagram
CRC models
32
Use case diagram
• Là một tập hợp của các chuỗi hành động mà một hệ thống thực
hiện để tạo ra một kết quả có thể quan sát được, tức là một giá
trị đến với một tác nhân cụ thể.
• Những hành động này có thể bao gồm việc giao tiếp với một
loạt các tác nhân cũng như thực hiện tính toán và công việc
nội bộ bên trong hệ thống.
• Use case bao gồm:
– Actor (tác nhân)
– Use case (hành động)
33
Ví dụ
34
Data Flow diagram
• Flow-oriented modeling vẫn là 1 trong những cách thông dụng nhất hiện
nay để phân tích hệ thống. Tên gọi khác lược đồ dòng dữ liệu (Data Flow
Diagram – DFD)
• DFD dùng để mô hình hóa các yêu cầu hệ thống.
• DFD biểu diễn các bước mà luồng dữ liệu phải trải qua trong hệ thống từ
điểm đầu tới điểm cuối.
• DFD mô hình hoá hệ thống từ góc độ một chức năng. Việc tìm vết và tư
liệu hoá quan hệ giữa dữ liệu với một quy trình rất có ích đối với việc tìm
hiểu toàn bộ hệ thống.
• DFD bao gồm:
– Mức ngữ cảnh
– Mức 1, mức 2 …
• Tuy DFD và không thuộc định dạng của UML nhưng chúng vẫn được
dùng để bổ sung cho các lược đồ UML và giúp xác định rõ hơn các yêu
cầu của hệ thống
35
Ví dụ
36
State diagram
• Tất cả các đối tượng đều có trạng thái;
• Tạng thái là một kết quả của các hoạt động trước đó đã được
đối tượng thực hiện và nó thường được xác định qua giá trị
của các thuộc tính cũng như các nối kết của đối tượng với các
đối tượng khác.
• Một lớp có thể có một thuộc tính đặc biệt xác định trạng thái,
hoặc trạng thái cũng có thể được xác định qua giá trị của các
thuộc tính “bình thường" trong đối tượng.
• Một đối tượng sẽ thay đổi trạng thái khi có một việc nào đó
xảy ra, thứ được gọi là sự kiện;
• Miêu tả một đối tượng có thể có những trạng thái nào trong hệ
thống
37
Ví dụ
38
Ví dụ
39
Class diagram
• Là một tập hợp các đối tượng có chung các thuộc tính, các ứng
xử và các ngữ nghĩa
• Lớp gồm có:
– Tên lớp (lass name)
– Thuộc tính (attribute)
– Phương thức (methods)
• Biểu đồ lớp mô tả các lớp và các quan hệ giữa các lớp với
nhau
40
Ví dụ
41
Mô hình hóa dữ liệu
(Data Modeling)
• Mô hình dữ liệu gồm 3 thành phần chính:
– Đối tượng dữ liệu (Data object)
– Thuộc tính (attribute): mô tả đối tượng dữ liệu
– Mối liên hệ (relationship) giữa các đối tượng dữ liệu
42
Mô hình hóa dữ liệu
(Data Modeling)
• Lược đồ Entity-Relationship (ERD)
• Lược đồ Relational Data Model (RDM)
• Chuẩn hóa dữ liệu
• Từ điển dữ liệu
43
Các bước phân tích yêu cầu theo hướng
dòng dữ liệu (Flow oriented)
Draw the
context diagram
Draw the
context diagram
Develop
Prototypes
(optional)
Develop
Prototypes
(optional)
Model the
requirements
Model the
requirements
Finalise the
requirements
Finalise the
requirements
44
Phát triển prototype
(Development of protoype)
• Xây dựng prototype tương tự như hệ thống cần xây dựng,
khách hàng sẽ xem xét cho cho ý kiến phản hồi, prototype sẽ
liên tục được điều chỉnh để thỏa mãn yêu cầu khách hàng.
• Prototype là cách giúp tìm hiểu hiệu quả mong muốn thực sự
của khách hàng.
• Prototype thường được xây dựng nhanh, chi phí thấp, nên sẽ
có nhiều hạn chế và thiếu xót so với hệ thống cuối 
Prototype chỉ là 1 tùy chọn (optional)
45
Nội dung chính của SRS
1. Functionality: phần mềm được dùng để làm gì?
2. External interfaces: phần mềm giao diện với người dùng như
thế nào? Với phần cứng và các phần mềm khác ra sao?
3. Performance: tốc độ, thời gian đáp ứng, thờigian hồi phục,…
của mỗi chức năng phần mềm thế nào?
4. Attributes: khả năng bảo trì, độ chính xác, độ tin cậy, khả
năng bảo mật, …
5. Design constraints: Phần mềm bị ràng buộc bởi các tiêu
chuẩn nào? Ngôn ngữ thực thi, chính sách bảo toàn cSDL,
hạn chế về tài nguyên, hệ điều hành sử dụng,…
46
Yêu cầu của SRS
1. Nên xác định đúng tất cả yêu cầu phần mềm.
2. Không nên mô tả bất kỳ chi tiết nào liên quan đến thiết kế
hay thực thi
3. Không nên đưa các ràng buộc dư thừa vào SRS. Một số ràng
buộc về chất lượng nên đưa vào kế hoạch bảo đảm chất lượng
phần mềm
47
Đặc tính của SRS
• Correct
• Unambiguous
• Complete
• Consistent
• Stability
• Verifiable
• Modifiable
• Traceable
• (chính xác)
• (rõ ràng)
• (hoàn thành)
• (nhất quán)
• (ổn định)
• (có thể thẩm tra)
• (có thể sửa đổi)
• (có thể miêu tả)
48
Nghiên cứu tính thực thi
Feasibility study
• Feasibility study là 1 bước quan trọng trong bất kỳ
quy trình phát triển phần mềm nào. Nghiên cứu này
nhằm phân tích chi phí (cost), thời gian (time) cần
thực hiện trong mỗi giai đoạn.
• Feasibility study là một trong các kết quả của phân
tích yêu cầu phần mềm.
49
Thuận lợi của feasibility study
• Được xem như bước khởi đầu của chu kỳ phát triển
phần mềm (SDLC) dùng để phân tích toàn diện các yêu
cầu của hệ thống.
• Giúp nhận biết các thừa số rủi ro (risk factor) ảnh
hưởng đến việc phát triển và triển khai hệ thống.
• Là cơ sở để phân tích chi phí/lợi nhuận của hệ thống
• Giúp lập kế hoạch đào tạo đội ngũ phát triển hệ thống.
• Là báo cáo giúp ban lãnh đạo dựa vào đó ra quyết định
50
Bước 3: Đặc tả yêu cầu
(Requirement Documentation)
• Tạo tư liệu về yêu cầu (requirement documentation) là một
hoạt động rất quan trọng sau khi thu thập và phân tích yêu cầu
hệ thống. Đây là cách để biểu diễn yêu cầu theo một định dạng
thống nhất.
• Các tài liệu về yêu cầu được gọi là đặc tả yêu cầu phần mềm
(Software requirement Specification – SRS)
• Các đặc tả có thể là tài liệu, mô hình đồ họa, mô hình toán
học, tập hợp các ngữ cảnh hay dùng.
• Có một số mẫu tiêu chuẩn “standard template”, tuy nhiên tùy
theo hệ thống các đặc tả này có thể thay đổi linh động theo.
51
Các phương pháp đặc tả
• Đặc tả yêu cầu bằng ngôn ngữ tự nhiên
– Không rõ ràng
– Quá mềm dẽo
– Thiếu cấu trúc
• Đặc tả yêu cầu bằng ngôn ngữ cấu trúc
– Tuân thủ các chuẩn về từ ngữ, về cấu trúc
– Duy trì ngôn ngữ tự nhiên
• Đặc tả bằng biểu mẫu
• Đặc tả dạng bảng
• Đặc tả theo ngôn ngữ PDL (Program Design Language)
• Đặc tả theo mô hình
• Đặc tả theo IEEE
52
Bước 4: Đánh giá yêu cầu
(Requirement Review)
• Xác định những yêu cầu có phù hợp với những gì khách hàng
mong muốn hay không
• Chi phí cho lỗi về yêu cầu rất cao (chi phí cho sửa lỗi sau khi
xuất xưởng gấp 100 lần so với khi cài đặt)
• Các thuộc tính cần kiểm tra
– Giá trị (validity)
– Toàn vẹn (Consistency)
– Đầy đủ (Completeness)
– Hiện thực (Realism)
– Kiểm tra được (Verifiability)
53
Kỹ thuật đánh giá yêu cầu
• Kiểm tra yêu cầu
– Phân tích thủ công
– Kiểm tra có tính hệ thống
• Tạo mẫu
– Sử dụng các mô hình có thể thực thi
• Tạo tình huống kiểm tra
– Tình huống bình thường
– Tình huống đặc biệt
54
Nội dung
• Ước tính quy mô dự án (Size estimation)
– Số dòng lệnh (lines of code)
– Function Point
• Ước tính chi phí
– Mô hình COCOMO
55
Ước tính quy mô dự án
• Là bước quan trọng khi bắt đầu dự án
• Rất khó để ước tính phạm vi của 1 hệ thống phần mềm vì:
– Phần mềm là sản phẩm trừu tượng
– Xây nhà, cầu đường là sản phẩm cụ thể, có thể nhìn thấy và
sờ mó được
• Hai phương pháp thông dụng:
– Tính số dòng lệnh (Lines Of Code – LOC)
– Tính Function Point (FP)
56
Lines Of Code (LOC)
• Chưa có sự thống nhất trong quy ước đếm LOC
• Trước đây: không tính đến các dòng khai báo dữ liệu, chú
thích, ..
• Gần đây: tính cả dòng khai báo, chú thích
• Lý do: chương trình mới chứa hơn 50% dòng dữ liệu, và các
dòng này cũng thường xuyên gây lỗi như các dòng lệnh thông
thường
57
Ví dụ
10 If (x[i] < x[j])
11 {
12 Save = x[i];
13 X[i] = x[j];
14 X[j] = Save;
15 }
16 }
17 Return 0;
18 }
1 int sort(int x[], int n)
2 {
3 int i,j, save, im1;
4 /* this function sorts array x
5 if (n<2) return 1;
6 for (i=2;i<=n;i++)
7 {
8 im1= i-1;
9 for(j=1;j<=im;j++)
58
Lines Of Code (LOC)
• LOC của chương trình? 17, 18 hay 13
• Theo định nghĩa của Conte: Dòng mã là bất kỳ dòng nào (tiêu
đề, khai báo, lệnh khả thi và không khả thi) trong chương
trình, không kể dòng chú thích (comment), bất kể có bao nhiêu
dòng mã hay khối mã trên cùng 1 dòng”
• LOC của chương trình là 17
59
Lines Of Code (LOC)
• Ưu điểm: đơn giản, cụ thể
• Nhược điểm:
– Phụ thuộc vào ngôn ngữ, không chỉ ra được tổng thể dự án
– Đếm dòng lệnh tương tự như đếm số gạch để xây nhà cao
tầng, chỉ cho biết số gạch cần dùng nhưng không chỉ ra
được số phòng, tổng diện tích xây dựng, tổng diện tích đất,
…
• Ứng dụng: dùng LOC để ước tính thời gian lập trình
60
Tính Function Point (FP)
• Dùng để đánh giá chức năng của phần mềm theo quan điểm
người dùng (người dùng yêu cầu gì và hệ thống đáp ứng ra
sao)
• Đo lường quy mô dự án theo FP không phụ thuộc vào việc sử
dụng công nghệ
• Ví dụ:
– Hai phần mềm kế toán, một được viết bằng assembler, một
được viết bằng C#, nhưng thực thi những chức năng như
nhau.
– Người dùng chỉ quan tâm đến việc mua phần mềm kế toán,
mà không cần quan tâm đến nó chứa bao nhiêu dòng lệnh,
viết bằng ngôn ngữ nào.
61
62
Tính Function Point (FP)
• Theo FPA (FP analysis) của Albrecht, một hệ thống được chia
thành 5 đơn vị chức năng (functional unit) như sau:
– Inputs
– Outputs
– Enquiries
– Internal logical files
– External interface files
63
Tính Function Point (FP)
• Các đơn vị chức năng được phân loại dựa vào độ phức tạp:
Low, Average, High.
Functional Units
Weighting factors
Low Average High
External Inputs (EI) 3 4 5
External Outputs (EO) 4 5 7
External Inquiries (EQ) 3 4 6
Internal logical files (ILF) 7 10 15
External interface files (EIF) 5 7 10
Bảng 1
64
Tính Function Point (FP)
• Trình tự tính FP của hệ thống:
– Phân loại theo năm loại chức năng
– Tính UFP (Unadjusted Function Points)
– Tính FP
65
Tính UFP (Unadjusted Function Points)
∑∑= =
=
5
1
3
1i j
ijij wZUFP
i là chỉ số hàng, j là chỉ số cột của bảng 1
wij là giá trị của hàng i cột j bảng 1
Zij là kết quả đếm của loại chức năng i với độ phức
tạp tương ứng với cột j
66
Tính FP
FP = UFP * CAF
• CAF (complexity adjustment factor) và được tính
như sau:
∑+= ]01.065.0[ iFCAF
Fi (i=1 to 14) là mức độ ảnh hưởng dựa vào 14 câu hỏi
trong bảng 2.
Mỗi thừa số sẽ có tỷ lệ từ 0 đến 5
67
Bảng 2: Các thừa số Fi
1. Does the system require reliable backup and recovery?
2. Is data communication required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing heavily utilized oprational
environment?
6. Does the system require on line data entry?
7. Does the on line data entry require the input transaction to be
built over multiple screens or operations?
8. Are the master files updated on line?
9. Is the inputs, outputs, files or inquiries complex?
68
Bảng 2: Các thừa số Fi
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease of
use by the user?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease of
use by the user?
0 1 2 3 4 5
No
Influence
Incredental Moderate Average Significant Essential
69
Mục đích của việc tính FP
• Dành cho nhà quản lý để giám sát mức hiệu quả của dự án.
• FP phản ánh được quy mô của dự án.
• Dựa vào FP để tính chi phí phát triển dự án:
– Productivity = FP/person-months
– Quality = Defects/FP
– Cost = USD/FP
– Documentation = Pages of documentation per FP
70
Ví dụ 1
• Khảo sát dự án với các đơn vị chức năng như sau:
– Number of user inputs = 50
– Number of user outputs = 40
– Number of user enquiries = 35
– Number of user files = 06
– Number of external interfaces = 04
Giả sử tất cả các thừa số điều chỉnh độ phức tạp và thừa số trọng
số đều trung bình
Tính FP cho dự án
71
Ví dụ 1
∑∑= =
=
5
1
3
1i j
ijij wZUFP
UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7 = 628
CAF = (0.65 + 0.01 ΣFi) = 0.65 + 0.01(14x3) = 1.07
FP = UFP x CAF = 628 x 1.07 = 672
72
Ước tính chi phí bằng mô hình COCOMO
• Mô hình COCOMO (Constructive Cost Model) bao gồm:
– Mô hình cơ bản (Basic model)
– Mô hình trung cấp (Intermediate model)
– Mô hình con chi tiết (Detailed sub model)
73
Mô hình COCOMO cơ bản
• Dùng ước tính nhanh và sơ bộ chi phí dự án cho hầu
hết các dự án nhỏ và vừa.
• Có ba dạng phát triển phần mềm:
– Organic: dành cho 1 đội nhỏ các nhà phát triển có
kinh nghiệm và mội trường quen thuộc
– Semi-detached: trung gian giữa organic và
embedded
– Embedded: dành cho dự án có nhiều ràng buộc chặt
chẽ, thường là dự án mới và duy nhất, khó tìm
người thực hiện
74
Bảng so sánh ba dạng COCOMO
Mode Quy
mô dự
án
Bản chất dự án Sự sáng
tạo
Thời
hạn
Môi trường
phát triển
Organic 2-50
KLOC
Dự án nhỏ, developer kinh
nghiệm trong môi trường
thân thiện
Ít Không
chặt
Quen
thuộc, nội
bộ
Semi
-detached
50 –
300
KLOC
Dự án TB, đội TB, kinh
nghiệm đã làm cho dự án
tương tự TB
TB TB TB
Embbeded >300
KLOC
Dự án lớn, HT real time.
Giao diện phức tạp, đội có
kinh nghiệm trước đó rất ít
Đáng
kể
Chặt Yêu cầu
HW và
giao diện
phức
75
Mô hình COCOMO cơ bản
• Công thức tính COCOMO cơ bản (basic)
b
b
d
b
b
b
EcD
KLOCaE
)(
)(
=
=
E là Effort được tính bằng Person-Months
D là thời gian phát triển ( development time), tính bằng tháng
ab, bb, db là các hệ số được tra theo bảng 3
• Số lượng nhân viên và mức độ hiệu quả của dự án được tính như sau:
Average staff size (SS) = E/D Persons
Productivity (P) = KLOC/E KLOC/PM
76
Bảng 3: Các hệ số COCOMO cơ bản
Project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi -detached 3.0 1.12 2.5 0.35
Embbeded 3.6 1.20 2.5 0.32
Bảng 3
77
• Giả sử dự án được ước tính khoảng 400 KLOC. Hãy tính
nhân lực và thời gian cho mỗi loại dự án khác nhau
1. Đối với loại Organic:
E = 2.4(400)1.05
= 1295.31 PM
D = 2.5(1295.31)0.38
= 38.07 M
2. Đối với loại Semidetached:
E = 3.0(400)1.12
= 2462.79 PM
D = 2.5(2462.79)0.35
= 38.45 M
3. Đối với loại Embbeded:
E = 3.6(400)1.20
= 4772.81 PM
D = 2.5(1295)0.32
= 38 M
Ví dụ 1
Nhận xét?
78
Nhận xét
• Chọn loại dự án rất quan trọng, tùy thuộc vào 2 yếu tố:
– Quy mô dự án
– Các hệ số trong bảng 3
79
Ví dụ 2
• Quy mô dự án được ước tính khoảng 200 KLOC. Đội phát
triển phần mềm có kinh nghiệm ở mức trung bình cho các loại
dự án tương tự. Lịch biều của dự án không đòi hỏi chặt chẽ
lắm. Hãy tính thời gian phát triển, số người bình quân của đội,
và tính hiệu suất của dự án
Solution: Dự án thuộc loại semi-detached
– Tính các hệ số: E = 3.0(200)1.12
= 1133.12 PM
D = 2.5(1133.12)0.35
= 38.67 M
– Số nhân viên (staff size) = E/D = 38.67 người
– Hiệu suất dự án (productivity) = KLOC/E = 176 LOC/PM
80
Mô hình COCOMO intermediate
(mức trung cấp)
• Mô hình COCOMO cơ bản tuy ước tính nhanh nhưng sơ bộ
nên thiếu chính xác.
• Mô hình COCOMO mức trung bổ sung thêm 15 thừa số chi
phí (cost driver)
• Các thừa số chi phí này được phân thành 4 nhóm chính (bảng
4)
81
Cost Driver
RATINGS
Very low Low Norminal High Very High Extra High
Product Attributes
RELY 0.75 0.88 1.00 1.15 1.40 -
DATA - 0.94 1.00 1.08 1.16 -
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
Computer Attributes
TIME - 1.00 1.11 1.30 1.66
STOR - - 1.00 1.06 1.21 1.56
VIRT - 0.87 1.00 1.15 1.30 -
TURN - 0.87 1.00 1.07 1.15 -
Personnel Attributes
ACAP 1.46 1.19 1.00 0.86 0.71 -
AEXP 1.29 1.13 1.00 0.91 0.82 -
PCAP 1.42 1.17 1.00 0.86 0.70 -
VEXP 1.21 1.10 1.00 0.90 - -
LEXP 1.14 1.07 1.00 0.95 - -
Project Atributes
MODP 1.24 1.10 1.00 0.91 0.82 -
TOOL 1.24 1.10 1.00 0.91 0.83 -
SCED 1.23 1.08 1.00 1.04 1.10 -
BẢNG 4
82
Product Attributes
RELY Required sotware Reliability
DATA Database size
CPLX Product complexity
Computer Attributes
TIME Execution Time constraints
STOR Main Storage constraints
VIRT Virtual Machine volatility
TURN Computer turnaround time
Personnel Attributes
ACAP Analyst capability
AEXP Application experience
PCAP Programmer capability
VEXP Virtual Machine experience
LEXP Programming Language experience
Project Atributes
MODP Modern Programming practices
TOOL Use of software tools
SCED Required development schedule
83
Mô hình COCOMO intermediate
(mức trung cấp)
• Thừa số EAF (Effort adjustment factor) là tích của 15 thừa số
chi phí.
• EAF thường dao động từ 0.9 đến 1.4
84
Bảng 5: Các hệ số của
COCOMO mức trung
Project ai bi ci di
Organic 3.2 1.05 2.5 0.38
Semi -detached 3.0 1.12 2.5 0.35
Embbeded 2.8 1.20 2.5 0.32
85
Mô hình COCOMO mức trung
• Công thức tính COCOMO mức trung (intermediate)
i
i
d
i
b
i
EcD
KLOCaE
)(
)(
=
=
E là Effort được tính bằng Person-Months
D là thời gian phát triển ( development time), tính bằng tháng
ai, bi, di là các hệ số được tra theo bảng 5
• E tinh chỉnh = E x EAF
• Số lượng nhân viên và mức độ hiệu quả của dự án được tính như
sau:
Average staff size (SS) = E/D Persons
Productivity (P) = KLOC/E KLOC/PM
86
Ví dụ
• Một dự án mới được ước tính là hệ thống nhúng (embedded
system) có 400 KLOC. Người quản lý dự án phải chọn lựa
giữa 2 nhóm làm việc: một nhóm rất có năng lực nhưng hầu
như không có kinh nghiệm gì về ngôn ngữ lập trình sẽ được
dùng trong dự án; nhóm khác thì không giỏi lắm nhưng có
nhiều kinh nghiệm về ngôn ngữ lập trình. Hãy xét xem việc
chọn lựa các nhóm sẽ ảnh hưởng như thế nào đến dự án??
87
Ví dụ
Solution:
Vì là dự án kiểu embedded và mô hình COCOMO mức trung
nên:
E= ai(KLOC)bi
= 2.8(400)1.20
= 3712 PM
Trường hợp 1: chọn nhóm có năng lực nhưng không có kinh
nghiệm
EAF = 0.82 x 1.14 = 0.9348
 E1 = EAF x E = 0.9348 x 3712 = 3470 PM
 D1 = ci (E)di
= 2.5(3470)0.32
= 33.9 PM
88
Ví dụ
• Trường hợp 2: nhóm ít có năng lực nhưng nhiều kinh nghiệm
– EAF = 1.29 x 0.95 = 1.22
– E2 = EAF x E = 1.22 x 3712 = 4528 PM
– D2 = ci (E)di
= 2.5(4528)0.32
= 36.9PM
Nhận xét:
Nhóm 2 cần nhiều người và thời gian hơn. Vì vậy, nhóm năng
lực yếu tuy có nhiều kinh nghiệm lập trình không thể phù hợp
với dự án loại embedded.
89
Mối quan hệ giữa LOC và FP
• Phụ thuộc vào ngôn ngữ lập trình được dùng để thực thi và
chất lượng thiết kế.
• LOC và FP được dùng để ước tính khá chính xác chi phí (cost)
và nhân lực (effect)
• Bảng LOC/FP
90
Các ví dụ
• Ước tính theo LOC (page 128 Roger 5e)
• Ước tính theo FP (page 129 Roger 5e)
91
Ví dụ ước tính theo LOC
• A software package to be developed for a computer-aided
design application for mechanical components. A review of
the System Specification indicates that the software is to
execute on an engineering workstation and must interface with
various computer graphics peripherals including a mouse,
digitizer, high resolution color display and laser printer.
• Using the System Specification as a guide, a preliminary
statement of software scope can be developed:
92
Ví dụ ước tính theo LOC
• The CAD software will accept two- and three-dimensional
geometric data from an engineer. The engineer will interact
and control the CAD system through a user interface that will
exhibit characteristics of good human/ machine interface
design. All geometric data and other supporting information
will be maintained in a CAD database. Design analysis
modules will be developed to produce the required output,
which will be displayed on a variety of graphics devices. The
software will be designed to control and interact with
peripheral devices that include a mouse, digitizer, laser printer,
and plotter.
93
Ví dụ ước tính theo LOC
• Dựa vào phát biểu sơ bộ về phạm vi phần mềm (preliminary
statement of software scope), xác định được các chức năng
chính của phần mềm:
• User interface and control facilities (UICF)
• Two-dimensional geometric analysis (2DGA)
• Three-dimensional geometric analysis (3DGA)
• Database management (DBM)
• Computer graphics display facilities (CGDF)
• Peripheral control function (PCF)
• Design analysis modules (DAM)
94
Ví dụ ước tính theo LOC
95
Ví dụ ước tính theo LOC
• A review of historical data indicates that the organizational
average productivity for systems of this type is 620 LOC/pm.
Based on a burdened labor rate of $8000 per month, the cost
per line of code is approximately $13. Based on the LOC
estimate and the historical productivity data, the total
estimated project cost is $431,000 and the estimated effort is
54 person-months.
96
Ví dụ Ước tính theo FP
• The project planner estimates inputs, outputs, inquiries, files,
and external interfaces for the CAD software. For the purposes
of this estimate, the complexity weighting factor is assumed to
be average.
• The expected value for the estimation variable (size), S, can be
computed as a weighted average of the optimistic (sopt), most
likely (sm), and pessimistic (spess) estimates.
S = (sopt + 4sm + spess)/6
97
Ví dụ Ước tính theo FP
98
Tính CAF=0.65+0.01x ΣFi
99
Ví dụ Ước tính theo FP
• The estimated number of FP is derived:
FPestimated = count-total x [0.65 + 0.01 xΣ(Fi)] =375
• The organizational average productivity for systems of this type
is 6.5 FP/pm. Based on a burdened labor rate of $8000 per
month, the cost per FP is approximately $1230.
• Based on the LOC estimate and the historical productivity data,
the total estimated project cost is $461,000 and the estimated
effort is 58 person-months.
100
Bài đọc thêm
• Blog của Glorevenhite
http://glorevenhite.wordpress.com/2008/04/01/function-point-analys
• Website QMS
http://www.qsm.com/?q=resources/function-point-languages-
table/index.html

Más contenido relacionado

La actualidad más candente

De thi qlda cntt itc vdc trac nghiem 05-2006
De thi qlda cntt itc vdc trac nghiem 05-2006De thi qlda cntt itc vdc trac nghiem 05-2006
De thi qlda cntt itc vdc trac nghiem 05-2006Tran Tien
 
Công nghệ yêu cầu requirements engineering (re)
Công nghệ yêu cầu requirements engineering (re)Công nghệ yêu cầu requirements engineering (re)
Công nghệ yêu cầu requirements engineering (re)nataliej4
 
Xây dựng hệ thống quản lý sân bóng sử dụng Yii Framework
Xây dựng hệ thống quản lý sân bóng sử dụng Yii FrameworkXây dựng hệ thống quản lý sân bóng sử dụng Yii Framework
Xây dựng hệ thống quản lý sân bóng sử dụng Yii FrameworkGMO-Z.com Vietnam Lab Center
 
Mô hình hóa yêu cầu
Mô hình hóa yêu cầuMô hình hóa yêu cầu
Mô hình hóa yêu cầuNguyen Tran
 
Chuong 4 - CSDL phân tán
Chuong 4 - CSDL phân tánChuong 4 - CSDL phân tán
Chuong 4 - CSDL phân tánduysu
 
Tong hop cau hoi trac nghiem hdh
Tong hop cau hoi trac nghiem hdhTong hop cau hoi trac nghiem hdh
Tong hop cau hoi trac nghiem hdhHoat Thai Van
 
BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin
BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin
BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin nataliej4
 
Slide Báo Cáo Đồ Án Tốt Nghiệp CNTT
Slide Báo Cáo Đồ Án Tốt Nghiệp CNTTSlide Báo Cáo Đồ Án Tốt Nghiệp CNTT
Slide Báo Cáo Đồ Án Tốt Nghiệp CNTTHiệu Nguyễn
 
Nhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềmNhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềmTrần Gia Bảo
 
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UMLPHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UMLDang Tuan
 
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng HồBáo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng HồzDollz Lovez
 
Chuẩn hóa lược đồ quan hệ
Chuẩn hóa lược đồ quan hệChuẩn hóa lược đồ quan hệ
Chuẩn hóa lược đồ quan hệHưởng Nguyễn
 
Giới thiệu về Rational Rose và Các diagram
Giới thiệu về Rational Rose và Các diagramGiới thiệu về Rational Rose và Các diagram
Giới thiệu về Rational Rose và Các diagramHuy Vũ
 
Quản lý học sinh cấp 2
Quản lý học sinh cấp 2Quản lý học sinh cấp 2
Quản lý học sinh cấp 2laonap166
 
Do an xay_dung_website_thuong_mai_dien_tu
Do an xay_dung_website_thuong_mai_dien_tuDo an xay_dung_website_thuong_mai_dien_tu
Do an xay_dung_website_thuong_mai_dien_tuThiênĐàng CôngDân
 
Hệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng onlineHệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng onlineHan Nguyen
 
đồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thị
đồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thịđồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thị
đồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thịThanh Hoa
 
Các giao thức sử dụng trong các lớp của mô hình osi
Các giao thức sử dụng trong các lớp của mô hình osiCác giao thức sử dụng trong các lớp của mô hình osi
Các giao thức sử dụng trong các lớp của mô hình osiUDCNTT
 

La actualidad más candente (20)

De thi qlda cntt itc vdc trac nghiem 05-2006
De thi qlda cntt itc vdc trac nghiem 05-2006De thi qlda cntt itc vdc trac nghiem 05-2006
De thi qlda cntt itc vdc trac nghiem 05-2006
 
Công nghệ yêu cầu requirements engineering (re)
Công nghệ yêu cầu requirements engineering (re)Công nghệ yêu cầu requirements engineering (re)
Công nghệ yêu cầu requirements engineering (re)
 
Xây dựng hệ thống quản lý sân bóng sử dụng Yii Framework
Xây dựng hệ thống quản lý sân bóng sử dụng Yii FrameworkXây dựng hệ thống quản lý sân bóng sử dụng Yii Framework
Xây dựng hệ thống quản lý sân bóng sử dụng Yii Framework
 
Mô hình hóa yêu cầu
Mô hình hóa yêu cầuMô hình hóa yêu cầu
Mô hình hóa yêu cầu
 
Chuong 4 - CSDL phân tán
Chuong 4 - CSDL phân tánChuong 4 - CSDL phân tán
Chuong 4 - CSDL phân tán
 
Tong hop cau hoi trac nghiem hdh
Tong hop cau hoi trac nghiem hdhTong hop cau hoi trac nghiem hdh
Tong hop cau hoi trac nghiem hdh
 
Phân Tích Thiết Kế Hệ Thống Thông Tin - Quản Lý Điểm
Phân Tích Thiết Kế Hệ Thống Thông Tin -  Quản Lý ĐiểmPhân Tích Thiết Kế Hệ Thống Thông Tin -  Quản Lý Điểm
Phân Tích Thiết Kế Hệ Thống Thông Tin - Quản Lý Điểm
 
BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin
BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin
BÀI TẬP PHÂN TÍCH THIẾT KẾ HỆ THỐNG -Bộ môn Hệ thống thông tin
 
Slide Báo Cáo Đồ Án Tốt Nghiệp CNTT
Slide Báo Cáo Đồ Án Tốt Nghiệp CNTTSlide Báo Cáo Đồ Án Tốt Nghiệp CNTT
Slide Báo Cáo Đồ Án Tốt Nghiệp CNTT
 
Nhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềmNhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềm
 
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UMLPHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
 
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng HồBáo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
 
Chuẩn hóa lược đồ quan hệ
Chuẩn hóa lược đồ quan hệChuẩn hóa lược đồ quan hệ
Chuẩn hóa lược đồ quan hệ
 
Giới thiệu về Rational Rose và Các diagram
Giới thiệu về Rational Rose và Các diagramGiới thiệu về Rational Rose và Các diagram
Giới thiệu về Rational Rose và Các diagram
 
Quản lý học sinh cấp 2
Quản lý học sinh cấp 2Quản lý học sinh cấp 2
Quản lý học sinh cấp 2
 
Do an xay_dung_website_thuong_mai_dien_tu
Do an xay_dung_website_thuong_mai_dien_tuDo an xay_dung_website_thuong_mai_dien_tu
Do an xay_dung_website_thuong_mai_dien_tu
 
Hệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng onlineHệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng online
 
Chuong 2. cnpm
Chuong 2. cnpmChuong 2. cnpm
Chuong 2. cnpm
 
đồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thị
đồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thịđồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thị
đồ áN phân tích thiết kế hệ thống quản lý bán hàng siêu thị
 
Các giao thức sử dụng trong các lớp của mô hình osi
Các giao thức sử dụng trong các lớp của mô hình osiCác giao thức sử dụng trong các lớp của mô hình osi
Các giao thức sử dụng trong các lớp của mô hình osi
 

Destacado

Quản lý quy trình phần mềm KHTN
Quản lý quy trình phần mềm KHTNQuản lý quy trình phần mềm KHTN
Quản lý quy trình phần mềm KHTNNguyen Van Toan
 
Girl Geeks Dinner Imposter Syndrome
Girl Geeks Dinner Imposter SyndromeGirl Geeks Dinner Imposter Syndrome
Girl Geeks Dinner Imposter SyndromeAlexis Wong Baird
 
ScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh Cường
ScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh CườngScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh Cường
ScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh CườngVu Hung Nguyen
 
Giáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinGiáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinVõ Phúc
 
Giáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinGiáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinVõ Phúc
 
18 cách kiếm tiền online uy tín nhất
18 cách kiếm tiền online uy tín nhất18 cách kiếm tiền online uy tín nhất
18 cách kiếm tiền online uy tín nhấtkiemtienonline2030
 

Destacado (6)

Quản lý quy trình phần mềm KHTN
Quản lý quy trình phần mềm KHTNQuản lý quy trình phần mềm KHTN
Quản lý quy trình phần mềm KHTN
 
Girl Geeks Dinner Imposter Syndrome
Girl Geeks Dinner Imposter SyndromeGirl Geeks Dinner Imposter Syndrome
Girl Geeks Dinner Imposter Syndrome
 
ScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh Cường
ScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh CườngScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh Cường
ScrumDay Vietnam 2013: PMBOK là Waterfall hay Agile? - Phùng Thanh Cường
 
Giáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinGiáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tin
 
Giáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinGiáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tin
 
18 cách kiếm tiền online uy tín nhất
18 cách kiếm tiền online uy tín nhất18 cách kiếm tiền online uy tín nhất
18 cách kiếm tiền online uy tín nhất
 

Similar a Chuong 3 xac_dinh_yeu_cau_he_thong, hệ thống

KyngheYC_Requirements 18.pptx
KyngheYC_Requirements 18.pptxKyngheYC_Requirements 18.pptx
KyngheYC_Requirements 18.pptxssuser73ecd9
 
Chuong 6 Phát triển hệ thống thông tin kế toan
Chuong 6 Phát triển hệ thống thông tin kế toanChuong 6 Phát triển hệ thống thông tin kế toan
Chuong 6 Phát triển hệ thống thông tin kế toandlmonline24h
 
C01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdfC01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdfSnMinhThun
 
tnyc-c1-yeucauphanmem-sv.pdf
tnyc-c1-yeucauphanmem-sv.pdftnyc-c1-yeucauphanmem-sv.pdf
tnyc-c1-yeucauphanmem-sv.pdfitexcel
 
Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao
Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao
Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao nataliej4
 
HDH_chuong 1_2019_color.pdf
HDH_chuong 1_2019_color.pdfHDH_chuong 1_2019_color.pdf
HDH_chuong 1_2019_color.pdfHongVitc
 
Chuong 1 - Gioi Thieu.pptx
Chuong 1 - Gioi Thieu.pptxChuong 1 - Gioi Thieu.pptx
Chuong 1 - Gioi Thieu.pptxCngNguynPhmHuy
 
Mo hinh He thong va Mo phong.ppt
Mo hinh He thong va Mo phong.pptMo hinh He thong va Mo phong.ppt
Mo hinh He thong va Mo phong.pptHaTrungKien2
 
3-Requirements_VI.pdf
3-Requirements_VI.pdf3-Requirements_VI.pdf
3-Requirements_VI.pdfEllieHuynh3
 
Chuong trinh hoc phan phan tich thiet ke httt
Chuong trinh hoc phan phan tich thiet ke htttChuong trinh hoc phan phan tich thiet ke httt
Chuong trinh hoc phan phan tich thiet ke htttlvtoi1403
 
Chương 1. GiỚI THIỆU VỀ MÔ PHỎNG
Chương 1. GiỚI THIỆU VỀ MÔ PHỎNGChương 1. GiỚI THIỆU VỀ MÔ PHỎNG
Chương 1. GiỚI THIỆU VỀ MÔ PHỎNGLe Nguyen Truong Giang
 

Similar a Chuong 3 xac_dinh_yeu_cau_he_thong, hệ thống (20)

Chuong 3. cnpm
Chuong 3. cnpmChuong 3. cnpm
Chuong 3. cnpm
 
KyngheYC_Requirements 18.pptx
KyngheYC_Requirements 18.pptxKyngheYC_Requirements 18.pptx
KyngheYC_Requirements 18.pptx
 
Chuong 6 Phát triển hệ thống thông tin kế toan
Chuong 6 Phát triển hệ thống thông tin kế toanChuong 6 Phát triển hệ thống thông tin kế toan
Chuong 6 Phát triển hệ thống thông tin kế toan
 
C01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdfC01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdf
 
tnyc-c1-yeucauphanmem-sv.pdf
tnyc-c1-yeucauphanmem-sv.pdftnyc-c1-yeucauphanmem-sv.pdf
tnyc-c1-yeucauphanmem-sv.pdf
 
2 thu thap va mo hinh yeu cau
2 thu thap va mo hinh yeu cau2 thu thap va mo hinh yeu cau
2 thu thap va mo hinh yeu cau
 
Lecture03
Lecture03Lecture03
Lecture03
 
Lecture03(1)
Lecture03(1)Lecture03(1)
Lecture03(1)
 
Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao
Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao
Bài Giảng Môn Học Cơ Sở Dữ Liệu Nâng Cao
 
Tuan1_pttkhtt.pptx
Tuan1_pttkhtt.pptxTuan1_pttkhtt.pptx
Tuan1_pttkhtt.pptx
 
HDH_chuong 1_2019_color.pdf
HDH_chuong 1_2019_color.pdfHDH_chuong 1_2019_color.pdf
HDH_chuong 1_2019_color.pdf
 
Ct343
Ct343Ct343
Ct343
 
Chuong 1 - Gioi Thieu.pptx
Chuong 1 - Gioi Thieu.pptxChuong 1 - Gioi Thieu.pptx
Chuong 1 - Gioi Thieu.pptx
 
Mo hinh He thong va Mo phong.ppt
Mo hinh He thong va Mo phong.pptMo hinh He thong va Mo phong.ppt
Mo hinh He thong va Mo phong.ppt
 
3-Requirements_VI.pdf
3-Requirements_VI.pdf3-Requirements_VI.pdf
3-Requirements_VI.pdf
 
Chuong trinh hoc phan phan tich thiet ke httt
Chuong trinh hoc phan phan tich thiet ke htttChuong trinh hoc phan phan tich thiet ke httt
Chuong trinh hoc phan phan tich thiet ke httt
 
Đồ-Án-1.docx
Đồ-Án-1.docxĐồ-Án-1.docx
Đồ-Án-1.docx
 
Chương 1. GiỚI THIỆU VỀ MÔ PHỎNG
Chương 1. GiỚI THIỆU VỀ MÔ PHỎNGChương 1. GiỚI THIỆU VỀ MÔ PHỎNG
Chương 1. GiỚI THIỆU VỀ MÔ PHỎNG
 
01_SE intro1.pptx
01_SE intro1.pptx01_SE intro1.pptx
01_SE intro1.pptx
 
ChuyenDe7.pdf
ChuyenDe7.pdfChuyenDe7.pdf
ChuyenDe7.pdf
 

Último

CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...Nguyen Thanh Tu Collection
 
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...Nguyen Thanh Tu Collection
 
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...Nguyen Thanh Tu Collection
 
lịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.pptlịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.pptLinhPham480
 
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...Nguyen Thanh Tu Collection
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...Nguyen Thanh Tu Collection
 
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...Nguyen Thanh Tu Collection
 
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...Nguyen Thanh Tu Collection
 
IELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptxIELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptxNguynHn870045
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...Nguyen Thanh Tu Collection
 
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...Nguyen Thanh Tu Collection
 
Day tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptxDay tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptxngothevinhs6lite
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...Nguyen Thanh Tu Collection
 
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...Nguyen Thanh Tu Collection
 
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...Nguyen Thanh Tu Collection
 
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...Nguyen Thanh Tu Collection
 
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...Nguyen Thanh Tu Collection
 

Último (17)

CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
 
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
 
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
 
lịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.pptlịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.ppt
 
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
 
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
 
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
 
IELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptxIELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptx
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
 
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
 
Day tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptxDay tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptx
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
 
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
 
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
 
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
 
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
 

Chuong 3 xac_dinh_yeu_cau_he_thong, hệ thống

  • 1. 1 Chương 3 Kỹ thuật yêu cầu (Requirement Engineering)
  • 2. 2 Nội dung 1. Kỹ thuật yêu cầu là gì 2. Xác định yêu cầu hệ thống là gì 3. Các loại yêu cầu hệ thống 4. Quy trình RE
  • 3. 3 1. Kỹ thuật yêu cầu là gì (Requirement Engineering) • Ta dùng Requirement Engineering thay cho Requirement Analysis • RE là quá trình lặp bao gồm 3 hoạt động: – Rút ra yêu cầu từ thực tế (Elicitation) – Đặc tả yêu cầu (Specification) – Xác thực (Validation) • Kết quả của quá trình RE là những đặc tả về hệ thống phần mềm
  • 4. 4 2. Yêu cầu (Requirement ) là gì? Requirements described the “what” of a system, not the “how” Mô tả cái gì cần cho hệ thốngMô tả cái gì cần cho hệ thống
  • 5. 5 Yêu cầu phần mềm • Phản ánh sự hiểu biết lẫn nhau về vấn đề giữa người phân tích và khách hàng • Nền tảng để xây dựng hợp đồng • Là sự chuẩn bị cho giai đoạn tiếp theo (giai đoạn phân tích) • Là tài liệu để kiểm tra hệ thống khi được phát hành
  • 6. 6 Input/ Output của xác định yêu cầu • Input: – Các yêu cầu từ khách hàng (Problem statement prepared by the customers) • Output: – Tài liệu đặc tả yêu cầu ( Software requirements specification – SRS)
  • 7. 7 Mức độ mô tả yêu cầu • Yêu cầu người dùng: – Chủ yếu dành cho người dùng – Viết bằng ngôn ngữ tự nhiên và biểu đồ – Mô tả dịch vụ và ràng buộc hoạt động • Yêu cầu hệ thống: – Tài liệu có cấu trúc mô tả chức năng, dịch vụ và ràng buộc hoạt động của hệ thống – Có thể là một phần của hợp đồng
  • 9. 9 3. Các loại yêu cầu hệ thống • Các yêu cầu của hệ thống phần mềm thường được chia thành ba loại: – Yêu cầu chức năng – Yêu cầu phi chức năng – Yêu cầu miền ứng dụng • Thực tế khó phân biệt ba loại yêu cầu này một cách rõ ràng.
  • 10. 10 03/11/14 10 Yêu cầu chức năng • Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống một cách chi tiết. • Đặc điểm của yêu cầu chức năng: – Tính mập mờ, không rõ ràng của các yêu cầu: • Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận. – Tính hoàn thiện và nhất quán: • Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược giữa các yêu cầu.
  • 11. 11 Ví dụ • Trong hệ thống quản lý thư viện: – Người dùng được cấp tài khoản riêng – Người dùng có thể tìm kiếm; download; in các bài báo – Người dùng có thể được cấp một vùng riêng để lưu dữ liệu
  • 12. 12 03/11/14 12 Yêu cầu phi chức năng • Yêu cầu phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. • Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: – độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ … – các ràng buộc của hệ thống (khả năng của thiết bị vào/ra, giao diện …) • Một số yêu cầu phi chức năng còn có liên quan đến quy trình xây dựng hệ thống (các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình …) • Các yêu cầu phi chức năng có thể hạn chế những yêu cầu chức năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ không sử dụng được.
  • 13. 13 3 yêu cầu phi chức năng cơ bản • Yêu cầu về sản phẩm: – Hiệu năng – Khả năng sử dụng – Độ tin cậy … của sản phẩm • Yêu cầu về mặt tổ chức: – Cơ cấu tổ chức; Chính sách của tổ chức – Thời gian bàn giao – Tương thích với hệ thống cũ • Yêu cầu ngoài: – Do các tác nhân ngoài hệ thống – Tính pháp lý – Tính riêng tư
  • 14. 14 03/11/14 14 Lý do xuất hiện yêu cầu phi chức năng • 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
  • 15. 15 15 Ví dụ về yêu cầu phi chức năng • Xác định các yêu cầu phi chức năng của Hệ thống đặt vé tàu trước – Yêu cầu về sản phẩm: phải xây dựng website – Yêu cầu về mặt tổ chức: mạng máy tính nối tất cả các trạm xe lửa với nhau. – Yêu cầu ngoài: Hệ thống phải bảo mật
  • 16. 16 03/11/14 16 Ví dụ về yêu cầu phi chức năng • Các mục tiêu và yêu cầu phi chức năng có thể thẩm định được của Hệ thống đặt vé tàu trước – Mục tiêu của hệ thống là dễ sử dụng đối với nhân viên cũng như hành khách và được tổ chức để sao cho tối thiểu hoá được lỗi. – Các yêu cầu phi chức năng có thể thẩm định được: Những người nhân viên sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày.
  • 17. 17 03/11/14 17 Yêu cầu miền ứng dụng • Yêu cầu miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng. • Nó có thể là yêu cầu chức năng hoặc phi chức năng. • Nếu yêu cầu miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được. • Một số vấn đề liên quan đến yêu cầu miền ứng dụng: – Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng. – Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật.
  • 18. 18 Một số ràng buộc • Ràng buộc trước sau • Ràng buộc cấu trúc • Ràng buộc suy diễn • Ràng buộc thời gian Môn học loại cơ sở phải học trước môn học loại chuyên ngành Điểm giữa kỳ <4 thì thi lại, nếu thi lại <4 thì học lại, nếu >=4 thì được thi cuối kỳ Dựa vào luật Lương kỳ 1 phải trả trước ngày 5 hàng tháng Khi người dùng nhấn Enter thì chỉ trong 2 giây thì hệ thống phải hồi đáp
  • 19. 19 4. Quy trình RE • Thu thập yêu cầu (Requirement Elicitation) • Phân tích yêu cầu (Requirement Analysis) • Tạo tài liệu đặc tả yêu cầu (Requirement Documentation) • Đánh giá yêu cầu (Requirement Review)
  • 20. 20
  • 21. 21 Bước 1: Thu thập yêu cầu (Requirement Elicitation) • Mục đích • Nội dung cần thu thập • Những khó khăn • Các kỹ thuật
  • 22. 22 Mục đích • Tiếp cận với nghiệp vụ, chuyên môn, môi trường hoạt động của hệ thống • Tìm hiểu các chức năng, nhiệm vụ và cung cách hoạt động của hệ thống • Chỉ ra những chỗ hợp lý cần được kế thừa, những chỗ bất hợp lý cần khắc phục
  • 23. 23 Nội dung cần thu thập • Đánh giá tính khả thi về nghiệp vụ và kỹ thuật của hệ thống • Nhận biết xem ai sẽ giúp xác định yêu cầu và hiểu biết thực chất của tổ chức – Operation manager, product manager – Makerting people – Internal/external customer – End-users – Consultant – Product engineer, Software engineer • Xác định môi trường kỹ thuật • Nhận biết các ràng buộc nghiệp vụ (domain constraint)
  • 24. 24 Những khó khăn thường gặp 1. Khó khăn về phạm vi (Problems of scope): đường biên hệ thống thường mập mờ, hay khách hàng chỉ nhắm đến các yếu tố kỹ thuật hơn là mục tiêu tổng thể của hệ thống 2. Khó khăn về hiểu biết khách hàng: khách hàng không biết họ cần gì, có ý kiến trái ngược nhau về hệ thống cần xây dựng, ít hiểu biết về kỹ thuật, thời gian giao tiếp với kỹ sư hệ thống thường rất hạn chế. 3. Khó khăn về tính ổn định: yêu cầu thường thay đổi theo thời gian
  • 25. 25 Các kỹ thuật thu thập yêu cầu • Các kỹ thuật thu thập yêu cầu: – Phỏng vấn (Interview) • Chọn lựa stakeholder để phỏng vấn – Phiếu điều tra (questionnaire) – Thu thập tài liệu : biểu mẫu, báo cáo, thống kê, số liệu,… – Phiên họp động não ( brainstorm session): kỹ thuật thảo luận nhóm giúp tìm ra nhanh chóng những ý tưởng mới – Sử dụng kịch bản (scenario) để phát hiện các yêu cầu của hệ thống. • Tạo các kịch bản (scenario) để giúp khách hàng/người dùng xác định tốt hơn các yêu cầu chính của hệ thống • Một tập hợp các use case sẽ mô tả tất cả các tương tác có thể trong hệ thống.
  • 26. 26 Bước 2: Phân tích yêu cầu (Requirement Analysis) • Mục đích • Nguyên lý phân tích • Hướng phân tích • Các mô hình phân tích • Các bước phân tích yêu cầu theo hướng dòng dữ liệu • Nội dung chính của RSC
  • 27. 27 Mục đích • Phân tích yêu cầu nhằm phân loại và tổ chức các yêu cầu thành các tập con có liên quan nhau • Xếp loại các yêu cầu theo nhu cầu của người dùng • Tổng hợp, điều chỉnh yêu cầu theo hướng tổng quan nhất • Chỉ ra được hệ thống làm việc gì, làm với dữ liệu nào
  • 28. 28 Nguyên lý phân tích • Nguyên lý 1: Miền dữ liệu – Xác định đối tượng dữ liệu – Mô tả thuộc tính dữ liệu – Thiết lập quan hệ dữ liệu • Nguyên lý 2: Miền chức năng – Xác định chức năng biến đổi dữ liệu – Chỉ ra luồng dữ liệu trong hệ thống – Biểu diễn chức năng, luồng dữ liệu, kho dữ liệu • Nguyên lý 3: Xác định các trạng thái – Chỉ ra những trạng thái của hệ thống – Chỉ ra những sự kiện gây biến đối trạng thái • Nguyên lý 4: Phân tách mô hình – Tinh chế đối tượng, dữ liệu – Tạo hệ thống ở cấp bậc chức năng – Biểu diễn hành vi ở mức chi tiết • Nguyên lý 5: Sự thiết yếu – Chú trọng vấn đề thiết yếu – Loại bỏ những vấn đề chi tiết
  • 29. 29 Nguyên lý davis • Hiểu vấn đề trước khi tạo mô hình phân tích • Tạo bản mẫu (prototype) cho phép người dùng hiểu được tương tác giữa người và máy • Ghi nhận nguồn gốc và lý do của mỗi yêu cầu • Dùng nhiều khung nhìn • Phân loại mức độ ưu tiên của yêu cầu • Loại bỏ những sự mơ hồ
  • 30. 30 Hướng phân tích • Phân tích hướng cấu trúc – Dữ liệu, quá trình biến đổi dữ liệu – Sử dụng các biểu đồ: chức năng, DFD, ERD, RDM, chuẩn hóa dữ liệu, từ điển dữ liệu • Phân tích hướng đối tượng – Tập trung vào đối tượng, sự tương tác giữa các đối tượng – Sử dụng UML
  • 31. 31 Các mô hình phân tích Analysis Model Scenario-based Element Use case diagram Activity diagram Scenario-based Element Use case diagram Activity diagram Flow-oriented Element Data Flow Diagram Control-Flow diagram Flow-oriented Element Data Flow Diagram Control-Flow diagram Behavioral Element State diagram Sequence diagram Behavioral Element State diagram Sequence diagram Class-based Element Class diagram CRC models Class-based Element Class diagram CRC models
  • 32. 32 Use case diagram • Là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể. • Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống. • Use case bao gồm: – Actor (tác nhân) – Use case (hành động)
  • 34. 34 Data Flow diagram • Flow-oriented modeling vẫn là 1 trong những cách thông dụng nhất hiện nay để phân tích hệ thống. Tên gọi khác lược đồ dòng dữ liệu (Data Flow Diagram – DFD) • DFD dùng để mô hình hóa các yêu cầu hệ thống. • DFD biểu diễn các bước mà luồng dữ liệu phải trải qua trong hệ thống từ điểm đầu tới điểm cuối. • DFD mô hình hoá hệ thống từ góc độ một chức năng. Việc tìm vết và tư liệu hoá quan hệ giữa dữ liệu với một quy trình rất có ích đối với việc tìm hiểu toàn bộ hệ thống. • DFD bao gồm: – Mức ngữ cảnh – Mức 1, mức 2 … • Tuy DFD và không thuộc định dạng của UML nhưng chúng vẫn được dùng để bổ sung cho các lược đồ UML và giúp xác định rõ hơn các yêu cầu của hệ thống
  • 36. 36 State diagram • Tất cả các đối tượng đều có trạng thái; • Tạng thái là một kết quả của các hoạt động trước đó đã được đối tượng thực hiện và nó thường được xác định qua giá trị của các thuộc tính cũng như các nối kết của đối tượng với các đối tượng khác. • Một lớp có thể có một thuộc tính đặc biệt xác định trạng thái, hoặc trạng thái cũng có thể được xác định qua giá trị của các thuộc tính “bình thường" trong đối tượng. • Một đối tượng sẽ thay đổi trạng thái khi có một việc nào đó xảy ra, thứ được gọi là sự kiện; • Miêu tả một đối tượng có thể có những trạng thái nào trong hệ thống
  • 39. 39 Class diagram • Là một tập hợp các đối tượng có chung các thuộc tính, các ứng xử và các ngữ nghĩa • Lớp gồm có: – Tên lớp (lass name) – Thuộc tính (attribute) – Phương thức (methods) • Biểu đồ lớp mô tả các lớp và các quan hệ giữa các lớp với nhau
  • 41. 41 Mô hình hóa dữ liệu (Data Modeling) • Mô hình dữ liệu gồm 3 thành phần chính: – Đối tượng dữ liệu (Data object) – Thuộc tính (attribute): mô tả đối tượng dữ liệu – Mối liên hệ (relationship) giữa các đối tượng dữ liệu
  • 42. 42 Mô hình hóa dữ liệu (Data Modeling) • Lược đồ Entity-Relationship (ERD) • Lược đồ Relational Data Model (RDM) • Chuẩn hóa dữ liệu • Từ điển dữ liệu
  • 43. 43 Các bước phân tích yêu cầu theo hướng dòng dữ liệu (Flow oriented) Draw the context diagram Draw the context diagram Develop Prototypes (optional) Develop Prototypes (optional) Model the requirements Model the requirements Finalise the requirements Finalise the requirements
  • 44. 44 Phát triển prototype (Development of protoype) • Xây dựng prototype tương tự như hệ thống cần xây dựng, khách hàng sẽ xem xét cho cho ý kiến phản hồi, prototype sẽ liên tục được điều chỉnh để thỏa mãn yêu cầu khách hàng. • Prototype là cách giúp tìm hiểu hiệu quả mong muốn thực sự của khách hàng. • Prototype thường được xây dựng nhanh, chi phí thấp, nên sẽ có nhiều hạn chế và thiếu xót so với hệ thống cuối  Prototype chỉ là 1 tùy chọn (optional)
  • 45. 45 Nội dung chính của SRS 1. Functionality: phần mềm được dùng để làm gì? 2. External interfaces: phần mềm giao diện với người dùng như thế nào? Với phần cứng và các phần mềm khác ra sao? 3. Performance: tốc độ, thời gian đáp ứng, thờigian hồi phục,… của mỗi chức năng phần mềm thế nào? 4. Attributes: khả năng bảo trì, độ chính xác, độ tin cậy, khả năng bảo mật, … 5. Design constraints: Phần mềm bị ràng buộc bởi các tiêu chuẩn nào? Ngôn ngữ thực thi, chính sách bảo toàn cSDL, hạn chế về tài nguyên, hệ điều hành sử dụng,…
  • 46. 46 Yêu cầu của SRS 1. Nên xác định đúng tất cả yêu cầu phần mềm. 2. Không nên mô tả bất kỳ chi tiết nào liên quan đến thiết kế hay thực thi 3. Không nên đưa các ràng buộc dư thừa vào SRS. Một số ràng buộc về chất lượng nên đưa vào kế hoạch bảo đảm chất lượng phần mềm
  • 47. 47 Đặc tính của SRS • Correct • Unambiguous • Complete • Consistent • Stability • Verifiable • Modifiable • Traceable • (chính xác) • (rõ ràng) • (hoàn thành) • (nhất quán) • (ổn định) • (có thể thẩm tra) • (có thể sửa đổi) • (có thể miêu tả)
  • 48. 48 Nghiên cứu tính thực thi Feasibility study • Feasibility study là 1 bước quan trọng trong bất kỳ quy trình phát triển phần mềm nào. Nghiên cứu này nhằm phân tích chi phí (cost), thời gian (time) cần thực hiện trong mỗi giai đoạn. • Feasibility study là một trong các kết quả của phân tích yêu cầu phần mềm.
  • 49. 49 Thuận lợi của feasibility study • Được xem như bước khởi đầu của chu kỳ phát triển phần mềm (SDLC) dùng để phân tích toàn diện các yêu cầu của hệ thống. • Giúp nhận biết các thừa số rủi ro (risk factor) ảnh hưởng đến việc phát triển và triển khai hệ thống. • Là cơ sở để phân tích chi phí/lợi nhuận của hệ thống • Giúp lập kế hoạch đào tạo đội ngũ phát triển hệ thống. • Là báo cáo giúp ban lãnh đạo dựa vào đó ra quyết định
  • 50. 50 Bước 3: Đặc tả yêu cầu (Requirement Documentation) • Tạo tư liệu về yêu cầu (requirement documentation) là một hoạt động rất quan trọng sau khi thu thập và phân tích yêu cầu hệ thống. Đây là cách để biểu diễn yêu cầu theo một định dạng thống nhất. • Các tài liệu về yêu cầu được gọi là đặc tả yêu cầu phần mềm (Software requirement Specification – SRS) • Các đặc tả có thể là tài liệu, mô hình đồ họa, mô hình toán học, tập hợp các ngữ cảnh hay dùng. • Có một số mẫu tiêu chuẩn “standard template”, tuy nhiên tùy theo hệ thống các đặc tả này có thể thay đổi linh động theo.
  • 51. 51 Các phương pháp đặc tả • Đặc tả yêu cầu bằng ngôn ngữ tự nhiên – Không rõ ràng – Quá mềm dẽo – Thiếu cấu trúc • Đặc tả yêu cầu bằng ngôn ngữ cấu trúc – Tuân thủ các chuẩn về từ ngữ, về cấu trúc – Duy trì ngôn ngữ tự nhiên • Đặc tả bằng biểu mẫu • Đặc tả dạng bảng • Đặc tả theo ngôn ngữ PDL (Program Design Language) • Đặc tả theo mô hình • Đặc tả theo IEEE
  • 52. 52 Bước 4: Đánh giá yêu cầu (Requirement Review) • Xác định những yêu cầu có phù hợp với những gì khách hàng mong muốn hay không • Chi phí cho lỗi về yêu cầu rất cao (chi phí cho sửa lỗi sau khi xuất xưởng gấp 100 lần so với khi cài đặt) • Các thuộc tính cần kiểm tra – Giá trị (validity) – Toàn vẹn (Consistency) – Đầy đủ (Completeness) – Hiện thực (Realism) – Kiểm tra được (Verifiability)
  • 53. 53 Kỹ thuật đánh giá yêu cầu • Kiểm tra yêu cầu – Phân tích thủ công – Kiểm tra có tính hệ thống • Tạo mẫu – Sử dụng các mô hình có thể thực thi • Tạo tình huống kiểm tra – Tình huống bình thường – Tình huống đặc biệt
  • 54. 54 Nội dung • Ước tính quy mô dự án (Size estimation) – Số dòng lệnh (lines of code) – Function Point • Ước tính chi phí – Mô hình COCOMO
  • 55. 55 Ước tính quy mô dự án • Là bước quan trọng khi bắt đầu dự án • Rất khó để ước tính phạm vi của 1 hệ thống phần mềm vì: – Phần mềm là sản phẩm trừu tượng – Xây nhà, cầu đường là sản phẩm cụ thể, có thể nhìn thấy và sờ mó được • Hai phương pháp thông dụng: – Tính số dòng lệnh (Lines Of Code – LOC) – Tính Function Point (FP)
  • 56. 56 Lines Of Code (LOC) • Chưa có sự thống nhất trong quy ước đếm LOC • Trước đây: không tính đến các dòng khai báo dữ liệu, chú thích, .. • Gần đây: tính cả dòng khai báo, chú thích • Lý do: chương trình mới chứa hơn 50% dòng dữ liệu, và các dòng này cũng thường xuyên gây lỗi như các dòng lệnh thông thường
  • 57. 57 Ví dụ 10 If (x[i] < x[j]) 11 { 12 Save = x[i]; 13 X[i] = x[j]; 14 X[j] = Save; 15 } 16 } 17 Return 0; 18 } 1 int sort(int x[], int n) 2 { 3 int i,j, save, im1; 4 /* this function sorts array x 5 if (n<2) return 1; 6 for (i=2;i<=n;i++) 7 { 8 im1= i-1; 9 for(j=1;j<=im;j++)
  • 58. 58 Lines Of Code (LOC) • LOC của chương trình? 17, 18 hay 13 • Theo định nghĩa của Conte: Dòng mã là bất kỳ dòng nào (tiêu đề, khai báo, lệnh khả thi và không khả thi) trong chương trình, không kể dòng chú thích (comment), bất kể có bao nhiêu dòng mã hay khối mã trên cùng 1 dòng” • LOC của chương trình là 17
  • 59. 59 Lines Of Code (LOC) • Ưu điểm: đơn giản, cụ thể • Nhược điểm: – Phụ thuộc vào ngôn ngữ, không chỉ ra được tổng thể dự án – Đếm dòng lệnh tương tự như đếm số gạch để xây nhà cao tầng, chỉ cho biết số gạch cần dùng nhưng không chỉ ra được số phòng, tổng diện tích xây dựng, tổng diện tích đất, … • Ứng dụng: dùng LOC để ước tính thời gian lập trình
  • 60. 60 Tính Function Point (FP) • Dùng để đánh giá chức năng của phần mềm theo quan điểm người dùng (người dùng yêu cầu gì và hệ thống đáp ứng ra sao) • Đo lường quy mô dự án theo FP không phụ thuộc vào việc sử dụng công nghệ • Ví dụ: – Hai phần mềm kế toán, một được viết bằng assembler, một được viết bằng C#, nhưng thực thi những chức năng như nhau. – Người dùng chỉ quan tâm đến việc mua phần mềm kế toán, mà không cần quan tâm đến nó chứa bao nhiêu dòng lệnh, viết bằng ngôn ngữ nào.
  • 61. 61
  • 62. 62 Tính Function Point (FP) • Theo FPA (FP analysis) của Albrecht, một hệ thống được chia thành 5 đơn vị chức năng (functional unit) như sau: – Inputs – Outputs – Enquiries – Internal logical files – External interface files
  • 63. 63 Tính Function Point (FP) • Các đơn vị chức năng được phân loại dựa vào độ phức tạp: Low, Average, High. Functional Units Weighting factors Low Average High External Inputs (EI) 3 4 5 External Outputs (EO) 4 5 7 External Inquiries (EQ) 3 4 6 Internal logical files (ILF) 7 10 15 External interface files (EIF) 5 7 10 Bảng 1
  • 64. 64 Tính Function Point (FP) • Trình tự tính FP của hệ thống: – Phân loại theo năm loại chức năng – Tính UFP (Unadjusted Function Points) – Tính FP
  • 65. 65 Tính UFP (Unadjusted Function Points) ∑∑= = = 5 1 3 1i j ijij wZUFP i là chỉ số hàng, j là chỉ số cột của bảng 1 wij là giá trị của hàng i cột j bảng 1 Zij là kết quả đếm của loại chức năng i với độ phức tạp tương ứng với cột j
  • 66. 66 Tính FP FP = UFP * CAF • CAF (complexity adjustment factor) và được tính như sau: ∑+= ]01.065.0[ iFCAF Fi (i=1 to 14) là mức độ ảnh hưởng dựa vào 14 câu hỏi trong bảng 2. Mỗi thừa số sẽ có tỷ lệ từ 0 đến 5
  • 67. 67 Bảng 2: Các thừa số Fi 1. Does the system require reliable backup and recovery? 2. Is data communication required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing heavily utilized oprational environment? 6. Does the system require on line data entry? 7. Does the on line data entry require the input transaction to be built over multiple screens or operations? 8. Are the master files updated on line? 9. Is the inputs, outputs, files or inquiries complex?
  • 68. 68 Bảng 2: Các thừa số Fi 10. Is the internal processing complex? 11. Is the code designed to be reusable? 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? 10. Is the internal processing complex? 11. Is the code designed to be reusable? 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? 0 1 2 3 4 5 No Influence Incredental Moderate Average Significant Essential
  • 69. 69 Mục đích của việc tính FP • Dành cho nhà quản lý để giám sát mức hiệu quả của dự án. • FP phản ánh được quy mô của dự án. • Dựa vào FP để tính chi phí phát triển dự án: – Productivity = FP/person-months – Quality = Defects/FP – Cost = USD/FP – Documentation = Pages of documentation per FP
  • 70. 70 Ví dụ 1 • Khảo sát dự án với các đơn vị chức năng như sau: – Number of user inputs = 50 – Number of user outputs = 40 – Number of user enquiries = 35 – Number of user files = 06 – Number of external interfaces = 04 Giả sử tất cả các thừa số điều chỉnh độ phức tạp và thừa số trọng số đều trung bình Tính FP cho dự án
  • 71. 71 Ví dụ 1 ∑∑= = = 5 1 3 1i j ijij wZUFP UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7 = 628 CAF = (0.65 + 0.01 ΣFi) = 0.65 + 0.01(14x3) = 1.07 FP = UFP x CAF = 628 x 1.07 = 672
  • 72. 72 Ước tính chi phí bằng mô hình COCOMO • Mô hình COCOMO (Constructive Cost Model) bao gồm: – Mô hình cơ bản (Basic model) – Mô hình trung cấp (Intermediate model) – Mô hình con chi tiết (Detailed sub model)
  • 73. 73 Mô hình COCOMO cơ bản • Dùng ước tính nhanh và sơ bộ chi phí dự án cho hầu hết các dự án nhỏ và vừa. • Có ba dạng phát triển phần mềm: – Organic: dành cho 1 đội nhỏ các nhà phát triển có kinh nghiệm và mội trường quen thuộc – Semi-detached: trung gian giữa organic và embedded – Embedded: dành cho dự án có nhiều ràng buộc chặt chẽ, thường là dự án mới và duy nhất, khó tìm người thực hiện
  • 74. 74 Bảng so sánh ba dạng COCOMO Mode Quy mô dự án Bản chất dự án Sự sáng tạo Thời hạn Môi trường phát triển Organic 2-50 KLOC Dự án nhỏ, developer kinh nghiệm trong môi trường thân thiện Ít Không chặt Quen thuộc, nội bộ Semi -detached 50 – 300 KLOC Dự án TB, đội TB, kinh nghiệm đã làm cho dự án tương tự TB TB TB TB Embbeded >300 KLOC Dự án lớn, HT real time. Giao diện phức tạp, đội có kinh nghiệm trước đó rất ít Đáng kể Chặt Yêu cầu HW và giao diện phức
  • 75. 75 Mô hình COCOMO cơ bản • Công thức tính COCOMO cơ bản (basic) b b d b b b EcD KLOCaE )( )( = = E là Effort được tính bằng Person-Months D là thời gian phát triển ( development time), tính bằng tháng ab, bb, db là các hệ số được tra theo bảng 3 • Số lượng nhân viên và mức độ hiệu quả của dự án được tính như sau: Average staff size (SS) = E/D Persons Productivity (P) = KLOC/E KLOC/PM
  • 76. 76 Bảng 3: Các hệ số COCOMO cơ bản Project ab bb cb db Organic 2.4 1.05 2.5 0.38 Semi -detached 3.0 1.12 2.5 0.35 Embbeded 3.6 1.20 2.5 0.32 Bảng 3
  • 77. 77 • Giả sử dự án được ước tính khoảng 400 KLOC. Hãy tính nhân lực và thời gian cho mỗi loại dự án khác nhau 1. Đối với loại Organic: E = 2.4(400)1.05 = 1295.31 PM D = 2.5(1295.31)0.38 = 38.07 M 2. Đối với loại Semidetached: E = 3.0(400)1.12 = 2462.79 PM D = 2.5(2462.79)0.35 = 38.45 M 3. Đối với loại Embbeded: E = 3.6(400)1.20 = 4772.81 PM D = 2.5(1295)0.32 = 38 M Ví dụ 1 Nhận xét?
  • 78. 78 Nhận xét • Chọn loại dự án rất quan trọng, tùy thuộc vào 2 yếu tố: – Quy mô dự án – Các hệ số trong bảng 3
  • 79. 79 Ví dụ 2 • Quy mô dự án được ước tính khoảng 200 KLOC. Đội phát triển phần mềm có kinh nghiệm ở mức trung bình cho các loại dự án tương tự. Lịch biều của dự án không đòi hỏi chặt chẽ lắm. Hãy tính thời gian phát triển, số người bình quân của đội, và tính hiệu suất của dự án Solution: Dự án thuộc loại semi-detached – Tính các hệ số: E = 3.0(200)1.12 = 1133.12 PM D = 2.5(1133.12)0.35 = 38.67 M – Số nhân viên (staff size) = E/D = 38.67 người – Hiệu suất dự án (productivity) = KLOC/E = 176 LOC/PM
  • 80. 80 Mô hình COCOMO intermediate (mức trung cấp) • Mô hình COCOMO cơ bản tuy ước tính nhanh nhưng sơ bộ nên thiếu chính xác. • Mô hình COCOMO mức trung bổ sung thêm 15 thừa số chi phí (cost driver) • Các thừa số chi phí này được phân thành 4 nhóm chính (bảng 4)
  • 81. 81 Cost Driver RATINGS Very low Low Norminal High Very High Extra High Product Attributes RELY 0.75 0.88 1.00 1.15 1.40 - DATA - 0.94 1.00 1.08 1.16 - CPLX 0.70 0.85 1.00 1.15 1.30 1.65 Computer Attributes TIME - 1.00 1.11 1.30 1.66 STOR - - 1.00 1.06 1.21 1.56 VIRT - 0.87 1.00 1.15 1.30 - TURN - 0.87 1.00 1.07 1.15 - Personnel Attributes ACAP 1.46 1.19 1.00 0.86 0.71 - AEXP 1.29 1.13 1.00 0.91 0.82 - PCAP 1.42 1.17 1.00 0.86 0.70 - VEXP 1.21 1.10 1.00 0.90 - - LEXP 1.14 1.07 1.00 0.95 - - Project Atributes MODP 1.24 1.10 1.00 0.91 0.82 - TOOL 1.24 1.10 1.00 0.91 0.83 - SCED 1.23 1.08 1.00 1.04 1.10 - BẢNG 4
  • 82. 82 Product Attributes RELY Required sotware Reliability DATA Database size CPLX Product complexity Computer Attributes TIME Execution Time constraints STOR Main Storage constraints VIRT Virtual Machine volatility TURN Computer turnaround time Personnel Attributes ACAP Analyst capability AEXP Application experience PCAP Programmer capability VEXP Virtual Machine experience LEXP Programming Language experience Project Atributes MODP Modern Programming practices TOOL Use of software tools SCED Required development schedule
  • 83. 83 Mô hình COCOMO intermediate (mức trung cấp) • Thừa số EAF (Effort adjustment factor) là tích của 15 thừa số chi phí. • EAF thường dao động từ 0.9 đến 1.4
  • 84. 84 Bảng 5: Các hệ số của COCOMO mức trung Project ai bi ci di Organic 3.2 1.05 2.5 0.38 Semi -detached 3.0 1.12 2.5 0.35 Embbeded 2.8 1.20 2.5 0.32
  • 85. 85 Mô hình COCOMO mức trung • Công thức tính COCOMO mức trung (intermediate) i i d i b i EcD KLOCaE )( )( = = E là Effort được tính bằng Person-Months D là thời gian phát triển ( development time), tính bằng tháng ai, bi, di là các hệ số được tra theo bảng 5 • E tinh chỉnh = E x EAF • Số lượng nhân viên và mức độ hiệu quả của dự án được tính như sau: Average staff size (SS) = E/D Persons Productivity (P) = KLOC/E KLOC/PM
  • 86. 86 Ví dụ • Một dự án mới được ước tính là hệ thống nhúng (embedded system) có 400 KLOC. Người quản lý dự án phải chọn lựa giữa 2 nhóm làm việc: một nhóm rất có năng lực nhưng hầu như không có kinh nghiệm gì về ngôn ngữ lập trình sẽ được dùng trong dự án; nhóm khác thì không giỏi lắm nhưng có nhiều kinh nghiệm về ngôn ngữ lập trình. Hãy xét xem việc chọn lựa các nhóm sẽ ảnh hưởng như thế nào đến dự án??
  • 87. 87 Ví dụ Solution: Vì là dự án kiểu embedded và mô hình COCOMO mức trung nên: E= ai(KLOC)bi = 2.8(400)1.20 = 3712 PM Trường hợp 1: chọn nhóm có năng lực nhưng không có kinh nghiệm EAF = 0.82 x 1.14 = 0.9348  E1 = EAF x E = 0.9348 x 3712 = 3470 PM  D1 = ci (E)di = 2.5(3470)0.32 = 33.9 PM
  • 88. 88 Ví dụ • Trường hợp 2: nhóm ít có năng lực nhưng nhiều kinh nghiệm – EAF = 1.29 x 0.95 = 1.22 – E2 = EAF x E = 1.22 x 3712 = 4528 PM – D2 = ci (E)di = 2.5(4528)0.32 = 36.9PM Nhận xét: Nhóm 2 cần nhiều người và thời gian hơn. Vì vậy, nhóm năng lực yếu tuy có nhiều kinh nghiệm lập trình không thể phù hợp với dự án loại embedded.
  • 89. 89 Mối quan hệ giữa LOC và FP • Phụ thuộc vào ngôn ngữ lập trình được dùng để thực thi và chất lượng thiết kế. • LOC và FP được dùng để ước tính khá chính xác chi phí (cost) và nhân lực (effect) • Bảng LOC/FP
  • 90. 90 Các ví dụ • Ước tính theo LOC (page 128 Roger 5e) • Ước tính theo FP (page 129 Roger 5e)
  • 91. 91 Ví dụ ước tính theo LOC • A software package to be developed for a computer-aided design application for mechanical components. A review of the System Specification indicates that the software is to execute on an engineering workstation and must interface with various computer graphics peripherals including a mouse, digitizer, high resolution color display and laser printer. • Using the System Specification as a guide, a preliminary statement of software scope can be developed:
  • 92. 92 Ví dụ ước tính theo LOC • The CAD software will accept two- and three-dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/ machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter.
  • 93. 93 Ví dụ ước tính theo LOC • Dựa vào phát biểu sơ bộ về phạm vi phần mềm (preliminary statement of software scope), xác định được các chức năng chính của phần mềm: • User interface and control facilities (UICF) • Two-dimensional geometric analysis (2DGA) • Three-dimensional geometric analysis (3DGA) • Database management (DBM) • Computer graphics display facilities (CGDF) • Peripheral control function (PCF) • Design analysis modules (DAM)
  • 94. 94 Ví dụ ước tính theo LOC
  • 95. 95 Ví dụ ước tính theo LOC • A review of historical data indicates that the organizational average productivity for systems of this type is 620 LOC/pm. Based on a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months.
  • 96. 96 Ví dụ Ước tính theo FP • The project planner estimates inputs, outputs, inquiries, files, and external interfaces for the CAD software. For the purposes of this estimate, the complexity weighting factor is assumed to be average. • The expected value for the estimation variable (size), S, can be computed as a weighted average of the optimistic (sopt), most likely (sm), and pessimistic (spess) estimates. S = (sopt + 4sm + spess)/6
  • 97. 97 Ví dụ Ước tính theo FP
  • 99. 99 Ví dụ Ước tính theo FP • The estimated number of FP is derived: FPestimated = count-total x [0.65 + 0.01 xΣ(Fi)] =375 • The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a burdened labor rate of $8000 per month, the cost per FP is approximately $1230. • Based on the LOC estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.
  • 100. 100 Bài đọc thêm • Blog của Glorevenhite http://glorevenhite.wordpress.com/2008/04/01/function-point-analys • Website QMS http://www.qsm.com/?q=resources/function-point-languages- table/index.html