Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu
Tổng quan và đặc tả yêu cầu
Gồm các công đoạn:
Nghiên cứu tính khả thi
Phân tích mô hình
Đặc tả yêu cầu.
Được phối hợp giữa nhóm phát triển phần mềm và khách hàng
Yêu cầu của khách hàng được thu thập đầy đủ và chi tiết
Công cụ: các loại sơ đồ biểu diễn được các khái niệm và mô hình hóa được mối quan hệ giữa các đối tượng trong hệ thống.
Bao gồm các bước phân tích:
Phân tích phạm vi dự án
Phân tích mở rộng yêu cầu nghiệp vụ
Phân tích yêu cầu bảo mật
Phân tích yêu cầu tốc độ
Phân tích yêu cầu vận hành
Phân tích khả năng mở rộng yêu cầu
Phân tích yêu cầu sẵn dùng
Phân tích yếu tố con người
Phân tích yêu cầu tích hợp
Phân tích thực tiễn nghiệp vụ tồn tại
Phân tích yêu cầu khả năng và quy mô
Trang 1
Trang 2
Trang 3
Trang 4
Trang 5
Trang 6
Trang 7
Trang 8
Trang 9
Trang 10
Tải về để xem bản đầy đủ
Tóm tắt nội dung tài liệu: Bài giảng Công nghệ phần mềm - Phân tích và đặc tả yêu cầu
u của ng ư ời dùng. X ác định những kinh nghiệm sử dụng phần mềm của người dùng. 26 2.2.8. Phân tích yếu tố con ng ư ời Nếu nâng cấp từ một hệ thống cũ , yêu cầu chuyển đổi dữ liệu từ hệ thống cũ sang hệ thống mới thì cần phải có kế hoạch tích hợp từ công cụ có sẵn hoặc xây dựng các tiện ích chuyển đổi. Nếu nhu cầu l ư u trữ dữ liệu lớn thì có thể phải xây dựng lại CSDL dựa trên cấu trúc của CSDL hiện tại để tránh phá vỡ mã nguồn của CSDL hiện tại. 27 2.2.9. Phân tích yêu cầu tích hợp Phân tích thực tiễn nghiệp vụ giúp nhóm dự án h iểu được những nghiệp vụ của doanh nghiệp , xây dựng chức năng phần mềm chính xác h ơ n, tránh được sai sót. Hiểu được cấu trúc tổ chức và sơ đồ nghiệp vụ của doanh nghiệp là yếu tố quyết định sự thành công của bước phân tích yêu cầu và xây dựng phần mềm. Tìm hiểu những tiến trình, chính sách liên quan trên phần mềm mới 28 2.2.10. Phân tích thực tiễn nghiệp vụ Quy mô của phần mềm : là khả năng phục vụ ng ư ời dùng Để nâng cao khả năng phục vụ, là nâng cấp cơ sở hạ tầng (CPU nhanh, nhiều RAM,...) cả phía người dùng và phía hệ thống (máy chủ). Giải pháp khác là phát triển phần mềm phân tán để có thể hoạt động trên nhiều máy chủ cùng lúc, giúp kiểm soát và đáp ứng việc phân phối tài nguyên và thời gian xử lý. 29 2.2.11. Phân tích yêu cầu khả năng và quy mô Mục tiêu của việc xác định yêu cầu: X ác định chính xác và đầy đủ các yêu cầu của phần mềm sẽ được xây dựng. Kết quả của giai đoạn xác định yêu cầu : Danh sách các công việc (liên quan đến những chức năng của phần mềm) sẽ được thực hiện trên máy tính Những mô tả chi tiết về các công việc này khi được triển khai vận hành trong thế giới thực Thông tin khái quát về các hoạt động trong thế giới thực. 30 2.3 . Xác định yêu cầu Yêu cầu: Là công việc mà phần mềm phải thực hiện, xuất phát từ yêu cầu của khách hàng. Mô tả yêu cầu : M ô tả đầy đủ , rõ ràng và chi tiết các thông tin liên quan đến công việc tương ứng mà phần mềm phải thực hiện, mô tả này phải đ ư ợc nhóm phần mềm và khách hàng hiểu rõ và thống nhất . Bảng mô tả yêu cầu đ ư ợc dùng làm cơ sở để nghiệm thu và đánh giá phần mềm khi được chuyển giao. 31 2.3.1. Yêu cầu và mô tả yêu cầu Các thông tin trong bảng x ác định yêu cầu phần mềm T ên công việc ứng với từng yêu cầu : Cần xác định cụ thể, tránh dùng các tên chung chung, mơ hồ (như “Quản lý độc giả” là chung chung, nên cụ thể hơn như “Đăng ký mượn sách”, “Gia hạn thẻ độc giả”, “Trả sách”) X ác định chính xác người dùng : Những người dùng có vai trò và công việc tương tự nhau sẽ được xếp vào cùng loại . Cùng một công việc có thể có nhiều loại người dùng khác nhau; một loại người dùng có thể thực hiện nhiều công việc khác nhau. 32 2.3.1. Yêu cầu và mô tả yêu cầu Các thông tin trong bảng x ác định yêu cầu phần mềm X ác định chính xác địa điểm, thời điểm tiến hành công việc. Quy trình thực hiện công việc và các quy tắc liên quan , cần phải kiểm tra khi thực hiện công việc. Ví dụ: ch ư ơng trình quản lý th ư viện Chỉ cho những độc giả có thẻ độc giả còn hạn m ư ợn sách, số sách tối đa là 1 và không có sách m ư ợn quá hạn. M ỗi ngày trả trễ phạt 1500 đồng/ngày. Từ ngày trả trễ thứ 10 trở đi sẽ phạt 5000 đồng/ngày, thu hồi thẻ độc giả 2 tuần 33 2.3.1. Yêu cầu và mô tả yêu cầu 34 2.3.2. Phân loại yêu cầu Yêu cầu chức năng: Danh sách công việc được thực hiện trên máy tính và các thông tin mô tả. Yêu cầu chức năng nghiệp vụ : Các chức năng phần mềm tương ứng với nghiệp vụ của doanh nghiệp . Chức năng lưu trữ : Tương ứng với công việc ghi chép. Ví dụ: Ghi nhận việc cho mượn sách của một thư viện theo quy định mượ n. Chức năng tra cứu : tìm kiếm, theo dõi hoạt động và xem thông tin về một đối tượng. Chức năng tính toán : thống kê, tính toán Chức năng kết xuất: lập báo cáo (theo biểu mẫu). 35 2.3.2. Phân loại yêu cầu Yêu cầu chức năng hệ thống : Các chức năng phần mềm phát sinh thêm khi thực hiện công việc của phần mềm. Chức năng môi trường: Định cấu hình thiết bị, thời gian, nhân sự(Số nhân công, loại máy in, ) Chức năng mô phỏng : Mô phỏng hoạt động của thế giới thực. Chức năng tự động: Tự động thông báo, nhắc nhở người dùng Chức năng phân quyền : Phân quyền sử dụng cho các loại người dùng Quản trị hệ thống: phân quyền ng ư ời dùng Chức năng sao lưu : Sao lưu, phục hồi dữ liệu . 36 2.3.2. Phân loại yêu cầu Yêu cầu phi chức năng: Các yêu cầu liên quan đến chất lượng phần mềm, các ràng buộc cách thực hiện các yêu cầu chức năng. Liên quan đến ng ư ời dùng cuối Tính tiến hóa : cho phép người dùng thay đổi lại cách mô tả của yêu cầu chức năng Tính tiện dụng : giao diện, th an thiện , dễ sử dụng, dễ học, đầy đủ thông tin . Tính hiệu quả: thời gian đáp trả nhanh , dung lượng lưu trữ, chi phí sử dụng tài nguyên hệ thống như sử dụng tối ưu các không gian . Tính tương thích : Các yêu cầu liên quan đến việc chuyển đổi dữ liệu giữa phần mềm đang xét và các phần mềm khác, sự nhất quán giữa các màn hình trong hệ thống 37 2.3.2. Phân loại yêu cầu Yêu cầu liên quan đến các chuyên viên tin học Tính tái sử dụng : khả năng sử dụng lại các thành phần của hệ thống phần mềm cho các hệ thống khác t ư ơng đ ư ơng. Tính bảo trì : dễ bảo trì, dễ nâng cấp, khi bảo trì sẽ không ảnh h ư ởng đến dữ liệu trong hệ thống. 38 2.3.2. Phân loại yêu cầu Bước 1: Thực hiện : Khảo sát hiện trạng K ết quả : bảng báo cáo hiện trạng. Bước 2 : Thực hiện : Lập danh sách các yêu cầu K ết quả : d anh sách các yêu cầu sẽ được thực hiện trên máy tính. 39 2.3.3. Các b ư ớc xác định yêu cầu Đối t ư ợng tham gia xác định yêu cầu : Chuyên viên tin học : Là những người hiểu rõ về khả năng của máy tính , có kiến thức về tin học . Họ lắng nghe chuyên gia để hiểu rõ về nghiệp vụ của hệ thống. Chuyên gia : Là những người có kiến thức chuyên môn và nghiệp vụ của doanh nghiệp . Họ cần lắng nghe ý kiến của các chuyên viên tin học để đảm bảo các yêu cầu của họ là có thể thực hiện được trên phần mềm với chi phí và thời gian hợp lý. 40 2.3.3. Các b ư ớc xác định yêu cầu Các hình thức thực hiện phổ biến: Quan sát: Theo dõi các hoạt động diễn ra ở thế giới thực có liên quan, có thể ghi âm, ghi hình đối với những tình huống mang tính phức tạp, quan trọng, cần sự chính xác cao Phỏng vấn trực tiếp : Tổ chức phỏng vấn bắt đầu từ cấp lãnh đạo dần xuống các vị trí công việc. Có thể sử dụng các bảng câu hỏi có sẵn các câu trả lời cho đối tượng được phỏng vấn lựa chọ n Thu thập thông tin, tài liệu : Các công thức tính toán, quy định; các bảng biểu, mẫu giấy tờ có ít nhiều liên quan. Ví dụ: Phiếu mượn sách tại thư viện. 41 2.3.3.1. Khảo sát hiện trạng Quy trình thực hiện : Tìm hiểu tổng quan về thế giới thực : Quy mô hoạt động và các hoạt động mà đơn vị có tham gia. Tìm hiểu hiện trạng cơ cấu tổ chức : Tiến hành khảo sát cơ cấu tổ chức các bộ phận , t rách nhiệm và quyền hạn. giúp xác định đối t ư ợng sử dụng phần mềm . Tìm hiểu hiện trạng nghiệp vụ : chọn ng ư ời hoặc bộ phận để t hực hiện khảo sát , lập danh sách các công việc mà bộ phận này phụ trách, sau đó tìm hiểu các thông tin chi tiết của từng công việc , bao gồm : Thông tin đầu vào, Quá trình xử lý, Thông tin kết xuất. l ưu trữ, tra cứu, tính toán, tổng hợp/thống kê. 42 2.3.3.1. Khảo sát hiện trạng Xác định yêu cầu chức năng nghiệp vụ Cách tiến hành : Chuyên gia đề xuất và chuyên viên tin học sẽ kiểm tra lại Các b ước tiến hành : Xác định các công việc mà người dùng sẽ thực hiện trên phần mềm theo từng loại công việc sau: Lưu trữ, Tra cứu, Tính toán, Kết xuất 43 2.3.3.2 Lập danh sách các yêu cầu Lập bảng yêu cầu chức năng nghiệp vụ, bảng quy định/công thức và các biểu mẫu. Các biểu mẫu được mô tả chi tiết ngay sau bảng quy định/Công thức 44 2.3.3.2 Lập danh sách các yêu cầu Ví dụ: Xét phần mềm quản lý thư viện (i) Bảng yêu cần chức năng 45 2.3.3.2 Lập danh sách các yêu cầu 46 2.3.3.2 Lập danh sách các yêu cầu Bảng Quy định/ Công thức liên quan 47 2.3.3.2 Lập danh sách các yêu cầu Bảng Quy định/ Công thức liên quan 48 2.3.3.2 Lập danh sách các yêu cầu 49 2.3.3.2 Lập danh sách các yêu cầu 50 2.3.3.2 Lập danh sách các yêu cầu 51 2.3.3.2 Lập danh sách các yêu cầu 52 2.3.3.2 Lập danh sách các yêu cầu Xác định yêu cầu chức năng hệ thống và yêu cầu chất l ư ợng : Cách tiến hành : Chuyên viên tin học và chuyên gia cùng đề xuất và xem xét các yêu cầu. B ư ớc tiến hành Bước 1: Xem xét các yêu cầu chức năng: phân quyền, sao lưu, phục hồi, định cấu hình hệ thống, Bước 2: Xem xét các yêu cầu chức năng hệ thống chuyên biệt: yêu cầu về công việc mới, chỉ có thể tiến hành khi thực hiện trên máy tính Bước 3: Xem xét các yêu cầu về chất lượng theo từng loại tiêu chuẩn sau: Tiến hóa, Tiện dụng, Hiệu quả, Tương thích. 53 2.3.3.2 Lập danh sách các yêu cầu Sau đó lập bảng yêu cầu tương ứng theo mẫu sau : 54 2.3.3.2 Lập danh sách các yêu cầu 55 2.3.3.2 Lập danh sách các yêu cầu Ví dụ: Xét phần mềm quản lý thư viện (được xây dựng nhằm phục vụ cho 4 bộ phận là: độc giả, thủ thư, ban giám đốc và quản trị hệ thống). (i) Bảng yêu cầu chức năng hệ thống: Bảng yêu cầu về chất lượng hệ thống: 56 2.3.3.2 Lập danh sách các yêu cầu Mô hình hóa yêu cầu của hệ thống là cách biểu diễn các yêu cầu chức năng của hệ thống đã đ ư ợc xác định trong giai đoạn phân tích bằng các mô hình trực quan giúp cho các bên tham gia có thệ hiểu hệ thống một cách chính xác h ơ n. 57 2.4. Mô hình hoá yêu cầu hệ thống Mục tiêu : biểu diễn trực quan và chi tiết hơn về ngữ cảnh vấn đề cần giải quyết và các thông tin cốt lõi trong yêu cầu của hệ thống . Kết quả : các mô hình mô tả toàn bộ hoạt động của hệ thống. Kỹ thuật phân tích: Dựa vào các chức năng đã đ ư ợc xác định và mô tả chi tiết trong b ư ớc phân tích, sau đó sử dụng các công cụ mô hình hóa thực hiện các mô hình biểu diễn các chức năng của hệ thống. 58 2.4. Mô hình hoá yêu cầu hệ thống Nguyên lý 1 : M ô hình hóa phạm vi hệ thống (Domain) Định danh dữ liệu (đối tượng, thực thể), Định nghĩa các thuộc tính, thiết lập các mối quan hệ giữa các dữ liệu Nguyên lý 2: Mô hình hóa Chức năng của hệ thống Định danh các chức năng (biến đối thông tin) Xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống Xác định các tác nhận tạo dữ liệu và tác nhân tiêu thụ dữ liệu 59 2.4.1. Các nguyên lý mô hình hóa Nguyên lý 3: Mô hình hóa Hành vi Phần mềm (hệ thống) Xác định các trạng thái hệ thống . Ví dụ: giao diện đồ họa Xác định các dữ liệu làm thay đổi hành vi hệ thống . Ví dụ: bàn phím, chuột, các cổng thông tin Nguyên lý 4: Phân hoạch Mô hình Làm mịn các mô hình dữ liệu Tạo cây (mô hình) phân rã chức năng Biểu diễn hành vi ở các mức chi tiết khác nhau Nguyên lý 5: Tìm hiểu vấn đề bản chất Chỉ xét bản chất của yêu cầu và không quan tâm đến cách cài đặt. 60 2.4.1. Các nguyên lý mô hình hóa Sơ đồ phân rã chức năng (Function Decomposition Diagram) B iểu diễn các chức năng bằng cách mô tả các tính chất của dữ liệu đầu vào và đầu ra nhằm: Xá c định được phạm vi của hệ thống P hân hoạch được hệ thống chức năng T ạo nền tảng cho thiết kế kiến trúc hệ thống 61 2.4.2. Sơ đồ phân rã chức năng ( FDD ) 62 2.4.2. Sơ đồ phân rã chức năng (FDD) 63 2.4.2. Sơ đồ phân rã chức năng (FDD) Mô hình bản mẫu là một phát thảo s ơ bộ một số chức năng của hệ thống gồm giao diện, dựa trên các ý tưởng/yêu cầu của khách hàng. Bản mẫu mô tả cách thức phần mềm hoạt động , cách người dùng tương tác với hệ thống và giúp người dùng có thể hình dung được sản phẩm theo yêu cầu. 64 2.4.3. Mô hình bản mẫu (prototype) Thực hiện bản mẫu Mô hình bản mẫu đ ư ợc tạo bởi kỹ sư phân tích và kỹ sư thiết kế phần mềm Người sử dụng xem bản mẫu và đ ưa ra ý kiến đóng góp và phản hồi thông tin giúp nhóm phân tích có đ ư ợc yêu cầu chính xác nhất . Nếu người sử dụng đồng ý với bản mẫu thì n hóm phát triển sẽ tiến hành xây dựng phần mềm Ngược lại cả hai phải quay lại giai đoạn xác định yêu cầu. Công việc này được lặp lại liên tục cho đến khi người sử dụng đồng ý với các bản mẫu do nhà phát triển đưa ra. 65 2.4.3. Mô hình bản mẫu (prototype) S ơ đồ luồng dữ liệu (data-flow diagram): Là mô hình biểu diễn l uồng dữ liệu và cách thức dữ liệu được xử lý bên trong hệ thống với nhiều mức chi tiết khác nhau. Sơ đồ này có nhiều biến thể mở rộng khác nhau. 66 2.4.4. Sơ đồ luồng dữ liệu ( DFD ) P h ư ơng pháp phân tích h ư ớng đối t ư ợng: dựa trên ý t ư ởng lập trình h ư ớng đối t ư ợng, gồm các khái niệm Ðối tượng (Object): gồm dữ liệu và hành vi tác động lên dữ liệu này. Lớp (Class): tập các đối tượng có cùng cấu trúc dữ liệu và hành vi. Đ óng gói (Encapsulation): khả năng hạn chế tác động trực tiếp lên dữ liệu của đối tượng Kế thừa (inheritance): là đặc tính cho phép một lớp kế thừa thuộc tính và hành vi của lớp cha. 67 2.4.5. Mô hình h ư ớng đối t ư ợng Mô hình h ư ớng đối t ư ợng: mô hình hóa các đối t ư ợng và mối quan hệ giữa các đối t ư ợng Công cụ : sử dụng ngôn ngữ mô hình hóa UML, bao gồm các mô hình biểu diễn các khía cạnh của hệ thống: Biểu diễn hành vi: use case diagram, sequence diagram, activity diagram,.... Biểu diễn nghiệp vụ: business model Biểu diễn cấu trúc của hệ thống: domain model , class diagram, component diagram. 68 2.4.5. Mô hình h ư ớng đối t ư ợng Ví dụ: Use Case Diagram 69 2.4.5. Mô hình h ư ớng đối t ư ợng Ví dụ: class Diagram 70 2.4.5. Mô hình h ư ớng đối t ư ợng Ví dụ: Phân tích phần mềm quản lý thư viện gồm 4 yêu cầu: L ập thẻ độc giả Nhận sách, C ho mượn sách, Trả sách. 71 2.4.6. Minh họa từ yêu cầu sang mô hình hóa Mô hình hóa yêu cầu Sơ đồ luồng dữ liệu cho công việc lập thẻ độc giả D1: Thông tin về thẻ độc giả cần nhập D4: Thông tin về thẻ độc giả cần lưu trữ trên kho D5: Thông tin trên thẻ độc giả (trong thế giới thực) Xử lý thẻ độc giả : Kiểm tra tính hợp lệ của thẻ trước ghi nhận và in 72 2.4.6. Minh họa từ yêu cầu sang mô hình hóa 73 2.4.6. Minh họa từ yêu cầu sang mô hình hóa Mô hình hóa yêu cầu Sơ đồ luồng dữ liệu cho công việc nhận sách D1: Thông tin về thẻ sách cần nhập D4: Thông tin về sách cần lưu trữ trên kho Xử lý nhập sách: Kiểm tra tính hợp lệ của sách trước khi lưu vào kho Mô hình hóa yêu cầu Sơ đồ luồng dữ liệu cho công việc cho m ư ợn sách D1: Thông tin về độc giả và sách muốn mượn D3: Thông tin được sử dụng cho việc kiểm tra quy định mượn sách D4: Thông tin về việc mượn sách Xử lý cho mượn sách: Kiểm tra tính hợp lệ của việc mượn, lưu vào kho 74 2.4.6. Minh họa từ yêu cầu sang mô hình hóa Mô hình hóa yêu cầu Sơ đồ luồng dữ liệu cho công việc trả sách D1: Thông tin về độc giả và sách trả D3: Thông tin sử dụng cho việc kiểm tra quy định trả sách D4: Thông tin về việc trả sách Xử lý trả sách : Kiểm tra tính hợp lệ của việc trả sách, lưu vào kho. 75 2.4.6. Minh họa từ yêu cầu sang mô hình hóa 1. Phụ lục A trang 170 2. Phụ lục B trang 179 76 BÀI TẬP
File đính kèm:
- bai_giang_cong_nghe_phan_mem_phan_tich_va_dac_ta_yeu_cau.pptx