write a 2-page Class Journal (Need it by tomorrow night)

hopman2t

IS531_Lecture-2.ppt

Home >Information Systems homework help >write a 2-page Class Journal (Need it by tomorrow night)

http://www.csun.edu/~dn58412/IS531

Lecture 2

Systems Development Process

Learning Objectives

Systems Development Life Cycle vs. Systems Development Process

Zachman Framework and Stakehoders’ Perspectives in Systems Development

Classic Phases in Systems Development Process

IS 531 : Lecture 2

Systems Development
Life Cycle (SDLC)

Systems Development Life Cycle (SDLC) :the factoring of the lifetime of an information system into two stages, (1) systems development and (2) systems operation and maintenance.
Systems Development Process :a standardized methodology defines a set of activities, methods, best practices, deliverables, and tools for system developers and project managers to develop and continuously improve information systems and software.

IS 531 : Lecture 2

Systems development life cycle (SDLC) – The overall process for developing information systems from planning and analysis through implementation and maintenance

IS 531 : Lecture 2

Systems Development
Life Cycle (SDLC)

IS 531 : Lecture 2

Systems Development
Life Cycle (SDLC)

IS 531 : Lecture 2

Where Do Systems Development Projects Come From?

Problem – an actual undesirable situation that prevents the organization from fully achieving its purpose, goals, and/or objectives.
Opportunity – a chance to improve the organization even in the absence of an identified problem (using PIECES framework).
Directive - a new requirement that is imposed by management, government, or some external influence/parties.

IS 531 : Lecture 2

PIECES Framework for Systems Improvement

P the need to improve performance

I the need to improve information (and data)

E the need to improve economics, control costs, or

increase profits

C the need to improve control or security

E the need to improve efficiency of people and processes

S the need to improve service to customers, suppliers, partners, employees, etc.

IS 531 : Lecture 2

Where Do Systems Development Projects Come From?

Planned Projects

An information systems strategy plan has examined the business as a whole to identify those system development projects that will return the greatest strategic (long-term) value to the business
A business process redesign has thoroughly analyzed a series of business processes to eliminate redundancy and bureaucracy and to improve efficiency and value added. Now it is time to design/redesign the supporting information system for those redesigned business processes.

IS 531 : Lecture 2

No additional notes.

Where Do Systems Development Projects Come From?

Unplanned projects

Triggered by a specific problem, opportunity, or directive that occurs in the course of doing business.
Steering committee – an administrative body of system owners and information technology executives that prioritizes and approves candidate system development projects.
Backlog – a repository of project proposals that cannot be funded or staffed because they are a lower priority than those that have been approved for system development.

IS 531 : Lecture 2

No additional notes.

Problem-Solving

What “problems” to solve: (Project Definition)

True problem situations, either real or anticipated, that require corrective action
Opportunities to improve a situation despite the absence of complaints
Directives to change a situation regardless of whether anyone has complained about the current situation

IS 531 : Lecture 2

Problem-Solving …

Why: (Project Justification)

Effective: Do right thing
Efficient: Do thing right
Competitive: Do thing differently

IS 531 : Lecture 2

Zachman Framework

IS 531 : Lecture 2

Perspectives on
an Information System

IS 531 : Lecture 2

System Stakeholders

System owners
System users
System analysts
System designer
System builder

IS 531 : Lecture 2

System Owners

System owners – an information system’s sponsors and executives advocate, usually responsible for funding the project of developing, operating, and maintaining the information system. They define the SCOPE of a system: what business problem to be solved
They view the system in term of cost/benefit to solve a business problem

IS 531 : Lecture 2

System Users

System users – use or are affected by an information system on a regular basis – capturing, validating, entering, responding to, storing, and exchanging data and information. They define the REQUIREMENTS of the system.
Internal users
External users

IS 531 : Lecture 2

System designers translate system users’ business requirements and constraints into technical solution: computer databases, inputs, outputs, networks, and software meeting the system users’ requirements. Their activities relate to the DESIGN of a system

System Designers

IS 531 : Lecture 2

System builders constructs information systems based on the design specifications from the system designers. Their activities relate to building the COMPONENTS of the system.

System Builders

IS 531 : Lecture 2

