Bài giảng Nhập môn Công nghệ phần mềm: Tuần 5+6 - Nguyễn Thị Minh Tuyền

73 184 0
Bài giảng Nhập môn Công nghệ phần mềm: Tuần 5+6 - Nguyễn Thị Minh Tuyền

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Bài giảng Nhập môn Công nghệ phần mềm - Tuần 5+6: Yêu cầu phần mềm cung cấp cho người học các kiến thức: Yêu cầu chức năng và yêu cầu phi chức năng, đặc tả yêu cầu, các quy trình kỹ thuật về yêu cầu, thu thập và phân tích yêu cầu,... Mời các bạn cùng tham khảo.

Nhập môn Công nghệ phần mềm Tuần – 6: Yêu cầu phần mềm Nội dung slide dựa vào slide Ian Sommerville CuuDuongThanCong.com https://fb.com/tailieudientucntt Contents Yêu cầu chức yêu cầu phi chức Đặc tả yêu cầu Các quy trình kỹ thuật yêu cầu Thu thập phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu Tài liệu yêu cầu phần mềm NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Yêu cầu (requirement) gì? £ Có nhiều mức p Mơ tả trừu tượng mức cao dịch vụ hay ràng buộc hệ thống p Đặc tả chi tiết chức £ Có thể có hai chức khác p Cơ sở để thương lượng hợp đồng viết mức trừu tượng để sau diễn giải thêm; p Cơ sở để viết hợp đồng cần phải định nghĩa chi tiết; p Cả hai trường hợp gọi yêu cầu NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Requirements abstraction (Davis) £ “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not predefined The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will Both of these documents may be called the requirements document for the system.” CuuDuongThanCong.com https://fb.com/tailieudientucntt Các loại yêu cầu £ Yêu cầu người dùng (user requirement) p Những phát biểu (bằng ngôn ngữ tự nhiên kết hợp với biểu đồ) dịch vụ mà hệ thống cung cấp ràng buộc hoạt động p Viết cho khách hàng £ Yêu cầu hệ thống (system requirement) p Một tài liệu có cấu trúc mô tả chi tiết chức hệ thống, dịch vụ ràng buộc hoạt động hệ thống p Định nghĩa xác cần cài đặt Có thể phần hợp đồng khách hàng người nhận thầu NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Ví dụ User requirements definition The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month System requirements specification 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated 1.2 The system shall generate the report for printing after 17.30 on the last working day of the month 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs 1.4 If drugs are available in different dose units (e.g 10mg, 20mg, etc) separate reports shall be created for each dose unit 1.5 Access to drug cost reports shall be restricted to authorized users as listed on a management access control list NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Người đọc đặc tả yêu cầu User requirements Client managers System end-users Client engineers Contractor managers System architects System requirements System end-users Client engineers System architects Software developers NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt System stakeholders £ Là người tổ chức có ảnh hưởng đến hệ thống theo cách có quyền lợi hợp pháp £ Các loại stakeholder p p p p End users System managers System owners External stakeholders CuuDuongThanCong.com https://fb.com/tailieudientucntt Các stakeholder hệ thống Mentcare £ Bệnh nhân: thông tin họ lưu hệ thống £ Bác sĩ: người chịu trách nhiệm đánh giá tình hình bệnh chữa trị cho bệnh nhân £ Y tá: người phối hợp khám chữa bệnh với bác sĩ quản lý số điều trị £ Lễ tân y tế: người quản lý lịch hẹn bệnh nhân £ Đội ngũ IT: người chịu trách nhiệm cài đặt bảo trì hệ thống £ Quản lý đạo đức y tế: người đảm bảo hệ thống đáp ứng hướng dẫn mặt y đức cho việc chữa trị bệnh nhân £ Nhà quản lý chăm sóc sức khoẻ: người chịu trách nhiệm việc quản lý thông tin từ hệ thống £ Đội ngũ lưu trữ y tế: người chịu trách nhiệm việc đảm bảo cho thông tin hệ thống trì lưu trữ NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Stakeholder hệ thống ATM £ Khách hàng (người sử dụng dịch vụ) £ Đại diện ngân hàng khác (ATM ngân hàng dùng để giao dịch với ngân hàng khác) £ Quản lý ngân hàng (dùng thông tin quản lý từ hệ thống ATM) £ Nhân viên làm việc chi nhánh ngân hàng (vận hành hệ thống) £ Quản trị sở liệu (tích hợp hệ thống với CSDL ngân hàng) £ Quản lý an ninh £ Phòng marketing (muốn dùng ATM để quảng cáo) £ Kĩ sư IT bảo trì phần mềm phần cứng £ Những người điều phối hệ thống ngân hàng quốc gia (đảm bảo hệ thống tuân theo nguyên tắc chung) 10 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Kỹ thuật thẩm định yêu cầu £ Duyệt yêu cầu (Requirements reviews) p Phân tích cách có hệ thống u cầu (không dùng công cụ tự động) £ Phiên thử nghiệm (Prototyping) p Sử dụng mơ hình chạy hệ thống để kiểm tra yêu cầu £ Sinh test-case (test-case generation) p Phát triển test cho yêu cầu để kiểm tra khả test hay không 59 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Duyệt yêu cầu £ Nên duyệt yêu cầu thường xuyên trình định nghĩa yêu cầu hình thành £ Cả hai bên ký hợp đồng nên tham gia duyệt yêu cầu £ Việc duyệt yêu cầu mang tính hình thức (với tài liệu hồn chỉnh) khơng mang tính hình thức Giao tiếp tốt người phát triển, khách hàng người dùng giải vấn đề từ đầu 60 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Kiểm tra duyệt u cầu £ Tính kiểm định (Verifiability) p Trên thực tế, có test yêu cầu khơng? £ Tính dễ hiểu (Comprehensibility) p u cầu hiểu khơng? £ Tính lần vết (Traceability) p Nguồn gốc yêu cầu có rõ khơng? £ Tính thích ứng (Adaptability) p Có thể thay đổi yêu cầu mà không làm ảnh hưởng đến yêu cầu khác không? 61 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Contents Yêu cầu chức yêu cầu phi chức Đặc tả yêu cầu Các quy trình kỹ thuật yêu cầu Thu thập phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu Tài liệu yêu cầu phần mềm NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Vì yêu cầu thay đổi? £ Môi trường doanh nghiệp kỹ thuật hệ thống luôn thay đổi trình phát triển hệ thống sau đưa hệ thống vào sử dụng £ Người chi trả cho hệ thống người dùng hệ thống £ Những hệ thống lớn thường có cộng đồng người dùng đa dạng 63 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Cải tiến yêu cầu Hiểu biết ban đầu vấn đề Các yêu cầu ban đầu Thay đổi hiểu biết vấn đề Các yêu cầu thay đổi 64 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Quản trị yêu cầu £ Là quy trình quản trị thay đổi yêu cầu suốt trình công nghệ yêu cầu phát triển hệ thống £ Các yêu cầu phát sinh hệ thống phát triển đưa vào sử dụng £ Cần theo dõi yêu cầu đơn lẻ trì mối liên hệ yêu cầu phụ thuộc £ Cần thiết lập quy trình hình thức cho đề nghị thay đổi tạo mối liên hệ yêu cầu với yêu cầu hệ thống 65 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Kế hoạch quản lý yêu cầu £ Thiết lập mức độ chi tiết quản lý yêu cầu £ Cần lập kế hoạch : p Định danh yêu cầu : Mỗi yêu cầu phải đánh số để tham chiếu từ yêu cầu khác p Một quy trình quản lý thay đổi : Đây tập hoạt động để đánh giá mức độ ảnh hưởng chi phí thay đổi p Các sách lần vết : định nghĩa mối quan hệ yêu cầu yêu cầu với thiết kế hệ thống p Công cụ hỗ trợ : Sử dụng công cụ hỗ trợ cho công việc quản lý thay đổi yêu cầu 66 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Quy trình quản lý thay đổi yêu cầu Vấn đề nhận diện Phân tích vấn đề đặc tả thay đổi Để kiểm tra tính hợp lệ yêu cầu cần thay đổi Để trả lời người đưa yêu cầu cho việc thay đổi: định xem nên chấp nhận thay đổi hay nên định hủy bỏ yêu cầu thay đổi Phân tích ước lượng chi phí thay đổi Dùng thông tin lần vết kiến thức tổng quát yêu cầu hệ thống để đánh giá hiệu ứng thay đổi Khi hoàn thành phân tích này: đưa định nên tiến hành thay đổi yêu cầu hay không Cài đặt thay đổi Các yêu cầu duyệt Sửa tài liệu yêu cầu tài liệu cài đặt thiết kế hệ thống cần Lý tưởng: tài liệu nên tổ chức cho việc thay đổi cài đặt dễ dàng 67 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Contents Yêu cầu chức yêu cầu phi chức Đặc tả yêu cầu Các quy trình kỹ thuật yêu cầu Thu thập phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu Tài liệu yêu cầu phần mềm NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Tài liệu yêu cầu phần mềm £ Tài liệu yêu cầu phần mềm phát biểu thức mà người phát triển hệ thống phải cài đặt £ Nên bao gồm định nghĩa yêu cầu người dùng đặc tả yêu cầu hệ thống £ Đây tài liệu thiết kế, nên định nghĩa hệ thống hỗ trợ vào chi tiết việc phải cài đặt 69 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Ai sử dụng tài liệu yêu cầu? System customers Specify the requirements and read them to check that they meet their needs Customers specify changes to the requirements Managers Use the requirements document to plan a bid for the system and to plan the system development process System engineers Use the requirements to understand what system is to be developed System test engineers Use the requirements to develop validation tests for the system System maintenance engineers Use the requirements to understand the system and the relationships between its parts 70 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Tài liệu yêu cầu £ Thông tin tài liệu yêu cầu phụ thuộc vào loại hệ thống phương pháp phát triển sử dụng £ Hệ thống phát triển thường chứa chi tiết tài liệu yêu cầu £ Các chuẩn tài liệu yêu cầu thiết kế sẵn, ví dụ chuẩn IEEE Các chuẩn áp dụng cho dự án công nghệ hệ thống lớn 71 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Cấu trúc tài liệu yêu cầu Chapter Description Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version Introduction This should describe the need for the system It should briefly describe the system’s functions and explain how it will work with other systems It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software Glossary This should define the technical terms used in the document You should not make assumptions about the experience or expertise of the reader User requirements definition Here, you describe the services provided for the user The nonfunctional system requirements should also be described in this section This description may use natural language, diagrams, or other notations that are understandable to customers Product and process standards that must be followed should be specified System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules Architectural components that are reused should be highlighted 72 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt Cấu trúc tài liệu yêu cầu Chapter Description System requirements specification This should describe the functional and nonfunctional requirements in more detail If necessary, further detail may also be added to the nonfunctional requirements Interfaces to other systems may be defined System models This might include graphical system models showing the relationships between the system components and the system and its environment Examples of possible models are object models, data-flow models, or semantic data models System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions Hardware requirements define the minimal and optimal configurations for the system Database requirements define the logical organization of the data used by the system and the relationships between data Index Several indexes to the document may be included As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on CuuDuongThanCong.com https://fb.com/tailieudientucntt 73 ... quảng cáo) £ Kĩ sư IT bảo trì phần mềm phần cứng £ Những người điều phối hệ thống ngân hàng quốc gia (đảm bảo hệ thống tuân theo nguyên tắc chung) 10 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt... phi chức Đặc tả u cầu Các quy trình cơng nghệ u cầu Thu thập phân tích yêu cầu Thẩm định yêu cầu Quản trị yêu cầu Tài liệu yêu cầu phần mềm NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt... nghĩa (Một lộ trình tự kiểm tra tìm lỗi phần cứng phần mềm báo cho người sử dụng biết hệ thống khơng thể hoạt động bình thường được) 30 NGUYỄN Thị Minh Tuyền CuuDuongThanCong.com https://fb.com/tailieudientucntt

Ngày đăng: 11/01/2020, 18:38

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan