Information Systems 414

Test Week Notes

Introduction:
Information System

It is an arrangement of
o people,
o data,
o processes,
o interfaces,
o technology,
o networks
that interact to
o Support and improve day-to-day operations in a business,
o Support the problem-solving and decision-making needs of
management.

Chapter 1:
Systems, Roles and Development
Methodologies
Systems Analyst

Roles of a Systems Analyst:

o Consultant Do not work for the business and hired to address a specific
IS problem
o Supporting Expert Help an analyst with better understanding the
business structure and needs
o Agent of Change A person who serves as a catalyst for change,
develops and implements a plan for change.
Qualities of a Systems Analyst:
o Problem Solver
o Communicator
o Strong personal and professional ethics
o Self-disciplined and self-motivated

Systems Development Life Cycle (SDLC)

A phased approach to analysis and design which holds that the systems are
best developed through the use of a specific cycle of analyst and user
activities
7 Phases of SDLC
1. Identify problems, opportunities & objectives
Identify and record all problems,
opportunities & objectives for
management to read and implement
2. Determine human information
requirements
Understand the current system and
begin to know how to improve it
3. Analysing system needs
Create a proposal for a new system
Use DFDs, Activity diagrams,
Sequence diagrams, Data dictionaries etc.
4. Designing the recommended system
Design and model a new system
5. Developing and documenting software
Analysts and developers work to develop a new system
6. Testing and maintaining the system
Test and debug system
7. Implementing and evaluate system
Train users to properly use the new system
Impact of maintenance

CASE
Tools
o
o
o
o
o
o
o
o
o
o
o
o
Computer-aided software engineering tools that have been created
explicitly to improve work through automated support
o Reasons why analysts make use of them:
Increases analyst productivity
Improves analyst-user communication
Integrating life cycle activities

Agile Approach

It is Incremental and Iterative

Based on
o Values
o Principles
o Core practices
So as to adjust resources such as
o Time
o Cost
o Quality
o Scope
5 Stages of agile Development
o Exploration
o Planning
o Iterations to first development
o Productionising
o Maintenance

Object Orientated Analysis and

Design (O-O)

Alternative approach to the SDLC

that intends to facilitate the development of systems that change rapidly.

Conclusion:
Use
SDLC
Agile
Object
Oriente
d

When
Systems have been developed & documented in SDLC
It is important to document each step
There is a project champion of Agile methods in the organisation
The customer is happy with incremental improvements
Organisation supports the UML learning
Systems can be added gradually, one subsystem at a time

Chapter 2:
Understanding and Modelling
Organizational Systems
Systems

An interrelated set of objects that cooperate to achieve a common

goal
All systems and subsystems are interrelated and interdependent

Organisational Environments

Community
o Physical location
Economic
o Market factors
Political
o State and local Government
Legal
o Federal, state, Regional, local laws and guidelines

The Doughnut Principle

It requires looking at the whole problem in its entirety ehilst also

focusing on the Hole.

Enterprise Resource Planning

An ERP is an IT structure that links all departments in a company so

that all workers can make informed decisions
Software that helps the flow of information between the functional
areas within the organisation
Issues to overcome for ERP Success:
o User acceptance
o Integration with legacy systems and the supply chain
o Upgrading functionality of ERP modules
o Reorganising work life of users and decision makers
o Expanded reach across several organisations
o Strategic repositioning of the company

Levels of Management

Operational Control
o Oversee operating details of the organisation
Execute tasksManagerial Planning and Control
o Make short term plans regarding resources and objectives
o Manage resources
Strategic Management
o Look onward from the organisation to the future

o Set long term goals

Chapter 3:

Project Management

Project Management Fundamentals

Project Initiation
Determine Project Feasibility
Activity Planning & Control
Project Scheduling
Managing System Analysis Team Members

Selection of Projects

Backing from management

Appropriate timing of project commitment
Possibility of improving attainment of organisational goals
Practical in terms of resources for the system analyst and organisation
Worthwhile project compared with other ways the organisation could
invest resources

3 Key Elements to Feasibility

Technical Feasibility
o Is the technology available or easy to
upgrade?
Economic Feasibility
o Is the cost of the project less than the
value it adds?
Operational Feasibility
o Is it user friendly once it has been
installed?
Cloud Computing

