Systems Analysis I Introduction and Fundamentals

1
Systems Analysis IIntroduction and Fundamentals

• ISYS 200
• Glenn Booker

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
• Well 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

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

4
The Life Cycle

• We use one or more life cycle models to help
  structure the tasks needed to create a system
• Key activities well 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

5
Syllabus

• Note the office hours other than that, email is
  the best way to contact me
• Participation isnt graded per se, but you are
  responsible for the contents of the lectures, and
  they will help clarify the assignments

6
About the Text

• Were skipping five chapters of the text, since
  700 pages in ten weeks is a bit much
• Theres 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
• Youre responsible for printing the lecture notes
  after this set ?

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

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 cleaners,
  etc.), legal offices, transportation, etc.
• Are there any youre particularly interested in?

9
Why Bother?

• Why do we need information systems?
• Theres 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 users and the organizations needs, and
• Is developed on time and within budget

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

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

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

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

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

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

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)

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

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
• Whats 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.)

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

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
• Thats what the SDLC does, by breaking
  development into life cycle phases
• There are many types of life cycles were
  focusing on a basic waterfall model

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

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?

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

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

25
Analyze system needs

• Based on the information needs, determine the
  requirements for your system
• Often this phase is combined with the previous
• Well 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

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 (wont cover in
  class)

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

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

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
  (DCL), and training users and support staff
• Now determine if system met its objectives

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

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-80s, CASE tools help
  manage the complexity in large scale software
  development

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

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

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

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

36
The Systems View

• There are two major aspects to what were 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.)

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, )

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
  organizations top management doesnt care about
  any of the previous components of our system
  they think of it in terms of how it helps perform
  business functions

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

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

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

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?

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

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?

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

46
Organizations as Systems

• Look for how open your systems 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

47
Virtual Organizations

• Organizations dont 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

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

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

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?

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 arent kept in
  entities

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?

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

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

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 gt1)

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

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

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