zunia.vn

Tuyển sinh 2024 dành cho Gen-Z

zunia.vn

» Công Nghệ Thông Tin

» Hệ điều hành

Bài giảng Công nghệ phần mềm: Chương 2 - ĐH Công nghệ TP.HCM

Chia sẻ: Elysale Elysale | Ngày: | Loại File: PPTX | Số trang:76

Báo xấu

30
lượt xem 11
download

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

Bài giảng Công nghệ phần mềm: Chương 2 Phân tích và đặc tả yêu cầu cung cấp cho người học những kiến thức như: Tổng quan; Quá rình phân tích; Xác định yêu cầu; Mô hình hóa yêu cầu hệ thống. Mời các bạn cùng tham khảo!

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 Công nghệ phần mềm: Chương 2 - ĐH Công nghệ TP.HCM

Insert or Drag and Drop your Image PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU Jens Martensson
NỘI DUNG 1. Tổng quan 2. Quá rình phân tích 3. Xác định yêu cầu 4. Mô hình hóa yêu cầu hệ thống Jens Martensson 2
2.1. 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. Jens Martensson 3
2.2. Quá trình phân tích 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 Jens Martensson 4
2.2. Quá trình phân tích Jens Martensson 5
2.2.1 Phân tích phạm vi dự án • Xác định rõ quá trình nghiệp vụ mà phần mềm sẽ xử lý. • Một giải pháp nghiệp vụ gồm: • Phần triển khai phần mềm: Trong đó yêu cầu nghiệp vụ của khách hàng được hiện thực hóa thành phần mềm cụ thể, • Phần thực hiện bởi con người hay chương trình: Là giai đoạn vận hành sử dụng hệ thống Jens Martensson 6
2.2.1 Phân tích phạm vi dự án • Mục đích của việc chia giải pháp nghiệp vụ thành 2 phần là: • Chia trách nhiệm thành những nhiệm vụ con tương ứng với việc chia chương trình thành các module. • Xác định bao nhiêu vùng địa lý liên quan (chi nhánh văn phòng), • Ước lượng số người dùng phần mềm, thời gian phần mềm được duy trì, • Biết được tính chính xác của yêu cầu phần mềm, • Hiểu khách hàng mong đợi dự án được triển khai • Xác định được phạm vi của dự án, dự đoán ngân sách, thời gian và nguồn nhân lực. Jens Martensson 7
2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ • Xác định yêu cầu nghiệp vụ: • Mỗi dự án sẽ có một hay nhiều yêu cầu nghiệp vụ (tác vụ) liên quan đến việc mô tả công việc cụ thể trong nghiệp vụ. • Một tác vụ có thể được chia nhỏ thành nhiều phần đủ để mô tả công việc chính xác nhất. Jens Martensson 8
2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ Jens Martensson 9
2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ • Xác định yêu cầu chất lượng: • Mỗi dự án có các yêu cầu liên quan đến khả năng đáp ứng nhanh, bảo mật, phụ thuộc, dễ dùng … • Chất lượng của dự án là trên mức độ chấp nhận, và sự thỏa mãn nhu cầu của khách hàng. Jens Martensson 10
2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ • Phân tích cơ sở hạ tầng hiện hành: • Giải pháp PM đưa vào, nếu phù hợp với cơ sở hạ tầng thì sẽ tốt hơn là thay thế hệ thống hiện hành. • Sự tương thích với cơ sở hạ tầng hiện hành sẽ đảm bảo khả thi, vì dự án cần làm việc trên phần cứng và phần mềm hiện có. • Nếu biết được HĐH, loại mạng đang sử dụng, thông tin cấu hình của máy chủ, và những phần mềm không tương thích với chương trình mới thì sẽ giúp việc phân tích chính xác và hiệu quả hơn. Jens Martensson 11
2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ • Phân tích ảnh hưởng kỹ thuật: • Nâng cấp, mở rộng chức năng cho hệ thống hiện hành hoặc thay mới. Tuy nhiên, cải thiện hệ thống cũ và tích hợp dễ dàng hơn hệ thống mới. • Ví dụ: hệ thống kế toán cũ lưu trữ dữ liệu trên MS Access. Khi nâng cấp hệ thống, có thể chuyển toàn bộ dữ liệu sang SQL Server. Jens Martensson 12
2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ • Phân tích ảnh hưởng kỹ thuật: • Nên tìm hiểu sự khác biệt về giao tác, bảo mật, và những chức năng khác. • Nên tìm hiểu thủ tục chuyển đổi dữ liệu từ hệ thống cũ sang hệ thống mới, có kế hoạch bảo lưu khi việc thực hiện này bị lỗi. • Cần có biện pháp đảm bảo an toàn những dữ liệu. Jens Martensson 13
2.2.3. Phân tích yêu cầu bảo mật • Xác định các vai trò người dùng của hệ thống: Một hệ thống phần mềm có nhiều mức độ bảo mật • Người dùng cuối: chỉ cần quyền truy xuất giới hạn. • Quản trị hệ thống: có quyền cao nhất. • Xử lý bảo mật phần mềm là kỹ thuật dùng để cấp quyền sử dụng với mức độ bảo mật khác nhau. Jens Martensson 14
2.2.3. Phân tích yêu cầu bảo mật • Xác định môi trường bảo mật phần mềm • Người dùng phải đăng nhập vào hệ thống để thực hiện các chức năng theo quyền được cấp, nhằm để kiểm soát quyền truy cập các tài nguyên được chia sẽ như tập tin, dịch vụ hệ thống, CSDL. • Mức độ kiểm soát của phần mềm được gọi là ngữ cảnh bảo mật. • Độ bảo mật của phần mềm không bị giới hạn bởi người dùng. Jens Martensson 15
2.2.3. Phân tích yêu cầu bảo mật • Xác định ảnh hưởng bảo mật: • Nếu hệ thống cũ có sẵn cơ chế bảo mật, thì hệ thống mới nên điều chỉnh cho phù hợp với cơ chế đã có. • Nếu đang thực hiện hệ thống bảo mật mới, cần phân tích tác động của hệ thống trên hệ thống hiện tại: • Hệ thống mới có làm hỏng chức năng của phần mềm hiện tại? • Hệ thống mới có đòi hỏi phải hỗ trợ thêm đăng nhập mở rộng? • Hệ thống mới có hạn chế một số người dùng những tài nguyên mà họ được quyền truy cập trước đây? Jens Martensson 16
2.2.3. Phân tích yêu cầu bảo mật • Kế hoạch vận hành: • Khi tổ chức của khách hàng thay đổi nhân sự. Những thao tác này đòi hỏi hiệu chỉnh bảo mật CSDL. • Nếu người dùng có nhiều vị trí khác nhau, cần lên kế hoạch tái tạo bảo mật CSDL đã được lưu giữ ở các vị trí khác nhau, nhằm tạo thuận lợi cho người dùng là có thể đăng nhập bằng thông tin được lưu ở vị trí gần hơn so với vị trí gốc. Jens Martensson 17
2.2.3. Phân tích yêu cầu bảo mật • Kế hoạch kiểm soát và đăng nhập: • File nhật ký giao dịch trợ giúp kiểm soát hoạt động cho vấn đề bảo mật, ghi lại tất cả các giao dịch trên hệ thống. • Phải lập kế hoạch kiểm soát nhật ký để phát hiện các giao dịch bất thường, và có đề nghị xử lý. Jens Martensson 18
2.2.3. Phân tích yêu cầu bảo mật • Xác định mức độ yêu cầu bảo mật • Việc triển khai mức độ bảo mật cho phần mềm cần được cân nhắc dựa trên tính hiệu quả và chi phí. • Nếu hệ thống không lưu trữ dữ liệu có tính nhạy cảm cao, thì chỉ cần lưu trữ thông tin về “sự xác thực của người dùng”. • Nếu hệ thống có lưu trữ các thông tin cần bảo mật, thì cần có chi phí cho chức năng bảo mật và cần phải được kiểm chứng. Jens Martensson 19
2.2.4. Phân tích yêu cầu tốc độ • Yêu cầu về tốc độ xử lý của phần mềm: là một yêu cầu khó đối với nhóm phát triển phần mềm. • Tốc độ xử lý của phần mềm là sự đáp trả của hệ thống đối với thao tác của người dùng. • Tốc độ của phần mềm phụ thuộc vào việc thiết kế hệ thống. • Đối với phần mềm phân tán, tốc độ xử lý của phần mềm còn tùy thuộc vào số người truy cập vào hệ thống tại cùng một thời điểm. Jens Martensson 20

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.