Systems Analysis Methods Part 2
Project Management is
the process of planning
and controlling development of a system within a specified timeframe at
a minimum cost with the right functionality. This applies to any system.
A project manager
has the primary responsibility for managing the hundreds of tasks and roles
that need to be carefully coordinated.
In the 2000 Standish Group Study
Only 28% of system development projects successful.
72% of projects cancelled, completed late, completed over
budget, and/or limited in functionality.
Key Steps in Managing
a project
·
Identifying project size (scope)
·
Creating and managing the work-plan
·
Staffing the project
·
Coordinating project activities
Identifying project
size
Project Manager’s
Balancing Act
·
Project Management involves making trade-offs
·
Modifying one element requires adjusting the
others
Project Estimation
(Guess –ta- mate)
·
The process of assigning projected values for
time and effort
·
Sources of estimates
¨
Methodology in use
¨
Actual previous projects
¨
Experienced developers
·
Estimates
begin as a range and become more specific as the project progresses
Planning
|
Analysis
|
Design
|
Implementation
|
|
Typical industry standards for business applications
|
15%
|
20%
|
35%
|
30%
|
Estimates based on actual figures for first stages of SDLC
|
Actual
|
Estimated
|
Estimated
|
Estimated
|
4 person
|
5.33 person
|
9.33 person
|
8 person
|
|
months
|
months
|
months
|
months
|
SDLC= system development life cycle
Creating and Managing
the work plan
Work
Plan Information
|
Example
|
Name of task
Start date
Completion date
Person assigned
Deliverable (s)
Completion status
Priority
Resources needed
Estimated time
Actual time
|
Preform economic feasibility
Jan 05,2005
Jan 19, 2005
Project sponsor: Mary Smith
Cost-benefit analysis
Open
High
Spreadsheet
16 hours
14.5 hours
|
LOC = Line of
Code
Project Work plan
·
List of all tasks in the work breakdown
structure, plus
·
Duration of task
·
Current task status
·
Task dependencies
·
Milestone (dates)
Tracking Project Tasks
·
Gantt
Chart
·
Bar chart format
·
Useful to monitor project status at any point in
time
Pert Chart
·
Flowchart format
·
Illustrate task dependencies
Identifying Tasks
·
Methodology
§
Using standard list of tasks
·
Top-down approach
·
Identify highest level tasks
·
Break them into increasingly smaller units
·
Organize into work breakdown structure
Managing Scope
·
Scope creep (size)
·
JAD and prototyping(joint application
development)
·
Formal change approval
·
Defer additional requirements as future system
enhancements
Time boxing
·
Fixed deadline
·
Reduced functionality, if necessary
·
Fewer “finishing touches”
Staffing the Project
Staffing Attributes
·
Staffing levels will change over a project’s
lifetime
·
Adding staff may add more overhead than
additional labour ”Brooke” said that
·
Using teams of 8-10 reporting in a hierarchical
structure can reduce complexity
Coordinating Project Activities
Case Tools
Planning Analysis Design Implementation
Upper CASE Lower
CASE
Integrated
CASE (I-CASE)
Classic Mistakes
·
Overly optimistic schedule
·
Failing to monitor schedule
·
Failing to update schedule
·
Adding people to a late project
Oversight committee
Project manager works
with Client, Users, Subcontractors, Team leaders, They are all members
Feasibility
Feasibility is a
measure of how beneficial or practical the development of an information system
will be to an organization
Feasibility analysis/study
is the process by which feasibility is measured. A project that is feasible at
one point in time may become infeasible at a later point
Concept of feasibility
checkpoints
Four Tests for
Feasibility
1. Operational
2. Technical
3. Schedule
4. Legal
5. Economic
·
Operational
feasibility
Operational feasibility measures
how well the solution of problems or specific solution will work in the
organization
·
Feasibility
tests
It is also a measure of how people feel
about the system/project
How do the end-users and management feel
about the problem solution
·
Technical
feasibility
Measures the practicality of a specific
technical solution and the availability of technical resources and expertise
Most difficult area to asses at this stage
Go/ No Go Design
Feasibility tests
Three major considerations
Development Risk: can
the system element be designed so that necessary function and performance are
achieved within the constraints uncovered during analysis
Resource
availability:
Has relevant technology progressed to a state to support the
system?
Schedule feasibility:
Measures how reasonable the project timeline is given our
technical expertise, are the project deadlines reasonable?
Missed schedule are bad but inadequate systems are worse
Feasibility Tests need
to determine whether the deadlines are mandatory or desirable. It is preferable
(unless the deadline is absolutely mandatory)
to deliver a properly functioning information system late than to deliver an
error-prone information system on time.
Legal Feasibility
Legal Feasibility is a determination of any infringement,
violation or liability that could result from development of a system.
All projects are feasible – given unlimited resources and
infinite time!
Economic Feasibility
Measures the cost effectiveness of a project or solution.
Often called a cost-benefit analysis.
Generally the bottom line consideration for most systems.
Exceptions: national defence systems, high technology applications e.g. Space
Program.
System Development
Costs
Usually once off costs that will not recur after the project
has been completed.
·
Facilities
·
Equipment and installation
·
Software and licences
·
Consulting fees
·
Training/ personnel costs
The lifetime benefits must
recover both the developmental and operating costs. (Key)
System Operating
Costs
System Operating Costs Recur throughout the lifetime of the system.
Costs classified as fixed and variable
Fixed
costs occur at regular intervals
and at relatively fixed rates
·
Lease
·
Salaries
Variable
costs occur in proportion to some usage factor
·
Supplies
·
Overhead costs e.g. utilities, maintenance
What Benefits Will
The System Provide?
Benefits
normally increase profits or decrease costs.
Tangible Benefits
Tangible Benefits are those that can be easily quantified.
Measured in terms of monthly or annual savings or profit to
the firm.
·
Fewer processing errors
·
Reduced expenses
·
Increased sales
·
Reducing staff- automation of manual functions
Intangible benefits
Intangible benefits are those benefits believed to be
difficult or impossible to quantify
Improved customer goodwill
Improved employee moral
Sales tracking system which leads to better information for
marking decisions
·
Reputation
Pay Back Analysis
Break-even point is when lifetime benefits will overtake the
lifetime costs.
A.
Will our current printer be able to handle the
new reports and forms required of a new system? Technical.
B.
What are the fixed and variable costs of the
operating the system? Economic
C.
Does the system provide adequate throughput and
response time? Operational
D.
Does the system offer adequate service level and
capacity to reduce the costs of business or increase the profits of the
business? Operational
E.
What are the tangible and intangible benefits of
the system? Economic
F.
Does the system offer adequate controls to
ensure against fraud and embezzlement and to guarantee the accuracy and
security of data and information? Operational
G.
Does the system make maximum use of available
resources, including people, time, flow of forms, minimum processing delays, and
the like? Operational
H.
Does management support the system? Operational
I.
What is the net present value of the
system? Economical
J.
How will the working environment of the user
change? Operational
K.
How do the users feel about their role in the new
system? Operational
L.
Do we have the expertise to implement the
solution? Technical
M.
What is the payback period for the proposed
system solution? Economical
N.
Does the system provide users and managers with
timely, pertinent, accurate, and usefully formatted information? Operational
O.
What is the return on investment for the new
system? Economical
P.
Is the project deadline mandatory or
desirable? Schedule
Q.
Does the system provide desirable and reliable
service to those who need it? Operational
R.
Is the system flexible and expandable? Operational
S.
Are the resource available in our data
processing? Technical
Sample Candidate
System
·
Custom
·
Off the shelf
Feasibility analysis
matrix is a tool
We weight each of the of the types of feasibility in
percentages and then sore each section
Net Payback Analysis
The time value of money recognizes that a dollar today is
worth more than a dollar one year from now.
(Future) value (FV) of £1 in n years, at interest rate, i, can be described by the following
equation.
FV =PV(1+i)n
Where
FV = Future value
PV = Present value
n = Number of years
i = Interest rate (discount rate)
Example: Net payback
analysis
The value of €500 after 2 years at an annual interest rate of 6% would be:
FV =500(1+0.06)2 = 500(1.236)=€561.80
Restating the
above equation:
FV/(1+i)n =PV
FV x 1/(1+i)n = PV
Discount factor
Example: Net Payback
Analysis
If you were offered €561.80 in two years time, 6%discount
rate, what is the value today?
€561.80 x 1/(1+0.06)2 = PV
PV = €561.80 X 1/(1.1236)
PV = €561.80 X 0.8899
PV = €500
The discount factor
is always:
1/(1+i)n
The discount factor on a sum to be received a year from now
(6%P.a)
1/(1.06)1=0.94
Two years from now:
1/(1.06)2=0.889
ERD: is an Entity Relationship Diagram
Focus on system data
DFD: is a Data Flow Diagram
Focus on system processes
System Modelling
A model
is a representation of reality
Logical models
Show what
a system “is” or “does”. They are implementation- independent- illustrate the
essence of the system
Physical model
Show what a system “is” or “does” and how the system is physically and technically
implemented- implementation-dependent
System Modelling
System analysis activites focus on the logical system
models:
Logical models removes biases
Logical models reduce the risk of missing business
requirements
Allow us to communicate with end users in a non-technical
language
Data Modelling
Sometimes called data base modelling because a data model is
usually implemented as a data base
The process of constructing data models helps analysis ans
users quickly reach consensus on business terminology and rules.
Data
Models are frequently referred to entity relationship diagrams (ERD)
Entities
All systems contain data-Data describes “things”
A concept to abstractly represent all instances of a group of similar
“things” is called an entity.
An entity is something about which we want to store data.
E.g Persons, Places, Objects, Events about which we need to
capture and store data.
An
entity instance is a single occurrence of an entity
Attributes
The pieces of data that we want to store about each instance
of a given entity are called attributes
Values for each attribute are defined in terms of three
properties: data type,
domain, and default
The data type for attribute:
E.g
Number 10-99
Text max
size 30
Date mmddyy
The domain
The domain of an attribute defines what values an attribute
can legitimately take on.
E.g
Number integers-
10-99
Text max size
30
Date
format- mmddyy
The default value for an attribute is that value which will
be recorded if not specified by the user
E.g number = 0
Key
Hence every entity must have an identifier or key
Candidate Key: where an entity can have more than one –Key-
each of these attributes is called a candidate key
Candidate Key: where a group of attributes is required to
uniquely identifies an instance of an entity
DVD entity in video store
Title NO + Copy No
Primary Key
Is that candidate key which will most commonly be used to
uniquely identify a single entity instance
Type ID (instance Primary Key)
Alternate keys
Are those not specified as primary keys
|
Customer
Customer Number (PK)
Customer Name
Shipping address*
Billing address*
Balance due*
|
|
Order
Order number (PK)
Order date
Order total cost
Customer number
(FK)
|
*alternative
keys
If I took customer name and customer number it would be a
concatenated key
|
Ordered Product
Order product ID
(PK)
Order number (FK)
Product number
(FK)
Quantity ordered
unit price
|
|
Inventory product
Product number
(PK)
Product name
Unit of measure
Unit price
|
A Subsetting criteria
Is an attribute whose values divide all entity instances
into useful subsets.
Need to identify all male students and all female students
Relationships
A relationship
is a natural business association that exits between one or more entities
A connecting line between two entities on an entity relationship
diagram (ERD) represents a relationship
A verb phrase describes the relationship
|
Curriculum
|
|
Student
|
1 or many
Cardinality
The complexity or degree of each
relationship is called cardinality
Cardinality defines the minimum and maximum number
of occurrences of one entity foe a single occurrence of related entity
E.g must there exist an instance
of student for each instance of curriculum? No
Must there exist an instance of
curriculum for each of students? Yes
3 important things in a ERD
1. Attributes
2. Keys
(primary, alternate, foreign)
3. Cardinality
– show symbol and relationship E.g 1 to many
The degree of a relationship is the number ot entities that participate
in the relationship
A Binary relationship has a
degree = 2
Recursive relationship degree =1
An associative entity is an entity that inherits its primary key from
more than one other entity (parents)
Foreign Keys
A foreign key is a primary key of one entity that
is duplicated in another entity for the purpose of identifying instances of a
relationship
A non –specific relationship (or many –to-many
relationship) is one in which many instances of one entity are associated with
many instances of another entity
JAD (joint application
development) sessions
Facts collected by sampling
existing forms and files; researching similar system; surveys of users and
management
How to construct data models
Step 1 – Identify Entity
Entities should be named with nouns that describe the person, event, place, or tangible thing
about which we want to store data.
Step 2 – Define keys for each entity
The value of a key should not
change over the life time of each entity instance.
The value of a key cannot be null (entity
integrity)
Step 3 Draw a rough draft of the ERD model
Step 4 Identify Data Elements/ Attributes
Step 5 Draw the Fully Attributed Data Model
Process Concepts & Conventions
Logical process are work or
actions that must
be performed no matter
how you implement
the system
Each process will be implemented
as one or more physical process that may include:
·
Work performed by people
·
Work performed by robots / machines
·
Work performed by computer soft ware
Three types of logical processes:
functions, events, and elementary
process.
Functions
A function is a set of related
and on-going
activates of the business. A function has no start or end it just continuously performs it’s work as
needed.
Events
An event is a logical unit of
work that must be completed as a whole
Elementary process
An event process can be further
decomposed into elementary processes that illustrate in detail how the system
must respond to an event
Three Errors with process
A black hole is when a process has inputs but no outputs. Data
enters the process and then disappears
A miracle is when a process has output but no input
A grey hole is when the inputs of a process are insufficient to
produce the output(most common)
Process modelling
A technique for organizing
and documenting the structure flow of data through a system analysis /processes
A data flow diagram (DFD)/(bubble graph)
Process model consists of data
flow depicts the flow of data through a system diagram and the work or
processing preformed by the system.
As information moves through
software , modified by series of transformations
Data Flow Diagram
Uses three symbols and one
connection
What are the symbol of a DFD (data flow diagram)
Process
Rounded rectangle or circles represent
process performs
transformation on its input data to yield tis output data
|
Process
|
|
Process
|
External agents or external
entity
Square represent External agents, a source of
system inputs or a sink of system outputs residing outside system
|
Eternal
Agent
|
1.
Data flows should not split into two or more
different data flows
2. Don’t
connect 2 exit entities NB don’t connect to data store
3. Process
need to have at least one input data
flow and one output data flow,
Data stores
Open ended boxes represent data stores, repository of data- never to be shown
in a context diagram
Data Flows
Arrows represent data flows, to connect processes to each other
Rules for DFDs
1.
Each object must connect to at least one other
process- objects is external entity, process, data store, data flow
2.
Each process must use at least one input data
flow and produce one output data flow
3.
Each item in a process’s data flow must
correspond or derive from the process’s input data flow
4.
Each data flow to or from a data store/ external
entity must connect to a process. Maximum 7 process per DFD
Arrange process so that major data flow is
from left to right
Process: verbs
Data flows: external entities; data stores:
nouns
A Process
Is work performed on, or in response to, incoming data flow
or conditions
Process Decomposition
When a complex system is too difficult to fully understand when viewed as a whole
(meaning as a single process)
System analysis separates a system into its component
subsystems, which in turn are decomposed into smaller subsystem
Process abstraction
Process of reducing complexity by mapping details into one
higher level concept, ie. A concept diagram
Never
add data stores to a context diagram
Only one
process, data flows and external entities are placed in a context diagram
Requirements-Gathering
Techniques
Interviews
Most commonly used technique
Basic steps
·
Selecting interviewees
·
Designing interview questions
·
Prepare for the interview
·
Conducting the interview
·
Post-interview follow up
Selecting
interviewees
·
Based on information needs
·
Best to get different perspectives
Managers
Users
Ideally, all key stakeholders
·
Keep organizational politics in mind
Designing interview
questions
·
Unstructured interview useful early in
information gathering
Goal is broad, roughly defined information
·
Structured interview useful later in process
Goal is very specific information
Preparing for
interview
·
Prepare general interview plan
List of question
Anticipated answers and follow ups
·
Confirm areas of knowledge
·
Set priorities in case of time shortage
·
Prepare the interviewee
Schedule
Inform of reason for interview
Inform of areas of discussion
Conducting the
interview
·
Appear professional and unbiased
·
Record all information
·
Check on organizational policy regarding tape
recording
·
Be sure you understand all issues and terms
·
Separate facts from opinions
·
Give interviewee time to ask questions
·
Be sure to thank the interviewee
·
End on time
Post –interview
follow-up
·
Prepare interview notes
·
Prepare interview report
·
Have interviewee review and confirm interview
report
·
Look for gaps and new questions
Joint Application
Development(JAD)
·
A structured group process focused on
determining requirements
·
Involves project team, users, and
management working together
·
May reduce scope creep by 50%
·
Very useful technique
·
Quality : walkthrough, inspections, and formal
technical reviews
JAD Participants
·
Facilitator
Trained in JAD techniques
Sets agenda and guides group processes
·
Scribe(s)
Record content of JAD sessions
·
Users and
managers from business area with broad and detailed knowledge
Preparing for JAD
sessions
·
Time commitment – ½ day to several weeks
·
Strong management support is needed to release
key perticipants from their usual responsibilities
·
Careful planning is essential
·
E-JAD can help alleviate some problems inherent
with groups
Conducting the JAD
Session
·
Formal agenda and ground rules
·
Top- down structure most successful
·
Facilitator activities
Keep session on track
Help with technical terms and jargon
Record group input
Stay neutral, but help resolve issues
·
Post-session follow up report
Post JAD follow –up
·
Post session report is prepared and circulated
among session attendees
·
The report should be completed approximately a
week to two after the JAD session
Questionnaires
·
A set of written questions, often sent to a
large number of people
·
May be paper-based or electronic
·
Select participants using samples of the
population
·
Design the questions for clarity and ease of
analysis
·
Administer the questionnaire and take steps to
get a good response rate
·
Questionnaire follow up report
Good questionnaire
design
·
Begin with nonthreatening and interesting
questions
·
Group items into logically coherent sections
·
Do not put important items at the very end of
the questionnaire
·
Do not crowd a page with too many items
·
Avoid abbreviations
·
Avoid biased or suggestive items or terms
·
Pre-test the questionnaire to identify confusing
questions
·
Provide anonymity to respondents
Document analysis
·
Study of existing material describing the
current system
·
Forms, reports, policy manuals, organization
charts describe the formal system
·
Look for the informal system in user additions
to forms /report and unused form /report elements
·
User changes to existing forms /reports or
non-use of existing forms /reports suggest the system needs modification
Observation
·
Watch processes being preformed
·
Users/managers often don’t accurately recall
everything they do
·
Checks validity of information gathered other
ways
·
Be aware that behaviours change when people are
watched
·
Be unobtrusive
·
Identify peak and lull periods
Selecting the
appropriate requirements- gathering techniques
·
Type of information
·
Depth of information
·
Breadth of information
·
Integration of information
·
User involvement
·
Cost
·
Combining techniques
Reference information attained from course material
Posts
