1. Trang chủ
  2. » Công Nghệ Thông Tin

Bài giảng Phân tích thiết kế hệ thống thông tin: Bài 5 - TS. Trần Mạnh Tuấn

41 23 0

Đ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

Thông tin cơ bản

Định dạng
Số trang 41
Dung lượng 1,38 MB

Nội dung

Bài giảng Phân tích thiết kế hệ thống thông tin: Bài 5 Requirements – Yêu cầu cung cấp cho người học những kiến thức như: Quy trình phát triển HĐT(OO) - RUP; Mô hình hóa nghiệp vụ; Requirement – Yêu cầu. Mời các bạn cùng tham khảo!

PHÂN TÍCH THIẾT KẾ HỆ THỐNG THƠNG TIN Bài Requirements – Yêu cầu Giáo viên: TS Trần Mạnh Tuấn Bộ môn: Hệ thống thông tin Khoa: Công nghệ thông tin Email: tmtuan@tlu.edu.vn Điện thoai: 0983.668.841 Nội dung Quy trình phát triển HĐT(OO) - RUP Mơ hình hóa nghiệp vụ Requirement – Yêu cầu Quy trình phát triển HĐT  Quy trình phát triển theo chức gặp nhiều hạn chế, thiếu tiêu chí chất lượng đặc biệt tính bảo trì  Thúc phát sinh quy trình phát triển theo hướng đối tượng (OO)  RUP – Rational Unified Process – Quy trình đồng hợp quy trình Quy trình phát triển HĐT Các triệu chứng vấn đề phát triển phần mềm  Triệu chứng (Symptoms) – Các vấn đề xấu phần mềm Việc xử lý triệu chứng xấu làm chất lượng phần mềm cao theo định hướng lặp dự đốn Quy trình phát triển HĐT Bộ kinh nghiệm thực tế (Best practises)  Tập phương pháp phát triển phần mềm kiểm nghiệm phần mềm thương mại  Tính đắng khẳng định thơng qua q trình sử dụng thường xuyên thành công công nghiệp tổ chức  Bộ kinh nghiệm thu được: • Khách hàng • Dự án • Chuyên gia Quy trình phát triển HĐT Bộ kinh nghiệm thực tế  Phát triển lặp  Kỹ thuật sử dụng để chuyển chức hệ thống vào chuỗi liên tục phiên hoàn thiện tăng dần  Mỗi phiên phát triển thời gian cố định, gọi vòng lặp Mỗi vòng lặp tập trung vào: định nghĩa – phân tích – thiết kế - xây dựng – kiểm thử tập yêu cầu Quy trình phát triển HĐT Bộ kinh nghiệm thực tế  Vòng lặp giải vấn đề: • Giải rủi ro lớn trước đầu tư • Sớm nhận phản hồi người dùng • Làm cho việc kiểm thử tích hợp diễn liên tục • Định nghĩa mốc ngắn hạn cho dự án • Làm cho việc cài đặt phần thực thi sẵn sàng Quản lý yêu cầu:  Tỉ lệ thành công dự án phụ thuộc lớn (yêu tố định) việc quản lý yêu cầu dự án  Các khía cạnh quản lý u cầu: • Phân tích vấn đề • Hiểu mong đợi người sử dụng • Định nghĩa hệ thống • Quản lý phạm vi • Làm mịn định nghĩa hệ thống • Quản lý thay đổi yêu cầu Quy trình phát triển HĐT Bộ kinh nghiệm thực tế  Sử dụng kiến trúc phần mềm  Kiến trúc phần thiết kế Nó bao gồm định làm hệ thống xây dựng  Kiến trúc phần mềm khía cạnh quan trọng nhất, điều khiển quy trình phát triển lặp tăng thêm hệ thống suốt vịng đời phát triển  Tính chất kiến trúc: • Khả đàn hồi linh động  Đề đạt tính chất cần dự đốn lĩnh vực phần mềm cơng nghệ phát triển, để đưa thiết kế tính đến thay đổi  Kỹ thuật chính: • Trừu tượng hóa • Đóng gói • Phân tích thiết kế hướng đối tượng  Kết quả: đưa ứng dụng bảo trì mở rộng Quy trình phát triển HĐT Bộ kinh nghiệm thực tế  Mơ hình hóa trực quan  Mơ hình đơn giản hóa thực, cung cấp mô tả đầy đủ hệ thống từ góc nhìn  Mơ hình hóa quan trọng giúp việc phát triển thị, đặc tả, xây dựng tài liệu hóa cấu trúc hành vi kiến trúc hệ thống Sử dụng UML thành viên nhóm phát triển trao đổi định hệ thống với  Giúp đội phát triển quản lý phức tạp hệ thống Quy trình phát triển HĐT Bộ kinh nghiệm thực tế  Kiểm tra thường xuyên  Kiểm thư chức (Functional Testing)  Kiểm thử tính dùng (Usability Testing)  Kiểm thử tin cậy (Reliability Testing)  Kiểm thử hiệu (Performance Testing)  Kiểm thư tính hỗ trợ (Supportability Testing) 10 Bài tập Bài tốn: Một cửa hàng bn bán đồ dùng thể thao muốn xây dựng chương trình quản lý bán hàng qua môi trường Web cửa hàng Hãy xác định yêu cầu người dùng 27 Trao đổi, câu hỏi? 28 Tiến trình phát triển phần mềm  Mọi kỹ nghệ (engineering) đề cập đến sản xuất sản phẩm theo tiến trình  Tổng quát tiến trình (process) xác định (Who) làm (What); làm (When) làm (How) để đạt tới mục đích mong muốn  Tiến trình phát triển phần mềm (Software Development Process - SDP) tiến trình xây dựng sản phẩm phầm mềm hay nâng cấp phần mềm có  Thí dụ tiến trình phát triển phần mềm:  Rational Unified Process - RUP New or changed requirements 29 Software Development Process New or changed system Tiến trình phát triển phần mềm  Tiến trình phát triển phần mềm mơ tả tập hoạt động cần thiết để chuyển đổi từ yêu cầu người sử dụng sang hệ thống phần mềm  Yêu cầu người sử dụng xác định mục tiêu phát triển phần mềm  Khách hàng kỹ sư tin học xác định dịch vụ mà hệ thống cần có (yêu cầu chức hệ thống)  Yêu cầu chức mô tả mà hệ thống phải làm (What) không mô tả hệ thống làm (How)  Khách hàng có ràng buộc phi chức năng: thời gian đáp ứng, chuẩn ngôn ngữ 30 Tiến trình phát triển phần mềm  Thu thập phân tích u cầu cơng việc khó khăn  Các u cầu thường khơng hồn chỉnh  Yêu cầu khách hàng thường mô tả khái niệm, đối tượng thuật ngữ khó hiểu với kỹ sư tin học  Các yêu cầu khách hàng thường thiếu cấu trúc, thiếu xác, dư thừa, chừng, thiếu quán  Các yêu cầu thiếu tính khả thi  Do  Bất kỳ tiến trình phát triển thu thập phân tích yêu cầu  Các hoạt động SDP kết liên quan hình thành pha tiến trình 31 gọi Phân tích yêu cầu Thu thập phân tích yêu cầu  Mục tiêu  Hình thành tài liệu đặc tả yêu cầu (Requirement Specification)  Tài liệu đặc tả yêu cầu sử dụng  Cam kết khách hàng tổ chức phát triển hệ thống mà hệ thống làm (và mà hệ thống làm)  Cơ sở để đội ngũ phát triển phát triển hệ thống  Mô hình tương đối đầy đủ hệ thống địi hỏi  Tiến trình phân tích u cầu bao gồm hoạt động lặp Developer Understanding Client Domain Expert User 32 Requirement Capture Feasibility Study Validation Specification document Classification Các hoạt động phân tích yêu cầu  Hiểu lĩnh vực vấn đề (Understanding)  Phân tích viên trình bày hiểu biết lĩnh vực vấn đề  Khám phá quan niệm  Suy yêu cầu khách hàng  Thu thập yêu cầu (Requirement Capture)  Phân tích viên cần có cách thu thập nhu cầu khách hàng cho họ tham gia vào dự án  Phân tích viên, khách hàng, chuyên gia lĩnh vực ứng dụng người sử dụng hệ thống phát thu thập yêu cầu  Kỹ trừu tượng quan trọng để thu thập chính, bỏ qua khơng cần thiết  Phân lớp  Đánh giá  Nghiên cứu khả thi 33 Các hoạt động phân tích yêu cầu  Hiểu lĩnh vực vấn đề  Thu thập yêu cầu  Phân lớp (Classification)  Đầu vào hoạt động tập hợp phi cấu trúc yêu cầu thu thập pha trước để tổ chức chúng thành nhóm dính liền  Gắn mức ưu tiên cho yêu cầu theo tầm quan trọng chúng khách hàng người sử dụng  Đánh giá (Validation)  Kiểm tra xem yêu cầu có quán đầy đủ  Giải mâu thuẫn yêu cầu  Nghiên cứu khả thi (Feasibility study)  Dự báo khả thỏa mãn sử dụng phần cứng, phần mềm yêu cầu nhận  Quyết định bước hệ thống đề xuất có hiệu 34 Phân tích yêu cầu  Khi kết thúc phân tích u cầu?  Khơng có quy luật định  Để tiến tới bước phát triển phần mềm trả lời câu hỏi sau:  Khách hàng, người sử dụng cuối người phát triển hiểu trọn vẹn hệ thống?  Mơ hình hệ thống địi hỏi xây dựng hình thành đầy đủ? • có đầy đủ chức (dịch vụ) • có đầy đủ đầu vào- đầu • cần loại liệu  Chú ý: Chưa mô tả định cài đặt mơ hình  Đặc tả u cầu mơ hình hệ thống mức cần phải hiệu chỉnh, bổ sung cần thiết pha phát triển 35 Phân tích yêu cầu  Đặc tả yêu cầu  thơng báo thức địi hỏi hệ thống phải phát triển  Nó khơng phải tài liệu thiết kế  Mô tả đặc tả yêu cầu  Ngôn ngữ đặc tả  Ký pháp đồ họa Pha thu thập phân tích yêu cầu quan trọng Nếu không phát lỗi pha khó tốn để phát pha 36 Thiết kế hệ thống  Sau có đặc tả yêu cầu, hai tiến trình thiết kế hệ thống  Thiết kế kiến trúc (logíc) • Phân hoạch u cầu thành thành phần • Tài liệu thiết kế kiến trúc mơ tả thành phần cần làm chúng tương tác với để hình thành chức hệ thống  Thiết kế chi tiết (vật lý) • Thiết kế thành phần • Tài liệu thiết kế chi tiết mô tả thành phần hệ thống phải làm cần làm  Các hoạt động thiết kế Mơ hình hệ thống Đặc tả u cầu Thiết kế logíc: Phân hoạch Thành phần làm gì? Quan hệ thành phần 37 Trừu tượng Độc lập cài đặt Kiến trúc tổng thể Hệ thống cốt lõi cụ thể phụ thuộc cài đặt Thiết kế chi tiết: Làm mịn Thành phần làm nào? Thiết kế quan hệ Thiết kế hệ thống  Tài liệu pha thiết kế kiến trúc mơ hình kiến trúc  Đặc tả thành phần, mô tả mà thành phần phải làm cách giao diện thành phần  Mơ hình hệ thống chủ yếu mơ tả “what”, mơ tả “how”  Thiết kế chi tiết thực nhiều bước làm mịn mơ hình kiến trúc  Mơ hình thiết kế chi tiết mô tả:  thiết kế chức thành phần  thiết kế giao diện thành phần  Mơ hình hệ thống mức xem hệ thống cốt lõi  cụ thể  phụ thuộc cài đặt  xác định “How” 38 Lập trình kiểm thử mođun  Mỗi thành phần pha thiết kế thực thành mođun chương trình  Kiểm chứng hay kiểm thử mođun chương trình theo đặc tả có từ pha thiết kế 39 Tích hợp kiểm thử hệ thống  Tổ hợp mođun chương trình thành hệ thống  Kiểm thử hệ thống chương trình để đảm bảo đáp ứng đầy đủ yêu cầu  Khi người phát triển thỏa mãn với sản phẩm  khách hàng kiểm thử hệ thống  Pha kết thúc khách hàng chấp nhận sản phẩm 40 Bảo trì hệ thống  Pha bắt đầu hệ thống cài đặt sử dụng thực tế, sau cấp phát sản phẩm cho khách hàng  Bảo trì bao gồm thay đổi sản phẩm để khách hàng đồng ý họ thỏa mãn với sản phẩm  Bảo trì bao gồm  sửa phần mềm • loại bỏ lỗi mà không phát pha trước  nâng cấp phần mềm • Hiệu năng: Bổ sung chức năng, tăng tốc độ thực chương trình • Thích nghi: Các thay đổi cho phù hợp với mơi trường phần mềm hoạt động thay đổi, thí dụ yêu cầu phủ  Thời gian trung bình:  sửa lỗi 17,5%, hiệu 60%, thích nghi 18% 41 ... thu thập phân tích u cầu quan trọng Nếu khơng phát lỗi pha khó tốn để phát pha 36 Thiết kế hệ thống  Sau có đặc tả u cầu, hai tiến trình thiết kế hệ thống  Thiết kế kiến trúc (logíc) • Phân hoạch... đặt Kiến trúc tổng thể Hệ thống cốt lõi cụ thể phụ thuộc cài đặt Thiết kế chi tiết: Làm mịn Thành phần làm nào? Thiết kế quan hệ Thiết kế hệ thống  Tài liệu pha thiết kế kiến trúc mơ hình kiến... dụng  Cam kết khách hàng tổ chức phát triển hệ thống mà hệ thống làm (và mà hệ thống khơng thể làm)  Cơ sở để đội ngũ phát triển phát triển hệ thống  Mơ hình tương đối đầy đủ hệ thống địi hỏi

Ngày đăng: 09/08/2021, 18:14

TỪ KHÓA LIÊN QUAN