Introduction to Information Systems Analysis Foundations and Building Blocks

1. Introduction to InformationSystems AnalysisFoundations and Building Blocks INFO 503 Glenn Booker Lecture #1

2. Syllabus • This class focuses on understanding the ways in which the concept for a product can be turned into requirements and a design • Best to reach me by e-mail; phone if urgent • Will cover most of textbook; will not cover object-oriented methods since that’s a very different approach (see INFO 620) • Yes, the text is quite repetitive Lecture #1

3. Syllabus • All course materials are on my web sitehttp://users.snip.net/~gbooker/ • Be sure to read the General Course Information and Document Review Notes (http://users.snip.net/~gbooker/general.htm) and (http://users.snip.net/~gbooker/doc-review.doc) Lecture #1

4. Why So Many Military Sources? • They have vast experience with the development and acquisition of complex software and systems • Which was paid for with tax dollars, so… • Many of their lessons learned are freely available! • (Under References, look for SEI, INCOSE, and STSC.) Lecture #1

5. My Biases • DOD and FAA background, so I apologize for the TLA’s (Three Letter Acronyms) • Speak up if I use one you don’t know • Use a Systems Engineering approach; information systems are a special case • Mostly work with long-lived systems, so maintenance issues get extra attention Lecture #1

6. Soundstage Entertainment Club • …is a case study which is followed throughout the textbook • It will not generally be discussed in class • FAST = “Framework for the Application of System Techniques,” (p. 80) is a term for the system analysis and design approach used by the text; it is a condensed version of a typical systems development method Lecture #1

7. Information Systems • Information systems are systems which use computer, database and/or data processing technology to store and analyze data • A systems analyst supports development and maintenance of some system • Development consists of several types of activities, including analysis and design of the system Lecture #1

8. Information System Applications • Information system applications include • Transaction processing systems (TPS) tohandle orders, payments, reservations, or other transactions • Management and executive information systems (MIS & EIS) produce reports to help run the business • Decision support systems (DSS) help make decisions or refine business rules Lecture #1

9. Stakeholders • Stakeholders are the people who affect the development and creation of your system • Note that a given person could fulfill many stakeholder roles, or they may be so far separated that they never meet! Lecture #1

10. Types of Stakeholders • General types of stakeholders include: • System Owners • System Users • System Designers • System Builders • System Analysts • Each of these may include many more specific roles Lecture #1

11. System Owners • The System Owner (a.k.a. sponsor) provides the money for a system to be developed • They generally make the final decisions about the scope and future of the system • Often technically ill informed Lecture #1

12. System Users • The System User (a.k.a. end user) is the person who actually uses the product or system on a day-to-day basis to do their job • Users may be internal (within your organization) or external (outside) • Include support & professional staff, managers, customers, suppliers, andremote users Lecture #1

13. System Users • Often the User (client or customer) is the person who controls the detailed requirements for a system • Warning: The text often assumes the System User knows a lot about the detailed data requirements - may or may not be true • If not, the System Designer must fill in Lecture #1

14. System Designers • System designers are the people who design the system (duh!) • Often includes many technical specialties, such as database administrators, network designers, web architects, graphic artists, security experts, and experts in your business environment (a.k.a. Subject Matter Experts) Lecture #1

15. System Builders • System Builders are the people who create the system designed by the Designers • Includes the most technically specific experts, such as application, systems, and database programmers, network and security administrators, and system integrators Lecture #1

16. System Analysts • Main role is problem solving; to fix an existing system or create a new one • Uses the system development life cycle to manage and control the solution of problems • Helps bridge the gaps among the other stakeholders who affect creation of a system Lecture #1

17. System Development Life Cycle • The System Development Life Cycle (SDLC) is a structured series of activities used to produce a system which is ready for operational or production use • Development is followed by the support or maintenance phase, which is hopefully the longest phase of the system’s life Lecture #1

