1. INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN 1

2. Information System 2

3. What Is An Information System? 3  An information system is a collection of interrelated components that collect, process, store, and provide as output the information needed to complete a business task.

4. Examples of Information Systems 4  Course registration system  Online order system  Online banking system

5. Why Are Information Systems Important? 5  Support business functions in modern business organizations  Make business more competitive  Enhance productivity and profits

6. Types of Information Systems 6  Customer Relationship Management (CRM)  Supply Chain Management (SCM)  Accounting and Financial Management (AFM)  Human Resource Management (HRM)  Manufacturing Management  Knowledge Management (KM)  Collaboration Support Systems (CSS)  Business Intelligence System

7. 7 Information Systems and Component Parts

8. System Analysis 8

9. What Is System Analysis About? 9  Understanding the goals and strategies of the business.  Defining the information requirements that support those goals and strategies.  It is not about programming.

10. System Analysis Vs. System Design 10  Systems analysis is a process of understanding in detail what a system should accomplish.  Systems design is a process of specifying in detail how components of an information system should be physically implemented.

11. System Analyst 11  A business professional who uses analysis and design techniques to solve business problems using information technology.

12. The Role of a System Analyst  Investigate, analyze, design, develop, installs, evaluate, and maintains a company’s information systems.  A business problem solver  The solution to the “problem” is generally a new information system  Help translate business requirements into IT projects. 12

13. Typical Problems System Analyst Typically Solve 13  Customers want to order product anytime of the day.  Suppliers want to minimize inventory holding costs.  Marketing want to know customer needs better.  Management want to analyzing financial information more efficiently.

14. The Analyst as a Business Problem Solver 14  Has computer technology knowledge and programming expertise  Understands business problems  Uses logical methods for solving problems  Has fundamental curiosity  Wants to make things better  Is more of a business problem solver than a technical programmer

15. What is your problem solving approach? 15  Assume that you are deciding whether to buy a new laptop to replace the old one.

16. Analyst’s Approach to Problem Solving 16 1.Research and understand the problem 2.Verify benefits of solving problem outweigh the costs 3.Define the requirements for solving the problem 4.Develop a set of possible solutions (alternatives) 5.Decide which solution is best and recommend 6.Define the details of the chosen solution 7.Implement the solution 8.Monitor to ensure desired results

17. Required Skills of the Systems Analyst 17 1. Technical 2. Business 3. People

18. 1-Technical Knowledge and Skills 18  Computers / peripheral devices (hardware)  Communication networks and connectivity  Database and database management systems (DBMS)  Programming languages (for example, VB.NET or Java)  Operating systems and utilities

19. 1-Technical Knowledge and Skills – Tools 19  Software productivity packages  Integrated development environments (IDEs) for programming languages  CASE tools, testing, documentation support, reverse engineering, configuration management

20. 1- Technical Knowledge and Skills – Techniques 20  Project planning, systems analysis  Systems design, database design, network design  Construction, implementation, systems support

21. 2- Business Knowledge and Skills 21  Business functions performed by organization  Strategies, plans, traditions, and values of the organization  Organizational structure  Organization management techniques  Functional work processes

22. 3- People Knowledge and Skills 22  Systems analysts need to understand how people  Think  Learn  React to change  Communicate  Work (in a variety of jobs and levels)

23. 3- People Knowledge and Skills ( continued ) 23  Interpersonal and communication skills are crucial to  Obtaining information  Motivating people  Getting cooperation  Understanding the complexity and workings of an organization in order to provide necessary support

24. Hard and Soft Skills 24  Hard skills are the skills in technical areas such as database design, programming, and telecommunication.  Soft skills are the skills in nontechnical areas such as interviewing, team management, and leadership.

25. Integrity and Ethics 25  Analyst has access to confidential information, such as salary, an organization’s planned projects, security systems, and so on.  Must keep information private  Any impropriety can ruin an analyst’s career  Analyst plans security in systems to protect confidential information

26. Analyst-Related Careers 26  ERP software related  Business Analysts in different business functions  Auditing, compliance, and security  Web Development

27. System Development 27

