Bài giảng Hệ thống thông tin - Chương 1: Tổng quan về hệ thống tin

1TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN 22 TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN  Khái niệm cơ bản về hệ thống (System)  Tổ chức (Organization)  Dữ liệu (Data) và thông tin (information)  Thông tin và các mức ra quyết định quản lý (Management decision making)  Định nghĩa hệ thống thông tin (Information Systems)  Phân loạI IS  Các IS phân loại theo mức quản lý tổ chức. 33 System A Subsystem B Subsystem C Subsystem E Subsystem D BoundaryInterface Environment of System A 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) 44 Tổ chức (Organization)  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 HRI Purchasing Training Môi trường hoạt động của tổ chức 55 Dữ liệu và thông tin  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, ...  Thông tin (information): “Information is data that have been processed in such a way as to be useful to the recipient.” (Lucey)  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 66 Information Systems (IS)  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.  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, 77 Hệ thống thông tin tự động hóa  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 88  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 Anthony’s Pyramid: cấu trúc quản lý của tổ chức Operational Tactical Strategic Large time horizon Small time horizon Summary data Detail data Unstructured problems Structured problems Thông tin và các cấp quản lý 99 Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Insurance SystemsLeisure Industry 1010 Real-Time Systems Automated Production Control Control Systems Security Systems 1111 Management Information Systems 0 10 20 30 40 50 60 70 80 90 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr East West North Decision Support Systems Office Automation Systems Knowledge Based Systems Executive Information Systems 12 Best Practices of Software Engineering 13 Objectives: Best Practices  Identify symptoms of software development problems.  Explain the Best Practices.  Present the Rational Unified Process (RUP) within the context of the Best Practices. 1414 Mục đích của công nghệ phần mềm  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  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)  1515 Bản chất việc phát triển phần mềm  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ề”  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. 1616 Con người liên quan (Stakeholders)  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.  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” 17 Symptoms of Software Development Problems  User or business needs not met  Requirements not addressed  Modules not integrating  Difficulties with maintenance  Late discovery of flaws  Poor quality of end-user experience  Poor performance under load  No coordinated team effort  Build-and-release issues 18 Trace Symptoms to Root Causes Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Symptoms Root Causes Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Model Visually (UML) Continuously Verify Quality l ot fit 19 Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally Ensures users are involved as requirements evolve 20 Practice 1: Develop Iteratively Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 21 Waterfall Development Characteristics  Delays confirmation of critical risk resolution.  Measures progress by assessing work-products that are poor predictors of time-to-completion.  Delays and aggregates integration and testing.  Precludes early deployment.  Frequently results in major unplanned iterations. Code and Test Design Subsystem Integration System Test Waterfall Process Requirements Analysis Planning 22 Iterative Development Characteristics  Resolves major risks before making large investments.  Enables early user feedback.  Makes testing and integration continuous.  Focuses project short-term objective milestones.  Makes possible deployment of partial implementations. T I M E Iteration 1 Iteration 2 Iteration 3 P R D C I T P R D C I T P R D C I T 23 Develop Iteratively  Iterative development produces an executable 1. Initial Planning 2. Planning 3. Requirements 4. Analysis & Design 5. Implementation 7. Deployment 6. Test 8. Evaluation Management Environment (on-going) Each iteration results in an executable release 24 Risk Profiles Time R is k Waterfall Risk Iterative Risk Risk Reduction 25 Practice 2: Manage Requirements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 26 Managing Requirements  Ensures that you  solve the right problem  build the right system  by taking a systematic approach to  Understanding the problem.  Eliciting, organizing, and documenting the requirements.  Managing the changing requirements of a software application. 27 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 28 Use Component Architectures  Software architecture needs to be: Component-based Resilient  Reuse or customize components  Select from commercially available components  Evolve existing software incrementally  Meets current and future requirements  Improves extensibility  Enables reuse  Encapsulates system dependencies 29 Purpose of a Component-Based Architecture  Basis for reuse  Component  Architecture  Basis for project management  Planning  Staffing  Delivery  Intellectual control  Manage complexity  Maintain integrity System- software Middleware Business- specific Application- specific Component-based architecture with layers 30 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 31 Model Visually (UML)  Captures structure and behavior  Shows how system elements fit together  Keeps design and implementation consistent  Hides or exposes details as appropriate  Promotes unambiguous communication  The UML provides one language for all practitioners. 32 Visual Modeling with the Unified Modeling Language Dynamic Diagrams Multiple views Precise syntax and semantics Activity Diagrams Models Static Diagrams Sequence Diagrams Communication Diagrams State Machine Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class DiagramsUse-Case Diagrams 3333 Activity Diagram – Lược đồ hoạt động  Activity diagrams được dùng để miêu tả dòng công việc  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 Print Invoice Send Invoice Wait For Payment Process Payment 3434 Use Case Diagram Use Case Actor Use Case Diagram B > A > a1 Generalization 3535 Class Diagram Personal Customer creditCard# Customer name address creditRating() {if Order.customer.creditRating is "poor" then Order.isPrepaid must be true} Employee Corporate Customer contactName creditRating creditLimit remind() billForMonth() 0..1 0..n sales rep Order dateReceived isPrepaid number : String price : Money dispatch() close() 10..n Product Order Line quantity : Integer price : Money isSatisfied : Boolean 1..n 1 10..n 3636 Sequence Diagram – Lược đồ tuần tự Order Entry window Order O rder Line St ock It em Reorder Item Delivery Item prepare() *prepare() hasStock:= chec k() [has St ock] rem ove() needsReorder:= needsToReorder() [needsReorder] new [hasStock] new X 3737 Collaboration Diagram – Lược đồ cộng tác aReorderItem : Reorder Item :O rder Entry W indow anOrder : Order anOrderLine : Order Line aDelivery Item : Delivery Item aStockItem : Stock Item 5: needsReorder := needToReorder() 1: prepare() 2: * [for al l ord er lines] : prepare() 7: [ hasStock]: new 3: hasStock := check 4: [hasStock]: remove() 6: [needsReorder]:new 3838 Statechart Diagram – Lược đồ trạng thái Cancelled [All items checked && all items available] D elive red [A ll items checked && some items not in stock] Item rec eived [S om e i tems not in s t ock] Item rece ived [al l it em s available] Cancel led Check ing do/ check item W aiting Disp atching do/ initiate delivery Cancelled [Not all items checked /get next item 3939 Component Diagram – Lược đồ thành phầ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;  Các thành phần được xây dựng từ các đối tượng Call Centre Interface Order Management Customer Management Database Management 40 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 41 Continuously Verify Quality Cost TransitionConstructionElaborationInception  Cost to Repair Software  Cost of Lost Opportunities  Cost of Lost Customers Software problems are 100 to 1000 times more costly to find and repair after deployment 42 Test Dimensions of Quality Reliability Test the application for consistent and predictable behavior. Performance Test online response under average and peak loading. Functionality Test the accurate workings of each usage scenario. Usability Test the application from the perspective of convenience to end-user. Supportability Test the ability to maintain and support the application under production use. 43 UML Model and Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 3 Test Suite 3 Test Each Iteration Test Suite 4 Iteration 4 44 Practice 6: Manage Change Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 45 Change requests come from many sources throughout the product lifecycle. Change Request Management Concepts Help Desk User input Coders input Testers input Customer and User input Marketing New Feature New Requirement Bug Approved Decision Process Change Control Board (CCB) Single Channel for Approval Change Request (CR) Reqt Design Code Test Maint Weinberg, ‘95 46 Workspace Management Process Integration Parallel Development Build Management Configuration Management is more than just check-in and check-out Manage Change  To avoid confusion, have:  Secure workspaces for each developer  Automated integration/build management  Parallel development 47 Manage Change (continued)  Unified Change Management (UCM) involves:  Management across the lifecycle  System  Project management  Activity-based management  Tasks  Defects  Enhancements  Progress tracking  Charts  Reports 48 Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Rational Unified Process Implements Best Practices Best Practices Process Made Practical 49 Achieving Best Practices  Iterative approach  Guidance for activities and artifacts  Process focus on architecture  Use cases that drive design and implementation  Models that abstract the system 50 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 New or changed system Software Engineering Process 51 Process Structure - Lifecycle Phases  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 52 Bringing It All Together: The Iterative Approach Disciplines group activities logically. In an iteration, you walk through all disciplines. 53 Summary  Best Practices guide software engineering by addressing root causes.  Best Practices reinforce each other.  Process guides a team on who does what, when, and how.  The Rational Unified Process is a means of achieving Best Practices.