Systems Analysis I Introduction and Fundamentals

1. Systems Analysis IIntroduction and Fundamentals ISYS 200 Glenn Booker Week #1

2. Systems Analysis I • This course is an introduction to the process used to create an information system • Much of it also applies to creating any other kind of software • We’ll focus on the relational model for designing the data structure of a system • In contrast, ISYS 355 uses object-oriented methods • Both are useful approaches Week #1

3. Systems Analysis I • This course provides an overview of many topics which are examined in more detail in subsequent courses • Relational modeling is covered in ISYS 210 • Interface design is covered in ISYS 110 and 310 • Project management is covered in ISYS 420 • Systems analysis starts with the concept for a system, and produces the blueprints to be able to implement it Week #1

4. The Life Cycle • We use one or more life cycle models to help structure the tasks needed to create a system • Key activities we’ll examine include • Determine if system is feasible • Gather information to determine requirements • Model processes with a Data Flow Diagram; and model data with an Entity Relationship Diagram • Design outputs, inputs, and the user interface • Implement the system Week #1

5. Syllabus • Note the office hours; other than that, email is the best way to contact me • Participation isn’t graded per se, but you are responsible for the contents of the lectures, and they will help clarify the assignments Week #1

6. About the Text • We’re skipping five chapters of the text, since 700 pages in ten weeks is a bit much • There’s still a lot of reading, but most of it goes pretty quickly • Be sure to read the text and review the lecture notes before class • You’re responsible for printing the lecture notes after this set  Week #1

7. My Background • Come from 18 years of system analysis, design and maintenance for various government agencies (mostly FAA & DOD) • Teaching for Drexel since 1998 • Predominantly graduate students for the first six years • Have been known to use acronyms, so be sure to stop me if I forget to define one Week #1

8. Industry Focus • Keep in mind that information systems are used to support nearly every industry • Banking, real estate, manufacturing, pharmaceuticals, logistics, retail sales, service fields (auto repair, restaurant, dry cleaner’s, etc.), legal offices, transportation, etc. • Are there any you’re particularly interested in? Week #1

9. Why Bother? • Why do we need information systems? • There’s too much data to reliably track and manage manually • Why bother with analysis and design? • To prevent joining the third of major software projects that fail • By doing analysis and design properly, we will be much more likely to create a system which • Meets user’s and the organization’s needs, and • Is developed on time and within budget Week #1

10. A Bit of Review • The first chapter should be a review of what you covered in ISYS 102 – the types of information systems • From a systems analyst perspective, we might be involved in the development, maintenance, or reengineering of any of these kinds of systems Week #1

11. Types of Systems • From most basic to most complex, we have many types of info systems • Transaction processing systems (TPS) process data for routine business functions – sales, payroll, inventory, etc. • Office automation systems (OAS) manage or organize information • Includes MS Office applications, desktop publishing, scheduling, voice or email, video conferencing Week #1

12. Types of Systems • Knowledge work systems (KWS) are used by various professionals to help them create new knowledge and share it with their organization or profession • Management information systems (MIS) take input from TPS and helps analyze that data to make better decisions • Typically uses models of business processes or rules • Decision support systems (DSS) are more customized systems to help make good decisions Week #1

13. Types of Systems • Artificial intelligence (AI) refers to a set of techniques for creating complex systems, whether they perform mundane tasks or expert tasks • AI also includes natural language processing (NLP), neural networks, and other approaches • Knowledge-based systems (KBS) are AI systems that represent knowledge explicitly • Expert systems are the first KBS methodology; they go beyond DSS to create new rules or select from existing rules to make their own decisions • KBS may use statistical approaches to deal with uncertainty, or apply fuzzy set theory Week #1

14. Types of Systems • Computer-supported collaborative work (CSCW) is a relatively new field to help groups of people work together on a project, whether in the same room or on different continents • Group decision support systems (GDSS) is a subset of CSCW used to focus on group decision-making • Executive support systems (ESS) help top management levels evaluate the overall status of an organization, often drawing from many TPS or MIS Week #1

15. Technologies • All of these types of systems can be supported by various kinds of technology • E-commerce has had a profound influence on the way businesses reach clients • Nothing else has had global impact on marketing at such small cost • Web-based systems are becoming universal • From four computers in 1969, the Internet protocols have provided a common language for almost every computer, and many devices Week #1