28. The Systems Development Lifecycle 28  SDLC provides overall framework for managing systems development process.  Two main approaches to SDLC  Predictive approach – assumes project can be planned out in advance  Adaptive approach – more flexible, assumes project cannot be planned out in advance  All projects use some variation of SDLC

29. 29 Choosing the Predictive vs. Adaptive Approach to the SDLC

30. Traditional Predictive Approach to the SDLC 30  Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project  Analysis – understand business needs and processing requirements  Design – define solution system based on requirements and analysis decisions  Implementation – construct, test, train users, and install new system  Support – keep system running and improve

31. 31 Information System Development Phases

32. SDLC and Problem Solving 32  Organization recognizes problem (project planning)  Project team investigates, understands problem and solution requirements (analysis)  Solution is specified in detail (design)  System that solves problem is built and installed (implementation)  System used, maintained, and enhanced to continue to provide intended benefits (support)

33. Waterfall Model 33  Waterfall model is an SDLC approach that assumes the various phases of a project can be completed sequentially – one phase leads into the next phase.

34. 34 “Waterfall” Approach to the SDLC

35. 35 Modified Waterfall Approach with Overlapping Phases

36. Newer Adaptive Approaches to the SDLC 36  Based on spiral model  Project cycles through development activities over and over until project is complete  Prototype created by end of each cycle  Focuses on mitigating risk  Iteration – Work activities are repeated  Each iteration refines previous result  Approach assumes no one gets it right the first time  There are a series of mini projects for each iteration

37. 37 The Spiral Life Cycle Model

38. Activities of Each SDLC Phase 38  Predictive or adaptive approach use SDLC  Activities of each “phase” are similar  Phases are not always sequential  Phases can overlap

39. Activities of Planning Phase of SDLC 39  Define business problem and scope  Produce detailed project schedule  Confirm project feasibility  Economic, organizational, technical, resource, and schedule  Staff the project (resource management)  Launch project  official announcement

40. Activities of Analysis Phase of SDLC 40  Gather information to learn problem domain  Define system requirements  Build prototypes for discovery of requirements  Prioritize requirements  Generate and evaluate alternatives  Review recommendations with management

41. Activities of Design Phase of SDLC 41  Design and integrate the network  Design the application architecture  Design the user interfaces  Design the system interfaces  Design and integrate the database  Prototype for design details  Design and integrate system controls

42. Activities of Implementation Phase of SDLC 42  Construct software components  Verify and test  Convert data  Train users and document the system  Install the system

43. Activities of Support Phase of SDLC 43  Maintain system  Small patches, repairs, and updates  Enhance system  Small upgrades or enhancements to expand system capabilities  Larger enhancements may require separate development project  Support users  Help desk and/or support team

44. Approaches to System Development 44

45. Two Approaches to System Development 45  Traditional (Structured) approach  Also called structured system development  Structured analysis and design technique (SADT)  Includes information engineering (IE)  Object-oriented approach  Also called OOA, OOD, and OOP  Views information system as collection of interacting objects that work together to accomplish tasks

46. 1- Traditional (Structured) approach 46

47. Structured System Development 47  Structure Programming  Top-down Programming  Structured Design  Structured Analysis

48. Structured Programming 48  Improves computer program quality  Allows other programmers to easily read and modify code  Each program module has one beginning and one ending  Three programming constructs (sequence, decision, repetition)

49. 49 Three Structured Programming Constructs

50. Top-Down Programming 50  Divides complex programs into hierarchy of modules  The module at top controls execution by “calling” lower level modules  Modular programming  Similar to top-down programming  One program calls other programs to work together as single system

51. 51 Top-Down or Modular Programming

52. Structured Design 52  What the set of programs should be  What each program should accomplish  How the programs should be organized into a hierarchy

53. Main Principles of Structured Design 53  Loosely coupled – module is independent of other modules  Highly cohesive – module has one clear task

54. 54 Structure Chart Created Using Structured Design Technique

55. Structured Analysis 55  Define what system needs to do (processing requirements)  Define data system needs to store and use (data requirements)  Define inputs and outputs  Define how functions work together to accomplish tasks  Data flow diagrams (DFD) and entity relationship diagrams (ERD) show results of structured analysis

56. 56 Data Flow Diagram (DFD)

