final exam review
Download
Skip this Video
Download Presentation
Final Exam Review

Loading in 2 Seconds...

play fullscreen
1 / 67

Final Exam Review - PowerPoint PPT Presentation


  • 156 Views
  • Uploaded on

Final Exam Review. IDS 306 Spring 1999 Vicki Murphy. 5/11/99. Norman Ch 1 Introduction. 4-5 What is a system 5-6 What is an information system 7 What is an automated information system 10 -12 Both systems analysis and design sections 14 -17 Three sections on systems analysts

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Final Exam Review' - faris


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
final exam review

Final Exam Review

IDS 306

Spring 1999

Vicki Murphy

5/11/99

norman ch 1 introduction
Norman Ch 1 Introduction
  • 4-5 What is a system
  • 5-6 What is an information system
  • 7 What is an automated information system
  • 10 -12 Both systems analysis and design sections
  • 14 -17 Three sections on systems analysts
  • 23-24 IS Requirements Specification
  • 24-25 IS Life Cycle & Information SDLC
  • 26-27 Principles to guide SA&D
slide3
SYSTEM

processing

boundary

controls

inputs

outputs

feedback

A Generic System Model

(with Six Components)

  • Examples:
  • Automobile
  • Student Registration System
  • Others...
slide4
An INFORMATION SYSTEM is:
      • a type of fabricated system
      • used by one or more persons
      • to help them accomplish some task or assignment they have
  • An Information System:
    • supports policies & procedures
    • has three components - data,
      • people, procedures - in addition to
      • the six general system components

data

people

procedures

(input, output, processing, control, feedback and boundary)

slide5
An AUTOMATED INFORMATION SYSTEM IS:
  • a type of fabricated system
  • used by one or more persons
  • to help them accomplish some task or assignment they have
  • utilizes hardware and software

data

people

procedures

software

hardware

slide6
What makes Systems Analysis and Design a difficult activity?
  • Initially, problem domains (areas) tend to have poorly defined BOUNDARIES
  • Problem domain SOLUTIONS are artificial
  • Problem domains are DYNAMIC
  • Problem domain solutions usually require INTERDISCIPLINARY knowledge and skills
  • Systems Analyst’s KNOWLEDGEBASE is continually expanding
  • Systems Analysis and Design is a highly COGNITIVE activity
  • Working with PEOPLE
slide7
What does a Systems Analyst do?

Studies the problems and needs of an organization looking for improvement opportunities for:

  • increasing revenue/profit
  • decreasing costs
  • improving quality of service
slide8
What is a Systems Analyst responsible for?

Effective and efficient:

  • CAPTURE of input data
  • PROCESSING & STORAGE of data
  • DELIVERY of timely and accurate information
slide9
General Model of Information Systems Development (“Partnership”)

Stakeholder

Information

System (6)

Requirements

(1)

Continued

Involvement

(5)

Design

and

Implementation

Requirements Specification

(3)

Analysis

Problem

Definition

Skills (2)

Problem

Solution

Skills (4)

Information

Technology

Staff

slide10
SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

Analysis

  • Planning
  • Feasibility Study (optional)
  • Requirements Determination
  • Conceptual Design
  • Physical Design
  • Construction and/or Purchase (prototype)
  • Conversion - old to new
  • Training
  • Implementation
  • Evolution - maintenance & enhancements

Design

norman ch 2 feasibility rd
Norman Ch 2 Feasibility & RD
  • 30-33 Feasibility Analysis
  • 33-35 Requirements Determination
  • 36-37 Problem Domain
  • 37-38 Frameworks for RD
  • 40-44 Kozar’s Requirements Model
  • 44-45 Object-Oriented RD
  • 46, 47, 50, 51
feasibility analysis
FEASIBILITY ANALYSIS
  • FEASIBILITY (in information systems development) is the measure of how beneficial the development or enhancement of an information system will be to the business
  • FEASIBILITY ANALYSIS is the process by which feasibility is measured
feasibility types
FEASIBILITY TYPES
  • OPERATIONAL FEASIBILITY is the measure of how well a particular information system will work in a given environment
  • TECHNICAL FEASIBILITY is the measure of the practicality of a specific technical information system solution and the availability of technical resources
  • ECONOMIC FEASIBILITY is the measure of the cost-effectiveness of an information system solution
