http://dn58412/is531/is531_sp15.html lecture 2 systems development process

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

Lecture 2Systems Development Process

Learning ObjectivesLearning Objectives

1. Systems Development Life Cycle vs. Systems Development Process

2. Zachman Framework and Stakehoders’ Perspectives in Systems Development

3. Classic Phases in Systems Development Process

IS 531 : Lecture 2 2

Systems Development Systems Development Life Cycle (SDLC)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.


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



Where Do Systems Development Where Do Systems Development Projects Come From?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.


PIECES Framework for Systems PIECES Framework for Systems ImprovementImprovement

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.



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



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


Problem-SolvingProblem-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


Problem-Solving …Problem-Solving …

• Why: (Project Justification)

– Effective: Do right thing

– Efficient: Do thing right

– Competitive: Do thing differently


Zachman FrameworkZachman Framework


Perspectives on Perspectives on an Information Systeman Information System


System StakeholdersSystem Stakeholders

• System owners • System users• System analysts• System designer• System builder


System OwnersSystem 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


System UsersSystem 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


• 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 DesignersSystem Designers


• 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 BuildersSystem Builders


Systems AnalystsSystems 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


HIS Professional Involvement in HIS Professional Involvement in Systems DevelopmentSystems Development• User

• Analyst

• Purchaser

• Implementer

• Consultant

• Internal Auditor

• External Auditor


Focuses for Focuses for Information SystemsInformation 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.


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


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


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


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


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


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


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


COMMUNICATION FocusCOMMUNICATION 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).


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


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


Systems Development ObjectivesSystems 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).


Characteristics of a Systems Characteristics of a Systems Development MethodologyDevelopment 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.


Classic Systems Classic Systems Development ProcessDevelopment Process


Systems Development Systems Development Process PhasesProcess Phases

• Scope Definition Phase• Problem Analysis Phase• Requirement Analysis Phase• Logical Design• Decision Analysis Phase• Design Phase• Construction Phase• Implementation Phase


1. Scope Definition1. 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


2. Problem Analysis2. 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


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 statementIS 531 : Lecture 2 38

4. Logical Design4. 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.


5. Decision Analysis5. 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


6. Physical Design6. 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


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


8. Implementation Phase8. 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


Operation and SupportOperation 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


Summary: Summary: Systems Development ProcessSystems 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



Systems Development as Systems Development as Problem SolvingProblem Solving

Feasibility AnalysisFeasibility 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)


Costs and BenefitsCosts 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.


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


Costs and Benefits ...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.


Costs and Benefits ...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).


Economic FeasibilityEconomic 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


Economic Feasibility …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


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


PERT ChartPERT 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 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

ScheduledStart

ScheduledFinish

Actual Start ActualFinish

Task

ScheduledStart

ScheduledFinish

Actual Start ActualFinish

Task

intertaskdependency

Legend


Critical PathCritical Path

TASKC

Fri 2/9/01 2 days

Fri 2/9/01 0 days

TASKD

Tue 2/20/01 7 days

Tue 2/20/01 0 days

TASKI

Tue 2/27/01 5 days

Tue 2/27/01 0 days

TASKE

Mon 2/19/016 days

Tue 2/20/01 1 day

TASKB

Wed 2/7/01 2 days

Wed 2/7/01 0 days

TASKA

Mon 2/5/01 3 days

Mon 2/5/01 0 days

TASKH

Thu 2/15/01 1 day

Tue 2/20/01 3 days

TASKF

Wed 2/14/013 days

Fri 2/16/01 2 days

TASKG

Fri 2/16/01 2 days

Tue 2/20/01 2 days

Duration

Slack Time


Gantt ChartGantt Chart

Incomplete Task

Complete Task

Legend

ID

1

2

3

4

5

6

7

Preliminary investigation

Problem analysis

Requirements analysis

Decision analysis

Design

Construction

Implementation

May Jun Jul Aug Sep Oct Nov Dec

2001Task Name

Today


In-Sourcing Vs. OutsourcingIn-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


• 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” OptionTasks for “Build” Option


Tasks for “Buy” OptionTasks 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


Systems Acceptance TestSystems 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


Systems Acceptance Test …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.


• Conduct System Test• Prepare Conversion Plan• Install Databases• Train Users• Convert to New System

Tasks in Implementation PhaseTasks in Implementation Phase


System ConversionSystem Conversion


Installation/Conversion Installation/Conversion Approaches Approaches

Risk

Cost

AbruptCutover

LocationConversion

StagedConversion

ParallelConversion


Post-Implementation ReviewPost-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.


Post Implementation Review…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.


Post Implementation Review…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.


System Support ActivitiesSystem 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 269

System Maintenance System Maintenance ObjectivesObjectives

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


System ObsolescenceSystem 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


Typical Contents of Typical Contents of a Systems Proposala Systems Proposal


• 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 SuccessMeasures of Project Success


http://dn58412/is531/is531_sp15.html lecture 2 systems development process

Documents