16. Technologies • Enterprise resource planning (ERP) systems are designed to integrate what were separate systems (manufacturing, payroll, logistics, etc.) • SAP is a big local player • Oracle just bought PeopleSoft • JD Edwards is also in the field • Wireless networks are common now • Wireless LANs (WLANs), Bluetooth, or generic Wi-Fi (802.11g) Week #1

17. Technologies • Handheld devices (PDAs) are increasingly common too • Blackberry, Palm, etc. • Open source software has emerged in the last decade from a geek oddity to a significant force in the market • GNU and Linux are big players Week #1

18. The Systems Analyst • The role of the systems analyst is part detective, part translator • Detective to seek out the requirements from the various stakeholders and reconcile them • What’s a stakeholder? Why might you need to reconcile requirements? • Translator to translate those requirements into a design which will fulfill them, and be intelligible to the people who implement the system (programmers, etc.) Week #1

19. The Systems Analyst • An analyst might be called on for an objective opinion on a system elsewhere in the organization • Hence keeping current with HW and SW trends and technologies is critical • Implementing or modifying information systems also changes an organization, so the analyst must also plan and support those changes Week #1

20. The SDLC • A Software Development Life Cycle (SDLC) is used to systematically get from a need to an implemented system • How do you solve a big problem? Break it into little problems and solve them • That’s what the SDLC does, by breaking development into life cycle phases • There are many types of life cycles; we’re focusing on a basic ‘waterfall’ model Week #1

21. Typical SDLC Phases • Creating any kind of software system typically involves these phases • Identify problems and opportunities • Determine information requirements • Analyze system needs • Design the system • Develop the system • Test the system • Implement the system Week #1

22. Identify problems and opportunities • Creating an information system is expensive • Therefore, we must prove that doing so is worth our while (and money) • Start by identifying • What problems are there with the current system (whether manual or automated)? Is it slow, expensive, error-prone, …what? • What new features or capabilities could we put in the new system? Week #1

23. Identify problems and opportunities • Based on the problems and opportunities, define objectives for the new system • Estimate the percent improvement in processing speed, market share, data accuracy, etc. • Put the description of problems, opportunities and objectives into a feasibility study • Then some higher manager decides if the project is worth pursuing Week #1

24. Determine information requirements • Then determine the existing information requirements, by studying the users of the existing system, and the system itself • Interviews, data sampling, questionnaires, observation, and prototyping are methods typically used for gathering requirements • People, data, and procedures • Look for ways to improve existing procedures and data Week #1

25. Analyze system needs • Based on the information needs, determine the requirements for your system • Often this phase is combined with the previous • We’ll use a Data Flow Diagram (DFD) to capture the data needs for a system • A data flow diagram shows the types of users of the system, the processes which can be performed, and the types of data needed for each process Week #1

26. Design the system • Then the system is designed to accomplish the processes described in the DFD • This includes • Design of data structure using an entity-relationship diagram (ERD) • Design of the user interface • Design of data entry procedures (won’t cover in class) Week #1

27. Develop the system • Then the analyst supports the programmers and database analysts who develop the system itself • Includes documentation of the code, which is increasingly done automatically by the development environment • Requirements and design may be refined during development Week #1

28. Test the system • The system is tested before being put into production • Unit level testing is done by the programmers • Integration and system testing are often done by a separate testing organization • Independent testers or customers may also perform testing • Maintenance of the system begins here Week #1

29. Implement the system • Implementation is when the system is put into routine use (also called ‘deployed into a production environment’) • Planning for implementation includes choosing a deployment strategy, data conversion and loading (DC&L), and training users and support staff • Now determine if system met its objectives Week #1

30. Maintenance • After the development life cycle, maintenance of the system begins • Maintenance can cost 50% to 200% of the cost of developing a system • Tasks are • Fix bugs in the existing system • Make minor improvements • Update commercial components (OS patches, apply service packs, product upgrades, etc.) Week #1

31. CASE Tools • Computer-Aided Software Engineering (CASE) tools are big, fancy software applications designed to help create other software applications • First used in the mid-80’s, CASE tools help manage the complexity in large scale software development Week #1

32. CASE Tools • Used properly, they can help: • Increase productivity, by automating boring and error-prone tasks (generating diagrams, documenting code) • Improve communication with users, by speeding updates to diagrams, models, and prototypes • Integrate life cycle activities, by providing a common platform for exchanging work products • Help assess maintenance changes, by identifying the impact of changes across the system Week #1