18. System Development Life Cycle • Any development life cycle generally includes five major activities: • Initiation - to establish the scope of the problem, and develop the strategy and goals for solving the problem • Analysis - to determine the problem’s causes and effects, and determine what requirements are needed p. 37 (p. 10) 6th and (4th) edition Lecture #1

19. System Development Life Cycle • Design - the architecture and structure which the solution should have to solve the problem the best way • Implementation - create the solution, using software tools, source code, hardware, etc. • Support and Improvement - find and fix existing problems in the operational system, and add new features Lecture #1

20. Software Life Cycle • The system development life cycle is similar to the classic Waterfall software development life cycle • Life cycle phases are: concept development, requirements analysis, high and low level design, coding, testing, and implementation • This course mostly covers requirements analysis, high- and low-level design Lecture #1

21. Sequential versus Iterative • System development can be done in one pass through the life cycle (like the waterfall), or an iterative approach can be used • An iterative life cycle defines requirements and high level design, then does design and implement many times, adding more and more to the system each time p. 41 (n/a) Lecture #1

22. Information Systems Architecture • Contains three goal-oriented perspectives • Knowledge improve the Data which is stored or manipulated by the system • Processes improve how people use the system • Communications, which improve the Interfaces with people or other systems, and the effects of Geography on data distribution Lecture #1

23. Information Systems Architecture • These three goals are met by the Builders of the system with three technologies • Database technologies to manage the data • Software technologies to implement the processes • Interface technologies to support communications Lecture #1

24. Information Services • Information services may be located in a centralized organization used throughout a company, or it may be decentralized to support unique needs of each group within an organization • Services may be outsourced - obtained from a third party, or obtained from consultants for each project which needs them Lecture #1

25. Information Services • In extreme cases, a software solution provider may be used to support a massive software implementation (e.g. Oracle, SAP, PeopleSoft, etc.) • Online services may provide business-to-business (B2B) or business-to-consumer (B2C) sales, or may provide product marketing (advertising) Lecture #1

26. Business Process Redesign • Business Process Redesign (BPR) is the deliberate examination of business activities (processes) to reduce costs and make sure every step adds value to the product, whenever possible • Tends to produce radical changes in an organization Lecture #1

27. Continuous Process Improvement • Focuses on making lots of small or incremental changes to business processes in order to keep improving quality, productivity, etc. • Goal is to keep improving process maturity and product quality forever Lecture #1

28. Process Maturity Models • Quality standards and goals are often embodied in process maturity standards, to guide organizations’ process improvement efforts • The primary software standard is the Software Engineering Institute’s (SEI’s) Capability Maturity Model Integration (CMMI) Lecture #1

29. ISO 9000 • The ISO 9000 standards define a quality system which affects most aspects of a business • Focused on manufacturing environment, but also applies to software development • Need ISO 9000 certification for doing business with the European Union Lecture #1

30. Globalization • The Internet has brought global markets even closer together • This affects system requirements such as • Language translation • Character sets to express those languages • Currency exchange (got Euro?) • Environmental aspects such as time zones • Available labor markets Lecture #1

31. Technology Influences • Other technology trends have influenced information systems recently • Placement of seemingly everything on a web page (and the expectation that information system interfaces will be web-based) • Emergence of e-commerce and e-business • Security and privacy concerns • Freedom through wireless networking Lecture #1

32. Refine Stakeholder Perspectives • System Owners determine the scope of the system; including its purpose, vision, goals, objectives, costs, and benefits • May be technologically illiterate • Generally think in terms of development time and money (both development and maintenance costs), and how they are offset by the benefits of the system Lecture #1

33. Refine Stakeholder Perspectives • System Users help determine its requirements; they only care what it does, not how it can do so (as a system user, do you care how a light switch works?) • Help define products and processes for data input, validation, storage, and reporting • Concerned about system interface and ease of use Lecture #1

34. Refine Stakeholder Perspectives • System Designers determine how the system will meet the requirements, including the types of technology to be used, and its high and low level structure • Tend to specialize their expertise: database, software engineering, system integration, networking, process improvement, etc. Lecture #1

