Nội dung

Phân tích yêu cầu phần mềm Bài tập tuần 1 Giảng viên: PGS.TS. Huỳnh Quyết Thắng Danh sách sinh viên: Lê Trung Hiếu Đàm Văn Hoài Nguyễn Đức Cương Đoàn Văn Đạt 20111568 20111600 20111203 20111370 CNTT-TT 2.3 K56 CNTT-TT 2.3 K56 CNTT-TT 2.3 K56 CNTT-TT 2.3 K56 Bài I Các hướng tiếp cận  Process-Oriented  Data-Oriented  Architecture-Oriented  Điểm mạnh, điểm yếu của các phương pháp tiếp cận 1. Process-Oriented Approach  Bản chất:phân tích và thiêt kế đặt trọng tâm vào các chức năng do phần mềm thực hiện. • Tập trung vào các giải thuật và thao tác xử lý dữ liệu • Quá trình phát triển phần mềm tập trung vào thể hiện các phương pháp xử lý dữ liệu • Cấu trúc dữ liệu thông thường không thể hiện rõ Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 3 2. Data-Oriented Approach  Dữ liệu không thay đổi bởi các yêu cầu hay đòi hỏi của người dùng về các thao tác nghiệp vụ.  Trong thiết kế hướng dữ liệu, hệ thống được thiết kế dựa trên cấu trúc tiến trình dữ liệu.  Việc phân tích thiết kế được tiến hành cho dữ liệu một cách tách bạch với yêu cầu hay đòi hỏi của người dùng về thao tác. Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 4 2. Data-Oriented Approach Nghiên cứu và phát triển cơ sở dữ liệu tập trung vào các thực thể và các mối quan hệ giữa các thực thể. Mô tả tổ chức của dữ liệu ,mô tả dữ liệu lấy ra ở đâu và sử dụng như thế nào Mô hình dữ liệu được thành lập và được mô tả mối quan hệ giữa các dữ liệu tương ứng này và các quy định về mối quan hệ. Sử dụng các Business rules để chỉ ra phương pháp xử lí dữ liệu. Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 5 3. Architecture-Oriented Approach  Là phương pháp phân tích và thiết kế có cấu trúc. • Các yêu cầu của hệ thống đích được phát triển được phân tích bằng việc đặc biệt chú ý tới chức năng của hệ thống và luồng dữ liệu giữa các chức năng. • Mục đích của phương pháp này là chuyển các tiến trình trong biểu đồ thành các modules chương trình và tiến hành phân chia các modules bằng cách tiếp cận từ trên xuống. Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 6 3. Architecture-Oriented Approach • Lựa chọn kiến trúc và công nghệ phần mềm để thực hiện bài toán. • Áp dụng các phương pháp Prototyping để nhanh chóng xây dựng được phần mềm. • Sử dụng các Pattern kiến trúc mẫu để chỉ ra phương pháp xử lý dữ liệu Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 7 4. Điểm mạnh, điểm yếu của các phương pháp tiếp cận Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 8 4.1 Process-Oriented Approach Điểm mạnh: • Thích hợp với các bài toán phức tạp. • Giảm thời gian đáp ứng của phần mềm do tập trung vào giải thuật và xử lí dữ liệu • Tránh được sự trùng lặp trong cơ sở dữ liệu  Điểm yếu: • Khó điều chỉnh các yêu cầu cho nhiều người dùng. • Sử dụng các chức năng chồng chéo nhau là khó tránh khỏi. Kết quả là hệ thống có nhiều chức năng chồng chéo nhau là một trong những nhân tố làm cho việc bảo trì trở nên khó khăn. • Các tệp dữ liệu được xây rất khó để thỏa mãn phần mềm Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 9 4.2 Data-Oriented Approach Điểm mạnh: • Thích hợp với hệ thống quản lí cơ sở dữ liệu. • Không phụ thuộc vào chức năng và yêu cầu người sử dụng do thiết kế dữ liệu tách bạch. • Biểu diễn đươc các mối quan hệ trong các bảng và giữa các dữ liệu với nhau Điểm yếu: • Việc xử lí dữ liệu không được linh hoạt do phụ thuộc vào các Business rules • Các chức năng của phần mềm phụ thuộc vào cách tổ chức cơ sở dữ liệu. Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 10 4.3 Architecture-Oriented Approach Điểm mạnh: • Việc thiết kế phần mềm nhanh do áp dụng các bản mẫu có sẵn. Từ đó thưa kế được những ưu điểm sẵn có. • Áp dụng các kiến trúc công nghệ tốt nhất tăng chất lượng phần mềm. Điểm yếu: • Dữ liệu được xử lí phụ thuộc cao vào các bản mẫu sẵn có Bị động trong thiết kế • Phụ thuộc vào công nghệ hiện tại Nhóm 3-Phân tích yêu cầu phần mềm 01/31/22 11 Bài II Software Development Life-Cycle  Mô hình thác nước  Mô hình sử dụng lại  Mô hình xoắn ốc  Mô hình tiến hóa  Mô hình Rational Unified Process Mô hình thác nước • Là một mô hình vòng đời phát triển phần mềm • Quy trình phát triển trông giống như một dòng chảy • Các pha được thực hiện theo trật tự nghiêm ngặt Mô hình thác nước Các giai đoạn: 1.Phân tích yêu cầu và tài liệu đặc tả (Requirements) 2.Phân tích hệ thống (Analysis) 3.Thiết kế (Design) 4.Lập trình (coding) 5.Kiểm thử (Testing) 6.Cài đặt và bảo trì (Acceptance) Mô hình thác nước Ưu điểm Nhược điểm • Đơn giản và dễ dàng để hiểu và sử dụng • Chuỗi các hoạt động được thực hiện theo quy trình rõ ràng. • Dễ phân công công việc, phân bố chi phí, giám sát công việc. • Thực tế các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có sự lặp lại. • Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu • Khách hàng phải có lòng kiên nhẫn chờ đợi thời gian nhất định mới có sản phẩm Mô hình sử dụng lại • Là một mô hình vòng đời phát triển phần mềm • Tái sử dụng thông tin được tạo ra trong các dự án phát triển phần mềm trước đó. • Việc sử dụng lại cho phép xây dựng hệ thống phần mềm mới với chất lượng và độ tin cậy cao hơn. Mô hình sử dụng lại Mô hình sử dụng lại Các giai đoạn: 1.Requirements specification ( Yêu cầu kỹ thuật) 2.Component analysis ( Phân tích thành phần ) 3.Requirements modification ( Sửa đổi) 4.System design with reuse ( Thiết kế hệ thống với các thành phần tái sử dụng) 5.Development and integration ( Phát triển) 6.System validation ( Xác nhận hệ thống ) Mô hình sử dụng lại Ưu điểm Nhược điểm • Giảm chi phí phát triển phần mềm • Tiết kiệm thời gian. • Giảm thiểu các sai sót, lỗi của sản phẩm cuối cùng so với phần mềm trước đó. • Việc sử dụng lại có thể không khả thi vì các thành phần tái sử dụng có thể không đầy đủ, cần phải thiết kế mới. • Có thể không đáp ứng được nhu cầu của khách hàng • Có thể không đáp ứng được nhu cầu của khách hàng Mô hình xoắn ốc • Là một mô hình vòng đời phát triển phần mềm (SDLC model) • Định hướng giải quyết rủi ro • Lặp (Iterative) • Tăng tiến (Incremental) • Chứa nhiều cải tiến so với mô hình thác nước Mô hình xoắn ốc • Mỗi chu kỳ xoắn ốc: – Lên kế hoạch – Phân tích rủi ro  Prototype – Thực hiện  Sản phẩm – Đánh giá Mô hình xoắn ốc Ưu điểm • Quản lý rủi ro tốt hơn • Đáp ứng cao các thay đổi • Ước toán dễ dàng hơn • Khách hàng hiểu rõ hệ thống mới hơn Nhược điểm • Ít hiệu quả với các dự án nhỏ • Tốn kém về tài chính,nhân lực • Thành công phụ thuộc nhiều vào phân tích rủi ro • Cần được thực hiện nghiêm ngặt, chặt chẽ Mô hình xoắn ốc • Áp dụng cho dự án: – Mức rủi ro từ mức trung bình trở lên – Dự án dài hạn có thể thay đổi lớn – Yêu cầu người dùng không chắc chắn – Yêu cầu quá phức tạp – Cần cho ra 1 dòng sản phẩm mới – Nghiên cứu, khám phá Mô hình tiến hóa • Ý tưởng: – Phát triển nhanh phiên bản đầu – Phản hồi khách hàng  Cải tiến – Lặp lại bước trên đến khi tương đối thỏa mãn yêu cầu người dùng – Phiên bản cuối  Khách hàng Mô hình tiến hóa Các bước triển khai mô hình tiến hóa Mô hình tiến hóa Ưu điểm • Tầm nhìn dài hạn  Các bước ngắn hạn • Mỗi vòng lặp đơn giản hơn • Sớm có nguyên mẫu sử dụng được  Nhanh chóng nhận được phản hồi khách hàng • Phần mềm dần hoàn thiện Nhược điểm • Không phù hợp các dự án nhỏ • Tăng độ phức tạp quản lý • Khó xác định phạm vi dự án • Tốn kém về mặt tài nguyên (tài chính và kỹ năng con người) Mô hình tiến hóa • Áp dụng cho dự án lớn mà: – Yêu cầu ban đầu không rõ ràng – Các yêu cầu chỉ xác định khi khách hàng có thực tiễn sử dụng – Cần có sản phẩm sớm – Có độ rủi ro do thay đổi cao Mô hình RUP (Rational Unified Process) • Là một mô hình SDLC: – Mang tính thích nghi – Lặp – Mỗi bước có các cột mốc yêu cầu rõ ràng Mô hình RUP với các cột mốc yêu cầu Mô hình RUP (Rational Unified Process) • Mô hình lặp của RUP gồm 4 pha. Bản thân mỗi pha là những vòng lặp khác nhau trong quá trình phát triển. Mô hình RUP (Rational Unified Process) Ưu điểm • Hiệu quả trong sử dụng tài nguyên • Thỏa mãn yêu cầu khách hàng • Phát hiện sớm các rủi ro • Cải thiện quản lý rủi ro • Hỗ trợ mô hình lặp • Thường xuyên nhận phản hồi từ các cổ đông Nhược điểm • Tiến trình phức tạp để thực hiện • Quá trình phát triển có thể vượt quá tầm kiểm soát • Tiến trình nặng • Cần nhiều chuyên gia Mô hình RUP (Rational Unified Process) • Được áp dụng rộng rãi nhờ tính thích nghi của nó Bài 3 • Tìm các KPA cơ bản của Requirement Engineering • Vẽ sơ đồ biểu diễn mối quan hệ này. • Mô tả ngắn gọn nội dung của từng KPA. Định nghĩa Requirement Engineering Requirement Engineering (quy trình yêu cầu phần mềm) là cơ chế thích hợp để hiểu khách hàng muốn gì, phân tích yêu cầu, đánh giá tính khả thi, đàm phán một giải pháp hợp lí, xác định giải pháp rõ ràng, xác nhận yêu cầu kĩ thuật và quản lí yêu cầu khi chúng được chuyển thành hệ thống hoạt động. Requirement Engineering Document: What system do?  Requirement Development (Phát triển yêu cầu) • + Requirement Elicitation (Phát hiện yêu cầu) • + Requirement Analysis (Phân tích yêu cầu) • + Requirement Specification (Đặc tả yêu cầu) • + Requirement Verification (Kiểm thử yêu cầu)  Requirement Management (Quản lí yêu cầu) Các KPA cơ bản của Requirement Engineering Sơ đồ mối quan hệ trong quá trình hoạt động của các KPA Làm việc vơi khách hàng Cập nhật Làm việc vơi khách hàng Các KPA Requirement Development (Phát triển yêu cầu) Phát triển yêu cầu là giai đoạn xác định các yêu cầu của khách hàng đối với hệ thống, sản phẩm cho ra là bản yêu cầu cơ sở. Các KPA Requirement Elicitation (Phát hiện yêu cầu) Phát hiện yêu cầu là quá trình thu thập và tài liệu hóa các nhu cầu của các bên liên quan, xác định các yêu cầu tài nguyên và thu thập các thông tin, tài liệu cần thiết khác. • Phỏng vấn khách hàng • Quan sát người dùng thực hiện công việc của họ • Nghiên cứu các kịch bản làm việc • Tổ chức các hội thảo • Kiểm tra các báo cáo vấn đề • Tái sử dụng yêu cầu Xác định các yêu cầu quá trình phát triển • Xác định tầm nhìn và phạm vi • Xác định các lớp người dùng • Xác định các tiêu chí sản phẩm • Xác định các trường hợp ca sử dụng • Xác định các sự kiện hệ thống và đáp ứng Các KPA Requirement Analysis (Phân tích yêu cầu)  Phân tích các dữ liệu thu được từ Phát hiện yêu cầu Giải quyết xung đột  Phân tích luật thương mại  Tài liệu hóa các giả định, ràng buộc và phụ thuộc, Làm việc với các bên liên quan để tạo lập các ưu tiên ban đầu. Các KPA Requirement Specification (Đặc tả yêu cầu) UML Các yêu cầu Mô hình hóa tiến trình Các văn bản chức năng & Xác định bổ trợ Các bảng khung v.v. Các KPA Các KPA Requirement Verification (Kiểm thử yêu cầu) Kiểm thử yêu cầu là quá trình xem xét lại các đặc tả yêu cầu và các minh họa trực quan đi kèm với các bên liên quan để xác định các thuộc tính chất lượng như sự hoàn thiện, sự phù hợp, sự rõ ràng, tính thực tiễn… • Kiểm tra các tài liệu yêu cầu • Kiểm tra các yêu cầu • Xác định các tiêu chí chấp nhận • Tạo mẫu thử • Kiểm tra sự chấp nhận • Đảm bảo các kĩ sư phần mềm hiểu rõ tất cả yêu cầu • Đảm bảo các yêu cầu đưa ra được khách hàng chấp nhận Các KPA Requirement Management (Quản lí yêu cầu) Xác định giới hạn của phần mềm (Requirement baseline) Duyệt lại các giới hạn của phần mềm Quản lý các thay đổi trong yêu cầu phần mềm (Requirement Changes) Các KPA Requirement Management (Quản lí yêu cầu)      Xác định một quá trình kiểm soát thay đổi yêu cầu Thành lập ban kiểm soát thay đổi Phân tích các tác động của sự thay đổi yêu cầu Thiết lập đường cơ sở kiểm soát các phiên bản yêu cầu Duy trì một lịch sử của yêu cầu thay đổi Cảm ơn thầy và các bạn đã lắng nghe