Скачать презентацию TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN 1 Скачать презентацию TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN 1

c279b6bcc617f8aab08610aa00c49579.ppt

  • Количество слайдов: 53

TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN 1 TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN 1

TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN n Khái niệm cơ bản về hệ TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN n Khái niệm cơ bản về hệ thống (System) n Tổ chức (Organization) n Dữ liệu (Data) và thông tin (information) n Thông tin và các mức ra quyết định quản lý (Management decision making) n Định nghĩa hệ thống thông tin (Information Systems) n Phân loạI IS ¨ Các IS phân loại theo mức quản lý tổ chức. 2 2

Khái niệm cơ bản về hệ thống Khái niệm cơ bản về hệ thống "Một hệ thống là một tập hợp các thành phần liên quan với nhau và phối hợp hoạt động cùng với nhau nhằm đạt được một mục tiêu cụ thể" (Lee) System A Subsystem B Subsystem C Subsystem E Environment of System A Subsystem D Interface Boundary 3 3

Tổ chức (Organization) n Tổ chức là một hệ thống ¨ ¨ Tổ chức Tổ chức (Organization) n Tổ chức là một hệ thống ¨ ¨ Tổ chức kinh tế: xí nghiệp, công ty, … Tổ chức xã hội: bệnh viện, câu lạc bộ, … Sales IT Training Purchasing Môi trường hoạt động của tổ chức HRI 4 4

Dữ liệu và thông tin n Dữ liệu (data): Dữ liệu và thông tin n Dữ liệu (data): "Data is the raw input from which information is provided” (Lucey) ¨ Là các dữ kiện, các sự kiện, các giao dịch thô, rời rạc, . . . n Thông tin (information): “Information is data that have been processed in such a way as to be useful to the recipient. ” (Lucey) n Thông tin là tài nguyên của tổ chức, và có vai trò quan trọng quyết định sự thành công của tổ chức. ¨ ¨ ¨ Thông tin được tạo ra và truy xuất ngày càng tăng Yêu cầu quản lý thông tin hiệu quả. Xử lý để tạo ra các thông tin mới có giá trị hơn 5 5

Information Systems (IS) n Một hệ thống thông tin: Là các phương tiện có Information Systems (IS) n Một hệ thống thông tin: Là các phương tiện có thể nhận dữ liệu (input), lưu trữ và xử lý dữ liệu, để tạo ra thông tin (output) cho mục đích hỗ trợ ra quyết định. ¨ Có thể xử lý bằng tay hoặc máy tính. ¨ n Hệ thống thông tin của tổ chức gồm: Một cơ sở thông tin (information base) mà bao gồm một hay nhiều nguồn thông tin khác; ¨ Một tập các xử lý mà được thực hiện bởi người hay máy để truy xuất, cập nhập và xử lý thông tin. ¨ Ví dụ: Một hệ thống thư viện có cơ sở thông tin là sách, loại sách, …; các xử lý là tìm, mượn, trả sách, … ¨ 6 6

Hệ thống thông tin tự động hóa n Hệ thống thông tin tự động Hệ thống thông tin tự động hóa n Hệ thống thông tin tự động hóa (Computerized Information Systems) bao gồm: Một hay nhiều cơ sở dữ liệu (databases) hay tập tin (files) lưu trữ cở sở thông tin. ¨ Một hay nhiều chương trình ứng dụng (Application programs) để truy xuất và cập nhật cơ sở thông tin bằng máy tính. ¨ Một hay nhiều giao diện người dùng (user interface) cho các nhóm người dùng khác nhau. ¨ Computerized Information System = Databases + Applications + Interfaces 7 7

Thông tin và các cấp quản lý n Thông tin cần thiết cho doanh Thông tin và các cấp quản lý n Thông tin cần thiết cho doanh nghiệp và giúp ra quyết định ở nhiều mức quản lý khác nhau trong tổ chức Large time horizon Summary Unstructured data problems Strategic Tactical Operational Small time horizon Detail data Structured problems Anthony’s Pyramid: cấu trúc quản lý của tổ chức 8 8

Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Leisure Industry Insurance Systems 9 Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Leisure Industry Insurance Systems 9 9

Real-Time Systems Automated Production Control Systems Security Systems 10 10 Real-Time Systems Automated Production Control Systems Security Systems 10 10

