Final exam review
This presentation is the property of its rightful owner.
Sponsored Links
1 / 67

Final Exam Review PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Final Exam Review

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


Final exam review

SYSTEM

processing

boundary

controls

inputs

outputs

feedback

A Generic System Model

(with Six Components)

  • Examples:

  • Automobile

  • Student Registration System

  • Others...


Final exam review

  • 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)


Final exam review

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


Final exam review

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


Final exam review

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


Final exam review

What is a Systems Analyst responsible for?

Effective and efficient:

  • CAPTURE of input data

  • PROCESSING & STORAGE of data

  • DELIVERY of timely and accurate information


Final exam review

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


Final exam review

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


Final exam review

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


Final exam review

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


Final exam review

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.


Final exam review

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


    Final exam review

    • 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


    Final exam review

    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...


    Final exam review

    • Inheritance

    A mechanism for expressing similarity

    between things thus simplifying their definition.

    Inheritance

    Person

    Student

    Faculty

    Staff

    • looks

    • behavior

    • attitudes

    • etc...


    Final exam review

    • Message Communication

    Objects communicate via messages

    OBJECT

    OBJECT

    OBJECT

    OBJECT


    Final exam review

    • 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


    Final exam review

    • 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


    Final exam review

    • 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


    Final exam review

    • 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...


    Final exam review

    • 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)


    Final exam review

    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”


    Final exam review

    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


    Final exam review

    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


    Final exam review

    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


    Final exam review

    Employee

    attributes

    services

    SalariedEmployee

    HourlyEmployee

    attributes

    attributes

    services

    services

    Hourly-Salaried

    Employee

    attributes

    services

    Object-Oriented Strategy for Mutually Exclusive Attributes


    Final exam review

    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


    Final exam review

    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


    Final exam review

    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


    Final exam review

    Person

    attributes

    services

    Administrator

    Student

    Faculty

    attributes

    attributes

    attributes

    services

    services

    services

    Gen-Spec Example


    Final exam review

    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


    Final exam review

    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)


  • Login