slide14
1. Systems Development Costs(one-time; representative only)
  • Personnel:
  • 2 Systems Analysts (450 hours/each @ $45/hour) $40,500
  • 5 Software Developers (275 hours/each @ $36/hour) 49,500
  • 1 Data Communications Specialist (60 hours @ $40/hour) 2,400
  • 1 Database Administrator (30 hours @ $42/hour) 1,260
  • 2 Technical Writers (120 hours/each @ $25/hour) 6,000
  • 1 Secretary (160 hours @ $15/hour) 2,400
  • 2 Data Entry clerks during conversion (40 hrs/ea @ $12/hr) 960
  • Training:
  • 3 day in-house course for developers 7,000
  • User 3 day in-house course for 30 users 10,000
  • Supplies:
  • Duplication 500
  • Disks, tapes, paper, etc. 650
  • Purchased Hardware & Software:
  • Windows for 20 workstations 1,000
  • Memory upgrades in 20 workstations 8,000
  • Mouse for 20 workstations 2,500
  • Network Software 15,000
  • Office Productivity Software for 20 workstations 20,000
  • TOTAL SYSTEMS DEVELOPMENT COSTS: $161,670
slide15
2. Annual Operating Costs(on-going each year)
  • Personnel:
  • Maintenance Programmer/Analyst (250 hrs/year @ $42/hr) $10,500
  • Network Supervisor (300 hrs/year @ $50/hr) 15,000
  • Purchased Hardware & Software Upgrades:
  • Hardware 5,000
  • Software 6,000
  • Supplies and Miscellaneous items 3,500
  • TOTAL ANNUAL OPERATING COSTS: 40,000
  • -----------------------------------------------------------------------------------------------------------
  • TOTAL COST TO DEVELOP AND OPERATE THE SYSTEM: $201,670

==========

what are requirements
What are Requirements?

Three (3) alternative ways to think about Requirements:

  • Requirements are criteria that are necessary, needed, or demanded.
  • Requirements are implicit or explicit criteria that must, should, or might be met.
  • Requirements equal the wants and needs of the user(s).
observations about requirements
Observations about Requirements
  • Requirements are not supposed to dictate any details regarding the implementation of a solution.
  • We commonly define differing levels of necessity for our requirements, such as “absolutely must be satisfied”, “nice to have”, and “optional”.
  • Some requirements may apply to an entire system, while others apply only to part of the system.
  • Compromise is often necessary for conflicting requirements from different user(s).
  • Some requirements are static, while others are dynamic and evolve or emerge over time.
  • Requirements are not always easy to explain (communicate), understand, or document.
types of requirements
Types of Requirements

There are three major types of requirements:

  • User-Driven
    • not desirable
  • User-Reviewed
    • user and analyst working together
  • User-Independent
    • software product vendors
be suspicious of the quality of requirements
Be Suspicious of the Quality of Requirements

Requirements usually have one or

more of the following 8 problems:

  • Omissions
  • Contradictions
  • Ambiguities
  • Duplications
  • Inaccuracies
  • Introduced elements
  • Too much design
  • Irrelevant information
slide20
Framework: Requirements Model (Kozar)*

A strategy that links information systems activities with

established business activities.

PREMISE: Information systems support business

activities; therefore, associating information systems

activities with business activities should be possible.

Provides verification and validation (V & V) traceability

* Adapted from Kozar, K.A., Humanized Information Systems Analysis and Design,

McGraw-Hill Inc., 1989, pp. 61-62 and personal communication with the author.

slide21
Kozar’s Requirements Model

Hired a marketing consultant

Recommends better tracking

of where sales orders come from

Mkt. code on each promo. piece

mailed out

Develop mkt. codes

Track sales based on mkt. codes

Reports showing promo. piece

effectiveness

Modify Sales Order Fulfillment Sys

(about 2 dozen changes)

STIMULI

BUSINESS

OBJECTIVES

BUSINESS

TACTICS

INFO. SYS.

OBJECTIVES

INFO. SYS.

TACTICS

A change of some type

forces changed enterprise needs

causing changed user behaviors

requiring changed information needs

requiring changed I.S. activities

BENEFITS

COSTS

BENEFITS

COSTS

an object oriented requirements determination methodology
AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY

The preceeding four (4) activities are performed for each of four (4) Object Model Components:

  • Problem Domain component (PD)
  • Human Interaction component (HI)
  • Data Management component (DM)
  • System Interaction component (SI)
an object oriented requirements determination methodology1
AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY

Four Activities:

1. Identify the purpose and features of the information system

2. Identify objects and patterns

3. Establish object responsibilities - attributes, relationships, and services

4. Work out the information system’s dynamics using scenarios

