Transcript Systems Analysis I Review ISYS 200 Glenn Booker ISYS 200 Week #10 The Life Cycle   We use one or more life cycle models to help structure the.

Systems Analysis I
Review
ISYS 200
Glenn Booker
ISYS 200
Week #10
1
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





ISYS 200
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 #10
2
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



ISYS 200
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 #10
3
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 #10
4
Typical SDLC Phases

Creating any kind of software system
typically involves these phases







ISYS 200
Identify problems and opportunities
Determine information requirements
Analyze system needs
Design the system
Develop the system
Test the system
Implement the system
Week #10
5
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



ISYS 200
Fix bugs in the existing system
Make minor improvements
Update commercial components (OS patches,
apply service packs, product upgrades, etc.)
Week #10
6
Context Diagram



The context diagram is the highest level
of data flow diagram
The system is reduced to a single box,
representing all its processes at once
Data flows to all the types of users and
external systems are shown
ISYS 200
Week #10
7
Information Gathering

There are two types of methods for gathering
information about a system



Interactive methods, which interact with
the users of the existing system
Unobtrusive (passive) methods, which
observe aspects of the existing system
Our goal is to understand the good and bad
aspects of the existing system, to help
determine requirements for our new system
ISYS 200
Week #10
8
Interactive Methods

There are three common methods for
gathering information interactively

Interviews




Joint Application Design (JAD)
Questionnaires

ISYS 200
Open-ended versus closed questions
Pyramid, funnel, and diamond structures for questions
Choosing good scales for answers to questions
Week #10
9
Unobtrusive Methods

Unobtrusive methods for gathering
information include

Sampling





Systematic, simple random, stratified, or clustered
Set margin for error and confidence interval
Investigation- qualitative and quantitative
Observation
These should be used in conjunction
with one or more interactive methods
ISYS 200
Week #10
10
Prototyping

There are four major types of prototype




ISYS 200
Patched-up prototype – proof of concept
Nonoperational prototype – interface images only
First-of-a-series prototype – nearly finished
complete system
Selected features prototype – a few functions are
fully functional
Week #10
11
Rapid Application
Development (RAD)



RAD is another method for speeding
development time, this time using
specialized development tools
Often used when time to market is critical
RAD uses three phases



ISYS 200
Requirements Planning Phase
RAD Design Workshop
Implementation
Week #10
12
Extreme Programming (XP)

Extreme Programming is one of a family of
“agile” development methods which includes




Scrum
DSDM
Evo
And others
Please note that the linked file has copyright by the Software Productivity Consortium.
ISYS 200
Week #10
13
Four XP Core Practices

XP is best known for its core practices




Short releases – some features now, others later
Forty-hour workweek – don’t burn out
your developers!
Onsite customer – to make all that
communication possible
Pair programming – develop code in pairs, so
everyone can quickly have peer reviews

ISYS 200
Change pairs frequently to keep objectivity intact
Week #10
14
Data Flow Diagrams (DFDs)

DFDs show the flow of data through the
processes your system can perform



ISYS 200
Processes are connected to the entities which
start them, and/or receive outputs from them
Processes are connected to the data stores
used to capture important information created
by or used by them
Important to make sure processes and data
stores aren’t miracles (no input) or black holes
(no output)
Week #10
15
CRUD Matrix


A CRUD matrix maps data and processes
to verify that all data is used correctly
throughout the system
The CRUD matrix shows process names
in each row, and data stores in each
column (p. 203)


ISYS 200
For each process and data store, enter C, R, U,
and/or D to indicate allowable data activities
Show the process and data store numbers from
the DFD
Week #10
16
Data Modeling



Data need to be stored for later reference
and analysis
Entities are the name given to what later
become data tables
Lots of kinds of files


Master files, Transaction files, Document files,
Archival files, Table look-up files, Audit files
Need to define what files are needed, and
how they are related to each other
ISYS 200
Week #10
17
Data Modeling


ERD model captures
The entities needed for permanent data



