Object Oriented Analyis

1
C H A P T E R
5
SYSTEMS ANALYSIS
2
Chapter Five Objectives

• What are information systems, and who are the
  stakeholders in the information systems game?
• Define systems analysis and relate the term to
  the preliminary investigation, problem analysis,
  requirements analysis, and decision analysis
  phases of the systems development methodology.
• Describe a number of systems analysis approaches
  for solving business system problems.
• Describe the preliminary investigation, problem
  analysis, requirements analysis, and decision
  analysis phases in terms of your information
  system building blocks.
• Describe the preliminary investigation, problem
  analysis, requirements analysis, and decision
  analysis phases in terms of purpose,
  participants, inputs, outputs, techniques, and
  steps.
• Understand the importance of never making
  assumptions!

3
Systems Analysis vs. Systems Design

• Systems analysis is a problem-solving technique
  that decomposes a system into its component
  pieces for the purpose of studying how well those
  component parts work and interact to accomplish
  their purpose.
• Systems design (also called systems synthesis)
  is a complementary problem-solving technique (to
  systems analysis) that reassembles a systems
  component pieces back into a complete
  systemhopefully, an improved system. This may
  involves adding, deleting, and changing pieces
  relative to the original system.

4
Information Systems Analysis

• Information systems analysis is defined as those
  development phases in a project that primarily
  focus on the business problem, independent of any
  technology that can or will be used to implement
  a solution to that problem.

5
Repository

• A repository is a location (or set of locations)
  where systems analysts, systems designers, and
  system builders keep all of the documentation
  associated with one or more systems or projects.
• A network directory of computer-generated files
  that contain project correspondence, reports, and
  data
• A CASE tool dictionary or encyclopedia
• Printed documentation (binders and system
  libraries)
• An intranet website interface to the above
  components

6
Never Make Assumptions Nativity Scene

• Christmas season - independent of religious
  beliefs, the most recognized icon of the season
  is the Nativity scene.
• Take a moment to review the typical Nativity
  scene in your head.
• Try to describe all of the elements of the scene.
  Have you seen it so much that you cant properly
  remember all of the pieces??
• What is the correct description? Where do we
  find it?

7
Model-Driven Analysis Methods

• Model-driven analysis emphasizes the drawing of
  pictorial system models to document and validate
  both existing and/or proposed systems.
  Ultimately, the system model becomes the
  blueprint for designing and constructing an
  improved system.
• A model is a representation of either reality or
  vision. Just as a picture is worth a thousand
  words, most models use pictures to represent the
  reality or vision.

8
Model-Driven Methods

• Structured analysis is a model-driven,
  process-centered technique used to either analyze
  an existing system, define business requirements
  for a new system, or both. The models are
  pictures that illustrate the systems component
  pieces processes and their associated inputs,
  outputs, and files.
• Information engineering (IE) is a model-driven
  and data-centered, but process-sensitive
  technique to plan, analyze, and design
  information systems. IE models are pictures that
  illustrate and synchronize the systems data and
  processes.
• Object-oriented analysis (OOA) is a model-driven
  technique that integrates data and process
  concerns into constructs called objects. OOA
  models are pictures that illustrate the systems
  objects from various perspectives such as
  structure and behavior.

9
A Simple Process Model
10
A Simple Data Model
11
A Simple Object Model
12
Accelerated Analysis Methods

• Accelerated analysis approaches emphasize the
  construction of prototypes to more rapidly
  identify business and user requirements for a new
  system.
• A prototype is a small-scale, incomplete, but
  working sample of a desired system. Prototypes
  cater to the Ill know what I want when I see
  it way of thinking that is characteristic of
  many users and managers.

13
Accelerated Analysis Methods

• Discovery prototyping (sometimes called
  requirements prototyping) is used to identify the
  users business requirements by having them react
  to a quick-and-dirty implementation of those
  requirements.
• Rapid architecture analysis is an approach that
  attempts to derive system models (as described
  earlier in this section) from existing systems or
  discovery prototypes.
• Reverse engineering technology reads the program
  code for a database, application program, and/or
  user interface and automatically generates the
  equivalent system model.

