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

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

2. 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. 2

3. 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 C Subsystem B Subsystem E Subsystem D Environment of System A Boundary Interface 3

4. 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 Training HRI Purchasing Môi trường hoạt động của tổ chức 4

5. 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 5

6. 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, … 6

7. 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 7

8. 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 Thông tin và các cấp quản lý Large time horizon Summary data Unstructured 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

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

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

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

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.

14. 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) … 14

15. 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. 15

16. 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” 16

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

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

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. 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. Waterfall Process Planning Requirements Analysis Design Code and Test Subsystem Integration System Test Waterfall Development Characteristics

22. P P P R R R D D D C C C I I I T T T 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. Iteration 1 Iteration 2 Iteration 3 T I M E

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

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

25. Practice 2: Manage Requirements Best Practices Process Made Practical DevelopIteratively 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 DevelopIteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

28. Use Component Architectures • Software architecture needs to be:

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 Component-based architecture with layers Application- specific Business- specific Middleware System- software

30. Practice 4: Model Visually (UML) Best Practices Process Made Practical DevelopIteratively 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. Static Diagrams Class Diagrams Use-Case Diagrams Object Diagrams Sequence Diagrams Component Diagrams Communication Diagrams Models Deployment Diagrams State Machine Diagrams Activity Diagrams Visual Modeling with the Unified Modeling Language Multiple views Precise syntax and semantics Dynamic Diagrams

33. 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 33

34. Use Case Diagram Use Case Diagram <<include>> A Use Case Generalization <<extend>> Actor a1 B 34

35. Class Diagram Order dateReceived Customer isPrepaid name number : String address price : Money 0..n 0..n 1 1 creditRating() dispatch() close() 1 1 {if Order.customer.creditRating is "poor" then Corporate Customer Order.isPrepaid Personal Customer must be true} contactName creditCard# creditRating creditLimit remind() billForMonth() 0..n 0..n 0..1 0..1 sales rep Employee 1..n 1..n Order Line quantity : Integer Product price : Money 0..n 0..n isSatisfied : Boolean 1 1 35

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

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

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

39. 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 Customer Order Management Management Database Management 39

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

41. Continuously Verify Quality Software problems are100 to 1000 times more costlyto find and repair after deployment • Cost to Repair Software • Cost of Lost Opportunities • Cost of Lost Customers Cost Inception Elaboration Construction Transition

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

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

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

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

46. Workspace Management Configuration Management is more than just check-in and check-out Process Integration Parallel Development Build Management 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. Rational Unified Process Implements Best Practices Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

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 orderto reach a certain goal. New or changed requirements New or changed system Software Engineering Process