33. CASE Tools • There are upper and lower CASE tools • Upper CASE tools focus on the start of the life cycle – requirements and design of the system • Some help do prototyping too • Lower CASE tools, therefore, focus on the end of the life cycle – coding and testing • Automatic generation of code, and automated testing are key features here Week #1

34. CASE Tools • Some CASE tools can reverse engineer or help reengineer code • Reverse engineering code is to input the source code, and generate the design drawings from it • Is code generation run backwards • Reverse compilation is also possible • Reengineering code often refers to rethinking how business processes work, and restruc-turing how the applications support them Week #1

35. Extreme Programming (XP) • Extreme programming, agile programming, scrum, DSDM, and other variations are used to speed traditional development methods, but keep enough structure to maintain control • XP, for example, features • Short release schedules • A 40-hour work week • Having the customer onsite • Programming by pairs of people Week #1

36. The Systems View • There are two major aspects to what we’re calling ‘the systems view’ • In dealing with the information system, we need to recognize that it consists of much more than just software or a database • It will include • Hardware (the servers and networking equipment it runs on) • Training materials (for users, support staff, etc.) Week #1

37. The Systems View • Documentation, such as • User manual • Installation manual • Work products from development • Feasibility study • Requirements document • Design documents • Implementation plan • Processes used by the development team • Commercial components (e.g. the operating system, database system, … ) Week #1

38. The Systems View • When we create an information system, we create all these things, not just some software • The second perspective is to realize that the organization’s top management doesn’t care about any of the previous components of our system – they think of it in terms of how it helps perform business functions Week #1

39. Organizations as Systems • Organizations typically have three levels of management focus • Strategic – what lines of business are we in? • Middle management – what projects within our line of business do we pursue? • Operations – how can I manage this project well? • Hopefully, all of them are working to achieve common goals or objectives • Usually, the goal is ‘make money’ Week #1

40. Organizations as Systems • The levels of management tend to need different time scales of data from information systems • Strategic – long term trends and competitive information, lots of predictions • Middle management – short and medium term performance information, some historical data • Operations – repetitive, low level data on their project; current and past performance Week #1

41. Organizations as Systems • Each organization is broken into parts (e.g. divisions or departments) to help achieve different functions to meet that goal • Each part, or functional area, might be • Purchasing • Finance • Production • Marketing • Distribution Week #1

42. Organizations as Systems • Information systems typically serve more than one functional area of an organization • Hence to determine the information needs of your system, you first need to identify what areas are affected by it • Who will generate input for your system? • Who will use outputs from your system? Week #1

43. Organizations as Systems • Identify how those areas affect each other • Does output from one area become an input for another area? • Marketing results in production and then distribution • Purchasing provides materials for production • Finance pays for purchasing and marketing Week #1

44. Organizations as Systems • Look for feedback mechanisms to help improve your system • Any process exists to take some input(s) and create some output(s) • What kind of outputs from other systems could influence your system, either as a direct input, or change the rules your system uses? Week #1

45. Organizations as Systems • Look for outside influences on your organization and system • Export laws and tariffs may affect distribution • Production may be limited by labor laws • Finance should comply with accounting practices and tax laws • Marketing might be limited by truth-in-advertising laws, intellectual property rights, and competition Week #1

46. Organizations as Systems • Look for how open your system’s organization is • Is information encouraged to flow freely? • Are there a lot of approvals and checks & balances? • Who is allowed to communicate with whom? • Trouble is, everyone tends to think their organization is the most important one Week #1

47. Virtual Organizations • Organizations don’t have to be physically located together • If not, they are a virtual organization • Could save money on facilities or travel • Social aspects are unclear • Harder to form identity with a virtual team Week #1

48. Context Diagram • The context diagram (called in the text a ‘context-level data flow diagram’) is the highest level view of the data needs for a system • At its center is a rounded box which represents your entire system • Around that box are square boxes representing • 1) The types of users of your system, and • 2) External systems with which your system interacts Week #1

49. Context Diagram • Show only users who interact directly with your system • Lines between your system and the other boxes are labeled to identify the types of data which flow between them • If data flow goes both directions, use separate lines for each direction to distinguish inputs from outputs • Example on page 33, figure 2.5 Week #1

50. Context Diagram • The context diagram is also handy for defining system requirements • Consider each type of user or external system separately, and ask: • What kind of inputs and outputs would they want from this system? • What kind of processes would they expect to be able to perform? Week #1