14
Requirements Discovery Methods

• Requirements discovery includes those techniques
  to be used by systems analysts to identify or
  extract system problems and solution requirements
  from the user community.
• Fact-finding (or information gathering) is a
  classical set of techniques used to collect
  information about system problems, opportunities,
  solution requirements, and priorities.
• Sampling
• Research
• Observation
• Questionnaires and surveys
• Interviews
• Joint requirements planning (JRP) techniques use
  facilitated workshops to bring together all of
  the system owners, system users, systems
  analysts, and some systems designer and builders
  to jointly perform systems analysis.

15
Business Process Redesign Methods

• Business process redesign is the application of
  systems analysis methods to the goal of
  dramatically changing and improving the
  fundamental business processes of an
  organization, independent of information
  technology.

16
Systems Analysis Phases

• Preliminary Investigation Phase
• Problem Analysis Phase
• Requirements Analysis Phase
• Decision Analysis Phase

17
Cause-and-Effect Analysis

• Cause-and-effect analysis is a technique in which
  problems are studied to determine their causes
  and effects.
• In practice, effects can be symptomatic of more
  deeply rooted or basic problems which, in turn,
  must be analyzed for causes and effects until
  such a time as the causes and effects do not
  yield symptoms of other problems.

18
System Improvement Objectives

• An objective is a measure of success. It is
  something that you expect to achieve, if given
  sufficient resources.
• Reduce the number of uncollectible customer
  accounts by 50 percent within the next year.
• Increase by 25 percent the number of loan
  applications that can be processed during an
  eight-hour shift.
• Decrease by 50 percent the time required to
  reschedule a production lot when a workstation
  malfunctions.
• A constraint is something that will limit your
  flexibility in defining a solution to your
  objectives. Essentially, constraints cannot be
  changed.

19
Business Requirements

• A functional requirement is a description of
  activities and services a system must provide.
• A nonfunctional requirement is a description of
  other features, characteristics, and constraints
  that define a satisfactory system.

20
Logical System Models

• Logical system models depict what a system is or
  what a system must donot how the system will be
  implemented. Because logical models depict the
  essential requirements of a system, they are
  sometimes called essential system models.
• Process models (e.g., data flow diagrams)
• Data models (e.g., entity relationship diagrams)
• Interface models (e.g., context diagrams)
• Object models (e.g., Uniform Modeling Language
  diagrams)

21
A Simple Interface Model
22
Requirements Statement
23
Feasibility Analyses

• Technical feasibility. Is the solution
  technically practical? Does our staff have the
  technical expertise to design and build this
  solution?
• Operational feasibility. Will the solution
  fulfill the users requirements? To what degree?
  How will the solution change the users work
  environment? How do users feel about such a
  solution?
• Economic feasibility. Is the solution
  cost-effective?
• Schedule feasibility. Can the solution be
  designed and implemented within an acceptable
  time period?

24

• Automated Tools for Systems Development

4.24
25
Learning Objectives

• Identify the trade-offs when using CASE
• Describe organizational forces for and against
  adoption of CASE tools
• Describe the role of CASE tools and how they are
  used to support the SDLC
• List and describe the typical components of a
  comprehensive CASE environment
• Describe the general functions of upper CASE
  tools, lower CASE tools, cross life-cycle CASE
  tools and the CASE repository

4.25
26
Learning Objectives

• Describe visual and emerging development tools
  and how they are being used

4.26
27
Introduction

• Computer-aided Software Engineering (CASE)
• Automated software tool used by systems analysts
  to develop information systems
• Used to support or automate activities throughout
  the systems development life cycle (SDLC)
• Increase productivity
• Improve overall quality of systems

4.27
28
The Use of CASE in Organizations

• Purpose of CASE is to facilitate a single design
  philosophy within an organization

4.28
29
The Use of CASE in Organizations

• Objectives of CASE
• Improve quality of systems developed
• Increase speed of development and design
• Ease and improve testing process through
  automated checking
• Improve integration of development activities via
  common methodologies
