Introduction to Information Systems Analysis Information Systems Development Fact Finding Techniques

1
Introduction to InformationSystems
AnalysisInformation Systems DevelopmentFact
Finding Techniques

• INFO 503
• Glenn Booker

2
System Development Life Cycle

• A System Development Life Cycle is the process
  used for developing a system
• A life cycle is a management tool for planning,
  conducting, and controlling an activity
• Software and System life cycles are similar,
  differing in the details of each activity

3
Methodology

• A methodology, such as FAST, implements a life
  cycle by defining activities
• Each activity has roles and responsibilities,
  creates work products, and uses tools and
  techniques
• Major recurring theme in the text
• Methodology should cover entire life cycle

4
Capability Maturity Model

• Level 1 Initial chaos no consistent
  processes
• Level 2 Repeatable processes for a project
• Level 3 Defined processes across an
  organization
• Level 4 Quantitatively Managed projects
• Level 5 Processes Optimized continuously

5
Groundwork

• Any system development should first define its
  general scope
• What kind of product will be created?
• What order of magnitude for time frame and number
  of resources are available for this effort?
  (e.g. week, month, year, or 10k, 1M)
• What is the current state of similar products?
• What will make this product special?

6
Ten Principles of System Development

• Get the system users involved
• Use a problem-solving approach
• Establish phases and activities
• Document throughout Development
• Establish standards
• Manage the Process and Projects
• Justify systems as capital investments
• Dont be afraid to cancel or revise scope
• Divide and conquer
• Design systems for growth and change

7
1. Get the System Users Involved

• Encourage owners, users, and developers to work
  cooperatively and collaborate
• Get everyone involved in defining requirements
  and discussing changes
• Document decisions well
• Education of owners and users can help overcome
  biases and fears

8
2. Use a Problem-Solving Approach

• The methodology (life cycle) is an approach
• Study the problem and its context
• Define the requirements of a solution
• Identify possible solutions and pick one
• Design and implement the solution
• Observe the solutions impact, and refine it
• Dont skip steps!

9
3. Establish Phases and Activities
p. 89 (75)

• Major FAST phases are
• Scope Definition (led by system owners)
• Problem and Requirements Analysis (users)
• Logical Design and Decision Analysis (designers)
• Physical Design and Integration (builders)
• Construction and Testing
• Installation and Delivery

10
3. Establish Phases and Activities

• Higher levels are business-driven lower are
  technology-driven
• Each phase is broken down into activities and
  tasks to make them manageable
• Development is often iterative, with frequent
  back-tracking to refine requirements and the
  design
• Be sure not to get stuck in iteration!

11
4. Document throughout Development

• In order for large projects to succeed, programs
  need to be documented and agreed upon before
  theyre developed
• Necessary for coordination across stakeholders,
  and to leave a comprehensible legacy for
  maintenance

12
5. Establish Standards

• Standards should be used for both creation of the
  information system itself, and for the processes
  used to create the system
• Records assumptions and measure progress
• May include document style standards, file and
  variable naming conventions, and file
  organization conventions

13
5. Establish Standards

• System development standards may describe, for
  every phase of the life cycle
• Activities (what happened?)
• Responsibilities (who did it and why?)
• Documentation requirements (tailor from corporate
  standard templates)
• Quality checks (peer review, defect prevention)

14
6. Manage the Process and Projects

• Deliberate process and project management ensures
  that your organization 1) has defined processes,
  and 2) they are actually used, and 3) you can
  determine how to improve them
• Benefits not only this program, but others in
  the future too

15
7. Justify Systems as Capital Investments

• Information systems often outlive many projects,
  hence are capital investments
• Make sure alternatives are well investigated (do
  you buy the first house you see?)
• Analyze the cost-effectiveness of all major
  alternatives, including both development and
  operational costs
• Manage risks during development

16
8. Dont be afraid to Cancel or Revise Scope

• The iterative nature of development makes it
  tempting to implement a not-good system