The attributes and the data types of each attribute
(text, number, Boolean, etc.)
The primary and, as needed, foreign keys
Relationships between entities describe


ISYS 200
Cardinality (0, 1, and/or many)
A verb phrase to describe the relationship
Week #10
18
Data Modeling


Can use associative entities to show when a
given entity only exists in connection with
records from two other entities
Can use attributive entity to show when an
entity is dependent upon a parent entity
ISYS 200
Week #10
19
Summary of Key Traits

The bottom line for keys is:

Each entity must have at least one PK






ISYS 200
More than one PK implies a concatenated key
Alternate keys are completely optional
Each entity may have from zero to many FK’s
Each FK is a PK in another, related entity
Only one PK-FK relationship is needed to relate
two entities
Some keys are not inherently meaningful data
Week #10
20
Normalization of Entities

Entities are normalized to third normal form
(3NF) when




Every attribute appears only once for each record
Each non-primary-key attribute is uniquely
determined by the entire primary key
Every attribute depends only on the primary key
We don’t worry about fourth and fifth level
normalization
ISYS 200
Week #10
21
Output Design

We design outputs by




Determine if they are internal or external outputs
Choose the best output technology
Deliberately avoiding bias in the design
Follow typical design conventions




ISYS 200
Group related information
Separate constant from variable information
Use a consistent design approach and layout
Control distribution and security of outputs
Week #10
22
Input Design

Develop inputs needed to fulfill the outputs






ISYS 200
Consider the seven typical input form sections
Use appropriate captions
Validate data inputs and use input controls to help
avoid data entry errors
Use navigation and controls for screen inputs
Plan feedback options and easy user movement
Provide instructions, and use a logical sequence
of data entry
Week #10
23
Interface Selection

Choose appropriate interface type for the
user needs and sophistication



Natural language, Question and answer, Menus,
Form-fill, Command language, GUI, Pointing
devices (stylus, tablet PC, touch screen) and
Voice recognition systems
Minimize user actions, especially typing!
Keep look and feel of the interface consistent


ISYS 200
Provide help for various levels of users
Provide feedback to the user
Week #10
24
Problems & Opportunities

We can look for problems and opportunities
in many parts of our organization, and the
existing systems which are supported



Define what’s wrong with the existing system, so
you can fix it with the new system
Identify new features to provide functionality not
previously possible
Then establish system objectives to predict
how much better the new system will be
ISYS 200
Week #10
25
Feasibility Analysis

Feasibility consists of several types we want
to assess for each candidate project

Technical feasibility


Economic feasibility



Determine present value of system benefits and costs
Assess break even point, lifetime and annual ROI,
and/or cash flow
Operational feasibility

ISYS 200
Is system technically achievable?
How does new system affect users?
Week #10
26
Project Planning


Look at a project in terms of a set of tasks to
be accomplished, and managing the
resources (people, tools) needed to perform
those tasks
Use a life cycle model to identify the major
sets of activities, called life cycle phases

ISYS 200
Each phase is broken down into more and more
specific activities, until the time needed for each
activity can be reliably estimated
Week #10
27
Gantt Chart

Determine the time and sequence in which
tasks need to be done, and put them in a
Gantt chart




ISYS 200
A timeline represents when the project occurs
Tasks are bars under the timeline
Summary tasks group related tasks together
Decisions appear as milestones
Week #10
28
PERT Diagrams

PERT diagrams, or PERT charts, are
primarily used to help identify the critical
path for a project


The critical path is the sequence of tasks which,
if any tasks were changed, would also change
the completion date of the project
Tasks on the critical path tend to get
preferential treatment for getting resources
ISYS 200
Week #10
29
System Proposal

A system proposal describes the proposed
approach for creating a system



Is strengthened by analysis of several candidate
solutions, including feasibility study of each
They differ in terms of architecture, technology,
degree of automation, choice of commercial
components, or selection of custom vs
commercial components
The proposal is a sales tool to convince your
audience you’ve found the best solution
ISYS 200
Week #10
30