3 main categories of Cloud Computing

o Software as a Service (SaaS)
You buy access to an application
o Infrastructure as a Service (IaaS)
Your hardware is outsourced to the
vendor
o Platform as a Service (PaaS)
Combination of above
Benefits:
o Less time spent on maintenance
o May be simpler to acquire IT services
o Can be expanded
o Consistency across multiple platforms
o Capital is not tied up

Drawbacks
o Loss of control of data stored
o Potential security threats
o Reliability on internet

Alternatives to software acquisition

Create your own software

Commercial off the shelf software
Software as a service

Advantages and disadvantages of Hardware vs. Software

Hardwa
re

Softwar
e

Advantages
Full control over hardware &
software
Cheaper in the long run
Maintenance & Upgrades done
by provider
Scalable

Chapter 6:

Disadvantages
High initial cost
Risk of being stuck if choice is
wrong
No control of data
Potential security threat

Agile Modelling and Prototyping

Prototyping

Prototyping is an information gathering technique useful in seeking

o User Reactions
o Suggestions
o Innovations
o Revision Plans
Kinds of Prototypes
o Patched-Up Prototype
A fully functional model that has all the features but is
inefficient
o Non-Operational Prototype
Used to teste certain parts of the prototype, but is not
operational
o First-of-a-Series Prototype
A Pilot implementation
o Selected features Prototype
A prototype that only uses certain features
Prototyping as an Alternative to SDLC
o SDLC Is long and requirements change
o Rather than using prototyping to replace SDLC, us Prototyping and
SDLC together

Guidelines for developing a Prototype

o Work in manageable modules
o Build the prototype rapidly
o Modify the prototype in successive iterations
o Stress the user interface

Advantages:
o Potential for changing the system early in its development
o Opportunity to swop development on a system that is not working
o Possibility of developing a system that more closely addresses
users needs and expectations
Disadvantages
o It can be difficult to manage prototyping as a project in the larger
systems effort
o Users and analysts may adopt a prototype as a completed system
Users role in prototyping
o Experimenting with the prototype
o Giving open reactions to the prototype
o Suggestions

Agile Modelling

A collection of innovative, user-centred approaches to systems

development
Values of Agile Modelling
o Communication
o Simplicity
o Feedback
o Courage
Activities of Agile Modelling
o Coding
o Testing
o Listening
o Designing
Resources of Agile Modelling
o Time
o Cost
o Quality
o Scope
Core Agile Practices
o Short Releases
o 40-hour work Week
o Onsite Customer
o Pair Programming

Chapter 7:

Using Data Flow Diagrams

What is a DFD?

A structures analysis technique that allows system analysts to put

together a graphical representation of data processes and flows in a
business system.

DFD Symbols

Developing DFDs

Make a list of business activities

Create a Context Diagram
Draw Diagram 0
Crete a Child Diagram
Check Diagram for errors
Create physical DFD from Logical DFD

Logical vs. Physical DFD (2 Types)

Logical Focuses on the business and how it operates

Physical Shows how the system will be implemented

Advantages of the DFD Approach

Freedom from committing to the technical implementation too early

Understanding of the interrelatedness of systems and subsystems
Communicating current system knowledge to users
Analysis of the proposed system

Chapter 10:
UML

Object-Oriented Systems and Design Using

Object Oriented Systems

O-O Analysis and Design (Why O-O approach)

o Works well in situations where complicated systems are
undergoing continuous maintenance, adaption and design
o Build systems that are responsive to changing business
landscapes
O-O Concepts
o Objects
Persons, places or things that are relevant to the system
being analysed
Grouped into Behaviours and Attributes
o Classes
A set of shared attributes and behaviours found in each object
in a class
Attributes some property that is possessed by all objects in
a class
Method an action that can be requested from any object
from a class
o Inheritance
When a derived class inherits all the attributes and
behaviours of the base class

What makes O-O programming different from Classical Programming

o All of the objects attributes and methods are put within one selfcontained structure the class

Unified Modelling Language (UML) Concepts and Diagrams

The result of collaboration of individual O-O methods that have been

adopted as a standard for modelling O-O systems
Major Elements
o Things The Objects
o Relationships The glue that holds the things together
o Diagrams Categorised as either structural or behavioural