• Improve quality and completeness of documentation
• Help standardize the development process
• Improve project management
• Simply program maintenance
• Promote reusability
• Improve software portability

4.29
30
CASE and System Quality

• Majority of organizations adopt CASE to improve
  speed and quality of systems development projects
• Widespread deployment has been slower than
  expected

4.30
31
CASE and System Quality

• Several factors that inhibit widespread
  deployment
• Cost
• Between 5,000 and 15,000 per year to provide
  CASE tools to one systems analyst
• Return on Investment
• Biggest benefits of CASE come in late stages of
  SDLC
• Productivity Bottlenecks
• Inability of some tools to share information
• Difficulty in providing tools for all stages of
  SDLC

4.31
32
The Outlook for CASE

• Functionality is increasing
• Cost is decreasing
• Reverse Engineering Tools
• Automated tools that read program source code as
  input and create graphical and textual
  representations of program design-level
  information
• Reengineering Tools
• Automated software that reads program source
  code, analyzes it and automatically or
  interactively alters an existing system to
  improve quality and/or performance

4.32
33
Components of CASE

• Upper CASE
• CASE tools designed to support the information
  planning and the project identification and
  selection, project initiation and planning,
  analysis and design phases of the systems
  development life cycle
• Lower CASE
• CASE tools designed to support the implementation
  and maintenance phases of the systems development
  life cycle

4.33
34
Components of CASE

• Cross life-cycle CASE
• CASE tools designed to support activities that
  occur across multiple phases of the systems
  development life cycle
• Most CASE tools utilize a repository to store all
  diagrams, forms, models and report definitions

4.34
35
Components of CASE

• Types of CASE tools
• Diagramming tools
• Computer display and report generators
• Analysis tools used to check for incomplete,
  inconsistent or incorrect specifications
• A central repository
• Documentation generators
• Code generators

4.35
36
Components of CASE

• Security Features
• Version Control
• Import/Export
• Backup and Recovery

4.36
37
CASE versus Traditional Systems Development

• Traditional approach does not offer support for
  integration of specification documents
• Often, documentation is done after coding is
  completed in traditional systems development
• Traditional approach often leads to out- of-date
  documentation

4.37
38
CASE versus Traditional Systems Development

• Traditional Systems Development
• Emphasis on coding and testing
• Paper-based specifications
• Manual coding of programs
• Manual documenting
• Intensive software testing
• Maintain code and documentation

• CASE-Based Systems Development
• Emphasis on analysis and design
• Rapid interactive prototyping
• Automated code generation
• Automated documentation generation
• Automated design checking
• Maintain design specifications

4.38
39
CASE Diagramming Tools

• Enable representation of a system and components
  visually
• Effective for representing process flows, data
  structures and program structures
• Several types of diagrams
• Data Flow Diagrams (DFD)
• Functional Hierarchy Diagrams
• Entity-Relationship Diagrams

4.39
40
CASE Form and Report Generator Tools

• CASE tools that support the creation of system
  forms and reports in order to prototype how
  systems will look and feel to users
• Two Purposes
• Create, modify and test prototypes of computer
  display forms and reports
• Identify which data items to display or collect
  for each form or report

4.40
41
CASE Analysis Tools

• Enable automatic checking for incomplete,
  inconsistent or incorrect specifications in
  diagrams, forms and reports.
• Types of analyses vary depending on the
  organizations development methodology and
  features of CASE environment

4.41
42
CASE Repository

• Integrated CASE (I-CASE)
• Automated systems development environment that
  provides numerous tools to create diagrams, forms
  and reports
• Provides analysis, reporting and code generation
  facilities
• Seamlessly shares and integrates data across and
  between tools
• Repository is central place to store information
  to share between tools

4.42
43
CASE Repository

• Holds complete information needed to create,
  modify and evolve a software system from project
  initiation and planning to code generation and
  maintenance
• Two Primary Segments
• Information Repository
• Data Dictionary

4.43
44
CASE Repository

• Information Repository
• Combines information about an organizations
  business information and its application
  portfolio
• Provides automated tools to manage and control
  access to repository
• Business Information
• Data stored in corporate databases
• Application Portfolio
• Application programs used to manage business