Systems Analysts

Systems analysts study the problems and needs of an organization to determine how people, data, processes, and information technology can best accomplish improvements for the business. They are FACILITATORS of the system development project.

A programmer-analyst

A business analyst / consultant

IS 531 : Lecture 2

HIS Professional Involvement in Systems Development

User

Analyst

Purchaser

Implementer

Consultant

Internal Auditor

External Auditor

IS 531 : Lecture 2

Focuses for
Information Systems

KNOWLEDGE (Data) — the raw material used to create useful information.
PROCESSES — the activities (including management) that carry out the mission of the business.
COMMUNICATION (Interfaces) — how the system interfaces with its users and other information systems.

IS 531 : Lecture 2

KNOWLEDGE Focus

System owners’ view

Interested not in raw data but in information that adds new business knowledge and information that help managers make intelligent decisions.
Data entities and business rules.

IS 531 : Lecture 2

KNOWLEDGE Focus . . .

System users’ view

Something recorded on forms, stored in file cabinets, recorded in books and binders, organized into spreadsheets, or stored in computer files and databases.
Focus on the business issues as they pertain to the data.
Data requirement – a representation of users’ data in terms of entities, attributes, relationships, and rules independent of data technology.

IS 531 : Lecture 2

KNOWLEDGE Focus . . .

System designers’ view

Data structures, database schemas, fields, indexes, and constraints of particular database management system (DBMS).

System builders’ view

Coding
DBMS or other data technologies

IS 531 : Lecture 2

PROCESS Focus

System owners’ view

concerned with high-level process
Business function – a group of related processes that support the business. Functions can be decomposed into other sub-functions, activities, tasks.
A cross-functional information system – a system that supports relevant business processes from several functions within organizational boundaries.

IS 531 : Lecture 2

PROCESS Focus . . .

System users’ view

concerned with work that must be performed to provide the appropriate responses to business events.
Business processes – activities that respond to business events.
Process requirements – a user’s expectation of the processing requirements for a business process and its information systems.
Policy – a set of rules that govern a business process.
Procedure – a step-by-step set of instructions and logic for accomplishing a business process.
Work flow – the flow of transactions through business processes to ensure appropriate checks and approvals are implemented.

IS 531 : Lecture 2

System designers’ view

Concerned with which processes to automate and how to automate them
Constrained by limitations of application development technologies being used
Software specifications – the technical design of business processes to be automated or supported by computer programs (off-shelf, in-house) to be written by system builders.

PROCESS Focus . . .

IS 531 : Lecture 2

System builders’ view

Concerned with programming logic that implements automated processes
Application program – a language-based, machine-readable representation of what a software process is supposed to do, or how a software process is supposed to accomplish its task.
Prototyping – a technique for quickly building a functioning, but incomplete model of the information system using rapid application development tools.

PROCESS Focus . . .

IS 531 : Lecture 2

COMMUNICATION Focus

System owners’ view

Concerned with communications scope of an information system.
Who (which business units, employees, customers, and partners) must interact with the system?
Where are these business units, employees, customers, and partners located?
What other information systems will the system have to interface with?

System users’ view

Concerned with the information system’s inputs and outputs (Interface Requirements).

IS 531 : Lecture 2

System designers’ view

Concerned with the technical design of both the user and the system-to-system communication interfaces.
Interface specifications – technical designs that document how system users are to interact with a system and how a system interacts with other systems.
User dialogue – a specification of how the user moves from window to window or page to page, interacting with the application programs to perform useful work.

COMMUNICATION Focus . . .

IS 531 : Lecture 2

System builders’ view

Concerned with the construction, installation, testing and implementation of user and system-to-system interface solutions.
Middleware – utility software that allows application software and systems software that utilize differing technologies to interoperate.

COMMUNICATION Focus . . .

IS 531 : Lecture 2

Systems Development Objectives

To ensure the information system satisfies an organization’s informational and operational needs (product-oriented objective).

To develop/acquire an information system in an efficient and effective manner (process-oriented objective).

IS 531 : Lecture 2

Characteristics of a Systems Development Methodology

Divide project into identifiable processes, each having a starting and ending point.

Produce deliverables to monitor process.