Behavioural Relationships
o Communicates
o Includes
o Extends
o Generalises
Behavioural Diagrams
o Use Case Diagrams
Describe what the system does
Starting point for UML Modelling
o Activity Diagram
Illustrated the overall flow of activities

Use Case Modelling

Describes what the system does without describing how it does it

Provides 3 things
o An actor that initiates an event
o An event that triggers a use case
o The use case that performs the actions triggered by the event
Use Case Relations
o Communicates Used to
connect an actor to a use case
o Includes Situation in which
a use case contains a
behaviour that is common to
more than 1 use case
o Extends When 1 use case
varies the outcome of another
use case
o Generalizes 1 thing is more
typical that another
(NOTE: See hand-written notes for better description)

Developing Use Case Diagrams

o Review business specifications and identify the actors involved

o May use Agile Stories

o Identify high level events and develop primary use cases that
describe events and how actors initiate them
o Review each primary use case to determine possible variations of
flow
o Context DFD should act as a starting point
Main reasons for use cases
o Use Case allow for people to tell stories
o Use Case stories make sense to nontechnical people
o Use Cases do not depend on a special language
o Use Cases help analysts define boundaries

Things included in a Use Case Scenario

o Name and description
o Identifiers
o Initiators
o Steps performed and information required per step
o Preconditions
o Post-conditions Assumptions
o Questions

Activity Diagrams

Show the sequence of activities in a process including sequential

and parallel activities, and decisions that are made
Constructed for each Use Case
Symbols:

Creating Activity Diagrams

o Ask what happens first, second etc.
o Determine which activities are done in sequence and parallel
o Sequence can be determined from physical DFDs
o Can be created by examining all scenarios for a Use Case

Chapter 8:

Analysing Systems Using Data Dictionaries

The Data Dictionary

A reference work of data about data (metadata), compiled by

systems analysts to guide them through analysis and design
Must be consistent and accurate
o Means that every time (consistency) a data value is accessed, it
represents the correct value (accuracy) associated with it.
Where it fits in
o It is the bridge between processes and data structures/stores
How Data dictionaries relate to DFDs

Need for understanding Data Dictionary

o Provide documentation
o Eliminate redundancy
o Validate the DFD
o Provide a starting point for developing screens and reports
o Determine the contents of data stored in files
o To develop the logic for the DFD processes
Data dictionary Categories
o Data Flows
o Data Structures
o Elements
o Data Stores
Describing Data Structures
o =
is composed of
o +
and
o {}
repetitive elements
o [|]
either/or
o ()
optional elements
Logical vs. Physical Data Structures
o Logical Show what data the business needs for its day-to-day
operations
o Physical Include additional elements necessary for
implementing the system
Structural Records
o A group of elements such as Name, Address & Number
Difference between Data Structures and Elements
o A data structure consists of none or few substructures and has 1
or more basic data elements. The elements are the lowest basic
type that a data structure can be broken into.
Data element Characteristics
o Element ID

o Name of element
o Aliases
o Short description of the element
o Elelment is base or derived
o Element Length
o Type of data
o Input and output formats
o Validation criteria
o Default value
o Additional comment or remark area
Data truncation
o If an element is too long, data will be truncated
Types of Data
o Alphanumeric or text data
Data Stores
o Created for each different data entity being stored
Difference between base and derived element
o A base element is one that is initially keyed into the system
o A derived element is one which is created/ derived by the process

Chapter 9:
Decisions

Process Specifications and Structured

How process specifications Relate to the DFD

Structured English

Used when the process logic involves formulas or iteration, or when

structured decisions are not complex
Structured English Types:
o Sequential Action 1
Action 2
o Decision If A is TRUE
THEN implement Action A
ELSE implement Action B
ENDIF
o Case IF Case 1 implement Action 1
ELSE IF Case 2
implement Action 2
ENDIF
o Iteration DO WHILE there are customers
Action1
ENDDO
Advantages
o Clarifying the logic and relationships found in human languages
o An effective communication tool, it can be taught to and
understood by users in the organisation
When to use which Process Specification
Structured
English
Decision Tables

Many repetitious actions

Communication to end users is important
Complex combinations of conditions, actions and rules