35. Refine Stakeholder Perspectives • System Builders create the system by writing code, testing it, and delivering the finished product • This type of activity is not covered by this course, and includes network design, programming, etc. • Changes most quickly with technology Lecture #1

36. p. 64 (49) Building Blocks • Now that the stakeholders have been defined, we look at their relationships to the building blocks of the system: • Knowledge (Data) • Process • Communications (Interface and Geography) Lecture #1

37. Building Blocks • The Geography aspect is downplayed in version 6 of the text • Think of the Geography aspect as the effect of the physical scale of the system (e.g. time zones, internationalization) and networking among parts of a distributed system (how much data do I need to send from site A to site B every day?) Lecture #1

38. Knowledge Building Blocks • The System Owners only care about data in the broadest form of information • Owners want to know the state of business resources, such as money, inventory, sales, facilities, etc. • Owners express their concerns in simple statements about their business model, such as “CUSTOMERS are in SALES REGIONS” Lecture #1

39. Knowledge Building Blocks • System Users want to know how to use the system to perform routine functions, such as placing an order or generating an inventory report • They may know a lot about the data requirements in terms of relationships, including how a legacy system was used and could be improved upon Lecture #1

40. Knowledge Building Blocks • System Designers translate requirements into the files and tables which will be used to capture and manipulate them • This is expressed as a database schema, which may be limited by the type of database tool used (Access, Oracle, DB2, etc.) Lecture #1

41. Knowledge Building Blocks • System Builders write the gory details which make it all happen – in some sort of language (SQL, COBOL, Ada, C+-, Visual Basic, etc.) • Primitive systems had to use flat file technology, such as ISAM or FileMaker Pro, similar to using a spreadsheet Lecture #1

42. Process Building Blocks • System Owners are interested in business functions • Most information systems are function-based, such as finance, personnel, sales, etc. • Recent trends are to blend these systems into one really big system, like ERP (Enterprise Resource Planning) Lecture #1

43. Process Building Blocks • System Users care about their business processes from the most practical perspective: when I get an order over the phone, I click on the Enter Invoice button and fill in the customer information… • These processes are defined in policies, processes, and procedures, which are often defined by higher levels of management Lecture #1

44. Process Building Blocks • System Designers take the business processes, and show how they will be implemented and automated • This results in application schema, which shows how the entire system will work via flowcharts, state diagrams, and/or structure charts Lecture #1

45. Process Building Blocks • System Builders write applications which implement the processes • Applications result from writing source code, compiling it to produce “object” files, and linking the object files to produce an executable application • Prototyping may be used to generate a quick model of the desired application Lecture #1

46. Communications Building Blocks • System Owners are concerned about large scale interfaces: • How does this system relate to other systems in this organization? • How does the customer relate to this system? • How does it relate to external systems? • What are the system’s inputs and outputs? • Are there any legal or regulatory concerns? Lecture #1

47. Communications Building Blocks • System Users are very concerned about the interface to themselves! (A.k.a. the human-computer interface or HCI) • Use of a graphical user interface (GUI) is expected • User interface should follow common standards for “look and feel” Lecture #1

48. Communications Building Blocks • System Designers must bridge the gap between the user interfaces and the system-level interfaces • They plan how the user will be able to navigate in the application • And keep track of what’s currently possible through state transition diagrams (e.g. typing ‘f’ versus ‘Alt–f’) Lecture #1

49. Communications Building Blocks • System Builders create the user interfaces, possibly using a graphical development tool like Visual Basic or PowerBuilder • Middleware, such as ODBC (Open Database Connectivity), is often used for system-level interfaces, such as communicating between database programs Lecture #1

50. Geography Building Blocks • System Owners often think in terms of operating locations • Where is it most effective to operate this system? Labor rates, tax laws, and customs may affect the answer. • How distributed will this system be? • How will sites be affected by this system? Lecture #1