• Feature and schedule creep can sneak up quietly,
  one good decision after another
• Avoid getting stuck by choosing creeping
  commitment points during development
• At each, consider cancellation, projected system
  cost, schedule, and feature scope

17
9. Divide and Conquer

• Every system is part of a larger system
  (supersystem) and most contain smaller systems
  (subsystems)
• Interaction with supersystem can change
  requirements during system development
• Defining subsystems can help make project design
  more manageable

18
10. Design Systems for Growth and Change

• Business needs change over time
• During system maintenance (support), maintenance
  cost grows as the system requirements evolve and
  hardware wears out system becomes obsolete
• Hence need to design systems so that they can be
  replaced some day

19
FAST Methodology

• An information system project starts when
• Problems keep your organization from reaching its
  business goals or objectives
• Opportunities arise when a new capability is
  identified (e.g. new features)
• Directives from outside your organization mandate
  new features or requirements (e.g. laws,
  regulations)

20
PIECES Review Criteria

• Assess new projects for their
• Performance improvement potential
• Information or data improvement
• Economic or cost improvement
• Control or security improvement
• Efficiency improvement (people or process)
• Service to customer, supplier, staff, etc.

21
FAST Phases
p. 96 (83)key overview

• Scope Definition in 4th Ed. Survey Phase
  (system owner)
• Problem Analysis Study Phase (analyst)
• Requirements Analysis Definition Phase
  (analyst)
• Logical Design not separate in 4th Ed.
• Decision Analysis Configuration Phase
  (designer)

22
FAST Phases

• Procurement Phase Version 4 separate only or
  blend into other phases (designer)
• Physical Design Integration Design Phase
  (designer)
• Construction Testing Construction Phase
  (builder)
• Installation Delivery Delivery Phase (builder)

23
1. Scope Definition

• This is a sanity check to see if the project is
  worth looking at
• If so, define the project team, budget, and
  schedule (very rough)
• Involves sponsors and managers, plus user
  involvement
• Deliver a feasibility study and project plan

24
2. Problem Analysis

• Study existing system (automated or not) for
  problems and opportunities
• Is the new improved system worth having?
• Run by system analyst, with user and owner
  involvement
• Define system objectives, and success criteria
  for new system

25
3. Requirements Analysis

• Now define and prioritize detailed system and
  business requirements
• Consider also what it does NOT do
• Do NOT describe HOW it does anything
• System analyst and many users do this
• Create models of data, process, interface, and
  geography perspectives

26
3. Requirements Analysis

• Might use prototyping to verify requirements
• Present requirements and models in a requirements
  statement
• Time boxing is placing requirements into
  staged deliveries for implementation (hence start
  to think of priorities)

27
4. Logical Design

• The logical design phase is when various models
  are developed to describe the logical functions
  of the system
• This typically includes data, process, and/or
  object models
• Beware of getting stuck in analysis paralysis

28
5. Decision Analysis

• Identify candidate solutions, analyze them, and
  recommend the best one
• Done by system analyst, with support from all
  others, and maybe consultants
• May start before requirements are done
• May include make-or-buy decisions, and define an
  application architecture

29
5. Decision Analysis

• Evaluate each solution for technical,
  operational, economic, and schedule feasibility
• Produce a system proposal for owners approval
• Often includes procurement phase for
  off-the-shelf applications

30
Procurement Phase

• Major system components are often acquired, not
  built from scratch
• See COTS tool reports (Commercial-Off-The-Shelf
  software) by the SEI, STSC
• Vendors help system analyst and users
• Study existing market future trends, then
  generate a RFP or RFI (see References)

31
Procurement Phase

• Evaluate vendors proposals pick the one that
  meets requirements and is most cost effective
• Negotiate contractual and licensing needs to
  obtain products, installation, training, etc.

32
6. Physical Design Integration

• Turn requirements into plans for the builders,
  iteratively, until plans are complete (Rapid
  Application Development)