are found
You require a method that effectively avoids impossible
situations, redundancies and contradictions
Sequence of conditions and actions is critical
When not every condition is relevant to every action

Decision Trees

Difference between Structured and Semi-Structured Decisions

Structured decisions are clear and often taken by machines, whereas
semi-structured decisions are taken with human intervention

Chapter 13:

Designing Databases
Store Data ONCE!

Data Storage

The data must be available when the user wants to use it

The data must be accurate and consistent
Efficient storage of data as well as efficient updating and retrieval
It is necessary that information retrieval be purposeful
2 Approaches to the storage of data in a computer based system:
o Store the data in individual files, each unique to a particular
application
o Store data in a database

Database

A formally defined and centrally controlled store of data intended for

use in many different applications
5 effectiveness objectives
o Data can be shared
o Ensure data is readily available
o Allow users to construct their own personal view of the data
o Maintaining data thats accurate and consistent
o Allow database to evolve as user needs change/grow

3 Data concepts

Reality The real world

Data Collected about people, objects or events in reality and
eventually stored in a file or database
Metadata Information that describes data

Entities

Any person, object or event about which a person chooses to collect

data

3 Types
o Primary

o Attributive

o Intersection

Entity

Entity

entity

Consists of
o Rows Records
Collection of properties/characteristics of an entity
o Columns Attributes
Some characteristic of an entity

Relationships

Shows how entities interact

Types:
o One-to-one
o One-to-many
o Many-to-many

Keys

Data items in a record used

to uniquely identify the record
Key Types
o Primary Key unique attribute for the record
o Composite Key a combination of 2 or more attributes
representing the key
Key Properties
o Uniquely identify records
o Are dataless (no text or dates)
o Are never null
o Never change
o Can be used in combination
Transaction Records

Used to enter changes that update the master file and produce
records

Optionalites

We refine the Entity-Relationship Diagram by adding optionalities to

the relationships
Once optionalities are added to the ERD, we call it an Extended
Entity-relationship Diagram (EERD)
Used to describe One-to Many relationships

Difference between ERD and EERD

EERD contains intersection entities

EERD contains optionalities

Normalisation

The transformation of complex user views and data stores to a set of

smaller, stable and easily maintainable
data structures
3 Major steps
o Remove Repeating groups
o Remove Partial dependencies
o Remove Transitive dependencies
First Normal Form (1NF)
o Remove repeating groups
o The primary key with repeating
group attributes are moved into a
new table
o When a relation contains no
repeating groups, it is in 1NF
Second Normal Form (2NF)
o Remove any partially dependant
attributes and place them in another
relation
o A partial dependency is when the data is dependent on part of a
primary key
o A relation is created for the data that is only dependent on part of
the key and another for data that is dependent on other parts
Third Normal Form (3NF)
o Must be in 2NF
o Remove any transitive dependencies
o A transitive dependency is when a nonkey attribute is dependent
not only on the primary key, but also on a nonkey attribute

Integrity Constraints

Entity Integrity
o Primary key cannot be null
o If the primary key is a composite key, none of the fields in the
key can be null
Referential Integrity
o Governs the nature of records in a one-to-many relationship
o Referential integrity means that all the foreign keys in the many
table (child table) must have a matching record in the parent
table
o Implications:
Cannot add a record to the many table without a matching
record in the parent table
Cannot change a primary key that has a matching child table
record
You cannot delete a record that has child records
o Implemented in 2 ways
A restricted database updates or deletes a key only if there
are no matching child records
A cascaded database will delete or update all child records
when a parent record is deleted or changed
Domain Integrity
o Domain integrity rules are used to validate data
o Has 2 forms:
Check constraints, which are defined at the table level
Rules, which are defined as separate objects and can be used
within a number of fields
Anomalies

Data Redundancy
o When the same data is stored in 1 place in the database
o Solved by being in 3NF
Insert Anomaly
o Occurs when the entire primary key is not known and the
database cannot insert a new record, which would violate entity
integrity
o Can be avoided by using a sequence number for a primary key

Deletion Anomaly
o Happens when a record is deleted that results in the loss of other
related data
Update Anomaly
o When a change to one attribute value causes the database to
either contain inconsistent data or causes multiple records to
need changing
o May be prevented by being in 3NF