Require signoffs.

Test system before implementation.

Conduct training.

Use program change controls.

Conduct post-implementation review.

IS 531 : Lecture 2

Classic Systems Development Process

IS 531 : Lecture 2

Systems Development Process Phases

Scope Definition Phase

Problem Analysis Phase

Requirement Analysis Phase

Logical Design

Decision Analysis Phase

Design Phase

Construction Phase

Implementation Phase

IS 531 : Lecture 2

1. Scope Definition

Purpose: define perceived problems, opportunities, and directives ; assess the risk of project; establish scope, preliminary requirements and constraints, participants, budget and schedule (preliminary study)

Issues: Is the project worthwhile? (using PIECES framework) Define the scope of project

Deliverable: Project charter/plan

Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification

IS 531 : Lecture 2

2. Problem Analysis

Purpose: to study and analyze the existing system from the users’ perspectives as they see Data, Processes, and Interfaces

Issue: Cost/benefits of building new system to solve these problems

Deliverable: system improvement objectives (business criteria to evaluate the new system)

Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification

IS 531 : Lecture 2

3. Requirement Analysis

Purpose: discover users’ needs or expectations out of the new system in terms of Data, Processes, and Interfaces

Issue: Specify requirements for the new system (WHAT TO BE DONE) without prematurely expressing technical details (HOW)

Errors and omissions in requirement analysis result in user dissatisfaction of final system and costly modifications

Deliverable: business requirements statement

IS 531 : Lecture 2

4. Logical Design

Purpose: translating business user requirements into a system model that depicts only WHAT TO DO without specifying any possible technical design or implementation of those requirements (conceptual design).

Issue: using graphical model of a system to represent user requirements in terms of Data, Processes and Interfaces, and to facilitate improved communication between system stakeholders.

IS 531 : Lecture 2

5. Decision Analysis

Purpose: identify all candidate solutions, analyze the feasibility of each candidate, recommend a candidate system as the target solution

Issue: Feasibility analysis in terms of technical, operational, economic, schedule (TOES), and risk

Deliverable: approved system proposal

Feasibility check: Cancel project / Approve system proposal with budget and schedule modification / Reduce the scope of proposed solution with budget and schedule modification

IS 531 : Lecture 2

6. Physical Design

Purpose: to transform business requirements into technical design specifications for construction

Issue: HOW technology will be used to build the system in terms of Data, Processes, and Interfaces

Design by Specifications vs. Design by Prototyping

Deliverable: System design specifications (blueprints)

Feasibility check: Continue/ Reduce or expanse the scope with budget and schedule modification

IS 531 : Lecture 2

7. Construction Phase

Purpose: to build and test a system that fulfill business requirements and design specs; implement interfaces between new and existing systems

Issue: Construct database, application programs, user/system interfaces, implement purchased or leased software

Deliverable: proposed system within budget and schedule

IS 531 : Lecture 2

8. Implementation Phase

Purpose: deliver the production system into operation

Issue: Train users, write manuals, load files, populate database, final test

Conversion plan: parallel systems, switch point

Deliverable: system up and running

IS 531 : Lecture 2

Operation and Support

Ongoing system support would be provided until the system becomes obsolete and is replaced by a new one

Issues: technical support for user, fixing bugs, recovering plan, adapt to emerging requirements

When a system has reached entropy, new project for new system should be initiated

IS 531 : Lecture 2

Summary:
Systems Development Process

Scope Definition Phase: What Business Problem
Problem Analysis Phase: What System Issues (Info/Data, Processes, Communications/Interfaces)
Requirement Analysis Phase: What User Needs
Logical Design: (Conceptual Model) – What to Do
Decision Analysis Phase: What Solution
Design Phase: (Physical Model) - How IT Can Do
Construction Phase: Do It
Implementation Phase: Use It

IS 531 : Lecture 2

Systems Development as Problem Solving

IS 531 : Lecture 2

Feasibility Analysis

Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise.
Operational feasibility is a measure of how well the solution will work in the organization. It is also a measure of how people feel about the system/project.
Economic feasibility is a measure of the cost-effectiveness of a project or solution.
Schedule feasibility is a measure of how reasonable the project timetable is.
Risk feasibility – What is the probability of a successful implementation using the technology and approach? (Risk Management)