some final thoughts regarding requirements determination
Some Final Thoughts Regarding Requirements Determination
  • People ARE Different! (Thinking & Behaviors)
  • Each Software Development Project Is Different!
  • Requirements Determination Is an Iterative Process
  • Some Sub-Processes May Be Accomplished Concurrently
  • The Requirements Determination Effort May Be Accomplished At More Than One Point In the Life-Cycle
  • The Requirements Determination Effort May Be Driven By External or Uncontrollable Circumstances
  • Requirements Determination Should Not Be Driven By Low-Level Issues
  • Verification, Validation, and Quality Assurance Are Always Important for Requirements Determination
  • Corrections and changes to Requirements late in the SDLC may cost between 30 and 70 times their cost if done initially
norman ch 3 o o model
Norman Ch 3 O-O Model
  • 55-56 Methodologies
  • 60-66 Key Characteristics of O-O
  • 68-71 Coad’s OO A&D Methodology
  • 73 component definitions
  • 73-82 An Object-Oriented Model
methodology overview
METHODOLOGY OVERVIEW
  • Classifications of Methodologies
      • Traditional
      • Structured Analysis and Design
      • Information Modeling/Engineering
      • Object-Oriented
  • Prototyping is a technique - (some say that it is a methodology)
object technology principles
Object Technology Principles
  • Abstraction
  • Encapsulation (Information Hiding)
  • Inheritance
  • Message Communication
  • Associations
  • Polymorphism
  • Common Methods of Organization
  • Reuse
slide29
Abstraction

A mental ability that permits people to view real-world problem domains with varying degrees of detail depending on the current context of the problem.

  • Helps people to think about what they are doing
  • Functional and Data abstraction
slide30
cake
  • Encapsulation (Information Hiding)

A technique in which data are packaged together with their corresponding procedures.

  • In Object-Oriented Technology the “package” is called an OBJECT
  • The interface to each object is defined in such a way as to reveal as little as possible about its inner workings
  • Encapsulation allows [software] changes to be reliably made with limited effort [Gannon, Hamlet, & Mills, 1987]

One cake please!

Ingredients

2 eggs 4 cups flour

1 cup milk 1 cup sugar

etc.......

Directions

Pre-heat oven to 350; Put

milk, eggs, and sugar

in 2 quart mixing bowl...

slide31
Inheritance

A mechanism for expressing similarity

between things thus simplifying their definition.

Inheritance

Person

Student

Faculty

Staff

  • looks
  • behavior
  • attitudes
  • etc...
slide32
Message Communication

Objects communicate via messages

OBJECT

OBJECT

OBJECT

OBJECT

slide33
Associations

The union or connection of ideas or things.

(Objects need to interact with each other)

  • same point in time
  • under similar circumstances

crime

scene

#2

crime

scene

#1

Advertisement #2

Advertisement #1

Billing Statement

crime

scene

#n

slide34
Polymorphism (“many forms”)
  • The ability to hide different implementations behind a common interface.
  • The ability for two or more objects to respond to the same request, each in its own way.
  • H O = water, ice, steam (liquid, solid, vapor)
  • Eating

2

Door

#1

#2

#3

Door

#1

Door

#2

Door

#3

versus

slide35
Polymorphism
  • Two examples

PRINT

TEXT object

PRINT

GRAPH object

PRINT

IMAGE object

PO object

= add a line item to the PO

Add

Object #1

= increase $ Amount Balance

Account object

Object #2

Add

Department object

= hire a new employee

Object #3

Add

o o systems analysis design methodology
O-O Systems Analysis & Design Methodology

Classification Theory

(Common Methods of Organization)

  • Objects and their characteristics
  • Wholes and Parts
  • Groups (Classes) and Members
slide37
Common Methods of Organization

People are accustomed to thinking in terms of...

Objects & Attributes

  • color
  • price
  • weight
  • engine
  • options...

Wholes and Parts

Groups & Members

  • number of doors
  • number of wheels
  • number of windows
  • number of lights
  • number of bolt type 1
  • number of bolt type 2
  • etc....
  • VANS:
  • light utility
  • utility
  • passenger
  • etc...
slide38
Reuse

The ability to reuse objects

  • Varying Degrees of Reuse:
      • complete or sharing
      • copy, purchase or cloning
      • partial or adjusting
      • none
  • Software:
  • “Chips”
  • Components
  • Controls
  • Models