Management Information Systems Decision Support Systems Knowledge Based Systems Office Automation Systems Executive Information Management Information Systems Decision Support Systems Knowledge Based Systems Office Automation Systems Executive Information Systems 11 11

Best Practices of Software Engineering 12 Best Practices of Software Engineering 12

Objectives: Best Practices n Identify symptoms of software development problems. n Explain the Best Objectives: Best Practices n Identify symptoms of software development problems. n Explain the Best Practices. n Present the Rational Unified Process (RUP) within the context of the Best Practices. 13

Mục đích của công nghệ phần mềm n Nhằm tạo ra sản phẩm phần Mục đích của công nghệ phần mềm n Nhằm tạo ra sản phẩm phần mềm có chất lượng Với ít nỗ lực (tiến trình phát triển dễ dàng) ¨ Với ít chi phí và thời gian ¨ n Chất lượng phần mềm (Quality Software) bao gồm: Tính đáng tin cậy (Reliable) ¨ Tính dễ dùng (Reusable) ¨ Tinh tế (Robust): có các chức năng hiệu quả ¨ Dễ bảo trì (Maintainable) ¨ Tính Hiệu quả (Efficient) ¨ Thân thiện người dùng (Userfriendly) ¨… ¨ 14 14

Bản chất việc phát triển phần mềm n Phần mềm là sản phẩm của Bản chất việc phát triển phần mềm n Phần mềm là sản phẩm của hoạt động phát triển một cách sáng tạo của các “nghệ sĩ lành nghề” ¨ ¨ n Phần mềm được phát triển, chứ không phải sản xuất. Ngay cả với công nghệ thành phần (Component technology), phần mềm được xây dựng bằng cách lắp ghép các thành phần thì xử lý lắp ghép này cũng là nghệ thuật. Cho bất kỳ hệ thống nào, luôn cần phải tạo ra một mô hình quan niệm của giải pháp cuối cùng thỏa mãn các yêu cầu của khách hàng. ¨ ¨ Đó là kết quả của nhiệm vụ phân tích yêu cầu và thiết kế hệ thống. Độc lập với cài đặt. 15 15

Con người liên quan (Stakeholders) n Khách hàng (Customers): Users và System owners Các Con người liên quan (Stakeholders) n Khách hàng (Customers): Users và System owners Các nguyên nhân dẫn đến thất bại của dự án phần mềm liên quan đến khách hàng: ¨ Yêu cầu khách hàng bị hiểu sai và hay thu thập không đầy đủ ¨ Yêu cầu khách hàng thay đổi quá thường xuyên. ¨ Khách hàng không giao đầy đủ các tài nguyên cho dự án. ¨ Khách hàng không hợp tác với người phát triển. ¨ Mong đợi không thực tế của khách hàng. ¨ Khách hàng không cần đến hệ thống nữa. n Người phát triển (Developers): Analysts, Designers, Programmers ¨ “Thiết kế tốt được tạo từ những nhà thiết kế tốt” 16 16

Symptoms of Software Development Problems n User or business needs not met n Requirements Symptoms of Software Development Problems n User or business needs not met n Requirements not addressed n Modules not integrating n Difficulties with maintenance n Late discovery of flaws n Poor quality of end-user experience n Poor performance under load n No coordinated team effort n Build-and-release issues 17

Trace Symptoms to Root Causes Symptoms Needs not met Requirements churn Modules do not Trace Symptoms to Root Causes Symptoms Needs not met Requirements churn Modules do not fit Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming Undetected complexity inconsistencies Undetected inconsistencies Colliding developers Poor testing Build-and-release Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Waterfall development Subjective assessment Uncontrolled change Insufficient automation Manage Change 18

Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Ensures users are involved as requirements evolve Validates architectural decisions early on Addresses complexity of design/implementation incrementally Continuously Verify Quality Measures quality early and often Manage Change Evolves baselines incrementally 19

Practice 1: Develop Iteratively Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Practice 1: Develop Iteratively Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 20

Waterfall Development Characteristics n Measures progress by assessing work-products that are poor predictors of Waterfall Development Characteristics n Measures progress by assessing work-products that are poor predictors of time-to-completion. n Planning Delays confirmation of critical risk resolution. n Waterfall Process Delays and aggregates integration and testing. n Precludes early deployment. n Frequently results in major unplanned iterations. Requirements Analysis Design Code and Test Subsystem Integration System Test 21

