Nhập môn Công nghệ Phần mềm (Introduction to Software Engineering) CHƯƠNG 6 Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) Mục tiêu của bài học Sinh viên sẽ được trang bị các kiến thức sau: - Hiểu rõ các khái niệm liên quan tới kĩ nghệ yêu cầu phần mềm - Biết, nắm vững vị trí, vai trò của kĩ nghệ YCPM - Có khái niệm về một số yếu tố liên quan tới các yêu cầu chức năng và phi chức năng - Nắm vững các hoạt động chính của kĩ nghệ YCPM Nội dung 1. Tầm quan trọng của yêu cầu phần mềm 3. Yêu cầu chức năng và yêu cầu phi chức năng 4. Các hoạt động chính trong kỹ nghệ yêu cầu phần mềm 5 1.
Khái niệm (1) • Các đặc tính của hệ thống hay sản phẩm do khách hàng - người sử dụng PM - đặt ra → Xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng - người sử dụng phần mềm Bài toán của khách Lĩnh vực ứng dụng hàng cần giải quyết của hệ thống/sản phẩm Nhu cầu và ràng buộc Ngữ cảnh nghiệp vụ: tương tác của những người có của hệ thông/sản phẩm và đóng quyền lợi và nghĩa vụ góp về mặc nghiệp vụ của hệ liên quan đến hệ thống thống /sản phẩm 6 1. Khái niệm (2) • Khởi đầu (Inception): Hỏi một loạt các câu hỏi để xác định: • Hiểu biết căn bản về vấn đề cần giải quyết. • Người đang cần giải pháp • Loại giải pháp mong muốn • Mức độ hiệu quả ban đầu của việc trao đổi thông tin giữa khách hàng và nhà phát triển • Khám phá (Elicitation): tìm ra yêu cầu của tất cả khách hàng. • Xây dựng (Elaboration): tạo ra mô hình phân tích xác định dữ liệu, chức năng và hành vi được yêu cầu.
• Đàm phán (Negotiation): đồng ý với một hệ thống có thể bàn giao một cách thực tế đối với cả 2 bên. Khái niệm (3) • Đặc tả (Specification): có thể là một/ nhiều những thứ sau: • Một Tài liệu được viết • Một Tập hợp các mô hình • Một hình thức biểu diễn toán học • Một tập các kịch bản người dùng ( use-case ) • Một Nguyên mẫu • Đánh giá (Validation): tạo cơ chế xem xét các vấn đề: • Sai sót trong nội dung hoặc giải thích. • Phần được yêu cầu làm rõ. • Thông tin bị thiếu • Mâu thuẫn • Yêu cầu không thực tế, không thể đạt được.
• Quản lý các Yêu cầu (Requirements management) 8 Nội dung 1. Tầm quan trọng của yêu cầu phần mềm 3. Yêu cầu chức năng và yêu cầu phi chức năng 4. Các hoạt động chính trong kỹ nghệ yêu cầu phần mềm 9 Nguồn gốc yêu cầu phần mềm ❑Người sử dụng (Khách hàng): theo mô hình phân lớp của yêu cầu phần mềm Khách hàng được chia làm hai loại: • Khách hàng cung cấp các business requirement: cung cấp các thông tin về công ty, về các đặc điểm ở mức độ cao, về mô hình và phạm vi của hệ thống • Khách hàng cung cấp các user requirement: cung cấp các công tin về từng nhiệm vụ cụ thể mà họ sẽ làm việc với phần mềm ❑Cần phải phối hợp, kết hợp chặt chẽ với hai phân loại khách hàng trên Đặc điểm của khách hàng phần mềm • Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ.
• Cho nên chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết” • Khách hàng rất hay thay đổi các đòi hỏi của mình, chúng ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý 11 Vấn đề YCPM giải quyết (1) ❑Sự tham gia quá mức của NSD ✓ Thông thường người sử dụng không hiểu rõ về quá trình xây dựng các yêu cầu phần mềm và các đặc điểm của phần mềm. ✓ Họ sẽ đưa những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm như viết code,. ✓ Họ đưa ra những yêu cầu và đề nghị rất khó chấp nhận và gây khó khăn cho các PTV ❑Có quá nhiều yêu cầu trong yêu cầu phần mềm ✓ Thông thường các yêu cầu phần mềm được phát hiện trong quá trình khảo sát và rất có thể các yêu cầu về phần mềm sẽ lớn hơn khả năng của đội ngũ phát triển về: nhân lực, thời gian, tài chính. ✓ Cần hạn chế không để các yêu cầu phần mềm phát sinh đi quá phạm vi và giới hạn của phần mềm ✓ Cần quản lý các thay đổi về yêu cầu phần mềm một cách hợp lý và xem xét ảnh hưởng của nó tới kiến trúc hệ thống, … trong quá trình phát triển Vấn đề YCPM giải quyết (2) ❑Các yêu cầu phần mềm mơ hồ nhập nhằng ✓ Đây là một vấn đề rất hay xảy ra trong quá trình phát triển các yêu cầu phần mềm ✓ Các yêu cầu phần mềm cần phải rõ ràng, không được phép hiểu theo nhiều cách ✓ Phương pháp sửa các yêu cầu mơ hồ nhập nhằng là làm lại, đặc tả lại các yêu cầu này.
✓ Theo đánh giá của các nhà phân tích: làm lại yêu cầu phần mềm thường chiếm khoảng 40% quá trình xây dựng nó và 70-80% các đặc tính xây dựng lại có thể dẫn đến các lỗi ✓ Lưu ý tới từng yêu cầu phần mềm và không để sót những yêu cầu mơ hồ, không rõ ràng ❑Không lưu ý tới người sử dụng phần mềm ✓ Thông thường phần mềm làm ra cho một tập hợp các đôi tượng nào đó sử dụng ✓ Cần quan tâm tới đặc điểm của đối tượng này Vấn đề YCPM giải quyết (3) ❑Các đặc tính thừa: ✓ Thông thường người phát triển theo các thói quen nghề nghiệp thêm vào các yêu cầu phần mềm các chức năng không cần thiết cho phần mềm ✓ Tương tự như vậy người sử dụng có thể đưa ra một số yêu cầu phụ cho phần mềm. Các yêu cầu này có thể đòi hỏi các tốn kém về mặt xây dựng mà trên thực tế hoàn toàn không cần thiết ✓ Cần đánh giá các đặc tính và tính cần thiết của nó đối với các phần mềm. Những đặc tính phụ có thể xem xét kỹ hơn xem khả năng đáp ứng nó về mặt kỹ thuật có đáng giá hay không. ❑Đặc tả quá ít ✓ NSD là chuyên viên trong một lĩnh vực nào đó có thói quen nghĩ rằng tất cả các LTV đều là các chuyên viên trong lĩnh vực đó.
✓ NSD đưa ra những yêu cầu quá ngắn gọn mà không miêu tả kỹ lưỡng chúng là gì ✓ Cần hỏi rõ NSD và tranh thủ các kiến thức của họ Vấn đề YCPM giải quyết (4) ❑Kế hoạch sai: ✓Các LTV đánh giá sai về mức độ phức tạp của vấn đề và dẫn tới lập kế hoạch sai về mặt thời gian hoàn thành. ✓Cần lưu ý đánh giá thật chắc chắn các đặc tính của phần mềm khi lập kế hoạch xây dựng phần mềm ✓Nên trả lời cho khách hàng các câu trả lời dạng “gần chính xác”: trong trường hợp xấu nhất…. Tầm quan trọng của yêu cầu phần mềm 3. Yêu cầu chức năng và yêu cầu phi chức năng 4.
Các hoạt động chính trong kỹ nghệ yêu cầu phần mềm 16 Phân loại yêu cầu • Theo 4 thành phần của phần mềm: • Các yêu cầu về phần mềm (Software) • Các yêu cầu về phần cứng (Hardware) • Các yêu cầu về dữ liệu (Data) • Các yêu cầu về con người (People, Users) • Theo cách đặc tả phần mềm • Các yêu cầu chức năng • Các yêu cầu ngoài chức năng • Các ràng buộc khác 17 Yêu cầu chức năng • Miêu tả các chức năng của hệ thống, phụ thuộc vào kiểu phần mềm và mong đợi của người dùng • Tương tác giữa phần mềm và môi trường, độc lập với việc cài đặt • Ví dụ: Hệ thống đồng hồ phải hiển thị thời gian dựa trên vị trí của nó • Các công cụ đặc tả yêu cầu chức năng tiêu biểu: • Biểu đồ luồng dữ liệu (Data Flow Diagrams) • Máy trạng thái hữu hạn (Finite State Machines) • Mạng Petri (Petri nets),… • Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự nhiên. 18 Yêu cầu phi chức năng và ràng buộc • Yêu cầu phi chức năng: Định nghĩa các khía cạnh sử dụng phần mềm, không liên quan trực tiếp tới các hành vi chức năng: • Các tính chất của hệ thống như độ tin cậy, thời gian trả lời, dung lượng bộ nhớ, … • Thời gian trả lời phải nhỏ hơn 1 giây • Ràng buộc: do khách hàng hay môi trường thực thi phần mềm đặt ra • Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành, chuẩn tài liệu, … • Ngôn ngữ cài đặt phải là COBOL • Các yêu cầu từ bên ngoài • Phải giao tiếp với hệ thống điều phối được viết vào năm 1956. • Thường sử dụng các công cụ • Biểu đồ thực thể liên kết (Entity-Relationship Diagrams) • Đặc tả Logic (Logic Specifications) • Đặc tả đại số (Algebraic Specifications) → Khó phát biểu chính xác, Rất khó kiểm tra 19 Nội dung 1. Tầm quan trọng của yêu cầu phần mềm 3.
Yêu cầu chức năng và yêu cầu phi chức năng 4. Các hoạt động chính trong kỹ nghệ yêu cầu phần mềm 20 4. Các hoạt động chính trong kỹ nghệ YCPM • Phát hiện các yêu cầu phần mềm (Requirements elicitation) • Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation) • Đặc tả các yêu cầu phần mềm (Requirements specification) • Mô hình hóa hệ thống (System modeling) • Kiểm tra tính hợp lý của các yêu cầu phần mềm (Requirements validation) • Quản trị các yêu cầu phần mềm (Requirements management) 21 4. Các hoạt động chính (tiếp) Xây dựng một nguyên mẫu (prototype) Xác định Phát triển Xem Vấn đề yêu cầu đặc điểm kỹ thuật duyệt Tạo ra mô hình phân tích Last Update8-07 Dept.
of SE, 2002 SE-III. Phát hiện yêu cầu phần mềm • Đánh giá tính khả thi về kỹ thuật và nghiệp vụ của phần mềm định phát triển • Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp chúng ta xác định yêu cầu phần mềm • Xác định môi trường kỹ thuật trong đó sẽ triển khai phần mềm • Xác định các ràng buộc về lĩnh vực ứng dụng của phần mềm (giới hạn về chức năng/hiệu năng phần mềm) 23 4a.Phát hiện yêu cầu phần mềm (tiếp) • Xác định các phương pháp sử dụng để phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.