model components
Model Components
  • Problem domain -- directly correspond to the problem being modeled
  • Human interaction -- provide interface between the PD objects and people
  • Data management -- provide interface between PD objects and a database or file management system
  • System interaction -- provide interface between PD objects and other systems or devices
coad s object model notation
Coad’s Object Model Notation

model component

class with objects

class

coad s object model notation1
Coad’s Object Model Notation

Expanded view

of a class or

class with objects

into its three

sections:

top: Class Name

middle: attributes

bottom: services

Member

{

memberNumber

firstName

lastName

telephone

address

city

etc...

Attributes

{

checkOutVideo

checkInVideo

buyItem

etc...

Services

coad s object model notation2
Coad’s Object Model Notation

whole-part

object connection

generalization-specialization

connection

n-n

1

object connection

message

n

n

n

norman ch 4 objects classes
Norman Ch 4 Objects & Classes
  • 87-88 Objects & Classes
  • 89 Figure 4.2
  • 89-91 Class Attributes & Services Defined
  • 92 Finding Objects
  • 95-96 (challenging objects)
slide44
Defining Objects

An OBJECT is an abstraction of a person, place,

thing, or concept within the problem domain that

the information system must be aware of.

...Objects are “instantiated” (created)

...the term “instance” is interchangeable with “object”

slide45
Objects
  • Objects have three responsibilities:
  • What they know about themselves - Attributes
  • What they know about other objects - Relationships
  • What they do - Operations
a class with no objects is often referred to as an abstract class

A CLASS with no objects is oftenreferred to as an ABSTRACT CLASS

Person

Faculty

Administrator

Student

rules and guidelines for the object model notation
1. Objects must always belong to a class.

2. The first letter of class names and the first letter of each word in the class name should be capitalized.

Examples: Student, Bicycle, DataEntryClerk.

3. All names of classes, attributes and services should be singular. Examples: Student instead of Students; Bicycle instead of Bicycles; DataEntryClerk instead of DataEntryClerks.

4. All names of classes, attributes and services should be meaningful. Examples: SalesDept, AccountsPayable, Cashier, SaleLineItem.

5. The class notation symbol is partitioned into 3 parts:

Name, attributes and services.

6. Attribute and service names should start with a lower case letter; each additional word used in the name should begin with a capital letter. Example: studentIdNumber, inventoryControlNumber, gradePointAverage, requestTranscript, calculateSalesTax.

Rules and Guidelines for the Object Model Notation
challenge classes objects based on
CHALLENGE CLASSES/OBJECTS BASED ON:
  • More than one Attribute
  • Needed services
  • Needed remembrance
  • More than one Object
  • Avoid derived (computed) results
norman ch 5 attributes
Norman Ch 5 Attributes
  • 103-106 Attributes
  • 107-108 Attribute Types
  • 109-112 Both sections on OO Strategy
    • be sure to check your errata sheet
slide50
Student

studentName

studentIDNumber

eyeColor

height

weight

dateOfBirth

etc...

services

studentName studentIDNumber eyeColor height weight dateOfBirth

MIchael W Smith

Amy Grant

559-46-0912

371-38-7640

Blue

Brown

5ft 9in

5ft 6in

155

118

4-12-74

12-2-73

Single Value Attributes Example

slide51
Employee

employeeName

employeeID

hourlyRate

weeklySalary

services

employeeName employeeNumber hourlyRate weeklySalary

559-46-0912

371-38-7640

$9.75

MIchael W Smith

Amy Grant

$475.00

mutually exclusive attributes with values

Mutually Exclusive Attribute Values Example

slide52
Employee

attributes

services

SalariedEmployee

HourlyEmployee

attributes

attributes

services

services

Hourly-Salaried

Employee

attributes

services

Object-Oriented Strategy for Mutually Exclusive Attributes

slide53
Student

studentName

studentIDNumber

collegeAttended

collegeGradePointAvg

services

studentName studentIDNumber collegeAttended collegeGradePointAvg

559-46-0912

371-38-7640

270-73-9815

Grossmont

Point Loma

NY Univ.

Golden Gate

Georgia State

U of San Diego

2.9

2.7

3.2

2.2

2.9

3.1

MIchael W Smith

Amy Grant

M.C. Hammer

multi-value attributes with values

Multi-Value Attributes Example

slide54
studentName studentIDNumber

Student

559-46-0912

371-38-7640

270-73-9815

MIchael W Smith

Amy Grant

M.C. Hammer

studentName

studentIDNumber

services

0,m

collegeAttended gradePointAvg

1

Grossmont

Point Loma

NY Univ.

Golden Gate

Georgia State

U of San Diego

2.9

2.7

3.2

2.2

2.9

3.1

CollegeAttended

collegeAttended

gradePointAvg

services

Student and CollegeAttended

Whole-Part Class with Objects Connection

norman ch 6 connections
Norman Ch 6 Connections
  • 117 “Who I Know”
  • 118 Object Patterns
  • 118-124 Gen-Spec Pattern
  • 125- top 126 Gen-Spec Inheritance
  • 128-136 Whole-Part
  • 136-139 Object Connection Patterns
slide56
Generalization-Specialization Class Connection

Generalization

attributes

services

Specialization2

SpecializationN

Specialization1

. . .

attributes

attributes

attributes

services

services

services

The generalization-specialization (Gen-Spec) pattern

  • Gen-Spec can be used to resolve mutually exclusive attributes
slide57
Person

attributes

services

Administrator

Student

Faculty

attributes

attributes

attributes

services

services

services

Gen-Spec Example

slide58
Generalization-Specialization Pattern Guidelines

1. A gen-spec follows the “is a” or “is a kind of” heuristic.

2. The gen-spec notation symbol is an ARC or semicircle.

3. The line connecting a generalization with a

specialization starts with the generalization’s class

squircle (bold line symbol) and ends with the

specialization’s class squircle (bold line symbol).

4. Specialization objects are not connected to any

generalization objects as they are separate and distinct.

5. Specializations have their own attributes and/or

services as well as inheriting additional attributes and/or

services from the generalization node above them.

6. Inherited attributes and services may be overriden or

enhanced at the specialization node level.

7. Multiple inheritance is allowed but can complicate

the object model’s understanding and implementation.

whole part object connection
Whole-Part Object Connection

Whole

attributes

services

x

x

x

x

x

x

Part2

Part1

PartN

attributes

services

attributes

services

attributes

services

Note: In this template, “x” represents many possible

object connection constraints, such as:

0 - n 1 - n 1 - 5 1 25 any integer

  • Whole-Part can be used to resolve multi-value attributes
slide60
Whole-Part Object Connection Pattern Guidelines
  • 1. A whole-part object connection follows the “has a” heuristic which is read from the WHOLE to the PART
  • 2. The whole-part notation symbol is a TRIANGLE.
  • 3. The line connecting a WHOLE with a PART starts with the Whole’s Object squircle (thin line symbol) and ends with the Part’s Object squircle (thin line symbol).
  • 4. A Part Object may or may not be connected to a Whole Object depending on the Object Connection Constraint.
  • 5. Whole Objects have their own distinct attributes and services and so do the Part Objects - there is NO inheritance.
  • 6. Whole-Part object connections use the “object connection constraint” concept.
object connections
Object Connections
  • “Softer” connection than a whole-part
  • Necessary for a Class with Objects to fulfill its responsibilities
  • Includes “object connection constraints” just as whole-part connection
norman ch 7 services scenarios
Norman Ch 7 Services & Scenarios
  • 149-150 “What I Do”
  • 151-154 Basic Services
  • 154-159 PD Specific Services
  • 164-165 Techniques
  • 165-166 Scenarios
  • 166-168 Pseudocode
services
Services
  • Synonyms: methods and functions
  • Definition: Actions performed to fulfill the purpose of the information system and meet the needs of the user.
  • Respond to an event that happens:
      • External events - business activities
      • Internal events - messages sent to accomplish a service’s intended purpose
types of services
Types of Services
  • Basic - implied or implicit (not listed)
      • create an object
      • search for an object
      • get and set attribute values
      • add and remove object connections
      • delete an object
  • Problem domain specific
encapsulation and reuse services example
Encapsulation and Reuse Services Example

Student

ClassName

enterStudentIDNumber

validateIDNumber

enterClassScheduleNumber

validateClassScheduleNumber

checkSeatAvailability

checkStudentRestrictions

reserveSeatInClass

addClass

NOTE: The addClass service requests the assistance of each of

the other services (which are either part of the Student Class or

some other Class within the information system) in order to

carry out its intended purpose.

addClass responds to external event; others respond to internal event

describing service details
Describing ServiceDetails
  • Scenarios
  • Structured English or Pseudocode
  • Decision Tables and Decision Trees
  • State-Transition Diagrams
scenarios
Scenarios
  • Specific time-ordered sequence of object interactions
  • Service scenarios have three parts:
      • sender class & service (optional)
      • receiver class and service
      • parameters & number of invocations (optional)
ad