Iterative Development Characteristics n Resolves major risks before making large investments. n Enables early Iterative Development Characteristics n Resolves major risks before making large investments. n Enables early user feedback. n Makes testing and integration continuous. n Focuses project short-term objective milestones. n Makes possible deployment of partial implementations. Iteration 1 Iteration 2 P Iteration 3 P R D R D C I C I T T T I M E 22

Develop Iteratively n Iterative development produces an executable 3. 1. Initial Planning Requireme 4. Develop Iteratively n Iterative development produces an executable 3. 1. Initial Planning Requireme 4. Analysis & Design nts 2. Planning 5. Implementation Management Environment (on-going) 6. Test 8. Evaluation 7. Deployment Each iteration results in an executable release 23

Risk Profiles Risk Waterfall Risk Reduction Iterative Risk Time 24 Risk Profiles Risk Waterfall Risk Reduction Iterative Risk Time 24

Practice 2: Manage Requirements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Practice 2: Manage Requirements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 25

Managing Requirements n Ensures that you solve the right problem ¨ build the right Managing Requirements n Ensures that you solve the right problem ¨ build the right system ¨ n by taking a systematic approach to Understanding the problem. ¨ Eliciting, organizing, and documenting the requirements. ¨ Managing the changing requirements of a software application. ¨ 26

Practice 3: Use Component Architectures Best Practices Process Made Practical Develop Iteratively Manage Requirements Practice 3: Use Component Architectures Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 27

Use Component Architectures n Software architecture needs to be: Component-based ¨ Reuse or customize Use Component Architectures n Software architecture needs to be: Component-based ¨ Reuse or customize components ¨ Select from commercially available components ¨ Evolve existing software incrementally Resilient ¨ Meets current and future requirements ¨ Improves extensibility ¨ Enables reuse ¨ Encapsulates system dependencies 28

Purpose of a Component-Based Architecture n Basis for reuse Component ¨ Architecture ¨ n Purpose of a Component-Based Architecture n Basis for reuse Component ¨ Architecture ¨ n Component-based architecture with layers Basis for project management Planning ¨ Staffing ¨ Delivery ¨ n Intellectual control Manage complexity ¨ Maintain integrity ¨ Applicationspecific Businessspecific Middleware Systemsoftware 29

Practice 4: Model Visually (UML) Best Practices Process Made Practical Develop Iteratively Manage Requirements Practice 4: Model Visually (UML) Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 30

Model Visually (UML) n Captures structure and behavior n Shows how system elements fit Model Visually (UML) n Captures structure and behavior n Shows how system elements fit together n Keeps design and implementation consistent n Hides or exposes details as appropriate n Promotes unambiguous communication ¨ The UML provides one language for all practitioners. 31

Visual Modeling with the Unified Modeling Language Multiple views Precise syntax and semantics Sequence Visual Modeling with the Unified Modeling Language Multiple views Precise syntax and semantics Sequence Diagrams Use-Case Diagrams Communication Diagrams Dynamic Diagrams State Machine Diagrams Models Activity Diagrams Static Diagrams Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams 32

Activity Diagram – Lược đồ hoạt động n Activity diagrams được dùng để miêu Activity Diagram – Lược đồ hoạt động n Activity diagrams được dùng để miêu tả dòng công việc n Ví dụ: Một lược đồ hoạt động trình bày một quy trình nghiệp vụ đơn giản để xuất hóa đơn và thanh toán 33 33

Use Case Diagram <<include>> A Use Case Generalization Actor <<extend>> a 1 B 34 Use Case Diagram <> A Use Case Generalization Actor <> a 1 B 34 34

Class Diagram Order date. Received is. Prepaid number : String price : Money Customer Class Diagram Order date. Received is. Prepaid number : String price : Money Customer name address 0. . n 1 credit. Rating() dispatch() close() 1 {if Order. customer. credit. Rating is "poor" then Corporate Customer Order. is. Prepaid must be true} contact. Name credit. Rating credit. Limit Personal Customer credit. Card# remind() bill. For. Month() 0. . n sales rep 0. . 1 Employee 1. . n Order Line quantity : Integer price : Money is. Satisfied : Boolean Product 0. . n 1 35 35

