Bài giảng Nhập môn Công nghệ phần mềm: Phần 2.1 - ThS. Phan Phương Lan

Chia sẻ: Thanh Hoa | Ngày: | Loại File: PDF | Số trang:23

Thêm vào BST

Báo xấu

80
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Nhập môn Công nghệ phần mềm - Phần 2: Tiến trình phần mềm" phần Phân tích và đặc tả yêu cầu" cung cấp cho người học các kiến thức: Quy trình và xác định yêu cầu, thu thập các yêu cầu, phân loại các yêu cầu, các đặc trưng của yêu cầu,... Mời các bạn cùng tham khảo nội dung chi tiết.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Nhập môn Công nghệ phần mềm: Phần 2.1 - ThS. Phan Phương Lan

Nội dung NHẬP MÔN  Phân tích và Đặc tả CÔNG NGHỆ PHẦN MỀM  Thiết kế PHẦN II –  Lập trình TIẾN TRÌNH PHẦN MỀM  Kiểm thử Bộ môn Công nghệ phần mềm,  Triển khai hệ thống và Bảo trì Khoa CNTT&TT, Đại học Cần Thơ  Tiến trình RUP 1 2 Ths.Phan Phương Lan Ths.Phan Phương Lan Nội dung TIẾN TRÌNH  Quy trình xác định các yêu cầu PHẦN MỀM  Thu thập các yêu cầu  Phân loại các yêu cầu  Các đặc trưng của yêu cầu PHẦN II.1 – PHÂN TÍCH &  Các ký hiệu mô hình hóa  Các ngôn ngữ đặc tả và yêu cầu ĐẶC TẢ YÊU CẦU  Lập bản mẫu cho các yêu cầu  Tài liệu yêu cầu  Thẩm tra và công nhận hợp lệ 3 4 Ths.Phan Phương Lan Ths.Phan Phương Lan 1
Quy trình xác định các yêu cầu Quy trình xác định các yêu cầu  Các yêu cầu là quan trọng  Một yêu cầu là sự diễn đạt cách hoạt động (behaviour)  Các yếu tố hàng đầu làm cho dự án thất bại: mong muốn.  Các yêu cầu không hoàn chỉnh  Một yêu cầu đề cập đến:  Thiếu sự tham gia của người sử dụng  Các đối tượng hay thực thể  Các mong muốn không thực tế  Trạng thái của đối tượng hay thực thể  Thiếu sự hỗ trợ về quản lý  Các chức năng được thực hiện để thay đổi trạng thái  Thay đổi các yêu cầu và các đặc tả hay các đặc trưng của đối tượng  Thiếu việc lập kế hoạch  Hệ thống không được cần nữa  Các yêu cầu tập trung vào nhu cầu của khách hàng chứ không phải tập trung vào giải pháp hay sự thực hiện.  Một phần nào đó trong quy trình xác định các yêu cầu liên quan đến hầu hết các nguyên nhân này. 5  Lỗi về yêu cầu có thể gây tốn kém nếu không được phát hiện sớm. 6 Ths.Phan Phương Lan Ths.Phan Phương Lan Quy trình xác định các yêu cầu Thu thập các yêu cầu  Được thực hiện bởi nhà phân tích yêu cầu hay nhà phân tích hệ thống. Có khoảng cách thông tin giữa khách hàng và nhà  Kết quả cuối cùng là tài liệu đặc tả các yêu cầu phần mềm. phân tích.   Sự thảo luận với các thành viên tham gia vào hoạt động thu thập yêu cầu là quan trọng.  Sự thảo luận đưa đến sự đồng ý giữa các bên về các yêu cầu. 7 8 Ths.Phan Phương Lan Ths.Phan Phương Lan 2
Thu thập các yêu cầu Thu thập các yêu cầu  Các thành viên tham gia trong hoạt động thu thập yêu cầu  Clients: trả tiền cho phần mềm được phát triển.  Các cách thu thập yêu cầu  Phỏng vấn những người tham gia trong hệ thống.  Customers: mua phần mềm sau khi nó được phát triển.  Người dùng: sử dụng hệ thống.  Phỏng vấn những người tham gia vào hệ thống theo nhóm.  Chuyên gia về lĩnh vực: biết rõ vấn đề mà phần mềm phải  Xem lại các tài liệu có sẵn. tin học hóa.  Quan sát hệ thống hiện hành (nếu hệ thống tồn tại).  Nhà nghiên cứu thị trường: thực hiện các cuộc khảo sát để  Theo người dùng để học về nghiệp vụ của họ một cách chi xác định các xu hướng tương lai và những khách hàng tiềm tiết hơn. năng.  Sử dụng các chiến lược xác định vấn đề như thiết kế ứng  Luật sư và kiểm toán viên: biết rõ các yêu cầu của luật dụng chung (Joint Application Design). pháp, chính phủ hay sự an toàn.  Vận dụng trí tuệ tập thể (brainstorming) của người dùng  Kỹ sư phần mềm và các chuyên gia công nghệ khác: đảm hiện tại và tiềm năng để có được các yêu cầu. bảo phần mềm là khả thi về kinh tế và công nghệ. 9 10 Ths.Phan Phương Lan Ths.Phan Phương Lan Thu thập các yêu cầu Phân loại các yêu cầu  Các nguồn của các yêu cầu có thể có  Phân loại các yêu cầu  Giải quyết các xung đột  Các loại tài liệu yêu cầu 11 12 Ths.Phan Phương Lan Ths.Phan Phương Lan 3
Phân loại các yêu cầu Phân loại các yêu cầu  Các yêu cầu chức năng (functional requirements) mô tả các chức năng và dịch vụ mà hệ thống phải cung cấp.  Các loại yêu cầu phi chức năng  Các yêu cầu phi chức năng (non-functional requirements) mô tả một đặc trưng nào đó về chất lượng nào mà phần mềm phải có.  Các ràng buộc thiết kế như chọn nền hay các thành phần của giao diện.  Các ràng buộc quy trình như sự hạn chế về các kỹ thuật và các tài nguyên được sử dụng để xây dựng hệ thống. 13 14 Ths.Phan Phương Lan Ths.Phan Phương Lan Phân loại các yêu cầu Các đặc trưng của yêu cầu  Giải quyết sự xung đột  Chính xác (Correct)  Các thành viên khác nhau có các yêu cầu khác nhau => các yêu cầu xung đột tiềm ẩn.  Nhất quán (Consistent)  Giải quyết sự xung đột bằng cách sắp thứ tự ưu tiên cho  Không mơ hồ (Unambigious) các yêu cầu.  Hoàn chỉnh (Complete)  Ba hạng mục ưu tiên:  Khả thi (Feasible)  Cần thiết: phải được đáp ứng một cách hoàn toàn.  Mong muốn: mong được đáp ứng cao nhưng không nhất  Có liên quan (Relevant) thiết.  Có thể kiểm thử (Testable)  Tùy chọn: có thể được đáp ứng nhưng có thể bị loại trừ.  Có thể theo vết (Traceable) 15 16 Ths.Phan Phương Lan Ths.Phan Phương Lan 4
Mô thức ký hiệu - Lưu đồ thực thể Các ký hiệu mô hình hóa quan hệ  Việc có các ký hiệu chuẩn để mô hình hóa, lập tài liệu, giao tiếp với các quyết định là quan trọng.  Một lưu đồ ký hiệu dạng đồ thị được ưa dùng để  Việc mô hình hóa giúp ta hiểu thấu đáo các yêu cầu (hoạt biểu diễn các mô hình mức quan niệm động còn mơ hồ hay chưa biết, sự xung đột giữa các kết  Các thành phần cốt lõi trong lưu đồ xuất hay sự không nhất quan trong các yêu cầu).  Thực thể: được vẽ như một hình chữ nhật, biểu diễn cho  Một số mô thức (paradigm) ký hiệu cơ bản: tập các đối tượng trong thế giới thực mà chúng có chung  Lưu đồ thực thể quan hệ (Entity Relationship Diagram - ERD) các đặc điểm và cách hoạt động  Dò theo sự kiện (Event Traces)  Quan hệ: được vẽ như một cạnh nối hai thực thể, với  Máy trạng thái (State Machines) hình thoi ở chính giữa cạnh xác định loại quan hệ  Lưu đồ dòng dữ liệu (Data Flow Diagram)  Hàm và quan hệ  Thuộc tính: một diễn giải trong thực thể. Nó mô tả dữ  Logic liệu hay các đặc tính được kết hợp với thực thể 17 18 Ths.Phan Phương Đặc tả đại số  Lan Ths.Phan Phương Lan Mô thức ký hiệu Mô thức ký hiệu - Lưu đồ thực thể - Lưu đồ thực thể quan hệ quan hệ  Ví dụ: sơ đồ lớp của UML (UML Class Diagram)  Ví dụ: sơ đồ thực thể - là một lưu đồ thực thể quan hệ phức tạp quan hệ của bài toán cửa quay  Lưu đồ thực thể quan hệ là phổ biến vì  Nó cung cấp một cái nhìn tổng quan về vấn đề phải được xác định.  Tính tổng quan là tương đối ổn định khi có thay đổi trong các yêu cầu.  Lưu đồ thực thể quan hệ có vẻ phù hợp để mô hình hóa vấn đề sớm trong quy trình xác định các yêu cầu. 19 20 Ths.Phan Phương Lan Ths.Phan Phương Lan 5
Mô thức ký hiệu - Lưu đồ thực thể Mô thức ký hiệu - Lưu đồ thực thể quan hệ quan hệ  Ví dụ: sơ đồ lớp của UML là lưu đồ thực thể quan hệ phức  Ví dụ: sơ đồ lớp của UML là lưu đồ thực thể quan hệ tạp phức tạp  Các thuộc tính và các phương thức được kết hợp với lớp hơn là với các thể hiện của lớp.  Liên kết kết tập (aggregation association)  Thuộc tính phạm vi lớp, được biểu diễn như một thuộc tính  Liên kết cấu thành (composition association) được gạch chân, là một giá trị dữ liệu mà nó được chia sẻ bởi  Liên kết tổng quát hóa tất cả các thể hiện của lớp.  …  Phương thức phạm vi lớp, được biểu diễn như một phương thức được gạch chân, là một phương thức được thực hiện bởi lớp trừu tượng hơn là bởi các thể hiện của lớp.  Liên kết (association), được biểu diễn bởi một đường nối giữa hai lớp, chỉ ra mối quan hệ giữa các thực thể của các lớp. 21 22 Ths.Phan Phương Lan Ths.Phan Phương Lan Mô thức ký hiệu - Dò theo sự kiện Mô thức ký hiệu - Dò theo sự kiện  Mô hình thực thể quan hệ không nói gì về cách mà các  Ví dụ: sự biểu diễn đồ thị của 2 theo vết của bài toán thực thể hành xử. cửa quay  Dò theo sự kiện là sự mô tả ở dạng đồ thị của một chuỗi các sự kiện mà chúng được trao đổi giữa các thực thể của thế giới thực.  Trục tung: đường thời gian của một thực thể riêng biệt; tên của nó xuất hiện trên đỉnh của trục.  Trục hoành: một sự kiện hay sự tương tác giữa hai thực thể.  Thời gian tiến triển theo hướng từ trên xuống.  Mỗi đồ thị mô tả một đơn dò theo sự kiện, biểu diễn cho một trong một vài cách hoạt động có thể có 23 24 Ths.Phan Phương Lan Ths.Phan Phương Lan 6
Mô thức ký hiệu - Dò theo sự kiện Mô thức ký hiệu - Dò theo sự kiện  Ví dụ biểu đồ tuần tự thông điệp là dò theo sự kiện được cải tiến: biểu  Ví dụ: sơ đồ tuần tự thông điệp là ký hiệu dò theo sự kiện đồ tuần tự thông điệp cho giao dịch mượn tài liệu của thư viện được cải tiến, với các phương tiện cho phép tạo ra hay hủy bỏ các thực thể, xác định các hoạt động và định thời, và tạo ra các dò theo  Đường dọc biểu diễn cho một thực thể tham gia  Thông điệp được vẽ bằng một mũi tên hướng từ thực thể gửi sang thực thể nhận.  Hoạt động được vẽ bằng hình chữ nhật được gán nhãn và được đặt trên đường thực thi của thực thể  Điều kiện là các trạng thái quan trọng trong sự tiến hóa của thực thể, được biểu diễn bằng hình sáu cạnh có gán nhãn 25 26 Ths.Phan Phương Lan Ths.Phan Phương Lan Mô thức ký hiệu - Máy trạng thái Mô thức ký hiệu - Máy trạng thái  Đường đi: bắt đầu từ trạng thái bắt đầu của máy và đi theo các  Sự mô tả ở dạng đồ thị của tất cả các cuộc đối thoại dịch chuyển từ trạng thái này sang trạng thái khác. giữa hệ thống và môi trường của nó.  Máy trạng thái hữu hạn: với mỗi trạng thái hay sự kiện, có một  Nút (trạng thái) biểu diễn một tập ổn định các điều kiện đáp ứng duy nhất. mà nó tồn tại giữa các lần xuất hiện của sự kiện.  Ví dụ: sơ đồ trạng thái máy cho bài toán cửa quay  Cạnh (dịch chuyển) biểu diễn cho sự thay đổi về hành vi hay điều kiện do sự xuất hiện của một sự kiện.  Hữu ích cả cho việc xác định hành vi động và cho việc mô tả cách mà hành vi nên thay đổi để đáp ứng được lịch sử của các sự kiện mà chúng đã xuất hiện. 27 28 Ths.Phan Phương Lan Ths.Phan Phương Lan 7
Mô thức ký hiệu - Máy trạng thái Mô thức ký hiệu - Máy trạng thái  Ví dụ: sơ đồ trạng thái của UML  Ví dụ: sơ đồ trạng thái của UML cho lớp Publication  Mô tả hành vi động của các đối tượng trong một lớp UML.  Có một cú pháp phong phú, bao gồm sự phân cấp trạng thái, sự đồng thời và giao tiếp giữa các máy. 29 30 Ths.Phan Phương Lan Ths.Phan Phương Lan Mô thức ký hiệu - Máy trạng thái Mô thức ký hiệu - Máy trạng thái  Ví dụ: mạng Petri cho mượn sách  Ví dụ: mạng Petri  Ký pháp dịch chuyển trạng thái được sử dụng để mô hình hóa các hoạt động đồng thời và sự tương tác của chúng.  Vòng tròn biểu diễn cho các hoạt động hay các điều kiện.  Thanh ngang/ dọc biểu diễn cho các dịch chuyển.  Cung nối kết một dịch chuyển với các hoạt động và điều kiện vào và ra của nó. Ths.Phan Phương Lan 31 Ths.Phan Phương Lan 32 8
Mô thức ký hiệu - Lưu đồ dòng Mô thức ký hiệu - Lưu đồ dòng dữ liệu dữ liệu  Lưu đồ dòng dữ liệu mô hình hóa chức năng và  Lược đồ thực thể quan hệ phân rã vấn đề theo các dòng dữ liệu từ chức năng này sang chức năng thực thể. khác.  Dò theo sự kiện phân rã vấn đề theo kịch bản.  Hình elip biểu diễn cho quy trình hay chức năng: biến đổi dữ liệu  Máy trạng thái phân rã vấn đề theo trạng thái điều  Mũi tên biểu diễn cho dòng dữ liệu (vào hay ra của chức khiển. năng).  Cả ba chỉ mô tả các hành vi mức thấp => rất khó  Hai đường song song biểu diễn cho kho dữ liệu: lưu giữ nhìn thấy chức năng mức cao của mô hình. các dữ liệu.  Hình chữ nhật biểu diễn cho các tác nhân: các thực thể cung cấp dữ liệu vào và nhận kết quả kết xuất. 33 34 Ths.Phan Phương Lan Ths.Phan Phương Lan Mô thức ký hiệu - Lưu đồ dòng Mô thức ký hiệu - Lưu đồ dòng dữ liệu dữ liệu  Lưu đồ dòng dữ liệu mức cao biểu diễn cho bài toán thư  Thuận lợi: viện  Cung cấp một mô hình trực quan về chức năng mức cao của hệ thống được đề nghị và của các phụ thuộc dữ liệu giữa các quy trình khác nhau.  Khó khăn :  Có thể làm tăng tính mơ hồ đối với nhà phát triển phần mềm, người chưa quen với vấn đề đang được mô hình hóa. 35 36 Ths.Phan Phương Lan Ths.Phan Phương Lan 9
Mô thức ký hiệu - Lưu đồ dòng Mô thức ký hiệu - Lưu đồ dòng dữ liệu dữ liệu  Ví dụ: sơ đồ use case của UML  Ví dụ sơ đồ use case của UML: một số use case của thư viện  Các thành phần  Đường biên của hệ thống (được ký hiệu bởi hình chữ nhật)  Tác nhân (được ký hiệu bởi hình người hay >)  Trường hợp sử dụng – use case - (được ký hiệu bằng hình oval). Một use case biểu diễn một chức năng được yêu cầu nào đó và biến thể của nó  Quan hệ giữa tác nhân và use case hay giữa các use case (được biểu diễn bằng các đường hay đường nét đứt) 37 38 Ths.Phan Phương Lan Ths.Phan Phương Lan Mô thức ký hiệu – Logic, Đặc tả Mô thức ký hiệu – Hàm và quan hệ đại số  Phương thức hay cách tiếp cận hình thức: các kỹ  Logic thuật thiết kế và đặc tả dựa vào toán học.  Một logic bao gồm một ngôn ngữ diễn tả các thuộc tính  Phương thức hình thức mô hình hóa các yêu cầu hay và một tập các quy tắc suy luận ra các thuộc tính kết hoạt động phần mềm như một tập các hàm hay quan hệ quả, mới từ những thuộc tính đã có.  Ví dụ: ngôn ngữ đặc tả yêu cầu hình thức Z toán học, chúng ánh xạ từ đầu vào của hệ thống tới đầu ra của hệ thống.  Đặc tả đại số  Hàm: xác định trạng thái của sự thực thi của hệ thống, và  Xác định hành vi của các phép toán bằng cách xác các kết xuất. d9inh6 sự tương tác giữa các cặp phép toán thay vì mô hình hóa các phép toán riêng lẻ.  Quan hệ: được sử dụng khi 1 giá trị nhập ánh xạ tới nhiều  Khó có thể định nghĩa được tập các tiên đề mà nó là hơn 1 giá trị xuất. hoàn chỉnh, nhất quán và phản ánh hành vi mong muốn.  Ví dụ: bảng quyết định  Ví dụ: SDL Data 39 40 Ths.Phan Phương Lan Ths.Phan Phương Lan 10
Các ngôn ngữ đặc tả và yêu cầu Các ngôn ngữ đặc tả và yêu cầu  Ngôn ngữ mô hình hóa hợp nhất (Unified Modeling  UML (Unified Modeling Language) Language - UML)  Kết hợp nhiều sơ đồ ký hiệu.  Ngôn ngữ mô tả và đặc tả (Specification and  Các sơ đồ UML được sử dụng trong suốt sự định Description Language – SDL) nghĩa và đặc tả các yêu cầu.  Sơ đồ use case (Lưu đồ dòng dữ liệu mức cao)  Sơ đồ lớp (Lưu đồ thực thể quan hệ)  Sơ đồ tuần tự (Dò theo sự kiện)  Sơ đồ cộng tác (Dò theo sự kiện)  Sơ đồ trạng thái (Mô hình trạng thái máy) 41 42 Ths.Phan Phương Lan Ths.Phan Phương Lan Các ngôn ngữ đặc tả và yêu cầu Lập bản mẫu cho các yêu cầu  Ngôn ngữ mô tả và đặc tả (SDL)  Xây dựng bản mẫu  Xác định hành vi của các quy trình phân tán, đồng thời và  Để thu thập các chi tiết của hệ thống được đề nghị thời gian thực mà chúng giao tiếp với nhau thông qua các hàng đợi thông điệp không giới hạn.  Để cố gắng lấy được thông tin phản hồi từ người dùng tiềm năng về:  Bao gồm:  Những khía cạnh mà họ muốn cải tiến.  Sơ đồ hệ thống SDL (Lưu đồ dòng dữ liệu)  Những đặc tính là không quá hữu ích.  Sơ đồ khối SDL (Lưu đồ dòng dữ liệu)  Chức năng đang thiếu.  Sơ đồ quy trình SDL (Mô hình máy trạng thái)  Giúp xác định xem vấn đề của khách hàng có giải pháp  Kiểu dữ liệu SDL (Đặc tả đại số) khả thi hay không.  Thường được đi kèm bởi một tập sơ đồ tuần tự của thông  Hỗ trợ trong việc thăm dò các chọn lựa để tối ưu hóa các điệp. yêu cầu về chất lượng. 43 44 Ths.Phan Phương Lan Ths.Phan Phương Lan 11
Lập bản mẫu cho các yêu cầu Lập bản mẫu cho các yêu cầu  Các cách tiếp cận để làm bản mẫu  Cách tiếp cận được làm ra để sử dụng một lần duy nhất  Sự khác nhau giữa lập bản mẫu và mô hình hóa (throwaway prototype)  Lập bản mẫu  Được phát triển để nghiên cứu thêm về vấn đề hay giải  Tốt khi trả lời những câu hỏi về giao diện pháp được đề nghị , và không bao giờ được xem là một phần của phần mềm được phân phối. người dùng.  Cách tiếp cận tiến hóa (evolutionary prototype)  Mô hình hóa  Được phát triển không chỉ giúp chúng ta trả lời các câu  Trả lời nhanh các câu hỏi về các ràng buộc hỏi mà còn được kết hợp vào sản phẩm cuối cùng. theo thứ tự mà theo đó các sự kiện nên xuất  Bản mẫu cuối cùng phải biểu thị các yêu cầu về chất lượng của sản phẩm cuối. hiện, về sự đồng bộ của các hoạt động.  Cả hai kỹ thuật này đôi khi được gọi là làm bản mẫu nhanh. 45 46 Ths.Phan Phương Lan Ths.Phan Phương Lan Tài liệu yêu cầu Tài liệu yêu cầu  Các loại tài liệu yêu cầu  Định nghĩa các yêu cầu - Các bước của quy trình  Định nghĩa các yêu cầu: một danh sách hoàn chỉnh về  Phác thảo mục đích chung và phạm vi của hệ thống, bao gồm những thứ mà khách hàng muốn đạt được các lợi ích liên quan, các mục tiêu và mục đích.  Mô tả các thực thể trong môi trường nơi hệ thống sẽ được  Mô tả nền tảng và nhân tố cơ bản ẩn sau sự đề xuất cho hệ cài đặt (các thực thể trong thế giới thực của khách hàng). thống mới.  Mô tả các phép biến đổi hay các ràng buộc lên các thực thể  Mô tả các đặc trưng cần thiết của một giải pháp có thể chấp đó. nhận được.  Đặc tả các yêu cầu: diễn tả lại các yêu cầu như một đặc  Mô tả môi trường trong đó hệ thống sẽ vận hành. tả về cách mà hệ thống được đề nghị sẽ hoạt động  Chỉ tham khảo tới các thực thể mà hệ thống có thể truy  Phác thảo sự mô tả về đề xuất, nếu khách hàng có một đề xuất chúng qua giao diện của hệ thống (chỉ các thực thể xuất cho giải quyết vấn đề. trong thế giới thực mà chúng có trong hệ thống được đề  Liệt kê bất cứ giả định nào về cách mà môi trường hoạt nghị). động. 47 48 Ths.Phan Phương Lan Ths.Phan Phương Lan 12
Tài liệu yêu cầu Tài liệu yêu cầu  Đặc tả các yêu cầu - Các bước của quy trình  Mô tả chi tiết tất cả các đầu vào, đầu ra, bao gồm:  Chuẩn IEEE cho đặc tả các yêu cầu phần mềm 1.Introduction to the Document  Các nguồn của đầu vào 1.1 Purpose of the Product  Các đích của đầu ra 1.2 Scope of the Product  Các miền giá trị 1.3 Acronyms, Abbreviations, Definitions  Định dạng dữ liệu cho dữ liệu vào/ra 1.4 References  Các giao thức của dữ liệu 1.5 Outline of the rest of the SRS 2.General Description of Product  Tổ chức và định dạng của cửa sổ 2.1 Context of Product  Ràng buộc thời gian 2.2 Product Functions  Diễn đạt lại chức năng được yêu cầu dưới dạng các đầu 2.3 User Characteristics vào/ra của giao diện. 2.4 Constraints  Đưa ra tiêu chuẩn phù hợp cho từng yêu cầu về chất lượng 2.5 Assumptions and Dependencies của khách hàng. 49 50 Ths.Phan Phương Lan Ths.Phan Phương Lan Tài liệu yêu cầu Thẩm tra và công nhận hợp lệ 3. Specific Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces  Công nhận hợp lệ (xác nhận, validation) của các 3.1.2 Hardware Interfaces yêu cầu: ta kiểm tra xem định nghĩa các yêu cầu có 3.1.3 Software Interfaces 3.1.4 Communications Interfaces phản ánh chính xác nhu cầu của khách hàng. 3.2 Functional Requirements  Thẩm tra (verification) các yêu cầu: ta kiểm tra 3.2.1 Class 1 3.2.2 Class 2 xem một tài liệu được tạo ra có tuân theo tài liệu … khác. Tại mức yêu cầu, ta kiểm tra xem đặc tả yêu 3.3 Performance Requirements cầu có phù hợp với định nghĩa yêu cầu. 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4. Appendices 51 52 Ths.Phan Phương Lan Ths.Phan Phương Lan 13
Thẩm tra và công nhận hợp lệ Thẩm tra và công nhận hợp lệ  Các kỹ thuật công nhận hợp lệ  Thẩm tra  Kiểm tra xem tài liệu đặc tả các yêu cầu có tương đương với định nghĩa các yêu cầu.  Đảm bảo rằng nếu ta thực hiện một hệ thống mà nó đáp ứng sự đặc tả thì hệ thống sẽ đáp ứng các yêu cầu của khách hàng.  Đảm bảo rằng mỗi yêu cầu trong tài liệu định nghĩa là có thể theo vết trong đặc tả. 53 54 Ths.Phan Phương Lan Ths.Phan Phương Lan Thẩm tra và công nhận hợp lệ TIẾN TRÌNH  Các kỹ thuật thẩm tra PHẦN MỀM PHẦN II.2 – THIẾT KẾ 55 56 Ths.Phan Phương Lan Ths.Phan Phương Lan 14
Định nghĩa về thiết kế Nội dung  Định nghĩa về thiết kế  Thiết kế là quá trình sáng tạo thực hiện việc chuyển  Các nội dung thiết kế đổi vấn đề thành giải pháp.  Một số vấn đề trong thiết kế  Sự mô tả của một giải pháp còn được biết như là  Đặc trưng của thiết kế hoàn thiện thiết kế.  Tài liệu thiết kế  Đặc tả các yêu cầu định nghĩa vấn đề.  Tài liệu thiết kế xác định một giải pháp cụ thể cho vấn đề. 57 58 Ths.Phan Phương Lan Ths.Phan Phương Lan Định nghĩa về thiết kế Định nghĩa về thiết kế  Thiết kế là một quá trình tương tác gồm hai phần:  Thiết kế mức quan niệm nói với khách hàng  Thiết kế mức quan niệm (thiết kế hệ thống) những cái mà hệ thống phải làm:  Thiết kế kỹ thuật  Dữ liệu đến từ đâu?  Điều gì sẽ xảy ra với dữ liệu trong hệ thống?  (Đối với người sử dụng) Hệ thống trông giống cái gì?  Những lựa chọn nào sẽ được cung cấp cho người dùng?  Các báo cáo và màn hình giống cái gì?  Định thời gian cho các sự kiện? 59 60 Ths.Phan Phương Lan Ths.Phan Phương Lan 15
Định nghĩa về thiết kế Định nghĩa về thiết kế  Thiết kế mức quan niệm  Thiết kế kỹ thuật nói với lập trình viên những cái Các đặc trưng của một thiết kế mức quan niệm mà hệ thống phải làm như: hoàn thiện:  Các thành phần phần cứng chính và chức năng của  Theo ngôn ngữ mà khách hàng có thể hiểu chúng.  Sự phân cấp và các chức năng của các thành phần  Không có các từ kỹ thuật phần mềm.  Mô tả các chức năng của hệ thống  Các cấu trúc dữ liệu và dòng dữ liệu.  Độc lập với sự cài đặt  Được liên kết với các yêu cầu 61 62 Ths.Phan Phương Lan Ths.Phan Phương Lan Định nghĩa về thiết kế Định nghĩa về thiết kế  Sự khác nhau trong tài liệu thiết kế  Thiết kế một hệ thống là xác định một tập các thành phần và các giao diện giữa các thành phần để đáp ứng tập các yêu cầu được đặc tả.  Những phương pháp tạo ra thiết kế  Phân rã theo mô đun  Phân rã hướng dữ liệu  Phân rã hướng sự kiện  Thiết kế trong ngoài  Thiết kế hướng đối tượng 63 64 Ths.Phan Phương Lan Ths.Phan Phương Lan 16
Định nghĩa về thiết kế Định nghĩa về thiết kế Sự phân rã Tính mô đun hóa  Mô tả dữ liệu hệ thống  Mô đun hay thành phần (component): các bộ phận  Mô tả chức năng mức hợp lại của thiết kế. cao  Một hệ thống là có tính mô đun khi  Tạo ra sự phân cấp thông  Mỗi hoạt động của hệ thống được thực hiện bởi chỉ một tin với các chi tiết tăng thành. dần  Đầu vào và đầu ra của mỗi thành phần là rành mạch  Tất cả các đầu vào là cần thiết cho chức năng của nó.  Tất cả các kết xuất được tạo ra bởi một trong các hoạt động của nó. Ths.Phan Phương Lan Các mức phân rã 65 Ths.Phan Phương Lan 66 Các nội dung thiết kế Thiết kế kiến trúc  Nhà thiết kế thực hiện các công việc:  Thiết kế kiến trúc  Thiết kế kiến trúc  Liên kết các thành phần của hệ thống với các  Thiết kế dữ liệu khả năng đã được xác định trong đặc tả yêu cầu.  Thiết kế giao diện  Một loại kiến trúc phần mềm liên quan tới các  Thiết kế thủ tục (thuật toán) thành phần, các liên kết và các ràng buộc trên các thành phần kết hợp. 67 68 Ths.Phan Phương Lan Ths.Phan Phương Lan 17
Thiết kế kiến trúc  Thiết kế kiến trúc Đường dẫn và bộ lọc  Các loại kiến trúc phần mềm Thiết kế kiến trúc - Ví dụ Phân lớp 69 70 Ths.Phan Phương Lan Ths.Phan Phương Lan Thiết kế dữ liệu Thiết kế dữ liệu – Ví dụ  Thiết kế dữ liệu  Các thành phần dữ liệu và bảng để tạo CSDL.  Các cấu trúc dữ liệu.  Các mức thiết kế dữ liệu  Thiết kế cấu trúc logic: các quan hệ chuẩn, các khóa, các tham chiếu, các cấu trúc thao tác dữ liệu.  Thiết kế cấu trúc vật lý: các file, các kiểu, kích thước. 71 72 Ths.Phan Phương Lan Ths.Phan Phương Lan 18
Thiết kế dữ liệu – Ví dụ Thiết kế giao diện  Thiết kế giao diện  Các form nhập liệu.  Các reports và những kết xuất mà hệ thống phải sinh ra. 73 74 Ths.Phan Phương Lan Ths.Phan Phương Lan Thiết kế giao Thiết kế thủ tục diện  Thiết kế thủ tục (thuật toán)  Giải thích quá trình xử lý từ input đến output.  Phương pháp biểu diễn  Lưu đồ giải thuật.  Ngôn ngữ giả. 75 76 Ths.Phan Phương Lan Ths.Phan Phương Lan 19
Một số vấn đề trong thiết kế Thiết kế thủ tục  Thiết kế cộng tác  Hầu hết các dự án làm việc cộng tác.  Các vấn đề trong thiết kế cộng tác  Ai là người phù hợp nhất để thiết kế từng bộ phận của hệ thống.  Viết tài liệu thiết kế như thế nào. Lưu đồ xử lý khi nhấn  Làm thế nào để kết hợp các thành phần thiết kế thành nút “Đăng nhập” một thiết kế hợp nhất.  Các vấn đề trong việc thực hiện thiết kế cộng tác  Sự khác nhau về kinh nghiệm cá nhân, sự hiểu biết, sở thích. 77 78 Ths.Phan Phương Lan Ths.Phan Phương Lan Một số vấn đề trong thiết kế Một số vấn đề trong thiết kế  Thiết kế giao diện  Một số lưu ý khi thiết kế giao diện  Các vấn đề then chốt được xem xét khi thiết kế giao diện:  Hạn chế nhập dữ liệu trực tiếp, nếu có thể, nên cho  Các vấn đề về văn hóa (quốc tịch, dân tộc, giới tính, người dùng chọn lựa từ một số dữ liệu có sẵn. nghề nghiệp, tuổi tác, vùng miền).  Yêu cầu xác nhận những tác vụ mang tính phá hủy  Sở thích của người dùng. (xoá dữ liệu).  Một số lưu ý khi thiết kế giao diện:  Chấp nhận lỗi từ phía người sử dụng.  Nên có sự đồng nhất giữa các giao diện (menu, lệnh, hiển thị...).  Nên cung cấp feedback cho người dùng.  Đặt tên nhãn ngắn gọn, dễ nhớ.  Tạo ra thông báo lỗi có ý nghĩa.  Tối ưu trong trình bày hộp thoại và di chuyển chuột.  Cung cấp trợ giúp. 79 80 Ths.Phan Phương Lan Ths.Phan Phương Lan 20