4.44
45
CASE Repository

• Data Dictionary
• Computer software tool used to manage and control
  access to the information repository
• Contains all data definitions for all
  organizational applications
• Cross referencing
• Enables one description of a data item to be
  stored and accessed by all individuals
• Single definition for a data item is established
  and used

4.45
46
CASE Repository

• Data Dictionary
• Entries have a standard definition
• Element name and alias
• Textual description of the element
• List of related elements
• Element type and format
• Range of acceptable values
• Other information unique to the proper processing
  of this element

4.46
47
CASE Repository

• CASE Repository and the SDLC
• During project initiation and planning phase, all
  information related to the problem being solved
  is stored in the repository
• Problem domain, project resources, history and
  organizational context
• During analysis and design phases, store
  graphical diagrams and prototype forms and
  reports
• Data stored in repository are used for basis to
  generate code and documentation

4.47
48
CASE Repository

• Additional Advantages
• Assistance with project management tasks
• Aids in software reusability
• The ability to design software modules in a
  manner so that they can be used again and again
  in different systems without significant
  modification

4.48
49
CASE Documentation Generator Tools

• Enable the easy production of both technical and
  user documentation
• Allow creation of master templates used to verify
  that documentation conforms to all stages of SDLC

4.49
50
CASE Code Generation Tools

• Enable the automatic generation of program and
  database definition code directly from the design
  documents, diagrams, forms and reports stored in
  the repository

4.50
51
Visual and Emerging Development Tools

• Object-Oriented Development Tools
• Object
• A chunk of program and data that is built to
  perform common functions within a system
• Easily reused
• Encapsulation
• Process of grouping data and instructions
  together
• Development environment includes pre-defined
  objects and facilitates reuse of code

4.51
52
Visual and Emerging Development Tools

• Visual Development Tools
• Enable developers to quickly create user
  interfaces
• Popular tools include
• Microsoft Visual Studio
• Delphi
• Powerbuilder
• ColdFusion

4.52
53
Summary

• Use of CASE in Organizations
• Categories of CASE Tools
• Reverse Engineering
• Re-engineering
• Components of CASE
• Upper CASE
• Diagramming tools
• Form and report generators
• Analysis tools

4.53
54

• Break

55

• INFORMATION GATHERING
• FOR INFORMATION
• SYSTEMS DEVELOPMENT

56
Lecture Objectives

• to be aware of various methods for data gathering
  in respect of information system development
• to understand the usefulness and suitability of
  various data gathering methods for particular
  problem situations

57
Data gathering in systems development

• Data gathering is a major task of systems
  analysis.
• Systems analysis involves
• Understanding and describing how the current
  system functions
• Determining what users would like their new
  system to do (requirements)
• Need to collect information
• current and future situations, problems,
  opportunities, constraints

58
Data gathering as a foundation for developing
information systems

• What data?
• Sources of data?
• What data gathering methods?
• What strategy for gathering data is needed?
• How will the data gathered be analysed?

59
What data to gather?

• Data about the business or organisation
• Data about the business environment
• Data about the systems environment
• Data about the users of the system
• Data about the current system
• Data about the proposed system
• Constraints e.g. cost, technical,timeframe

60
What data to gather?

• The business or organisation
• Data about the nature of the business and its
  market and business environment
• Data about business goals and objectives that
  dictate what and how work is done
• Data about organisational structure major
  functions, departments etc
• Data about major business subsystems and how they
  interact
• Data about business policies and guidelines

61
What data to gather?

• Users of the system
• Roles and responsibilities
• Reporting structures
• Job specifications and actual tasks performed
• Information needed to do their jobs
• Formal and informal communication and workflow
  channels

62
What data to gather?

• Users of the system
• Data about roles and responsibilities
• Data about reporting structures
• Job specifications and data about actual tasks
  performed
• Data about information needed to do their jobs
• Data about formal and informal communication and
  workflow channels

63
What data to gather?

• The existing system
• Data about tasks and workflow functions,
  processes, sequence of processes, methods and
  procedures, inputs, outputs