IS 531 : Lecture 2

Costs and Benefits

Direct costs (benefits): directly attributable to the system or the system change.
Direct costs include equipment purchased, personnel salaries, site preparation, and materials and supplies.
Direct benefits include items such as reduced personnel and hardware costs, and improved data reliability.

IS 531 : Lecture 2

Costs and Benefits . . .

Indirect costs (benefits): not directly attributable to the system or the system change.
Indirect costs are those associate with overhead expenses, such as personnel fringe benefits and utilities.
Indirect benefits are most difficult to quantify. Ex: an indirect benefit is increased revenue resulting from improved customer support

IS 531 : Lecture 2

Costs and Benefits ...

Tangible costs (benefits): can be reasonably quantified.
Costs include software purchases and insurance
Benefits include reduced equipment costs and increased revenue.
Intangible cost (benefit): cannot be reasonably quantified.
Costs include productivity loss caused by low employee morale.
Benefits may accrue from improved information.

IS 531 : Lecture 2

Costs and Benefits ...

Nonrecurring costs, such as those for systems development, are incurred only once to get the system operational (development costs).
Recurring costs, such as those for equipment rental, occur throughout all or most of the system’s life (operational costs).

IS 531 : Lecture 2

Economic Feasibility

Payback Analysis
Payback analysis is to determine if and when an investment will pay for itself.
Payback period is the period of time that will lapse before accrued benefits overtake accrued and continuing costs.
Net Present Value
a dollar today is worth more than a dollar one year from now
Discount rate : a percentage that the business earns on investing money in other projects or investments: opportunity cost

IS 531 : Lecture 2

Economic Feasibility …

Return-on-Investment (ROI) Analysis
Lifetime ROI =(estimated lifetime benefits – estimated lifetime costs) / estimated lifetime costs
Annual ROI = lifetime ROI / lifetime of the system

IS 531 : Lecture 2

Scheduling Strategies

Forward Scheduling – a project scheduling approach that establishes a project start date and then schedules forward from that date.

Reverse Scheduling – a project scheduling strategy that establishes a project deadline and then schedules backward from that date.

IS 531 : Lecture 2

PERT Chart

5-3-2001

5-12-2001

5-3-2001

5-11-2001

Preliminary Investigation

5-12-2001

6-12-2001

5-12-2001

6-14-2001

Problem Analysis

5-28-2001

7-15-2001

5-30-2001

7-18-2001

Requirements Analysis

6-13-2001

7-30-2001

6-13-2001

8-3-2001

Decision Analysis

9-10-2001

12-14-2001

TBD

Implementation

7-19-2001

11-13-2001

7-20-2001

In Progress

Construction

7-3-2001

9-25-2001

7-5-2001

10-9-2001

Design

5-3-2001

N/A

5-3-2001

N/A

Project Initiation

Scheduled

Start

Scheduled

Finish

Actual Start

Actual

Finish

Task

Scheduled

Start

Scheduled

Finish

Actual Start

Actual

Finish

Task

intertask

dependency

Legend

IS 531 : Lecture 2

Critical Path

IS 531 : Lecture 2

TASK

Fri 2/9/01

2 days

Fri 2/9/01

0 days

TASK

Tue 2/20/01

7 days

Tue 2/20/01

0 days

TASK

Tue 2/27/01

5 days

Tue 2/27/01

0 days

TASK

Mon 2/19/01

6 days

Tue 2/20/01

1 day

TASK

Wed 2/7/01

2 days

Wed 2/7/01

0 days

TASK

Mon 2/5/01

3 days

Mon 2/5/01

0 days

TASK

Thu 2/15/01

1 day

Tue 2/20/01

3 days

TASK

Wed 2/14/01

3 days

Fri 2/16/01

2 days

TASK

Fri 2/16/01

2 days

Tue 2/20/01

2 days

Duration

Slack Time

IS 531 : Lecture 2

No additional notes

Gantt Chart

IS 531 : Lecture 2

Incomplete Task

Complete Task

Legend

Preliminary investigation

Problem analysis

Requirements analysis

Decision analysis

Design

Construction