• Analyst and specialists involved
• Database, program, human and system interfaces
  are all designed using iterative prototyping

33
6. Physical Design Integration

• Iterate
• Define base system
• Define database, load with data, and review with
  users
• Define inputs, and review with users
• Define outputs, and review with users
• Define interfaces, and review with users
• Define other controls, and implement. Repeat.

34
7. Construction Testing

• Now build the real system and its interfaces
• System builders lead the team
• Design specifications are main input
• Write code, then conduct unit test, and system
  test
• May deliver system in stages

35
8. Installation Delivery

• Install new system and place it into operation
• May include data conversion and loading to
  initialize system, and training of end users
• Users provide feedback (problem reports) to
  identify initial support issues

36
System Operation and Maintenance

• While system is in use
• Assist users (help desk)
• Fix bugs
• Recover system after failures
• Adapt to new requirements (implement new
  features)

37
Cross Life Cycle Activities

• These may overlap many (or all) other phases of
  development
• Fact-finding
• Help collect information about systems,
  requirements, and user preferences
• Most important early in life cycle

38
Cross Life Cycle Activities

• Documentation is generated to record the work
  accomplished so far, and plan future activities
• Presentations are a formal packaging, in writing
  or orally, of some documentation
• Dog and pony shows are presentations made to
  upper management or sponsors

39
Cross Life Cycle Activities

• Estimation and measurement are performed
  throughout the life cycle (see INFO 630)
• Estimation is to predict the amount of time,
  effort, cost, and benefits of some activity
  within system development
• Measurement is to determine the actual amount of
  what was estimated
• Earned value is one way of comparing them

40
Cross Life Cycle Activities

• Feasibility analysis is performed early in a
  project to determine its potential benefits
• Recall mention of technical, operational,
  economic, and schedule feasibility
• Project management is the deliberate planning and
  control of a project to achieve the desired goal
  (creation of a product)

41
Cross Life Cycle Activities

• Process management is the conscious definition
  and management of the processes used to conduct a
  project, using standards to define typical work
  products (deliverables)
• Data and documents from all phases should be
  stored, such as in a repository

42
Methodology Options
p. 108 (n/a)

• Systems can be build from scratch, purchased
  off-the-shelf, or some of both
• Methodologies can be very rigid (prescriptive),
  or flexible (adaptive)
• Methodologies can be model-driven (draw pictures
  first, e.g. FAST) or product-driven (build
  something and see if it works)

43
Model-Driven Development

• Most methods for analysis and design focus on
  using models to capture thoughts
• Structured analysis focuses on processes, such as
  the data flow diagram
• Information engineering focuses on data, such as
  the entity relationship diagram
• Object oriented analysis and design blend data
  and process into objects

44
RAD and COTS

• Rapid Application Development (RAD) focuses on
  iterative development of prototypes with lots of
  user input
• Often uses time boxing to limit the effort on
  each iteration
• Commercial Off The Shelf (COTS) products can be
  used as the entire system, or significant
  portions of a developed one

45
CASE Tools

• Computer Assisted Software Engineering (or
  Systems Engineering) tools use an information
  system (customized database) which is devoted to
  managing a system development effort
• CASE tools may include compilers, design and
  diagram tools, quality and document management
  tools, and generate code

46
CASE Tools

• Upper CASE Tools focus on early development
  activities requirements and high level design
  phases may also be able to reverse engineer code
• Lower CASE Tools focus on (you guessed it!) later
  development activities detailed design,
  construction (coding), implementation, and
  perhaps support

47
CASE and ADE Tools

• CASE Tools are noted for pretty graphical
  capabilities - diagrams, flow charts, etc.
• They store projects in repositories
• Price is high in both and learning curve
• Compilers have evolved into Application (or
  Integrated) Development Environments (ADE or IDE)
  may include debuggers and interface tools,
  testing and version control

48
Fact Finding and Information Gathering

• Fact finding is the formal process of using
  various techniques to collect information about
  system requirements and user preferences
