Embed Size (px)
Citation preview
ISYS 200 Week #1 1
Systems Analysis IIntroduction and Fundamentals
ISYS 200
Glenn Booker
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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?
ISYS 200 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
1. Meets user’s and the organization’s needs, and 2. Is developed on time and within budget
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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)
ISYS 200 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
ISYS 200 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.)
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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?
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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)
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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.)
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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.)
ISYS 200 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, … )
ISYS 200 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
ISYS 200 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’
ISYS 200 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
ISYS 200 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
ISYS 200 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?
ISYS 200 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
ISYS 200 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?
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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
ISYS 200 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?
ISYS 200 Week #1 51
Entity-Relationship Model
The Entity-Relationship Model will be refined later to show the data structure for our system
For now, we can use the same notation to indicate early results of system analysis
Each entity represents some key concept related to your system – a user, event, thing, etc. that you want to keep information about Transient or temporary data aren’t kept in entities
ISYS 200 Week #1 52
Entity-Relationship Model
A line between entities is labeled with verb phrases to identify what kind of relationship exists between those entities Employee ‘is assigned to’ Office Passenger ‘is flying to’ Destination
The ends of the line are marked to show the “cardinality” – how many of one thing could be associated with the other?
ISYS 200 Week #1 53
Cardinality and Relationships
To determine the cardinality shown, ask “for one example of entity A, how many possible entries could exist in entity B?”
Consider extreme cases; a Customer may have zero Orders briefly, before their first order is completed
A B
ISYS 200 Week #1 54
Cardinality and Relationships
Relationships are described by how many records of each entity may be related: 0 (shown by a ‘0’), 1 (shown with a single or double line), or many (shown by a trident)
• Here we are using the Martin notation; many others exist
Cardinality of zero implies the relationship is optional in that direction
One-to-one is a unique relationship
ISYS 200 Week #1 55
Cardinality and Relationships
Cardinality conveys the minimum and maximum number of relationships, and must be defined in both directions for all relationships: Only one Zero or one One or many (more) Zero, (one), or many Many (only >1)
ISYS 200 Week #1 56
Associative Entity
In discussion, cardinality is often abbreviated to “one to one”, “one to many”, or “many to many”
“Many to many” relationships are bad; break them up with an associative entity
An associative entity is an entity that shares traits from two other entities, because it is associated with both of them
ISYS 200 Week #1 57
Associative Entity
The example in the text (p. 37) is breaking up Patron – Concert
With the associative entity Reservation, to become Patron – Reservation – Concert
Another example is Employee – Employer Becomes Employee – Contract – Employer
ISYS 200 Week #1 58
Associative Entity
An associative entity must also have some characteristics which are unique to it (e.g. data)
The symbol for an associative entity has a diamond in it