57. 57 Entity-Relationship Diagram (ERD)

58. 58 Framework of Structured Development

59. Information Engineering (IE) 59  Refinement to structured development  Methodology with strategic planning, data modeling, automated tools focus  More rigorous and complete than SADT  Industry merged key concepts from structured development and information engineering approaches into traditional approach

60. 2- Object Oriented Approach 60

61. Object-Oriented Approach 61  Completely different approach to information systems  Views information system as collection of interacting objects that work together to accomplish tasks  Objects – things in computer system that can respond to messages  Conceptually, no processes, programs, data entities, or files are defined – just objects  OO languages: Java, C++, C#.NET, VB.NET

62. Object-oriented Analysis and design (OOAD)  OOAD essential for creating well-designed, & maintainable software system using  All Software Analysis and Design is preceded by the analysis of requirements. 62

63. Terminologies of O-O Approach 63  Object-oriented analysis (OOA)  Object-oriented design (OOD)  Object-oriented programming (OOP)

64. OOA - OOD - OOP Analysis Design Implementation “Baseball Model” 64

65. Object-oriented analysis (OOA) 65  Defines types of objects users deal with  Shows use cases are required to complete tasks  How to get understanding of what we want to build investigation of the problem (rather than how a solution is defined)  During OOD, there is an emphasis on finding and describing the objects (or concepts) in the problem domain.  For example, concepts in a Library Information System include: Book, and Catalog.

66. 66 Class Diagram Created During OO Analysis

67. Ex: Use Case (Analysis)  Start from requirements  Describe response of system to events – Normal flow of action – Error and exception handling  Can implement tests to check use cases  Can be quite formal – UML diagrams 67

68. Use Case Summary  Create use cases from requirements – Response of system to events – Normal and errors/exceptions  Leads to tests – Map use cases to tests  Use cases are not designs – That's how you manage to satisfy the tests derived from use cases 68

69. Object-oriented design (OOD) 69  Defines object types needed to communicate with people and devices in system  Shows how objects interact to complete tasks  Refines each type of object for implementation with specific language of environment  UML is used in this phase

70. OOD:Object Oriented Design Emphasizes a conceptual solution that fulfils the requirements specified in the analysis. Need to define software objects and how they collaborate to fulfill the requirements. For example, in the Library Information System, a Book object may have a title attribute and a display() method. Designs are implemented in a programming language. In the example, we will have a Book class in Java. 70

71. Analysis vs. Design –Discovery - Invention –What? - How? –Physical - Logical 71

72. Object-oriented programming (OOP) 72  Writing statements in programming language to define what each type of object does  OO Programming Language (e.g. C++, Java, smalltalk, …)

73. OOP: Object-Oriented Programming During Implementation, or Object-Oriented Programming, design objects are implemented, such as a book class in Java. Implementation is also known as Coding or Construction. 73

74. Objects  concepts, concrete or abstract, with meaning derived from the problem domain “the real world”  provide a basis for implementation  encapsulation of state (data values) and behavior (operations) 74

75. Objects (cont.)  Exhibit behavior by invoking a method in response to a message  instances of classes  an object-oriented program is a collection of autonomous interacting and collaborating objects 75

76. Classes  objects sharing common characteristics  dictate the behavior of the object  contain  state: attributes, fields, variables, data member  behavior: functions, methods, function member 76

77. 3 Pillars of Object-Orientation  encapsulation  inheritance  polymorphism 77

78. Encapsulation  combination of state and behavior  implementation details are hidden internally  internal mechanisms can change while public interfaces remain stable  state may be retrieved using public methods  behavior consists of methods activated by receipt of messages 78

79. Inheritance  organization of classes into a hierarchical inheritance tree  data and behavior associated with classes higher in the tree are accessible to those classes lower in the tree  terminology  ancestor/descendant  superclass/subclass  generalization/specialization 79

80. Another Inheritance Diagram 80

81. Polymorphism  polymorphism: many forms  localizes responsibility for behavior  object automatically uses correct implementation for a method  many objects can respond to the same message  minimizes interface parameter passing 81

82. Polymorphism  treat many types (all derived from the same type) as if they were all one type  single piece of interface works on all these types 82

83. Polymorphism Example 83