• Facts are the basis for modeling
• Conclusions about the system are also drawn from
  these facts
• So facts are, like, really important )

49
Fact Finding and Information Gathering

• Fact finding is most important during the
  planning and analysis phases, but still useful
  during the rest of the life cycle
• Seven techniques to choose from often use
  several on any given project
• Fact finding may also discover business rules
  how does the system need to respond under
  different conditions?

50
Requirements
See also INFO627

• Fact finding may give info at various levels of
  detail, depending on the audience
• Requirements capture what and/or how the system
  needs to be able to support its users
• A requirement is more precise than a user need,
  but more vague than a specification
• Defining requirements is a key output from fact
  finding and information gathering

51
Requirements

• A Need defines the basis for requirements, such
  as the system must support 20 simultaneous
  users
• A Requirement defines what capability the system
  must fulfill to meet the need, the system must
  handle 1000 tps from 20 simultaneous users
• A Specification defines how to measure the
  requirement, such as the protocol or test
  conditions to be used

tps transactions per second
52
Requirements

• Many requirements are functional they describe
  what the system can do
• Non-functional requirements describe how the
  system performs the functional reqts
• Performance, cost, control (security), efficiency
  (resource usage), and the ilities (reliability,
  availability, maintainability, usability, etc.)

53
Fact Finding and Information Gathering
p. 243 (623)

• Techniques are
• Sampling
• Research and Site Visits
• Observation of the Work Environment
• Questionnaires
• Interviews
• Prototyping

54
Sampling

• Works well for study of an existing system
• Comes before interviews may include
• Look for organization chart
• Investigate project history
• Look for high level mission or policies
• Charters for each organization affected
• Processes and procedures in use

55
Sampling

• And study existing system documents
• Inputs
• Outputs
• Program documentation
• Data dictionaries
• User and maintenance manuals

56
Sampling

• If you know a lot about the consistency of data,
  can use statistical sampling techniques
• A random sample should be truly random, not just
  convenient
• A stratified sample may be used to avoid
  important special cases

See also INFO 630
57
Research and Site Visits

• Research may use various sources, such as
• The Internet (e.g. for vendors)
• Trade and professional journals (AITP, AIS, IEEE,
  ACM, etc.)
• Company-specific intranets
• Government agencies (SEI, STSC, etc.)
• Site visits are to see the existing system

58
Observation of the Work Environment

• Participate in, or watch the existing system
  being used
• Should determine what kind of data to collect,
  when, and how (what forms)
• Should already understand the process being
  observed somewhat
• Can use sampling for large numbers of
  observations

59
Observation of the Work Environment

• Determine who, what, where, why, and how
• Obtain permission from supervisor
• Inform subject of reason for visit
• Keep a low profile dont interrupt
• Take copious notes, and review them
• Focus on important activities
• Dont make assumptions

60
Questionnaires

• Can be efficient for large audiences
• But hard to guarantee responses, or fairness
• Can use free format, but hard to analyze
• Fixed format may include
• Multiple choice (Y/N or A/B/C/..)
• Rating (5-point from strongly agree to strongly
  disagree)
• Ranking (importance, or or time)

61
Interviews

• Provide more personal information about body
  language, inflection, tone, etc.
• Take a lot more time, but are often liked
• Can be structured or unstructured (rare)
• Structured tend to use open-ended questions
  rather than closed-ended ones (yes/no)
• Need to be well prepared, take good notes

62
Prototyping

• Prototyping, or discovery prototyping, tends to
  use very specialized tools, and may define and
  refine prototypes with direct user involvement
• Can be part of a RAD development approach
• Highly iterative helps clarify requirements
• Easy to omit quality and performance reqts

63
Ethics

• Many professional organizations, such as the
  AITP, IEEE, the Computer Ethics Institute, and
  ACM have defined standards of professional
  conduct
• Such standards should be used for guidance when
  dealing with information which may be sensitive,
  such as pricing structure, profit data, or
  employee personal data