• Data about the data (definition, volumes, size
  etc.)
• Data about interactions with other systems
• Data about work volumes and processing cycles
• Data about performance standards and criteria
• Data about control mechanisms e.g security,
  accuracy
• Data about problems e.g. efficiency, information

64
What data to gather?

• The new system
• Data about system requirement a need or desire
  to be met by a proposed system
• Data about both functional requirements
  (processes and functionality) and
• non-functional requirements (security,
  performance, service etc.)
• Data about constraints e.g. existing technology
• Data about interactions with other systems
• Data about relationship to existing system/s

65
Sources of data

• Users and other stakeholders
• Documents about the system
• Documents about the organisation
• Documents and data used within the existing
  system
• Transactions within existing system
• External sources

66
Sources of data

• Users
• System sponsor/owner overall project objectives
• Managers high level, broad view of existing
  system and requirements
• End-users detailed, operational level view of
  existing system and requirements
• Technical staff technology capaabilities,
  limitations etc.
• External stakeholders e.g. customers

67
Sources of data

• Documents about the system and organisation
• Organisation charts
• Policy manuals
• Business reports financial, annual etc.
• Jobs, procedure, operations manuals
• Training manuals
• Existing system documentation
• Internal reports relating to the system

68
Sources of data

• Documents and data used within the existing
  system
• Files, databases, programs, forms, reports
• Informal Memos, bulletin boards, files
• External sources
• Other organisations systems
• Hardware software vendors
• Business industry publications

69

What data gathering methods?

• Interviews
• Questionnaires
• Observation
• Sampling documents and transactions
• Research and site visits

70
Interviews

• Generally the most important and widely-used
  method for data gathering
• May be formal/structured (specific questions) or
  informal/unstructured (general goal or purpose)
• Need an interview strategy for the entire
  interviewing process
• Need an interview plan or guide for each interview

71
The interview strategy

• Identify the users to interview
• Do this after you have an initial understanding
  of the organisation and system
• Establish general objectives and guidelines for
  the entire interviewing process
• e.g. information to be obtained, sources,
  formats, documenting, analysis
• Ensure all key people are included

72
The interview strategy

• Determine the sequence of interviews
• E.g. management first
• broad overview of system operations
• gain support and co-operation
• help to identify who to interview next
• Then system users
• obtain information about detailed operations
• Co-ordinate the interviewing process
• Compare results, select follow ups etc.

73
The interview strategy

• Need individual interview plans
• Initial interviews to meet users
• Fact gathering interviews
• Follow up interviews
• Interview plans
• Decide on interview structure
• Determine content of questions
• Decide on question types

74
Interviews

• Need to consider
• Who has the information you need?
• Where to conduct the interview?
• When is the best time to interview?
• How should the interview progress?

75
The individual interview

• Before the interview
• Arrange time and place, necessary materials,
  inform interviewee of interview purpose
• Conduct the interview
• After the interview
• Write an interview report
• Review this with the interviewee at a follow up
  interview

76
The interview structure

• Preliminaries
• Introduction, purpose, environment and procedures
  e.g. permission to tape
• Body
• Define what you already believe to be true and
  confirm this, explore points issues further,
  new areas (questions)
• Conclusion
• Summarise and confirm your findings
• Schedule a follow up interview

77
Interviews types of questions

• Closed how many transactions per day?
• Limits available responses
• Open tell me about ..
• Leaves options open for interviewee
• Probe tell me more about the problem with the
  .
• To clarify and expand
• Mirror From what you said, I understand that.
• To confirm what was said etc.

78
Interviews types of questions

• Avoid long, complex, or double-barrelled
  questions
• what decisions are made during this process and
  how do you make them?
• Avoid leading questions
• you dont need the customer number on this
  report, do you?
• Avoid loaded questions
• when did you first discover the mistake?
• i.e. how long have you known and done nothing?

79
Interviews advantages

• obtain extensive, complex detailed information
• get insights and opinions
• discover informal procedures
• flexible e.g. explore issues further or new
  issues
• establish rapport with interviewee and understand
  their attitudes