Implementation

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

2001

Task Name

Today

IS 531 : Lecture 2

In-Sourcing Vs. Outsourcing

In-sourcing (Build) –Uses professional expertise within an organization to develop and maintain its information technology systems

Outsourcing (Buy) – Obtains services from a software developer

IS 531 : Lecture 2

Design the Application Architecture

Defines technologies to be used and used to build

Design the System Databases

Database schema

Design the System Interface

User Interfaces: Input, output, and dialogue specifications

Package Design Specifications

Specifications for programmers

Tasks for “Build” Option

IS 531 : Lecture 2

No additional notes.

Tasks for “Buy” Option

Research Technical Criteria and Options

Solicit Proposals/Quotes from Vendors

Validate Vendor Claims and Performances

Evaluate and Rank Vendor Proposals: Gap Analysis on the differences between proposed and desired features. Also Cost/Benefit Analysis.

Contract “Winning” Vendor and Debrief “Losing” Vendors

IS 531 : Lecture 2

Systems Acceptance Test

Systems Acceptance Test – a test performed on the final system wherein users conduct a verification, validation, and audit test.

Uses real data over an extended time period
Extensive test that addresses: verification testing, validation testing, and audit testing.

Verification Testing runs the system in a simulated environment using simulated data.

Checks for errors and omissions regarding end-use and design specifications

IS 531 : Lecture 2

No additional notes

Systems Acceptance Test …

Validation testing runs the system in a live environment using real data.

Testing:
Systems performance (throughput and response time)
Peak workload performance
Human engineering
Methods and procedures
Backup and recovery

Audit testing certifies that the system is free of errors and is ready to be placed into operation.

IS 531 : Lecture 2

No additional notes.

Conduct System Test

Prepare Conversion Plan

Install Databases

Train Users

Convert to New System

Tasks in Implementation Phase

IS 531 : Lecture 2

No additional notes

System Conversion

IS 531 : Lecture 2

Installation/Conversion Approaches

Risk

Cost

Abrupt

Cutover

Location

Conversion

Staged

Conversion

Parallel

Conversion

IS 531 : Lecture 2

No additional notes

Post-Implementation Review

Post-implementation review: examination of a working information system, conducted soon after that system’s implementation, to determine if:
user’s requirements have been satisfied
development effort was efficient and conducted in accordance with the organization’s systems development standards.

IS 531 : Lecture 2

Post Implementation Review…

Determine if the user is satisfied with the new system.
Identify how well the system’s achieved performance corresponds to the performance requirements, recommending improvements if necessary.
Evaluate the quality of the new system’s documentation, training programs, and data conversions.

IS 531 : Lecture 2

Post Implementation Review…

Ascertain that the organization’s project management framework and SDLC were followed during development.

Recommend improvements to the systems development/acquisition standards manual if necessary.

Improve the cost/effectiveness analysis process by reviewing cost projections and benefit estimations and determining the degree to which these were achieved.

IS 531 : Lecture 2

System Support Activities

Program Maintenance corrects “bugs” or errors that slipped through the system development process.
System Recovery is the restoration of the system and data after a system failure.
Technical Support is any assistance provided to users in response to inexperience or unanticipated situations.
System Enhancement is the improvement of the system to handle new business problems, new technical problems, or new technology requirements.

IS 531 : Lecture 2

No additional notes.

System Maintenance Objectives

To make predictable changes to existing programs to correct errors.

To preserve those aspects of the programs that were correct, and to avoid “ripple effects” of changes that may adversely affect the correctly functioning aspects.

To avoid, as much as possible, the degradation of system performance.

To complete the task as quickly as possible without sacrificing quality and reliability of the system.

IS 531 : Lecture 2

No additional notes.

System Obsolescence

All systems degrade over time (entropy)

At some point, not cost-effective to support and maintain

Leads to a new systems development project

New cycle of SDLC

IS 531 : Lecture 2

Typical Contents of
a Systems Proposal

IS 531 : Lecture 2

The resulting information system is acceptable to the user.

The system was delivered “on time.”

The system was delivered “within budget.”

The system development process had a minimal impact on ongoing organizational operations.

Measures of Project Success

IS 531 : Lecture 2