Sequence Diagram – Lược đồ tuần tự 36 36 Sequence Diagram – Lược đồ tuần tự 36 36

Collaboration Diagram – Lược đồ cộng tác 37 37 Collaboration Diagram – Lược đồ cộng tác 37 37

Statechart Diagram – Lược đồ trạng thái 38 38 Statechart Diagram – Lược đồ trạng thái 38 38

Component Diagram – Lược đồ thành phần n Lược đồ thành phần trình bày Component Diagram – Lược đồ thành phần n Lược đồ thành phần trình bày hệ thống được tổ chức thành các thành phần cộng tác với nhau như thế nào; n Các thành phần được xây dựng từ các đối tượng Call Centre Interface Customer Management Order Management Database Management 39 39

Practice 5: Continuously Verify Quality Best Practices Process Made Practical Develop Iteratively Manage Requirements Practice 5: Continuously Verify Quality Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 40

Continuously Verify Quality Software problems are 100 to 1000 times more costly to find Continuously Verify Quality Software problems are 100 to 1000 times more costly to find and repair after deployment Cost w Cost to Repair Software w Cost of Lost Opportunities w Cost of Lost Customers Inception Elaboration Construction Transition 41

Test Dimensions of Quality Usability Test the application from the perspective of convenience to Test Dimensions of Quality Usability Test the application from the perspective of convenience to end Reliability Functionality -user. Test the accurate Test the application workings of each for consistent and usage scenario. predictable behavior. Supportability Test the ability to maintain and support the application under production use. Performance Test online response under average and peak loading. 42

Test Each Iteration 1 Iteration 2 Iteration 3 Iteration 4 Test Suite 1 Test Test Each Iteration 1 Iteration 2 Iteration 3 Iteration 4 Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 UML Model and Implementation Tests 43

Practice 6: Manage Change Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Practice 6: Manage Change Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 44

Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. New Feature Single Channel for Approval Approved Decision Process Change Control Board (CCB) New Requirement Bug Change Request (CR) Customer and User input Reqt Design Code Test Marketing Coders input Testers input Help Desk User input Maint Weinberg, ‘ 95 45

Manage Change n To avoid confusion, have: Secure workspaces for each developer ¨ Automated Manage Change n To avoid confusion, have: Secure workspaces for each developer ¨ Automated integration/build management ¨ Parallel development ¨ Workspace Management Configuration Management is more than just check-in and check-out Process Integration Parallel Development Build Managem ent 46

Manage Change (continued) n Unified Change Management (UCM) involves: ¨ Management across the lifecycle Manage Change (continued) n Unified Change Management (UCM) involves: ¨ Management across the lifecycle n n ¨ Activity-based management n n n ¨ System Project management Tasks Defects Enhancements Progress tracking n n Charts Reports 47

Rational Unified Process Implements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Rational Unified Process Implements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 48

Achieving Best Practices n Iterative approach n Guidance for activities and artifacts n Process Achieving Best Practices n Iterative approach n Guidance for activities and artifacts n Process focus on architecture n Use cases that drive design and implementation n Models that abstract the system 49

A Team-Based Definition of Process A process defines Who is doing What, When, and A Team-Based Definition of Process A process defines Who is doing What, When, and How, in order to reach a certain goal. New or changed requirements Software Engineering Process New or changed system 50

Process Structure - Lifecycle Phases n The Rational Unified Process has four phases: Inception Process Structure - Lifecycle Phases n The Rational Unified Process has four phases: Inception – Define the scope of the project ¨ Elaboration – Plan the project; specify features and baseline architecture ¨ Construction – Build the product ¨ Transition – Transition the product into the end-user community ¨ Inception Elaboration Construction Transition Time 51

Bringing It All Together: The Iterative Approach In an iteration, you walk through all Bringing It All Together: The Iterative Approach In an iteration, you walk through all disciplines. Disciplines group activities logically. 52

Summary n Best Practices guide software engineering by addressing root causes. n Best Practices Summary n Best Practices guide software engineering by addressing root causes. n Best Practices reinforce each other. n Process guides a team on who does what, when, and how. n The Rational Unified Process is a means of achieving Best Practices. 53