• reveal the politics of the system environment
• information is revealed both by the spoken word
  and by the interviewees body language
• guaranteed response

80
Interviews Disadvantages

• Time-consuming
• Costly
• Danger of bias
• More difficult to tabulate and analyse results
  e.g. to obtain an overall picture
• Success in interviewing depends on the
  inter-personal skills of the interviewer

81
Questionnaires

• A structured method of data gathering in which
  written questions/comments are provided for the
  participants to respond to in written form
• The questionnaire can take many forms - write
  comments/ select from a list of possible
  responses/ mark on a scale
• May permit either quantitative or qualitative
  data (mark out of 10/grade from good to bad)
• Usually involves no direct contact between data
  gatherer and respondents

82
Questionnaires

• Useful when small amounts of data are required
  from a large number of people
• For geographically dispersed respondents
• Types of questions
• Open-ended (free format)
• Fill-in-the-blank
• Multiple choice
• Rating
• Ranking

83
Designing questionnaires

• What facts and opinions to be collected
• Who to sample and sample size
• Types of questions and wording (precise,
  accurate, unambiguous)
• How to administer e.g. paper, online, mail out
  etc.
• Format and layout (grouping, crosschecks etc.)
• Test on small sample of respondents
• How completed questionnaires will be returned and
  collated
• How analysis of the data will be carried out

84
Questionnaires

• Useful for
• Obtaining simple opinions, facts
• Quantifying what was found in interviews
• Identifying issues before interviewing
• Determining extent of problems
• Not useful for detailed or complex information or
  exploring issues in depth
• Can supplement other methods

85
Questionnaires advantages

• most economical method for gathering data from
  large numbers of people
• quick and easy to administer
• results can be tabulated rapidly and analysed
  readily
• allow respondents to be anonymous
• gives respondents time to reflect on answers
• respondents complete in their own time

86
Questionnaires disadvantages

• difficult to construct effective questionnaires
• specific and limited amounts of information
• possible low return rates
• possible bias and misinterpretation
• cannot probe issues further (inflexible)
• cannot clarify vague or incomplete answers
• lack non-verbal communication

87
Observation

• observing the actual processes of a system
• need to prepare beforehand, and report on data
  collected
• gain first hand knowledge of current systems
  operations
• clarify other information collected
• understand complex procedures
• inexpensive
• behaviour distortions may affect reliability
• unrepresentative samples affect reliability

88
Sampling of documents and transactions

• Sampling collecting a representative sample of
  documents, forms, transactions
• Useful for specific information e.g. transaction
  volumes and types, file sizes
• Useful where large volumes exist
• Information about existing system operations
• Representative samples must be selected
• determine sample size, appropriate range, avoid
  bias

89
Research and site visits

• Most problems not unique learn from experiences
  of other organisations
• Professional societies can provide contacts for
  site visits
• Computer trade journals and magazines and the
  internet can be sources for research into the
  problem/s e.g. do appropriate software packages
  exist?

90
Other data gathering methods

• Other modern methods used
• Discovery prototyping
• JAD (Joint Application Development) sessions
• Focus groups

91
A data gathering strategy

• Data gathering must be carefully planned in order
  to make the most of the time and resources
  available
• Information sources
• Data gathering methods
• Recording and documentation methods
• Data analysis methods
• Procedures for reviewing results with management
  and users

92
A data gathering strategy

• E.g. a top down approach
• Initial interviews with management to determine
  major system activities and data
• Document and verify this
• Expand major system component descriptions into
  detailed descriptions
• Interview operational users, sampling,
  questionnaires, observation etc
• Document and verify this
• Repeat these last two steps as necessary
• Review findings with management

93
A data gathering strategy

• Consider costs allow for time and resources
  required for initial and ongoing information
  gathering
• Use the least expensive methods first
• Plan how to check the validity of data
• Cross checking between groups, methods
• Evaluate data for inconsistencies
• Ask further questions
• Plan documentation of data e.g. records of
  interviews etc. data dictionary, system models

94
Data gathering in practice

• Completeness?
• Accuracy?
• Objectivity?
• Biases?
• Stability?
• Representative?
• Finished?